Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4006

Diameter Credit-Control Application

Pages: 114
Obsoleted by:  8506
Part 3 of 5 – Pages 41 to 67
First   Prev   Next

ToP   noToC   RFC4006 - Page 41   prevText

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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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   noToC   RFC4006 - 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 ]