idnits 2.17.1 draft-ietf-aaa-diameter-cc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5220. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2471 has weird spacing: '...mporary end ...' == Line 2580 has weird spacing: '...mer Tcc relea...' == Line 4927 has weird spacing: '...session for s...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RE_AUTHORIZATION 1 This value indicates to the Diameter AAA server that a credit-control session is ongoing for the subscriber and the credit-control server MUST not be contacted. The Credit-Control AVP set to the value of 1 is to be used only when the first interrogation has been successfully performed and the credit-control session is ongoing (i.e. re-authorization triggered by Authorization-Lifetime). This value MUST NOT be used in AA request sent to perform the first interrogation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: RETRY_AND_TERMINATE 2 When the Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE the credit-control client SHOULD re-send the request to an alternative server in case of transport or temporary failures, provided that failover procedure is supported in the credit-control server and the credit-control client, and an alternative server is available. Otherwise, the service SHOULD not be granted when the credit-control messages can't be delivered. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following table presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2004) is 7190 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DIAMMIP' is mentioned on line 4324, but not defined == Missing Reference: 'RFC2866' is mentioned on line 4322, but not defined == Missing Reference: 'E121' is mentioned on line 3656, but not defined == Missing Reference: 'CE121' is mentioned on line 3656, but not defined == Missing Reference: 'DIAMEAP' is mentioned on line 4331, but not defined == Missing Reference: 'RFC2865' is mentioned on line 4327, but not defined == Missing Reference: 'RFC3725' is mentioned on line 4794, but not defined == Unused Reference: 'E212' is defined on line 4271, but no explicit reference was found in the text == Unused Reference: 'CE212' is defined on line 4275, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (ref. 'DIAMBASE') (Obsoleted by RFC 6733) -- Possible downref: Non-RFC (?) normative reference: ref. '3GPPCHARG' ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE164' -- Possible downref: Non-RFC (?) normative reference: ref. 'E212' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE212' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3513 (ref. 'IPv6Addr') (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'NASREQ' ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPPIMEI' Summary: 10 errors (**), 0 flaws (~~), 19 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group 3 Internet Draft Harri Hakala 4 Document: draft-ietf-aaa-diameter-cc-06.txt Leena Mattila 5 Expires: February 12, 2005 Ericsson 6 Juha-Pekka Koskinen 7 Marco Stura 8 John Loughney 9 Nokia 10 August 12, 2004 12 Diameter Credit-Control Application 14 Status of this memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance 19 with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This document is a product of the Authentication, Authorization and 38 Accounting (AAA) Working Group of the Internet Engineering Task 39 Force (IETF). Comments are welcome should be submitted to the 40 mailing list aaa-wg@merit.edu. 42 Abstract 44 This document specifies a DIAMETER application that can be used to 45 implement real-time credit-control for a variety of end user 46 services such as network access, Session Initiation Protocol (SIP) 47 services, messaging services, download services etc. 49 1. Introduction...................................................5 50 1.1 Requirements language......................................5 51 1.2 Terminology................................................6 52 1.3 Advertising application support............................7 53 2. Architecture Models............................................8 54 3. Credit-Control Messages.......................................10 55 3.1 Credit-Control-Request (CCR) Command......................10 56 3.2 Credit-Control-Answer (CCA) Command.......................11 57 4. Credit Control Application Overview...........................12 58 4.1 Service-Specific Rating Input and Interoperability........13 59 5. Session Based Credit-control..................................16 60 5.1 General Principles........................................16 61 5.2 First Interrogation.......................................21 62 5.3 Intermediate Interrogation................................27 63 5.4 Final Interrogation.......................................29 64 5.5 Server-Initiated Credit Re-Authorization..................30 65 5.6 Graceful Service Termination..............................32 66 5.7 Failure Procedures........................................37 67 6. One Time Event................................................40 68 6.1 Service Price Enquiry.....................................41 69 6.2 Balance Check.............................................41 70 6.3 Direct Debiting...........................................42 71 6.4 Refund....................................................43 72 6.5 Failure Procedure.........................................44 73 7. Credit Control Application State Machine......................45 74 8. Credit Control AVPs...........................................54 75 8.1 CC-Correlation-Id AVP.....................................57 76 8.2 CC-Request-Number AVP.....................................57 77 8.3 CC-Request-Type AVP.......................................57 78 8.4 CC-Session-Failover AVP...................................58 79 8.5 CC-Sub-Session-Id AVP.....................................58 80 8.6 Check-Balance-Result AVP..................................59 81 8.7 Cost-Information AVP......................................59 82 8.8 Unit-Value AVP............................................60 83 8.9 Exponent AVP..............................................60 84 8.10 Value-Digits AVP.........................................60 85 8.11 Currency-Code AVP........................................61 86 8.12 Cost-Unit AVP............................................61 87 8.13 Credit-Control AVP.......................................61 88 8.14 Credit-Control-Failure-Handling AVP......................61 89 8.15 Direct-Debiting-Failure-Handling AVP.....................62 90 8.16 Multiple-Services-Credit-Control AVP.....................63 91 8.17 Granted-Service-Unit AVP.................................64 92 8.18 Requested-Service-Unit AVP...............................65 93 8.19 Used-Service-Unit AVP....................................65 94 8.20 Tariff-Time-Change AVP...................................66 95 8.21 CC-Time AVP..............................................66 96 8.22 CC-Money AVP.............................................66 97 8.23 CC-Total-Octets AVP......................................67 98 8.24 CC-Input-Octets AVP......................................67 99 8.25 CC-Output-Octets AVP.....................................67 100 8.26 CC-Service-Specific-Units AVP............................67 101 8.27 Tariff-Change-Usage AVP..................................67 102 8.28 Service-Identifier AVP...................................68 103 8.29 Rating-Group AVP.........................................68 104 8.30 G-S-U-Pool-Reference AVP.................................69 105 8.31 G-S-U-Pool-Identifier AVP................................69 106 8.32 CC-Unit-Type AVP.........................................69 107 8.33 Validity-Time AVP........................................70 108 8.34 Final-Unit-Indication AVP................................70 109 8.35 Final-Unit-Action AVP....................................71 110 8.36 Restriction-Filter-Rule AVP..............................72 111 8.37 Redirect-Server AVP......................................72 112 8.38 Redirect-Address-Type AVP................................72 113 8.39 Redirect-Server-Address AVP..............................73 114 8.40 Multiple-Services-Indicator AVP..........................73 115 8.41 Requested-Action AVP.....................................73 116 8.42 Service-Context-Id AVP...................................74 117 8.43 Service-Parameter-Info AVP...............................75 118 8.44 Service-Parameter-Type AVP...............................75 119 8.45 Service-Parameter-Value AVP..............................76 120 8.46 Subscription-Id AVP......................................76 121 8.47 Subscription-Id-Type AVP.................................76 122 8.48 Subscription-Id-Data AVP.................................77 123 8.49 User-Equipment-Info AVP..................................77 124 8.50 User-Equipment-Info-Type AVP.............................77 125 8.50 User-Equipment-Info-Value AVP............................78 126 9. Result Code AVP values........................................78 127 9.1 Transient Failures........................................78 128 9.2 Permanent Failures........................................79 129 10. AVP Occurrence Table.........................................79 130 10.1 Credit Control AVP Table.................................79 131 10.2 Re-Auth-Request/Answer AVP Table.........................81 132 11. RADIUS/Diameter Credit-control Interworking Model............81 133 12. IANA Considerations..........................................84 134 12.1 Application Identifier...................................84 135 12.2 Command Codes............................................84 136 12.3 AVP Codes................................................84 137 12.4 Result-Code AVP Values...................................84 138 12.5 CC-Request-Type AVP......................................84 139 12.6 CC-Session-Failover AVP..................................84 140 12.7 CC-Unit-Type AVP.........................................85 141 12.8 Check-Balance-Result AVP.................................85 142 12.9 Credit-Control AVP.......................................85 143 12.10 Credit-Control-Failure-Handling AVP.....................85 144 12.11 Direct-Debiting-Failure-Handling AVP....................85 145 12.12 Final-Unit-Action AVP...................................85 146 12.13 Multiple-Services-Indicator AVP.........................86 147 12.14 Redirect-Address-Type AVP...............................86 148 12.15 Requested-Action AVP....................................86 149 12.16 Subscription-Id-Type AVP................................86 150 12.17 Tariff-Change-Usage AVP.................................86 151 12.18 User-Equipment-Info-Type AVP............................86 152 13. Credit-control Application Related Parameters................87 153 14. Security Consideration.......................................87 154 14.1 Direct Connection with Redirects.........................88 155 15. References...................................................89 156 15.1 Normative................................................89 157 15.2 Non-Normative............................................90 158 16. Acknowledgement..............................................91 159 A.1 Flow I..................................................92 160 A.2 Flow II.................................................94 161 A.3 Flow III................................................96 162 A.4 Flow IV.................................................97 163 A.5 Flow V..................................................98 164 A.6 Flow VI.................................................99 165 A.7 Flow VII...............................................100 166 A.8 Flow VIII..............................................102 167 A.9 Flow IX..................................................104 168 Author's Address................................................108 169 Intellectual Property Considerations...Error! Bookmark not defined. 171 1. Introduction 173 This document specifies a DIAMETER application that can be used to 174 implement real-time credit-control for a variety of end user 175 services such as network access, Session Initiation Protocol (SIP) 176 services, messaging services, download services etc. It provides a 177 general solution to the real-time cost and credit control. 179 The prepaid model has been shown to be very successful for instance 180 in GSM networks where network operators offering prepaid services 181 have experienced a substantial growth of their customer base and 182 revenues. Prepaid services are now cropping up in many other 183 wireless and wire line based networks as well. 185 In next generation wireless networks, additional functionality is 186 required beyond that specified in the Diameter base protocol. For 187 example, the 3GPP Charging and Billing requirements [3GPPCHARG] 188 state that an application must be able to rate service information 189 in real-time. In addition, it is necessary to check that the end 190 user's account provides coverage for the requested service, prior to 191 initiation of that service. When an account is exhausted or expired, 192 the user must be denied the ability to compile additional chargeable 193 events. 195 A mechanism needs to be provided to allow the user to be informed of 196 the charges to be levied for a requested service. In addition, there 197 are services such as gaming and advertising that may credit as well 198 as debit from a user account. 200 The other Diameter applications provide service specific 201 authorization and they do not provide credit authorization for 202 prepaid users. The credit authorization shall be generic and 203 applicable to all the service environments required to support 204 prepaid services. 206 To fulfill these requirements, it is necessary to facilitate credit- 207 control communication between the network element providing the 208 service (e.g. Network Access Server, SIP Proxy, Application Server 209 etc.) and a credit-control server. 211 The scope of this specification is the credit authorization. Service 212 specific authorization and authentication is out of the scope. 214 1.1 Requirements language 216 In this document, the key words "MAY", "MUST, "MUST NOT", 217 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 218 interpreted as described in [KEYWORDS]. 220 1.2 Terminology 222 AAA 224 Authentication, Authorization and Accounting 226 AA answer 228 AA answer generically refers to a service specific authorization and 229 authentication answer. AA answer commands are defined in service 230 specific authorization applications e.g. [NASREQ] and [DIAMMIP]. 232 AA request 234 AA request generically refers to a service specific authorization 235 and authentication request. AA request commands are defined in 236 service specific authorization applications e.g. [NASREQ] and 237 [DIAMMIP]. 239 Credit-control 241 Credit-control is a mechanism, which directly interacts in real-time 242 with an account and controls or monitors the charges, related to the 243 service usage. Credit-control is a process of: checking if credit is 244 available, credit-reservation, deduction of credit from the end user 245 account when service is completed and refunding of reserved credit 246 not used. 248 Diameter Credit-control Server 250 Diameter Credit-control server acts as a prepaid server, performing 251 real-time rating and credit control. It is located in the home 252 domain and is accessed by service elements or Diameter AAA servers 253 in real-time for purpose of price determination and credit-control 254 before the service event is delivered to the end-user. It may also 255 interact with business support systems. 257 Diameter Credit-control Client 259 A Diameter credit-control client is an entity that interacts with a 260 credit-control server. It monitors the usage of the granted quota 261 according to instructions returned by credit-control server. 263 Interrogation 265 The Diameter credit-control client uses interrogation to initiate a 266 session based credit-control process and during the credit-control 267 process to report the used quota and request a new one. An 268 interrogation maps to a request/answer transaction. 270 One-time event 272 Basically a request/answer transaction of type event. 274 Rating 276 The act of determining the cost of the service event. 278 Service 280 A type of task that is performed by a service element for an end 281 user. 283 Service Element 285 A network element that provides a service to the end users. The 286 Service Element may include the Credit-control Client, or another 287 entity (e.g. RADIUS AAA server) can act as a Credit-control Client 288 on behalf of the Service Element. In the latter case the interface 289 between the Service Element and the Diameter Credit-control Client 290 is outside the scope of this specification. Examples of the Service 291 Elements include Network Access Server (NAS), SIP Proxy and 292 Application Servers such as messaging server, content server and 293 gaming server. 295 Service Event 297 An event relating to a service provided to the end user. 299 Session based credit-control 301 A credit-control process that makes use of several interrogations: 302 the first, possible intermediate and the final interrogation. The 303 first interrogation is used to reserve money from the user's account 304 and initiate the process. The intermediate interrogations may be 305 needed to request new quota while the service is being rendered. The 306 final interrogation is used to exit the process. The credit-control 307 server is required to maintain session state for session-based 308 credit-control. 310 1.3 Advertising application support 312 Diameter nodes conforming to this specification MUST advertise 313 support by including the value of XXX [IANA please fill in XXX 314 (suggested value 4 in section 12.1) and remove this note] in the 315 Auth-Application-Id of the Capabilities-Exchange-Request and 316 Capabilities-Exchange-Answer command [DIAMBASE]. 318 2. Architecture Models 320 The current accounting models specified in the Radius Accounting 321 [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real- 322 time credit control, where credit-worthiness is to be determined 323 prior to service initiation. Also, the existing Diameter 324 authorization applications [NASREQ] and [DIAMMIP] only provides 325 service authorization, but do not provide credit authorization for 326 prepaid users. In order to support real-time credit control a new 327 type of server is needed in the AAA infrastructure; Diameter credit- 328 control server. The Diameter credit-control server is the entity 329 responsible of credit authorization for prepaid subscribers. 331 A service element may authenticate and authorize the end user with 332 the AAA server using AAA protocols, e.g. RADIUS or a Diameter base 333 protocol with a possible Diameter application. 335 Accounting protocols such as RADIUS accounting and the Diameter base 336 accounting protocol can be used to provide accounting data to the 337 accounting server after service is initiated, and to provide 338 possible interim reports until service completion. However, for 339 real-time credit control, these authorization and accounting models 340 are not sufficient. 342 When real-time credit-control is required, the credit-control client 343 contacts the credit-control server with possible service event 344 information. The credit-control process is performed in order to 345 determine potential charges and to verify whether the end user's 346 account balance is sufficient to cover the cost of the service being 347 rendered. 349 Figure 1 illustrates the typical credit-control architecture, which 350 consist of a Service Element with embedded Diameter credit-control 351 client, a Diameter credit-control server and an AAA server. A 352 Business Support System is usually deployed; it includes at least 353 the billing functionality. The credit-control server and AAA server 354 in this architecture model are logical entities. The real 355 configuration can combine them into a single host. The credit- 356 control protocol is the Diameter base protocol with the Diameter 357 credit-control application. 359 When an end user requests services such as SIP services or messaging 360 services, the request is typically forwarded to a service element 361 (e.g. SIP Proxy) in the user's home domain. In some cases it might 362 be possible that the service element in the visited domain can offer 363 services to the end user, however a commercial agreement must exist 364 between the visited domain and the home domain. Network access is an 365 example of a service offered in the visited domain where the NAS, 366 through an AAA infrastructure, authenticates and authorizes the user 367 with the user's home network. 369 Service Element AAA and CC 370 +----------+ +---------+ protocols+-----------+ +--------+ 371 | End |<---->|+-------+|<------------>| AAA | |Business| 372 | User | +->|| CC || | Server |->|Support | 373 | | | || client||<-----+ | | |System | 374 +----------+ | |+-------+| | +-----------+ | | 375 | +---------+ | ^ +--------+ 376 +----------+ | | CC protocol | ^ 377 | End |<--+ | +-----v----+ | 378 | User | +------>|Credit- | | 379 +----------+ credit-control |control |--------+ 380 protocol |server | 381 +----------+ 383 Figure 1: Typical credit-control architecture 385 There can be multiple credit-control servers in the system for 386 reasons of redundancy and load balancing. The system can also 387 contain separate rating server(s) and accounts can be located in a 388 centralized database. For duplicate detection only one place in the 389 credit-control system should perform duplicate detection to ensure 390 that the end user's account is not debited or credited multiple 391 times for the same service event. System internal interfaces can 392 exist to relay messages between servers and an account manager. 393 However the detailed architecture of credit-control system and its 394 interfaces are implementation specific and are out of scope of this 395 specification. 397 There can exist protocol transparent Diameter relays between credit- 398 control client and credit-control server. Also Diameter Redirect 399 agents, which refer credit control clients, to credit control 400 servers and allow them to communicate directly can exist. These 401 agents transparently support the Diameter credit-control 402 application. The different roles of Diameter Agents are defined in 403 Diameter base [DIAMBASE] section 2.8. 405 If Diameter credit-control proxies exist between the credit-control 406 client and the credit-control server, they MUST advertise the 407 Diameter credit-control application support. 409 3. Credit-Control Messages 411 This section defines new Diameter message Command-Code values that 412 MUST be supported by all Diameter implementations that conform to 413 this specification. The Command Codes are: 415 Command-Name Abbrev. Code Reference 416 ----------------------------------------------------------- 417 Credit-Control-Request CCR xxx 3.1 418 Credit-Control-Answer CCA xxx 3.2 420 [IANA please fill in xxx (suggested value 272) and remove this note] 422 Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code 423 ABNF specification. These formats are observed in Credit-Control 424 messages. 426 3.1 Credit-Control-Request (CCR) Command 428 The Credit-Control-Request message (CCR), indicated by the command- 429 code field set to xxx [IANA please fill in xxx (suggested value 272) 430 and remove this note] and the 'R' bit set in the Command Flags 431 field, is used between the Diameter credit-control client and the 432 credit-control server to request credit authorization for a given 433 service. 435 The Auth-Application-Id MUST be set to the value XXX [IANA please 436 fill in XXX (suggested value 4 in section 12.1) and remove this 437 note] indicating the Diameter credit-control application. 439 Message Format 441 ::= < Diameter Header: xxx, REQ, PXY > 442 < Session-Id > 443 { Origin-Host } 444 { Origin-Realm } 445 { Destination-Realm } 446 { Auth-Application-Id } 447 { Service-Context-Id } 448 { CC-Request-Type } 449 { CC-Request-Number } 450 [ Destination-Host ] 451 [ User-Name ] 452 [ CC-Sub-Session-Id ] 453 [ Acct-Multi-Session-Id ] 454 [ Origin-State-Id ] 455 [ Event-Timestamp ] 456 *[ Subscription-Id ] 458 [ Service-Identifier ] 459 [ Termination-Cause ] 460 [ Requested-Service-Unit ] 461 [ Requested-Action ] 462 *[ Used-Service-Unit ] 463 [ Multiple-Services-Indicator ] 464 *[ Multiple-Services-Credit-Control 465 ] 466 *[ Service-Parameter-Info ] 467 [ CC-Correlation-Id ] 468 [ User-Equipment-Info ] 469 *[ Proxy-Info ] 470 *[ Route-Record ] 471 *[ AVP ] 473 [IANA please fill in xxx (suggested value 272) and remove this note] 475 3.2 Credit-Control-Answer (CCA) Command 477 The Credit-Control-Answer message (CCA), indicated by the command- 478 code field set to xxx [IANA please fill in xxx (suggested value 272) 479 and remove this note] and the 'R' bit cleared in the Command Flags 480 field, is used between the credit-control server and the Diameter 481 credit-control client to acknowledge a Credit-Control-Request 482 command. 484 Message Format 486 ::= < Diameter Header: xxx, PXY > 487 < Session-Id > 488 { Result-Code } 489 { Origin-Host } 490 { Origin-Realm } 491 { Auth-Application-Id } 492 { CC-Request-Type } 493 { CC-Request-Number } 494 [ User-Name ] 495 [ CC-Session-Failover ] 496 [ CC-Sub-Session-Id ] 497 [ Acct-Multi-Session-Id ] 498 [ Origin-State-Id ] 499 [ Event-Timestamp ] 500 [ Granted-Service-Unit ] 501 *[ Multiple-Services-Credit-Control 502 ] 503 [ Cost-Information] 504 [ Final-Unit-Indication ] 505 [ Check-Balance-Result ] 506 [ Credit-Control-Failure-Handling ] 508 [ Direct-Debiting-Failure-Handling 509 ] 510 [ Validity-Time] 511 *[ Redirect-Host] 512 [ Redirect-Host-Usage ] 513 [ Redirect-Max-Cache-Time ] 514 *[ Proxy-Info ] 515 *[ Route-Record ] 516 *[ Failed-AVP ] 517 *[ AVP ] 519 [IANA please fill in xxx (suggested value 272) and remove this note] 521 4. Credit Control Application Overview 523 The credit authorization process takes place before and during 524 service delivery to the end user and generally requires user's 525 authentication and authorization before any request is sent to the 526 credit-control server. The credit control application defined in 527 this specification supports two different credit authorization 528 models: credit authorization with money reservation and credit 529 authorization with direct debiting. In both the models, the credit 530 control client requests credit authorization to the credit control 531 server prior to allow any service to be delivered to the end user. 533 In the first model, the credit control server rates the request, 534 reserves a suitable amount of money from the user's account and 535 returns the corresponding amount of credit resources. Note that 536 credit resources may not imply actual monetary credit; credit 537 resources may be granted to the credit control client in form of 538 units (e.g. data volume or time) to be metered. 540 Upon reception of a successful credit authorization answer with a 541 certain amount of credit resources, the credit control client allows 542 service delivery to the end user and starts monitoring the usage of 543 the granted resources. When the credit resources granted to the user 544 have been consumed, or the service has been successfully delivered 545 or terminated, the credit control client reports back to the server 546 the used amount. The credit control server deducts the used amount 547 from the end user's account; it may perform rating and make a new 548 credit reservation if the service delivery is continuing. This 549 process is accomplished with session based credit control that 550 includes the first interrogation, possible intermediate 551 interrogations and the final interrogation. For session based credit 552 control, both the credit control client and the credit control 553 server are required to maintain credit control session state. 554 Session based credit control is described in more detail, with more 555 variations, in section 5. 557 In contrast, credit authorization with direct debiting is a single 558 transaction process where the credit control server directly deducts 559 a suitable amount of money from the user's account as soon as the 560 credit authorization request is received. Upon reception of a 561 successful credit authorization answer, the credit control client 562 allows service delivery to the end user. This process is 563 accomplished with the One-time event. Session state is not 564 maintained. 566 In a multi-service environment, an end user may issue an additional 567 service request (e.g. data service) during an ongoing service (e.g. 568 voice call) towards the same account; or during an active multimedia 569 session an additional media type is added to the session causing a 570 new simultaneous request towards same account. Consequently this 571 needs to be considered when credit resources are granted to the 572 services. 574 The credit control application also supports operations such as 575 service price enquiry, user's balance check and refund of credit on 576 the user's account. These operations are accomplished with the One- 577 time event. Session state is not maintained. 579 A flexible Credit control application specific failure handling is 580 defined 581 where the home service provider can model the credit control client 582 behavior according to its own credit risk management policy. 584 The Credit-Control-Failure-Handling AVP and the Direct-Debiting- 585 Failure-Handling AVP are defined to determine what to do if the 586 sending of credit-control messages to the credit-control server has 587 been temporarily prevented. The usage of Credit-Control-Failure- 588 Handling AVP and the Direct-Debiting-Failure- Handling AVP gives 589 flexibility to have different failure handling for credit-control 590 session and one time event direct debiting. 592 4.1 Service-Specific Rating Input and Interoperability 594 The Diameter Credit-Control Application defines the framework for 595 credit control; it provides generic credit control mechanisms 596 supporting multiple service applications. The Credit Control 597 Application, therefore, does not define AVPs that could be used as 598 input in the rating process. Listing the possible services that 599 could use this Diameter application is seen as out of scope for this 600 generic mechanism as well. 602 Furthermore, it is reasonable to expect that there will exist a 603 service level agreement between providers of the credit-control 604 client and the credit-control server covering the charging, services 605 offered, roaming agreements, agreed rating input (i.e. AVPs), etc. 607 Therefore, it is assumed that a Diameter credit control server will 608 provide service only for Diameter credit-control clients that have 609 agreed beforehand the content of credit control messages. Protocol 610 wise, it is naturally possible that any arbitrary Diameter credit- 611 control client can interchange credit control messages with any 612 Diameter credit control server, but with a higher likelihood that 613 unsupported services/AVPs could be present in the credit-control 614 message causing the server to reject the request with an appropriate 615 result-code. 617 4.1.1 Specifying Rating Input AVPs 619 There are two ways for providing rating input to the credit control 620 server, either by using AVPs or by including them in the Service- 621 Parameter-Info AVP. The general principles for sending rating 622 parameters are: 624 1a. The service SHOULD re-use existing AVPs, if theservice can use 625 AVPs defined in existing Diameter applications (e.g. NASREQ for 626 network access services). Re-use of existing AVPs is strongly 627 recommended in [DIAMBASE]. 628 For AVPs of type Enumerated the service may require a new value to 629 be defined. Allocation of new AVP values is done as specified in 630 [DIAMBASE], section 1.2. 632 1b. New AVPs can be defined if the existing AVPs do not provide 633 sufficient rating information. In such a case, the procedures 634 defined in [DIAMBASE] for creating new AVPs MUST be followed. 636 1c. For services specific only to one vendor's implementation, a 637 Vendor-Specific AVP code for Private use can be used. Where a 638 Vendor-Specific AVP is implemented by more than one vendor, 639 allocation of global AVPs are encouraged instead, refer to 640 [DIAMBASE]. 642 2. The Service-Parameter-Info AVP MAY be used as a container to pass 643 legacy rating information in its original encoded form (e.g. ASN.1 644 BER). This method can be used to avoid unnecessary data format 645 conversions from an existing format to an AVP format. In that case 646 the rating input is embedded in the Service-Parameter-Info AVP as 647 defined in section 8.43. 648 New service applications SHOULD favor the use of explicitly defined 649 AVPs as described in items 1a and 1b, to simplify interoperability. 651 4.1.2 Service-Specific Documentation 653 The service specific rating input AVPs, the contents of the Service- 654 Parameter-Info AVP or Service-Context-Id AVP (defined in section 655 8.42) are not within the scope of this document. To facilitate 656 interoperability, it is RECOMMENDED that the rating input and the 657 values of the Service-Context-Id are coordinated via an 658 informational RFC or other permanent and readily available reference 659 such as the specification of another cooperative standardization 660 body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. However, private 661 services may be deployed that are subject to agreements between 662 providers of the credit control server and client, in this case 663 vendor specific AVPs can be used. 665 This specification, together with the above service specific 666 documents, governs the credit control message. The rule is that 667 service specific documents define what existing AVPs or new AVPs are 668 used as input to the rating process (i.e. they do not define new 669 credit control applications), and thus need to be included in the 670 Credit-Control-Request command by a Diameter Credit Control Client 671 supporting a given service as *[AVP]. Should Service-Parameter-Info 672 be used, then the service specific document MUST specify the exact 673 content of this grouped AVP. 675 The Service-Context-Id AVP MUST be included at the command level of 676 a Credit Control Request to identify the service specific document 677 that applies to the request. The specific service or rating group 678 that the request relates to is uniquely identified by the 679 combination of Service-Context-Id and Service-Identifier or Rating- 680 Group. 682 4.1.3 Handling of Unsupported/Incorrect Rating Input 684 Diameter credit control implementations are required to support the 685 Mandatory rating AVPs defined in service specific documentation of 686 the services they support according to the 'M' bit rules in 687 [DIAMBASE]. 688 In case a rating input required for the rating process is incorrect 689 in the Credit control request, or the credit control server does not 690 support the requested service context (identified by the Service- 691 Context-Id AVP at command level), the Credit control answer MUST 692 contain error code DIAMETER_RATING_FAILED. A CCA message with this 693 error MUST contain one or more Failed-AVP AVPs containing the 694 missing and/or unsupported AVPs that caused the failure. A Diameter 695 credit control client receiving error code DIAMETER_RATING_FAILED in 696 answer to a request MUST NOT send such similar requests in the 697 future. 699 4.1.4 RADIUS Vendor-Specific Rating Attributes 701 When service specific documents include RADIUS vendor specific 702 attributes that could be used as input in the rating process, the 703 rules described in [NASREQ] for formatting the Diameter AVP MUST be 704 followed. 706 For example, the AVP code used is the vendor attribute type code, 707 the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be 708 set to the IANA Vendor identification value. The Diameter AVP data 709 field contains only the attribute value of the RADIUS attribute. 711 5. Session Based Credit-control 713 5.1 General Principles 715 For a session-based credit-control, several interrogations are 716 needed: the first, intermediate (optional) and the final 717 interrogation. This is illustrated in Figure 2 and Figure 3. 719 If the credit-control client performs credit-reservation before 720 granting service to the end user it MUST use several interrogations 721 towards the credit-control server (i.e. session based credit- 722 control). In this case the credit-control server MUST maintain the 723 credit control session state. 725 Each credit-control session MUST have globally unique Session-Id as 726 defined in [DIAMBASE] and it MUST NOT be changed during the lifetime 727 of a credit-control session. 729 There are certain applications that require multiple credit control 730 sub-sessions. Such applications would send messages with a constant 731 Session-Id AVP, but a different CC-Sub-Session-Id AVP. If several 732 credit sub-sessions will be used, all sub-sessions MUST be closed 733 separately before closing the main session to be able to report used 734 units per sub-session. The absence of this AVP implies no sub- 735 sessions are in use. 737 It should be noted that the service element might send a service 738 specific re-authorization message to the AAA server due to 739 expiration of the authorization-lifetime during an ongoing credit 740 control session. However, the service specific re-authorization does 741 not influence the credit authorization that is ongoing between 742 credit-control client and credit-control server since credit 743 authorization is controlled by the burning rate of the granted 744 quota. 746 In the event that service specific re-authorization fails the user 747 will be disconnected and the credit-control client MUST send a final 748 interrogation to the credit-control server. 750 The Diameter credit-control server may want to control the validity 751 time of the granted quota and/or the production of intermediate 752 interrogations, thus it MAY include the Validity-Time AVP in the 753 answer message to the credit-control client. Upon expiration of the 754 Validity-Time, the credit-control client MUST generate a credit- 755 control update request and report the used quota to the credit- 756 control server. It is up to the credit-control server to determine, 757 the value of the Validity-Time to be used for consumption of the 758 granted service units. If the Validity-Time is used, its value 759 SHOULD be given as input to set the session supervision timer Tcc 760 (the session supervision timer MAY be set to two times the value of 761 the Validity-Time as defined in section 13). Since credit-control 762 update requests are also produced at the expiry of granted service 763 units and/or for mid-session service events the omission of 764 Validity-Time does not mean that intermediate interrogation for the 765 purpose of credit control are not performed. 767 5.1.1 Basic Tariff-Time Change Support 769 The Diameter credit-control server and client MAY optionally support 770 a tariff change mechanism. The Diameter credit-control server may 771 include a Tariff-Time-Change AVP in the answer message. Note that 772 the granted units should be allocated based on the worst-case 773 scenario in case of forthcoming tariff change, so that the overall 774 reported used units would never exceed the credit reservation. 776 When the Diameter credit-control client reports the used units and a 777 tariff change has occurred during the reporting period then the 778 Diameter credit-control client MUST separately itemize the units 779 used before and after the tariff change. In case the client is 780 unable to distinguish whether units that straddle the tariff change 781 are used before or after the tariff change, the credit-control 782 client MUST itemize those units in a third category. 784 If a client does not support the tariff change mechanism, and it 785 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 786 terminate the credit control session, giving a reason of 787 DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 789 For time based services the quota is continuously consumed at the 790 regular rate of 60 seconds per minute, the server already knows at 791 the time when credit resources are allocated how many units will be 792 consumed before the tariff time change and how many units will be 793 consumed after. Similarly, the server can determine the units 794 consumed at the before rate and the units consumed at the rate 795 afterwards in the event that the end-user closes the session before 796 the consumption of the allotted quota. There is no need for 797 additional traffic between client and server in case of tariff time 798 changes for continuous time based service, therefore the tariff 799 change mechanism is not used for continuous time based services. For 800 time-based services where the quota is NOT continuously consumed at 801 a regular rate, the tariff change mechanism described for volume and 802 event units MAY be used. 804 5.1.2 Credit-Control for Multiple Services within a (sub-)Session 806 When multiple services are used within one user session and each 807 service or group of services are subject to different cost, it is 808 necessary to perform credit-control for each of these services 809 independently. Making use of credit control sub-sessions to achieve 810 independent credit-control will result in increased signaling load 811 and resources usage in both the credit control client and the credit 812 control server. For instance, during one network access session the 813 end user may use several http-services subject to different access 814 cost, the network access specific attributes such as the quality of 815 service (QoS) are common to all the services carried within the 816 access bearer, but the cost of the bearer may vary depending on its 817 content. 819 To optimally support these scenarios, the credit control application 820 enables for independent credit control of multiple services in a 821 single credit control (sub-)session. This is achieved by including 822 the optional Multiple-Services-Credit-Control AVP in Credit-Control- 823 Request/Answer messages. It is possible to request and allocate 824 resources as a credit pool that is shared between multiple services. 825 The services can be further grouped into rating groups in order to 826 achieve even further aggregation of credit allocation. It is also 827 possible to request and allocate quotas on a per service basis. 828 Where quotas are allocated to a pool by means of the Multiple- 829 Services-Credit-Control AVP, the quotas remain independent objects 830 that can be re-authorized independently at any time. Quotas can also 831 be given independent result codes, validity times and Final-Unit- 832 Indications. 834 A Rating-group groups a set of services, identified by a Service- 835 Identifier, subject to the same cost and rating type (e.g. 836 $0.1/minute). It is assumed that the service element is provided, by 837 means outside the scope of this specification, with Rating-Groups, 838 with Service-Identifiers and their associated parameters that define 839 what need to be metered (example of parameters associated to 840 Service-Identifiers are IP 5-tuple, HTTP URL etc.). Service- 841 identifiers enable on a per-service based credit authorization as 842 well as itemized reporting of service usage. It is up to the credit 843 control server whether to authorize credit for one or more services 844 or for the whole rating-group. However, the client SHOULD always 845 report used units at the finest level of granularity that it 846 supports. Where quota is allocated to a rating-group, all the 847 services belonging to that rating-group draw from the allotted 848 quota. The following is a graphical representation of the relation 849 between service-identifiers, rating-groups, credit pools and credit- 850 control (sub-)session. 852 DCC (Sub-)Session 853 | 854 +------------+-----------+-------------+--------------- + 855 | | | | | 856 Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z 857 \ / \ / / 858 \ / \ / / 859 \ / Rating-Group 1.......Rating-Group n 860 \ / | | 861 Quota ---------------Quota Quota 862 | / | 863 | / | 864 Credit-Pool Credit-Pool 866 In case independent credit control of multiple services is used, the 867 validity-time and final-unit-indication SHOULD be present either in 868 the Multiple-Services-Credit-Control AVP(s) or at command level as 869 single AVPs. However, the Result-Code AVP MAY be present both on the 870 command level and within the Multiple-Services-Credit-Control AVP. 871 If the Result-Code on the command level indicates other value than 872 SUCCESS then the Result-Code on command level takes precedence over 873 the one(s) included in the Multiple-Services-Credit-Control AVP. 875 The Credit-control client MUST indicate support for independent 876 credit control of multiple services within a (sub-)session by 877 including the Multiple-Services-Indicator AVP in the first 878 interrogation. A Credit-Control-server not supporting the feature 879 MUST treat the Multiple-Services-Indicator AVP and possibly received 880 Multiple-Services-Credit-Control AVPs as invalid AVPs. 882 If the client indicated support for independent credit control of 883 multiple services, a credit-control server that wishes to use the 884 feature MUST return the granted units within the Multiple-Services- 885 Credit-Control AVP associated to the corresponding service- 886 identifier and/or rating-group. 888 To avoid a situation where several parallel, and typically also 889 small, credit reservations must be made on the same account (i.e. 890 credit fragmentation) and also to avoid unnecessary load on the 891 credit control server, it is possible to provide service units as a 892 pool that applies to multiple services or rating groups. This is 893 achieved by providing the service units in the form of a quota for a 894 particular service or rating group in the Multiple-Services-Credit- 895 Control AVP, but also including a reference to a credit pool for 896 that unit type. 898 The reference includes a multiplier derived from the rating 899 parameter, which translates from service units of a specific type to 900 the abstract service units in the pool. For instance if the rating 901 parameter for service 1 is $1/MB and rating parameter for service 2 902 is $0.5/MB the multipliers could be 10 and 5 for service 1 and 903 service 2 respectively. 905 If S is the total service units within the pool, M1, M2, ... , Mn 906 are the multipliers provided for services 1, 2, ..., n and C1, 907 C2,... ,Cn are the used resources within the session, then the pool 908 credit is exhausted and re-authorization MUST be sought when: 910 C1*M1 + C2*M2 + ... + Cn*Mn >= S 912 The total credit in the pool, S, is calculated from the quotas which 913 are currently allocated to the pool as follows: 915 S = Q1*M1 + Q2*M2 + ... + Qn*Mn 917 If services or rating groups are added to or removed from the pool, 918 then the total credit is adjusted appropriately. Note that when the 919 total credit is adjusted because services or rating groups are 920 removed from the pool, the value that need to be removed is the 921 consumed one (i.e. Cx*Mx). 923 Re-authorizations for an individual service or rating group may be 924 sought at any time, for example if a 'non-pooled' quota is used up 925 or the Validity-Time expires. 927 Where multiple G-S-U-Pool-Reference AVPs (section 8.30) with the 928 same G-S-U-Pool-Identifier are provided within a Multiple-Services- 929 Credit-Control AVP (section 8.16) together with the Granted-Service- 930 Unit AVP, then these MUST have different CC-Unit-Type values and 931 they all draw on the credit pool separately. For instance, if one 932 multiplier for time (M1t) and one multiplier for volume (M1v) are 933 given, then the used resources from the pool is the sum C1t*M1t + 934 C1v*M1v, where C1t are the time units and C1v are the volume unit. 936 Where service units are provided within a Multiple-Services-Credit- 937 Control AVP without a corresponding G-S-U-Reference AVP then these 938 are handled independently from any credit pool and from any other 939 services or rating groups within the session. 941 The credit pool concept is an optimal tool to avoid the over- 942 reservation effect of the basic single quota tariff time change 943 mechanism (the mechanism described in section 5.1.1). Therefore, 944 Diameter credit-control clients and servers implementing the 945 independent credit control of multiple services SHOULD leverage the 946 credit pool concept when supporting the tariff time change. The 947 Diameter credit-control server SHOULD include both the Tariff-Time- 948 Change and Tariff-Change-Usage AVPs in two quota allocations in the 949 answer message (i.e. two instances of the Multiple-Services-Credit- 950 Control AVP). One of the granted units is allocated to be used 951 before the potential tariff change while the second granted units 952 are used after a tariff change. Both granted unit quotas MUST 953 contain the same Service-Identifier and/or Rating-Group. This dual 954 quota mechanism ensures that the overall reported used units would 955 never exceed the credit reservation. The Diameter credit-control 956 client reports both the used units before and after the tariff 957 change in a single instance of the Multiple-Services-Credit-Control 958 AVP. 960 The failure handling for credit control sessions is defined in 961 section 5.7 and reflected in the basic credit-control state machine 962 in section 7 Credit-control clients and servers implementing the 963 independent credit control of multiple services in a (sub-)session 964 functionality MUST ensure failure handling and general behavior 965 fully consistent with the above mentioned sections while capable of 966 handling parallel ongoing credit re-authorization within a (sub- 967 )session. It is then RECOMMENDED that Diameter credit-control 968 clients maintain a PENDING-U message queue and restarts the Tx timer 969 (section 13) every time a CCR message with value UPDATE_REQUEST is 970 sent while in PENDING-U state. When answers to all the pending 971 messages are received the state machine moves to OPEN and Tx is 972 stopped. Naturally the action performed when a problem is detected 973 for the session according to section 5.7, affect all the ongoing 974 services (e.g. failover to a backup server if possible affect all 975 the CCR messages with value UPDATE_REQUEST in the PENDING-U queue). 977 Since the client may send CCR messages with value UPDATE_REQUEST 978 while in PENDING-U (i.e. without waiting for an answer to ongoing 979 credit re-authorization), the time space between these requests may 980 be very short and the server may not have received the previous 981 request(s) yet. Therefore in this situation the server may receive 982 out of sequence requests and SHOULD NOT consider this as an error 983 condition, a proper answer is to be returned to each of those 984 requests. 986 5.2 First Interrogation 988 When session based credit-control is required (e.g. the 989 authentication server indicated prepaid user), the first 990 interrogation MUST be sent before the Diameter credit-control client 991 allows any service event to the end user. The CC-Request-Type is set 992 to the value INITIAL_REQUEST in the request message. 994 If the Diameter credit-control client knows the cost of the service 995 event (e.g. a content server delivering ringing tones may know their 996 cost) the monetary amount to be charged is included in the 997 Requested-Service-Unit AVP. If the Diameter credit-control client 998 does not know the cost of the service event, the Requested-Service- 999 Unit AVP MAY contain the number of requested service events. Where 1000 the Multiple-Services-Credit-Control AVP is used, it MUST contain 1001 the Requested-Service-Unit AVP to indicate that quota for the 1002 associated service/rating-group is requested. In case of multiple 1003 services, the Service-Identifier AVP or the Rating-Group AVP within 1004 the Multiple-Services-Credit-Control AVP, always indicates the 1005 concerned service. Additional service event information to be rated 1006 MAY be sent as service specific AVPs or MAY be sent within the 1007 Service-Parameter-Info AVP at command level. The Service-Context-Id 1008 AVP indicates the service specific document applicable to the 1009 request. 1011 The Event-Timestamp AVP SHOULD be included in the request and 1012 contains the time when the service event is requested in the service 1013 element. The Subscription-Id AVP SHOULD be included to identify the 1014 End-User in the credit-control server. The credit control client MAY 1015 include the User-Equipment-Info AVP so that the credit control 1016 server has some indication about the type and capabilities of the 1017 end user access device. How the credit control server uses this 1018 information is outside the scope of this document. 1020 The credit-control server SHOULD rate the service event and make a 1021 credit-reservation from the end user's account that covers the cost 1022 of the service event. If the type of the Requested-Service-Unit AVP 1023 is money, no rating is needed but the corresponding monetary amount 1024 is reserved from end user's account. 1026 The credit-control server returns the Granted-Service-Unit AVP in 1027 the Answer message to the Diameter credit-control client. The 1028 Granted-Service-Unit AVP contains the amount of service units that 1029 the Diameter credit-control client can provide to the end user until 1030 a new Credit-Control-Request MUST be sent to the credit-control 1031 server. If several unit types are sent in the Answer message the 1032 credit-control client MUST handle each unit type separately. The 1033 type of the Granted-Service-Unit AVP can be time, volume, service 1034 specific or money depending on the type of service event. The unit 1035 type(s) SHOULD NOT be changed within an ongoing credit-control 1036 session. 1038 There MUST be maximum one instance of the same unit type in one 1039 Answer message. However, in case multiple quotas are conveyed to the 1040 credit control client in the Multiple-Services-Credit-Control AVPs, 1041 it is possible to carry two instances of the same unit type 1042 associated to a service-identifier/rating-group. This is typically 1043 the case when a tariff time change is expected and the credit- 1044 control server wants to make a distinction between the granted quota 1045 before and after tariff change. 1047 If the credit-control server determines that no further control is 1048 needed for the service it MAY include the result code indicating 1049 that the credit-control is not applicable (e.g. service is free of 1050 charge). This result code at command level implies that the credit- 1051 control session is to be terminated. 1053 The Credit-Control-Answer message MAY also include the Final-Unit- 1054 Indication AVP to indicate that the answer message contains the 1055 final units for the service. After the end user has consumed these 1056 units, the Diameter credit-control-client MUST behave as described 1057 in section 5.6. 1059 This document defines two different approaches to perform the first 1060 interrogation to be used indifferent network architectures. The 1061 first approach uses credit-control messages after user's 1062 authorization and authentication took place. The second approach 1063 uses service specific authorization messages to perform the first 1064 interrogation during the user's authorization/authentication phase, 1065 and credit-control messages for the intermediate and the final 1066 interrogations. In case an implementation of the credit-control 1067 client supports both the methods, it SHOULD be configurable what 1068 method to use. 1070 In service environments such as the Network Access Server (NAS), it 1071 is desired to perform the first interrogation as part of the 1072 authorization/authentication process for the sake of protocol 1073 efficiency. Further credit authorizations after the first 1074 interrogation took place are performed with credit control commands 1075 defined in this specification. Implementations of credit-control 1076 client operating in the mentioned environments SHOULD support this 1077 method. In case the credit-control server and AAA server are 1078 separate physical entities the service element sends the request 1079 messages to the AAA server, which then issue an appropriate request 1080 or proxy the received request forward to the credit-control server. 1082 In other service environments, such as the 3GPP network and some SIP 1083 scenario, there is a substantial decoupling between 1084 registration/access to the network and the actual service request 1085 (i.e. the authentication/authorization is executed once at 1086 registration/access to the network and is not executed for every 1087 service event requested by the subscriber). In such environments it 1088 is more appropriate to perform the first interrogation after the 1089 user has been authenticated and authorized. The first interrogation, 1090 the intermediate and final interrogations are executed with credit 1091 control commands defined in this specification. 1093 Other IETF standards or standards developed by other standardization 1094 bodies may define what is the most suitable method in their 1095 architecture. 1097 5.2.1 First Interrogation after Authorization and Authentication 1099 The Diameter credit-control client in the service element may get 1100 information from the authorization server whether credit-control is 1101 required based on its knowledge of the end user. If credit-control 1102 is required the credit-control server needs to be contacted prior to 1103 initiating service delivery to the end user. The accounting protocol 1104 and the credit-control protocol can be used in parallel, the 1105 authorization server may also drive whether the parallel accounting 1106 stream is required. 1108 The following diagram illustrates the case where both protocols are 1109 used in parallel and the service element sends credit-control 1110 messages directly to the credit-control server. More credit-control 1111 sequence examples are given in Annex A. 1112 Diameter 1113 End-User Service Element AAA Server CC Server 1114 (CC Client) 1115 | Registration | AA request/answer(accounting,cc or both)| 1116 |<----------------->|<------------------>| | 1117 | : | | | 1118 | : | | | 1119 | Service Request | | | 1120 |------------------>| | | 1121 | | CCR(Initial,Credit-Control AVPs) | 1122 | +|---------------------------------------->| 1123 | CC stream|| | CCA(Granted-Units)| 1124 | +|<----------------------------------------| 1125 | Service Delivery | | | 1126 |<----------------->| ACR(start,Accounting AVPs) | 1127 | : |------------------->|+ | 1128 | : | ACA || Accounting stream | 1129 | |<-------------------|+ | 1130 | : | | | 1131 | : | | | 1132 | | CCR(Update,Used-Units) | 1133 | |---------------------------------------->| 1134 | | | CCA(Granted-Units)| 1135 | |<----------------------------------------| 1136 | : | | | 1137 | : | | | 1138 | End of Service | | | 1139 |------------------>| CCR(Termination, Used-Units) | 1140 | |---------------------------------------->| 1141 | | | CCA | 1142 | |<----------------------------------------| 1143 | | ACR(stop) | | 1144 | |------------------->| | 1145 | | ACA | | 1146 | |<-------------------| | 1148 Figure 2: Protocol example with first interrogation after user's 1149 authorization/authentication 1151 5.2.2 Authorization Messages for First Interrogation 1153 The Diameter credit-control client in the service element MUST 1154 actively co-operate with the authorization/authentication client in 1155 the construction of the AA request by adding appropriate credit 1156 control AVPs. The credit-control client MUST add the Credit-Control 1157 AVP to indicate credit-control capabilities and MAY add other 1158 relevant credit-control specific AVPs to the proper 1159 authorization/authentication command to perform the first 1160 interrogation towards the home Diameter AAA server. The Auth- 1161 Application-Id is set to the appropriate value as defined in the 1162 relevant service specific authorization/authentication application 1163 document (e.g. [NASREQ], [DIAMMIP]). The home Diameter AAA server 1164 authenticates/authorizes the subscriber and determines whether or 1165 not credit-control is required. 1167 If credit-control is not required for the subscriber the home 1168 Diameter AAA server will respond as usual with an appropriate AA 1169 answer message. If credit-control is required for the subscriber and 1170 the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION 1171 was present in the authorization request, the home AAA server MUST 1172 contact the credit-control server to perform the first 1173 interrogation. If credit-control is required for the subscriber and 1174 the Credit-Control AVP was not present in the authorization request, 1175 the home AAA server MUST send an authorization reject answer 1176 message. 1178 The Diameter AAA server supporting credit-control is required to 1179 send the Credit-Control-Request command (CCR) defined in this 1180 document to the credit-control server. The Diameter AAA server 1181 populates the CCR based on service specific AVPs used for input to 1182 the rating process and possibly credit-control AVPs received in the 1183 AA request. The credit-control server will make money reservation 1184 from the user's account, will rate the request and will send a 1185 credit-control answer message to the home Diameter AAA server. The 1186 answer message includes the Granted-Service-Unit AVP(s) and MAY 1187 include other credit-control specific AVPs as appropriate. 1188 Additionally, the credit-control server MAY set the Validity-Time 1189 and MAY include the Credit-Control-Failure-Handling AVP and the 1190 Direct-Debiting-Failure-Handling AVP to determine what to do if the 1191 sending of credit-control messages to the credit-control server has 1192 been temporarily prevented. 1194 Upon receiving the credit-control answer message from the credit- 1195 control server, the home Diameter AAA server will populate the AA 1196 answer with the received credit-control AVPs and with usual service 1197 attributes according to the authorization/authentication specific 1198 application (e.g. [NASREQ], [DIAMMIP]) and forward the packet to the 1199 credit-control client. If the home Diameter AAA server receives a 1200 credit-control reject message, it will simply generate an 1201 appropriate authorization reject message to the credit-control 1202 client including the credit-control specific error code. 1204 The credit-control client in this model sends further credit-control 1205 messages to the credit-control server via the home Diameter AAA 1206 server. Upon receiving successful authorization answer message with 1207 the Granted-Service-Unit AVP(s), the credit-control client will 1208 grant the service to the end user and will generate intermediate 1209 credit-control request as required by using Credit-Control commands. 1210 The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 1211 (for how to produce unique value for the CC-Request-Number AVP see 1212 section 8.2). 1214 If service specific re-authorization is performed (i.e. 1215 authorization-lifetime expires), the credit-control client MUST add 1216 to the service specific re-authorization request the Credit-Control 1217 AVP with value set to RE-AUTHORIZATION to indicate that the credit- 1218 control server MUST NOT be contacted. When session based credit- 1219 control is used for the subscriber a constant Credit-Control 1220 messages stream is flowing through the home Diameter AAA server. The 1221 home Diameter AAA server can make use of this credit-control 1222 messages flow to deduce that user's activity is ongoing; hence it is 1223 recommended to set the authorization-lifetime to a reasonably high 1224 value when credit-control is used for the subscriber. 1226 In this scenario the home Diameter AAA server MUST advertise support 1227 for the credit-control application to its peers during the 1228 capability exchange process. 1230 The following diagram illustrates the use of authorization / 1231 authentication messages to perform the first interrogation. The 1232 parallel accounting stream is not shown in the figure. 1234 Diameter 1235 End-User Service Element AAA Server CC 1236 Server 1237 (CC Client) 1238 | Service Request | AA Request (CC AVPs) | 1239 |------------------>|------------------->| | 1240 | | | CCR(Initial, CC AVPs) 1241 | | |------------------->| 1242 | | | CCA(Granted-Units) 1243 | | |<-------------------| 1244 | | AA Answer(Granted-Units) | 1245 | Service Delivery |<-------------------| | 1246 |<----------------->| | | 1247 | : | | | 1248 | : | | | 1249 | : | | | 1250 | | | | 1251 | | CCR(Update,Used-Units) | 1252 | |------------------->| CCR(Update,Used-Units) 1253 | | |------------------->| 1254 | | | CCA(Granted-Units)| 1255 | | CCA(Granted-Units)|<-------------------| 1256 | |<-------------------| | 1257 | : | | | 1258 | : | | | 1259 | End of Service | | | 1260 |------------------>| CCR(Termination,Used-Units) | 1261 | |------------------->| CCR(Term.,Used-Units) 1262 | | |------------------->| 1263 | | | CCA | 1264 | | CCA |<-------------------| 1265 | |<-------------------| | 1267 Figure 3: Protocol example with use of the 1268 authorization messages for the first interrogation. 1270 5.3 Intermediate Interrogation 1272 When all of the granted service units for one unit type are spent by 1273 the end user or the Validity-Time is expired, the Diameter credit- 1274 control client MUST send a new Credit-Control-Request to the credit- 1275 control server. In the event that credit control for multiple 1276 services in one credit control session is applied (i.e. units are 1277 granted associated to Service-Identifier(s) or Rating-Group), a new 1278 Credit-Control-Request MUST be sent to the credit-control server 1279 when the whole credit reservation has been consumed, or upon 1280 expiration of the Validity-Time. It is always up to the Diameter 1281 credit-control client to send a new request well in advance before 1282 the expiration of the previous request in order to avoiding 1283 interruption in the service element. Even if the granted service 1284 units reserved by the credit-control server have not been spent upon 1285 expiration of the Validity-Time, the Diameter credit-control client 1286 MUST send a new Credit-Control-Request to the credit-control server. 1288 There can be also mid-session service events, which might affect the 1289 rating of the current service events. In this case a spontaneous 1290 updating (a new Credit-Control-Request) SHOULD be sent including 1291 information related to the service event even if all the granted 1292 service units have not been spent or the Validity-Time has not 1293 expired. 1295 When the used units are reported to the credit-control server, the 1296 credit-control client will not have any units in its possession 1297 before new granted units are received from the credit-control 1298 server. When the new granted units are received from the credit- 1299 control server these units apply from the point where the 1300 measurement of the reported used units stopped. Where independent 1301 credit-control of multiple services is supported, this process may 1302 be executed for one or more services, a single rating-group or for a 1303 pool within the (sub)session. 1305 The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the 1306 intermediate request message. The Subscription-Id AVP SHOULD be 1307 included in the intermediate message to identify the end user in the 1308 credit-control server. The Service-Context-Id AVP indicates the 1309 service specific document applicable to the request. 1311 The Requested-Service-Unit AVP MAY contain the new amount of 1312 requested service units. Where the Multiple-Services-Credit-Control 1313 AVP is used, it MUST contain the Requested-Service-Unit AVP if new 1314 quota for the associated service/rating-group is requested. The 1315 Used-Service-Unit AVP contains the amount of used service units 1316 measured from the point when the service became active or, in case 1317 of interim interrogations are used during the session, from the 1318 point when the previous measurement ended. The same unit types that 1319 are used in the previous message SHOULD be used. If several unit 1320 types were included in the previous answer message the used service 1321 units for each unit type MUST be reported. 1323 The Event-Timestamp AVP SHOULD be included in the request and 1324 contains the time of the event that triggered the sending of the new 1325 Credit-Control-Request. 1327 The credit-control server MUST deduct the used amount from the end 1328 user's account. It MAY rate the new request and make a new credit- 1329 reservation from the end user's account that covers the cost of the 1330 requested service event. 1332 The Credit-Control-Answer message with the CC-Request-Type AVP set 1333 to the value UPDATE_REQUEST MAY include the Cost-Information AVP 1334 containing the accumulated cost estimation for the session without 1335 taking any credit-reservation into account. 1336 The Credit-Control-Answer message MAY also include the Final-Unit- 1337 Indication AVP to indicate that the answer message contains the 1338 final units for the service. After the end user has consumed these 1339 units, the Diameter credit-control-client MUST behave as described 1340 in section 5.6. 1342 There can be several intermediate interrogations within a session. 1344 5.4 Final Interrogation 1346 When the end user terminates the service session or according to the 1347 graceful service termination as described in section 5.6, the 1348 Diameter credit-control client MUST send a final Credit-Control- 1349 Request message to the credit-control server. The CC-Request-Type 1350 AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id 1351 AVP indicates the service specific document applicable to the 1352 request. 1354 The Event-Timestamp AVP SHOULD be included in the request and 1355 contains the time of the session was terminated. 1357 The Used-Service-Unit AVP contains the amount of used service units 1358 measured from the point when the service became active or, in case 1359 of interim interrogations are used during the session, from the 1360 point when the previous measurement ended. If several unit types 1361 were included in the previous answer message the used service units 1362 for each unit type MUST be reported. 1364 After final interrogation the credit-control server MUST refund the 1365 reserved credit amount not used to the end user's account and deduct 1366 the used monetary amount from the end user's account. 1368 The Credit-Control-Answer message with the CC-Request-Type set to 1369 the value TERMINATION_REQUEST MAY include the Cost-Information AVP 1370 containing the estimated total cost for the session in question. 1372 If the user logoff during an ongoing credit-control session or some 1373 other reason causes the user to be logged-off (e.g. final-unit 1374 indication causes user logoff according to local policy) the service 1375 element, according to application specific policy, may send a 1376 session-termination-request (STR) to the home Diameter AAA server as 1377 usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit 1378 indication causes the user logoff upon consumption of the final 1379 granted units and STR is generated. 1381 End-User Service Element AAA Server CC 1382 Server 1383 (CC Client) 1384 | Service Delivery | | | 1385 |<----------------->| | | 1386 | : | | | 1387 | : | | | 1388 | : | | | 1389 | | | | 1390 | | CCR(Update,Used-Units) | 1391 | |------------------->| CCR(Update,Used-Units) 1392 | | |------------------->| 1393 | | CCA(Final-Unit, Terminate) 1394 | CCA(Final-Unit, Terminate)|<-------------------| 1395 | |<-------------------| | 1396 | : | | | 1397 | : | | | 1398 | Disconnect user | | | 1399 |<------------------| CCR(Termination,Used-Units) | 1400 | |------------------->| CCR(Term.,Used-Units) 1401 | | |------------------->| 1402 | | | CCA | 1403 | | CCA |<-------------------| 1404 | |<-------------------| | 1405 | | STR | | 1406 | |------------------->| | 1407 | | STA | | 1408 | |<-------------------| | 1409 Figure 4: User disconnected due to account exhausted 1411 5.5 Server-Initiated Credit Re-Authorization 1413 The Diameter Credit Control Application supports server-initiated 1414 re-authorization. The credit control server MAY optionally initiate 1415 the credit re-authorization by issuing a Re-Auth-Request (RAR) as 1416 defined in the Diameter base protocol [DIAMBASE]. The Auth- 1417 Application-Id in the RAR message is set to XXX [IANA please fill in 1418 XXX (suggested value 4 in section 12.1) and remove this note] to 1419 indicate the Diameter Credit Control Application and the Re-Auth- 1420 Request-Type is set to AUTHORIZE_ONLY. 1422 Section 5.1.2 defines the feature to enable credit-control for 1423 multiple services within a single (sub-)session where the server can 1424 authorize credit usage at a different level of granularity. Further, 1425 the server may provide credit resources to multiple services or 1426 rating groups as a pool (see section 5.1.2 for details and 1427 definitions). Therefore the server, based on its service logic and 1428 its knowledge of the ongoing session, can decide to request credit 1429 re-authorization for: a whole (sub-)session, a single credit pool, a 1430 single service or a single rating-group. To request credit re- 1431 authorization for a credit pool, the server includes in the RAR 1432 message the G-S-U-Pool-Identifier AVP indicating the affected pool. 1433 To request credit re-authorization for a service or a rating-group, 1434 the server includes in the RAR message the Service-Identifier AVP or 1435 the Rating-Group AVP respectively. To request credit re- 1436 authorization for all the ongoing services within the (sub-)session 1437 the server includes none of the above mentioned AVPs in the RAR 1438 message. 1440 If a credit re-authorization is not already ongoing (i.e. the credit 1441 control session is in OPEN state), a credit control client that 1442 receives such a RAR message with Session-Id equal to a currently 1443 active credit control session MUST acknowledge the request by 1444 sending the Re-Auth-Answer (RAA) message and MUST initiate the 1445 credit re-authorization towards the server by sending a Credit- 1446 Control-Request message with the CC-Request-Type AVP set to the 1447 value UPDATE_REQUEST. The Result-Code 2002 1448 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to 1449 indicate an additional message (i.e. CCR message with value 1450 UPDATE_REQUEST) is required to complete the procedure. If a quota 1451 was allocated to the service, the credit control client MUST report 1452 the used quota in the Credit-Control-Request. Note that the end user 1453 does not need to be prompted for the credit re-authorization, since 1454 the credit re-authorization is transparent to the user (i.e it takes 1455 place exclusively between the credit control client and the credit 1456 control server). 1458 Where multiple services in a user's session are supported, the 1459 procedure of the above paragraph will be executed at the granularity 1460 as requested by the server in the RAR message. 1462 If credit re-authorization is ongoing at the time when the RAR 1463 message is received (i.e. RAR-CCR collision), the credit control 1464 client successfully acknowledges the request but it does not 1465 initiate a new credit re-authorization. The Result-Code 2001 1466 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate a 1467 credit re-authorization procedure is already ongoing (i.e. the 1468 client was in PendingU state when the RAR was received). The credit 1469 control server SHOULD process the Credit-Control-Request as if it 1470 was received in answer to the server initiated credit re- 1471 authorization, and should consider the server initiated credit re- 1472 authorization process successful upon reception of the Re-Auth- 1473 Answer message. 1475 Where multiple services in a user's session are supported, it may 1476 happen that the server requests credit re-authorization for a credit 1477 pool (or for the (sub-)session) and a credit re-authorization is 1478 already ongoing for some of the services or rating-groups. In this 1479 case the client acknowledges the server request with a RAA message 1480 and MUST send a new Credit-Control-Request message to perform re- 1481 authorization for the remaining services/rating-groups. The Result- 1482 Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA 1483 message to indicate an additional message (i.e. CCR message with 1484 value UPDATE_REQUEST) is required to complete the procedure. The 1485 server processes the received requests and returns an appropriate 1486 answer to both of the requests. 1488 The above-defined procedures are enabled for each of the possibly 1489 active Diameter credit-control sub-sessions. The server MAY request 1490 re-authorization for an active sub-session by including the CC-Sub- 1491 Session-Id AVP in the RAR message in addition to the Session-Id AVP. 1493 5.6 Graceful Service Termination 1495 When the user's account runs out of money the user may be denied to 1496 compile additional chargeable events. However, the home service 1497 provider may offer some services, for instance access to a service 1498 portal where it is possible to refill the account, for which the 1499 user is allowed to benefit for a limited amount of time. This time 1500 is usually dependant on the home service provider policy. 1502 This section defines the graceful service termination optional 1503 feature that MAY be supported by the credit control server. Credit 1504 control client implementations MUST support the Final-Unit- 1505 Indication with at least the tear down of the ongoing service 1506 session upon the subscriber has consumed all the final granted 1507 units. 1509 Where independent credit control of multiple services in a single 1510 credit control (sub-)session is supported, it is possible to use the 1511 graceful service termination for each of the services/rating-groups 1512 independently. Naturally, the graceful service termination process 1513 defined in the following sub-sections will apply to the specific 1514 service/rating-group as requested by the server. 1516 In some service environments (e.g. NAS) the graceful service 1517 termination may be used to redirect the subscriber to a service 1518 portal for online balance refill or other services offered by the 1519 home service provider. In this case the graceful termination process 1520 installs a set of packet filters to restrict the user's access 1521 capability only to/from the specified destinations, all the IP 1522 packets not matching the filters will be dropped or possibly re- 1523 directed to the service portal. The user may also be displayed an 1524 appropriate notification why the access has been limited. These 1525 actions may be communicated explicitly from the server to client or 1526 may be configured per-service at the client. Explicitly signaled 1527 redirect or restrict instructions always take precedence over 1528 configured ones. 1530 It is also possible use the graceful service termination to connect 1531 the prepaid user to a top-up server that play an announcement and 1532 prompt the user to replenish the account. In such a case the credit 1533 control server sends only the address of the top-up server where the 1534 prepaid user shall be connected after the final granted units have 1535 been consumed. An example of this is given in Appendix A (Flow VII). 1537 The credit control server MAY initiate the graceful service 1538 termination by including the Final-Unit-Indication AVP in the Credit 1539 Control Answer to indicate that the message contains the final units 1540 for the service. 1542 When the credit control client receives the Final-Unit-Indication 1543 AVP in the answer from the server its behavior depends on the value 1544 indicated in the Final-Unit-Action AVP. The server may request the 1545 following actions: TERMINATE, REDIRECT and RESTRICT_ACCESS. 1547 The following Figure illustrates the graceful service termination 1548 procedure described in the following sub-sections. 1550 Diameter 1551 End-User Service Element AAA Server CC 1552 Server 1553 (CC Client) 1554 | Service Delivery | | | 1555 |<----------------->| | | 1556 | |CCR(Update,Used-Units) | 1557 | |------------------->|CCR(Update,Used-Units) 1558 | : | |------------------->| 1559 | : | |CCA(Final-Unit,Action) 1560 | : | |<-------------------| 1561 | |CCA(Final-Unit,Action) | 1562 | |<-------------------| | 1563 | | | | 1564 | : | | | 1565 | : | | | 1566 | : | | | 1567 | /////////////// |CCR(Update,Used-Units) | 1568 |/Final Units End/->|------------------->|CCR(Update,Used-Units) 1569 |/Action and // | |------------------->| 1570 |/Restrictions // | | CCA(Validity-Time)| 1571 |/Start // | CCA(Validity-Time)|<-------------------| 1572 | ///////////// |<-------------------| | 1573 | : | | | 1574 | : | | | 1575 | Replenish Account +-------+ | 1576 |<-------------------------------------------->|Account| | 1577 | | | +-------+ | 1578 | | | RAR | 1579 | + | RAR |<===================| 1580 | | |<===================| | 1581 | | | RAA | | 1582 | ///////////// | |===================>| RAA | 1583 | /If supported / | | CCR(Update) |===================>| 1584 | /by CC Server/ | |===================>| CCR(Update) | 1585 | ///////////// | | |===================>| 1586 | | | | CCA(Granted-Unit)| 1587 | | | CCA(Granted-Unit)|<===================| 1588 | Restrictions ->+ |<===================| | 1589 | removed | | | 1590 | : | | | 1591 | OR | CCR(Update) | | 1592 | Validity-Time ->|------------------->| CCR(Update) | 1593 | expires | |------------------->| 1594 | | | CCA(Granted-Unit)| 1595 | | CCA(Granted-Unit)|<-------------------| 1596 | Restrictions ->|<-------------------| | 1597 | removed | | | 1598 Figure 5: Optional graceful service termination procedure 1600 5.6.1 Terminate Action 1602 The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does 1603 not include any other information. When the subscriber has consumed 1604 the final granted units, the service element MUST terminate the 1605 service. This is the default handling applicable whenever the credit 1606 control client receives an unsupported Final-Unit-Action value and 1607 MUST be supported by all the Diameter credit control client 1608 implementations conforming to this specification. A final Credit- 1609 Control-Request message to the credit control server MUST be sent if 1610 the Final-Unit-Indication AVP indicating action TERMINATE was 1611 present at command level. The CC-Request-Type AVP in the request is 1612 set to the value TERMINATION_REQUEST. 1614 5.6.2 Redirect Action 1616 The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT 1617 indicates to the service element supporting this action that, upon 1618 consumption of the final granted units, the user MUST be re-directed 1619 to the address specified in the Redirect-Server AVP as follows. 1621 The credit control server sends the Redirect-Server AVP in the 1622 Credit-Control-Answer message. In such a case the service element 1623 MUST redirect or connect the user to the destination specified in 1624 the Redirect-Server AVP, if possible. When the end user is 1625 redirected (by using other protocols than Diameter) to the specified 1626 server or connected to the top-up server, an additional 1627 authorization (and possibly authentication) may be needed before the 1628 subscriber can replenish the account, however, this is out of the 1629 scope of this specification. 1631 In addition to the Redirect-Server AVP, the credit control server 1632 MAY include one or more Restriction-Filter-Rule AVP or one or more 1633 Filter-Id AVP in the Credit-Control-Answer message in order to 1634 enable the user to access other services (for example zero-rated 1635 services). In such a case the access device MUST drop all the 1636 packets not matching the IP filters specified in the Credit-Control- 1637 Answer message and redirect the user to the destination specified in 1638 the Redirect-Server AVP, if possible. 1640 Another entity than the credit control server may provision the 1641 access device with appropriate IP packet filters to be used in 1642 conjunction with the Diameter credit control application. This case 1643 is considered in section 5.6.3. 1645 When the final granted units have been consumed the credit control 1646 client MUST perform an intermediate interrogation. The purpose of 1647 this intermediate interrogation is to indicate to the credit control 1648 server that the specified action started and to report the used 1649 units. The credit control server MUST deduct the used amount from 1650 the end user's account but MUST NOT make a new credit reservation. 1651 The credit control client, however, may send intermediate 1652 interrogations before all the final granted units have been consumed 1653 for which rating and money reservation may be needed, for instance 1654 upon Validity-Time expires or upon mid-session service event that 1655 affect the rating of the current service. Therefore, the credit 1656 control client MUST NOT include any rating related AVP in the 1657 request sent upon all the final granted units have been consumed as 1658 an indication to the server that the requested final unit action 1659 started, rating and money reservation are not required (when the 1660 Multiple-Services-Credit-Control AVP is used, the Service-Identifier 1661 or Rating-Group AVPs is included to indicate the concerned 1662 services). Naturally, the Credit-Control-Answer message does not 1663 contain any granted service unit and MUST include the Validity-Time 1664 AVP to indicate to the credit control client how long the subscriber 1665 is allowed to use network resources before a new intermediate 1666 interrogation is sent to the server. 1668 At the expiry of Validity-Time the credit control client sends a 1669 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does 1670 not include the Used-Service-Unit AVP since there is no allotted 1671 quota to report. The credit control server processes the request and 1672 MUST perform the credit reservation. If during this time the 1673 subscriber did not replenish his/her account whether he/she will be 1674 disconnected or will be granted access to services not controlled by 1675 credit control server for unlimited time is dependent on the home 1676 service provider policy (note: the latter option implies that the 1677 service element should not remove the restriction filters upon 1678 termination of the credit control). The server will return the 1679 appropriate Result-Code (see section 9.1) in the Credit-Control- 1680 Answer message in order to implement the policy-defined action. 1681 Otherwise new quota will be returned, the service element MUST 1682 remove all the possible restrictions activated by the graceful 1683 service termination process and continue the credit control session 1684 and the service session as usual. 1686 The credit control client may not wait until the expiration of the 1687 Validity-Time and may send a spontaneous updating (a new Credit- 1688 Control-Request) if the service element can determine for instance 1689 that communication between the end user and the top-up server took 1690 place. An example of this is given in Appendix A (Figure A.8). 1692 It is worth noting that the credit control server may initiate the 1693 above-described process already for the first interrogation. 1694 However, the user's account might be empty at the time when the 1695 first interrogation is performed. In this case the subscriber can be 1696 offered a chance to replenish the account and continue the service. 1697 The credit control client receives a Credit-Control-Answer or 1698 service specific authorization answer with the Final-Unit-Indication 1699 AVP, Validity-Time AVP but no Granted-Unit. In such a case it 1700 immediately starts the graceful service termination without sending 1701 any message to the server. An example of this case is illustrated in 1702 Appendix A. 1704 5.6.3 Restrict Access Action 1706 The Final-Unit-Indication AVP with Final-Unit-Action RESTRICT_ACCESS 1707 indicates to the access device supporting this action that the user 1708 MUST be restricted access according to the IP packet filters given 1709 in the Restriction-Filter-Rule AVP(s) or according to the IP packet 1710 filters identified by the Filter-Id AVP(s). The credit control 1711 server SHOULD include either the Restriction-Filter-Rule AVP or the 1712 Filter-Id AVP in the Credit-Control-Answer message. 1714 Another entity than the credit control server may provision the 1715 access device with appropriate IP packet filters to be used in 1716 conjunction with the Diameter credit control application. Such an 1717 entity, for instance, may configure the access device with IP flows 1718 that are to be passed when the Diameter credit control application 1719 indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP 1720 packets according to the filter rules possibly received in the 1721 Credit-Control-Answer message in addition to the filter rules 1722 possibly configured by the other entity. However, the action to be 1723 taken when the user's account cannot cover the cost of the requested 1724 service is the responsibility of the credit control server that 1725 controls the prepaid subscriber. 1727 If another entity working in conjunction with the Diameter Credit 1728 Control application already provisions the access device with all 1729 the required filter rules for the end user, it is presumably not 1730 needed for the credit control server to send any additional filter. 1731 Therefore it is RECOMMENDED that credit control server 1732 implementations supporting the graceful service termination can be 1733 configurable whether to send the Restriction-Filter-Rule AVP, the 1734 Filter-Id AVP or none of the above. 1736 When the final granted units have been consumed, the credit control 1737 client MUST perform an intermediate interrogation. The credit 1738 control client and the credit control server process this 1739 intermediate interrogation and execute subsequent procedures as 1740 specified in the previous section for the REDIRECT action. 1742 The credit control server may initiate the graceful service 1743 termination with action RESTRICT_ACCESS already for the first 1744 interrogation as specified in the previous section for the REDIRECT 1745 action. 1747 5.6.4 Usage of the Server-Initiated Credit Re-Authorization 1749 Once the subscriber replenishes the account she presumably expects 1750 all the restrictions placed by the graceful termination procedure be 1751 immediately removed and unlimited services' access be resumed. For 1752 the best user experience the credit control server implementation 1753 MAY support the server-initiated credit re-authorization (see 1754 section 5.5). In such a case, upon the successful account top-up 1755 took place, the credit control server sends the Re-Auth-Request 1756 (RAR) message to solicit the credit re-authorization. The credit 1757 control client initiates the credit re-authorization by sending the 1758 Credit- Control-Request message with the CC-Request-Type AVP set to 1759 the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included 1760 in the request since there is no allotted quota to report. The 1761 Requested-Service-Unit AVP MAY be included in the request. After the 1762 credit control client successfully receives the Credit-Control- 1763 Answer with new Granted-Service-Unit all the possible restrictions 1764 activated for the purpose of the graceful service termination MUST 1765 be removed in the service element, the credit control session and 1766 the service session continue as usual. 1768 5.7 Failure Procedures 1770 The Credit-Control-Failure-Handling AVP (CCFH) as described in this 1771 section determines the behavior of the credit control client in 1772 fault situations. The CCFH may be received from the Diameter home 1773 AAA server, from the credit control server or may be locally 1774 configured. The CCFH value received from the home AAA server 1775 overrides the locally configured value and the CCFH value received 1776 from the credit control server in the Credit-Control-Answer message 1777 always override any already existing value. 1779 The authorization server MAY include the Accounting-Realtime- 1780 Required AVP to determine what to do if the sending of accounting 1781 records to the accounting server has been temporarily prevented as 1782 defined in [DIAMBASE]. It is RECOMMENDED that the client complement 1783 the credit-control failure procedures with backup accounting flow 1784 towards an accounting server. Using different combinations of 1785 Accounting-Realtime-Required and Credit-Control-Failure-Handling 1786 AVPs different safety levels can be built. For example by choosing 1787 the Credit-Control-Failure-Handling AVP equal to CONTINUE for the 1788 credit control flow and Accounting-Realtime-Required AVP equal to 1789 DELIVER_AND_GRANT for the accounting flow, the service can be 1790 granted to the end user even if the connection to the credit-control 1791 server is down but the accounting server is able to collect the 1792 accounting information, provided that there is information exchange 1793 taking place between the accounting server and credit-control 1794 server. 1796 Since the credit-control application is based on real-time bi- 1797 directional communication between the credit-control client and the 1798 credit-control server, the usage of alternative destinations and the 1799 buffering of messages may not be sufficient in the event of 1800 communication failures. Since the credit-control server has to 1801 maintain session states, moving the credit-control message stream to 1802 a backup server requires a complex context transfer solution. 1803 Whether the credit-control message stream is moved to a backup 1804 credit-control server during an ongoing credit-control session 1805 depends on the value of the CC-session-Failover AVP. However, 1806 failover may occur at any point in the path between credit-control 1807 client and credit-control server in the event that a transport 1808 failure is detected with a peer, as described in [DIAMBASE]. As a 1809 consequence the credit-control server might receive duplicate 1810 messages. These duplicates or out of sequence messages can be 1811 detected in the credit-control server based on the credit-control 1812 server session state machine (section 7), Session-Id AVP and CC- 1813 Request-Number AVP. 1815 If a failure occurs during an ongoing credit-control session, the 1816 credit-control client may move the credit control message stream to 1817 an alternative server if the CC-server indicated FAILOVER_SUPPORTED 1818 in the CC-Session-Failover AVP. A secondary credit control server 1819 name, received from the home Diameter AAA server or locally 1820 configured, can be used as an address of the backup server. If the 1821 CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the credit 1822 control message stream MUST NOT be moved to backup server. 1824 For new credit control sessions, failover to an alternative credit- 1825 control server SHOULD be performed if possible. For instance, if an 1826 implementation of the credit control client can determine primary 1827 credit control server unavailability it can establish the new credit 1828 control sessions with a possibly available secondary credit control 1829 server. 1831 The AAA transport profile [AAATRANS] defines the application layer 1832 watchdog algorithm that enables failover from a peer that has failed 1833 and is controlled by a watchdog timer (Tw) defined in [AAATRANS]. 1834 The recommended default initial value for Tw (Twinit) is 30 seconds. 1835 Twinit may be set as low as 6 seconds, however, according to 1836 [AAATRANS] setting too low value for Twinit is likely to result in 1837 an increased probability of duplicates, as well as an increase in 1838 spurious failover and failback attempts. Since the Diameter base 1839 protocol is common to several different types of Diameter AAA 1840 applications that may be run in the same service element, tuning the 1841 timer Twinit to a lower value in order to satisfy the requirements 1842 of real-time applications, such as the Diameter Credit Control 1843 application, will certainly materialize the above mentioned 1844 problems. For prepaid services, however, the end user expects an 1845 answer from the network in a reasonable time, thus the Diameter 1846 credit control client shall react faster than the underlying base 1847 protocol. Therefore this specification defines the timer Tx that is 1848 used by the credit-control client (as defined in section 13) to 1849 supervise the communication with the credit-control server. When the 1850 timer Tx elapses the credit-control client takes an action to the 1851 end user according to the Credit-Control-Failure-Handling AVP. 1853 When Tx expires, the Diameter credit control client always 1854 terminates the service if the Credit-Control-Failure-Handling (CCFH) 1855 AVP is set to the value TERMINATE. The credit control session may be 1856 moved to an alternative server only in case a protocol error 1857 DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before 1858 Tx expires, therefore, the value TERMINATE is not appropriate if 1859 proper failover behavior is desired. 1861 If the Credit-Control-Failure-Handling AVP is set to the value 1862 CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the 1863 end user upon the timer Tx expires. An answer message with granted- 1864 units may arrive later on due to the base protocol transport 1865 failover occurred in the path to the Credit Control Server (Twinit 1866 default value is 3 times more than the Tx recommended value). The 1867 credit control client SHOULD grant the service to the end user, 1868 start monitoring the resource usage and wait for the possible late 1869 answer until the timeout of the request (e.g. 120 seconds). If the 1870 request fails and the CC-Session-Failover AVP is set to FAILOVER_NOT 1871 SUPPORTED, the credit control client terminates or continues the 1872 service depending on the value set in the CCFH and MUST free all the 1873 reserved resources for the credit control session. If a protocol 1874 error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or 1875 the request timeout and the CC-Session-Failover AVP is set to 1876 FAILOVER SUPPORTED, the credit control client MAY send the request 1877 to a backup server if possible. If the credit control client 1878 receives a successful answer from the backup server, it continues 1879 the credit control session with such a server. If also the re- 1880 transmitted request fails, the credit control client terminates or 1881 continues the service depending on the value set in the CCFH and 1882 MUST free all the reserved resources for the credit control session. 1884 If a communication failure occurs during the graceful service 1885 termination procedure, the service element SHOULD always terminate 1886 the ongoing service session. 1888 If the credit-control server detects a failure during an ongoing 1889 credit-control session, it will terminate the credit-control session 1890 and return the reserved units back to the end user's account. 1892 The supervision session timer Tcc (as defined in section 13) is used 1893 in the credit-control server to supervise the credit-control 1894 session. 1896 In order to support the failover between credit control servers 1897 information transfer about the credit control session and account 1898 state SHOULD take place between the primary and the secondary credit 1899 control server. Implementations supporting the credit control 1900 session failover MUST also ensure proper detection of duplicate or 1901 out of sequence messages. The communication between the servers is 1902 regarded as an implementation issue and is outside of the scope of 1903 this specification. 1905 6. One Time Event 1907 The one-time event is used when there is no need to maintain any 1908 state in the Diameter credit-control server, for example enquiring 1909 the price of the service. The use of one-time event implies that the 1910 user has been authenticated and authorized beforehand. 1911 The one time event can be used when the credit-control client wants 1912 to know the cost of the service event without any credit-reservation 1913 or to check the account balance without any credit-reservation. It 1914 can be used also for refunding service units on the user's account 1915 or direct debiting without any credit-reservation. The one time 1916 event is shown in Figure 6. 1918 Diameter 1920 End-User Service Element AAA Server CC 1921 Server 1922 (CC Client) 1923 | Service Request | | | 1924 |------------------>| | | 1925 | | CCR(Event) | | 1926 | |------------------->| CCR(Event) | 1927 | | |------------------->| 1928 | | | CCA(Granted-Units)| 1929 | | CCA(Granted-Units)|<-------------------| 1930 | Service Delivery |<-------------------| | 1931 |<----------------->| | | 1933 Figure 6: One time event 1935 In environments such as the 3GPP architecture the one time event can 1936 be sent from the service element directly to the credit-control 1937 server. 1939 6.1 Service Price Enquiry 1941 The credit-control client may need to know the price of the service 1942 event. There might exist services offered by application service 1943 providers, whose prices are not known in the credit-control client. 1944 End user might also want to get an estimation of the price of a 1945 service event before requesting it. 1947 A Diameter credit-control client requesting the cost information 1948 MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include the 1949 Requested-Action AVP set to PRICE_ENQUIRY and set the requested 1950 service event information into the Service-Identifier AVP in the 1951 Credit-Control-Request message. Additional service event information 1952 may be sent as service specific AVPs or may be sent within the 1953 Service-Parameter-Info AVP. The Service-Context-Id AVP indicates the 1954 service specific document applicable to the request. 1956 The credit-control server calculates the cost of the requested 1957 service event, but it does not perform any account balance check or 1958 credit-reservation from the account. 1960 The estimated cost of the requested service event is returned to the 1961 credit-control client in the Cost-Information AVP in the Credit- 1962 Control-Answer message. 1964 6.2 Balance Check 1966 The Diameter credit-control client may need only to verify that the 1967 end user's account balance covers the cost for a certain service 1968 without reserving any units from the account at the time of the 1969 inquiry. This method does not guarantee that there would be credit 1970 left when the Diameter credit-control client requests the debiting 1971 of the account with a separate request. 1973 A Diameter credit-control client requesting the balance check MUST 1974 set the CC-Request-Type AVP equal to EVENT_REQUEST, include 1975 Requested-Action AVP set to CHECK_BALANCE and include the 1976 Subscription-Id AVP to identify the End-User in the credit-control 1977 server. The Service-Context-Id AVP indicates the service specific 1978 document applicable to the request. 1980 The credit-control server makes the balance check, but it does not 1981 do any credit-reservation from the account. 1983 The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to 1984 the credit-control client in the Check-Balance-Result AVP in the 1985 Credit-Control-Answer message. 1987 6.3 Direct Debiting 1989 There are certain service events for which service execution is 1990 always successful in the service environment. The delay between the 1991 service invocation and the actual service delivery to the end user 1992 can be sufficiently long that the use of the session-based credit- 1993 control would lead to unreasonable long credit-control sessions. In 1994 these cases the Diameter credit-control client can use the one-time 1995 event scenario for direct debiting. The Diameter credit-control 1996 client SHOULD be sure that the requested service event execution 1997 would be successful, when this scenario is used. 1999 The CC-Request-Type is set to the value EVENT_REQUEST and the 2000 Requested-Action AVP set to DIRECT_DEBITING in the Credit-Control- 2001 Request message. The Subscription-Id AVP SHOULD be included to 2002 identify the End-User in the credit-control server. The Event- 2003 Timestamp AVP SHOULD be included in the request and contains the 2004 time when the service event is requested in the service element. The 2005 Service-Context-Id AVP indicates the service specific document 2006 applicable to the request. 2008 The Diameter credit-control client MAY include the monetary amount 2009 to be charged in the Requested-Service-Unit AVP, if it knows the 2010 cost of the service event. If the Diameter credit-control client 2011 does not know the cost of the service event, the Requested-Service- 2012 Unit AVP MAY contain the number of requested service events. The 2013 Service-Identifier AVP always indicates the concerned service, 2014 additional service event information to be rated MAY be sent as 2015 service specific AVPs or MAY be sent within the Service-Parameter- 2016 Info AVP. 2018 The credit-control server SHOULD rate the service event and deduct 2019 the corresponding monetary amount from end user's account. If the 2020 type of the Requested-Service-Unit AVP is money, no rating is needed 2021 but the corresponding monetary amount is deducted from the End 2022 User's account. 2024 The credit-control server returns the Granted-Service-Unit AVP in 2025 the Answer message to the Diameter credit-control client. The 2026 Granted-Service-Unit AVP contains the amount of service units that 2027 the Diameter credit-control client can provide to the end user. The 2028 type of the Granted-Service-Unit can be time, volume, service 2029 specific or money depending on the type of service event. 2031 If the credit-control server determines that no credit-control is 2032 needed for the service it can include the result code indicating 2033 that the credit-control is not applicable (e.g. service is free of 2034 charge). 2036 For informative purposes, the Credit-Control-Answer message MAY also 2037 include the Cost-Information AVP containing the estimated total cost 2038 of the requested service. 2040 6.4 Refund 2042 Some services may refund service units to the end user's account, 2043 for example gaming services. 2045 The credit-control client MUST set CC-Request-Type to the value 2046 EVENT_REQUEST and the Requested-Action AVP to REFUND in the Credit- 2047 Control-Request message. The Subscription-Id AVP SHOULD be included 2048 to identify the End-User in the credit-control server. The Service- 2049 Context-Id AVP indicates the service specific document applicable to 2050 the request. 2052 The Diameter credit-control client MAY include the monetary amount 2053 to be refunded in the Requested-Service-Unit AVP. The Service- 2054 Identifier AVP always indicates the concerned service. If the 2055 Diameter credit-control client does not know the monetary amount to 2056 be refunded, in addition to the Service-Identifier AVP it MAY send 2057 service specific AVPs or the Service-Parameter-Info AVP containing 2058 additional service event information to be rated. 2060 For informative purposes, the Credit-Control-Answer message MAY also 2061 include the Cost-Information AVP containing the estimated monetary 2062 amount of refunded unit. 2064 6.5 Failure Procedure 2066 Failover to an alternative credit-control server is allowed for one 2067 time event since the server is not maintaining session states, for 2068 instance, if the credit control client receives a protocol error 2069 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY it can re-send the 2070 request to an alternative server if possible. There MAY exist 2071 protocol transparent Diameter relays and redirect agents or Diameter 2072 credit-control proxies between credit-control client and credit- 2073 control server. Failover may occur at any point in the path between 2074 credit-control client and credit-control server in the event that a 2075 transport failure is detected with a peer, as described in 2076 [DIAMBASE]. Because there can be duplicate requests for various 2077 reasons the credit-control server is therefore responsible for the 2078 real time duplicate detection. Implementation issues for duplicate 2079 detection are discussed in [DIAMBASE] Appendix C. 2081 When the credit-control client detects a communication failure to 2082 the credit-control server, its behavior depends on the requested 2083 action. The timer Tx (as defined in section 13) is used in the 2084 credit-control client to supervise the communication with the 2085 credit-control server. 2087 In case the requested action is PRICE_ENQUIRY or BALANCE_CHECK and 2088 communication failure is detected the credit-control client SHOULD 2089 forward the request messages to an alternative credit-control 2090 server, if possible. The secondary Credit control server name, if 2091 received from the home Diameter AAA server, can be used as an 2092 address of backup server. 2094 If the requested action is DIRECT_DEBITING the Direct-Debiting- 2095 Failure-Handling AVP (DDFH) controls the credit control client 2096 behavior. The DDFH may be received from the home Diameter AAA server 2097 or may be locally configured. The credit control server may also 2098 send the DDFH in any CCA message to be used for direct debiting 2099 events compiled thereafter. The DDFH value received from the home 2100 Diameter AAA server overrides the locally configured value and the 2101 DDFH value received from the credit control server in a Credit- 2102 Control-Answer message always override any already existing value. 2104 If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client 2105 SHOULD NOT grant the service if it can determine, eventually after a 2106 possible re-transmission attempt to an alternative credit control 2107 server, from the result code or error code in the answer message 2108 that units have not been debited. Otherwise the credit-control 2109 client SHOULD grant the service to the end user and store the 2110 request in the credit-control application level non-volatile storage 2111 (Note that re-sending the request at a later time is not a guarantee 2112 that the service will be debited, since the user's account may be 2113 empty at the time when the server successfully processes the 2114 request). The credit-control client MUST mark these request messages 2115 as possible duplicate by setting the T-flag in the command header as 2116 described in [DIAMBASE] section 3. 2117 If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 2118 service SHOULD be granted even if credit-control messages cannot be 2119 delivered and messages are not buffered. 2121 If the timer Tx expires the credit-control client MUST continue the 2122 service and wait for a possible late answer. If the request timeout 2123 the credit control client re-transmit the request (marked with T- 2124 flag) to a backup credit control server if possible. In the event 2125 that also the re-transmitted request timeout or a temporary error is 2126 received in answer to such a request, the credit control client 2127 buffers the request if the value of the Direct-Debiting-Failure- 2128 Handling AVP is set to TERMINATE_OR_BUFFER. If a failed answer is 2129 received for the re-transmitted request, the credit control client 2130 frees all the resources reserved for the event message and deletes 2131 the request regardless the value of the DDFH. 2133 The Credit-Control-Request with requested action REFUND should 2134 always be stored in the credit-control application level non- 2135 volatile storage in case of temporary failure. The credit-control 2136 client MUST mark the re-transmitted request message as possible 2137 duplicate by setting the T-flag in the command header as described 2138 in [DIAMBASE] section 3. 2140 For stored requests, the implementation may choose to limit the 2141 number of re-transmission attempts and define a re-transmission 2142 interval. 2144 It should be noted that only one place in the credit-control system 2145 SHOULD be responsible for duplicate detection. If there is only one 2146 credit-control server within the given realm, the credit-control 2147 server may perform duplicate detection. In case when more than one 2148 credit-control servers are serving a given realm, only one entity in 2149 the credit control system should be responsible to ensure that the 2150 end user's account is not debited or credited multiple times for the 2151 same service event. 2153 7. Credit Control Application State Machine 2155 This section defines the credit control application state machine. 2157 The first four state machines are to be observed by credit-control 2158 clients. The first one describes the session-based credit-control 2159 when the first interrogation is executed as part of the 2160 authorization/authentication process. The second one describes the 2161 session-based credit-control when the first interrogation is 2162 executed after the authorization/authentication process. The 2163 requirements what state machine need to be supported are discussed 2164 in section 5.2. 2166 The third state machine describes the session-based credit-control 2167 for intermediate and final interrogations. The fourth one describes 2168 the event-based credit-control. These latter state machines are to 2169 be observed by all the implementations that conform to this 2170 specification. 2172 The fifth state machine describes the credit-control session from a 2173 credit-control server perspective. 2175 Any event not listed in the state machines MUST be considered as an 2176 error condition, and a corresponding answer, if applicable, MUST be 2177 returned to the originator of the message. 2179 In the state table, the event 'Failure to send' means that the 2180 Diameter credit-control client is unable to communicate with the 2181 desired destination or with a possibly defined alternative 2182 destination in case failover procedure is supported (e.g. the 2183 request timeout and the answer message is not received). This could 2184 be due to the peer being down, or due to a physical link failure in 2185 the path to/from the credit-control server. 2187 The event 'Temporary error' means that the Diameter credit-control 2188 client received a protocol error notification DIAMETER_TOO_BUSY, 2189 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_LOOP_DETECTED in the Result- 2190 Code AVP of the Credit-Control-Answer command. The above protocol 2191 error notification may be ultimately received in answer to the re- 2192 transmitted request to a possibly defined alternative destination if 2193 failover is supported. 2195 The event 'Failed answer' means that the Diameter credit-control 2196 client received non-transient failure (permanent failure) 2197 notification in the Credit-Control-Answer command. The above 2198 permanent failure notification may be ultimately received in answer 2199 to the re-transmitted request to a possibly defined alternative 2200 destination if failover is supported. 2201 The action 'store request' means that a request is stored in the 2202 credit-control application level non-volatile storage. 2204 The event 'Not successfully processed' means that the credit-control 2205 server could not process the message, e.g. due to unknown end user, 2206 account being empty or due to errors defined in [DIAMBASE]. 2208 The event 'User service terminated' can be triggered by various 2209 reasons, e.g. normal user termination, network failure and ASR 2210 (Abort-Session-Request). The Termination-Cause AVP contains 2211 information about the termination reason as specified in [DIAMBASE]. 2213 The Tx timer, which is used to control the waiting time in the 2214 Credit control client in the PENDING state, is stopped when exiting 2215 the Pending state. The stopping of the Tx timer is omitted in the 2216 state machine when the new state is Idle since moving to Idle state 2217 implies the clearing of the session and all the variables associated 2218 to it. 2220 The states PendingI, PendingU, PendingT PendingE and PendingB stand 2221 for pending states to wait for an answer to a credit control request 2222 related to Initial, Update, Termination, Event or Buffered request 2223 respectively. 2225 The abbreviations CCFH and DDFH stand for Credit-Control-Failure- 2226 Handling and Direct-Debiting-Failure-Handling respectively. 2228 In the following state machine table the failover to a possibly 2229 secondary server upon 'Temporary error' or 'Failure to send' is not 2230 explicitly described. Moving an ongoing credit control message 2231 stream to an alternative server is, however, possible if the CC- 2232 Session-Failover AVP is set to FAILOVER_SUPPORTED as described in 2233 section 5.7. 2235 Re-sending a credit control event to an alternative server is 2236 supported as described in section 6.5. 2238 CLIENT, SESSION BASED for the first interrogation with AA request 2240 State Event Action New State 2241 --------------------------------------------------------------- 2242 Idle Client or device requests Send PendingI 2243 access/service AA request 2244 with added 2245 CC AVPs, 2246 start Tx 2248 PendingI Successful AA req. Grant Open 2249 answer received service to 2250 end user, 2251 stop Tx 2253 PendingI Tx expired Disconnect Idle 2254 user/dev 2256 PendingI Failed AA answer received Disconnect Idle 2257 user/dev 2259 PendingI AA answer Grant Idle 2260 received with result code service 2261 equal to CREDIT_CONTROL_ to end user 2262 NOT_APPLICABLE 2264 PendingI User service terminated Queue PendingI 2265 termination 2266 event 2268 PendingI Change in rating condition Queue PendingI 2269 changed 2270 rating 2271 condition 2272 event 2273 CLIENT, SESSION BASED for the first interrogation with CCR 2275 State Event Action New State 2276 ---------------------------------------------------------------- 2278 Idle Client or device requests Send PendingI 2279 access/service CC initial 2280 req., 2281 start Tx. 2283 PendingI Successful CC initial Stop Tx Open 2284 answer received 2286 PendingI Failure to send, or Grant Idle 2287 temporary error and service to 2288 CCFH equal to CONTINUE end user 2290 PendingI Failure to send, or Terminate Idle 2291 temporary error and end user's 2292 CCFH equal to TERMINATE service 2293 or equal to RETRY_AND_TERMINATE 2295 PendingI Tx expired and CCFH Terminate Idle 2296 equal to TERMINATE end user's 2297 service 2299 PendingI Tx expired and CCFH equal Grant PendingI 2300 to CONTINUE or equal to service to 2301 RETRY_AND_TERMINATE end user 2303 PendingI CC initial answer Terminate Idle 2304 received with result code end user's 2305 SERVICE_ DENIED or service 2306 USER_UNKNOWN 2308 PendingI CC initial answer Grant Idle 2309 received with result code service 2310 equal to CREDIT_CONTROL_ to end user 2311 NOT_APPLICABLE 2313 PendingI Failed CC initial answer Grant Idle 2314 received CCFH equal to Service to 2315 CONTINUE end user 2317 PendingI Failed CC initial answer Terminate Idle 2318 received and CCFH equal end user's 2319 to TERMINATE or equal to service 2320 RETRY_AND_TERMINATE 2322 PendingI User service terminated Queue PendingI 2323 termination 2324 event 2326 PendingI Change in rating condition Queue PendingI 2327 changed 2328 rating 2329 condition 2330 event 2332 CLIENT, SESSION BASED for intermediate and final interrogations 2334 State Event Action New State 2335 ---------------------------------------------------------------- 2337 Open Granted unit elapses Send PendingU 2338 and no final unit CC update 2339 indication received req., 2340 start Tx. 2342 Open Granted unit elapses Terminate PendingT 2343 and final unit action end user's 2344 equal to TERMINATE service, send 2345 received CC termination 2346 req. 2348 Open Change in rating condition Send PendingU 2349 in queue CC update 2350 req., 2351 Start Tx. 2353 Open Service terminated in queue Send PendingT 2354 CC termination 2355 req. 2357 Open Change in rating condition Send PendingU 2358 or Validity-Time elapses CC update 2359 req., 2360 Start Tx. 2362 Open User service terminated Send PendingT 2363 CC termination 2364 req. 2366 Open RAR received Send RAA PendingU 2367 followed by 2368 CC update req., 2369 start Tx 2371 PendingU Successful CC update Stop Tx Open 2372 answer received 2374 PendingU Failure to send, or Grant Idle 2375 temporary error and service to 2376 CCFH equal to CONTINUE end user 2378 PendingU Failure to send, or Terminate Idle 2379 temporary error and end user's 2380 CCFH equal to TERMINATE service 2381 or equal to RETRY_AND_TERMINATE 2383 PendingU Tx expired and CCFH Terminate Idle 2384 equal to TERMINATE end user's 2385 service 2387 PendingU Tx expired and CCFH equal Grant PendingU 2388 to CONTINUE or equal to service to 2389 RETRY_AND_TERMINATE end user. 2391 PendingU CC update answer Terminate Idle 2392 received with result code end user's 2393 SERVICE_DENIED service 2395 PendingU CC update answer Grant Idle 2396 received with result code service 2397 equal to CREDIT_CONTROL_ to end user 2398 NOT_APPLICABLE 2400 PendingU Failed CC update Grant Idle 2401 answer received and service to 2402 CCFH equal to CONTINUE end user. 2404 PendingU Failed CC update Terminate Idle 2405 answer received CCFH end user's 2406 equal to TERMINATE or service 2407 equal to RETRY_AND_TERMINATE 2409 PendingU User service terminated Queue PendingU 2410 termination 2411 event 2413 PendingU Change in rating Queue PendingU 2414 condition changed 2415 rating 2416 condition 2417 event 2419 PendingU RAR received Send RAA PendingU 2421 PendingT Successful CC Idle 2422 termination answer received 2424 PendingT Failure to send, or temporary Idle 2425 error or failed answer 2427 PendingT Change in rating condition PendingT 2429 CLIENT, EVENT BASED 2431 State Event Action New State 2432 ---------------------------------------------------------------- 2433 Idle Client or device requests Send PendingE 2434 a one-time service CC event 2435 req., 2436 Start Tx. 2438 Idle Request in storage Send PendingB 2439 stored 2440 request 2442 PendingE Successful CC event Grant Idle 2443 answer received service to 2444 end user 2446 PendingE Failure to send, temporary Indicate Idle 2447 error or failed CC event service 2448 answer received, or error 2449 Tx expired, requested 2450 action BALANCE_CHECK or 2451 PRICE_ENQUIRY 2453 PendingE CC event answer Terminate Idle 2454 received with result code end user's 2455 SERVICE_DENIED or service 2456 USER_UNKNOWN and Tx running 2458 PendingE CC event answer Grant Idle 2459 received with result code service 2460 CREDIT_CONTROL_NOT_APPLICABLE, to end 2461 requested action user 2462 DIRECT_DEBITING 2464 PendingE Failure to send, temporary Grant Idle 2465 error or failed CC event service 2466 answer received, requested to end 2467 action DIRECT_DEBITING and user 2468 DDFH equal to CONTINUE 2470 PendingE Failed CC event Terminate Idle 2471 answer received or temporary end user's 2472 error, requested action service 2473 DIRECT_DEBITING and 2474 DDFH equal to 2475 TERMINATE_OR_BUFFER and 2476 Tx running 2478 PendingE Tx expired, requested Grant PendingE 2479 action DIRECT_DEBITING service 2480 to end 2481 user 2483 PendingE Failure to send, requested Store Idle 2484 action DIRECT_DEBITING and request with 2485 DDFH equal to T-flag 2486 TERMINATE_OR_BUFFER 2488 PendingE Temporary error, requested Store Idle 2489 action DIRECT_DEBITING and request 2490 DDFH equal to 2491 TERMINATE_OR_BUFFER and 2492 Tx expired 2494 PendingE Failed answer or answer Idle 2495 received with result code 2496 SERVICE DENIED or USER_UNKNOWN, 2497 requested action 2498 DIRECT_DEBITING and Tx expired 2500 PendingE Failed CC event answer Indicate Idle 2501 received, requested service 2502 action REFUND_ACCOUNT error and 2503 delete request 2505 PendingE Failure to send or Store Idle 2506 Tx expired, requested request 2507 action REFUND_ACCOUNT with T-flag 2509 PendingE Temporary error Store Idle 2510 and requested action request 2511 REFUND_ACCOUNT 2513 PendingB Successful CC answer Delete Idle 2514 received request 2516 PendingB Failed CC answer Delete Idle 2517 received request 2519 PendingB Failure to send or Idle 2520 temporary error 2522 SERVER, SESSION AND EVENT BASED 2524 State Event Action New State 2525 ---------------------------------------------------------------- 2527 Idle CC initial request Send Open 2528 received and successfully CC initial 2529 processed. answer, 2530 reserve units, 2531 start Tcc 2533 Idle CC initial request Send Idle 2534 received, but not CC initial 2535 successfully processed. answer with 2536 Result-Code 2537 != SUCCESS 2539 Idle CC event request Send Idle 2540 received and successfully CC event 2541 processed. answer 2543 Idle CC event request Send Idle 2544 received, but not CC event 2545 successfully processed. answer with 2546 Result-Code 2547 != SUCCESS 2549 Open CC update request Send CC Open 2550 received and successfully update answer, 2551 processed debit used 2552 units and 2553 reserve 2554 new units, 2555 Restart Tcc 2557 Open CC update request Send Idle 2558 received, but not CC update 2559 successfully processed. answer with 2560 Result-Code 2561 != SUCCESS, 2562 debit used 2563 units 2565 Open CC termination request Send Idle 2566 received, and successfully CC termin. 2567 processed answer, 2568 Stop Tcc, 2569 debit used 2570 units 2572 Open CC termination request Send Idle 2573 received, but not CC termin. 2574 successfully processed. answer with 2575 Result-Code 2576 != SUCCESS, 2577 debit used 2578 units 2580 Open Session supervision timer Tcc release Idle 2581 expired reserved 2582 units 2584 8. Credit Control AVPs 2586 This section defines the credit-control AVPs that are specific to 2587 Diameter Credit-control Application and MAY be included in the 2588 Diameter credit control messages. 2590 The AVPs defined in this section MAY also be included in 2591 authorization commands defined in authorization specific 2592 applications, such as [NASREQ] and [DIAMMIP], in case the first 2593 interrogation is performed as part of the authorization / 2594 authentication process as described in section 5.2. 2596 The Diameter AVP rules are defined in the Diameter Base [DIAMBASE], 2597 section 4. These AVP rules are observed in AVPs defined in this 2598 section. 2600 The following table describes the Diameter AVPs defined in Credit- 2601 control application, their AVP Code values, types, possible flag 2602 values and whether the AVP MAY be encrypted. The Diameter base 2603 [DIAMBASE] specifies in the section 4.5 the AVP Flag rules for AVPs. 2605 +--------------------+ 2606 | AVP Flag rules | 2607 |----+-----+----+----|----+ 2608 AVP Section | | |SHLD|MUST| | 2609 Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr| 2610 -----------------------------------------|----+-----+----+----|----| 2611 CC-Correlation-Id TBD 8.1 OctetString| | P,M | | V | Y | 2612 CC-Input-Octets TBD 8.24 Unsigned64 | M | P | | V | Y | 2613 CC-Money TBD 8.22 Grouped | M | P | | V | Y | 2614 CC-Output-Octets TBD 8.25 Unsigned64 | M | P | | V | Y | 2615 CC-Request-Number TBD 8.2 Unsigned32 | M | P | | V | Y | 2616 CC-Request-Type TBD 8.3 Enumerated | M | P | | V | Y | 2617 CC-Service- TBD 8.26 Unsigned64 | M | P | | V | Y | 2618 Specific-Units | | | | | | 2619 CC-Session- TBD 8.4 Enumerated | M | P | | V | Y | 2620 Failover | | | | | | 2621 CC-Sub-Session-Id TBD 8.5 Unsigned64 | M | P | | V | Y | 2622 CC-Time TBD 8.21 Unsigned32 | M | P | | V | Y | 2623 CC-Total-Octets TBD 8.23 Unsigned64 | M | P | | V | Y | 2624 CC-Unit-Type TBD 8.32 Enumerated | M | P | | V | Y | 2625 Check-Balance- TBD 8.6 Enumerated | M | P | | V | Y | 2626 Result | | | | | | 2627 Cost-Information TBD 8.7 Grouped | M | P | | V | Y | 2628 Cost-Unit TBD 8.12 UTF8String | M | P | | V | Y | 2629 Credit-Control TBD 8.13 Enumerated | M | P | | V | Y | 2630 Credit-Control- TBD 8.14 Enumerated | M | P | | V | Y | 2631 Failure-Handling | | | | | | 2632 Currency-Code TBD 8.18 Unsigned32 | M | P | | V | Y | 2633 Direct-Debiting TBD 8.19 Enumerated | M | P | | V | Y | 2634 Failure-Handling | | | | | | 2635 Exponent TBD 8.9 Integer32 | M | P | | V | Y | 2636 Final-Unit-Action TBD 8.35 Enumerated | M | P | | V | Y | 2637 Final-Unit- TBD 8.34 Grouped | M | P | | V | Y | 2638 Indication | | | | | | 2639 Granted-Service- TBD 8.17 Grouped | M | P | | V | Y | 2640 Unit | | | | | | 2641 G-S-U-Pool- TBD 8.32 Unsigned32 | M | P | | V | Y | 2642 Identifier | | | | | | 2643 G-S-U-Pool- TBD 8.25 Grouped | M | P | | V | Y | 2644 Reference | | | | | | 2645 Multiple-Services TBD 8.16 Grouped | M | P | | V | Y | 2646 -Credit-Control | | | | | | 2647 Multiple-Services TBD 8.40 Enumerated | M | P | | V | Y | 2648 -Indicator | | | | | | 2649 Rating-Group TBD 8.29 Unsigned32 | M | P | | V | Y | 2650 Redirect-Address TBD 8.38 Enumerated | M | P | | V | Y | 2651 -Type | | | | | | 2652 Redirect-Server TBD 8.37 Grouped | M | P | | V | Y | 2653 Redirect-Server TBD 8.39 UTF8String | M | P | | V | Y | 2654 -Address | | | | | | 2655 Requested-Action TBD 8.41 Enumerated | M | P | | V | Y | 2656 Requested-Service TBD 8.18 Grouped | M | P | | V | Y | 2657 Unit | | | | | | 2658 Restriction TBD 8.36 IPFiltrRule| M | P | | V | Y | 2659 -Filter-Rule | | | | | | 2660 Service-Context TBD 8.42 UTF8String | M | P | | V | Y | 2661 -Id | | | | | | 2662 Service- TBD 8.28 UTF8String | M | P | | V | Y | 2663 Identifier | | | | | | 2664 Service-Parameter TBD 8.43 Grouped | | P,M | | V | Y | 2665 -Info | | | | | | 2666 Service- TBD 8.44 Unsigned32 | | P,M | | V | Y | 2667 Parameter-Type | | | | | | 2668 Service- TBD 8.45 OctetString| | P,M | | V | Y | 2669 Parameter-Value | | | | | | 2670 Subscription-Id TBD 8.46 Grouped | M | P | | V | Y | 2671 Subscription-Id TBD 8.48 UTF8String | M | P | | V | Y | 2672 -Data | | | | | | 2673 Subscription-Id TBD 8.47 Enumerated | M | P | | V | Y | 2674 -Type | | | | | | 2675 Tariff-Change TBD 8.27 Enumerated | M | P | | V | Y | 2676 -Usage | | | | | | 2677 Tariff-Time TBD 8.20 Time | M | P | | V | Y | 2678 -Change | | | | | | 2679 Unit-Value TBD 8.8 Grouped | M | P | | V | Y | 2680 Used-Service-Unit TBD 8.19 Grouped | M | P | | V | Y | 2681 User-Equipment TBD 8.49 Grouped | | P,M | | V | Y | 2682 -Info | | | | | | 2683 User-Equipment TBD 8.50 Enumerated | | P,M | | V | Y | 2684 -Info-Type | | | | | | 2685 User-Equipment TBD 8.51 OctetString| | P,M | | V | Y | 2686 -Info-Value | | | | | | 2687 Value-Digits TBD 8.10 Integer64 | M | P | | V | Y | 2688 Validity-Time TBD 8.33 Unsigned32 | M | P | | V | Y | 2690 [IANA please fill in the TBD values in this table with appropriate 2691 AVP codes, suggested values listed below and remove this note.] 2693 8.1 CC-Correlation-Id AVP 2695 The CC-Correlation-Id AVP (AVP Code XXX - IANA please fill in and 2696 remove this note - suggested value 411) is of type OctetString and 2697 contains information to correlate credit control requests generated 2698 for different components of the service, e.g. transport and service 2699 level. The one who allocates the Service-Context-Id, i.e. unique 2700 identifier of a service specific document, is also responsible to 2701 define the content and encoding of the CC-Correlation-Id AVP. 2703 8.2 CC-Request-Number AVP 2705 The CC-Request-Number AVP (AVP Code XXX - IANA please fill in and 2706 remove this note - suggested value 415) is of type Unsigned32 and 2707 identifies this request within one session. As Session-Id AVPs are 2708 globally unique, the combination of Session-Id and CC-Request-Number 2709 AVPs is also globally unique, and can be used in matching credit 2710 control messages with confirmations. An easy way to produce unique 2711 numbers is to set the value to 0 for credit control request of type 2712 INITIAL_REQUEST and EVENT_REQUEST, and set the value to 1 for the 2713 first UPDATE_REQUEST, 2 for the second, and so on until the value 2714 for 2715 TERMINATION_REQUEST. 2717 8.3 CC-Request-Type AVP 2719 The CC-Request-Type AVP (AVP Code XXX - IANA please fill in and 2720 remove this note - suggested value 416) is of type Enumerated and 2721 contains the reason for sending the Credit-control request message. 2722 It MUST be present in all CC-Request messages. The following values 2723 are defined for the CC-Request-Type AVP: 2725 INITIAL_REQUEST 1 2726 A Credit-control Initial request is used to initiate a credit 2727 control session, and contains credit control information that is 2728 relevant to the initiation of the session. 2730 UPDATE_REQUEST 2 2731 An Update Credit-control request contains credit control 2732 information for an existing credit control session. Update 2733 Credit-control requests SHOULD be sent every time a credit- 2734 control re-authorization is needed at the expiry of the allocated 2735 quota or validity time. Further, additional service-specific 2736 events MAY trigger a spontaneous Update request. 2738 TERMINATION_REQUEST 3 2739 A Credit-control Termination Request is sent to terminate a 2740 credit-control session and contains credit control information 2741 relevant to the existing session. 2743 EVENT_REQUEST 4 2744 A Credit Control Event Request is used when there is no need 2745 to maintain any credit control session state in the credit- 2746 control server. This request contains all information relevant to 2747 the service, and is the only request of the service. The reason 2748 for the Event request is further detailed in the Requested-Action 2749 AVP. The Requested-Action AVP MUST be included in the Credit- 2750 Control-Request message when CC-Request-Type is set to 2751 EVENT_REQUEST. 2753 8.4 CC-Session-Failover AVP 2755 The CC-Session-Failover AVP (AVP Code XXX - IANA please fill in and 2756 remove this note - suggested value 418) is type of Enumerated and 2757 contains information whether the moving of the credit-control 2758 message stream to a backup server during an ongoing credit-control 2759 session is supported. In case of communication failures, the credit 2760 control message streams can be moved to an alternative destination 2761 if the credit control server supports failover to an alternative 2762 server. The secondary credit control server name, if received from 2763 the home Diameter AAA server, can be used as an address of the 2764 backup server. An implementation is not required to support the 2765 moving of credit control message stream to an alternative server, 2766 since it requires also moving of information related to the credit 2767 control session to backup server. 2769 The following values are defined for the CC-Session-Failover AVP: 2771 FAILOVER_NOT_SUPPORTED 0 2772 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED 2773 the Credit control message stream MUST NOT to be moved to 2774 alternative destination in case of communication failure. 2776 This is the default behavior if the AVP isn't included in the 2777 reply from the authorization or credit-control server. 2779 FAILOVER_SUPPORTED 1 2780 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, 2781 the Credit control message stream SHOULD be moved to alternative 2782 destination in case of communication failure. The moving the 2783 credit control message stream to backup server MAY require that 2784 information related to the credit control session should be also 2785 forwarded to alternative server. 2787 8.5 CC-Sub-Session-Id AVP 2788 The CC-Sub-Session-Id AVP (AVP Code XXX - IANA please fill in and 2789 remove this note - suggested value 419) is of type Unsigned64 and 2790 contains the credit-control sub-session identifier. The combination 2791 of the Session-Id and this AVP MUST be unique per sub-session, and 2792 the value of this AVP MUST be monotonically increased by one for all 2793 new sub-sessions. The absence of this AVP implies no sub-sessions 2794 are in use. 2796 8.6 Check-Balance-Result AVP 2798 The Check Balance Result AVP (AVP Code XXX - IANA please fill in and 2799 remove this note - suggested value 422) is of type Enumerated and 2800 contains the result of the balance check. This AVP is applicable 2801 only when the Requested-Action AVP indicates CHECK_BALANCE in the 2802 Credit-Control-Request command. 2804 The following values are defined for the Check-Balance-Result AVP. 2806 ENOUGH_CREDIT 0 2807 There is enough credit in the account to cover the requested 2808 service. 2810 NO_CREDIT 1 2811 There isn't enough credit in the account to cover the requested 2812 service. 2814 8.7 Cost-Information AVP 2816 The Cost-Information AVP (AVP Code XXX - IANA please fill in and 2817 remove this note - suggested value 423) is of type Grouped and it is 2818 used to return the cost information of a service, which the credit 2819 control client can transfer transparently to the end user. The 2820 included Unit-Value AVP contains the cost estimate (always type of 2821 money) of the service in case of price enquiry or the accumulated 2822 cost estimation in the case of credit-control session. 2824 The Currency-Code specifies in which currency the cost was given. 2825 The Cost-Unit specifies the unit when the service cost is a cost per 2826 unit (e.g. cost for the service is $1 per minute). 2828 When the Requested-Action AVP with value PRICE_ENQUIRY is included 2829 in the Credit-Control-Request command the Cost-Information AVP sent 2830 in the succeeding Credit-Control-Answer command contains the cost 2831 estimation of the requested service, without any reservation being 2832 made. 2834 The Cost-Information AVP included in the Credit-Control-Answer 2835 command with the CC-Request-Type set to UPDATE_REQUEST contains the 2836 accumulated cost estimation for the session without taking any 2837 credit-reservation into account. 2839 The Cost-Information AVP included in the Credit-Control-Answer 2840 command with the CC-Request-Type set to EVENT_REQUEST or 2841 TERMINATION_REQUEST contains the estimated total cost for the 2842 requested service. 2844 It has the following ABNF grammar: 2846 Cost-Information ::= < AVP Header: TBD > 2847 { Unit-Value } 2848 { Currency-Code } 2849 [ Cost-Unit ] 2851 8.8 Unit-Value AVP 2853 Unit-Value AVP is of type Grouped (AVP Code XXX - IANA please fill 2854 in and remove this note - suggested value 445) and specifies the 2855 units as decimal value. The Unit-Value is a value together with an 2856 exponent, i.e. Unit-Value = Value-Digits AVP * 10^Exponent. This 2857 representation avoids unwanted rounding off. For example the value 2858 of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The 2859 absence of exponent part MUST be interpreted as exponent being equal 2860 to zero. 2862 It has the following ABNF grammar: 2864 Unit-Value ::= < AVP Header: TBD > 2865 { Value-Digits } 2866 [ Exponent ] 2868 8.9 Exponent AVP 2870 Exponent AVP is of type Integer32 (AVP Code XXX - IANA please fill 2871 in and remove this note - suggested value 429) and contains the 2872 exponent value to be applied for the Value-Digit AVP within the 2873 Unit-Value AVP. 2875 8.10 Value-Digits AVP 2877 The Value-Digits AVP is of type Integer64 (AVP Code XXX - IANA 2878 please fill in and remove this note - suggested value 447) and 2879 contains the significant digits of the number. If decimal values are 2880 needed to present the units, the scaling MUST be indicated with the 2881 related Exponent AVP. For example for the monetary amount $ 0.05 the 2882 value of Value-Digits AVP MUST be set to 5 and the scaling MUST be 2883 indicated with the Exponent AVP set to -2. 2885 8.11 Currency-Code AVP 2887 The Currency-Code AVP (AVP Code XXX - IANA please fill in and remove 2888 this note - suggested value 425) is of type Unsigned32 and contains 2889 a currency code that specifies in which currency the values of AVPs 2890 containing monetary units were given. It is specified using the 2891 numeric values defined in the ISO 4217 standard [ISO4217]. 2893 8.12 Cost-Unit AVP 2895 The Cost-Unit AVP (AVP Code XXX - IANA please fill in and remove 2896 this note - suggested value 424) is of type UTF8String and it is 2897 used 2898 to display human readable string to the end user. It specifies the 2899 applicable unit to the Cost-Information when the service cost is a 2900 cost per unit (e.g. cost of the service is $1 per minute). The Cost- 2901 Unit can be for instance minute, hour, day, kilobytes, megabytes 2902 etc. 2904 8.13 Credit-Control AVP 2906 The Credit-Control AVP (AVP Code XXX - IANA please fill in and 2907 remove this note - suggested value 426) is of type Enumerated and 2908 MUST be included in AA requests when service element has credit 2909 control capabilities. 2911 CREDIT_AUTHORIZATION 0 2912 If the home Diameter AAA server determines the user is a prepaid 2913 user, this value indicates that credit-control server MUST be 2914 contacted to perform the first interrogation. The value of the 2915 Credit-Control AVP MUST always be set to 0 in AA request sent to 2916 perform the first interrogation and initiate a new credit-control 2917 session. 2919 RE_AUTHORIZATION 1 2920 This value indicates to the Diameter AAA server that a credit- 2921 control session is ongoing for the subscriber and the credit- 2922 control server MUST not be contacted. The Credit-Control AVP set 2923 to the value of 1 is to be used only when the first interrogation 2924 has been successfully performed and the credit-control session is 2925 ongoing (i.e. re-authorization triggered by Authorization- 2926 Lifetime). This value MUST NOT be used in AA request sent to 2927 perform the first interrogation. 2929 8.14 Credit-Control-Failure-Handling AVP 2931 The Credit-Control-Failure-Handling AVP (AVP Code XXX - IANA please 2932 fill in and remove this note - suggested value 427) is of type 2933 Enumerated. The credit-control client uses information in this AVP 2934 to decide what to do if the sending of credit-control messages to 2935 the credit-control server has been for instance temporarily 2936 prevented due to a network problem. Depending on the service logic, 2937 the credit-control server can order the client to terminate the 2938 service immediately when there is a reason to believe that the 2939 service cannot be charged, or to try failover to an alternative 2940 server, if possible, and then either terminate or grant the service 2941 should also the alternative connection fail. 2943 TERMINATE 0 2944 When the Credit-Control-Failure-Handling AVP is set to TERMINATE 2945 the service MUST only be granted as long as there is a connection 2946 to the credit-control server. If the credit-control client does 2947 not receive any Credit-Control-Answer message within the Tx timer 2948 (as defined in section 13) the credit-control request is regarded 2949 failed and the end user's service session is terminated. 2951 This is the default behavior if the AVP isn't included in the 2952 reply from the authorization or credit-control server. 2954 CONTINUE 1 2955 When the Credit-Control-Failure-Handling AVP is set to CONTINUE 2956 the credit-control client SHOULD re-send the request to an 2957 alternative server in case of transport or temporary failures, 2958 provided that failover procedure is supported in the credit- 2959 control server and the credit-control client, and an alternative 2960 server is available. Otherwise, the service SHOULD be granted 2961 even if credit-control messages can't be delivered. 2963 RETRY_AND_TERMINATE 2 2964 When the Credit-Control-Failure-Handling AVP is set to 2965 RETRY_AND_TERMINATE the credit-control client SHOULD re-send the 2966 request to an alternative server in case of transport or 2967 temporary failures, provided that failover procedure is 2968 supported in the credit-control server and the credit-control 2969 client, and an alternative server is available. Otherwise, the 2970 service SHOULD not be granted when the credit-control messages 2971 can't be delivered. 2973 8.15 Direct-Debiting-Failure-Handling AVP 2975 The Direct-Debiting-Failure-Handling AVP (AVP Code XXX - IANA please 2976 fill in and remove this note - suggested value 428) is of type 2977 Enumerated. The credit-control client uses information in this AVP 2978 to decide what to do if the sending of credit-control messages 2979 (Requested-Action AVP set to Direct Debiting) to the credit-control 2980 server has been for instance temporarily prevented due to a network 2981 problem. 2983 TERMINATE_OR_BUFFER 0 2984 When the Direct-Debiting-Failure-Handling AVP is set to 2985 TERMINATE_OR_BUFFER the service MUST be granted as long as there 2986 is a connection to the credit-control server. If the credit- 2987 control client does not receive any Credit-Control-Answer 2988 message within the Tx timer (as defined in section 13) the 2989 credit-control request is regarded failed. The client SHOULD 2990 terminate the service if it can determine from the failed answer 2991 that units have not been debited. Otherwise the credit-control 2992 client SHOULD grant the service, store the request to 2993 application level non-volatile storage and try to re-send the 2994 request. These requests MUST be marked as possible duplicate by 2995 setting the T-flag in the command header as described in 2996 [DIAMBASE] section 3. 2998 This is the default behavior if the AVP isn't included in the 2999 reply from the authorization server. 3001 CONTINUE 1 3002 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE 3003 the service SHOULD be granted even if credit-control messages 3004 can't be delivered and the request should be deleted. 3006 8.16 Multiple-Services-Credit-Control AVP 3008 Multiple-Services-Credit-Control AVP (AVP Code XXX - IANA please 3009 fill in and remove this note - suggested value 456) is of type 3010 Grouped and contains the AVPs related to the independent credit 3011 control of multiple services feature. Note that each instance of 3012 this AVP carries units related to one or more services or related to 3013 a single rating-group. 3015 The Service-Identifier and the Rating-Group AVPs are used to 3016 associate the granted units to a given service or rating group. 3017 In case both the Service-Identifier and the Rating-Group AVPs are 3018 included, the target of the service units is always the service(s) 3019 indicated by the value of the Service-Identifier AVP(s). If only the 3020 Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control 3021 AVP relates to all the services that belong to the specified rating 3022 group. 3024 The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- 3025 Pool-Identifier identifying a credit pool within which the units of 3026 the specified type are considered to be pooled. If a G-S-U-Pool- 3027 Reference AVP is present then actual service units of the specified 3028 type MUST also be present. For example, if the G-S-U-Pool-Reference 3029 AVP specifies Unit-Type TIME, then the CC-Time AVP MUST be present. 3031 The Requested-Service-Unit AVP MAY contain the amount of requested 3032 service units or the requested monetary value. It MUST be present in 3033 the initial interrogation and within the intermediate interrogations 3034 where new quota is requested. If the credit-control client does not 3035 include the Requested-Service-Unit AVP in a request command, for 3036 instance because it has determined that the end-user terminated the 3037 service, the server MUST debit the used amount from the user's 3038 account but MUST NOT return a new quota in the corresponding answer. 3039 The Validity-Time, Result-Code and Final-Unit-Indication AVPs MAY be 3040 present in an answer command as defined in section 5.1.2 and 5.6 for 3041 the graceful service termination. 3043 When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are 3044 present, the server MUST include two separate instances of the 3045 Multiple-Services-Credit-Control AVP with the Granted-Service-Unit 3046 AVP associated to the same Service-Identifier and/or Rating-Group. 3047 Where the two quotas are associated to the same pool or to different 3048 pools, the credit pooling mechanism as defined in section 5.1.2 3049 applies. The Tariff-Change-Usage AVP MUST NOT be included in request 3050 commands, to report used units before and after tariff time change 3051 the Used-Service-Unit AVP MUST be used. 3052 A server not implementing the independent credit control of multiple 3053 services functionality MUST treat the Multiple-Services-Credit- 3054 Control AVP as invalid AVP. 3056 The Multiple-Services-Control AVP has the following ABNF grammar: 3058 Multiple-Services-Credit-Control ::= < AVP Header: TBD > 3059 [ Granted-Service-Unit ] 3060 [ Requested-Service-Unit ] 3061 *[ Used-Service-Unit ] 3062 [ Tariff-Change-Usage ] 3063 *[ Service-Identifier ] 3064 [ Rating-Group ] 3065 *[ G-S-U-Pool-Reference ] 3066 [ Validity-Time ] 3067 [ Result-Code ] 3068 [ Final-Unit-Indication ] 3069 *[ AVP ] 3071 8.17 Granted-Service-Unit AVP 3072 Granted-Service-Unit AVP (AVP Code XXX - IANA please fill in and 3073 remove this note - suggested value 431) is of type Grouped and 3074 contains the amount of units that the Diameter credit-control client 3075 can provide to the end user until the service must be released or 3076 the new Credit-Control-Request must be sent. A client is not 3077 required to implement all of the unit types, and must treat unknown 3078 or unsupported unit types in the answer message as an incorrect CCA 3079 answer. In that case the client MUST terminate the credit control 3080 session and indicate in the Termination-Cause AVP reason 3081 DIAMETER_BAD_ANSWER. 3083 The Granted-Service-Unit AVP has the following ABNF grammar: 3085 Granted-Service-Unit ::= < AVP Header: TBD > 3086 [ Tariff-Time-Change ] 3087 [ CC-Time ] 3088 [ CC-Money ] 3089 [ CC-Total-Octets ] 3090 [ CC-Input-Octets ] 3091 [ CC-Output-Octets ] 3092 [ CC-Service-Specific-Units ] 3093 *[ AVP ] 3095 8.18 Requested-Service-Unit AVP 3097 The Requested-Service-Unit AVP (AVP Code XXX - IANA please fill in 3098 and remove this note - suggested value 437) is of type Grouped and 3099 contains the amount of requested units specified by the Diameter 3100 credit-control client. A server is not required to implement all of 3101 the unit types, and must treat unknown or unsupported unit types as 3102 invalid AVPs. 3104 The Requested-Service-Unit AVP has the following ABNF grammar: 3106 Requested-Service-Unit ::= < AVP Header: TBD > 3107 [ CC-Time ] 3108 [ CC-Money ] 3109 [ CC-Total-Octets ] 3110 [ CC-Input-Octets ] 3111 [ CC-Output-Octets ] 3112 [ CC-Service-Specific-Units ] 3113 *[ AVP ] 3115 8.19 Used-Service-Unit AVP 3117 The Used-Service-Unit AVP is of type Grouped AVP (AVP Code XXX - 3118 IANA please fill in and remove this note - suggested value 446) and 3119 contains the amount of used units measured from the point when the 3120 service became active or, in case of interim interrogations are used 3121 during the session, from the point when the previous measurement 3122 ended. 3124 The Used-Service-Unit AVP has the following ABNF grammar: 3126 Used-Service-Unit ::= < AVP Header: TBD > 3127 [ Tariff-Change-Usage ] 3128 [ CC-Time ] 3129 [ CC-Money ] 3130 [ CC-Total-Octets ] 3131 [ CC-Input-Octets ] 3132 [ CC-Output-Octets ] 3133 [ CC-Service-Specific-Units ] 3134 *[ AVP ] 3136 8.20 Tariff-Time-Change AVP 3138 The Tariff-Time-Change AVP (AVP Code XXX - IANA please fill in and 3139 remove this note - suggested value 451) is of type Time, it is sent 3140 from the server to the client and includes the time in seconds since 3141 January 1, 1900 00:00 UTC when the tariff of the service will be 3142 changed. 3144 The tariff change mechanism is optional for client and server and it 3145 is not used for time-based services as defined in the section 5. 3146 If a client does not support the tariff time change mechanism it 3147 MUST treat Tariff-Time-Change AVP in the answer message as an 3148 incorrect 3149 CCA answer. In that case the client terminates the credit control 3150 session and indicate in the Termination-Cause AVP reason 3151 DIAMETER_BAD_ANSWER. 3153 Omission of this AVP means that no tariff change is to be reported. 3155 8.21 CC-Time AVP 3157 The CC-Time AVP (AVP Code XXX - IANA please fill in and remove this 3158 note - suggested value 420) is of type Unsigned32, and indicates the 3159 length of the requested, granted or used time in seconds. 3161 8.22 CC-Money AVP 3163 The CC-Money AVP (AVP Code XXX - IANA please fill in and remove this 3164 note - suggested value 413) is of type Grouped, and specifies the 3165 monetary amount in the given currency. The Currency-Code AVP SHOULD 3166 be included. It has the following ABNF grammar: 3168 CC-Money ::= < AVP Header: TBD > 3169 { Unit-Value } 3170 [ Currency-Code ] 3172 8.23 CC-Total-Octets AVP 3174 The CC-Total-Octets AVP (AVP Code XXX - IANA please fill in and 3175 remove this note - suggested value 421) is of type Unsigned64, and 3176 contains the total number of requested, granted or used octets 3177 regardless of the direction (sent or received). 3179 8.24 CC-Input-Octets AVP 3181 The CC-Input-Octets AVP (AVP Code XXX - IANA please fill in and 3182 remove this note - suggested value 412) is of type Unsigned64, and 3183 contains the number of requested, granted or used octets that can 3184 be/have been received from the end user. 3186 8.25 CC-Output-Octets AVP 3188 The CC-Output-Octets AVP (AVP Code XXX - IANA please fill in and 3189 remove this note - suggested value 414) is of type Unsigned64, and 3190 contains the number of requested, granted or used octets that can 3191 be/have been sent to the end user. 3193 8.26 CC-Service-Specific-Units AVP 3195 The CC-Service-Specific-Units AVP (AVP Code XXX - IANA please fill 3196 in and remove this note - suggested value 417) is of type 3197 Unsigned64, and specifies the number of service specific units (e.g. 3198 number of events, points) given in a selected service. The service 3199 specific units always refer to the service identified in the 3200 Service-Identifier AVP (or Rating-Group AVP when the Multiple- 3201 Services-Credit-Control AVP is used). 3203 8.27 Tariff-Change-Usage AVP 3205 The Tariff-Change-Usage AVP (AVP Code XXX - IANA please fill in and 3206 remove this note - suggested value 452) is of type Enumerated and 3207 defines whether units are used before or, after a tariff change, or 3208 the units straddled tariff change when a tariff change has occurred 3209 during the reporting period. 3210 Omission of this AVP means that no tariff change has occurred. 3212 In addition, when present in answer messages as part of the 3213 Multiple-Services-Credit-Control AVP, this AVP defines whether units 3214 are allocated to be used before or after a tariff change event. 3216 Omission of this AVP in answer messages when the Tariff-Time-Change 3217 AVP is present means that the single quota mechanism applies. 3219 Tariff-Change-Usage can be one of the following: 3221 UNIT_BEFORE_TARIFF_CHANGE 0 3222 When present in the Multiple-Services-Credit-Control AVP, this 3223 value indicates the amount of the units allocated for use before 3224 a tariff change occurs. 3226 When present in the Used-Service-Unit AVP, this value indicates 3227 the amount of resource units used before a tariff change had 3228 occurred. 3230 UNIT_AFTER_TARIFF_CHANGE 1 3231 When present in the Multiple-Services-Credit-Control AVP, this 3232 value indicates the amount of the units allocated for use after a 3233 tariff change occurs. 3235 When present in the Used-Service-Unit AVP, this value indicates 3236 the amount of resource units used after tariff change had 3237 occurred. 3239 UNIT_INDETERMINATE 2 3240 The used unit contains the amount of units that straddle the 3241 tariff change (e.g. the metering process reports to the credit- 3242 control client in blocks of n octets and one block straddled the 3243 tariff change). This value is to be used only in the Used- 3244 Service-Unit AVP. 3246 8.28 Service-Identifier AVP 3248 The Service-Identifier AVP is of type Unsigned32 (AVP Code XXX - 3249 IANA please fill in and remove this note - suggested value 439) and 3250 contains the identifier of a service. The specific service that the 3251 request relates to is uniquely identified by the combination of 3252 Service-Context-Id and Service-Identifier AVPs. 3254 A usage example of this AVP is illustrated in Appendix A (Flow IX). 3256 8.29 Rating-Group AVP 3258 The Rating-Group AVP is of type Unsigned32 (AVP Code XXX - IANA 3259 please fill in and remove this note - suggested value 432) and 3260 contains the identifier of a rating group. All the services subject 3261 to the same rating type are part of the same rating group. The 3262 specific rating group that the request relates to is uniquely 3263 identified by the combination of Service-Context-Id and Rating-Group 3264 AVPs. 3266 A usage example of this AVP is illustrated in Appendix A (Flow IX). 3268 8.30 G-S-U-Pool-Reference AVP 3270 The G-S-U-Pool-Reference AVP (AVP Code XXX - IANA please fill in and 3271 remove this note - suggested value 457) is of type Grouped, it is 3272 used in the Credit-Control-Answer message and associates the 3273 Granted-Service-Units AVP within which it appears with a credit pool 3274 within the session. 3276 The G-S-U-Pool-Identifier AVP specifies the credit pool from which 3277 credit is drawn for this unit type. 3279 The CC-Unit-Type AVP specifies the type of units for which credit is 3280 pooled. 3282 The Unit-Value AVP specifies the multiplier, which converts between 3283 service units of type CC-Unit-Type and abstract service units within 3284 the credit pool (and hence to service units of any other service or 3285 rating group associated with the same pool). 3287 The G-S-U-Pool-Reference AVP has the following ABNF grammar: 3289 G-S-U-Pool-Reference ::= < AVP Header: TBD > 3290 { G-S-U-Pool-Identifier } 3291 { CC-Unit-Type } 3292 { Unit-Value } 3294 8.31 G-S-U-Pool-Identifier AVP 3296 The G-S-U-Pool-Identifier AVP (AVP Code XXX - IANA please fill in 3297 and remove this note - suggested value 453) is of type Unsigned32 3298 and identifies a 'credit pool' within the session. 3300 8.32 CC-Unit-Type AVP 3302 The CC-Unit-Type AVP (AVP Code XXX - IANA please fill in and remove 3303 this note - suggested value 454) is of type Enumerated and specifies 3304 the type of units which are considered to be pooled into a credit 3305 pool. 3307 The following values are defined for the CC-Unit-Type AVP: 3308 TIME 0 3309 MONEY 1 3310 TOTAL-OCTETS 2 3311 INPUT-OCTETS 3 3312 OUTPUT-OCTETS 4 3313 SERVICE-SPECIFIC-UNITS 5 3315 8.33 Validity-Time AVP 3317 The Validity-Time AVP is of type Unsigned32 (AVP Code XXX - IANA 3318 please fill in and remove this note - suggested value 448) and it is 3319 sent from the credit-control server to the credit-control client. 3320 The AVP contains the validity time of the granted service units. The 3321 measurement of the Validity-Time is started at reception of the 3322 Credit-Control-Answer Message containing this AVP. If the granted 3323 service units have not been consumed within the validity time 3324 specified in this AVP, the credit-control client MUST send a Credit- 3325 Control-Request message to the server with CC-Request-Type set to 3326 UPDATE_REQUEST. The value field of the Validity-Time AVP is given in 3327 seconds. 3329 The Validity-Time AVP is also used for the graceful service 3330 termination (see section 5.6) to indicate to the credit control 3331 client how long the subscriber is allowed to use network resources 3332 after the specified action (i.e. REDIRECT or RESTRICT_ACCESS) 3333 started. Upon the Validity-Time elapses a new intermediate 3334 interrogation is sent to the server. 3336 8.34 Final-Unit-Indication AVP 3338 The Final-Unit-Indication AVP (AVP Code XXX - IANA please fill in 3339 and remove this note - suggested value 430) is of type Grouped and 3340 indicates that the Granted-Service-Unit AVP in the Credit-Control- 3341 Answer, or in the AA answer, contains the final units for the 3342 service. After these units have expired, the Diameter credit-control 3343 client is responsible for executing the action indicated in the 3344 Final-Unit-Action AVP (see section 5.6). 3346 If more than one unit types are received in the Credit-Control- 3347 Answer, the Unit type which first expired SHOULD cause the credit- 3348 control client to execute the specified action. 3350 In the first interrogation, the Final-Unit-Indication AVP with 3351 Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present 3352 with no Granted-Service-Unit AVP in the Credit-Control-Answer or in 3353 the AA answer. This indicates to the Diameter credit-control client 3354 to immediately execute the specified action. If the home service 3355 provider policy is to terminate the service, naturally, the server 3356 SHOULD return the appropriate transient failure (see section 9.1) in 3357 order to implement the policy-defined action. 3359 The Final-Unit-Action AVP defines the behavior of the service 3360 element when the user's account cannot cover the cost of the service 3361 and MUST always be present if the Final-Unit-Indication AVP is 3362 included in a command. 3364 If the Final-Unit-Action AVP is set to TERMINATE no other AVPs MUST 3365 be present. 3367 If the Final-Unit-Action AVP is set to REDIRECT at least the 3368 Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP 3369 or the Filter-Id AVP MAY be present in the Credit-Control-Answer 3370 message if the user is allowed to access also other services not 3371 accessible through the address given in the Redirect-Server AVP. 3373 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS either the 3374 Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 3376 The Filter-Id AVP is defined in [NASREQ]. The Filter-Id AVP can be 3377 used to reference an IP filter list installed in the access device 3378 by other means than the Diameter Credit Control Application e.g. 3379 locally configured or configured by another entity. 3381 The Final-Unit-Indication AVP has the following ABNF grammar: 3383 Final-Unit-Indication ::= < AVP Header: TBD > 3384 { Final-Unit-Action } 3385 *[ Restriction-Filter-Rule ] 3386 *[ Filter-Id ] 3387 [ Redirect-Server ] 3389 8.35 Final-Unit-Action AVP 3391 The Final-Unit-Action AVP (AVP Code XXX - IANA please fill in and 3392 remove this note - suggested value 449) is of type Enumerated and 3393 indicates to the credit-control client the action to be taken when 3394 the user's account cannot cover the service cost. 3396 The Final-Unit-Action can be one of the following: 3398 TERMINATE 0 3399 The credit control client MUST terminate the service session. 3400 This is the default handling applicable whenever the credit 3401 control client receives an unsupported Final-Unit-Action value 3402 and MUST be supported by all the Diameter credit control client 3403 implementations conforming to this specification. 3405 REDIRECT 1 3406 The service element MUST redirect the user to the address 3407 specified in the Redirect-Server-Address AVP. The redirect action 3408 is defined in section 5.6.2. 3410 RESTRICT_ACCESS 2 3411 The access device MUST restrict the user access according to the 3412 IP packet filters defined in the Restriction-Filter-Rule AVP or 3413 according to the IP packet filters identified by the Filter-Id 3414 AVP. All the packets not matching the filters MUST be dropped 3415 (see section 5.6.3). 3417 8.36 Restriction-Filter-Rule AVP 3419 The Restriction-Filter-Rule AVP (AVP Code XXX - IANA please fill in 3420 and remove this note - suggested value 438) is of type IPFilterRule 3421 and provides filter rules corresponding to services which are to 3422 remain accessible despite there being no more service units granted. 3423 The access device need to configure the specified filter rules for 3424 the subscriber and MUST drop all the packets not matching these 3425 filters. Zero, one or more such AVPs MAY be present in a Credit- 3426 Control-Answer message or in an AA answer message. 3428 8.37 Redirect-Server AVP 3430 The Redirect-Server AVP (AVP Code XXX - IANA please fill in and 3431 remove this note - suggested value 434) is of type Grouped and 3432 contains the address information of the redirect server (e.g. HTTP 3433 redirect server, SIP Server) where the end user is to be connected 3434 when the account cannot cover the service cost. It MUST be present 3435 when the Final-Unit-Action AVP is set to REDIRECT. 3437 It has the following ABNF grammar: 3439 Redirect-Server ::= < AVP Header: TBD > 3440 { Redirect-Address-Type } 3441 { Redirect-Server-Address } 3443 8.38 Redirect-Address-Type AVP 3445 The Redirect-Address-Type AVP (AVP Code XXX - IANA please fill in 3446 and remove this note - suggested value 433) is of type Enumerated 3447 and defines the address type of the address given in the Redirect- 3448 Server-Address AVP. 3450 The address type can be one of the following: 3452 IPv4 Address 0 3453 The address type is in form of "dotted-decimal" IPv4 address, 3454 as defined in [IPv4]. 3456 IPv6 Address 1 3457 The address type is in form of IPv6 address, as defined in 3458 [IPv6Addr]. The address is a text representation of the address 3459 in either the preferred or alternate text form [IPv6Addr]. 3460 Conformant implementations MUST support the preferred form and 3461 SHOULD support the alternate text form for IPv6 addresses. 3463 URL 2 3464 The address type is in form of Uniform Resource Locator, as 3465 defined in [URL]. 3467 SIP URI 3 3468 The address type is in form of SIP Uniform Resource Identifier, 3469 as defined in [SIP]. 3471 8.39 Redirect-Server-Address AVP 3473 The Redirect-Server-Address AVP (AVP Code XXX - IANA please fill in 3474 and remove this note - suggested value 435) is of type UTF8String 3475 and defines the address of the redirect server (e.g. HTTP redirect 3476 server, SIP Server) where the end user is to be connected when the 3477 account cannot cover the service cost. 3479 8.40 Multiple-Services-Indicator AVP 3481 The Multiple-Services-Indicator AVP (AVP Code XXX - IANA please fill 3482 in and remove this note - suggested value 455) is of type Enumerated 3483 and indicates whether the Diameter Credit-control client is capable 3484 of handling multiple services independently within a (sub-) session. 3485 The absence of this AVP means that independent credit control of 3486 multiple services is not supported. 3488 A server not implementing the independent credit control of multiple 3489 services MUST treat the Multiple-Services-Indicator AVP as invalid 3490 AVP. 3492 The following values are defined for the Multiple-Services-Indicator 3493 AVP: 3495 MULTIPLE_SERVICES_NOT_SUPPORTED 0 3496 Client does not support independent credit control of multiple 3497 services within a (sub-)session. 3499 MULTIPLE_SERVICES_SUPPORTED 1 3500 Client supports independent credit control of multiple services 3501 within a (sub-)session. 3503 8.41 Requested-Action AVP 3505 The Requested-Action AVP (AVP Code XXX - IANA please fill in and 3506 remove this note - suggested value 436) is type of Enumerated and 3507 contains the requested action being sent by Credit-Control-Request 3508 command where the CC-Request-Type is set to EVENT_REQUEST. The 3509 following values are defined for the Requested-Action AVP: 3511 DIRECT_DEBITING 0 3512 Direct debiting indicates that the request is to decrease the end 3513 user's account according to information specified in the 3514 Requested-Service-Unit AVP and/or Service-Identifier AVP 3515 (additional rating information may be included in service 3516 specific AVPs or in the Service-Parameter-Info AVP). The Granted- 3517 Service Unit AVP in the Credit-Control-Answer command contains 3518 the debited units. 3520 REFUND_ACCOUNT 1 3521 Refund account indicates that the request is to increase the end 3522 user's account according to information specified in the 3523 Requested-Service-Unit AVP and/or Service-Identifier AVP 3524 (additional rating information may be included in service 3525 specific AVPs or in the Service-Parameter-Info AVP). The Granted- 3526 Service Unit AVP in the Credit-Control-Answer command contains 3527 the refunded units. 3529 CHECK_BALANCE 2 3530 Check balance indicates that the request is a balance check 3531 request. In this case the checking of the account balance is done 3532 without any credit reservation from the account. The Check- 3533 Balance-Result AVP in the Credit-Control-Answer command contains 3534 the result of the Balance Check. 3536 PRICE_ENQUIRY 3 3537 Price Enquiry indicates that the request is a price enquiry 3538 request. In this case neither checking of the account balance nor 3539 reservation from the account will be done, only the price of the 3540 service will be returned in the Cost-Information AVP in the 3541 Credit-Control-Answer Command. 3543 8.42 Service-Context-Id AVP 3545 The Service-Context-Id AVP is of type UTF8String (AVP Code XXX - 3546 IANA please fill in and remove this note - suggested value 458) and 3547 contains a unique identifier of the Diameter Credit Control service 3548 specific document that applies to the request (as defined in section 3549 4.1.2). This is an identifier allocated by the service provider, by 3550 the service element manufacturer or by a standardization body and 3551 MUST uniquely identify a given Diameter Credit Control service 3552 specific document. The format of the Service-Context-Id is: 3554 "service-context" "@" "domain" 3556 service-context = Token 3557 The Token is an arbitrary string of characters and digits. 3559 domain = represents the entity that allocated the Service-Context- 3560 Id. It can be ietf.org, 3gpp.org etc., if the identifier is 3561 allocated by a standardization body, or it can be the FQDN of the 3562 service provider (e.g. provider.example.com) or of the vendor (e.g. 3563 vendor.example.com) if the identifier is allocated by a private 3564 entity. 3566 This AVP SHOULD be placed as closed to the Diameter header as 3567 possible. 3569 Service specific documents that are for private use only, i.e. to 3570 one provider's own use, where no interoperability is deemed useful 3571 may define private identifiers without need of coordination. 3572 However, when interoperability is wanted, coordination of the 3573 identifiers via e.g. publication of informational RFC is RECOMMENDED 3574 to make Service-Context-Id globally available. 3576 8.43 Service-Parameter-Info AVP 3578 The Service-Parameter-Info AVP (AVP Code XXX - IANA please fill in 3579 and remove this note - suggested value 440) is of type Grouped and 3580 contains a service specific information used for price calculation 3581 or rating. The Service-Parameter-Type AVP defines the service 3582 parameter type and the Service-Parameter-Value AVP contains the 3583 parameter value. The actual contents of these AVPs are not within 3584 the scope of this document and SHOULD be defined in another Diameter 3585 application, standards written by other standardization bodies, or 3586 service specific documentation. 3588 In case of unknown service request (e.g. unknown Service-Parameter- 3589 Type), the corresponding answer message MUST contain error code 3590 DIAMETER_RATING_FAILED. A Credit Control Answer message with this 3591 error MUST contain one or more Failed-AVP AVPs containing the 3592 Service-Parameter-Info AVPs that caused the failure. 3594 It has the following ABNF grammar: 3596 Service-Parameter-Info ::= < AVP Header: TBD > 3597 { Service-Parameter-Type } 3598 { Service-Parameter-Value } 3600 8.44 Service-Parameter-Type AVP 3602 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code XXX - 3603 IANA please fill in and remove this note - suggested value 441) and 3604 defines the type of the service event specific parameter (e.g. it 3605 can be end-user location, service name). The different parameters 3606 and their types are service specific and the meanings of these 3607 parameters are not defined in this document. The one who allocates 3608 the Service-Context-Id, i.e. unique identifier of a service specific 3609 document, is also responsible for assigning Service-Parameter-Type 3610 values for the service and ensuring their uniqueness within the 3611 given service. The Service-Parameter-Value AVP contains the value 3612 associated with the service parameter type. 3614 8.45 Service-Parameter-Value AVP 3616 The Service-Parameter-Value AVP is of type OctetString (AVP Code XXX 3617 - IANA please fill in and remove this note - suggested value 442) 3618 and contains the value of the service parameter type. 3620 8.46 Subscription-Id AVP 3622 The Subscription-Id AVP (AVP Code XXX - IANA please fill in and 3623 remove this note - suggested value 443) is used to identify the end 3624 user's subscription and is of type Grouped. The Subscription-Id AVP 3625 includes a Subscription-Id-Data AVP that hold the identifier and a 3626 Subscription-Id-Type AVP that defines the identifier type. 3628 It has the following ABNF grammar: 3630 Subscription-Id ::= < AVP Header: TBD > 3631 { Subscription-Id-Type } 3632 { Subscription-Id-Data } 3634 8.47 Subscription-Id-Type AVP 3636 The Subscription-Id-Type AVP (AVP Code XXX - IANA please fill in and 3637 remove this note - suggested value 450) is of type Enumerated and it 3638 is used to determine which type of identifier that is carried by the 3639 Subscription-Id AVP. 3641 This specification defines the following subscription identifiers. 3642 However, new Subscription-Id-Type values can be assigned via IANA 3643 designated expert as defined in section 12. A server MUST implement 3644 all of the Subscription-Id-Types required to perform credit 3645 authorization for the services it supports, including possible 3646 future values. Unknown or unsupported Subscription-Id-Types MUST be 3647 treated according to the 'M' flag rule as defined in [DIAMBASE]. 3649 END_USER_E164 0 3650 The identifier is in international E.164 format (e.g. MSISDN), 3651 according to the ITU-T E.164 numbering plan as defined in [E164] 3652 and [CE164]. 3654 END_USER_IMSI 1 3655 The identifier is in international IMSI format, according to the 3656 ITU-T E.212 numbering plan as defined in [E121] and [CE121]. 3658 END_USER_SIP_URI 2 3659 The identifier is in the form of a SIP URI as defined in [SIP]. 3661 END_USER_NAI 3 3662 The identifier is in the form of a Network Access Identifier as 3663 defined in [NAI]. 3665 END_USER_PRIVATE 4 3666 The Identifier is a credit-control server private identifier. 3668 8.48 Subscription-Id-Data AVP 3670 The Subscription-Id-Data AVP (AVP Code XXX - IANA please fill in and 3671 remove this note - suggested value 444) is used to identify the end- 3672 user and is of type UTF8String. The Subscription-Id-Type AVP defines 3673 which type of identifier is used. 3675 8.49 User-Equipment-Info AVP 3677 The User-Equipment-Info AVP (AVP Code XXX - IANA please fill in and 3678 remove this note - suggested value 458) is of type Grouped, and 3679 allows the Credit-control client to indicate the identity and 3680 capability of the terminal the subscriber is using for the 3681 connection to network. 3683 It has the following ABNF grammar: 3685 User-Equipment-Info ::= < AVP Header: TBD > 3686 { User-Equipment-Info-Type } 3687 { User-Equipment-Info-Value } 3689 8.50 User-Equipment-Info-Type AVP 3691 The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 3692 XXX - IANA please fill in and remove this note - suggested value 3693 459) and defines the type of the user equipment information 3694 contained in the User-Equipment-Info-Value AVP. 3696 This specification defines the following user equipment types. 3697 However, new User-Equipment-Info-Type values can be assigned via 3698 IANA designated expert as defined in section 12. 3700 IMEISV 0 3701 The identifier contains the International Mobile Equipment 3702 Identifier and Software Version in the international IMEISV 3703 format according to 3GPP TS 23.003 [3GPPIMEI]. 3705 MAC 1 3706 The 48-bit MAC address is formatted as described in [RAD802.1X]. 3708 EUI64 2 3709 The 64-bit identifier used to identify hardware instance of the 3710 product as defined in [EUI64]. 3712 MODIFIED_EUI64 3 3713 There are a number of types of terminals that have identifiers 3714 other than IMEI, IEEE 802 MACs or EUI-64. These identifiers can 3715 be converted to modified EUI-64 format as described in [IPv6Addr] 3716 or using some other methods referred to in the service specific 3717 documentation. 3719 8.50 User-Equipment-Info-Value AVP 3721 The User-Equipment-Info-Value AVP (AVP Code XXX - IANA please fill 3722 in and remove this note - suggested value 460) is of type 3723 OctetString The User-Equipment-Info-Type AVP defines which type of 3724 identifier is used. 3726 9. Result Code AVP values 3728 This section defines new Result-Code AVP [DIAMBASE] values that must 3729 be supported by all Diameter implementations that conform to this 3730 specification. 3732 The Credit-Control-Answer message includes the Result-Code AVP, 3733 which may indicate that an error was present in the Credit-Control- 3734 Request message. A rejected Credit-Control-Request message SHOULD 3735 cause the user's session to be terminated. 3737 9.1 Transient Failures 3739 Errors that fall within the transient failures category are used to 3740 inform a peer that the request could not be satisfied at the time it 3741 was received, but MAY be able to satisfy the request in the future. 3743 DIAMETER_END_USER_SERVICE_DENIED 4010 3744 The credit-control server denies the service request due to 3745 service restrictions. If the CCR contained used-service-units 3746 they are deducted, if possible. 3748 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 3749 The credit-control server determines that the service can be 3750 granted to the end user but no further credit-control is needed 3751 for the service (e.g. service is free of charge). 3753 DIAMETER_CREDIT_LIMIT_REACHED 4012 3754 The credit-control server denies the service request since the 3755 end- user's account could not cover the requested service. If the 3756 CCR contained used-service-units they are deducted, if possible. 3758 9.2 Permanent Failures 3760 Errors that fall within permanent failure category are used to 3761 inform the peer that the request failed, and should not be attempted 3762 again. 3764 DIAMETER_USER_UNKNOWN 5030 3765 The specified end user is unknown in the credit-control server. 3767 DIAMETER_RATING_FAILED 5031 3768 This error code is used to inform the credit-control client that 3769 the credit-control server cannot rate the service request due to 3770 insufficient rating input, incorrect AVP combination or due to an 3771 AVP or an AVP value that is not recognized or supported in the 3772 rating. The Failed-AVP AVP MUST be included and contain a copy of 3773 the entire AVP(s) that could not be processed successfully or an 3774 example of the missing AVP complete with the Vendor-Id if 3775 applicable. The value field of the missing AVP should be of 3776 correct minimum length and contain zeroes. 3778 10. AVP Occurrence Table 3780 The following table presents the AVPs defined in this document, and 3781 specifies in which Diameter messages they MAY, or MAY NOT be 3782 present. Note that AVPs that can only be present within a Grouped 3783 AVP are not represented in this table. 3785 The table uses the following symbols: 3786 0 The AVP MUST NOT be present in the message. 3787 0+ Zero or more instances of the AVP MAY be present in the 3788 message. 3789 0-1 Zero or one instance of the AVP MAY be present in the 3790 message. It is considered an error if there are more 3791 than one instance of the AVP. 3792 1 One instance of the AVP MUST be present in the message. 3793 1+ At least one instance of the AVP MUST be present in the 3794 message. 3796 10.1 Credit Control AVP Table 3797 The table in this section is used to represent which Credit-control 3798 applications specific AVPs defined in this document are to be 3799 present in the Credit Control messages. 3800 +-----------+ 3801 | Command | 3802 | Code | 3803 |-----+-----+ 3804 Attribute Name | CCR | CCA | 3805 ------------------------------|-----+-----+ 3806 Acct-Multi-Session-Id | 0-1 | 0-1 | 3807 Auth-Application-Id | 1 | 1 | 3808 CC-Correlation-Id | 0-1 | 0 | 3809 CC-Session-Failover | 0 | 0-1 | 3810 CC-Request-Number | 1 | 1 | 3811 CC-Request-Type | 1 | 1 | 3812 CC-Sub-Session-Id | 0-1 | 0-1 | 3813 Check-Balance-Result | 0 | 0-1 | 3814 Cost-Information | 0 | 0-1 | 3815 Credit-Control-Failure- | 0 | 0-1 | 3816 Handling | | | 3817 Destination-Host | 0-1 | 0 | 3818 Destination-Realm | 1 | 0 | 3819 Direct-Debiting-Failure- | 0 | 0-1 | 3820 Handling | | | 3821 Event-Timestamp | 0-1 | 0-1 | 3822 Failed-AVP | 0 | 0+ | 3823 Final-Unit-Indication | 0 | 0-1 | 3824 Granted-Service-Unit | 0 | 0-1 | 3825 Multiple-Services-Credit- | 0+ | 0+ | 3826 Control | | | 3827 Multiple-Services-Indicator | 0-1 | 0 | 3828 Origin-Host | 1 | 1 | 3829 Origin-Realm | 1 | 1 | 3830 Origin-State-Id | 0-1 | 0-1 | 3831 Proxy-Info | 0+ | 0+ | 3832 Redirect-Host | 0 | 0+ | 3833 Redirect-Host-Usage | 0 | 0-1 | 3834 Redirect-Max-Cache-Time | 0 | 0-1 | 3835 Requested-Action | 0-1 | 0 | 3836 Requested-Service-Unit | 0-1 | 0 | 3837 Route-Record | 0+ | 0+ | 3838 Result-Code | 0 | 1 | 3839 Service-Context-Id | 1 | 0 | 3840 Service-Identifier | 0-1 | 0 | 3841 Service-Parameter-Info | 0+ | 0 | 3842 Session-Id | 1 | 1 | 3843 Subscription-Id | 0+ | 0 | 3844 Termination-Cause | 0-1 | 0 | 3845 User-Equipment-Info | 0-1 | 0 | 3846 Used-Service-Unit | 0+ | 0 | 3847 User-Name | 0-1 | 0-1 | 3848 Validity-Time | 0 | 0-1 | 3849 ------------------------------|-----+-----+ 3851 10.2 Re-Auth-Request/Answer AVP Table 3853 This section defines AVPs that are specific to Diameter Credit 3854 Control Application and MAY be included in the Diameter Re-Auth- 3855 Request/Answer (RAR/RAA) message [DIAMBASE]. 3857 Re-Auth-Request/Answer command MAY include the following additional 3858 AVPs: 3860 +---------------+ 3861 | Command Code | 3862 |-------+-------+ 3863 Attribute Name | RAR | RAA | 3864 ------------------------------+-------+-------+ 3865 CC-Sub-Session-Id | 0-1 | 0-1 | 3866 G-S-U-Pool-Identifier | 0-1 | 0-1 | 3867 Service-Identifier | 0-1 | 0-1 | 3868 Rating-Group | 0-1 | 0-1 | 3869 ------------------------------+-------+-------+ 3871 11. RADIUS/Diameter Credit-control Interworking Model 3873 This section defines the basic principles for the Diameter Credit- 3874 control/RADIUS prepaid inter-working model, that is a message 3875 translation between RADIUS based prepaid solution and Diameter 3876 Credit-control application. A complete description of the protocol 3877 translations between RADIUS and Diameter Credit-control application 3878 is 3879 beyond the scope of this specification and SHOULD be addressed in 3880 another appropriate document such as the RADIUS prepaid 3881 specification. 3883 The Diameter credit-control architecture may have a Translation 3884 Agent, which is capable of translation between RADIUS prepaid and 3885 Diameter Credit-control protocol. An AAA server, usually the home 3886 AAA server, may act as a Translation Agent while acting also as 3887 Diameter credit-control client for service elements that use credit 3888 control mechanisms other than Diameter credit-control, for instance 3889 RADIUS prepaid. In this case the home AAA server contacts the 3890 Diameter credit-control server as part of the authorization process. 3891 The interworking architecture is illustrated in figure 7 and 3892 interworking flow in figure 8. In roaming situation the service 3893 element (e.g. the NAS) may be located in the visited network and a 3894 visited AAA server is usually contacted. The visited AAA server 3895 connects then to the home AAA server. 3897 Radius prepaid 3898 +--------+ +---------+ protocol +------------+ +--------+ 3899 | End |<----->| Service |<---------->| Home AAA | |Business| 3900 | User | | Element | | Server | |Support | 3901 +--------+ +-->| | |+----------+|->|System | 3902 | +---------+ ||CC client || | | 3903 | |+----------+| | | 3904 +--------+ | +------^-----+ +----^---+ 3905 | End |<--+ credit-control | | 3906 | User | protocol | | 3907 +--------+ +-------V--------+ | 3908 |Credit-control |----+ 3909 | Server | 3910 +----------------+ 3912 Figure 7: Credit-control architecture with Service Element 3913 containing translation agent, translating RADIUS 3914 prepaid to Diameter credit control protocol 3916 When the AAA server acting as a Translation Agent receives an 3917 initial RADIUS Access-Request message from service Element (e.g. NAS 3918 access), it performs regular Authentication and Authorization. If 3919 the RADIUS Access-Request message indicates that the service element 3920 is capable of credit-control, and if the home AAA server finds that 3921 the subscriber is a prepaid subscriber then a Diameter Credit 3922 control request SHOULD be sent towards the credit-control server to 3923 perform credit authorization and to establish a credit control 3924 session. After the Diameter credit-control server checks the end 3925 user's account balance, rates the service and reserves credit from 3926 the end user's account, the reserved quota is returned to the home 3927 AAA server in the Diameter Credit-Control-Answer. Then the home AAA 3928 server sends the reserved quota to the service element in the RADIUS 3929 Access-Accept. 3931 At the expiry of the allocated quota, the service element sends a 3932 new RADIUS Access-Request to the home AAA server containing the 3933 units used this far. The home AAA server shall map RADIUS Access- 3934 Request containing the reported units to the Diameter credit-control 3935 server in a Diameter Credit-Control-Request (UPDATE_REQUEST). The 3936 Diameter credit-control server debits the used units from the end 3937 user's account and allocates a new quota that is returned to the 3938 home AAA server in the Diameter Credit-Control-Answer. The quota is 3939 transferred to the service element in the RADIUS Access-Accept. When 3940 the end user terminates the service or when the entire quota has 3941 been used, the service element sends a RADIUS Access-Request. To 3942 debit the used units from the end user's account and to stop the 3943 credit control session, the home AAA server sends a Diameter Credit- 3944 Control-Request (TERMINATION_REQUEST) to the credit-control server. 3945 The Diameter credit-control server acknowledges the session 3946 termination by sending a Diameter Credit-Control-Answer to the home 3947 AAA server. The RADIUS Access-Accept is sent to the NAS. 3949 A following diagram illustrates a RADIUS prepaid - Diameter credit 3950 control interworking sequence. 3952 Service Element Translation agent 3953 (e.g.NAS) (CC Client) CC Server 3954 | Access-Request | | 3955 |----------------------->| | 3956 | | CCR (initial) | 3957 | |----------------------->| 3958 | | CCA (granted_Units) | 3959 | |<-----------------------| 3960 | Access-Accept | | 3961 | (granted Units) | | 3962 |<-----------------------| | 3963 : : : 3964 | Access-Request | | 3965 | (used Units) | | 3966 |----------------------->| | 3967 | | CCR (update, | 3968 | | used Units, | 3969 | |----------------------->| 3970 | | CCA (granted_Units) | 3971 | |<-----------------------| 3972 | Access-Accept | | 3973 | (granted Units) | | 3974 |<-----------------------| | 3975 : : : 3976 | Access-Request | | 3977 |----------------------->| | 3978 | | CCR (termin., | 3979 | | used Units) | 3980 | |----------------------->| 3981 | | CCA | 3982 | |<-----------------------| 3983 | Access-Accept | | 3984 |<-----------------------| | 3985 | | | 3987 Figure 8: Message flow example with RADIUS prepaid - 3988 Diameter credit control interworking 3990 12. IANA Considerations 3992 This section contains the namespaces that have either been created 3993 in this specification, or the values assigned to existing namespaces 3994 managed by IANA. 3996 12.1 Application Identifier 3998 This specification assigns the value XXX [IANA please fill in XXX 3999 (suggested value 4) and remove this note], 'Diameter Credit 4000 Control', to the Application Identifier namespace defined in 4001 [DIAMBASE]. See section 1.3 for more information. 4003 12.2 Command Codes 4005 This specification uses the value [IANA please fill in XXX 4006 (suggested value 272) and remove this note] from the Command code 4007 namespace defined in [DIAMBASE] for the Credit-Control-Request (CCR) 4008 and Credit-Control-Answer (CCA) commands. 4010 12.3 AVP Codes 4012 This specification assigns the values XXX - YYY [IANA please fill in 4013 XXX, YYY (suggested values 411, 458) and remove this note] from the 4014 AVP code namespace defined in [DIAMBASE] See section 8 for the 4015 assignment of the namespace in this specification. 4017 12.4 Result-Code AVP Values 4019 This specification assigns the values X1, X2, X3, X4, X5 [IANA 4020 please fill in XXX (suggested value 4010, 4011, 4012, 5030 and 5031) 4021 and remove this note] from the Result-Code AVP value namespace 4022 defined in [DIAMBASE]. See section 9 for the assignment of the 4023 namespace in this specification. 4025 12.5 CC-Request-Type AVP 4027 As defined in section 8.3, the CC-Request-Type AVP includes 4028 Enumerated type values X1 - X3. IANA is to create and maintain a 4029 namespace for this AVP.[IANA please fill in X1-X3 (suggested value 4030 1, 3) and remove this note]. All remaining values are available for 4031 assignment via Designated Expert [IANA]. 4033 12.6 CC-Session-Failover AVP 4034 As defined in section 8.4, the CC-Failover-Supported AVP includes 4035 Enumerated type values X0 - X1. IANA is to create and maintain a 4036 namespace for this AVP.[IANA please fill in X0, X1 (suggested value 4037 0, 1) and remove this note]. All remaining values are available for 4038 assignment via Designated Expert [IANA]. 4040 12.7 CC-Unit-Type AVP 4042 As defined in section 8.32, the CC-Unit-Type AVP includes Enumerated 4043 type values X0 - X5. IANA is to create and maintain a namespace for 4044 this AVP. [IANA please fill in X0-X5 (suggested value 0, 5) and 4045 remove this note]. All remaining values are available for assignment 4046 via Designated Expert [IANA]. 4048 12.8 Check-Balance-Result AVP 4050 As defined in Section 8.6, the Check-Balance-Result AVP includes 4051 Enumerated type values X0 - X1. IANA is to create and maintain a 4052 namespace for this AVP.[IANA please fill in X0-X1 (suggested value 4053 0, 1) and remove this note]. All remaining values are available for 4054 assignment via Designated Expert [IANA]. 4056 12.9 Credit-Control AVP 4058 As defined in section 8.13, the Credit-Control AVP includes 4059 Enumerated type values X0 - X1. IANA is to create and maintain a 4060 namespace for this AVP. [IANA please fill in X0-X1 (suggested value 4061 0, 1) and remove this note]. All remaining values are available for 4062 assignment via Designated Expert [IANA]. 4064 12.10 Credit-Control-Failure-Handling AVP 4066 As defined in Section 8.14, the Credit-Control-Failure-Handling AVP 4067 includes Enumerated type values X0 - X2. IANA is to create and 4068 maintain a namespace for this AVP. [IANA please fill in X0-X2 4069 (suggested value 0, 2) and remove this note]. All remaining values 4070 are available for assignment via Designated Expert [IANA]. 4072 12.11 Direct-Debiting-Failure-Handling AVP 4074 As defined in Section 8.15, the Direct-Debiting-Failure-Handling AVP 4075 includes Enumerated type values X0 - X1. IANA is to create and 4076 maintain a namespace for this AVP.[IANA please fill in X0-X1 4077 (suggested value 0, 1) and remove this note]. All remaining values 4078 are available for assignment via Designated Expert [IANA]. 4080 12.12 Final-Unit-Action AVP 4081 As defined in Section 8.35, the Final-Unit-Action AVP includes 4082 Enumerated type values X0 - X2. IANA is to create and maintain a 4083 namespace for this AVP. [IANA please fill in X0-X2 (suggested value 4084 0, 2) and remove this note]. All remaining values are available for 4085 assignment via Designated Expert [IANA]. 4087 12.13 Multiple-Services-Indicator AVP 4089 As defined in Section 8.40, the Multiple-Services-Indicator AVP 4090 includes Enumerated type values X0 - X1. IANA is to create and 4091 maintain a namespace for this AVP. [IANA please fill in X0-X1 4092 (suggested value 0, 1) and remove this note]. All remaining values 4093 are available for assignment via Designated Expert [IANA]. 4095 12.14 Redirect-Address-Type AVP 4097 As defined in Section 8.38, the Redirect-Address-Type AVP includes 4098 Enumerated type values X0 - X3. IANA is to create and maintain a 4099 namespace for this AVP. [IANA please fill in X0-X3 (suggested value 4100 0, 3) and remove this note]. All remaining values are available for 4101 assignment via Designated Expert [IANA]. 4103 12.15 Requested-Action AVP 4105 As defined in Section 8.41, the Requested-Action AVP includes 4106 Enumerated type values X0 - X3. IANA is to create and maintain a 4107 namespace for this AVP. [IANA please fill in X0-X3 (suggested value 4108 0, 3) and remove this note]. All remaining values are available for 4109 assignment via Designated Expert [IANA]. 4111 12.16 Subscription-Id-Type AVP 4113 As defined in Section 8.47, the Subscription-Id-Type AVP includes 4114 Enumerated type values X0 - X4. IANA is to create and maintain a 4115 namespace for this AVP. [IANA please fill in X0-X4 (suggested value 4116 0, 4) and remove this note]. All remaining values are available for 4117 assignment via Designated Expert [IANA]. 4119 12.17 Tariff-Change-Usage AVP 4121 As defined in Section 8.27, the Tariff-Change-Usage AVP includes 4122 Enumerated type values X0 - X2. IANA is to create and maintain a 4123 namespace for this AVP. [IANA please fill in X0-X2 (suggested value 4124 0, 2) and remove this note]. All remaining values are available for 4125 assignment via Designated Expert [IANA]. 4127 12.18 User-Equipment-Info-Type AVP 4128 As defined in Section 8.50, the User-Equipment-Info-Type AVP 4129 includes Enumerated type values X0 - X3. IANA is to create and 4130 maintain a namespace for this AVP. [IANA please fill in X0-X3 4131 (suggested value 0, 3) and remove this note]. All remaining values 4132 are available for assignment via Designated Expert [IANA]. 4134 13. Credit-control Application Related Parameters 4136 Tx timer 4138 When real-time credit-control is required, the credit-control 4139 client contacts the credit-control server before and during the 4140 service is provided to an end user. Due to real-time nature of 4141 the application the communication delays SHOULD be minimized, 4142 e.g. to avoid too long service set up time experienced by the end 4143 user. The Tx timer is introduced to control the waiting time in 4144 the client in the PENDING state. When the Tx timer elapses the 4145 credit-control client takes an action to the end user according 4146 to the value of the Credit-Control-Failure-Handling AVP or 4147 according to the value of the Direct-Debiting-Failure-Handling 4148 AVP. 4150 The recommended value is 10 seconds. 4152 Tcc timer 4154 The Tcc timer supervises an ongoing credit control session in the 4155 credit control server. It is RECOMMENDED to use the Validity-Time 4156 as input to set the Tcc timer value. To avoid the credit control 4157 session in the Diameter credit control server to change to Idle 4158 state in case of short transient network failure, Tcc MAY be set 4159 to two times the value of Validity-Time. 4161 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 4163 Client implementations may offer the possibility to locally 4164 configure these AVPs. In such a case their value and behavior is 4165 defined in section 5.7 for the Credit-Control-Failure-Handling 4166 and in section 6.5 for the Direct-Debiting-Failure-Handling. 4168 14. Security Consideration 4170 The Diameter base protocol [DIAMBASE] requires that each Diameter 4171 implementation uses underlying security, i.e. IPsec or TLS. These 4172 mechanisms are believed to provide sufficient protection under the 4173 normal Internet threat model - that is, assuming the authorized 4174 nodes engaging in the protocol have not been compromised, but the 4175 attacker has complete control over the communication channels 4176 between them. This includes eavesdropping, message modification, 4177 insertion, man-in-the-middle and replay attacks. Note also that this 4178 application includes a mechanism for application layer replay 4179 protection by the means of Session-ID from [DIAMBASE], and CC- 4180 Request-Number specified in this document. The Diameter credit 4181 control application is often used within one domain and there may be 4182 just single hop between the peers. In these environments the use of 4183 TLS or IPsec is sufficient. The details of TLS and IPsec related 4184 security considerations are discussed in the [DIAMBASE]. 4186 Because this application handles monetary transactions (directly or 4187 indirectly) this kind of application increases the interest for 4188 various security attacks. Therefore all parties communicating with 4189 each other MUST be authenticated, including, for instance, TLS 4190 client-side authentication. In addition to this, authorization of 4191 the client SHOULD be emphasized, i.e. that the client is allowed to 4192 perform credit control for a certain user. The specific means of 4193 authorization are outside of the scope of this specification but can 4194 be for instance, manual configuration. 4196 Another kind of threat is malicious modification, injection or 4197 deletion of AVPs or complete credit control messages. The credit 4198 control messages contain sensitive billing related information (such 4199 as subscription Id, granted units, used units, cost information) 4200 whose malicious modification can have financial consequences. 4201 Sometimes simply delaying the credit control messages can cause 4202 disturbances in the credit control client or server. 4204 Even without any modification to the messages an adversary can 4205 invite a security threat by eavesdropping, because the transactions 4206 contain private information about the user. Also by monitoring the 4207 credit control messages one can collect information about credit 4208 control server's billing models and business relationships. 4210 When third party relays or proxy are involved, the hop-by-hop 4211 security does not necessarily provide sufficient protection for 4212 Diameter user session. Diameter messages, such as CCR and CCA, 4213 containing sensitive AVPs may be inappropriate in some cases to be 4214 sent via untrusted Diameter proxy agents since there are no 4215 assurance that third party proxies will not modify the credit 4216 control commands or AVP values. 4218 14.1 Direct Connection with Redirects 4220 A Diameter Credit control agent cannot always know whether agents 4221 between it and the end user's Diameter credit control server are 4222 reliable. In this case the Diameter Credit control agent doesn't 4223 have a routing entry in its Diameter Routing Table (defined in 4224 [DIAMBASE] in section 2.7) for the realm of the Credit Control 4225 Server in the end user's home domain. The Diameter Credit control 4226 agent can have a default route configured to a local Redirect agent 4227 and it re-directs the CCR message to the redirect agent. The local 4228 Redirect agent then returns a redirect notification (Result-code 4229 3006, DIAMETER_REDIRECT_INDICATION) to the Credit control agent, as 4230 well Diameter Credit control Server(s) information (Redirect-Host 4231 AVP) and information (Redirect-Host-Usage AVP) how to the routing 4232 entry resulting from the Redirect-Host is to be used. The Diameter 4233 credit control agent then forwards the CCR message directly to one 4234 of the hosts identified by the CCA message from the redirect agent. 4235 If the value of the Redirect-Host-Usage AVP is unequal than zero all 4236 following messages are sent to the host specified in the Redirect- 4237 Host AVP until the time specified by the Redirect-Max-Cache-Time AVP 4238 is expired. 4240 There are some authorization issues even with redirects. There may 4241 be attacks towards nodes that have been properly authorized, but 4242 abuse their authorization or have been compromised. These issues are 4243 discussed more widely in [DIAMEAP] section 8. 4245 15. References 4247 15.1 Normative 4249 [DIAMBASE] P. Calhoun, J. Loughney, J. Arkko, E. Guttman, G. Zorn. 4250 "Diameter Base Protocol", RFC 3588, September 2003. 4252 [3GPPCHARG] 3rd Generation Partnership Project; Technical 4253 Specification Group Services and System Aspects, Service 4254 aspects; Charging and Billing, (release 5), 3GPP TS 4255 22.115 v. 5.2.1, 2002-03 4257 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, 4258 G. Camarillo, A. Johnston, J. Peterson, R. Sparks 4259 "SIP: Session Initiation Protocol", RFC 3261. June 2002. 4260 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 4261 2486. 4262 January 1999. 4264 [E164] Recommendation E.164/I.331 (05/97): The International 4265 Public Telecommunication Numbering Plan. 1997. 4267 [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List 4268 of ITU-T Recommendation E.164 assigned country codes", 4269 June 2000. 4271 [E212] Recommendation E.212 (11/98): The international 4272 identification plan for mobile terminals and mobile 4273 users. 1998. 4275 [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" 4276 List 4277 of mobile country or geographical area codes ", February 4278 1999. 4280 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 4281 Considerations Section in RFCs", BCP 26, RFC 2434, 4282 October 4283 1998 4285 [IPv4] J. Postel. "Internet Protocol", STD 5, RFC 791, 4286 September 1981. 4288 [IPv6Addr] R. Hinden, S. Deering. "Internet Protocol Version 6 4289 (IPv6) 4290 Addressing Architecture", RFC 3513, April 2003. 4292 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 4293 Requirement Levels", BCP 14, RFC 2119, March 1997. 4295 [ISO4217] Codes for the representation of currencies and funds, 4296 International Standard ISO 4217,2001 4298 [NASREQ] P. Calhoun, G. Zorn, D. Spence, D. Mitton. "Diameter 4299 NASREQ Application", IETF work in progress. 4301 [AAATRANS] B. Aboba, J. Wood. "Authentication, Authorization and 4302 Accounting (AAA) Transport Profile", RFC 3539, June 2003 4304 [URL] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform 4305 Resource Locators (URL)�, RFC 1738, December 1994 4307 [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", 4308 RFC 3580, September 2003. 4310 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 4311 Registration Authority", 4312 http://standards.ieee.org/regauth/oui/tutorials/EUI64.ht 4313 ml March 1997. 4315 [3GPPIMEI] 3rd Generation Partnership Project; Technical 4316 Specification Group Core Network, Numbering, addressing 4317 and identification, (release 5), 3GPP TS 23.003 4318 v. 5.8.0, 2003-12 4320 15.2 Non-Normative 4322 [RFC2866] C. Rigney. "Radius Accounting", RFC 2866, June 2000 4324 [DIAMMIP] P. Calhoun, T. Johansson, C. Perkins "Diameter Mobile IP 4325 Application", IETF work in progress. 4327 [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson. "Remote 4328 Authentication Dial In User Service (RADIUS), RFC 2865, 4329 June 2000 4331 [DIAMEAP] P. Eronen, T. Hiller, G. Zorn. "Diameter Extensible 4332 Authentication Protocol (EAP) Application", IETF work in 4333 progress. 4335 [RFC3725] J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo, 4336 "Best Current Practices for Third Party Call Control 4337 (3pcc) in the Session Initiation Protocol (SIP)", RFC 4338 3725, April 2004 4340 16. Acknowledgement 4342 The authors would like to thank Bernard Aboba, Jari Arkko, Robert 4343 Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, 4344 Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, 4345 Christopher Richards, Juha Vallinen and Mark Watson for their 4346 comments and suggestions. 4348 Appendix A Credit Control sequences 4350 A.1 Flow I 4352 End-User NAS AAA Server CC Server 4353 (CC Client) 4354 |(1)User Logon |(2)AA Request (CC AVPs) | 4355 |------------------>|------------------->| | 4356 | | |(3)CCR(initial, CC 4357 AVPs) 4358 | | |------------------->| 4359 | | | (4)CCA(granted Units) 4360 | | |<-------------------| 4361 | |(5)AA Answer(granted Units) | 4362 |(6)Access granted |<-------------------| | 4363 |<----------------->| | | 4364 | | | | 4365 : : : : 4366 | |(7)CCR(update,used Units) | 4367 | |------------------->|(8)CCR | 4368 | | | (update,used units) 4369 | | |------------------->| 4370 | | |(9)CCA(granted Units) 4371 | |(10)CCA(granted Units)<------------------| 4372 | |<-------------------| | 4373 : : : : 4374 | (Auth. lifetime expires) | | 4375 | |(11) AAR (CC AVP) | | 4376 | |------------------->| | 4377 | | (12) AAA | | 4378 | |<-------------------| | 4379 : : : : 4380 : : : : 4381 |(13) User logoff | | | 4382 |------------------>|(14)CCR(term.,used-Units) | 4383 | |------------------->|(15)CCR | 4384 | | | (term.,used-Units) 4385 | | |------------------->| 4386 | | | (16)CCA | 4387 | | (17)CCA |<-------------------| 4388 | |<-------------------| | 4389 | |(18)STR | | 4390 | |------------------->| | 4391 | | (19)STA | | 4392 | |<-------------------| | 4394 Figure A.1: Flow I 4396 A credit control flow for Network Access Services prepaid is shown 4397 in Figure A.1. The Diameter [NASREQ] is implemented in the Network 4398 Access Server (NAS). The focus of this flow is in the credit 4399 authorization. 4401 The user logs onto the network (1). The Diameter NAS first sends a 4402 Diameter Authorization-Authentication-Request to the home Diameter 4403 AAA Server, the credit-control client populates the AAR with the 4404 Credit-Control AVP set to CREDIT_AUTHORIZATION and service specific 4405 AVPs are included as usual [NASREQ]. The home Diameter AAA server 4406 performs service specific Authentication and Authorization as 4407 usual. The home Diameter AAA server determines that the user is a 4408 prepaid user and notices from the Credit-Control AVP that the NAS 4409 has credit control capabilities, it sends a Diameter Credit- 4410 Control-Request with CC-Request-Type set to INITIAL_REQUEST to the 4411 Diameter credit-control server to perform credit authorization (3) 4412 and to establish a credit control session (the home Diameter AAA 4413 server may forward service specific AVPs as received from the NAS 4414 as input for the rating process). The Diameter credit-control 4415 server checks the end user's account balance, rates the service and 4416 reserves credit from the end user's account. The reserved quota is 4417 returned to the home Diameter AAA server in the Diameter Credit- 4418 Control-Answer (4). The home Diameter AAA server sends the reserved 4419 quota to the NAS in the Diameter Authorization-Authentication- 4420 Answer. Upon successful AAA the NAS starts the credit-control 4421 session and starts monitoring the granted units (5). The NAS grant 4422 access to the end user (6). At the expiry of the allocated quota, 4423 the NAS sends a Diameter Credit-Control-Request with CC-Request- 4424 Type set to UPDATE_REQUEST to the Home Diameter AAA server (7). 4425 This message contains the units used this far. The home Diameter 4426 AAA server forwards the CCR to the Diameter credit-control server 4427 (8). The Diameter credit-control server debits the used units from 4428 the end user's account and allocates a new quota that is returned 4429 to the home Diameter AAA server in the Diameter Credit-Control- 4430 Answer (9). The message is forwarded to the NAS (10). During the 4431 ongoing credit-control session the authorization-lifetime expires, 4432 the authorization/authentication client in the NAS performs service 4433 specific re-authorization to the home Diameter AAA server as usual. 4434 The credit-control client populate the AAR with the Credit-Control 4435 AVP set to RE_AUTHORIZATION indicating that the credit-control 4436 server shall not be contacted, since the credit authorization is 4437 controlled by the burning rate of the granted units (11). The home 4438 Diameter AAA server performs service specific re-authorization as 4439 usual and returns the Authorization-Authentication-Answer to the 4440 NAS (12). The end user logs off from the network (13). To debit the 4441 used units from the end user's account and to stop the credit 4442 control session, the NAS sends a Diameter Credit-Control-Request 4443 with CC-Request-Type set to TERMINATION_REQUEST to the home 4444 Diameter AAA server (14). The home Diameter AAA server forwards the 4445 CCR to the credit-control server (15). The Diameter credit-control 4446 server acknowledges the session termination by sending a Diameter 4447 Credit-Control-Answer to the home Diameter AAA server (16). The 4448 home Diameter AAA server forwards the answer to the NAS (17). 4449 STR/STA take place between NAS and home Diameter AAA server as 4450 usual (18-19). 4452 A.2 Flow II 4454 SIP Proxy/Registrar AAA 4455 A (CC Client) Server B CC Server 4456 |(i) REGISTER | | | | 4457 |------------->|(ii) | | | 4458 | |------------->| | | 4459 | |authentication & | | 4460 | |authorization | | | 4461 | |<-------------| | | 4462 |(iii)200 OK | | | 4463 |<-------------| | | 4464 : : : : 4465 |(1) INVITE | : 4466 |------------->| 4467 | |(2) CCR (Intial, SIP specific AVP) | 4468 | |------------------------------------------->| 4469 | |(3) CCA (granted_Units) | 4470 | |<-------------------------------------------| 4471 | |(4) INVITE | | 4472 | |---------------------------->| | 4473 : : : : 4474 | |(5) CCR (update, used Units) | 4475 | |------------------------------------------->| 4476 | |(6) CCA (granted_Units) | 4477 | |<-------------------------------------------| 4478 : : : : 4479 |(7) BYE | | | 4480 |------------->| | | 4481 | |(8) BYE | | 4482 | |---------------------------->| | 4483 | |(9) CCR (termination, used Units)----------| 4484 | |------------------------------------------->| 4485 | |(10) CCA () | 4486 | |<-------------------------------------------| 4487 | | | | 4489 Figure A.2: Flow II 4491 This is an example of Diameter Credit Control for SIP sessions. 4492 While the flow focuses on illustrating the usage of credit-control 4493 messages, the SIP signaling is inaccurate and the diagram is not by 4494 any means an attempt to define a service provider's SIP network. 4495 However, for the sake of this example some assumption is made as 4496 discussed in the next paragraph. 4498 Typically, prepaid services based e.g. on time usage for SIP session 4499 require an entity in the service provider network to intercept all 4500 the requests within the SIP dialog in order to detect events, such 4501 as session establishment and session release, which are essential to 4502 perform credit-control operations with the credit control server. It 4503 is, therefore, assumed in this example that the SIP Proxy record- 4504 route since the initial INVITE to make sure that all the future 4505 requests in the created dialog traverse through it. Finally, the 4506 degree of credit control measuring of the media by the proxy depends 4507 on the business model design used in setting up the end system and 4508 proxies in the SIP network 4510 The end user (SIP User Agent A) sends REGISTER with credentials (i). 4511 The SIP Proxy sends a request to the home AAA server to perform 4512 Multimedia authentication and authorization by using for instance 4513 Diameter Multimedia application (ii). The home AAA server checks 4514 that the credentials are correct and checks the user profile. 4515 Eventually, 200 OK response (iii) is sent to the UA. Note that the 4516 Authentication and Authorization is valid for the registration 4517 validity period duration (i.e. until re-registration is performed), 4518 of several SIP sessions may be established without re-authorization 4519 is performed. 4521 UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- 4522 Control-Request (INITIAL_REQUEST) to the Diameter credit-control 4523 server (2). The Credit-Control-Request contains information obtained 4524 from the SIP signaling describing the requested service (e.g. 4525 calling party, called party, Session Description Protocol 4526 attributes). The Diameter credit-control server checks the end 4527 user's account balance, rates the service and reserves credit from 4528 the end user's account. The reserved quota is returned to the SIP 4529 Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy 4530 forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. 4531 The media flows between them and the SIP Proxy starts measuring the 4532 quota. At the expiry of the allocated quota, the SIP Proxy sends a 4533 Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 4534 credit-control server (5). This message contains the units used this 4535 far. The Diameter credit-control server debits the used units from 4536 the end user's account and allocates new credit that is returned to 4537 the SIP Proxy in the Diameter Credit-Control-Answer (6). The end 4538 user terminates the service by sending a BYE (7). The SIP Proxy 4539 forwards the BYE message to UA B (8) and sends a Diameter Credit- 4540 Control-Request (TERMINATION_REQUEST) to the Credit-control server 4541 (9). The Diameter Credit-control server acknowledges the session 4542 termination by sending a Diameter Credit-Control-Answer to the SIP 4543 Proxy (10). 4545 A.3 Flow III 4547 MMS Server 4548 A (CC Client) B CC Server 4549 |(1) Send MMS | | | 4550 |--------------->| | | 4551 | |(2) CCR (event, DIRECT_DEBITING,| 4552 | | MMS specific AVP) | 4553 | |-------------------------------->| 4554 | |(3) CCA (granted_Units) | 4555 | |<--------------------------------| 4556 |(4) Send MMS Ack| | | 4557 |<---------------| | | 4558 | |(5) Notify MMS | | 4559 | |--------------->| | 4560 : : : : 4561 | |(6) Retrieve MMS| | 4562 | |<---------------| | 4563 | |(7) Retrieve MMS| | 4564 | | Ack | | 4565 | |--------------->| | 4566 | | | | 4568 Figure A.3: Flow III 4570 A credit control flow for Multimedia Messaging Services is shown in 4571 Figure A.3. The sender is charged as soon as the messaging server 4572 successfully stores the message. 4574 The end user A sends a Multimedia Message (MMS) to the MMS Server 4575 (1). The MMS Server stores the message and sends a Diameter Credit- 4576 Control-Request (EVENT_REQUEST with Requested-Action: 4577 DIRECT_DEBITING) to the Diameter credit-control server (2). The 4578 Credit-Control-Request contains information about the MMS message 4579 (e.g. size, recipient address, image coding type). The Diameter 4580 credit-control server checks the end user's account balance, rates 4581 the service and debits the service from the end user's account. The 4582 granted quota is returned to the MMS Server in the Diameter Credit- 4583 Control-Answer (3). The MMS Server acknowledges the successful 4584 reception of the MMS message (4). The MMS Server notifies the 4585 recipient about the new MMS (5), and the end user B retrieves the 4586 message from the MMS message store (6),(7). 4588 A.4 Flow IV 4590 MMS Server 4591 Content Server (CC Client) B CC Server 4592 |(1) Send MMS | | | 4593 |--------------->| | | 4594 | |(2) CCR (event, BALANCE_CHECK, | 4595 | | MMS specific AVP) | 4596 | |-------------------------------->| 4597 | |(3) CCA (ENOUGH_CREDIT) | 4598 | |<--------------------------------| 4599 |(4) Send MMS Ack| | | 4600 |<---------------| | | 4601 | |(5) Notify MMS | | 4602 | |--------------->| | 4603 : : : : 4604 | |(6) Retrieve MMS| | 4605 | |<---------------| | 4606 | |(7) CCR (event, DIRECT_DEBITING,| 4607 | | MMS specific AVP) | 4608 | |-------------------------------->| 4609 | |(8) CCA (granted_Units) | 4610 | |<--------------------------------| 4611 | |(9) Retrieve MMS| | 4612 | | Ack | | 4613 | |--------------->| | 4614 | | | | 4616 Figure A.4: Flow IV 4618 This is an example of Diameter Credit Control for Direct Debiting 4619 using Multimedia Messaging Service environment. While the flow 4620 focuses on illustrating the usage of credit-control messages, the 4621 MMS signaling is inaccurate and the diagram is not by any means an 4622 attempt to define any service provider's MMS configuration or 4623 billing model. 4625 A credit control flow for Multimedia Messaging Service is shown in 4626 Figure A.4. The recipient is charged at the message delivery. 4628 A Content Server sends a Multimedia Message (MMS) to the MMS Server 4629 (1) that stores the message. The message recipient will be charged 4630 for the MMS message in this case. Since there can be substantially 4631 long time between the reception of the message at the MMS Server and 4632 the actual retrieval of the message, the MMS Server does not 4633 establish any credit control session to the Diameter Credit-Control 4634 Server but performs first only a balance check (without any credit 4635 reservation) by sending a Diameter Credit-Control-Request 4636 (EVENT_REQUEST with Requested-Action: BALANCE_CHECK) to verify that 4637 the end user B's can cover the cost for the MMS (2). The Diameter 4638 credit-control server checks the end user's account balance and 4639 returns the answer to the MMS Server in the Diameter Credit-Control- 4640 Answer (3). The MMS Server acknowledges the successful reception of 4641 the MMS message (4). The MMS Server notifies the recipient about the 4642 new MMS (5), and after some time the end user B retrieves the 4643 message from the MMS message store (6). The MMS Server sends a 4644 Diameter Credit-Control-Request (EVENT_REQUEST with Requested- 4645 Action: DIRECT_DEBITING) to the Diameter Credit-control server (7). 4646 The Credit-Control-Request contains information about the MMS 4647 message (e.g. size, recipient address, coding type). The Diameter 4648 credit-control server checks the end user's account balance, rates 4649 the service and debits the service from the end user's account. The 4650 granted quota is returned to the MMS Server in the Diameter Credit- 4651 Control-Request (8). The MMS is transferred to the end user B (9). 4653 Note that the transfer of the MMS message can take an extended time, 4654 and can fail, in which case a recovery action is needed. The MMS 4655 Server should return the already debited units to the user's account 4656 by using the REFUND action described in section 6.4. 4658 A.5 Flow V 4660 SIP Controller 4661 A (CC Client) B CC Server 4662 |(1)INVITE B(SDP)| | | 4663 |--------------->| | | 4664 | |(2) CCR (event, PRICE_ENQUIRY, | 4665 | | SIP specific AVPs) | 4666 | |-------------------------------->| 4667 | |(3) CCA (Cost-Information) | 4668 | |<--------------------------------| 4669 | (4)MESSAGE(URL)| | | 4670 |<---------------| | | 4671 |(5)HTTP GET | | | 4672 |--------------->| | | 4673 |(6)HTTP POST | | | 4674 |--------------->|(7)INVITE(SDP) | | 4675 | |--------------->| | 4676 | | (8)200 OK | | 4677 | (9)200 OK |<---------------| | 4678 |<---------------| | | 4680 Figure A.5: Flow V 4682 This is an example of Diameter Credit Control for SIP sessions. 4683 While the flow focuses on illustrating the usage of credit-control 4684 messages, the SIP signaling is inaccurate and the diagram is not by 4685 any means an attempt to define a service provider's SIP network. 4687 Figure A.5 is an example of Advice of Charge (AoC) service for SIP 4688 call, the user A can be either postpaid or prepaid subscriber using 4689 the AoC service. It is assumed that the SIP Controller also has HTTP 4690 capabilities and delivers an interactive AoC web page with for 4691 instance the cost information, the details of the call derived from 4692 the SDP and a button to accept/not accept the charges (there may be 4693 many other ways to deliver AoC information, however, this flow focus 4694 on the use of the credit control messages). The user has been 4695 authenticated and authorized prior to initiate the call and 4696 subscribed to AoC service. 4698 UA A sends an INVITE with SDP to B (1). The SIP controller 4699 determines the user is subscribed to AoC service and sends a 4700 Diameter Credit-Control-Request (EVENT_REQUEST with Requested- 4701 Action: PRICE_ENQUIRY) to the Diameter credit control server (2). 4702 The Credit-Control-Request contains SIP specific AVPs derived from 4703 the SIP signaling describing the requested service (e.g. calling 4704 party, called party, Session Description Protocol attributes). The 4705 Diameter credit control server determines the cost of the service 4706 and returns the Credit-Control-Answer including the Cost-Information 4707 AVP (3). The SIP controller manufactures the AoC web page with 4708 information received in SIP signaling and with the cost information 4709 received from the credit control server, then sends a SIP MESSAGE 4710 that contains a URL pointing to the AoC information web page (4). At 4711 the reception of the SIP MESSAGE the A's UA invokes automatically 4712 the web browser that retrieves the AoC information (5). The user 4713 clicks on a proper button and accept the charges (6). The SIP 4714 controller continues the session and sends the INVITE to the B party 4715 that accepts the call (7,8,9). 4717 A.6 Flow VI 4719 Gaming Server 4720 End-User (CC Client) CC Server 4721 | (1)Service Delivery | | 4722 |<---------------------->| | 4723 : : : 4724 : : : 4725 | |(2)CCR(event,REFUND,Requested- 4726 | |Service-Unit,Service-Parameter-Info) 4727 | |----------------------->| 4728 | | (3)CCA(Cost-Information) 4729 | |<-----------------------| 4730 | (4)Notification | | 4731 |<-----------------------| | 4733 Figure A.6: Flow VI 4735 Figure A.6 illustrates a credit control flow for the REFUND case. It 4736 is assumed that trusted relationship and secure connection between 4737 the Gaming server and the Diameter credit control server exist. The 4738 end user may be a prepaid subscriber or a postpaid subscriber. 4740 While the end user is playing the game (1) she enters a new level 4741 that entitles for a bonus. The Gaming server sends a Diameter 4742 Credit-Control-Request (EVENT_REQUEST with Requested-Action: REFUND) 4743 to the Diameter credit control server (2). The Credit-Control- 4744 Request contains the Requested-Service-Unit AVP with Unit-Type set 4745 to CREDIT_TYPE_SERVICE_SPECIFIC with the CC-Service-Specific-Units 4746 containing the number of points the user just won. The Service- 4747 Parameter-Info AVP is also included in the request and specifies the 4748 service event to be rated (e.g. Tetris Bonus). The Diameter credit 4749 control server, based on received information, determines the amount 4750 to be credited, refunds the user's account and returns the Credit- 4751 Control-Answer including the Cost-Information AVP (3). The Cost- 4752 Information indicates the credited amount. At the first opportunity 4753 the Gaming server notify the end user of the credited amount (4). 4755 A.7 Flow VII 4757 SIP Controller Top-UP 4758 A (CC Client) Server B CC 4759 Server 4760 | | | | | 4761 | | (1) CCR(Update,Used-Unit) | | 4762 | |------------------------------------------>| 4763 | | (2) CCA(Final-Unit, Redirect)| 4764 | |<------------------------------------------| 4765 : : : : : 4766 : : : : : 4767 | | (3) CCR(Update, Used-Units)| | 4768 | |------------------------------------------>| 4769 | | (3a)INVITE("hold") | | 4770 | |--------------------------->| | 4771 | | | (4) CCA(Validity-Time)| 4772 | |<------------------------------------------| 4773 | (5)INVITE | (6)INVITE | | | 4774 |<--------------|------------->| | | 4775 | (7)RTP | | | 4776 |..............................| | | 4777 | | (8)BYE | | | 4778 | |<-------------| | | 4779 | | (9)CCR(Update) | | 4780 | |------------------------------------------>| 4781 | | (10)CCA(Granted-Unit) | 4782 | |<------------------------------------------| 4783 | (12)INVITE | (11)INVITE | | 4784 |<--------------|--------------------------->| | 4786 Figure A.7: Flow VII 4788 Figure A.7 is an example of the graceful service termination for a 4789 SIP call. It is assumed the call is set up so that the controller is 4790 in the call as a B2BUA (Back to Back User Agent) performing third 4791 party call control (3PCC). Note that the SIP signaling is inaccurate 4792 since the focus of this flow is in the graceful service termination 4793 and credit control authorization, best practice for 3PCC are defined 4794 in [RFC3725]. 4796 The call is ongoing between user A and user B, user A is a prepaid 4797 user. At the expiry of the allocated quota, the SIP controller sends 4798 a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 4799 credit control server (1). This message contains the units used this 4800 far. The Diameter credit control server debits the used units from 4801 the end user's account and allocates the final quota that is 4802 returned to the SIP controller in the Diameter Credit-Control-Answer 4803 (2). This message contains the Final-Unit-Indication AVP with: the 4804 Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to 4805 SIP URI and the Redirect-Server-Address set to the Top-up server 4806 name (e.g. sip:sip-topup-server@domain.com). At the expiry of the 4807 final allocated quota, the SIP controller sends a Diameter Credit- 4808 Control-Request (UPDATE_REQUEST) to the Diameter credit control 4809 server (3) and places the called party on "hold" by sending an 4810 INVITE with the appropriate connection address in the SDP (3a). The 4811 Credit-Control-Request message contains the units used this far. The 4812 Diameter credit control server debits the used units from the end 4813 user's account but does not make any credit reservation. The Credit- 4814 Control-Answer message, that contains the Validity-Time to supervise 4815 the graceful service termination, is returned to the SIP controller 4816 (4). The SIP controller establishes a SIP session between the 4817 prepaid user and the Top-up server (5, 6). The Top-up server plays 4818 an announcement and prompts the user to enter a credit card number 4819 and the amount of money to be used to replenish the account (7). The 4820 Top-up server validates the credit card number and replenishes the 4821 user's account (using some means outside the scope of this 4822 specification) and releases the SIP session (8). The SIP controller 4823 can now assume that communication between the prepaid user and the 4824 Top-up server took place and thus sends a spontaneous Credit- 4825 Control-Request (UPDATE_REQUEST) to the Diameter credit control 4826 server to check if the account has been replenished (9). The 4827 Diameter credit control server reserves credit from the end user's 4828 account and return the reserved quota to the SIP controller in the 4829 Credit-Control-Answer (10). At this point, the SIP controller re- 4830 connects the caller and the called party (11,12). 4832 A.8 Flow VIII 4834 End-User NAS AAA Server Top-up CC 4835 Server 4836 (CC Client) Server 4837 |(1)User Logon |(2)AA Request (CC AVPs) | | 4838 |------------------>|------------------->| | | 4839 | | |(3)CCR(initial, CC 4840 AVPs) 4841 | | |------------------->| 4842 | | |(4)CCA(Final-Unit, | 4843 | | | Validity-Time)| 4844 | | |<-------------------| 4845 | |(5)AA Answer(Final-Unit,Validity-Time) | 4846 |(6)Limited Access |<-------------------| | | 4847 | granted | | | | 4848 |<----------------->| | | | 4849 | | | | | 4850 | (7)TCP/HTTP | (8)TCP/HTTP | | 4851 |<----------------->|<----------------------------->| | 4852 | (9) Replenish account | | 4853 |<------------------------------------------------->| | 4854 | | | (10)RAR | 4855 | |<-------------------|<-------------------| 4856 | | (11) RAA | | 4857 | |------------------->|------------------->| 4858 | |(12)CCR(update) | | 4859 | |------------------->|(13)CCR(Update) | 4860 | | |------------------->| 4861 | | |(14)CCA(granted Units) 4862 | |(15)CCA(granted Units)<------------------| 4863 | |<-------------------| | 4865 Figure A.8: Flow VIII 4867 Figure A.8 is an example of the graceful service termination 4868 initiated when the first interrogation take place due to user's 4869 account is empty. In this example the credit control server 4870 supports the server initiated credit re-authorization. The Diameter 4871 [NASREQ] is implemented in the Network Access Server (NAS). 4873 The user logs onto the network (1). The Diameter NAS first sends a 4874 Diameter Authorization-Authentication-Request to the home Diameter 4875 AAA Server, the credit-control client populates the AAR with the 4876 Credit-Control AVP set to CREDIT_AUTHORIZATION and service specific 4877 AVPs are included as usual [NASREQ]. The home Diameter AAA server 4878 performs service specific Authentication and Authorization as usual. 4879 The home Diameter AAA server determines that the user is a prepaid 4880 user and notices from the Credit-Control AVP that the NAS has credit 4881 control capabilities, it sends a Diameter Credit-Control-Request 4882 with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit- 4883 control server to perform credit authorization (3) and to establish 4884 a credit control session (the home Diameter AAA server may forward 4885 service specific AVPs as received from the NAS as input for the 4886 rating process). The Diameter credit-control server checks the end 4887 user's account balance, determines that the account cannot cover the 4888 cost of the service and initiates the graceful service termination. 4889 The Credit-Control-Answer is returned to the home Diameter AAA 4890 server (4). This message contains the Final-Unit-Indication AVP and 4891 the Validity-Time AVP set to a reasonable time to give chance to the 4892 user to replenish his/her account (e.g. 10 minutes). The Final-Unit- 4893 Indication AVP includes: the Final-Unit-Action set to REDIRECT, the 4894 Redirect-Address-Type set to URL and the Redirect-Server-Address set 4895 to the HTTP Top-up server name. The home Diameter AAA server sends 4896 the received credit control AVPs to the NAS in the Diameter 4897 Authorization-Authentication-Answer (5). Upon successful AAA the NAS 4898 starts the credit-control session and starts immediately the 4899 graceful service termination as instructed by the server. The NAS 4900 grant limited access to the user (6). The HTTP client software 4901 running in the user's device opens the transport connection that is 4902 redirected by the NAS to the Top-up server (7,8). The user is 4903 displayed an appropriate web page where to enter the credit card 4904 number, the amount of money to be used to replenish the account and 4905 with a notification message that she will be granted unlimited 4906 access if the replenishment operation will be successfully executed 4907 within the next e.g. 10 minutes. The Top-up server validates the 4908 credit card number and replenishes the user's account (using some 4909 means outside the scope of this specification)(9). After successful 4910 account top-up the credit control server sends a Re-Auth-Request 4911 message to the NAS (10). The NAS acknowledges the request by 4912 returning the Re-Auth-Answer message (11) and initiates the credit 4913 re-authorization by sending a Credit-Control-request 4914 (UPDATE_REQUEST) to the Diameter credit control server (12,13). 4916 The Diameter credit control server reserves credit from the end 4917 user's account and return the reserved quota to the NAS via the home 4918 Diameter AAA server in the Credit-Control-Answer (14,15). The NAS 4919 removes the restriction placed by the graceful service termination 4920 and starts monitoring the granted units. 4922 A.9 Flow IX 4924 The Diameter Credit Control Application defines the Multiple- 4925 Services-Credit-Control AVP that can be used to support independent 4926 credit control of multiple services in a single credit control (sub- 4927 )session for service elements that have such capabilities. 4928 It is possible to request and allocate resources as a credit 4929 pool that is shared between services or rating groups. 4931 The flow example hereafter illustrates a usage scenario where the 4932 Credit-control client and server support independent credit control 4933 of multiple services as defined in section 5.1.2. It is assumed 4934 that Service-Identifiers, Rating-Groups and their associated 4935 parameters (e.g. IP 5-tuple) are locally configured in the Service 4936 Element or provisioned by another entity than the credit control 4937 server. 4939 End-User Service Element CC Server 4940 (CC client) 4941 |(1)User logon | | 4942 |------------------>|(2)CCR(initial, Service-Id access, | 4943 | | Access specific AVPs, | 4944 | | Multiple-Service-Indicator) | 4945 | |---------------------------------------->| 4946 | |(3)CCA(Multiple-Services-CC ( | 4947 | | Granted-Units(Total-Octets), | 4948 | | Service-Id access, | 4949 | | Validity-time, | 4950 | | G-S-U-Pool-Reference(Pool-Id 1, | 4951 | | Multiplier 10))) | 4952 | |<----------------------------------------| 4953 : : : 4954 |(4)Service-Request (Service 1) | 4955 |------------------>|(5)CCR(update, Multiple-Services-CC( | 4956 | | Requested-Units(), Service-Id 1, | 4957 | | Rating-Group 1)) | 4958 | |---------------------------------------->| 4959 | |(6)CCA(Multiple-Services-CC ( | 4960 | | Granted-Units(Time), | 4961 | | Rating-Group 1, | 4962 | | G-S-U-Pool-Reference(Pool-Id 1, | 4963 | | Multiplier 1))) | 4964 | |<----------------------------------------| 4965 : : : 4966 |(7)Service-Request (Service 2) | 4967 |------------------>| | 4968 : : : 4969 : : : 4971 |(8)Service-Request (Service 3&4) | 4972 |------------------>|(9)CCR(update, Multiple-Services-CC ( | 4973 | | Requested-Units(), Service-Id 3, | 4974 | | Rating-group 2), | 4975 | | Multiple-Services-CC ( | 4976 | | Requested-Units(), Service-Id 4, | 4977 | | Rating-Group 3)) | 4978 | |---------------------------------------->| 4979 | |(10)CCA(Multiple-Services-CC ( | 4980 | | Granted-Units(Total-Octets), | 4981 | | Service-Id 3, Rating-group 2, | 4982 | | Validity-time, | 4983 | | G-S-U-Pool-Reference(Pool-Id 2, | 4984 | | Multiplier 2)), | 4985 | | Multiple-Services-CC ( | 4986 | | Granted-Units(Total-Octets), | 4987 | | Service-Id 4, Rating-group 3 | 4988 | | Validity-time, | 4989 | | Final-Unit-Ind.(Terminate), | 4990 | | G-S-U-Pool-Reference(Pool-Id 2, | 4991 | | Multiplier 5))) | 4992 | |<----------------------------------------| 4993 : : : 4994 : : : 4995 | +--------------+ | | 4996 | |Validity time | |(11)CCR(update, | 4997 | |expires for | | Multiple-Services-CC ( | 4998 | |Service-Id | | Requested-Unit(), | 4999 | | access | | Used-Units(In-Octets,Out-Octets),| 5000 | +--------------+ | Service-Id access)) | 5001 | |---------------------------------------->| 5002 | |(12)CCA(Multiple-Services-CC ( | 5003 | | Granted-Units(Total-Octets), | 5004 | | Service-Id access, | 5005 | | Validity-time, | 5006 | | G-S-U-Pool-Reference(Pool-Id 1, | 5007 | | Multiplier 10))) | 5008 | |<----------------------------------------| 5009 : : : 5010 : : : 5011 | +--------------+ | | 5012 | |Total Quota | |(13)CCR(update, | 5013 | |elapses for | | Multiple-Services-CC ( | 5014 | |pool 2: | | Requested-Unit(), | 5015 | |service 4 not | | Used-Units(In-Octets,Out-Octets),| 5016 | |allowed, | | Service-Id 3, Rating-group 2), | 5017 | |service 3 cont| | Multiple-Services-CC ( | 5018 | +--------------+ | Used-Units(In-Octets,Out-Octets),| 5019 | | Service-Id 4, Rating-group 3)) | 5020 | |---------------------------------------->| 5021 | |(14)CCA(Multiple-Services-CC ( | 5022 | | Result-Code 4011, | 5023 | | Service-Id 3)) | 5024 | |<----------------------------------------| 5025 : : : 5026 : : : 5027 |(15) User logoff | | 5028 |------------------>|(16)CCR(term, | 5029 | | Multiple-Services-CC ( | 5030 | | Used-Units(In-Octets,Out-Octets),| 5031 | | Service-Id access), | 5032 | | Multiple-Services-CC ( | 5033 | | Used-Units(Time), | 5034 | | Service-Id 1, Rating-group 1), | 5035 | | Multiple-Services-CC ( | 5036 | | Used-Units(Time), | 5037 | | Service-Id 2, Rating-group 1)) | 5038 | |---------------------------------------->| 5039 | |(17)CCA(term) | 5040 | |<----------------------------------------| 5042 Figure A.9: Independent credit control of multiple services in a 5043 Credit Control (sub-)Session, flow example. 5045 The user logs onto the network (1). The Service Element sends a 5046 Diameter Credit-Control-Request with CC-Request-Type set to 5047 INITIAL_REQUEST to the Diameter credit-control server to perform 5048 credit authorization for the bearer service (e.g. internet access 5049 service) and to establish a credit control session (2). In this 5050 message the credit-control client indicates support for independent 5051 credit control of multiple services within the session by including 5052 the Multiple-Service-Indicator AVP. The Diameter credit-control 5053 server checks the end user's account balance, based on the rating 5054 information received from the client (i.e. Service-Id and access 5055 specific AVPs) rates the request and reserves credit from the end 5056 user's account. Say the server reserves $5 and determines the cost 5057 is $1/MB. It then returns to the service element a Credit-Control- 5058 Answer message that include the Multiple-Services-Credit-Control AVP 5059 with a quota of 5MB associated to the Service-Id (access), to a 5060 multiplier value of 10 and to the Pool-Id 1 (3). 5062 The user uses Service 1 (4). The service element sends a Diameter 5063 Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to 5064 the credit control server to perform credit authorization for 5065 service 1 (5). This message includes the Multiple-Services-Credit- 5066 Control AVP to request service units for the Service 1 that belong 5067 to Rating-Group 1. The Diameter credit-control server determines 5068 that Service 1 draws credit resources from the same account as the 5069 access service (i.e. pool 1), based on Service-Id/Rating-Group rates 5070 the request and updates the existing reservation by requesting more 5071 credit. Say the server reserves $5 more (now the reservation is $10) 5072 and determines the cost is $0.1/minutes. The server authorizes the 5073 whole Rating-Group, it then returns to the service element a Credit- 5074 Control-Answer message that include the Multiple-Services-Credit- 5075 Control AVP with a quota of 50min. associated to the Rating-Group 1, 5076 to a multiplier value of 1 and to the Pool-Id 1 (6). The client 5077 adjusts the total amount of resources for pool 1 according the 5078 received quota, which gives S for Pool 1 = 100. 5080 The user uses Service 2 that belongs to the authorized Rating-Group 5081 1 (7). Resources are then consumed from the pool 1. 5083 The user requests now Service 3 and Service 4 as well, that are not 5084 authorized (8). The service element sends a Diameter Credit-Control- 5085 Request with CC-Request-Type set to UPDATE_REQUEST to the credit 5086 control server to perform credit authorization for service 3 and 4 5087 (9). This message includes two instances of the Multiple-Services- 5088 Credit-Control AVP to request service units for the Service 3 that 5089 belong to Rating-Group 2 and for the Service 4 that belong to 5090 Rating-Group 3. The Diameter credit-control server determines that 5091 Service 3 and 4 draw credit resources from another account (i.e. 5092 pool 2), it checks the end user's account balance and based on 5093 Service-Ids/Rating-Groups information rates the request and reserve 5094 credit from pool 2. 5096 For example, the server reserves $5 and determines that Service 3 5097 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes 5098 only Services 3 and 4, it then returns to the service element a 5099 Credit-Control-Answer message that include two instances of the 5100 Multiple-Services-Credit-Control AVP (10). One instance grants a 5101 quota of 12.5MB associated to the Service-Id 3, to a multiplier 5102 value of 2 and to the Pool-Id 2. The other instance grants a quota 5103 of 5 MB associated to the Service-Id 4, to a multiplier value of 5 5104 and to the Pool-Id 2. 5106 The server also determines that pool 2 is exhausted and Service 4 is 5107 not allowed to continue after these units will be consumed. 5108 Therefore the Final-Unit-Indication AVP with action TERMINATE is 5109 associated to the Service-Id 4. The client calculates the total 5110 amount of resources that can be used for Pool 2 according the 5111 received quotas and multipliers, which give S for Pool 2 = 50. 5113 The Validity-Time for the access service expires. The service 5114 element sends a Credit-Control-Request message to the server to 5115 perform credit re-authorization for Service-Id (access) (11). This 5116 message carries one instance of the Multiple-Services-Credit-Control 5117 AVP that includes the units used by this service. Say the total 5118 amount of used units is 4MB. The client adjusts the total amount of 5119 resources for Pool 1 accordingly, which gives S for Pool 1 = 60. 5121 The server deducts $4 from the user's account and updates the 5122 reservation by requesting more credit. Say the server reserves $5 5123 more (now the reservation is $11) and already knows the cost of the 5124 Service-Id (access) that is $1/MB. It then returns to the service 5125 element a Credit-Control-Answer message that include the Multiple- 5126 Services-Credit-Control AVP with a quota of 5 MB associated to the 5127 Service-Id (access), to a multiplier value of 10 and to the Pool-Id 5128 1 (12). The client adjusts the total amount of resources for pool 1 5129 according the received quota, which gives S for Pool 1 = 110. 5131 Services 3 and 4 consume the total amount of Pool 2 credit resources 5132 (i.e. C1*2 + C2*5 >= S). The service element immediately starts the 5133 TERMINATE action concerning Service 4 and sends a Credit-Control- 5134 Request message with CC-Request-Type set to UPDATE_REQUEST to the 5135 credit control server to perform credit re-authorization for Service 5136 3 (13). This message contains two instances of the Multiple- 5137 Services-Credit-Control AVP to report the units used by Service 3 5138 and Service 4. The server deducts the last $5 from the user's 5139 account (Pool 2) and returns the answer with Result-Code 4011 in the 5140 Multiple-Services-Credit-Control AVP to indicate that Service 3 can 5141 continue without credit control (14). 5143 The end user logs off from the network (15). To debit the used units 5144 from the end user's account and to stop the credit control session, 5145 the service element sends a Diameter Credit-Control-Request with CC- 5146 Request-Type set to TERMINATION_REQUEST to the credit control server 5147 (16). This message contains the units consumed by each of the used 5148 services in multiple instances of the Multiple-Services-Credit- 5149 Control AVP. The used units are associated with the relevant 5150 Service-Identifier and Rating-Group. The Diameter credit-control 5151 server debits the used units to the user's account (Pool 1) and 5152 acknowledges the session termination by sending a Diameter Credit- 5153 Control-Answer to the service element (17). 5155 Author's Address 5157 Harri Hakala 5158 Oy L M Ericsson Ab 5159 Joukahaisenkatu 1 5160 20520 Turku 5161 Finland 5162 Phone: +358 2 265 3722 5163 EMail: Harri.Hakala@ericsson.com 5165 Leena Mattila 5166 Oy L M Ericsson Ab 5167 Joukahaisenkatu 1 5168 20520 Turku 5169 Finland 5170 Phone: +358 2 265 3731 5171 EMail: Leena.Mattila@ericsson.com 5173 Juha-Pekka Koskinen 5174 Nokia Networks 5175 Hatanpaanvaltatie 30 5176 33100 Tampere 5177 Finland 5179 Phone: +358 7180 74027 5180 Email: juha-pekka.koskinen@nokia.com 5182 Marco Stura 5183 Nokia Networks 5184 Hiomotie 32 5185 00380 Helsinki 5186 Finland 5187 Phone: +358 7180 64308 5188 Email: marco.stura@nokia.com 5190 John Loughney 5191 Nokia Research Center 5192 Itamerenkatu 11-13 5193 00180 Helsinki 5194 Finland 5195 Phone: +358 50 483 642 5196 Email: John.Loughney@nokia.com 5198 Intellectual Property Statement 5200 The IETF takes no position regarding the validity or scope of any 5201 Intellectual Property Rights or other rights that might be claimed 5202 to pertain to the implementation or use of the technology described 5203 in this document or the extent to which any license under such 5204 rights might or might not be available; nor does it represent that 5205 it has made any independent effort to identify any such rights. 5206 Information on the procedures with respect to rights in RFC 5207 documents can be found in BCP 78 and BCP 79. 5209 Copies of IPR disclosures made to the IETF Secretariat and any 5210 assurances of licenses to be made available, or the result of an 5211 attempt made to obtain a general license or permission for the use 5212 of such proprietary rights by implementers or users of this 5213 specification can be obtained from the IETF on-line IPR repository 5214 at http://www.ietf.org/ipr. 5216 The IETF invites any interested party to bring to its attention any 5217 copyrights, patents or patent applications, or other proprietary 5218 rights that may cover technology that may be required to implement 5219 this standard. Please address the information to the IETF at 5220 ietf-ipr@ietf.org. 5222 Disclaimer of Validity 5224 This document and the information contained herein are provided on 5225 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 5226 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 5227 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 5228 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5229 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5230 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5232 Copyright Statement 5234 Copyright (C) The Internet Society (2004). This document is subject 5235 to the rights, licenses and restrictions contained in BCP 78, and 5236 except as set forth therein, the authors retain all their rights. 5238 Acknowledgment 5240 Funding for the RFC Editor function is currently provided by the 5241 Internet Society.