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 3 of 9 – Pages 17 to 34
First   Prev   Next

Top   ToC   Page 17   prevText
5.  Session-Based Credit-Control

5.1.  General Principles

   For session-based credit-control, several interrogations are needed:
   the first, the intermediate (optional), and the final.  This is
   illustrated in Figures 3 and 4 (Sections 5.2.1 and 5.2.2).

   If the credit-control client performs credit reservation before
   granting service to the end user, it MUST use several interrogations
   toward the credit-control server (i.e., session-based
   credit-control).  In this case, the credit-control server MUST
   maintain the credit-control session state.

   Each credit-control session MUST have a globally unique Session-Id as
   defined in [RFC6733]; this Session-Id MUST NOT be changed during the
   lifetime of a credit-control session.

   Certain applications require multiple credit-control sub-sessions.
   These applications would send messages with a constant Session-Id AVP
   but with a different CC-Sub-Session-Id AVP.  If several credit
   sub-sessions will be used, all sub-sessions MUST be closed separately
   before the main session is closed so that units per sub-session may
   be reported.  The absence of the CC-Sub-Session-Id AVP implies that
   no sub-sessions are in use.
Top   ToC   Page 18
   Note that the Service Element might send a service-specific
   re-authorization message to the AAA server due to expiration of the
   authorization lifetime during an ongoing credit-control session.
   However, the service-specific re-authorization does not influence the
   credit authorization that is ongoing between the credit-control
   client and credit-control server, as credit authorization is
   controlled by the burning rate of the granted quota.

   If service-specific re-authorization fails, the user will be
   disconnected, and the credit-control client MUST send a final
   interrogation to the credit-control server.

   The Diameter Credit-Control server may seek to control the validity
   time of the granted quota and/or the production of intermediate
   interrogations.  Thus, it MAY include the Validity-Time AVP in the
   Answer message to the credit-control client.  Upon expiration of the
   Validity-Time, the credit-control client MUST generate a
   credit-control update request and report the used quota to the
   credit-control server.  It is up to the credit-control server to
   determine the value of the Validity-Time to be used for consumption
   of the granted service unit(s) (G-S-U).  If the Validity-Time is
   used, its value SHOULD be given as input to set the session
   supervision timer Tcc (the session supervision timer MAY be set to
   two times the value of the Validity-Time, as defined in Section 13).
   Since credit-control update requests are also produced at the expiry
   of granted service units and/or for mid-session service events, the
   omission of Validity-Time does not mean that intermediate
   interrogation for the purpose of credit-control is not performed.

5.1.1.  Basic Support for Tariff Time Change

   The Diameter Credit-Control server and client MAY optionally support
   a tariff change mechanism.  The Diameter Credit-Control server may
   include a Tariff-Time-Change AVP in the Answer message.  Note that
   the granted units should be allocated based on the worst-case
   scenario, so that the overall reported used units would never exceed
   the credit reservation.  For example, in the case of a forthcoming
   tariff change, in which the new rate is higher, the allocation should
   be given so it does not exceed the credit, assuming that all of it is
   used after the tariff changed.

   When the Diameter Credit-Control client reports the used units and a
   tariff change has occurred during the reporting period, the Diameter
   Credit-Control client MUST separately itemize the units used before
   and after the tariff change.  If the client is unable to distinguish
   whether units straddling the tariff change were used before or after
   the tariff change, the credit-control client MUST itemize those units
   in a third category.
Top   ToC   Page 19
   If a client does not support the tariff change mechanism and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit-control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.

   For time-based services, the quota is consumed at the rate of the
   passage of real time (ignoring leap seconds).  That is, precisely
   1 second of quota is consumed per second of real time.  At the time
   when credit resources are allocated, the server already knows how
   many units will be consumed before the tariff time change and how
   many units will be consumed afterward.  Similarly, the server can
   determine the units consumed at the "before" rate and the units
   consumed at the "afterward" rate in the event that the end user
   closes the session before the consumption of the allotted quota.
   There is no need for additional traffic between the client and server
   in the case of tariff time changes for continuous time-based service.
   Therefore, the tariff change mechanism is not used for such services.
   For time-based services in which the quota is NOT continuously
   consumed at a regular rate, the tariff change mechanism described for
   volume and event units MAY be used.

