Hakala Request for Comments: L. Koskinen M. Stura J. Loughney Nokia August Diameter Credit-Control Application Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.
|Published (Last):||9 December 2019|
|PDF File Size:||1.89 Mb|
|ePub File Size:||12.11 Mb|
|Price:||Free* [*Free Regsitration Required]|
Transient Failures Permanent Failures AVP Occurrence Table IANA Considerations Application Identifier Command Codes AVP Codes Credit-Control AVP Requested-Action AVP Parameters Related to the Credit-Control Application Security Considerations Direct Connection with Redirects Application-Level Redirects Privacy Considerations Privacy-Sensitive AVPs Data Minimization Diameter Agents Normative References Informative References Credit-Control Sequences Flow I Flow II Flow III Flow IV Flow V Flow VI Flow VII Flow VIII Flow IX Introduction This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol SIP services, messaging services, and download services.
The Diameter Credit-Control application as defined in this document obsoletes [ RFC ], and it must be supported by all new Diameter Credit-Control application implementations. This document provides a general solution to real-time cost and credit-control. The prepaid model has been shown to be very successful -- for instance, in GSM networks, where network operators offering prepaid services have experienced a substantial growth of their customer base and revenues.
Prepaid services are now cropping up in many other wireless and wire-line-based networks. In mobile networks, additional functionality is required beyond that specified in the Diameter base protocol [ RFC ]. When an account is exhausted or expired, the user must be denied the ability to compile additional chargeable events. Bertz, et al. In addition, there are services such as gaming and advertising that may credit as well as debit a user account.
The other Diameter applications provide service-specific authorization, and they do not provide credit authorization for prepaid users. The credit authorization shall be generic and applicable to all the service environments required to support prepaid services. To fulfill these requirements, it is necessary to facilitate credit-control communication between the network element providing the service e.
The scope of this specification is credit authorization. Service- specific authorization and authentication are out of scope. AA-Answer: "AA-Answer" generically refers to a service-specific authorization and authentication answer. AA-Answer commands are defined in service-specific authorization applications, e.
AA-Request: "AA-Request" generically refers to a service-specific authorization and authentication request. AA-Request commands are defined in service-specific authorization applications, e.
Credit-control: "Credit-control" is a mechanism that directly interacts in real time with an account and controls or monitors the charges related to service usage. Credit-control is a process of 1 checking whether or not credit is available, 2 credit reservation, 3 deduction of credit from the end-user account when service is completed, and 4 refunding of reserved credit that is not used. It is located in the home domain and is accessed by Service Elements or Diameter AAA servers in real time, for the purpose of price determination and credit-control before the service event is delivered to the end user.
It may also interact with Business Support Systems. Diameter Credit-Control client: A Diameter Credit-Control client is an entity that interacts with a credit-control server.
It monitors the usage of the granted quota according to instructions returned by the credit-control server. Interrogation: The Diameter Credit-Control client uses interrogation to initiate a session-based credit-control process. During the credit-control process, it is used to report the used quota and request a new one.
One-time event: A charging transaction session comprising a single request and single response. Rating: The act of determining the cost of the service event. Service: A type of task performed by a Service Element for an end user. Service Element: A network element that provides a service to the end users. In the latter case, the interface between the Service Element and the Diameter Credit-Control client is outside the scope of this specification. Service event: An event relating to a service provided to the end user.
Session-based credit-control: A credit-control process that makes use of several interrogations: the first, a possible intermediate, and the final. Intermediate interrogations if any may be needed to request a new quota while the service is being rendered.
The final interrogation is used to exit the process. The credit-control server is required to maintain session state for session-based credit-control. Also, the existing Diameter authorization applications [ RFC ] [ RFC ] only provide service authorization; they do not provide credit authorization for prepaid users.
In order to support real-time credit-control, a new type of server is needed in the AAA infrastructure: the Diameter Credit-Control server. The Diameter Credit-Control server is the entity responsible for credit authorization for prepaid subscribers. Accounting protocols such as RADIUS accounting and the Diameter base accounting protocol can be used to provide accounting data to the accounting server after service is initiated and to provide possible interim reports until service completion.
However, for real-time credit-control, these authorization and accounting models are not sufficient. When real-time credit-control is required, the credit-control client contacts the credit-control server with information about a possible service event.
A Business Support System is usually deployed; at a minimum, it includes billing functionality. The credit-control server and AAA server in this architecture model are logical entities. The real configuration can combine them into a single host. In some cases, it might be possible that the Service Element in the local realm [ RFC ] can offer services to the end user; however, a commercial agreement must exist between the local realm and the home realm.
The system can also contain separate rating server s , and accounts can be located in a centralized database. System-internal interfaces can exist to relay messages between servers and an account manager. However, the detailed architecture of the credit-control system and its interfaces is implementation specific and is out of scope for this specification.
Protocol-transparent Diameter relays can exist between the credit-control client and credit-control server. Also, Diameter redirect agents that refer credit-control clients to credit-control servers and allow them to communicate directly can exist. These agents transparently support the Diameter Credit-Control application. These formats are observed in credit-control messages.
It is used between the Diameter Credit-Control client and the credit-control server to request credit authorization for a given service. It is used between the credit-control server and the Diameter Credit-Control client to acknowledge a Credit-Control-Request command. The credit-control application defined in this specification supports two different credit authorization models: credit authorization with money reservation and credit authorization with direct debiting.
In both models, the credit-control client requests credit authorization from the credit-control server prior to allowing any services to be delivered to the end user. Note that credit resources may not imply actual monetary credit; credit resources may be granted to the credit-control client in the form of units e. Upon receipt of a successful credit authorization answer with a certain amount of credit resources, the credit-control client allows service delivery to the end user and starts monitoring the usage of the granted resources.
When the credit resources granted to the user have been consumed or the service has been successfully delivered or terminated, the credit-control client reports back to the server the used amount. This process is accomplished with session-based credit-control that includes the first interrogation, possible intermediate interrogations, and the final interrogation.
For session-based credit-control, both the credit-control client and the credit-control server are required to maintain credit-control session state. Session-based credit-control is described in more detail, with more variations, in Section 5.
Upon receipt of a successful credit authorization answer, the credit-control client allows service delivery to the end user. This process is accomplished with the one-time event. Session state is not maintained. In a multi-service environment, an end user can issue an additional service request e. Alternatively, during an active multimedia session, an additional media type is added to the session, causing a new simultaneous request toward the same account. Consequently, this needs to be considered when credit resources are granted to the services.
These operations are accomplished with the one-time event.
DIAMETER PROTOCOL RFC 4006 PDF
Google Network Working Group H. Hakala Request for Comments: L. Koskinen M. Stura J.
Diameter Credit-Control Application
Bertz, Ed. Request for Comments: Sprint Obsoletes: D. Dolson, Ed. Category: Standards Track Y. Lifshitz, Ed. ISSN: Sandvine March Diameter Credit-Control Application Abstract This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol SIP services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC , and it must be supported by all new Diameter Credit-Control application implementations.
Yozshut Distribution of this memo is unlimited. It is used between the credit-control server and the Diameter credit-control client to acknowledge a Credit- Control-Request command. This process is accomplished with the one-time event. Obsolete RFCs are indicated with strikethrough text. Abstract This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of diametr user services such as network access, Session Initiation Protocol SIP services, messaging services, and download services. If cleared, the message MUST be locally processed. Therefore, it is assumed that a Diameter credit-control server will provide service only for Diameter credit-control clients that have agreed beforehand as to the content of credit-control messages.
DIAMETER RFC 4006 PDF
Money Points Units e. For instance, a user may pay for both online time and download bytes but has only a single account balance. Session-based charging[ edit ] A session-based credit control process uses several interrogations which may include first, intermediate and last interrogation. During interrogation money is reserved from the user account. Session-based charging is typically used for scenarios where the charged units are continuously consumed, e. Event-based charging[ edit ] An event-based credit control process uses events as charging mechanism.