idnits 2.17.1 draft-ietf-dime-rfc4006bis-07.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 (March 20, 2018) is 2222 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: September 21, 2018 Sandvine 7 March 20, 2018 9 Diameter Credit-Control Application 10 draft-ietf-dime-rfc4006bis-07 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 September 21, 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. Privacy Considerations . . . . . . . . . . . . . . . . . . . 99 206 15.1. Privacy Sensitive AVPs . . . . . . . . . . . . . . . . . 99 207 15.2. Data Minimization . . . . . . . . . . . . . . . . . . . 100 208 15.3. Diameter Agents . . . . . . . . . . . . . . . . . . . . 101 209 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 210 16.1. Normative References . . . . . . . . . . . . . . . . . . 102 211 16.2. Informative References . . . . . . . . . . . . . . . . . 104 212 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 105 213 Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 105 214 B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 105 215 B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 108 216 B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 110 217 B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 110 218 B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 112 219 B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 113 220 B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 114 221 B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 116 222 B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 118 223 Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 123 224 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 226 1. Introduction 228 This document specifies a Diameter application that can be used to 229 implement real-time credit-control for a variety of end user services 230 such as network access, Session Initiation Protocol (SIP) services, 231 messaging services, and download services. It provides a general 232 solution to real-time cost and credit-control. 234 The prepaid model has been shown to be very successful, for instance, 235 in GSM networks, where network operators offering prepaid services 236 have experienced a substantial growth of their customer base and 237 revenues. Prepaid services are now cropping up in many other 238 wireless and wire line based networks. 240 In next generation wireless networks, additional functionality is 241 required beyond that specified in the Diameter base protocol. For 242 example, the 3GPP Charging and Billing requirements [TGPPCHARG] state 243 that an application must be able to rate service information in real- 244 time. In addition, it is necessary to check that the end user's 245 account provides coverage for the requested service prior to 246 initiation of that service. When an account is exhausted or expired, 247 the user must be denied the ability to compile additional chargeable 248 events. 250 A mechanism has to be provided to allow the user to be informed of 251 the charges to be levied for a requested service. In addition, there 252 are services such as gaming and advertising that may credit as well 253 as debit a user account. 255 The other Diameter applications provide service specific 256 authorization, and they do not provide credit authorization for 257 prepaid users. The credit authorization shall be generic and 258 applicable to all the service environments required to support 259 prepaid services. 261 To fulfill these requirements, it is necessary to facilitate credit- 262 control communication between the network element providing the 263 service (e.g., Network Access Server, SIP Proxy, and Application 264 Server) and a credit-control server. 266 The scope of this specification is the credit authorization. Service 267 specific authorization and authentication is out of the scope. 269 1.1. Requirements Language 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 1.2. Terminology 277 AAA Authentication, Authorization, and Accounting 279 AA answer AA answer generically refers to a service specific 280 authorization and authentication answer. AA answer commands are 281 defined in service specific authorization applications, e.g., 282 [RFC7155] and [RFC4004]. 284 AA request AA request generically refers to a service specific 285 authorization and authentication request. AA request commands are 286 defined in service specific authorization applications e.g., 287 [RFC7155] and [RFC4004]. 289 Credit-control Credit-control is a mechanism that directly interacts 290 in real-time with an account and controls or monitors the charges 291 related to the service usage. Credit-control is a process of 292 checking whether credit is available, credit-reservation, 293 deduction of credit from the end user account when service is 294 completed and refunding of reserved credit that is not used. 296 Diameter Credit-control Server A Diameter credit-control server acts 297 as a prepaid server, performing real-time rating and credit- 298 control. It is located in the home domain and is accessed by 299 service elements or Diameter AAA servers in real-time for purpose 300 of price determination and credit-control before the service event 301 is delivered to the end-user. It may also interact with business 302 support systems. 304 Diameter Credit-control Client A Diameter credit-control client is 305 an entity that interacts with a credit-control server. It 306 monitors the usage of the granted quota according to instructions 307 returned by credit-control server. 309 Interrogation The Diameter credit-control client uses interrogation 310 to initiate a session based credit-control process. During the 311 credit-control process, it is used to report the used quota and 312 request a new one. An interrogation maps to a request/answer 313 transaction. 315 One-time event Basically, a request/answer transaction of type 316 event. 318 Rating The act of determining the cost of the service event. 320 Service A type of task performed by a service element for an end 321 user. 323 Service Element A network element that provides a service to the end 324 users. The Service Element may include the Diameter credit- 325 control client, or another entity (e.g., RADIUS AAA server) that 326 can act as a credit-control client on behalf of the Service 327 Element. In the latter case, the interface between the Service 328 Element and the Diameter credit-control client is outside the 329 scope of this specification. Examples of the Service Elements 330 include Network Access Server (NAS), SIP Proxy, and Application 331 Servers such as messaging server, content server, and gaming 332 server. 334 Service Event An event relating to a service provided to the end 335 user. 337 Session based credit-control A credit-control process that makes use 338 of several interrogations: the first, a possible intermediate, and 339 the final. The first interrogation is used to reserve money from 340 the user's account and to initiate the process. The intermediate 341 interrogations may be needed to request new quota while the 342 service is being rendered. The final interrogation is used to 343 exit the process. The credit-control server is required to 344 maintain session state for session-based credit-control. 346 1.3. Advertising Application Support 348 Diameter nodes conforming to this specification MUST advertise 349 support by including the value of 4 in the Auth-Application-Id of the 350 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 351 command [RFC6733]. 353 2. Architecture Models 355 The current accounting models specified in the Radius Accounting 356 [RFC2866] and Diameter base [RFC6733] are not sufficient for real- 357 time credit-control, where credit-worthiness is to be determined 358 prior to service initiation. Also, the existing Diameter 359 authorization applications, [RFC7155] and [RFC4004], only provide 360 service authorization, but do not provide credit authorization for 361 prepaid users. In order to support real-time credit-control, a new 362 type of server is needed in the AAA infrastructure: Diameter credit- 363 control server. The Diameter credit-control server is the entity 364 responsible for credit authorization for prepaid subscribers. 366 A service element may authenticate and authorize the end user with 367 the AAA server by using AAA protocols; e.g., RADIUS or a Diameter 368 base protocol with a possible Diameter application. 370 Accounting protocols such as RADIUS accounting and the Diameter base 371 accounting protocol can be used to provide accounting data to the 372 accounting server after service is initiated, and to provide possible 373 interim reports until service completion. However, for real-time 374 credit-control, these authorization and accounting models are not 375 sufficient. 377 When real-time credit-control is required, the credit-control client 378 contacts the credit-control server with information about a possible 379 service event. The credit-control process is performed to determine 380 potential charges and to verify whether the end user's account 381 balance is sufficient to cover the cost of the service being 382 rendered. 384 Figure 1 illustrates the typical credit-control architecture, which 385 consists of a Service Element with an embedded Diameter credit- 386 control client, a Diameter credit-control server, and an AAA server. 387 A Business Support System is usually deployed; it includes at least 388 the billing functionality. The credit-control server and AAA server 389 in this architecture model are logical entities. The real 390 configuration can combine them into a single host. The credit- 391 control protocol is the Diameter base protocol with the Diameter 392 credit-control application. 394 When an end user requests services such as SIP or messaging, the 395 request is typically forwarded to a service element (e.g., SIP Proxy) 396 in the user's home domain. In some cases it might be possible that 397 the service element in the visited domain can offer services to the 398 end user; however, a commercial agreement must exist between the 399 visited domain and the home domain. Network access is an example of 400 a service offered in the visited domain where the NAS, through an AAA 401 infrastructure, authenticates and authorizes the user with the user's 402 home network. 404 Service Element AAA and CC 405 +----------+ +---------+ Protocols+-----------+ +--------+ 406 | End |<---->|+-------+|<------------>| AAA | |Business| 407 | User | +->|| CC || | Server |->|Support | 408 | | | || Client||<-----+ | | |System | 409 +----------+ | |+-------+| | +-----------+ | | 410 | +---------+ | ^ +--------+ 411 +----------+ | | CC Protocol | ^ 412 | End |<--+ | +-----v----+ | 413 | User | +------>|Credit- | | 414 +----------+ Credit-Control |Control |--------+ 415 Protocol |Server | 416 +----------+ 418 Figure 1: Typical credit-control architecture 420 There can be multiple credit-control servers in the system for 421 redundancy and load balancing. The system can also contain separate 422 rating server(s), and accounts can be located in a centralized 423 database. To ensure that the end user's account is not debited or 424 credited multiple times for the same service event, only one place in 425 the credit-control system should perform duplicate detection. System 426 internal interfaces can exist to relay messages between servers and 427 an account manager. However, the detailed architecture of the 428 credit-control system and its interfaces are implementation specific 429 and are out of scope of this specification. 431 Protocol transparent Diameter relays can exist between the credit- 432 control client and credit-control server. Also, Diameter Redirect 433 agents that refer credit-control clients to credit-control servers 434 and allow them to communicate directly can exist. These agents 435 transparently support the Diameter credit-control application. The 436 different roles of Diameter Agents are defined in Diameter base 437 [RFC6733], section 2.8. 439 If Diameter credit-control proxies exist between the credit-control 440 client and the credit-control server, they MUST advertise the 441 Diameter credit-control application support. 443 3. Credit-Control Messages 445 This section defines new Diameter message Command-Code values that 446 MUST be supported by all Diameter implementations that conform to 447 this specification. The Command Codes are as follows: 449 +------------------------+---------+------+-----------+ 450 | Command-Name | Abbrev. | Code | Reference | 451 +------------------------+---------+------+-----------+ 452 | Credit-Control-Request | CCR | 272 | 3.1 | 453 | Credit-Control-Answer | CCA | 272 | 3.2 | 454 +------------------------+---------+------+-----------+ 456 Table 1: Credit-Control Commands 458 Diameter Base [RFC6733] defines in the section 3.2 the Command Code 459 format specification. These formats are observed in Credit-Control 460 messages. 462 3.1. Credit-Control-Request (CCR) Command 464 The Credit-Control-Request message (CCR) is indicated by the command- 465 code field being set to 272 and the 'R' bit being set in the Command 466 Flags field. It is used between the Diameter credit-control client 467 and the credit-control server to request credit authorization for a 468 given service. 470 The Auth-Application-Id MUST be set to the value 4, indicating the 471 Diameter credit-control application. 473 Message Format 474 ::= < Diameter Header: 272, REQ, PXY > 475 < Session-Id > 476 { Origin-Host } 477 { Origin-Realm } 478 { Destination-Realm } 479 { Auth-Application-Id } 480 { Service-Context-Id } 481 { CC-Request-Type } 482 { CC-Request-Number } 483 [ Destination-Host ] 484 [ User-Name ] 485 [ CC-Sub-Session-Id ] 486 [ Acct-Multi-Session-Id ] 487 [ Origin-State-Id ] 488 [ Event-Timestamp ] 489 *[ Subscription-Id ] 490 *[ Subscription-Id-Extension ] 491 [ Service-Identifier ] 492 [ Termination-Cause ] 493 [ Requested-Service-Unit ] 494 [ Requested-Action ] 495 *[ Used-Service-Unit ] 496 [ Multiple-Services-Indicator ] 497 *[ Multiple-Services-Credit-Control ] 498 *[ Service-Parameter-Info ] 499 [ CC-Correlation-Id ] 500 [ User-Equipment-Info ] 501 [ User-Equipment-Info-Extension ] 502 *[ Proxy-Info ] 503 *[ Route-Record ] 504 *[ AVP ] 506 3.2. Credit-Control-Answer (CCA) Command 508 The Credit-Control-Answer message (CCA) is indicated by the command- 509 code field being set to 272 and the 'R' bit being cleared in the 510 Command Flags field. It is used between the credit-control server 511 and the Diameter credit-control client to acknowledge a Credit- 512 Control-Request command. 514 Message Format 515 ::= < Diameter Header: 272, PXY > 516 < Session-Id > 517 { Result-Code } 518 { Origin-Host } 519 { Origin-Realm } 520 { Auth-Application-Id } 521 { CC-Request-Type } 522 { CC-Request-Number } 523 [ User-Name ] 524 [ CC-Session-Failover ] 525 [ CC-Sub-Session-Id ] 526 [ Acct-Multi-Session-Id ] 527 [ Origin-State-Id ] 528 [ Event-Timestamp ] 529 [ Granted-Service-Unit ] 530 *[ Multiple-Services-Credit-Control ] 531 [ Cost-Information] 532 [ Final-Unit-Indication ] 533 [ QoS-Final-Unit-Indication ] 534 [ Check-Balance-Result ] 535 [ Credit-Control-Failure-Handling ] 536 [ Direct-Debiting-Failure-Handling ] 537 [ Validity-Time ] 538 *[ Redirect-Host ] 539 [ Redirect-Host-Usage ] 540 [ Redirect-Max-Cache-Time ] 541 *[ Proxy-Info ] 542 *[ Route-Record ] 543 *[ Failed-AVP ] 544 *[ AVP ] 546 4. Credit-Control Application Overview 548 The credit authorization process takes place before and during 549 service delivery to the end user and generally requires the user's 550 authentication and authorization before any request is sent to the 551 credit-control server. The credit-control application defined in 552 this specification supports two different credit authorization 553 models: credit authorization with money reservation and credit 554 authorization with direct debiting. In both models, the credit- 555 control client requests credit authorization from the credit-control 556 server prior to allowing any service to be delivered to the end user. 558 In the first model, the credit-control server rates the request, 559 reserves a suitable amount of money from the user's account, and 560 returns the corresponding amount of credit resources. Note that 561 credit resources may not imply actual monetary credit; credit 562 resources may be granted to the credit-control client in the form of 563 units (e.g., data volume or time) to be metered. 565 Upon receipt of a successful credit authorization answer with a 566 certain amount of credit resources, the credit-control client allows 567 service delivery to the end user and starts monitoring the usage of 568 the granted resources. When the credit resources granted to the user 569 have been consumed or the service has been successfully delivered or 570 terminated, the credit-control client reports back to the server the 571 used amount. The credit-control server deducts the used amount from 572 the end user's account; it may perform rating and make a new credit 573 reservation if the service delivery is continuing. This process is 574 accomplished with session based credit-control that includes the 575 first interrogation, possible intermediate interrogations, and the 576 final interrogation. For session based credit-control, both the 577 credit-control client and the credit-control server are required to 578 maintain credit-control session state. Session based credit-control 579 is described in more detail, with more variations, in Section 5. 581 In contrast, credit authorization with direct debiting is a single 582 transaction process wherein the credit-control server directly 583 deducts a suitable amount of money from the user's account as soon as 584 the credit authorization request is received. Upon receipt of a 585 successful credit authorization answer, the credit-control client 586 allows service delivery to the end user. This process is 587 accomplished with the one-time event. Session state is not 588 maintained. 590 In a multi-service environment, an end user can issue an additional 591 service request (e.g., data service) during an ongoing service (e.g., 592 voice call) toward the same account. Alternatively, during an active 593 multimedia session, an additional media type is added to the session, 594 causing a new simultaneous request toward same account. 595 Consequently, this needs to be considered when credit resources are 596 granted to the services. 598 The credit-control application also supports operations such as 599 service price enquiry, user's balance check, and refund of credit on 600 the user's account. These operations are accomplished with the one- 601 time event. Session state is not maintained. 603 A flexible credit-control application specific failure handling is 604 defined in which the home service provider can model the credit- 605 control client behavior according to its own credit risk management 606 policy. 608 The Credit-Control-Failure-Handling AVP and the Direct-Debiting- 609 Failure-Handling AVP are defined to determine what is done if the 610 sending of credit-control messages to the credit-control server has 611 been temporarily prevented. The usage of the Credit-Control-Failure- 612 Handling AVP and the Direct-Debiting-Failure-Handling AVP allows 613 flexibility, as failure handling for the credit-control session and 614 one-time event direct debiting may be different. 616 4.1. Service-Specific Rating Input and Interoperability 618 The Diameter credit-control application defines the framework for 619 credit-control; it provides generic credit-control mechanisms 620 supporting multiple service applications. The credit-control 621 application, therefore, does not define AVPs that could be used as 622 input in the rating process. Listing the possible services that 623 could use this Diameter application is out of scope for this generic 624 mechanism. 626 It is reasonable to expect that a service level agreement will exist 627 between providers of the credit-control client and the credit-control 628 server covering the charging, services offered, roaming agreements, 629 agreed rating input (i.e., AVPs), and so on. 631 Therefore, it is assumed that a Diameter credit-control server will 632 provide service only for Diameter credit-control clients that have 633 agreed beforehand as to the content of credit-control messages. 634 Naturally, it is possible that any arbitrary Diameter credit-control 635 client can interchange credit-control messages with any Diameter 636 credit-control server, but with a higher likelihood that unsupported 637 services/AVPs could be present in the credit-control message, causing 638 the server to reject the request with an appropriate result-code. 640 4.1.1. Specifying Rating Input AVPs 642 There are two ways to provide rating input to the credit-control 643 server: either by using AVPs or by including them in the Service- 644 Parameter-Info AVP. The general principles for sending rating 645 parameters are as follows: 647 1a. The service SHOULD re-use existing AVPs if it can use AVPs 648 defined in existing Diameter applications (e.g., [RFC7155] for 649 network access services). Re-use of existing AVPs is strongly 650 recommended in [RFC6733]. 652 For AVPs of type Enumerated, the service may require a new value to 653 be defined. Allocation of new AVP values is done as specified in 654 [RFC6733], section 1.3. 656 1b. New AVPs can be defined if the existing AVPs do not provide 657 sufficient rating information. In this case, the procedures defined 658 in [RFC6733] for creating new AVPs MUST be followed. 660 1c. For services specific only to one vendor's implementation, a 661 Vendor-Specific AVP code for Private use can be used. Where a 662 Vendor-Specific AVP is implemented by more than one vendor, 663 allocation of global AVPs is encouraged instead; refer to [RFC6733]. 665 2. The Service-Parameter-Info AVP MAY be used as a container to pass 666 legacy rating information in its original encoded form (e.g., ASN.1 667 BER). This method can be used to avoid unnecessary conversions from 668 an existing data format to an AVP format. In this case, the rating 669 input is embedded in the Service-Parameter-Info AVP as defined in 670 Section 8.43. 672 New service applications SHOULD favor the use of explicitly defined 673 AVPs as described in items 1a and 1b, to simplify interoperability. 675 4.1.2. Service-Specific Documentation 677 The service specific rating input AVPs, the contents of the Service- 678 Parameter-Info AVP or Service-Context-Id AVP (defined in 679 Section 8.42) are not within the scope of this document. To 680 facilitate interoperability, it is RECOMMENDED that the rating input 681 and the values of the Service-Context-Id be coordinated via an 682 informational RFC or other permanent and readily available reference. 683 The specification of another cooperative standardization body (e.g., 684 3GPP, OMA, or 3GPP2) SHOULD be used. However, private services may 685 be deployed that are subject to agreements between providers of the 686 credit-control server and client. In this case, vendor specific AVPs 687 can be used. 689 This specification, together with the above service specific 690 documents, governs the credit-control message. Service specific 691 documents define which existing AVPs or new AVPs are used as input to 692 the rating process (i.e., those that do not define new credit-control 693 applications), and thus have to be included in the Credit-Control- 694 Request command by a Diameter credit-control client supporting a 695 given service as *[AVP]. Should Service-Parameter-Info be used, then 696 the service specific document MUST specify the exact content of this 697 grouped AVP. 699 The Service-Context-Id AVP MUST be included at the command level of a 700 Credit-Control Request to identify the service specific document that 701 applies to the request. The specific service or rating group the 702 request relates to is uniquely identified by the combination of 703 Service-Context-Id and Service-Identifier or Rating-Group. 705 4.1.3. Handling of Unsupported/Incorrect Rating Input 707 Diameter credit-control implementations are required to support the 708 Mandatory rating AVPs defined in service specific documentation of 709 the services they support, according to the 'M' bit rules in 710 [RFC6733]. 712 If a rating input required for the rating process is incorrect in the 713 Credit-control request, or if the credit-control server does not 714 support the requested service context (identified by the Service- 715 Context-Id AVP at command level), the Credit-control answer MUST 716 contain the error code DIAMETER_RATING_FAILED. A CCA message with 717 this error MUST contain one or more Failed-AVP AVPs containing the 718 missing and/or unsupported AVPs that caused the failure. A Diameter 719 credit-control client that receives the error code 720 DIAMETER_RATING_FAILED in response to a request MUST NOT send similar 721 requests in the future. 723 4.1.4. RADIUS Vendor-Specific Rating Attributes 725 When service specific documents include RADIUS vendor specific 726 attributes that could be used as input in the rating process, the 727 rules described in [RFC7155] for formatting the Diameter AVP MUST be 728 followed. 730 For example, if the AVP code used is the vendor attribute type code, 731 the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be 732 set to the IANA Vendor identification value. The Diameter AVP data 733 field contains only the attribute value of the RADIUS attribute. 735 5. Session Based Credit-Control 737 5.1. General Principles 739 For a session-based credit-control, several interrogations are 740 needed: the first, intermediate (optional) and the final 741 interrogations. This is illustrated in Figure 3 and Figure 4. 743 If the credit-control client performs credit-reservation before 744 granting service to the end user, it MUST use several interrogations 745 toward the credit-control server (i.e., session based credit- 746 control). In this case, the credit-control server MUST maintain the 747 credit-control session state. 749 Each credit-control session MUST have a globally unique Session-Id as 750 defined in [RFC6733], which MUST NOT be changed during the lifetime 751 of a credit-control session. 753 Certain applications require multiple credit-control sub-sessions. 754 These applications would send messages with a constant Session-Id 755 AVP, but with a different CC-Sub-Session-Id AVP. If several credit 756 sub-sessions will be used, all sub-sessions MUST be closed separately 757 before the main session is closed so that units per sub-session may 758 be reported. The absence of this AVP implies that no sub-sessions 759 are in use. 761 Note that the service element might send a service specific re- 762 authorization message to the AAA server due to expiration of the 763 authorization-lifetime during an ongoing credit-control session. 764 However, the service specific re-authorization does not influence the 765 credit authorization that is ongoing between the credit-control 766 client and credit-control server, as credit authorization is 767 controlled by the burning rate of the granted quota. 769 If service specific re-authorization fails, the user will be 770 disconnected, and the credit-control client MUST send a final 771 interrogation to the credit-control server. 773 The Diameter credit-control server may seek to control the validity 774 time of the granted quota and/or the production of intermediate 775 interrogations. Thus, it MAY include the Validity-Time AVP in the 776 answer message to the credit-control client. Upon expiration of the 777 Validity-Time, the credit-control client MUST generate a credit- 778 control update request and report the used quota to the credit- 779 control server. It is up to the credit-control server to determine 780 the value of the Validity-Time to be used for consumption of the 781 granted service units. If the Validity-Time is used, its value 782 SHOULD be given as input to set the session supervision timer Tcc 783 (the session supervision timer MAY be set to two times the value of 784 the Validity-Time, as defined in Section 13). Since credit-control 785 update requests are also produced at the expiry of granted service 786 units and/or for mid-session service events, the omission of 787 Validity-Time does not mean that intermediate interrogation for the 788 purpose of credit-control is not performed. 790 5.1.1. Basic Tariff-Time Change Support 792 The Diameter credit-control server and client MAY optionally support 793 a tariff change mechanism. The Diameter credit-control server may 794 include a Tariff-Time-Change AVP in the answer message. Note that 795 the granted units should be allocated based on the worst-case 796 scenario in case of forthcoming tariff change, so that the overall 797 reported used units would never exceed the credit reservation. 799 When the Diameter credit-control client reports the used units and a 800 tariff change has occurred during the reporting period, the Diameter 801 credit-control client MUST separately itemize the units used before 802 and after the tariff change. If the client is unable to distinguish 803 whether units straddling the tariff change were used before or after 804 the tariff change, the credit-control client MUST itemize those units 805 in a third category. 807 If a client does not support the tariff change mechanism and it 808 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 809 terminate the credit-control session, giving a reason of 810 DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 812 For time based services, the quota is continuously consumed at the 813 regular rate of 60 seconds per minute. At the time when credit 814 resources are allocated, the server already knows how many units will 815 be consumed before the tariff time change and how many units will be 816 consumed afterward. Similarly, the server can determine the units 817 consumed at the before rate and the units consumed at the rate 818 afterward in the event that the end-user closes the session before 819 the consumption of the allotted quota. There is no need for 820 additional traffic between client and server in the case of tariff 821 time changes for continuous time based service. Therefore, the 822 tariff change mechanism is not used for such services. For time- 823 based services in which the quota is NOT continuously consumed at a 824 regular rate, the tariff change mechanism described for volume and 825 event units MAY be used. 827 5.1.2. Credit-Control for Multiple Services within a (sub-)Session 829 When multiple services are used within the same user session and each 830 service or group of services is subject to different cost, it is 831 necessary to perform credit-control for each service independently. 832 Making use of credit-control sub-sessions to achieve independent 833 credit-control will result in increased signaling load and usage of 834 resources in both the credit-control client and the credit-control 835 server. For instance, during one network access session the end user 836 may use several http-services subject to different access cost. The 837 network access specific attributes such as the quality of service 838 (QoS) are common to all the services carried within the access 839 bearer, but the cost of the bearer may vary depending on its content. 841 To support these scenarios optimally, the credit-control application 842 enables independent credit-control of multiple services in a single 843 credit-control (sub-)session. This is achieved by including the 844 optional Multiple-Services-Credit-Control AVP in Credit-Control- 845 Request/Answer messages. It is possible to request and allocate 846 resources as a credit pool shared between multiple services. The 847 services can be grouped into rating groups in order to achieve even 848 further aggregation of credit allocation. It is also possible to 849 request and allocate quotas on a per service basis. Where quotas are 850 allocated to a pool by means of the Multiple-Services-Credit-Control 851 AVP, the quotas remain independent objects that can be re-authorized 852 independently at any time. Quotas can also be given independent 853 result codes, validity times, and Final-Unit-Indications or QoS- 854 Final-Unit-Indications. 856 A Rating-Group gathers a set of services, identified by a Service- 857 Identifier, and subject to the same cost and rating type (e.g., $0.1/ 858 minute). It is assumed that the service element is provided with 859 Rating-Groups, Service-Identifiers, and their associated parameters 860 that define what has to be metered by means outside the scope of this 861 specification. (Examples of parameters associated to Service- 862 Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers enable 863 authorization on a per-service based credit as well as itemized 864 reporting of service usage. It is up to the credit-control server 865 whether to authorize credit for one or more services or for the whole 866 rating-group. However, the client SHOULD always report used units at 867 the finest supported level of granularity. Where quota is allocated 868 to a rating-group, all the services belonging to that group draw from 869 the allotted quota. The following is a graphical representation of 870 the relationship between service-identifiers, rating-groups, credit 871 pools, and credit-control (sub-)session. 873 DCC (Sub-)Session 874 | 875 +------------+-----------+-------------+--------------- + 876 | | | | | 877 Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z 878 \ / \ / / 879 \ / \ / / 880 \ / Rating-Group 1.......Rating-Group n 881 \ / | | 882 Quota ---------------Quota Quota 883 | / | 884 | / | 885 Credit-Pool Credit-Pool 887 Figure 2: Multiple-Service (sub)-Session Example 889 If independent credit-control of multiple services is used, the 890 Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- 891 Indication AVP SHOULD be present either in the Multiple-Services- 892 Credit-Control AVP(s) or at command level as single AVPs. However, 893 the Result-Code AVP MAY be present both on the command level and 894 within the Multiple-Services-Credit-Control AVP. If the Result-Code 895 AVP on the command level indicates a value other than SUCCESS, then 896 the Result-Code AVP on command level takes precedence over any 897 included in the Multiple-Services-Credit-Control AVP. 899 The credit-control client MUST indicate support for independent 900 credit-control of multiple services within a (sub-)session by 901 including the Multiple-Services-Indicator AVP in the first 902 interrogation. A credit-control server not supporting this feature 903 MUST treat the Multiple-Services-Indicator AVP and any received 904 Multiple-Services-Credit-Control AVPs as invalid AVPs. 906 If the client indicated support for independent credit-control of 907 multiple services, a credit-control server that wishes to use the 908 feature MUST return the granted units within the Multiple-Services- 909 Credit-Control AVP associated to the corresponding service-identifier 910 and/or rating-group. 912 To avoid a situation where several parallel (and typically also 913 small) credit reservations must be made on the same account (i.e., 914 credit fragmentation), and also to avoid unnecessary load on the 915 credit-control server, it is possible to provide service units as a 916 pool that applies to multiple services or rating groups. This is 917 achieved by providing the service units in the form of a quota for a 918 particular service or rating group in the Multiple-Services-Credit- 919 Control AVP, and also by including a reference to a credit pool for 920 that unit type. 922 The reference includes a multiplier derived from the rating 923 parameter, which translates from service units of a specific type to 924 the abstract service units in the pool. For instance, if the rating 925 parameter for service 1 is $1/MB and the rating parameter for service 926 2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2, 927 respectively. 929 If S is the total service units within the pool, M1, M2, ..., Mn are 930 the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., 931 Cn are the used resources within the session, then the pool credit is 932 exhausted and re-authorization MUST be sought when: 934 C1*M1 + C2*M2 + ... + Cn*Mn >= S 936 The total credit in the pool, S, is calculated from the quotas, which 937 are currently allocated to the pool as follows: 939 S = Q1*M1 + Q2*M2 + ... + Qn*Mn 941 If services or rating groups are added to or removed from the pool, 942 then the total credit is adjusted appropriately. Note that when the 943 total credit is adjusted because services or rating groups are 944 removed from the pool, the value that need to be removed is the 945 consumed one (i.e., Cx*Mx). 947 Re-authorizations for an individual service or rating group may be 948 sought at any time; for example, if a 'non-pooled' quota is used up 949 or the Validity-Time expires. 951 Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same 952 G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit- 953 Control AVP (Section 8.16) along with the Granted-Service-Unit AVP, 954 then these MUST have different CC-Unit-Type values, and they all draw 955 from the credit pool separately. For instance, if one multiplier for 956 time (M1t) and one multiplier for volume (M1v) are given, then the 957 used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t 958 is the time unit and C1v is the volume unit. 960 Where service units are provided within a Multiple-Services-Credit- 961 Control AVP without a corresponding G-S-U-Pool-Reference AVP, then 962 these are handled independently from any credit pool and from any 963 other services or rating groups within the session. 965 The credit pool concept is an optimal tool to avoid the over- 966 reservation effect of the basic single quota tariff time change 967 mechanism (the mechanism described in Section 5.1.1). Therefore, 968 Diameter credit-control clients and servers implementing the 969 independent credit-control of multiple services SHOULD leverage the 970 credit pool concept when supporting the tariff time change. The 971 Diameter credit-control server SHOULD include both the Tariff-Time- 972 Change and Tariff-Change-Usage AVPs in two quota allocations in the 973 answer message (i.e., two instances of the Multiple-Services-Credit- 974 Control AVP). One of the granted units is allocated to be used 975 before the potential tariff change, while the second granted units 976 are for use after a tariff change. Both granted unit quotas MUST 977 contain the same Service-Identifier and/or Rating-Group. This dual 978 quota mechanism ensures that the overall reported used units would 979 never exceed the credit reservation. The Diameter credit-control 980 client reports both the used units before and after the tariff change 981 in a single instance of the Multiple-Services-Credit-Control AVP. 983 The failure handling for credit-control sessions is defined in 984 Section 5.7 and reflected in the basic credit-control state machine 985 in Section 7. Credit-control clients and servers implementing the 986 independent credit-control of multiple services in a (sub-)session 987 functionality MUST ensure failure handling and general behavior fully 988 consistent with the above mentioned sections, while maintaining the 989 ability to handle parallel ongoing credit re-authorization within a 990 (sub-)session. Therefore, it is RECOMMENDED that Diameter credit- 991 control clients maintain a PendingU message queue and restart the Tx 992 timer (Section 13) every time a CCR message with the value 993 UPDATE_REQUEST is sent while they are in PendingU state. When 994 answers to all pending messages are received, the state machine moves 995 to OPEN state, and Tx is stopped. Naturally, the action performed 996 when a problem for the session is detected according to Section 5.7 997 affects all the ongoing services (e.g., failover to a backup server 998 if possible affect all the CCR messages with the value UPDATE_REQUEST 999 in the PendingU queue). 1001 Since the client may send CCR messages with the value UPDATE_REQUEST 1002 while in PendingU (i.e., without waiting for an answer to ongoing 1003 credit re-authorization), the time space between these requests may 1004 be very short, and the server may not have received the previous 1005 request(s) yet. Therefore, in this situation the server may receive 1006 out of sequence requests and SHOULD NOT consider this an error 1007 condition. A proper answer is to be returned to each of those 1008 requests. 1010 5.2. First Interrogation 1012 When session based credit-control is required (e.g., the 1013 authentication server indicated a prepaid user), the first 1014 interrogation MUST be sent before the Diameter credit-control client 1015 allows any service event to the end user. The CC-Request-Type is set 1016 to the value INITIAL_REQUEST in the request message. 1018 If the Diameter credit-control client knows the cost of the service 1019 event (e.g., a content server delivering ringing tones may know their 1020 cost) the monetary amount to be charged is included in the Requested- 1021 Service-Unit AVP. If the Diameter credit-control client does not 1022 know the cost of the service event, the Requested-Service-Unit AVP 1023 MAY contain the number of requested service events. Where the 1024 Multiple-Services-Credit-Control AVP is used, it MUST contain the 1025 Requested-Service-Unit AVP to indicate that the quota for the 1026 associated service/rating-group is requested. In the case of 1027 multiple services, the Service-Identifier AVP or the Rating-Group AVP 1028 within the Multiple-Services-Credit-Control AVP always indicates the 1029 service concerned. Additional service event information to be rated 1030 MAY be sent as service specific AVPs or MAY be sent within the 1031 Service-Parameter-Info AVP at command level. The Service-Context-Id 1032 AVP indicates the service specific document applicable to the 1033 request. 1035 The Event-Timestamp AVP SHOULD be included in the request and 1036 contains the time when the service event is requested in the service 1037 element. The Subscription-Id AVP or the Subscription-Id-Extension 1038 AVP SHOULD be included to identify the end user in the credit-control 1039 server. The credit-control client MAY include the User-Equipment- 1040 Info AVP or User-Equipment-Info-Extension AVP so that the credit- 1041 control server has some indication of the type and capabilities of 1042 the end user access device. How the credit-control server uses this 1043 information is outside the scope of this document. 1045 The credit-control server SHOULD rate the service event and make a 1046 credit-reservation from the end user's account that covers the cost 1047 of the service event. If the type of the Requested-Service-Unit AVP 1048 is money, no rating is needed, but the corresponding monetary amount 1049 is reserved from the end user's account. 1051 The credit-control server returns the Granted-Service-Unit AVP in the 1052 Answer message to the Diameter credit-control client. The Granted- 1053 Service-Unit AVP contains the amount of service units that the 1054 Diameter credit-control client can provide to the end user until a 1055 new Credit-Control-Request MUST be sent to the credit-control server. 1056 If several unit types are sent in the Answer message, the credit- 1057 control client MUST handle each unit type separately. The type of 1058 the Granted-Service-Unit AVP can be time, volume, service specific, 1059 or money, depending on the type of service event. The unit type(s) 1060 SHOULD NOT be changed within an ongoing credit-control session. 1062 There MUST be a maximum of one instance of the same unit type in one 1063 Answer message. However, if multiple quotas are conveyed to the 1064 credit-control client in the Multiple-Services-Credit-Control AVPs, 1065 it is possible to carry two instances of the same unit type 1066 associated to a service-identifier/rating-group. This is typically 1067 the case when a tariff time change is expected and the credit-control 1068 server wants to make a distinction between the granted quota before 1069 and after tariff change. 1071 If the credit-control server determines that no further control is 1072 needed for the service, it MAY include the result code indicating 1073 that the credit-control is not applicable (e.g., if the service is 1074 free of charge). This result code at command level implies that the 1075 credit-control session is to be terminated. 1077 The Credit-Control-Answer message MAY also include the Final-Unit- 1078 Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that 1079 the answer message contains the final units for the service. After 1080 the end user has consumed these units, the Diameter credit-control- 1081 client MUST behave as described in Section 5.6. 1083 This document defines two different approaches to perform the first 1084 interrogation to be used in different network architectures. The 1085 first approach uses credit-control messages after the user's 1086 authorization and authentication takes place. The second approach 1087 uses service specific authorization messages to perform the first 1088 interrogation during the user's authorization/authentication phase, 1089 and credit-control messages for the intermediate and final 1090 interrogations. If an implementation of the credit-control client 1091 supports both the methods, determining which method to use SHOULD be 1092 configurable. 1094 In service environments such as the Network Access Server (NAS), it 1095 is desired to perform the first interrogation as part of the 1096 authorization/authentication process for the sake of protocol 1097 efficiency. Further credit authorizations after the first 1098 interrogation are performed with credit-control commands defined in 1099 this specification. Implementations of credit-control clients 1100 operating in the mentioned environments SHOULD support this method. 1101 If the credit-control server and AAA server are separate physical 1102 entities, the service element sends the request messages to the AAA 1103 server, which then issues an appropriate request or proxies the 1104 received request forward to the credit-control server. 1106 In other service environments, such as the 3GPP network and some SIP 1107 scenarios, there is a substantial decoupling between registration/ 1108 access to the network and the actual service request (i.e., the 1109 authentication/authorization is executed once at registration/access 1110 to the network and is not executed for every service event requested 1111 by the subscriber). In these environments, it is more appropriate to 1112 perform the first interrogation after the user has been authenticated 1113 and authorized. The first, the intermediate, and the final 1114 interrogations are executed with credit-control commands defined in 1115 this specification. 1117 Other IETF standards or standards developed by other standardization 1118 bodies may define the most suitable method in their architectures. 1120 5.2.1. First Interrogation after Authorization and Authentication 1122 The Diameter credit-control client in the service element may get 1123 information from the authorization server as to whether credit- 1124 control is required, based on its knowledge of the end user. If 1125 credit-control is required the credit-control server needs to be 1126 contacted prior to initiating service delivery to the end user. The 1127 accounting protocol and the credit-control protocol can be used in 1128 parallel. The authorization server may also determine whether the 1129 parallel accounting stream is required. 1131 The following diagram illustrates the case where both protocols are 1132 used in parallel and the service element sends credit-control 1133 messages directly to the credit-control server. More credit-control 1134 sequence examples are given in Annex A. 1136 Diameter 1137 End User Service Element AAA Server CC Server 1138 (CC Client) 1139 | Registration | AA request/answer(accounting,cc or both)| 1140 |<----------------->|<------------------>| | 1141 | : | | | 1142 | : | | | 1143 | Service Request | | | 1144 |------------------>| | | 1145 | | CCR(Initial,Credit-Control AVPs) | 1146 | +|---------------------------------------->| 1147 | CC stream|| | CCA(Granted-Units)| 1148 | +|<----------------------------------------| 1149 | Service Delivery | | | 1150 |<----------------->| ACR(start,Accounting AVPs) | 1151 | : |------------------->|+ | 1152 | : | ACA || Accounting stream | 1153 | |<-------------------|+ | 1154 | : | | | 1155 | : | | | 1156 | | CCR(Update,Used-Units) | 1157 | |---------------------------------------->| 1158 | | | CCA(Granted-Units)| 1159 | |<----------------------------------------| 1160 | : | | | 1161 | : | | | 1162 | End of Service | | | 1163 |------------------>| CCR(Termination, Used-Units) | 1164 | |---------------------------------------->| 1165 | | | CCA | 1166 | |<----------------------------------------| 1167 | | ACR(stop) | | 1168 | |------------------->| | 1169 | | ACA | | 1170 | |<-------------------| | 1172 Figure 3: Protocol example with first interrogation after user's 1173 authorization/authentication 1175 5.2.2. Authorization Messages for First Interrogation 1177 The Diameter credit-control client in the service element MUST 1178 actively co-operate with the authorization/authentication client in 1179 the construction of the AA request by adding appropriate credit- 1180 control AVPs. The credit-control client MUST add the Credit-Control 1181 AVP to indicate credit-control capabilities and MAY add other 1182 relevant credit-control specific AVPs to the proper authorization/ 1183 authentication command to perform the first interrogation toward the 1184 home Diameter AAA server. The Auth-Application-Id is set to the 1185 appropriate value, as defined in the relevant service specific 1186 authorization/authentication application document (e.g., [RFC7155], 1187 [RFC4004]). The home Diameter AAA server authenticates/authorizes 1188 the subscriber and determines whether credit-control is required. 1190 If credit-control is not required for the subscriber, the home 1191 Diameter AAA server will respond as usual, with an appropriate AA 1192 answer message. If credit-control is required for the subscriber and 1193 the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was 1194 present in the authorization request, the home AAA server MUST 1195 contact the credit-control server to perform the first interrogation. 1196 If credit-control is required for the subscriber and the Credit- 1197 Control AVP was not present in the authorization request, the home 1198 AAA server MUST send an authorization reject answer message. 1200 The Diameter AAA server supporting credit-control is required to send 1201 the Credit-Control-Request command (CCR) defined in this document to 1202 the credit-control server. The Diameter AAA server populates the CCR 1203 based on service specific AVPs used for input to the rating process, 1204 and possibly on credit-control AVPs received in the AA request. The 1205 credit-control server will reserve money from the user's account, 1206 will rate the request and will send a Credit-Control-Answer message 1207 to the home Diameter AAA server. The answer message includes the 1208 Granted-Service-Unit AVP(s) and MAY include other credit-control 1209 specific AVPs, as appropriate. Additionally, the credit-control 1210 server MAY set the Validity-Time and MAY include the Credit-Control- 1211 Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to 1212 determine what to do if the sending of credit-control messages to the 1213 credit-control server has been temporarily prevented. 1215 Upon receiving the Credit-Control-Answer message from the credit- 1216 control server, the home Diameter AAA server will populate the AA 1217 answer with the received credit-control AVPs and with the appropriate 1218 service attributes according to the authorization/authentication 1219 specific application (e.g., [RFC7155], [RFC4004]). It will then 1220 forward the packet to the credit-control client. If the home 1221 Diameter AAA server receives a credit-control reject message, it will 1222 simply generate an appropriate authorization reject message to the 1223 credit-control client, including the credit-control specific error 1224 code. 1226 In this model, the credit-control client sends further credit-control 1227 messages to the credit-control server via the home Diameter AAA 1228 server. Upon receiving a successful authorization answer message 1229 with the Granted-Service-Unit AVP(s), the credit-control client will 1230 grant the service to the end user and will generate an intermediate 1231 credit-control request, as required by using credit-control commands. 1233 The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 1234 (for how to produce unique value for the CC-Request-Number AVP, see 1235 Section 8.2). 1237 If service specific re-authorization is performed (i.e., 1238 authorization-lifetime expires), the credit-control client MUST add 1239 to the service specific re-authorization request the Credit-Control 1240 AVP with a value set to RE_AUTHORIZATION to indicate that the credit- 1241 control server MUST NOT be contacted. When session based credit- 1242 control is used for the subscriber, a constant credit-control message 1243 stream flows through the home Diameter AAA server. The home Diameter 1244 AAA server can make use of this credit-control message flow to deduce 1245 that the user's activity is ongoing; therefore, it is recommended to 1246 set the authorization-lifetime to a reasonably high value when 1247 credit-control is used for the subscriber. 1249 In this scenario, the home Diameter AAA server MUST advertise support 1250 for the credit-control application to its peers during the capability 1251 exchange process. 1253 The following diagram illustrates the use of authorization/ 1254 authentication messages to perform the first interrogation. The 1255 parallel accounting stream is not shown in the figure. 1257 Service Element Diameter 1258 End User (CC Client) AAA Server CC Server 1259 | Service Request | AA Request (CC AVPs) | 1260 |------------------>|------------------->| | 1261 | | | CCR(Initial, CC AVPs) 1262 | | |------------------->| 1263 | | | CCA(Granted-Units) 1264 | | |<-------------------| 1265 | | AA Answer(Granted-Units) | 1266 | Service Delivery |<-------------------| | 1267 |<----------------->| | | 1268 | : | | | 1269 | : | | | 1270 | : | | | 1271 | | | | 1272 | | CCR(Update,Used-Units) | 1273 | |------------------->| CCR(Update,Used-Units) 1274 | | |------------------->| 1275 | | | CCA(Granted-Units)| 1276 | | CCA(Granted-Units)|<-------------------| 1277 | |<-------------------| | 1278 | : | | | 1279 | : | | | 1280 | End of Service | | | 1281 |------------------>| CCR(Termination,Used-Units) | 1282 | |------------------->| CCR(Term.,Used-Units) 1283 | | |------------------->| 1284 | | | CCA | 1285 | | CCA |<-------------------| 1286 | |<-------------------| | 1288 Figure 4: Protocol example with use of the authorization messages for 1289 the first interrogation 1291 5.3. Intermediate Interrogation 1293 When all the granted service units for one unit type are spent by the 1294 end user or the Validity-Time is expired, the Diameter credit-control 1295 client MUST send a new Credit-Control-Request to the credit-control 1296 server. In the event that credit-control for multiple services is 1297 applied in one credit-control session (i.e., units associated to 1298 Service-Identifier(s) or Rating-Group are granted), a new Credit- 1299 Control-Request MUST be sent to the credit-control server when the 1300 credit reservation has been wholly consumed, or upon expiration of 1301 the Validity-Time. It is always up to the Diameter credit-control 1302 client to send a new request well in advance of the expiration of the 1303 previous request in order to avoid interruption in the service 1304 element. Even if the granted service units reserved by the credit- 1305 control server have not been spent upon expiration of the Validity- 1306 Time, the Diameter credit-control client MUST send a new Credit- 1307 Control-Request to the credit-control server. 1309 There can also be mid-session service events, which might affect the 1310 rating of the current service events. In this case, a spontaneous 1311 updating (a new Credit-Control-Request) SHOULD be sent including 1312 information related to the service event even if all the granted 1313 service units have not been spent or the Validity-Time has not 1314 expired. 1316 When the used units are reported to the credit-control server, the 1317 credit-control client will not have any units in its possession 1318 before new granted units are received from the credit-control server. 1319 When the new granted units are received, these units apply from the 1320 point where the measurement of the reported used units stopped. 1321 Where independent credit-control of multiple services is supported, 1322 this process may be executed for one or more services, a single 1323 rating-group, or a pool within the (sub)session. 1325 The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the 1326 intermediate request message. The Subscription-Id AVP or 1327 Subscription-Id-Extension AVP SHOULD be included in the intermediate 1328 message to identify the end user in the credit-control server. The 1329 Service-Context-Id AVP indicates the service specific document 1330 applicable to the request. 1332 The Requested-Service-Unit AVP MAY contain the new amount of 1333 requested service units. Where the Multiple-Services-Credit-Control 1334 AVP is used, it MUST contain the Requested-Service-Unit AVP if a new 1335 quota is requested for the associated service/rating-group. The 1336 Used-Service-Unit AVP contains the amount of used service units 1337 measured from the point when the service became active or, if interim 1338 interrogations are used during the session, from the point when the 1339 previous measurement ended. The same unit types used in the previous 1340 message SHOULD be used. If several unit types were included in the 1341 previous answer message, the used service units for each unit type 1342 MUST be reported. 1344 The Event-Timestamp AVP SHOULD be included in the request and 1345 contains the time of the event that triggered the sending of the new 1346 Credit-Control-Request. 1348 The credit-control server MUST deduct the used amount from the end 1349 user's account. It MAY rate the new request and make a new credit- 1350 reservation from the end user's account that covers the cost of the 1351 requested service event. 1353 A Credit-Control-Answer message with the CC-Request-Type AVP set to 1354 the value UPDATE_REQUEST MAY include the Cost-Information AVP 1355 containing the accumulated cost estimation for the session, without 1356 taking any credit-reservation into account. 1358 The Credit-Control-Answer message MAY also include the Final-Unit- 1359 Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that 1360 the answer message contains the final units for the service. After 1361 the end user has consumed these units, the Diameter credit-control- 1362 client MUST behave as described in Section 5.6. 1364 There can be several intermediate interrogations within a session. 1366 5.4. Final Interrogation 1368 When the end user terminates the service session, or when the 1369 graceful service termination described in Section 5.6 takes place, 1370 the Diameter credit-control client MUST send a final Credit-Control- 1371 Request message to the credit-control server. The CC-Request-Type 1372 AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id 1373 AVP indicates the service specific document applicable to the 1374 request. 1376 The Event-Timestamp AVP SHOULD be included in the request and 1377 contains the time when the session was terminated. 1379 The Used-Service-Unit AVP contains the amount of used service units 1380 measured from the point when the service became active or, if interim 1381 interrogations are used during the session, from the point when the 1382 previous measurement ended. If several unit types were included in 1383 the previous answer message, the used service units for each unit 1384 type MUST be reported. 1386 After final interrogation, the credit-control server MUST refund the 1387 reserved credit amount not used to the end user's account and deduct 1388 the used monetary amount from the end user's account. 1390 A Credit-Control-Answer message with the CC-Request-Type set to the 1391 value TERMINATION_REQUEST MAY include the Cost-Information AVP 1392 containing the estimated total cost for the session in question. 1394 If the user logs off during an ongoing credit-control session, or if 1395 some other reason causes the user to become logged off (e.g., final- 1396 unit indication causes user logoff according to local policy), the 1397 service element, according to application specific policy, may send a 1398 Session-Termination-Request (STR) to the home Diameter AAA server as 1399 usual [RFC6733]. Figure 5 illustrates the case when the final-unit 1400 indication causes user logoff upon consumption of the final granted 1401 units and the generation of STR. 1403 Service Element AAA Server CC Server 1404 End User (CC Client) 1405 | Service Delivery | | | 1406 |<----------------->| | | 1407 | : | | | 1408 | : | | | 1409 | : | | | 1410 | | | | 1411 | | CCR(Update,Used-Units) | 1412 | |------------------->| CCR(Update,Used-Units) 1413 | | |------------------->| 1414 | | CCA(Final-Unit, Terminate) 1415 | CCA(Final-Unit, Terminate)|<-------------------| 1416 | |<-------------------| | 1417 | : | | | 1418 | : | | | 1419 | Disconnect user | | | 1420 |<------------------| CCR(Termination,Used-Units) | 1421 | |------------------->| CCR(Term.,Used-Units) 1422 | | |------------------->| 1423 | | | CCA | 1424 | | CCA |<-------------------| 1425 | |<-------------------| | 1426 | | STR | | 1427 | |------------------->| | 1428 | | STA | | 1429 | |<-------------------| | 1431 Figure 5: User disconnected due to exhausted account 1433 5.5. Server-Initiated Credit Re-Authorization 1435 The Diameter credit-control application supports server-initiated re- 1436 authorization. The credit-control server MAY optionally initiate the 1437 credit re-authorization by issuing a Re-Auth-Request (RAR) as defined 1438 in the Diameter base protocol [RFC6733]. The Auth-Application-Id in 1439 the RAR message is set to 4 to indicate Diameter Credit Control, and 1440 the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. 1442 Section 5.1.2 defines the feature to enable credit-control for 1443 multiple services within a single (sub-)session where the server can 1444 authorize credit usage at a different level of granularity. Further, 1445 the server may provide credit resources to multiple services or 1446 rating groups as a pool (see Section 5.1.2 for details and 1447 definitions). Therefore, the server, based on its service logic and 1448 its knowledge of the ongoing session, can decide to request credit 1449 re-authorization for a whole (sub-)session, a single credit pool, a 1450 single service, or a single rating-group. To request credit re- 1451 authorization for a credit pool, the server includes in the RAR 1452 message the G-S-U-Pool-Identifier AVP indicating the affected pool. 1453 To request credit re-authorization for a service or a rating-group, 1454 the server includes in the RAR message the Service-Identifier AVP or 1455 the Rating-Group AVP, respectively. To request credit re- 1456 authorization for all the ongoing services within the (sub-)session, 1457 the server includes none of the above mentioned AVPs in the RAR 1458 message. 1460 If a credit re-authorization is not already ongoing (i.e., the 1461 credit-control session is in Open state), a credit-control client 1462 that receives an RAR message with Session-Id equal to a currently 1463 active credit-control session MUST acknowledge the request by sending 1464 the Re-Auth-Answer (RAA) message and MUST initiate the credit re- 1465 authorization toward the server by sending a Credit-Control-Request 1466 message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. 1467 The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the 1468 RAA message to indicate that an additional message (i.e., CCR message 1469 with the value UPDATE_REQUEST) is required to complete the procedure. 1470 If a quota was allocated to the service, the credit-control client 1471 MUST report the used quota in the Credit-Control-Request. Note that 1472 the end user does not need to be prompted for the credit re- 1473 authorization, since the credit re-authorization is transparent to 1474 the user (i.e., it takes place exclusively between the credit-control 1475 client and the credit-control server). 1477 Where multiple services in a user's session are supported, the 1478 procedure in the above paragraph will be executed at the granularity 1479 requested by the server in the RAR message. 1481 If credit re-authorization is ongoing at the time when the RAR 1482 message is received (i.e., RAR-CCR collision), the credit-control 1483 client successfully acknowledges the request but does not initiate a 1484 new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) 1485 SHOULD be used in the RAA message to indicate that a credit re- 1486 authorization procedure is already ongoing (i.e., the client was in 1487 PendingU state when the RAR was received). The credit-control server 1488 SHOULD process the Credit-Control-Request as if it was received in 1489 answer to the server initiated credit re-authorization, and should 1490 consider the server initiated credit re-authorization process 1491 successful upon reception of the Re-Auth-Answer message. 1493 When multiple services are supported in a user's session, the server 1494 may request credit re-authorization for a credit pool (or for the 1495 (sub-)session) while a credit re-authorization is already ongoing for 1496 some of the services or rating-groups. In this case, the client 1497 acknowledges the server request with an RAA message and MUST send a 1498 new Credit-Control-Request message to perform re-authorization for 1499 the remaining services/rating-groups. The Result-Code 2002 1500 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to 1501 indicate that an additional message (i.e., CCR message with value 1502 UPDATE_REQUEST) is required to complete the procedure. The server 1503 processes the received requests and returns an appropriate answer to 1504 both requests. 1506 The above-defined procedures are enabled for each of the possibly 1507 active Diameter credit-control sub-sessions. The server MAY request 1508 re-authorization for an active sub-session by including the CC-Sub- 1509 Session-Id AVP in the RAR message in addition to the Session-Id AVP. 1511 5.6. Graceful Service Termination 1513 When the user's account runs out of money, the user may not be 1514 allowed to compile additional chargeable events. However, the home 1515 service provider may offer some services; for instance, access to a 1516 service portal where it is possible to refill the account, for which 1517 the user is allowed to benefit for a limited time. The length of 1518 this time is usually dependent on the home service provider policy. 1520 This section defines the optional graceful service termination 1521 feature that MAY be supported by the credit-control server. Credit- 1522 control client implementations MUST support the Final-Unit-Indication 1523 AVP or QoS-Final-Unit-Indication AVP with at least the teardown of 1524 the ongoing service session once the subscriber has consumed all the 1525 final granted units. 1527 Where independent credit-control of multiple services in a single 1528 credit-control (sub-)session is supported, it is possible to use the 1529 graceful service termination for each of the services/rating-groups 1530 independently. Naturally, the graceful service termination process 1531 defined in the following sub-sections will apply to the specific 1532 service/rating-group as requested by the server. 1534 In some service environments (e.g., NAS), the graceful service 1535 termination may be used to redirect the subscriber to a service 1536 portal for online balance refill or other services offered by the 1537 home service provider. In this case, the graceful termination 1538 process installs a set of packet filters to restrict the user's 1539 access capability only to/from the specified destinations. All the 1540 IP packets not matching the filters will be dropped or, possibly, re- 1541 directed to the service portal. The user may also be sent an 1542 appropriate notification as to why the access has been limited. 1543 These actions may be communicated explicitly from the server to the 1544 client or may be configured per-service at the client. Explicitly 1545 signaled redirect or restrict instructions always take precedence 1546 over configured ones. 1548 It is also possible use the graceful service termination to connect 1549 the prepaid user to a top-up server that plays an announcement and 1550 prompts the user to replenish the account. In this case, the credit- 1551 control server sends only the address of the top-up server where the 1552 prepaid user shall be connected after the final granted units have 1553 been consumed. An example of this is given Appendix B.7. 1555 The credit-control server MAY initiate the graceful service 1556 termination by including the Final-Unit-Indication AVP or the QoS- 1557 Final-Unit-Indication AVP in the Credit-Control-Answer to indicate 1558 that the message contains the final units for the service. 1560 When the credit-control client receives the Final-Unit-Indication AVP 1561 or the QoS-Final-Unit-Indication AVP in the answer from the server, 1562 its behavior depends on the value indicated in the Final-Unit-Action 1563 AVP. The server may request the following actions: TERMINATE, 1564 REDIRECT, or RESTRICT_ACCESS. 1566 The following figure illustrates the graceful service termination 1567 procedure described in the following sub-sections. 1569 Diameter 1570 End User Service Element AAA Server CC Server 1571 (CC Client) 1572 | Service Delivery | | | 1573 |<----------------->| | | 1574 | |CCR(Update,Used-Units) | 1575 | |------------------->|CCR(Update,Used-Units) 1576 | : | |------------------->| 1577 | : | |CCA(Final-Unit,Action) 1578 | : | |<-------------------| 1579 | |CCA(Final-Unit,Action) | 1580 | |<-------------------| | 1581 | | | | 1582 | : | | | 1583 | : | | | 1584 | : | | | 1585 | /////////////// |CCR(Update,Used-Units) | 1586 |/Final Units End/->|------------------->|CCR(Update,Used-Units) 1587 |/Action and // | |------------------->| 1588 |/Restrictions // | | CCA(Validity-Time)| 1589 |/Start // | CCA(Validity-Time)|<-------------------| 1590 | ///////////// |<-------------------| | 1591 | : | | | 1592 | : | | | 1593 | Replenish Account +-------+ | 1594 |<-------------------------------------------->|Account| | 1595 | | | +-------+ | 1596 | | | RAR | 1597 | + | RAR |<===================| 1598 | | |<===================| | 1599 | | | RAA | | 1600 | ///////////// | |===================>| RAA | 1601 | /If supported / | | CCR(Update) |===================>| 1602 | /by CC Server/ | |===================>| CCR(Update) | 1603 | ///////////// | | |===================>| 1604 | | | | CCA(Granted-Unit)| 1605 | | | CCA(Granted-Unit)|<===================| 1606 | Restrictions ->+ |<===================| | 1607 | removed | | | 1608 | : | | | 1609 | OR | CCR(Update) | | 1610 | Validity-Time ->|------------------->| CCR(Update) | 1611 | expires | |------------------->| 1612 | | | CCA(Granted-Unit)| 1613 | | CCA(Granted-Unit)|<-------------------| 1614 | Restrictions ->|<-------------------| | 1615 | removed | | | 1616 Figure 6: Optional graceful service termination procedure 1618 In addition, the credit-control server MAY reply with Final-Unit- 1619 Indication AVP or QoS-Final-Unit-Indication AVP holding a G-S-U AVP 1620 with a zero grant, indicating that the service SHOULD be terminated 1621 immediately, and no further reporting is required. A following 1622 figure illustrates a graceful service termination procedure that 1623 applies immediately after receiving a zero grant. 1625 Diameter 1626 End User Service Element AAA Server CC Server 1627 (CC Client) 1628 | Service Delivery | | | 1629 |<----------------->| | | 1630 | |CCR(Update,Used-Units) | 1631 | |------------------->|CCR(Update,Used-Units) 1632 | : | |------------------->| 1633 | : | |CCA(Final-Unit,Action, 1634 | : | | Zero G-S-U) 1635 | : | |<-------------------| 1636 | |CCA(Final-Unit,Action, | 1637 | | Zero G-S-U) | 1638 | |<-------------------| | 1639 | /////////////// | | | 1640 |/Action and // | | | 1641 |/Restrictions // | | | 1642 |/Start // | | | 1643 | ///////////// | | | 1644 | : | | | 1645 | : | | | 1647 Figure 7: Optional immediate graceful service termination procedure 1649 5.6.1. Terminate Action 1651 The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP 1652 with Final-Unit-Action TERMINATE does not include any other 1653 information. When the subscriber has consumed the final granted 1654 units, the service element MUST terminate the service. This is the 1655 default handling applicable whenever the credit-control client 1656 receives an unsupported Final-Unit-Action value and MUST be supported 1657 by all the Diameter credit-control client implementations conforming 1658 to this specification. A final Credit-Control-Request message to the 1659 credit-control server MUST be sent if the Final-Unit-Indication AVP 1660 or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was 1661 present at command level. The CC-Request-Type AVP in the request is 1662 set to the value TERMINATION_REQUEST. 1664 5.6.2. Redirect Action 1666 The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP 1667 with Final-Unit-Action REDIRECT indicates to the service element 1668 supporting this action that, upon consumption of the final granted 1669 units, the user MUST be re-directed to the address specified in the 1670 Redirect-Server AVP or Redirect-Server-Extension AVP as follows. 1672 The credit-control server sends the Redirect-Server AVP or Redirect- 1673 Server-Extension AVP in the Credit-Control-Answer message. In such a 1674 case, the service element MUST redirect or connect the user to the 1675 destination specified in the Redirect-Server AVP or Redirect-Server- 1676 Extension AVP, if possible. When the end user is redirected (by 1677 using protocols others than Diameter) to the specified server or 1678 connected to the top-up server, an additional authorization (and 1679 possibly authentication) may be needed before the subscriber can 1680 replenish the account; however, this is out of the scope of this 1681 specification. 1683 In addition to the Redirect-Server AVP or Redirect-Server-Extension 1684 AVP, the credit-control server MAY include one or more Restriction- 1685 Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more 1686 Filter-Id AVPs in the Credit-Control-Answer message to enable the 1687 user to access other services (for example, zero-rated services). In 1688 such a case, the access device MUST drop all the packets not matching 1689 the IP filters specified in the Restriction-Filter-Rule AVPs, Filter- 1690 Rule AVPs or Filter-Id AVPs. If enforcement actions other than 1691 allowing the packets (e.g., QoS), are indicated in the Filter-Rule 1692 AVPs or Filter-Id AVPs, they SHOULD be performed as well. In 1693 addition, if possible, to redirecting the user to the destination 1694 specified in the Redirect-Server AVP or Redirect-Server-Extension 1695 AVP. 1697 An entity other than the credit-control server may provision the 1698 access device with appropriate IP packet filters to be used in 1699 conjunction with the Diameter credit-control application. This case 1700 is considered in Section 5.6.3. 1702 When the final granted units have been consumed, the credit-control 1703 client MUST perform an intermediate interrogation. The purpose of 1704 this interrogation is to indicate to the credit-control server that 1705 the specified action started and to report the used units. The 1706 credit-control server MUST deduct the used amount from the end user's 1707 account but MUST NOT make a new credit reservation. The credit- 1708 control client, however, may send intermediate interrogations before 1709 all the final granted units have been consumed for which rating and 1710 money reservation may be needed; for instance, upon Validity-Time 1711 expires or upon mid-session service events that affect the rating of 1712 the current service. Therefore, the credit-control client MUST NOT 1713 include any rating related AVP in the request sent once all the final 1714 granted units have been consumed as an indication to the server that 1715 the requested final unit action started, rating and money reservation 1716 are not required (when the Multiple-Services-Credit-Control AVP is 1717 used, the Service-Identifier or Rating-Group AVPs is included to 1718 indicate the concerned services). Naturally, the Credit-Control- 1719 Answer message does not contain any granted service unit and MUST 1720 include the Validity-Time AVP to indicate to the credit-control 1721 client how long the subscriber is allowed to use network resources 1722 before a new intermediate interrogation is sent to the server. 1724 At the expiry of Validity-Time, the credit-control client sends a 1725 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does 1726 not include the Used-Service-Unit AVP, as there is no allotted quota 1727 to report. The credit-control server processes the request and MUST 1728 perform the credit reservation. If during this time the subscriber 1729 did not replenish his/her account, whether he/she will be 1730 disconnected or will be granted access to services not controlled by 1731 a credit-control server for an unlimited time is dependent on the 1732 home service provider policy (note: the latter option implies that 1733 the service element should not remove the restriction filters upon 1734 termination of the credit-control). The server will return the 1735 appropriate Result-Code (see Section 9.1) in the Credit-Control- 1736 Answer message in order to implement the policy-defined action. 1737 Otherwise, new quota will be returned, the service element MUST 1738 remove all the possible restrictions activated by the graceful 1739 service termination process and continue the credit-control session 1740 and service session as usual. 1742 The credit-control client may not wait until the expiration of the 1743 Validity-Time and may send a spontaneous update (a new Credit- 1744 Control-Request) if the service element can determine, for instance, 1745 that communication between the end user and the top-up server took 1746 place. An example of this is given in Appendix B.8 (Figure 18). 1748 Note that the credit-control server may already have initiated the 1749 above-described process for the first interrogation. However, the 1750 user's account might be empty when this first interrogation is 1751 performed. In this case, the subscriber can be offered a chance to 1752 replenish the account and continue the service. The credit-control 1753 client receives a Credit-Control-Answer or service specific 1754 authorization answer with the Final-Unit-Indication or the QoS-Final- 1755 Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- 1756 Unit AVP. It immediately starts the graceful service termination 1757 without sending any message to the server. An example of this case 1758 is illustrated in Appendix B. 1760 5.6.3. Restrict Access Action 1762 A Final-Unit-Indication AVP with the Final-Unit-Action 1763 RESTRICT_ACCESS indicates to the device supporting this action that, 1764 upon consumption of the final granted units, the user's access MUST 1765 be restricted according to the IP packet filters given in the 1766 Restriction-Filter-Rule AVP(s) or according to the IP packet filters 1767 identified by the Filter-Id AVP(s). The credit-control server SHOULD 1768 include either the Restriction-Filter-Rule AVP or the Filter-Id AVP 1769 in the Final-Unit-Indication group AVP of the Credit-Control-Answer 1770 message. 1772 A QoS-Final-Unit-Indication AVP with the Final-Unit-Action 1773 RESTRICT_ACCESS indicates to the device supporting this action that, 1774 upon consumption of the final granted units, the actions specified in 1775 Filter-Rule AVP(s) MUST restrict the traffic according to the 1776 classifiers in the Filter-Rule AVP(s). If Filter-Id AVP(s) are 1777 provided in the Credit-Control-Answer message, the credit-control 1778 client MUST restrict the traffic according to the IP packet filters 1779 identified by the Filter-Id AVP(s). The credit-control server SHOULD 1780 include either the Filter-Rule AVP or the Filter-Id AVP in the QoS- 1781 Final-Unit-Indication group AVP of the Credit-Control-Answer message. 1783 If both Final-Unit-Indication AVP and QoS-Final-Unit-Indication AVP 1784 exist in the Credit-Control-Answer message, a credit-control client 1785 which supports the QoS-Final-Unit-Indication AVP SHOULD follow the 1786 directives included in the QoS-Final-Unit-Indication AVP and SHOULD 1787 ignore the Final-Unit-Indication AVP. 1789 An entity other than the credit-control server may provision the 1790 access device with appropriate IP packet filters to be used in 1791 conjunction with the Diameter credit-control application. Such an 1792 entity may, for instance, configure the access device with IP flows 1793 to be passed when the Diameter credit-control application indicates 1794 RESTRICT_ACCESS or REDIRECT. The access device passes IP packets 1795 according to the filter rules that may have been received in the 1796 Credit-Control-Answer message in addition to those that may have been 1797 configured by the other entity. However, when the user's account 1798 cannot cover the cost of the requested service, the action taken is 1799 the responsibility of the credit-control server that controls the 1800 prepaid subscriber. 1802 If another entity working in conjunction with the Diameter credit- 1803 control application already provisions the access device with all the 1804 required filter rules for the end user, the credit-control server 1805 presumably need not send any additional filter. Therefore, it is 1806 RECOMMENDED that credit-control server implementations supporting the 1807 graceful service termination be configurable for sending the 1808 Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, 1809 or none of the above. 1811 When the final granted units have been consumed, the credit-control 1812 client MUST perform an intermediate interrogation. The credit- 1813 control client and the credit-control server process this 1814 intermediate interrogation and execute subsequent procedures, as 1815 specified in the previous section for the REDIRECT action. 1817 The credit-control server may initiate the graceful service 1818 termination with action RESTRICT_ACCESS already for the first 1819 interrogation, as specified in the previous section for the REDIRECT 1820 action. 1822 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 1824 Once the subscriber replenishes the account, she presumably expects 1825 all the restrictions placed by the graceful termination procedure to 1826 be removed immediately and unlimited service access to be resumed. 1827 For the best user experience, the credit-control server 1828 implementation MAY support the server-initiated credit re- 1829 authorization (see Section 5.5). In such a case, upon the successful 1830 account top-up, the credit-control server sends the Re-Auth-Request 1831 (RAR) message to solicit the credit re-authorization. The credit- 1832 control client initiates the credit re-authorization by sending the 1833 Credit-Control-Request message with the CC-Request-Type AVP set to 1834 the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included 1835 in the request, as there is no allotted quota to report. The 1836 Requested-Service-Unit AVP MAY be included in the request. After the 1837 credit-control client successfully receives the Credit-Control-Answer 1838 with new Granted-Service-Unit, all the possible restrictions 1839 activated for the purpose of the graceful service termination MUST be 1840 removed in the service element. The credit-control session and the 1841 service session continue as usual. 1843 5.7. Failure Procedures 1845 The Credit-Control-Failure-Handling AVP (CCFH), as described in this 1846 section, determines the behavior of the credit-control client in 1847 fault situations. The CCFH may be received from the Diameter home 1848 AAA server, from the credit-control server, or may be configured 1849 locally. The CCFH value received from the home AAA server overrides 1850 the locally configured value. The CCFH value received from the 1851 credit-control server in the Credit-Control-Answer message always 1852 overrides any existing value. 1854 The authorization server MAY include the Accounting-Realtime-Required 1855 AVP to determine what to do if the sending of accounting records to 1856 the accounting server has been temporarily prevented, as defined in 1857 [RFC6733]. It is RECOMMENDED that the client complement the credit- 1858 control failure procedures with backup accounting flow toward an 1859 accounting server. By using different combinations of Accounting- 1860 Realtime-Required and Credit-Control-Failure-Handling AVPs, different 1861 safety levels can be built. For example, by choosing a Credit- 1862 Control-Failure-Handling AVP equal to CONTINUE for the credit-control 1863 flow and an Accounting-Realtime-Required AVP equal to 1864 DELIVER_AND_GRANT for the accounting flow, the service can be granted 1865 to the end user even if the connection to the credit-control server 1866 is down, as long as the accounting server is able to collect the 1867 accounting information and information exchange is taking place 1868 between the accounting server and credit-control server. 1870 As the credit-control application is based on real-time bi- 1871 directional communication between the credit-control client and the 1872 credit-control server, the usage of alternative destinations and the 1873 buffering of messages may not be sufficient in the event of 1874 communication failures. Because the credit-control server has to 1875 maintain session states, moving the credit-control message stream to 1876 a backup server requires a complex context transfer solution. 1877 Whether the credit-control message stream is moved to a backup 1878 credit-control server during an ongoing credit-control session 1879 depends on the value of the CC-Session-Failover AVP. However, 1880 failover may occur at any point in the path between the credit- 1881 control client and the credit-control server if a transport failure 1882 is detected with a peer, as described in [RFC6733]. As a 1883 consequence, the credit-control server might receive duplicate 1884 messages. These duplicates or out of sequence messages can be 1885 detected in the credit-control server based on the credit-control 1886 server session state machine (Section 7), Session-Id AVP, and CC- 1887 Request-Number AVP. 1889 If a failure occurs during an ongoing credit-control session, the 1890 credit-control client may move the credit-control message stream to 1891 an alternative server if the CC-server indicated FAILOVER_SUPPORTED 1892 in the CC-Session-Failover AVP. A secondary credit-control server 1893 name, either received from the home Diameter AAA server or configured 1894 locally, can be used as an address of the backup server. If the CC- 1895 Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- 1896 control message stream MUST NOT be moved to a backup server. 1898 For new credit-control sessions, failover to an alternative credit- 1899 control server SHOULD be performed if possible. For instance, if an 1900 implementation of the credit-control client can determine primary 1901 credit-control server unavailability, it can establish the new 1902 credit-control sessions with a possibly available secondary credit- 1903 control server. 1905 The AAA transport profile [RFC3539] defines the application layer 1906 watchdog algorithm that enables failover from a peer that has failed 1907 and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The 1908 recommended default initial value for Tw (Twinit) is 30 seconds. 1909 Twinit may be set as low as 6 seconds; however, according to 1910 [RFC3539], setting too low a value for Twinit is likely to result in 1911 an increased probability of duplicates, as well as an increase in 1912 spurious failover and failback attempts. The Diameter base protocol 1913 is common to several different types of Diameter AAA applications 1914 that may be run in the same service element. Therefore, tuning the 1915 timer Twinit to a lower value in order to satisfy the requirements of 1916 real-time applications, such as the Diameter credit-control 1917 application, will certainly cause the above mentioned problems. For 1918 prepaid services, however, the end user expects an answer from the 1919 network in a reasonable time. Thus, the Diameter credit-control 1920 client will react faster than would the underlying base protocol. 1921 Therefore this specification defines the timer Tx that is used by the 1922 credit-control client (as defined in Section 13) to supervise the 1923 communication with the credit-control server. When the timer Tx 1924 elapses, the credit-control client takes an action to the end user 1925 according to the Credit-Control-Failure-Handling AVP. 1927 When Tx expires, the Diameter credit-control client always terminates 1928 the service if the Credit-Control-Failure-Handling (CCFH) AVP is set 1929 to the value TERMINATE. The credit-control session may be moved to 1930 an alternative server only if a protocol error DIAMETER_TOO_BUSY or 1931 DIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore, 1932 the value TERMINATE is not appropriate if proper failover behavior is 1933 desired. 1935 If the Credit-Control-Failure-Handling AVP is set to the value 1936 CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the 1937 end user when the timer Tx expires. An answer message with granted 1938 units may arrive later if the base protocol transport failover 1939 occurred in the path to the credit-control server. (The Twinit 1940 default value is 3 times more than the Tx recommended value.) The 1941 credit-control client SHOULD grant the service to the end user, start 1942 monitoring the resource usage, and wait for the possible late answer 1943 until the timeout of the request (e.g., 120 seconds). If the request 1944 fails and the CC-Session-Failover AVP is set to 1945 FAILOVER_NOT_SUPPORTED, the credit-control client terminates or 1946 continues the service depending on the value set in the CCFH and MUST 1947 free all the reserved resources for the credit-control session. If 1948 the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is 1949 received or the request times out and the CC-Session-Failover AVP is 1950 set to FAILOVER_SUPPORTED, the credit-control client MAY send the 1951 request to a backup server, if possible. If the credit-control 1952 client receives a successful answer from the backup server, it 1953 continues the credit-control session with such a server. If the re- 1954 transmitted request also fails, the credit-control client terminates 1955 or continues the service depending on the value set in the CCFH and 1956 MUST free all the reserved resources for the credit-control session. 1958 If a communication failure occurs during the graceful service 1959 termination procedure, the service element SHOULD always terminate 1960 the ongoing service session. 1962 If the credit-control server detects a failure during an ongoing 1963 credit-control session, it will terminate the credit-control session 1964 and return the reserved units back to the end user's account. 1966 The supervision session timer Tcc (as defined in Section 13) is used 1967 in the credit-control server to supervise the credit-control session. 1969 In order to support failover between credit-control servers, 1970 information transfer about the credit-control session and account 1971 state SHOULD take place between the primary and the secondary credit- 1972 control server. Implementations supporting the credit-control 1973 session failover MUST also ensure proper detection of duplicate or 1974 out of sequence messages. The communication between the servers is 1975 regarded as an implementation issue and is outside of the scope of 1976 this specification. 1978 6. One Time Event 1980 The one-time event is used when there is no need to maintain any 1981 state in the Diameter credit-control server; for example, enquiring 1982 about the price of the service. The use of a one-time event implies 1983 that the user has been authenticated and authorized beforehand. 1985 The one-time event can be used when the credit-control client wants 1986 to know the cost of the service event or to check the account balance 1987 without any credit-reservation. It can also be used for refunding 1988 service units on the user's account or for direct debiting without 1989 any credit-reservation. The one-time event is shown in Figure 8. 1991 Diameter 1992 End User Service Element AAA Server CC Server 1993 (CC Client) 1994 | Service Request | | | 1995 |------------------>| | | 1996 | | CCR(Event) | | 1997 | |------------------->| CCR(Event) | 1998 | | |------------------->| 1999 | | | CCA(Granted-Units)| 2000 | | CCA(Granted-Units)|<-------------------| 2001 | Service Delivery |<-------------------| | 2002 |<----------------->| | | 2004 Figure 8: One time event 2006 In environments such as the 3GPP architecture, the one-time event can 2007 be sent from the service element directly to the credit-control 2008 server. 2010 6.1. Service Price Enquiry 2012 The credit-control client may need to know the price of the services 2013 event. Services offered by application service providers whose 2014 prices are not known in the credit-control client might exist. The 2015 end user might also want to get an estimation of the price of a 2016 service event before requesting it. 2018 A Diameter credit-control client requesting the cost information MUST 2019 set the CC-Request-Type AVP equal to EVENT_REQUEST, include the 2020 Requested-Action AVP set to PRICE_ENQUIRY, and set the requested 2021 service event information into the Service-Identifier AVP in the 2022 Credit-Control-Request message. Additional service event information 2023 may be sent as service specific AVPs or within the Service-Parameter- 2024 Info AVP. The Service-Context-Id AVP indicates the service specific 2025 document applicable to the request. 2027 The credit-control server calculates the cost of the requested 2028 service event, but it does not perform any account balance check or 2029 credit-reservation from the account. 2031 The estimated cost of the requested service event is returned to the 2032 credit-control client in the Cost-Information AVP in the Credit- 2033 Control-Answer message. 2035 6.2. Balance Check 2037 The Diameter credit-control client may only have to verify that the 2038 end user's account balance covers the cost of a certain service 2039 without reserving any units from the account at the time of the 2040 inquiry. This method does not guarantee that credit would be left 2041 when the Diameter credit-control client requests the debiting of the 2042 account with a separate request. 2044 A Diameter credit-control client requesting the balance check MUST 2045 set the CC-Request-Type AVP equal to EVENT_REQUEST, include a 2046 Requested-Action AVP set to CHECK_BALANCE, and include the 2047 Subscription-Id AVP or Subscription-Id-Extension AVP in order to 2048 identify the end user in the credit-control server. The Service- 2049 Context-Id AVP indicates the service specific document applicable to 2050 the request. 2052 The credit-control server makes the balance check, but it does not 2053 make any credit-reservation from the account. 2055 The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to 2056 the credit-control client in the Check-Balance-Result AVP in the 2057 Credit-Control-Answer message. 2059 6.3. Direct Debiting 2061 There are certain service events for which service execution is 2062 always successful in the service environment. The delay between the 2063 service invocation and the actual service delivery to the end user 2064 can be sufficiently long that the use of the session-based credit- 2065 control would lead to unreasonably long credit-control sessions. In 2066 these cases, the Diameter credit-control client can use the one-time 2067 event scenario for direct debiting. The Diameter credit-control 2068 client SHOULD be sure that the requested service event execution 2069 would be successful when this scenario is used. 2071 In the Credit-Control-Request message, the CC-Request-Type is set to 2072 the value EVENT_REQUEST and the Requested-Action AVP is set to 2073 DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id- 2074 Extension AVP SHOULD be included to identify the end user in the 2075 credit-control server. The Event-Timestamp AVP SHOULD be included in 2076 the request and contain the time when the service event is requested 2077 in the service element. The Service-Context-Id AVP indicates the 2078 service specific document applicable to the request. 2080 The Diameter credit-control client MAY include the monetary amount to 2081 be charged in the Requested-Service-Unit AVP, if it knows the cost of 2082 the service event. If the Diameter credit-control client does not 2083 know the cost of the service event, the Requested-Service-Unit AVP 2084 MAY contain the number of requested service events. The Service- 2085 Identifier AVP always indicates the service concerned. Additional 2086 service event information to be rated MAY be sent as service specific 2087 AVPs or within the Service-Parameter-Info AVP. 2089 The credit-control server SHOULD rate the service event and deduct 2090 the corresponding monetary amount from the end user's account. If 2091 the type of the Requested-Service-Unit AVP is money, no rating is 2092 needed, but the corresponding monetary amount is deducted from the 2093 end user's account. 2095 The credit-control server returns the Granted-Service-Unit AVP in the 2096 Credit-Control-Answer message to the Diameter credit-control client. 2097 The Granted-Service-Unit AVP contains the amount of service units 2098 that the Diameter credit-control client can provide to the end user. 2099 The type of the Granted-Service-Unit can be time, volume, service 2100 specific, or money, depending on the type of service event. 2102 If the credit-control server determines that no credit-control is 2103 needed for the service, it can include the result code indicating 2104 that the credit-control is not applicable (e.g., service is free of 2105 charge). 2107 For informative purposes, the Credit-Control-Answer message MAY also 2108 include the Cost-Information AVP containing the estimated total cost 2109 of the requested service. 2111 6.4. Refund 2113 Some services may refund service units to the end user's account; for 2114 example, gaming services. 2116 The credit-control client MUST set CC-Request-Type to the value 2117 EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the 2118 Credit-Control-Request message. The Subscription-Id AVP or 2119 Subscription-Id-Extension AVP SHOULD be included to identify the end 2120 user in the credit-control server. The Service-Context-Id AVP 2121 indicates the service specific document applicable to the request. 2123 The Diameter credit-control client MAY include the monetary amount to 2124 be refunded in the Requested-Service-Unit AVP. The Service- 2125 Identifier AVP always indicates the concerned service. If the 2126 Diameter credit-control client does not know the monetary amount to 2127 be refunded, in addition to the Service-Identifier AVP it MAY send 2128 service specific AVPs or the Service-Parameter-Info AVP containing 2129 additional service event information to be rated. 2131 For informative purposes, the Credit-Control-Answer message MAY also 2132 include the Cost-Information AVP containing the estimated monetary 2133 amount of refunded unit. 2135 6.5. Failure Procedure 2137 Failover to an alternative credit-control server is allowed for a one 2138 time event, as the server is not maintaining session states. For 2139 instance, if the credit-control client receives a protocol error 2140 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the 2141 request to an alternative server, if possible. There MAY be protocol 2142 transparent Diameter relays and redirect agents or Diameter credit- 2143 control proxies between the credit-control client and credit-control 2144 server. Failover may occur at any point in the path between the 2145 credit-control client and the credit-control server if a transport 2146 failure is detected with a peer, as described in [RFC6733]. Because 2147 there can be duplicate requests for various reasons, the credit- 2148 control server is responsible for real time duplicate detection. 2149 Implementation issues for duplicate detection are discussed in 2150 [RFC6733], Appendix C. 2152 When the credit-control client detects a communication failure with 2153 the credit-control server, its behavior depends on the requested 2154 action. The timer Tx (as defined in Section 13) is used in the 2155 credit-control client to supervise the communication with the credit- 2156 control server. 2158 If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and 2159 communication failure is detected, the credit-control client SHOULD 2160 forward the request messages to an alternative credit-control server, 2161 if possible. The secondary credit-control server name, if received 2162 from the home Diameter AAA server, can be used as an address of 2163 backup server. 2165 If the requested action is DIRECT_DEBITING, the Direct-Debiting- 2166 Failure-Handling AVP (DDFH) controls the credit-control client's 2167 behavior. The DDFH may be received from the home Diameter AAA server 2168 or may be locally configured. The credit-control server may also 2169 send the DDFH in any CCA message to be used for direct debiting 2170 events compiled thereafter. The DDFH value received from the home 2171 Diameter AAA server overrides the locally configured value, and the 2172 DDFH value received from the credit-control server in a Credit- 2173 Control-Answer message always overrides any existing value. 2175 If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client 2176 SHOULD NOT grant the service if it can determine, eventually after a 2177 possible re-transmission attempt to an alternative credit-control 2178 server, from the result code or error code in the answer message that 2179 units have not been debited. Otherwise, the credit-control client 2180 SHOULD grant the service to the end user and store the request in the 2181 credit-control application level non-volatile storage. (Note that 2182 re-sending the request at a later time is not a guarantee that the 2183 service will be debited, as the user's account may be empty when the 2184 server successfully processes the request.) The credit-control 2185 client MUST mark these request messages as possible duplicates by 2186 setting the T-flag in the command header as described in [RFC6733], 2187 Section 3. 2189 If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 2190 service SHOULD be granted, even if credit-control messages cannot be 2191 delivered and messages are not buffered. 2193 If the timer Tx expires, the credit-control client MUST continue the 2194 service and wait for a possible late answer. If the request times 2195 out, the credit-control client re-transmits the request (marked with 2196 T-flag) to a backup credit-control server, if possible. If the re- 2197 transmitted request also times out, or if a temporary error is 2198 received in answer, the credit-control client buffers the request if 2199 the value of the Direct-Debiting-Failure-Handling AVP is set to 2200 TERMINATE_OR_BUFFER. If a failed answer is received for the re- 2201 transmitted request, the credit-control client frees all the 2202 resources reserved for the event message and deletes the request 2203 regardless of the value of the DDFH. 2205 The Credit-Control-Request with the requested action REFUND_ACCOUNT 2206 should always be stored in the credit-control application level non- 2207 volatile storage in case of temporary failure. The credit-control 2208 client MUST mark the re-transmitted request message as a possible 2209 duplicate by setting the T-flag in the command header as described in 2210 [RFC6733], Section 3. 2212 For stored requests, the implementation may choose to limit the 2213 number of re-transmission attempts and to define a re-transmission 2214 interval. 2216 Note that only one place in the credit-control system SHOULD be 2217 responsible for duplicate detection. If there is only one credit- 2218 control server within the given realm, the credit-control server may 2219 perform duplicate detection. If there is more than one credit- 2220 control server in a given realm, only one entity in the credit- 2221 control system should be responsible, to ensure that the end user's 2222 account is not debited or credited multiple times for the same 2223 service event. 2225 7. Credit-Control Application State Machine 2227 This section defines the credit-control application state machine. 2229 The first four state machines are to be observed by credit-control 2230 clients. The first one describes the session-based credit-control 2231 when the first interrogation is executed as part of the 2232 authorization/authentication process. The second describes the 2233 session-based credit-control when the first interrogation is executed 2234 after the authorization/authentication process. The requirements as 2235 to what state machines have to be supported are discussed in 2236 Section 5.2. 2238 The third state machine describes the session-based credit-control 2239 for the intermediate and final interrogations. The fourth one 2240 describes the event-based credit-control. These latter state 2241 machines are to be observed by all implementations that conform to 2242 this specification. 2244 The fifth state machine describes the credit-control session from a 2245 credit-control server perspective. 2247 Any event not listed in the state machines MUST be considered an 2248 error condition, and a corresponding answer, if applicable, MUST be 2249 returned to the originator of the message. 2251 In the state table, the event 'Failure to send' means that the 2252 Diameter credit-control client is unable to communicate with the 2253 desired destination or, if failover procedure is supported, with a 2254 possibly defined alternative destination (e.g., the request times out 2255 and the answer message is not received). This could be due to the 2256 peer being down, or due to a physical link failure in the path to or 2257 from the credit-control server. 2259 The event 'Temporary error' means that the Diameter credit-control 2260 client received a protocol error notification (DIAMETER_TOO_BUSY, 2261 DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result- 2262 Code AVP of the Credit-Control-Answer command. The above protocol 2263 error notification may ultimately be received in answer to the re- 2264 transmitted request to a defined alternative destination, if failover 2265 is supported. 2267 The event 'Failed answer' means that the Diameter credit-control 2268 client received non-transient failure (permanent failure) 2269 notification in the Credit-Control-Answer command. The above 2270 permanent failure notification may ultimately be received in answer 2271 to the re-transmitted request to a defined alternative destination, 2272 if failover is supported. 2274 The action 'store request' means that a request is stored in the 2275 credit-control application level non-volatile storage. 2277 The event 'Not successfully processed' means that the credit-control 2278 server could not process the message; e.g., due to an unknown end 2279 user, account being empty, or errors defined in [RFC6733]. 2281 The event 'User service terminated' can be triggered by various 2282 reasons, e.g., normal user termination, network failure, and ASR 2283 (Abort-Session-Request). The Termination-Cause AVP contains 2284 information about the termination reason, as specified in [RFC6733]. 2286 The Tx timer, which is used to control the waiting time in the 2287 credit-control client in the Pending state, is stopped upon exit of 2288 the Pending state. The stopping of the Tx timer is omitted in the 2289 state machine when the new state is Idle, as moving to Idle state 2290 implies the clearing of the session and all the variables associated 2291 to it. 2293 The states PendingI, PendingU, PendingT, PendingE, and PendingB stand 2294 for pending states to wait for an answer to a credit-control request 2295 related to Initial, Update, Termination, Event, or Buffered request, 2296 respectively. 2298 The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling 2299 and Direct-Debiting-Failure-Handling, respectively. 2301 In the following state machine table, the failover to a secondary 2302 server upon 'Temporary error' or 'Failure to send' is not explicitly 2303 described. Moving an ongoing credit-control message stream to an 2304 alternative server is, however, possible if the CC-Session-Failover 2305 AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7. 2307 Re-sending a credit-control event to an alternative server is 2308 supported as described in Section 6.5. 2310 +----------+-------------------------------+-------------+----------+ 2311 | State | Event | Action | New | 2312 | | | | State | 2313 +----------+-------------------------------+-------------+----------+ 2314 | Idle | Client or device requests | Send AA | PendingI | 2315 | | access/service | request | | 2316 | | | with added | | 2317 | | | CC AVPs, | | 2318 | | | start Tx | | 2319 | PendingI | Successful AA req. answer | Grant | Open | 2320 | | received | service to | | 2321 | | | end user, | | 2322 | | | stop Tx | | 2323 | PendingI | Tx expired | Disconnect | Idle | 2324 | | | user/dev | | 2325 | PendingI | Failed AA answer received | Disconnect | Idle | 2326 | | | user/dev | | 2327 | PendingI | AA answer received with | Grant | Idle | 2328 | | result code equal to | service to | | 2329 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2330 | PendingI | User service terminated | Queue | PendingI | 2331 | | | termination | | 2332 | | | event | | 2333 | PendingI | Change in rating condition | Queue | PendingI | 2334 | | | changed | | 2335 | | | rating | | 2336 | | | condition | | 2337 | | | event | | 2338 +----------+-------------------------------+-------------+----------+ 2340 Table 2: CLIENT, SESSION BASED for the first interrogation with AA 2341 request 2343 +----------+-------------------------------+-------------+----------+ 2344 | State | Event | Action | New | 2345 | | | | State | 2346 +----------+-------------------------------+-------------+----------+ 2347 | Idle | Client or device requests | Send CC | PendingI | 2348 | | access/service | initial | | 2349 | | | req., start | | 2350 | | | Tx | | 2351 | PendingI | Successful CC initial answer | Stop Tx | Open | 2352 | | received | | | 2353 | PendingI | Failure to send, or temporary | Grant | Idle | 2354 | | error and CCFH equal to | service to | | 2355 | | CONTINUE | end user | | 2356 | PendingI | Failure to send, or temporary | Terminate | Idle | 2357 | | error and CCFH equal to | end user's | | 2358 | | TERMINATE or to | service | | 2359 | | RETRY_AND_TERMINATE | | | 2360 | PendingI | Tx expired and CCFH equal to | Terminate | Idle | 2361 | | TERMINATE | end user's | | 2362 | | | service | | 2363 | PendingI | Tx expired and CCFH equal to | Grant | PendingI | 2364 | | CONTINUE or to | service to | | 2365 | | RETRY_AND_TERMINATE | end user | | 2366 | PendingI | CC initial answer received | Terminate | Idle | 2367 | | with result code | end user's | | 2368 | | END_USER_SERVICE_DENIED or | service | | 2369 | | USER_UNKNOWN | | | 2370 | PendingI | CC initial answer received | Grant | Idle | 2371 | | with result code equal to | service to | | 2372 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2373 | PendingI | Failed CC initial answer | Grant | Idle | 2374 | | received and CCFH equal to | service to | | 2375 | | CONTINUE | end user | | 2376 | PendingI | Failed CC initial answer | Terminate | Idle | 2377 | | received and CCFH equal to | end user's | | 2378 | | TERMINATE or to | service | | 2379 | | RETRY_AND_TERMINATE | | | 2380 | PendingI | User service terminated | Queue | PendingI | 2381 | | | termination | | 2382 | | | event | | 2383 | PendingI | Change in rating condition | Queue | PendingI | 2384 | | | changed | | 2385 | | | rating | | 2386 | | | condition | | 2387 | | | event | | 2388 +----------+-------------------------------+-------------+----------+ 2390 Table 3: CLIENT, SESSION BASED for the first interrogation with CCR 2392 +----------+-------------------------------+-------------+----------+ 2393 | State | Event | Action | New | 2394 | | | | State | 2395 +----------+-------------------------------+-------------+----------+ 2396 | Open | Granted unit elapses and no | Send CC | PendingU | 2397 | | final unit indication | update | | 2398 | | received | req., start | | 2399 | | | Tx | | 2400 | Open | Granted unit elapses and | Terminate | PendingT | 2401 | | final unit action equal to | end user's | | 2402 | | TERMINATE received | service, | | 2403 | | | send CC | | 2404 | | | termination | | 2405 | | | req. | | 2406 | Open | Change in rating condition in | Send CC | PendingU | 2407 | | queue | update | | 2408 | | | req., Start | | 2409 | | | Tx | | 2410 | Open | Service terminated in queue | Send CC | PendingT | 2411 | | | termination | | 2412 | | | req. | | 2413 | Open | Change in rating condition or | Send CC | PendingU | 2414 | | Validity-Time elapses | update | | 2415 | | | req., Start | | 2416 | | | Tx | | 2417 | Open | User service terminated | Send CC | PendingT | 2418 | | | termination | | 2419 | | | req. | | 2420 | Open | RAR received | Send RAA | PendingU | 2421 | | | followed by | | 2422 | | | CC update | | 2423 | | | req., start | | 2424 | | | Tx | | 2425 | PendingU | Successful CC update answer | Stop Tx | Open | 2426 | | received | | | 2427 | PendingU | Failure to send, or temporary | Grant | Idle | 2428 | | error and CCFH equal to | service to | | 2429 | | CONTINUE | end user | | 2430 | PendingU | Failure to send, or temporary | Terminate | Idle | 2431 | | error and CCFH equal to | end user's | | 2432 | | TERMINATE or to | service | | 2433 | | RETRY_AND_TERMINATE | | | 2434 | PendingU | Tx expired and CCFH equal to | Terminate | Idle | 2435 | | TERMINATE | end user's | | 2436 | | | service | | 2437 | PendingU | Tx expired and CCFH equal to | Grant | PendingU | 2438 | | CONTINUE or to | service to | | 2439 | | RETRY_AND_TERMINATE | end user | | 2440 | PendingU | CC update answer received | Terminate | Idle | 2441 | | with result code | end user's | | 2442 | | END_USER_SERVICE_DENIED | service | | 2443 | PendingU | CC update answer received | Grant | Idle | 2444 | | with result code equal to | service to | | 2445 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2446 | PendingU | Failed CC update answer | Grant | Idle | 2447 | | received and CCFH equal to | service to | | 2448 | | CONTINUE | end user | | 2449 | PendingU | Failed CC update answer | Terminate | Idle | 2450 | | received and CCFH equal to | end user's | | 2451 | | TERMINATE or to | service | | 2452 | | RETRY_AND_TERMINATE | | | 2453 | PendingU | User service terminated | Queue | PendingU | 2454 | | | termination | | 2455 | | | event | | 2456 | PendingU | Change in rating condition | Queue | PendingU | 2457 | | | changed | | 2458 | | | rating | | 2459 | | | condition | | 2460 | | | event | | 2461 | PendingU | RAR received | Send RAA | PendingU | 2462 | PendingT | Successful CC termination | | Idle | 2463 | | answer received | | | 2464 | PendingT | Failure to send, temporary | | Idle | 2465 | | error, or failed answer | | | 2466 | PendingT | Change in rating condition | | PendingT | 2467 +----------+-------------------------------+-------------+----------+ 2469 Table 4: CLIENT, SESSION BASED for intermediate and final 2470 interrogations 2472 +----------+--------------------------------+------------+----------+ 2473 | State | Event | Action | New | 2474 | | | | State | 2475 +----------+--------------------------------+------------+----------+ 2476 | Idle | Client or device requests a | Send CC | PendingE | 2477 | | one-time service | event | | 2478 | | | req., | | 2479 | | | Start Tx | | 2480 | Idle | Request in storage | Send | PendingB | 2481 | | | stored | | 2482 | | | request | | 2483 | PendingE | Successful CC event answer | Grant | Idle | 2484 | | received | service to | | 2485 | | | end user | | 2486 | PendingE | Failure to send, temporary | Indicate | Idle | 2487 | | error, failed CC event answer | service | | 2488 | | received, or Tx expired; | error | | 2489 | | requested action CHECK_BALANCE | | | 2490 | | or PRICE_ENQUIRY | | | 2491 | PendingE | CC event answer received with | Terminate | Idle | 2492 | | result code | end user's | | 2493 | | END_USER_SERVICE_DENIED or | service | | 2494 | | USER_UNKNOWN and Tx running | | | 2495 | PendingE | CC event answer received with | Grant | Idle | 2496 | | result code | service to | | 2497 | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | | 2498 | | requested action | | | 2499 | | DIRECT_DEBITING | | | 2500 | PendingE | Failure to send, temporary | Grant | Idle | 2501 | | error, failed CC event answer | service to | | 2502 | | received; requested action | end user | | 2503 | | DIRECT_DEBITING; DDFH equal to | | | 2504 | | CONTINUE | | | 2505 | PendingE | Failed CC event answer | Terminate | Idle | 2506 | | received or temporary error; | end user's | | 2507 | | requested action | service | | 2508 | | DIRECT_DEBITING; DDFH equal to | | | 2509 | | TERMINATE_OR_BUFFER and Tx | | | 2510 | | running | | | 2511 | PendingE | Tx expired; requested action | Grant | PendingE | 2512 | | DIRECT_DEBITING | service to | | 2513 | | | end user | | 2514 | PendingE | Failure to send; requested | Store | Idle | 2515 | | action DIRECT_DEBITING; DDFH | request | | 2516 | | equal to TERMINATE_OR_BUFFER | with | | 2517 | | | T-flag | | 2518 | PendingE | Temporary error; requested | Store | Idle | 2519 | | action DIRECT_DEBITING; DDFH | request | | 2520 | | equal to TERMINATE_OR_BUFFER; | | | 2521 | | Tx expired | | | 2522 | PendingE | Failed answer or answer | | Idle | 2523 | | received with result code | | | 2524 | | END_USER_SERVICE DENIED or | | | 2525 | | USER_UNKNOWN; requested action | | | 2526 | | DIRECT_DEBITING; Tx expired | | | 2527 | PendingE | Failed CC event answer | Indicate | Idle | 2528 | | received; requested action | service | | 2529 | | REFUND_ACCOUNT | error and | | 2530 | | | delete | | 2531 | | | request | | 2532 | PendingE | Failure to send or Tx expired; | Store | Idle | 2533 | | requested action | request | | 2534 | | REFUND_ACCOUNT | with | | 2535 | | | T-flag | | 2536 | PendingE | Temporary error, and requested | Store | Idle | 2537 | | action REFUND_ACCOUNT | request | | 2538 | PendingB | Successful CC answer received | Delete | Idle | 2539 | | | request | | 2540 | PendingB | Failed CC answer received | Delete | Idle | 2541 | | | request | | 2542 | PendingB | Failure to send or temporary | | Idle | 2543 | | error | | | 2544 +----------+--------------------------------+------------+----------+ 2546 Table 5: CLIENT, EVENT BASED 2548 +-------+------------------------+--------------------------+-------+ 2549 | State | Event | Action | New | 2550 | | | | State | 2551 +-------+------------------------+--------------------------+-------+ 2552 | Idle | CC initial request | Send CC initial answer, | Open | 2553 | | received and | reserve units, start Tcc | | 2554 | | successfully processed | | | 2555 | Idle | CC initial request | Send CC initial answer | Idle | 2556 | | received but not | with Result-Code != | | 2557 | | successfully processed | SUCCESS | | 2558 | Idle | CC event request | Send CC event answer | Idle | 2559 | | received and | | | 2560 | | successfully processed | | | 2561 | Idle | CC event request | Send CC event answer | Idle | 2562 | | received but not | with Result-Code != | | 2563 | | successfully processed | SUCCESS | | 2564 | Open | CC update request | Send CC update answer, | Open | 2565 | | received and | debit used units, | | 2566 | | successfully processed | reserve new units, | | 2567 | | | restart Tcc | | 2568 | Open | CC update request | Send CC update answer | Idle | 2569 | | received but not | with Result-Code != | | 2570 | | successfully processed | SUCCESS, debit used | | 2571 | | | units | | 2572 | Open | CC termination request | Send CC termin. answer, | Idle | 2573 | | received and | Stop Tcc, debit used | | 2574 | | successfully processed | units | | 2575 | Open | CC termination request | Send CC termin. answer | Idle | 2576 | | received but not | with Result-Code != | | 2577 | | successfully processed | SUCCESS, debit used | | 2578 | | | units | | 2579 | Open | Session supervision | Release reserved units | Idle | 2580 | | timer Tcc expired | | | 2581 +-------+------------------------+--------------------------+-------+ 2583 Table 6: SERVER, SESSION AND EVENT BASED 2585 8. Credit-Control AVPs 2587 This section defines the credit-control AVPs that are specific to 2588 Diameter credit-control application and that MAY be included in the 2589 Diameter credit-control messages. 2591 The AVPs defined in this section MAY also be included in 2592 authorization commands defined in authorization-specific 2593 applications, such as [RFC7155] and [RFC4004], if the first 2594 interrogation is performed as part of the authorization/ 2595 authentication process, as described in Section 5.2. 2597 The Diameter AVP rules are defined in the Diameter Base [RFC6733], 2598 Section 4. These AVP rules are observed in AVPs defined in this 2599 section. 2601 The following table describes the Diameter AVPs defined in the 2602 credit-control application, their AVP Code values, types, and 2603 possible flag values. The AVP Flag rules are explained in the 2604 Diameter base [RFC6733], section 4.1. 2606 +---------------+ 2607 |AVP Flag rules | 2608 |----+-----+----| 2609 AVP Section | | |MUST| 2610 Attribute Name Code Defined Data Type |MUST| MAY |NOT | 2611 -----------------------------------------|----+-----+----| 2612 CC-Correlation-Id 411 8.1 OctetString| | M | V | 2613 CC-Input-Octets 412 8.24 Unsigned64 | M | | V | 2614 CC-Money 413 8.22 Grouped | M | | V | 2615 CC-Output-Octets 414 8.25 Unsigned64 | M | | V | 2616 CC-Request-Number 415 8.2 Unsigned32 | M | | V | 2617 CC-Request-Type 416 8.3 Enumerated | M | | V | 2618 CC-Service- 417 8.26 Unsigned64 | M | | V | 2619 Specific-Units | | | | 2620 CC-Session- 418 8.4 Enumerated | M | | V | 2621 Failover | | | | 2622 CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V | 2623 CC-Time 420 8.21 Unsigned32 | M | | V | 2624 CC-Total-Octets 421 8.23 Unsigned64 | M | | V | 2625 CC-Unit-Type 454 8.32 Enumerated | M | | V | 2626 Check-Balance- 422 8.6 Enumerated | M | | V | 2627 Result | | | | 2628 Cost-Information 423 8.7 Grouped | M | | V | 2629 Cost-Unit 424 8.12 UTF8String | M | | V | 2630 Credit-Control 426 8.13 Enumerated | M | | V | 2631 Credit-Control- 427 8.14 Enumerated | M | | V | 2632 Failure-Handling | | | | 2634 Currency-Code 425 8.11 Unsigned32 | M | | V | 2635 Direct-Debiting- 428 8.15 Enumerated | M | | V | 2636 Failure-Handling | | | | 2637 Exponent 429 8.9 Integer32 | M | | V | 2638 Final-Unit-Action 449 8.35 Enumerated | M | | V | 2639 Final-Unit- 430 8.34 Grouped | M | | V | 2640 Indication | | | | 2641 QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | 2642 Indication | | | | 2643 Granted-Service- 431 8.17 Grouped | M | | V | 2644 Unit | | | | 2645 G-S-U-Pool- 453 8.31 Unsigned32 | M | | V | 2646 Identifier | | | | 2647 G-S-U-Pool- 457 8.30 Grouped | M | | V | 2648 Reference | | | | 2649 Multiple-Services 456 8.16 Grouped | M | | V | 2650 -Credit-Control | | | | 2651 Multiple-Services 455 8.40 Enumerated | M | | V | 2652 -Indicator | | | | 2653 Rating-Group 432 8.29 Unsigned32 | M | | V | 2654 Redirect-Address 433 8.38 Enumerated | M | | V | 2655 -Type | | | | 2656 Redirect-Server 434 8.37 Grouped | M | | V | 2657 Redirect-Server 435 8.39 UTF8String | M | | V | 2658 -Address | | | | 2659 Redirect-Server TBD13 8.64 Grouped | | M | V | 2660 -Extension | | | | 2661 Redirect-Address TBD14 8.65 Address | | M | V | 2662 -IPAddress | | | | 2663 Redirect-Address TBD15 8.66 UTF8String | | M | V | 2664 -URL | | | | 2665 Redirect-Address TBD16 8.67 UTF8String | | M | V | 2666 -SIP-URI | | | | 2667 Requested-Action 436 8.41 Enumerated | M | | V | 2668 Requested-Service 437 8.18 Grouped | M | | V | 2669 -Unit | | | | 2670 Restriction 438 8.36 IPFiltrRule| M | | V | 2671 -Filter-Rule | | | | 2672 Service-Context 461 8.42 UTF8String | M | | V | 2673 -Id | | | | 2674 Service- 439 8.28 Unsigned32 | M | | V | 2675 Identifier | | | | 2676 Service-Parameter 440 8.43 Grouped | | M | V | 2677 -Info | | | | 2678 Service- 441 8.44 Unsigned32 | | M | V | 2679 Parameter-Type | | | | 2680 Service- 442 8.45 OctetString| | M | V | 2681 Parameter-Value | | | | 2683 Subscription-Id 443 8.46 Grouped | M | | V | 2684 Subscription-Id 444 8.48 UTF8String | M | | V | 2685 -Data | | | | 2686 Subscription-Id 450 8.47 Enumerated | M | | V | 2687 -Type | | | | 2688 Subscription-Id TBD7 8.58 Grouped | | M | V | 2689 -Extension | | | | 2690 Subscription-Id TBD8 8.59 UTF8String | | M | V | 2691 -E164 | | | | 2692 Subscription-Id TBD9 8.60 UTF8String | | M | V | 2693 -IMSI | | | | 2694 Subscription-Id TBD10 8.61 UTF8String | | M | V | 2695 -SIP-URI | | | | 2696 Subscription-Id TBD11 8.62 UTF8String | | M | V | 2697 -NAI | | | | 2698 Subscription-Id TBD12 8.63 UTF8String | | M | V | 2699 -Private | | | | 2700 Tariff-Change 452 8.27 Enumerated | M | | V | 2701 -Usage | | | | 2702 Tariff-Time 451 8.20 Time | M | | V | 2703 -Change | | | | 2704 Unit-Value 445 8.8 Grouped | M | | V | 2705 Used-Service-Unit 446 8.19 Grouped | M | | V | 2706 User-Equipment 458 8.49 Grouped | | M | V | 2707 -Info | | | | 2708 User-Equipment 459 8.50 Enumerated | | M | V | 2709 -Info-Type | | | | 2710 User-Equipment 460 8.51 OctetString| | M | V | 2711 -Info-Value | | | | 2712 User-Equipment TBD1 8.52 Grouped | | M | V | 2713 -Info-Extension | | | | 2714 User-Equipment TBD2 8.53 OctetString| | M | V | 2715 -Info-IMEISV | | | | 2716 User-Equipment TBD3 8.54 OctetString| | M | V | 2717 -Info-MAC | | | | 2718 User-Equipment TBD4 8.55 OctetString| | M | V | 2719 -Info-EUI64 | | | | 2720 User-Equipment TBD5 8.56 OctetString| | M | V | 2721 -Info-ModifiedEUI64 | | | | 2722 User-Equipment TBD6 8.57 OctetString| | M | V | 2723 -Info-IMEI | | | | 2724 Value-Digits 447 8.10 Integer64 | M | | V | 2725 Validity-Time 448 8.33 Unsigned32 | M | | V | 2727 8.1. CC-Correlation-Id AVP 2729 The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and 2730 contains information to correlate credit-control requests generated 2731 for different components of the service; e.g., transport and service 2732 level. The one who allocates the Service-Context-Id (i.e., unique 2733 identifier of a service specific document) is also responsible for 2734 defining the content and encoding of the CC-Correlation-Id AVP. 2736 8.2. CC-Request-Number AVP 2738 The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and 2739 identifies this request within one session. As Session-Id AVPs are 2740 globally unique, the combination of Session-Id and CC-Request-Number 2741 AVPs is also globally unique and can be used in matching credit- 2742 control messages with confirmations. An easy way to produce unique 2743 numbers is to set the value to 0 for a credit-control request of type 2744 INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the 2745 first UPDATE_REQUEST, to 2 for the second, and so on until the value 2746 for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST. 2748 8.3. CC-Request-Type AVP 2750 The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and 2751 contains the reason for sending the credit-control request message. 2752 It MUST be present in all Credit-Control-Request messages. The 2753 following values are defined for the CC-Request-Type AVP: 2755 INITIAL_REQUEST 1 2757 An Initial request is used to initiate a credit-control session, and 2758 contains credit-control information that is relevant to the 2759 initiation. 2761 UPDATE_REQUEST 2 2763 An Update request contains credit-control information for an existing 2764 credit-control session. Update credit-control requests SHOULD be 2765 sent every time a credit-control re-authorization is needed at the 2766 expiry of the allocated quota or validity time. Further, additional 2767 service-specific events MAY trigger a spontaneous Update request. 2769 TERMINATION_REQUEST 3 2771 A Termination request is sent to terminate a credit-control session 2772 and contains credit-control information relevant to the existing 2773 session. 2775 EVENT_REQUEST 4 2777 An Event request is used when there is no need to maintain any 2778 credit-control session state in the credit-control server. This 2779 request contains all information relevant to the service, and is the 2780 only request of the service. The reason for the Event request is 2781 further detailed in the Requested-Action AVP. The Requested-Action 2782 AVP MUST be included in the Credit-Control-Request message when CC- 2783 Request-Type is set to EVENT_REQUEST. 2785 8.4. CC-Session-Failover AVP 2787 The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and 2788 contains information as to whether moving the credit-control message 2789 stream to a backup server during an ongoing credit-control session is 2790 supported. In communication failures, the credit-control message 2791 streams can be moved to an alternative destination if the credit- 2792 control server supports failover to an alternative server. The 2793 secondary credit-control server name, if received from the home 2794 Diameter AAA server, can be used as an address of the backup server. 2795 An implementation is not required to support moving a credit-control 2796 message stream to an alternative server, as this also requires moving 2797 information related to the credit-control session to backup server. 2799 The following values are defined for the CC-Session-Failover AVP: 2801 FAILOVER_NOT_SUPPORTED 0 2803 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, 2804 the credit-control message stream MUST NOT be moved to an alternative 2805 destination in the case of communication failure. This is the 2806 default behavior if the AVP isn't included in the reply from the 2807 authorization or credit-control server. 2809 FAILOVER_SUPPORTED 1 2811 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the 2812 credit-control message stream SHOULD be moved to an alternative 2813 destination in the case of communication failure. Moving the credit- 2814 control message stream to a backup server MAY require that 2815 information related to the credit-control session should also be 2816 forwarded to an alternative server. 2818 8.5. CC-Sub-Session-Id AVP 2820 The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and 2821 contains the credit-control sub-session identifier. The combination 2822 of the Session-Id and this AVP MUST be unique per sub-session, and 2823 the value of this AVP MUST be monotonically increased by one for all 2824 new sub-sessions. The absence of this AVP implies that no sub- 2825 sessions are in use. 2827 8.6. Check-Balance-Result AVP 2829 The Check Balance Result AVP (AVP Code 422) is of type Enumerated and 2830 contains the result of the balance check. This AVP is applicable 2831 only when the Requested-Action AVP indicates CHECK_BALANCE in the 2832 Credit-Control-Request command. The following values are defined for 2833 the Check-Balance-Result AVP. 2835 ENOUGH_CREDIT 0 2837 There is enough credit in the account to cover the requested service. 2839 NO_CREDIT 1 2841 There isn't enough credit in the account to cover the requested 2842 service. 2844 8.7. Cost-Information AVP 2846 The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is 2847 used to return the cost information of a service, which the credit- 2848 control client can transfer transparently to the end user. The 2849 included Unit-Value AVP contains the cost estimate (always type of 2850 money) of the service, in the case of price enquiry, or the 2851 accumulated cost estimation, in the case of credit-control session. 2853 The Currency-Code specifies in which currency the cost was given. 2854 The Cost-Unit specifies the unit when the service cost is a cost per 2855 unit (e.g., cost for the service is $1 per minute). 2857 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 2858 the Credit-Control-Request command, the Cost-Information AVP sent in 2859 the succeeding Credit-Control-Answer command contains the cost 2860 estimation of the requested service, without any reservation being 2861 made. 2863 The Cost-Information AVP included in the Credit-Control-Answer 2864 command with the CC-Request-Type set to UPDATE_REQUEST contains the 2865 accumulated cost estimation for the session, without taking any 2866 credit reservation into account. 2868 The Cost-Information AVP included in the Credit-Control-Answer 2869 command with the CC-Request-Type set to EVENT_REQUEST or 2870 TERMINATION_REQUEST contains the estimated total cost for the 2871 requested service. 2873 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2875 Cost-Information ::= < AVP Header: 423 > 2876 { Unit-Value } 2877 { Currency-Code } 2878 [ Cost-Unit ] 2880 8.8. Unit-Value AVP 2882 Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the 2883 units as decimal value. The Unit-Value is a value with an exponent; 2884 i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This 2885 representation avoids unwanted rounding off. For example, the value 2886 of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The 2887 absence of the exponent part MUST be interpreted as an exponent equal 2888 to zero. 2890 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2892 Unit-Value ::= < AVP Header: 445 > 2893 { Value-Digits } 2894 [ Exponent ] 2896 8.9. Exponent AVP 2898 Exponent AVP is of type Integer32 (AVP Code 429) and contains the 2899 exponent value to be applied for the Value-Digit AVP within the Unit- 2900 Value AVP. 2902 8.10. Value-Digits AVP 2904 The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains 2905 the significant digits of the number. If decimal values are needed 2906 to present the units, the scaling MUST be indicated with the related 2907 Exponent AVP. For example, for the monetary amount $ 0.05 the value 2908 of Value-Digits AVP MUST be set to 5, and the scaling MUST be 2909 indicated with the Exponent AVP set to -2. 2911 8.11. Currency-Code AVP 2913 The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and 2914 contains a currency code that specifies in which currency the values 2915 of AVPs containing monetary units were given. It is specified by 2916 using the numeric values defined in the ISO 4217 standard [ISO4217]. 2918 8.12. Cost-Unit AVP 2920 The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is 2921 used to display a human readable string to the end user. It 2922 specifies the applicable unit to the Cost-Information when the 2923 service cost is a cost per unit (e.g., cost of the service is $1 per 2924 minute). The Cost-Unit can be minutes, hours, days, kilobytes, 2925 megabytes, etc. 2927 8.13. Credit-Control AVP 2929 The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST 2930 be included in AA requests when the service element has credit- 2931 control capabilities. 2933 CREDIT_AUTHORIZATION 0 2935 If the home Diameter AAA server determines that the user has prepaid 2936 subscription, this value indicates that the credit-control server 2937 MUST be contacted to perform the first interrogation. The value of 2938 the Credit-Control AVP MUST always be set to 0 in an AA request sent 2939 to perform the first interrogation and to initiate a new credit- 2940 control session. 2942 RE_AUTHORIZATION 1 2944 This value indicates to the Diameter AAA server that a credit-control 2945 session is ongoing for the subscriber and that the credit-control 2946 server MUST NOT be contacted. The Credit-Control AVP set to the 2947 value of 1 is to be used only when the first interrogation has been 2948 successfully performed and the credit-control session is ongoing 2949 (i.e., re-authorization triggered by Authorization-Lifetime). This 2950 value MUST NOT be used in an AA request sent to perform the first 2951 interrogation. 2953 8.14. Credit-Control-Failure-Handling AVP 2955 The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type 2956 Enumerated. The credit-control client uses information in this AVP 2957 to decide what to do if sending credit-control messages to the 2958 credit-control server has been, for instance, temporarily prevented 2959 due to a network problem. Depending on the service logic, the 2960 credit-control server can order the client to terminate the service 2961 immediately when there is a reason to believe that the service cannot 2962 be charged, or to try failover to an alternative server, if possible. 2964 Then the server could either terminate or grant the service, should 2965 the alternative connection also fail. 2967 TERMINATE 0 2969 When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the 2970 service MUST only be granted for as long as there is a connection to 2971 the credit-control server. If the credit-control client does not 2972 receive any Credit-Control-Answer message within the Tx timer (as 2973 defined in Section 13), the credit-control request is regarded as 2974 failed, and the end user's service session is terminated. 2976 This is the default behavior if the AVP isn't included in the reply 2977 from the authorization or credit-control server. 2979 CONTINUE 1 2981 When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the 2982 credit-control client SHOULD re-send the request to an alternative 2983 server in the case of transport or temporary failures, provided that 2984 a failover procedure is supported in the credit-control server and 2985 the credit-control client, and that an alternative server is 2986 available. Otherwise, the service SHOULD be granted, even if credit- 2987 control messages can't be delivered. 2989 RETRY_AND_TERMINATE 2 2991 When the Credit-Control-Failure-Handling AVP is set to 2992 RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the 2993 request to an alternative server in the case of transport or 2994 temporary failures, provided that a failover procedure is supported 2995 in the credit-control server and the credit-control client, and that 2996 an alternative server is available. Otherwise, the service SHOULD 2997 NOT be granted when the credit-control messages can't be delivered. 2999 8.15. Direct-Debiting-Failure-Handling AVP 3001 The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type 3002 Enumerated. The credit-control client uses information in this AVP 3003 to decide what to do if sending credit-control messages (Requested- 3004 Action AVP set to DIRECT_DEBITING) to the credit-control server has 3005 been, for instance, temporarily prevented due to a network problem. 3007 TERMINATE_OR_BUFFER 0 3009 When the Direct-Debiting-Failure-Handling AVP is set to 3010 TERMINATE_OR_BUFFER, the service MUST be granted for as long as there 3011 is a connection to the credit-control server. If the credit-control 3012 client does not receive any Credit-Control-Answer message within the 3013 Tx timer (as defined in Section 13) the credit-control request is 3014 regarded as failed. The client SHOULD terminate the service if it 3015 can determine from the failed answer that units have not been 3016 debited. Otherwise the credit-control client SHOULD grant the 3017 service, store the request in application level non-volatile storage, 3018 and try to re-send the request. These requests MUST be marked as 3019 possible duplicates by setting the T-flag in the command header as 3020 described in [RFC6733] section 3. This is the default behavior if 3021 the AVP isn't included in the reply from the authorization server. 3023 CONTINUE 1 3025 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 3026 service SHOULD be granted, even if credit-control messages can't be 3027 delivered, and the request should be deleted. 3029 8.16. Multiple-Services-Credit-Control AVP 3031 Multiple-Services-Credit-Control AVP (AVP Code 456) is of type 3032 Grouped and contains the AVPs related to the independent credit- 3033 control of multiple services feature. Note that each instance of 3034 this AVP carries units related to one or more services or related to 3035 a single rating group. 3037 The Service-Identifier and the Rating-Group AVPs are used to 3038 associate the granted units to a given service or rating group. If 3039 both the Service-Identifier and the Rating-Group AVPs are included, 3040 the target of the service units is always the service(s) indicated by 3041 the value of the Service-Identifier AVP(s). If only the Rating- 3042 Group-Id AVP is present, the Multiple-Services-Credit-Control AVP 3043 relates to all the services that belong to the specified rating 3044 group. 3046 The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- 3047 Pool-Identifier identifying a credit pool within which the units of 3048 the specified type are considered pooled. If a G-S-U-Pool-Reference 3049 AVP is present, then actual service units of the specified type MUST 3050 also be present. For example, if the G-S-U-Pool-Reference AVP 3051 specifies Unit-Type TIME, then the CC-Time AVP MUST be present. 3053 The Requested-Service-Unit AVP MAY contain the amount of requested 3054 service units or the requested monetary value. It MUST be present in 3055 the initial interrogation and within the intermediate interrogations 3056 in which new quota is requested. If the credit-control client does 3057 not include the Requested-Service-Unit AVP in a request command, 3058 because for instance, it has determined that the end-user terminated 3059 the service, the server MUST debit the used amount from the user's 3060 account but MUST NOT return a new quota in the corresponding answer. 3061 The Validity-Time, Result-Code, and Final-Unit-Indication or QoS- 3062 Final-Unit-Indication AVPs MAY be present in an answer command as 3063 defined in Section 5.1.2 and Section 5.6 for the graceful service 3064 termination. 3066 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 3067 present, the server MUST include two separate instances of the 3068 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit 3069 AVP associated to the same service-identifier and/or rating-group. 3070 Where the two quotas are associated to the same pool or to different 3071 pools, the credit pooling mechanism defined in Section 5.1.2 applies. 3072 The Tariff-Change-Usage AVP MUST NOT be included in request commands 3073 to report used units before, and after tariff time change the Used- 3074 Service-Unit AVP MUST be used. 3076 A server not implementing the independent credit-control of multiple 3077 services functionality MUST treat the Multiple-Services-Credit- 3078 Control AVP as an invalid AVP. 3080 The Multiple-Services-Control AVP is defined as follows (per the 3081 grouped-avp-def of [RFC6733]): 3083 Multiple-Services-Credit-Control ::= < AVP Header: 456 > 3084 [ Granted-Service-Unit ] 3085 [ Requested-Service-Unit ] 3086 *[ Used-Service-Unit ] 3087 [ Tariff-Change-Usage ] 3088 *[ Service-Identifier ] 3089 [ Rating-Group ] 3090 *[ G-S-U-Pool-Reference ] 3091 [ Validity-Time ] 3092 [ Result-Code ] 3093 [ Final-Unit-Indication ] 3094 [ QoS-Final-Unit-Indication ] 3095 *[ AVP ] 3097 8.17. Granted-Service-Unit AVP 3099 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 3100 contains the amount of units that the Diameter credit-control client 3101 can provide to the end user until the service must be released or the 3102 new Credit-Control-Request must be sent. A client is not required to 3103 implement all the unit types, and it must treat unknown or 3104 unsupported unit types in the answer message as an incorrect CCA 3105 answer. In this case, the client MUST terminate the credit-control 3106 session and indicate in the Termination-Cause AVP reason 3107 DIAMETER_BAD_ANSWER. 3109 The Granted-Service-Unit AVP is defined as follows (per the grouped- 3110 avp-def of [RFC6733]): 3112 Granted-Service-Unit ::= < AVP Header: 431 > 3113 [ Tariff-Time-Change ] 3114 [ CC-Time ] 3115 [ CC-Money ] 3116 [ CC-Total-Octets ] 3117 [ CC-Input-Octets ] 3118 [ CC-Output-Octets ] 3119 [ CC-Service-Specific-Units ] 3120 *[ AVP ] 3122 8.18. Requested-Service-Unit AVP 3124 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and 3125 contains the amount of requested units specified by the Diameter 3126 credit-control client. A server is not required to implement all the 3127 unit types, and it must treat unknown or unsupported unit types as 3128 invalid AVPs. 3130 The Requested-Service-Unit AVP is defined as follows (per the 3131 grouped-avp-def of [RFC6733]): 3133 Requested-Service-Unit ::= < AVP Header: 437 > 3134 [ CC-Time ] 3135 [ CC-Money ] 3136 [ CC-Total-Octets ] 3137 [ CC-Input-Octets ] 3138 [ CC-Output-Octets ] 3139 [ CC-Service-Specific-Units ] 3140 *[ AVP ] 3142 8.19. Used-Service-Unit AVP 3144 The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and 3145 contains the amount of used units measured from the point when the 3146 service became active or, if interim interrogations are used during 3147 the session, from the point when the previous measurement ended. 3148 Note: The values reported in a Used-Service-Unit AVP does not 3149 necessarily have a relation to the grant provided in a Granted- 3150 Service-Unit AVP, e.g., the value in this AVP may exceed the value in 3151 the grant. 3153 The Used-Service-Unit AVP is defined as follows (per the grouped-avp- 3154 def of [RFC6733]): 3156 Used-Service-Unit ::= < AVP Header: 446 > 3157 [ Tariff-Change-Usage ] 3158 [ CC-Time ] 3159 [ CC-Money ] 3160 [ CC-Total-Octets ] 3161 [ CC-Input-Octets ] 3162 [ CC-Output-Octets ] 3163 [ CC-Service-Specific-Units ] 3164 *[ AVP ] 3166 8.20. Tariff-Time-Change AVP 3168 The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is 3169 sent from the server to the client and includes the time in seconds 3170 since January 1, 1900, 00:00 UTC, when the tariff of the service will 3171 be changed. 3173 The tariff change mechanism is optional for the client and server, 3174 and it is not used for time-based services defined in Section 5. If 3175 a client does not support the tariff time change mechanism, it MUST 3176 treat Tariff-Time-Change AVP in the answer message as an incorrect 3177 CCA answer. In this case, the client terminates the credit-control 3178 session and indicates in the Termination-Cause AVP reason 3179 DIAMETER_BAD_ANSWER. 3181 Omission of this AVP means that no tariff change is to be reported. 3183 8.21. CC-Time AVP 3185 The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates 3186 the length of the requested, granted, or used time in seconds. 3188 8.22. CC-Money AVP 3190 The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the 3191 monetary amount in the given currency. The Currency-Code AVP SHOULD 3192 be included. It is defined as follows (per the grouped-avp-def of 3193 [RFC6733]): 3195 CC-Money ::= < AVP Header: 413 > 3196 { Unit-Value } 3197 [ Currency-Code ] 3199 8.23. CC-Total-Octets AVP 3201 The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and 3202 contains the total number of requested, granted, or used octets 3203 regardless of the direction (sent or received). 3205 8.24. CC-Input-Octets AVP 3207 The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and 3208 contains the number of requested, granted, or used octets that can 3209 be/have been received from the end user. 3211 8.25. CC-Output-Octets AVP 3213 The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and 3214 contains the number of requested, granted, or used octets that can 3215 be/have been sent to the end user. 3217 8.26. CC-Service-Specific-Units AVP 3219 The CC-Service-Specific-Units AVP (AVP Code 417) is of type 3220 Unsigned64 and specifies the number of service-specific units (e.g., 3221 number of events, points) given in a selected service. The service- 3222 specific units always refer to the service identified in the Service- 3223 Identifier AVP (or Rating-Group AVP when the Multiple-Services- 3224 Credit-Control AVP is used). 3226 8.27. Tariff-Change-Usage AVP 3228 The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and 3229 defines whether units are used before or after a tariff change, or 3230 whether the units straddled a tariff change during the reporting 3231 period. Omission of this AVP means that no tariff change has 3232 occurred. 3234 In addition, when present in answer messages as part of the Multiple- 3235 Services-Credit-Control AVP, this AVP defines whether units are 3236 allocated to be used before or after a tariff change event. 3238 When the Tariff-Time-Change AVP is present, omission of this AVP in 3239 answer messages means that the single quota mechanism applies. 3241 Tariff-Change-Usage can be one of the following: 3243 UNIT_BEFORE_TARIFF_CHANGE 0 3244 When present in the Multiple-Services-Credit-Control AVP, this value 3245 indicates the amount of the units allocated for use before a tariff 3246 change occurs. 3248 When present in the Used-Service-Unit AVP, this value indicates the 3249 amount of resource units used before a tariff change had occurred. 3251 UNIT_AFTER_TARIFF_CHANGE 1 3253 When present in the Multiple-Services-Credit-Control AVP, this value 3254 indicates the amount of the units allocated for use after a tariff 3255 change occurs. 3257 When present in the Used-Service-Unit AVP, this value indicates the 3258 amount of resource units used after tariff change had occurred. 3260 UNIT_INDETERMINATE 2 3262 The used unit contains the amount of units that straddle the tariff 3263 change (e.g., the metering process reports to the credit-control 3264 client in blocks of n octets, and one block straddled the tariff 3265 change). This value is to be used only in the Used-Service-Unit AVP. 3267 8.28. Service-Identifier AVP 3269 The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and 3270 contains the identifier of a service. The specific service the 3271 request relates to is uniquely identified by the combination of 3272 Service-Context-Id and Service-Identifier AVPs. 3274 A usage example of this AVP is illustrated in Appendix B.9. 3276 8.29. Rating-Group AVP 3278 The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and 3279 contains the identifier of a rating group. All the services subject 3280 to the same rating type are part of the same rating group. The 3281 specific rating group the request relates to is uniquely identified 3282 by the combination of Service-Context-Id and Rating-Group AVPs. 3284 A usage example of this AVP is illustrated in Appendix B.9. 3286 8.30. G-S-U-Pool-Reference AVP 3288 The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It 3289 is used in the Credit-Control-Answer message, and associates the 3290 Granted-Service-Unit AVP within which it appears with a credit pool 3291 within the session. 3293 The G-S-U-Pool-Identifier AVP specifies the credit pool from which 3294 credit is drawn for this unit type. 3296 The CC-Unit-Type AVP specifies the type of units for which credit is 3297 pooled. 3299 The Unit-Value AVP specifies the multiplier, which converts between 3300 service units of type CC-Unit-Type and abstract service units within 3301 the credit pool (and thus to service units of any other service or 3302 rating group associated with the same pool). 3304 The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- 3305 avp-def of [RFC6733]): 3307 G-S-U-Pool-Reference ::= < AVP Header: 457 > 3308 { G-S-U-Pool-Identifier } 3309 { CC-Unit-Type } 3310 { Unit-Value } 3312 8.31. G-S-U-Pool-Identifier AVP 3314 The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 3315 and identifies a credit pool within the session. 3317 8.32. CC-Unit-Type AVP 3319 The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and 3320 specifies the type of units considered to be pooled into a credit 3321 pool. 3323 The following values are defined for the CC-Unit-Type AVP: 3325 TIME 0 3326 MONEY 1 3327 TOTAL-OCTETS 2 3328 INPUT-OCTETS 3 3329 OUTPUT-OCTETS 4 3330 SERVICE-SPECIFIC-UNITS 5 3332 8.33. Validity-Time AVP 3334 The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is 3335 sent from the credit-control server to the credit-control client. 3336 The AVP contains the validity time of the granted service units. The 3337 measurement of the Validity-Time is started upon receipt of the 3338 Credit-Control-Answer Message containing this AVP. If the granted 3339 service units have not been consumed within the validity time 3340 specified in this AVP, the credit-control client MUST send a Credit- 3341 Control-Request message to the server, with CC-Request-Type set to 3342 UPDATE_REQUEST. The value field of the Validity-Time AVP is given in 3343 seconds. 3345 The Validity-Time AVP is also used for the graceful service 3346 termination (see Section 5.6) to indicate to the credit-control 3347 client how long the subscriber is allowed to use network resources 3348 after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) 3349 started. When the Validity-Time elapses, a new intermediate 3350 interrogation is sent to the server. 3352 8.34. Final-Unit-Indication AVP 3354 The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and 3355 indicates that the Granted-Service-Unit AVP in the Credit-Control- 3356 Answer, or in the AA answer, contains the final units for the 3357 service. After these units have expired, the Diameter credit-control 3358 client is responsible for executing the action indicated in the 3359 Final-Unit-Action AVP (see Section 5.6). 3361 If more than one unit type is received in the Credit-Control-Answer, 3362 the unit type that first expired SHOULD cause the credit-control 3363 client to execute the specified action. 3365 In the first interrogation, the Final-Unit-Indication AVP with Final- 3366 Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no 3367 Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA 3368 answer. This indicates to the Diameter credit-control client to 3369 execute the specified action immediately. If the home service 3370 provider policy is to terminate the service, naturally, the server 3371 SHOULD return the appropriate transient failure (see Section 9.1) in 3372 order to implement the policy-defined action. 3374 The Final-Unit-Action AVP defines the behavior of the service element 3375 when the user's account cannot cover the cost of the service and MUST 3376 always be present if the Final-Unit-Indication AVP is included in a 3377 command. 3379 If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit- 3380 Indication group MUST NOT contain any other AVPs. 3382 If the Final-Unit-Action AVP is set to REDIRECT at least the 3383 Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP 3384 or the Filter-Id AVP MAY be present in the Credit-Control-Answer 3385 message if the user is also allowed to access other services that are 3386 not accessible through the address given in the Redirect-Server AVP. 3388 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3389 Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3391 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 3392 used to reference an IP filter list installed in the access device by 3393 means other than the Diameter credit-control application, e.g., 3394 locally configured or configured by another entity. 3396 If the Final-Unit-Action AVP is set to REDIRECT and the type of 3397 server is not one of the enumerations in the Redirect-Address-Type 3398 AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together 3399 with the Redirect-Server-Extension AVP instead of the Final-Unit- 3400 Indication AVP. 3402 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT 3403 and the classification of the restricted traffic cannot be expressed 3404 using IPFilterRule, or different actions (e.g., QoS) than just 3405 allowing traffic needs to be enforced, then the QoS-Final-Unit- 3406 Indication AVP SHOULD be used instead of the Final-Unit-Indication 3407 AVP. However, if the credit-control server wants to preserve 3408 backward compatibility with credit-control clients that support only 3409 [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with 3410 the Filter-Id AVP. 3412 The Final-Unit-Indication AVP is defined as follows (per the grouped- 3413 avp-def of [RFC6733]): 3415 Final-Unit-Indication ::= < AVP Header: 430 > 3416 { Final-Unit-Action } 3417 *[ Restriction-Filter-Rule ] 3418 *[ Filter-Id ] 3419 [ Redirect-Server ] 3421 8.35. Final-Unit-Action AVP 3423 The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and 3424 indicates to the credit-control client the action to be taken when 3425 the user's account cannot cover the service cost. 3427 The Final-Unit-Action can be one of the following: 3429 TERMINATE 0 3431 The credit-control client MUST terminate the service session. This 3432 is the default handling, applicable whenever the credit-control 3433 client receives an unsupported Final-Unit-Action value, and it MUST 3434 be supported by all the Diameter credit-control client 3435 implementations conforming to this specification. 3437 REDIRECT 1 3439 The service element MUST redirect the user to the address specified 3440 in the Redirect-Server-Address AVP or one of the AVPs included in the 3441 Redirect-Server-Extension AVP. The redirect action is defined in 3442 Section 5.6.2. 3444 RESTRICT_ACCESS 2 3446 The access device MUST restrict the user access according to the 3447 filter AVPs contained in the applied grouped AVP: according to IP 3448 packet filters defined in the Restriction-Filter-Rule AVP, according 3449 to the packet classifier filters defined in Filter-Rule AVP, or 3450 according to the packet filters identified by the Filter-Id AVP. All 3451 the packets not matching any filters MUST be dropped (see 3452 Section 5.6.3). 3454 8.36. Restriction-Filter-Rule AVP 3456 The Restriction-Filter-Rule AVP (AVP Code 438) is of type 3457 IPFilterRule and provides filter rules corresponding to services that 3458 are to remain accessible even if there are no more service units 3459 granted. The access device has to configure the specified filter 3460 rules for the subscriber and MUST drop all the packets not matching 3461 these filters. Zero, one, or more such AVPs MAY be present in a 3462 Credit-Control-Answer message or in an AA answer message. 3464 8.37. Redirect-Server AVP 3466 The Redirect-Server AVP (AVP Code 434) is of type Grouped and 3467 contains the address information of the redirect server (e.g., HTTP 3468 redirect server, SIP Server) with which the end user is to be 3469 connected when the account cannot cover the service cost. It MUST be 3470 present when the Final-Unit-Action AVP is set to REDIRECT. 3472 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3474 Redirect-Server ::= < AVP Header: 434 > 3475 { Redirect-Address-Type } 3476 { Redirect-Server-Address } 3478 8.38. Redirect-Address-Type AVP 3480 The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated 3481 and defines the address type of the address given in the Redirect- 3482 Server-Address AVP. 3484 The address type can be one of the following: 3486 IPv4 Address 0 3488 The address type is in the form of "dotted-decimal" IPv4 address, as 3489 defined in [RFC0791]. 3491 IPv6 Address 1 3493 The address type is in the form of IPv6 address, as defined in 3494 [RFC4291]. The address MUST conform to the text representation of 3495 the address according to [RFC5952]. 3497 URL 2 3499 The address type is in the form of Uniform Resource Locator, as 3500 defined in [RFC3986]. 3502 SIP URI 3 3504 The address type is in the form of SIP Uniform Resource Identifier, 3505 as defined in [RFC3261]. 3507 8.39. Redirect-Server-Address AVP 3509 The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String 3510 and defines the address of the redirect server (e.g., HTTP redirect 3511 server, SIP Server) with which the end user is to be connected when 3512 the account cannot cover the service cost. 3514 8.40. Multiple-Services-Indicator AVP 3516 The Multiple-Services-Indicator AVP (AVP Code 455) is of type 3517 Enumerated and indicates whether the Diameter credit-control client 3518 is capable of handling multiple services independently within a 3519 (sub-) session. The absence of this AVP means that independent 3520 credit-control of multiple services is not supported. 3522 A server not implementing the independent credit-control of multiple 3523 services MUST treat the Multiple-Services-Indicator AVP as an invalid 3524 AVP. 3526 The following values are defined for the Multiple-Services-Indicator 3527 AVP: 3529 MULTIPLE_SERVICES_NOT_SUPPORTED 0 3531 Client does not support independent credit-control of multiple 3532 services within a (sub-)session. 3534 MULTIPLE_SERVICES_SUPPORTED 1 3536 Client supports independent credit-control of multiple services 3537 within a (sub-)session. 3539 8.41. Requested-Action AVP 3541 The Requested-Action AVP (AVP Code 436) is of type Enumerated and 3542 contains the requested action being sent by Credit-Control-Request 3543 command where the CC-Request-Type is set to EVENT_REQUEST. The 3544 following values are defined for the Requested-Action AVP: 3546 DIRECT_DEBITING 0 3548 This indicates a request to decrease the end user's account according 3549 to information specified in the Requested-Service-Unit AVP and/or 3550 Service-Identifier AVP (additional rating information may be included 3551 in service-specific AVPs or in the Service-Parameter-Info AVP). The 3552 Granted-Service-Unit AVP in the Credit-Control-Answer command 3553 contains the debited units. 3555 REFUND_ACCOUNT 1 3557 This indicates a request to increase the end user's account according 3558 to information specified in the Requested-Service-Unit AVP and/or 3559 Service-Identifier AVP (additional rating information may be included 3560 in service-specific AVPs or in the Service-Parameter-Info AVP). The 3561 Granted-Service-Unit AVP in the Credit-Control-Answer command 3562 contains the refunded units. 3564 CHECK_BALANCE 2 3566 This indicates a balance check request. In this case, the checking 3567 of the account balance is done without any credit reservation from 3568 the account. The Check-Balance-Result AVP in the Credit-Control- 3569 Answer command contains the result of the balance check. 3571 PRICE_ENQUIRY 3 3572 This indicates a price enquiry request. In this case, neither 3573 checking of the account balance nor reservation from the account will 3574 be done; only the price of the service will be returned in the Cost- 3575 Information AVP in the Credit-Control-Answer Command. 3577 8.42. Service-Context-Id AVP 3579 The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and 3580 contains a unique identifier of the Diameter credit-control service 3581 specific document that applies to the request (as defined in 3582 Section 4.1.2). This is an identifier allocated by the service 3583 provider, by the service element manufacturer, or by a 3584 standardization body, and MUST uniquely identify a given Diameter 3585 credit-control service specific document. The format of the Service- 3586 Context-Id is: 3588 "service-context" "@" "domain" 3590 service-context = Token 3592 The Token is an arbitrary string of characters and digits. 3594 'domain' represents the entity that allocated the Service-Context-Id. 3595 It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by 3596 a standardization body, or it can be the FQDN of the service provider 3597 (e.g., provider.example.com) or of the vendor (e.g., 3598 vendor.example.com) if the identifier is allocated by a private 3599 entity. 3601 This AVP SHOULD be placed as close to the Diameter header as 3602 possible. 3604 Service-specific documents that are for private use only (i.e., to 3605 one provider's own use, where no interoperability is deemed useful) 3606 may define private identifiers without need of coordination. 3607 However, when interoperability is wanted, coordination of the 3608 identifiers via, for example, publication of an informational RFC is 3609 RECOMMENDED in order to make Service-Context-Id globally available. 3611 8.43. Service-Parameter-Info AVP 3613 The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and 3614 contains service-specific information used for price calculation or 3615 rating. The Service-Parameter-Type AVP defines the service parameter 3616 type, and the Service-Parameter-Value AVP contains the parameter 3617 value. The actual contents of these AVPs are not within the scope of 3618 this document and SHOULD be defined in another Diameter application, 3619 in standards written by other standardization bodies, or in service- 3620 specific documentation. 3622 In the case of an unknown service request (e.g., unknown Service- 3623 Parameter-Type), the corresponding answer message MUST contain the 3624 error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message 3625 with this error MUST contain one or more Failed-AVP AVPs containing 3626 the Service-Parameter-Info AVPs that caused the failure. 3628 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3630 Service-Parameter-Info ::= < AVP Header: 440 > 3631 { Service-Parameter-Type } 3632 { Service-Parameter-Value } 3634 8.44. Service-Parameter-Type AVP 3636 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) 3637 and defines the type of the service event specific parameter (e.g., 3638 it can be the end-user location or service name). The different 3639 parameters and their types are service specific, and the meanings of 3640 these parameters are not defined in this document. Whoever allocates 3641 the Service-Context-Id (i.e., unique identifier of a service-specific 3642 document) is also responsible for assigning Service-Parameter-Type 3643 values for the service and ensuring their uniqueness within the given 3644 service. The Service-Parameter-Value AVP contains the value 3645 associated with the service parameter type. 3647 8.45. Service-Parameter-Value AVP 3649 The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) 3650 and contains the value of the service parameter type. 3652 8.46. Subscription-Id AVP 3654 The Subscription-Id AVP (AVP Code 443) is used to identify the end 3655 user's subscription and is of type Grouped. The Subscription-Id AVP 3656 includes a Subscription-Id-Data AVP that holds the identifier and a 3657 Subscription-Id-Type AVP that defines the identifier type. 3659 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3661 Subscription-Id ::= < AVP Header: 443 > 3662 { Subscription-Id-Type } 3663 { Subscription-Id-Data } 3665 8.47. Subscription-Id-Type AVP 3667 The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, 3668 and it is used to determine which type of identifier is carried by 3669 the Subscription-Id AVP. 3671 This specification defines the following subscription identifiers. 3672 However, new Subscription-Id-Type values can be assigned by an IANA 3673 designated expert, as defined in Section 12. A server MUST implement 3674 all the Subscription-Id-Types required to perform credit 3675 authorization for the services it supports, including possible future 3676 values. Unknown or unsupported Subscription-Id-Types MUST be treated 3677 according to the 'M' flag rule, as defined in [RFC6733]. 3679 END_USER_E164 0 3681 The identifier is in international E.164 format (e.g., MSISDN), 3682 according to the ITU-T E.164 numbering plan defined in [E164] and 3683 [CE164]. 3685 END_USER_IMSI 1 3687 The identifier is in international IMSI format, according to the 3688 ITU-T E.212 numbering plan as defined in [E212] and [CE212]. 3690 END_USER_SIP_URI 2 3692 The identifier is in the form of a SIP URI, as defined in [RFC3261]. 3694 END_USER_NAI 3 3696 The identifier is in the form of a Network Access Identifier, as 3697 defined in [RFC7542]. 3699 END_USER_PRIVATE 4 3701 The Identifier is a credit-control server private identifier. 3703 8.48. Subscription-Id-Data AVP 3705 The Subscription-Id-Data AVP (AVP Code 444) is used to identify the 3706 end user and is of type UTF8String. The Subscription-Id-Type AVP 3707 defines which type of identifier is used. 3709 8.49. User-Equipment-Info AVP 3711 The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and 3712 allows the credit-control client to indicate the identity and 3713 capability of the terminal the subscriber is using for the connection 3714 to network. 3716 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3718 User-Equipment-Info ::= < AVP Header: 458 > 3719 { User-Equipment-Info-Type } 3720 { User-Equipment-Info-Value } 3722 8.50. User-Equipment-Info-Type AVP 3724 The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) 3725 and defines the type of user equipment information contained in the 3726 User-Equipment-Info-Value AVP. 3728 This specification defines the following user equipment types. 3729 However, new User-Equipment-Info-Type values can be assigned by an 3730 IANA designated expert, as defined in Section 12. 3732 IMEISV 0 3734 The identifier contains the International Mobile Equipment Identifier 3735 and Software Version in the international IMEISV format according to 3736 3GPP TS 23.003 [TGPPIMEI]. 3738 MAC 1 3740 The 48-bit MAC address is formatted as described in [RFC3580]. 3742 EUI64 2 3744 The 64-bit identifier used to identify the hardware instance of the 3745 product, as defined in [EUI64]. 3747 MODIFIED_EUI64 3 3749 There are a number of types of terminals that have identifiers other 3750 than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be 3751 converted to modified EUI-64 format as described in [RFC4291] or by 3752 using some other methods referred to in the service-specific 3753 documentation. 3755 8.51. User-Equipment-Info-Value AVP 3757 The User-Equipment-Info-Value AVP (AVP Code 460) is of type 3758 OctetString. The User-Equipment-Info-Type AVP defines which type of 3759 identifier is used. 3761 8.52. User-Equipment-Info-Extension AVP 3763 The User-Equipment-Info-Extension AVP (AVP Code TBD1) is of type 3764 Grouped and allows the credit-control client to indicate the identity 3765 and capability of the terminal the subscriber is using for the 3766 connection to network. If the type of the equipment is one of the 3767 enumerated types of User-Equipment-Info-Type AVP, then the credit- 3768 control client SHOULD send the information in the User-Equipment-Info 3769 AVP, in addition to or instead of the User-Equipment-Info-Extension 3770 AVP. This is in order to preserve backward compatibility with 3771 credit-control servers that support only [RFC4006]. Exactly one AVP 3772 MUST be included inside the User-Equipment-Info-Extension AVP. 3774 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3776 User-Equipment-Info-Extension ::= < AVP Header: TBD1 > 3777 [ User-Equipment-Info-IMEISV ] 3778 [ User-Equipment-Info-MAC ] 3779 [ User-Equipment-Info-EUI64 ] 3780 [ User-Equipment-Info-ModifiedEUI64 ] 3781 [ User-Equipment-Info-IMEI ] 3782 [ AVP ] 3784 8.53. User-Equipment-Info-IMEISV AVP 3786 The User-Equipment-Info-IMEISV (AVP Code TBD2) is of type 3787 OctetString. The User-Equipment-Info-IMEISV AVP contains the 3788 International Mobile Equipment Identifier and Software Version in the 3789 international IMEISV format according to 3GPP TS 23.003 [TGPPIMEI]. 3791 8.54. User-Equipment-Info-MAC AVP 3793 The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. 3794 The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is 3795 formatted as described in [RFC3580]. 3797 8.55. User-Equipment-Info-EUI64 AVP 3799 The User-Equipment-Info-EUI64 (AVP Code TBD4) is of type OctetString. 3800 The UUser-Equipment-Info-EUI64 AVP contains the 64-bit identifier 3801 used to identify the hardware instance of the product, as defined in 3802 [EUI64]. 3804 8.56. User-Equipment-Info-ModifiedEUI64 AVP 3806 The User-Equipment-Info-ModifiedEUI64 (AVP Code TBD5) is of type 3807 OctetString. There are a number of types of terminals that have 3808 identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These 3809 identifiers can be converted to modified EUI-64 format as described 3810 in [RFC4291] or by using some other methods referred to in the 3811 service-specific documentation. The User-Equipment-Info- 3812 ModifiedEUI64 AVP contains such identifiers. 3814 8.57. User-Equipment-Info-IMEI AVP 3816 The User-Equipment-Info-IMEI (AVP Code TBD6) is of type OctetString. 3817 The User-Equipment-Info-IMEI AVP contains the International Mobile 3818 Equipment Identifier in the international IMEI format according to 3819 3GPP TS 23.003 [TGPPIMEI]. 3821 8.58. Subscription-Id-Extension AVP 3823 The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify 3824 the end user's subscription and is of type Grouped. The 3825 Subscription-Id-Extension group AVP MUST include an AVP holding the 3826 subscription identifier. The type of this included AVP indicates the 3827 type of the subscription identifier. For each of the enumerated 3828 values of the Subscription-Id-Type AVP, there is a corresponding sub- 3829 AVP for use within the Subscription-Id-Extension group AVP. If a new 3830 identifier type is required a corresponding new sub-AVP SHOULD be 3831 defined for use within the Subscription-Id-Extension group AVP. 3833 If full backward compatibility with [RFC4006] is required, then the 3834 Subscription-Id AVP MUST be used to indicate identifier types 3835 enumerated in the Subscription-Id-Type AVP, whereas the Subscription- 3836 Id-Extension AVP MUST be used only for newly defined identifier 3837 types. If full backward compatibility with [RFC4006] is not 3838 required, then the Subscription-Id-Extension AVP MAY be used to carry 3839 out the existing identifier types. In this case, Subscription-Id- 3840 Extension AVP MAY be sent together with Subscription-Id AVP. 3842 Exactly one sub-AVP MUST be included inside the Subscription-Id- 3843 Extension AVP. 3845 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3847 Subscription-Id-Extension ::= < AVP Header: TBD7 > 3848 [ Subscription-Id-E164 ] 3849 [ Subscription-Id-IMSI ] 3850 [ Subscription-Id-SIP-URI ] 3851 [ Subscription-Id-NAI ] 3852 [ Subscription-Id-Private ] 3853 [ AVP ] 3855 8.59. Subscription-Id-E164 AVP 3857 The Subscription-Id-E164 (AVP Code TBD8) is of type UTF8String. The 3858 Subscription-Id-E164 AVP contains the international E.164 format 3859 (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined 3860 in [E164] and [CE164]. 3862 8.60. Subscription-Id-IMSI AVP 3864 The Subscription-Id-IMSI (AVP Code TBD9) is of type UTF8String. The 3865 Subscription-Id-IMSI AVP contains the international IMSI format, 3866 according to the ITU-T E.212 numbering plan as defined in [E212] and 3867 [CE212]. 3869 8.61. Subscription-Id-SIP-URI AVP 3871 The Subscription-Id-SIP-URI (AVP Code TBD10) is of type UTF8String. 3872 The Subscription-Id-SIP-URI AVP contains the identifier in the form 3873 of a SIP URI, as defined in [RFC3261]. 3875 8.62. Subscription-Id-NAI AVP 3877 The Subscription-Id-NAI (AVP Code TBD11) is of type UTF8String. The 3878 Subscription-Id-NAI AVP contains the identifier in the form of a 3879 Network Access Identifier, as defined in [RFC7542]. 3881 8.63. Subscription-Id-Private AVP 3883 The Subscription-Id-Private (AVP Code TBD12) is of type UTF8String. 3884 The Subscription-Id-Private AVP contains a credit-control server 3885 private identifier. 3887 8.64. Redirect-Server-Extension AVP 3889 The Redirect-Server-Extension AVP (AVP Code TBD13) is of type Grouped 3890 and contains the address information of the redirect server (e.g., 3891 HTTP redirect server, SIP Server) with which the end user is to be 3892 connected when the account cannot cover the service cost. It MUST be 3893 present inside the QoS-Final-Unit-Indication AVP when the Final-Unit- 3894 Action AVP is set to REDIRECT. If the type of the redirect server is 3895 one of the enumerated values of the Redirect-Address-Type AVP, then 3896 the credit-control server SHOULD send the information in the 3897 Redirect-Server AVP, in addition to or instead of the Redirect- 3898 Server-Extension AVP. This is in order to preserve backward 3899 compatibility with credit-control clients that support only 3900 [RFC4006]. Exactly one AVP MUST be included inside the Redirect- 3901 Server-Extension AVP. 3903 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3905 Redirect-Server-Extension ::= < AVP Header: TBD13 > 3906 [ Redirect-Address-IPAddress ] 3907 [ Redirect-Address-URL ] 3908 [ Redirect-Address-SIP-URI ] 3909 [ AVP ] 3911 8.65. Redirect-Address-IPAddress AVP 3913 The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type 3914 Address and defines the IPv4 or IPv6 address of the redirect server 3915 with which the end user is to be connected when the account cannot 3916 cover the service cost. 3918 When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 3919 format [RFC4291] MAY be used to indicate an IPv4 address. 3921 8.66. Redirect-Address-URL AVP 3923 The Redirect-Address-URL AVP (AVP Code TBD15) is of type UTF8String 3924 and defines the address of the redirect server with which the end 3925 user is to be connected when the account cannot cover the service 3926 cost. The address type is in the form of Uniform Resource Locator, 3927 as defined in [RFC3986]. 3929 8.67. Redirect-Address-SIP-URI AVP 3931 The Redirect-Address-SIP-URI AVP (AVP Code TBD16) is of type 3932 UTF8String and defines the address of the redirect server with which 3933 the end user is to be connected when the account cannot cover the 3934 service cost. The address type is in the form of SIP Uniform 3935 Resource Identifier, as defined in [RFC3261]. 3937 8.68. QoS-Final-Unit-Indication AVP 3939 The QoS-Final-Unit-Indication AVP (AVP Code TBD17) is of type Grouped 3940 and indicates that the Granted-Service-Unit AVP in the Credit- 3941 Control-Answer, or in the AA answer, contains the final units for the 3942 service. After these units have expired, the Diameter credit-control 3943 client is responsible for executing the action indicated in the 3944 Final-Unit-Action AVP (see Section 5.6). 3946 If more than one unit type is received in the Credit-Control-Answer, 3947 the unit type that first expired SHOULD cause the credit-control 3948 client to execute the specified action. 3950 In the first interrogation, the QoS-Final-Unit-Indication AVP with 3951 Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present 3952 with no Granted-Service-Unit AVP in the Credit-Control-Answer or in 3953 the AA answer. This indicates to the Diameter credit-control client 3954 to execute the specified action immediately. If the home service 3955 provider policy is to terminate the service, naturally, the server 3956 SHOULD return the appropriate transient failure (see Section 9.1) in 3957 order to implement the policy-defined action. 3959 The Final-Unit-Action AVP defines the behavior of the service element 3960 when the user's account cannot cover the cost of the service and MUST 3961 always be present if the QoS-Final-Unit-Indication AVP is included in 3962 a command. 3964 If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit- 3965 Indication group MUST NOT contain any other AVPs. 3967 If the Final-Unit-Action AVP is set to REDIRECT at least the 3968 Redirect-Server-Extension AVP MUST be present. The Filter-Rule AVP 3969 or the Filter-Id AVP MAY be present in the Credit-Control-Answer 3970 message if the user is also allowed to access other services that are 3971 not accessible through the address given in the Redirect-Server- 3972 Extension AVP or if the access to these services needs to be limited 3973 in some way (e.g., QoS). 3975 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3976 Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3978 The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can 3979 be used to define a specific condition and action combination. If 3980 used only with traffic conditions, it should define which traffic 3981 should allowed when no more service units are granted. However, if 3982 QoS or treatment information exists in the AVP, these actions should 3983 be executed, e.g., limiting the allowed traffic with certain QoS. 3985 When multiple Filter-Rule AVPs exist, precedence should be determined 3986 as defined in [RFC5777]. 3988 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 3989 used to reference an IP filter list installed in the access device by 3990 means other than the Diameter credit-control application, e.g., 3991 locally configured or configured by another entity. 3993 If the Final-Unit-Action AVP is set to TERMINATE, or set to 3994 RESTRICT_ACCESS and the action required is allow only traffic that 3995 could be classified using an IPFilterRule, or set to REDIRECT of a 3996 type which is one of the types in the Redirect-Address-Type AVP, then 3997 the credit-control server SHOULD send the information in the Final- 3998 Unit-Indication AVP, in addition to or instead of the QoS-Final-Unit- 3999 Indication AVP. This is in order to preserve backward compatibility 4000 with credit-control clients that support only [RFC4006]. 4002 The QoS-Final-Unit-Indication AVP is defined as follows (per the 4003 grouped-avp-def of [RFC6733]): 4005 QoS-Final-Unit-Indication ::= < AVP Header: TBD17 > 4006 { Final-Unit-Action } 4007 *[ Filter-Rule ] 4008 *[ Filter-Id ] 4009 [ Redirect-Server-Extension ] 4010 *[ AVP ] 4012 9. Result Code AVP Values 4014 This section defines new Result-Code AVP [RFC6733] values that must 4015 be supported by all Diameter implementations that conform to this 4016 specification. 4018 The Credit-Control-Answer message includes the Result-Code AVP, which 4019 may indicate that an error was present in the Credit-Control-Request 4020 message. A rejected Credit-Control-Request message SHOULD cause the 4021 user's session to be terminated. 4023 9.1. Transient Failures 4025 Errors that fall within the transient failures category are used to 4026 inform a peer that the request could not be satisfied at the time it 4027 was received, but that the request MAY be able to be satisfied in the 4028 future. 4030 DIAMETER_END_USER_SERVICE_DENIED 4010 4031 The credit-control server denies the service request due to service 4032 restrictions. If the CCR contained used-service-units, they are 4033 deducted, if possible. 4035 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 4037 The credit-control server determines that the service can be granted 4038 to the end user but that no further credit-control is needed for the 4039 service (e.g., service is free of charge). 4041 DIAMETER_CREDIT_LIMIT_REACHED 4012 4043 The credit-control server denies the service request because the end 4044 user's account could not cover the requested service. If the CCR 4045 contained used-service-units they are deducted, if possible. 4047 9.2. Permanent Failures 4049 Errors that fall within the permanent failure category are used to 4050 inform the peer that the request failed and should not be attempted 4051 again. 4053 DIAMETER_USER_UNKNOWN 5030 4055 The specified end user is unknown in the credit-control server. 4057 DIAMETER_RATING_FAILED 5031 4059 This error code is used to inform the credit-control client that the 4060 credit-control server cannot rate the service request due to 4061 insufficient rating input, an incorrect AVP combination, or an AVP or 4062 an AVP value that is not recognized or supported in the rating. The 4063 Failed-AVP AVP MUST be included and contain a copy of the entire 4064 AVP(s) that could not be processed successfully or an example of the 4065 missing AVP complete with the Vendor-Id if applicable. The value 4066 field of the missing AVP should be of correct minimum length and 4067 contain zeros. 4069 10. AVP Occurrence Table 4071 The following table presents the AVPs defined in this document and 4072 specifies in which Diameter messages they MAY or MUST NOT be present. 4073 Note that AVPs that can only be present within a Grouped AVP are not 4074 represented in this table. 4076 The table uses the following symbols: 4078 0 The AVP MUST NOT be present in the message. 4079 0+ Zero or more instances of the AVP MAY be present in the 4080 message. 4081 0-1 Zero or one instance of the AVP MAY be present in the 4082 message. It is considered an error if there is more 4083 than one instance of the AVP. 4084 1 One instance of the AVP MUST be present in the message. 4085 1+ At least one instance of the AVP MUST be present in the 4086 message. 4088 10.1. Credit-Control AVP Table 4090 The table in this section is used to represent which credit-control 4091 applications specific AVPs defined in this document are to be present 4092 in the credit-control messages. 4094 +-----------+ 4095 | Command | 4096 | Code | 4097 |-----+-----+ 4098 Attribute Name | CCR | CCA | 4099 ------------------------------|-----+-----+ 4100 Acct-Multi-Session-Id | 0-1 | 0-1 | 4101 Auth-Application-Id | 1 | 1 | 4102 CC-Correlation-Id | 0-1 | 0 | 4103 CC-Session-Failover | 0 | 0-1 | 4104 CC-Request-Number | 1 | 1 | 4105 CC-Request-Type | 1 | 1 | 4106 CC-Sub-Session-Id | 0-1 | 0-1 | 4107 Check-Balance-Result | 0 | 0-1 | 4108 Cost-Information | 0 | 0-1 | 4109 Credit-Control-Failure- | 0 | 0-1 | 4110 Handling | | | 4111 Destination-Host | 0-1 | 0 | 4112 Destination-Realm | 1 | 0 | 4113 Direct-Debiting-Failure- | 0 | 0-1 | 4114 Handling | | | 4115 Event-Timestamp | 0-1 | 0-1 | 4116 Failed-AVP | 0 | 0+ | 4117 Final-Unit-Indication | 0 | 0-1 | 4118 QoS-Final-Unit-Indication | 0 | 0-1 | 4119 Granted-Service-Unit | 0 | 0-1 | 4120 Multiple-Services-Credit- | 0+ | 0+ | 4121 Control | | | 4122 Multiple-Services-Indicator | 0-1 | 0 | 4123 Origin-Host | 1 | 1 | 4124 Origin-Realm | 1 | 1 | 4125 Origin-State-Id | 0-1 | 0-1 | 4126 Proxy-Info | 0+ | 0+ | 4127 Redirect-Host | 0 | 0+ | 4128 Redirect-Host-Usage | 0 | 0-1 | 4129 Redirect-Max-Cache-Time | 0 | 0-1 | 4130 Requested-Action | 0-1 | 0 | 4131 Requested-Service-Unit | 0-1 | 0 | 4132 Route-Record | 0+ | 0+ | 4133 Result-Code | 0 | 1 | 4134 Service-Context-Id | 1 | 0 | 4135 Service-Identifier | 0-1 | 0 | 4136 Service-Parameter-Info | 0+ | 0 | 4137 Session-Id | 1 | 1 | 4138 Subscription-Id | 0+ | 0 | 4139 Subscription-Id-Extension | 0+ | 0 | 4140 Termination-Cause | 0-1 | 0 | 4141 User-Equipment-Info | 0-1 | 0 | 4142 User-Equipment-Info-Extension | 0-1 | 0 | 4143 Used-Service-Unit | 0+ | 0 | 4144 User-Name | 0-1 | 0-1 | 4145 Validity-Time | 0 | 0-1 | 4146 ------------------------------|-----+-----+ 4148 10.2. Re-Auth-Request/Answer AVP Table 4150 This section defines AVPs that are specific to the Diameter credit- 4151 control application and that MAY be included in the Diameter Re-Auth- 4152 Request/Answer (RAR/RAA) message [RFC6733]. 4154 Re-Auth-Request/Answer command MAY include the following additional 4155 AVPs: 4157 +---------------+ 4158 | Command Code | 4159 |-------+-------+ 4160 Attribute Name | RAR | RAA | 4161 ------------------------------+-------+-------+ 4162 CC-Sub-Session-Id | 0-1 | 0-1 | 4163 G-S-U-Pool-Identifier | 0-1 | 0-1 | 4164 Service-Identifier | 0-1 | 0-1 | 4165 Rating-Group | 0-1 | 0-1 | 4166 ------------------------------+-------+-------+ 4168 11. RADIUS/Diameter Credit-Control Interworking Model 4170 This section defines the basic principles for the Diameter credit- 4171 control/RADIUS prepaid inter-working model; that is, a message 4172 translation between a RADIUS based prepaid solution and a Diameter 4173 credit-control application. A complete description of the protocol 4174 translations between RADIUS and the Diameter credit-control 4175 application is beyond the scope of this specification and SHOULD be 4176 addressed in another appropriate document, such as the RADIUS prepaid 4177 specification. 4179 The Diameter credit-control architecture may have a Translation Agent 4180 capable of translation between RADIUS prepaid and Diameter credit- 4181 control protocols. An AAA server (usually the home AAA server) may 4182 act as a Translation Agent and as a Diameter credit-control client 4183 for service elements that use credit-control mechanisms other than 4184 Diameter credit-control for instance, RADIUS prepaid. In this case, 4185 the home AAA server contacts the Diameter credit-control server as 4186 part of the authorization process. The interworking architecture is 4187 illustrated Figure 9, and interworking flow in Figure 10. In a 4188 roaming situation the service element (e.g., the NAS) may be located 4189 in the visited network, and a visited AAA server is usually 4190 contacted. The visited AAA server connects then to the home AAA 4191 server. 4193 RADIUS Prepaid 4194 +--------+ +---------+ protocol +------------+ +--------+ 4195 | End |<----->| Service |<---------->| Home AAA | |Business| 4196 | User | | Element | | Server | |Support | 4197 +--------+ +-->| | |+----------+|->|System | 4198 | +---------+ ||CC Client || | | 4199 | |+----------+| | | 4200 +--------+ | +------^-----+ +----^---+ 4201 | End |<--+ Credit-Control | | 4202 | User | Protocol | | 4203 +--------+ +-------V--------+ | 4204 |Credit-Control |----+ 4205 | Server | 4206 +----------------+ 4208 Figure 9: Credit-control architecture with service element containing 4209 translation agent, translating RADIUS prepaid to Diameter credit- 4210 control protocol 4212 When the AAA server acting as a Translation Agent receives an initial 4213 RADIUS Access-Request message from service element (e.g., NAS 4214 access), it performs regular authentication and authorization. If 4215 the RADIUS Access-Request message indicates that the service element 4216 is capable of credit-control, and if the home AAA server finds that 4217 the subscriber is a prepaid subscriber, then a Diameter credit- 4218 control request SHOULD be sent toward the credit-control server to 4219 perform credit authorization and to establish a credit-control 4220 session. After the Diameter credit-control server checks the end 4221 user's account balance, rates the service, and reserves credit from 4222 the end user's account, the reserved quota is returned to the home 4223 AAA server in the Diameter Credit-Control-Answer. Then the home AAA 4224 server sends the reserved quota to the service element in the RADIUS 4225 Access-Accept. 4227 At the expiry of the allocated quota, the service element sends a new 4228 RADIUS Access-Request containing the units used this far to the home 4229 AAA server. The home AAA server shall map a RADIUS Access-Request 4230 containing the reported units to the Diameter credit-control server 4231 in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter 4232 credit-control server debits the used units from the end user's 4233 account and allocates a new quota that is returned to the home AAA 4234 server in the Diameter Credit-Control-Answer. The quota is 4235 transferred to the service element in the RADIUS Access-Accept. When 4236 the end user terminates the service, or when the entire quota has 4237 been used, the service element sends a RADIUS Access-Request. To 4238 debit the used units from the end user's account and to stop the 4239 credit-control session, the home AAA server sends a Diameter Credit- 4240 Control-Request (TERMINATION_REQUEST) to the credit-control server. 4241 The Diameter credit-control server acknowledges the session 4242 termination by sending a Diameter Credit-Control-Answer to the home 4243 AAA server. The RADIUS Access-Accept is sent to the NAS. 4245 A following diagram illustrates a RADIUS prepaid - Diameter credit- 4246 control interworking sequence. 4248 Service Element Translation Agent 4249 (e.g., NAS) (CC Client) CC Server 4250 | Access-Request | | 4251 |----------------------->| | 4252 | | CCR (initial) | 4253 | |----------------------->| 4254 | | CCA (Granted-Units) | 4255 | |<-----------------------| 4256 | Access-Accept | | 4257 | (Granted-Units) | | 4258 |<-----------------------| | 4259 : : : 4260 | Access-Request | | 4261 | (Used-Units) | | 4262 |----------------------->| | 4263 | | CCR (update, | 4264 | | Used-Units) | 4265 | |----------------------->| 4266 | | CCA (Granted-Units) | 4267 | |<-----------------------| 4268 | Access-Accept | | 4269 | (Granted-Units) | | 4270 |<-----------------------| | 4271 : : : 4272 | Access-Request | | 4273 |----------------------->| | 4274 | | CCR (terminate, | 4275 | | Used-Units) | 4276 | |----------------------->| 4277 | | CCA | 4278 | |<-----------------------| 4279 | Access-Accept | | 4280 |<-----------------------| | 4281 | | | 4283 Figure 10: Message flow example with RADIUS prepaid - Diameter 4284 credit-control interworking 4286 12. IANA Considerations 4288 This section contains the namespaces that have either been created in 4289 this specification, or the values assigned to existing namespaces 4290 managed by IANA. 4292 In the subsections below, when we speak about review by a Designated 4293 Expert, please note that the designated expert will be assigned by 4294 the IESG. Initially, such Expert discussions take place on the AAA 4295 WG mailing list. 4297 12.1. Application Identifier 4299 This specification assigns the value 4, 'Diameter Credit Control', to 4300 the Application Identifier namespace defined in [RFC6733]. See 4301 Section 1.3 for more information. 4303 12.2. Command Codes 4305 This specification uses the value 272 from the Command code namespace 4306 defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit- 4307 Control-Answer (CCA) commands. 4309 12.3. AVP Codes 4311 See Section 8 for the assignment of the namespace in this 4312 specification. 4314 12.4. Result-Code AVP Values 4316 This specification assigns the values 4010, 4011, 4012, 5030, 5031 4317 from the Result-Code AVP value namespace defined in [RFC6733]. See 4318 Section 9 for the assignment of the namespace in this specification. 4320 12.5. CC-Request-Type AVP 4322 As defined in Section 8.3, the CC-Request-Type AVP includes 4323 Enumerated type values 1 - 4. IANA has created and is maintaining a 4324 namespace for this AVP. All remaining values are available for 4325 assignment by a Designated Expert [RFC8126], under the conditions for 4326 enumerated values described in [RFC7423] Section 5.6. 4328 12.6. CC-Session-Failover AVP 4330 As defined in Section 8.4, the CC-Failover-Supported AVP includes 4331 Enumerated type values 0 - 1. IANA has created and is maintaining a 4332 namespace for this AVP. All remaining values are available for 4333 assignment by a Designated Expert [RFC8126], under the conditions for 4334 enumerated values described in [RFC7423] Section 5.6. 4336 12.7. CC-Unit-Type AVP 4338 As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated 4339 type values 0 - 5. IANA has created and is maintaining a namespace 4340 for this AVP. All remaining values are available for assignment by a 4341 Designated Expert [RFC8126], under the conditions for enumerated 4342 values described in [RFC7423] Section 5.6. 4344 12.8. Check-Balance-Result AVP 4346 As defined in Section 8.6, the Check-Balance-Result AVP includes 4347 Enumerated type values 0 - 1. IANA has created and is maintaining a 4348 namespace for this AVP. All remaining values are available for 4349 assignment by a Designated Expert [RFC8126], under the conditions for 4350 enumerated values described in [RFC7423] Section 5.6. 4352 12.9. Credit-Control AVP 4354 As defined in Section 8.13, the Credit-Control AVP includes 4355 Enumerated type values 0 - 1. IANA has created and is maintaining a 4356 namespace for this AVP. All remaining values are available for 4357 assignment by a Designated Expert [RFC8126], under the conditions for 4358 enumerated values described in [RFC7423] Section 5.6. 4360 12.10. Credit-Control-Failure-Handling AVP 4362 As defined in Section 8.14, the Credit-Control-Failure-Handling AVP 4363 includes Enumerated type values 0 - 2. IANA has created and is 4364 maintaining a namespace for this AVP. All remaining values are 4365 available for assignment by a Designated Expert [RFC8126], under the 4366 conditions for enumerated values described in [RFC7423] Section 5.6. 4368 12.11. Direct-Debiting-Failure-Handling AVP 4370 As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP 4371 includes Enumerated type values 0 - 1. IANA has created and is 4372 maintaining a namespace for this AVP. All remaining values are 4373 available for assignment by a Designated Expert [RFC8126], under the 4374 conditions for enumerated values described in [RFC7423] Section 5.6. 4376 12.12. Final-Unit-Action AVP 4378 As defined in Section 8.35, the Final-Unit-Action AVP includes 4379 Enumerated type values 0 - 2. IANA has created and is maintaining a 4380 namespace for this AVP. All remaining values are available for 4381 assignment by a Designated Expert [RFC8126], under the conditions for 4382 enumerated values described in [RFC7423] Section 5.6. 4384 12.13. Multiple-Services-Indicator AVP 4386 As defined in Section 8.40, the Multiple-Services-Indicator AVP 4387 includes Enumerated type values 0 - 1. IANA has created and is 4388 maintaining a namespace for this AVP. All remaining values are 4389 available for assignment by a Designated Expert [RFC8126], under the 4390 conditions for enumerated values described in [RFC7423] Section 5.6. 4392 12.14. Redirect-Address-Type AVP 4394 As defined in Section 8.38, the Redirect-Address-Type AVP includes 4395 Enumerated type values 0 - 3. IANA has created and is maintaining a 4396 namespace for this AVP. All remaining values are available for 4397 assignment by a Designated Expert [RFC8126], under the conditions for 4398 enumerated values described in [RFC7423] Section 5.6. 4400 12.15. Requested-Action AVP 4402 As defined in Section 8.41, the Requested-Action AVP includes 4403 Enumerated type values 0 - 3. IANA has created and is maintaining a 4404 namespace for this AVP. All remaining values are available for 4405 assignment by a Designated Expert [RFC8126], under the conditions for 4406 enumerated values described in [RFC7423] Section 5.6. 4408 12.16. Subscription-Id-Type AVP 4410 As defined in Section 8.47, the Subscription-Id-Type AVP includes 4411 Enumerated type values 0 - 4. IANA has created and is maintaining a 4412 namespace for this AVP. All remaining values are available for 4413 assignment by a Designated Expert [RFC8126], under the conditions for 4414 enumerated values described in [RFC7423] Section 5.6. 4416 12.17. Tariff-Change-Usage AVP 4418 As defined in Section 8.27, the Tariff-Change-Usage AVP includes 4419 Enumerated type values 0 - 2. IANA has created and is maintaining a 4420 namespace for this AVP. All remaining values are available for 4421 assignment by a Designated Expert [RFC8126], under the conditions for 4422 enumerated values described in [RFC7423] Section 5.6. 4424 12.18. User-Equipment-Info-Type AVP 4426 As defined in Section 8.50, the User-Equipment-Info-Type AVP includes 4427 Enumerated type values 0 - 3. IANA has created and is maintaining a 4428 namespace for this AVP. All remaining values are available for 4429 assignment by a Designated Expert [RFC8126], under the conditions for 4430 enumerated values described in [RFC7423] Section 5.6. 4432 13. Credit-Control Application Related Parameters 4434 Tx timer 4436 When real-time credit-control is required, the credit-control client 4437 contacts the credit-control server before and while the service is 4438 provided to an end user. Due to the real-time nature of the 4439 application, the communication delays SHOULD be minimized; e.g., to 4440 avoid an overly long service setup time experienced by the end user. 4441 The Tx timer is introduced to control the waiting time in the client 4442 in the Pending state. When the Tx timer elapses, the credit-control 4443 client takes an action to the end user according to the value of the 4444 Credit-Control-Failure-Handling AVP 4446 or Direct-Debiting-Failure-Handling AVP. The recommended value is 10 4447 seconds. 4449 Tcc timer 4451 The Tcc timer supervises an ongoing credit-control session in the 4452 credit-control server. It is RECOMMENDED to use the Validity-Time as 4453 input to set the Tcc timer value. In case of transient failures in 4454 the network, the Diameter credit-control server might change to Idle 4455 state. To avoid this, the Tcc timer MAY be set so that Tcc equals to 4456 2 x Validity-Time. 4458 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 4460 Client implementations may offer the possibility of locally 4461 configuring these AVPs. In such a case their value and behavior is 4462 defined in Section 5.7 for the Credit-Control-Failure-Handling and in 4463 Section 6.5 for the Direct-Debiting-Failure-Handling. 4465 14. Security Considerations 4467 Security considerations regarding the Diameter protocol itself are 4468 discussed in [RFC6733]. Use of this application of Diameter MUST 4469 take into consideration the security issues and requirements of the 4470 base protocol. 4472 This application includes a mechanism for application layer replay 4473 protection by means of the Session-Id from [RFC6733] and CC-Request- 4474 Number, which is specified in this document. The Diameter credit- 4475 control application is often used within one domain, and there may be 4476 a single hop between the peers. In these environments, the use of 4477 TLS/TCP, DTLS/SCTP or IPsec is sufficient. The details of TLS/TCP, 4478 DTLS/SCTP or IPsec related security considerations are discussed in 4479 the [RFC6733]. 4481 Because this application handles monetary transactions (directly or 4482 indirectly), it increases the interest for various security attacks. 4483 Therefore, all parties communicating with each other MUST be 4484 authenticated, including, for instance, TLS client-side 4485 authentication. In addition, authorization of the client SHOULD be 4486 emphasized; i.e., that the client is allowed to perform credit- 4487 control for a certain user. The specific means of authorization are 4488 outside of the scope of this specification but can be, for instance, 4489 manual configuration. 4491 Another kind of threat is malicious modification, injection, or 4492 deletion of AVPs or complete credit-control messages. The credit- 4493 control messages contain sensitive billing related information (such 4494 as subscription Id, granted units, used units, cost information) 4495 whose malicious modification can have financial consequences. 4496 Sometimes simply delaying the credit-control messages can cause 4497 disturbances in the credit-control client or server. 4499 Even without any modification to the messages, an adversary can 4500 eavesdrop on transactions that contain privacy-sensitive information 4501 about the user. Also, by monitoring the credit-control messages one 4502 can collect information about the credit-control server's billing 4503 models and business relationships. 4505 When third-party relays or proxy are involved, the hop-by-hop 4506 security does not necessarily provide sufficient protection for 4507 Diameter user session. In some cases, it may be inappropriate to 4508 send Diameter messages, such as CCR and CCA, containing sensitive 4509 AVPs via untrusted Diameter proxy agents, as there are no assurances 4510 that third-party proxies will not modify the credit-control commands 4511 or AVP values. 4513 14.1. Direct Connection with Redirects 4515 A Diameter credit-control agent cannot always know whether agents 4516 between it and the end user's Diameter credit-control server are 4517 reliable. In this case, the Diameter credit-control agent doesn't 4518 have a routing entry in its Diameter Routing Table (defined in 4519 [RFC6733], section 2.7) for the realm of the credit-control server in 4520 the end user's home domain. The Diameter credit-control agent can 4521 have a default route configured to a local Redirect agent, and it 4522 redirects the CCR message to the redirect agent. The local Redirect 4523 agent then returns a redirect notification (Result-code 3006, 4524 DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as 4525 Diameter credit-control server(s) information (Redirect-Host AVP) and 4526 information (Redirect-Host-Usage AVP) about how the routing entry 4527 resulting from the Redirect-Host is to be used. The Diameter credit- 4528 control agent then forwards the CCR message directly to one of the 4529 hosts identified by the CCA message from the redirect agent. If the 4530 value of the Redirect-Host-Usage AVP is unequal to zero, all 4531 following messages are sent to the host specified in the Redirect- 4532 Host AVP until the time specified by the Redirect-Max-Cache-Time AVP 4533 is expired. 4535 There are some authorization issues even with redirects. There may 4536 be attacks toward nodes that have been properly authorized, but that 4537 abuse their authorization or have been compromised. These issues are 4538 discussed more widely in [RFC4072], Section 8. 4540 15. Privacy Considerations 4542 As the Diameter protocol, and especially credit-control application, 4543 deals with subscribers and their actions, extra care should be taken 4544 regarding the privacy of the subscribers. In terms of [RFC6973], 4545 both the credit-control client and credit-control server are 4546 intermediary entities, wherein the subscribers' privacy may be 4547 compromised even if no security issues exist, and only authorized 4548 entities have access to the privacy-sensitive information. 4550 15.1. Privacy Sensitive AVPs 4552 The following AVPs contain privacy-sensitive information at different 4553 levels: 4555 1. CC-Correlation-Id AVP: may contain privacy-sensitive information 4556 as the service-provider may encode personal information that 4557 helps it correlate different subscriptions and access 4558 technologies. 4560 2. Check-Balance-Result AVP: contains information on the balance 4561 status of the subscriber. 4563 3. Currency-Code AVP: contains information on the subscriber's 4564 locale. 4566 4. Cost-Unit AVP: contains privacy-sensitive information, as a 4567 human readable format of the Cost-Information AVP. 4569 5. Service-Identifier AVP: may contain privacy-sensitive 4570 information about the subscriber's internet activity. 4572 6. Rating-Group AVP: may contain privacy-sensitive information 4573 about the subscriber's internet activity. 4575 7. Restriction-Filter-Rule AVP: the information inside IPFilterRule 4576 may be used to infer services used by the subscriber. 4578 8. Redirect-Server-Address AVP: the service-provider may embed 4579 personal information on the subscriber in the URL/I (e.g. to 4580 create a personalized message). However, the service-provider 4581 may anonymise the subscriber's identity instead in the URL/I, 4582 and let the redirect server query the information directly. 4584 Similar AVPs are: Redirect-Address-URL, Redirect-Address-SIP- 4585 URI. 4587 9. Service-Context-Id AVP: depending with how the service-provider 4588 uses it, it may contain privacy-sensitive information about the 4589 service (e.g. in a 3GPP network Service-Context-Id AVP has a 4590 different value for: Packet Switching, SMS and MMS etc.) 4592 10. Service-Parameter-Info AVP: depending with how the service- 4593 provider uses it, it may contain privacy-sensitive information 4594 about the subscriber (e.g. location). 4596 11. Subscription-Id-Data AVP: contains the identity of the 4597 subscriber. Similar AVPs are: Subscription-Id-E164, 4598 Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id- 4599 NAI, Subscription-Id-Private. 4601 12. User-Equipment-Info-Value AVP: contains the identity of the 4602 device of the subscriber. Similar AVPs are: User-Equipment- 4603 Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, 4604 User-Equipment-Info-ModifiedEUI64, User-Equipment-Info-IMEI. 4606 13. QoS-Final-Unit-Indication AVP: grouped AVP which may contains 4607 privacy-sensitive information in its sub-AVPs (e.g IPFilterRule, 4608 redirect address). 4610 Note that some AVPs which are used in this document are defined in 4611 [RFC6733] and may contain privacy-sensitive information. These AVPs 4612 are not listed above. 4614 15.2. Data Minimization 4616 Due to the nature of the credit-control application, some personal 4617 data and identity information must be stored in both credit-control 4618 client and credit-control server. This, however, could be minimized 4619 by following these guidelines: 4621 1. Data stored in the credit-control client does not need to be 4622 persisted across sessions. All data could be deleted once the 4623 session end, and reconstructed once a new session is initialized. 4624 Note that, while the credit-control server is usually owned by 4625 the service provider with which the subscriber already has some 4626 direct legal or business relationship (where privacy level could 4627 be agreed upon), this is not always true for the credit-control 4628 client, that may be owned by a third-party. 4630 2. Some information about the subscriber has to be stored in 4631 persistent storage in the credit-control server (e.g. identity, 4632 balance), however, per transaction information does not have to 4633 be stored in persistent storage, and per session information may 4634 be deleted from persistent storage once the session ends. 4636 3. In some cases, per transaction information has to be stored on 4637 the credit-control server, client, or both, for regulatory, 4638 auditability or debugging reasons. However, this could be 4639 minimized by following these guidelines: 4641 A. Data retention does not need to exceed the required duration. 4643 B. Transaction information could be aggregated in some cases. 4644 E.g. prefer information per sessions over information per 4645 rating-group; prefer hourly byte summary over per transaction 4646 byte counts. 4648 C. If not strictly needed, the more sensitive information (E.g. 4649 location, equipment type) could be filtered out of such logs. 4650 This information is often used to make rating decisions, and 4651 in this case, the rating decision should be logged instead of 4652 the data used to make them. 4654 D. Due to the reasons explained in 1, the credit-control server 4655 would be a preferred location for storing such transaction 4656 information, instead of the credit-control client 4658 15.3. Diameter Agents 4660 Diameter agents, as described in [RFC6733], may be owned by third- 4661 parties. If end-to-end security is supported between credit-control 4662 client and credit-control server, the operator can use it to encrypt 4663 privacy-sensitive AVPs (as listed in Section 15.1), and prevent such 4664 information from leaking into the agent. 4666 In some cases, the Diameter agent needs access into privacy-sensitive 4667 AVPs, in order to take correct routing decisions, or even modify the 4668 content of these AVPs. For example, a proxy agent may need to look 4669 into the Subscription-Id-IMSI AVP, in order to extract the mobile 4670 country and network codes of the user, and use them to lookup the 4671 destination to which the request should be routed (see: section 2.8.2 4672 in [RFC6733]). In such a case, the credit-control client and credit- 4673 control server may use a mechanism that anonymizes the identity of 4674 the subscriber, as well as a mechanism to encrypt other AVPs not used 4675 by the agent. 4677 16. References 4679 16.1. Normative References 4681 [CE164] "Complement to ITU-T Recommendation E.164 (05/1997):"List 4682 of ITU-T Recommendation E.164 assigned country codes"", 4683 June 2000. 4685 [CE212] "Complement to ITU-T Recommendation E.212 (11/1997):" List 4686 of mobile country or geographical area codes"", February 4687 1999. 4689 [E164] "Recommendation E.164/I.331 (05/97): The International 4690 Public Telecommunication Numbering Plan.", 1997. 4692 [E212] "Recommendation E.212 (11/98): The international 4693 identification plan for mobile terminals and mobile 4694 users.", 1998. 4696 [EUI64] IEEE, ""Guidelines for 64-bit Global Identifier (EUI-64) 4697 Registration Authority"", March 1997, 4698 . 4701 [ISO4217] "Codes for the representation of currencies and funds, 4702 International Standard ISO 4217", 2001. 4704 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4705 DOI 10.17487/RFC0791, September 1981, 4706 . 4708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4709 Requirement Levels", BCP 14, RFC 2119, 4710 DOI 10.17487/RFC2119, March 1997, 4711 . 4713 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4714 A., Peterson, J., Sparks, R., Handley, M., and E. 4715 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4716 DOI 10.17487/RFC3261, June 2002, 4717 . 4719 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 4720 Accounting (AAA) Transport Profile", RFC 3539, 4721 DOI 10.17487/RFC3539, June 2003, 4722 . 4724 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 4725 Resource Identifier (URI): Generic Syntax", STD 66, 4726 RFC 3986, DOI 10.17487/RFC3986, January 2005, 4727 . 4729 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 4730 Loughney, "Diameter Credit-Control Application", RFC 4006, 4731 DOI 10.17487/RFC4006, August 2005, 4732 . 4734 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4735 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4736 2006, . 4738 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 4739 Ed., and A. Lior, "Traffic Classification and Quality of 4740 Service (QoS) Attributes for Diameter", RFC 5777, 4741 DOI 10.17487/RFC5777, February 2010, 4742 . 4744 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 4745 Address Text Representation", RFC 5952, 4746 DOI 10.17487/RFC5952, August 2010, 4747 . 4749 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 4750 Ed., "Diameter Base Protocol", RFC 6733, 4751 DOI 10.17487/RFC6733, October 2012, 4752 . 4754 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 4755 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 4756 . 4758 [RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter 4759 Applications Design Guidelines", BCP 193, RFC 7423, 4760 DOI 10.17487/RFC7423, November 2014, 4761 . 4763 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 4764 DOI 10.17487/RFC7542, May 2015, 4765 . 4767 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4768 Writing an IANA Considerations Section in RFCs", BCP 26, 4769 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4770 . 4772 [TGPPIMEI] 4773 3rd Generation Partnership Project, "Technical 4774 Specification Group Core Network, Numbering, addressing 4775 and identification, (release 13), 3GPP TS 23.003 v. 4776 13.5.0", 2016-04. 4778 16.2. Informative References 4780 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 4781 DOI 10.17487/RFC2866, June 2000, 4782 . 4784 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 4785 "IEEE 802.1X Remote Authentication Dial In User Service 4786 (RADIUS) Usage Guidelines", RFC 3580, 4787 DOI 10.17487/RFC3580, September 2003, 4788 . 4790 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 4791 Camarillo, "Best Current Practices for Third Party Call 4792 Control (3pcc) in the Session Initiation Protocol (SIP)", 4793 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 4794 . 4796 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., 4797 and P. McCann, "Diameter Mobile IPv4 Application", 4798 RFC 4004, DOI 10.17487/RFC4004, August 2005, 4799 . 4801 [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter 4802 Extensible Authentication Protocol (EAP) Application", 4803 RFC 4072, DOI 10.17487/RFC4072, August 2005, 4804 . 4806 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 4807 Morris, J., Hansen, M., and R. Smith, "Privacy 4808 Considerations for Internet Protocols", RFC 6973, 4809 DOI 10.17487/RFC6973, July 2013, 4810 . 4812 [TGPPCHARG] 4813 3rd Generation Partnership Project, "Technical 4814 Specification Group Services and System Aspects, Service 4815 aspects; Charging and Billing, (release 13), 3GPP TS 4816 22.115 v. 13.3.0", 2016-03. 4818 Appendix A. Acknowledgements 4820 The original authors of RFC4006 are: Harri Hakala, Leena Mattila, 4821 Juha-Pekka Koskinen, Marco Stura, and John Loughney. 4823 The authors would like to thank Bernard Aboba, Jari Arkko, Robert 4824 Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, 4825 Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, 4826 Christopher Richards, Juha Vallinen, and Mark Watson for their 4827 comments and suggestions. 4829 Appendix B. Credit-Control Sequences 4831 B.1. Flow I 4832 NAS 4833 End User (CC Client) AAA Server CC Server 4834 |(1)User Logon |(2)AA Request (CC AVPs) | 4835 |------------------>|------------------->| | 4836 | | |(3)CCR(initial, CC AVPs) 4837 | | |------------------->| 4838 | | | (4)CCA(Granted-Units) 4839 | | |<-------------------| 4840 | |(5)AA Answer(Granted-Units) | 4841 |(6)Access granted |<-------------------| | 4842 |<----------------->| | | 4843 | | | | 4844 : : : : 4845 | |(7)CCR(update,Used-Units) | 4846 | |------------------->|(8)CCR | 4847 | | | (update,Used-Units) 4848 | | |------------------->| 4849 | | |(9)CCA(Granted-Units) 4850 | |(10)CCA(Granted-Units)<------------------| 4851 | |<-------------------| | 4852 : : : : 4853 | (Auth. lifetime expires) | | 4854 | |(11) AAR (CC AVP) | | 4855 | |------------------->| | 4856 | | (12) AAA | | 4857 | |<-------------------| | 4858 : : : : 4859 : : : : 4860 |(13) User logoff | | | 4861 |------------------>|(14)CCR(term.,Used-Units) | 4862 | |------------------->|(15)CCR | 4863 | | | (term.,Used-Units) 4864 | | |------------------->| 4865 | | | (16)CCA | 4866 | | (17)CCA |<-------------------| 4867 | |<-------------------| | 4868 | |(18)STR | | 4869 | |------------------->| | 4870 | | (19)STA | | 4871 | |<-------------------| | 4873 Figure 11: Flow I 4875 A credit-control flow for Network Access Services prepaid is shown in 4876 Figure 11. The Diameter [RFC7155] is implemented in the Network 4877 Access Server (NAS). The focus of this flow is in the credit 4878 authorization. 4880 The user logs on to the network (1). The Diameter NAS sends a 4881 Diameter AA-Request (AAR) to the home Diameter AAA server. The 4882 credit-control client populates the AAR with the Credit-Control AVP 4883 set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, 4884 as usual [RFC7155]. The home Diameter AAA server performs service- 4885 specific Authentication and Authorization, as usual. The home 4886 Diameter AAA server determines that the user is a prepaid user and 4887 notices from the Credit-Control AVP that the NAS has credit-control 4888 capabilities. It sends a Diameter Credit-Control-Request with CC- 4889 Request-Type set to INITIAL_REQUEST to the Diameter credit-control 4890 server to perform credit authorization (3) and to establish a credit- 4891 control session. (The home Diameter AAA server may forward service- 4892 specific AVPs received from the NAS as input for the rating process.) 4893 The Diameter credit-control server checks the end user's account 4894 balance, rates the service, and reserves credit from the end user's 4895 account. The reserved quota is returned to the home Diameter AAA 4896 server in the Diameter Credit-Control-Answer (4). The home Diameter 4897 AAA server sends the reserved quota to the NAS in the Diameter AA- 4898 Answer (AAA). Upon successful AAA, the NAS starts the credit-control 4899 session and starts monitoring the granted units (5). The NAS grants 4900 access to the end user (6). At the expiry of the allocated quota, 4901 the NAS sends a Diameter Credit-Control-Request with CC-Request-Type 4902 set to UPDATE_REQUEST to the Home Diameter AAA server (7). This 4903 message contains the units used thus far. The home Diameter AAA 4904 server forwards the CCR to the Diameter credit-control server (8). 4905 The Diameter credit-control server debits the used units from the end 4906 user's account and allocates a new quota that is returned to the home 4907 Diameter AAA server in the Diameter Credit-Control-Answer (9). The 4908 message is forwarded to the NAS (10). During the ongoing credit- 4909 control session, the authorization lifetime expires, and the 4910 authorization/authentication client in the NAS performs service 4911 specific re-authorization to the home Diameter AAA server, as usual. 4912 The credit-control client populates the AAR with the Credit-Control 4913 AVP set to RE_AUTHORIZATION, indicating that the credit-control 4914 server shall not be contacted, as the credit authorization is 4915 controlled by the burning rate of the granted units (11). The home 4916 Diameter AAA server performs service-specific re-authorization as 4917 usual and returns the AA-Answer to the NAS (12). The end user logs 4918 off from the network (13). To debit the used units from the end 4919 user's account and to stop the credit-control session, the NAS sends 4920 a Diameter Credit-Control-Request with CC-Request-Type set to 4921 TERMINATION_REQUEST to the home Diameter AAA server (14). The home 4922 Diameter AAA server forwards the CCR to the credit-control server 4923 (15). The Diameter credit-control server acknowledges the session 4924 termination by sending a Diameter Credit-Control-Answer to the home 4925 Diameter AAA server (16). The home Diameter AAA server forwards the 4926 answer to the NAS (17). STR/STA takes place between the NAS and home 4927 Diameter AAA server, as usual (18-19). 4929 B.2. Flow II 4931 SIP Proxy/Registrar AAA 4932 A (CC Client) Server B CC Server 4933 |(i) REGISTER | | | | 4934 |------------->|(ii) | | | 4935 | |------------->| | | 4936 | |authentication & | | 4937 | |authorization | | | 4938 | |<-------------| | | 4939 |(iii)200 OK | | | 4940 |<-------------| | | 4941 : : : : 4942 |(1) INVITE | : 4943 |------------->| 4944 | |(2) CCR (Initial, SIP specific AVP) | 4945 | |------------------------------------------->| 4946 | |(3) CCA (Granted-Units) | 4947 | |<-------------------------------------------| 4948 | |(4) INVITE | | 4949 | |---------------------------->| | 4950 : : : : 4951 | |(5) CCR (update, Used-Units) | 4952 | |------------------------------------------->| 4953 | |(6) CCA (Granted-Units) | 4954 | |<-------------------------------------------| 4955 : : : : 4956 |(7) BYE | | | 4957 |------------->| | | 4958 | |(8) BYE | | 4959 | |---------------------------->| | 4960 | |(9) CCR (termination, Used-Units) | 4961 | |------------------------------------------->| 4962 | |(10) CCA () | 4963 | |<-------------------------------------------| 4964 | | | | 4966 Figure 12: Flow II 4968 This is an example of Diameter credit-control for SIP sessions. 4969 Although the flow focuses on illustrating the usage of credit-control 4970 messages, the SIP signaling is inaccurate, and the diagram is not by 4971 any means an attempt to define a service provider's SIP network. 4972 However, for the sake of this example, some assumptions are made 4973 below. 4975 Typically, prepaid services based, for example, on time usage for SIP 4976 session require an entity in the service provider network to 4977 intercept all the requests within the SIP dialog in order to detect 4978 events, such as session establishment and session release, that are 4979 essential to perform credit-control operations with the credit- 4980 control server. Therefore, in this example, it is assumed that the 4981 SIP Proxy adds a Record-Route header in the initial SIP INVITE to 4982 make sure that all the future requests in the created dialog traverse 4983 through it (for the definitions of 'Record-Route' and 'dialog' please 4984 refer to [RFC3261]). Finally, the degree of credit-control measuring 4985 of the media by the proxy depends on the business model design used 4986 in setting up the end system and proxies in the SIP network. 4988 The end user (SIP User Agent A) sends REGISTER with credentials (i). 4989 The SIP Proxy sends a request to the home AAA server to perform 4990 Multimedia authentication and authorization by using, for instance, 4991 Diameter Multimedia application (ii). The home AAA server checks 4992 that the credentials are correct and checks the user profile. 4993 Eventually, 200 OK response (iii) is sent to the UA. Note that the 4994 Authentication and Authorization is valid for the registration 4995 validity period duration (i.e., until re-registration is performed). 4996 Several SIP sessions may be established without re-authorization. 4998 UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- 4999 Control-Request (INITIAL_REQUEST) to the Diameter credit-control 5000 server (2). The Credit-Control-Request contains information obtained 5001 from the SIP signaling describing the requested service (e.g., 5002 calling party, called party, Session Description Protocol 5003 attributes). The Diameter credit-control server checks the end 5004 user's account balance, rates the service, and reserves credit from 5005 the end user's account. The reserved quota is returned to the SIP 5006 Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy 5007 forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. 5008 The media flows between them, and the SIP Proxy starts measuring the 5009 quota. At the expiry of the allocated quota, the SIP Proxy sends a 5010 Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 5011 credit-control server (5). This message contains the units used thus 5012 far. The Diameter credit-control server debits the used units from 5013 the end user's account and allocates new credit that is returned to 5014 the SIP Proxy in the Diameter Credit-Control-Answer (6). The end 5015 user terminates the service by sending a BYE (7). The SIP Proxy 5016 forwards the BYE message to UA B (8) and sends a Diameter Credit- 5017 Control-Request (TERMINATION_REQUEST) to the credit-control server 5018 (9). The Diameter credit-control server acknowledges the session 5019 termination by sending a Diameter Credit-Control-Answer to the SIP 5020 Proxy (10). 5022 B.3. Flow III 5024 MMS Server 5025 A (CC Client) B CC Server 5026 |(1) Send MMS | | | 5027 |--------------->| | | 5028 | |(2) CCR (event, DIRECT_DEBITING,| 5029 | | MMS specific AVP) | 5030 | |-------------------------------->| 5031 | |(3) CCA (Granted-Units) | 5032 | |<--------------------------------| 5033 |(4) Send MMS Ack| | | 5034 |<---------------| | | 5035 | |(5) Notify MMS | | 5036 | |--------------->| | 5037 : : : : 5038 | |(6) Retrieve MMS| | 5039 | |<---------------| | 5040 | |(7) Retrieve MMS| | 5041 | | Ack | | 5042 | |--------------->| | 5043 | | | | 5045 Figure 13: Flow III 5047 A credit-control flow for Multimedia Messaging Services is shown in 5048 Figure 13. The sender is charged as soon as the messaging server 5049 successfully stores the message. 5051 The end user A sends a Multimedia Message (MMS) to the MMS server 5052 (1). The MMS server stores the message and sends a Diameter Credit- 5053 Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) 5054 to the Diameter credit-control server (2). The Credit-Control- 5055 Request contains information about the MMS message (e.g., size, 5056 recipient address, image coding type). The Diameter credit-control 5057 server checks the end user's account balance, rates the service, and 5058 debits the service from the end user's account. The granted quota is 5059 returned to the MMS server in the Diameter Credit-Control-Answer (3). 5060 The MMS server acknowledges the successful reception of the MMS 5061 message (4). The MMS Server notifies the recipient about the new MMS 5062 (5), and end user B retrieves the message from the MMS message store 5063 (6),(7). 5065 B.4. Flow IV 5066 MMS Server 5067 Content Server (CC Client) B CC Server 5068 |(1) Send MMS | | | 5069 |--------------->| | | 5070 | |(2) CCR (event, CHECK_BALANCE, | 5071 | | MMS specific AVP) | 5072 | |-------------------------------->| 5073 | |(3) CCA (ENOUGH_CREDIT) | 5074 | |<--------------------------------| 5075 |(4) Send MMS Ack| | | 5076 |<---------------| | | 5077 | |(5) Notify MMS | | 5078 | |--------------->| | 5079 : : : : 5080 | |(6) Retrieve MMS| | 5081 | |<---------------| | 5082 | |(7) CCR (event, DIRECT_DEBITING,| 5083 | | MMS specific AVP) | 5084 | |-------------------------------->| 5085 | |(8) CCA (Granted-Units) | 5086 | |<--------------------------------| 5087 | |(9) Retrieve MMS| | 5088 | | Ack | | 5089 | |--------------->| | 5090 | | | | 5092 Figure 14: Flow IV 5094 This is an example of Diameter credit-control for direct debiting 5095 using the Multimedia Messaging Service environment. Although the 5096 flow focuses on illustrating the usage of credit-control messages, 5097 the MMS signaling is inaccurate, and the diagram is not by any means 5098 an attempt to define any service provider's MMS configuration or 5099 billing model. 5101 A credit-control flow for Multimedia Messaging Service is shown in 5102 Figure 14. The recipient is charged at the message delivery. 5104 A content server sends a Multimedia Message (MMS) to the MMS server 5105 (1) that stores the message. The message recipient will be charged 5106 for the MMS message in this case. As there can be a substantially 5107 long time between the receipt of the message at the MMS server and 5108 the actual retrieval of the message, the MMS server does not 5109 establish any credit-control session to the Diameter credit-control 5110 server but performs first only a balance check (without any credit 5111 reservation) by sending a Diameter Credit-Control-Request 5112 (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that 5113 end user B can cover the cost for the MMS (2). The Diameter credit- 5114 control server checks the end user's account balance and returns the 5115 answer to the MMS server in the Diameter Credit-Control-Answer (3). 5116 The MMS server acknowledges the successful reception of the MMS 5117 message (4). The MMS server notifies the recipient of the new MMS 5118 (5), and after some time end user B retrieves the message from the 5119 MMS message store (6). The MMS server sends a Diameter Credit- 5120 Control-Request (EVENT_REQUEST with Requested-Action: 5121 DIRECT_DEBITING) to the Diameter credit-control server (7). The 5122 Credit-Control-Request contains information about the MMS message 5123 (e.g., size, recipient address, coding type). The Diameter credit- 5124 control server checks the end user's account balance, rates the 5125 service, and debits the service from the end user's account. The 5126 granted quota is returned to the MMS server in the Diameter Credit- 5127 Control-Request (8). The MMS is transferred to end user B (9). 5129 Note that the transfer of the MMS message can take an extended time 5130 and can fail, in which case a recovery action is needed. The MMS 5131 server should return the already debited units to the user's account 5132 by using the REFUND action described in Section 6.4. 5134 B.5. Flow V 5136 SIP Controller 5137 A (CC Client) B CC Server 5138 |(1)INVITE B(SDP)| | | 5139 |--------------->| | | 5140 | |(2) CCR (event, PRICE_ENQUIRY, | 5141 | | SIP specific AVPs) | 5142 | |-------------------------------->| 5143 | |(3) CCA (Cost-Information) | 5144 | |<--------------------------------| 5145 | (4)MESSAGE(URL)| | | 5146 |<---------------| | | 5147 |(5)HTTP GET | | | 5148 |--------------->| | | 5149 |(6)HTTP POST | | | 5150 |--------------->|(7)INVITE(SDP) | | 5151 | |--------------->| | 5152 | | (8)200 OK | | 5153 | (9)200 OK |<---------------| | 5154 |<---------------| | | 5156 Figure 15: Flow V 5158 This is an example of Diameter credit-control for SIP sessions. 5159 Although the flow focuses on illustrating the usage of credit-control 5160 messages, the SIP signaling is inaccurate, and the diagram is not by 5161 any means an attempt to define a service provider's SIP network. 5163 Figure 15 is an example of Advice of Charge (AoC) service for SIP 5164 call. User A can be either a postpaid or prepaid subscriber using 5165 the AoC service. It is assumed that the SIP controller also has HTTP 5166 capabilities and delivers an interactive AoC web page with, for 5167 instance, the cost information, the details of the call derived from 5168 the SDP, and a button to accept/not accept the charges. (There may 5169 be many other ways to deliver AoC information; however, this flow 5170 focuses on the use of the credit-control messages.) The user has 5171 been authenticated and authorized prior to initiating the call and 5172 subscribed to AoC service. 5174 UA A sends an INVITE with SDP to B (1). The SIP controller 5175 determines that the user is subscribed to AoC service and sends a 5176 Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: 5177 PRICE_ENQUIRY) to the Diameter credit-control server (2). The 5178 Credit-Control-Request contains SIP specific AVPs derived from the 5179 SIP signaling, describing the requested service (e.g., calling party, 5180 called party, Session Description Protocol attributes). The Diameter 5181 credit-control server determines the cost of the service and returns 5182 the Credit-Control-Answer including the Cost-Information AVP (3). 5183 The SIP controller manufactures the AoC web page with information 5184 received in SIP signaling and with the cost information received from 5185 the credit-control server. Then it sends a SIP MESSAGE that contains 5186 a URL pointing to the AoC information web page (4). At the receipt 5187 of the SIP MESSAGE, A's UA automatically invokes the web browser that 5188 retrieves the AoC information (5). The user clicks on a proper 5189 button and accepts the charges (6). The SIP controller continues the 5190 session and sends the INVITE to the B party, which accepts the call 5191 (7,8,9). 5193 B.6. Flow VI 5195 Gaming Server 5196 End User (CC Client) CC Server 5197 | (1)Service Delivery | | 5198 |<---------------------->| | 5199 : : : 5200 : : : 5201 | |(2)CCR(event,REFUND,Requested- 5202 | |Service-Unit,Service-Parameter-Info) 5203 | |----------------------->| 5204 | | (3)CCA(Cost-Information) 5205 | |<-----------------------| 5206 | (4)Notification | | 5207 |<-----------------------| | 5209 Figure 16: Flow VI 5211 Figure 16 illustrates a credit-control flow for the REFUND case. It 5212 is assumed that there is a trusted relationship and secure connection 5213 between the Gaming server and the Diameter credit-control server. 5214 The end user may be a prepaid subscriber or a postpaid subscriber. 5216 While the end user is playing the game (1), she enters a new level 5217 that entitles her to a bonus. The Gaming server sends a Diameter 5218 Credit-Control-Request (EVENT_REQUEST with Requested-Action: 5219 REFUND_ACCOUNT) to the Diameter credit-control server (2). The 5220 Credit-Control-Request Request contains the Requested-Service-Unit 5221 AVP with the CC-Service-Specific-Units containing the number of 5222 points the user just won. The Service-Parameter-Info AVP is also 5223 included in the request and specifies the service event to be rated 5224 (e.g., Tetris Bonus). From information received, the Diameter 5225 credit-control server determines the amount to be credited, refunds 5226 the user's account, and returns the Credit-Control-Answer, including 5227 the Cost-Information AVP (3). The Cost-Information indicates the 5228 credited amount. At the first opportunity, the Gaming server 5229 notifies the end user of the credited amount (4). 5231 B.7. Flow VII 5232 SIP Controller Top-Up 5233 A (CC Client) Server B CC Server 5234 | | | | | 5235 | | (1) CCR(Update,Used-Unit) | | 5236 | |------------------------------------------>| 5237 | | (2) CCA(Final-Unit, Redirect)| 5238 | |<------------------------------------------| 5239 : : : : : 5240 : : : : : 5241 | | (3) CCR(Update, Used-Units)| | 5242 | |------------------------------------------>| 5243 | | (3a)INVITE("hold") | | 5244 | |--------------------------->| | 5245 | | | (4) CCA(Validity-Time)| 5246 | |<------------------------------------------| 5247 | (5)INVITE | (6)INVITE | | | 5248 |<--------------|------------->| | | 5249 | (7)RTP | | | 5250 |..............................| | | 5251 | | (8)BYE | | | 5252 | |<-------------| | | 5253 | | (9)CCR(Update) | | 5254 | |------------------------------------------>| 5255 | | (10)CCA(Granted-Unit) | 5256 | |<------------------------------------------| 5257 | (12)INVITE | (11)INVITE | | 5258 |<--------------|--------------------------->| | 5260 Figure 17: Flow VII 5262 Figure 17 is an example of the graceful service termination for a SIP 5263 call. It is assumed that the call is set up so that the controller 5264 is in the call as a B2BUA (Back to Back User Agent) performing third- 5265 party call control (3PCC). Note that the SIP signaling is 5266 inaccurate, as the focus of this flow is in the graceful service 5267 termination and credit-control authorization. The best practice for 5268 3PCC is defined in [RFC3725]. 5270 The call is ongoing between users A and B; user A has a prepaid 5271 subscription. At the expiry of the allocated quota, the SIP 5272 controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) 5273 to the Diameter credit-control server (1). This message contains the 5274 units used thus far. The Diameter credit-control server debits the 5275 used units from the end user's account and allocates the final quota 5276 returned to the SIP controller in the Diameter Credit-Control-Answer 5277 (2). This message contains the Final-Unit-Indication AVP with the 5278 Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to 5279 SIP URI, and the Redirect-Server-Address set to the Top-up server 5280 name (e.g., sip:sip-topup-server@domain.com). At the expiry of the 5281 final allocated quota, the SIP controller sends a Diameter Credit- 5282 Control-Request (UPDATE_REQUEST) to the Diameter credit-control 5283 server (3) and places the called party on "hold" by sending an INVITE 5284 with the appropriate connection address in the SDP (3a). The Credit- 5285 Control-Request message contains the units used thus far. The 5286 Diameter credit-control server debits the used units from the end 5287 user's account but does not make any credit reservation. The Credit- 5288 Control-Answer message, which contains the Validity-Time to supervise 5289 the graceful service termination, is returned to the SIP controller 5290 (4). The SIP controller establishes a SIP session between the 5291 prepaid user and the Top-up server (5, 6). The Top-up server plays 5292 an announcement and prompts the user to enter a credit card number 5293 and the amount of money to be used to replenish the account (7). The 5294 Top-up server validates the credit card number and replenishes the 5295 user's account (using some means outside the scope of this 5296 specification) and releases the SIP session (8). The SIP controller 5297 can now assume that communication between the prepaid user and the 5298 Top-up server took place. It sends a spontaneous Credit-Control- 5299 Request (UPDATE_REQUEST) to the Diameter credit-control server to 5300 check whether the account has been replenished (9). The Diameter 5301 credit-control server reserves credit from the end user's account and 5302 returns the reserved quota to the SIP controller in the Credit- 5303 Control-Answer (10). At this point, the SIP controller re-connects 5304 the caller and the called party (11,12). 5306 B.8. Flow VIII 5307 NAS Top-up CC 5308 End-User (CC Client) AAA Server Server Server 5309 |(1)User Logon |(2)AA Request (CC AVPs) | | 5310 |------------------>|------------------->| | | 5311 | | |(3)CCR(initial, CC AVPs) 5312 | | |------------------->| 5313 | | |(4)CCA(Final-Unit, | 5314 | | | Validity-Time)| 5315 | | |<-------------------| 5316 | |(5)AA Answer(Final-Unit,Validity-Time) | 5317 |(6)Limited Access |<-------------------| | | 5318 | granted | | | | 5319 |<----------------->| | | | 5320 | | | | | 5321 | (7)TCP/HTTP | (8)TCP/HTTP | | 5322 |<----------------->|<----------------------------->| | 5323 | (9) Replenish account | | 5324 |<------------------------------------------------->| | 5325 | | | (10)RAR | 5326 | |<-------------------|<-------------------| 5327 | | (11) RAA | | 5328 | |------------------->|------------------->| 5329 | |(12)CCR(update) | | 5330 | |------------------->|(13)CCR(Update) | 5331 | | |------------------->| 5332 | | |(14)CCA(Granted-Units) 5333 | |(15)CCA(Granted-Units)<------------------| 5334 | |<-------------------| | 5336 Figure 18: Flow VIII 5338 Figure 18 is an example of the graceful service termination initiated 5339 when the first interrogation takes place because the user's account 5340 is empty. In this example, the credit-control server supports the 5341 server-initiated credit re-authorization. The Diameter [RFC7155] is 5342 implemented in the Network Access Server (NAS). 5344 The user logs on to the network (1). The Diameter NAS sends a 5345 Diameter AA-Request to the home Diameter AAA server. The credit- 5346 control client populates the AAR with the Credit-Control AVP set to 5347 CREDIT_AUTHORIZATION, and service specific AVPs are included, as 5348 usual [RFC7155]. The home Diameter AAA server performs service 5349 specific Authentication and Authorization, as usual. The home 5350 Diameter AAA server determines that the user has a prepaid 5351 subscription and notices from the Credit-Control AVP that the NAS has 5352 credit-control capabilities. It sends a Diameter Credit-Control- 5353 Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter 5354 credit-control server to perform credit authorization (3) and to 5355 establish a credit-control session. (The home Diameter AAA server 5356 may forward service specific AVPs received from the NAS as input for 5357 the rating process.) The Diameter credit-control server checks the 5358 end user's account balance, determines that the account cannot cover 5359 the cost of the service, and initiates the graceful service 5360 termination. The Credit-Control-Answer is returned to the home 5361 Diameter AAA server (4). This message contains the Final-Unit- 5362 Indication AVP and the Validity-Time AVP set to a reasonable amount 5363 of time to give the user a chance to replenish his/her account (e.g., 5364 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- 5365 Action set to REDIRECT, the Redirect-Address-Type set to URL, and the 5366 Redirect-Server-Address set to the HTTP Top-up server name. The home 5367 Diameter AAA server sends the received credit-control AVPs to the NAS 5368 in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts 5369 the credit-control session and immediately starts the graceful 5370 service termination, as instructed by the server. The NAS grants 5371 limited access to the user (6). The HTTP client software running in 5372 the user's device opens the transport connection redirected by the 5373 NAS to the Top-up server (7,8). The user is displayed an appropriate 5374 web page on which to enter the credit card number, and the amount of 5375 money to be used to replenish the account, and with a notification 5376 message that she is granted unlimited access if the replenishment 5377 operation will be successfully executed within the next, for example, 5378 10 minutes. The Top-up server validates the credit card number and 5379 replenishes the user's account (using some means outside the scope of 5380 this specification)(9). After successful account top-up, the credit- 5381 control server sends a Re-Auth-Request message to the NAS (10). The 5382 NAS acknowledges the request by returning the Re-Auth-Answer message 5383 (11) and initiates the credit re-authorization by sending a Credit- 5384 Control-request (UPDATE_REQUEST) to the Diameter credit-control 5385 server (12,13). 5387 The Diameter credit-control server reserves credit from the end 5388 user's account and returns the reserved quota to the NAS via the home 5389 Diameter AAA server in the Credit-Control-Answer (14,15). The NAS 5390 removes the restriction placed by the graceful service termination 5391 and starts monitoring the granted units. 5393 B.9. Flow IX 5395 The Diameter credit-control application defines the Multiple- 5396 Services-Credit-Control AVP that can be used to support independent 5397 credit-control of multiple services in a single credit-control (sub-) 5398 session for service elements that have such capabilities. It is 5399 possible to request and allocate resources as a credit pool that is 5400 shared between services or rating groups. 5402 The flow example hereafter illustrates a usage scenario where the 5403 credit-control client and server support independent credit-control 5404 of multiple services, as defined in Section 5.1.2. It is assumed 5405 that Service-Identifiers, Rating-Groups, and their associated 5406 parameters (e.g., IP 5-tuple) are locally configured in the service 5407 element or provisioned by an entity other than the credit-control 5408 server. 5410 End User Service Element CC Server 5411 (CC client) 5412 |(1)User logon | | 5413 |------------------>|(2)CCR(initial, Service-Id access, | 5414 | | Access specific AVPs, | 5415 | | Multiple-Service-Indicator) | 5416 | |---------------------------------------->| 5417 | |(3)CCA(Multiple-Services-CC ( | 5418 | | Granted-Units(Total-Octets), | 5419 | | Service-Id access, | 5420 | | Validity-time, | 5421 | | G-S-U-Pool-Reference(Pool-Id 1, | 5422 | | Multiplier 10))) | 5423 | |<----------------------------------------| 5424 : : : 5425 |(4)Service-Request (Service 1) | 5426 |------------------>|(5)CCR(update, Multiple-Services-CC( | 5427 | | Requested-Units(), Service-Id 1, | 5428 | | Rating-Group 1)) | 5429 | |---------------------------------------->| 5430 | |(6)CCA(Multiple-Services-CC ( | 5431 | | Granted-Units(Time), | 5432 | | Rating-Group 1, | 5433 | | G-S-U-Pool-Reference(Pool-Id 1, | 5434 | | Multiplier 1))) | 5435 | |<----------------------------------------| 5436 : : : 5437 |(7)Service-Request (Service 2) | 5438 |------------------>| | 5439 : : : 5440 : : : 5441 |(8)Service-Request (Service 3&4) | 5442 |------------------>|(9)CCR(update, Multiple-Services-CC ( | 5443 | | Requested-Units(), Service-Id 3, | 5444 | | Rating-Group 2), | 5445 | | Multiple-Services-CC ( | 5446 | | Requested-Units(), Service-Id 4, | 5447 | | Rating-Group 3)) | 5448 | |---------------------------------------->| 5449 | |(10)CCA(Multiple-Services-CC ( | 5450 | | Granted-Units(Total-Octets), | 5451 | | Service-Id 3, Rating-Group 2, | 5452 | | Validity-time, | 5453 | | G-S-U-Pool-Reference(Pool-Id 2, | 5454 | | Multiplier 2)), | 5455 | | Multiple-Services-CC ( | 5456 | | Granted-Units(Total-Octets), | 5457 | | Service-Id 4, Rating-Group 3 | 5458 | | Validity-Time, | 5459 | | Final-Unit-Ind.(Terminate), | 5460 | | G-S-U-Pool-Reference(Pool-Id 2, | 5461 | | Multiplier 5))) | 5462 | |<----------------------------------------| 5463 : : : 5464 : : : 5465 | +--------------+ | | 5466 | |Validity time | |(11)CCR(update, | 5467 | |expires for | | Multiple-Services-CC ( | 5468 | |Service-Id | | Requested-Unit(), | 5469 | | access | | Used-Units(In-Octets,Out-Octets),| 5470 | +--------------+ | Service-Id access)) | 5471 | |---------------------------------------->| 5472 | |(12)CCA(Multiple-Services-CC ( | 5473 | | Granted-Units(Total-Octets), | 5474 | | Service-Id access, | 5475 | | Validity-Time, | 5476 | | G-S-U-Pool-Reference(Pool-Id 1, | 5477 | | Multiplier 10))) | 5478 | |<----------------------------------------| 5479 : : : 5480 : : : 5481 | +--------------+ | | 5482 | |Total Quota | |(13)CCR(update, | 5483 | |elapses for | | Multiple-Services-CC ( | 5484 | |pool 2: | | Requested-Unit(), | 5485 | |service 4 not | | Used-Units(In-Octets,Out-Octets),| 5486 | |allowed, | | Service-Id 3, Rating-group 2), | 5487 | |service 3 cont| | Multiple-Services-CC ( | 5488 | +--------------+ | Used-Units(In-Octets,Out-Octets),| 5489 | | Service-Id 4, Rating-Group 3)) | 5490 | |---------------------------------------->| 5491 | |(14)CCA(Multiple-Services-CC ( | 5492 | | Result-Code 4011, | 5493 | | Service-Id 3)) | 5494 | |<----------------------------------------| 5495 : : : 5496 : : : 5497 |(15) User logoff | | 5498 |------------------>|(16)CCR(term, | 5499 | | Multiple-Services-CC ( | 5500 | | Used-Units(In-Octets,Out-Octets),| 5501 | | Service-Id access), | 5502 | | Multiple-Services-CC ( | 5503 | | Used-Units(Time), | 5504 | | Service-Id 1, Rating-Group 1), | 5505 | | Multiple-Services-CC ( | 5506 | | Used-Units(Time), | 5507 | | Service-Id 2, Rating-Group 1)) | 5508 | |---------------------------------------->| 5509 | |(17)CCA(term) | 5510 | |<----------------------------------------| 5512 Figure 19: Flow example independent credit-control of multiple 5513 services in a credit-control (sub-)Session 5515 The user logs on to the network (1). The service element sends a 5516 Diameter Credit-Control-Request with CC-Request-Type set to 5517 INITIAL_REQUEST to the Diameter credit-control server to perform 5518 credit authorization for the bearer service (e.g., Internet access 5519 service) and to establish a credit-control session (2). In this 5520 message, the credit-control client indicates support for independent 5521 credit-control of multiple services within the session by including 5522 the Multiple-Service-Indicator AVP. The Diameter credit-control 5523 server checks the end user's account balance, with rating information 5524 received from the client (i.e., Service-Id and access specific AVPs), 5525 rates the request, and reserves credit from the end user's account. 5526 Suppose that the server reserves $5 and determines that the cost is 5527 $1/MB. It then returns to the service element a Credit-Control- 5528 Answer message that includes the Multiple-Services-Credit-Control AVP 5529 with a quota of 5MB associated to the Service-Id (access), to a 5530 multiplier value of 10, and to the Pool-Id 1 (3). 5532 The user uses Service 1 (4). The service element sends a Diameter 5533 Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to 5534 the credit-control server to perform credit authorization for service 5535 1 (5). This message includes the Multiple-Services-Credit-Control 5536 AVP to request service units for Service 1 that belong to Rating- 5537 Group 1. The Diameter credit-control server determines that Service 5538 1 draws credit resources from the same account as the access service 5539 (i.e., pool 1). It rates the request according to Service-Id/Rating- 5540 Group and updates the existing reservation by requesting more credit. 5541 Suppose that the server reserves $5 more (now the reservation is $10) 5542 and determines that the cost is $0.1/minute. The server authorizes 5543 the whole Rating-Group. It then returns to the service element a 5544 Credit-Control-Answer message that includes the Multiple-Services- 5545 Credit-Control AVP with a quota of 50min. associated to the Rating- 5546 Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The 5547 client adjusts the total amount of resources for pool 1 according the 5548 received quota, which gives S for Pool 1 = 100. 5550 The user uses Service 2, which belongs to the authorized Rating- 5551 Group, 1 (7). Resources are then consumed from the pool 1. 5553 The user now requests Services 3 and 4 as well, which are not 5554 authorized (8). The service element sends a Diameter Credit-Control- 5555 Request with CC-Request-Type set to UPDATE_REQUEST to the credit- 5556 control server in order to perform credit authorization for Services 5557 3 and 4 (9). This message includes two instances of the Multiple- 5558 Services-Credit-Control AVP to request service units for Service 3 5559 that belong to Rating-Group 2 and for Service 4 that belong to 5560 Rating-Group 3. The Diameter credit-control server determines that 5561 Services 3 and 4 draw credit resources from another account (i.e., 5562 pool 2). It checks the end user's account balance and, according to 5563 Service-Ids/Rating-Groups information, rates the request. Then it 5564 reserves credit from pool 2. 5566 For example, the server reserves $5 and determines that Service 3 5567 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes 5568 only Services 3 and 4. It returns to the service element a Credit- 5569 Control-Answer message that includes two instances of the Multiple- 5570 Services-Credit-Control AVP (10). One instance grants a quota of 5571 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and 5572 to the Pool-Id 2. The other instance grants a quota of 5 MB 5573 associated to the Service-Id 4 to a multiplier value of 5 and to the 5574 Pool-Id 2. 5576 The server also determines that pool 2 is exhausted and Service 4 is 5577 not allowed to continue after these units will be consumed. 5578 Therefore the Final-Unit-Indication AVP with action TERMINATE is 5579 associated to the Service-Id 4. The client calculates the total 5580 amount of resources that can be used for pool 2 according the 5581 received quotas and multipliers, which gives S for Pool 2 = 50. 5583 The Validity-Time for the access service expires. The service 5584 element sends a Credit-Control-Request message to the server in order 5585 to perform credit re-authorization for Service-Id (access) (11). 5586 This message carries one instance of the Multiple-Services-Credit- 5587 Control AVP that includes the units used by this service. Suppose 5588 that the total amount of used units is 4MB. The client adjusts the 5589 total amount of resources for pool 1 accordingly, which gives S for 5590 Pool 1 = 60. 5592 The server deducts $4 from the user's account and updates the 5593 reservation by requesting more credit. Suppose that the server 5594 reserves $5 more (now the reservation is $11) and already knows the 5595 cost of the Service-Id (access), which is $1/MB. It then returns to 5596 the service element a Credit-Control-Answer message that includes the 5597 Multiple-Services-Credit-Control AVP with a quota of 5 MB associated 5598 to the Service-Id (access), to a multiplier value of 10, and to the 5599 Pool-Id 1 (12). The client adjusts the total amount of resources for 5600 pool 1 according the received quota, which gives S for Pool 1 = 110. 5602 Services 3 and 4 consume the total amount of pool 2 credit resources 5603 (i.e., C1*2 + C2*5 >= S). The service element immediately starts the 5604 TERMINATE action concerning Service 4 and sends a Credit-Control- 5605 Request message with CC-Request-Type set to UPDATE_REQUEST to the 5606 credit-control server in order to perform credit re-authorization for 5607 Service 3 (13). This message contains two instances of the Multiple- 5608 Services-Credit-Control AVP to report the units used by Services 3 5609 and 4. The server deducts the last $5 from the user's account (pool 5610 2) and returns the answer with Result-Code 4011 in the Multiple- 5611 Services-Credit-Control AVP to indicate that Service 3 can continue 5612 without credit-control (14). 5614 The end user logs off from the network (15). To debit the used units 5615 from the end user's account and to stop the credit-control session, 5616 the service element sends a Diameter Credit-Control-Request with CC- 5617 Request-Type set to TERMINATION_REQUEST to the credit-control server 5618 (16). This message contains the units consumed by each of the used 5619 services in multiple instances of the Multiple-Services-Credit- 5620 Control AVP. The used units are associated with the relevant 5621 Service-Identifier and Rating-Group. The Diameter credit-control 5622 server debits the used units to the user's account (Pool 1) and 5623 acknowledges the session termination by sending a Diameter Credit- 5624 Control-Answer to the service element (17). 5626 Appendix C. Changes relative to RFC4006 5628 The following changes were made relative to RFC4006: 5630 Update references to obsolete RFC 3588 to refer to RFC 6733. 5632 Update references to obsolete RFC 4005 to refer to RFC 7155. 5634 Update references to obsolete RFC 2486 to refer to RFC 7542. 5636 Update references to current 3GPP documents. 5638 Update AVP per Errata ID 3329. 5640 Update reference to "IPsec or TLS" to be "TLS/TCP, DTLS/SCTP or 5641 IPsec". 5643 Clarify Filter-Rule AVP in Restrict Access Action. 5645 Remove Encr column from AVP flag rules. 5647 Clarify that RESTRICT_ACCESS action applies after consumption of 5648 final granted units (Section 5.6.3). 5650 Clarify that values in Used-Service-Unit AVP may exceed Granted- 5651 Service-Unit AVP (Section 8.19). 5653 Clarify that IPv6 representation in Redirect-Address-Type AVP 5654 conforms to RFC5952 (Section 8.38). 5656 Describe immediate graceful service termination procedure (in 5657 Section 5.6). 5659 Add extensible User-Equipment-Info-Extension AVP and included 5660 types (from Section 8.52 to Section 8.57). 5662 Add extensible Subscription-Id-Extension AVP and included types 5663 (from Section 8.58 to Section 8.63). 5665 Add extensible Redirect-Server-Extension AVP and included types 5666 (from Section 8.64 to Section 8.67). 5668 Add extensible QoS-Final-Unit-Indication AVP (in Section 8.68). 5670 Updated Security Section to include language consistent with 5671 structures of latest base protocol specification. 5673 Update references to obsolete RFC 5226 to refer to RFC 8126, and 5674 resulting updates to Section 12. 5676 Add section on Privacy Considerations. 5678 Authors' Addresses 5680 Lyle Bertz (editor) 5681 Sprint 5682 6220 Sprint Parkway 5683 Overland Park, KS 66251 5684 United States 5686 Email: lyleb551144@gmail.com 5687 David Dolson (editor) 5688 Sandvine 5689 408 Albert Street 5690 Waterloo, ON N2L 3V3 5691 Canada 5693 Email: ddolson@acm.org 5695 Yuval Lifshitz (editor) 5696 Sandvine 5697 408 Albert Street 5698 Waterloo, ON N2L 3V3 5699 Canada 5701 Email: yuvalif@yahoo.com