5.1.2.  Credit-Control for Multiple Services within a (Sub-)Session

   When multiple services are used within the same user session and each
   service or group of services is subject to different cost, it is
   necessary to perform credit-control for each service independently.
   Making use of credit-control sub-sessions to achieve independent
   credit-control will result in increased signaling load and usage of
   resources in both the credit-control client and the credit-control
   server.  For instance, during one network access session, the
   end user may use several HTTP-based services that could be charged
   with different costs.  The network-access-specific attributes, such
   as Quality of Service (QoS), are common to all the services carried
   within the access bearer, but the cost of the bearer may vary,
   depending on its content.

   To support these scenarios optimally, the credit-control application
   enables independent credit-control of multiple services in a single
   credit-control (sub-)session.  This is achieved by including the
   optional Multiple-Services-Credit-Control AVP in Credit-Control-
   Request/Credit-Control-Answer messages.  It is possible to request
   and allocate resources as a credit pool shared between multiple
   services.  The services can be grouped into rating-groups in order to
   achieve even further aggregation of credit allocation.  It is also
   possible to request and allocate quotas on a per-service basis.
   Where quotas are allocated to a pool by means of the Multiple-
   Services-Credit-Control AVP, the quotas remain independent objects
Top   ToC   Page 20
   that can be re-authorized independently at any time.  Quotas can also
   be given independent result codes, validity times, and Final-Unit-
   Indication AVP values or QoS-Final-Unit-Indication AVP values.

   A rating-group gathers a set of services, identified by a Service-
   Identifier and subject to the same cost and rating type (e.g.,
   $0.1/minute).  It is assumed that the Service Element is provided
   with rating-groups, service-identifiers, and their associated
   parameters that define what has to be metered by means outside the
   scope of this specification.  (Examples of parameters associated to
   service-identifiers are IP 5-tuples and HTTP URLs.)  Service-
   identifiers enable authorization on a per-service-based credit as
   well as itemized reporting of service usage.  It is up to the
   credit-control server whether to authorize credit for one or more
   services or for the whole rating-group.  However, the client SHOULD
   always report used units at the finest supported level of
   granularity.  Where a quota is allocated to a rating-group, all the
   services belonging to that group draw from the allotted quota.
   Figure 2 provides a graphical representation of the relationship
   between service-identifiers, rating-groups, credit pools, and
   credit-control (sub-)sessions.

                  Diameter Credit-Control (Sub-)Session
                                  |
         +------------+-----------+-------------+--------------- +
         |            |           |             |                |
   Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
         \        /                 \         /                /
          \      /                   \       /                /
           \    /                  Rating-Group 1.......Rating-Group n
            \  /                         |                    |
           Quota       ---------------Quota                 Quota
             |        /                                       |
             |       /                                        |
          Credit Pool                                    Credit Pool

             Figure 2: Multiple-Service (Sub-)Session Example

   If independent credit-control of multiple services is used, the
   Validity-Time AVP, and the Final-Unit-Indication AVP or
   QoS-Final-Unit-Indication AVP, SHOULD be present either in the
   Multiple-Services-Credit-Control AVP(s) or at the command level as
   single AVPs.  However, the Result-Code AVP MAY be present both at the
   command level and within the Multiple-Services-Credit-Control AVP.
   If the Result-Code AVP at the command level indicates a value other
   than SUCCESS, then the Result-Code AVP at the command level takes
   precedence over any other AVPs included in the Multiple-Services-
   Credit-Control AVP.
Top   ToC   Page 21
   The credit-control client MUST indicate support for independent
   credit-control of multiple services within a (sub-)session by
   including the Multiple-Services-Indicator AVP in the first
   interrogation.  A credit-control server not supporting this feature
   MUST treat the Multiple-Services-Indicator AVP and any received
   Multiple-Services-Credit-Control AVPs as invalid AVPs.

   If the client indicated support for independent credit-control of
   multiple services, a credit-control server that wishes to use the
   feature MUST return the granted units within the Multiple-Services-
   Credit-Control AVP associated to the corresponding service-identifier
   and/or rating-group.

   To avoid a situation where several parallel (and typically also
   small) credit reservations must be made on the same account (i.e.,
   credit fragmentation), and also to avoid unnecessary load on the
   credit-control server, it is possible to provide service units as a
   pool that applies to multiple services or rating-groups.  This is
   achieved by providing the service units in the form of a quota for a
   particular service or rating-group in the Multiple-Services-Credit-
   Control AVP, and also by including a reference to a credit pool for
   that unit type.

   The reference includes a multiplier derived from the rating
   parameter, which translates from service units of a specific type to
   the abstract service units in the pool.  For instance, if the rating
   parameter for service 1 is $1/MB and the rating parameter for
   service 2 is $0.5/MB, the multipliers could be 10 and 5 for
   services 1 and 2, respectively.

   If (1) S is the total service units within the pool, (2) M1, M2, ...,
   Mn are the multipliers provided for services 1, 2, ..., n, and
   (3) C1, C2, ..., Cn are the used resources within the session, then
   the pool's credit is exhausted and re-authorization MUST be sought
   when:

            C1*M1 + C2*M2 + ... + Cn*Mn >= S

   The total credit in the pool, S, is calculated from the quotas, which
   are currently allocated to the pool as follows:

            S = Q1*M1 + Q2*M2 + ... + Qn*Mn

   If services or rating-groups are added to or removed from the pool,
   then the total credit is adjusted appropriately.  Note that when the
   total credit is adjusted because services or rating-groups are
   removed from the pool, the value that needs to be removed is the
   consumed one (i.e., Cx*Mx).
