RFC 8506
Diameter Credit-Control Application
Appendix A. Credit-Control Sequences
A.1. Flow I
A credit-control flow for Network Access Services prepaid is shown in Figure 11. The Diameter protocol application is implemented in the Network Access Server (NAS) per [RFC7155]. The focus of this flow is on credit authorization. NAS End User (CC Client) AAA Server CC Server |(1)User Logon |(2)AA-Request (CC AVPs) | |------------------>|-------------------->| | | | |(3)CCR(Initial, CC AVPs) | | |-------------------->| | | |(4)CCA(Granted-Units)| | | |<--------------------| | |(5)AA-Answer(Granted-Units) | |(6)Access granted |<--------------------| | |<----------------->| | | | | | | : : : : | |(7)CCR(Update, Used-Units) | | |-------------------->|(8)CCR | | | | (Update, Used-Units) | | |-------------------->| | | |(9)CCA(Granted-Units)| | |(10)CCA(Granted-Units)<--------------------| | |<--------------------| | : : : : | (Auth. lifetime expires) | | | |(11)AAR (CC AVP) | | | |-------------------->| | | | (12)AAA | | | |<--------------------| | : : : : : : : :
|(13)User logoff | | | |------------------>|(14)CCR(Term., Used-Units) | | |-------------------->|(15)CCR | | | | (Term., Used-Units) | | |-------------------->| | | | (16)CCA | | | (17)CCA |<--------------------| | |<--------------------| | | |(18)STR | | | |-------------------->| | | | (19)STA | | | |<--------------------| | Figure 11: Flow I The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server (2). The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, as usual [RFC7155]. The home Diameter AAA server performs service- specific authentication and authorization, as usual. The home Diameter AAA server determines that the user is a prepaid user and notices from the Credit-Control AVP that the NAS has credit-control capabilities. It sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service-specific AVPs received from the NAS as input for the rating process.) The Diameter Credit-Control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. The reserved quota is returned to the home Diameter AAA server in the Diameter Credit-Control-Answer (4). The home Diameter AAA server sends the reserved quota to the NAS in the Diameter AA-Answer (AAA). Upon receiving the AA-Answer, the NAS starts the credit-control session and starts monitoring the granted units (5). The NAS grants access to the end user (6). At the expiry of the allocated quota, the NAS sends a Diameter Credit-Control- Request with CC-Request-Type set to UPDATE_REQUEST to the home Diameter AAA server (7). This message contains the units used thus far. The home Diameter AAA server forwards the CCR to the Diameter Credit-Control server (8). The Diameter Credit-Control server debits the used units from the end user's account and allocates a new quota that is returned to the home Diameter AAA server in the Diameter Credit-Control-Answer (9). The message is forwarded to the NAS (10). During the ongoing credit-control session, the authorization lifetime expires, and the authorization/authentication client in the NAS performs service-specific re-authorization to the home Diameter AAA server, as usual. The credit-control client populates the AAR with
the Credit-Control AVP set to RE_AUTHORIZATION, indicating that the credit-control server shall not be contacted, as the credit authorization is controlled by the burning rate of the granted units (11). The home Diameter AAA server performs service-specific re-authorization as usual and returns the AA-Answer to the NAS (12). The end user logs off from the network (13). To debit the used units from the end user's account and to stop the credit-control session, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the home Diameter AAA server (14). The home Diameter AAA server forwards the CCR to the credit-control server (15). The Diameter Credit-Control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the home Diameter AAA server (16). The home Diameter AAA server forwards the answer to the NAS (17). The STR/STA takes place between the NAS and home Diameter AAA server, as usual (18), (19).A.2. Flow II
Figure 12 provides an example of Diameter Credit-Control for SIP sessions. Although the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's SIP network. However, for the sake of this example, some assumptions are made below.
SIP Proxy/Registrar AAA A (CC Client) Server B CC Server | (i) REGISTER | | | | |------------->|(ii) | | | | |------------->| | | | |authentication & | | | |authorization | | | | |<-------------| | | |(iii) 200 OK | | | |<-------------| | | : : : : |(1) INVITE | : |------------->| | |(2) CCR (Initial, SIP-specific AVP) | | |------------------------------------------->| | |(3) CCA (Granted-Units) | | |<-------------------------------------------| | |(4) INVITE | | | |---------------------------->| | : : : : | |(5) CCR (Update, Used-Units) | | |------------------------------------------->| | |(6) CCA (Granted-Units) | | |<-------------------------------------------| : : : : |(7) BYE | | | |------------->| | | | |(8) BYE | | | |---------------------------->| | | |(9) CCR (Termination, Used-Units) | | |------------------------------------------->| | |(10) CCA () | | |<-------------------------------------------| | | | | Figure 12: Flow II Typically, prepaid services based, for example, on time usage for SIP sessions require an entity in the service provider network to intercept all the requests within the SIP dialog in order to detect events, such as session establishment and session release, that are essential for performing credit-control operations with the credit-control server. Therefore, in this example, it is assumed that the SIP Proxy adds a Record-Route header in the initial SIP INVITE to make sure that all the future requests in the created dialog traverse through it (for the definitions of "Record-Route" and "dialog", please refer to [RFC3261]). Finally, the degree of
credit-control measuring of the media by the proxy depends on the business model design used in setting up the end system and proxies in the SIP network. The end user (SIP User Agent A) sends a REGISTER with credentials (i). The SIP Proxy sends a request to the home AAA server to perform multimedia authentication and authorization by using, for instance, a Diameter multimedia application (ii). The home AAA server checks that the credentials are correct and checks the user profile. Eventually, a 200 OK response (iii) is sent to the User Agent. Note that the authentication and authorization are valid for the registration validity period duration (i.e., until re-registration is performed). Several SIP sessions may be established without re-authorization. User Agent A sends an INVITE (1). The SIP Proxy sends a Diameter Credit-Control-Request (INITIAL_REQUEST) to the Diameter Credit-Control server (2). The Credit-Control-Request contains information obtained from the SIP signaling describing the requested service (e.g., calling party, called party, Session Description Protocol (SDP) attributes). The Diameter Credit-Control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. The reserved quota is returned to the SIP Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy forwards the SIP INVITE to User Agent B (4). B's phone rings, and B answers. The media flows between them, and the SIP Proxy starts measuring the quota. At the expiry of the allocated quota, the SIP Proxy sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (5). This message contains the units used thus far. The Diameter Credit-Control server debits the used units from the end user's account and allocates new credit that is returned to the SIP Proxy in the Diameter Credit-Control-Answer (6). The end user terminates the service by sending a BYE message (7). The SIP Proxy forwards the BYE message to User Agent B (8) and sends a Diameter Credit-Control- Request (TERMINATION_REQUEST) to the credit-control server (9). The Diameter Credit-Control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the SIP Proxy (10).
A.3. Flow III
A credit-control flow for Multimedia Messaging Service is shown in Figure 13. The sender is charged as soon as the messaging server successfully stores the message. MMS Server A (CC Client) B CC Server |(1) Send MMS | | | |--------------->| | | | |(2) CCR (Event, DIRECT_DEBITING, | | | MMS-specific AVP) | | |-------------------------------->| | |(3) CCA (Granted-Units) | | |<--------------------------------| |(4) Send MMS Ack| | | |<---------------| | | | |(5) Notify MMS | | | |--------------->| | : : : : | |(6) Retrieve MMS| | | |<---------------| | | |(7) Retrieve MMS| | | | Ack | | | |--------------->| | | | | | Figure 13: Flow III This is an example of Diameter Credit-Control for direct debiting using the Multimedia Messaging Service environment. Although the flow focuses on illustrating the usage of credit-control messages, the MMS signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's MMS configuration or billing model. End user A sends an MMS to the MMS server (1). The MMS server stores the message and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to DIRECT_DEBITING) to the Diameter Credit-Control server (2). The Credit-Control-Request contains information about the MMS message (e.g., size, recipient address, image coding type). The Diameter Credit-Control server checks the end user's account balance, rates the service, and debits the service from the end user's account. The granted quota is returned to the MMS server in the Diameter Credit-Control-Answer (3).
The MMS server acknowledges the successful reception of the MMS message (4). The MMS server notifies the recipient about the new MMS (5), and end user B retrieves the message from the MMS message store (6), (7). Note that the transfer of the MMS message can take an extended period of time and can fail, in which case a recovery action is needed. The MMS server should return the already-debited units to the user's account by using the REFUND action described in Section 6.4.A.4. Flow IV
Another credit-control flow for Multimedia Messaging Service is shown in Figure 14. The recipient is charged at the time of message delivery. MMS Server Content Server (CC Client) B CC Server |(1) Send MMS | | | |--------------->| | | | |(2) CCR (Event, CHECK_BALANCE, | | | MMS-specific AVP) | | |-------------------------------->| | |(3) CCA (ENOUGH_CREDIT) | | |<--------------------------------| |(4) Send MMS Ack| | | |<---------------| | | | |(5) Notify MMS | | | |--------------->| | : : : : | |(6) Retrieve MMS| | | |<---------------| | | |(7) CCR (Event, DIRECT_DEBITING, | | | MMS-specific AVP) | | |-------------------------------->| | |(8) CCA (Granted-Units) | | |<--------------------------------| | |(9) Retrieve MMS| | | | Ack | | | |--------------->| | | | | | Figure 14: Flow IV
This is an example of Diameter Credit-Control for direct debiting using the Multimedia Messaging Service environment. Although the flow focuses on illustrating the usage of credit-control messages, the MMS signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's MMS configuration or billing model. A content server sends an MMS to the MMS server (1), which stores the message. The message recipient will be charged for the MMS message in this case. As there can be a substantially long time between the receipt of the message at the MMS server and the actual retrieval of the message, the MMS server does not establish any credit-control sessions to the Diameter Credit-Control server; rather, it first performs only a balance check (without any credit reservations) by sending a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to CHECK_BALANCE) to verify that end user B can cover the cost for the MMS (2). The Diameter Credit-Control server checks the end user's account balance and returns the answer to the MMS server in the Diameter Credit-Control-Answer (3). The MMS server acknowledges the successful reception of the MMS message (4). The MMS server notifies the recipient of the new MMS (5), and after some time end user B retrieves the message from the MMS message store (6). The MMS server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to DIRECT_DEBITING) to the Diameter Credit-Control server (7). The Credit-Control-Request contains information about the MMS message (e.g., size, recipient address, coding type). The Diameter Credit-Control server checks the end user's account balance, rates the service, and debits the service from the end user's account. The granted quota is returned to the MMS server in the Diameter Credit-Control-Answer (8). The MMS is transferred to end user B (9). Note that the transfer of the MMS message can take an extended period of time and can fail, in which case a recovery action is needed. The MMS server should return the already-debited units to the user's account by using the REFUND action described in Section 6.4.
A.5. Flow V
Figure 15 provides an example of an Advice of Charge (AoC) service for a SIP call. SIP Controller User Agent A (CC Client) User Agent B CC Server |(1)INVITE | | | | User Agent B(SDP)| | | |------------------>| | | | |(2)CCR (Event, PRICE_ENQUIRY, | | | SIP-specific AVPs) | | |------------------------------->| | |(3)CCA (Cost-Information) | | |<-------------------------------| |(4)MESSAGE(URL) | | | |<------------------| | | |(5)HTTP GET | | | |------------------>| | | |(6)HTTP POST | | | |------------------>|(7)INVITE(SDP) | | | |--------------->| | | | (8)200 OK | | | (9)200 OK |<---------------| | |<------------------| | | Figure 15: Flow V This is an example of Diameter Credit-Control for SIP sessions. Although the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's SIP network. User Agent A can be either a postpaid or prepaid subscriber using the AoC service. It is assumed that the SIP controller also has HTTP capabilities and delivers an interactive AoC web page with, for instance, the cost information, the details of the call derived from the SDP, and a button to accept/not accept the charges. (There may be many other ways to deliver AoC information; however, this flow focuses on the use of the credit-control messages.) The user has been authenticated and authorized prior to initiating the call and has been subscribed to the AoC service. User Agent A sends an INVITE with the SDP to User Agent B via the SIP controller (1). The SIP controller determines that the user is subscribed to an AoC service and sends a Diameter Credit-Control- Request (EVENT_REQUEST with Requested-Action set to PRICE_ENQUIRY) to the Diameter Credit-Control server (2). The Credit-Control-Request
contains SIP-specific AVPs derived from the SIP signaling, describing the requested service (e.g., calling party, called party, SDP attributes). The Diameter Credit-Control server determines the cost of the service and returns the Credit-Control-Answer, including the Cost-Information AVP (3). The SIP controller manufactures the AoC web page with information received in SIP signaling and with the cost information received from the credit-control server. It then sends a SIP MESSAGE that contains a URL pointing to the AoC information web page (4). Upon receipt of the SIP MESSAGE, User Agent A automatically invokes the web browser that retrieves the AoC information (5). The user clicks on the appropriate button to accept the charges (6). The SIP controller continues the session and sends the INVITE to User Agent B, which accepts the call (7), (8), (9).A.6. Flow VI
Figure 16 illustrates a credit-control flow for the REFUND case. It is assumed that there is a trusted relationship and secure connection between the gaming server and the Diameter Credit-Control server. The end user may be a prepaid subscriber or a postpaid subscriber. Gaming Server End User (CC Client) CC Server | (1)Service Delivery | | |<---------------------->| | : : : : : : | |(2)CCR(Event, REFUND,Requested- | |Service-Unit, Service-Parameter-Info) | |----------------------->| | | (3)CCA(Cost-Information) | |<-----------------------| | (4)Notification | | |<-----------------------| | Figure 16: Flow VI While the end user is playing the game (1), they enter a new level that entitles them to a bonus. The gaming server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to REFUND_ACCOUNT) to the Diameter Credit-Control server (2). The Credit-Control-Request contains the Requested-Service-Unit AVP with the CC-Service-Specific-Units containing the number of points the user just won. The Service-Parameter-Info AVP is also included in the request and specifies the service event to be rated (e.g., Tetris Bonus). From information received, the Diameter Credit-Control server determines the amount to be credited, refunds the user's account, and returns the Credit-Control-Answer, including the
Cost-Information AVP (3). The Cost-Information AVP indicates the credited amount. At the first opportunity, the gaming server notifies the end user of the credited amount (4).A.7. Flow VII
Figure 17 provides an example of graceful service termination for a SIP call. It is assumed that the call is set up so that the controller is in the call as a B2BUA (Back-to-Back User Agent) performing third-party call control (3PCC). Note that the SIP signaling is inaccurate, as the focus of this flow is on graceful service termination and credit-control authorization. Best practices for 3PCC are defined in [RFC3725]. SIP Controller Top-Up User Agent A (CC Client) Server User Agent B CC Server | | | | | | | (1)CCR(Update, Used-Units) | | | |------------------------------------------>| | | (2)CCA(Final-Unit, Redirect)| | |<------------------------------------------| : : : : : : : : : : | | (3)CCR(Update, Used-Units)| | | |------------------------------------------>| | | (3a)INVITE("hold") | | | |--------------------------->| | | | | (4)CCA(Validity-Time)| | |<------------------------------------------| | (5)INVITE | (6)INVITE | | | |<---------------|------------->| | | | (7)RTP | | | |...............................| | | | | (8)BYE | | | | |<-------------| | | | | (9)CCR(Update) | | | |------------------------------------------>| | | (10)CCA(Granted-Units)| | |<------------------------------------------| | (12)INVITE | (11)INVITE | | |<---------------|--------------------------->| | Figure 17: Flow VII
The call is ongoing between User Agents A and B; User Agent A has a prepaid subscription. At the expiry of the allocated quota, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (1). This message contains the units used thus far. The Diameter Credit-Control server debits the used units from the end user's account and allocates the final quota returned to the SIP controller in the Diameter Credit-Control-Answer (2). This message contains the Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to SIP URI, and the Redirect-Server-Address set to the top-up server name (e.g., sip:sip-topup-server@domain.com). At the expiry of the final allocated quota, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (3) and places the called party on "hold" by sending an INVITE with the appropriate connection address in the SDP (3a). The Credit-Control-Request message contains the units used thus far. The Diameter Credit-Control server debits the used units from the end user's account but does not make any credit reservations. The Credit-Control-Answer message, which contains the Validity-Time to supervise the graceful service termination process, is returned to the SIP controller (4). The SIP controller establishes a SIP session between the prepaid user and the top-up server (5), (6). The top-up server plays an announcement and prompts the user to enter a credit card number and the amount of money to be used to replenish the account (7). The top-up server validates the credit card number, replenishes the user's account (using some means outside the scope of this specification), and releases the SIP session (8). The SIP controller can now assume that communication between the prepaid user and the top-up server took place. It sends a spontaneous Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server to check whether the account has been replenished (9). The Diameter Credit-Control server reserves credit from the end user's account and returns the reserved quota to the SIP controller in the Credit-Control-Answer (10). At this point, the SIP controller reconnects the caller and the called party (11), (12).
A.8. Flow VIII
Figure 18 provides an example of graceful service termination initiated when the first interrogation takes place because the user's account is empty. In this example, the credit-control server supports the server-initiated credit re-authorization. The Diameter protocol application is implemented in the NAS per [RFC7155]. NAS Top-Up CC End User (CC Client) AAA Server Server Server |(1)User Logon |(2)AA-Request (CC AVPs) | | |------------------>|------------------->| | | | | |(3)CCR(Initial, CC AVPs) | | |------------------->| | | |(4)CCA(Final-Unit, | | | | Validity-Time)| | | |<-------------------| | |(5)AA-Answer(Final-Unit, Validity-Time) | |(6)Limited access |<-------------------| | | | granted | | | | |<----------------->| | | | | | | | | | (7)TCP/HTTP | (8)TCP/HTTP | | |<----------------->|<----------------------------->| | | (9)Replenish account | | |<------------------------------------------------->| | | | | (10)RAR | | |<-------------------|<-------------------| | |(11)RAA | | | |------------------->|------------------->| | |(12)CCR(Update) | | | |------------------->|(13)CCR(Update) | | | |------------------->| | | |(14)CCA(Granted-Units) | |(15)CCA(Granted-Units)<------------------| | |<-------------------| | Figure 18: Flow VIII The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server (2). The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, as usual [RFC7155]. The home Diameter AAA server performs service- specific authentication and authorization, as usual. The home Diameter AAA server determines that the user has a prepaid subscription and notices from the Credit-Control AVP that the NAS has credit-control capabilities. It sends a Diameter Credit-Control-
Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service-specific AVPs received from the NAS as input for the rating process.) The Diameter Credit-Control server checks the end user's account balance, determines that the account cannot cover the cost of the service, and initiates graceful service termination. The Credit-Control-Answer is returned to the home Diameter AAA server (4). This message contains the Final-Unit-Indication AVP and the Validity-Time AVP set to a reasonable amount of time, to give the user a chance to replenish their account (e.g., 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to URL, and the Redirect- Server-Address set to the HTTP top-up server name. The home Diameter AAA server sends the received Credit-Control AVPs to the NAS in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts the credit-control session and immediately starts graceful service termination, as instructed by the server. The NAS grants limited access to the user (6). The HTTP client software running in the user's device opens the transport connection redirected by the NAS to the top-up server (7), (8). An appropriate web page is provided for the user where the user can enter the credit card number and the amount of money to be used to replenish the account, along with a notification message that they are granted unlimited access if the replenishment operation will be successfully executed within, for example, the next 10 minutes. The top-up server validates the credit card number and replenishes the user's account (using some means outside the scope of this specification) (9). After successful account top-up, the credit-control server sends a Re-Auth-Request message to the NAS (10). The NAS acknowledges the request by returning the Re-Auth-Answer message (11) and initiates the credit re-authorization by sending a Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (12), (13). The Diameter Credit-Control server reserves credit from the end user's account and returns the reserved quota to the NAS via the home Diameter AAA server in the Credit-Control-Answer (14), (15). The NAS removes the restriction applied by graceful service termination and starts monitoring the granted units.A.9. Flow IX
The Diameter Credit-Control application defines the Multiple- Services-Credit-Control AVP, which can be used to support independent credit-control of multiple services in a single credit-control (sub-)session for Service Elements that have such capabilities. It is possible to request and allocate resources as a credit pool that is shared between services or rating-groups.
Figure 19 illustrates a usage scenario where the credit-control client and server support independent credit-control of multiple services, as defined in Section 5.1.2. It is assumed that service- identifiers, rating-groups, and their associated parameters (e.g., IP 5-tuples) are locally configured in the Service Element or provisioned by an entity other than the credit-control server. End User Service Element CC Server (CC Client) |(1)User logon | | |------------------>|(2)CCR(Initial, Service-Id access, | | | Access-specific AVPs, | | | Multiple-Services-Indicator) | | |------------------------------------------->| | |(3)CCA(Multiple-Services-CC ( | | | Granted-Units(Total-Octets), | | | Service-Id access, | | | Validity-Time, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 10))) | | |<-------------------------------------------| : : : |(4)Service-Request (Service 1) | |------------------>|(5)CCR(Update, Multiple-Services-CC ( | | | Requested-Units(), Service-Id 1, | | | Rating-Group 1)) | | |------------------------------------------->| | |(6)CCA(Multiple-Services-CC ( | | | Granted-Units(Time), | | | Rating-Group 1, | | | G-S-U-Pool-Reference(Pool-Id 1, | | | Multiplier 1))) | | |<-------------------------------------------| : : : |(7)Service-Request (Service 2) | |------------------>| | : : : : : : |(8)Service-Request (Services 3 & 4) | |------------------>|(9)CCR(Update, Multiple-Services-CC ( | | | Requested-Units(), Service-Id 3, | | | Rating-Group 2), | | | Multiple-Services-CC ( | | | Requested-Units(), Service-Id 4, | | | Rating-Group 3)) | | |------------------------------------------->|
| |(10)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 3, Rating-Group 2, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 2)), |
| | Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 4, Rating-Group 3 |
| | Validity-Time, |
| | Final-Unit-Ind.(Terminate), |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 5))) |
| |<-------------------------------------------|
: : :
: : :
| +--------------+ | |
| |Validity time | |(11)CCR(Update, |
| |expires for | | Multiple-Services-CC ( |
| |Service-Id | | Requested-Unit(), |
| | access | | Used-Units(In-Octets, Out-Octets), |
| +--------------+ | Service-Id access)) |
| |------------------------------------------->|
| |(12)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<-------------------------------------------|
: : :
: : :
| +--------------+ | |
| |Total quota | |(13)CCR(Update, |
| |elapses for | | Multiple-Services-CC ( |
| |Pool 2: | | Requested-Unit(), |
| |Service 4 not | | Used-Units(In-Octets, Out-Octets),|
| |allowed, | | Service-Id 3, Rating-Group 2), |
| |Service 3 | | Multiple-Services-CC ( |
| |continues | | Used-Units(In-Octets, Out-Octets),|
| +--------------+ | Service-Id 4, Rating-Group 3)) |
| |------------------------------------------->|
| |(14)CCA(Multiple-Services-CC ( |
| | Result-Code 4011, |
| | Service-Id 3)) |
| |<-------------------------------------------|
: : :
: : :
|(15)User logoff | | |------------------>|(16)CCR(Term., | | | Multiple-Services-CC ( | | | Used-Units(In-Octets, Out-Octets),| | | Service-Id access), | | | Multiple-Services-CC ( | | | Used-Units(Time), | | | Service-Id 1, Rating-Group 1), | | | Multiple-Services-CC ( | | | Used-Units(Time), | | | Service-Id 2, Rating-Group 1)) | | |------------------------------------------->| | |(17)CCA(Term.) | | |<-------------------------------------------| Figure 19: Flow IX: Example of Independent Credit-Control of Multiple Services in a Credit-Control (Sub-)Session The user logs on to the network (1). The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control server to perform credit authorization for the bearer service (e.g., Internet access service) and to establish a credit-control session (2). In this message, the credit-control client indicates support for independent credit-control of multiple services within the session by including the Multiple-Services-Indicator AVP. The Diameter Credit-Control server checks the end user's account balance, with rating information received from the client (i.e., Service-Id and access-specific AVPs); rates the request; and reserves credit from the end user's account. Suppose that the server reserves $5 and determines that the cost is $1/MB. It then returns to the Service Element a Credit-Control- Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to Pool-Id 1 (3). The user uses service 1 (4). The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server to perform credit authorization for service 1 (5). This message includes the Multiple-Services-Credit- Control AVP to request service units for service 1 that belong to Rating-Group 1. The Diameter Credit-Control server determines that service 1 draws credit resources from the same account as the access service (i.e., pool 1). It rates the request according to Service-Id/rating-group and updates the existing reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $10) and determines that the cost is $0.1/minute. The server authorizes the whole rating-group. It then returns to the Service Element a Credit-Control-Answer message that
includes the Multiple-Services-Credit-Control AVP with a quota of 50 minutes associated to Rating-Group 1, to a multiplier value of 1, and to Pool-Id 1 (6). The client adjusts the total amount of resources for pool 1 according to the received quota, which gives S for pool 1 = 100. The user uses service 2, which belongs to the authorized rating-group (Rating-Group 1) (7). Resources are then consumed from pool 1. The user now requests services 3 and 4 as well, which are not authorized (8). The Service Element sends a Diameter Credit-Control- Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit authorization for services 3 and 4 (9). This message includes two instances of the Multiple-Services-Credit-Control AVP to request service units for service 3 that belong to Rating-Group 2 and service units for service 4 that belong to Rating-Group 3. The Diameter Credit-Control server determines that services 3 and 4 draw credit resources from another account (i.e., pool 2). It checks the end user's account balance and, according to Service-Id/rating-group information, rates the request. It then reserves credit from pool 2. For example, the server reserves $5 and determines that service 3 costs $0.2/MB and service 4 costs $0.5/MB. The server authorizes only services 3 and 4. It returns to the Service Element a Credit-Control-Answer message that includes two instances of the Multiple-Services-Credit-Control AVP (10). One instance grants a quota of 12.5 MB associated to Service-Id 3 to a multiplier value of 2 and to Pool-Id 2. The other instance grants a quota of 5 MB associated to Service-Id 4 to a multiplier value of 5 and to Pool-Id 2. The server also determines that pool 2 is exhausted and service 4 is not allowed to continue after these units will be consumed. Therefore, the Final-Unit-Indication AVP with action TERMINATE is associated to Service-Id 4. The client calculates the total amount of resources that can be used for pool 2 according to the received quotas and multipliers, which gives S for pool 2 = 50. The Validity-Time for the access service expires. The Service Element sends a Credit-Control-Request message to the server in order to perform credit re-authorization for the Service-Id (access) (11). This message carries one instance of the Multiple-Services-Credit- Control AVP that includes the units used by this service. Suppose that the total amount of used units is 4 MB. The client adjusts the total amount of resources for pool 1 accordingly, which gives S for pool 1 = 60.
The server deducts $4 from the user's account and updates the reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $11) and already knows the cost of the Service-Id (access), which is $1/MB. It then returns to the Service Element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to Pool-Id 1 (12). The client adjusts the total amount of resources for pool 1 according to the received quota, which gives S for pool 1 = 110. Services 3 and 4 consume the total amount of pool 2's credit resources (i.e., C1*2 + C2*5 >= S). The Service Element immediately starts the TERMINATE action for service 4 and sends a Credit-Control- Request message with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit re-authorization for service 3 (13). This message contains two instances of the Multiple- Services-Credit-Control AVP to report the units used by services 3 and 4. The server deducts the last $5 from the user's account (pool 2) and returns the answer with Result-Code 4011 in the Multiple-Services-Credit-Control AVP to indicate that service 3 can continue without credit-control (14). The end user logs off from the network (15). To debit the used units from the end user's account and to stop the credit-control session, the Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the credit-control server (16). This message contains the units used by each service in multiple instances of the Multiple-Services-Credit-Control AVP. The used units are associated with the relevant Service-Identifier and rating-group. The Diameter Credit-Control server debits the used units to the user's account (pool 1) and acknowledges the session termination by sending a Diameter Credit-Control-Answer to the Service Element (17).
Acknowledgements
The original authors of RFC 4006 are Harri Hakala, Leena Mattila, Juha-Pekka Koskinen, Marco Stura, and John Loughney. The authors would like to thank Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Jussi Maki, Paco Marin, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions.Authors' Addresses
Lyle Bertz (editor) Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States of America Email: lyleb551144@gmail.com David Dolson (editor) Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada Email: ddolson@acm.org Yuval Lifshitz (editor) Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada Email: yuvalif@yahoo.com