idnits 2.17.1 draft-ietf-dime-rfc4006bis-06.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 (January 2, 2018) is 2306 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: July 6, 2018 Sandvine 7 January 2, 2018 9 Diameter Credit-Control Application 10 draft-ietf-dime-rfc4006bis-06 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 July 6, 2018. 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. Authorization Messages for First Interrogation . . . 25 91 5.3. Intermediate Interrogation . . . . . . . . . . . . . . . 28 92 5.4. Final Interrogation . . . . . . . . . . . . . . . . . . . 30 93 5.5. Server-Initiated Credit Re-Authorization . . . . . . . . 31 94 5.6. Graceful Service Termination . . . . . . . . . . . . . . 33 95 5.6.1. Terminate Action . . . . . . . . . . . . . . . . . . 36 96 5.6.2. Redirect Action . . . . . . . . . . . . . . . . . . . 37 97 5.6.3. Restrict Access Action . . . . . . . . . . . . . . . 39 98 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 40 99 5.7. Failure Procedures . . . . . . . . . . . . . . . . . . . 40 100 6. One Time Event . . . . . . . . . . . . . . . . . . . . . . . 43 101 6.1. Service Price Enquiry . . . . . . . . . . . . . . . . . . 44 102 6.2. Balance Check . . . . . . . . . . . . . . . . . . . . . . 45 103 6.3. Direct Debiting . . . . . . . . . . . . . . . . . . . . . 45 104 6.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . . 46 105 6.5. Failure Procedure . . . . . . . . . . . . . . . . . . . . 47 106 7. Credit-Control Application State Machine . . . . . . . . . . 49 107 8. Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . . 57 108 8.1. CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . . 60 109 8.2. CC-Request-Number AVP . . . . . . . . . . . . . . . . . . 60 110 8.3. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 60 111 8.4. CC-Session-Failover AVP . . . . . . . . . . . . . . . . . 61 112 8.5. CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . . 61 113 8.6. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 62 114 8.7. Cost-Information AVP . . . . . . . . . . . . . . . . . . 62 115 8.8. Unit-Value AVP . . . . . . . . . . . . . . . . . . . . . 63 116 8.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . . 63 117 8.10. Value-Digits AVP . . . . . . . . . . . . . . . . . . . . 63 118 8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . . 63 119 8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . . 64 120 8.13. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 64 121 8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . . 64 122 8.15. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 65 123 8.16. Multiple-Services-Credit-Control AVP . . . . . . . . . . 66 124 8.17. Granted-Service-Unit AVP . . . . . . . . . . . . . . . . 67 125 8.18. Requested-Service-Unit AVP . . . . . . . . . . . . . . . 68 126 8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . . 68 127 8.20. Tariff-Time-Change AVP . . . . . . . . . . . . . . . . . 69 128 8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . . 69 129 8.22. CC-Money AVP . . . . . . . . . . . . . . . . . . . . . . 69 130 8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . . 70 131 8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . . 70 132 8.25. CC-Output-Octets AVP . . . . . . . . . . . . . . . . . . 70 133 8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . . 70 134 8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . . 70 135 8.28. Service-Identifier AVP . . . . . . . . . . . . . . . . . 71 136 8.29. Rating-Group AVP . . . . . . . . . . . . . . . . . . . . 71 137 8.30. G-S-U-Pool-Reference AVP . . . . . . . . . . . . . . . . 71 138 8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . . 72 139 8.32. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 72 140 8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . . 72 141 8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . . 73 142 8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . . 74 143 8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . . 75 144 8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . . 75 145 8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . . 76 146 8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . . 76 147 8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . . 76 148 8.41. Requested-Action AVP . . . . . . . . . . . . . . . . . . 77 149 8.42. Service-Context-Id AVP . . . . . . . . . . . . . . . . . 78 150 8.43. Service-Parameter-Info AVP . . . . . . . . . . . . . . . 78 151 8.44. Service-Parameter-Type AVP . . . . . . . . . . . . . . . 79 152 8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . . 79 153 8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . . 79 154 8.47. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 80 155 8.48. Subscription-Id-Data AVP . . . . . . . . . . . . . . . . 80 156 8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . . 81 157 8.50. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 81 158 8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . . 82 159 8.52. User-Equipment-Info-Extension AVP . . . . . . . . . . . . 82 160 8.53. User-Equipment-Info-IMEISV AVP . . . . . . . . . . . . . 82 161 8.54. User-Equipment-Info-MAC AVP . . . . . . . . . . . . . . . 82 162 8.55. User-Equipment-Info-EUI64 AVP . . . . . . . . . . . . . . 82 163 8.56. User-Equipment-Info-ModifiedEUI64 AVP . . . . . . . . . . 83 164 8.57. User-Equipment-Info-IMEI AVP . . . . . . . . . . . . . . 83 165 8.58. Subscription-Id-Extension AVP . . . . . . . . . . . . . . 83 166 8.59. Subscription-Id-E164 AVP . . . . . . . . . . . . . . . . 84 167 8.60. Subscription-Id-IMSI AVP . . . . . . . . . . . . . . . . 84 168 8.61. Subscription-Id-SIP-URI AVP . . . . . . . . . . . . . . . 84 169 8.62. Subscription-Id-NAI AVP . . . . . . . . . . . . . . . . . 84 170 8.63. Subscription-Id-Private AVP . . . . . . . . . . . . . . . 84 171 8.64. Redirect-Server-Extension AVP . . . . . . . . . . . . . . 84 172 8.65. Redirect-Address-IPAddress AVP . . . . . . . . . . . . . 85 173 8.66. Redirect-Address-URL AVP . . . . . . . . . . . . . . . . 85 174 8.67. Redirect-Address-SIP-URI AVP . . . . . . . . . . . . . . 85 175 8.68. QoS-Final-Unit-Indication AVP . . . . . . . . . . . . . . 86 176 9. Result Code AVP Values . . . . . . . . . . . . . . . . . . . 87 177 9.1. Transient Failures . . . . . . . . . . . . . . . . . . . 87 178 9.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 88 179 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 88 180 10.1. Credit-Control AVP Table . . . . . . . . . . . . . . . . 89 181 10.2. Re-Auth-Request/Answer AVP Table . . . . . . . . . . . . 90 182 11. RADIUS/Diameter Credit-Control Interworking Model . . . . . . 90 183 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 184 12.1. Application Identifier . . . . . . . . . . . . . . . . . 94 185 12.2. Command Codes . . . . . . . . . . . . . . . . . . . . . 94 186 12.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 94 187 12.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . 94 188 12.5. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . 94 189 12.6. CC-Session-Failover AVP . . . . . . . . . . . . . . . . 94 190 12.7. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 94 191 12.8. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 95 192 12.9. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 95 193 12.10. Credit-Control-Failure-Handling AVP . . . . . . . . . . 95 194 12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 95 195 12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 95 196 12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 95 197 12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 96 198 12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 96 199 12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 96 200 12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 96 201 12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 96 202 13. Credit-Control Application Related Parameters . . . . . . . . 96 203 14. Security Considerations . . . . . . . . . . . . . . . . . . . 97 204 14.1. Direct Connection with Redirects . . . . . . . . . . . . 98 205 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 206 15.1. Normative References . . . . . . . . . . . . . . . . . . 99 207 15.2. Informative References . . . . . . . . . . . . . . . . . 101 208 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 102 209 Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 102 210 B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 102 211 B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 105 212 B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 107 213 B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 107 214 B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 109 215 B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 110 216 B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 111 217 B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 113 218 B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 115 219 Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 120 220 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 121 222 1. Introduction 224 This document specifies a Diameter application that can be used to 225 implement real-time credit-control for a variety of end user services 226 such as network access, Session Initiation Protocol (SIP) services, 227 messaging services, and download services. It provides a general 228 solution to real-time cost and credit-control. 230 The prepaid model has been shown to be very successful, for instance, 231 in GSM networks, where network operators offering prepaid services 232 have experienced a substantial growth of their customer base and 233 revenues. Prepaid services are now cropping up in many other 234 wireless and wire line based networks. 236 In next generation wireless networks, additional functionality is 237 required beyond that specified in the Diameter base protocol. For 238 example, the 3GPP Charging and Billing requirements [TGPPCHARG] state 239 that an application must be able to rate service information in real- 240 time. In addition, it is necessary to check that the end user's 241 account provides coverage for the requested service prior to 242 initiation of that service. When an account is exhausted or expired, 243 the user must be denied the ability to compile additional chargeable 244 events. 246 A mechanism has to be provided to allow the user to be informed of 247 the charges to be levied for a requested service. In addition, there 248 are services such as gaming and advertising that may credit as well 249 as debit a user account. 251 The other Diameter applications provide service specific 252 authorization, and they do not provide credit authorization for 253 prepaid users. The credit authorization shall be generic and 254 applicable to all the service environments required to support 255 prepaid services. 257 To fulfill these requirements, it is necessary to facilitate credit- 258 control communication between the network element providing the 259 service (e.g., Network Access Server, SIP Proxy, and Application 260 Server) and a credit-control server. 262 The scope of this specification is the credit authorization. Service 263 specific authorization and authentication is out of the scope. 265 1.1. Requirements Language 267 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 268 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 269 document are to be interpreted as described in [RFC2119]. 271 1.2. Terminology 273 AAA Authentication, Authorization, and Accounting 275 AA answer AA answer generically refers to a service specific 276 authorization and authentication answer. AA answer commands are 277 defined in service specific authorization applications, e.g., 278 [RFC7155] and [RFC4004]. 280 AA request AA request generically refers to a service specific 281 authorization and authentication request. AA request commands are 282 defined in service specific authorization applications e.g., 283 [RFC7155] and [RFC4004]. 285 Credit-control Credit-control is a mechanism that directly interacts 286 in real-time with an account and controls or monitors the charges 287 related to the service usage. Credit-control is a process of 288 checking whether credit is available, credit-reservation, 289 deduction of credit from the end user account when service is 290 completed and refunding of reserved credit that is not used. 292 Diameter Credit-control Server A Diameter credit-control server acts 293 as a prepaid server, performing real-time rating and credit- 294 control. It is located in the home domain and is accessed by 295 service elements or Diameter AAA servers in real-time for purpose 296 of price determination and credit-control before the service event 297 is delivered to the end-user. It may also interact with business 298 support systems. 300 Diameter Credit-control Client A Diameter credit-control client is 301 an entity that interacts with a credit-control server. It 302 monitors the usage of the granted quota according to instructions 303 returned by credit-control server. 305 Interrogation The Diameter credit-control client uses interrogation 306 to initiate a session based credit-control process. During the 307 credit-control process, it is used to report the used quota and 308 request a new one. An interrogation maps to a request/answer 309 transaction. 311 One-time event Basically, a request/answer transaction of type 312 event. 314 Rating The act of determining the cost of the service event. 316 Service A type of task performed by a service element for an end 317 user. 319 Service Element A network element that provides a service to the end 320 users. The Service Element may include the Diameter credit- 321 control client, or another entity (e.g., RADIUS AAA server) that 322 can act as a credit-control client on behalf of the Service 323 Element. In the latter case, the interface between the Service 324 Element and the Diameter credit-control client is outside the 325 scope of this specification. Examples of the Service Elements 326 include Network Access Server (NAS), SIP Proxy, and Application 327 Servers such as messaging server, content server, and gaming 328 server. 330 Service Event An event relating to a service provided to the end 331 user. 333 Session based credit-control A credit-control process that makes use 334 of several interrogations: the first, a possible intermediate, and 335 the final. The first interrogation is used to reserve money from 336 the user's account and to initiate the process. The intermediate 337 interrogations may be needed to request new quota while the 338 service is being rendered. The final interrogation is used to 339 exit the process. The credit-control server is required to 340 maintain session state for session-based credit-control. 342 1.3. Advertising Application Support 344 Diameter nodes conforming to this specification MUST advertise 345 support by including the value of 4 in the Auth-Application-Id of the 346 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 347 command [RFC6733]. 349 2. Architecture Models 351 The current accounting models specified in the Radius Accounting 352 [RFC2866] and Diameter base [RFC6733] are not sufficient for real- 353 time credit-control, where credit-worthiness is to be determined 354 prior to service initiation. Also, the existing Diameter 355 authorization applications, [RFC7155] and [RFC4004], only provide 356 service authorization, but do not provide credit authorization for 357 prepaid users. In order to support real-time credit-control, a new 358 type of server is needed in the AAA infrastructure: Diameter credit- 359 control server. The Diameter credit-control server is the entity 360 responsible for credit authorization for prepaid subscribers. 362 A service element may authenticate and authorize the end user with 363 the AAA server by using AAA protocols; e.g., RADIUS or a Diameter 364 base protocol with a possible Diameter application. 366 Accounting protocols such as RADIUS accounting and the Diameter base 367 accounting protocol can be used to provide accounting data to the 368 accounting server after service is initiated, and to provide possible 369 interim reports until service completion. However, for real-time 370 credit-control, these authorization and accounting models are not 371 sufficient. 373 When real-time credit-control is required, the credit-control client 374 contacts the credit-control server with information about a possible 375 service event. The credit-control process is performed to determine 376 potential charges and to verify whether the end user's account 377 balance is sufficient to cover the cost of the service being 378 rendered. 380 Figure 1 illustrates the typical credit-control architecture, which 381 consists of a Service Element with an embedded Diameter credit- 382 control client, a Diameter credit-control server, and an AAA server. 383 A Business Support System is usually deployed; it includes at least 384 the billing functionality. The credit-control server and AAA server 385 in this architecture model are logical entities. The real 386 configuration can combine them into a single host. The credit- 387 control protocol is the Diameter base protocol with the Diameter 388 credit-control application. 390 When an end user requests services such as SIP or messaging, the 391 request is typically forwarded to a service element (e.g., SIP Proxy) 392 in the user's home domain. In some cases it might be possible that 393 the service element in the visited domain can offer services to the 394 end user; however, a commercial agreement must exist between the 395 visited domain and the home domain. Network access is an example of 396 a service offered in the visited domain where the NAS, through an AAA 397 infrastructure, authenticates and authorizes the user with the user's 398 home network. 400 Service Element AAA and CC 401 +----------+ +---------+ Protocols+-----------+ +--------+ 402 | End |<---->|+-------+|<------------>| AAA | |Business| 403 | User | +->|| CC || | Server |->|Support | 404 | | | || Client||<-----+ | | |System | 405 +----------+ | |+-------+| | +-----------+ | | 406 | +---------+ | ^ +--------+ 407 +----------+ | | CC Protocol | ^ 408 | End |<--+ | +-----v----+ | 409 | User | +------>|Credit- | | 410 +----------+ Credit-Control |Control |--------+ 411 Protocol |Server | 412 +----------+ 414 Figure 1: Typical credit-control architecture 416 There can be multiple credit-control servers in the system for 417 redundancy and load balancing. The system can also contain separate 418 rating server(s), and accounts can be located in a centralized 419 database. To ensure that the end user's account is not debited or 420 credited multiple times for the same service event, only one place in 421 the credit-control system should perform duplicate detection. System 422 internal interfaces can exist to relay messages between servers and 423 an account manager. However, the detailed architecture of the 424 credit-control system and its interfaces are implementation specific 425 and are out of scope of this specification. 427 Protocol transparent Diameter relays can exist between the credit- 428 control client and credit-control server. Also, Diameter Redirect 429 agents that refer credit-control clients to credit-control servers 430 and allow them to communicate directly can exist. These agents 431 transparently support the Diameter credit-control application. The 432 different roles of Diameter Agents are defined in Diameter base 433 [RFC6733], section 2.8. 435 If Diameter credit-control proxies exist between the credit-control 436 client and the credit-control server, they MUST advertise the 437 Diameter credit-control application support. 439 3. Credit-Control Messages 441 This section defines new Diameter message Command-Code values that 442 MUST be supported by all Diameter implementations that conform to 443 this specification. The Command Codes are as follows: 445 +------------------------+---------+------+-----------+ 446 | Command-Name | Abbrev. | Code | Reference | 447 +------------------------+---------+------+-----------+ 448 | Credit-Control-Request | CCR | 272 | 3.1 | 449 | Credit-Control-Answer | CCA | 272 | 3.2 | 450 +------------------------+---------+------+-----------+ 452 Table 1: Credit-Control Commands 454 Diameter Base [RFC6733] defines in the section 3.2 the Command Code 455 format specification. These formats are observed in Credit-Control 456 messages. 458 3.1. Credit-Control-Request (CCR) Command 460 The Credit-Control-Request message (CCR) is indicated by the command- 461 code field being set to 272 and the 'R' bit being set in the Command 462 Flags field. It is used between the Diameter credit-control client 463 and the credit-control server to request credit authorization for a 464 given service. 466 The Auth-Application-Id MUST be set to the value 4, indicating the 467 Diameter credit-control application. 469 Message Format 470 ::= < Diameter Header: 272, REQ, PXY > 471 < Session-Id > 472 { Origin-Host } 473 { Origin-Realm } 474 { Destination-Realm } 475 { Auth-Application-Id } 476 { Service-Context-Id } 477 { CC-Request-Type } 478 { CC-Request-Number } 479 [ Destination-Host ] 480 [ User-Name ] 481 [ CC-Sub-Session-Id ] 482 [ Acct-Multi-Session-Id ] 483 [ Origin-State-Id ] 484 [ Event-Timestamp ] 485 *[ Subscription-Id ] 486 *[ Subscription-Id-Extension ] 487 [ Service-Identifier ] 488 [ Termination-Cause ] 489 [ Requested-Service-Unit ] 490 [ Requested-Action ] 491 *[ Used-Service-Unit ] 492 [ Multiple-Services-Indicator ] 493 *[ Multiple-Services-Credit-Control ] 494 *[ Service-Parameter-Info ] 495 [ CC-Correlation-Id ] 496 [ User-Equipment-Info ] 497 [ User-Equipment-Info-Extension ] 498 *[ Proxy-Info ] 499 *[ Route-Record ] 500 *[ AVP ] 502 3.2. Credit-Control-Answer (CCA) Command 504 The Credit-Control-Answer message (CCA) is indicated by the command- 505 code field being set to 272 and the 'R' bit being cleared in the 506 Command Flags field. It is used between the credit-control server 507 and the Diameter credit-control client to acknowledge a Credit- 508 Control-Request command. 510 Message Format 511 ::= < Diameter Header: 272, PXY > 512 < Session-Id > 513 { Result-Code } 514 { Origin-Host } 515 { Origin-Realm } 516 { Auth-Application-Id } 517 { CC-Request-Type } 518 { CC-Request-Number } 519 [ User-Name ] 520 [ CC-Session-Failover ] 521 [ CC-Sub-Session-Id ] 522 [ Acct-Multi-Session-Id ] 523 [ Origin-State-Id ] 524 [ Event-Timestamp ] 525 [ Granted-Service-Unit ] 526 *[ Multiple-Services-Credit-Control ] 527 [ Cost-Information] 528 [ Final-Unit-Indication ] 529 [ QoS-Final-Unit-Indication ] 530 [ Check-Balance-Result ] 531 [ Credit-Control-Failure-Handling ] 532 [ Direct-Debiting-Failure-Handling ] 533 [ Validity-Time ] 534 *[ Redirect-Host ] 535 [ Redirect-Host-Usage ] 536 [ Redirect-Max-Cache-Time ] 537 *[ Proxy-Info ] 538 *[ Route-Record ] 539 *[ Failed-AVP ] 540 *[ AVP ] 542 4. Credit-Control Application Overview 544 The credit authorization process takes place before and during 545 service delivery to the end user and generally requires the user's 546 authentication and authorization before any request is sent to the 547 credit-control server. The credit-control application defined in 548 this specification supports two different credit authorization 549 models: credit authorization with money reservation and credit 550 authorization with direct debiting. In both models, the credit- 551 control client requests credit authorization from the credit-control 552 server prior to allowing any service to be delivered to the end user. 554 In the first model, the credit-control server rates the request, 555 reserves a suitable amount of money from the user's account, and 556 returns the corresponding amount of credit resources. Note that 557 credit resources may not imply actual monetary credit; credit 558 resources may be granted to the credit control client in the form of 559 units (e.g., data volume or time) to be metered. 561 Upon receipt of a successful credit authorization answer with a 562 certain amount of credit resources, the credit-control client allows 563 service delivery to the end user and starts monitoring the usage of 564 the granted resources. When the credit resources granted to the user 565 have been consumed or the service has been successfully delivered or 566 terminated, the credit-control client reports back to the server the 567 used amount. The credit-control server deducts the used amount from 568 the end user's account; it may perform rating and make a new credit 569 reservation if the service delivery is continuing. This process is 570 accomplished with session based credit-control that includes the 571 first interrogation, possible intermediate interrogations, and the 572 final interrogation. For session based credit-control, both the 573 credit control client and the credit-control server are required to 574 maintain credit-control session state. Session based credit-control 575 is described in more detail, with more variations, in Section 5. 577 In contrast, credit authorization with direct debiting is a single 578 transaction process wherein the credit-control server directly 579 deducts a suitable amount of money from the user's account as soon as 580 the credit authorization request is received. Upon receipt of a 581 successful credit authorization answer, the credit-control client 582 allows service delivery to the end user. This process is 583 accomplished with the one-time event. Session state is not 584 maintained. 586 In a multi-service environment, an end user can issue an additional 587 service request (e.g., data service) during an ongoing service (e.g., 588 voice call) toward the same account. Alternatively, during an active 589 multimedia session, an additional media type is added to the session, 590 causing a new simultaneous request toward same account. 591 Consequently, this needs to be considered when credit resources are 592 granted to the services. 594 The credit-control application also supports operations such as 595 service price enquiry, user's balance check, and refund of credit on 596 the user's account. These operations are accomplished with the one- 597 time event. Session state is not maintained. 599 A flexible credit-control application specific failure handling is 600 defined in which the home service provider can model the credit- 601 control client behavior according to its own credit risk management 602 policy. 604 The Credit-Control-Failure-Handling AVP and the Direct-Debiting- 605 Failure-Handling AVP are defined to determine what is done if the 606 sending of credit-control messages to the credit-control server has 607 been temporarily prevented. The usage of the Credit-Control-Failure- 608 Handling AVP and the Direct-Debiting-Failure-Handling AVP allows 609 flexibility, as failure handling for the credit-control session and 610 one-time event direct debiting may be different. 612 4.1. Service-Specific Rating Input and Interoperability 614 The Diameter credit-control application defines the framework for 615 credit-control; it provides generic credit-control mechanisms 616 supporting multiple service applications. The credit-control 617 application, therefore, does not define AVPs that could be used as 618 input in the rating process. Listing the possible services that 619 could use this Diameter application is out of scope for this generic 620 mechanism. 622 It is reasonable to expect that a service level agreement will exist 623 between providers of the credit-control client and the credit-control 624 server covering the charging, services offered, roaming agreements, 625 agreed rating input (i.e., AVPs), and so on. 627 Therefore, it is assumed that a Diameter credit-control server will 628 provide service only for Diameter credit-control clients that have 629 agreed beforehand as to the content of credit-control messages. 630 Naturally, it is possible that any arbitrary Diameter credit-control 631 client can interchange credit-control messages with any Diameter 632 credit-control server, but with a higher likelihood that unsupported 633 services/AVPs could be present in the credit-control message, causing 634 the server to reject the request with an appropriate result-code. 636 4.1.1. Specifying Rating Input AVPs 638 There are two ways to provide rating input to the credit-control 639 server: either by using AVPs or by including them in the Service- 640 Parameter-Info AVP. The general principles for sending rating 641 parameters are as follows: 643 1a. The service SHOULD re-use existing AVPs if it can use AVPs 644 defined in existing Diameter applications (e.g., [RFC7155] for 645 network access services). Re-use of existing AVPs is strongly 646 recommended in [RFC6733]. 648 For AVPs of type Enumerated, the service may require a new value to 649 be defined. Allocation of new AVP values is done as specified in 650 [RFC6733], section 1.3. 652 1b. New AVPs can be defined if the existing AVPs do not provide 653 sufficient rating information. In this case, the procedures defined 654 in [RFC6733] for creating new AVPs MUST be followed. 656 1c. For services specific only to one vendor's implementation, a 657 Vendor-Specific AVP code for Private use can be used. Where a 658 Vendor-Specific AVP is implemented by more than one vendor, 659 allocation of global AVPs is encouraged instead; refer to [RFC6733]. 661 2. The Service-Parameter-Info AVP MAY be used as a container to pass 662 legacy rating information in its original encoded form (e.g., ASN.1 663 BER). This method can be used to avoid unnecessary conversions from 664 an existing data format to an AVP format. In this case, the rating 665 input is embedded in the Service-Parameter-Info AVP as defined in 666 Section 8.43. 668 New service applications SHOULD favor the use of explicitly defined 669 AVPs as described in items 1a and 1b, to simplify interoperability. 671 4.1.2. Service-Specific Documentation 673 The service specific rating input AVPs, the contents of the Service- 674 Parameter-Info AVP or Service-Context-Id AVP (defined in 675 Section 8.42) are not within the scope of this document. To 676 facilitate interoperability, it is RECOMMENDED that the rating input 677 and the values of the Service-Context-Id be coordinated via an 678 informational RFC or other permanent and readily available reference. 679 The specification of another cooperative standardization body (e.g., 680 3GPP, OMA, or 3GPP2) SHOULD be used. However, private services may 681 be deployed that are subject to agreements between providers of the 682 credit-control server and client. In this case, vendor specific AVPs 683 can be used. 685 This specification, together with the above service specific 686 documents, governs the credit-control message. Service specific 687 documents define which existing AVPs or new AVPs are used as input to 688 the rating process (i.e., those that do not define new credit-control 689 applications), and thus have to be included in the Credit-Control- 690 Request command by a Diameter credit-control client supporting a 691 given service as *[AVP]. Should Service-Parameter-Info be used, then 692 the service specific document MUST specify the exact content of this 693 grouped AVP. 695 The Service-Context-Id AVP MUST be included at the command level of a 696 Credit-Control Request to identify the service specific document that 697 applies to the request. The specific service or rating group the 698 request relates to is uniquely identified by the combination of 699 Service-Context-Id and Service-Identifier or Rating-Group. 701 4.1.3. Handling of Unsupported/Incorrect Rating Input 703 Diameter credit-control implementations are required to support the 704 Mandatory rating AVPs defined in service specific documentation of 705 the services they support, according to the 'M' bit rules in 706 [RFC6733]. 708 If a rating input required for the rating process is incorrect in the 709 Credit-control request, or if the credit-control server does not 710 support the requested service context (identified by the Service- 711 Context-Id AVP at command level), the Credit-control answer MUST 712 contain the error code DIAMETER_RATING_FAILED. A CCA message with 713 this error MUST contain one or more Failed-AVP AVPs containing the 714 missing and/or unsupported AVPs that caused the failure. A Diameter 715 credit-control client that receives the error code 716 DIAMETER_RATING_FAILED in response to a request MUST NOT send similar 717 requests in the future. 719 4.1.4. RADIUS Vendor-Specific Rating Attributes 721 When service specific documents include RADIUS vendor specific 722 attributes that could be used as input in the rating process, the 723 rules described in [RFC7155] for formatting the Diameter AVP MUST be 724 followed. 726 For example, if the AVP code used is the vendor attribute type code, 727 the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be 728 set to the IANA Vendor identification value. The Diameter AVP data 729 field contains only the attribute value of the RADIUS attribute. 731 5. Session Based Credit-Control 733 5.1. General Principles 735 For a session-based credit-control, several interrogations are 736 needed: the first, intermediate (optional) and the final 737 interrogations. This is illustrated in Figure 3 and Figure 4. 739 If the credit-control client performs credit-reservation before 740 granting service to the end user, it MUST use several interrogations 741 toward the credit-control server (i.e., session based credit- 742 control). In this case, the credit-control server MUST maintain the 743 credit-control session state. 745 Each credit-control session MUST have a globally unique Session-Id as 746 defined in [RFC6733], which MUST NOT be changed during the lifetime 747 of a credit-control session. 749 Certain applications require multiple credit-control sub-sessions. 750 These applications would send messages with a constant Session-Id 751 AVP, but with a different CC-Sub-Session-Id AVP. If several credit 752 sub-sessions will be used, all sub-sessions MUST be closed separately 753 before the main session is closed so that units per sub-session may 754 be reported. The absence of this AVP implies that no sub-sessions 755 are in use. 757 Note that the service element might send a service specific re- 758 authorization message to the AAA server due to expiration of the 759 authorization-lifetime during an ongoing credit-control session. 760 However, the service specific re-authorization does not influence the 761 credit authorization that is ongoing between the credit-control 762 client and credit-control server, as credit authorization is 763 controlled by the burning rate of the granted quota. 765 If service specific re-authorization fails, the user will be 766 disconnected, and the credit-control client MUST send a final 767 interrogation to the credit-control server. 769 The Diameter credit-control server may seek to control the validity 770 time of the granted quota and/or the production of intermediate 771 interrogations. Thus, it MAY include the Validity-Time AVP in the 772 answer message to the credit-control client. Upon expiration of the 773 Validity-Time, the credit-control client MUST generate a credit- 774 control update request and report the used quota to the credit- 775 control server. It is up to the credit-control server to determine 776 the value of the Validity-Time to be used for consumption of the 777 granted service units. If the Validity-Time is used, its value 778 SHOULD be given as input to set the session supervision timer Tcc 779 (the session supervision timer MAY be set to two times the value of 780 the Validity-Time, as defined in Section 13). Since credit-control 781 update requests are also produced at the expiry of granted service 782 units and/or for mid-session service events, the omission of 783 Validity-Time does not mean that intermediate interrogation for the 784 purpose of credit-control is not performed. 786 5.1.1. Basic Tariff-Time Change Support 788 The Diameter credit-control server and client MAY optionally support 789 a tariff change mechanism. The Diameter credit-control server may 790 include a Tariff-Time-Change AVP in the answer message. Note that 791 the granted units should be allocated based on the worst-case 792 scenario in case of forthcoming tariff change, so that the overall 793 reported used units would never exceed the credit reservation. 795 When the Diameter credit-control client reports the used units and a 796 tariff change has occurred during the reporting period, the Diameter 797 credit-control client MUST separately itemize the units used before 798 and after the tariff change. If the client is unable to distinguish 799 whether units straddling the tariff change were used before or after 800 the tariff change, the credit-control client MUST itemize those units 801 in a third category. 803 If a client does not support the tariff change mechanism and it 804 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 805 terminate the credit-control session, giving a reason of 806 DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 808 For time based services, the quota is continuously consumed at the 809 regular rate of 60 seconds per minute. At the time when credit 810 resources are allocated, the server already knows how many units will 811 be consumed before the tariff time change and how many units will be 812 consumed afterward. Similarly, the server can determine the units 813 consumed at the before rate and the units consumed at the rate 814 afterward in the event that the end-user closes the session before 815 the consumption of the allotted quota. There is no need for 816 additional traffic between client and server in the case of tariff 817 time changes for continuous time based service. Therefore, the 818 tariff change mechanism is not used for such services. For time- 819 based services in which the quota is NOT continuously consumed at a 820 regular rate, the tariff change mechanism described for volume and 821 event units MAY be used. 823 5.1.2. Credit-Control for Multiple Services within a (sub-)Session 825 When multiple services are used within the same user session and each 826 service or group of services is subject to different cost, it is 827 necessary to perform credit-control for each service independently. 828 Making use of credit-control sub-sessions to achieve independent 829 credit-control will result in increased signaling load and usage of 830 resources in both the credit-control client and the credit-control 831 server. For instance, during one network access session the end user 832 may use several http-services subject to different access cost. The 833 network access specific attributes such as the quality of service 834 (QoS) are common to all the services carried within the access 835 bearer, but the cost of the bearer may vary depending on its content. 837 To support these scenarios optimally, the credit-control application 838 enables independent credit-control of multiple services in a single 839 credit-control (sub-)session. This is achieved by including the 840 optional Multiple-Services-Credit-Control AVP in Credit-Control- 841 Request/Answer messages. It is possible to request and allocate 842 resources as a credit pool shared between multiple services. The 843 services can be grouped into rating groups in order to achieve even 844 further aggregation of credit allocation. It is also possible to 845 request and allocate quotas on a per service basis. Where quotas are 846 allocated to a pool by means of the Multiple-Services-Credit-Control 847 AVP, the quotas remain independent objects that can be re-authorized 848 independently at any time. Quotas can also be given independent 849 result codes, validity times, and Final-Unit-Indications or QoS- 850 Final-Unit-Indications. 852 A Rating-Group gathers a set of services, identified by a Service- 853 Identifier, and subject to the same cost and rating type (e.g., $0.1/ 854 minute). It is assumed that the service element is provided with 855 Rating-Groups, Service-Identifiers, and their associated parameters 856 that define what has to be metered by means outside the scope of this 857 specification. (Examples of parameters associated to Service- 858 Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers enable 859 authorization on a per-service based credit as well as itemized 860 reporting of service usage. It is up to the credit-control server 861 whether to authorize credit for one or more services or for the whole 862 rating-group. However, the client SHOULD always report used units at 863 the finest supported level of granularity. Where quota is allocated 864 to a rating-group, all the services belonging to that group draw from 865 the allotted quota. The following is a graphical representation of 866 the relationship between service-identifiers, rating-groups, credit 867 pools, and credit-control (sub-)session. 869 DCC (Sub-)Session 870 | 871 +------------+-----------+-------------+--------------- + 872 | | | | | 873 Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z 874 \ / \ / / 875 \ / \ / / 876 \ / Rating-Group 1.......Rating-Group n 877 \ / | | 878 Quota ---------------Quota Quota 879 | / | 880 | / | 881 Credit-Pool Credit-Pool 883 Figure 2: Multiple-Service (sub)-Session Example 885 If independent credit-control of multiple services is used, the 886 Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- 887 Indication AVP SHOULD be present either in the Multiple-Services- 888 Credit-Control AVP(s) or at command level as single AVPs. However, 889 the Result-Code AVP MAY be present both on the command level and 890 within the Multiple-Services-Credit-Control AVP. If the Result-Code 891 AVP on the command level indicates a value other than SUCCESS, then 892 the Result-Code AVP on command level takes precedence over any 893 included in the Multiple-Services-Credit-Control AVP. 895 The credit-control client MUST indicate support for independent 896 credit-control of multiple services within a (sub-)session by 897 including the Multiple-Services-Indicator AVP in the first 898 interrogation. A credit-control server not supporting this feature 899 MUST treat the Multiple-Services-Indicator AVP and any received 900 Multiple-Services-Credit-Control AVPs as invalid AVPs. 902 If the client indicated support for independent credit-control of 903 multiple services, a credit-control server that wishes to use the 904 feature MUST return the granted units within the Multiple-Services- 905 Credit-Control AVP associated to the corresponding service-identifier 906 and/or rating-group. 908 To avoid a situation where several parallel (and typically also 909 small) credit reservations must be made on the same account (i.e., 910 credit fragmentation), and also to avoid unnecessary load on the 911 credit-control server, it is possible to provide service units as a 912 pool that applies to multiple services or rating groups. This is 913 achieved by providing the service units in the form of a quota for a 914 particular service or rating group in the Multiple-Services-Credit- 915 Control AVP, and also by including a reference to a credit pool for 916 that unit type. 918 The reference includes a multiplier derived from the rating 919 parameter, which translates from service units of a specific type to 920 the abstract service units in the pool. For instance, if the rating 921 parameter for service 1 is $1/MB and the rating parameter for service 922 2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2, 923 respectively. 925 If S is the total service units within the pool, M1, M2, ..., Mn are 926 the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., 927 Cn are the used resources within the session, then the pool credit is 928 exhausted and re-authorization MUST be sought when: 930 C1*M1 + C2*M2 + ... + Cn*Mn >= S 932 The total credit in the pool, S, is calculated from the quotas, which 933 are currently allocated to the pool as follows: 935 S = Q1*M1 + Q2*M2 + ... + Qn*Mn 937 If services or rating groups are added to or removed from the pool, 938 then the total credit is adjusted appropriately. Note that when the 939 total credit is adjusted because services or rating groups are 940 removed from the pool, the value that need to be removed is the 941 consumed one (i.e., Cx*Mx). 943 Re-authorizations for an individual service or rating group may be 944 sought at any time; for example, if a 'non-pooled' quota is used up 945 or the Validity-Time expires. 947 Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same 948 G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit- 949 Control AVP (Section 8.16) along with the Granted-Service-Unit AVP, 950 then these MUST have different CC-Unit-Type values, and they all draw 951 from the credit pool separately. For instance, if one multiplier for 952 time (M1t) and one multiplier for volume (M1v) are given, then the 953 used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t 954 is the time unit and C1v is the volume unit. 956 Where service units are provided within a Multiple-Services-Credit- 957 Control AVP without a corresponding G-S-U-Pool-Reference AVP, then 958 these are handled independently from any credit pool and from any 959 other services or rating groups within the session. 961 The credit pool concept is an optimal tool to avoid the over- 962 reservation effect of the basic single quota tariff time change 963 mechanism (the mechanism described in Section 5.1.1). Therefore, 964 Diameter credit-control clients and servers implementing the 965 independent credit-control of multiple services SHOULD leverage the 966 credit pool concept when supporting the tariff time change. The 967 Diameter credit-control server SHOULD include both the Tariff-Time- 968 Change and Tariff-Change-Usage AVPs in two quota allocations in the 969 answer message (i.e., two instances of the Multiple-Services-Credit- 970 Control AVP). One of the granted units is allocated to be used 971 before the potential tariff change, while the second granted units 972 are for use after a tariff change. Both granted unit quotas MUST 973 contain the same Service-Identifier and/or Rating-Group. This dual 974 quota mechanism ensures that the overall reported used units would 975 never exceed the credit reservation. The Diameter credit-control 976 client reports both the used units before and after the tariff change 977 in a single instance of the Multiple-Services-Credit-Control AVP. 979 The failure handling for credit-control sessions is defined in 980 Section 5.7 and reflected in the basic credit-control state machine 981 in Section 7. Credit-control clients and servers implementing the 982 independent credit-control of multiple services in a (sub-)session 983 functionality MUST ensure failure handling and general behavior fully 984 consistent with the above mentioned sections, while maintaining the 985 ability to handle parallel ongoing credit re-authorization within a 986 (sub-)session. Therefore, it is RECOMMENDED that Diameter credit- 987 control clients maintain a PendingU message queue and restart the Tx 988 timer (Section 13) every time a CCR message with the value 989 UPDATE_REQUEST is sent while they are in PendingU state. When 990 answers to all pending messages are received, the state machine moves 991 to OPEN state, and Tx is stopped. Naturally, the action performed 992 when a problem for the session is detected according to Section 5.7 993 affects all the ongoing services (e.g., failover to a backup server 994 if possible affect all the CCR messages with the value UPDATE_REQUEST 995 in the PendingU queue). 997 Since the client may send CCR messages with the value UPDATE_REQUEST 998 while in PendingU (i.e., without waiting for an answer to ongoing 999 credit re-authorization), the time space between these requests may 1000 be very short, and the server may not have received the previous 1001 request(s) yet. Therefore, in this situation the server may receive 1002 out of sequence requests and SHOULD NOT consider this an error 1003 condition. A proper answer is to be returned to each of those 1004 requests. 1006 5.2. First Interrogation 1008 When session based credit-control is required (e.g., the 1009 authentication server indicated a prepaid user), the first 1010 interrogation MUST be sent before the Diameter credit-control client 1011 allows any service event to the end user. The CC-Request-Type is set 1012 to the value INITIAL_REQUEST in the request message. 1014 If the Diameter credit-control client knows the cost of the service 1015 event (e.g., a content server delivering ringing tones may know their 1016 cost) the monetary amount to be charged is included in the Requested- 1017 Service-Unit AVP. If the Diameter credit-control client does not 1018 know the cost of the service event, the Requested-Service-Unit AVP 1019 MAY contain the number of requested service events. Where the 1020 Multiple-Services-Credit-Control AVP is used, it MUST contain the 1021 Requested-Service-Unit AVP to indicate that the quota for the 1022 associated service/rating-group is requested. In the case of 1023 multiple services, the Service-Identifier AVP or the Rating-Group AVP 1024 within the Multiple-Services-Credit-Control AVP always indicates the 1025 service concerned. Additional service event information to be rated 1026 MAY be sent as service specific AVPs or MAY be sent within the 1027 Service-Parameter-Info AVP at command level. The Service-Context-Id 1028 AVP indicates the service specific document applicable to the 1029 request. 1031 The Event-Timestamp AVP SHOULD be included in the request and 1032 contains the time when the service event is requested in the service 1033 element. The Subscription-Id AVP or the Subscription-Id-Extension 1034 AVP SHOULD be included to identify the end user in the credit-control 1035 server. The credit-control client MAY include the User-Equipment- 1036 Info AVP or User-Equipment-Info-Extension AVP so that the credit- 1037 control server has some indication of the type and capabilities of 1038 the end user access device. How the credit-control server uses this 1039 information is outside the scope of this document. 1041 The credit-control server SHOULD rate the service event and make a 1042 credit-reservation from the end user's account that covers the cost 1043 of the service event. If the type of the Requested-Service-Unit AVP 1044 is money, no rating is needed, but the corresponding monetary amount 1045 is reserved from the end user's account. 1047 The credit-control server returns the Granted-Service-Unit AVP in the 1048 Answer message to the Diameter credit-control client. The Granted- 1049 Service-Unit AVP contains the amount of service units that the 1050 Diameter credit-control client can provide to the end user until a 1051 new Credit-Control-Request MUST be sent to the credit-control server. 1052 If several unit types are sent in the Answer message, the credit- 1053 control client MUST handle each unit type separately. The type of 1054 the Granted-Service-Unit AVP can be time, volume, service specific, 1055 or money, depending on the type of service event. The unit type(s) 1056 SHOULD NOT be changed within an ongoing credit-control session. 1058 There MUST be a maximum of one instance of the same unit type in one 1059 Answer message. However, if multiple quotas are conveyed to the 1060 credit-control client in the Multiple-Services-Credit-Control AVPs, 1061 it is possible to carry two instances of the same unit type 1062 associated to a service-identifier/rating-group. This is typically 1063 the case when a tariff time change is expected and the credit-control 1064 server wants to make a distinction between the granted quota before 1065 and after tariff change. 1067 If the credit-control server determines that no further control is 1068 needed for the service, it MAY include the result code indicating 1069 that the credit-control is not applicable (e.g., if the service is 1070 free of charge). This result code at command level implies that the 1071 credit-control session is to be terminated. 1073 The Credit-Control-Answer message MAY also include the Final-Unit- 1074 Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that 1075 the answer message contains the final units for the service. After 1076 the end user has consumed these units, the Diameter credit-control- 1077 client MUST behave as described in Section 5.6. 1079 This document defines two different approaches to perform the first 1080 interrogation to be used in different network architectures. The 1081 first approach uses credit-control messages after the user's 1082 authorization and authentication takes place. The second approach 1083 uses service specific authorization messages to perform the first 1084 interrogation during the user's authorization/authentication phase, 1085 and credit-control messages for the intermediate and final 1086 interrogations. If an implementation of the credit-control client 1087 supports both the methods, determining which method to use SHOULD be 1088 configurable. 1090 In service environments such as the Network Access Server (NAS), it 1091 is desired to perform the first interrogation as part of the 1092 authorization/authentication process for the sake of protocol 1093 efficiency. Further credit authorizations after the first 1094 interrogation are performed with credit-control commands defined in 1095 this specification. Implementations of credit-control clients 1096 operating in the mentioned environments SHOULD support this method. 1097 If the credit-control server and AAA server are separate physical 1098 entities, the service element sends the request messages to the AAA 1099 server, which then issues an appropriate request or proxies the 1100 received request forward to the credit-control server. 1102 In other service environments, such as the 3GPP network and some SIP 1103 scenarios, there is a substantial decoupling between registration/ 1104 access to the network and the actual service request (i.e., the 1105 authentication/authorization is executed once at registration/access 1106 to the network and is not executed for every service event requested 1107 by the subscriber). In these environments, it is more appropriate to 1108 perform the first interrogation after the user has been authenticated 1109 and authorized. The first, the intermediate, and the final 1110 interrogations are executed with credit-control commands defined in 1111 this specification. 1113 Other IETF standards or standards developed by other standardization 1114 bodies may define the most suitable method in their architectures. 1116 5.2.1. First Interrogation after Authorization and Authentication 1118 The Diameter credit-control client in the service element may get 1119 information from the authorization server as to whether credit- 1120 control is required, based on its knowledge of the end user. If 1121 credit-control is required the credit-control server needs to be 1122 contacted prior to initiating service delivery to the end user. The 1123 accounting protocol and the credit-control protocol can be used in 1124 parallel. The authorization server may also determine whether the 1125 parallel accounting stream is required. 1127 The following diagram illustrates the case where both protocols are 1128 used in parallel and the service element sends credit-control 1129 messages directly to the credit-control server. More credit-control 1130 sequence examples are given in Annex A. 1132 Diameter 1133 End User Service Element AAA Server CC Server 1134 (CC Client) 1135 | Registration | AA request/answer(accounting,cc or both)| 1136 |<----------------->|<------------------>| | 1137 | : | | | 1138 | : | | | 1139 | Service Request | | | 1140 |------------------>| | | 1141 | | CCR(Initial,Credit-Control AVPs) | 1142 | +|---------------------------------------->| 1143 | CC stream|| | CCA(Granted-Units)| 1144 | +|<----------------------------------------| 1145 | Service Delivery | | | 1146 |<----------------->| ACR(start,Accounting AVPs) | 1147 | : |------------------->|+ | 1148 | : | ACA || Accounting stream | 1149 | |<-------------------|+ | 1150 | : | | | 1151 | : | | | 1152 | | CCR(Update,Used-Units) | 1153 | |---------------------------------------->| 1154 | | | CCA(Granted-Units)| 1155 | |<----------------------------------------| 1156 | : | | | 1157 | : | | | 1158 | End of Service | | | 1159 |------------------>| CCR(Termination, Used-Units) | 1160 | |---------------------------------------->| 1161 | | | CCA | 1162 | |<----------------------------------------| 1163 | | ACR(stop) | | 1164 | |------------------->| | 1165 | | ACA | | 1166 | |<-------------------| | 1168 Figure 3: Protocol example with first interrogation after user's 1169 authorization/authentication 1171 5.2.2. Authorization Messages for First Interrogation 1173 The Diameter credit-control client in the service element MUST 1174 actively co-operate with the authorization/authentication client in 1175 the construction of the AA request by adding appropriate credit- 1176 control AVPs. The credit-control client MUST add the Credit-Control 1177 AVP to indicate credit-control capabilities and MAY add other 1178 relevant credit-control specific AVPs to the proper authorization/ 1179 authentication command to perform the first interrogation toward the 1180 home Diameter AAA server. The Auth-Application-Id is set to the 1181 appropriate value, as defined in the relevant service specific 1182 authorization/authentication application document (e.g., [RFC7155], 1183 [RFC4004]). The home Diameter AAA server authenticates/authorizes 1184 the subscriber and determines whether credit-control is required. 1186 If credit-control is not required for the subscriber, the home 1187 Diameter AAA server will respond as usual, with an appropriate AA 1188 answer message. If credit-control is required for the subscriber and 1189 the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was 1190 present in the authorization request, the home AAA server MUST 1191 contact the credit-control server to perform the first interrogation. 1192 If credit-control is required for the subscriber and the Credit- 1193 Control AVP was not present in the authorization request, the home 1194 AAA server MUST send an authorization reject answer message. 1196 The Diameter AAA server supporting credit-control is required to send 1197 the Credit-Control-Request command (CCR) defined in this document to 1198 the credit-control server. The Diameter AAA server populates the CCR 1199 based on service specific AVPs used for input to the rating process, 1200 and possibly on credit-control AVPs received in the AA request. The 1201 credit-control server will reserve money from the user's account, 1202 will rate the request and will send a Credit-Control-Answer message 1203 to the home Diameter AAA server. The answer message includes the 1204 Granted-Service-Unit AVP(s) and MAY include other credit-control 1205 specific AVPs, as appropriate. Additionally, the credit-control 1206 server MAY set the Validity-Time and MAY include the Credit-Control- 1207 Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to 1208 determine what to do if the sending of credit-control messages to the 1209 credit-control server has been temporarily prevented. 1211 Upon receiving the Credit-Control-Answer message from the credit- 1212 control server, the home Diameter AAA server will populate the AA 1213 answer with the received credit-control AVPs and with the appropriate 1214 service attributes according to the authorization/authentication 1215 specific application (e.g., [RFC7155], [RFC4004]). It will then 1216 forward the packet to the credit-control client. If the home 1217 Diameter AAA server receives a credit-control reject message, it will 1218 simply generate an appropriate authorization reject message to the 1219 credit-control client, including the credit-control specific error 1220 code. 1222 In this model, the credit-control client sends further credit-control 1223 messages to the credit-control server via the home Diameter AAA 1224 server. Upon receiving a successful authorization answer message 1225 with the Granted-Service-Unit AVP(s), the credit-control client will 1226 grant the service to the end user and will generate an intermediate 1227 credit-control request, as required by using credit-control commands. 1229 The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 1230 (for how to produce unique value for the CC-Request-Number AVP, see 1231 Section 8.2). 1233 If service specific re-authorization is performed (i.e., 1234 authorization-lifetime expires), the credit-control client MUST add 1235 to the service specific re-authorization request the Credit-Control 1236 AVP with a value set to RE_AUTHORIZATION to indicate that the credit- 1237 control server MUST NOT be contacted. When session based credit- 1238 control is used for the subscriber, a constant credit-control message 1239 stream flows through the home Diameter AAA server. The home Diameter 1240 AAA server can make use of this credit-control message flow to deduce 1241 that the user's activity is ongoing; therefore, it is recommended to 1242 set the authorization-lifetime to a reasonably high value when 1243 credit-control is used for the subscriber. 1245 In this scenario, the home Diameter AAA server MUST advertise support 1246 for the credit-control application to its peers during the capability 1247 exchange process. 1249 The following diagram illustrates the use of authorization/ 1250 authentication messages to perform the first interrogation. The 1251 parallel accounting stream is not shown in the figure. 1253 Service Element Diameter 1254 End User (CC Client) AAA Server CC Server 1255 | Service Request | AA Request (CC AVPs) | 1256 |------------------>|------------------->| | 1257 | | | CCR(Initial, CC AVPs) 1258 | | |------------------->| 1259 | | | CCA(Granted-Units) 1260 | | |<-------------------| 1261 | | AA Answer(Granted-Units) | 1262 | Service Delivery |<-------------------| | 1263 |<----------------->| | | 1264 | : | | | 1265 | : | | | 1266 | : | | | 1267 | | | | 1268 | | CCR(Update,Used-Units) | 1269 | |------------------->| CCR(Update,Used-Units) 1270 | | |------------------->| 1271 | | | CCA(Granted-Units)| 1272 | | CCA(Granted-Units)|<-------------------| 1273 | |<-------------------| | 1274 | : | | | 1275 | : | | | 1276 | End of Service | | | 1277 |------------------>| CCR(Termination,Used-Units) | 1278 | |------------------->| CCR(Term.,Used-Units) 1279 | | |------------------->| 1280 | | | CCA | 1281 | | CCA |<-------------------| 1282 | |<-------------------| | 1284 Figure 4: Protocol example with use of the authorization messages for 1285 the first interrogation 1287 5.3. Intermediate Interrogation 1289 When all the granted service units for one unit type are spent by the 1290 end user or the Validity-Time is expired, the Diameter credit-control 1291 client MUST send a new Credit-Control-Request to the credit-control 1292 server. In the event that credit-control for multiple services is 1293 applied in one credit-control session (i.e., units associated to 1294 Service-Identifier(s) or Rating-Group are granted), a new Credit- 1295 Control-Request MUST be sent to the credit-control server when the 1296 credit reservation has been wholly consumed, or upon expiration of 1297 the Validity-Time. It is always up to the Diameter credit-control 1298 client to send a new request well in advance of the expiration of the 1299 previous request in order to avoid interruption in the service 1300 element. Even if the granted service units reserved by the credit- 1301 control server have not been spent upon expiration of the Validity- 1302 Time, the Diameter credit-control client MUST send a new Credit- 1303 Control-Request to the credit-control server. 1305 There can also be mid-session service events, which might affect the 1306 rating of the current service events. In this case, a spontaneous 1307 updating (a new Credit-Control-Request) SHOULD be sent including 1308 information related to the service event even if all the granted 1309 service units have not been spent or the Validity-Time has not 1310 expired. 1312 When the used units are reported to the credit-control server, the 1313 credit-control client will not have any units in its possession 1314 before new granted units are received from the credit-control server. 1315 When the new granted units are received, these units apply from the 1316 point where the measurement of the reported used units stopped. 1317 Where independent credit-control of multiple services is supported, 1318 this process may be executed for one or more services, a single 1319 rating-group, or a pool within the (sub)session. 1321 The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the 1322 intermediate request message. The Subscription-Id AVP or 1323 Subscription-Id-Extension AVP SHOULD be included in the intermediate 1324 message to identify the end user in the credit-control server. The 1325 Service-Context-Id AVP indicates the service specific document 1326 applicable to the request. 1328 The Requested-Service-Unit AVP MAY contain the new amount of 1329 requested service units. Where the Multiple-Services-Credit-Control 1330 AVP is used, it MUST contain the Requested-Service-Unit AVP if a new 1331 quota is requested for the associated service/rating-group. The 1332 Used-Service-Unit AVP contains the amount of used service units 1333 measured from the point when the service became active or, if interim 1334 interrogations are used during the session, from the point when the 1335 previous measurement ended. The same unit types used in the previous 1336 message SHOULD be used. If several unit types were included in the 1337 previous answer message, the used service units for each unit type 1338 MUST be reported. 1340 The Event-Timestamp AVP SHOULD be included in the request and 1341 contains the time of the event that triggered the sending of the new 1342 Credit-Control-Request. 1344 The credit-control server MUST deduct the used amount from the end 1345 user's account. It MAY rate the new request and make a new credit- 1346 reservation from the end user's account that covers the cost of the 1347 requested service event. 1349 A Credit-Control-Answer message with the CC-Request-Type AVP set to 1350 the value UPDATE_REQUEST MAY include the Cost-Information AVP 1351 containing the accumulated cost estimation for the session, without 1352 taking any credit-reservation into account. 1354 The Credit-Control-Answer message MAY also include the Final-Unit- 1355 Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that 1356 the answer message contains the final units for the service. After 1357 the end user has consumed these units, the Diameter credit-control- 1358 client MUST behave as described in Section 5.6. 1360 There can be several intermediate interrogations within a session. 1362 5.4. Final Interrogation 1364 When the end user terminates the service session, or when the 1365 graceful service termination described in Section 5.6 takes place, 1366 the Diameter credit-control client MUST send a final Credit-Control- 1367 Request message to the credit-control server. The CC-Request-Type 1368 AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id 1369 AVP indicates the service specific document applicable to the 1370 request. 1372 The Event-Timestamp AVP SHOULD be included in the request and 1373 contains the time when the session was terminated. 1375 The Used-Service-Unit AVP contains the amount of used service units 1376 measured from the point when the service became active or, if interim 1377 interrogations are used during the session, from the point when the 1378 previous measurement ended. If several unit types were included in 1379 the previous answer message, the used service units for each unit 1380 type MUST be reported. 1382 After final interrogation, the credit-control server MUST refund the 1383 reserved credit amount not used to the end user's account and deduct 1384 the used monetary amount from the end user's account. 1386 A Credit-Control-Answer message with the CC-Request-Type set to the 1387 value TERMINATION_REQUEST MAY include the Cost-Information AVP 1388 containing the estimated total cost for the session in question. 1390 If the user logs off during an ongoing credit-control session, or if 1391 some other reason causes the user to become logged off (e.g., final- 1392 unit indication causes user logoff according to local policy), the 1393 service element, according to application specific policy, may send a 1394 Session-Termination-Request (STR) to the home Diameter AAA server as 1395 usual [RFC6733]. Figure 5 illustrates the case when the final-unit 1396 indication causes user logoff upon consumption of the final granted 1397 units and the generation of STR. 1399 Service Element AAA Server CC Server 1400 End User (CC Client) 1401 | Service Delivery | | | 1402 |<----------------->| | | 1403 | : | | | 1404 | : | | | 1405 | : | | | 1406 | | | | 1407 | | CCR(Update,Used-Units) | 1408 | |------------------->| CCR(Update,Used-Units) 1409 | | |------------------->| 1410 | | CCA(Final-Unit, Terminate) 1411 | CCA(Final-Unit, Terminate)|<-------------------| 1412 | |<-------------------| | 1413 | : | | | 1414 | : | | | 1415 | Disconnect user | | | 1416 |<------------------| CCR(Termination,Used-Units) | 1417 | |------------------->| CCR(Term.,Used-Units) 1418 | | |------------------->| 1419 | | | CCA | 1420 | | CCA |<-------------------| 1421 | |<-------------------| | 1422 | | STR | | 1423 | |------------------->| | 1424 | | STA | | 1425 | |<-------------------| | 1427 Figure 5: User disconnected due to exhausted account 1429 5.5. Server-Initiated Credit Re-Authorization 1431 The Diameter credit-control application supports server-initiated re- 1432 authorization. The credit-control server MAY optionally initiate the 1433 credit re-authorization by issuing a Re-Auth-Request (RAR) as defined 1434 in the Diameter base protocol [RFC6733]. The Auth-Application-Id in 1435 the RAR message is set to 4 to indicate Diameter Credit Control, and 1436 the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. 1438 Section 5.1.2 defines the feature to enable credit-control for 1439 multiple services within a single (sub-)session where the server can 1440 authorize credit usage at a different level of granularity. Further, 1441 the server may provide credit resources to multiple services or 1442 rating groups as a pool (see Section 5.1.2 for details and 1443 definitions). Therefore, the server, based on its service logic and 1444 its knowledge of the ongoing session, can decide to request credit 1445 re-authorization for a whole (sub-)session, a single credit pool, a 1446 single service, or a single rating-group. To request credit re- 1447 authorization for a credit pool, the server includes in the RAR 1448 message the G-S-U-Pool-Identifier AVP indicating the affected pool. 1449 To request credit re-authorization for a service or a rating-group, 1450 the server includes in the RAR message the Service-Identifier AVP or 1451 the Rating-Group AVP, respectively. To request credit re- 1452 authorization for all the ongoing services within the (sub-)session, 1453 the server includes none of the above mentioned AVPs in the RAR 1454 message. 1456 If a credit re-authorization is not already ongoing (i.e., the 1457 credit-control session is in Open state), a credit control client 1458 that receives an RAR message with Session-Id equal to a currently 1459 active credit-control session MUST acknowledge the request by sending 1460 the Re-Auth-Answer (RAA) message and MUST initiate the credit re- 1461 authorization toward the server by sending a Credit-Control-Request 1462 message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. 1463 The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the 1464 RAA message to indicate that an additional message (i.e., CCR message 1465 with the value UPDATE_REQUEST) is required to complete the procedure. 1466 If a quota was allocated to the service, the credit-control client 1467 MUST report the used quota in the Credit-Control-Request. Note that 1468 the end user does not need to be prompted for the credit re- 1469 authorization, since the credit re-authorization is transparent to 1470 the user (i.e., it takes place exclusively between the credit-control 1471 client and the credit-control server). 1473 Where multiple services in a user's session are supported, the 1474 procedure in the above paragraph will be executed at the granularity 1475 requested by the server in the RAR message. 1477 If credit re-authorization is ongoing at the time when the RAR 1478 message is received (i.e., RAR-CCR collision), the credit-control 1479 client successfully acknowledges the request but does not initiate a 1480 new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) 1481 SHOULD be used in the RAA message to indicate that a credit re- 1482 authorization procedure is already ongoing (i.e., the client was in 1483 PendingU state when the RAR was received). The credit-control server 1484 SHOULD process the Credit-Control-Request as if it was received in 1485 answer to the server initiated credit re-authorization, and should 1486 consider the server initiated credit re-authorization process 1487 successful upon reception of the Re-Auth-Answer message. 1489 When multiple services are supported in a user's session, the server 1490 may request credit re-authorization for a credit pool (or for the 1491 (sub-)session) while a credit re-authorization is already ongoing for 1492 some of the services or rating-groups. In this case, the client 1493 acknowledges the server request with an RAA message and MUST send a 1494 new Credit-Control-Request message to perform re-authorization for 1495 the remaining services/rating-groups. The Result-Code 2002 1496 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to 1497 indicate that an additional message (i.e., CCR message with value 1498 UPDATE_REQUEST) is required to complete the procedure. The server 1499 processes the received requests and returns an appropriate answer to 1500 both requests. 1502 The above-defined procedures are enabled for each of the possibly 1503 active Diameter credit-control sub-sessions. The server MAY request 1504 re-authorization for an active sub-session by including the CC-Sub- 1505 Session-Id AVP in the RAR message in addition to the Session-Id AVP. 1507 5.6. Graceful Service Termination 1509 When the user's account runs out of money, the user may not be 1510 allowed to compile additional chargeable events. However, the home 1511 service provider may offer some services; for instance, access to a 1512 service portal where it is possible to refill the account, for which 1513 the user is allowed to benefit for a limited time. The length of 1514 this time is usually dependent on the home service provider policy. 1516 This section defines the optional graceful service termination 1517 feature that MAY be supported by the credit-control server. Credit- 1518 control client implementations MUST support the Final-Unit-Indication 1519 AVP or QoS-Final-Unit-Indication AVP with at least the teardown of 1520 the ongoing service session once the subscriber has consumed all the 1521 final granted units. 1523 Where independent credit-control of multiple services in a single 1524 credit-control (sub-)session is supported, it is possible to use the 1525 graceful service termination for each of the services/rating-groups 1526 independently. Naturally, the graceful service termination process 1527 defined in the following sub-sections will apply to the specific 1528 service/rating-group as requested by the server. 1530 In some service environments (e.g., NAS), the graceful service 1531 termination may be used to redirect the subscriber to a service 1532 portal for online balance refill or other services offered by the 1533 home service provider. In this case, the graceful termination 1534 process installs a set of packet filters to restrict the user's 1535 access capability only to/from the specified destinations. All the 1536 IP packets not matching the filters will be dropped or, possibly, re- 1537 directed to the service portal. The user may also be sent an 1538 appropriate notification as to why the access has been limited. 1539 These actions may be communicated explicitly from the server to the 1540 client or may be configured per-service at the client. Explicitly 1541 signaled redirect or restrict instructions always take precedence 1542 over configured ones. 1544 It is also possible use the graceful service termination to connect 1545 the prepaid user to a top-up server that plays an announcement and 1546 prompts the user to replenish the account. In this case, the credit- 1547 control server sends only the address of the top-up server where the 1548 prepaid user shall be connected after the final granted units have 1549 been consumed. An example of this is given Appendix B.7. 1551 The credit-control server MAY initiate the graceful service 1552 termination by including the Final-Unit-Indication AVP or the QoS- 1553 Final-Unit-Indication AVP in the Credit-Control-Answer to indicate 1554 that the message contains the final units for the service. 1556 When the credit-control client receives the Final-Unit-Indication AVP 1557 or the QoS-Final-Unit-Indication AVP in the answer from the server, 1558 its behavior depends on the value indicated in the Final-Unit-Action 1559 AVP. The server may request the following actions: TERMINATE, 1560 REDIRECT, or RESTRICT_ACCESS. 1562 The following figure illustrates the graceful service termination 1563 procedure described in the following sub-sections. 1565 Diameter 1566 End User Service Element AAA Server CC Server 1567 (CC Client) 1568 | Service Delivery | | | 1569 |<----------------->| | | 1570 | |CCR(Update,Used-Units) | 1571 | |------------------->|CCR(Update,Used-Units) 1572 | : | |------------------->| 1573 | : | |CCA(Final-Unit,Action) 1574 | : | |<-------------------| 1575 | |CCA(Final-Unit,Action) | 1576 | |<-------------------| | 1577 | | | | 1578 | : | | | 1579 | : | | | 1580 | : | | | 1581 | /////////////// |CCR(Update,Used-Units) | 1582 |/Final Units End/->|------------------->|CCR(Update,Used-Units) 1583 |/Action and // | |------------------->| 1584 |/Restrictions // | | CCA(Validity-Time)| 1585 |/Start // | CCA(Validity-Time)|<-------------------| 1586 | ///////////// |<-------------------| | 1587 | : | | | 1588 | : | | | 1589 | Replenish Account +-------+ | 1590 |<-------------------------------------------->|Account| | 1591 | | | +-------+ | 1592 | | | RAR | 1593 | + | RAR |<===================| 1594 | | |<===================| | 1595 | | | RAA | | 1596 | ///////////// | |===================>| RAA | 1597 | /If supported / | | CCR(Update) |===================>| 1598 | /by CC Server/ | |===================>| CCR(Update) | 1599 | ///////////// | | |===================>| 1600 | | | | CCA(Granted-Unit)| 1601 | | | CCA(Granted-Unit)|<===================| 1602 | Restrictions ->+ |<===================| | 1603 | removed | | | 1604 | : | | | 1605 | OR | CCR(Update) | | 1606 | Validity-Time ->|------------------->| CCR(Update) | 1607 | expires | |------------------->| 1608 | | | CCA(Granted-Unit)| 1609 | | CCA(Granted-Unit)|<-------------------| 1610 | Restrictions ->|<-------------------| | 1611 | removed | | | 1612 Figure 6: Optional graceful service termination procedure 1614 In addition, the credit-control server MAY reply with Final-Unit- 1615 Indication AVP or QoS-Final-Unit-Indication AVP holding a G-S-U AVP 1616 with a zero grant, indicating that the service SHOULD be terminated 1617 immediately, and no further reporting is required. A following 1618 figure illustrates a graceful service termination procedure that 1619 applies immediately after receiving a zero grant. 1621 Diameter 1622 End User Service Element AAA Server CC Server 1623 (CC Client) 1624 | Service Delivery | | | 1625 |<----------------->| | | 1626 | |CCR(Update,Used-Units) | 1627 | |------------------->|CCR(Update,Used-Units) 1628 | : | |------------------->| 1629 | : | |CCA(Final-Unit,Action, 1630 | : | | Zero G-S-U) 1631 | : | |<-------------------| 1632 | |CCA(Final-Unit,Action, | 1633 | | Zero G-S-U) | 1634 | |<-------------------| | 1635 | /////////////// | | | 1636 |/Action and // | | | 1637 |/Restrictions // | | | 1638 |/Start // | | | 1639 | ///////////// | | | 1640 | : | | | 1641 | : | | | 1643 Figure 7: Optional immediate graceful service termination procedure 1645 5.6.1. Terminate Action 1647 The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP 1648 with Final-Unit-Action TERMINATE does not include any other 1649 information. When the subscriber has consumed the final granted 1650 units, the service element MUST terminate the service. This is the 1651 default handling applicable whenever the credit-control client 1652 receives an unsupported Final-Unit-Action value and MUST be supported 1653 by all the Diameter credit-control client implementations conforming 1654 to this specification. A final Credit-Control-Request message to the 1655 credit-control server MUST be sent if the Final-Unit-Indication AVP 1656 or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was 1657 present at command level. The CC-Request-Type AVP in the request is 1658 set to the value TERMINATION_REQUEST. 1660 5.6.2. Redirect Action 1662 The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP 1663 with Final-Unit-Action REDIRECT indicates to the service element 1664 supporting this action that, upon consumption of the final granted 1665 units, the user MUST be re-directed to the address specified in the 1666 Redirect-Server AVP or Redirect-Server-Extension AVP as follows. 1668 The credit-control server sends the Redirect-Server AVP or Redirect- 1669 Server-Extension AVP in the Credit-Control-Answer message. In such a 1670 case, the service element MUST redirect or connect the user to the 1671 destination specified in the Redirect-Server AVP or Redirect-Server- 1672 Extension AVP, if possible. When the end user is redirected (by 1673 using protocols others than Diameter) to the specified server or 1674 connected to the top-up server, an additional authorization (and 1675 possibly authentication) may be needed before the subscriber can 1676 replenish the account; however, this is out of the scope of this 1677 specification. 1679 In addition to the Redirect-Server AVP or Redirect-Server-Extension 1680 AVP, the credit-control server MAY include one or more Restriction- 1681 Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more 1682 Filter-Id AVPs in the Credit-Control-Answer message to enable the 1683 user to access other services (for example, zero-rated services). In 1684 such a case, the access device MUST drop all the packets not matching 1685 the IP filters specified in the Restriction-Filter-Rule AVPs, Filter- 1686 Rule AVPs or Filter-Id AVPs. If enforcement actions other than 1687 allowing the packets (e.g., QoS), are indicated in the Filter-Rule 1688 AVPs or Filter-Id AVPs, they SHOULD be performed as well. In 1689 addition, if possible, to redirecting the user to the destination 1690 specified in the Redirect-Server AVP or Redirect-Server-Extension 1691 AVP. 1693 An entity other than the credit-control server may provision the 1694 access device with appropriate IP packet filters to be used in 1695 conjunction with the Diameter credit-control application. This case 1696 is considered in Section 5.6.3. 1698 When the final granted units have been consumed, the credit-control 1699 client MUST perform an intermediate interrogation. The purpose of 1700 this interrogation is to indicate to the credit-control server that 1701 the specified action started and to report the used units. The 1702 credit-control server MUST deduct the used amount from the end user's 1703 account but MUST NOT make a new credit reservation. The credit- 1704 control client, however, may send intermediate interrogations before 1705 all the final granted units have been consumed for which rating and 1706 money reservation may be needed; for instance, upon Validity-Time 1707 expires or upon mid-session service events that affect the rating of 1708 the current service. Therefore, the credit-control client MUST NOT 1709 include any rating related AVP in the request sent once all the final 1710 granted units have been consumed as an indication to the server that 1711 the requested final unit action started, rating and money reservation 1712 are not required (when the Multiple-Services-Credit-Control AVP is 1713 used, the Service-Identifier or Rating-Group AVPs is included to 1714 indicate the concerned services). Naturally, the Credit-Control- 1715 Answer message does not contain any granted service unit and MUST 1716 include the Validity-Time AVP to indicate to the credit-control 1717 client how long the subscriber is allowed to use network resources 1718 before a new intermediate interrogation is sent to the server. 1720 At the expiry of Validity-Time, the credit-control client sends a 1721 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does 1722 not include the Used-Service-Unit AVP, as there is no allotted quota 1723 to report. The credit-control server processes the request and MUST 1724 perform the credit reservation. If during this time the subscriber 1725 did not replenish his/her account, whether he/she will be 1726 disconnected or will be granted access to services not controlled by 1727 a credit-control server for an unlimited time is dependent on the 1728 home service provider policy (note: the latter option implies that 1729 the service element should not remove the restriction filters upon 1730 termination of the credit-control). The server will return the 1731 appropriate Result-Code (see Section 9.1) in the Credit-Control- 1732 Answer message in order to implement the policy-defined action. 1733 Otherwise, new quota will be returned, the service element MUST 1734 remove all the possible restrictions activated by the graceful 1735 service termination process and continue the credit-control session 1736 and service session as usual. 1738 The credit-control client may not wait until the expiration of the 1739 Validity-Time and may send a spontaneous update (a new Credit- 1740 Control-Request) if the service element can determine, for instance, 1741 that communication between the end user and the top-up server took 1742 place. An example of this is given in Appendix B.8 (Figure 18). 1744 Note that the credit-control server may already have initiated the 1745 above-described process for the first interrogation. However, the 1746 user's account might be empty when this first interrogation is 1747 performed. In this case, the subscriber can be offered a chance to 1748 replenish the account and continue the service. The credit-control 1749 client receives a Credit-Control-Answer or service specific 1750 authorization answer with the Final-Unit-Indication or the QoS-Final- 1751 Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- 1752 Unit AVP. It immediately starts the graceful service termination 1753 without sending any message to the server. An example of this case 1754 is illustrated in Appendix B. 1756 5.6.3. Restrict Access Action 1758 A Final-Unit-Indication AVP with the Final-Unit-Action 1759 RESTRICT_ACCESS indicates to the device supporting this action that, 1760 upon consumption of the final granted units, the user's access MUST 1761 be restricted according to the IP packet filters given in the 1762 Restriction-Filter-Rule AVP(s) or according to the IP packet filters 1763 identified by the Filter-Id AVP(s). The credit-control server SHOULD 1764 include either the Restriction-Filter-Rule AVP or the Filter-Id AVP 1765 in the Final-Unit-Indication group AVP of the Credit-Control-Answer 1766 message. 1768 A QoS-Final-Unit-Indication AVP with the Final-Unit-Action 1769 RESTRICT_ACCESS indicates to the device supporting this action that, 1770 upon consumption of the final granted units, the actions specified in 1771 Filter-Rule AVP(s) MUST restrict the traffic according to the 1772 classifiers in the Filter-Rule AVP(s). If Filter-Id AVP(s) are 1773 provided in the Credit-Control-Answer message, the credit control 1774 client MUST restrict the traffic according to the IP packet filters 1775 identified by the Filter-Id AVP(s). The credit-control server SHOULD 1776 include either the Filter-Rule AVP or the Filter-Id AVP in the QoS- 1777 Final-Unit-Indication group AVP of the Credit-Control-Answer message. 1779 If both Final-Unit-Indication AVP and QoS-Final-Unit-Indication AVP 1780 exist in the Credit-Control-Answer message, a credit control client 1781 which supports the QoS-Final-Unit-Indication AVP SHOULD follow the 1782 directives included in the QoS-Final-Unit-Indication AVP and SHOULD 1783 ignore the Final-Unit-Indication AVP. 1785 An entity other than the credit-control server may provision the 1786 access device with appropriate IP packet filters to be used in 1787 conjunction with the Diameter credit-control application. Such an 1788 entity may, for instance, configure the access device with IP flows 1789 to be passed when the Diameter credit-control application indicates 1790 RESTRICT_ACCESS or REDIRECT. The access device passes IP packets 1791 according to the filter rules that may have been received in the 1792 Credit-Control-Answer message in addition to those that may have been 1793 configured by the other entity. However, when the user's account 1794 cannot cover the cost of the requested service, the action taken is 1795 the responsibility of the credit-control server that controls the 1796 prepaid subscriber. 1798 If another entity working in conjunction with the Diameter credit- 1799 control application already provisions the access device with all the 1800 required filter rules for the end user, the credit-control server 1801 presumably need not send any additional filter. Therefore, it is 1802 RECOMMENDED that credit-control server implementations supporting the 1803 graceful service termination be configurable for sending the 1804 Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, 1805 or none of the above. 1807 When the final granted units have been consumed, the credit-control 1808 client MUST perform an intermediate interrogation. The credit- 1809 control client and the credit-control server process this 1810 intermediate interrogation and execute subsequent procedures, as 1811 specified in the previous section for the REDIRECT action. 1813 The credit-control server may initiate the graceful service 1814 termination with action RESTRICT_ACCESS already for the first 1815 interrogation, as specified in the previous section for the REDIRECT 1816 action. 1818 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 1820 Once the subscriber replenishes the account, she presumably expects 1821 all the restrictions placed by the graceful termination procedure to 1822 be removed immediately and unlimited service access to be resumed. 1823 For the best user experience, the credit-control server 1824 implementation MAY support the server-initiated credit re- 1825 authorization (see Section 5.5). In such a case, upon the successful 1826 account top-up, the credit-control server sends the Re-Auth-Request 1827 (RAR) message to solicit the credit re-authorization. The credit- 1828 control client initiates the credit re-authorization by sending the 1829 Credit-Control-Request message with the CC-Request-Type AVP set to 1830 the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included 1831 in the request, as there is no allotted quota to report. The 1832 Requested-Service-Unit AVP MAY be included in the request. After the 1833 credit-control client successfully receives the Credit-Control-Answer 1834 with new Granted-Service-Unit, all the possible restrictions 1835 activated for the purpose of the graceful service termination MUST be 1836 removed in the service element. The credit-control session and the 1837 service session continue as usual. 1839 5.7. Failure Procedures 1841 The Credit-Control-Failure-Handling AVP (CCFH), as described in this 1842 section, determines the behavior of the credit-control client in 1843 fault situations. The CCFH may be received from the Diameter home 1844 AAA server, from the credit-control server, or may be configured 1845 locally. The CCFH value received from the home AAA server overrides 1846 the locally configured value. The CCFH value received from the 1847 credit-control server in the Credit-Control-Answer message always 1848 overrides any existing value. 1850 The authorization server MAY include the Accounting-Realtime-Required 1851 AVP to determine what to do if the sending of accounting records to 1852 the accounting server has been temporarily prevented, as defined in 1853 [RFC6733]. It is RECOMMENDED that the client complement the credit- 1854 control failure procedures with backup accounting flow toward an 1855 accounting server. By using different combinations of Accounting- 1856 Realtime-Required and Credit-Control-Failure-Handling AVPs, different 1857 safety levels can be built. For example, by choosing a Credit- 1858 Control-Failure-Handling AVP equal to CONTINUE for the credit-control 1859 flow and an Accounting-Realtime-Required AVP equal to 1860 DELIVER_AND_GRANT for the accounting flow, the service can be granted 1861 to the end user even if the connection to the credit-control server 1862 is down, as long as the accounting server is able to collect the 1863 accounting information and information exchange is taking place 1864 between the accounting server and credit-control server. 1866 As the credit-control application is based on real-time bi- 1867 directional communication between the credit-control client and the 1868 credit-control server, the usage of alternative destinations and the 1869 buffering of messages may not be sufficient in the event of 1870 communication failures. Because the credit-control server has to 1871 maintain session states, moving the credit-control message stream to 1872 a backup server requires a complex context transfer solution. 1873 Whether the credit-control message stream is moved to a backup 1874 credit-control server during an ongoing credit-control session 1875 depends on the value of the CC-Session-Failover AVP. However, 1876 failover may occur at any point in the path between the credit- 1877 control client and the credit-control server if a transport failure 1878 is detected with a peer, as described in [RFC6733]. As a 1879 consequence, the credit-control server might receive duplicate 1880 messages. These duplicates or out of sequence messages can be 1881 detected in the credit-control server based on the credit-control 1882 server session state machine (Section 7), Session-Id AVP, and CC- 1883 Request-Number AVP. 1885 If a failure occurs during an ongoing credit-control session, the 1886 credit-control client may move the credit-control message stream to 1887 an alternative server if the CC-server indicated FAILOVER_SUPPORTED 1888 in the CC-Session-Failover AVP. A secondary credit-control server 1889 name, either received from the home Diameter AAA server or configured 1890 locally, can be used as an address of the backup server. If the CC- 1891 Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- 1892 control message stream MUST NOT be moved to a backup server. 1894 For new credit-control sessions, failover to an alternative credit- 1895 control server SHOULD be performed if possible. For instance, if an 1896 implementation of the credit-control client can determine primary 1897 credit-control server unavailability, it can establish the new 1898 credit-control sessions with a possibly available secondary credit- 1899 control server. 1901 The AAA transport profile [RFC3539] defines the application layer 1902 watchdog algorithm that enables failover from a peer that has failed 1903 and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The 1904 recommended default initial value for Tw (Twinit) is 30 seconds. 1905 Twinit may be set as low as 6 seconds; however, according to 1906 [RFC3539], setting too low a value for Twinit is likely to result in 1907 an increased probability of duplicates, as well as an increase in 1908 spurious failover and failback attempts. The Diameter base protocol 1909 is common to several different types of Diameter AAA applications 1910 that may be run in the same service element. Therefore, tuning the 1911 timer Twinit to a lower value in order to satisfy the requirements of 1912 real-time applications, such as the Diameter credit-control 1913 application, will certainly cause the above mentioned problems. For 1914 prepaid services, however, the end user expects an answer from the 1915 network in a reasonable time. Thus, the Diameter credit-control 1916 client will react faster than would the underlying base protocol. 1917 Therefore this specification defines the timer Tx that is used by the 1918 credit-control client (as defined in Section 13) to supervise the 1919 communication with the credit-control server. When the timer Tx 1920 elapses, the credit-control client takes an action to the end user 1921 according to the Credit-Control-Failure-Handling AVP. 1923 When Tx expires, the Diameter credit-control client always terminates 1924 the service if the Credit-Control-Failure-Handling (CCFH) AVP is set 1925 to the value TERMINATE. The credit-control session may be moved to 1926 an alternative server only if a protocol error DIAMETER_TOO_BUSY or 1927 DIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore, 1928 the value TERMINATE is not appropriate if proper failover behavior is 1929 desired. 1931 If the Credit-Control-Failure-Handling AVP is set to the value 1932 CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the 1933 end user when the timer Tx expires. An answer message with granted 1934 units may arrive later if the base protocol transport failover 1935 occurred in the path to the credit-control server. (The Twinit 1936 default value is 3 times more than the Tx recommended value.) The 1937 credit-control client SHOULD grant the service to the end user, start 1938 monitoring the resource usage, and wait for the possible late answer 1939 until the timeout of the request (e.g., 120 seconds). If the request 1940 fails and the CC-Session-Failover AVP is set to 1941 FAILOVER_NOT_SUPPORTED, the credit-control client terminates or 1942 continues the service depending on the value set in the CCFH and MUST 1943 free all the reserved resources for the credit-control session. If 1944 the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is 1945 received or the request times out and the CC-Session-Failover AVP is 1946 set to FAILOVER_SUPPORTED, the credit-control client MAY send the 1947 request to a backup server, if possible. If the credit-control 1948 client receives a successful answer from the backup server, it 1949 continues the credit-control session with such a server. If the re- 1950 transmitted request also fails, the credit-control client terminates 1951 or continues the service depending on the value set in the CCFH and 1952 MUST free all the reserved resources for the credit-control session. 1954 If a communication failure occurs during the graceful service 1955 termination procedure, the service element SHOULD always terminate 1956 the ongoing service session. 1958 If the credit-control server detects a failure during an ongoing 1959 credit-control session, it will terminate the credit-control session 1960 and return the reserved units back to the end user's account. 1962 The supervision session timer Tcc (as defined in Section 13) is used 1963 in the credit-control server to supervise the credit-control session. 1965 In order to support failover between credit-control servers, 1966 information transfer about the credit-control session and account 1967 state SHOULD take place between the primary and the secondary credit- 1968 control server. Implementations supporting the credit-control 1969 session failover MUST also ensure proper detection of duplicate or 1970 out of sequence messages. The communication between the servers is 1971 regarded as an implementation issue and is outside of the scope of 1972 this specification. 1974 6. One Time Event 1976 The one-time event is used when there is no need to maintain any 1977 state in the Diameter credit-control server; for example, enquiring 1978 about the price of the service. The use of a one-time event implies 1979 that the user has been authenticated and authorized beforehand. 1981 The one-time event can be used when the credit-control client wants 1982 to know the cost of the service event or to check the account balance 1983 without any credit-reservation. It can also be used for refunding 1984 service units on the user's account or for direct debiting without 1985 any credit-reservation. The one-time event is shown in Figure 8. 1987 Diameter 1988 End User Service Element AAA Server CC Server 1989 (CC Client) 1990 | Service Request | | | 1991 |------------------>| | | 1992 | | CCR(Event) | | 1993 | |------------------->| CCR(Event) | 1994 | | |------------------->| 1995 | | | CCA(Granted-Units)| 1996 | | CCA(Granted-Units)|<-------------------| 1997 | Service Delivery |<-------------------| | 1998 |<----------------->| | | 2000 Figure 8: One time event 2002 In environments such as the 3GPP architecture, the one-time event can 2003 be sent from the service element directly to the credit-control 2004 server. 2006 6.1. Service Price Enquiry 2008 The credit-control client may need to know the price of the services 2009 event. Services offered by application service providers whose 2010 prices are not known in the credit-control client might exist. The 2011 end user might also want to get an estimation of the price of a 2012 service event before requesting it. 2014 A Diameter credit-control client requesting the cost information MUST 2015 set the CC-Request-Type AVP equal to EVENT_REQUEST, include the 2016 Requested-Action AVP set to PRICE_ENQUIRY, and set the requested 2017 service event information into the Service-Identifier AVP in the 2018 Credit-Control-Request message. Additional service event information 2019 may be sent as service specific AVPs or within the Service-Parameter- 2020 Info AVP. The Service-Context-Id AVP indicates the service specific 2021 document applicable to the request. 2023 The credit-control server calculates the cost of the requested 2024 service event, but it does not perform any account balance check or 2025 credit-reservation from the account. 2027 The estimated cost of the requested service event is returned to the 2028 credit-control client in the Cost-Information AVP in the Credit- 2029 Control-Answer message. 2031 6.2. Balance Check 2033 The Diameter credit-control client may only have to verify that the 2034 end user's account balance covers the cost of a certain service 2035 without reserving any units from the account at the time of the 2036 inquiry. This method does not guarantee that credit would be left 2037 when the Diameter credit-control client requests the debiting of the 2038 account with a separate request. 2040 A Diameter credit-control client requesting the balance check MUST 2041 set the CC-Request-Type AVP equal to EVENT_REQUEST, include a 2042 Requested-Action AVP set to CHECK_BALANCE, and include the 2043 Subscription-Id AVP or Subscription-Id-Extension AVP in order to 2044 identify the end user in the credit-control server. The Service- 2045 Context-Id AVP indicates the service specific document applicable to 2046 the request. 2048 The credit-control server makes the balance check, but it does not 2049 make any credit-reservation from the account. 2051 The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to 2052 the credit-control client in the Check-Balance-Result AVP in the 2053 Credit-Control-Answer message. 2055 6.3. Direct Debiting 2057 There are certain service events for which service execution is 2058 always successful in the service environment. The delay between the 2059 service invocation and the actual service delivery to the end user 2060 can be sufficiently long that the use of the session-based credit- 2061 control would lead to unreasonably long credit-control sessions. In 2062 these cases, the Diameter credit-control client can use the one-time 2063 event scenario for direct debiting. The Diameter credit-control 2064 client SHOULD be sure that the requested service event execution 2065 would be successful when this scenario is used. 2067 In the Credit-Control-Request message, the CC-Request-Type is set to 2068 the value EVENT_REQUEST and the Requested-Action AVP is set to 2069 DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id- 2070 Extension AVP SHOULD be included to identify the end user in the 2071 credit-control server. The Event-Timestamp AVP SHOULD be included in 2072 the request and contain the time when the service event is requested 2073 in the service element. The Service-Context-Id AVP indicates the 2074 service specific document applicable to the request. 2076 The Diameter credit-control client MAY include the monetary amount to 2077 be charged in the Requested-Service-Unit AVP, if it knows the cost of 2078 the service event. If the Diameter credit-control client does not 2079 know the cost of the service event, the Requested-Service-Unit AVP 2080 MAY contain the number of requested service events. The Service- 2081 Identifier AVP always indicates the service concerned. Additional 2082 service event information to be rated MAY be sent as service specific 2083 AVPs or within the Service-Parameter-Info AVP. 2085 The credit-control server SHOULD rate the service event and deduct 2086 the corresponding monetary amount from the end user's account. If 2087 the type of the Requested-Service-Unit AVP is money, no rating is 2088 needed, but the corresponding monetary amount is deducted from the 2089 end user's account. 2091 The credit-control server returns the Granted-Service-Unit AVP in the 2092 Credit-Control-Answer message to the Diameter credit-control client. 2093 The Granted-Service-Unit AVP contains the amount of service units 2094 that the Diameter credit-control client can provide to the end user. 2095 The type of the Granted-Service-Unit can be time, volume, service 2096 specific, or money, depending on the type of service event. 2098 If the credit-control server determines that no credit-control is 2099 needed for the service, it can include the result code indicating 2100 that the credit-control is not applicable (e.g., service is free of 2101 charge). 2103 For informative purposes, the Credit-Control-Answer message MAY also 2104 include the Cost-Information AVP containing the estimated total cost 2105 of the requested service. 2107 6.4. Refund 2109 Some services may refund service units to the end user's account; for 2110 example, gaming services. 2112 The credit-control client MUST set CC-Request-Type to the value 2113 EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the 2114 Credit-Control-Request message. The Subscription-Id AVP or 2115 Subscription-Id-Extension AVP SHOULD be included to identify the end 2116 user in the credit-control server. The Service-Context-Id AVP 2117 indicates the service specific document applicable to the request. 2119 The Diameter credit-control client MAY include the monetary amount to 2120 be refunded in the Requested-Service-Unit AVP. The Service- 2121 Identifier AVP always indicates the concerned service. If the 2122 Diameter credit-control client does not know the monetary amount to 2123 be refunded, in addition to the Service-Identifier AVP it MAY send 2124 service specific AVPs or the Service-Parameter-Info AVP containing 2125 additional service event information to be rated. 2127 For informative purposes, the Credit-Control-Answer message MAY also 2128 include the Cost-Information AVP containing the estimated monetary 2129 amount of refunded unit. 2131 6.5. Failure Procedure 2133 Failover to an alternative credit-control server is allowed for a one 2134 time event, as the server is not maintaining session states. For 2135 instance, if the credit-control client receives a protocol error 2136 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the 2137 request to an alternative server, if possible. There MAY be protocol 2138 transparent Diameter relays and redirect agents or Diameter credit- 2139 control proxies between the credit-control client and credit-control 2140 server. Failover may occur at any point in the path between the 2141 credit-control client and the credit-control server if a transport 2142 failure is detected with a peer, as described in [RFC6733]. Because 2143 there can be duplicate requests for various reasons, the credit- 2144 control server is responsible for real time duplicate detection. 2145 Implementation issues for duplicate detection are discussed in 2146 [RFC6733], Appendix C. 2148 When the credit-control client detects a communication failure with 2149 the credit-control server, its behavior depends on the requested 2150 action. The timer Tx (as defined in Section 13) is used in the 2151 credit-control client to supervise the communication with the credit- 2152 control server. 2154 If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and 2155 communication failure is detected, the credit-control client SHOULD 2156 forward the request messages to an alternative credit-control server, 2157 if possible. The secondary credit-control server name, if received 2158 from the home Diameter AAA server, can be used as an address of 2159 backup server. 2161 If the requested action is DIRECT_DEBITING, the Direct-Debiting- 2162 Failure-Handling AVP (DDFH) controls the credit-control client's 2163 behavior. The DDFH may be received from the home Diameter AAA server 2164 or may be locally configured. The credit-control server may also 2165 send the DDFH in any CCA message to be used for direct debiting 2166 events compiled thereafter. The DDFH value received from the home 2167 Diameter AAA server overrides the locally configured value, and the 2168 DDFH value received from the credit-control server in a Credit- 2169 Control-Answer message always overrides any existing value. 2171 If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client 2172 SHOULD NOT grant the service if it can determine, eventually after a 2173 possible re-transmission attempt to an alternative credit-control 2174 server, from the result code or error code in the answer message that 2175 units have not been debited. Otherwise, the credit-control client 2176 SHOULD grant the service to the end user and store the request in the 2177 credit-control application level non-volatile storage. (Note that 2178 re-sending the request at a later time is not a guarantee that the 2179 service will be debited, as the user's account may be empty when the 2180 server successfully processes the request.) The credit-control 2181 client MUST mark these request messages as possible duplicates by 2182 setting the T-flag in the command header as described in [RFC6733], 2183 Section 3. 2185 If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 2186 service SHOULD be granted, even if credit-control messages cannot be 2187 delivered and messages are not buffered. 2189 If the timer Tx expires, the credit-control client MUST continue the 2190 service and wait for a possible late answer. If the request times 2191 out, the credit-control client re-transmits the request (marked with 2192 T-flag) to a backup credit-control server, if possible. If the re- 2193 transmitted request also times out, or if a temporary error is 2194 received in answer, the credit-control client buffers the request if 2195 the value of the Direct-Debiting-Failure-Handling AVP is set to 2196 TERMINATE_OR_BUFFER. If a failed answer is received for the re- 2197 transmitted request, the credit-control client frees all the 2198 resources reserved for the event message and deletes the request 2199 regardless of the value of the DDFH. 2201 The Credit-Control-Request with the requested action REFUND_ACCOUNT 2202 should always be stored in the credit-control application level non- 2203 volatile storage in case of temporary failure. The credit-control 2204 client MUST mark the re-transmitted request message as a possible 2205 duplicate by setting the T-flag in the command header as described in 2206 [RFC6733], Section 3. 2208 For stored requests, the implementation may choose to limit the 2209 number of re-transmission attempts and to define a re-transmission 2210 interval. 2212 Note that only one place in the credit-control system SHOULD be 2213 responsible for duplicate detection. If there is only one credit- 2214 control server within the given realm, the credit-control server may 2215 perform duplicate detection. If there is more than one credit- 2216 control server in a given realm, only one entity in the credit- 2217 control system should be responsible, to ensure that the end user's 2218 account is not debited or credited multiple times for the same 2219 service event. 2221 7. Credit-Control Application State Machine 2223 This section defines the credit-control application state machine. 2225 The first four state machines are to be observed by credit-control 2226 clients. The first one describes the session-based credit-control 2227 when the first interrogation is executed as part of the 2228 authorization/authentication process. The second describes the 2229 session-based credit-control when the first interrogation is executed 2230 after the authorization/authentication process. The requirements as 2231 to what state machines have to be supported are discussed in 2232 Section 5.2. 2234 The third state machine describes the session-based credit-control 2235 for the intermediate and final interrogations. The fourth one 2236 describes the event-based credit-control. These latter state 2237 machines are to be observed by all implementations that conform to 2238 this specification. 2240 The fifth state machine describes the credit-control session from a 2241 credit-control server perspective. 2243 Any event not listed in the state machines MUST be considered an 2244 error condition, and a corresponding answer, if applicable, MUST be 2245 returned to the originator of the message. 2247 In the state table, the event 'Failure to send' means that the 2248 Diameter credit-control client is unable to communicate with the 2249 desired destination or, if failover procedure is supported, with a 2250 possibly defined alternative destination (e.g., the request times out 2251 and the answer message is not received). This could be due to the 2252 peer being down, or due to a physical link failure in the path to or 2253 from the credit-control server. 2255 The event 'Temporary error' means that the Diameter credit-control 2256 client received a protocol error notification (DIAMETER_TOO_BUSY, 2257 DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result- 2258 Code AVP of the Credit-Control-Answer command. The above protocol 2259 error notification may ultimately be received in answer to the re- 2260 transmitted request to a defined alternative destination, if failover 2261 is supported. 2263 The event 'Failed answer' means that the Diameter credit-control 2264 client received non-transient failure (permanent failure) 2265 notification in the Credit-Control-Answer command. The above 2266 permanent failure notification may ultimately be received in answer 2267 to the re-transmitted request to a defined alternative destination, 2268 if failover is supported. 2270 The action 'store request' means that a request is stored in the 2271 credit-control application level non-volatile storage. 2273 The event 'Not successfully processed' means that the credit-control 2274 server could not process the message; e.g., due to an unknown end 2275 user, account being empty, or errors defined in [RFC6733]. 2277 The event 'User service terminated' can be triggered by various 2278 reasons, e.g., normal user termination, network failure, and ASR 2279 (Abort-Session-Request). The Termination-Cause AVP contains 2280 information about the termination reason, as specified in [RFC6733]. 2282 The Tx timer, which is used to control the waiting time in the 2283 credit-control client in the Pending state, is stopped upon exit of 2284 the Pending state. The stopping of the Tx timer is omitted in the 2285 state machine when the new state is Idle, as moving to Idle state 2286 implies the clearing of the session and all the variables associated 2287 to it. 2289 The states PendingI, PendingU, PendingT, PendingE, and PendingB stand 2290 for pending states to wait for an answer to a credit-control request 2291 related to Initial, Update, Termination, Event, or Buffered request, 2292 respectively. 2294 The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling 2295 and Direct-Debiting-Failure-Handling, respectively. 2297 In the following state machine table, the failover to a secondary 2298 server upon 'Temporary error' or 'Failure to send' is not explicitly 2299 described. Moving an ongoing credit-control message stream to an 2300 alternative server is, however, possible if the CC-Session-Failover 2301 AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7. 2303 Re-sending a credit-control event to an alternative server is 2304 supported as described in Section 6.5. 2306 +----------+-------------------------------+-------------+----------+ 2307 | State | Event | Action | New | 2308 | | | | State | 2309 +----------+-------------------------------+-------------+----------+ 2310 | Idle | Client or device requests | Send AA | PendingI | 2311 | | access/service | request | | 2312 | | | with added | | 2313 | | | CC AVPs, | | 2314 | | | start Tx | | 2315 | PendingI | Successful AA req. answer | Grant | Open | 2316 | | received | service to | | 2317 | | | end user, | | 2318 | | | stop Tx | | 2319 | PendingI | Tx expired | Disconnect | Idle | 2320 | | | user/dev | | 2321 | PendingI | Failed AA answer received | Disconnect | Idle | 2322 | | | user/dev | | 2323 | PendingI | AA answer received with | Grant | Idle | 2324 | | result code equal to | service to | | 2325 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2326 | PendingI | User service terminated | Queue | PendingI | 2327 | | | termination | | 2328 | | | event | | 2329 | PendingI | Change in rating condition | Queue | PendingI | 2330 | | | changed | | 2331 | | | rating | | 2332 | | | condition | | 2333 | | | event | | 2334 +----------+-------------------------------+-------------+----------+ 2336 Table 2: CLIENT, SESSION BASED for the first interrogation with AA 2337 request 2339 +----------+-------------------------------+-------------+----------+ 2340 | State | Event | Action | New | 2341 | | | | State | 2342 +----------+-------------------------------+-------------+----------+ 2343 | Idle | Client or device requests | Send CC | PendingI | 2344 | | access/service | initial | | 2345 | | | req., start | | 2346 | | | Tx | | 2347 | PendingI | Successful CC initial answer | Stop Tx | Open | 2348 | | received | | | 2349 | PendingI | Failure to send, or temporary | Grant | Idle | 2350 | | error and CCFH equal to | service to | | 2351 | | CONTINUE | end user | | 2352 | PendingI | Failure to send, or temporary | Terminate | Idle | 2353 | | error and CCFH equal to | end user's | | 2354 | | TERMINATE or to | service | | 2355 | | RETRY_AND_TERMINATE | | | 2356 | PendingI | Tx expired and CCFH equal to | Terminate | Idle | 2357 | | TERMINATE | end user's | | 2358 | | | service | | 2359 | PendingI | Tx expired and CCFH equal to | Grant | PendingI | 2360 | | CONTINUE or to | service to | | 2361 | | RETRY_AND_TERMINATE | end user | | 2362 | PendingI | CC initial answer received | Terminate | Idle | 2363 | | with result code | end user's | | 2364 | | END_USER_SERVICE_DENIED or | service | | 2365 | | USER_UNKNOWN | | | 2366 | PendingI | CC initial answer received | Grant | Idle | 2367 | | with result code equal to | service to | | 2368 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2369 | PendingI | Failed CC initial answer | Grant | Idle | 2370 | | received and CCFH equal to | service to | | 2371 | | CONTINUE | end user | | 2372 | PendingI | Failed CC initial answer | Terminate | Idle | 2373 | | received and CCFH equal to | end user's | | 2374 | | TERMINATE or to | service | | 2375 | | RETRY_AND_TERMINATE | | | 2376 | PendingI | User service terminated | Queue | PendingI | 2377 | | | termination | | 2378 | | | event | | 2379 | PendingI | Change in rating condition | Queue | PendingI | 2380 | | | changed | | 2381 | | | rating | | 2382 | | | condition | | 2383 | | | event | | 2384 +----------+-------------------------------+-------------+----------+ 2386 Table 3: CLIENT, SESSION BASED for the first interrogation with CCR 2388 +----------+-------------------------------+-------------+----------+ 2389 | State | Event | Action | New | 2390 | | | | State | 2391 +----------+-------------------------------+-------------+----------+ 2392 | Open | Granted unit elapses and no | Send CC | PendingU | 2393 | | final unit indication | update | | 2394 | | received | req., start | | 2395 | | | Tx | | 2396 | Open | Granted unit elapses and | Terminate | PendingT | 2397 | | final unit action equal to | end user's | | 2398 | | TERMINATE received | service, | | 2399 | | | send CC | | 2400 | | | termination | | 2401 | | | req. | | 2402 | Open | Change in rating condition in | Send CC | PendingU | 2403 | | queue | update | | 2404 | | | req., Start | | 2405 | | | Tx | | 2406 | Open | Service terminated in queue | Send CC | PendingT | 2407 | | | termination | | 2408 | | | req. | | 2409 | Open | Change in rating condition or | Send CC | PendingU | 2410 | | Validity-Time elapses | update | | 2411 | | | req., Start | | 2412 | | | Tx | | 2413 | Open | User service terminated | Send CC | PendingT | 2414 | | | termination | | 2415 | | | req. | | 2416 | Open | RAR received | Send RAA | PendingU | 2417 | | | followed by | | 2418 | | | CC update | | 2419 | | | req., start | | 2420 | | | Tx | | 2421 | PendingU | Successful CC update answer | Stop Tx | Open | 2422 | | received | | | 2423 | PendingU | Failure to send, or temporary | Grant | Idle | 2424 | | error and CCFH equal to | service to | | 2425 | | CONTINUE | end user | | 2426 | PendingU | Failure to send, or temporary | Terminate | Idle | 2427 | | error and CCFH equal to | end user's | | 2428 | | TERMINATE or to | service | | 2429 | | RETRY_AND_TERMINATE | | | 2430 | PendingU | Tx expired and CCFH equal to | Terminate | Idle | 2431 | | TERMINATE | end user's | | 2432 | | | service | | 2433 | PendingU | Tx expired and CCFH equal to | Grant | PendingU | 2434 | | CONTINUE or to | service to | | 2435 | | RETRY_AND_TERMINATE | end user | | 2436 | PendingU | CC update answer received | Terminate | Idle | 2437 | | with result code | end user's | | 2438 | | END_USER_SERVICE_DENIED | service | | 2439 | PendingU | CC update answer received | Grant | Idle | 2440 | | with result code equal to | service to | | 2441 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2442 | PendingU | Failed CC update answer | Grant | Idle | 2443 | | received and CCFH equal to | service to | | 2444 | | CONTINUE | end user | | 2445 | PendingU | Failed CC update answer | Terminate | Idle | 2446 | | received and CCFH equal to | end user's | | 2447 | | TERMINATE or to | service | | 2448 | | RETRY_AND_TERMINATE | | | 2449 | PendingU | User service terminated | Queue | PendingU | 2450 | | | termination | | 2451 | | | event | | 2452 | PendingU | Change in rating condition | Queue | PendingU | 2453 | | | changed | | 2454 | | | rating | | 2455 | | | condition | | 2456 | | | event | | 2457 | PendingU | RAR received | Send RAA | PendingU | 2458 | PendingT | Successful CC termination | | Idle | 2459 | | answer received | | | 2460 | PendingT | Failure to send, temporary | | Idle | 2461 | | error, or failed answer | | | 2462 | PendingT | Change in rating condition | | PendingT | 2463 +----------+-------------------------------+-------------+----------+ 2465 Table 4: CLIENT, SESSION BASED for intermediate and final 2466 interrogations 2468 +----------+--------------------------------+------------+----------+ 2469 | State | Event | Action | New | 2470 | | | | State | 2471 +----------+--------------------------------+------------+----------+ 2472 | Idle | Client or device requests a | Send CC | PendingE | 2473 | | one-time service | event | | 2474 | | | req., | | 2475 | | | Start Tx | | 2476 | Idle | Request in storage | Send | PendingB | 2477 | | | stored | | 2478 | | | request | | 2479 | PendingE | Successful CC event answer | Grant | Idle | 2480 | | received | service to | | 2481 | | | end user | | 2482 | PendingE | Failure to send, temporary | Indicate | Idle | 2483 | | error, failed CC event answer | service | | 2484 | | received, or Tx expired; | error | | 2485 | | requested action CHECK_BALANCE | | | 2486 | | or PRICE_ENQUIRY | | | 2487 | PendingE | CC event answer received with | Terminate | Idle | 2488 | | result code | end user's | | 2489 | | END_USER_SERVICE_DENIED or | service | | 2490 | | USER_UNKNOWN and Tx running | | | 2491 | PendingE | CC event answer received with | Grant | Idle | 2492 | | result code | service to | | 2493 | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | | 2494 | | requested action | | | 2495 | | DIRECT_DEBITING | | | 2496 | PendingE | Failure to send, temporary | Grant | Idle | 2497 | | error, failed CC event answer | service to | | 2498 | | received; requested action | end user | | 2499 | | DIRECT_DEBITING; DDFH equal to | | | 2500 | | CONTINUE | | | 2501 | PendingE | Failed CC event answer | Terminate | Idle | 2502 | | received or temporary error; | end user's | | 2503 | | requested action | service | | 2504 | | DIRECT_DEBITING; DDFH equal to | | | 2505 | | TERMINATE_OR_BUFFER and Tx | | | 2506 | | running | | | 2507 | PendingE | Tx expired; requested action | Grant | PendingE | 2508 | | DIRECT_DEBITING | service to | | 2509 | | | end user | | 2510 | PendingE | Failure to send; requested | Store | Idle | 2511 | | action DIRECT_DEBITING; DDFH | request | | 2512 | | equal to TERMINATE_OR_BUFFER | with | | 2513 | | | T-flag | | 2514 | PendingE | Temporary error; requested | Store | Idle | 2515 | | action DIRECT_DEBITING; DDFH | request | | 2516 | | equal to TERMINATE_OR_BUFFER; | | | 2517 | | Tx expired | | | 2518 | PendingE | Failed answer or answer | | Idle | 2519 | | received with result code | | | 2520 | | END_USER_SERVICE DENIED or | | | 2521 | | USER_UNKNOWN; requested action | | | 2522 | | DIRECT_DEBITING; Tx expired | | | 2523 | PendingE | Failed CC event answer | Indicate | Idle | 2524 | | received; requested action | service | | 2525 | | REFUND_ACCOUNT | error and | | 2526 | | | delete | | 2527 | | | request | | 2528 | PendingE | Failure to send or Tx expired; | Store | Idle | 2529 | | requested action | request | | 2530 | | REFUND_ACCOUNT | with | | 2531 | | | T-flag | | 2532 | PendingE | Temporary error, and requested | Store | Idle | 2533 | | action REFUND_ACCOUNT | request | | 2534 | PendingB | Successful CC answer received | Delete | Idle | 2535 | | | request | | 2536 | PendingB | Failed CC answer received | Delete | Idle | 2537 | | | request | | 2538 | PendingB | Failure to send or temporary | | Idle | 2539 | | error | | | 2540 +----------+--------------------------------+------------+----------+ 2542 Table 5: CLIENT, EVENT BASED 2544 +-------+------------------------+--------------------------+-------+ 2545 | State | Event | Action | New | 2546 | | | | State | 2547 +-------+------------------------+--------------------------+-------+ 2548 | Idle | CC initial request | Send CC initial answer, | Open | 2549 | | received and | reserve units, start Tcc | | 2550 | | successfully processed | | | 2551 | Idle | CC initial request | Send CC initial answer | Idle | 2552 | | received but not | with Result-Code != | | 2553 | | successfully processed | SUCCESS | | 2554 | Idle | CC event request | Send CC event answer | Idle | 2555 | | received and | | | 2556 | | successfully processed | | | 2557 | Idle | CC event request | Send CC event answer | Idle | 2558 | | received but not | with Result-Code != | | 2559 | | successfully processed | SUCCESS | | 2560 | Open | CC update request | Send CC update answer, | Open | 2561 | | received and | debit used units, | | 2562 | | successfully processed | reserve new units, | | 2563 | | | restart Tcc | | 2564 | Open | CC update request | Send CC update answer | Idle | 2565 | | received but not | with Result-Code != | | 2566 | | successfully processed | SUCCESS, debit used | | 2567 | | | units | | 2568 | Open | CC termination request | Send CC termin. answer, | Idle | 2569 | | received and | Stop Tcc, debit used | | 2570 | | successfully processed | units | | 2571 | Open | CC termination request | Send CC termin. answer | Idle | 2572 | | received but not | with Result-Code != | | 2573 | | successfully processed | SUCCESS, debit used | | 2574 | | | units | | 2575 | Open | Session supervision | Release reserved units | Idle | 2576 | | timer Tcc expired | | | 2577 +-------+------------------------+--------------------------+-------+ 2579 Table 6: SERVER, SESSION AND EVENT BASED 2581 8. Credit-Control AVPs 2583 This section defines the credit-control AVPs that are specific to 2584 Diameter credit-control application and that MAY be included in the 2585 Diameter credit-control messages. 2587 The AVPs defined in this section MAY also be included in 2588 authorization commands defined in authorization-specific 2589 applications, such as [RFC7155] and [RFC4004], if the first 2590 interrogation is performed as part of the authorization/ 2591 authentication process, as described in Section 5.2. 2593 The Diameter AVP rules are defined in the Diameter Base [RFC6733], 2594 Section 4. These AVP rules are observed in AVPs defined in this 2595 section. 2597 The following table describes the Diameter AVPs defined in the 2598 credit-control application, their AVP Code values, types, and 2599 possible flag values. The AVP Flag rules are explained in the 2600 Diameter base [RFC6733], section 4.1. 2602 +---------------+ 2603 |AVP Flag rules | 2604 |----+-----+----| 2605 AVP Section | | |MUST| 2606 Attribute Name Code Defined Data Type |MUST| MAY |NOT | 2607 -----------------------------------------|----+-----+----| 2608 CC-Correlation-Id 411 8.1 OctetString| | M | V | 2609 CC-Input-Octets 412 8.24 Unsigned64 | M | | V | 2610 CC-Money 413 8.22 Grouped | M | | V | 2611 CC-Output-Octets 414 8.25 Unsigned64 | M | | V | 2612 CC-Request-Number 415 8.2 Unsigned32 | M | | V | 2613 CC-Request-Type 416 8.3 Enumerated | M | | V | 2614 CC-Service- 417 8.26 Unsigned64 | M | | V | 2615 Specific-Units | | | | 2616 CC-Session- 418 8.4 Enumerated | M | | V | 2617 Failover | | | | 2618 CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V | 2619 CC-Time 420 8.21 Unsigned32 | M | | V | 2620 CC-Total-Octets 421 8.23 Unsigned64 | M | | V | 2621 CC-Unit-Type 454 8.32 Enumerated | M | | V | 2622 Check-Balance- 422 8.6 Enumerated | M | | V | 2623 Result | | | | 2624 Cost-Information 423 8.7 Grouped | M | | V | 2625 Cost-Unit 424 8.12 UTF8String | M | | V | 2626 Credit-Control 426 8.13 Enumerated | M | | V | 2627 Credit-Control- 427 8.14 Enumerated | M | | V | 2628 Failure-Handling | | | | 2630 Currency-Code 425 8.11 Unsigned32 | M | | V | 2631 Direct-Debiting- 428 8.15 Enumerated | M | | V | 2632 Failure-Handling | | | | 2633 Exponent 429 8.9 Integer32 | M | | V | 2634 Final-Unit-Action 449 8.35 Enumerated | M | | V | 2635 Final-Unit- 430 8.34 Grouped | M | | V | 2636 Indication | | | | 2637 QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | 2638 Indication | | | | 2639 Granted-Service- 431 8.17 Grouped | M | | V | 2640 Unit | | | | 2641 G-S-U-Pool- 453 8.31 Unsigned32 | M | | V | 2642 Identifier | | | | 2643 G-S-U-Pool- 457 8.30 Grouped | M | | V | 2644 Reference | | | | 2645 Multiple-Services 456 8.16 Grouped | M | | V | 2646 -Credit-Control | | | | 2647 Multiple-Services 455 8.40 Enumerated | M | | V | 2648 -Indicator | | | | 2649 Rating-Group 432 8.29 Unsigned32 | M | | V | 2650 Redirect-Address 433 8.38 Enumerated | M | | V | 2651 -Type | | | | 2652 Redirect-Server 434 8.37 Grouped | M | | V | 2653 Redirect-Server 435 8.39 UTF8String | M | | V | 2654 -Address | | | | 2655 Redirect-Server TBD13 8.64 Grouped | | M | V | 2656 -Extension | | | | 2657 Redirect-Address TBD14 8.65 Address | | M | V | 2658 -IPAddress | | | | 2659 Redirect-Address TBD15 8.66 UTF8String | | M | V | 2660 -URL | | | | 2661 Redirect-Address TBD16 8.67 UTF8String | | M | V | 2662 -SIP-URI | | | | 2663 Requested-Action 436 8.41 Enumerated | M | | V | 2664 Requested-Service 437 8.18 Grouped | M | | V | 2665 -Unit | | | | 2666 Restriction 438 8.36 IPFiltrRule| M | | V | 2667 -Filter-Rule | | | | 2668 Service-Context 461 8.42 UTF8String | M | | V | 2669 -Id | | | | 2670 Service- 439 8.28 Unsigned32 | M | | V | 2671 Identifier | | | | 2672 Service-Parameter 440 8.43 Grouped | | M | V | 2673 -Info | | | | 2674 Service- 441 8.44 Unsigned32 | | M | V | 2675 Parameter-Type | | | | 2676 Service- 442 8.45 OctetString| | M | V | 2677 Parameter-Value | | | | 2679 Subscription-Id 443 8.46 Grouped | M | | V | 2680 Subscription-Id 444 8.48 UTF8String | M | | V | 2681 -Data | | | | 2682 Subscription-Id 450 8.47 Enumerated | M | | V | 2683 -Type | | | | 2684 Subscription-Id TBD7 8.58 Grouped | | M | V | 2685 -Extension | | | | 2686 Subscription-Id TBD8 8.59 UTF8String | | M | V | 2687 -E164 | | | | 2688 Subscription-Id TBD9 8.60 UTF8String | | M | V | 2689 -IMSI | | | | 2690 Subscription-Id TBD10 8.61 UTF8String | | M | V | 2691 -SIP-URI | | | | 2692 Subscription-Id TBD11 8.62 UTF8String | | M | V | 2693 -NAI | | | | 2694 Subscription-Id TBD12 8.63 UTF8String | | M | V | 2695 -Private | | | | 2696 Tariff-Change 452 8.27 Enumerated | M | | V | 2697 -Usage | | | | 2698 Tariff-Time 451 8.20 Time | M | | V | 2699 -Change | | | | 2700 Unit-Value 445 8.8 Grouped | M | | V | 2701 Used-Service-Unit 446 8.19 Grouped | M | | V | 2702 User-Equipment 458 8.49 Grouped | | M | V | 2703 -Info | | | | 2704 User-Equipment 459 8.50 Enumerated | | M | V | 2705 -Info-Type | | | | 2706 User-Equipment 460 8.51 OctetString| | M | V | 2707 -Info-Value | | | | 2708 User-Equipment TBD1 8.52 Grouped | | M | V | 2709 -Info-Extension | | | | 2710 User-Equipment TBD2 8.53 OctetString| | M | V | 2711 -Info-IMEISV | | | | 2712 User-Equipment TBD3 8.54 OctetString| | M | V | 2713 -Info-MAC | | | | 2714 User-Equipment TBD4 8.55 OctetString| | M | V | 2715 -Info-EUI64 | | | | 2716 User-Equipment TBD5 8.56 OctetString| | M | V | 2717 -Info-ModifiedEUI64 | | | | 2718 User-Equipment TBD6 8.57 OctetString| | M | V | 2719 -Info-IMEI | | | | 2720 Value-Digits 447 8.10 Integer64 | M | | V | 2721 Validity-Time 448 8.33 Unsigned32 | M | | V | 2723 8.1. CC-Correlation-Id AVP 2725 The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and 2726 contains information to correlate credit-control requests generated 2727 for different components of the service; e.g., transport and service 2728 level. The one who allocates the Service-Context-Id (i.e., unique 2729 identifier of a service specific document) is also responsible for 2730 defining the content and encoding of the CC-Correlation-Id AVP. 2732 8.2. CC-Request-Number AVP 2734 The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and 2735 identifies this request within one session. As Session-Id AVPs are 2736 globally unique, the combination of Session-Id and CC-Request-Number 2737 AVPs is also globally unique and can be used in matching credit- 2738 control messages with confirmations. An easy way to produce unique 2739 numbers is to set the value to 0 for a credit-control request of type 2740 INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the 2741 first UPDATE_REQUEST, to 2 for the second, and so on until the value 2742 for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST. 2744 8.3. CC-Request-Type AVP 2746 The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and 2747 contains the reason for sending the credit-control request message. 2748 It MUST be present in all Credit-Control-Request messages. The 2749 following values are defined for the CC-Request-Type AVP: 2751 INITIAL_REQUEST 1 2753 An Initial request is used to initiate a credit-control session, and 2754 contains credit control information that is relevant to the 2755 initiation. 2757 UPDATE_REQUEST 2 2759 An Update request contains credit-control information for an existing 2760 credit-control session. Update credit-control requests SHOULD be 2761 sent every time a credit-control re-authorization is needed at the 2762 expiry of the allocated quota or validity time. Further, additional 2763 service-specific events MAY trigger a spontaneous Update request. 2765 TERMINATION_REQUEST 3 2767 A Termination request is sent to terminate a credit-control session 2768 and contains credit-control information relevant to the existing 2769 session. 2771 EVENT_REQUEST 4 2773 An Event request is used when there is no need to maintain any 2774 credit-control session state in the credit-control server. This 2775 request contains all information relevant to the service, and is the 2776 only request of the service. The reason for the Event request is 2777 further detailed in the Requested-Action AVP. The Requested-Action 2778 AVP MUST be included in the Credit-Control-Request message when CC- 2779 Request-Type is set to EVENT_REQUEST. 2781 8.4. CC-Session-Failover AVP 2783 The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and 2784 contains information as to whether moving the credit-control message 2785 stream to a backup server during an ongoing credit-control session is 2786 supported. In communication failures, the credit-control message 2787 streams can be moved to an alternative destination if the credit- 2788 control server supports failover to an alternative server. The 2789 secondary credit-control server name, if received from the home 2790 Diameter AAA server, can be used as an address of the backup server. 2791 An implementation is not required to support moving a credit-control 2792 message stream to an alternative server, as this also requires moving 2793 information related to the credit-control session to backup server. 2795 The following values are defined for the CC-Session-Failover AVP: 2797 FAILOVER_NOT_SUPPORTED 0 2799 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, 2800 the credit-control message stream MUST NOT be moved to an alternative 2801 destination in the case of communication failure. This is the 2802 default behavior if the AVP isn't included in the reply from the 2803 authorization or credit-control server. 2805 FAILOVER_SUPPORTED 1 2807 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the 2808 credit-control message stream SHOULD be moved to an alternative 2809 destination in the case of communication failure. Moving the credit- 2810 control message stream to a backup server MAY require that 2811 information related to the credit-control session should also be 2812 forwarded to an alternative server. 2814 8.5. CC-Sub-Session-Id AVP 2816 The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and 2817 contains the credit-control sub-session identifier. The combination 2818 of the Session-Id and this AVP MUST be unique per sub-session, and 2819 the value of this AVP MUST be monotonically increased by one for all 2820 new sub-sessions. The absence of this AVP implies that no sub- 2821 sessions are in use. 2823 8.6. Check-Balance-Result AVP 2825 The Check Balance Result AVP (AVP Code 422) is of type Enumerated and 2826 contains the result of the balance check. This AVP is applicable 2827 only when the Requested-Action AVP indicates CHECK_BALANCE in the 2828 Credit-Control-Request command. The following values are defined for 2829 the Check-Balance-Result AVP. 2831 ENOUGH_CREDIT 0 2833 There is enough credit in the account to cover the requested service. 2835 NO_CREDIT 1 2837 There isn't enough credit in the account to cover the requested 2838 service. 2840 8.7. Cost-Information AVP 2842 The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is 2843 used to return the cost information of a service, which the credit- 2844 control client can transfer transparently to the end user. The 2845 included Unit-Value AVP contains the cost estimate (always type of 2846 money) of the service, in the case of price enquiry, or the 2847 accumulated cost estimation, in the case of credit-control session. 2849 The Currency-Code specifies in which currency the cost was given. 2850 The Cost-Unit specifies the unit when the service cost is a cost per 2851 unit (e.g., cost for the service is $1 per minute). 2853 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 2854 the Credit-Control-Request command, the Cost-Information AVP sent in 2855 the succeeding Credit-Control-Answer command contains the cost 2856 estimation of the requested service, without any reservation being 2857 made. 2859 The Cost-Information AVP included in the Credit-Control-Answer 2860 command with the CC-Request-Type set to UPDATE_REQUEST contains the 2861 accumulated cost estimation for the session, without taking any 2862 credit reservation into account. 2864 The Cost-Information AVP included in the Credit-Control-Answer 2865 command with the CC-Request-Type set to EVENT_REQUEST or 2866 TERMINATION_REQUEST contains the estimated total cost for the 2867 requested service. 2869 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2871 Cost-Information ::= < AVP Header: 423 > 2872 { Unit-Value } 2873 { Currency-Code } 2874 [ Cost-Unit ] 2876 8.8. Unit-Value AVP 2878 Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the 2879 units as decimal value. The Unit-Value is a value with an exponent; 2880 i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This 2881 representation avoids unwanted rounding off. For example, the value 2882 of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The 2883 absence of the exponent part MUST be interpreted as an exponent equal 2884 to zero. 2886 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2888 Unit-Value ::= < AVP Header: 445 > 2889 { Value-Digits } 2890 [ Exponent ] 2892 8.9. Exponent AVP 2894 Exponent AVP is of type Integer32 (AVP Code 429) and contains the 2895 exponent value to be applied for the Value-Digit AVP within the Unit- 2896 Value AVP. 2898 8.10. Value-Digits AVP 2900 The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains 2901 the significant digits of the number. If decimal values are needed 2902 to present the units, the scaling MUST be indicated with the related 2903 Exponent AVP. For example, for the monetary amount $ 0.05 the value 2904 of Value-Digits AVP MUST be set to 5, and the scaling MUST be 2905 indicated with the Exponent AVP set to -2. 2907 8.11. Currency-Code AVP 2909 The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and 2910 contains a currency code that specifies in which currency the values 2911 of AVPs containing monetary units were given. It is specified by 2912 using the numeric values defined in the ISO 4217 standard [ISO4217]. 2914 8.12. Cost-Unit AVP 2916 The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is 2917 used to display a human readable string to the end user. It 2918 specifies the applicable unit to the Cost-Information when the 2919 service cost is a cost per unit (e.g., cost of the service is $1 per 2920 minute). The Cost-Unit can be minutes, hours, days, kilobytes, 2921 megabytes, etc. 2923 8.13. Credit-Control AVP 2925 The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST 2926 be included in AA requests when the service element has credit- 2927 control capabilities. 2929 CREDIT_AUTHORIZATION 0 2931 If the home Diameter AAA server determines that the user has prepaid 2932 subscription, this value indicates that the credit-control server 2933 MUST be contacted to perform the first interrogation. The value of 2934 the Credit-Control AVP MUST always be set to 0 in an AA request sent 2935 to perform the first interrogation and to initiate a new credit- 2936 control session. 2938 RE_AUTHORIZATION 1 2940 This value indicates to the Diameter AAA server that a credit-control 2941 session is ongoing for the subscriber and that the credit-control 2942 server MUST NOT be contacted. The Credit-Control AVP set to the 2943 value of 1 is to be used only when the first interrogation has been 2944 successfully performed and the credit-control session is ongoing 2945 (i.e., re-authorization triggered by Authorization-Lifetime). This 2946 value MUST NOT be used in an AA request sent to perform the first 2947 interrogation. 2949 8.14. Credit-Control-Failure-Handling AVP 2951 The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type 2952 Enumerated. The credit-control client uses information in this AVP 2953 to decide what to do if sending credit-control messages to the 2954 credit-control server has been, for instance, temporarily prevented 2955 due to a network problem. Depending on the service logic, the 2956 credit-control server can order the client to terminate the service 2957 immediately when there is a reason to believe that the service cannot 2958 be charged, or to try failover to an alternative server, if possible. 2960 Then the server could either terminate or grant the service, should 2961 the alternative connection also fail. 2963 TERMINATE 0 2965 When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the 2966 service MUST only be granted for as long as there is a connection to 2967 the credit-control server. If the credit-control client does not 2968 receive any Credit-Control-Answer message within the Tx timer (as 2969 defined in Section 13), the credit-control request is regarded as 2970 failed, and the end user's service session is terminated. 2972 This is the default behavior if the AVP isn't included in the reply 2973 from the authorization or credit-control server. 2975 CONTINUE 1 2977 When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the 2978 credit-control client SHOULD re-send the request to an alternative 2979 server in the case of transport or temporary failures, provided that 2980 a failover procedure is supported in the credit-control server and 2981 the credit-control client, and that an alternative server is 2982 available. Otherwise, the service SHOULD be granted, even if credit- 2983 control messages can't be delivered. 2985 RETRY_AND_TERMINATE 2 2987 When the Credit-Control-Failure-Handling AVP is set to 2988 RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the 2989 request to an alternative server in the case of transport or 2990 temporary failures, provided that a failover procedure is supported 2991 in the credit-control server and the credit-control client, and that 2992 an alternative server is available. Otherwise, the service SHOULD 2993 NOT be granted when the credit-control messages can't be delivered. 2995 8.15. Direct-Debiting-Failure-Handling AVP 2997 The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type 2998 Enumerated. The credit-control client uses information in this AVP 2999 to decide what to do if sending credit-control messages (Requested- 3000 Action AVP set to DIRECT_DEBITING) to the credit-control server has 3001 been, for instance, temporarily prevented due to a network problem. 3003 TERMINATE_OR_BUFFER 0 3005 When the Direct-Debiting-Failure-Handling AVP is set to 3006 TERMINATE_OR_BUFFER, the service MUST be granted for as long as there 3007 is a connection to the credit-control server. If the credit-control 3008 client does not receive any Credit-Control-Answer message within the 3009 Tx timer (as defined in Section 13) the credit-control request is 3010 regarded as failed. The client SHOULD terminate the service if it 3011 can determine from the failed answer that units have not been 3012 debited. Otherwise the credit-control client SHOULD grant the 3013 service, store the request in application level non-volatile storage, 3014 and try to re-send the request. These requests MUST be marked as 3015 possible duplicates by setting the T-flag in the command header as 3016 described in [RFC6733] section 3. This is the default behavior if 3017 the AVP isn't included in the reply from the authorization server. 3019 CONTINUE 1 3021 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 3022 service SHOULD be granted, even if credit-control messages can't be 3023 delivered, and the request should be deleted. 3025 8.16. Multiple-Services-Credit-Control AVP 3027 Multiple-Services-Credit-Control AVP (AVP Code 456) is of type 3028 Grouped and contains the AVPs related to the independent credit- 3029 control of multiple services feature. Note that each instance of 3030 this AVP carries units related to one or more services or related to 3031 a single rating group. 3033 The Service-Identifier and the Rating-Group AVPs are used to 3034 associate the granted units to a given service or rating group. If 3035 both the Service-Identifier and the Rating-Group AVPs are included, 3036 the target of the service units is always the service(s) indicated by 3037 the value of the Service-Identifier AVP(s). If only the Rating- 3038 Group-Id AVP is present, the Multiple-Services-Credit-Control AVP 3039 relates to all the services that belong to the specified rating 3040 group. 3042 The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- 3043 Pool-Identifier identifying a credit pool within which the units of 3044 the specified type are considered pooled. If a G-S-U-Pool-Reference 3045 AVP is present, then actual service units of the specified type MUST 3046 also be present. For example, if the G-S-U-Pool-Reference AVP 3047 specifies Unit-Type TIME, then the CC-Time AVP MUST be present. 3049 The Requested-Service-Unit AVP MAY contain the amount of requested 3050 service units or the requested monetary value. It MUST be present in 3051 the initial interrogation and within the intermediate interrogations 3052 in which new quota is requested. If the credit-control client does 3053 not include the Requested-Service-Unit AVP in a request command, 3054 because for instance, it has determined that the end-user terminated 3055 the service, the server MUST debit the used amount from the user's 3056 account but MUST NOT return a new quota in the corresponding answer. 3057 The Validity-Time, Result-Code, and Final-Unit-Indication or QoS- 3058 Final-Unit-Indication AVPs MAY be present in an answer command as 3059 defined in Section 5.1.2 and Section 5.6 for the graceful service 3060 termination. 3062 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 3063 present, the server MUST include two separate instances of the 3064 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit 3065 AVP associated to the same service-identifier and/or rating-group. 3066 Where the two quotas are associated to the same pool or to different 3067 pools, the credit pooling mechanism defined in Section 5.1.2 applies. 3068 The Tariff-Change-Usage AVP MUST NOT be included in request commands 3069 to report used units before, and after tariff time change the Used- 3070 Service-Unit AVP MUST be used. 3072 A server not implementing the independent credit-control of multiple 3073 services functionality MUST treat the Multiple-Services-Credit- 3074 Control AVP as an invalid AVP. 3076 The Multiple-Services-Control AVP is defined as follows (per the 3077 grouped-avp-def of [RFC6733]): 3079 Multiple-Services-Credit-Control ::= < AVP Header: 456 > 3080 [ Granted-Service-Unit ] 3081 [ Requested-Service-Unit ] 3082 *[ Used-Service-Unit ] 3083 [ Tariff-Change-Usage ] 3084 *[ Service-Identifier ] 3085 [ Rating-Group ] 3086 *[ G-S-U-Pool-Reference ] 3087 [ Validity-Time ] 3088 [ Result-Code ] 3089 [ Final-Unit-Indication ] 3090 [ QoS-Final-Unit-Indication ] 3091 *[ AVP ] 3093 8.17. Granted-Service-Unit AVP 3095 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 3096 contains the amount of units that the Diameter credit-control client 3097 can provide to the end user until the service must be released or the 3098 new Credit-Control-Request must be sent. A client is not required to 3099 implement all the unit types, and it must treat unknown or 3100 unsupported unit types in the answer message as an incorrect CCA 3101 answer. In this case, the client MUST terminate the credit-control 3102 session and indicate in the Termination-Cause AVP reason 3103 DIAMETER_BAD_ANSWER. 3105 The Granted-Service-Unit AVP is defined as follows (per the grouped- 3106 avp-def of [RFC6733]): 3108 Granted-Service-Unit ::= < AVP Header: 431 > 3109 [ Tariff-Time-Change ] 3110 [ CC-Time ] 3111 [ CC-Money ] 3112 [ CC-Total-Octets ] 3113 [ CC-Input-Octets ] 3114 [ CC-Output-Octets ] 3115 [ CC-Service-Specific-Units ] 3116 *[ AVP ] 3118 8.18. Requested-Service-Unit AVP 3120 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and 3121 contains the amount of requested units specified by the Diameter 3122 credit-control client. A server is not required to implement all the 3123 unit types, and it must treat unknown or unsupported unit types as 3124 invalid AVPs. 3126 The Requested-Service-Unit AVP is defined as follows (per the 3127 grouped-avp-def of [RFC6733]): 3129 Requested-Service-Unit ::= < AVP Header: 437 > 3130 [ CC-Time ] 3131 [ CC-Money ] 3132 [ CC-Total-Octets ] 3133 [ CC-Input-Octets ] 3134 [ CC-Output-Octets ] 3135 [ CC-Service-Specific-Units ] 3136 *[ AVP ] 3138 8.19. Used-Service-Unit AVP 3140 The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and 3141 contains the amount of used units measured from the point when the 3142 service became active or, if interim interrogations are used during 3143 the session, from the point when the previous measurement ended. 3144 Note: The values reported in a Used-Service-Unit AVP does not 3145 necessarily have a relation to the grant provided in a Granted- 3146 Service-Unit AVP, e.g., the value in this AVP may exceed the value in 3147 the grant. 3149 The Used-Service-Unit AVP is defined as follows (per the grouped-avp- 3150 def of [RFC6733]): 3152 Used-Service-Unit ::= < AVP Header: 446 > 3153 [ Tariff-Change-Usage ] 3154 [ CC-Time ] 3155 [ CC-Money ] 3156 [ CC-Total-Octets ] 3157 [ CC-Input-Octets ] 3158 [ CC-Output-Octets ] 3159 [ CC-Service-Specific-Units ] 3160 *[ AVP ] 3162 8.20. Tariff-Time-Change AVP 3164 The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is 3165 sent from the server to the client and includes the time in seconds 3166 since January 1, 1900, 00:00 UTC, when the tariff of the service will 3167 be changed. 3169 The tariff change mechanism is optional for the client and server, 3170 and it is not used for time-based services defined in Section 5. If 3171 a client does not support the tariff time change mechanism, it MUST 3172 treat Tariff-Time-Change AVP in the answer message as an incorrect 3173 CCA answer. In this case, the client terminates the credit-control 3174 session and indicates in the Termination-Cause AVP reason 3175 DIAMETER_BAD_ANSWER. 3177 Omission of this AVP means that no tariff change is to be reported. 3179 8.21. CC-Time AVP 3181 The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates 3182 the length of the requested, granted, or used time in seconds. 3184 8.22. CC-Money AVP 3186 The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the 3187 monetary amount in the given currency. The Currency-Code AVP SHOULD 3188 be included. It is defined as follows (per the grouped-avp-def of 3189 [RFC6733]): 3191 CC-Money ::= < AVP Header: 413 > 3192 { Unit-Value } 3193 [ Currency-Code ] 3195 8.23. CC-Total-Octets AVP 3197 The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and 3198 contains the total number of requested, granted, or used octets 3199 regardless of the direction (sent or received). 3201 8.24. CC-Input-Octets AVP 3203 The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and 3204 contains the number of requested, granted, or used octets that can 3205 be/have been received from the end user. 3207 8.25. CC-Output-Octets AVP 3209 The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and 3210 contains the number of requested, granted, or used octets that can 3211 be/have been sent to the end user. 3213 8.26. CC-Service-Specific-Units AVP 3215 The CC-Service-Specific-Units AVP (AVP Code 417) is of type 3216 Unsigned64 and specifies the number of service-specific units (e.g., 3217 number of events, points) given in a selected service. The service- 3218 specific units always refer to the service identified in the Service- 3219 Identifier AVP (or Rating-Group AVP when the Multiple-Services- 3220 Credit-Control AVP is used). 3222 8.27. Tariff-Change-Usage AVP 3224 The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and 3225 defines whether units are used before or after a tariff change, or 3226 whether the units straddled a tariff change during the reporting 3227 period. Omission of this AVP means that no tariff change has 3228 occurred. 3230 In addition, when present in answer messages as part of the Multiple- 3231 Services-Credit-Control AVP, this AVP defines whether units are 3232 allocated to be used before or after a tariff change event. 3234 When the Tariff-Time-Change AVP is present, omission of this AVP in 3235 answer messages means that the single quota mechanism applies. 3237 Tariff-Change-Usage can be one of the following: 3239 UNIT_BEFORE_TARIFF_CHANGE 0 3240 When present in the Multiple-Services-Credit-Control AVP, this value 3241 indicates the amount of the units allocated for use before a tariff 3242 change occurs. 3244 When present in the Used-Service-Unit AVP, this value indicates the 3245 amount of resource units used before a tariff change had occurred. 3247 UNIT_AFTER_TARIFF_CHANGE 1 3249 When present in the Multiple-Services-Credit-Control AVP, this value 3250 indicates the amount of the units allocated for use after a tariff 3251 change occurs. 3253 When present in the Used-Service-Unit AVP, this value indicates the 3254 amount of resource units used after tariff change had occurred. 3256 UNIT_INDETERMINATE 2 3258 The used unit contains the amount of units that straddle the tariff 3259 change (e.g., the metering process reports to the credit-control 3260 client in blocks of n octets, and one block straddled the tariff 3261 change). This value is to be used only in the Used-Service-Unit AVP. 3263 8.28. Service-Identifier AVP 3265 The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and 3266 contains the identifier of a service. The specific service the 3267 request relates to is uniquely identified by the combination of 3268 Service-Context-Id and Service-Identifier AVPs. 3270 A usage example of this AVP is illustrated in Appendix B.9. 3272 8.29. Rating-Group AVP 3274 The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and 3275 contains the identifier of a rating group. All the services subject 3276 to the same rating type are part of the same rating group. The 3277 specific rating group the request relates to is uniquely identified 3278 by the combination of Service-Context-Id and Rating-Group AVPs. 3280 A usage example of this AVP is illustrated in Appendix B.9. 3282 8.30. G-S-U-Pool-Reference AVP 3284 The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It 3285 is used in the Credit-Control-Answer message, and associates the 3286 Granted-Service-Unit AVP within which it appears with a credit pool 3287 within the session. 3289 The G-S-U-Pool-Identifier AVP specifies the credit pool from which 3290 credit is drawn for this unit type. 3292 The CC-Unit-Type AVP specifies the type of units for which credit is 3293 pooled. 3295 The Unit-Value AVP specifies the multiplier, which converts between 3296 service units of type CC-Unit-Type and abstract service units within 3297 the credit pool (and thus to service units of any other service or 3298 rating group associated with the same pool). 3300 The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- 3301 avp-def of [RFC6733]): 3303 G-S-U-Pool-Reference ::= < AVP Header: 457 > 3304 { G-S-U-Pool-Identifier } 3305 { CC-Unit-Type } 3306 { Unit-Value } 3308 8.31. G-S-U-Pool-Identifier AVP 3310 The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 3311 and identifies a credit pool within the session. 3313 8.32. CC-Unit-Type AVP 3315 The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and 3316 specifies the type of units considered to be pooled into a credit 3317 pool. 3319 The following values are defined for the CC-Unit-Type AVP: 3321 TIME 0 3322 MONEY 1 3323 TOTAL-OCTETS 2 3324 INPUT-OCTETS 3 3325 OUTPUT-OCTETS 4 3326 SERVICE-SPECIFIC-UNITS 5 3328 8.33. Validity-Time AVP 3330 The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is 3331 sent from the credit-control server to the credit-control client. 3332 The AVP contains the validity time of the granted service units. The 3333 measurement of the Validity-Time is started upon receipt of the 3334 Credit-Control-Answer Message containing this AVP. If the granted 3335 service units have not been consumed within the validity time 3336 specified in this AVP, the credit-control client MUST send a Credit- 3337 Control-Request message to the server, with CC-Request-Type set to 3338 UPDATE_REQUEST. The value field of the Validity-Time AVP is given in 3339 seconds. 3341 The Validity-Time AVP is also used for the graceful service 3342 termination (see Section 5.6) to indicate to the credit-control 3343 client how long the subscriber is allowed to use network resources 3344 after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) 3345 started. When the Validity-Time elapses, a new intermediate 3346 interrogation is sent to the server. 3348 8.34. Final-Unit-Indication AVP 3350 The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and 3351 indicates that the Granted-Service-Unit AVP in the Credit-Control- 3352 Answer, or in the AA answer, contains the final units for the 3353 service. After these units have expired, the Diameter credit-control 3354 client is responsible for executing the action indicated in the 3355 Final-Unit-Action AVP (see Section 5.6). 3357 If more than one unit type is received in the Credit-Control-Answer, 3358 the unit type that first expired SHOULD cause the credit-control 3359 client to execute the specified action. 3361 In the first interrogation, the Final-Unit-Indication AVP with Final- 3362 Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no 3363 Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA 3364 answer. This indicates to the Diameter credit-control client to 3365 execute the specified action immediately. If the home service 3366 provider policy is to terminate the service, naturally, the server 3367 SHOULD return the appropriate transient failure (see Section 9.1) in 3368 order to implement the policy-defined action. 3370 The Final-Unit-Action AVP defines the behavior of the service element 3371 when the user's account cannot cover the cost of the service and MUST 3372 always be present if the Final-Unit-Indication AVP is included in a 3373 command. 3375 If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit- 3376 Indication group MUST NOT contain any other AVPs. 3378 If the Final-Unit-Action AVP is set to REDIRECT at least the 3379 Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP 3380 or the Filter-Id AVP MAY be present in the Credit-Control-Answer 3381 message if the user is also allowed to access other services that are 3382 not accessible through the address given in the Redirect-Server AVP. 3384 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3385 Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3387 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 3388 used to reference an IP filter list installed in the access device by 3389 means other than the Diameter credit-control application, e.g., 3390 locally configured or configured by another entity. 3392 If the Final-Unit-Action AVP is set to REDIRECT and the type of 3393 server is not one of the enumerations in the Redirect-Address-Type 3394 AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together 3395 with the Redirect-Server-Extension AVP instead of the Final-Unit- 3396 Indication AVP. 3398 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT 3399 and the classification of the restricted traffic cannot be expressed 3400 using IPFilterRule, or different actions (e.g., QoS) than just 3401 allowing QoS needs to be enforced traffic, then the QoS-Final-Unit- 3402 Indication AVP SHOULD be used instead of the Final-Unit-Indication 3403 AVP. However, if the credit control server wants to preserve 3404 backward compatibility with credit-control clients that support only 3405 [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with 3406 the Filter-Id AVP. 3408 The Final-Unit-Indication AVP is defined as follows (per the grouped- 3409 avp-def of [RFC6733]): 3411 Final-Unit-Indication ::= < AVP Header: 430 > 3412 { Final-Unit-Action } 3413 *[ Restriction-Filter-Rule ] 3414 *[ Filter-Id ] 3415 [ Redirect-Server ] 3417 8.35. Final-Unit-Action AVP 3419 The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and 3420 indicates to the credit-control client the action to be taken when 3421 the user's account cannot cover the service cost. 3423 The Final-Unit-Action can be one of the following: 3425 TERMINATE 0 3427 The credit-control client MUST terminate the service session. This 3428 is the default handling, applicable whenever the credit-control 3429 client receives an unsupported Final-Unit-Action value, and it MUST 3430 be supported by all the Diameter credit-control client 3431 implementations conforming to this specification. 3433 REDIRECT 1 3435 The service element MUST redirect the user to the address specified 3436 in the Redirect-Server-Address AVP or one of the AVPs included in the 3437 Redirect-Server-Extension AVP. The redirect action is defined in 3438 Section 5.6.2. 3440 RESTRICT_ACCESS 2 3442 The access device MUST restrict the user access according to the 3443 filter AVPs contained in the applied grouped AVP: according to IP 3444 packet filters defined in the Restriction-Filter-Rule AVP, according 3445 to the packet classifier filters defined in Filter-Rule AVP, or 3446 according to the packet filters identified by the Filter-Id AVP. All 3447 the packets not matching any filters MUST be dropped (see 3448 Section 5.6.3). 3450 8.36. Restriction-Filter-Rule AVP 3452 The Restriction-Filter-Rule AVP (AVP Code 438) is of type 3453 IPFilterRule and provides filter rules corresponding to services that 3454 are to remain accessible even if there are no more service units 3455 granted. The access device has to configure the specified filter 3456 rules for the subscriber and MUST drop all the packets not matching 3457 these filters. Zero, one, or more such AVPs MAY be present in a 3458 Credit-Control-Answer message or in an AA answer message. 3460 8.37. Redirect-Server AVP 3462 The Redirect-Server AVP (AVP Code 434) is of type Grouped and 3463 contains the address information of the redirect server (e.g., HTTP 3464 redirect server, SIP Server) with which the end user is to be 3465 connected when the account cannot cover the service cost. It MUST be 3466 present when the Final-Unit-Action AVP is set to REDIRECT. 3468 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3470 Redirect-Server ::= < AVP Header: 434 > 3471 { Redirect-Address-Type } 3472 { Redirect-Server-Address } 3474 8.38. Redirect-Address-Type AVP 3476 The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated 3477 and defines the address type of the address given in the Redirect- 3478 Server-Address AVP. 3480 The address type can be one of the following: 3482 IPv4 Address 0 3484 The address type is in the form of "dotted-decimal" IPv4 address, as 3485 defined in [RFC0791]. 3487 IPv6 Address 1 3489 The address type is in the form of IPv6 address, as defined in 3490 [RFC4291]. The address MUST conform to the text representation of 3491 the address according to [RFC5952]. 3493 URL 2 3495 The address type is in the form of Uniform Resource Locator, as 3496 defined in [RFC3986]. 3498 SIP URI 3 3500 The address type is in the form of SIP Uniform Resource Identifier, 3501 as defined in [RFC3261]. 3503 8.39. Redirect-Server-Address AVP 3505 The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String 3506 and defines the address of the redirect server (e.g., HTTP redirect 3507 server, SIP Server) with which the end user is to be connected when 3508 the account cannot cover the service cost. 3510 8.40. Multiple-Services-Indicator AVP 3512 The Multiple-Services-Indicator AVP (AVP Code 455) is of type 3513 Enumerated and indicates whether the Diameter credit-control client 3514 is capable of handling multiple services independently within a 3515 (sub-) session. The absence of this AVP means that independent 3516 credit-control of multiple services is not supported. 3518 A server not implementing the independent credit-control of multiple 3519 services MUST treat the Multiple-Services-Indicator AVP as an invalid 3520 AVP. 3522 The following values are defined for the Multiple-Services-Indicator 3523 AVP: 3525 MULTIPLE_SERVICES_NOT_SUPPORTED 0 3527 Client does not support independent credit-control of multiple 3528 services within a (sub-)session. 3530 MULTIPLE_SERVICES_SUPPORTED 1 3532 Client supports independent credit-control of multiple services 3533 within a (sub-)session. 3535 8.41. Requested-Action AVP 3537 The Requested-Action AVP (AVP Code 436) is of type Enumerated and 3538 contains the requested action being sent by Credit-Control-Request 3539 command where the CC-Request-Type is set to EVENT_REQUEST. The 3540 following values are defined for the Requested-Action AVP: 3542 DIRECT_DEBITING 0 3544 This indicates a request to decrease the end user's account according 3545 to information specified in the Requested-Service-Unit AVP and/or 3546 Service-Identifier AVP (additional rating information may be included 3547 in service-specific AVPs or in the Service-Parameter-Info AVP). The 3548 Granted-Service-Unit AVP in the Credit-Control-Answer command 3549 contains the debited units. 3551 REFUND_ACCOUNT 1 3553 This indicates a request to increase the end user's account according 3554 to information specified in the Requested-Service-Unit AVP and/or 3555 Service-Identifier AVP (additional rating information may be included 3556 in service-specific AVPs or in the Service-Parameter-Info AVP). The 3557 Granted-Service-Unit AVP in the Credit-Control-Answer command 3558 contains the refunded units. 3560 CHECK_BALANCE 2 3562 This indicates a balance check request. In this case, the checking 3563 of the account balance is done without any credit reservation from 3564 the account. The Check-Balance-Result AVP in the Credit-Control- 3565 Answer command contains the result of the balance check. 3567 PRICE_ENQUIRY 3 3568 This indicates a price enquiry request. In this case, neither 3569 checking of the account balance nor reservation from the account will 3570 be done; only the price of the service will be returned in the Cost- 3571 Information AVP in the Credit-Control-Answer Command. 3573 8.42. Service-Context-Id AVP 3575 The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and 3576 contains a unique identifier of the Diameter credit-control service 3577 specific document that applies to the request (as defined in 3578 Section 4.1.2). This is an identifier allocated by the service 3579 provider, by the service element manufacturer, or by a 3580 standardization body, and MUST uniquely identify a given Diameter 3581 credit-control service specific document. The format of the Service- 3582 Context-Id is: 3584 "service-context" "@" "domain" 3586 service-context = Token 3588 The Token is an arbitrary string of characters and digits. 3590 'domain' represents the entity that allocated the Service-Context-Id. 3591 It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by 3592 a standardization body, or it can be the FQDN of the service provider 3593 (e.g., provider.example.com) or of the vendor (e.g., 3594 vendor.example.com) if the identifier is allocated by a private 3595 entity. 3597 This AVP SHOULD be placed as close to the Diameter header as 3598 possible. 3600 Service-specific documents that are for private use only (i.e., to 3601 one provider's own use, where no interoperability is deemed useful) 3602 may define private identifiers without need of coordination. 3603 However, when interoperability is wanted, coordination of the 3604 identifiers via, for example, publication of an informational RFC is 3605 RECOMMENDED in order to make Service-Context-Id globally available. 3607 8.43. Service-Parameter-Info AVP 3609 The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and 3610 contains service-specific information used for price calculation or 3611 rating. The Service-Parameter-Type AVP defines the service parameter 3612 type, and the Service-Parameter-Value AVP contains the parameter 3613 value. The actual contents of these AVPs are not within the scope of 3614 this document and SHOULD be defined in another Diameter application, 3615 in standards written by other standardization bodies, or in service- 3616 specific documentation. 3618 In the case of an unknown service request (e.g., unknown Service- 3619 Parameter-Type), the corresponding answer message MUST contain the 3620 error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message 3621 with this error MUST contain one or more Failed-AVP AVPs containing 3622 the Service-Parameter-Info AVPs that caused the failure. 3624 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3626 Service-Parameter-Info ::= < AVP Header: 440 > 3627 { Service-Parameter-Type } 3628 { Service-Parameter-Value } 3630 8.44. Service-Parameter-Type AVP 3632 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) 3633 and defines the type of the service event specific parameter (e.g., 3634 it can be the end-user location or service name). The different 3635 parameters and their types are service specific, and the meanings of 3636 these parameters are not defined in this document. Whoever allocates 3637 the Service-Context-Id (i.e., unique identifier of a service-specific 3638 document) is also responsible for assigning Service-Parameter-Type 3639 values for the service and ensuring their uniqueness within the given 3640 service. The Service-Parameter-Value AVP contains the value 3641 associated with the service parameter type. 3643 8.45. Service-Parameter-Value AVP 3645 The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) 3646 and contains the value of the service parameter type. 3648 8.46. Subscription-Id AVP 3650 The Subscription-Id AVP (AVP Code 443) is used to identify the end 3651 user's subscription and is of type Grouped. The Subscription-Id AVP 3652 includes a Subscription-Id-Data AVP that holds the identifier and a 3653 Subscription-Id-Type AVP that defines the identifier type. 3655 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3657 Subscription-Id ::= < AVP Header: 443 > 3658 { Subscription-Id-Type } 3659 { Subscription-Id-Data } 3661 8.47. Subscription-Id-Type AVP 3663 The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, 3664 and it is used to determine which type of identifier is carried by 3665 the Subscription-Id AVP. 3667 This specification defines the following subscription identifiers. 3668 However, new Subscription-Id-Type values can be assigned by an IANA 3669 designated expert, as defined in Section 12. A server MUST implement 3670 all the Subscription-Id-Types required to perform credit 3671 authorization for the services it supports, including possible future 3672 values. Unknown or unsupported Subscription-Id-Types MUST be treated 3673 according to the 'M' flag rule, as defined in [RFC6733]. 3675 END_USER_E164 0 3677 The identifier is in international E.164 format (e.g., MSISDN), 3678 according to the ITU-T E.164 numbering plan defined in [E164] and 3679 [CE164]. 3681 END_USER_IMSI 1 3683 The identifier is in international IMSI format, according to the 3684 ITU-T E.212 numbering plan as defined in [E212] and [CE212]. 3686 END_USER_SIP_URI 2 3688 The identifier is in the form of a SIP URI, as defined in [RFC3261]. 3690 END_USER_NAI 3 3692 The identifier is in the form of a Network Access Identifier, as 3693 defined in [RFC7542]. 3695 END_USER_PRIVATE 4 3697 The Identifier is a credit-control server private identifier. 3699 8.48. Subscription-Id-Data AVP 3701 The Subscription-Id-Data AVP (AVP Code 444) is used to identify the 3702 end user and is of type UTF8String. The Subscription-Id-Type AVP 3703 defines which type of identifier is used. 3705 8.49. User-Equipment-Info AVP 3707 The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and 3708 allows the credit-control client to indicate the identity and 3709 capability of the terminal the subscriber is using for the connection 3710 to network. 3712 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3714 User-Equipment-Info ::= < AVP Header: 458 > 3715 { User-Equipment-Info-Type } 3716 { User-Equipment-Info-Value } 3718 8.50. User-Equipment-Info-Type AVP 3720 The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) 3721 and defines the type of user equipment information contained in the 3722 User-Equipment-Info-Value AVP. 3724 This specification defines the following user equipment types. 3725 However, new User-Equipment-Info-Type values can be assigned by an 3726 IANA designated expert, as defined in Section 12. 3728 IMEISV 0 3730 The identifier contains the International Mobile Equipment Identifier 3731 and Software Version in the international IMEISV format according to 3732 3GPP TS 23.003 [TGPPIMEI]. 3734 MAC 1 3736 The 48-bit MAC address is formatted as described in [RFC3580]. 3738 EUI64 2 3740 The 64-bit identifier used to identify the hardware instance of the 3741 product, as defined in [EUI64]. 3743 MODIFIED_EUI64 3 3745 There are a number of types of terminals that have identifiers other 3746 than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be 3747 converted to modified EUI-64 format as described in [RFC4291] or by 3748 using some other methods referred to in the service-specific 3749 documentation. 3751 8.51. User-Equipment-Info-Value AVP 3753 The User-Equipment-Info-Value AVP (AVP Code 460) is of type 3754 OctetString. The User-Equipment-Info-Type AVP defines which type of 3755 identifier is used. 3757 8.52. User-Equipment-Info-Extension AVP 3759 The User-Equipment-Info-Extension AVP (AVP Code TBD1) is of type 3760 Grouped and allows the credit-control client to indicate the identity 3761 and capability of the terminal the subscriber is using for the 3762 connection to network. If the type of the equipment is one of the 3763 enumerated types of User-Equipment-Info-Type AVP, then the credit- 3764 control client SHOULD send the information in the User-Equipment-Info 3765 AVP, in addition to or instead of the User-Equipment-Info-Extension 3766 AVP. This is in order to preserve backward compatibility with 3767 credit-control servers that support only [RFC4006]. Exactly one AVP 3768 MUST be included inside the User-Equipment-Info-Extension AVP. 3770 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3772 User-Equipment-Info-Extension ::= < AVP Header: TBD1 > 3773 [ User-Equipment-Info-IMEISV ] 3774 [ User-Equipment-Info-MAC ] 3775 [ User-Equipment-Info-EUI64 ] 3776 [ User-Equipment-Info-ModifiedEUI64 ] 3777 [ User-Equipment-Info-IMEI ] 3778 [ AVP ] 3780 8.53. User-Equipment-Info-IMEISV AVP 3782 The User-Equipment-Info-IMEISV (AVP Code TBD2) is of type 3783 OctetString. The User-Equipment-Info-IMEISV AVP contains the 3784 International Mobile Equipment Identifier and Software Version in the 3785 international IMEISV format according to 3GPP TS 23.003 [TGPPIMEI]. 3787 8.54. User-Equipment-Info-MAC AVP 3789 The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. 3790 The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is 3791 formatted as described in [RFC3580]. 3793 8.55. User-Equipment-Info-EUI64 AVP 3795 The User-Equipment-Info-EUI64 (AVP Code TBD4) is of type OctetString. 3796 The UUser-Equipment-Info-EUI64 AVP contains the 64-bit identifier 3797 used to identify the hardware instance of the product, as defined in 3798 [EUI64]. 3800 8.56. User-Equipment-Info-ModifiedEUI64 AVP 3802 The User-Equipment-Info-ModifiedEUI64 (AVP Code TBD5) is of type 3803 OctetString. There are a number of types of terminals that have 3804 identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These 3805 identifiers can be converted to modified EUI-64 format as described 3806 in [RFC4291] or by using some other methods referred to in the 3807 service-specific documentation. The User-Equipment-Info- 3808 ModifiedEUI64 AVP contains such identifiers. 3810 8.57. User-Equipment-Info-IMEI AVP 3812 The User-Equipment-Info-IMEI (AVP Code TBD6) is of type OctetString. 3813 The User-Equipment-Info-IMEI AVP contains the International Mobile 3814 Equipment Identifier in the international IMEI format according to 3815 3GPP TS 23.003 [TGPPIMEI]. 3817 8.58. Subscription-Id-Extension AVP 3819 The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify 3820 the end user's subscription and is of type Grouped. The 3821 Subscription-Id-Extension group AVP MUST include an AVP holding the 3822 subscription identifier. The type of this included AVP indicates the 3823 type of the subscription identifier. For each of the enumerated 3824 values of the Subscription-Id-Type AVP, there is a corresponding sub- 3825 AVP for use within the Subscription-Id-Extension group AVP. If a new 3826 identifier type is required a corresponding new sub-AVP SHOULD be 3827 defined for use within the Subscription-Id-Extension group AVP. 3829 If full backward compatibility with [RFC4006] is required, then the 3830 Subscription-Id AVP MUST be used to indicate identifier types 3831 enumerated in the Subscription-Id-Type AVP, whereas the Subscription- 3832 Id-Extension AVP MUST be used only for newly defined identifier 3833 types. If full backward compatibility with [RFC4006] is not 3834 required, then the Subscription-Id-Extension AVP MAY be used to carry 3835 out the existing identifier types. In this case, Subscription-Id- 3836 Extension AVP MAY be sent together with Subscription-Id AVP. 3838 Exactly one sub-AVP MUST be included inside the Subscription-Id- 3839 Extension AVP. 3841 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3843 Subscription-Id-Extension ::= < AVP Header: TBD7 > 3844 [ Subscription-Id-E164 ] 3845 [ Subscription-Id-IMSI ] 3846 [ Subscription-Id-SIP-URI ] 3847 [ Subscription-Id-NAI ] 3848 [ Subscription-Id-Private ] 3849 [ AVP ] 3851 8.59. Subscription-Id-E164 AVP 3853 The Subscription-Id-E164 (AVP Code TBD8) is of type UTF8String. The 3854 Subscription-Id-E164 AVP contains the international E.164 format 3855 (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined 3856 in [E164] and [CE164]. 3858 8.60. Subscription-Id-IMSI AVP 3860 The Subscription-Id-IMSI (AVP Code TBD9) is of type UTF8String. The 3861 Subscription-Id-IMSI AVP contains the international IMSI format, 3862 according to the ITU-T E.212 numbering plan as defined in [E212] and 3863 [CE212]. 3865 8.61. Subscription-Id-SIP-URI AVP 3867 The Subscription-Id-SIP-URI (AVP Code TBD10) is of type UTF8String. 3868 The Subscription-Id-SIP-URI AVP contains the identifier in the form 3869 of a SIP URI, as defined in [RFC3261]. 3871 8.62. Subscription-Id-NAI AVP 3873 The Subscription-Id-NAI (AVP Code TBD11) is of type UTF8String. The 3874 Subscription-Id-NAI AVP contains the identifier in the form of a 3875 Network Access Identifier, as defined in [RFC7542]. 3877 8.63. Subscription-Id-Private AVP 3879 The Subscription-Id-Private (AVP Code TBD12) is of type UTF8String. 3880 The Subscription-Id-Private AVP contains a credit-control server 3881 private identifier. 3883 8.64. Redirect-Server-Extension AVP 3885 The Redirect-Server-Extension AVP (AVP Code TBD13) is of type Grouped 3886 and contains the address information of the redirect server (e.g., 3887 HTTP redirect server, SIP Server) with which the end user is to be 3888 connected when the account cannot cover the service cost. It MUST be 3889 present inside the QoS-Final-Unit-Indication AVP when the Final-Unit- 3890 Action AVP is set to REDIRECT. If the type of the redirect server is 3891 one of the enumerated values of the Redirect-Address-Type AVP, then 3892 the credit-control server SHOULD send the information in the 3893 Redirect-Server AVP, in addition to or instead of the Redirect- 3894 Server-Extension AVP. This is in order to preserve backward 3895 compatibility with credit-control clients that support only 3896 [RFC4006]. Exactly one AVP MUST be included inside the Redirect- 3897 Server-Extension AVP. 3899 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3901 Redirect-Server-Extension ::= < AVP Header: TBD13 > 3902 [ Redirect-Address-IPAddress ] 3903 [ Redirect-Address-URL ] 3904 [ Redirect-Address-SIP-URI ] 3905 [ AVP ] 3907 8.65. Redirect-Address-IPAddress AVP 3909 The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type 3910 Address and defines the IPv4 or IPv6 address of the redirect server 3911 with which the end user is to be connected when the account cannot 3912 cover the service cost. 3914 When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 3915 format [RFC4291] MAY be used to indicate an IPv4 address. 3917 8.66. Redirect-Address-URL AVP 3919 The Redirect-Address-URL AVP (AVP Code TBD15) is of type UTF8String 3920 and defines the address of the redirect server with which the end 3921 user is to be connected when the account cannot cover the service 3922 cost. The address type is in the form of Uniform Resource Locator, 3923 as defined in [RFC3986]. 3925 8.67. Redirect-Address-SIP-URI AVP 3927 The Redirect-Address-SIP-URI AVP (AVP Code TBD16) is of type 3928 UTF8String and defines the address of the redirect server with which 3929 the end user is to be connected when the account cannot cover the 3930 service cost. The address type is in the form of SIP Uniform 3931 Resource Identifier, as defined in [RFC3261]. 3933 8.68. QoS-Final-Unit-Indication AVP 3935 The QoS-Final-Unit-Indication AVP (AVP Code TBD17) is of type Grouped 3936 and indicates that the Granted-Service-Unit AVP in the Credit- 3937 Control-Answer, or in the AA answer, contains the final units for the 3938 service. After these units have expired, the Diameter credit-control 3939 client is responsible for executing the action indicated in the 3940 Final-Unit-Action AVP (see Section 5.6). 3942 If more than one unit type is received in the Credit-Control-Answer, 3943 the unit type that first expired SHOULD cause the credit-control 3944 client to execute the specified action. 3946 In the first interrogation, the QoS-Final-Unit-Indication AVP with 3947 Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present 3948 with no Granted-Service-Unit AVP in the Credit-Control-Answer or in 3949 the AA answer. This indicates to the Diameter credit-control client 3950 to execute the specified action immediately. If the home service 3951 provider policy is to terminate the service, naturally, the server 3952 SHOULD return the appropriate transient failure (see Section 9.1) in 3953 order to implement the policy-defined action. 3955 The Final-Unit-Action AVP defines the behavior of the service element 3956 when the user's account cannot cover the cost of the service and MUST 3957 always be present if the QoS-Final-Unit-Indication AVP is included in 3958 a command. 3960 If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit- 3961 Indication group MUST NOT contain any other AVPs. 3963 If the Final-Unit-Action AVP is set to REDIRECT at least the 3964 Redirect-Server-Extension AVP MUST be present. The Filter-Rule AVP 3965 or the Filter-Id AVP MAY be present in the Credit-Control-Answer 3966 message if the user is also allowed to access other services that are 3967 not accessible through the address given in the Redirect-Server- 3968 Extension AVP or if the access to these services needs to be limited 3969 in some way (e.g., QoS). 3971 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3972 Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3974 The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can 3975 be used to define a specific condition and action combination. If 3976 used only with traffic conditions, it should define which traffic 3977 should allowed when no more service units are granted. However, if 3978 QoS or treatment information exists in the AVP, these actions should 3979 be executed, e.g., limiting the allowed traffic with certain QoS. 3981 When multiple Filter-Rule AVPs exist, precedence should be determined 3982 as defined in [RFC5777]. 3984 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 3985 used to reference an IP filter list installed in the access device by 3986 means other than the Diameter credit-control application, e.g., 3987 locally configured or configured by another entity. 3989 If the Final-Unit-Action AVP is set to TERMINATE, or set to 3990 RESTRICT_ACCESS and the action required is allow only traffic that 3991 could be classified using an IPFilterRule, or set to REDIRECT of a 3992 type which is one of the types in the Redirect-Address-Type AVP, then 3993 the credit-control server SHOULD send the information in the Final- 3994 Unit-Indication AVP, in addition to or instead of the QoS-Final-Unit- 3995 Indication AVP. This is in order to preserve backward compatibility 3996 with credit-control clients that support only [RFC4006]. 3998 The QoS-Final-Unit-Indication AVP is defined as follows (per the 3999 grouped-avp-def of [RFC6733]): 4001 QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > 4002 { Final-Unit-Action } 4003 *[ Filter-Rule ] 4004 *[ Filter-Id ] 4005 [ Redirect-Server-Extension ] 4006 *[ AVP ] 4008 9. Result Code AVP Values 4010 This section defines new Result-Code AVP [RFC6733] values that must 4011 be supported by all Diameter implementations that conform to this 4012 specification. 4014 The Credit-Control-Answer message includes the Result-Code AVP, which 4015 may indicate that an error was present in the Credit-Control-Request 4016 message. A rejected Credit-Control-Request message SHOULD cause the 4017 user's session to be terminated. 4019 9.1. Transient Failures 4021 Errors that fall within the transient failures category are used to 4022 inform a peer that the request could not be satisfied at the time it 4023 was received, but that the request MAY be able to be satisfied in the 4024 future. 4026 DIAMETER_END_USER_SERVICE_DENIED 4010 4027 The credit-control server denies the service request due to service 4028 restrictions. If the CCR contained used-service-units, they are 4029 deducted, if possible. 4031 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 4033 The credit-control server determines that the service can be granted 4034 to the end user but that no further credit-control is needed for the 4035 service (e.g., service is free of charge). 4037 DIAMETER_CREDIT_LIMIT_REACHED 4012 4039 The credit-control server denies the service request because the end 4040 user's account could not cover the requested service. If the CCR 4041 contained used-service-units they are deducted, if possible. 4043 9.2. Permanent Failures 4045 Errors that fall within the permanent failure category are used to 4046 inform the peer that the request failed and should not be attempted 4047 again. 4049 DIAMETER_USER_UNKNOWN 5030 4051 The specified end user is unknown in the credit-control server. 4053 DIAMETER_RATING_FAILED 5031 4055 This error code is used to inform the credit-control client that the 4056 credit-control server cannot rate the service request due to 4057 insufficient rating input, an incorrect AVP combination, or an AVP or 4058 an AVP value that is not recognized or supported in the rating. The 4059 Failed-AVP AVP MUST be included and contain a copy of the entire 4060 AVP(s) that could not be processed successfully or an example of the 4061 missing AVP complete with the Vendor-Id if applicable. The value 4062 field of the missing AVP should be of correct minimum length and 4063 contain zeros. 4065 10. AVP Occurrence Table 4067 The following table presents the AVPs defined in this document and 4068 specifies in which Diameter messages they MAY or MUST NOT be present. 4069 Note that AVPs that can only be present within a Grouped AVP are not 4070 represented in this table. 4072 The table uses the following symbols: 4074 0 The AVP MUST NOT be present in the message. 4075 0+ Zero or more instances of the AVP MAY be present in the 4076 message. 4077 0-1 Zero or one instance of the AVP MAY be present in the 4078 message. It is considered an error if there is more 4079 than one instance of the AVP. 4080 1 One instance of the AVP MUST be present in the message. 4081 1+ At least one instance of the AVP MUST be present in the 4082 message. 4084 10.1. Credit-Control AVP Table 4086 The table in this section is used to represent which credit-control 4087 applications specific AVPs defined in this document are to be present 4088 in the credit-control messages. 4090 +-----------+ 4091 | Command | 4092 | Code | 4093 |-----+-----+ 4094 Attribute Name | CCR | CCA | 4095 ------------------------------|-----+-----+ 4096 Acct-Multi-Session-Id | 0-1 | 0-1 | 4097 Auth-Application-Id | 1 | 1 | 4098 CC-Correlation-Id | 0-1 | 0 | 4099 CC-Session-Failover | 0 | 0-1 | 4100 CC-Request-Number | 1 | 1 | 4101 CC-Request-Type | 1 | 1 | 4102 CC-Sub-Session-Id | 0-1 | 0-1 | 4103 Check-Balance-Result | 0 | 0-1 | 4104 Cost-Information | 0 | 0-1 | 4105 Credit-Control-Failure- | 0 | 0-1 | 4106 Handling | | | 4107 Destination-Host | 0-1 | 0 | 4108 Destination-Realm | 1 | 0 | 4109 Direct-Debiting-Failure- | 0 | 0-1 | 4110 Handling | | | 4111 Event-Timestamp | 0-1 | 0-1 | 4112 Failed-AVP | 0 | 0+ | 4113 Final-Unit-Indication | 0 | 0-1 | 4114 QoS-Final-Unit-Indication | 0 | 0-1 | 4115 Granted-Service-Unit | 0 | 0-1 | 4116 Multiple-Services-Credit- | 0+ | 0+ | 4117 Control | | | 4118 Multiple-Services-Indicator | 0-1 | 0 | 4119 Origin-Host | 1 | 1 | 4120 Origin-Realm | 1 | 1 | 4121 Origin-State-Id | 0-1 | 0-1 | 4122 Proxy-Info | 0+ | 0+ | 4123 Redirect-Host | 0 | 0+ | 4124 Redirect-Host-Usage | 0 | 0-1 | 4125 Redirect-Max-Cache-Time | 0 | 0-1 | 4126 Requested-Action | 0-1 | 0 | 4127 Requested-Service-Unit | 0-1 | 0 | 4128 Route-Record | 0+ | 0+ | 4129 Result-Code | 0 | 1 | 4130 Service-Context-Id | 1 | 0 | 4131 Service-Identifier | 0-1 | 0 | 4132 Service-Parameter-Info | 0+ | 0 | 4133 Session-Id | 1 | 1 | 4134 Subscription-Id | 0+ | 0 | 4135 Subscription-Id-Extension | 0+ | 0 | 4136 Termination-Cause | 0-1 | 0 | 4137 User-Equipment-Info | 0-1 | 0 | 4138 User-Equipment-Info-Extension | 0-1 | 0 | 4139 Used-Service-Unit | 0+ | 0 | 4140 User-Name | 0-1 | 0-1 | 4141 Validity-Time | 0 | 0-1 | 4142 ------------------------------|-----+-----+ 4144 10.2. Re-Auth-Request/Answer AVP Table 4146 This section defines AVPs that are specific to the Diameter credit- 4147 control application and that MAY be included in the Diameter Re-Auth- 4148 Request/Answer (RAR/RAA) message [RFC6733]. 4150 Re-Auth-Request/Answer command MAY include the following additional 4151 AVPs: 4153 +---------------+ 4154 | Command Code | 4155 |-------+-------+ 4156 Attribute Name | RAR | RAA | 4157 ------------------------------+-------+-------+ 4158 CC-Sub-Session-Id | 0-1 | 0-1 | 4159 G-S-U-Pool-Identifier | 0-1 | 0-1 | 4160 Service-Identifier | 0-1 | 0-1 | 4161 Rating-Group | 0-1 | 0-1 | 4162 ------------------------------+-------+-------+ 4164 11. RADIUS/Diameter Credit-Control Interworking Model 4166 This section defines the basic principles for the Diameter credit- 4167 control/RADIUS prepaid inter-working model; that is, a message 4168 translation between a RADIUS based prepaid solution and a Diameter 4169 credit-control application. A complete description of the protocol 4170 translations between RADIUS and the Diameter credit-control 4171 application is beyond the scope of this specification and SHOULD be 4172 addressed in another appropriate document, such as the RADIUS prepaid 4173 specification. 4175 The Diameter credit-control architecture may have a Translation Agent 4176 capable of translation between RADIUS prepaid and Diameter credit- 4177 control protocols. An AAA server (usually the home AAA server) may 4178 act as a Translation Agent and as a Diameter credit-control client 4179 for service elements that use credit-control mechanisms other than 4180 Diameter credit control for instance, RADIUS prepaid. In this case, 4181 the home AAA server contacts the Diameter credit-control server as 4182 part of the authorization process. The interworking architecture is 4183 illustrated Figure 9, and interworking flow in Figure 10. In a 4184 roaming situation the service element (e.g., the NAS) may be located 4185 in the visited network, and a visited AAA server is usually 4186 contacted. The visited AAA server connects then to the home AAA 4187 server. 4189 RADIUS Prepaid 4190 +--------+ +---------+ protocol +------------+ +--------+ 4191 | End |<----->| Service |<---------->| Home AAA | |Business| 4192 | User | | Element | | Server | |Support | 4193 +--------+ +-->| | |+----------+|->|System | 4194 | +---------+ ||CC Client || | | 4195 | |+----------+| | | 4196 +--------+ | +------^-----+ +----^---+ 4197 | End |<--+ Credit-Control | | 4198 | User | Protocol | | 4199 +--------+ +-------V--------+ | 4200 |Credit-Control |----+ 4201 | Server | 4202 +----------------+ 4204 Figure 9: Credit-control architecture with service element containing 4205 translation agent, translating RADIUS prepaid to Diameter credit- 4206 control protocol 4208 When the AAA server acting as a Translation Agent receives an initial 4209 RADIUS Access-Request message from service element (e.g., NAS 4210 access), it performs regular authentication and authorization. If 4211 the RADIUS Access-Request message indicates that the service element 4212 is capable of credit-control, and if the home AAA server finds that 4213 the subscriber is a prepaid subscriber, then a Diameter credit- 4214 control request SHOULD be sent toward the credit-control server to 4215 perform credit authorization and to establish a credit-control 4216 session. After the Diameter credit-control server checks the end 4217 user's account balance, rates the service, and reserves credit from 4218 the end user's account, the reserved quota is returned to the home 4219 AAA server in the Diameter Credit-Control-Answer. Then the home AAA 4220 server sends the reserved quota to the service element in the RADIUS 4221 Access-Accept. 4223 At the expiry of the allocated quota, the service element sends a new 4224 RADIUS Access-Request containing the units used this far to the home 4225 AAA server. The home AAA server shall map a RADIUS Access-Request 4226 containing the reported units to the Diameter credit-control server 4227 in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter 4228 credit-control server debits the used units from the end user's 4229 account and allocates a new quota that is returned to the home AAA 4230 server in the Diameter Credit-Control-Answer. The quota is 4231 transferred to the service element in the RADIUS Access-Accept. When 4232 the end user terminates the service, or when the entire quota has 4233 been used, the service element sends a RADIUS Access-Request. To 4234 debit the used units from the end user's account and to stop the 4235 credit-control session, the home AAA server sends a Diameter Credit- 4236 Control-Request (TERMINATION_REQUEST) to the credit-control server. 4237 The Diameter credit-control server acknowledges the session 4238 termination by sending a Diameter Credit-Control-Answer to the home 4239 AAA server. The RADIUS Access-Accept is sent to the NAS. 4241 A following diagram illustrates a RADIUS prepaid - Diameter credit- 4242 control interworking sequence. 4244 Service Element Translation Agent 4245 (e.g., NAS) (CC Client) CC Server 4246 | Access-Request | | 4247 |----------------------->| | 4248 | | CCR (initial) | 4249 | |----------------------->| 4250 | | CCA (Granted-Units) | 4251 | |<-----------------------| 4252 | Access-Accept | | 4253 | (Granted-Units) | | 4254 |<-----------------------| | 4255 : : : 4256 | Access-Request | | 4257 | (Used-Units) | | 4258 |----------------------->| | 4259 | | CCR (update, | 4260 | | Used-Units) | 4261 | |----------------------->| 4262 | | CCA (Granted-Units) | 4263 | |<-----------------------| 4264 | Access-Accept | | 4265 | (Granted-Units) | | 4266 |<-----------------------| | 4267 : : : 4268 | Access-Request | | 4269 |----------------------->| | 4270 | | CCR (terminate, | 4271 | | Used-Units) | 4272 | |----------------------->| 4273 | | CCA | 4274 | |<-----------------------| 4275 | Access-Accept | | 4276 |<-----------------------| | 4277 | | | 4279 Figure 10: Message flow example with RADIUS prepaid - Diameter 4280 credit-control interworking 4282 12. IANA Considerations 4284 This section contains the namespaces that have either been created in 4285 this specification, or the values assigned to existing namespaces 4286 managed by IANA. 4288 In the subsections below, when we speak about review by a Designated 4289 Expert, please note that the designated expert will be assigned by 4290 the IESG. Initially, such Expert discussions take place on the AAA 4291 WG mailing list. 4293 12.1. Application Identifier 4295 This specification assigns the value 4, 'Diameter Credit Control', to 4296 the Application Identifier namespace defined in [RFC6733]. See 4297 Section 1.3 for more information. 4299 12.2. Command Codes 4301 This specification uses the value 272 from the Command code namespace 4302 defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit- 4303 Control-Answer (CCA) commands. 4305 12.3. AVP Codes 4307 See Section 8 for the assignment of the namespace in this 4308 specification. 4310 12.4. Result-Code AVP Values 4312 This specification assigns the values 4010, 4011, 4012, 5030, 5031 4313 from the Result-Code AVP value namespace defined in [RFC6733]. See 4314 Section 9 for the assignment of the namespace in this specification. 4316 12.5. CC-Request-Type AVP 4318 As defined in Section 8.3, the CC-Request-Type AVP includes 4319 Enumerated type values 1 - 4. IANA has created and is maintaining a 4320 namespace for this AVP. All remaining values are available for 4321 assignment by a Designated Expert [RFC8126], under the conditions for 4322 enumerated values described in [RFC7423] Section 5.6. 4324 12.6. CC-Session-Failover AVP 4326 As defined in Section 8.4, the CC-Failover-Supported AVP includes 4327 Enumerated type values 0 - 1. IANA has created and is maintaining a 4328 namespace for this AVP. All remaining values are available for 4329 assignment by a Designated Expert [RFC8126], under the conditions for 4330 enumerated values described in [RFC7423] Section 5.6. 4332 12.7. CC-Unit-Type AVP 4334 As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated 4335 type values 0 - 5. IANA has created and is maintaining a namespace 4336 for this AVP. All remaining values are available for assignment by a 4337 Designated Expert [RFC8126], under the conditions for enumerated 4338 values described in [RFC7423] Section 5.6. 4340 12.8. Check-Balance-Result AVP 4342 As defined in Section 8.6, the Check-Balance-Result AVP includes 4343 Enumerated type values 0 - 1. IANA has created and is maintaining a 4344 namespace for this AVP. All remaining values are available for 4345 assignment by a Designated Expert [RFC8126], under the conditions for 4346 enumerated values described in [RFC7423] Section 5.6. 4348 12.9. Credit-Control AVP 4350 As defined in Section 8.13, the Credit-Control AVP includes 4351 Enumerated type values 0 - 1. IANA has created and is maintaining a 4352 namespace for this AVP. All remaining values are available for 4353 assignment by a Designated Expert [RFC8126], under the conditions for 4354 enumerated values described in [RFC7423] Section 5.6. 4356 12.10. Credit-Control-Failure-Handling AVP 4358 As defined in Section 8.14, the Credit-Control-Failure-Handling AVP 4359 includes Enumerated type values 0 - 2. IANA has created and is 4360 maintaining a namespace for this AVP. All remaining values are 4361 available for assignment by a Designated Expert [RFC8126], under the 4362 conditions for enumerated values described in [RFC7423] Section 5.6. 4364 12.11. Direct-Debiting-Failure-Handling AVP 4366 As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP 4367 includes Enumerated type values 0 - 1. IANA has created and is 4368 maintaining a namespace for this AVP. All remaining values are 4369 available for assignment by a Designated Expert [RFC8126], under the 4370 conditions for enumerated values described in [RFC7423] Section 5.6. 4372 12.12. Final-Unit-Action AVP 4374 As defined in Section 8.35, the Final-Unit-Action AVP includes 4375 Enumerated type values 0 - 2. IANA has created and is maintaining a 4376 namespace for this AVP. All remaining values are available for 4377 assignment by a Designated Expert [RFC8126], under the conditions for 4378 enumerated values described in [RFC7423] Section 5.6. 4380 12.13. Multiple-Services-Indicator AVP 4382 As defined in Section 8.40, the Multiple-Services-Indicator AVP 4383 includes Enumerated type values 0 - 1. IANA has created and is 4384 maintaining a namespace for this AVP. All remaining values are 4385 available for assignment by a Designated Expert [RFC8126], under the 4386 conditions for enumerated values described in [RFC7423] Section 5.6. 4388 12.14. Redirect-Address-Type AVP 4390 As defined in Section 8.38, the Redirect-Address-Type AVP includes 4391 Enumerated type values 0 - 3. IANA has created and is maintaining a 4392 namespace for this AVP. All remaining values are available for 4393 assignment by a Designated Expert [RFC8126], under the conditions for 4394 enumerated values described in [RFC7423] Section 5.6. 4396 12.15. Requested-Action AVP 4398 As defined in Section 8.41, the Requested-Action AVP includes 4399 Enumerated type values 0 - 3. IANA has created and is maintaining a 4400 namespace for this AVP. All remaining values are available for 4401 assignment by a Designated Expert [RFC8126], under the conditions for 4402 enumerated values described in [RFC7423] Section 5.6. 4404 12.16. Subscription-Id-Type AVP 4406 As defined in Section 8.47, the Subscription-Id-Type AVP includes 4407 Enumerated type values 0 - 4. IANA has created and is maintaining a 4408 namespace for this AVP. All remaining values are available for 4409 assignment by a Designated Expert [RFC8126], under the conditions for 4410 enumerated values described in [RFC7423] Section 5.6. 4412 12.17. Tariff-Change-Usage AVP 4414 As defined in Section 8.27, the Tariff-Change-Usage AVP includes 4415 Enumerated type values 0 - 2. IANA has created and is maintaining a 4416 namespace for this AVP. All remaining values are available for 4417 assignment by a Designated Expert [RFC8126], under the conditions for 4418 enumerated values described in [RFC7423] Section 5.6. 4420 12.18. User-Equipment-Info-Type AVP 4422 As defined in Section 8.50, the User-Equipment-Info-Type AVP includes 4423 Enumerated type values 0 - 3. IANA has created and is maintaining a 4424 namespace for this AVP. All remaining values are available for 4425 assignment by a Designated Expert [RFC8126], under the conditions for 4426 enumerated values described in [RFC7423] Section 5.6. 4428 13. Credit-Control Application Related Parameters 4430 Tx timer 4432 When real-time credit-control is required, the credit-control client 4433 contacts the credit-control server before and while the service is 4434 provided to an end user. Due to the real-time nature of the 4435 application, the communication delays SHOULD be minimized; e.g., to 4436 avoid an overly long service setup time experienced by the end user. 4437 The Tx timer is introduced to control the waiting time in the client 4438 in the Pending state. When the Tx timer elapses, the credit-control 4439 client takes an action to the end user according to the value of the 4440 Credit-Control-Failure-Handling AVP 4442 or Direct-Debiting-Failure-Handling AVP. The recommended value is 10 4443 seconds. 4445 Tcc timer 4447 The Tcc timer supervises an ongoing credit-control session in the 4448 credit-control server. It is RECOMMENDED to use the Validity-Time as 4449 input to set the Tcc timer value. In case of transient failures in 4450 the network, the Diameter credit-control server might change to Idle 4451 state. To avoid this, the Tcc timer MAY be set so that Tcc equals to 4452 2 x Validity-Time. 4454 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 4456 Client implementations may offer the possibility of locally 4457 configuring these AVPs. In such a case their value and behavior is 4458 defined in Section 5.7 for the Credit-Control-Failure-Handling and in 4459 Section 6.5 for the Direct-Debiting-Failure-Handling. 4461 14. Security Considerations 4463 Security considerations regarding the Diameter protocol itself are 4464 discussed in [RFC6733]. Use of this application of Diameter MUST 4465 take into consideration the security issues and requirements of the 4466 base protocol. 4468 This application includes a mechanism for application layer replay 4469 protection by means of the Session-Id from [RFC6733] and CC-Request- 4470 Number, which is specified in this document. The Diameter credit- 4471 control application is often used within one domain, and there may be 4472 a single hop between the peers. In these environments, the use of 4473 TLS/TCP, DTLS/SCTP or IPsec is sufficient. The details of TLS/TCP, 4474 DTLS/SCTP or IPsec related security considerations are discussed in 4475 the [RFC6733]. 4477 Because this application handles monetary transactions (directly or 4478 indirectly), it increases the interest for various security attacks. 4479 Therefore, all parties communicating with each other MUST be 4480 authenticated, including, for instance, TLS client-side 4481 authentication. In addition, authorization of the client SHOULD be 4482 emphasized; i.e., that the client is allowed to perform credit- 4483 control for a certain user. The specific means of authorization are 4484 outside of the scope of this specification but can be, for instance, 4485 manual configuration. 4487 Another kind of threat is malicious modification, injection, or 4488 deletion of AVPs or complete credit-control messages. The credit- 4489 control messages contain sensitive billing related information (such 4490 as subscription Id, granted units, used units, cost information) 4491 whose malicious modification can have financial consequences. 4492 Sometimes simply delaying the credit-control messages can cause 4493 disturbances in the credit-control client or server. 4495 Even without any modification to the messages, an adversary can 4496 invite a security threat by eavesdropping, as the transactions 4497 contain private information about the user. Also, by monitoring the 4498 credit-control messages one can collect information about the credit- 4499 control server's billing models and business relationships. 4501 When third-party relays or proxy are involved, the hop-by-hop 4502 security does not necessarily provide sufficient protection for 4503 Diameter user session. In some cases, it may be inappropriate to 4504 send Diameter messages, such as CCR and CCA, containing sensitive 4505 AVPs via untrusted Diameter proxy agents, as there are no assurances 4506 that third-party proxies will not modify the credit-control commands 4507 or AVP values. 4509 14.1. Direct Connection with Redirects 4511 A Diameter credit-control agent cannot always know whether agents 4512 between it and the end user's Diameter credit-control server are 4513 reliable. In this case, the Diameter credit-control agent doesn't 4514 have a routing entry in its Diameter Routing Table (defined in 4515 [RFC6733], section 2.7) for the realm of the credit-control server in 4516 the end user's home domain. The Diameter credit-control agent can 4517 have a default route configured to a local Redirect agent, and it 4518 redirects the CCR message to the redirect agent. The local Redirect 4519 agent then returns a redirect notification (Result-code 3006, 4520 DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as 4521 Diameter credit-control server(s) information (Redirect-Host AVP) and 4522 information (Redirect-Host-Usage AVP) about how the routing entry 4523 resulting from the Redirect-Host is to be used. The Diameter credit- 4524 control agent then forwards the CCR message directly to one of the 4525 hosts identified by the CCA message from the redirect agent. If the 4526 value of the Redirect-Host-Usage AVP is unequal to zero, all 4527 following messages are sent to the host specified in the Redirect- 4528 Host AVP until the time specified by the Redirect-Max-Cache-Time AVP 4529 is expired. 4531 There are some authorization issues even with redirects. There may 4532 be attacks toward nodes that have been properly authorized, but that 4533 abuse their authorization or have been compromised. These issues are 4534 discussed more widely in [RFC4072], Section 8. 4536 15. References 4538 15.1. Normative References 4540 [CE164] "Complement to ITU-T Recommendation E.164 (05/1997):"List 4541 of ITU-T Recommendation E.164 assigned country codes"", 4542 June 2000. 4544 [CE212] "Complement to ITU-T Recommendation E.212 (11/1997):" List 4545 of mobile country or geographical area codes"", February 4546 1999. 4548 [E164] "Recommendation E.164/I.331 (05/97): The International 4549 Public Telecommunication Numbering Plan.", 1997. 4551 [E212] "Recommendation E.212 (11/98): The international 4552 identification plan for mobile terminals and mobile 4553 users.", 1998. 4555 [EUI64] IEEE, ""Guidelines for 64-bit Global Identifier (EUI-64) 4556 Registration Authority"", March 1997, 4557 . 4560 [ISO4217] "Codes for the representation of currencies and funds, 4561 International Standard ISO 4217", 2001. 4563 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4564 DOI 10.17487/RFC0791, September 1981, 4565 . 4567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4568 Requirement Levels", BCP 14, RFC 2119, 4569 DOI 10.17487/RFC2119, March 1997, 4570 . 4572 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4573 A., Peterson, J., Sparks, R., Handley, M., and E. 4574 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4575 DOI 10.17487/RFC3261, June 2002, 4576 . 4578 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 4579 Accounting (AAA) Transport Profile", RFC 3539, 4580 DOI 10.17487/RFC3539, June 2003, 4581 . 4583 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4584 Resource Identifier (URI): Generic Syntax", STD 66, 4585 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4586 . 4588 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 4589 Loughney, "Diameter Credit-Control Application", RFC 4006, 4590 DOI 10.17487/RFC4006, August 2005, 4591 . 4593 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4594 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4595 2006, . 4597 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 4598 Ed., and A. Lior, "Traffic Classification and Quality of 4599 Service (QoS) Attributes for Diameter", RFC 5777, 4600 DOI 10.17487/RFC5777, February 2010, 4601 . 4603 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 4604 Address Text Representation", RFC 5952, 4605 DOI 10.17487/RFC5952, August 2010, 4606 . 4608 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 4609 Ed., "Diameter Base Protocol", RFC 6733, 4610 DOI 10.17487/RFC6733, October 2012, 4611 . 4613 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 4614 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 4615 . 4617 [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter 4618 Applications Design Guidelines", BCP 193, RFC 7423, 4619 DOI 10.17487/RFC7423, November 2014, 4620 . 4622 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 4623 DOI 10.17487/RFC7542, May 2015, 4624 . 4626 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4627 Writing an IANA Considerations Section in RFCs", BCP 26, 4628 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4629 . 4631 [TGPPIMEI] 4632 3rd Generation Partnership Project, "Technical 4633 Specification Group Core Network, Numbering, addressing 4634 and identification, (release 13), 3GPP TS 23.003 v. 4635 13.5.0", 2016-04. 4637 15.2. Informative References 4639 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 4640 DOI 10.17487/RFC2866, June 2000, 4641 . 4643 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 4644 "IEEE 802.1X Remote Authentication Dial In User Service 4645 (RADIUS) Usage Guidelines", RFC 3580, 4646 DOI 10.17487/RFC3580, September 2003, 4647 . 4649 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 4650 Camarillo, "Best Current Practices for Third Party Call 4651 Control (3pcc) in the Session Initiation Protocol (SIP)", 4652 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 4653 . 4655 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., 4656 and P. McCann, "Diameter Mobile IPv4 Application", 4657 RFC 4004, DOI 10.17487/RFC4004, August 2005, 4658 . 4660 [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter 4661 Extensible Authentication Protocol (EAP) Application", 4662 RFC 4072, DOI 10.17487/RFC4072, August 2005, 4663 . 4665 [TGPPCHARG] 4666 3rd Generation Partnership Project, "Technical 4667 Specification Group Services and System Aspects, Service 4668 aspects; Charging and Billing, (release 13), 3GPP TS 4669 22.115 v. 13.3.0", 2016-03. 4671 Appendix A. Acknowledgements 4673 The original authors of RFC4006 are: Harri Hakala, Leena Mattila, 4674 Juha-Pekka Koskinen, Marco Stura, and John Loughney. 4676 The authors would like to thank Bernard Aboba, Jari Arkko, Robert 4677 Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, 4678 Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, 4679 Christopher Richards, Juha Vallinen, and Mark Watson for their 4680 comments and suggestions. 4682 Appendix B. Credit-Control Sequences 4684 B.1. Flow I 4685 NAS 4686 End User (CC Client) AAA Server CC Server 4687 |(1)User Logon |(2)AA Request (CC AVPs) | 4688 |------------------>|------------------->| | 4689 | | |(3)CCR(initial, CC AVPs) 4690 | | |------------------->| 4691 | | | (4)CCA(Granted-Units) 4692 | | |<-------------------| 4693 | |(5)AA Answer(Granted-Units) | 4694 |(6)Access granted |<-------------------| | 4695 |<----------------->| | | 4696 | | | | 4697 : : : : 4698 | |(7)CCR(update,Used-Units) | 4699 | |------------------->|(8)CCR | 4700 | | | (update,Used-Units) 4701 | | |------------------->| 4702 | | |(9)CCA(Granted-Units) 4703 | |(10)CCA(Granted-Units)<------------------| 4704 | |<-------------------| | 4705 : : : : 4706 | (Auth. lifetime expires) | | 4707 | |(11) AAR (CC AVP) | | 4708 | |------------------->| | 4709 | | (12) AAA | | 4710 | |<-------------------| | 4711 : : : : 4712 : : : : 4713 |(13) User logoff | | | 4714 |------------------>|(14)CCR(term.,Used-Units) | 4715 | |------------------->|(15)CCR | 4716 | | | (term.,Used-Units) 4717 | | |------------------->| 4718 | | | (16)CCA | 4719 | | (17)CCA |<-------------------| 4720 | |<-------------------| | 4721 | |(18)STR | | 4722 | |------------------->| | 4723 | | (19)STA | | 4724 | |<-------------------| | 4726 Figure 11: Flow I 4728 A credit-control flow for Network Access Services prepaid is shown in 4729 Figure 11. The Diameter [RFC7155] is implemented in the Network 4730 Access Server (NAS). The focus of this flow is in the credit 4731 authorization. 4733 The user logs on to the network (1). The Diameter NAS sends a 4734 Diameter AA-Request (AAR) to the home Diameter AAA server. The 4735 credit-control client populates the AAR with the Credit-Control AVP 4736 set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, 4737 as usual [RFC7155]. The home Diameter AAA server performs service- 4738 specific Authentication and Authorization, as usual. The home 4739 Diameter AAA server determines that the user is a prepaid user and 4740 notices from the Credit-Control AVP that the NAS has credit-control 4741 capabilities. It sends a Diameter Credit-Control-Request with CC- 4742 Request-Type set to INITIAL_REQUEST to the Diameter credit-control 4743 server to perform credit authorization (3) and to establish a credit- 4744 control session. (The home Diameter AAA server may forward service- 4745 specific AVPs received from the NAS as input for the rating process.) 4746 The Diameter credit-control server checks the end user's account 4747 balance, rates the service, and reserves credit from the end user's 4748 account. The reserved quota is returned to the home Diameter AAA 4749 server in the Diameter Credit-Control-Answer (4). The home Diameter 4750 AAA server sends the reserved quota to the NAS in the Diameter AA- 4751 Answer (AAA). Upon successful AAA, the NAS starts the credit-control 4752 session and starts monitoring the granted units (5). The NAS grants 4753 access to the end user (6). At the expiry of the allocated quota, 4754 the NAS sends a Diameter Credit-Control-Request with CC-Request-Type 4755 set to UPDATE_REQUEST to the Home Diameter AAA server (7). This 4756 message contains the units used thus far. The home Diameter AAA 4757 server forwards the CCR to the Diameter credit-control server (8). 4758 The Diameter credit-control server debits the used units from the end 4759 user's account and allocates a new quota that is returned to the home 4760 Diameter AAA server in the Diameter Credit-Control-Answer (9). The 4761 message is forwarded to the NAS (10). During the ongoing credit- 4762 control session, the authorization lifetime expires, and the 4763 authorization/authentication client in the NAS performs service 4764 specific re-authorization to the home Diameter AAA server, as usual. 4765 The credit-control client populates the AAR with the Credit-Control 4766 AVP set to RE_AUTHORIZATION, indicating that the credit-control 4767 server shall not be contacted, as the credit authorization is 4768 controlled by the burning rate of the granted units (11). The home 4769 Diameter AAA server performs service-specific re-authorization as 4770 usual and returns the AA-Answer to the NAS (12). The end user logs 4771 off from the network (13). To debit the used units from the end 4772 user's account and to stop the credit-control session, the NAS sends 4773 a Diameter Credit-Control-Request with CC-Request-Type set to 4774 TERMINATION_REQUEST to the home Diameter AAA server (14). The home 4775 Diameter AAA server forwards the CCR to the credit-control server 4776 (15). The Diameter credit-control server acknowledges the session 4777 termination by sending a Diameter Credit-Control-Answer to the home 4778 Diameter AAA server (16). The home Diameter AAA server forwards the 4779 answer to the NAS (17). STR/STA takes place between the NAS and home 4780 Diameter AAA server, as usual (18-19). 4782 B.2. Flow II 4784 SIP Proxy/Registrar AAA 4785 A (CC Client) Server B CC Server 4786 |(i) REGISTER | | | | 4787 |------------->|(ii) | | | 4788 | |------------->| | | 4789 | |authentication & | | 4790 | |authorization | | | 4791 | |<-------------| | | 4792 |(iii)200 OK | | | 4793 |<-------------| | | 4794 : : : : 4795 |(1) INVITE | : 4796 |------------->| 4797 | |(2) CCR (Initial, SIP specific AVP) | 4798 | |------------------------------------------->| 4799 | |(3) CCA (Granted-Units) | 4800 | |<-------------------------------------------| 4801 | |(4) INVITE | | 4802 | |---------------------------->| | 4803 : : : : 4804 | |(5) CCR (update, Used-Units) | 4805 | |------------------------------------------->| 4806 | |(6) CCA (Granted-Units) | 4807 | |<-------------------------------------------| 4808 : : : : 4809 |(7) BYE | | | 4810 |------------->| | | 4811 | |(8) BYE | | 4812 | |---------------------------->| | 4813 | |(9) CCR (termination, Used-Units) | 4814 | |------------------------------------------->| 4815 | |(10) CCA () | 4816 | |<-------------------------------------------| 4817 | | | | 4819 Figure 12: Flow II 4821 This is an example of Diameter credit-control for SIP sessions. 4822 Although the flow focuses on illustrating the usage of credit-control 4823 messages, the SIP signaling is inaccurate, and the diagram is not by 4824 any means an attempt to define a service provider's SIP network. 4825 However, for the sake of this example, some assumptions are made 4826 below. 4828 Typically, prepaid services based, for example, on time usage for SIP 4829 session require an entity in the service provider network to 4830 intercept all the requests within the SIP dialog in order to detect 4831 events, such as session establishment and session release, that are 4832 essential to perform credit-control operations with the credit- 4833 control server. Therefore, in this example, it is assumed that the 4834 SIP Proxy adds a Record-Route header in the initial SIP INVITE to 4835 make sure that all the future requests in the created dialog traverse 4836 through it (for the definitions of 'Record-Route' and 'dialog' please 4837 refer to [RFC3261]). Finally, the degree of credit-control measuring 4838 of the media by the proxy depends on the business model design used 4839 in setting up the end system and proxies in the SIP network. 4841 The end user (SIP User Agent A) sends REGISTER with credentials (i). 4842 The SIP Proxy sends a request to the home AAA server to perform 4843 Multimedia authentication and authorization by using, for instance, 4844 Diameter Multimedia application (ii). The home AAA server checks 4845 that the credentials are correct and checks the user profile. 4846 Eventually, 200 OK response (iii) is sent to the UA. Note that the 4847 Authentication and Authorization is valid for the registration 4848 validity period duration (i.e., until re-registration is performed). 4849 Several SIP sessions may be established without re-authorization. 4851 UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- 4852 Control-Request (INITIAL_REQUEST) to the Diameter credit-control 4853 server (2). The Credit-Control-Request contains information obtained 4854 from the SIP signaling describing the requested service (e.g., 4855 calling party, called party, Session Description Protocol 4856 attributes). The Diameter credit-control server checks the end 4857 user's account balance, rates the service, and reserves credit from 4858 the end user's account. The reserved quota is returned to the SIP 4859 Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy 4860 forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. 4861 The media flows between them, and the SIP Proxy starts measuring the 4862 quota. At the expiry of the allocated quota, the SIP Proxy sends a 4863 Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 4864 credit-control server (5). This message contains the units used thus 4865 far. The Diameter credit-control server debits the used units from 4866 the end user's account and allocates new credit that is returned to 4867 the SIP Proxy in the Diameter Credit-Control-Answer (6). The end 4868 user terminates the service by sending a BYE (7). The SIP Proxy 4869 forwards the BYE message to UA B (8) and sends a Diameter Credit- 4870 Control-Request (TERMINATION_REQUEST) to the credit-control server 4871 (9). The Diameter credit-control server acknowledges the session 4872 termination by sending a Diameter Credit-Control-Answer to the SIP 4873 Proxy (10). 4875 B.3. Flow III 4877 MMS Server 4878 A (CC Client) B CC Server 4879 |(1) Send MMS | | | 4880 |--------------->| | | 4881 | |(2) CCR (event, DIRECT_DEBITING,| 4882 | | MMS specific AVP) | 4883 | |-------------------------------->| 4884 | |(3) CCA (Granted-Units) | 4885 | |<--------------------------------| 4886 |(4) Send MMS Ack| | | 4887 |<---------------| | | 4888 | |(5) Notify MMS | | 4889 | |--------------->| | 4890 : : : : 4891 | |(6) Retrieve MMS| | 4892 | |<---------------| | 4893 | |(7) Retrieve MMS| | 4894 | | Ack | | 4895 | |--------------->| | 4896 | | | | 4898 Figure 13: Flow III 4900 A credit-control flow for Multimedia Messaging Services is shown in 4901 Figure 13. The sender is charged as soon as the messaging server 4902 successfully stores the message. 4904 The end user A sends a Multimedia Message (MMS) to the MMS server 4905 (1). The MMS server stores the message and sends a Diameter Credit- 4906 Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) 4907 to the Diameter credit-control server (2). The Credit-Control- 4908 Request contains information about the MMS message (e.g., size, 4909 recipient address, image coding type). The Diameter credit-control 4910 server checks the end user's account balance, rates the service, and 4911 debits the service from the end user's account. The granted quota is 4912 returned to the MMS server in the Diameter Credit-Control-Answer (3). 4913 The MMS server acknowledges the successful reception of the MMS 4914 message (4). The MMS Server notifies the recipient about the new MMS 4915 (5), and end user B retrieves the message from the MMS message store 4916 (6),(7). 4918 B.4. Flow IV 4919 MMS Server 4920 Content Server (CC Client) B CC Server 4921 |(1) Send MMS | | | 4922 |--------------->| | | 4923 | |(2) CCR (event, CHECK_BALANCE, | 4924 | | MMS specific AVP) | 4925 | |-------------------------------->| 4926 | |(3) CCA (ENOUGH_CREDIT) | 4927 | |<--------------------------------| 4928 |(4) Send MMS Ack| | | 4929 |<---------------| | | 4930 | |(5) Notify MMS | | 4931 | |--------------->| | 4932 : : : : 4933 | |(6) Retrieve MMS| | 4934 | |<---------------| | 4935 | |(7) CCR (event, DIRECT_DEBITING,| 4936 | | MMS specific AVP) | 4937 | |-------------------------------->| 4938 | |(8) CCA (Granted-Units) | 4939 | |<--------------------------------| 4940 | |(9) Retrieve MMS| | 4941 | | Ack | | 4942 | |--------------->| | 4943 | | | | 4945 Figure 14: Flow IV 4947 This is an example of Diameter credit-control for direct debiting 4948 using the Multimedia Messaging Service environment. Although the 4949 flow focuses on illustrating the usage of credit-control messages, 4950 the MMS signaling is inaccurate, and the diagram is not by any means 4951 an attempt to define any service provider's MMS configuration or 4952 billing model. 4954 A credit-control flow for Multimedia Messaging Service is shown in 4955 Figure 14. The recipient is charged at the message delivery. 4957 A content server sends a Multimedia Message (MMS) to the MMS server 4958 (1) that stores the message. The message recipient will be charged 4959 for the MMS message in this case. As there can be a substantially 4960 long time between the receipt of the message at the MMS server and 4961 the actual retrieval of the message, the MMS server does not 4962 establish any credit-control session to the Diameter credit-control 4963 server but performs first only a balance check (without any credit 4964 reservation) by sending a Diameter Credit-Control-Request 4965 (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that 4966 end user B can cover the cost for the MMS (2). The Diameter credit- 4967 control server checks the end user's account balance and returns the 4968 answer to the MMS server in the Diameter Credit-Control-Answer (3). 4969 The MMS server acknowledges the successful reception of the MMS 4970 message (4). The MMS server notifies the recipient of the new MMS 4971 (5), and after some time end user B retrieves the message from the 4972 MMS message store (6). The MMS server sends a Diameter Credit- 4973 Control-Request (EVENT_REQUEST with Requested-Action: 4974 DIRECT_DEBITING) to the Diameter credit-control server (7). The 4975 Credit-Control-Request contains information about the MMS message 4976 (e.g., size, recipient address, coding type). The Diameter credit- 4977 control server checks the end user's account balance, rates the 4978 service, and debits the service from the end user's account. The 4979 granted quota is returned to the MMS server in the Diameter Credit- 4980 Control-Request (8). The MMS is transferred to end user B (9). 4982 Note that the transfer of the MMS message can take an extended time 4983 and can fail, in which case a recovery action is needed. The MMS 4984 server should return the already debited units to the user's account 4985 by using the REFUND action described in Section 6.4. 4987 B.5. Flow V 4989 SIP Controller 4990 A (CC Client) B CC Server 4991 |(1)INVITE B(SDP)| | | 4992 |--------------->| | | 4993 | |(2) CCR (event, PRICE_ENQUIRY, | 4994 | | SIP specific AVPs) | 4995 | |-------------------------------->| 4996 | |(3) CCA (Cost-Information) | 4997 | |<--------------------------------| 4998 | (4)MESSAGE(URL)| | | 4999 |<---------------| | | 5000 |(5)HTTP GET | | | 5001 |--------------->| | | 5002 |(6)HTTP POST | | | 5003 |--------------->|(7)INVITE(SDP) | | 5004 | |--------------->| | 5005 | | (8)200 OK | | 5006 | (9)200 OK |<---------------| | 5007 |<---------------| | | 5009 Figure 15: Flow V 5011 This is an example of Diameter credit-control for SIP sessions. 5012 Although the flow focuses on illustrating the usage of credit-control 5013 messages, the SIP signaling is inaccurate, and the diagram is not by 5014 any means an attempt to define a service provider's SIP network. 5016 Figure 15 is an example of Advice of Charge (AoC) service for SIP 5017 call. User A can be either a postpaid or prepaid subscriber using 5018 the AoC service. It is assumed that the SIP controller also has HTTP 5019 capabilities and delivers an interactive AoC web page with, for 5020 instance, the cost information, the details of the call derived from 5021 the SDP, and a button to accept/not accept the charges. (There may 5022 be many other ways to deliver AoC information; however, this flow 5023 focuses on the use of the credit-control messages.) The user has 5024 been authenticated and authorized prior to initiating the call and 5025 subscribed to AoC service. 5027 UA A sends an INVITE with SDP to B (1). The SIP controller 5028 determines that the user is subscribed to AoC service and sends a 5029 Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: 5030 PRICE_ENQUIRY) to the Diameter credit-control server (2). The 5031 Credit-Control-Request contains SIP specific AVPs derived from the 5032 SIP signaling, describing the requested service (e.g., calling party, 5033 called party, Session Description Protocol attributes). The Diameter 5034 credit-control server determines the cost of the service and returns 5035 the Credit-Control-Answer including the Cost-Information AVP (3). 5036 The SIP controller manufactures the AoC web page with information 5037 received in SIP signaling and with the cost information received from 5038 the credit-control server. Then it sends a SIP MESSAGE that contains 5039 a URL pointing to the AoC information web page (4). At the receipt 5040 of the SIP MESSAGE, A's UA automatically invokes the web browser that 5041 retrieves the AoC information (5). The user clicks on a proper 5042 button and accepts the charges (6). The SIP controller continues the 5043 session and sends the INVITE to the B party, which accepts the call 5044 (7,8,9). 5046 B.6. Flow VI 5048 Gaming Server 5049 End User (CC Client) CC Server 5050 | (1)Service Delivery | | 5051 |<---------------------->| | 5052 : : : 5053 : : : 5054 | |(2)CCR(event,REFUND,Requested- 5055 | |Service-Unit,Service-Parameter-Info) 5056 | |----------------------->| 5057 | | (3)CCA(Cost-Information) 5058 | |<-----------------------| 5059 | (4)Notification | | 5060 |<-----------------------| | 5062 Figure 16: Flow VI 5064 Figure 16 illustrates a credit-control flow for the REFUND case. It 5065 is assumed that there is a trusted relationship and secure connection 5066 between the Gaming server and the Diameter credit-control server. 5067 The end user may be a prepaid subscriber or a postpaid subscriber. 5069 While the end user is playing the game (1), she enters a new level 5070 that entitles her to a bonus. The Gaming server sends a Diameter 5071 Credit-Control-Request (EVENT_REQUEST with Requested-Action: 5072 REFUND_ACCOUNT) to the Diameter credit-control server (2). The 5073 Credit-Control-Request Request contains the Requested-Service-Unit 5074 AVP with the CC-Service-Specific-Units containing the number of 5075 points the user just won. The Service-Parameter-Info AVP is also 5076 included in the request and specifies the service event to be rated 5077 (e.g., Tetris Bonus). From information received, the Diameter 5078 credit-control server determines the amount to be credited, refunds 5079 the user's account, and returns the Credit-Control-Answer, including 5080 the Cost-Information AVP (3). The Cost-Information indicates the 5081 credited amount. At the first opportunity, the Gaming server 5082 notifies the end user of the credited amount (4). 5084 B.7. Flow VII 5085 SIP Controller Top-Up 5086 A (CC Client) Server B CC Server 5087 | | | | | 5088 | | (1) CCR(Update,Used-Unit) | | 5089 | |------------------------------------------>| 5090 | | (2) CCA(Final-Unit, Redirect)| 5091 | |<------------------------------------------| 5092 : : : : : 5093 : : : : : 5094 | | (3) CCR(Update, Used-Units)| | 5095 | |------------------------------------------>| 5096 | | (3a)INVITE("hold") | | 5097 | |--------------------------->| | 5098 | | | (4) CCA(Validity-Time)| 5099 | |<------------------------------------------| 5100 | (5)INVITE | (6)INVITE | | | 5101 |<--------------|------------->| | | 5102 | (7)RTP | | | 5103 |..............................| | | 5104 | | (8)BYE | | | 5105 | |<-------------| | | 5106 | | (9)CCR(Update) | | 5107 | |------------------------------------------>| 5108 | | (10)CCA(Granted-Unit) | 5109 | |<------------------------------------------| 5110 | (12)INVITE | (11)INVITE | | 5111 |<--------------|--------------------------->| | 5113 Figure 17: Flow VII 5115 Figure 17 is an example of the graceful service termination for a SIP 5116 call. It is assumed that the call is set up so that the controller 5117 is in the call as a B2BUA (Back to Back User Agent) performing third- 5118 party call control (3PCC). Note that the SIP signaling is 5119 inaccurate, as the focus of this flow is in the graceful service 5120 termination and credit-control authorization. The best practice for 5121 3PCC is defined in [RFC3725]. 5123 The call is ongoing between users A and B; user A has a prepaid 5124 subscription. At the expiry of the allocated quota, the SIP 5125 controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) 5126 to the Diameter credit-control server (1). This message contains the 5127 units used thus far. The Diameter credit-control server debits the 5128 used units from the end user's account and allocates the final quota 5129 returned to the SIP controller in the Diameter Credit-Control-Answer 5130 (2). This message contains the Final-Unit-Indication AVP with the 5131 Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to 5132 SIP URI, and the Redirect-Server-Address set to the Top-up server 5133 name (e.g., sip:sip-topup-server@domain.com). At the expiry of the 5134 final allocated quota, the SIP controller sends a Diameter Credit- 5135 Control-Request (UPDATE_REQUEST) to the Diameter credit-control 5136 server (3) and places the called party on "hold" by sending an INVITE 5137 with the appropriate connection address in the SDP (3a). The Credit- 5138 Control-Request message contains the units used thus far. The 5139 Diameter credit-control server debits the used units from the end 5140 user's account but does not make any credit reservation. The Credit- 5141 Control-Answer message, which contains the Validity-Time to supervise 5142 the graceful service termination, is returned to the SIP controller 5143 (4). The SIP controller establishes a SIP session between the 5144 prepaid user and the Top-up server (5, 6). The Top-up server plays 5145 an announcement and prompts the user to enter a credit card number 5146 and the amount of money to be used to replenish the account (7). The 5147 Top-up server validates the credit card number and replenishes the 5148 user's account (using some means outside the scope of this 5149 specification) and releases the SIP session (8). The SIP controller 5150 can now assume that communication between the prepaid user and the 5151 Top-up server took place. It sends a spontaneous Credit-Control- 5152 Request (UPDATE_REQUEST) to the Diameter credit-control server to 5153 check whether the account has been replenished (9). The Diameter 5154 credit-control server reserves credit from the end user's account and 5155 returns the reserved quota to the SIP controller in the Credit- 5156 Control-Answer (10). At this point, the SIP controller re-connects 5157 the caller and the called party (11,12). 5159 B.8. Flow VIII 5160 NAS Top-up CC 5161 End-User (CC Client) AAA Server Server Server 5162 |(1)User Logon |(2)AA Request (CC AVPs) | | 5163 |------------------>|------------------->| | | 5164 | | |(3)CCR(initial, CC AVPs) 5165 | | |------------------->| 5166 | | |(4)CCA(Final-Unit, | 5167 | | | Validity-Time)| 5168 | | |<-------------------| 5169 | |(5)AA Answer(Final-Unit,Validity-Time) | 5170 |(6)Limited Access |<-------------------| | | 5171 | granted | | | | 5172 |<----------------->| | | | 5173 | | | | | 5174 | (7)TCP/HTTP | (8)TCP/HTTP | | 5175 |<----------------->|<----------------------------->| | 5176 | (9) Replenish account | | 5177 |<------------------------------------------------->| | 5178 | | | (10)RAR | 5179 | |<-------------------|<-------------------| 5180 | | (11) RAA | | 5181 | |------------------->|------------------->| 5182 | |(12)CCR(update) | | 5183 | |------------------->|(13)CCR(Update) | 5184 | | |------------------->| 5185 | | |(14)CCA(Granted-Units) 5186 | |(15)CCA(Granted-Units)<------------------| 5187 | |<-------------------| | 5189 Figure 18: Flow VIII 5191 Figure 18 is an example of the graceful service termination initiated 5192 when the first interrogation takes place because the user's account 5193 is empty. In this example, the credit-control server supports the 5194 server-initiated credit re-authorization. The Diameter [RFC7155] is 5195 implemented in the Network Access Server (NAS). 5197 The user logs on to the network (1). The Diameter NAS sends a 5198 Diameter AA-Request to the home Diameter AAA server. The credit- 5199 control client populates the AAR with the Credit-Control AVP set to 5200 CREDIT_AUTHORIZATION, and service specific AVPs are included, as 5201 usual [RFC7155]. The home Diameter AAA server performs service 5202 specific Authentication and Authorization, as usual. The home 5203 Diameter AAA server determines that the user has a prepaid 5204 subscription and notices from the Credit-Control AVP that the NAS has 5205 credit-control capabilities. It sends a Diameter Credit-Control- 5206 Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter 5207 credit-control server to perform credit authorization (3) and to 5208 establish a credit-control session. (The home Diameter AAA server 5209 may forward service specific AVPs received from the NAS as input for 5210 the rating process.) The Diameter credit-control server checks the 5211 end user's account balance, determines that the account cannot cover 5212 the cost of the service, and initiates the graceful service 5213 termination. The Credit-Control-Answer is returned to the home 5214 Diameter AAA server (4). This message contains the Final-Unit- 5215 Indication AVP and the Validity-Time AVP set to a reasonable amount 5216 of time to give the user a chance to replenish his/her account (e.g., 5217 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- 5218 Action set to REDIRECT, the Redirect-Address-Type set to URL, and the 5219 Redirect-Server-Address set to the HTTP Top-up server name. The home 5220 Diameter AAA server sends the received credit-control AVPs to the NAS 5221 in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts 5222 the credit-control session and immediately starts the graceful 5223 service termination, as instructed by the server. The NAS grants 5224 limited access to the user (6). The HTTP client software running in 5225 the user's device opens the transport connection redirected by the 5226 NAS to the Top-up server (7,8). The user is displayed an appropriate 5227 web page on which to enter the credit card number, and the amount of 5228 money to be used to replenish the account, and with a notification 5229 message that she is granted unlimited access if the replenishment 5230 operation will be successfully executed within the next, for example, 5231 10 minutes. The Top-up server validates the credit card number and 5232 replenishes the user's account (using some means outside the scope of 5233 this specification)(9). After successful account top-up, the credit- 5234 control server sends a Re-Auth-Request message to the NAS (10). The 5235 NAS acknowledges the request by returning the Re-Auth-Answer message 5236 (11) and initiates the credit re-authorization by sending a Credit- 5237 Control-request (UPDATE_REQUEST) to the Diameter credit-control 5238 server (12,13). 5240 The Diameter credit-control server reserves credit from the end 5241 user's account and returns the reserved quota to the NAS via the home 5242 Diameter AAA server in the Credit-Control-Answer (14,15). The NAS 5243 removes the restriction placed by the graceful service termination 5244 and starts monitoring the granted units. 5246 B.9. Flow IX 5248 The Diameter credit-control application defines the Multiple- 5249 Services-Credit-Control AVP that can be used to support independent 5250 credit-control of multiple services in a single credit-control (sub-) 5251 session for service elements that have such capabilities. It is 5252 possible to request and allocate resources as a credit pool that is 5253 shared between services or rating groups. 5255 The flow example hereafter illustrates a usage scenario where the 5256 credit-control client and server support independent credit-control 5257 of multiple services, as defined in Section 5.1.2. It is assumed 5258 that Service-Identifiers, Rating-Groups, and their associated 5259 parameters (e.g., IP 5-tuple) are locally configured in the service 5260 element or provisioned by an entity other than the credit-control 5261 server. 5263 End User Service Element CC Server 5264 (CC client) 5265 |(1)User logon | | 5266 |------------------>|(2)CCR(initial, Service-Id access, | 5267 | | Access specific AVPs, | 5268 | | Multiple-Service-Indicator) | 5269 | |---------------------------------------->| 5270 | |(3)CCA(Multiple-Services-CC ( | 5271 | | Granted-Units(Total-Octets), | 5272 | | Service-Id access, | 5273 | | Validity-time, | 5274 | | G-S-U-Pool-Reference(Pool-Id 1, | 5275 | | Multiplier 10))) | 5276 | |<----------------------------------------| 5277 : : : 5278 |(4)Service-Request (Service 1) | 5279 |------------------>|(5)CCR(update, Multiple-Services-CC( | 5280 | | Requested-Units(), Service-Id 1, | 5281 | | Rating-Group 1)) | 5282 | |---------------------------------------->| 5283 | |(6)CCA(Multiple-Services-CC ( | 5284 | | Granted-Units(Time), | 5285 | | Rating-Group 1, | 5286 | | G-S-U-Pool-Reference(Pool-Id 1, | 5287 | | Multiplier 1))) | 5288 | |<----------------------------------------| 5289 : : : 5290 |(7)Service-Request (Service 2) | 5291 |------------------>| | 5292 : : : 5293 : : : 5294 |(8)Service-Request (Service 3&4) | 5295 |------------------>|(9)CCR(update, Multiple-Services-CC ( | 5296 | | Requested-Units(), Service-Id 3, | 5297 | | Rating-Group 2), | 5298 | | Multiple-Services-CC ( | 5299 | | Requested-Units(), Service-Id 4, | 5300 | | Rating-Group 3)) | 5301 | |---------------------------------------->| 5302 | |(10)CCA(Multiple-Services-CC ( | 5303 | | Granted-Units(Total-Octets), | 5304 | | Service-Id 3, Rating-Group 2, | 5305 | | Validity-time, | 5306 | | G-S-U-Pool-Reference(Pool-Id 2, | 5307 | | Multiplier 2)), | 5308 | | Multiple-Services-CC ( | 5309 | | Granted-Units(Total-Octets), | 5310 | | Service-Id 4, Rating-Group 3 | 5311 | | Validity-Time, | 5312 | | Final-Unit-Ind.(Terminate), | 5313 | | G-S-U-Pool-Reference(Pool-Id 2, | 5314 | | Multiplier 5))) | 5315 | |<----------------------------------------| 5316 : : : 5317 : : : 5318 | +--------------+ | | 5319 | |Validity time | |(11)CCR(update, | 5320 | |expires for | | Multiple-Services-CC ( | 5321 | |Service-Id | | Requested-Unit(), | 5322 | | access | | Used-Units(In-Octets,Out-Octets),| 5323 | +--------------+ | Service-Id access)) | 5324 | |---------------------------------------->| 5325 | |(12)CCA(Multiple-Services-CC ( | 5326 | | Granted-Units(Total-Octets), | 5327 | | Service-Id access, | 5328 | | Validity-Time, | 5329 | | G-S-U-Pool-Reference(Pool-Id 1, | 5330 | | Multiplier 10))) | 5331 | |<----------------------------------------| 5332 : : : 5333 : : : 5334 | +--------------+ | | 5335 | |Total Quota | |(13)CCR(update, | 5336 | |elapses for | | Multiple-Services-CC ( | 5337 | |pool 2: | | Requested-Unit(), | 5338 | |service 4 not | | Used-Units(In-Octets,Out-Octets),| 5339 | |allowed, | | Service-Id 3, Rating-group 2), | 5340 | |service 3 cont| | Multiple-Services-CC ( | 5341 | +--------------+ | Used-Units(In-Octets,Out-Octets),| 5342 | | Service-Id 4, Rating-Group 3)) | 5343 | |---------------------------------------->| 5344 | |(14)CCA(Multiple-Services-CC ( | 5345 | | Result-Code 4011, | 5346 | | Service-Id 3)) | 5347 | |<----------------------------------------| 5348 : : : 5349 : : : 5350 |(15) User logoff | | 5351 |------------------>|(16)CCR(term, | 5352 | | Multiple-Services-CC ( | 5353 | | Used-Units(In-Octets,Out-Octets),| 5354 | | Service-Id access), | 5355 | | Multiple-Services-CC ( | 5356 | | Used-Units(Time), | 5357 | | Service-Id 1, Rating-Group 1), | 5358 | | Multiple-Services-CC ( | 5359 | | Used-Units(Time), | 5360 | | Service-Id 2, Rating-Group 1)) | 5361 | |---------------------------------------->| 5362 | |(17)CCA(term) | 5363 | |<----------------------------------------| 5365 Figure 19: Flow example independent credit-control of multiple 5366 services in a credit-control (sub-)Session 5368 The user logs on to the network (1). The service element sends a 5369 Diameter Credit-Control-Request with CC-Request-Type set to 5370 INITIAL_REQUEST to the Diameter credit-control server to perform 5371 credit authorization for the bearer service (e.g., Internet access 5372 service) and to establish a credit-control session (2). In this 5373 message, the credit-control client indicates support for independent 5374 credit-control of multiple services within the session by including 5375 the Multiple-Service-Indicator AVP. The Diameter credit-control 5376 server checks the end user's account balance, with rating information 5377 received from the client (i.e., Service-Id and access specific AVPs), 5378 rates the request, and reserves credit from the end user's account. 5379 Suppose that the server reserves $5 and determines that the cost is 5380 $1/MB. It then returns to the service element a Credit-Control- 5381 Answer message that includes the Multiple-Services-Credit-Control AVP 5382 with a quota of 5MB associated to the Service-Id (access), to a 5383 multiplier value of 10, and to the Pool-Id 1 (3). 5385 The user uses Service 1 (4). The service element sends a Diameter 5386 Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to 5387 the credit-control server to perform credit authorization for service 5388 1 (5). This message includes the Multiple-Services-Credit-Control 5389 AVP to request service units for Service 1 that belong to Rating- 5390 Group 1. The Diameter credit-control server determines that Service 5391 1 draws credit resources from the same account as the access service 5392 (i.e., pool 1). It rates the request according to Service-Id/Rating- 5393 Group and updates the existing reservation by requesting more credit. 5394 Suppose that the server reserves $5 more (now the reservation is $10) 5395 and determines that the cost is $0.1/minute. The server authorizes 5396 the whole Rating-Group. It then returns to the service element a 5397 Credit-Control-Answer message that includes the Multiple-Services- 5398 Credit-Control AVP with a quota of 50min. associated to the Rating- 5399 Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The 5400 client adjusts the total amount of resources for pool 1 according the 5401 received quota, which gives S for Pool 1 = 100. 5403 The user uses Service 2, which belongs to the authorized Rating- 5404 Group, 1 (7). Resources are then consumed from the pool 1. 5406 The user now requests Services 3 and 4 as well, which are not 5407 authorized (8). The service element sends a Diameter Credit-Control- 5408 Request with CC-Request-Type set to UPDATE_REQUEST to the credit- 5409 control server in order to perform credit authorization for Services 5410 3 and 4 (9). This message includes two instances of the Multiple- 5411 Services-Credit-Control AVP to request service units for Service 3 5412 that belong to Rating-Group 2 and for Service 4 that belong to 5413 Rating-Group 3. The Diameter credit-control server determines that 5414 Services 3 and 4 draw credit resources from another account (i.e., 5415 pool 2). It checks the end user's account balance and, according to 5416 Service-Ids/Rating-Groups information, rates the request. Then it 5417 reserves credit from pool 2. 5419 For example, the server reserves $5 and determines that Service 3 5420 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes 5421 only Services 3 and 4. It returns to the service element a Credit- 5422 Control-Answer message that includes two instances of the Multiple- 5423 Services-Credit-Control AVP (10). One instance grants a quota of 5424 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and 5425 to the Pool-Id 2. The other instance grants a quota of 5 MB 5426 associated to the Service-Id 4 to a multiplier value of 5 and to the 5427 Pool-Id 2. 5429 The server also determines that pool 2 is exhausted and Service 4 is 5430 not allowed to continue after these units will be consumed. 5431 Therefore the Final-Unit-Indication AVP with action TERMINATE is 5432 associated to the Service-Id 4. The client calculates the total 5433 amount of resources that can be used for pool 2 according the 5434 received quotas and multipliers, which gives S for Pool 2 = 50. 5436 The Validity-Time for the access service expires. The service 5437 element sends a Credit-Control-Request message to the server in order 5438 to perform credit re-authorization for Service-Id (access) (11). 5439 This message carries one instance of the Multiple-Services-Credit- 5440 Control AVP that includes the units used by this service. Suppose 5441 that the total amount of used units is 4MB. The client adjusts the 5442 total amount of resources for pool 1 accordingly, which gives S for 5443 Pool 1 = 60. 5445 The server deducts $4 from the user's account and updates the 5446 reservation by requesting more credit. Suppose that the server 5447 reserves $5 more (now the reservation is $11) and already knows the 5448 cost of the Service-Id (access), which is $1/MB. It then returns to 5449 the service element a Credit-Control-Answer message that includes the 5450 Multiple-Services-Credit-Control AVP with a quota of 5 MB associated 5451 to the Service-Id (access), to a multiplier value of 10, and to the 5452 Pool-Id 1 (12). The client adjusts the total amount of resources for 5453 pool 1 according the received quota, which gives S for Pool 1 = 110. 5455 Services 3 and 4 consume the total amount of pool 2 credit resources 5456 (i.e., C1*2 + C2*5 >= S). The service element immediately starts the 5457 TERMINATE action concerning Service 4 and sends a Credit-Control- 5458 Request message with CC-Request-Type set to UPDATE_REQUEST to the 5459 credit-control server in order to perform credit re-authorization for 5460 Service 3 (13). This message contains two instances of the Multiple- 5461 Services-Credit-Control AVP to report the units used by Services 3 5462 and 4. The server deducts the last $5 from the user's account (pool 5463 2) and returns the answer with Result-Code 4011 in the Multiple- 5464 Services-Credit-Control AVP to indicate that Service 3 can continue 5465 without credit-control (14). 5467 The end user logs off from the network (15). To debit the used units 5468 from the end user's account and to stop the credit-control session, 5469 the service element sends a Diameter Credit-Control-Request with CC- 5470 Request-Type set to TERMINATION_REQUEST to the credit-control server 5471 (16). This message contains the units consumed by each of the used 5472 services in multiple instances of the Multiple-Services-Credit- 5473 Control AVP. The used units are associated with the relevant 5474 Service-Identifier and Rating-Group. The Diameter credit-control 5475 server debits the used units to the user's account (Pool 1) and 5476 acknowledges the session termination by sending a Diameter Credit- 5477 Control-Answer to the service element (17). 5479 Appendix C. Changes relative to RFC4006 5481 The following changes were made relative to RFC4006: 5483 Update references to obsolete RFC 3588 to refer to RFC 6733. 5485 Update references to obsolete RFC 4005 to refer to RFC 7155. 5487 Update references to obsolete RFC 2486 to refer to RFC 7542. 5489 Update references to current 3GPP documents. 5491 Update AVP per Errata ID 3329. 5493 Update reference to "IPsec or TLS" to be "TLS/TCP, DTLS/SCTP or 5494 IPsec". 5496 Clarify Filter-Rule AVP in Restrict Access Action. 5498 Remove Encr column from AVP flag rules. 5500 Clarify that RESTRICT_ACCESS action applies after consumption of 5501 final granted units (Section 5.6.3). 5503 Clarify that values in Used-Service-Unit AVP may exceed Granted- 5504 Service-Unit AVP (Section 8.19). 5506 Clarify that IPv6 representation in Redirect-Address-Type AVP 5507 conforms to RFC5952 (Section 8.38). 5509 Describe immediate graceful service termination procedure (in 5510 Section 5.6). 5512 Add extensible User-Equipment-Info-Extension AVP and included 5513 types (from Section 8.52 to Section 8.57). 5515 Add extensible Subscription-Id-Extension AVP and included types 5516 (from Section 8.58 to Section 8.63). 5518 Add extensible Redirect-Server-Extension AVP and included types 5519 (from Section 8.64 to Section 8.67). 5521 Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68). 5523 Updated Security Section to include language consistent with 5524 structures of latest base protocol specification. 5526 Update references to obsolete RFC 5226 to refer to RFC 8126, and 5527 resulting updateds to Section 12. 5529 Authors' Addresses 5531 Lyle Bertz (editor) 5532 Sprint 5533 6220 Sprint Parkway 5534 Overland Park, KS 66251 5535 United States 5537 Email: lyleb551144@gmail.com 5538 David Dolson (editor) 5539 Sandvine 5540 408 Albert Street 5541 Waterloo, ON N2L 3V3 5542 Canada 5544 Phone: +1 519 880 2400 5545 Email: ddolson@sandvine.com 5547 Yuval Lifshitz (editor) 5548 Sandvine 5549 408 Albert Street 5550 Waterloo, ON N2L 3V3 5551 Canada 5553 Phone: +1 519 880 2400 5554 Email: ylifshitz@sandvine.com