tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4006

 
 
 

Diameter Credit-Control Application

Part 3 of 5, p. 41 to 67
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 41 
6.  One Time Event

   The one-time event is used when there is no need to maintain any
   state in the Diameter credit-control server; for example, enquiring
   about the price of the service.  The use of a one-time event implies
   that the user has been authenticated and authorized beforehand.

   The one time event can be used when the credit-control client wants
   to know the cost of the service event or to check the account balance
   without any credit-reservation.  It can also be used for refunding
   service units on the user's account or for direct debiting without
   any credit-reservation.  The one time event is shown in Figure 6.

                                           Diameter
   End User        Service Element        AAA Server        CC Server
                     (CC Client)
      | Service Request   |                    |                    |
      |------------------>|                    |                    |
      |                   | CCR(Event)         |                    |
      |                   |------------------->| CCR(Event)         |
      |                   |                    |------------------->|
      |                   |                    |  CCA(Granted-Units)|
      |                   |  CCA(Granted-Units)|<-------------------|
      |  Service Delivery |<-------------------|                    |
      |<----------------->|                    |                    |

                         Figure 6: One time event

   In environments such as the 3GPP architecture, the one time event can
   be sent from the service element directly to the credit-control
   server.

Top      Up      ToC       Page 42 
6.1.  Service Price Enquiry

   The credit-control client may need to know the price of the service
   event.  Services offered by application service providers whose
   prices are not known in the credit-control client might exist.  The
   end user might also want to get an estimation of the price of a
   service event before requesting it.

   A Diameter credit-control client requesting the cost information MUST
   set the CC-Request-Type AVP equal to EVENT_REQUEST, include the
   Requested-Action AVP set to PRICE_ENQUIRY, and set the requested
   service event information into the Service-Identifier AVP in the
   Credit-Control-Request message.  Additional service event information
   may be sent as service specific AVPs or within the Service-
   Parameter-Info AVP.  The Service-Context-Id AVP indicates the service
   specific document applicable to the request.

   The credit-control server calculates the cost of the requested
   service event, but it does not perform any account balance check or
   credit-reservation from the account.

   The estimated cost of the requested service event is returned to the
   credit-control client in the Cost-Information AVP in the Credit-
   Control-Answer message.

6.2.  Balance Check

   The Diameter credit-control client may only have to verify that the
   end user's account balance covers the cost of a certain service
   without reserving any units from the account at the time of the
   inquiry.  This method does not guarantee that credit would be left
   when the Diameter credit-control client requests the debiting of the
   account with a separate request.

   A Diameter credit-control client requesting the balance check MUST
   set the CC-Request-Type AVP equal to EVENT_REQUEST, include a
   Requested-Action AVP set to CHECK_BALANCE, and include the
   Subscription-Id AVP in order 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 credit-control server makes the balance check, but it does not
   make any credit-reservation from the account.

   The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to
   the credit-control client in the Check-Balance-Result AVP in the
   Credit-Control-Answer message.

Top      Up      ToC       Page 43 
6.3.  Direct Debiting

   There are certain service events for which service execution is
   always successful in the service environment.  The delay between the
   service invocation and the actual service delivery to the end user
   can be sufficiently long that the use of the session-based credit-
   control would lead to unreasonably long credit-control sessions.  In
   these cases, the Diameter credit-control client can use the one-time
   event scenario for direct debiting.  The Diameter credit-control
   client SHOULD be sure that the requested service event execution
   would be successful when this scenario is used.

   In the Credit-Control-Request message, the CC-Request-Type is set to
   the value EVENT_REQUEST and the Requested-Action AVP is set to
   DIRECT_DEBITING.  The Subscription-Id AVP SHOULD be included to
   identify the end user in the credit-control server.  The Event-
   Timestamp AVP SHOULD be included in the request and contain the time
   when the service event is requested in the service element.  The
   Service-Context-Id AVP indicates the service specific document
   applicable to the request.

   The Diameter credit-control client MAY include the monetary amount to
   be charged in the Requested-Service-Unit AVP, if it knows the cost of
   the service event.  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.  The Service-
   Identifier AVP always indicates the service concerned.  Additional
   service event information to be rated MAY be sent as service specific
   AVPs or within the Service-Parameter-Info AVP.

   The credit-control server SHOULD rate the service event and deduct
   the corresponding monetary amount from the end user's account.  If
   the type of the Requested-Service-Unit AVP is money, no rating is
   needed, but the corresponding monetary amount is deducted from the
   end user's account.

   The credit-control server returns the Granted-Service-Unit AVP in the
   Credit-Control-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.
   The type of the Granted-Service-Unit can be time, volume, service
   specific, or money, depending on the type of service event.

   If the credit-control server determines that no credit-control is
   needed for the service, it can include the result code indicating
   that the credit-control is not applicable (e.g., service is free of
   charge).

Top      Up      ToC       Page 44 
   For informative purposes, the Credit-Control-Answer message MAY also
   include the Cost-Information AVP containing the estimated total cost
   of the requested service.

6.4.  Refund

   Some services may refund service units to the end user's account; for
   example, gaming services.

   The credit-control client MUST set CC-Request-Type to the value
   EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the
   Credit-Control-Request message.  The Subscription-Id AVP SHOULD be
   included 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 Diameter credit-control client MAY include the monetary amount to
   be refunded in the Requested-Service-Unit AVP.  The Service-
   Identifier AVP always indicates the concerned service.  If the
   Diameter credit-control client does not know the monetary amount to
   be refunded, in addition to the Service-Identifier AVP it MAY send
   service specific AVPs or the Service-Parameter-Info AVP containing
   additional service event information to be rated.

   For informative purposes, the Credit-Control-Answer message MAY also
   include the Cost-Information AVP containing the estimated monetary
   amount of refunded unit.

6.5.  Failure Procedure

   Failover to an alternative credit-control server is allowed for a one
   time event, as the server is not maintaining session states.  For
   instance, if the credit-control client receives a protocol error
   DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the
   request to an alternative server, if possible.  There MAY be protocol
   transparent Diameter relays and redirect agents or Diameter credit-
   control proxies between the credit-control client and credit-control
   server.  Failover may occur at any point in the path between the
   credit-control client and the credit-control server if a transport
   failure is detected with a peer, as described in [DIAMBASE].  Because
   there can be duplicate requests for various reasons, the credit-
   control server is responsible for real time duplicate detection.
   Implementation issues for duplicate detection are discussed in
   [DIAMBASE], Appendix C.

   When the credit-control client detects a communication failure with
   the credit-control server, its behavior depends on the requested
   action.  The timer Tx (as defined in section 13) is used in the

Top      Up      ToC       Page 45 
   credit-control client to supervise the communication with the
   credit-control server.

   If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and
   communication failure is detected, the credit-control client SHOULD
   forward the request messages to an alternative credit-control server,
   if possible.  The secondary credit-control server name, if received
   from the home Diameter AAA server, can be used as an address of
   backup server.

   If the requested action is DIRECT_DEBITING, the Direct-Debiting-
   Failure-Handling AVP (DDFH) controls the credit-control client's
   behavior.  The DDFH may be received from the home Diameter AAA server
   or may be locally configured.  The credit-control server may also
   send the DDFH in any CCA message to be used for direct debiting
   events compiled thereafter.  The DDFH value received from the home
   Diameter AAA server overrides the locally configured value, and the
   DDFH value received from the credit-control server in a Credit-
   Control-Answer message always overrides any existing value.

   If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client
   SHOULD NOT grant the service if it can determine, eventually after a
   possible re-transmission attempt to an alternative credit-control
   server, from the result code or error code in the answer message that
   units have not been debited.  Otherwise, the credit-control client
   SHOULD grant the service to the end user and store the request in the
   credit-control application level non-volatile storage.  (Note that
   re-sending the request at a later time is not a guarantee that the
   service will be debited, as the user's account may be empty when the
   server successfully processes the request.)  The credit-control
   client MUST mark these request messages as possible duplicates by
   setting the T-flag in the command header as described in [DIAMBASE],
   section 3.

   If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the
   service SHOULD be granted, even if credit-control messages cannot be
   delivered and messages are not buffered.

   If the timer Tx expires, the credit-control client MUST continue the
   service and wait for a possible late answer.  If the request times
   out, the credit-control client re-transmits the request (marked with
   T-flag) to a backup credit-control server, if possible.  If the re-
   transmitted request also times out, or if a temporary error is
   received in answer, the credit-control client buffers the request if
   the value of the Direct-Debiting-Failure-Handling AVP is set to
   TERMINATE_OR_BUFFER.  If a failed answer is received for the

Top      Up      ToC       Page 46 
   re-transmitted request, the credit-control client frees all the
   resources reserved for the event message and deletes the request
   regardless of the value of the DDFH.

   The Credit-Control-Request with the requested action REFUND_ACCOUNT
   should always be stored in the credit-control application level non-
   volatile storage in case of temporary failure.  The credit-control
   client MUST mark the re-transmitted request message as a possible
   duplicate by setting the T-flag in the command header as described in
   [DIAMBASE], section 3.

   For stored requests, the implementation may choose to limit the
   number of re-transmission attempts and to define a re-transmission
   interval.

   Note that only one place in the credit-control system SHOULD be
   responsible for duplicate detection.  If there is only one credit-
   control server within the given realm, the credit-control server may
   perform duplicate detection.  If there is more than one credit-
   control server in a given realm, only one entity in the credit-
   control system should be responsible, to ensure that the end user's
   account is not debited or credited multiple times for the same
   service event.

7.  Credit-Control Application State Machine

   This section defines the credit-control application state machine.

   The first four state machines are to be observed by credit-control
   clients.  The first one describes the session-based credit-control
   when the first interrogation is executed as part of the
   authorization/authentication process.  The second describes the
   session-based credit-control when the first interrogation is executed
   after the authorization/authentication process.  The requirements as
   to what state machines have to be supported are discussed in section
   5.2.

   The third state machine describes the session-based credit-control
   for the intermediate and final interrogations.  The fourth one
   describes the event-based credit-control.  These latter state
   machines are to be observed by all implementations that conform to
   this specification.

   The fifth state machine describes the credit-control session from a
   credit-control server perspective.

