idnits 2.17.1 draft-ietf-aaa-diameter-cc-02.txt: -(3283): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances 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 : ---------------------------------------------------------------------------- ** There are 271 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 299: '...is specification MUST advertise suppor...' RFC 2119 keyword, line 417: '...rol server, they MUST advertise the Di...' RFC 2119 keyword, line 423: '... MUST be supported by all Diameter i...' RFC 2119 keyword, line 438: '...h-Application-Id MUST be set to the va...' RFC 2119 keyword, line 594: '...that the service SHOULD re-use existin...' (201 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2062 has weird spacing: '...quested to en...' == Line 2072 has weird spacing: '...mporary end ...' -- 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. == 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: Since the credit-control application is based on real-time bi-directional communication between the credit-control client and the credit-control server, the usage of alternative destinations and the buffering of messages MAY NOT be sufficient in the event of communication failures. Since the credit-control server has to maintain session states, moving the credit-control message stream to a backup server requires a complex context transfer solution. Whether the credit-control message stream is moved to a backup credit-control server during an ongoing credit-control session depends on the value of the CC-session-Failover AVP. However, failover may occur at any point in the path between credit-control client and credit-control server in the event that a transport failure is detected with a peer, as described in [DIAMBASE]. As a consequence the credit-control server might receive duplicate messages. These duplicates or out of sequence messages can be detected in the credit-control server based on the credit-control server session state machine (section 7), Session-Id AVP and CC-Request-Number AVP. == 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: 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 (December 16, 2003) is 7435 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: 'KEYWORDS' is mentioned on line 3593, but not defined == Missing Reference: 'NASREQ' is mentioned on line 4266, but not defined == Missing Reference: 'DiamMip' is mentioned on line 224, but not defined == Missing Reference: 'RFC2866' is mentioned on line 3599, but not defined == Missing Reference: 'DIAMMIP' is mentioned on line 3604, but not defined == Missing Reference: 'DiamMIP' is mentioned on line 2194, but not defined == Missing Reference: 'Update' is mentioned on line 1138, but not defined == Missing Reference: 'AAATRANS' is mentioned on line 1481, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 2691, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'E121' is mentioned on line 2874, but not defined == Missing Reference: 'CE121' is mentioned on line 2875, but not defined == Missing Reference: 'RFC2865' is mentioned on line 3607, but not defined == Missing Reference: 'DIAMEAP' is mentioned on line 3611, but not defined == Missing Reference: 'ACCMGMT' is mentioned on line 3596, but not defined == Unused Reference: 'E212' is defined on line 3579, but no explicit reference was found in the text == Unused Reference: 'CE212' is defined on line 3583, 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) Summary: 9 errors (**), 0 flaws (~~), 25 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group 2 Internet Draft Harri Hakala 3 Document: draft-ietf-aaa-diameter-cc-02.txt Leena Mattila 4 Expires: June 2004 Ericsson 5 Juha-Pekka Koskinen 6 Marco Stura 7 John Loughney 8 Nokia 9 December 16, 2003 11 Diameter Credit-Control Application 13 Status of this memo 15 This document is an Internet-Draft and is subject to all provisions of 16 Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a product of the Authentication, Authorization and 34 Accounting (AAA) Working Group of the Internet Engineering Task Force 35 (IETF). Comments are welcome should be submitted to the mailing list 36 aaa-wg@merit.edu. 38 Abstract 40 This document specifies a DIAMETER application that can be used to 41 implement real-time credit-control for a variety of end user services 42 such as network access, SIP services, messaging services, download 43 services etc. 45 1. Introduction...................................................5 46 1.1 Requirements language......................................5 47 1.2 Terminology................................................6 48 1.3 Advertising application support............................7 49 2. Architecture Models............................................7 50 3. Credit-Control Messages.......................................10 51 3.1 Credit-Control-Request (CCR) Command......................10 52 3.2 Credit-Control-Answer (CCA) Command.......................11 53 4. Credit Control Application Overview...........................12 54 4.1 Service-Specific Rating Input and Interoperability........13 55 5. Session Based Credit-control..................................15 56 5.1 First Interrogation.......................................16 57 5.2 Intermediate Interrogation................................21 58 5.3 Final Interrogation.......................................23 59 5.4 Server-Initiated Credit Re-Authorization..................24 60 5.5 Graceful Service Termination..............................25 61 5.6 Failure Procedures........................................30 62 6. One Time Event................................................33 63 6.1 Service Price Enquiry.....................................34 64 6.2 Balance Check.............................................34 65 6.3 Direct Debiting...........................................35 66 6.4 Refund....................................................36 67 6.5 Failure Procedure.........................................36 68 7. Credit Control Application State Machine......................38 69 8. Credit Control AVPs...........................................48 70 8.1 CC-Correlation-Id AVP.....................................50 71 8.2 CC-Request-Number AVP.....................................50 72 8.3 CC-Request-Type AVP.......................................50 73 8.4 CC-Session-Failover AVP...................................51 74 8.5 CC-Sub-Session-Id AVP.....................................52 75 8.6 Check-Balance-Result AVP..................................52 76 8.7 Cost-Information AVP......................................52 77 8.8 Cost-Unit AVP.............................................53 78 8.9 Credit-Control AVP........................................53 79 8.10 Credit-Control-Failure-Handling AVP......................54 80 8.11 Currency-Code AVP........................................55 81 8.12 Direct-Debiting-Failure-Handling AVP.....................55 82 8.13 Exponent AVP.............................................56 83 8.14 Final-Unit-Action AVP....................................56 84 8.15 Final-Unit-Indication AVP................................56 85 8.16 Granted-Service-Unit AVP.................................57 86 8.17 Redirect-Address-Type AVP................................58 87 8.18 Redirect-Server AVP......................................59 88 8.19 Redirect-Server-Address AVP..............................59 89 8.20 Requested-Action AVP.....................................59 90 8.21 Requested-Service-Unit AVP...............................60 91 8.22 Restriction-Filter-Rule AVP..............................61 92 8.23 Service-Parameter-Info AVP...............................61 93 8.24 Service-Parameter-Type AVP...............................61 94 8.25 Service-Parameter-Value AVP..............................62 95 8.26 Subscription-Id AVP......................................62 96 8.27 Subscription-Id-Data AVP.................................62 97 8.28 Subscription-Id-Type AVP.................................62 98 8.29 Unit-Value AVP...........................................63 99 8.30 Used-Service-Unit AVP....................................63 100 8.31 Value-Digits AVP.........................................64 101 8.32 Validity-Time AVP........................................64 102 8.33 CC-Input-Octets AVP......................................64 103 8.34 CC-Money AVP.............................................64 104 8.35 CC-Output-Octets AVP.....................................65 105 8.36 CC-Service-Specific-Units AVP............................65 106 8.37 CC-Time AVP..............................................65 107 8.38 CC-Total-Octets AVP......................................65 108 8.39 Rating-Group AVP.........................................65 109 8.40 Service-Identifier AVP...................................65 110 8.41 Tariff-Time-Change AVP...................................66 111 8.42 Tariff-Change-Usage AVP..................................66 112 9. Result Code AVP values........................................67 113 9.1 Transient Failure.........................................67 114 9.2 Permanent Failures........................................67 115 10. AVP Occurrence Table.........................................68 116 10.1 Credit Control AVP Table.................................68 117 11. RADIUS/Diameter Credit-control Interworking..................69 118 11.1 Initial RADIUS Access-Request............................70 119 11.2 Subsequent RADIUS Access-Request message.................71 120 11.3 RADIUS Vendor Specific Attributes for Credit Control.....72 121 12. IANA Considerations..........................................72 122 12.1 Application Identifier...................................73 123 12.2 Command Codes............................................73 124 12.3 AVP Codes................................................73 125 12.4 Result-Code AVP Values...................................73 126 12.5 CC-Request-Type AVP......................................73 127 12.6 CC-Session-Failover AVP..................................73 128 12.7 Check-Balance-Result AVP.................................73 129 12.8 Credit-Control AVP.......................................73 130 12.9 Credit-Control-Failure-Handling AVP......................73 131 12.10 Direct-Debiting-Failure-Handling AVP....................74 132 12.11 Final-Unit-Action AVP...................................74 133 12.12 Redirect-Address-Type AVP...............................74 134 12.13 Requested-Action AVP....................................74 135 12.14 Subscription-Id-Type AVP................................74 136 12.15 Tariff-Change-Usage AVP.................................74 137 13. Credit-control Application Related Parameters................74 138 14. Security Consideration.......................................75 139 14.1 Direct Connection with Redirects.........................76 140 15. References...................................................77 141 15.1 Normative................................................77 142 15.2 Non-Normative............................................77 143 16. Acknowledgement..............................................78 144 17. Author's Address.............................................78 145 18. Full Copyright Statement.....................................79 146 19. Notices......................................................79 147 20. Expiration Date..............................................80 148 Appendix A Credit Control sequences..............................80 149 A.1 Flow I...................................................80 150 A.2 Flow II..................................................82 151 A.3 Flow III.................................................83 152 A.4 Flow IV..................................................85 153 A.5 Flow V...................................................86 154 A.6 Flow VI..................................................87 155 A.7 Flow VII.................................................88 156 A.8 Flow VIII................................................89 157 A.9 Flow IX..................................................90 158 A.10 Flow X...................................................92 160 1. Introduction 162 This document specifies a DIAMETER application that can be used to 163 implement real-time credit-control for a variety of end user services 164 such as network access, SIP services, messaging services, download 165 services etc. It provides a general solution to the real-time cost and 166 credit control. 168 The prepaid model shown to be very successful for instance in GSM 169 networks where network operators offering prepaid services have 170 experienced a substantial growth of their customer base and revenues, 171 prepaid services are now cropping up in many other wireless and wire 172 line based networks as well. 174 In next generation wireless networks, additional functionality is 175 required beyond that specified in the Diameter base protocol. For 176 example, the 3GPP Charging and Billing requirements [3GPPCHARG] state 177 that an application must be able to rate service information in real- 178 time. In addition, it is necessary to check that the end user's 179 account provides coverage for the requested service, prior to 180 initiation of that service. When an account is exhausted or expired, 181 the user must be denied the ability to compile additional chargeable 182 events. 184 A mechanism needs to be provided to allow the user to be informed of 185 the charges to be levied for a requested service. In addition, there 186 are services such as gaming and advertising that may credit as well as 187 deduct from a user account. 189 The currently existing Diameter applications provide service specific 190 authorization and they do not provide credit authorization for prepaid 191 users. The credit authorization shall be generic and applicable to all 192 the service environments required to support prepaid services. 194 To fulfill these requirements, it is necessary to facilitate 195 communication between the network element providing the service (e.g. 196 NAS, SIP Proxy, Application Server etc.) and a credit-control server, 197 in order to minimize financial risk. 199 The scope of this specification is the credit authorization. Service 200 specific authorization and authentication is out of the scope. 202 1.1 Requirements language 204 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 205 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 206 described in [KEYWORDS]. 208 1.2 Terminology 210 AAA 212 Authentication, Authorization and Accounting 214 AA answer 216 AA answer does generically refer to a service specific authorization 217 and authentication answer. AA answer commands are defined in service 218 specific authorization applications e.g. [NASREQ] and [DiamMip]. 220 AA request 222 AA request does generically refer to a service specific authorization 223 and authentication request. AA request commands are defined in service 224 specific authorization applications e.g. [NASREQ] and [DiamMip]. 226 Credit-control 228 Credit-control is a mechanism, which directly interacts in real-time 229 with an account and controls or monitors the charges, related to the 230 service usage. Credit-control is a process of checking if credit is 231 available, credit-reservation, deduction of credit from the end user 232 account when service is completed and refunding of reserved credit not 233 used. 235 Diameter Credit-control Server 237 Diameter Credit-control server acts as a prepaid server, performing 238 real-time rating and credit control. It is located in the home domain 239 and is accessed by service elements or AAA servers in real-time for 240 purpose of price determination and credit-control before the service 241 event is delivered to the end-user. It may also interact with business 242 support systems. 244 Diameter Credit-control Client 246 A Diameter credit-control client is an entity that interacts with a 247 credit-control server. It monitors the usage of the granted quota 248 according to instructions returned by credit-control server. 250 Interrogation 252 The Diameter credit-control client uses interrogation to initiate a 253 session based credit-control process and during the credit-control 254 process to report the used quota and request a new one. An 255 interrogation maps to a request/answer transaction. 257 One-time event 259 Basically a request/answer transaction of type event. The credit- 260 control server is not required to maintain session state for one-time 261 event. 263 Rating 265 The act of determining the cost of the service event. 267 Service 269 A type of task that is performed by a service element for an end user. 271 Service Element 273 A network element that provides a service to the end users. The 274 Service Element may include the Credit-control Client, or another 275 entity (e.g. RADIUS AAA server) can act as a Credit-control Client on 276 behalf of the Service Element. In the latter case the interface 277 between the Service Element and the Diameter Credit-control Client is 278 outside the scope of this specification. Examples of the Service 279 Elements include NAS, Sip Proxy and Application Servers such as 280 messaging server, content server and gaming server. 282 Service Event 284 An event relating to a service provided to the end user. 286 Session based credit-control 288 Credit-control process that makes use of several interrogations: the 289 first, possible intermediates and the final interrogation. The first 290 interrogation is used to reserve money from the user's account and 291 initiate the process. The intermediate interrogations may be needed to 292 request new quota while the service is being rendered. The final 293 interrogation is used to exit the process. The credit-control server 294 is required to maintain session state for session-based credit- 295 control. 297 1.3 Advertising application support 299 Diameter nodes conforming to this specification MUST advertise support 300 by including the value of 4 in the Auth-Application-Id of the 301 Capabilities-Exchange-Request and Capabilities-Exchange-Answer command 302 [DIAMBASE]. 304 2. Architecture Models 305 The current accounting models specified in the Radius Accounting 306 [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real- 307 time credit control, where credit-worthiness is to be determined prior 308 to service initiation. Also, the existing Diameter authorization 309 applications [NASREQ] and [DIAMMIP] only provides service 310 authorization, but do not provide credit authorization for prepaid 311 users. In order to support real-time credit control a new type of 312 server is needed in the AAA infrastructure; Diameter credit-control 313 server. The Diameter credit-control server is the entity responsible 314 of credit authorization for prepaid subscribers. 316 A service element may authenticate and authorize the end user with the 317 AAA server using AAA protocols, e.g. RADIUS or a Diameter base 318 protocol with a possible Diameter application. 320 Accounting protocols such as RADIUS accounting and the Diameter base 321 accounting protocol can be used to provide accounting data to the 322 accounting server after service is initiated, and to provide possible 323 interim reports until service completion. However, for real-time 324 credit control, these authorization and accounting models are not 325 sufficient. 327 When real-time credit-control is required, the credit-control client 328 contacts the credit-control server with possible service event 329 information included before the service is provided to the end user. 330 This process is performed in order to determine potential charges and 331 to verify whether the end user's account balance is sufficient to 332 cover the cost of the service being rendered. 334 Figure 1 illustrates the typical credit-control architecture, which 335 consist of a Service Element with embedded Diameter credit-control 336 client, a Diameter credit-control server and an AAA server. A Business 337 Support System is usually deployed; it includes at least the billing 338 functionality. The credit-control server and AAA server in this 339 architecture model are logical entities. The real configuration can 340 combine them into a single host. The credit-control protocol is the 341 Diameter base protocol with the Diameter credit-control application. 343 When an end user requests services such as for instance SIP services 344 or messaging services, the request is typically forwarded to a service 345 element (e.g. SIP Proxy) in the user's home domain. In some cases it 346 might be possible that the service element in the visited domain can 347 offer services to the end user, however a commercial agreement must 348 exist between the visited domain and the home domain. Network access 349 is an example of a service offered in the visited domain where the 350 NAS, through an AAA infrastructure, authenticates and authorizes the 351 user with the user's home network. 353 Service Element AAA and credit-control 355 +----------+ +---------+ protocols +-----------+ +--------+ 356 | End |<---->|+-------+|<------------>| AAA | |Business| 357 | User | +->|| CC || | Server |->|Support | 358 | | | || client||<-----+ | | |System | 359 +----------+ | |+-------+| | +-----------+ | | 360 | +---------+ | ^ +--------+ 361 +----------+ | | CC protocol | ^ 362 | End |<--+ | +-----v----+ | 363 | User | +------>|Credit- | | 364 +----------+ credit-control |control |--------+ 365 protocol |server | 366 +----------+ 368 Figure 1: Typical credit-control architecture 370 Other entities, such as RADIUS AAA server, may act as a Diameter 371 credit-control client towards the Diameter credit-control server for 372 service elements that use credit control mechanisms other than 373 Diameter credit-control. In this case the AAA server contact the 374 Diameter credit-control server as part of the authorization process. 375 The interworking architecture is illustrated in Figure 2, the 376 interaction between the Diameter credit-control client and the service 377 element is outside the scope of this specification. Interworking with 378 RADIUS is addressed in section 11 and Annex A. 380 AAA 381 +--------+ +---------+ protocol +------------+ +--------+ 382 | End |<----->| Service |<------------>| AAA | |Business| 383 | User | | Element | | Server | |Support | 384 +--------+ +-->| | |+----------+|-->|System | 385 | +---------+ ||CC client || | | 386 | |+----------+| | | 387 +--------+ | +------^-----+ +--------+ 388 | End |<--+ credit-control | ^ 389 | User | protocol | | 390 +--------+ +-------V------+ | 391 |Credit-control|--------+ 392 | Server | 393 +--------------+ 395 Figure 2: Credit-control architecture with Service Element not 396 supporting the credit-control protocol 398 There can be multiple credit-control servers in the system for reasons 399 of redundancy and load balancing. The system can also contain separate 400 rating server(s) and accounts can locate in a centralized database. 401 For duplicate detection only one place in the credit-control system 402 should perform duplicate detection to ensure that the end user's 403 account is not debited or credited multiple times for the same service 404 event. System internal interfaces can exist to relay messages between 405 servers and an account manager. However the detailed architecture of 406 credit-control system and its interfaces are implementation specific 407 and are out of scope of this specification. 409 There can exist protocol transparent Diameter relays and redirect 410 agents between credit-control client and credit-control server. Also 411 Diameter Redirect agents, which refer credit control clients to credit 412 control servers and allow them to communicate directly can exist. 413 These agents transparently support the Diameter credit-control 414 application. 416 If Diameter credit-control proxies exist between the credit-control 417 client and the credit-control server, they MUST advertise the Diameter 418 credit-control application support. 420 3. Credit-Control Messages 422 This section defines new Diameter message Command-Code values that 423 MUST be supported by all Diameter implementations that conform to this 424 specification. The Command Codes are: 426 Command-Name Abbrev. Code Reference 427 ----------------------------------------------------------- 428 Credit-Control-Request CCR 272 3.1 429 Credit-Control-Answer CCA 272 3.2 431 3.1 Credit-Control-Request (CCR) Command 433 The Credit-Control-Request message (CCR), indicated by the command- 434 code field set to 272 and the 'R' bit set in the Command Flags field, 435 is used between the Diameter credit-control client and the credit- 436 control server to request credit authorization for a given service. 438 The Auth-Application-Id MUST be set to the value 4 indicating the 439 Diameter credit-control application. 441 Message Format 443 ::= < Diameter Header: 272, REQ, PXY > 444 < Session-Id > 445 { Origin-Host } 446 { Origin-Realm } 447 { Destination-Realm } 448 { Auth-Application-Id } 449 { CC-Request-Type } 450 { CC-Request-Number } 451 [ Destination-Host ] 452 [ User-Name ] 454 [ CC-Sub-Session-Id ] 455 [ Acct-Multi-Session-Id ] 456 [ Origin-State-Id ] 457 [ Event-Timestamp ] 458 [ Subscription-Id ] 459 [ Service-Identifier ] 460 [ Termination-Cause ] 461 *[ Requested-Service-Unit ] 462 [ Requested-Action ] 463 *[ Used-Service-Unit ] 464 *[ Service-Parameter-Info ] 465 *[ CC-Correlation-Id ] 466 *[ Proxy-Info ] 467 [ Redirect-Host AVP ] 468 [ Redirect-Host-Usage AVP ] 469 [ Redirect-Max-Cache-Time AVP ] 470 *[ Route-Record ] 471 *[ AVP ] 473 3.2 Credit-Control-Answer (CCA) Command 475 The Credit-Control-Answer message (CCA), indicated by the command-code 476 field set to 272 and the 'R' bit cleared in the Command Flags field, 477 is used between the credit-control server and the Diameter credit- 478 control client to acknowledge a Credit-Control-Request command. 480 Message Format 482 ::= < Diameter Header: 272, PXY > 483 < Session-Id > 484 { Result-Code } 485 { Origin-Host } 486 { Origin-Realm } 487 { Auth-Application-Id } 488 { CC-Request-Type } 489 { CC-Request-Number } 490 [ User-Name ] 491 [ CC-Session-Failover ] 492 [ CC-Sub-Session-Id ] 493 [ Acct-Multi-Session-Id ] 494 [ Origin-State-Id ] 495 [ Event-Timestamp ] 496 [ Subscription-Id ] 497 *[ Granted-Service-Unit ] 498 [ Cost-Information] 499 [ Final-Unit-Indication ] 500 [ Check-Balance-Result ] 501 [ Credit-Control-Failure-Handling ] 502 [ Direct-Debiting-Failure-Handling ] 504 [ Validity-Time] 505 *[ Proxy-Info ] 506 *[ Route-Record ] 507 *[ AVP ] 509 4. Credit Control Application Overview 511 The credit authorization process takes place before and during service 512 delivery to the end user, it generally requires user's authentication 513 and authorization before any request is sent to the credit-control 514 server. 516 The credit control application defined in this specification supports 517 for two different credit authorization models: credit authorization 518 with money reservation and credit authorization with direct debiting. 519 In both the models, the credit control client requests credit 520 authorization to the credit control server prior to allow any service 521 to be delivered to the end user. 523 In the first model, the credit control server rates the request, 524 reserve a suitable amount of money from the user's account and return 525 the corresponding amount of credit resources. Note that credit 526 resources may not imply actual monetary credit; credit resources may 527 be granted to the credit control client in form of units (e.g. data 528 volume or time) to be metered. 530 Upon reception of a successful credit authorization answer with a 531 certain amount of credit resources, the credit control client allows 532 service delivery to the end user and start monitoring the usage of the 533 granted resources. When the credit resources granted to the user have 534 been consumed, or the service has been successfully delivered or 535 terminated, the credit control client reports back to the server the 536 used amount. The credit control server deducts the used amount from 537 the end user's account; it may perform rating and make a new credit 538 reservation if the service delivery is continuing. This process is 539 accomplished with session based credit control that includes the first 540 interrogation, possible intermediate interrogations and the final 541 interrogation. For session based credit control, both the credit 542 control client and the credit control server are required to maintain 543 credit control session state. 545 In contrast, credit authorization with direct debiting is a single 546 transaction process where the credit control server directly deducts 547 the suitable amount of money from the user's account as soon as the 548 credit authorization request is received. Upon reception of a 549 successful credit authorization answer, the credit control client 550 allows service delivery to the end user. This process is accomplished 551 with the one time event. Session state is not maintained. 553 In a multi-service environment, an end user may issue an additional 554 service request (e.g. data service) during an ongoing service (e.g. 555 voice call) towards the same account; or during an active multimedia 556 session an additional media type is added to the session causing a new 557 simultaneous request towards same account. Consequently this needs to 558 be considered when credit resources are granted to the services. 560 The credit control application also support for operations such as 561 service price enquiry, user's balance check and refund of credit on 562 the user's account. These operations are accomplished with the one 563 time event. Session state is not maintained. 565 A flexible Credit control application specific failure handling is 566 defined where the home service provider can model the credit control 567 client behavior according to own credit risk management policy. 568 The Credit-Control-Failure-Handling AVP and the Direct-Debiting- 569 Failure-Handling AVP are defined to determine what to do if the 570 sending of credit-control messages to the credit-control server has 571 been temporarily prevented. The usage of Credit-Control-Failure- 572 Handling AVP and the Direct-Debiting-Failure- Handling AVP gives 573 flexibility to have different failure handling for credit-control 574 session and one time event direct debiting. 576 4.1 Service-Specific Rating Input and Interoperability 578 The Diameter Credit Control Application defines the framework for 579 credit control, it provides generic credit control mechanisms 580 supporting multiple service applications. The Credit Control 581 Application, therefore, does not define AVPs that could be used as 582 input in the rating process. Listing the possible services that could 583 use this Diameter application is seen as out of scope for this generic 584 mechanisms as well. 586 It is reasonable to expect that there will exist a service level 587 agreement between providers of the credit control client and the 588 credit control server covering the charging, services offered, roaming 589 agreements, agreed rating input, etc. 591 There are two ways for providing rating input to the credit control 592 server, either by using AVPs or by including them in the Service- 593 Parameter-Info AVP. The general principle for sending rating 594 parameters is that the service SHOULD re-use existing AVPs, if the 595 service can use AVPs defined in existing service specific Diameter 596 applications (e.g. NASREQ for network access services). 597 Alternatively, new AVPs can be defined if the existing AVPs do not 598 provide sufficient rating information. The Service-Parameter-Info AVP 599 MAY be used as a container to pass legacy rating information in its 600 original encoded form (e.g. ASN.1 BER). In that case the rating input 601 is embedded in the Service-Parameter-Info AVP as defined in section 602 8.23. New service applications SHOULD favor the use of explicitly 603 defined AVPs, to simplify interoperability. 605 The service specific rating input AVPs, the contents of the Service- 606 Parameter-Info AVP or Service-Identifier AVP are not within the scope 607 of this document. To facilitate interoperability, it is RECOMMENDED 608 that the rating input and values of service identifiers are 609 coordinated via an informational RFC or other permanent and readily 610 available reference such as the specification of another cooperative 611 standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. 612 However, private services may be deployed that are subject to 613 agreements between providers of the credit control server and client, 614 in this case vendor specific AVPs can be used. 616 This specification, together with service specific documents, is 617 governing the credit control message. The rule is that service 618 specific documents only define what existing AVPs or new AVPs are used 619 as input to the rating process (i.e. they do not define new credit 620 control applications), and thus need to be included in the Credit- 621 Control-Request command by a Diameter Credit Control Client supporting 622 a given service as *[AVP]. In order to define new AVPs, service 623 specific documents MUST follow the practices defined in 624 [DIAMBASE]. The service SHOULD be identified using the Service- 625 Identifier AVP at command level. The Service-Identifier AVP SHOULD be 626 a unique identifier for a given service as defined in section 8.40. 627 As a result it is the combination of support of the Diameter Credit 628 Control Application (DCC) and the service defined in the Service- 629 Identifier AVP, which defines interoperability between any given DCC 630 client and server. 632 Diameter credit control implementations are required to support the 633 Mandatory rating AVPs defined in service specific documentation of the 634 services they support. Introducing new credit control mechanisms not 635 defined in this specification implies the definition of a new version 636 of the Diameter Credit Control Application and corresponding 637 Application Identifier. 639 In case a rating input required for the rating process is missing from 640 the Credit control request, or the credit control server does not 641 support the requested service (i.e. does not support one or more 642 Mandatory rating AVPs included in the request command), the Credit 643 control answer MUST contain error code DIAMETER_RATING_FAILED. A CCR 644 message with this error MUST contain one or more Failed-AVP AVPs 645 containing the missing and/or unsupported AVPs that caused the 646 failure. A Diameter credit control client receiving error code 647 DIAMETER_RATING_FAILED in answer to a request MUST NOT send such 648 similar requests in the future. 650 5. Session Based Credit-control 652 For a session-based credit-control, several interrogations are needed: 653 the first, intermediate (optional) and the final interrogation. This 654 is illustrated in Figure 3 and Figure 4. 656 If the credit-control client performs credit-reservation before 657 granting service to the end user it MUST use several interrogations 658 towards the credit-control server (i.e. session based credit-control). 659 In this case the credit-control server MUST maintain the credit 660 control session state. 662 Each credit-control session MUST have globally unique Session-Id as 663 defined in [DIAMBASE] and it MUST NOT be changed during the lifetime 664 of a credit-control session. 666 There are certain applications that require multiple credit control 667 sub-sessions. Such applications would send messages with a constant 668 Session-Id AVP, but a different CC-Sub-Session-Id AVP. If several 669 credit sub-sessions will be used, all sub-sessions MUST be closed 670 separately before the closing the main session to be able to report 671 used units per sub-session. The absence of this AVP implies no sub- 672 sessions are in use. 674 When multiple services are used within one user session and each 675 service or group of services are subject to different cost, making use 676 of credit control sub-sessions will result in increased signaling load 677 and resources usage in both the credit control client and the credit 678 control server. For instance, during one network access session the 679 end user may use several http-services subject to different access 680 cost. To optimally support these scenarios, the credit control 681 application enables for multiple services credit control in a single 682 credit control session. It is possible to request and allocate 683 multiple quotas as a credit pool that is shared between multiple 684 services. The services can be further grouped into rating groups in 685 order to achieve even further aggregation of credit allocation. It is 686 also possible to request and allocate multiple quotas on a per service 687 basis. The mechanism is illustrated in Appendix A (Flow X). 689 It should be noted that the service element might send a service 690 specific re-authorization message to the Diameter AAA server due to 691 expiration of the authorization-lifetime during an ongoing credit 692 control session. However, the service specific re-authorization does 693 not influence the credit authorization that is ongoing between credit- 694 control client and credit-control server since credit authorization is 695 controlled by the burning rate of the granted quota. 696 In the event that service specific re-authorization fails the user 697 will be disconnected and the credit-control client MUST send a final 698 interrogation to the credit-control server. 700 The Diameter credit-control server may want to control the validity 701 time of the granted quota and/or the production of intermediate 702 interrogations, thus it MAY include the Validity-Time AVP in the 703 answer message to the credit-control client. Upon expiration of the 704 Validity-Time, the credit-control client MUST generate a credit- 705 control update request and report the used quota to the credit-control 706 server. It is up to the credit-control server to determine, the value 707 of the Validity-Time to be used for consumption of the granted service 708 units. If the Validity-Time is used, its value SHOULD be given as 709 input to set the session supervision timer Tcc (the session 710 supervision timer MAY be set to two times the value of the Validity- 711 Time as defined in section 13). Since credit-control update requests 712 are also produced at the expiry of granted service units and/or for 713 mid-session service events the omission of Validity-Time does not mean 714 that intermediate interrogation for the purpose of credit control are 715 not performed. 717 The Diameter credit-control server and client may optionally support a 718 tariff change mechanism. The Diameter credit-control server may 719 include a Tariff-Time-Change AVP in the answer message. Note that the 720 granted units should be allocated based on the worst-case scenario in 721 case of forthcoming tariff change, so that the overall reported used 722 units would never exceed the credit reservation. 723 When the Diameter credit-control client reports the used units and a 724 tariff change has occurred during the reporting period then the 725 Diameter credit-control client SHOULD itemize the units used before 726 and after the tariff change. In case some units straddled the tariff 727 change, the credit-control client SHOULD itemize those units as well. 729 5.1 First Interrogation 731 When session based credit-control is required (e.g. the authentication 732 server indicated prepaid user), the first interrogation MUST be sent 733 before the Diameter credit-control client allows any service event to 734 the end user. The CC-Request-Type is set to the value INITIAL_REQUEST 735 in the request message. 737 If the Diameter credit-control client knows the cost of the service 738 event (e.g. a content server delivering ringing tones may know their 739 cost) the monetary amount to be charged is included in the Requested- 740 Service-Unit AVP. If the Diameter credit-control client does not know 741 the cost of the service event, the Requested-Service-Unit AVP MAY 742 contain the number of requested service events and the Service- 743 Parameter-Info AVP MAY contain the service event information to be 744 rated by the credit-control server. The Service-Parameter-Info AVP 745 always refers to the requested service units. Alternatively, service 746 event information to be rated can be sent as service specific AVPs. 748 The Event-Timestamp AVP contains the time when the service event is 749 requested in the service element. 751 The credit-control server SHOULD rate the service event and make a 752 credit-reservation from the end user's account that covers the cost of 753 the service event. If the type of the Requested-Service-Unit AVP is 754 money, no rating is needed but the corresponding monetary amount is 755 reserved from end user's account. 757 The credit-control server returns the Granted-Service-Unit AVP in the 758 Answer message to the Diameter credit-control client. The Granted- 759 Service-Unit AVP contains the amount of service units that the 760 Diameter credit-control client can provide to the end user until a new 761 Credit-Control-Request MUST be sent to the credit-control server. If 762 several unit types are sent in the Answer message the credit-control 763 client MUST handle each unit type separately. There MUST be maximum 764 one instance of the same unit type in one Answer message. In case 765 multiple quotas are conveyed to the credit control client, there MUST 766 be maximum one instance of the same unit type associated to a Service- 767 Identifier, or set of Service-Identifiers, or associated to a Rating- 768 Group. The type of the Granted-Service-Unit AVP can be time, volume, 769 service specific or money depending on the type of service event. It 770 is not allowed to change the unit type(s) within the session. 772 If the credit-control server determines that no further control is 773 needed for the service it MAY include the result code indicating that 774 the credit-control is not applicable (e.g. service is free of charge) 775 and terminate the credit-control session. 777 The Credit-Control-Answer message MAY also include the Final-Unit- 778 Indication AVP to indicate that the answer message contains the final 779 units for the service session. After the end user has consumed these 780 units, the Diameter credit-control-client MUST behave as described in 781 section 5.5. 783 Two different approaches are defined for the first interrogation to 784 suit properly in all the possible architectures. The first approach 785 uses credit-control messages after user's authorization and 786 authentication took place. The second approach uses service specific 787 authorization messages to perform the first interrogation during the 788 user's authorization/authentication phase, and credit-control messages 789 for the intermediate and the final interrogations. 790 In case an implementation of the credit-control client supports both 791 the methods, it SHOULD be configurable what method to use. 793 In service environments such as the Network Access Server (NAS) , it 794 is desired to perform the first interrogation as part of the 795 authorization/authentication process for the sake of protocol 796 efficiency. Further credit authorizations after the first 797 interrogation took place are performed with credit control commands 798 defined in this specification. Implementations of credit-control 799 client operating in the mentioned environments SHOULD support this 800 method. In case the credit-control server and AAA server are separate 801 physical entities the service element send the request messages to the 802 AAA server, which then issue an appropriate request or proxy the 803 received request forward to the credit-control server. 805 In other service environments, such as the 3GPP network and some SIP 806 scenario, there is a substantial decoupling between 807 registration/access to the network and the actual service request 808 (i.e. the authentication/authorization is executed once at 809 registration/access to the network and is not executed for every 810 service event requested by the subscriber). In such environments it is 811 more appropriate to perform the first interrogation after the user has 812 been authenticated and authorized. The first interrogation, the 813 intermediate and final interrogations are executed with credit control 814 commands defined in this specification. 816 Other IETF standards or standards developed by other standardization 817 bodies may define what is the most suitable method in their 818 architecture. 820 5.1.1 First Interrogation after Authorization and Authentication 822 The Diameter credit-control client in the service element may get 823 information from the authorization server whether credit-control is 824 required based on its knowledge of the end user. If credit-control is 825 required the credit-control server needs to be contacted prior to 826 initiate the service delivery to the end user. The accounting protocol 827 and the credit-control protocol can be used in parallel, the 828 authorization server may also drive whether the parallel accounting 829 stream is required. 831 The following diagram illustrates the case where both protocols are 832 used in parallel and the service element sends credit-control messages 833 directly to the credit-control server. More credit-control sequence 834 examples are given in Annex A. 836 End-User Service Element AAA Server CC Server 837 (CC Client) 838 | Registration | AA request/answer(accounting,cc or both)| 839 |<----------------->|<------------------>| | 840 | : | | | 841 | : | | | 842 | Service Request | | | 843 |------------------>| | | 844 | | CCR(Initial,Credit-Control AVPs) | 845 | +|---------------------------------------->| 846 | CC stream|| | CCA(Granted-Units)| 847 | +|<----------------------------------------| 848 | Service Delivery | | | 849 |<----------------->| ACR(start,Accounting AVPs) | 850 | : |------------------->|+ | 851 | : | ACA || Accounting stream | 852 | |<-------------------|+ | 853 | : | | | 854 | : | | | 855 | | CCR(Update,Used-Units) | 856 | |---------------------------------------->| 857 | | | CCA(Granted-Units)| 858 | |<----------------------------------------| 859 | : | | | 860 | : | | | 861 | End of Service | | | 862 |------------------>| CCR(Termination, Used-Units) | 863 | |---------------------------------------->| 864 | | | CCA | 865 | |<----------------------------------------| 866 | | ACR(stop) | | 867 | |------------------->| | 868 | | ACA | | 869 | |<-------------------| | 871 Figure 3: Protocol example with first interrogation after user's 872 authorization/authentication 874 5.1.2 Authorization Messages for First Interrogation 876 The Diameter credit-control client in the service element MUST 877 actively contribute with the authorization/authentication client in 878 the construction of the AA request by adding appropriate credit 879 control AVPs. The credit-control client MUST add the Credit-Control 880 AVP to indicate credit-control capabilities and MAY add other relevant 881 credit-control specific AVPs to the proper 882 authorization/authentication command to perform the first 883 interrogation towards the home Diameter AAA server. The Auth- 884 Application-Id is set to the appropriate value as defined in the 885 relevant service specific authorization/authentication application 886 document (e.g. [NASREQ], [DiamMIP]). The home Diameter AAA server 887 authenticate/authorize the subscriber and determine whether or not 888 credit-control is required. 890 If credit-control is not required for the subscriber the home AAA 891 will respond as usual with an appropriate AA answer message. If 892 credit-control is required for the subscriber and the Credit-Control 893 AVP with the value set to CREDIT_AUTHORIZATION was present in the 894 authorization request, the home AAA server MUST contact the credit- 895 control server to perform the first interrogation. If credit-control 896 is required for the subscriber and the Credit-Control AVP was not 897 present in the authorization request, the home AAA server MUST send an 898 authorization reject answer message. 900 The Diameter AAA server supporting credit-control is required to send 901 the Credit-Control-Request command (CCR) defined in this document to 902 the credit-control server. The Diameter AAA server populates the CCR 903 based on service specific AVPs used for input to the rating process 904 and possibly credit-control AVPs received in the AA request. The 905 credit-control server will make money reservation from the user's 906 account, will rate the request and will send a credit-control answer 907 message to the home Diameter AAA server. The answer message includes 908 the Granted-Service-Unit AVP(s) and MAY include other credit-control 909 specific AVPs as appropriate. Additionally, the credit-control server 910 MAY set the Validity-Time and MAY include the Credit-Control-Failure- 911 Handling AVP and the Direct-Debiting-Failure-Handling AVP to determine 912 what to do if the sending of credit-control messages to the credit- 913 control server has been temporarily prevented. 915 Upon receiving the credit-control answer message from the credit- 916 control server, the home Diameter AAA server will populate the AA 917 answer with the received credit-control AVPs and with usual service 918 attributes according to the authorization/authentication specific 919 application (e.g. [NASREQ], [DiamMIP]) and forward the packet to the 920 credit-control client. If the home AAA server receives a credit- 921 control reject message, it will simply generate an appropriate 922 authorization reject message to the credit-control client including 923 the credit-control specific error code. 925 The credit-control client in this model sends further credit-control 926 messages to the credit-control server via the home AAA server. 927 Upon receiving successful authorization answer message with the 928 Granted-Service-Unit AVP(s), the credit-control client will grant the 929 service to the end user and will generate intermediate credit-control 930 request as required by using Credit-Control commands. The CC-Request- 931 Number of the first intermediate request MUST be set to 1 (for how to 932 produce unique value for the CC-Request-Number AVP see section 8.2). 934 If service specific re-authorization is performed (i.e. authorization- 935 lifetime expires), the credit-control client MUST add to the service 936 specific re-authorization request the Credit-Control AVP with value 937 set to RE-AUTHORIZATION to indicate that the credit-control server 938 MUST NOT be contacted. When session based credit-control is used for 939 the subscriber a constant Credit-Control messages stream is flowing 940 through the Diameter AAA server. The Diameter AAA server can make use 941 of this credit-control messages flow to deduce that user's activity is 942 ongoing; hence it is recommended to set the authorization-lifetime to 943 a reasonably high value when credit-control is used for the 944 subscriber. 946 In this scenario the home AAA server MUST advertise support for the 947 credit-control application to its peers during the capability exchange 948 process. 950 The following diagram illustrates the use of authorization / 951 authentication messages to perform the first interrogation. The 952 parallel accounting stream is not shown in the figure. 954 End-User Service Element AAA Server CC Server 955 (CC Client) 956 | Service Request | AA Request (CC AVPs) | 957 |------------------>|------------------->| | 958 | | | CCR(Initial, CC AVPs) 959 | | |------------------->| 960 | | | CCA(Granted-Units) 961 | | |<-------------------| 962 | | AA Answer(Granted-Units) | 963 | Service Delivery |<-------------------| | 964 |<----------------->| | | 965 | : | | | 966 | : | | | 967 | : | | | 968 | | | | 969 | | CCR(Update,Used-Units) | 970 | |------------------->| CCR(Update,Used-Units) 971 | | |------------------->| 972 | | | CCA(Granted-Units)| 973 | | CCA(Granted-Units)|<-------------------| 974 | |<-------------------| | 975 | : | | | 976 | : | | | 977 | End of Service | | | 978 |------------------>| CCR(Termination,Used-Units) | 979 | |------------------->| CCR(Term.,Used-Units) 980 | | |------------------->| 981 | | | CCA | 982 | | CCA |<-------------------| 983 | |<-------------------| | 985 Figure 4: Protocol example with use of the 986 authorization messages for the first interrogation. 988 5.2 Intermediate Interrogation 989 When all of the granted service units for one unit type are spent by 990 the end user or the Validity-Time is expired, the Diameter credit- 991 control client MUST send a new Credit-Control-Request to the credit- 992 control server. In the event that credit control for multiple services 993 in one credit control session is applied (i.e. units are granted 994 associated to Service-Identifier(s) or Rating-Group), a new Credit- 995 Control-Request MUST be sent to the credit-control server when the 996 whole credit reservation has been consumed, or upon expiration of the 997 Validity-Time. In the case when the Validity-Time is used, it is 998 always up to the Diameter credit-control client to send a new request 999 well in advance before the expiration of the previous request in order 1000 to avoiding interruption in the service element. Even if the granted 1001 service units reserved by the credit-control server have not been 1002 spent upon expiration of the Validity-Time, the Diameter credit- 1003 control client MUST send a new Credit-Control-Request to the credit- 1004 control server. 1006 There can be also mid-session service events, which might affect the 1007 rating of the current service events. In this case a spontaneous 1008 updating (a new Credit-Control-Request) SHOULD be sent including 1009 information related to the service event even if all the granted 1010 service units have not been spent or the Validity-Time has not 1011 expired. 1013 When the used units are reported to the credit-control server the 1014 credit-control client will not have any units in its possession before 1015 new granted units are received from the credit-control server. When 1016 the new granted units are received from the credit-control server 1017 these units apply from the point where the measurement of the reported 1018 used units stopped. 1020 The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the 1021 intermediate request message. The Subscription-Id-Data AVP SHOULD be 1022 included in the intermediate message to identify the end user in the 1023 credit-control server. 1025 The Requested-Service-Unit AVP contains the new amount of requested 1026 service units. The Used-Service-Unit AVP contains the amount of used 1027 service units measured from the point when the service became active 1028 or, in case of interim interrogations are used during the session, 1029 from the point when the previous measurement ended. The same unit 1030 types that are used in the previous message MUST be used. If several 1031 unit types were included in the previous answer message the used 1032 service units for each unit type MUST be reported. 1034 The Event-Timestamp AVP contains the time of the event that triggered 1035 the sending of the new Credit-Control-Request. 1037 The credit-control server MUST deduct the used amount from the end 1038 user's account. It MAY rate the new request and make a new credit- 1039 reservation from the end user's account that covers the cost of the 1040 requested service event. 1042 The Credit-Control-Answer message with the CC-Request-Type AVP set to 1043 the value UPDATE_REQUEST MAY include the Cost-Information AVP 1044 containing the accumulated cost estimation for the session without 1045 taking any credit-reservation into account. 1047 The Credit-Control-Answer message MAY also include the Final-Unit- 1048 Indication AVP to indicate that the answer message contains the final 1049 units for the service session. After the end user has consumed these 1050 units, the Diameter credit-control-client MUST behave as described in 1051 section 5.5. 1053 There can be several intermediate interrogations within a session. 1055 5.3 Final Interrogation 1057 When the end user terminates the service session or according to the 1058 graceful service termination as described in section 5.5, the Diameter 1059 credit-control client MUST send a final Credit-Control-Request message 1060 to the credit-control server. The CC-Request-Type AVP is set to the 1061 value TERMINATION_REQUEST. 1063 The Event-Timestamp AVP MAY contain the time of the session was 1064 terminated. 1066 The Used-Service-Unit AVP contains the amount of used service units 1067 measured from the point when the service became active or, in case of 1068 interim interrogations are used during the session, from the point 1069 when the previous measurement ended. If several unit types were 1070 included in the previous answer message the used service units for 1071 each unit type MUST be reported. 1073 After final interrogation the credit-control server MUST refund the 1074 reserved credit amount not used to the end user's account and deduct 1075 the used monetary amount from the end user's account. 1077 The Credit-Control-Answer message with the CC-Request-Type set to the 1078 value TERMINATION_REQUEST MAY include the Cost-Information AVP 1079 containing the estimated total cost for the session in question. 1081 If the user logoff during an ongoing credit-control session or some 1082 other reason causes the user to be logged-off (e.g. final-unit 1083 indication causes user logoff according to local policy) the service 1084 element, according to application specific policy, may send a session- 1085 termination-request (STR) to the home Diameter AAA server as usual 1087 [DIAMBASE]. Figure 5 illustrates the case when the final-unit 1088 indication causes the user logoff upon consumption of the final 1089 granted units and STR is generated. 1091 End-User Service Element AAA Server CC Server 1092 (CC Client) 1093 | Service Delivery | | | 1094 |<----------------->| | | 1095 | : | | | 1096 | : | | | 1097 | : | | | 1098 | | | | 1099 | | CCR(Update,Used-Units) | 1100 | |------------------->| CCR(Update,Used-Units) 1101 | | |------------------->| 1102 | | CCA(Final-Unit, Terminate) 1103 | CCA(Final-Unit, Terminate)|<-------------------| 1104 | |<-------------------| | 1105 | : | | | 1106 | : | | | 1107 | Disconnect user | | | 1108 |<------------------| CCR(Termination,Used-Units) | 1109 | |------------------->| CCR(Term.,Used-Units) 1110 | | |------------------->| 1111 | | | CCA | 1112 | | CCA |<-------------------| 1113 | |<-------------------| | 1114 | | STR | | 1115 | |------------------->| | 1116 | | STA | | 1117 | |<-------------------| | 1118 Figure 5: User disconnected due to account exhausted 1120 5.4 Server-Initiated Credit Re-Authorization 1122 The Diameter Credit Control Application supports the server-initiated 1123 re-authorization. The credit control server MAY optionally initiate 1124 the credit re-authorization by issuing a Re-Auth-Request (RAR) as 1125 defined in the Diameter base protocol [DIAMBASE]. The Auth- 1126 Application-Id in the RAR message is set to 4 to indicate the Diameter 1127 Credit Control Application and the Re-Auth-Request-Type is set to 1128 AUTHORIZE_ONLY. 1130 If a credit re-authorization is not already ongoing (i.e. the credit 1131 control session is in OPEN state), a credit control client that 1132 receives such a RAR message with Session-Id equal to a currently 1133 active credit control session acknowledges the request by sending the 1134 Re-Auth-Answer (RAA) message and MUST initiate the credit re- 1135 authorization towards the server by sending a Credit-Control-Request 1136 message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. 1137 The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the 1138 RAA message to indicate an additional message (i.e. CCR[Update]) is 1139 required to complete the procedure. If a quota was allocated to the 1140 session, the credit control client MUST report the used quota in the 1141 Credit-Control-Request. Note that the end user does not need to be 1142 prompted for the credit re-authorization, since the credit re- 1143 authorization is transparent to the user (i.e it takes place 1144 exclusively between the credit control client and the credit control 1145 server). 1147 If credit re-authorization is ongoing at the time when the RAR message 1148 is received (i.e. RAR-CCR collision), the credit control client 1149 successfully acknowledges the request but it does not initiate a new 1150 credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) 1151 SHOULD be used in the RAA message to indicate a credit re- 1152 authorization procedure is already ongoing (i.e. the client was in 1153 PendingU state when the RAR was received). The credit control server 1154 SHOULD process the Credit-Control-Request as if it was received in 1155 answer to the server initiated credit re-authorization, and should 1156 consider the server initiated credit re-authorization process 1157 successful upon reception of the Re-Auth-Answer message. 1159 If several credit control sub-sessions are in use, a credit control 1160 client receiving the RAR command for a given session will trigger 1161 credit re-authorization for all the sub-session separately. 1163 5.5 Graceful Service Termination 1165 When the user's account runs out of money the user must be denied to 1166 compile additional chargeable events. However, the home service 1167 provider may offer free access services, for instance access to a 1168 service portal where it is possible to top-up the account, for which 1169 the user is allowed to benefit for a limited amount of time. This time 1170 is usually dependant on the home service provider policy. 1172 This section defines the graceful service termination optional feature 1173 that MAY be supported by the credit control server. Credit control 1174 client implementations MUST support the Final-Unit-Indication with at 1175 least the tear down of the ongoing service session upon the subscriber 1176 has consumed all the final granted units. 1178 In some service environments (e.g. NAS) the graceful service 1179 termination may be used to redirect the subscriber to a service portal 1180 for online balance top-up or other zero-rated services offered by the 1181 home service provider. In this case the graceful termination process 1182 installs a set of packet filters to restrict the user's access 1183 capability only to/from the specified destinations, all the IP packets 1184 not matching the filters will be dropped or possibly re-directed to 1185 the service portal. The user may also be displayed an appropriate 1186 notification why the access has been limited. 1188 It is also possible use the graceful service termination to connect 1189 the prepaid user to a top-up server that play an announcement and 1190 prompt the user to replenish the account. In such a case the credit 1191 control server sends only the address of the top-up server where the 1192 prepaid user shall be connected after the final granted units have 1193 been consumed. An example of this is given in Appendix A (Flow VIII). 1195 The credit control server MAY initiate the graceful service 1196 termination by including the Final-Unit-Indication AVP in the Credit 1197 Control Answer to indicate that the message contains the final units 1198 for the service session. 1199 When the credit control client receives the Final-Unit-Indication AVP 1200 in the answer from the server its behavior depends on the value 1201 indicated in the Final-Unit-Action AVP. The server may request the 1202 following actions: TERMINATE, REDIRECT and RESTRICT_ACCESS. 1204 The following Figure illustrates the graceful service termination 1205 procedure described in the following sub-sections. 1207 End-User Service Element AAA Server CC Server 1208 (CC Client) 1209 | Service Delivery | | | 1210 |<----------------->| | | 1211 | |CCR(Update,Used-Units) | 1212 | |------------------->|CCR(Update,Used-Units) 1213 | : | |------------------->| 1214 | : | |CCA(Final-Unit,Action) 1215 | : | |<-------------------| 1216 | |CCA(Final-Unit,Action) | 1217 | |<-------------------| | 1218 | | | | 1219 | : | | | 1220 | : | | | 1221 | : | | | 1222 | /////////////// |CCR(Update,Used-Units) | 1223 |/Final Units End/->|------------------->|CCR(Update,Used-Units) 1224 |/Action and // | |------------------->| 1225 |/Restrictions // | | CCA(Validity-Time)| 1226 |/Start // | CCA(Validity-Time)|<-------------------| 1227 | ///////////// |<-------------------| | 1228 | : | | | 1229 | : | | | 1230 | Replenish Account +-------+ | 1231 |<-------------------------------------------->|Account| | 1232 | | | +-------+ | 1233 | | | RAR | 1234 | + | RAR |<===================| 1235 | | |<===================| | 1236 | | | RAA | | 1237 | ///////////// | |===================>| RAA | 1238 | /If supported / | | CCR(Update) |===================>| 1239 | /by CC Server/ | |===================>| CCR(Update) | 1240 | ///////////// | | |===================>| 1241 | | | | CCA(Granted-Unit)| 1242 | | | CCA(Granted-Unit)|<===================| 1243 | Restrictions ->+ |<===================| | 1244 | removed | | | 1245 | : | | | 1246 | OR | CCR(Update) | | 1247 | Validity-Time ->|------------------->| CCR(Update) | 1248 | expires | |------------------->| 1249 | | | CCA(Granted-Unit)| 1250 | | CCA(Granted-Unit)|<-------------------| 1251 | Restrictions ->|<-------------------| | 1252 | removed | | | 1253 Figure 6: Optional graceful service termination procedure 1255 5.5.1 Terminate Action 1257 The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does 1258 not include any other information. Upon the subscriber has consumed 1259 the final granted units the service element MUST terminate the service 1260 session and MUST send a final Credit-Control-Request message to the 1261 credit control server. The CC-Request-Type AVP in the request is set 1262 to the value TERMINATION_REQUEST. This is the default handling 1263 applicable whenever the credit control client receives an unsupported 1264 Final-Unit-Action value and MUST be supported by all the Diameter 1265 credit control client implementations conforming to this 1266 specification. 1268 5.5.2 Redirect Action 1270 The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT 1271 indicates to the service element supporting this action that, upon 1272 consumption of the final granted units, the user MUST be re-directed 1273 to the address specified in the Redirect-Server AVP as follow. 1275 The credit control server sends the Redirect-Server AVP in the Credit- 1276 Control-Answer message. In such a case the service element MUST 1277 redirect or connect the user to the destination specified in the 1278 Redirect-Server AVP, if possible. When the end user is redirected (by 1279 using other protocols than Diameter) to the specified server or 1280 connected to the top-up server, an additional authorization (and 1281 possibly authentication) may be needed before the subscriber can 1282 replenish the account, however, this is out of the scope of this 1283 specification. 1285 In addition to the Redirect-Server AVP, the credit control server MAY 1286 include one or more Restriction-Filter-Rule AVP or one or more Filter- 1287 Id AVP in the Credit-Control-Answer message in order to enable the 1288 user to access other zero-rated services. In such a case the access 1289 device MUST drop all the packets not matching the IP filters specified 1290 in the Credit-Control-Answer message and redirect the user to the 1291 destination specified in the Redirect-Server AVP, if possible. 1293 Another entity than the credit control server may provision the access 1294 device with appropriate IP packet filters to be used in conjunction 1295 with the Diameter credit control application. This case is considered 1296 in section 5.5.3. 1298 When the final granted units have been consumed the credit control 1299 client MUST perform an intermediate interrogation. The purpose of this 1300 intermediate interrogation is to indicate to the credit control server 1301 that the specified action started and to report the used units. The 1302 credit control server MUST deduct the used amount from the end user's 1303 account but MUST NOT make a new credit reservation. The credit control 1304 client, however, may send intermediate interrogations before all the 1305 final granted units have been consumed for which rating and money 1306 reservation may be needed, for instance upon Validity-Time expires or 1307 upon mid-session service event that affect the rating of the current 1308 service. Therefore, the credit control client MUST NOT include any 1309 rating related AVP in the request sent upon all the final granted 1310 units have been consumed as a hint to the server that the requested 1311 final unit action started, rating and money reservation are not 1312 required. Naturally, the Credit-Control-Answer message does not 1313 contain any granted service unit and MUST include the Validity-Time 1314 AVP to indicate to the credit control client how long the subscriber 1315 is allowed to use network resources before a new intermediate 1316 interrogation is sent to the server. 1318 At the expiry of Validity-Time the credit control client sends a 1319 Credit-Control-Request (UPDATE_REQUEST) as usual. This message does 1320 not include the Used-Service-Unit AVP since there is no allotted quota 1321 to report. The credit control server processes the request and MUST 1322 perform the credit reservation. If during this time the subscriber did 1323 not replenish his/her account whether he/she will be disconnected or 1324 will be granted access to zero-rated services for unlimited time is 1325 dependent on the home service provider policy (note: the latter option 1326 implies that the service element should not remove the restriction 1327 filters upon termination of the credit control session). The server 1328 will return the appropriate Result-Code (see section 9.1) in the 1329 Credit-Control-Answer message in order to close the credit control 1330 session and implement the policy-defined action. Otherwise new quota 1331 will be returned, the service element MUST remove all the possible 1332 restrictions activated by the graceful service termination process and 1333 continue the credit control session and the service session as usual. 1335 The credit control client may not wait until the expiration of the 1336 Validity-Time and may send a spontaneous updating (a new Credit- 1337 Control-Request) if the service element can determine for instance 1338 that communication between the end user and the top-up server took 1339 place. An example of this is given in Appendix A (Figure A.8). 1341 It is worth noting that the credit control server may initiate the 1342 above-described process already for the first interrogation. However, 1343 the user's account might be empty at the time when the first 1344 interrogation is performed. In this case the subscriber can be offered 1345 a chance to replenish the account and continue the service. The credit 1346 control client receives a Credit-Control-Answer or service specific 1347 authorization answer with the Final-Unit-Indication AVP, Validity-Time 1348 AVP but no Granted-Unit. In such a case it starts immediately the 1349 graceful service termination without sending any message to the 1350 server. An example of this case is illustrated in Appendix A. 1352 5.5.3 Restrict Access Action 1354 The Final-Unit-Indication AVP with Final-Unit-Action RESTRICT_ACCESS 1355 indicates to the access device supporting this action that the user 1356 MUST be restricted access according to the IP packet filters given in 1357 the Restriction-Filter-Rule AVP(s) or according to the IP packet 1358 filters identified by the Filter-Id AVP(s). The credit control server 1359 SHOULD include either the Restriction-Filter-Rule AVP or the Filter-Id 1360 AVP in the Credit-Control-Answer message. 1362 Another entity than the credit control server may provision the access 1363 device with appropriate IP packet filters to be used in conjunction 1364 with the Diameter credit control application. Such an entity, for 1365 instance, may configure the access device with "zero-rated" IP flows 1366 that are to be passed when the Diameter credit control application 1367 indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP 1368 packets according to the filter rules possibly received in the Credit- 1369 Control-Answer message in addition to the filter rules possibly 1370 configured by the other entity. However, the action to be taken when 1371 the user's account cannot cover the cost of the requested service is 1372 the responsibility of the credit control server that controls the 1373 prepaid subscriber. 1375 If another entity working in conjunction with the Diameter Credit 1376 control application already provisions the access device with all the 1377 required filter rules for the end user, it is presumably not needed 1378 for the credit control server to send any additional filter. Therefore 1379 it is RECOMMENDED that credit control server implementations 1380 supporting the graceful service termination can be configurable 1381 whether to send the Restriction-Filter-Rule AVP, the Filter-Id AVP or 1382 none of the above. 1384 When the final granted units have been consumed, the credit control 1385 client MUST perform an intermediate interrogation. The credit control 1386 client and the credit control server process this intermediate 1387 interrogation and execute subsequent procedures as specified in the 1388 previous section for the REDIRECT action. 1390 The credit control server may initiate the graceful service 1391 termination with action RESTRICT_ACCESS already for the first 1392 interrogation as specified in the previous section for the REDIRECT 1393 action. 1395 5.5.4 Usage of the Server-Initiated Credit Re-Authorization 1397 Once the subscriber replenishes the account she presumably expects all 1398 the restrictions placed by the graceful termination procedure be 1399 immediately removed and unlimited services' access be resumed. For the 1400 best user experience the credit control server implementation MAY 1401 support the server-initiated credit re-authorization (see section 1402 5.4). In such a case, upon the successful account top-up took place, 1403 the credit control server sends the Re-Auth-Request (RAR) message to 1404 solicit the credit re-authorization. The credit control client 1405 initiates then the credit re-authorization by sending the Credit- 1406 Control-Request message with the CC-Request-Type AVP set to the value 1407 UPDATE_REQUEST. The Used-Service-Unit AVP is not included in the 1408 request since there is no allotted quota to report. The Requested- 1409 Service-Unit AVP MAY be included in the request. After the credit 1410 control client successfully receives the Credit-Control-Answer with 1411 new Granted-Service-Unit all the possible restrictions activated for 1412 the purpose of the graceful service termination MUST be removed in the 1413 service element, the credit control session and the service session 1414 continue as usual. 1416 5.6 Failure Procedures 1418 The Credit-Control-Failure-Handling AVP (CCFH) as described in this 1419 section determines the behavior of the credit control client in fault 1420 situations. The CCFH may be received from the Diameter home AAA 1421 server, from the credit control server or may be locally configured. 1422 The CCFH value received from the home AAA server overrides the locally 1423 configured value and the CCFH value received from the credit control 1424 server in the Credit-Control-Answer message always override any 1425 already existing value. 1427 The authorization server MAY include the Accounting-Realtime-Required 1428 AVP to determine what to do if the sending of accounting records to 1429 the accounting server has been temporarily prevented as defined in 1430 [DIAMBASE]. It is RECOMMENDED that the client complement the credit- 1431 control failure procedures with backup accounting flow towards an 1432 accounting server. Using different combinations of Accounting- 1433 Realtime-Required and Credit-Control-Failure-Handling AVPs different 1434 safety levels can be built. For example by choosing the Credit- 1435 Control-Failure-Handling AVP equal to CONTINUE for the credit control 1436 flow and Accounting-Realtime-Required AVP equal to DELIVER_AND_GRANT 1437 for the accounting flow, the service can be granted to the end user 1438 even if the connection to the credit-control server is down but the 1439 accounting server is able to collect the accounting information, 1440 provided that there is information exchange taking place between the 1441 accounting server and credit-control server. 1443 Since the credit-control application is based on real-time bi- 1444 directional communication between the credit-control client and the 1445 credit-control server, the usage of alternative destinations and the 1446 buffering of messages MAY NOT be sufficient in the event of 1447 communication failures. Since the credit-control server has to 1448 maintain session states, moving the credit-control message stream to a 1449 backup server requires a complex context transfer solution. Whether 1450 the credit-control message stream is moved to a backup credit-control 1451 server during an ongoing credit-control session depends on the value 1452 of the CC-session-Failover AVP. However, failover may occur at any 1453 point in the path between credit-control client and credit-control 1454 server in the event that a transport failure is detected with a peer, 1455 as described in [DIAMBASE]. As a consequence the credit-control server 1456 might receive duplicate messages. These duplicates or out of sequence 1457 messages can be detected in the credit-control server based on the 1458 credit-control server session state machine (section 7), Session-Id 1459 AVP and CC-Request-Number AVP. 1461 If a failure occurs during an ongoing credit-control session, the 1462 credit-control client may move the credit control message stream to an 1463 alternative server if the CC-server indicated FAILOVER_SUPPORTED in 1464 the CC-Session-Failover AVP. A secondary credit control server name, 1465 received from the AAA server or locally configured, can be used as an 1466 address of the backup server. If the CC-Session-Failover AVP is set to 1467 FAILOVER_NOT SUPPORTED the credit control message stream MUST NOT be 1468 moved to backup server. 1470 For new credit control sessions, failover to an alternative credit- 1471 control server SHOULD be performed if possible. For instance, if an 1472 implementation of the credit control client can determine primary 1473 credit control server unavailability it can establish the new credit 1474 control sessions with a possibly available secondary credit control 1475 server. 1477 The AAA client/agent is typically using only a single persistent 1478 transport connection to the AAA agent or server, but it may have 1479 connections to multiple AAA agents or servers and treat them as 1480 primary/secondary or balance load between them. The AAA transport 1481 profile [AAATRANS] defines the application layer watchdog algorithm 1482 that enables failover from a peer that has failed and is controlled by 1483 the timer Twinit. The recommended default value for Twinit is 30 1484 seconds. Since the AAA infrastructure is common to several different 1485 types of AAA applications, tuning the timer Twinit to a lower value in 1486 order to satisfy the requirements of real-time applications, such as 1487 the Diameter Credit Control application, will certainly increase the 1488 probability of premature failover significantly and potentially cause 1489 congestive collapse in heavy loaded networks. For prepaid services, 1490 however, the end user expects an answer from the network in a 1491 reasonable time, thus the Diameter credit control client shall react 1492 faster than the underlying base protocol. Therefore this specification 1493 defines the timer Tx that is used by the credit-control client (as 1494 defined in section 13) to supervise the communication with the credit- 1495 control server. When the timer Tx elapses the credit-control client 1496 takes an action to the end user according to the Credit-Control- 1497 Failure-Handling AVP. 1499 When Tx expires, the Diameter credit control client always terminates 1500 the service if the Credit-Control-Failure-Handling (CCFH) AVP is set 1501 to the value TERMINATE. The credit control session may be moved to an 1502 alternative server only in case a protocol error DIAMETER_TOO_BUSY or 1503 DIAMETER_UNABLE_TO_DELIVER is received before Tx expires, therefore, 1504 the value TERMINATE is not appropriate if proper failover behavior is 1505 desired. 1507 If the Credit-Control-Failure-Handling AVP is set to the value 1508 CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the 1509 end user upon the timer Tx expires. An answer message with granted- 1510 units may arrive later on due to the base protocol transport failover 1511 occurred in the path to the Credit Control Server (Twinit default 1512 value is 3 times more than the Tx recommended value). The credit 1513 control client SHOULD grant the service to the end user, start 1514 monitoring the resource usage and wait for the possible late answer 1515 until the timeout of the request (e.g. 120 seconds). If the request 1516 fails and the CC-Session-Failover AVP is set to FAILOVER_NOT 1517 SUPPORTED, the credit control client terminates or continues the 1518 service depending on the value set in the CCFH and MUST free all the 1519 reserved resources for the credit control session. If a protocol error 1520 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the 1521 request timeout and the CC-Session-Failover AVP is set to FAILOVER 1522 SUPPORTED, the credit control client MAY send the request to a backup 1523 server if possible. If the credit control client receives a successful 1524 answer from the backup server, it continues the credit control session 1525 with such a server. If also the re-transmitted request fails, the 1526 credit control client terminates or continues the service depending on 1527 the value set in the CCFH and MUST free all the reserved resources for 1528 the credit control session. 1530 If a communication failure occurs during the graceful service 1531 termination procedure, the service element SHOULD always terminate the 1532 ongoing service session. 1534 If the credit-control server detects a failure during an ongoing 1535 credit-control session, it will terminate the credit-control session 1536 and return the reserved units back to the end user's account. 1538 The supervision session timer Tcc (as defined in section 13) is used 1539 in the credit-control server to supervise the credit-control session. 1541 In order to support the failover between credit control servers 1542 information transfer about the credit control session and account 1543 state SHOULD take place between the primary and the secondary credit 1544 control server. Implementations supporting the credit control session 1545 failover MUST also ensure proper detection of duplicate or out of 1546 sequence messages. The communication between the servers is regarded 1547 as an implementation issue and is outside of the scope of this 1548 specification. 1550 6. One Time Event 1552 The one-time event is used when there is no need to maintain any state 1553 in the Diameter credit-control server, for example enquiring the price 1554 of the service. The use of one-time event implies that the user has 1555 been authenticated and authorized beforehand. 1557 The one time event can be used when the credit-control client wants to 1558 know the cost of the service event without any credit-reservation or 1559 to check the account balance without any credit-reservation. It can be 1560 used also for refunding service units on the user's account or direct 1561 debiting without any credit-reservation. The one time event is shown 1562 in Figure 7. 1564 End-User Service Element AAA Server CC Server 1565 (CC Client) 1566 | Service Request | | | 1567 |------------------>| | | 1568 | | CCR(Event) | | 1569 | |------------------->| CCR(Event) | 1570 | | |------------------->| 1571 | | | CCA(Granted-Units)| 1572 | | CCA(Granted-Units)|<-------------------| 1573 | Service Delivery |<-------------------| | 1574 |<----------------->| | | 1575 Figure 7: One time event 1577 In environments such as the 3GPP architecture the one time event can 1578 be sent from the service element directly to the credit-control 1579 server. 1581 6.1 Service Price Enquiry 1583 The credit-control client may need to know the price of the service 1584 event. There might exist services offered by application service 1585 providers, whose prices are not known in the credit-control client. 1586 End user might also want to get an estimation of the price of a 1587 service event before requesting it. 1589 A Diameter credit-control client requesting the cost information MUST 1590 set the CC-Request-Type AVP equal to EVENT_REQUEST, include the 1591 Requested-Action AVP set to PRICE_ENQUIRY and set the requested 1592 service event information into the Service-Parameter-Info AVP in the 1593 Credit-Control-Request message. 1595 The credit-control server calculates the cost of the requested service 1596 event, but it does not perform any account balance check or credit- 1597 reservation from the account. 1599 The estimated cost of the requested service event is returned to the 1600 credit-control client in the Cost-Information AVP in the Credit- 1601 Control-Answer message. 1603 6.2 Balance Check 1605 The Diameter credit-control client may need only to verify that the 1606 end user's account balance covers the cost for a certain service 1607 without reserving any units from the account at the time of the 1608 inquiry. This method does not guarantee that there would be credit 1609 left when the Diameter credit-control client requests the debiting of 1610 the account with a separate request. 1612 A Diameter credit-control client requesting the balance check MUST set 1613 the CC-Request-Type AVP equal to EVENT_REQUEST, include Requested- 1614 Action AVP set to CHECK_BALANCE and include the Subscription-Id-Data 1615 to identify the End-User in the credit-control server. 1617 The credit-control server makes the balance check, but it does not do 1618 any credit-reservation from the account. 1620 The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to 1621 the credit-control client in the Check-Balance-Result AVP in the 1622 Credit-Control-Answer message. 1624 6.3 Direct Debiting 1626 There are certain service events for which service execution is always 1627 successful in the service environment. The delay between the service 1628 invocation and the actual service delivery to the end user can be 1629 sufficiently long that the use of the session-based credit-control 1630 would lead to unreasonable long credit-control sessions. In these 1631 cases the Diameter credit-control client can use the one-time event 1632 scenario for direct debiting. The Diameter credit-control client 1633 SHOULD be sure that the requested service event execution would be 1634 successful, when this scenario is used. 1636 The CC-Request-Type is set to the value EVENT_REQUEST and the 1637 Requested-Action AVP set to DIRECT_DEBITING in the Credit-Control- 1638 Request message. The Subscription-Id-Data AVP SHOULD be included to 1639 identify the End-User in the credit-control server. The Event- 1640 Timestamp AVP contains the time when the service event is requested in 1641 the service element. 1643 The Diameter credit-control client can include the monetary amount to 1644 be charged in the Request-Service-Unit AVP, if it knows the cost of 1645 the service event. If the Diameter credit-control client does not know 1646 the cost of the service event, then the Service-Parameter-Info AVP 1647 SHOULD contain the service event information to be rated by the 1648 credit-control server. The Service-Parameter-Info AVP always refers to 1649 the requested service unit. 1651 The credit-control server SHOULD rate the service event and deduct the 1652 corresponding monetary amount from end user's account. If the type of 1653 the Requested-Service-Unit AVP is money, no rating is needed but the 1654 corresponding monetary amount is deducted from the End User's account. 1656 The credit-control server returns the Granted-Service-Unit AVP in the 1657 Answer message to the Diameter credit-control client. The Granted- 1658 Service-Unit AVP contains the amount of service units that the 1659 Diameter credit-control client can provide to the end user. The type 1660 of the Granted-Service-Unit can be time, volume, service specific or 1661 money depending on the type of service event. 1663 If the credit-control server determines that no credit-control is 1664 needed for the service it can include the result code indicating that 1665 the credit-control is not applicable (e.g. service is free of charge). 1667 For informative purposes, the Credit-Control-Answer message MAY also 1668 include the Cost-Information AVP containing the estimated total cost 1669 of the requested service. 1671 6.4 Refund 1673 Some services may refund service units to the end user's account, for 1674 example gaming services. 1676 The credit-control client MUST set CC-Request-Type to the value 1677 EVENT_REQUEST and the Requested-Action AVP to REFUND in the Credit- 1678 Control-Request message. The Subscription-Id-Data AVP SHOULD be 1679 included to identify the End-User in the credit-control server. 1681 The Diameter credit-control client MAY include the monetary amount to 1682 be refunded in the Requested-Service-Unit AVP. If the Diameter credit- 1683 control client does not know the monetary amount to be refunded, then 1684 the Service-Parameter-Info AVP, or other rating AVPs, SHOULD contain 1685 the service event information to be rated by the credit-control 1686 server. 1688 For informative purposes, the Credit-Control-Answer message MAY also 1689 include the Cost-Information AVP containing the estimated monetary 1690 amount of refunded unit. 1692 6.5 Failure Procedure 1694 Failover to an alternative credit-control server is allowed for one 1695 time event since the server is not maintaining session states, for 1696 instance, if the credit control client receives a protocol error 1697 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY it can re-send the 1698 request to an alternative server if possible. There MAY exist protocol 1699 transparent Diameter relays and redirect agents or Diameter credit- 1700 control proxies between credit-control client and credit-control 1701 server. Failover may occur at any point in the path between credit- 1702 control client and credit-control server in the event that a transport 1703 failure is detected with a peer, as described in [DIAMBASE]. Because 1704 there can be duplicate requests for various reasons the credit-control 1705 server is therefore responsible for the real time duplicate detection. 1706 Implementation issues for duplicate detection are discussed in 1707 [DIAMBASE] Appendix C. 1709 When the credit-control client detects a communication failure to the 1710 credit-control server, its behavior depends on the requested action. 1711 The timer Tx (as defined in section 13) is used in the credit-control 1712 client to supervise the communication with the credit-control server. 1714 In case the requested action is PRICE_ENQUIRY or BALANCE_CHECK and 1715 communication failure is detected the credit-control client SHOULD 1716 forward the request messages to an alternative credit-control server, 1717 if possible. The secondary Credit control server name, if received 1718 from the AAA server, can be used as an address of backup server. 1720 If the requested action is DIRECT_DEBITING the Direct-Debiting- 1721 Failure-Handling AVP (DDFH) controls the credit control client 1722 behavior. The DDFH may be received from the Diameter home AAA server 1723 or may be locally configured. The credit control server may also send 1724 the DDFH in any CCA message to be used for direct debiting events 1725 compiled thereafter. The DDFH value received from the home AAA server 1726 overrides the locally configured value and the DDFH value received 1727 from the credit control server in a Credit-Control-Answer message 1728 always override any already existing value. If the DDFH is set to 1729 TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the 1730 service if it can determine, eventually after a possible re- 1731 transmission attempt to an alternative credit control server, from the 1732 result code or error code in the answer message that units have not 1733 been debited. Otherwise the credit-control client SHOULD grant the 1734 service to the end user and store the request in the credit-control 1735 application level non-volatile storage (Note that re-sending the 1736 request at a later time is not a guarantee that the service will be 1737 debited, since the user's account may be empty at the time when the 1738 server successfully processes the request). The credit-control client 1739 MUST mark these request messages as possible duplicate by setting the 1740 T-flag in the command header as described in [DIAMBASE] section 3. If 1741 the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the 1742 service SHOULD be granted even if credit-control messages cannot be 1743 delivered and messages are not buffered. 1744 If the timer Tx expires the credit-control client MUST continue the 1745 service and wait for a possible late answer. If the request timeout 1746 the credit control client re-transmit the request (marked with T-flag) 1747 to a backup credit control server if possible. In the event that also 1748 the re-transmitted request timeout or a temporary error is received in 1749 answer to such a request, the credit control client buffers the 1750 request if the value of the Direct-Debiting-Failure-Handling AVP is 1751 set to TERMINATE_OR_BUFFER. If a failed answer is received for the re- 1752 transmitted request, the credit control client frees all the resources 1753 reserved for the event message and deletes the request regardless the 1754 value of the DDFH. 1756 The Credit-Control-Request with requested action REFUND should always 1757 be stored in the credit-control application level non-volatile storage 1758 in case of temporary failure. The credit-control client MUST mark the 1759 re-transmitted request message as possible duplicate by setting the T- 1760 flag in the command header as described in [DIAMBASE] section 3. 1762 For stored requests, the implementation may choose to limit the number 1763 of re-transmission attempts and define a re-transmission interval. 1765 It should be noted that only one place in the credit-control system 1766 SHOULD be responsible for duplicate detection. If there is only one 1767 credit-control server within the given realm, the credit-control 1768 server may perform duplicate detection. In case when more than one 1769 credit-control servers are serving a given realm, only one entity in 1770 the credit control system should be responsible to ensure that the end 1771 user's account is not debited or credited multiple times for the same 1772 service event. 1774 7. Credit Control Application State Machine 1776 This section defines the credit control application state machine. 1778 The first four state machines are to be observed by credit-control 1779 clients. The first one describes the session-based credit-control when 1780 the first interrogation is executed as part of the 1781 authorization/authentication process. The second one describes the 1782 session-based credit-control when the first interrogation is executed 1783 after the authorization/authentication process. The requirements what 1784 state machine need to be supported are discussed in section 5.1. 1786 The third state machine describes the session-based credit-control for 1787 intermediate and final interrogations. The fourth one describes the 1788 event-based credit-control. These latter state machines are to be 1789 observed by all the implementations that conform to this 1790 specification. 1792 The fifth state machine describes the credit-control session from a 1793 credit-control server perspective. 1795 Any event not listed in the state machines MUST be considered as an 1796 error condition, and a corresponding answer, if applicable, MUST be 1797 returned to the originator of the message. 1799 In the state table, the event 'Failure to send' means that the 1800 Diameter credit-control client is unable to communicate with the 1801 desired destination or with a possibly defined alternative destination 1802 in case failover procedure is supported (e.g. the request timeout and 1803 the answer message is not received). This could be due to the peer 1804 being down, or due to a physical link failure in the path to/from the 1805 credit-control server. 1807 The event 'Temporary error' means that the Diameter credit-control 1808 client received a protocol error notification DIAMETER_TOO_BUSY, 1809 DIAMETER_UNABLE_TO_DELIVER or DIAMETER_LOOP_DETECTED in the Result- 1810 Code AVP of the Credit-Control-Answer command. The above protocol 1811 error notification may be ultimately received in answer to the re- 1812 transmitted request to a possibly defined alternative destination if 1813 failover is supported. 1815 The event 'Failed answer' means that the Diameter credit-control 1816 client received non-transient failure (permanent failure) notification 1817 in the Credit-Control-Answer command. The above permanent failure 1818 notification may be ultimately received in answer to the re- 1819 transmitted request to a possibly defined alternative destination if 1820 failover is supported. 1821 The action 'store request' means that a request is stored in the 1822 credit-control application level non-volatile storage. 1824 The event 'Not successfully processed' means that the credit-control 1825 server could not process the message, e.g. due to unknown end user, 1826 account being empty or due to errors defined in [DIAMBASE]. 1828 The states PendingI, PendingU, PendingT PendingE and PendingB stand 1829 for pending states to wait for an answer to a credit control request 1830 related to Initial, Update, Termination, Event or Buffered request 1831 respectively. 1833 The abbreviations CCFH and DDFH stand for Credit-Control-Failure- 1834 Handling and Direct-Debiting-Failure-Handling respectively. 1836 In the following state machine table the failover to a possibly 1837 secondary server upon 'Temporary error' or 'Failure to send' is not 1838 explicitly described. Moving an ongoing credit control message stream 1839 to an alternative server is, however, possible if the CC-Session- 1840 Failover AVP is set to FAILOVER_SUPPORTED as described in section 5.6. 1842 Re-sending a credit control event to an alternative server is 1843 supported as described in section 6.5. 1845 CLIENT, SESSION BASED for the first interrogation with AA request 1847 State Event Action New State 1848 --------------------------------------------------------------- 1849 Idle Client or device requests Send PendingI 1850 access/service AA request 1851 with added 1852 CC AVPs, 1853 start Tx 1855 PendingI Successful AA req. Grant Open 1856 answer received service to 1857 end user, 1858 stop Tx 1860 PendingI Tx expired Disconnect Idle 1861 user/dev 1863 PendingI Failed AA answer received Disconnect Idle 1864 user/dev 1866 PendingI AA answer Grant Idle 1867 received with result code service 1868 equal to credit-control N/A to end user 1870 PendingI User service terminated Queue PendingI 1871 termination 1872 event 1874 PendingI Change in rating condition Queue PendingI 1875 changed 1876 rating 1877 condition 1878 event 1880 CLIENT, SESSION BASED for the first interrogation with CCR 1882 State Event Action New State 1883 ---------------------------------------------------------------- 1885 Idle Client or device requests Send PendingI 1886 access/service CC initial 1887 req., 1888 start Tx. 1890 PendingI Successful CC initial Stop Tx Open 1891 answer received 1893 PendingI Failure to send, or Grant Idle 1894 temporary error and service to 1895 CCFH equal to CONTINUE end user 1897 PendingI Failure to send, or Terminate Idle 1898 temporary error and end user's 1899 CCFH equal to TERMINATE service 1900 or equal to RETRY_AND_TERMINATE 1902 PendingI Tx expired and CCFH Terminate Idle 1903 equal to TERMINATE end user's 1904 service 1906 PendingI Tx expired and CCFH equal Grant PendingI 1907 to CONTINUE or equal to service to 1908 RETRY_AND_TERMINATE end user 1910 PendingI CC initial answer Terminate Idle 1911 received with result code end user's 1912 SERVICE_ DENIED or service 1913 USER_UNKNOWN 1915 PendingI CC initial answer Grant Idle 1916 received with result code service 1917 equal to credit-control N/A to end user 1919 PendingI Failed CC initial answer Grant Idle 1920 received CCFH equal to Service to 1921 CONTINUE end user 1923 PendingI Failed CC initial answer Terminate Idle 1924 received and CCFH equal end user's 1925 to TERMINATE or equal to service 1926 RETRY_AND_TERMINATE 1928 PendingI User service terminated Queue PendingI 1929 termination 1930 event 1932 PendingI Change in rating condition Queue PendingI 1933 changed 1934 rating 1935 condition 1936 event 1938 CLIENT, SESSION BASED for intermediate and final interrogations 1939 State Event Action New State 1940 ---------------------------------------------------------------- 1942 Open Granted unit elapses Send PendingU 1943 and no final unit CC update 1944 indication received req., 1945 start Tx. 1947 Open Granted unit elapses Terminate PendingT 1948 and final unit action end user's 1949 equal to TERMINATE service, send 1950 received CC termination 1951 req. 1953 Open Change in rating condition Send PendingU 1954 in queue CC update 1955 req., 1956 Start Tx. 1958 Open Service terminated in queue Send PendingT 1959 CC termination 1960 req. 1962 Open Change in rating condition Send PendingU 1963 or Validity-Time elapses CC update 1964 req., 1965 Start Tx. 1967 Open User service terminated Send PendingT 1968 CC termination 1969 req. 1971 Open RAR received Send RAA PendingU 1972 followed by 1973 CC update req., 1974 start Tx 1976 PendingU Successful CC update Stop Tx Open 1977 answer received 1979 PendingU Failure to send, or Grant Idle 1980 temporary error and service to 1981 CCFH equal to CONTINUE end user 1983 PendingU Failure to send, or Terminate Idle 1984 temporary error and end user's 1985 CCFH equal to TERMINATE service 1986 or equal to RETRY_AND_TERMINATE 1988 PendingU Tx expired and CCFH Terminate Idle 1989 equal to TERMINATE end user's 1990 service 1992 PendingU Tx expired and CCFH equal Grant PendingU 1993 to CONTINUE or equal to service to 1994 RETRY_AND_TERMINATE end user. 1996 PendingU CC update answer Terminate Idle 1997 received with result code end user's 1998 SERVICE_DENIED service 2000 PendingU CC update answer Grant Idle 2001 received with result code service 2002 equal to credit-control N/A to end user 2004 PendingU Failed CC update Grant Idle 2005 answer received and service to 2006 CCFH equal to CONTINUE end user. 2008 PendingU Failed CC update Terminate Idle 2009 answer received CCFH end user's 2010 equal to TERMINATE or service 2011 equal to RETRY_AND_TERMINATE 2013 PendingU User service terminated Queue PendingU 2014 termination 2015 event 2017 PendingU Change in rating Queue PendingU 2018 condition changed 2019 rating 2020 condition 2021 event 2023 PendingU RAR received Send RAA PendingU 2025 PendingT Successful CC Idle 2026 termination answer received 2028 PendingT Failure to send, or temporary Idle 2029 error or failed answer 2031 PendingT Change in rating condition PendingT 2032 CLIENT, EVENT BASED 2033 State Event Action New State 2034 ---------------------------------------------------------------- 2035 Idle Client or device requests Send PendingE 2036 a one-time service CC event 2037 req., 2038 Start Tx. 2040 Idle Request in storage Send PendingB 2041 stored 2042 request 2044 PendingE Successful CC event Grant Idle 2045 answer received service to 2046 end user 2048 PendingE Failure to send, temporary Indicate Idle 2049 error or failed CC event service 2050 answer received, or error 2051 Tx expired, requested 2052 action BALANCE_CHECK or 2053 PRICE_ENQUIRY 2055 PendingE CC event answer Terminate Idle 2056 received with result code end user's 2057 SERVICE_DENIED or service 2058 USER_UNKNOWN and Tx running 2060 PendingE CC event answer Grant Idle 2061 received with result code service 2062 credit-control N/A, requested to end 2063 action DIRECT_DEBITING user 2065 PendingE Failure to send, temporary Grant Idle 2066 error or failed CC event service 2067 answer received, requested to end 2068 action DIRECT_DEBITING and user 2069 DDFH equal to CONTINUE 2071 PendingE Failed CC event Terminate Idle 2072 answer received or temporary end user's 2073 error, requested action service 2074 DIRECT_DEBITING and 2075 DDFH equal to 2076 TERMINATE_OR_BUFFER and 2077 Tx running 2079 PendingE Tx expired, requested Grant PendingE 2080 action DIRECT_DEBITING service 2081 to end 2082 user 2084 PendingE Failure to send, requested Store Idle 2085 action DIRECT_DEBITING and request with 2086 DDFH equal to T-flag 2087 TERMINATE_OR_BUFFER 2089 PendingE Temporary error, requested Store Idle 2090 action DIRECT_DEBITING and request 2091 DDFH equal to 2092 TERMINATE_OR_BUFFER and 2093 Tx expired 2095 PendingE Failed answer or answer Idle 2096 received with result code 2097 SERVICE DENIED or USER_UNKNOWN, 2098 requested action 2099 DIRECT_DEBITING and Tx expired 2101 PendingE Failed CC event answer Indicate Idle 2102 received, requested service 2103 action REFUND_ACCOUNT error and 2104 delete request 2106 PendingE Failure to send or Store Idle 2107 Tx expired, requested request 2108 action REFUND_ACCOUNT with T-flag 2110 PendingE Temporary error Store Idle 2111 and requested action request 2112 REFUND_ACCOUNT 2114 PendingB Successful CC answer Delete Idle 2115 received request 2117 PendingB Failed CC answer Delete Idle 2118 received request 2120 PendingB Failure to send or Idle 2121 temporary error 2122 SERVER, SESSION AND EVENT BASED 2124 State Event Action New State 2125 ---------------------------------------------------------------- 2127 Idle CC initial request Send Open 2128 received and successfully CC initial 2129 processed. answer, 2130 reserve units, 2131 start Tcc 2133 Idle CC initial request Send Idle 2134 received, but not CC initial 2135 successfully processed. answer with 2136 Result-Code 2137 =! SUCCESS 2139 Idle CC event request Send Idle 2140 received and successfully CC event 2141 processed. answer, 2142 debit units 2144 Idle CC event request Send Idle 2145 received, but not CC event 2146 successfully processed. Answer with 2147 Result-Code 2148 != SUCCESS 2150 Open CC update request Send Open 2151 received and successfully CC answer, 2152 processed debit used 2153 units and 2154 reserve 2155 new units, 2156 Restart Tcc 2158 Open CC update request Send Idle 2159 received, but not CC update 2160 successfully processed. Answer with 2161 Result-Code 2162 != SUCCESS, 2163 debit used 2164 units 2166 Open CC termination request Send Idle 2167 received, and successfully CC termin. 2168 processed answer, 2169 Stop Tcc, 2170 debit used 2171 units 2173 Open CC termination request Send Idle 2174 received, but not CC termin. 2175 successfully processed. Answer with 2176 Result-Code 2177 != SUCCESS, 2178 debit used 2179 units 2181 Open Session supervision timer Tcc Stop Tcc, Idle 2182 expired release 2183 reserved 2184 units 2186 8. Credit Control AVPs 2188 This section defines the credit-control AVPs that are specific to 2189 Diameter Credit-control Application and MAY be included in the 2190 Diameter credit control messages. 2192 The AVPs defined in this section MAY also be included in authorization 2193 commands defined in authorization specific applications, such as 2194 [NASREQ] and [DiamMIP], in case the first interrogation is performed 2195 as part of the authorization / authentication process as described in 2196 section 4. 2198 The following table describes the Diameter AVPs defined in Credit- 2199 control application, their AVP Code values, types, possible flag 2200 values and whether the AVP MAY be encrypted. 2202 +---------------------+ 2203 | AVP Flag rules | 2204 |----+-----+----+-----|----+ 2205 AVP Section | | |SHLD| MUST| | 2206 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 2207 -----------------------------------------|----+-----+----+-----|----| 2208 CC-Correlation-Id 411 8.1 OctetString| - | P | | V | Y | 2209 CC-Input-Octets 412 8.33 Unsigned64 | M | P | | V | Y | 2210 CC-Money 413 8.34 Grouped | M | P | | V | Y | 2211 CC-Output-Octets 414 8.35 Unsigned64 | M | P | | V | Y | 2212 CC-Request-Number 415 8.2 Unsigned32 | M | P | | V | Y | 2213 CC-Request-Type 416 8.3 Enumerated | M | P | | V | Y | 2214 CC-Service- 417 8.36 OctetString| M | P | | V | Y | 2215 Specific-Units | | | | | | 2216 CC-Session- 418 8.4 Enumerated | M | P | | V | Y | 2217 Failover | | | | | | 2218 CC-Sub-Session-Id 419 8.5 Unsigned64 | M | P | | V | Y | 2219 CC-Time 420 8.37 Unsigned32 | M | P | | V | Y | 2220 CC-Total-Octets 421 8.38 Unsigned64 | M | P | | V | Y | 2221 Check-Balance- 422 8.6 Enumerated | M | P | | V | Y | 2222 Result | | | | | | 2223 Cost-Information 423 8.7 Grouped | M | P | | V | Y | 2224 Cost-Unit 424 8.8 UTF8String | M | P | | V | Y | 2225 Currency-Code 425 8.11 Unsigned32 | M | P | | V | Y | 2226 Credit-Control 426 8.9 Enumerated | M | P | | V | Y | 2227 Credit-Control- 427 8.10 Enumerated | M | P | | V | Y | 2228 Failure-Handling | | | | | | 2229 Direct-Debiting 428 8.12 Enumerated | M | P | | V | Y | 2230 Failure-Handling | | | | | | 2231 Exponent 429 8.13 Integer32 | M | P | | V | Y | 2232 Final-Unit-Action 449 8.14 Enumerated | M | P | | V | Y | 2233 Final-Unit- 430 8.15 Grouped | M | P | | V | Y | 2234 Indication | | | | | | 2235 Granted-Service- 431 8.16 Grouped | M | P | | V | Y | 2236 Unit | | | | | | 2237 Rating-Group 432 8.39 Unsigned32 | M | P | | V | Y | 2238 Redirect-Address 433 8.17 Enumerated | M | P | | V | Y | 2239 -Type | | | | | | 2240 Redirect-Server 434 8.18 Grouped | M | P | | V | Y | 2241 Redirect-Server 435 8.19 UTF8String | M | P | | V | Y | 2242 -Address | | | | | | 2243 Requested-Action 436 8.20 Enumerated | M | P | | V | Y | 2244 Requested-Service 437 8.21 Grouped | M | P | | V | Y | 2245 Unit | | | | | | 2246 Restriction 438 8.22 IPFiltrRule| M | P | | V | Y | 2247 -Filter-Rule | | | | | | 2248 Service- 439 8.40 UTF8String | M | P | | V | Y | 2249 Identifier | | | | | | 2250 Service-Parameter 440 8.23 Grouped | - | P | | V | Y | 2251 Info | | | | | | 2252 Service- 441 8.24 Unsigned32 | - | P | | V | Y | 2253 Parameter-Type | | | | | | 2254 Service- 442 8.25 UTF8String | - | P | | V | Y | 2255 Parameter-Value | | | | | | 2256 Subscription-Id 443 8.26 Grouped | M | P | | V | Y | 2257 Subscription-Id 444 8.27 UTF8String | M | P | | V | Y | 2258 -Data | | | | | | 2259 Subscription-Id 450 8.28 Enumerated | M | P | | V | Y | 2260 -Type | | | | | | 2261 Tariff-Change 452 8.42 Enumerated | M | P | | V | Y | 2262 -Usage | | | | | | 2263 Tariff-Time 451 8.41 Time | M | P | | V | Y | 2264 -Change | | | | | | 2265 Unit-Value 445 8.29 Grouped | M | P | | V | Y | 2266 Used-Service-Unit 446 8.30 Grouped | M | P | | V | Y | 2267 Value-Digits 447 8.31 Unsigned64 | M | P | | V | Y | 2268 Validity-Time 448 8.32 Unsigned32 | M | P | | V | Y | 2270 8.1 CC-Correlation-Id AVP 2272 The CC-Correlation-Id AVP (AVP Code 411) is type of OctetString and 2273 contains information to correlate credit control requests generated 2274 for different components of the service, e.g. transport and service 2275 level. 2277 8.2 CC-Request-Number AVP 2279 The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and 2280 identifies this request within one session. As Session-Id AVPs are 2281 globally unique, the combination of Session-Id and CC-Request-Number 2282 AVPs is also globally unique, and can be used in matching credit 2283 control messages with confirmations. An easy way to produce unique 2284 numbers is to set the value to 0 for credit control request of type 2285 INITIAL_REQUEST and EVENT_REQUEST, and set the value to 1 for the 2286 first UPDATE_REQUEST, 2 for the second, and so on until the value for 2287 TERMINATION_REQUEST. 2289 8.3 CC-Request-Type AVP 2291 The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and 2292 contains the reason for sending the Credit-control request message. 2293 It MUST be present in all CC-Request messages. The following values 2294 are defined for the CC-Request-Type AVP: 2296 INITIAL_REQUEST 1 2297 A Credit-control Initial request is used to initiate a 2298 credit control session, and contains credit control 2299 information that is relevant to the initiation of the 2300 session. 2302 UPDATE_REQUEST 2 2303 An Update Credit-control request contains credit control 2304 information for an existing credit control session. Update 2305 Credit-control requests SHOULD be sent every time a credit- 2306 control re-authorization is needed at the expiry of the 2307 allocated quota or validity time. Further, additional 2308 service-specific events MAY trigger a spontaneous Update 2309 request. 2311 TERMINATION_REQUEST 3 2312 A Credit-control Termination Request is sent to terminate a 2313 credit-control session and contains credit control 2314 information relevant to the existing session. 2316 EVENT_REQUEST 4 2317 A Credit Control Event Request is used when there is no need 2318 to maintain any credit control session state in the credit- 2319 control server. This request contains all information 2320 relevant to the service, and is the only request of the 2321 service. The reason for the Event request 2322 is further detailed in the Requested-Action AVP. The 2323 Requested-AVP MUST be included in the Credit-Control-Request 2324 message when CC-Request-Type is set to EVENT_REQUEST. 2326 8.4 CC-Session-Failover AVP 2328 The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and 2329 contains information whether the moving of the credit-control message 2330 stream to a backup server during an ongoing credit-control session is 2331 supported. In case of communication failures, the credit control 2332 message streams can be moved to an alternative destination if the 2333 credit control server supports failover to an alternative server. The 2334 secondary credit control server name, if received from the AAA server, 2335 can be used as an address of the backup server. An implementation is 2336 not required to support the moving of credit control message stream to 2337 an alternative server, since it requires also moving of information 2338 related to the credit control session to backup server. 2340 The following values are defined for the CC-Session-Failover AVP: 2342 FAILOVER_NOT_SUPPORTED 0 2344 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED 2345 the Credit control message stream MUST NOT to be moved to 2346 alternative destination in case of communication failure. 2348 This is the default behavior if the AVP isn't included in the reply 2349 from the authorization or credit-control server. 2351 FAILOVER_SUPPORTED 1 2353 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the 2354 Credit control message stream SHOULD be moved to alternative 2355 destination in case of communication failure. The moving the credit 2356 control message stream to backup server MAY require that 2357 information related to the credit control session should be also 2358 forwarded to alternative server. 2360 8.5 CC-Sub-Session-Id AVP 2362 The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and 2363 contains the credit-control sub-session identifier. The combination of 2364 the Session-Id and this AVP MUST be unique per sub-session, and the 2365 value of this AVP MUST be monotonically increased by one for all new 2366 sub-sessions. The absence of this AVP implies no sub-sessions are in 2367 use, with the exception of a CC-Request whose CC-Request-Type is set 2368 to TERMINATION_REQUEST. A TERMINATION_REQUEST message with no CC-Sub- 2369 Session-Id AVP present will signal the termination of all sub-sessions 2370 for a given Session-Id. 2372 8.6 Check-Balance-Result AVP 2374 The Check Balance Result AVP (AVP code 422) is of type Enumerated and 2375 contains the result of the balance check. This AVP is applicable only 2376 when the Requested-Action AVP indicates CHECK_BALANCE in the Credit- 2377 Control-Request command. 2379 The following values are defined for the Check-Balance-Result AVP. 2381 ENOUGH_CREDIT 0 2382 There is enough credit in the account to cover the 2383 requested service. 2385 NO_CREDIT 1 2386 There isn't enough credit in the account to cover the 2387 requested service. 2389 8.7 Cost-Information AVP 2391 The Cost-Information AVP (AVP Code 423) is of type Grouped and is used 2392 to return the cost information of a service in the Credit-Control- 2393 Answer command. The included Unit-Value AVP contains the cost estimate 2394 (always type of money) of the service in case of price enquiry or the 2395 accumulated cost estimation in the case of credit- control session. 2397 The Currency-Code specifies in which currency the cost was given. 2398 The Cost-Unit specifies the unit when the service cost is a cost per 2399 unit (e.g. cost for the service is $1 per minute). 2401 When the Requested-Action AVP with value PRICE_ENQUIRY is included in 2402 the Credit-Control-Request command the Cost-Information AVP sent in 2403 the succeeding Credit-Control-Answer command contains the cost 2404 estimation of the requested service, without any reservation being 2405 made. 2407 The Cost-Information AVP included in the Credit-Control-Answer command 2408 with the CC-Request-Type set to UPDATE_REQUEST contains the 2409 accumulated cost estimation for the session without taking any credit- 2410 reservation into account. 2412 The Cost-Information AVP included in the Credit-Control-Answer command 2413 with the CC-Request-Type set to EVENT_REQUEST or TERMINATION_REQUEST 2414 contains the estimated total cost for the requested service. 2416 It has the following ABNF grammar: 2418 Cost-Information ::= < AVP Header: 423 > 2419 { Unit-Value } 2420 { Currency-Code } 2421 [ Cost-Unit ] 2423 8.8 Cost-Unit AVP 2425 The Cost-Unit AVP (AVP Code 424) is of type UTF8String and specifies 2426 the applicable unit to the Cost-Information when the service cost is a 2427 cost per unit (e.g. cost of the service is $1 pe rminute). The Cost- 2428 Unit can be for instance minute, hour, day, kilobytes, megabytes etc. 2430 8.9 Credit-Control AVP 2432 The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST 2433 be included in AA requests when service element has credit control 2434 capabilities. 2436 CREDIT_AUTHORIZATION 0 2438 If the AAA server determines the user is a prepaid user, this value 2439 indicates that credit-control server MUST be contacted to perform 2440 the first interrogation. The value of the Credit-Control AVP MUST 2441 always be set to 0 in AA request sent to perform the first 2442 interrogation and initiate a new credit-control session. 2444 RE_AUTHORIZATION 1 2445 This value indicates to the Diameter AAA server that a credit- 2446 control session is ongoing for the subscriber and the credit-control 2447 server MUST not be contacted. The Credit-Control AVP set to the 2448 value of 1 is to be used only when the first interrogation has been 2449 successfully performed and the credit-control session is ongoing 2450 (i.e. re-authorization triggered by Authorization-Lifetime). This 2451 value MUST NOT be used in AA request sent to perform the first 2452 interrogation. 2454 8.10 Credit-Control-Failure-Handling AVP 2456 The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type 2457 Enumerated. The credit-control client uses information in this AVP to 2458 decide what to do if the sending of credit-control messages to the 2459 credit-control server has been for instance temporarily prevented due 2460 to a network problem. Depending on the service logic, the credit- 2461 control server can order the client to terminate the service 2462 immediately when there is a reason to believe that the service cannot 2463 be charged, or to try failover to an alternative server, if possible, 2464 and then either terminate or grant the service should also the 2465 alternative connection fail. 2467 TERMINATE 0 2469 When the Credit-Control-Failure-Handling AVP is set to TERMINATE 2470 the service MUST only be granted as long as there is a connection 2471 to the credit-control server. If the credit-control client does not 2472 receive any Credit-Control-Answer message within the Tx timer (as 2473 defined in section 13) the credit-control request is regarded 2474 failed and the end user's service session is terminated. 2476 This is the default behavior if the AVP isn't included in the reply 2477 from the authorization or credit-control server. 2479 CONTINUE 1 2481 When the Credit-Control-Failure-Handling AVP is set to CONTINUE 2482 the credit-control client SHOULD re-send the request to an 2483 alternative server in case of transport or temporary failures, 2484 provided that failover procedure is supported in the credit- 2485 control server and the credit-control client, and an alternative 2486 server is available. Otherwise, the service SHOULD be granted 2487 even if credit-control messages can't be delivered. 2489 RETRY_AND_TERMINATE 2 2491 When the Credit-Control-Failure-Handling AVP is set to 2492 RETRY_AND_TERMINATE the credit-control client SHOULD re-send the 2493 request to an alternative server in case of transport or 2494 temporary failures, provided that failover procedure is 2495 supported in the credit-control server and the credit-control 2496 client, and an alternative server is available. Otherwise, the 2497 service SHOULD not be granted when the credit-control messages 2498 can't be delivered. 2500 8.11 Currency-Code AVP 2502 The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and 2503 contains a currency code that specifies in which currency the values 2504 of AVPs containing monetary units were given. It is specified using 2505 the numeric values defined in the ISO 4217 standard. 2507 8.12 Direct-Debiting-Failure-Handling AVP 2509 The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type 2510 Enumerated. The credit-control client uses information in this AVP to 2511 decide what to do if the sending of credit-control messages 2512 (Requested-Action AVP set to Direct Debiting) to the credit-control 2513 server has been for instance temporarily prevented due to a network 2514 problem. 2516 TERMINATE_OR_BUFFER 0 2518 When the Direct-Debiting-Failure-Handling AVP is set to 2519 TERMINATE_OR_BUFFER the service MUST be granted as long as there 2520 is a connection to the credit-control server. If the credit- 2521 control client does not receive any Credit-Control-Answer 2522 message within the Tx timer (as defined in section 13) the 2523 credit-control request is regarded failed. The client SHOULD 2524 terminate the service if it can determine from the failed answer 2525 that units have not been debited. Otherwise the credit-control 2526 client SHOULD grant the service, store the request to 2527 application level non-volatile storage and try to re-send the 2528 request. These requests MUST be marked as possible duplicate by 2529 setting the T-flag in the command header as described in 2530 [DIAMBASE] section 3. 2532 This is the default behavior if the AVP isn't included in the 2533 reply from the authorization server. 2535 CONTINUE 2536 1 2537 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE 2538 the service SHOULD be granted even if credit-control messages 2539 can't be delivered and the request should be deleted. 2541 8.13 Exponent AVP 2543 Exponent AVP is of type Integer32 (AVP code 429) and contains the 2544 exponent value to be applied for the Value-Digit AVP within the Unit- 2545 Value AVP. 2547 8.14 Final-Unit-Action AVP 2549 The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and 2550 indicates to the credit-control client the action to be taken when the 2551 user's account cannot cover the service cost. 2553 The Final-Unit-Action can be one of the following: 2555 TERMINATE 0 2557 The credit control client MUST terminate the service session. 2558 This is the default handling applicable whenever the credit 2559 control client receives an unsupported Final-Unit-Action value 2560 and MUST be supported by all the Diameter credit control client 2561 implementations conforming to this specification. 2563 REDIRECT 1 2565 The service element MUST redirect the user to the address 2566 specified in the Redirect-Server-Address AVP. The redirect 2567 action is defined in section 5.5.2. 2569 RESTRICT_ACCESS 2 2571 The access device MUST restrict the user access according to the 2572 IP packet filters defined in the Restriction-Filter-Rule AVP or 2573 according to the IP packet filters identified by the Filter-Id 2574 AVP. All the packets not matching the filters MUST be dropped 2575 (see section 5.5.3). 2577 8.15 Final-Unit-Indication AVP 2579 The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and 2580 indicates that the Granted-Service-Unit AVP in the Credit-Control- 2581 Answer, or in the AA answer, contains the final units for the service. 2582 After these units have expired, the Diameter credit-control client is 2583 responsible for executing the action indicated in the Final-Unit- 2584 Action AVP (see section 5.5). 2586 If more than one unit types are received in the Credit-Control-Answer, 2587 the Unit type which first expired SHOULD cause the credit-control 2588 client to execute the specified action. 2590 In the first interrogation, the Final-Unit-Indication AVP with Final- 2591 Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no 2592 Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA 2593 answer. This indicates to the Diameter credit-control client to 2594 immediately execute the specified action. If the home service provider 2595 policy is to terminate the service, naturally, the server SHOULD 2596 return the appropriate transient failure (see section 9.1) in order to 2597 disconnect the end user and close the credit control session. 2599 The Final-Unit-Action AVP defines the behavior of the service element 2600 when the user's account cannot cover the cost of the service and MUST 2601 always be present if the Final-Unit-Indication AVP is included in a 2602 command. 2604 If the Final-Unit-Action AVP is set to TERMINATE no other AVPs MUST be 2605 present. 2607 If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect- 2608 Server AVP MUST be present. The Restriction-Filter-Rule AVP or the 2609 Filter-Id AVP MAY be present in the Credit-Control-Answer message if 2610 the user is allowed to access also other zero-rated services not 2611 accessible through the address given in the Redirect-Server AVP. 2613 If the Final-Unit-Action AVP is set to RESTRICT_ACCESS either the 2614 Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. 2616 The Filter-Id AVP is defined in [NASREQ]. The Filter-Id AVP can be 2617 used to reference an IP filter list installed in the access device by 2618 other means than the Diameter Credit Control Application e.g. locally 2619 configured or configured by another entity. 2621 The Final-Unit-Indication AVP has the following ABNF grammar: 2623 Final-Unit-Indication ::= < AVP Header: 430 > 2624 { Final-Unit-Action } 2625 *[ Restriction-Filter-Rule ] 2626 *[ Filter-Id ] 2627 [ Redirect-Server ] 2629 8.16 Granted-Service-Unit AVP 2631 Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and 2632 contains the amount of units that the Diameter credit-control client 2633 can provide to the end user until the service must be released or the 2634 new Credit-Control-Request must be sent. A client is not required to 2635 implement all of the unit types, and must treat unknown or unsupported 2636 unit types in the answer message as an incorrect CCA answer. In that 2637 case the client shall terminate credit control session and indicate in 2638 the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. 2640 The Service-Identifier and the Rating-Group AVPs are used to associate 2641 the granted units to a given service or rating group. 2642 In case both the Service-Identifier and the Rating-Group AVPs are 2643 included, the target of the granted units is always the service(s) 2644 indicated by the value of the Service-Identifier AVP. 2645 A value of 0 (zero) granted service unit associated to a Service- 2646 entifier(s) or Rating-Group indicates that the corresponding traffic 2647 MUST be denied. Note that in case the credit-control server want to 2648 disconnect the user and close the credit-control session, it SHOULD 2649 use the appropriate error code in the Credit-Control-Answer message 2650 rather than including n times the Granted-Service-Units AVPs with the 2651 value of 0 (zero). 2652 In contrast, a value of max type granted service unit (e.g. max 2653 Unsigned 32 is FFFFFFFF) associated to a Service-Identifier(s) or 2654 Rating-Group indicates that the corresponding traffic is free-of- 2655 charge. With unit type money, the value of the Exponent AVP is set to 2656 0 (zero) when free-of-charge is indicated. With unit type service 2657 specific, the value of the CC-Service-Specific-Units AVP is set to 2658 FFFFFFFF to indicate free-of-charge. 2660 The Granted-Service-Unit AVP has the following ABNF grammar: 2662 Granted-Service-Unit ::= < AVP Header: 431 > 2663 [ Tariff-Time-Change ] 2664 [ CC-Time ] 2665 [ CC-Money ] 2666 [ CC-Total-Octets ] 2667 [ CC-Input-Octets ] 2668 [ CC-Output-Octets ] 2669 [ CC-Service-Specific-Units ] 2670 *[ Service-Identifier ] 2671 [ Rating-Group ] 2673 8.17 Redirect-Address-Type AVP 2675 The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated and 2676 defines the address type of the address given in the Redirect-Server- 2677 Address AVP. 2679 The address type can be one of the following: 2681 IPv4 Address 0 2682 The address type is in form of IPv4 address, as defined in [RFC 2683 791]. 2685 IPv6 Address 1 2686 The address type is in form of IPv6 address, as defined in [RFC 2687 2373]. 2689 URL 2 2690 The address type is in form of Uniform Resource Locator, as 2691 defined in [RFC 1738]. 2693 SIP URI 3 2694 The address type is in form of SIP Uniform Resource Indicator, 2695 as defined in [SIP]. 2697 8.18 Redirect-Server AVP 2699 The Redirect-Server AVP (AVP Code 434) is of type Grouped and contains 2700 the address information of the redirect server (e.g. HTTP redirect 2701 server, SIP Server) where the end user is to be connected when the 2702 account cannot cover the service cost. It MUST be present when the 2703 Final-Unit-Action AVP is set to REDIRECT. 2705 It has the following ABNF grammar: 2707 Redirect-Server ::= < AVP Header: 434 > 2708 { Redirect-Address-Type } 2709 { Redirect-Server-Address } 2711 8.19 Redirect-Server-Address AVP 2713 The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String 2714 and defines the address of the redirect server (e.g. HTTP redirect 2715 server, SIP Server) where the end user is to be connected when the 2716 account cannot cover the service cost. 2718 8.20 Requested-Action AVP 2720 The Requested-Action AVP (AVP Code 436) is type of Enumerated and 2721 contains the requested action being sent by Credit-Control-Request 2722 command where the CC-Request-Type is set to EVENT_REQUEST. The 2723 following values are defined for the Requested-Action AVP: 2725 DIRECT_DEBITING 0 2727 Direct debiting indicates that the request is to decrease the 2728 end user's account according to information specified in the 2729 Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 2730 The Granted-Service Unit AVP in the Credit-Control-Answer 2731 command contains the debited units. 2733 REFUND_ACCOUNT 1 2734 Refund account indicates that the request is to increase the 2735 end user's account according to information specified in the 2736 Requested-Service-Unit AVP and/or Service-Parameter-Info AVP. 2737 The Granted-Service Unit AVP in the Credit-Control-Answer 2738 command contains the refunded units. 2740 CHECK_BALANCE 2 2742 Check balance indicates that the request is a balance check 2743 request. In this case the checking of the account balance is 2744 done without any credit reservation from the account. The 2745 Check-Balance-Result AVP in the Credit-Control-Answer command 2746 contains the result of the Balance Check. 2748 PRICE_ENQUIRY 3 2750 Price Enquiry indicates that the request is a price enquiry 2751 request. In this case neither checking of the account balance 2752 nor reservation from the account will be done, only the price 2753 of the service will be returned in the Cost-Information AVP in 2754 the Credit-Control-Answer Command. 2756 8.21 Requested-Service-Unit AVP 2758 The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and 2759 contains the amount of requested units specified by the Diameter 2760 credit-control client. A server is not required to implement all of 2761 the unit types, and must treat unknown or unsupported unit types as 2762 invalid AVPs. 2764 The Service-Identifier and the Rating-Group AVPs are used to request 2765 units for a given service(s) or rating group when the service element 2766 supports credit control for multiple services in one credit control 2767 session. 2769 If both the AVPs are present, the Rating-Group AVP indicates the 2770 rating group to which the service(s) specified by the Service- 2771 Identifier(s) belongs. If only the Rating-Group-Id AVP is present, 2772 this is a credit authorization request for all the services that 2773 belongs to the specified rating group. 2775 A server not implementing the Service-Identifier AVP and the Rating- 2776 Group AVP must treat them as invalid AVPs. 2778 The Requested-Service-Unit AVP has the following ABNF grammar: 2780 Requested-Service-Unit ::= < AVP Header: 437 > 2781 [ CC-Time ] 2782 [ CC-Money ] 2784 [ CC-Total-Octets ] 2785 [ CC-Input-Octets ] 2786 [ CC-Output-Octets ] 2787 [ CC-Service-Specific-Units ] 2788 *[ Service-Identifier ] 2789 [ Rating-Group ] 2791 8.22 Restriction-Filter-Rule AVP 2793 The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule 2794 and provides filter rules corresponding to zero-rated services offered 2795 by the home service provider. The access device need to configure the 2796 specified filter rules for the subscriber and MUST drop all the 2797 packets not matching these filters. Zero, one or more such AVPs MAY be 2798 present in a Credit-Control-Answer message or in an AA answer message. 2800 8.23 Service-Parameter-Info AVP 2802 The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and 2803 contains a service specific information used for price calculation or 2804 rating. The Service-Parameter-Type AVP defines the service parameter 2805 type and the Service-Parameter-Value AVP contains the parameter value. 2806 The actual contents of these AVPs are not within the scope of this 2807 document and SHOULD be defined in another Diameter application, 2808 standards written by other standardization bodies, or service specific 2809 documentation. 2811 In case of unknown service request (e.g. unknown Service-Parameter- 2812 Type), the corresponding answer message MUST contain error code 2813 DIAMETER_RATING_FAILED. A Credit Control Answer message with this 2814 error MUST contain one or more Failed-AVP AVPs containing the Service- 2815 Parameter-Info AVPs that caused the failure. 2817 It has the following ABNF grammar: 2819 Service-Parameter-Info ::= < AVP Header: 440 > 2820 [ Service-Parameter-Type ] 2821 [ Service-Parameter-Value ] 2823 8.24 Service-Parameter-Type AVP 2825 The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) 2826 and defines the type of the service event specific parameter (e.g. it 2827 can be end-user location, service name). The different parameters and 2828 their types are service specific and the meanings of these parameters 2829 are not defined in this document. The Service-Parameter-Value AVP 2830 contains the service parameter type. 2832 8.25 Service-Parameter-Value AVP 2834 The Service-Parameter-Value AVP is of type UTF8String (AVP Code 442) 2835 and contains the value of the service parameter type. 2837 8.26 Subscription-Id AVP 2839 The Subscription-Id AVP (AVP Code 443) is used to identify the end 2840 user's subscription and is of type Grouped. The Subscription-Id AVP 2841 includes a Subscription-Id-Data AVP that hold the identifier and a 2842 Subscription-Id-Type AVP that defines the identifier type. 2844 It has the following ABNF grammar: 2846 Subscription-Id ::= < AVP Header: 443 > 2847 { Subscription-Id-Type } 2848 { Subscription-Id-Data } 2850 8.27 Subscription-Id-Data AVP 2852 The Subscription-Id-Data AVP (AVP Code 444) is used to identify the 2853 end-user and is of type UTF8String. The Subscription-Id-Type AVP 2854 defines which type of identifier is used. 2856 8.28 Subscription-Id-Type AVP 2858 The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated and 2859 it is used to determine which type of identifier that is carried by 2860 the Subscription-Id AVP. A server is not required to implement all of 2861 the Subscription-Id-Types, and MUST treat unknown or unsupported 2862 Subscription-Id-Types as invalid AVP values. 2864 The identifier can be one of the following: 2866 END_USER_MSISDN 0 2868 The identifier is in international MSISDN format, according 2869 to the ITU-T E.164 numbering plan as defined in [E164] and 2870 [CE164]. 2872 END_USER_IMSI 1 2873 The identifier is in international IMSI format, according to 2874 the ITU-T E.212 numbering plan as defined in [E121] and 2875 [CE121]. 2877 END_USER_SIP_URL 2 2878 The identifier is in the form of a SIP URL as defined in 2879 [SIP]. 2881 END_USER_NAI 3 2882 The identifier is in the form of a Network Access Identifier 2883 as defined in [NAI]. 2885 END_USER_PRIVATE 4 2886 The Identifier is a credit-control server private identifier. 2888 8.29 Unit-Value AVP 2890 Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the 2891 units as decimal value. The Unit-Value is a value together with an 2892 exponent, i.e. Unit-Value = Value-Digits AVP * 10^Exponent. This 2893 representation avoids unwanted rounding off. For example the value of 2894 2,3 is represented as Value-Digits = 23 and Exponent = -1. The absence 2895 of exponent part MUST be interpreted as exponent being equal to zero. 2897 It has the following ABNF grammar: 2899 Unit-Value ::= < AVP Header: 445 > 2900 { Value-Digits } 2901 [ Exponent ] 2903 8.30 Used-Service-Unit AVP 2905 The Used-Service-Unit AVP is of type Grouped AVP (AVP Code 446) and 2906 contains the amount of used units measured from the point when the 2907 service became active or, in case of interim interrogations are used 2908 during the session, from the point when the previous measurement 2909 ended. 2911 The Service-Identifier and the Rating-Group AVPs are used to associate 2912 the used units to a given service or rating group. 2913 When granted service units are associated to a service or rating 2914 group, the credit control client MUST report the corresponding used 2915 service units. If the granted units are associated to a rating group, 2916 the units used by each of the Service-Identifier belonging to that 2917 rating group SHOULD be reported if this information is available to 2918 the credit control client. Therefore, multiple instances of the Used- 2919 Service-Unit AVP MAY be present in a request, each associated to the 2920 relevant Rating-Group-Id and to the identifier of the service (i.e. 2921 Service-Identifier) that consumed some of the granted units. 2923 The Used-Service-Unit AVP has the following ABNF grammar: 2925 Used-Service-Unit ::= < AVP Header: 446 > 2926 [ Tariff-Change-Usage ] 2927 [ CC-Time ] 2928 [ CC-Money ] 2929 [ CC-Total-Octets ] 2931 [ CC-Input-Octets ] 2932 [ CC-Output-Octets ] 2933 [ CC-Service-Specific-Units ] 2934 *[ Service-Identifier ] 2935 [ Rating-Group ] 2937 8.31 Value-Digits AVP 2939 The Value-Digits AVP is of type Unsigned64 (AVP code 447) and contains 2940 the significant digits of the number. If decimal values are needed to 2941 present the units, the scaling MUST be indicated with the related 2942 Exponent AVP. For example for the monetary amount $ 0.05 the value of 2943 Value-Digits AVP MUST be set to 5 and the scaling MUST be indicated 2944 with the Exponent AVP set to -2. 2946 8.32 Validity-Time AVP 2948 The Validity-Time AVP is of type Unsigned32 (AVP code 448) and is sent 2949 from the credit-control server to the credit-control client. The AVP 2950 contains the validity time of the granted service units. If the 2951 granted service units have not been consumed within the validity time 2952 specified in this AVP, the credit-control client MUST send a Credit- 2953 Control-Request request to the server with CC-Request-Type set to 2954 UPDATE_REQUEST. The value field of the Validity-Time AVP is given in 2955 seconds. 2957 The Validity-Time AVP is also used for the graceful service 2958 termination (see section 5.5) to indicate to the credit control client 2959 how long the subscriber is allowed to use network resources after the 2960 specified action (i.e. REDIRECT or RESTRICT_ACCESS) started. Upon the 2961 Validity-Time elapses a new intermediate interrogation is sent to the 2962 server. 2964 8.33 CC-Input-Octets AVP 2966 The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64, and 2967 contains the number of requested, granted or used octets that can 2968 be/have been received from the end user. 2970 8.34 CC-Money AVP 2972 The CC-Money AVP (AVP Code 413) is of type Grouped, and specifies the 2973 monetary amount in the given currency. The Currency-Code AVP SHOULD be 2974 included. It has the following ABNF grammar: 2976 CC-Money ::= < AVP Header: 413 > 2977 { Unit-Value } 2978 [ Currency-Code ] 2980 8.35 CC-Output-Octets AVP 2982 The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64, and 2983 contains the number of requested, granted or used octets that can 2984 be/have been sent to the end user. 2986 8.36 CC-Service-Specific-Units AVP 2988 The CC-Service-Specific-Units AVP (AVP Code 417) is of type 2989 OctetString, and specifies the number of service specific units (e.g. 2990 number of events, points) given in a selected service. 2992 8.37 CC-Time AVP 2994 The CC-Time AVP (AVP Code 420) is of type Unsigned32, and indicates 2995 the length of the requested, granted or used time in seconds. 2997 8.38 CC-Total-Octets AVP 2999 The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64, and 3000 contains the total number of requested, granted or used octets 3001 regardless of the direction (sent or received). 3003 8.39 Rating-Group AVP 3005 The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and contains 3006 the identifier of a rating group. All the services subject to the same 3007 rating type are part of the same rating group. This is an identifier 3008 allocated by the home service provider and MUST be unique within the 3009 home service provider domain. 3011 A usage example of this AVP is illustrated in Appendix A (Flow X). 3013 8.40 Service-Identifier AVP 3015 The Service-Identifier AVP is of type UTF8String (AVP Code 439) and 3016 contains a unique identifier of a service. This is an identifier 3017 allocated by the service provider, by the service element manufacturer 3018 or by a standardization body and MUST uniquely identify a given 3019 service. The format of the service identifier is: 3021 "service-identifier" "@" "domain" 3023 service-identifier = Token 3024 The Token is an arbitrary string of characters 3025 and digits. 3027 domain = represents the entity that allocated the service-identifier. 3029 It can be ietf.org, 3gpp.org etc. if the identifier is 3030 allocated by a standardization body, or it can be the FQDN 3031 of the service provider (e.g. provider.com) or of the vendor 3032 (e.g. vendor.com) if the identifier is allocated by a 3033 private entity. 3035 Services that are for private use only, i.e. to one provider's own 3036 use, where no interoperability is deemed useful may define private 3037 identifiers without need of coordination. However, when 3038 interoperability is wanted, coordination of the identifiers via e.g. 3039 publication of informational RFC is RECOMMENDED to make Service- 3040 Identifier globally available. 3042 A usage example of this AVP for multiple services in one user session 3043 is illustrated in Appendix A (Flow X). 3045 8.41 Tariff-Time-Change AVP 3047 The Tariff-Time-Change AVP (AVP code 451) is of type Time, and 3048 includes the time in seconds since January 1, 1900 00:00 UTC when the 3049 tariff of the service will be changed. 3051 The tariff change mechanism is optional for client and server and it 3052 is not used for unit type time, since the server has full control of 3053 the time. 3055 If a client does not support the tariff time change mechanism it must 3056 treat Tariff-Time-Change AVP in the answer message as an incorrect 3057 CCA answer. In that case the client shall terminate credit control 3058 session and indicate in the Termination-Cause AVP reason 3059 DIAMETER_BAD_ANSWER. 3061 8.42 Tariff-Change-Usage AVP 3063 The Tariff-Change-Usage AVP (AVP code 452) is of type Enumerated and 3064 defines whether units are used before, after or straddled tariff 3065 change when a tariff change has occurred during the reporting period. 3066 Omission of this AVP means that no tariff change has been occurred. 3068 Tariff-Change-Usage can be one of the following. 3070 UNIT_BEFORE_TARIFF_CHANGE 0 3072 The used units contains the amount of the units before tariff 3073 change, that is units measured from the point when the previous 3074 measurement ended to the point when tariff change occurred. 3076 UNIT_AFTER_TARIFF_CHANGE 1 3077 The used units contains the amount of the units after tariff change 3078 has been occurred. 3080 UNIT_INDETERMINATE 2 3082 The used units contains the amount of units that straddle the 3083 tariff change (e.g. the metering process reports to the credit- 3084 control client in blocks of n octets and one block straddled the 3085 tariff change). 3087 9. Result Code AVP values 3089 This section defines new Result-Code AVP [DIAMBASE] values that must 3090 be supported by all Diameter implementations that conform to this 3091 specification. 3093 The Credit-Control-Answer message includes the Result-Code AVP, which 3094 MAY indicate that an error was present in the Credit-Control-Request 3095 message. A rejected Credit-Control-Request message SHOULD cause the 3096 user's session to be terminated. 3098 9.1 Transient Failure 3100 Errors that fall within the transient failures category are used to 3101 inform a peer that the request could not be satisfied at the time it 3102 was received, but MAY be able to satisfy the request in the future. 3104 DIAMETER_END_USER_SERVICE_DENIED 4010 3105 The credit-control server denies the service request due to 3106 service restrictions or limitations related to the end-user, 3107 for example the end-user's account could not cover the requested 3108 service. The possibly reported used-service-units with the CCR 3109 are deducted. 3111 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 3112 The credit-control server determines that the service can be 3113 granted to the end user but no further credit-control is needed 3114 for the service (e.g. service is free of charge). 3116 9.2 Permanent Failures 3118 Errors that fall within permanent failure category are used to inform 3119 the peer that the request failed, and should not be attempted again. 3121 DIAMETER_USER_UNKNOWN 5030 3122 The specified end user is unknown in the credit-control server. 3124 DIAMETER_RATING_FAILED 5031 3125 This error code is used to inform the credit-control client 3126 that the credit-control server cannot rate the service request 3127 due to insufficient rating input, incorrect AVP combination or 3128 due to an AVP or an AVP value that is not recognized or 3129 supported in the rating. The Failed-AVP AVP MUST be included 3130 and contain a copy of the entire AVP(s) that could not be 3131 processed successfully or an example of the missing AVP 3132 complete with the Vendor-Id if applicable. The value field of 3133 the missing AVP should be of correct minimum length and contain 3134 zeroes. 3136 10. AVP Occurrence Table 3138 The following table presents the AVPs defined in this document, and 3139 specifies in which Diameter messages they MAY, or MAY NOT be present. 3140 Note that AVPs that can only be present within a Grouped AVP are not 3141 represented in this table. 3143 The table uses the following symbols: 3144 0 The AVP MUST NOT be present in the message. 3145 0+ Zero or more instances of the AVP MAY be present in the 3146 message. 3147 0-1 Zero or one instance of the AVP MAY be present in the 3148 message. It is considered an error if there are more than 3149 once instance of the AVP. 3150 1 One instance of the AVP MUST be present in the message. 3151 1+ At least one instance of the AVP MUST be present in the 3152 message. 3154 10.1 Credit Control AVP Table 3156 The table in this section is used to represent which Credit-control 3157 applications specific AVPs defined in this document are to be present 3158 in the Credit Control messages. 3160 +-----------+ 3161 | Command | 3162 | Code | 3163 |-----+-----+ 3164 Attribute Name | CCR | CCA | 3165 ------------------------------|-----+-----+ 3166 Acct-Multi-Session-Id | 0-1 | 0-1 | 3167 Auth-Application-Id | 1 | 1 | 3168 CC-Correlation-Id | 0-1 | 0 | 3169 CC-Failover-Supported | 0 | 0-1 | 3170 CC-Request-Number | 1 | 1 | 3171 CC-Request-Type | 1 | 1 | 3172 CC-Sub-Session-Id | 0-1 | 0-1 | 3173 Check-Balance-Result | 0 | 0-1 | 3174 Cost-Information | 0 | 0-1 | 3175 Credit-Control-Failure- | 0 | 0-1 | 3176 Handling | | | 3177 Destination-Host | 0-1 | 0 | 3178 Destination-Realm | 1 | 0 | 3179 Direct-Debiting-Failure- | 0 | 0-1 | 3180 Handling | | | 3181 Event-Timestamp | 0-1 | 0-1 | 3182 Final-Unit-Indication | 0 | 0-1 | 3183 Granted-Service-Unit | 0 | 0+ | 3184 Origin-Host | 1 | 1 | 3185 Origin-Realm | 1 | 1 | 3186 Origin-State-Id | 0-1 | 0-1 | 3187 Proxy-Info | 0+ | 0+ | 3188 Redirect-Host | - | 0+ | 3189 Redirect-Host-Usage | - | 0-1 | 3190 Redirect-Max-Cache-Time | - | 0�1 | 3191 Requested-Action | 0-1 | 0 | 3192 Requested-Service-Unit | 0+ | 0 | 3193 Route-Record | 0+ | 0+ | 3194 Service-Identifier | 0-1 | 0 | 3195 Service-Parameter-Info | 0+ | 0 | 3196 Session-Id | 1 | 1 | 3197 Subscription-Id | 0+ | 0+ | 3198 Termination-Cause | 0-1 | 0 | 3199 Used-Service-Unit | 0+ | 0 | 3200 User-Name | 0-1 | 0-1 | 3201 Validity-Time | 0 | 0-1 | 3202 ------------------------------|-----+-----+ 3204 11. RADIUS/Diameter Credit-control Interworking 3206 This section defines some basic guidelines to provide the Diameter 3207 Credit-control/RADIUS inter-working, that is a protocol translation 3208 between RADIUS [RFC2865] and Diameter Credit-control application. A 3209 complete description of all protocol translations between RADIUS and 3210 Diameter Credit-control application is beyond the scope of this 3211 document. Note that this document does not restrict implementations 3212 from creating additional methods; it just provides some guiding 3213 principles for protocol translation. Translation makes use of RADIUS 3214 Vendor Specific Attributes (VSAs) for transporting Diameter credit- 3215 control AVPs. 3217 The Diameter NASREQ [NASREQ] application defines how a RADIUS Request 3218 is forwarded as a Diameter Request. Guidelines defined in the Diameter 3219 NASREQ should be followed to the appropriate extent. 3221 A protocol translation between RADIUS and Diameter Credit-control 3222 application is shown in Annex A. 3224 11.1 Initial RADIUS Access-Request 3226 When an AAA server acting as a Translation Agent receives an initial 3227 RADIUS Access-Request message indicating that the service element is 3228 capable of credit-control (e.g. Radius VSA Pre-Paid-Accounting- 3229 Capability), and if the AAA server determines that the subscriber is a 3230 prepaid subscriber then a Diameter Credit control request MUST be sent 3231 towards the credit-control server. 3233 In addition to those steps defined in [NASREQ] the AAA server should 3234 perform the following steps related to the protocol translation 3235 between RADIUS and Diameter Credit-control application: 3237 - The credit control Session-Id should be included in the Session- 3238 Id AVP. 3239 - The CC-Request-Type is set to INITIAL_REQUEST and CC-Request- 3240 Number value is set to 0. 3241 - Subscription-Id should be added using User-Name attribute from 3242 the RADIUS Access-Request message or some AAA server local Id to 3243 identify user's credit control subscription. 3244 - If the Access-Request message contains the Event-Timestamp 3245 attribute it should be included in the Event-Timestamp AVP 3247 The following steps are applied to response the Access-Request message 3248 when successful credit-control answer is received from the Credit- 3249 control server: 3251 - The AAA server shall generate a RADIUS VSA Quota Id to correlate 3252 subsequent RADIUS message with the credit-control session. 3253 - The Termination-Action attribute must be set to be RADIUS-request 3254 to ensure that the used quota is returned by the service element 3255 upon termination of the service. 3256 - If the Granted-Service-Unit AVP including the CC-Time AVP or the 3257 Validity-Time AVP is returned by the credit control server, then 3258 the smallest value should be included in the RADIUS VSA 3259 Duration-Quota. 3260 - If the Granted-Service-Unit AVP including the CC-Total-Octets AVP 3261 is returned by the credit-control server, then the volume should 3262 be included in the RADIUS VSA Volume-Quota. 3263 - If separate RADIUS VSA Thresholds (volume or duration) are 3264 required by RADIUS implementation, the AAA server shall derive 3265 the threshold values from the Granted-Service-Unit AVPs. The 3266 threshold should be less than the Duration-Quota or Volume- 3267 Quota, except when the Final-Unit-Indication AVP is returned by 3268 the credit control server. 3270 When credit-control answer message includes the Result-Code, which 3271 indicates that credit control authorization is rejected, the AAA 3272 server shall send an Access-Reject message to service element. 3274 11.2 Subsequent RADIUS Access-Request message 3276 When an AAA server receives a RADIUS Access-Request message containing 3277 RADIUS VSA Quota Id, it indicates that the Access-Request message is 3278 subsequent RADIUS Request related to the credit control session. The 3279 AAA server shall use the Quota Id to identify the credit-control 3280 session. 3282 The AAA server's next steps depend on the value of the RADIUS VSA 3283 Update-Reason. If the Update-Reason indicates �Threshold reached' then 3284 the AAA server should perform the following steps related to a new 3285 quota request: 3287 - The CC-Request-Type is set to UPDATE_REQUEST and CC-Request-Number 3288 value is increased by one. 3289 - If the Granted-Service-Unit AVP including the CC-Time AVP or the 3290 Validity-Time AVP is returned by the credit control server, then 3291 the smallest value should be included in the RADIUS VSA Duration- 3292 Quota. 3293 - If the Granted-Service-Unit AVP including the CC-Total-Octets AVP 3294 is returned by the credit-control server, then the volume should 3295 be included in the RADIUS VSA Volume-Quota. 3297 The reply to the RADIUS Access-Request message shall be handled as 3298 described in initial Radius Access-Request. 3300 If the RADIUS VSA Update-Reason indicates that the associated 3301 resources are released at the service element, then the AAA server 3302 shall terminate the credit control session by performing the following 3303 steps: 3305 - The CC-Request-Type is set to TERMINATION_REQUEST and CC-Request- 3306 Number value is increased by one. 3308 - If the RADIUS VSA Volume-Quota is present, the value shall be 3309 included in the Used-Service-Unit AVP as CC-Total-Octets. 3310 - If the RADIUS VSA Time-Quota is present, the value shall be 3311 included in the Used-Service-Unit AVP as CC-Time. 3313 After the AAA server receives response to the final credit Control 3314 Credit-Control-Request the RADIUS Access-Accept message shall be 3315 return to the service element. 3317 11.3 RADIUS Vendor Specific Attributes for Credit Control 3319 To provide the credit control for RADIUS implementation the RADIUS 3320 Vendor Specific Attributes (VSAs) are used for transporting Diameter 3321 credit-control AVPs. The RADIUS Type 26 (= Vendor-Specific) is used 3322 for RADIUS VSA. 3324 RADIUS Inter-working with the Diameter Credit control uses the 3325 following VSA included with the RADIUS Access Request and Access 3326 Accept messages: 3328 - Pre-Paid-Accounting-Capability; defines that the Service element 3329 in RADIUS implementation is capable of credit-control. 3330 - Quota Id; generated by the AAA server and it is used to correlate 3331 subsequent RADIUS message with the credit-control session. 3332 - Duration-Quota; in RADIUS Access-Request message it indicates the 3333 used Duration and in RADIUS Access-Accept message it indicates 3334 the Duration allocated for the service element. 3335 - Volume-Quota; in RADIUS Access-Request message it indicates the 3336 used Volume and in RADIUS Access-Accept message it indicates the 3337 Volume allocated for the service element. 3338 - Volume-Threshold; If RADIUS implementation requires separate 3339 threshold attribute for Volume, then Volume-Threshold is sent in 3340 RADIUS Access-Accept message and it represents the volume (in 3341 bytes) that shall be used by the service element before 3342 requesting a new Volume quota. 3343 - Duration-Threshold; If RADIUS implementation requires separate 3344 threshold attribute for Duration, then Duration-Threshold is 3345 sent in RADIUS Access-Accept message and it represents the 3346 duration (in seconds) that shall be used by the service element 3347 before requesting a new Duration quota. 3348 - Update-Reason; in RADIUS Access-Request message it indicates the 3349 reason for the initiating the quota update operation. 3351 12. IANA Considerations 3353 This section contains the namespaces that have either been created in 3354 this specification, or the values assigned to existing namespaces 3355 managed by IANA. 3357 12.1 Application Identifier 3359 This specification assigns the value 4 to the Application Identifier 3360 namespace defined in [DIAMBASE]. See section 1.3 for more information. 3362 12.2 Command Codes 3364 This specification uses the value 272 from the Command code namespace 3365 defined in [DIAMBASE]. 3367 12.3 AVP Codes 3369 This specification assigns the values 411 - 450 from the AVP code 3370 namespace defined in [DIAMBASE] See section 8 for the assignment of 3371 the namespace in this specification. 3373 12.4 Result-Code AVP Values 3375 This specification assigns the values 4010, 4011, 5030 and 5031 from 3376 the Result-Code AVP (AVP Code 268) value namespace defined in 3377 [DIAMBASE]. See section 9 for the assignment of the namespace in this 3378 specification. 3380 12.5 CC-Request-Type AVP 3382 As defined in section 8.3, the CC-Request-Type AVP (AVP code 416) 3383 defines the value 1-3. All remaining values are available for 3384 assignment via Designated Expert [IANA]. 3386 12.6 CC-Session-Failover AVP 3388 As defined in section 8.4, the CC-Failover-Supported AVP (AVP code 3389 418) defines the value 0-1. All remaining values are available for 3390 assignment via Designated Expert [IANA]. 3392 12.7 Check-Balance-Result AVP 3394 As defined in Section 8.6, the Check-Balance-Result AVP (AVP Code 422) 3395 defines the values 0-1. All remaining values are available for 3396 assignment via Designated Expert [IANA]. 3398 12.8 Credit-Control AVP 3400 As defined in section 8.9, the Credit-Control AVP (AVP code 426) 3401 defines the value 0-1. All remaining values are available for 3402 assignment via Designated Expert [IANA]. 3404 12.9 Credit-Control-Failure-Handling AVP 3405 As defined in Section 8.10, the Credit-Control-Failure-Handling AVP 3406 (AVP Code 427) defines the values 0-2. All remaining values are 3407 available for assignment via Designated Expert [IANA]. 3409 12.10 Direct-Debiting-Failure-Handling AVP 3411 As defined in Section 8.12, the Direct-Debiting-Failure-Handling AVP 3412 (AVP Code 448) defines the values 0-1. All remaining values are 3413 available for assignment via Designated Expert [IANA]. 3415 12.11 Final-Unit-Action AVP 3417 As defined in Section 8.14, the Final-Unit-Action AVP (AVP Code 449) 3418 defines the values 0-2. All remaining values are available for 3419 assignment via Designated Expert [IANA]. 3421 12.12 Redirect-Address-Type AVP 3423 As defined in Section 8.17, the Redirect-Address-Type AVP (AVP Code 3424 433) defines the values 0-3. All remaining values are available for 3425 assignment via Designated Expert [IANA]. 3427 12.13 Requested-Action AVP 3429 As defined in Section 8.20, the Requested-Action AVP (AVP Code 436) 3430 defines the values 0-3. All remaining values are available for 3431 assignment via Designated Expert [IANA]. 3433 12.14 Subscription-Id-Type AVP 3435 As defined in Section 8.28, the Subscription-Id-Type AVP (AVP Code 3436 450) defines the values 0-4. All remaining values are available for 3437 assignment via Designated Expert [IANA]. 3439 12.15 Tariff-Change-Usage AVP 3441 As defined in Section 8.42, the Tariff-Change-Usage AVP (AVP Code 452) 3442 defines the values 0-2. All remaining values are available for 3443 assignment via Designated Expert [IANA]. 3445 13. Credit-control Application Related Parameters 3447 Tx timer 3449 When real-time credit-control is required, the credit-control 3450 client contacts the credit-control server before and during the 3451 service is provided to an end user. Due to real-time nature of 3452 application the communication delays SHOULD be minimized, e.g. to 3453 avoid too long service set up time experienced by the end user. The 3454 Tx timer is introduced to control the waiting time in the client in 3455 the PENDING state. When the Tx timer elapses the credit-control 3456 client takes an action to the end user according to the value of 3457 the Credit-Control-Failure-Handling AVP or according to the value 3458 of the Direct-Debiting-Failure-Handling AVP. 3460 The recommended value is 10 seconds. 3462 Tcc timer 3464 The Tcc timer supervises an ongoing credit control session in the 3465 credit control server. It is RECOMMENDED to use the Validity-Time 3466 as input to set the Tcc timer value. To avoid the credit control 3467 session in the Diameter credit control server to change to Idle 3468 state in case of short transient network failure, Tcc MAY be set to 3469 two times the value of Validity-Time. 3471 Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 3473 Client implementations may offer the possibility to locally 3474 configure these AVPs. In such a case their value and behavior is 3475 defined in section 5.6 for the Credit-Control-Failure-Handling and 3476 in section 6.5 for the Direct-Debiting-Failure-Handling. 3478 14. Security Consideration 3480 The Diameter base protocol [DIAMBASE] assumes that each Diameter 3481 implementation uses underlying security, i.e. IPsec or TLS. These 3482 mechanisms are believed to provide sufficient protection under the 3483 normal Internet threat model - that is, assuming the authorized nodes 3484 engaging in the protocol have not been compromised, but the attacker 3485 has complete control over the communication channels between them. 3486 This includes eavesdropping, message modification, insertion, man-in- 3487 the-middle and replay attacks. Note also that this application 3488 includes a mechanism for application layer replay protection by the 3489 means of Session-ID from [DIAMBASE], and CC-Request-Number specified 3490 in this document. The Diameter credit control application is often 3491 used within one domain and there may be just single hop between the 3492 peers. In these environments the use of TLS or IPsec is sufficient. 3493 The details of TLS and IPsec related security considerations are 3494 discussed in the [DIAMBASE]. 3496 Because this application handles monetary transactions (directly or 3497 indirectly) this kind of application increases the interest for 3498 various security attacks. Therefore all parties communicating with 3499 each other must be authenticated, including, for instance, TLS client- 3500 side authentication. In addition to this, authorization of the client 3501 shall be emphasized, i.e. that the client is allowed to perform credit 3502 control for a certain user. The specific means of authorization are 3503 outside of the scope of this specification but can be for instance, 3504 manual configuration. 3506 Another kind threat is malicious modification, injection or deletion 3507 of AVPs or complete credit control messages. The credit control 3508 messages contain sensitive billing related information (such as 3509 subscription Id, granted units, used units, cost information) whose 3510 malicious modification can have economical consequences. Sometimes 3511 simply delaying the credit control messages can cause disturbances in 3512 the credit control client or server. 3514 Even without any modification to the messages an adversary can invite 3515 a security threat by eavesdropping, because the transactions contain 3516 private information about the user. Also by monitoring the credit 3517 control messages one can collect information about credit control 3518 server's billing models and business relationships. 3520 When third party relays or proxy are involved, the hop-by-hop security 3521 does not necessarily provide sufficient protection for Diameter user 3522 session. Diameter messages, such as CCR and CCA, containing sensitive 3523 AVPs may be inappropriate in some cases to be sent via untrusted 3524 Diameter proxy agents since there are no assurance that third party 3525 proxies will not modify the credit control commands or AVP values. 3527 14.1 Direct Connection with Redirects 3529 A Diameter Credit control agent cannot always know whether agents 3530 between it and the end user's Diameter credit control server are 3531 reliable. In this case the Diameter Credit control agent doesn't have 3532 a routing entry in its Diameter Routing Table for the realm of the 3533 Credit Control Server in the end user's home domain. The Diameter 3534 Credit control agent can have a default route configured to a local 3535 Redirect agent and it re-directs the CCR message to the redirect 3536 agent. The local Redirect agent then returns a redirect notification 3537 (Result-code 3006, DIAMETER_REDIRECT_INDICATION) to the Credit control 3538 agent, as well Diameter Credit control Server(s) information 3539 (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) how to 3540 the routing entry resulting from the Redirect-Host is to be used. The 3541 Diameter credit control agent then forwards the CCR message directly 3542 to one of the hosts identified by the CCA message from the redirect 3543 agent. If the value of the Redirect-Host-Usage AVP is unequal than 3544 zero all following messages are sent to the host specified in the 3545 Redirect-Host AVP until the time specified by the Redirect-Max-Cache- 3546 Time AVP is expired. 3548 There are some authorization issues even with redirects. There may 3549 have attacks towards nodes that have been properly authorized, but 3550 abuse their authorization or have been compromised. These issues are 3551 discussed more widely in [DIAMEAP] section 8. 3553 15. References 3555 15.1 Normative 3557 [DIAMBASE] P. Calhoun, J. Loughney, J. Arkko, E. Guttman, G. Zorn. 3558 "Diameter Base Protocol", RFC 3588, September 2003. 3560 [3GPPCHARG] 3rd Generation Partnership Project; Technical 3561 Specification Group Services and System Aspects, Service 3562 aspects; Charging and Billing, (release 5), 3GPP TS 22.115 3563 v. 5.2.1, 2002-03 3565 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, G. 3566 Camarillo, A. Johnston, J. Peterson, R. Sparks 3567 "SIP: Session Initiation Protocol", RFC 3261. June 2002. 3569 [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486. 3570 January 1999. 3572 [E164] Recommendation E.164/I.331 (05/97): The International 3573 Public Telecommunication Numbering Plan. 1997. 3575 [CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List 3576 of ITU-T Recommendation E.164 assigned country codes", 3577 June 2000. 3579 [E212] Recommendation E.212 (11/98): The international 3580 identification plan for mobile terminals and mobile users. 3581 1998. 3583 [CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List 3584 of mobile country or geographical area codes ", February 3585 1999. 3587 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA 3588 Considerations Section in RFCs", BCP 26, RFC 2434, October 3589 1998 3591 15.2 Non-Normative 3593 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 3594 Requirement Levels", BCP 14, RFC 2119, March 1997. 3596 [ACCMGMT] B. Aboba, J.Arkko, D.Harrington. "Introduction to 3597 Accounting Management", RFC 2975, October 2000. 3599 [RFC2866] C. Rigney. "Radius Accounting", RFC 2866, June 2000 3601 [NASREQ] P. Calhoun, G. Zorn, D. Spence, D. Mitton. "Diameter 3602 NASREQ Application", IETF work in progress. 3604 [DIAMMIP] P. Calhoun, T. Johansson, C. Perkins "Diameter Mobile IP 3605 Application", IETF work in progress. 3607 [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson. "Remote 3608 Authentication Dial In User Service (RADIUS), RFC 2865, 3609 June 2000 3611 [DIAMEAP] P. Eronen, T. Hiller, G. Zorn. "Diameter Extensible 3612 Authentication Protocol (EAP) Application", IETF work in 3613 progress. 3615 16. Acknowledgement 3617 The authors would like to thank Bernard Aboba, Robert Ekblad, Benny 3618 Gustafsson, Robert Karlsson, Avi Lior, Paco Marin, Jussi Maki, Jeff 3619 Meyer, Anne Narhi, Juha Vallinen, John Prudhoe, Christopher Richards 3620 and Jari Arkko for their comments and suggestions. 3622 17. Author's Address 3624 Harri Hakala 3625 Oy L M Ericsson Ab 3626 Joukahaisenkatu 1 3627 20520 Turku 3628 Finland 3629 Phone: +358 2 265 3722 3630 EMail: Harri.Hakala@ericsson.com 3632 Leena Mattila 3633 Oy L M Ericsson Ab 3634 Joukahaisenkatu 1 3635 20520 Turku 3636 Finland 3637 Phone: +358 2 265 3731 3638 EMail: Leena.Mattila@ericsson.com 3640 Juha-Pekka Koskinen 3641 Nokia Networks 3642 Hatanpaanvaltatie 30 3643 33100 Tampere 3644 Finland 3646 Phone: +358 7180 74027 3647 Email: juha-pekka.koskinen@nokia.com 3649 Marco Stura 3650 Nokia Networks 3651 Hiomotie 32 3652 00380 Helsinki 3653 Finland 3654 Phone: +358 7180 64308 3655 Email: marco.stura@nokia.com 3657 John Loughney 3658 Nokia Research Center 3659 Itamerenkatu 11-13 3660 00180 Helsinki 3661 Finland 3662 Phone: +358 50 483 642 3663 Email: John.Loughney@nokia.com 3665 18. Full Copyright Statement 3667 Copyright (C) The Internet Society (2003). All Rights Reserved. 3669 This document and translations of it may be copied and furnished to 3670 others, and derivative works that comment on or otherwise explain it 3671 or assist in its implementation may be prepared, copied, published and 3672 distributed, in whole or in part, without restriction of any kind, 3673 provided that the above copyright notice and this paragraph are 3674 included on all such copies and derivative works. However, this 3675 document itself may not be modified in any way, such as by removing 3676 the copyright notice or references to the Internet Society or other 3677 Internet organizations, except as needed for the purpose of developing 3678 Internet standards in which case the procedures for copyrights defined 3679 in the Internet Standards process must be followed, or as required to 3680 translate it into languages other than English. The limited 3681 permissions granted above are perpetual and will not be revoked by the 3682 Internet Society or its successors or assigns. 3684 This document and the information contained herein is provided on an 3685 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3686 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 3687 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 3688 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3689 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3691 19. Notices 3693 The IETF takes no position regarding the validity or scope of any 3694 intellectual property or other rights that might be claimed to pertain 3695 to the implementation or use of the technology described in this 3696 document or the extent to which any license under such rights might or 3697 might not be available; neither does it represent that it has made any 3698 effort to identify any such rights. Information on the IETF's 3699 procedures with respect to rights in standards-track and standards- 3700 related documentation can be found in BCP-11. Copies of claims of 3701 rights made available for publication and any assurances of licenses 3702 to be made available, or the result of an attempt made to obtain a 3703 general license or permission for the use of such proprietary rights 3704 by implementors or users of this specification can be obtained from 3705 the IETF Secretariat. 3707 The IETF invites any interested party to bring to its attention any 3708 copyrights, patents or patent applications, or other proprietary 3709 rights, which may cover technology that may be required to practice 3710 this standard. Please address the information to the IETF Executive 3711 Director. 3713 20. Expiration Date 3715 This memo is filed as and expires 3716 in June 2004. 3718 Appendix A Credit Control sequences 3720 A.1 Flow I 3722 End-User NAS AAA Server CC Server 3723 (CC Client) 3724 |(1)User Logon |(2)AA Request (CC AVPs) | 3725 |------------------>|------------------->| | 3726 | | |(3)CCR(initial, CC AVPs) 3727 | | |------------------->| 3728 | | | (4)CCA(granted Units) 3729 | | |<-------------------| 3730 | |(5)AA Answer(granted Units) | 3731 |(6)Access granted |<-------------------| | 3732 |<----------------->| | | 3733 | | | | 3734 : : : : 3735 | |(7)CCR(update,used Units) | 3736 | |------------------->|(8)CCR | 3737 (update,used units) 3738 | | |------------------->| 3739 | | |(9)CCA(granted Units) 3740 | |(10)CCA(granted Units)<------------------| 3741 | |<-------------------| | 3742 : : : : 3743 | (Auth. lifetime expires) | | 3744 | |(11) AAR (CC AVP) | | 3745 | |------------------->| | 3746 | | (12) AAA | | 3747 | |<-------------------| | 3748 : : : : 3749 : : : : 3750 |(13) User logoff | | | 3751 |------------------>|(14)CCR(term.,used-Units) | 3752 | |------------------->|(15)CCR | 3753 | | | (term.,used-Units) 3754 | | |------------------->| 3755 | | | (16)CCA | 3756 | | (17)CCA |<-------------------| 3757 | |<-------------------| | 3758 | |(18)STR | | 3759 | |------------------->| | 3760 | | (19)STA | | 3761 | |<-------------------| | 3763 Figure A.1: Flow I 3765 A credit control flow for Network Access Services prepaid is shown in 3766 Figure A.1. The Diameter [NASREQ] is implemented in the Network Access 3767 Server (NAS). The focus of this flow is in the credit authorization. 3769 The user logs onto the network (1). The Diameter NAS first sends a 3770 Diameter Authorization-Authentication-Request to the home AAA Server, 3771 the credit-control client populates the AAR with the Credit-Control 3772 AVP set to CREDIT_AUTHORIZATION and service specific AVPs are 3773 included as usual [NASREQ]. The home AAA server performs service 3774 specific Authentication and Authorization as usual. The AAA server 3775 determines that the user is a prepaid user and notices from the 3776 Credit-Control AVP that the NAS has credit control capabilities, it 3777 sends a Diameter Credit-Control-Request with CC-Request-Type set to 3778 INITIAL_REQUEST to the Diameter credit-control server to perform 3779 credit authorization (3) and to establish a credit control session 3780 (the AAA server may forward service specific AVPs as received from 3781 the NAS as input for the rating process). The Diameter credit-control 3782 server checks the end user's account balance, rates the service and 3783 reserves credit from the end user's account. The reserved quota is 3784 returned to the Home AAA server in the Diameter Credit-Control-Answer 3785 (4). The Home AAA server sends the reserved quota to the NAS in the 3786 Diameter Authorization-Authentication-Answer. Upon successful AAA the 3787 NAS starts the credit-control session and starts monitoring the 3788 granted units (5). The NAS grant access to the end user (6). At the 3789 expiry of the allocated quota, the NAS sends a Diameter Credit- 3790 Control-Request with CC-Request-Type set to UPDATE_REQUEST to the 3791 Home AAA server (7). This message contains the units used this far. 3792 The AAA server forwards the CCR to the Diameter credit-control server 3793 (8). The Diameter credit-control server debits the used units from 3794 the end user's account and allocates a new quota that is returned to 3795 the Home AAA server in the Diameter Credit-Control-Answer (9). The 3796 message is forwarded to the NAS (10). During the ongoing credit- 3797 control session the authorization-lifetime expires, the 3798 authorization/authentication client in the NAS performs service 3799 specific re-authorization to the Home AAA server as usual. The 3800 credit-control client populate the AAR with the Credit-Control AVP 3801 set to RE_AUTHORIZATION indicating that the credit-control server 3802 shall not be contacted, since the credit authorization is controlled 3803 by the burning rate of the granted units (11). The Home AAA server 3804 performs service specific re-authorization as usual and returns the 3805 Authorization-Authentication-Answer to the NAS (12). The end user 3806 logs off from the network (13). To debit the used units from the end 3807 user's account and to stop the credit control session, the NAS sends 3808 a Diameter Credit-Control-Request with CC-Request-Type set to 3809 TERMINATION_REQUEST to the Home AAA server (14). The AAA server 3810 forwards the CCR to the credit-control server (15). The Diameter 3811 credit-control server acknowledges the session termination by sending 3812 a Diameter Credit-Control-Answer to the Home AAA server (16). The AAA 3813 server forwards the answer to the NAS (17). STR/STA take place 3814 between NAS and Home AAA server as usual (18-19). 3816 A.2 Flow II 3818 AAA Server 3819 NAS (CC Client) CC Server 3820 |(1) Access-Request | | 3821 |----------------------->| | 3822 | |(2) CCR (initial) | 3823 | |----------------------->| 3824 | |(3) CCA (granted_Units) | 3825 | |<-----------------------| 3826 |(4) Access-Accept | | 3827 | (granted Units) | | 3828 |<-----------------------| | 3829 : : : 3830 |(5) Access-Request | | 3831 | (used Units) | | 3832 |----------------------->| | 3833 | |(6) CCR (update, | 3834 | | used Units, | 3835 | |----------------------->| 3836 | |(7) CCA (granted_Units) | 3837 | |<-----------------------| 3838 |(8) Access-Accept | | 3839 | (granted Units) | | 3840 |<-----------------------| | 3841 : : : 3842 |(9) Access-Request | | 3843 |----------------------->| | 3844 | |(10) CCR (termin., | 3845 | | used Units) | 3846 | |----------------------->| 3847 | |(11) CCA | 3848 | |<-----------------------| 3849 |(12) Access-Accept | | 3850 |<-----------------------| | 3851 | | | 3853 Figure A.2: Flow II 3855 A credit control flow for RADIUS prepaid - Diameter credit control 3856 interworking is shown in Figure A.2. The focus of this flow is in the 3857 AAA Server (Diameter credit-control client) and Diameter credit- 3858 control server interworking. 3860 The NAS first sends a RADIUS Access-Request to the home AAA Server 3861 (1). The home AAA server performs regular Authentication and 3862 Authorization. When the AAA server notices that the user is a prepaid 3863 user it sends a Diameter Credit-Control-Request with CC-Request-Type 3864 set to INITIAL_REQUEST to the Diameter credit-control server to 3865 perform credit authorization (2) and to establish a credit control 3866 session. The Diameter credit-control server checks the end user's 3867 account balance, rates the service and reserves credit from the end 3868 user's account. The reserved quota is returned to the Home AAA server 3869 in the Diameter Credit-Control-Answer (3). The Home AAA server sends 3870 the reserved quota to the NAS in the RADIUS Access-Accept (4). At the 3871 expiry of the allocated quota, the NAS sends a new RADIUS Access- 3872 Request to the Home AAA server (5). This message contains the units 3873 used this far. The units are reported to the Diameter credit-control 3874 server in a Diameter Credit-Control-Request (UPDATE_REQUEST) (6). The 3875 Diameter credit-control server debits the used units from the end 3876 user's account and allocates a new quota that is returned to the Home 3877 AAA server in the Diameter Credit-Control-Answer (7). The quota is 3878 transferred to the NAS in the RADIUS Access-Accept (8). When the end 3879 user terminates the service the NAS sends a RADIUS Access-Request (9). 3880 To debit the used units from the end user's account and to stop the 3881 credit control session, the Home AAA server sends a Diameter Credit- 3882 Control-Request (TERMINATION_REQUEST) to the credit-control server 3883 (10). The Diameter credit-control server acknowledges the session 3884 termination by sending a Diameter Credit-Control-Answer to the Home 3885 AAA server (11). The RADIUS Access-Accept is sent to the NAS (12). 3887 A.3 Flow III 3889 SIP Proxy/Registrar AAA 3890 A (CC Client) Server B CC Server 3891 |(i) REGISTER | | | | 3892 |------------->|(ii) | | | 3893 | |------------->| | | 3894 | |authentication & | | 3895 | |authorization | | | 3896 | |<-------------| | | 3897 |(iii)200 OK | | | 3898 |<-------------| | | 3899 : : : : 3900 |(1) INVITE | : 3901 |------------->| 3902 | |(2) CCR (Intial, SIP specific AVP) | 3903 | |------------------------------------------->| 3904 | |(3) CCA (granted_Units) | 3905 | |<-------------------------------------------| 3906 | |(4) INVITE | | 3907 | |---------------------------->| | 3908 : : : : 3909 | |(5) CCR (update, used Units) | 3910 | |------------------------------------------->| 3911 | |(6) CCA (granted_Units) | 3912 | |<-------------------------------------------| 3913 : : : : 3914 |(7) BYE | | | 3915 |------------->| | | 3916 | |(8) BYE | | 3917 | |---------------------------->| | 3918 | |(9) CCR (termination, used Units)----------| 3919 | |------------------------------------------->| 3920 | |(10) CCA () | 3921 | |<-------------------------------------------| 3922 | | | | 3924 Figure A.3: Flow III 3926 The end user (SIP User Agent A) sends REGISTER with credentials (i). 3927 The SIP Proxy sends a request to the AAA server to perform Multimedia 3928 authentication and authorization by using for instance Diameter 3929 Multimedia application (ii). The AAA server checks that the 3930 credentials are correct and checks the user profile. Eventually, 200 3931 OK response (iii) is sent to the UA. Note that the Authentication and 3932 Authorization is valid for the registration validity period duration 3933 (i.e. until re-registration is performed), of several SIP sessions may 3934 be established without re-authorization is performed. 3936 UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- 3937 Control-Request (INITIAL_REQUEST) to the Diameter credit-control 3938 server (2). The Credit-Control-Request contains information obtained 3939 from the SIP signaling describing the requested service (e.g. calling 3940 party, called party, Session Description Protocol attributes). The 3941 Diameter credit-control server checks the end user's account balance, 3942 rates the service and reserves credit from the end user's account. The 3943 reserved quota is returned to the SIP Proxy in the Diameter Credit- 3944 Control-Answer (3). The SIP Proxy forwards the SIP INVITE to UA B (4). 3945 B's phone rings, and B answers. The media flows between them and the 3946 SIP Proxy starts measuring the quota. At the expiry of the allocated 3947 quota, the SIP Proxy sends a Diameter Credit-Control-Request 3948 (UPDATE_REQUEST) to the Diameter credit-control server (5). This 3949 message contains the units used this far. The Diameter credit-control 3950 server debits the used units from the end user's account and allocates 3951 new credit that is returned to the Sip Proxy in the Diameter Credit- 3952 Control-Answer (6). The end user terminates the service by sending a 3953 BYE (7). The SIP Proxy forwards the BYE message to UA B (8) and sends 3954 a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the Credit- 3955 control server (9). The Diameter Credit-control server acknowledges 3956 the session termination by sending a Diameter Credit-Control-Answer to 3957 the SIP Proxy (10). 3959 A.4 Flow IV 3961 MMS Server 3962 A (CC Client) B CC Server 3963 |(1) Send MMS | | | 3964 |--------------->| | | 3965 | |(2) CCR (event, DIRECT_DEBITING,| 3966 | | MMS specific AVP) | 3967 | |-------------------------------->| 3968 | |(3) CCA (granted_Units) | 3969 | |<--------------------------------| 3970 |(4) Send MMS Ack| | | 3971 |<---------------| | | 3972 | |(5) Notify MMS | | 3973 | |--------------->| | 3974 : : : : 3975 | |(6) Retrieve MMS| | 3976 | |<---------------| | 3977 | |(7) Retrieve MMS| | 3978 | | Ack | | 3979 | |--------------->| | 3980 | | | | 3982 Figure A.4: Flow IV 3984 A credit control flow for Multimedia Messaging Services is shown in 3985 Figure A.4. The sender is charged as soon as the messaging server 3986 successfully stores the message. 3988 The end user A sends a Multimedia Message (MMS) to the MMS Server (1). 3989 The MMS Server stores the message and sends a Diameter Credit-Control- 3990 Request (EVENT_REQUEST with Requested-Action: DIRECT_DEBITING) to the 3991 Diameter credit-control server (2). The Credit-Control-Request 3992 contains information about the MMS message (e.g. size, recipient 3993 address, image coding type). The Diameter credit-control server checks 3994 the end user's account balance, rates the service and debits the 3995 service from the end user's account. The granted quota is returned to 3996 the MMS Server in the Diameter Credit-Control-Answer (3). The MMS 3997 Server acknowledges the successful reception of the MMS message (4). 3998 The MMS Server notifies the recipient about the new MMS (5), and the 3999 end user B retrieves the message from the MMS message store (6),(7). 4001 A.5 Flow V 4003 MMS Server 4004 Content Server (CC Client) B CC Server 4005 |(1) Send MMS | | | 4006 |--------------->| | | 4007 | |(2) CCR (event, BALANCE_CHECK, | 4008 | | MMS specific AVP) | 4009 | |-------------------------------->| 4010 | |(3) CCA (OK) | 4011 | |<--------------------------------| 4012 |(4) Send MMS Ack| | | 4013 |<---------------| | | 4014 | |(5) Notify MMS | | 4015 | |--------------->| | 4016 : : : : 4017 | |(6) Retrieve MMS| | 4018 | |<---------------| | 4019 | |(7) CCR (event, DIRECT_DEBITING,| 4020 | | MMS specific AVP) | 4021 | |-------------------------------->| 4022 | |(8) CCA (granted_Units) | 4023 | |<--------------------------------| 4024 | |(9) Retrieve MMS| | 4025 | | Ack | | 4026 | |--------------->| | 4027 | | | | 4029 Figure A.5: Flow V 4031 A credit control flow for Multimedia Messaging Service is shown in 4032 Figure A.5. The recipient is charged at the message delivery. 4034 A Content Server sends a Multimedia Message (MMS) to the MMS Server 4035 (1) that stores the message. The message recipient will be charged for 4036 the MMS message in this case. Since there can be substantially long 4037 time between the reception of the message at the MMS Server and the 4038 actual retrieval of the message, the MMS Server does not establish any 4039 credit control session to the Diameter Credit-Control Server but 4040 performs first only a balance check (without any credit reservation) 4041 by sending a Diameter Credit-Control-Request (EVENT_REQUEST with 4042 Requested-Action: BALANCE_CHECK) to verify that the end user B's can 4043 cover the cost for the MMS (2). The Diameter credit-control server 4044 checks the end user's account balance and returns the answer to the 4045 MMS Server in the Diameter Credit-Control-Answer (3). The MMS Server 4046 acknowledges the successful reception of the MMS message (4). The MMS 4047 Server notifies the recipient about the new MMS (5), and after some 4048 time the end user B retrieves the message from the MMS message store 4049 (6). The MMS Server sends a Diameter Credit-Control-Request 4050 (EVENT_REQUEST with Requested-Action: DIRECT_DEBITING) to the Diameter 4051 Credit-control server (7). The Credit-Control-Request contains 4052 information about the MMS message (e.g. size, recipient address, 4053 coding type). The Diameter credit-control server checks the end user's 4054 account balance, rates the service and debits the service from the end 4055 user's account. The granted quota is returned to the MMS Server in the 4056 Diameter Credit-Control-Request (8). The MMS is transferred to the end 4057 user B (9). 4059 A.6 Flow VI 4061 SIP Controller 4062 A (CC Client) B CC Server 4063 |(1)INVITE(SDP) | | | 4064 |--------------->| | | 4065 | |(2) CCR (event, PRICE_ENQUIRY, | 4066 | | SIP specific AVPs) | 4067 | |-------------------------------->| 4068 | |(3) CCA (Cost-Information) | 4069 | |<--------------------------------| 4070 | (4)MESSAGE(URL)| | | 4071 |<---------------| | | 4072 |(5)HTTP GET | | | 4073 |--------------->| | | 4074 |(6)HTTP POST | | | 4075 |--------------->|(7)INVITE(SDP) | | 4076 | |--------------->| | 4077 | | (8)200 OK | | 4078 | (9)200 OK |<---------------| | 4079 |<---------------| | | 4081 Figure A.6: Flow VI 4083 Figure A.6 is an example of Advice of Charge (AoC) service for SIP 4084 call, the user A can be either postpaid or prepaid subscriber using 4085 the AoC service. It is assumed that the SIP Controller also has HTTP 4086 capabilities and delivers an interactive AoC web page with for 4087 instance the cost information, the details of the call derived from 4088 the SDP and a button to accetp/not accept the charges (there may be 4089 many other ways to deliver AoC information, however, this flow focus 4090 on the use of the credit control messages). The user has been 4091 authenticated and authorized prior to initiate the call and subscribed 4092 to AoC service. 4094 UA A sends an INVITE with SDP (1). The SIP controller determines the 4095 user is subscribed to AoC service and sends a Diameter Credit-Conrol- 4096 Request (EVENT_REQUEST with Requested-Action: PRICE_ENQUIRY) to the 4097 Diameter credit control server (2). The Credit-Control-Request 4098 contains SIP specific AVPs derived from the SIP signaling describing 4099 the requested service (e.g. calling party, called party, Session 4100 Description Protocol attributes). The Diameter credit control server 4101 determines the cost of the service and returns the Credit-Control- 4102 Answer including the Cost-Information AVP (3). The SIP controller 4103 manufactures the AoC web page with information received in SIP 4104 signaling and with the cost information received from the credit 4105 control server, then sends a SIP MESSAGE that contains a URL pointing 4106 to the AoC information web page (4). At the reception of the SIP 4107 MESSAGE the A's UA invokes automatically the web browser that 4108 retrieves the AoC information (5). The user clicks on a proper button 4109 and accept the charges (6). The SIP controller continues the session 4110 and sends the INVITE to the B party that accepts the call (7,8,9). 4112 A.7 Flow VII 4114 Gaming Server 4115 End-User (CC Client) CC Server 4116 | (1)Service Delivery | | 4117 |<---------------------->| | 4118 : : : 4119 : : : 4120 | |(2)CCR(event,REFUND,Requested- 4121 | |Service-Unit,Service-Parameter-Info) 4122 | |----------------------->| 4123 | | (3)CCA(Cost-Information) 4124 | |<-----------------------| 4125 | (4)Notification | | 4126 |<-----------------------| | 4128 Figure A.7: Flow VII 4130 Figure A.7 illustrates a credit control flow for the REFUND case. It 4131 is assumed that trusted relationship and secure connection between the 4132 Gaming server and the Diameter credit control server exist. The end 4133 user may be a prepaid subscriber or a postpaid subscriber. 4135 While the end user is playing the game (1) she enters a new level that 4136 entitles for a bonus. The Gaming server sends a Diameter Credit- 4137 Conrol-Request (EVENT_REQUEST with Requested-Action: REFUND) to the 4138 Diameter credit control server (2). The Credit-Control-Request 4139 contains the Requested-Service-Unit AVP with Unit-Type set to 4140 CREDIT_TYPE_SERVICE_SPECIFIC and Unit-Value set to the number of 4141 points the user just won. The Service-Parameter-Info AVP is also 4142 included in the request and specifies the service event to be rated 4143 (e.g. Tetris Bonus). The Diameter credit control server, based on 4144 received information, determines the amount to be credited, refunds 4145 the user's account and returns the Credit-Control-Answer including the 4146 Cost-Information AVP (3). The Cost-Information indicates the credited 4147 amount. At the first opportunity the Gaming server notify the end user 4148 of the credited amount (4). 4150 A.8 Flow VIII 4152 SIP Controller Top-UP 4153 A (CC Client) Server B CC Server 4154 | | | | | 4155 | | (1) CCR(Update,Used-Unit) | | 4156 | |------------------------------------------>| 4157 | | (2) CCA(Final-Unit, Redirect)| 4158 | |<------------------------------------------| 4159 : : : : : 4160 : : : : : 4161 | | (3) CCR(Update, Used-Units)| | 4162 | |------------------------------------------>| 4163 | | (3a)INVITE("hold") | | 4164 | |--------------------------->| | 4165 | | | (4) CCA(Validity-Time)| 4166 | |<------------------------------------------| 4167 | (5)INVITE | (6)INVITE | | | 4168 |<--------------|------------->| | | 4169 | (7)RTP | | | 4170 |..............................| | | 4171 | | (8)BYE | | | 4172 | |<-------------| | | 4173 | | (9)CCR(Update) | | 4174 | |------------------------------------------>| 4175 | | (10)CCA(Granted-Unit) | 4176 | |<------------------------------------------| 4177 | (12)INVITE | (11)INVITE | | 4178 |<--------------|--------------------------->| | 4180 Figure A.8: Flow VIII 4182 Figure A.8 is an example of the graceful service termination for a SIP 4183 call. It is assumed the call is set up so that the controller is in 4184 the call as a B2BUA (Back to Back User Agent). Note that the SIP 4185 signaling is inaccurate since the focus of this flow is in the 4186 graceful service termination and credit control authorization. 4188 The call is ongoing between user A and user B, user A is a prepaid 4189 user. At the expiry of the allocated quota, the SIP controller sends a 4190 Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter 4191 credit control server (1). This message contains the units used this 4192 far. The Diameter credit control server debits the used units from the 4193 end user's account and allocates the final quota that is returned to 4194 the SIP controller in the Diameter Credit-Control-Answer (2). This 4195 message contains the Final-Unit-Indication AVP with: the Final-Unit- 4196 Action set to REDIRECT, the Redirect-Address-Type set to SIP URI and 4197 the Redirect-Server-Address set to the Top-up server name (e.g. 4198 sip:sip-topup-server@domain.com). At the expiry of the final allocated 4199 quota, the SIP controller sends a Diameter Credit-Control-Request 4200 (UPDATE_REQUEST) to the Diameter credit control server (3) and places 4201 the called party on "hold" by sending an INVITE with the appropriate 4202 connection address in the SDP (3a). The Credit-Control-Request message 4203 contains the units used this far. The Diameter credit control server 4204 debits the used units from the end user's account but does not make 4205 any credit reservation. The Credit-Control-Answer message, that 4206 contains the Validity-Time to supervise the graceful service 4207 termination, is returned to the SIP controller (4). The SIP controller 4208 establishes a SIP session between the prepaid user and the Top-up 4209 server (5, 6). The Top-up server plays an announcement and prompts the 4210 user to enter a credit card number and the amount of money to be used 4211 to replenish the account (7). The Top-up server validates the credit 4212 card number and replenishes the user's account (using some means 4213 outside the scope of this specification) and releases the SIP session 4214 (8). The SIP controller can now assume that communication between the 4215 prepaid user and the Top-up server took place and thus sends a 4216 spontaneous Credit-Control-Request (UPDATE_REQUEST) to the Diameter 4217 credit control server to check if the account has been replenished 4218 (9). The Diameter credit control server reserves credit from the end 4219 user's account and return the reserved quota to the SIP controller in 4220 the Credit-Control-Answer (10). At this point, the SIP controller re- 4221 connects the caller and the called party (11,12). 4223 A.9 Flow IX 4225 End-User NAS AAA Server Top-up CC Server 4226 (CC Client) Server 4227 |(1)User Logon |(2)AA Request (CC AVPs) | | 4228 |------------------>|------------------->| | | 4229 | | |(3)CCR(initial, CC AVPs) 4230 | | |------------------->| 4231 | | |(4)CCA(Final-Unit, | 4232 | | | Validity-Time)| 4233 | | |<-------------------| 4234 | |(5)AA Answer(Final-Unit,Validity-Time) | 4235 |(6)Limited Access |<-------------------| | | 4236 | granted | | | | 4237 |<----------------->| | | | 4238 | | | | | 4239 | (7)TCP/HTTP | (8)TCP/HTTP | | 4240 |<----------------->|<----------------------------->| | 4241 | (9) Replenish account | | 4242 |<------------------------------------------------->| | 4243 | | | (10)RAR | 4244 | |<-------------------|<-------------------| 4245 | | (11) RAA | | 4246 | |------------------->|------------------->| 4247 | |(12)CCR(update) | | 4248 | |------------------->|(13)CCR(Update) | 4249 | | |------------------->| 4250 | | |(14)CCA(granted Units) 4251 | |(15)CCA(granted Units)<------------------| 4252 | |<-------------------| | 4254 Figure A.9: Flow IX 4256 Figure A.9 is an example of the graceful service termination initiated 4257 when the first interrogation take place due to user's account is 4258 empty. In this example the credit control server supports the server 4259 initiated credit re-authorization. The Diameter [NASREQ] is 4260 implemented in the Network Access Server (NAS). 4262 The user logs onto the network (1). The Diameter NAS first sends a 4263 Diameter Authorization-Authentication-Request to the home AAA Server, 4264 the credit-control client populates the AAR with the Credit-Control 4265 AVP set to CREDIT_AUTHORIZATION and service specific AVPs are included 4266 as usual [NASREQ]. The home AAA server performs service specific 4267 Authentication and Authorization as usual. The AAA server determines 4268 that the user is a prepaid user and notices from the Credit-Control 4269 AVP that the NAS has credit control capabilities, it sends a Diameter 4270 Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to 4271 the Diameter credit-control server to perform credit authorization (3) 4272 and to establish a credit control session (the AAA server may forward 4273 service specific AVPs as received from the NAS as input for the rating 4274 process). The Diameter credit-control server checks the end user's 4275 account balance, determines that the account cannot cover the cost of 4276 the sevice and initiates the graceful service termination. The Credit- 4277 Control-Answer is returned to the Home AAA server (4). This message 4278 contains the Final-Unit-Indication AVP and the Validity-Time AVP set 4279 to a reasonable time to give chance to the user to replenish his/her 4280 account (e.g. 10 minutes). The Final-Unit-Indication AVP includes: the 4281 Final-Unit-Actioin set to REDIRECT, the Redirect-Address-Type set to 4282 ULR and the Redirect-Server-Address set to the HTTP Top-up server 4283 name. The Home AAA server sends the received credit control AVPs to 4284 the NAS in the Diameter Authorization-Authentication-Answer (5). Upon 4285 successful AAA the NAS starts the credit-control session and starts 4286 immediately the graceful service termination as instructed by the 4287 server. The NAS grant limited access to the user (6). The HTTP client 4288 software running in the user's device opens the transport connection 4289 that is redirected by the NAS to the Top-up server (7,8). The user is 4290 displayed an appropriate web page where to enter the credit card 4291 number, the amount of money to be used to replenish the account and 4292 with a notification message that she will be granted unlimited access 4293 if the replenishment operation will be successfully executed within 4294 the next e.g. 10 minutes. The Top-up server validates the credit card 4295 number and replenishes the user's account (using some means outside 4296 the scope of this specification)(9). After successful account top-up 4297 the credit control server sends a Re-Auth-Request message to the NAS 4298 (10). The NAS acknowledges the request by returning the Re-Auth-Answer 4299 message (11) and initiates the credit re-authorization by sending a 4300 Credit-Control-request (UPDATE_REQUEST) to the Diameter credit control 4301 server (12,13). 4303 The Diameter credit control server reserves credit from the end user's 4304 account and return the reserved quota to the NAS via the Home AAA 4305 server in the Credit-Control-Answer (14,15). The NAS removes the 4306 restriction placed by the graceful service termination and starts 4307 monitoring the granted units. 4309 A.10 Flow X 4311 The Diameter Credit Control Application defines the Rating-Group and 4312 Service-Identifier AVPs that can be used to support credit control for 4313 multiple services in a single credit control session for service 4314 elements that have such capabilities. The flow example hereafter 4315 illustrates the usage of these AVPs. 4317 It is assumed that the Service-Identifiers and the Rating-Groups are 4318 locally configured in the Service Element or provisioned by another 4319 entity than the credit control server. 4321 The credit control client may request credit authorization either for 4322 all the possible configured Rating-Groups in one single request, 4323 onwards named all-in-one mode, or for a single Rating-Group upon an 4324 external triggering event, onwards named on-demand mode. The on-demand 4325 mode can be used as well to request individual credit resource limit 4326 for each service. 4328 In this example only the all-in-one mode is shown. 4330 A single credit reservation is kept for the credit control session to 4331 simplify the account management tasks. The credit control server 4332 reserves an amount of credit from the user's account and performs 4333 rating for all the requested Rating-Groups and Service-Identifiers 4334 against the reserved credit. 4336 For instance, assume a Credit-Control-Request is received with Rating- 4337 Group-Id 1 and 2. The credit control server queries the rating server 4338 that answers with the following rating parameters: Rating-Group 1 4339 costs $1/Mbyte and Rating-Group 2 costs $1/minute. The credit control 4340 server reserves $20 from the user's account; this gives 20Mbytes for 4341 Rating-Group 1 and 20minutes for Rating-Group 2. 4343 The calculated quotas are conveyed to the credit control client in the 4344 CCA message, each quota associated with the appropriate Rating-Group 4345 or Service-Identifier. At this point the credit control client just 4346 need to track the fraction of reserved credit used by the 4347 corresponding service or Rating-Group, when the sum of the fractions 4348 reaches 100% the credit control client sends an intermediate 4349 interrogation since the whole amount of reserved credit is consumed. 4351 If the credit control client initializes a counter C for each of the 4352 received quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the 4353 intermediate interrogation will be sent when (C1/Q1 + C1/Q2 + ... + 4354 Cn/Qn)>= 1. 4356 Continuing the example, the end user uses 10 Mbytes from Rating-Group 4357 1 and 10minutes from Rating-Group 2. This means that Rating-Group 1 4358 consumed 50% of the reservation and Rating-Group 2 consumed the 4359 remaining 50%. 0.5 + 0.5 >=1, so the credit control client sends an 4360 intermediate interrogation to report the used units and request new 4361 ones. 4363 Service Element 4364 End-User (CC client) CC Server 4365 |(1)User logon | | 4366 |------------------>|(2)CCR(initial,Requested-Units(Rating-Group 1), 4367 | | Requested-Units(Rating-Group 2)) | 4368 | |---------------------------------------->| 4369 | |(3)CCA(Granted-Units(Rating-Group 1, | 4370 | | Total-Octets)) | 4371 | | Granted-Units(Rating-Group 2, | 4372 | | Time)) | 4373 | |<----------------------------------------| 4374 : : : 4375 |(4)Service-Request (Service 1) | 4376 |------------------>| | 4377 : : : 4378 |(5)Service-Request (Service 2) | 4379 |------------------>| | 4380 : : : 4381 | |(6)CCR(update, Used-Units(Input-Octets, | 4382 | | Output-Octets, | 4383 | | Service-Id 1, | 4384 | | Rating-Group 1), 4385 | | Used-Units(Time, | 4386 | | Service-Id 2, | 4387 | | Rating-Group 2), 4388 | | Requested-Units(Rating-G.1), 4389 | | Requested-Units(Rating-G.2)) 4390 | |---------------------------------------->| 4391 | |(7)CCA(Granted-Units(Rating-Group 1, | 4392 | | Total-Octets), | 4393 | | Granted-Units(Rating-Group 2, | 4394 | | Time)) | 4395 | |<----------------------------------------| 4396 : : : 4397 |(8)Service-Request (Service 3) | 4398 |------------------>| | 4399 : : : 4400 |(9) User logoff | | 4401 |------------------>|(10)CCR(term, Used-Units(Input-Octets, | 4402 | | Output-Octets, | 4403 | | Service-Id 1, | 4404 | | Rating-Group 1),| 4405 | | Used-Units(Input-Octets, | 4406 | | Output-Octets, | 4407 | | Service-Id 3, | 4408 | | Rating-Group 1),| 4409 | | Used-Units(Time, | 4410 | | Service-Id 2, | 4411 | | Rating-Group 2),| 4412 | |---------------------------------------->| 4413 | |(11)CCA(term) | 4414 | |<----------------------------------------| 4416 Figure A.10: Credit Control for Multiple Services in One Credit 4417 Control Session, flow example 4419 The user logs onto the network (1). The Service Element sends a 4420 Diameter Credit-Control-Request with CC-Request-Type set to 4421 INITIAL_REQUEST to the Diameter credit-control server to perform 4422 credit authorization for multiple rating groups and to establish a 4423 credit control session (2). In this message credit authorization is 4424 requested for Rating-Group 1 and Rating-Group 2 by including two 4425 instances of the Requested-Service-Unit AVP. The Diameter credit- 4426 control server checks the end user's account balance, based on the 4427 Rating-Group information rates the request and reserves credit from 4428 the end user's account. Multiple quotas are returned to the Service 4429 Element, each associated with the relevant Rating-Group (3). The user 4430 uses service 1 and service 2 (4, 5). The service 1 belongs to Rating- 4431 Group 1 and is volume based charged, the service 2 belongs to Rating- 4432 Group 2 and is time based charged. When the user has consumed the 4433 allotted credit, the Service Element sends a Diameter Credit-Control- 4434 Request with CC-Request-Type set to UPDATE_REQUEST to the credit 4435 control server (6). This message contains the units consumed by each 4436 of the used services in the Used-Service-Unit AVPs and two instances 4437 of the Requested-Service-Unit AVP to request credit re-authorization 4438 for the two Rating-Groups. The used units are associated with the 4439 relevant Service-Identifier and Rating-Group. 4441 The Diameter credit-control server debits the used units from the end 4442 user's account and reserves a new amount of credit that is returned in 4443 form of multiple quotas to the Service Element in the Diameter Credit- 4444 Control-Answer (7). Each quota is associated with the relevant Rating- 4445 Group. In addition to service 1 and service 2, the user now starts 4446 using service 3 (8). Service 3 belongs to Rating-Group 1 and is 4447 charged based on volume. The end user logs off from the network (9). 4448 To debit the used units from the end user's account and to stop the 4449 credit control session, the Service Element sends a Diameter Credit- 4450 Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the 4451 credit control server (10). 4453 This message contains the units consumed by each of the used services 4454 in the Used-Service-Unit AVPs. The used units are associated with the 4455 relevant Service-Identifier and Rating-Group. The Diameter credit- 4456 control server debits the used units to the user's account and 4457 acknowledges the session termination by sending a Diameter Credit- 4458 Control-Answer to the Service Element (11).