| < draft-ietf-aaa-diameter-cc-05.txt | draft-ietf-aaa-diameter-cc-06.txt > | |||
|---|---|---|---|---|
| AAA Working Group | AAA Working Group | |||
| Internet Draft Harri Hakala | Internet Draft Harri Hakala | |||
| Document: draft-ietf-aaa-diameter-cc-05.txt Leena Mattila | Document: draft-ietf-aaa-diameter-cc-06.txt Leena Mattila | |||
| Expires: November 13, 2004 Ericsson | Expires: February 12, 2005 Ericsson | |||
| Juha-Pekka Koskinen | Juha-Pekka Koskinen | |||
| Marco Stura | Marco Stura | |||
| John Loughney | John Loughney | |||
| Nokia | Nokia | |||
| May 14, 2004 | August 12, 2004 | |||
| Diameter Credit-Control Application | Diameter Credit-Control Application | |||
| Status of this memo | Status of this memo | |||
| By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, I certify that any applicable | |||
| patent or other IPR claims of which I am aware have been disclosed, | patent or other IPR claims of which I am aware have been disclosed, | |||
| and any of which I become aware will be disclosed, in accordance with | and any of which I become aware will be disclosed, in accordance | |||
| RFC 3668. | with RFC 3668. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||
| and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other documents | |||
| time. It is inappropriate to use Internet-Drafts as reference | at any time. It is inappropriate to use Internet-Drafts as | |||
| material or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This document is a product of the Authentication, Authorization and | This document is a product of the Authentication, Authorization and | |||
| Accounting (AAA) Working Group of the Internet Engineering Task Force | Accounting (AAA) Working Group of the Internet Engineering Task | |||
| (IETF). Comments are welcome should be submitted to the mailing list | Force (IETF). Comments are welcome should be submitted to the | |||
| aaa-wg@merit.edu. | mailing list aaa-wg@merit.edu. | |||
| 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 | |||
| such as network access, Session Initiation Protocol (SIP) services, | services such as network access, Session Initiation Protocol (SIP) | |||
| messaging services, download services etc. | services, messaging services, download services etc. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 1. Introduction...................................................5 | 1. Introduction...................................................5 | |||
| 1.1 Requirements language......................................5 | 1.1 Requirements language......................................5 | |||
| 1.2 Terminology................................................6 | 1.2 Terminology................................................6 | |||
| 1.3 Advertising application support............................7 | 1.3 Advertising application support............................7 | |||
| 2. Architecture Models............................................8 | 2. Architecture Models............................................8 | |||
| 3. Credit-Control Messages........................................9 | 3. Credit-Control Messages.......................................10 | |||
| 3.1 Credit-Control-Request (CCR) Command......................10 | 3.1 Credit-Control-Request (CCR) Command......................10 | |||
| 3.2 Credit-Control-Answer (CCA) Command.......................11 | 3.2 Credit-Control-Answer (CCA) Command.......................11 | |||
| 4. Credit Control Application Overview...........................12 | 4. Credit Control Application Overview...........................12 | |||
| 4.1 Service-Specific Rating Input and Interoperability........13 | 4.1 Service-Specific Rating Input and Interoperability........13 | |||
| 5. Session Based Credit-control..................................15 | 5. Session Based Credit-control..................................16 | |||
| 5.1 General Principles........................................15 | 5.1 General Principles........................................16 | |||
| 5.2 First Interrogation.......................................20 | 5.2 First Interrogation.......................................21 | |||
| 5.3 Intermediate Interrogation................................26 | 5.3 Intermediate Interrogation................................27 | |||
| 5.4 Final Interrogation.......................................28 | 5.4 Final Interrogation.......................................29 | |||
| 5.5 Server-Initiated Credit Re-Authorization..................29 | 5.5 Server-Initiated Credit Re-Authorization..................30 | |||
| 5.6 Graceful Service Termination..............................31 | 5.6 Graceful Service Termination..............................32 | |||
| 5.7 Failure Procedures........................................36 | 5.7 Failure Procedures........................................37 | |||
| 6. One Time Event................................................39 | 6. One Time Event................................................40 | |||
| 6.1 Service Price Enquiry.....................................40 | 6.1 Service Price Enquiry.....................................41 | |||
| 6.2 Balance Check.............................................40 | 6.2 Balance Check.............................................41 | |||
| 6.3 Direct Debiting...........................................41 | 6.3 Direct Debiting...........................................42 | |||
| 6.4 Refund....................................................42 | 6.4 Refund....................................................43 | |||
| 6.5 Failure Procedure.........................................42 | 6.5 Failure Procedure.........................................44 | |||
| 7. Credit Control Application State Machine......................44 | 7. Credit Control Application State Machine......................45 | |||
| 8. Credit Control AVPs...........................................53 | 8. Credit Control AVPs...........................................54 | |||
| 8.1 CC-Correlation-Id AVP.....................................55 | 8.1 CC-Correlation-Id AVP.....................................57 | |||
| 8.2 CC-Request-Number AVP.....................................55 | 8.2 CC-Request-Number AVP.....................................57 | |||
| 8.3 CC-Request-Type AVP.......................................56 | 8.3 CC-Request-Type AVP.......................................57 | |||
| 8.4 CC-Session-Failover AVP...................................57 | 8.4 CC-Session-Failover AVP...................................58 | |||
| 8.5 CC-Sub-Session-Id AVP.....................................57 | 8.5 CC-Sub-Session-Id AVP.....................................58 | |||
| 8.6 Check-Balance-Result AVP..................................57 | 8.6 Check-Balance-Result AVP..................................59 | |||
| 8.7 Cost-Information AVP......................................58 | 8.7 Cost-Information AVP......................................59 | |||
| 8.8 Unit-Value AVP............................................59 | 8.8 Unit-Value AVP............................................60 | |||
| 8.9 Exponent AVP..............................................59 | 8.9 Exponent AVP..............................................60 | |||
| 8.10 Value-Digits AVP.........................................59 | 8.10 Value-Digits AVP.........................................60 | |||
| 8.11 Currency-Code AVP........................................59 | 8.11 Currency-Code AVP........................................61 | |||
| 8.12 Cost-Unit AVP............................................60 | 8.12 Cost-Unit AVP............................................61 | |||
| 8.13 Credit-Control AVP.......................................60 | 8.13 Credit-Control AVP.......................................61 | |||
| 8.14 Credit-Control-Failure-Handling AVP......................60 | 8.14 Credit-Control-Failure-Handling AVP......................61 | |||
| 8.15 Direct-Debiting-Failure-Handling AVP.....................61 | 8.15 Direct-Debiting-Failure-Handling AVP.....................62 | |||
| 8.16 Multiple-Services-Credit-Control AVP.....................62 | 8.16 Multiple-Services-Credit-Control AVP.....................63 | |||
| 8.17 Granted-Service-Unit AVP.................................63 | 8.17 Granted-Service-Unit AVP.................................64 | |||
| 8.18 Requested-Service-Unit AVP...............................64 | 8.18 Requested-Service-Unit AVP...............................65 | |||
| 8.19 Used-Service-Unit AVP....................................64 | 8.19 Used-Service-Unit AVP....................................65 | |||
| 8.20 Tariff-Time-Change AVP...................................65 | 8.20 Tariff-Time-Change AVP...................................66 | |||
| 8.21 CC-Time AVP..............................................65 | 8.21 CC-Time AVP..............................................66 | |||
| 8.22 CC-Money AVP.............................................65 | 8.22 CC-Money AVP.............................................66 | |||
| 8.23 CC-Total-Octets AVP......................................67 | ||||
| Diameter Credit Control Application May 14, 2004 | 8.24 CC-Input-Octets AVP......................................67 | |||
| 8.25 CC-Output-Octets AVP.....................................67 | ||||
| 8.23 CC-Total-Octets AVP......................................65 | 8.26 CC-Service-Specific-Units AVP............................67 | |||
| 8.24 CC-Input-Octets AVP......................................65 | 8.27 Tariff-Change-Usage AVP..................................67 | |||
| 8.25 CC-Output-Octets AVP.....................................66 | 8.28 Service-Identifier AVP...................................68 | |||
| 8.26 CC-Service-Specific-Units AVP............................66 | 8.29 Rating-Group AVP.........................................68 | |||
| 8.27 Tariff-Change-Usage AVP..................................66 | 8.30 G-S-U-Pool-Reference AVP.................................69 | |||
| 8.28 Service-Identifier AVP...................................67 | 8.31 G-S-U-Pool-Identifier AVP................................69 | |||
| 8.29 Rating-Group AVP.........................................67 | 8.32 CC-Unit-Type AVP.........................................69 | |||
| 8.30 G-S-U-Pool-Reference AVP.................................68 | 8.33 Validity-Time AVP........................................70 | |||
| 8.31 G-S-U-Pool-Identifier AVP................................68 | 8.34 Final-Unit-Indication AVP................................70 | |||
| 8.32 CC-Unit-Type AVP.........................................68 | 8.35 Final-Unit-Action AVP....................................71 | |||
| 8.33 Validity-Time AVP........................................69 | 8.36 Restriction-Filter-Rule AVP..............................72 | |||
| 8.34 Final-Unit-Indication AVP................................69 | 8.37 Redirect-Server AVP......................................72 | |||
| 8.35 Final-Unit-Action AVP....................................70 | 8.38 Redirect-Address-Type AVP................................72 | |||
| 8.36 Restriction-Filter-Rule AVP..............................71 | 8.39 Redirect-Server-Address AVP..............................73 | |||
| 8.37 Redirect-Server AVP......................................71 | 8.40 Multiple-Services-Indicator AVP..........................73 | |||
| 8.38 Redirect-Address-Type AVP................................71 | ||||
| 8.39 Redirect-Server-Address AVP..............................72 | ||||
| 8.40 Multiple-Services-Indicator AVP..........................72 | ||||
| 8.41 Requested-Action AVP.....................................73 | 8.41 Requested-Action AVP.....................................73 | |||
| 8.42 Service-Parameter-Info AVP...............................73 | 8.42 Service-Context-Id AVP...................................74 | |||
| 8.43 Service-Parameter-Type AVP...............................74 | 8.43 Service-Parameter-Info AVP...............................75 | |||
| 8.44 Service-Parameter-Value AVP..............................74 | 8.44 Service-Parameter-Type AVP...............................75 | |||
| 8.45 Subscription-Id AVP......................................74 | 8.45 Service-Parameter-Value AVP..............................76 | |||
| 8.46 Subscription-Id-Type AVP.................................75 | 8.46 Subscription-Id AVP......................................76 | |||
| 8.47 Subscription-Id-Data AVP.................................75 | 8.47 Subscription-Id-Type AVP.................................76 | |||
| 8.48 User-Equipment-Info AVP..................................75 | 8.48 Subscription-Id-Data AVP.................................77 | |||
| 8.49 User-Equipment-Info-Type AVP.............................76 | 8.49 User-Equipment-Info AVP..................................77 | |||
| 8.50 User-Equipment-Info-Value AVP............................76 | 8.50 User-Equipment-Info-Type AVP.............................77 | |||
| 9. Result Code AVP values........................................76 | 8.50 User-Equipment-Info-Value AVP............................78 | |||
| 9.1 Transient Failures........................................77 | 9. Result Code AVP values........................................78 | |||
| 9.2 Permanent Failures........................................77 | 9.1 Transient Failures........................................78 | |||
| 10. AVP Occurrence Table.........................................77 | 9.2 Permanent Failures........................................79 | |||
| 10.1 Credit Control AVP Table.................................78 | 10. AVP Occurrence Table.........................................79 | |||
| 10.2 Re-Auth-Request/Answer AVP Table.........................79 | 10.1 Credit Control AVP Table.................................79 | |||
| 11. RADIUS/Diameter Credit-control Interworking Model............79 | 10.2 Re-Auth-Request/Answer AVP Table.........................81 | |||
| 12. IANA Considerations..........................................82 | 11. RADIUS/Diameter Credit-control Interworking Model............81 | |||
| 12.1 Application Identifier...................................82 | 12. IANA Considerations..........................................84 | |||
| 12.2 Command Codes............................................82 | 12.1 Application Identifier...................................84 | |||
| 12.3 AVP Codes................................................82 | 12.2 Command Codes............................................84 | |||
| 12.4 Result-Code AVP Values...................................82 | 12.3 AVP Codes................................................84 | |||
| 12.5 CC-Request-Type AVP......................................83 | 12.4 Result-Code AVP Values...................................84 | |||
| 12.6 CC-Session-Failover AVP..................................83 | 12.5 CC-Request-Type AVP......................................84 | |||
| 12.7 CC-Unit-Type AVP.........................................83 | 12.6 CC-Session-Failover AVP..................................84 | |||
| 12.8 Check-Balance-Result AVP.................................83 | 12.7 CC-Unit-Type AVP.........................................85 | |||
| 12.9 Credit-Control AVP.......................................83 | 12.8 Check-Balance-Result AVP.................................85 | |||
| 12.10 Credit-Control-Failure-Handling AVP.....................83 | 12.9 Credit-Control AVP.......................................85 | |||
| 12.11 Direct-Debiting-Failure-Handling AVP....................83 | 12.10 Credit-Control-Failure-Handling AVP.....................85 | |||
| 12.12 Final-Unit-Action AVP...................................84 | 12.11 Direct-Debiting-Failure-Handling AVP....................85 | |||
| 12.13 Multiple-Services-Indicator AVP.........................84 | 12.12 Final-Unit-Action AVP...................................85 | |||
| 12.13 Multiple-Services-Indicator AVP.........................86 | ||||
| Diameter Credit Control Application May 14, 2004 | 12.14 Redirect-Address-Type AVP...............................86 | |||
| 12.15 Requested-Action AVP....................................86 | ||||
| 12.14 Redirect-Address-Type AVP...............................84 | 12.16 Subscription-Id-Type AVP................................86 | |||
| 12.15 Requested-Action AVP....................................84 | 12.17 Tariff-Change-Usage AVP.................................86 | |||
| 12.16 Subscription-Id-Type AVP................................84 | 12.18 User-Equipment-Info-Type AVP............................86 | |||
| 12.17 Tariff-Change-Usage AVP.................................84 | 13. Credit-control Application Related Parameters................87 | |||
| 12.18 User-Equipment-Info-Type AVP............................84 | 14. Security Consideration.......................................87 | |||
| 13. Credit-control Application Related Parameters................85 | 14.1 Direct Connection with Redirects.........................88 | |||
| 14. Security Consideration.......................................85 | 15. References...................................................89 | |||
| 14.1 Direct Connection with Redirects.........................86 | 15.1 Normative................................................89 | |||
| 15. References...................................................87 | 15.2 Non-Normative............................................90 | |||
| 15.1 Normative................................................87 | 16. Acknowledgement..............................................91 | |||
| 15.2 Non-Normative............................................88 | A.1 Flow I..................................................92 | |||
| 16. Acknowledgement..............................................89 | A.2 Flow II.................................................94 | |||
| Appendix A Credit Control sequences..............................89 | A.3 Flow III................................................96 | |||
| A.1 Flow I...................................................89 | A.4 Flow IV.................................................97 | |||
| A.2 Flow II..................................................91 | A.5 Flow V..................................................98 | |||
| A.3 Flow III.................................................93 | A.6 Flow VI.................................................99 | |||
| A.4 Flow IV..................................................93 | A.7 Flow VII...............................................100 | |||
| A.5 Flow V...................................................95 | A.8 Flow VIII..............................................102 | |||
| A.6 Flow VI..................................................96 | A.9 Flow IX..................................................104 | |||
| A.7 Flow VII.................................................97 | Author's Address................................................108 | |||
| A.8 Flow VIII................................................98 | Intellectual Property Considerations...Error! Bookmark not defined. | |||
| A.9 Flow IX..................................................100 | ||||
| Author's Address................................................105 | ||||
| Intellectual Property Considerations............................106 | ||||
| Diameter Credit Control Application May 14, 2004 | ||||
| 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 | |||
| such as network access, Session Initiation Protocol (SIP) services, | services such as network access, Session Initiation Protocol (SIP) | |||
| messaging services, download services etc. It provides a general | services, messaging services, download services etc. It provides a | |||
| solution to the real-time cost and credit control. | general solution to the 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 instance | |||
| in GSM networks where network operators offering prepaid services | in GSM networks where network operators offering prepaid services | |||
| have experienced a substantial growth of their customer base and | have experienced a substantial growth of their customer base and | |||
| revenues. Prepaid services are now cropping up in many other wireless | revenues. Prepaid services are now cropping up in many other | |||
| and wire line based networks as well. | wireless and wire line based networks as well. | |||
| In next generation wireless networks, additional functionality is | In next generation wireless networks, additional functionality is | |||
| required beyond that specified in the Diameter base protocol. For | required beyond that specified in the Diameter base protocol. For | |||
| example, the 3GPP Charging and Billing requirements [3GPPCHARG] state | example, the 3GPP Charging and Billing requirements [3GPPCHARG] | |||
| that an application must be able to rate service information in real- | state that an application must be able to rate service information | |||
| time. In addition, it is necessary to check that the end user's | in real-time. In addition, it is necessary to check that the end | |||
| account provides coverage for the requested service, prior to | user's account provides coverage for the requested service, prior to | |||
| initiation of that service. When an account is exhausted or expired, | initiation of that service. When an account is exhausted or expired, | |||
| the user must be denied the ability to compile additional chargeable | the user must be denied the ability to compile additional chargeable | |||
| events. | events. | |||
| A mechanism needs to be provided to allow the user to be informed of | A mechanism needs 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 from a user account. | as debit from a user account. | |||
| The other Diameter applications provide service specific | The other Diameter applications provide service specific | |||
| skipping to change at page 5, line 50 ¶ | skipping to change at page 5, line 48 ¶ | |||
| prepaid services. | prepaid services. | |||
| To fulfill these requirements, it is necessary to facilitate credit- | To fulfill these requirements, it is necessary to facilitate credit- | |||
| control communication between the network element providing the | control communication between the network element providing the | |||
| service (e.g. Network Access Server, SIP Proxy, Application Server | service (e.g. Network Access Server, SIP Proxy, Application Server | |||
| etc.) and a credit-control server. | etc.) and a credit-control server. | |||
| The scope of this specification is the credit authorization. Service | The scope of this specification is the credit authorization. Service | |||
| specific authorization and authentication is out of the scope. | specific authorization and authentication is out of the scope. | |||
| 1.1 Requirements language | 1.1 Requirements language | |||
| In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", | ||||
| "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as | ||||
| described in [KEYWORDS]. | ||||
| Diameter Credit Control Application May 14, 2004 | In this document, the key words "MAY", "MUST, "MUST NOT", | |||
| "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be | ||||
| interpreted as described in [KEYWORDS]. | ||||
| 1.2 Terminology | 1.2 Terminology | |||
| AAA | AAA | |||
| Authentication, Authorization and Accounting | Authentication, Authorization and Accounting | |||
| AA answer | AA answer | |||
| AA answer generically refers to a service specific authorization and | AA answer generically refers to a service specific authorization and | |||
| authentication answer. AA answer commands are defined in service | authentication answer. AA answer commands are defined in service | |||
| specific authorization applications e.g. [NASREQ] and [DIAMMIP]. | specific authorization applications e.g. [NASREQ] and [DIAMMIP]. | |||
| AA request | AA request | |||
| AA request generically refers to a service specific authorization and | AA request generically refers to a service specific authorization | |||
| authentication request. AA request commands are defined in service | and authentication request. AA request commands are defined in | |||
| specific authorization applications e.g. [NASREQ] and [DIAMMIP]. | service specific authorization applications e.g. [NASREQ] and | |||
| [DIAMMIP]. | ||||
| Credit-control | Credit-control | |||
| Credit-control is a mechanism, which directly interacts in real-time | Credit-control is a mechanism, which directly interacts in real-time | |||
| with an account and controls or monitors the charges, related to the | with an account and controls or monitors the charges, related to the | |||
| service usage. Credit-control is a process of: checking if credit is | service usage. Credit-control is a process of: checking if credit is | |||
| available, credit-reservation, deduction of credit from the end user | available, credit-reservation, deduction of credit from the end user | |||
| account when service is completed and refunding of reserved credit | account when service is completed and refunding of reserved credit | |||
| not used. | not used. | |||
| Diameter Credit-control Server | Diameter Credit-control Server | |||
| Diameter Credit-control server acts as a prepaid server, performing | Diameter Credit-control server acts as a prepaid server, performing | |||
| real-time rating and credit control. It is located in the home domain | real-time rating and credit control. It is located in the home | |||
| and is accessed by service elements or Diameter AAA servers in real- | domain and is accessed by service elements or Diameter AAA servers | |||
| time for purpose of price determination and credit-control before the | in real-time for purpose of price determination and credit-control | |||
| service event is delivered to the end-user. It may also interact with | before the service event is delivered to the end-user. It may also | |||
| business support systems. | interact with business support systems. | |||
| Diameter Credit-control Client | Diameter Credit-control Client | |||
| A Diameter credit-control client is an entity that interacts with a | A Diameter credit-control client is an entity that interacts with a | |||
| credit-control server. It monitors the usage of the granted quota | credit-control server. It monitors the usage of the granted quota | |||
| according to instructions returned by credit-control server. | according to instructions returned by credit-control server. | |||
| Interrogation | Interrogation | |||
| The Diameter credit-control client uses interrogation to initiate a | The Diameter credit-control client uses interrogation to initiate a | |||
| session based credit-control process and during the credit-control | session based credit-control process and during the credit-control | |||
| process to report the used quota and request a new one. An | process to report the used quota and request a new one. An | |||
| interrogation maps to a request/answer transaction. | interrogation maps to a request/answer transaction. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| One-time event | One-time event | |||
| Basically a request/answer transaction of type event. | Basically a request/answer transaction of type event. | |||
| Rating | Rating | |||
| The act of determining the cost of the service event. | The act of determining the cost of the service event. | |||
| Service | Service | |||
| A type of task that is performed by a service element for an end | A type of task that is performed by a service element for an end | |||
| user. | user. | |||
| Service Element | Service Element | |||
| A network element that provides a service to the end users. The | A network element that provides a service to the end users. The | |||
| Service Element may include the Credit-control Client, or another | Service Element may include the Credit-control Client, or another | |||
| entity (e.g. RADIUS AAA server) can act as a Credit-control Client on | entity (e.g. RADIUS AAA server) can act as a Credit-control Client | |||
| behalf of the Service Element. In the latter case the interface | on behalf of the Service Element. In the latter case the interface | |||
| between the Service Element and the Diameter Credit-control Client is | between the Service Element and the Diameter Credit-control Client | |||
| outside the scope of this specification. Examples of the Service | is outside the scope of this specification. Examples of the Service | |||
| Elements include Network Acess Server (NAS), SIP Proxy and | Elements include Network Access Server (NAS), SIP Proxy and | |||
| Application Servers such as messaging server, content server and | Application Servers such as messaging server, content server and | |||
| gaming server. | gaming server. | |||
| Service Event | Service Event | |||
| An event relating to a service provided to the end user. | An event relating to a service provided to the end user. | |||
| Session based credit-control | Session based credit-control | |||
| A credit-control process that makes use of several interrogations: | A credit-control process that makes use of several interrogations: | |||
| the first, possible intermediate and the final interrogation. The | the first, possible intermediate and the final interrogation. The | |||
| first interrogation is used to reserve money from the user's account | first interrogation is used to reserve money from the user's account | |||
| and initiate the process. The intermediate interrogations may be | and initiate the process. The intermediate interrogations may be | |||
| needed to request new quota while the service is being rendered. The | needed to request new quota while the service is being rendered. The | |||
| final interrogation is used to exit the process. The credit-control | final interrogation is used to exit the process. The credit-control | |||
| server is required to maintain session state for session-based | server is required to maintain session state for session-based | |||
| credit-control. | 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 XXX [IANA please fill in XXX | |||
| Capabilities-Exchange-Request and Capabilities-Exchange-Answer | (suggested value 4 in section 12.1) and remove this note] in the | |||
| command [DIAMBASE]. | Auth-Application-Id of the Capabilities-Exchange-Request and | |||
| Capabilities-Exchange-Answer command [DIAMBASE]. | ||||
| Diameter Credit Control Application May 14, 2004 | ||||
| 2. Architecture Models | 2. Architecture Models | |||
| The current accounting models specified in the Radius Accounting | The current accounting models specified in the Radius Accounting | |||
| [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real- | [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real- | |||
| time credit control, where credit-worthiness is to be determined | time credit control, where credit-worthiness is to be determined | |||
| prior to service initiation. Also, the existing Diameter | prior to service initiation. Also, the existing Diameter | |||
| authorization applications [NASREQ] and [DIAMMIP] only provides | authorization applications [NASREQ] and [DIAMMIP] only provides | |||
| service authorization, but do not provide credit authorization for | service authorization, but do not provide credit authorization for | |||
| prepaid users. In order to support real-time credit control a new | prepaid users. In order to support real-time credit control a new | |||
| type of server is needed in the AAA infrastructure; Diameter credit- | type of server is needed in the AAA infrastructure; Diameter credit- | |||
| control server. The Diameter credit-control server is the entity | control server. The Diameter credit-control server is the entity | |||
| responsible of credit authorization for prepaid subscribers. | responsible of 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 using AAA protocols, e.g. RADIUS or a Diameter base | the AAA server using AAA protocols, e.g. RADIUS or a Diameter base | |||
| protocol with a possible Diameter application. | protocol with a possible 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 | |||
| interim reports until service completion. However, for real-time | possible interim reports until service completion. However, for | |||
| credit control, these authorization and accounting models are not | real-time credit control, these authorization and accounting models | |||
| sufficient. | are not 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 possible service event | contacts the credit-control server with possible service event | |||
| information. The credit-control process is performed in order to | information. The credit-control process is performed in order to | |||
| determine potential charges and to verify whether the end user's | determine potential charges and to verify whether the end user's | |||
| account balance is sufficient to cover the cost of the service being | account 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 | |||
| consist of a Service Element with embedded Diameter credit-control | consist of a Service Element with embedded Diameter credit-control | |||
| client, a Diameter credit-control server and an AAA server. A | client, a Diameter credit-control server and an AAA server. A | |||
| Business Support System is usually deployed; it includes at least the | Business Support System is usually deployed; it includes at least | |||
| billing functionality. The credit-control server and AAA server in | the billing functionality. The credit-control server and AAA server | |||
| this architecture model are logical entities. The real configuration | in this architecture model are logical entities. The real | |||
| can combine them into a single host. The credit-control protocol is | configuration can combine them into a single host. The credit- | |||
| the Diameter base protocol with the Diameter credit-control | control protocol is the Diameter base protocol with the Diameter | |||
| application. | credit-control application. | |||
| When an end user requests services such as SIP services or messaging | When an end user requests services such as SIP services or messaging | |||
| services, the request is typically forwarded to a service element | services, the request is typically forwarded to a service element | |||
| (e.g. SIP Proxy) in the user's home domain. In some cases it might be | (e.g. SIP Proxy) in the user's home domain. In some cases it might | |||
| possible that the service element in the visited domain can offer | be possible that the service element in the visited domain can offer | |||
| services to the end user, however a commercial agreement must exist | services to the end user, however a commercial agreement must exist | |||
| between the visited domain and the home domain. Network access is an | between the visited domain and the home domain. Network access is an | |||
| example of a service offered in the visited domain where the NAS, | example of a service offered in the visited domain where the NAS, | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| through an AAA infrastructure, authenticates and authorizes the user | through an AAA infrastructure, authenticates and authorizes the user | |||
| with the user's home network. | 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 | |||
| reasons of redundancy and load balancing. The system can also contain | reasons of redundancy and load balancing. The system can also | |||
| separate rating server(s) and accounts can be located in a | contain separate rating server(s) and accounts can be located in a | |||
| centralized database. For duplicate detection only one place in the | centralized database. For duplicate detection only one place in the | |||
| credit-control system should perform duplicate detection to ensure | credit-control system should perform duplicate detection to ensure | |||
| that the end user's account is not debited or credited multiple times | that the end user's account is not debited or credited multiple | |||
| for the same service event. System internal interfaces can exist to | times for the same service event. System internal interfaces can | |||
| relay messages between servers and an account manager. However the | exist to relay messages between servers and an account manager. | |||
| detailed architecture of credit-control system and its interfaces are | However the detailed architecture of credit-control system and its | |||
| implementation specific and are out of scope of this specification. | interfaces are implementation specific and are out of scope of this | |||
| specification. | ||||
| There can exist protocol transparent Diameter relays between credit- | There can exist protocol transparent Diameter relays between credit- | |||
| control client and credit-control server. Also Diameter Redirect | control client and credit-control server. Also Diameter Redirect | |||
| agents, which refer credit control clients, to credit control servers | agents, which 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 | |||
| different roles of Diameter Agents are defined in Diameter base | application. The different roles of Diameter Agents are defined in | |||
| [DIAMBASE] section 2.8. | Diameter base [DIAMBASE] 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 the | |||
| Diameter credit-control application support. | Diameter credit-control application support. | |||
| 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: | this specification. The Command Codes are: | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Command-Name Abbrev. Code Reference | Command-Name Abbrev. Code Reference | |||
| ----------------------------------------------------------- | ----------------------------------------------------------- | |||
| Credit-Control-Request CCR xxx 3.1 | Credit-Control-Request CCR xxx 3.1 | |||
| Credit-Control-Answer CCA xxx 3.2 | Credit-Control-Answer CCA xxx 3.2 | |||
| [IANA please fill in xxx (suggested value 272) and remove this note] | [IANA please fill in xxx (suggested value 272) and remove this note] | |||
| Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code | Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code | |||
| ABNF specification. These formats are observed in Credit-Control | ABNF 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), indicated by the command- | The Credit-Control-Request message (CCR), indicated by the command- | |||
| code field set to xxx [IANA please fill in xxx (suggested value 272) | code field set to xxx [IANA please fill in xxx (suggested value 272) | |||
| and remove this note] and the 'R' bit set in the Command Flags field, | and remove this note] and the 'R' bit set in the Command Flags | |||
| is used between the Diameter credit-control client and the credit- | field, is used between the Diameter credit-control client and the | |||
| control server to request credit authorization for a given service. | credit-control server to request credit authorization for a 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 XXX [IANA please | |||
| Diameter credit-control application. | fill in XXX (suggested value 4 in section 12.1) and remove this | |||
| note] indicating the Diameter credit-control application. | ||||
| Message Format | Message Format | |||
| <Credit-Control-Request> ::= < Diameter Header: xxx, REQ, PXY > | <Credit-Control-Request> ::= < Diameter Header: xxx, 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 } | ||||
| { CC-Request-Type } | { CC-Request-Type } | |||
| { CC-Request-Number } | { CC-Request-Number } | |||
| [ Destination-Host ] | [ Destination-Host ] | |||
| [ User-Name ] | [ User-Name ] | |||
| [ 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 ] | |||
| *[ Subscription-Id ] | *[ Subscription-Id ] | |||
| [ Service-Identifier ] | [ Service-Identifier ] | |||
| [ Termination-Cause ] | [ Termination-Cause ] | |||
| [ Requested-Service-Unit ] | [ Requested-Service-Unit ] | |||
| [ Requested-Action ] | [ Requested-Action ] | |||
| *[ Used-Service-Unit ] | *[ Used-Service-Unit ] | |||
| [ Multiple-Services-Indicator ] | [ Multiple-Services-Indicator ] | |||
| *[ Multiple-Services-Credit-Control | *[ Multiple-Services-Credit-Control | |||
| ] | ] | |||
| *[ Service-Parameter-Info ] | *[ Service-Parameter-Info ] | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| [ CC-Correlation-Id ] | [ CC-Correlation-Id ] | |||
| [ User-Equipment-Info ] | [ User-Equipment-Info ] | |||
| *[ Proxy-Info ] | *[ Proxy-Info ] | |||
| *[ Route-Record ] | *[ Route-Record ] | |||
| *[ AVP ] | *[ AVP ] | |||
| [IANA please fill in xxx (suggested value 272) and remove this note] | [IANA please fill in xxx (suggested value 272) and remove this note] | |||
| 3.2 Credit-Control-Answer (CCA) Command | 3.2 Credit-Control-Answer (CCA) Command | |||
| The Credit-Control-Answer message (CCA), indicated by the command- | The Credit-Control-Answer message (CCA), indicated by the command- | |||
| code field set to xxx [IANA please fill in xxx (suggested value 272) | code field set to xxx [IANA please fill in xxx (suggested value 272) | |||
| and remove this note] and the 'R' bit cleared in the Command Flags | and remove this note] and the 'R' bit cleared in the Command Flags | |||
| field, is used between the credit-control server and the Diameter | field, is used between the credit-control server and the Diameter | |||
| credit-control client to acknowledge a Credit-Control-Request | credit-control client to acknowledge a Credit-Control-Request | |||
| command. | command. | |||
| Message Format | Message Format | |||
| skipping to change at page 11, line 40 ¶ | skipping to change at page 11, line 47 ¶ | |||
| { 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 ] | |||
| *[ Subscription-Id ] | ||||
| [ Granted-Service-Unit ] | [ Granted-Service-Unit ] | |||
| *[ Multiple-Services-Credit-Control ] | *[ Multiple-Services-Credit-Control | |||
| ] | ||||
| [ Cost-Information] | [ Cost-Information] | |||
| [ Final-Unit-Indication ] | [ 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 AVP ] | *[ 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 ] | ||||
| *[ AVP ] | *[ AVP ] | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| [IANA please fill in xxx (suggested value 272) and remove this note] | [IANA please fill in xxx (suggested value 272) and remove this note] | |||
| 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 user's | service delivery to the end user and generally requires user's | |||
| authentication and authorization before any request is sent to the | authentication and authorization before any request is sent to the | |||
| credit-control server. | credit-control server. The credit control application defined in | |||
| this specification supports two different credit authorization | ||||
| The credit control application defined in this specification supports | models: credit authorization with money reservation and credit | |||
| two different credit authorization models: credit authorization with | authorization with direct debiting. In both the models, the credit | |||
| money reservation and credit authorization with direct debiting. | control client requests credit authorization to the credit control | |||
| In both the models, the credit control client requests credit | server prior to allow any service to be delivered to the end user. | |||
| authorization to the credit control server prior to allow any service | ||||
| 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 corresponding amount of credit resources. Note that | returns the corresponding amount of credit resources. Note that | |||
| credit resources may not imply actual monetary credit; credit | credit resources may not imply actual monetary credit; credit | |||
| resources may be granted to the credit control client in form of | resources may be granted to the credit control client in form of | |||
| units (e.g. data volume or time) to be metered. | units (e.g. data volume or time) to be metered. | |||
| Upon reception of a successful credit authorization answer with a | Upon reception 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 | |||
| terminated, the credit control client reports back to the server the | or terminated, the credit control client reports back to the server | |||
| used amount. The credit control server deducts the used amount from | the used amount. The credit control server deducts the used amount | |||
| the end user's account; it may perform rating and make a new credit | from the end user's account; it may perform rating and make a new | |||
| reservation if the service delivery is continuing. This process is | credit reservation if the service delivery is continuing. This | |||
| accomplished with session based credit control that includes the | process is accomplished with session based credit control that | |||
| first interrogation, possible intermediate interrogations and the | includes the first interrogation, possible intermediate | |||
| final interrogation. For session based credit control, both the | interrogations and the final interrogation. For session based credit | |||
| credit control client and the credit control server are required to | control, both the credit control client and the credit control | |||
| maintain credit control session state. | server are required to maintain credit control session state. | |||
| Session based credit control 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 single | |||
| transaction process where the credit control server directly deducts | transaction process where the credit control server directly deducts | |||
| a suitable amount of money from the user's account as soon as the | a suitable amount of money from the user's account as soon as the | |||
| credit authorization request is received. Upon reception of a | credit authorization request is received. Upon reception 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 accomplished | allows service delivery to the end user. This process is | |||
| with the One-time event. Session state is not maintained. | accomplished with the One-time event. Session state is not | |||
| maintained. | ||||
| In a multi-service environment, an end user may issue an additional | In a multi-service environment, an end user may 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) towards the same account; or during an active multimedia | voice call) towards the same account; or during an active multimedia | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| session an additional media type is added to the session causing a | session an additional media type is added to the session causing a | |||
| new simultaneous request towards same account. Consequently this | new simultaneous request towards same account. Consequently this | |||
| needs to be considered when credit resources are granted to the | needs to be considered when credit resources are granted to the | |||
| services. | 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 enquiry, user's balance check and refund of credit on | |||
| the user's account. These operations are accomplished with the One- | the user's account. These operations are accomplished with the One- | |||
| time event. Session state is not maintained. | time event. Session state is not maintained. | |||
| A flexible Credit control application specific failure handling is | A flexible Credit control application specific failure handling is | |||
| defined where the home service provider can model the credit control | defined | |||
| client behavior according to its own credit risk management policy. | where the home service provider can model the credit control client | |||
| behavior according to its own credit risk management policy. | ||||
| The Credit-Control-Failure-Handling AVP and the Direct-Debiting- | The Credit-Control-Failure-Handling AVP and the Direct-Debiting- | |||
| Failure-Handling AVP are defined to determine what to do if the | Failure-Handling AVP are defined to determine what to do if the | |||
| sending of credit-control messages to the credit-control server has | sending of credit-control messages to the credit-control server has | |||
| been temporarily prevented. The usage of Credit-Control-Failure- | been temporarily prevented. The usage of Credit-Control-Failure- | |||
| Handling AVP and the Direct-Debiting-Failure- Handling AVP gives | Handling AVP and the Direct-Debiting-Failure- Handling AVP gives | |||
| flexibility to have different failure handling for credit-control | flexibility to have different failure handling for credit-control | |||
| session and one time event direct debiting. | session and one time event direct debiting. | |||
| 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 could | input in the rating process. Listing the possible services that | |||
| use this Diameter application is seen as out of scope for this | could use this Diameter application is seen as out of scope for this | |||
| generic mechanism as well. | generic mechanism as well. | |||
| It is reasonable to expect that there will exist a service level | Furthermore, it is reasonable to expect that there will exist a | |||
| agreement between providers of the credit control client and the | service level agreement between providers of the credit-control | |||
| credit control server covering the charging, services offered, | client and the credit-control server covering the charging, services | |||
| roaming agreements, agreed rating input, etc. | offered, roaming agreements, agreed rating input (i.e. AVPs), etc. | |||
| Therefore, it is assumed that a Diameter credit control server will | ||||
| provide service only for Diameter credit-control clients that have | ||||
| agreed beforehand the content of credit control messages. Protocol | ||||
| wise, it is naturally possible that any arbitrary Diameter credit- | ||||
| control client can interchange credit control messages with any | ||||
| Diameter credit control server, but with a higher likelihood that | ||||
| unsupported services/AVPs could be present in the credit-control | ||||
| message causing the server to reject the request with an appropriate | ||||
| result-code. | ||||
| 4.1.1 Specifying Rating Input AVPs | ||||
| There are two ways for providing rating input to the credit control | There are two ways for providing rating input to the credit control | |||
| server, either by using AVPs or by including them in the Service- | server, either by using AVPs or by including them in the Service- | |||
| Parameter-Info AVP. The general principle for sending rating | Parameter-Info AVP. The general principles for sending rating | |||
| parameters is that the service SHOULD re-use existing AVPs, if the | parameters are: | |||
| service can use AVPs defined in existing service specific Diameter | ||||
| applications (e.g. NASREQ for network access services). | ||||
| Alternatively, new AVPs can be defined if the existing AVPs do not | ||||
| provide sufficient rating information. 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 BER). In that case the rating input | ||||
| is embedded in the Service-Parameter-Info AVP as defined in section | ||||
| 8.42. New service applications SHOULD favor the use of explicitly | ||||
| defined AVPs, to simplify interoperability. | ||||
| Diameter Credit Control Application May 14, 2004 | 1a. The service SHOULD re-use existing AVPs, if theservice can use | |||
| AVPs defined in existing Diameter applications (e.g. NASREQ for | ||||
| network access services). Re-use of existing AVPs is strongly | ||||
| recommended in [DIAMBASE]. | ||||
| For AVPs of type Enumerated the service may require a new value to | ||||
| be defined. Allocation of new AVP values is done as specified in | ||||
| [DIAMBASE], section 1.2. | ||||
| 1b. New AVPs can be defined if the existing AVPs do not provide | ||||
| sufficient rating information. In such a case, the procedures | ||||
| defined in [DIAMBASE] for creating new AVPs MUST be followed. | ||||
| 1c. 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 are encouraged instead, refer to | ||||
| [DIAMBASE]. | ||||
| 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 | ||||
| BER). This method can be used to avoid unnecessary data format | ||||
| conversions from an existing format to an AVP format. In that case | ||||
| the rating input is embedded in the Service-Parameter-Info AVP as | ||||
| defined in section 8.43. | ||||
| New service applications SHOULD favor the use of explicitly defined | ||||
| AVPs as described in items 1a and 1b, to simplify interoperability. | ||||
| 4.1.2 Service-Specific Documentation | ||||
| The service specific rating input AVPs, the contents of the Service- | The service specific rating input AVPs, the contents of the Service- | |||
| Parameter-Info AVP or Service-Identifier AVP are not within the scope | Parameter-Info AVP or Service-Context-Id AVP (defined in section | |||
| of this document. To facilitate interoperability, it is RECOMMENDED | 8.42) are not within the scope of this document. To facilitate | |||
| that the rating input and values of service identifiers are | interoperability, it is RECOMMENDED that the rating input and the | |||
| coordinated via an informational RFC or other permanent and readily | values of the Service-Context-Id are coordinated via an | |||
| available reference such as the specification of another cooperative | informational RFC or other permanent and readily available reference | |||
| standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. | such as the specification of another cooperative standardization | |||
| However, private services may be deployed that are subject to | body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private | |||
| agreements between providers of the credit control server and client, | services may be deployed that are subject to agreements between | |||
| 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 service specific documents, is | This specification, together with the above service specific | |||
| governing the credit control message. The rule is that service | documents, governs the credit control message. The rule is that | |||
| specific documents only define what existing AVPs or new AVPs are | service specific documents define what existing AVPs or new AVPs are | |||
| used as input to the rating process (i.e. they do not define new | used as input to the rating process (i.e. they do not define new | |||
| credit control applications), and thus need to be included in the | credit control applications), and thus need to be included in the | |||
| Credit-Control-Request command by a Diameter Credit Control Client | Credit-Control-Request command by a Diameter Credit Control Client | |||
| supporting a given service as *[AVP]. In order to define new AVPs, | supporting a given service as *[AVP]. Should Service-Parameter-Info | |||
| service specific documents MUST follow the practices defined in | be used, then the service specific document MUST specify the exact | |||
| [DIAMBASE]. The service SHOULD be identified using the Service- | content of this grouped AVP. | |||
| Identifier AVP. The Service-Identifier AVP MUST be a unique | ||||
| identifier for a given service as defined in section 8.28. | ||||
| As a result it is the combination of support of the Diameter Credit | The Service-Context-Id AVP MUST be included at the command level of | |||
| Control Application and the service defined in the Service-Identifier | a Credit Control Request to identify the service specific document | |||
| AVP, which defines interoperability between any given credit control | that applies to the request. The specific service or rating group | |||
| client and server. | that the request relates to is uniquely identified by the | |||
| combination of Service-Context-Id and Service-Identifier or Rating- | ||||
| Group. | ||||
| 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 the | |||
| Mandatory rating AVPs defined in service specific documentation of | Mandatory rating AVPs defined in service specific documentation of | |||
| the services they support. Introducing new credit control mechanisms | the services they support according to the 'M' bit rules in | |||
| not defined in this specification implies the definition of a new | [DIAMBASE]. | |||
| version of the Diameter Credit Control Application and corresponding | In case a rating input required for the rating process is incorrect | |||
| Application Identifier. | in the Credit control request, or the credit control server does not | |||
| support the requested service context (identified by the Service- | ||||
| Context-Id AVP at command level), the Credit control answer MUST | ||||
| contain error code DIAMETER_RATING_FAILED. A CCA message with this | ||||
| error MUST contain one or more Failed-AVP AVPs containing the | ||||
| missing and/or unsupported AVPs that caused the failure. A Diameter | ||||
| credit control client receiving error code DIAMETER_RATING_FAILED in | ||||
| answer to a request MUST NOT send such similar requests in the | ||||
| future. | ||||
| 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 [NASREQ] for formatting the Diameter AVP MUST be | rules described in [NASREQ] for formatting the Diameter AVP MUST be | |||
| followed. For example, the AVP code used is the vendor attribute type | followed. | |||
| code, 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 field contains only the attribute value of the RADIUS attribute. | ||||
| In case a rating input required for the rating process is incorrect | ||||
| in the Credit control request, or the credit control server does not | ||||
| support the requested service, the Credit control answer MUST contain | ||||
| error code DIAMETER_RATING_FAILED. A CCR message with this error MUST | ||||
| contain one or more Failed-AVP AVPs containing the missing and/or | ||||
| Diameter Credit Control Application May 14, 2004 | ||||
| unsupported AVPs that caused the failure. A Diameter credit control | For example, the AVP code used is the vendor attribute type code, | |||
| client receiving error code DIAMETER_RATING_FAILED in answer to a | the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be | |||
| request MUST NOT send such similar requests in the future. | set to the IANA Vendor identification value. The Diameter AVP data | |||
| 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 a session-based credit-control, several interrogations are | |||
| needed: the first, intermediate (optional) and the final | needed: the first, intermediate (optional) and the final | |||
| interrogation. This is illustrated in Figure 2 and Figure 3. | interrogation. This is illustrated in Figure 2 and Figure 3. | |||
| 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 | |||
| towards the credit-control server (i.e. session based credit- | towards the credit-control server (i.e. session based credit- | |||
| control). In this case the credit-control server MUST maintain the | control). In this case the credit-control server MUST maintain the | |||
| credit control session state. | credit control session state. | |||
| skipping to change at page 15, line 38 ¶ | skipping to change at page 16, line 39 ¶ | |||
| There are certain applications that require multiple credit control | There are certain applications that require multiple credit control | |||
| sub-sessions. Such applications would send messages with a constant | sub-sessions. Such applications would send messages with a constant | |||
| Session-Id AVP, but a different CC-Sub-Session-Id AVP. If several | Session-Id AVP, but a different CC-Sub-Session-Id AVP. If several | |||
| credit sub-sessions will be used, all sub-sessions MUST be closed | credit sub-sessions will be used, all sub-sessions MUST be closed | |||
| separately before closing the main session to be able to report used | separately before closing the main session to be able to report used | |||
| units per sub-session. The absence of this AVP implies no sub- | units per sub-session. The absence of this AVP implies no sub- | |||
| sessions are in use. | sessions are in use. | |||
| It should be noted that the service element might send a service | It should be noted that the service element might send a service | |||
| specific re-authorization message to the AAA server due to expiration | specific re-authorization message to the AAA server due to | |||
| of the authorization-lifetime during an ongoing credit control | expiration of the authorization-lifetime during an ongoing credit | |||
| session. However, the service specific re-authorization does not | control session. However, the service specific re-authorization does | |||
| influence the credit authorization that is ongoing between credit- | not influence the credit authorization that is ongoing between | |||
| control client and credit-control server since credit authorization | credit-control client and credit-control server since credit | |||
| is controlled by the burning rate of the granted quota. | authorization is controlled by the burning rate of the granted | |||
| quota. | ||||
| In the event that service specific re-authorization fails the user | In the event that service specific re-authorization fails the user | |||
| will be disconnected and the credit-control client MUST send a final | will be 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 want to control the validity | The Diameter credit-control server may want 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 credit- | |||
| control update request and report the used quota to the credit- | control update request and report the used quota to the credit- | |||
| control server. It is up to the credit-control server to determine, | control server. It is up to the credit-control server to determine, | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| the value of the Validity-Time to be used for consumption of the | the value of the Validity-Time to be used for consumption of the | |||
| granted service units. If the Validity-Time is used, its value SHOULD | granted service units. If the Validity-Time is used, its value | |||
| be given as input to set the session supervision timer Tcc (the | SHOULD be given as input to set the session supervision timer Tcc | |||
| session supervision timer MAY be set to two times the value of the | (the session supervision timer MAY be set to two times the value of | |||
| Validity-Time as defined in section 13). Since credit-control update | the Validity-Time as defined in section 13). Since credit-control | |||
| requests are also produced at the expiry of granted service units | update requests are also produced at the expiry of granted service | |||
| and/or for mid-session service events the omission of Validity-Time | units and/or for mid-session service events the omission of | |||
| does not mean that intermediate interrogation for the purpose of | Validity-Time does not mean that intermediate interrogation for the | |||
| credit control are not performed. | purpose of credit control are not performed. | |||
| 5.1.1 Basic Tariff-Time Change Support | ||||
| 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 the | include a Tariff-Time-Change AVP in the answer message. Note that | |||
| granted units should be allocated based on the worst-case scenario in | the granted units should be allocated based on the worst-case | |||
| case of forthcoming tariff change, so that the overall reported used | scenario in case of forthcoming tariff change, so that the overall | |||
| units would never exceed the credit reservation. | reported used units would never exceed the credit reservation. | |||
| 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 then the | tariff change has occurred during the reporting period then the | |||
| Diameter credit-control client MUST separately itemize the units used | Diameter credit-control client MUST separately itemize the units | |||
| before and after the tariff change. In case the client is unable to | used before and after the tariff change. In case the client is | |||
| distinguish whether units that straddle the tariff change are used | unable to distinguish whether units that straddle the tariff change | |||
| before or after the tariff change, the credit-control client MUST | are used before or after the tariff change, the credit-control | |||
| itemize those units in a third category. | client MUST itemize those units 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 continuously consumed at the | |||
| regular rate of 60 seconds per minute, the server already knows at | regular rate of 60 seconds per minute, the server already knows at | |||
| the time when credit resources are allocated how many units will be | the time when credit resources are allocated how many units will be | |||
| consumed before the tariff time change and how many units will be | consumed before the tariff time change and how many units will be | |||
| consumed after. Similarly, the server can determine the units | consumed after. Similarly, the server can determine the units | |||
| consumed at the before rate and the units consumed at the rate | consumed at the before rate and the units consumed at the rate | |||
| afterwards in the event that the end-user closes the session before | afterwards in the event that the end-user closes the session before | |||
| the consumption of the allotted quota. There is no need for | the consumption of the allotted quota. There is no need for | |||
| additional traffic between client and server in case of tariff time | additional traffic between client and server in case of tariff time | |||
| changes for continuous time based service, therefore the tariff | changes for continuous time based service, therefore the tariff | |||
| change mechanism is not used for continuous time based services. For | change mechanism is not used for continuous time based services. For | |||
| time-based services where the quota is NOT continuously consumed at a | time-based services where the quota is NOT continuously consumed at | |||
| regular rate, the tariff change mechanism described for volume and | a regular rate, the tariff change mechanism described for volume and | |||
| event units MAY be used. | event units MAY be used. | |||
| 5.1.1 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 one user session and each | When multiple services are used within one user session and each | |||
| service or group of services are subject to different cost, it is | service or group of services are subject to different cost, it is | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| necessary to perform credit-control for each of these services | necessary to perform credit-control for each of these services | |||
| independently. Making use of credit control sub-sessions to achieve | independently. Making use of credit control sub-sessions to achieve | |||
| independent credit-control will result in increased signaling load | independent credit-control will result in increased signaling load | |||
| and resources usage in both the credit control client and the credit | and resources usage in both the credit control client and the credit | |||
| control server. For instance, during one network access session the | control server. For instance, during one network access session the | |||
| end user may use several http-services subject to different access | end user may use several http-services subject to different access | |||
| cost, the network access specific attributes such as the quality of | cost, the network access specific attributes such as the quality of | |||
| service (QoS) are common to all the services carried within the | service (QoS) are common to all the services carried within the | |||
| access bearer, but the cost of the bearer may vary depending on its | access bearer, but the cost of the bearer may vary depending on its | |||
| content. | content. | |||
| To optimally support these scenarios, the credit control application | To optimally support these scenarios, the credit control application | |||
| enables for independent credit control of multiple services in a | enables for independent credit control of multiple services in a | |||
| single credit control (sub-)session. This is achieved by including | single credit control (sub-)session. This is achieved by including | |||
| the optional Multiple-Services-Credit-Control AVP in Credit-Control- | the optional Multiple-Services-Credit-Control AVP in Credit-Control- | |||
| Request/Answer messages. It is possible to request and allocate | Request/Answer messages. It is possible to request and allocate | |||
| resources as a credit pool that is shared between multiple services. | resources as a credit pool that is shared between multiple services. | |||
| The services can be further grouped into rating groups in order to | The services can be further grouped into rating groups in order to | |||
| achieve even further aggregation of credit allocation. It is also | achieve even further aggregation of credit allocation. It is also | |||
| possible to request and allocate quotas on a per service basis. Where | possible to request and allocate quotas on a per service basis. | |||
| quotas are allocated to a pool by means of the Multiple-Services- | Where quotas are allocated to a pool by means of the Multiple- | |||
| Credit-Control AVP, the quotas remain independent objects that can be | Services-Credit-Control AVP, the quotas remain independent objects | |||
| re-authorized independently at any time. Quotas can also be given | that can be re-authorized independently at any time. Quotas can also | |||
| independent result codes, validity times and Final-Unit-Indications. | be given independent result codes, validity times and Final-Unit- | |||
| Indications. | ||||
| A Rating-group groups a set of services, identified by a Service- | A Rating-group groups a set of services, identified by a Service- | |||
| Identifier, subject to the same cost and rating type (e.g. | Identifier, subject to the same cost and rating type (e.g. | |||
| $0.1/minute). It is assumed that the service element is provided, by | $0.1/minute). It is assumed that the service element is provided, by | |||
| means outside the scope of this specification, with Rating-Groups, | means outside the scope of this specification, with Rating-Groups, | |||
| with Service-Identifiers and their associated parameters that define | with Service-Identifiers and their associated parameters that define | |||
| what need to be metered (example of parameters associated to Service- | what need to be metered (example of parameters associated to | |||
| Identifiers are IP 5-tuple, HTTP URL etc.). Service-identifiers | Service-Identifiers are IP 5-tuple, HTTP URL etc.). Service- | |||
| enable on a per-service based credit authorization as well as | identifiers enable on a per-service based credit authorization as | |||
| itemized reporting of service usage. It is up to the credit control | well as itemized reporting of service usage. It is up to the credit | |||
| server whether to authorize credit for one or more services or for | control server whether to authorize credit for one or more services | |||
| the whole rating-group, but the client SHOULD always report used | or for the whole rating-group. However, the client SHOULD always | |||
| units itemizing the service level usage. Where quota is allocated to | report used units at the finest level of granularity that it | |||
| a rating-group, all the services belonging to that rating-group draw | supports. Where quota is allocated to a rating-group, all the | |||
| from the allotted quota. The following is a graphical representation | services belonging to that rating-group draw from the allotted | |||
| of the relation between service-identifiers, rating-groups, credit | quota. The following is a graphical representation of the relation | |||
| pools and credit-control (sub-)session. | between service-identifiers, rating-groups, credit pools and credit- | |||
| control (sub-)session. | ||||
| Diameter Credit Control Application May 14, 2004 | ||||
| DCC (Sub-)Session | DCC (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 2.......Rating-Group n | \ / Rating-Group 1.......Rating-Group n | |||
| | | | | \ / | | | |||
| Quota- ---------------Quota Quota | Quota ---------------Quota Quota | |||
| \ / | | | / | | |||
| \ / | | | / | | |||
| Credit-Pool Credit-Pool | Credit-Pool Credit-Pool | |||
| In case independent credit control of multiple services is used, the | In case independent credit control of multiple services is used, the | |||
| validity-time and final-unit-indication SHOULD be present either in | validity-time and final-unit-indication SHOULD be present either in | |||
| the Multiple-Service-Credit-Control AVP(s) or at command level as | the Multiple-Services-Credit-Control AVP(s) or at command level as | |||
| single AVPs. However, the Result-Code AVP MAY be present both on the | single AVPs. However, the Result-Code AVP MAY be present both on the | |||
| command level and within the Multiple-Services-Credit-Control AVP. If | command level and within the Multiple-Services-Credit-Control AVP. | |||
| the Result-Code on the command level indicates other value than | If the Result-Code on the command level indicates other value than | |||
| SUCCESS then the Result-Code on command level takes precedence over | SUCCESS then the Result-Code on command level takes precedence over | |||
| the one(s) included in the Multiple-Services-Credit-Control AVP. | the one(s) 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 the feature | interrogation. A Credit-Control-server not supporting the feature | |||
| MUST treat the Multiple-Services-Indicator AVP and possibly received | MUST treat the Multiple-Services-Indicator AVP and possibly 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 whishes 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- | |||
| and/or rating-group. | identifier and/or rating-group. | |||
| To avoid a situation where several parallel, and typically also | ||||
| small, credit reservations must be made on the same account (i.e. | ||||
| credit fragmentation) and also to avoid unnecessary load on the | ||||
| credit control server, it is possible to provide service units as a | ||||
| 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 | ||||
| particular service or rating group in the Multiple-Services-Credit- | ||||
| Control AVP, but also including a reference to a credit pool for | ||||
| that unit type. | ||||
| To avoid credit fragmentation and unnecessary load on the credit | ||||
| control server, it is possible for service units to be provided to | ||||
| multiple services or rating groups as a pool. This is achieved by | ||||
| providing the service units in the form of a quota for a particular | ||||
| service or rating group in the Multiple-Services-Credit-Control AVP, | ||||
| but also including a reference to a credit pool for 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 rating parameter for service 2 | parameter for service 1 is $1/MB and rating parameter for service 2 | |||
| is $0.5/MB the multipliers could be 10 and 5 for service 1 and | is $0.5/MB the multipliers could be 10 and 5 for service 1 and | |||
| service 2 respectively. | service 2 respectively. | |||
| Diameter Credit Control Application May 14, 2004 | If S is the total service units within the pool, M1, M2, ... , Mn | |||
| are the multipliers provided for services 1, 2, ..., n and C1, | ||||
| If M is the total service units within the pool, M1, M2, ... , Mn are | C2,... ,Cn are the used resources within the session, then the pool | |||
| the multipliers provided for services 1, 2, ..., n and C1, C2,... ,Cn | credit is exhausted and re-authorization MUST be sought when: | |||
| are the used resources within the session, then the pool credit is | ||||
| exhausted and re-authorization MUST be sought when: | ||||
| C1*M1 + C2*M2 + ... + Cn*Mn >= M | C1*M1 + C2*M2 + ... + Cn*Mn >= S | |||
| The total credit in the pool, M, 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: | |||
| M = 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 need 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 or | sought at any time, for example if a 'non-pooled' quota is used up | |||
| 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 | |||
| G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit- | same G-S-U-Pool-Identifier are provided within a Multiple-Services- | |||
| Control AVP (section 8.16) together with the Granted-Service-Unit | Credit-Control AVP (section 8.16) together with the Granted-Service- | |||
| AVP, then these MUST have different CC-Unit-Type values and they all | Unit AVP, then these MUST have different CC-Unit-Type values and | |||
| draw on the credit pool separately. For instance, if one multiplier | they all draw on the credit pool separately. For instance, if one | |||
| for time (M1t) and one multiplier for volume (M1v) are given, then | multiplier for time (M1t) and one multiplier for volume (M1v) are | |||
| the used resources from the pool is the sum C1t*M1t + C1v*M1v, where | given, then the used resources from the pool is the sum C1t*M1t + | |||
| C1t are the time units and C1v are the volume unit. | C1v*M1v, where C1t are the time units and C1v are 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-Reference AVP then these | Control AVP without a corresponding G-S-U-Reference AVP then these | |||
| are handled independently from any credit pool and from any other | are handled independently from any credit pool and from any other | |||
| services or rating groups within the session. | 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 over- | |||
| reservation effect of the basic single quota tariff time change | reservation effect of the basic single quota tariff time change | |||
| mechanism (the mechanism described in section 5.1). Therefore, | mechanism (the mechanism described in section 5.1.1). Therefore, | |||
| Diameter credit-control clients and servers implementing the | Diameter credit-control clients and servers implementing the | |||
| independent credit control of multiple services SHOULD leverage the | independent credit control of multiple services SHOULD leverage the | |||
| credit pool concept when supporting the tariff time change. The | credit pool concept when supporting the tariff time change. The | |||
| Diameter credit-control server SHOULD include both the Tariff-Time- | Diameter credit-control server SHOULD include both the Tariff-Time- | |||
| Change and Tariff-Change-Usage AVPs in two quota allocations in the | Change and Tariff-Change-Usage AVPs in two quota allocations in the | |||
| answer message (i.e. two instances of the Multiple-Services-Credit- | answer message (i.e. two instances of the Multiple-Services-Credit- | |||
| Control AVP). One of the granted units is allocated to be used before | Control AVP). One of the granted units is allocated to be used | |||
| the potential tariff change while the second granted units are used | before the potential tariff change while the second granted units | |||
| after a tariff change. Both granted unit quotas MUST contain the same | are used after a tariff change. Both granted unit quotas MUST | |||
| contain the same Service-Identifier and/or Rating-Group. This dual | ||||
| Diameter Credit Control Application May 14, 2004 | quota mechanism ensures that the overall reported used units would | |||
| never exceed the credit reservation. The Diameter credit-control | ||||
| Service-Identifier and/or Rating-Group. This dual quota mechanism | client reports both the used units before and after the tariff | |||
| ensures that the overall reported used units would never exceed the | change in a single instance of the Multiple-Services-Credit-Control | |||
| credit reservation. The Diameter credit-control client reports both | AVP. | |||
| the used units before and after the tariff change in a single | ||||
| instance of the Multiple-Services-Credit-Control AVP. | ||||
| The failure handling for credit control sessions is defined in | The 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 machine | |||
| in section 7 Credit-control clients and servers implementing the | in section 7 Credit-control clients and servers implementing the | |||
| independent credit control of multiple services in a (sub-)session | independent credit control of multiple services in a (sub-)session | |||
| functionality MUST ensure failure handling and general behavior fully | functionality MUST ensure failure handling and general behavior | |||
| consistent with the above mentioned sections while capable of | fully consistent with the above mentioned sections while capable of | |||
| handling parallel ongoing credit re-authorization within a (sub- | handling parallel ongoing credit re-authorization within a (sub- | |||
| )session. It is then RECOMMENDED that Diameter credit-control clients | )session. It is then RECOMMENDED that Diameter credit-control | |||
| maintain a PENDING-U message queue and restarts the Tx timer (section | clients maintain a PENDING-U message queue and restarts the Tx timer | |||
| 13) every time a CCR message with value UPDATE_REQUEST is sent while | (section 13) every time a CCR message with value UPDATE_REQUEST is | |||
| in PENDING-U state. When answers to all the pending messages are | sent while in PENDING-U state. When answers to all the pending | |||
| received the state machine moves to OPEN and Tx is stopped. Naturally | messages are received the state machine moves to OPEN and Tx is | |||
| the action performed when a problem is detected for the session | stopped. Naturally the action performed when a problem is detected | |||
| according to section 5.7, affect all the ongoing services (e.g. | for the session according to section 5.7, affect all the ongoing | |||
| failover to a backup server if possible affect all the CCR messages | services (e.g. failover to a backup server if possible affect all | |||
| with value UPDATE_REQUEST in the PENDING-U queue). | the CCR messages with value UPDATE_REQUEST in the PENDING-U queue). | |||
| Since the client may send CCR messages with value UPDATE_REQUEST | Since the client may send CCR messages with value UPDATE_REQUEST | |||
| while in PENDING-U (i.e. without waiting for an answer to ongoing | while in PENDING-U (i.e. without waiting for an answer to ongoing | |||
| credit re-authorization), the time space between these requests may | credit re-authorization), the time space between these requests may | |||
| be very short and the server may not have received the previous | be very short and the server may not have received the previous | |||
| request(s) yet. Therefore in this situation the server may receive | request(s) yet. Therefore in this situation the server may receive | |||
| out of sequence requests and SHOULD NOT consider this as an error | out of sequence requests and SHOULD NOT consider this as an error | |||
| condition, a proper answer is to be returned to each of those | 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 prepaid user), the first | authentication server indicated 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 event to the end user. The CC-Request-Type is set | |||
| to the value INITIAL_REQUEST in the request message. | 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 | |||
| Service-Unit AVP. If the Diameter credit-control client does not know | Requested-Service-Unit AVP. If the Diameter credit-control client | |||
| the cost of the service event, the Requested-Service-Unit AVP MAY | does not know the cost of the service event, the Requested-Service- | |||
| contain the number of requested service events. Where the Multiple- | Unit AVP MAY contain the number of requested service events. Where | |||
| Services-Credit-Control AVP is used, it MUST contain the Requested- | the Multiple-Services-Credit-Control AVP is used, it MUST contain | |||
| Service-Unit AVP to indicate that quota for the associated | the Requested-Service-Unit AVP to indicate that quota for the | |||
| service/rating-group is requested. The Service-Identifier AVP, in | associated service/rating-group is requested. In case of multiple | |||
| services, the Service-Identifier AVP or the Rating-Group AVP within | ||||
| Diameter Credit Control Application May 14, 2004 | the Multiple-Services-Credit-Control AVP, always indicates the | |||
| concerned service. Additional service event information to be rated | ||||
| case of multiple services the Service-Identifier AVP or the Rating- | MAY be sent as service specific AVPs or MAY be sent within the | |||
| Group AVP within the Multiple-Services-Credit-Control AVP, always | Service-Parameter-Info AVP at command level. The Service-Context-Id | |||
| indicates the concerned service. Additional service event | AVP indicates the service specific document applicable to the | |||
| information to be rated MAY be sent as service specific AVPs or MAY | request. | |||
| be sent within the Service-Parameter-Info AVP at command level. | ||||
| The Event-Timestamp AVP contains the time when the service event is | The Event-Timestamp AVP SHOULD be included in the request and | |||
| requested in the service element. The Subscription-Id AVP SHOULD be | contains the time when the service event is requested in the service | |||
| included to identify the End-User in the credit-control server. The | element. The Subscription-Id AVP SHOULD be included to identify the | |||
| credit control client MAY include the User-Equipment-Info AVP so that | End-User in the credit-control server. The credit control client MAY | |||
| the credit control server has some indication about the type and | include the User-Equipment-Info AVP so that the credit control | |||
| capabilities of the end user access device. How the credit control | server has some indication about the type and capabilities of the | |||
| server uses this information is outside the scope of this document. | end user access device. How the credit control 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 amount | |||
| is reserved from end user's account. | is reserved from 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 | |||
| Answer message to the Diameter credit-control client. The Granted- | the Answer message to the Diameter credit-control client. The | |||
| Service-Unit AVP contains the amount of service units that the | Granted-Service-Unit AVP contains the amount of service units that | |||
| Diameter credit-control client can provide to the end user until a | the Diameter credit-control client can provide to the end user until | |||
| new Credit-Control-Request MUST be sent to the credit-control server. | a new Credit-Control-Request MUST be sent to the credit-control | |||
| If several unit types are sent in the Answer message the credit- | server. If several unit types are sent in the Answer message the | |||
| control client MUST handle each unit type separately. The type of the | credit-control client MUST handle each unit type separately. The | |||
| Granted-Service-Unit AVP can be time, volume, service specific or | type of the Granted-Service-Unit AVP can be time, volume, service | |||
| money depending on the type of service event. The unit type(s) SHOULD | specific or money depending on the type of service event. The unit | |||
| NOT be changed within an ongoing credit-control session. | type(s) SHOULD NOT be changed within an ongoing credit-control | |||
| session. | ||||
| There MUST be maximum one instance of the same unit type in one | There MUST be maximum one instance of the same unit type in one | |||
| Answer message. However, in case multiple quotas are conveyed to the | Answer message. However, in case 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- | |||
| server wants to make a distinction between the granted quota before | control server wants to make a distinction between the granted quota | |||
| and after tariff change. | before and after 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 that | needed for the service it MAY include the result code indicating | |||
| the credit-control is not applicable (e.g. service is free of | that the credit-control is not applicable (e.g. service is free of | |||
| charge). This result code at command level implies that the credit- | charge). This result code at command level implies that the credit- | |||
| control session is to be terminated. | 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 to indicate that the answer message contains the final | Indication AVP to indicate that the answer message contains the | |||
| units for the service. After the end user has consumed these units, | final units for the service. After the end user has consumed these | |||
| units, the Diameter credit-control-client MUST behave as described | ||||
| Diameter Credit Control Application May 14, 2004 | in section 5.6. | |||
| the Diameter credit-control-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 to perform the first | |||
| interrogation to be used indifferent network architectures. The first | interrogation to be used indifferent network architectures. The | |||
| approach uses credit-control messages after user's authorization and | first approach uses credit-control messages after user's | |||
| authentication took place. The second approach uses service specific | authorization and authentication took place. The second approach | |||
| authorization messages to perform the first interrogation during the | uses service specific authorization messages to perform the first | |||
| user's authorization/authentication phase, and credit-control | interrogation during the user's authorization/authentication phase, | |||
| messages for the intermediate and the final interrogations. In case | and credit-control messages for the intermediate and the final | |||
| an implementation of the credit-control client supports both the | interrogations. In case an implementation of the credit-control | |||
| methods, it SHOULD be configurable what method to use. | client supports both the methods, it SHOULD be configurable what | |||
| method to use. | ||||
| In service environments such as the Network Access Server (NAS), it | In service environments such as the Network Access Server (NAS), it | |||
| is desired to perform the first interrogation as part of the | is desired to perform the first interrogation as part of the | |||
| authorization/authentication process for the sake of protocol | authorization/authentication process for the sake of protocol | |||
| efficiency. Further credit authorizations after the first | efficiency. Further credit authorizations after the first | |||
| interrogation took place are performed with credit control commands | interrogation took place are performed with credit control commands | |||
| defined in this specification. Implementations of credit-control | defined in this specification. Implementations of credit-control | |||
| client operating in the mentioned environments SHOULD support this | client operating in the mentioned environments SHOULD support this | |||
| method. In case the credit-control server and AAA server are separate | method. In case the credit-control server and AAA server are | |||
| physical entities the service element sends the request messages to | separate physical entities the service element sends the request | |||
| the AAA server, which then issue an appropriate request or proxy the | messages to the AAA server, which then issue an appropriate request | |||
| received request forward to the credit-control server. | or proxy the 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 | |||
| scenario, there is a substantial decoupling between | scenario, there is a substantial decoupling between | |||
| registration/access to the network and the actual service request | registration/access to the network and the actual service request | |||
| (i.e. the authentication/authorization is executed once at | (i.e. the authentication/authorization is executed once at | |||
| registration/access to the network and is not executed for every | registration/access to the network and is not executed for every | |||
| service event requested by the subscriber). In such environments it | service event requested by the subscriber). In such environments it | |||
| is more appropriate to perform the first interrogation after the user | is more appropriate to perform the first interrogation after the | |||
| has been authenticated and authorized. The first interrogation, the | user has been authenticated and authorized. The first interrogation, | |||
| intermediate and final interrogations are executed with credit | the intermediate and final interrogations are executed with credit | |||
| control commands defined in this specification. | control commands 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 what is the most suitable method in their | bodies may define what is the most suitable method in their | |||
| architecture. | architecture. | |||
| 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 whether credit-control is | information from the authorization server whether credit-control is | |||
| required based on its knowledge of the end user. If credit-control is | required based on its knowledge of the end user. If credit-control | |||
| required the credit-control server needs to be contacted prior to | is required the credit-control server needs to be contacted prior to | |||
| initiating service delivery to the end user. The accounting protocol | initiating service delivery to the end user. The accounting protocol | |||
| and the credit-control protocol can be used in parallel, the | and the credit-control protocol can be used in parallel, the | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| authorization server may also drive whether the parallel accounting | authorization server may also drive whether the parallel accounting | |||
| stream is required. | stream is required. | |||
| The following diagram illustrates the case where both protocols are | The following diagram illustrates the case where both protocols are | |||
| used in parallel and the service element sends credit-control | used in parallel and the service element sends credit-control | |||
| messages directly to the credit-control server. More credit-control | messages directly to the credit-control server. More credit-control | |||
| sequence examples are given in Annex A. | sequence examples are given in Annex A. | |||
| Diameter | Diameter | |||
| End-User Service Element AAA Server CC Server | End-User Service Element AAA Server CC Server | |||
| (CC Client) | (CC Client) | |||
| skipping to change at page 24, line 5 ¶ | skipping to change at page 25, line 15 ¶ | |||
| | | ACR(stop) | | | | | ACR(stop) | | | |||
| | |------------------->| | | | |------------------->| | | |||
| | | ACA | | | | | ACA | | | |||
| | |<-------------------| | | | |<-------------------| | | |||
| Figure 2: Protocol example with first interrogation after user's | Figure 2: Protocol example with first interrogation after user's | |||
| authorization/authentication | authorization/authentication | |||
| 5.2.2 Authorization Messages for First Interrogation | 5.2.2 Authorization Messages for First Interrogation | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 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 credit | |||
| control AVPs. The credit-control client MUST add the Credit-Control | control AVPs. The credit-control client MUST add the Credit-Control | |||
| AVP to indicate credit-control capabilities and MAY add other | AVP to indicate credit-control capabilities and MAY add other | |||
| relevant credit-control specific AVPs to the proper | relevant credit-control specific AVPs to the proper | |||
| authorization/authentication command to perform the first | authorization/authentication command to perform the first | |||
| interrogation towards the home Diameter AAA server. The Auth- | interrogation towards the home Diameter AAA server. The Auth- | |||
| Application-Id is set to the appropriate value as defined in the | Application-Id is set to the appropriate value as defined in the | |||
| relevant service specific authorization/authentication application | relevant service specific authorization/authentication application | |||
| document (e.g. [NASREQ], [DIAMMIP]). The home Diameter AAA server | document (e.g. [NASREQ], [DIAMMIP]). The home Diameter AAA server | |||
| authenticates/authorizes the subscriber and determines whether or not | authenticates/authorizes the subscriber and determines whether or | |||
| credit-control is required. | not 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 AA | |||
| answer message. If credit-control is required for the subscriber and | answer message. If credit-control is required for the subscriber and | |||
| the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was | 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 | |||
| If credit-control is required for the subscriber and the Credit- | interrogation. If credit-control is required for the subscriber and | |||
| Control AVP was not present in the authorization request, the home | the Credit-Control AVP was not present in the authorization request, | |||
| AAA server MUST send an authorization reject answer message. | the 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 | |||
| the Credit-Control-Request command (CCR) defined in this document to | send the Credit-Control-Request command (CCR) defined in this | |||
| the credit-control server. The Diameter AAA server populates the CCR | document to the credit-control server. The Diameter AAA server | |||
| based on service specific AVPs used for input to the rating process | populates the CCR based on service specific AVPs used for input to | |||
| and possibly credit-control AVPs received in the AA request. The | the rating process and possibly credit-control AVPs received in the | |||
| credit-control server will make money reservation from the user's | AA request. The credit-control server will make money reservation | |||
| account, will rate the request and will send a credit-control answer | from the user's account, will rate the request and will send a | |||
| message to the home Diameter AAA server. The answer message includes | credit-control answer message to the home Diameter AAA server. The | |||
| the Granted-Service-Unit AVP(s) and MAY include other credit-control | answer message includes the Granted-Service-Unit AVP(s) and MAY | |||
| specific AVPs as appropriate. Additionally, the credit-control server | include other credit-control specific AVPs as appropriate. | |||
| MAY set the Validity-Time and MAY include the Credit-Control-Failure- | Additionally, the credit-control server MAY set the Validity-Time | |||
| Handling AVP and the Direct-Debiting-Failure-Handling AVP to | and MAY include the Credit-Control-Failure-Handling AVP and the | |||
| determine what to do if the sending of credit-control messages to the | Direct-Debiting-Failure-Handling AVP to determine what to do if the | |||
| credit-control server has been temporarily prevented. | sending of credit-control messages to the 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 credit- | |||
| control server, the home Diameter AAA server will populate the AA | control server, the home Diameter AAA server will populate the AA | |||
| answer with the received credit-control AVPs and with usual service | answer with the received credit-control AVPs and with usual service | |||
| attributes according to the authorization/authentication specific | attributes according to the authorization/authentication specific | |||
| application (e.g. [NASREQ], [DIAMMIP]) and forward the packet to the | application (e.g. [NASREQ], [DIAMMIP]) and forward the packet to the | |||
| credit-control client. If the home Diameter AAA server receives a | credit-control client. If the home Diameter AAA server receives a | |||
| credit-control reject message, it will simply generate an appropriate | credit-control reject message, it will simply generate an | |||
| authorization reject message to the credit-control client including | appropriate authorization reject message to the credit-control | |||
| the credit-control specific error code. | client including the credit-control specific error code. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| The credit-control client in this model sends further credit-control | The credit-control client in this model 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 successful authorization answer message with | server. Upon receiving successful authorization answer message with | |||
| the Granted-Service-Unit AVP(s), the credit-control client will grant | the Granted-Service-Unit AVP(s), the credit-control client will | |||
| the service to the end user and will generate intermediate credit- | grant the service to the end user and will generate intermediate | |||
| control request as required by using Credit-Control commands. The CC- | credit-control request as required by using Credit-Control commands. | |||
| Request-Number of the first UPDATE_REQUEST MUST be set to 1 (for how | The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 | |||
| to produce unique value for the CC-Request-Number AVP see section | (for how to produce unique value for the CC-Request-Number AVP see | |||
| 8.2). | section 8.2). | |||
| If service specific re-authorization is performed (i.e. | If service specific re-authorization is performed (i.e. | |||
| 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 value set to RE-AUTHORIZATION to indicate that the credit- | AVP with value set to RE-AUTHORIZATION to indicate that the credit- | |||
| control server MUST NOT be contacted. When session based credit- | control server MUST NOT be contacted. When session based credit- | |||
| control is used for the subscriber a constant Credit-Control messages | control is used for the subscriber a constant Credit-Control | |||
| stream is flowing through the home Diameter AAA server. The home | messages stream is flowing through the home Diameter AAA server. The | |||
| Diameter AAA server can make use of this credit-control messages flow | home Diameter AAA server can make use of this credit-control | |||
| to deduce that user's activity is ongoing; hence it is recommended to | messages flow to deduce that user's activity is ongoing; hence 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 | |||
| exchange process. | capability exchange process. | |||
| The following diagram illustrates the use of authorization / | The following diagram illustrates the use of authorization / | |||
| authentication messages to perform the first interrogation. The | authentication messages to perform the first interrogation. The | |||
| parallel accounting stream is not shown in the figure. | parallel accounting stream is not shown in the figure. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Diameter | Diameter | |||
| End-User Service Element AAA Server CC Server | End-User Service Element AAA Server CC | |||
| Server | ||||
| (CC Client) | (CC Client) | |||
| | Service Request | AA Request (CC AVPs) | | | Service Request | AA Request (CC AVPs) | | |||
| |------------------>|------------------->| | | |------------------>|------------------->| | | |||
| | | | CCR(Initial, CC AVPs) | | | | CCR(Initial, CC AVPs) | |||
| | | |------------------->| | | | |------------------->| | |||
| | | | CCA(Granted-Units) | | | | CCA(Granted-Units) | |||
| | | |<-------------------| | | | |<-------------------| | |||
| | | AA Answer(Granted-Units) | | | | AA Answer(Granted-Units) | | |||
| | Service Delivery |<-------------------| | | | Service Delivery |<-------------------| | | |||
| |<----------------->| | | | |<----------------->| | | | |||
| skipping to change at page 26, line 40 ¶ | skipping to change at page 27, line 39 ¶ | |||
| | : | | | | | : | | | | |||
| | End of Service | | | | | End of Service | | | | |||
| |------------------>| CCR(Termination,Used-Units) | | |------------------>| CCR(Termination,Used-Units) | | |||
| | |------------------->| CCR(Term.,Used-Units) | | |------------------->| CCR(Term.,Used-Units) | |||
| | | |------------------->| | | | |------------------->| | |||
| | | | CCA | | | | | CCA | | |||
| | | CCA |<-------------------| | | | CCA |<-------------------| | |||
| | |<-------------------| | | | |<-------------------| | | |||
| Figure 3: Protocol example with use of the | Figure 3: Protocol example with use of the | |||
| authorization messages for the first interrogation. | authorization messages for the first interrogation. | |||
| 5.3 Intermediate Interrogation | 5.3 Intermediate Interrogation | |||
| When all of the granted service units for one unit type are spent by | When all of the granted service units for one unit type are spent by | |||
| the end user or the Validity-Time is expired, the Diameter credit- | the end user or the Validity-Time is expired, the Diameter credit- | |||
| control client MUST send a new Credit-Control-Request to the credit- | control client MUST send a new Credit-Control-Request to the credit- | |||
| control server. In the event that credit control for multiple | control server. In the event that credit control for multiple | |||
| services in one credit control session is applied (i.e. units are | services in one credit control session is applied (i.e. units are | |||
| granted associated to Service-Identifier(s) or Rating-Group), a new | granted associated to Service-Identifier(s) or Rating-Group), a new | |||
| Credit-Control-Request MUST be sent to the credit-control server when | Credit-Control-Request MUST be sent to the credit-control server | |||
| the whole credit reservation has been consumed, or upon expiration of | when the whole credit reservation has been consumed, or upon | |||
| the Validity-Time. In the case when the Validity-Time is used, it is | expiration of the Validity-Time. It is always up to the Diameter | |||
| always up to the Diameter credit-control client to send a new request | credit-control client to send a new request well in advance before | |||
| well in advance before the expiration of the previous request in | the expiration of the previous request in order to avoiding | |||
| interruption in the service element. Even if the granted service | ||||
| Diameter Credit Control Application May 14, 2004 | units reserved by the credit-control server have not been spent upon | |||
| expiration of the Validity-Time, the Diameter credit-control client | ||||
| order to avoiding interruption in the service element. Even if the | MUST send a new Credit-Control-Request to the credit-control server. | |||
| granted service units reserved by the credit-control server have not | ||||
| been spent upon expiration of the Validity-Time, the Diameter credit- | ||||
| control client MUST send a new Credit-Control-Request to the credit- | ||||
| control server. | ||||
| There can be also mid-session service events, which might affect the | There can be also 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 | updating (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 | |||
| When the new granted units are received from the credit-control | server. When the new granted units are received from the credit- | |||
| server these units apply from the point where the measurement of the | control server these units apply from the point where the | |||
| reported used units stopped. Where independent credit-control of | measurement of the reported used units stopped. Where independent | |||
| multiple services is supported, this process may be executed for one | credit-control of multiple services is supported, this process may | |||
| or more services, a single rating-group or for a pool within the | be executed for one or more services, a single rating-group or for a | |||
| (sub)session. | 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 SHOULD be | intermediate request message. The Subscription-Id AVP SHOULD be | |||
| included in the intermediate message to identify the end user in the | included in the intermediate message to identify the end user in the | |||
| credit-control server. | credit-control server. The Service-Context-Id AVP indicates the | |||
| service specific document 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 new | AVP is used, it MUST contain the Requested-Service-Unit AVP if new | |||
| quota for the associated service/rating-group is requested. The Used- | quota for the associated service/rating-group is requested. The | |||
| Service-Unit AVP contains the amount of used service units measured | Used-Service-Unit AVP contains the amount of used service units | |||
| from the point when the service became active or, in case of interim | measured from the point when the service became active or, in case | |||
| interrogations are used during the session, from the point when the | of interim interrogations are used during the session, from the | |||
| previous measurement ended. The same unit types that are used in the | point when the previous measurement ended. The same unit types that | |||
| previous message SHOULD be used. If several unit types were included | are used in the previous message SHOULD be used. If several unit | |||
| in the previous answer message the used service units for each unit | types were included in the previous answer message the used service | |||
| type MUST be reported. | units for each unit type MUST be reported. | |||
| The Event-Timestamp AVP contains the time of the event that triggered | The Event-Timestamp AVP SHOULD be included in the request and | |||
| the sending of the new Credit-Control-Request. | contains the time of the event that triggered the sending of the new | |||
| 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 end | |||
| user's account. It MAY rate the new request and make a new credit- | user's account. It MAY rate the new request and make a new credit- | |||
| reservation from the end user's account that covers the cost of the | reservation from the end user's account that covers the cost of the | |||
| requested service event. | requested service event. | |||
| Diameter Credit Control Application May 14, 2004 | The Credit-Control-Answer message with the CC-Request-Type AVP set | |||
| to the value UPDATE_REQUEST MAY include the Cost-Information AVP | ||||
| The Credit-Control-Answer message with the CC-Request-Type AVP set to | ||||
| 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-reservation 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 to indicate that the answer message contains the final | Indication AVP to indicate that the answer message contains the | |||
| units for the service. After the end user has consumed these units, | final units for the service. After the end user has consumed these | |||
| the Diameter credit-control-client MUST behave as described in | units, the Diameter credit-control-client MUST behave as described | |||
| section 5.6. | 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 according to the | When the end user terminates the service session or according to the | |||
| graceful service termination as described in section 5.6, the | graceful service termination as described in section 5.6, 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 AVP | Request message to the credit-control server. The CC-Request-Type | |||
| is set to the value TERMINATION_REQUEST. | AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id | |||
| AVP indicates the service specific document applicable to the | ||||
| request. | ||||
| The Event-Timestamp AVP MAY contain the time of the session was | The Event-Timestamp AVP SHOULD be included in the request and | |||
| terminated. | contains the time of 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, in case of | measured from the point when the service became active or, in case | |||
| interim interrogations are used during the session, from the point | of interim interrogations are used during the session, from the | |||
| when the previous measurement ended. If several unit types were | point when the previous measurement ended. If several unit types | |||
| included in the previous answer message the used service units for | were included in the previous answer message the used service units | |||
| each unit type MUST be reported. | for each unit 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. | |||
| The Credit-Control-Answer message with the CC-Request-Type set to the | The Credit-Control-Answer message with the CC-Request-Type 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 logoff during an ongoing credit-control session or some | If the user logoff during an ongoing credit-control session or some | |||
| other reason causes the user to be logged-off (e.g. final-unit | other reason causes the user to be logged-off (e.g. final-unit | |||
| indication causes user logoff according to local policy) the service | indication causes user logoff according to local policy) the 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 [DIAMBASE]. Figure 4 illustrates the case when the final-unit | usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit | |||
| indication causes the user logoff upon consumption of the final | indication causes the user logoff upon consumption of the final | |||
| granted units and STR is generated. | granted units and STR is generated. | |||
| Diameter Credit Control Application May 14, 2004 | 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) | |||
| | | |------------------->| | | | |------------------->| | |||
| skipping to change at page 29, line 36 ¶ | skipping to change at page 30, line 35 ¶ | |||
| | | |------------------->| | | | |------------------->| | |||
| | | | CCA | | | | | CCA | | |||
| | | CCA |<-------------------| | | | CCA |<-------------------| | |||
| | |<-------------------| | | | |<-------------------| | | |||
| | | STR | | | | | STR | | | |||
| | |------------------->| | | | |------------------->| | | |||
| | | STA | | | | | STA | | | |||
| | |<-------------------| | | | |<-------------------| | | |||
| Figure 4: User disconnected due to account exhausted | Figure 4: User disconnected due to account exhausted | |||
| 5.5 Server-Initiated Credit Re-Authorization | 5.5 Server-Initiated Credit Re-Authorization | |||
| The Diameter Credit Control Application supports server-initiated re- | The Diameter Credit Control Application supports server-initiated | |||
| authorization. The credit control server MAY optionally initiate the | re-authorization. The credit control server MAY optionally initiate | |||
| credit re-authorization by issuing a Re-Auth-Request (RAR) as defined | the credit re-authorization by issuing a Re-Auth-Request (RAR) as | |||
| in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in | defined in the Diameter base protocol [DIAMBASE]. The Auth- | |||
| the RAR message is set to 4 to indicate the Diameter Credit Control | Application-Id in the RAR message is set to XXX [IANA please fill in | |||
| Application and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. | XXX (suggested value 4 in section 12.1) and remove this note] to | |||
| indicate the Diameter Credit Control Application and the Re-Auth- | ||||
| Request-Type is set to AUTHORIZE_ONLY. | ||||
| Section 5.1.1 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.1 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 re- | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| authorization for a credit pool, the server includes in the RAR | 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-authorization | the Rating-Group AVP respectively. To request credit re- | |||
| for all the ongoing services within the (sub-)session the server | authorization for all the ongoing services within the (sub-)session | |||
| includes none of the above mentione AVPs in the RAR message. | the server includes none of the above mentioned AVPs in the RAR | |||
| message. | ||||
| If a credit re-authorization is not already ongoing (i.e. the credit | If a credit re-authorization is not already ongoing (i.e. the credit | |||
| control session is in OPEN state), a credit control client that | control session is in OPEN state), a credit control client that | |||
| receives such a RAR message with Session-Id equal to a currently | receives such a RAR message with Session-Id equal to a currently | |||
| active credit control session acknowledges the request by sending the | active credit control session MUST acknowledge the request by | |||
| Re-Auth-Answer (RAA) message and MUST initiate the credit re- | sending the Re-Auth-Answer (RAA) message and MUST initiate the | |||
| authorization towards the server by sending a Credit-Control-Request | credit re-authorization towards the server by sending a Credit- | |||
| message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. | Control-Request message with the CC-Request-Type AVP set to the | |||
| The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the | value UPDATE_REQUEST. The Result-Code 2002 | |||
| RAA message to indicate an additional message (i.e. CCR message with | (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to | |||
| value UPDATE_REQUEST) is required to complete the procedure. If a | indicate an additional message (i.e. CCR message with value | |||
| quota was allocated to the service, the credit control client MUST | UPDATE_REQUEST) is required to complete the procedure. If a quota | |||
| report the used quota in the Credit-Control-Request. Note that the | was allocated to the service, the credit control client MUST report | |||
| end user does not need to be prompted for the credit re- | the used quota in the Credit-Control-Request. Note that the end user | |||
| authorization, since the credit re-authorization is transparent to | does not need to be prompted for the credit re-authorization, since | |||
| the user (i.e it takes place exclusively between the credit control | the credit re-authorization is transparent to the user (i.e it takes | |||
| client and the credit control server). | place 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 of the above paragraph will be executed at the granularity | procedure of the above paragraph will be executed at the granularity | |||
| as requested by the server in the RAR message. | as 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. RAR-CCR collision), the credit control | |||
| client successfully acknowledges the request but it does not initiate | client successfully acknowledges the request but it does not | |||
| a new credit re-authorization. The Result-Code 2001 | initiate a new credit re-authorization. The Result-Code 2001 | |||
| (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate a | (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate a | |||
| credit re-authorization procedure is already ongoing (i.e. the client | credit re-authorization procedure is already ongoing (i.e. the | |||
| was in PendingU state when the RAR was received). The credit control | client was in PendingU state when the RAR was received). The credit | |||
| server SHOULD process the Credit-Control-Request as if it was | control server SHOULD process the Credit-Control-Request as if it | |||
| received in answer to the server initiated credit re-authorization, | was received in answer to the server initiated credit re- | |||
| and should consider the server initiated credit re-authorization | authorization, and should consider the server initiated credit re- | |||
| process successful upon reception of the Re-Auth-Answer message. | authorization process successful upon reception of the Re-Auth- | |||
| Answer message. | ||||
| Where multiple services in a user's session are supported, it may | Where multiple services in a user's session are supported, it may | |||
| happen that the server requests credit re-authorization for a credit | happen that the server requests credit re-authorization for a credit | |||
| pool (or for the (sub-)session) and a credit re-authorization is | pool (or for the (sub-)session) and a credit re-authorization is | |||
| already ongoing for some of the services or rating-groups. In this | already ongoing for some of the services or rating-groups. In this | |||
| case the client acknowledges the server request with a RAA message | case the client acknowledges the server request with a RAA message | |||
| and MUST send a new Credit-Control-Request message to perform re- | and MUST send a new Credit-Control-Request message to perform re- | |||
| authorization for the remaining services/rating-groups. The Result- | authorization for the remaining services/rating-groups. The Result- | |||
| Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA | Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA | |||
| message to indicate an additional message (i.e. CCR message with | message to indicate an additional message (i.e. CCR message with | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| value UPDATE_REQUEST) is required to complete the procedure. The | value UPDATE_REQUEST) is required to complete the procedure. The | |||
| server processes the received requests and returns an appropriate | server processes the received requests and returns an appropriate | |||
| answer to both of the requests. | answer to both of the 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 CC-Sub- | |||
| Session-Id AVP in the RAR message in addition to the Session-Id AVP. | 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 be denied to | When the user's account runs out of money the user may be denied to | |||
| compile additional chargeable events. However, the home service | 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 the user | portal where it is possible to refill the account, for which the | |||
| is allowed to benefit for a limited amount of time. This time is | user is allowed to benefit for a limited amount of time. This time | |||
| usually dependant on the home service provider policy. | is usually dependant on the home service provider policy. | |||
| This section defines the graceful service termination optional | This section defines the graceful service termination optional | |||
| feature that MAY be supported by the credit control server. Credit | feature that MAY be supported by the credit control server. Credit | |||
| control client implementations MUST support the Final-Unit-Indication | control client implementations MUST support the Final-Unit- | |||
| with at least the tear down of the ongoing service session upon the | Indication with at least the tear down of the ongoing service | |||
| subscriber has consumed all the final granted units. | session upon the subscriber has 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 the | |||
| 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 sub-sections 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) the graceful service | |||
| termination may be used to redirect the subscriber to a service | termination may be used to redirect the subscriber to a service | |||
| skipping to change at page 32, line 4 ¶ | skipping to change at page 33, line 11 ¶ | |||
| appropriate notification why the access has been limited. These | appropriate notification why the access has been limited. These | |||
| actions may be communicated explicitly from the server to client or | actions may be communicated explicitly from the server to client or | |||
| may be configured per-service at the client. Explicitly signaled | may be configured per-service at the client. Explicitly signaled | |||
| redirect or restrict instructions always take precedence over | redirect or restrict instructions always take precedence over | |||
| configured ones. | configured ones. | |||
| It is also possible use the graceful service termination to connect | It is also possible use the graceful service termination to connect | |||
| the prepaid user to a top-up server that play an announcement and | the prepaid user to a top-up server that play an announcement and | |||
| prompt the user to replenish the account. In such a case the credit | prompt the user to replenish the account. In such a case the credit | |||
| control server sends only the address of the top-up server where the | control server sends only the address of the top-up server where the | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| prepaid user shall be connected after the final granted units have | prepaid user shall be connected after the final granted units have | |||
| been consumed. An example of this is given in Appendix A (Flow VII). | been consumed. An example of this is given in Appendix A (Flow VII). | |||
| The credit control server MAY initiate the graceful service | The credit control server MAY initiate the graceful service | |||
| termination by including the Final-Unit-Indication AVP in the Credit | termination by including the Final-Unit-Indication AVP in the Credit | |||
| Control Answer to indicate that the message contains the final units | Control Answer to indicate that the message contains the final units | |||
| for the service. | for the service. | |||
| When the credit control client receives the Final-Unit-Indication AVP | When the credit control client receives the Final-Unit-Indication | |||
| in the answer from the server its behavior depends on the value | AVP in the answer from the server its behavior depends on the value | |||
| indicated in the Final-Unit-Action AVP. The server may request the | indicated in the Final-Unit-Action AVP. The server may request the | |||
| following actions: TERMINATE, REDIRECT and RESTRICT_ACCESS. | following actions: TERMINATE, REDIRECT and RESTRICT_ACCESS. | |||
| The following Figure illustrates the graceful service termination | The following Figure illustrates the graceful service termination | |||
| procedure described in the following sub-sections. | procedure described in the following sub-sections. | |||
| 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) | | |||
| | |<-------------------| | | | |<-------------------| | | |||
| skipping to change at page 33, line 4 ¶ | skipping to change at page 34, line 11 ¶ | |||
| | : | | | | | : | | | | |||
| | : | | | | | : | | | | |||
| | Replenish Account +-------+ | | | Replenish Account +-------+ | | |||
| |<-------------------------------------------->|Account| | | |<-------------------------------------------->|Account| | | |||
| | | | +-------+ | | | | | +-------+ | | |||
| | | | RAR | | | | | RAR | | |||
| | + | RAR |<===================| | | + | RAR |<===================| | |||
| | | |<===================| | | | | |<===================| | | |||
| | | | RAA | | | | | | RAA | | | |||
| | ///////////// | |===================>| RAA | | | ///////////// | |===================>| RAA | | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | /If supported / | | CCR(Update) |===================>| | | /If supported / | | CCR(Update) |===================>| | |||
| | /by CC Server/ | |===================>| CCR(Update) | | | /by CC Server/ | |===================>| CCR(Update) | | |||
| | ///////////// | | |===================>| | | ///////////// | | |===================>| | |||
| | | | | CCA(Granted-Unit)| | | | | | CCA(Granted-Unit)| | |||
| | | | CCA(Granted-Unit)|<===================| | | | | CCA(Granted-Unit)|<===================| | |||
| | Restrictions ->+ |<===================| | | | Restrictions ->+ |<===================| | | |||
| | removed | | | | | removed | | | | |||
| | : | | | | | : | | | | |||
| | OR | CCR(Update) | | | | OR | CCR(Update) | | | |||
| | Validity-Time ->|------------------->| CCR(Update) | | | Validity-Time ->|------------------->| CCR(Update) | | |||
| skipping to change at page 33, line 34 ¶ | skipping to change at page 34, line 38 ¶ | |||
| 5.6.1 Terminate Action | 5.6.1 Terminate Action | |||
| The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does | The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does | |||
| not include any other information. When the subscriber has consumed | not include any other information. When the subscriber has consumed | |||
| the final granted units, the service element MUST terminate the | the final granted units, the service element MUST terminate the | |||
| service. This is the default handling applicable whenever the credit | service. This is the default handling applicable whenever the credit | |||
| control client receives an unsupported Final-Unit-Action value and | control client receives an unsupported Final-Unit-Action value and | |||
| MUST be supported by all the Diameter credit control client | MUST be supported by all the Diameter credit control client | |||
| implementations conforming to this specification. A final Credit- | implementations conforming to this specification. A final Credit- | |||
| Control-Request message to the credit control server MUST be sent if | Control-Request message to the credit control server MUST be sent if | |||
| the Final-Unit-Indication AVP indicating action TERMINATE was present | the Final-Unit-Indication AVP indicating action TERMINATE was | |||
| at command level. The CC-Request-Type AVP in the request is set to | present at command level. The CC-Request-Type AVP in the request is | |||
| the value TERMINATION_REQUEST. | set to the value TERMINATION_REQUEST. | |||
| 5.6.2 Redirect Action | 5.6.2 Redirect Action | |||
| The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT | The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT | |||
| indicates to the service element supporting this action that, upon | indicates to the service element supporting this action that, upon | |||
| consumption of the final granted units, the user MUST be re-directed | consumption of the final granted units, the user MUST be re-directed | |||
| to the address specified in the Redirect-Server AVP as follows. | to the address specified in the Redirect-Server AVP as follows. | |||
| The credit control server sends the Redirect-Server AVP in the | The credit control server sends the Redirect-Server AVP in the | |||
| Credit-Control-Answer message. In such a case the service element | Credit-Control-Answer message. In such a case the service element | |||
| MUST redirect or connect the user to the destination specified in the | MUST redirect or connect the user to the destination specified in | |||
| Redirect-Server AVP, if possible. When the end user is redirected (by | the Redirect-Server AVP, if possible. When the end user is | |||
| using other protocols than Diameter) to the specified server or | redirected (by using other protocols than Diameter) to the specified | |||
| connected to the top-up server, an additional authorization (and | server or connected to the top-up server, an additional | |||
| possibly authentication) may be needed before the subscriber can | authorization (and possibly authentication) may be needed before the | |||
| replenish the account, however, this is out of the scope of this | subscriber can replenish the account, however, this is out of the | |||
| specification. | scope of this specification. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| In addition to the Redirect-Server AVP, the credit control server MAY | In addition to the Redirect-Server AVP, the credit control server | |||
| include one or more Restriction-Filter-Rule AVP or one or more | MAY include one or more Restriction-Filter-Rule AVP or one or more | |||
| Filter-Id AVP in the Credit-Control-Answer message in order to enable | Filter-Id AVP in the Credit-Control-Answer message in order to | |||
| the user to access other services (for example zero-rated services). | enable the user to access other services (for example zero-rated | |||
| In such a case the access device MUST drop all the packets not | services). In such a case the access device MUST drop all the | |||
| matching the IP filters specified in the Credit-Control-Answer | packets not matching the IP filters specified in the Credit-Control- | |||
| message and redirect the user to the destination specified in the | Answer message and redirect the user to the destination specified in | |||
| Redirect-Server AVP, if possible. | the Redirect-Server AVP, if possible. | |||
| Another entity than the credit control server may provision the | Another entity 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 intermediate interrogation is to indicate to the credit control | this intermediate interrogation is to indicate to the credit control | |||
| server that the specified action started and to report the used | server that the specified action started and to report the used | |||
| units. The credit control server MUST deduct the used amount from the | units. The credit control server MUST deduct the used amount from | |||
| end user's account but MUST NOT make a new credit reservation. The | the end user's account but MUST NOT make a new credit reservation. | |||
| credit control client, however, may send intermediate interrogations | The credit control client, however, may send intermediate | |||
| before all the final granted units have been consumed for which | interrogations before all the final granted units have been consumed | |||
| rating and money reservation may be needed, for instance upon | for which rating and money reservation may be needed, for instance | |||
| Validity-Time expires or upon mid-session service event that affect | upon Validity-Time expires or upon mid-session service event that | |||
| the rating of the current service. Therefore, the credit control | affect the rating of the current service. Therefore, the credit | |||
| client MUST NOT include any rating related AVP in the request sent | control client MUST NOT include any rating related AVP in the | |||
| upon all the final granted units have been consumed as a hint to the | request sent upon all the final granted units have been consumed as | |||
| server that the requested final unit action started, rating and money | an indication to the server that the requested final unit action | |||
| reservation are not required (when the Multiple-Services-Credit- | started, rating and money reservation are not required (when the | |||
| Control AVP is used, the Service-Identifier or Rating-Group AVPs is | Multiple-Services-Credit-Control AVP is used, the Service-Identifier | |||
| included to indicate the concerned services). Naturally, the Credit- | or Rating-Group AVPs is included to indicate the concerned | |||
| Control-Answer message does not contain any granted service unit and | services). Naturally, the Credit-Control-Answer message does not | |||
| MUST include the Validity-Time AVP to indicate to the credit control | contain any granted service unit and MUST include the Validity-Time | |||
| client how long the subscriber is allowed to use network resources | AVP to indicate to the credit control client how long the subscriber | |||
| before a new intermediate interrogation is sent to the server. | 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 since there is no allotted | not include the Used-Service-Unit AVP since there is no allotted | |||
| quota to report. The credit control server processes the request and | quota to report. The credit control server processes the request and | |||
| MUST perform the credit reservation. If during this time the | MUST perform the credit reservation. If during this time the | |||
| subscriber did not replenish his/her account whether he/she will be | subscriber did not replenish his/her account whether he/she will be | |||
| disconnected or will be granted access to services not controlled by | disconnected or will be granted access to services not controlled by | |||
| credit control server for unlimited time is dependent on the home | credit control server for unlimited time is dependent on the home | |||
| service provider policy (note: the latter option implies that the | service provider policy (note: the latter option implies that the | |||
| service element should not remove the restriction filters upon | service element should not remove the restriction filters upon | |||
| termination of the credit control). The server will return the | termination of the credit control). The server will return the | |||
| appropriate Result-Code (see section 9.1) in the Credit-Control- | appropriate Result-Code (see section 9.1) in the Credit-Control- | |||
| Answer message in order to implement the policy-defined action. | Answer message in order to implement the policy-defined action. | |||
| Otherwise new quota will be returned, the service element MUST | ||||
| Diameter Credit Control Application May 14, 2004 | remove all the possible restrictions activated by the graceful | |||
| service termination process and continue the credit control session | ||||
| Otherwise new quota will be returned, the service element MUST remove | and the service session as usual. | |||
| all the possible restrictions activated by the graceful service | ||||
| termination process and continue the credit control session and the | ||||
| service session 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 updating (a new Credit- | Validity-Time and may send a spontaneous updating (a new Credit- | |||
| Control-Request) if the service element can determine for instance | Control-Request) if the service element can determine for instance | |||
| that communication between the end user and the top-up server took | that communication between the end user and the top-up server took | |||
| place. An example of this is given in Appendix A (Figure A.8). | place. An example of this is given in Appendix A (Figure A.8). | |||
| It is worth noting that the credit control server may initiate the | It is worth noting that the credit control server may initiate the | |||
| above-described process already for the first interrogation. However, | above-described process already for the first interrogation. | |||
| the user's account might be empty at the time when the first | However, the user's account might be empty at the time when the | |||
| interrogation is performed. In this case the subscriber can be | first interrogation is performed. In this case the subscriber can be | |||
| offered a chance to replenish the account and continue the service. | offered a chance to replenish the account and continue the service. | |||
| The credit control client receives a Credit-Control-Answer or service | The credit control client receives a Credit-Control-Answer or | |||
| specific authorization answer with the Final-Unit-Indication AVP, | service specific authorization answer with the Final-Unit-Indication | |||
| Validity-Time AVP but no Granted-Unit. In such a case it immediately | AVP, Validity-Time AVP but no Granted-Unit. In such a case it | |||
| starts the graceful service termination without sending any message | immediately starts the graceful service termination without sending | |||
| to the server. An example of this case is illustrated in Appendix A. | any message to the server. An example of this case is illustrated in | |||
| Appendix A. | ||||
| 5.6.3 Restrict Access Action | 5.6.3 Restrict Access Action | |||
| The Final-Unit-Indication AVP with Final-Unit-Action RESTRICT_ACCESS | The Final-Unit-Indication AVP with Final-Unit-Action RESTRICT_ACCESS | |||
| indicates to the access device supporting this action that the user | indicates to the access device supporting this action that the user | |||
| MUST be restricted access according to the IP packet filters given in | MUST be restricted access according to the IP packet filters given | |||
| the Restriction-Filter-Rule AVP(s) or according to the IP packet | in the Restriction-Filter-Rule AVP(s) or according to the IP packet | |||
| filters identified by the Filter-Id AVP(s). The credit control server | filters identified by the Filter-Id AVP(s). The credit control | |||
| SHOULD include either the Restriction-Filter-Rule AVP or the Filter- | server SHOULD include either the Restriction-Filter-Rule AVP or the | |||
| Id AVP in the Credit-Control-Answer message. | Filter-Id AVP in the Credit-Control-Answer message. | |||
| Another entity than the credit control server may provision the | Another entity 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, for instance, may configure the access device with IP flows | entity, for instance, may configure the access device with IP flows | |||
| that are to be passed when the Diameter credit control application | that are to be passed when the Diameter credit control application | |||
| indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP | indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP | |||
| packets according to the filter rules possibly received in the | packets according to the filter rules possibly received in the | |||
| Credit-Control-Answer message in addition to the filter rules | Credit-Control-Answer message in addition to the filter rules | |||
| possibly configured by the other entity. However, the action to be | possibly configured by the other entity. However, the action to be | |||
| taken when the user's account cannot cover the cost of the requested | taken when the user's account cannot cover the cost of the requested | |||
| service is the responsibility of the credit control server that | service is the responsibility of the credit control server that | |||
| controls the 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 Credit | |||
| Control application already provisions the access device with all the | Control application already provisions the access device with all | |||
| required filter rules for the end user, it is presumably not needed | the required filter rules for the end user, it is presumably not | |||
| for the credit control server to send any additional filter. | needed for the credit control server to send any additional filter. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Therefore it is RECOMMENDED that credit control server | Therefore it is RECOMMENDED that credit control server | |||
| implementations supporting the graceful service termination can be | implementations supporting the graceful service termination can be | |||
| configurable whether to send the Restriction-Filter-Rule AVP, the | configurable whether to send the Restriction-Filter-Rule AVP, the | |||
| Filter-Id AVP or none of the above. | Filter-Id 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 control | client MUST perform an intermediate interrogation. The credit | |||
| client and the credit control server process this intermediate | control client and the credit control server process this | |||
| interrogation and execute subsequent procedures as specified in the | intermediate interrogation and execute subsequent procedures as | |||
| previous section for the REDIRECT action. | specified in the previous section for the REDIRECT action. | |||
| The credit control server may initiate the graceful service | The credit control server may initiate the graceful service | |||
| termination with action RESTRICT_ACCESS already for the first | termination with action RESTRICT_ACCESS already for the first | |||
| interrogation as specified in the previous section for the REDIRECT | interrogation as specified in the previous section for the REDIRECT | |||
| action. | action. | |||
| 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 she presumably expects | |||
| all the restrictions placed by the graceful termination procedure be | all the restrictions placed by the graceful termination procedure be | |||
| immediately removed and unlimited services' access be resumed. For | immediately removed and unlimited services' access be resumed. For | |||
| the best user experience the credit control server implementation MAY | the best user experience the credit control server implementation | |||
| support the server-initiated credit re-authorization (see section | MAY support the server-initiated credit re-authorization (see | |||
| 5.5). In such a case, upon the successful account top-up took place, | section 5.5). In such a case, upon the successful account top-up | |||
| the credit control server sends the Re-Auth-Request (RAR) message to | took place, the credit control server sends the Re-Auth-Request | |||
| solicit the credit re-authorization. The credit control client | (RAR) message to solicit the credit re-authorization. The credit | |||
| initiates the credit re-authorization by sending the Credit- Control- | control client initiates the credit re-authorization by sending the | |||
| Request message with the CC-Request-Type AVP set to the value | Credit- Control-Request message with the CC-Request-Type AVP set to | |||
| UPDATE_REQUEST. The Used-Service-Unit AVP is not included in the | the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included | |||
| request since there is no allotted quota to report. The Requested- | in the request since there is no allotted quota to report. The | |||
| Service-Unit AVP MAY be included in the request. After the credit | Requested-Service-Unit AVP MAY be included in the request. After the | |||
| control client successfully receives the Credit-Control-Answer with | credit control client successfully receives the Credit-Control- | |||
| new Granted-Service-Unit all the possible restrictions activated for | Answer with new Granted-Service-Unit all the possible restrictions | |||
| the purpose of the graceful service termination MUST be removed in | activated for the purpose of the graceful service termination MUST | |||
| the service element, the credit control session and the service | be removed in the service element, the credit control session and | |||
| session continue as usual. | 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 Credit-Control-Failure-Handling AVP (CCFH) as described in this | |||
| section determines the behavior of the credit control client in fault | section determines the behavior of the credit control client in | |||
| situations. The CCFH may be received from the Diameter home AAA | fault situations. The CCFH may be received from the Diameter home | |||
| server, from the credit control server or may be locally configured. | AAA server, from the credit control server or may be locally | |||
| The CCFH value received from the home AAA server overrides the | configured. The CCFH value received from the home AAA server | |||
| locally configured value and the CCFH value received from the credit | overrides the locally configured value and the CCFH value received | |||
| control server in the Credit-Control-Answer message always override | from the credit control server in the Credit-Control-Answer message | |||
| any already existing value. | always override any already existing value. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| The authorization server MAY include the Accounting-Realtime-Required | The authorization server MAY include the Accounting-Realtime- | |||
| AVP to determine what to do if the sending of accounting records to | Required AVP to determine what to do if the sending of accounting | |||
| the accounting server has been temporarily prevented as defined in | records to the accounting server has been temporarily prevented as | |||
| [DIAMBASE]. It is RECOMMENDED that the client complement the credit- | defined in [DIAMBASE]. It is RECOMMENDED that the client complement | |||
| control failure procedures with backup accounting flow towards an | the credit-control failure procedures with backup accounting flow | |||
| accounting server. Using different combinations of Accounting- | towards an accounting server. Using different combinations of | |||
| Realtime-Required and Credit-Control-Failure-Handling AVPs different | Accounting-Realtime-Required and Credit-Control-Failure-Handling | |||
| safety levels can be built. For example by choosing the Credit- | AVPs different safety levels can be built. For example by choosing | |||
| Control-Failure-Handling AVP equal to CONTINUE for the credit control | the Credit-Control-Failure-Handling AVP equal to CONTINUE for the | |||
| flow and Accounting-Realtime-Required AVP equal to DELIVER_AND_GRANT | credit control flow and Accounting-Realtime-Required AVP equal to | |||
| for the accounting flow, the service can be granted to the end user | DELIVER_AND_GRANT for the accounting flow, the service can be | |||
| even if the connection to the credit-control server is down but the | granted to the end user even if the connection to the credit-control | |||
| accounting server is able to collect the accounting information, | server is down but the accounting server is able to collect the | |||
| provided that there is information exchange taking place between the | accounting information, provided that there is information exchange | |||
| accounting server and credit-control server. | taking place between the accounting server and credit-control | |||
| server. | ||||
| Since the credit-control application is based on real-time bi- | Since the credit-control application is based on real-time bi- | |||
| directional communication between the credit-control client and the | directional 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. Since the credit-control server has to | communication failures. Since 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. Whether | a backup server requires a complex context transfer solution. | |||
| the credit-control message stream is moved to a backup credit-control | Whether the credit-control message stream is moved to a backup | |||
| server during an ongoing credit-control session depends on the value | credit-control server during an ongoing credit-control session | |||
| of the CC-session-Failover AVP. However, failover may occur at any | depends on the value of the CC-session-Failover AVP. However, | |||
| point in the path between credit-control client and credit-control | failover may occur at any point in the path between credit-control | |||
| server in the event that a transport failure is detected with a peer, | client and credit-control server in the event that a transport | |||
| as described in [DIAMBASE]. As a consequence the credit-control | failure is detected with a peer, as described in [DIAMBASE]. As a | |||
| server might receive duplicate messages. These duplicates or out of | consequence the credit-control server might receive duplicate | |||
| sequence messages can be detected in the credit-control server based | messages. These duplicates or out of sequence messages can be | |||
| on the credit-control server session state machine (section 7), | detected in the credit-control server based on the credit-control | |||
| Session-Id AVP and CC-Request-Number AVP. | server session state machine (section 7), Session-Id AVP and 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 CC-server indicated FAILOVER_SUPPORTED | |||
| in the CC-Session-Failover AVP. A secondary credit control server | in the CC-Session-Failover AVP. A secondary credit control server | |||
| name, received from the home Diameter AAA server or locally | name, received from the home Diameter AAA server or locally | |||
| configured, can be used as an address of the backup server. If the | configured, can be used as an address of the backup server. If the | |||
| CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the credit | CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the credit | |||
| control message stream MUST NOT be moved to backup server. | control message stream MUST NOT be moved to backup server. | |||
| For new credit control sessions, failover to an alternative credit- | For new credit control sessions, failover to an alternative credit- | |||
| control server SHOULD be performed if possible. For instance, if an | control server SHOULD be performed if possible. For instance, if an | |||
| implementation of the credit control client can determine primary | implementation of the credit control client can determine primary | |||
| credit control server unavailability it can establish the new credit | credit control server unavailability it can establish the new credit | |||
| control sessions with a possibly available secondary credit control | control sessions with a possibly available secondary credit control | |||
| server. | server. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| The AAA transport profile [AAATRANS] defines the application layer | The AAA transport profile [AAATRANS] defines the 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 [AAATRANS]. The | and is controlled by a watchdog timer (Tw) defined in [AAATRANS]. | |||
| 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 | |||
| [AAATRANS] setting too low value for Twinit is likely to result in an | [AAATRANS] setting too low value for Twinit is likely to result in | |||
| 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. Since the Diameter base | spurious failover and failback attempts. Since the Diameter base | |||
| protocol is common to several different types of Diameter AAA | protocol is common to several different types of Diameter AAA | |||
| applications that may be run in the same service element, tuning the | applications that may be run in the same service element, tuning the | |||
| timer Twinit to a lower value in order to satisfy the requirements of | timer Twinit to a lower value in order to satisfy the requirements | |||
| real-time applications, such as the Diameter Credit Control | of real-time applications, such as the Diameter Credit Control | |||
| application, will certainly materialize the above mentioned problems. | application, will certainly materialize the above mentioned | |||
| For prepaid services, however, the end user expects an answer from | problems. For prepaid services, however, the end user expects an | |||
| the network in a reasonable time, thus the Diameter credit control | answer from the network in a reasonable time, thus the Diameter | |||
| client shall react faster than the underlying base protocol. | credit control client shall react faster than the underlying base | |||
| Therefore this specification defines the timer Tx that is used by the | protocol. Therefore this specification defines the timer Tx that is | |||
| credit-control client (as defined in section 13) to supervise the | used by the credit-control client (as defined in section 13) to | |||
| communication with the credit-control server. When the timer Tx | supervise the communication with the credit-control server. When the | |||
| elapses the credit-control client takes an action to the end user | timer Tx elapses the credit-control client takes an action to the | |||
| according to the Credit-Control-Failure-Handling AVP. | end user according to the Credit-Control-Failure-Handling AVP. | |||
| When Tx expires, the Diameter credit control client always terminates | When Tx expires, the Diameter credit control client always | |||
| the service if the Credit-Control-Failure-Handling (CCFH) AVP is set | terminates the service if the Credit-Control-Failure-Handling (CCFH) | |||
| to the value TERMINATE. The credit control session may be moved to an | AVP is set to the value TERMINATE. The credit control session may be | |||
| alternative server only in case a protocol error DIAMETER_TOO_BUSY or | moved to an alternative server only in case a protocol error | |||
| DIAMETER_UNABLE_TO_DELIVER is received before Tx expires, therefore, | DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before | |||
| the value TERMINATE is not appropriate if proper failover behavior is | Tx expires, therefore, the value TERMINATE is not appropriate if | |||
| desired. | proper failover behavior is desired. | |||
| If the Credit-Control-Failure-Handling AVP is set to the value | If the Credit-Control-Failure-Handling AVP is set to the value | |||
| CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the | CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the | |||
| end user upon the timer Tx expires. An answer message with granted- | end user upon the timer Tx expires. An answer message with granted- | |||
| units may arrive later on due to the base protocol transport failover | units may arrive later on due to the base protocol transport | |||
| occurred in the path to the Credit Control Server (Twinit default | failover occurred in the path to the Credit Control Server (Twinit | |||
| value is 3 times more than the Tx recommended value). The credit | default value is 3 times more than the Tx recommended value). The | |||
| control client SHOULD grant the service to the end user, start | credit control client SHOULD grant the service to the end user, | |||
| monitoring the resource usage and wait for the possible late answer | start monitoring the resource usage and wait for the possible late | |||
| until the timeout of the request (e.g. 120 seconds). If the request | answer until the timeout of the request (e.g. 120 seconds). If the | |||
| fails and the CC-Session-Failover AVP is set to FAILOVER_NOT | request fails and the CC-Session-Failover AVP is set to FAILOVER_NOT | |||
| SUPPORTED, the credit control client terminates or continues the | SUPPORTED, the credit control client terminates or continues the | |||
| service depending on the value set in the CCFH and MUST free all the | service depending on the value set in the CCFH and MUST free all the | |||
| reserved resources for the credit control session. If a protocol | reserved resources for the credit control session. If a protocol | |||
| error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or | error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or | |||
| the request timeout and the CC-Session-Failover AVP is set to | the request timeout and the CC-Session-Failover AVP is set to | |||
| FAILOVER SUPPORTED, the credit control client MAY send the request to | FAILOVER SUPPORTED, the credit control client MAY send the request | |||
| to a backup server if possible. If the credit control client | ||||
| Diameter Credit Control Application May 14, 2004 | receives a successful answer from the backup server, it continues | |||
| the credit control session with such a server. If also the re- | ||||
| a backup server if possible. If the credit control client receives a | transmitted request fails, the credit control client terminates or | |||
| successful answer from the backup server, it continues the credit | continues the service depending on the value set in the CCFH and | |||
| control session with such a server. If also the re-transmitted | MUST free all the reserved resources for the credit control session. | |||
| request fails, the credit control client terminates or continues the | ||||
| service depending on the value set in the CCFH and MUST 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 the failover between credit control servers | In order to support the 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 the secondary credit | |||
| control server. Implementations supporting the credit control session | control server. Implementations supporting the credit control | |||
| failover MUST also ensure proper detection of duplicate or out of | session failover MUST also ensure proper detection of duplicate or | |||
| sequence messages. The communication between the servers is regarded | out of sequence messages. The communication between the servers is | |||
| as an implementation issue and is outside of the scope of this | regarded as an implementation issue and is outside of the scope of | |||
| specification. | this 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 enquiring | |||
| the price of the service. The use of one-time event implies that the | the price of the service. The use of one-time event implies that the | |||
| user has been authenticated and authorized beforehand. | 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 without any credit-reservation | to know the cost of the service event without any credit-reservation | |||
| or to check the account balance without any credit-reservation. It | or to check the account balance without any credit-reservation. It | |||
| can be used also for refunding service units on the user's account or | can be used also for refunding service units on the user's account | |||
| direct debiting without any credit-reservation. The one time event is | or direct debiting without any credit-reservation. The one time | |||
| shown in Figure 6. | event is shown in Figure 6. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 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 6: One time event | Figure 6: 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 Enquiry | |||
| The credit-control client may need to know the price of the service | The credit-control client may need to know the price of the service | |||
| event. There might exist services offered by application service | event. There might exist services offered by application service | |||
| providers, whose prices are not known in the credit-control client. | providers, whose prices are not known in the credit-control client. | |||
| End user might also want to get an estimation of the price of a | End user might also want to get an estimation of the price of a | |||
| service event before requesting it. | service event before requesting it. | |||
| A Diameter credit-control client requesting the cost information MUST | A Diameter credit-control client requesting the cost information | |||
| set the CC-Request-Type AVP equal to EVENT_REQUEST, include the | MUST 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 into 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 may be sent within the | may be sent as service specific AVPs or may be sent within the | |||
| Service-Parameter-Info AVP. | Service-Parameter-Info AVP. The Service-Context-Id AVP indicates the | |||
| service specific 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 check or | |||
| credit-reservation from the account. | credit-reservation 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 Credit- | |||
| Control-Answer message. | Control-Answer message. | |||
| 6.2 Balance Check | 6.2 Balance Check | |||
| The Diameter credit-control client may need only to verify that the | The Diameter credit-control client may need only to verify that the | |||
| end user's account balance covers the cost for a certain service | end user's account balance covers the cost for 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 | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| inquiry. This method does not guarantee that there would be credit | inquiry. This method does not guarantee that there would be credit | |||
| left when the Diameter credit-control client requests the debiting of | left when the Diameter credit-control client requests the debiting | |||
| the account with a separate request. | of the account with a separate request. | |||
| A Diameter credit-control client requesting the balance check MUST | A Diameter credit-control client requesting the balance check MUST | |||
| set the CC-Request-Type AVP equal to EVENT_REQUEST, include | set the CC-Request-Type AVP equal to EVENT_REQUEST, include | |||
| Requested-Action AVP set to CHECK_BALANCE and include the | Requested-Action AVP set to CHECK_BALANCE and include the | |||
| Subscription-Id AVP to identify the End-User in the credit-control | Subscription-Id AVP to identify the End-User in the credit-control | |||
| server. | server. The Service-Context-Id AVP indicates the service specific | |||
| document applicable to the request. | ||||
| The credit-control server makes the balance check, but it does not do | The credit-control server makes the balance check, but it does not | |||
| any credit-reservation from the account. | do any credit-reservation from the account. | |||
| The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to | The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to | |||
| the credit-control client in the Check-Balance-Result AVP in the | 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 the session-based credit- | |||
| control would lead to unreasonable long credit-control sessions. In | control would lead to unreasonable long credit-control sessions. In | |||
| these cases the Diameter credit-control client can use the one-time | these cases the Diameter credit-control client can use the one-time | |||
| event scenario for direct debiting. The Diameter credit-control | event scenario for direct debiting. The Diameter credit-control | |||
| client SHOULD be sure that the requested service event execution | client SHOULD be sure that the requested service event execution | |||
| would be successful, when this scenario is used. | would be successful, when this scenario is used. | |||
| The CC-Request-Type is set to the value EVENT_REQUEST and the | The CC-Request-Type is set to the value EVENT_REQUEST and the | |||
| Requested-Action AVP set to DIRECT_DEBITING in the Credit-Control- | Requested-Action AVP set to DIRECT_DEBITING in the Credit-Control- | |||
| Request message. The Subscription-Id AVP SHOULD be included to | Request message. The Subscription-Id AVP SHOULD be included to | |||
| identify the End-User in the credit-control server. The Event- | identify the End-User in the credit-control server. The Event- | |||
| Timestamp AVP contains the time when the service event is requested | Timestamp AVP SHOULD be included in the request and contains the | |||
| in the service element. | time when the service event is requested in the service element. The | |||
| Service-Context-Id AVP 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 | |||
| be charged in the Requested-Service-Unit AVP, if it knows the cost of | to be charged in the Requested-Service-Unit AVP, if it knows the | |||
| the service event. If the Diameter credit-control client does not | cost of the service event. If the Diameter credit-control client | |||
| know the cost of the service event, the Requested-Service-Unit AVP | does not know the cost of the service event, the Requested-Service- | |||
| MAY contain the number of requested service events. The Service- | Unit AVP MAY contain the number of requested service events. The | |||
| Identifier AVP always indicates the concerned service, additional | Service-Identifier AVP always indicates the concerned service, | |||
| 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 MAY be sent within the Service-Parameter-Info AVP. | service specific AVPs or MAY be sent 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 end user's account. If the | the corresponding monetary amount from end user's account. If the | |||
| type of the Requested-Service-Unit AVP is money, no rating is needed | type of the Requested-Service-Unit AVP is money, no rating is needed | |||
| but the corresponding monetary amount is deducted from the End | ||||
| User's account. | ||||
| Diameter Credit Control Application May 14, 2004 | The credit-control server returns the Granted-Service-Unit AVP in | |||
| the Answer message to the Diameter credit-control client. The | ||||
| but the corresponding monetary amount is deducted from the End User's | Granted-Service-Unit AVP contains the amount of service units that | |||
| account. | the Diameter credit-control client can provide to the end user. The | |||
| type of the Granted-Service-Unit can be time, volume, service | ||||
| The credit-control server returns the Granted-Service-Unit AVP in the | specific or money depending on the type of service event. | |||
| Answer message to the Diameter credit-control client. The Granted- | ||||
| Service-Unit AVP contains the amount of service units that the | ||||
| Diameter credit-control client can provide to the end user. The type | ||||
| of the Granted-Service-Unit can be time, volume, service 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 that | needed for the service it can include the result code indicating | |||
| the credit-control is not applicable (e.g. service is free of | that the credit-control is not applicable (e.g. service is free of | |||
| charge). | 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 Refund | |||
| 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 CC-Request-Type to the value | |||
| EVENT_REQUEST and the Requested-Action AVP to REFUND in the Credit- | EVENT_REQUEST and the Requested-Action AVP to REFUND in the Credit- | |||
| Control-Request message. The Subscription-Id AVP SHOULD be included | Control-Request message. The Subscription-Id AVP SHOULD be included | |||
| to identify the End-User in the credit-control server. | to identify the End-User in the credit-control server. The Service- | |||
| Context-Id AVP 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 | |||
| be refunded in the Requested-Service-Unit AVP. The Service-Identifier | to be refunded in the Requested-Service-Unit AVP. The Service- | |||
| AVP always indicates the concerned service. If the Diameter credit- | Identifier AVP always indicates the concerned service. If the | |||
| control client does not know the monetary amount to be refunded, in | Diameter credit-control client does not know the monetary amount to | |||
| addition to the Service-Identifier AVP it MAY send service specific | be refunded, in addition to the Service-Identifier AVP it MAY send | |||
| AVPs or the Service-Parameter-Info AVP containing additional service | service specific AVPs or the Service-Parameter-Info AVP containing | |||
| 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 unit. | |||
| 6.5 Failure Procedure | 6.5 Failure Procedure | |||
| Failover to an alternative credit-control server is allowed for one | Failover to an alternative credit-control server is allowed for one | |||
| time event since the server is not maintaining session states, for | time event since 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 re-send the | |||
| request to an alternative server if possible. There MAY exist | request to an alternative server if possible. There MAY exist | |||
| protocol transparent Diameter relays and redirect agents or Diameter | protocol transparent Diameter relays and redirect agents or Diameter | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| credit-control proxies between credit-control client and credit- | credit-control proxies between credit-control client and credit- | |||
| control server. Failover may occur at any point in the path between | control server. Failover may occur at any point in the path between | |||
| credit-control client and credit-control server in the event that a | credit-control client and credit-control server in the event that a | |||
| transport failure is detected with a peer, as described in | transport failure is detected with a peer, as described in | |||
| [DIAMBASE]. Because there can be duplicate requests for various | [DIAMBASE]. Because there can be duplicate requests for various | |||
| reasons the credit-control server is therefore responsible for the | reasons the credit-control server is therefore responsible for the | |||
| real time duplicate detection. Implementation issues for duplicate | real time duplicate detection. Implementation issues for duplicate | |||
| detection are discussed in [DIAMBASE] Appendix C. | detection are discussed in [DIAMBASE] Appendix C. | |||
| When the credit-control client detects a communication failure to the | When the credit-control client detects a communication failure to | |||
| credit-control server, its behavior depends on the requested action. | the credit-control server, its behavior depends on the requested | |||
| The timer Tx (as defined in section 13) is used in the credit-control | action. The timer Tx (as defined in section 13) is used in the | |||
| client to supervise the communication with the credit-control server. | credit-control client to supervise the communication with the | |||
| credit-control server. | ||||
| In case the requested action is PRICE_ENQUIRY or BALANCE_CHECK and | In case the requested action is PRICE_ENQUIRY or BALANCE_CHECK and | |||
| 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 | |||
| if possible. The secondary Credit control server name, if received | server, if possible. The secondary Credit control server name, if | |||
| from the home Diameter AAA server, can be used as an address of | received from the home Diameter AAA server, can be used as an | |||
| backup server. | address of backup server. | |||
| If the requested action is DIRECT_DEBITING the Direct-Debiting- | If the requested action is DIRECT_DEBITING the Direct-Debiting- | |||
| Failure-Handling AVP (DDFH) controls the credit control client | Failure-Handling AVP (DDFH) controls the credit control client | |||
| behavior. The DDFH may be received from the home Diameter AAA server | behavior. The DDFH may be received from the home Diameter AAA server | |||
| or may be locally configured. The credit control server may also send | or may be locally configured. The credit control server may also | |||
| the DDFH in any CCA message to be used for direct debiting events | send the DDFH in any CCA message to be used for direct debiting | |||
| compiled thereafter. The DDFH value received from the home Diameter | events compiled thereafter. The DDFH value received from the home | |||
| AAA server overrides the locally configured value and the DDFH value | Diameter AAA server overrides the locally configured value and the | |||
| received from the credit control server in a Credit-Control-Answer | DDFH value received from the credit control server in a Credit- | |||
| message always override any already existing value. If the DDFH is | Control-Answer message always override any already existing value. | |||
| set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT | ||||
| grant the service if it can determine, eventually after a possible | ||||
| re-transmission attempt to an alternative credit control server, from | ||||
| the result code or error code in the answer message that units have | ||||
| not been debited. Otherwise the credit-control client SHOULD grant | ||||
| the service to the end user and store the request in the credit- | ||||
| control application level non-volatile storage (Note that re-sending | ||||
| the request at a later time is not a guarantee that the service will | ||||
| be debited, since the user's account may be empty at the time when | ||||
| the server successfully processes the request). The credit-control | ||||
| client MUST mark these request messages as possible duplicate by | ||||
| setting the T-flag in the command header as described in [DIAMBASE] | ||||
| section 3. If the Direct-Debiting-Failure-Handling AVP is set to | ||||
| CONTINUE, the service SHOULD be granted even if credit-control | ||||
| messages cannot be delivered and messages are not buffered. | ||||
| If the timer Tx expires the credit-control client MUST continue the | ||||
| service and wait for a possible late answer. If the request timeout | ||||
| the credit control client re-transmit the request (marked with T- | ||||
| flag) to a backup credit control server if possible. In the event | ||||
| Diameter Credit Control Application May 14, 2004 | 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 | ||||
| possible re-transmission attempt to an alternative credit control | ||||
| server, from the result code or error code in the answer message | ||||
| that units have not been debited. Otherwise the credit-control | ||||
| client SHOULD grant the service to the end user and store the | ||||
| request in the credit-control application level non-volatile storage | ||||
| (Note that re-sending the request at a later time is not a guarantee | ||||
| that the service will be debited, since the user's account may be | ||||
| empty at the time when the server successfully processes the | ||||
| request). The credit-control client MUST mark these request messages | ||||
| as possible duplicate by setting the T-flag in the command header as | ||||
| described in [DIAMBASE] section 3. | ||||
| If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the | ||||
| service SHOULD be granted even if credit-control messages cannot be | ||||
| delivered and messages are not buffered. | ||||
| that also the re-transmitted request timeout or a temporary error is | If the timer Tx expires the credit-control client MUST continue the | |||
| received in answer to such a request, the credit control client | service and wait for a possible late answer. If the request timeout | |||
| buffers the request if the value of the Direct-Debiting-Failure- | the credit control client re-transmit the request (marked with T- | |||
| Handling AVP is set to TERMINATE_OR_BUFFER. If a failed answer is | flag) to a backup credit control server if possible. In the event | |||
| received for the re-transmitted request, the credit control client | that also the re-transmitted request timeout or a temporary error is | |||
| frees all the resources reserved for the event message and deletes | received in answer to such a request, the credit control client | |||
| the request regardless the value of the DDFH. | buffers the request if the value of the Direct-Debiting-Failure- | |||
| Handling AVP is set to TERMINATE_OR_BUFFER. If a failed answer is | ||||
| received for the re-transmitted request, the credit control client | ||||
| frees all the resources reserved for the event message and deletes | ||||
| the request regardless the value of the DDFH. | ||||
| The Credit-Control-Request with requested action REFUND should always | The Credit-Control-Request with requested action REFUND should | |||
| be stored in the credit-control application level non-volatile | always be stored in the credit-control application level non- | |||
| storage in case of temporary failure. The credit-control client MUST | volatile storage in case of temporary failure. The credit-control | |||
| mark the re-transmitted request message as possible duplicate by | client MUST mark the re-transmitted request message as possible | |||
| setting the T-flag in the command header as described in [DIAMBASE] | duplicate by setting the T-flag in the command header as described | |||
| section 3. | in [DIAMBASE] 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 define a re-transmission | number of re-transmission attempts and define a re-transmission | |||
| interval. | interval. | |||
| It should be noted that only one place in the credit-control system | It should be noted that only one place in the credit-control system | |||
| SHOULD be responsible for duplicate detection. If there is only one | SHOULD be responsible for duplicate detection. If there is only one | |||
| credit-control server within the given realm, the credit-control | credit-control server within the given realm, the credit-control | |||
| server may perform duplicate detection. In case when more than one | server may perform duplicate detection. In case when more than one | |||
| credit-control servers are serving a given realm, only one entity in | credit-control servers are serving a given realm, only one entity in | |||
| the credit control system should be responsible to ensure that the | the credit control system should be responsible to ensure that the | |||
| end user's account is not debited or credited multiple times for the | end user's account is not debited or credited multiple times for the | |||
| same service event. | same service event. | |||
| 7. Credit Control Application State Machine | 7. Credit Control Application State Machine | |||
| This section defines the credit control application state machine. | This section defines the credit control application state machine. | |||
| 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. The first one describes the session-based credit-control | |||
| when the first interrogation is executed as part of the | when the first interrogation is executed as part of the | |||
| authorization/authentication process. The second one describes the | authorization/authentication process. The second one describes the | |||
| session-based credit-control when the first interrogation is executed | session-based credit-control when the first interrogation is | |||
| after the authorization/authentication process. The requirements what | executed after the authorization/authentication process. The | |||
| state machine need to be supported are discussed in section 5.2. | requirements what state machine need to be supported are discussed | |||
| in section 5.2. | ||||
| The third state machine describes the session-based credit-control | The third state machine describes the session-based credit-control | |||
| for intermediate and final interrogations. The fourth one describes | for intermediate and final interrogations. The fourth one describes | |||
| the event-based credit-control. These latter state machines are to be | the event-based credit-control. These latter state machines are to | |||
| observed by all the implementations that conform to this | be observed by all the implementations that conform to this | |||
| specification. | 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 perspective. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Any event not listed in the state machines MUST be considered as an | Any event not listed in the state machines MUST be considered as 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 the state table, 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 with a possibly defined alternative | desired destination or with a possibly defined alternative | |||
| destination in case failover procedure is supported (e.g. the request | destination in case failover procedure is supported (e.g. the | |||
| timeout and the answer message is not received). This could be due to | request timeout and the answer message is not received). This could | |||
| the peer being down, or due to a physical link failure in the path | be due to the peer being down, or due to a physical link failure in | |||
| to/from the credit-control server. | the path to/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 Result- | |||
| Code AVP of the Credit-Control-Answer command. The above protocol | Code AVP of the Credit-Control-Answer command. The above protocol | |||
| error notification may be ultimately received in answer to the re- | error notification may be ultimately received in answer to the re- | |||
| transmitted request to a possibly defined alternative destination if | transmitted request to a possibly defined alternative destination if | |||
| failover 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 | |||
| skipping to change at page 45, line 40 ¶ | skipping to change at page 46, line 50 ¶ | |||
| permanent failure notification may be ultimately received in answer | permanent failure notification may be ultimately received in answer | |||
| to the re-transmitted request to a possibly defined alternative | to the re-transmitted request to a possibly defined alternative | |||
| destination if failover is supported. | destination if 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 the | |||
| 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 unknown end user, | server could not process the message, e.g. due to unknown end user, | |||
| account being empty or due to errors defined in [DIAMBASE]. | account being empty or due to errors defined in [DIAMBASE]. | |||
| The Tx timer, which is used to control the waiting time in the Credit | The event 'User service terminated' can be triggered by various | |||
| control client in the PENDING state, is stopped when exiting the | reasons, e.g. normal user termination, network failure and ASR | |||
| Pending state. The stopping of the Tx timer is omitted in the state | (Abort-Session-Request). The Termination-Cause AVP contains | |||
| machine when the new state is Idle since moving to Idle state implies | information about the termination reason as specified in [DIAMBASE]. | |||
| the clearing of the session and all the variables associated to it. | ||||
| The Tx timer, which is used to control the waiting time in the | ||||
| Credit control client in the PENDING state, is stopped when exiting | ||||
| the Pending state. The stopping of the Tx timer is omitted in the | ||||
| state machine when the new state is Idle since moving to Idle state | ||||
| implies the clearing of the session and all the variables associated | ||||
| 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 abbreviations CCFH and DDFH stand for Credit-Control-Failure- | The abbreviations CCFH and DDFH stand for Credit-Control-Failure- | |||
| Handling and Direct-Debiting-Failure-Handling respectively. | Handling and Direct-Debiting-Failure-Handling respectively. | |||
| In the following state machine table the failover to a possibly | In the following state machine table the failover to a possibly | |||
| secondary server upon 'Temporary error' or 'Failure to send' is not | secondary server upon 'Temporary error' or 'Failure to send' is not | |||
| explicitly described. Moving an ongoing credit control message | ||||
| Diameter Credit Control Application May 14, 2004 | stream to an alternative server is, however, possible if the CC- | |||
| Session-Failover AVP is set to FAILOVER_SUPPORTED as described in | ||||
| explicitly described. Moving an ongoing credit control message stream | section 5.7. | |||
| 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 | Re-sending a credit control event to an alternative server is | |||
| supported as described in section 6.5. | supported as described in section 6.5. | |||
| CLIENT, SESSION BASED for the first interrogation with AA request | CLIENT, SESSION BASED for the first interrogation with AA request | |||
| State Event Action New State | State Event Action New State | |||
| --------------------------------------------------------------- | --------------------------------------------------------------- | |||
| Idle Client or device requests Send PendingI | Idle Client or device requests Send PendingI | |||
| access/service AA request | access/service AA request | |||
| with added | with added | |||
| CC AVPs, | CC AVPs, | |||
| start Tx | start Tx | |||
| PendingI Successful AA req. Grant Open | PendingI Successful AA req. Grant Open | |||
| skipping to change at page 46, line 38 ¶ | skipping to change at page 48, line 8 ¶ | |||
| stop Tx | stop Tx | |||
| PendingI Tx expired Disconnect Idle | PendingI Tx 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 Grant Idle | PendingI AA answer Grant Idle | |||
| received with result code service | received with result code service | |||
| equal to credit-control N/A to end user | equal to CREDIT_CONTROL_ to end user | |||
| NOT_APPLICABLE | ||||
| 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 | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| CLIENT, SESSION BASED for the first interrogation with CCR | CLIENT, SESSION BASED for the first interrogation with CCR | |||
| State Event Action New State | State Event Action New State | |||
| ---------------------------------------------------------------- | ---------------------------------------------------------------- | |||
| Idle Client or device requests Send PendingI | Idle Client or device requests Send PendingI | |||
| access/service CC initial | access/service CC initial | |||
| req., | req., | |||
| start Tx. | start Tx. | |||
| skipping to change at page 47, line 44 ¶ | skipping to change at page 49, line 9 ¶ | |||
| to CONTINUE or equal to service to | to CONTINUE or equal to service to | |||
| RETRY_AND_TERMINATE end user | RETRY_AND_TERMINATE end user | |||
| PendingI CC initial answer Terminate Idle | PendingI CC initial answer Terminate Idle | |||
| received with result code end user's | received with result code end user's | |||
| SERVICE_ DENIED or service | SERVICE_ DENIED or service | |||
| USER_UNKNOWN | USER_UNKNOWN | |||
| PendingI CC initial answer Grant Idle | PendingI CC initial answer Grant Idle | |||
| received with result code service | received with result code service | |||
| equal to credit-control N/A to end user | equal to CREDIT_CONTROL_ to end user | |||
| NOT_APPLICABLE | ||||
| PendingI Failed CC initial answer Grant Idle | PendingI Failed CC initial answer Grant Idle | |||
| received CCFH equal to Service to | received 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 end user's | received and CCFH equal end user's | |||
| to TERMINATE or equal to service | to TERMINATE or equal to service | |||
| RETRY_AND_TERMINATE | RETRY_AND_TERMINATE | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 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 | |||
| skipping to change at page 49, line 4 ¶ | skipping to change at page 50, line 19 ¶ | |||
| Open Change in rating condition Send PendingU | Open Change in rating condition Send PendingU | |||
| or Validity-Time elapses CC update | or Validity-Time elapses CC update | |||
| req., | req., | |||
| Start Tx. | Start Tx. | |||
| Open User service terminated Send PendingT | Open User service terminated Send PendingT | |||
| CC termination | CC termination | |||
| req. | req. | |||
| Open RAR received Send RAA PendingU | Open RAR received Send RAA PendingU | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| followed by | followed by | |||
| CC update req., | CC update req., | |||
| start Tx | start Tx | |||
| PendingU Successful CC update Stop Tx Open | PendingU Successful CC update Stop Tx Open | |||
| answer received | answer received | |||
| PendingU Failure to send, or Grant Idle | PendingU Failure to send, or Grant Idle | |||
| temporary error and service to | temporary error and service to | |||
| CCFH equal to CONTINUE end user | CCFH equal to CONTINUE end user | |||
| skipping to change at page 49, line 37 ¶ | skipping to change at page 50, line 49 ¶ | |||
| PendingU Tx expired and CCFH equal Grant PendingU | PendingU Tx expired and CCFH equal Grant PendingU | |||
| to CONTINUE or equal to service to | to CONTINUE or equal to service to | |||
| RETRY_AND_TERMINATE end user. | RETRY_AND_TERMINATE end user. | |||
| PendingU CC update answer Terminate Idle | PendingU CC update answer Terminate Idle | |||
| received with result code end user's | received with result code end user's | |||
| SERVICE_DENIED service | SERVICE_DENIED service | |||
| PendingU CC update answer Grant Idle | PendingU CC update answer Grant Idle | |||
| received with result code service | received with result code service | |||
| equal to credit-control N/A to end user | equal to CREDIT_CONTROL_ to end user | |||
| NOT_APPLICABLE | ||||
| PendingU Failed CC update Grant Idle | PendingU Failed CC update Grant Idle | |||
| answer received and service to | answer received and service to | |||
| CCFH equal to CONTINUE end user. | CCFH equal to CONTINUE end user. | |||
| PendingU Failed CC update Terminate Idle | PendingU Failed CC update Terminate Idle | |||
| answer received CCFH end user's | answer received CCFH end user's | |||
| equal to TERMINATE or service | equal to TERMINATE or service | |||
| equal to RETRY_AND_TERMINATE | equal to RETRY_AND_TERMINATE | |||
| PendingU User service terminated Queue PendingU | PendingU User service terminated Queue PendingU | |||
| termination | termination | |||
| event | event | |||
| PendingU Change in rating Queue PendingU | PendingU Change in rating Queue PendingU | |||
| condition changed | condition changed | |||
| rating | rating | |||
| condition | condition | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| event | event | |||
| PendingU RAR received Send RAA PendingU | PendingU RAR received Send RAA PendingU | |||
| PendingT Successful CC Idle | PendingT Successful CC Idle | |||
| termination answer received | termination answer received | |||
| PendingT Failure to send, or temporary Idle | PendingT Failure to send, or temporary Idle | |||
| error or failed answer | error or failed answer | |||
| skipping to change at page 50, line 50 ¶ | skipping to change at page 52, line 16 ¶ | |||
| action BALANCE_CHECK or | action BALANCE_CHECK or | |||
| PRICE_ENQUIRY | PRICE_ENQUIRY | |||
| PendingE CC event answer Terminate Idle | PendingE CC event answer Terminate Idle | |||
| received with result code end user's | received with result code end user's | |||
| SERVICE_DENIED or service | SERVICE_DENIED or service | |||
| USER_UNKNOWN and Tx running | USER_UNKNOWN and Tx running | |||
| PendingE CC event answer Grant Idle | PendingE CC event answer Grant Idle | |||
| received with result code service | received with result code service | |||
| credit-control N/A, requested to end | CREDIT_CONTROL_NOT_APPLICABLE, to end | |||
| action DIRECT_DEBITING user | requested action user | |||
| DIRECT_DEBITING | ||||
| PendingE Failure to send, temporary Grant Idle | PendingE Failure to send, temporary Grant Idle | |||
| error or failed CC event service | error or failed CC event service | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| answer received, requested to end | answer received, requested to end | |||
| action DIRECT_DEBITING and user | action DIRECT_DEBITING and user | |||
| DDFH equal to CONTINUE | DDFH equal to CONTINUE | |||
| PendingE Failed CC event Terminate Idle | PendingE Failed CC event Terminate Idle | |||
| answer received or temporary end user's | answer received or temporary end user's | |||
| error, requested action service | error, requested action service | |||
| DIRECT_DEBITING and | DIRECT_DEBITING and | |||
| DDFH equal to | DDFH equal to | |||
| TERMINATE_OR_BUFFER and | TERMINATE_OR_BUFFER and | |||
| skipping to change at page 52, line 5 ¶ | skipping to change at page 53, line 23 ¶ | |||
| Tx expired, requested request | Tx expired, requested request | |||
| action REFUND_ACCOUNT with T-flag | action REFUND_ACCOUNT with T-flag | |||
| PendingE Temporary error Store Idle | PendingE Temporary error Store Idle | |||
| and requested action request | and requested action request | |||
| REFUND_ACCOUNT | REFUND_ACCOUNT | |||
| PendingB Successful CC answer Delete Idle | PendingB Successful CC answer Delete Idle | |||
| received request | received request | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| PendingB Failed CC answer Delete Idle | PendingB Failed CC answer Delete Idle | |||
| received request | received request | |||
| PendingB Failure to send or Idle | PendingB Failure to send or Idle | |||
| temporary error | temporary error | |||
| SERVER, SESSION AND EVENT BASED | SERVER, SESSION AND EVENT BASED | |||
| State Event Action New State | State Event Action New State | |||
| ---------------------------------------------------------------- | ---------------------------------------------------------------- | |||
| Idle CC initial request Send Open | Idle CC initial request Send Open | |||
| received and successfully CC initial | received and successfully CC initial | |||
| processed. answer, | processed. answer, | |||
| reserve units, | reserve units, | |||
| start Tcc | start Tcc | |||
| Idle CC initial request Send Idle | Idle CC initial request Send Idle | |||
| received, but not CC initial | received, but not CC initial | |||
| successfully processed. answer with | successfully processed. answer with | |||
| Result-Code | Result-Code | |||
| != SUCCESS | != SUCCESS | |||
| Idle CC event request Send Idle | Idle CC event request Send Idle | |||
| received and successfully CC event | received and successfully CC event | |||
| processed. answer | processed. answer | |||
| Idle CC event request Send Idle | Idle CC event request Send Idle | |||
| received, but not CC event | received, but not CC event | |||
| successfully processed. answer with | successfully processed. answer with | |||
| Result-Code | Result-Code | |||
| != SUCCESS | != SUCCESS | |||
| Open CC update request Send CC Open | Open CC update request Send CC Open | |||
| received and successfully update answer, | received and successfully update answer, | |||
| processed debit used | processed debit used | |||
| skipping to change at page 53, line 5 ¶ | skipping to change at page 54, line 23 ¶ | |||
| Restart Tcc | Restart Tcc | |||
| Open CC update request Send Idle | Open CC update request Send Idle | |||
| received, but not CC update | received, but not CC update | |||
| successfully processed. answer with | successfully processed. answer with | |||
| Result-Code | Result-Code | |||
| != SUCCESS, | != SUCCESS, | |||
| debit used | debit used | |||
| units | units | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Open CC termination request Send Idle | Open CC termination request Send Idle | |||
| received, and successfully CC termin. | received, and successfully CC termin. | |||
| processed answer, | processed answer, | |||
| Stop Tcc, | Stop Tcc, | |||
| debit used | debit used | |||
| units | units | |||
| Open CC termination request Send Idle | Open CC termination request Send Idle | |||
| received, but not CC termin. | received, but not CC termin. | |||
| successfully processed. answer with | successfully processed. answer with | |||
| Result-Code | Result-Code | |||
| != SUCCESS, | != SUCCESS, | |||
| debit used | debit used | |||
| units | units | |||
| Open Session supervision timer Tcc release Idle | Open Session supervision timer Tcc release Idle | |||
| expired reserved | expired reserved | |||
| units | units | |||
| 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 | |||
| Diameter Credit-control Application and MAY be included in the | Diameter Credit-control Application and 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 [NASREQ] and [DIAMMIP], in case the first | applications, such as [NASREQ] and [DIAMMIP], in case 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 [DIAMBASE], | The Diameter AVP rules are defined in the Diameter Base [DIAMBASE], | |||
| section 4. These AVP rules are observed in AVPs defined in this | section 4. These AVP rules are observed in AVPs defined in this | |||
| section. | section. | |||
| The following table describes the Diameter AVPs defined in Credit- | The following table describes the Diameter AVPs defined in Credit- | |||
| control application, their AVP Code values, types, possible flag | control application, their AVP Code values, types, possible flag | |||
| values and whether the AVP MAY be encrypted. The Diameter base | values and whether the AVP MAY be encrypted. The Diameter base | |||
| [DIAMBASE] specifies in the section 4.5 the AVP Flag rules for AVPs. | [DIAMBASE] specifies in the section 4.5 the AVP Flag rules for AVPs. | |||
| Diameter Credit Control Application May 14, 2004 | +--------------------+ | |||
| | AVP Flag rules | | ||||
| +---------------------+ | |----+-----+----+----|----+ | |||
| | AVP Flag rules | | AVP Section | | |SHLD|MUST| | | |||
| |----+-----+----+-----|----+ | Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr| | |||
| AVP Section | | |SHLD| MUST| | | -----------------------------------------|----+-----+----+----|----| | |||
| Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| | CC-Correlation-Id TBD 8.1 OctetString| | P,M | | V | Y | | |||
| -----------------------------------------|----+-----+----+-----|----| | CC-Input-Octets TBD 8.24 Unsigned64 | M | P | | V | Y | | |||
| CC-Correlation-Id TBD 8.1 OctetString| | P,M | | V | Y | | CC-Money TBD 8.22 Grouped | M | P | | V | Y | | |||
| CC-Input-Octets TBD 8.24 Unsigned64 | M | P | | V | Y | | CC-Output-Octets TBD 8.25 Unsigned64 | M | P | | V | Y | | |||
| CC-Money TBD 8.22 Grouped | M | P | | V | Y | | CC-Request-Number TBD 8.2 Unsigned32 | M | P | | V | Y | | |||
| CC-Output-Octets TBD 8.25 Unsigned64 | M | P | | V | Y | | CC-Request-Type TBD 8.3 Enumerated | M | P | | V | Y | | |||
| CC-Request-Number TBD 8.2 Unsigned32 | M | P | | V | Y | | CC-Service- TBD 8.26 Unsigned64 | M | P | | V | Y | | |||
| CC-Request-Type TBD 8.3 Enumerated | M | P | | V | Y | | Specific-Units | | | | | | | |||
| CC-Service- TBD 8.26 Unsigned64 | M | P | | V | Y | | CC-Session- TBD 8.4 Enumerated | M | P | | V | Y | | |||
| Specific-Units | | | | | | | Failover | | | | | | | |||
| CC-Session- TBD 8.4 Enumerated | M | P | | V | Y | | CC-Sub-Session-Id TBD 8.5 Unsigned64 | M | P | | V | Y | | |||
| Failover | | | | | | | CC-Time TBD 8.21 Unsigned32 | M | P | | V | Y | | |||
| CC-Sub-Session-Id TBD 8.5 Unsigned64 | M | P | | V | Y | | CC-Total-Octets TBD 8.23 Unsigned64 | M | P | | V | Y | | |||
| CC-Time TBD 8.21 Unsigned32 | M | P | | V | Y | | CC-Unit-Type TBD 8.32 Enumerated | M | P | | V | Y | | |||
| CC-Total-Octets TBD 8.23 Unsigned64 | M | P | | V | Y | | Check-Balance- TBD 8.6 Enumerated | M | P | | V | Y | | |||
| CC-Unit-Type TBD 8.32 Enumerated | M | P | | V | Y | | Result | | | | | | | |||
| Check-Balance- TBD 8.6 Enumerated | M | P | | V | Y | | Cost-Information TBD 8.7 Grouped | M | P | | V | Y | | |||
| Result | | | | | | | Cost-Unit TBD 8.12 UTF8String | M | P | | V | Y | | |||
| Cost-Information TBD 8.7 Grouped | M | P | | V | Y | | Credit-Control TBD 8.13 Enumerated | M | P | | V | Y | | |||
| Cost-Unit TBD 8.12 UTF8String | M | P | | V | Y | | Credit-Control- TBD 8.14 Enumerated | M | P | | V | Y | | |||
| Credit-Control TBD 8.13 Enumerated | M | P | | V | Y | | Failure-Handling | | | | | | | |||
| Credit-Control- TBD 8.14 Enumerated | M | P | | V | Y | | Currency-Code TBD 8.18 Unsigned32 | M | P | | V | Y | | |||
| Failure-Handling | | | | | | | Direct-Debiting TBD 8.19 Enumerated | M | P | | V | Y | | |||
| Currency-Code TBD 8.18 Unsigned32 | M | P | | V | Y | | Failure-Handling | | | | | | | |||
| Direct-Debiting TBD 8.19 Enumerated | M | P | | V | Y | | Exponent TBD 8.9 Integer32 | M | P | | V | Y | | |||
| Failure-Handling | | | | | | | Final-Unit-Action TBD 8.35 Enumerated | M | P | | V | Y | | |||
| Exponent TBD 8.9 Integer32 | M | P | | V | Y | | Final-Unit- TBD 8.34 Grouped | M | P | | V | Y | | |||
| Final-Unit-Action TBD 8.35 Enumerated | M | P | | V | Y | | Indication | | | | | | | |||
| Final-Unit- TBD 8.34 Grouped | M | P | | V | Y | | Granted-Service- TBD 8.17 Grouped | M | P | | V | Y | | |||
| Indication | | | | | | | Unit | | | | | | | |||
| Granted-Service- TBD 8.17 Grouped | M | P | | V | Y | | G-S-U-Pool- TBD 8.32 Unsigned32 | M | P | | V | Y | | |||
| Unit | | | | | | | Identifier | | | | | | | |||
| G-S-U-Pool- TBD 8.32 Unsigned32 | M | P | | V | Y | | G-S-U-Pool- TBD 8.25 Grouped | M | P | | V | Y | | |||
| Identifier | | | | | | | Reference | | | | | | | |||
| G-S-U-Pool- TBD 8.25 Grouped | M | P | | V | Y | | Multiple-Services TBD 8.16 Grouped | M | P | | V | Y | | |||
| Reference | | | | | | | -Credit-Control | | | | | | | |||
| Multiple-Services TBD 8.16 Grouped | M | P | | V | Y | | Multiple-Services TBD 8.40 Enumerated | M | P | | V | Y | | |||
| -Credit-Control | | | | | | | -Indicator | | | | | | | |||
| Multiple-Services TBD 8.40 Enumerated | M | P | | V | Y | | Rating-Group TBD 8.29 Unsigned32 | M | P | | V | Y | | |||
| -Indicator | | | | | | | Redirect-Address TBD 8.38 Enumerated | M | P | | V | Y | | |||
| Rating-Group TBD 8.29 Unsigned32 | M | P | | V | Y | | -Type | | | | | | | |||
| Redirect-Address TBD 8.38 Enumerated | M | P | | V | Y | | Redirect-Server TBD 8.37 Grouped | M | P | | V | Y | | |||
| -Type | | | | | | | Redirect-Server TBD 8.39 UTF8String | M | P | | V | Y | | |||
| Redirect-Server TBD 8.37 Grouped | M | P | | V | Y | | -Address | | | | | | | |||
| Redirect-Server TBD 8.39 UTF8String | M | P | | V | Y | | Requested-Action TBD 8.41 Enumerated | M | P | | V | Y | | |||
| Requested-Service TBD 8.18 Grouped | M | P | | V | Y | | ||||
| Diameter Credit Control Application May 14, 2004 | Unit | | | | | | | |||
| Restriction TBD 8.36 IPFiltrRule| M | P | | V | Y | | ||||
| -Address | | | | | | | -Filter-Rule | | | | | | | |||
| Requested-Action TBD 8.41 Enumerated | M | P | | V | Y | | Service-Context TBD 8.42 UTF8String | M | P | | V | Y | | |||
| Requested-Service TBD 8.18 Grouped | M | P | | V | Y | | -Id | | | | | | | |||
| Unit | | | | | | | Service- TBD 8.28 UTF8String | M | P | | V | Y | | |||
| Restriction TBD 8.36 IPFiltrRule| M | P | | V | Y | | Identifier | | | | | | | |||
| -Filter-Rule | | | | | | | Service-Parameter TBD 8.43 Grouped | | P,M | | V | Y | | |||
| Service- TBD 8.28 UTF8String | M | P | | V | Y | | -Info | | | | | | | |||
| Identifier | | | | | | | Service- TBD 8.44 Unsigned32 | | P,M | | V | Y | | |||
| Service-Parameter TBD 8.42 Grouped | | P,M | | V | Y | | Parameter-Type | | | | | | | |||
| -Info | | | | | | | Service- TBD 8.45 OctetString| | P,M | | V | Y | | |||
| Service- TBD 8.43 Unsigned32 | | P,M | | V | Y | | Parameter-Value | | | | | | | |||
| Parameter-Type | | | | | | | Subscription-Id TBD 8.46 Grouped | M | P | | V | Y | | |||
| Service- TBD 8.44 OctetString| | P,M | | V | Y | | Subscription-Id TBD 8.48 UTF8String | M | P | | V | Y | | |||
| Parameter-Value | | | | | | | -Data | | | | | | | |||
| Subscription-Id TBD 8.45 Grouped | M | P | | V | Y | | Subscription-Id TBD 8.47 Enumerated | M | P | | V | Y | | |||
| Subscription-Id TBD 8.47 UTF8String | M | P | | V | Y | | -Type | | | | | | | |||
| -Data | | | | | | | Tariff-Change TBD 8.27 Enumerated | M | P | | V | Y | | |||
| Subscription-Id TBD 8.46 Enumerated | M | P | | V | Y | | -Usage | | | | | | | |||
| -Type | | | | | | | Tariff-Time TBD 8.20 Time | M | P | | V | Y | | |||
| Tariff-Change TBD 8.27 Enumerated | M | P | | V | Y | | -Change | | | | | | | |||
| -Usage | | | | | | | Unit-Value TBD 8.8 Grouped | M | P | | V | Y | | |||
| Tariff-Time TBD 8.20 Time | M | P | | V | Y | | Used-Service-Unit TBD 8.19 Grouped | M | P | | V | Y | | |||
| -Change | | | | | | | User-Equipment TBD 8.49 Grouped | | P,M | | V | Y | | |||
| Unit-Value TBD 8.8 Grouped | M | P | | V | Y | | -Info | | | | | | | |||
| Used-Service-Unit TBD 8.19 Grouped | M | P | | V | Y | | User-Equipment TBD 8.50 Enumerated | | P,M | | V | Y | | |||
| User-Equipment TBD 8.48 Grouped | | P,M | | V | Y | | -Info-Type | | | | | | | |||
| -Info | | | | | | | User-Equipment TBD 8.51 OctetString| | P,M | | V | Y | | |||
| User-Equipment TBD 8.49 Enumerated | | P,M | | V | Y | | -Info-Value | | | | | | | |||
| -Info-Type | | | | | | | Value-Digits TBD 8.10 Integer64 | M | P | | V | Y | | |||
| User-Equipment TBD 8.50 OctetString| | P,M | | V | Y | | Validity-Time TBD 8.33 Unsigned32 | M | P | | V | Y | | |||
| -Info-Value | | | | | | | ||||
| Value-Digits TBD 8.10 Integer64 | M | P | | V | Y | | ||||
| Validity-Time TBD 8.33 Unsigned32 | M | P | | V | Y | | ||||
| [IANA please fill in the TBA values in this table with appropriate | [IANA please fill in the TBD values in this table with appropriate | |||
| AVP codes, suggested values listed below and remove this note.] | AVP codes, suggested values listed below and remove this note.] | |||
| 8.1 CC-Correlation-Id AVP | 8.1 CC-Correlation-Id AVP | |||
| The CC-Correlation-Id AVP (AVP Code XXX - IANA please fill in and | The CC-Correlation-Id AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 411) is of type OctetString and | remove this note - suggested value 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-Identifier, i.e. unique | level. The one who allocates the Service-Context-Id, i.e. unique | |||
| identifier of a service, is also responsible to define the content | identifier of a service specific document, is also responsible to | |||
| and encoding of the CC-Correlation-Id AVP. | define the content and encoding of the CC-Correlation-Id AVP. | |||
| 8.2 CC-Request-Number AVP | ||||
| Diameter Credit Control Application May 14, 2004 | 8.2 CC-Request-Number AVP | |||
| The CC-Request-Number AVP (AVP Code XXX - IANA please fill in and | The CC-Request-Number AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 415) is of type Unsigned32 and | remove this note - suggested value 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 Session-Id and CC-Request-Number | |||
| AVPs is also globally unique, and can be used in matching credit | AVPs is also globally unique, and can be used in matching credit | |||
| control messages with confirmations. An easy way to produce unique | control messages with confirmations. An easy way to produce unique | |||
| numbers is to set the value to 0 for credit control request of type | numbers is to set the value to 0 for credit control request of type | |||
| INITIAL_REQUEST and EVENT_REQUEST, and set the value to 1 for the | INITIAL_REQUEST and EVENT_REQUEST, and set the value to 1 for the | |||
| first UPDATE_REQUEST, 2 for the second, and so on until the value for | first UPDATE_REQUEST, 2 for the second, and so on until the value | |||
| for | ||||
| TERMINATION_REQUEST. | TERMINATION_REQUEST. | |||
| 8.3 CC-Request-Type AVP | 8.3 CC-Request-Type AVP | |||
| The CC-Request-Type AVP (AVP Code XXX - IANA please fill in and | The CC-Request-Type AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 416) is of type Enumerated and | remove this note - suggested value 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 CC-Request messages. The following values | It MUST be present in all CC-Request messages. The following values | |||
| are defined for the CC-Request-Type AVP: | are defined for the CC-Request-Type AVP: | |||
| INITIAL_REQUEST 1 | INITIAL_REQUEST 1 | |||
| A Credit-control Initial request is used to initiate a credit | A Credit-control Initial request is used to initiate a credit | |||
| control session, and contains credit control information that is | control session, and contains credit control information that is | |||
| skipping to change at page 56, line 49 ¶ | skipping to change at page 58, line 10 ¶ | |||
| TERMINATION_REQUEST 3 | TERMINATION_REQUEST 3 | |||
| A Credit-control Termination Request is sent to terminate a | A Credit-control Termination Request is sent to terminate a | |||
| credit-control session and contains credit control information | credit-control session and contains credit control information | |||
| relevant to the existing session. | relevant to the existing session. | |||
| EVENT_REQUEST 4 | EVENT_REQUEST 4 | |||
| A Credit Control Event Request is used when there is no need | A Credit Control Event Request is used when there is no need | |||
| to maintain any credit control session state in the credit- | to maintain any credit control session state in the credit- | |||
| control server. This request contains all information relevant to | control server. This request contains all information relevant to | |||
| the service, and is the only request of the service. The reason | the service, and is the only request of the service. The reason | |||
| forthe Event request is further detailed in the Requested-Action | for the Event request is further detailed in the Requested-Action | |||
| AVP. The Requested-Action AVP MUST be included in the Credit- | AVP. The Requested-Action AVP MUST be included in the Credit- | |||
| Control-Request message when CC-Request-Type is set to | Control-Request message when CC-Request-Type is set to | |||
| EVENT_REQUEST. | EVENT_REQUEST. | |||
| Diameter Credit Control Application May 14, 2004 | 8.4 CC-Session-Failover AVP | |||
| 8.4 CC-Session-Failover AVP | ||||
| The CC-Session-Failover AVP (AVP Code XXX - IANA please fill in and | The CC-Session-Failover AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 418) is type of Enumerated and | remove this note - suggested value 418) is type of Enumerated and | |||
| contains information whether the moving of the credit-control message | contains information whether the moving of the credit-control | |||
| stream to a backup server during an ongoing credit-control session is | message stream to a backup server during an ongoing credit-control | |||
| supported. In case of communication failures, the credit control | session is supported. In case of communication failures, the credit | |||
| message streams can be moved to an alternative destination if the | control message streams can be moved to an alternative destination | |||
| credit control server supports failover to an alternative server. The | if the credit control server supports failover to an alternative | |||
| secondary credit control server name, if received from the home | server. The secondary credit control server name, if received from | |||
| Diameter AAA server, can be used as an address of the backup server. | the home Diameter AAA server, can be used as an address of the | |||
| An implementation is not required to support the moving of credit | backup server. An implementation is not required to support the | |||
| control message stream to an alternative server, since it requires | moving of credit control message stream to an alternative server, | |||
| also moving of information related to the credit control session to | since it requires also moving of information related to the credit | |||
| backup server. | control session to 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 to be moved to | the Credit control message stream MUST NOT to be moved to | |||
| alternative destination in case of communication failure. | alternative destination in case of communication failure. | |||
| This is the default behavior if the AVP isn't included in the | This is the default behavior if the AVP isn't included in the | |||
| reply from the authorization or credit-control server. | reply from the 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, | |||
| Credit control message stream SHOULD be moved to alternative | the Credit control message stream SHOULD be moved to alternative | |||
| destination in case of communication failure. The moving the | destination in case of communication failure. The moving the | |||
| credit control message stream to backup server MAY require that | credit control message stream to backup server MAY require that | |||
| information related to the credit control session should be also | information related to the credit control session should be also | |||
| forwarded to alternative server. | forwarded to alternative server. | |||
| 8.5 CC-Sub-Session-Id AVP | 8.5 CC-Sub-Session-Id AVP | |||
| The CC-Sub-Session-Id AVP (AVP Code XXX - IANA please fill in and | The CC-Sub-Session-Id AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 419) is of type Unsigned64 and | remove this note - suggested value 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 and this AVP MUST be unique per sub-session, and | |||
| the value of this AVP MUST be monotonically increased by one for all | the value of this AVP MUST be monotonically increased by one for all | |||
| new sub-sessions. The absence of this AVP implies no sub-sessions are | new sub-sessions. The absence of this AVP implies no sub-sessions | |||
| in use. | are in use. | |||
| 8.6 Check-Balance-Result AVP | 8.6 Check-Balance-Result AVP | |||
| The Check Balance Result AVP (AVP Code XXX - IANA please fill in and | The Check Balance Result AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 422) is of type Enumerated and | remove this note - suggested value 422) is of type Enumerated and | |||
| contains the result of the balance check. This AVP is applicable | ||||
| Diameter Credit Control Application May 14, 2004 | only when the Requested-Action AVP indicates CHECK_BALANCE in the | |||
| Credit-Control-Request command. | ||||
| contains the result of the balance check. This AVP is applicable only | ||||
| when the Requested-Action AVP indicates CHECK_BALANCE in the Credit- | ||||
| Control-Request command. | ||||
| The following values are defined for the Check-Balance-Result AVP. | The following values are defined for the Check-Balance-Result AVP. | |||
| ENOUGH_CREDIT 0 | ENOUGH_CREDIT 0 | |||
| There is enough credit in the account to cover the requested | There is enough credit in the account to cover the requested | |||
| service. | 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 XXX - IANA please fill in and | The Cost-Information AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 423) is of type Grouped and it is | remove this note - suggested value 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 credit | |||
| control client can transfer transparently to the end user. The | control client can transfer transparently to the end user. The | |||
| included Unit-Value AVP contains the cost estimate (always type of | included Unit-Value AVP contains the cost estimate (always type of | |||
| money) of the service in case of price enquiry or the accumulated | money) of the service in case of price enquiry or the accumulated | |||
| cost estimation in the case of credit-control session. | cost estimation in the case of credit-control session. | |||
| The Currency-Code specifies in which currency the cost was given. | The Currency-Code 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 specifies the unit when the service cost is a cost per | |||
| unit (e.g. cost for the service is $1 per minute). | 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 value PRICE_ENQUIRY is included | |||
| the Credit-Control-Request command the Cost-Information AVP sent in | in the Credit-Control-Request command the Cost-Information AVP sent | |||
| the succeeding Credit-Control-Answer command contains the cost | in the succeeding Credit-Control-Answer command contains the cost | |||
| estimation of the requested service, without any reservation being | estimation of the requested service, without any reservation being | |||
| made. | 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-reservation 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 has the following ABNF grammar: | It has the following ABNF grammar: | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Cost-Information ::= < AVP Header: TBD > | Cost-Information ::= < AVP Header: TBD > | |||
| { 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 XXX - IANA please fill in | Unit-Value AVP is of type Grouped (AVP Code XXX - IANA please fill | |||
| and remove this note - suggested value 445) and specifies the units | in and remove this note - suggested value 445) and specifies the | |||
| as decimal value. The Unit-Value is a value together with an | units as decimal value. The Unit-Value is a value together with an | |||
| exponent, i.e. Unit-Value = Value-Digits AVP * 10^Exponent. This | exponent, i.e. Unit-Value = Value-Digits AVP * 10^Exponent. This | |||
| representation avoids unwanted rounding off. For example the value of | representation avoids unwanted rounding off. For example the value | |||
| 2,3 is represented as Value-Digits = 23 and Exponent = -1. The | of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The | |||
| absence of exponent part MUST be interpreted as exponent being equal | absence of exponent part MUST be interpreted as exponent being equal | |||
| to zero. | to zero. | |||
| It has the following ABNF grammar: | It has the following ABNF grammar: | |||
| Unit-Value ::= < AVP Header: TBD > | Unit-Value ::= < AVP Header: TBD > | |||
| { Value-Digits } | { Value-Digits } | |||
| [ Exponent ] | [ Exponent ] | |||
| 8.9 Exponent AVP | 8.9 Exponent AVP | |||
| Exponent AVP is of type Integer32 (AVP Code XXX - IANA please fill in | Exponent AVP is of type Integer32 (AVP Code XXX - IANA please fill | |||
| and remove this note - suggested value 429) and contains the exponent | in and remove this note - suggested value 429) and contains the | |||
| value to be applied for the Value-Digit AVP within the Unit-Value | exponent value to be applied for the Value-Digit AVP within the | |||
| AVP. | Unit-Value AVP. | |||
| 8.10 Value-Digits AVP | 8.10 Value-Digits AVP | |||
| The Value-Digits AVP is of type Integer64 (AVP Code XXX - IANA please | The Value-Digits AVP is of type Integer64 (AVP Code XXX - IANA | |||
| fill in and remove this note - suggested value 447) and contains the | please fill in and remove this note - suggested value 447) and | |||
| significant digits of the number. If decimal values are needed to | contains the significant digits of the number. If decimal values are | |||
| present the units, the scaling MUST be indicated with the related | needed to present the units, the scaling MUST be indicated with the | |||
| Exponent AVP. For example for the monetary amount $ 0.05 the value of | related Exponent AVP. For example for the monetary amount $ 0.05 the | |||
| Value-Digits AVP MUST be set to 5 and the scaling MUST be indicated | value of Value-Digits AVP MUST be set to 5 and the scaling MUST be | |||
| 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 XXX - IANA please fill in and remove | The Currency-Code AVP (AVP Code XXX - IANA please fill in and remove | |||
| this note - suggested value 425) is of type Unsigned32 and contains a | this note - suggested value 425) is of type Unsigned32 and contains | |||
| currency code that specifies in which currency the values of AVPs | a currency code that specifies in which currency the values of AVPs | |||
| containing monetary units were given. It is specified using the | containing monetary units were given. It is specified using the | |||
| numeric values defined in the ISO 4217 standard [ISO4217]. | numeric values defined in the ISO 4217 standard [ISO4217]. | |||
| Diameter Credit Control Application May 14, 2004 | 8.12 Cost-Unit AVP | |||
| 8.12 Cost-Unit AVP | ||||
| The Cost-Unit AVP (AVP Code XXX - IANA please fill in and remove this | The Cost-Unit AVP (AVP Code XXX - IANA please fill in and remove | |||
| note - suggested value 424) is of type UTF8String and it is used | this note - suggested value 424) is of type UTF8String and it is | |||
| used | ||||
| to display human readable string to the end user. It specifies the | to display human readable string to the end user. It specifies the | |||
| applicable unit to the Cost-Information when the service cost is a | applicable unit to the Cost-Information when the service cost is a | |||
| cost per unit (e.g. cost of the service is $1 per minute). The Cost- | cost per unit (e.g. cost of the service is $1 per minute). The Cost- | |||
| Unit can be for instance minute, hour, day, kilobytes, megabytes etc. | Unit can be for instance minute, hour, day, kilobytes, megabytes | |||
| etc. | ||||
| 8.13 Credit-Control AVP | 8.13 Credit-Control AVP | |||
| The Credit-Control AVP (AVP Code XXX - IANA please fill in and remove | The Credit-Control AVP (AVP Code XXX - IANA please fill in and | |||
| this note - suggested value 426) is of type Enumerated and MUST be | remove this note - suggested value 426) is of type Enumerated and | |||
| included in AA requests when service element has credit control | MUST be included in AA requests when service element has credit | |||
| capabilities. | control capabilities. | |||
| CREDIT_AUTHORIZATION 0 | CREDIT_AUTHORIZATION 0 | |||
| If the home Diameter AAA server determines the user is a prepaid | If the home Diameter AAA server determines the user is a prepaid | |||
| user, this value indicates that credit-control server MUST be | user, this value indicates that credit-control server MUST be | |||
| contacted to perform the first interrogation. The value of the | contacted to perform the first interrogation. The value of the | |||
| Credit-Control AVP MUST always be set to 0 in AA request sent to | Credit-Control AVP MUST always be set to 0 in AA request sent to | |||
| perform the first interrogation and initiate a new credit-control | perform the first interrogation and initiate a new credit-control | |||
| session. | session. | |||
| RE_AUTHORIZATION 1 | RE_AUTHORIZATION 1 | |||
| This value indicates to the Diameter AAA server that a credit- | This value indicates to the Diameter AAA server that a credit- | |||
| control session is ongoing for the subscriber and the credit- | control session is ongoing for the subscriber and the credit- | |||
| control server MUST not be contacted. The Credit-Control AVP set | control server MUST not be contacted. The Credit-Control AVP set | |||
| to the value of 1 is to be used only when the first interrogation | to the value of 1 is to be used only when the first interrogation | |||
| has been successfully performed and the credit-control session is | has been successfully performed and the credit-control session is | |||
| ongoing (i.e. re-authorization triggered by Authorization- | ongoing (i.e. re-authorization triggered by Authorization- | |||
| Lifetime). This value MUST NOT be used in AA request sent to | Lifetime). This value MUST NOT be used in AA request sent to | |||
| perform the first interrogation. | perform the first interrogation. | |||
| 8.14 Credit-Control-Failure-Handling AVP | 8.14 Credit-Control-Failure-Handling AVP | |||
| The Credit-Control-Failure-Handling AVP (AVP Code XXX - IANA please | The Credit-Control-Failure-Handling AVP (AVP Code XXX - IANA please | |||
| fill in and remove this note - suggested value 427) is of type | fill in and remove this note - suggested value 427) is of type | |||
| Enumerated. The credit-control client uses information in this AVP to | Enumerated. The credit-control client uses information in this AVP | |||
| decide what to do if the sending of credit-control messages to the | to decide what to do if the sending of credit-control messages to | |||
| credit-control server has been for instance temporarily prevented due | the credit-control server has been for instance temporarily | |||
| to a network problem. Depending on the service logic, the credit- | prevented due to a network problem. Depending on the service logic, | |||
| control server can order the client to terminate the service | the credit-control server can order the client to terminate the | |||
| immediately when there is a reason to believe that the service cannot | service immediately when there is a reason to believe that the | |||
| be charged, or to try failover to an alternative server, if possible, | service cannot be charged, or to try failover to an alternative | |||
| and then either terminate or grant the service should also the | server, if possible, and then either terminate or grant the service | |||
| alternative connection fail. | should also the alternative connection fail. | |||
| TERMINATE 0 | TERMINATE 0 | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| When the Credit-Control-Failure-Handling AVP is set to TERMINATE | When the Credit-Control-Failure-Handling AVP is set to TERMINATE | |||
| the service MUST only be granted as long as there is a connection | the service MUST only be granted as long as there is a connection | |||
| to the credit-control server. If the credit-control client does | to the credit-control server. If the credit-control client does | |||
| not receive any Credit-Control-Answer message within the Tx timer | not receive any Credit-Control-Answer message within the Tx timer | |||
| (as defined in section 13) the credit-control request is regarded | (as defined in section 13) the credit-control request is regarded | |||
| failed and the end user's service session is terminated. | failed and the end user's service session is terminated. | |||
| This is the default behavior if the AVP isn't included in the | This is the default behavior if the AVP isn't included in the | |||
| reply from the authorization or credit-control server. | reply from the authorization or credit-control server. | |||
| skipping to change at page 61, line 30 ¶ | skipping to change at page 62, line 38 ¶ | |||
| alternative server in case of transport or temporary failures, | alternative server in case of transport or temporary failures, | |||
| provided that failover procedure is supported in the credit- | provided that failover procedure is supported in the credit- | |||
| control server and the credit-control client, and an alternative | control server and the credit-control client, and an alternative | |||
| server is available. Otherwise, the service SHOULD be granted | server is available. Otherwise, the service SHOULD be granted | |||
| even if credit-control messages can't be delivered. | even if credit-control messages can't be delivered. | |||
| RETRY_AND_TERMINATE 2 | RETRY_AND_TERMINATE 2 | |||
| When the Credit-Control-Failure-Handling AVP is set to | When the Credit-Control-Failure-Handling AVP is set to | |||
| RETRY_AND_TERMINATE the credit-control client SHOULD re-send the | RETRY_AND_TERMINATE the credit-control client SHOULD re-send the | |||
| request to an alternative server in case of transport or | request to an alternative server in case of transport or | |||
| temporary failures, provided that failover procedure is supported | temporary failures, provided that failover procedure is | |||
| in the credit-control server and the credit-control client, and | supported in the credit-control server and the credit-control | |||
| an alternative server is available. Otherwise, the service SHOULD | client, and an alternative server is available. Otherwise, the | |||
| not be granted when the credit-control messages can't be | service SHOULD not be granted when the credit-control messages | |||
| delivered. | can't be delivered. | |||
| 8.15 Direct-Debiting-Failure-Handling AVP | 8.15 Direct-Debiting-Failure-Handling AVP | |||
| The Direct-Debiting-Failure-Handling AVP (AVP Code XXX - IANA please | The Direct-Debiting-Failure-Handling AVP (AVP Code XXX - IANA please | |||
| fill in and remove this note - suggested value 428) is of type | fill in and remove this note - suggested value 428) is of type | |||
| Enumerated. The credit-control client uses information in this AVP to | Enumerated. The credit-control client uses information in this AVP | |||
| decide what to do if the sending of credit-control messages | to decide what to do if the sending of credit-control messages | |||
| (Requested-Action AVP set to Direct Debiting) to the credit-control | (Requested-Action AVP set to Direct Debiting) to the credit-control | |||
| server has been for instance temporarily prevented due to a network | server has been for instance temporarily prevented due to a network | |||
| problem. | problem. | |||
| TERMINATE_OR_BUFFER 0 | TERMINATE_OR_BUFFER 0 | |||
| When the Direct-Debiting-Failure-Handling AVP is set to | When the Direct-Debiting-Failure-Handling AVP is set to | |||
| TERMINATE_OR_BUFFER the service MUST be granted as long as there | TERMINATE_OR_BUFFER the service MUST be granted as long as there | |||
| is a connection to the credit-control server. If the credit- | is a connection to the credit-control server. If the credit- | |||
| control client does not receive any Credit-Control-Answer message | control client does not receive any Credit-Control-Answer | |||
| within the Tx timer (as defined in section 13) the credit-control | message within the Tx timer (as defined in section 13) the | |||
| request is regarded failed. The client SHOULD terminate the | credit-control request is regarded failed. The client SHOULD | |||
| service if it can determine from the failed answer that units | terminate the service if it can determine from the failed answer | |||
| have not been debited. Otherwise the credit-control client SHOULD | that units have not been debited. Otherwise the credit-control | |||
| grant the service, store the request to application level non- | client SHOULD grant the service, store the request to | |||
| application level non-volatile storage and try to re-send the | ||||
| Diameter Credit Control Application May 14, 2004 | request. These requests MUST be marked as possible duplicate by | |||
| setting the T-flag in the command header as described in | ||||
| volatile storage and try to re-send the request. These requests | [DIAMBASE] section 3. | |||
| MUST be marked as possible duplicate by setting the T-flag in the | ||||
| command header as described in [DIAMBASE] section 3. | ||||
| This is the default behavior if the AVP isn't included in the | This is the default behavior if the AVP isn't included in the | |||
| reply from the authorization server. | reply from the authorization server. | |||
| CONTINUE 1 | CONTINUE 1 | |||
| When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE | When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE | |||
| the service SHOULD be granted even if credit-control messages | the service SHOULD be granted even if credit-control messages | |||
| can't be delivered and the request should be deleted. | 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 XXX - IANA please fill | Multiple-Services-Credit-Control AVP (AVP Code XXX - IANA please | |||
| in and remove this note - suggested value 456) is of type Grouped and | fill in and remove this note - suggested value 456) is of type | |||
| contains the AVPs related to the independent credit control of | Grouped and contains the AVPs related to the independent credit | |||
| multiple services feature. Note that each instance of this AVP | control of multiple services feature. Note that each instance of | |||
| carries units related to one or more services or related to a single | this AVP carries units related to one or more services or related to | |||
| rating-group. | a single rating-group. | |||
| The Service-Identifier and the Rating-Group AVPs are used to | The Service-Identifier and the Rating-Group AVPs are used to | |||
| associate the granted units to a given service or rating group. | associate the granted units to a given service or rating group. | |||
| In case both the Service-Identifier and the Rating-Group AVPs are | In case both the Service-Identifier and the Rating-Group AVPs are | |||
| included, the target of the service units is always the service(s) | included, the target of the service units is always the service(s) | |||
| indicated by the value of the Service-Identifier AVP(s). If only the | indicated by the value of the Service-Identifier AVP(s). If only the | |||
| Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control | Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control | |||
| AVP relates to all the services that belong to the specified rating | AVP relates to all the services that belong to the specified rating | |||
| group. | 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 G-S-U- | |||
| Pool-Identifier identifying a credit pool within which the units of | Pool-Identifier identifying a credit pool within which the units of | |||
| the specified type are considered to be pooled. If a G-S-U-Pool- | the specified type are considered to be pooled. If a G-S-U-Pool- | |||
| Reference AVP is present then actual service units of the specified | Reference AVP is present then actual service units of the specified | |||
| type MUST also be present. For example, if the G-S-U-Pool-Reference | type MUST also be present. For example, if the G-S-U-Pool-Reference | |||
| AVP specifies Unit-Type TIME, then the CC-Time AVP MUST be present. | AVP specifies Unit-Type TIME, 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 | |||
| where new quota is requested. If the credit-control client does not | where new quota is requested. If the credit-control client does not | |||
| include the Requested-Service-Unit AVP in a request command, for | include the Requested-Service-Unit AVP in a request command, for | |||
| instance because it has determined that the end-user terminated the | instance because it has determined that the end-user terminated the | |||
| service, the server MUST debit the used amount from the user's | 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 AVPs MAY be | The Validity-Time, Result-Code and Final-Unit-Indication AVPs MAY be | |||
| present in an answer command as defined in section 5.1.1 and 5.6 for | present in an answer command as defined in section 5.1.2 and 5.6 for | |||
| the graceful service termination. | the graceful service termination. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are | When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are | |||
| present, the server MUST include two separate instances of the | 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 as defined in section 5.1.1 | pools, the credit pooling mechanism as defined in section 5.1.2 | |||
| applies. The Tariff-Change-Usage AVP MUST NOT be included in request | applies. The Tariff-Change-Usage AVP MUST NOT be included in request | |||
| commands, to report used units before and after tariff time change | commands, to report used units before and after tariff time change | |||
| the Used-Service-Unit AVP MUST be used. | the Used-Service-Unit AVP MUST be used. | |||
| 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 functionality MUST treat the Multiple-Services-Credit- | |||
| Control AVP as invalid AVP. | Control AVP as invalid AVP. | |||
| The Multiple-Services-Control AVP has the following ABNF grammar: | The Multiple-Services-Control AVP has the following ABNF grammar: | |||
| Multiple-Services-Credit-Control ::= < AVP Header: TBD > | Multiple-Services-Credit-Control ::= < AVP Header: TBD > | |||
| skipping to change at page 63, line 35 ¶ | skipping to change at page 64, line 48 ¶ | |||
| *[ 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 ] | |||
| *[ AVP ] | *[ AVP ] | |||
| 8.17 Granted-Service-Unit AVP | 8.17 Granted-Service-Unit AVP | |||
| Granted-Service-Unit AVP (AVP Code XXX - IANA please fill in and | Granted-Service-Unit AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 431) is of type Grouped and | remove this note - suggested value 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 | |||
| new Credit-Control-Request must be sent. A client is not required to | the new Credit-Control-Request must be sent. A client is not | |||
| implement all of the unit types, and must treat unknown or | required to implement all of the unit types, and must treat unknown | |||
| unsupported unit types in the answer message as an incorrect CCA | or unsupported unit types in the answer message as an incorrect CCA | |||
| answer. In that case the client MUST terminate the credit control | answer. In that case the client MUST terminate the credit control | |||
| session and indicate in the Termination-Cause AVP reason | session and indicate in the Termination-Cause AVP reason | |||
| DIAMETER_BAD_ANSWER. | DIAMETER_BAD_ANSWER. | |||
| The Granted-Service-Unit AVP has the following ABNF grammar: | The Granted-Service-Unit AVP has the following ABNF grammar: | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Granted-Service-Unit ::= < AVP Header: TBD > | Granted-Service-Unit ::= < AVP Header: TBD > | |||
| [ 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 XXX - IANA please fill in | The Requested-Service-Unit AVP (AVP Code XXX - IANA please fill in | |||
| and remove this note - suggested value 437) is of type Grouped and | and remove this note - suggested value 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 of | credit-control client. A server is not required to implement all of | |||
| the unit types, and must treat unknown or unsupported unit types as | the unit types, and must treat unknown or unsupported unit types as | |||
| invalid AVPs. | invalid AVPs. | |||
| The Requested-Service-Unit AVP has the following ABNF grammar: | The Requested-Service-Unit AVP has the following ABNF grammar: | |||
| Requested-Service-Unit ::= < AVP Header: TBD > | Requested-Service-Unit ::= < AVP Header: TBD > | |||
| [ 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 (AVP Code XXX - IANA | The Used-Service-Unit AVP is of type Grouped AVP (AVP Code XXX - | |||
| please fill in and remove this note - suggested value 446) and | IANA please fill in and remove this note - suggested value 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, in case of interim interrogations are used | service became active or, in case of interim interrogations are used | |||
| during the session, from the point when the previous measurement | during the session, from the point when the previous measurement | |||
| ended. | ended. | |||
| The Used-Service-Unit AVP has the following ABNF grammar: | The Used-Service-Unit AVP has the following ABNF grammar: | |||
| Used-Service-Unit ::= < AVP Header: TBD > | Used-Service-Unit ::= < AVP Header: TBD > | |||
| [ 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 ] | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| *[ AVP ] | *[ AVP ] | |||
| 8.20 Tariff-Time-Change AVP | 8.20 Tariff-Time-Change AVP | |||
| The Tariff-Time-Change AVP (AVP Code XXX - IANA please fill in and | The Tariff-Time-Change AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 451) is of type Time, it is sent | remove this note - suggested value 451) is of type Time, it is sent | |||
| from the server to the client and includes the time in seconds since | 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 be | January 1, 1900 00:00 UTC when the tariff of the service will be | |||
| changed. | changed. | |||
| The tariff change mechanism is optional for client and server and it | The tariff change mechanism is optional for client and server and it | |||
| is not used for time-based services as defined in the section 5. | is not used for time-based services as defined in the section 5. | |||
| If a client does not support the tariff time change mechanism it MUST | If a client does not support the tariff time change mechanism it | |||
| treat Tariff-Time-Change AVP in the answer message as an incorrect | MUST treat Tariff-Time-Change AVP in the answer message as an | |||
| incorrect | ||||
| CCA answer. In that case the client terminates the credit control | CCA answer. In that case the client terminates the credit control | |||
| session and indicate in the Termination-Cause AVP reason | session and indicate in the Termination-Cause AVP reason | |||
| DIAMETER_BAD_ANSWER. | DIAMETER_BAD_ANSWER. | |||
| 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 XXX - IANA please fill in and remove this | The CC-Time AVP (AVP Code XXX - IANA please fill in and remove this | |||
| note - suggested value 420) is of type Unsigned32, and indicates the | note - suggested value 420) is of type Unsigned32, and indicates the | |||
| length of the requested, granted or used time in seconds. | 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 XXX - IANA please fill in and remove this | The CC-Money AVP (AVP Code XXX - IANA please fill in and remove this | |||
| note - suggested value 413) is of type Grouped, and specifies the | note - suggested value 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 has the following ABNF grammar: | be included. It has the following ABNF grammar: | |||
| CC-Money ::= < AVP Header: TBD > | CC-Money ::= < AVP Header: TBD > | |||
| { 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 XXX - IANA please fill in and | The CC-Total-Octets AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 421) is of type Unsigned64, and | remove this note - suggested value 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 XXX - IANA please fill in and | The CC-Input-Octets AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 412) is of type Unsigned64, and | remove this note - suggested value 412) is of type Unsigned64, and | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| contains the number of requested, granted or used octets that can | contains the number of requested, granted or used octets that can | |||
| be/have been received from the end user. | 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 XXX - IANA please fill in and | The CC-Output-Octets AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 414) is of type Unsigned64, and | remove this note - suggested value 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 can | |||
| be/have been sent to the end user. | 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 XXX - IANA please fill in | The CC-Service-Specific-Units AVP (AVP Code XXX - IANA please fill | |||
| and remove this note - suggested value 417) is of type Unsigned64, | in and remove this note - suggested value 417) is of type | |||
| and specifies the number of service specific units (e.g. number of | Unsigned64, and specifies the number of service specific units (e.g. | |||
| events, points) given in a selected service. The service specific | number of events, points) given in a selected service. The service | |||
| units always refer to the service identified in the Service- | specific units always refer to the service identified in the | |||
| Identifier AVP (or Rating-Group AVP when the Multiple-Services- | Service-Identifier AVP (or Rating-Group AVP when the Multiple- | |||
| Credit-Control AVP is used). | Services-Credit-Control AVP is used). | |||
| 8.27 Tariff-Change-Usage AVP | 8.27 Tariff-Change-Usage AVP | |||
| The Tariff-Change-Usage AVP (AVP Code XXX - IANA please fill in and | The Tariff-Change-Usage AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 452) is of type Enumerated and | remove this note - suggested value 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 | |||
| the units straddled tariff change when a tariff change has occurred | the units straddled tariff change when a tariff change has occurred | |||
| during the reporting period. | during the reporting period. | |||
| Omission of this AVP means that no tariff change has occurred. | Omission of this AVP means that no tariff change has occurred. | |||
| In addition, when present in answer messages as part of the Multiple- | In addition, when present in answer messages as part of the | |||
| Services-Credit-Control AVP, this AVP defines whether units are | Multiple-Services-Credit-Control AVP, this AVP defines whether units | |||
| allocated to be used before or after a tariff change event. | are allocated to be used before or after a tariff change event. | |||
| Omission of this AVP in answer messages when the Tariff-Time-Change | Omission of this AVP in answer messages when the Tariff-Time-Change | |||
| AVP is present means that the single quota mechanism applies. | AVP is present means that the single quota mechanism applies. | |||
| Tariff-Change-Usage can be one of the following: | Tariff-Change-Usage can be one of the following: | |||
| UNIT_BEFORE_TARIFF_CHANGE 0 | UNIT_BEFORE_TARIFF_CHANGE 0 | |||
| When present in the Multiple-Services-Credit-Control AVP, this | When present in the Multiple-Services-Credit-Control AVP, this | |||
| value indicates the amount of the units allocated for use before a | value indicates the amount of the units allocated for use before | |||
| tariff change occurs. | a tariff change occurs. | |||
| When present in the Used-Service-Unit AVP, this value indicates | When present in the Used-Service-Unit AVP, this value indicates | |||
| the amount of resource units used before a tariff change had | the amount of resource units used before a tariff change had | |||
| occurred. | occurred. | |||
| UNIT_AFTER_TARIFF_CHANGE 1 | UNIT_AFTER_TARIFF_CHANGE 1 | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| When present in the Multiple-Services-Credit-Control AVP, this | When present in the Multiple-Services-Credit-Control AVP, this | |||
| value indicates the amount of the units allocated for use after a | value indicates the amount of the units allocated for use after a | |||
| tariff change occurs. | tariff change occurs. | |||
| When present in the Used-Service-Unit AVP, this value indicates | When present in the Used-Service-Unit AVP, this value indicates | |||
| the amount of resource units used after tariff change had | the amount of resource units used after tariff change had | |||
| occurred. | occurred. | |||
| UNIT_INDETERMINATE 2 | UNIT_INDETERMINATE 2 | |||
| The used unit contains the amount of units that straddle the | The used unit contains the amount of units that straddle the | |||
| tariff change (e.g. the metering process reports to the credit- | tariff change (e.g. the metering process reports to the credit- | |||
| control client in blocks of n octets and one block straddled the | control client in blocks of n octets and one block straddled the | |||
| tariff change). This value is to be used only in the Used-Service- | tariff change). This value is to be used only in the Used- | |||
| Unit AVP. | Service-Unit AVP. | |||
| 8.28 Service-Identifier AVP | ||||
| The Service-Identifier AVP is of type UTF8String (AVP Code XXX - IANA | ||||
| please fill in and remove this note - suggested value 439) and | ||||
| contains a unique identifier of a service. This is an identifier | ||||
| allocated by the service provider, by the service element | ||||
| manufacturer or by a standardization body and MUST uniquely identify | ||||
| a given service. The format of the service identifier is: | ||||
| "service-identifier" "@" "domain" | ||||
| service-identifier = Token | ||||
| The Token is an arbitrary string of characters | ||||
| and digits. | ||||
| domain = represents the entity that allocated the service-identifier. | ||||
| 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 (e.g. provider.example.com) or of | ||||
| the vendor (e.g. vendor.example.com) if the identifier is | ||||
| allocated by a private entity. | ||||
| Services that are for private use only, i.e. to one provider's own | 8.28 Service-Identifier AVP | |||
| use, where no interoperability is deemed useful may define private | ||||
| identifiers without need of coordination. However, when | ||||
| interoperability is wanted, coordination of the identifiers via e.g. | ||||
| publication of informational RFC is RECOMMENDED to make Service- | ||||
| Identifier globally available. | ||||
| A usage example of this AVP for multiple services in one user session | The Service-Identifier AVP is of type Unsigned32 (AVP Code XXX - | |||
| is illustrated in Appendix A (Flow IX). | IANA please fill in and remove this note - suggested value 439) and | |||
| contains the identifier of a service. The specific service that the | ||||
| request relates to is uniquely identified by the combination of | ||||
| Service-Context-Id and Service-Identifier AVPs. | ||||
| 8.29 Rating-Group AVP | A usage example of this AVP is illustrated in Appendix A (Flow IX). | |||
| Diameter Credit Control Application May 14, 2004 | 8.29 Rating-Group AVP | |||
| The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA | The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA | |||
| please fill in and remove this note - suggested value 432) and | please fill in and remove this note - suggested value 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. This is an | to the same rating type are part of the same rating group. The | |||
| identifier allocated by the home service provider and MUST be unique | specific rating group that the request relates to is uniquely | |||
| within the home service provider domain. | identified by the combination of Service-Context-Id and Rating-Group | |||
| AVPs. | ||||
| A usage example of this AVP is illustrated in Appendix A (Flow IX). | A usage example of this AVP is illustrated in Appendix A (Flow IX). | |||
| 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 XXX - IANA please fill in and | The G-S-U-Pool-Reference AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 457) is of type Grouped, it is | remove this note - suggested value 457) is of type Grouped, it is | |||
| used in the Credit-Control-Answer message and associates the Granted- | used in the Credit-Control-Answer message and associates the | |||
| Service-Units AVP within which it appears with a credit pool within | Granted-Service-Units AVP within which it appears with a credit pool | |||
| 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 hence to service units of any other service or | the credit pool (and hence to service units of any other service or | |||
| rating group associated with the same pool). | rating group associated with the same pool). | |||
| The G-S-U-Pool-Reference AVP has the following ABNF grammar: | The G-S-U-Pool-Reference AVP has the following ABNF grammar: | |||
| G-S-U-Pool-Reference ::= < AVP Header: TBD > | G-S-U-Pool-Reference ::= < AVP Header: TBD > | |||
| { 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 XXX - IANA please fill in and | The G-S-U-Pool-Identifier AVP (AVP Code XXX - IANA please fill in | |||
| remove this note - suggested value 453) is of type Unsigned32 and | and remove this note - suggested value 453) is of type Unsigned32 | |||
| 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 XXX - IANA please fill in and remove | The CC-Unit-Type AVP (AVP Code XXX - IANA please fill in and remove | |||
| this note - suggested value 454) is of type Enumerated and specifies | this note - suggested value 454) is of type Enumerated and specifies | |||
| the type of units which are considered to be pooled into a credit | the type of units which are considered to be pooled into a credit | |||
| pool. | pool. | |||
| The following values are defined for the CC-Unit-Type AVP: | The following values are defined for the CC-Unit-Type AVP: | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 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 XXX - IANA | The Validity-Time AVP is of type Unsigned32 (AVP Code XXX - IANA | |||
| please fill in and remove this note - suggested value 448) and it is | please fill in and remove this note - suggested value 448) and it is | |||
| sent from the credit-control server to the credit-control client. The | sent from the credit-control server to the credit-control client. | |||
| AVP contains the validity time of the granted service units. The | The AVP contains the validity time of the granted service units. The | |||
| measurement of the Validity-Time is started at reception of the | measurement of the Validity-Time is started at reception of the | |||
| Credit-Control-Answer Message containing this AVP. If the granted | Credit-Control-Answer Message containing this AVP. If the granted | |||
| service units have not been consumed within the validity time | service units have not been consumed within the validity time | |||
| specified in this AVP, the credit-control client MUST send a Credit- | specified in this AVP, the credit-control client MUST send a Credit- | |||
| Control-Request message to the server with CC-Request-Type set to | Control-Request message to the server with CC-Request-Type set to | |||
| UPDATE_REQUEST. The value field of the Validity-Time AVP is given in | UPDATE_REQUEST. The value field of the Validity-Time AVP is given in | |||
| seconds. | seconds. | |||
| The Validity-Time AVP is also used for the graceful service | The Validity-Time AVP is also used for the graceful service | |||
| termination (see section 5.6) to indicate to the credit control | termination (see section 5.6) to indicate to the credit control | |||
| client how long the subscriber is allowed to use network resources | client how long the subscriber is allowed to use network resources | |||
| after the specified action (i.e. REDIRECT or RESTRICT_ACCESS) | after the specified action (i.e. REDIRECT or RESTRICT_ACCESS) | |||
| started. Upon the Validity-Time elapses a new intermediate | started. Upon the Validity-Time elapses a new intermediate | |||
| interrogation is sent to the server. | interrogation is sent to the server. | |||
| 8.34 Final-Unit-Indication AVP | 8.34 Final-Unit-Indication AVP | |||
| The Final-Unit-Indication AVP (AVP Code XXX - IANA please fill in and | The Final-Unit-Indication AVP (AVP Code XXX - IANA please fill in | |||
| remove this note - suggested value 430) is of type Grouped and | and remove this note - suggested value 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. After these units have expired, the Diameter credit-control | service. After these units have expired, the Diameter credit-control | |||
| client is responsible for executing the action indicated in the | client is responsible for executing the action indicated in the | |||
| Final-Unit-Action AVP (see section 5.6). | Final-Unit-Action AVP (see section 5.6). | |||
| If more than one unit types are received in the Credit-Control- | If more than one unit types are received in the Credit-Control- | |||
| Answer, the Unit type which first expired SHOULD cause the credit- | Answer, the Unit type which first expired SHOULD cause the credit- | |||
| control client to execute the specified action. | control 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 REDIRECT or RESTRICT_ACCESS can also be present | |||
| Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA | with no Granted-Service-Unit AVP in the Credit-Control-Answer or in | |||
| answer. This indicates to the Diameter credit-control client to | the AA answer. This indicates to the Diameter credit-control client | |||
| immediately execute the specified action. If the home service | to immediately execute the specified action. If the home service | |||
| provider policy is to terminate the service, naturally, the server | provider policy is to terminate the service, naturally, the server | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| SHOULD return the appropriate transient failure (see section 9.1) in | SHOULD return the appropriate transient failure (see section 9.1) in | |||
| order to implement the policy-defined action. | 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 | |||
| when the user's account cannot cover the cost of the service and MUST | element when the user's account cannot cover the cost of the service | |||
| always be present if the Final-Unit-Indication AVP is included in a | and MUST always be present if the Final-Unit-Indication AVP is | |||
| command. | included in a command. | |||
| If the Final-Unit-Action AVP is set to TERMINATE no other AVPs MUST | If the Final-Unit-Action AVP is set to TERMINATE no other AVPs MUST | |||
| be present. | be present. | |||
| If the Final-Unit-Action AVP is set to REDIRECT at least the | If the Final-Unit-Action AVP is set to REDIRECT at least the | |||
| Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP | Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP | |||
| or the Filter-Id AVP MAY be present in the Credit-Control-Answer | or the Filter-Id AVP MAY be present in the Credit-Control-Answer | |||
| message if the user is allowed to access also other services not | message if the user is allowed to access also other services not | |||
| accessible through the address given in the Redirect-Server AVP. | accessible through the 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 [NASREQ]. The Filter-Id AVP can be | The Filter-Id AVP is defined in [NASREQ]. 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 | |||
| other means than the Diameter Credit Control Application e.g. locally | by other means than the Diameter Credit Control Application e.g. | |||
| configured or configured by another entity. | locally configured or configured by another entity. | |||
| The Final-Unit-Indication AVP has the following ABNF grammar: | The Final-Unit-Indication AVP has the following ABNF grammar: | |||
| Final-Unit-Indication ::= < AVP Header: TBD > | Final-Unit-Indication ::= < AVP Header: TBD > | |||
| { 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 XXX - IANA please fill in and | The Final-Unit-Action AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 449) is of type Enumerated and | remove this note - suggested value 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: | The Final-Unit-Action can be one of the following: | |||
| TERMINATE 0 | TERMINATE 0 | |||
| The credit control client MUST terminate the service session. This | The credit control client MUST terminate the service session. | |||
| is the default handling applicable whenever the credit control | This is the default handling applicable whenever the credit | |||
| client receives an unsupported Final-Unit-Action value and MUST be | control client receives an unsupported Final-Unit-Action value | |||
| supported by all the Diameter credit control client | and MUST be supported by all the Diameter credit control client | |||
| implementations conforming to this specification. | implementations conforming to this specification. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| REDIRECT 1 | REDIRECT 1 | |||
| The service element MUST redirect the user to the address | The service element MUST redirect the user to the address | |||
| specified in the Redirect-Server-Address AVP. The redirect action | specified in the Redirect-Server-Address AVP. The redirect action | |||
| is defined in section 5.6.2. | is defined in section 5.6.2. | |||
| RESTRICT_ACCESS 2 | RESTRICT_ACCESS 2 | |||
| The access device MUST restrict the user access according to the | The access device MUST restrict the user access according to the | |||
| IP packet filters defined in the Restriction-Filter-Rule AVP or | IP packet filters defined in the Restriction-Filter-Rule AVP or | |||
| according to the IP packet filters identified by the Filter-Id | according to the IP packet filters identified by the Filter-Id | |||
| AVP. All the packets not matching the filters MUST be dropped (see | AVP. All the packets not matching the filters MUST be dropped | |||
| section 5.6.3). | (see section 5.6.3). | |||
| 8.36 Restriction-Filter-Rule AVP | 8.36 Restriction-Filter-Rule AVP | |||
| The Restriction-Filter-Rule AVP (AVP Code XXX - IANA please fill in | The Restriction-Filter-Rule AVP (AVP Code XXX - IANA please fill in | |||
| and remove this note - suggested value 438) is of type IPFilterRule | and remove this note - suggested value 438) is of type IPFilterRule | |||
| and provides filter rules corresponding to services which are to | and provides filter rules corresponding to services which are to | |||
| remain accessible despite there being no more service units granted. | remain accessible despite there being no more service units granted. | |||
| The access device need to configure the specified filter rules for | The access device need to configure the specified filter rules for | |||
| the subscriber and MUST drop all the packets not matching these | the subscriber and MUST drop all the packets not matching these | |||
| filters. Zero, one or more such AVPs MAY be present in a Credit- | filters. Zero, one or more such AVPs MAY be present in a Credit- | |||
| Control-Answer message or in an AA answer message. | 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 XXX - IANA please fill in and | The Redirect-Server AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 434) is of type Grouped and | remove this note - suggested value 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) where the end user is to be connected | redirect server, SIP Server) where the end user is to be connected | |||
| when the account cannot cover the service cost. It MUST be present | when the account cannot cover the service cost. It MUST be present | |||
| when the Final-Unit-Action AVP is set to REDIRECT. | when the Final-Unit-Action AVP is set to REDIRECT. | |||
| It has the following ABNF grammar: | It has the following ABNF grammar: | |||
| Redirect-Server ::= < AVP Header: TBD > | Redirect-Server ::= < AVP Header: TBD > | |||
| { 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 XXX - IANA please fill in and | The Redirect-Address-Type AVP (AVP Code XXX - IANA please fill in | |||
| remove this note - suggested value 433) is of type Enumerated and | and remove this note - suggested value 433) is of type Enumerated | |||
| defines the address type of the address given in the Redirect-Server- | and defines the address type of the address given in the Redirect- | |||
| Address AVP. | Server-Address AVP. | |||
| The address type can be one of the following: | The address type can be one of the following: | |||
| IPv4 Address 0 | IPv4 Address 0 | |||
| The address type is in form of "dotted-decimal" IPv4 address, | The address type is in form of "dotted-decimal" IPv4 address, | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| as defined in [IPv4]. | as defined in [IPv4]. | |||
| IPv6 Address 1 | IPv6 Address 1 | |||
| The address type is in form of IPv6 address, as defined in | The address type is in form of IPv6 address, as defined in | |||
| [IPv6Addr]. The address is a text representation of the address | [IPv6Addr]. The address is a text representation of the address | |||
| in either the preferred or alternate text form [IPv6Addr]. | in either the preferred or alternate text form [IPv6Addr]. | |||
| Conformant implementations MUST support the preferred form and | Conformant implementations MUST support the preferred form and | |||
| SHOULD support the alternate text form for IPv6 addresses. | SHOULD support the alternate text form for IPv6 addresses. | |||
| URL 2 | URL 2 | |||
| The address type is in form of Uniform Resource Locator, as | The address type is in form of Uniform Resource Locator, as | |||
| defined in [URL]. | defined in [URL]. | |||
| SIP URI 3 | SIP URI 3 | |||
| The address type is in form of SIP Uniform Resource Indicator, as | The address type is in form of SIP Uniform Resource Identifier, | |||
| defined in [SIP]. | as defined in [SIP]. | |||
| 8.39 Redirect-Server-Address AVP | 8.39 Redirect-Server-Address AVP | |||
| The Redirect-Server-Address AVP (AVP Code XXX - IANA please fill in | The Redirect-Server-Address AVP (AVP Code XXX - IANA please fill in | |||
| and remove this note - suggested value 435) is of type UTF8String and | and remove this note - suggested value 435) is of type UTF8String | |||
| 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) where the end user is to be connected when the | server, SIP Server) where the end user is to be connected when the | |||
| account cannot cover the service cost. | 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 XXX - IANA please fill | The Multiple-Services-Indicator AVP (AVP Code XXX - IANA please fill | |||
| in and remove this note - suggested value 455) is of type Enumerated | in and remove this note - suggested value 455) is of type Enumerated | |||
| and indicates whether the Diameter Credit-control client is capable | and indicates whether the Diameter Credit-control client is capable | |||
| of handling multiple services independently within a (sub-) session. | of handling multiple services independently within a (sub-) session. | |||
| The absence of this AVP means that independent credit control of | The absence of this AVP means that independent credit control of | |||
| multiple services is not supported. | 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 invalid | services MUST treat the Multiple-Services-Indicator AVP as invalid | |||
| skipping to change at page 73, line 5 ¶ | skipping to change at page 73, line 48 ¶ | |||
| AVP: | AVP: | |||
| MULTIPLE_SERVICES_NOT_SUPPORTED 0 | MULTIPLE_SERVICES_NOT_SUPPORTED 0 | |||
| Client does not support independent credit control of multiple | 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 | Client supports independent credit control of multiple services | |||
| within a (sub-)session. | within a (sub-)session. | |||
| Diameter Credit Control Application May 14, 2004 | 8.41 Requested-Action AVP | |||
| 8.41 Requested-Action AVP | ||||
| The Requested-Action AVP (AVP Code XXX - IANA please fill in and | The Requested-Action AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 436) is type of Enumerated and | remove this note - suggested value 436) is type of Enumerated and | |||
| contains the requested action being sent by Credit-Control-Request | contains the requested action being sent by 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 | |||
| Direct debiting indicates that the request is to decrease the end | Direct debiting indicates that the request is to decrease the end | |||
| user's account according to information specified in the | user's account according to information specified in the | |||
| Requested-Service-Unit AVP and/or Service-Identifier AVP | Requested-Service-Unit AVP and/or Service-Identifier AVP | |||
| (additional rating information may be included in service specific | (additional rating information may be included in service | |||
| AVPs or in the Service-Parameter-Info AVP). The Granted-Service | specific AVPs or in the Service-Parameter-Info AVP). The Granted- | |||
| Unit AVP in the Credit-Control-Answer command contains the debited | Service Unit AVP in the Credit-Control-Answer command contains | |||
| units. | the debited units. | |||
| REFUND_ACCOUNT 1 | REFUND_ACCOUNT 1 | |||
| Refund account indicates that the request is to increase the end | Refund account indicates that the request is to increase the end | |||
| user's account according to information specified in the | user's account according to information specified in the | |||
| Requested-Service-Unit AVP and/or Service-Identifier AVP | Requested-Service-Unit AVP and/or Service-Identifier AVP | |||
| (additional rating information may be included in service specific | (additional rating information may be included in service | |||
| AVPs or in the Service-Parameter-Info AVP). The Granted-Service | specific AVPs or in the Service-Parameter-Info AVP). The Granted- | |||
| Unit AVP in the Credit-Control-Answer command contains the | Service Unit AVP in the Credit-Control-Answer command contains | |||
| refunded units. | the refunded units. | |||
| CHECK_BALANCE 2 | CHECK_BALANCE 2 | |||
| Check balance indicates that the request is a balance check | Check balance indicates that the request is a balance check | |||
| request. In this case the checking of the account balance is done | request. In this case the checking of the account balance is done | |||
| without any credit reservation from the account. The Check- | without any credit reservation from the account. The Check- | |||
| Balance-Result AVP in the Credit-Control-Answer command contains | Balance-Result AVP in the Credit-Control-Answer command contains | |||
| the result of the Balance Check. | the result of the Balance Check. | |||
| PRICE_ENQUIRY 3 | PRICE_ENQUIRY 3 | |||
| Price Enquiry indicates that the request is a price enquiry | Price Enquiry indicates that the request is a price enquiry | |||
| request. In this case neither checking of the account balance nor | request. In this case neither checking of the account balance nor | |||
| reservation from the account will be done, only the price of the | reservation from the account will be done, only the price of the | |||
| service will be returned in the Cost-Information AVP in the | service will be returned in the Cost-Information AVP in the | |||
| Credit-Control-Answer Command. | Credit-Control-Answer Command. | |||
| 8.42 Service-Parameter-Info AVP | 8.42 Service-Context-Id AVP | |||
| The Service-Parameter-Info AVP (AVP Code XXX - IANA please fill in | The Service-Context-Id AVP is of type UTF8String (AVP Code XXX - | |||
| and remove this note - suggested value 440) is of type Grouped and | IANA please fill in and remove this note - suggested value 458) and | |||
| contains a service specific information used for price calculation or | contains a unique identifier of the Diameter Credit Control service | |||
| rating. The Service-Parameter-Type AVP defines the service parameter | specific document that applies to the request (as defined in section | |||
| type and the Service-Parameter-Value AVP contains the parameter | 4.1.2). This is an identifier allocated by the service provider, by | |||
| value. The actual contents of these AVPs are not within the scope of | the service element manufacturer or by a standardization body and | |||
| MUST uniquely identify a given Diameter Credit Control service | ||||
| specific document. The format of the Service-Context-Id is: | ||||
| Diameter Credit Control Application May 14, 2004 | "service-context" "@" "domain" | |||
| this document and SHOULD be defined in another Diameter application, | service-context = Token | |||
| standards written by other standardization bodies, or service | The Token is an arbitrary string of characters and digits. | |||
| specific documentation. | ||||
| domain = represents the entity that allocated the Service-Context- | ||||
| Id. 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 (e.g. provider.example.com) or of the vendor (e.g. | ||||
| vendor.example.com) if the identifier is allocated by a private | ||||
| entity. | ||||
| This AVP SHOULD be placed as closed to the Diameter header as | ||||
| possible. | ||||
| Service specific documents that are for private use only, i.e. to | ||||
| one provider's own use, where no interoperability is deemed useful | ||||
| may define private identifiers without need of coordination. | ||||
| However, when interoperability is wanted, coordination of the | ||||
| identifiers via e.g. publication of informational RFC is RECOMMENDED | ||||
| to make Service-Context-Id globally available. | ||||
| 8.43 Service-Parameter-Info AVP | ||||
| The Service-Parameter-Info AVP (AVP Code XXX - IANA please fill in | ||||
| and remove this note - suggested value 440) is of type Grouped and | ||||
| contains a service specific information used for price calculation | ||||
| or rating. The Service-Parameter-Type AVP defines the service | ||||
| parameter type and the Service-Parameter-Value AVP contains the | ||||
| parameter value. The actual contents of these AVPs are not within | ||||
| the scope of this document and SHOULD be defined in another Diameter | ||||
| application, standards written by other standardization bodies, or | ||||
| service specific documentation. | ||||
| In case of unknown service request (e.g. unknown Service-Parameter- | In case of unknown service request (e.g. unknown Service-Parameter- | |||
| Type), the corresponding answer message MUST contain error code | Type), the corresponding answer message MUST contain error code | |||
| DIAMETER_RATING_FAILED. A Credit Control Answer message with this | DIAMETER_RATING_FAILED. A Credit Control Answer message with this | |||
| error MUST contain one or more Failed-AVP AVPs containing the | error MUST contain one or more Failed-AVP AVPs containing the | |||
| Service-Parameter-Info AVPs that caused the failure. | Service-Parameter-Info AVPs that caused the failure. | |||
| It has the following ABNF grammar: | It has the following ABNF grammar: | |||
| Service-Parameter-Info ::= < AVP Header: TBD > | Service-Parameter-Info ::= < AVP Header: TBD > | |||
| [ Service-Parameter-Type ] | { Service-Parameter-Type } | |||
| [ Service-Parameter-Value ] | { Service-Parameter-Value } | |||
| 8.43 Service-Parameter-Type AVP | 8.44 Service-Parameter-Type AVP | |||
| The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code XXX - | The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code XXX - | |||
| IANA please fill in and remove this note - suggested value 441) and | IANA please fill in and remove this note - suggested value 441) and | |||
| defines the type of the service event specific parameter (e.g. it can | defines the type of the service event specific parameter (e.g. it | |||
| be end-user location, service name). The different parameters and | can be end-user location, service name). The different parameters | |||
| their types are service specific and the meanings of these parameters | and their types are service specific and the meanings of these | |||
| are not defined in this document. The one who allocates the Service- | parameters are not defined in this document. The one who allocates | |||
| Identifier, i.e. unique identifier of a service, is also responsible | the Service-Context-Id, i.e. unique identifier of a service specific | |||
| for assigning Service-Parameter-Type values for the service and | document, is also responsible for assigning Service-Parameter-Type | |||
| ensuring their uniqueness within the given service. The Service- | values for the service and ensuring their uniqueness within the | |||
| Parameter-Value AVP contains the value associated with the service | given service. The Service-Parameter-Value AVP contains the value | |||
| parameter type. | associated with the service parameter type. | |||
| 8.44 Service-Parameter-Value AVP | 8.45 Service-Parameter-Value AVP | |||
| The Service-Parameter-Value AVP is of type OctetString (AVP Code XXX | The Service-Parameter-Value AVP is of type OctetString (AVP Code XXX | |||
| - IANA please fill in and remove this note - suggested value 442) and | - IANA please fill in and remove this note - suggested value 442) | |||
| contains the value of the service parameter type. | and contains the value of the service parameter type. | |||
| 8.45 Subscription-Id AVP | 8.46 Subscription-Id AVP | |||
| The Subscription-Id AVP (AVP Code XXX - IANA please fill in and | The Subscription-Id AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 443) is used to identify the end | remove this note - suggested value 443) is used to identify the end | |||
| user's subscription and is of type Grouped. The Subscription-Id AVP | user's subscription and is of type Grouped. The Subscription-Id AVP | |||
| includes a Subscription-Id-Data AVP that hold the identifier and a | includes a Subscription-Id-Data AVP that hold the identifier and a | |||
| Subscription-Id-Type AVP that defines the identifier type. | Subscription-Id-Type AVP that defines the identifier type. | |||
| It has the following ABNF grammar: | It has the following ABNF grammar: | |||
| Subscription-Id ::= < AVP Header: TBD > | Subscription-Id ::= < AVP Header: TBD > | |||
| { Subscription-Id-Type } | { Subscription-Id-Type } | |||
| { Subscription-Id-Data } | { Subscription-Id-Data } | |||
| Diameter Credit Control Application May 14, 2004 | 8.47 Subscription-Id-Type AVP | |||
| 8.46 Subscription-Id-Type AVP | ||||
| The Subscription-Id-Type AVP (AVP Code XXX - IANA please fill in and | The Subscription-Id-Type AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 450) is of type Enumerated and it | remove this note - suggested value 450) is of type Enumerated and it | |||
| is used to determine which type of identifier that is carried by the | is used to determine which type of identifier that is carried by the | |||
| Subscription-Id AVP. A server is not required to implement all of the | Subscription-Id AVP. | |||
| Subscription-Id-Types, and MUST treat unknown or unsupported | ||||
| Subscription-Id-Types as invalid AVP values. | ||||
| The identifier can be one of the following: | This specification defines the following subscription identifiers. | |||
| However, new Subscription-Id-Type values can be assigned via IANA | ||||
| designated expert as defined in section 12. A server MUST implement | ||||
| all of the Subscription-Id-Types required to perform credit | ||||
| authorization for the services it supports, including possible | ||||
| future values. Unknown or unsupported Subscription-Id-Types MUST be | ||||
| treated according to the 'M' flag rule as defined in [DIAMBASE]. | ||||
| 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 as defined in [E164] | according to the ITU-T E.164 numbering plan as defined in [E164] | |||
| and [CE164]. | and [CE164]. | |||
| END_USER_IMSI 1 | END_USER_IMSI 1 | |||
| The identifier is in international IMSI format, according to the | The identifier is in international IMSI format, according to the | |||
| ITU-T E.212 numbering plan as defined in [E121] and [CE121]. | ITU-T E.212 numbering plan as defined in [E121] and [CE121]. | |||
| END_USER_SIP_URI 2 | END_USER_SIP_URI 2 | |||
| The identifier is in the form of a SIP URL as defined in [SIP]. | The identifier is in the form of a SIP URI as defined in [SIP]. | |||
| 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 [NAI]. | defined in [NAI]. | |||
| 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.47 Subscription-Id-Data AVP | 8.48 Subscription-Id-Data AVP | |||
| The Subscription-Id-Data AVP (AVP Code XXX - IANA please fill in and | The Subscription-Id-Data AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 444) is used to identify the end- | remove this note - suggested value 444) is used to identify the end- | |||
| user and is of type UTF8String. The Subscription-Id-Type AVP defines | user and is of type UTF8String. The Subscription-Id-Type AVP defines | |||
| which type of identifier is used. | which type of identifier is used. | |||
| 8.48 User-Equipment-Info AVP | 8.49 User-Equipment-Info AVP | |||
| The User-Equipment-Info AVP (AVP Code XXX - IANA please fill in and | The User-Equipment-Info AVP (AVP Code XXX - IANA please fill in and | |||
| remove this note - suggested value 458) is of type Grouped, and | remove this note - suggested value 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 | |||
| to network. | connection to network. | |||
| It has the following ABNF grammar: | It has the following ABNF grammar: | |||
| User-Equipment-Info ::= < AVP Header: TBD > | User-Equipment-Info ::= < AVP Header: TBD > | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| { User-Equipment-Info-Type } | { User-Equipment-Info-Type } | |||
| { User-Equipment-Info-Value } | { User-Equipment-Info-Value } | |||
| 8.49 User-Equipment-Info-Type AVP | 8.50 User-Equipment-Info-Type AVP | |||
| The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code XXX | The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code | |||
| - IANA please fill in and remove this note - suggested value 459) and | XXX - IANA please fill in and remove this note - suggested value | |||
| defines the type of the user equipment information contained in the | 459) and defines the type of the user equipment information | |||
| User-Equipment-Info-Value AVP. | contained in the User-Equipment-Info-Value AVP. | |||
| The identifier can be one of the following: | This specification defines the following user equipment types. | |||
| However, new User-Equipment-Info-Type values can be assigned via | ||||
| IANA designated expert as defined in section 12. | ||||
| IMEISV 0 | IMEISV 0 | |||
| The identifier contains the International Mobile Equipment | The identifier contains the International Mobile Equipment | |||
| Identifier and Software Version in the international IMEISV format | Identifier and Software Version in the international IMEISV | |||
| according to 3GPP TS 23.003 [3GPPIMEI]. | format according to 3GPP TS 23.003 [3GPPIMEI]. | |||
| MAC 1 | MAC 1 | |||
| The 48-bit MAC address is formatted as described in [RAD802.1X]. | The 48-bit MAC address is formatted as described in [RAD802.1X]. | |||
| EUI64 2 | EUI64 2 | |||
| The 64-bit identifier used to identify hardware instance of the | The 64-bit identifier used to identify 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 | There are a number of types of terminals that have identifiers | |||
| other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can be | other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can | |||
| converted to modified EUI-64 format as described in [IPv6Addr] or | be converted to modified EUI-64 format as described in [IPv6Addr] | |||
| using some other methods referred to in the service specific | or using some other methods referred to in the service specific | |||
| documentation. | documentation. | |||
| 8.50 User-Equipment-Info-Value AVP | 8.50 User-Equipment-Info-Value AVP | |||
| The User-Equipment-Info-Value AVP (AVP Code XXX - IANA please fill in | The User-Equipment-Info-Value AVP (AVP Code XXX - IANA please fill | |||
| and remove this note - suggested value 460) is of type OctetString | in and remove this note - suggested value 460) is of type | |||
| The User-Equipment-Info-Type AVP defines which type of identifier is | OctetString The User-Equipment-Info-Type AVP defines which type of | |||
| used. | identifier is used. | |||
| 9. Result Code AVP values | 9. Result Code AVP values | |||
| This section defines new Result-Code AVP [DIAMBASE] values that must | This section defines new Result-Code AVP [DIAMBASE] values that must | |||
| be supported by all Diameter implementations that conform to this | be supported by all Diameter implementations that conform to this | |||
| specification. | specification. | |||
| The Credit-Control-Answer message includes the Result-Code AVP, which | The Credit-Control-Answer message includes the Result-Code AVP, | |||
| may indicate that an error was present in the Credit-Control-Request | which may indicate that an error was present in the Credit-Control- | |||
| message. A rejected Credit-Control-Request message SHOULD cause the | Request message. A rejected Credit-Control-Request message SHOULD | |||
| user's session to be terminated. | cause the user's session to be terminated. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 9.1 Transient Failures | 9.1 Transient Failures | |||
| Errors that fall within the transient failures category are used to | Errors that fall within the transient failures category are used to | |||
| inform a peer that the request could not be satisfied at the time it | inform a peer that the request could not be satisfied at the time it | |||
| was received, but MAY be able to satisfy the request in the future. | was received, but MAY be able to satisfy the request in the future. | |||
| DIAMETER_END_USER_SERVICE_DENIED 4010 | DIAMETER_END_USER_SERVICE_DENIED 4010 | |||
| The credit-control server denies the service request due to | The credit-control server denies the service request due to | |||
| service restrictions. If the CCR contained used-service-units they | service restrictions. If the CCR contained used-service-units | |||
| are deducted, if possible. | they are deducted, if possible. | |||
| DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 | DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 | |||
| The credit-control server determines that the service can be | The credit-control server determines that the service can be | |||
| granted to the end user but no further credit-control is needed | granted to the end user but no further credit-control is needed | |||
| for the service (e.g. service is free of charge). | for the service (e.g. service is free of charge). | |||
| DIAMETER_CREDIT_LIMIT_REACHED 4012 | DIAMETER_CREDIT_LIMIT_REACHED 4012 | |||
| The credit-control server denies the service request since the | The credit-control server denies the service request since the | |||
| end- | end- user's account could not cover the requested service. If the | |||
| user's account could not cover the requested service. If the CCR | CCR contained used-service-units they are deducted, if possible. | |||
| contained used-service-units they are deducted, if possible. | ||||
| 9.2 Permanent Failures | 9.2 Permanent Failures | |||
| Errors that fall within permanent failure category are used to inform | Errors that fall within permanent failure category are used to | |||
| the peer that the request failed, and should not be attempted again. | inform the peer that the request failed, and should not be attempted | |||
| again. | ||||
| DIAMETER_USER_UNKNOWN 5030 | DIAMETER_USER_UNKNOWN 5030 | |||
| The specified end user is unknown in the credit-control server. | The specified end user is unknown in the credit-control server. | |||
| DIAMETER_RATING_FAILED 5031 | DIAMETER_RATING_FAILED 5031 | |||
| This error code is used to inform the credit-control client that | This error code is used to inform the credit-control client that | |||
| the credit-control server cannot rate the service request due to | the credit-control server cannot rate the service request due to | |||
| insufficient rating input, incorrect AVP combination or due to an | insufficient rating input, incorrect AVP combination or due to an | |||
| AVP or an AVP value that is not recognized or supported in the | AVP or an AVP value that is not recognized or supported in the | |||
| rating. The Failed-AVP AVP MUST be included and contain a copy of | rating. The Failed-AVP AVP MUST be included and contain a copy of | |||
| the entire AVP(s) that could not be processed successfully or an | the entire AVP(s) that could not be processed successfully or an | |||
| example of the missing AVP complete with the Vendor-Id if | example of the missing AVP complete with the Vendor-Id if | |||
| applicable. The value field of the missing AVP should be of | applicable. The value field of the missing AVP should be of | |||
| correct minimum length and contain zeroes. | correct minimum length and contain zeroes. | |||
| 10. AVP Occurrence Table | 10. AVP Occurrence Table | |||
| The following table presents the AVPs defined in this document, and | The following table presents the AVPs defined in this document, and | |||
| specifies in which Diameter messages they MAY, or MAY NOT be present. | specifies in which Diameter messages they MAY, or MAY NOT be | |||
| Note that AVPs that can only be present within a Grouped AVP are not | present. Note that AVPs that can only be present within a Grouped | |||
| represented in this table. | AVP are not represented in this table. | |||
| The table uses the following symbols: | The table uses the following symbols: | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| 0 The AVP MUST NOT be present in the message. | 0 The AVP MUST NOT be present in the message. | |||
| 0+ Zero or more instances of the AVP MAY be present in the | 0+ Zero or more instances of the AVP MAY be present in the | |||
| message. | message. | |||
| 0-1 Zero or one instance of the AVP MAY be present in the | 0-1 Zero or one instance of the AVP MAY be present in the | |||
| message. It is considered an error if there are more than | message. It is considered an error if there are more | |||
| once instance of the AVP. | than one instance of the AVP. | |||
| 1 One instance of the AVP MUST be present in the message. | 1 One instance of the AVP MUST be present in the message. | |||
| 1+ At least one instance of the AVP MUST be present in the | 1+ At least one instance of the AVP MUST be present in the | |||
| message. | message. | |||
| 10.1 Credit Control AVP Table | 10.1 Credit Control AVP Table | |||
| The table in this section is used to represent which Credit-control | The table in this section is used to represent which Credit-control | |||
| applications specific AVPs defined in this document are to be present | applications specific AVPs defined in this document are to be | |||
| in the Credit Control messages. | present in the Credit Control messages. | |||
| +-----------+ | +-----------+ | |||
| | Command | | | Command | | |||
| | Code | | | Code | | |||
| |-----+-----+ | |-----+-----+ | |||
| Attribute Name | CCR | CCA | | Attribute Name | CCR | CCA | | |||
| ------------------------------|-----+-----+ | ------------------------------|-----+-----+ | |||
| Acct-Multi-Session-Id | 0-1 | 0-1 | | Acct-Multi-Session-Id | 0-1 | 0-1 | | |||
| Auth-Application-Id | 1 | 1 | | Auth-Application-Id | 1 | 1 | | |||
| CC-Correlation-Id | 0-1 | 0 | | CC-Correlation-Id | 0-1 | 0 | | |||
| CC-Session-Failover | 0 | 0-1 | | CC-Session-Failover | 0 | 0-1 | | |||
| skipping to change at page 78, line 44 ¶ | skipping to change at page 80, line 29 ¶ | |||
| CC-Sub-Session-Id | 0-1 | 0-1 | | CC-Sub-Session-Id | 0-1 | 0-1 | | |||
| Check-Balance-Result | 0 | 0-1 | | Check-Balance-Result | 0 | 0-1 | | |||
| Cost-Information | 0 | 0-1 | | Cost-Information | 0 | 0-1 | | |||
| Credit-Control-Failure- | 0 | 0-1 | | Credit-Control-Failure- | 0 | 0-1 | | |||
| Handling | | | | Handling | | | | |||
| Destination-Host | 0-1 | 0 | | Destination-Host | 0-1 | 0 | | |||
| Destination-Realm | 1 | 0 | | Destination-Realm | 1 | 0 | | |||
| Direct-Debiting-Failure- | 0 | 0-1 | | Direct-Debiting-Failure- | 0 | 0-1 | | |||
| Handling | | | | Handling | | | | |||
| Event-Timestamp | 0-1 | 0-1 | | Event-Timestamp | 0-1 | 0-1 | | |||
| Failed-AVP | 0 | 0+ | | ||||
| Final-Unit-Indication | 0 | 0-1 | | Final-Unit-Indication | 0 | 0-1 | | |||
| Granted-Service-Unit | 0 | 0-1 | | Granted-Service-Unit | 0 | 0-1 | | |||
| Multiple-Services-Credit- | 0+ | 0+ | | Multiple-Services-Credit- | 0+ | 0+ | | |||
| Control | | | | Control | | | | |||
| Multiple-Services-Indicator | 0-1 | 0 | | Multiple-Services-Indicator | 0-1 | 0 | | |||
| Origin-Host | 1 | 1 | | Origin-Host | 1 | 1 | | |||
| Origin-Realm | 1 | 1 | | Origin-Realm | 1 | 1 | | |||
| Origin-State-Id | 0-1 | 0-1 | | Origin-State-Id | 0-1 | 0-1 | | |||
| Proxy-Info | 0+ | 0+ | | Proxy-Info | 0+ | 0+ | | |||
| Redirect-Host | 0 | 0+ | | Redirect-Host | 0 | 0+ | | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Redirect-Host-Usage | 0 | 0-1 | | Redirect-Host-Usage | 0 | 0-1 | | |||
| Redirect-Max-Cache-Time | 0 | 0–1 | | Redirect-Max-Cache-Time | 0 | 0-1 | | |||
| Requested-Action | 0-1 | 0 | | Requested-Action | 0-1 | 0 | | |||
| Requested-Service-Unit | 0-1 | 0 | | Requested-Service-Unit | 0-1 | 0 | | |||
| Route-Record | 0+ | 0+ | | Route-Record | 0+ | 0+ | | |||
| Result-Code | 0 | 1 | | Result-Code | 0 | 1 | | |||
| Service-Context-Id | 1 | 0 | | ||||
| Service-Identifier | 0-1 | 0 | | Service-Identifier | 0-1 | 0 | | |||
| Service-Parameter-Info | 0+ | 0 | | Service-Parameter-Info | 0+ | 0 | | |||
| Session-Id | 1 | 1 | | Session-Id | 1 | 1 | | |||
| Subscription-Id | 0+ | 0+ | | Subscription-Id | 0+ | 0 | | |||
| Termination-Cause | 0-1 | 0 | | Termination-Cause | 0-1 | 0 | | |||
| User-Equipment-Info | 0-1 | 0 | | User-Equipment-Info | 0-1 | 0 | | |||
| Used-Service-Unit | 0+ | 0 | | Used-Service-Unit | 0+ | 0 | | |||
| User-Name | 0-1 | 0-1 | | User-Name | 0-1 | 0-1 | | |||
| Validity-Time | 0 | 0-1 | | Validity-Time | 0 | 0-1 | | |||
| ------------------------------|-----+-----+ | ------------------------------|-----+-----+ | |||
| 10.2 Re-Auth-Request/Answer AVP Table | 10.2 Re-Auth-Request/Answer AVP Table | |||
| This section defines AVPs that are specific to Diameter Credit | This section defines AVPs that are specific to Diameter Credit | |||
| Control Application and MAY be included in the Diameter Re-Auth- | Control Application and MAY be included in the Diameter Re-Auth- | |||
| Request/Answer (RAR/RAA) message [DIAMBASE]. | Request/Answer (RAR/RAA) message [DIAMBASE]. | |||
| Re-Auth-Request/Answer command MAY include the following additional | Re-Auth-Request/Answer command MAY include the following additional | |||
| AVPs: | AVPs: | |||
| +---------------+ | +---------------+ | |||
| | Command Code | | | Command Code | | |||
| |-------+-------+ | |-------+-------+ | |||
| Attribute Name | RAR | RAA | | Attribute Name | RAR | RAA | | |||
| ------------------------------+-------+-------+ | ------------------------------+-------+-------+ | |||
| CC-Sub-Session-Id | 0-1 | 0-1 | | CC-Sub-Session-Id | 0-1 | 0-1 | | |||
| G-S-U-Pool-Identifier | 0-1 | 0-1 | | G-S-U-Pool-Identifier | 0-1 | 0-1 | | |||
| Service-Identifier | 0-1 | 0-1 | | Service-Identifier | 0-1 | 0-1 | | |||
| Rating-Group | 0-1 | 0-1 | | Rating-Group | 0-1 | 0-1 | | |||
| ------------------------------+-------+-------+ | ------------------------------+-------+-------+ | |||
| 11. RADIUS/Diameter Credit-control Interworking Model | 11. RADIUS/Diameter Credit-control Interworking Model | |||
| This section defines the basic principles for the Diameter Credit- | This section defines the basic principles for the Diameter Credit- | |||
| control/RADIUS prepaid inter-working model, that is a message | control/RADIUS prepaid inter-working model, that is a message | |||
| translation between RADIUS based prepaid solution and Diameter | translation between RADIUS based prepaid solution and Diameter | |||
| Credit-control application. A complete description of the protocol | Credit-control application. A complete description of the protocol | |||
| translations between RADIUS and Diameter Credit-control application | translations between RADIUS and Diameter Credit-control application | |||
| is | is | |||
| beyond the scope of this specification and SHOULD be addressed in | beyond the scope of this specification and SHOULD be addressed in | |||
| another appropriate document such as the RADIUS prepaid | another appropriate document such as the RADIUS prepaid | |||
| specification. | specification. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| The Diameter credit-control architecture may have a Translation | The Diameter credit-control architecture may have a Translation | |||
| Agent, which is capable of translation between RADIUS prepaid and | Agent, which is capable of translation between RADIUS prepaid and | |||
| Diameter Credit-control protocol. An AAA server, usually the home AAA | Diameter Credit-control protocol. An AAA server, usually the home | |||
| server, may act as a Translation Agent while acting also as Diameter | AAA server, may act as a Translation Agent while acting also as | |||
| credit-control client for service elements that use credit control | Diameter credit-control client for service elements that use credit | |||
| mechanisms other than Diameter credit-control, for instance RADIUS | control mechanisms other than Diameter credit-control, for instance | |||
| prepaid. In this case the home AAA server contacts the Diameter | RADIUS prepaid. In this case the home AAA server contacts the | |||
| credit-control server as part of the authorization process. The | Diameter credit-control server as part of the authorization process. | |||
| interworking architecture is illustrated in figure 7 and interworking | The interworking architecture is illustrated in figure 7 and | |||
| flow in figure 8. In roaming situation the service element (e.g. the | interworking flow in figure 8. In roaming situation the service | |||
| NAS) may be located in the visited network and a visited AAA server | element (e.g. the NAS) may be located in the visited network and a | |||
| is usually contacted. The visited AAA server connects then to the | visited AAA server is usually contacted. The visited AAA server | |||
| home AAA server. | connects then to the home AAA server. | |||
| Radius prepaid | Radius prepaid | |||
| +--------+ +---------+ protocol +------------+ +--------+ | +--------+ +---------+ protocol +------------+ +--------+ | |||
| | End |<----->| Service |<---------->| Home AAA | |Business| | | End |<----->| Service |<---------->| Home AAA | |Business| | |||
| | User | | Element | | Server | |Support | | | User | | Element | | Server | |Support | | |||
| +--------+ +-->| | |+----------+|->|System | | +--------+ +-->| | |+----------+|->|System | | |||
| | +---------+ ||CC client || | | | | +---------+ ||CC client || | | | |||
| | |+----------+| | | | | |+----------+| | | | |||
| +--------+ | +------^-----+ +----^---+ | +--------+ | +------^-----+ +----^---+ | |||
| | End |<--+ credit-control | | | | End |<--+ credit-control | | | |||
| | User | protocol | | | | User | protocol | | | |||
| +--------+ +-------V--------+ | | +--------+ +-------V--------+ | | |||
| |Credit-control |----+ | |Credit-control |----+ | |||
| | Server | | | Server | | |||
| +----------------+ | +----------------+ | |||
| Figure 7: Credit-control architecture with Service Element | Figure 7: Credit-control architecture with Service Element | |||
| containing translation agent, translating RADIUS | containing translation agent, translating RADIUS | |||
| prepaid to Diameter credit control protocol | prepaid to Diameter credit control protocol | |||
| When the AAA server acting as a Translation Agent receives an initial | When the AAA server acting as a Translation Agent receives an | |||
| RADIUS Access-Request message from service Element (e.g. NAS access), | initial RADIUS Access-Request message from service Element (e.g. NAS | |||
| it performs regular Authentication and Authorization. If the RADIUS | access), it performs regular Authentication and Authorization. If | |||
| Access-Request message indicates that the service element is capable | the RADIUS Access-Request message indicates that the service element | |||
| of credit-control, and if the home AAA server finds that the | is capable of credit-control, and if the home AAA server finds that | |||
| subscriber is a prepaid subscriber then a Diameter Credit control | the subscriber is a prepaid subscriber then a Diameter Credit | |||
| request SHOULD be sent towards the credit-control server to perform | control request SHOULD be sent towards the credit-control server to | |||
| credit authorization and to establish a credit control session. After | perform credit authorization and to establish a credit control | |||
| the Diameter credit-control server checks the end user's account | session. After the Diameter credit-control server checks the end | |||
| balance, rates the service and reserves credit from the end user's | user's account balance, rates the service and reserves credit from | |||
| account, the reserved quota is returned to the home AAA server in the | the end user's account, the reserved quota is returned to the home | |||
| Diameter Credit-Control-Answer. Then the home AAA server sends the | AAA server in the Diameter Credit-Control-Answer. Then the home AAA | |||
| reserved quota to the service element in the RADIUS Access-Accept. | server sends the reserved quota to the service element in the RADIUS | |||
| Access-Accept. | ||||
| Diameter Credit Control Application May 14, 2004 | ||||
| At the expiry of the allocated quota, the service element sends a new | At the expiry of the allocated quota, the service element sends a | |||
| RADIUS Access-Request to the home AAA server containing the units | new RADIUS Access-Request to the home AAA server containing the | |||
| used this far. The home AAA server shall map RADIUS Access-Request | units used this far. The home AAA server shall map RADIUS Access- | |||
| containing the reported units to the Diameter credit-control server | Request containing the reported units to the Diameter credit-control | |||
| in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter | server in a Diameter Credit-Control-Request (UPDATE_REQUEST). The | |||
| credit-control server debits the used units from the end user's | Diameter credit-control server debits the used units from the end | |||
| account and allocates a new quota that is returned to the home AAA | user's account and allocates a new quota that is returned to the | |||
| server in the Diameter Credit-Control-Answer. The quota is | home AAA server in the Diameter Credit-Control-Answer. The quota is | |||
| transferred to the service element in the RADIUS Access-Accept. When | transferred to the service element in the RADIUS Access-Accept. When | |||
| the end user terminates the service or when the entire quota has been | the end user terminates the service or when the entire quota has | |||
| used, the service element sends a RADIUS Access-Request. To debit the | been used, the service element sends a RADIUS Access-Request. To | |||
| used units from the end user's account and to stop the credit control | debit the used units from the end user's account and to stop the | |||
| session, the home AAA server sends a Diameter Credit-Control-Request | credit control session, the home AAA server sends a Diameter Credit- | |||
| (TERMINATION_REQUEST) to the credit-control server. The Diameter | Control-Request (TERMINATION_REQUEST) to the credit-control server. | |||
| credit-control server acknowledges the session termination by sending | The Diameter credit-control server acknowledges the session | |||
| a Diameter Credit-Control-Answer to the home AAA server. The RADIUS | termination by sending a Diameter Credit-Control-Answer to the home | |||
| Access-Accept is sent to the NAS. | AAA server. The RADIUS Access-Accept is sent to the NAS. | |||
| A following diagram illustrates a RADIUS prepaid - Diameter credit | A following diagram illustrates a RADIUS prepaid - Diameter credit | |||
| control interworking sequence. | control interworking sequence. | |||
| Service Element Translation agent | Service Element Translation agent | |||
| (e.g.NAS) (CC Client) CC Server | (e.g.NAS) (CC Client) CC Server | |||
| | Access-Request | | | | Access-Request | | | |||
| |----------------------->| | | |----------------------->| | | |||
| | | CCR (initial) | | | | CCR (initial) | | |||
| | |----------------------->| | | |----------------------->| | |||
| skipping to change at page 82, line 4 ¶ | skipping to change at page 83, line 38 ¶ | |||
| |----------------------->| | | |----------------------->| | | |||
| | | CCR (update, | | | | CCR (update, | | |||
| | | used Units, | | | | used Units, | | |||
| | |----------------------->| | | |----------------------->| | |||
| | | CCA (granted_Units) | | | | CCA (granted_Units) | | |||
| | |<-----------------------| | | |<-----------------------| | |||
| | Access-Accept | | | | Access-Accept | | | |||
| | (granted Units) | | | | (granted Units) | | | |||
| |<-----------------------| | | |<-----------------------| | | |||
| : : : | : : : | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | Access-Request | | | | Access-Request | | | |||
| |----------------------->| | | |----------------------->| | | |||
| | | CCR (termin., | | | | CCR (termin., | | |||
| | | used Units) | | | | used Units) | | |||
| | |----------------------->| | | |----------------------->| | |||
| | | CCA | | | | CCA | | |||
| | |<-----------------------| | | |<-----------------------| | |||
| | Access-Accept | | | | Access-Accept | | | |||
| |<-----------------------| | | |<-----------------------| | | |||
| | | | | | | | | |||
| Figure 8: Message flow example with RADIUS prepaid - Diameter | ||||
| credit control interworking | ||||
| 12. IANA Considerations | Figure 8: Message flow example with RADIUS prepaid - | |||
| Diameter credit control interworking | ||||
| This section contains the namespaces that have either been created in | 12. IANA Considerations | |||
| this specification, or the values assigned to existing namespaces | ||||
| This section contains the namespaces that have either been created | ||||
| in this specification, or the values assigned to existing namespaces | ||||
| managed by IANA. | managed by IANA. | |||
| 12.1 Application Identifier | 12.1 Application Identifier | |||
| This specification assigns the value XXX [IANA please fill in XXX | This specification assigns the value XXX [IANA please fill in XXX | |||
| (suggested value 4) and remove this note] to the Application | (suggested value 4) and remove this note], 'Diameter Credit | |||
| Identifier namespace defined in [DIAMBASE]. See section 1.3 for more | Control', to the Application Identifier namespace defined in | |||
| information. | [DIAMBASE]. See section 1.3 for more information. | |||
| 12.2 Command Codes | 12.2 Command Codes | |||
| This specification uses the value [IANA please fill in XXX (suggested | This specification uses the value [IANA please fill in XXX | |||
| value 272) and remove this note] from the Command code namespace | (suggested value 272) and remove this note] from the Command code | |||
| defined in [DIAMBASE]. | namespace defined in [DIAMBASE] for the Credit-Control-Request (CCR) | |||
| and Credit-Control-Answer (CCA) commands. | ||||
| 12.3 AVP Codes | 12.3 AVP Codes | |||
| This specification assigns the values XXX - YYY [IANA please fill in | This specification assigns the values XXX - YYY [IANA please fill in | |||
| XXX, YYY (suggested values 411, 457) and remove this note] from the | XXX, YYY (suggested values 411, 458) and remove this note] from the | |||
| AVP code namespace defined in [DIAMBASE] See section 8 for the | AVP code namespace defined in [DIAMBASE] See section 8 for the | |||
| assignment of the namespace in this specification. | assignment of the namespace in this specification. | |||
| 12.4 Result-Code AVP Values | 12.4 Result-Code AVP Values | |||
| This specification assigns the values X1, X2, X3, X4, X5 [IANA please | ||||
| fill in XXX (suggested value 4010, 4011, 4012, 5030 and 5031) and | ||||
| remove this note] from the Result-Code AVP value namespace defined in | ||||
| [DIAMBASE]. See section 9 for the assignment of the namespace in this | ||||
| specification. | ||||
| Diameter Credit Control Application May 14, 2004 | ||||
| 12.5 CC-Request-Type AVP | ||||
| As defined in section 8.3, the CC-Request-Type AVP defines the values | ||||
| X1-X3 [IANA please fill in X1-X3 (suggested value 1, 3) and remove | ||||
| this note]. All remaining values are available for assignment via | ||||
| Designated Expert [IANA]. | ||||
| 12.6 CC-Session-Failover AVP | This specification assigns the values X1, X2, X3, X4, X5 [IANA | |||
| please fill in XXX (suggested value 4010, 4011, 4012, 5030 and 5031) | ||||
| and remove this note] from the Result-Code AVP value namespace | ||||
| defined in [DIAMBASE]. See section 9 for the assignment of the | ||||
| namespace in this specification. | ||||
| As defined in section 8.4, the CC-Failover-Supported AVP defines the | 12.5 CC-Request-Type AVP | |||
| values X1-X2 [IANA please fill in X1, X2 (suggested value 0, 1) and | ||||
| remove this note]. All remaining values are available for assignment | ||||
| via Designated Expert [IANA]. | ||||
| 12.7 CC-Unit-Type AVP | As defined in section 8.3, the CC-Request-Type AVP includes | |||
| Enumerated type values X1 - X3. IANA is to create and maintain a | ||||
| namespace for this AVP.[IANA please fill in X1-X3 (suggested value | ||||
| 1, 3) and remove this note]. All remaining values are available for | ||||
| assignment via Designated Expert [IANA]. | ||||
| As defined in section 8.32, the CC-Unit-Type AVP defines the values | 12.6 CC-Session-Failover AVP | |||
| X1-X5 [IANA please fill in X1-X5 (suggested value 0, 5) and remove | As defined in section 8.4, the CC-Failover-Supported AVP includes | |||
| this note]. All remaining values are available for assignment via | Enumerated type values X0 - X1. IANA is to create and maintain a | |||
| Designated Expert [IANA]. | namespace for this AVP.[IANA please fill in X0, X1 (suggested value | |||
| 0, 1) and remove this note]. All remaining values are available for | ||||
| assignment via Designated Expert [IANA]. | ||||
| 12.8 Check-Balance-Result AVP | 12.7 CC-Unit-Type AVP | |||
| As defined in Section 8.6, the Check-Balance-Result AVP defines the | As defined in section 8.32, the CC-Unit-Type AVP includes Enumerated | |||
| values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 1) and | type values X0 - X5. IANA is to create and maintain a namespace for | |||
| this AVP. [IANA please fill in X0-X5 (suggested value 0, 5) and | ||||
| remove this note]. All remaining values are available for assignment | remove this note]. All remaining values are available for assignment | |||
| via Designated Expert [IANA]. | via Designated Expert [IANA]. | |||
| 12.9 Credit-Control AVP | 12.8 Check-Balance-Result AVP | |||
| As defined in section 8.13, the Credit-Control AVP defines the values | ||||
| X1-X2 [IANA please fill in X1-X2 (suggested value 0, 1) and remove | ||||
| this note]. All remaining values are available for assignment via | ||||
| Designated Expert [IANA]. | ||||
| 12.10 Credit-Control-Failure-Handling AVP | ||||
| As defined in Section 8.14, the Credit-Control-Failure-Handling AVP | As defined in Section 8.6, the Check-Balance-Result AVP includes | |||
| defines the values [IANA please fill in X1-X2 (suggested value 0, 2) | Enumerated type values X0 - X1. IANA is to create and maintain a | |||
| and remove this note]. All remaining values are available for | namespace for this AVP.[IANA please fill in X0-X1 (suggested value | |||
| 0, 1) and remove this note]. All remaining values are available for | ||||
| assignment via Designated Expert [IANA]. | assignment via Designated Expert [IANA]. | |||
| 12.11 Direct-Debiting-Failure-Handling AVP | 12.9 Credit-Control AVP | |||
| As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP | As defined in section 8.13, the Credit-Control AVP includes | |||
| defines the values [IANA please fill in X1-X2 (suggested value 0, 1) | Enumerated type values X0 - X1. IANA is to create and maintain a | |||
| and remove this note]. All remaining values are available for | namespace for this AVP. [IANA please fill in X0-X1 (suggested value | |||
| 0, 1) and remove this note]. All remaining values are available for | ||||
| assignment via Designated Expert [IANA]. | assignment via Designated Expert [IANA]. | |||
| Diameter Credit Control Application May 14, 2004 | 12.10 Credit-Control-Failure-Handling AVP | |||
| 12.12 Final-Unit-Action AVP | As defined in Section 8.14, the Credit-Control-Failure-Handling AVP | |||
| includes Enumerated type values X0 - X2. IANA is to create and | ||||
| maintain a namespace for this AVP. [IANA please fill in X0-X2 | ||||
| (suggested value 0, 2) and remove this note]. All remaining values | ||||
| are available for assignment via Designated Expert [IANA]. | ||||
| As defined in Section 8.35, the Final-Unit-Action AVP defines the | 12.11 Direct-Debiting-Failure-Handling AVP | |||
| values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 2) and | ||||
| remove this note]. All remaining values are available for assignment | ||||
| via Designated Expert [IANA]. | ||||
| 12.13 Multiple-Services-Indicator AVP | As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP | |||
| includes Enumerated type values X0 - X1. IANA is to create and | ||||
| maintain a namespace for this AVP.[IANA please fill in X0-X1 | ||||
| (suggested value 0, 1) and remove this note]. All remaining values | ||||
| are available for assignment via Designated Expert [IANA]. | ||||
| As defined in Section 8.40, the Multiple-Services-Indicator AVP | 12.12 Final-Unit-Action AVP | |||
| defines the values X1-X2 [IANA please fill in X1-X2 (suggested value | As defined in Section 8.35, the Final-Unit-Action AVP includes | |||
| 0, 1) and remove this note]. All remaining values are available for | Enumerated type values X0 - X2. IANA is to create and maintain a | |||
| namespace for this AVP. [IANA please fill in X0-X2 (suggested value | ||||
| 0, 2) and remove this note]. All remaining values are available for | ||||
| assignment via Designated Expert [IANA]. | assignment via Designated Expert [IANA]. | |||
| 12.14 Redirect-Address-Type AVP | 12.13 Multiple-Services-Indicator AVP | |||
| As defined in Section 8.38, the Redirect-Address-Type AVP defines the | As defined in Section 8.40, the Multiple-Services-Indicator AVP | |||
| values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 3) and | includes Enumerated type values X0 - X1. IANA is to create and | |||
| remove this note]. All remaining values are available for assignment | maintain a namespace for this AVP. [IANA please fill in X0-X1 | |||
| via Designated Expert [IANA]. | (suggested value 0, 1) and remove this note]. All remaining values | |||
| are available for assignment via Designated Expert [IANA]. | ||||
| 12.15 Requested-Action AVP | 12.14 Redirect-Address-Type AVP | |||
| As defined in Section 8.41, the Requested-Action AVP defines the | As defined in Section 8.38, the Redirect-Address-Type AVP includes | |||
| values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 3) and | Enumerated type values X0 - X3. IANA is to create and maintain a | |||
| remove this note]. All remaining values are available for assignment | namespace for this AVP. [IANA please fill in X0-X3 (suggested value | |||
| via Designated Expert [IANA]. | 0, 3) and remove this note]. All remaining values are available for | |||
| assignment via Designated Expert [IANA]. | ||||
| 12.16 Subscription-Id-Type AVP | 12.15 Requested-Action AVP | |||
| As defined in Section 8.46, the Subscription-Id-Type AVP defines the | As defined in Section 8.41, the Requested-Action AVP includes | |||
| values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 4) and | Enumerated type values X0 - X3. IANA is to create and maintain a | |||
| remove this note]. All remaining values are available for assignment | namespace for this AVP. [IANA please fill in X0-X3 (suggested value | |||
| via Designated Expert [IANA]. | 0, 3) and remove this note]. All remaining values are available for | |||
| assignment via Designated Expert [IANA]. | ||||
| 12.17 Tariff-Change-Usage AVP | 12.16 Subscription-Id-Type AVP | |||
| As defined in Section 8.27, the Tariff-Change-Usage AVP defines the | As defined in Section 8.47, the Subscription-Id-Type AVP includes | |||
| values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 2) and | Enumerated type values X0 - X4. IANA is to create and maintain a | |||
| remove this note]. All remaining values are available for assignment | namespace for this AVP. [IANA please fill in X0-X4 (suggested value | |||
| via Designated Expert [IANA]. | 0, 4) and remove this note]. All remaining values are available for | |||
| assignment via Designated Expert [IANA]. | ||||
| 12.18 User-Equipment-Info-Type AVP | 12.17 Tariff-Change-Usage AVP | |||
| As defined in Section 8.49, the User-Equipment-Info-Type AVP defines | As defined in Section 8.27, the Tariff-Change-Usage AVP includes | |||
| the values X1-X2 [IANA please fill in X1-X2 (suggested value 0, 3) | Enumerated type values X0 - X2. IANA is to create and maintain a | |||
| and remove this note]. All remaining values are available for | namespace for this AVP. [IANA please fill in X0-X2 (suggested value | |||
| 0, 2) and remove this note]. All remaining values are available for | ||||
| assignment via Designated Expert [IANA]. | assignment via Designated Expert [IANA]. | |||
| Diameter Credit Control Application May 14, 2004 | 12.18 User-Equipment-Info-Type AVP | |||
| As defined in Section 8.50, the User-Equipment-Info-Type AVP | ||||
| includes Enumerated type values X0 - X3. IANA is to create and | ||||
| maintain a namespace for this AVP. [IANA please fill in X0-X3 | ||||
| (suggested value 0, 3) and remove this note]. All remaining values | ||||
| are available for assignment via Designated Expert [IANA]. | ||||
| 13. Credit-control Application Related Parameters | 13. Credit-control Application Related Parameters | |||
| Tx timer | Tx timer | |||
| When real-time credit-control is required, the credit-control | When real-time credit-control is required, the credit-control | |||
| client contacts the credit-control server before and during the | client contacts the credit-control server before and during the | |||
| service is provided to an end user. Due to real-time nature of the | service is provided to an end user. Due to real-time nature of | |||
| application the communication delays SHOULD be minimized, e.g. to | the application the communication delays SHOULD be minimized, | |||
| avoid too long service set up time experienced by the end user. | e.g. to avoid too long service set up time experienced by the end | |||
| The Tx timer is introduced to control the waiting time in the | user. The Tx timer is introduced to control the waiting time in | |||
| client in the PENDING state. When the Tx timer elapses the credit- | the client in the PENDING state. When the Tx timer elapses the | |||
| control client takes an action to the end user according to the | credit-control client takes an action to the end user according | |||
| value of the Credit-Control-Failure-Handling AVP or according to | to the value of the Credit-Control-Failure-Handling AVP or | |||
| the value of the Direct-Debiting-Failure-Handling AVP. | according to the value of the Direct-Debiting-Failure-Handling | |||
| AVP. | ||||
| The recommended value is 10 seconds. | The recommended value is 10 seconds. | |||
| Tcc timer | Tcc timer | |||
| The Tcc timer supervises an ongoing credit control session in the | The Tcc timer supervises an ongoing credit control session in the | |||
| credit control server. It is RECOMMENDED to use the Validity-Time | credit control server. It is RECOMMENDED to use the Validity-Time | |||
| as input to set the Tcc timer value. To avoid the credit control | as input to set the Tcc timer value. To avoid the credit control | |||
| session in the Diameter credit control server to change to Idle | session in the Diameter credit control server to change to Idle | |||
| state in case of short transient network failure, Tcc MAY be set | state in case of short transient network failure, Tcc MAY be set | |||
| to two times the value of Validity-Time. | to two times the value of Validity-Time. | |||
| Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling | Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling | |||
| Client implementations may offer the possibility to locally | Client implementations may offer the possibility to locally | |||
| configure these AVPs. In such a case their value and behavior is | configure these AVPs. In such a case their value and behavior is | |||
| defined in section 5.7 for the Credit-Control-Failure-Handling and | defined in section 5.7 for the Credit-Control-Failure-Handling | |||
| in section 6.5 for the Direct-Debiting-Failure-Handling. | and in section 6.5 for the Direct-Debiting-Failure-Handling. | |||
| 14. Security Consideration | 14. Security Consideration | |||
| The Diameter base protocol [DIAMBASE] requires that each Diameter | The Diameter base protocol [DIAMBASE] requires that each Diameter | |||
| implementation uses underlying security, i.e. IPsec or TLS. These | implementation uses underlying security, i.e. IPsec or TLS. These | |||
| mechanisms are believed to provide sufficient protection under the | mechanisms are believed to provide sufficient protection under the | |||
| normal Internet threat model - that is, assuming the authorized nodes | normal Internet threat model - that is, assuming the authorized | |||
| engaging in the protocol have not been compromised, but the attacker | nodes engaging in the protocol have not been compromised, but the | |||
| has complete control over the communication channels between them. | attacker has complete control over the communication channels | |||
| This includes eavesdropping, message modification, insertion, man-in- | between them. This includes eavesdropping, message modification, | |||
| the-middle and replay attacks. Note also that this application | insertion, man-in-the-middle and replay attacks. Note also that this | |||
| includes a mechanism for application layer replay protection by the | application includes a mechanism for application layer replay | |||
| means of Session-ID from [DIAMBASE], and CC-Request-Number specified | protection by the means of Session-ID from [DIAMBASE], and CC- | |||
| in this document. The Diameter credit control application is often | Request-Number specified in this document. The Diameter credit | |||
| used within one domain and there may be just single hop between the | control application is often used within one domain and there may be | |||
| peers. In these environments the use of TLS or IPsec is sufficient. | just single hop between the peers. In these environments the use of | |||
| TLS or IPsec is sufficient. The details of TLS and IPsec related | ||||
| Diameter Credit Control Application May 14, 2004 | security considerations are discussed in the [DIAMBASE]. | |||
| The details of TLS and IPsec related security considerations are | ||||
| discussed in the [DIAMBASE]. | ||||
| Because this application handles monetary transactions (directly or | Because this application handles monetary transactions (directly or | |||
| indirectly) this kind of application increases the interest for | indirectly) this kind of application increases the interest for | |||
| various security attacks. Therefore all parties communicating with | various security attacks. Therefore all parties communicating with | |||
| each other MUST be authenticated, including, for instance, TLS | each other MUST be authenticated, including, for instance, TLS | |||
| client-side authentication. In addition to this, authorization of the | client-side authentication. In addition to this, authorization of | |||
| client SHOULD be emphasized, i.e. that the client is allowed to | the client SHOULD be emphasized, i.e. that the client is allowed to | |||
| perform credit control for a certain user. The specific means of | perform credit control for a certain user. The specific means of | |||
| authorization are outside of the scope of this specification but can | authorization are outside of the scope of this specification but can | |||
| be for instance, manual configuration. | be for instance, manual configuration. | |||
| Another kind of threat is malicious modification, injection or | Another kind of threat is malicious modification, injection or | |||
| deletion of AVPs or complete credit control messages. The credit | deletion of AVPs or complete credit control messages. The credit | |||
| control messages contain sensitive billing related information (such | control messages contain sensitive billing related information (such | |||
| as subscription Id, granted units, used units, cost information) | as subscription Id, granted units, used units, cost information) | |||
| whose malicious modification can have financial consequences. | whose malicious modification can have financial consequences. | |||
| Sometimes simply delaying the credit control messages can cause | Sometimes simply delaying the credit control messages can cause | |||
| disturbances in the credit control client or server. | disturbances in the credit control client or server. | |||
| Even without any modification to the messages an adversary can invite | Even without any modification to the messages an adversary can | |||
| a security threat by eavesdropping, because the transactions contain | invite a security threat by eavesdropping, because the transactions | |||
| private information about the user. Also by monitoring the credit | contain private information about the user. Also by monitoring the | |||
| control messages one can collect information about credit control | credit control messages one can collect information about credit | |||
| server's billing models and business relationships. | control server's billing models and business relationships. | |||
| When third party relays or proxy are involved, the hop-by-hop | When third party relays or proxy are involved, the hop-by-hop | |||
| security does not necessarily provide sufficient protection for | security does not necessarily provide sufficient protection for | |||
| Diameter user session. Diameter messages, such as CCR and CCA, | Diameter user session. Diameter messages, such as CCR and CCA, | |||
| containing sensitive AVPs may be inappropriate in some cases to be | containing sensitive AVPs may be inappropriate in some cases to be | |||
| sent via untrusted Diameter proxy agents since there are no assurance | sent via untrusted Diameter proxy agents since there are no | |||
| that third party proxies will not modify the credit control commands | assurance that third party proxies will not modify the credit | |||
| or AVP values. | control commands or AVP values. | |||
| 14.1 Direct Connection with Redirects | 14.1 Direct Connection with Redirects | |||
| A Diameter Credit control agent cannot always know whether agents | A Diameter Credit control agent cannot always know whether agents | |||
| between it and the end user's Diameter credit control server are | between it and the end user's Diameter credit control server are | |||
| reliable. In this case the Diameter Credit control agent doesn't have | reliable. In this case the Diameter Credit control agent doesn't | |||
| a routing entry in its Diameter Routing Table (defined in [DIAMBASE] | have a routing entry in its Diameter Routing Table (defined in | |||
| in section 2.7) for the realm of the Credit Control Server in the end | [DIAMBASE] in section 2.7) for the realm of the Credit Control | |||
| user's home domain. The Diameter Credit control agent can have a | Server in the end user's home domain. The Diameter Credit control | |||
| default route configured to a local Redirect agent and it re-directs | agent can have a default route configured to a local Redirect agent | |||
| the CCR message to the redirect agent. The local Redirect agent then | and it re-directs the CCR message to the redirect agent. The local | |||
| returns a redirect notification (Result-code 3006, | Redirect agent then returns a redirect notification (Result-code | |||
| DIAMETER_REDIRECT_INDICATION) to the Credit control agent, as well | 3006, DIAMETER_REDIRECT_INDICATION) to the Credit control agent, as | |||
| Diameter Credit control Server(s) information (Redirect-Host AVP) and | well Diameter Credit control Server(s) information (Redirect-Host | |||
| information (Redirect-Host-Usage AVP) how to the routing entry | AVP) and information (Redirect-Host-Usage AVP) how to the routing | |||
| entry resulting from the Redirect-Host is to be used. The Diameter | ||||
| Diameter Credit Control Application May 14, 2004 | credit control agent then forwards the CCR message directly to one | |||
| of the hosts identified by the CCA message from the redirect agent. | ||||
| resulting from the Redirect-Host is to be used. The Diameter credit | If the value of the Redirect-Host-Usage AVP is unequal than zero all | |||
| control agent then forwards the CCR message directly to one of the | ||||
| hosts identified by the CCA message from the redirect agent. If the | ||||
| value of the Redirect-Host-Usage AVP is unequal than zero all | ||||
| following messages are sent to the host specified in the Redirect- | following messages are sent to the host specified in the Redirect- | |||
| Host AVP until the time specified by the Redirect-Max-Cache-Time AVP | Host AVP until the time specified by the Redirect-Max-Cache-Time AVP | |||
| is expired. | is expired. | |||
| There are some authorization issues even with redirects. There may be | There are some authorization issues even with redirects. There may | |||
| attacks towards nodes that have been properly authorized, but abuse | be attacks towards nodes that have been properly authorized, but | |||
| their authorization or have been compromised. These issues are | abuse their authorization or have been compromised. These issues are | |||
| discussed more widely in [DIAMEAP] section 8. | discussed more widely in [DIAMEAP] section 8. | |||
| 15. References | 15. References | |||
| 15.1 Normative | 15.1 Normative | |||
| [DIAMBASE] P. Calhoun, J. Loughney, J. Arkko, E. Guttman, G. Zorn. | [DIAMBASE] P. Calhoun, J. Loughney, J. Arkko, E. Guttman, G. Zorn. | |||
| "Diameter Base Protocol", RFC 3588, September 2003. | "Diameter Base Protocol", RFC 3588, September 2003. | |||
| [3GPPCHARG] 3rd Generation Partnership Project; Technical | [3GPPCHARG] 3rd Generation Partnership Project; Technical | |||
| Specification Group Services and System Aspects, Service | Specification Group Services and System Aspects, Service | |||
| aspects; Charging and Billing, (release 5), 3GPP TS | aspects; Charging and Billing, (release 5), 3GPP TS | |||
| 22.115 v. 5.2.1, 2002-03 | 22.115 v. 5.2.1, 2002-03 | |||
| [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, G. | [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, | |||
| Camarillo, A. Johnston, J. Peterson, R. Sparks | G. Camarillo, A. Johnston, J. Peterson, R. Sparks | |||
| "SIP: Session Initiation Protocol", RFC 3261. June 2002. | "SIP: Session Initiation Protocol", RFC 3261. June 2002. | |||
| [NAI] Aboba, Beadles "The Network Access Identifier." RFC | ||||
| [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486. | 2486. | |||
| January 1999. | January 1999. | |||
| [E164] Recommendation E.164/I.331 (05/97): The International | [E164] Recommendation E.164/I.331 (05/97): The International | |||
| Public Telecommunication Numbering Plan. 1997. | Public Telecommunication Numbering Plan. 1997. | |||
| [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List | [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List | |||
| of ITU-T Recommendation E.164 assigned country codes", | of ITU-T Recommendation E.164 assigned country codes", | |||
| June 2000. | June 2000. | |||
| [E212] Recommendation E.212 (11/98): The international | [E212] Recommendation E.212 (11/98): The international | |||
| identification plan for mobile terminals and mobile | identification plan for mobile terminals and mobile | |||
| users. 1998. | users. 1998. | |||
| [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List | [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" | |||
| List | ||||
| of mobile country or geographical area codes ", February | of mobile country or geographical area codes ", February | |||
| 1999. | 1999. | |||
| [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA | [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| Considerations Section in RFCs", BCP 26, RFC 2434, | Considerations Section in RFCs", BCP 26, RFC 2434, | |||
| October | October | |||
| 1998 | 1998 | |||
| [IPv4] J. Postel. "Internet Protocol", STD 5, RFC 791, September | [IPv4] J. Postel. "Internet Protocol", STD 5, RFC 791, | |||
| 1981. | September 1981. | |||
| [IPv6Addr] R. Hinden, S. Deering. "Internet Protocol Version 6 | [IPv6Addr] R. Hinden, S. Deering. "Internet Protocol Version 6 | |||
| (IPv6) | (IPv6) | |||
| Addressing Architecture", RFC 3513, April 2003. | Addressing Architecture", RFC 3513, April 2003. | |||
| [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate | [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [ISO4217] Codes for the representation of currencies and funds, | [ISO4217] Codes for the representation of currencies and funds, | |||
| International Standard ISO 4217,2001 | International Standard ISO 4217,2001 | |||
| [NASREQ] P. Calhoun, G. Zorn, D. Spence, D. Mitton. "Diameter | [NASREQ] P. Calhoun, G. Zorn, D. Spence, D. Mitton. "Diameter | |||
| NASREQ Application", IETF work in progress. | NASREQ Application", IETF work in progress. | |||
| [AAATRANS] B. Aboba, J. Wood. "Authentication, Authorization and | [AAATRANS] B. Aboba, J. Wood. "Authentication, Authorization and | |||
| Accounting (AAA) Transport Profile", RFC 3539, June 2003 | Accounting (AAA) Transport Profile", RFC 3539, June 2003 | |||
| [URL] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform | [URL] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform | |||
| Resource Locators (URL)", RFC 1738, December 1994 | Resource Locators (URL)ö, RFC 1738, December 1994 | |||
| [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", | [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", | |||
| RFC 3580, September 2003. | RFC 3580, September 2003. | |||
| [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) | [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) | |||
| Registration Authority", | Registration Authority", | |||
| http://standards.ieee.org/regauth/oui/tutorials/EUI64.htm | http://standards.ieee.org/regauth/oui/tutorials/EUI64.ht | |||
| l March 1997. | ml March 1997. | |||
| [3GPPIMEI] 3rd Generation Partnership Project; Technical | [3GPPIMEI] 3rd Generation Partnership Project; Technical | |||
| Specification Group Core Network, Numbering, addressing | Specification Group Core Network, Numbering, addressing | |||
| and identification, (release 5), 3GPP TS 23.003 | and identification, (release 5), 3GPP TS 23.003 | |||
| v. 5.8.0, 2003-12 | v. 5.8.0, 2003-12 | |||
| 15.2 Non-Normative | 15.2 Non-Normative | |||
| [RFC2866] C. Rigney. "Radius Accounting", RFC 2866, June 2000 | [RFC2866] C. Rigney. "Radius Accounting", RFC 2866, June 2000 | |||
| [DIAMMIP] P. Calhoun, T. Johansson, C. Perkins "Diameter Mobile IP | [DIAMMIP] P. Calhoun, T. Johansson, C. Perkins "Diameter Mobile IP | |||
| Application", IETF work in progress. | Application", IETF work in progress. | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson. "Remote | [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson. "Remote | |||
| Authentication Dial In User Service (RADIUS), RFC 2865, | Authentication Dial In User Service (RADIUS), RFC 2865, | |||
| June 2000 | June 2000 | |||
| [DIAMEAP] P. Eronen, T. Hiller, G. Zorn. "Diameter Extensible | [DIAMEAP] P. Eronen, T. Hiller, G. Zorn. "Diameter Extensible | |||
| Authentication Protocol (EAP) Application", IETF work in | Authentication Protocol (EAP) Application", IETF work in | |||
| progress. | progress. | |||
| 16. Acknowledgement | [RFC3725] J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo, | |||
| "Best Current Practices for Third Party Call Control | ||||
| (3pcc) in the Session Initiation Protocol (SIP)", RFC | ||||
| 3725, April 2004 | ||||
| 16. Acknowledgement | ||||
| The authors would like to thank Bernard Aboba, Jari Arkko, Robert | The authors would like to thank Bernard Aboba, Jari Arkko, Robert | |||
| Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, | Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, | |||
| Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, | Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, | |||
| Christopher Richards, Juha Vallinen and Mark Watson for their | Christopher Richards, Juha Vallinen and Mark Watson for their | |||
| comments and suggestions. | comments and suggestions. | |||
| Appendix A Credit Control sequences | Appendix A Credit Control sequences | |||
| A.1 Flow I | A.1 Flow I | |||
| End-User NAS AAA Server CC Server | End-User NAS AAA Server CC Server | |||
| (CC Client) | (CC Client) | |||
| |(1)User Logon |(2)AA Request (CC AVPs) | | |(1)User Logon |(2)AA Request (CC AVPs) | | |||
| |------------------>|------------------->| | | |------------------>|------------------->| | | |||
| | | |(3)CCR(initial, CC AVPs) | | | |(3)CCR(initial, CC | |||
| AVPs) | ||||
| | | |------------------->| | | | |------------------->| | |||
| | | | (4)CCA(granted Units) | | | | (4)CCA(granted Units) | |||
| | | |<-------------------| | | | |<-------------------| | |||
| | |(5)AA Answer(granted Units) | | | |(5)AA Answer(granted Units) | | |||
| |(6)Access granted |<-------------------| | | |(6)Access granted |<-------------------| | | |||
| |<----------------->| | | | |<----------------->| | | | |||
| | | | | | | | | | | |||
| : : : : | : : : : | |||
| | |(7)CCR(update,used Units) | | | |(7)CCR(update,used Units) | | |||
| | |------------------->|(8)CCR | | | |------------------->|(8)CCR | | |||
| (update,used units) | | | | (update,used units) | |||
| | | |------------------->| | | | |------------------->| | |||
| | | |(9)CCA(granted Units) | | | |(9)CCA(granted Units) | |||
| | |(10)CCA(granted Units)<------------------| | | |(10)CCA(granted Units)<------------------| | |||
| | |<-------------------| | | | |<-------------------| | | |||
| : : : : | : : : : | |||
| | (Auth. lifetime expires) | | | | (Auth. lifetime expires) | | | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | |(11) AAR (CC AVP) | | | | |(11) AAR (CC AVP) | | | |||
| | |------------------->| | | | |------------------->| | | |||
| | | (12) AAA | | | | | (12) AAA | | | |||
| | |<-------------------| | | | |<-------------------| | | |||
| : : : : | : : : : | |||
| : : : : | : : : : | |||
| |(13) User logoff | | | | |(13) User logoff | | | | |||
| |------------------>|(14)CCR(term.,used-Units) | | |------------------>|(14)CCR(term.,used-Units) | | |||
| | |------------------->|(15)CCR | | | |------------------->|(15)CCR | | |||
| | | | (term.,used-Units) | | | | (term.,used-Units) | |||
| skipping to change at page 90, line 28 ¶ | skipping to change at page 93, line 5 ¶ | |||
| | | | (16)CCA | | | | | (16)CCA | | |||
| | | (17)CCA |<-------------------| | | | (17)CCA |<-------------------| | |||
| | |<-------------------| | | | |<-------------------| | | |||
| | |(18)STR | | | | |(18)STR | | | |||
| | |------------------->| | | | |------------------->| | | |||
| | | (19)STA | | | | | (19)STA | | | |||
| | |<-------------------| | | | |<-------------------| | | |||
| Figure A.1: Flow I | Figure A.1: Flow I | |||
| A credit control flow for Network Access Services prepaid is shown in | A credit control flow for Network Access Services prepaid is shown | |||
| Figure A.1. The Diameter [NASREQ] is implemented in the Network | in Figure A.1. The Diameter [NASREQ] is implemented in the Network | |||
| Access Server (NAS). The focus of this flow is in the credit | Access Server (NAS). The focus of this flow is in the credit | |||
| authorization. | authorization. | |||
| The user logs onto the network (1). The Diameter NAS first sends a | The user logs onto the network (1). The Diameter NAS first sends a | |||
| Diameter Authorization-Authentication-Request to the home Diameter | Diameter Authorization-Authentication-Request to the home Diameter | |||
| AAA Server, the credit-control client populates the AAR with the | AAA Server, the credit-control client populates the AAR with the | |||
| Credit-Control AVP set to CREDIT_AUTHORIZATION and service specific | Credit-Control AVP set to CREDIT_AUTHORIZATION and service specific | |||
| AVPs are included as usual [NASREQ]. The home Diameter AAA server | AVPs are included as usual [NASREQ]. The home Diameter AAA server | |||
| performs service specific Authentication and Authorization as usual. | performs service specific Authentication and Authorization as | |||
| The home Diameter AAA server determines that the user is a prepaid | usual. The home Diameter AAA server determines that the user is a | |||
| user and notices from the Credit-Control AVP that the NAS has credit | prepaid user and notices from the Credit-Control AVP that the NAS | |||
| control capabilities, it sends a Diameter Credit-Control-Request | has credit control capabilities, it sends a Diameter Credit- | |||
| with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit- | Control-Request with CC-Request-Type set to INITIAL_REQUEST to the | |||
| control server to perform credit authorization (3) and to establish | Diameter credit-control server to perform credit authorization (3) | |||
| a credit control session (the home Diameter AAA server may forward | and to establish a credit control session (the home Diameter AAA | |||
| service specific AVPs as received from the NAS as input for the | server may forward service specific AVPs as received from the NAS | |||
| rating process). The Diameter credit-control server checks the end | as input for the rating process). The Diameter credit-control | |||
| user's account balance, rates the service and reserves credit from | server checks the end user's account balance, rates the service and | |||
| the end user's account. The reserved quota is returned to the home | reserves credit from the end user's account. The reserved quota is | |||
| Diameter AAA server in the Diameter Credit-Control-Answer (4). The | returned to the home Diameter AAA server in the Diameter Credit- | |||
| home Diameter AAA server sends the reserved quota to the NAS in the | Control-Answer (4). The home Diameter AAA server sends the reserved | |||
| Diameter Authorization-Authentication-Answer. Upon successful AAA | quota to the NAS in the Diameter Authorization-Authentication- | |||
| the NAS starts the credit-control session and starts monitoring the | Answer. Upon successful AAA the NAS starts the credit-control | |||
| granted units (5). The NAS grant access to the end user (6). At the | session and starts monitoring the granted units (5). The NAS grant | |||
| expiry of the allocated quota, the NAS sends a Diameter Credit- | access to the end user (6). At the expiry of the allocated quota, | |||
| Control-Request with CC-Request-Type set to UPDATE_REQUEST to the | the NAS sends a Diameter Credit-Control-Request with CC-Request- | |||
| Type set to UPDATE_REQUEST to the Home Diameter AAA server (7). | ||||
| Diameter Credit Control Application May 14, 2004 | This message contains the units used this far. The home Diameter | |||
| AAA server forwards the CCR to the Diameter credit-control server | ||||
| Home Diameter AAA server (7). This message contains the units used | (8). The Diameter credit-control server debits the used units from | |||
| this far. The home Diameter AAA server forwards the CCR to the | the end user's account and allocates a new quota that is returned | |||
| Diameter credit-control server (8). The Diameter credit-control | to the home Diameter AAA server in the Diameter Credit-Control- | |||
| server debits the used units from the end user's account and | Answer (9). The message is forwarded to the NAS (10). During the | |||
| allocates a new quota that is returned to the home Diameter AAA | ongoing credit-control session the authorization-lifetime expires, | |||
| server in the Diameter Credit-Control-Answer (9). The message is | the authorization/authentication client in the NAS performs service | |||
| forwarded to the NAS (10). During the ongoing credit-control session | specific re-authorization to the home Diameter AAA server as usual. | |||
| the authorization-lifetime expires, the authorization/authentication | The credit-control client populate the AAR with the Credit-Control | |||
| client in the NAS performs service specific re-authorization to the | AVP set to RE_AUTHORIZATION indicating that the credit-control | |||
| home Diameter AAA server as usual. The credit-control client | server shall not be contacted, since the credit authorization is | |||
| populate the AAR with the Credit-Control AVP set to RE_AUTHORIZATION | controlled by the burning rate of the granted units (11). The home | |||
| indicating that the credit-control server shall not be contacted, | Diameter AAA server performs service specific re-authorization as | |||
| since the credit authorization is controlled by the burning rate of | usual and returns the Authorization-Authentication-Answer to the | |||
| the granted units (11). The home Diameter AAA server performs | NAS (12). The end user logs off from the network (13). To debit the | |||
| service specific re-authorization as usual and returns the | used units from the end user's account and to stop the credit | |||
| Authorization-Authentication-Answer to the NAS (12). The end user | control session, the NAS sends a Diameter Credit-Control-Request | |||
| logs off from the network (13). To debit the used units from the end | with CC-Request-Type set to TERMINATION_REQUEST to the home | |||
| user's account and to stop the credit control session, the NAS sends | Diameter AAA server (14). The home Diameter AAA server forwards the | |||
| a Diameter Credit-Control-Request with CC-Request-Type set to | CCR to the credit-control server (15). The Diameter credit-control | |||
| TERMINATION_REQUEST to the home Diameter AAA server (14). The home | server acknowledges the session termination by sending a Diameter | |||
| Diameter AAA server forwards the CCR to the credit-control server | Credit-Control-Answer to the home Diameter AAA server (16). The | |||
| (15). The Diameter credit-control server acknowledges the session | home Diameter AAA server forwards the answer to the NAS (17). | |||
| termination by sending a Diameter Credit-Control-Answer to the home | STR/STA take place between NAS and home Diameter AAA server as | |||
| Diameter AAA server (16). The home Diameter AAA server forwards the | usual (18-19). | |||
| answer to the NAS (17). STR/STA take place between NAS and home | ||||
| Diameter AAA server as usual (18-19). | ||||
| A.2 Flow II | A.2 Flow II | |||
| SIP Proxy/Registrar AAA | SIP Proxy/Registrar AAA | |||
| A (CC Client) Server B CC Server | A (CC Client) Server B CC Server | |||
| |(i) REGISTER | | | | | |(i) REGISTER | | | | | |||
| |------------->|(ii) | | | | |------------->|(ii) | | | | |||
| | |------------->| | | | | |------------->| | | | |||
| | |authentication & | | | | |authentication & | | | |||
| | |authorization | | | | | |authorization | | | | |||
| skipping to change at page 92, line 4 ¶ | skipping to change at page 94, line 31 ¶ | |||
| |(iii)200 OK | | | | |(iii)200 OK | | | | |||
| |<-------------| | | | |<-------------| | | | |||
| : : : : | : : : : | |||
| |(1) INVITE | : | |(1) INVITE | : | |||
| |------------->| | |------------->| | |||
| | |(2) CCR (Intial, SIP specific AVP) | | | |(2) CCR (Intial, SIP specific AVP) | | |||
| | |------------------------------------------->| | | |------------------------------------------->| | |||
| | |(3) CCA (granted_Units) | | | |(3) CCA (granted_Units) | | |||
| | |<-------------------------------------------| | | |<-------------------------------------------| | |||
| | |(4) INVITE | | | | |(4) INVITE | | | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | |---------------------------->| | | | |---------------------------->| | | |||
| : : : : | : : : : | |||
| | |(5) CCR (update, used Units) | | | |(5) CCR (update, used Units) | | |||
| | |------------------------------------------->| | | |------------------------------------------->| | |||
| | |(6) CCA (granted_Units) | | | |(6) CCA (granted_Units) | | |||
| | |<-------------------------------------------| | | |<-------------------------------------------| | |||
| : : : : | : : : : | |||
| |(7) BYE | | | | |(7) BYE | | | | |||
| |------------->| | | | |------------->| | | | |||
| | |(8) BYE | | | | |(8) BYE | | | |||
| | |---------------------------->| | | | |---------------------------->| | | |||
| | |(9) CCR (termination, used Units)----------| | | |(9) CCR (termination, used Units)----------| | |||
| | |------------------------------------------->| | | |------------------------------------------->| | |||
| | |(10) CCA () | | | |(10) CCA () | | |||
| | |<-------------------------------------------| | | |<-------------------------------------------| | |||
| | | | | | | | | | | |||
| Figure A.2: Flow II | Figure A.2: Flow II | |||
| This is an example of Diameter Credit Control for SIP sessions. | ||||
| While the flow focuses on illustrating the usage of credit-control | ||||
| messages, the SIP signaling is inaccurate and the diagram is not by | ||||
| any means an attempt to define a service provider's SIP network. | ||||
| However, for the sake of this example some assumption is made as | ||||
| discussed in the next paragraph. | ||||
| Typically, prepaid services based e.g. on time usage for SIP session | ||||
| require an entity in the service provider network to intercept all | ||||
| the requests within the SIP dialog in order to detect events, such | ||||
| as session establishment and session release, which are essential to | ||||
| perform credit-control operations with the credit control server. It | ||||
| is, therefore, assumed in this example that the SIP Proxy record- | ||||
| route since the initial INVITE to make sure that all the future | ||||
| requests in the created dialog traverse through it. Finally, the | ||||
| degree of credit control measuring of the media by the proxy depends | ||||
| on the business model design used in setting up the end system and | ||||
| proxies in the SIP network | ||||
| The end user (SIP User Agent A) sends REGISTER with credentials (i). | The end user (SIP User Agent A) sends REGISTER with credentials (i). | |||
| The SIP Proxy sends a request to the home AAA server to perform | The SIP Proxy sends a request to the home AAA server to perform | |||
| Multimedia authentication and authorization by using for instance | Multimedia authentication and authorization by using for instance | |||
| Diameter Multimedia application (ii). The home AAA server checks that | Diameter Multimedia application (ii). The home AAA server checks | |||
| the credentials are correct and checks the user profile. Eventually, | that the credentials are correct and checks the user profile. | |||
| 200 OK response (iii) is sent to the UA. Note that the Authentication | Eventually, 200 OK response (iii) is sent to the UA. Note that the | |||
| and Authorization is valid for the registration validity period | Authentication and Authorization is valid for the registration | |||
| duration (i.e. until re-registration is performed), of several SIP | validity period duration (i.e. until re-registration is performed), | |||
| sessions may be established without re-authorization is performed. | of several SIP sessions may be established without re-authorization | |||
| is performed. | ||||
| UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- | UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- | |||
| Control-Request (INITIAL_REQUEST) to the Diameter credit-control | Control-Request (INITIAL_REQUEST) to the Diameter credit-control | |||
| server (2). The Credit-Control-Request contains information obtained | server (2). The Credit-Control-Request contains information obtained | |||
| from the SIP signaling describing the requested service (e.g. calling | from the SIP signaling describing the requested service (e.g. | |||
| party, called party, Session Description Protocol attributes). The | calling party, called party, Session Description Protocol | |||
| Diameter credit-control server checks the end user's account balance, | attributes). The Diameter credit-control server checks the end | |||
| rates the service and reserves credit from the end user's account. | user's account balance, rates the service and reserves credit from | |||
| The reserved quota is returned to the SIP Proxy in the Diameter | the end user's account. The reserved quota is returned to the SIP | |||
| Credit-Control-Answer (3). The SIP Proxy forwards the SIP INVITE to | Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy | |||
| UA B (4). B's phone rings, and B answers. The media flows between | forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. | |||
| them and the SIP Proxy starts measuring the quota. At the expiry of | The media flows between them and the SIP Proxy starts measuring the | |||
| the allocated quota, the SIP Proxy sends a Diameter Credit-Control- | quota. At the expiry of the allocated quota, the SIP Proxy sends a | |||
| Request (UPDATE_REQUEST) to the Diameter credit-control server (5). | Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter | |||
| This message contains the units used this far. The Diameter credit- | credit-control server (5). This message contains the units used this | |||
| control server debits the used units from the end user's account and | far. The Diameter credit-control server debits the used units from | |||
| allocates new credit that is returned to the SIP Proxy in the | the end user's account and allocates new credit that is returned to | |||
| Diameter Credit-Control-Answer (6). The end user terminates the | the SIP Proxy in the Diameter Credit-Control-Answer (6). The end | |||
| service by sending a BYE (7). The SIP Proxy forwards the BYE message | user terminates the service by sending a BYE (7). The SIP Proxy | |||
| to UA B (8) and sends a Diameter Credit-Control-Request | forwards the BYE message to UA B (8) and sends a Diameter Credit- | |||
| (TERMINATION_REQUEST) to the Credit-control server (9). The Diameter | Control-Request (TERMINATION_REQUEST) to the Credit-control server | |||
| (9). The Diameter Credit-control server acknowledges the session | ||||
| Diameter Credit Control Application May 14, 2004 | termination by sending a Diameter Credit-Control-Answer to the SIP | |||
| Proxy (10). | ||||
| Credit-control server acknowledges the session termination by sending | ||||
| a Diameter Credit-Control-Answer to the SIP Proxy (10). | ||||
| A.3 Flow III | A.3 Flow III | |||
| MMS Server | MMS Server | |||
| A (CC Client) B CC Server | A (CC Client) B CC Server | |||
| |(1) Send MMS | | | | |(1) Send MMS | | | | |||
| |--------------->| | | | |--------------->| | | | |||
| | |(2) CCR (event, DIRECT_DEBITING,| | | |(2) CCR (event, DIRECT_DEBITING,| | |||
| | | MMS specific AVP) | | | | MMS specific AVP) | | |||
| | |-------------------------------->| | | |-------------------------------->| | |||
| skipping to change at page 94, line 5 ¶ | skipping to change at page 97, line 9 ¶ | |||
| credit-control server checks the end user's account balance, rates | credit-control server checks the end user's account balance, rates | |||
| the service and debits the service from the end user's account. The | the service and debits the service from the end user's account. The | |||
| granted quota is returned to the MMS Server in the Diameter Credit- | granted quota is returned to the MMS Server in the Diameter Credit- | |||
| Control-Answer (3). The MMS Server acknowledges the successful | Control-Answer (3). The MMS Server acknowledges the successful | |||
| reception of the MMS message (4). The MMS Server notifies the | reception of the MMS message (4). The MMS Server notifies the | |||
| recipient about the new MMS (5), and the end user B retrieves the | recipient about the new MMS (5), and the end user B retrieves the | |||
| message from the MMS message store (6),(7). | message from the MMS message store (6),(7). | |||
| A.4 Flow IV | A.4 Flow IV | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| MMS Server | MMS Server | |||
| Content Server (CC Client) B CC Server | Content Server (CC Client) B CC Server | |||
| |(1) Send MMS | | | | |(1) Send MMS | | | | |||
| |--------------->| | | | |--------------->| | | | |||
| | |(2) CCR (event, BALANCE_CHECK, | | | |(2) CCR (event, BALANCE_CHECK, | | |||
| | | MMS specific AVP) | | | | MMS specific AVP) | | |||
| | |-------------------------------->| | | |-------------------------------->| | |||
| | |(3) CCA (ENOUGH_CREDIT) | | | |(3) CCA (ENOUGH_CREDIT) | | |||
| | |<--------------------------------| | | |<--------------------------------| | |||
| |(4) Send MMS Ack| | | | |(4) Send MMS Ack| | | | |||
| skipping to change at page 94, line 35 ¶ | skipping to change at page 97, line 37 ¶ | |||
| | |-------------------------------->| | | |-------------------------------->| | |||
| | |(8) CCA (granted_Units) | | | |(8) CCA (granted_Units) | | |||
| | |<--------------------------------| | | |<--------------------------------| | |||
| | |(9) Retrieve MMS| | | | |(9) Retrieve MMS| | | |||
| | | Ack | | | | | Ack | | | |||
| | |--------------->| | | | |--------------->| | | |||
| | | | | | | | | | | |||
| Figure A.4: Flow IV | Figure A.4: Flow IV | |||
| This is an example of Diameter Credit Control for Direct Debiting | ||||
| using Multimedia Messaging Service environment. While the flow | ||||
| focuses on illustrating the usage of credit-control messages, the | ||||
| MMS signaling is inaccurate and the diagram is not by any means an | ||||
| attempt to define any service provider's MMS configuration or | ||||
| billing model. | ||||
| A credit control flow for Multimedia Messaging Service is shown in | A credit control flow for Multimedia Messaging Service is shown in | |||
| Figure A.4. The recipient is charged at the message delivery. | Figure A.4. The recipient is charged at the message delivery. | |||
| A Content Server sends a Multimedia Message (MMS) to the MMS Server | A Content Server sends a Multimedia Message (MMS) to the MMS Server | |||
| (1) that stores the message. The message recipient will be charged | (1) that stores the message. The message recipient will be charged | |||
| for the MMS message in this case. Since there can be substantially | for the MMS message in this case. Since there can be substantially | |||
| long time between the reception of the message at the MMS Server and | long time between the reception of the message at the MMS Server and | |||
| the actual retrieval of the message, the MMS Server does not | the actual retrieval of the message, the MMS Server does not | |||
| establish any credit control session to the Diameter Credit-Control | establish any credit control session to the Diameter Credit-Control | |||
| Server but performs first only a balance check (without any credit | Server but performs first only a balance check (without any credit | |||
| reservation) by sending a Diameter Credit-Control-Request | reservation) by sending a Diameter Credit-Control-Request | |||
| (EVENT_REQUEST with Requested-Action: BALANCE_CHECK) to verify that | (EVENT_REQUEST with Requested-Action: BALANCE_CHECK) to verify that | |||
| the end user B's can cover the cost for the MMS (2). The Diameter | the end user B's can cover the cost for the MMS (2). The Diameter | |||
| credit-control server checks the end user's account balance and | credit-control server checks the end user's account balance and | |||
| returns the answer to the MMS Server in the Diameter Credit-Control- | returns the answer to the MMS Server in the Diameter Credit-Control- | |||
| Answer (3). The MMS Server acknowledges the successful reception of | Answer (3). The MMS Server acknowledges the successful reception of | |||
| the MMS message (4). The MMS Server notifies the recipient about the | the MMS message (4). The MMS Server notifies the recipient about the | |||
| new MMS (5), and after some time the end user B retrieves the message | new MMS (5), and after some time the end user B retrieves the | |||
| from the MMS message store (6). The MMS Server sends a Diameter | message from the MMS message store (6). The MMS Server sends a | |||
| Credit-Control-Request (EVENT_REQUEST with Requested-Action: | Diameter Credit-Control-Request (EVENT_REQUEST with Requested- | |||
| Action: DIRECT_DEBITING) to the Diameter Credit-control server (7). | ||||
| Diameter Credit Control Application May 14, 2004 | The Credit-Control-Request contains information about the MMS | |||
| message (e.g. size, recipient address, coding type). The Diameter | ||||
| DIRECT_DEBITING) to the Diameter Credit-control server (7). The | credit-control server checks the end user's account balance, rates | |||
| Credit-Control-Request contains information about the MMS message | the service and debits the service from the end user's account. The | |||
| (e.g. size, recipient address, coding type). The Diameter credit- | ||||
| control server checks the end user's account balance, rates the | ||||
| service and debits the service from the end user's account. The | ||||
| granted quota is returned to the MMS Server in the Diameter Credit- | granted quota is returned to the MMS Server in the Diameter Credit- | |||
| Control-Request (8). The MMS is transferred to the end user B (9). | Control-Request (8). The MMS is transferred to the end user B (9). | |||
| Note that the transfer of the MMS message can take an extended time, | ||||
| and can fail, in which case a recovery action is needed. The MMS | ||||
| Server should return the already debited units to the user's account | ||||
| by using the REFUND action described in section 6.4. | ||||
| A.5 Flow V | A.5 Flow V | |||
| SIP Controller | SIP Controller | |||
| A (CC Client) B CC Server | A (CC Client) B CC Server | |||
| |(1)INVITE(SDP) | | | | |(1)INVITE B(SDP)| | | | |||
| |--------------->| | | | |--------------->| | | | |||
| | |(2) CCR (event, PRICE_ENQUIRY, | | | |(2) CCR (event, PRICE_ENQUIRY, | | |||
| | | SIP specific AVPs) | | | | SIP specific AVPs) | | |||
| | |-------------------------------->| | | |-------------------------------->| | |||
| | |(3) CCA (Cost-Information) | | | |(3) CCA (Cost-Information) | | |||
| | |<--------------------------------| | | |<--------------------------------| | |||
| | (4)MESSAGE(URL)| | | | | (4)MESSAGE(URL)| | | | |||
| |<---------------| | | | |<---------------| | | | |||
| |(5)HTTP GET | | | | |(5)HTTP GET | | | | |||
| |--------------->| | | | |--------------->| | | | |||
| |(6)HTTP POST | | | | |(6)HTTP POST | | | | |||
| |--------------->|(7)INVITE(SDP) | | | |--------------->|(7)INVITE(SDP) | | | |||
| | |--------------->| | | | |--------------->| | | |||
| | | (8)200 OK | | | | | (8)200 OK | | | |||
| | (9)200 OK |<---------------| | | | (9)200 OK |<---------------| | | |||
| |<---------------| | | | |<---------------| | | | |||
| Figure A.5: Flow V | Figure A.5: Flow V | |||
| This is an example of Diameter Credit Control for SIP sessions. | ||||
| While the flow focuses on illustrating the usage of credit-control | ||||
| messages, the SIP signaling is inaccurate and the diagram is not by | ||||
| any means an attempt to define a service provider's SIP network. | ||||
| Figure A.5 is an example of Advice of Charge (AoC) service for SIP | Figure A.5 is an example of Advice of Charge (AoC) service for SIP | |||
| call, the user A can be either postpaid or prepaid subscriber using | call, the user A can be either postpaid or prepaid subscriber using | |||
| the AoC service. It is assumed that the SIP Controller also has HTTP | the AoC service. It is assumed that the SIP Controller also has HTTP | |||
| capabilities and delivers an interactive AoC web page with for | capabilities and delivers an interactive AoC web page with for | |||
| instance the cost information, the details of the call derived from | instance the cost information, the details of the call derived from | |||
| the SDP and a button to accept/not accept the charges (there may be | the SDP and a button to accept/not accept the charges (there may be | |||
| many other ways to deliver AoC information, however, this flow focus | many other ways to deliver AoC information, however, this flow focus | |||
| on the use of the credit control messages). The user has been | on the use of the credit control messages). The user has been | |||
| authenticated and authorized prior to initiate the call and | authenticated and authorized prior to initiate the call and | |||
| subscribed to AoC service. | subscribed to AoC service. | |||
| UA A sends an INVITE with SDP (1). The SIP controller determines the | UA A sends an INVITE with SDP to B (1). The SIP controller | |||
| user is subscribed to AoC service and sends a Diameter Credit- | determines the user is subscribed to AoC service and sends a | |||
| Control-Request (EVENT_REQUEST with Requested-Action: PRICE_ENQUIRY) | Diameter Credit-Control-Request (EVENT_REQUEST with Requested- | |||
| to the Diameter credit control server (2). The Credit-Control-Request | Action: PRICE_ENQUIRY) to the Diameter credit control server (2). | |||
| contains SIP specific AVPs derived from the SIP signaling describing | The Credit-Control-Request contains SIP specific AVPs derived from | |||
| the requested service (e.g. calling party, called party, Session | the SIP signaling describing the requested service (e.g. calling | |||
| party, called party, Session Description Protocol attributes). The | ||||
| Diameter Credit Control Application May 14, 2004 | Diameter credit control server determines the cost of the service | |||
| and returns the Credit-Control-Answer including the Cost-Information | ||||
| Description Protocol attributes). The Diameter credit control server | AVP (3). The SIP controller manufactures the AoC web page with | |||
| determines the cost of the service and returns the Credit-Control- | information received in SIP signaling and with the cost information | |||
| Answer including the Cost-Information AVP (3). The SIP controller | received from the credit control server, then sends a SIP MESSAGE | |||
| manufactures the AoC web page with information received in SIP | that contains a URL pointing to the AoC information web page (4). At | |||
| signaling and with the cost information received from the credit | the reception of the SIP MESSAGE the A's UA invokes automatically | |||
| control server, then sends a SIP MESSAGE that contains a URL pointing | the web browser that retrieves the AoC information (5). The user | |||
| to the AoC information web page (4). At the reception of the SIP | clicks on a proper button and accept the charges (6). The SIP | |||
| MESSAGE the A's UA invokes automatically the web browser that | controller continues the session and sends the INVITE to the B party | |||
| retrieves the AoC information (5). The user clicks on a proper button | that accepts the call (7,8,9). | |||
| and accept the charges (6). The SIP controller continues the session | ||||
| and sends the INVITE to the B party that accepts the call (7,8,9). | ||||
| A.6 Flow VI | A.6 Flow VI | |||
| Gaming Server | Gaming Server | |||
| End-User (CC Client) CC Server | End-User (CC Client) CC Server | |||
| | (1)Service Delivery | | | | (1)Service Delivery | | | |||
| |<---------------------->| | | |<---------------------->| | | |||
| : : : | : : : | |||
| : : : | : : : | |||
| | |(2)CCR(event,REFUND,Requested- | | |(2)CCR(event,REFUND,Requested- | |||
| | |Service-Unit,Service-Parameter-Info) | | |Service-Unit,Service-Parameter-Info) | |||
| | |----------------------->| | | |----------------------->| | |||
| | | (3)CCA(Cost-Information) | | | (3)CCA(Cost-Information) | |||
| | |<-----------------------| | | |<-----------------------| | |||
| | (4)Notification | | | | (4)Notification | | | |||
| |<-----------------------| | | |<-----------------------| | | |||
| Figure A.6: Flow VI | Figure A.6: Flow VI | |||
| Figure A.6 illustrates a credit control flow for the REFUND case. It | Figure A.6 illustrates a credit control flow for the REFUND case. It | |||
| is assumed that trusted relationship and secure connection between | is assumed that trusted relationship and secure connection between | |||
| the Gaming server and the Diameter credit control server exist. The | the Gaming server and the Diameter credit control server exist. The | |||
| end user may be a prepaid subscriber or a postpaid subscriber. | end user may be a prepaid subscriber or a postpaid subscriber. | |||
| While the end user is playing the game (1) she enters a new level | While the end user is playing the game (1) she enters a new level | |||
| that entitles for a bonus. The Gaming server sends a Diameter Credit- | that entitles for a bonus. The Gaming server sends a Diameter | |||
| Conrol-Request (EVENT_REQUEST with Requested-Action: REFUND) to the | Credit-Control-Request (EVENT_REQUEST with Requested-Action: REFUND) | |||
| Diameter credit control server (2). The Credit-Control-Request | to the Diameter credit control server (2). The Credit-Control- | |||
| contains the Requested-Service-Unit AVP with Unit-Type set to | Request contains the Requested-Service-Unit AVP with Unit-Type set | |||
| CREDIT_TYPE_SERVICE_SPECIFIC with the CC-Service-Specific-Units | to CREDIT_TYPE_SERVICE_SPECIFIC with the CC-Service-Specific-Units | |||
| containing the number of points the user just won. The Service- | containing the number of points the user just won. The Service- | |||
| Parameter-Info AVP is also included in the request and specifies the | Parameter-Info AVP is also included in the request and specifies the | |||
| service event to be rated (e.g. Tetris Bonus). The Diameter credit | service event to be rated (e.g. Tetris Bonus). The Diameter credit | |||
| control server, based on received information, determines the amount | control server, based on received information, determines the amount | |||
| to be credited, refunds the user's account and returns the Credit- | to be credited, refunds the user's account and returns the Credit- | |||
| Control-Answer including the Cost-Information AVP (3). The Cost- | Control-Answer including the Cost-Information AVP (3). The Cost- | |||
| Information indicates the credited amount. At the first opportunity | Information indicates the credited amount. At the first opportunity | |||
| the Gaming server notify the end user of the credited amount (4). | the Gaming server notify the end user of the credited amount (4). | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| A.7 Flow VII | A.7 Flow VII | |||
| SIP Controller Top-UP | SIP Controller Top-UP | |||
| A (CC Client) Server B CC Server | A (CC Client) Server B CC | |||
| Server | ||||
| | | | | | | | | | | | | |||
| | | (1) CCR(Update,Used-Unit) | | | | | (1) CCR(Update,Used-Unit) | | | |||
| | |------------------------------------------>| | | |------------------------------------------>| | |||
| | | (2) CCA(Final-Unit, Redirect)| | | | (2) CCA(Final-Unit, Redirect)| | |||
| | |<------------------------------------------| | | |<------------------------------------------| | |||
| : : : : : | : : : : : | |||
| : : : : : | : : : : : | |||
| | | (3) CCR(Update, Used-Units)| | | | | (3) CCR(Update, Used-Units)| | | |||
| | |------------------------------------------>| | | |------------------------------------------>| | |||
| | | (3a)INVITE("hold") | | | | | (3a)INVITE("hold") | | | |||
| skipping to change at page 97, line 39 ¶ | skipping to change at page 101, line 17 ¶ | |||
| | |<-------------| | | | | |<-------------| | | | |||
| | | (9)CCR(Update) | | | | | (9)CCR(Update) | | | |||
| | |------------------------------------------>| | | |------------------------------------------>| | |||
| | | (10)CCA(Granted-Unit) | | | | (10)CCA(Granted-Unit) | | |||
| | |<------------------------------------------| | | |<------------------------------------------| | |||
| | (12)INVITE | (11)INVITE | | | | (12)INVITE | (11)INVITE | | | |||
| |<--------------|--------------------------->| | | |<--------------|--------------------------->| | | |||
| Figure A.7: Flow VII | Figure A.7: Flow VII | |||
| Figure A.7 is an example of the graceful service termination for a | Figure A.7 is an example of the graceful service termination for a | |||
| SIP call. It is assumed the call is set up so that the controller is | SIP call. It is assumed the call is set up so that the controller is | |||
| in the call as a B2BUA (Back to Back User Agent). Note that the SIP | in the call as a B2BUA (Back to Back User Agent) performing third | |||
| signaling is inaccurate since the focus of this flow is in the | party call control (3PCC). Note that the SIP signaling is inaccurate | |||
| graceful service termination and credit control authorization. | since the focus of this flow is in the graceful service termination | |||
| and credit control authorization, best practice for 3PCC are defined | ||||
| in [RFC3725]. | ||||
| The call is ongoing between user A and user B, user A is a prepaid | The call is ongoing between user A and user B, user A is a prepaid | |||
| user. At the expiry of the allocated quota, the SIP controller sends | user. At the expiry of the allocated quota, the SIP controller sends | |||
| a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter | a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter | |||
| credit control server (1). This message contains the units used this | credit control server (1). This message contains the units used this | |||
| far. The Diameter credit control server debits the used units from | far. The Diameter credit control server debits the used units from | |||
| the end user's account and allocates the final quota that is returned | the end user's account and allocates the final quota that is | |||
| to the SIP controller in the Diameter Credit-Control-Answer (2). This | returned to the SIP controller in the Diameter Credit-Control-Answer | |||
| message contains the Final-Unit-Indication AVP with: the Final-Unit- | (2). This message contains the Final-Unit-Indication AVP with: the | |||
| Action set to REDIRECT, the Redirect-Address-Type set to SIP URI and | Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to | |||
| SIP URI and the Redirect-Server-Address set to the Top-up server | ||||
| Diameter Credit Control Application May 14, 2004 | name (e.g. sip:sip-topup-server@domain.com). At the expiry of the | |||
| final allocated quota, the SIP controller sends a Diameter Credit- | ||||
| the Redirect-Server-Address set to the Top-up server name (e.g. | Control-Request (UPDATE_REQUEST) to the Diameter credit control | |||
| sip:sip-topup-server@domain.com). At the expiry of the final | server (3) and places the called party on "hold" by sending an | |||
| allocated quota, the SIP controller sends a Diameter Credit-Control- | INVITE with the appropriate connection address in the SDP (3a). The | |||
| Request (UPDATE_REQUEST) to the Diameter credit control server (3) | Credit-Control-Request message contains the units used this far. The | |||
| and places the called party on "hold" by sending an INVITE with the | Diameter credit control server debits the used units from the end | |||
| appropriate connection address in the SDP (3a). The Credit-Control- | user's account but does not make any credit reservation. The Credit- | |||
| Request message contains the units used this far. The Diameter credit | Control-Answer message, that contains the Validity-Time to supervise | |||
| control server debits the used units from the end user's account but | the graceful service termination, is returned to the SIP controller | |||
| does not make any credit reservation. The Credit-Control-Answer | (4). The SIP controller establishes a SIP session between the | |||
| message, that contains the Validity-Time to supervise the graceful | prepaid user and the Top-up server (5, 6). The Top-up server plays | |||
| service termination, is returned to the SIP controller (4). The SIP | an announcement and prompts the user to enter a credit card number | |||
| controller establishes a SIP session between the prepaid user and the | and the amount of money to be used to replenish the account (7). The | |||
| Top-up server (5, 6). The Top-up server plays an announcement and | Top-up server validates the credit card number and replenishes the | |||
| prompts the user to enter a credit card number and the amount of | user's account (using some means outside the scope of this | |||
| money to be used to replenish the account (7). The Top-up server | specification) and releases the SIP session (8). The SIP controller | |||
| validates the credit card number and replenishes the user's account | can now assume that communication between the prepaid user and the | |||
| (using some means outside the scope of this specification) and | Top-up server took place and thus sends a spontaneous Credit- | |||
| releases the SIP session (8). The SIP controller can now assume that | Control-Request (UPDATE_REQUEST) to the Diameter credit control | |||
| communication between the prepaid user and the Top-up server took | server to check if the account has been replenished (9). The | |||
| place and thus sends a spontaneous Credit-Control-Request | Diameter credit control server reserves credit from the end user's | |||
| (UPDATE_REQUEST) to the Diameter credit control server to check if | account and return the reserved quota to the SIP controller in the | |||
| the account has been replenished (9). The Diameter credit control | Credit-Control-Answer (10). At this point, the SIP controller re- | |||
| server reserves credit from the end user's account and return the | connects the caller and the called party (11,12). | |||
| reserved quota to the SIP controller in the Credit-Control-Answer | ||||
| (10). At this point, the SIP controller re-connects the caller and | ||||
| the called party (11,12). | ||||
| A.8 Flow VIII | A.8 Flow VIII | |||
| End-User NAS AAA Server Top-up CC Server | End-User NAS AAA Server Top-up CC | |||
| Server | ||||
| (CC Client) Server | (CC Client) Server | |||
| |(1)User Logon |(2)AA Request (CC AVPs) | | | |(1)User Logon |(2)AA Request (CC AVPs) | | | |||
| |------------------>|------------------->| | | | |------------------>|------------------->| | | | |||
| | | |(3)CCR(initial, CC AVPs) | | | |(3)CCR(initial, CC | |||
| AVPs) | ||||
| | | |------------------->| | | | |------------------->| | |||
| | | |(4)CCA(Final-Unit, | | | | |(4)CCA(Final-Unit, | | |||
| | | | Validity-Time)| | | | | Validity-Time)| | |||
| | | |<-------------------| | | | |<-------------------| | |||
| | |(5)AA Answer(Final-Unit,Validity-Time) | | | |(5)AA Answer(Final-Unit,Validity-Time) | | |||
| |(6)Limited Access |<-------------------| | | | |(6)Limited Access |<-------------------| | | | |||
| | granted | | | | | | granted | | | | | |||
| |<----------------->| | | | | |<----------------->| | | | | |||
| | | | | | | | | | | | | |||
| | (7)TCP/HTTP | (8)TCP/HTTP | | | | (7)TCP/HTTP | (8)TCP/HTTP | | | |||
| |<----------------->|<----------------------------->| | | |<----------------->|<----------------------------->| | | |||
| | (9) Replenish account | | | | (9) Replenish account | | | |||
| |<------------------------------------------------->| | | |<------------------------------------------------->| | | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | | | (10)RAR | | | | | (10)RAR | | |||
| | |<-------------------|<-------------------| | | |<-------------------|<-------------------| | |||
| | | (11) RAA | | | | | (11) RAA | | | |||
| | |------------------->|------------------->| | | |------------------->|------------------->| | |||
| | |(12)CCR(update) | | | | |(12)CCR(update) | | | |||
| | |------------------->|(13)CCR(Update) | | | |------------------->|(13)CCR(Update) | | |||
| | | |------------------->| | | | |------------------->| | |||
| | | |(14)CCA(granted Units) | | | |(14)CCA(granted Units) | |||
| | |(15)CCA(granted Units)<------------------| | | |(15)CCA(granted Units)<------------------| | |||
| | |<-------------------| | | | |<-------------------| | | |||
| Figure A.8: Flow VIII | Figure A.8: Flow VIII | |||
| Figure A.8 is an example of the graceful service termination | Figure A.8 is an example of the graceful service termination | |||
| initiated when the first interrogation take place due to user's | initiated when the first interrogation take place due to user's | |||
| account is empty. In this example the credit control server supports | account is empty. In this example the credit control server | |||
| the server initiated credit re-authorization. The Diameter [NASREQ] | supports the server initiated credit re-authorization. The Diameter | |||
| is implemented in the Network Access Server (NAS). | [NASREQ] is implemented in the Network Access Server (NAS). | |||
| The user logs onto the network (1). The Diameter NAS first sends a | The user logs onto the network (1). The Diameter NAS first sends a | |||
| Diameter Authorization-Authentication-Request to the home Diameter | Diameter Authorization-Authentication-Request to the home Diameter | |||
| AAA Server, the credit-control client populates the AAR with the | AAA Server, the credit-control client populates the AAR with the | |||
| Credit-Control AVP set to CREDIT_AUTHORIZATION and service specific | Credit-Control AVP set to CREDIT_AUTHORIZATION and service specific | |||
| AVPs are included as usual [NASREQ]. The home Diameter AAA server | AVPs are included as usual [NASREQ]. The home Diameter AAA server | |||
| performs service specific Authentication and Authorization as usual. | performs service specific Authentication and Authorization as usual. | |||
| The home Diameter AAA server determines that the user is a prepaid | The home Diameter AAA server determines that the user is a prepaid | |||
| user and notices from the Credit-Control AVP that the NAS has credit | user and notices from the Credit-Control AVP that the NAS has credit | |||
| control capabilities, it sends a Diameter Credit-Control-Request with | control capabilities, it sends a Diameter Credit-Control-Request | |||
| CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control | with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit- | |||
| server to perform credit authorization (3) and to establish a credit | control server to perform credit authorization (3) and to establish | |||
| control session (the home Diameter AAA server may forward service | a credit control session (the home Diameter AAA server may forward | |||
| specific AVPs as received from the NAS as input for the rating | service specific AVPs as received from the NAS as input for the | |||
| process). The Diameter credit-control server checks the end user's | rating process). The Diameter credit-control server checks the end | |||
| account balance, determines that the account cannot cover the cost of | user's account balance, determines that the account cannot cover the | |||
| the sevice and initiates the graceful service termination. The | cost of the service and initiates the graceful service termination. | |||
| Credit-Control-Answer is returned to the home Diameter AAA server | The Credit-Control-Answer is returned to the home Diameter AAA | |||
| (4). This message contains the Final-Unit-Indication AVP and the | server (4). This message contains the Final-Unit-Indication AVP and | |||
| Validity-Time AVP set to a reasonable time to give chance to the user | the Validity-Time AVP set to a reasonable time to give chance to the | |||
| to replenish his/her account (e.g. 10 minutes). The Final-Unit- | user to replenish his/her account (e.g. 10 minutes). The Final-Unit- | |||
| Indication AVP includes: the Final-Unit-Actioin set to REDIRECT, the | Indication AVP includes: the Final-Unit-Action set to REDIRECT, the | |||
| Redirect-Address-Type set to ULR and the Redirect-Server-Address set | Redirect-Address-Type set to URL and the Redirect-Server-Address set | |||
| to the HTTP Top-up server name. The home Diameter AAA server sends | to the HTTP Top-up server name. The home Diameter AAA server sends | |||
| the received credit control AVPs to the NAS in the Diameter | the received credit control AVPs to the NAS in the Diameter | |||
| Authorization-Authentication-Answer (5). Upon successful AAA the NAS | Authorization-Authentication-Answer (5). Upon successful AAA the NAS | |||
| starts the credit-control session and starts immediately the graceful | starts the credit-control session and starts immediately the | |||
| service termination as instructed by the server. The NAS grant | graceful service termination as instructed by the server. The NAS | |||
| limited access to the user (6). The HTTP client software running in | grant limited access to the user (6). The HTTP client software | |||
| the user's device opens the transport connection that is redirected | running in the user's device opens the transport connection that is | |||
| by the NAS to the Top-up server (7,8). The user is displayed an | redirected by the NAS to the Top-up server (7,8). The user is | |||
| displayed an appropriate web page where to enter the credit card | ||||
| Diameter Credit Control Application May 14, 2004 | number, the amount of money to be used to replenish the account and | |||
| with a notification message that she will be granted unlimited | ||||
| appropriate web page where to enter the credit card number, the | access if the replenishment operation will be successfully executed | |||
| amount of money to be used to replenish the account and with a | within the next e.g. 10 minutes. The Top-up server validates the | |||
| notification message that she will be granted unlimited access if the | credit card number and replenishes the user's account (using some | |||
| replenishment operation will be successfully executed within the next | means outside the scope of this specification)(9). After successful | |||
| e.g. 10 minutes. The Top-up server validates the credit card number | account top-up the credit control server sends a Re-Auth-Request | |||
| and replenishes the user's account (using some means outside the | message to the NAS (10). The NAS acknowledges the request by | |||
| scope of this specification)(9). After successful account top-up the | returning the Re-Auth-Answer message (11) and initiates the credit | |||
| credit control server sends a Re-Auth-Request message to the NAS | re-authorization by sending a Credit-Control-request | |||
| (10). The NAS acknowledges the request by returning the Re-Auth- | (UPDATE_REQUEST) to the Diameter credit control server (12,13). | |||
| Answer message (11) and initiates the credit re-authorization by | ||||
| sending a Credit-Control-request (UPDATE_REQUEST) to the Diameter | ||||
| credit control server (12,13). | ||||
| The Diameter credit control server reserves credit from the end | The Diameter credit control server reserves credit from the end | |||
| user's account and return the reserved quota to the NAS via the home | user's account and return the reserved quota to the NAS via the home | |||
| Diameter AAA server in the Credit-Control-Answer (14,15). The NAS | Diameter AAA server in the Credit-Control-Answer (14,15). The NAS | |||
| removes the restriction placed by the graceful service termination | removes the restriction placed by the graceful service termination | |||
| and starts monitoring the granted units. | and starts monitoring the granted units. | |||
| A.9 Flow IX | A.9 Flow IX | |||
| The Diameter Credit Control Application defines the Multiple- | The Diameter Credit Control Application defines the Multiple- | |||
| Services-Credit-Control AVP that can be used to support independent | Services-Credit-Control AVP that can be used to support independent | |||
| credit control of multiple services in a single credit control (sub- | credit control of multiple services in a single credit control (sub- | |||
| )session for service elements that have such capabilities. | )session for service elements that have such capabilities. | |||
| It is possible to request and allocate resources as a credit | It is possible to request and allocate resources as a credit | |||
| pool that is shared between services or rating groups. | pool that is shared between services or rating groups. | |||
| The flow example hereafter illustrates a usage scenario where the | The flow example hereafter illustrates a usage scenario where the | |||
| Credit-control client and server support independent credit control | Credit-control client and server support independent credit control | |||
| of multiple services as defined in section 5.1.1. It is assumed that | of multiple services as defined in section 5.1.2. It is assumed | |||
| Service-Identifiers, Rating-Groups and their associated parameters | that Service-Identifiers, Rating-Groups and their associated | |||
| (e.g. IP 5-tuple) are locally configured in the Service Element or | parameters (e.g. IP 5-tuple) are locally configured in the Service | |||
| provisioned by another entity than the credit control server. | Element or provisioned by another entity than the credit control | |||
| server. | ||||
| End-User Service Element CC Server | End-User Service Element CC Server | |||
| (CC client) | (CC client) | |||
| |(1)User logon | | | |(1)User logon | | | |||
| |------------------>|(2)CCR(initial, Service-Id access, | | |------------------>|(2)CCR(initial, Service-Id access, | | |||
| | | Access specific AVPs, | | | | Access specific AVPs, | | |||
| | | Multiple-Service-Indicator) | | | | Multiple-Service-Indicator) | | |||
| | |---------------------------------------->| | | |---------------------------------------->| | |||
| | |(3)CCA(Multiple-Services-CC ( | | | |(3)CCA(Multiple-Services-CC ( | | |||
| | | Granted-Units(Total-Octets), | | | | Granted-Units(Total-Octets), | | |||
| | | Service-Id access, | | | | Service-Id access, | | |||
| | | Validity-time, | | | | Validity-time, | | |||
| | | G-S-U-Pool-Reference(Pool-Id 1, | | | | G-S-U-Pool-Reference(Pool-Id 1, | | |||
| | | Multiplier 10))) | | | | Multiplier 10))) | | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | |<----------------------------------------| | | |<----------------------------------------| | |||
| : : : | : : : | |||
| |(4)Service-Request (Service 1) | | |(4)Service-Request (Service 1) | | |||
| |------------------>|(5)CCR(update, Multiple-Services-CC( | | |------------------>|(5)CCR(update, Multiple-Services-CC( | | |||
| | | Requested-Units(), Service-Id 1, | | | | Requested-Units(), Service-Id 1, | | |||
| | | Rating-Group 1)) | | | | Rating-Group 1)) | | |||
| | |---------------------------------------->| | | |---------------------------------------->| | |||
| | |(6)CCA(Multiple-Services-CC ( | | | |(6)CCA(Multiple-Services-CC ( | | |||
| | | Granted-Units(Time), | | | | Granted-Units(Time), | | |||
| | | Rating-Group 1, | | | | Rating-Group 1, | | |||
| skipping to change at page 102, line 4 ¶ | skipping to change at page 105, line 36 ¶ | |||
| | |<----------------------------------------| | | |<----------------------------------------| | |||
| : : : | : : : | |||
| : : : | : : : | |||
| | +--------------+ | | | | +--------------+ | | | |||
| | |Validity time | |(11)CCR(update, | | | |Validity time | |(11)CCR(update, | | |||
| | |expires for | | Multiple-Services-CC ( | | | |expires for | | Multiple-Services-CC ( | | |||
| | |Service-Id | | Requested-Unit(), | | | |Service-Id | | Requested-Unit(), | | |||
| | | access | | Used-Units(In-Octets,Out-Octets),| | | | access | | Used-Units(In-Octets,Out-Octets),| | |||
| | +--------------+ | Service-Id access)) | | | +--------------+ | Service-Id access)) | | |||
| | |---------------------------------------->| | | |---------------------------------------->| | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| | |(12)CCA(Multiple-Services-CC ( | | | |(12)CCA(Multiple-Services-CC ( | | |||
| | | Granted-Units(Total-Octets), | | | | Granted-Units(Total-Octets), | | |||
| | | Service-Id access, | | | | Service-Id access, | | |||
| | | Validity-time, | | | | Validity-time, | | |||
| | | G-S-U-Pool-Reference(Pool-Id 1, | | | | G-S-U-Pool-Reference(Pool-Id 1, | | |||
| | | Multiplier 10))) | | | | Multiplier 10))) | | |||
| | |<----------------------------------------| | | |<----------------------------------------| | |||
| : : : | : : : | |||
| : : : | : : : | |||
| | +--------------+ | | | | +--------------+ | | | |||
| skipping to change at page 103, line 4 ¶ | skipping to change at page 106, line 34 ¶ | |||
| | |<----------------------------------------| | | |<----------------------------------------| | |||
| Figure A.9: Independent credit control of multiple services in a | Figure A.9: Independent credit control of multiple services in a | |||
| Credit Control (sub-)Session, flow example. | Credit Control (sub-)Session, flow example. | |||
| The user logs onto the network (1). The Service Element sends a | The user logs onto the network (1). The Service Element sends a | |||
| Diameter Credit-Control-Request with CC-Request-Type set to | Diameter Credit-Control-Request with CC-Request-Type set to | |||
| INITIAL_REQUEST to the Diameter credit-control server to perform | INITIAL_REQUEST to the Diameter credit-control server to perform | |||
| credit authorization for the bearer service (e.g. internet access | credit authorization for the bearer service (e.g. internet access | |||
| service) and to establish a credit control session (2). In this | service) and to establish a credit control session (2). In this | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| message the credit-control client indicates support for independent | message the credit-control client indicates support for independent | |||
| credit control of multiple services within the session by including | credit control of multiple services within the session by including | |||
| the Multiple-Service-Indicator AVP. The Diameter credit-control | the Multiple-Service-Indicator AVP. The Diameter credit-control | |||
| server checks the end user's account balance, based on the rating | server checks the end user's account balance, based on the rating | |||
| information received from the client (i.e. Service-Id and access | information received from the client (i.e. Service-Id and access | |||
| specific AVPs) rates the request and reserves credit from the end | specific AVPs) rates the request and reserves credit from the end | |||
| user's account. Say the server reserves $5 and determines the cost is | user's account. Say the server reserves $5 and determines the cost | |||
| $1/MB. It then returns to the service element a Credit-Control-Answer | is $1/MB. It then returns to the service element a Credit-Control- | |||
| message that include the Multiple-Services-Credit-Control AVP with a | Answer message that include the Multiple-Services-Credit-Control AVP | |||
| quota of 5MB associated to the Service-Id (access), to a multiplier | with a quota of 5MB associated to the Service-Id (access), to a | |||
| value of 10 and to the Pool-Id 1 (3). | multiplier value of 10 and to the Pool-Id 1 (3). | |||
| The user uses Service 1 (4). The service element sends a Diameter | The user uses Service 1 (4). The service element sends a Diameter | |||
| Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to | Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to | |||
| the credit control server to perform credit authorization for service | the credit control server to perform credit authorization for | |||
| 1 (5). This message includes the Multiple-Services-Credit-Control AVP | service 1 (5). This message includes the Multiple-Services-Credit- | |||
| to request service units for the Service 1 that belong to Rating- | Control AVP to request service units for the Service 1 that belong | |||
| Group 1. The Diameter credit-control server determines that Service 1 | to Rating-Group 1. The Diameter credit-control server determines | |||
| draws credit resources from the same account as the access service | that Service 1 draws credit resources from the same account as the | |||
| (i.e. pool 1), based on Service-Id/Rating-Group rates the request and | access service (i.e. pool 1), based on Service-Id/Rating-Group rates | |||
| updates the existing reservation by requesting more credit. Say the | the request and updates the existing reservation by requesting more | |||
| server reserves $5 more (now the reservation is $10) and determines | credit. Say the server reserves $5 more (now the reservation is $10) | |||
| the cost is $0.1/minutes. The server authorizes the whole Rating- | and determines the cost is $0.1/minutes. The server authorizes the | |||
| Group, it then returns to the service element a Credit-Control-Answer | whole Rating-Group, it then returns to the service element a Credit- | |||
| message that include the Multiple-Services-Credit-Control AVP with a | Control-Answer message that include the Multiple-Services-Credit- | |||
| quota of 50min. associated to the Rating-Group 1, to a multiplier | Control AVP with a quota of 50min. associated to the Rating-Group 1, | |||
| value of 1 and to the Pool-Id 1 (6). The client adjusts the total | to a multiplier value of 1 and to the Pool-Id 1 (6). The client | |||
| amount of resources for pool 1 according the received quota, which | adjusts the total amount of resources for pool 1 according the | |||
| gives M for Pool 1 = 100. | received quota, which gives S for Pool 1 = 100. | |||
| The user uses Service 2 that belongs to the authorized Rating-Group 1 | The user uses Service 2 that belongs to the authorized Rating-Group | |||
| (7). Resources are then consumed from the pool 1. | 1 (7). Resources are then consumed from the pool 1. | |||
| The user requests now Service 3 and Service 4 as well, that are not | The user requests now Service 3 and Service 4 as well, that are not | |||
| authorized (8). The service element sends a Diameter Credit-Control- | authorized (8). The service element sends a Diameter Credit-Control- | |||
| Request with CC-Request-Type set to UPDATE_REQUEST to the credit | Request with CC-Request-Type set to UPDATE_REQUEST to the credit | |||
| control server to perform credit authorization for service 3 and 4 | control server to perform credit authorization for service 3 and 4 | |||
| (9). This message includes two instances of the Multiple-Services- | (9). This message includes two instances of the Multiple-Services- | |||
| Credit-Control AVP to request service units for the Service 3 that | Credit-Control AVP to request service units for the Service 3 that | |||
| belong to Rating-Group 2 and for the Service 4 that belong to Rating- | belong to Rating-Group 2 and for the Service 4 that belong to | |||
| Group 3. The Diameter credit-control server determines that Service 3 | Rating-Group 3. The Diameter credit-control server determines that | |||
| and 4 draw credit resources from another account (i.e. pool 2), it | Service 3 and 4 draw credit resources from another account (i.e. | |||
| checks the end user's account balance and based on Service- | pool 2), it checks the end user's account balance and based on | |||
| Ids/Rating-Groups information rates the request and reserve credit | Service-Ids/Rating-Groups information rates the request and reserve | |||
| from pool 2. | credit from pool 2. | |||
| For example, the server reserves $5 and determines that Service 3 | For example, the server reserves $5 and determines that Service 3 | |||
| costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes only | costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes | |||
| Services 3 and 4, it then returns to the service element a Credit- | only Services 3 and 4, it then returns to the service element a | |||
| Credit-Control-Answer message that include two instances of the | ||||
| Diameter Credit Control Application May 14, 2004 | Multiple-Services-Credit-Control AVP (10). One instance grants a | |||
| quota of 12.5MB associated to the Service-Id 3, to a multiplier | ||||
| Control-Answer message that include two instances of the Multiple- | value of 2 and to the Pool-Id 2. The other instance grants a quota | |||
| Services-Credit-Control AVP (10). One instance grants a quota of | of 5 MB associated to the Service-Id 4, to a multiplier value of 5 | |||
| 12.5MB associated to the Service-Id 3, to a multiplier value of 2 and | and to the Pool-Id 2. | |||
| to the Pool-Id 2. The other instance grants a quota of 5 MB | ||||
| associated to the Service-Id 4, to a multiplier value of 5 and to the | ||||
| Pool-Id 2. | ||||
| The server also determines that pool 2 is exhausted and Service 4 is | The server also determines that pool 2 is exhausted and Service 4 is | |||
| not allowed to continue after these units will be consumed. Therefore | not allowed to continue after these units will be consumed. | |||
| the Final-Unit-Indication AVP with action TERMINATE is associated to | Therefore the Final-Unit-Indication AVP with action TERMINATE is | |||
| the Service-Id 4. The client calculates the total amount of resources | associated to the Service-Id 4. The client calculates the total | |||
| that can be used for Pool 2 according the received quotas and | amount of resources that can be used for Pool 2 according the | |||
| multipliers, which give M for Pool 2 = 50. | received quotas and multipliers, which give S for Pool 2 = 50. | |||
| The Validity-Time for the access service expires. The service element | The Validity-Time for the access service expires. The service | |||
| sends a Credit-Control-Request message to the server to perform | element sends a Credit-Control-Request message to the server to | |||
| credit re-authorization for Service-Id (access) (11). This message | perform credit re-authorization for Service-Id (access) (11). This | |||
| carries one instance of the Multiple-Services-Credit-Control AVP that | message carries one instance of the Multiple-Services-Credit-Control | |||
| includes the units used by this service. Say the total amount of used | AVP that includes the units used by this service. Say the total | |||
| units is 4MB. The client adjusts the total amount of resources for | amount of used units is 4MB. The client adjusts the total amount of | |||
| Pool 1 accordingly, which gives M for Pool 1 = 60. | resources for Pool 1 accordingly, which gives S for Pool 1 = 60. | |||
| The server deducts $4 from the user's account and updates the | The server deducts $4 from the user's account and updates the | |||
| reservation by requesting more credit. Say the server reserves $5 | reservation by requesting more credit. Say the server reserves $5 | |||
| more (now the reservation is $11) and already knows the cost of the | more (now the reservation is $11) and already knows the cost of the | |||
| Service-Id (access) that is $1/MB. It then returns to the service | Service-Id (access) that is $1/MB. It then returns to the service | |||
| element a Credit-Control-Answer message that include the Multiple- | element a Credit-Control-Answer message that include the Multiple- | |||
| Services-Credit-Control AVP with a quota of 5 MB associated to the | Services-Credit-Control AVP with a quota of 5 MB associated to the | |||
| Service-Id (access), to a multiplier value of 10 and to the Pool-Id 1 | Service-Id (access), to a multiplier value of 10 and to the Pool-Id | |||
| (12). The client adjusts the total amount of resources for pool 1 | 1 (12). The client adjusts the total amount of resources for pool 1 | |||
| according the received quota, which gives M for Pool 1 = 110. | according the received quota, which gives S for Pool 1 = 110. | |||
| Services 3 and 4 consume the total amount of Pool 2 credit resources | Services 3 and 4 consume the total amount of Pool 2 credit resources | |||
| (i.e. C1*2 + C2*5 >= M). The service element immediately starts the | (i.e. C1*2 + C2*5 >= S). The service element immediately starts the | |||
| TERMINATE action concerning Service 4 and sends a Credit-Control- | TERMINATE action concerning Service 4 and sends a Credit-Control- | |||
| Request message with CC-Request-Type set to UPDATE_REQUEST to the | Request message with CC-Request-Type set to UPDATE_REQUEST to the | |||
| credit control server to perform credit re-authorization for Service | credit control server to perform credit re-authorization for Service | |||
| 3 (13). This message contains two instances of the Multiple-Services- | 3 (13). This message contains two instances of the Multiple- | |||
| Credit-Control AVP to report the units used by Service 3 and Service | Services-Credit-Control AVP to report the units used by Service 3 | |||
| 4. The server deducts the last $5 from the user's account (Pool 2) | and Service 4. The server deducts the last $5 from the user's | |||
| and returns the answer with Result-Code 4011 in the Multiple- | account (Pool 2) and returns the answer with Result-Code 4011 in the | |||
| Services-Credit-Control AVP to indicate that Service 3 can continue | Multiple-Services-Credit-Control AVP to indicate that Service 3 can | |||
| without credit control (14). | continue without credit control (14). | |||
| The end user logs off from the network (15). To debit the used units | The end user logs off from the network (15). To debit the used units | |||
| from the end user's account and to stop the credit control session, | from the end user's account and to stop the credit control session, | |||
| the service element sends a Diameter Credit-Control-Request with CC- | the service element sends a Diameter Credit-Control-Request with CC- | |||
| Request-Type set to TERMINATION_REQUEST to the credit control server | Request-Type set to TERMINATION_REQUEST to the credit control server | |||
| (16). This message contains the units consumed by each of the used | (16). This message contains the units consumed by each of the used | |||
| Diameter Credit Control Application May 14, 2004 | ||||
| services in multiple instances of the Multiple-Services-Credit- | services in multiple instances of the Multiple-Services-Credit- | |||
| Control AVP. The used units are associated with the relevant Service- | Control AVP. The used units are associated with the relevant | |||
| Identifier and Rating-Group. The Diameter credit-control server | Service-Identifier and Rating-Group. The Diameter credit-control | |||
| debits the used units to the user's account (Pool 1) and acknowledges | server debits the used units to the user's account (Pool 1) and | |||
| the session termination by sending a Diameter Credit-Control-Answer | acknowledges the session termination by sending a Diameter Credit- | |||
| to the service element (17). | Control-Answer to the service element (17). | |||
| Author's Address | Author's Address | |||
| Harri Hakala | Harri Hakala | |||
| Oy L M Ericsson Ab | Oy L M Ericsson Ab | |||
| Joukahaisenkatu 1 | Joukahaisenkatu 1 | |||
| 20520 Turku | 20520 Turku | |||
| Finland | Finland | |||
| Phone: +358 2 265 3722 | Phone: +358 2 265 3722 | |||
| EMail: Harri.Hakala@ericsson.com | EMail: Harri.Hakala@ericsson.com | |||
| skipping to change at page 106, line 5 ¶ | skipping to change at page 109, line 36 ¶ | |||
| Email: marco.stura@nokia.com | Email: marco.stura@nokia.com | |||
| John Loughney | John Loughney | |||
| Nokia Research Center | Nokia Research Center | |||
| Itamerenkatu 11-13 | Itamerenkatu 11-13 | |||
| 00180 Helsinki | 00180 Helsinki | |||
| Finland | Finland | |||
| Phone: +358 50 483 642 | Phone: +358 50 483 642 | |||
| Email: John.Loughney@nokia.com | Email: John.Loughney@nokia.com | |||
| Diameter Credit Control Application May 14, 2004 | Intellectual Property Statement | |||
| Intellectual Property Considerations | ||||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| intellectual property or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed | |||
| pertain to the implementation or use of the technology described in | to pertain to the implementation or use of the technology described | |||
| this document or the extent to which any license under such rights | in this document or the extent to which any license under such | |||
| might or might not be available; neither does it represent that it | rights might or might not be available; nor does it represent that | |||
| has made any effort to identify any such rights. Information on the | it has made any independent effort to identify any such rights. | |||
| IETF's procedures with respect to rights in standards-track and | Information on the procedures with respect to rights in RFC | |||
| standards-related documentation can be found in BCP-11. Copies of | documents can be found in BCP 78 and BCP 79. | |||
| claims of rights made available for publication and any assurances of | ||||
| licenses to be made available, or the result of an attempt made to | Copies of IPR disclosures made to the IETF Secretariat and any | |||
| obtain a general license or permission for the use of such | assurances of licenses to be made available, or the result of an | |||
| proprietary rights by implementers or users of this specification can | attempt made to obtain a general license or permission for the use | |||
| be obtained from the IETF Secretariat. | of such proprietary rights by implementers or users of this | |||
| specification can be obtained from the IETF on-line IPR repository | ||||
| at http://www.ietf.org/ipr. | ||||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights, which may cover technology that may be required to practice | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF Executive | this standard. Please address the information to the IETF at | |||
| Director. | ietf-ipr@ietf.org. | |||
| Full Copyright Statement | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | Disclaimer of Validity | |||
| This document and translations of it may be copied and furnished to | This document and the information contained herein are provided on | |||
| others, and derivative works that comment on or otherwise explain it | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
| or assist in its implementation may be prepared, copied, published | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | |||
| and distributed, in whole or in part, without restriction of any | INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | |||
| kind, provided that the above copyright notice and this paragraph are | IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
| included on all such copies and derivative works. However, this | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
| document itself may not be modified in any way, such as by removing | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| the copyright notice or references to the Internet Society or other | ||||
| Internet organizations, except as needed for the purpose of | ||||
| developing Internet standards in which case the procedures for | ||||
| copyrights defined in the Internet Standards process must be | ||||
| followed, or as required to translate it into languages other than | ||||
| English. | ||||
| The limited permissions granted above are perpetual and will not be | Copyright Statement | |||
| revoked by the Internet Society or its successors or assigns. | ||||
| This document and the information contained herein is provided on an | Copyright (C) The Internet Society (2004). This document is subject | |||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | ||||
| Diameter Credit Control Application May 14, 2004 | Acknowledgment | |||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | Funding for the RFC Editor function is currently provided by the | |||
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | Internet Society. | |||
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| End of changes. 490 change blocks. | ||||
| 1989 lines changed or deleted | 1915 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||