Top   ToC   Page 22
   Re-authorizations for an individual service or rating-group may be
   sought at any time -- for example, if a "non-pooled" quota is used up
   or the Validity-Time expires.

   Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same
   G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit-
   Control AVP (Section 8.16) along with the Granted-Service-Unit AVP,
   these AVPs MUST have different CC-Unit-Type values, and they all draw
   from the credit pool separately.  For instance, if one multiplier for
   time (M1t) and one multiplier for volume (M1v) are given, then the
   used resources from the pool yield the sum of C1t*M1t + C1v*M1v,
   where C1t is the time unit and C1v is the volume unit.

   Where service units are provided within a Multiple-Services-Credit-
   Control AVP without a corresponding G-S-U-Pool-Reference AVP, these
   units are handled independently from any credit pools and from any
   other services or rating-groups within the session.

   The "credit pool" concept is an optimal tool to avoid the
   over-reservation effect of the basic single-quota tariff time change
   mechanism (Section 5.1.1).  Therefore, Diameter Credit-Control
   clients and servers implementing the independent credit-control of
   multiple services SHOULD leverage the credit pool concept when
   supporting the tariff time change.  The Diameter Credit-Control
   server SHOULD include both the Tariff-Time-Change AVP and the
   Tariff-Change-Usage AVP in two quota allocations in the Answer
   message (i.e., two instances of the Multiple-Services-Credit-Control
   AVP).  One of the grants is allocated to be used before the potential
   tariff change, while the second grant is for use after a tariff
   change.  Both granted unit quotas MUST contain the same Service-
   Identifier and/or rating-group.  This dual-quota mechanism ensures
   that the overall reported used units would never exceed the credit
   reservation.  The Diameter Credit-Control client reports the used
   units both before and after the tariff change in a single instance of
   the Multiple-Services-Credit-Control AVP.

   Failure handling for credit-control sessions is defined in
   Section 5.7 and reflected in the basic credit-control state machines
   defined in Section 7.  Credit-control clients and servers
   implementing the functionality of independent credit-control of
   multiple services in a (sub-)session MUST ensure failure handling and
   general behavior fully consistent with Sections 5.7 and 7 while
   maintaining the ability to handle parallel ongoing credit
   re-authorization within a (sub-)session.  Therefore, it is
   RECOMMENDED that Diameter Credit-Control clients maintain a PendingU
   message queue (Section 7) and restart the Tx timer (Section 13) every
   time a CCR message with the value UPDATE_REQUEST is sent while they
   are in PendingU state.  When answers to all pending messages are
Top   ToC   Page 23
   received, the state machine moves to Open state, and the Tx timer is
   stopped.  Naturally, when a problem is detected and acted upon per
   Section 5.7, all of the ongoing services are affected (e.g., failover
   to a backup server affects all of the CCR messages in the PendingU
   queue).

   Since the client may send CCR messages with the value UPDATE_REQUEST
   while in PendingU state (i.e., without waiting for an answer to
   ongoing credit re-authorization), the time space between these
   requests may be very short, and the server may not have received the
   previous request(s) yet.  Therefore, in this situation the server may
   receive out-of-sequence requests and SHOULD NOT consider this an
   error condition.  A proper answer is to be returned to each of those
   requests.

