idnits 2.17.1 draft-bertz-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 (July 8, 2016) is 2847 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPPCHARG' -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPPIMEI' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Bertz, Ed. 3 Internet-Draft Sprint 4 Intended status: Standards Track D. Dolson, Ed. 5 Expires: January 9, 2017 Y. Lifshitz, Ed. 6 Sandvine 7 H. Hakala 8 L. Mattila 9 Oy L M Ericsson Ab 10 J-P. Koskinen 11 M. Stura 12 Nokia Networks 13 J. Loughney 14 Nokia Research Center 15 July 8, 2016 17 Diameter Credit-Control Application 18 draft-bertz-dime-rfc4006bis-01 20 Abstract 22 This document specifies a Diameter application that can be used to 23 implement real-time credit-control for a variety of end user services 24 such as network access, Session Initiation Protocol (SIP) services, 25 messaging services, and download services. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 76 1.3. Advertising Application Support . . . . . . . . . . . . . 7 77 2. Architecture Models . . . . . . . . . . . . . . . . . . . . . 8 78 3. Credit-Control Messages . . . . . . . . . . . . . . . . . . . 9 79 3.1. Credit-Control-Request (CCR) Command . . . . . . . . . . 10 80 3.2. Credit-Control-Answer (CCA) Command . . . . . . . . . . . 11 81 4. Credit-Control Application Overview . . . . . . . . . . . . . 12 82 4.1. Service-Specific Rating Input and Interoperability . . . 14 83 4.1.1. Specifying Rating Input AVPs . . . . . . . . . . . . 14 84 4.1.2. Service-Specific Documentation . . . . . . . . . . . 15 85 4.1.3. Handling of Unsupported/Incorrect Rating Input . . . 16 86 4.1.4. RADIUS Vendor-Specific Rating Attributes . . . . . . 16 87 5. Session Based Credit-Control . . . . . . . . . . . . . . . . 16 88 5.1. General Principles . . . . . . . . . . . . . . . . . . . 16 89 5.1.1. Basic Tariff-Time Change Support . . . . . . . . . . 17 90 5.1.2. Credit-Control for Multiple Services within a 91 (sub-)Session . . . . . . . . . . . . . . . . . . . . 18 92 5.2. First Interrogation . . . . . . . . . . . . . . . . . . . 22 93 5.2.1. First Interrogation after Authorization and 94 Authentication . . . . . . . . . . . . . . . . . . . 24 95 5.2.2. Authorization Messages for First Interrogation . . . 25 96 5.3. Intermediate Interrogation . . . . . . . . . . . . . . . 28 97 5.4. Final Interrogation . . . . . . . . . . . . . . . . . . . 30 98 5.5. Server-Initiated Credit Re-Authorization . . . . . . . . 31 99 5.6. Graceful Service Termination . . . . . . . . . . . . . . 33 100 5.6.1. Terminate Action . . . . . . . . . . . . . . . . . . 35 101 5.6.2. Redirect Action . . . . . . . . . . . . . . . . . . . 35 102 5.6.3. Restrict Access Action . . . . . . . . . . . . . . . 37 103 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 38 104 5.7. Failure Procedures . . . . . . . . . . . . . . . . . . . 39 105 6. One Time Event . . . . . . . . . . . . . . . . . . . . . . . 41 106 6.1. Service Price Enquiry . . . . . . . . . . . . . . . . . . 42 107 6.2. Balance Check . . . . . . . . . . . . . . . . . . . . . . 43 108 6.3. Direct Debiting . . . . . . . . . . . . . . . . . . . . . 43 109 6.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . . 44 110 6.5. Failure Procedure . . . . . . . . . . . . . . . . . . . . 45 111 7. Credit-Control Application State Machine . . . . . . . . . . 47 112 8. Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . . 55 113 8.1. CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . . 58 114 8.2. CC-Request-Number AVP . . . . . . . . . . . . . . . . . . 58 115 8.3. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 58 116 8.4. CC-Session-Failover AVP . . . . . . . . . . . . . . . . . 59 117 8.5. CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . . 59 118 8.6. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 60 119 8.7. Cost-Information AVP . . . . . . . . . . . . . . . . . . 60 120 8.8. Unit-Value AVP . . . . . . . . . . . . . . . . . . . . . 61 121 8.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . . 61 122 8.10. Value-Digits AVP . . . . . . . . . . . . . . . . . . . . 61 123 8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . . 61 124 8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . . 62 125 8.13. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 62 126 8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . . 62 127 8.15. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 63 128 8.16. Multiple-Services-Credit-Control AVP . . . . . . . . . . 64 129 8.17. Granted-Service-Unit AVP . . . . . . . . . . . . . . . . 65 130 8.18. Requested-Service-Unit AVP . . . . . . . . . . . . . . . 66 131 8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . . 66 132 8.20. Tariff-Time-Change AVP . . . . . . . . . . . . . . . . . 67 133 8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . . 67 134 8.22. CC-Money AVP . . . . . . . . . . . . . . . . . . . . . . 67 135 8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . . 68 136 8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . . 68 137 8.25. CC-Output-Octets AVP . . . . . . . . . . . . . . . . . . 68 138 8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . . 68 139 8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . . 68 140 8.28. Service-Identifier AVP . . . . . . . . . . . . . . . . . 69 141 8.29. Rating-Group AVP . . . . . . . . . . . . . . . . . . . . 69 142 8.30. G-S-U-Pool-Reference AVP . . . . . . . . . . . . . . . . 69 143 8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . . 70 144 8.32. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 70 145 8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . . 70 146 8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . . 71 147 8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . . 72 148 8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . . 73 149 8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . . 73 150 8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . . 73 151 8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . . 74 152 8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . . 74 153 8.41. Requested-Action AVP . . . . . . . . . . . . . . . . . . 74 154 8.42. Service-Context-Id AVP . . . . . . . . . . . . . . . . . 75 155 8.43. Service-Parameter-Info AVP . . . . . . . . . . . . . . . 76 156 8.44. Service-Parameter-Type AVP . . . . . . . . . . . . . . . 76 157 8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . . 77 158 8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . . 77 159 8.47. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 77 160 8.48. Subscription-Id-Data AVP . . . . . . . . . . . . . . . . 78 161 8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . . 78 162 8.50. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 78 163 8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . . 79 164 9. Result Code AVP Values . . . . . . . . . . . . . . . . . . . 79 165 9.1. Transient Failures . . . . . . . . . . . . . . . . . . . 79 166 9.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 80 167 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 80 168 10.1. Credit-Control AVP Table . . . . . . . . . . . . . . . . 81 169 10.2. Re-Auth-Request/Answer AVP Table . . . . . . . . . . . . 82 170 11. RADIUS/Diameter Credit-Control Interworking Model . . . . . . 82 171 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 172 12.1. Application Identifier . . . . . . . . . . . . . . . . . 86 173 12.2. Command Codes . . . . . . . . . . . . . . . . . . . . . 86 174 12.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 86 175 12.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . 86 176 12.5. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . 86 177 12.6. CC-Session-Failover AVP . . . . . . . . . . . . . . . . 86 178 12.7. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 86 179 12.8. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 87 180 12.9. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 87 181 12.10. Credit-Control-Failure-Handling AVP . . . . . . . . . . 87 182 12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 87 183 12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 87 184 12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 87 185 12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 87 186 12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 88 187 12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 88 188 12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 88 189 12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 88 190 13. Credit-Control Application Related Parameters . . . . . . . . 88 191 14. Security Considerations . . . . . . . . . . . . . . . . . . . 89 192 14.1. Direct Connection with Redirects . . . . . . . . . . . . 90 194 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 195 15.1. Normative References . . . . . . . . . . . . . . . . . . 91 196 15.2. Informative References . . . . . . . . . . . . . . . . . 92 197 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 93 198 Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 93 199 B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 93 200 B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 96 201 B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 98 202 B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 98 203 B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 100 204 B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 101 205 B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 102 206 B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 104 207 B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 106 208 Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 111 209 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112 211 1. Introduction 213 This document specifies a Diameter application that can be used to 214 implement real-time credit-control for a variety of end user services 215 such as network access, Session Initiation Protocol (SIP) services, 216 messaging services, and download services. It provides a general 217 solution to real-time cost and credit-control. 219 The prepaid model has been shown to be very successful, for instance, 220 in GSM networks, where network operators offering prepaid services 221 have experienced a substantial growth of their customer base and 222 revenues. Prepaid services are now cropping up in many other 223 wireless and wire line based networks. 225 In next generation wireless networks, additional functionality is 226 required beyond that specified in the Diameter base protocol. For 227 example, the 3GPP Charging and Billing requirements [TGPPCHARG] state 228 that an application must be able to rate service information in real- 229 time. In addition, it is necessary to check that the end user's 230 account provides coverage for the requested service prior to 231 initiation of that service. When an account is exhausted or expired, 232 the user must be denied the ability to compile additional chargeable 233 events. 235 A mechanism has to be provided to allow the user to be informed of 236 the charges to be levied for a requested service. In addition, there 237 are services such as gaming and advertising that may credit as well 238 as debit a user account. 240 The other Diameter applications provide service specific 241 authorization, and they do not provide credit authorization for 242 prepaid users. The credit authorization shall be generic and 243 applicable to all the service environments required to support 244 prepaid services. 246 To fulfill these requirements, it is necessary to facilitate credit- 247 control communication between the network element providing the 248 service (e.g., Network Access Server, SIP Proxy, and Application 249 Server) and a credit-control server. 251 The scope of this specification is the credit authorization. Service 252 specific authorization and authentication is out of the scope. 254 1.1. Requirements Language 256 In this document, the key words "MAY", "MUST", "MUST NOT", 257 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 258 interpreted as described in [RFC2119]. 260 1.2. Terminology 262 AAA Authentication, Authorization, and Accounting 264 AA answer AA answer generically refers to a service specific 265 authorization and authentication answer. AA answer commands are 266 defined in service specific authorization applications, e.g., 267 [RFC7155] and [RFC4004]. 269 AA request AA request generically refers to a service specific 270 authorization and authentication request. AA request commands are 271 defined in service specific authorization applications e.g., 272 [RFC7155] and [RFC4004]. 274 Credit-control Credit-control is a mechanism that directly interacts 275 in real-time with an account and controls or monitors the charges 276 related to the service usage. Credit-control is a process of 277 checking whether credit is available, credit-reservation, 278 deduction of credit from the end user account when service is 279 completed and refunding of reserved credit that is not used. 281 Diameter Credit-control Server A Diameter credit-control server acts 282 as a prepaid server, performing real-time rating and credit- 283 control. It is located in the home domain and is accessed by 284 service elements or Diameter AAA servers in real-time for purpose 285 of price determination and credit-control before the service event 286 is delivered to the end-user. It may also interact with business 287 support systems. 289 Diameter Credit-control Client A Diameter credit-control client is 290 an entity that interacts with a credit-control server. It 291 monitors the usage of the granted quota according to instructions 292 returned by credit-control server. 294 Interrogation The Diameter credit-control client uses interrogation 295 to initiate a session based credit-control process. During the 296 credit-control process, it is used to report the used quota and 297 request a new one. An interrogation maps to a request/answer 298 transaction. 300 One-time event Basically, a request/answer transaction of type 301 event. 303 Rating The act of determining the cost of the service event. 305 Service A type of task performed by a service element for an end 306 user. 308 Service Element A network element that provides a service to the end 309 users. The Service Element may include the Diameter credit- 310 control client, or another entity (e.g., RADIUS AAA server) that 311 can act as a Credit- control client on behalf of the Service 312 Element. In the latter case, the interface between the Service 313 Element and the Diameter credit- control client is outside the 314 scope of this specification. Examples of the Service Elements 315 include Network Access Server (NAS), SIP Proxy, and Application 316 Servers such as messaging server, content server, and gaming 317 server. 319 Service Event An event relating to a service provided to the end 320 user. 322 Session based credit-control A credit-control process that makes use 323 of several interrogations: the first, a possible intermediate, and 324 the final. The first interrogation is used to reserve money from 325 the user's account and to initiate the process. The intermediate 326 interrogations may be needed to request new quota while the 327 service is being rendered. The final interrogation is used to 328 exit the process. The credit-control server is required to 329 maintain session state for session-based credit- control. 331 1.3. Advertising Application Support 333 Diameter nodes conforming to this specification MUST advertise 334 support by including the value of 4 in the Auth-Application-Id of the 335 Capabilities-Exchange-Request and Capabilities-Exchange-Answer 336 command [RFC6733]. 338 2. Architecture Models 340 The current accounting models specified in the Radius Accounting 341 [RFC2866] and Diameter base [RFC6733] are not sufficient for real- 342 time credit-control, where credit-worthiness is to be determined 343 prior to service initiation. Also, the existing Diameter 344 authorization applications, [RFC7155] and [RFC4004], only provide 345 service authorization, but do not provide credit authorization for 346 prepaid users. In order to support real-time credit-control, a new 347 type of server is needed in the AAA infrastructure: Diameter credit- 348 control server. The Diameter credit-control server is the entity 349 responsible for credit authorization for prepaid subscribers. 351 A service element may authenticate and authorize the end user with 352 the AAA server by using AAA protocols; e.g., RADIUS or a Diameter 353 base protocol with a possible Diameter application. 355 Accounting protocols such as RADIUS accounting and the Diameter base 356 accounting protocol can be used to provide accounting data to the 357 accounting server after service is initiated, and to provide possible 358 interim reports until service completion. However, for real-time 359 credit-control, these authorization and accounting models are not 360 sufficient. 362 When real-time credit-control is required, the credit-control client 363 contacts the credit-control server with information about a possible 364 service event. The credit-control process is performed to determine 365 potential charges and to verify whether the end user's account 366 balance is sufficient to cover the cost of the service being 367 rendered. 369 Figure 1 illustrates the typical credit-control architecture, which 370 consists of a Service Element with an embedded Diameter credit- 371 control client, a Diameter credit-control server, and an AAA server. 372 A Business Support System is usually deployed; it includes at least 373 the billing functionality. The credit-control server and AAA server 374 in this architecture model are logical entities. The real 375 configuration can combine them into a single host. The credit- 376 control protocol is the Diameter base protocol with the Diameter 377 credit-control application. 379 When an end user requests services such as SIP or messaging, the 380 request is typically forwarded to a service element (e.g., SIP Proxy) 381 in the user's home domain. In some cases it might be possible that 382 the service element in the visited domain can offer services to the 383 end user; however, a commercial agreement must exist between the 384 visited domain and the home domain. Network access is an example of 385 a service offered in the visited domain where the NAS, through an AAA 386 infrastructure, authenticates and authorizes the user with the user's 387 home network. 389 Service Element AAA and CC 390 +----------+ +---------+ Protocols+-----------+ +--------+ 391 | End |<---->|+-------+|<------------>| AAA | |Business| 392 | User | +->|| CC || | Server |->|Support | 393 | | | || Client||<-----+ | | |System | 394 +----------+ | |+-------+| | +-----------+ | | 395 | +---------+ | ^ +--------+ 396 +----------+ | | CC Protocol | ^ 397 | End |<--+ | +-----v----+ | 398 | User | +------>|Credit- | | 399 +----------+ Credit-Control |Control |--------+ 400 Protocol |Server | 401 +----------+ 403 Figure 1: Typical credit-control architecture 405 There can be multiple credit-control servers in the system for 406 redundancy and load balancing. The system can also contain separate 407 rating server(s), and accounts can be located in a centralized 408 database. To ensure that the end user's account is not debited or 409 credited multiple times for the same service event, only one place in 410 the credit-control system should perform duplicate detection. System 411 internal interfaces can exist to relay messages between servers and 412 an account manager. However, the detailed architecture of the 413 credit-control system and its interfaces are implementation specific 414 and are out of scope of this specification. 416 Protocol transparent Diameter relays can exist between the credit- 417 control client and credit-control server. Also, Diameter Redirect 418 agents that refer credit-control clients to credit-control servers 419 and allow them to communicate directly can exist. These agents 420 transparently support the Diameter credit-control application. The 421 different roles of Diameter Agents are defined in Diameter base 422 [RFC6733], section 2.8. 424 If Diameter credit-control proxies exist between the credit-control 425 client and the credit-control server, they MUST advertise the 426 Diameter credit-control application support. 428 3. Credit-Control Messages 430 This section defines new Diameter message Command-Code values that 431 MUST be supported by all Diameter implementations that conform to 432 this specification. The Command Codes are as follows: 434 +------------------------+---------+------+-----------+ 435 | Command-Name | Abrrev. | Code | Reference | 436 +------------------------+---------+------+-----------+ 437 | Credit-Control-Request | CCR | 272 | 3.1 | 438 | Credit-Control-Answer | CCA | 272 | 3.2 | 439 +------------------------+---------+------+-----------+ 441 Table 1: Credit-Control Commands 443 Diameter Base [RFC6733] defines in the section 3.2 the Command Code 444 format specification. These formats are observed in Credit-Control 445 messages. 447 3.1. Credit-Control-Request (CCR) Command 449 The Credit-Control-Request message (CCR) is indicated by the command- 450 code field being set to 272 and the 'R' bit being set in the Command 451 Flags field. It is used between the Diameter credit-control client 452 and the credit-control server to request credit authorization for a 453 given service. 455 The Auth-Application-Id MUST be set to the value 4, indicating the 456 Diameter credit-control application. 458 Message Format 459 ::= < Diameter Header: 272, REQ, PXY > 460 < Session-Id > 461 { Origin-Host } 462 { Origin-Realm } 463 { Destination-Realm } 464 { Auth-Application-Id } 465 { Service-Context-Id } 466 { CC-Request-Type } 467 { CC-Request-Number } 468 [ Destination-Host ] 469 [ User-Name ] 470 [ CC-Sub-Session-Id ] 471 [ Acct-Multi-Session-Id ] 472 [ Origin-State-Id ] 473 [ Event-Timestamp ] 474 *[ Subscription-Id ] 475 [ Service-Identifier ] 476 [ Termination-Cause ] 477 [ Requested-Service-Unit ] 478 [ Requested-Action ] 479 *[ Used-Service-Unit ] 480 [ Multiple-Services-Indicator ] 481 *[ Multiple-Services-Credit-Control ] 482 *[ Service-Parameter-Info ] 483 [ CC-Correlation-Id ] 484 [ User-Equipment-Info ] 485 *[ Proxy-Info ] 486 *[ Route-Record ] 487 *[ AVP ] 489 3.2. Credit-Control-Answer (CCA) Command 491 The Credit-Control-Answer message (CCA) is indicated by the command- 492 code field being set to 272 and the 'R' bit being cleared in the 493 Command Flags field. It is used between the credit-control server 494 and the Diameter credit-control client to acknowledge a Credit- 495 Control-Request command. 497 Message Format 498 ::= < Diameter Header: 272, PXY > 499 < Session-Id > 500 { Result-Code } 501 { Origin-Host } 502 { Origin-Realm } 503 { Auth-Application-Id } 504 { CC-Request-Type } 505 { CC-Request-Number } 506 [ User-Name ] 507 [ CC-Session-Failover ] 508 [ CC-Sub-Session-Id ] 509 [ Acct-Multi-Session-Id ] 510 [ Origin-State-Id ] 511 [ Event-Timestamp ] 512 [ Granted-Service-Unit ] 513 *[ Multiple-Services-Credit-Control ] 514 [ Cost-Information] 515 [ Final-Unit-Indication ] 516 [ Check-Balance-Result ] 517 [ Credit-Control-Failure-Handling ] 518 [ Direct-Debiting-Failure-Handling ] 519 [ Validity-Time] 520 *[ Redirect-Host] 521 [ Redirect-Host-Usage ] 522 [ Redirect-Max-Cache-Time ] 523 *[ Proxy-Info ] 524 *[ Route-Record ] 525 *[ Failed-AVP ] 526 *[ AVP ] 528 4. Credit-Control Application Overview 530 The credit authorization process takes place before and during 531 service delivery to the end user and generally requires the user's 532 authentication and authorization before any request is sent to the 533 credit-control server. The credit-control application defined in 534 this specification supports two different credit authorization 535 models: credit authorization with money reservation and credit 536 authorization with direct debiting. In both models, the credit- 537 control client requests credit authorization from the credit-control 538 server prior to allowing any service to be delivered to the end user. 540 In the first model, the credit-control server rates the request, 541 reserves a suitable amount of money from the user's account, and 542 returns the corresponding amount of credit resources. Note that 543 credit resources may not imply actual monetary credit; credit 544 resources may be granted to the credit control client in the form of 545 units (e.g., data volume or time) to be metered. 547 Upon receipt of a successful credit authorization answer with a 548 certain amount of credit resources, the credit-control client allows 549 service delivery to the end user and starts monitoring the usage of 550 the granted resources. When the credit resources granted to the user 551 have been consumed or the service has been successfully delivered or 552 terminated, the credit-control client reports back to the server the 553 used amount. The credit-control server deducts the used amount from 554 the end user's account; it may perform rating and make a new credit 555 reservation if the service delivery is continuing. This process is 556 accomplished with session based credit-control that includes the 557 first interrogation, possible intermediate interrogations, and the 558 final interrogation. For session based credit-control, both the 559 credit control client and the credit-control server are required to 560 maintain credit-control session state. Session based credit-control 561 is described in more detail, with more variations, in Section 5. 563 In contrast, credit authorization with direct debiting is a single 564 transaction process wherein the credit-control server directly 565 deducts a suitable amount of money from the user's account as soon as 566 the credit authorization request is received. Upon receipt of a 567 successful credit authorization answer, the credit-control client 568 allows service delivery to the end user. This process is 569 accomplished with the one-time event. Session state is not 570 maintained. 572 In a multi-service environment, an end user can issue an additional 573 service request (e.g., data service) during an ongoing service (e.g., 574 voice call) toward the same account. Alternatively, during an active 575 multimedia session, an additional media type is added to the session, 576 causing a new simultaneous request toward same account. 577 Consequently, this needs to be considered when credit resources are 578 granted to the services. 580 The credit-control application also supports operations such as 581 service price enquiry, user's balance check, and refund of credit on 582 the user's account. These operations are accomplished with the one- 583 time event. Session state is not maintained. 585 A flexible credit-control application specific failure handling is 586 defined in which the home service provider can model the credit- 587 control client behavior according to its own credit risk management 588 policy. 590 The Credit-Control-Failure-Handling AVP and the Direct-Debiting- 591 Failure-Handling AVP are defined to determine what is done if the 592 sending of credit-control messages to the credit-control server has 593 been temporarily prevented. The usage of the Credit-Control- 594 Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP 595 allows flexibility, as failure handling for the credit-control 596 session and one time event direct debiting may be different. 598 4.1. Service-Specific Rating Input and Interoperability 600 The Diameter credit-control application defines the framework for 601 credit-control; it provides generic credit-control mechanisms 602 supporting multiple service applications. The credit-control 603 application, therefore, does not define AVPs that could be used as 604 input in the rating process. Listing the possible services that 605 could use this Diameter application is out of scope for this generic 606 mechanism. 608 It is reasonable to expect that a service level agreement will exist 609 between providers of the credit-control client and the credit-control 610 server covering the charging, services offered, roaming agreements, 611 agreed rating input (i.e., AVPs), and so on. 613 Therefore, it is assumed that a Diameter credit-control server will 614 provide service only for Diameter credit-control clients that have 615 agreed beforehand as to the content of credit-control messages. 616 Naturally, it is possible that any arbitrary Diameter credit-control 617 client can interchange credit-control messages with any Diameter 618 credit-control server, but with a higher likelihood that unsupported 619 services/AVPs could be present in the credit-control message, causing 620 the server to reject the request with an appropriate result-code. 622 4.1.1. Specifying Rating Input AVPs 624 There are two ways to provide rating input to the credit-control 625 server: either by using AVPs or by including them in the Service- 626 Parameter-Info AVP. The general principles for sending rating 627 parameters are as follows: 629 1a. The service SHOULD re-use existing AVPs if it can use AVPs 630 defined in existing Diameter applications (e.g., [RFC7155] for 631 network access services). Re-use of existing AVPs is strongly 632 recommended in [RFC6733]. 634 For AVPs of type Enumerated, the service may require a new value to 635 be defined. Allocation of new AVP values is done as specified in 636 [RFC6733], section 1.3. 638 1b. New AVPs can be defined if the existing AVPs do not provide 639 sufficient rating information. In this case, the procedures defined 640 in [RFC6733] for creating new AVPs MUST be followed. 642 1c. For services specific only to one vendor's implementation, a 643 Vendor-Specific AVP code for Private use can be used. Where a 644 Vendor-Specific AVP is implemented by more than one vendor, 645 allocation of global AVPs is encouraged instead; refer to [RFC6733]. 647 2. The Service-Parameter-Info AVP MAY be used as a container to pass 648 legacy rating information in its original encoded form (e.g., ASN.1 649 BER). This method can be used to avoid unnecessary conversions from 650 an existing data format to an AVP format. In this case, the rating 651 input is embedded in the Service-Parameter-Info AVP as defined in 652 Section 8.43. 654 New service applications SHOULD favor the use of explicitly defined 655 AVPs as described in items 1a and 1b, to simplify interoperability. 657 4.1.2. Service-Specific Documentation 659 The service specific rating input AVPs, the contents of the Service- 660 Parameter-Info AVP or Service-Context-Id AVP (defined in 661 Section 8.42) are not within the scope of this document. To 662 facilitate interoperability, it is RECOMMENDED that the rating input 663 and the values of the Service-Context-Id be coordinated via an 664 informational RFC or other permanent and readily available reference. 665 The specification of another cooperative standardization body (e.g., 666 3GPP, OMA, and 3GPP2) SHOULD be used. However, private services may 667 be deployed that are subject to agreements between providers of the 668 credit-control server and client. In this case, vendor specific AVPs 669 can be used. 671 This specification, together with the above service specific 672 documents, governs the credit-control message. Service specific 673 documents define which existing AVPs or new AVPs are used as input to 674 the rating process (i.e., those that do not define new credit-control 675 applications), and thus have to be included in the Credit-Control- 676 Request command by a Diameter credit-control client supporting a 677 given service as *[AVP]. Should Service-Parameter-Info be used, then 678 the service specific document MUST specify the exact content of this 679 grouped AVP. 681 The Service-Context-Id AVP MUST be included at the command level of a 682 Credit-Control Request to identify the service specific document that 683 applies to the request. The specific service or rating group the 684 request relates to is uniquely identified by the combination of 685 Service-Context-Id and Service-Identifier or Rating-Group. 687 4.1.3. Handling of Unsupported/Incorrect Rating Input 689 Diameter credit-control implementations are required to support the 690 Mandatory rating AVPs defined in service specific documentation of 691 the services they support, according to the 'M' bit rules in 692 [RFC6733]. 694 If a rating input required for the rating process is incorrect in the 695 Credit-control request, or if the credit-control server does not 696 support the requested service context (identified by the Service- 697 Context-Id AVP at command level), the Credit-control answer MUST 698 contain the error code DIAMETER_RATING_FAILED. A CCA message with 699 this error MUST contain one or more Failed-AVP AVPs containing the 700 missing and/or unsupported AVPs that caused the failure. A Diameter 701 credit-control client that receives the error code 702 DIAMETER_RATING_FAILED in response to a request MUST NOT send similar 703 requests in the future. 705 4.1.4. RADIUS Vendor-Specific Rating Attributes 707 When service specific documents include RADIUS vendor specific 708 attributes that could be used as input in the rating process, the 709 rules described in [RFC7155] for formatting the Diameter AVP MUST be 710 followed. 712 For example, if the AVP code used is the vendor attribute type code, 713 the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be 714 set to the IANA Vendor identification value. The Diameter AVP data 715 field contains only the attribute value of the RADIUS attribute. 717 5. Session Based Credit-Control 719 5.1. General Principles 721 For a session-based credit-control, several interrogations are 722 needed: the first, intermediate (optional) and the final 723 interrogations. This is illustrated in Figures 2 and 3. 725 If the credit-control client performs credit-reservation before 726 granting service to the end user, it MUST use several interrogations 727 toward the credit-control server (i.e., session based credit- 728 control). In this case, the credit-control server MUST maintain the 729 credit-control session state. 731 Each credit-control session MUST have a globally unique Session-Id as 732 defined in [RFC6733], which MUST NOT be changed during the lifetime 733 of a credit-control session. 735 Certain applications require multiple credit-control sub-sessions. 736 These applications would send messages with a constant Session-Id 737 AVP, but with a different CC-Sub-Session-Id AVP. If several credit 738 sub-sessions will be used, all sub-sessions MUST be closed separately 739 before the main session is closed so that units per sub-session may 740 be reported. The absence of this AVP implies that no sub-sessions 741 are in use. 743 Note that the service element might send a service specific re- 744 authorization message to the AAA server due to expiration of the 745 authorization-lifetime during an ongoing credit-control session. 746 However, the service specific re-authorization does not influence the 747 credit authorization that is ongoing between the credit-control 748 client and credit-control server, as credit authorization is 749 controlled by the burning rate of the granted quota. 751 If service specific re-authorization fails, the user will be 752 disconnected, and the credit-control client MUST send a final 753 interrogation to the credit-control server. 755 The Diameter credit-control server may seek to control the validity 756 time of the granted quota and/or the production of intermediate 757 interrogations. Thus, it MAY include the Validity-Time AVP in the 758 answer message to the credit-control client. Upon expiration of the 759 Validity-Time, the credit-control client MUST generate a credit- 760 control update request and report the used quota to the credit- 761 control server. It is up to the credit-control server to determine 762 the value of the Validity-Time to be used for consumption of the 763 granted service units. If the Validity-Time is used, its value 764 SHOULD be given as input to set the session supervision timer Tcc 765 (the session supervision timer MAY be set to two times the value of 766 the Validity-Time, as defined in Section 13). Since credit-control 767 update requests are also produced at the expiry of granted service 768 units and/or for mid-session service events, the omission of 769 Validity-Time does not mean that intermediate interrogation for the 770 purpose of credit-control is not performed. 772 5.1.1. Basic Tariff-Time Change Support 774 The Diameter credit-control server and client MAY optionally support 775 a tariff change mechanism. The Diameter credit-control server may 776 include a Tariff-Time-Change AVP in the answer message. Note that 777 the granted units should be allocated based on the worst-case 778 scenario in case of forthcoming tariff change, so that the overall 779 reported used units would never exceed the credit reservation. 781 When the Diameter credit-control client reports the used units and a 782 tariff change has occurred during the reporting period, the Diameter 783 credit-control client MUST separately itemize the units used before 784 and after the tariff change. If the client is unable to distinguish 785 whether units straddling the tariff change were used before or after 786 the tariff change, the credit-control client MUST itemize those units 787 in a third category. 789 If a client does not support the tariff change mechanism and it 790 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 791 terminate the credit-control session, giving a reason of 792 DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 794 For time based services, the quota is continuously consumed at the 795 regular rate of 60 seconds per minute. At the time when credit 796 resources are allocated, the server already knows how many units will 797 be consumed before the tariff time change and how many units will be 798 consumed afterward. Similarly, the server can determine the units 799 consumed at the before rate and the units consumed at the rate 800 afterward in the event that the end-user closes the session before 801 the consumption of the allotted quota. There is no need for 802 additional traffic between client and server in the case of tariff 803 time changes for continuous time based service. Therefore, the 804 tariff change mechanism is not used for such services. For time- 805 based services in which the quota is NOT continuously consumed at a 806 regular rate, the tariff change mechanism described for volume and 807 event units MAY be used. 809 5.1.2. Credit-Control for Multiple Services within a (sub-)Session 811 When multiple services are used within the same user session and each 812 service or group of services is subject to different cost, it is 813 necessary to perform credit-control for each service independently. 814 Making use of credit-control sub-sessions to achieve independent 815 credit-control will result in increased signaling load and usage of 816 resources in both the credit-control client and the credit-control 817 server. For instance, during one network access session the end user 818 may use several http-services subject to different access cost. The 819 network access specific attributes such as the quality of service 820 (QoS) are common to all the services carried within the access 821 bearer, but the cost of the bearer may vary depending on its content. 823 To support these scenarios optimally, the credit-control application 824 enables independent credit-control of multiple services in a single 825 credit-control (sub-)session. This is achieved by including the 826 optional Multiple-Services-Credit-Control AVP in Credit-Control- 827 Request/Answer messages. It is possible to request and allocate 828 resources as a credit pool shared between multiple services. The 829 services can be grouped into rating groups in order to achieve even 830 further aggregation of credit allocation. It is also possible to 831 request and allocate quotas on a per service basis. Where quotas are 832 allocated to a pool by means of the Multiple-Services-Credit-Control 833 AVP, the quotas remain independent objects that can be re-authorized 834 independently at any time. Quotas can also be given independent 835 result codes, validity times, and Final-Unit-Indications. 837 A Rating-Group gathers a set of services, identified by a Service- 838 Identifier, and subject to the same cost and rating type (e.g., $0.1/ 839 minute). It is assumed that the service element is provided with 840 Rating-Groups, Service-Identifiers, and their associated parameters 841 that define what has to be metered by means outside the scope of this 842 specification. (Examples of parameters associated to Service- 843 Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers enable 844 authorization on a per-service based credit as well as itemized 845 reporting of service usage. It is up to the credit-control server 846 whether to authorize credit for one or more services or for the whole 847 rating-group. However, the client SHOULD always report used units at 848 the finest supported level of granularity. Where quota is allocated 849 to a rating-group, all the services belonging to that group draw from 850 the allotted quota. The following is a graphical representation of 851 the relationship between service-identifiers, rating-groups, credit 852 pools, and credit-control (sub-)session. 854 DCC (Sub-)Session 855 | 856 +------------+-----------+-------------+--------------- + 857 | | | | | 858 Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z 859 \ / \ / / 860 \ / \ / / 861 \ / Rating-Group 1.......Rating-Group n 862 \ / | | 863 Quota ---------------Quota Quota 864 | / | 865 | / | 866 Credit-Pool Credit-Pool 868 Figure 2: Multiple-Service (sub)-Session Example 870 If independent credit-control of multiple services is used, the 871 validity-time and final-unit-indication SHOULD be present either in 872 the Multiple-Services-Credit-Control AVP(s) or at command level as 873 single AVPs. However, the Result-Code AVP MAY be present both on the 874 command level and within the Multiple-Services-Credit-Control AVP. 875 If the Result-Code on the command level indicates a value other than 876 SUCCESS, then the Result-Code on command level takes precedence over 877 any included in the Multiple-Services-Credit-Control AVP. 879 The credit-control client MUST indicate support for independent 880 credit-control of multiple services within a (sub-)session by 881 including the Multiple-Services-Indicator AVP in the first 882 interrogation. A credit-control server not supporting this feature 883 MUST treat the Multiple-Services-Indicator AVP and any received 884 Multiple-Services-Credit-Control AVPs as invalid AVPs. 886 If the client indicated support for independent credit-control of 887 multiple services, a credit-control server that wishes to use the 888 feature MUST return the granted units within the Multiple-Services- 889 Credit-Control AVP associated to the corresponding service-identifier 890 and/or rating-group. 892 To avoid a situation where several parallel (and typically also 893 small) credit reservations must be made on the same account (i.e., 894 credit fragmentation), and also to avoid unnecessary load on the 895 credit-control server, it is possible to provide service units as a 896 pool that applies to multiple services or rating groups. This is 897 achieved by providing the service units in the form of a quota for a 898 particular service or rating group in the Multiple-Services-Credit- 899 Control AVP, and also by including a reference to a credit pool for 900 that unit type. 902 The reference includes a multiplier derived from the rating 903 parameter, which translates from service units of a specific type to 904 the abstract service units in the pool. For instance, if the rating 905 parameter for service 1 is $1/MB and the rating parameter for service 906 2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2, 907 respectively. 909 If S is the total service units within the pool, M1, M2, ..., Mn are 910 the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., 911 Cn are the used resources within the session, then the pool credit is 912 exhausted and re-authorization MUST be sought when: 914 C1*M1 + C2*M2 + ... + Cn*Mn >= S 916 The total credit in the pool, S, is calculated from the quotas, which 917 are currently allocated to the pool as follows: 919 S = Q1*M1 + Q2*M2 + ... + Qn*Mn 921 If services or rating groups are added to or removed from the pool, 922 then the total credit is adjusted appropriately. Note that when the 923 total credit is adjusted because services or rating groups are 924 removed from the pool, the value that need to be removed is the 925 consumed one (i.e., Cx*Mx). 927 Re-authorizations for an individual service or rating group may be 928 sought at any time; for example, if a 'non-pooled' quota is used up 929 or the Validity-Time expires. 931 Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same 932 G-S-U-Pool-Identifier are provided within a Multiple-Services- 933 Credit-Control AVP (Section 8.16) along with the Granted-Service-Unit 934 AVP, then these MUST have different CC-Unit-Type values, and they all 935 draw from the credit pool separately. For instance, if one 936 multiplier for time (M1t) and one multiplier for volume (M1v) are 937 given, then the used resources from the pool is the sum C1t*M1t + 938 C1v*M1v, where C1t is the time unit and C1v is the volume unit. 940 Where service units are provided within a Multiple-Services-Credit- 941 Control AVP without a corresponding G-S-U-Pool-Reference AVP, then 942 these are handled independently from any credit pool and from any 943 other services or rating groups within the session. 945 The credit pool concept is an optimal tool to avoid the over- 946 reservation effect of the basic single quota tariff time change 947 mechanism (the mechanism described in Section 5.1.1). Therefore, 948 Diameter credit-control clients and servers implementing the 949 independent credit-control of multiple services SHOULD leverage the 950 credit pool concept when supporting the tariff time change. The 951 Diameter credit-control server SHOULD include both the Tariff-Time- 952 Change and Tariff-Change-Usage AVPs in two quota allocations in the 953 answer message (i.e., two instances of the Multiple-Services-Credit- 954 Control AVP). One of the granted units is allocated to be used 955 before the potential tariff change, while the second granted units 956 are for use after a tariff change. Both granted unit quotas MUST 957 contain the same Service-Identifier and/or Rating-Group. This dual 958 quota mechanism ensures that the overall reported used units would 959 never exceed the credit reservation. The Diameter credit-control 960 client reports both the used units before and after the tariff change 961 in a single instance of the Multiple-Services-Credit-Control AVP. 963 The failure handling for credit-control sessions is defined in 964 Section 5.7 and reflected in the basic credit-control state machine 965 in Section 7. Credit-control clients and servers implementing the 966 independent credit-control of multiple services in a (sub-)session 967 functionality MUST ensure failure handling and general behavior fully 968 consistent with the above mentioned sections, while maintaining the 969 ability to handle parallel ongoing credit re-authorization within a 970 (sub-)session. Therefore, it is RECOMMENDED that Diameter credit- 971 control clients maintain a PendingU message queue and restart the Tx 972 timer (Section 13) every time a CCR message with the value 973 UPDATE_REQUEST is sent while they are in PendingU state. When 974 answers to all pending messages are received, the state machine moves 975 to OPEN state, and Tx is stopped. Naturally, the action performed 976 when a problem for the session is detected according to Section 5.7 977 affects all the ongoing services (e.g., failover to a backup server 978 if possible affect all the CCR messages with the value UPDATE_REQUEST 979 in the PendingU queue). 981 Since the client may send CCR messages with the value UPDATE_REQUEST 982 while in PendingU (i.e., without waiting for an answer to ongoing 983 credit re-authorization), the time space between these requests may 984 be very short, and the server may not have received the previous 985 request(s) yet. Therefore, in this situation the server may receive 986 out of sequence requests and SHOULD NOT consider this an error 987 condition. A proper answer is to be returned to each of those 988 requests. 990 5.2. First Interrogation 992 When session based credit-control is required (e.g., the 993 authentication server indicated a prepaid user), the first 994 interrogation MUST be sent before the Diameter credit-control client 995 allows any service event to the end user. The CC-Request-Type is set 996 to the value INITIAL_REQUEST in the request message. 998 If the Diameter credit-control client knows the cost of the service 999 event (e.g., a content server delivering ringing tones may know their 1000 cost) the monetary amount to be charged is included in the Requested- 1001 Service-Unit AVP. If the Diameter credit-control client does not 1002 know the cost of the service event, the Requested-Service- Unit AVP 1003 MAY contain the number of requested service events. Where the 1004 Multiple-Services-Credit-Control AVP is used, it MUST contain the 1005 Requested-Service-Unit AVP to indicate that the quota for the 1006 associated service/rating-group is requested. In the case of 1007 multiple services, the Service-Identifier AVP or the Rating-Group AVP 1008 within the Multiple-Services-Credit-Control AVP always indicates the 1009 service concerned. Additional service event information to be rated 1010 MAY be sent as service specific AVPs or MAY be sent within the 1011 Service-Parameter-Info AVP at command level. The Service-Context-Id 1012 AVP indicates the service specific document applicable to the 1013 request. 1015 The Event-Timestamp AVP SHOULD be included in the request and 1016 contains the time when the service event is requested in the service 1017 element. The Subscription-Id AVP SHOULD be included to identify the 1018 end user in the credit-control server. The credit-control client MAY 1019 include the User-Equipment-Info AVP so that the credit-control server 1020 has some indication of the type and capabilities of the end user 1021 access device. How the credit-control server uses this information 1022 is outside the scope of this document. 1024 The credit-control server SHOULD rate the service event and make a 1025 credit-reservation from the end user's account that covers the cost 1026 of the service event. If the type of the Requested-Service-Unit AVP 1027 is money, no rating is needed, but the corresponding monetary amount 1028 is reserved from the end user's account. 1030 The credit-control server returns the Granted-Service-Unit AVP in the 1031 Answer message to the Diameter credit-control client. The Granted- 1032 Service-Unit AVP contains the amount of service units that the 1033 Diameter credit-control client can provide to the end user until a 1034 new Credit-Control-Request MUST be sent to the credit-control server. 1035 If several unit types are sent in the Answer message, the credit- 1036 control client MUST handle each unit type separately. The type of 1037 the Granted-Service-Unit AVP can be time, volume, service specific, 1038 or money, depending on the type of service event. The unit type(s) 1039 SHOULD NOT be changed within an ongoing credit-control session. 1041 There MUST be a maximum of one instance of the same unit type in one 1042 Answer message. However, if multiple quotas are conveyed to the 1043 credit-control client in the Multiple-Services-Credit-Control AVPs, 1044 it is possible to carry two instances of the same unit type 1045 associated to a service-identifier/rating-group. This is typically 1046 the case when a tariff time change is expected and the credit-control 1047 server wants to make a distinction between the granted quota before 1048 and after tariff change. 1050 If the credit-control server determines that no further control is 1051 needed for the service, it MAY include the result code indicating 1052 that the credit-control is not applicable (e.g., if the service is 1053 free of charge). This result code at command level implies that the 1054 credit-control session is to be terminated. 1056 The Credit-Control-Answer message MAY also include the Final-Unit- 1057 Indication AVP to indicate that the answer message contains the final 1058 units for the service. After the end user has consumed these units, 1059 the Diameter credit-control-client MUST behave as described in 1060 Section 5.6. 1062 This document defines two different approaches to perform the first 1063 interrogation to be used in different network architectures. The 1064 first approach uses credit-control messages after the user's 1065 authorization and authentication takes place. The second approach 1066 uses service specific authorization messages to perform the first 1067 interrogation during the user's authorization/authentication phase, 1068 and credit-control messages for the intermediate and final 1069 interrogations. If an implementation of the credit-control client 1070 supports both the methods, determining which method to use SHOULD be 1071 configurable. 1073 In service environments such as the Network Access Server (NAS), it 1074 is desired to perform the first interrogation as part of the 1075 authorization/authentication process for the sake of protocol 1076 efficiency. Further credit authorizations after the first 1077 interrogation are performed with credit-control commands defined in 1078 this specification. Implementations of credit-control clients 1079 operating in the mentioned environments SHOULD support this method. 1080 If the credit-control server and AAA server are separate physical 1081 entities, the service element sends the request messages to the AAA 1082 server, which then issues an appropriate request or proxies the 1083 received request forward to the credit-control server. 1085 In other service environments, such as the 3GPP network and some SIP 1086 scenarios, there is a substantial decoupling between registration/ 1087 access to the network and the actual service request (i.e., the 1088 authentication/authorization is executed once at registration/access 1089 to the network and is not executed for every service event requested 1090 by the subscriber). In these environments, it is more appropriate to 1091 perform the first interrogation after the user has been authenticated 1092 and authorized. The first, the intermediate, and the final 1093 interrogations are executed with credit- control commands defined in 1094 this specification. 1096 Other IETF standards or standards developed by other standardization 1097 bodies may define the most suitable method in their architectures. 1099 5.2.1. First Interrogation after Authorization and Authentication 1101 The Diameter credit-control client in the service element may get 1102 information from the authorization server as to whether credit- 1103 control is required, based on its knowledge of the end user. If 1104 credit-control is required the credit-control server needs to be 1105 contacted prior to initiating service delivery to the end user. The 1106 accounting protocol and the credit-control protocol can be used in 1107 parallel. The authorization server may also determine whether the 1108 parallel accounting stream is required. 1110 The following diagram illustrates the case where both protocols are 1111 used in parallel and the service element sends credit-control 1112 messages directly to the credit-control server. More credit-control 1113 sequence examples are given in Annex A. 1115 Diameter 1116 End User Service Element AAA Server CC Server 1117 (CC Client) 1118 | Registration | AA request/answer(accounting,cc or both)| 1119 |<----------------->|<------------------>| | 1120 | : | | | 1121 | : | | | 1122 | Service Request | | | 1123 |------------------>| | | 1124 | | CCR(Initial,Credit-Control AVPs) | 1125 | +|---------------------------------------->| 1126 | CC stream|| | CCA(Granted-Units)| 1127 | +|<----------------------------------------| 1128 | Service Delivery | | | 1129 |<----------------->| ACR(start,Accounting AVPs) | 1130 | : |------------------->|+ | 1131 | : | ACA || Accounting stream | 1132 | |<-------------------|+ | 1133 | : | | | 1134 | : | | | 1135 | | CCR(Update,Used-Units) | 1136 | |---------------------------------------->| 1137 | | | CCA(Granted-Units)| 1138 | |<----------------------------------------| 1139 | : | | | 1140 | : | | | 1141 | End of Service | | | 1142 |------------------>| CCR(Termination, Used-Units) | 1143 | |---------------------------------------->| 1144 | | | CCA | 1145 | |<----------------------------------------| 1146 | | ACR(stop) | | 1147 | |------------------->| | 1148 | | ACA | | 1149 | |<-------------------| | 1151 Figure 3: Protocol example with first interrogation after user's 1152 authorization/authentication 1154 5.2.2. Authorization Messages for First Interrogation 1156 The Diameter credit-control client in the service element MUST 1157 actively co-operate with the authorization/authentication client in 1158 the construction of the AA request by adding appropriate credit- 1159 control AVPs. The credit-control client MUST add the Credit-Control 1160 AVP to indicate credit-control capabilities and MAY add other 1161 relevant credit-control specific AVPs to the proper authorization/ 1162 authentication command to perform the first interrogation toward the 1163 home Diameter AAA server. The Auth- Application-Id is set to the 1164 appropriate value, as defined in the relevant service specific 1165 authorization/authentication application document (e.g., [RFC7155], 1166 [RFC4004]). The home Diameter AAA server authenticates/authorizes 1167 the subscriber and determines whether credit-control is required. 1169 If credit-control is not required for the subscriber, the home 1170 Diameter AAA server will respond as usual, with an appropriate AA 1171 answer message. If credit-control is required for the subscriber and 1172 the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was 1173 present in the authorization request, the home AAA server MUST 1174 contact the credit-control server to perform the first interrogation. 1175 If credit-control is required for the subscriber and the Credit- 1176 Control AVP was not present in the authorization request, the home 1177 AAA server MUST send an authorization reject answer message. 1179 The Diameter AAA server supporting credit-control is required to send 1180 the Credit-Control-Request command (CCR) defined in this document to 1181 the credit-control server. The Diameter AAA server populates the CCR 1182 based on service specific AVPs used for input to the rating process, 1183 and possibly on credit-control AVPs received in the AA request. The 1184 credit-control server will reserve money from the user's account, 1185 will rate the request and will send a Credit-Control-Answer message 1186 to the home Diameter AAA server. The answer message includes the 1187 Granted-Service-Unit AVP(s) and MAY include other credit-control 1188 specific AVPs, as appropriate. Additionally, the credit-control 1189 server MAY set the Validity-Time and MAY include the Credit-Control- 1190 Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to 1191 determine what to do if the sending of credit-control messages to the 1192 credit-control server has been temporarily prevented. 1194 Upon receiving the Credit-Control-Answer message from the credit- 1195 control server, the home Diameter AAA server will populate the AA 1196 answer with the received credit-control AVPs and with the appropriate 1197 service attributes according to the authorization/authentication 1198 specific application (e.g., [RFC7155], [RFC4004]). It will then 1199 forward the packet to the credit-control client. If the home 1200 Diameter AAA server receives a credit-control reject message, it will 1201 simply generate an appropriate authorization reject message to the 1202 credit-control client, including the credit-control specific error 1203 code. 1205 In this model, the credit-control client sends further credit-control 1206 messages to the credit-control server via the home Diameter AAA 1207 server. Upon receiving a successful authorization answer message 1208 with the Granted-Service-Unit AVP(s), the credit-control client will 1209 grant the service to the end user and will generate an intermediate 1210 credit-control request, as required by using credit-control commands. 1212 The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 1213 (for how to produce unique value for the CC-Request-Number AVP, see 1214 Section 8.2). 1216 If service specific re-authorization is performed (i.e., 1217 authorization-lifetime expires), the credit-control client MUST add 1218 to the service specific re-authorization request the Credit-Control 1219 AVP with a value set to RE_AUTHORIZATION to indicate that the credit- 1220 control server MUST NOT be contacted. When session based credit- 1221 control is used for the subscriber, a constant credit-control message 1222 stream flows through the home Diameter AAA server. The home Diameter 1223 AAA server can make use of this credit-control message flow to deduce 1224 that the user's activity is ongoing; therefore, it is recommended to 1225 set the authorization-lifetime to a reasonably high value when 1226 credit-control is used for the subscriber. 1228 In this scenario, the home Diameter AAA server MUST advertise support 1229 for the credit-control application to its peers during the capability 1230 exchange process. 1232 The following diagram illustrates the use of authorization/ 1233 authentication messages to perform the first interrogation. The 1234 parallel accounting stream is not shown in the figure. 1236 Service Element Diameter 1237 End User (CC Client) AAA Server CC Server 1238 | Service Request | AA Request (CC AVPs) | 1239 |------------------>|------------------->| | 1240 | | | CCR(Initial, CC AVPs) 1241 | | |------------------->| 1242 | | | CCA(Granted-Units) 1243 | | |<-------------------| 1244 | | AA Answer(Granted-Units) | 1245 | Service Delivery |<-------------------| | 1246 |<----------------->| | | 1247 | : | | | 1248 | : | | | 1249 | : | | | 1250 | | | | 1251 | | CCR(Update,Used-Units) | 1252 | |------------------->| CCR(Update,Used-Units) 1253 | | |------------------->| 1254 | | | CCA(Granted-Units)| 1255 | | CCA(Granted-Units)|<-------------------| 1256 | |<-------------------| | 1257 | : | | | 1258 | : | | | 1259 | End of Service | | | 1260 |------------------>| CCR(Termination,Used-Units) | 1261 | |------------------->| CCR(Term.,Used-Units) 1262 | | |------------------->| 1263 | | | CCA | 1264 | | CCA |<-------------------| 1265 | |<-------------------| | 1267 Figure 4: Protocol example with use of the authorization messages for 1268 the first interrogation 1270 5.3. Intermediate Interrogation 1272 When all the granted service units for one unit type are spent by the 1273 end user or the Validity-Time is expired, the Diameter credit-control 1274 client MUST send a new Credit-Control-Request to the credit-control 1275 server. In the event that credit-control for multiple services is 1276 applied in one credit-control session (i.e., units associated to 1277 Service-Identifier(s) or Rating-Group are granted), a new Credit- 1278 Control-Request MUST be sent to the credit-control server when the 1279 credit reservation has been wholly consumed, or upon expiration of 1280 the Validity-Time. It is always up to the Diameter credit-control 1281 client to send a new request well in advance of the expiration of the 1282 previous request in order to avoid interruption in the service 1283 element. Even if the granted service units reserved by the credit- 1284 control server have not been spent upon expiration of the Validity- 1285 Time, the Diameter credit-control client MUST send a new Credit- 1286 Control-Request to the credit-control server. 1288 There can also be mid-session service events, which might affect the 1289 rating of the current service events. In this case, a spontaneous 1290 updating (a new Credit-Control-Request) SHOULD be sent including 1291 information related to the service event even if all the granted 1292 service units have not been spent or the Validity-Time has not 1293 expired. 1295 When the used units are reported to the credit-control server, the 1296 credit-control client will not have any units in its possession 1297 before new granted units are received from the credit-control server. 1298 When the new granted units are received, these units apply from the 1299 point where the measurement of the reported used units stopped. 1300 Where independent credit-control of multiple services is supported, 1301 this process may be executed for one or more services, a single 1302 rating-group, or a pool within the (sub)session. 1304 The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the 1305 intermediate request message. The Subscription-Id AVP SHOULD be 1306 included in the intermediate message to identify the end user in the 1307 credit-control server. The Service-Context-Id AVP indicates the 1308 service specific document applicable to the request. 1310 The Requested-Service-Unit AVP MAY contain the new amount of 1311 requested service units. Where the Multiple-Services-Credit-Control 1312 AVP is used, it MUST contain the Requested-Service-Unit AVP if a new 1313 quota is requested for the associated service/rating-group. The 1314 Used-Service-Unit AVP contains the amount of used service units 1315 measured from the point when the service became active or, if interim 1316 interrogations are used during the session, from the point when the 1317 previous measurement ended. The same unit types used in the previous 1318 message SHOULD be used. If several unit types were included in the 1319 previous answer message, the used service units for each unit type 1320 MUST be reported. 1322 The Event-Timestamp AVP SHOULD be included in the request and 1323 contains the time of the event that triggered the sending of the new 1324 Credit-Control-Request. 1326 The credit-control server MUST deduct the used amount from the end 1327 user's account. It MAY rate the new request and make a new credit- 1328 reservation from the end user's account that covers the cost of the 1329 requested service event. 1331 A Credit-Control-Answer message with the CC-Request-Type AVP set to 1332 the value UPDATE_REQUEST MAY include the Cost-Information AVP 1333 containing the accumulated cost estimation for the session, without 1334 taking any credit-reservation into account. 1336 The Credit-Control-Answer message MAY also include the Final-Unit- 1337 Indication AVP to indicate that the answer message contains the final 1338 units for the service. After the end user has consumed these units, 1339 the Diameter credit-control-client MUST behave as described in 1340 Section 5.6. 1342 There can be several intermediate interrogations within a session. 1344 5.4. Final Interrogation 1346 When the end user terminates the service session, or when the 1347 graceful service termination described in Section 5.6 takes place, 1348 the Diameter credit-control client MUST send a final Credit-Control- 1349 Request message to the credit-control server. The CC-Request-Type 1350 AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id 1351 AVP indicates the service specific document applicable to the 1352 request. 1354 The Event-Timestamp AVP SHOULD be included in the request and 1355 contains the time when the session was terminated. 1357 The Used-Service-Unit AVP contains the amount of used service units 1358 measured from the point when the service became active or, if interim 1359 interrogations are used during the session, from the point when the 1360 previous measurement ended. If several unit types were included in 1361 the previous answer message, the used service units for each unit 1362 type MUST be reported. 1364 After final interrogation, the credit-control server MUST refund the 1365 reserved credit amount not used to the end user's account and deduct 1366 the used monetary amount from the end user's account. 1368 A Credit-Control-Answer message with the CC-Request-Type set to the 1369 value TERMINATION_REQUEST MAY include the Cost-Information AVP 1370 containing the estimated total cost for the session in question. 1372 If the user logs off during an ongoing credit-control session, or if 1373 some other reason causes the user to become logged off (e.g., final- 1375 unit indication causes user logoff according to local policy), the 1376 service element, according to application specific policy, may send a 1377 Session-Termination-Request (STR) to the home Diameter AAA server as 1378 usual [RFC6733]. Figure 5 illustrates the case when the final-unit 1379 indication causes user logoff upon consumption of the final granted 1380 units and the generation of STR. 1382 Service Element AAA Server CC Server 1383 End User (CC Client) 1384 | Service Delivery | | | 1385 |<----------------->| | | 1386 | : | | | 1387 | : | | | 1388 | : | | | 1389 | | | | 1390 | | CCR(Update,Used-Units) | 1391 | |------------------->| CCR(Update,Used-Units) 1392 | | |------------------->| 1393 | | CCA(Final-Unit, Terminate) 1394 | CCA(Final-Unit, Terminate)|<-------------------| 1395 | |<-------------------| | 1396 | : | | | 1397 | : | | | 1398 | Disconnect user | | | 1399 |<------------------| CCR(Termination,Used-Units) | 1400 | |------------------->| CCR(Term.,Used-Units) 1401 | | |------------------->| 1402 | | | CCA | 1403 | | CCA |<-------------------| 1404 | |<-------------------| | 1405 | | STR | | 1406 | |------------------->| | 1407 | | STA | | 1408 | |<-------------------| | 1410 Figure 5: User disconnected due to exhausted account 1412 5.5. Server-Initiated Credit Re-Authorization 1414 The Diameter credit-control application supports server-initiated re- 1415 authorization. The credit-control server MAY optionally initiate the 1416 credit re-authorization by issuing a Re-Auth-Request (RAR) as defined 1417 in the Diameter base protocol [RFC6733]. The Auth- Application-Id in 1418 the RAR message is set to 4 to indicate Diameter Credit Control, and 1419 the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. 1421 Section 5.1.2 defines the feature to enable credit-control for 1422 multiple services within a single (sub-)session where the server can 1423 authorize credit usage at a different level of granularity. Further, 1424 the server may provide credit resources to multiple services or 1425 rating groups as a pool (see Section 5.1.2 for details and 1426 definitions). Therefore, the server, based on its service logic and 1427 its knowledge of the ongoing session, can decide to request credit 1428 re-authorization for a whole (sub-)session, a single credit pool, a 1429 single service, or a single rating-group. To request credit re- 1430 authorization for a credit pool, the server includes in the RAR 1431 message the G-S-U-Pool-Identifier AVP indicating the affected pool. 1432 To request credit re-authorization for a service or a rating-group, 1433 the server includes in the RAR message the Service-Identifier AVP or 1434 the Rating-Group AVP, respectively. To request credit re- 1435 authorization for all the ongoing services within the (sub-)session, 1436 the server includes none of the above mentioned AVPs in the RAR 1437 message. 1439 If a credit re-authorization is not already ongoing (i.e., the 1440 credit-control session is in Open state), a credit control client 1441 that receives an RAR message with Session-Id equal to a currently 1442 active credit-control session MUST acknowledge the request by sending 1443 the Re-Auth-Answer (RAA) message and MUST initiate the credit re- 1444 authorization toward the server by sending a Credit-Control-Request 1445 message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. 1446 The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the 1447 RAA message to indicate that an additional message (i.e., CCR message 1448 with the value UPDATE_REQUEST) is required to complete the procedure. 1449 If a quota was allocated to the service, the credit-control client 1450 MUST report the used quota in the Credit-Control-Request. Note that 1451 the end user does not need to be prompted for the credit re- 1452 authorization, since the credit re-authorization is transparent to 1453 the user (i.e., it takes place exclusively between the credit-control 1454 client and the credit-control server). 1456 Where multiple services in a user's session are supported, the 1457 procedure in the above paragraph will be executed at the granularity 1458 requested by the server in the RAR message. 1460 If credit re-authorization is ongoing at the time when the RAR 1461 message is received (i.e., RAR-CCR collision), the credit-control 1462 client successfully acknowledges the request but does not initiate a 1463 new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) 1464 SHOULD be used in the RAA message to indicate that a credit re- 1465 authorization procedure is already ongoing (i.e., the client was in 1466 PendingU state when the RAR was received). The credit-control server 1467 SHOULD process the Credit-Control-Request as if it was received in 1468 answer to the server initiated credit re-authorization, and should 1469 consider the server initiated credit re-authorization process 1470 successful upon reception of the Re-Auth-Answer message. 1472 When multiple services are supported in a user's session, the server 1473 may request credit re-authorization for a credit pool (or for the 1474 (sub-)session) while a credit re-authorization is already ongoing for 1475 some of the services or rating-groups. In this case, the client 1476 acknowledges the server request with an RAA message and MUST send a 1477 new Credit-Control-Request message to perform re-authorization for 1478 the remaining services/rating-groups. The Result-Code 2002 1479 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to 1480 indicate that an additional message (i.e., CCR message with value 1481 UPDATE_REQUEST) is required to complete the procedure. The server 1482 processes the received requests and returns an appropriate answer to 1483 both requests. 1485 The above-defined procedures are enabled for each of the possibly 1486 active Diameter credit-control sub-sessions. The server MAY request 1487 re-authorization for an active sub-session by including the CC-Sub- 1488 Session-Id AVP in the RAR message in addition to the Session-Id AVP. 1490 5.6. Graceful Service Termination 1492 When the user's account runs out of money, the user may not be 1493 allowed to compile additional chargeable events. However, the home 1494 service provider may offer some services; for instance, access to a 1495 service portal where it is possible to refill the account, for which 1496 the user is allowed to benefit for a limited time. The length of 1497 this time is usually dependent on the home service provider policy. 1499 This section defines the optional graceful service termination 1500 feature that MAY be supported by the credit-control server. Credit- 1501 control client implementations MUST support the Final-Unit-Indication 1502 with at least the teardown of the ongoing service session once the 1503 subscriber has consumed all the final granted units. 1505 Where independent credit-control of multiple services in a single 1506 credit-control (sub-)session is supported, it is possible to use the 1507 graceful service termination for each of the services/rating-groups 1508 independently. Naturally, the graceful service termination process 1509 defined in the following sub-sections will apply to the specific 1510 service/rating-group as requested by the server. 1512 In some service environments (e.g., NAS), the graceful service 1513 termination may be used to redirect the subscriber to a service 1514 portal for online balance refill or other services offered by the 1515 home service provider. In this case, the graceful termination 1516 process installs a set of packet filters to restrict the user's 1517 access capability only to/from the specified destinations. All the 1518 IP packets not matching the filters will be dropped or, possibly, re- 1519 directed to the service portal. The user may also be sent an 1520 appropriate notification as to why the access has been limited. 1521 These actions may be communicated explicitly from the server to the 1522 client or may be configured per-service at the client. Explicitly 1523 signaled redirect or restrict instructions always take precedence 1524 over configured ones. 1526 It is also possible use the graceful service termination to connect 1527 the prepaid user to a top-up server that plays an announcement and 1528 prompts the user to replenish the account. In this case, the credit- 1529 control server sends only the address of the top-up server where the 1530 prepaid user shall be connected after the final granted units have 1531 been consumed. An example of this is given in Appendix A (Flow VII). 1533 The credit-control server MAY initiate the graceful service 1534 termination by including the Final-Unit-Indication AVP in the Credit- 1535 Control-Answer to indicate that the message contains the final units 1536 for the service. 1538 When the credit-control client receives the Final-Unit-Indication AVP 1539 in the answer from the server, its behavior depends on the value 1540 indicated in the Final-Unit-Action AVP. The server may request the 1541 following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS. 1543 A following figure illustrates the graceful service termination 1544 procedure described in the following sub-sections. 1546 Diameter 1547 End User Service Element AAA Server CC Server 1548 (CC Client) 1549 | Service Delivery | | | 1550 |<----------------->| | | 1551 | |CCR(Update,Used-Units) | 1552 | |------------------->|CCR(Update,Used-Units) 1553 | : | |------------------->| 1554 | : | |CCA(Final-Unit,Action) 1555 | : | |<-------------------| 1556 | |CCA(Final-Unit,Action) | 1557 | |<-------------------| | 1558 | | | | 1559 | : | | | 1560 | : | | | 1561 | : | | | 1562 | /////////////// |CCR(Update,Used-Units) | 1563 |/Final Units End/->|------------------->|CCR(Update,Used-Units) 1564 |/Action and // | |------------------->| 1565 |/Restrictions // | | CCA(Validity-Time)| 1566 |/Start // | CCA(Validity-Time)|<-------------------| 1567 | ///////////// |<-------------------| | 1568 | : | | | 1569 | : | | | 1570 | Replenish Account +-------+ | 1571 |<-------------------------------------------->|Account| | 1572 | | | +-------+ | 1573 | | | RAR | 1574 | + | RAR |<===================| 1575 | | |<===================| | 1576 | | | RAA | | 1577 | ///////////// | |===================>| RAA | 1578 | /If supported / | | CCR(Update) |===================>| 1579 | /by CC Server/ | |===================>| CCR(Update) | 1580 | ///////////// | | |===================>| 1581 | | | | CCA(Granted-Unit)| 1582 | | | CCA(Granted-Unit)|<===================| 1583 | Restrictions ->+ |<===================| | 1584 | removed | | | 1585 | : | | | 1586 | OR | CCR(Update) | | 1587 | Validity-Time ->|------------------->| CCR(Update) | 1588 | expires | |------------------->| 1589 | | | CCA(Granted-Unit)| 1590 | | CCA(Granted-Unit)|<-------------------| 1591 | Restrictions ->|<-------------------| | 1592 | removed | | | 1594 Figure 6: Optional graceful service termination procedure 1596 5.6.1. Terminate Action 1598 The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does 1599 not include any other information. When the subscriber has consumed 1600 the final granted units, the service element MUST terminate the 1601 service. This is the default handling applicable whenever the 1602 credit-control client receives an unsupported Final-Unit-Action value 1603 and MUST be supported by all the Diameter credit-control client 1604 implementations conforming to this specification. A final Credit- 1605 Control-Request message to the credit-control server MUST be sent if 1606 the Final-Unit-Indication AVP indicating action TERMINATE was present 1607 at command level. The CC-Request-Type AVP in the request is set to 1608 the value TERMINATION_REQUEST. 1610 5.6.2. Redirect Action 1612 The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT 1613 indicates to the service element supporting this action that, upon 1614 consumption of the final granted units, the user MUST be re-directed 1615 to the address specified in the Redirect-Server AVP as follows. 1617 The credit-control server sends the Redirect-Server AVP in the 1618 Credit-Control-Answer message. In such a case, the service element 1619 MUST redirect or connect the user to the destination specified in the 1620 Redirect-Server AVP, if possible. When the end user is redirected 1621 (by using protocols others than Diameter) to the specified server or 1622 connected to the top-up server, an additional authorization (and 1623 possibly authentication) may be needed before the subscriber can 1624 replenish the account; however, this is out of the scope of this 1625 specification. 1627 In addition to the Redirect-Server AVP, the credit-control server MAY 1628 include one or more Restriction-Filter-Rule AVPs or one or more 1629 Filter-Id AVPs in the Credit-Control-Answer message to enable the 1630 user to access other services (for example, zero-rated services). In 1631 such a case, the access device MUST drop all the packets not matching 1632 the IP filters specified in the Credit-Control-Answer message and, if 1633 possible, redirect the user to the destination specified in the 1634 Redirect-Server AVP. 1636 An entity other than the credit-control server may provision the 1637 access device with appropriate IP packet filters to be used in 1638 conjunction with the Diameter credit-control application. This case 1639 is considered in Section 5.6.3. 1641 When the final granted units have been consumed, the credit-control 1642 client MUST perform an intermediate interrogation. The purpose of 1643 this interrogation is to indicate to the credit-control server that 1644 the specified action started and to report the used units. The 1645 credit-control server MUST deduct the used amount from the end user's 1646 account but MUST NOT make a new credit reservation. The credit- 1647 control client, however, may send intermediate interrogations before 1648 all the final granted units have been consumed for which rating and 1649 money reservation may be needed; for instance, upon Validity-Time 1650 expires or upon mid-session service events that affect the rating of 1651 the current service. Therefore, the credit-control client MUST NOT 1652 include any rating related AVP in the request sent once all the final 1653 granted units have been consumed as an indication to the server that 1654 the requested final unit action started, rating and money reservation 1655 are not required (when the Multiple-Services-Credit-Control AVP is 1656 used, the Service-Identifier or Rating-Group AVPs is included to 1657 indicate the concerned services). Naturally, the Credit-Control- 1658 Answer message does not contain any granted service unit and MUST 1659 include the Validity-Time AVP to indicate to the credit-control 1660 client how long the subscriber is allowed to use network resources 1661 before a new intermediate interrogation is sent to the server. 1663 At the expiry of Validity-Time, the credit-control client sends a 1664 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does 1665 not include the Used-Service-Unit AVP, as there is no allotted quota 1666 to report. The credit-control server processes the request and MUST 1667 perform the credit reservation. If during this time the subscriber 1668 did not replenish his/her account, whether he/she will be 1669 disconnected or will be granted access to services not controlled by 1670 a credit-control server for an unlimited time is dependent on the 1671 home service provider policy (note: the latter option implies that 1672 the service element should not remove the restriction filters upon 1673 termination of the credit-control). The server will return the 1674 appropriate Result-Code (see Section 9.1) in the Credit-Control- 1675 Answer message in order to implement the policy-defined action. 1676 Otherwise, new quota will be returned, the service element MUST 1677 remove all the possible restrictions activated by the graceful 1678 service termination process and continue the credit-control session 1679 and service session as usual. 1681 The credit-control client may not wait until the expiration of the 1682 Validity-Time and may send a spontaneous update (a new Credit- 1683 Control-Request) if the service element can determine, for instance, 1684 that communication between the end user and the top-up server took 1685 place. An example of this is given in Appendix A (Figure A.8). 1687 Note that the credit-control server may already have initiated the 1688 above-described process for the first interrogation. However, the 1689 user's account might be empty when this first interrogation is 1690 performed. In this case, the subscriber can be offered a chance to 1691 replenish the account and continue the service. The credit-control 1692 client receives a Credit-Control-Answer or service specific 1693 authorization answer with the Final-Unit-Indication and Validity-Time 1694 AVPs but no Granted-Service-Unit AVP. It immediately starts the 1695 graceful service termination without sending any message to the 1696 server. An example of this case is illustrated in Appendix A. 1698 5.6.3. Restrict Access Action 1700 A Final-Unit-Indication AVP with the Final-Unit-Action 1701 RESTRICT_ACCESS indicates to the device supporting this action that 1702 the user's access MUST be restricted according to the IP packet 1703 filters given in the Restriction-Filter-Rule AVP(s) or according to 1704 the IP packet filters identified by the Filter-Id AVP(s). The 1705 credit-control server SHOULD include either the Restriction-Filter- 1706 Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message. 1708 An entity other than the credit-control server may provision the 1709 access device with appropriate IP packet filters to be used in 1710 conjunction with the Diameter credit-control application. Such an 1711 entity may, for instance, configure the access device with IP flows 1712 to be passed when the Diameter credit-control application indicates 1713 RESTRICT_ACCESS or REDIRECT. The access device passes IP packets 1714 according to the filter rules that may have been received in the 1715 Credit-Control-Answer message in addition to those that may have been 1716 configured by the other entity. However, when the user's account 1717 cannot cover the cost of the requested service, the action taken is 1718 the responsibility of the credit-control server that controls the 1719 prepaid subscriber. 1721 If another entity working in conjunction with the Diameter credit- 1722 control application already provisions the access device with all the 1723 required filter rules for the end user, the credit-control server 1724 presumably need not send any additional filter. Therefore, it is 1725 RECOMMENDED that credit-control server implementations supporting the 1726 graceful service termination be configurable for sending the 1727 Restriction-Filter-Rule AVP, the Filter-Id AVP, or none of the above. 1729 When the final granted units have been consumed, the credit-control 1730 client MUST perform an intermediate interrogation. The credit- 1731 control client and the credit-control server process this 1732 intermediate interrogation and execute subsequent procedures, as 1733 specified in the previous section for the REDIRECT action. 1735 The credit-control server may initiate the graceful service 1736 termination with action RESTRICT_ACCESS already for the first 1737 interrogation, as specified in the previous section for the REDIRECT 1738 action. 1740 5.6.4. Usage of the Server-Initiated Credit Re-Authorization 1742 Once the subscriber replenishes the account, she presumably expects 1743 all the restrictions placed by the graceful termination procedure to 1744 be removed immediately and unlimited service' access to be resumed. 1745 For the best user experience, the credit-control server 1746 implementation MAY support the server-initiated credit re- 1747 authorization (see Section 5.5). In such a case, upon the successful 1748 account top-up, the credit-control server sends the Re-Auth-Request 1749 (RAR) message to solicit the credit re-authorization. The credit- 1750 control client initiates the credit re-authorization by sending the 1751 Credit-Control-Request message with the CC-Request-Type AVP set to 1752 the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included 1753 in the request, as there is no allotted quota to report. The 1754 Requested-Service-Unit AVP MAY be included in the request. After the 1755 credit-control client successfully receives the Credit-Control-Answer 1756 with new Granted-Service-Unit, all the possible restrictions 1757 activated for the purpose of the graceful service termination MUST be 1758 removed in the service element. The credit-control session and the 1759 service session continue as usual. 1761 5.7. Failure Procedures 1763 The Credit-Control-Failure-Handling AVP (CCFH), as described in this 1764 section, determines the behavior of the credit-control client in 1765 fault situations. The CCFH may be received from the Diameter home 1766 AAA server, from the credit-control server, or may be configured 1767 locally. The CCFH value received from the home AAA server overrides 1768 the locally configured value. The CCFH value received from the 1769 credit-control server in the Credit-Control-Answer message always 1770 overrides any existing value. 1772 The authorization server MAY include the Accounting-Realtime-Required 1773 AVP to determine what to do if the sending of accounting records to 1774 the accounting server has been temporarily prevented, as defined in 1775 [RFC6733]. It is RECOMMENDED that the client complement the credit- 1776 control failure procedures with backup accounting flow toward an 1777 accounting server. By using different combinations of Accounting- 1778 Realtime-Required and Credit-Control-Failure-Handling AVPs, different 1779 safety levels can be built. For example, by choosing a Credit- 1780 Control-Failure-Handling AVP equal to CONTINUE for the credit-control 1781 flow and a Accounting-Realtime-Required AVP equal to 1782 DELIVER_AND_GRANT for the accounting flow, the service can be granted 1783 to the end user even if the connection to the credit-control server 1784 is down, as long as the accounting server is able to collect the 1785 accounting information and information exchange is taking place 1786 between the accounting server and credit-control server. 1788 As the credit-control application is based on real-time bi- 1789 directional communication between the credit-control client and the 1790 credit-control server, the usage of alternative destinations and the 1791 buffering of messages may not be sufficient in the event of 1792 communication failures. Because the credit-control server has to 1793 maintain session states, moving the credit-control message stream to 1794 a backup server requires a complex context transfer solution. 1795 Whether the credit-control message stream is moved to a backup 1796 credit-control server during an ongoing credit-control session 1797 depends on the value of the CC-Session-Failover AVP. However, 1798 failover may occur at any point in the path between the credit- 1799 control client and the credit-control server if a transport failure 1800 is detected with a peer, as described in [RFC6733]. As a 1801 consequence, the credit-control server might receive duplicate 1802 messages. These duplicates or out of sequence messages can be 1803 detected in the credit-control server based on the credit-control 1804 server session state machine (Section 7), Session-Id AVP, and CC- 1805 Request-Number AVP. 1807 If a failure occurs during an ongoing credit-control session, the 1808 credit-control client may move the credit-control message stream to 1809 an alternative server if the CC-server indicated FAILOVER_SUPPORTED 1810 in the CC-Session-Failover AVP. A secondary credit-control server 1811 name, either received from the home Diameter AAA server or configured 1812 locally, can be used as an address of the backup server. If the CC- 1813 Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- 1814 control message stream MUST NOT be moved to a backup server. 1816 For new credit-control sessions, failover to an alternative credit- 1817 control server SHOULD be performed if possible. For instance, if an 1818 implementation of the credit-control client can determine primary 1819 credit-control server unavailability, it can establish the new 1820 credit-control sessions with a possibly available secondary credit- 1821 control server. 1823 The AAA transport profile [RFC3539] defines the application layer 1824 watchdog algorithm that enables failover from a peer that has failed 1825 and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The 1826 recommended default initial value for Tw (Twinit) is 30 seconds. 1827 Twinit may be set as low as 6 seconds; however, according to 1828 [RFC3539], setting too low a value for Twinit is likely to result in 1829 an increased probability of duplicates, as well as an increase in 1830 spurious failover and failback attempts. The Diameter base protocol 1831 is common to several different types of Diameter AAA applications 1832 that may be run in the same service element. Therefore, tuning the 1833 timer Twinit to a lower value in order to satisfy the requirements of 1834 real-time applications, such as the Diameter credit-control 1835 application, will certainly cause the above mentioned problems. For 1836 prepaid services, however, the end user expects an answer from the 1837 network in a reasonable time. Thus, the Diameter credit-control 1838 client will react faster than would the underlying base protocol. 1839 Therefore this specification defines the timer Tx that is used by the 1840 credit-control client (as defined in Section 13) to supervise the 1841 communication with the credit-control server. When the timer Tx 1842 elapses, the credit-control client takes an action to the end user 1843 according to the Credit-Control-Failure-Handling AVP. 1845 When Tx expires, the Diameter credit-control client always terminates 1846 the service if the Credit-Control-Failure-Handling (CCFH) AVP is set 1847 to the value TERMINATE. The credit-control session may be moved to 1848 an alternative server only if a protocol error DIAMETER_TOO_BUSY or 1849 DIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore, 1850 the value TERMINATE is not appropriate if proper failover behavior is 1851 desired. 1853 If the Credit-Control-Failure-Handling AVP is set to the value 1854 CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the 1855 end user when the timer Tx expires. An answer message with granted- 1856 units may arrive later if the base protocol transport failover 1857 occurred in the path to the credit-control server. (The Twinit 1858 default value is 3 times more than the Tx recommended value.) The 1859 credit-control client SHOULD grant the service to the end user, start 1860 monitoring the resource usage, and wait for the possible late answer 1861 until the timeout of the request (e.g., 120 seconds). If the request 1862 fails and the CC-Session-Failover AVP is set to 1863 FAILOVER_NOT_SUPPORTED, the credit-control client terminates or 1864 continues the service depending on the value set in the CCFH and MUST 1865 free all the reserved resources for the credit-control session. If 1866 the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is 1867 received or the request times out and the CC-Session-Failover AVP is 1868 set to FAILOVER_SUPPORTED, the credit-control client MAY send the 1869 request to a backup server, if possible. If the credit-control 1870 client receives a successful answer from the backup server, it 1871 continues the credit-control session with such a server. If the re- 1872 transmitted request also fails, the credit-control client terminates 1873 or continues the service depending on the value set in the CCFH and 1874 MUST free all the reserved resources for the credit-control session. 1876 If a communication failure occurs during the graceful service 1877 termination procedure, the service element SHOULD always terminate 1878 the ongoing service session. 1880 If the credit-control server detects a failure during an ongoing 1881 credit-control session, it will terminate the credit-control session 1882 and return the reserved units back to the end user's account. 1884 The supervision session timer Tcc (as defined in Section 13) is used 1885 in the credit-control server to supervise the credit-control session. 1887 In order to support failover between credit-control servers, 1888 information transfer about the credit-control session and account 1889 state SHOULD take place between the primary and the secondary credit- 1890 control server. Implementations supporting the credit-control 1891 session failover MUST also ensure proper detection of duplicate or 1892 out of sequence messages. The communication between the servers is 1893 regarded as an implementation issue and is outside of the scope of 1894 this specification. 1896 6. One Time Event 1898 The one-time event is used when there is no need to maintain any 1899 state in the Diameter credit-control server; for example, enquiring 1900 about the price of the service. The use of a one-time event implies 1901 that the user has been authenticated and authorized beforehand. 1903 The one time event can be used when the credit-control client wants 1904 to know the cost of the service event or to check the account balance 1905 without any credit-reservation. It can also be used for refunding 1906 service units on the user's account or for direct debiting withouts 1907 any credit-reservation. The one time event is shown in Figure 7. 1909 Diameter 1910 End User Service Element AAA Server CC Server 1911 (CC Client) 1912 | Service Request | | | 1913 |------------------>| | | 1914 | | CCR(Event) | | 1915 | |------------------->| CCR(Event) | 1916 | | |------------------->| 1917 | | | CCA(Granted-Units)| 1918 | | CCA(Granted-Units)|<-------------------| 1919 | Service Delivery |<-------------------| | 1920 |<----------------->| | | 1922 Figure 7: One time event 1924 In environments such as the 3GPP architecture, the one time event can 1925 be sent from the service element directly to the credit-control 1926 server. 1928 6.1. Service Price Enquiry 1930 The credit-control client may need to know the price of the services 1931 event. Services offered by application service providers whose 1932 prices are not known in the credit-control client might exist. The 1933 end user might also want to get an estimation of the price of a 1934 service event before requesting it. 1936 A Diameter credit-control client requesting the cost information MUST 1937 set the CC-Request-Type AVP equal to EVENT_REQUEST, include the 1938 Requested-Action AVP set to PRICE_ENQUIRY, and set the requested 1939 service event information into the Service-Identifier AVP in the 1940 Credit-Control-Request message. Additional service event information 1941 may be sent as service specific AVPs or within the Service- 1942 Parameter-Info AVP. The Service-Context-Id AVP indicates the service 1943 specific document applicable to the request. 1945 The credit-control server calculates the cost of the requested 1946 service event, but it does not perform any account balance check or 1947 credit-reservation from the account. 1949 The estimated cost of the requested service event is returned to the 1950 credit-control client in the Cost-Information AVP in the Credit- 1951 Control-Answer message. 1953 6.2. Balance Check 1955 The Diameter credit-control client may only have to verify that the 1956 end user's account balance covers the cost of a certain service 1957 without reserving any units from the account at the time of the 1958 inquiry. This method does not guarantee that credit would be left 1959 when the Diameter credit-control client requests the debiting of the 1960 account with a separate request. 1962 A Diameter credit-control client requesting the balance check MUST 1963 set the CC-Request-Type AVP equal to EVENT_REQUEST, include a 1964 Requested-Action AVP set to CHECK_BALANCE, and include the 1965 Subscription-Id AVP in order to identify the end user in the credit- 1966 control server. The Service-Context-Id AVP indicates the service 1967 specific document applicable to the request. 1969 The credit-control server makes the balance check, but it does not 1970 make any credit-reservation from the account. 1972 The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to 1973 the credit-control client in the Check-Balance-Result AVP in the 1974 Credit-Control-Answer message. 1976 6.3. Direct Debiting 1978 There are certain service events for which service execution is 1979 always successful in the service environment. The delay between the 1980 service invocation and the actual service delivery to the end user 1981 can be sufficiently long that the use of the session-based credit- 1982 control would lead to unreasonably long credit-control sessions. In 1983 these cases, the Diameter credit-control client can use the one-time 1984 event scenario for direct debiting. The Diameter credit-control 1985 client SHOULD be sure that the requested service event execution 1986 would be successful when this scenario is used. 1988 In the Credit-Control-Request message, the CC-Request-Type is set to 1989 the value EVENT_REQUEST and the Requested-Action AVP is set to 1990 DIRECT_DEBITING. The Subscription-Id AVP SHOULD be included to 1991 identify the end user in the credit-control server. The Event- 1992 Timestamp AVP SHOULD be included in the request and contain the time 1993 when the service event is requested in the service element. The 1994 Service-Context-Id AVP indicates the service specific document 1995 applicable to the request. 1997 The Diameter credit-control client MAY include the monetary amount to 1998 be charged in the Requested-Service-Unit AVP, if it knows the cost of 1999 the service event. If the Diameter credit-control client does not 2000 know the cost of the service event, the Requested-Service-Unit AVP 2001 MAY contain the number of requested service events. The Service- 2002 Identifier AVP always indicates the service concerned. Additional 2003 service event information to be rated MAY be sent as service specific 2004 AVPs or within the Service-Parameter-Info AVP. 2006 The credit-control server SHOULD rate the service event and deduct 2007 the corresponding monetary amount from the end user's account. If 2008 the type of the Requested-Service-Unit AVP is money, no rating is 2009 needed, but the corresponding monetary amount is deducted from the 2010 end user's account. 2012 The credit-control server returns the Granted-Service-Unit AVP in the 2013 Credit-Control-Answer message to the Diameter credit-control client. 2014 The Granted-Service-Unit AVP contains the amount of service units 2015 that the Diameter credit-control client can provide to the end user. 2016 The type of the Granted-Service-Unit can be time, volume, service 2017 specific, or money, depending on the type of service event. 2019 If the credit-control server determines that no credit-control is 2020 needed for the service, it can include the result code indicating 2021 that the credit-control is not applicable (e.g., service is free of 2022 charge). 2024 For informative purposes, the Credit-Control-Answer message MAY also 2025 include the Cost-Information AVP containing the estimated total cost 2026 of the requested service. 2028 6.4. Refund 2030 Some services may refund service units to the end user's account; for 2031 example, gaming services. 2033 The credit-control client MUST set CC-Request-Type to the value 2034 EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the 2035 Credit-Control-Request message. The Subscription-Id AVP SHOULD be 2036 included to identify the end user in the credit-control server. The 2037 Service-Context-Id AVP indicates the service specific document 2038 applicable to the request. 2040 The Diameter credit-control client MAY include the monetary amount to 2041 be refunded in the Requested-Service-Unit AVP. The Service- 2042 Identifier AVP always indicates the concerned service. If the 2043 Diameter credit-control client does not know the monetary amount to 2044 be refunded, in addition to the Service-Identifier AVP it MAY send 2045 service specific AVPs or the Service-Parameter-Info AVP containing 2046 additional service event information to be rated. 2048 For informative purposes, the Credit-Control-Answer message MAY also 2049 include the Cost-Information AVP containing the estimated monetary 2050 amount of refunded unit. 2052 6.5. Failure Procedure 2054 Failover to an alternative credit-control server is allowed for a one 2055 time event, as the server is not maintaining session states. For 2056 instance, if the credit-control client receives a protocol error 2057 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the 2058 request to an alternative server, if possible. There MAY be protocol 2059 transparent Diameter relays and redirect agents or Diameter credit- 2060 control proxies between the credit-control client and credit-control 2061 server. Failover may occur at any point in the path between the 2062 credit-control client and the credit-control server if a transport 2063 failure is detected with a peer, as described in [RFC6733]. Because 2064 there can be duplicate requests for various reasons, the credit- 2065 control server is responsible for real time duplicate detection. 2066 Implementation issues for duplicate detection are discussed in 2067 [RFC6733], Appendix C. 2069 When the credit-control client detects a communication failure with 2070 the credit-control server, its behavior depends on the requested 2071 action. The timer Tx (as defined in Section 13) is used in the 2072 credit-control client to supervise the communication with the credit- 2073 control server. 2075 If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and 2076 communication failure is detected, the credit-control client SHOULD 2077 forward the request messages to an alternative credit-control server, 2078 if possible. The secondary credit-control server name, if received 2079 from the home Diameter AAA server, can be used as an address of 2080 backup server. 2082 If the requested action is DIRECT_DEBITING, the Direct-Debiting- 2083 Failure-Handling AVP (DDFH) controls the credit-control client's 2084 behavior. The DDFH may be received from the home Diameter AAA server 2085 or may be locally configured. The credit-control server may also 2086 send the DDFH in any CCA message to be used for direct debiting 2087 events compiled thereafter. The DDFH value received from the home 2088 Diameter AAA server overrides the locally configured value, and the 2089 DDFH value received from the credit-control server in a Credit- 2090 Control-Answer message always overrides any existing value. 2092 If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client 2093 SHOULD NOT grant the service if it can determine, eventually after a 2094 possible re-transmission attempt to an alternative credit-control 2095 server, from the result code or error code in the answer message that 2096 units have not been debited. Otherwise, the credit-control client 2097 SHOULD grant the service to the end user and store the request in the 2098 credit-control application level non-volatile storage. (Note that 2099 re-sending the request at a later time is not a guarantee that the 2100 service will be debited, as the user's account may be empty when the 2101 server successfully processes the request.) The credit-control 2102 client MUST mark these request messages as possible duplicates by 2103 setting the T-flag in the command header as described in [RFC6733], 2104 Section 3. 2106 If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 2107 service SHOULD be granted, even if credit-control messages cannot be 2108 delivered and messages are not buffered. 2110 If the timer Tx expires, the credit-control client MUST continue the 2111 service and wait for a possible late answer. If the request times 2112 out, the credit-control client re-transmits the request (marked with 2113 T-flag) to a backup credit-control server, if possible. If the re- 2114 transmitted request also times out, or if a temporary error is 2115 received in answer, the credit-control client buffers the request if 2116 the value of the Direct-Debiting-Failure-Handling AVP is set to 2117 TERMINATE_OR_BUFFER. If a failed answer is received for the re- 2118 transmitted request, the credit-control client frees all the 2119 resources reserved for the event message and deletes the request 2120 regardless of the value of the DDFH. 2122 The Credit-Control-Request with the requested action REFUND_ACCOUNT 2123 should always be stored in the credit-control application level non- 2124 volatile storage in case of temporary failure. The credit-control 2125 client MUST mark the re-transmitted request message as a possible 2126 duplicate by setting the T-flag in the command header as described in 2127 [RFC6733], Section 3. 2129 For stored requests, the implementation may choose to limit the 2130 number of re-transmission attempts and to define a re-transmission 2131 interval. 2133 Note that only one place in the credit-control system SHOULD be 2134 responsible for duplicate detection. If there is only one credit- 2135 control server within the given realm, the credit-control server may 2136 perform duplicate detection. If there is more than one credit- 2137 control server in a given realm, only one entity in the credit- 2138 control system should be responsible, to ensure that the end user's 2139 account is not debited or credited multiple times for the same 2140 service event. 2142 7. Credit-Control Application State Machine 2144 This section defines the credit-control application state machine. 2146 The first four state machines are to be observed by credit-control 2147 clients. The first one describes the session-based credit-control 2148 when the first interrogation is executed as part of the 2149 authorization/authentication process. The second describes the 2150 session-based credit-control when the first interrogation is executed 2151 after the authorization/authentication process. The requirements as 2152 to what state machines have to be supported are discussed in 2153 Section 5.2. 2155 The third state machine describes the session-based credit-control 2156 for the intermediate and final interrogations. The fourth one 2157 describes the event-based credit-control. These latter state 2158 machines are to be observed by all implementations that conform to 2159 this specification. 2161 The fifth state machine describes the credit-control session from a 2162 credit-control server perspective. 2164 Any event not listed in the state machines MUST be considered an 2165 error condition, and a corresponding answer, if applicable, MUST be 2166 returned to the originator of the message. 2168 In the state table, the event 'Failure to send' means that the 2169 Diameter credit-control client is unable to communicate with the 2170 desired destination or, if failover procedure is supported, with a 2171 possibly defined alternative destination (e.g., the request times out 2172 and the answer message is not received). This could be due to the 2173 peer being down, or due to a physical link failure in the path to or 2174 from the credit-control server. 2176 The event 'Temporary error' means that the Diameter credit-control 2177 client received a protocol error notification (DIAMETER_TOO_BUSY, 2178 DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result- 2179 Code AVP of the Credit-Control-Answer command. The above protocol 2180 error notification may ultimately be received in answer to the re- 2181 transmitted request to a defined alternative destination, if failover 2182 is supported. 2184 The event 'Failed answer' means that the Diameter credit-control 2185 client received non-transient failure (permanent failure) 2186 notification in the Credit-Control-Answer command. The above 2187 permanent failure notification may ultimately be received in answer 2188 to the re-transmitted request to a defined alternative destination, 2189 if failover is supported. 2191 The action 'store request' means that a request is stored in the 2192 credit-control application level non-volatile storage. 2194 The event 'Not successfully processed' means that the credit-control 2195 server could not process the message; e.g., due to an unknown end 2196 user, account being empty, or errors defined in [RFC6733]. 2198 The event 'User service terminated' can be triggered by various 2199 reasons, e.g., normal user termination, network failure, and ASR 2200 (Abort-Session-Request). The Termination-Cause AVP contains 2201 information about the termination reason, as specified in [RFC6733]. 2203 The Tx timer, which is used to control the waiting time in the 2204 credit-control client in the Pending state, is stopped upon exit of 2205 the Pending state. The stopping of the Tx timer is omitted in the 2206 state machine when the new state is Idle, as moving to Idle state 2207 implies the clearing of the session and all the variables associated 2208 to it. 2210 The states PendingI, PendingU, PendingT, PendingE, and PendingB stand 2211 for pending states to wait for an answer to a credit-control request 2212 related to Initial, Update, Termination, Event, or Buffered request, 2213 respectively. 2215 The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling 2216 and Direct-Debiting-Failure-Handling, respectively. 2218 In the following state machine table, the failover to a secondary 2219 server upon 'Temporary error' or 'Failure to send' is not explicitly 2220 described. Moving an ongoing credit-control message stream to an 2221 alternative server is, however, possible if the CC-Session-Failover 2222 AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7. 2224 Re-sending a credit-control event to an alternative server is 2225 supported as described in Section 6.5. 2227 +----------+-------------------------------+-------------+----------+ 2228 | State | Event | Action | New | 2229 | | | | State | 2230 +----------+-------------------------------+-------------+----------+ 2231 | Idle | Client or device requests | Send AA | PendingI | 2232 | | access/service | request | | 2233 | | | with added | | 2234 | | | CC AVPs, | | 2235 | | | start Tx | | 2236 | PendingI | Successful AA req. answer | Grant | Open | 2237 | | received | service to | | 2238 | | | end user, | | 2239 | | | stop Tx | | 2240 | PendingI | Tx expired | Disconnect | Idle | 2241 | | | user/dev | | 2242 | PendingI | Failed AA answer received | Disconnect | Idle | 2243 | | | user/dev | | 2244 | PendingI | AA answer received with | Grant | Idle | 2245 | | result code equal to | service to | | 2246 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2247 | PendingI | User service terminated | Queue | PendingI | 2248 | | | termination | | 2249 | | | event | | 2250 | PendingI | Change in rating condition | Queue | PendingI | 2251 | | | changed | | 2252 | | | rating | | 2253 | | | condition | | 2254 | | | event | | 2255 +----------+-------------------------------+-------------+----------+ 2257 Table 2: CLIENT, SESSION BASED for the first interrogation with AA 2258 request 2260 +----------+-------------------------------+-------------+----------+ 2261 | State | Event | Action | New | 2262 | | | | State | 2263 +----------+-------------------------------+-------------+----------+ 2264 | Idle | Client or device requests | Send CC | PendingI | 2265 | | access/service | initial | | 2266 | | | req., start | | 2267 | | | Tx | | 2268 | PendingI | Successful CC intial answer | Stop Tx | Open | 2269 | | received | | | 2270 | PendingI | Failure to send, or temporary | Grant | Idle | 2271 | | error and CCFH equal to | service to | | 2272 | | CONTINUE | end user | | 2273 | PendingI | Failure to send, or temporary | Terminate | Idle | 2274 | | error and CCFH equal to | end user's | | 2275 | | TERMINATEor to | service | | 2276 | | RETRY_AND_TERMINATE | | | 2277 | PendingI | Tx expired and CCFH equal to | Terminate | Idle | 2278 | | TERMINATE | end user's | | 2279 | | | service | | 2280 | PendingI | Tx expired and CCFH equal to | Grant | Idle | 2281 | | CONTINUE or to | service to | | 2282 | | RETRY_AND_TERMINATE | end user | | 2283 | PendingI | CC initial answer received | Terminate | Idle | 2284 | | with result code | end user's | | 2285 | | END_USER_SERVICE_DENIED or | service | | 2286 | | USER_UNKNOWN | | | 2287 | PendingI | CC initial answer received | Grant | Idle | 2288 | | with result code equal to | service to | | 2289 | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | 2290 | PendingI | Failed CC initial answer | Grant | Idle | 2291 | | received and CCFH equal to | service to | | 2292 | | CONTINUE | end user | | 2293 | PendingI | Failed CC initial answer | Terminate | Idle | 2294 | | received and CCFH equal to | end user's | | 2295 | | TERMINATE or to | service | | 2296 | | RETRY_AND_TERMINATE | | | 2297 | PendingI | User service terminated | Queue | PendingI | 2298 | | | termination | | 2299 | | | event | | 2300 | PendingI | Change in rating condition | Queue | PendingI | 2301 | | | changed | | 2302 | | | rating | | 2303 | | | condition | | 2304 | | | event | | 2305 +----------+-------------------------------+-------------+----------+ 2307 Table 3: CLIENT, SESSION BASED for the first interrogation with CCR 2309 +----------+-------------------------------+-------------+----------+ 2310 | State | Event | Action | New | 2311 | | | | State | 2312 +----------+-------------------------------+-------------+----------+ 2313 | Open | Granted unit elapses and no | Send CC | PendingU | 2314 | | final unit indication | update req. | | 2315 | | received | | | 2316 | Open | Granted unit elapses and | Terminate | PendingT | 2317 | | final unit action equal to | end user's | | 2318 | | TERMINATE received | service, | | 2319 | | | send CC | | 2320 | | | termination | | 2321 | | | req. | | 2322 | Open | Change in rating condition in | Send CC | PendingU | 2323 | | queue | update | | 2324 | | | req., Start | | 2325 | | | Tx | | 2326 | Open | Service terminated in queue | Send CC | PendingT | 2327 | | | termination | | 2328 | | | req. | | 2329 | Open | Change in rating condition or | Send CC | PendingU | 2330 | | Validity-Time elapses | update | | 2331 | | | req., Start | | 2332 | | | Tx | | 2333 | Open | User service terminated | Send CC | PendingT | 2334 | | | termination | | 2335 | | | req. | | 2336 | Open | RAR received | Send RAA | PendingU | 2337 | | | followed by | | 2338 | | | CC update | | 2339 | | | req., start | | 2340 | | | Tx | | 2341 | PendingU | Successful CC update answer | Stop Tx | Open | 2342 | | received | | | 2343 | PendingU | Failure to send, or temporary | Grant | Idle | 2344 | | error and CCFH equal to | service to | | 2345 | | CONTINUE | end user | | 2346 | PendingU | Failure to send, or temporary | Terminate | Idle | 2347 | | error and CCFH equal to | end user's | | 2348 | | TERMINATE or to | service | | 2349 | | RETRY_AND_TERMINATE | | | 2350 | PendingU | Tx expired and CCFH equal to | Terminate | Idle | 2351 | | TERMINATE | end user's | | 2352 | | | service | | 2353 | PendingU | Tx expired and CCFH equal to | Grant | PendingU | 2354 | | CONTINUE or to | service to | | 2355 | | RETRY_AND_TERMINATE | end user | | 2356 | PendingU | CC update answer received | Terminate | Idle | 2357 | | with result code | end user's | | 2358 | | END_USER_SERVICE_DENIED | service | | 2359 | PendingU | CC update answer received | Terminate | Idle | 2360 | | with result code equal to | end user's | | 2361 | | CREDIT_CONTROL_NOT_APPLICABLE | service | | 2362 | PendingU | Failed CC update answer | Grant | Idle | 2363 | | received and CCFH equal to | service to | | 2364 | | CONTINUE | end user | | 2365 | PendingU | Failed CC update answer | Terminate | Idle | 2366 | | received and CCFH equal to | end user's | | 2367 | | TERMINATE or to | service | | 2368 | | RETRY_AND_TERMINATE | | | 2369 | PendingU | User service terminated | Queue | PendingU | 2370 | | | termination | | 2371 | | | event | | 2372 | PendingU | Change in rating condition | Queue | PendingU | 2373 | | | changed | | 2374 | | | rating | | 2375 | | | condition | | 2376 | | | event | | 2377 | PendingU | RAR received | Send RAA | PendingU | 2378 | PendingT | Successful CC termination | | Idle | 2379 | | answer received | | | 2380 | PendingT | Failure to send, temporary | | Idle | 2381 | | error, or failed answer | | | 2382 | PendingT | Change in rating condition | | PendingT | 2383 +----------+-------------------------------+-------------+----------+ 2385 Table 4: CLIENT, SESSION BASED for intermediate and final 2386 interrogations 2388 +----------+--------------------------------+------------+----------+ 2389 | State | Event | Action | New | 2390 | | | | State | 2391 +----------+--------------------------------+------------+----------+ 2392 | Idle | Client or device requests a | Send CC | PendingE | 2393 | | one-time service | event | | 2394 | | | req., | | 2395 | | | Start Tx | | 2396 | Idle | Request in storage | Send | PendingB | 2397 | | | stored | | 2398 | | | request | | 2399 | PendingE | Grant service to end user | Send | Idle | 2400 | | | stored | | 2401 | | | request | | 2402 | PendingE | Failure to send, temporary | Indicate | Idle | 2403 | | error, failed CC event answer | service | | 2404 | | received, or Tx expired; | error | | 2405 | | requested action CHECK_BALANCE | | | 2406 | | or PRICE_ENQUIRY | | | 2407 | PendingE | CC event answer received with | Terminate | Idle | 2408 | | result code | end user's | | 2409 | | END_USER_SERVICE_DENIED or | service | | 2410 | | USER_UNKNOWN and Tx running | | | 2411 | PendingE | CC event answer received with | Grant | Idle | 2412 | | result code | service to | | 2413 | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | | 2414 | | requested action | | | 2415 | | DIRECT_DEBITING | | | 2416 | PendingE | Failure to send, temporary | Grant | Idle | 2417 | | error, failed CC event answer | service to | | 2418 | | received; requested action | end user | | 2419 | | DIRECT_DEBITING; DDFH equal to | | | 2420 | | CONTINUE | | | 2421 | PendingE | Failed CC event answer | Terminate | Idle | 2422 | | received or temporary error; | end user's | | 2423 | | requested action | service | | 2424 | | DIRECT_DEBITING; DDFH equal to | | | 2425 | | TERMINATE_OR_BUFFER and Tx | | | 2426 | | running | | | 2427 | PendingE | Tx expired; requested action | Grant | PendingE | 2428 | | DIRECT_DEBITING | service to | | 2429 | | | end user | | 2430 | PendingE | Failure to send; requested | Store | Idle | 2431 | | action DIRECT_DEBITING; DDFH | request | | 2432 | | equal to TERMINATE_OR_BUFFER | with | | 2433 | | | T-flag | | 2434 | PendingE | Failure to send; requested | Store | Idle | 2435 | | action DIRECT_DEBITING; DDFH | request | | 2436 | | equal to TERMINATE_OR_BUFFER | with | | 2437 | | | T-flag | | 2438 | PendingE | Temporary error; requested | Store | Idle | 2439 | | action DIRECT_DEBITING; DDFH | request | | 2440 | | equal to TERMINATE_OR_BUFFER; | | | 2441 | | Tx expired | | | 2442 | PendingE | Failed answer or answer | | Idle | 2443 | | received with result code | | | 2444 | | END_USER_SERVICE DENIED or | | | 2445 | | USER_UNKNOWN; requested action | | | 2446 | | DIRECT_DEBITING; Tx expired | | | 2447 | PendingE | Failed CC event answer | Indicate | Idle | 2448 | | received; requested action | service | | 2449 | | REFUND_ACCOUNT | error and | | 2450 | | | delete | | 2451 | | | request | | 2452 | PendingE | Failure to send or Tx expired; | Store | Idle | 2453 | | requested action | request | | 2454 | | REFUND_ACCOUNT | with | | 2455 | | | T-flag | | 2456 | PendingE | Temporary error, and requested | Store | Idle | 2457 | | action REFUND_ACCOUNT | request | | 2458 | PendingE | Successful CC answer received | Delete | Idle | 2459 | | | request | | 2460 | PendingE | Failed CC answer received | Delete | Idle | 2461 | | | request | | 2462 | PendingE | Failure to send or temporary | | Idle | 2463 | | error | | | 2464 +----------+--------------------------------+------------+----------+ 2466 CLIENT, EVENT BASED 2468 +-------+------------------------+--------------------------+-------+ 2469 | State | Event | Action | New | 2470 | | | | State | 2471 +-------+------------------------+--------------------------+-------+ 2472 | Idle | CC initial request | Send CC initial answer, | Open | 2473 | | received and | reserve units, start Tcc | | 2474 | | successfully processed | | | 2475 | Idle | CC initial request | Send CC initial answer | Idle | 2476 | | received but not | with Result-Code != | | 2477 | | successfully processed | SUCCESS | | 2478 | Idle | CC event request | Send CC event answer | Idle | 2479 | | received and | | | 2480 | | successfully processed | | | 2481 | Idle | CC event request | Send CC event answer | Idle | 2482 | | received but not | with Result-Code != | | 2483 | | successfully processed | SUCCESS | | 2484 | Open | CC update request | Send CC update answer, | Open | 2485 | | received and | debit used units, | | 2486 | | successfully processed | reserve new units, | | 2487 | | | restart Tcc | | 2488 | Open | CC update request | Send CC update answer | Idle | 2489 | | received but not | with Result-Code != | | 2490 | | successfully processed | SUCCESS, debit used | | 2491 | | | units | | 2492 | Open | CC termination request | Send CC termin. answer, | Idle | 2493 | | received and | Stop Tcc, debit used | | 2494 | | successfully processed | units | | 2495 | Open | CC termination request | Send CC termin. answer | Idle | 2496 | | received but not | with Result-Code != | | 2497 | | successfully processed | SUCCESS, debit used | | 2498 | | | units | | 2499 | Open | Session supervision | Release reserved units | Idle | 2500 | | timer Tcc expired | | | 2501 +-------+------------------------+--------------------------+-------+ 2503 SERVER, SESSION AND EVENT BASED 2505 8. Credit-Control AVPs 2507 This section defines the credit-control AVPs that are specific to 2508 Diameter credit-control application and that MAY be included in the 2509 Diameter credit-control messages. 2511 The AVPs defined in this section MAY also be included in 2512 authorization commands defined in authorization-specific 2513 applications, such as [RFC7155] and [RFC4004], if the first 2514 interrogation is performed as part of the authorization/ 2515 authentication process, as described in Section 5.2. 2517 The Diameter AVP rules are defined in the Diameter Base [RFC6733], 2518 Section 4. These AVP rules are observed in AVPs defined in this 2519 section. 2521 The following table describes the Diameter AVPs defined in the 2522 credit-control application, their AVP Code values, types, possible 2523 flag values, and whether the AVP MAY be encrypted. The Diameter base 2524 [RFC6733] specifies the AVP Flag rules for AVPs in section 4.5. 2526 +---------------+ 2527 |AVP Flag rules | 2528 |----+-----+----| 2529 AVP Section | | |MUST| 2530 Attribute Name Code Defined Data Type |MUST| MAY |NOT | 2531 -----------------------------------------|----+-----+----| 2532 CC-Correlation-Id 411 8.1 OctetString| | M | V | 2533 CC-Input-Octets 412 8.24 Unsigned64 | M | | V | 2534 CC-Money 413 8.22 Grouped | M | | V | 2535 CC-Output-Octets 414 8.25 Unsigned64 | M | | V | 2536 CC-Request-Number 415 8.2 Unsigned32 | M | | V | 2537 CC-Request-Type 416 8.3 Enumerated | M | | V | 2538 CC-Service- 417 8.26 Unsigned64 | M | | V | 2539 Specific-Units | | | | 2540 CC-Session- 418 8.4 Enumerated | M | | V | 2541 Failover | | | | 2542 CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V | 2543 CC-Time 420 8.21 Unsigned32 | M | | V | 2544 CC-Total-Octets 421 8.23 Unsigned64 | M | | V | 2545 CC-Unit-Type 454 8.32 Enumerated | M | | V | 2546 Check-Balance- 422 8.6 Enumerated | M | | V | 2547 Result | | | | 2548 Cost-Information 423 8.7 Grouped | M | | V | 2549 Cost-Unit 424 8.12 UTF8String | M | | V | 2550 Credit-Control 426 8.13 Enumerated | M | | V | 2551 Credit-Control- 427 8.14 Enumerated | M | | V | 2552 Failure-Handling | | | | 2553 Currency-Code 425 8.11 Unsigned32 | M | | V | 2554 Direct-Debiting- 428 8.15 Enumerated | M | | V | 2555 Failure-Handling | | | | 2556 Exponent 429 8.9 Integer32 | M | | V | 2557 Final-Unit-Action 449 8.35 Enumerated | M | | V | 2558 Final-Unit- 430 8.34 Grouped | M | | V | 2559 Indication | | | | 2560 Granted-Service- 431 8.17 Grouped | M | | V | 2561 Unit | | | | 2562 G-S-U-Pool- 453 8.31 Unsigned32 | M | | V | 2563 Identifier | | | | 2564 G-S-U-Pool- 457 8.30 Grouped | M | | V | 2565 Reference | | | | 2566 Multiple-Services 456 8.16 Grouped | M | | V | 2567 -Credit-Control | | | | 2568 Multiple-Services 455 8.40 Enumerated | M | | V | 2569 -Indicator | | | | 2570 Rating-Group 432 8.29 Unsigned32 | M | | V | 2571 Redirect-Address 433 8.38 Enumerated | M | | V | 2572 -Type | | | | 2573 Redirect-Server 434 8.37 Grouped | M | | V | 2574 Redirect-Server 435 8.39 UTF8String | M | | V | 2575 -Address | | | | 2576 Requested-Action 436 8.41 Enumerated | M | | V | 2577 Requested-Service 437 8.18 Grouped | M | | V | 2578 -Unit | | | | 2579 Restriction 438 8.36 IPFiltrRule| M | | V | 2580 -Filter-Rule | | | | 2581 Service-Context 461 8.42 UTF8String | M | | V | 2582 -Id | | | | 2583 Service- 439 8.28 Unsigned32 | M | | V | 2584 Identifier | | | | 2585 Service-Parameter 440 8.43 Grouped | | M | V | 2586 -Info | | | | 2587 Service- 441 8.44 Unsigned32 | | M | V | 2588 Parameter-Type | | | | 2589 Service- 442 8.45 OctetString| | M | V | 2590 Parameter-Value | | | | 2591 Subscription-Id 443 8.46 Grouped | M | | V | 2592 Subscription-Id 444 8.48 UTF8String | M | | V | 2593 -Data | | | | 2594 Subscription-Id 450 8.47 Enumerated | M | | V | 2595 -Type | | | | 2596 Tariff-Change 452 8.27 Enumerated | M | | V | 2597 -Usage | | | | 2598 Tariff-Time 451 8.20 Time | M | | V | 2599 -Change | | | | 2600 Unit-Value 445 8.8 Grouped | M | | V | 2601 Used-Service-Unit 446 8.19 Grouped | M | | V | 2602 User-Equipment 458 8.49 Grouped | | M | V | 2603 -Info | | | | 2604 User-Equipment 459 8.50 Enumerated | | M | V | 2605 -Info-Type | | | | 2606 User-Equipment 460 8.51 OctetString| | M | V | 2607 -Info-Value | | | | 2608 Value-Digits 447 8.10 Integer64 | M | | V | 2609 Validity-Time 448 8.33 Unsigned32 | M | | V | 2611 8.1. CC-Correlation-Id AVP 2613 The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and 2614 contains information to correlate credit-control requests generated 2615 for different components of the service; e.g., transport and service 2616 level. The one who allocates the Service-Context-Id (i.e., unique 2617 identifier of a service specific document) is also responsible for 2618 defining the content and encoding of the CC-Correlation-Id AVP. 2620 8.2. CC-Request-Number AVP 2622 The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and 2623 identifies this request within one session. As Session-Id AVPs are 2624 globally unique, the combination of Session-Id and CC-Request-Number 2625 AVPs is also globally unique and can be used in matching credit- 2626 control messages with confirmations. An easy way to produce unique 2627 numbers is to set the value to 0 for a credit-control request of type 2628 INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the 2629 first UPDATE_REQUEST, to 2 for the second, and so on until the value 2630 for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST. 2632 8.3. CC-Request-Type AVP 2634 The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and 2635 contains the reason for sending the credit-control request message. 2636 It MUST be present in all Credit-Control-Request messages. The 2637 following values are defined for the CC-Request-Type AVP: 2639 INITIAL_REQUEST 1 2641 An Initial request is used to initiate a credit-control session, and 2642 contains credit control information that is relevant to the 2643 initiation. 2645 UPDATE_REQUEST 2 2647 An Update request contains credit-control information for an existing 2648 credit-control session. Update credit-control requests SHOULD be 2649 sent every time a credit-control re-authorization is needed at the 2650 expiry of the allocated quota or validity time. Further, additional 2651 service-specific events MAY trigger a spontaneous Update request. 2653 TERMINATION_REQUEST 3 2655 A Termination request is sent to terminate a credit-control session 2656 and contains credit-control information relevant to the existing 2657 session. 2659 EVENT_REQUEST 4 2661 An Event request is used when there is no need to maintain any 2662 credit-control session state in the credit-control server. This 2663 request contains all information relevant to the service, and is the 2664 only request of the service. The reason for the Event request is 2665 further detailed in the Requested-Action AVP. The Requested- Action 2666 AVP MUST be included in the Credit-Control-Request message when CC- 2667 Request-Type is set to EVENT_REQUEST. 2669 8.4. CC-Session-Failover AVP 2671 The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and 2672 contains information as to whether moving the credit-control message 2673 stream to a backup server during an ongoing credit-control session is 2674 supported. In communication failures, the credit-control message 2675 streams can be moved to an alternative destination if the credit- 2676 control server supports failover to an alternative server. The 2677 secondary credit-control server name, if received from the home 2678 Diameter AAA server, can be used as an address of the backup server. 2679 An implementation is not required to support moving a credit-control 2680 message stream to an alternative server, as this also requires moving 2681 information related to the credit-control session to backup server. 2683 The following values are defined for the CC-Session-Failover AVP: 2685 FAILOVER_NOT_SUPPORTED 0 2687 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, 2688 the credit-control message stream MUST NOT to be moved to an 2689 alternative destination in the case of communication failure. This 2690 is the default behavior if the AVP isn't included in the reply from 2691 the authorization or credit-control server. 2693 FAILOVER_SUPPORTED 1 2695 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the 2696 credit-control message stream SHOULD be moved to an alternative 2697 destination in the case of communication failure. Moving the credit- 2698 control message stream to a backup server MAY require that 2699 information related to the credit-control session should also be 2700 forwarded to alternative server. 2702 8.5. CC-Sub-Session-Id AVP 2704 The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and 2705 contains the credit-control sub-session identifier. The combination 2706 of the Session-Id and this AVP MUST be unique per sub-session, and 2707 the value of this AVP MUST be monotonically increased by one for all 2708 new sub-sessions. The absence of this AVP implies that no sub- 2709 sessions are in use. 2711 8.6. Check-Balance-Result AVP 2713 The Check Balance Result AVP (AVP Code 422) is of type Enumerated and 2714 contains the result of the balance check. This AVP is applicable 2715 only when the Requested-Action AVP indicates CHECK_BALANCE in the 2716 Credit-Control-Request command. The following values are defined for 2717 the Check-Balance-Result AVP. 2719 ENOUGH_CREDIT 0 2721 There is enough credit in the account to cover the requested service. 2723 NO_CREDIT 1 2725 There isn't enough credit in the account to cover the requested 2726 service. 2728 8.7. Cost-Information AVP 2730 The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is 2731 used to return the cost information of a service, which the credit- 2732 control client can transfer transparently to the end user. The 2733 included Unit-Value AVP contains the cost estimate (always type of 2734 money) of the service, in the case of price enquiry, or the 2735 accumulated cost estimation, in the case of credit-control session. 2737 The Currency-Code specifies in which currency the cost was given. 2738 The Cost-Unit specifies the unit when the service cost is a cost per 2739 unit (e.g., cost for the service is $1 per minute). 2741 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 2742 the Credit-Control-Request command, the Cost-Information AVP sent in 2743 the succeeding Credit-Control-Answer command contains the cost 2744 estimation of the requested service, without any reservation being 2745 made. 2747 The Cost-Information AVP included in the Credit-Control-Answer 2748 command with the CC-Request-Type set to UPDATE_REQUEST contains the 2749 accumulated cost estimation for the session, without taking any 2750 credit reservation into account. 2752 The Cost-Information AVP included in the Credit-Control-Answer 2753 command with the CC-Request-Type set to EVENT_REQUEST or 2754 TERMINATION_REQUEST contains the estimated total cost for the 2755 requested service. 2757 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2759 Cost-Information ::= < AVP Header: 423 > 2760 { Unit-Value } 2761 { Currency-Code } 2762 [ Cost-Unit ] 2764 8.8. Unit-Value AVP 2766 Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the 2767 units as decimal value. The Unit-Value is a value with an exponent; 2768 i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This 2769 representation avoids unwanted rounding off. For example, the value 2770 of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The 2771 absence of the exponent part MUST be interpreted as an exponent equal 2772 to zero. 2774 It is defined as follows (per the grouped-avp-def of [RFC6733]): 2776 Unit-Value ::= < AVP Header: 445 > 2777 { Value-Digits } 2778 [ Exponent ] 2780 8.9. Exponent AVP 2782 Exponent AVP is of type Integer32 (AVP Code 429) and contains the 2783 exponent value to be applied for the Value-Digit AVP within the Unit- 2784 Value AVP. 2786 8.10. Value-Digits AVP 2788 The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains 2789 the significant digits of the number. If decimal values are needed 2790 to present the units, the scaling MUST be indicated with the related 2791 Exponent AVP. For example, for the monetary amount $ 0.05 the value 2792 of Value-Digits AVP MUST be set to 5, and the scaling MUST be 2793 indicated with the Exponent AVP set to -2. 2795 8.11. Currency-Code AVP 2797 The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and 2798 contains a currency code that specifies in which currency the values 2799 of AVPs containing monetary units were given. It is specified by 2800 using the numeric values defined in the ISO 4217 standard [ISO4217]. 2802 8.12. Cost-Unit AVP 2804 The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is 2805 used to display a human readable string to the end user. It 2806 specifies the applicable unit to the Cost-Information when the 2807 service cost is a cost per unit (e.g., cost of the service is $1 per 2808 minute). The Cost-Unit can be minutes, hours, days, kilobytes, 2809 megabytes, etc. 2811 8.13. Credit-Control AVP 2813 The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST 2814 be included in AA requests when the service element has credit- 2815 control capabilities. 2817 CREDIT_AUTHORIZATION 0 2819 If the home Diameter AAA server determines that the user has prepaid 2820 subscription, this value indicates that the credit-control server 2821 MUST be contacted to perform the first interrogation. The value of 2822 the Credit-Control AVP MUST always be set to 0 in an AA request sent 2823 to perform the first interrogation and to initiate a new credit- 2824 control session. 2826 RE_AUTHORIZATION 1 2828 This value indicates to the Diameter AAA server that a credit- 2829 control session is ongoing for the subscriber and that the credit- 2830 control server MUST not be contacted. The Credit-Control AVP set to 2831 the value of 1 is to be used only when the first interrogation has 2832 been successfully performed and the credit- control session is 2833 ongoing (i.e., re-authorization triggered by Authorization-Lifetime). 2834 This value MUST NOT be used in an AA request sent to perform the 2835 first interrogation. 2837 8.14. Credit-Control-Failure-Handling AVP 2839 The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type 2840 Enumerated. The credit-control client uses information in this AVP 2841 to decide what to do if sending credit-control messages to the 2842 credit-control server has been, for instance, temporarily prevented 2843 due to a network problem. Depending on the service logic, the 2844 credit-control server can order the client to terminate the service 2845 immediately when there is a reason to believe that the service cannot 2846 be charged, or to try failover to an alternative server, if possible. 2848 Then the server could either terminate or grant the service, should 2849 the alternative connection also fail. 2851 TERMINATE 0 2853 When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the 2854 service MUST only be granted for as long as there is a connection to 2855 the credit-control server. If the credit-control client does not 2856 receive any Credit-Control-Answer message within the Tx timer (as 2857 defined in Section 13), the credit-control request is regarded as 2858 failed, and the end user's service session is terminated. 2860 This is the default behavior if the AVP isn't included in the reply 2861 from the authorization or credit-control server. 2863 CONTINUE 1 2865 When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the 2866 credit-control client SHOULD re-send the request to an alternative 2867 server in the case of transport or temporary failures, provided that 2868 a failover procedure is supported in the credit- control server and 2869 the credit-control client, and that an alternative server is 2870 available. Otherwise, the service SHOULD be granted, even if credit- 2871 control messages can't be delivered. 2873 RETRY_AND_TERMINATE 2 2875 When the Credit-Control-Failure-Handling AVP is set to 2876 RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the 2877 request to an alternative server in the case of transport or 2878 temporary failures, provided that a failover procedure is supported 2879 in the credit-control server and the credit-control client, and that 2880 an alternative server is available. Otherwise, the service SHOULD 2881 not be granted when the credit-control messages can't be delivered. 2883 8.15. Direct-Debiting-Failure-Handling AVP 2885 The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type 2886 Enumerated. The credit-control client uses information in this AVP 2887 to decide what to do if sending credit-control messages (Requested- 2888 Action AVP set to DIRECT_DEBITING) to the credit-control server has 2889 been, for instance, temporarily prevented due to a network problem. 2891 TERMINATE_OR_BUFFER 0 2893 When the Direct-Debiting-Failure-Handling AVP is set to 2894 TERMINATE_OR_BUFFER, the service MUST be granted for as long as there 2895 is a connection to the credit-control server. If the credit-control 2896 client does not receive any Credit-Control-Answer message within the 2897 Tx timer (as defined in Section 13) the credit-control request is 2898 regarded as failed. The client SHOULD terminate the service if it 2899 can determine from the failed answer that units have not been 2900 debited. Otherwise the credit-control client SHOULD grant the 2901 service, store the request in application level non-volatile storage, 2902 and try to re-send the request. These requests MUST be marked as 2903 possible duplicates by setting the T- flag in the command header as 2904 described in [RFC6733] section 3. This is the default behavior if 2905 the AVP isn't included in the reply from the authorization server. 2907 CONTINUE 1 2909 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 2910 service SHOULD be granted, even if credit-control messages can't be 2911 delivered, and the request should be deleted. 2913 8.16. Multiple-Services-Credit-Control AVP 2915 Multiple-Services-Credit-Control AVP (AVP Code 456) is of type 2916 Grouped and contains the AVPs related to the independent credit- 2917 control of multiple services feature. Note that each instance of 2918 this AVP carries units related to one or more services or related to 2919 a single rating group. 2921 The Service-Identifier and the Rating-Group AVPs are used to 2922 associate the granted units to a given service or rating group. If 2923 both the Service-Identifier and the Rating-Group AVPs are included, 2924 the target of the service units is always the service(s) indicated by 2925 the value of the Service-Identifier AVP(s). If only the Rating- 2926 Group-Id AVP is present, the Multiple-Services-Credit-Control AVP 2927 relates to all the services that belong to the specified rating 2928 group. 2930 The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- 2931 Pool-Identifier identifying a credit pool within which the units of 2932 the specified type are considered pooled. If a G-S-U-Pool-Reference 2933 AVP is present, then actual service units of the specified type MUST 2934 also be present. For example, if the G-S-U-Pool-Reference AVP 2935 specifies Unit-Type TIME, then the CC-Time AVP MUST be present. 2937 The Requested-Service-Unit AVP MAY contain the amount of requested 2938 service units or the requested monetary value. It MUST be present in 2939 the initial interrogation and within the intermediate interrogations 2940 in which new quota is requested. If the credit-control client does 2941 not include the Requested-Service-Unit AVP in a request command, 2942 because for instance, it has determined that the end-user terminated 2943 the service, the server MUST debit the used amount from the user's 2944 account but MUST NOT return a new quota in the corresponding answer. 2945 The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY be 2946 present in an answer command as defined in sections 5.1.2 and 5.6 for 2947 the graceful service termination. 2949 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 2950 present, the server MUST include two separate instances of the 2951 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit 2952 AVP associated to the same service-identifier and/or rating-group. 2953 Where the two quotas are associated to the same pool or to different 2954 pools, the credit pooling mechanism defined in Section 5.1.2 applies. 2955 The Tariff-Change-Usage AVP MUST NOT be included in request commands 2956 to report used units before, and after tariff time change the Used- 2957 Service-Unit AVP MUST be used. 2959 A server not implementing the independent credit-control of multiple 2960 services functionality MUST treat the Multiple-Services-Credit- 2961 Control AVP as an invalid AVP. 2963 The Multiple-Services-Control AVP is defined as follows (per the 2964 grouped-avp-def of [RFC6733]): 2966 Multiple-Services-Credit-Control ::= < AVP Header: 456 > 2967 [ Granted-Service-Unit ] 2968 [ Requested-Service-Unit ] 2969 *[ Used-Service-Unit ] 2970 [ Tariff-Change-Usage ] 2971 *[ Service-Identifier ] 2972 [ Rating-Group ] 2973 *[ G-S-U-Pool-Reference ] 2974 [ Validity-Time ] 2975 [ Result-Code ] 2976 [ Final-Unit-Indication ] 2977 *[ AVP ] 2979 8.17. Granted-Service-Unit AVP 2981 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 2982 contains the amount of units that the Diameter credit-control client 2983 can provide to the end user until the service must be released or the 2984 new Credit-Control-Request must be sent. A client is not required to 2985 implement all the unit types, and it must treat unknown or 2986 unsupported unit types in the answer message as an incorrect CCA 2987 answer. In this case, the client MUST terminate the credit-control 2988 session and indicate in the Termination-Cause AVP reason 2989 DIAMETER_BAD_ANSWER. 2991 The Granted-Service-Unit AVP is defined as follows (per the grouped- 2992 avp-def of [RFC6733]): 2994 Granted-Service-Unit ::= < AVP Header: 431 > 2995 [ Tariff-Time-Change ] 2996 [ CC-Time ] 2997 [ CC-Money ] 2998 [ CC-Total-Octets ] 2999 [ CC-Input-Octets ] 3000 [ CC-Output-Octets ] 3001 [ CC-Service-Specific-Units ] 3002 *[ AVP ] 3004 8.18. Requested-Service-Unit AVP 3006 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and 3007 contains the amount of requested units specified by the Diameter 3008 credit-control client. A server is not required to implement all the 3009 unit types, and it must treat unknown or unsupported unit types as 3010 invalid AVPs. 3012 The Requested-Service-Unit AVP is defined as follows (per the 3013 grouped-avp-def of [RFC6733]): 3015 Requested-Service-Unit ::= < AVP Header: 437 > 3016 [ CC-Time ] 3017 [ CC-Money ] 3018 [ CC-Total-Octets ] 3019 [ CC-Input-Octets ] 3020 [ CC-Output-Octets ] 3021 [ CC-Service-Specific-Units ] 3022 *[ AVP ] 3024 8.19. Used-Service-Unit AVP 3026 The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and 3027 contains the amount of used units measured from the point when the 3028 service became active or, if interim interrogations are used during 3029 the session, from the point when the previous measurement ended. 3031 The Used-Service-Unit AVP is defined as follows (per the grouped- 3032 avp-def of [RFC6733]): 3034 Used-Service-Unit ::= < AVP Header: 446 > 3035 [ Tariff-Change-Usage ] 3036 [ CC-Time ] 3037 [ CC-Money ] 3038 [ CC-Total-Octets ] 3039 [ CC-Input-Octets ] 3040 [ CC-Output-Octets ] 3041 [ CC-Service-Specific-Units ] 3042 *[ AVP ] 3044 8.20. Tariff-Time-Change AVP 3046 The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is 3047 sent from the server to the client and includes the time in seconds 3048 since January 1, 1900, 00:00 UTC, when the tariff of the service will 3049 be changed. 3051 The tariff change mechanism is optional for the client and server, 3052 and it is not used for time-based services defined in Section 5. If 3053 a client does not support the tariff time change mechanism, it MUST 3054 treat Tariff-Time-Change AVP in the answer message as an incorrect 3055 CCA answer. In this case, the client terminates the credit-control 3056 session and indicates in the Termination-Cause AVP reason 3057 DIAMETER_BAD_ANSWER. 3059 Omission of this AVP means that no tariff change is to be reported. 3061 8.21. CC-Time AVP 3063 The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates 3064 the length of the requested, granted, or used time in seconds. 3066 8.22. CC-Money AVP 3068 The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the 3069 monetary amount in the given currency. The Currency-Code AVP SHOULD 3070 be included. It is defined as follows (per the grouped-avp-def of 3071 [RFC6733]): 3073 CC-Money ::= < AVP Header: 413 > 3074 { Unit-Value } 3075 [ Currency-Code ] 3077 8.23. CC-Total-Octets AVP 3079 The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and 3080 contains the total number of requested, granted, or used octets 3081 regardless of the direction (sent or received). 3083 8.24. CC-Input-Octets AVP 3085 The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and 3086 contains the number of requested, granted, or used octets that can 3087 be/have been received from the end user. 3089 8.25. CC-Output-Octets AVP 3091 The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and 3092 contains the number of requested, granted, or used octets that can 3093 be/have been sent to the end user. 3095 8.26. CC-Service-Specific-Units AVP 3097 The CC-Service-Specific-Units AVP (AVP Code 417) is of type 3098 Unsigned64 and specifies the number of service-specific units (e.g., 3099 number of events, points) given in a selected service. The service- 3100 specific units always refer to the service identified in the Service- 3101 Identifier AVP (or Rating-Group AVP when the Multiple- Services- 3102 Credit-Control AVP is used). 3104 8.27. Tariff-Change-Usage AVP 3106 The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and 3107 defines whether units are used before or after a tariff change, or 3108 whether the units straddled a tariff change during the reporting 3109 period. Omission of this AVP means that no tariff change has 3110 occurred. 3112 In addition, when present in answer messages as part of the Multiple- 3113 Services-Credit-Control AVP, this AVP defines whether units are 3114 allocated to be used before or after a tariff change event. 3116 When the Tariff-Time-Change AVP is present, omission of this AVP in 3117 answer messages means that the single quota mechanism applies. 3119 Tariff-Change-Usage can be one of the following: 3121 UNIT_BEFORE_TARIFF_CHANGE 0 3122 When present in the Multiple-Services-Credit-Control AVP, this value 3123 indicates the amount of the units allocated for use before a tariff 3124 change occurs. 3126 When present in the Used-Service-Unit AVP, this value indicates the 3127 amount of resource units used before a tariff change had occurred. 3129 UNIT_AFTER_TARIFF_CHANGE 1 3131 When present in the Multiple-Services-Credit-Control AVP, this value 3132 indicates the amount of the units allocated for use after a tariff 3133 change occurs. 3135 When present in the Used-Service-Unit AVP, this value indicates the 3136 amount of resource units used after tariff change had occurred. 3138 UNIT_INDETERMINATE 2 3140 The used unit contains the amount of units that straddle the tariff 3141 change (e.g., the metering process reports to the credit- control 3142 client in blocks of n octets, and one block straddled the tariff 3143 change). This value is to be used only in the Used- Service-Unit 3144 AVP. 3146 8.28. Service-Identifier AVP 3148 The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and 3149 contains the identifier of a service. The specific service the 3150 request relates to is uniquely identified by the combination of 3151 Service-Context-Id and Service-Identifier AVPs. 3153 A usage example of this AVP is illustrated in Appendix A (Flow IX). 3155 8.29. Rating-Group AVP 3157 The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and 3158 contains the identifier of a rating group. All the services subject 3159 to the same rating type are part of the same rating group. The 3160 specific rating group the request relates to is uniquely identified 3161 by the combination of Service-Context-Id and Rating-Group AVPs. 3163 A usage example of this AVP is illustrated in Appendix A (Flow IX). 3165 8.30. G-S-U-Pool-Reference AVP 3167 The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It 3168 is used in the Credit-Control-Answer message, and associates the 3169 Granted-Service-Unit AVP within which it appears with a credit pool 3170 within the session. 3172 The G-S-U-Pool-Identifier AVP specifies the credit pool from which 3173 credit is drawn for this unit type. 3175 The CC-Unit-Type AVP specifies the type of units for which credit is 3176 pooled. 3178 The Unit-Value AVP specifies the multiplier, which converts between 3179 service units of type CC-Unit-Type and abstract service units within 3180 the credit pool (and thus to service units of any other service or 3181 rating group associated with the same pool). 3183 The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- 3184 avp-def of [RFC6733]): 3186 G-S-U-Pool-Reference ::= < AVP Header: 457 > 3187 { G-S-U-Pool-Identifier } 3188 { CC-Unit-Type } 3189 { Unit-Value } 3191 8.31. G-S-U-Pool-Identifier AVP 3193 The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 3194 and identifies a credit pool within the session. 3196 8.32. CC-Unit-Type AVP 3198 The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and 3199 specifies the type of units considered to be pooled into a credit 3200 pool. 3202 The following values are defined for the CC-Unit-Type AVP: 3204 TIME 0 3205 MONEY 1 3206 TOTAL-OCTETS 2 3207 INPUT-OCTETS 3 3208 OUTPUT-OCTETS 4 3209 SERVICE-SPECIFIC-UNITS 5 3211 8.33. Validity-Time AVP 3213 The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is 3214 sent from the credit-control server to the credit-control client. 3215 The AVP contains the validity time of the granted service units. The 3216 measurement of the Validity-Time is started upon receipt of the 3217 Credit-Control-Answer Message containing this AVP. If the granted 3218 service units have not been consumed within the validity time 3219 specified in this AVP, the credit-control client MUST send a Credit- 3220 Control-Request message to the server, with CC-Request-Type set to 3221 UPDATE_REQUEST. The value field of the Validity-Time AVP is given in 3222 seconds. 3224 The Validity-Time AVP is also used for the graceful service 3225 termination (see Section 5.6) to indicate to the credit-control 3226 client how long the subscriber is allowed to use network resources 3227 after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) 3228 started. When the Validity-Time elapses, a new intermediate 3229 interrogation is sent to the server. 3231 8.34. Final-Unit-Indication AVP 3233 The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and 3234 indicates that the Granted-Service-Unit AVP in the Credit-Control- 3235 Answer, or in the AA answer, contains the final units for the 3236 service. After these units have expired, the Diameter credit-control 3237 client is responsible for executing the action indicated in the 3238 Final-Unit-Action AVP (see Section 5.6). 3240 If more than one unit type is received in the Credit-Control-Answer, 3241 the unit type that first expired SHOULD cause the credit-control 3242 client to execute the specified action. 3244 In the first interrogation, the Final-Unit-Indication AVP with Final- 3245 Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no 3246 Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA 3247 answer. This indicates to the Diameter credit-control client to 3248 execute the specified action immediately. If the home service 3249 provider policy is to terminate the service, naturally, the server 3250 SHOULD return the appropriate transient failure (see Section 9.1) in 3251 order to implement the policy-defined action. 3253 The Final-Unit-Action AVP defines the behavior of the service element 3254 when the user's account cannot cover the cost of the service and MUST 3255 always be present if the Final-Unit-Indication AVP is included in a 3256 command. 3258 If the Final-Unit-Action AVP is set to TERMINATE, no other AVPs MUST 3259 be present. 3261 If the Final-Unit-Action AVP is set to REDIRECT at least the 3262 Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP 3263 or the Filter-Id AVP MAY be present in the Credit-Control-Answer 3264 message if the user is also allowed to access other services that are 3265 not accessible through the address given in the Redirect-Server AVP. 3267 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the 3268 Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3270 The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be 3271 used to reference an IP filter list installed in the access device by 3272 means other than the Diameter credit-control application, e.g., 3273 locally configured or configured by another entity. 3275 The Final-Unit-Indication AVP is defined as follows (per the grouped- 3276 avp-def of [RFC6733]): 3278 Final-Unit-Indication ::= < AVP Header: 430 > 3279 { Final-Unit-Action } 3280 *[ Restriction-Filter-Rule ] 3281 *[ Filter-Id ] 3282 [ Redirect-Server ] 3284 8.35. Final-Unit-Action AVP 3286 The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and 3287 indicates to the credit-control client the action to be taken when 3288 the user's account cannot cover the service cost. 3290 The Final-Unit-Action can be one of the following: 3292 TERMINATE 0 3294 The credit-control client MUST terminate the service session. This 3295 is the default handling, applicable whenever the credit- control 3296 client receives an unsupported Final-Unit-Action value, and it MUST 3297 be supported by all the Diameter credit-control client 3298 implementations conforming to this specification. 3300 REDIRECT 1 3302 The service element MUST redirect the user to the address specified 3303 in the Redirect-Server-Address AVP. The redirect action is defined 3304 in Section 5.6.2. 3306 RESTRICT_ACCESS 2 3308 The access device MUST restrict the user access according to the IP 3309 packet filters defined in the Restriction-Filter-Rule AVP or 3310 according to the IP packet filters identified by the Filter-Id AVP. 3312 All the packets not matching the filters MUST be dropped (see 3313 Section 5.6.3). 3315 8.36. Restriction-Filter-Rule AVP 3317 The Restriction-Filter-Rule AVP (AVP Code 438) is of type 3318 IPFilterRule and provides filter rules corresponding to services that 3319 are to remain accessible even if there are no more service units 3320 granted. The access device has to configure the specified filter 3321 rules for the subscriber and MUST drop all the packets not matching 3322 these filters. Zero, one, or more such AVPs MAY be present in a 3323 Credit-Control-Answer message or in an AA answer message. 3325 8.37. Redirect-Server AVP 3327 The Redirect-Server AVP (AVP Code 434) is of type Grouped and 3328 contains the address information of the redirect server (e.g., HTTP 3329 redirect server, SIP Server) with which the end user is to be 3330 connected when the account cannot cover the service cost. It MUST be 3331 present when the Final-Unit-Action AVP is set to REDIRECT. 3333 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3335 Redirect-Server ::= < AVP Header: 434 > 3336 { Redirect-Address-Type } 3337 { Redirect-Server-Address } 3339 8.38. Redirect-Address-Type AVP 3341 The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated 3342 and defines the address type of the address given in the Redirect- 3343 Server-Address AVP. 3345 The address type can be one of the following: 3347 IPv4 Address 0 3349 The address type is in the form of "dotted-decimal" IPv4 address, as 3350 defined in [RFC0791]. 3352 IPv6 Address 1 3354 The address type is in the form of IPv6 address, as defined in 3355 [RFC4291]. The address is a text representation of the address in 3356 either the preferred or alternate text form [RFC4291]. Conformant 3357 implementations MUST support the preferred form and SHOULD support 3358 the alternate text form for IPv6 addresses. 3360 URL 2 3362 The address type is in the form of Uniform Resource Locator, as 3363 defined in [RFC1738]. 3365 SIP URI 3 3367 The address type is in the form of SIP Uniform Resource Identifier, 3368 as defined in [RFC3261]. 3370 8.39. Redirect-Server-Address AVP 3372 The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String 3373 and defines the address of the redirect server (e.g., HTTP redirect 3374 server, SIP Server) with which the end user is to be connected when 3375 the account cannot cover the service cost. 3377 8.40. Multiple-Services-Indicator AVP 3379 The Multiple-Services-Indicator AVP (AVP Code 455) is of type 3380 Enumerated and indicates whether the Diameter credit-control client 3381 is capable of handling multiple services independently within a 3382 (sub-) session. The absence of this AVP means that independent 3383 credit-control of multiple services is not supported. 3385 A server not implementing the independent credit-control of multiple 3386 services MUST treat the Multiple-Services-Indicator AVP as an invalid 3387 AVP. 3389 The following values are defined for the Multiple-Services-Indicator 3390 AVP: 3392 MULTIPLE_SERVICES_NOT_SUPPORTED 0 3394 Client does not support independent credit-control of multiple 3395 services within a (sub-)session. 3397 MULTIPLE_SERVICES_SUPPORTED 1 3399 Client supports independent credit-control of multiple services 3400 within a (sub-)session. 3402 8.41. Requested-Action AVP 3404 The Requested-Action AVP (AVP Code 436) is of type Enumerated and 3405 contains the requested action being sent by Credit-Control-Request 3406 command where the CC-Request-Type is set to EVENT_REQUEST. The 3407 following values are defined for the Requested-Action AVP: 3409 DIRECT_DEBITING 0 3411 This indicates a request to decrease the end user's account according 3412 to information specified in the Requested-Service-Unit AVP and/or 3413 Service-Identifier AVP (additional rating information may be included 3414 in service-specific AVPs or in the Service- Parameter-Info AVP). The 3415 Granted-Service-Unit AVP in the Credit- Control-Answer command 3416 contains the debited units. 3418 REFUND_ACCOUNT 1 3420 This indicates a request to increase the end user's account according 3421 to information specified in the Requested-Service-Unit AVP and/or 3422 Service-Identifier AVP (additional rating information may be included 3423 in service-specific AVPs or in the Service- Parameter-Info AVP). The 3424 Granted-Service-Unit AVP in the Credit- Control-Answer command 3425 contains the refunded units. 3427 CHECK_BALANCE 2 3429 This indicates a balance check request. In this case, the checking 3430 of the account balance is done without any credit reservation from 3431 the account. The Check-Balance-Result AVP in the Credit-Control- 3432 Answer command contains the result of the balance check. 3434 PRICE_ENQUIRY 3 3436 This indicates a price enquiry request. In this case, neither 3437 checking of the account balance nor reservation from the account will 3438 be done; only the price of the service will be returned in the Cost- 3439 Information AVP in the Credit-Control-Answer Command. 3441 8.42. Service-Context-Id AVP 3443 The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and 3444 contains a unique identifier of the Diameter credit-control service 3445 specific document that applies to the request (as defined in section 3446 4.1.2). This is an identifier allocated by the service provider, by 3447 the service element manufacturer, or by a standardization body, and 3448 MUST uniquely identify a given Diameter credit-control service 3449 specific document. The format of the Service-Context-Id is: 3451 "service-context" "@" "domain" 3453 service-context = Token 3455 The Token is an arbitrary string of characters and digits. 3457 'domain' represents the entity that allocated the Service-Context-Id. 3458 It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by 3459 a standardization body, or it can be the FQDN of the service provider 3460 (e.g., provider.example.com) or of the vendor (e.g., 3461 vendor.example.com) if the identifier is allocated by a private 3462 entity. 3464 This AVP SHOULD be placed as close to the Diameter header as 3465 possible. 3467 Service-specific documents that are for private use only (i.e., to 3468 one provider's own use, where no interoperability is deemed useful) 3469 may define private identifiers without need of coordination. 3470 However, when interoperability is wanted, coordination of the 3471 identifiers via, for example, publication of an informational RFC is 3472 RECOMMENDED in order to make Service-Context-Id globally available. 3474 8.43. Service-Parameter-Info AVP 3476 The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and 3477 contains service-specific information used for price calculation or 3478 rating. The Service-Parameter-Type AVP defines the service parameter 3479 type, and the Service-Parameter-Value AVP contains the parameter 3480 value. The actual contents of these AVPs are not within the scope of 3481 this document and SHOULD be defined in another Diameter application, 3482 in standards written by other standardization bodies, or in service- 3483 specific documentation. 3485 In the case of an unknown service request (e.g., unknown Service- 3486 Parameter-Type), the corresponding answer message MUST contain the 3487 error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message 3488 with this error MUST contain one or more Failed-AVP AVPs containing 3489 the Service-Parameter-Info AVPs that caused the failure. 3491 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3493 Service-Parameter-Info ::= < AVP Header: 440 > 3494 { Service-Parameter-Type } 3495 { Service-Parameter-Value } 3497 8.44. Service-Parameter-Type AVP 3499 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) 3500 and defines the type of the service event specific parameter (e.g., 3501 it can be the end-user location or service name). The different 3502 parameters and their types are service specific, and the meanings of 3503 these parameters are not defined in this document. Whoever allocates 3504 the Service-Context-Id (i.e., unique identifier of a service-specific 3505 document) is also responsible for assigning Service-Parameter-Type 3506 values for the service and ensuring their uniqueness within the given 3507 service. The Service-Parameter-Value AVP contains the value 3508 associated with the service parameter type. 3510 8.45. Service-Parameter-Value AVP 3512 The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) 3513 and contains the value of the service parameter type. 3515 8.46. Subscription-Id AVP 3517 The Subscription-Id AVP (AVP Code 443) is used to identify the end 3518 user's subscription and is of type Grouped. The Subscription-Id AVP 3519 includes a Subscription-Id-Data AVP that holds the identifier and a 3520 Subscription-Id-Type AVP that defines the identifier type. 3522 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3524 Subscription-Id ::= < AVP Header: 443 > 3525 { Subscription-Id-Type } 3526 { Subscription-Id-Data } 3528 8.47. Subscription-Id-Type AVP 3530 The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, 3531 and it is used to determine which type of identifier is carried by 3532 the Subscription-Id AVP. 3534 This specification defines the following subscription identifiers. 3535 However, new Subscription-Id-Type values can be assigned by an IANA 3536 designated expert, as defined in Section 12. A server MUST implement 3537 all the Subscription-Id-Types required to perform credit 3538 authorization for the services it supports, including possible future 3539 values. Unknown or unsupported Subscription-Id-Types MUST be treated 3540 according to the 'M' flag rule, as defined in [RFC6733]. 3542 END_USER_E164 0 3544 The identifier is in international E.164 format (e.g., MSISDN), 3545 according to the ITU-T E.164 numbering plan defined in [E164] and 3546 [CE164]. 3548 END_USER_IMSI 1 3549 The identifier is in international IMSI format, according to the 3550 ITU-T E.212 numbering plan as defined in [E212] and [CE212]. 3552 END_USER_SIP_URI 2 3554 The identifier is in the form of a SIP URI, as defined in [RFC3261]. 3556 END_USER_NAI 3 3558 The identifier is in the form of a Network Access Identifier, as 3559 defined in [RFC2486]. 3561 END_USER_PRIVATE 4 3563 The Identifier is a credit-control server private identifier. 3565 8.48. Subscription-Id-Data AVP 3567 The Subscription-Id-Data AVP (AVP Code 444) is used to identify the 3568 end user and is of type UTF8String. The Subscription-Id-Type AVP 3569 defines which type of identifier is used. 3571 8.49. User-Equipment-Info AVP 3573 The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and 3574 allows the credit-control client to indicate the identity and 3575 capability of the terminal the subscriber is using for the connection 3576 to network. 3578 It is defined as follows (per the grouped-avp-def of [RFC6733]): 3580 User-Equipment-Info ::= < AVP Header: 458 > 3581 { User-Equipment-Info-Type } 3582 { User-Equipment-Info-Value } 3584 8.50. User-Equipment-Info-Type AVP 3586 The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) 3587 and defines the type of user equipment information contained in the 3588 User-Equipment-Info-Value AVP. 3590 This specification defines the following user equipment types. 3591 However, new User-Equipment-Info-Type values can be assigned by an 3592 IANA designated expert, as defined in Section 12. 3594 IMEISV 0 3595 The identifier contains the International Mobile Equipment Identifier 3596 and Software Version in the international IMEISV format according to 3597 3GPP TS 23.003 [TGPPIMEI]. 3599 MAC 1 3601 The 48-bit MAC address is formatted as described in [RFC3580]. 3603 EUI64 2 3605 The 64-bit identifier used to identify hardware instance of the 3606 product, as defined in [EUI64]. 3608 MODIFIED_EUI64 3 3610 There are a number of types of terminals that have identifiers other 3611 than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be 3612 converted to modified EUI-64 format as described in [RFC4291] or by 3613 using some other methods referred to in the service-specific 3614 documentation. 3616 8.51. User-Equipment-Info-Value AVP 3618 The User-Equipment-Info-Value AVP (AVP Code 460) is of type 3619 OctetString. The User-Equipment-Info-Type AVP defines which type of 3620 identifier is used. 3622 9. Result Code AVP Values 3624 This section defines new Result-Code AVP [RFC6733] values that must 3625 be supported by all Diameter implementations that conform to this 3626 specification. 3628 The Credit-Control-Answer message includes the Result-Code AVP, which 3629 may indicate that an error was present in the Credit-Control-Request 3630 message. A rejected Credit-Control-Request message SHOULD cause the 3631 user's session to be terminated. 3633 9.1. Transient Failures 3635 Errors that fall within the transient failures category are used to 3636 inform a peer that the request could not be satisfied at the time it 3637 was received, but that the request MAY be able to be satisfied in the 3638 future. 3640 DIAMETER_END_USER_SERVICE_DENIED 4010 3641 The credit-control server denies the service request due to service 3642 restrictions. If the CCR contained used-service-units, they are 3643 deducted, if possible. 3645 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 3647 The credit-control server determines that the service can be granted 3648 to the end user but that no further credit-control is needed for the 3649 service (e.g., service is free of charge). 3651 DIAMETER_CREDIT_LIMIT_REACHED 4012 3653 The credit-control server denies the service request because the end 3654 user's account could not cover the requested service. If the CCR 3655 contained used-service-units they are deducted, if possible. 3657 9.2. Permanent Failures 3659 Errors that fall within the permanent failure category are used to 3660 inform the peer that the request failed and should not be attempted 3661 again. 3663 DIAMETER_USER_UNKNOWN 5030 3665 The specified end user is unknown in the credit-control server. 3667 DIAMETER_RATING_FAILED 5031 3669 This error code is used to inform the credit-control client that the 3670 credit-control server cannot rate the service request due to 3671 insufficient rating input, an incorrect AVP combination, or an AVP or 3672 an AVP value that is not recognized or supported in the rating. The 3673 Failed-AVP AVP MUST be included and contain a copy of the entire 3674 AVP(s) that could not be processed successfully or an example of the 3675 missing AVP complete with the Vendor-Id if applicable. The value 3676 field of the missing AVP should be of correct minimum length and 3677 contain zeros. 3679 10. AVP Occurrence Table 3681 The following table presents the AVPs defined in this document and 3682 specifies in which Diameter messages they MAY or MAY NOT be present. 3683 Note that AVPs that can only be present within a Grouped AVP are not 3684 represented in this table. 3686 The table uses the following symbols: 3688 0 The AVP MUST NOT be present in the message. 3689 0+ Zero or more instances of the AVP MAY be present in the 3690 message. 3691 0-1 Zero or one instance of the AVP MAY be present in the 3692 message. It is considered an error if there is more 3693 than one instance of the AVP. 3694 1 One instance of the AVP MUST be present in the message. 3695 1+ At least one instance of the AVP MUST be present in the 3696 message. 3698 10.1. Credit-Control AVP Table 3700 The table in this section is used to represent which credit-control 3701 applications specific AVPs defined in this document are to be present 3702 in the credit-control messages. 3704 +-----------+ 3705 | Command | 3706 | Code | 3707 |-----+-----+ 3708 Attribute Name | CCR | CCA | 3709 ------------------------------|-----+-----+ 3710 Acct-Multi-Session-Id | 0-1 | 0-1 | 3711 Auth-Application-Id | 1 | 1 | 3712 CC-Correlation-Id | 0-1 | 0 | 3713 CC-Session-Failover | 0 | 0-1 | 3714 CC-Request-Number | 1 | 1 | 3715 CC-Request-Type | 1 | 1 | 3716 CC-Sub-Session-Id | 0-1 | 0-1 | 3717 Check-Balance-Result | 0 | 0-1 | 3718 Cost-Information | 0 | 0-1 | 3719 Credit-Control-Failure- | 0 | 0-1 | 3720 Handling | | | 3721 Destination-Host | 0-1 | 0 | 3722 Destination-Realm | 1 | 0 | 3723 Direct-Debiting-Failure- | 0 | 0-1 | 3724 Handling | | | 3725 Event-Timestamp | 0-1 | 0-1 | 3726 Failed-AVP | 0 | 0+ | 3727 Final-Unit-Indication | 0 | 0-1 | 3728 Granted-Service-Unit | 0 | 0-1 | 3729 Multiple-Services-Credit- | 0+ | 0+ | 3730 Control | | | 3731 Multiple-Services-Indicator | 0-1 | 0 | 3732 Origin-Host | 1 | 1 | 3733 Origin-Realm | 1 | 1 | 3734 Origin-State-Id | 0-1 | 0-1 | 3735 Proxy-Info | 0+ | 0+ | 3736 Redirect-Host | 0 | 0+ | 3737 Redirect-Host-Usage | 0 | 0-1 | 3738 Redirect-Max-Cache-Time | 0 | 0-1 | 3739 Requested-Action | 0-1 | 0 | 3740 Requested-Service-Unit | 0-1 | 0 | 3741 Route-Record | 0+ | 0+ | 3742 Result-Code | 0 | 1 | 3743 Service-Context-Id | 1 | 0 | 3744 Service-Identifier | 0-1 | 0 | 3745 Service-Parameter-Info | 0+ | 0 | 3746 Session-Id | 1 | 1 | 3747 Subscription-Id | 0+ | 0 | 3748 Termination-Cause | 0-1 | 0 | 3749 User-Equipment-Info | 0-1 | 0 | 3750 Used-Service-Unit | 0+ | 0 | 3751 User-Name | 0-1 | 0-1 | 3752 Validity-Time | 0 | 0-1 | 3753 ------------------------------|-----+-----+ 3755 10.2. Re-Auth-Request/Answer AVP Table 3757 This section defines AVPs that are specific to the Diameter credit- 3758 control application and that MAY be included in the Diameter Re- 3759 Auth-Request/Answer (RAR/RAA) message [RFC6733]. 3761 Re-Auth-Request/Answer command MAY include the following additional 3762 AVPs: 3764 +---------------+ 3765 | Command Code | 3766 |-------+-------+ 3767 Attribute Name | RAR | RAA | 3768 ------------------------------+-------+-------+ 3769 CC-Sub-Session-Id | 0-1 | 0-1 | 3770 G-S-U-Pool-Identifier | 0-1 | 0-1 | 3771 Service-Identifier | 0-1 | 0-1 | 3772 Rating-Group | 0-1 | 0-1 | 3773 ------------------------------+-------+-------+ 3775 11. RADIUS/Diameter Credit-Control Interworking Model 3777 This section defines the basic principles for the Diameter credit- 3778 control/RADIUS prepaid inter-working model; that is, a message 3779 translation between a RADIUS based prepaid solution and a Diameter 3780 credit-control application. A complete description of the protocol 3781 translations between RADIUS and the Diameter credit-control 3782 application is beyond the scope of this specification and SHOULD be 3783 addressed in another appropriate document, such as the RADIUS prepaid 3784 specification. 3786 The Diameter credit-control architecture may have a Translation Agent 3787 capable of translation between RADIUS prepaid and Diameter credit- 3788 control protocols. An AAA server (usually the home AAA server) may 3789 act as a Translation Agent and as a Diameter credit-control client 3790 for service elements that use credit-control mechanisms other than 3791 Diameter credit control for instance, RADIUS prepaid. In this case, 3792 the home AAA server contacts the Diameter credit-control server as 3793 part of the authorization process. The interworking architecture is 3794 illustrated Figure 8, and interworking flow in Figure 9. In a 3795 roaming situation the service element (e.g., the NAS) may be located 3796 in the visited network, and a visited AAA server is usually 3797 contacted. The visited AAA server connects then to the home AAA 3798 server. 3800 RADIUS Prepaid 3801 +--------+ +---------+ protocol +------------+ +--------+ 3802 | End |<----->| Service |<---------->| Home AAA | |Business| 3803 | User | | Element | | Server | |Support | 3804 +--------+ +-->| | |+----------+|->|System | 3805 | +---------+ ||CC Client || | | 3806 | |+----------+| | | 3807 +--------+ | +------^-----+ +----^---+ 3808 | End |<--+ Credit-Control | | 3809 | User | Protocol | | 3810 +--------+ +-------V--------+ | 3811 |Credit-Control |----+ 3812 | Server | 3813 +----------------+ 3815 Figure 8: Credit-control architecture with service element containing 3816 translation agent, translating RADIUS prepaid to Diameter credit- 3817 control protocol 3819 When the AAA server acting as a Translation Agent receives an initial 3820 RADIUS Access-Request message from service element (e.g., NAS 3821 access), it performs regular authentication and authorization. If 3822 the RADIUS Access-Request message indicates that the service element 3823 is capable of credit-control, and if the home AAA server finds that 3824 the subscriber is a prepaid subscriber, then a Diameter credit- 3825 control request SHOULD be sent toward the credit-control server to 3826 perform credit authorization and to establish a credit-control 3827 session. After the Diameter credit-control server checks the end 3828 user's account balance, rates the service, and reserves credit from 3829 the end user's account, the reserved quota is returned to the home 3830 AAA server in the Diameter Credit-Control-Answer. Then the home AAA 3831 server sends the reserved quota to the service element in the RADIUS 3832 Access-Accept. 3834 At the expiry of the allocated quota, the service element sends a new 3835 RADIUS Access-Request containing the units used this far to the home 3836 AAA server. The home AAA server shall map a RADIUS Access-Request 3837 containing the reported units to the Diameter credit-control server 3838 in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter 3839 credit-control server debits the used units from the end user's 3840 account and allocates a new quota that is returned to the home AAA 3841 server in the Diameter Credit-Control-Answer. The quota is 3842 transferred to the service element in the RADIUS Access-Accept. When 3843 the end user terminates the service, or when the entire quota has 3844 been used, the service element sends a RADIUS Access-Request. To 3845 debit the used units from the end user's account and to stop the 3846 credit-control session, the home AAA server sends a Diameter Credit- 3847 Control-Request (TERMINATION_REQUEST) to the credit-control server. 3848 The Diameter credit-control server acknowledges the session 3849 termination by sending a Diameter Credit-Control-Answer to the home 3850 AAA server. The RADIUS Access-Accept is sent to the NAS. 3852 A following diagram illustrates a RADIUS prepaid - Diameter credit- 3853 control interworking sequence. 3855 Service Element Translation Agent 3856 (e.g., NAS) (CC Client) CC Server 3857 | Access-Request | | 3858 |----------------------->| | 3859 | | CCR (initial) | 3860 | |----------------------->| 3861 | | CCA (Granted-Units) | 3862 | |<-----------------------| 3863 | Access-Accept | | 3864 | (Granted-Units) | | 3865 |<-----------------------| | 3866 : : : 3867 | Access-Request | | 3868 | (Used-Units) | | 3869 |----------------------->| | 3870 | | CCR (update, | 3871 | | Used-Units) | 3872 | |----------------------->| 3873 | | CCA (Granted-Units) | 3874 | |<-----------------------| 3875 | Access-Accept | | 3876 | (Granted-Units) | | 3877 |<-----------------------| | 3878 : : : 3879 | Access-Request | | 3880 |----------------------->| | 3881 | | CCR (terminate, | 3882 | | Used-Units) | 3883 | |----------------------->| 3884 | | CCA | 3885 | |<-----------------------| 3886 | Access-Accept | | 3887 |<-----------------------| | 3888 | | | 3890 Figure 9: Message flow example with RADIUS prepaid - Diameter credit- 3891 control interworking 3893 12. IANA Considerations 3895 This section contains the namespaces that have either been created in 3896 this specification, or the values assigned to existing namespaces 3897 managed by IANA. 3899 In the subsections below, when we speak about review by a Designated 3900 Expert, please note that the designated expert will be assigned by 3901 the IESG. Initially, such Expert discussions take place on the AAA 3902 WG mailing list. 3904 12.1. Application Identifier 3906 This specification assigns the value 4, 'Diameter Credit Control', to 3907 the Application Identifier namespace defined in [RFC6733]. See 3908 Section 1.3 for more information. 3910 12.2. Command Codes 3912 This specification uses the value 272 from the Command code namespace 3913 defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit- 3914 Control-Answer (CCA) commands. 3916 12.3. AVP Codes 3918 This specification assigns the values 411 - 461 from the AVP code 3919 namespace defined in [RFC6733]. See Section 8 for the assignment of 3920 the namespace in this specification. 3922 12.4. Result-Code AVP Values 3924 This specification assigns the values 4010, 4011, 4012, 5030, 5031 3925 from the Result-Code AVP value namespace defined in [RFC6733]. See 3926 Section 9 for the assignment of the namespace in this specification. 3928 12.5. CC-Request-Type AVP 3930 As defined in Section 8.3, the CC-Request-Type AVP includes 3931 Enumerated type values 1 - 4. IANA has created and is maintaining a 3932 namespace for this AVP. All remaining values are available for 3933 assignment by a Designated Expert [RFC2434]. 3935 12.6. CC-Session-Failover AVP 3937 As defined in Section 8.4, the CC-Failover-Supported AVP includes 3938 Enumerated type values 0 - 1. IANA has created and is maintaining a 3939 namespace for this AVP. All remaining values are available for 3940 assignment by a Designated Expert [RFC2434]. 3942 12.7. CC-Unit-Type AVP 3944 As defined in Section 8.32, the CC-Unit-Type AVP includes Enumerated 3945 type values 0 - 5. IANA has created and is maintaining a namespace 3946 for this AVP. All remaining values are available for assignment by a 3947 Designated Expert [RFC2434]. 3949 12.8. Check-Balance-Result AVP 3951 As defined in Section 8.6, the Check-Balance-Result AVP includes 3952 Enumerated type values 0 - 1. IANA has created and is maintaining a 3953 namespace for this AVP. All remaining values are available for 3954 assignment by a Designated Expert [RFC2434]. 3956 12.9. Credit-Control AVP 3958 As defined in Section 8.13, the Credit-Control AVP includes 3959 Enumerated type values 0 - 1. IANA has created and is maintaining a 3960 namespace for this AVP. All remaining values are available for 3961 assignment by a Designated Expert [RFC2434]. 3963 12.10. Credit-Control-Failure-Handling AVP 3965 As defined in Section 8.14, the Credit-Control-Failure-Handling AVP 3966 includes Enumerated type values 0 - 2. IANA has created and is 3967 maintaining a namespace for this AVP. All remaining values are 3968 available for assignment by a Designated Expert [RFC2434]. 3970 12.11. Direct-Debiting-Failure-Handling AVP 3972 As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP 3973 includes Enumerated type values 0 - 1. IANA has created and is 3974 maintaining a namespace for this AVP. All remaining values are 3975 available for assignment by a Designated Expert [RFC2434]. 3977 12.12. Final-Unit-Action AVP 3979 As defined in Section 8.35, the Final-Unit-Action AVP includes 3980 Enumerated type values 0 - 2. IANA has created and is maintaining a 3981 namespace for this AVP. All remaining values are available for 3982 assignment by a Designated Expert [RFC2434]. 3984 12.13. Multiple-Services-Indicator AVP 3986 As defined in Section 8.40, the Multiple-Services-Indicator AVP 3987 includes Enumerated type values 0 - 1. IANA has created and is 3988 maintaining a namespace for this AVP. All remaining values are 3989 available for assignment by a Designated Expert [RFC2434]. 3991 12.14. Redirect-Address-Type AVP 3993 As defined in Section 8.38, the Redirect-Address-Type AVP includes 3994 Enumerated type values 0 - 3. IANA has created and is maintaining a 3995 namespace for this AVP. All remaining values are available for 3996 assignment by a Designated Expert [RFC2434]. 3998 12.15. Requested-Action AVP 4000 As defined in Section 8.41, the Requested-Action AVP includes 4001 Enumerated type values 0 - 3. IANA has created and is maintaining a 4002 namespace for this AVP. All remaining values are available for 4003 assignment by a Designated Expert [RFC2434]. 4005 12.16. Subscription-Id-Type AVP 4007 As defined in Section 8.47, the Subscription-Id-Type AVP includes 4008 Enumerated type values 0 - 4. IANA has created and is maintaining a 4009 namespace for this AVP. All remaining values are available for 4010 assignment by a Designated Expert [RFC2434]. 4012 12.17. Tariff-Change-Usage AVP 4014 As defined in Section 8.27, the Tariff-Change-Usage AVP includes 4015 Enumerated type values 0 - 2. IANA has created and is maintaining a 4016 namespace for this AVP. All remaining values are available for 4017 assignment by a Designated Expert [RFC2434]. 4019 12.18. User-Equipment-Info-Type AVP 4021 As defined in Section 8.50, the User-Equipment-Info-Type AVP includes 4022 Enumerated type values 0 - 3. IANA has created and is maintaining a 4023 namespace for this AVP. All remaining values are available for 4024 assignment by a Designated Expert [RFC2434]. 4026 13. Credit-Control Application Related Parameters 4028 Tx timer 4030 When real-time credit-control is required, the credit-control client 4031 contacts the credit-control server before and while the service is 4032 provided to an end user. Due to the real-time nature of the 4033 application, the communication delays SHOULD be minimized; e.g., to 4034 avoid an overly long service setup time experienced by the end user. 4035 The Tx timer is introduced to control the waiting time in the client 4036 in the Pending state. When the Tx timer elapses, the credit-control 4037 client takes an action to the end user according to the value of the 4038 Credit-Control-Failure-Handling AVP 4040 or Direct-Debiting-Failure-Handling AVP. The recommended value is 10 4041 seconds. 4043 Tcc timer 4044 The Tcc timer supervises an ongoing credit-control session in the 4045 credit-control server. It is RECOMMENDED to use the Validity-Time as 4046 input to set the Tcc timer value. In case of transient failures in 4047 the network, the Diameter credit-control server might change to Idle 4048 state. To avoid this, the Tcc timer MAY be set so that Tcc equals to 4049 2 x Validity-Time. 4051 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 4053 Client implementations may offer the possibility of locally 4054 configuring these AVPs. In such a case their value and behavior is 4055 defined in Section 5.7 for the Credit-Control-Failure-Handling and in 4056 Section 6.5 for the Direct-Debiting-Failure-Handling. 4058 14. Security Considerations 4060 The Diameter base protocol [RFC6733] requires that each Diameter 4061 implementation use underlying security; i.e., TLS/TCP, DTLS/SCTP or 4062 IPsec. These mechanisms are believed to provide sufficient 4063 protection under the normal Internet threat model; that is, assuming 4064 that the authorized nodes engaging in the protocol have not been 4065 compromised, but that the attacker has complete control over the 4066 communication channels between them. This includes eavesdropping, 4067 message modification, insertion, and man-in-the-middle and replay 4068 attacks. Note also that this application includes a mechanism for 4069 application layer replay protection by means of the Session-Id from 4070 [RFC6733] and CC- Request-Number, which is specified in this 4071 document. The Diameter credit-control application is often used 4072 within one domain, and there may be a single hop between the peers. 4073 In these environments, the use of TLS/TCP, DTLS/SCTP or IPsec is 4074 sufficient. The details of TLS/TCP, DTLS/SCTP or IPsec related 4075 security considerations are discussed in the [RFC6733]. 4077 Because this application handles monetary transactions (directly or 4078 indirectly), it increases the interest for various security attacks. 4079 Therefore, all parties communicating with each other MUST be 4080 authenticated, including, for instance, TLS client-side 4081 authentication. In addition, authorization of the client SHOULD be 4082 emphasized; i.e., that the client is allowed to perform credit- 4083 control for a certain user. The specific means of authorization are 4084 outside of the scope of this specification but can be, for instance, 4085 manual configuration. 4087 Another kind of threat is malicious modification, injection, or 4088 deletion of AVPs or complete credit-control messages. The credit- 4089 control messages contain sensitive billing related information (such 4090 as subscription Id, granted units, used units, cost information) 4091 whose malicious modification can have financial consequences. 4093 Sometimes simply delaying the credit-control messages can cause 4094 disturbances in the credit-control client or server. 4096 Even without any modification to the messages, an adversary can 4097 invite a security threat by eavesdropping, as the transactions 4098 contain private information about the user. Also, by monitoring the 4099 credit-control messages one can collect information about the credit- 4100 control server's billing models and business relationships. 4102 When third-party relays or proxy are involved, the hop-by-hop 4103 security does not necessarily provide sufficient protection for 4104 Diameter user session. In some cases, it may be inappropriate to 4105 send Diameter messages, such as CCR and CCA, containing sensitive 4106 AVPs via untrusted Diameter proxy agents, as there are no assurances 4107 that third-party proxies will not modify the credit-control commands 4108 or AVP values. 4110 14.1. Direct Connection with Redirects 4112 A Diameter credit-control agent cannot always know whether agents 4113 between it and the end user's Diameter credit-control server are 4114 reliable. In this case, the Diameter credit-control agent doesn't 4115 have a routing entry in its Diameter Routing Table (defined in 4116 [RFC6733], section 2.7) for the realm of the credit-control server in 4117 the end user's home domain. The Diameter credit-control agent can 4118 have a default route configured to a local Redirect agent, and it 4119 redirects the CCR message to the redirect agent. The local Redirect 4120 agent then returns a redirect notification (Result-code 3006, 4121 DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as 4122 Diameter credit-control server(s) information (Redirect-Host AVP) and 4123 information (Redirect-Host-Usage AVP) about how the routing entry 4124 resulting from the Redirect-Host is to be used. The Diameter credit- 4125 control agent then forwards the CCR message directly to one of the 4126 hosts identified by the CCA message from the redirect agent. If the 4127 value of the Redirect-Host-Usage AVP is unequal to zero, all 4128 following messages are sent to the host specified in the Redirect- 4129 Host AVP until the time specified by the Redirect-Max-Cache-Time AVP 4130 is expired. 4132 There are some authorization issues even with redirects. There may 4133 be attacks toward nodes that have been properly authorized, but that 4134 abuse their authorization or have been compromised. These issues are 4135 discussed more widely in [DIAMEAP], Section 8. 4137 15. References 4139 15.1. Normative References 4141 [CE164] "Complement to ITU-T Recommendation E.164 (05/1997):"List 4142 of ITU-T Recommendation E.164 assigned country codes"", 4143 June 2000. 4145 [CE212] "Complement to ITU-T Recommendation E.212 (11/1997):" List 4146 of mobile country or geographical area codes"", February 4147 1999. 4149 [E164] "Recommendation E.164/I.331 (05/97): The International 4150 Public Telecommunication Numbering Plan.", 1997. 4152 [E212] "Recommendation E.212 (11/98): The international 4153 identification plan for mobile terminals and mobile 4154 users.", 1998. 4156 [EUI64] IEEE, ""Guidelines for 64-bit Global Identifier (EUI-64) 4157 Registration Authority"", March 1997, 4158 . 4161 [ISO4217] "Codes for the representation of currencies and funds, 4162 International Standard ISO 4217", 2001. 4164 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4165 DOI 10.17487/RFC0791, September 1981, 4166 . 4168 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 4169 Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, 4170 December 1994, . 4172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4173 Requirement Levels", BCP 14, RFC 2119, 4174 DOI 10.17487/RFC2119, March 1997, 4175 . 4177 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4178 IANA Considerations Section in RFCs", RFC 2434, 4179 DOI 10.17487/RFC2434, October 1998, 4180 . 4182 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 4183 RFC 2486, DOI 10.17487/RFC2486, January 1999, 4184 . 4186 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4187 A., Peterson, J., Sparks, R., Handley, M., and E. 4188 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4189 DOI 10.17487/RFC3261, June 2002, 4190 . 4192 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 4193 Accounting (AAA) Transport Profile", RFC 3539, 4194 DOI 10.17487/RFC3539, June 2003, 4195 . 4197 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 4198 "IEEE 802.1X Remote Authentication Dial In User Service 4199 (RADIUS) Usage Guidelines", RFC 3580, 4200 DOI 10.17487/RFC3580, September 2003, 4201 . 4203 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4204 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4205 2006, . 4207 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 4208 Ed., "Diameter Base Protocol", RFC 6733, 4209 DOI 10.17487/RFC6733, October 2012, 4210 . 4212 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 4213 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 4214 . 4216 [TGPPCHARG] 4217 3rd Generation Partnership Project, "Technical 4218 Specification Group Services and System Aspects, Service 4219 aspects; Charging and Billing, (release 13), 3GPP TS 4220 22.115 v. 13.3.0", 2016-03. 4222 [TGPPIMEI] 4223 3rd Generation Partnership Project, "Technical 4224 Specification Group Core Network, Numbering, addressing 4225 and identification, (release 13), 3GPP TS 23.003 v. 4226 13.5.0", 2016-04. 4228 15.2. Informative References 4230 [DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 4231 Authentication Protocol (EAP) Application", Work in 4232 Progress. 4234 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 4235 DOI 10.17487/RFC2866, June 2000, 4236 . 4238 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 4239 Camarillo, "Best Current Practices for Third Party Call 4240 Control (3pcc) in the Session Initiation Protocol (SIP)", 4241 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 4242 . 4244 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., 4245 and P. McCann, "Diameter Mobile IPv4 Application", 4246 RFC 4004, DOI 10.17487/RFC4004, August 2005, 4247 . 4249 Appendix A. Acknowledgements 4251 The authors would like to thank Bernard Aboba, Jari Arkko, Robert 4252 Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, 4253 Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, 4254 Christopher Richards, Juha Vallinen, and Mark Watson for their 4255 comments and suggestions. 4257 Appendix B. Credit-Control Sequences 4259 B.1. Flow I 4260 NAS 4261 End User (CC Client) AAA Server CC Server 4262 |(1)User Logon |(2)AA Request (CC AVPs) | 4263 |------------------>|------------------->| | 4264 | | |(3)CCR(initial, CC AVPs) 4265 | | |------------------->| 4266 | | | (4)CCA(Granted-Units) 4267 | | |<-------------------| 4268 | |(5)AA Answer(Granted-Units) | 4269 |(6)Access granted |<-------------------| | 4270 |<----------------->| | | 4271 | | | | 4272 : : : : 4273 | |(7)CCR(update,Used-Units) | 4274 | |------------------->|(8)CCR | 4275 | | | (update,Used-Units) 4276 | | |------------------->| 4277 | | |(9)CCA(Granted-Units) 4278 | |(10)CCA(Granted-Units)<------------------| 4279 | |<-------------------| | 4280 : : : : 4281 | (Auth. lifetime expires) | | 4282 | |(11) AAR (CC AVP) | | 4283 | |------------------->| | 4284 | | (12) AAA | | 4285 | |<-------------------| | 4286 : : : : 4287 : : : : 4288 |(13) User logoff | | | 4289 |------------------>|(14)CCR(term.,Used-Units) | 4290 | |------------------->|(15)CCR | 4291 | | | (term.,Used-Units) 4292 | | |------------------->| 4293 | | | (16)CCA | 4294 | | (17)CCA |<-------------------| 4295 | |<-------------------| | 4296 | |(18)STR | | 4297 | |------------------->| | 4298 | | (19)STA | | 4299 | |<-------------------| | 4301 Figure 10: Flow I 4303 A credit-control flow for Network Access Services prepaid is shown in 4304 Figure A.1. The Diameter [RFC7155] is implemented in the Network 4305 Access Server (NAS). The focus of this flow is in the credit 4306 authorization. 4308 The user logs on to the network (1). The Diameter NAS sends a 4309 Diameter AA-Request (AAR) to the home Diameter AAA server. The 4310 credit-control client populates the AAR with the Credit-Control AVP 4311 set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, 4312 as usual [RFC7155]. The home Diameter AAA server performs service- 4313 specific Authentication and Authorization, as usual. The home 4314 Diameter AAA server determines that the user is a prepaid user and 4315 notices from the Credit-Control AVP that the NAS has credit-control 4316 capabilities. It sends a Diameter Credit-Control-Request with CC- 4317 Request-Type set to INITIAL_REQUEST to the Diameter credit-control 4318 server to perform credit authorization (3) and to establish a credit- 4319 control session. (The home Diameter AAA server may forward service- 4320 specific AVPs received from the NAS as input for the rating process.) 4321 The Diameter credit-control server checks the end user's account 4322 balance, rates the service, and reserves credit from the end user's 4323 account. The reserved quota is returned to the home Diameter AAA 4324 server in the Diameter Credit-Control-Answer (4). The home Diameter 4325 AAA server sends the reserved quota to the NAS in the Diameter AA- 4326 Answer (AAA). Upon successful AAA, the NAS starts the credit-control 4327 session and starts monitoring the granted units (5). The NAS grants 4328 access to the end user (6). At the expiry of the allocated quota, 4329 the NAS sends a Diameter Credit-Control-Request with CC-Request-Type 4330 set to UPDATE_REQUEST to the Home Diameter AAA server (7). This 4331 message contains the units used thus far. The home Diameter AAA 4332 server forwards the CCR to the Diameter credit-control server (8). 4333 The Diameter credit-control server debits the used units from the end 4334 user's account and allocates a new quota that is returned to the home 4335 Diameter AAA server in the Diameter Credit- Control-Answer (9). The 4336 message is forwarded to the NAS (10). During the ongoing credit- 4337 control session, the authorization lifetime expires, and the 4338 authorization/authentication client in the NAS performs service 4339 specific re-authorization to the home Diameter AAA server, as usual. 4340 The credit-control client populates the AAR with the Credit-Control 4341 AVP set to RE_AUTHORIZATION, indicating that the credit-control 4342 server shall not be contacted, as the credit authorization is 4343 controlled by the burning rate of the granted units (11). The home 4344 Diameter AAA server performs service-specific re- authorization as 4345 usual and returns the AA-Answer to the NAS (12). The end user logs 4346 off from the network (13). To debit the used units from the end 4347 user's account and to stop the credit-control session, the NAS sends 4348 a Diameter Credit-Control-Request with CC-Request-Type set to 4349 TERMINATION_REQUEST to the home Diameter AAA server (14). The home 4350 Diameter AAA server forwards the CCR to the credit-control server 4351 (15). The Diameter credit-control server acknowledges the session 4352 termination by sending a Diameter Credit-Control-Answer to the home 4353 Diameter AAA server (16). The home Diameter AAA server forwards the 4354 answer to the NAS (17). STR/STA takes place between the NAS and home 4355 Diameter AAA server, as usual (18-19). 4357 B.2. Flow II 4359 SIP Proxy/Registrar AAA 4360 A (CC Client) Server B CC Server 4361 |(i) REGISTER | | | | 4362 |------------->|(ii) | | | 4363 | |------------->| | | 4364 | |authentication & | | 4365 | |authorization | | | 4366 | |<-------------| | | 4367 |(iii)200 OK | | | 4368 |<-------------| | | 4369 : : : : 4370 |(1) INVITE | : 4371 |------------->| 4372 | |(2) CCR (Initial, SIP specific AVP) | 4373 | |------------------------------------------->| 4374 | |(3) CCA (Granted-Units) | 4375 | |<-------------------------------------------| 4376 | |(4) INVITE | | 4377 | |---------------------------->| | 4378 : : : : 4379 | |(5) CCR (update, Used-Units) | 4380 | |------------------------------------------->| 4381 | |(6) CCA (Granted-Units) | 4382 | |<-------------------------------------------| 4383 : : : : 4384 |(7) BYE | | | 4385 |------------->| | | 4386 | |(8) BYE | | 4387 | |---------------------------->| | 4388 | |(9) CCR (termination, Used-Units) | 4389 | |------------------------------------------->| 4390 | |(10) CCA () | 4391 | |<-------------------------------------------| 4392 | | | | 4394 Figure 11: Flow II 4396 This is an example of Diameter credit-control for SIP sessions. 4397 Although the flow focuses on illustrating the usage of credit-control 4398 messages, the SIP signaling is inaccurate, and the diagram is not by 4399 any means an attempt to define a service provider's SIP network. 4400 However, for the sake of this example, some assumptions are made 4401 below. 4403 Typically, prepaid services based, for example, on time usage for SIP 4404 session require an entity in the service provider network to 4405 intercept all the requests within the SIP dialog in order to detect 4406 events, such as session establishment and session release, that are 4407 essential to perform credit-control operations with the credit- 4408 control server. Therefore, in this example, it is assumed that the 4409 SIP Proxy adds a Record-Route header in the initial SIP INVITE to 4410 make sure that all the future requests in the created dialog traverse 4411 through it (for the definitions of 'Record-Route' and 'dialog' please 4412 refer to [RFC3261]). Finally, the degree of credit-control measuring 4413 of the media by the proxy depends on the business model design used 4414 in setting up the end system and proxies in the SIP network. 4416 The end user (SIP User Agent A) sends REGISTER with credentials (i). 4417 The SIP Proxy sends a request to the home AAA server to perform 4418 Multimedia authentication and authorization by using, for instance, 4419 Diameter Multimedia application (ii). The home AAA server checks 4420 that the credentials are correct and checks the user profile. 4421 Eventually, 200 OK response (iii) is sent to the UA. Note that the 4422 Authentication and Authorization is valid for the registration 4423 validity period duration (i.e., until re-registration is performed). 4424 Several SIP sessions may be established without re-authorization. 4426 UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- 4427 Control-Request (INITIAL_REQUEST) to the Diameter credit-control 4428 server (2). The Credit-Control-Request contains information obtained 4429 from the SIP signaling describing the requested service (e.g., 4430 calling party, called party, Session Description Protocol 4431 attributes). The Diameter credit-control server checks the end 4432 user's account balance, rates the service, and reserves credit from 4433 the end user's account. The reserved quota is returned to the SIP 4434 Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy 4435 forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. 4436 The media flows between them, and the SIP Proxy starts measuring the 4437 quota. At the expiry of the allocated quota, the SIP Proxy sends a 4438 Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 4439 credit-control server (5). This message contains the units used thus 4440 far. The Diameter credit-control server debits the used units from 4441 the end user's account and allocates new credit that is returned to 4442 the SIP Proxy in the Diameter Credit-Control-Answer (6). The end 4443 user terminates the service by sending a BYE (7). The SIP Proxy 4444 forwards the BYE message to UA B (8) and sends a Diameter Credit- 4445 Control-Request (TERMINATION_REQUEST) to the credit-control server 4446 (9). The Diameter credit-control server acknowledges the session 4447 termination by sending a Diameter Credit-Control-Answer to the SIP 4448 Proxy (10). 4450 B.3. Flow III 4452 MMS Server 4453 A (CC Client) B CC Server 4454 |(1) Send MMS | | | 4455 |--------------->| | | 4456 | |(2) CCR (event, DIRECT_DEBITING,| 4457 | | MMS specific AVP) | 4458 | |-------------------------------->| 4459 | |(3) CCA (Granted-Units) | 4460 | |<--------------------------------| 4461 |(4) Send MMS Ack| | | 4462 |<---------------| | | 4463 | |(5) Notify MMS | | 4464 | |--------------->| | 4465 : : : : 4466 | |(6) Retrieve MMS| | 4467 | |<---------------| | 4468 | |(7) Retrieve MMS| | 4469 | | Ack | | 4470 | |--------------->| | 4471 | | | | 4473 Figure 12: Flow III 4475 A credit-control flow for Multimedia Messaging Services is shown in 4476 Figure A.3. The sender is charged as soon as the messaging server 4477 successfully stores the message. 4479 The end user A sends a Multimedia Message (MMS) to the MMS server 4480 (1). The MMS server stores the message and sends a Diameter Credit- 4481 Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) 4482 to the Diameter credit-control server (2). The Credit-Control- 4483 Request contains information about the MMS message (e.g., size, 4484 recipient address, image coding type). The Diameter credit-control 4485 server checks the end user's account balance, rates the service, and 4486 debits the service from the end user's account. The granted quota is 4487 returned to the MMS server in the Diameter Credit-Control-Answer (3). 4488 The MMS server acknowledges the successful reception of the MMS 4489 message (4). The MMS Server notifies the recipient about the new MMS 4490 (5), and end user B retrieves the message from the MMS message store 4491 (6),(7). 4493 B.4. Flow IV 4494 MMS Server 4495 Content Server (CC Client) B CC Server 4496 |(1) Send MMS | | | 4497 |--------------->| | | 4498 | |(2) CCR (event, CHECK_BALANCE, | 4499 | | MMS specific AVP) | 4500 | |-------------------------------->| 4501 | |(3) CCA (ENOUGH_CREDIT) | 4502 | |<--------------------------------| 4503 |(4) Send MMS Ack| | | 4504 |<---------------| | | 4505 | |(5) Notify MMS | | 4506 | |--------------->| | 4507 : : : : 4508 | |(6) Retrieve MMS| | 4509 | |<---------------| | 4510 | |(7) CCR (event, DIRECT_DEBITING,| 4511 | | MMS specific AVP) | 4512 | |-------------------------------->| 4513 | |(8) CCA (Granted-Units) | 4514 | |<--------------------------------| 4515 | |(9) Retrieve MMS| | 4516 | | Ack | | 4517 | |--------------->| | 4518 | | | | 4520 Figure 13: Flow IV 4522 This is an example of Diameter credit-control for direct debiting 4523 using the Multimedia Messaging Service environment. Although the 4524 flow focuses on illustrating the usage of credit-control messages, 4525 the MMS signaling is inaccurate, and the diagram is not by any means 4526 an attempt to define any service provider's MMS configuration or 4527 billing model. 4529 A credit-control flow for Multimedia Messaging Service is shown in 4530 Figure A.4. The recipient is charged at the message delivery. 4532 A content server sends a Multimedia Message (MMS) to the MMS server 4533 (1) that stores the message. The message recipient will be charged 4534 for the MMS message in this case. As there can be a substantially 4535 long time between the receipt of the message at the MMS server and 4536 the actual retrieval of the message, the MMS server does not 4537 establish any credit-control session to the Diameter credit-control 4538 server but performs first only a balance check (without any credit 4539 reservation) by sending a Diameter Credit-Control-Request 4540 (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that 4541 end user B can cover the cost for the MMS (2). The Diameter credit- 4542 control server checks the end user's account balance and returns the 4543 answer to the MMS server in the Diameter Credit-Control-Answer (3). 4544 The MMS server acknowledges the successful reception of the MMS 4545 message (4). The MMS server notifies the recipient of the new MMS 4546 (5), and after some time end user B retrieves the message from the 4547 MMS message store (6). The MMS server sends a Diameter Credit- 4548 Control-Request (EVENT_REQUEST with Requested-Action: 4549 DIRECT_DEBITING) to the Diameter credit-control server (7). The 4550 Credit-Control-Request contains information about the MMS message 4551 (e.g., size, recipient address, coding type). The Diameter credit- 4552 control server checks the end user's account balance, rates the 4553 service, and debits the service from the end user's account. The 4554 granted quota is returned to the MMS server in the Diameter Credit- 4555 Control-Request (8). The MMS is transferred to end user B (9). 4557 Note that the transfer of the MMS message can take an extended time 4558 and can fail, in which case a recovery action is needed. The MMS 4559 server should return the already debited units to the user's account 4560 by using the REFUND action described in Section 6.4. 4562 B.5. Flow V 4564 SIP Controller 4565 A (CC Client) B CC Server 4566 |(1)INVITE B(SDP)| | | 4567 |--------------->| | | 4568 | |(2) CCR (event, PRICE_ENQUIRY, | 4569 | | SIP specific AVPs) | 4570 | |-------------------------------->| 4571 | |(3) CCA (Cost-Information) | 4572 | |<--------------------------------| 4573 | (4)MESSAGE(URL)| | | 4574 |<---------------| | | 4575 |(5)HTTP GET | | | 4576 |--------------->| | | 4577 |(6)HTTP POST | | | 4578 |--------------->|(7)INVITE(SDP) | | 4579 | |--------------->| | 4580 | | (8)200 OK | | 4581 | (9)200 OK |<---------------| | 4582 |<---------------| | | 4584 Figure 14: Flow V 4586 This is an example of Diameter credit-control for SIP sessions. 4587 Although the flow focuses on illustrating the usage of credit-control 4588 messages, the SIP signaling is inaccurate, and the diagram is not by 4589 any means an attempt to define a service provider's SIP network. 4591 Figure A.5 is an example of Advice of Charge (AoC) service for SIP 4592 call. User A can be either a postpaid or prepaid subscriber using 4593 the AoC service. It is assumed that the SIP controller also has HTTP 4594 capabilities and delivers an interactive AoC web page with, for 4595 instance, the cost information, the details of the call derived from 4596 the SDP, and a button to accept/not accept the charges. (There may 4597 be many other ways to deliver AoC information; however, this flow 4598 focuses on the use of the credit-control messages.) The user has 4599 been authenticated and authorized prior to initiating the call and 4600 subscribed to AoC service. 4602 UA A sends an INVITE with SDP to B (1). The SIP controller 4603 determines that the user is subscribed to AoC service and sends a 4604 Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: 4605 PRICE_ENQUIRY) to the Diameter credit-control server (2). The 4606 Credit-Control-Request contains SIP specific AVPs derived from the 4607 SIP signaling, describing the requested service (e.g., calling party, 4608 called party, Session Description Protocol attributes). The Diameter 4609 credit-control server determines the cost of the service and returns 4610 the Credit-Control-Answer including the Cost-Information AVP (3). 4611 The SIP controller manufactures the AoC web page with information 4612 received in SIP signaling and with the cost information received from 4613 the credit-control server. Then it sends a SIP MESSAGE that contains 4614 a URL pointing to the AoC information web page (4). At the receipt 4615 of the SIP MESSAGE, A's UA automatically invokes the web browser that 4616 retrieves the AoC information (5). The user clicks on a proper 4617 button and accepts the charges (6). The SIP controller continues the 4618 session and sends the INVITE to the B party, which accepts the call 4619 (7,8,9). 4621 B.6. Flow VI 4623 Gaming Server 4624 End User (CC Client) CC Server 4625 | (1)Service Delivery | | 4626 |<---------------------->| | 4627 : : : 4628 : : : 4629 | |(2)CCR(event,REFUND,Requested- 4630 | |Service-Unit,Service-Parameter-Info) 4631 | |----------------------->| 4632 | | (3)CCA(Cost-Information) 4633 | |<-----------------------| 4634 | (4)Notification | | 4635 |<-----------------------| | 4637 Figure 15: Flow VI 4639 Figure A.6 illustrates a credit-control flow for the REFUND case. It 4640 is assumed that there is a trusted relationship and secure connection 4641 between the Gaming server and the Diameter credit-control server. 4642 The end user may be a prepaid subscriber or a postpaid subscriber. 4644 While the end user is playing the game (1), she enters a new level 4645 that entitles her to a bonus. The Gaming server sends a Diameter 4646 Credit-Control-Request (EVENT_REQUEST with Requested-Action: 4647 REFUND_ACCOUNT) to the Diameter credit-control server (2). The 4648 Credit-Control-Request Request contains the Requested-Service-Unit 4649 AVP with the CC-Service-Specific-Units containing the number of 4650 points the user just won. The Service-Parameter-Info AVP is also 4651 included in the request and specifies the service event to be rated 4652 (e.g., Tetris Bonus). From information received, the Diameter 4653 credit-control server determines the amount to be credited, refunds 4654 the user's account, and returns the Credit-Control-Answer, including 4655 the Cost-Information AVP (3). The Cost-Information indicates the 4656 credited amount. At the first opportunity, the Gaming server 4657 notifies the end user of the credited amount (4). 4659 B.7. Flow VII 4660 SIP Controller Top-Up 4661 A (CC Client) Server B CC Server 4662 | | | | | 4663 | | (1) CCR(Update,Used-Unit) | | 4664 | |------------------------------------------>| 4665 | | (2) CCA(Final-Unit, Redirect)| 4666 | |<------------------------------------------| 4667 : : : : : 4668 : : : : : 4669 | | (3) CCR(Update, Used-Units)| | 4670 | |------------------------------------------>| 4671 | | (3a)INVITE("hold") | | 4672 | |--------------------------->| | 4673 | | | (4) CCA(Validity-Time)| 4674 | |<------------------------------------------| 4675 | (5)INVITE | (6)INVITE | | | 4676 |<--------------|------------->| | | 4677 | (7)RTP | | | 4678 |..............................| | | 4679 | | (8)BYE | | | 4680 | |<-------------| | | 4681 | | (9)CCR(Update) | | 4682 | |------------------------------------------>| 4683 | | (10)CCA(Granted-Unit) | 4684 | |<------------------------------------------| 4685 | (12)INVITE | (11)INVITE | | 4686 |<--------------|--------------------------->| | 4688 Figure 16: Flow VII 4690 Figure A.7 is an example of the graceful service termination for a 4691 SIP call. It is assumed that the call is set up so that the 4692 controller is in the call as a B2BUA (Back to Back User Agent) 4693 performing third-party call control (3PCC). Note that the SIP 4694 signaling is inaccurate, as the focus of this flow is in the graceful 4695 service termination and credit-control authorization. The best 4696 practice for 3PCC is defined in [RFC3725]. 4698 The call is ongoing between users A and B; user A has a prepaid 4699 subscription. At the expiry of the allocated quota, the SIP 4700 controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) 4701 to the Diameter credit-control server (1). This message contains the 4702 units used thus far. The Diameter credit-control server debits the 4703 used units from the end user's account and allocates the final quota 4704 returned to the SIP controller in the Diameter Credit-Control-Answer 4705 (2). This message contains the Final-Unit-Indication AVP with the 4706 Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to 4707 SIP URI, and the Redirect-Server-Address set to the Top-up server 4708 name (e.g., sip:sip-topup-server@domain.com). At the expiry of the 4709 final allocated quota, the SIP controller sends a Diameter Credit- 4710 Control-Request (UPDATE_REQUEST) to the Diameter credit-control 4711 server (3) and places the called party on "hold" by sending an INVITE 4712 with the appropriate connection address in the SDP (3a). The Credit- 4713 Control-Request message contains the units used thus far. The 4714 Diameter credit-control server debits the used units from the end 4715 user's account but does not make any credit reservation. The Credit- 4716 Control-Answer message, which contains the Validity-Time to supervise 4717 the graceful service termination, is returned to the SIP controller 4718 (4). The SIP controller establishes a SIP session between the 4719 prepaid user and the Top-up server (5, 6). The Top-up server plays 4720 an announcement and prompts the user to enter a credit card number 4721 and the amount of money to be used to replenish the account (7). The 4722 Top-up server validates the credit card number and replenishes the 4723 user's account (using some means outside the scope of this 4724 specification) and releases the SIP session (8). The SIP controller 4725 can now assume that communication between the prepaid user and the 4726 Top-up server took place. It sends a spontaneous Credit- Control- 4727 Request (UPDATE_REQUEST) to the Diameter credit-control server to 4728 check whether the account has been replenished (9). The Diameter 4729 credit-control server reserves credit from the end user's account and 4730 returns the reserved quota to the SIP controller in the Credit- 4731 Control-Answer (10). At this point, the SIP controller re- connects 4732 the caller and the called party (11,12). 4734 B.8. Flow VIII 4735 NAS Top-up CC 4736 End-User (CC Client) AAA Server Server Server 4737 |(1)User Logon |(2)AA Request (CC AVPs) | | 4738 |------------------>|------------------->| | | 4739 | | |(3)CCR(initial, CC AVPs) 4740 | | |------------------->| 4741 | | |(4)CCA(Final-Unit, | 4742 | | | Validity-Time)| 4743 | | |<-------------------| 4744 | |(5)AA Answer(Final-Unit,Validity-Time) | 4745 |(6)Limited Access |<-------------------| | | 4746 | granted | | | | 4747 |<----------------->| | | | 4748 | | | | | 4749 | (7)TCP/HTTP | (8)TCP/HTTP | | 4750 |<----------------->|<----------------------------->| | 4751 | (9) Replenish account | | 4752 |<------------------------------------------------->| | 4753 | | | (10)RAR | 4754 | |<-------------------|<-------------------| 4755 | | (11) RAA | | 4756 | |------------------->|------------------->| 4757 | |(12)CCR(update) | | 4758 | |------------------->|(13)CCR(Update) | 4759 | | |------------------->| 4760 | | |(14)CCA(Granted-Units) 4761 | |(15)CCA(Granted-Units)<------------------| 4762 | |<-------------------| | 4764 Figure 17: Flow VIII 4766 Figure A.8 is an example of the graceful service termination 4767 initiated when the first interrogation takes place because the user's 4768 account is empty. In this example, the credit-control server 4769 supports the server-initiated credit re-authorization. The Diameter 4770 [RFC7155] is implemented in the Network Access Server (NAS). 4772 The user logs on to the network (1). The Diameter NAS sends a 4773 Diameter AA-Request to the home Diameter AAA server. The credit- 4774 control client populates the AAR with the Credit-Control AVP set to 4775 CREDIT_AUTHORIZATION, and service specific AVPs are included, as 4776 usual [RFC7155]. The home Diameter AAA server performs service 4777 specific Authentication and Authorization, as usual. The home 4778 Diameter AAA server determines that the user has a prepaid 4779 subscription and notices from the Credit-Control AVP that the NAS has 4780 credit-control capabilities. It sends a Diameter Credit-Control- 4781 Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter 4782 credit-control server to perform credit authorization (3) and to 4783 establish a credit-control session. (The home Diameter AAA server 4784 may forward service specific AVPs received from the NAS as input for 4785 the rating process.) The Diameter credit-control server checks the 4786 end user's account balance, determines that the account cannot cover 4787 the cost of the service, and initiates the graceful service 4788 termination. The Credit-Control-Answer is returned to the home 4789 Diameter AAA server (4). This message contains the Final-Unit- 4790 Indication AVP and the Validity-Time AVP set to a reasonable amount 4791 of time to give the user a chance to replenish his/her account (e.g., 4792 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- 4793 Action set to REDIRECT, the Redirect-Address-Type set to URL, and the 4794 Redirect-Server-Address set to the HTTP Top-up server name. The home 4795 Diameter AAA server sends the received credit-control AVPs to the NAS 4796 in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts 4797 the credit-control session and immediately starts the graceful 4798 service termination, as instructed by the server. The NAS grants 4799 limited access to the user (6). The HTTP client software running in 4800 the user's device opens the transport connection redirected by the 4801 NAS to the Top-up server (7,8). The user is displayed an appropriate 4802 web page on which to enter the credit card number, and the amount of 4803 money to be used to replenish the account, and with a notification 4804 message that she is granted unlimited access if the replenishment 4805 operation will be successfully executed within the next, for example, 4806 10 minutes. The Top-up server validates the credit card number and 4807 replenishes the user's account (using some means outside the scope of 4808 this specification)(9). After successful account top-up, the credit- 4809 control server sends a Re-Auth-Request message to the NAS (10). The 4810 NAS acknowledges the request by returning the Re-Auth- Answer message 4811 (11) and initiates the credit re-authorization by sending a Credit- 4812 Control-request (UPDATE_REQUEST) to the Diameter credit-control 4813 server (12,13). 4815 The Diameter credit-control server reserves credit from the end 4816 user's account and returns the reserved quota to the NAS via the home 4817 Diameter AAA server in the Credit-Control-Answer (14,15). The NAS 4818 removes the restriction placed by the graceful service termination 4819 and starts monitoring the granted units. 4821 B.9. Flow IX 4823 The Diameter credit-control application defines the Multiple- 4824 Services-Credit-Control AVP that can be used to support independent 4825 credit-control of multiple services in a single credit-control (sub-) 4826 session for service elements that have such capabilities. It is 4827 possible to request and allocate resources as a credit pool that is 4828 shared between services or rating groups. 4830 The flow example hereafter illustrates a usage scenario where the 4831 credit-control client and server support independent credit-control 4832 of multiple services, as defined in Section 5.1.2. It is assumed 4833 that Service-Identifiers, Rating-Groups, and their associated 4834 parameters (e.g., IP 5-tuple) are locally configured in the service 4835 element or provisioned by an entity other than the credit-control 4836 server. 4838 End User Service Element CC Server 4839 (CC client) 4840 |(1)User logon | | 4841 |------------------>|(2)CCR(initial, Service-Id access, | 4842 | | Access specific AVPs, | 4843 | | Multiple-Service-Indicator) | 4844 | |---------------------------------------->| 4845 | |(3)CCA(Multiple-Services-CC ( | 4846 | | Granted-Units(Total-Octets), | 4847 | | Service-Id access, | 4848 | | Validity-time, | 4849 | | G-S-U-Pool-Reference(Pool-Id 1, | 4850 | | Multiplier 10))) | 4851 | |<----------------------------------------| 4852 : : : 4853 |(4)Service-Request (Service 1) | 4854 |------------------>|(5)CCR(update, Multiple-Services-CC( | 4855 | | Requested-Units(), Service-Id 1, | 4856 | | Rating-Group 1)) | 4857 | |---------------------------------------->| 4858 | |(6)CCA(Multiple-Services-CC ( | 4859 | | Granted-Units(Time), | 4860 | | Rating-Group 1, | 4861 | | G-S-U-Pool-Reference(Pool-Id 1, | 4862 | | Multiplier 1))) | 4863 | |<----------------------------------------| 4864 : : : 4865 |(7)Service-Request (Service 2) | 4866 |------------------>| | 4867 : : : 4868 : : : 4869 |(8)Service-Request (Service 3&4) | 4870 |------------------>|(9)CCR(update, Multiple-Services-CC ( | 4871 | | Requested-Units(), Service-Id 3, | 4872 | | Rating-Group 2), | 4873 | | Multiple-Services-CC ( | 4874 | | Requested-Units(), Service-Id 4, | 4875 | | Rating-Group 3)) | 4876 | |---------------------------------------->| 4877 | |(10)CCA(Multiple-Services-CC ( | 4878 | | Granted-Units(Total-Octets), | 4879 | | Service-Id 3, Rating-Group 2, | 4880 | | Validity-time, | 4881 | | G-S-U-Pool-Reference(Pool-Id 2, | 4882 | | Multiplier 2)), | 4883 | | Multiple-Services-CC ( | 4884 | | Granted-Units(Total-Octets), | 4885 | | Service-Id 4, Rating-Group 3 | 4886 | | Validity-Time, | 4887 | | Final-Unit-Ind.(Terminate), | 4888 | | G-S-U-Pool-Reference(Pool-Id 2, | 4889 | | Multiplier 5))) | 4890 | |<----------------------------------------| 4891 : : : 4892 : : : 4893 | +--------------+ | | 4894 | |Validity time | |(11)CCR(update, | 4895 | |expires for | | Multiple-Services-CC ( | 4896 | |Service-Id | | Requested-Unit(), | 4897 | | access | | Used-Units(In-Octets,Out-Octets),| 4898 | +--------------+ | Service-Id access)) | 4899 | |---------------------------------------->| 4900 | |(12)CCA(Multiple-Services-CC ( | 4901 | | Granted-Units(Total-Octets), | 4902 | | Service-Id access, | 4903 | | Validity-Time, | 4904 | | G-S-U-Pool-Reference(Pool-Id 1, | 4905 | | Multiplier 10))) | 4906 | |<----------------------------------------| 4907 : : : 4908 : : : 4909 | +--------------+ | | 4910 | |Total Quota | |(13)CCR(update, | 4911 | |elapses for | | Multiple-Services-CC ( | 4912 | |pool 2: | | Requested-Unit(), | 4913 | |service 4 not | | Used-Units(In-Octets,Out-Octets),| 4914 | |allowed, | | Service-Id 3, Rating-group 2), | 4915 | |service 3 cont| | Multiple-Services-CC ( | 4916 | +--------------+ | Used-Units(In-Octets,Out-Octets),| 4917 | | Service-Id 4, Rating-Group 3)) | 4918 | |---------------------------------------->| 4919 | |(14)CCA(Multiple-Services-CC ( | 4920 | | Result-Code 4011, | 4921 | | Service-Id 3)) | 4922 | |<----------------------------------------| 4923 : : : 4924 : : : 4925 |(15) User logoff | | 4926 |------------------>|(16)CCR(term, | 4927 | | Multiple-Services-CC ( | 4928 | | Used-Units(In-Octets,Out-Octets),| 4929 | | Service-Id access), | 4930 | | Multiple-Services-CC ( | 4931 | | Used-Units(Time), | 4932 | | Service-Id 1, Rating-Group 1), | 4933 | | Multiple-Services-CC ( | 4934 | | Used-Units(Time), | 4935 | | Service-Id 2, Rating-Group 1)) | 4936 | |---------------------------------------->| 4937 | |(17)CCA(term) | 4938 | |<----------------------------------------| 4940 Figure 18: Flow example independent credit-control of multiple 4941 services in a credit-control (sub-)Session 4943 The user logs on to the network (1). The service element sends a 4944 Diameter Credit-Control-Request with CC-Request-Type set to 4945 INITIAL_REQUEST to the Diameter credit-control server to perform 4946 credit authorization for the bearer service (e.g., Internet access 4947 service) and to establish a credit-control session (2). In this 4948 message, the credit-control client indicates support for independent 4949 credit-control of multiple services within the session by including 4950 the Multiple-Service-Indicator AVP. The Diameter credit-control 4951 server checks the end user's account balance, with rating information 4952 received from the client (i.e., Service-Id and access specific AVPs), 4953 rates the request, and reserves credit from the end user's account. 4954 Suppose that the server reserves $5 and determines that the cost is 4955 $1/MB. It then returns to the service element a Credit-Control- 4956 Answer message that includes the Multiple-Services-Credit-Control AVP 4957 with a quota of 5MB associated to the Service-Id (access), to a 4958 multiplier value of 10, and to the Pool-Id 1 (3). 4960 The user uses Service 1 (4). The service element sends a Diameter 4961 Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to 4962 the credit-control server to perform credit authorization for service 4963 1 (5). This message includes the Multiple-Services-Credit-Control 4964 AVP to request service units for Service 1 that belong to Rating- 4965 Group 1. The Diameter credit-control server determines that Service 4966 1 draws credit resources from the same account as the access service 4967 (i.e., pool 1). It rates the request according to Service- Id/ 4968 Rating-Group and updates the existing reservation by requesting more 4969 credit. Suppose that the server reserves $5 more (now the 4970 reservation is $10) and determines that the cost is $0.1/minute. The 4971 server authorizes the whole Rating-Group. It then returns to the 4972 service element a Credit-Control-Answer message that includes the 4973 Multiple-Services-Credit-Control AVP with a quota of 50min. 4975 associated to the Rating-Group 1, to a multiplier value of 1, and to 4976 the Pool-Id 1 (6). The client adjusts the total amount of resources 4977 for pool 1 according the received quota, which gives S for Pool 1 = 4978 100. 4980 The user uses Service 2, which belongs to the authorized Rating- 4981 Group, 1 (7). Resources are then consumed from the pool 1. 4983 The user now requests Services 3 and 4 as well, which are not 4984 authorized (8). The service element sends a Diameter Credit- 4985 Control-Request with CC-Request-Type set to UPDATE_REQUEST to the 4986 credit-control server in order to perform credit authorization for 4987 Services 3 and 4 (9). This message includes two instances of the 4988 Multiple-Services-Credit-Control AVP to request service units for 4989 Service 3 that belong to Rating-Group 2 and for Service 4 that belong 4990 to Rating-Group 3. The Diameter credit-control server determines 4991 that Services 3 and 4 draw credit resources from another account 4992 (i.e., pool 2). It checks the end user's account balance and, 4993 according to Service-Ids/Rating-Groups information, rates the 4994 request. Then it reserves credit from pool 2. 4996 For example, the server reserves $5 and determines that Service 3 4997 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes 4998 only Services 3 and 4. It returns to the service element a Credit- 4999 Control-Answer message that includes two instances of the Multiple- 5000 Services-Credit-Control AVP (10). One instance grants a quota of 5001 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and 5002 to the Pool-Id 2. The other instance grants a quota of 5 MB 5003 associated to the Service-Id 4 to a multiplier value of 5 and to the 5004 Pool-Id 2. 5006 The server also determines that pool 2 is exhausted and Service 4 is 5007 not allowed to continue after these units will be consumed. 5008 Therefore the Final-Unit-Indication AVP with action TERMINATE is 5009 associated to the Service-Id 4. The client calculates the total 5010 amount of resources that can be used for pool 2 according the 5011 received quotas and multipliers, which gives S for Pool 2 = 50. 5013 The Validity-Time for the access service expires. The service 5014 element sends a Credit-Control-Request message to the server in order 5015 to perform credit re-authorization for Service-Id (access) (11). 5016 This message carries one instance of the Multiple-Services-Credit- 5017 Control AVP that includes the units used by this service. Suppose 5018 that the total amount of used units is 4MB. The client adjusts the 5019 total amount of resources for pool 1 accordingly, which gives S for 5020 Pool 1 = 60. 5022 The server deducts $4 from the user's account and updates the 5023 reservation by requesting more credit. Suppose that the server 5024 reserves $5 more (now the reservation is $11) and already knows the 5025 cost of the Service-Id (access), which is $1/MB. It then returns to 5026 the service element a Credit-Control-Answer message that includes the 5027 Multiple-Services-Credit-Control AVP with a quota of 5 MB associated 5028 to the Service-Id (access), to a multiplier value of 10, and to the 5029 Pool-Id 1 (12). The client adjusts the total amount of resources for 5030 pool 1 according the received quota, which gives S for Pool 1 = 110. 5032 Services 3 and 4 consume the total amount of pool 2 credit resources 5033 (i.e., C1*2 + C2*5 >= S). The service element immediately starts the 5034 TERMINATE action concerning Service 4 and sends a Credit-Control- 5035 Request message with CC-Request-Type set to UPDATE_REQUEST to the 5036 credit-control server in order to perform credit re-authorization for 5037 Service 3 (13). This message contains two instances of the Multiple- 5038 Services-Credit-Control AVP to report the units used by Services 3 5039 and 4. The server deducts the last $5 from the user's account (pool 5040 2) and returns the answer with Result-Code 4011 in the Multiple- 5041 Services-Credit-Control AVP to indicate that Service 3 can continue 5042 without credit-control (14). 5044 The end user logs off from the network (15). To debit the used units 5045 from the end user's account and to stop the credit-control session, 5046 the service element sends a Diameter Credit-Control-Request with CC- 5047 Request-Type set to TERMINATION_REQUEST to the credit-control server 5048 (16). This message contains the units consumed by each of the used 5049 services in multiple instances of the Multiple-Services-Credit- 5050 Control AVP. The used units are associated with the relevant 5051 Service-Identifier and Rating-Group. The Diameter credit-control 5052 server debits the used units to the user's account (Pool 1) and 5053 acknowledges the session termination by sending a Diameter Credit- 5054 Control-Answer to the service element (17). 5056 Appendix C. Changes relative to RFC4006 5058 The following changes were made relative to RFC4006: 5060 Update references to obsolete RFC 3588 to refer to RFC 6733. 5062 Update references to obsolete RFC 4005 to refer to RFC 7155. 5064 Update reference to "IPsec or TLS" to be "TLS/TCP, DTLS/SCTP or 5065 IPsec" 5067 Update AVP per Errata ID 3329 5069 Authors' Addresses 5071 Lyle Bertz (editor) 5072 Sprint 5073 6220 Sprint Parkway 5074 Overland Park, KS 66251 5075 United States 5077 Email: lyleb551144@gmail.com 5079 David Dolson (editor) 5080 Sandvine 5081 408 Albert Street 5082 Waterloo, ON N2L 3V3 5083 Canada 5085 Phone: +1 519 880 2400 5086 Email: ddolson@sandvine.com 5088 Yuval Lifshitz (editor) 5089 Sandvine 5090 408 Albert Street 5091 Waterloo, ON N2L 3V3 5092 Canada 5094 Phone: +1 519 880 2400 5095 Email: ylifshitz@sandvine.com 5097 Harri Hakala 5098 Oy L M Ericsson Ab 5099 Joukahaisenkatu 1 5100 Turku 20520 5101 Finland 5103 Phone: +358 2 265 3722 5104 Email: Harri.Hakala@ericsson.com 5105 Leena Mattila 5106 Oy L M Ericsson Ab 5107 Joukahaisenkatu 1 5108 Turku 20520 5109 Finland 5111 Phone: +358 2 265 3731 5112 Email: Leena.Mattila@ericsson.com 5114 Juha-Pekka Koskinen 5115 Nokia Networks 5116 Hatanpaanvaltatie 30 5117 Tampere 33100 5118 Finland 5120 Phone: +358 7180 74027 5121 Email: juha-pekka.koskinen@nokia.com 5123 Marco Stura 5124 Nokia Networks 5125 Hiomotie 32 5126 Tampere 00380 5127 Helsinki 5129 Phone: +358 7180 64308 5130 Email: marco.stura@nokia.com 5132 John Loughney 5133 Nokia Research Center 5134 Itamerenkatu 11-13 5135 Tampere 00180 5136 Helsinki 5138 Phone: +358 50 483 642 5139 Email: John.Loughney@nokia.com