draft-ietf-dime-rfc4006bis-12.txt   rfc8506.txt 
Network Working Group L. Bertz, Ed. Internet Engineering Task Force (IETF) L. Bertz, Ed.
Internet-Draft Sprint Request for Comments: 8506 Sprint
Obsoletes: 4006 (if approved) D. Dolson, Ed. Obsoletes: 4006 D. Dolson, Ed.
Intended status: Standards Track Y. Lifshitz, Ed. Category: Standards Track Y. Lifshitz, Ed.
Expires: March 17, 2019 Sandvine ISSN: 2070-1721 Sandvine
September 13, 2018 March 2019
Diameter Credit-Control Application Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-12
Abstract Abstract
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end-user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. The Diameter Credit- messaging services, and download services. The Diameter Credit-
Control application as defined in this document obsoletes RFC4006, Control application as defined in this document obsoletes RFC 4006,
and it must be supported by all new Diameter Credit-Control and it must be supported by all new Diameter Credit-Control
Application implementations. application implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 17, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8506.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................6
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language ......................................7
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology ................................................7
1.3. Advertising Application Support . . . . . . . . . . . . . 8 1.3. Advertising Application Support ............................9
2. Architecture Models . . . . . . . . . . . . . . . . . . . . . 8 2. Architecture Models .............................................9
3. Credit-Control Messages . . . . . . . . . . . . . . . . . . . 10 3. Credit-Control Messages ........................................11
3.1. Credit-Control-Request (CCR) Command . . . . . . . . . . 10 3.1. Credit-Control-Request (CCR) Command ......................11
3.2. Credit-Control-Answer (CCA) Command . . . . . . . . . . . 11 3.2. Credit-Control-Answer (CCA) Command .......................12
4. Credit-Control Application Overview . . . . . . . . . . . . . 12 4. Credit-Control Application Overview ............................13
4.1. Service-Specific Rating Input and Interoperability . . . 14 4.1. Service-Specific Rating Input and Interoperability ........14
4.1.1. Specifying Rating Input AVPs . . . . . . . . . . . . 14 4.1.1. Specifying Rating Input AVPs .......................15
4.1.2. Service-Specific Documentation . . . . . . . . . . . 15 4.1.2. Service-Specific Documentation .....................16
4.1.3. Handling of Unsupported/Incorrect Rating Input . . . 16 4.1.3. Handling of Unsupported/Incorrect Rating Input .....16
4.1.4. RADIUS Vendor-Specific Rating Attributes . . . . . . 16 4.1.4. RADIUS Vendor-Specific Rating Attributes ...........17
5. Session Based Credit-Control . . . . . . . . . . . . . . . . 16 5. Session-Based Credit-Control ...................................17
5.1. General Principles . . . . . . . . . . . . . . . . . . . 16 5.1. General Principles ........................................17
5.1.1. Basic Tariff-Time Change Support . . . . . . . . . . 17 5.1.1. Basic Support for Tariff Time Change ...............18
5.1.2. Credit-Control for Multiple Services within a 5.1.2. Credit-Control for Multiple Services within
(sub-)Session . . . . . . . . . . . . . . . . . . . . 18 a (Sub-)Session ....................................19
5.2. First Interrogation . . . . . . . . . . . . . . . . . . . 22 5.2. First Interrogation .......................................23
5.2.1. First Interrogation after Authorization and 5.2.1. First Interrogation after Authorization and
Authentication . . . . . . . . . . . . . . . . . . . 24 Authentication .....................................25
5.2.2. First Interrogation Included with Authorization 5.2.2. First Interrogation Included with
Messages . . . . . . . . . . . . . . . . . . . . . . 25 Authorization Messages .............................27
5.3. Intermediate Interrogation . . . . . . . . . . . . . . . 28 5.3. Intermediate Interrogation ................................29
5.4. Final Interrogation . . . . . . . . . . . . . . . . . . . 30 5.4. Final Interrogation .......................................31
5.5. Server-Initiated Credit Re-Authorization . . . . . . . . 31 5.5. Server-Initiated Credit Re-authorization ..................32
5.6. Graceful Service Termination . . . . . . . . . . . . . . 33 5.6. Graceful Service Termination ..............................34
5.6.1. Terminate Action . . . . . . . . . . . . . . . . . . 36 5.6.1. Terminate Action ...................................37
5.6.2. Redirect Action . . . . . . . . . . . . . . . . . . . 37 5.6.2. Redirect Action ....................................38
5.6.3. Restrict Access Action . . . . . . . . . . . . . . . 39 5.6.3. Restrict Access Action .............................40
5.6.4. Usage of the Server-Initiated Credit Re-Authorization 40 5.6.4. Usage of the Server-Initiated Credit
5.7. Failure Procedures . . . . . . . . . . . . . . . . . . . 40 Re-authorization ...................................41
6. One Time Event . . . . . . . . . . . . . . . . . . . . . . . 43 5.7. Failure Procedures ........................................41
6.1. Service Price Enquiry . . . . . . . . . . . . . . . . . . 44 6. One-Time Event .................................................44
6.2. Balance Check . . . . . . . . . . . . . . . . . . . . . . 45 6.1. Service Price Inquiry .....................................45
6.3. Direct Debiting . . . . . . . . . . . . . . . . . . . . . 45 6.2. Balance Checks ............................................46
6.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.3. Direct Debiting ...........................................46
6.5. Failure Procedure . . . . . . . . . . . . . . . . . . . . 47 6.4. Refunds ...................................................47
7. Credit-Control Application State Machine . . . . . . . . . . 49 6.5. Failure Procedure .........................................48
8. Credit-Control AVPs . . . . . . . . . . . . . . . . . . . . . 57 7. Credit-Control Application State Machines ......................50
8.1. CC-Correlation-Id AVP . . . . . . . . . . . . . . . . . . 60 8. Credit-Control AVPs ............................................59
8.2. CC-Request-Number AVP . . . . . . . . . . . . . . . . . . 60 8.1. CC-Correlation-Id AVP .....................................61
8.3. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 61 8.2. CC-Request-Number AVP .....................................62
8.4. CC-Session-Failover AVP . . . . . . . . . . . . . . . . . 61 8.3. CC-Request-Type AVP .......................................62
8.5. CC-Sub-Session-Id AVP . . . . . . . . . . . . . . . . . . 62 8.4. CC-Session-Failover AVP ...................................63
8.6. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 62 8.5. CC-Sub-Session-Id AVP .....................................64
8.7. Cost-Information AVP . . . . . . . . . . . . . . . . . . 63 8.6. Check-Balance-Result AVP ..................................64
8.8. Unit-Value AVP . . . . . . . . . . . . . . . . . . . . . 63 8.7. Cost-Information AVP ......................................64
8.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . . 64 8.8. Unit-Value AVP ............................................65
8.10. Value-Digits AVP . . . . . . . . . . . . . . . . . . . . 64 8.9. Exponent AVP ..............................................65
8.11. Currency-Code AVP . . . . . . . . . . . . . . . . . . . . 64 8.10. Value-Digits AVP .........................................66
8.12. Cost-Unit AVP . . . . . . . . . . . . . . . . . . . . . . 64 8.11. Currency-Code AVP ........................................66
8.13. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 64 8.12. Cost-Unit AVP ............................................66
8.14. Credit-Control-Failure-Handling AVP . . . . . . . . . . . 65 8.13. Credit-Control AVP .......................................66
8.15. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 66 8.14. Credit-Control-Failure-Handling AVP (CCFH) ...............67
8.16. Multiple-Services-Credit-Control AVP . . . . . . . . . . 67 8.15. Direct-Debiting-Failure-Handling AVP (DDFH) ..............68
8.17. Granted-Service-Unit AVP . . . . . . . . . . . . . . . . 68 8.16. Multiple-Services-Credit-Control AVP .....................68
8.18. Requested-Service-Unit AVP . . . . . . . . . . . . . . . 69 8.17. Granted-Service-Unit AVP .................................70
8.19. Used-Service-Unit AVP . . . . . . . . . . . . . . . . . . 69 8.18. Requested-Service-Unit AVP ...............................71
8.20. Tariff-Time-Change AVP . . . . . . . . . . . . . . . . . 70 8.19. Used-Service-Unit AVP ....................................71
8.21. CC-Time AVP . . . . . . . . . . . . . . . . . . . . . . . 70 8.20. Tariff-Time-Change AVP ...................................72
8.22. CC-Money AVP . . . . . . . . . . . . . . . . . . . . . . 70 8.21. CC-Time AVP ..............................................72
8.23. CC-Total-Octets AVP . . . . . . . . . . . . . . . . . . . 70 8.22. CC-Money AVP .............................................72
8.24. CC-Input-Octets AVP . . . . . . . . . . . . . . . . . . . 70 8.23. CC-Total-Octets AVP ......................................72
8.25. CC-Output-Octets AVP . . . . . . . . . . . . . . . . . . 71 8.24. CC-Input-Octets AVP ......................................72
8.26. CC-Service-Specific-Units AVP . . . . . . . . . . . . . . 71 8.25. CC-Output-Octets AVP .....................................73
8.27. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . . 71 8.26. CC-Service-Specific-Units AVP ............................73
8.28. Service-Identifier AVP . . . . . . . . . . . . . . . . . 72 8.27. Tariff-Change-Usage AVP ..................................73
8.29. Rating-Group AVP . . . . . . . . . . . . . . . . . . . . 72 8.28. Service-Identifier AVP ...................................74
8.30. G-S-U-Pool-Reference AVP . . . . . . . . . . . . . . . . 72 8.29. Rating-Group AVP .........................................74
8.31. G-S-U-Pool-Identifier AVP . . . . . . . . . . . . . . . . 73 8.30. G-S-U-Pool-Reference AVP .................................74
8.32. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 73 8.31. G-S-U-Pool-Identifier AVP ................................75
8.33. Validity-Time AVP . . . . . . . . . . . . . . . . . . . . 73 8.32. CC-Unit-Type AVP .........................................75
8.34. Final-Unit-Indication AVP . . . . . . . . . . . . . . . . 74 8.33. Validity-Time AVP ........................................75
8.35. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . . 75 8.34. Final-Unit-Indication AVP ................................76
8.36. Restriction-Filter-Rule AVP . . . . . . . . . . . . . . . 76 8.35. Final-Unit-Action AVP ....................................77
8.37. Redirect-Server AVP . . . . . . . . . . . . . . . . . . . 76 8.36. Restriction-Filter-Rule AVP ..............................78
8.38. Redirect-Address-Type AVP . . . . . . . . . . . . . . . . 76 8.37. Redirect-Server AVP ......................................78
8.39. Redirect-Server-Address AVP . . . . . . . . . . . . . . . 77 8.38. Redirect-Address-Type AVP ................................79
8.40. Multiple-Services-Indicator AVP . . . . . . . . . . . . . 77 8.39. Redirect-Server-Address AVP ..............................79
8.41. Requested-Action AVP . . . . . . . . . . . . . . . . . . 78 8.40. Multiple-Services-Indicator AVP ..........................80
8.42. Service-Context-Id AVP . . . . . . . . . . . . . . . . . 78 8.41. Requested-Action AVP .....................................80
8.43. Service-Parameter-Info AVP . . . . . . . . . . . . . . . 79 8.42. Service-Context-Id AVP ...................................81
8.44. Service-Parameter-Type AVP . . . . . . . . . . . . . . . 80 8.43. Service-Parameter-Info AVP ...............................82
8.45. Service-Parameter-Value AVP . . . . . . . . . . . . . . . 80 8.44. Service-Parameter-Type AVP ...............................82
8.46. Subscription-Id AVP . . . . . . . . . . . . . . . . . . . 80 8.45. Service-Parameter-Value AVP ..............................83
8.47. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 80 8.46. Subscription-Id AVP ......................................83
8.48. Subscription-Id-Data AVP . . . . . . . . . . . . . . . . 81 8.47. Subscription-Id-Type AVP .................................83
8.49. User-Equipment-Info AVP . . . . . . . . . . . . . . . . . 81 8.48. Subscription-Id-Data AVP .................................84
8.50. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 82 8.49. User-Equipment-Info AVP ..................................84
8.51. User-Equipment-Info-Value AVP . . . . . . . . . . . . . . 82 8.50. User-Equipment-Info-Type AVP .............................84
8.52. User-Equipment-Info-Extension AVP . . . . . . . . . . . . 82 8.51. User-Equipment-Info-Value AVP ............................85
8.53. User-Equipment-Info-IMEISV AVP . . . . . . . . . . . . . 83 8.52. User-Equipment-Info-Extension AVP ........................85
8.54. User-Equipment-Info-MAC AVP . . . . . . . . . . . . . . . 83 8.53. User-Equipment-Info-IMEISV AVP ...........................86
8.55. User-Equipment-Info-EUI64 AVP . . . . . . . . . . . . . . 83 8.54. User-Equipment-Info-MAC AVP ..............................86
8.56. User-Equipment-Info-ModifiedEUI64 AVP . . . . . . . . . . 83 8.55. User-Equipment-Info-EUI64 AVP ............................86
8.57. User-Equipment-Info-IMEI AVP . . . . . . . . . . . . . . 84 8.56. User-Equipment-Info-ModifiedEUI64 AVP ....................86
8.58. Subscription-Id-Extension AVP . . . . . . . . . . . . . . 84 8.57. User-Equipment-Info-IMEI AVP .............................86
8.59. Subscription-Id-E164 AVP . . . . . . . . . . . . . . . . 84 8.58. Subscription-Id-Extension AVP ............................87
8.60. Subscription-Id-IMSI AVP . . . . . . . . . . . . . . . . 85 8.59. Subscription-Id-E164 AVP .................................87
8.61. Subscription-Id-SIP-URI AVP . . . . . . . . . . . . . . . 85 8.60. Subscription-Id-IMSI AVP .................................87
8.62. Subscription-Id-NAI AVP . . . . . . . . . . . . . . . . . 85 8.61. Subscription-Id-SIP-URI AVP ..............................88
8.63. Subscription-Id-Private AVP . . . . . . . . . . . . . . . 85 8.62. Subscription-Id-NAI AVP ..................................88
8.64. Redirect-Server-Extension AVP . . . . . . . . . . . . . . 85 8.63. Subscription-Id-Private AVP ..............................88
8.65. Redirect-Address-IPAddress AVP . . . . . . . . . . . . . 86 8.64. Redirect-Server-Extension AVP ............................88
8.66. Redirect-Address-URL AVP . . . . . . . . . . . . . . . . 86 8.65. Redirect-Address-IPAddress AVP ...........................89
8.67. Redirect-Address-SIP-URI AVP . . . . . . . . . . . . . . 86 8.66. Redirect-Address-URL AVP .................................89
8.68. QoS-Final-Unit-Indication AVP . . . . . . . . . . . . . . 86 8.67. Redirect-Address-SIP-URI AVP .............................89
9. Result Code AVP Values . . . . . . . . . . . . . . . . . . . 88 8.68. QoS-Final-Unit-Indication AVP ............................89
9.1. Transient Failures . . . . . . . . . . . . . . . . . . . 88 9. Result-Code AVP Values .........................................91
9.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 89 9.1. Transient Failures ........................................91
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 89 9.2. Permanent Failures ........................................92
10.1. Credit-Control AVP Table . . . . . . . . . . . . . . . . 90 10. AVP Occurrence Table ..........................................92
10.2. Re-Auth-Request/Answer AVP Table . . . . . . . . . . . . 91 10.1. Credit-Control AVP Table .................................93
11. RADIUS/Diameter Credit-Control Interworking Model . . . . . . 91 10.2. Re-Auth-Request/Re-Auth-Answer AVP Table .................94
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 11. RADIUS/Diameter Credit-Control Interworking Model .............94
12.1. Application Identifier . . . . . . . . . . . . . . . . . 95 12. IANA Considerations ...........................................97
12.2. Command Codes . . . . . . . . . . . . . . . . . . . . . 95 12.1. Application Identifier ...................................97
12.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 95 12.2. Command Codes ............................................97
12.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . 96 12.3. AVP Codes ................................................97
12.5. CC-Request-Type AVP . . . . . . . . . . . . . . . . . . 96 12.4. Result-Code AVP Values ...................................98
12.6. CC-Session-Failover AVP . . . . . . . . . . . . . . . . 96 12.5. CC-Request-Type AVP ......................................98
12.7. CC-Unit-Type AVP . . . . . . . . . . . . . . . . . . . . 96 12.6. CC-Session-Failover AVP ..................................98
12.8. Check-Balance-Result AVP . . . . . . . . . . . . . . . . 96 12.7. CC-Unit-Type AVP .........................................99
12.9. Credit-Control AVP . . . . . . . . . . . . . . . . . . . 96 12.8. Check-Balance-Result AVP .................................99
12.10. Credit-Control-Failure-Handling AVP . . . . . . . . . . 97 12.9. Credit-Control AVP .......................................99
12.11. Direct-Debiting-Failure-Handling AVP . . . . . . . . . . 97 12.10. Credit-Control-Failure-Handling AVP .....................99
12.12. Final-Unit-Action AVP . . . . . . . . . . . . . . . . . 97 12.11. Direct-Debiting-Failure-Handling AVP ....................99
12.13. Multiple-Services-Indicator AVP . . . . . . . . . . . . 97 12.12. Final-Unit-Action AVP ...................................99
12.14. Redirect-Address-Type AVP . . . . . . . . . . . . . . . 97 12.13. Multiple-Services-Indicator AVP ........................100
12.15. Requested-Action AVP . . . . . . . . . . . . . . . . . . 97 12.14. Redirect-Address-Type AVP ..............................100
12.16. Subscription-Id-Type AVP . . . . . . . . . . . . . . . . 98 12.15. Requested-Action AVP ...................................100
12.17. Tariff-Change-Usage AVP . . . . . . . . . . . . . . . . 98 12.16. Subscription-Id-Type AVP ...............................100
12.18. User-Equipment-Info-Type AVP . . . . . . . . . . . . . . 98 12.17. Tariff-Change-Usage AVP ................................100
13. Credit-Control Application Related Parameters . . . . . . . . 98 12.18. User-Equipment-Info-Type AVP ...........................100
14. Security Considerations . . . . . . . . . . . . . . . . . . . 99 13. Parameters Related to the Credit-Control Application .........101
14.1. Direct Connection with Redirects . . . . . . . . . . . . 100 14. Security Considerations ......................................101
14.2. Application Level Redirects . . . . . . . . . . . . . . 100 14.1. Direct Connection with Redirects ........................102
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 101 14.2. Application-Level Redirects .............................103
15.1. Privacy Sensitive AVPs . . . . . . . . . . . . . . . . . 101
15.2. Data Minimization . . . . . . . . . . . . . . . . . . . 103 15. Privacy Considerations .......................................104
15.3. Diameter Agents . . . . . . . . . . . . . . . . . . . . 104 15.1. Privacy-Sensitive AVPs ..................................104
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 15.2. Data Minimization .......................................106
16.1. Normative References . . . . . . . . . . . . . . . . . . 104 15.3. Diameter Agents .........................................107
16.2. Informative References . . . . . . . . . . . . . . . . . 106 16. References ...................................................107
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 107 16.1. Normative References ....................................107
Appendix B. Credit-Control Sequences . . . . . . . . . . . . . . 107 16.2. Informative References ..................................110
B.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . . 107 Appendix A. Credit-Control Sequences .............................111
B.2. Flow II . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.1. Flow I ....................................................111
B.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . . 112 A.2. Flow II ...................................................113
B.4. Flow IV . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.3. Flow III ..................................................116
B.5. Flow V . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.4. Flow IV ...................................................117
B.6. Flow VI . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.5. Flow V ....................................................119
B.7. Flow VII . . . . . . . . . . . . . . . . . . . . . . . . 117 A.6. Flow VI ...................................................120
B.8. Flow VIII . . . . . . . . . . . . . . . . . . . . . . . . 118 A.7. Flow VII ..................................................121
B.9. Flow IX . . . . . . . . . . . . . . . . . . . . . . . . . 120 A.8. Flow VIII .................................................123
Appendix C. Changes relative to RFC4006 . . . . . . . . . . . . 125 A.9. Flow IX ...................................................124
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 126 Acknowledgements .................................................130
Authors' Addresses ...............................................130
1. Introduction 1. Introduction
This document specifies a Diameter application that can be used to This document specifies a Diameter application that can be used to
implement real-time credit-control for a variety of end user services implement real-time credit-control for a variety of end-user services
such as network access, Session Initiation Protocol (SIP) services, such as network access, Session Initiation Protocol (SIP) services,
messaging services, and download services. It provides a general messaging services, and download services. ("Credit-control" is
solution to real-time cost and credit-control. sometimes abbreviated as "CC" in figures and tables throughout this
document.) The Diameter Credit-Control application as defined in
this document obsoletes [RFC4006], and it must be supported by all
new Diameter Credit-Control application implementations. This
document provides a general solution to real-time cost and
credit-control.
The prepaid model has been shown to be very successful, for instance, The prepaid model has been shown to be very successful -- for
in GSM networks, where network operators offering prepaid services instance, in GSM networks, where network operators offering prepaid
have experienced a substantial growth of their customer base and services have experienced a substantial growth of their customer base
revenues. Prepaid services are now cropping up in many other and revenues. Prepaid services are now cropping up in many other
wireless and wire line based networks. wireless and wire-line-based networks.
In mobile networks, additional functionality is required beyond that In mobile networks, additional functionality is required beyond that
specified in the Diameter base protocol [RFC6733]. For example, the specified in the Diameter base protocol [RFC6733]. For example, the
3GPP Charging and Billing requirements [TGPPCHARG] state that an 3GPP charging and billing requirements document [TGPPCHARG] states
application must be able to rate service information in real-time. that an application must be able to rate service information in
In addition, it is necessary to check that the end user's account real time. In addition, it is necessary to check that the end user's
provides coverage for the requested service prior to initiation of account provides coverage for the requested service prior to
that service. When an account is exhausted or expired, the user must initiation of that service. When an account is exhausted or expired,
be denied the ability to compile additional chargeable events. the user must be denied the ability to compile additional chargeable
events.
A mechanism has to be provided to allow the user to be informed of A mechanism has to be provided to allow the user to be informed of
the charges to be levied for a requested service. In addition, there the charges to be levied for a requested service. In addition, there
are services such as gaming and advertising that may credit as well are services such as gaming and advertising that may credit as well
as debit a user account. as debit a user account.
The other Diameter applications provide service-specific The other Diameter applications provide service-specific
authorization, and they do not provide credit authorization for authorization, and they do not provide credit authorization for
prepaid users. The credit authorization shall be generic and prepaid users. The credit authorization shall be generic and
applicable to all the service environments required to support applicable to all the service environments required to support
prepaid services. prepaid services.
To fulfill these requirements, it is necessary to facilitate credit- To fulfill these requirements, it is necessary to facilitate
control communication between the network element providing the credit-control communication between the network element providing
service (e.g., Network Access Server, SIP Proxy, and Application the service (e.g., Network Access Server (NAS), SIP Proxy,
Server) and a credit-control server. Application Server) and a credit-control server.
The scope of this specification is the credit authorization. The scope of this specification is credit authorization. Service-
Service-specific authorization and authentication is out of scope. specific authorization and authentication are out of scope.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
AAA Authentication, Authorization, and Accounting AAA: Authentication, Authorization, and Accounting.
AA answer AA answer generically refers to a service-specific AA-Answer: "AA-Answer" generically refers to a service-specific
authorization and authentication answer. AA answer commands are authorization and authentication answer. AA-Answer commands are
defined in service-specific authorization applications, e.g., defined in service-specific authorization applications, e.g.,
[RFC7155] and [RFC4004]. [RFC7155] [RFC4004].
AA request AA request generically refers to a service-specific AA-Request: "AA-Request" generically refers to a service-specific
authorization and authentication request. AA request commands are authorization and authentication request. AA-Request commands are
defined in service-specific authorization applications e.g., defined in service-specific authorization applications, e.g.,
[RFC7155] and [RFC4004]. [RFC7155] [RFC4004].
Credit-control Credit-control is a mechanism that directly interacts Credit-control: "Credit-control" is a mechanism that directly
in real-time with an account and controls or monitors the charges interacts in real time with an account and controls or monitors
related to the service usage. Credit-control is a process of the charges related to service usage. Credit-control is a
checking whether credit is available, credit-reservation, process of (1) checking whether or not credit is available,
deduction of credit from the end user account when service is (2) credit reservation, (3) deduction of credit from the end-user
completed and refunding of reserved credit that is not used. account when service is completed, and (4) refunding of reserved
credit that is not used.
Diameter Credit-control Server A Diameter credit-control server acts Diameter Credit-Control server: A Diameter Credit-Control server
as a prepaid server, performing real-time rating and credit- acts as a prepaid server, performing real-time rating and
control. It is located in the home domain and is accessed by credit-control. It is located in the home domain and is accessed
service elements or Diameter AAA servers in real-time for purpose by Service Elements or Diameter AAA servers in real time, for the
of price determination and credit-control before the service event purpose of price determination and credit-control before the
is delivered to the end-user. It may also interact with business service event is delivered to the end user. It may also interact
support systems. with Business Support Systems.
Diameter Credit-control Client A Diameter credit-control client is Diameter Credit-Control client: A Diameter Credit-Control client is
an entity that interacts with a credit-control server. It an entity that interacts with a credit-control server. It
monitors the usage of the granted quota according to instructions monitors the usage of the granted quota according to instructions
returned by credit-control server. returned by the credit-control server.
Interrogation The Diameter credit-control client uses interrogation Interrogation: The Diameter Credit-Control client uses interrogation
to initiate a session based credit-control process. During the to initiate a session-based credit-control process. During the
credit-control process, it is used to report the used quota and credit-control process, it is used to report the used quota and
request a new one. An interrogation maps to a request/answer request a new one. An interrogation maps to a request/answer
transaction. transaction.
One-time event Basically, a request/answer transaction of type One-time event: A charging transaction session comprising a single
event. request and single response.
Rating The act of determining the cost of the service event. Rating: The act of determining the cost of the service event.
Service A type of task performed by a service element for an end Service: A type of task performed by a Service Element for an
user. end user.
Service Element A network element that provides a service to the end Service Element: A network element that provides a service to the
users. The Service Element may include the Diameter credit- end users. The Service Element may include the Diameter
control client, or another entity (e.g., RADIUS AAA server) that Credit-Control client or another entity (e.g., a RADIUS AAA
can act as a credit-control client on behalf of the Service server) that can act as a credit-control client on behalf of the
Element. In the latter case, the interface between the Service Service Element. In the latter case, the interface between the
Element and the Diameter credit-control client is outside the Service Element and the Diameter Credit-Control client is outside
scope of this specification. Examples of the Service Elements the scope of this specification. Examples of Service Elements
include Network Access Server (NAS), SIP Proxy, and Application include NASs, SIP Proxies, and Application Servers such as
Servers such as messaging server, content server, and gaming messaging servers, content servers, and gaming servers.
server.
Service Event An event relating to a service provided to the end Service event: An event relating to a service provided to the
user. end user.
Session based credit-control A credit-control process that makes use Session-based credit-control: A credit-control process that makes
of several interrogations: the first, a possible intermediate, and use of several interrogations: the first, a possible intermediate,
the final. The first interrogation is used to reserve money from and the final. The first interrogation is used to reserve money
the user's account and to initiate the process. The intermediate from the user's account and to initiate the process. Intermediate
interrogations may be needed to request new quota while the interrogations (if any) may be needed to request a new quota while
service is being rendered. The final interrogation is used to the service is being rendered. The final interrogation is used to
exit the process. The credit-control server is required to exit the process. The credit-control server is required to
maintain session state for session-based credit-control. maintain session state for session-based credit-control.
1.3. Advertising Application Support 1.3. Advertising Application Support
Diameter nodes conforming to this specification MUST advertise Diameter nodes conforming to this specification MUST advertise
support by including the value of 4 in the Auth-Application-Id of the support by including the value of 4 in the Auth-Application-Id of the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer Capabilities-Exchange-Request and Capabilities-Exchange-Answer
command [RFC6733]. commands [RFC6733].
2. Architecture Models 2. Architecture Models
The current accounting models specified in the Radius Accounting The current accounting models specified in the RADIUS accounting and
[RFC2866] and Diameter base [RFC6733] are not sufficient for real- Diameter base specifications [RFC2866] [RFC6733] are not sufficient
time credit-control, where credit-worthiness is to be determined for real-time credit-control, where creditworthiness is to be
prior to service initiation. Also, the existing Diameter determined prior to service initiation. Also, the existing Diameter
authorization applications, [RFC7155] and [RFC4004], only provide authorization applications [RFC7155] [RFC4004] only provide service
service authorization, but do not provide credit authorization for authorization; they do not provide credit authorization for prepaid
prepaid users. In order to support real-time credit-control, a new users. In order to support real-time credit-control, a new type of
type of server is needed in the AAA infrastructure: Diameter credit- server is needed in the AAA infrastructure: the Diameter
control server. The Diameter credit-control server is the entity Credit-Control server. The Diameter Credit-Control server is the
responsible for credit authorization for prepaid subscribers. entity responsible for credit authorization for prepaid subscribers.
A service element may authenticate and authorize the end user with A Service Element may authenticate and authorize the end user with
the AAA server by using AAA protocols; e.g., RADIUS or a Diameter the AAA server by using AAA protocols, e.g., RADIUS or the Diameter
base protocol with a possible Diameter application. base protocol (possibly extended via a Diameter application).
Accounting protocols such as RADIUS accounting and the Diameter base Accounting protocols such as RADIUS accounting and the Diameter base
accounting protocol can be used to provide accounting data to the accounting protocol can be used to provide accounting data to the
accounting server after service is initiated, and to provide possible accounting server after service is initiated and to provide possible
interim reports until service completion. However, for real-time interim reports until service completion. However, for real-time
credit-control, these authorization and accounting models are not credit-control, these authorization and accounting models are not
sufficient. sufficient.
When real-time credit-control is required, the credit-control client When real-time credit-control is required, the credit-control client
contacts the credit-control server with information about a possible contacts the credit-control server with information about a possible
service event. The credit-control process is performed to determine service event. The credit-control process is performed to determine
potential charges and to verify whether the end user's account potential charges and to verify whether the end user's account
balance is sufficient to cover the cost of the service being balance is sufficient to cover the cost of the service being
rendered. rendered.
Figure 1 illustrates the typical credit-control architecture, which Figure 1 illustrates the typical credit-control architecture, which
consists of a Service Element with an embedded Diameter credit- consists of a Service Element with an embedded Diameter
control client, a Diameter credit-control server, and an AAA server. Credit-Control client, a Diameter Credit-Control server, and a AAA
A Business Support System is usually deployed; it includes at least server. A Business Support System is usually deployed; at a minimum,
the billing functionality. The credit-control server and AAA server it includes billing functionality. The credit-control server and AAA
in this architecture model are logical entities. The real server in this architecture model are logical entities. The real
configuration can combine them into a single host. The credit- configuration can combine them into a single host. The
control protocol is the Diameter base protocol [RFC6733] with the credit-control protocol is the Diameter base protocol [RFC6733] with
Diameter credit-control application. the Diameter Credit-Control application.
When an end user requests services such as SIP or messaging, the When an end user requests services such as SIP or messaging, the
request is typically forwarded to a service element (e.g., SIP Proxy) request is typically forwarded to a Service Element (e.g., a SIP
in the user's home realm as defined in [RFC6733]. In some cases it Proxy) in the user's home realm as defined in [RFC6733]. In some
might be possible that the service element in the local realm cases, it might be possible that the Service Element in the local
[RFC6733] can offer services to the end user; however, a commercial realm [RFC6733] can offer services to the end user; however, a
agreement must exist between the local realm and the home realm. commercial agreement must exist between the local realm and the home
Network access is an example of a service offered in the local realm realm. Network access is an example of a service offered in the
where the NAS, through an AAA infrastructure, authenticates and local realm where the NAS, through a AAA infrastructure,
authorizes the user with the user's home network. authenticates and authorizes the user with the user's home network.
Service Element AAA and CC Service Element AAA and CC
+----------+ +---------+ Protocols+-----------+ +--------+ +----------+ +---------+ Protocols+-----------+ +--------+
| End |<---->|+-------+|<------------>| AAA | |Business| | End |<---->|+-------+|<------------>| AAA | |Business|
| User | +->|| CC || | Server |->|Support | | User | +->|| CC || | Server |->|Support |
| | | || Client||<-----+ | | |System | | | | || Client||<-----+ | | |System |
+----------+ | |+-------+| | +-----------+ | | +----------+ | |+-------+| | +-----------+ | |
| +---------+ | ^ +--------+ | +---------+ | ^ +--------+
+----------+ | | CC Protocol | ^ +----------+ | | CC Protocol | ^
| End |<--+ | +-----v----+ | | End |<--+ | +-----v----+ |
| User | +------>|Credit- | | | User | +------>|Credit- | |
+----------+ Credit-Control |Control |--------+ +----------+ Credit-Control |Control |--------+
Protocol |Server | Protocol |Server |
+----------+ +----------+
Figure 1: Typical credit-control architecture Figure 1: Typical Credit-Control Architecture
There can be multiple credit-control servers in the system for There can be multiple credit-control servers in the system for
redundancy and load balancing. The system can also contain separate redundancy and load balancing. The system can also contain separate
rating server(s), and accounts can be located in a centralized rating server(s), and accounts can be located in a centralized
database. To ensure that the end user's account is not debited or database. To ensure that the end user's account is not debited or
credited multiple times for the same service event, only one place in credited multiple times for the same service event, only one entity
the credit-control system should perform duplicate detection. System in the credit-control system should perform duplicate detection.
internal interfaces can exist to relay messages between servers and System-internal interfaces can exist to relay messages between
an account manager. However, the detailed architecture of the servers and an account manager. However, the detailed architecture
credit-control system and its interfaces are implementation specific of the credit-control system and its interfaces is implementation
and are out of scope of this specification. specific and is out of scope for this specification.
Protocol transparent Diameter relays can exist between the credit- Protocol-transparent Diameter relays can exist between the
control client and credit-control server. Also, Diameter Redirect credit-control client and credit-control server. Also, Diameter
agents that refer credit-control clients to credit-control servers redirect agents that refer credit-control clients to credit-control
and allow them to communicate directly can exist. These agents servers and allow them to communicate directly can exist. These
transparently support the Diameter credit-control application. The agents transparently support the Diameter Credit-Control application.
different roles of Diameter Agents are defined in Diameter base The different roles of Diameter agents are defined in Diameter base
[RFC6733], section 2.8. [RFC6733], Section 2.8.
If Diameter credit-control proxies exist between the credit-control If Diameter Credit-Control proxies exist between the credit-control
client and the credit-control server, they MUST advertise the client and the credit-control server, they MUST advertise support for
Diameter credit-control application support. the Diameter Credit-Control application.
3. Credit-Control Messages 3. Credit-Control Messages
This section defines new Diameter message Command-Code values that This section defines new Diameter message Command Code values that
MUST be supported by all Diameter implementations that conform to MUST be supported by all Diameter implementations that conform to
this specification. The Command Codes are as follows: this specification. The Command Codes are as follows:
+------------------------+---------+------+-----------+ +------------------------+---------+------+-------------+
| Command-Name | Abbrev. | Code | Reference | | Command Name | Abbrev. | Code | Reference |
+------------------------+---------+------+-----------+ +------------------------+---------+------+-------------+
| Credit-Control-Request | CCR | 272 | 3.1 | | Credit-Control-Request | CCR | 272 | Section 3.1 |
| Credit-Control-Answer | CCA | 272 | 3.2 | | Credit-Control-Answer | CCA | 272 | Section 3.2 |
+------------------------+---------+------+-----------+ +------------------------+---------+------+-------------+
Table 1: Credit-Control Commands Table 1: Credit-Control Commands
Diameter Base [RFC6733] defines in the section 3.2 the Command Code Section 3.2 of [RFC6733] (Diameter base) defines the Command Code
format specification. These formats are observed in Credit-Control Format specification. These formats are observed in credit-control
messages. messages.
3.1. Credit-Control-Request (CCR) Command 3.1. Credit-Control-Request (CCR) Command
The Credit-Control-Request message (CCR) is indicated by the command- The Credit-Control-Request message (CCR) is indicated by the Command
code field being set to 272 and the 'R' bit being set in the Command Code field being set to 272 and the 'R' bit being set in the Command
Flags field. It is used between the Diameter credit-control client Flags field. It is used between the Diameter Credit-Control client
and the credit-control server to request credit authorization for a and the credit-control server to request credit authorization for a
given service. given service.
The Auth-Application-Id MUST be set to the value 4, indicating the The Auth-Application-Id MUST be set to the value 4, indicating the
Diameter credit-control application. Diameter Credit-Control application.
The CCR is extensible via the inclusion of one or more Attribute The CCR is extensible via the inclusion of one or more
Value Pairs (AVPs). Attribute-Value Pairs (AVPs).
Message Format Message Format:
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY > <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Application-Id } { Auth-Application-Id }
{ Service-Context-Id } { Service-Context-Id }
{ CC-Request-Type } { CC-Request-Type }
{ CC-Request-Number } { CC-Request-Number }
skipping to change at page 11, line 41 skipping to change at page 12, line 26
*[ Service-Parameter-Info ] *[ Service-Parameter-Info ]
[ CC-Correlation-Id ] [ CC-Correlation-Id ]
[ User-Equipment-Info ] [ User-Equipment-Info ]
[ User-Equipment-Info-Extension ] [ User-Equipment-Info-Extension ]
*[ Proxy-Info ] *[ Proxy-Info ]
*[ Route-Record ] *[ Route-Record ]
*[ AVP ] *[ AVP ]
3.2. Credit-Control-Answer (CCA) Command 3.2. Credit-Control-Answer (CCA) Command
The Credit-Control-Answer message (CCA) is indicated by the command- The Credit-Control-Answer message (CCA) is indicated by the Command
code field being set to 272 and the 'R' bit being cleared in the Code field being set to 272 and the 'R' bit being cleared in the
Command Flags field. It is used between the credit-control server Command Flags field. It is used between the credit-control server
and the Diameter credit-control client to acknowledge a Credit- and the Diameter Credit-Control client to acknowledge a
Control-Request command. Credit-Control-Request command.
Message Format:
Message Format
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY > <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Auth-Application-Id } { Auth-Application-Id }
{ CC-Request-Type } { CC-Request-Type }
{ CC-Request-Number } { CC-Request-Number }
[ User-Name ] [ User-Name ]
[ CC-Session-Failover ] [ CC-Session-Failover ]
[ CC-Sub-Session-Id ] [ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ] [ Acct-Multi-Session-Id ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Event-Timestamp ] [ Event-Timestamp ]
[ Granted-Service-Unit ] [ Granted-Service-Unit ]
*[ Multiple-Services-Credit-Control ] *[ Multiple-Services-Credit-Control ]
[ Cost-Information] [ Cost-Information ]
[ Final-Unit-Indication ] [ Final-Unit-Indication ]
[ QoS-Final-Unit-Indication ] [ QoS-Final-Unit-Indication ]
[ Check-Balance-Result ] [ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ] [ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ] [ Direct-Debiting-Failure-Handling ]
[ Validity-Time ] [ Validity-Time ]
*[ Redirect-Host ] *[ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
*[ Proxy-Info ] *[ Proxy-Info ]
*[ Route-Record ] *[ Route-Record ]
*[ Failed-AVP ] *[ Failed-AVP ]
skipping to change at page 12, line 39 skipping to change at page 13, line 21
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
*[ Proxy-Info ] *[ Proxy-Info ]
*[ Route-Record ] *[ Route-Record ]
*[ Failed-AVP ] *[ Failed-AVP ]
*[ AVP ] *[ AVP ]
4. Credit-Control Application Overview 4. Credit-Control Application Overview
The credit authorization process takes place before and during The credit authorization process takes place before and during
service delivery to the end user and generally requires the user's service delivery to the end user and generally requires the user's
authentication and authorization before any request is sent to the authentication and authorization before any requests are sent to the
credit-control server. The credit-control application defined in credit-control server. The credit-control application defined in
this specification supports two different credit authorization this specification supports two different credit authorization
models: credit authorization with money reservation and credit models: credit authorization with money reservation and credit
authorization with direct debiting. In both models, the credit- authorization with direct debiting. In both models, the
control client requests credit authorization from the credit-control credit-control client requests credit authorization from the
server prior to allowing any service to be delivered to the end user. credit-control server prior to allowing any services to be delivered
to the end user.
In the first model, the credit-control server rates the request, In the first model, the credit-control server rates the request,
reserves a suitable amount of money from the user's account, and reserves a suitable amount of money from the user's account, and
returns the amount of credit reserved. Note that credit resources returns the amount of credit reserved. Note that credit resources
may not imply actual monetary credit; credit resources may be granted may not imply actual monetary credit; credit resources may be granted
to the credit-control client in the form of units (e.g., data volume to the credit-control client in the form of units (e.g., data volume
or time) to be metered. or time) to be metered.
Upon receipt of a successful credit authorization answer with a Upon receipt of a successful credit authorization answer with a
certain amount of credit resources, the credit-control client allows certain amount of credit resources, the credit-control client allows
service delivery to the end user and starts monitoring the usage of service delivery to the end user and starts monitoring the usage of
the granted resources. When the credit resources granted to the user the granted resources. When the credit resources granted to the user
have been consumed or the service has been successfully delivered or have been consumed or the service has been successfully delivered or
terminated, the credit-control client reports back to the server the terminated, the credit-control client reports back to the server the
used amount. The credit-control server deducts the used amount from used amount. The credit-control server deducts the used amount from
the end user's account; it may perform rating and make a new credit the end user's account; it may perform rating and make a new credit
reservation if the service delivery is continuing. This process is reservation if the service delivery is continuing. This process is
accomplished with session based credit-control that includes the accomplished with session-based credit-control that includes the
first interrogation, possible intermediate interrogations, and the first interrogation, possible intermediate interrogations, and the
final interrogation. For session based credit-control, both the final interrogation. For session-based credit-control, both the
credit-control client and the credit-control server are required to credit-control client and the credit-control server are required to
maintain credit-control session state. Session based credit-control maintain credit-control session state. Session-based credit-control
is described in more detail, with more variations, in Section 5. is described in more detail, with more variations, in Section 5.
In contrast, credit authorization with direct debiting is a single In contrast, credit authorization with direct debiting is a
transaction process wherein the credit-control server directly single-transaction process wherein the credit-control server directly
deducts a suitable amount of money from the user's account as soon as deducts a suitable amount of money from the user's account as soon as
the credit authorization request is received. Upon receipt of a the credit authorization request is received. Upon receipt of a
successful credit authorization answer, the credit-control client successful credit authorization answer, the credit-control client
allows service delivery to the end user. This process is allows service delivery to the end user. This process is
accomplished with the one-time event. Session state is not accomplished with the one-time event. Session state is not
maintained. maintained.
In a multi-service environment, an end user can issue an additional In a multi-service environment, an end user can issue an additional
service request (e.g., data service) during an ongoing service (e.g., service request (e.g., data service) during an ongoing service (e.g.,
voice call) toward the same account. Alternatively, during an active voice call) toward the same account. Alternatively, during an active
multimedia session, an additional media type is added to the session, multimedia session, an additional media type is added to the session,
causing a new simultaneous request toward same account. causing a new simultaneous request toward the same account.
Consequently, this needs to be considered when credit resources are Consequently, this needs to be considered when credit resources are
granted to the services. granted to the services.
The credit-control application also supports operations such as The credit-control application also supports operations such as
service price enquiry, user's balance check, and refund of credit on service price inquiries, user's balance checks, and refunds of credit
the user's account. These operations are accomplished with the one- on the user's account. These operations are accomplished with the
time event. Session state is not maintained. one-time event. Session state is not maintained.
Flexible failure handling, specific to the credit-control, is defined Flexible failure handling, specific to the credit-control
in the application. This allows the the service provider to control application, is defined in the application. This allows the service
the credit-control client behavior according to its own risk provider to control the credit-control client's behavior according to
management policy. its own risk management policy.
The Credit-Control-Failure-Handling AVP and the Direct-Debiting- The Credit-Control-Failure-Handling AVP (also referred to as the
Failure-Handling AVP are defined to determine what is done if the CCFH) and the Direct-Debiting-Failure-Handling AVP (also referred to
sending of credit-control messages to the credit-control server has as the DDFH) are defined to determine what is done if the sending of
been temporarily prevented. The usage of the Credit-Control-Failure- credit-control messages to the credit-control server has been
Handling AVP and the Direct-Debiting-Failure-Handling AVP allows temporarily prevented. The usage of the CCFH and the DDFH allows
flexibility, as failure handling for the credit-control session and flexibility, as failure handling for the credit-control session and
one-time event direct debiting may be different. one-time event direct debiting may be different.
4.1. Service-Specific Rating Input and Interoperability 4.1. Service-Specific Rating Input and Interoperability
The Diameter credit-control application defines the framework for The Diameter Credit-Control application defines the framework for
credit-control; it provides generic credit-control mechanisms credit-control; it provides generic credit-control mechanisms
supporting multiple service applications. The credit-control supporting multiple service applications. The credit-control
application, therefore, does not define AVPs that could be used as application therefore does not define AVPs that could be used as
input in the rating process. Listing the possible services that input in the rating process. Listing the possible services that
could use this Diameter application is out of scope for this generic could use this Diameter application is out of scope for this generic
mechanism. mechanism.
It is reasonable to expect that a service level agreement will exist It is reasonable to expect that a service level agreement will exist
between providers of the credit-control client and the credit-control between providers of the credit-control client and the credit-control
server covering the charging, services offered, roaming agreements, server covering the charging, services offered, roaming agreements,
agreed rating input (i.e., AVPs), and so on. agreed-upon rating input (i.e., AVPs), and so on.
Therefore, it is assumed that a Diameter credit-control server will Therefore, it is assumed that a Diameter Credit-Control server will
provide service only for Diameter credit-control clients that have provide service only for Diameter Credit-Control clients that have
agreed beforehand as to the content of credit-control messages. agreed beforehand as to the content of credit-control messages.
Naturally, it is possible that any arbitrary Diameter credit-control Naturally, it is possible that any arbitrary Diameter Credit-Control
client can interchange credit-control messages with any Diameter client can interchange credit-control messages with any Diameter
credit-control server, but with a higher likelihood that unsupported Credit-Control server, but with a higher likelihood that unsupported
services/AVPs could be present in the credit-control message, causing services/AVPs could be present in the credit-control message, causing
the server to reject the request with an appropriate result-code. the server to reject the request with an appropriate Result-Code.
4.1.1. Specifying Rating Input AVPs 4.1.1. Specifying Rating Input AVPs
There are two ways to provide rating input to the credit-control There are two ways to provide rating input to the credit-control
server: either by using AVPs or by including them in the Service- server: by either using AVPs or including the rating input in the
Parameter-Info AVP. The general principles for sending rating Service-Parameter-Info AVP. The general principles for sending
parameters are as follows: rating parameters are as follows:
1a. The service SHOULD re-use existing AVPs if it can use AVPs 1. Using AVPs:
defined in existing Diameter applications (e.g., [RFC7155] for
network access services). Re-use of existing AVPs is strongly
recommended in [RFC6733].
For AVPs of type Enumerated, the service may require a new value to A. The service SHOULD reuse existing AVPs if it can use AVPs
be defined. Allocation of new AVP values is done as specified in defined in existing Diameter applications (e.g., [RFC7155]
[RFC6733], section 1.3. for network access services). [RFC6733] strongly recommends
the reuse of existing AVPs.
1b. New AVPs can be defined if the existing AVPs do not provide For AVPs of type Enumerated, the service may require a new
sufficient rating information. In this case, the procedures defined value to be defined. Allocation of new AVP values is done as
in [RFC6733] for creating new AVPs MUST be followed. specified in [RFC6733], Section 1.3.
1c. For services specific only to one vendor's implementation, a B. New AVPs can be defined if the existing AVPs do not provide
Vendor-Specific AVP code for Private use can be used. Where a sufficient rating information. In this case, the procedures
Vendor-Specific AVP is implemented by more than one vendor, defined in [RFC6733] for creating new AVPs MUST be followed.
allocation of global AVPs is encouraged instead; refer to [RFC6733].
C. For services specific only to one vendor's implementation, a
vendor-specific AVP code for private use can be used. Where
a vendor-specific AVP is implemented by more than one vendor,
allocation of global AVPs is encouraged instead; refer to
[RFC6733].
2. The Service-Parameter-Info AVP MAY be used as a container to pass 2. The Service-Parameter-Info AVP MAY be used as a container to pass
legacy rating information in its original encoded form (e.g., ASN.1 legacy rating information in its original encoded form (e.g.,
BER). This method can be used to avoid unnecessary conversions from ASN.1 BER). This method can be used to avoid unnecessary
an existing data format to an AVP format. In this case, the rating conversions from an existing data format to an AVP format. In
input is embedded in the Service-Parameter-Info AVP as defined in this case, the rating input is embedded in the Service-Parameter-
Section 8.43. Info AVP as defined in Section 8.43.
New service applications SHOULD favor the use of explicitly defined New service applications SHOULD favor the use of explicitly defined
AVPs as described in items 1a and 1b, to simplify interoperability. AVPs as described in items 1a and 1b, to simplify interoperability.
4.1.2. Service-Specific Documentation 4.1.2. Service-Specific Documentation
The service-specific rating input AVPs, the contents of the Service- The service-specific rating input AVPs, and the contents of the
Parameter-Info AVP or Service-Context-Id AVP (defined in Service-Parameter-Info AVP or Service-Context-Id AVP (defined in
Section 8.42) are not within the scope of this document. To Section 8.42), are not within the scope of this document. To
facilitate interoperability, it is RECOMMENDED that the rating input facilitate interoperability, it is RECOMMENDED that the rating input
and the values of the Service-Context-Id be coordinated via an and the values of the Service-Context-Id be coordinated via an
informational RFC or other permanent and readily available reference, informational RFC or other permanent and readily available reference
preferably, of another cooperative standardization body (e.g., 3GPP, (preferably that of another cooperative standardization body, e.g.,
OMA, or 3GPP2). However, private services may be deployed that are 3GPP, the Open Mobile Alliance (OMA), or 3GPP2). However, private
subject to agreements between providers of the credit-control server services may be deployed that are subject to agreements between
and client. In this case, vendor-specific AVPs can be used. providers of the credit-control server and client. In this case,
vendor-specific AVPs can be used.
This specification, together with the above service-specific This specification, together with the above-mentioned service-
documents, governs the credit-control message. Service-specific specific documents, governs the credit-control message. Service-
documents define which existing AVPs or new AVPs are used as input to specific documents (i.e., those documents that do not define new
the rating process (i.e., those that do not define new credit-control credit-control applications) define which existing AVPs or new AVPs
applications), and thus have to be included in the Credit-Control- are used as input to the rating process; thus, the AVPs in question
Request command by a Diameter credit-control client supporting a have to be included in the Credit-Control-Request command by a
given service as *[AVP]. Should Service-Parameter-Info be used, then Diameter Credit-Control client supporting a given service as
the service-specific document MUST specify the exact content of this "* [AVP]". Should the Service-Parameter-Info AVP be used, the
grouped AVP. service-specific document MUST specify the exact content of this
Grouped AVP.
The Service-Context-Id AVP MUST be included at the command level of a The Service-Context-Id AVP MUST be included at the command level of a
Credit-Control Request to identify the service-specific document that Credit-Control-Request to identify the service-specific document that
applies to the request. The specific service or rating group the applies to the request. The specific service or rating-group the
request relates to is uniquely identified by the combination of request relates to is uniquely identified by the combination of
Service-Context-Id and Service-Identifier or Rating-Group. Service-Context-Id and Service-Identifier or rating-group.
4.1.3. Handling of Unsupported/Incorrect Rating Input 4.1.3. Handling of Unsupported/Incorrect Rating Input
Diameter credit-control implementations are required to support the Diameter Credit-Control implementations are required to support
Mandatory rating AVPs defined in service-specific documentation of mandatory rating-related AVPs defined in service-specific documents
the services they support, according to the 'M' bit rules in for the services they support, according to the 'M' bit rules in
[RFC6733]. [RFC6733].
If a rating input required for the rating process is incorrect in the If a rating input required for the rating process is incorrect in
Credit-control request, or if the credit-control server does not the Credit-Control-Request or if the credit-control server does not
support the requested service context (identified by the Service- support the requested service context (identified by the
Context-Id AVP at command level), the Credit-control answer MUST Service-Context-Id AVP at the command level), the
contain the error code DIAMETER_RATING_FAILED. A CCA message with Credit-Control-Answer MUST contain the error code
this error MUST contain one or more Failed-AVP AVPs containing the DIAMETER_RATING_FAILED. A CCA message with this error MUST contain
missing and/or unsupported AVPs that caused the failure. A Diameter one or more Failed-AVP AVPs containing the missing and/or unsupported
credit-control client that receives the error code AVPs that caused the failure. A Diameter Credit-Control client that
DIAMETER_RATING_FAILED in response to a request MUST NOT send similar receives the error code DIAMETER_RATING_FAILED in response to a
requests in the future. request MUST NOT send similar requests in the future.
4.1.4. RADIUS Vendor-Specific Rating Attributes 4.1.4. RADIUS Vendor-Specific Rating Attributes
When service-specific documents include RADIUS vendor-specific When service-specific documents include RADIUS vendor-specific
attributes that could be used as input in the rating process, the attributes that could be used as input in the rating process, the
rules described in [RFC7155] for formatting the Diameter AVP MUST be rules described in [RFC7155] for formatting the Diameter AVP MUST be
followed. followed.
For example, if the AVP code used is the vendor attribute type code, For example, if the AVP code used is the vendor attribute type code,
the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be the Vendor-Specific flag MUST be set to 1 and the Vendor-Id MUST be
set to the IANA Vendor identification value. The Diameter AVP data set to the IANA Vendor identification value. The Diameter AVP Data
field contains only the attribute value of the RADIUS attribute. field contains only the attribute value of the RADIUS attribute.
5. Session Based Credit-Control 5. Session-Based Credit-Control
5.1. General Principles 5.1. General Principles
For a session-based credit-control, several interrogations are For session-based credit-control, several interrogations are needed:
needed: the first, intermediate (optional) and the final the first, the intermediate (optional), and the final. This is
interrogations. This is illustrated in Figure 3 and Figure 4. illustrated in Figures 3 and 4 (Sections 5.2.1 and 5.2.2).
If the credit-control client performs credit-reservation before If the credit-control client performs credit reservation before
granting service to the end user, it MUST use several interrogations granting service to the end user, it MUST use several interrogations
toward the credit-control server (i.e., session based credit- toward the credit-control server (i.e., session-based
control). In this case, the credit-control server MUST maintain the credit-control). In this case, the credit-control server MUST
credit-control session state. maintain the credit-control session state.
Each credit-control session MUST have a globally unique Session-Id as Each credit-control session MUST have a globally unique Session-Id as
defined in [RFC6733], which MUST NOT be changed during the lifetime defined in [RFC6733]; this Session-Id MUST NOT be changed during the
of a credit-control session. lifetime of a credit-control session.
Certain applications require multiple credit-control sub-sessions. Certain applications require multiple credit-control sub-sessions.
These applications would send messages with a constant Session-Id These applications would send messages with a constant Session-Id AVP
AVP, but with a different CC-Sub-Session-Id AVP. If several credit but with a different CC-Sub-Session-Id AVP. If several credit
sub-sessions will be used, all sub-sessions MUST be closed separately sub-sessions will be used, all sub-sessions MUST be closed separately
before the main session is closed so that units per sub-session may before the main session is closed so that units per sub-session may
be reported. The absence of this AVP implies that no sub-sessions be reported. The absence of the CC-Sub-Session-Id AVP implies that
are in use. no sub-sessions are in use.
Note that the service element might send a service-specific re- Note that the Service Element might send a service-specific
authorization message to the AAA server due to expiration of the re-authorization message to the AAA server due to expiration of the
authorization-lifetime during an ongoing credit-control session. authorization lifetime during an ongoing credit-control session.
However, the service-specific re-authorization does not influence the However, the service-specific re-authorization does not influence the
credit authorization that is ongoing between the credit-control credit authorization that is ongoing between the credit-control
client and credit-control server, as credit authorization is client and credit-control server, as credit authorization is
controlled by the burning rate of the granted quota. controlled by the burning rate of the granted quota.
If service-specific re-authorization fails, the user will be If service-specific re-authorization fails, the user will be
disconnected, and the credit-control client MUST send a final disconnected, and the credit-control client MUST send a final
interrogation to the credit-control server. interrogation to the credit-control server.
The Diameter credit-control server may seek to control the validity The Diameter Credit-Control server may seek to control the validity
time of the granted quota and/or the production of intermediate time of the granted quota and/or the production of intermediate
interrogations. Thus, it MAY include the Validity-Time AVP in the interrogations. Thus, it MAY include the Validity-Time AVP in the
answer message to the credit-control client. Upon expiration of the Answer message to the credit-control client. Upon expiration of the
Validity-Time, the credit-control client MUST generate a credit- Validity-Time, the credit-control client MUST generate a
control update request and report the used quota to the credit- credit-control update request and report the used quota to the
control server. It is up to the credit-control server to determine credit-control server. It is up to the credit-control server to
the value of the Validity-Time to be used for consumption of the determine the value of the Validity-Time to be used for consumption
granted service unit(s) (G-S-U). If the Validity-Time is used, its of the granted service unit(s) (G-S-U). If the Validity-Time is
value SHOULD be given as input to set the session supervision timer used, its value SHOULD be given as input to set the session
Tcc (the session supervision timer MAY be set to two times the value supervision timer Tcc (the session supervision timer MAY be set to
of the Validity-Time, as defined in Section 13). Since credit- two times the value of the Validity-Time, as defined in Section 13).
control update requests are also produced at the expiry of granted Since credit-control update requests are also produced at the expiry
service units and/or for mid-session service events, the omission of of granted service units and/or for mid-session service events, the
Validity-Time does not mean that intermediate interrogation for the omission of Validity-Time does not mean that intermediate
purpose of credit-control is not performed. interrogation for the purpose of credit-control is not performed.
5.1.1. Basic Tariff-Time Change Support 5.1.1. Basic Support for Tariff Time Change
The Diameter credit-control server and client MAY optionally support The Diameter Credit-Control server and client MAY optionally support
a tariff change mechanism. The Diameter credit-control server may a tariff change mechanism. The Diameter Credit-Control server may
include a Tariff-Time-Change AVP in the answer message. Note that include a Tariff-Time-Change AVP in the Answer message. Note that
the granted units should be allocated based on the worst-case the granted units should be allocated based on the worst-case
scenario in case of forthcoming tariff change, so that the overall scenario, so that the overall reported used units would never exceed
reported used units would never exceed the credit reservation. the credit reservation. For example, in the case of a forthcoming
tariff change, in which the new rate is higher, the allocation should
be given so it does not exceed the credit, assuming that all of it is
used after the tariff changed.
When the Diameter credit-control client reports the used units and a When the Diameter Credit-Control client reports the used units and a
tariff change has occurred during the reporting period, the Diameter tariff change has occurred during the reporting period, the Diameter
credit-control client MUST separately itemize the units used before Credit-Control client MUST separately itemize the units used before
and after the tariff change. If the client is unable to distinguish and after the tariff change. If the client is unable to distinguish
whether units straddling the tariff change were used before or after whether units straddling the tariff change were used before or after
the tariff change, the credit-control client MUST itemize those units the tariff change, the credit-control client MUST itemize those units
in a third category. in a third category.
If a client does not support the tariff change mechanism and it If a client does not support the tariff change mechanism and it
receives a CCA message carrying the Tariff-Time-Change AVP, it MUST receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
terminate the credit-control session, giving a reason of terminate the credit-control session, giving a reason of
DIAMETER_BAD_ANSWER in the Termination-Cause AVP. DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
For time based services, the quota is continuously consumed at the For time-based services, the quota is consumed at the rate of the
regular rate of 60 seconds per minute (ignoring leap seconds). At passage of real time (ignoring leap seconds). That is, precisely
the time when credit resources are allocated, the server already 1 second of quota is consumed per second of real time. At the time
knows how many units will be consumed before the tariff time change when credit resources are allocated, the server already knows how
and how many units will be consumed afterward. Similarly, the server many units will be consumed before the tariff time change and how
can determine the units consumed at the before rate and the units many units will be consumed afterward. Similarly, the server can
consumed at the rate afterward in the event that the end-user closes determine the units consumed at the "before" rate and the units
the session before the consumption of the allotted quota. There is consumed at the "afterward" rate in the event that the end user
no need for additional traffic between client and server in the case closes the session before the consumption of the allotted quota.
of tariff time changes for continuous time based service. Therefore, There is no need for additional traffic between the client and server
the tariff change mechanism is not used for such services. For time- in the case of tariff time changes for continuous time-based service.
based services in which the quota is NOT continuously consumed at a Therefore, the tariff change mechanism is not used for such services.
regular rate, the tariff change mechanism described for volume and For time-based services in which the quota is NOT continuously
event units MAY be used. consumed at a regular rate, the tariff change mechanism described for
volume and event units MAY be used.
5.1.2. Credit-Control for Multiple Services within a (sub-)Session 5.1.2. Credit-Control for Multiple Services within a (Sub-)Session
When multiple services are used within the same user session and each When multiple services are used within the same user session and each
service or group of services is subject to different cost, it is service or group of services is subject to different cost, it is
necessary to perform credit-control for each service independently. necessary to perform credit-control for each service independently.
Making use of credit-control sub-sessions to achieve independent Making use of credit-control sub-sessions to achieve independent
credit-control will result in increased signaling load and usage of credit-control will result in increased signaling load and usage of
resources in both the credit-control client and the credit-control resources in both the credit-control client and the credit-control
server. For instance, during one network access session the end user server. For instance, during one network access session, the
may use several http-services subject to different access cost. The end user may use several HTTP-based services that could be charged
network-access-specific attributes such as the quality of service with different costs. The network-access-specific attributes, such
(QoS) are common to all the services carried within the access as Quality of Service (QoS), are common to all the services carried
bearer, but the cost of the bearer may vary depending on its content. within the access bearer, but the cost of the bearer may vary,
depending on its content.
To support these scenarios optimally, the credit-control application To support these scenarios optimally, the credit-control application
enables independent credit-control of multiple services in a single enables independent credit-control of multiple services in a single
credit-control (sub-)session. This is achieved by including the credit-control (sub-)session. This is achieved by including the
optional Multiple-Services-Credit-Control AVP in Credit-Control- optional Multiple-Services-Credit-Control AVP in Credit-Control-
Request/Answer messages. It is possible to request and allocate Request/Credit-Control-Answer messages. It is possible to request
resources as a credit pool shared between multiple services. The and allocate resources as a credit pool shared between multiple
services can be grouped into rating groups in order to achieve even services. The services can be grouped into rating-groups in order to
further aggregation of credit allocation. It is also possible to achieve even further aggregation of credit allocation. It is also
request and allocate quotas on a per service basis. Where quotas are possible to request and allocate quotas on a per-service basis.
allocated to a pool by means of the Multiple-Services-Credit-Control Where quotas are allocated to a pool by means of the Multiple-
AVP, the quotas remain independent objects that can be re-authorized Services-Credit-Control AVP, the quotas remain independent objects
independently at any time. Quotas can also be given independent that can be re-authorized independently at any time. Quotas can also
result codes, validity times, and Final-Unit-Indications or QoS- be given independent result codes, validity times, and Final-Unit-
Final-Unit-Indications. Indication AVP values or QoS-Final-Unit-Indication AVP values.
A Rating-Group gathers a set of services, identified by a Service- A rating-group gathers a set of services, identified by a Service-
Identifier, and subject to the same cost and rating type (e.g., $0.1/ Identifier and subject to the same cost and rating type (e.g.,
minute). It is assumed that the service element is provided with $0.1/minute). It is assumed that the Service Element is provided
Rating-Groups, Service-Identifiers, and their associated parameters with rating-groups, service-identifiers, and their associated
that define what has to be metered by means outside the scope of this parameters that define what has to be metered by means outside the
specification. (Examples of parameters associated to Service- scope of this specification. (Examples of parameters associated to
Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers enable service-identifiers are IP 5-tuples and HTTP URLs.) Service-
authorization on a per-service based credit as well as itemized identifiers enable authorization on a per-service-based credit as
reporting of service usage. It is up to the credit-control server well as itemized reporting of service usage. It is up to the
whether to authorize credit for one or more services or for the whole credit-control server whether to authorize credit for one or more
rating-group. However, the client SHOULD always report used units at services or for the whole rating-group. However, the client SHOULD
the finest supported level of granularity. Where quota is allocated always report used units at the finest supported level of
to a rating-group, all the services belonging to that group draw from granularity. Where a quota is allocated to a rating-group, all the
the allotted quota. The following is a graphical representation of services belonging to that group draw from the allotted quota.
the relationship between service-identifiers, rating-groups, credit Figure 2 provides a graphical representation of the relationship
pools, and credit-control (sub-)session. between service-identifiers, rating-groups, credit pools, and
credit-control (sub-)sessions.
DCC (Sub-)Session Diameter Credit-Control (Sub-)Session
| |
+------------+-----------+-------------+--------------- + +------------+-----------+-------------+--------------- +
| | | | | | | | | |
Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
\ / \ / / \ / \ / /
\ / \ / / \ / \ / /
\ / Rating-Group 1.......Rating-Group n \ / Rating-Group 1.......Rating-Group n
\ / | | \ / | |
Quota ---------------Quota Quota Quota ---------------Quota Quota
| / | | / |
| / | | / |
Credit-Pool Credit-Pool Credit Pool Credit Pool
Figure 2: Multiple-Service (sub)-Session Example Figure 2: Multiple-Service (Sub-)Session Example
If independent credit-control of multiple services is used, the If independent credit-control of multiple services is used, the
Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- Validity-Time AVP, and the Final-Unit-Indication AVP or
Indication AVP SHOULD be present either in the Multiple-Services- QoS-Final-Unit-Indication AVP, SHOULD be present either in the
Credit-Control AVP(s) or at command level as single AVPs. However, Multiple-Services-Credit-Control AVP(s) or at the command level as
the Result-Code AVP MAY be present both on the command level and single AVPs. However, the Result-Code AVP MAY be present both at the
within the Multiple-Services-Credit-Control AVP. If the Result-Code command level and within the Multiple-Services-Credit-Control AVP.
AVP on the command level indicates a value other than SUCCESS, then If the Result-Code AVP at the command level indicates a value other
the Result-Code AVP on command level takes precedence over any than SUCCESS, then the Result-Code AVP at the command level takes
included in the Multiple-Services-Credit-Control AVP. precedence over any other AVPs included in the Multiple-Services-
Credit-Control AVP.
The credit-control client MUST indicate support for independent The credit-control client MUST indicate support for independent
credit-control of multiple services within a (sub-)session by credit-control of multiple services within a (sub-)session by
including the Multiple-Services-Indicator AVP in the first including the Multiple-Services-Indicator AVP in the first
interrogation. A credit-control server not supporting this feature interrogation. A credit-control server not supporting this feature
MUST treat the Multiple-Services-Indicator AVP and any received MUST treat the Multiple-Services-Indicator AVP and any received
Multiple-Services-Credit-Control AVPs as invalid AVPs. Multiple-Services-Credit-Control AVPs as invalid AVPs.
If the client indicated support for independent credit-control of If the client indicated support for independent credit-control of
multiple services, a credit-control server that wishes to use the multiple services, a credit-control server that wishes to use the
feature MUST return the granted units within the Multiple-Services- feature MUST return the granted units within the Multiple-Services-
Credit-Control AVP associated to the corresponding service-identifier Credit-Control AVP associated to the corresponding service-identifier
and/or rating-group. and/or rating-group.
To avoid a situation where several parallel (and typically also To avoid a situation where several parallel (and typically also
small) credit reservations must be made on the same account (i.e., small) credit reservations must be made on the same account (i.e.,
credit fragmentation), and also to avoid unnecessary load on the credit fragmentation), and also to avoid unnecessary load on the
credit-control server, it is possible to provide service units as a credit-control server, it is possible to provide service units as a
pool that applies to multiple services or rating groups. This is pool that applies to multiple services or rating-groups. This is
achieved by providing the service units in the form of a quota for a achieved by providing the service units in the form of a quota for a
particular service or rating group in the Multiple-Services-Credit- particular service or rating-group in the Multiple-Services-Credit-
Control AVP, and also by including a reference to a credit pool for Control AVP, and also by including a reference to a credit pool for
that unit type. that unit type.
The reference includes a multiplier derived from the rating The reference includes a multiplier derived from the rating
parameter, which translates from service units of a specific type to parameter, which translates from service units of a specific type to
the abstract service units in the pool. For instance, if the rating the abstract service units in the pool. For instance, if the rating
parameter for service 1 is $1/MB and the rating parameter for service parameter for service 1 is $1/MB and the rating parameter for
2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2, service 2 is $0.5/MB, the multipliers could be 10 and 5 for
respectively. services 1 and 2, respectively.
If S is the total service units within the pool, M1, M2, ..., Mn are If (1) S is the total service units within the pool, (2) M1, M2, ...,
the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., Mn are the multipliers provided for services 1, 2, ..., n, and
Cn are the used resources within the session, then the pool credit is (3) C1, C2, ..., Cn are the used resources within the session, then
exhausted and re-authorization MUST be sought when: the pool's credit is exhausted and re-authorization MUST be sought
when:
C1*M1 + C2*M2 + ... + Cn*Mn >= S C1*M1 + C2*M2 + ... + Cn*Mn >= S
The total credit in the pool, S, is calculated from the quotas, which The total credit in the pool, S, is calculated from the quotas, which
are currently allocated to the pool as follows: are currently allocated to the pool as follows:
S = Q1*M1 + Q2*M2 + ... + Qn*Mn S = Q1*M1 + Q2*M2 + ... + Qn*Mn
If services or rating groups are added to or removed from the pool, If services or rating-groups are added to or removed from the pool,
then the total credit is adjusted appropriately. Note that when the then the total credit is adjusted appropriately. Note that when the
total credit is adjusted because services or rating groups are total credit is adjusted because services or rating-groups are
removed from the pool, the value that need to be removed is the removed from the pool, the value that needs to be removed is the
consumed one (i.e., Cx*Mx). consumed one (i.e., Cx*Mx).
Re-authorizations for an individual service or rating group may be Re-authorizations for an individual service or rating-group may be
sought at any time; for example, if a 'non-pooled' quota is used up sought at any time -- for example, if a "non-pooled" quota is used up
or the Validity-Time expires. or the Validity-Time expires.
Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same
G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit- G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit-
Control AVP (Section 8.16) along with the Granted-Service-Unit AVP, Control AVP (Section 8.16) along with the Granted-Service-Unit AVP,
then these MUST have different CC-Unit-Type values, and they all draw these AVPs MUST have different CC-Unit-Type values, and they all draw
from the credit pool separately. For instance, if one multiplier for from the credit pool separately. For instance, if one multiplier for
time (M1t) and one multiplier for volume (M1v) are given, then the time (M1t) and one multiplier for volume (M1v) are given, then the
used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t used resources from the pool yield the sum of C1t*M1t + C1v*M1v,
is the time unit and C1v is the volume unit. where C1t is the time unit and C1v is the volume unit.
Where service units are provided within a Multiple-Services-Credit- Where service units are provided within a Multiple-Services-Credit-
Control AVP without a corresponding G-S-U-Pool-Reference AVP, then Control AVP without a corresponding G-S-U-Pool-Reference AVP, these
these are handled independently from any credit pool and from any units are handled independently from any credit pools and from any
other services or rating groups within the session. other services or rating-groups within the session.
The credit pool concept is an optimal tool to avoid the over- The "credit pool" concept is an optimal tool to avoid the
reservation effect of the basic single quota tariff time change over-reservation effect of the basic single-quota tariff time change
mechanism (the mechanism described in Section 5.1.1). Therefore, mechanism (Section 5.1.1). Therefore, Diameter Credit-Control
Diameter credit-control clients and servers implementing the clients and servers implementing the independent credit-control of
independent credit-control of multiple services SHOULD leverage the multiple services SHOULD leverage the credit pool concept when
credit pool concept when supporting the tariff time change. The supporting the tariff time change. The Diameter Credit-Control
Diameter credit-control server SHOULD include both the Tariff-Time- server SHOULD include both the Tariff-Time-Change AVP and the
Change and Tariff-Change-Usage AVPs in two quota allocations in the Tariff-Change-Usage AVP in two quota allocations in the Answer
answer message (i.e., two instances of the Multiple-Services-Credit- message (i.e., two instances of the Multiple-Services-Credit-Control
Control AVP). One of the granted units is allocated to be used AVP). One of the grants is allocated to be used before the potential
before the potential tariff change, while the second granted units tariff change, while the second grant is for use after a tariff
are for use after a tariff change. Both granted unit quotas MUST change. Both granted unit quotas MUST contain the same Service-
contain the same Service-Identifier and/or Rating-Group. This dual Identifier and/or rating-group. This dual-quota mechanism ensures
quota mechanism ensures that the overall reported used units would that the overall reported used units would never exceed the credit
never exceed the credit reservation. The Diameter credit-control reservation. The Diameter Credit-Control client reports the used
client reports both the used units before and after the tariff change units both before and after the tariff change in a single instance of
in a single instance of the Multiple-Services-Credit-Control AVP. the Multiple-Services-Credit-Control AVP.
The failure handling for credit-control sessions is defined in Failure handling for credit-control sessions is defined in
Section 5.7 and reflected in the basic credit-control state machine Section 5.7 and reflected in the basic credit-control state machines
in Section 7. Credit-control clients and servers implementing the defined in Section 7. Credit-control clients and servers
independent credit-control of multiple services in a (sub-)session implementing the functionality of independent credit-control of
functionality MUST ensure failure handling and general behavior fully multiple services in a (sub-)session MUST ensure failure handling and
consistent with the above mentioned sections, while maintaining the general behavior fully consistent with Sections 5.7 and 7 while
ability to handle parallel ongoing credit re-authorization within a maintaining the ability to handle parallel ongoing credit
(sub-)session. Therefore, it is RECOMMENDED that Diameter credit- re-authorization within a (sub-)session. Therefore, it is
control clients maintain a PendingU message queue and restart the Tx RECOMMENDED that Diameter Credit-Control clients maintain a PendingU
timer (Section 13) every time a CCR message with the value message queue (Section 7) and restart the Tx timer (Section 13) every
UPDATE_REQUEST is sent while they are in PendingU state. When time a CCR message with the value UPDATE_REQUEST is sent while they
answers to all pending messages are received, the state machine moves are in PendingU state. When answers to all pending messages are
to OPEN state, and Tx timer is stopped. Naturally, the action received, the state machine moves to Open state, and the Tx timer is
performed when a problem for the session is detected according to stopped. Naturally, when a problem is detected and acted upon per
Section 5.7 affects all the ongoing services (e.g., failover to a Section 5.7, all of the ongoing services are affected (e.g., failover
backup server if possible affect all the CCR messages with the value to a backup server affects all of the CCR messages in the PendingU
UPDATE_REQUEST in the PendingU queue). queue).
Since the client may send CCR messages with the value UPDATE_REQUEST Since the client may send CCR messages with the value UPDATE_REQUEST
while in PendingU (i.e., without waiting for an answer to ongoing while in PendingU state (i.e., without waiting for an answer to
credit re-authorization), the time space between these requests may ongoing credit re-authorization), the time space between these
be very short, and the server may not have received the previous requests may be very short, and the server may not have received the
request(s) yet. Therefore, in this situation the server may receive previous request(s) yet. Therefore, in this situation the server may
out of sequence requests and SHOULD NOT consider this an error receive out-of-sequence requests and SHOULD NOT consider this an
condition. A proper answer is to be returned to each of those error condition. A proper answer is to be returned to each of those
requests. requests.
5.2. First Interrogation 5.2. First Interrogation
When session based credit-control is required (e.g., the When session-based credit-control is required (e.g., the
authentication server indicated a prepaid user), the first authentication server indicated a prepaid user), the first
interrogation MUST be sent before the Diameter credit-control client interrogation MUST be sent before the Diameter Credit-Control client
allows any service event to the end user. The CC-Request-Type is set allows any service events for the end user. The CC-Request-Type AVP
to the value INITIAL_REQUEST in the request message. is set to the value INITIAL_REQUEST in the request message.
If the Diameter credit-control client knows the cost of the service If the Diameter Credit-Control client knows the cost of the service
event (e.g., a content server delivering ringing tones may know their event (e.g., a content server delivering ringing tones may know their
cost) the monetary amount to be charged is included in the Requested- cost) the monetary amount to be charged is included in the Requested-
Service-Unit AVP. If the Diameter credit-control client does not Service-Unit AVP. If the Diameter Credit-Control client does not
know the cost of the service event, the Requested-Service-Unit AVP know the cost of the service event, the Requested-Service-Unit AVP
MAY contain the number of requested service events. Where the MAY contain the number of requested service events. Where the
Multiple-Services-Credit-Control AVP is used, it MUST contain the Multiple-Services-Credit-Control AVP is used, it MUST contain the
Requested-Service-Unit AVP to indicate that the quota for the Requested-Service-Unit AVP to indicate that the quota for the
associated service/rating-group is requested. In the case of associated service/rating-group is requested. In the case of
multiple services, the Service-Identifier AVP or the Rating-Group AVP multiple services, the Service-Identifier AVP or the Rating-Group AVP
within the Multiple-Services-Credit-Control AVP always indicates the within the Multiple-Services-Credit-Control AVP always indicates the
service concerned. Additional service event information to be rated service concerned. Additional service event information to be rated
MAY be sent as service-specific AVPs or MAY be sent within the MAY be sent as service-specific AVPs or MAY be sent within the
Service-Parameter-Info AVP at command level. The Service-Context-Id Service-Parameter-Info AVP at the command level. The
AVP indicates the service-specific document applicable to the Service-Context-Id AVP indicates the service-specific document
request. applicable to the request.
The Event-Timestamp AVP SHOULD be included in the request and The Event-Timestamp AVP SHOULD be included in the request and
contains the time when the service event is requested in the service contains the time when the service event is requested in the Service
element. The Subscription-Id AVP or the Subscription-Id-Extension Element. The Subscription-Id AVP or the Subscription-Id-Extension
AVP SHOULD be included to identify the end user in the credit-control AVP SHOULD be included to identify the end user in the credit-control
server. The credit-control client MAY include the User-Equipment- server. The credit-control client MAY include the User-Equipment-
Info AVP or User-Equipment-Info-Extension AVP so that the credit- Info AVP or User-Equipment-Info-Extension AVP so that the
control server has some indication of the type and capabilities of credit-control server has some indication of the type and
the end user access device. How the credit-control server uses this capabilities of the end-user access device. How the credit-control
information is outside the scope of this document. server uses this information is outside the scope of this document.
The credit-control server SHOULD rate the service event and make a The credit-control server SHOULD rate the service event and make a
credit-reservation from the end user's account that covers the cost credit reservation from the end user's account that covers the cost
of the service event. If the type of the Requested-Service-Unit AVP of the service event. If the type of the Requested-Service-Unit AVP
is money, no rating is needed, but the corresponding monetary amount is "money", no rating is needed, but the corresponding monetary
is reserved from the end user's account. amount is reserved from the end user's account.
The credit-control server returns the Granted-Service-Unit AVP in the The credit-control server returns the Granted-Service-Unit AVP in the
Answer message to the Diameter credit-control client. The Granted- Answer message to the Diameter Credit-Control client. The Granted-
Service-Unit AVP contains the amount of service units that the Service-Unit AVP contains the amount of service units that the
Diameter credit-control client can provide to the end user until a Diameter Credit-Control client can provide to the end user until a
new Credit-Control-Request MUST be sent to the credit-control server. new Credit-Control-Request MUST be sent to the credit-control server.
If several unit types are sent in the Answer message, the credit- If several unit types are sent in the Answer message, the
control client MUST handle each unit type separately. The type of credit-control client MUST handle each unit type separately. The
the Granted-Service-Unit AVP can be time, volume, service-specific, type of the Granted-Service-Unit AVP can be time, volume, service-
or money, depending on the type of service event. The unit type(s) specific, or money, depending on the type of service event. The unit
SHOULD NOT be changed within an ongoing credit-control session. type(s) SHOULD NOT be changed within an ongoing credit-control
session.
There MUST be a maximum of one instance of the same unit type in one There MUST be a maximum of one instance of the same unit type in one
Answer message. However, if multiple quotas are conveyed to the Answer message. However, if multiple quotas are conveyed to the
credit-control client in the Multiple-Services-Credit-Control AVPs, credit-control client in the Multiple-Services-Credit-Control AVPs,
it is possible to carry two instances of the same unit type it is possible to carry two instances of the same unit type
associated to a service-identifier/rating-group. This is typically associated to a service-identifier/rating-group. This is typically
the case when a tariff time change is expected and the credit-control the case when a tariff time change is expected and the credit-control
server wants to make a distinction between the granted quota before server wants to make a distinction between the granted quota before
and after tariff change. the tariff change and the granted quota after the tariff change.
If the credit-control server determines that no further control is If the credit-control server determines that no further control is
needed for the service, it MAY include the result code indicating needed for the service, it MAY include the result code indicating
that the credit-control is not applicable (e.g., if the service is that the credit-control is not applicable (e.g., if the service is
free of charge). This result code at command level implies that the free of charge). This result code, at the command level, implies
credit-control session is to be terminated. that the credit-control session is to be terminated.
The Credit-Control-Answer message MAY also include the Final-Unit- The Credit-Control-Answer message MAY also include the Final-Unit-
Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
the answer message contains the final units for the service. After the Answer message contains the final units for the service. After
the end user has consumed these units, the Diameter credit-control- the end user has consumed these units, the Diameter Credit-Control
client MUST behave as described in Section 5.6. client MUST behave as described in Section 5.6.
This document defines two different approaches to perform the first This document defines two different approaches for performing the
interrogation to be used in different network architectures. The first interrogation to be used in different network architectures.
first approach uses credit-control messages after the user's The first approach uses credit-control messages after the user's
authorization and authentication takes place. The second approach authorization and authentication take place. The second approach
uses service-specific authorization messages to perform the first uses (1) service-specific authorization messages to perform the first
interrogation during the user's authorization/authentication phase, interrogation during the user's authorization/authentication phase
and credit-control messages for the intermediate and final and (2) credit-control messages for the intermediate and final
interrogations. If an implementation of the credit-control client interrogations. If an implementation of the credit-control client
supports both the methods, determining which method to use SHOULD be supports both methods, determining which method to use SHOULD be
configurable. configurable.
In service environments such as the Network Access Server (NAS), it In service environments such as NAS environments, it is desired to
is desired to perform the first interrogation as part of the perform the first interrogation as part of the authorization/
authorization/authentication process for the sake of protocol authentication process for the sake of protocol efficiency. Further
efficiency. Further credit authorizations after the first credit authorizations after the first interrogation are performed
interrogation are performed with credit-control commands defined in with credit-control commands defined in this specification.
this specification. Implementations of credit-control clients Implementations of credit-control clients operating in the
operating in the mentioned environments SHOULD support this method. environments mentioned in this document SHOULD support this method.
If the credit-control server and AAA server are separate physical If the credit-control server and AAA server are separate physical
entities, the service element sends the request messages to the AAA entities, the Service Element sends the request messages to the AAA
server, which then issues an appropriate request or proxies the server, which then issues an appropriate request or proxies the
received request forward to the credit-control server. received request forward to the credit-control server.
In other service environments, such as the 3GPP network and some SIP In other service environments, such as the 3GPP network and some SIP
scenarios, there is a substantial decoupling between registration/ scenarios, there is a substantial decoupling between registration/
access to the network and the actual service request (i.e., the access to the network and the actual service request (i.e., the
authentication/authorization is executed once at registration/access authentication/authorization is executed once during registration/
to the network and is not executed for every service event requested access to the network and is not executed for every service event
by the subscriber). In these environments, it is more appropriate to requested by the subscriber). In these environments, it is more
perform the first interrogation after the user has been authenticated appropriate to perform the first interrogation after the user has
and authorized. The first, the intermediate, and the final been authenticated and authorized. The first, intermediate, and
interrogations are executed with credit-control commands defined in final interrogations are executed with credit-control commands
this specification. defined in this specification.
Other IETF standards or standards developed by other standardization Other IETF standards or standards developed by other standardization
bodies may define the most suitable method in their architectures. bodies may define the most suitable method in their architectures.
5.2.1. First Interrogation after Authorization and Authentication 5.2.1. First Interrogation after Authorization and Authentication
The Diameter credit-control client in the service element may get The Diameter Credit-Control client in the Service Element may get
information from the authorization server as to whether credit- information from the authorization server as to whether
control is required, based on its knowledge of the end user. If credit-control is required, based on its knowledge of the end user.
credit-control is required the credit-control server needs to be If credit-control is required, the credit-control server needs to be
contacted prior to initiating service delivery to the end user. The contacted prior to initiating service delivery to the end user. The
accounting protocol and the credit-control protocol can be used in accounting protocol and the credit-control protocol can be used in
parallel. The authorization server may also determine whether the parallel. The authorization server may also determine whether the
parallel accounting stream is required. parallel accounting stream is required.
The following diagram illustrates the case where both protocols are Figure 3 illustrates the case where both protocols are used in
used in parallel and the service element sends credit-control parallel and the Service Element sends credit-control messages
messages directly to the credit-control server. More credit-control directly to the credit-control server. More credit-control sequence
sequence examples are given in Annex A. examples are given in Appendix A.
Diameter Diameter
End User Service Element AAA Server CC Server End User Service Element AAA Server CC Server
(CC Client) (CC Client)
| Registration | AA request/answer(accounting,cc or both)| | Registration | AA-Request/Answer(accounting, CC, or both)|
|<----------------->|<------------------>| | |<----------------->|<------------------>| |
| : | | | | : | | |
| : | | | | : | | |
| Service Request | | | | Service Request | | |
|------------------>| | | |------------------>| | |
| | CCR(Initial,Credit-Control AVPs) | | | CCR(Initial, Credit-Control AVPs) |
| +|---------------------------------------->| | +|------------------------------------------>|
| CC stream|| | CCA(Granted-Units)| | CC stream|| | CCA(Granted-Units)|
| +|<----------------------------------------| | +|<------------------------------------------|
| Service Delivery | | | | Service Delivery | | |
|<----------------->| ACR(start,Accounting AVPs) | |<----------------->| ACR(start, Accounting AVPs) |
| : |------------------->|+ | | : |------------------->|+ |
| : | ACA || Accounting stream | | : | ACA || Accounting stream |
| |<-------------------|+ | | |<-------------------|+ |
| : | | | | : | | |
| : | | | | : | | |
| | CCR(Update,Used-Units) | | | CCR(Update, Used-Units) |
| |---------------------------------------->| | |------------------------------------------>|
| | | CCA(Granted-Units)| | | | CCA(Granted-Units)|
| |<----------------------------------------| | |<------------------------------------------|
| : | | | | : | | |
| : | | | | : | | |
| End of Service | | | | End of Service | | |
|------------------>| CCR(Termination, Used-Units) | |------------------>| CCR(Termination, Used-Units) |
| |---------------------------------------->| | |------------------------------------------>|
| | | CCA | | | | CCA |
| |<----------------------------------------| | |<------------------------------------------|
| | ACR(stop) | | | | ACR(stop) | |
| |------------------->| | | |------------------->| |
| | ACA | | | | ACA | |
| |<-------------------| | | |<-------------------| |
Figure 3: Protocol example with first interrogation after user's ACR: Accounting-Request
authorization/authentication ACA: Accounting-Answer
Figure 3: Protocol Example with First Interrogation
after User's Authorization/Authentication
5.2.2. First Interrogation Included with Authorization Messages 5.2.2. First Interrogation Included with Authorization Messages
The Diameter credit-control client in the service element MUST The Diameter Credit-Control client in the Service Element MUST
actively co-operate with the authorization/authentication client in actively co-operate with the authorization/authentication client in
the construction of the AA request by adding appropriate credit- the construction of the AA-Request by adding appropriate
control AVPs. The credit-control client MUST add the Credit-Control Credit-Control AVPs. The credit-control client MUST add the
AVP to indicate credit-control capabilities and MAY add other Credit-Control AVP to indicate credit-control capabilities and MAY
relevant credit-control-specific AVPs to the proper authorization/ add other relevant credit-control-specific AVPs to the proper
authentication command to perform the first interrogation toward the authorization/authentication command to perform the first
home Diameter AAA server. The Auth-Application-Id is set to the interrogation toward the home Diameter AAA server. The
appropriate value, as defined in the relevant service-specific Auth-Application-Id is set to the appropriate value, as defined in
authorization/authentication application document (e.g., [RFC7155], service-specific authorization/authentication application document
[RFC4004]). The home Diameter AAA server authenticates/authorizes (e.g., [RFC7155] [RFC4004]). The home Diameter AAA server
the subscriber and determines whether credit-control is required. authenticates/authorizes the subscriber and determines whether
credit-control is required.
If credit-control is not required for the subscriber, the home If credit-control is not required for the subscriber, the home
Diameter AAA server will respond as usual, with an appropriate AA Diameter AAA server will respond as usual, with an appropriate
answer message. If credit-control is required for the subscriber and AA-Answer message. If credit-control is required for the subscriber
the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was and the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION
present in the authorization request, the home AAA server MUST was present in the authorization request, the home AAA server MUST
contact the credit-control server to perform the first interrogation. contact the credit-control server to perform the first interrogation.
If credit-control is required for the subscriber and the Credit- If credit-control is required for the subscriber and the
Control AVP was not present in the authorization request, the home Credit-Control AVP was not present in the authorization request, the
AAA server MUST send an authorization reject answer message. home AAA server MUST send an authorization reject Answer message.
The Diameter AAA server supporting credit-control is required to send The Diameter AAA server supporting credit-control is required to send
the Credit-Control-Request command (CCR) defined in this document to the Credit-Control-Request command (CCR) defined in this document to
the credit-control server. The Diameter AAA server populates the CCR the credit-control server. The Diameter AAA server populates the CCR
based on service-specific AVPs used for input to the rating process, based on service-specific AVPs used for input to the rating process,
and possibly on credit-control AVPs received in the AA request. The and possibly on Credit-Control AVPs received in the AA-Request. The
credit-control server will reserve money from the user's account, credit-control server will reserve money from the user's account,
will rate the request and will send a Credit-Control-Answer message will rate the request, and will send a Credit-Control-Answer message
to the home Diameter AAA server. The answer message includes the to the home Diameter AAA server. The Answer message includes the
Granted-Service-Unit AVP(s) and MAY include other credit-control- Granted-Service-Unit AVP(s) and MAY include other credit-control-
specific AVPs, as appropriate. Additionally, the credit-control specific AVPs, as appropriate. Additionally, the credit-control
server MAY set the Validity-Time and MAY include the Credit-Control- server MAY set the Validity-Time and MAY include the CCFH and the
Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to DDFH to determine what to do if the sending of credit-control
determine what to do if the sending of credit-control messages to the messages to the credit-control server has been temporarily prevented.
credit-control server has been temporarily prevented.
Upon receiving the Credit-Control-Answer message from the credit- Upon receiving the Credit-Control-Answer message from the
control server, the home Diameter AAA server will populate the AA credit-control server, the home Diameter AAA server will populate the
answer with the received credit-control AVPs and with the appropriate AA-Answer with the received Credit-Control AVPs and with the
service attributes according to the authorization/authentication- appropriate service attributes according to the authorization/
specific application (e.g., [RFC7155], [RFC4004]). It will then authentication-specific application (e.g., [RFC7155] [RFC4004]). It
forward the packet to the credit-control client. If the home will then forward the packet to the credit-control client. If the
Diameter AAA server receives a credit-control reject message, it will home Diameter AAA server receives a credit-control reject message, it
simply generate an appropriate authorization reject message to the will simply generate an appropriate authorization reject message to
credit-control client, including the credit-control-specific error the credit-control client, including the credit-control-specific
code. error code.
In this model, the credit-control client sends further credit-control In this model, the credit-control client sends further credit-control
messages to the credit-control server via the home Diameter AAA messages to the credit-control server via the home Diameter AAA
server. Upon receiving a successful authorization answer message server. Upon receiving a successful authorization Answer message
with the Granted-Service-Unit AVP(s), the credit-control client will with the Granted-Service-Unit AVP(s), the credit-control client will
grant the service to the end user and will generate an intermediate grant the service to the end user and will generate an intermediate
credit-control request, as required by using credit-control commands. Credit-Control-Request, if required, by using credit-control
commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be
The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 set to 1 (for details regarding how to produce a unique value for the
(for how to produce unique value for the CC-Request-Number AVP, see CC-Request-Number AVP, see Section 8.2).
Section 8.2).
If service-specific re-authorization is performed (i.e., If service-specific re-authorization is performed (i.e., the
authorization-lifetime expires), the credit-control client MUST add authorization lifetime expires), the credit-control client MUST add
to the service-specific re-authorization request the Credit-Control to the service-specific re-authorization request the Credit-Control
AVP with a value set to RE_AUTHORIZATION to indicate that the credit- AVP with a value set to RE_AUTHORIZATION to indicate that the
control server MUST NOT be contacted. When session based credit- credit-control server MUST NOT be contacted. When session-based
control is used for the subscriber, a constant credit-control message credit-control is used for the subscriber, a constant credit-control
stream flows through the home Diameter AAA server. The home Diameter message stream flows through the home Diameter AAA server. The home
AAA server can make use of this credit-control message flow to deduce Diameter AAA server can make use of this credit-control message flow
that the user's activity is ongoing; therefore, it is recommended to to deduce that the user's activity is ongoing; therefore, it is
set the authorization-lifetime to a reasonably high value when recommended to set the authorization lifetime to a reasonably high
credit-control is used for the subscriber. value when credit-control is used for the subscriber.
In this scenario, the home Diameter AAA server MUST advertise support In this scenario, the home Diameter AAA server MUST advertise support
for the credit-control application to its peers during the capability for the credit-control application to its peers during the capability
exchange process. exchange process.
The following diagram illustrates the use of authorization/ Figure 4 illustrates the use of authorization/authentication messages
authentication messages to perform the first interrogation. The to perform the first interrogation. The parallel accounting stream
parallel accounting stream is not shown in the figure. is not shown in the figure.
Service Element Diameter Diameter
End User (CC Client) AAA Server CC Server Service Element AAA Server CC Server
| Service Request | AA Request (CC AVPs) | End User (CC Client)
|------------------>|------------------->| | | Service Request | AA-Request (CC AVPs) | |
| | | CCR(Initial, CC AVPs) |------------------>|--------------------->| |
| | |------------------->| | | | CCR(Initial, CC AVPs)
| | | CCA(Granted-Units) | | |-------------------->|
| | |<-------------------| | | | CCA(Granted-Units)|
| | AA Answer(Granted-Units) | | | |<--------------------|
| Service Delivery |<-------------------| | | | AA-Answer(Granted-Units) |
|<----------------->| | | | Service Delivery |<---------------------| |
| : | | | |<----------------->| | |
| : | | | | : | | |
| : | | | | : | | |
| | | | | : | | |
| | CCR(Update,Used-Units) | | | | |
| |------------------->| CCR(Update,Used-Units) | | CCR(Update, Used-Units) |
| | |------------------->| | |--------------------->| CCR(Update, Used-Units)
| | | CCA(Granted-Units)| | | |-------------------->|
| | CCA(Granted-Units)|<-------------------| | | | CCA(Granted-Units)|
| |<-------------------| | | | CCA(Granted-Units)|<--------------------|
| : | | | | |<---------------------| |
| : | | | | : | | |
| End of Service | | | | : | | |
|------------------>| CCR(Termination,Used-Units) | | End of Service | | |
| |------------------->| CCR(Term.,Used-Units) |------------------>| CCR(Termination, Used-Units) |
| | |------------------->| | |--------------------->| CCR(Term., Used-Units)
| | | CCA | | | |-------------------->|
| | CCA |<-------------------| | | | CCA |
| |<-------------------| | | | CCA |<--------------------|
| |<---------------------| |
Figure 4: Protocol example with use of the authorization messages for Figure 4: Protocol Example with Use of Authorization Messages
the first interrogation for the First Interrogation
5.3. Intermediate Interrogation 5.3. Intermediate Interrogation
When all the granted service units for one unit type are spent by the When all the granted service units for one unit type are spent by the
end user or the Validity-Time is expired, the Diameter credit-control end user or the Validity-Time has expired, the Diameter
client MUST send a new Credit-Control-Request to the credit-control Credit-Control client MUST send a new Credit-Control-Request to the
server. In the event that credit-control for multiple services is credit-control server. In the event that credit-control for multiple
applied in one credit-control session (i.e., units associated to services is applied in one credit-control session (i.e., units
Service-Identifier(s) or Rating-Group are granted), a new Credit- associated to Service-Identifier(s) or the rating-group are granted),
Control-Request MUST be sent to the credit-control server when the a new Credit-Control-Request MUST be sent to the credit-control
credit reservation has been wholly consumed, or upon expiration of server when the credit reservation has been wholly consumed or upon
the Validity-Time. It is always up to the Diameter credit-control expiration of the Validity-Time. It is always up to the Diameter
client to send a new request well in advance of the expiration of the Credit-Control client to send a new request well in advance of the
previous request in order to avoid interruption in the service expiration of the previous request in order to avoid interruption in
element. Even if the granted service units reserved by the credit- the Service Element. Even if the granted service units reserved by
control server have not been spent upon expiration of the Validity- the credit-control server have not been spent upon expiration of the
Time, the Diameter credit-control client MUST send a new Credit- Validity-Time, the Diameter Credit-Control client MUST send a new
Control-Request to the credit-control server. Credit-Control-Request to the credit-control server.
There can also be mid-session service events, which might affect the There can also be mid-session service events, which might affect the
rating of the current service events. In this case, a spontaneous rating of the current service events. In this case, a spontaneous
updating (a new Credit-Control-Request) SHOULD be sent including update (a new Credit-Control-Request) SHOULD be sent, including
information related to the service event even if all the granted information related to the service event, even if all the granted
service units have not been spent or the Validity-Time has not service units have not been spent or the Validity-Time has not
expired. expired.
When the used units are reported to the credit-control server, the When the used units are reported to the credit-control server, the
credit-control client will not have any units in its possession credit-control client will not have any units in its possession
before new granted units are received from the credit-control server. before new granted units are received from the credit-control server.
When the new granted units are received, these units apply from the When the new granted units are received, these units apply from the
point where the measurement of the reported used units stopped. point where the measurement of the reported used units stopped.
Where independent credit-control of multiple services is supported, Where independent credit-control of multiple services is supported,
this process may be executed for one or more services, a single this process may be executed for one or more services, a single
rating-group, or a pool within the (sub)session. rating-group, or a pool within the (sub-)session.
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the
intermediate request message. The Subscription-Id AVP or intermediate request message. The Subscription-Id AVP or
Subscription-Id-Extension AVP SHOULD be included in the intermediate Subscription-Id-Extension AVP SHOULD be included in the intermediate
message to identify the end user in the credit-control server. The message to identify the end user in the credit-control server. The
Service-Context-Id AVP indicates the service-specific document Service-Context-Id AVP indicates the service-specific document
applicable to the request. applicable to the request.
The Requested-Service-Unit AVP MAY contain the new amount of The Requested-Service-Unit AVP MAY contain the new amount of
requested service units. Where the Multiple-Services-Credit-Control requested service units. Where the Multiple-Services-Credit-Control
AVP is used, it MUST contain the Requested-Service-Unit AVP if a new AVP is used, it MUST contain the Requested-Service-Unit AVP if a new
quota is requested for the associated service/rating-group. The quota is requested for the associated service/rating-group. The
Used-Service-Unit AVP contains the amount of used service units Used-Service-Unit AVP contains the amount of used service units
measured from the point when the service became active or, if interim measured from the point when the service became active or, if interim
interrogations are used during the session, from the point when the interrogations are used during the session, from the point when the
previous measurement ended. The same unit types used in the previous previous measurement ended. The same unit types used in the previous
message SHOULD be used. If several unit types were included in the message SHOULD be used. If several unit types were included in the
previous answer message, the used service units for each unit type previous Answer message, the used service units for each unit type
MUST be reported. MUST be reported.
The Event-Timestamp AVP SHOULD be included in the request and The Event-Timestamp AVP SHOULD be included in the request and
contains the time of the event that triggered the sending of the new contains the time of the event that triggered the sending of the new
Credit-Control-Request. Credit-Control-Request.
The credit-control server MUST deduct the used amount from the end The credit-control server MUST deduct the used amount from the
user's account. It MAY rate the new request and make a new credit- end user's account. It MAY rate the new request and make a new
reservation from the end user's account that covers the cost of the credit reservation from the end user's account that covers the cost
requested service event. of the requested service event.
A Credit-Control-Answer message with the CC-Request-Type AVP set to A Credit-Control-Answer message with the CC-Request-Type AVP set to
the value UPDATE_REQUEST MAY include the Cost-Information AVP the value UPDATE_REQUEST MAY include the Cost-Information AVP
containing the accumulated cost estimation for the session, without containing the accumulated cost estimation for the session, without
taking any credit-reservation into account. taking any credit reservations into account.
The Credit-Control-Answer message MAY also include the Final-Unit- The Credit-Control-Answer message MAY also include the Final-Unit-
Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that
the answer message contains the final units for the service. After the Answer message contains the final units for the service. After
the end user has consumed these units, the Diameter credit-control- the end user has consumed these units, the Diameter Credit-Control
client MUST behave as described in Section 5.6. client MUST behave as described in Section 5.6.
There can be several intermediate interrogations within a session. There can be several intermediate interrogations within a session.
5.4. Final Interrogation 5.4. Final Interrogation
When the end user terminates the service session, or when the When the end user terminates the service session or when graceful
graceful service termination described in Section 5.6 takes place, service termination (described in Section 5.6) takes place, the
the Diameter credit-control client MUST send a final Credit-Control- Diameter Credit-Control client MUST send a final Credit-Control-
Request message to the credit-control server. The CC-Request-Type Request message to the credit-control server. The CC-Request-Type
AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id
AVP indicates the service-specific document applicable to the AVP indicates the service-specific document applicable to the
request. request.
The Event-Timestamp AVP SHOULD be included in the request and The Event-Timestamp AVP SHOULD be included in the request and
contains the time when the session was terminated. contains the time when the session was terminated.
The Used-Service-Unit AVP contains the amount of used service units The Used-Service-Unit AVP contains the amount of used service units
measured from the point when the service became active or, if interim measured from the point when the service became active or, if interim
interrogations are used during the session, from the point when the interrogations are used during the session, from the point when the
previous measurement ended. If several unit types were included in previous measurement ended. If several unit types were included in
the previous answer message, the used service units for each unit the previous Answer message, the used service units for each unit
type MUST be reported. type MUST be reported.
After final interrogation, the credit-control server MUST refund the After final interrogation, the credit-control server MUST refund the
reserved credit amount not used to the end user's account and deduct reserved credit amount not used to the end user's account and deduct
the used monetary amount from the end user's account. the used monetary amount from the end user's account.
A Credit-Control-Answer message with the CC-Request-Type set to the A Credit-Control-Answer message with the CC-Request-Type AVP set to
value TERMINATION_REQUEST MAY include the Cost-Information AVP the value TERMINATION_REQUEST MAY include the Cost-Information AVP
containing the estimated total cost for the session in question. containing the estimated total cost for the session in question.
If the user logs off during an ongoing credit-control session, or if If the user logs off during an ongoing credit-control session or if
some other reason causes the user to become logged off (e.g., final- the user becomes logged off for some other reason (e.g., a final-unit
unit indication causes user logoff according to local policy), the indication causes user logoff according to local policy), the Service
service element, according to application-specific policy, may send a Element, according to application-specific policy, may send a
Session-Termination-Request (STR) to the home Diameter AAA server as Session-Termination-Request (STR) to the home Diameter AAA server as
usual [RFC6733]. Figure 5 illustrates the case when the final-unit usual [RFC6733]. Figure 5 illustrates the case when the final-unit
indication causes user logoff upon consumption of the final granted indication causes user logoff upon consumption of the final granted
units and the generation of STR. units and the generation of an STR.
Service Element AAA Server CC Server The Diameter AAA server responds with a Session-Termination-Answer
End User (CC Client) (STA).
| Service Delivery | | |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | CCA(Final-Unit, Terminate)
| CCA(Final-Unit, Terminate)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| Disconnect user | | |
|<------------------| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
| | STR | |
| |------------------->| |
| | STA | |
| |<-------------------| |
Figure 5: User disconnected due to exhausted account Service Element AAA Server CC Server
End User (CC Client)
| Service Delivery | | |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update, Used-Units) |
| |-------------------->| CCR(Update, Used-Units)
| | |-------------------->|
| | CCA(Final-Unit, Terminate)
| CCA(Final-Unit, Terminate)|<--------------------|
| |<--------------------| |
| : | | |
| : | | |
| Disconnect user | | |
|<------------------| CCR(Termination, Used-Units) |
| |-------------------->| CCR(Term., Used-Units)
| | |-------------------->|
| | | CCA |
| | CCA |<--------------------|
| |<--------------------| |
| | STR | |
| |-------------------->| |
| | STA | |
| |<--------------------| |
5.5. Server-Initiated Credit Re-Authorization Figure 5: User Disconnected Due to Exhausted Account
The Diameter credit-control application supports server-initiated re- 5.5. Server-Initiated Credit Re-authorization
authorization. The credit-control server MAY optionally initiate the
credit re-authorization by issuing a Re-Auth-Request (RAR) as defined The Diameter Credit-Control application supports server-initiated
in the Diameter base protocol [RFC6733]. The Auth-Application-Id in re-authorization. The credit-control server MAY optionally initiate
the RAR message is set to 4 to indicate Diameter Credit Control, and the credit re-authorization by issuing a Re-Auth-Request (RAR) as
the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. defined in the Diameter base protocol [RFC6733]. The
Auth-Application-Id in the RAR message is set to 4 to indicate
"Diameter Credit Control", and the Re-Auth-Request-Type is set to
AUTHORIZE_ONLY.
Section 5.1.2 defines the feature to enable credit-control for Section 5.1.2 defines the feature to enable credit-control for
multiple services within a single (sub-)session where the server can multiple services within a single (sub-)session where the server can
authorize credit usage at a different level of granularity. Further, authorize credit usage at a different level of granularity. Further,
the server may provide credit resources to multiple services or the server may provide credit resources to multiple services or
rating groups as a pool (see Section 5.1.2 for details and rating-groups as a pool (see Section 5.1.2 for details and
definitions). Therefore, the server, based on its service logic and definitions). Therefore, the server, based on its service logic and
its knowledge of the ongoing session, can decide to request credit its knowledge of the ongoing session, can decide to request credit
re-authorization for a whole (sub-)session, a single credit pool, a re-authorization for a whole (sub-)session, a single credit pool, a
single service, or a single rating-group. To request credit re- single service, or a single rating-group. To request credit
authorization for a credit pool, the server includes in the RAR re-authorization for a credit pool, the server includes in the RAR
message the G-S-U-Pool-Identifier AVP indicating the affected pool. message the G-S-U-Pool-Identifier AVP indicating the affected pool.
To request credit re-authorization for a service or a rating-group, To request credit re-authorization for a service or a rating-group,
the server includes in the RAR message the Service-Identifier AVP or the server includes in the RAR message the Service-Identifier AVP or
the Rating-Group AVP, respectively. To request credit re- the Rating-Group AVP, respectively. To request credit
authorization for all the ongoing services within the (sub-)session, re-authorization for all the ongoing services within the
the server includes none of the above mentioned AVPs in the RAR (sub-)session, the server includes none of the above-mentioned AVPs
message. in the RAR message.
If a credit re-authorization is not already ongoing (i.e., the If a credit re-authorization is not already ongoing (i.e., the
credit-control session is in Open state), a credit-control client credit-control session is in Open state), a credit-control client
that receives an RAR message with Session-Id equal to a currently that receives an RAR message with Session-Id equal to a currently
active credit-control session MUST acknowledge the request by sending active credit-control session MUST acknowledge the request by sending
the Re-Auth-Answer (RAA) message and MUST initiate the credit re- the Re-Auth-Answer (RAA) message and MUST initiate the credit
authorization toward the server by sending a Credit-Control-Request re-authorization toward the server by sending a Credit-Control-
message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. Request message with the CC-Request-Type AVP set to the value
The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS)
RAA message to indicate that an additional message (i.e., CCR message SHOULD be used in the RAA message to indicate that an additional
with the value UPDATE_REQUEST) is required to complete the procedure. message (i.e., a CCR message with the value UPDATE_REQUEST) is
If a quota was allocated to the service, the credit-control client required to complete the procedure. If a quota was allocated to the
MUST report the used quota in the Credit-Control-Request. Note that service, the credit-control client MUST report the used quota in the
the end user does not need to be prompted for the credit re- Credit-Control-Request. Note that the end user does not need to be
authorization, since the credit re-authorization is transparent to prompted for the credit re-authorization, since the credit
the user (i.e., it takes place exclusively between the credit-control re-authorization is transparent to the user (i.e., it takes place
client and the credit-control server). exclusively between the credit-control client and the credit-control
server).
Where multiple services in a user's session are supported, the Where multiple services in a user's session are supported, the
procedure in the above paragraph will be executed at the granularity procedure in the above paragraph will be executed at the granularity
requested by the server in the RAR message. requested by the server in the RAR message.
If credit re-authorization is ongoing at the time when the RAR If credit re-authorization is ongoing at the time when the RAR
message is received (i.e., RAR-CCR collision), the credit-control message is received (i.e., an RAR-CCR collision), the credit-control
client successfully acknowledges the request but does not initiate a client successfully acknowledges the request but does not initiate a
new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS)
SHOULD be used in the RAA message to indicate that a credit re- SHOULD be used in the RAA message to indicate that a credit
authorization procedure is already ongoing (i.e., the client was in re-authorization procedure is already ongoing (i.e., the client was
PendingU state when the RAR was received). The credit-control server in PendingU state when the RAR was received). The credit-control
SHOULD process the Credit-Control-Request as if it was received in server SHOULD process the Credit-Control-Request as if it was
answer to the server initiated credit re-authorization, and should received in answer to the server-initiated credit re-authorization
consider the server initiated credit re-authorization process and should consider the server-initiated credit re-authorization
successful upon reception of the Re-Auth-Answer message. process successful upon reception of the RAA message.
When multiple services are supported in a user's session, the server When multiple services are supported in a user's session, the server
may request credit re-authorization for a credit pool (or for the may request credit re-authorization for a credit pool (or for the
(sub-)session) while a credit re-authorization is already ongoing for (sub-)session) while a credit re-authorization is already ongoing for
some of the services or rating-groups. In this case, the client some of the services or rating-groups. In this case, the client
acknowledges the server request with an RAA message and MUST send a acknowledges the server request with an RAA message and MUST send a
new Credit-Control-Request message to perform re-authorization for new Credit-Control-Request message to perform re-authorization for
the remaining services/rating-groups. The Result-Code 2002 the remaining services/rating-groups. The Result-Code 2002
(DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to
indicate that an additional message (i.e., CCR message with value indicate that an additional message (i.e., a CCR message with the
UPDATE_REQUEST) is required to complete the procedure. The server value UPDATE_REQUEST) is required to complete the procedure. The
processes the received requests and returns an appropriate answer to server processes the received requests and returns an appropriate
both requests. answer to both requests.
The above-defined procedures are enabled for each of the possibly The above-defined procedures are enabled for each of the possibly
active Diameter credit-control sub-sessions. The server MAY request active Diameter Credit-Control sub-sessions. The server MAY request
re-authorization for an active sub-session by including the CC-Sub- re-authorization for an active sub-session by including the
Session-Id AVP in the RAR message in addition to the Session-Id AVP. CC-Sub-Session-Id AVP in the RAR message in addition to the
Session-Id AVP.
5.6. Graceful Service Termination 5.6. Graceful Service Termination
When the user's account runs out of money, the user may not be When the user's account runs out of money, the user may not be
allowed to compile additional chargeable events. However, the home allowed to compile additional chargeable events. However, the home
service provider may offer some services; for instance, access to a service provider may offer some services -- for instance, access to a
service portal where it is possible to refill the account, for which service portal where it is possible to refill the account -- from
the user is allowed to benefit for a limited time. The length of which the user is allowed to benefit for a limited time. The length
this time is usually dependent on the home service provider policy. of this time is usually dependent on the home service provider
policy.
This section defines the optional graceful service termination This section defines the optional graceful service termination
feature that MAY be supported by the credit-control server. Credit- feature. This feature MAY be supported by the credit-control server.
control client implementations MUST support the Final-Unit-Indication Credit-control client implementations MUST support the Final-Unit-
AVP or QoS-Final-Unit-Indication AVP with at least the teardown of Indication AVP or QoS-Final-Unit-Indication AVP with at least the
the ongoing service session once the subscriber has consumed all the teardown of the ongoing service session once the subscriber has
final granted units. consumed all the final granted units.
Where independent credit-control of multiple services in a single Where independent credit-control of multiple services in a single
credit-control (sub-)session is supported, it is possible to use the credit-control (sub-)session is supported, it is possible to use
graceful service termination for each of the services/rating-groups graceful service termination for each of the services/rating-groups
independently. Naturally, the graceful service termination process independently. Naturally, the graceful service termination process
defined in the following sub-sections will apply to the specific defined in the following subsections will apply to the specific
service/rating-group as requested by the server. service/rating-group as requested by the server.
In some service environments (e.g., NAS), the graceful service In some service environments (e.g., NAS), graceful service
termination may be used to redirect the subscriber to a service termination may be used to redirect the subscriber to a service
portal for online balance refill or other services offered by the portal for online balance refill or other services offered by the
home service provider. In this case, the graceful termination home service provider. In this case, the graceful service
process installs a set of packet filters to restrict the user's termination process installs a set of packet filters to restrict the
access capability only to/from the specified destinations. All the user's access capability only to/from the specified destinations.
IP packets not matching the filters will be dropped or, possibly, re- All the IP packets not matching the filters will be dropped or,
directed to the service portal. The user may also be sent an possibly, redirected to the service portal. The user may also be
appropriate notification as to why the access has been limited. sent an appropriate notification as to why the access has been
These actions may be communicated explicitly from the server to the limited. These actions may be communicated explicitly from the
client or may be configured per-service at the client. Explicitly server to the client or may be configured "per service" at the
signaled redirect or restrict instructions always take precedence client. Explicitly signaled redirection or restriction instructions
over configured ones. always take precedence over configured ones.
It is also possible use the graceful service termination to connect It is also possible to use graceful service termination to connect
the prepaid user to a top-up server that plays an announcement and the prepaid user to a top-up server that plays an announcement and
prompts the user to replenish the account. In this case, the credit- prompts the user to replenish the account. In this case, the
control server sends only the address of the top-up server where the credit-control server sends only the address of the top-up server
prepaid user shall be connected after the final granted units have where the prepaid user shall be connected after the final granted
been consumed. An example of this is given Appendix B.7. units have been consumed. An example of this case is given in
Appendix A.7.
The credit-control server MAY initiate the graceful service The credit-control server MAY initiate graceful service termination
termination by including the Final-Unit-Indication AVP or the QoS- by including the Final-Unit-Indication AVP or the
Final-Unit-Indication AVP in the Credit-Control-Answer to indicate QoS-Final-Unit-Indication AVP in the Credit-Control-Answer to
that the message contains the final units for the service. indicate that the message contains the final units for the service.
When the credit-control client receives the Final-Unit-Indication AVP When the credit-control client receives the Final-Unit-Indication AVP
or the QoS-Final-Unit-Indication AVP in the answer from the server, or the QoS-Final-Unit-Indication AVP in the answer from the server,
its behavior depends on the value indicated in the Final-Unit-Action its behavior depends on the value indicated in the Final-Unit-Action
AVP. The server may request the following actions: TERMINATE, AVP. The server may request the following actions: TERMINATE,
REDIRECT, or RESTRICT_ACCESS. REDIRECT, or RESTRICT_ACCESS.
The following figure illustrates the graceful service termination Figure 6 illustrates the graceful service termination procedure
procedure described in the following sub-sections. described in the following subsections.
Diameter Diameter
End User Service Element AAA Server CC Server End User Service Element AAA Server CC Server
(CC Client) (CC Client)
| Service Delivery | | | | Service Delivery | | |
|<----------------->| | | |<----------------->| | |
| |CCR(Update,Used-Units) | | |CCR(Update, Used-Units) |
| |------------------->|CCR(Update,Used-Units) | |-------------------->|CCR(Update, Used-Units)
| : | |------------------->| | : | |-------------------->|
| : | |CCA(Final-Unit,Action) | : | |CCA(Final-Unit, Action)
| : | |<-------------------| | : | |<--------------------|
| |CCA(Final-Unit,Action) | | |CCA(Final-Unit, Action) |
| |<-------------------| | | |<--------------------| |
| | | | | | | |
| : | | | | : | | |
| : | | | | : | | |
| : | | | | /////////////// |CCR(Update, Used-Units) |
| /////////////// |CCR(Update,Used-Units) | |/Final Units End/->|-------------------->|CCR(Update, Used-Units)
|/Final Units End/->|------------------->|CCR(Update,Used-Units) |/Action and // | |-------------------->|
|/Action and // | |------------------->| |/Restrictions // | | CCA(Validity-Time)|
|/Restrictions // | | CCA(Validity-Time)| |/Start // | CCA(Validity-Time)|<--------------------|
|/Start // | CCA(Validity-Time)|<-------------------| | ///////////// |<--------------------| |
| ///////////// |<-------------------| | | : | | |
| : | | | | : | | |
| : | | | | Replenish account | +-------+ |
| Replenish Account +-------+ | |<--------------------------------------------->|Account| |
|<-------------------------------------------->|Account| | | | | +-------+ |
| | | +-------+ | | | | RAR |
| | | RAR | | + | RAR |<====================|
| + | RAR |<===================| | | |<====================| |
| | |<===================| | | | | RAA | |
| | | RAA | | | ///////////// | |====================>| RAA |
| ///////////// | |===================>| RAA | | /If supported / | | CCR(Update) |====================>|
| /If supported / | | CCR(Update) |===================>| | /by CC Server/ | |====================>| CCR(Update) |
| /by CC Server/ | |===================>| CCR(Update) | | ///////////// | | |====================>|
| ///////////// | | |===================>| | | | | CCA(Granted-Units)|
| | | | CCA(Granted-Unit)| | | | CCA(Granted-Units)|<====================|
| | | CCA(Granted-Unit)|<===================| | Restrictions ->+ |<====================| |
| Restrictions ->+ |<===================| | | removed | | |
| removed | | | | : | | |
| : | | | | OR | CCR(Update) | |
| OR | CCR(Update) | | | Validity-Time ->|-------------------->| CCR(Update) |
| Validity-Time ->|------------------->| CCR(Update) | | expires | |-------------------->|
| expires | |------------------->| | | | CCA(Granted-Units)|
| | | CCA(Granted-Unit)| | | CCA(Granted-Units)|<--------------------|
| | CCA(Granted-Unit)|<-------------------| | Restrictions ->|<--------------------| |
| Restrictions ->|<-------------------| | | removed | | |
| removed | | |
Figure 6: Optional graceful service termination procedure
In addition, the credit-control server MAY reply with Final-Unit- Figure 6: Optional Graceful Service Termination Procedure
Indication AVP or QoS-Final-Unit-Indication AVP holding a G-S-U AVP
with a zero grant, indicating that the service SHOULD be terminated
immediately, and no further reporting is required. A following
figure illustrates a graceful service termination procedure that
applies immediately after receiving a zero grant.
Diameter In addition, the credit-control server MAY reply with the Final-Unit-
End User Service Element AAA Server CC Server Indication AVP or QoS-Final-Unit-Indication AVP holding a Granted-
Service-Unit (G-S-U) with a zero grant, indicating that the service
SHOULD be terminated immediately, and no further reporting is
required. Figure 7 illustrates a graceful service termination
procedure that applies immediately after receiving a zero grant.
Diameter
End User Service Element AAA Server CC Server
(CC Client) (CC Client)
| Service Delivery | | | | Service Delivery | | |
|<----------------->| | | |<----------------->| | |
| |CCR(Update,Used-Units) | | |CCR(Update, Used-Units) |
| |------------------->|CCR(Update,Used-Units) | |--------------------->|CCR(Update, Used-Units)
| : | |------------------->| | : | |-------------------->|
| : | |CCA(Final-Unit,Action, | : | |CCA(Final-Unit, Action,
| : | | Zero G-S-U) | : | | Zero G-S-U)
| : | |<-------------------| | : | |<--------------------|
| |CCA(Final-Unit,Action, | | |CCA(Final-Unit, Action, |
| | Zero G-S-U) | | | Zero G-S-U) |
| |<-------------------| | | |<---------------------| |
| /////////////// | | | | /////////////// | | |
|/Action and // | | | |/Action and // | | |
|/Restrictions // | | | |/Restrictions // | | |
|/Start // | | | |/Start // | | |
| ///////////// | | | | ///////////// | | |
| : | | | | : | | |
| : | | | | : | | |
Figure 7: Optional immediate graceful service termination procedure Figure 7: Optional Immediate Graceful Service Termination Procedure
5.6.1. Terminate Action 5.6.1. Terminate Action
The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP
with Final-Unit-Action TERMINATE does not include any other with Final-Unit-Action set to TERMINATE does not include any other
information. When the subscriber has consumed the final granted information. When the subscriber has consumed the final granted
units, the service element MUST terminate the service. This is the units, the Service Element MUST terminate the service. This is the
default handling applicable whenever the credit-control client default handling applicable whenever the credit-control client
receives an unsupported Final-Unit-Action value and MUST be supported receives an unsupported Final-Unit-Action value and MUST be supported
by all the Diameter credit-control client implementations conforming by all the Diameter Credit-Control client implementations conforming
to this specification. A final Credit-Control-Request message to the to this specification. A final Credit-Control-Request message to the
credit-control server MUST be sent if the Final-Unit-Indication AVP credit-control server MUST be sent if the Final-Unit-Indication AVP
or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was
present at command level. The CC-Request-Type AVP in the request is present at the command level. The CC-Request-Type AVP in the request
set to the value TERMINATION_REQUEST. is set to the value TERMINATION_REQUEST.
5.6.2. Redirect Action 5.6.2. Redirect Action
The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP
with Final-Unit-Action REDIRECT indicates to the service element with Final-Unit-Action set to REDIRECT indicates to the Service
supporting this action that, upon consumption of the final granted Element supporting this action that, upon consumption of the final
units, the user MUST be re-directed to the address specified in the granted units, the user MUST be redirected to the address specified
Redirect-Server AVP or Redirect-Server-Extension AVP as follows. in the Redirect-Server AVP or Redirect-Server-Extension AVP as
follows.
The credit-control server sends the Redirect-Server AVP or Redirect- The credit-control server sends the Redirect-Server AVP or Redirect-
Server-Extension AVP in the Credit-Control-Answer message. In such a Server-Extension AVP in the Credit-Control-Answer message. In such a
case, the service element MUST redirect or connect the user to the case, the Service Element MUST redirect or connect the user to the
destination specified in the Redirect-Server AVP or Redirect-Server- destination specified in the Redirect-Server AVP or Redirect-Server-
Extension AVP, if possible. When the end user is redirected (by Extension AVP, if possible. When the end user is redirected (by
using protocols others than Diameter) to the specified server or using protocols other than Diameter) to the specified server or
connected to the top-up server, an additional authorization (and connected to the top-up server, an additional authorization (and
possibly authentication) may be needed before the subscriber can possibly authentication) may be needed before the subscriber can
replenish the account; however, this is out of the scope of this replenish the account; however, this scenario is out of scope for
specification. this specification.
In addition to the Redirect-Server AVP or Redirect-Server-Extension In addition to the Redirect-Server AVP or Redirect-Server-Extension
AVP, the credit-control server MAY include one or more Restriction- AVP, the credit-control server MAY include one or more Restriction-
Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more
Filter-Id AVPs in the Credit-Control-Answer message to enable the Filter-Id AVPs in the Credit-Control-Answer message to enable the
user to access other services (for example, zero-rated services). In user to access other services (for example, zero-rated services). In
such a case, the access device MUST treat all packets according to such a case, the access device MUST treat all packets according to
the Restriction-Filter-Rule AVPs, Filter-Rules AVPs and the rules the Restriction-Filter-Rule AVPs, Filter-Rule AVPs, and the rules
referred to by the Filter-Id AVP. After treatment is applied referred to by the Filter-Id AVP. After treatment is applied
according to these rules, all traffic that has not been dropped or according to these rules, all traffic that has not been dropped or
already forwarded MUST be redirected to the destination specified in already forwarded MUST be redirected to the destination specified in
the Redirect-Server AVP or Redirect-Server-Extension AVP. the Redirect-Server AVP or Redirect-Server-Extension AVP.
An entity other than the credit-control server may provision the An entity other than the credit-control server may provision the
access device with appropriate IP packet filters to be used in access device with appropriate IP packet filters to be used in
conjunction with the Diameter credit-control application. This case conjunction with the Diameter Credit-Control application. This case
is considered in Section 5.6.3. is considered in Section 5.6.3.
When the final granted units have been consumed, the credit-control When the final granted units have been consumed, the credit-control
client MUST perform an intermediate interrogation. The purpose of client MUST perform an intermediate interrogation. The purpose of
this interrogation is to indicate to the credit-control server that this interrogation is to indicate to the credit-control server that
the specified action started and to report the used units. The the specified action started and to report the used units. The
credit-control server MUST deduct the used amount from the end user's credit-control server MUST deduct the used amount from the end user's
account but MUST NOT make a new credit reservation. The credit- account but MUST NOT make a new credit reservation. The
control client, however, may send intermediate interrogations before credit-control client, however, may send intermediate interrogations
all the final granted units have been consumed for which rating and before all the final granted units have been consumed for which
money reservation may be needed; for instance, upon Validity-Time rating and money reservation may be needed -- for instance, upon
expires or upon mid-session service events that affect the rating of Validity-Time expiration or upon mid-session service events that
the current service. Therefore, the credit-control client MUST NOT affect the rating of the current service. Therefore, the
include any rating related AVP in the request sent once all the final credit-control client MUST NOT include any rating-related AVPs in the
granted units have been consumed as an indication to the server that request sent once all the final granted units have been consumed, as
the requested final unit action started, rating and money reservation an indication to the server that (1) the requested final unit action
are not required (when the Multiple-Services-Credit-Control AVP is started and (2) rating and money reservation are not required (when
used, the Service-Identifier or Rating-Group AVPs is included to the Multiple-Services-Credit-Control AVP is used, the Service-
indicate the concerned services). Naturally, the Credit-Control- Identifier AVP or the Rating-Group AVP is included to indicate the
Answer message does not contain any granted service unit and MUST services concerned). Naturally, the Credit-Control-Answer message
include the Validity-Time AVP to indicate to the credit-control does not contain any granted service units and MUST include the
client how long the subscriber is allowed to use network resources Validity-Time AVP to indicate to the credit-control client how long
before a new intermediate interrogation is sent to the server. the subscriber is allowed to use network resources before a new
intermediate interrogation is sent to the server.
At the expiry of Validity-Time, the credit-control client sends a At the expiry of Validity-Time, the credit-control client sends a
Credit-Control-Request (UPDATE_REQUEST) as usual. This message does Credit-Control-Request (UPDATE_REQUEST) as usual. This message does
not include the Used-Service-Unit AVP, as there is no allotted quota not include the Used-Service-Unit AVP, as there is no allotted quota
to report. The credit-control server processes the request and MUST to report. The credit-control server processes the request and MUST
perform the credit reservation. If during this time the subscriber perform the credit reservation. If during this time the subscriber
did not replenish his/her account, whether he/she will be did not replenish their account, whether they will be disconnected or
disconnected or will be granted access to services not controlled by will be granted access to services not controlled by a credit-control
a credit-control server for an unlimited time is dependent on the server for an unlimited time is dependent on the home service
home service provider policy (note: the latter option implies that provider policy. (Note: The latter option implies that the Service
the service element should not remove the restriction filters upon Element should not remove the restriction filters upon termination of
termination of the credit-control). The server will return the the credit-control.) The server will return the appropriate
appropriate Result-Code (see Section 9.1) in the Credit-Control- Result-Code (see Section 9.1) in the Credit-Control-Answer message in
Answer message in order to implement the policy-defined action. order to implement the policy-defined action. Otherwise, a new quota
Otherwise, new quota will be returned, the service element MUST will be returned, and the Service Element MUST remove all the
remove all the possible restrictions activated by the graceful possible restrictions activated by the graceful service termination
service termination process and continue the credit-control session process and continue the credit-control session and service session
and service session as usual. as usual.
The credit-control client may not wait until the expiration of the The credit-control client may not wait until the expiration of the
Validity-Time and may send a spontaneous update (a new Credit- Validity-Time and may send a spontaneous update (a new
Control-Request) if the service element can determine, for instance, Credit-Control-Request) if the Service Element can determine, for
that communication between the end user and the top-up server took instance, that communication between the end user and the top-up
place. An example of this is given in Appendix B.8 (Figure 18). server took place. An example of this case is given in Appendix A.8
(Figure 18).
Note that the credit-control server may already have initiated the Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. When the credit- replenish the account and continue the service. When the
control client receives (either at session or service-specific level) credit-control client receives (at either the session level or a
a Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP, service-specific level) a Final-Unit-Indication AVP or QoS-Final-
together with Validity-Time AVPs, but without Granted-Service-Unit Unit-Indication AVP, together with Validity-Time AVPs, but without a
AVP, it immediately starts the graceful service termination without Granted-Service-Unit AVP, it immediately starts the graceful service
sending any message to the server. An example of this case is termination process without sending any messages to the server. An
illustrated in Appendix B. example of this case is illustrated in Appendix A.8 (Figure 18).
5.6.3. Restrict Access Action 5.6.3. Restrict Access Action
A Final-Unit-Indication AVP with the Final-Unit-Action A Final-Unit-Indication AVP with Final-Unit-Action set to
RESTRICT_ACCESS indicates to the device supporting this action that, RESTRICT_ACCESS indicates to the device supporting this action that,
upon consumption of the final granted units, the user's access MUST upon consumption of the final granted units, the user's access MUST
be restricted according to the IP packet filters given in the be restricted according to the IP packet filters given in the
Restriction-Filter-Rule AVP(s) or according to the IP packet filters Restriction-Filter-Rule AVP(s) or according to the IP packet filters
identified by the Filter-Id AVP(s). The credit-control server SHOULD identified by the Filter-Id AVP(s). The credit-control server SHOULD
include either the Restriction-Filter-Rule AVP or the Filter-Id AVP include either the Restriction-Filter-Rule AVP or the Filter-Id AVP
in the Final-Unit-Indication group AVP of the Credit-Control-Answer in the Final-Unit-Indication group AVP of the Credit-Control-Answer
message. message.
A QoS-Final-Unit-Indication AVP with the Final-Unit-Action A QoS-Final-Unit-Indication AVP with Final-Unit-Action set to
RESTRICT_ACCESS indicates to the device supporting this action that, RESTRICT_ACCESS indicates to the device supporting this action that,
upon consumption of the final granted units, the actions specified in upon consumption of the final granted units, the actions specified in
Filter-Rule AVP(s) MUST restrict the traffic according to the Filter-Rule AVP(s) MUST restrict the traffic according to the
classifiers in the Filter-Rule AVP(s). If Filter-Id AVP(s) are classifiers in the Filter-Rule AVP(s). If one or more Filter-Id AVPs
provided in the Credit-Control-Answer message, the credit-control are provided in the Credit-Control-Answer message, the credit-control
client MUST restrict the traffic according to the IP packet filters client MUST restrict the traffic according to the IP packet filters
identified by the Filter-Id AVP(s). The credit-control server SHOULD identified by the Filter-Id AVP(s). The credit-control server SHOULD
include either the Filter-Rule AVP or the Filter-Id AVP in the QoS- include either the Filter-Rule AVP or the Filter-Id AVP in the
Final-Unit-Indication group AVP of the Credit-Control-Answer message. QoS-Final-Unit-Indication group AVP of the Credit-Control-Answer
message.
If both Final-Unit-Indication AVP and QoS-Final-Unit-Indication AVP If both the Final-Unit-Indication AVP and the QoS-Final-Unit-
exist in the Credit-Control-Answer message, a credit-control client Indication AVP exist in the Credit-Control-Answer message, a
which supports the QoS-Final-Unit-Indication AVP SHOULD follow the credit-control client that supports the QoS-Final-Unit-Indication AVP
directives included in the QoS-Final-Unit-Indication AVP and SHOULD SHOULD follow the directives included in the QoS-Final-Unit-
ignore the Final-Unit-Indication AVP. Indication AVP and SHOULD ignore the Final-Unit-Indication AVP.
An entity other than the credit-control server may provision the An entity other than the credit-control server may provision the
access device with appropriate IP packet filters to be used in access device with appropriate IP packet filters to be used in
conjunction with the Diameter credit-control application. Such an conjunction with the Diameter Credit-Control application. Such an
entity may, for instance, configure the access device with IP flows entity may, for instance, configure the access device with IP flows
to be passed when the Diameter credit-control application indicates to be passed when the Diameter Credit-Control application indicates
RESTRICT_ACCESS or REDIRECT. The access device passes IP packets RESTRICT_ACCESS or REDIRECT. The access device passes IP packets
according to the filter rules that may have been received in the according to the filter rules that may have been received in the
Credit-Control-Answer message in addition to those that may have been Credit-Control-Answer message, in addition to those rules that may
configured by the other entity. However, when the user's account have been configured by the other entity. However, when the user's
cannot cover the cost of the requested service, the action taken is account cannot cover the cost of the requested service, the action
the responsibility of the credit-control server that controls the taken is the responsibility of the credit-control server that
prepaid subscriber. controls the prepaid subscriber.
If another entity working in conjunction with the Diameter credit- If another entity working in conjunction with the Diameter
control application already provisions the access device with all the Credit-Control application already provisions the access device with
required filter rules for the end user, the credit-control server all the required filter rules for the end user, the credit-control
presumably need not send any additional filter. Therefore, it is server presumably need not send any additional filters. Therefore,
RECOMMENDED that credit-control server implementations supporting the it is RECOMMENDED that credit-control server implementations
graceful service termination be configurable for sending the supporting graceful service termination be configurable for sending
Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, the Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id
or none of the above. AVP, or none of the above.
When the final granted units have been consumed, the credit-control When the final granted units have been consumed, the credit-control
client MUST perform an intermediate interrogation. The credit- client MUST perform an intermediate interrogation. The
control client and the credit-control server process this credit-control client and the credit-control server process this
intermediate interrogation and execute subsequent procedures, as intermediate interrogation and execute subsequent procedures, as
specified in the previous section for the REDIRECT action. specified in Section 5.6.2.
The credit-control server may initiate the graceful service The credit-control server may initiate graceful service termination
termination with action RESTRICT_ACCESS already for the first when replying with the action RESTRICT_ACCESS for the first
interrogation, as specified in the previous section for the REDIRECT interrogation. This is similar to the behavior specified in
action. Section 5.6.2.
5.6.4. Usage of the Server-Initiated Credit Re-Authorization 5.6.4. Usage of the Server-Initiated Credit Re-authorization
Once the subscriber replenishes the account, she presumably expects Once the subscriber replenishes the account, they presumably expect
all the restrictions placed by the graceful termination procedure to all the restrictions applied by the graceful service termination
be removed immediately and unlimited service access to be resumed. procedure to be removed immediately and unlimited service access to
For the best user experience, the credit-control server be resumed. For the best user experience, the credit-control server
implementation MAY support the server-initiated credit re- implementation MAY support the server-initiated credit
authorization (see Section 5.5). In such a case, upon the successful re-authorization (see Section 5.5). In such a case, upon the
account top-up, the credit-control server sends the Re-Auth-Request successful account top-up, the credit-control server sends the
(RAR) message to solicit the credit re-authorization. The credit- Re-Auth-Request (RAR) message to solicit the credit re-authorization.
control client initiates the credit re-authorization by sending the The credit-control client initiates the credit re-authorization by
Credit-Control-Request message with the CC-Request-Type AVP set to sending the Credit-Control-Request message with the CC-Request-Type
the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included AVP set to the value UPDATE_REQUEST. The Used-Service-Unit AVP is
in the request, as there is no allotted quota to report. The not included in the request, as there is no allotted quota to report.
Requested-Service-Unit AVP MAY be included in the request. After the The Requested-Service-Unit AVP MAY be included in the request. After
credit-control client successfully receives the Credit-Control-Answer the credit-control client successfully receives the Credit-Control-
with new Granted-Service-Unit, all the possible restrictions Answer with a new Granted-Service-Unit AVP, all the possible
activated for the purpose of the graceful service termination MUST be restrictions activated for the purpose of graceful service
removed in the service element. The credit-control session and the termination MUST be removed in the Service Element. The
service session continue as usual. credit-control session and the service session continue as usual.
5.7. Failure Procedures 5.7. Failure Procedures
The Credit-Control-Failure-Handling AVP (CCFH), as described in this The CCFH, as described in this section, determines the behavior of
section, determines the behavior of the credit-control client in the credit-control client in fault situations. The CCFH may be
fault situations. The CCFH may be received from the Diameter home (1) received from the Diameter home AAA server, (2) received from the
AAA server, from the credit-control server, or may be configured credit-control server, or (3) configured locally. The CCFH value
locally. The CCFH value received from the home AAA server overrides received from the home AAA server overrides the locally configured
the locally configured value. The CCFH value received from the value. The CCFH value received from the credit-control server in the
credit-control server in the Credit-Control-Answer message always Credit-Control-Answer message always overrides any existing values.
overrides any existing value.
The authorization server MAY include the Accounting-Realtime-Required The authorization server MAY include the Accounting-Realtime-Required
AVP to determine what to do if the sending of accounting records to AVP to determine what to do if the sending of accounting records to
the accounting server has been temporarily prevented, as defined in the accounting server has been temporarily prevented, as defined in
[RFC6733]. It is RECOMMENDED that the client complement the credit- [RFC6733]. It is RECOMMENDED that the client complement the
control failure procedures with a backup accounting flow toward an credit-control failure procedures with a backup accounting flow
accounting server. By using different combinations of Accounting- toward an accounting server. By using different combinations of the
Realtime-Required and Credit-Control-Failure-Handling AVPs, different Accounting-Realtime-Required AVP and the CCFH, different safety
safety levels can be built. For example, by choosing a Credit- levels can be built. For example, by choosing a CCFH equal to
Control-Failure-Handling AVP equal to CONTINUE for the credit-control CONTINUE for the credit-control flow and an Accounting-Realtime-
flow and an Accounting-Realtime-Required AVP equal to Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the
DELIVER_AND_GRANT for the accounting flow, the service can be granted service can be granted to the end user even if the connection to the
to the end user even if the connection to the credit-control server credit-control server is down, as long as the accounting server is
is down, as long as the accounting server is able to collect the able to collect the accounting information and information exchange
accounting information and information exchange is taking place is taking place between the accounting server and credit-control
between the accounting server and credit-control server. server.
As the credit-control application is based on real-time bi- As the credit-control application is based on real-time bidirectional
directional communication between the credit-control client and the communication between the credit-control client and the
credit-control server, the usage of alternative destinations and the credit-control server, the usage of alternative destinations and the
buffering of messages may not be sufficient in the event of buffering of messages may not be sufficient in the event of
communication failures. Because the credit-control server has to communication failures. Because the credit-control server has to
maintain session states, moving the credit-control message stream to maintain session states, moving the credit-control message stream to
a backup server requires a complex context transfer solution. a backup server requires a complex context transfer solution.
Whether the credit-control message stream is moved to a backup Whether the credit-control message stream is moved to a backup
credit-control server during an ongoing credit-control session credit-control server during an ongoing credit-control session
depends on the value of the CC-Session-Failover AVP. However, depends on the value of the CC-Session-Failover AVP. However,
failover may occur at any point in the path between the credit- failover may occur at any point in the path between the
control client and the credit-control server if a transport failure credit-control client and the credit-control server if a transport
is detected with a peer, as described in [RFC6733]. As a failure is detected with a peer, as described in [RFC6733]. As a
consequence, the credit-control server might receive duplicate consequence, the credit-control server might receive duplicate
messages. These duplicates or out of sequence messages can be messages. These duplicate or out-of-sequence messages can be
detected in the credit-control server based on the credit-control detected in the credit-control server based on the credit-control
server session state machine (Section 7), Session-Id AVP, and CC- server session state machine (Section 7), Session-Id AVP, and
Request-Number AVP. CC-Request-Number AVP.
If a failure occurs during an ongoing credit-control session, the If a failure occurs during an ongoing credit-control session, the
credit-control client may move the credit-control message stream to credit-control client may move the credit-control message stream to
an alternative server if the CC-server indicated FAILOVER_SUPPORTED an alternative server if the credit-control server indicated
in the CC-Session-Failover AVP. A secondary credit-control server FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary
name, either received from the home Diameter AAA server or configured credit-control server name, either received from the home Diameter
locally, can be used as an address of the backup server. If the CC- AAA server or configured locally, can be used as an address of the
Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- backup server. If the CC-Session-Failover AVP is set to
control message stream MUST NOT be moved to a backup server. FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be
moved to a backup server.
For new credit-control sessions, failover to an alternative credit- For new credit-control sessions, failover to an alternative
control server SHOULD be performed if possible. For instance, if an credit-control server SHOULD be performed, if possible. For
implementation of the credit-control client can determine primary instance, if an implementation of the credit-control client can
credit-control server unavailability, it can establish the new determine primary credit-control server unavailability, it can
credit-control sessions with a possibly available secondary credit- establish the new credit-control sessions with a possibly available
control server. secondary credit-control server.
The AAA transport profile [RFC3539] defines an application layer The AAA transport profile [RFC3539] defines an application-layer
watchdog algorithm that enables failover from a peer that has failed watchdog algorithm that enables failover from a peer that has failed
and is controlled by a watchdog timer (Tw) defined in [RFC3539]. The and is controlled by a watchdog timer (Tw) (defined in [RFC3539]).
recommended default initial value for Tw (Twinit) is 30 seconds. The recommended default initial value for Tw (Twinit) is 30 seconds.
Twinit may be set as low as 6 seconds; however, according to Twinit may be set as low as 6 seconds; however, according to
[RFC3539], setting too low a value for Twinit is likely to result in [RFC3539], setting too low a value for Twinit is likely to result in
an increased probability of duplicates, as well as an increase in an increased probability of duplicates, as well as an increase in
spurious failover and failback attempts. The Diameter base protocol spurious failover and failback attempts. The Diameter base protocol
[RFC6733] is common to several different types of Diameter AAA [RFC6733] is common to several different types of Diameter AAA
applications that may be run in the same service element. Therefore, applications that may be run in the same Service Element. Therefore,
tuning the timer Twinit to a lower value in order to satisfy the tuning the timer for Twinit to a lower value in order to satisfy the
requirements of real-time applications, such as the Diameter credit- requirements of real-time applications, such as the Diameter
control application, will certainly cause the above mentioned Credit-Control application, will certainly cause the above-mentioned
problems. For prepaid services, however, the end user expects an problems. For prepaid services, however, the end user expects an
answer from the network in a reasonable time. Thus, the Diameter answer from the network in a reasonable time. Thus, the Diameter
credit-control client will react faster than would the underlying Credit-Control client will react more quickly than would the
base protocol. Therefore this specification defines the Tx timer underlying base protocol. Therefore, this specification defines the
that is used by the credit-control client (as defined in Section 13) Tx timer (as defined in Section 13), which is used by the
to supervise the communication with the credit-control server. When credit-control client to supervise communication with the
the Tx timer elapses, the credit-control client takes an action to credit-control server. When the Tx timer elapses, the credit-control
the end user according to the Credit-Control-Failure-Handling AVP. client takes action for the end user according to the CCFH.
When Tx timer expires, the Diameter credit-control client always When the Tx timer expires, the Diameter Credit-Control client always
terminates the service if the Credit-Control-Failure-Handling (CCFH) terminates the service if the CCFH is set to the value TERMINATE.
AVP is set to the value TERMINATE. The credit-control session may be The credit-control session may be moved to an alternative server only
moved to an alternative server only if a protocol error if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER
DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before Tx is received before the Tx timer expires. Therefore, the value
timer expires. Therefore, the value TERMINATE is not appropriate if TERMINATE is not appropriate if proper failover behavior is desired.
proper failover behavior is desired.
If the Credit-Control-Failure-Handling AVP is set to the value If the CCFH is set to the value CONTINUE or RETRY_AND_TERMINATE, the
CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the service will be granted to the end user when the Tx timer expires.
end user when the Tx timer expires. An answer message with granted An Answer message with granted units may arrive later if the base
units may arrive later if the base protocol transport failover protocol transport failover occurred in the path to the
occurred in the path to the credit-control server. (The Twinit credit-control server. (The Twinit default value is 3 times more
default value is 3 times more than the Tx timeout recommended value.) than the recommended Tx timeout value.) The credit-control client
The credit-control client SHOULD grant the service to the end user, SHOULD grant the service to the end user, start monitoring resource
start monitoring the resource usage, and wait for the possible late usage, and wait for the possible late answer until the timeout of the
answer until the timeout of the request (e.g., 120 seconds). If the request (e.g., 120 seconds). If the request fails and the
request fails and the CC-Session-Failover AVP is set to CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the
FAILOVER_NOT_SUPPORTED, the credit-control client terminates or credit-control client terminates or continues the service --
continues the service depending on the value set in the CCFH and MUST depending on the value set in the CCFH -- and MUST free all the
free all the reserved resources for the credit-control session. If reserved resources for the credit-control session. If the protocol
the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or
received or the request times out and the CC-Session-Failover AVP is the request times out and the CC-Session-Failover AVP is set to
set to FAILOVER_SUPPORTED, the credit-control client MAY send the FAILOVER_SUPPORTED, the credit-control client MAY send the request to
request to a backup server, if possible. If the credit-control a backup server, if possible. If the credit-control client receives
client receives a successful answer from the backup server, it a successful answer from the backup server, it continues the
continues the credit-control session with such a server. If the re- credit-control session with such a server. If the retransmitted
transmitted request also fails, the credit-control client terminates request also fails, the credit-control client terminates or continues
or continues the service depending on the value set in the CCFH and the service -- depending on the value set in the CCFH -- and MUST
MUST free all the reserved resources for the credit-control session. free all the reserved resources for the credit-control session.
If a communication failure occurs during the graceful service If a communication failure occurs during the graceful service
termination procedure, the service element SHOULD always terminate termination procedure, the Service Element SHOULD always terminate
the ongoing service session. the ongoing service session.
If the credit-control server detects a failure during an ongoing If the credit-control server detects a failure during an ongoing
credit-control session, it will terminate the credit-control session credit-control session, it will terminate the credit-control session
and return the reserved units back to the end user's account. and return the reserved units back to the end user's account.
The supervision session timer Tcc (as defined in Section 13) is used The supervision session timer Tcc (as defined in Section 13) is used
in the credit-control server to supervise the credit-control session. in the credit-control server to supervise the credit-control session.
In order to support failover between credit-control servers, In order to support failover between credit-control servers,
information transfer about the credit-control session and account information transfer about the credit-control session and account
state SHOULD take place between the primary and the secondary credit- state SHOULD take place between the primary and secondary
control server. Implementations supporting the credit-control credit-control servers. Implementations supporting credit-control
session failover MUST also ensure proper detection of duplicate or session failover MUST also ensure proper detection of duplicate or
out of sequence messages. The communication between the servers is out-of-sequence messages. Communication between the servers is
regarded as an implementation issue and is outside of the scope of regarded as an implementation issue and is outside the scope of this
this specification. specification.
6. One Time Event 6. One-Time Event
The one-time event is used when there is no need to maintain any The one-time event is used when there is no need to maintain any
state in the Diameter credit-control server; for example, enquiring state in the Diameter Credit-Control server -- for example, inquiring
about the price of the service. The use of a one-time event implies about the price of the service. The use of a one-time event implies
that the user has been authenticated and authorized beforehand. that the user has been authenticated and authorized beforehand.
The one-time event can be used when the credit-control client wants The one-time event can be used when the credit-control client wants
to know the cost of the service event or to check the account balance to know the cost of the service event or to check the account balance
without any credit-reservation. It can also be used for refunding without any credit reservations. It can also be used for refunding
service units on the user's account or for direct debiting without service units on the user's account or for direct debiting without
any credit-reservation. The one-time event is shown in Figure 8. any credit reservations. The one-time event is shown in Figure 8.
Diameter Diameter
End User Service Element AAA Server CC Server End User Service Element AAA Server CC Server
(CC Client) (CC Client)
| Service Request | | | | Service Request | | |
|------------------>| | | |------------------>| | |
| | CCR(Event) | | | | CCR(Event) | |
| |------------------->| CCR(Event) | | |------------------->| CCR(Event) |
| | |------------------->| | | |------------------->|
| | | CCA(Granted-Units)| | | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------| | | CCA(Granted-Units)|<-------------------|
| Service Delivery |<-------------------| | | Service Delivery |<-------------------| |
|<----------------->| | | |<----------------->| | |
Figure 8: One time event Figure 8: One-Time Event
In environments such as the 3GPP architecture, the one-time event can In environments such as the 3GPP architecture, the one-time event can
be sent from the service element directly to the credit-control be sent from the Service Element directly to the credit-control
server. server.
6.1. Service Price Enquiry 6.1. Service Price Inquiry
The credit-control client may need to know the price of the services The credit-control client may need to know the price of the service
event. Services offered by application service providers whose event. Services offered by application service providers whose
prices are not known in the credit-control client might exist. The prices are not known in the credit-control client might exist. The
end user might also want to get an estimation of the price of a end user might also want to get an estimate of the price of a service
service event before requesting it. event before requesting it.
A Diameter credit-control client requesting the cost information MUST A Diameter Credit-Control client requesting the cost information MUST
set the CC-Request-Type AVP equal to EVENT_REQUEST, include the set the CC-Request-Type AVP equal to EVENT_REQUEST, include the
Requested-Action AVP set to PRICE_ENQUIRY, and set the requested Requested-Action AVP set to PRICE_ENQUIRY, and set the requested
service event information into the Service-Identifier AVP in the service event information in the Service-Identifier AVP in the
Credit-Control-Request message. Additional service event information Credit-Control-Request message. Additional service event information
may be sent as service-specific AVPs or within the Service-Parameter- may be sent as service-specific AVPs or within the Service-Parameter-
Info AVP. The Service-Context-Id AVP indicates the service-specific Info AVP. The Service-Context-Id AVP indicates the service-specific
document applicable to the request. document applicable to the request.
The credit-control server calculates the cost of the requested The credit-control server calculates the cost of the requested
service event, but it does not perform any account balance check or service event, but it does not perform any account-balance checks or
credit-reservation from the account. credit reservations from the account.
The estimated cost of the requested service event is returned to the The estimated cost of the requested service event is returned to the
credit-control client in the Cost-Information AVP in the Credit- credit-control client in the Cost-Information AVP in the
Control-Answer message. Credit-Control-Answer message.
6.2. Balance Check 6.2. Balance Checks
The Diameter credit-control client may only have to verify that the The Diameter Credit-Control client may only have to verify that the
end user's account balance covers the cost of a certain service end user's account balance covers the cost of a certain service
without reserving any units from the account at the time of the without reserving any units from the account at the time of the
inquiry. This method does not guarantee that credit would be left inquiry. This method does not guarantee that credit would be left
when the Diameter credit-control client requests the debiting of the when the Diameter Credit-Control client requests the debiting of the
account with a separate request. account with a separate request.
A Diameter credit-control client requesting the balance check MUST A Diameter Credit-Control client requesting a balance check MUST set
set the CC-Request-Type AVP equal to EVENT_REQUEST, include a the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested-
Requested-Action AVP set to CHECK_BALANCE, and include the Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP
Subscription-Id AVP or Subscription-Id-Extension AVP in order to or Subscription-Id-Extension AVP in order to identify the end user in
identify the end user in the credit-control server. The Service- the credit-control server. The Service-Context-Id AVP indicates the
Context-Id AVP indicates the service-specific document applicable to service-specific document applicable to the request.
the request.
The credit-control server makes the balance check, but it does not The credit-control server makes the balance check, but it does not
make any credit-reservation from the account. make any credit reservations from the account.
The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to The result of the balance check (ENOUGH_CREDIT/NO_CREDIT) is returned
the credit-control client in the Check-Balance-Result AVP in the to the credit-control client in the Check-Balance-Result AVP in the
Credit-Control-Answer message. Credit-Control-Answer message.
6.3. Direct Debiting 6.3. Direct Debiting
There are certain service events for which service execution is There are certain service events for which service execution is
always successful in the service environment. The delay between the always successful in the service environment. The delay between the
service invocation and the actual service delivery to the end user service invocation and the actual service delivery to the end user
can be sufficiently long that the use of the session-based credit- can be sufficiently long that the use of session-based credit-control
control would lead to unreasonably long credit-control sessions. In would lead to unreasonably long credit-control sessions. In these
these cases, the Diameter credit-control client can use the one-time cases, the Diameter Credit-Control client can use the one-time event
event scenario for direct debiting. The Diameter credit-control scenario for direct debiting. The Diameter Credit-Control client
client SHOULD be sure that the requested service event execution SHOULD be sure that the requested service event execution would be
would be successful when this scenario is used. successful when this scenario is used.
In the Credit-Control-Request message, the CC-Request-Type is set to In the Credit-Control-Request message, the CC-Request-Type AVP is set
the value EVENT_REQUEST and the Requested-Action AVP is set to to the value EVENT_REQUEST and the Requested-Action AVP is set to
DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id- DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id-
Extension AVP SHOULD be included to identify the end user in the Extension AVP SHOULD be included to identify the end user in the
credit-control server. The Event-Timestamp AVP SHOULD be included in credit-control server. The Event-Timestamp AVP SHOULD be included in
the request and contain the time when the service event is requested the request and contain the time when the service event is requested
in the service element. The Service-Context-Id AVP indicates the in the Service Element. The Service-Context-Id AVP indicates the
service-specific document applicable to the request. service-specific document applicable to the request.
The Diameter credit-control client MAY include the monetary amount to If it knows the cost of the service event, the Diameter
be charged in the Requested-Service-Unit AVP, if it knows the cost of Credit-Control client MAY include in the Requested-Service-Unit AVP
the service event. If the Diameter credit-control client does not the monetary amount to be charged. If the Diameter Credit-Control
know the cost of the service event, the Requested-Service-Unit AVP client does not know the cost of the service event, the Requested-
MAY contain the number of requested service events. The Service- Service-Unit AVP MAY contain the number of requested service events.
Identifier AVP always indicates the service concerned. Additional The Service-Identifier AVP always indicates the service concerned.
service event information to be rated MAY be sent as service-specific Additional service event information to be rated MAY be sent as
AVPs or within the Service-Parameter-Info AVP. service-specific AVPs or within the Service-Parameter-Info AVP.
The credit-control server SHOULD rate the service event and deduct The credit-control server SHOULD rate the service event and deduct
the corresponding monetary amount from the end user's account. If the corresponding monetary amount from the end user's account. If
the type of the Requested-Service-Unit AVP is money, no rating is the type of the Requested-Service-Unit AVP is "money", no rating is
needed, but the corresponding monetary amount is deducted from the needed, but the corresponding monetary amount is deducted from the
end user's account. end user's account.
The credit-control server returns the Granted-Service-Unit AVP in the The credit-control server returns the Granted-Service-Unit AVP in the
Credit-Control-Answer message to the Diameter credit-control client. Credit-Control-Answer message to the Diameter Credit-Control client.
The Granted-Service-Unit AVP contains the amount of service units The Granted-Service-Unit AVP contains the amount of service units
that the Diameter credit-control client can provide to the end user. that the Diameter Credit-Control client can provide to the end user.
The type of the Granted-Service-Unit can be time, volume, service- The type of the Granted-Service-Unit can be time, volume, service-
specific, or money, depending on the type of service event. specific, or money, depending on the type of service event.
If the credit-control server determines that no credit-control is If the credit-control server determines that no credit-control is
needed for the service, it can include the result code indicating needed for the service, it can include the result code indicating
that the credit-control is not applicable (e.g., service is free of that the credit-control is not applicable (e.g., the service is free
charge). of charge).
For informative purposes, the Credit-Control-Answer message MAY also For informative purposes, the Credit-Control-Answer message MAY also
include the Cost-Information AVP containing the estimated total cost include the Cost-Information AVP containing the estimated total cost
of the requested service. of the requested service.
6.4. Refund 6.4. Refunds
Some services may refund service units to the end user's account; for Some services may refund service units to the end user's account --
example, gaming services. for example, gaming services.
The credit-control client MUST set CC-Request-Type to the value The credit-control client MUST set the CC-Request-Type AVP to the
EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in
Credit-Control-Request message. The Subscription-Id AVP or the Credit-Control-Request message. The Subscription-Id AVP or
Subscription-Id-Extension AVP SHOULD be included to identify the end Subscription-Id-Extension AVP SHOULD be included to identify the
user in the credit-control server. The Service-Context-Id AVP end user in the credit-control server. The Service-Context-Id AVP
indicates the service-specific document applicable to the request. indicates the service-specific document applicable to the request.
The Diameter credit-control client MAY include the monetary amount to The Diameter Credit-Control client MAY include the monetary amount to
be refunded in the Requested-Service-Unit AVP. The Service- be refunded in the Requested-Service-Unit AVP. The Service-
Identifier AVP always indicates the concerned service. If the Identifier AVP always indicates the service concerned. If the
Diameter credit-control client does not know the monetary amount to Diameter Credit-Control client does not know the monetary amount to
be refunded, in addition to the Service-Identifier AVP it MAY send be refunded, in addition to the Service-Identifier AVP it MAY send
service-specific AVPs or the Service-Parameter-Info AVP containing service-specific AVPs or the Service-Parameter-Info AVP containing
additional service event information to be rated. additional service event information to be rated.
For informative purposes, the Credit-Control-Answer message MAY also For informative purposes, the Credit-Control-Answer message MAY also
include the Cost-Information AVP containing the estimated monetary include the Cost-Information AVP containing the estimated monetary
amount of refunded unit. amount of refunded units.
6.5. Failure Procedure 6.5. Failure Procedure
Failover to an alternative credit-control server is allowed for a one Failover to an alternative credit-control server is allowed for a
time event, as the server is not maintaining session states. For one-time event, as the server is not maintaining session states. For
instance, if the credit-control client receives a protocol error instance, if the credit-control client receives a protocol error
DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can resend the
request to an alternative server, if possible. There MAY be protocol request to an alternative server, if possible. There MAY be
transparent Diameter relays and redirect agents or Diameter credit- protocol-transparent Diameter relays and redirect agents or Diameter
control proxies between the credit-control client and credit-control Credit-Control proxies between the credit-control client and
server. Failover may occur at any point in the path between the credit-control server. Failover may occur at any point in the path
credit-control client and the credit-control server if a transport between the credit-control client and the credit-control server if a
failure is detected with a peer, as described in [RFC6733]. Because transport failure is detected with a peer, as described in [RFC6733].
there can be duplicate requests for various reasons, the credit- Because there can be duplicate requests for various reasons, the
control server is responsible for real time duplicate detection. credit-control server is responsible for real-time duplicate
Implementation issues for duplicate detection are discussed in detection. Implementation issues for duplicate detection are
[RFC6733], Appendix C. discussed in [RFC6733], Appendix C.
When the credit-control client detects a communication failure with When the credit-control client detects a communication failure with
the credit-control server, its behavior depends on the requested the credit-control server, its behavior depends on the requested
action. The Tx timer (as defined in Section 13) is used in the action. The Tx timer (as defined in Section 13) is used in the
credit-control client to supervise the communication with the credit- credit-control client to supervise communication with the
control server. credit-control server.
If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a
communication failure is detected, the credit-control client SHOULD communication failure is detected, the credit-control client SHOULD
forward the request messages to an alternative credit-control server, forward the request messages to an alternative credit-control server,
if possible. The secondary credit-control server name, if received if possible. The secondary credit-control server name, if received
from the home Diameter AAA server, can be used as an address of from the home Diameter AAA server, can be used as an address of the
backup server. backup server.
If the requested action is DIRECT_DEBITING, the Direct-Debiting- If the requested action is DIRECT_DEBITING, the DDFH controls the
Failure-Handling AVP (DDFH) controls the credit-control client's credit-control client's behavior. The DDFH may be received from the
behavior. The DDFH may be received from the home Diameter AAA server home Diameter AAA server or may be locally configured. The
or may be locally configured. The credit-control server may also credit-control server may also send the DDFH in any CCA messages to
send the DDFH in any CCA message to be used for direct debiting be used for direct-debiting events compiled thereafter. The DDFH
events compiled thereafter. The DDFH value received from the home value received from the home Diameter AAA server overrides the
Diameter AAA server overrides the locally configured value, and the locally configured value, and the DDFH value received from the
DDFH value received from the credit-control server in a Credit- credit-control server in a Credit-Control-Answer message always
Control-Answer message always overrides any existing value. overrides any existing values.
If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client
SHOULD NOT grant the service if it can determine, eventually after a SHOULD NOT grant the service if, after a possible retransmission
possible re-transmission attempt to an alternative credit-control attempt to an alternative credit-control server, the credit-control
server, from the result code or error code in the answer message that client can eventually determine from the result code or error code in
units have not been debited. Otherwise, the credit-control client the Answer message that units have not been debited. Otherwise, the
SHOULD grant the service to the end user and store the request in the credit-control client SHOULD grant the service to the end user and
credit-control application level non-volatile storage. (Note that store the request in credit-control application-level non-volatile
re-sending the request at a later time is not a guarantee that the storage. (Note that resending the request at a later time is not a
service will be debited, as the user's account may be empty when the guarantee that the service will be debited, as the user's account may
server successfully processes the request.) The credit-control be empty when the server successfully processes the request.) The
client MUST mark these request messages as possible duplicates by credit-control client MUST mark these request messages as possible
setting the T-flag in the command header as described in [RFC6733], duplicates by setting the T flag in the command header as described
Section 3. in [RFC6733], Section 3.
If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the If the DDFH is set to CONTINUE, the service SHOULD be granted, even
service SHOULD be granted, even if credit-control messages cannot be if credit-control messages cannot be delivered and messages are not
delivered and messages are not buffered. buffered.
If the Tx timer expires, the credit-control client MUST continue the If the Tx timer expires, the credit-control client MUST continue the
service and wait for a possible late answer. If the request times service and wait for a possible late answer. If the request
out, the credit-control client re-transmits the request (marked with times out, the credit-control client retransmits the request (marked
T-flag) to a backup credit-control server, if possible. If the re- with the T flag) to a backup credit-control server, if possible. If
transmitted request also times out, or if a temporary error is the retransmitted request also times out or if a temporary error is
received in answer, the credit-control client buffers the request if received in answer, the credit-control client buffers the request if
the value of the Direct-Debiting-Failure-Handling AVP is set to the value of the DDFH is set to TERMINATE_OR_BUFFER. If a failed
TERMINATE_OR_BUFFER. If a failed answer is received for the re- answer is received for the retransmitted request, the credit-control
transmitted request, the credit-control client frees all the client frees all the resources reserved for the event message and
resources reserved for the event message and deletes the request deletes the request regardless of the value of the DDFH.
regardless of the value of the DDFH.
The Credit-Control-Request with the requested action REFUND_ACCOUNT The Credit-Control-Request with the requested action REFUND_ACCOUNT
should always be stored in the credit-control application level non- should always be stored in credit-control application-level
volatile storage in case of temporary failure. The credit-control non-volatile storage in case a temporary failure occurs. The
client MUST mark the re-transmitted request message as a possible credit-control client MUST mark the retransmitted request message as
duplicate by setting the T-flag in the command header as described in a possible duplicate by setting the T flag in the command header as
[RFC6733], Section 3. described in [RFC6733], Section 3.
For stored requests, the implementation may choose to limit the For stored requests, the implementation may choose to limit the
number of re-transmission attempts and to define a re-transmission number of retransmission attempts and to define a retransmission
interval. interval.
Note that only one place in the credit-control system SHOULD be Note that only one entity in the credit-control system SHOULD be
responsible for duplicate detection. If there is only one credit- responsible for duplicate detection. If there is only one
control server within the given realm, the credit-control server may credit-control server within the given realm, the credit-control
perform duplicate detection. If there is more than one credit- server may perform duplicate detection. If there is more than one
control server in a given realm, only one entity in the credit- credit-control server in a given realm, only one entity in the
control system should be responsible, to ensure that the end user's credit-control system should be responsible, to ensure that the
account is not debited or credited multiple times for the same end user's account is not debited or credited multiple times for the
service event. same service event.
7. Credit-Control Application State Machine
This section defines the credit-control application state machine. 7. Credit-Control Application State Machines
This section defines five credit-control application state machines.
The first four state machines are to be observed by credit-control The first four state machines are to be observed by credit-control
clients. The first one describes the session-based credit-control clients.
when the first interrogation is executed as part of the
authorization/authentication process. The second describes the
session-based credit-control when the first interrogation is executed
after the authorization/authentication process. The requirements as
to what state machines have to be supported are discussed in
Section 5.2.
The third state machine describes the session-based credit-control The first state machine describes session-based credit-control where
for the intermediate and final interrogations. The fourth one the first interrogation is executed as part of the authorization/
describes the event-based credit-control. These latter state authentication process. The second state machine describes
machines are to be observed by all implementations that conform to session-based credit-control where the first interrogation is
this specification. executed after the authorization/authentication process. The
requirements regarding what has to be supported for these two state
machines are discussed in Section 5.2.
The third state machine describes session-based credit-control for
the intermediate and final interrogations. The fourth state machine
describes event-based credit-control. These two state machines are
to be observed by all implementations that conform to this
specification.
The fifth state machine describes the credit-control session from a The fifth state machine describes the credit-control session from a
credit-control server perspective. credit-control server's perspective.
Any event not listed in the state machines MUST be considered an Any event not listed in the state machines MUST be considered an
error condition, and a corresponding answer, if applicable, MUST be error condition, and a corresponding answer, if applicable, MUST be
returned to the originator of the message. returned to the originator of the message.
In the state table, the event 'Failure to send' means that the In Tables 3, 4, and 5, the event "failure to send" means that the
Diameter credit-control client is unable to communicate with the Diameter Credit-Control client is unable to communicate with the
desired destination or, if failover procedure is supported, with a desired destination or, if a failover procedure is supported, with a
possibly defined alternative destination (e.g., the request times out possibly defined alternative destination (e.g., the request times out
and the answer message is not received). This could be due to the and the Answer message is not received). This could be due to
peer being down, or due to a physical link failure in the path to or (1) the peer being down or (2) a physical link failure in the path to
from the credit-control server. or from the credit-control server.
The event 'Temporary error' means that the Diameter credit-control The event "temporary error" means that the Diameter Credit-Control
client received a protocol error notification (DIAMETER_TOO_BUSY, client received a protocol error notification (DIAMETER_TOO_BUSY,
DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result- DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the
Code AVP of the Credit-Control-Answer command. The above protocol Result-Code AVP of the Credit-Control-Answer command. This type of
error notification may ultimately be received in answer to the re- notification may ultimately be received in answer to the
transmitted request to a defined alternative destination, if failover retransmitted request to a defined alternative destination, if
is supported. failover is supported.
The event 'Failed answer' means that the Diameter credit-control The event "failed answer" means that the Diameter Credit-Control
client received non-transient failure (permanent failure) client received a non-transient failure (permanent failure)
notification in the Credit-Control-Answer command. The above notification in the Credit-Control-Answer command. This type of
permanent failure notification may ultimately be received in answer notification may ultimately be received in answer to the
to the re-transmitted request to a defined alternative destination, retransmitted request to a defined alternative destination, if
if failover is supported. failover is supported.
The action 'store request' means that a request is stored in the The action "store request" means that a request is stored in
credit-control application level non-volatile storage. credit-control application-level non-volatile storage.
The event 'Not successfully processed' means that the credit-control The event "not successfully processed" means that the credit-control
server could not process the message; e.g., due to an unknown end server could not process the message, e.g., due to an unknown
user, account being empty, or errors defined in [RFC6733]. end user, an account being empty, or errors defined in [RFC6733].
The event 'User service terminated' can be triggered by various The event "user service terminated" can be triggered for various
reasons, e.g., normal user termination, network failure, and ASR reasons, e.g., normal user termination, network failure, and ASR
(Abort-Session-Request). The Termination-Cause AVP contains (Abort-Session-Request). The Termination-Cause AVP contains
information about the termination reason, as specified in [RFC6733]. information about the reason for termination, as specified in
[RFC6733].
The Tx timer, which is used to control the waiting time in the The Tx timer, which is used to control the waiting time in the
credit-control client in the Pending state, is stopped upon exit of credit-control client in the Pending state, is stopped upon exit of
the Pending state. The stopping of the Tx timer is omitted in the the Pending state. The stopping of the Tx timer is omitted in the
state machine when the new state is Idle, as moving to Idle state state machine when the new state is Idle, as moving to Idle state
implies the clearing of the session and all the variables associated implies the clearing of the session and all the variables associated
to it. to it.
The states PendingI, PendingU, PendingT, PendingE, and PendingB stand The states PendingI, PendingU, PendingT, PendingE, and PendingB stand
for pending states to wait for an answer to a credit-control request for pending states to wait for an answer to a credit-control request
related to Initial, Update, Termination, Event, or Buffered request, related to Initial, Update, Termination, Event, or Buffered request,
respectively. respectively.
The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling In Table 2, failover to a secondary server upon "temporary error" or
and Direct-Debiting-Failure-Handling, respectively. "failure to send" is not explicitly described. However, moving an
ongoing credit-control message stream to an alternative server is
In the following state machine table, the failover to a secondary possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED,
server upon 'Temporary error' or 'Failure to send' is not explicitly as described in Section 5.7.
described. Moving an ongoing credit-control message stream to an
alternative server is, however, possible if the CC-Session-Failover
AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7.
Re-sending a credit-control event to an alternative server is Resending a credit-control event to an alternative server is
supported as described in Section 6.5. supported as described in Section 6.5.
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send AA | PendingI | | Idle | Client or device requests | Send | PendingI |
| | access/service | request | | | | access/service | AA-Request | |
| | | with added | | | | | with added | |
| | | CC AVPs, | | | | | CC AVPs, | |
| | | start Tx | | | | | start Tx | |
| | | timer | | | | | timer | |
| PendingI | Successful AA req. answer | Grant | Open | | | | | |
| | received | service to | | | PendingI | Successful answer to | Grant | Open |
| | AA-Request received | service to | |
| | | end user, | | | | | end user, | |
| | | stop Tx | | | | | stop Tx | |
| | | timer | | | | | timer | |
| | | | |
| PendingI | Tx timer expired | Disconnect | Idle | | PendingI | Tx timer expired | Disconnect | Idle |
| | | user/dev | | | | | user/dev | |
| PendingI | Failed AA answer received | Disconnect | Idle | | | | | |
| PendingI | Failed AA-Answer received | Disconnect | Idle |
| | | user/dev | | | | | user/dev | |
| PendingI | AA answer received with | Grant | Idle | | | | | |
| | result code equal to | service to | | | PendingI | AA-Answer received with | Grant | Idle |
| | Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingI | User service terminated | Queue | PendingI | | PendingI | User service terminated | Queue | PendingI |
| | | termination | | | | | termination | |
| | | event | | | | | event | |
| | | | |
| PendingI | Change in rating condition | Queue | PendingI | | PendingI | Change in rating condition | Queue | PendingI |
| | | changed | | | | | changed | |
| | | rating | | | | | rating | |
| | | condition | | | | | condition | |
| | | event | | | | | event | |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
Table 2: CLIENT, SESSION BASED for the first interrogation with AA Table 2: Session-Based Client State Machine for the
request First Interrogation with AA-Request
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send CC | PendingI | | Idle | Client or device requests | Send CC | PendingI |
| | access/service | initial | | | | access/service | initial | |
| | | req., start | | | | | req., start | |
| | | Tx timer | | | | | Tx timer | |
| | | | |
| PendingI | Successful CC initial answer | Stop Tx | Open | | PendingI | Successful CC initial answer | Stop Tx | Open |
| | received | timer | | | | received | timer | |
| | | | |
| PendingI | Failure to send, or temporary | Grant | Idle | | PendingI | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | | | | error and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
| | | | |
| PendingI | Failure to send, or temporary | Terminate | Idle | | PendingI | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | | | | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | | | | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | | | | RETRY_AND_TERMINATE | | |
| | | | |
| PendingI | Tx timer expired and CCFH | Terminate | Idle | | PendingI | Tx timer expired and CCFH | Terminate | Idle |
| | equal to TERMINATE | end user's | | | | equal to TERMINATE | end user's | |
| | | service | | | | | service | |
| | | | |
| PendingI | Tx timer expired and CCFH | Grant | PendingI | | PendingI | Tx timer expired and CCFH | Grant | PendingI |
| | equal to CONTINUE or to | service to | | | | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | | | | RETRY_AND_TERMINATE | end user | |
| | | | |
| PendingI | CC initial answer received | Terminate | Idle | | PendingI | CC initial answer received | Terminate | Idle |
| | with result code | end user's | | | | with Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED or | service | | | | END_USER_SERVICE_DENIED or to | service | |
| | USER_UNKNOWN | | | | | USER_UNKNOWN | | |
| | | | |
| PendingI | CC initial answer received | Grant | Idle | | PendingI | CC initial answer received | Grant | Idle |
| | with result code equal to | service to | | | | with Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingI | Failed CC initial answer | Grant | Idle | | PendingI | Failed CC initial answer | Grant | Idle |
| | received and CCFH equal to | service to | | | | received and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
| | | | |
| PendingI | Failed CC initial answer | Terminate | Idle | | PendingI | Failed CC initial answer | Terminate | Idle |
| | received and CCFH equal to | end user's | | | | received and CCFH equal to | end user's | |
| | TERMINATE or to | service | | | | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | | | | RETRY_AND_TERMINATE | | |
| | | | |
| PendingI | User service terminated | Queue | PendingI | | PendingI | User service terminated | Queue | PendingI |
| | | termination | | | | | termination | |
| | | event | | | | | event | |
| | | | |
| PendingI | Change in rating condition | Queue | PendingI | | PendingI | Change in rating condition | Queue | PendingI |
| | | changed | | | | | changed | |
| | | rating | | | | | rating | |
| | | condition | | | | | condition | |
| | | event | | | | | event | |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
Table 3: CLIENT, SESSION BASED for the first interrogation with CCR Table 3: Session-Based Client State Machine for the
First Interrogation with CCR
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
| Open | Granted unit elapses and no | Send CC | PendingU | | Open | Granted unit elapses and no | Send CC | PendingU |
| | final unit indication | update | | | | final-unit indication | update | |
| | received | req., start | | | | received | req., start | |
| | | Tx timer | | | | | Tx timer | |
| | | | |
| Open | Granted unit elapses and | Terminate | PendingT | | Open | Granted unit elapses and | Terminate | PendingT |
| | final unit action equal to | end user's | | | | final unit action equal to | end user's | |
| | TERMINATE received | service, | | | | TERMINATE received | service, | |
| | | send CC | | | | | send CC | |
| | | termination | | | | | termination | |
| | | req. | | | | | req. | |
| | | | |
| Open | Change in rating condition in | Send CC | PendingU | | Open | Change in rating condition in | Send CC | PendingU |
| | queue | update | | | | queue | update | |
| | | req., Start | | | | | req., start | |
| | | Tx timer | | | | | Tx timer | |
| | | | |
| Open | Service terminated in queue | Send CC | PendingT | | Open | Service terminated in queue | Send CC | PendingT |
| | | termination | | | | | termination | |
| | | req. | | | | | req. | |
| | | | |
| Open | Change in rating condition or | Send CC | PendingU | | Open | Change in rating condition or | Send CC | PendingU |
| | Validity-Time elapses | update | | | | Validity-Time elapses | update | |
| | | req., Start | | | | | req., start | |
| | | Tx timer | | | | | Tx timer | |
| | | | |
| Open | User service terminated | Send CC | PendingT | | Open | User service terminated | Send CC | PendingT |
| | | termination | | | | | termination | |
| | | req. | | | | | req. | |
| | | | |
| Open | RAR received | Send RAA | PendingU | | Open | RAR received | Send RAA | PendingU |
| | | followed by | | | | | followed by | |
| | | CC update | | | | | CC update | |
| | | req., start | | | | | req., start | |
| | | Tx timer | | | | | Tx timer | |
| | | | |
| PendingU | Successful CC update answer | Stop Tx | Open | | PendingU | Successful CC update answer | Stop Tx | Open |
| | received | timer | | | | received | timer | |
| | | | |
| PendingU | Failure to send, or temporary | Grant | Idle | | PendingU | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | | | | error and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
| | | | |
| PendingU | Failure to send, or temporary | Terminate | Idle | | PendingU | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | | | | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | | | | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | | | | RETRY_AND_TERMINATE | | |
| | | | |
| PendingU | Tx timer expired and CCFH | Terminate | Idle | | PendingU | Tx timer expired and CCFH | Terminate | Idle |
| | equal to TERMINATE | end user's | | | | equal to TERMINATE | end user's | |
| | | service | | | | | service | |
| | | | |
| PendingU | Tx timer expired and CCFH | Grant | PendingU | | PendingU | Tx timer expired and CCFH | Grant | PendingU |
| | equal to CONTINUE or to | service to | | | | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | | | | RETRY_AND_TERMINATE | end user | |
| | | | |
| PendingU | CC update answer received | Terminate | Idle | | PendingU | CC update answer received | Terminate | Idle |
| | with result code | end user's | | | | with Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED | service | | | | END_USER_SERVICE_DENIED | service | |
| | | | |
| PendingU | CC update answer received | Grant | Idle | | PendingU | CC update answer received | Grant | Idle |
| | with result code equal to | service to | | | | with Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingU | Failed CC update answer | Grant | Idle | | PendingU | Failed CC update answer | Grant | Idle |
| | received and CCFH equal to | service to | | | | received and CCFH equal to | service to | |
| | CONTINUE | end user | | | | CONTINUE | end user | |
| | | | |
| PendingU | Failed CC update answer | Terminate | Idle | | PendingU | Failed CC update answer | Terminate | Idle |
| | received and CCFH equal to | end user's | | | | received and CCFH equal to | end user's | |
| | TERMINATE or to | service | | | | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | | | | RETRY_AND_TERMINATE | | |
| | | | |
| PendingU | User service terminated | Queue | PendingU | | PendingU | User service terminated | Queue | PendingU |
| | | termination | | | | | termination | |
| | | event | | | | | event | |
| | | | |
| PendingU | Change in rating condition | Queue | PendingU | | PendingU | Change in rating condition | Queue | PendingU |
| | | changed | | | | | changed | |
| | | rating | | | | | rating | |
| | | condition | | | | | condition | |
| | | event | | | | | event | |
| | | | |
| PendingU | RAR received | Send RAA | PendingU | | PendingU | RAR received | Send RAA | PendingU |
| | | | |
| PendingT | Successful CC termination | | Idle | | PendingT | Successful CC termination | | Idle |
| | answer received | | | | | answer received | | |
| | | | |
| PendingT | Failure to send, temporary | | Idle | | PendingT | Failure to send, temporary | | Idle |
| | error, or failed answer | | | | | error, or failed answer | | |
| | | | |
| PendingT | Change in rating condition | | PendingT | | PendingT | Change in rating condition | | PendingT |
+----------+-------------------------------+-------------+----------+ +----------+-------------------------------+-------------+----------+
Table 4: CLIENT, SESSION BASED for intermediate and final Table 4: Session-Based Client State Machine for Intermediate and
interrogations Final Interrogations
+----------+--------------------------------+------------+----------+ +----------+--------------------------------+------------+----------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+----------+--------------------------------+------------+----------+ +----------+--------------------------------+------------+----------+
| Idle | Client or device requests a | Send CC | PendingE | | Idle | Client or device requests a | Send CC | PendingE |
| | one-time service | event | | | | one-time service | event | |
| | | req., | | | | | req., | |
| | | Start Tx | | | | | start Tx | |
| | | timer | | | | | timer | |
| | | | |
| Idle | Request in storage | Send | PendingB | | Idle | Request in storage | Send | PendingB |
| | | stored | | | | | stored | |
| | | request | | | | | request | |
| | | | |
| PendingE | Successful CC event answer | Grant | Idle | | PendingE | Successful CC event answer | Grant | Idle |
| | received | service to | | | | received | service to | |
| | | end user | | | | | end user | |
| | | | |
| PendingE | Failure to send, temporary | Indicate | Idle | | PendingE | Failure to send, temporary | Indicate | Idle |
| | error, failed CC event answer | service | | | | error, failed CC event answer | service | |
| | received, or Tx timer expired; | error | | | | received, or Tx timer expired; | error | |
| | requested action CHECK_BALANCE | | | | | requested action CHECK_BALANCE | | |
| | or PRICE_ENQUIRY | | | | | or PRICE_ENQUIRY | | |
| | | | |
| PendingE | CC event answer received with | Terminate | Idle | | PendingE | CC event answer received with | Terminate | Idle |
| | result code | end user's | | | | Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED or | service | | | | END_USER_SERVICE_DENIED or to | service | |
| | USER_UNKNOWN and Tx timer | | | | | USER_UNKNOWN and Tx timer | | |
| | running | | | | | running | | |
| | | | |
| PendingE | CC event answer received with | Grant | Idle | | PendingE | CC event answer received with | Grant | Idle |
| | result code | service to | | | | Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE; | end user | | | | CREDIT_CONTROL_NOT_APPLICABLE; | end user | |
| | requested action | | | | | requested action | | |
| | DIRECT_DEBITING | | | | | DIRECT_DEBITING | | |
| | | | |
| PendingE | Failure to send, temporary | Grant | Idle | | PendingE | Failure to send, temporary | Grant | Idle |
| | error, failed CC event answer | service to | | | | error, or failed CC event | service to | |
| | received; requested action | end user | | | | answer received; requested | end user | |
| | DIRECT_DEBITING; DDFH equal to | | | | | action DIRECT_DEBITING; DDFH | | |
| | CONTINUE | | | | | equal to CONTINUE | | |
| | | | |
| PendingE | Failed CC event answer | Terminate | Idle | | PendingE | Failed CC event answer | Terminate | Idle |
| | received or temporary error; | end user's | | | | received or temporary error; | end user's | |
| | requested action | service | | | | requested action | service | |
| | DIRECT_DEBITING; DDFH equal to | | | | | DIRECT_DEBITING; DDFH equal to | | |
| | TERMINATE_OR_BUFFER and Tx | | | | | TERMINATE_OR_BUFFER and Tx | | |
| | timer running | | | | | timer running | | |
| | | | |
| PendingE | Tx timer expired; requested | Grant | PendingE | | PendingE | Tx timer expired; requested | Grant | PendingE |
| | action DIRECT_DEBITING | service to | | | | action DIRECT_DEBITING | service to | |
| | | end user | | | | | end user | |
| | | | |
| PendingE | Failure to send; requested | Store | Idle | | PendingE | Failure to send; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | | | | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER | with | | | | equal to TERMINATE_OR_BUFFER | with | |
| | | T-flag | | | | | T flag | |
| | | | |
| PendingE | Temporary error; requested | Store | Idle | | PendingE | Temporary error; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | | | | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER; | | | | | equal to TERMINATE_OR_BUFFER; | | |
| | Tx timer expired | | | | | Tx timer expired | | |
| | | | |
| PendingE | Failed answer or answer | | Idle | | PendingE | Failed answer or answer | | Idle |
| | received with result code | | | | | received with Result-Code | | |
| | END_USER_SERVICE DENIED or | | | | | equal to END_USER_SERVICE | | |
| | USER_UNKNOWN; requested action | | | | | DENIED or to USER_UNKNOWN; | | |
| | requested action | | |
| | DIRECT_DEBITING; Tx timer | | | | | DIRECT_DEBITING; Tx timer | | |
| | expired | | | | | expired | | |
| | | | |
| PendingE | Failed CC event answer | Indicate | Idle | | PendingE | Failed CC event answer | Indicate | Idle |
| | received; requested action | service | | | | received; requested action | service | |
| | REFUND_ACCOUNT | error and | | | | REFUND_ACCOUNT | error and | |
| | | delete | | | | | delete | |
| | | request | | | | | request | |
| | | | |
| PendingE | Failure to send or Tx timer | Store | Idle | | PendingE | Failure to send or Tx timer | Store | Idle |
| | expired; requested action | request | | | | expired; requested action | request | |
| | REFUND_ACCOUNT | with | | | | REFUND_ACCOUNT | with | |
| | | T-flag | | | | | T flag | |
| PendingE | Temporary error, and requested | Store | Idle | | | | | |
| PendingE | Temporary error; requested | Store | Idle |
| | action REFUND_ACCOUNT | request | | | | action REFUND_ACCOUNT | request | |
| | | | |
| PendingB | Successful CC answer received | Delete | Idle | | PendingB | Successful CC answer received | Delete | Idle |
| | | request | | | | | request | |
| | | | |
| PendingB | Failed CC answer received | Delete | Idle | | PendingB | Failed CC answer received | Delete | Idle |
| | | request | | | | | request | |
| | | | |
| PendingB | Failure to send or temporary | | Idle | | PendingB | Failure to send or temporary | | Idle |
| | error | | | | | error | | |
+----------+--------------------------------+------------+----------+ +----------+--------------------------------+------------+----------+
Table 5: CLIENT, EVENT BASED Table 5: One-Time Event Client State Machine
+-------+------------------------+--------------------------+-------+ +-------+------------------------+--------------------------+-------+
| State | Event | Action | New | | State | Event | Action | New |
| | | | State | | | | | State |
+-------+------------------------+--------------------------+-------+ +-------+------------------------+--------------------------+-------+
| Idle | CC initial request | Send CC initial answer, | Open | | Idle | CC initial request | Send CC initial answer, | Open |
| | received and | reserve units, start Tcc | | | | received and | reserve units, start Tcc | |
| | successfully processed | | | | | successfully processed | | |
| | | | |
| Idle | CC initial request | Send CC initial answer | Idle | | Idle | CC initial request | Send CC initial answer | Idle |
| | received but not | with Result-Code != | | | | received but not | with Result-Code != | |
| | successfully processed | SUCCESS | | | | successfully processed | SUCCESS | |
| | | | |
| Idle | CC event request | Send CC event answer | Idle | | Idle | CC event request | Send CC event answer | Idle |
| | received and | | | | | received and | | |
| | successfully processed | | | | | successfully processed | | |
| | | | |
| Idle | CC event request | Send CC event answer | Idle | | Idle | CC event request | Send CC event answer | Idle |
| | received but not | with Result-Code != | | | | received but not | with Result-Code != | |
| | successfully processed | SUCCESS | | | | successfully processed | SUCCESS | |
| | | | |
| Open | CC update request | Send CC update answer, | Open | | Open | CC update request | Send CC update answer, | Open |
| | received and | debit used units, | | | | received and | debit used units, | |
| | successfully processed | reserve new units, | | | | successfully processed | reserve new units, | |
| | | restart Tcc | | | | | restart Tcc | |
| | | | |
| Open | CC update request | Send CC update answer | Idle | | Open | CC update request | Send CC update answer | Idle |
| | received but not | with Result-Code != | | | | received but not | with Result-Code != | |
| | successfully processed | SUCCESS, debit used | | | | successfully processed | SUCCESS, debit used | |
| | | units | | | | | units | |
| | | | |
| Open | CC termination request | Send CC termin. answer, | Idle | | Open | CC termination request | Send CC termin. answer, | Idle |
| | received and | Stop Tcc, debit used | | | | received and | stop Tcc, debit used | |
| | successfully processed | units | | | | successfully processed | units | |
| | | | |
| Open | CC termination request | Send CC termin. answer | Idle | | Open | CC termination request | Send CC termin. answer | Idle |
| | received but not | with Result-Code != | | | | received but not | with Result-Code != | |
| | successfully processed | SUCCESS, debit used | | | | successfully processed | SUCCESS, debit used | |
| | | units | | | | | units | |
| | | | |
| Open | Session supervision | Release reserved units | Idle | | Open | Session supervision | Release reserved units | Idle |
| | timer Tcc expired | | | | | timer Tcc expired | | |
+-------+------------------------+--------------------------+-------+ +-------+------------------------+--------------------------+-------+
Table 6: SERVER, SESSION AND EVENT BASED Table 6: Session-Based and Event-Based Server State Machine
8. Credit-Control AVPs 8. Credit-Control AVPs
This section defines the credit-control AVPs that are specific to This section defines the Credit-Control AVPs that are specific to the
Diameter credit-control application and that MAY be included in the Diameter Credit-Control application and that MAY be included in the
Diameter credit-control messages. Diameter Credit-Control messages.
The AVPs defined in this section MAY also be included in The AVPs defined in this section MAY also be included in
authorization commands defined in authorization-specific authorization commands defined in authorization-specific
applications, such as [RFC7155] and [RFC4004], if the first applications, such as [RFC7155] and [RFC4004], if the first
interrogation is performed as part of the authorization/ interrogation is performed as part of the authorization/
authentication process, as described in Section 5.2. authentication process, as described in Section 5.2.
The Diameter AVP rules are defined in the Diameter Base [RFC6733], The Diameter AVP rules are defined in [RFC6733], Section 4. These
Section 4. These AVP rules are observed in AVPs defined in this AVP rules are observed in AVPs defined in this section.
section.
The following table describes the Diameter AVPs defined in the The following table describes the Diameter AVPs defined in the
credit-control application, their AVP Code values, types, and credit-control application, their AVP Code values, types, and
possible flag values. The AVP Flag rules are explained in the possible flag values. The AVP Flag rules ('M', 'V') are explained in
Diameter base [RFC6733], section 4.1. [RFC6733], Section 4.1.
+---------------+ +---------------+
|AVP Flag rules | |AVP Flag Rules |
|----+-----+----| Defined |----+-----+----|
AVP Section | | |MUST| AVP in | | |MUST|
Attribute Name Code Defined Data Type |MUST| MAY |NOT | Attribute Name Code Section Data Type |MUST| MAY |NOT |
-----------------------------------------|----+-----+----| ----------------------------------------------------|----+-----+----|
CC-Correlation-Id 411 8.1 OctetString| | M | V | CC-Correlation-Id 411 8.1 OctetString | | M | V |
CC-Input-Octets 412 8.24 Unsigned64 | M | | V | CC-Input-Octets 412 8.24 Unsigned64 | M | | V |
CC-Money 413 8.22 Grouped | M | | V | CC-Money 413 8.22 Grouped | M | | V |
CC-Output-Octets 414 8.25 Unsigned64 | M | | V | CC-Output-Octets 414 8.25 Unsigned64 | M | | V |
CC-Request-Number 415 8.2 Unsigned32 | M | | V | CC-Request-Number 415 8.2 Unsigned32 | M | | V |
CC-Request-Type 416 8.3 Enumerated | M | | V | CC-Request-Type 416 8.3 Enumerated | M | | V |
CC-Service- 417 8.26 Unsigned64 | M | | V | CC-Service-Specific- 417 8.26 Unsigned64 | M | | V |
Specific-Units | | | | Units | | | |
CC-Session- 418 8.4 Enumerated | M | | V | CC-Session-Failover 418 8.4 Enumerated | M | | V |
Failover | | | | CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V |
CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V | CC-Time 420 8.21 Unsigned32 | M | | V |
CC-Time 420 8.21 Unsigned32 | M | | V | CC-Total-Octets 421 8.23 Unsigned64 | M | | V |
CC-Total-Octets 421 8.23 Unsigned64 | M | | V | CC-Unit-Type 454 8.32 Enumerated | M | | V |
CC-Unit-Type 454 8.32 Enumerated | M | | V | Check-Balance-Result 422 8.6 Enumerated | M | | V |
Check-Balance- 422 8.6 Enumerated | M | | V | Cost-Information 423 8.7 Grouped | M | | V |
Result | | | | Cost-Unit 424 8.12 UTF8String | M | | V |
Cost-Information 423 8.7 Grouped | M | | V | Credit-Control 426 8.13 Enumerated | M | | V |
Cost-Unit 424 8.12 UTF8String | M | | V | Credit-Control- 427 8.14 Enumerated | M | | V |
Credit-Control 426 8.13 Enumerated | M | | V | Failure-Handling | | | |
Credit-Control- 427 8.14 Enumerated | M | | V | Currency-Code 425 8.11 Unsigned32 | M | | V |
Failure-Handling | | | | Direct-Debiting- 428 8.15 Enumerated | M | | V |
Currency-Code 425 8.11 Unsigned32 | M | | V | Failure-Handling | | | |
Direct-Debiting- 428 8.15 Enumerated | M | | V | Exponent 429 8.9 Integer32 | M | | V |
Failure-Handling | | | | Final-Unit-Action 449 8.35 Enumerated | M | | V |
Exponent 429 8.9 Integer32 | M | | V | Final-Unit-Indication 430 8.34 Grouped | M | | V |
Final-Unit-Action 449 8.35 Enumerated | M | | V | QoS-Final-Unit-Indication 669 8.68 Grouped | | M | V |
Final-Unit- 430 8.34 Grouped | M | | V | Granted-Service-Unit 431 8.17 Grouped | M | | V |
Indication | | | | G-S-U-Pool-Identifier 453 8.31 Unsigned32 | M | | V |
QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | G-S-U-Pool-Reference 457 8.30 Grouped | M | | V |
Indication | | | | Multiple-Services- 456 8.16 Grouped | M | | V |
Granted-Service- 431 8.17 Grouped | M | | V | Credit-Control | | | |
Unit | | | | Multiple-Services- 455 8.40 Enumerated | M | | V |
G-S-U-Pool- 453 8.31 Unsigned32 | M | | V | Indicator | | | |
Identifier | | | | Rating-Group 432 8.29 Unsigned32 | M | | V |
G-S-U-Pool- 457 8.30 Grouped | M | | V | Redirect-Address-Type 433 8.38 Enumerated | M | | V |
Reference | | | | Redirect-Server 434 8.37 Grouped | M | | V |
Multiple-Services 456 8.16 Grouped | M | | V | Redirect-Server-Address 435 8.39 UTF8String | M | | V |
-Credit-Control | | | | Redirect-Server-Extension 665 8.64 Grouped | | M | V |
Multiple-Services 455 8.40 Enumerated | M | | V | Redirect-Address- 666 8.65 Address | | M | V |
-Indicator | | | | IPAddress | | | |
Rating-Group 432 8.29 Unsigned32 | M | | V | Redirect-Address-URL 667 8.66 UTF8String | | M | V |
Redirect-Address 433 8.38 Enumerated | M | | V | Redirect-Address-SIP-URI 668 8.67 UTF8String | | M | V |
-Type | | | | Requested-Action 436 8.41 Enumerated | M | | V |
Redirect-Server 434 8.37 Grouped | M | | V | Requested-Service-Unit 437 8.18 Grouped | M | | V |
Redirect-Server 435 8.39 UTF8String | M | | V | Restriction-Filter-Rule 438 8.36 IPFilterRule| M | | V |
-Address | | | | Service-Context-Id 461 8.42 UTF8String | M | | V |
Redirect-Server TBD13 8.64 Grouped | | M | V | Service-Identifier 439 8.28 Unsigned32 | M | | V |
-Extension | | | | Service-Parameter-Info 440 8.43 Grouped | | M | V |
Redirect-Address TBD14 8.65 Address | | M | V | Service-Parameter-Type 441 8.44 Unsigned32 | | M | V |
-IPAddress | | | | Service-Parameter-Value 442 8.45 OctetString | | M | V |
Redirect-Address TBD15 8.66 UTF8String | | M | V | Subscription-Id 443 8.46 Grouped | M | | V |
-URL | | | | Subscription-Id-Data 444 8.48 UTF8String | M | | V |
Redirect-Address TBD16 8.67 UTF8String | | M | V | Subscription-Id-Type 450 8.47 Enumerated | M | | V |
-SIP-URI | | | | Subscription-Id-Extension 659 8.58 Grouped | | M | V |
Requested-Action 436 8.41 Enumerated | M | | V | Subscription-Id-E164 660 8.59 UTF8String | | M | V |
Requested-Service 437 8.18 Grouped | M | | V | Subscription-Id-IMSI 661 8.60 UTF8String | | M | V |
-Unit | | | | Subscription-Id-SIP-URI 662 8.61 UTF8String | | M | V |
Restriction 438 8.36 IPFiltrRule| M | | V | Subscription-Id-NAI 663 8.62 UTF8String | | M | V |
-Filter-Rule | | | | Subscription-Id-Private 664 8.63 UTF8String | | M | V |
Service-Context 461 8.42 UTF8String | M | | V | Tariff-Change-Usage 452 8.27 Enumerated | M | | V |
-Id | | | | Tariff-Time-Change 451 8.20 Time | M | | V |
Service- 439 8.28 Unsigned32 | M | | V | Unit-Value 445 8.8 Grouped | M | | V |
Identifier | | | | Used-Service-Unit 446 8.19 Grouped | M | | V |
Service-Parameter 440 8.43 Grouped | | M | V | User-Equipment-Info 458 8.49 Grouped | | M | V |
-Info | | | | User-Equipment-Info-Type 459 8.50 Enumerated | | M | V |
Service- 441 8.44 Unsigned32 | | M | V | User-Equipment-Info-Value 460 8.51 OctetString | | M | V |
Parameter-Type | | | | User-Equipment-Info- 653 8.52 Grouped | | M | V |
Service- 442 8.45 OctetString| | M | V | Extension | | | |
Parameter-Value | | | | User-Equipment-Info- 654 8.53 OctetString | | M | V |
Subscription-Id 443 8.46 Grouped | M | | V | IMEISV | | | |
Subscription-Id 444 8.48 UTF8String | M | | V | User-Equipment-Info-MAC 655 8.54 OctetString | | M | V |
-Data | | | | User-Equipment-Info-EUI64 656 8.55 OctetString | | M | V |
Subscription-Id 450 8.47 Enumerated | M | | V | User-Equipment-Info- 657 8.56 OctetString | | M | V |
-Type | | | | ModifiedEUI64 | | | |
Subscription-Id TBD7 8.58 Grouped | | M | V | User-Equipment-Info-IMEI 658 8.57 OctetString | | M | V |
-Extension | | | | Value-Digits 447 8.10 Integer64 | M | | V |
Subscription-Id TBD8 8.59 UTF8String | | M | V | Validity-Time 448 8.33 Unsigned32 | M | | V |
-E164 | | | |
Subscription-Id TBD9 8.60 UTF8String | | M | V |
-IMSI | | | |
Subscription-Id TBD10 8.61 UTF8String | | M | V |
-SIP-URI | | | |
Subscription-Id TBD11 8.62 UTF8String | | M | V |
-NAI | | | |
Subscription-Id TBD12 8.63 UTF8String | | M | V |
-Private | | | |
Tariff-Change 452 8.27 Enumerated | M | | V |
-Usage | | | |
Tariff-Time 451 8.20 Time | M | | V |
-Change | | | |
Unit-Value 445 8.8 Grouped | M | | V |
Used-Service-Unit 446 8.19 Grouped | M | | V |
User-Equipment 458 8.49 Grouped | | M | V |
-Info | | | |
User-Equipment 459 8.50 Enumerated | | M | V |
-Info-Type | | | |
User-Equipment 460 8.51 OctetString| | M | V |
-Info-Value | | | |
User-Equipment TBD1 8.52 Grouped | | M | V |
-Info-Extension | | | |
User-Equipment TBD2 8.53 OctetString| | M | V |
-Info-IMEISV | | | |
User-Equipment TBD3 8.54 OctetString| | M | V |
-Info-MAC | | | |
User-Equipment TBD4 8.55 OctetString| | M | V |
-Info-EUI64 | | | |
User-Equipment TBD5 8.56 OctetString| | M | V |
-Info-ModifiedEUI64 | | | |
User-Equipment TBD6 8.57 OctetString| | M | V |
-Info-IMEI | | | |
Value-Digits 447 8.10 Integer64 | M | | V |
Validity-Time 448 8.33 Unsigned32 | M | | V |
8.1. CC-Correlation-Id AVP 8.1. CC-Correlation-Id AVP
The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and
contains information to correlate credit-control requests generated contains information to correlate credit-control requests generated
for different components of the service; e.g., transport and service for different components of the service, e.g., transport and service
level. The one who allocates the Service-Context-Id (i.e., unique level. Whoever allocates the Service-Context-Id (i.e., a unique
identifier of a service-specific document) is also responsible for identifier of a service-specific document) is also responsible for
defining the content and encoding of the CC-Correlation-Id AVP. defining the content and encoding of the CC-Correlation-Id AVP.
8.2. CC-Request-Number AVP 8.2. CC-Request-Number AVP
The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and
identifies this request within one session. As Session-Id AVPs are identifies this request within one session. As Session-Id AVPs are
globally unique, the combination of Session-Id and CC-Request-Number globally unique, the combination of the Session-Id AVP and the
AVPs is also globally unique and can be used in matching credit- CC-Request-Number AVP is also globally unique and can be used in
control messages with confirmations. An easy way to produce unique matching credit-control messages with confirmations. An easy way to
numbers is to set the value to 0 for a credit-control request of type produce unique numbers is to set the value of the CC-Request-Number
INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the AVP to 0 for a credit-control request with a CC-Request-Type AVP of
first UPDATE_REQUEST, to 2 for the second, and so on until the value INITIAL_REQUEST (the initial request in a session). The value of the
for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST. CC-Request-Number AVP should be set to 1 for the first
UPDATE_REQUEST, to 2 for the second, and so on until the value for
TERMINATION_REQUEST is one more than the value for the last
UPDATE_REQUEST. In the case of event charging (when the CC-Request-
Type AVP has the value EVENT_REQUEST), the CC-Request-Number AVP
should be set to 0 for a credit-control request.
8.3. CC-Request-Type AVP 8.3. CC-Request-Type AVP
The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and
contains the reason for sending the credit-control request message. contains the reason for sending the Credit-Control-Request message.
It MUST be present in all Credit-Control-Request messages. The It MUST be present in all Credit-Control-Request messages. The
following values are defined for the CC-Request-Type AVP (The value following values are defined for the CC-Request-Type AVP (the value
of zero is reserved): of 0 (zero) is reserved):
INITIAL_REQUEST 1 INITIAL_REQUEST 1
An Initial request is used to initiate a credit-control session, and This request is used to initiate a credit-control session. It
contains credit-control information that is relevant to the contains credit-control information that is relevant to the
initiation. initiation.
UPDATE_REQUEST 2 UPDATE_REQUEST 2
An Update request contains credit-control information for an existing This request contains credit-control information for an existing
credit-control session. Update credit-control requests SHOULD be credit-control session. Credit-control requests of this type SHOULD
sent every time a credit-control re-authorization is needed at the be sent every time a credit-control re-authorization is needed at the
expiry of the allocated quota or validity time. Further, additional expiry of the allocated quota or validity time. Further, additional
service-specific events MAY trigger a spontaneous Update request. service-specific events MAY trigger a spontaneous UPDATE_REQUEST.
TERMINATION_REQUEST 3 TERMINATION_REQUEST 3
A Termination request is sent to terminate a credit-control session This request is sent to terminate a credit-control session. It
and contains credit-control information relevant to the existing contains credit-control information relevant to the existing session.
session.
EVENT_REQUEST 4 EVENT_REQUEST 4
An Event request is used when there is no need to maintain any This request is used when there is no need to maintain any
credit-control session state in the credit-control server. This credit-control session state in the credit-control server. It
request contains all information relevant to the service, and is the contains all information relevant to the service and is the only
only request of the service. The reason for the Event request is request of the service. The reason for this request is further
further detailed in the Requested-Action AVP. The Requested-Action detailed in the Requested-Action AVP. The Requested-Action AVP MUST
AVP MUST be included in the Credit-Control-Request message when CC- be included in the Credit-Control-Request message when CC-Request-
Request-Type is set to EVENT_REQUEST. Type is set to EVENT_REQUEST.
8.4. CC-Session-Failover AVP 8.4. CC-Session-Failover AVP
The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and The CC-Session-Failover AVP (AVP Code 418) is of type Enumerated and
contains information as to whether moving the credit-control message contains information as to whether moving the credit-control message
stream to a backup server during an ongoing credit-control session is stream to a backup server during an ongoing credit-control session is
supported. In communication failures, the credit-control message supported. In the case of communication failures, the credit-control
streams can be moved to an alternative destination if the credit- message streams can be moved to an alternative destination if the
control server supports failover to an alternative server. The credit-control server supports failover to an alternative server.
secondary credit-control server name, if received from the home The secondary credit-control server name, if received from the home
Diameter AAA server, can be used as an address of the backup server. Diameter AAA server, can be used as an address of the backup server.
An implementation is not required to support moving a credit-control An implementation is not required to support moving a credit-control
message stream to an alternative server, as this also requires moving message stream to an alternative server, as this also requires moving
information related to the credit-control session to backup server. information related to the credit-control session to the backup
server.
The following values are defined for the CC-Session-Failover AVP: The following values are defined for the CC-Session-Failover AVP:
FAILOVER_NOT_SUPPORTED 0 FAILOVER_NOT_SUPPORTED 0
When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,
the credit-control message stream MUST NOT be moved to an alternative the credit-control message stream MUST NOT be moved to an alternative
destination in the case of communication failure. This is the destination in the case of a communication failure. This is the
default behavior if the AVP isn't included in the reply from the default behavior if the AVP isn't included in the reply from the
authorization or credit-control server. authorization or credit-control server.
FAILOVER_SUPPORTED 1 FAILOVER_SUPPORTED 1
When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the
credit-control message stream SHOULD be moved to an alternative credit-control message stream SHOULD be moved to an alternative
destination in the case of communication failure. Moving the credit- destination in the case of a communication failure. Moving the
control message stream to a backup server MAY require that credit-control message stream to a backup server MAY require that
information related to the credit-control session should also be information related to the credit-control session should also be
forwarded to an alternative server. forwarded to an alternative server.
8.5. CC-Sub-Session-Id AVP 8.5. CC-Sub-Session-Id AVP
The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and
contains the credit-control sub-session identifier. The combination contains the credit-control sub-session identifier. The combination
of the Session-Id and this AVP MUST be unique per sub-session, and of the Session-Id AVP and this AVP MUST be unique per sub-session,
the value of this AVP MUST be monotonically increased by one for all and the value of this AVP MUST be monotonically increased by one for
new sub-sessions. The absence of this AVP implies that no sub- all new sub-sessions. The absence of this AVP implies that no
sessions are in use. sub-sessions are in use.
8.6. Check-Balance-Result AVP 8.6. Check-Balance-Result AVP
The Check Balance Result AVP (AVP Code 422) is of type Enumerated and The Check-Balance-Result AVP (AVP Code 422) is of type Enumerated and
contains the result of the balance check. This AVP is applicable contains the result of the balance check. This AVP is applicable
only when the Requested-Action AVP indicates CHECK_BALANCE in the only when the Requested-Action AVP indicates CHECK_BALANCE in the
Credit-Control-Request command. The following values are defined for Credit-Control-Request command. The following values are defined for
the Check-Balance-Result AVP. the Check-Balance-Result AVP:
ENOUGH_CREDIT 0 ENOUGH_CREDIT 0
There is enough credit in the account to cover the requested service. There is enough credit in the account to cover the requested service.
NO_CREDIT 1 NO_CREDIT 1
There isn't enough credit in the account to cover the requested There isn't enough credit in the account to cover the requested
service. service.
8.7. Cost-Information AVP 8.7. Cost-Information AVP
The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is
used to return the cost information of a service, which the credit- used to return the cost information of a service, which the
control client can transfer transparently to the end user. The credit-control client can transfer transparently to the end user.
included Unit-Value AVP contains the cost estimate (always type of The included Unit-Value AVP contains the cost estimate (always of
money) of the service, in the case of price enquiry, or the type "money") of the service in the case of price inquiries, or the
accumulated cost estimation, in the case of credit-control session. accumulated cost estimation in the case of a credit-control session.
The Currency-Code specifies in which currency the cost was given. The Currency-Code AVP specifies in which currency the cost was given.
The Cost-Unit specifies the unit when the service cost is a cost per The Cost-Unit AVP specifies the unit when the service cost is a cost
unit (e.g., cost for the service is $1 per minute). per unit (e.g., cost for the service is $1 per minute).
When the Requested-Action AVP with value PRICE_ENQUIRY is included in When the Requested-Action AVP with the value PRICE_ENQUIRY is
the Credit-Control-Request command, the Cost-Information AVP sent in included in the Credit-Control-Request command, the Cost-Information
the succeeding Credit-Control-Answer command contains the cost AVP sent in the succeeding Credit-Control-Answer command contains the
estimation of the requested service, without any reservation being cost estimation for the requested service, without any reservations
made. being made.
The Cost-Information AVP included in the Credit-Control-Answer The Cost-Information AVP included in the Credit-Control-Answer
command with the CC-Request-Type set to UPDATE_REQUEST contains the command with the CC-Request-Type set to UPDATE_REQUEST contains the
accumulated cost estimation for the session, without taking any accumulated cost estimation for the session, without taking any
credit reservation into account. credit reservations into account.
The Cost-Information AVP included in the Credit-Control-Answer The Cost-Information AVP included in the Credit-Control-Answer
command with the CC-Request-Type set to EVENT_REQUEST or command with the CC-Request-Type set to EVENT_REQUEST or
TERMINATION_REQUEST contains the estimated total cost for the TERMINATION_REQUEST contains the estimated total cost for the
requested service. requested service.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Cost-Information AVP is defined as follows (per grouped-avp-def
as defined in [RFC6733]):
Cost-Information ::= < AVP Header: 423 > Cost-Information ::= < AVP Header: 423 >
{ Unit-Value } { Unit-Value }
{ Currency-Code } { Currency-Code }
[ Cost-Unit ] [ Cost-Unit ]
8.8. Unit-Value AVP 8.8. Unit-Value AVP
Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the The Unit-Value AVP is of type Grouped (AVP Code 445) and specifies
units as decimal value. The Unit-Value is a value with an exponent; the cost as a floating-point value. The Unit-Value is a significand
i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This with an exponent; i.e., Unit-Value = Value-Digits AVP * 10^Exponent.
representation avoids unwanted rounding off. For example, the value This representation avoids unwanted rounding off. For example, the
of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The value of 2,3 is represented as Value-Digits = 23 and Exponent = -1.
absence of the exponent part MUST be interpreted as an exponent equal The absence of the exponent part MUST be interpreted as an exponent
to zero. equal to zero.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Unit-Value AVP is defined as follows (per grouped-avp-def as
defined in [RFC6733]):
Unit-Value ::= < AVP Header: 445 > Unit-Value ::= < AVP Header: 445 >
{ Value-Digits } { Value-Digits }
[ Exponent ] [ Exponent ]
8.9. Exponent AVP 8.9. Exponent AVP
Exponent AVP is of type Integer32 (AVP Code 429) and contains the The Exponent AVP is of type Integer32 (AVP Code 429) and contains the
exponent value to be applied for the Value-Digit AVP within the Unit- exponent value to be applied for the Value-Digits AVP within the
Value AVP. Unit-Value AVP.
8.10. Value-Digits AVP 8.10. Value-Digits AVP
The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains
the significant digits of the number. If decimal values are needed the significant digits of the number. If decimal values are needed
to present the units, the scaling MUST be indicated with the related to present the units, the scaling MUST be indicated with the related
Exponent AVP. For example, for the monetary amount $ 0.05 the value Exponent AVP. For example, for the monetary amount $0.05, the value
of Value-Digits AVP MUST be set to 5, and the scaling MUST be of the Value-Digits AVP MUST be set to 5, and the scaling MUST be
indicated with the Exponent AVP set to -2. indicated with the Exponent AVP set to -2.
8.11. Currency-Code AVP 8.11. Currency-Code AVP
The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and
contains a currency code that specifies in which currency the values contains a currency code that specifies in which currency the values
of AVPs containing monetary units were given. It is specified by of AVPs containing monetary units were given. It is specified by
using the numeric values defined in the ISO 4217 standard [ISO4217]. using the numeric values defined in the ISO 4217 standard [ISO4217].
8.12. Cost-Unit AVP 8.12. Cost-Unit AVP
The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is
used to display a human readable string to the end user. It used to display a human-readable string to the end user. It
specifies the applicable unit to the Cost-Information when the specifies the applicable unit to the Cost-Information AVP when the
service cost is a cost per unit (e.g., cost of the service is $1 per service cost is a cost per unit (e.g., cost of the service is $1 per
minute). The Cost-Unit can be minutes, hours, days, kilobytes, minute). The Cost-Unit setting can be minutes, hours, days,
megabytes, etc. kilobytes, megabytes, etc.
8.13. Credit-Control AVP 8.13. Credit-Control AVP
The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST
be included in AA requests when the service element has credit- be included in AA-Request messages when the Service Element has
control capabilities. credit-control capabilities. The following values are defined for
the Credit-Control AVP:
CREDIT_AUTHORIZATION 0 CREDIT_AUTHORIZATION 0
If the home Diameter AAA server determines that the user has prepaid If the home Diameter AAA server determines that the user has a
subscription, this value indicates that the credit-control server prepaid subscription, this value indicates that the credit-control
MUST be contacted to perform the first interrogation. The value of server MUST be contacted to perform the first interrogation. The
the Credit-Control AVP MUST always be set to 0 in an AA request sent value of the Credit-Control AVP MUST always be set to 0 in an
to perform the first interrogation and to initiate a new credit- AA-Request sent to perform the first interrogation and to initiate a
control session. new credit-control session.
RE_AUTHORIZATION 1 RE_AUTHORIZATION 1
This value indicates to the Diameter AAA server that a credit-control This value indicates to the Diameter AAA server that a credit-control
session is ongoing for the subscriber and that the 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 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 value of 1 is to be used only when the first interrogation has been
successfully performed and the credit-control session is ongoing successfully performed and the credit-control session is ongoing
(i.e., re-authorization triggered by Authorization-Lifetime). This (i.e., re-authorization triggered by authorization lifetime). This
value MUST NOT be used in an AA request sent to perform the first value MUST NOT be used in an AA-Request sent to perform the first
interrogation. interrogation.
8.14. Credit-Control-Failure-Handling AVP 8.14. Credit-Control-Failure-Handling AVP (CCFH)
The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type The CCFH (AVP Code 427) is of type Enumerated. The credit-control
Enumerated. The credit-control client uses information in this AVP client uses information in this AVP to decide what to do if sending
to decide what to do if sending credit-control messages to the credit-control messages to the credit-control server has been, for
credit-control server has been, for instance, temporarily prevented instance, temporarily prevented due to a network problem. Depending
due to a network problem. Depending on the service logic, the on the service logic, the credit-control server can order the client
credit-control server can order the client to terminate the service to terminate the service immediately when there is a reason to
immediately when there is a reason to believe that the service cannot believe that the service cannot be charged, or to try failover to an
be charged, or to try failover to an alternative server, if possible. alternative server, if possible. The server could then either
Then the server could either terminate or grant the service, should terminate or grant the service, should the alternative connection
the alternative connection also fail. also fail.
TERMINATE 0 The following values are defined for the CCFH:
When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the TERMINATE 0
service MUST only be granted for as long as there is a connection to
the credit-control server. If the credit-control client does not When the CCFH is set to TERMINATE, the service MUST only be granted
receive any Credit-Control-Answer message within the Tx timer (as for as long as there is a connection to the credit-control server.
defined in Section 13), the credit-control request is regarded as If the credit-control client does not receive any Credit-Control-
failed, and the end user's service session is terminated. Answer messages before the Tx timer (as defined in Section 13)
expires, the credit-control request is regarded as failed, and the
end user's service session is terminated.
This is the default behavior if the AVP isn't included in the reply This is the default behavior if the AVP isn't included in the reply
from the authorization or credit-control server. from the authorization or credit-control server.
CONTINUE 1 CONTINUE 1
When the Credit-Control-Failure-Handling AVP is set to CONTINUE, 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 be granted, even if credit-
control messages can't be delivered.
RETRY_AND_TERMINATE 2 When the CCFH is set to CONTINUE, the credit-control client SHOULD
resend the request to an alternative server in the case of transport
or temporary failures, provided that (1) a failover procedure is
supported in the credit-control server and the credit-control client
and (2) an alternative server is available. Otherwise, the service
SHOULD be granted, even if credit-control messages can't be
delivered.
When the Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE 2
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.
8.15. Direct-Debiting-Failure-Handling AVP When the CCFH is set to RETRY_AND_TERMINATE, the credit-control
client SHOULD resend the request to an alternative server in the case
of transport or temporary failures, provided that (1) a failover
procedure is supported in the credit-control server and the
credit-control client and (2) an alternative server is available.
The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type Otherwise, the service SHOULD NOT be granted when the credit-control
Enumerated. The credit-control client uses information in this AVP messages can't be delivered.
to decide what to do if sending credit-control messages (Requested-
Action AVP set to DIRECT_DEBITING) to the credit-control server has
been, for instance, temporarily prevented due to a network problem.
TERMINATE_OR_BUFFER 0 8.15. Direct-Debiting-Failure-Handling AVP (DDFH)
When the Direct-Debiting-Failure-Handling AVP is set to The DDFH (AVP Code 428) is of type Enumerated. The credit-control
TERMINATE_OR_BUFFER, the service MUST be granted for as long as there client uses information in this AVP to decide what to do if sending
is a connection to the credit-control server. If the credit-control credit-control messages (Requested-Action AVP set to DIRECT_DEBITING)
client does not receive any Credit-Control-Answer message within the to the credit-control server has been, for instance, temporarily
Tx timer (as defined in Section 13) the credit-control request is prevented due to a network problem.
regarded as failed. The client SHOULD terminate the service if it
can determine from the failed answer that units have not been
debited. Otherwise the credit-control client SHOULD grant the
service, store the request in application level non-volatile storage,
and try to re-send the request. These requests MUST be marked as
possible duplicates by setting the T-flag in the command header as
described in [RFC6733] section 3. This is the default behavior if
the AVP isn't included in the reply from the authorization server.
CONTINUE 1 The following values are defined for the DDFH:
When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the TERMINATE_OR_BUFFER 0
service SHOULD be granted, even if credit-control messages can't be
delivered, and the request should be deleted. When the DDFH is set to TERMINATE_OR_BUFFER, the service MUST be
granted for as long as there is a connection to the credit-control
server. If the credit-control client does not receive any
Credit-Control-Answer messages before the Tx timer (as defined in
Section 13) expires, the credit-control request is regarded as
failed. The client SHOULD terminate the service if it can determine
from the failed answer that units have not been debited. Otherwise,
the credit-control client SHOULD grant the service, store the request
in application-level non-volatile storage, and try to resend the
request. These requests MUST be marked as possible duplicates by
setting the T flag in the command header as described in [RFC6733],
Section 3. This is the default behavior if the AVP isn't included in
the reply from the authorization server.
CONTINUE 1
When the DDFH is set to CONTINUE, the service SHOULD be granted, even
if credit-control messages can't be delivered, and the request should
be deleted.
8.16. Multiple-Services-Credit-Control AVP 8.16. Multiple-Services-Credit-Control AVP
Multiple-Services-Credit-Control AVP (AVP Code 456) is of type The Multiple-Services-Credit-Control AVP (AVP Code 456) is of type
Grouped and contains the AVPs related to the independent credit- Grouped and contains the AVPs related to the independent
control of multiple services feature. Note that each instance of credit-control of multiple services. Note that each instance of this
this AVP carries units related to one or more services or related to AVP carries units related to one or more services or related to a
a single rating group. single rating-group.
The Service-Identifier and the Rating-Group AVPs are used to The Service-Identifier AVP and the Rating-Group AVP are used to
associate the granted units to a given service or rating group. If associate the granted units to a given service or rating-group. If
both the Service-Identifier and the Rating-Group AVPs are included, both the Service-Identifier AVP and the Rating-Group AVP are
the target of the service units is always the service(s) indicated by included, the target of the service units is always the service(s)
the value of the Service-Identifier AVP(s). If only the Rating- indicated by the value of the Service-Identifier AVP(s). If only the
Group-Id AVP is present, the Multiple-Services-Credit-Control AVP Rating-Group AVP is present, the Multiple-Services-Credit-Control AVP
relates to all the services that belong to the specified rating relates to all the services that belong to the specified
group. rating-group.
The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- The G-S-U-Pool-Reference AVP allows the server to specify a
Pool-Identifier identifying a credit pool within which the units of G-S-U-Pool-Identifier identifying a credit pool within which the
the specified type are considered pooled. If a G-S-U-Pool-Reference units of the specified type are considered pooled. If a G-S-U-Pool-
AVP is present, then actual service units of the specified type MUST Reference AVP is present, then actual service units of the specified
also be present. For example, if the G-S-U-Pool-Reference AVP type MUST also be present. For example, if the G-S-U-Pool-Reference
specifies Unit-Type TIME, then the CC-Time AVP MUST be present. AVP specifies a CC-Unit-Type value of TIME (Section 8.32), then the
CC-Time AVP MUST be present.
The Requested-Service-Unit AVP MAY contain the amount of requested The Requested-Service-Unit AVP MAY contain the amount of requested
service units or the requested monetary value. It MUST be present in service units or the requested monetary value. It MUST be present in
the initial interrogation and within the intermediate interrogations the initial interrogation and within the intermediate interrogations
in which new quota is requested. If the credit-control client does in which a new quota is requested. If the credit-control client does
not include the Requested-Service-Unit AVP in a request command, not include the Requested-Service-Unit AVP in a request command --
because for instance, it has determined that the end-user terminated because, for instance, it has determined that the end user terminated
the service, the server MUST debit the used amount from the user's the service -- the server MUST debit the used amount from the user's
account but MUST NOT return a new quota in the corresponding answer. account but MUST NOT return a new quota in the corresponding answer.
The Validity-Time, Result-Code, and Final-Unit-Indication or QoS- The Validity-Time, Result-Code, and Final-Unit-Indication or
Final-Unit-Indication AVPs MAY be present in an answer command as QoS-Final-Unit-Indication AVPs MAY be present in a Credit-Control-
defined in Section 5.1.2 and Section 5.6 for the graceful service Answer command as defined in Sections 5.1.2 and 5.6 for graceful
termination. service termination.
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are When both the Tariff-Time-Change AVP and the Tariff-Change-Usage AVP
present, the server MUST include two separate instances of the are present, the server MUST include two separate instances of the
Multiple-Services-Credit-Control AVP with the Granted-Service-Unit Multiple-Services-Credit-Control AVP with the Granted-Service-Unit
AVP associated to the same service-identifier and/or rating-group. AVP associated to the same service-identifier and/or rating-group.
Where the two quotas are associated to the same pool or to different Where the two quotas are associated to the same pool or to different
pools, the credit pooling mechanism defined in Section 5.1.2 applies. pools, the credit-pooling mechanism defined in Section 5.1.2 applies.
The Tariff-Change-Usage AVP MUST NOT be included in request commands When the client is reporting used units before and after the tariff
to report used units before, and after tariff time change the Used- time change, it MUST use the Tariff-Change-Usage AVP inside the
Service-Unit AVP MUST be used. Used-Service-Unit AVP.
A server not implementing the independent credit-control of multiple A server not implementing the independent credit-control of multiple
services functionality MUST treat the Multiple-Services-Credit- services MUST treat the Multiple-Services-Credit-Control AVP as an
Control AVP as an invalid AVP. invalid AVP.
The Multiple-Services-Control AVP is defined as follows (per the The Multiple-Services-Credit-Control AVP is defined as follows (per
grouped-avp-def of [RFC6733]): grouped-avp-def as defined in [RFC6733]):
Multiple-Services-Credit-Control ::= < AVP Header: 456 > Multiple-Services-Credit-Control ::= < AVP Header: 456 >
[ Granted-Service-Unit ] [ Granted-Service-Unit ]
[ Requested-Service-Unit ] [ Requested-Service-Unit ]
*[ Used-Service-Unit ] *[ Used-Service-Unit ]
[ Tariff-Change-Usage ] [ Tariff-Change-Usage ]
*[ Service-Identifier ] *[ Service-Identifier ]
[ Rating-Group ] [ Rating-Group ]
*[ G-S-U-Pool-Reference ] *[ G-S-U-Pool-Reference ]
[ Validity-Time ] [ Validity-Time ]
[ Result-Code ] [ Result-Code ]
[ Final-Unit-Indication ] [ Final-Unit-Indication ]
[ QoS-Final-Unit-Indication ] [ QoS-Final-Unit-Indication ]
*[ AVP ] *[ AVP ]
8.17. Granted-Service-Unit AVP 8.17. Granted-Service-Unit AVP
Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and The Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and
contains the amount of units that the Diameter credit-control client contains the amount of units that the Diameter Credit-Control client
can provide to the end user until the service must be released or the can provide to the end user until the service must be released or the
new Credit-Control-Request must be sent. A client is not required to new Credit-Control-Request must be sent. A client is not required to
implement all the unit types, and it must treat unknown or implement all the unit types, and it must treat unknown or
unsupported unit types in the answer message as an incorrect CCA unsupported unit types in the Answer message as an incorrect CCA. In
answer. In this case, the client MUST terminate the credit-control this case, the client MUST terminate the credit-control session and
session and indicate in the Termination-Cause AVP reason indicate the reason as DIAMETER_BAD_ANSWER in the Termination-Cause
DIAMETER_BAD_ANSWER. AVP.
The Granted-Service-Unit AVP is defined as follows (per the grouped- The Granted-Service-Unit AVP is defined as follows (per
avp-def of [RFC6733]): grouped-avp-def as defined in [RFC6733]):
Granted-Service-Unit ::= < AVP Header: 431 > Granted-Service-Unit ::= < AVP Header: 431 >
[ Tariff-Time-Change ] [ Tariff-Time-Change ]
[ CC-Time ] [ CC-Time ]
[ CC-Money ] [ CC-Money ]
[ CC-Total-Octets ] [ CC-Total-Octets ]
[ CC-Input-Octets ] [ CC-Input-Octets ]
[ CC-Output-Octets ] [ CC-Output-Octets ]
[ CC-Service-Specific-Units ] [ CC-Service-Specific-Units ]
*[ AVP ] *[ AVP ]
8.18. Requested-Service-Unit AVP 8.18. Requested-Service-Unit AVP
The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and
contains the amount of requested units specified by the Diameter contains the amount of requested units specified by the Diameter
credit-control client. A server is not required to implement all the Credit-Control client. A server is not required to implement all the
unit types, and it must treat unknown or unsupported unit types as unit types, and it must treat unknown or unsupported unit types as
invalid AVPs. invalid AVPs.
The Requested-Service-Unit AVP is defined as follows (per the The Requested-Service-Unit AVP is defined as follows (per
grouped-avp-def of [RFC6733]): grouped-avp-def as defined in [RFC6733]):
Requested-Service-Unit ::= < AVP Header: 437 > Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ] [ CC-Time ]
[ CC-Money ] [ CC-Money ]
[ CC-Total-Octets ] [ CC-Total-Octets ]
[ CC-Input-Octets ] [ CC-Input-Octets ]
[ CC-Output-Octets ] [ CC-Output-Octets ]
[ CC-Service-Specific-Units ] [ CC-Service-Specific-Units ]
*[ AVP ] *[ AVP ]
8.19. Used-Service-Unit AVP 8.19. Used-Service-Unit AVP
The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and
contains the amount of used units measured from the point when the contains the amount of used units measured from the point when the
service became active or, if interim interrogations are used during service became active or, if interim interrogations are used during
the session, from the point when the previous measurement ended. the session, from the point when the previous measurement ended.
Note: The values reported in a Used-Service-Unit AVP does not Note: The value reported in a Used-Service-Unit AVP is not
necessarily have a relation to the grant provided in a Granted- necessarily related to the grant provided in a Granted-Service-Unit
Service-Unit AVP, e.g., the value in this AVP may exceed the value in AVP, e.g., the value in this AVP may exceed the value in the grant.
the grant.
The Used-Service-Unit AVP is defined as follows (per the grouped-avp- The Used-Service-Unit AVP is defined as follows (per grouped-avp-def
def of [RFC6733]): as defined in [RFC6733]):
Used-Service-Unit ::= < AVP Header: 446 > Used-Service-Unit ::= < AVP Header: 446 >
[ Tariff-Change-Usage ] [ Tariff-Change-Usage ]
[ CC-Time ] [ CC-Time ]
[ CC-Money ] [ CC-Money ]
[ CC-Total-Octets ] [ CC-Total-Octets ]
[ CC-Input-Octets ] [ CC-Input-Octets ]
[ CC-Output-Octets ] [ CC-Output-Octets ]
[ CC-Service-Specific-Units ] [ CC-Service-Specific-Units ]
*[ AVP ] *[ AVP ]
8.20. Tariff-Time-Change AVP 8.20. Tariff-Time-Change AVP
The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is
sent from the server to the client and includes the time in seconds sent from the server to the client and includes the time in seconds
since January 1, 1900, 00:00 UTC, when the tariff of the service will since January 1, 1900, 00:00 UTC, when the tariff of the service will
be changed. be changed.
The tariff change mechanism is optional for the client and server, The tariff change mechanism is optional for the client and server,
and it is not used for time-based services defined in Section 5. If and it is not used for time-based services (Section 5). If a client
a client does not support the tariff time change mechanism, it MUST does not support the tariff time change mechanism, it MUST treat the
treat Tariff-Time-Change AVP in the answer message as an incorrect Tariff-Time-Change AVP in the Answer message as an incorrect CCA. In
CCA answer. In this case, the client terminates the credit-control this case, the client terminates the credit-control session and
session and indicates in the Termination-Cause AVP reason indicates the reason as DIAMETER_BAD_ANSWER in the Termination-Cause
DIAMETER_BAD_ANSWER. AVP.
Omission of this AVP means that no tariff change is to be reported. Omission of this AVP means that no tariff change is to be reported.
8.21. CC-Time AVP 8.21. CC-Time AVP
The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates
the length of the requested, granted, or used time in seconds. the length of the requested, granted, or used time in seconds.
8.22. CC-Money AVP 8.22. CC-Money AVP
The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the
monetary amount in the given currency. The Currency-Code AVP SHOULD monetary amount in the given currency. The Currency-Code AVP SHOULD
be included. It is defined as follows (per the grouped-avp-def of be included. The CC-Money AVP is defined as follows (per
[RFC6733]): grouped-avp-def as defined in [RFC6733]):
CC-Money ::= < AVP Header: 413 > CC-Money ::= < AVP Header: 413 >
{ Unit-Value } { Unit-Value }
[ Currency-Code ] [ Currency-Code ]
8.23. CC-Total-Octets AVP 8.23. CC-Total-Octets AVP
The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and
contains the total number of requested, granted, or used octets contains the total number of requested, granted, or used octets
regardless of the direction (sent or received). regardless of the direction (sent or received).
8.24. CC-Input-Octets AVP 8.24. CC-Input-Octets AVP
The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can contains the number of requested, granted, or used octets that
be/have been received from the end user. can be / have been received from the end user.
8.25. CC-Output-Octets AVP 8.25. CC-Output-Octets AVP
The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can contains the number of requested, granted, or used octets that
be/have been sent to the end user. can be / have been sent to the end user.
8.26. CC-Service-Specific-Units AVP 8.26. CC-Service-Specific-Units AVP
The CC-Service-Specific-Units AVP (AVP Code 417) is of type The CC-Service-Specific-Units AVP (AVP Code 417) is of type
Unsigned64 and specifies the number of service-specific units (e.g., Unsigned64 and specifies the number of service-specific units (e.g.,
number of events, points) given in a selected service. The service- number of events, points) given in a selected service. The service-
specific units always refer to the service identified in the Service- specific units always refer to the service identified in the Service-
Identifier AVP (or Rating-Group AVP when the Multiple-Services- Identifier AVP (or Rating-Group AVP when the Multiple-Services-
Credit-Control AVP is used). Credit-Control AVP is used).
8.27. Tariff-Change-Usage AVP 8.27. Tariff-Change-Usage AVP
The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and
defines whether units are used before or after a tariff change, or defines whether units are used before or after a tariff change, or
whether the units straddled a tariff change during the reporting whether the units straddled a tariff change during the reporting
period. Omission of this AVP means that no tariff change has period. Omission of this AVP means that no tariff change has
occurred. occurred.
In addition, when present in answer messages as part of the Multiple- In addition, when present in Answer messages as part of the Multiple-
Services-Credit-Control AVP, this AVP defines whether units are Services-Credit-Control AVP, this AVP defines whether units are
allocated to be used before or after a tariff change event. allocated to be used before or after a tariff change event.
When the Tariff-Time-Change AVP is present, omission of this AVP in When the Tariff-Time-Change AVP is present, omission of this AVP in
answer messages means that the single quota mechanism applies. Answer messages means that the single-quota mechanism applies.
Tariff-Change-Usage can be one of the following: Tariff-Change-Usage can be set to one of the following values:
UNIT_BEFORE_TARIFF_CHANGE 0 UNIT_BEFORE_TARIFF_CHANGE 0
When present in the Multiple-Services-Credit-Control AVP, this value When present in the Multiple-Services-Credit-Control AVP, this value
indicates the amount of the units allocated for use before a tariff indicates the amount of units allocated for use before a tariff
change occurs. change occurs.
When present in the Used-Service-Unit AVP, this value indicates the When present in the Used-Service-Unit AVP, this value indicates the
amount of resource units used before a tariff change had occurred. amount of resource units used before a tariff change had occurred.
UNIT_AFTER_TARIFF_CHANGE 1 UNIT_AFTER_TARIFF_CHANGE 1
When present in the Multiple-Services-Credit-Control AVP, this value When present in the Multiple-Services-Credit-Control AVP, this value
indicates the amount of the units allocated for use after a tariff indicates the amount of units allocated for use after a tariff change
change occurs. occurs.
When present in the Used-Service-Unit AVP, this value indicates the When present in the Used-Service-Unit AVP, this value indicates the
amount of resource units used after tariff change had occurred. amount of resource units used after a tariff change had occurred.
UNIT_INDETERMINATE 2 UNIT_INDETERMINATE 2
The used unit contains the amount of units that straddle the tariff This value is to be used only in the Used-Service-Unit AVP and
indicates the amount of resource units that straddle the tariff
change (e.g., the metering process reports to the credit-control change (e.g., the metering process reports to the credit-control
client in blocks of n octets, and one block straddled the tariff client in blocks of n octets, and one block straddled the tariff
change). This value is to be used only in the Used-Service-Unit AVP. change).
8.28. Service-Identifier AVP 8.28. Service-Identifier AVP
The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and
contains the identifier of a service. The specific service the contains the identifier of a service. The specific service the
request relates to is uniquely identified by the combination of request relates to is uniquely identified by the combination of the
Service-Context-Id and Service-Identifier AVPs. Service-Context-Id AVP and the Service-Identifier AVP.
A usage example of this AVP is illustrated in Appendix B.9. A usage example of this AVP is illustrated in Appendix A.9.
8.29. Rating-Group AVP 8.29. Rating-Group AVP
The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and
contains the identifier of a rating group. All the services subject contains the identifier of a rating-group. All the services subject
to the same rating type are part of the same rating group. The to the same rating type are part of the same rating-group. The
specific rating group the request relates to is uniquely identified specific rating-group the request relates to is uniquely identified
by the combination of Service-Context-Id and Rating-Group AVPs. by the combination of the Service-Context-Id AVP and the Rating-Group
AVP.
A usage example of this AVP is illustrated in Appendix B.9. A usage example of this AVP is illustrated in Appendix A.9.
8.30. G-S-U-Pool-Reference AVP 8.30. G-S-U-Pool-Reference AVP
The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It
is used in the Credit-Control-Answer message, and associates the is used in the Credit-Control-Answer message and associates the
Granted-Service-Unit AVP within which it appears with a credit pool Granted-Service-Unit AVP within which it appears with a credit pool
within the session. within the session.
The G-S-U-Pool-Identifier AVP specifies the credit pool from which The G-S-U-Pool-Identifier AVP specifies the credit pool from which
credit is drawn for this unit type. credit is drawn for this unit type.
The CC-Unit-Type AVP specifies the type of units for which credit is The CC-Unit-Type AVP specifies the type of units for which credit is
pooled. pooled.
The Unit-Value AVP specifies the multiplier, which converts between The Unit-Value AVP specifies the multiplier, which converts between
service units of type CC-Unit-Type and abstract service units within service units of type CC-Unit-Type and abstract service units within
the credit pool (and thus to service units of any other service or the credit pool (and thus to service units of any other services or
rating group associated with the same pool). rating-groups associated with the same pool).
The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- The G-S-U-Pool-Reference AVP is defined as follows (per
avp-def of [RFC6733]): grouped-avp-def as defined in [RFC6733]):
G-S-U-Pool-Reference ::= < AVP Header: 457 > G-S-U-Pool-Reference ::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier } { G-S-U-Pool-Identifier }
{ CC-Unit-Type } { CC-Unit-Type }
{ Unit-Value } { Unit-Value }
8.31. G-S-U-Pool-Identifier AVP 8.31. G-S-U-Pool-Identifier AVP
The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32
and identifies a credit pool within the session. and identifies a credit pool within the session.
8.32. CC-Unit-Type AVP 8.32. CC-Unit-Type AVP
The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and
specifies the type of units considered to be pooled into a credit specifies the type of units considered to be pooled into a
pool. credit pool.
The following values are defined for the CC-Unit-Type AVP: The following values are defined for the CC-Unit-Type AVP:
TIME 0 TIME 0
MONEY 1 MONEY 1
TOTAL-OCTETS 2 TOTAL-OCTETS 2
INPUT-OCTETS 3 INPUT-OCTETS 3
OUTPUT-OCTETS 4 OUTPUT-OCTETS 4
SERVICE-SPECIFIC-UNITS 5 SERVICE-SPECIFIC-UNITS 5
8.33. Validity-Time AVP 8.33. Validity-Time AVP
The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is
sent from the credit-control server to the credit-control client. sent from the credit-control server to the credit-control client.
The AVP contains the validity time of the granted service units. The The Validity-Time AVP contains the validity time of the granted
measurement of the Validity-Time is started upon receipt of the service units. The measurement of the Validity-Time is started upon
Credit-Control-Answer Message containing this AVP. If the granted receipt of the Credit-Control-Answer message containing this AVP. If
service units have not been consumed within the validity time the granted service units have not been consumed within the validity
specified in this AVP, the credit-control client MUST send a Credit- time specified in this AVP, the credit-control client MUST send a
Control-Request message to the server, with CC-Request-Type set to Credit-Control-Request message to the server, with CC-Request-Type
UPDATE_REQUEST. The value field of the Validity-Time AVP is given in set to UPDATE_REQUEST. The value field of the Validity-Time AVP is
seconds. given in seconds.
The Validity-Time AVP is also used for the graceful service The Validity-Time AVP is also used for graceful service termination
termination (see Section 5.6) to indicate to the credit-control (see Section 5.6) to indicate to the credit-control client how long
client how long the subscriber is allowed to use network resources the subscriber is allowed to use network resources after the
after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) specified action (i.e., REDIRECT or RESTRICT_ACCESS) started. When
started. When the Validity-Time elapses, a new intermediate the Validity-Time elapses, a new intermediate interrogation is sent
interrogation is sent to the server. to the server.
8.34. Final-Unit-Indication AVP 8.34. Final-Unit-Indication AVP
The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and
indicates that the Granted-Service-Unit AVP in the Credit-Control- indicates that the Granted-Service-Unit AVP in the Credit-Control-
Answer, or in the AA answer, contains the final units for the Answer or in the AA-Answer contains the final units for the service.
service. After these units have expired, the Diameter credit-control After these units have expired, the Diameter Credit-Control client is
client is responsible for executing the action indicated in the responsible for executing the action indicated in the Final-Unit-
Final-Unit-Action AVP (see Section 5.6). Action AVP (see Section 5.6).
If more than one unit type is received in the Credit-Control-Answer, If more than one unit type is received in the Credit-Control-Answer,
the unit type that first expired SHOULD cause the credit-control the unit type that first expired SHOULD cause the credit-control
client to execute the specified action. client to execute the specified action.
In the first interrogation, the Final-Unit-Indication AVP with Final- In the first interrogation, the Final-Unit-Indication AVP with
Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also be
Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA present with no Granted-Service-Unit AVP in the Credit-Control-Answer
answer. This indicates to the Diameter credit-control client to or in the AA-Answer. This indicates to the Diameter Credit-Control
execute the specified action immediately. If the home service client that the client is to execute the specified action
provider policy is to terminate the service, naturally, the server immediately. If the home service provider policy is to terminate the
SHOULD return the appropriate transient failure (see Section 9.1) in service, naturally, the server SHOULD return the appropriate
order to implement the policy-defined action. transient failure (see Section 9.1) in order to implement the policy-
defined action.
The Final-Unit-Action AVP defines the behavior of the service element The Final-Unit-Action AVP defines the behavior of the Service Element
when the user's account cannot cover the cost of the service and MUST when the user's account cannot cover the cost of the service and MUST
always be present if the Final-Unit-Indication AVP is included in a always be present if the Final-Unit-Indication AVP is included in a
command. command.
If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit- If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit-
Indication group MUST NOT contain any other AVPs. Indication group AVP MUST NOT contain any other AVPs.
If the Final-Unit-Action AVP is set to REDIRECT at least one of the If the Final-Unit-Action AVP is set to REDIRECT, the Redirect-Server
Redirect-Server and Redirect-Server-Extension AVPs MUST be present. AVP or the Redirect-Server-Extension AVP (at least one) MUST be
The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be
in the Credit-Control-Answer message if the user is also allowed to present in the Credit-Control-Answer message if the user is also
access other services that are not accessible through the address allowed to access other services that are not accessible through the
given in the Redirect-Server AVP. address given in the Redirect-Server AVP.
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the
Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be The Filter-Id AVP is defined in [RFC7155]. The Filter-Id AVP can be
used to reference an IP filter list installed in the access device by used to reference an IP filter list installed in the access device by
means other than the Diameter credit-control application, e.g., means other than the Diameter Credit-Control application, e.g.,
locally configured or configured by another entity. locally configured or configured by another entity.
If the Final-Unit-Action AVP is set to REDIRECT and the type of If the Final-Unit-Action AVP is set to REDIRECT and the type of
server is not one of the enumerations in the Redirect-Address-Type server is not one of the enumerations in the Redirect-Address-Type
AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together
with the Redirect-Server-Extension AVP instead of the Final-Unit- with the Redirect-Server-Extension AVP instead of the Final-Unit-
Indication AVP. Indication AVP.
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
and the classification of the restricted traffic cannot be expressed and the classification of the restricted traffic cannot be expressed
using IPFilterRule, or different actions (e.g., QoS) than just using an IPFilterRule, or if actions (e.g., QoS) other than just
allowing traffic needs to be enforced, then the QoS-Final-Unit- allowing traffic need to be enforced, then the QoS-Final-Unit-
Indication AVP SHOULD be used instead of the Final-Unit-Indication Indication AVP SHOULD be used instead of the Final-Unit-Indication
AVP. However, if the credit-control server wants to preserve AVP. However, if the credit-control server wants to preserve
backward compatibility with credit-control clients that support only backward compatibility with credit-control clients that support only
[RFC4006], the Final-Unit-Indication AVP SHOULD be used together with [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with
the Filter-Id AVP. the Filter-Id AVP.
The Final-Unit-Indication AVP is defined as follows (per the grouped- The Final-Unit-Indication AVP is defined as follows (per
avp-def of [RFC6733]): grouped-avp-def as defined in [RFC6733]):
Final-Unit-Indication ::= < AVP Header: 430 > Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action } { Final-Unit-Action }
*[ Restriction-Filter-Rule ] *[ Restriction-Filter-Rule ]
*[ Filter-Id ] *[ Filter-Id ]
[ Redirect-Server ] [ Redirect-Server ]
8.35. Final-Unit-Action AVP 8.35. Final-Unit-Action AVP
The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and
indicates to the credit-control client the action to be taken when indicates to the credit-control client the action to be taken when
the user's account cannot cover the service cost. the user's account cannot cover the service cost.
The Final-Unit-Action can be one of the following: Final-Unit-Action can be set to one of the following values:
TERMINATE 0 TERMINATE 0
The credit-control client MUST terminate the service session. This The credit-control client MUST terminate the service session. This
is the default handling, applicable whenever the credit-control is the default handling, applicable whenever the credit-control
client receives an unsupported Final-Unit-Action value, and it MUST client receives an unsupported Final-Unit-Action value, and it MUST
be supported by all the Diameter credit-control client be supported by all the Diameter Credit-Control client
implementations conforming to this specification. implementations conforming to this specification.
REDIRECT 1 REDIRECT 1
The service element MUST redirect the user to the address specified The Service Element MUST redirect the user to the address specified
in the Redirect-Server-Address AVP or one of the AVPs included in the in the Redirect-Server-Address AVP or one of the AVPs included in the
Redirect-Server-Extension AVP. The redirect action is defined in Redirect-Server-Extension AVP. The redirect action is defined in
Section 5.6.2. Section 5.6.2.
RESTRICT_ACCESS 2 RESTRICT_ACCESS 2
The access device MUST restrict the user access according to the
filter AVPs contained in the applied grouped AVP: according to IP The access device MUST restrict the user's access according to the
filter AVPs contained in the applied Grouped AVP: according to IP
packet filters defined in the Restriction-Filter-Rule AVP, according packet filters defined in the Restriction-Filter-Rule AVP, according
to the packet classifier filters defined in Filter-Rule AVP, or to the packet classifier filters defined in the Filter-Rule AVP, or
according to the packet filters identified by the Filter-Id AVP. All according to the packet filters identified by the Filter-Id AVP. All
the packets not matching any filters MUST be dropped (see of the packets not matching any restriction filters (see
Section 5.6.3). Section 5.6.3) MUST be dropped.
8.36. Restriction-Filter-Rule AVP 8.36. Restriction-Filter-Rule AVP
The Restriction-Filter-Rule AVP (AVP Code 438) is of type The Restriction-Filter-Rule AVP (AVP Code 438) is of type
IPFilterRule and provides filter rules corresponding to services that IPFilterRule and provides filter rules corresponding to services that
are to remain accessible even if there are no more service units are to remain accessible even if there are no more service units
granted. The access device has to configure the specified filter granted. The access device has to configure the specified filter
rules for the subscriber and MUST drop all the packets not matching rules for the subscriber and MUST drop all the packets not matching
these filters. Zero, one, or more such AVPs MAY be present in a these filters. Zero, one, or more such AVPs MAY be present in a
Credit-Control-Answer message or in an AA answer message. Credit-Control-Answer message or in an AA-Answer message.
8.37. Redirect-Server AVP 8.37. Redirect-Server AVP
The Redirect-Server AVP (AVP Code 434) is of type Grouped and The Redirect-Server AVP (AVP Code 434) is of type Grouped and
contains the address information of the redirect server (e.g., HTTP contains the address information of the redirect server (e.g., HTTP
redirect server, SIP Server) with which the end user is to be redirect server, SIP Server) with which the end user is to be
connected when the account cannot cover the service cost. It MUST be connected when the account cannot cover the service cost. It MUST be
present when the Final-Unit-Action AVP is set to REDIRECT. present when the Final-Unit-Action AVP is set to REDIRECT.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Redirect-Server AVP is defined as follows (per grouped-avp-def as
defined in [RFC6733]):
Redirect-Server ::= < AVP Header: 434 > Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type } { Redirect-Address-Type }
{ Redirect-Server-Address } { Redirect-Server-Address }
8.38. Redirect-Address-Type AVP 8.38. Redirect-Address-Type AVP
The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated
and defines the address type of the address given in the Redirect- and defines the address type of the address given in the Redirect-
Server-Address AVP. Server-Address AVP.
The address type can be one of the following: Redirect-Address-Type can be set to one of the following values:
IPv4 Address 0 IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address, as The address type is in the form of a "dotted-decimal" IPv4 address,
defined in [RFC0791]. as defined in [RFC791].
IPv6 Address 1 IPv6 Address 1
The address type is in the form of IPv6 address, as defined in
[RFC4291]. The address MUST conform to the text representation of The address type is in the form of an IPv6 address, as defined in
[RFC4291]. The address MUST conform to the textual representation of
the address according to [RFC5952]. the address according to [RFC5952].
Because [RFC5952] is more restrictive than the RFC3513 format Because [RFC5952] is more restrictive than the "RFC 3513" format
required by [RFC4006], some legacy implementations may not be required by [RFC4006], some legacy implementations may not be
compliant with the new requirements. Accordingly, implementations compliant with the new requirements. Accordingly, implementations
receiving this AVP MAY be liberal in the textual IPv6 representations receiving this AVP MAY be liberal in the textual IPv6 representations
that are accepted without raising an error. that are accepted, without raising an error.
URL 2 URL 2
The address type is in the form of Uniform Resource Locator, as The address type is in the form of a Uniform Resource Locator, as
defined in [RFC3986]. defined in [RFC3986].
SIP URI 3 SIP URI 3
The address type is in the form of SIP Uniform Resource Identifier, The address type is in the form of a SIP Uniform Resource Identifier,
as defined in [RFC3261]. as defined in [RFC3261].
8.39. Redirect-Server-Address AVP 8.39. Redirect-Server-Address AVP
The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String
and defines the address of the redirect server (e.g., HTTP redirect and defines the address of the redirect server (e.g., HTTP redirect
server, SIP Server) with which the end user is to be connected when server, SIP Server) with which the end user is to be connected when
the account cannot cover the service cost. the account cannot cover the service cost.
8.40. Multiple-Services-Indicator AVP 8.40. Multiple-Services-Indicator AVP
The Multiple-Services-Indicator AVP (AVP Code 455) is of type The Multiple-Services-Indicator AVP (AVP Code 455) is of type
Enumerated and indicates whether the Diameter credit-control client Enumerated and indicates whether the Diameter Credit-Control client
is capable of handling multiple services independently within a is capable of handling multiple services independently within a
(sub-) session. The absence of this AVP means that independent (sub-)session. The absence of this AVP means that independent
credit-control of multiple services is not supported. credit-control of multiple services is not supported.
A server not implementing the independent credit-control of multiple A server not implementing the independent credit-control of multiple
services MUST treat the Multiple-Services-Indicator AVP as an invalid services MUST treat the Multiple-Services-Indicator AVP as an
AVP. invalid AVP.
The following values are defined for the Multiple-Services-Indicator The following values are defined for the Multiple-Services-Indicator
AVP: AVP:
MULTIPLE_SERVICES_NOT_SUPPORTED 0 MULTIPLE_SERVICES_NOT_SUPPORTED 0
Client does not support independent credit-control of multiple The client does not support independent credit-control of multiple
services within a (sub-)session. services within a (sub-)session.
MULTIPLE_SERVICES_SUPPORTED 1 MULTIPLE_SERVICES_SUPPORTED 1
Client supports independent credit-control of multiple services
The client supports independent credit-control of multiple services
within a (sub-)session. within a (sub-)session.
8.41. Requested-Action AVP 8.41. Requested-Action AVP
The Requested-Action AVP (AVP Code 436) is of type Enumerated and The Requested-Action AVP (AVP Code 436) is of type Enumerated and
contains the requested action being sent by Credit-Control-Request contains the requested action being sent in a Credit-Control-Request
command where the CC-Request-Type is set to EVENT_REQUEST. The command where the CC-Request-Type is set to EVENT_REQUEST. The
following values are defined for the Requested-Action AVP: following values are defined for the Requested-Action AVP:
DIRECT_DEBITING 0 DIRECT_DEBITING 0
This indicates a request to decrease the end user's account according This indicates a request to decrease the end user's account according
to information specified in the Requested-Service-Unit AVP and/or to information specified in the Requested-Service-Unit AVP and/or
Service-Identifier AVP (additional rating information may be included Service-Identifier AVP (additional rating information may be included
in service-specific AVPs or in the Service-Parameter-Info AVP). The in service-specific AVPs or in the Service-Parameter-Info AVP). The
Granted-Service-Unit AVP in the Credit-Control-Answer command Granted-Service-Unit AVP in the Credit-Control-Answer command
contains the debited units. contains the debited units.
REFUND_ACCOUNT 1 REFUND_ACCOUNT 1
This indicates a request to increase the end user's account according This indicates a request to increase the end user's account according
to information specified in the Requested-Service-Unit AVP and/or to information specified in the Requested-Service-Unit AVP and/or
Service-Identifier AVP (additional rating information may be included Service-Identifier AVP (additional rating information may be included
in service-specific AVPs or in the Service-Parameter-Info AVP). The in service-specific AVPs or in the Service-Parameter-Info AVP). The
Granted-Service-Unit AVP in the Credit-Control-Answer command Granted-Service-Unit AVP in the Credit-Control-Answer command
contains the refunded units. contains the refunded units.
CHECK_BALANCE 2 CHECK_BALANCE 2
This indicates a balance check request. In this case, the checking This indicates a balance-check request. In this case, the checking
of the account balance is done without any credit reservation from of the account balance is done without any credit reservations from
the account. The Check-Balance-Result AVP in the Credit-Control- the account. The Check-Balance-Result AVP in the Credit-Control-
Answer command contains the result of the balance check. Answer command contains the result of the balance check.
PRICE_ENQUIRY 3 PRICE_ENQUIRY 3
This indicates a price enquiry request. In this case, neither This indicates a price-inquiry request. In this case, neither
checking of the account balance nor reservation from the account will checking of the account balance nor reservation from the account will
be done; only the price of the service will be returned in the Cost- be done; only the price of the service will be returned in the
Information AVP in the Credit-Control-Answer Command. Cost-Information AVP in the Credit-Control-Answer command.
8.42. Service-Context-Id AVP 8.42. Service-Context-Id AVP
The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and
contains a unique identifier of the Diameter credit-control service- contains a unique identifier of the Diameter Credit-Control service-
specific document that applies to the request (as defined in specific document (as defined in Section 4.1.2) that applies to the
Section 4.1.2). This is an identifier allocated by the service request. This is an identifier allocated by the service provider,
provider, by the service element manufacturer, or by a the Service Element manufacturer, or a standardization body, and MUST
standardization body, and MUST uniquely identify a given Diameter uniquely identify a given Diameter Credit-Control service-specific
credit-control service-specific document. The format of the Service- document. The format of the Service-Context-Id is:
Context-Id is:
"service-context" "@" "domain" "service-context" "@" "domain"
service-context = Token service-context = Token
The Token is an arbitrary string of characters and digits. The Token is an arbitrary string of characters and digits.
'domain' represents the entity that allocated the Service-Context-Id. "domain" represents the entity that allocated the Service-Context-Id.
It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by It can be ietf.org, 3gpp.org, etc. if the identifier is allocated by
a standardization body, or it can be the FQDN of the service provider a standardization body, or it can be the Fully Qualified Domain Name
(e.g., provider.example.com) or of the vendor (e.g., (FQDN) of the service provider (e.g., provider.example.com) or the
vendor.example.com) if the identifier is allocated by a private vendor (e.g., vendor.example.com) if the identifier is allocated by a
entity. private entity.
This AVP SHOULD be placed as close to the Diameter header as This AVP SHOULD be placed as close to the Diameter header as
possible. possible.
Service-specific documents that are for private use only (i.e., to Service-specific documents that are for private use only (i.e., for
one provider's own use, where no interoperability is deemed useful) one provider's own use, where no interoperability is deemed useful)
may define private identifiers without need of coordination. may define private identifiers without a need for coordination.
However, when interoperability is wanted, coordination of the However, when interoperability is desired, coordination of the
identifiers via, for example, publication of an informational RFC is identifiers via, for example, publication of an informational RFC is
RECOMMENDED in order to make Service-Context-Id globally available. RECOMMENDED in order to make the Service-Context-Id AVP globally
available.
8.43. Service-Parameter-Info AVP 8.43. Service-Parameter-Info AVP
The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and
contains service-specific information used for price calculation or contains service-specific information used for price calculation or
rating. The Service-Parameter-Type AVP defines the service parameter rating. The Service-Parameter-Type AVP defines the service parameter
type, and the Service-Parameter-Value AVP contains the parameter type, and the Service-Parameter-Value AVP contains the parameter
value. The actual contents of these AVPs are not within the scope of value. The actual contents of these AVPs are not within the scope of
this document and SHOULD be defined in another Diameter application, this document and SHOULD be defined in another Diameter application,
in standards written by other standardization bodies, or in service- in standards written by other standardization bodies, or in service-
specific documentation. specific documentation.
In the case of an unknown service request (e.g., unknown Service- In the case of an unknown service request (e.g., unknown Service-
Parameter-Type), the corresponding answer message MUST contain the Parameter-Type), the corresponding Answer message MUST contain the
error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message
with this error MUST contain one or more Failed-AVP AVPs containing with this error MUST contain one or more Failed-AVP AVPs containing
the Service-Parameter-Info AVPs that caused the failure. the Service-Parameter-Info AVPs that caused the failure.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Service-Parameter-Info AVP is defined as follows (per
grouped-avp-def as defined in [RFC6733]):
Service-Parameter-Info ::= < AVP Header: 440 > Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type } { Service-Parameter-Type }
{ Service-Parameter-Value } { Service-Parameter-Value }
8.44. Service-Parameter-Type AVP 8.44. Service-Parameter-Type AVP
The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441)
and defines the type of the service event specific parameter (e.g., and defines the type of the service-event-specific parameter (e.g.,
it can be the end-user location or service name). The different it can be the end-user location or service name). The different
parameters and their types are service-specific, and the meanings of parameters and their types are service specific, and the meanings of
these parameters are not defined in this document. Whoever allocates these parameters are not defined in this document. Whoever allocates
the Service-Context-Id (i.e., unique identifier of a service-specific the Service-Context-Id (i.e., a unique identifier of a service-
document) is also responsible for assigning Service-Parameter-Type specific document) is also responsible for assigning Service-
values for the service and ensuring their uniqueness within the given Parameter-Type values for the service and ensuring their uniqueness
service. The Service-Parameter-Value AVP contains the value within the given service. The Service-Parameter-Value AVP contains
associated with the service parameter type. the value associated with the service parameter type.
8.45. Service-Parameter-Value AVP 8.45. Service-Parameter-Value AVP
The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) The Service-Parameter-Value AVP is of type OctetString (AVP Code 442)
and contains the value of the service parameter type. and contains the value of the service parameter type.
8.46. Subscription-Id AVP 8.46. Subscription-Id AVP
The Subscription-Id AVP (AVP Code 443) is used to identify the end The Subscription-Id AVP (AVP Code 443) is used to identify the
user's subscription and is of type Grouped. The Subscription-Id AVP end user's subscription and is of type Grouped. The Subscription-Id
includes a Subscription-Id-Data AVP that holds the identifier and a AVP includes a Subscription-Id-Data AVP that holds the identifier and
Subscription-Id-Type AVP that defines the identifier type. a Subscription-Id-Type AVP that defines the identifier type.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Subscription-Id AVP is defined as follows (per grouped-avp-def as
defined in [RFC6733]):
Subscription-Id ::= < AVP Header: 443 > Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type } { Subscription-Id-Type }
{ Subscription-Id-Data } { Subscription-Id-Data }
8.47. Subscription-Id-Type AVP 8.47. Subscription-Id-Type AVP
The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated,
and it is used to determine which type of identifier is carried by and it is used to determine which type of identifier is carried by
the Subscription-Id AVP. the Subscription-Id AVP.
This specification defines the following subscription identifiers. This specification defines the following subscription identifiers.
However, new Subscription-Id-Type values can be assigned by IANA as However, new Subscription-Id-Type values can be assigned by IANA as
defined in Section 12. A server MUST implement all the Subscription- defined in Section 12. A server MUST implement all the Subscription-
Id-Types required to perform credit authorization for the services it Id-Type values required to perform credit authorization for the
supports, including possible future values. Unknown or unsupported services it supports, including possible future values. Unknown or
Subscription-Id-Types MUST be treated according to the 'M' flag rule, unsupported Subscription-Id-Type values MUST be treated according to
as defined in [RFC6733]. the 'M' flag rule, as defined in [RFC6733].
END_USER_E164 0 END_USER_E164 0
The identifier is in international E.164 format (e.g., MSISDN), The identifier is in international E.164 format (e.g., MSISDN),
according to the ITU-T E.164 numbering plan defined in [E164] and according to the ITU-T E.164 numbering plan defined in [E164] and
[CE164]. [CE164].
END_USER_IMSI 1 END_USER_IMSI 1
The identifier is in international IMSI format, according to the The identifier is in IMSI format, according to the ITU-T E.212
ITU-T E.212 numbering plan as defined in [E212] and [CE212]. identification plan as defined in [E212] and [CE212].
END_USER_SIP_URI 2 END_USER_SIP_URI 2
The identifier is in the form of a SIP URI, as defined in [RFC3261]. The identifier is in the form of a SIP URI, as defined in [RFC3261].
END_USER_NAI 3 END_USER_NAI 3
The identifier is in the form of a Network Access Identifier, as The identifier is in the form of a Network Access Identifier, as
defined in [RFC7542]. defined in [RFC7542].
END_USER_PRIVATE 4 END_USER_PRIVATE 4
The Identifier is a credit-control server private identifier. The identifier is a credit-control server private identifier.
8.48. Subscription-Id-Data AVP 8.48. Subscription-Id-Data AVP
The Subscription-Id-Data AVP (AVP Code 444) is used to identify the The Subscription-Id-Data AVP (AVP Code 444) is used to identify the
end user and is of type UTF8String. The Subscription-Id-Type AVP end user and is of type UTF8String. The Subscription-Id-Type AVP
defines which type of identifier is used. defines which type of identifier is used.
8.49. User-Equipment-Info AVP 8.49. User-Equipment-Info AVP
The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and
allows the credit-control client to indicate the identity and allows the credit-control client to indicate the identity and
capability of the terminal the subscriber is using for the connection capability of the terminal the subscriber is using for the connection
to network. to the network.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The User-Equipment-Info AVP is defined as follows (per
grouped-avp-def as defined in [RFC6733]):
User-Equipment-Info ::= < AVP Header: 458 > User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type } { User-Equipment-Info-Type }
{ User-Equipment-Info-Value } { User-Equipment-Info-Value }
8.50. User-Equipment-Info-Type AVP 8.50. User-Equipment-Info-Type AVP
The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459)
and defines the type of user equipment information contained in the and defines the type of user equipment information contained in the
User-Equipment-Info-Value AVP. User-Equipment-Info-Value AVP.
This specification defines the following user equipment types. This specification defines the following user equipment types.
However, new User-Equipment-Info-Type values can be assigned by an However, new User-Equipment-Info-Type values can be assigned by IANA
IANA as defined in Section 12. as defined in Section 12.
IMEISV 0 IMEISV 0
The identifier contains the International Mobile Equipment Identifier The identifier contains the International Mobile Equipment Identifier
and Software Version in the international IMEISV format according to and Software Version (IMEISV) in the IMEISV format according to 3GPP
3GPP TS 23.003 [TGPPIMEI]. TS 23.003 [TGPPIMEI].
MAC 1 MAC 1
The 48-bit MAC address is formatted as described in section 3.21 of The 48-bit Media Access Control (MAC) address is formatted as
[RFC3580]. described in Section 3.21 of [RFC3580].
EUI64 2 EUI64 2
The 64-bit identifier used to identify the hardware instance of the The 64-bit identifier used to identify the hardware instance of the
product, as defined in [EUI64]. product, as defined in [EUI64].
MODIFIED_EUI64 3 MODIFIED_EUI64 3
There are a number of types of terminals that have identifiers other There are a number of types of terminals that have identifiers other
than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be than the International Mobile Equipment Identifier (IMEI), IEEE 802
converted to modified EUI-64 format as described in [RFC4291] or by MACs, or EUI-64. These identifiers can be converted to modified
using some other methods referred to in the service-specific EUI-64 format as described in [RFC4291] or by using some other
documentation. methods referred to in the service-specific documentation.
8.51. User-Equipment-Info-Value AVP 8.51. User-Equipment-Info-Value AVP
The User-Equipment-Info-Value AVP (AVP Code 460) is of type The User-Equipment-Info-Value AVP (AVP Code 460) is of type
OctetString. The User-Equipment-Info-Type AVP defines which type of OctetString. The User-Equipment-Info-Type AVP defines which type of
identifier is used. identifier is used.
8.52. User-Equipment-Info-Extension AVP 8.52. User-Equipment-Info-Extension AVP
The User-Equipment-Info-Extension AVP (AVP Code TBD1) is of type The User-Equipment-Info-Extension AVP (AVP Code 653) is of type
Grouped and allows the credit-control client to indicate the identity Grouped and allows the credit-control client to indicate the identity
and capability of the terminal the subscriber is using for the and capability of the terminal the subscriber is using for the
connection to network. If the type of the equipment is one of the connection to the network. If the type of the equipment is one of
enumerated types of User-Equipment-Info-Type AVP, then the credit- the enumerated User-Equipment-Info-Type AVP values, then the
control client SHOULD send the information in the User-Equipment-Info credit-control client SHOULD send the information in the
AVP, in addition to or instead of the User-Equipment-Info-Extension User-Equipment-Info AVP, in addition to or instead of the
AVP. This is in order to preserve backward compatibility with User-Equipment-Info-Extension AVP. This is done in order to preserve
credit-control servers that support only [RFC4006]. Exactly one AVP backward compatibility with credit-control servers that support only
MUST be included inside the User-Equipment-Info-Extension AVP. [RFC4006]. Exactly one AVP MUST be included inside the
User-Equipment-Info-Extension AVP.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The User-Equipment-Info-Extension AVP is defined as follows (per
grouped-avp-def as defined in [RFC6733]):
User-Equipment-Info-Extension ::= < AVP Header: TBD1 > User-Equipment-Info-Extension ::= < AVP Header: 653 >
[ User-Equipment-Info-IMEISV ] [ User-Equipment-Info-IMEISV ]
[ User-Equipment-Info-MAC ] [ User-Equipment-Info-MAC ]
[ User-Equipment-Info-EUI64 ] [ User-Equipment-Info-EUI64 ]
[ User-Equipment-Info-ModifiedEUI64 ] [ User-Equipment-Info-ModifiedEUI64 ]
[ User-Equipment-Info-IMEI ] [ User-Equipment-Info-IMEI ]
[ AVP ] [ AVP ]
8.53. User-Equipment-Info-IMEISV AVP 8.53. User-Equipment-Info-IMEISV AVP
The User-Equipment-Info-IMEISV (AVP Code TBD2) is of type The User-Equipment-Info-IMEISV AVP (AVP Code 654) is of type
OctetString. The User-Equipment-Info-IMEISV AVP contains the OctetString. The User-Equipment-Info-IMEISV AVP contains the
International Mobile Equipment Identifier and Software Version in the International Mobile Equipment Identifier and Software Version in the
international IMEISV format according to 3GPP TS 23.003 [TGPPIMEI]. IMEISV format according to 3GPP TS 23.003 [TGPPIMEI].
8.54. User-Equipment-Info-MAC AVP 8.54. User-Equipment-Info-MAC AVP
The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. The User-Equipment-Info-MAC AVP (AVP Code 655) is of type
The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is OctetString. The User-Equipment-Info-MAC AVP contains the 48-bit MAC
formatted as described in section 4.1.7.8 of [RFC5777]. address; the MAC address is formatted as described in Section 4.1.7.8
of [RFC5777].
8.55. User-Equipment-Info-EUI64 AVP 8.55. User-Equipment-Info-EUI64 AVP
The User-Equipment-Info-EUI64 (AVP Code TBD4) is of type OctetString. The User-Equipment-Info-EUI64 AVP (AVP Code 656) is of type
The UUser-Equipment-Info-EUI64 AVP contains the 64-bit identifier OctetString. The User-Equipment-Info-EUI64 AVP contains the 64-bit
used to identify the hardware instance of the product, as defined in identifier used to identify the hardware instance of the product, as
[EUI64]. defined in [EUI64].
8.56. User-Equipment-Info-ModifiedEUI64 AVP 8.56. User-Equipment-Info-ModifiedEUI64 AVP
The User-Equipment-Info-ModifiedEUI64 (AVP Code TBD5) is of type The User-Equipment-Info-ModifiedEUI64 AVP (AVP Code 657) is of type
OctetString. There are a number of types of terminals that have OctetString. There are a number of types of terminals that have
identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These
identifiers can be converted to modified EUI-64 format as described identifiers can be converted to modified EUI-64 format as described
in [RFC4291] or by using some other methods referred to in the in [RFC4291] or by using some other methods referred to in the
service-specific documentation. The User-Equipment-Info- service-specific documentation. The User-Equipment-Info-
ModifiedEUI64 AVP contains such identifiers. ModifiedEUI64 AVP contains such identifiers.
8.57. User-Equipment-Info-IMEI AVP 8.57. User-Equipment-Info-IMEI AVP
The User-Equipment-Info-IMEI (AVP Code TBD6) is of type OctetString. The User-Equipment-Info-IMEI AVP (AVP Code 658) is of type
The User-Equipment-Info-IMEI AVP contains the International Mobile OctetString. The User-Equipment-Info-IMEI AVP contains the
Equipment Identifier in the international IMEI format according to International Mobile Equipment Identifier in the IMEI format
3GPP TS 23.003 [TGPPIMEI]. according to 3GPP TS 23.003 [TGPPIMEI].
8.58. Subscription-Id-Extension AVP 8.58. Subscription-Id-Extension AVP
The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify The Subscription-Id-Extension AVP (AVP Code 659) is used to identify
the end user's subscription and is of type Grouped. The the end user's subscription and is of type Grouped. The
Subscription-Id-Extension group AVP MUST include an AVP holding the Subscription-Id-Extension group AVP MUST include an AVP holding the
subscription identifier. The type of this included AVP indicates the subscription identifier. The type of this included AVP indicates the
type of the subscription identifier. For each of the enumerated type of the subscription identifier. For each of the enumerated
values of the Subscription-Id-Type AVP, there is a corresponding sub- values of the Subscription-Id-Type AVP, there is a corresponding
AVP for use within the Subscription-Id-Extension group AVP. If a new sub-AVP for use within the Subscription-Id-Extension group AVP. If a
identifier type is required a corresponding new sub-AVP SHOULD be new identifier type is required, a corresponding new sub-AVP SHOULD
defined for use within the Subscription-Id-Extension group AVP. be defined for use within the Subscription-Id-Extension group AVP.
If full backward compatibility with [RFC4006] is required, then the If full backward compatibility with [RFC4006] is required, then the
Subscription-Id AVP MUST be used to indicate identifier types Subscription-Id AVP MUST be used to indicate identifier types
enumerated in the Subscription-Id-Type AVP, whereas the Subscription- enumerated in the Subscription-Id-Type AVP, whereas the Subscription-
Id-Extension AVP MUST be used only for newly defined identifier Id-Extension AVP MUST be used only for newly defined identifier
types. If full backward compatibility with [RFC4006] is not types. If full backward compatibility with [RFC4006] is not
required, then the Subscription-Id-Extension AVP MAY be used to carry required, then the Subscription-Id-Extension AVP MAY be used to carry
out the existing identifier types. In this case, Subscription-Id- the existing identifier types. In this case, the Subscription-Id-
Extension AVP MAY be sent together with Subscription-Id AVP. Extension AVP MAY be sent together with the Subscription-Id AVP.
Exactly one sub-AVP MUST be included inside the Subscription-Id- Exactly one sub-AVP MUST be included inside the Subscription-Id-
Extension AVP. Extension AVP.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Subscription-Id-Extension AVP is defined as follows (per
grouped-avp-def as defined in [RFC6733]):
Subscription-Id-Extension ::= < AVP Header: TBD7 > Subscription-Id-Extension ::= < AVP Header: 659 >
[ Subscription-Id-E164 ] [ Subscription-Id-E164 ]
[ Subscription-Id-IMSI ] [ Subscription-Id-IMSI ]
[ Subscription-Id-SIP-URI ] [ Subscription-Id-SIP-URI ]
[ Subscription-Id-NAI ] [ Subscription-Id-NAI ]
[ Subscription-Id-Private ] [ Subscription-Id-Private ]
[ AVP ] [ AVP ]
8.59. Subscription-Id-E164 AVP 8.59. Subscription-Id-E164 AVP
The Subscription-Id-E164 (AVP Code TBD8) is of type UTF8String. The The Subscription-Id-E164 AVP (AVP Code 660) is of type UTF8String.
Subscription-Id-E164 AVP contains the international E.164 format The Subscription-Id-E164 AVP contains the international E.164 format
(e.g., MSISDN), according to the ITU-T E.164 numbering plan defined (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined
in [E164] and [CE164]. in [E164] and [CE164].
8.60. Subscription-Id-IMSI AVP 8.60. Subscription-Id-IMSI AVP
The Subscription-Id-IMSI (AVP Code TBD9) is of type UTF8String. The The Subscription-Id-IMSI AVP (AVP Code 661) is of type UTF8String.
Subscription-Id-IMSI AVP contains the international IMSI format, The Subscription-Id-IMSI AVP contains the IMSI format, according to
according to the ITU-T E.212 numbering plan as defined in [E212] and the ITU-T E.212 identification plan as defined in [E212] and [CE212].
[CE212].
8.61. Subscription-Id-SIP-URI AVP 8.61. Subscription-Id-SIP-URI AVP
The Subscription-Id-SIP-URI (AVP Code TBD10) is of type UTF8String. The Subscription-Id-SIP-URI AVP (AVP Code 662) is of type UTF8String.
The Subscription-Id-SIP-URI AVP contains the identifier in the form The Subscription-Id-SIP-URI AVP contains the identifier in the form
of a SIP URI, as defined in [RFC3261]. of a SIP URI, as defined in [RFC3261].
8.62. Subscription-Id-NAI AVP 8.62. Subscription-Id-NAI AVP
The Subscription-Id-NAI (AVP Code TBD11) is of type UTF8String. The The Subscription-Id-NAI AVP (AVP Code 663) is of type UTF8String.
Subscription-Id-NAI AVP contains the identifier in the form of a The Subscription-Id-NAI AVP contains the identifier in the form of a
Network Access Identifier, as defined in [RFC7542]. Network Access Identifier, as defined in [RFC7542].
8.63. Subscription-Id-Private AVP 8.63. Subscription-Id-Private AVP
The Subscription-Id-Private (AVP Code TBD12) is of type UTF8String. The Subscription-Id-Private AVP (AVP Code 664) is of type UTF8String.
The Subscription-Id-Private AVP contains a credit-control server The Subscription-Id-Private AVP contains a credit-control server
private identifier. private identifier.
8.64. Redirect-Server-Extension AVP 8.64. Redirect-Server-Extension AVP
The Redirect-Server-Extension AVP (AVP Code TBD13) is of type Grouped The Redirect-Server-Extension AVP (AVP Code 665) is of type Grouped
and contains the address information of the redirect server (e.g., and contains the address information of the redirect server (e.g.,
HTTP redirect server, SIP Server) with which the end user is to be HTTP redirect server, SIP Server) with which the end user is to be
connected when the account cannot cover the service cost. It MUST be connected when the account cannot cover the service cost. It MUST be
present inside the QoS-Final-Unit-Indication AVP when the Final-Unit- present inside the QoS-Final-Unit-Indication AVP when the Final-Unit-
Action AVP is set to REDIRECT. If the type of the redirect server is Action AVP is set to REDIRECT. If the type of the redirect server is
one of the enumerated values of the Redirect-Address-Type AVP, then one of the enumerated values of the Redirect-Address-Type AVP, then
the credit-control server SHOULD send the information in the the credit-control server SHOULD send the information in the
Redirect-Server AVP, in addition to or instead of the Redirect- Redirect-Server AVP, in addition to or instead of the Redirect-
Server-Extension AVP. This is in order to preserve backward Server-Extension AVP. This is done in order to preserve backward
compatibility with credit-control clients that support only compatibility with credit-control clients that support only
[RFC4006]. Exactly one AVP MUST be included inside the Redirect- [RFC4006]. Exactly one AVP MUST be included inside the Redirect-
Server-Extension AVP. Server-Extension AVP.
It is defined as follows (per the grouped-avp-def of [RFC6733]): The Redirect-Server-Extension AVP is defined as follows (per
grouped-avp-def as defined in [RFC6733]):
Redirect-Server-Extension ::= < AVP Header: TBD13 > Redirect-Server-Extension ::= < AVP Header: 665 >
[ Redirect-Address-IPAddress ] [ Redirect-Address-IPAddress ]
[ Redirect-Address-URL ] [ Redirect-Address-URL ]
[ Redirect-Address-SIP-URI ] [ Redirect-Address-SIP-URI ]
[ AVP ] [ AVP ]
8.65. Redirect-Address-IPAddress AVP 8.65. Redirect-Address-IPAddress AVP
The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type The Redirect-Address-IPAddress AVP (AVP Code 666) is of type Address
Address and defines the IPv4 or IPv6 address of the redirect server and defines the IPv4 or IPv6 address of the redirect server with
with which the end user is to be connected when the account cannot which the end user is to be connected when the account cannot cover
cover the service cost. the service cost.
When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6
format [RFC4291] MAY be used to indicate an IPv4 address. format [RFC4291] MAY be used to indicate an IPv4 address.
The interpretation of Redirect-Address-IPAddress by the Diameter The interpretation of Redirect-Address-IPAddress by the Diameter
Credit-control Client is a matter of local policy. Credit-Control client is a matter of local policy.
8.66. Redirect-Address-URL AVP 8.66. Redirect-Address-URL AVP
The Redirect-Address-URL AVP (AVP Code TBD15) is of type UTF8String The Redirect-Address-URL AVP (AVP Code 667) is of type UTF8String and
and defines the address of the redirect server with which the end defines the address of the redirect server with which the end user is
user is to be connected when the account cannot cover the service to be connected when the account cannot cover the service cost. The
cost. The address type is in the form of Uniform Resource Locator, address type is in the form of a Uniform Resource Locator, as defined
as defined in [RFC3986]. Note that individual URL schemes may in [RFC3986]. Note that individual URL schemes may restrict the
restrict the contents of the UTF8String. contents of the UTF8String.
8.67. Redirect-Address-SIP-URI AVP 8.67. Redirect-Address-SIP-URI AVP
The Redirect-Address-SIP-URI AVP (AVP Code TBD16) is of type The Redirect-Address-SIP-URI AVP (AVP Code 668) is of type UTF8String
UTF8String and defines the address of the redirect server with which and defines the address of the redirect server with which the end
the end user is to be connected when the account cannot cover the user is to be connected when the account cannot cover the service
service cost. The address type is in the form of SIP Uniform cost. The address type is in the form of a SIP Uniform Resource
Resource Identifier, as defined in [RFC3261]. Identifier, as defined in [RFC3261].
8.68. QoS-Final-Unit-Indication AVP 8.68. QoS-Final-Unit-Indication AVP
The QoS-Final-Unit-Indication AVP (AVP Code TBD17) is of type Grouped The QoS-Final-Unit-Indication AVP (AVP Code 669) is of type Grouped
and indicates that the Granted-Service-Unit AVP in the Credit- and indicates that the Granted-Service-Unit AVP in the
Control-Answer, or in the AA answer, contains the final units for the Credit-Control-Answer or in the AA-Answer contains the final units
service. After these units have expired, the Diameter credit-control for the service. After these units have expired, the Diameter
client is responsible for executing the action indicated in the Credit-Control client is responsible for executing the action
Final-Unit-Action AVP (see Section 5.6). indicated in the Final-Unit-Action AVP (see Section 5.6).
If more than one unit type is received in the Credit-Control-Answer, If more than one unit type is received in the Credit-Control-Answer,
the unit type that first expired SHOULD cause the credit-control the unit type that first expired SHOULD cause the credit-control
client to execute the specified action. client to execute the specified action.
In the first interrogation, the QoS-Final-Unit-Indication AVP with In the first interrogation, the QoS-Final-Unit-Indication AVP with
Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS can also be
with no Granted-Service-Unit AVP in the Credit-Control-Answer or in present with no Granted-Service-Unit AVP in the Credit-Control-Answer
the AA answer. This indicates to the Diameter credit-control client or in the AA-Answer. This indicates to the Diameter Credit-Control
to execute the specified action immediately. If the home service client that the client is to execute the specified action
provider policy is to terminate the service, naturally, the server immediately. If the home service provider policy is to terminate the
SHOULD return the appropriate transient failure (see Section 9.1) in service, naturally, the server SHOULD return the appropriate