5.2.  First Interrogation

   When session-based credit-control is required (e.g., the
   authentication server indicated a prepaid user), the first
   interrogation MUST be sent before the Diameter Credit-Control client
   allows any service events for the end user.  The CC-Request-Type AVP
   is set to the value INITIAL_REQUEST in the request message.

   If the Diameter Credit-Control client knows the cost of the service
   event (e.g., a content server delivering ringing tones may know their
   cost) the monetary amount to be charged is included in the Requested-
   Service-Unit AVP.  If the Diameter Credit-Control client does not
   know the cost of the service event, the Requested-Service-Unit AVP
   MAY contain the number of requested service events.  Where the
   Multiple-Services-Credit-Control AVP is used, it MUST contain the
   Requested-Service-Unit AVP to indicate that the quota for the
   associated service/rating-group is requested.  In the case of
   multiple services, the Service-Identifier AVP or the Rating-Group AVP
   within the Multiple-Services-Credit-Control AVP always indicates the
   service concerned.  Additional service event information to be rated
   MAY be sent as service-specific AVPs or MAY be sent within the
   Service-Parameter-Info AVP at the command level.  The
   Service-Context-Id AVP indicates the service-specific document
   applicable to the request.

   The Event-Timestamp AVP SHOULD be included in the request and
   contains the time when the service event is requested in the Service
   Element.  The Subscription-Id AVP or the Subscription-Id-Extension
   AVP SHOULD be included to identify the end user in the credit-control
   server.  The credit-control client MAY include the User-Equipment-
   Info AVP or User-Equipment-Info-Extension AVP so that the
Top   ToC   Page 24
   credit-control server has some indication of the type and
   capabilities of the end-user access device.  How the credit-control
   server uses this information is outside the scope of this document.

   The credit-control server SHOULD rate the service event and make a
   credit reservation from the end user's account that covers the cost
   of the service event.  If the type of the Requested-Service-Unit AVP
   is "money", no rating is needed, but the corresponding monetary
   amount is reserved from the end user's account.

   The credit-control server returns the Granted-Service-Unit AVP in the
   Answer message to the Diameter Credit-Control client.  The Granted-
   Service-Unit AVP contains the amount of service units that the
   Diameter Credit-Control client can provide to the end user until a
   new Credit-Control-Request MUST be sent to the credit-control server.
   If several unit types are sent in the Answer message, the
   credit-control client MUST handle each unit type separately.  The
   type of the Granted-Service-Unit AVP can be time, volume, service-
   specific, or money, depending on the type of service event.  The unit
   type(s) SHOULD NOT be changed within an ongoing credit-control
   session.

   There MUST be a maximum of one instance of the same unit type in one
   Answer message.  However, if multiple quotas are conveyed to the
   credit-control client in the Multiple-Services-Credit-Control AVPs,
   it is possible to carry two instances of the same unit type
   associated to a service-identifier/rating-group.  This is typically
   the case when a tariff time change is expected and the credit-control
   server wants to make a distinction between the granted quota before
   the tariff change and the granted quota after the tariff change.

   If the credit-control server determines that no further control is
   needed for the service, it MAY include the result code indicating
   that the credit-control is not applicable (e.g., if the service is
   free of charge).  This result code, at the command level, implies
   that the credit-control session is to be terminated.

   The Credit-Control-Answer message MAY also include the Final-Unit-
   Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
   the Answer message contains the final units for the service.  After
   the end user has consumed these units, the Diameter Credit-Control
   client MUST behave as described in Section 5.6.

   This document defines two different approaches for performing the
   first interrogation to be used in different network architectures.
   The first approach uses credit-control messages after the user's
   authorization and authentication take place.  The second approach
   uses (1) service-specific authorization messages to perform the first
Top   ToC   Page 25
   interrogation during the user's authorization/authentication phase
   and (2) credit-control messages for the intermediate and final
   interrogations.  If an implementation of the credit-control client
   supports both methods, determining which method to use SHOULD be
   configurable.

   In service environments such as NAS environments, it is desired to
   perform the first interrogation as part of the authorization/
   authentication process for the sake of protocol efficiency.  Further
   credit authorizations after the first interrogation are performed
   with credit-control commands defined in this specification.
   Implementations of credit-control clients operating in the
   environments mentioned in this document SHOULD support this method.
   If the credit-control server and AAA server are separate physical
   entities, the Service Element sends the request messages to the AAA
   server, which then issues an appropriate request or proxies the
   received request forward to the credit-control server.

   In other service environments, such as the 3GPP network and some SIP
   scenarios, there is a substantial decoupling between registration/
   access to the network and the actual service request (i.e., the
   authentication/authorization is executed once during registration/
   access to the network and is not executed for every service event
   requested by the subscriber).  In these environments, it is more
   appropriate to perform the first interrogation after the user has
   been authenticated and authorized.  The first, intermediate, and
   final interrogations are executed with credit-control commands
   defined in this specification.

   Other IETF standards or standards developed by other standardization
   bodies may define the most suitable method in their architectures.

