idnits 2.17.1 draft-ietf-dime-rfc4006bis-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2018) is 2052 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CE164' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE212' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' -- Possible downref: Non-RFC (?) normative reference: ref. 'E212' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPPIMEI' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Bertz, Ed. 3 Internet-Draft Sprint 4 Obsoletes: 4006 (if approved) D. Dolson, Ed. 5 Intended status: Standards Track Y. Lifshitz, Ed. 6 Expires: March 17, 2019 Sandvine 7 September 13, 2018 9 Diameter Credit-Control Application 10 draft-ietf-dime-rfc4006bis-12 12 Abstract 14 This document specifies a Diameter application that can be used to 15 implement real-time credit-control for a variety of end user services 16 such as network access, Session Initiation Protocol (SIP) services, 17 messaging services, and download services. The Diameter Credit- 18 Control application as defined in this document obsoletes RFC4006, 19 and it must be supported by all new Diameter Credit-Control 20 Application implementations. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 17, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 71 1.3. Advertising Application Support . . . . . . . . . . . . . 8 72 2. Architecture Models . . . . . . . . . . . . . . . . . . . . . 8 73 3. Credit-Control Messages . . . . . . . . . . . . . . . . . . . 10 74 3.1. Credit-Control-Request (CCR) Command . . . . . . . . . . 10 75 3.2. Credit-Control-Answer (CCA) Command . . . . . . . . . . . 11 76 4. Credit-Control Application Overview . . . . . . . . . . . . . 12 77 4.1. Service-Specific Rating Input and Interoperability . . . 14 78 4.1.1. Specifying Rating Input AVPs . . . . . . . . . . . . 14 79 4.1.2. Service-Specific Documentation . . . . . . . . . . . 15 80 4.1.3. Handling of Unsupported/Incorrect Rating Input . . . 16 81 4.1.4. RADIUS Vendor-Specific Rating Attributes . . . . . . 16 82 5. Session Based Credit-Control . . . . . . . . . . . . . . . . 16 83 5.1. General Principles . . . . . . . . . . . . . . . . . . . 16 84 5.1.1. Basic Tariff-Time Change Support . . . . . . . . . . 17 85 5.1.2. Credit-Control for Multiple Services within a 86 (sub-)Session . . . . . . . . . . . . . . . . . . . . 18 87 5.2. First Interrogation . . . . . . . . . . . . . . . . . . . 22 88 5.2.1. First Interrogation after Authorization and 89 Authentication . . . . . . . . . . . . . . . . . . . 24 90 5.2.2. First Interrogation Included with Authorization 91 Messages . . . . . . . . . . . . . . . . . . . . . . 25 92 5.3. Intermediate Interrogation . . . . . . . . . . . . . . . 28 93 5.4. Final Interrogation . . . . . . . . . . . . . . . . . . . 30 94 5.5. Server-Initiated Credit Re-Authorization . . . . . . . . 31 95 5.6. Graceful Service Termination . . . . . . . . . . . . . . 33 96 5.6.1. Terminate Action . . . . . . . . . . . . . . . . . . 36 97 5.6.2. Redirect Action . . . . . . . . . . . . . . . . . . . 37 98 5.6.3. Restrict Access Action . . . . . . . . . . . . . . . 39 99 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 40 100 5.7. Failure Procedures . . . . . . . . . . . . . . . . . . . 40 101 6. One Time Event . . . . . . . . . . . . . . . . . . . . . . . 43 102 6.1. Service Price Enquiry . . . . . . . . . . . . . . . . . . 44 103 6.2. Balance Check . . . . . . . . . . . . . . . . . . . . . . 45 104 6.3. Direct Debiting . . . . . . . . . . . . . . . . . . . . . 45 105 6.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . . 46 106 6.5. Failure Procedure . . . . . . . . . . . . . . . . . . . . 47 107 7. Credit-Control Application State Machine . . . . . . . . . . 49 108 8. Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . . 57 109 8.1. CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . . 60 110 8.2. CC-Request-Number AVP . . . . . . . . . . . . . . . . . . 60 111 8.3. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 61 112 8.4. CC-Session-Failover AVP . . . . . . . . . . . . . . . . . 61 113 8.5. CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . . 62 114 8.6. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 62 115 8.7. Cost-Information AVP . . . . . . . . . . . . . . . . . . 63 116 8.8. Unit-Value AVP . . . . . . . . . . . . . . . . . . . . . 63 117 8.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . . 64 118 8.10. Value-Digits AVP . . . . . . . . . . . . . . . . . . . . 64 119 8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . . 64 120 8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . . 64 121 8.13. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 64 122 8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . . 65 123 8.15. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 66 124 8.16. Multiple-Services-Credit-Control AVP . . . . . . . . . . 67 125 8.17. Granted-Service-Unit AVP . . . . . . . . . . . . . . . . 68 126 8.18. Requested-Service-Unit AVP . . . . . . . . . . . . . . . 69 127 8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . . 69 128 8.20. Tariff-Time-Change AVP . . . . . . . . . . . . . . . . . 70 129 8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . . 70 130 8.22. CC-Money AVP . . . . . . . . . . . . . . . . . . . . . . 70 131 8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . . 70 132 8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . . 70 133 8.25. CC-Output-Octets AVP . . . . . . . . . . . . . . . . . . 71 134 8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . . 71 135 8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . . 71 136 8.28. Service-Identifier AVP . . . . . . . . . . . . . . . . . 72 137 8.29. Rating-Group AVP . . . . . . . . . . . . . . . . . . . . 72 138 8.30. G-S-U-Pool-Reference AVP . . . . . . . . . . . . . . . . 72 139 8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . . 73 140 8.32. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 73 141 8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . . 73 142 8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . . 74 143 8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . . 75 144 8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . . 76 145 8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . . 76 146 8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . . 76 147 8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . . 77 148 8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . . 77 149 8.41. Requested-Action AVP . . . . . . . . . . . . . . . . . . 78 150 8.42. Service-Context-Id AVP . . . . . . . . . . . . . . . . . 78 151 8.43. Service-Parameter-Info AVP . . . . . . . . . . . . . . . 79 152 8.44. Service-Parameter-Type AVP . . . . . . . . . . . . . . . 80 153 8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . . 80 154 8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . . 80 155 8.47. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 80 156 8.48. Subscription-Id-Data AVP . . . . . . . . . . . . . . . . 81 157 8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . . 81 158 8.50. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 82 159 8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . . 82 160 8.52. User-Equipment-Info-Extension AVP . . . . . . . . . . . . 82 161 8.53. User-Equipment-Info-IMEISV AVP . . . . . . . . . . . . . 83 162 8.54. User-Equipment-Info-MAC AVP . . . . . . . . . . . . . . . 83 163 8.55. User-Equipment-Info-EUI64 AVP . . . . . . . . . . . . . . 83 164 8.56. User-Equipment-Info-ModifiedEUI64 AVP . . . . . . . . . . 83 165 8.57. User-Equipment-Info-IMEI AVP . . . . . . . . . . . . . . 84 166 8.58. Subscription-Id-Extension AVP . . . . . . . . . . . . . . 84 167 8.59. Subscription-Id-E164 AVP . . . . . . . . . . . . . . . . 84 168 8.60. Subscription-Id-IMSI AVP . . . . . . . . . . . . . . . . 85 169 8.61. Subscription-Id-SIP-URI AVP . . . . . . . . . . . . . . . 85 170 8.62. Subscription-Id-NAI AVP . . . . . . . . . . . . . . . . . 85 171 8.63. Subscription-Id-Private AVP . . . . . . . . . . . . . . . 85 172 8.64. Redirect-Server-Extension AVP . . . . . . . . . . . . . . 85 173 8.65. Redirect-Address-IPAddress AVP . . . . . . . . . . . . . 86 174 8.66. Redirect-Address-URL AVP . . . . . . . . . . . . . . . . 86 175 8.67. Redirect-Address-SIP-URI AVP . . . . . . . . . . . . . . 86 176 8.68. QoS-Final-Unit-Indication AVP . . . . . . . . . . . . . . 86 177 9. Result Code AVP Values . . . . . . . . . . . . . . . . . . . 88 178 9.1. Transient Failures . . . . . . . . . . . . . . . . . . . 88 179 9.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 89 180 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 89 181 10.1. Credit-Control AVP Table . . . . . . . . . . . . . . . . 90 182 10.2. Re-Auth-Request/Answer AVP Table . . . . . . . . . . . . 91 183 11. RADIUS/Diameter Credit-Control Interworking Model . . . . . . 91 184 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 185 12.1. Application Identifier . . . . . . . . . . . . . . . . . 95 186 12.2. Command Codes . . . . . . . . . . . . . . . . . . . . . 95 187 12.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 95 188 12.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . 96 189 12.5. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . 96 190 12.6. CC-Session-Failover AVP . . . . . . . . . . . . . . . . 96 191 12.7. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 96 192 12.8. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 96 193 12.9. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 96 194 12.10. Credit-Control-Failure-Handling AVP . . . . . . . . . . 97 195 12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 97 196 12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 97 197 12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 97 198 12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 97 199 12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 97 200 12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 98 201 12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 98 202 12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 98 203 13. Credit-Control Application Related Parameters . . . . . . . . 98 204 14. Security Considerations . . . . . . . . . . . . . . . . . . . 99 205 14.1. Direct Connection with Redirects . . . . . . . . . . . . 100 206 14.2. Application Level Redirects . . . . . . . . . . . . . . 100 207 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 101 208 15.1. Privacy Sensitive AVPs . . . . . . . . . . . . . . . . . 101 209 15.2. Data Minimization . . . . . . . . . . . . . . . . . . . 103 210 15.3. Diameter Agents . . . . . . . . . . . . . . . . . . . . 104 211 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 212 16.1. Normative References . . . . . . . . . . . . . . . . . . 104 213 16.2. Informative References . . . . . . . . . . . . . . . . . 106 214 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 107 215 Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 107 216 B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 107 217 B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 110 218 B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 112 219 B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 113 220 B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 114 221 B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 116 222 B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 117 223 B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 118 224 B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 120 225 Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 125 226 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 126 228 1. Introduction 230 This document specifies a Diameter application that can be used to 231 implement real-time credit-control for a variety of end user services 232 such as network access, Session Initiation Protocol (SIP) services, 233 messaging services, and download services. It provides a general 234 solution to real-time cost and credit-control. 236 The prepaid model has been shown to be very successful, for instance, 237 in GSM networks, where network operators offering prepaid services 238 have experienced a substantial growth of their customer base and 239 revenues. Prepaid services are now cropping up in many other 240 wireless and wire line based networks. 242 In mobile networks, additional functionality is required beyond that 243 specified in the Diameter base protocol [RFC6733]. For example, the 244 3GPP Charging and Billing requirements [TGPPCHARG] state that an 245 application must be able to rate service information in real-time. 246 In addition, it is necessary to check that the end user's account 247 provides coverage for the requested service prior to initiation of 248 that service. When an account is exhausted or expired, the user must 249 be denied the ability to compile additional chargeable events. 251 A mechanism has to be provided to allow the user to be informed of 252 the charges to be levied for a requested service. In addition, there 253 are services such as gaming and advertising that may credit as well 254 as debit a user account. 256 The other Diameter applications provide service-specific 257 authorization, and they do not provide credit authorization for 258 prepaid users. The credit authorization shall be generic and 259 applicable to all the service environments required to support 260 prepaid services. 262 To fulfill these requirements, it is necessary to facilitate credit- 263 control communication between the network element providing the 264 service (e.g., Network Access Server, SIP Proxy, and Application 265 Server) and a credit-control server. 267 The scope of this specification is the credit authorization. 268 Service-specific authorization and authentication is out of scope. 270 1.1. Requirements Language 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 274 "OPTIONAL" in this document are to be interpreted as described in BCP 275 14 [RFC2119] [RFC8174] when, and only when, they appear in all 276 capitals, as shown here. 278 1.2. Terminology 280 AAA Authentication, Authorization, and Accounting 282 AA answer AA answer generically refers to a service-specific 283 authorization and authentication answer. AA answer commands are 284 defined in service-specific authorization applications, e.g., 285 [RFC7155] and [RFC4004]. 287 AA request AA request generically refers to a service-specific 288 authorization and authentication request. AA request commands are 289 defined in service-specific authorization applications e.g., 290 [RFC7155] and [RFC4004]. 292 Credit-control Credit-control is a mechanism that directly interacts 293 in real-time with an account and controls or monitors the charges 294 related to the service usage. Credit-control is a process of 295 checking whether credit is available, credit-reservation, 296 deduction of credit from the end user account when service is 297 completed and refunding of reserved credit that is not used. 299 Diameter Credit-control Server A Diameter credit-control server acts 300 as a prepaid server, performing real-time rating and credit- 301 control. It is located in the home domain and is accessed by 302 service elements or Diameter AAA servers in real-time for purpose 303 of price determination and credit-control before the service event 304 is delivered to the end-user. It may also interact with business 305 support systems. 307 Diameter Credit-control Client A Diameter credit-control client is 308 an entity that interacts with a credit-control server. It 309 monitors the usage of the granted quota according to instructions 310 returned by credit-control server. 312 Interrogation The Diameter credit-control client uses interrogation 313 to initiate a session based credit-control process. During the 314 credit-control process, it is used to report the used quota and 315 request a new one. An interrogation maps to a request/answer 316 transaction. 318 One-time event Basically, a request/answer transaction of type 319 event. 321 Rating The act of determining the cost of the service event. 323 Service A type of task performed by a service element for an end 324 user. 326 Service Element A network element that provides a service to the end 327 users. The Service Element may include the Diameter credit- 328 control client, or another entity (e.g., RADIUS AAA server) that 329 can act as a credit-control client on behalf of the Service 330 Element. In the latter case, the interface between the Service 331 Element and the Diameter credit-control client is outside the 332 scope of this specification. Examples of the Service Elements 333 include Network Access Server (NAS), SIP Proxy, and Application 334 Servers such as messaging server, content server, and gaming 335 server. 337 Service Event An event relating to a service provided to the end 338 user. 340 Session based credit-control A credit-control process that makes use 341 of several interrogations: the first, a possible intermediate, and 342 the final. The first interrogation is used to reserve money from 343 the user's account and to initiate the process. The intermediate 344 interrogations may be needed to request new quota while the 345 service is being rendered. The final interrogation is used to 346 exit the process. The credit-control server is required to 347 maintain session state for session-based credit-control. 349 1.3. Advertising Application Support 351 Diameter nodes conforming to this specification MUST advertise 352 support by including the value of 4 in the Auth-Application-Id of the 353 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 354 command [RFC6733]. 356 2. Architecture Models 358 The current accounting models specified in the Radius Accounting 359 [RFC2866] and Diameter base [RFC6733] are not sufficient for real- 360 time credit-control, where credit-worthiness is to be determined 361 prior to service initiation. Also, the existing Diameter 362 authorization applications, [RFC7155] and [RFC4004], only provide 363 service authorization, but do not provide credit authorization for 364 prepaid users. In order to support real-time credit-control, a new 365 type of server is needed in the AAA infrastructure: Diameter credit- 366 control server. The Diameter credit-control server is the entity 367 responsible for credit authorization for prepaid subscribers. 369 A service element may authenticate and authorize the end user with 370 the AAA server by using AAA protocols; e.g., RADIUS or a Diameter 371 base protocol with a possible Diameter application. 373 Accounting protocols such as RADIUS accounting and the Diameter base 374 accounting protocol can be used to provide accounting data to the 375 accounting server after service is initiated, and to provide possible 376 interim reports until service completion. However, for real-time 377 credit-control, these authorization and accounting models are not 378 sufficient. 380 When real-time credit-control is required, the credit-control client 381 contacts the credit-control server with information about a possible 382 service event. The credit-control process is performed to determine 383 potential charges and to verify whether the end user's account 384 balance is sufficient to cover the cost of the service being 385 rendered. 387 Figure 1 illustrates the typical credit-control architecture, which 388 consists of a Service Element with an embedded Diameter credit- 389 control client, a Diameter credit-control server, and an AAA server. 390 A Business Support System is usually deployed; it includes at least 391 the billing functionality. The credit-control server and AAA server 392 in this architecture model are logical entities. The real 393 configuration can combine them into a single host. The credit- 394 control protocol is the Diameter base protocol [RFC6733] with the 395 Diameter credit-control application. 397 When an end user requests services such as SIP or messaging, the 398 request is typically forwarded to a service element (e.g., SIP Proxy) 399 in the user's home realm as defined in [RFC6733]. In some cases it 400 might be possible that the service element in the local realm 401 [RFC6733] can offer services to the end user; however, a commercial 402 agreement must exist between the local realm and the home realm. 403 Network access is an example of a service offered in the local realm 404 where the NAS, through an AAA infrastructure, authenticates and 405 authorizes the user with the user's home network. 407 Service Element AAA and CC 408 +----------+ +---------+ Protocols+-----------+ +--------+ 409 | End |<---->|+-------+|<------------>| AAA | |Business| 410 | User | +->|| CC || | Server |->|Support | 411 | | | || Client||<-----+ | | |System | 412 +----------+ | |+-------+| | +-----------+ | | 413 | +---------+ | ^ +--------+ 414 +----------+ | | CC Protocol | ^ 415 | End |<--+ | +-----v----+ | 416 | User | +------>|Credit- | | 417 +----------+ Credit-Control |Control |--------+ 418 Protocol |Server | 419 +----------+ 421 Figure 1: Typical credit-control architecture 423 There can be multiple credit-control servers in the system for 424 redundancy and load balancing. The system can also contain separate 425 rating server(s), and accounts can be located in a centralized 426 database. To ensure that the end user's account is not debited or 427 credited multiple times for the same service event, only one place in 428 the credit-control system should perform duplicate detection. System 429 internal interfaces can exist to relay messages between servers and 430 an account manager. However, the detailed architecture of the 431 credit-control system and its interfaces are implementation specific 432 and are out of scope of this specification. 434 Protocol transparent Diameter relays can exist between the credit- 435 control client and credit-control server. Also, Diameter Redirect 436 agents that refer credit-control clients to credit-control servers 437 and allow them to communicate directly can exist. These agents 438 transparently support the Diameter credit-control application. The 439 different roles of Diameter Agents are defined in Diameter base 440 [RFC6733], section 2.8. 442 If Diameter credit-control proxies exist between the credit-control 443 client and the credit-control server, they MUST advertise the 444 Diameter credit-control application support. 446 3. Credit-Control Messages 448 This section defines new Diameter message Command-Code values that 449 MUST be supported by all Diameter implementations that conform to 450 this specification. The Command Codes are as follows: 452 +------------------------+---------+------+-----------+ 453 | Command-Name | Abbrev. | Code | Reference | 454 +------------------------+---------+------+-----------+ 455 | Credit-Control-Request | CCR | 272 | 3.1 | 456 | Credit-Control-Answer | CCA | 272 | 3.2 | 457 +------------------------+---------+------+-----------+ 459 Table 1: Credit-Control Commands 461 Diameter Base [RFC6733] defines in the section 3.2 the Command Code 462 format specification. These formats are observed in Credit-Control 463 messages. 465 3.1. Credit-Control-Request (CCR) Command 467 The Credit-Control-Request message (CCR) is indicated by the command- 468 code field being set to 272 and the 'R' bit being set in the Command 469 Flags field. It is used between the Diameter credit-control client 470 and the credit-control server to request credit authorization for a 471 given service. 473 The Auth-Application-Id MUST be set to the value 4, indicating the 474 Diameter credit-control application. 476 The CCR is extensible via the inclusion of one or more Attribute 477 Value Pairs (AVPs). 479 Message Format 481 ::= < Diameter Header: 272, REQ, PXY > 482 < Session-Id > 483 { Origin-Host } 484 { Origin-Realm } 485 { Destination-Realm } 486 { Auth-Application-Id } 487 { Service-Context-Id } 488 { CC-Request-Type } 489 { CC-Request-Number } 490 [ Destination-Host ] 491 [ User-Name ] 492 [ CC-Sub-Session-Id ] 493 [ Acct-Multi-Session-Id ] 494 [ Origin-State-Id ] 495 [ Event-Timestamp ] 496 *[ Subscription-Id ] 497 *[ Subscription-Id-Extension ] 498 [ Service-Identifier ] 499 [ Termination-Cause ] 500 [ Requested-Service-Unit ] 501 [ Requested-Action ] 502 *[ Used-Service-Unit ] 503 [ Multiple-Services-Indicator ] 504 *[ Multiple-Services-Credit-Control ] 505 *[ Service-Parameter-Info ] 506 [ CC-Correlation-Id ] 507 [ User-Equipment-Info ] 508 [ User-Equipment-Info-Extension ] 509 *[ Proxy-Info ] 510 *[ Route-Record ] 511 *[ AVP ] 513 3.2. Credit-Control-Answer (CCA) Command 515 The Credit-Control-Answer message (CCA) is indicated by the command- 516 code field being set to 272 and the 'R' bit being cleared in the 517 Command Flags field. It is used between the credit-control server 518 and the Diameter credit-control client to acknowledge a Credit- 519 Control-Request command. 521 Message Format 522 ::= < Diameter Header: 272, PXY > 523 < Session-Id > 524 { Result-Code } 525 { Origin-Host } 526 { Origin-Realm } 527 { Auth-Application-Id } 528 { CC-Request-Type } 529 { CC-Request-Number } 530 [ User-Name ] 531 [ CC-Session-Failover ] 532 [ CC-Sub-Session-Id ] 533 [ Acct-Multi-Session-Id ] 534 [ Origin-State-Id ] 535 [ Event-Timestamp ] 536 [ Granted-Service-Unit ] 537 *[ Multiple-Services-Credit-Control ] 538 [ Cost-Information] 539 [ Final-Unit-Indication ] 540 [ QoS-Final-Unit-Indication ] 541 [ Check-Balance-Result ] 542 [ Credit-Control-Failure-Handling ] 543 [ Direct-Debiting-Failure-Handling ] 544 [ Validity-Time ] 545 *[ Redirect-Host ] 546 [ Redirect-Host-Usage ] 547 [ Redirect-Max-Cache-Time ] 548 *[ Proxy-Info ] 549 *[ Route-Record ] 550 *[ Failed-AVP ] 551 *[ AVP ] 553 4. Credit-Control Application Overview 555 The credit authorization process takes place before and during 556 service delivery to the end user and generally requires the user's 557 authentication and authorization before any request is sent to the 558 credit-control server. The credit-control application defined in 559 this specification supports two different credit authorization 560 models: credit authorization with money reservation and credit 561 authorization with direct debiting. In both models, the credit- 562 control client requests credit authorization from the credit-control 563 server prior to allowing any service to be delivered to the end user. 565 In the first model, the credit-control server rates the request, 566 reserves a suitable amount of money from the user's account, and 567 returns the amount of credit reserved. Note that credit resources 568 may not imply actual monetary credit; credit resources may be granted 569 to the credit-control client in the form of units (e.g., data volume 570 or time) to be metered. 572 Upon receipt of a successful credit authorization answer with a 573 certain amount of credit resources, the credit-control client allows 574 service delivery to the end user and starts monitoring the usage of 575 the granted resources. When the credit resources granted to the user 576 have been consumed or the service has been successfully delivered or 577 terminated, the credit-control client reports back to the server the 578 used amount. The credit-control server deducts the used amount from 579 the end user's account; it may perform rating and make a new credit 580 reservation if the service delivery is continuing. This process is 581 accomplished with session based credit-control that includes the 582 first interrogation, possible intermediate interrogations, and the 583 final interrogation. For session based credit-control, both the 584 credit-control client and the credit-control server are required to 585 maintain credit-control session state. Session based credit-control 586 is described in more detail, with more variations, in Section 5. 588 In contrast, credit authorization with direct debiting is a single 589 transaction process wherein the credit-control server directly 590 deducts a suitable amount of money from the user's account as soon as 591 the credit authorization request is received. Upon receipt of a 592 successful credit authorization answer, the credit-control client 593 allows service delivery to the end user. This process is 594 accomplished with the one-time event. Session state is not 595 maintained. 597 In a multi-service environment, an end user can issue an additional 598 service request (e.g., data service) during an ongoing service (e.g., 599 voice call) toward the same account. Alternatively, during an active 600 multimedia session, an additional media type is added to the session, 601 causing a new simultaneous request toward same account. 602 Consequently, this needs to be considered when credit resources are 603 granted to the services. 605 The credit-control application also supports operations such as 606 service price enquiry, user's balance check, and refund of credit on 607 the user's account. These operations are accomplished with the one- 608 time event. Session state is not maintained. 610 Flexible failure handling, specific to the credit-control, is defined 611 in the application. This allows the the service provider to control 612 the credit-control client behavior according to its own risk 613 management policy. 615 The Credit-Control-Failure-Handling AVP and the Direct-Debiting- 616 Failure-Handling AVP are defined to determine what is done if the 617 sending of credit-control messages to the credit-control server has 618 been temporarily prevented. The usage of the Credit-Control-Failure- 619 Handling AVP and the Direct-Debiting-Failure-Handling AVP allows 620 flexibility, as failure handling for the credit-control session and 621 one-time event direct debiting may be different. 623 4.1. Service-Specific Rating Input and Interoperability 625 The Diameter credit-control application defines the framework for 626 credit-control; it provides generic credit-control mechanisms 627 supporting multiple service applications. The credit-control 628 application, therefore, does not define AVPs that could be used as 629 input in the rating process. Listing the possible services that 630 could use this Diameter application is out of scope for this generic 631 mechanism. 633 It is reasonable to expect that a service level agreement will exist 634 between providers of the credit-control client and the credit-control 635 server covering the charging, services offered, roaming agreements, 636 agreed rating input (i.e., AVPs), and so on. 638 Therefore, it is assumed that a Diameter credit-control server will 639 provide service only for Diameter credit-control clients that have 640 agreed beforehand as to the content of credit-control messages. 641 Naturally, it is possible that any arbitrary Diameter credit-control 642 client can interchange credit-control messages with any Diameter 643 credit-control server, but with a higher likelihood that unsupported 644 services/AVPs could be present in the credit-control message, causing 645 the server to reject the request with an appropriate result-code. 647 4.1.1. Specifying Rating Input AVPs 649 There are two ways to provide rating input to the credit-control 650 server: either by using AVPs or by including them in the Service- 651 Parameter-Info AVP. The general principles for sending rating 652 parameters are as follows: 654 1a. The service SHOULD re-use existing AVPs if it can use AVPs 655 defined in existing Diameter applications (e.g., [RFC7155] for 656 network access services). Re-use of existing AVPs is strongly 657 recommended in [RFC6733]. 659 For AVPs of type Enumerated, the service may require a new value to 660 be defined. Allocation of new AVP values is done as specified in 661 [RFC6733], section 1.3. 663 1b. New AVPs can be defined if the existing AVPs do not provide 664 sufficient rating information. In this case, the procedures defined 665 in [RFC6733] for creating new AVPs MUST be followed. 667 1c. For services specific only to one vendor's implementation, a 668 Vendor-Specific AVP code for Private use can be used. Where a 669 Vendor-Specific AVP is implemented by more than one vendor, 670 allocation of global AVPs is encouraged instead; refer to [RFC6733]. 672 2. The Service-Parameter-Info AVP MAY be used as a container to pass 673 legacy rating information in its original encoded form (e.g., ASN.1 674 BER). This method can be used to avoid unnecessary conversions from 675 an existing data format to an AVP format. In this case, the rating 676 input is embedded in the Service-Parameter-Info AVP as defined in 677 Section 8.43. 679 New service applications SHOULD favor the use of explicitly defined 680 AVPs as described in items 1a and 1b, to simplify interoperability. 682 4.1.2. Service-Specific Documentation 684 The service-specific rating input AVPs, the contents of the Service- 685 Parameter-Info AVP or Service-Context-Id AVP (defined in 686 Section 8.42) are not within the scope of this document. To 687 facilitate interoperability, it is RECOMMENDED that the rating input 688 and the values of the Service-Context-Id be coordinated via an 689 informational RFC or other permanent and readily available reference, 690 preferably, of another cooperative standardization body (e.g., 3GPP, 691 OMA, or 3GPP2). However, private services may be deployed that are 692 subject to agreements between providers of the credit-control server 693 and client. In this case, vendor-specific AVPs can be used. 695 This specification, together with the above service-specific 696 documents, governs the credit-control message. Service-specific 697 documents define which existing AVPs or new AVPs are used as input to 698 the rating process (i.e., those that do not define new credit-control 699 applications), and thus have to be included in the Credit-Control- 700 Request command by a Diameter credit-control client supporting a 701 given service as *[AVP]. Should Service-Parameter-Info be used, then 702 the service-specific document MUST specify the exact content of this 703 grouped AVP. 705 The Service-Context-Id AVP MUST be included at the command level of a 706 Credit-Control Request to identify the service-specific document that 707 applies to the request. The specific service or rating group the 708 request relates to is uniquely identified by the combination of 709 Service-Context-Id and Service-Identifier or Rating-Group. 711 4.1.3. Handling of Unsupported/Incorrect Rating Input 713 Diameter credit-control implementations are required to support the 714 Mandatory rating AVPs defined in service-specific documentation of 715 the services they support, according to the 'M' bit rules in 716 [RFC6733]. 718 If a rating input required for the rating process is incorrect in the 719 Credit-control request, or if the credit-control server does not 720 support the requested service context (identified by the Service- 721 Context-Id AVP at command level), the Credit-control answer MUST 722 contain the error code DIAMETER_RATING_FAILED. A CCA message with 723 this error MUST contain one or more Failed-AVP AVPs containing the 724 missing and/or unsupported AVPs that caused the failure. A Diameter 725 credit-control client that receives the error code 726 DIAMETER_RATING_FAILED in response to a request MUST NOT send similar 727 requests in the future. 729 4.1.4. RADIUS Vendor-Specific Rating Attributes 731 When service-specific documents include RADIUS vendor-specific 732 attributes that could be used as input in the rating process, the 733 rules described in [RFC7155] for formatting the Diameter AVP MUST be 734 followed. 736 For example, if the AVP code used is the vendor attribute type code, 737 the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be 738 set to the IANA Vendor identification value. The Diameter AVP data 739 field contains only the attribute value of the RADIUS attribute. 741 5. Session Based Credit-Control 743 5.1. General Principles 745 For a session-based credit-control, several interrogations are 746 needed: the first, intermediate (optional) and the final 747 interrogations. This is illustrated in Figure 3 and Figure 4. 749 If the credit-control client performs credit-reservation before 750 granting service to the end user, it MUST use several interrogations 751 toward the credit-control server (i.e., session based credit- 752 control). In this case, the credit-control server MUST maintain the 753 credit-control session state. 755 Each credit-control session MUST have a globally unique Session-Id as 756 defined in [RFC6733], which MUST NOT be changed during the lifetime 757 of a credit-control session. 759 Certain applications require multiple credit-control sub-sessions. 760 These applications would send messages with a constant Session-Id 761 AVP, but with a different CC-Sub-Session-Id AVP. If several credit 762 sub-sessions will be used, all sub-sessions MUST be closed separately 763 before the main session is closed so that units per sub-session may 764 be reported. The absence of this AVP implies that no sub-sessions 765 are in use. 767 Note that the service element might send a service-specific re- 768 authorization message to the AAA server due to expiration of the 769 authorization-lifetime during an ongoing credit-control session. 770 However, the service-specific re-authorization does not influence the 771 credit authorization that is ongoing between the credit-control 772 client and credit-control server, as credit authorization is 773 controlled by the burning rate of the granted quota. 775 If service-specific re-authorization fails, the user will be 776 disconnected, and the credit-control client MUST send a final 777 interrogation to the credit-control server. 779 The Diameter credit-control server may seek to control the validity 780 time of the granted quota and/or the production of intermediate 781 interrogations. Thus, it MAY include the Validity-Time AVP in the 782 answer message to the credit-control client. Upon expiration of the 783 Validity-Time, the credit-control client MUST generate a credit- 784 control update request and report the used quota to the credit- 785 control server. It is up to the credit-control server to determine 786 the value of the Validity-Time to be used for consumption of the 787 granted service unit(s) (G-S-U). If the Validity-Time is used, its 788 value SHOULD be given as input to set the session supervision timer 789 Tcc (the session supervision timer MAY be set to two times the value 790 of the Validity-Time, as defined in Section 13). Since credit- 791 control update requests are also produced at the expiry of granted 792 service units and/or for mid-session service events, the omission of 793 Validity-Time does not mean that intermediate interrogation for the 794 purpose of credit-control is not performed. 796 5.1.1. Basic Tariff-Time Change Support 798 The Diameter credit-control server and client MAY optionally support 799 a tariff change mechanism. The Diameter credit-control server may 800 include a Tariff-Time-Change AVP in the answer message. Note that 801 the granted units should be allocated based on the worst-case 802 scenario in case of forthcoming tariff change, so that the overall 803 reported used units would never exceed the credit reservation. 805 When the Diameter credit-control client reports the used units and a 806 tariff change has occurred during the reporting period, the Diameter 807 credit-control client MUST separately itemize the units used before 808 and after the tariff change. If the client is unable to distinguish 809 whether units straddling the tariff change were used before or after 810 the tariff change, the credit-control client MUST itemize those units 811 in a third category. 813 If a client does not support the tariff change mechanism and it 814 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 815 terminate the credit-control session, giving a reason of 816 DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 818 For time based services, the quota is continuously consumed at the 819 regular rate of 60 seconds per minute (ignoring leap seconds). At 820 the time when credit resources are allocated, the server already 821 knows how many units will be consumed before the tariff time change 822 and how many units will be consumed afterward. Similarly, the server 823 can determine the units consumed at the before rate and the units 824 consumed at the rate afterward in the event that the end-user closes 825 the session before the consumption of the allotted quota. There is 826 no need for additional traffic between client and server in the case 827 of tariff time changes for continuous time based service. Therefore, 828 the tariff change mechanism is not used for such services. For time- 829 based services in which the quota is NOT continuously consumed at a 830 regular rate, the tariff change mechanism described for volume and 831 event units MAY be used. 833 5.1.2. Credit-Control for Multiple Services within a (sub-)Session 835 When multiple services are used within the same user session and each 836 service or group of services is subject to different cost, it is 837 necessary to perform credit-control for each service independently. 838 Making use of credit-control sub-sessions to achieve independent 839 credit-control will result in increased signaling load and usage of 840 resources in both the credit-control client and the credit-control 841 server. For instance, during one network access session the end user 842 may use several http-services subject to different access cost. The 843 network-access-specific attributes such as the quality of service 844 (QoS) are common to all the services carried within the access 845 bearer, but the cost of the bearer may vary depending on its content. 847 To support these scenarios optimally, the credit-control application 848 enables independent credit-control of multiple services in a single 849 credit-control (sub-)session. This is achieved by including the 850 optional Multiple-Services-Credit-Control AVP in Credit-Control- 851 Request/Answer messages. It is possible to request and allocate 852 resources as a credit pool shared between multiple services. The 853 services can be grouped into rating groups in order to achieve even 854 further aggregation of credit allocation. It is also possible to 855 request and allocate quotas on a per service basis. Where quotas are 856 allocated to a pool by means of the Multiple-Services-Credit-Control 857 AVP, the quotas remain independent objects that can be re-authorized 858 independently at any time. Quotas can also be given independent 859 result codes, validity times, and Final-Unit-Indications or QoS- 860 Final-Unit-Indications. 862 A Rating-Group gathers a set of services, identified by a Service- 863 Identifier, and subject to the same cost and rating type (e.g., $0.1/ 864 minute). It is assumed that the service element is provided with 865 Rating-Groups, Service-Identifiers, and their associated parameters 866 that define what has to be metered by means outside the scope of this 867 specification. (Examples of parameters associated to Service- 868 Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers enable 869 authorization on a per-service based credit as well as itemized 870 reporting of service usage. It is up to the credit-control server 871 whether to authorize credit for one or more services or for the whole 872 rating-group. However, the client SHOULD always report used units at 873 the finest supported level of granularity. Where quota is allocated 874 to a rating-group, all the services belonging to that group draw from 875 the allotted quota. The following is a graphical representation of 876 the relationship between service-identifiers, rating-groups, credit 877 pools, and credit-control (sub-)session. 879 DCC (Sub-)Session 880 | 881 +------------+-----------+-------------+--------------- + 882 | | | | | 883 Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z 884 \ / \ / / 885 \ / \ / / 886 \ / Rating-Group 1.......Rating-Group n 887 \ / | | 888 Quota ---------------Quota Quota 889 | / | 890 | / | 891 Credit-Pool Credit-Pool 893 Figure 2: Multiple-Service (sub)-Session Example 895 If independent credit-control of multiple services is used, the 896 Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- 897 Indication AVP SHOULD be present either in the Multiple-Services- 898 Credit-Control AVP(s) or at command level as single AVPs. However, 899 the Result-Code AVP MAY be present both on the command level and 900 within the Multiple-Services-Credit-Control AVP. If the Result-Code 901 AVP on the command level indicates a value other than SUCCESS, then 902 the Result-Code AVP on command level takes precedence over any 903 included in the Multiple-Services-Credit-Control AVP. 905 The credit-control client MUST indicate support for independent 906 credit-control of multiple services within a (sub-)session by 907 including the Multiple-Services-Indicator AVP in the first 908 interrogation. A credit-control server not supporting this feature 909 MUST treat the Multiple-Services-Indicator AVP and any received 910 Multiple-Services-Credit-Control AVPs as invalid AVPs. 912 If the client indicated support for independent credit-control of 913 multiple services, a credit-control server that wishes to use the 914 feature MUST return the granted units within the Multiple-Services- 915 Credit-Control AVP associated to the corresponding service-identifier 916 and/or rating-group. 918 To avoid a situation where several parallel (and typically also 919 small) credit reservations must be made on the same account (i.e., 920 credit fragmentation), and also to avoid unnecessary load on the 921 credit-control server, it is possible to provide service units as a 922 pool that applies to multiple services or rating groups. This is 923 achieved by providing the service units in the form of a quota for a 924 particular service or rating group in the Multiple-Services-Credit- 925 Control AVP, and also by including a reference to a credit pool for 926 that unit type. 928 The reference includes a multiplier derived from the rating 929 parameter, which translates from service units of a specific type to 930 the abstract service units in the pool. For instance, if the rating 931 parameter for service 1 is $1/MB and the rating parameter for service 932 2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2, 933 respectively. 935 If S is the total service units within the pool, M1, M2, ..., Mn are 936 the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., 937 Cn are the used resources within the session, then the pool credit is 938 exhausted and re-authorization MUST be sought when: 940 C1*M1 + C2*M2 + ... + Cn*Mn >= S 942 The total credit in the pool, S, is calculated from the quotas, which 943 are currently allocated to the pool as follows: 945 S = Q1*M1 + Q2*M2 + ... + Qn*Mn 947 If services or rating groups are added to or removed from the pool, 948 then the total credit is adjusted appropriately. Note that when the 949 total credit is adjusted because services or rating groups are 950 removed from the pool, the value that need to be removed is the 951 consumed one (i.e., Cx*Mx). 953 Re-authorizations for an individual service or rating group may be 954 sought at any time; for example, if a 'non-pooled' quota is used up 955 or the Validity-Time expires. 957 Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same 958 G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit- 959 Control AVP (Section 8.16) along with the Granted-Service-Unit AVP, 960 then these MUST have different CC-Unit-Type values, and they all draw 961 from the credit pool separately. For instance, if one multiplier for 962 time (M1t) and one multiplier for volume (M1v) are given, then the 963 used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t 964 is the time unit and C1v is the volume unit. 966 Where service units are provided within a Multiple-Services-Credit- 967 Control AVP without a corresponding G-S-U-Pool-Reference AVP, then 968 these are handled independently from any credit pool and from any 969 other services or rating groups within the session. 971 The credit pool concept is an optimal tool to avoid the over- 972 reservation effect of the basic single quota tariff time change 973 mechanism (the mechanism described in Section 5.1.1). Therefore, 974 Diameter credit-control clients and servers implementing the 975 independent credit-control of multiple services SHOULD leverage the 976 credit pool concept when supporting the tariff time change. The 977 Diameter credit-control server SHOULD include both the Tariff-Time- 978 Change and Tariff-Change-Usage AVPs in two quota allocations in the 979 answer message (i.e., two instances of the Multiple-Services-Credit- 980 Control AVP). One of the granted units is allocated to be used 981 before the potential tariff change, while the second granted units 982 are for use after a tariff change. Both granted unit quotas MUST 983 contain the same Service-Identifier and/or Rating-Group. This dual 984 quota mechanism ensures that the overall reported used units would 985 never exceed the credit reservation. The Diameter credit-control 986 client reports both the used units before and after the tariff change 987 in a single instance of the Multiple-Services-Credit-Control AVP. 989 The failure handling for credit-control sessions is defined in 990 Section 5.7 and reflected in the basic credit-control state machine 991 in Section 7. Credit-control clients and servers implementing the 992 independent credit-control of multiple services in a (sub-)session 993 functionality MUST ensure failure handling and general behavior fully 994 consistent with the above mentioned sections, while maintaining the 995 ability to handle parallel ongoing credit re-authorization within a 996 (sub-)session. Therefore, it is RECOMMENDED that Diameter credit- 997 control clients maintain a PendingU message queue and restart the Tx 998 timer (Section 13) every time a CCR message with the value 999 UPDATE_REQUEST is sent while they are in PendingU state. When 1000 answers to all pending messages are received, the state machine moves 1001 to OPEN state, and Tx timer is stopped. Naturally, the action 1002 performed when a problem for the session is detected according to 1003 Section 5.7 affects all the ongoing services (e.g., failover to a 1004 backup server if possible affect all the CCR messages with the value 1005 UPDATE_REQUEST in the PendingU queue). 1007 Since the client may send CCR messages with the value UPDATE_REQUEST 1008 while in PendingU (i.e., without waiting for an answer to ongoing 1009 credit re-authorization), the time space between these requests may 1010 be very short, and the server may not have received the previous 1011 request(s) yet. Therefore, in this situation the server may receive 1012 out of sequence requests and SHOULD NOT consider this an error 1013 condition. A proper answer is to be returned to each of those 1014 requests. 1016 5.2. First Interrogation 1018 When session based credit-control is required (e.g., the 1019 authentication server indicated a prepaid user), the first 1020 interrogation MUST be sent before the Diameter credit-control client 1021 allows any service event to the end user. The CC-Request-Type is set 1022 to the value INITIAL_REQUEST in the request message. 1024 If the Diameter credit-control client knows the cost of the service 1025 event (e.g., a content server delivering ringing tones may know their 1026 cost) the monetary amount to be charged is included in the Requested- 1027 Service-Unit AVP. If the Diameter credit-control client does not 1028 know the cost of the service event, the Requested-Service-Unit AVP 1029 MAY contain the number of requested service events. Where the 1030 Multiple-Services-Credit-Control AVP is used, it MUST contain the 1031 Requested-Service-Unit AVP to indicate that the quota for the 1032 associated service/rating-group is requested. In the case of 1033 multiple services, the Service-Identifier AVP or the Rating-Group AVP 1034 within the Multiple-Services-Credit-Control AVP always indicates the 1035 service concerned. Additional service event information to be rated 1036 MAY be sent as service-specific AVPs or MAY be sent within the 1037 Service-Parameter-Info AVP at command level. The Service-Context-Id 1038 AVP indicates the service-specific document applicable to the 1039 request. 1041 The Event-Timestamp AVP SHOULD be included in the request and 1042 contains the time when the service event is requested in the service 1043 element. The Subscription-Id AVP or the Subscription-Id-Extension 1044 AVP SHOULD be included to identify the end user in the credit-control 1045 server. The credit-control client MAY include the User-Equipment- 1046 Info AVP or User-Equipment-Info-Extension AVP so that the credit- 1047 control server has some indication of the type and capabilities of 1048 the end user access device. How the credit-control server uses this 1049 information is outside the scope of this document. 1051 The credit-control server SHOULD rate the service event and make a 1052 credit-reservation from the end user's account that covers the cost 1053 of the service event. If the type of the Requested-Service-Unit AVP 1054 is money, no rating is needed, but the corresponding monetary amount 1055 is reserved from the end user's account. 1057 The credit-control server returns the Granted-Service-Unit AVP in the 1058 Answer message to the Diameter credit-control client. The Granted- 1059 Service-Unit AVP contains the amount of service units that the 1060 Diameter credit-control client can provide to the end user until a 1061 new Credit-Control-Request MUST be sent to the credit-control server. 1062 If several unit types are sent in the Answer message, the credit- 1063 control client MUST handle each unit type separately. The type of 1064 the Granted-Service-Unit AVP can be time, volume, service-specific, 1065 or money, depending on the type of service event. The unit type(s) 1066 SHOULD NOT be changed within an ongoing credit-control session. 1068 There MUST be a maximum of one instance of the same unit type in one 1069 Answer message. However, if multiple quotas are conveyed to the 1070 credit-control client in the Multiple-Services-Credit-Control AVPs, 1071 it is possible to carry two instances of the same unit type 1072 associated to a service-identifier/rating-group. This is typically 1073 the case when a tariff time change is expected and the credit-control 1074 server wants to make a distinction between the granted quota before 1075 and after tariff change. 1077 If the credit-control server determines that no further control is 1078 needed for the service, it MAY include the result code indicating 1079 that the credit-control is not applicable (e.g., if the service is 1080 free of charge). This result code at command level implies that the 1081 credit-control session is to be terminated. 1083 The Credit-Control-Answer message MAY also include the Final-Unit- 1084 Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that 1085 the answer message contains the final units for the service. After 1086 the end user has consumed these units, the Diameter credit-control- 1087 client MUST behave as described in Section 5.6. 1089 This document defines two different approaches to perform the first 1090 interrogation to be used in different network architectures. The 1091 first approach uses credit-control messages after the user's 1092 authorization and authentication takes place. The second approach 1093 uses service-specific authorization messages to perform the first 1094 interrogation during the user's authorization/authentication phase, 1095 and credit-control messages for the intermediate and final 1096 interrogations. If an implementation of the credit-control client 1097 supports both the methods, determining which method to use SHOULD be 1098 configurable. 1100 In service environments such as the Network Access Server (NAS), it 1101 is desired to perform the first interrogation as part of the 1102 authorization/authentication process for the sake of protocol 1103 efficiency. Further credit authorizations after the first 1104 interrogation are performed with credit-control commands defined in 1105 this specification. Implementations of credit-control clients 1106 operating in the mentioned environments SHOULD support this method. 1107 If the credit-control server and AAA server are separate physical 1108 entities, the service element sends the request messages to the AAA 1109 server, which then issues an appropriate request or proxies the 1110 received request forward to the credit-control server. 1112 In other service environments, such as the 3GPP network and some SIP 1113 scenarios, there is a substantial decoupling between registration/ 1114 access to the network and the actual service request (i.e., the 1115 authentication/authorization is executed once at registration/access 1116 to the network and is not executed for every service event requested 1117 by the subscriber). In these environments, it is more appropriate to 1118 perform the first interrogation after the user has been authenticated 1119 and authorized. The first, the intermediate, and the final 1120 interrogations are executed with credit-control commands defined in 1121 this specification. 1123 Other IETF standards or standards developed by other standardization 1124 bodies may define the most suitable method in their architectures. 1126 5.2.1. First Interrogation after Authorization and Authentication 1128 The Diameter credit-control client in the service element may get 1129 information from the authorization server as to whether credit- 1130 control is required, based on its knowledge of the end user. If 1131 credit-control is required the credit-control server needs to be 1132 contacted prior to initiating service delivery to the end user. The 1133 accounting protocol and the credit-control protocol can be used in 1134 parallel. The authorization server may also determine whether the 1135 parallel accounting stream is required. 1137 The following diagram illustrates the case where both protocols are 1138 used in parallel and the service element sends credit-control 1139 messages directly to the credit-control server. More credit-control 1140 sequence examples are given in Annex A. 1142 Diameter 1143 End User Service Element AAA Server CC Server 1144 (CC Client) 1145 | Registration | AA request/answer(accounting,cc or both)| 1146 |<----------------->|<------------------>| | 1147 | : | | | 1148 | : | | | 1149 | Service Request | | | 1150 |------------------>| | | 1151 | | CCR(Initial,Credit-Control AVPs) | 1152 | +|---------------------------------------->| 1153 | CC stream|| | CCA(Granted-Units)| 1154 | +|<----------------------------------------| 1155 | Service Delivery | | | 1156 |<----------------->| ACR(start,Accounting AVPs) | 1157 | : |------------------->|+ | 1158 | : | ACA || Accounting stream | 1159 | |<-------------------|+ | 1160 | : | | | 1161 | : | | | 1162 | | CCR(Update,Used-Units) | 1163 | |---------------------------------------->| 1164 | | | CCA(Granted-Units)| 1165 | |<----------------------------------------| 1166 | : | | | 1167 | : | | | 1168 | End of Service | | | 1169 |------------------>| CCR(Termination, Used-Units) | 1170 | |---------------------------------------->| 1171 | | | CCA | 1172 | |<----------------------------------------| 1173 | | ACR(stop) | | 1174 | |------------------->| | 1175 | | ACA | | 1176 | |<-------------------| | 1178 Figure 3: Protocol example with first interrogation after user's 1179 authorization/authentication 1181 5.2.2. First Interrogation Included with Authorization Messages 1183 The Diameter credit-control client in the service element MUST 1184 actively co-operate with the authorization/authentication client in 1185 the construction of the AA request by adding appropriate credit- 1186 control AVPs. The credit-control client MUST add the Credit-Control 1187 AVP to indicate credit-control capabilities and MAY add other 1188 relevant credit-control-specific AVPs to the proper authorization/ 1189 authentication command to perform the first interrogation toward the 1190 home Diameter AAA server. The Auth-Application-Id is set to the 1191 appropriate value, as defined in the relevant service-specific 1192 authorization/authentication application document (e.g., [RFC7155], 1193 [RFC4004]). The home Diameter AAA server authenticates/authorizes 1194 the subscriber and determines whether credit-control is required. 1196 If credit-control is not required for the subscriber, the home 1197 Diameter AAA server will respond as usual, with an appropriate AA 1198 answer message. If credit-control is required for the subscriber and 1199 the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was 1200 present in the authorization request, the home AAA server MUST 1201 contact the credit-control server to perform the first interrogation. 1202 If credit-control is required for the subscriber and the Credit- 1203 Control AVP was not present in the authorization request, the home 1204 AAA server MUST send an authorization reject answer message. 1206 The Diameter AAA server supporting credit-control is required to send 1207 the Credit-Control-Request command (CCR) defined in this document to 1208 the credit-control server. The Diameter AAA server populates the CCR 1209 based on service-specific AVPs used for input to the rating process, 1210 and possibly on credit-control AVPs received in the AA request. The 1211 credit-control server will reserve money from the user's account, 1212 will rate the request and will send a Credit-Control-Answer message 1213 to the home Diameter AAA server. The answer message includes the 1214 Granted-Service-Unit AVP(s) and MAY include other credit-control- 1215 specific AVPs, as appropriate. Additionally, the credit-control 1216 server MAY set the Validity-Time and MAY include the Credit-Control- 1217 Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to 1218 determine what to do if the sending of credit-control messages to the 1219 credit-control server has been temporarily prevented. 1221 Upon receiving the Credit-Control-Answer message from the credit- 1222 control server, the home Diameter AAA server will populate the AA 1223 answer with the received credit-control AVPs and with the appropriate 1224 service attributes according to the authorization/authentication- 1225 specific application (e.g., [RFC7155], [RFC4004]). It will then 1226 forward the packet to the credit-control client. If the home 1227 Diameter AAA server receives a credit-control reject message, it will 1228 simply generate an appropriate authorization reject message to the 1229 credit-control client, including the credit-control-specific error 1230 code. 1232 In this model, the credit-control client sends further credit-control 1233 messages to the credit-control server via the home Diameter AAA 1234 server. Upon receiving a successful authorization answer message 1235 with the Granted-Service-Unit AVP(s), the credit-control client will 1236 grant the service to the end user and will generate an intermediate 1237 credit-control request, as required by using credit-control commands. 1239 The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 1240 (for how to produce unique value for the CC-Request-Number AVP, see 1241 Section 8.2). 1243 If service-specific re-authorization is performed (i.e., 1244 authorization-lifetime expires), the credit-control client MUST add 1245 to the service-specific re-authorization request the Credit-Control 1246 AVP with a value set to RE_AUTHORIZATION to indicate that the credit- 1247 control server MUST NOT be contacted. When session based credit- 1248 control is used for the subscriber, a constant credit-control message 1249 stream flows through the home Diameter AAA server. The home Diameter 1250 AAA server can make use of this credit-control message flow to deduce 1251 that the user's activity is ongoing; therefore, it is recommended to 1252 set the authorization-lifetime to a reasonably high value when 1253 credit-control is used for the subscriber. 1255 In this scenario, the home Diameter AAA server MUST advertise support 1256 for the credit-control application to its peers during the capability 1257 exchange process. 1259 The following diagram illustrates the use of authorization/ 1260 authentication messages to perform the first interrogation. The 1261 parallel accounting stream is not shown in the figure. 1263 Service Element Diameter 1264 End User (CC Client) AAA Server CC Server 1265 | Service Request | AA Request (CC AVPs) | 1266 |------------------>|------------------->| | 1267 | | | CCR(Initial, CC AVPs) 1268 | | |------------------->| 1269 | | | CCA(Granted-Units) 1270 | | |<-------------------| 1271 | | AA Answer(Granted-Units) | 1272 | Service Delivery |<-------------------| | 1273 |<----------------->| | | 1274 | : | | | 1275 | : | | | 1276 | : | | | 1277 | | | | 1278 | | CCR(Update,Used-Units) | 1279 | |------------------->| CCR(Update,Used-Units) 1280 | | |------------------->| 1281 | | | CCA(Granted-Units)| 1282 | | CCA(Granted-Units)|<-------------------| 1283 | |<-------------------| | 1284 | : | | | 1285 | : | | | 1286 | End of Service | | | 1287 |------------------>| CCR(Termination,Used-Units) | 1288 | |------------------->| CCR(Term.,Used-Units) 1289 | | |------------------->| 1290 | | | CCA | 1291 | | CCA |<-------------------| 1292 | |<-------------------| | 1294 Figure 4: Protocol example with use of the authorization messages for 1295 the first interrogation 1297 5.3. Intermediate Interrogation 1299 When all the granted service units for one unit type are spent by the 1300 end user or the Validity-Time is expired, the Diameter credit-control 1301 client MUST send a new Credit-Control-Request to the credit-control 1302 server. In the event that credit-control for multiple services is 1303 applied in one credit-control session (i.e., units associated to 1304 Service-Identifier(s) or Rating-Group are granted), a new Credit- 1305 Control-Request MUST be sent to the credit-control server when the 1306 credit reservation has been wholly consumed, or upon expiration of 1307 the Validity-Time. It is always up to the Diameter credit-control 1308 client to send a new request well in advance of the expiration of the 1309 previous request in order to avoid interruption in the service 1310 element. Even if the granted service units reserved by the credit- 1311 control server have not been spent upon expiration of the Validity- 1312 Time, the Diameter credit-control client MUST send a new Credit- 1313 Control-Request to the credit-control server. 1315 There can also be mid-session service events, which might affect the 1316 rating of the current service events. In this case, a spontaneous 1317 updating (a new Credit-Control-Request) SHOULD be sent including 1318 information related to the service event even if all the granted 1319 service units have not been spent or the Validity-Time has not 1320 expired. 1322 When the used units are reported to the credit-control server, the 1323 credit-control client will not have any units in its possession 1324 before new granted units are received from the credit-control server. 1325 When the new granted units are received, these units apply from the 1326 point where the measurement of the reported used units stopped. 1327 Where independent credit-control of multiple services is supported, 1328 this process may be executed for one or more services, a single 1329 rating-group, or a pool within the (sub)session. 1331 The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the 1332 intermediate request message. The Subscription-Id AVP or 1333 Subscription-Id-Extension AVP SHOULD be included in the intermediate 1334 message to identify the end user in the credit-control server. The 1335 Service-Context-Id AVP indicates the service-specific document 1336 applicable to the request. 1338 The Requested-Service-Unit AVP MAY contain the new amount of 1339 requested service units. Where the Multiple-Services-Credit-Control 1340 AVP is used, it MUST contain the Requested-Service-Unit AVP if a new 1341 quota is requested for the associated service/rating-group. The 1342 Used-Service-Unit AVP contains the amount of used service units 1343 measured from the point when the service became active or, if interim 1344 interrogations are used during the session, from the point when the 1345 previous measurement ended. The same unit types used in the previous 1346 message SHOULD be used. If several unit types were included in the 1347 previous answer message, the used service units for each unit type 1348 MUST be reported. 1350 The Event-Timestamp AVP SHOULD be included in the request and 1351 contains the time of the event that triggered the sending of the new 1352 Credit-Control-Request. 1354 The credit-control server MUST deduct the used amount from the end 1355 user's account. It MAY rate the new request and make a new credit- 1356 reservation from the end user's account that covers the cost of the 1357 requested service event. 1359 A Credit-Control-Answer message with the CC-Request-Type AVP set to 1360 the value UPDATE_REQUEST MAY include the Cost-Information AVP 1361 containing the accumulated cost estimation for the session, without 1362 taking any credit-reservation into account. 1364 The Credit-Control-Answer message MAY also include the Final-Unit- 1365 Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that 1366 the answer message contains the final units for the service. After 1367 the end user has consumed these units, the Diameter credit-control- 1368 client MUST behave as described in Section 5.6. 1370 There can be several intermediate interrogations within a session. 1372 5.4. Final Interrogation 1374 When the end user terminates the service session, or when the 1375 graceful service termination described in Section 5.6 takes place, 1376 the Diameter credit-control client MUST send a final Credit-Control- 1377 Request message to the credit-control server. The CC-Request-Type 1378 AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id 1379 AVP indicates the service-specific document applicable to the 1380 request. 1382 The Event-Timestamp AVP SHOULD be included in the request and 1383 contains the time when the session was terminated. 1385 The Used-Service-Unit AVP contains the amount of used service units 1386 measured from the point when the service became active or, if interim 1387 interrogations are used during the session, from the point when the 1388 previous measurement ended. If several unit types were included in 1389 the previous answer message, the used service units for each unit 1390 type MUST be reported. 1392 After final interrogation, the credit-control server MUST refund the 1393 reserved credit amount not used to the end user's account and deduct 1394 the used monetary amount from the end user's account. 1396 A Credit-Control-Answer message with the CC-Request-Type set to the 1397 value TERMINATION_REQUEST MAY include the Cost-Information AVP 1398 containing the estimated total cost for the session in question. 1400 If the user logs off during an ongoing credit-control session, or if 1401 some other reason causes the user to become logged off (e.g., final- 1402 unit indication causes user logoff according to local policy), the 1403 service element, according to application-specific policy, may send a 1404 Session-Termination-Request (STR) to the home Diameter AAA server as 1405 usual [RFC6733]. Figure 5 illustrates the case when the final-unit 1406 indication causes user logoff upon consumption of the final granted 1407 units and the generation of STR. 1409 Service Element AAA Server CC Server 1410 End User (CC Client) 1411 | Service Delivery | | | 1412 |<----------------->| | | 1413 | : | | | 1414 | : | | | 1415 | : | | | 1416 | | | | 1417 | | CCR(Update,Used-Units) | 1418 | |------------------->| CCR(Update,Used-Units) 1419 | | |------------------->| 1420 | | CCA(Final-Unit, Terminate) 1421 | CCA(Final-Unit, Terminate)|<-------------------| 1422 | |<-------------------| | 1423 | : | | | 1424 | : | | | 1425 | Disconnect user | | | 1426 |<------------------| CCR(Termination,Used-Units) | 1427 | |------------------->| CCR(Term.,Used-Units) 1428 | | |------------------->| 1429 | | | CCA | 1430 | | CCA |<-------------------| 1431 | |<-------------------| | 1432 | | STR | | 1433 | |------------------->| | 1434 | | STA | | 1435 | |<-------------------| | 1437 Figure 5: User disconnected due to exhausted account 1439 5.5. Server-Initiated Credit Re-Authorization 1441 The Diameter credit-control application supports server-initiated re- 1442 authorization. The credit-control server MAY optionally initiate the 1443 credit re-authorization by issuing a Re-Auth-Request (RAR) as defined 1444 in the Diameter base protocol [RFC6733]. The Auth-Application-Id in 1445 the RAR message is set to 4 to indicate Diameter Credit Control, and 1446 the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. 1448 Section 5.1.2 defines the feature to enable credit-control for 1449 multiple services within a single (sub-)session where the server can 1450 authorize credit usage at a different level of granularity. Further, 1451 the server may provide credit resources to multiple services or 1452 rating groups as a pool (see Section 5.1.2 for details and 1453 definitions). Therefore, the server, based on its service logic and 1454 its knowledge of the ongoing session, can decide to request credit 1455 re-authorization for a whole (sub-)session, a single credit pool, a 1456 single service, or a single rating-group. To request credit re- 1457 authorization for a credit pool, the server includes in the RAR 1458 message the G-S-U-Pool-Identifier AVP indicating the affected pool. 1459 To request credit re-authorization for a service or a rating-group, 1460 the server includes in the RAR message the Service-Identifier AVP or 1461 the Rating-Group AVP, respectively. To request credit re- 1462 authorization for all the ongoing services within the (sub-)session, 1463 the server includes none of the above mentioned AVPs in the RAR 1464 message. 1466 If a credit re-authorization is not already ongoing (i.e., the 1467 credit-control session is in Open state), a credit-control client 1468 that receives an RAR message with Session-Id equal to a currently 1469 active credit-control session MUST acknowledge the request by sending 1470 the Re-Auth-Answer (RAA) message and MUST initiate the credit re- 1471 authorization toward the server by sending a Credit-Control-Request 1472 message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. 1473 The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the 1474 RAA message to indicate that an additional message (i.e., CCR message 1475 with the value UPDATE_REQUEST) is required to complete the procedure. 1476 If a quota was allocated to the service, the credit-control client 1477 MUST report the used quota in the Credit-Control-Request. Note that 1478 the end user does not need to be prompted for the credit re- 1479 authorization, since the credit re-authorization is transparent to 1480 the user (i.e., it takes place exclusively between the credit-control 1481 client and the credit-control server). 1483 Where multiple services in a user's session are supported, the 1484 procedure in the above paragraph will be executed at the granularity 1485 requested by the server in the RAR message. 1487 If credit re-authorization is ongoing at the time when the RAR 1488 message is received (i.e., RAR-CCR collision), the credit-control 1489 client successfully acknowledges the request but does not initiate a 1490 new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) 1491 SHOULD be used in the RAA message to indicate that a credit re- 1492 authorization procedure is already ongoing (i.e., the client was in 1493 PendingU state when the RAR was received). The credit-control server 1494 SHOULD process the Credit-Control-Request as if it was received in 1495 answer to the server initiated credit re-authorization, and should 1496 consider the server initiated credit re-authorization process 1497 successful upon reception of the Re-Auth-Answer message. 1499 When multiple services are supported in a user's session, the server 1500 may request credit re-authorization for a credit pool (or for the 1501 (sub-)session) while a credit re-authorization is already ongoing for 1502 some of the services or rating-groups. In this case, the client 1503 acknowledges the server request with an RAA message and MUST send a 1504 new Credit-Control-Request message to perform re-authorization for 1505 the remaining services/rating-groups. The Result-Code 2002 1506 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to 1507 indicate that an additional message (i.e., CCR message with value 1508 UPDATE_REQUEST) is required to complete the procedure. The server 1509 processes the received requests and returns an appropriate answer to 1510 both requests. 1512 The above-defined procedures are enabled for each of the possibly 1513 active Diameter credit-control sub-sessions. The server MAY request 1514 re-authorization for an active sub-session by including the CC-Sub- 1515 Session-Id AVP in the RAR message in addition to the Session-Id AVP. 1517 5.6. Graceful Service Termination 1519 When the user's account runs out of money, the user may not be 1520 allowed to compile additional chargeable events. However, the home 1521 service provider may offer some services; for instance, access to a 1522 service portal where it is possible to refill the account, for which 1523 the user is allowed to benefit for a limited time. The length of 1524 this time is usually dependent on the home service provider policy. 1526 This section defines the optional graceful service termination 1527 feature that MAY be supported by the credit-control server. Credit- 1528 control client implementations MUST support the Final-Unit-Indication 1529 AVP or QoS-Final-Unit-Indication AVP with at least the teardown of 1530 the ongoing service session once the subscriber has consumed all the 1531 final granted units. 1533 Where independent credit-control of multiple services in a single 1534 credit-control (sub-)session is supported, it is possible to use the 1535 graceful service termination for each of the services/rating-groups 1536 independently. Naturally, the graceful service termination process 1537 defined in the following sub-sections will apply to the specific 1538 service/rating-group as requested by the server. 1540 In some service environments (e.g., NAS), the graceful service 1541 termination may be used to redirect the subscriber to a service 1542 portal for online balance refill or other services offered by the 1543 home service provider. In this case, the graceful termination 1544 process installs a set of packet filters to restrict the user's 1545 access capability only to/from the specified destinations. All the 1546 IP packets not matching the filters will be dropped or, possibly, re- 1547 directed to the service portal. The user may also be sent an 1548 appropriate notification as to why the access has been limited. 1549 These actions may be communicated explicitly from the server to the 1550 client or may be configured per-service at the client. Explicitly 1551 signaled redirect or restrict instructions always take precedence 1552 over configured ones. 1554 It is also possible use the graceful service termination to connect 1555 the prepaid user to a top-up server that plays an announcement and 1556 prompts the user to replenish the account. In this case, the credit- 1557 control server sends only the address of the top-up server where the 1558 prepaid user shall be connected after the final granted units have 1559 been consumed. An example of this is given Appendix B.7. 1561 The credit-control server MAY initiate the graceful service 1562 termination by including the Final-Unit-Indication AVP or the QoS- 1563 Final-Unit-Indication AVP in the Credit-Control-Answer to indicate 1564 that the message contains the final units for the service. 1566 When the credit-control client receives the Final-Unit-Indication AVP 1567 or the QoS-Final-Unit-Indication AVP in the answer from the server, 1568 its behavior depends on the value indicated in the Final-Unit-Action 1569 AVP. The server may request the following actions: TERMINATE, 1570 REDIRECT, or RESTRICT_ACCESS. 1572 The following figure illustrates the graceful service termination 1573 procedure described in the following sub-sections. 1575 Diameter 1576 End User Service Element AAA Server CC Server 1577 (CC Client) 1578 | Service Delivery | | | 1579 |<----------------->| | | 1580 | |CCR(Update,Used-Units) | 1581 | |------------------->|CCR(Update,Used-Units) 1582 | : | |------------------->| 1583 | : | |CCA(Final-Unit,Action) 1584 | : | |<-------------------| 1585 | |CCA(Final-Unit,Action) | 1586 | |<-------------------| | 1587 | | | | 1588 | : | | | 1589 | : | | | 1590 | : | | | 1591 | /////////////// |CCR(Update,Used-Units) | 1592 |/Final Units End/->|------------------->|CCR(Update,Used-Units) 1593 |/Action and // | |------------------->| 1594 |/Restrictions // | | CCA(Validity-Time)| 1595 |/Start // | CCA(Validity-Time)|<-------------------| 1596 | ///////////// |<-------------------| | 1597 | : | | | 1598 | : | | | 1599 | Replenish Account +-------+ | 1600 |<-------------------------------------------->|Account| | 1601 | | | +-------+ | 1602 | | | RAR | 1603 | + | RAR |<===================| 1604 | | |<===================| | 1605 | | | RAA | | 1606 | ///////////// | |===================>| RAA | 1607 | /If supported / | | CCR(Update) |===================>| 1608 | /by CC Server/ | |===================>| CCR(Update) | 1609 | ///////////// | | |===================>| 1610 | | | | CCA(Granted-Unit)| 1611 | | | CCA(Granted-Unit)|<===================| 1612 | Restrictions ->+ |<===================| | 1613 | removed | | | 1614 | : | | | 1615 | OR | CCR(Update) | | 1616 | Validity-Time ->|------------------->| CCR(Update) | 1617 | expires | |------------------->| 1618 | | | CCA(Granted-Unit)| 1619 | | CCA(Granted-Unit)|<-------------------| 1620 | Restrictions ->|<-------------------| | 1621 | removed | | | 1622 Figure 6: Optional graceful service termination procedure 1624 In addition, the credit-control server MAY reply with Final-Unit- 1625 Indication AVP or QoS-Final-Unit-Indication AVP holding a G-S-U AVP 1626 with a zero grant, indicating that the service SHOULD be terminated 1627 immediately, and no further reporting is required. A following 1628 figure illustrates a graceful service termination procedure that 1629 applies immediately after receiving a zero grant. 1631 Diameter 1632 End User Service Element AAA Server CC Server 1633 (CC Client) 1634 | Service Delivery | | | 1635 |<----------------->| | | 1636 | |CCR(Update,Used-Units) | 1637 | |------------------->|CCR(Update,Used-Units) 1638 | : | |------------------->| 1639 | : | |CCA(Final-Unit,Action, 1640 | : | | Zero G-S-U) 1641 | : | |<-------------------| 1642 | |CCA(Final-Unit,Action, | 1643 | | Zero G-S-U) | 1644 | |<-------------------| | 1645 | /////////////// | | | 1646 |/Action and // | | | 1647 |/Restrictions // | | | 1648 |/Start // | | | 1649 | ///////////// | | | 1650 | : | | | 1651 | : | | | 1653 Figure 7: Optional immediate graceful service termination procedure 1655 5.6.1. Terminate Action 1657 The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP 1658 with Final-Unit-Action TERMINATE does not include any other 1659 information. When the subscriber has consumed the final granted 1660 units, the service element MUST terminate the service. This is the 1661 default handling applicable whenever the credit-control client 1662 receives an unsupported Final-Unit-Action value and MUST be supported 1663 by all the Diameter credit-control client implementations conforming 1664 to this specification. A final Credit-Control-Request message to the 1665 credit-control server MUST be sent if the Final-Unit-Indication AVP 1666 or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was 1667 present at command level. The CC-Request-Type AVP in the request is 1668 set to the value TERMINATION_REQUEST. 1670 5.6.2. Redirect Action 1672 The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP 1673 with Final-Unit-Action REDIRECT indicates to the service element 1674 supporting this action that, upon consumption of the final granted 1675 units, the user MUST be re-directed to the address specified in the 1676 Redirect-Server AVP or Redirect-Server-Extension AVP as follows. 1678 The credit-control server sends the Redirect-Server AVP or Redirect- 1679 Server-Extension AVP in the Credit-Control-Answer message. In such a 1680 case, the service element MUST redirect or connect the user to the 1681 destination specified in the Redirect-Server AVP or Redirect-Server- 1682 Extension AVP, if possible. When the end user is redirected (by 1683 using protocols others than Diameter) to the specified server or 1684 connected to the top-up server, an additional authorization (and 1685 possibly authentication) may be needed before the subscriber can 1686 replenish the account; however, this is out of the scope of this 1687 specification. 1689 In addition to the Redirect-Server AVP or Redirect-Server-Extension 1690 AVP, the credit-control server MAY include one or more Restriction- 1691 Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more 1692 Filter-Id AVPs in the Credit-Control-Answer message to enable the 1693 user to access other services (for example, zero-rated services). In 1694 such a case, the access device MUST treat all packets according to 1695 the Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules 1696 referred to by the Filter-Id AVP. After treatment is applied 1697 according to these rules, all traffic that has not been dropped or 1698 already forwarded MUST be redirected to the destination specified in 1699 the Redirect-Server AVP or Redirect-Server-Extension AVP. 1701 An entity other than the credit-control server may provision the 1702 access device with appropriate IP packet filters to be used in 1703 conjunction with the Diameter credit-control application. This case 1704 is considered in Section 5.6.3. 1706 When the final granted units have been consumed, the credit-control 1707 client MUST perform an intermediate interrogation. The purpose of 1708 this interrogation is to indicate to the credit-control server that 1709 the specified action started and to report the used units. The 1710 credit-control server MUST deduct the used amount from the end user's 1711 account but MUST NOT make a new credit reservation. The credit- 1712 control client, however, may send intermediate interrogations before 1713 all the final granted units have been consumed for which rating and 1714 money reservation may be needed; for instance, upon Validity-Time 1715 expires or upon mid-session service events that affect the rating of 1716 the current service. Therefore, the credit-control client MUST NOT 1717 include any rating related AVP in the request sent once all the final 1718 granted units have been consumed as an indication to the server that 1719 the requested final unit action started, rating and money reservation 1720 are not required (when the Multiple-Services-Credit-Control AVP is 1721 used, the Service-Identifier or Rating-Group AVPs is included to 1722 indicate the concerned services). Naturally, the Credit-Control- 1723 Answer message does not contain any granted service unit and MUST 1724 include the Validity-Time AVP to indicate to the credit-control 1725 client how long the subscriber is allowed to use network resources 1726 before a new intermediate interrogation is sent to the server. 1728 At the expiry of Validity-Time, the credit-control client sends a 1729 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does 1730 not include the Used-Service-Unit AVP, as there is no allotted quota 1731 to report. The credit-control server processes the request and MUST 1732 perform the credit reservation. If during this time the subscriber 1733 did not replenish his/her account, whether he/she will be 1734 disconnected or will be granted access to services not controlled by 1735 a credit-control server for an unlimited time is dependent on the 1736 home service provider policy (note: the latter option implies that 1737 the service element should not remove the restriction filters upon 1738 termination of the credit-control). The server will return the 1739 appropriate Result-Code (see Section 9.1) in the Credit-Control- 1740 Answer message in order to implement the policy-defined action. 1741 Otherwise, new quota will be returned, the service element MUST 1742 remove all the possible restrictions activated by the graceful 1743 service termination process and continue the credit-control session 1744 and service session as usual. 1746 The credit-control client may not wait until the expiration of the 1747 Validity-Time and may send a spontaneous update (a new Credit- 1748 Control-Request) if the service element can determine, for instance, 1749 that communication between the end user and the top-up server took 1750 place. An example of this is given in Appendix B.8 (Figure 18). 1752 Note that the credit-control server may already have initiated the 1753 above-described process for the first interrogation. However, the 1754 user's account might be empty when this first interrogation is 1755 performed. In this case, the subscriber can be offered a chance to 1756 replenish the account and continue the service. When the credit- 1757 control client receives (either at session or service-specific level) 1758 a Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP, 1759 together with Validity-Time AVPs, but without Granted-Service-Unit 1760 AVP, it immediately starts the graceful service termination without 1761 sending any message to the server. An example of this case is 1762 illustrated in Appendix B. 1764 5.6.3. Restrict Access Action 1766 A Final-Unit-Indication AVP with the Final-Unit-Action 1767 RESTRICT_ACCESS indicates to the device supporting this action that, 1768 upon consumption of the final granted units, the user's access MUST 1769 be restricted according to the IP packet filters given in the 1770 Restriction-Filter-Rule AVP(s) or according to the IP packet filters 1771 identified by the Filter-Id AVP(s). The credit-control server SHOULD 1772 include either the Restriction-Filter-Rule AVP or the Filter-Id AVP 1773 in the Final-Unit-Indication group AVP of the Credit-Control-Answer 1774 message. 1776 A QoS-Final-Unit-Indication AVP with the Final-Unit-Action 1777 RESTRICT_ACCESS indicates to the device supporting this action that, 1778 upon consumption of the final granted units, the actions specified in 1779 Filter-Rule AVP(s) MUST restrict the traffic according to the 1780 classifiers in the Filter-Rule AVP(s). If Filter-Id AVP(s) are 1781 provided in the Credit-Control-Answer message, the credit-control 1782 client MUST restrict the traffic according to the IP packet filters 1783 identified by the Filter-Id AVP(s). The credit-control server SHOULD 1784 include either the Filter-Rule AVP or the Filter-Id AVP in the QoS- 1785 Final-Unit-Indication group AVP of the Credit-Control-Answer message. 1787 If both Final-Unit-Indication AVP and QoS-Final-Unit-Indication AVP 1788 exist in the Credit-Control-Answer message, a credit-control client 1789 which supports the QoS-Final-Unit-Indication AVP SHOULD follow the 1790 directives included in the QoS-Final-Unit-Indication AVP and SHOULD 1791 ignore the Final-Unit-Indication AVP. 1793 An entity other than the credit-control server may provision the 1794 access device with appropriate IP packet filters to be used in 1795 conjunction with the Diameter credit-control application. Such an 1796 entity may, for instance, configure the access device with IP flows 1797 to be passed when the Diameter credit-control application indicates 1798 RESTRICT_ACCESS or REDIRECT. The access device passes IP packets 1799 according to the filter rules that may have been received in the 1800 Credit-Control-Answer message in addition to those that may have been 1801 configured by the other entity. However, when the user's account 1802 cannot cover the cost of the requested service, the action taken is 1803 the responsibility of the credit-control server that controls the 1804 prepaid subscriber. 1806 If another entity working in conjunction with the Diameter credit- 1807 control application already provisions the access device with all the 1808 required filter rules for the end user, the credit-control server 1809 presumably need not send any additional filter. Therefore, it is 1810 RECOMMENDED that credit-control server implementations supporting the 1811 graceful service termination be configurable for sending the 1812 Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, 1813 or none of the above. 1815 When the final granted units have been consumed, the credit-control 1816 client MUST perform an intermediate interrogation. The credit- 1817 control client and the credit-control server process this 1818 intermediate interrogation and execute subsequent procedures, as 1819 specified in the previous section for the REDIRECT action. 1821 The credit-control server may initiate the graceful service 1822 termination with action RESTRICT_ACCESS already for the first 1823 interrogation, as specified in the previous section for the REDIRECT 1824 action. 1826 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 1828 Once the subscriber replenishes the account, she presumably expects 1829 all the restrictions placed by the graceful termination procedure to 1830 be removed immediately and unlimited service access to be resumed. 1831 For the best user experience, the credit-control server 1832 implementation MAY support the server-initiated credit re- 1833 authorization (see Section 5.5). In such a case, upon the successful 1834 account top-up, the credit-control server sends the Re-Auth-Request 1835 (RAR) message to solicit the credit re-authorization. The credit- 1836 control client initiates the credit re-authorization by sending the 1837 Credit-Control-Request message with the CC-Request-Type AVP set to 1838 the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included 1839 in the request, as there is no allotted quota to report. The 1840 Requested-Service-Unit AVP MAY be included in the request. After the 1841 credit-control client successfully receives the Credit-Control-Answer 1842 with new Granted-Service-Unit, all the possible restrictions 1843 activated for the purpose of the graceful service termination MUST be 1844 removed in the service element. The credit-control session and the 1845 service session continue as usual. 1847 5.7. Failure Procedures 1849 The Credit-Control-Failure-Handling AVP (CCFH), as described in this 1850 section, determines the behavior of the credit-control client in 1851 fault situations. The CCFH may be received from the Diameter home 1852 AAA server, from the credit-control server, or may be configured 1853 locally. The CCFH value received from the home AAA server overrides 1854 the locally configured value. The CCFH value received from the 1855 credit-control server in the Credit-Control-Answer message always 1856 overrides any existing value. 1858 The authorization server MAY include the Accounting-Realtime-Required 1859 AVP to determine what to do if the sending of accounting records to 1860 the accounting server has been temporarily prevented, as defined in 1861 [RFC6733]. It is RECOMMENDED that the client complement the credit- 1862 control failure procedures with a backup accounting flow toward an 1863 accounting server. By using different combinations of Accounting- 1864 Realtime-Required and Credit-Control-Failure-Handling AVPs, different 1865 safety levels can be built. For example, by choosing a Credit- 1866 Control-Failure-Handling AVP equal to CONTINUE for the credit-control 1867 flow and an Accounting-Realtime-Required AVP equal to 1868 DELIVER_AND_GRANT for the accounting flow, the service can be granted 1869 to the end user even if the connection to the credit-control server 1870 is down, as long as the accounting server is able to collect the 1871 accounting information and information exchange is taking place 1872 between the accounting server and credit-control server. 1874 As the credit-control application is based on real-time bi- 1875 directional communication between the credit-control client and the 1876 credit-control server, the usage of alternative destinations and the 1877 buffering of messages may not be sufficient in the event of 1878 communication failures. Because the credit-control server has to 1879 maintain session states, moving the credit-control message stream to 1880 a backup server requires a complex context transfer solution. 1881 Whether the credit-control message stream is moved to a backup 1882 credit-control server during an ongoing credit-control session 1883 depends on the value of the CC-Session-Failover AVP. However, 1884 failover may occur at any point in the path between the credit- 1885 control client and the credit-control server if a transport failure 1886 is detected with a peer, as described in [RFC6733]. As a 1887 consequence, the credit-control server might receive duplicate 1888 messages. These duplicates or out of sequence messages can be 1889 detected in the credit-control server based on the credit-control 1890 server session state machine (Section 7), Session-Id AVP, and CC- 1891 Request-Number AVP. 1893 If a failure occurs during an ongoing credit-control session, the 1894 credit-control client may move the credit-control message stream to 1895 an alternative server if the CC-server indicated FAILOVER_SUPPORTED 1896 in the CC-Session-Failover AVP. A secondary credit-control server 1897 name, either received from the home Diameter AAA server or configured 1898 locally, can be used as an address of the backup server. If the CC- 1899 Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- 1900 control message stream MUST NOT be moved to a backup server. 1902 For new credit-control sessions, failover to an alternative credit- 1903 control server SHOULD be performed if possible. For instance, if an 1904 implementation of the credit-control client can determine primary 1905 credit-control server unavailability, it can establish the new 1906 credit-control sessions with a possibly available secondary credit- 1907 control server. 1909 The AAA transport profile [RFC3539] defines an application layer 1910 watchdog algorithm that enables failover from a peer that has failed 1911 and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The 1912 recommended default initial value for Tw (Twinit) is 30 seconds. 1913 Twinit may be set as low as 6 seconds; however, according to 1914 [RFC3539], setting too low a value for Twinit is likely to result in 1915 an increased probability of duplicates, as well as an increase in 1916 spurious failover and failback attempts. The Diameter base protocol 1917 [RFC6733] is common to several different types of Diameter AAA 1918 applications that may be run in the same service element. Therefore, 1919 tuning the timer Twinit to a lower value in order to satisfy the 1920 requirements of real-time applications, such as the Diameter credit- 1921 control application, will certainly cause the above mentioned 1922 problems. For prepaid services, however, the end user expects an 1923 answer from the network in a reasonable time. Thus, the Diameter 1924 credit-control client will react faster than would the underlying 1925 base protocol. Therefore this specification defines the Tx timer 1926 that is used by the credit-control client (as defined in Section 13) 1927 to supervise the communication with the credit-control server. When 1928 the Tx timer elapses, the credit-control client takes an action to 1929 the end user according to the Credit-Control-Failure-Handling AVP. 1931 When Tx timer expires, the Diameter credit-control client always 1932 terminates the service if the Credit-Control-Failure-Handling (CCFH) 1933 AVP is set to the value TERMINATE. The credit-control session may be 1934 moved to an alternative server only if a protocol error 1935 DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before Tx 1936 timer expires. Therefore, the value TERMINATE is not appropriate if 1937 proper failover behavior is desired. 1939 If the Credit-Control-Failure-Handling AVP is set to the value 1940 CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the 1941 end user when the Tx timer expires. An answer message with granted 1942 units may arrive later if the base protocol transport failover 1943 occurred in the path to the credit-control server. (The Twinit 1944 default value is 3 times more than the Tx timeout recommended value.) 1945 The credit-control client SHOULD grant the service to the end user, 1946 start monitoring the resource usage, and wait for the possible late 1947 answer until the timeout of the request (e.g., 120 seconds). If the 1948 request fails and the CC-Session-Failover AVP is set to 1949 FAILOVER_NOT_SUPPORTED, the credit-control client terminates or 1950 continues the service depending on the value set in the CCFH and MUST 1951 free all the reserved resources for the credit-control session. If 1952 the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is 1953 received or the request times out and the CC-Session-Failover AVP is 1954 set to FAILOVER_SUPPORTED, the credit-control client MAY send the 1955 request to a backup server, if possible. If the credit-control 1956 client receives a successful answer from the backup server, it 1957 continues the credit-control session with such a server. If the re- 1958 transmitted request also fails, the credit-control client terminates 1959 or continues the service depending on the value set in the CCFH and 1960 MUST free all the reserved resources for the credit-control session. 1962 If a communication failure occurs during the graceful service 1963 termination procedure, the service element SHOULD always terminate 1964 the ongoing service session. 1966 If the credit-control server detects a failure during an ongoing 1967 credit-control session, it will terminate the credit-control session 1968 and return the reserved units back to the end user's account. 1970 The supervision session timer Tcc (as defined in Section 13) is used 1971 in the credit-control server to supervise the credit-control session. 1973 In order to support failover between credit-control servers, 1974 information transfer about the credit-control session and account 1975 state SHOULD take place between the primary and the secondary credit- 1976 control server. Implementations supporting the credit-control 1977 session failover MUST also ensure proper detection of duplicate or 1978 out of sequence messages. The communication between the servers is 1979 regarded as an implementation issue and is outside of the scope of 1980 this specification. 1982 6. One Time Event 1984 The one-time event is used when there is no need to maintain any 1985 state in the Diameter credit-control server; for example, enquiring 1986 about the price of the service. The use of a one-time event implies 1987 that the user has been authenticated and authorized beforehand. 1989 The one-time event can be used when the credit-control client wants 1990 to know the cost of the service event or to check the account balance 1991 without any credit-reservation. It can also be used for refunding 1992 service units on the user's account or for direct debiting without 1993 any credit-reservation. The one-time event is shown in Figure 8. 1995 Diameter 1996 End User Service Element AAA Server CC Server 1997 (CC Client) 1998 | Service Request | | | 1999 |------------------>| | | 2000 | | CCR(Event) | | 2001 | |------------------->| CCR(Event) | 2002 | | |------------------->| 2003 | | | CCA(Granted-Units)| 2004 | | CCA(Granted-Units)|<-------------------| 2005 | Service Delivery |<-------------------| | 2006 |<----------------->| | | 2008 Figure 8: One time event 2010 In environments such as the 3GPP architecture, the one-time event can 2011 be sent from the service element directly to the credit-control 2012 server. 2014 6.1. Service Price Enquiry 2016 The credit-control client may need to know the price of the services 2017 event. Services offered by application service providers whose 2018 prices are not known in the credit-control client might exist. The 2019 end user might also want to get an estimation of the price of a 2020 service event before requesting it. 2022 A Diameter credit-control client requesting the cost information MUST 2023 set the CC-Request-Type AVP equal to EVENT_REQUEST, include the 2024 Requested-Action AVP set to PRICE_ENQUIRY, and set the requested 2025 service event information into the Service-Identifier AVP in the 2026 Credit-Control-Request message. Additional service event information 2027 may be sent as service-specific AVPs or within the Service-Parameter- 2028 Info AVP. The Service-Context-Id AVP indicates the service-specific 2029 document applicable to the request. 2031 The credit-control server calculates the cost of the requested 2032 service event, but it does not perform any account balance check or 2033 credit-reservation from the account. 2035 The estimated cost of the requested service event is returned to the 2036 credit-control client in the Cost-Information AVP in the Credit- 2037 Control-Answer message. 2039 6.2. Balance Check 2041 The Diameter credit-control client may only have to verify that the 2042 end user's account balance covers the cost of a certain service 2043 without reserving any units from the account at the time of the 2044 inquiry. This method does not guarantee that credit would be left 2045 when the Diameter credit-control client requests the debiting of the 2046 account with a separate request. 2048 A Diameter credit-control client requesting the balance check MUST 2049 set the CC-Request-Type AVP equal to EVENT_REQUEST, include a 2050 Requested-Action AVP set to CHECK_BALANCE, and include the 2051 Subscription-Id AVP or Subscription-Id-Extension AVP in order to 2052 identify the end user in the credit-control server. The Service- 2053 Context-Id AVP indicates the service-specific document applicable to 2054 the request. 2056 The credit-control server makes the balance check, but it does not 2057 make any credit-reservation from the account. 2059 The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to 2060 the credit-control client in the Check-Balance-Result AVP in the 2061 Credit-Control-Answer message. 2063 6.3. Direct Debiting 2065 There are certain service events for which service execution is 2066 always successful in the service environment. The delay between the 2067 service invocation and the actual service delivery to the end user 2068 can be sufficiently long that the use of the session-based credit- 2069 control would lead to unreasonably long credit-control sessions. In 2070 these cases, the Diameter credit-control client can use the one-time 2071 event scenario for direct debiting. The Diameter credit-control 2072 client SHOULD be sure that the requested service event execution 2073 would be successful when this scenario is used. 2075 In the Credit-Control-Request message, the CC-Request-Type is set to 2076 the value EVENT_REQUEST and the Requested-Action AVP is set to 2077 DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id- 2078 Extension AVP SHOULD be included to identify the end user in the 2079 credit-control server. The Event-Timestamp AVP SHOULD be included in 2080 the request and contain the time when the service event is requested 2081 in the service element. The Service-Context-Id AVP indicates the 2082 service-specific document applicable to the request. 2084 The Diameter credit-control client MAY include the monetary amount to 2085 be charged in the Requested-Service-Unit AVP, if it knows the cost of 2086 the service event. If the Diameter credit-control client does not 2087 know the cost of the service event, the Requested-Service-Unit AVP 2088 MAY contain the number of requested service events. The Service- 2089 Identifier AVP always indicates the service concerned. Additional 2090 service event information to be rated MAY be sent as service-specific 2091 AVPs or within the Service-Parameter-Info AVP. 2093 The credit-control server SHOULD rate the service event and deduct 2094 the corresponding monetary amount from the end user's account. If 2095 the type of the Requested-Service-Unit AVP is money, no rating is 2096 needed, but the corresponding monetary amount is deducted from the 2097 end user's account. 2099 The credit-control server returns the Granted-Service-Unit AVP in the 2100 Credit-Control-Answer message to the Diameter credit-control client. 2101 The Granted-Service-Unit AVP contains the amount of service units 2102 that the Diameter credit-control client can provide to the end user. 2103 The type of the Granted-Service-Unit can be time, volume, service- 2104 specific, or money, depending on the type of service event. 2106 If the credit-control server determines that no credit-control is 2107 needed for the service, it can include the result code indicating 2108 that the credit-control is not applicable (e.g., service is free of 2109 charge). 2111 For informative purposes, the Credit-Control-Answer message MAY also 2112 include the Cost-Information AVP containing the estimated total cost 2113 of the requested service. 2115 6.4. Refund 2117 Some services may refund service units to the end user's account; for 2118 example, gaming services. 2120 The credit-control client MUST set CC-Request-Type to the value 2121 EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the 2122 Credit-Control-Request message. The Subscription-Id AVP or 2123 Subscription-Id-Extension AVP SHOULD be included to identify the end 2124 user in the credit-control server. The Service-Context-Id AVP 2125 indicates the service-specific document applicable to the request. 2127 The Diameter credit-control client MAY include the monetary amount to 2128 be refunded in the Requested-Service-Unit AVP. The Service- 2129 Identifier AVP always indicates the concerned service. If the 2130 Diameter credit-control client does not know the monetary amount to 2131 be refunded, in addition to the Service-Identifier AVP it MAY send 2132 service-specific AVPs or the Service-Parameter-Info AVP containing 2133 additional service event information to be rated. 2135 For informative purposes, the Credit-Control-Answer message MAY also 2136 include the Cost-Information AVP containing the estimated monetary 2137 amount of refunded unit. 2139 6.5. Failure Procedure 2141 Failover to an alternative credit-control server is allowed for a one 2142 time event, as the server is not maintaining session states. For 2143 instance, if the credit-control client receives a protocol error 2144 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the 2145 request to an alternative server, if possible. There MAY be protocol 2146 transparent Diameter relays and redirect agents or Diameter credit- 2147 control proxies between the credit-control client and credit-control 2148 server. Failover may occur at any point in the path between the 2149 credit-control client and the credit-control server if a transport 2150 failure is detected with a peer, as described in [RFC6733]. Because 2151 there can be duplicate requests for various reasons, the credit- 2152 control server is responsible for real time duplicate detection. 2153 Implementation issues for duplicate detection are discussed in 2154 [RFC6733], Appendix C. 2156 When the credit-control client detects a communication failure with 2157 the credit-control server, its behavior depends on the requested 2158 action. The Tx timer (as defined in Section 13) is used in the 2159 credit-control client to supervise the communication with the credit- 2160 control server. 2162 If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and 2163 communication failure is detected, the credit-control client SHOULD 2164 forward the request messages to an alternative credit-control server, 2165 if possible. The secondary credit-control server name, if received 2166 from the home Diameter AAA server, can be used as an address of 2167 backup server. 2169 If the requested action is DIRECT_DEBITING, the Direct-Debiting- 2170 Failure-Handling AVP (DDFH) controls the credit-control client's 2171 behavior. The DDFH may be received from the home Diameter AAA server 2172 or may be locally configured. The credit-control server may also 2173 send the DDFH in any CCA message to be used for direct debiting 2174 events compiled thereafter. The DDFH value received from the home 2175 Diameter AAA server overrides the locally configured value, and the 2176 DDFH value received from the credit-control server in a Credit- 2177 Control-Answer message always overrides any existing value. 2179 If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client 2180 SHOULD NOT grant the service if it can determine, eventually after a 2181 possible re-transmission attempt to an alternative credit-control 2182 server, from the result code or error code in the answer message that 2183 units have not been debited. Otherwise, the credit-control client 2184 SHOULD grant the service to the end user and store the request in the 2185 credit-control application level non-volatile storage. (Note that 2186 re-sending the request at a later time is not a guarantee that the 2187 service will be debited, as the user's account may be empty when the 2188 server successfully processes the request.) The credit-control 2189 client MUST mark these request messages as possible duplicates by 2190 setting the T-flag in the command header as described in [RFC6733], 2191 Section 3. 2193 If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 2194 service SHOULD be granted, even if credit-control messages cannot be 2195 delivered and messages are not buffered. 2197 If the Tx timer expires, the credit-control client MUST continue the 2198 service and wait for a possible late answer. If the request times 2199 out, the credit-control client re-transmits the request (marked with 2200 T-flag) to a backup credit-control server, if possible. If the re- 2201 transmitted request also times out, or if a temporary error is 2202 received in answer, the credit-control client buffers the request if 2203 the value of the Direct-Debiting-Failure-Handling AVP is set to 2204 TERMINATE_OR_BUFFER. If a failed answer is received for the re- 2205 transmitted request, the credit-control client frees all the 2206 resources reserved for the event message and deletes the request 2207 regardless of the value of the DDFH. 2209 The Credit-Control-Request with the requested action REFUND_ACCOUNT 2210 should always be stored in the credit-control application level non- 2211 volatile storage in case of temporary failure. The credit-control 2212 client MUST mark the re-transmitted request message as a possible 2213 duplicate by setting the T-flag in the command header as described in 2214 [RFC6733], Section 3. 2216 For stored requests, the implementation may choose to limit the 2217 number of re-transmission attempts and to define a re-transmission 2218 interval. 2220 Note that only one place in the credit-control system SHOULD be 2221 responsible for duplicate detection. If there is only one credit- 2222 control server within the given realm, the credit-control server may 2223 perform duplicate detection. If there is more than one credit- 2224 control server in a given realm, only one entity in the credit- 2225 control system should be responsible, to ensure that the end user's 2226 account is not debited or credited multiple times for the same 2227 service event. 2229 7. Credit-Control Application State Machine 2231 This section defines the credit-control application state machine. 2233 The first four state machines are to be observed by credit-control 2234 clients. The first one describes the session-based credit-control 2235 when the first interrogation is executed as part of the 2236 authorization/authentication process. The second describes the 2237 session-based credit-control when the first interrogation is executed 2238 after the authorization/authentication process. The requirements as 2239 to what state machines have to be supported are discussed in 2240 Section 5.2. 2242 The third state machine describes the session-based credit-control 2243 for the intermediate and final interrogations. The fourth one 2244 describes the event-based credit-control. These latter state 2245 machines are to be observed by all implementations that conform to 2246 this specification. 2248 The fifth state machine describes the credit-control session from a 2249 credit-control server perspective. 2251 Any event not listed in the state machines MUST be considered an 2252 error condition, and a corresponding answer, if applicable, MUST be 2253 returned to the originator of the message. 2255 In the state table, the event 'Failure to send' means that the 2256 Diameter credit-control client is unable to communicate with the 2257 desired destination or, if failover procedure is supported, with a 2258 possibly defined alternative destination (e.g., the request times out 2259 and the answer message is not received). This could be due to the 2260 peer being down, or due to a physical link failure in the path to or 2261 from the credit-control server. 2263 The event 'Temporary error' means that the Diameter credit-control 2264 client received a protocol error notification (DIAMETER_TOO_BUSY, 2265 DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result- 2266 Code AVP of the Credit-Control-Answer command. The above protocol 2267 error notification may ultimately be received in answer to the re- 2268 transmitted request to a defined alternative destination, if failover 2269 is supported. 2271 The event 'Failed answer' means that the Diameter credit-control 2272 client received non-transient failure (permanent failure) 2273 notification in the Credit-Control-Answer command. The above 2274 permanent failure notification may ultimately be received in answer 2275 to the re-transmitted request to a defined alternative destination, 2276 if failover is supported. 2278 The action 'store request' means that a request is stored in the 2279 credit-control application level non-volatile storage. 2281 The event 'Not successfully processed' means that the credit-control 2282 server could not process the message; e.g., due to an unknown end 2283 user, account being empty, or errors defined in [RFC6733]. 2285 The event 'User service terminated' can be triggered by various 2286 reasons, e.g., normal user termination, network failure, and ASR 2287 (Abort-Session-Request). The Termination-Cause AVP contains 2288 information about the termination reason, as specified in [RFC6733]. 2290 The Tx timer, which is used to control the waiting time in the 2291 credit-control client in the Pending state, is stopped upon exit of 2292 the Pending state. The stopping of the Tx timer is omitted in the 2293 state machine when the new state is Idle, as moving to Idle state 2294 implies the clearing of the session and all the variables associated 2295 to it. 2297 The states PendingI, PendingU, PendingT, PendingE, and PendingB stand 2298 for pending states to wait for an answer to a credit-control request 2299 related to Initial, Update, Termination, Event, or Buffered request, 2300 respectively. 2302 The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling 2303 and Direct-Debiting-Failure-Handling, respectively. 2305 In the following state machine table, the failover to a secondary 2306 server upon 'Temporary error' or 'Failure to send' is not explicitly 2307 described. Moving an ongoing credit-control message stream to an 2308 alternative server is, however, possible if the CC-Session-Failover 2309 AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7. 2311 Re-sending a credit-control event to an alternative server is 2312 supported as described in Section 6.5. 2314 +----------+-------------------------------+-------------+----------+ 2315 | State | Event | Action | New | 2316 | | | | State | 2317 +----------+-------------------------------+-------------+----------+ 2318 | Idle | Client or device requests | Send AA | PendingI | 2319 | | access/service | request | | 2320 | | | with added | | 2321 | | | CC AVPs, | | 2322 | | | start Tx | | 2323 | | | timer | | 2324 | PendingI | Successful AA req. answer | Grant | Open | 2325 | | received | service to | | 2326 | | | end user, | | 2327 | | | stop Tx | | 2328 | | | timer | | 2329 | PendingI | Tx timer expired | Disconnect | Idle | 2330 | | | user/dev | | 2331 | PendingI | Failed AA answer received | Disconnect | Idle | 2332 | | | user/dev | | 2333 | PendingI | AA answer received with | Grant | Idle | 2334 | | result code equal to | service to | | 2335 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2336 | PendingI | User service terminated | Queue | PendingI | 2337 | | | termination | | 2338 | | | event | | 2339 | PendingI | Change in rating condition | Queue | PendingI | 2340 | | | changed | | 2341 | | | rating | | 2342 | | | condition | | 2343 | | | event | | 2344 +----------+-------------------------------+-------------+----------+ 2346 Table 2: CLIENT, SESSION BASED for the first interrogation with AA 2347 request 2349 +----------+-------------------------------+-------------+----------+ 2350 | State | Event | Action | New | 2351 | | | | State | 2352 +----------+-------------------------------+-------------+----------+ 2353 | Idle | Client or device requests | Send CC | PendingI | 2354 | | access/service | initial | | 2355 | | | req., start | | 2356 | | | Tx timer | | 2357 | PendingI | Successful CC initial answer | Stop Tx | Open | 2358 | | received | timer | | 2359 | PendingI | Failure to send, or temporary | Grant | Idle | 2360 | | error and CCFH equal to | service to | | 2361 | | CONTINUE | end user | | 2362 | PendingI | Failure to send, or temporary | Terminate | Idle | 2363 | | error and CCFH equal to | end user's | | 2364 | | TERMINATE or to | service | | 2365 | | RETRY_AND_TERMINATE | | | 2366 | PendingI | Tx timer expired and CCFH | Terminate | Idle | 2367 | | equal to TERMINATE | end user's | | 2368 | | | service | | 2369 | PendingI | Tx timer expired and CCFH | Grant | PendingI | 2370 | | equal to CONTINUE or to | service to | | 2371 | | RETRY_AND_TERMINATE | end user | | 2372 | PendingI | CC initial answer received | Terminate | Idle | 2373 | | with result code | end user's | | 2374 | | END_USER_SERVICE_DENIED or | service | | 2375 | | USER_UNKNOWN | | | 2376 | PendingI | CC initial answer received | Grant | Idle | 2377 | | with result code equal to | service to | | 2378 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2379 | PendingI | Failed CC initial answer | Grant | Idle | 2380 | | received and CCFH equal to | service to | | 2381 | | CONTINUE | end user | | 2382 | PendingI | Failed CC initial answer | Terminate | Idle | 2383 | | received and CCFH equal to | end user's | | 2384 | | TERMINATE or to | service | | 2385 | | RETRY_AND_TERMINATE | | | 2386 | PendingI | User service terminated | Queue | PendingI | 2387 | | | termination | | 2388 | | | event | | 2389 | PendingI | Change in rating condition | Queue | PendingI | 2390 | | | changed | | 2391 | | | rating | | 2392 | | | condition | | 2393 | | | event | | 2394 +----------+-------------------------------+-------------+----------+ 2396 Table 3: CLIENT, SESSION BASED for the first interrogation with CCR 2398 +----------+-------------------------------+-------------+----------+ 2399 | State | Event | Action | New | 2400 | | | | State | 2401 +----------+-------------------------------+-------------+----------+ 2402 | Open | Granted unit elapses and no | Send CC | PendingU | 2403 | | final unit indication | update | | 2404 | | received | req., start | | 2405 | | | Tx timer | | 2406 | Open | Granted unit elapses and | Terminate | PendingT | 2407 | | final unit action equal to | end user's | | 2408 | | TERMINATE received | service, | | 2409 | | | send CC | | 2410 | | | termination | | 2411 | | | req. | | 2412 | Open | Change in rating condition in | Send CC | PendingU | 2413 | | queue | update | | 2414 | | | req., Start | | 2415 | | | Tx timer | | 2416 | Open | Service terminated in queue | Send CC | PendingT | 2417 | | | termination | | 2418 | | | req. | | 2419 | Open | Change in rating condition or | Send CC | PendingU | 2420 | | Validity-Time elapses | update | | 2421 | | | req., Start | | 2422 | | | Tx timer | | 2423 | Open | User service terminated | Send CC | PendingT | 2424 | | | termination | | 2425 | | | req. | | 2426 | Open | RAR received | Send RAA | PendingU | 2427 | | | followed by | | 2428 | | | CC update | | 2429 | | | req., start | | 2430 | | | Tx timer | | 2431 | PendingU | Successful CC update answer | Stop Tx | Open | 2432 | | received | timer | | 2433 | PendingU | Failure to send, or temporary | Grant | Idle | 2434 | | error and CCFH equal to | service to | | 2435 | | CONTINUE | end user | | 2436 | PendingU | Failure to send, or temporary | Terminate | Idle | 2437 | | error and CCFH equal to | end user's | | 2438 | | TERMINATE or to | service | | 2439 | | RETRY_AND_TERMINATE | | | 2440 | PendingU | Tx timer expired and CCFH | Terminate | Idle | 2441 | | equal to TERMINATE | end user's | | 2442 | | | service | | 2443 | PendingU | Tx timer expired and CCFH | Grant | PendingU | 2444 | | equal to CONTINUE or to | service to | | 2445 | | RETRY_AND_TERMINATE | end user | | 2446 | PendingU | CC update answer received | Terminate | Idle | 2447 | | with result code | end user's | | 2448 | | END_USER_SERVICE_DENIED | service | | 2449 | PendingU | CC update answer received | Grant | Idle | 2450 | | with result code equal to | service to | | 2451 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2452 | PendingU | Failed CC update answer | Grant | Idle | 2453 | | received and CCFH equal to | service to | | 2454 | | CONTINUE | end user | | 2455 | PendingU | Failed CC update answer | Terminate | Idle | 2456 | | received and CCFH equal to | end user's | | 2457 | | TERMINATE or to | service | | 2458 | | RETRY_AND_TERMINATE | | | 2459 | PendingU | User service terminated | Queue | PendingU | 2460 | | | termination | | 2461 | | | event | | 2462 | PendingU | Change in rating condition | Queue | PendingU | 2463 | | | changed | | 2464 | | | rating | | 2465 | | | condition | | 2466 | | | event | | 2467 | PendingU | RAR received | Send RAA | PendingU | 2468 | PendingT | Successful CC termination | | Idle | 2469 | | answer received | | | 2470 | PendingT | Failure to send, temporary | | Idle | 2471 | | error, or failed answer | | | 2472 | PendingT | Change in rating condition | | PendingT | 2473 +----------+-------------------------------+-------------+----------+ 2475 Table 4: CLIENT, SESSION BASED for intermediate and final 2476 interrogations 2478 +----------+--------------------------------+------------+----------+ 2479 | State | Event | Action | New | 2480 | | | | State | 2481 +----------+--------------------------------+------------+----------+ 2482 | Idle | Client or device requests a | Send CC | PendingE | 2483 | | one-time service | event | | 2484 | | | req., | | 2485 | | | Start Tx | | 2486 | | | timer | | 2487 | Idle | Request in storage | Send | PendingB | 2488 | | | stored | | 2489 | | | request | | 2490 | PendingE | Successful CC event answer | Grant | Idle | 2491 | | received | service to | | 2492 | | | end user | | 2493 | PendingE | Failure to send, temporary | Indicate | Idle | 2494 | | error, failed CC event answer | service | | 2495 | | received, or Tx timer expired; | error | | 2496 | | requested action CHECK_BALANCE | | | 2497 | | or PRICE_ENQUIRY | | | 2498 | PendingE | CC event answer received with | Terminate | Idle | 2499 | | result code | end user's | | 2500 | | END_USER_SERVICE_DENIED or | service | | 2501 | | USER_UNKNOWN and Tx timer | | | 2502 | | running | | | 2503 | PendingE | CC event answer received with | Grant | Idle | 2504 | | result code | service to | | 2505 | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | | 2506 | | requested action | | | 2507 | | DIRECT_DEBITING | | | 2508 | PendingE | Failure to send, temporary | Grant | Idle | 2509 | | error, failed CC event answer | service to | | 2510 | | received; requested action | end user | | 2511 | | DIRECT_DEBITING; DDFH equal to | | | 2512 | | CONTINUE | | | 2513 | PendingE | Failed CC event answer | Terminate | Idle | 2514 | | received or temporary error; | end user's | | 2515 | | requested action | service | | 2516 | | DIRECT_DEBITING; DDFH equal to | | | 2517 | | TERMINATE_OR_BUFFER and Tx | | | 2518 | | timer running | | | 2519 | PendingE | Tx timer expired; requested | Grant | PendingE | 2520 | | action DIRECT_DEBITING | service to | | 2521 | | | end user | | 2522 | PendingE | Failure to send; requested | Store | Idle | 2523 | | action DIRECT_DEBITING; DDFH | request | | 2524 | | equal to TERMINATE_OR_BUFFER | with | | 2525 | | | T-flag | | 2526 | PendingE | Temporary error; requested | Store | Idle | 2527 | | action DIRECT_DEBITING; DDFH | request | | 2528 | | equal to TERMINATE_OR_BUFFER; | | | 2529 | | Tx timer expired | | | 2530 | PendingE | Failed answer or answer | | Idle | 2531 | | received with result code | | | 2532 | | END_USER_SERVICE DENIED or | | | 2533 | | USER_UNKNOWN; requested action | | | 2534 | | DIRECT_DEBITING; Tx timer | | | 2535 | | expired | | | 2536 | PendingE | Failed CC event answer | Indicate | Idle | 2537 | | received; requested action | service | | 2538 | | REFUND_ACCOUNT | error and | | 2539 | | | delete | | 2540 | | | request | | 2541 | PendingE | Failure to send or Tx timer | Store | Idle | 2542 | | expired; requested action | request | | 2543 | | REFUND_ACCOUNT | with | | 2544 | | | T-flag | | 2545 | PendingE | Temporary error, and requested | Store | Idle | 2546 | | action REFUND_ACCOUNT | request | | 2547 | PendingB | Successful CC answer received | Delete | Idle | 2548 | | | request | | 2549 | PendingB | Failed CC answer received | Delete | Idle | 2550 | | | request | | 2551 | PendingB | Failure to send or temporary | | Idle | 2552 | | error | | | 2553 +----------+--------------------------------+------------+----------+ 2555 Table 5: CLIENT, EVENT BASED 2557 +-------+------------------------+--------------------------+-------+ 2558 | State | Event | Action | New | 2559 | | | | State | 2560 +-------+------------------------+--------------------------+-------+ 2561 | Idle | CC initial request | Send CC initial answer, | Open | 2562 | | received and | reserve units, start Tcc | | 2563 | | successfully processed | | | 2564 | Idle | CC initial request | Send CC initial answer | Idle | 2565 | | received but not | with Result-Code != | | 2566 | | successfully processed | SUCCESS | | 2567 | Idle | CC event request | Send CC event answer | Idle | 2568 | | received and | | | 2569 | | successfully processed | | | 2570 | Idle | CC event request | Send CC event answer | Idle | 2571 | | received but not | with Result-Code != | | 2572 | | successfully processed | SUCCESS | | 2573 | Open | CC update request | Send CC update answer, | Open | 2574 | | received and | debit used units, | | 2575 | | successfully processed | reserve new units, | | 2576 | | | restart Tcc | | 2577 | Open | CC update request | Send CC update answer | Idle | 2578 | | received but not | with Result-Code != | | 2579 | | successfully processed | SUCCESS, debit used | | 2580 | | | units | | 2581 | Open | CC termination request | Send CC termin. answer, | Idle | 2582 | | received and | Stop Tcc, debit used | | 2583 | | successfully processed | units | | 2584 | Open | CC termination request | Send CC termin. answer | Idle | 2585 | | received but not | with Result-Code != | | 2586 | | successfully processed | SUCCESS, debit used | | 2587 | | | units | | 2588 | Open | Session supervision | Release reserved units | Idle | 2589 | | timer Tcc expired | | | 2590 +-------+------------------------+--------------------------+-------+ 2592 Table 6: SERVER, SESSION AND EVENT BASED 2594 8. Credit-Control AVPs 2596 This section defines the credit-control AVPs that are specific to 2597 Diameter credit-control application and that MAY be included in the 2598 Diameter credit-control messages. 2600 The AVPs defined in this section MAY also be included in 2601 authorization commands defined in authorization-specific 2602 applications, such as [RFC7155] and [RFC4004], if the first 2603 interrogation is performed as part of the authorization/ 2604 authentication process, as described in Section 5.2. 2606 The Diameter AVP rules are defined in the Diameter Base [RFC6733], 2607 Section 4. These AVP rules are observed in AVPs defined in this 2608 section. 2610 The following table describes the Diameter AVPs defined in the 2611 credit-control application, their AVP Code values, types, and 2612 possible flag values. The AVP Flag rules are explained in the 2613 Diameter base [RFC6733], section 4.1. 2615 +---------------+ 2616 |AVP Flag rules | 2617 |----+-----+----| 2618 AVP Section | | |MUST| 2619 Attribute Name Code Defined Data Type |MUST| MAY |NOT | 2620 -----------------------------------------|----+-----+----| 2621 CC-Correlation-Id 411 8.1 OctetString| | M | V | 2622 CC-Input-Octets 412 8.24 Unsigned64 | M | | V | 2623 CC-Money 413 8.22 Grouped | M | | V | 2624 CC-Output-Octets 414 8.25 Unsigned64 | M | | V | 2625 CC-Request-Number 415 8.2 Unsigned32 | M | | V | 2626 CC-Request-Type 416 8.3 Enumerated | M | | V | 2627 CC-Service- 417 8.26 Unsigned64 | M | | V | 2628 Specific-Units | | | | 2629 CC-Session- 418 8.4 Enumerated | M | | V | 2630 Failover | | | | 2631 CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V | 2632 CC-Time 420 8.21 Unsigned32 | M | | V | 2633 CC-Total-Octets 421 8.23 Unsigned64 | M | | V | 2634 CC-Unit-Type 454 8.32 Enumerated | M | | V | 2635 Check-Balance- 422 8.6 Enumerated | M | | V | 2636 Result | | | | 2637 Cost-Information 423 8.7 Grouped | M | | V | 2638 Cost-Unit 424 8.12 UTF8String | M | | V | 2639 Credit-Control 426 8.13 Enumerated | M | | V | 2640 Credit-Control- 427 8.14 Enumerated | M | | V | 2641 Failure-Handling | | | | 2642 Currency-Code 425 8.11 Unsigned32 | M | | V | 2643 Direct-Debiting- 428 8.15 Enumerated | M | | V | 2644 Failure-Handling | | | | 2645 Exponent 429 8.9 Integer32 | M | | V | 2646 Final-Unit-Action 449 8.35 Enumerated | M | | V | 2647 Final-Unit- 430 8.34 Grouped | M | | V | 2648 Indication | | | | 2649 QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | 2650 Indication | | | | 2651 Granted-Service- 431 8.17 Grouped | M | | V | 2652 Unit | | | | 2653 G-S-U-Pool- 453 8.31 Unsigned32 | M | | V | 2654 Identifier | | | | 2655 G-S-U-Pool- 457 8.30 Grouped | M | | V | 2656 Reference | | | | 2657 Multiple-Services 456 8.16 Grouped | M | | V | 2658 -Credit-Control | | | | 2659 Multiple-Services 455 8.40 Enumerated | M | | V | 2660 -Indicator | | | | 2661 Rating-Group 432 8.29 Unsigned32 | M | | V | 2662 Redirect-Address 433 8.38 Enumerated | M | | V | 2663 -Type | | | | 2664 Redirect-Server 434 8.37 Grouped | M | | V | 2665 Redirect-Server 435 8.39 UTF8String | M | | V | 2666 -Address | | | | 2667 Redirect-Server TBD13 8.64 Grouped | | M | V | 2668 -Extension | | | | 2669 Redirect-Address TBD14 8.65 Address | | M | V | 2670 -IPAddress | | | | 2671 Redirect-Address TBD15 8.66 UTF8String | | M | V | 2672 -URL | | | | 2673 Redirect-Address TBD16 8.67 UTF8String | | M | V | 2674 -SIP-URI | | | | 2675 Requested-Action 436 8.41 Enumerated | M | | V | 2676 Requested-Service 437 8.18 Grouped | M | | V | 2677 -Unit | | | | 2678 Restriction 438 8.36 IPFiltrRule| M | | V | 2679 -Filter-Rule | | | | 2680 Service-Context 461 8.42 UTF8String | M | | V | 2681 -Id | | | | 2682 Service- 439 8.28 Unsigned32 | M | | V | 2683 Identifier | | | | 2684 Service-Parameter 440 8.43 Grouped | | M | V | 2685 -Info | | | | 2686 Service- 441 8.44 Unsigned32 | | M | V | 2687 Parameter-Type | | | | 2688 Service- 442 8.45 OctetString| | M | V | 2689 Parameter-Value | | | | 2690 Subscription-Id 443 8.46 Grouped | M | | V | 2691 Subscription-Id 444 8.48 UTF8String | M | | V | 2692 -Data | | | | 2693 Subscription-Id 450 8.47 Enumerated | M | | V | 2694 -Type | | | | 2695 Subscription-Id TBD7 8.58 Grouped | | M | V | 2696 -Extension | | | | 2697 Subscription-Id TBD8 8.59 UTF8String | | M | V | 2698 -E164 | | | | 2699 Subscription-Id TBD9 8.60 UTF8String | | M | V | 2700 -IMSI | | | | 2701 Subscription-Id TBD10 8.61 UTF8String | | M | V | 2702 -SIP-URI | | | | 2703 Subscription-Id TBD11 8.62 UTF8String | | M | V | 2704 -NAI | | | | 2705 Subscription-Id TBD12 8.63 UTF8String | | M | V | 2706 -Private | | | | 2707 Tariff-Change 452 8.27 Enumerated | M | | V | 2708 -Usage | | | | 2709 Tariff-Time 451 8.20 Time | M | | V | 2710 -Change | | | | 2711 Unit-Value 445 8.8 Grouped | M | | V | 2712 Used-Service-Unit 446 8.19 Grouped | M | | V | 2713 User-Equipment 458 8.49 Grouped | | M | V | 2714 -Info | | | | 2715 User-Equipment 459 8.50 Enumerated | | M | V | 2716 -Info-Type | | | | 2717 User-Equipment 460 8.51 OctetString| | M | V | 2718 -Info-Value | | | | 2719 User-Equipment TBD1 8.52 Grouped | | M | V | 2720 -Info-Extension | | | | 2721 User-Equipment TBD2 8.53 OctetString| | M | V | 2722 -Info-IMEISV | | | | 2723 User-Equipment TBD3 8.54 OctetString| | M | V | 2724 -Info-MAC | | | | 2725 User-Equipment TBD4 8.55 OctetString| | M | V | 2726 -Info-EUI64 | | | | 2727 User-Equipment TBD5 8.56 OctetString| | M | V | 2728 -Info-ModifiedEUI64 | | | | 2729 User-Equipment TBD6 8.57 OctetString| | M | V | 2730 -Info-IMEI | | | | 2731 Value-Digits 447 8.10 Integer64 | M | | V | 2732 Validity-Time 448 8.33 Unsigned32 | M | | V | 2734 8.1. CC-Correlation-Id AVP 2736 The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and 2737 contains information to correlate credit-control requests generated 2738 for different components of the service; e.g., transport and service 2739 level. The one who allocates the Service-Context-Id (i.e., unique 2740 identifier of a service-specific document) is also responsible for 2741 defining the content and encoding of the CC-Correlation-Id AVP. 2743 8.2. CC-Request-Number AVP 2745 The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and 2746 identifies this request within one session. As Session-Id AVPs are 2747 globally unique, the combination of Session-Id and CC-Request-Number 2748 AVPs is also globally unique and can be used in matching credit- 2749 control messages with confirmations. An easy way to produce unique 2750 numbers is to set the value to 0 for a credit-control request of type 2751 INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the 2752 first UPDATE_REQUEST, to 2 for the second, and so on until the value 2753 for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST. 2755 8.3. CC-Request-Type AVP 2757 The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and 2758 contains the reason for sending the credit-control request message. 2759 It MUST be present in all Credit-Control-Request messages. The 2760 following values are defined for the CC-Request-Type AVP (The value 2761 of zero is reserved): 2763 INITIAL_REQUEST 1 2765 An Initial request is used to initiate a credit-control session, and 2766 contains credit-control information that is relevant to the 2767 initiation. 2769 UPDATE_REQUEST 2 2771 An Update request contains credit-control information for an existing 2772 credit-control session. Update credit-control requests SHOULD be 2773 sent every time a credit-control re-authorization is needed at the 2774 expiry of the allocated quota or validity time. Further, additional 2775 service-specific events MAY trigger a spontaneous Update request. 2777 TERMINATION_REQUEST 3 2779 A Termination request is sent to terminate a credit-control session 2780 and contains credit-control information relevant to the existing 2781 session. 2783 EVENT_REQUEST 4 2785 An Event request is used when there is no need to maintain any 2786 credit-control session state in the credit-control server. This 2787 request contains all information relevant to the service, and is the 2788 only request of the service. The reason for the Event request is 2789 further detailed in the Requested-Action AVP. The Requested-Action 2790 AVP MUST be included in the Credit-Control-Request message when CC- 2791 Request-Type is set to EVENT_REQUEST. 2793 8.4. CC-Session-Failover AVP 2795 The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and 2796 contains information as to whether moving the credit-control message 2797 stream to a backup server during an ongoing credit-control session is 2798 supported. In communication failures, the credit-control message 2799 streams can be moved to an alternative destination if the credit- 2800 control server supports failover to an alternative server. The 2801 secondary credit-control server name, if received from the home 2802 Diameter AAA server, can be used as an address of the backup server. 2803 An implementation is not required to support moving a credit-control 2804 message stream to an alternative server, as this also requires moving 2805 information related to the credit-control session to backup server. 2807 The following values are defined for the CC-Session-Failover AVP: 2809 FAILOVER_NOT_SUPPORTED 0 2811 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, 2812 the credit-control message stream MUST NOT be moved to an alternative 2813 destination in the case of communication failure. This is the 2814 default behavior if the AVP isn't included in the reply from the 2815 authorization or credit-control server. 2817 FAILOVER_SUPPORTED 1 2819 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the 2820 credit-control message stream SHOULD be moved to an alternative 2821 destination in the case of communication failure. Moving the credit- 2822 control message stream to a backup server MAY require that 2823 information related to the credit-control session should also be 2824 forwarded to an alternative server. 2826 8.5. CC-Sub-Session-Id AVP 2828 The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and 2829 contains the credit-control sub-session identifier. The combination 2830 of the Session-Id and this AVP MUST be unique per sub-session, and 2831 the value of this AVP MUST be monotonically increased by one for all 2832 new sub-sessions. The absence of this AVP implies that no sub- 2833 sessions are in use. 2835 8.6. Check-Balance-Result AVP 2837 The Check Balance Result AVP (AVP Code 422) is of type Enumerated and 2838 contains the result of the balance check. This AVP is applicable 2839 only when the Requested-Action AVP indicates CHECK_BALANCE in the 2840 Credit-Control-Request command. The following values are defined for 2841 the Check-Balance-Result AVP. 2843 ENOUGH_CREDIT 0 2845 There is enough credit in the account to cover the requested service. 2847 NO_CREDIT 1 2849 There isn't enough credit in the account to cover the requested 2850 service. 2852 8.7. Cost-Information AVP 2854 The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is 2855 used to return the cost information of a service, which the credit- 2856 control client can transfer transparently to the end user. The 2857 included Unit-Value AVP contains the cost estimate (always type of 2858 money) of the service, in the case of price enquiry, or the 2859 accumulated cost estimation, in the case of credit-control session. 2861 The Currency-Code specifies in which currency the cost was given. 2862 The Cost-Unit specifies the unit when the service cost is a cost per 2863 unit (e.g., cost for the service is $1 per minute). 2865 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 2866 the Credit-Control-Request command, the Cost-Information AVP sent in 2867 the succeeding Credit-Control-Answer command contains the cost 2868 estimation of the requested service, without any reservation being 2869 made. 2871 The Cost-Information AVP included in the Credit-Control-Answer 2872 command with the CC-Request-Type set to UPDATE_REQUEST contains the 2873 accumulated cost estimation for the session, without taking any 2874 credit reservation into account. 2876 The Cost-Information AVP included in the Credit-Control-Answer 2877 command with the CC-Request-Type set to EVENT_REQUEST or 2878 TERMINATION_REQUEST contains the estimated total cost for the 2879 requested service. 2881 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2883 Cost-Information ::= < AVP Header: 423 > 2884 { Unit-Value } 2885 { Currency-Code } 2886 [ Cost-Unit ] 2888 8.8. Unit-Value AVP 2890 Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the 2891 units as decimal value. The Unit-Value is a value with an exponent; 2892 i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This 2893 representation avoids unwanted rounding off. For example, the value 2894 of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The 2895 absence of the exponent part MUST be interpreted as an exponent equal 2896 to zero. 2898 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2900 Unit-Value ::= < AVP Header: 445 > 2901 { Value-Digits } 2902 [ Exponent ] 2904 8.9. Exponent AVP 2906 Exponent AVP is of type Integer32 (AVP Code 429) and contains the 2907 exponent value to be applied for the Value-Digit AVP within the Unit- 2908 Value AVP. 2910 8.10. Value-Digits AVP 2912 The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains 2913 the significant digits of the number. If decimal values are needed 2914 to present the units, the scaling MUST be indicated with the related 2915 Exponent AVP. For example, for the monetary amount $ 0.05 the value 2916 of Value-Digits AVP MUST be set to 5, and the scaling MUST be 2917 indicated with the Exponent AVP set to -2. 2919 8.11. Currency-Code AVP 2921 The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and 2922 contains a currency code that specifies in which currency the values 2923 of AVPs containing monetary units were given. It is specified by 2924 using the numeric values defined in the ISO 4217 standard [ISO4217]. 2926 8.12. Cost-Unit AVP 2928 The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is 2929 used to display a human readable string to the end user. It 2930 specifies the applicable unit to the Cost-Information when the 2931 service cost is a cost per unit (e.g., cost of the service is $1 per 2932 minute). The Cost-Unit can be minutes, hours, days, kilobytes, 2933 megabytes, etc. 2935 8.13. Credit-Control AVP 2937 The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST 2938 be included in AA requests when the service element has credit- 2939 control capabilities. 2941 CREDIT_AUTHORIZATION 0 2943 If the home Diameter AAA server determines that the user has prepaid 2944 subscription, this value indicates that the credit-control server 2945 MUST be contacted to perform the first interrogation. The value of 2946 the Credit-Control AVP MUST always be set to 0 in an AA request sent 2947 to perform the first interrogation and to initiate a new credit- 2948 control session. 2950 RE_AUTHORIZATION 1 2952 This value indicates to the Diameter AAA server that a credit-control 2953 session is ongoing for the subscriber and that the credit-control 2954 server MUST NOT be contacted. The Credit-Control AVP set to the 2955 value of 1 is to be used only when the first interrogation has been 2956 successfully performed and the credit-control session is ongoing 2957 (i.e., re-authorization triggered by Authorization-Lifetime). This 2958 value MUST NOT be used in an AA request sent to perform the first 2959 interrogation. 2961 8.14. Credit-Control-Failure-Handling AVP 2963 The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type 2964 Enumerated. The credit-control client uses information in this AVP 2965 to decide what to do if sending credit-control messages to the 2966 credit-control server has been, for instance, temporarily prevented 2967 due to a network problem. Depending on the service logic, the 2968 credit-control server can order the client to terminate the service 2969 immediately when there is a reason to believe that the service cannot 2970 be charged, or to try failover to an alternative server, if possible. 2971 Then the server could either terminate or grant the service, should 2972 the alternative connection also fail. 2974 TERMINATE 0 2976 When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the 2977 service MUST only be granted for as long as there is a connection to 2978 the credit-control server. If the credit-control client does not 2979 receive any Credit-Control-Answer message within the Tx timer (as 2980 defined in Section 13), the credit-control request is regarded as 2981 failed, and the end user's service session is terminated. 2983 This is the default behavior if the AVP isn't included in the reply 2984 from the authorization or credit-control server. 2986 CONTINUE 1 2987 When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the 2988 credit-control client SHOULD re-send the request to an alternative 2989 server in the case of transport or temporary failures, provided that 2990 a failover procedure is supported in the credit-control server and 2991 the credit-control client, and that an alternative server is 2992 available. Otherwise, the service SHOULD be granted, even if credit- 2993 control messages can't be delivered. 2995 RETRY_AND_TERMINATE 2 2997 When the Credit-Control-Failure-Handling AVP is set to 2998 RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the 2999 request to an alternative server in the case of transport or 3000 temporary failures, provided that a failover procedure is supported 3001 in the credit-control server and the credit-control client, and that 3002 an alternative server is available. Otherwise, the service SHOULD 3003 NOT be granted when the credit-control messages can't be delivered. 3005 8.15. Direct-Debiting-Failure-Handling AVP 3007 The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type 3008 Enumerated. The credit-control client uses information in this AVP 3009 to decide what to do if sending credit-control messages (Requested- 3010 Action AVP set to DIRECT_DEBITING) to the credit-control server has 3011 been, for instance, temporarily prevented due to a network problem. 3013 TERMINATE_OR_BUFFER 0 3015 When the Direct-Debiting-Failure-Handling AVP is set to 3016 TERMINATE_OR_BUFFER, the service MUST be granted for as long as there 3017 is a connection to the credit-control server. If the credit-control 3018 client does not receive any Credit-Control-Answer message within the 3019 Tx timer (as defined in Section 13) the credit-control request is 3020 regarded as failed. The client SHOULD terminate the service if it 3021 can determine from the failed answer that units have not been 3022 debited. Otherwise the credit-control client SHOULD grant the 3023 service, store the request in application level non-volatile storage, 3024 and try to re-send the request. These requests MUST be marked as 3025 possible duplicates by setting the T-flag in the command header as 3026 described in [RFC6733] section 3. This is the default behavior if 3027 the AVP isn't included in the reply from the authorization server. 3029 CONTINUE 1 3031 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 3032 service SHOULD be granted, even if credit-control messages can't be 3033 delivered, and the request should be deleted. 3035 8.16. Multiple-Services-Credit-Control AVP 3037 Multiple-Services-Credit-Control AVP (AVP Code 456) is of type 3038 Grouped and contains the AVPs related to the independent credit- 3039 control of multiple services feature. Note that each instance of 3040 this AVP carries units related to one or more services or related to 3041 a single rating group. 3043 The Service-Identifier and the Rating-Group AVPs are used to 3044 associate the granted units to a given service or rating group. If 3045 both the Service-Identifier and the Rating-Group AVPs are included, 3046 the target of the service units is always the service(s) indicated by 3047 the value of the Service-Identifier AVP(s). If only the Rating- 3048 Group-Id AVP is present, the Multiple-Services-Credit-Control AVP 3049 relates to all the services that belong to the specified rating 3050 group. 3052 The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- 3053 Pool-Identifier identifying a credit pool within which the units of 3054 the specified type are considered pooled. If a G-S-U-Pool-Reference 3055 AVP is present, then actual service units of the specified type MUST 3056 also be present. For example, if the G-S-U-Pool-Reference AVP 3057 specifies Unit-Type TIME, then the CC-Time AVP MUST be present. 3059 The Requested-Service-Unit AVP MAY contain the amount of requested 3060 service units or the requested monetary value. It MUST be present in 3061 the initial interrogation and within the intermediate interrogations 3062 in which new quota is requested. If the credit-control client does 3063 not include the Requested-Service-Unit AVP in a request command, 3064 because for instance, it has determined that the end-user terminated 3065 the service, the server MUST debit the used amount from the user's 3066 account but MUST NOT return a new quota in the corresponding answer. 3067 The Validity-Time, Result-Code, and Final-Unit-Indication or QoS- 3068 Final-Unit-Indication AVPs MAY be present in an answer command as 3069 defined in Section 5.1.2 and Section 5.6 for the graceful service 3070 termination. 3072 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 3073 present, the server MUST include two separate instances of the 3074 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit 3075 AVP associated to the same service-identifier and/or rating-group. 3076 Where the two quotas are associated to the same pool or to different 3077 pools, the credit pooling mechanism defined in Section 5.1.2 applies. 3078 The Tariff-Change-Usage AVP MUST NOT be included in request commands 3079 to report used units before, and after tariff time change the Used- 3080 Service-Unit AVP MUST be used. 3082 A server not implementing the independent credit-control of multiple 3083 services functionality MUST treat the Multiple-Services-Credit- 3084 Control AVP as an invalid AVP. 3086 The Multiple-Services-Control AVP is defined as follows (per the 3087 grouped-avp-def of [RFC6733]): 3089 Multiple-Services-Credit-Control ::= < AVP Header: 456 > 3090 [ Granted-Service-Unit ] 3091 [ Requested-Service-Unit ] 3092 *[ Used-Service-Unit ] 3093 [ Tariff-Change-Usage ] 3094 *[ Service-Identifier ] 3095 [ Rating-Group ] 3096 *[ G-S-U-Pool-Reference ] 3097 [ Validity-Time ] 3098 [ Result-Code ] 3099 [ Final-Unit-Indication ] 3100 [ QoS-Final-Unit-Indication ] 3101 *[ AVP ] 3103 8.17. Granted-Service-Unit AVP 3105 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 3106 contains the amount of units that the Diameter credit-control client 3107 can provide to the end user until the service must be released or the 3108 new Credit-Control-Request must be sent. A client is not required to 3109 implement all the unit types, and it must treat unknown or 3110 unsupported unit types in the answer message as an incorrect CCA 3111 answer. In this case, the client MUST terminate the credit-control 3112 session and indicate in the Termination-Cause AVP reason 3113 DIAMETER_BAD_ANSWER. 3115 The Granted-Service-Unit AVP is defined as follows (per the grouped- 3116 avp-def of [RFC6733]): 3118 Granted-Service-Unit ::= < AVP Header: 431 > 3119 [ Tariff-Time-Change ] 3120 [ CC-Time ] 3121 [ CC-Money ] 3122 [ CC-Total-Octets ] 3123 [ CC-Input-Octets ] 3124 [ CC-Output-Octets ] 3125 [ CC-Service-Specific-Units ] 3126 *[ AVP ] 3128 8.18. Requested-Service-Unit AVP 3130 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and 3131 contains the amount of requested units specified by the Diameter 3132 credit-control client. A server is not required to implement all the 3133 unit types, and it must treat unknown or unsupported unit types as 3134 invalid AVPs. 3136 The Requested-Service-Unit AVP is defined as follows (per the 3137 grouped-avp-def of [RFC6733]): 3139 Requested-Service-Unit ::= < AVP Header: 437 > 3140 [ CC-Time ] 3141 [ CC-Money ] 3142 [ CC-Total-Octets ] 3143 [ CC-Input-Octets ] 3144 [ CC-Output-Octets ] 3145 [ CC-Service-Specific-Units ] 3146 *[ AVP ] 3148 8.19. Used-Service-Unit AVP 3150 The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and 3151 contains the amount of used units measured from the point when the 3152 service became active or, if interim interrogations are used during 3153 the session, from the point when the previous measurement ended. 3154 Note: The values reported in a Used-Service-Unit AVP does not 3155 necessarily have a relation to the grant provided in a Granted- 3156 Service-Unit AVP, e.g., the value in this AVP may exceed the value in 3157 the grant. 3159 The Used-Service-Unit AVP is defined as follows (per the grouped-avp- 3160 def of [RFC6733]): 3162 Used-Service-Unit ::= < AVP Header: 446 > 3163 [ Tariff-Change-Usage ] 3164 [ CC-Time ] 3165 [ CC-Money ] 3166 [ CC-Total-Octets ] 3167 [ CC-Input-Octets ] 3168 [ CC-Output-Octets ] 3169 [ CC-Service-Specific-Units ] 3170 *[ AVP ] 3172 8.20. Tariff-Time-Change AVP 3174 The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is 3175 sent from the server to the client and includes the time in seconds 3176 since January 1, 1900, 00:00 UTC, when the tariff of the service will 3177 be changed. 3179 The tariff change mechanism is optional for the client and server, 3180 and it is not used for time-based services defined in Section 5. If 3181 a client does not support the tariff time change mechanism, it MUST 3182 treat Tariff-Time-Change AVP in the answer message as an incorrect 3183 CCA answer. In this case, the client terminates the credit-control 3184 session and indicates in the Termination-Cause AVP reason 3185 DIAMETER_BAD_ANSWER. 3187 Omission of this AVP means that no tariff change is to be reported. 3189 8.21. CC-Time AVP 3191 The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates 3192 the length of the requested, granted, or used time in seconds. 3194 8.22. CC-Money AVP 3196 The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the 3197 monetary amount in the given currency. The Currency-Code AVP SHOULD 3198 be included. It is defined as follows (per the grouped-avp-def of 3199 [RFC6733]): 3201 CC-Money ::= < AVP Header: 413 > 3202 { Unit-Value } 3203 [ Currency-Code ] 3205 8.23. CC-Total-Octets AVP 3207 The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and 3208 contains the total number of requested, granted, or used octets 3209 regardless of the direction (sent or received). 3211 8.24. CC-Input-Octets AVP 3213 The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and 3214 contains the number of requested, granted, or used octets that can 3215 be/have been received from the end user. 3217 8.25. CC-Output-Octets AVP 3219 The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and 3220 contains the number of requested, granted, or used octets that can 3221 be/have been sent to the end user. 3223 8.26. CC-Service-Specific-Units AVP 3225 The CC-Service-Specific-Units AVP (AVP Code 417) is of type 3226 Unsigned64 and specifies the number of service-specific units (e.g., 3227 number of events, points) given in a selected service. The service- 3228 specific units always refer to the service identified in the Service- 3229 Identifier AVP (or Rating-Group AVP when the Multiple-Services- 3230 Credit-Control AVP is used). 3232 8.27. Tariff-Change-Usage AVP 3234 The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and 3235 defines whether units are used before or after a tariff change, or 3236 whether the units straddled a tariff change during the reporting 3237 period. Omission of this AVP means that no tariff change has 3238 occurred. 3240 In addition, when present in answer messages as part of the Multiple- 3241 Services-Credit-Control AVP, this AVP defines whether units are 3242 allocated to be used before or after a tariff change event. 3244 When the Tariff-Time-Change AVP is present, omission of this AVP in 3245 answer messages means that the single quota mechanism applies. 3247 Tariff-Change-Usage can be one of the following: 3249 UNIT_BEFORE_TARIFF_CHANGE 0 3251 When present in the Multiple-Services-Credit-Control AVP, this value 3252 indicates the amount of the units allocated for use before a tariff 3253 change occurs. 3255 When present in the Used-Service-Unit AVP, this value indicates the 3256 amount of resource units used before a tariff change had occurred. 3258 UNIT_AFTER_TARIFF_CHANGE 1 3260 When present in the Multiple-Services-Credit-Control AVP, this value 3261 indicates the amount of the units allocated for use after a tariff 3262 change occurs. 3264 When present in the Used-Service-Unit AVP, this value indicates the 3265 amount of resource units used after tariff change had occurred. 3267 UNIT_INDETERMINATE 2 3269 The used unit contains the amount of units that straddle the tariff 3270 change (e.g., the metering process reports to the credit-control 3271 client in blocks of n octets, and one block straddled the tariff 3272 change). This value is to be used only in the Used-Service-Unit AVP. 3274 8.28. Service-Identifier AVP 3276 The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and 3277 contains the identifier of a service. The specific service the 3278 request relates to is uniquely identified by the combination of 3279 Service-Context-Id and Service-Identifier AVPs. 3281 A usage example of this AVP is illustrated in Appendix B.9. 3283 8.29. Rating-Group AVP 3285 The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and 3286 contains the identifier of a rating group. All the services subject 3287 to the same rating type are part of the same rating group. The 3288 specific rating group the request relates to is uniquely identified 3289 by the combination of Service-Context-Id and Rating-Group AVPs. 3291 A usage example of this AVP is illustrated in Appendix B.9. 3293 8.30. G-S-U-Pool-Reference AVP 3295 The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It 3296 is used in the Credit-Control-Answer message, and associates the 3297 Granted-Service-Unit AVP within which it appears with a credit pool 3298 within the session. 3300 The G-S-U-Pool-Identifier AVP specifies the credit pool from which 3301 credit is drawn for this unit type. 3303 The CC-Unit-Type AVP specifies the type of units for which credit is 3304 pooled. 3306 The Unit-Value AVP specifies the multiplier, which converts between 3307 service units of type CC-Unit-Type and abstract service units within 3308 the credit pool (and thus to service units of any other service or 3309 rating group associated with the same pool). 3311 The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- 3312 avp-def of [RFC6733]): 3314 G-S-U-Pool-Reference ::= < AVP Header: 457 > 3315 { G-S-U-Pool-Identifier } 3316 { CC-Unit-Type } 3317 { Unit-Value } 3319 8.31. G-S-U-Pool-Identifier AVP 3321 The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 3322 and identifies a credit pool within the session. 3324 8.32. CC-Unit-Type AVP 3326 The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and 3327 specifies the type of units considered to be pooled into a credit 3328 pool. 3330 The following values are defined for the CC-Unit-Type AVP: 3332 TIME 0 3333 MONEY 1 3334 TOTAL-OCTETS 2 3335 INPUT-OCTETS 3 3336 OUTPUT-OCTETS 4 3337 SERVICE-SPECIFIC-UNITS 5 3339 8.33. Validity-Time AVP 3341 The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is 3342 sent from the credit-control server to the credit-control client. 3343 The AVP contains the validity time of the granted service units. The 3344 measurement of the Validity-Time is started upon receipt of the 3345 Credit-Control-Answer Message containing this AVP. If the granted 3346 service units have not been consumed within the validity time 3347 specified in this AVP, the credit-control client MUST send a Credit- 3348 Control-Request message to the server, with CC-Request-Type set to 3349 UPDATE_REQUEST. The value field of the Validity-Time AVP is given in 3350 seconds. 3352 The Validity-Time AVP is also used for the graceful service 3353 termination (see Section 5.6) to indicate to the credit-control 3354 client how long the subscriber is allowed to use network resources 3355 after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) 3356 started. When the Validity-Time elapses, a new intermediate 3357 interrogation is sent to the server. 3359 8.34. Final-Unit-Indication AVP 3361 The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and 3362 indicates that the Granted-Service-Unit AVP in the Credit-Control- 3363 Answer, or in the AA answer, contains the final units for the 3364 service. After these units have expired, the Diameter credit-control 3365 client is responsible for executing the action indicated in the 3366 Final-Unit-Action AVP (see Section 5.6). 3368 If more than one unit type is received in the Credit-Control-Answer, 3369 the unit type that first expired SHOULD cause the credit-control 3370 client to execute the specified action. 3372 In the first interrogation, the Final-Unit-Indication AVP with Final- 3373 Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no 3374 Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA 3375 answer. This indicates to the Diameter credit-control client to 3376 execute the specified action immediately. If the home service 3377 provider policy is to terminate the service, naturally, the server 3378 SHOULD return the appropriate transient failure (see Section 9.1) in 3379 order to implement the policy-defined action. 3381 The Final-Unit-Action AVP defines the behavior of the service element 3382 when the user's account cannot cover the cost of the service and MUST 3383 always be present if the Final-Unit-Indication AVP is included in a 3384 command. 3386 If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit- 3387 Indication group MUST NOT contain any other AVPs. 3389 If the Final-Unit-Action AVP is set to REDIRECT at least one of the 3390 Redirect-Server and Redirect-Server-Extension AVPs MUST be present. 3391 The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present 3392 in the Credit-Control-Answer message if the user is also allowed to 3393 access other services that are not accessible through the address 3394 given in the Redirect-Server AVP. 3396 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3397 Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3399 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 3400 used to reference an IP filter list installed in the access device by 3401 means other than the Diameter credit-control application, e.g., 3402 locally configured or configured by another entity. 3404 If the Final-Unit-Action AVP is set to REDIRECT and the type of 3405 server is not one of the enumerations in the Redirect-Address-Type 3406 AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together 3407 with the Redirect-Server-Extension AVP instead of the Final-Unit- 3408 Indication AVP. 3410 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT 3411 and the classification of the restricted traffic cannot be expressed 3412 using IPFilterRule, or different actions (e.g., QoS) than just 3413 allowing traffic needs to be enforced, then the QoS-Final-Unit- 3414 Indication AVP SHOULD be used instead of the Final-Unit-Indication 3415 AVP. However, if the credit-control server wants to preserve 3416 backward compatibility with credit-control clients that support only 3417 [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with 3418 the Filter-Id AVP. 3420 The Final-Unit-Indication AVP is defined as follows (per the grouped- 3421 avp-def of [RFC6733]): 3423 Final-Unit-Indication ::= < AVP Header: 430 > 3424 { Final-Unit-Action } 3425 *[ Restriction-Filter-Rule ] 3426 *[ Filter-Id ] 3427 [ Redirect-Server ] 3429 8.35. Final-Unit-Action AVP 3431 The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and 3432 indicates to the credit-control client the action to be taken when 3433 the user's account cannot cover the service cost. 3435 The Final-Unit-Action can be one of the following: 3437 TERMINATE 0 3439 The credit-control client MUST terminate the service session. This 3440 is the default handling, applicable whenever the credit-control 3441 client receives an unsupported Final-Unit-Action value, and it MUST 3442 be supported by all the Diameter credit-control client 3443 implementations conforming to this specification. 3445 REDIRECT 1 3447 The service element MUST redirect the user to the address specified 3448 in the Redirect-Server-Address AVP or one of the AVPs included in the 3449 Redirect-Server-Extension AVP. The redirect action is defined in 3450 Section 5.6.2. 3452 RESTRICT_ACCESS 2 3453 The access device MUST restrict the user access according to the 3454 filter AVPs contained in the applied grouped AVP: according to IP 3455 packet filters defined in the Restriction-Filter-Rule AVP, according 3456 to the packet classifier filters defined in Filter-Rule AVP, or 3457 according to the packet filters identified by the Filter-Id AVP. All 3458 the packets not matching any filters MUST be dropped (see 3459 Section 5.6.3). 3461 8.36. Restriction-Filter-Rule AVP 3463 The Restriction-Filter-Rule AVP (AVP Code 438) is of type 3464 IPFilterRule and provides filter rules corresponding to services that 3465 are to remain accessible even if there are no more service units 3466 granted. The access device has to configure the specified filter 3467 rules for the subscriber and MUST drop all the packets not matching 3468 these filters. Zero, one, or more such AVPs MAY be present in a 3469 Credit-Control-Answer message or in an AA answer message. 3471 8.37. Redirect-Server AVP 3473 The Redirect-Server AVP (AVP Code 434) is of type Grouped and 3474 contains the address information of the redirect server (e.g., HTTP 3475 redirect server, SIP Server) with which the end user is to be 3476 connected when the account cannot cover the service cost. It MUST be 3477 present when the Final-Unit-Action AVP is set to REDIRECT. 3479 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3481 Redirect-Server ::= < AVP Header: 434 > 3482 { Redirect-Address-Type } 3483 { Redirect-Server-Address } 3485 8.38. Redirect-Address-Type AVP 3487 The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated 3488 and defines the address type of the address given in the Redirect- 3489 Server-Address AVP. 3491 The address type can be one of the following: 3493 IPv4 Address 0 3495 The address type is in the form of "dotted-decimal" IPv4 address, as 3496 defined in [RFC0791]. 3498 IPv6 Address 1 3499 The address type is in the form of IPv6 address, as defined in 3500 [RFC4291]. The address MUST conform to the text representation of 3501 the address according to [RFC5952]. 3503 Because [RFC5952] is more restrictive than the RFC3513 format 3504 required by [RFC4006], some legacy implementations may not be 3505 compliant with the new requirements. Accordingly, implementations 3506 receiving this AVP MAY be liberal in the textual IPv6 representations 3507 that are accepted without raising an error. 3509 URL 2 3511 The address type is in the form of Uniform Resource Locator, as 3512 defined in [RFC3986]. 3514 SIP URI 3 3516 The address type is in the form of SIP Uniform Resource Identifier, 3517 as defined in [RFC3261]. 3519 8.39. Redirect-Server-Address AVP 3521 The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String 3522 and defines the address of the redirect server (e.g., HTTP redirect 3523 server, SIP Server) with which the end user is to be connected when 3524 the account cannot cover the service cost. 3526 8.40. Multiple-Services-Indicator AVP 3528 The Multiple-Services-Indicator AVP (AVP Code 455) is of type 3529 Enumerated and indicates whether the Diameter credit-control client 3530 is capable of handling multiple services independently within a 3531 (sub-) session. The absence of this AVP means that independent 3532 credit-control of multiple services is not supported. 3534 A server not implementing the independent credit-control of multiple 3535 services MUST treat the Multiple-Services-Indicator AVP as an invalid 3536 AVP. 3538 The following values are defined for the Multiple-Services-Indicator 3539 AVP: 3541 MULTIPLE_SERVICES_NOT_SUPPORTED 0 3543 Client does not support independent credit-control of multiple 3544 services within a (sub-)session. 3546 MULTIPLE_SERVICES_SUPPORTED 1 3547 Client supports independent credit-control of multiple services 3548 within a (sub-)session. 3550 8.41. Requested-Action AVP 3552 The Requested-Action AVP (AVP Code 436) is of type Enumerated and 3553 contains the requested action being sent by Credit-Control-Request 3554 command where the CC-Request-Type is set to EVENT_REQUEST. The 3555 following values are defined for the Requested-Action AVP: 3557 DIRECT_DEBITING 0 3559 This indicates a request to decrease the end user's account according 3560 to information specified in the Requested-Service-Unit AVP and/or 3561 Service-Identifier AVP (additional rating information may be included 3562 in service-specific AVPs or in the Service-Parameter-Info AVP). The 3563 Granted-Service-Unit AVP in the Credit-Control-Answer command 3564 contains the debited units. 3566 REFUND_ACCOUNT 1 3568 This indicates a request to increase the end user's account according 3569 to information specified in the Requested-Service-Unit AVP and/or 3570 Service-Identifier AVP (additional rating information may be included 3571 in service-specific AVPs or in the Service-Parameter-Info AVP). The 3572 Granted-Service-Unit AVP in the Credit-Control-Answer command 3573 contains the refunded units. 3575 CHECK_BALANCE 2 3577 This indicates a balance check request. In this case, the checking 3578 of the account balance is done without any credit reservation from 3579 the account. The Check-Balance-Result AVP in the Credit-Control- 3580 Answer command contains the result of the balance check. 3582 PRICE_ENQUIRY 3 3584 This indicates a price enquiry request. In this case, neither 3585 checking of the account balance nor reservation from the account will 3586 be done; only the price of the service will be returned in the Cost- 3587 Information AVP in the Credit-Control-Answer Command. 3589 8.42. Service-Context-Id AVP 3591 The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and 3592 contains a unique identifier of the Diameter credit-control service- 3593 specific document that applies to the request (as defined in 3594 Section 4.1.2). This is an identifier allocated by the service 3595 provider, by the service element manufacturer, or by a 3596 standardization body, and MUST uniquely identify a given Diameter 3597 credit-control service-specific document. The format of the Service- 3598 Context-Id is: 3600 "service-context" "@" "domain" 3602 service-context = Token 3604 The Token is an arbitrary string of characters and digits. 3606 'domain' represents the entity that allocated the Service-Context-Id. 3607 It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by 3608 a standardization body, or it can be the FQDN of the service provider 3609 (e.g., provider.example.com) or of the vendor (e.g., 3610 vendor.example.com) if the identifier is allocated by a private 3611 entity. 3613 This AVP SHOULD be placed as close to the Diameter header as 3614 possible. 3616 Service-specific documents that are for private use only (i.e., to 3617 one provider's own use, where no interoperability is deemed useful) 3618 may define private identifiers without need of coordination. 3619 However, when interoperability is wanted, coordination of the 3620 identifiers via, for example, publication of an informational RFC is 3621 RECOMMENDED in order to make Service-Context-Id globally available. 3623 8.43. Service-Parameter-Info AVP 3625 The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and 3626 contains service-specific information used for price calculation or 3627 rating. The Service-Parameter-Type AVP defines the service parameter 3628 type, and the Service-Parameter-Value AVP contains the parameter 3629 value. The actual contents of these AVPs are not within the scope of 3630 this document and SHOULD be defined in another Diameter application, 3631 in standards written by other standardization bodies, or in service- 3632 specific documentation. 3634 In the case of an unknown service request (e.g., unknown Service- 3635 Parameter-Type), the corresponding answer message MUST contain the 3636 error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message 3637 with this error MUST contain one or more Failed-AVP AVPs containing 3638 the Service-Parameter-Info AVPs that caused the failure. 3640 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3642 Service-Parameter-Info ::= < AVP Header: 440 > 3643 { Service-Parameter-Type } 3644 { Service-Parameter-Value } 3646 8.44. Service-Parameter-Type AVP 3648 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) 3649 and defines the type of the service event specific parameter (e.g., 3650 it can be the end-user location or service name). The different 3651 parameters and their types are service-specific, and the meanings of 3652 these parameters are not defined in this document. Whoever allocates 3653 the Service-Context-Id (i.e., unique identifier of a service-specific 3654 document) is also responsible for assigning Service-Parameter-Type 3655 values for the service and ensuring their uniqueness within the given 3656 service. The Service-Parameter-Value AVP contains the value 3657 associated with the service parameter type. 3659 8.45. Service-Parameter-Value AVP 3661 The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) 3662 and contains the value of the service parameter type. 3664 8.46. Subscription-Id AVP 3666 The Subscription-Id AVP (AVP Code 443) is used to identify the end 3667 user's subscription and is of type Grouped. The Subscription-Id AVP 3668 includes a Subscription-Id-Data AVP that holds the identifier and a 3669 Subscription-Id-Type AVP that defines the identifier type. 3671 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3673 Subscription-Id ::= < AVP Header: 443 > 3674 { Subscription-Id-Type } 3675 { Subscription-Id-Data } 3677 8.47. Subscription-Id-Type AVP 3679 The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, 3680 and it is used to determine which type of identifier is carried by 3681 the Subscription-Id AVP. 3683 This specification defines the following subscription identifiers. 3684 However, new Subscription-Id-Type values can be assigned by IANA as 3685 defined in Section 12. A server MUST implement all the Subscription- 3686 Id-Types required to perform credit authorization for the services it 3687 supports, including possible future values. Unknown or unsupported 3688 Subscription-Id-Types MUST be treated according to the 'M' flag rule, 3689 as defined in [RFC6733]. 3691 END_USER_E164 0 3693 The identifier is in international E.164 format (e.g., MSISDN), 3694 according to the ITU-T E.164 numbering plan defined in [E164] and 3695 [CE164]. 3697 END_USER_IMSI 1 3699 The identifier is in international IMSI format, according to the 3700 ITU-T E.212 numbering plan as defined in [E212] and [CE212]. 3702 END_USER_SIP_URI 2 3704 The identifier is in the form of a SIP URI, as defined in [RFC3261]. 3706 END_USER_NAI 3 3708 The identifier is in the form of a Network Access Identifier, as 3709 defined in [RFC7542]. 3711 END_USER_PRIVATE 4 3713 The Identifier is a credit-control server private identifier. 3715 8.48. Subscription-Id-Data AVP 3717 The Subscription-Id-Data AVP (AVP Code 444) is used to identify the 3718 end user and is of type UTF8String. The Subscription-Id-Type AVP 3719 defines which type of identifier is used. 3721 8.49. User-Equipment-Info AVP 3723 The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and 3724 allows the credit-control client to indicate the identity and 3725 capability of the terminal the subscriber is using for the connection 3726 to network. 3728 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3730 User-Equipment-Info ::= < AVP Header: 458 > 3731 { User-Equipment-Info-Type } 3732 { User-Equipment-Info-Value } 3734 8.50. User-Equipment-Info-Type AVP 3736 The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) 3737 and defines the type of user equipment information contained in the 3738 User-Equipment-Info-Value AVP. 3740 This specification defines the following user equipment types. 3741 However, new User-Equipment-Info-Type values can be assigned by an 3742 IANA as defined in Section 12. 3744 IMEISV 0 3746 The identifier contains the International Mobile Equipment Identifier 3747 and Software Version in the international IMEISV format according to 3748 3GPP TS 23.003 [TGPPIMEI]. 3750 MAC 1 3752 The 48-bit MAC address is formatted as described in section 3.21 of 3753 [RFC3580]. 3755 EUI64 2 3757 The 64-bit identifier used to identify the hardware instance of the 3758 product, as defined in [EUI64]. 3760 MODIFIED_EUI64 3 3762 There are a number of types of terminals that have identifiers other 3763 than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be 3764 converted to modified EUI-64 format as described in [RFC4291] or by 3765 using some other methods referred to in the service-specific 3766 documentation. 3768 8.51. User-Equipment-Info-Value AVP 3770 The User-Equipment-Info-Value AVP (AVP Code 460) is of type 3771 OctetString. The User-Equipment-Info-Type AVP defines which type of 3772 identifier is used. 3774 8.52. User-Equipment-Info-Extension AVP 3776 The User-Equipment-Info-Extension AVP (AVP Code TBD1) is of type 3777 Grouped and allows the credit-control client to indicate the identity 3778 and capability of the terminal the subscriber is using for the 3779 connection to network. If the type of the equipment is one of the 3780 enumerated types of User-Equipment-Info-Type AVP, then the credit- 3781 control client SHOULD send the information in the User-Equipment-Info 3782 AVP, in addition to or instead of the User-Equipment-Info-Extension 3783 AVP. This is in order to preserve backward compatibility with 3784 credit-control servers that support only [RFC4006]. Exactly one AVP 3785 MUST be included inside the User-Equipment-Info-Extension AVP. 3787 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3789 User-Equipment-Info-Extension ::= < AVP Header: TBD1 > 3790 [ User-Equipment-Info-IMEISV ] 3791 [ User-Equipment-Info-MAC ] 3792 [ User-Equipment-Info-EUI64 ] 3793 [ User-Equipment-Info-ModifiedEUI64 ] 3794 [ User-Equipment-Info-IMEI ] 3795 [ AVP ] 3797 8.53. User-Equipment-Info-IMEISV AVP 3799 The User-Equipment-Info-IMEISV (AVP Code TBD2) is of type 3800 OctetString. The User-Equipment-Info-IMEISV AVP contains the 3801 International Mobile Equipment Identifier and Software Version in the 3802 international IMEISV format according to 3GPP TS 23.003 [TGPPIMEI]. 3804 8.54. User-Equipment-Info-MAC AVP 3806 The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. 3807 The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is 3808 formatted as described in section 4.1.7.8 of [RFC5777]. 3810 8.55. User-Equipment-Info-EUI64 AVP 3812 The User-Equipment-Info-EUI64 (AVP Code TBD4) is of type OctetString. 3813 The UUser-Equipment-Info-EUI64 AVP contains the 64-bit identifier 3814 used to identify the hardware instance of the product, as defined in 3815 [EUI64]. 3817 8.56. User-Equipment-Info-ModifiedEUI64 AVP 3819 The User-Equipment-Info-ModifiedEUI64 (AVP Code TBD5) is of type 3820 OctetString. There are a number of types of terminals that have 3821 identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These 3822 identifiers can be converted to modified EUI-64 format as described 3823 in [RFC4291] or by using some other methods referred to in the 3824 service-specific documentation. The User-Equipment-Info- 3825 ModifiedEUI64 AVP contains such identifiers. 3827 8.57. User-Equipment-Info-IMEI AVP 3829 The User-Equipment-Info-IMEI (AVP Code TBD6) is of type OctetString. 3830 The User-Equipment-Info-IMEI AVP contains the International Mobile 3831 Equipment Identifier in the international IMEI format according to 3832 3GPP TS 23.003 [TGPPIMEI]. 3834 8.58. Subscription-Id-Extension AVP 3836 The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify 3837 the end user's subscription and is of type Grouped. The 3838 Subscription-Id-Extension group AVP MUST include an AVP holding the 3839 subscription identifier. The type of this included AVP indicates the 3840 type of the subscription identifier. For each of the enumerated 3841 values of the Subscription-Id-Type AVP, there is a corresponding sub- 3842 AVP for use within the Subscription-Id-Extension group AVP. If a new 3843 identifier type is required a corresponding new sub-AVP SHOULD be 3844 defined for use within the Subscription-Id-Extension group AVP. 3846 If full backward compatibility with [RFC4006] is required, then the 3847 Subscription-Id AVP MUST be used to indicate identifier types 3848 enumerated in the Subscription-Id-Type AVP, whereas the Subscription- 3849 Id-Extension AVP MUST be used only for newly defined identifier 3850 types. If full backward compatibility with [RFC4006] is not 3851 required, then the Subscription-Id-Extension AVP MAY be used to carry 3852 out the existing identifier types. In this case, Subscription-Id- 3853 Extension AVP MAY be sent together with Subscription-Id AVP. 3855 Exactly one sub-AVP MUST be included inside the Subscription-Id- 3856 Extension AVP. 3858 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3860 Subscription-Id-Extension ::= < AVP Header: TBD7 > 3861 [ Subscription-Id-E164 ] 3862 [ Subscription-Id-IMSI ] 3863 [ Subscription-Id-SIP-URI ] 3864 [ Subscription-Id-NAI ] 3865 [ Subscription-Id-Private ] 3866 [ AVP ] 3868 8.59. Subscription-Id-E164 AVP 3870 The Subscription-Id-E164 (AVP Code TBD8) is of type UTF8String. The 3871 Subscription-Id-E164 AVP contains the international E.164 format 3872 (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined 3873 in [E164] and [CE164]. 3875 8.60. Subscription-Id-IMSI AVP 3877 The Subscription-Id-IMSI (AVP Code TBD9) is of type UTF8String. The 3878 Subscription-Id-IMSI AVP contains the international IMSI format, 3879 according to the ITU-T E.212 numbering plan as defined in [E212] and 3880 [CE212]. 3882 8.61. Subscription-Id-SIP-URI AVP 3884 The Subscription-Id-SIP-URI (AVP Code TBD10) is of type UTF8String. 3885 The Subscription-Id-SIP-URI AVP contains the identifier in the form 3886 of a SIP URI, as defined in [RFC3261]. 3888 8.62. Subscription-Id-NAI AVP 3890 The Subscription-Id-NAI (AVP Code TBD11) is of type UTF8String. The 3891 Subscription-Id-NAI AVP contains the identifier in the form of a 3892 Network Access Identifier, as defined in [RFC7542]. 3894 8.63. Subscription-Id-Private AVP 3896 The Subscription-Id-Private (AVP Code TBD12) is of type UTF8String. 3897 The Subscription-Id-Private AVP contains a credit-control server 3898 private identifier. 3900 8.64. Redirect-Server-Extension AVP 3902 The Redirect-Server-Extension AVP (AVP Code TBD13) is of type Grouped 3903 and contains the address information of the redirect server (e.g., 3904 HTTP redirect server, SIP Server) with which the end user is to be 3905 connected when the account cannot cover the service cost. It MUST be 3906 present inside the QoS-Final-Unit-Indication AVP when the Final-Unit- 3907 Action AVP is set to REDIRECT. If the type of the redirect server is 3908 one of the enumerated values of the Redirect-Address-Type AVP, then 3909 the credit-control server SHOULD send the information in the 3910 Redirect-Server AVP, in addition to or instead of the Redirect- 3911 Server-Extension AVP. This is in order to preserve backward 3912 compatibility with credit-control clients that support only 3913 [RFC4006]. Exactly one AVP MUST be included inside the Redirect- 3914 Server-Extension AVP. 3916 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3918 Redirect-Server-Extension ::= < AVP Header: TBD13 > 3919 [ Redirect-Address-IPAddress ] 3920 [ Redirect-Address-URL ] 3921 [ Redirect-Address-SIP-URI ] 3922 [ AVP ] 3924 8.65. Redirect-Address-IPAddress AVP 3926 The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type 3927 Address and defines the IPv4 or IPv6 address of the redirect server 3928 with which the end user is to be connected when the account cannot 3929 cover the service cost. 3931 When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 3932 format [RFC4291] MAY be used to indicate an IPv4 address. 3934 The interpretation of Redirect-Address-IPAddress by the Diameter 3935 Credit-control Client is a matter of local policy. 3937 8.66. Redirect-Address-URL AVP 3939 The Redirect-Address-URL AVP (AVP Code TBD15) is of type UTF8String 3940 and defines the address of the redirect server with which the end 3941 user is to be connected when the account cannot cover the service 3942 cost. The address type is in the form of Uniform Resource Locator, 3943 as defined in [RFC3986]. Note that individual URL schemes may 3944 restrict the contents of the UTF8String. 3946 8.67. Redirect-Address-SIP-URI AVP 3948 The Redirect-Address-SIP-URI AVP (AVP Code TBD16) is of type 3949 UTF8String and defines the address of the redirect server with which 3950 the end user is to be connected when the account cannot cover the 3951 service cost. The address type is in the form of SIP Uniform 3952 Resource Identifier, as defined in [RFC3261]. 3954 8.68. QoS-Final-Unit-Indication AVP 3956 The QoS-Final-Unit-Indication AVP (AVP Code TBD17) is of type Grouped 3957 and indicates that the Granted-Service-Unit AVP in the Credit- 3958 Control-Answer, or in the AA answer, contains the final units for the 3959 service. After these units have expired, the Diameter credit-control 3960 client is responsible for executing the action indicated in the 3961 Final-Unit-Action AVP (see Section 5.6). 3963 If more than one unit type is received in the Credit-Control-Answer, 3964 the unit type that first expired SHOULD cause the credit-control 3965 client to execute the specified action. 3967 In the first interrogation, the QoS-Final-Unit-Indication AVP with 3968 Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present 3969 with no Granted-Service-Unit AVP in the Credit-Control-Answer or in 3970 the AA answer. This indicates to the Diameter credit-control client 3971 to execute the specified action immediately. If the home service 3972 provider policy is to terminate the service, naturally, the server 3973 SHOULD return the appropriate transient failure (see Section 9.1) in 3974 order to implement the policy-defined action. 3976 The Final-Unit-Action AVP defines the behavior of the service element 3977 when the user's account cannot cover the cost of the service and MUST 3978 always be present if the QoS-Final-Unit-Indication AVP is included in 3979 a command. 3981 If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit- 3982 Indication group MUST NOT contain any other AVPs. 3984 If the Final-Unit-Action AVP is set to REDIRECT then the Redirect- 3985 Server-Extension AVPs MUST be present. The Filter-Rule AVP or the 3986 Filter-Id AVP MAY be present in the Credit-Control-Answer message if 3987 the user is also allowed to access other services that are not 3988 accessible through the address given in the Redirect-Server-Extension 3989 AVP or if the access to these services needs to be limited in some 3990 way (e.g., QoS). 3992 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3993 Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3995 The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can 3996 be used to define a specific condition and action combination. If 3997 used only with traffic conditions, it should define which traffic 3998 should allowed when no more service units are granted. However, if 3999 QoS or treatment information exists in the AVP, these actions should 4000 be executed, e.g., limiting the allowed traffic with certain QoS. 4001 When multiple Filter-Rule AVPs exist, precedence should be determined 4002 as defined in [RFC5777]. 4004 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 4005 used to reference an IP filter list installed in the access device by 4006 means other than the Diameter credit-control application, e.g., 4007 locally configured or configured by another entity. 4009 If the Final-Unit-Action AVP is set to TERMINATE, or set to 4010 RESTRICT_ACCESS and the action required is allow only traffic that 4011 could be classified using an IPFilterRule, or set to REDIRECT of a 4012 type which is one of the types in the Redirect-Address-Type AVP, then 4013 the credit-control server SHOULD send the information in the Final- 4014 Unit-Indication AVP, in addition to or instead of the QoS-Final-Unit- 4015 Indication AVP. This is in order to preserve backward compatibility 4016 with credit-control clients that support only [RFC4006]. 4018 The QoS-Final-Unit-Indication AVP is defined as follows (per the 4019 grouped-avp-def of [RFC6733]): 4021 QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > 4022 { Final-Unit-Action } 4023 *[ Filter-Rule ] 4024 *[ Filter-Id ] 4025 [ Redirect-Server-Extension ] 4026 *[ AVP ] 4028 9. Result Code AVP Values 4030 This section defines new Result-Code AVP [RFC6733] values that must 4031 be supported by all Diameter implementations that conform to this 4032 specification. 4034 The Credit-Control-Answer message includes the Result-Code AVP, which 4035 may indicate that an error was present in the Credit-Control-Request 4036 message. A rejected Credit-Control-Request message SHOULD cause the 4037 user's session to be terminated. 4039 9.1. Transient Failures 4041 Errors that fall within the transient failures category are used to 4042 inform a peer that the request could not be satisfied at the time it 4043 was received, but that the request MAY be able to be satisfied in the 4044 future. 4046 DIAMETER_END_USER_SERVICE_DENIED 4010 4048 The credit-control server denies the service request due to service 4049 restrictions. If the CCR contained used-service-units, they are 4050 deducted, if possible. 4052 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 4054 The credit-control server determines that the service can be granted 4055 to the end user but that no further credit-control is needed for the 4056 service (e.g., service is free of charge). 4058 DIAMETER_CREDIT_LIMIT_REACHED 4012 4060 The credit-control server denies the service request because the end 4061 user's account could not cover the requested service. If the CCR 4062 contained used-service-units they are deducted, if possible. 4064 9.2. Permanent Failures 4066 Errors that fall within the permanent failure category are used to 4067 inform the peer that the request failed and should not be attempted 4068 again. 4070 DIAMETER_USER_UNKNOWN 5030 4072 The specified end user is unknown in the credit-control server. 4074 DIAMETER_RATING_FAILED 5031 4076 This error code is used to inform the credit-control client that the 4077 credit-control server cannot rate the service request due to 4078 insufficient rating input, an incorrect AVP combination, or an AVP or 4079 an AVP value that is not recognized or supported in the rating. The 4080 Failed-AVP AVP MUST be included and contain a copy of the entire 4081 AVP(s) that could not be processed successfully or an example of the 4082 missing AVP complete with the Vendor-Id if applicable. The value 4083 field of the missing AVP should be of correct minimum length and 4084 contain zeros. 4086 10. AVP Occurrence Table 4088 The following table presents the AVPs defined in this document and 4089 specifies in which Diameter messages they MAY or MUST NOT be present. 4090 Note that AVPs that can only be present within a Grouped AVP are not 4091 represented in this table. 4093 The table uses the following symbols: 4095 0 The AVP MUST NOT be present in the message. 4096 0+ Zero or more instances of the AVP MAY be present in the 4097 message. 4098 0-1 Zero or one instance of the AVP MAY be present in the 4099 message. It is considered an error if there is more 4100 than one instance of the AVP. 4101 1 One instance of the AVP MUST be present in the message. 4102 1+ At least one instance of the AVP MUST be present in the 4103 message. 4105 10.1. Credit-Control AVP Table 4107 The table in this section is used to represent which credit-control 4108 application-specific AVPs defined in this document are to be present 4109 in the credit-control messages. 4111 +-----------+ 4112 | Command | 4113 | Code | 4114 |-----+-----+ 4115 Attribute Name | CCR | CCA | 4116 ------------------------------|-----+-----+ 4117 Acct-Multi-Session-Id | 0-1 | 0-1 | 4118 Auth-Application-Id | 1 | 1 | 4119 CC-Correlation-Id | 0-1 | 0 | 4120 CC-Session-Failover | 0 | 0-1 | 4121 CC-Request-Number | 1 | 1 | 4122 CC-Request-Type | 1 | 1 | 4123 CC-Sub-Session-Id | 0-1 | 0-1 | 4124 Check-Balance-Result | 0 | 0-1 | 4125 Cost-Information | 0 | 0-1 | 4126 Credit-Control-Failure- | 0 | 0-1 | 4127 Handling | | | 4128 Destination-Host | 0-1 | 0 | 4129 Destination-Realm | 1 | 0 | 4130 Direct-Debiting-Failure- | 0 | 0-1 | 4131 Handling | | | 4132 Event-Timestamp | 0-1 | 0-1 | 4133 Failed-AVP | 0 | 0+ | 4134 Final-Unit-Indication | 0 | 0-1 | 4135 QoS-Final-Unit-Indication | 0 | 0-1 | 4136 Granted-Service-Unit | 0 | 0-1 | 4137 Multiple-Services-Credit- | 0+ | 0+ | 4138 Control | | | 4139 Multiple-Services-Indicator | 0-1 | 0 | 4140 Origin-Host | 1 | 1 | 4141 Origin-Realm | 1 | 1 | 4142 Origin-State-Id | 0-1 | 0-1 | 4143 Proxy-Info | 0+ | 0+ | 4144 Redirect-Host | 0 | 0+ | 4145 Redirect-Host-Usage | 0 | 0-1 | 4146 Redirect-Max-Cache-Time | 0 | 0-1 | 4147 Requested-Action | 0-1 | 0 | 4148 Requested-Service-Unit | 0-1 | 0 | 4149 Route-Record | 0+ | 0+ | 4150 Result-Code | 0 | 1 | 4151 Service-Context-Id | 1 | 0 | 4152 Service-Identifier | 0-1 | 0 | 4153 Service-Parameter-Info | 0+ | 0 | 4154 Session-Id | 1 | 1 | 4155 Subscription-Id | 0+ | 0 | 4156 Subscription-Id-Extension | 0+ | 0 | 4157 Termination-Cause | 0-1 | 0 | 4158 User-Equipment-Info | 0-1 | 0 | 4159 User-Equipment-Info-Extension | 0-1 | 0 | 4160 Used-Service-Unit | 0+ | 0 | 4161 User-Name | 0-1 | 0-1 | 4162 Validity-Time | 0 | 0-1 | 4163 ------------------------------|-----+-----+ 4165 10.2. Re-Auth-Request/Answer AVP Table 4167 This section defines AVPs that are specific to the Diameter credit- 4168 control application and that MAY be included in the Diameter Re-Auth- 4169 Request/Answer (RAR/RAA) message [RFC6733]. 4171 Re-Auth-Request/Answer command MAY include the following additional 4172 AVPs: 4174 +---------------+ 4175 | Command Code | 4176 |-------+-------+ 4177 Attribute Name | RAR | RAA | 4178 ------------------------------+-------+-------+ 4179 CC-Sub-Session-Id | 0-1 | 0-1 | 4180 G-S-U-Pool-Identifier | 0-1 | 0-1 | 4181 Service-Identifier | 0-1 | 0-1 | 4182 Rating-Group | 0-1 | 0-1 | 4183 ------------------------------+-------+-------+ 4185 11. RADIUS/Diameter Credit-Control Interworking Model 4187 This section defines the basic principles for the Diameter credit- 4188 control/RADIUS prepaid inter-working model; that is, a message 4189 translation between a RADIUS based prepaid solution and a Diameter 4190 credit-control application. A complete description of the protocol 4191 translations between RADIUS and the Diameter credit-control 4192 application is beyond the scope of this specification and SHOULD be 4193 addressed in another appropriate document, such as the RADIUS prepaid 4194 specification. 4196 The Diameter credit-control architecture may have a Translation Agent 4197 capable of translation between RADIUS prepaid and Diameter credit- 4198 control protocols. An AAA server (usually the home AAA server) may 4199 act as a Translation Agent and as a Diameter credit-control client 4200 for service elements that use credit-control mechanisms other than 4201 Diameter credit-control for instance, RADIUS prepaid. In this case, 4202 the home AAA server contacts the Diameter credit-control server as 4203 part of the authorization process. The interworking architecture is 4204 illustrated Figure 9, and interworking flow in Figure 10. In a 4205 roaming situation the service element (e.g., the NAS) may be located 4206 in the visited network, and a visited AAA server is usually 4207 contacted. The visited AAA server connects then to the home AAA 4208 server. 4210 RADIUS Prepaid 4211 +--------+ +---------+ protocol +------------+ +--------+ 4212 | End |<----->| Service |<---------->| Home AAA | |Business| 4213 | User | | Element | | Server | |Support | 4214 +--------+ +-->| | |+----------+|->|System | 4215 | +---------+ ||CC Client || | | 4216 | |+----------+| | | 4217 +--------+ | +------^-----+ +----^---+ 4218 | End |<--+ Credit-Control | | 4219 | User | Protocol | | 4220 +--------+ +-------V--------+ | 4221 |Credit-Control |----+ 4222 | Server | 4223 +----------------+ 4225 Figure 9: Credit-control architecture with service element containing 4226 translation agent, translating RADIUS prepaid to Diameter credit- 4227 control protocol 4229 When the AAA server acting as a Translation Agent receives an initial 4230 RADIUS Access-Request message from service element (e.g., NAS 4231 access), it performs regular authentication and authorization. If 4232 the RADIUS Access-Request message indicates that the service element 4233 is capable of credit-control, and if the home AAA server finds that 4234 the subscriber is a prepaid subscriber, then a Diameter credit- 4235 control request SHOULD be sent toward the credit-control server to 4236 perform credit authorization and to establish a credit-control 4237 session. After the Diameter credit-control server checks the end 4238 user's account balance, rates the service, and reserves credit from 4239 the end user's account, the reserved quota is returned to the home 4240 AAA server in the Diameter Credit-Control-Answer. Then the home AAA 4241 server sends the reserved quota to the service element in the RADIUS 4242 Access-Accept. 4244 At the expiry of the allocated quota, the service element sends a new 4245 RADIUS Access-Request containing the units used this far to the home 4246 AAA server. The home AAA server shall map a RADIUS Access-Request 4247 containing the reported units to the Diameter credit-control server 4248 in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter 4249 credit-control server debits the used units from the end user's 4250 account and allocates a new quota that is returned to the home AAA 4251 server in the Diameter Credit-Control-Answer. The quota is 4252 transferred to the service element in the RADIUS Access-Accept. When 4253 the end user terminates the service, or when the entire quota has 4254 been used, the service element sends a RADIUS Access-Request. To 4255 debit the used units from the end user's account and to stop the 4256 credit-control session, the home AAA server sends a Diameter Credit- 4257 Control-Request (TERMINATION_REQUEST) to the credit-control server. 4258 The Diameter credit-control server acknowledges the session 4259 termination by sending a Diameter Credit-Control-Answer to the home 4260 AAA server. The RADIUS Access-Accept is sent to the NAS. 4262 A following diagram illustrates a RADIUS prepaid - Diameter credit- 4263 control interworking sequence. 4265 Service Element Translation Agent 4266 (e.g., NAS) (CC Client) CC Server 4267 | Access-Request | | 4268 |----------------------->| | 4269 | | CCR (initial) | 4270 | |----------------------->| 4271 | | CCA (Granted-Units) | 4272 | |<-----------------------| 4273 | Access-Accept | | 4274 | (Granted-Units) | | 4275 |<-----------------------| | 4276 : : : 4277 | Access-Request | | 4278 | (Used-Units) | | 4279 |----------------------->| | 4280 | | CCR (update, | 4281 | | Used-Units) | 4282 | |----------------------->| 4283 | | CCA (Granted-Units) | 4284 | |<-----------------------| 4285 | Access-Accept | | 4286 | (Granted-Units) | | 4287 |<-----------------------| | 4288 : : : 4289 | Access-Request | | 4290 |----------------------->| | 4291 | | CCR (terminate, | 4292 | | Used-Units) | 4293 | |----------------------->| 4294 | | CCA | 4295 | |<-----------------------| 4296 | Access-Accept | | 4297 |<-----------------------| | 4298 | | | 4300 Figure 10: Message flow example with RADIUS prepaid - Diameter 4301 credit-control interworking 4303 12. IANA Considerations 4305 This document uses several registries that were originally created in 4306 [RFC4006] or the values assigned to existing namespaces managed by 4307 IANA. IANA [SHALL update/has updated] these to reference this 4308 document. The registries and their allocation policies are below. 4310 12.1. Application Identifier 4312 This specification assigns the value 4, 'Diameter Credit Control', to 4313 the Application Identifier namespace defined in [RFC6733]. See 4314 Section 1.3 for more information. 4316 12.2. Command Codes 4318 This specification uses the value 272 from the Command code namespace 4319 defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit- 4320 Control-Answer (CCA) commands. 4322 12.3. AVP Codes 4324 See Section 8 for the assignment of the namespace in this 4325 specification. 4327 This document describes new AVP codes beyond those described in 4328 [RFC4006]. IANA is requested to allocate codes for the AVPs defined 4329 in the following Table 7. 4331 +-----------------------------------+-------+--------------------+ 4332 | Attribute Name | Code | Defined in section | 4333 +-----------------------------------+-------+--------------------+ 4334 | User-Equipment-Info-Extension | TBD1 | 8.52 | 4335 | User-Equipment-Info-IMEISV | TBD2 | 8.53 | 4336 | User-Equipment-Info-MAC | TBD3 | 8.54 | 4337 | User-Equipment-Info-EUI64 | TBD4 | 8.55 | 4338 | User-Equipment-Info-ModifiedEUI64 | TBD5 | 8.56 | 4339 | User-Equipment-Info-IMEI | TBD6 | 8.57 | 4340 | Subscription-Id-Extension | TBD7 | 8.58 | 4341 | Subscription-Id-E164 | TBD8 | 8.59 | 4342 | Subscription-Id-IMSI | TBD9 | 8.60 | 4343 | Subscription-Id-SIP-URI | TBD10 | 8.61 | 4344 | Subscription-Id-NAI | TBD11 | 8.62 | 4345 | Subscription-Id-Private | TBD12 | 8.63 | 4346 | Redirect-Server-Extension | TBD13 | 8.64 | 4347 | Redirect-Address-IPAddress | TBD14 | 8.65 | 4348 | Redirect-Address-URL | TBD15 | 8.66 | 4349 | Redirect-Address-SIP-URI | TBD16 | 8.67 | 4350 | QoS-Final-Unit-Indication | TBD17 | 8.68 | 4351 +-----------------------------------+-------+--------------------+ 4353 Table 7: Requested AVP Assignments 4355 12.4. Result-Code AVP Values 4357 This specification assigns the values 4010, 4011, 4012, 5030, 5031 4358 from the Result-Code AVP value namespace defined in [RFC6733]. See 4359 Section 9 for the assignment of the namespace in this specification. 4361 12.5. CC-Request-Type AVP 4363 As defined in Section 8.3, the CC-Request-Type AVP includes 4364 Enumerated type values 1 - 4. IANA has created and is maintaining a 4365 namespace for this AVP. The definition of new values is subject to 4366 the Specification Required policy [RFC8126] and conditions for 4367 enumerated values described in [RFC7423] Section 5.6. 4369 12.6. CC-Session-Failover AVP 4371 As defined in Section 8.4, the CC-Failover-Supported AVP includes 4372 Enumerated type values 0 - 1. IANA has created and is maintaining a 4373 namespace for this AVP. The definition of new values is subject to 4374 the Specification Required policy [RFC8126] and conditions for 4375 enumerated values described in [RFC7423] Section 5.6. 4377 12.7. CC-Unit-Type AVP 4379 As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated 4380 type values 0 - 5. IANA has created and is maintaining a namespace 4381 for this AVP. The definition of new values is subject to the 4382 Specification Required policy [RFC8126] and conditions for enumerated 4383 values described in [RFC7423] Section 5.6. 4385 12.8. Check-Balance-Result AVP 4387 As defined in Section 8.6, the Check-Balance-Result AVP includes 4388 Enumerated type values 0 - 1. IANA has created and is maintaining a 4389 namespace for this AVP. The definition of new values is subject to 4390 the Specification Required policy [RFC8126] and conditions for 4391 enumerated values described in [RFC7423] Section 5.6. 4393 12.9. Credit-Control AVP 4395 As defined in Section 8.13, the Credit-Control AVP includes 4396 Enumerated type values 0 - 1. IANA has created and is maintaining a 4397 namespace for this AVP. The definition of new values is subject to 4398 the Specification Required policy [RFC8126] and conditions for 4399 enumerated values described in [RFC7423] Section 5.6. 4401 12.10. Credit-Control-Failure-Handling AVP 4403 As defined in Section 8.14, the Credit-Control-Failure-Handling AVP 4404 includes Enumerated type values 0 - 2. IANA has created and is 4405 maintaining a namespace for this AVP. The definition of new values 4406 is subject to the Specification Required policy [RFC8126] and 4407 conditions for enumerated values described in [RFC7423] Section 5.6. 4409 12.11. Direct-Debiting-Failure-Handling AVP 4411 As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP 4412 includes Enumerated type values 0 - 1. IANA has created and is 4413 maintaining a namespace for this AVP. The definition of new values 4414 is subject to the Specification Required policy [RFC8126] and 4415 conditions for enumerated values described in [RFC7423] Section 5.6. 4417 12.12. Final-Unit-Action AVP 4419 As defined in Section 8.35, the Final-Unit-Action AVP includes 4420 Enumerated type values 0 - 2. IANA has created and is maintaining a 4421 namespace for this AVP. The definition of new values is subject to 4422 the Specification Required policy [RFC8126] and conditions for 4423 enumerated values described in [RFC7423] Section 5.6. 4425 12.13. Multiple-Services-Indicator AVP 4427 As defined in Section 8.40, the Multiple-Services-Indicator AVP 4428 includes Enumerated type values 0 - 1. IANA has created and is 4429 maintaining a namespace for this AVP. The definition of new values 4430 is subject to the Specification Required policy [RFC8126] and 4431 conditions for enumerated values described in [RFC7423] Section 5.6. 4433 12.14. Redirect-Address-Type AVP 4435 As defined in Section 8.38, the Redirect-Address-Type AVP includes 4436 Enumerated type values 0 - 3. IANA has created and is maintaining a 4437 namespace for this AVP. The definition of new values is subject to 4438 the Specification Required policy [RFC8126] and conditions for 4439 enumerated values described in [RFC7423] Section 5.6. 4441 12.15. Requested-Action AVP 4443 As defined in Section 8.41, the Requested-Action AVP includes 4444 Enumerated type values 0 - 3. IANA has created and is maintaining a 4445 namespace for this AVP. The definition of new values is subject to 4446 the Specification Required policy [RFC8126] and conditions for 4447 enumerated values described in [RFC7423] Section 5.6. 4449 12.16. Subscription-Id-Type AVP 4451 As defined in Section 8.47, the Subscription-Id-Type AVP includes 4452 Enumerated type values 0 - 4. IANA has created and is maintaining a 4453 namespace for this AVP. The definition of new values is subject to 4454 the Specification Required policy [RFC8126] and conditions for 4455 enumerated values described in [RFC7423] Section 5.6. 4457 12.17. Tariff-Change-Usage AVP 4459 As defined in Section 8.27, the Tariff-Change-Usage AVP includes 4460 Enumerated type values 0 - 2. IANA has created and is maintaining a 4461 namespace for this AVP. The definition of new values is subject to 4462 the Specification Required policy [RFC8126] and conditions for 4463 enumerated values described in [RFC7423] Section 5.6. 4465 12.18. User-Equipment-Info-Type AVP 4467 As defined in Section 8.50, the User-Equipment-Info-Type AVP includes 4468 Enumerated type values 0 - 3. IANA has created and is maintaining a 4469 namespace for this AVP. The definition of new values is subject to 4470 the Specification Required policy [RFC8126] and conditions for 4471 enumerated values described in [RFC7423] Section 5.6. 4473 13. Credit-Control Application Related Parameters 4475 Tx timer 4477 When real-time credit-control is required, the credit-control client 4478 contacts the credit-control server before and while the service is 4479 provided to an end user. Due to the real-time nature of the 4480 application, the communication delays SHOULD be minimized; e.g., to 4481 avoid an overly long service setup time experienced by the end user. 4482 The Tx timer is introduced to control the waiting time in the client 4483 in the Pending state. When the Tx timer elapses, the credit-control 4484 client takes an action to the end user according to the value of the 4485 Credit-Control-Failure-Handling AVP 4487 or Direct-Debiting-Failure-Handling AVP. The recommended value is 10 4488 seconds. 4490 Tcc timer 4492 The Tcc timer supervises an ongoing credit-control session in the 4493 credit-control server. It is RECOMMENDED to use the Validity-Time as 4494 input to set the Tcc timer value. In case of transient failures in 4495 the network, the Diameter credit-control server might change to Idle 4496 state. To avoid this, the Tcc timer MAY be set so that Tcc equals to 4497 2 x Validity-Time. 4499 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 4501 Client implementations may offer the possibility of locally 4502 configuring these AVPs. In such a case their value and behavior is 4503 defined in Section 5.7 for the Credit-Control-Failure-Handling and in 4504 Section 6.5 for the Direct-Debiting-Failure-Handling. 4506 14. Security Considerations 4508 Security considerations regarding the Diameter protocol itself are 4509 discussed in [RFC6733]. Use of this application of Diameter MUST 4510 take into consideration the security issues and requirements of the 4511 base protocol. 4513 This application includes a mechanism for application layer replay 4514 protection by means of the Session-Id from [RFC6733] and CC-Request- 4515 Number, which is specified in this document. The Diameter credit- 4516 control application is often used within one domain, and there may be 4517 a single hop between the peers. In these environments, the use of 4518 TLS/TCP, DTLS/SCTP or IPsec is sufficient. The details of TLS/TCP, 4519 DTLS/SCTP or IPsec related security considerations are discussed in 4520 the [RFC6733]. 4522 Because this application handles monetary transactions (directly or 4523 indirectly), it increases the interest for various security attacks. 4524 Therefore, all parties communicating with each other MUST be 4525 authenticated, including, for instance, TLS client-side 4526 authentication. In addition, authorization of the client SHOULD be 4527 emphasized; i.e., that the client is allowed to perform credit- 4528 control for a certain user. The specific means of authorization are 4529 outside of the scope of this specification but can be, for instance, 4530 manual configuration. 4532 Another kind of threat is malicious modification, injection, or 4533 deletion of AVPs or complete credit-control messages. The credit- 4534 control messages contain sensitive billing related information (such 4535 as subscription Id, granted units, used units, cost information) 4536 whose malicious modification can have financial consequences. 4537 Sometimes simply delaying the credit-control messages can cause 4538 disturbances in the credit-control client or server. 4540 Even without any modification to the messages, an adversary that can 4541 eavesdrop on transactions can obtain privacy-sensitive information. 4542 Also, by monitoring the credit-control messages one can collect 4543 information about the credit-control server's billing models and 4544 business relationships. 4546 When third-party relays or proxy are involved, the hop-by-hop 4547 security does not necessarily provide sufficient protection for 4548 Diameter user session. In some cases, it may be inappropriate to 4549 send Diameter messages, such as CCR and CCA, containing sensitive 4550 AVPs via untrusted Diameter proxy agents, as there are no assurances 4551 that third-party proxies will not modify the credit-control commands 4552 or AVP values. 4554 14.1. Direct Connection with Redirects 4556 A Diameter credit-control agent cannot always know whether agents 4557 between it and the end user's Diameter credit-control server are 4558 reliable. In this case, the Diameter credit-control agent doesn't 4559 have a routing entry in its Diameter Routing Table (defined in 4560 [RFC6733], section 2.7) for the realm of the credit-control server in 4561 the end user's home realm. The Diameter credit-control agent can 4562 have a default route configured to a local Redirect agent, and it 4563 redirects the CCR message to the redirect agent. The local Redirect 4564 agent then returns a redirect notification (Result-code 3006, 4565 DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as 4566 Diameter credit-control server(s) information (Redirect-Host AVP) and 4567 information (Redirect-Host-Usage AVP) about how the routing entry 4568 resulting from the Redirect-Host is to be used. The Diameter credit- 4569 control agent then forwards the CCR message directly to one of the 4570 hosts identified by the CCA message from the redirect agent. If the 4571 value of the Redirect-Host-Usage AVP is unequal to zero, all 4572 following messages are sent to the host specified in the Redirect- 4573 Host AVP until the time specified by the Redirect-Max-Cache-Time AVP 4574 is expired. 4576 There are some authorization issues even with redirects. There may 4577 be attacks toward nodes that have been properly authorized, but that 4578 abuse their authorization or have been compromised. These issues are 4579 discussed more widely in [RFC4072], Section 8. 4581 14.2. Application Level Redirects 4583 This document includes a redirection facility in Section 5.6.2, 4584 whereby the service provider can redirect (in an application-specific 4585 way) the end user to an alternate location when their credits have 4586 expired. This is useful in that it allows for the user to return to 4587 normal service quickly, but also exposes additional risks and attack 4588 surface. In particular, this redirection can potentially occur at an 4589 arbitrary point in a user's session, potentially without any 4590 additional contextual confirmation available to the user that the 4591 redirection is driven by the network. This lack of confirmation 4592 matters, because, in many application protocols, the communication 4593 peer is also capable of inducing redirection. When the peer is an 4594 attacker, the redirection can be to an attacker-controlled site. In 4595 particular, such sites may be "phishing" sites designed to appear 4596 similar to legitimate payment sites in an attempt to obtain users' 4597 payment information for fraudulent uses. When users become used to 4598 such redirection, they may have difficulty distinguishing such 4599 attacks from legitimate redirections. 4601 Because of the potentially harmful consequences of arbitrary 4602 redirection by an attacker (such as to phishing sites), it is 4603 important for service providers to be aware of that risk and assure 4604 their users are aware of it as well. Service providers should follow 4605 industry best practices for the specific application layer protocol 4606 to reduce the chances that such attacks could be mistaken for 4607 legitimate redirection. The details of such practice are out of 4608 scope for this document. 4610 15. Privacy Considerations 4612 As the Diameter protocol, and especially credit-control application, 4613 deals with subscribers and their actions, extra care should be taken 4614 regarding the privacy of the subscribers. In terms of [RFC6973], 4615 both the credit-control client and credit-control server are 4616 intermediary entities, wherein the subscribers' privacy may be 4617 compromised even if no security issues exist, and only authorized 4618 entities have access to the privacy-sensitive information. 4620 15.1. Privacy Sensitive AVPs 4622 The privacy-sensitive AVPs listed in this section MUST NOT be sent 4623 across non-trusted networks or Diameter agents without end-to-end 4624 authentication and confidentiality protection, as described in 4625 [RFC6733] section 13.3. 4627 The following AVPs contain privacy-sensitive information at different 4628 levels: 4630 1. CC-Correlation-Id AVP: may contain privacy-sensitive information 4631 as the service-provider may encode personal information that 4632 helps it correlate different subscriptions and access 4633 technologies. 4635 2. Check-Balance-Result AVP: contains information on the balance 4636 status of the subscriber. 4638 3. Currency-Code AVP: contains information on the subscriber's 4639 locale. 4641 4. Cost-Unit AVP: contains privacy-sensitive information, as a 4642 human readable format of the Cost-Information AVP. 4644 5. Service-Identifier AVP: may contain privacy-sensitive 4645 information about the subscriber's internet activity. 4647 6. Rating-Group AVP: may contain privacy-sensitive information 4648 about the subscriber's internet activity. 4650 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule 4651 may be used to infer services used by the subscriber. 4653 8. Redirect-Server-Address AVP: the service-provider might embed 4654 personal information on the subscriber in the URL/I (e.g. to 4655 create a personalized message). However, the service-provider 4656 may anonymise the subscriber's identity instead in the URL/I, 4657 and let the redirect server query the information directly. 4658 Such anonymized information must not allow personal information 4659 or the subscriber's identity to be easily guessed. Furthermore, 4660 the service-provider should treat the URL/I schema itself as 4661 confidential, and make sure it cannot be inferred from 4662 observation of the traffic, or due to its trivial structure. A 4663 trivial structure could allow an adversary to query/modify 4664 personal information even without knowing the subscriber's 4665 identity. Similar AVPs are: Redirect-Address-URL, Redirect- 4666 Address-SIP-URI. 4668 9. Service-Context-Id AVP: depending with how the service-provider 4669 uses it, it may contain privacy-sensitive information about the 4670 service (e.g. in a 3GPP network Service-Context-Id AVP has a 4671 different value for: Packet Switching, SMS and MMS etc.) 4673 10. Service-Parameter-Info AVP: depending with how the service- 4674 provider uses it, it may contain privacy-sensitive information 4675 about the subscriber (e.g. location). 4677 11. Subscription-Id-Data AVP: contains the identity of the 4678 subscriber. Similar AVPs are: Subscription-Id-E164, 4679 Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id- 4680 NAI, Subscription-Id-Private. 4682 12. User-Equipment-Info-Value AVP: contains the identity of the 4683 device of the subscriber. Similar AVPs are: User-Equipment- 4684 Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, 4685 User-Equipment-Info-ModifiedEUI64, User-Equipment-Info-IMEI. 4687 13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains 4688 privacy-sensitive information in its sub-AVPs (e.g IPFilterRule, 4689 redirect address). 4691 Note that some AVPs which are used in this document are defined in 4692 [RFC6733] and may contain privacy-sensitive information. These AVPs 4693 are not listed above. 4695 15.2. Data Minimization 4697 Due to the nature of the credit-control application, some personal 4698 data and identity information must be stored in both credit-control 4699 client and credit-control server. This, however, could be minimized 4700 by following these guidelines: 4702 1. Data stored in the credit-control client does not need to be 4703 persisted across sessions. All data could be deleted once the 4704 session end, and reconstructed once a new session is initialized. 4705 Note that, while the credit-control server is usually owned by 4706 the service provider with which the subscriber already has some 4707 direct legal or business relationship (where privacy level could 4708 be agreed upon), this is not always true for the credit-control 4709 client, that may be owned by a third-party. 4711 2. Some information about the subscriber has to be stored in 4712 persistent storage in the credit-control server (e.g. identity, 4713 balance), however, per transaction information does not have to 4714 be stored in persistent storage, and per session information may 4715 be deleted from persistent storage once the session ends. 4717 3. In some cases, per transaction information has to be stored on 4718 the credit-control server, client, or both, for regulatory, 4719 auditability or debugging reasons. However, this could be 4720 minimized by following these guidelines: 4722 A. Data retention does not need to exceed the required duration. 4724 B. Transaction information could be aggregated in some cases. 4725 E.g. prefer information per sessions over information per 4726 rating-group; prefer hourly byte summary over per transaction 4727 byte counts. 4729 C. If not strictly needed, the more sensitive information (E.g. 4730 location, equipment type) could be filtered out of such logs. 4731 This information is often used to make rating decisions, and 4732 in this case, the rating decision should be logged instead of 4733 the data used to make them. 4735 D. Due to the reasons explained in 1, the credit-control server 4736 would be a preferred location for storing such transaction 4737 information, instead of the credit-control client 4739 15.3. Diameter Agents 4741 Diameter agents, as described in [RFC6733], may be owned by third- 4742 parties. If end-to-end security is supported between credit-control 4743 client and credit-control server, the operator can use it to encrypt 4744 privacy-sensitive AVPs (as listed in Section 15.1), and prevent such 4745 information from leaking into the agent. 4747 In some cases, the Diameter agent needs access into privacy-sensitive 4748 AVPs, in order to take correct routing decisions, or even modify the 4749 content of these AVPs. For example, a proxy agent may need to look 4750 into the Subscription-Id-IMSI AVP, in order to extract the mobile 4751 country and network codes of the user, and use them to lookup the 4752 destination to which the request should be routed (see: section 2.8.2 4753 in [RFC6733]). In such a case, the credit-control client and credit- 4754 control server may use a mechanism that anonymizes the identity of 4755 the subscriber, as well as a mechanism to encrypt other AVPs not used 4756 by the agent. 4758 16. References 4760 16.1. Normative References 4762 [CE164] "Complement to ITU-T Recommendation E.164 (05/1997):"List 4763 of ITU-T Recommendation E.164 assigned country codes"", 4764 June 2000. 4766 [CE212] "Complement to ITU-T Recommendation E.212 (11/1997):" List 4767 of mobile country or geographical area codes"", February 4768 1999. 4770 [E164] "Recommendation E.164/I.331 (05/97): The International 4771 Public Telecommunication Numbering Plan.", 1997. 4773 [E212] "Recommendation E.212 (11/98): The international 4774 identification plan for mobile terminals and mobile 4775 users.", 1998. 4777 [EUI64] IEEE, ""Guidelines for 64-bit Global Identifier (EUI-64) 4778 Registration Authority"", March 1997, 4779 . 4782 [ISO4217] "Codes for the representation of currencies and funds, 4783 International Standard ISO 4217", 2001. 4785 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4786 DOI 10.17487/RFC0791, September 1981, 4787 . 4789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4790 Requirement Levels", BCP 14, RFC 2119, 4791 DOI 10.17487/RFC2119, March 1997, 4792 . 4794 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4795 A., Peterson, J., Sparks, R., Handley, M., and E. 4796 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4797 DOI 10.17487/RFC3261, June 2002, 4798 . 4800 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 4801 Accounting (AAA) Transport Profile", RFC 3539, 4802 DOI 10.17487/RFC3539, June 2003, 4803 . 4805 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4806 Resource Identifier (URI): Generic Syntax", STD 66, 4807 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4808 . 4810 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 4811 Loughney, "Diameter Credit-Control Application", RFC 4006, 4812 DOI 10.17487/RFC4006, August 2005, 4813 . 4815 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4816 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4817 2006, . 4819 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 4820 Ed., and A. Lior, "Traffic Classification and Quality of 4821 Service (QoS) Attributes for Diameter", RFC 5777, 4822 DOI 10.17487/RFC5777, February 2010, 4823 . 4825 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 4826 Address Text Representation", RFC 5952, 4827 DOI 10.17487/RFC5952, August 2010, 4828 . 4830 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 4831 Ed., "Diameter Base Protocol", RFC 6733, 4832 DOI 10.17487/RFC6733, October 2012, 4833 . 4835 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 4836 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 4837 . 4839 [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter 4840 Applications Design Guidelines", BCP 193, RFC 7423, 4841 DOI 10.17487/RFC7423, November 2014, 4842 . 4844 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 4845 DOI 10.17487/RFC7542, May 2015, 4846 . 4848 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4849 Writing an IANA Considerations Section in RFCs", BCP 26, 4850 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4851 . 4853 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4854 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4855 May 2017, . 4857 [TGPPIMEI] 4858 3rd Generation Partnership Project, "Technical 4859 Specification Group Core Network, Numbering, addressing 4860 and identification, (release 13), 3GPP TS 23.003 v. 4861 13.5.0", 2016-04. 4863 16.2. Informative References 4865 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 4866 DOI 10.17487/RFC2866, June 2000, 4867 . 4869 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 4870 "IEEE 802.1X Remote Authentication Dial In User Service 4871 (RADIUS) Usage Guidelines", RFC 3580, 4872 DOI 10.17487/RFC3580, September 2003, 4873 . 4875 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 4876 Camarillo, "Best Current Practices for Third Party Call 4877 Control (3pcc) in the Session Initiation Protocol (SIP)", 4878 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 4879 . 4881 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., 4882 and P. McCann, "Diameter Mobile IPv4 Application", 4883 RFC 4004, DOI 10.17487/RFC4004, August 2005, 4884 . 4886 [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter 4887 Extensible Authentication Protocol (EAP) Application", 4888 RFC 4072, DOI 10.17487/RFC4072, August 2005, 4889 . 4891 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 4892 Morris, J., Hansen, M., and R. Smith, "Privacy 4893 Considerations for Internet Protocols", RFC 6973, 4894 DOI 10.17487/RFC6973, July 2013, 4895 . 4897 [TGPPCHARG] 4898 3rd Generation Partnership Project, "Technical 4899 Specification Group Services and System Aspects, Service 4900 aspects; Charging and Billing, (release 13), 3GPP TS 4901 22.115 v. 13.3.0", 2016-03. 4903 Appendix A. Acknowledgements 4905 The original authors of RFC4006 are: Harri Hakala, Leena Mattila, 4906 Juha-Pekka Koskinen, Marco Stura, and John Loughney. 4908 The authors would like to thank Bernard Aboba, Jari Arkko, Robert 4909 Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, 4910 Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, 4911 Christopher Richards, Juha Vallinen, and Mark Watson for their 4912 comments and suggestions. 4914 Appendix B. Credit-Control Sequences 4916 B.1. Flow I 4917 NAS 4918 End User (CC Client) AAA Server CC Server 4919 |(1)User Logon |(2)AA Request (CC AVPs) | 4920 |------------------>|------------------->| | 4921 | | |(3)CCR(initial, CC AVPs) 4922 | | |------------------->| 4923 | | | (4)CCA(Granted-Units) 4924 | | |<-------------------| 4925 | |(5)AA Answer(Granted-Units) | 4926 |(6)Access granted |<-------------------| | 4927 |<----------------->| | | 4928 | | | | 4929 : : : : 4930 | |(7)CCR(update,Used-Units) | 4931 | |------------------->|(8)CCR | 4932 | | | (update,Used-Units) 4933 | | |------------------->| 4934 | | |(9)CCA(Granted-Units) 4935 | |(10)CCA(Granted-Units)<------------------| 4936 | |<-------------------| | 4937 : : : : 4938 | (Auth. lifetime expires) | | 4939 | |(11) AAR (CC AVP) | | 4940 | |------------------->| | 4941 | | (12) AAA | | 4942 | |<-------------------| | 4943 : : : : 4944 : : : : 4945 |(13) User logoff | | | 4946 |------------------>|(14)CCR(term.,Used-Units) | 4947 | |------------------->|(15)CCR | 4948 | | | (term.,Used-Units) 4949 | | |------------------->| 4950 | | | (16)CCA | 4951 | | (17)CCA |<-------------------| 4952 | |<-------------------| | 4953 | |(18)STR | | 4954 | |------------------->| | 4955 | | (19)STA | | 4956 | |<-------------------| | 4958 Figure 11: Flow I 4960 A credit-control flow for Network Access Services prepaid is shown in 4961 Figure 11. The Diameter [RFC7155] is implemented in the Network 4962 Access Server (NAS). The focus of this flow is in the credit 4963 authorization. 4965 The user logs on to the network (1). The Diameter NAS sends a 4966 Diameter AA-Request (AAR) to the home Diameter AAA server. The 4967 credit-control client populates the AAR with the Credit-Control AVP 4968 set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, 4969 as usual [RFC7155]. The home Diameter AAA server performs service- 4970 specific Authentication and Authorization, as usual. The home 4971 Diameter AAA server determines that the user is a prepaid user and 4972 notices from the Credit-Control AVP that the NAS has credit-control 4973 capabilities. It sends a Diameter Credit-Control-Request with CC- 4974 Request-Type set to INITIAL_REQUEST to the Diameter credit-control 4975 server to perform credit authorization (3) and to establish a credit- 4976 control session. (The home Diameter AAA server may forward service- 4977 specific AVPs received from the NAS as input for the rating process.) 4978 The Diameter credit-control server checks the end user's account 4979 balance, rates the service, and reserves credit from the end user's 4980 account. The reserved quota is returned to the home Diameter AAA 4981 server in the Diameter Credit-Control-Answer (4). The home Diameter 4982 AAA server sends the reserved quota to the NAS in the Diameter AA- 4983 Answer (AAA). Upon successful AAA, the NAS starts the credit-control 4984 session and starts monitoring the granted units (5). The NAS grants 4985 access to the end user (6). At the expiry of the allocated quota, 4986 the NAS sends a Diameter Credit-Control-Request with CC-Request-Type 4987 set to UPDATE_REQUEST to the Home Diameter AAA server (7). This 4988 message contains the units used thus far. The home Diameter AAA 4989 server forwards the CCR to the Diameter credit-control server (8). 4990 The Diameter credit-control server debits the used units from the end 4991 user's account and allocates a new quota that is returned to the home 4992 Diameter AAA server in the Diameter Credit-Control-Answer (9). The 4993 message is forwarded to the NAS (10). During the ongoing credit- 4994 control session, the authorization lifetime expires, and the 4995 authorization/authentication client in the NAS performs service- 4996 specific re-authorization to the home Diameter AAA server, as usual. 4997 The credit-control client populates the AAR with the Credit-Control 4998 AVP set to RE_AUTHORIZATION, indicating that the credit-control 4999 server shall not be contacted, as the credit authorization is 5000 controlled by the burning rate of the granted units (11). The home 5001 Diameter AAA server performs service-specific re-authorization as 5002 usual and returns the AA-Answer to the NAS (12). The end user logs 5003 off from the network (13). To debit the used units from the end 5004 user's account and to stop the credit-control session, the NAS sends 5005 a Diameter Credit-Control-Request with CC-Request-Type set to 5006 TERMINATION_REQUEST to the home Diameter AAA server (14). The home 5007 Diameter AAA server forwards the CCR to the credit-control server 5008 (15). The Diameter credit-control server acknowledges the session 5009 termination by sending a Diameter Credit-Control-Answer to the home 5010 Diameter AAA server (16). The home Diameter AAA server forwards the 5011 answer to the NAS (17). STR/STA takes place between the NAS and home 5012 Diameter AAA server, as usual (18-19). 5014 B.2. Flow II 5016 SIP Proxy/Registrar AAA 5017 A (CC Client) Server B CC Server 5018 |(i) REGISTER | | | | 5019 |------------->|(ii) | | | 5020 | |------------->| | | 5021 | |authentication & | | 5022 | |authorization | | | 5023 | |<-------------| | | 5024 |(iii)200 OK | | | 5025 |<-------------| | | 5026 : : : : 5027 |(1) INVITE | : 5028 |------------->| 5029 | |(2) CCR (Initial, SIP-specific AVP) | 5030 | |------------------------------------------->| 5031 | |(3) CCA (Granted-Units) | 5032 | |<-------------------------------------------| 5033 | |(4) INVITE | | 5034 | |---------------------------->| | 5035 : : : : 5036 | |(5) CCR (update, Used-Units) | 5037 | |------------------------------------------->| 5038 | |(6) CCA (Granted-Units) | 5039 | |<-------------------------------------------| 5040 : : : : 5041 |(7) BYE | | | 5042 |------------->| | | 5043 | |(8) BYE | | 5044 | |---------------------------->| | 5045 | |(9) CCR (termination, Used-Units) | 5046 | |------------------------------------------->| 5047 | |(10) CCA () | 5048 | |<-------------------------------------------| 5049 | | | | 5051 Figure 12: Flow II 5053 This is an example of Diameter credit-control for SIP sessions. 5054 Although the flow focuses on illustrating the usage of credit-control 5055 messages, the SIP signaling is inaccurate, and the diagram is not by 5056 any means an attempt to define a service provider's SIP network. 5057 However, for the sake of this example, some assumptions are made 5058 below. 5060 Typically, prepaid services based, for example, on time usage for SIP 5061 session require an entity in the service provider network to 5062 intercept all the requests within the SIP dialog in order to detect 5063 events, such as session establishment and session release, that are 5064 essential to perform credit-control operations with the credit- 5065 control server. Therefore, in this example, it is assumed that the 5066 SIP Proxy adds a Record-Route header in the initial SIP INVITE to 5067 make sure that all the future requests in the created dialog traverse 5068 through it (for the definitions of 'Record-Route' and 'dialog' please 5069 refer to [RFC3261]). Finally, the degree of credit-control measuring 5070 of the media by the proxy depends on the business model design used 5071 in setting up the end system and proxies in the SIP network. 5073 The end user (SIP User Agent A) sends REGISTER with credentials (i). 5074 The SIP Proxy sends a request to the home AAA server to perform 5075 Multimedia authentication and authorization by using, for instance, 5076 Diameter Multimedia application (ii). The home AAA server checks 5077 that the credentials are correct and checks the user profile. 5078 Eventually, 200 OK response (iii) is sent to the UA. Note that the 5079 Authentication and Authorization is valid for the registration 5080 validity period duration (i.e., until re-registration is performed). 5081 Several SIP sessions may be established without re-authorization. 5083 UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- 5084 Control-Request (INITIAL_REQUEST) to the Diameter credit-control 5085 server (2). The Credit-Control-Request contains information obtained 5086 from the SIP signaling describing the requested service (e.g., 5087 calling party, called party, Session Description Protocol 5088 attributes). The Diameter credit-control server checks the end 5089 user's account balance, rates the service, and reserves credit from 5090 the end user's account. The reserved quota is returned to the SIP 5091 Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy 5092 forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. 5093 The media flows between them, and the SIP Proxy starts measuring the 5094 quota. At the expiry of the allocated quota, the SIP Proxy sends a 5095 Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 5096 credit-control server (5). This message contains the units used thus 5097 far. The Diameter credit-control server debits the used units from 5098 the end user's account and allocates new credit that is returned to 5099 the SIP Proxy in the Diameter Credit-Control-Answer (6). The end 5100 user terminates the service by sending a BYE (7). The SIP Proxy 5101 forwards the BYE message to UA B (8) and sends a Diameter Credit- 5102 Control-Request (TERMINATION_REQUEST) to the credit-control server 5103 (9). The Diameter credit-control server acknowledges the session 5104 termination by sending a Diameter Credit-Control-Answer to the SIP 5105 Proxy (10). 5107 B.3. Flow III 5109 MMS Server 5110 A (CC Client) B CC Server 5111 |(1) Send MMS | | | 5112 |--------------->| | | 5113 | |(2) CCR (event, DIRECT_DEBITING,| 5114 | | MMS-specific AVP) | 5115 | |-------------------------------->| 5116 | |(3) CCA (Granted-Units) | 5117 | |<--------------------------------| 5118 |(4) Send MMS Ack| | | 5119 |<---------------| | | 5120 | |(5) Notify MMS | | 5121 | |--------------->| | 5122 : : : : 5123 | |(6) Retrieve MMS| | 5124 | |<---------------| | 5125 | |(7) Retrieve MMS| | 5126 | | Ack | | 5127 | |--------------->| | 5128 | | | | 5130 Figure 13: Flow III 5132 This is an example of Diameter credit-control for direct debiting 5133 using the Multimedia Messaging Service environment. Although the 5134 flow focuses on illustrating the usage of credit-control messages, 5135 the MMS signaling is inaccurate, and the diagram is not by any means 5136 an attempt to define any service provider's MMS configuration or 5137 billing model. 5139 A credit-control flow for Multimedia Messaging Services is shown in 5140 Figure 13. The sender is charged as soon as the messaging server 5141 successfully stores the message. 5143 The end user A sends a Multimedia Message (MMS) to the MMS server 5144 (1). The MMS server stores the message and sends a Diameter Credit- 5145 Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) 5146 to the Diameter credit-control server (2). The Credit-Control- 5147 Request contains information about the MMS message (e.g., size, 5148 recipient address, image coding type). The Diameter credit-control 5149 server checks the end user's account balance, rates the service, and 5150 debits the service from the end user's account. The granted quota is 5151 returned to the MMS server in the Diameter Credit-Control-Answer (3). 5152 The MMS server acknowledges the successful reception of the MMS 5153 message (4). The MMS Server notifies the recipient about the new MMS 5154 (5), and end user B retrieves the message from the MMS message store 5155 (6),(7). 5157 Note that the transfer of the MMS message can take an extended time 5158 and can fail, in which case a recovery action is needed. The MMS 5159 server should return the already debited units to the user's account 5160 by using the REFUND action described in Section 6.4. 5162 B.4. Flow IV 5164 MMS Server 5165 Content Server (CC Client) B CC Server 5166 |(1) Send MMS | | | 5167 |--------------->| | | 5168 | |(2) CCR (event, CHECK_BALANCE, | 5169 | | MMS-specific AVP) | 5170 | |-------------------------------->| 5171 | |(3) CCA (ENOUGH_CREDIT) | 5172 | |<--------------------------------| 5173 |(4) Send MMS Ack| | | 5174 |<---------------| | | 5175 | |(5) Notify MMS | | 5176 | |--------------->| | 5177 : : : : 5178 | |(6) Retrieve MMS| | 5179 | |<---------------| | 5180 | |(7) CCR (event, DIRECT_DEBITING,| 5181 | | MMS-specific AVP) | 5182 | |-------------------------------->| 5183 | |(8) CCA (Granted-Units) | 5184 | |<--------------------------------| 5185 | |(9) Retrieve MMS| | 5186 | | Ack | | 5187 | |--------------->| | 5188 | | | | 5190 Figure 14: Flow IV 5192 This is an example of Diameter credit-control for direct debiting 5193 using the Multimedia Messaging Service environment. Although the 5194 flow focuses on illustrating the usage of credit-control messages, 5195 the MMS signaling is inaccurate, and the diagram is not by any means 5196 an attempt to define any service provider's MMS configuration or 5197 billing model. 5199 A credit-control flow for Multimedia Messaging Service is shown in 5200 Figure 14. The recipient is charged at the message delivery. 5202 A content server sends a Multimedia Message (MMS) to the MMS server 5203 (1) that stores the message. The message recipient will be charged 5204 for the MMS message in this case. As there can be a substantially 5205 long time between the receipt of the message at the MMS server and 5206 the actual retrieval of the message, the MMS server does not 5207 establish any credit-control session to the Diameter credit-control 5208 server but performs first only a balance check (without any credit 5209 reservation) by sending a Diameter Credit-Control-Request 5210 (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that 5211 end user B can cover the cost for the MMS (2). The Diameter credit- 5212 control server checks the end user's account balance and returns the 5213 answer to the MMS server in the Diameter Credit-Control-Answer (3). 5214 The MMS server acknowledges the successful reception of the MMS 5215 message (4). The MMS server notifies the recipient of the new MMS 5216 (5), and after some time end user B retrieves the message from the 5217 MMS message store (6). The MMS server sends a Diameter Credit- 5218 Control-Request (EVENT_REQUEST with Requested-Action: 5219 DIRECT_DEBITING) to the Diameter credit-control server (7). The 5220 Credit-Control-Request contains information about the MMS message 5221 (e.g., size, recipient address, coding type). The Diameter credit- 5222 control server checks the end user's account balance, rates the 5223 service, and debits the service from the end user's account. The 5224 granted quota is returned to the MMS server in the Diameter Credit- 5225 Control-Request (8). The MMS is transferred to end user B (9). 5227 Note that the transfer of the MMS message can take an extended time 5228 and can fail, in which case a recovery action is needed. The MMS 5229 server should return the already debited units to the user's account 5230 by using the REFUND action described in Section 6.4. 5232 B.5. Flow V 5233 SIP Controller 5234 A (CC Client) B CC Server 5235 |(1)INVITE B(SDP)| | | 5236 |--------------->| | | 5237 | |(2) CCR (event, PRICE_ENQUIRY, | 5238 | | SIP-specific AVPs) | 5239 | |-------------------------------->| 5240 | |(3) CCA (Cost-Information) | 5241 | |<--------------------------------| 5242 | (4)MESSAGE(URL)| | | 5243 |<---------------| | | 5244 |(5)HTTP GET | | | 5245 |--------------->| | | 5246 |(6)HTTP POST | | | 5247 |--------------->|(7)INVITE(SDP) | | 5248 | |--------------->| | 5249 | | (8)200 OK | | 5250 | (9)200 OK |<---------------| | 5251 |<---------------| | | 5253 Figure 15: Flow V 5255 This is an example of Diameter credit-control for SIP sessions. 5256 Although the flow focuses on illustrating the usage of credit-control 5257 messages, the SIP signaling is inaccurate, and the diagram is not by 5258 any means an attempt to define a service provider's SIP network. 5260 Figure 15 is an example of Advice of Charge (AoC) service for SIP 5261 call. User A can be either a postpaid or prepaid subscriber using 5262 the AoC service. It is assumed that the SIP controller also has HTTP 5263 capabilities and delivers an interactive AoC web page with, for 5264 instance, the cost information, the details of the call derived from 5265 the SDP, and a button to accept/not accept the charges. (There may 5266 be many other ways to deliver AoC information; however, this flow 5267 focuses on the use of the credit-control messages.) The user has 5268 been authenticated and authorized prior to initiating the call and 5269 subscribed to AoC service. 5271 UA A sends an INVITE with SDP to B (1). The SIP controller 5272 determines that the user is subscribed to AoC service and sends a 5273 Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: 5274 PRICE_ENQUIRY) to the Diameter credit-control server (2). The 5275 Credit-Control-Request contains SIP-specific AVPs derived from the 5276 SIP signaling, describing the requested service (e.g., calling party, 5277 called party, Session Description Protocol attributes). The Diameter 5278 credit-control server determines the cost of the service and returns 5279 the Credit-Control-Answer including the Cost-Information AVP (3). 5280 The SIP controller manufactures the AoC web page with information 5281 received in SIP signaling and with the cost information received from 5282 the credit-control server. Then it sends a SIP MESSAGE that contains 5283 a URL pointing to the AoC information web page (4). At the receipt 5284 of the SIP MESSAGE, A's UA automatically invokes the web browser that 5285 retrieves the AoC information (5). The user clicks on a proper 5286 button and accepts the charges (6). The SIP controller continues the 5287 session and sends the INVITE to the B party, which accepts the call 5288 (7,8,9). 5290 B.6. Flow VI 5292 Gaming Server 5293 End User (CC Client) CC Server 5294 | (1)Service Delivery | | 5295 |<---------------------->| | 5296 : : : 5297 : : : 5298 | |(2)CCR(event,REFUND,Requested- 5299 | |Service-Unit,Service-Parameter-Info) 5300 | |----------------------->| 5301 | | (3)CCA(Cost-Information) 5302 | |<-----------------------| 5303 | (4)Notification | | 5304 |<-----------------------| | 5306 Figure 16: Flow VI 5308 Figure 16 illustrates a credit-control flow for the REFUND case. It 5309 is assumed that there is a trusted relationship and secure connection 5310 between the Gaming server and the Diameter credit-control server. 5311 The end user may be a prepaid subscriber or a postpaid subscriber. 5313 While the end user is playing the game (1), she enters a new level 5314 that entitles her to a bonus. The Gaming server sends a Diameter 5315 Credit-Control-Request (EVENT_REQUEST with Requested-Action: 5316 REFUND_ACCOUNT) to the Diameter credit-control server (2). The 5317 Credit-Control-Request Request contains the Requested-Service-Unit 5318 AVP with the CC-Service-Specific-Units containing the number of 5319 points the user just won. The Service-Parameter-Info AVP is also 5320 included in the request and specifies the service event to be rated 5321 (e.g., Tetris Bonus). From information received, the Diameter 5322 credit-control server determines the amount to be credited, refunds 5323 the user's account, and returns the Credit-Control-Answer, including 5324 the Cost-Information AVP (3). The Cost-Information indicates the 5325 credited amount. At the first opportunity, the Gaming server 5326 notifies the end user of the credited amount (4). 5328 B.7. Flow VII 5330 SIP Controller Top-Up 5331 A (CC Client) Server B CC Server 5332 | | | | | 5333 | | (1) CCR(Update,Used-Unit) | | 5334 | |------------------------------------------>| 5335 | | (2) CCA(Final-Unit, Redirect)| 5336 | |<------------------------------------------| 5337 : : : : : 5338 : : : : : 5339 | | (3) CCR(Update, Used-Units)| | 5340 | |------------------------------------------>| 5341 | | (3a)INVITE("hold") | | 5342 | |--------------------------->| | 5343 | | | (4) CCA(Validity-Time)| 5344 | |<------------------------------------------| 5345 | (5)INVITE | (6)INVITE | | | 5346 |<--------------|------------->| | | 5347 | (7)RTP | | | 5348 |..............................| | | 5349 | | (8)BYE | | | 5350 | |<-------------| | | 5351 | | (9)CCR(Update) | | 5352 | |------------------------------------------>| 5353 | | (10)CCA(Granted-Unit) | 5354 | |<------------------------------------------| 5355 | (12)INVITE | (11)INVITE | | 5356 |<--------------|--------------------------->| | 5358 Figure 17: Flow VII 5360 Figure 17 is an example of the graceful service termination for a SIP 5361 call. It is assumed that the call is set up so that the controller 5362 is in the call as a B2BUA (Back to Back User Agent) performing third- 5363 party call control (3PCC). Note that the SIP signaling is 5364 inaccurate, as the focus of this flow is in the graceful service 5365 termination and credit-control authorization. The best practice for 5366 3PCC is defined in [RFC3725]. 5368 The call is ongoing between users A and B; user A has a prepaid 5369 subscription. At the expiry of the allocated quota, the SIP 5370 controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) 5371 to the Diameter credit-control server (1). This message contains the 5372 units used thus far. The Diameter credit-control server debits the 5373 used units from the end user's account and allocates the final quota 5374 returned to the SIP controller in the Diameter Credit-Control-Answer 5375 (2). This message contains the Final-Unit-Indication AVP with the 5376 Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to 5377 SIP URI, and the Redirect-Server-Address set to the Top-up server 5378 name (e.g., sip:sip-topup-server@domain.com). At the expiry of the 5379 final allocated quota, the SIP controller sends a Diameter Credit- 5380 Control-Request (UPDATE_REQUEST) to the Diameter credit-control 5381 server (3) and places the called party on "hold" by sending an INVITE 5382 with the appropriate connection address in the SDP (3a). The Credit- 5383 Control-Request message contains the units used thus far. The 5384 Diameter credit-control server debits the used units from the end 5385 user's account but does not make any credit reservation. The Credit- 5386 Control-Answer message, which contains the Validity-Time to supervise 5387 the graceful service termination, is returned to the SIP controller 5388 (4). The SIP controller establishes a SIP session between the 5389 prepaid user and the Top-up server (5, 6). The Top-up server plays 5390 an announcement and prompts the user to enter a credit card number 5391 and the amount of money to be used to replenish the account (7). The 5392 Top-up server validates the credit card number and replenishes the 5393 user's account (using some means outside the scope of this 5394 specification) and releases the SIP session (8). The SIP controller 5395 can now assume that communication between the prepaid user and the 5396 Top-up server took place. It sends a spontaneous Credit-Control- 5397 Request (UPDATE_REQUEST) to the Diameter credit-control server to 5398 check whether the account has been replenished (9). The Diameter 5399 credit-control server reserves credit from the end user's account and 5400 returns the reserved quota to the SIP controller in the Credit- 5401 Control-Answer (10). At this point, the SIP controller re-connects 5402 the caller and the called party (11,12). 5404 B.8. Flow VIII 5405 NAS Top-up CC 5406 End-User (CC Client) AAA Server Server Server 5407 |(1)User Logon |(2)AA Request (CC AVPs) | | 5408 |------------------>|------------------->| | | 5409 | | |(3)CCR(initial, CC AVPs) 5410 | | |------------------->| 5411 | | |(4)CCA(Final-Unit, | 5412 | | | Validity-Time)| 5413 | | |<-------------------| 5414 | |(5)AA Answer(Final-Unit,Validity-Time) | 5415 |(6)Limited Access |<-------------------| | | 5416 | granted | | | | 5417 |<----------------->| | | | 5418 | | | | | 5419 | (7)TCP/HTTP | (8)TCP/HTTP | | 5420 |<----------------->|<----------------------------->| | 5421 | (9) Replenish account | | 5422 |<------------------------------------------------->| | 5423 | | | (10)RAR | 5424 | |<-------------------|<-------------------| 5425 | | (11) RAA | | 5426 | |------------------->|------------------->| 5427 | |(12)CCR(update) | | 5428 | |------------------->|(13)CCR(Update) | 5429 | | |------------------->| 5430 | | |(14)CCA(Granted-Units) 5431 | |(15)CCA(Granted-Units)<------------------| 5432 | |<-------------------| | 5434 Figure 18: Flow VIII 5436 Figure 18 is an example of the graceful service termination initiated 5437 when the first interrogation takes place because the user's account 5438 is empty. In this example, the credit-control server supports the 5439 server-initiated credit re-authorization. The Diameter [RFC7155] is 5440 implemented in the Network Access Server (NAS). 5442 The user logs on to the network (1). The Diameter NAS sends a 5443 Diameter AA-Request to the home Diameter AAA server. The credit- 5444 control client populates the AAR with the Credit-Control AVP set to 5445 CREDIT_AUTHORIZATION, and service-specific AVPs are included, as 5446 usual [RFC7155]. The home Diameter AAA server performs service- 5447 specific Authentication and Authorization, as usual. The home 5448 Diameter AAA server determines that the user has a prepaid 5449 subscription and notices from the Credit-Control AVP that the NAS has 5450 credit-control capabilities. It sends a Diameter Credit-Control- 5451 Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter 5452 credit-control server to perform credit authorization (3) and to 5453 establish a credit-control session. (The home Diameter AAA server 5454 may forward service-specific AVPs received from the NAS as input for 5455 the rating process.) The Diameter credit-control server checks the 5456 end user's account balance, determines that the account cannot cover 5457 the cost of the service, and initiates the graceful service 5458 termination. The Credit-Control-Answer is returned to the home 5459 Diameter AAA server (4). This message contains the Final-Unit- 5460 Indication AVP and the Validity-Time AVP set to a reasonable amount 5461 of time to give the user a chance to replenish his/her account (e.g., 5462 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- 5463 Action set to REDIRECT, the Redirect-Address-Type set to URL, and the 5464 Redirect-Server-Address set to the HTTP Top-up server name. The home 5465 Diameter AAA server sends the received credit-control AVPs to the NAS 5466 in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts 5467 the credit-control session and immediately starts the graceful 5468 service termination, as instructed by the server. The NAS grants 5469 limited access to the user (6). The HTTP client software running in 5470 the user's device opens the transport connection redirected by the 5471 NAS to the Top-up server (7,8). The user is displayed an appropriate 5472 web page on which to enter the credit card number, and the amount of 5473 money to be used to replenish the account, and with a notification 5474 message that she is granted unlimited access if the replenishment 5475 operation will be successfully executed within the next, for example, 5476 10 minutes. The Top-up server validates the credit card number and 5477 replenishes the user's account (using some means outside the scope of 5478 this specification)(9). After successful account top-up, the credit- 5479 control server sends a Re-Auth-Request message to the NAS (10). The 5480 NAS acknowledges the request by returning the Re-Auth-Answer message 5481 (11) and initiates the credit re-authorization by sending a Credit- 5482 Control-request (UPDATE_REQUEST) to the Diameter credit-control 5483 server (12,13). 5485 The Diameter credit-control server reserves credit from the end 5486 user's account and returns the reserved quota to the NAS via the home 5487 Diameter AAA server in the Credit-Control-Answer (14,15). The NAS 5488 removes the restriction placed by the graceful service termination 5489 and starts monitoring the granted units. 5491 B.9. Flow IX 5493 The Diameter credit-control application defines the Multiple- 5494 Services-Credit-Control AVP that can be used to support independent 5495 credit-control of multiple services in a single credit-control (sub-) 5496 session for service elements that have such capabilities. It is 5497 possible to request and allocate resources as a credit pool that is 5498 shared between services or rating groups. 5500 The flow example hereafter illustrates a usage scenario where the 5501 credit-control client and server support independent credit-control 5502 of multiple services, as defined in Section 5.1.2. It is assumed 5503 that Service-Identifiers, Rating-Groups, and their associated 5504 parameters (e.g., IP 5-tuple) are locally configured in the service 5505 element or provisioned by an entity other than the credit-control 5506 server. 5508 End User Service Element CC Server 5509 (CC client) 5510 |(1)User logon | | 5511 |------------------>|(2)CCR(initial, Service-Id access, | 5512 | | Access-specific AVPs, | 5513 | | Multiple-Service-Indicator) | 5514 | |---------------------------------------->| 5515 | |(3)CCA(Multiple-Services-CC ( | 5516 | | Granted-Units(Total-Octets), | 5517 | | Service-Id access, | 5518 | | Validity-time, | 5519 | | G-S-U-Pool-Reference(Pool-Id 1, | 5520 | | Multiplier 10))) | 5521 | |<----------------------------------------| 5522 : : : 5523 |(4)Service-Request (Service 1) | 5524 |------------------>|(5)CCR(update, Multiple-Services-CC( | 5525 | | Requested-Units(), Service-Id 1, | 5526 | | Rating-Group 1)) | 5527 | |---------------------------------------->| 5528 | |(6)CCA(Multiple-Services-CC ( | 5529 | | Granted-Units(Time), | 5530 | | Rating-Group 1, | 5531 | | G-S-U-Pool-Reference(Pool-Id 1, | 5532 | | Multiplier 1))) | 5533 | |<----------------------------------------| 5534 : : : 5535 |(7)Service-Request (Service 2) | 5536 |------------------>| | 5537 : : : 5538 : : : 5539 |(8)Service-Request (Service 3&4) | 5540 |------------------>|(9)CCR(update, Multiple-Services-CC ( | 5541 | | Requested-Units(), Service-Id 3, | 5542 | | Rating-Group 2), | 5543 | | Multiple-Services-CC ( | 5544 | | Requested-Units(), Service-Id 4, | 5545 | | Rating-Group 3)) | 5546 | |---------------------------------------->| 5547 | |(10)CCA(Multiple-Services-CC ( | 5548 | | Granted-Units(Total-Octets), | 5549 | | Service-Id 3, Rating-Group 2, | 5550 | | Validity-time, | 5551 | | G-S-U-Pool-Reference(Pool-Id 2, | 5552 | | Multiplier 2)), | 5553 | | Multiple-Services-CC ( | 5554 | | Granted-Units(Total-Octets), | 5555 | | Service-Id 4, Rating-Group 3 | 5556 | | Validity-Time, | 5557 | | Final-Unit-Ind.(Terminate), | 5558 | | G-S-U-Pool-Reference(Pool-Id 2, | 5559 | | Multiplier 5))) | 5560 | |<----------------------------------------| 5561 : : : 5562 : : : 5563 | +--------------+ | | 5564 | |Validity time | |(11)CCR(update, | 5565 | |expires for | | Multiple-Services-CC ( | 5566 | |Service-Id | | Requested-Unit(), | 5567 | | access | | Used-Units(In-Octets,Out-Octets),| 5568 | +--------------+ | Service-Id access)) | 5569 | |---------------------------------------->| 5570 | |(12)CCA(Multiple-Services-CC ( | 5571 | | Granted-Units(Total-Octets), | 5572 | | Service-Id access, | 5573 | | Validity-Time, | 5574 | | G-S-U-Pool-Reference(Pool-Id 1, | 5575 | | Multiplier 10))) | 5576 | |<----------------------------------------| 5577 : : : 5578 : : : 5579 | +--------------+ | | 5580 | |Total Quota | |(13)CCR(update, | 5581 | |elapses for | | Multiple-Services-CC ( | 5582 | |pool 2: | | Requested-Unit(), | 5583 | |service 4 not | | Used-Units(In-Octets,Out-Octets),| 5584 | |allowed, | | Service-Id 3, Rating-group 2), | 5585 | |service 3 cont| | Multiple-Services-CC ( | 5586 | +--------------+ | Used-Units(In-Octets,Out-Octets),| 5587 | | Service-Id 4, Rating-Group 3)) | 5588 | |---------------------------------------->| 5589 | |(14)CCA(Multiple-Services-CC ( | 5590 | | Result-Code 4011, | 5591 | | Service-Id 3)) | 5592 | |<----------------------------------------| 5593 : : : 5594 : : : 5595 |(15) User logoff | | 5596 |------------------>|(16)CCR(term, | 5597 | | Multiple-Services-CC ( | 5598 | | Used-Units(In-Octets,Out-Octets),| 5599 | | Service-Id access), | 5600 | | Multiple-Services-CC ( | 5601 | | Used-Units(Time), | 5602 | | Service-Id 1, Rating-Group 1), | 5603 | | Multiple-Services-CC ( | 5604 | | Used-Units(Time), | 5605 | | Service-Id 2, Rating-Group 1)) | 5606 | |---------------------------------------->| 5607 | |(17)CCA(term) | 5608 | |<----------------------------------------| 5610 Figure 19: Flow example independent credit-control of multiple 5611 services in a credit-control (sub-)Session 5613 The user logs on to the network (1). The service element sends a 5614 Diameter Credit-Control-Request with CC-Request-Type set to 5615 INITIAL_REQUEST to the Diameter credit-control server to perform 5616 credit authorization for the bearer service (e.g., Internet access 5617 service) and to establish a credit-control session (2). In this 5618 message, the credit-control client indicates support for independent 5619 credit-control of multiple services within the session by including 5620 the Multiple-Service-Indicator AVP. The Diameter credit-control 5621 server checks the end user's account balance, with rating information 5622 received from the client (i.e., Service-Id and access-specific AVPs), 5623 rates the request, and reserves credit from the end user's account. 5624 Suppose that the server reserves $5 and determines that the cost is 5625 $1/MB. It then returns to the service element a Credit-Control- 5626 Answer message that includes the Multiple-Services-Credit-Control AVP 5627 with a quota of 5MB associated to the Service-Id (access), to a 5628 multiplier value of 10, and to the Pool-Id 1 (3). 5630 The user uses Service 1 (4). The service element sends a Diameter 5631 Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to 5632 the credit-control server to perform credit authorization for service 5633 1 (5). This message includes the Multiple-Services-Credit-Control 5634 AVP to request service units for Service 1 that belong to Rating- 5635 Group 1. The Diameter credit-control server determines that Service 5636 1 draws credit resources from the same account as the access service 5637 (i.e., pool 1). It rates the request according to Service-Id/Rating- 5638 Group and updates the existing reservation by requesting more credit. 5639 Suppose that the server reserves $5 more (now the reservation is $10) 5640 and determines that the cost is $0.1/minute. The server authorizes 5641 the whole Rating-Group. It then returns to the service element a 5642 Credit-Control-Answer message that includes the Multiple-Services- 5643 Credit-Control AVP with a quota of 50min. associated to the Rating- 5644 Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The 5645 client adjusts the total amount of resources for pool 1 according the 5646 received quota, which gives S for Pool 1 = 100. 5648 The user uses Service 2, which belongs to the authorized Rating- 5649 Group, 1 (7). Resources are then consumed from the pool 1. 5651 The user now requests Services 3 and 4 as well, which are not 5652 authorized (8). The service element sends a Diameter Credit-Control- 5653 Request with CC-Request-Type set to UPDATE_REQUEST to the credit- 5654 control server in order to perform credit authorization for Services 5655 3 and 4 (9). This message includes two instances of the Multiple- 5656 Services-Credit-Control AVP to request service units for Service 3 5657 that belong to Rating-Group 2 and for Service 4 that belong to 5658 Rating-Group 3. The Diameter credit-control server determines that 5659 Services 3 and 4 draw credit resources from another account (i.e., 5660 pool 2). It checks the end user's account balance and, according to 5661 Service-Ids/Rating-Groups information, rates the request. Then it 5662 reserves credit from pool 2. 5664 For example, the server reserves $5 and determines that Service 3 5665 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes 5666 only Services 3 and 4. It returns to the service element a Credit- 5667 Control-Answer message that includes two instances of the Multiple- 5668 Services-Credit-Control AVP (10). One instance grants a quota of 5669 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and 5670 to the Pool-Id 2. The other instance grants a quota of 5 MB 5671 associated to the Service-Id 4 to a multiplier value of 5 and to the 5672 Pool-Id 2. 5674 The server also determines that pool 2 is exhausted and Service 4 is 5675 not allowed to continue after these units will be consumed. 5676 Therefore the Final-Unit-Indication AVP with action TERMINATE is 5677 associated to the Service-Id 4. The client calculates the total 5678 amount of resources that can be used for pool 2 according the 5679 received quotas and multipliers, which gives S for Pool 2 = 50. 5681 The Validity-Time for the access service expires. The service 5682 element sends a Credit-Control-Request message to the server in order 5683 to perform credit re-authorization for Service-Id (access) (11). 5684 This message carries one instance of the Multiple-Services-Credit- 5685 Control AVP that includes the units used by this service. Suppose 5686 that the total amount of used units is 4MB. The client adjusts the 5687 total amount of resources for pool 1 accordingly, which gives S for 5688 Pool 1 = 60. 5690 The server deducts $4 from the user's account and updates the 5691 reservation by requesting more credit. Suppose that the server 5692 reserves $5 more (now the reservation is $11) and already knows the 5693 cost of the Service-Id (access), which is $1/MB. It then returns to 5694 the service element a Credit-Control-Answer message that includes the 5695 Multiple-Services-Credit-Control AVP with a quota of 5 MB associated 5696 to the Service-Id (access), to a multiplier value of 10, and to the 5697 Pool-Id 1 (12). The client adjusts the total amount of resources for 5698 pool 1 according the received quota, which gives S for Pool 1 = 110. 5700 Services 3 and 4 consume the total amount of pool 2 credit resources 5701 (i.e., C1*2 + C2*5 >= S). The service element immediately starts the 5702 TERMINATE action concerning Service 4 and sends a Credit-Control- 5703 Request message with CC-Request-Type set to UPDATE_REQUEST to the 5704 credit-control server in order to perform credit re-authorization for 5705 Service 3 (13). This message contains two instances of the Multiple- 5706 Services-Credit-Control AVP to report the units used by Services 3 5707 and 4. The server deducts the last $5 from the user's account (pool 5708 2) and returns the answer with Result-Code 4011 in the Multiple- 5709 Services-Credit-Control AVP to indicate that Service 3 can continue 5710 without credit-control (14). 5712 The end user logs off from the network (15). To debit the used units 5713 from the end user's account and to stop the credit-control session, 5714 the service element sends a Diameter Credit-Control-Request with CC- 5715 Request-Type set to TERMINATION_REQUEST to the credit-control server 5716 (16). This message contains the units consumed by each of the used 5717 services in multiple instances of the Multiple-Services-Credit- 5718 Control AVP. The used units are associated with the relevant 5719 Service-Identifier and Rating-Group. The Diameter credit-control 5720 server debits the used units to the user's account (Pool 1) and 5721 acknowledges the session termination by sending a Diameter Credit- 5722 Control-Answer to the service element (17). 5724 Appendix C. Changes relative to RFC4006 5726 The following changes were made relative to RFC4006: 5728 Update references to obsolete RFC 3588 to refer to RFC 6733. 5730 Update references to obsolete RFC 4005 to refer to RFC 7155. 5732 Update references to obsolete RFC 2486 to refer to RFC 7542. 5734 Update references to current 3GPP documents. 5736 Update AVP per Errata ID 3329. 5738 Update reference to "IPsec or TLS" to be "TLS/TCP, DTLS/SCTP or 5739 IPsec". 5741 Clarify Filter-Rule AVP in Restrict Access Action. 5743 Remove Encr column from AVP flag rules. 5745 Clarify that RESTRICT_ACCESS action applies after consumption of 5746 final granted units (Section 5.6.3). 5748 Clarify that values in Used-Service-Unit AVP may exceed Granted- 5749 Service-Unit AVP (Section 8.19). 5751 Clarify that IPv6 representation in Redirect-Address-Type AVP 5752 conforms to RFC5952 (Section 8.38). 5754 Describe immediate graceful service termination procedure (in 5755 Section 5.6). 5757 Add extensible User-Equipment-Info-Extension AVP and included 5758 types (from Section 8.52 to Section 8.57). 5760 Define binary MAC formatting in User-Equipment-Info-MAC instead of 5761 the textual formatting in User-Equipment-Info-Data when type is 5762 MAC. 5764 Add extensible Subscription-Id-Extension AVP and included types 5765 (from Section 8.58 to Section 8.63). 5767 Add extensible Redirect-Server-Extension AVP and included types 5768 (from Section 8.64 to Section 8.67). 5770 Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68). 5772 Updated Security Section to include language consistent with 5773 structures of latest base protocol specification. 5775 Update references to obsolete RFC 5226 to refer to RFC 8126, and 5776 resulting updates to Section 12. 5778 Add section on Privacy Considerations. 5780 Language updated from RFC 2119 updated to RFC 8174. 5782 Authors' Addresses 5783 Lyle Bertz (editor) 5784 Sprint 5785 6220 Sprint Parkway 5786 Overland Park, KS 66251 5787 United States 5789 Email: lyleb551144@gmail.com 5791 David Dolson (editor) 5792 Sandvine 5793 408 Albert Street 5794 Waterloo, ON N2L 3V3 5795 Canada 5797 Email: ddolson@acm.org 5799 Yuval Lifshitz (editor) 5800 Sandvine 5801 408 Albert Street 5802 Waterloo, ON N2L 3V3 5803 Canada 5805 Email: yuvalif@yahoo.com