Top      Up      ToC       Page 47 
   Any event not listed in the state machines MUST be considered an
   error condition, and a corresponding answer, if applicable, MUST be
   returned to the originator of the message.

   In the state table, the event 'Failure to send' means that the
   Diameter credit-control client is unable to communicate with the
   desired destination or, if failover procedure is supported, with a
   possibly defined alternative destination (e.g., the request times out
   and the answer message is not received).  This could be due to the
   peer being down, or due to a physical link failure in the path to or
   from the credit-control server.

   The event 'Temporary error' means that the Diameter credit-control
   client received a protocol error notification (DIAMETER_TOO_BUSY,
   DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the
   Result-Code AVP of the Credit-Control-Answer command.  The above
   protocol error notification may ultimately be received in answer to
   the re-transmitted request to a defined alternative destination, if
   failover is supported.

   The event 'Failed answer' means that the Diameter credit-control
   client received non-transient failure (permanent failure)
   notification in the Credit-Control-Answer command.  The above
   permanent failure notification may ultimately be received in answer
   to the re-transmitted request to a defined alternative destination,
   if failover is supported.

   The action 'store request' means that a request is stored in the
   credit-control application level non-volatile storage.

   The event 'Not successfully processed' means that the credit-control
   server could not process the message; e.g., due to an unknown end
   user, account being empty, or errors defined in [DIAMBASE].

   The event 'User service terminated' can be triggered by various
   reasons, e.g., normal user termination, network failure, and ASR
   (Abort-Session-Request).  The Termination-Cause AVP contains
   information about the termination reason, as specified in [DIAMBASE].

   The Tx timer, which is used to control the waiting time in the
   credit-control client in the Pending state, is stopped upon exit of
   the Pending state.  The stopping of the Tx timer is omitted in the
   state machine when the new state is Idle, as moving to Idle state
   implies the clearing of the session and all the variables associated
   to it.

Top      Up      ToC       Page 48 
   The states PendingI, PendingU, PendingT, PendingE, and PendingB stand
   for pending states to wait for an answer to a credit-control request
   related to Initial, Update, Termination, Event, or Buffered request,
   respectively.

   The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling
   and Direct-Debiting-Failure-Handling, respectively.

   In the following state machine table, the failover to a secondary
   server upon 'Temporary error' or 'Failure to send' is not explicitly
   described.  Moving an ongoing credit-control message stream to an
   alternative server is, however, possible if the CC-Session-Failover
   AVP is set to FAILOVER_SUPPORTED, as described in section 5.7.

   Re-sending a credit-control event to an alternative server is
   supported as described in section 6.5.

   CLIENT, SESSION BASED for the first interrogation with AA request

    State      Event                         Action       New State
    ---------------------------------------------------------------
    Idle       Client or device requests     Send          PendingI
               access/service                AA request
                                             with added
                                             CC AVPs,
                                             start Tx

    PendingI  Successful AA req.             Grant         Open
              answer received                service to
                                             end user,
                                             stop Tx

    PendingI  Tx expired                     Disconnect    Idle
                                             user/dev

    PendingI  Failed AA answer received      Disconnect    Idle
                                             user/dev

    PendingI  AA answer                      Grant         Idle
              received with result code      service
              equal to CREDIT_CONTROL_       to end user
              NOT_APPLICABLE

    PendingI  User service terminated        Queue         PendingI
                                             termination
                                             event

Top      Up      ToC       Page 49 
    PendingI  Change in rating condition     Queue         PendingI
                                             changed
                                             rating
                                             condition
                                             event

      CLIENT, SESSION BASED for the first interrogation with CCR

    State      Event                          Action       New State
    ----------------------------------------------------------------


    Idle      Client or device requests      Send         PendingI
              access/service                 CC initial
                                             req.,
                                             start Tx

    PendingI  Successful CC initial          Stop Tx      Open
              answer received

    PendingI  Failure to send, or            Grant        Idle
              temporary error and            service to
              CCFH equal to CONTINUE         end user

    PendingI  Failure to send, or            Terminate    Idle
              temporary error and            end user's
              CCFH equal to TERMINATE        service
              or to RETRY_AND_TERMINATE

    PendingI  Tx expired and CCFH            Terminate    Idle
              equal to TERMINATE             end user's
                                             service

    PendingI  Tx expired and CCFH equal      Grant        PendingI
              to CONTINUE or to              service to
              RETRY_AND_TERMINATE            end user

    PendingI  CC initial answer              Terminate    Idle
              received with result code      end user's
              END_USER_SERVICE_DENIED or     service
              USER_UNKNOWN

    PendingI  CC initial answer              Grant        Idle
              received with result code      service
              equal to CREDIT_CONTROL_       to end user
              NOT_APPLICABLE

Top      Up      ToC       Page 50 
    PendingI  Failed CC initial answer       Grant        Idle
              received and CCFH equal to     service to
              CONTINUE                       end user

    PendingI  Failed CC initial answer       Terminate    Idle
              received and CCFH equal        end user's
              to TERMINATE or to             service
              RETRY_AND_TERMINATE

    PendingI  User service terminated        Queue        PendingI
                                             termination
                                             event

    PendingI  Change in rating condition     Queue        PendingI
                                             changed
                                             rating
                                             condition
                                             event

     CLIENT, SESSION BASED for intermediate and final interrogations

    State     Event                          Action       New State
    ----------------------------------------------------------------

    Open      Granted unit elapses           Send         PendingU
              and no final unit              CC update
              indication received            req.,
                                             start Tx

    Open      Granted unit elapses           Terminate    PendingT
              and final unit action          end user's
              equal to TERMINATE             service, send
              received                       CC termination
                                             req.

    Open      Change in rating condition     Send         PendingU
              in queue                       CC update
                                             req.,
                                             Start Tx

    Open      Service terminated in queue    Send         PendingT
                                             CC termination
                                             req.

    Open      Change in rating condition     Send         PendingU
              or Validity-Time elapses       CC update
                                             req.,
                                             Start Tx

Top      Up      ToC       Page 51 
    Open      User service terminated        Send         PendingT
                                             CC termination
                                             req.

    Open      RAR received                   Send RAA     PendingU
                                             followed by
                                             CC update req.,
                                             start Tx

    PendingU  Successful CC update           Stop Tx      Open
              answer received

    PendingU  Failure to send, or            Grant        Idle
              temporary error and            service to
              CCFH equal to CONTINUE         end user

    PendingU  Failure to send, or            Terminate    Idle
              temporary error and            end user's
              CCFH equal to TERMINATE        service
              or to RETRY_AND_TERMINATE

    PendingU  Tx expired and CCFH            Terminate    Idle
              equal to TERMINATE             end user's
                                             service

    PendingU  Tx expired and CCFH equal      Grant        PendingU
              to CONTINUE or to              service to
              RETRY_AND_TERMINATE            end user

    PendingU  CC update answer               Terminate    Idle
              received with result code      end user's
              END_USER_SERVICE_DENIED        service

    PendingU  CC update answer               Grant        Idle
              received with result code      service
              equal to CREDIT_CONTROL_       to end user
              NOT_APPLICABLE

    PendingU  Failed CC update               Grant        Idle
              answer received and            service to
              CCFH equal to CONTINUE         end user

    PendingU  Failed CC update               Terminate    Idle
              answer received and CCFH       end user's
              equal to TERMINATE or          service
              to RETRY_AND_TERMINATE

Top      Up      ToC       Page 52 
    PendingU  User service terminated        Queue        PendingU
                                             termination
                                             event

    PendingU  Change in rating               Queue        PendingU
              condition                      changed
                                             rating
                                             condition
                                             event

    PendingU  RAR received                   Send RAA     PendingU

    PendingT  Successful CC                               Idle
              termination answer received

    PendingT  Failure to send, temporary                  Idle
              error, or failed answer

    PendingT  Change in rating condition                  PendingT

                       CLIENT, EVENT BASED

    State     Event                          Action        New State
    ----------------------------------------------------------------
    Idle      Client or device requests      Send          PendingE
              a one-time service             CC event
                                             req.,
                                             Start Tx

    Idle      Request in storage             Send          PendingB
                                             stored
                                             request

    PendingE  Successful CC event            Grant         Idle
              answer received                service to
                                             end user

    PendingE  Failure to send, temporary     Indicate      Idle
              error, failed CC event         service
              answer received, or            error
              Tx expired; requested
              action CHECK_BALANCE or
              PRICE_ENQUIRY

    PendingE  CC event answer                Terminate     Idle
              received with result code      end user's
              END_USER_SERVICE_DENIED or     service
              USER_UNKNOWN and Tx running

Top      Up      ToC       Page 53 
    PendingE  CC event answer                Grant         Idle
              received with result code      service
              CREDIT_CONTROL_NOT_APPLICABLE; to end
              requested action               user
              DIRECT_DEBITING

    PendingE  Failure to send, temporary     Grant         Idle
              error, or failed CC event      service
              answer received; requested     to end
              action DIRECT_DEBITING;        user
              DDFH equal to CONTINUE

    PendingE  Failed CC event                Terminate     Idle
              answer received or temporary   end user's
              error; requested action        service
              DIRECT_DEBITING;
              DDFH equal to
              TERMINATE_OR_BUFFER and
              Tx running

    PendingE  Tx expired; requested          Grant         PendingE
              action DIRECT_DEBITING         service
                                             to end
                                             user

    PendingE  Failure to send; requested     Store         Idle
              action DIRECT_DEBITING;        request with
              DDFH equal to                  T-flag
              TERMINATE_OR_BUFFER

    PendingE  Temporary error; requested     Store         Idle
              action DIRECT_DEBITING;        request
              DDFH equal to
              TERMINATE_OR_BUFFER;
              Tx expired

    PendingE  Failed answer or answer                      Idle
              received with result code
              END_USER_SERVICE DENIED or
              USER_UNKNOWN; requested action
              DIRECT_DEBITING; Tx expired

    PendingE  Failed CC event answer         Indicate      Idle
              received; requested            service
              action REFUND_ACCOUNT          error and
                                             delete request

Top      Up      ToC       Page 54 
    PendingE  Failure to send or             Store         Idle
              Tx expired; requested          request
              action REFUND_ACCOUNT          with T-flag

    PendingE  Temporary error,               Store         Idle
              and requested action           request
              REFUND_ACCOUNT

    PendingB  Successful CC answer           Delete        Idle
              received                       request

    PendingB  Failed CC answer               Delete        Idle
              received                       request

    PendingB  Failure to send or                           Idle
              temporary error

                   SERVER, SESSION AND EVENT BASED

    State     Event                          Action        New State
    ----------------------------------------------------------------

    Idle      CC initial request             Send          Open
              received and successfully      CC initial
              processed                      answer,
                                             reserve units,
                                             start Tcc

    Idle      CC initial request             Send          Idle
              received but not               CC initial
              successfully processed         answer with
                                             Result-Code
                                             != SUCCESS

    Idle      CC event request               Send          Idle
              received and successfully      CC event
              processed                      answer

    Idle      CC event request               Send          Idle
              received but not               CC event
              successfully processed         answer with
                                             Result-Code
                                             != SUCCESS

Top      Up      ToC       Page 55 
    Open      CC update request              Send CC       Open
              received and successfully      update answer,
              processed                      debit used
                                             units,
                                             reserve
                                             new units,
                                             restart Tcc

    Open      CC update request              Send          Idle
              received but not               CC update
              successfully processed         answer with
                                             Result-Code
                                             != SUCCESS,
                                             debit used
                                             units

    Open      CC termination request         Send          Idle
              received and successfully      CC termin.
              processed                      answer,
                                             Stop Tcc,
                                             debit used
                                             units

    Open      CC termination request         Send          Idle
              received but not               CC termin.
              successfully processed         answer with
                                             Result-Code
                                             != SUCCESS,
                                             debit used
                                             units

    Open      Session supervision timer Tcc  Release       Idle
              expired                        reserved
                                             units

8.  Credit-Control AVPs

   This section defines the credit-control AVPs that are specific to
   Diameter credit-control application and that MAY be included in the
   Diameter credit-control messages.

   The AVPs defined in this section MAY also be included in
   authorization commands defined in authorization-specific
   applications, such as [NASREQ] and [DIAMMIP], if the first
   interrogation is performed as part of the
   authorization/authentication process, as described in section 5.2.

Top      Up      ToC       Page 56 
   The Diameter AVP rules are defined in the Diameter Base [DIAMBASE],
   section 4.  These AVP rules are observed in AVPs defined in this
   section.

   The following table describes the Diameter AVPs defined in the
   credit-control application, their AVP Code values, types, possible
   flag values, and whether the AVP MAY be encrypted.  The Diameter base
   [DIAMBASE] specifies the AVP Flag rules for AVPs in section 4.5.

                                            +--------------------+
                                            |    AVP Flag rules  |
                                            |----+-----+----+----|----+
                     AVP  Section           |    |     |SHLD|MUST|    |
   Attribute Name    Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|
   -----------------------------------------|----+-----+----+----|----|
   CC-Correlation-Id 411  8.1    OctetString|    | P,M |    |  V | Y  |
   CC-Input-Octets   412  8.24   Unsigned64 | M  |  P  |    |  V | Y  |
   CC-Money          413  8.22   Grouped    | M  |  P  |    |  V | Y  |
   CC-Output-Octets  414  8.25   Unsigned64 | M  |  P  |    |  V | Y  |
   CC-Request-Number 415  8.2    Unsigned32 | M  |  P  |    |  V | Y  |
   CC-Request-Type   416  8.3    Enumerated | M  |  P  |    |  V | Y  |
   CC-Service-       417  8.26   Unsigned64 | M  |  P  |    |  V | Y  |
     Specific-Units                         |    |     |    |    |    |
   CC-Session-       418  8.4    Enumerated | M  |  P  |    |  V | Y  |
     Failover                               |    |     |    |    |    |
   CC-Sub-Session-Id 419  8.5    Unsigned64 | M  |  P  |    |  V | Y  |
   CC-Time           420  8.21   Unsigned32 | M  |  P  |    |  V | Y  |
   CC-Total-Octets   421  8.23   Unsigned64 | M  |  P  |    |  V | Y  |
   CC-Unit-Type      454  8.32   Enumerated | M  |  P  |    |  V | Y  |
   Check-Balance-    422  8.6    Enumerated | M  |  P  |    |  V | Y  |
     Result                                 |    |     |    |    |    |
   Cost-Information  423  8.7    Grouped    | M  |  P  |    |  V | Y  |
   Cost-Unit         424  8.12   UTF8String | M  |  P  |    |  V | Y  |
   Credit-Control    426  8.13   Enumerated | M  |  P  |    |  V | Y  |
   Credit-Control-   427  8.14   Enumerated | M  |  P  |    |  V | Y  |
     Failure-Handling                       |    |     |    |    |    |
   Currency-Code     425  8.11   Unsigned32 | M  |  P  |    |  V | Y  |
   Direct-Debiting-  428  8.15   Enumerated | M  |  P  |    |  V | Y  |
     Failure-Handling                       |    |     |    |    |    |
   Exponent          429  8.9    Integer32  | M  |  P  |    |  V | Y  |
   Final-Unit-Action 449  8.35   Enumerated | M  |  P  |    |  V | Y  |
   Final-Unit-       430  8.34   Grouped    | M  |  P  |    |  V | Y  |
     Indication                             |    |     |    |    |    |
   Granted-Service-  431  8.17   Grouped    | M  |  P  |    |  V | Y  |
     Unit                                   |    |     |    |    |    |
   G-S-U-Pool-       453  8.31   Unsigned32 | M  |  P  |    |  V | Y  |
     Identifier                             |    |     |    |    |    |

Top      Up      ToC       Page 57 
   G-S-U-Pool-       457  8.30   Grouped    | M  |  P  |    |  V | Y  |
     Reference                              |    |     |    |    |    |
   Multiple-Services 456  8.16   Grouped    | M  |  P  |    |  V | Y  |
    -Credit-Control                         |    |     |    |    |    |
   Multiple-Services 455  8.40   Enumerated | M  |  P  |    |  V | Y  |
    -Indicator                              |    |     |    |    |    |
   Rating-Group      432  8.29   Unsigned32 | M  |  P  |    |  V | Y  |
   Redirect-Address  433  8.38   Enumerated | M  |  P  |    |  V | Y  |
     -Type                                  |    |     |    |    |    |
   Redirect-Server   434  8.37   Grouped    | M  |  P  |    |  V | Y  |
   Redirect-Server   435  8.39   UTF8String | M  |  P  |    |  V | Y  |
     -Address                               |    |     |    |    |    |
   Requested-Action  436  8.41   Enumerated | M  |  P  |    |  V | Y  |
   Requested-Service 437  8.18   Grouped    | M  |  P  |    |  V | Y  |
     -Unit                                  |    |     |    |    |    |
   Restriction       438  8.36   IPFiltrRule| M  |  P  |    |  V | Y  |
     -Filter-Rule                           |    |     |    |    |    |
   Service-Context   461  8.42   UTF8String | M  |  P  |    |  V | Y  |
     -Id                                    |    |     |    |    |    |
   Service-          439  8.28   Unsigned32 | M  |  P  |    |  V | Y  |
     Identifier                             |    |     |    |    |    |
   Service-Parameter 440  8.43   Grouped    |    | P,M |    |  V | Y  |
     -Info                                  |    |     |    |    |    |
   Service-          441  8.44   Unsigned32 |    | P,M |    |  V | Y  |
     Parameter-Type                         |    |     |    |    |    |
   Service-          442  8.45   OctetString|    | P,M |    |  V | Y  |
     Parameter-Value                        |    |     |    |    |    |
   Subscription-Id   443  8.46   Grouped    | M  |  P  |    |  V | Y  |
   Subscription-Id   444  8.48   UTF8String | M  |  P  |    |  V | Y  |
     -Data                                  |    |     |    |    |    |
   Subscription-Id   450  8.47   Enumerated | M  |  P  |    |  V | Y  |
     -Type                                  |    |     |    |    |    |
   Tariff-Change     452  8.27   Enumerated | M  |  P  |    |  V | Y  |
     -Usage                                 |    |     |    |    |    |
   Tariff-Time       451  8.20   Time       | M  |  P  |    |  V | Y  |
     -Change                                |    |     |    |    |    |
   Unit-Value        445  8.8    Grouped    | M  |  P  |    |  V | Y  |
   Used-Service-Unit 446  8.19   Grouped    | M  |  P  |    |  V | Y  |
   User-Equipment    458  8.49   Grouped    |    | P,M |    |  V | Y  |
     -Info                                  |    |     |    |    |    |
   User-Equipment    459  8.50   Enumerated |    | P,M |    |  V | Y  |
     -Info-Type                             |    |     |    |    |    |
   User-Equipment    460  8.51   OctetString|    | P,M |    |  V | Y  |
     -Info-Value                            |    |     |    |    |    |
   Value-Digits      447  8.10   Integer64  | M  |  P  |    |  V | Y  |
   Validity-Time     448  8.33   Unsigned32 | M  |  P  |    |  V | Y  |

Top      Up      ToC       Page 58 
8.1.  CC-Correlation-Id AVP

   The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and
   contains information to correlate credit-control requests generated
   for different components of the service; e.g., transport and service
   level.  The one who allocates the Service-Context-Id (i.e., unique
   identifier of a service specific document) is also responsible for
   defining the content and encoding of the CC-Correlation-Id AVP.

8.2.  CC-Request-Number AVP

   The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and
   identifies this request within one session.  As Session-Id AVPs are
   globally unique, the combination of Session-Id and CC-Request-Number
   AVPs is also globally unique and can be used in matching credit-
   control messages with confirmations.  An easy way to produce unique
   numbers is to set the value to 0 for a credit-control request of type
   INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the
   first UPDATE_REQUEST, to 2 for the second, and so on until the value
   for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST.

8.3.  CC-Request-Type AVP

   The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and
   contains the reason for sending the credit-control request message.
   It MUST be present in all Credit-Control-Request messages.  The
   following values are defined for the CC-Request-Type AVP:

   INITIAL_REQUEST                 1
      An Initial request is used to initiate a credit-control session,
      and contains credit control information that is relevant to the
      initiation.

   UPDATE_REQUEST                  2
      An Update request contains credit-control information for an
      existing credit-control session.  Update credit-control requests
      SHOULD be sent every time a credit-control re-authorization is
      needed at the expiry of the allocated quota or validity time.
      Further, additional service-specific events MAY trigger a
      spontaneous Update request.

   TERMINATION_REQUEST             3
      A Termination request is sent to terminate a credit-control
      session and contains credit-control information relevant to the
      existing session.

Top      Up      ToC       Page 59 
   EVENT_REQUEST                   4
      An Event request is used when there is no need to maintain any
      credit-control session state in the credit-control server.  This
      request contains all information relevant to the service, and is
      the only request of the service.  The reason for the Event request
      is further detailed in the Requested-Action AVP.  The Requested-
      Action AVP MUST be included in the Credit-Control-Request message
      when CC-Request-Type is set to EVENT_REQUEST.

8.4.  CC-Session-Failover AVP

   The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and
   contains information as to whether moving the credit-control message
   stream to a backup server during an ongoing credit-control session is
   supported.  In communication failures, the credit-control message
   streams can be moved to an alternative destination if the credit-
   control server supports failover to an alternative server.  The
   secondary credit-control server name, if received from the home
   Diameter AAA server, can be used as an address of the backup server.
   An implementation is not required to support moving a credit-control
   message stream to an alternative server, as this also requires moving
   information related to the credit-control session to backup server.

   The following values are defined for the CC-Session-Failover AVP:

   FAILOVER_NOT_SUPPORTED          0
      When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,
      the credit-control message stream MUST NOT to be moved to an
      alternative destination in the case of communication failure.

      This is the default behavior if the AVP isn't included in the
      reply from the authorization or credit-control server.

   FAILOVER_SUPPORTED              1
      When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the
      credit-control message stream SHOULD be moved to an alternative
      destination in the case of communication failure.  Moving the
      credit-control message stream to a backup server MAY require that
      information related to the credit-control session should also be
      forwarded to alternative server.

8.5.  CC-Sub-Session-Id AVP

   The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and
   contains the credit-control sub-session identifier.  The combination
   of the Session-Id and this AVP MUST be unique per sub-session, and

Top      Up      ToC       Page 60 
   the value of this AVP MUST be monotonically increased by one for all
   new sub-sessions.  The absence of this AVP implies that no sub-
   sessions are in use.

8.6.  Check-Balance-Result AVP

   The Check Balance Result AVP (AVP Code 422) is of type Enumerated and
   contains the result of the balance check.  This AVP is applicable
   only when the Requested-Action AVP indicates CHECK_BALANCE in the
   Credit-Control-Request command.

   The following values are defined for the Check-Balance-Result AVP.

   ENOUGH_CREDIT                   0
      There is enough credit in the account to cover the requested
      service.

   NO_CREDIT                       1
      There isn't enough credit in the account to cover the requested
      service.

8.7.  Cost-Information AVP

   The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is
   used to return the cost information of a service, which the credit-
   control client can transfer transparently to the end user.  The
   included Unit-Value AVP contains the cost estimate (always type of
   money) of the service, in the case of price enquiry, or the
   accumulated cost estimation, in the case of credit-control session.

   The Currency-Code specifies in which currency the cost was given.
   The Cost-Unit specifies the unit when the service cost is a cost per
   unit (e.g., cost for the service is $1 per minute).

   When the Requested-Action AVP with value PRICE_ENQUIRY is included in
   the Credit-Control-Request command, the Cost-Information AVP sent in
   the succeeding Credit-Control-Answer command contains the cost
   estimation of the requested service, without any reservation being
   made.

   The Cost-Information AVP included in the Credit-Control-Answer
   command with the CC-Request-Type set to UPDATE_REQUEST contains the
   accumulated cost estimation for the session, without taking any
   credit reservation into account.

Top      Up      ToC       Page 61 
   The Cost-Information AVP included in the Credit-Control-Answer
   command with the CC-Request-Type set to EVENT_REQUEST or
   TERMINATION_REQUEST contains the estimated total cost for the
   requested service.

   It is defined as follows (per the grouped-avp-def of
   RFC 3588 [DIAMBASE]):

                Cost-Information ::= < AVP Header: 423 >
                                     { Unit-Value }
                                     { Currency-Code }
                                     [ Cost-Unit ]

8.8.  Unit-Value AVP

   Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the
   units as decimal value.  The Unit-Value is a value with an exponent;
   i.e., Unit-Value = Value-Digits AVP * 10^Exponent.  This
   representation avoids unwanted rounding off.  For example, the value
   of 2,3 is represented as Value-Digits = 23 and Exponent = -1.  The
   absence of the exponent part MUST be interpreted as an exponent equal
   to zero.

   It is defined as follows (per the grouped-avp-def of
   RFC 3588 [DIAMBASE]):

                    Unit-Value ::= < AVP Header: 445 >
                                   { Value-Digits }
                                   [ Exponent ]

8.9.  Exponent AVP

   Exponent AVP is of type Integer32 (AVP Code 429) and contains the
   exponent value to be applied for the Value-Digit AVP within the
   Unit-Value AVP.

8.10.  Value-Digits AVP

   The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains
   the significant digits of the number.  If decimal values are needed
   to present the units, the scaling MUST be indicated with the related
   Exponent AVP.  For example, for the monetary amount $ 0.05 the value
   of Value-Digits AVP MUST be set to 5, and the scaling MUST be
   indicated with the Exponent AVP set to -2.

Top      Up      ToC       Page 62 
8.11.  Currency-Code AVP

   The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and
   contains a currency code that specifies in which currency the values
   of AVPs containing monetary units were given.  It is specified by
   using the numeric values defined in the ISO 4217 standard [ISO4217].

8.12.  Cost-Unit AVP

   The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is
   used to display a human readable string to the end user.  It
   specifies the applicable unit to the Cost-Information when the
   service cost is a cost per unit (e.g., cost of the service is $1 per
   minute).  The Cost-Unit can be minutes, hours, days, kilobytes,
   megabytes, etc.

8.13.  Credit-Control AVP

   The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST
   be included in AA requests when the service element has credit-
   control capabilities.

   CREDIT_AUTHORIZATION            0
      If the home Diameter AAA server determines that the user has
      prepaid subscription, this value indicates that the credit-control
      server MUST be contacted to perform the first interrogation.  The
      value of the Credit-Control AVP MUST always be set to 0 in an AA
      request sent to perform the first interrogation and to initiate a
      new credit-control session.

   RE_AUTHORIZATION                1
      This value indicates to the Diameter AAA server that a credit-
      control session is ongoing for the subscriber and that the
      credit-control server MUST not be contacted.  The Credit-Control
      AVP set to the value of 1 is to be used only when the first
      interrogation has been successfully performed and the credit-
      control session is ongoing (i.e., re-authorization triggered by
      Authorization-Lifetime).  This value MUST NOT be used in an AA
      request sent to perform the first interrogation.

8.14.  Credit-Control-Failure-Handling AVP

   The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type
   Enumerated.  The credit-control client uses information in this AVP
   to decide what to do if sending credit-control messages to the
   credit-control server has been, for instance, temporarily prevented
   due to a network problem.  Depending on the service logic, the
   credit-control server can order the client to terminate the service

Top      Up      ToC       Page 63 
   immediately when there is a reason to believe that the service cannot
   be charged, or to try failover to an alternative server, if possible.
   Then the server could either terminate or grant the service, should
   the alternative connection also fail.

   TERMINATE                       0
      When the Credit-Control-Failure-Handling AVP is set to TERMINATE,
      the service MUST only be granted for as long as there is a
      connection to the credit-control server.  If the credit-control
      client does not receive any Credit-Control-Answer message within
      the Tx timer (as defined in section 13), the credit-control
      request is regarded as failed, and the end user's service session
      is terminated.

      This is the default behavior if the AVP isn't included in the
      reply from the authorization or credit-control server.

   CONTINUE                       1
      When the Credit-Control-Failure-Handling AVP is set to CONTINUE,
      the credit-control client SHOULD re-send the request to an
      alternative server in the case of transport or temporary failures,
      provided that a failover procedure is supported in the credit-
      control server and the credit-control client, and that an
      alternative server is available.  Otherwise, the service SHOULD be
      granted, even if credit-control messages can't be delivered.

   RETRY_AND_TERMINATE            2
      When the Credit-Control-Failure-Handling AVP is set to
      RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the
      request to an alternative server in the case of transport or
      temporary failures, provided that a failover procedure is
      supported in the credit-control server and the credit-control
      client, and that an alternative server is available.  Otherwise,
      the service SHOULD not be granted when the credit-control messages
      can't be delivered.

8.15.  Direct-Debiting-Failure-Handling AVP

   The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type
   Enumerated.  The credit-control client uses information in this AVP
   to decide what to do if sending credit-control messages (Requested-
   Action AVP set to DIRECT_DEBITING) to the credit-control server has
   been, for instance, temporarily prevented due to a network problem.

   TERMINATE_OR_BUFFER             0
      When the Direct-Debiting-Failure-Handling AVP is set to
      TERMINATE_OR_BUFFER, the service MUST be granted for as long as
      there is a connection to the credit-control server.  If the

Top      Up      ToC       Page 64 
      credit-control client does not receive any Credit-Control-Answer
      message within the Tx timer (as defined in section 13) the
      credit-control request is regarded as failed.  The client SHOULD
      terminate the service if it can determine from the failed answer
      that units have not been debited.  Otherwise the credit-control
      client SHOULD grant the service, store the request in application
      level non-volatile storage, and try to re-send the request.  These
      requests MUST be marked as possible duplicates by setting the T-
      flag in the command header as described in [DIAMBASE] section 3.

      This is the default behavior if the AVP isn't included in the
      reply from the authorization server.

   CONTINUE                                              1
      When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE,
      the service SHOULD be granted, even if credit-control messages
      can't be delivered, and the request should be deleted.

8.16.  Multiple-Services-Credit-Control AVP

   Multiple-Services-Credit-Control AVP (AVP Code 456) is of type
   Grouped and contains the AVPs related to the independent credit-
   control of multiple services feature.  Note that each instance of
   this AVP carries units related to one or more services or related to
   a single rating group.

   The Service-Identifier and the Rating-Group AVPs are used to
   associate the granted units to a given service or rating group.  If
   both the Service-Identifier and the Rating-Group AVPs are included,
   the target of the service units is always the service(s) indicated by
   the value of the Service-Identifier AVP(s).  If only the Rating-
   Group-Id AVP is present, the Multiple-Services-Credit-Control AVP
   relates to all the services that belong to the specified rating
   group.

   The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-
   Pool-Identifier identifying a credit pool within which the units of
   the specified type are considered pooled.  If a G-S-U-Pool-Reference
   AVP is present, then actual service units of the specified type MUST
   also be present.  For example, if the G-S-U-Pool-Reference AVP
   specifies Unit-Type TIME, then the CC-Time AVP MUST be present.

   The Requested-Service-Unit AVP MAY contain the amount of requested
   service units or the requested monetary value.  It MUST be present in
   the initial interrogation and within the intermediate interrogations
   in which new quota is requested.  If the credit-control client does
   not include the Requested-Service-Unit AVP in a request command,
   because for instance, it has determined that the end-user terminated

Top      Up      ToC       Page 65 
   the service, the server MUST debit the used amount from the user's
   account but MUST NOT return a new quota in the corresponding answer.
   The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY be
   present in an answer command as defined in sections 5.1.2 and 5.6 for
   the graceful service termination.

   When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are
   present, the server MUST include two separate instances of the
   Multiple-Services-Credit-Control AVP with the Granted-Service-Unit
   AVP associated to the same service-identifier and/or rating-group.
   Where the two quotas are associated to the same pool or to different
   pools, the credit pooling mechanism defined in section 5.1.2 applies.
   The Tariff-Change-Usage AVP MUST NOT be included in request commands
   to report used units before, and after tariff time change the Used-
   Service-Unit AVP MUST be used.

   A server not implementing the independent credit-control of multiple
   services functionality MUST treat the Multiple-Services-Credit-
   Control AVP as an invalid AVP.

   The Multiple-Services-Control AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [DIAMBASE]):

      Multiple-Services-Credit-Control ::= < AVP Header: 456 >
                                           [ Granted-Service-Unit ]
                                           [ Requested-Service-Unit ]
                                          *[ Used-Service-Unit ]
                                           [ Tariff-Change-Usage ]
                                          *[ Service-Identifier ]
                                           [ Rating-Group ]
                                          *[ G-S-U-Pool-Reference ]
                                           [ Validity-Time ]
                                           [ Result-Code ]
                                           [ Final-Unit-Indication ]
                                          *[ AVP ]

8.17.  Granted-Service-Unit AVP

   Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and
   contains the amount of units that the Diameter credit-control client
   can provide to the end user until the service must be released or the
   new Credit-Control-Request must be sent.  A client is not required to
   implement all the unit types, and it must treat unknown or
   unsupported unit types in the answer message as an incorrect CCA
   answer.  In this case, the client MUST terminate the credit-control
   session and indicate in the Termination-Cause AVP reason
   DIAMETER_BAD_ANSWER.

Top      Up      ToC       Page 66 
   The Granted-Service-Unit AVP is defined as follows (per the grouped-
   avp-def of RFC 3588 [DIAMBASE]):

      Granted-Service-Unit ::= < AVP Header: 431 >
                                 [ Tariff-Time-Change ]
                                 [ CC-Time ]
                                 [ CC-Money ]
                                 [ CC-Total-Octets ]
                                 [ CC-Input-Octets ]
                                 [ CC-Output-Octets ]
                                 [ CC-Service-Specific-Units ]
                                *[ AVP ]

8.18.  Requested-Service-Unit AVP

   The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and
   contains the amount of requested units specified by the Diameter
   credit-control client.  A server is not required to implement all the
   unit types, and it must treat unknown or unsupported unit types as
   invalid AVPs.

   The Requested-Service-Unit AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [DIAMBASE]):

      Requested-Service-Unit ::= < AVP Header: 437 >
                                 [ CC-Time ]
                                 [ CC-Money ]
                                 [ CC-Total-Octets ]
                                 [ CC-Input-Octets ]
                                 [ CC-Output-Octets ]
                                 [ CC-Service-Specific-Units ]
                                *[ AVP ]

