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