Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: DIME

RFC 8506

Diameter Credit-Control Application

Pages: 130
Proposed STD
Obsoletes:  4006
Part 9 of 9 – Pages 111 to 130
First   Prev   None

Top   ToC   Page 111   prevText
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  |                     |
     |                   |<--------------------|                     |
     :                   :                     :                     :
     :                   :                     :                     :
Top   ToC   Page 112
     |(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
Top   ToC   Page 113
   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.
Top   ToC   Page 114
         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
Top   ToC   Page 115
   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).
Top   ToC   Page 116
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).
Top   ToC   Page 117
   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
Top   ToC   Page 118
   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.
Top   ToC   Page 119
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
Top   ToC   Page 120
   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
Top   ToC   Page 121
   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
Top   ToC   Page 122
   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).
Top   ToC   Page 123
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-
Top   ToC   Page 124
   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.
Top   ToC   Page 125
   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))                    |
     |                   |------------------------------------------->|
Top   ToC   Page 126
     |                   |(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))                     |
     |                   |<-------------------------------------------|
     :                   :                                            :
     :                   :                                            :
Top   ToC   Page 127
     |(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
Top   ToC   Page 128
   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.
Top   ToC   Page 129
   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).
Top   ToC   Page 130
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