5.2.1.  First Interrogation after Authorization and Authentication

   The Diameter Credit-Control client in the Service Element may get
   information from the authorization server as to whether
   credit-control is required, based on its knowledge of the end user.
   If credit-control is required, the credit-control server needs to be
   contacted prior to initiating service delivery to the end user.  The
   accounting protocol and the credit-control protocol can be used in
   parallel.  The authorization server may also determine whether the
   parallel accounting stream is required.
Top   ToC   Page 26
   Figure 3 illustrates the case where both protocols are used in
   parallel and the Service Element sends credit-control messages
   directly to the credit-control server.  More credit-control sequence
   examples are given in Appendix A.

                                          Diameter
   End User      Service Element          AAA Server          CC Server
                    (CC Client)
     | Registration      | AA-Request/Answer(accounting, CC, or both)|
     |<----------------->|<------------------>|                      |
     |        :          |                    |                      |
     |        :          |                    |                      |
     | Service Request   |                    |                      |
     |------------------>|                    |                      |
     |                   | CCR(Initial, Credit-Control AVPs)         |
     |                  +|------------------------------------------>|
     |         CC stream||                    |    CCA(Granted-Units)|
     |                  +|<------------------------------------------|
     | Service Delivery  |                    |                      |
     |<----------------->| ACR(start, Accounting AVPs)               |
     |         :         |------------------->|+                     |
     |         :         |                ACA ||  Accounting stream  |
     |                   |<-------------------|+                     |
     |         :         |                    |                      |
     |         :         |                    |                      |
     |                   | CCR(Update, Used-Units)                   |
     |                   |------------------------------------------>|
     |                   |                    |    CCA(Granted-Units)|
     |                   |<------------------------------------------|
     |         :         |                    |                      |
     |         :         |                    |                      |
     | End of Service    |                    |                      |
     |------------------>| CCR(Termination, Used-Units)              |
     |                   |------------------------------------------>|
     |                   |                    |                 CCA  |
     |                   |<------------------------------------------|
     |                   | ACR(stop)          |                      |
     |                   |------------------->|                      |
     |                   |                ACA |                      |
     |                   |<-------------------|                      |

     ACR: Accounting-Request
     ACA: Accounting-Answer

            Figure 3: Protocol Example with First Interrogation
                 after User's Authorization/Authentication
Top   ToC   Page 27
5.2.2.  First Interrogation Included with Authorization Messages

   The Diameter Credit-Control client in the Service Element MUST
   actively co-operate with the authorization/authentication client in
   the construction of the AA-Request by adding appropriate
   Credit-Control AVPs.  The credit-control client MUST add the
   Credit-Control AVP to indicate credit-control capabilities and MAY
   add other relevant credit-control-specific AVPs to the proper
   authorization/authentication command to perform the first
   interrogation toward the home Diameter AAA server.  The
   Auth-Application-Id is set to the appropriate value, as defined in
   service-specific authorization/authentication application document
   (e.g., [RFC7155] [RFC4004]).  The home Diameter AAA server
   authenticates/authorizes the subscriber and determines whether
   credit-control is required.

   If credit-control is not required for the subscriber, the home
   Diameter AAA server will respond as usual, with an appropriate
   AA-Answer message.  If credit-control is required for the subscriber
   and the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION
   was present in the authorization request, the home AAA server MUST
   contact the credit-control server to perform the first interrogation.
   If credit-control is required for the subscriber and the
   Credit-Control AVP was not present in the authorization request, the
   home AAA server MUST send an authorization reject Answer message.

   The Diameter AAA server supporting credit-control is required to send
   the Credit-Control-Request command (CCR) defined in this document to
   the credit-control server.  The Diameter AAA server populates the CCR
   based on service-specific AVPs used for input to the rating process,
   and possibly on Credit-Control AVPs received in the AA-Request.  The
   credit-control server will reserve money from the user's account,
   will rate the request, and will send a Credit-Control-Answer message
   to the home Diameter AAA server.  The Answer message includes the
   Granted-Service-Unit AVP(s) and MAY include other credit-control-
   specific AVPs, as appropriate.  Additionally, the credit-control
   server MAY set the Validity-Time and MAY include the CCFH and the
   DDFH to determine what to do if the sending of credit-control
   messages to the credit-control server has been temporarily prevented.

   Upon receiving the Credit-Control-Answer message from the
   credit-control server, the home Diameter AAA server will populate the
   AA-Answer with the received Credit-Control AVPs and with the
   appropriate service attributes according to the authorization/
   authentication-specific application (e.g., [RFC7155] [RFC4004]).  It
   will then forward the packet to the credit-control client.  If the
   home Diameter AAA server receives a credit-control reject message, it
