RFC 8506
Diameter Credit-Control Application
RFC 8506: Diameter Credit-Control Application 💖
Part 1 of 33 🦋
Okay bestie, let's start with the title block because it's giving official paperwork energy ✨ This is RFC 8506, published by the IETF in March 2019. It's a Standards Track document, so it's a real protocol spec people are meant to implement 🔥 The editors are L. Bertz (from Sprint), D. Dolson, and Y. Lifshitz (from Sandvine), and the "Ed." after each name means they're the editors 👑 It's identified by ISSN 2070-1721.
The big plot twist is that this RFC obsoletes RFC 4006, so it replaces the older Diameter Credit-Control spec 💅 The title block doesn't list anything it updates.
Abstract
Okay so, the abstract is the "here's what this is about" part 🎀 This document defines a Diameter application for real-time credit-control, which is basically how a network keeps track of what you've got left before you run out. It's useful for all kinds of end-user services, like network access, Session Initiation Protocol (SIP) services, messaging services, and download services 📱✨
It also says that the Diameter Credit-Control application in this document obsoletes RFC 4006, and that it must be supported by all new Diameter Credit-Control application implementations. So if you're building one new, this is the one you use 🫶
Status of This Memo
Let's talk about where this doc stands 🌸 It's an Internet Standards Track document, which is the most official category there is 🔥 It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Wild, right? 💜
If you want more info on what Internet Standards are, check out Section 2 of RFC 7841. Also, the current status, any errata, and how to give feedback are all at https://www.rfc-editor.org/info/rfc8506 🧚
Copyright Notice
Last but not least, the legal stuff 🙈 The copyright belongs to the IETF Trust and the document authors, copyright (c) 2019, all rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please actually read these, because they explain your rights and restrictions. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in that license 💖
Heads up: this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that older material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫶
Part 2 coming up next, bestie 🦋
Table of Contents 🎀
okay so this is the map of the whole doc, bestie 🗺️✨ every section and subsection is listed in order, so you can see exactly where each piece lives 💅
1. Introduction ....................................................6
1.1. Requirements Language ......................................7
1.2. Terminology ................................................7
1.3. Advertising Application Support ............................9
2. Architecture Models .............................................9
3. Credit-Control Messages ........................................11
3.1. Credit-Control-Request (CCR) Command ......................11
3.2. Credit-Control-Answer (CCA) Command .......................12
4. Credit-Control Application Overview ............................13
4.1. Service-Specific Rating Input and Interoperability ........14
4.1.1. Specifying Rating Input AVPs .......................15
4.1.2. Service-Specific Documentation .....................16
4.1.3. Handling of Unsupported/Incorrect Rating Input .....16
4.1.4. RADIUS Vendor-Specific Rating Attributes ...........17
5. Session-Based Credit-Control ...................................17
5.1. General Principles ........................................17
5.1.1. Basic Support for Tariff Time Change ...............18
5.1.2. Credit-Control for Multiple Services within
a (Sub-)Session ....................................19
5.2. First Interrogation .......................................23
5.2.1. First Interrogation after Authorization and
Authentication .....................................25
5.2.2. First Interrogation Included with
Authorization Messages .............................27
5.3. Intermediate Interrogation ................................29
5.4. Final Interrogation .......................................31
5.5. Server-Initiated Credit Re-authorization ..................32
5.6. Graceful Service Termination ..............................34
5.6.1. Terminate Action ...................................37
5.6.2. Redirect Action ....................................38
5.6.3. Restrict Access Action .............................40
5.6.4. Usage of the Server-Initiated Credit
Re-authorization ...................................41
5.7. Failure Procedures ........................................41
6. One-Time Event .................................................44
6.1. Service Price Inquiry .....................................45
6.2. Balance Checks ............................................46
6.3. Direct Debiting ...........................................46
6.4. Refunds ...................................................47
6.5. Failure Procedure .........................................48
7. Credit-Control Application State Machines ......................50
8. Credit-Control AVPs ............................................59
8.1. CC-Correlation-Id AVP .....................................61
8.2. CC-Request-Number AVP .....................................62
8.3. CC-Request-Type AVP .......................................62
8.4. CC-Session-Failover AVP ...................................63
8.5. CC-Sub-Session-Id AVP .....................................64
8.6. Check-Balance-Result AVP ..................................64
8.7. Cost-Information AVP ......................................64
8.8. Unit-Value AVP ............................................65
8.9. Exponent AVP ..............................................65
8.10. Value-Digits AVP .........................................66
8.11. Currency-Code AVP ........................................66
8.12. Cost-Unit AVP ............................................66
8.13. Credit-Control AVP .......................................66
8.14. Credit-Control-Failure-Handling AVP (CCFH) ...............67
8.15. Direct-Debiting-Failure-Handling AVP (DDFH) ..............68
8.16. Multiple-Services-Credit-Control AVP .....................68
8.17. Granted-Service-Unit AVP .................................70
8.18. Requested-Service-Unit AVP ...............................71
8.19. Used-Service-Unit AVP ....................................71
8.20. Tariff-Time-Change AVP ...................................72
8.21. CC-Time AVP ..............................................72
8.22. CC-Money AVP .............................................72
8.23. CC-Total-Octets AVP ......................................72
8.24. CC-Input-Octets AVP ......................................72
8.25. CC-Output-Octets AVP .....................................73
8.26. CC-Service-Specific-Units AVP ............................73
8.27. Tariff-Change-Usage AVP ..................................73
8.28. Service-Identifier AVP ...................................74
8.29. Rating-Group AVP .........................................74
8.30. G-S-U-Pool-Reference AVP .................................74
8.31. G-S-U-Pool-Identifier AVP ................................75
8.32. CC-Unit-Type AVP .........................................75
8.33. Validity-Time AVP ........................................75
8.34. Final-Unit-Indication AVP ................................76
8.35. Final-Unit-Action AVP ....................................77
8.36. Restriction-Filter-Rule AVP ..............................78
8.37. Redirect-Server AVP ......................................78
8.38. Redirect-Address-Type AVP ................................79
8.39. Redirect-Server-Address AVP ..............................79
8.40. Multiple-Services-Indicator AVP ..........................80
8.41. Requested-Action AVP .....................................80
8.42. Service-Context-Id AVP ...................................81
8.43. Service-Parameter-Info AVP ...............................82
8.44. Service-Parameter-Type AVP ...............................82
8.45. Service-Parameter-Value AVP ..............................83
8.46. Subscription-Id AVP ......................................83
8.47. Subscription-Id-Type AVP .................................83
8.48. Subscription-Id-Data AVP .................................84
8.49. User-Equipment-Info AVP ..................................84
8.50. User-Equipment-Info-Type AVP .............................84
8.51. User-Equipment-Info-Value AVP ............................85
8.52. User-Equipment-Info-Extension AVP ........................85
8.53. User-Equipment-Info-IMEISV AVP ...........................86
8.54. User-Equipment-Info-MAC AVP ..............................86
8.55. User-Equipment-Info-EUI64 AVP ............................86
8.56. User-Equipment-Info-ModifiedEUI64 AVP ....................86
8.57. User-Equipment-Info-IMEI AVP .............................86
8.58. Subscription-Id-Extension AVP ............................87
8.59. Subscription-Id-E164 AVP .................................87
8.60. Subscription-Id-IMSI AVP .................................87
8.61. Subscription-Id-SIP-URI AVP ..............................88
8.62. Subscription-Id-NAI AVP ..................................88
8.63. Subscription-Id-Private AVP ..............................88
8.64. Redirect-Server-Extension AVP ............................88
8.65. Redirect-Address-IPAddress AVP ...........................89
8.66. Redirect-Address-URL AVP .................................89
8.67. Redirect-Address-SIP-URI AVP .............................89
8.68. QoS-Final-Unit-Indication AVP ............................89
9. Result-Code AVP Values .........................................91
9.1. Transient Failures ........................................91
9.2. Permanent Failures ........................................92
10. AVP Occurrence Table ..........................................92
10.1. Credit-Control AVP Table .................................93
10.2. Re-Auth-Request/Re-Auth-Answer AVP Table .................94
11. RADIUS/Diameter Credit-Control Interworking Model .............94
12. IANA Considerations ...........................................97
12.1. Application Identifier ...................................97
12.2. Command Codes ............................................97
12.3. AVP Codes ................................................97
12.4. Result-Code AVP Values ...................................98
12.5. CC-Request-Type AVP ......................................98
12.6. CC-Session-Failover AVP ..................................98
12.7. CC-Unit-Type AVP .........................................99
12.8. Check-Balance-Result AVP .................................99
12.9. Credit-Control AVP .......................................99
12.10. Credit-Control-Failure-Handling AVP .....................99
12.11. Direct-Debiting-Failure-Handling AVP ....................99
12.12. Final-Unit-Action AVP ...................................99
12.13. Multiple-Services-Indicator AVP ........................100
12.14. Redirect-Address-Type AVP ..............................100
12.15. Requested-Action AVP ...................................100
12.16. Subscription-Id-Type AVP ...............................100
12.17. Tariff-Change-Usage AVP ................................100
12.18. User-Equipment-Info-Type AVP ...........................100
13. Parameters Related to the Credit-Control Application .........101
14. Security Considerations ......................................101
14.1. Direct Connection with Redirects ........................102
14.2. Application-Level Redirects .............................103
15. Privacy Considerations .......................................104
15.1. Privacy-Sensitive AVPs ..................................104
15.2. Data Minimization .......................................106
15.3. Diameter Agents .........................................107
16. References ...................................................107
16.1. Normative References ....................................107
16.2. Informative References ..................................110
Appendix A. Credit-Control Sequences .............................111
A.1. Flow I ....................................................111
A.2. Flow II ...................................................113
A.3. Flow III ..................................................116
A.4. Flow IV ...................................................117
A.5. Flow V ....................................................119
A.6. Flow VI ...................................................120
A.7. Flow VII ..................................................121
A.8. Flow VIII .................................................123
A.9. Flow IX ...................................................124
Acknowledgements .................................................130
Authors' Addresses ...............................................130Heads up, the page numbers are the RFC's own, so they won't line up with your screen 📄🌸 Next up is the actual Introduction, where the good stuff starts 🦋💖
1. Introduction ✨
okay bestie, this doc is about a Diameter application for real-time credit-control 💸. It works for all kinds of end-user services: network access, Session Initiation Protocol (SIP) services, messaging, and download services. ("Credit-control" is sometimes shortened to "CC" in figures and tables throughout this document 🎀.) The Diameter Credit-Control application defined here obsoletes [RFC4006], and it must be supported by all new Diameter Credit-Control application implementations 🫶. It's a general solution for real-time cost and credit-control, so it's giving universal 👑.
The prepaid model has been super successful. In GSM networks, operators offering prepaid services saw their customer base and revenues grow a lot 📈. Prepaid services are now popping up in plenty of other wireless and wire-line networks too 🌸.
In mobile networks, the Diameter base protocol [RFC6733] isn't enough on its own 🙈. For example, the 3GPP charging and billing requirements document [TGPPCHARG] says an application must be able to rate service information in real time ⏱️. It's also necessary to check that the end user's account covers the requested service before that service starts 🛑. When an account is exhausted or expired, the user must be denied the ability to compile additional chargeable events 💀.
Users need to be told what charges will be levied for a requested service, so a mechanism has to be provided for that 🧾. And there are services like gaming and advertising that can credit as well as debit a user account 🎮.
The other Diameter applications handle service-specific authorization, but they don't do credit authorization for prepaid users 🙅♀️. The credit authorization shall be generic and applicable to all the service environments required to support prepaid services 💅.
To make all this work, credit-control communication has to happen between the network element providing the service (e.g., Network Access Server (NAS), SIP Proxy, Application Server) and a credit-control server 🦋.
The scope of this specification is credit authorization. Service-specific authorization and authentication are out of scope 🚫.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔠.
1.2. Terminology
Okay, time for the vocab list 📚.
AAA: Authentication, Authorization, and Accounting.
AA-Answer: "AA-Answer" generically refers to a service-specific authorization and authentication answer. AA-Answer commands are defined in service-specific authorization applications, e.g., [RFC7155] [RFC4004].
AA-Request: "AA-Request" generically refers to a service-specific authorization and authentication request. AA-Request commands are defined in service-specific authorization applications, e.g., [RFC7155] [RFC4004].
Credit-control: "Credit-control" is a mechanism that directly interacts in real time with an account and controls or monitors the charges related to service usage. It's a process of (1) checking whether or not credit is available, (2) credit reservation, (3) deduction of credit from the end-user account when service is completed, and (4) refunding of reserved credit that is not used 💰.
Diameter Credit-Control server: A Diameter Credit-Control server acts as a prepaid server, performing real-time rating and credit-control. It is located in the home domain and is accessed by Service Elements or Diameter AAA servers in real time, for the purpose of price determination and credit-control before the service event is delivered to the end user. It may also interact with Business Support Systems 🏦.
Diameter Credit-Control client: A Diameter Credit-Control client is an entity that interacts with a credit-control server. It monitors the usage of the granted quota according to instructions returned by the credit-control server 👀.
Interrogation: The Diameter Credit-Control client uses interrogation to initiate a session-based credit-control process. During the credit-control process, it is used to report the used quota and request a new one. An interrogation maps to a request/answer transaction 🔁.
One-time event: A charging transaction session comprising a single request and single response ☝️.
Rating: The act of determining the cost of the service event 🏷️.
Service: A type of task performed by a Service Element for an end user 🛎️.
Service Element: A network element that provides a service to the end users. The Service Element may include the Diameter Credit-Control client or another entity (e.g., a RADIUS AAA server) that can act as a credit-control client on behalf of the Service Element. In the latter case, the interface between the Service Element and the Diameter Credit-Control client is outside the scope of this specification. Examples of Service Elements include NASs, SIP Proxies, and Application Servers such as messaging servers, content servers, and gaming servers 🎀.
Service event: An event relating to a service provided to the end user ✨.
Session-based credit-control: A credit-control process that makes use of several interrogations: the first, a possible intermediate, and the final. The first interrogation is used to reserve money from the user's account and to initiate the process. Intermediate interrogations (if any) may be needed to request a new quota while the service is being rendered. The final interrogation is used to exit the process. The credit-control server is required to maintain session state for session-based credit-control 🧠.
1.3. Advertising Application Support
Diameter nodes conforming to this specification MUST advertise support by including the value of 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [RFC6733] 📣.
2. Architecture Models
The current accounting models in the RADIUS accounting and Diameter base specifications [RFC2866] [RFC6733] aren't sufficient for real-time credit-control, where creditworthiness has to be determined before service starts 🙅♀️. Also, the existing Diameter authorization applications [RFC7155] [RFC4004] only provide service authorization; they don't provide credit authorization for prepaid users. So to support real-time credit-control, we need a new kind of server in the AAA infrastructure: the Diameter Credit-Control server 🦸♀️. It's the entity responsible for credit authorization for prepaid subscribers, and it's the main character here 👑.
A Service Element may authenticate and authorize the end user with the AAA server by using AAA protocols, e.g., RADIUS or the Diameter base protocol (possibly extended via a Diameter application) 🔐.
Accounting protocols like RADIUS accounting and the Diameter base accounting protocol can provide accounting data to the accounting server after service is initiated, and they can send possible interim reports until service completion 🧾. However, for real-time credit-control, these authorization and accounting models just aren't enough 😭.
When real-time credit-control is required, the credit-control client contacts the credit-control server with information about a possible service event 📞. The credit-control process figures out potential charges and checks whether the end user's account balance is sufficient to cover the cost of the service being rendered 💅.
Figure 1 shows the typical credit-control architecture. It has a Service Element with an embedded Diameter Credit-Control client, a Diameter Credit-Control server, and a AAA server. A Business Support System is usually deployed; at a minimum, it includes billing functionality. The credit-control server and AAA server in this architecture model are logical entities, and the real configuration can combine them into a single host. The credit-control protocol is the Diameter base protocol [RFC6733] with the Diameter Credit-Control application 🗺️.
Service Element AAA and CC
+----------+ +---------+ Protocols+-----------+ +--------+
| End |<---->|+-------+|<------------>| AAA | |Business|
| User | +->|| CC || | Server |->|Support |
| | | || Client||<-----+ | | |System |
+----------+ | |+-------+| | +-----------+ | |
| +---------+ | ^ +--------+
+----------+ | | CC Protocol | ^
| End |<--+ | +-----v----+ |
| User | +------>|Credit- | |
+----------+ Credit-Control |Control |--------+
Protocol |Server |
+----------+
Figure 1: Typical Credit-Control ArchitectureWhen an end user requests services like SIP or messaging, the request is typically forwarded to a Service Element (e.g., a SIP Proxy) in the user's home realm as defined in [RFC6733] 📬. In some cases, a Service Element in the local realm [RFC6733] might be able to offer services to the end user, but a commercial agreement must exist between the local realm and the home realm 🤝. Network access is an example of a service offered in the local realm: the NAS, through a AAA infrastructure, authenticates and authorizes the user with the user's home network 🌐.
There can be multiple credit-control servers in the system for redundancy and load balancing 🛡️. The system can also contain separate rating server(s), and accounts can be located in a centralized database. To make sure the end user's account isn't debited or credited multiple times for the same service event, only one entity in the credit-control system should perform duplicate detection 🙈. System-internal interfaces can exist to relay messages between servers and an account manager. However, the detailed architecture of the credit-control system and its interfaces is implementation specific and is out of scope for this specification 🫠.
Protocol-transparent Diameter relays can exist between the credit-control client and credit-control server 🦋. Diameter redirect agents can also exist, which refer credit-control clients to credit-control servers and allow them to communicate directly. These agents transparently support the Diameter Credit-Control application. The different roles of Diameter agents are defined in Diameter base [RFC6733], Section 2.8 📖.
If Diameter Credit-Control proxies exist between the credit-control client and the credit-control server, they MUST advertise support for the Diameter Credit-Control application 📣💖.
3. Credit-Control Messages 💅
Okay bestie, this section is where the new Diameter message Command Code values show up. Every Diameter implementation that conforms to this specification MUST support them, so no skipping! 🫶 Here are the two Command Codes:
+------------------------+---------+------+-------------+
| Command Name | Abbrev. | Code | Reference |
+------------------------+---------+------+-------------+
| Credit-Control-Request | CCR | 272 | Section 3.1 |
| Credit-Control-Answer | CCA | 272 | Section 3.2 |
+------------------------+---------+------+-------------+
Table 1: Credit-Control CommandsSection 3.2 of [RFC6733] (Diameter base) defines the Command Code Format specification 📋 and these formats are what you'll see in credit-control messages too. Iconic continuity ✨
3.1. Credit-Control-Request (CCR) Command
The Credit-Control-Request message (CCR) is the one with Command Code 272 and the 'R' bit set in the Command Flags field 🚀 It's sent between the Diameter Credit-Control client and the credit-control server to ask for credit authorization for a given service. Main character energy, literally.
The Auth-Application-Id MUST be set to the value 4, which tells everyone this is the Diameter Credit-Control application 🎀
The CCR is extensible, because you can include one or more Attribute-Value Pairs (AVPs) 🌸
Message Format:
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
*[ Subscription-Id-Extension ]
[ Service-Identifier ]
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
*[ Service-Parameter-Info ]
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
[ User-Equipment-Info-Extension ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]3.2. Credit-Control-Answer (CCA) Command
The Credit-Control-Answer message (CCA) is the one with Command Code 272 and the 'R' bit cleared in the Command Flags field 🦋 It goes back between the credit-control server and the Diameter Credit-Control client to acknowledge a Credit-Control-Request command. It's basically the reply that closes the loop 💖
Message Format:
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ CC-Session-Failover ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
[ Granted-Service-Unit ]
*[ Multiple-Services-Credit-Control ]
[ Cost-Information ]
[ Final-Unit-Indication ]
[ QoS-Final-Unit-Indication ]
[ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ]
[ Validity-Time ]
*[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Failed-AVP ]
*[ AVP ]4. Credit-Control Application Overview 🌈
Credit authorization happens before and during service delivery to the end user 💸 It usually needs the user to be authenticated and authorized before any requests go to the credit-control server, so that's the vibe check first. ✨
The credit-control application in this spec supports two credit authorization models: credit authorization with money reservation, and credit authorization with direct debiting 👑 In both, the credit-control client asks the credit-control server for authorization before any service gets delivered to the end user. No freebies!
Okay so in the first model, the credit-control server rates the request, reserves a suitable amount of money from the user's account, and sends back the amount of credit it reserved 🫧 Quick note: credit resources may not imply actual monetary credit. They can be granted to the credit-control client as units instead, like data volume or time that gets metered. Not everything is cash, babe 💅
When the credit-control client gets a successful credit authorization answer with some credit resources, it lets service delivery to the end user go ahead and starts watching how much of the granted resources gets used 👀 Once the granted credit is used up, or the service has been successfully delivered or terminated, the client reports the used amount back to the server 📨 The server takes that used amount off the end user's account. If the service is still going, it can rate things again and make a new credit reservation 🔁 All of this runs through session-based credit-control, which covers the first interrogation, any possible intermediate interrogations, and the final interrogation. For session-based credit-control, both the credit-control client and the credit-control server are required to maintain credit-control session state 🧠 Section 5 has the full breakdown, with more variations, so go check it out 🫶
Credit authorization with direct debiting is the opposite energy: it's a single-transaction process 🎯 The credit-control server directly deducts a suitable amount of money from the user's account as soon as it gets the credit authorization request. After a successful credit authorization answer, the credit-control client lets service delivery to the end user happen. This runs on the one-time event, and session state is not maintained. Simple and clean ✨
In a multi-service environment, an end user can send an extra service request (like a data service) during an ongoing service (like a voice call) toward the same account 📱 Or, during an active multimedia session, another media type can be added to the session. That causes a new simultaneous request toward the same account 🎬 So credit resources granted to the services need to take this into account. Multitasking, but make it billing 💀
The credit-control application also handles service price inquiries, user balance checks, and refunds of credit on the user's account 🍓 These run on the one-time event too, and session state is not maintained.
Flexible failure handling, specific to the credit-control application, is defined in the application 🛡️ This lets the service provider control how the credit-control client behaves according to its own risk management policy. Their rules, their call 💼
The Credit-Control-Failure-Handling AVP (also called the CCFH) and the Direct-Debiting-Failure-Handling AVP (also called the DDFH) decide what happens when sending credit-control messages to the credit-control server has been temporarily prevented 🚧 Using the CCFH and the DDFH gives flexibility, since failure handling for the credit-control session and for one-time event direct debiting can be different. Mix and match, bestie 🌸
4.1. Service-Specific Rating Input and Interoperability
The Diameter Credit-Control application sets up the framework for credit-control 🧩 It gives generic credit-control mechanisms that support multiple service applications. Because of that, the credit-control application does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is out of scope for this generic mechanism 🙈
It's reasonable to expect a service level agreement between the providers of the credit-control client and the credit-control server. It would cover charging, services offered, roaming agreements, agreed-upon rating input (i.e., AVPs), and so on 📝 Lowkey a must-have for a smooth relationship 🫶
So, it's assumed that a Diameter Credit-Control server only provides service to Diameter Credit-Control clients that have agreed beforehand on the content of credit-control messages 🤝 Naturally, any arbitrary Diameter Credit-Control client can swap credit-control messages with any Diameter Credit-Control server. But there's a higher chance that unsupported services or AVPs show up in the credit-control message, and then the server rejects the request with an appropriate Result-Code 💀 Read the room before you send, periodt 💅
4.1.1. Specifying Rating Input AVPs
okay so bestie, there are two ways to hand rating input to the credit-control server 💅: either you use AVPs, or you tuck the rating input inside the Service-Parameter-Info AVP. the general principles for sending rating parameters go like this ✨
- Using AVPs:
A. The service SHOULD reuse existing AVPs if it can use AVPs defined in existing Diameter applications (e.g., [RFC7155] for network access services). [RFC6733] strongly recommends the reuse of existing AVPs. 🫶
For AVPs of type Enumerated, the service may require a new value to be defined. Allocation of new AVP values is done as specified in [RFC6733], Section 1.3. 🎀
B. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In this case, the procedures defined in [RFC6733] for creating new AVPs MUST be followed. 🦋
C. For services specific only to one vendor's implementation, a vendor-specific AVP code for private use can be used. Where a vendor-specific AVP is implemented by more than one vendor, allocation of global AVPs is encouraged instead; refer to [RFC6733]. 🌸
- The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). This method can be used to avoid unnecessary conversions from an existing data format to an AVP format. In this case, the rating input is embedded in the Service-Parameter-Info AVP as defined in Section 8.43. 🧚
New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability. 💖
4.1.2. Service-Specific Documentation ✨
okay so the service-specific rating input AVPs, plus the contents of the Service-Parameter-Info AVP or Service-Context-Id AVP (defined in Section 8.42), are NOT inside the scope of this document 🙈. to keep things interoperable, it is RECOMMENDED that the rating input and the values of the Service-Context-Id get coordinated through an informational RFC or some other permanent, readily available reference (ideally one from another cooperative standards body, e.g., 3GPP, the Open Mobile Alliance (OMA), or 3GPP2) 🍓. however, private services can be deployed under agreements between the credit-control server and client providers. in that case, vendor-specific AVPs can be used 🎀.
this spec, together with the service-specific docs above, governs the credit-control message 👑. service-specific documents (the ones that don't define new credit-control applications) decide which existing or new AVPs get used as rating input, so those AVPs have to be included in the Credit-Control-Request command by a Diameter Credit-Control client supporting that service as * [AVP] 💅. if the Service-Parameter-Info AVP is used, the service-specific document MUST specify the exact content of this Grouped AVP 🫶.
The Service-Context-Id AVP MUST be included at the command level of a Credit-Control-Request to identify the service-specific document that applies to the request. The specific service or rating-group the request relates to is uniquely identified by the combination of Service-Context-Id and Service-Identifier or rating-group. 🦋
4.1.3. Handling of Unsupported/Incorrect Rating Input ✨
okay bestie, Diameter Credit-Control implementations are REQUIRED to support mandatory rating-related AVPs defined in service-specific documents for the services they support, following the 'M' bit rules in [RFC6733] 💪.
if a rating input needed for the rating process is incorrect in the Credit-Control-Request, OR the credit-control server doesn't support the requested service context (identified by the Service-Context-Id AVP at the command level), the Credit-Control-Answer MUST contain the error code DIAMETER_RATING_FAILED 😭. a CCA message with this error MUST contain one or more Failed-AVP AVPs listing the missing and/or unsupported AVPs that caused the failure 🙈. and a Diameter Credit-Control client that gets DIAMETER_RATING_FAILED back for a request MUST NOT send similar requests in the future 💀.
4.1.4. RADIUS Vendor-Specific Rating Attributes ✨
when service-specific docs include RADIUS vendor-specific attributes that could be used as rating input, the rules in [RFC7155] for formatting the Diameter AVP MUST be followed 🌈.
for example, if the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-Id MUST be set to the IANA Vendor identification value 🧚. the Diameter AVP Data field contains only the attribute value of the RADIUS attribute 🫶.
5. Session-Based Credit-Control 👑
5.1. General Principles ✨
okay so for session-based credit-control, you need several interrogations: the first, the intermediate (optional), and the final 🔥. this is illustrated in Figures 3 and 4 (Sections 5.2.1 and 5.2.2) 🌸.
if the credit-control client does credit reservation before granting service to the end user, it MUST use several interrogations toward the credit-control server (i.e., session-based credit-control) 💅. in this case, the credit-control server MUST maintain the credit-control session state 🫶.
each credit-control session MUST have a globally unique Session-Id as defined in [RFC6733]; this Session-Id MUST NOT be changed during the lifetime of a credit-control session 🔒✨.
certain applications need multiple credit-control sub-sessions 🦋. these apps send messages with a constant Session-Id AVP but a different CC-Sub-Session-Id AVP. if several credit sub-sessions get used, all sub-sessions MUST be closed separately before the main session is closed, so that units per sub-session can be reported 💖. the absence of the CC-Sub-Session-Id AVP implies that no sub-sessions are in use 🙈.
note that the Service Element might send a service-specific re-authorization message to the AAA server because the authorization lifetime expired during an ongoing credit-control session 🧚. however, the service-specific re-authorization does NOT influence the credit authorization that's ongoing between the credit-control client and server, because credit authorization is controlled by the burning rate of the granted quota 🔥.
if service-specific re-authorization fails, the user will be disconnected, and the credit-control client MUST send a final interrogation to the credit-control server 😭.
the Diameter Credit-Control server may try to control the validity time of the granted quota and/or the production of intermediate interrogations. so it MAY include the Validity-Time AVP in the Answer message to the credit-control client 🍓. upon expiration of the Validity-Time, the credit-control client MUST generate a credit-control update request and report the used quota to the credit-control server 💅. it's up to the credit-control server to determine the Validity-Time value used for consumption of the granted service unit(s) (G-S-U) ✨. if the Validity-Time is used, its value SHOULD be given as input to set the session supervision timer Tcc (the session supervision timer MAY be set to two times the value of the Validity-Time, as defined in Section 13) 🎀. since credit-control update requests are also produced at the expiry of granted service units and/or for mid-session service events, leaving out Validity-Time does NOT mean that intermediate interrogation for the purpose of credit-control isn't performed 👑.
5.1.1. Basic Support for Tariff Time Change ✨
the Diameter Credit-Control server and client MAY optionally support a tariff change mechanism 🦋. the server may include a Tariff-Time-Change AVP in the Answer message. note that the granted units should be allocated based on the worst-case scenario, so the overall reported used units never exceed the credit reservation 💀. for example, if a tariff change is coming and the new rate is higher, the allocation should be given so it doesn't exceed the credit, assuming all of it gets used after the tariff changed 🌈.
when the Diameter Credit-Control client reports used units and a tariff change happened during the reporting period, the client MUST separately itemize the units used before and after the tariff change 🫶. if the client can't tell whether units straddling the tariff change were used before or after it, the credit-control client MUST itemize those units in a third category 🧚.
if a client doesn't support the tariff change mechanism and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit-control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP 😭.
for time-based services, the quota gets consumed at the rate of real time passing (ignoring leap seconds). that is, precisely 1 second of quota is consumed per second of real time 🕐. when credit resources are allocated, the server already knows how many units will be consumed before the tariff time change and how many will be consumed afterward. similarly, the server can work out the units consumed at the "before" rate and the units consumed at the "afterward" rate if the end user closes the session before the allotted quota is used up 💜. there's no need for extra traffic between the client and server for tariff time changes on continuous time-based service 🙌. so the tariff change mechanism is NOT used for such services 🙅♀️. for time-based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used 🍓.
5.1.2. Credit-Control for Multiple Services within a (Sub-)Session ✨
okay so bestie, this is where things get spicy 🌶️💅. When multiple services are running inside the same user session and each service (or group of services) has a different cost, you have to do credit-control for each service independently. 🫶 If you try to do that with credit-control sub-sessions, you end up with way more signaling and way more resources burned on both the client and the server. Not it. 😭
Picture this: during one network access session, the end user is hopping between several HTTP-based services, and each one could be charged differently. 🌈 The network-access stuff, like Quality of Service (QoS), is shared by everything riding on the access bearer, but the cost of that bearer can change depending on what's inside it. ✨
So to do this properly, the credit-control application lets you do independent credit-control of multiple services inside a single credit-control (sub-)session. 🦋 You get this by including the optional Multiple-Services-Credit-Control AVP in Credit-Control-Request/Credit-Control-Answer messages. 🎀 You can request and allocate resources as a credit pool that's shared between multiple services. You can also group services into rating-groups for even more aggregation. 🍓 And yes, you can request and allocate quotas on a per-service basis too. 💖
Here's the cute part: when quotas get allocated to a pool through the Multiple-Services-Credit-Control AVP, each quota is still its own independent object. It can be re-authorized independently whenever it wants. 🧚 Quotas can also get their own result codes, validity times, and Final-Unit-Indication AVP values or QoS-Final-Unit-Indication AVP values. Main character energy 👑.
A rating-group is a set of services that share a Service-Identifier and are subject to the same cost and rating type (for example, $0.1/minute). 💜 The Service Element is assumed to be handed rating-groups, service-identifiers, and their associated parameters that define what gets metered. That metering happens outside the scope of this spec. 🙈 (Examples of service-identifier parameters are IP 5-tuples and HTTP URLs.) Service-identifiers let you authorize credit per service and report usage itemized per service. ✨
It's totally up to the credit-control server whether it authorizes credit for one or more services or for the whole rating-group. 🌸 Still, the client SHOULD always report used units at the finest supported level of granularity. 💅 If a quota goes to a rating-group, every service in that group draws from that quota. 🫶
Here's a little picture of how it all fits together. 🦋
Diameter Credit-Control (Sub-)Session
|
+------------+-----------+-------------+--------------- +
| | | | |
Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
\ / \ / /
\ / \ / /
\ / Rating-Group 1.......Rating-Group n
\ / | |
Quota ---------------Quota Quota
| / |
| / |
Credit Pool Credit Pool
Figure 2: Multiple-Service (Sub-)Session Exampleokay, here's the important bit 🚨. If you're doing independent credit-control of multiple services, the Validity-Time AVP and the Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP SHOULD be present, either inside the Multiple-Services-Credit-Control AVP(s) or at the command level as single AVPs. ✨ The Result-Code AVP MAY show up both at the command level and inside the Multiple-Services-Credit-Control AVP. 🎀 But if the command-level Result-Code AVP says something other than SUCCESS, it takes precedence over anything in the Multiple-Services-Credit-Control AVP. 🙅♀️
Now the client MUST indicate support for independent credit-control of multiple services within a (sub-)session by including the Multiple-Services-Indicator AVP in the first interrogation. 🔥 And if a credit-control server doesn't support this feature, it MUST treat the Multiple-Services-Indicator AVP and any received Multiple-Services-Credit-Control AVPs as invalid AVPs. 💀
If the client said it supports independent credit-control of multiple services, then a server that wants to use the feature MUST return the granted units inside the Multiple-Services-Credit-Control AVP that's tied to the matching service-identifier and/or rating-group. 👑
Now, pooling is the whole point of avoiding credit fragmentation. 😭 Nobody wants a bunch of parallel, tiny credit reservations clogging up the same account, and nobody wants the server doing extra work either. So you can provide service units as a pool that applies to multiple services or rating-groups. 🧚 To do that, you give the units as a quota for a particular service or rating-group in the Multiple-Services-Credit-Control AVP, and you also include a reference to a credit pool for that unit type. 🦋
That reference includes a multiplier, derived from the rating parameter, that converts service units of one specific type into the abstract service units in the pool. 🌈 For example, if the rating parameter for service 1 is $1/MB and the rating parameter for service 2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2. 💖
Let's do the math, bestie 🧮. If (1) S is the total service units in the pool, (2) M1, M2, ..., Mn are the multipliers for services 1, 2, ..., n, and (3) C1, C2, ..., Cn are the used resources within the session, then the pool's credit is used up and re-authorization MUST be sought when:
C1*M1 + C2*M2 + ... + Cn*Mn >= SThe total credit in the pool, S, is worked out from the quotas that are currently allocated to the pool, like this:
S = Q1*M1 + Q2*M2 + ... + Qn*MnIf services or rating-groups get added to or removed from the pool, the total credit gets adjusted to match. 🫶 Quick heads-up: when services or rating-groups are removed, the value you take out is the consumed one (that's Cx*Mx). 🙈
Re-authorizations for an individual service or rating-group can happen at any time. 🌸 For example, that's when a "non-pooled" quota runs out or the Validity-Time expires. ⭐
Here's a fun one 🎀. When multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same G-S-U-Pool-Identifier show up inside a Multiple-Services-Credit-Control AVP (Section 8.16) alongside the Granted-Service-Unit AVP, they MUST have different CC-Unit-Type values, and they all draw from the credit pool separately. 💅 So if you've got one multiplier for time (M1t) and one for volume (M1v), the used resources from the pool add up to C1t*M1t + C1v*M1v, where C1t is the time unit and C1v is the volume unit. ✨
And if service units come inside a Multiple-Services-Credit-Control AVP without a matching G-S-U-Pool-Reference AVP, those units are handled on their own. 🦋 They're independent from any credit pools and from any other services or rating-groups in the session. 🌷
The "credit pool" idea is basically the best tool for avoiding the over-reservation effect of the basic single-quota tariff time change mechanism (Section 5.1.1). 🌈 So Diameter Credit-Control clients and servers that do independent credit-control of multiple services SHOULD use the credit pool concept when they handle a tariff time change. 💜 The server SHOULD put both the Tariff-Time-Change AVP and the Tariff-Change-Usage AVP into two quota allocations in the Answer message (that's two instances of the Multiple-Services-Credit-Control AVP). 🧚 One grant is for use before the potential tariff change, and the second is for use after it. 🫶 Both granted unit quotas MUST contain the same Service-Identifier and/or rating-group. 🔥 This dual-quota trick makes sure the total reported used units can never go over the credit reservation. 👑 And the client reports used units from before and after the tariff change in one single instance of the Multiple-Services-Credit-Control AVP. ✨
Failure handling for credit-control sessions is defined in Section 5.7 and shown in the basic credit-control state machines in Section 7. 💅 Clients and servers doing independent credit-control of multiple services in a (sub-)session MUST make sure failure handling and general behavior are fully consistent with Sections 5.7 and 7, while still handling parallel ongoing credit re-authorization within a (sub-)session. 😭 That's why it's RECOMMENDED that Diameter Credit-Control clients keep a PendingU message queue (Section 7) and restart the Tx timer (Section 13) every single time a CCR message with the value UPDATE_REQUEST gets sent while they're in PendingU state. 🎀 When answers to all the pending messages arrive, the state machine moves to Open state and the Tx timer stops. 🌸 And if a problem gets detected and handled per Section 5.7, all the ongoing services are affected. For example, failing over to a backup server hits every CCR message in the PendingU queue. 🙈
One more thing, and it's a big one 💖. The client may send CCR messages with the value UPDATE_REQUEST while it's in PendingU state, meaning it doesn't wait for an answer to the ongoing credit re-authorization. 🦋 So the gap between those requests can be super short, and the server might not have received the earlier request(s) yet. 🧚 That means the server may get requests out of sequence, and in this case it SHOULD NOT treat that as an error. 🫶 Just return a proper answer to each of those requests. ✨🌈
5.2. First Interrogation ✨
Okay so when session-based credit-control is required (like when the authentication server says "hey, this is a prepaid user" 💸), the first interrogation MUST be sent before the Diameter Credit-Control client lets any service events happen for the end user. No exceptions, bestie 🙅♀️ The CC-Request-Type AVP gets set to INITIAL_REQUEST in the request message.
If the client knows what the service event costs (a content server delivering ringing tones might, for example 🎶), the monetary amount goes in the Requested-Service-Unit AVP. If the client doesn't know the cost, the Requested-Service-Unit AVP MAY contain the number of requested service events instead. When Multiple-Services-Credit-Control is used, it MUST contain the Requested-Service-Unit AVP to show that the quota for the associated service/rating-group is being asked for. With multiple services, the Service-Identifier AVP or the Rating-Group AVP inside Multiple-Services-Credit-Control always tells you which service we're talking about 🧚. Extra service event info that needs rating MAY be sent as service-specific AVPs, or MAY be sent inside the Service-Parameter-Info AVP at the command level. And the Service-Context-Id AVP tells you which service-specific document applies to the request 📜.
The Event-Timestamp AVP SHOULD be included in the request. It holds the time the service event was requested in the Service Element ⏰. The Subscription-Id AVP or the Subscription-Id-Extension AVP SHOULD be included too, so the credit-control server knows who the end user is 🫶. The credit-control client MAY also include the User-Equipment-Info AVP or the User-Equipment-Info-Extension AVP, so the server gets a hint about what kind of device the end user is on and what it can do 📱. How the server uses that info is outside the scope of this document, so that's a server thing, not a us thing 🤷♀️.
The credit-control server SHOULD rate the service event and make a credit reservation from the end user's account that covers the cost. If the type of the Requested-Service-Unit AVP is "money", there's no rating needed, but the matching monetary amount still gets reserved from the end user's account 💰.
The credit-control server sends back the Granted-Service-Unit AVP in the Answer message. This tells the Diameter Credit-Control client how many service units it can give the end user until a new Credit-Control-Request MUST be sent to the credit-control server. If several unit types show up in the Answer message, the credit-control client MUST handle each unit type separately 🧩. The type of the Granted-Service-Unit AVP can be time, volume, service-specific, or money, depending on the service event. The unit type(s) SHOULD NOT be changed within an ongoing credit-control session, so don't switch things up mid-call, bestie 🙅♀️.
There MUST be a maximum of one instance of the same unit type in one Answer message. BUT (and this is a very cute exception 🎀), if multiple quotas get sent to the credit-control client in Multiple-Services-Credit-Control AVPs, you can have two instances of the same unit type tied to one service-identifier/rating-group. This usually happens when a tariff time change is coming up and the credit-control server wants to tell apart the quota before the change from the quota after it ⏳.
If the credit-control server decides no further control is needed for the service, it MAY include a result code saying that credit-control is not applicable (say, the service is totally free 🎁). At the command level, that result code means the credit-control session is to be terminated 🛑.
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP, to say the Answer message has the final units for the service 🏁. Once the end user has used up those units, the Diameter Credit-Control client MUST behave as described in Section 5.6. Main character energy for the end of the session, fr 💅.
This document defines two different ways to do the first interrogation, for different network architectures 🦋. The first way uses credit-control messages after the user's authorization and authentication happen. The second way uses (1) service-specific authorization messages to do the first interrogation during the user's authorization/authentication phase, and (2) credit-control messages for the intermediate and final interrogations. If a credit-control client supports both methods, deciding which one to use SHOULD be configurable ⚙️.
In service environments like NAS, it's desired to do the first interrogation as part of the authorization/authentication process, for the sake of protocol efficiency 🚀. Further credit authorizations after that first interrogation are done with the credit-control commands defined in this specification. Credit-control clients working in the environments mentioned in this document SHOULD support this method. If the credit-control server and the AAA server are separate physical entities, the Service Element sends the request messages to the AAA server, which then either issues an appropriate request itself or proxies the received request forward to the credit-control server 📬.
In other service environments, like the 3GPP network and some SIP scenarios, there's a big decoupling between registration/access to the network and the actual service request 🧁. The authentication/authorization happens once during registration/access and is NOT run for every service event the subscriber asks for. So in these environments, it makes more sense to do the first interrogation after the user has been authenticated and authorized. The first, intermediate, and final interrogations all run with the credit-control commands defined in this specification.
Other IETF standards, or standards from other standardization bodies, may define the most suitable method for their own architectures 🌈.
5.2.1. First Interrogation after Authorization and Authentication
The Diameter Credit-Control client in the Service Element might get info from the authorization server about whether credit-control is required, based on what it knows about the end user 👀. If credit-control is required, the credit-control server has to be contacted before service delivery starts for the end user, no skipping ahead 🙅♀️. The accounting protocol and the credit-control protocol can run in parallel. The authorization server might also decide whether the parallel accounting stream is needed 🧾.
Figure 3 shows the case where both protocols run in parallel and the Service Element sends credit-control messages straight to the credit-control server. There are more credit-control sequence examples in Appendix A, so go peek if you're curious 🔍.
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Registration | AA-Request/Answer(accounting, CC, or both)|
|<----------------->|<------------------>| |
| : | | |
| : | | |
| Service Request | | |
|------------------>| | |
| | CCR(Initial, Credit-Control AVPs) |
| +|------------------------------------------>|
| CC stream|| | CCA(Granted-Units)|
| +|<------------------------------------------|
| Service Delivery | | |
|<----------------->| ACR(start, Accounting AVPs) |
| : |------------------->|+ |
| : | ACA || Accounting stream |
| |<-------------------|+ |
| : | | |
| : | | |
| | CCR(Update, Used-Units) |
| |------------------------------------------>|
| | | CCA(Granted-Units)|
| |<------------------------------------------|
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination, Used-Units) |
| |------------------------------------------>|
| | | CCA |
| |<------------------------------------------|
| | ACR(stop) | |
| |------------------->| |
| | ACA | |
| |<-------------------| |
ACR: Accounting-Request
ACA: Accounting-Answer
Figure 3: Protocol Example with First Interrogation
after User's Authorization/Authentication5.2.2. First Interrogation Included with Authorization Messages
okay bestie, so this is the part where the Credit-Control client and the authorization/authentication client team up 🫶 to build the AA-Request. The Diameter Credit-Control client in the Service Element MUST actively co-operate with the authorization/authentication client in the construction of the AA-Request by adding appropriate Credit-Control AVPs. ✨ The credit-control client MUST add the Credit-Control AVP to indicate credit-control capabilities and MAY add other relevant credit-control-specific AVPs to the proper authorization/authentication command to perform the first interrogation toward the home Diameter AAA server. 💅 The Auth-Application-Id is set to the appropriate value, as defined in the service-specific authorization/authentication application document (e.g., [RFC7155] [RFC4004]). The home Diameter AAA server authenticates/authorizes the subscriber and determines whether credit-control is required. 🎀
If credit-control is not required for the subscriber, the home Diameter AAA server will respond as usual, with an appropriate AA-Answer message. 🌸 If credit-control is required for the subscriber and the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was present in the authorization request, the home AAA server MUST contact the credit-control server to perform the first interrogation. 😭 If credit-control is required for the subscriber and the Credit-Control AVP was not present in the authorization request, the home AAA server MUST send an authorization reject Answer message. 💀
The Diameter AAA server supporting credit-control is required to send the Credit-Control-Request command (CCR) defined in this document to the credit-control server. 🦋 The Diameter AAA server populates the CCR based on service-specific AVPs used for input to the rating process, and possibly on Credit-Control AVPs received in the AA-Request. The credit-control server will reserve money from the user's account, will rate the request, and will send a Credit-Control-Answer message to the home Diameter AAA server. 💖 The Answer message includes the Granted-Service-Unit AVP(s) and MAY include other credit-control-specific AVPs, as appropriate. Additionally, the credit-control server MAY set the Validity-Time and MAY include the CCFH and the DDFH to determine what to do if the sending of credit-control messages to the credit-control server has been temporarily prevented. 🧚
Upon receiving the Credit-Control-Answer message from the credit-control server, the home Diameter AAA server will populate the AA-Answer with the received Credit-Control AVPs and with the appropriate service attributes according to the authorization/authentication-specific application (e.g., [RFC7155] [RFC4004]). It will then forward the packet to the credit-control client. If the home Diameter AAA server receives a credit-control reject message, it will simply generate an appropriate authorization reject message to the credit-control client, including the credit-control-specific error code. 🙈
In this model, the credit-control client sends further credit-control messages to the credit-control server via the home Diameter AAA server. Upon receiving a successful authorization Answer message with the Granted-Service-Unit AVP(s), the credit-control client will grant the service to the end user and will generate an intermediate Credit-Control-Request, if required, by using credit-control commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 (for details regarding how to produce a unique value for the CC-Request-Number AVP, see Section 8.2). 🔥
If service-specific re-authorization is performed (i.e., the authorization lifetime expires), the credit-control client MUST add to the service-specific re-authorization request the Credit-Control AVP with a value set to RE_AUTHORIZATION to indicate that the credit-control server MUST NOT be contacted. 🍓 When session-based credit-control is used for the subscriber, a constant credit-control message stream flows through the home Diameter AAA server. The home Diameter AAA server can make use of this credit-control message flow to deduce that the user's activity is ongoing; therefore, it is recommended to set the authorization lifetime to a reasonably high value when credit-control is used for the subscriber. 👑
In this scenario, the home Diameter AAA server MUST advertise support for the credit-control application to its peers during the capability exchange process. ⭐
Figure 4 illustrates the use of authorization/authentication messages to perform the first interrogation. The parallel accounting stream is not shown in the figure. 🌈
Diameter
Service Element AAA Server CC Server
End User (CC Client)
| Service Request | AA-Request (CC AVPs) | |
|------------------>|--------------------->| |
| | | CCR(Initial, CC AVPs)
| | |-------------------->|
| | | CCA(Granted-Units)|
| | |<--------------------|
| | AA-Answer(Granted-Units) |
| Service Delivery |<---------------------| |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update, Used-Units) |
| |--------------------->| CCR(Update, Used-Units)
| | |-------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<--------------------|
| |<---------------------| |
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination, Used-Units) |
| |--------------------->| CCR(Term., Used-Units)
| | |-------------------->|
| | | CCA |
| | CCA |<--------------------|
| |<---------------------| |Figure 4: Protocol Example with Use of Authorization Messages for the First Interrogation
5.3. Intermediate Interrogation ✨
okay so this one is all about when the client needs to check back in with the server for more units 🦋 When all the granted service units for one unit type are spent by the end user or the Validity-Time has expired, the Diameter Credit-Control client MUST send a new Credit-Control-Request to the credit-control server. 💜 In the event that credit-control for multiple services is applied in one credit-control session (i.e., units associated to Service-Identifier(s) or the rating-group are granted), a new Credit-Control-Request MUST be sent to the credit-control server when the credit reservation has been wholly consumed or upon expiration of the Validity-Time. It is always up to the Diameter Credit-Control client to send a new request well in advance of the expiration of the previous request in order to avoid interruption in the Service Element. 😭 Even if the granted service units reserved by the credit-control server have not been spent upon expiration of the Validity-Time, the Diameter Credit-Control client MUST send a new Credit-Control-Request to the credit-control server. 🙈
There can also be mid-session service events, which might affect the rating of the current service events. 🌸 In this case, a spontaneous update (a new Credit-Control-Request) SHOULD be sent, including information related to the service event, even if all the granted service units have not been spent or the Validity-Time has not expired. ✨
When the used units are reported to the credit-control server, the credit-control client will not have any units in its possession before new granted units are received from the credit-control server. When the new granted units are received, these units apply from the point where the measurement of the reported used units stopped. Where independent credit-control of multiple services is supported, this process may be executed for one or more services, a single rating-group, or a pool within the (sub-)session. 🧚
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP or Subscription-Id-Extension AVP SHOULD be included in the intermediate message to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service-specific document applicable to the request. 💖
The Requested-Service-Unit AVP MAY contain the new amount of requested service units. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP if a new quota is requested for the associated service/rating-group. The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. The same unit types used in the previous message SHOULD be used. If several unit types were included in the previous Answer message, the used service units for each unit type MUST be reported. 👑
The Event-Timestamp AVP SHOULD be included in the request and contains the time of the event that triggered the sending of the new Credit-Control-Request. 🍓
The credit-control server MUST deduct the used amount from the end user's account. It MAY rate the new request and make a new credit reservation from the end user's account that covers the cost of the requested service event. 💅
A Credit-Control-Answer message with the CC-Request-Type AVP set to the value UPDATE_REQUEST MAY include the Cost-Information AVP containing the accumulated cost estimation for the session, without taking any credit reservations into account. 🌈
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that the Answer message contains the final units for the service. After the end user has consumed these units, the Diameter Credit-Control client MUST behave as described in Section 5.6. 🔥
There can be several intermediate interrogations within a session. 🫶
5.4. Final Interrogation
okay bestie, when the end user ends the service session (or graceful service termination from Section 5.6 happens), the Diameter Credit-Control client MUST send one last Credit-Control-Request to the credit-control server 💅 The CC-Request-Type gets set to TERMINATION_REQUEST, and Service-Context-Id tells you which service-specific document this request is about 🎀
The Event-Timestamp AVP SHOULD be included, and it holds the time the session was terminated ⏰
The Used-Service-Unit AVP is the tally of used units, counted from when the service became active or, if interim interrogations are running, from when the last measurement ended 📊 If several unit types were in the previous Answer message, the used service units for each unit type MUST be reported. no skipping, periodt 💀
After the final interrogation, the credit-control server MUST refund the reserved credit that wasn't used to the end user's account and deduct the used monetary amount from it 💸
A Credit-Control-Answer with CC-Request-Type set to TERMINATION_REQUEST MAY include the Cost-Information AVP, which has the estimated total cost for that session 🧾
Now the logged-off case 👀 If the user logs off during an ongoing credit-control session, or becomes logged off for some other reason (like a final-unit indication causing a logoff under local policy), the Service Element may, according to application-specific policy, send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [RFC6733]. Figure 5 shows the situation where the final-unit indication logs the user off once the final granted units are used up and the STR gets generated 🦋
The Diameter AAA server answers with a Session-Termination-Answer (STA) 🫶
Service Element AAA Server CC Server
End User (CC Client)
| Service Delivery | | |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update, Used-Units) |
| |-------------------->| CCR(Update, Used-Units)
| | |-------------------->|
| | CCA(Final-Unit, Terminate)
| CCA(Final-Unit, Terminate)|<--------------------|
| |<--------------------| |
| : | | |
| : | | |
| Disconnect user | | |
|<------------------| CCR(Termination, Used-Units) |
| |-------------------->| CCR(Term., Used-Units)
| | |-------------------->|
| | | CCA |
| | CCA |<--------------------|
| |<--------------------| |
| | STR | |
| |-------------------->| |
| | STA | |
| |<--------------------| |
Figure 5: User Disconnected Due to Exhausted Account5.5. Server-Initiated Credit Re-authorization
the Diameter Credit-Control application supports server-initiated re-authorization, which is giving the server main character energy 👑 The credit-control server MAY optionally start the credit re-authorization by sending a Re-Auth-Request (RAR) as defined in the Diameter base protocol [RFC6733]. In that RAR, Auth-Application-Id is set to 4 to mean "Diameter Credit Control", and Re-Auth-Request-Type is set to AUTHORIZE_ONLY 🌸
Section 5.1.2 is where the feature lives for enabling credit-control across multiple services inside one (sub-)session, so the server can authorize credit usage at a different level of granularity 🧚 The server can also hand out credit resources to multiple services or rating-groups as a pool (see Section 5.1.2 for the details and definitions). So based on its service logic and what it knows about the ongoing session, the server can ask for re-authorization of a whole (sub-)session, a single credit pool, a single service, or a single rating-group 🍓 To target a credit pool, the RAR includes the G-S-U-Pool-Identifier AVP for the affected pool. To target a service or a rating-group, it includes the Service-Identifier AVP or the Rating-Group AVP, respectively. To re-authorize all the ongoing services within the (sub-)session, the RAR includes none of those AVPs ✨
If a credit re-authorization isn't already happening (aka the credit-control session is in Open state), a credit-control client that gets an RAR with a Session-Id matching a currently active credit-control session MUST acknowledge it by sending a Re-Auth-Answer (RAA) and MUST start the credit re-authorization toward the server by sending a Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST 🔥 The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA to say that another message (a CCR with UPDATE_REQUEST) is needed to finish the procedure. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request. Also, the end user doesn't need to get prompted for this, because the re-authorization is totally transparent to them. It happens only between the credit-control client and the credit-control server 🙈
When multiple services are in a user's session, the procedure above runs at whatever granularity the server asked for in the RAR 🦋
Now the RAR-CCR collision situation 💅 If a credit re-authorization is already ongoing when the RAR shows up, the credit-control client successfully acknowledges the request but does NOT start a new one. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA to show that a re-authorization is already in progress (aka the client was in PendingU state when the RAR came in). The credit-control server SHOULD process the Credit-Control-Request as if it was received in answer to the server-initiated re-authorization, and should consider that server-initiated re-authorization successful once the RAA is received 🫶
When multiple services are supported in a user's session, the server may ask for re-authorization of a credit pool (or of the (sub-)session) while a re-authorization is already going for some of the services or rating-groups 🌈 In that case, the client acknowledges the request with an RAA and MUST send a new Credit-Control-Request to re-authorize the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA to indicate that an additional message (a CCR with UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and sends an appropriate answer to both of them ⭐
Last bit: all of the above is enabled for each of the possibly active Diameter Credit-Control sub-sessions. The server MAY request re-authorization for an active sub-session by including the CC-Sub-Session-Id AVP in the RAR, in addition to the Session-Id AVP 🎀
5.6. Graceful Service Termination ✨
Okay so bestie, picture this: the user's account runs out of money 💸 and suddenly they can't rack up any more chargeable events. Rude 😭. BUT the home service provider might still let them into something like a service portal where they can top up, and they get to use that for a limited time 🫶. How long that lasts usually depends on the home service provider policy.
This section defines the optional graceful service termination feature 🦋. This feature MAY be supported by the credit-control server. Credit-control client implementations MUST support the Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units 💅.
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, you can use graceful service termination for each service/rating-group on its own 🎀. The process in the subsections below applies to whichever service/rating-group the server asks for, obvi.
In some service environments (e.g., NAS), graceful service termination can redirect the subscriber to a service portal for balance refill or other offers from the home service provider 🌸. The process installs packet filters so the user can only talk to and from the specified destinations. Any IP packets that don't match the filters get dropped or, possibly, redirected to the portal. The user may also get a notification explaining why their access is limited. These actions can be signaled explicitly from the server to the client, or configured "per service" at the client. Explicitly signaled redirection or restriction instructions always take precedence over configured ones 👑.
Graceful termination can also connect the prepaid user to a top-up server that plays an announcement and prompts them to replenish ✨. Here the credit-control server only sends the address of the top-up server where the prepaid user shall be connected after the final granted units have been used up. There's an example of this in Appendix A.7 🧚.
The credit-control server MAY initiate graceful service termination by including the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP in the Credit-Control-Answer, to signal that the message contains the final units for the service 🔥.
When the credit-control client receives the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP in the answer from the server, what it does depends on the value in the Final-Unit-Action AVP. The server may request TERMINATE, REDIRECT, or RESTRICT_ACCESS 🙈.
Figure 6 shows the procedure covered in the subsections below. Very flowchart energy 💜.
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Delivery | | |
|<----------------->| | |
| |CCR(Update, Used-Units) |
| |-------------------->|CCR(Update, Used-Units)
| : | |-------------------->|
| : | |CCA(Final-Unit, Action)
| : | |<--------------------|
| |CCA(Final-Unit, Action) |
| |<--------------------| |
| | | |
| : | | |
| : | | |
| /////////////// |CCR(Update, Used-Units) |
|/Final Units End/->|-------------------->|CCR(Update, Used-Units)
|/Action and // | |-------------------->|
|/Restrictions // | | CCA(Validity-Time)|
|/Start // | CCA(Validity-Time)|<--------------------|
| ///////////// |<--------------------| |
| : | | |
| : | | |
| Replenish account | +-------+ |
|<--------------------------------------------->|Account| |
| | | +-------+ |
| | | RAR |
| + | RAR |<====================|
| | |<====================| |
| | | RAA | |
| ///////////// | |====================>| RAA |
| /If supported / | | CCR(Update) |====================>|
| /by CC Server/ | |====================>| CCR(Update) |
| ///////////// | | |====================>|
| | | | CCA(Granted-Units)|
| | | CCA(Granted-Units)|<====================|
| Restrictions ->+ |<====================| |
| removed | | |
| : | | |
| OR | CCR(Update) | |
| Validity-Time ->|-------------------->| CCR(Update) |
| expires | |-------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<--------------------|
| Restrictions ->|<--------------------| |
| removed | | |Figure 6: Optional Graceful Service Termination Procedure
In addition, the credit-control server MAY reply with the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP holding a Granted-Service-Unit (G-S-U) with a zero grant 🧊. That means the service SHOULD be terminated immediately, and no further reporting is required. Figure 7 shows the graceful service termination procedure that kicks in right after a zero grant.
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Delivery | | |
|<----------------->| | |
| |CCR(Update, Used-Units) |
| |--------------------->|CCR(Update, Used-Units)
| : | |-------------------->|
| : | |CCA(Final-Unit, Action,
| : | | Zero G-S-U)
| : | |<--------------------|
| |CCA(Final-Unit, Action, |
| | Zero G-S-U) |
| |<---------------------| |
| /////////////// | | |
|/Action and // | | |
|/Restrictions // | | |
|/Start // | | |
| ///////////// | | |
| : | | |
| : | | |Figure 7: Optional Immediate Graceful Service Termination Procedure
5.6.1. Terminate Action
Final-Unit-Indication or QoS-Final-Unit-Indication with Final-Unit-Action set to TERMINATE doesn't include any other info 🙃. When the subscriber has used up the final granted units, the Service Element MUST terminate the service. This is the default handling whenever the credit-control client gets an unsupported Final-Unit-Action value. It MUST be supported by all the Diameter Credit-Control client implementations conforming to this spec, so no skipping it 💖.
A final Credit-Control-Request message MUST be sent to the credit-control server if Final-Unit-Indication or QoS-Final-Unit-Indication indicating action TERMINATE was present at the command level 📨. The CC-Request-Type AVP in that request is set to TERMINATION_REQUEST ✨.
5.6.2. Redirect Action 🦋
okay so the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT tells the Service Element helping out with this action that, once the final granted units are all used up, the user MUST be redirected to the address in the Redirect-Server AVP or the Redirect-Server-Extension AVP. here's how it goes 💅
The credit-control server sends the Redirect-Server AVP or the Redirect-Server-Extension AVP in the Credit-Control-Answer message. In that case, the Service Element MUST redirect or connect the user to the destination in that AVP, if possible. When the end user gets redirected (using protocols other than Diameter) to that server, or gets connected to the top-up server, an additional authorization (and possibly authentication) may be needed before the subscriber can top up the account. ngl that whole scenario is out of scope for this spec 🙈
In addition to the Redirect-Server AVP or the Redirect-Server-Extension AVP, the credit-control server MAY include one or more Restriction-Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Id AVPs in the Credit-Control-Answer message. This lets the user reach other services, like zero-rated ones 🍓 In that case, the access device MUST treat all packets according to the Restriction-Filter-Rule AVPs, the Filter-Rule AVPs, and the rules referred to by the Filter-Id AVP. Once that treatment is applied, all traffic that has not been dropped or already forwarded MUST be redirected to the destination in the Redirect-Server AVP or the Redirect-Server-Extension AVP.
An entity other than the credit-control server may provision the access device with appropriate IP packet filters to use alongside the Diameter Credit-Control application. This case is considered in Section 5.6.3.
When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The point of this interrogation is to tell the credit-control server that the specified action started and to report the used units. The credit-control server MUST deduct the used amount from the end user's account, but MUST NOT make a new credit reservation. The credit-control client, however, may send intermediate interrogations before all the final granted units have been consumed, for which rating and money reservation may be needed. For instance, that happens upon Validity-Time expiration or upon mid-session service events that affect the rating of the current service. So the credit-control client MUST NOT include any rating-related AVPs in the request sent once all the final granted units have been consumed. That's the signal to the server that (1) the requested final unit action started and (2) rating and money reservation are not required. (When the Multiple-Services-Credit-Control AVP is used, the Service-Identifier AVP or the Rating-Group AVP is included to indicate the services concerned.) Naturally, the Credit-Control-Answer message does not contain any granted service units and MUST include the Validity-Time AVP, so the credit-control client knows how long the subscriber can use network resources before a new intermediate interrogation goes to the server ⏰
At the expiry of Validity-Time, the credit-control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP, since there's no allotted quota to report 🫶 The credit-control server processes the request and MUST perform the credit reservation. If the subscriber did not replenish their account during this time, whether they get disconnected or get access to services not controlled by a credit-control server for an unlimited time depends on the home service provider policy. (Note: The latter option implies that the Service Element should not remove the restriction filters upon termination of the credit-control.) The server returns the appropriate Result-Code (see Section 9.1) in the Credit-Control-Answer message to carry out the policy-defined action. Otherwise, a new quota is returned, and the Service Element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit-control session and service session as usual. ✨
The credit-control client does not have to wait for the Validity-Time to expire. It may send a spontaneous update (a new Credit-Control-Request) if the Service Element can determine, for instance, that communication between the end user and the top-up server took place. An example of this case is given in Appendix A.8 (Figure 18). 🧚
Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when that first interrogation happens. In this case, the subscriber can be offered a chance to replenish the account and continue the service 💜 When the credit-control client receives (at either the session level or a service-specific level) a Final-Unit-Indication AVP or a QoS-Final-Unit-Indication AVP, together with Validity-Time AVPs but without a Granted-Service-Unit AVP, it immediately starts the graceful service termination process without sending any messages to the server. An example of this case is illustrated in Appendix A.8 (Figure 18). 🌸
5.6.3. Restrict Access Action 🔥
A Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS tells the device supporting this action that, once the final granted units are consumed, the user's access MUST be restricted according to the IP packet filters given in the Restriction-Filter-Rule AVP(s), or according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Restriction-Filter-Rule AVP or the Filter-Id AVP in the Final-Unit-Indication group AVP of the Credit-Control-Answer message.
A QoS-Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS tells the device supporting this action that, once the final granted units are consumed, the actions specified in the Filter-Rule AVP(s) MUST restrict the traffic according to the classifiers in those Filter-Rule AVP(s). If one or more Filter-Id AVPs are provided in the Credit-Control-Answer message, the credit-control client MUST restrict the traffic according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Filter-Rule AVP or the Filter-Id AVP in the QoS-Final-Unit-Indication group AVP of the Credit-Control-Answer message. 🦋
If both the Final-Unit-Indication AVP and the QoS-Final-Unit-Indication AVP exist in the Credit-Control-Answer message, a credit-control client that supports the QoS-Final-Unit-Indication AVP SHOULD follow the directives in the QoS-Final-Unit-Indication AVP and SHOULD ignore the Final-Unit-Indication AVP. 👑
An entity other than the credit-control server may provision the access device with appropriate IP packet filters to use alongside the Diameter Credit-Control application. Such an entity may, for instance, configure the access device with IP flows to be passed when the Diameter Credit-Control application indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP packets according to the filter rules that may have been received in the Credit-Control-Answer message, in addition to the rules that may have been configured by the other entity. However, when the user's account cannot cover the cost of the requested service, the action taken is the responsibility of the credit-control server that controls the prepaid subscriber.
If another entity working in conjunction with the Diameter Credit-Control application already provisions the access device with all the required filter rules for the end user, the credit-control server presumably need not send any additional filters. Therefore, it is RECOMMENDED that credit-control server implementations supporting graceful service termination be configurable for sending the Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, or none of the above. 💅
When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The credit-control client and the credit-control server process this intermediate interrogation and execute subsequent procedures, as specified in Section 5.6.2. 🌈
The credit-control server may initiate graceful service termination when replying with the action RESTRICT_ACCESS for the first interrogation. This is similar to the behavior specified in Section 5.6.2. ✨
5.6.4. Usage of the Server-Initiated Credit Re-authorization 💖
Once the subscriber replenishes the account, they presumably expect all the restrictions applied by the graceful service termination procedure to be removed immediately, and unlimited service access to be resumed. 🥹 For the best user experience, the credit-control server implementation MAY support the server-initiated credit re-authorization (see Section 5.5). In that case, upon the successful account top-up, the credit-control server sends the Re-Auth-Request (RAR) message to solicit the credit re-authorization. The credit-control client initiates the credit re-authorization by sending the Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included in the request, since there's no allotted quota to report. The Requested-Service-Unit AVP MAY be included in the request. After the credit-control client successfully receives the Credit-Control-Answer with a new Granted-Service-Unit AVP, all the possible restrictions activated for the purpose of graceful service termination MUST be removed in the Service Element. The credit-control session and the service session continue as usual. 🎀
5.7. Failure Procedures ✨
okay so this section is the "what do we do when everything goes sideways" section and honestly it's my favourite kind of drama 🙈 the CCFH (Credit-Control Failure Handling) decides how the credit-control client behaves when stuff breaks 💅 and it can come from three places: the Diameter home AAA server 🏠, the credit-control server 🖥️, or just being configured locally 🎀. the value from the home AAA server beats the local config (local config is lowkey the underdog here 🥲), and the CCFH sent in a Credit-Control-Answer always overrides whatever it had before. no cap, the server gets the final word 👑
the authorization server MAY include the Accounting-Realtime-Required AVP to decide what happens when sending accounting records to the accounting server has been temporarily blocked, as defined in [RFC6733] 💜. and it is RECOMMENDED that the client backs up its credit-control failure procedures with a backup accounting flow toward an accounting server 🫶. mixing the Accounting-Realtime-Required AVP with the CCFH lets you build different safety levels 🌈. for example, set CCFH to CONTINUE for the credit-control flow and Accounting-Realtime-Required to DELIVER_AND_GRANT for the accounting flow, and the service can still be granted to the end user even if the credit-control server connection is down 😭✨ as long as the accounting server can collect the accounting info and the accounting server and credit-control server are still talking to each other 🦋
ngl the credit-control app is all about real-time two-way chatter between the client and the server 💬 so alternative destinations and buffering of messages might not be enough when comms fail 💀. the credit-control server has to keep session state, so moving the message stream to a backup server needs a complicated context transfer solution 🍓. whether the stream gets moved mid-session depends on the CC-Session-Failover AVP 🔁. failover can happen at any point on the path between client and server if a transport failure is detected with a peer, as described in [RFC6733] 🌸. which means the credit-control server might get duplicate messages 👀. the server can spot duplicate or out-of-sequence messages using its session state machine (Section 7), the Session-Id AVP, and the CC-Request-Number AVP 🧚
if a failure happens during an ongoing session, the client may move the message stream to an alternative server, but only if the server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP 🦋. a secondary credit-control server name, received from the home Diameter AAA server or configured locally, can be used as the backup's address 🎀. if CC-Session-Failover is set to FAILOVER_NOT_SUPPORTED, the stream MUST NOT be moved to a backup server 🚫💖
for new sessions, failover to an alternative credit-control server SHOULD be performed, if possible 🌈. like, if the client can tell the primary server is unavailable, it can set up the new sessions with a possibly available secondary server ✨
the AAA transport profile [RFC3539] defines an application-layer watchdog algorithm that lets you fail over from a peer that has failed, controlled by a watchdog timer (Tw) (defined in [RFC3539]) 🐶. the recommended default initial value for Tw (Twinit) is 30 seconds ⏱️. Twinit can go as low as 6 seconds, BUT according to [RFC3539], setting it too low is likely to cause more duplicates and more spurious failover and failback attempts 😩. the Diameter base protocol [RFC6733] is shared by lots of different AAA applications running in the same Service Element 🏗️, so turning Twinit way down to suit real-time apps like Credit-Control will definitely cause those same problems 🙃. but prepaid users expect an answer in a reasonable time ⏳, so the Credit-Control client reacts faster than the base protocol would 🏃♀️💨. that's why this spec defines the Tx timer (Section 13) 🎀, which the client uses to supervise communication with the credit-control server ⏲️. when Tx expires, the client acts for the end user according to the CCFH 💅
when Tx expires, the client ALWAYS terminates the service if the CCFH is TERMINATE 💀. the session may only be moved to an alternative server if DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER comes back before Tx expires 🔁. so TERMINATE is NOT the vibe if you want proper failover 🙅♀️
if the CCFH is CONTINUE or RETRY_AND_TERMINATE, the service is granted to the end user when Tx expires 🥳. an Answer with granted units might still show up later if base protocol transport failover happened on the path to the server 📬. (the Twinit default is 3 times the recommended Tx timeout value 🧮). the client SHOULD grant the service, start monitoring resource usage, and wait for that possible late answer until the request times out (e.g., 120 seconds) ⏳💖. if the request fails and CC-Session-Failover is FAILOVER_NOT_SUPPORTED, the client terminates or continues the service depending on the CCFH, and MUST free all the reserved resources for the session 🧹. if DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY comes back, or the request times out, and CC-Session-Failover is FAILOVER_SUPPORTED, the client MAY send the request to a backup server if possible 🚀. if it gets a successful answer from the backup, it keeps the session going with that server 🫶. if the retransmitted request fails too, the client terminates or continues depending on the CCFH and MUST free all reserved resources 🧼
if a comms failure happens during graceful service termination, the Service Element SHOULD always terminate the ongoing service session 🛑
if the credit-control server detects a failure during an ongoing session, it terminates the session and returns the reserved units back to the end user's account 💰
the supervision session timer Tcc (Section 13) is what the server uses to supervise the session 👀
to support failover between servers, session and account state information SHOULD be transferred between the primary and secondary credit-control servers 🤝. implementations supporting session failover MUST also make sure duplicate or out-of-sequence messages are properly detected 🔍. how the servers talk to each other is an implementation issue and outside the scope of this spec 🙈✨
6. One-Time Event 🎀
okay so the one-time event is for when you DON'T need to keep any state on the Diameter Credit-Control server 🧠🚫, like just asking how much something costs 💸. it assumes the user was already authenticated and authorized beforehand 🔐
you can use it when the client wants to know the cost of a service event, or check the account balance without making any credit reservations 🧾. it can also refund service units to the user's account, or debit directly without reservations 💳. here's the flow in Figure 8 🦋
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 8: One-Time Eventin environments like the 3GPP architecture, the one-time event can be sent from the Service Element straight to the credit-control server 🚀✨
6.1. Service Price Inquiry 💸
the credit-control client might need to know the price of a service event 🤔. some services from application service providers might have prices the client doesn't know about, and the end user might want an estimate before requesting it 👀
a Diameter Credit-Control client asking for cost info MUST set the CC-Request-Type AVP to EVENT_REQUEST, include the Requested-Action AVP set to PRICE_ENQUIRY, and put the requested service event info in the Service-Identifier AVP in the Credit-Control-Request message 💅. extra service event info can go in service-specific AVPs or inside the Service-Parameter-Info AVP 🎀. the Service-Context-Id AVP says which service-specific document applies to the request 📄
the credit-control server works out the cost of the requested event, but it does NOT do any account-balance checks or credit reservations 🙅♀️💖
the estimated cost comes back to the client in the Cost-Information AVP in the Credit-Control-Answer message 🧾✨
6.2. Balance Checks 🧾
a Diameter Credit-Control client might just need to check that the end user's balance covers a service's cost, WITHOUT reserving any units from the account during the inquiry 🔍. this doesn't guarantee that credit will still be there when the client later asks for the debit in a separate request 😬
a Diameter Credit-Control client requesting a balance check MUST set the CC-Request-Type AVP to EVENT_REQUEST, include a Requested-Action AVP set to CHECK_BALANCE, and include either the Subscription-Id AVP or the Subscription-Id-Extension AVP so the credit-control server can identify the end user 🫶. the Service-Context-Id AVP says which service-specific document applies 📄
the credit-control server does the balance check, but makes NO credit reservations from the account 🌸
the result (ENOUGH_CREDIT/NO_CREDIT) comes back to the client in the Check-Balance-Result AVP in the Credit-Control-Answer message 🎉👑
6.3. Direct Debiting 💸
Okay so there are some service events where the service execution is always successful in the service environment, no cap 💅. The delay between the service invocation and the actual service delivery to the end user can be long enough that session-based credit-control would lead to unreasonably long credit-control sessions 🙈. In those 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 AVP is set to the value EVENT_REQUEST and the Requested-Action AVP is set to DIRECT_DEBITING 🎀. The Subscription-Id AVP or Subscription-Id-Extension AVP SHOULD be included so the credit-control server can identify the end user 💖. 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 that applies to the request 🧚.
If the client knows the cost of the service event, the Diameter Credit-Control client MAY include the monetary amount to be charged in the Requested-Service-Unit AVP 💰. If the client does not know the cost, the Requested-Service-Unit AVP MAY contain the number of requested service events instead 🔢. 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", there's no rating needed, but the corresponding monetary amount still gets deducted from the end user's account 🤑.
The credit-control server sends back 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. Its type can be time, volume, service-specific, or money, depending on the type of service event ⏳.
If the credit-control server decides that no credit-control is needed for the service, it can include a result code showing that credit-control is not applicable (for example, the service is free of charge) 🎉.
For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP, which holds the estimated total cost of the requested service 📊.
6.4. Refunds 🍓
Some services may refund service units to the end user's account, gaming services for example 🎮.
The credit-control client MUST set the CC-Request-Type AVP to the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the Credit-Control-Request message 🔁. The Subscription-Id AVP or Subscription-Id-Extension AVP SHOULD be included to identify the end user in the credit-control server 🫶. The Service-Context-Id AVP indicates the service-specific document that applies 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 service concerned 🎯. If the client doesn't know the monetary amount to be refunded, then along with the Service-Identifier AVP it MAY send service-specific AVPs or the Service-Parameter-Info AVP with extra service event information to be rated 🧾.
For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP, which holds the estimated monetary amount of refunded units 📈.
6.5. Failure Procedure 🚨
Failover to an alternative credit-control server is allowed for a one-time event, because the server isn't maintaining session states 🧠. For instance, if the credit-control client gets a protocol error of DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can resend 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 happen at any point along the path between the credit-control client and the credit-control server if a transport failure is detected with a peer, as described in [RFC6733] 🔌. 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 [RFC6733], Appendix C 📚.
When the credit-control client detects a communication failure with the credit-control server, what it does next depends on the requested action 🫣. The Tx timer (as defined in Section 13) is used in the credit-control client to supervise communication with the credit-control server ⏱️.
If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a 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 the address of the backup server 🗝️.
If the requested action is DIRECT_DEBITING, the 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 messages, 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 values 👑.
If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the service if, after a possible retransmission attempt to an alternative credit-control server, it can eventually determine 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 credit-control application-level non-volatile storage 💾. (Note that resending 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 [RFC6733], Section 3 🏷️.
If the DDFH is set to CONTINUE, the service SHOULD be granted, even if credit-control messages can't be delivered and messages aren't buffered 🌈.
If the Tx timer 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 retransmits the request (marked with the T flag) to a backup credit-control server, if possible 🔁. If the retransmitted request also times out, or if a temporary error comes back in the answer, the credit-control client buffers the request if the DDFH is set to TERMINATE_OR_BUFFER 📥. If a failed answer comes back for the retransmitted request, the credit-control client frees all the resources reserved for the event message and deletes the request, no matter what the DDFH value is 🗑️.
A Credit-Control-Request with the requested action REFUND_ACCOUNT should always be stored in credit-control application-level non-volatile storage, in case a temporary failure occurs 🛟. The credit-control client MUST mark the retransmitted request message as a possible duplicate by setting the T flag in the command header, as described in [RFC6733], Section 3 🚩.
For stored requests, the implementation may choose to limit the number of retransmission attempts and to define a retransmission interval 🧘♀️.
Note that only one entity in the credit-control system SHOULD be responsible for duplicate detection 🕵️♀️. If there is only one credit-control server within the given realm, that 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, so the end user's account isn't debited or credited multiple times for the same service event 💜.
7. Credit-Control Application State Machines 🦋
This section defines five credit-control application state machines 🗺️. The first four state machines are to be observed by credit-control clients. The first one describes session-based credit-control where the first interrogation is executed as part of the authorization/authentication process. The second one describes session-based credit-control where the first interrogation is executed after the authorization/authentication process. The requirements for what has to be supported for these two state machines are discussed in Section 5.2 ✅.
The third state machine describes session-based credit-control for the intermediate and final interrogations. The fourth state machine describes event-based credit-control. These two 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's 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 Tables 3, 4, and 5, the events and actions mean the following 📋:
- "failure to send" means that the Diameter Credit-Control client is unable to communicate with the desired destination or, if a failover procedure is supported, with a possibly defined alternative destination (for example, the request times out and the Answer message is not received). This could be due to (1) the peer being down or (2) a physical link failure in the path to or from the credit-control server 📵.
- "temporary error" means that the Diameter Credit-Control client received a protocol error notification (
DIAMETER_TOO_BUSY,DIAMETER_UNABLE_TO_DELIVER, orDIAMETER_LOOP_DETECTED) in theResult-CodeAVP of the Credit-Control-Answer command 🐢. This type of notification may ultimately be received in answer to the retransmitted request to a defined alternative destination, if failover is supported. - "failed answer" means that the Diameter Credit-Control client received a non-transient failure (permanent failure) notification in the Credit-Control-Answer command 🙃. This type of notification may ultimately be received in answer to the retransmitted request to a defined alternative destination, if failover is supported.
- "store request" means that a request is stored in credit-control application-level non-volatile storage 🗄️.
- "not successfully processed" means that the credit-control server could not process the message, for example due to an unknown end user, an account being empty, or errors defined in [RFC6733] 😵💫.
The event "user service terminated" 💔 can happen for all kinds of reasons: normal user termination, network failure, or an ASR (Abort-Session-Request) 🙈. The Termination-Cause AVP tells you which reason it was, and [RFC6733] has the full rundown 💅.
The Tx timer keeps track of how long the credit-control client waits while it's chilling in the Pending state ⏳. The moment it leaves Pending, the timer gets stopped ✋. When the new state is Idle, the state machine doesn't bother writing out that stop, because going to Idle already means the session and everything tied to it gets cleared 🧹. It's implied, no cap 💀.
PendingI, PendingU, PendingT, PendingE, and PendingB are the "still waiting on an answer" states 🥹. They wait on the answer to a credit-control request that's Initial, Update, Termination, Event, or Buffered, respectively ✨.
Table 2 has a little gap, ngl 👀. Failing over to a secondary server on "temporary error" or "failure to send" isn't spelled out there. You can still move an ongoing credit-control message stream to another server if CC-Session-Failover is set to FAILOVER_SUPPORTED, as described in Section 5.7 🦋.
Resending a credit-control event to an alternative server is supported too, as described in Section 6.5 🎀.
+----------+-------------------------------+-------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send | PendingI |
| | access/service | AA-Request | |
| | | with added | |
| | | CC AVPs, | |
| | | start Tx | |
| | | timer | |
| | | | |
| PendingI | Successful answer to | Grant | Open |
| | AA-Request received | service to | |
| | | end user, | |
| | | stop Tx | |
| | | timer | |
| | | | |
| PendingI | Tx timer expired | Disconnect | Idle |
| | | user/dev | |
| | | | |
| PendingI | Failed AA-Answer received | Disconnect | Idle |
| | | user/dev | |
| | | | |
| PendingI | AA-Answer received with | Grant | Idle |
| | Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingI | User service terminated | Queue | PendingI |
| | | termination | |
| | | event | |
| | | | |
| PendingI | Change in rating condition | Queue | PendingI |
| | | changed | |
| | | rating | |
| | | condition | |
| | | event | |
+----------+-------------------------------+-------------+----------+ Table 2: Session-Based Client State Machine for the
First Interrogation with AA-Request +----------+-------------------------------+-------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send CC | PendingI |
| | access/service | initial | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| PendingI | Successful CC initial answer | Stop Tx | Open |
| | received | timer | |
| | | | |
| PendingI | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingI | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingI | Tx timer expired and CCFH | Terminate | Idle |
| | equal to TERMINATE | end user's | |
| | | service | |
| | | | |
| PendingI | Tx timer expired and CCFH | Grant | PendingI |
| | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | |
| | | | |
| PendingI | CC initial answer received | Terminate | Idle |
| | with Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED or to | service | |
| | USER_UNKNOWN | | |
| | | | |
| PendingI | CC initial answer received | Grant | Idle |
| | with Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| 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 to | end user's | |
| | 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 | |
+----------+-------------------------------+-------------+----------+ Table 3: Session-Based Client State Machine for the
First Interrogation with CCRokay bestie, this part is basically one giant table 🫶 It's Table 4, the session-based client state machine for intermediate and final interrogations 🦋 Each row is a little "if this happens while I'm in this state, do this, then go to that state" recipe ✨
+----------+-------------------------------+-------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+-------------------------------+-------------+----------+
| Open | Granted unit elapses and no | Send CC | PendingU |
| | final-unit indication | update | |
| | received | req., start | |
| | | Tx timer | |
| | | | |
| Open | Granted unit elapses and | Terminate | PendingT |
| | final unit action equal to | end user's | |
| | TERMINATE received | service, | |
| | | send CC | |
| | | termination | |
| | | req. | |
| | | | |
| Open | Change in rating condition in | Send CC | PendingU |
| | queue | update | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| Open | Service terminated in queue | Send CC | PendingT |
| | | termination | |
| | | req. | |
| | | | |
| Open | Change in rating condition or | Send CC | PendingU |
| | Validity-Time elapses | update | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| Open | User service terminated | Send CC | PendingT |
| | | termination | |
| | | req. | |
| | | | |
| Open | RAR received | Send RAA | PendingU |
| | | followed by | |
| | | CC update | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| PendingU | Successful CC update answer | Stop Tx | Open |
| | received | timer | |
| | | | |
| PendingU | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingU | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingU | Tx timer expired and CCFH | Terminate | Idle |
| | equal to TERMINATE | end user's | |
| | | service | |
| | | | |
| PendingU | Tx timer expired and CCFH | Grant | PendingU |
| | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | |
| | | | |
| PendingU | CC update answer received | Terminate | Idle |
| | with Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED | service | |
| | | | |
| PendingU | CC update answer received | Grant | Idle |
| | with Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingU | Failed CC update answer | Grant | Idle |
| | received and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingU | Failed CC update answer | Terminate | Idle |
| | received and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingU | User service terminated | Queue | PendingU |
| | | termination | |
| | | event | |
| | | | |
| PendingU | Change in rating condition | Queue | PendingU |
| | | changed | |
| | | rating | |
| | | condition | |
| | | event | |
| | | | |
| PendingU | RAR received | Send RAA | PendingU |
| | | | |
| PendingT | Successful CC termination | | Idle |
| | answer received | | |
| | | | |
| PendingT | Failure to send, temporary | | Idle |
| | error, or failed answer | | |
| | | | |
| PendingT | Change in rating condition | | PendingT |
+----------+-------------------------------+-------------+----------+
Table 4: Session-Based Client State Machine for Intermediate and
Final InterrogationsThe three states you'll see in the table are Open, PendingU, and PendingT 💜 Idle shows up as the "New State" for a bunch of rows too 🌸 Anything in the Action column is what the client does when that event hits, and the New State column says where it lands 💅
Okay bestie, the state machine tables are where the magic happens ✨ 💅 Here's the one-time event client table, then the session-based server table, copied exactly as they are 🎀
+----------+--------------------------------+------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+--------------------------------+------------+----------+
| Idle | Client or device requests a | Send CC | PendingE |
| | one-time service | event | |
| | | req., | |
| | | start Tx | |
| | | timer | |
| | | | |
| Idle | Request in storage | Send | PendingB |
| | | stored | |
| | | request | |
| | | | |
| PendingE | Successful CC event answer | Grant | Idle |
| | received | service to | |
| | | end user | |
| | | | |
| PendingE | Failure to send, temporary | Indicate | Idle |
| | error, failed CC event answer | service | |
| | received, or Tx timer expired; | error | |
| | requested action CHECK_BALANCE | | |
| | or PRICE_ENQUIRY | | |
| | | | |
| PendingE | CC event answer received with | Terminate | Idle |
| | Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED or to | service | |
| | USER_UNKNOWN and Tx timer | | |
| | running | | |
| | | | |
| PendingE | CC event answer received with | Grant | Idle |
| | Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE; | end user | |
| | requested action | | |
| | DIRECT_DEBITING | | |
| | | | |
| PendingE | Failure to send, temporary | Grant | Idle |
| | error, or failed CC event | service to | |
| | answer received; requested | end user | |
| | action DIRECT_DEBITING; DDFH | | |
| | equal to CONTINUE | | |
| | | | |
| PendingE | Failed CC event answer | Terminate | Idle |
| | received or temporary error; | end user's | |
| | requested action | service | |
| | DIRECT_DEBITING; DDFH equal to | | |
| | TERMINATE_OR_BUFFER and Tx | | |
| | timer running | | |
| | | | |
| PendingE | Tx timer expired; requested | Grant | PendingE |
| | action DIRECT_DEBITING | service to | |
| | | end user | |
| | | | |
| PendingE | Failure to send; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER | with | |
| | | T flag | |
| | | | |
| PendingE | Temporary error; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER; | | |
| | Tx timer expired | | |
| | | | |
| PendingE | Failed answer or answer | | Idle |
| | received with Result-Code | | |
| | equal to END_USER_SERVICE | | |
| | DENIED or to USER_UNKNOWN; | | |
| | requested action | | |
| | DIRECT_DEBITING; Tx timer | | |
| | expired | | |
| | | | |
| PendingE | Failed CC event answer | Indicate | Idle |
| | received; requested action | service | |
| | REFUND_ACCOUNT | error and | |
| | | delete | |
| | | request | |
| | | | |
| PendingE | Failure to send or Tx timer | Store | Idle |
| | expired; requested action | request | |
| | REFUND_ACCOUNT | with | |
| | | T flag | |
| | | | |
| PendingE | Temporary error; requested | Store | Idle |
| | action REFUND_ACCOUNT | request | |
| | | | |
| PendingB | Successful CC answer received | Delete | Idle |
| | | request | |
| | | | |
| PendingB | Failed CC answer received | Delete | Idle |
| | | request | |
| | | | |
| PendingB | Failure to send or temporary | | Idle |
| | error | | |
+----------+--------------------------------+------------+----------+
Table 5: One-Time Event Client State Machine
+-------+------------------------+--------------------------+-------+
| State | Event | Action | New |
| | | | State |
+-------+------------------------+--------------------------+-------+
| Idle | CC initial request | Send CC initial answer, | Open |
| | received and | reserve units, start Tcc | |
| | successfully processed | | |
| | | | |
| Idle | CC initial request | Send CC initial answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS | |
| | | | |
| Idle | CC event request | Send CC event answer | Idle |
| | received and | | |
| | successfully processed | | |
| | | | |
| Idle | CC event request | Send CC event answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS | |
| | | | |
| Open | CC update request | Send CC update answer, | Open |
| | received and | debit used units, | |
| | successfully processed | reserve new units, | |
| | | restart Tcc | |
| | | | |
| Open | CC update request | Send CC update answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS, debit used | |
| | | units | |
| | | | |
| Open | CC termination request | Send CC termin. answer, | Idle |
| | received and | stop Tcc, debit used | |
| | successfully processed | units | |
| | | | |
| Open | CC termination request | Send CC termin. answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS, debit used | |
| | | units | |
| | | | |
| Open | Session supervision | Release reserved units | Idle |
| | timer Tcc expired | | |
+-------+------------------------+--------------------------+-------+
Table 6: Session-Based and Event-Based Server State MachineThose are the two state machines for this part, and they're fully intact 🦋🌸
8. Credit-Control AVPs ✨
okay bestie, this is the AVP lineup 💅 This section defines the Credit-Control AVPs that are specific to the Diameter Credit-Control application, and they MAY be included in the Diameter Credit-Control messages 🎀
These AVPs MAY also show up in authorization commands from authorization-specific applications like [RFC7155] and [RFC4004], but only if the first interrogation happens as part of the authorization/authentication process, the way Section 5.2 describes 🦋
The Diameter AVP rules live in Section 4 of [RFC6733], and every AVP in this section follows them 🫶 The AVP Flag rules ('M', 'V') are explained in Section 4.1 of [RFC6733], so go check that if the letters look like alphabet soup 😭
Here's the full table of Diameter AVPs in the credit-control application, with their AVP Code values, types, and flag values:
+---------------+
|AVP Flag Rules |
Defined |----+-----+----|
AVP in | | |MUST|
Attribute Name Code Section Data Type |MUST| MAY |NOT |
----------------------------------------------------|----+-----+----|
CC-Correlation-Id 411 8.1 OctetString | | M | V |
CC-Input-Octets 412 8.24 Unsigned64 | M | | V |
CC-Money 413 8.22 Grouped | M | | V |
CC-Output-Octets 414 8.25 Unsigned64 | M | | V |
CC-Request-Number 415 8.2 Unsigned32 | M | | V |
CC-Request-Type 416 8.3 Enumerated | M | | V |
CC-Service-Specific- 417 8.26 Unsigned64 | M | | V |
Units | | | |
CC-Session-Failover 418 8.4 Enumerated | M | | V |
CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V |
CC-Time 420 8.21 Unsigned32 | M | | V |
CC-Total-Octets 421 8.23 Unsigned64 | M | | V |
CC-Unit-Type 454 8.32 Enumerated | M | | V |
Check-Balance-Result 422 8.6 Enumerated | M | | V |
Cost-Information 423 8.7 Grouped | M | | V |
Cost-Unit 424 8.12 UTF8String | M | | V |
Credit-Control 426 8.13 Enumerated | M | | V |
Credit-Control- 427 8.14 Enumerated | M | | V |
Failure-Handling | | | |
Currency-Code 425 8.11 Unsigned32 | M | | V |
Direct-Debiting- 428 8.15 Enumerated | M | | V |
Failure-Handling | | | |
Exponent 429 8.9 Integer32 | M | | V |
Final-Unit-Action 449 8.35 Enumerated | M | | V |
Final-Unit-Indication 430 8.34 Grouped | M | | V |
QoS-Final-Unit-Indication 669 8.68 Grouped | | M | V |
Granted-Service-Unit 431 8.17 Grouped | M | | V |
G-S-U-Pool-Identifier 453 8.31 Unsigned32 | M | | V |
G-S-U-Pool-Reference 457 8.30 Grouped | M | | V |
Multiple-Services- 456 8.16 Grouped | M | | V |
Credit-Control | | | |
Multiple-Services- 455 8.40 Enumerated | M | | V |
Indicator | | | |
Rating-Group 432 8.29 Unsigned32 | M | | V |
Redirect-Address-Type 433 8.38 Enumerated | M | | V |
Redirect-Server 434 8.37 Grouped | M | | V |
Redirect-Server-Address 435 8.39 UTF8String | M | | V |
Redirect-Server-Extension 665 8.64 Grouped | | M | V |
Redirect-Address- 666 8.65 Address | | M | V |
IPAddress | | | |
Redirect-Address-URL 667 8.66 UTF8String | | M | V |
Redirect-Address-SIP-URI 668 8.67 UTF8String | | M | V |
Requested-Action 436 8.41 Enumerated | M | | V |
Requested-Service-Unit 437 8.18 Grouped | M | | V |
Restriction-Filter-Rule 438 8.36 IPFilterRule| M | | V |
Service-Context-Id 461 8.42 UTF8String | M | | V |
Service-Identifier 439 8.28 Unsigned32 | M | | V |
Service-Parameter-Info 440 8.43 Grouped | | M | V |
Service-Parameter-Type 441 8.44 Unsigned32 | | M | V |
Service-Parameter-Value 442 8.45 OctetString | | M | V |
Subscription-Id 443 8.46 Grouped | M | | V |
Subscription-Id-Data 444 8.48 UTF8String | M | | V |
Subscription-Id-Type 450 8.47 Enumerated | M | | V |
Subscription-Id-Extension 659 8.58 Grouped | | M | V |
Subscription-Id-E164 660 8.59 UTF8String | | M | V |
Subscription-Id-IMSI 661 8.60 UTF8String | | M | V |
Subscription-Id-SIP-URI 662 8.61 UTF8String | | M | V |
Subscription-Id-NAI 663 8.62 UTF8String | | M | V |
Subscription-Id-Private 664 8.63 UTF8String | | M | V |
Tariff-Change-Usage 452 8.27 Enumerated | M | | V |
Tariff-Time-Change 451 8.20 Time | M | | V |
Unit-Value 445 8.8 Grouped | M | | V |
Used-Service-Unit 446 8.19 Grouped | M | | V |
User-Equipment-Info 458 8.49 Grouped | | M | V |
User-Equipment-Info-Type 459 8.50 Enumerated | | M | V |
User-Equipment-Info-Value 460 8.51 OctetString | | M | V |
User-Equipment-Info- 653 8.52 Grouped | | M | V |
Extension | | | |
User-Equipment-Info- 654 8.53 OctetString | | M | V |
IMEISV | | | |
User-Equipment-Info-MAC 655 8.54 OctetString | | M | V |
User-Equipment-Info-EUI64 656 8.55 OctetString | | M | V |
User-Equipment-Info- 657 8.56 OctetString | | M | V |
ModifiedEUI64 | | | |
User-Equipment-Info-IMEI 658 8.57 OctetString | | M | V |
Value-Digits 447 8.10 Integer64 | M | | V |
Validity-Time 448 8.33 Unsigned32 | M | | V |8.1. CC-Correlation-Id AVP
The CC-Correlation-Id AVP (AVP Code 411) is an OctetString 🌸 It holds info that correlates credit-control requests made for different parts of the same service, like the transport level and the service level. Whoever assigns the Service-Context-Id (basically the unique ID of a service-specific document) is also the one in charge of defining what goes into the CC-Correlation-Id AVP and how it's encoded 🧚
8.2. CC-Request-Number AVP
The CC-Request-Number AVP (AVP Code 415) is an Unsigned32 that identifies one request inside a session 🍓 Session-Id AVPs are globally unique, so pairing them with CC-Request-Number makes the combo globally unique too, which is how you match credit-control messages with their confirmations. A super easy way to get unique numbers: set CC-Request-Number to 0 for the INITIAL_REQUEST (the very first request in a session). Then the first UPDATE_REQUEST should be 1, the second 2, and so on, until the TERMINATION_REQUEST is one more than the last UPDATE_REQUEST. For event charging (when CC-Request-Type is EVENT_REQUEST), CC-Request-Number should be set to 0 for a credit-control request ✨
8.3. CC-Request-Type AVP
The CC-Request-Type AVP (AVP Code 416) is an Enumerated that tells you why the Credit-Control-Request message was sent 👑 It MUST be present in all Credit-Control-Request messages. These are the defined values (the value 0 is reserved, so don't use it):
INITIAL_REQUEST 1
UPDATE_REQUEST 2
TERMINATION_REQUEST 3
EVENT_REQUEST 4INITIAL_REQUEST starts a credit-control session, and it carries the credit-control info that's relevant to starting one 🌈
UPDATE_REQUEST brings credit-control info for a session that already exists 💖 These SHOULD be sent every time a credit-control re-authorization is needed, which happens when the allocated quota or validity time runs out. On top of that, extra service-specific events MAY trigger a spontaneous UPDATE_REQUEST 🔥
TERMINATION_REQUEST is how you end a credit-control session 🦋 It carries the info that matters for the session that's wrapping up.
EVENT_REQUEST is for when there's no need to keep any credit-control session state on the credit-control server 🧚 It has everything about the service, and it's the only request for that service. The reason for it is spelled out in the Requested-Action AVP, and the Requested-Action AVP MUST be included in the Credit-Control-Request message whenever CC-Request-Type is set to EVENT_REQUEST 💅
8.4. CC-Session-Failover AVP
The CC-Session-Failover AVP (AVP Code 418) is an Enumerated that says whether it's okay to move the credit-control message stream to a backup server in the middle of an ongoing session 🌸 If there are communication failures, the stream can move to a different destination, but only if the credit-control server actually supports failing over to another server. If the home Diameter AAA server sent a secondary credit-control server name, that can be used as the address of the backup 🫶 Implementations don't have to support moving the stream to another server, because that also means moving the session info over to the backup, which is a lot 😭
These are the defined values:
FAILOVER_NOT_SUPPORTED 0
FAILOVER_SUPPORTED 1FAILOVER_NOT_SUPPORTED (0): if CC-Session-Failover is this, the credit-control message stream MUST NOT be moved to another destination when a communication failure happens 🙈 This is also the default if the AVP isn't in the reply from the authorization or credit-control server.
FAILOVER_SUPPORTED (1): if CC-Session-Failover is this, the credit-control message stream SHOULD be moved to another destination when a communication failure happens ✨ Moving it to a backup server MAY mean that the session info should also be forwarded to the alternative server 🎀
8.5. CC-Sub-Session-Id AVP
The CC-Sub-Session-Id AVP (AVP Code 419) is an Unsigned64 that holds the credit-control sub-session identifier 🦋 The combo of the Session-Id AVP and this AVP MUST be unique per sub-session, and the value MUST go up by exactly one for every new sub-session 💜 If this AVP is missing, that means no sub-sessions are in use 🍓
8.6. Check-Balance-Result AVP ✨
Okay bestie, the Check-Balance-Result AVP (AVP Code 422) is an Enumerated one 🎀 and it holds the result of the balance check 💅. It only shows up when the Requested-Action AVP says CHECK_BALANCE inside a Credit-Control-Request command 🦋. There are two values you can get back:
ENOUGH_CREDIT 0Yay, there's enough credit in the account to cover the requested service 🌸
NO_CREDIT 1Uh oh, 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 a Grouped one 🧚, and its job is to return the cost info for a service 💖. The credit-control client can pass it along to the end user without changing it 🫶. Inside it, the Unit-Value AVP holds the cost estimate (always of type "money") for a price inquiry, or the accumulated cost estimate when you're in a credit-control session 💅.
The Currency-Code AVP tells you which currency the cost is in 🌈. The Cost-Unit AVP tells you the unit, but only when the service costs per unit, like $1 per minute ⏱️.
When the Credit-Control-Request has Requested-Action set to PRICE_ENQUIRY, the Cost-Information AVP in the Credit-Control-Answer that comes back has the cost estimate for the service you asked about 🔥. No reservations get made here, so nothing is locked up 🙈.
For a Credit-Control-Answer with CC-Request-Type set to UPDATE_REQUEST, the Cost-Information AVP has the accumulated cost estimate for the session 💜. Credit reservations are not taken into account for this one 🍓.
For a Credit-Control-Answer with CC-Request-Type set to EVENT_REQUEST or TERMINATION_REQUEST, the Cost-Information AVP has the estimated total cost for the requested service ✨.
The Cost-Information AVP is defined like this (per grouped-avp-def as defined in [RFC6733]) 👑:
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]8.8. Unit-Value AVP 🌸
The Unit-Value AVP is a Grouped one (AVP Code 445) 🦋, and it gives you the cost as a floating-point value 💅. The Unit-Value is a significand with an exponent, so Unit-Value = Value-Digits AVP * 10^Exponent 🔥. This way, you avoid unwanted rounding off, which is so important 🙌. For example, 2,3 is written as Value-Digits = 23 and Exponent = -1 🎀.
If the exponent part is missing, it MUST be read as an exponent equal to zero 🫶.
The Unit-Value AVP is defined like this (per grouped-avp-def as defined in [RFC6733]) 💜:
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]8.9. Exponent AVP ⭐
The Exponent AVP is an Integer32 (AVP Code 429) 🧚, and it holds the exponent value that gets applied to the Value-Digits AVP inside the Unit-Value AVP 💖.
8.10. Value-Digits AVP 🍓
The Value-Digits AVP is an Integer64 (AVP Code 447) 🌈, and it holds the significant digits of the number 💅. If you need decimal values to show the units, the scaling MUST be indicated with the related Exponent AVP 🔥. For example, for the monetary amount $0.05, the 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 an Unsigned32 🦋. It holds a currency code that says which currency the monetary values were given in 💜. It uses the numeric values from the ISO 4217 standard [ISO4217] ✨.
8.12. Cost-Unit AVP 🎀
The Cost-Unit AVP (AVP Code 424) is a UTF8String 💅, and it's there to show a human-readable string to the end user 🫶. It names the unit for the Cost-Information AVP when the service costs per unit, like $1 per minute ⏱️. The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, and so on 🌸.
8.13. Credit-Control AVP 👑
The Credit-Control AVP (AVP Code 426) is an Enumerated one, and it MUST be included in AA-Request messages when the Service Element has credit-control capabilities 🔥. Two values are defined:
CREDIT_AUTHORIZATION 0If the home Diameter AAA server decides the user has a prepaid subscription, this value says the credit-control server MUST be contacted for the first interrogation 💖. The Credit-Control AVP MUST always be set to 0 in an AA-Request that does the first interrogation and starts a new credit-control session 🧚.
RE_AUTHORIZATION 1This value tells the Diameter AAA server that a credit-control session is already going for the subscriber, and the credit-control server MUST NOT be contacted 🦋. Use the value 1 only after the first interrogation went through and the session is still ongoing, like when re-authorization is triggered by the authorization lifetime 🌈. This value MUST NOT be used in an AA-Request that does the first interrogation 🙈.
8.14. Credit-Control-Failure-Handling AVP (CCFH) 🛟
The CCFH (AVP Code 427) is an Enumerated one 💅. The credit-control client uses it to decide what to do when sending credit-control messages to the credit-control server has been blocked, for instance temporarily, by a network problem 😭. Depending on the service logic, the credit-control server can tell the client to end the service right away if there's reason to think it can't be charged, or to try failover to an alternative server if possible ✨. The server could then either terminate or grant the service if the alternative connection fails too 💜.
The following values are defined for the CCFH 👑:
TERMINATE 0With 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 doesn't get any Credit-Control-Answer messages before the Tx timer (as defined in Section 13) expires, the credit-control request is treated 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 1With CONTINUE, the credit-control client SHOULD resend the request to an alternative server when there's a transport or temporary failure, provided that (1) a failover procedure is supported in the credit-control server and the credit-control client and (2) an alternative server is available 🦋. Otherwise, the service SHOULD be granted, even if credit-control messages can't be delivered 🌸.
RETRY_AND_TERMINATE 2With RETRY_AND_TERMINATE, the credit-control client SHOULD resend the request to an alternative server when there's a transport or temporary failure, provided that (1) a failover procedure is supported in the credit-control server and the credit-control client and (2) 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 (DDFH) 💳
The DDFH (AVP Code 428) is an Enumerated one 🧚. The credit-control client uses it to decide what to do when sending credit-control messages (with Requested-Action AVP set to DIRECT_DEBITING) to the credit-control server has been blocked, for instance temporarily, by a network problem 🫶.
The following values are defined for the DDFH 🌈:
TERMINATE_OR_BUFFER 0With 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 doesn't get any Credit-Control-Answer messages before the Tx timer (as defined in Section 13) expires, the credit-control request is treated as failed 😭. The client SHOULD end the service if it can tell 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 resend the request 💜. These requests MUST be marked as possible duplicates by setting the T flag in the command header as described in [RFC6733], Section 3 🎀. This is the default behavior if the AVP isn't included in the reply from the authorization server 🙈.
CONTINUE 1With 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 💖
okay so this one is the grouped AVP for independent credit control across multiple services 🎀. Each instance can carry units for one or more services, or for a single rating-group ✨.
The Service-Identifier AVP and the Rating-Group AVP are how the granted units get linked to a service or rating-group 🦋. If both are included, the service units always go to the service(s) named by the Service-Identifier AVP(s). If only Rating-Group is there, this AVP covers all the services in that rating-group 🌸.
The G-S-U-Pool-Reference AVP lets the server name a G-S-U-Pool-Identifier for a credit pool where units of a given type are pooled 🧚. If it shows up, actual service units of that type MUST also be there. For example, if the G-S-U-Pool-Reference says the CC-Unit-Type is TIME (Section 8.32), then the CC-Time AVP MUST be present 😭.
The Requested-Service-Unit AVP MAY hold the requested service units or the requested monetary value 💅. It MUST be in the initial interrogation, and in the intermediate interrogations where a new quota is requested 🔥. If the credit-control client leaves out Requested-Service-Unit in a request command (because, say, it figured out 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 answer. The Validity-Time, Result-Code, and Final-Unit-Indication or QoS-Final-Unit-Indication AVPs MAY be present in a Credit-Control-Answer command, as defined in Sections 5.1.2 and 5.6, for graceful service termination 🫶.
When both Tariff-Time-Change and Tariff-Change-Usage are present, the server MUST include two separate instances of Multiple-Services-Credit-Control, with the Granted-Service-Unit AVP tied to the same service-identifier and/or rating-group 👑. If the two quotas go to the same pool or to different pools, the credit-pooling mechanism in Section 5.1.2 applies ✨. When the client reports used units from before and after the tariff time change, it MUST use Tariff-Change-Usage inside Used-Service-Unit 💜.
A server that doesn't implement independent credit control of multiple services MUST treat Multiple-Services-Credit-Control as an invalid AVP 🙈.
The AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
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 ]
[ QoS-Final-Unit-Indication ]
*[ AVP ]8.17. Granted-Service-Unit AVP 🌈
The Granted-Service-Unit AVP (AVP Code 431) is of type Grouped 🎁. It holds the amount of units the Diameter Credit-Control client can give 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 every unit type, and it must treat unknown or unsupported unit types in the Answer message as an incorrect CCA. In that case, the client MUST terminate the credit-control session and give the reason as DIAMETER_BAD_ANSWER in the Termination-Cause AVP 😬.
The AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
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 holds the amount of requested units the Diameter Credit-Control client asks for 🙋♀️. A server is not required to implement every unit type, and it must treat unknown or unsupported unit types as invalid AVPs.
Defined like this (per grouped-avp-def as defined in [RFC6733]):
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) 🧁. It holds 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.
Note: The value reported in aUsed-Service-UnitAVP is not necessarily related to the grant given in aGranted-Service-UnitAVP. For example, the value in this AVP may be bigger than the value in the grant. 🙈
Defined like this (per grouped-avp-def as defined in [RFC6733]):
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. The server sends it to the client, and it includes the time in seconds since January 1, 1900, 00:00 UTC, when the tariff of the service will change 🕰️.
The tariff change mechanism is optional for the client and server, and it isn't used for time-based services (Section 5). If a client doesn't support the tariff time change mechanism, it MUST treat the Tariff-Time-Change AVP in the Answer message as an incorrect CCA. In that case, the client terminates the credit-control session and gives the reason as DIAMETER_BAD_ANSWER in the Termination-Cause AVP 😭.
If this AVP is left out, that means no tariff change is to be reported 🌸.
8.21. CC-Time AVP ⌛
The CC-Time AVP (AVP Code 420) is of type Unsigned32 and shows 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's defined like this (per grouped-avp-def as defined in [RFC6733]):
CC-Money ::= < AVP Header: 413 >
{ Unit-Value }
[ Currency-Code ]8.23. CC-Total-Octets AVP 🧮
The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and holds the total number of requested, granted, or used octets, no matter the direction (sent or received) ↔️.
8.24. CC-Input-Octets AVP 📥
The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and holds the number of requested, granted, or used octets that can be, or have been, received from the end user 💌.
8.25. CC-Output-Octets AVP 📤
The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and holds the number of requested, granted, or used octets that can be, or have been, sent to the end user 🚀.
8.26. CC-Service-Specific-Units AVP 🧩
The CC-Service-Specific-Units AVP (AVP Code 417) is of type Unsigned64 and specifies the number of service-specific units (for example, number of events or points) given in a selected service 🎯. These service-specific units always refer to the service identified in the Service-Identifier AVP (or the Rating-Group AVP when Multiple-Services-Credit-Control is used) 🔗.
8.27. Tariff-Change-Usage AVP 🔄
The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and says whether units were used before or after a tariff change, or whether the units straddled a tariff change during the reporting period 🌗. If this AVP is left out, that means no tariff change has happened ✨.
Also, when it shows up in Answer messages as part of Multiple-Services-Credit-Control, this AVP says whether units are allocated to be used before or after a tariff change event 💜.
When Tariff-Time-Change is present, leaving this AVP out of Answer messages means the single-quota mechanism applies 👑.
Tariff-Change-Usage can be set to one of the following values 🦋:
UNIT_BEFORE_TARIFF_CHANGE 0When it's in Multiple-Services-Credit-Control, this value shows how many units were allocated for use before a tariff change happens ⏪.
When it's in Used-Service-Unit, this value shows how many resource units were used before a tariff change had happened 📉.
UNIT_AFTER_TARIFF_CHANGE 1When it's in Multiple-Services-Credit-Control, this value shows how many units were allocated for use after a tariff change happens ⏩.
When it's in Used-Service-Unit, this value shows how many resource units were used after a tariff change had happened 📈.
UNIT_INDETERMINATE 2This value is only for Used-Service-Unit, and it shows how many resource units straddle the tariff change 🌀. For example, the metering process reports to the credit-control client in blocks of n octets, and one block straddled the tariff change 🧱.
8.28. Service-Identifier AVP 🪪
The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and holds the identifier of a service 🆔. The specific service a request relates to is uniquely identified by the combination of the Service-Context-Id AVP and the Service-Identifier AVP 🫧.
There's a usage example of this AVP in Appendix A.9 📖.
8.29. Rating-Group AVP 🏷️
The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and holds the identifier of a rating-group 🌈. All the services that are subject to the same rating type are part of the same rating-group 🧃. The specific rating-group a request relates to is uniquely identified by the combination of the Service-Context-Id AVP and the Rating-Group AVP 👯♀️.
There's a usage example of this AVP in Appendix A.9 📖.
8.30. G-S-U-Pool-Reference AVP
Okay so bestie, this AVP is the glue for credit pools! 💖 The G-S-U-Pool-Reference AVP (AVP Code 457) is Grouped, and it shows up in the Credit-Control-Answer message. It links the Granted-Service-Unit AVP it lives inside to a credit pool within the session. Main character energy 👑
The G-S-U-Pool-Identifier AVP says which credit pool the credit gets drawn from for this unit type. 🧚
The CC-Unit-Type AVP says what kind of units are being pooled. 🌸
The Unit-Value AVP is the multiplier. It converts between service units of type CC-Unit-Type and abstract service units inside the credit pool, and that means it also converts to service units of any other services or rating-groups tied to the same pool. It's giving conversion queen 🔥
The G-S-U-Pool-Reference AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
G-S-U-Pool-Reference ::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }8.31. G-S-U-Pool-Identifier AVP
The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 and identifies a credit pool within the session. Its ID card 🪪✨
8.32. CC-Unit-Type AVP
The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and specifies the type of units considered to be pooled into a credit pool. 💅
The following values are defined for the CC-Unit-Type AVP:
TIME 0
MONEY 1
TOTAL-OCTETS 2
INPUT-OCTETS 3
OUTPUT-OCTETS 4
SERVICE-SPECIFIC-UNITS 58.33. Validity-Time AVP
The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It's sent from the credit-control server to the credit-control client, and it contains the validity time of the granted service units. The timer starts when the Credit-Control-Answer message containing this AVP is received. If the granted service units haven't been consumed within the validity time in this AVP, the credit-control client MUST send a Credit-Control-Request message to the server, with CC-Request-Type set to UPDATE_REQUEST. The value field is given in seconds. ⏰
The Validity-Time AVP also does double duty for graceful service termination (see Section 5.6). It tells the credit-control client how long the subscriber is allowed to keep using network resources after the specified action (REDIRECT or RESTRICT_ACCESS) kicks off. When the Validity-Time runs out, a new intermediate interrogation gets sent to the server. 🦋
8.34. Final-Unit-Indication AVP
The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped. It indicates that the Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA-Answer contains the final units for the service. Once those units expire, the Diameter Credit-Control client is responsible for executing the action in the Final-Unit-Action AVP (see Section 5.6). 🎀
If more than one unit type shows up in the Credit-Control-Answer, the unit type that expires first SHOULD cause the credit-control client to run the specified action. 🕐
In the first interrogation, the Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also appear with no Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA-Answer. This tells the Diameter Credit-Control client to run the action immediately. If the home service provider policy is to terminate the service, the server SHOULD return the appropriate transient failure (see Section 9.1) to carry out that policy-defined action. 🙈
The Final-Unit-Action AVP defines how the Service Element behaves when the user's account can't cover the cost of the service. It MUST always be present if the Final-Unit-Indication AVP is included in a command. Non-negotiable, bestie 😭
If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit-Indication group AVP MUST NOT contain any other AVPs. Keep it clean! 🧼
If the Final-Unit-Action AVP is set to REDIRECT, the Redirect-Server AVP or the Redirect-Server-Extension AVP (at least one) MUST be present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is also allowed to reach other services that aren't accessible through the address in the Redirect-Server AVP. 🌈
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 💜
The Filter-Id AVP is defined in [RFC7155]. It can reference an IP filter list installed in the access device by means other than the Diameter Credit-Control application, like one that's configured locally or set by another entity. 🍓
If the Final-Unit-Action AVP is set to REDIRECT and the type of server isn't one of the enumerations in the Redirect-Address-Type AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together with the Redirect-Server-Extension AVP instead of the Final-Unit-Indication AVP. ✨
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT, and the classification of the restricted traffic can't be expressed using an IPFilterRule, or if actions other than just allowing traffic (like QoS) need enforcing, then the QoS-Final-Unit-Indication AVP SHOULD be used instead of the Final-Unit-Indication AVP. However, if the credit-control server wants to stay backward compatible with credit-control clients that only support [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with the Filter-Id AVP. 🦄
The Final-Unit-Indication AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]8.35. Final-Unit-Action AVP
The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and tells the credit-control client what to do when the user's account can't cover the service cost. 💀
Final-Unit-Action can be set to one of the following values:
TERMINATE 0
The credit-control client MUST terminate the service session. This is the default handling, and it applies whenever the credit-control client receives an unsupported Final-Unit-Action value. It MUST be supported by all Diameter Credit-Control client implementations conforming to this specification. Bye-bye session 👋
REDIRECT 1
The Service Element MUST redirect the user to the address specified in the Redirect-Server-Address AVP or one of the AVPs included in the Redirect-Server-Extension AVP. The redirect action is defined in Section 5.6.2. 🚀
RESTRICT_ACCESS 2
The access device MUST restrict the user's access according to the filter AVPs in the applied Grouped AVP: according to IP packet filters defined in the Restriction-Filter-Rule AVP, according to the packet classifier filters defined in the Filter-Rule AVP, or according to the packet filters identified by the Filter-Id AVP. All packets that don't match any restriction filters (see Section 5.6.3) MUST be dropped. Gatekeeping at its finest 🔒
8.36. Restriction-Filter-Rule AVP
The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule and provides filter rules for services that stay accessible even when there are no more service units granted. The access device has to configure the specified filter rules for the subscriber and MUST drop all packets not matching these filters. Zero, one, or more of these AVPs MAY be present in a Credit-Control-Answer message or in an AA-Answer message. 🌸
8.37. Redirect-Server AVP
The Redirect-Server AVP (AVP Code 434) is of type Grouped and contains the address information of the redirect server (for example an HTTP redirect server or a SIP Server) that the end user gets connected to when the account can't cover the service cost. It MUST be present when the Final-Unit-Action AVP is set to REDIRECT. 🧭
The Redirect-Server AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }8.38. Redirect-Address-Type AVP
The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated and defines the address type of the address given in the Redirect-Server-Address AVP. 🎯
Redirect-Address-Type can be set to one of the following values:
IPv4 Address 0
The address type is in the form of a "dotted-decimal" IPv4 address, as defined in [RFC791]. 🍑
IPv6 Address 1
The address type is in the form of an IPv6 address, as defined in [RFC4291]. The address MUST conform to the textual representation of the address according to [RFC5952]. ✨
Because [RFC5952] is stricter than the "RFC 3513" format required by [RFC4006], some legacy implementations may not comply with the new requirements. So implementations receiving this AVP MAY be liberal in the textual IPv6 representations they accept, without raising an error. Lenient energy 🫶
URL 2
The address type is in the form of a Uniform Resource Locator, as defined in [RFC3986]. 🔗
SIP URI 3
The address type is in the form of a SIP Uniform Resource Identifier, as defined in [RFC3261]. 📞
8.39. Redirect-Server-Address AVP
The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String and defines the address of the redirect server (for example an HTTP redirect server or a SIP Server) that the end user gets connected to when the account can't cover the service cost. 🌐
8.40. Multiple-Services-Indicator AVP
The Multiple-Services-Indicator AVP (AVP Code 455) is of type Enumerated and indicates whether the Diameter Credit-Control client can handle multiple services independently within a (sub-)session. If this AVP is absent, it means independent credit-control of multiple services is not supported. 🧩
A server that does not implement independent credit-control of multiple services MUST treat the Multiple-Services-Indicator AVP as an invalid AVP. Rude! 🙅♀️
The following values are defined for the Multiple-Services-Indicator AVP:
MULTIPLE_SERVICES_NOT_SUPPORTED 0
The client does not support independent credit-control of multiple services within a (sub-)session. 🙃
MULTIPLE_SERVICES_SUPPORTED 1
The client supports independent credit-control of multiple services within a (sub-)session. Yesss, we love to see it 🌈
8.41. Requested-Action AVP ✨
okay so the Requested-Action AVP (AVP Code 436) is an Enumerated one 💅 and it tells you what the client is actually asking for in a Credit-Control-Request when the CC-Request-Type is set to EVENT_REQUEST 📨. There are four values:
DIRECT_DEBITING 0💸: this means "please take money off the end user's account." It uses the info in the Requested-Service-Unit AVP and/or the Service-Identifier AVP (extra rating info can ride along in service-specific AVPs or the Service-Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-Control-Answer then carries the units that got debited.REFUND_ACCOUNT 1🤑: the opposite energy! It means "please put money back on the end user's account," using the same inputs as above. The Granted-Service-Unit AVP in the answer carries the refunded units.CHECK_BALANCE 2👀: a balance-check request. The account is checked without any credit reservations being made from it, and the Check-Balance-Result AVP in the Credit-Control-Answer holds the result.PRICE_ENQUIRY 3🏷️: a price-inquiry. No balance checking and no reservations happen here. You just get the price of the service back, inside the Cost-Information AVP in the Credit-Control-Answer.
8.42. Service-Context-Id AVP ✨
The Service-Context-Id AVP is a UTF8String (AVP Code 461) and it's basically the unique ID of the Diameter Credit-Control service-specific document (see Section 4.1.2) that applies to the request 📚. The service provider, the Service Element manufacturer, or a standardization body allocates it, and it MUST uniquely identify a given Diameter Credit-Control service-specific document 🔑. The format looks like this:
"service-context" "@" "domain"
service-context = TokenThe Token is just an arbitrary string of characters and digits 🔤.
The domain part is whoever allocated the ID 🌐. If a standardization body did it, it could be something like ietf.org or 3gpp.org. If it's a private entity, it can be the Fully Qualified Domain Name (FQDN) of the service provider (like provider.example.com) or of the vendor (like vendor.example.com).
This AVP SHOULD be placed as close to the Diameter header as possible 📍.
Service-specific documents that are only for private use (one provider's own thing, where interoperability isn't useful) can define private identifiers with no coordination needed 🤫. But if you do want interoperability, coordinating the identifiers, for example by publishing an informational RFC, is RECOMMENDED so the Service-Context-Id AVP is globally available 🌍. Main character energy for interop! 🦋
8.43. Service-Parameter-Info AVP ✨
The Service-Parameter-Info AVP (AVP Code 440) is Grouped 🧺 and holds service-specific info used for price calculation or rating 💲. The Service-Parameter-Type AVP says what kind of parameter it is, and the Service-Parameter-Value AVP holds the actual value. What those contents are isn't in scope for this document, so they SHOULD be defined in another Diameter application, in standards from other standardization bodies, or in service-specific documentation 📖.
Now the important bit ⚠️: if a service request is unknown (say, an unknown Service-Parameter-Type), the corresponding Answer message MUST contain the error code DIAMETER_RATING_FAILED. A Credit-Control-Answer with this error MUST also contain one or more Failed-AVP AVPs holding the Service-Parameter-Info AVPs that caused the failure 🚨.
The error is not optional. If the Service-Parameter-Info AVPs are the cause, the Failed-AVP AVPs have to show them 💀.
The Service-Parameter-Info AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type }
{ Service-Parameter-Value }8.44. Service-Parameter-Type AVP ✨
The Service-Parameter-Type AVP is an Unsigned32 (AVP Code 441) 🔢. It defines the type of the service-event-specific parameter, like the end-user location or the service name 📍. The parameters and their types depend on the service, and this document doesn't define what they mean 🤷♀️. Whoever allocates the Service-Context-Id (the unique ID of a service-specific document) is also in charge of assigning Service-Parameter-Type values for that service and making sure they stay unique within it 🔐. The Service-Parameter-Value AVP carries the value tied to that parameter type 💖.
8.45. Service-Parameter-Value AVP ✨
The Service-Parameter-Value AVP is an OctetString (AVP Code 442) and it holds the value of the service parameter type 🧃.
8.46. Subscription-Id AVP ✨
The Subscription-Id AVP (AVP Code 443) identifies the end user's subscription and is Grouped 🪪. It includes a Subscription-Id-Data AVP that holds the identifier, and a Subscription-Id-Type AVP that says what kind of identifier it is 🗂️.
The Subscription-Id AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }8.47. Subscription-Id-Type AVP ✨
The Subscription-Id-Type AVP (AVP Code 450) is Enumerated, and it tells you which type of identifier is inside the Subscription-Id AVP 🆔.
This spec defines the following subscription identifiers. New Subscription-Id-Type values can be assigned by IANA as described in Section 12 🌱. A server MUST implement all the Subscription-Id-Type values it needs to perform credit authorization for the services it supports, including future values 🛡️. Unknown or unsupported Subscription-Id-Type values MUST be treated according to the 'M' flag rule, as defined in [RFC6733] 🏳️.
END_USER_E164 0📞: the identifier is in international E.164 format (for example, MSISDN), following the ITU-T E.164 numbering plan defined in [E164] and [CE164].END_USER_IMSI 1📱: the identifier is in IMSI format, following the ITU-T E.212 identification plan as defined in [E212] and [CE212].END_USER_SIP_URI 2🎧: the identifier is a SIP URI, as defined in [RFC3261].END_USER_NAI 3🪪: the identifier is a Network Access Identifier, as defined in [RFC7542].END_USER_PRIVATE 4🔒: the identifier is a credit-control server private identifier.
8.48. Subscription-Id-Data AVP ✨
The Subscription-Id-Data AVP (AVP Code 444) is used to identify the end user and is a UTF8String 🎀. The Subscription-Id-Type AVP tells you which type of identifier it is 💜.
8.49. User-Equipment-Info AVP ✨
The User-Equipment-Info AVP (AVP Code 458) is Grouped 📱 and lets the credit-control client say who the terminal is and what it can do, meaning the terminal the subscriber is using to connect to the network 🔌.
The User-Equipment-Info AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }8.50. User-Equipment-Info-Type AVP ✨
The User-Equipment-Info-Type AVP is Enumerated (AVP Code 459) and defines what kind of user equipment info is in the User-Equipment-Info-Value AVP 🏷️.
This spec defines the following user equipment types. New User-Equipment-Info-Type values can be assigned by IANA as described in Section 12 🌸.
IMEISV 0📟: the identifier holds the International Mobile Equipment Identifier and Software Version (IMEISV) in the IMEISV format, per 3GPP TS 23.003 [TGPPIMEI].MAC 1🖧: the 48-bit Media Access Control (MAC) address, formatted as described in Section 3.21 of [RFC3580].EUI64 2🔖: the 64-bit identifier used to identify the hardware instance of the product, as defined in [EUI64].MODIFIED_EUI64 3🧩: some terminals have identifiers that aren't IMEI, IEEE 802 MACs, or EUI-64. These can be converted to modified EUI-64 format, as described in [RFC4291], or with other methods mentioned in the service-specific documentation 🪄.
8.51. User-Equipment-Info-Value AVP ✨
The User-Equipment-Info-Value AVP (AVP Code 460) is an OctetString 🫧. The User-Equipment-Info-Type AVP says which type of identifier is being used 💅.
8.52. User-Equipment-Info-Extension AVP ✨
The User-Equipment-Info-Extension AVP (AVP Code 653) is Grouped 🧃 and, just like User-Equipment-Info, lets the credit-control client share the identity and capability of the subscriber's terminal 📲. If the equipment type is one of the enumerated User-Equipment-Info-Type values, the credit-control client SHOULD send that info in the User-Equipment-Info AVP as well as, or instead of, the User-Equipment-Info-Extension AVP 🔁. The reason is backward compatibility with credit-control servers that only support [RFC4006] 🤝. Exactly one AVP MUST be included inside the User-Equipment-Info-Extension AVP ☝️.
The User-Equipment-Info-Extension AVP is defined like this (per grouped-avp-def as defined in [RFC6733]):
User-Equipment-Info-Extension ::= < AVP Header: 653 >
[ User-Equipment-Info-IMEISV ]
[ User-Equipment-Info-MAC ]
[ User-Equipment-Info-EUI64 ]
[ User-Equipment-Info-ModifiedEUI64 ]
[ User-Equipment-Info-IMEI ]
[ AVP ]8.53. User-Equipment-Info-IMEISV AVP ✨
The User-Equipment-Info-IMEISV AVP (AVP Code 654) is an OctetString 📟. It holds the International Mobile Equipment Identifier and Software Version in the IMEISV format, per 3GPP TS 23.003 [TGPPIMEI] 🌷.
8.54. User-Equipment-Info-MAC AVP ✨
The User-Equipment-Info-MAC AVP (AVP Code 655) is an OctetString 🖧. It holds the 48-bit MAC address, formatted as described in Section 4.1.7.8 of [RFC5777] 💫.
8.55. User-Equipment-Info-EUI64 AVP ✨
The User-Equipment-Info-EUI64 AVP (AVP Code 656) is an OctetString 🔖. It holds the 64-bit identifier used to identify the hardware instance of the product, as defined in [EUI64] 🧠.
8.56. User-Equipment-Info-ModifiedEUI64 AVP ✨
The User-Equipment-Info-ModifiedEUI64 AVP (AVP Code 657) is an OctetString 🧩. Some terminals have identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These can be converted to modified EUI-64 format, as described in [RFC4291], or with other methods mentioned in the service-specific documentation 🌈. This AVP is where those identifiers go 💜.
8.57. User-Equipment-Info-IMEI AVP 📱
okay so the User-Equipment-Info-IMEI AVP (AVP Code 658) is an OctetString 🎀. It holds the International Mobile Equipment Identifier in the IMEI format, following 3GPP TS 23.003 [TGPPIMEI]. basically it's the phone's ID card 💅
8.58. Subscription-Id-Extension AVP 🦋
the Subscription-Id-Extension AVP (AVP Code 659) is how we identify the end user's subscription, and it's a Grouped type 🫶. the Subscription-Id-Extension group AVP MUST include an AVP holding the subscription identifier. the type of that included AVP tells you what kind of identifier it is. every enumerated value of the Subscription-Id-Type AVP has a matching sub-AVP you can use inside this group, and if a brand new identifier type ever shows up, a new sub-AVP SHOULD be defined for the Subscription-Id-Extension group AVP. so cute, extensible, iconic 🌈
if full backward compatibility with [RFC4006] is required, then the Subscription-Id AVP MUST be used for the identifier types enumerated in the Subscription-Id-Type AVP, whereas the Subscription-Id-Extension AVP MUST be used only for newly defined identifier types. the vibe is "old stuff stays where it lives, new stuff goes in the new spot" 🌸
if full backward compatibility with [RFC4006] is not required, then the Subscription-Id-Extension AVP MAY be used to carry the existing identifier types. in that case the Subscription-Id-Extension AVP MAY be sent together with the Subscription-Id AVP. choices, choices ✨
exactly one sub-AVP MUST be included inside the Subscription-Id-Extension AVP. one and only one, no sharing 🙈
the Subscription-Id-Extension AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Subscription-Id-Extension ::= < AVP Header: 659 >
[ Subscription-Id-E164 ]
[ Subscription-Id-IMSI ]
[ Subscription-Id-SIP-URI ]
[ Subscription-Id-NAI ]
[ Subscription-Id-Private ]
[ AVP ]8.59. Subscription-Id-E164 AVP 📞
the Subscription-Id-E164 AVP (AVP Code 660) is a UTF8String. it carries the international E.164 format (e.g., MSISDN), following the ITU-T E.164 numbering plan defined in [E164] and [CE164]. phone number energy 💖
8.60. Subscription-Id-IMSI AVP 🪪
the Subscription-Id-IMSI AVP (AVP Code 661) is a UTF8String. it contains the IMSI format, following the ITU-T E.212 identification plan as defined in [E212] and [CE212]. IMSI is giving "official ID with a plan" 💅
8.61. Subscription-Id-SIP-URI AVP 🎧
the Subscription-Id-SIP-URI AVP (AVP Code 662) is a UTF8String. it holds the identifier in the form of a SIP URI, as defined in [RFC3261]. very call-coded, very on-brand 📲
8.62. Subscription-Id-NAI AVP 🌷
the Subscription-Id-NAI AVP (AVP Code 663) is a UTF8String. it holds the identifier in the form of a Network Access Identifier, as defined in [RFC7542]. yes, another ID, we're collecting them all 🧚
8.63. Subscription-Id-Private AVP 🔒
the Subscription-Id-Private AVP (AVP Code 664) is a UTF8String. it contains a credit-control server private identifier. secret-sauce ID, only the server's inner circle gets to know 🤫
8.64. Redirect-Server-Extension AVP 🚀
the Redirect-Server-Extension AVP (AVP Code 665) is of type Grouped 🎀. it contains the address information of the redirect server (e.g., HTTP redirect server, SIP Server) that the end user is to be connected to when the account cannot cover the service cost. it MUST be present inside the QoS-Final-Unit-Indication AVP when the Final-Unit-Action AVP is set to REDIRECT. if the type of the redirect server is one of the enumerated values of the Redirect-Address-Type AVP, then the credit-control server SHOULD send the information in the Redirect-Server AVP, in addition to or instead of the Redirect-Server-Extension AVP. this keeps older credit-control clients that only support [RFC4006] happy 🫶 exactly one AVP MUST be included inside the Redirect-Server-Extension AVP. one little passenger, no more, no less 🙈
the Redirect-Server-Extension AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Redirect-Server-Extension ::= < AVP Header: 665 >
[ Redirect-Address-IPAddress ]
[ Redirect-Address-URL ]
[ Redirect-Address-SIP-URI ]
[ AVP ]8.65. Redirect-Address-IPAddress AVP 🌐
the Redirect-Address-IPAddress AVP (AVP Code 666) is of type Address and defines the IPv4 or IPv6 address of the redirect server that the end user is to be connected to when the account cannot cover the service cost.
when it's encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 format [RFC4291] MAY be used to indicate an IPv4 address. IPv4 dressed up as IPv6, very cute 🦋
the interpretation of Redirect-Address-IPAddress by the Diameter Credit-Control client is a matter of local policy. each client decides what it means for itself 💜
8.66. Redirect-Address-URL AVP 🔗
the Redirect-Address-URL AVP (AVP Code 667) is a UTF8String and defines the address of the redirect server that the end user is to be connected to when the account cannot cover the service cost. the address is in the form of a Uniform Resource Locator, as defined in [RFC3986]. heads up: individual URL schemes may restrict the contents of the UTF8String, so keep that in mind 👀
8.67. Redirect-Address-SIP-URI AVP 📨
the Redirect-Address-SIP-URI AVP (AVP Code 668) is a UTF8String and defines the address of the redirect server that the end user is to be connected to when the account cannot cover the service cost. the address is in the form of a SIP Uniform Resource Identifier, as defined in [RFC3261]. SIP again, we love a consistent vibe 🎶
8.68. QoS-Final-Unit-Indication AVP 👑
the QoS-Final-Unit-Indication AVP (AVP Code 669) is of type Grouped and indicates that the Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA-Answer contains the final units for the service. once those units expire, the Diameter Credit-Control client is responsible for executing the action indicated in the Final-Unit-Action AVP (see Section 5.6). the main character moment of the whole flow 🎬
if more than one unit type is received in the Credit-Control-Answer, the unit type that first expired SHOULD cause the credit-control client to execute the specified action. first one to expire wins, bestie 🏁
in the first interrogation, the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also be present with no Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA-Answer. this tells the Diameter Credit-Control client to execute the specified action immediately. if the home service provider policy is to terminate the service, naturally, the server SHOULD return the appropriate transient failure (see Section 9.1) in order to implement the policy-defined action. no drama, just policy 💀
the Final-Unit-Action AVP defines the behavior of the Service Element when the user's account cannot cover the cost of the service, and it MUST always be present if the QoS-Final-Unit-Indication AVP is included in a command. non-negotiable, it's the main event 🌸
if the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit-Indication group AVP MUST NOT contain any other AVPs. TERMINATE means it's a solo act, no backup dancers 🎭
if the Final-Unit-Action AVP is set to REDIRECT, then the Redirect-Server-Extension AVP MUST be present. the Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is also allowed to access other services that are not accessible through the address given in the Redirect-Server-Extension AVP, or if access to these services needs to be limited in some way (e.g., QoS). mix and match, it's a whole buffet 🍓
if the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Filter-Rule AVP or the Filter-Id AVP SHOULD be present. gatekeeper vibes 🔐
the Filter-Rule AVP is defined in [RFC5777]. it can be used to define a specific combination of a condition and an action. if it's only used with traffic conditions, it should define which traffic is allowed when no more service units are granted. however, if QoS or treatment information exists in the AVP, those actions should be executed, e.g., limiting the allowed traffic with certain QoS information. when multiple Filter-Rule AVPs exist, precedence should be determined as defined in [RFC5777]. rules within rules, very organized 🗂️
the Filter-Id AVP is defined in [RFC7155]. it can be used to reference an IP filter list installed in the access device by means other than the Diameter Credit-Control application, e.g., locally configured or configured by another entity. outsourcing the filter list, iykyk 🧾
if the Final-Unit-Action AVP is (1) set to TERMINATE, (2) set to RESTRICT_ACCESS and the action required is to allow only traffic that could be classified using an IPFilterRule, or (3) set to REDIRECT using a type that is one of the types in the Redirect-Address-Type AVP, then the credit-control server SHOULD send the information in the Final-Unit-Indication AVP, in addition to or instead of the QoS-Final-Unit-Indication AVP. this is done so older credit-control clients that support only [RFC4006] stay in the loop 🫶
the QoS-Final-Unit-Indication AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
QoS-Final-Unit-Indication ::= < AVP Header: 669 >
{ Final-Unit-Action }
*[ Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server-Extension ]
*[ AVP ]9. Result-Code AVP Values ✨
this section defines new Result-Code AVP [RFC6733] values that must be supported by all Diameter implementations that conform to this specification. the big rules for errors live here, so pay attention 📚
the Credit-Control-Answer message includes the Result-Code AVP, which may indicate that an error was present in the Credit-Control-Request message. a rejected Credit-Control-Request message SHOULD cause the user's session to be terminated. rejected request, session over 💔
9.1. Transient Failures 🌧️
errors in the category of transient failures are used to tell the peer that the request could not be satisfied at the time it was received, but that the request MAY be able to be satisfied in the future. not a no forever, just a "not right now" 🌤️
DIAMETER_END_USER_SERVICE_DENIED 4010the credit-control server denies the service request due to service restrictions. if the CCR contained used service units, they are deducted, if possible. ouch, but the units still get counted 😭
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011the credit-control server determines that the service can be granted to the end user, but that no further credit-control is needed for the service (e.g., the service is free of charge). free service, no paperwork needed, the dream 🍭
DIAMETER_CREDIT_LIMIT_REACHED 4012the credit-control server denies the service request because the end user's account could not cover the requested service. if the CCR contained used service units, they are deducted, if possible. wallet said no, units still get deducted if possible 💸
9.2. Permanent Failures
okay so permanent failures are the "don't bother retrying, bestie" errors 💅 they tell the peer the request failed and should not be attempted again. no cap, that's the whole vibe 💀
DIAMETER_USER_UNKNOWN 5030
the end user is unknown to the credit-control server 🙈
DIAMETER_RATING_FAILED 5031
this one tells the credit-control client that the server can't rate the service request. maybe the rating input is insufficient, the AVP combination is wrong, or there's an AVP or AVP value that the rating doesn't recognize or support 😭 the Failed-AVP AVP MUST be included and contain either (1) a copy of the entire AVP or AVPs that couldn't be processed successfully, or (2) an example of the missing AVP, complete with the Vendor-Id if applicable. the value field of the missing AVP should be of correct minimum length and contain zeros 🧚
10. AVP Occurrence Table 📋
the table in Section 10.1 lists the AVPs defined in this document and says which Diameter messages they MAY or MUST NOT be in 🎀 AVPs that can only show up inside a Grouped AVP aren't in the table, so don't look for them there, bestie 🫶
the table uses these symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message. It is considered an error if there is more
than one instance of the AVP.
1 One instance of the AVP MUST be present in the message.10.1. Credit-Control AVP Table
this table shows which credit-control application-specific AVPs from this document should be in the credit-control messages 🦋
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | CCR | CCA |
----------------------------------|-----+-----+
Acct-Multi-Session-Id | 0-1 | 0-1 |
Auth-Application-Id | 1 | 1 |
CC-Correlation-Id | 0-1 | 0 |
CC-Session-Failover | 0 | 0-1 |
CC-Request-Number | 1 | 1 |
CC-Request-Type | 1 | 1 |
CC-Sub-Session-Id | 0-1 | 0-1 |
Check-Balance-Result | 0 | 0-1 |
Cost-Information | 0 | 0-1 |
Credit-Control-Failure-Handling | 0 | 0-1 |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Direct-Debiting-Failure-Handling | 0 | 0-1 |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0+ |
Final-Unit-Indication | 0 | 0-1 |
QoS-Final-Unit-Indication | 0 | 0-1 |
Granted-Service-Unit | 0 | 0-1 |
Multiple-Services-Credit-Control | 0+ | 0+ |
Multiple-Services-Indicator | 0-1 | 0 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ |
Redirect-Host | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 |
Requested-Action | 0-1 | 0 |
Requested-Service-Unit | 0-1 | 0 |
Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 |
Service-Context-Id | 1 | 0 |
Service-Identifier | 0-1 | 0 |
Service-Parameter-Info | 0+ | 0 |
Session-Id | 1 | 1 |
Subscription-Id | 0+ | 0 |
Subscription-Id-Extension | 0+ | 0 |
Termination-Cause | 0-1 | 0 |
User-Equipment-Info | 0-1 | 0 |
User-Equipment-Info-Extension | 0-1 | 0 |
Used-Service-Unit | 0+ | 0 |
User-Name | 0-1 | 0-1 |
Validity-Time | 0 | 0-1 |
----------------------------------|-----+-----+10.2. Re-Auth-Request/Re-Auth-Answer AVP Table
this section defines AVPs that are specific to the Diameter Credit-Control application and that MAY be included in the Diameter Re-Auth-Request/Re-Auth-Answer (RAR/RAA) message [RFC6733] ✨ the RAR/RAA command MAY include these extra AVPs:
+---------------+
| Command Code |
|-------+-------+
Attribute Name | RAR | RAA |
------------------------------+-------+-------+
CC-Sub-Session-Id | 0-1 | 0-1 |
G-S-U-Pool-Identifier | 0-1 | 0-1 |
Service-Identifier | 0-1 | 0-1 |
Rating-Group | 0-1 | 0-1 |
------------------------------+-------+-------+11. RADIUS/Diameter Credit-Control Interworking Model 🌸
okay so this section is all about the prepaid interworking model 💖 It's basically the translation layer between a RADIUS-based prepaid setup and a Diameter Credit-Control application. The full blow-by-blow of those protocol translations is out of scope here, so it's giving "go read another doc for that" 📚 Yes, that doc SHOULD exist, and it's not this one.
The Diameter Credit-Control architecture can have a Translation Agent that speaks both RADIUS prepaid and Diameter Credit-Control 🦋 A AAA server (usually the home AAA server) can play that role, and it can also act as a Diameter Credit-Control client for Service Elements that use some other credit-control mechanism, like RADIUS prepaid 🧚 So the home AAA server reaches out to the Diameter Credit-Control server as part of authorization. The overall setup is in Figure 9, and the step-by-step flow is in Figure 10. When the user is roaming, the Service Element (like a NAS) might be in the visited network, and that's when a visited AAA server usually gets involved. That visited server then talks to the home AAA server, bestie 🌈
RADIUS Prepaid
+--------+ +---------+ Protocol +------------+ +--------+
| End |<----->| Service |<---------->| Home AAA | |Business|
| User | | Element | | Server | |Support |
+--------+ +-->| | |+----------+|->|System |
| +---------+ ||CC Client || | |
| |+----------+| | |
+--------+ | +------^-----+ +----^---+
| End |<--+ Credit-Control | |
| User | Protocol | |
+--------+ +-------V--------+ |
|Credit-Control |----+
| Server |
+----------------+
Figure 9: Credit-Control Architecture with Service Element
Containing Translation Agent, Translating RADIUS Prepaid
to Diameter Credit-Control ProtocolNow the flow itself 💅 When the AAA server acting as a Translation Agent gets an initial Access-Request from a Service Element (like NAS access), it does the usual authentication and authorization. If that Access-Request says the Service Element can do credit-control, AND the home AAA server finds the subscriber is prepaid, then a Credit-Control-Request SHOULD get sent toward the credit-control server to do credit authorization and set up a credit-control session 🔥 The Diameter Credit-Control server then checks the end user's balance, rates the service, and reserves credit from the account. The reserved quota comes back to the home AAA server in the Credit-Control-Answer, and the home AAA server passes it along to the Service Element in the Access-Accept. Iconic teamwork ✨
When the allocated quota runs out, the Service Element sends a new Access-Request carrying the units used so far to the home AAA server. The home AAA server shall map an Access-Request containing the reported units to the Diameter Credit-Control server in a Credit-Control-Request (UPDATE_REQUEST). The Diameter Credit-Control server debits the used units from the account and allocates a fresh quota, which goes back to the home AAA server in the Credit-Control-Answer. That quota then gets handed to the Service Element in the Access-Accept 🎀 When the end user ends the service, or when the whole quota has been used, the Service Element sends an Access-Request. To debit the used units and stop the credit-control session, the home AAA server sends a Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server. The Diameter Credit-Control server confirms the session termination with a Credit-Control-Answer back to the home AAA server. Finally, the Access-Accept goes to the NAS 👑
Figure 10 shows this whole interworking sequence 🧚
Service Element Translation Agent
(e.g., NAS) (CC Client) CC Server
| Access-Request | |
|----------------------->| |
| | CCR (Initial) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
| (Used-Units) | |
|----------------------->| |
| | CCR (Update, |
| | Used-Units) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
|----------------------->| |
| | CCR (Terminate, |
| | Used-Units) |
| |----------------------->|
| | CCA |
| |<-----------------------|
| Access-Accept | |
|<-----------------------| |
| | |
Figure 10: Message Flow Example with Diameter
Credit-Control / RADIUS Prepaid Interworking12. IANA Considerations 📋
okay IANA time, this part is about the registries 🌷 Some were originally made in [RFC4006], or they're values added to namespaces IANA already manages. IANA has updated them to point at this document, and the registries and their allocation policies are laid out below 💜
12.1. Application Identifier
This spec assigns the value 4, "Diameter Credit Control", to the "Application IDs" namespace defined in [RFC6733]. See Section 1.3 for more info 🦋
12.2. Command Codes
This spec uses the value 272 from the "Command Codes" namespace defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) commands 💖
12.3. AVP Codes
See Section 8 for the assignments in this spec 🎀
This document describes new AVP codes beyond the ones in [RFC4006]. IANA has allocated codes for the AVPs listed in Table 7, and it's giving very organized energy ✨
+-----------------------------------+------+--------------+
| Attribute Name | Code | Defined in |
+-----------------------------------+------+--------------+
| User-Equipment-Info-Extension | 653 | Section 8.52 |
| User-Equipment-Info-IMEISV | 654 | Section 8.53 |
| User-Equipment-Info-MAC | 655 | Section 8.54 |
| User-Equipment-Info-EUI64 | 656 | Section 8.55 |
| User-Equipment-Info-ModifiedEUI64 | 657 | Section 8.56 |
| User-Equipment-Info-IMEI | 658 | Section 8.57 |
| Subscription-Id-Extension | 659 | Section 8.58 |
| Subscription-Id-E164 | 660 | Section 8.59 |
| Subscription-Id-IMSI | 661 | Section 8.60 |
| Subscription-Id-SIP-URI | 662 | Section 8.61 |
| Subscription-Id-NAI | 663 | Section 8.62 |
| Subscription-Id-Private | 664 | Section 8.63 |
| Redirect-Server-Extension | 665 | Section 8.64 |
| Redirect-Address-IPAddress | 666 | Section 8.65 |
| Redirect-Address-URL | 667 | Section 8.66 |
| Redirect-Address-SIP-URI | 668 | Section 8.67 |
| QoS-Final-Unit-Indication | 669 | Section 8.68 |
+-----------------------------------+------+--------------+
Table 7: Requested AVP Assignments12.4. Result-Code AVP Values
This spec assigns the values 4010, 4011, and 4012 in the "Result-Code AVP Values (code 268) - Transient Failures" namespace 🌸 It also assigns 5030 and 5031 in the "Result-Code AVP Values (code 268) - Permanent Failure" namespace. Both namespaces were defined by [RFC6733]. See Section 9 for the assignments in this spec ✨
12.5. CC-Request-Type AVP
As defined in Section 8.3, the CC-Request-Type AVP includes Enumerated type values 1-4. IANA has created and maintains a namespace for this AVP 🧚 New values are subject to the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6.
12.6. CC-Session-Failover AVP
As defined in Section 8.4, the CC-Session-Failover AVP includes Enumerated type values 0-1. IANA has created and maintains a namespace for this AVP 💅 New values are subject to the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6.
12.7. CC-Unit-Type AVP
As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated type values 0-5. IANA has created and maintains a namespace for this AVP 🌈 New values are subject to the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6.
12.8. Check-Balance-Result AVP
As defined in Section 8.6, the Check-Balance-Result AVP includes Enumerated type values 0-1. IANA has created and maintains a namespace for this AVP 🍓 New values are subject to the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6.
12.9. Credit-Control AVP
As defined in Section 8.13, the Credit-Control AVP includes Enumerated type values 0-1. IANA has created and maintains a namespace for this AVP 💜 New values are subject to the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6.
12.10. Credit-Control-Failure-Handling AVP
As defined in Section 8.14, the Credit-Control-Failure-Handling AVP includes Enumerated type values 0-2. IANA has created and maintains a namespace for this AVP 🫶 New values are subject to the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6.
12.11. Direct-Debiting-Failure-Handling AVP 💸
Okay bestie, so per Section 8.15, the Direct-Debiting-Failure-Handling AVP has Enumerated type values 0-1 🎀. IANA already set up a namespace for it and keeps maintaining it 🗂️. Adding new values needs the Specification Required policy [RFC8126] plus the rules for enumerated values in [RFC7423], Section 5.6 💅.
12.12. Final-Unit-Action AVP 🦋
As defined in Section 8.35, the Final-Unit-Action AVP has Enumerated type values 0-2 🌸. IANA has its own namespace for this one too, and it's being maintained ✨. Any new values follow the Specification Required policy [RFC8126] and the enumerated-value conditions from [RFC7423], Section 5.6 🫶.
12.13. Multiple-Services-Indicator AVP 🍓
Per Section 8.40, the Multiple-Services-Indicator AVP comes with Enumerated type values 0-1 🧚. IANA created and keeps a namespace for it 📚. New values are subject to the Specification Required policy [RFC8126] and the enumerated-value conditions in [RFC7423], Section 5.6 💜.
12.14. Redirect-Address-Type AVP 🌈
As defined in Section 8.38, the Redirect-Address-Type AVP has Enumerated type values 0-3 👑. IANA set up and maintains a namespace for it 🔥. Adding values needs the Specification Required policy [RFC8126] and the enumerated-value rules from [RFC7423], Section 5.6 ⭐.
12.15. Requested-Action AVP 🎀
The Requested-Action AVP is defined in Section 8.41 and has Enumerated type values 0-3 💖. IANA created and is maintaining a namespace for it 🗂️. New values go through the Specification Required policy [RFC8126] and the conditions for enumerated values in [RFC7423], Section 5.6 ✨.
12.16. Subscription-Id-Type AVP 🔥
As defined in Section 8.47, the Subscription-Id-Type AVP includes Enumerated type values 0-4 😭. IANA has a namespace for it that it's actively maintaining 💅. Any new values are subject to the Specification Required policy [RFC8126] and the enumerated-value conditions in [RFC7423], Section 5.6 🫶.
12.17. Tariff-Change-Usage AVP 🌸
Per Section 8.27, the Tariff-Change-Usage AVP has Enumerated type values 0-2 🦋. IANA created a namespace for it and keeps it up to date 🗂️. New values follow the Specification Required policy [RFC8126] and the enumerated-value rules in [RFC7423], Section 5.6 🌈.
12.18. User-Equipment-Info-Type AVP 🧚
As defined in Section 8.50, the User-Equipment-Info-Type AVP has Enumerated type values 0-3 💜. IANA has a namespace for it, and it's being maintained 👑. Adding new values needs the Specification Required policy [RFC8126] and the enumerated-value conditions from [RFC7423], Section 5.6 ⭐.
13. Parameters Related to the Credit-Control Application 🎀
Tx timer ⏳
When real-time credit-control is needed, the credit-control client checks in with the credit-control server before and during the service for the end user 💖. Since it's real-time, communication delays SHOULD be minimized, e.g., so the end user doesn't get stuck waiting forever for service setup 🫠. The Tx timer exists to limit how long the client waits while sitting in the Pending state ⏳. When the Tx timer runs out, the client acts for the end user based on the value of the CCFH or the DDFH 🔥. The recommended value is 10 seconds ✨.
Tcc timer 🦋
The Tcc timer keeps watch over an ongoing credit-control session on the credit-control server 👀. It is RECOMMENDED to use the Validity-Time as input to set the Tcc timer value 💅. If there are transient failures in the network, the Diameter Credit-Control server might switch to Idle state 🙈. To help avoid that, the Tcc timer MAY be set so that Tcc is equal to 2 x Validity-Time 🌸.
Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 🍓
Client implementations may let you configure these AVPs locally 🧚. When they do, their values and behavior are defined in Sections 5.7 and 6.5, respectively 💜.
14. Security Considerations 🔐
Security considerations for the Diameter protocol itself are covered in [RFC6733] 🫶. The use of this application of Diameter MUST take into consideration the security issues and requirements of the base protocol 🔥.
This application has a mechanism for application-layer replay protection, using (1) the Session-Id AVP as specified in [RFC6733] and (2) the CC-Request-Number AVP, which is specified in this document ✨. The Diameter Credit-Control application is often used within one domain, and there may be a single hop between the peers 🌈. In these environments, using TLS/TCP, DTLS/SCTP (Datagram Transport Layer Security / Stream Control Transmission Protocol), or IPsec is sufficient 💖. The details on security considerations for TLS/TCP, DTLS/SCTP, and IPsec are in [RFC6733] 📚.
Because this application handles monetary transactions (directly or indirectly), it attracts more interest from various security attacks 😭. So all parties communicating with each other MUST be authenticated, including, for instance, TLS client-side authentication 🔒. On top of that, authorization of the client SHOULD be emphasized, meaning the client is allowed to perform credit-control for a certain user 👑. The specific means of authorization are outside the scope of this specification, but they can be, for instance, manual configuration 🎀.
Another kind of threat is malicious modification, injection, or deletion of AVPs or complete credit-control messages 💀. The credit-control messages carry sensitive billing-related information (such as subscription identifiers, granted units, used units, or cost information), and maliciously modifying it can have financial consequences 💸. Sometimes, just delaying the credit-control messages can cause disturbances in the credit-control client or server 🙈.
Even without any modifications to the messages, an adversary that can eavesdrop on transactions can obtain privacy-sensitive information 👀. Also, by monitoring the credit-control messages, someone can collect information about the credit-control server's billing models and business relationships 🕵️.
When third-party relays or proxies are involved, hop-by-hop security does not necessarily provide sufficient protection for Diameter user sessions 🚨. In some cases, it may be inappropriate to send Diameter messages, such as CCR messages and CCA messages, containing sensitive AVPs via untrusted Diameter proxy agents, because there are no assurances that third-party proxies won't modify the credit-control commands or AVP values 😱.
14.1. Direct Connection with Redirects 🧭
A Diameter Credit-Control agent cannot always know whether the agents between it and the end user's Diameter Credit-Control server are reliable 🤔. In this case, the agent doesn't have a routing entry in its Diameter routing table (defined in [RFC6733], Section 2.7) for the realm of the credit-control server in the end user's home realm 🗺️. The agent can have a default route configured to a local redirect agent, and it redirects the CCR message to that redirect agent 🔀. The local redirect agent then returns a redirect notification (Result-Code 3006, DIAMETER_REDIRECT_INDICATION) to the credit-control agent, along with information about the Diameter Credit-Control server(s) (Redirect-Host AVP) and how the routing entry resulting from the Redirect-Host is to be used (Redirect-Host-Usage AVP) 📬. The Diameter Credit-Control agent then forwards the CCR message directly to one of the hosts identified in the CCA message from the redirect agent 🚀. If the value of the Redirect-Host-Usage AVP does not equal zero, all subsequent messages go to the host in the Redirect-Host AVP until the time set by the Redirect-Max-Cache-Time AVP has expired ⏰.
Even with redirects, there are still some authorization issues 😬. Attacks may target nodes that were properly authorized but abuse that authorization or have been compromised 👿. These issues are discussed more widely in [RFC4072], Section 8 📖.
14.2. Application-Level Redirects 🚩
This document includes a redirection feature (Section 5.6.2) where the service provider can redirect the end user to an alternate location, in an application-specific way, when their credits have expired 💳. This is handy because the user can get back to normal service quickly, but it also opens the door to extra risks and attack surface 😰. This redirection can happen at an arbitrary point in a user's session, and the user may not have any extra context to confirm that the network is driving it 🫣. That lack of confirmation really matters, because in many application protocols the communication peer can also induce a redirect 🎣. When the peer is an attacker, the redirect can lead to an attacker-controlled site 🕸️. These might be "phishing" sites built to look like legitimate payment sites, so they can steal users' payment information for fraud 💀. Once users get used to these redirects, it gets harder for them to spot attacks versus legit redirects 😵.
Because arbitrary redirection by an attacker (such as to phishing sites) can have harmful consequences, it's important for service providers to know about that risk and make sure their users know about it too 📣. Service providers should follow industry best practices for the specific application-layer protocol to reduce the chances that such attacks get mistaken for legitimate redirections 🛡️. The details of such a practice are out of scope for this document 🙃.
15. Privacy Considerations 🫧
The Diameter protocol, and especially the credit-control application, deals with subscribers and what they do, so extra care should be taken with subscriber privacy 🥹. Using the terminology from [RFC6973], both the credit-control client and the credit-control server are intermediary entities. Subscriber privacy may be compromised there even if no security issues exist, so only authorized entities should have access to privacy-sensitive information 🔏💜.
15.1. Privacy-Sensitive AVPs ✨
Okay bestie, first things first 🚨 The privacy-sensitive AVPs in this section MUST NOT be sent across non-trusted networks or Diameter agents without end-to-end authentication and confidentiality protection, as described in [RFC6733], Section 13.3. No cap, that's a hard rule 🔒
Here's the list of AVPs that carry privacy-sensitive info, at different levels 👀
CC-Correlation-IdAVP: may contain privacy-sensitive information, bc the service provider may encode personal info that helps it correlate different subscriptions and access technologies 🕵️♀️Check-Balance-ResultAVP: contains info on the balance status of the subscriber 💸Currency-CodeAVP: contains info on the subscriber's locale 🌍Cost-UnitAVP: contains privacy-sensitive info for theCost-InformationAVP, in human-readable format 🙈Service-IdentifierAVP: may contain privacy-sensitive info about the subscriber's Internet activity 🌐Rating-GroupAVP: may contain privacy-sensitive info about the subscriber's Internet activity 🌐Restriction-Filter-RuleAVP: the info inside IPFilterRule may be used to infer services used by the subscriber 👀Redirect-Server-AddressAVP: this one is a big deal 🚩 The service provider might embed personal info on the subscriber in the URL/URI (e.g., to create a personalized message). However, the service provider may instead anonymize the subscriber's identity in the URL/URI and let the redirect server query the info directly. Such anonymized info must not allow personal info or the subscriber's identity to be easily guessed. Furthermore, the service provider should treat the URL/URI schema itself as confidential and make sure it cannot be inferred (1) from observation of the traffic or (2) due to its trivial structure. A trivial structure could allow an adversary to query/modify personal info even without knowing the subscriber's identity. Similar AVPs areRedirect-Address-URLandRedirect-Address-SIP-URI🎀Service-Context-IdAVP: depending on how the service provider uses it, it may contain privacy-sensitive info about the service (e.g., in a 3GPP networkService-Context-IdAVP, it has a different value for packet switching, SMS, Multimedia Messages (MMSs), etc.) 📱Service-Parameter-InfoAVP: depending on how the service provider uses it, it may contain privacy-sensitive info about the subscriber (e.g., location) 📍Subscription-Id-DataAVP: contains the identity of the subscriber 🪪 Similar AVPs areSubscription-Id-E164,Subscription-Id-IMSI,Subscription-Id-SIP-URI,Subscription-Id-NAI, andSubscription-Id-Private.User-Equipment-Info-ValueAVP: contains the identity of the subscriber's device 📲 Similar AVPs areUser-Equipment-Info-IMEISV,User-Equipment-Info-MAC,User-Equipment-Info-EUI64,User-Equipment-Info-ModifiedEUI64, andUser-Equipment-Info-IMEI.QoS-Final-Unit-IndicationAVP: a Grouped AVP that may contain privacy-sensitive info in its sub-AVPs (e.g., IPFilterRule, redirect address) 🧩
Note that some AVPs used in this document are defined in [RFC6733] and may contain privacy-sensitive information. These AVPs aren't listed above, so keep them in mind too 👀💜
15.2. Data Minimization 🧹
Okay so, the credit-control application kinda needs some personal data and identity info to work, so it has to be stored in both the credit-control client and the credit-control server 🥺 BUT, this can be minimized by following these guidelines, and I'm obsessed with them ✨
- Data stored in the credit-control client does not need to persist across sessions 💨 All data could be deleted once the session ends and could be reconstructed once a new session is initialized. Note that the credit-control server is usually owned by the service provider the subscriber already has some direct legal or business relationship with (where the privacy level could be agreed upon). This is not always true for a credit-control client, which may be owned by a third party 🏢
- Some info about the subscriber has to be stored in persistent storage in the credit-control server (e.g., identity, balance) 🗄️ However, per-transaction info does not have to be stored in persistent storage, and per-session info may be deleted from persistent storage once the session ends 🧹
- In some cases, per-transaction info has to be stored on the credit-control server, client, or both, for regulatory, auditability, or debugging reasons 📋 However, this could be minimized by following these guidelines:
A. Data retention does not need to exceed the required duration ⏳
B. Transaction info could be aggregated in some cases (e.g., prefer info per session over info per rating-group; prefer hourly byte summary over per-transaction byte counts) 📊
C. If not strictly needed, info that is more sensitive (e.g., location, equipment type) could be filtered out of such logs 🙈 This info is often used to make rating decisions, and in this case, the rating decisions should be logged instead of the data used to make them 🧠
D. Due to the reasons explained in the first guideline, the credit-control server, rather than the credit-control client, would be the preferred location for storing such transaction info 🏆
15.3. Diameter Agents 🛰️
Diameter agents, as described in [RFC6733], may be owned by third parties 👀 If end-to-end security is supported between the credit-control client and the credit-control server, the operator can use it to encrypt privacy-sensitive AVPs (as listed in Section 15.1) and stop that info from leaking into the agent 🔐
Sometimes the Diameter agent actually needs access to privacy-sensitive AVPs, so it can make correct routing decisions or even modify the content of these AVPs 🧭 For example, a proxy agent may need to look at the Subscription-Id-IMSI AVP, in order to extract the mobile country and network codes of the user and use them to look up the destination the request should be routed to (see Section 2.8.2 in [RFC6733]) 🗺️ In a case like that, the credit-control client and credit-control server may use a mechanism that anonymizes the subscriber's identity, plus a mechanism to encrypt the other AVPs the agent doesn't use 💖
16. References ✨
16.1. Normative References 📚
okay bestie, this is the must-read pile 💅✨
- [CE164] International Telecommunication Union, "COMPLEMENT TO ITU-T RECOMMENDATION E.164 (11/2010): LIST OF ITU-T RECOMMENDATION E.164 ASSIGNED COUNTRY CODES", November 2011,
<https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.164D-11-2011-PDF-E.pdf>. - [CE212] International Telecommunication Union, "COMPLEMENT TO RECOMMENDATION ITU-T E.212 (09/2016): LIST OF MOBILE COUNTRY OR GEOGRAPHICAL AREA CODES", February 2017,
<https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2017-PDF-E.pdf>. - [E164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010,
<https://www.itu.int/rec/T-REC-E.164/>. - [E212] International Telecommunication Union, "The international identification plan for public networks and subscriptions", ITU-T Recommendation E.212, September 2016,
<https://www.itu.int/rec/T-REC-E.212/en>. - [EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", August 2017,
<https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf>. - [ISO4217] ISO, "Codes for the representation of currencies", ISO 4217:2015, 2015,
<https://www.iso.org/iso-4217-currency-codes.html>. - [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. - [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, DOI 10.17487/RFC3539, June 2003,
<https://www.rfc-editor.org/info/rfc3539>. - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. - [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005,
<https://www.rfc-editor.org/info/rfc4006>. - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,
<https://www.rfc-editor.org/info/rfc4291>. - [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010,
<https://www.rfc-editor.org/info/rfc5777>. - [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. - [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. - [RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
<https://www.rfc-editor.org/info/rfc7155>. - [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter Applications Design Guidelines", BCP 193, RFC 7423, DOI 10.17487/RFC7423, November 2014,
<https://www.rfc-editor.org/info/rfc7423>. - [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. - [TGPPIMEI] 3rd Generation Partnership Project, Technical Specification Group Core Network, "Numbering, addressing and identification (release 15)", 3GPP TS 23.003 version 15.6.0, December 2018.
16.2. Informative References 🌸
these ones are the bonus reads, super helpful but not required 🫶
- [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/rfc2866>. - [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, DOI 10.17487/RFC3580, September 2003,
<https://www.rfc-editor.org/info/rfc3580>. - [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<https://www.rfc-editor.org/info/rfc3725>. - [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, DOI 10.17487/RFC4004, August 2005,
<https://www.rfc-editor.org/info/rfc4004>. - [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005,
<https://www.rfc-editor.org/info/rfc4072>. - [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. - [TGPPCHARG] 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, "Service aspects; Charging and Billing", 3GPP TS 22.115 version 15.5.0, September 2018.
Appendix A. Credit-Control Sequences 🎀
A.1. Flow I 🦋
okay bestie, let's look at the first flow 💖 it's a credit-control flow for Network Access Services prepaid, and you can see the whole thing in Figure 11 ✨ the Diameter protocol application lives in the Network Access Server (NAS) per [RFC7155] 🎀 and the main focus here is credit authorization 💅
NAS
End User (CC Client) AAA Server CC Server
|(1)User Logon |(2)AA-Request (CC AVPs) |
|------------------>|-------------------->| |
| | |(3)CCR(Initial, CC AVPs)
| | |-------------------->|
| | |(4)CCA(Granted-Units)|
| | |<--------------------|
| |(5)AA-Answer(Granted-Units) |
|(6)Access granted |<--------------------| |
|<----------------->| | |
| | | |
: : : :
| |(7)CCR(Update, Used-Units) |
| |-------------------->|(8)CCR |
| | | (Update, Used-Units)
| | |-------------------->|
| | |(9)CCA(Granted-Units)|
| |(10)CCA(Granted-Units)<--------------------|
| |<--------------------| |
: : : :
| (Auth. lifetime expires) | |
| |(11)AAR (CC AVP) | |
| |-------------------->| |
| | (12)AAA | |
| |<--------------------| |
: : : :
: : : :
|(13)User logoff | | |
|------------------>|(14)CCR(Term., Used-Units) |
| |-------------------->|(15)CCR |
| | | (Term., Used-Units)
| | |-------------------->|
| | | (16)CCA |
| | (17)CCA |<--------------------|
| |<--------------------| |
| |(18)STR | |
| |-------------------->| |
| | (19)STA | |
| |<--------------------| |
Figure 11: Flow Iokay so the user logs on to the network first (1) 🔐 then the Diameter NAS sends a Diameter AA-Request (AAR) over to the home Diameter AAA server (2) 📨 the credit-control client fills the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs get included too, as usual [RFC7155] 🎀 the home Diameter AAA server does its service-specific authentication and authorization, as usual ✨
next, the home server figures out the user is a prepaid user, and it notices from the Credit-Control AVP that the NAS has credit-control capabilities 👀 so it sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control server to do credit authorization (3) and set up a credit-control session 💅 (the home Diameter AAA server may forward service-specific AVPs it got from the NAS as input for the rating process, btw 🧚) the Diameter Credit-Control server checks the end user's account balance, rates the service, and reserves credit from the end user's account 💰 the reserved quota goes back to the home Diameter AAA server in the Diameter Credit-Control-Answer (4) and then the home server sends that reserved quota to the NAS in the Diameter AA-Answer (5) 🫶
once the NAS gets the AA-Answer, it starts the credit-control session and starts monitoring the granted units (5) and then it grants access to the end user (6) 🌈 when the allocated quota runs out, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the home Diameter AAA server (7) and this message carries the units used so far 📊 the home server forwards the CCR to the Diameter Credit-Control server (8) and that server debits the used units from the end user's account and allocates a new quota 🎀 it goes back to the home server in the Diameter Credit-Control-Answer (9), and then it's forwarded to the NAS (10) 💖
now, during the ongoing session, the authorization lifetime expires, and the authorization/authentication client in the NAS does service-specific re-authorization to the home Diameter AAA server, as usual 🔁 this time the credit-control client fills the AAR with the Credit-Control AVP set to RE_AUTHORIZATION, which indicates that the credit-control server shall not be contacted, because the credit authorization is controlled by the burning rate of the granted units (11) 🔥 the home Diameter AAA server does its service-specific re-authorization as usual and returns the AA-Answer to the NAS (12) ✨
then the end user logs off from the network (13) 👋 to debit the used units from the end user's account and stop the credit-control session, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the home Diameter AAA server (14) 💀 the home server forwards the CCR to the credit-control server (15) and the Diameter Credit-Control server acknowledges the session termination by sending a Diameter Credit-Control-Answer back to the home server (16) 🙈 the home server forwards that answer to the NAS (17) 🦋 and the STR/STA exchange happens between the NAS and the home Diameter AAA server, as usual (18), (19) 🫶
A.2. Flow II ✨
okay so Figure 12 is the example for Diameter Credit-Control for SIP sessions 💅. The whole point is the credit-control messages, and the SIP signaling is inaccurate on purpose 🙈, so this diagram is NOT a blueprint for a service provider's SIP network. still, for this example, some assumptions are made below. 🫶
SIP Proxy/Registrar AAA
A (CC Client) Server B CC Server
| (i) REGISTER | | | |
|------------->|(ii) | | |
| |------------->| | |
| |authentication & | |
| |authorization | | |
| |<-------------| | |
|(iii) 200 OK | | |
|<-------------| | |
: : : :
|(1) INVITE | :
|------------->|
| |(2) CCR (Initial, SIP-specific AVP) |
| |------------------------------------------->|
| |(3) CCA (Granted-Units) |
| |<-------------------------------------------|
| |(4) INVITE | |
| |---------------------------->| |
: : : :
| |(5) CCR (Update, Used-Units) |
| |------------------------------------------->|
| |(6) CCA (Granted-Units) |
| |<-------------------------------------------|
: : : :
|(7) BYE | | |
|------------->| | |
| |(8) BYE | |
| |---------------------------->| |
| |(9) CCR (Termination, Used-Units) |
| |------------------------------------------->|
| |(10) CCA () |
| |<-------------------------------------------|
| | | |
Figure 12: Flow IITypically, prepaid services based on, for example, time usage for SIP sessions need something in the service provider network to intercept all the requests within the SIP dialog 👀. That's how it catches the events that matter for credit control, like session establishment and session release 💰. So in this example, it's assumed that the SIP Proxy adds a Record-Route header in the initial SIP INVITE, so every future request in the created dialog goes through it 🛣️ (for the definitions of "Record-Route" and "dialog", check [RFC3261]). And how much media the proxy measures for credit control depends on the business model used when the end systems and proxies in the SIP network get set up 📊.
So the end user (SIP User Agent A) sends a REGISTER with credentials (i) 🔑. The SIP Proxy asks the home AAA server to do multimedia authentication and authorization, using a Diameter multimedia application for instance (ii). The home AAA server checks that the credentials are correct and checks the user profile 🕵️♀️. Eventually a 200 OK (iii) goes back to the User Agent ✅. Heads up, the authentication and authorization are valid for the registration validity period (aka until re-registration happens), so several SIP sessions can be set up without re-authorization 🌸.
User Agent A sends an INVITE (1) 📞. The SIP Proxy sends a Diameter Credit-Control-Request (INITIAL_REQUEST) to the Diameter Credit-Control server (2). That request carries info pulled from the SIP signaling that describes the service (calling party, called party, Session Description Protocol (SDP) attributes, etc.). The Diameter Credit-Control server checks the end user's account balance, rates the service, and reserves credit from the end user's account 🏦. The reserved quota comes back to the SIP Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy forwards the SIP INVITE to User Agent B (4), B's phone rings, and B picks up 📲. The media flows between them while the SIP Proxy starts measuring the quota 🎶.
When the allocated quota runs out, the SIP Proxy sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (5). This message has the units used so far 📉. The server debits those used units from the end user's account and allocates new credit, which comes back to the SIP Proxy in the Diameter Credit-Control-Answer (6) 💸. Then the end user ends the call with a BYE message (7) 👋. The SIP Proxy forwards that BYE to User Agent B (8) and sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server (9). The Diameter Credit-Control server acknowledges the session termination by sending a Diameter Credit-Control-Answer back to the SIP Proxy (10) 🎀.
A.3. Flow III 🦋
A credit-control flow for Multimedia Messaging Service is shown in Figure 13. The sender gets charged as soon as the messaging server successfully stores the message 📩💅.
MMS Server
A (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (Event, DIRECT_DEBITING, |
| | MMS-specific AVP) |
| |-------------------------------->|
| |(3) CCA (Granted-Units) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure 13: Flow IIIThis is an example of Diameter Credit-Control for direct debiting in the Multimedia Messaging Service environment 📱. The flow is all about showing off the credit-control messages, and the MMS signaling is inaccurate, so the diagram is not an attempt to define a service provider's MMS configuration or billing model. it's just vibes, bestie 🫶.
End user A sends an MMS to the MMS server (1) 💌. The MMS server stores the message and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to DIRECT_DEBITING) to the Diameter Credit-Control server (2). That request has info about the MMS message (size, recipient address, image coding type, etc.). The Diameter Credit-Control server checks the end user's account balance, rates the service, and debits the service from the end user's account 🤑. The granted quota comes back to the MMS server in the Diameter Credit-Control-Answer (3).
The MMS server acknowledges that it successfully received the MMS message (4) ✅. Then it notifies the recipient about the new MMS (5), and end user B grabs the message from the MMS message store (6), (7) 📬✨.
Note that transferring the MMS message can take an extended period of time and can fail 😬, in which case a recovery action is needed. The MMS server should return the already-debited units to the user's account by using the REFUND action described in Section 6.4 💜.
A.4. Flow IV
Okay bestie, check out Figure 14 🎀✨ This flow is for Multimedia Messaging Service (MMS), and the recipient is the one who gets charged, and it happens at the moment the message is delivered 💅
MMS Server
Content Server (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (Event, CHECK_BALANCE, |
| | MMS-specific AVP) |
| |-------------------------------->|
| |(3) CCA (ENOUGH_CREDIT) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) CCR (Event, DIRECT_DEBITING, |
| | MMS-specific AVP) |
| |-------------------------------->|
| |(8) CCA (Granted-Units) |
| |<--------------------------------|
| |(9) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |Figure 14: Flow IV
Okay so this is an example of Diameter Credit-Control for direct debiting in the MMS world 🦋 The flow is mostly about showing how the credit-control messages get used, and the MMS signaling is inaccurate on purpose. This diagram is NOT trying to define a service provider's MMS setup or billing model, so don't take it as gospel for your carrier 🙈
Here's the story. A content server sends an MMS to the MMS server (1), and the MMS server stores it 🌸 The message recipient is the one getting charged in this case. Now, there can be a seriously long gap between the MMS hitting the server and the recipient actually grabbing it, so the MMS server does NOT open any credit-control sessions with the Diameter Credit-Control server ngl 😭 Instead, it first does only a balance check, with no credit reservations, by sending a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to CHECK_BALANCE) to make sure end user B can cover the cost of the MMS (2). The Diameter Credit-Control server checks the end user's account balance and sends the answer back to the MMS server in the Diameter Credit-Control-Answer (3) 💖 The MMS server then acknowledges that it successfully received the MMS message (4). It notifies the recipient about the new MMS (5), and after some time, end user B retrieves the message from the MMS message store (6) 🧚
Then the MMS server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to DIRECT_DEBITING) to the Diameter Credit-Control server (7). The Credit-Control-Request carries info about the MMS message (for example, size, recipient address, coding type) ✨ The Diameter Credit-Control server checks the end user's account balance, rates the service, and debits the service from the end user's account 👑 The granted quota comes back to the MMS server in the Diameter Credit-Control-Answer (8). Finally, the MMS is transferred to end user B (9) 🫶
Heads up bestie: the MMS transfer can take a long time and can also fail, in which case a recovery action is needed 💀 The MMS server SHOULD return the already-debited units to the user's account by using the REFUND action described in Section 6.4.
A.5. Flow V
Next up is Figure 15, which shows an Advice of Charge (AoC) service for a SIP call 📞🌈
SIP Controller
User Agent A (CC Client) User Agent B CC Server
|(1)INVITE | | |
| User Agent B(SDP)| | |
|------------------>| | |
| |(2)CCR (Event, PRICE_ENQUIRY, |
| | SIP-specific AVPs) |
| |------------------------------->|
| |(3)CCA (Cost-Information) |
| |<-------------------------------|
|(4)MESSAGE(URL) | | |
|<------------------| | |
|(5)HTTP GET | | |
|------------------>| | |
|(6)HTTP POST | | |
|------------------>|(7)INVITE(SDP) | |
| |--------------->| |
| | (8)200 OK | |
| (9)200 OK |<---------------| |
|<------------------| | |Figure 15: Flow V
This is an example of Diameter Credit-Control for SIP sessions 🎀 Again, it's mostly about the credit-control messages, and the SIP signaling is inaccurate. The diagram is NOT an attempt to define a service provider's SIP network, so chill on that 💅
User Agent A can be either a postpaid or prepaid subscriber using the AoC service. It's assumed the SIP controller also has HTTP capabilities and delivers an interactive AoC web page with, for instance, the cost info, the call details derived from the SDP, and a button to accept or not accept the charges 🌸 (There may be lots of other ways to deliver AoC info, but this flow focuses on the credit-control messages.) The user has been authenticated and authorized before starting the call, and has been subscribed to the AoC service 🔥
So User Agent A sends an INVITE with the SDP to User Agent B via the SIP controller (1). The SIP controller sees that the user is subscribed to an AoC service and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to PRICE_ENQUIRY) to the Diameter Credit-Control server (2) 🧚 The Credit-Control-Request has SIP-specific AVPs pulled from the SIP signaling, describing the requested service (for example, calling party, called party, SDP attributes). The Diameter Credit-Control server works out the cost of the service and returns the Credit-Control-Answer, including the Cost-Information AVP (3) ✨ The SIP controller builds the AoC web page using info from the SIP signaling and the cost info from the credit-control server. Then it sends a SIP MESSAGE containing a URL pointing to the AoC information web page (4) 💖 When User Agent A gets the SIP MESSAGE, it automatically opens the web browser, which retrieves the AoC information (5). The user clicks the button to accept the charges (6) 👑 The SIP controller then continues the session and sends the INVITE to User Agent B, which accepts the call (7), (8), (9) 📞
A.6. Flow VI
Figure 16 is a credit-control flow for the REFUND case 🦋 It's assumed there's a trusted relationship and secure connection between the gaming server and the Diameter Credit-Control server. The end user may be a prepaid subscriber or a postpaid subscriber 🎮
Gaming Server
End User (CC Client) CC Server
| (1)Service Delivery | |
|<---------------------->| |
: : :
: : :
| |(2)CCR(Event, REFUND,Requested-
| |Service-Unit, Service-Parameter-Info)
| |----------------------->|
| | (3)CCA(Cost-Information)
| |<-----------------------|
| (4)Notification | |
|<-----------------------| |Figure 16: Flow VI
While the end user is playing the game (1), they hit a new level that gives them a bonus 🎉 The gaming server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to REFUND_ACCOUNT) to the Diameter Credit-Control server (2) 💜 The Credit-Control-Request carries the Requested-Service-Unit AVP, with the CC-Service-Specific-Units holding the number of points the user just won. The Service-Parameter-Info AVP is also in the request, and it specifies the service event to be rated (for example, Tetris Bonus) 🍓 From the info it received, the Diameter Credit-Control server works out the amount to be credited, refunds the user's account, and returns the Credit-Control-Answer, including the Cost-Information AVP (3). The Cost-Information AVP shows the credited amount. At the first chance it gets, the gaming server tells the end user the credited amount (4) 🌈
A.7. Flow VII
Okay bestie, Flow VII is giving graceful service termination for a SIP call 📞✨ Picture this: the call is set up so the controller is in the middle as a B2BUA (Back-to-Back User Agent) doing third-party call control (3PCC) 💅. Heads up, the SIP signaling in this one is kinda inaccurate on purpose, because the focus is on graceful service termination and credit-control authorization 🙈. If you want the 3PCC best practices, they're defined in [RFC3725] 🎀
SIP Controller Top-Up User Agent A (CC Client) Server User Agent B CC Server
| (1)CCR(Update, Used-Units) | ||
|---|---|---|
| ------------------------------------------> | ||
| (2)CCA(Final-Unit, Redirect) | ||
| <------------------------------------------ |
: : : : : : : : : :
| (3)CCR(Update, Used-Units) | |||
|---|---|---|---|
| ------------------------------------------> | |||
| (3a)INVITE("hold") | |||
| ---------------------------> | |||
| (4)CCA(Validity-Time) | |||
| <------------------------------------------ | |||
| (5)INVITE | (6)INVITE | ||
| <--------------- | -------------> | ||
| (7)RTP | |||
| ............................... | |||
| (8)BYE | |||
| <------------- | |||
| (9)CCR(Update) | |||
| ------------------------------------------> | |||
| (10)CCA(Granted-Units) | |||
| <------------------------------------------ | |||
| (12)INVITE | (11)INVITE | ||
| <--------------- | ---------------------------> |
Figure 17: Flow VII
So the call is ongoing between User Agents A and B, and User Agent A has a prepaid subscription 💖 When the allocated quota runs out, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (1). That message carries the units used so far 📊 The server debits those used units from the end user's account and hands back the final quota in the Diameter Credit-Control-Answer (2). This answer has the Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT, Redirect-Address-Type set to SIP URI, and Redirect-Server-Address set to the top-up server name (e.g., sip:sip-topup-server@domain.com) 🦋
When that final quota runs out too, the SIP controller sends another Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (3) and puts the called party on "hold" by sending an INVITE with the right connection address in the SDP (3a) 🌸 The CCR again carries the units used so far, and the server debits them but makes no credit reservations at all 🙅♀️ The Credit-Control-Answer comes back with the Validity-Time that supervises the graceful service termination process (4) 🧚
Next, the SIP controller sets up a SIP session between the prepaid user and the top-up server (5), (6) 📱 The top-up server plays an announcement and asks the user to enter a credit card number and how much money they want to top up with (7) 💳 Then it validates the card, replenishes the account (using some means outside the scope of this specification), and releases the SIP session (8) ✨ Now the SIP controller can assume the prepaid user and the top-up server actually talked, and it sends a spontaneous Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server to check whether the account got replenished (9) 👑 If it did, the server reserves credit from the end user's account and returns the reserved quota in the Credit-Control-Answer (10) 🎉 At this point, the SIP controller reconnects the caller and the called party (11), (12) 🥳💜
A.8. Flow VIII
Flow VIII is graceful service termination kicked off by the very first interrogation, because the user's account is empty 💀 In this example, the credit-control server supports server-initiated credit re-authorization 🔥 Also, the Diameter protocol application is implemented in the NAS per [RFC7155] 🛜
NAS Top-Up CC End User (CC Client) AAA Server Server Server
| (1)User Logon | (2)AA-Request (CC AVPs) | ||
|---|---|---|---|
| ------------------> | -------------------> | ||
| (3)CCR(Initial, CC AVPs) | |||
| -------------------> | |||
| (4)CCA(Final-Unit, | |||
| Validity-Time) | |||
| <------------------- | |||
| (5)AA-Answer(Final-Unit, Validity-Time) | |||
| (6)Limited access | <------------------- | ||
| granted | |||
| <-----------------> | |||
| (7)TCP/HTTP | (8)TCP/HTTP | ||
| <-----------------> | <-----------------------------> | ||
| (9)Replenish account | |||
| <-------------------------------------------------> | |||
| (10)RAR | |||
| <------------------- | <------------------- | ||
| (11)RAA | |||
| -------------------> | -------------------> | ||
| (12)CCR(Update) | |||
| -------------------> | (13)CCR(Update) | ||
| -------------------> | |||
| (14)CCA(Granted-Units) | |||
| (15)CCA(Granted-Units)<------------------ | |||
| <------------------- |
Figure 18: Flow VIII
The user logs on to the network (1) 🔑 The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server (2) 📨 The credit-control client fills the AAR in with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included as usual [RFC7155] 🧾 The home Diameter AAA server does its service-specific authentication and authorization as usual 🙌 It figures out the user has a prepaid subscription, and it notices from the Credit-Control AVP that the NAS has credit-control capabilities 👀 So it sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control server to do credit authorization (3) and set up a credit-control session (3) 💅 (Quick aside: the home Diameter AAA server MAY forward service-specific AVPs received from the NAS as input for the rating process 🧠)
The Diameter Credit-Control server checks the end user's account balance, sees that the account can't cover the cost of the service, and starts graceful service termination 😬 The Credit-Control-Answer goes back to the home Diameter AAA server (4). This message has the Final-Unit-Indication AVP and a Validity-Time AVP set to a reasonable amount of time, so the user has a chance to top up, for example 10 minutes ⏰ The Final-Unit-Indication AVP includes Final-Unit-Action set to REDIRECT, Redirect-Address-Type set to URL, and Redirect-Server-Address set to the HTTP top-up server name 🌐 The home Diameter AAA server then passes the received Credit-Control AVPs to the NAS in the Diameter AA-Answer (5) 📬 If AAA succeeds, the NAS starts the credit-control session and immediately begins graceful service termination, just as the server instructed 🚦 The NAS grants the user limited access (6) 🔒
The HTTP client software on the user's device opens the transport connection that the NAS redirected to the top-up server (7), (8) 🌈 The user gets a nice web page where they can enter a credit card number and how much money to top up with, plus a heads-up that they get unlimited access if the top-up goes through within, say, the next 10 minutes ⭐ The top-up server validates the card and replenishes the account (using some means outside the scope of this specification) (9) 💸 After a successful top-up, the credit-control server sends a Re-Auth-Request message to the NAS (10) 📣 The NAS acknowledges it with a Re-Auth-Answer message (11) and kicks off credit re-authorization by sending a Credit-Control-Request (UPDATE_REQUEST) to the Diameter Credit-Control server (12), (13) 🫶
The Diameter Credit-Control server reserves credit from the end user's account and sends the reserved quota back to the NAS through the home Diameter AAA server in the Credit-Control-Answer (14), (15) 🎊 Then the NAS lifts the restriction from graceful service termination and starts monitoring the granted units 🥂✨
A.9. Flow IX
Flow IX is all about the Multiple-Services-Credit-Control AVP, which is defined by the Diameter Credit-Control application 💜 It lets you do independent credit-control of multiple services inside a single credit-control (sub-)session, for Service Elements that can handle that 🧚♀️ You can also request and allocate resources as a credit pool that's shared between services or rating-groups 🍓
Figure 19 shows a usage scenario where the credit-control client and server support independent credit-control of multiple services, as defined in Section 5.1.2 🦋 It's assumed that service-identifiers, rating-groups, and their associated parameters (e.g., IP 5-tuples) are configured locally in the Service Element, or provisioned by some entity other than the credit-control server 🌸
Okay bestie, Flow IX is the grand finale 💅 Here's the whole diagram, then the tea ☕
End User Service Element CC Server
(CC Client)
|(1)User logon | |
|------------------>|(2)CCR(Initial, Service-Id access, |
| | Access-specific AVPs, |
| | Multiple-Services-Indicator) |
| |------------------------------------------->|
| |(3)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<-------------------------------------------|
: : :
|(4)Service-Request (Service 1) |
|------------------>|(5)CCR(Update, Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 1, |
| | Rating-Group 1)) |
| |------------------------------------------->|
| |(6)CCA(Multiple-Services-CC ( |
| | Granted-Units(Time), |
| | Rating-Group 1, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 1))) |
| |<-------------------------------------------|
: : :
|(7)Service-Request (Service 2) |
|------------------>| |
: : :
: : :
|(8)Service-Request (Services 3 & 4) |
|------------------>|(9)CCR(Update, Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 3, |
| | Rating-Group 2), |
| | Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 4, |
| | Rating-Group 3)) |
| |------------------------------------------->|
| |(10)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 3, Rating-Group 2, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 2)), |
| | Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 4, Rating-Group 3 |
| | Validity-Time, |
| | Final-Unit-Ind.(Terminate), |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 5))) |
| |<-------------------------------------------|
: : :
: : :
| +--------------+ | |
| |Validity time | |(11)CCR(Update, |
| |expires for | | Multiple-Services-CC ( |
| |Service-Id | | Requested-Unit(), |
| | access | | Used-Units(In-Octets, Out-Octets), |
| +--------------+ | Service-Id access)) |
| |------------------------------------------->|
| |(12)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<-------------------------------------------|
: : :
: : :
| +--------------+ | |
| |Total quota | |(13)CCR(Update, |
| |elapses for | | Multiple-Services-CC ( |
| |Pool 2: | | Requested-Unit(), |
| |Service 4 not | | Used-Units(In-Octets, Out-Octets),|
| |allowed, | | Service-Id 3, Rating-Group 2), |
| |Service 3 | | Multiple-Services-CC ( |
| |continues | | Used-Units(In-Octets, Out-Octets),|
| +--------------+ | Service-Id 4, Rating-Group 3)) |
| |------------------------------------------->|
| |(14)CCA(Multiple-Services-CC ( |
| | Result-Code 4011, |
| | Service-Id 3)) |
| |<-------------------------------------------|
: : :
: : :
|(15)User logoff | |
|------------------>|(16)CCR(Term., |
| | Multiple-Services-CC ( |
| | Used-Units(In-Octets, Out-Octets),|
| | Service-Id access), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 1, Rating-Group 1), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 2, Rating-Group 1)) |
| |------------------------------------------->|
| |(17)CCA(Term.) |
| |<-------------------------------------------|
Figure 19: Flow IX: Example of Independent Credit-Control of
Multiple Services in a Credit-Control (Sub-)SessionThe user logs on to the network (1) 🔐. The Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter Credit-Control server, so it can do credit authorization for the bearer service (e.g., Internet access service) and open a credit-control session (2) 🌸. In that message the client says it supports independent credit-control of multiple services within the session by including the Multiple-Services-Indicator AVP ✨. The server checks the end user's account balance using the rating info the client sent (Service-Id and access-specific AVPs), rates the request, and reserves credit from the end user's account 💰. Say the server reserves $5 and figures the cost is $1/MB. It sends back a Credit-Control-Answer with the Multiple-Services-Credit-Control AVP: a quota of 5 MB tied to Service-Id (access), a multiplier value of 10, and Pool-Id 1 (3) 🎀.
The user uses service 1 (4) 🦋. The Service Element sends a Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the server to get credit authorization for service 1 (5). It asks for service units for service 1 that belong to Rating-Group 1. The server sees that service 1 draws credit from the same account as the access service (that's pool 1), rates the request by Service-Id/rating-group, and updates the existing reservation by asking for more credit. Say it reserves $5 more (so the reservation is now $10) and the cost is $0.1/minute. The server authorizes the whole rating-group 🔥. The Credit-Control-Answer then gives a quota of 50 minutes for Rating-Group 1, a multiplier value of 1, and Pool-Id 1 (6). The client adjusts the total for pool 1 based on that quota, which gives S for pool 1 = 100 🧚.
The user uses service 2, which belongs to the authorized rating-group (Rating-Group 1) (7). Resources get consumed from pool 1 💜.
Now the user wants services 3 and 4 too, but those aren't authorized yet (8) 👀. The Service Element sends a Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the server to authorize services 3 and 4 (9). This message has two instances of the Multiple-Services-Credit-Control AVP: one requests service units for service 3 in Rating-Group 2, and the other requests service units for service 4 in Rating-Group 3. The server figures out that services 3 and 4 draw credit from another account (pool 2). It checks the end user's balance, rates the request by Service-Id/rating-group information, and reserves credit from pool 2 💅.
For example, the server reserves $5 and decides service 3 costs $0.2/MB and service 4 costs $0.5/MB. It authorizes only services 3 and 4 🙈. The Credit-Control-Answer has two instances of the Multiple-Services-Credit-Control AVP (10). One grants a quota of 12.5 MB for Service-Id 3, with a multiplier value of 2 and Pool-Id 2. The other grants a quota of 5 MB for Service-Id 4, with a multiplier value of 5 and Pool-Id 2 🍓.
The server also notices that pool 2 is running out, and service 4 isn't allowed to keep going once these units are used up 😭. So the Final-Unit-Indication AVP with action TERMINATE is attached to Service-Id 4. The client works out the total resources for pool 2 from the quotas and multipliers, which gives S for pool 2 = 50 ✨. That's the whole Flow IX, iconic behaviour from start to finish 👑
Okay so the Validity-Time for the access service just ran out ⏰😭. The Service Element sends a Credit-Control-Request to the server to re-authorize credit for the Service-Id (access) (11). This message carries one instance of the Multiple-Services-Credit-Control AVP that includes the units used by this service. Say the total used units hit 4 MB. The client updates the total resources for pool 1 to match, which gives S for pool 1 = 60 🧮.
The server takes $4 from the user's account and tops up the reservation by asking for more credit 💸. Let's say it reserves $5 more, so the reservation is now $11, and it already knows the Service-Id (access) costs $1/MB 🤑. It sends back a Credit-Control-Answer that includes a Multiple-Services-Credit-Control AVP with a quota of 5 MB tied to the Service-Id (access), a multiplier value of 10, and Pool-Id 1 (12) ✨. The client updates the pool 1 total based on that quota, which gives S for pool 1 = 110 🎉.
Services 3 and 4 are eating through the pool 2 credit, since C1*2 + C2*5 >= S 😬. The Service Element immediately kicks off the TERMINATE action for service 4 and sends a Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server so it can re-authorize service 3 (13) 🫶. This message has two instances of the Multiple-Services-Credit-Control AVP, one reporting units for service 3 and one for service 4. The server takes the last $5 from the user's account (pool 2) and replies with Result-Code 4011 in the Multiple-Services-Credit-Control AVP, which means service 3 can keep going without credit-control (14) 💅.
The end user logs off the network (15) 👋. To debit the used units from the end user's account and stop the credit-control session, the Service Element sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the credit-control server (16) 🌸. This message has the units used by each service in multiple instances of the Multiple-Services-Credit-Control AVP. The used units are tied to the matching Service-Identifier and rating-group 🍓. The Diameter Credit-Control server debits those units from the user's account (pool 1) and confirms the session termination by sending a Diameter Credit-Control-Answer to the Service Element (17) 💖.
Acknowledgements 🫶
The original authors of RFC 4006 are Harri Hakala, Leena Mattila, Juha-Pekka Koskinen, Marco Stura, and John Loughney 🌟.
The authors would like to thank Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Jussi Maki, Paco Marin, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions 💜. Thank you all, you're literally the reason this spec slaps 🙏.
Authors' Addresses 🦋
Lyle Bertz (editor)
Sprint
6220 Sprint Parkway
Overland Park, KS 66251
United States of America
Email: lyleb551144@gmail.com
David Dolson (editor)
Sandvine
408 Albert Street
Waterloo, ON N2L 3V3
Canada
Email: ddolson@acm.org
Yuval Lifshitz (editor)
Sandvine
408 Albert Street
Waterloo, ON N2L 3V3
Canada
Email: yuvalif@yahoo.com📦 where this page comes from
- ietf: rfc8506 2019-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms