Diameter Credit-Control Application
obsoleted by
- rfc-8506 — Diameter Credit-Control Application
Extracted elements (30)
The credit pool concept (G-S-U-Pool-Reference AVP) was introduced to avoid credit fragmentation when multiple concurrent services draw from the same account. Instead of separate small reservations per service, a shared pool with per-service multipliers allows efficient aggregation, reduces server load, and also mitigates the over-reservation problem caused by tariff-time changes.
Two credit authorization models are defined: reservation-based (session-based, multiple interrogations) and direct debiting (one-time event, single transaction). The reservation model supports ongoing services where total cost is unknown upfront; direct debiting suits discrete transactions. This duality accommodates both prepaid data/voice sessions and one-shot purchases such as content downloads.
Two methods for the first interrogation are defined: (1) after user authentication/authorization completes, and (2) embedded within the AA request/answer exchange. The embedded approach is preferred for NAS environments for protocol efficiency; the post-auth approach suits 3GPP and SIP environments where authentication and service requests are decoupled.
Section 11 defines a RADIUS/Diameter credit-control interworking model where a RADIUS AAA server acts as a Diameter credit-control client gateway. This enables RADIUS-based service elements (e.g., NAS) to utilize Diameter real-time credit-control without requiring modification to the service element itself.
The Diameter credit-control application intentionally does not define rating input AVPs; these are specified in service-specific documents (3GPP, OMA, informational RFCs). Interoperability requires prior agreement on Service-Context-Id values and associated rating AVPs between credit-control client and server providers.
Credit-control client implementations MUST support the Final-Unit-Indication AVP with at least the teardown of the ongoing service session once the subscriber has consumed all final granted units.
Diameter nodes conforming to this specification MUST advertise support by including the value 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
During intermediate interrogation, when granted service units are exhausted or Validity-Time expires, the credit-control client MUST send a new CCR with CC-Request-Type = UPDATE_REQUEST. If several unit types were included in the previous answer, used units for each type MUST be reported.
Each credit-control session MUST have a globally unique Session-Id as defined in the Diameter base protocol, which MUST NOT be changed during the lifetime of a credit-control session.
If a client does not support the tariff change mechanism and receives a CCA carrying the Tariff-Time-Change AVP, it MUST terminate the credit-control session with DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
If a rating input is incorrect or the server does not support the requested service context, the CCA MUST contain result code DIAMETER_RATING_FAILED and MUST include Failed-AVP AVPs identifying the missing or unsupported AVPs. A client receiving DIAMETER_RATING_FAILED MUST NOT send similar requests in the future.
If credit-control sub-sessions are used, all sub-sessions MUST be closed separately before the main session is closed so that units per sub-session may be reported.
If Diameter credit-control proxies exist between the credit-control client and the credit-control server, they MUST advertise the Diameter credit-control application support during capability exchange.
The credit-control client MUST include the Multiple-Services-Indicator AVP in the first interrogation to indicate support for independent credit-control of multiple services. A server not supporting this feature MUST treat Multiple-Services-Credit-Control AVPs as invalid AVPs.
The Service-Context-Id AVP MUST be included at the command level of a Credit-Control-Request to identify the service-specific document applicable to the request. The specific service or rating group is uniquely identified by the combination of Service-Context-Id and Service-Identifier or Rating-Group.
Upon expiration of the Validity-Time, the credit-control client MUST generate a credit-control update request (CC-Request-Type = UPDATE_REQUEST) and report the used quota to the credit-control server.
When no credit re-authorization is already ongoing and an RAR is received for an active session, the credit-control client MUST acknowledge via RAA and MUST initiate credit re-authorization by sending CCR with CC-Request-Type = UPDATE_REQUEST. Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA to signal that an additional CCR is required.
When session-based credit-control is required, the first interrogation (CC-Request-Type = INITIAL_REQUEST) MUST be sent before the Diameter credit-control client allows any service event to the end user.
When the end user terminates the service session or graceful termination occurs, the credit-control client MUST send a final CCR with CC-Request-Type = TERMINATION_REQUEST. After final interrogation, the credit-control server MUST refund the reserved credit not used and deduct the used amount from the user's account.
The CC-Request-Type AVP (Code 416) identifies the type of credit-control operation: INITIAL_REQUEST (1), UPDATE_REQUEST (2), TERMINATION_REQUEST (3), or EVENT_REQUEST (4). This AVP is mandatory in both CCR and CCA and drives the state machine.
The Credit-Control-Failure-Handling AVP (Code 427) instructs the client on behavior when credit-control messages cannot reach the server: TERMINATE (0) stops the service, CONTINUE (1) allows service to continue, and RETRY_AND_TERMINATE (2) retries and then terminates.
The Final-Unit-Indication AVP (Code 430) is a grouped AVP signaling that the answer contains the last quota for a service. The mandatory Final-Unit-Action sub-AVP specifies the client's required behavior upon exhaustion: TERMINATE (0), REDIRECT (1), or RESTRICT_ACCESS (2).
The G-S-U-Pool-Reference AVP (Code 457) is a grouped AVP that associates a granted quota with a credit pool. It contains G-S-U-Pool-Identifier and a unit multiplier that translates service-specific units to abstract pool units, enabling multiple services to draw from a shared reservation.
The Multiple-Services-Credit-Control AVP (Code 456) is a grouped AVP enabling independent credit-control of multiple services or rating groups within a single session. It carries Requested-Service-Unit, Granted-Service-Unit, Used-Service-Unit, Rating-Group, Service-Identifier, Validity-Time, Final-Unit-Indication, Result-Code, and G-S-U-Pool-Reference sub-AVPs.
IANA assigned Diameter Credit-Control Application-Id value 4, Command-Code 272 for CCR/CCA, and AVP codes for all credit-control-specific AVPs (e.g., CC-Request-Type, Granted-Service-Unit, Multiple-Services-Credit-Control). New Result-Code values include DIAMETER_CREDIT_LIMIT_REACHED (4012) and DIAMETER_RATING_FAILED (5031). Enumerated AVP registries are created for CC-Request-Type, CC-Unit-Type, Final-Unit-Action, and others.
The credit-control application carries sensitive financial data including account balances and transaction amounts. Diameter security mechanisms (TLS or IPsec) MUST be used to protect credit-control messages against eavesdropping and tampering. Unauthorized modification could allow fraudulent credit manipulation.
When Diameter Redirect agents refer credit-control clients to credit-control servers for direct connection, the client must ensure the redirected connection uses appropriate security. A malicious redirect could divert credit-control traffic to an unauthorized server, enabling fraudulent service grants or account manipulation.
Section 7 defines the Credit-Control Application state machine. States include Idle, PendingI (initial CCR sent, awaiting CCA), Open (session active, quota granted), PendingU (update CCR sent, awaiting CCA), PendingT (termination CCR sent), and PendingE (event CCR sent). Transitions are triggered by sending CCR, receiving CCA, Validity-Time expiry, Final-Unit-Indication consumption, and RAR receipt.
The Credit-Control-Answer (CCA) uses Command-Code 272 with the R bit cleared. Mandatory AVPs include Session-Id, Result-Code, Origin-Host, Origin-Realm, Auth-Application-Id, CC-Request-Type, and CC-Request-Number. Optional AVPs include Granted-Service-Unit, Multiple-Services-Credit-Control, Final-Unit-Indication, and Validity-Time.
The Credit-Control-Request (CCR) uses Command-Code 272 with the REQ bit set. Mandatory AVPs include Session-Id, Origin-Host, Origin-Realm, Destination-Realm, Auth-Application-Id (value 4), Service-Context-Id, CC-Request-Type, and CC-Request-Number.