Top   ToC   Page 28
   will simply generate an appropriate authorization reject message to
   the credit-control client, including the credit-control-specific
   error code.

   In this model, the credit-control client sends further credit-control
   messages to the credit-control server via the home Diameter AAA
   server.  Upon receiving a successful authorization Answer message
   with the Granted-Service-Unit AVP(s), the credit-control client will
   grant the service to the end user and will generate an intermediate
   Credit-Control-Request, if required, by using credit-control
   commands.  The CC-Request-Number of the first UPDATE_REQUEST MUST be
   set to 1 (for details regarding how to produce a unique value for the
   CC-Request-Number AVP, see Section 8.2).

   If service-specific re-authorization is performed (i.e., the
   authorization lifetime expires), the credit-control client MUST add
   to the service-specific re-authorization request the Credit-Control
   AVP with a value set to RE_AUTHORIZATION to indicate that the
   credit-control server MUST NOT be contacted.  When session-based
   credit-control is used for the subscriber, a constant credit-control
   message stream flows through the home Diameter AAA server.  The home
   Diameter AAA server can make use of this credit-control message flow
   to deduce that the user's activity is ongoing; therefore, it is
   recommended to set the authorization lifetime to a reasonably high
   value when credit-control is used for the subscriber.

   In this scenario, the home Diameter AAA server MUST advertise support
   for the credit-control application to its peers during the capability
   exchange process.
Top   ToC   Page 29
   Figure 4 illustrates the use of authorization/authentication messages
   to perform the first interrogation.  The parallel accounting stream
   is not shown in the figure.

                                            Diameter
                  Service Element           AAA Server        CC Server
   End User          (CC Client)
    | Service Request   | AA-Request (CC AVPs) |                     |
    |------------------>|--------------------->|                     |
    |                   |                      | CCR(Initial, CC AVPs)
    |                   |                      |-------------------->|
    |                   |                      |   CCA(Granted-Units)|
    |                   |                      |<--------------------|
    |                   | AA-Answer(Granted-Units)                   |
    | Service Delivery  |<---------------------|                     |
    |<----------------->|                      |                     |
    |         :         |                      |                     |
    |         :         |                      |                     |
    |         :         |                      |                     |
    |                   |                      |                     |
    |                   | CCR(Update, Used-Units)                    |
    |                   |--------------------->| CCR(Update, Used-Units)
    |                   |                      |-------------------->|
    |                   |                      |   CCA(Granted-Units)|
    |                   |    CCA(Granted-Units)|<--------------------|
    |                   |<---------------------|                     |
    |         :         |                      |                     |
    |         :         |                      |                     |
    | End of Service    |                      |                     |
    |------------------>| CCR(Termination, Used-Units)               |
    |                   |--------------------->| CCR(Term., Used-Units)
    |                   |                      |-------------------->|
    |                   |                      |                 CCA |
    |                   |                  CCA |<--------------------|
    |                   |<---------------------|                     |

       Figure 4: Protocol Example with Use of Authorization Messages
                        for the First Interrogation

5.3.  Intermediate Interrogation

   When all the granted service units for one unit type are spent by the
   end user or the Validity-Time has expired, the Diameter
   Credit-Control client MUST send a new Credit-Control-Request to the
   credit-control server.  In the event that credit-control for multiple
   services is applied in one credit-control session (i.e., units
   associated to Service-Identifier(s) or the rating-group are granted),
   a new Credit-Control-Request MUST be sent to the credit-control
