RFC 4006
Diameter Credit-Control Application
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.
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.
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).
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
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
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.
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.
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
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
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
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
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
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
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
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.
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 | | | | | |
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 |
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.
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
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.
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.
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
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
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
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.
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.
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 ]