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