Top   ToC   Page 30
   server when the credit reservation has been wholly consumed or upon
   expiration of the Validity-Time.  It is always up to the Diameter
   Credit-Control client to send a new request well in advance of the
   expiration of the previous request in order to avoid interruption in
   the Service Element.  Even if the granted service units reserved by
   the credit-control server have not been spent upon expiration of the
   Validity-Time, the Diameter Credit-Control client MUST send a new
   Credit-Control-Request to the credit-control server.

   There can also be mid-session service events, which might affect the
   rating of the current service events.  In this case, a spontaneous
   update (a new Credit-Control-Request) SHOULD be sent, including
   information related to the service event, even if all the granted
   service units have not been spent or the Validity-Time has not
   expired.

   When the used units are reported to the credit-control server, the
   credit-control client will not have any units in its possession
   before new granted units are received from the credit-control server.
   When the new granted units are received, these units apply from the
   point where the measurement of the reported used units stopped.
   Where independent credit-control of multiple services is supported,
   this process may be executed for one or more services, a single
   rating-group, or a pool within the (sub-)session.

   The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the
   intermediate request message.  The Subscription-Id AVP or
   Subscription-Id-Extension AVP SHOULD be included in the intermediate
   message to identify the end user in the credit-control server.  The
   Service-Context-Id AVP indicates the service-specific document
   applicable to the request.

   The Requested-Service-Unit AVP MAY contain the new amount of
   requested service units.  Where the Multiple-Services-Credit-Control
   AVP is used, it MUST contain the Requested-Service-Unit AVP if a new
   quota is requested for the associated service/rating-group.  The
   Used-Service-Unit AVP contains the amount of used service units
   measured from the point when the service became active or, if interim
   interrogations are used during the session, from the point when the
   previous measurement ended.  The same unit types used in the previous
   message SHOULD be used.  If several unit types were included in the
   previous Answer message, the used service units for each unit type
   MUST be reported.

   The Event-Timestamp AVP SHOULD be included in the request and
   contains the time of the event that triggered the sending of the new
   Credit-Control-Request.
Top   ToC   Page 31
   The credit-control server MUST deduct the used amount from the
   end user's account.  It MAY rate the new request and make a new
   credit reservation from the end user's account that covers the cost
   of the requested service event.

   A Credit-Control-Answer message with the CC-Request-Type AVP set to
   the value UPDATE_REQUEST MAY include the Cost-Information AVP
   containing the accumulated cost estimation for the session, without
   taking any credit reservations into account.

   The Credit-Control-Answer message MAY also include the Final-Unit-
   Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
   the Answer message contains the final units for the service.  After
   the end user has consumed these units, the Diameter Credit-Control
   client MUST behave as described in Section 5.6.

   There can be several intermediate interrogations within a session.

5.4.  Final Interrogation

   When the end user terminates the service session or when graceful
   service termination (described in Section 5.6) takes place, the
   Diameter Credit-Control client MUST send a final Credit-Control-
   Request message to the credit-control server.  The CC-Request-Type
   AVP is set to the value TERMINATION_REQUEST.  The Service-Context-Id
   AVP indicates the service-specific document applicable to the
   request.

   The Event-Timestamp AVP SHOULD be included in the request and
   contains the time when the session was terminated.

   The Used-Service-Unit AVP contains the amount of used service units
   measured from the point when the service became active or, if interim
   interrogations are used during the session, from the point when the
   previous measurement ended.  If several unit types were included in
   the previous Answer message, the used service units for each unit
   type MUST be reported.

   After final interrogation, the credit-control server MUST refund the
   reserved credit amount not used to the end user's account and deduct
   the used monetary amount from the end user's account.

   A Credit-Control-Answer message with the CC-Request-Type AVP set to
   the value TERMINATION_REQUEST MAY include the Cost-Information AVP
   containing the estimated total cost for the session in question.
Top   ToC   Page 32
   If the user logs off during an ongoing credit-control session or if
   the user becomes logged off for some other reason (e.g., a final-unit
   indication causes user logoff according to local policy), the Service
   Element, according to application-specific policy, may send a
   Session-Termination-Request (STR) to the home Diameter AAA server as
   usual [RFC6733].  Figure 5 illustrates the case when the final-unit
   indication causes user logoff upon consumption of the final granted
   units and the generation of an STR.

   The Diameter AAA server responds with a Session-Termination-Answer
   (STA).

                 Service Element         AAA Server         CC Server
   End User        (CC Client)
    | Service Delivery  |                     |                     |
    |<----------------->|                     |                     |
    |         :         |                     |                     |
    |         :         |                     |                     |
    |         :         |                     |                     |
    |                   |                     |                     |
    |                   | CCR(Update, Used-Units)                   |
    |                   |-------------------->| CCR(Update, Used-Units)
    |                   |                     |-------------------->|
    |                   |                   CCA(Final-Unit, Terminate)
    |               CCA(Final-Unit, Terminate)|<--------------------|
    |                   |<--------------------|                     |
    |         :         |                     |                     |
    |         :         |                     |                     |
    |  Disconnect user  |                     |                     |
    |<------------------| CCR(Termination, Used-Units)              |
    |                   |-------------------->| CCR(Term., Used-Units)
    |                   |                     |-------------------->|
    |                   |                     |                 CCA |
    |                   |                 CCA |<--------------------|
    |                   |<--------------------|                     |
    |                   | STR                 |                     |
    |                   |-------------------->|                     |
    |                   |                STA  |                     |
    |                   |<--------------------|                     |

           Figure 5: User Disconnected Due to Exhausted Account