8.19.  Used-Service-Unit AVP

   The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and
   contains the amount of used 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.

Top      Up      ToC       Page 67 
   The Used-Service-Unit AVP is defined as follows (per the grouped-
   avp-def of RFC 3588 [DIAMBASE]):

      Used-Service-Unit ::= < AVP Header: 446 >
                            [ Tariff-Change-Usage ]
                            [ CC-Time ]
                            [ CC-Money ]
                            [ CC-Total-Octets ]
                            [ CC-Input-Octets ]
                            [ CC-Output-Octets ]
                            [ CC-Service-Specific-Units ]
                           *[ AVP ]

8.20.  Tariff-Time-Change AVP

   The Tariff-Time-Change AVP (AVP Code 451) is of type Time.  It is
   sent from the server to the client and includes the time in seconds
   since January 1, 1900, 00:00 UTC, when the tariff of the service will
   be changed.

   The tariff change mechanism is optional for the client and server,
   and it is not used for time-based services defined in section 5.  If
   a client does not support the tariff time change mechanism, it MUST
   treat Tariff-Time-Change AVP in the answer message as an incorrect
   CCA answer.  In this case, the client terminates the credit-control
   session and indicates in the Termination-Cause AVP reason
   DIAMETER_BAD_ANSWER.

   Omission of this AVP means that no tariff change is to be reported.

8.21.  CC-Time AVP

   The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates
   the length of the requested, granted, or used time in seconds.

8.22.  CC-Money AVP

   The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the
   monetary amount in the given currency.  The Currency-Code AVP SHOULD
   be included.  It is defined as follows (per the grouped-avp-def of
   RFC 3588 [DIAMBASE]):

      CC-Money ::= < AVP Header: 413 >
                   { Unit-Value }
                   [ Currency-Code ]


Next RFC Part