5.5.  Server-Initiated Credit Re-authorization

   The Diameter Credit-Control application supports server-initiated
   re-authorization.  The credit-control server MAY optionally initiate
   the credit re-authorization by issuing a Re-Auth-Request (RAR) as
   defined in the Diameter base protocol [RFC6733].  The
Top   ToC   Page 33
   Auth-Application-Id in the RAR message is set to 4 to indicate
   "Diameter Credit Control", and the Re-Auth-Request-Type is set to
   AUTHORIZE_ONLY.

   Section 5.1.2 defines the feature to enable credit-control for
   multiple services within a single (sub-)session where the server can
   authorize credit usage at a different level of granularity.  Further,
   the server may provide credit resources to multiple services or
   rating-groups as a pool (see Section 5.1.2 for details and
   definitions).  Therefore, the server, based on its service logic and
   its knowledge of the ongoing session, can decide to request credit
   re-authorization for a whole (sub-)session, a single credit pool, a
   single service, or a single rating-group.  To request credit
   re-authorization for a credit pool, the server includes in the RAR
   message the G-S-U-Pool-Identifier AVP indicating the affected pool.
   To request credit re-authorization for a service or a rating-group,
   the server includes in the RAR message the Service-Identifier AVP or
   the Rating-Group AVP, respectively.  To request credit
   re-authorization for all the ongoing services within the
   (sub-)session, the server includes none of the above-mentioned AVPs
   in the RAR message.

   If a credit re-authorization is not already ongoing (i.e., the
   credit-control session is in Open state), a credit-control client
   that receives an RAR message with Session-Id equal to a currently
   active credit-control session MUST acknowledge the request by sending
   the Re-Auth-Answer (RAA) message and MUST initiate the credit
   re-authorization toward the server by sending a Credit-Control-
   Request message with the CC-Request-Type AVP set to the value
   UPDATE_REQUEST.  The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS)
   SHOULD be used in the RAA message to indicate that an additional
   message (i.e., a CCR message with the value UPDATE_REQUEST) is
   required to complete the procedure.  If a quota was allocated to the
   service, the credit-control client MUST report the used quota in the
   Credit-Control-Request.  Note that the end user does not need to be
   prompted for the credit re-authorization, since the credit
   re-authorization is transparent to the user (i.e., it takes place
   exclusively between the credit-control client and the credit-control
   server).

   Where multiple services in a user's session are supported, the
   procedure in the above paragraph will be executed at the granularity
   requested by the server in the RAR message.

   If credit re-authorization is ongoing at the time when the RAR
   message is received (i.e., an RAR-CCR collision), the credit-control
   client successfully acknowledges the request but does not initiate a
   new credit re-authorization.  The Result-Code 2001 (DIAMETER_SUCCESS)
Top   ToC   Page 34
   SHOULD be used in the RAA message to indicate that a credit
   re-authorization procedure is already ongoing (i.e., the client was
   in PendingU state when the RAR was received).  The credit-control
   server SHOULD process the Credit-Control-Request as if it was
   received in answer to the server-initiated credit re-authorization
   and should consider the server-initiated credit re-authorization
   process successful upon reception of the RAA message.

   When multiple services are supported in a user's session, the server
   may request credit re-authorization for a credit pool (or for the
   (sub-)session) while a credit re-authorization is already ongoing for
   some of the services or rating-groups.  In this case, the client
   acknowledges the server request with an RAA message and MUST send a
   new Credit-Control-Request message to perform re-authorization for
   the remaining services/rating-groups.  The Result-Code 2002
   (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to
   indicate that an additional message (i.e., a CCR message with the
   value UPDATE_REQUEST) is required to complete the procedure.  The
   server processes the received requests and returns an appropriate
   answer to both requests.

   The above-defined procedures are enabled for each of the possibly
   active Diameter Credit-Control sub-sessions.  The server MAY request
   re-authorization for an active sub-session by including the
   CC-Sub-Session-Id AVP in the RAR message in addition to the
   Session-Id AVP.



(page 34 continued on part 4)

Next Section