idnits 2.17.00 (12 Aug 2021) /tmp/idnits58047/draft-lior-radius-prepaid-extensions-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'SHALL not' in this paragraph: (n) The PPAQ in which a Cost-Information occurs SHALL NOT include a Quota-Identifier, because no quota is actually reserved by the PPS. The Service-ID SHALL be present with the Cost-Information for that Service-ID may not be present if the Cost-Information cannot be provided. All other attribute SHALL not appear. -- 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 (July 13, 2009) is 4694 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TS32240' is mentioned on line 262, but not defined -- Looks like a reference, but probably isn't: '3576' on line 1228 == Unused Reference: 'RFC3748' is defined on line 2852, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT A. Lior 3 Internet-Draft Bridgewater Systems 4 Intended status: Informational P. Yegani 5 Expires: January 14, 2010 Juniper 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Pashalidis 11 NEC 12 July 13, 2009 14 Prepaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 16 draft-lior-radius-prepaid-extensions-16.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 14, 2010. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents in effect on the date of 48 publication of this document (http://trustee.ietf.org/license-info). 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 Abstract 54 This document specifies an extension to the Remote Authentication 55 Dial-In User Service (RADIUS) protocol that enables service providers 56 to charge for prepaid services. The supported charging models 57 supported are volume-based, duration-based, and based on one-time 58 events. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 8 66 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 10 67 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 68 1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 12 69 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15 70 2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 15 71 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15 72 2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 17 73 2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18 74 2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 19 75 2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20 76 2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 20 77 2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 20 78 2.7.2. Resource Consumption Query . . . . . . . . . . . . . . 21 79 2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 21 80 2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 22 81 2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 22 82 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 23 84 3.2. Authentication and Authorization Operation . . . . . . . . 23 85 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 25 86 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 25 87 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 27 88 3.5.1. Unsolicited Session Termination Operation . . . . . . 27 89 3.5.2. Unsolicited Change of Authorization Operation . . . . 27 90 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 28 91 3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 28 92 3.8. Operation Considerations for Multiple Services . . . . . . 29 93 3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 29 94 3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 30 95 3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 30 96 3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30 97 3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 31 98 3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 31 99 3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31 100 3.8.8. Accounting Considerations . . . . . . . . . . . . . . 32 101 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 33 102 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 33 103 4.2. Session Termination Capability Attribute . . . . . . . . . 35 104 4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 37 105 4.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 53 106 4.5. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 54 107 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 60 108 6. Security Considerations . . . . . . . . . . . . . . . . . . . 61 109 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 62 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 113 10.1. Normative References . . . . . . . . . . . . . . . . . . . 68 114 10.2. Informative References . . . . . . . . . . . . . . . . . . 68 115 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 70 116 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 70 117 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 73 118 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 76 119 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 81 120 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 82 121 A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 83 122 Appendix B. Translation between RADIUS Prepaid and Diameter 123 Credit Control . . . . . . . . . . . . . . . . . . . 85 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94 126 1. Introduction 128 This document specifies an extension to the RADIUS protocol that 129 enables service providers to perform accounting and charging in an 130 "online" fashion. In particular, they enable the service provider to 132 (a) ensure that subscriber's remaining funds suffice before the 133 service is delivered, and 135 (b) interrupt service provision when the funds are exhausted. 137 Note that these capabilities are typically used in scenarios where 138 the subscriber maintains a prepaid account with the service provider; 139 hence, this extension is called the "prepaid" extension for RADIUS. 140 The functionality described in this document is often referred as 141 "online charging" in comparison to "offline charging" support 142 provided by RFC 2866 [RFC2866]. 144 The extensions were designed with the following goals in mind: 146 o Make use of existing infrastructure as much as possible (including 147 enabling the interworking of RADIUS-based and Diameter-based 148 infrastructures), and thereby limit the amount of necessary 149 capital expenditures, 151 o provide the ability to rate service requests in an "online" 152 fashion, 154 o provide the ability to charge the user's account prior to service 155 provision, 157 o protect against revenue loss, i.e., to prevent an end user from 158 obtaining service when the available funds do not suffice, 160 o protect against fraud, and 162 o be deployable for a number of services independent of the access 163 network technology. 165 The architecture between the entities that execute the RADIUS 166 protocols, with the extensions defined in this document, assumes that 167 the rating of chargeable events does not occur in the element that 168 provides the service. Instead, the rating may be performed at a 169 dedicated server, termed the "prepaid-enabled AAA server" or simply 170 "prepaid server" (PPS). Alternatively, the actual rating may occur 171 in an entity related to this prepaid server. 173 Furthermore, this document assumes that a "quota server" is available 174 which, through co-ordination with the rating entity and an account 175 balance manager, is able to provide a quota indication for a 176 particular user when requested. This quota server may or may not 177 coexist in the prepaid server. 179 1.1. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119 [RFC2119]. 185 Prepaid Client (PPC): 187 The entity which triggers the RADIUS message exchange, including 188 the prepaid extensions defined in this document. The PPC provides 189 the service to the users, and executes the RADIUS client which, 190 for the purposes of this document, is termed the "PrePaid Client" 191 (PPC). When the prepaid service is used the PPC collects service 192 event information and reports it while the services is provided to 193 the user. This event information is sent to the PPS using the 194 extensions defined in this document. 196 Prepaid Server (PPS): 198 The entity that interacts with the PPC using the RADIUS prepaid 199 extensions defined in this document. 201 Rating Entity: 203 This entity converts the credit that is allocated by the PPS into 204 a "quota". This quota is then returned to the requesting PPC via 205 the PPS. The rating entity may also determine that during service 206 provision a tariff switch will occur. In this case the rating 207 entity will include details of when exactly tariff switch will 208 occur. 210 Quota: 212 A quota denotes the amount of granted units to be consumed without 213 performing another credit control interaction. 215 Home Network: 217 The network which contains the user profile and the user's prepaid 218 account. 220 Authorize-Only Access Request: 222 A RADIUS message of type "Access Request" (code field = 1) that 223 contains a "Service-Type" AVP (type = 6) with value "Authorize- 224 Only". 226 Offline Charging: 228 Offline charging is a process where charging information for 229 resource usage is collected concurrently with that resource usage. 230 The charging information is then passed through a chain of logical 231 charging functions. At the end of this process, Charging Data 232 Record (CDR) files are generated, which are then transferred to 233 the operator's billing domain for the purpose of subscriber 234 billing and/or inter-operator accounting (or additional functions, 235 e.g., statistics, at the operator's discretion). The billing 236 domain typically comprises post-processing systems, such as the 237 operator's billing system or billing mediation device. In 238 conclusion, offline charging is a mechanism where charging 239 information does not affect, in real-time, the service rendered. 240 [TS32240] 242 Online Charging: 244 Online charging is a process where charging information for 245 resource usage is collected concurrently with that resource usage 246 in the same fashion as in offline charging. However, 247 authorization for the network resource usage must be obtained 248 prior to the actual resource usage to occur. This authorization 249 is granted by the PPS upon request from the PPC. When receiving a 250 resource usage request, the PPS assembles the relevant charging 251 information and generates a charging event in real-time. The PPS 252 then returns an appropriate resource usage authorization. The 253 resource usage authorization may be limited in its scope (e.g., 254 volume of data or duration), therefore the authorization may have 255 to be renewed from time to time as long as the resource usage 256 persists. Note that the charging information utilized in online 257 charging is not necessarily identical to the charging information 258 employed in offline charging. In conclusion, online charging is a 259 mechanism where charging information can affect, in real-time, the 260 service rendered and therefore a direct interaction of the 261 charging mechanism with the control of resource usage is required. 262 [TS32240] 264 1.2. Overview 266 This section provides an overview of the prepaid charging models and 267 architectures, which are supported by the extensions described in 268 this document. 270 A number of models of how to charge customers for services in a 271 prepaid manner are supported: 273 o Volume-based charging (e.g., 2 Cents/KiloByte). 275 o Duration-based charging (e.g., 3 Cents/minute). 277 o Resource-based charging (e.g., 3 videos for 10 Euros) 279 o Event-based charging (e.g., 7 Cents/ring tone) . 281 This draft assumes that the user maintains a prepaid account with his 282 home network. This account may be used to fund multiple services, 283 some of which may use the extensions defined in this document, and 284 some may use other mechanisms. The interworking of these mechanisms 285 is outside the scope of this document. Similarly, the means by which 286 the subscriber obtains funds is also outside the scope of this 287 document. 289 1.2.1. Architectural Model 291 This section describes the architectural model of the protocol 292 extensions described in this document. Figure 1 describes the 293 involved entities. 295 The end user establishes a connection with one of possibly multiple 296 PPCs during service access. The selected PPC communicates with a 297 HAAA server (directly or indirectly via a broker network). 299 The interface between the HAAA and the PPS is implemented using the 300 RADIUS protocol together with the extensions described in this 301 document. However, in cases where the PPS does not implement the 302 RADIUS protocol, the implementation would have to map the 303 requirements defined in this document to a functionally equivalent 304 protocol. 306 The requesting PPC meters the consumption of the service according to 307 the instructions provided by the PPS. After service completion, or 308 on reception of a subsequent request for service, the PPS deducts the 309 corresponding amount of credit from the user account. When a user 310 terminates an on-going service, the PPC informs the PPS with a 311 suitable indication about the unused portion of the allocated quota. 312 The PPS then refunds the user account accordingly. Note that 313 multiple PPSs may be deployed for reasons of redundancy and load 314 sharing. The system may also employ multiple rating servers. 316 Service 317 Access Device Accounting 318 +----------+ +---------+ Protocol +------------+ 319 | End |<---->|+-------+|<------------>| Accounting | 320 | User | +->|| PCC || | Server | 321 | | | || ||<----+ | | 322 +----------+ | |+-------+| | +------------+ 323 | +---------+ | 324 +----------+ | | 325 | End |<--+ | 326 | User | | +----------+ 327 +----------+ +------->| | 328 Prepapid | PPS | 329 Protocol | | 330 +----------+ 332 Figure 1: Basic Prepaid Architecture 334 The PPS and the accounting server in this architecture MAY be 335 combined. The PPC must have the ability to meter the consumption of 336 a prepaid data session. This metering is typically based on time 337 (i.e., seconds) or volume (i.e., octets). 339 The device running the PPC may also have "Dynamic Session 340 Capabilities", such as the ability to terminate a data session or to 341 change the filters associated with a specific data session by 342 processing "Disconnect" messages and "Change of Authorization" 343 messages as per RFC 3576 [RFC3576]. 345 This document assumes that the PPS is used as the AAA server. There 346 are three types of AAA server, as follows. 348 The AAA server in the home network (HAAA) is responsible for 349 authentication of the subscriber. In addition, the HAAA communicates 350 with the PPS using the RADIUS protocol in order to authorize 351 subscribers. 353 This document assumes that the PPS communicates with the HAAA for the 354 purposes of authentication and authorisation. The PPS, in turn, 355 interfaces to entities which 357 o keep the subscriber's account balance (balance manager), 359 o rate access service requests in real-time (rating engine), and 361 o manage quota for a particular prepaid service (quota server). 363 The balance manager, the rating engine and the quota server belong to 364 the service provider's backend infrastructure and are outside the 365 scope of this specification. In particular, as far as this 366 specification is concerned, they are assumed to exist in the PPS. 368 Accounting messages are not needed to deliver a prepaid service. 369 However, accounting messages can be used to keep the PPS up-to-date 370 as to what is happening with the prepaid data session. 372 1.2.2. Motivation 374 Why not use existing RADIUS attributes to construct a protocol for 375 prepaid scenarios? This could lead to a solution where no code has 376 to be modified at existing devices. 378 It is indeed possible to construct a solution for prepaid scenarios 379 using existing RADIUS attributes. The RADIUS server would send an 380 Access-Accept message containing a Session-Timeout(27) and include a 381 Termination-Action(29) in the RADIUS-request. Upon receiving the 382 Access-Accept message, the NAS would meter the duration of the 383 session and upon termination of the session the NAS would generate an 384 Access-Request message again. The RADIUS server would then re- 385 authenticate the session and reply with an Access-Accept message 386 indicating the amount of additional time in a Session-Timeout(27). 387 Alternatively, it could respond with an Access-Reject message if 388 there were no more resources in the user account. 390 Moreover, if the user terminates the session prematurely, the NAS 391 could indicate this in the accounting stream so that unused funds can 392 be returned into the prepaid user account. 394 Unfortunately, the above "solution" has a number of drawbacks, 395 including the following. 397 o It only supports time-based charging. The solution presented in 398 this document supports multiple charging metrics. 400 o Using accounting messages to recoup unused time may be problematic 401 because RADIUS accounting messages are not delivered in real-time. 402 A RADIUS server may store-and-forward accounting messages in 403 batches. Thus, relying on accounting messages for the purposes of 404 prepaid may cause revenue leakage. The solution presented in this 405 document does not rely on Accounting packets at all. It uses 406 Access-Request messages, which are required to flow through any 407 network in real-time. 409 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 410 subscriber is served by a NAS that does not adhere to Session- 411 Timeout then that subscriber may use the service for an 412 undetermined period of time. 414 o Termination-Action(29) presents its own issues. Firstly, the 415 behaviour of Termination-Action(29) is not mandatory. Secondly, 416 according to RFC 2865 [RFC2865], Termination-Action fires when the 417 provision of the service has completed. However, service should 418 not be terminated when negotiating additional quota, because this 419 should happen in a manner transparent to the subscriber. Due to 420 the fact that Termination-Action occurs when the service is 421 completed, it is unclear whether or not user experience would be 422 affected if this attribute would be used in a prepaid scenario. 423 The RADIUS server might even allocate a new IP address to the 424 subscriber device after a Termination-Action. Also, the RADIUS 425 server has no way of telling why a given Access-Request message 426 was generated. The RADIUS server might have to wait for the 427 corresponding accounting packet to determine the reason. Finally, 428 re-authenticating the subscriber may take too long. The solution 429 presented in this document allows quota replenishing to occur 430 without affecting user experience. No re-authentication is 431 required and quotas can be negotiated before the available credit 432 actually runs out. 434 o Due to the fact that the standard RADIUS attributes are not 435 mandatory, the correct prepaid operation is really an act of faith 436 on the part of the RADIUS server. If Session-Timeout(27) and/or 437 Termination-Action(29) are not supported, the prepaid subscriber 438 might be able to obtain the service for free. The solution 439 described in this document requires that a PPC informs the RADIUS 440 server, regardless of whether or not the latter supports the 441 prepaid extensions. The RADIUS server can then determine whether 442 or not service should be granted. For example, if a prepaid 443 subscriber is connected to a NAS that does not support prepaid, 444 the RADIUS server can either instruct the NAS to tunnel the 445 traffic to another entity in the home network (e.g., an Home 446 Agent) that supports prepaid, or cause it to provide only a 447 restricted service. 449 The solution presented in this document requires the support of two 450 mandatory and one optional attribute. Furthermore, it does not 451 require a great amount of additional code at a NAS (or similar 452 device) that already supports time or volume-based metering. The 453 solution requires that RADIUS entities advertise their prepaid 454 capabilities in an Access-Request and that they generate an Access- 455 Request packet with Service-Type="Authorize-Only" in order to obtain 456 more quota when or before the current quota is used up. It also 457 requires the NAS to send an Access-Request with Service- 458 Type="Authorize-Only" when the session terminates in order to refund 459 the subscriber account. 461 1.3. Assumptions 463 This document makes the following assumptions. 465 o The values carried in the Service Identifiers are pre-configured 466 between the PPC and the PPS. 468 o The decision about the service rating happens at the PPS. 470 o The decision whether credit control requests for two services are 471 placed in a resource pool are made by the PPS. 473 o The decision which services belong to the same rating group are 474 pre-configured at the PPC. Once a rating group is authorized it 475 is not necessary to re-authorize an additional service that 476 belongs to the same rating group at the PPS again. 478 o A price enquiry is done purely for the purpose of providing AoC 479 for the end user, not for processing at the PPC nor to trigger any 480 specific actions. 482 1.4. Example Use Case 484 This section describes the sequence of events in an example RADIUS 485 prepaid transaction. 487 1. When an end host attaches to a network (for example, using IEEE 488 802.1X), as usual, the PPC that is servicing the subscriber uses 489 the AAA infrastructure in order to authenticate and authorize the 490 subscriber with respect to the requested service. In order to do 491 this, it sends a RADIUS Access-Request to the AAA server. This 492 Access-Request contains the subscriber's credentials and may 493 contain the prepaid capabilities of the PPC. 495 2. The authentication procedure proceeds. This may involve several 496 message exchanges, as it is the case with the Extensible 497 Authentication Protocol (EAP) [RFC2284]. Once the subscriber has 498 been successfully authenticated, the home AAA server determines 499 that the subscriber is a prepaid subscriber and requests 500 authorisation from the PPS. This request MUST include the 501 prepaid capabilities of the serving PPC. 503 3. The PPS, possibly with the help of the backend infrastructure, 504 validates that the subscriber has a prepaid account and that the 505 account is active. It further validates that the PPC has the 506 appropriate prepaid capabilities. If all is in order, the PPS 507 authorises the subscriber to use the network. Otherwise it 508 rejects the request. The decision is sent to the AAA system in 509 the form of a response message. In the case of success, this 510 message contains attributes that indicate the allocation of a 511 portion of the subscriber credit. This portion is called the 512 "initial quota" and is expressed in units of time or volume. The 513 response may also include a threshold value. Note that only a 514 portion of the user's funds is allocated because the user may be 515 engaged in other services that may draw on the same account. For 516 example, the user may be engaged in a data session and a voice 517 session. Although these two services would draw from the same 518 account, they form separate parts of the overall system. If the 519 entire quota was allocated to the data session then the user 520 would have no more funds for a voice session. 522 4. The AAA system incorporates the attributes received from the PPS 523 into an Access-Accept message that it sends to the PPC. Note 524 that the AAA system is responsible for authorizing the service 525 whereas the prepaid system is responsible for prepaid 526 authorization. 528 5. Upon receiving the Access-Response, the PPC starts the prepaid 529 data session and meters the session based on time or volume, as 530 indicated in the message. 532 6. Once the consumption approaches the allocated limit (as expressed 533 by the threshold), the PPC will request additional quota. Re- 534 authorization for additional quota flows through the AAA system 535 to the PPS. The PPS revalidates the subscriber account and 536 subtracts the previously allocated quota from the current 537 balance. If there is remaining balance, it reauthorizes the 538 request with an additional quota allotment. Otherwise, the PPS 539 rejects the request. Note that the replenishment of the quota is 540 a re-authorization procedure and does not require the subscriber 541 to authenticate himself again. 543 7. Upon receiving a re-allotment of the quota, the PPC continues to 544 provide the requested service until the new threshold is reached. 545 If the request for additional quota cannot be fulfilled then the 546 PPC lets the subscriber use the remaining quota and terminates 547 the session. Alternatively, instead of terminating the session, 548 the PPC may restrict service access in such a way that the 549 subscriber can only reach a particular web server. This web 550 server maybe used to allow the subscriber to replenish his 551 account. This restriction can also be used to allow new 552 subscribers to set up prepaid accounts in the first place. 554 8. Should the subscriber terminate the session before the quota is 555 exhausted, the remaining balance allotted to the session is 556 refunded into his account. 558 Note that the subscriber may have disconnected while the PPC is 559 waiting for the initial quota. The entire allocated quota will have 560 to be credited back to the subscribers account in this case. Also 561 note that the PPS maintains session state for the subscriber. This 562 state includes how much account balance was allocated during the last 563 quota enquiry and how much is left in the account. Therefore, it is 564 required that all messages about the session reach the same (and 565 correct) PPS. 567 For a simple message flow, along the lines of this use case, please 568 see Appendix A. 570 2. Supported Features 572 This section describes the features that are supported by the 573 extensions specified in this document. 575 2.1. Services and Quotas 577 Examples of services that the user may be using are browsing the web, 578 participating in a VoIP conversation, watching streaming video and 579 downloading a ring tone. Some operators may want to distinguish 580 between these services and to charge them at different rates and 581 meters them differently. Therefore, the prepaid solution needs to be 582 able to distinguish services, and allocate quota to the services 583 using different unit types (time, volume) and allow for those quotas 584 to be consumed at different rates. 586 +---------+ +---------+ +-------+ 587 | | 1 N | | 1 1 | | 588 | Session |<---------->| Service |<---------->| Quota | 589 | | | | | | 590 +---------+ +---------+ +-------+ 592 Figure 2: Multiple services within a single session 594 As shown in Figure 2, a session may be associated with multiple 595 services. Each service is identified by a service identifier 596 (Service-ID). The format of the Service-ID is not in the scope of 597 this document. It may, for example, be expressed as a 5-tuple {i.e., 598 source IP address, destination IP address, source port, destination 599 port, and protocol type}. Each service is associated with a quota 600 whereby a quota might be applicable to multiple services. An example 601 message flow that involves multiple services within a single session 602 is given in the Appendix A. 604 2.2. Resource Pools 606 When working with multiple services a new problem arises because one 607 service may consume its quota faster than another service. When the 608 user balance is close to exhaustion, a situation could arise where 609 one service is unable to obtain quota while another service has 610 plenty of quota remaining. Unless the quotas can be rebalanced, the 611 SAD would then have to terminate the former service. Moreover, it is 612 likely that each service generates a certain amount of RADIUS prepaid 613 traffic. In an environment with many users and charged services, 614 this amount of traffic may become a considerable overhead that could 615 lead to inefficiency. 617 One method to circumvent the above situation is to use a so-called 618 "resource pool". Resource pools enable the allocation of resources 619 to multiple services of a session by allocating resources to a pool 620 and have services draw their quota from the pool at a rate 621 appropriate to that service. When the quota that has been allocated 622 to the pool is close to exhaustion, the entire pool (rather than 623 individual services) is replenished. 625 +-----------+ 626 | Service-A |-----+ +--------+ 627 +-----------+ | Ma | | 628 +-------->| | 629 | Pool | 630 +-------->| (1) | 631 +-----------+ | Mb | | 632 | Service-B |-----+ +--------+ 633 +-----------+ 635 Figure 3: Resource pool example 637 As shown in Figure 3, Service-A and Service-B are bound to Pool(1). 638 Ma and Mb are the pool multipliers (that are associated with 639 Service-A and Service-B respectively) that determine the rate at 640 which Service-A and Service-B draw from the pool. 642 The pool is initialized by taking the quota allocated to service n 643 and multiplying it by Mn. Therefore, the amount of resources 644 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 645 Qn denotes the amount of quota that is allocated to service n. 646 Further, the pool is considered to be empty if 648 Poolr <= Ca*Ma + Cb*Mb + . . ., 650 Figure 4 652 where Ca and Cb are resources consumed by Service-A and Service-B 653 respectively. 655 Note that the resources assigned to the pool are not associated with 656 a metric. That is, Service-A can be rated at $1 per MB and Service-B 657 can rated at $0.10 per minute. In this case, if $5 worth of 658 resources are allocated for service-A to the pool and if Ma = 10, 659 then 50 units would be placed into the pool. If a further $5 are 660 allocated for service-B to the pool, then M=1 and 50 units are 661 deposited into the pool. The pool would then have a total sum of 100 662 units to be shared between the two services. The PPC would then 663 mater the services such that each Mbyte used by Service-A will draw 664 10 units from the pool and each minute used by Service-B will draw 1 665 unit from the pool. 667 2.3. Rating Groups 669 A Rating Group gathers a set of services, identified by a service 670 identifier, and subject to the same cost and rating type (e.g., $0.1/ 671 minute). 673 The rating of a service can be quite complex. While some operators 674 follow linear pricing models, others may wish to apply more complex 675 functions. For example, a service provider may wish to rate a 676 service such that the first N MBytes are free, then the next M Mbytes 677 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 678 per MB. Such a function could be implemented by repeated message 679 exchanges in the prepaid system. 681 To avert the need to exchange many messages while still supporting 682 such complex rating functions, the concept of the Rating Group was 683 introduced. 685 As shown in Figure 5, a Rating Group is associated with one or more 686 services and defines the rate that the services associated with the 687 Rating Group consume an allocated amount of quota. 689 +--------------+ +--------------+ 690 +-----------+ N 1 | | M 1 | Resource Pool| 691 | Service-A +---------->| Rating Group |------>| or | 692 +-----------+ | | | Quota | 693 +--------------+ +--------------+ 695 Figure 5: Rating Group 697 During the usage of a service that is associated with a Rating Group, 698 the PPC sends the ID of the Rating Group to the PPS. The PPS 699 authorises the Rating Group by allocating a quota to it and assign it 700 to a Resource Pool. When an additional service that belongs to an 701 already authorised Rating Group is instantiated, the PPC does not 702 need to re-authorize this service. This effectively means that the 703 PPC meters the service such that it draws from the already allocated 704 quota. Therefore, no RADIUS messages need to be exchanged in this 705 case. This limits the amount of traffic between the PPC and the PPS. 706 An example of a flow that uses Rating Groups is given in Appendix A.3 708 2.4. Tariff Switching 710 Tariff is the set of parameters defining the utilization charges for 711 the use of a particular service. 713 This mechanism is useful if, for example, as shown in Figure 6, 714 traffic before 18:00 is rated at rate r1 and traffic after 18:00 is 715 rated at rate r2. The mechanism requires the PPC to report usage 716 before and after the switch occured. 718 18:00 719 ------------------+----------------- 720 r1 | r2 721 ------------------+----------------- 722 ^ ^ 723 |<----TSI---> | 724 | | 725 Access-Accept Access-Request 726 (quota allocated) (quota consumed) 728 Figure 6: Example of Tariff Switching 730 The PPC indicates support for tariff switching by setting the 731 appropriate bit in the PPAC. If the PPS needs to signal a tariff 732 switch time it will send a PTS attribute that indicates the point in 733 time when the switch will occur. This indication represents the 734 number of seconds from current time (TariffSwitchInterval TSI). 736 At some point after the tariff switch the PPC sends another Access- 737 Request, as a result of either the user having logged off or the 738 volume threshold being reached. The PPC reports how much volume was 739 used in total (in a PPAQ attribute) and how much volume was used 740 after the tariff switch (in a PTS VUATS subtype attribute). 742 In situations with multiple tariff switches, the PPS has to specify 743 the length of the tariff switch period using the 744 TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS 745 attribute, as shown in Figure 7. 747 18:00 23:30 748 ------------------+---------------------+-------------- 749 r1 | r2 | r3 750 ------------------+---------------------+-------------- 751 ^ ^ ^ 752 |<----TSI---><-----------|-------->|TITSU 753 | | 754 Access-Accept Access-Request 756 Figure 7: Multiple Tariff Switches 758 When a TITSU is specified in the PTS, the PPC MUST generate an 759 Access-Request within the time after TSI and before TITSU expires. 760 Note that, typically, the PPC will be triggered by the Volume 761 Threshold. However, it is possible that, during period r2, resources 762 are not entirely consumed and, thus, the threshold is not reached. 763 The TITSU attribute ensures that, even in this case, the PPC will 764 generate the new Access-Request in good time. 766 For time based services, the quota is continuously consumed at the 767 regular rate of 60 seconds per minute. At the time when credit 768 resources are allocated, the server already knows how many units will 769 be consumed before the tariff time change and how many units will be 770 consumed afterward. Similarly, the server can determine the units 771 consumed at the before rate and the units consumed at the rate 772 afterward in the event that the end user closes the session before 773 the consumption of the allotted quota. There is no need for 774 additional traffic between the PPC and the PPS in the case of tariff 775 time changes for continuous time based service. Therefore, the 776 tariff change mechanism is not used for such services. For time- 777 based services in which the quota is not continuously consumed at a 778 regular rate, the tariff change mechanism described for volume and 779 event units may be used. 781 2.5. Support for Roaming 783 In certain networks it is essential for prepaid data services to be 784 available to roaming subscribers. Support for both static and 785 dynamic roaming models is needed. In a static roaming scenario the 786 subscriber connects to a foreign network which has a roaming 787 agreement either directly with the home network, or through a broker 788 network. When the subscriber logs into another foreign network, a 789 new login procedure has to be executed. 791 In a dynamic roaming scenario the subscriber may move between 792 networks while maintaining his connection. In such a scenario the 793 data session is seamlessly handed off between the networks. 795 In both roaming scenarios, the subscriber always authenticates 796 himself to the home network. Authorization for the prepaid session 797 and quota replenishing occurs at the home network and more 798 specifically at the PPS where state is being maintained. 800 Roaming is challenging because a subscriber who established a prepaid 801 data session may move to another PPC that does not support the 802 prepaid extensions. 804 2.6. Dynamic Termination 806 When fraud or an error is detected, either only the affected session, 807 or all sessions of the affected subscriber should be immediately 808 terminated. Under certain conditions, the system may wish to 809 terminate the session in order to make sure that the user is not 810 charged for services it does not use. 812 Certain handoff procedures used in dynamic roaming scenarios require 813 that the system terminates the subscribers prepaid data session at a 814 PPC. This is the case, for example, when time-based prepaid is used 815 and the mobile subscriber performs a dormant handoff. 817 2.7. One Time Event 819 2.7.1. One-Time Charging 821 One-time charging is a mode of operation where the RADIUS prepaid 822 extensions are used for charging of a service that is provided 823 instansteneously. An example of such an event is the purchase of a 824 ring tone. Subscription based services can also be modeled as a one- 825 time event. In this case the one-time service event is the purchase 826 of a subscription. 828 For a given user, one-time charging may occur in parallel with other 829 charging models. For example, the subscriber may be connected to the 830 Internet, which is metered (based on time or volume), while he also 831 purchases a ring tone (a one-time-based event). 833 Note that it is up to the service providers to decide whether or not 834 the user will be charged for the download of, for example, the video 835 and also be charged for the data volume required to download the 836 video. The facilities provided by this document gives the service 837 provider the capability to achieve their service charging business 838 goals. 840 The PPC signals one-time charging to the PPS with an indication that 841 identifies the service and the units that should be debited from the 842 user account. 844 A PPC may decide to perform one-time charging and the PPC may need to 845 authenticate the user before sending the relevant message to the 846 user's home AAA server (and to the PPS). 848 Note that one-time charging can also be used to credit the prepaid 849 account. For example, the PPC can return resources to the subscriber 850 by issuing a one-time charging request that includes the amount of 851 resources to be credited into the account. 853 2.7.2. Resource Consumption Query 855 It should be possible for the PPS to query the PPC for the current 856 resource consumption and to adjust the users account balance. For 857 example, a request to the PPS is made (e.g., a one-time charging 858 event), the account is depleted and resources have been allocated to 859 the PPC. The PPS should have the ability to query the PPC and, if it 860 has the spare resources, to reassign the quotas to the PPC and to the 861 pending request. Note that the PPS does not know resource usage 862 until the PPC request for more resources. This can be a long time. 864 In the absence of this capability the PPS can minimize the effect of 865 this phenomenon by allocating small quotas, a practice that results 866 in more message exchanges. 868 2.7.3. Service Price Enquiry 870 The PPC may need to know the price of the service event. Services 871 offered by application service providers whose prices are not known 872 in the PPC might exist. The end user might also want to get an 873 estimation of the price of a service event before requesting it. 875 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 876 with the value set to "Price Enquiry" (2). The request includes 877 enough information to identify the service, namely a Service- 878 Identifier or a Rating-Group-Identifer. 880 The PPS calculates the cost of the requested service event, but it 881 does not perform any account balance check or credit reservation from 882 the account. 884 The estimated cost of the requested service event is returned to the 885 PPS with a PPAQ in the Cost-Information SubType. The PPC may 886 transfer the information to the end user as an advice of charge. 888 More information regarding the price enquiry functionality is 889 provided in Section 4.3.15 and in Section 4.3.17. 891 2.7.4. Balance Check 893 The PPC may only have to verify that the end user's account balance 894 covers the cost of a certain service without reserving any units from 895 the account at the time of the inquiry. This method does not 896 guarantee that credit would be left when the PPC requests the 897 debiting of the account with a separate request. 899 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 900 with the value set to "Balance Check" (1). The request includes 901 enough information to identify the service, namely a Service- 902 Identifier or a Rating-Group-Identifer. 904 The PPS makes the balance check, but it does not make any credit- 905 reservation from the account. 907 The result of balance check, namely "Success" (1) or "Failure" (2), 908 is returned to the PPC in the Check-Balance-Result SubType conveyed 909 in the PPAQ attribute from the PPS to the PPC. 911 More information regarding the balance check functionality is 912 provided in Section 4.3.15 and in Section 4.3.16. 914 2.7.5. Refund 916 Some services may refund service units to the end user's account; for 917 example, gaming services. 919 To initiate refunding the PPC includes the PPAQ attribute in an 920 Access-Request packet and the amount (as a negative value) to be 921 refunded is specified using the Resource Quota and Resource Quota 922 overflow subtypes. This functionality is similar to one-time 923 charging with the difference that refunding uses negative values 925 Information about the service need to be provided by the PPC to allow 926 service identification, namely the Service-ID field of the PPAQ 927 identifies the prepaid service. 929 Note that a monetary amount itself to be refunded is not provided but 930 rather abstract units. Based on prior out-of-band agreements between 931 the PPC and the PPS these abstract units are translated into a 932 monetary amount. 934 More information regarding the refund functionality is provided in 935 Section 3.8.6. 937 3. Operations 939 This section contains the normative text for the prepaid extension. 941 3.1. Capability Discovery 943 The PPC initiates the authentication and authorization procedure by 944 sending a RADIUS Access-Request to the HAAA. Since the PPC MUST 945 include a PPAC attribute in the RADIUS Access-Request. The PPAC 946 attribute indicates to the PPS which prepaid capabilities are 947 possessed by the PPC. These are required in order to complete the 948 prepaid authorization procedure.Moreover, if the PPC supports the 949 Disconnect-Message or the Change-of-Authorization capabilities, then 950 it SHOULD include the Session Termination attribute. 952 In certain deployments, there may be other ways to terminate a data 953 session, or change authorization of an active session. For example, 954 some PPCs provide a session termination service via Telnet or SNMP. 955 In these cases, the AAA server MAY add the Dynamic-Capabilities 956 message to the Access-Request. Upon receiving the Change-of- 957 Authorization message, the AAA server would then be responsible for 958 terminating the session using the means that are supported by the 959 device. 961 If the authentication procedure involves multiple message exchanges 962 (as it is the case with EAP), the PPC MUST include the PPAC attribute 963 in at least the last Access-Request of the authentication procedure. 965 3.2. Authentication and Authorization Operation 967 Once the Access-Request arrives at the HAAA, the HAAA authenticates 968 the subscriber. If this fails, the HAAA sends an Access-Reject 969 message to the client. If authentication succeeds, the HAAA 970 determines whether or not the subscriber is a prepaid subscriber. If 971 the subscriber is not a prepaid subscriber, then the HAAA responds as 972 usual with an Access-Accept or an Access-Reject message. If the 973 subscriber is a prepaid subscriber then the HAAA MAY forward the 974 Access-Request to the PPS for further authorization. 976 The Access-Request contains the PPAC attribute and the Dynamic- 977 Capabilities attribute if one was included. The User-Name(1) 978 attribute MAY be set to a value that identifies the subscriber. This 979 attribute is used by the PPS to locate his account. For added 980 security, the HAAA MAY also set the User-Password(2) attribute to the 981 password used between the HAAA and the PPS. 983 The PPS locates the subscriber account and authorizes him. During 984 this procedure, the PPS takes into consideration the PPCs 985 capabilities. Upon successful authorization, the PPS generates an 986 Access-Accept containing an PPAC attribute and an PPAQ attribute. 987 The PPAC attribute returned to the client indicates the type of 988 prepaid service to be provided for the session. The PPAQ attribute 989 includes the following information. 991 o The QID, which is set by the PPS to a unique value, is used to 992 correlate quota requests. 994 o Volume and/or Time quota, which is set to a value representing a 995 portion of the subscriber's credit. 997 o Time or Volume Threshold that indicates when the PPC should 998 request additional quota. This information is optional. 1000 o The IP address of the serving PPS and one or more alternative 1001 PPSs. This is used by the HAAA to route subsequent quota 1002 replenishing messages to the appropriate PPS(s). 1004 o A State attribute, as defined in RFC 2865 [RFC2865]. This is 1005 necessary in order to satisfy the requirements of Section 5.44 of 1006 RFC 2865 [RFC2865], which mandates that an Access-Request with 1007 Service-Type="Authorize-Only" must contain a State attribute. 1008 Since the PPC sends subsequent quota replenishment requests in the 1009 form of such "Authorize-Only" requests, a State attribute MUST be 1010 present in all Access-Accept messages that also carry a PPAQ 1011 attribute. 1013 Note: The Idle-Timeout(28) attribute can be used to trigger the 1014 premature termination of a prepaid service, for example as a result 1015 of inactivity. 1017 Depending on site policies, after failed authorization, the PPS may 1018 generate an Access-Reject in order to terminate the session 1019 immediately. Alternatively, the PPS may generate an Access-Accept 1020 blocking some or all of the traffic and/or redirect some or all of 1021 the traffic to a location to a fixed server. (This feature could be 1022 used, for example, to prompt the user to replenish their account.) 1023 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 1024 Filter-Rule (see [RFC4849]). A description of the redirect 1025 functionality is outside the scope of this document. The time period 1026 before the session is blocked/redirected is specified by the Session- 1027 Timeout(27) attribute. 1029 Upon receiving an Access-Accept from the PPS, the HAAA appends the 1030 usual service attributes and forward the packet to the PPC. The HAAA 1031 SHOULD NOT overwrite any attributes already set by the PPS. If the 1032 HAAA receives an Access-Reject message, it will simply forward the 1033 packet to its client. Depending on site policies, if the HAAA does 1034 not receive an Access-Accept or an Access-Reject message from the PPS 1035 it MAY do nothing or send an Access-Reject or an Access- Accept 1036 message back to the PPC. 1038 3.3. Session Start Operation 1040 The start of the session is indicated by the arrival of an 1041 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 1042 be routed to the PPS such that it can confirm the initial quota 1043 allocation. 1045 Note that the role of the PPS is not to record accounting messages 1046 and therefore it SHOULD NOT respond with an Accounting Response 1047 packet. If the PPS does not receive the Accounting-Request(start) 1048 message it will only know that the session has started upon the first 1049 reception of a quota replenishment operation. 1051 If the PPS does not receive indication directly (via Accounting- 1052 Request(start)) or indirectly, it SHOULD, after some configurable 1053 time, deduce that the session has not started. If the PPC supports 1054 termination capabilities, the PPS SHOULD send a Disconnect Message to 1055 the PPC as a measure to ensure that the session is indeed dead. 1057 3.4. Mid-Session Operation 1059 During the lifetime of a prepaid data session the PPC may request the 1060 replenishment of the quotas using an Authorize-Only Access-Request 1061 message. Once either the allocated quota has been exhausted or the 1062 threshold has been reached, the PPC MUST send an Access-Request with 1063 Service-Type(6) set to a value of "Authorize-Only" and the PPAQ 1064 attribute. 1066 The PPC MUST also include NAS identifiers, and Session Identifier 1067 attributes in the Authorize-Only Access-Request. The Session 1068 Identifier should be the same as the one used during the initial 1069 Access-Request. For example, if the User-Name(1) attribute was used 1070 in the Access-Request it has to be included in the Authorize-Only 1071 Access-Request as well, especially if the User-Name(1) attribute is 1072 used to route the Access-Request to the Home AAA server. 1074 The Authorize-Only Access-Request MUST NOT include a User Password 1075 and MUST NOT include a CHAP Password. In order to enable the 1076 receiver to authenticate the message, the PPC MUST include a Message- 1077 Authenticator(80). In order to satisfy the requirements of Section 1078 5.44 of RFC 2865 [RFC2865], the PPC MUST also include the State 1079 attribute. It is anticipated that the inclusion of the State 1080 attribute will enable the PPS to map the Authorize-Only Access 1081 Request to the authentication context that was established when the 1082 PPC authenticated itself at the beginning of the session. The PPC 1083 computes the value for the Message-Authenticator and the State 1084 attributes according to RFC 2869 [RFC2869] and RFC 2865 [RFC2865] 1085 respectively. 1087 When the HAAA receives an Authorize-Only Access-Request that contains 1088 a PPAQ, it validates the message using the Message-Authenticator(80), 1089 according to RFC 2869. If the HAAA receives an Authorize-Only 1090 Access-Request that contains a PPAQ and either no or an invalid 1091 Message-Authenticator(80) it SHALL silently discard the message. An 1092 Authorize Only Access-Request message that does not contain a PPAQ is 1093 either erroneous or belongs to another application (for example, a 1094 Change of Authorization message [RFC3576]). In this case the 1095 Authorize-Only Access-Request is either silently discarded or handled 1096 by another application. 1098 Once the Authorize-Only Access-Request message is validated, the HAAA 1099 SHALL forward the Authorize-Only Access-Request to the appropriate 1100 PPS. The HAAA MUST forward the Authorize-Only Access-Request to the 1101 PPS specified in the PPAQ. The HAAA MUST add a Message- 1102 Authenticator(80) to the message, according to RFC 2869. As with the 1103 Access-Request message, the HAAA MAY modify the User-Name(1) 1104 attribute such that it identifies the user to the PPS. 1106 When the PPS receives the Authorize-Only Access-Request containing a 1107 PPAQ attribute, it MUST validate the Message-Authenticator(80) as 1108 described in RFC 2869. If validation fails, the PPS MUST silently 1109 discard the message. If it receives an Authorize-Only Access-Request 1110 message that does not contain a PPAQ, it MUST silently discard the 1111 message. 1113 The PPS locates the prepaid session state and uses the QID contained 1114 within the PPAQ to detect replays. The PPS takes the most recently 1115 allocated quota and subtracts it from the user balance. If 1116 sufficient balance remains, the PPS authorizes the PPS and allocates 1117 additional quota. The PPS may also calculate a new threshold value. 1118 Upon successful re-authorization, the PPS generates an Access-Accept 1119 containing the PPAQ attribute. 1121 Depending on site policies, upon unsuccessful authorization, the PPS 1122 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1123 Ascend-Data-Filter attribute (if supported) and the Session- 1124 Timeout(27) attribute such that the subscriber can get access to a 1125 restricted set of locations for a short period of time. This feature 1126 could be used to enable users to replenish their accounts, create new 1127 accounts, or to access free content. 1129 Upon receiving an Access-Accept from the PPS, the HAAA forwards the 1130 message to its client. If the HAAA receives an Access-Reject 1131 message, it forwards the message. Depending on site policies, if the 1132 HAAA does not receive an Access-Accept or an Access-Reject message 1133 from the PPS it MAY do nothing or it MAY send an Access-Reject 1134 message back to its client. 1136 Upon receiving an Access-Accept, the PPC updates its quotas and 1137 threshold parameters with the values contained in the PPAQ attribute. 1138 Note that the PPS MAY update the PrePaidServer attribute(s) and these 1139 may have to be saved as well. If the Access-Accept message contains 1140 a Filter-Id(11), an Ascend-Data-Filter attribute, or Session 1141 Timeout(27), the PPC SHALL restrict the subscriber session 1142 accordingly. 1144 3.5. Dynamic Operations 1146 The PPS may take advantage of the dynamic capabilities that are 1147 supported by the PPC as advertised in the Session Termination and the 1148 PPAC attribute during the initial Access-Request. There are two 1149 types of actions that the PPS may perform. Firstly, it may request 1150 the session to be terminated. Secondly, it may request the 1151 attributes associated with the session to be modified. More 1152 specifically, it may modify a previously sent PPAQ. 1154 Both of these actions require that the session be uniquely identified 1155 at the PPC as described in [RFC3576]. 1157 3.5.1. Unsolicited Session Termination Operation 1159 At anytime during a session the PPS may send a Disconnect Message in 1160 order to terminate a session, see in [RFC3576]. Upon successful 1161 termination of a session the PPC MUST return any unused quota to the 1162 PPS by issuing an Authorize-Only Access-Request containing the PPAQ 1163 which contains any unused quota and the Update-Reason set to "Remote 1164 Forced Disconnection". 1166 3.5.2. Unsolicited Change of Authorization Operation 1168 At any time during the session the PPC may receive a Change of 1169 Authorization (CoA) message. A PPS may send a new quota to either 1170 add or to remove quota that is allocated to the service. If the 1171 Change of Authorization contains a PPAQ then that PPAQ overrides a 1172 previously received PPAQ. The PPS MUST NOT change the units used in 1173 the PPAQ. 1175 If the newly received PPAQ reduces the amount of allocated quota 1176 beyond what is already used then the PPC accepts the new PPAQ and act 1177 as it normally would when the quota is used up. For example, if the 1178 threshold is reached then is request a quota update. 1180 3.6. Termination Operation 1182 The termination phase is initiated when (i) the subscriber logs off, 1183 (ii) the subscriber balance is exhausted, or (iii) when the PPC 1184 receives a Disconnect Message. 1186 In case the user logged off, or the PPC receives a Disconnect 1187 Message, the PPC sends an Authorize-Only Access-Request message with 1188 a PPAQ and Update-Reason attribute set to either "Client Service 1189 Termination" or "Remote Forced Disconnect". This message indicates 1190 the amount of consumed quota. 1192 In case the currently allocated quota is exhausted, if the PPAQ 1193 contained the Termination-Action subytype, the PPC follows the 1194 specified action. 1196 3.7. Mobile IP Operations 1198 In roaming scenarios with Mobile-IP, the prepaid data session should 1199 be maintained transparently if the HA is acting as the access device 1200 hosting the PPC. As the subscriber device associates with a new 1201 access service device (AP or PDSN that supports PPC capability), this 1202 service access device sends a RADIUS Access-Request and the 1203 subscriber is re-authenticated and reauthorized. The service access 1204 device SHALL include the PPAC attribute in the RADIUS Access-Request. 1205 In this manner, the procedure follows the Authentication and 1206 Authorization procedure described earlier. 1208 If the HA was acting as the service access device before handoff, 1209 then the prepaid session does not undergo any change after the 1210 handoff because the Mobile IP session is anchored at the HA and the 1211 user's Home IP address does not change. 1213 In the case of a wireless access point or PDSN acting as the service 1214 access device, it is likely that the user's (care-of) IP address will 1215 change. The prepaid session will be affected by this. In this 1216 scenario the service access device shall send an Access-Request 1217 message which is routed to the home network and SHALL reach the PPS 1218 that is serving this session. The PPS correlates the new 1219 authorization request with the existing active session and assigns a 1220 quota to the new request. Any outstanding quota at the old service 1221 access device SHALL be returned to the PPS if the Mobile-IP nodes (HA 1222 and FA) support registration revocation (Mobile IPv4 only). 1223 Specifically, the quota SHOULD be returned when the service access 1224 device sends the Authorize-Only Access-Request with PPAQ Update- 1225 Reason set to either "Remote Forced Disconnect" or "Client Service 1226 Termination". In order to trigger the sending of this last 1227 Authorize-Only Access- Request, the PPS may issue a Disconnect 1228 Message [3576] to the service access device. 1230 Even if the subscriber moves to a service access device that does not 1231 have prepaid capabilities can the prepaid data service continue. 1232 This can be done by requesting the Home Agent (assuming it has such 1233 capabilities) to take over the responsibilities of the service access 1234 device (i.e. metering). This scenario will be discussed in detail in 1235 a later version of this document. 1237 3.8. Operation Considerations for Multiple Services 1239 This section describes the support for multiple prepaid services on a 1240 single PPC. Message flows illustrating the various interactions are 1241 presented in Appendix A. 1243 A PPC that supports prepaid operations for multi-services SHOULD set 1244 the "Multi-Services Supported" bit in the PPAC. When working with 1245 multi-services, we need to differentiate between the services. A 1246 Service-Id attribute is used in the PPAQ in order to uniquely 1247 differentiate between the services. The exact definition of the 1248 Service-Id attribute is outside the scope of this document. 1250 A PPAQ that contains a Service-Id is associated with that service. A 1251 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1252 Group. A PPAQ MUST NOT contain both a Rating-Group-Id and a 1253 Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a 1254 Service-Id then the default service is used, i.e., the "Access 1255 Service". 1257 3.8.1. Initial Quota Request 1259 When operations with multiple services is desired then the PPC 1260 requests the initial quota by sending a PPAQ containing the 1261 Service-Id in an Authorize-Only Access-Request packet for that 1262 service. Similarly, if the PPC supports rating groups then it may 1263 request a quota for the rating group by sending a PPAQ containing the 1264 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1265 Request". The Authorize-Only Access-Request message MAY contain more 1266 than one PPAQ. 1268 Upon receiving an Authorize-Only Access-Accept message containing one 1269 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1270 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1271 for that service or rating group. Additionally, the PPAQ MUST 1272 contain the Service-ID or Rating-Group-Id, unless the PPAQ is the 1273 generic "Access Service". 1275 3.8.2. Quota Update 1277 Once the services start to utilize their allotted quota they will 1278 eventually need to replenish their quotas (either the threshold is 1279 reached or no more quota remains). In order to replenish the quota, 1280 the PPC sends an Authorize-Only Access-Request message containing one 1281 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1282 Service-ID or Rating-Group-Id (or neither the Service-ID or Rating- 1283 Group-Id if the quota replenishment is for the "Access Service"). 1284 The Update-Reason filed indicates either "Threshold reached"(3), or 1285 "Quota reached"(4). 1287 Upon receiving an Authorize-Only Access-Request packet with one or 1288 more PPAQs the PPS responds with a new PPAQ for that service. The 1289 PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a 1290 new QID. If the PPS does not grant additional quota for the service 1291 it MUST include the Termination-Action subfield in the PPAQ that will 1292 instruct the PPC to take appropriate actions. 1294 3.8.3. Termination 1296 When the allotted quota for a service is exhausted, the PPC shall act 1297 in accordance with the flags set in the Termination-Action subtype. 1298 If the Termination-Action subtype is absent then the service MUST be 1299 terminated. If the service is to be terminated, then the PPC shall 1300 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1301 and the Update-Reason set to "Client Service Termination". 1303 If the "Access Service" has terminated, then all other services must 1304 be terminated as well. In this case the PPC MUST report on all 1305 issued quotas for the various services. The Update-Reason field 1306 should be set to "Access Service Terminated". 1308 3.8.4. Dynamic Operations 1310 Dynamic operations for multi-services are similar to dynamic 1311 operations described for single service operations. The PPS MAY send 1312 a COA message containing a PPAQ for an existing service instance. 1313 The PPC matches the PPAQ with the service using the Service-ID or the 1314 Rating-Group-Id attribute. The new quota could differ from the 1315 previously allocated value. 1317 A disconnect message terminates the "Access Service". As such the 1318 PPC MUST report all unused quotas by sending an Authorize-Only Access 1319 Request message containing a PPAQ for each active service. The 1320 Update-Reason MAY indicate that the reason for the update. 1322 3.8.5. Support for Resource Pools 1324 If the PPC supports pools as indicated by setting the "Pools 1325 supported" bit in the PPAC then the PPS may associate a quota with a 1326 Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ. 1327 When Resource Pools are used, the PPAQ MUST NOT use the threshold 1328 field. 1330 3.8.6. One-time Charging 1332 To initiate one-time charging the PPC includes the PPAQ attribute in 1333 an Access-Request packet. The Service-ID field of the PPAQ 1334 identifies the prepaid service. The amount to be charged is 1335 specified using the Resource Quota and Resource Quota overflow 1336 subtypes. If the value specified is negative then the resources are 1337 credited to the user account. This functionality corresponds to 1338 refunding. 1340 The QID subtype MUST be set to a unique value and is used by the PPS 1341 to detect duplicates. The Update Reason field MUST be set to One- 1342 Time Charging. Upon receiving a One-Time charge PPAQ, the RADIUS 1343 server authenticates the user and, if successful, passes the PPAQ to 1344 the PPS. The PPS locates the account and debits or credits it 1345 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1346 message if successful, or an Access-Reject message otherwise. 1348 In case of a successful operation the HAAA forwards the message to 1349 the PPC with an Access Accept message. Since this is a one-time 1350 charge the PPC MUST NOT allow the session to continue. Therefore, 1351 the RADIUS server SHOULD include in the Access-Accept a Session- 1352 Timeout set to 0. Upon receiving an Access-Accept response the PPC 1353 SHOULD generate an Accounting Stop message. 1355 A PPAQ used for One-Time charging MAY appear in an Authorize-Only 1356 Access Request. This is the case when the session already exists. 1357 The PPS responds with an Access-Accept to indicate that the user 1358 account has been debited or an Access-Reject otherwise. 1360 3.8.7. Error Handling 1362 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1363 PPAQ. 1365 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1366 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1368 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1369 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1371 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1372 Multiplier or a Pool-Multiplier without a Pool-Id it MUST ignore that 1373 PPAQ. 1375 3.8.8. Accounting Considerations 1377 Although typically generated, accounting messages are not required to 1378 deliver a prepaid data service. When generated, accounting messages 1379 are used for auditing purposes and for billing. Accounting messages 1380 associated with prepaid data sessions should include the PPAQ 1381 attribute. 1383 4. Attributes 1385 This section specifies the attributes that implement the RADIUS 1386 extensions for prepaid. 1388 4.1. PrePaid Accounting Capability (PPAC) Attribute 1390 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1391 Access-Request message by a PPC to describe its prepaid capabilities. 1393 0 1 2 3 1394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Type | Length | Vendor-Id 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Vendor-Id (cont) | Vendor type | Vendor length | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Continuation | VALUE ... 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1403 The fields have the following meaning and encoding: 1405 Type: 1407 26 for Vendor-Specific 1409 Length: 1411 6 + 3 + length of SubTypes 1413 Vendor-Id: 1415 The Vendor-Id value for WiMAX is 24757. 1417 Vendor type: 1419 35 for PPAC 1421 Vendor length: 1423 3 + length of VALUE 1425 Continuation: 1427 The Continuation Field is defined as follows: 1429 0 1430 0 1 2 3 4 5 6 7 1431 +-+-+-+-+-+-+-+-+ 1432 |C|r|r|r|r|r|r|r| 1433 +-+-+-+-+-+-+-+-+ 1435 The C-bit of the continuation field indicates 1436 if a attribute is being fragmented. When the 1437 C-bit is set to one '1' this indicates that 1438 the attribute is being fragmented that is 1439 the next VSA of the same type is to be appended 1440 to this attribute. When the C-bit is set to zero 1441 '0' this indicates that the next attribute is 1442 not a fragment of this attribute. 1443 An attribute that is not being fragmented will 1444 have the C-bit set to '0'. An attribute that is 1445 being fragmented will have its C-bit set to '1' 1446 for all fragments until the last fragment, which 1447 will have its C-bit set to '0' indicating it's 1448 the last fragment of the attribute. The r-bits 1449 are reserved for future use. They SHALL be set 1450 to zero by the sender and SHALL be ignored by 1451 the receiver. 1453 The value of the C-bit MUST be 0. 1455 VALUE : 1457 The content of the AvailableInClient (AiC) SubType fields 1458 are encoded using the data type String. 1460 Figure 8: PPAC Attribute 1462 The AvailableInClient (AiC) SubType is encoding as follows: 1464 0 1 2 3 1465 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | SubType | LENGTH | AvailableInClient (AiC) ... 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | AvailableInClient (AiC) | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 The fields have the following meaning and encoding: 1474 SubType : Value (1) 1476 LENGTH : 2 + 4 1478 AvailableInClient (AiC): The bitmap is encoded as: 1480 Value | Description 1481 ------------ -+------------------------------------- 1482 0x00000001 | Volume metering supported 1483 0x00000010 | Duration metering supported 1484 0x00000100 | Resource metering supported 1485 0x00001000 | Pools supported 1486 0x00010000 | Rating groups supported 1487 0x00100000 | Multi-Services supported 1488 0x01000000 | Tariff Switch supported 1489 0x10000000 | Reserved 1491 Figure 9: AvailableInClient (AiC) SubType 1493 4.2. Session Termination Capability Attribute 1495 The Session Termination Capability attribute is included in the 1496 RADIUS Access-Request message towards the RADIUS server to indicate 1497 whether or not the NAS supports Dynamic Authorization. 1499 0 1 2 3 1500 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Type | Length | Vendor-Id 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 Vendor-Id (cont) | Vendor type | Vendor length | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Continuation | String ... 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1509 The fields have the following meaning and encoding: 1511 Type: 1513 26 for Vendor-Specific 1515 Length: 1517 6 + 3 + 4 1519 Vendor-Id: 1521 The Vendor-Id value for WiMAX is 24757. 1523 Vendor type: 1525 36 for Session Termination Capability 1527 Vendor length: 1529 3 + 4 1531 Continuation: 1533 The Continuation Field is defined as follows: 1535 0 1536 0 1 2 3 4 5 6 7 1537 +-+-+-+-+-+-+-+-+ 1538 |C|r|r|r|r|r|r|r| 1539 +-+-+-+-+-+-+-+-+ 1541 The C-bit of the continuation field indicates 1542 if a attribute is being fragmented. When the 1543 C-bit is set to one '1' this indicates that 1544 the attribute is being fragmented that is 1545 the next VSA of the same type is to be appended 1546 to this attribute. When the C-bit is set to zero 1547 '0' this indicates that the next attribute is 1548 not a fragment of this attribute. 1549 An attribute that is not being fragmented will 1550 have the C-bit set to '0'. An attribute that is 1551 being fragmented will have its C-bit set to '1' 1552 for all fragments until the last fragment, which 1553 will have its C-bit set to '0' indicating it's 1554 the last fragment of the attribute. The r-bits 1555 are reserved for future use. They SHALL be set 1556 to zero by the sender and SHALL be ignored by 1557 the receiver. 1559 The value of the C-bit MUST be 0. 1561 String: 1563 This field is encoded as a bitmap. 1565 Value | Description 1566 ---------------+------------------------------------- 1567 0x00000000 | Reserved 1568 0x00000001 | Dynamic Authorization Extensions 1569 | (RFC 3576) is supported. 1570 ... | All further values are reserved. 1572 Figure 10: Session Termination Capability Attribute 1574 4.3. Prepaid Accounting Operation (PPAQ) Attribute 1576 One or more PPAQ attributes are sent in an Access Request, Authorize- 1577 Only Access-Request and Access-Accept message. In an Access Request 1578 message, the PPAQ attribute is used to facilitate one-time charging 1579 transactions. In Authorize-Only Access-Request messages it is used 1580 for one-time charging, report usage and to request further quota. It 1581 is also used in order to request prepaid quota for a new service 1582 instance. In an Access-Accept message it is used in order to 1583 allocate the (initial and subsequent) quotas. 1585 When multiple services are supported, a PPAQ is associated with a 1586 specific service as indicated by the presence of a Service-Id, a 1587 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1588 of both, the Service-Id and the Rating-Group-Id). 1590 Note: Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes 1591 MUST appear in the PPAQ attribute, except for the price enquiry 1592 message exchange where these subtypes MUST be absent. A single PPAQ 1593 attribute MUST NOT contain more than one Service-Id, MUST NOT contain 1594 more than one Rating-Group-Id, and MUST NOT contain both a Service-Id 1595 and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or 1596 a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT 1597 contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST 1598 also contain a Pool-Multiplier SubType. 1600 The PPAQ attribute, as shown in Figure 11, has a variable length 1601 (greater than 8, encoded into one octet), and consists of a variable 1602 number of subtypes. Unused subtypes are omitted from the message. 1604 The following table summarizes the presence of various SubTypes in 1605 the PPAQ attribute carried in the Access-Request and Access-Accept 1606 messages. 1608 Request Accept # SubType Name 1610 0-1(g) 0-1(m,n) 1 Quota Identifier 1611 0-1(a,g) 0-1(a,k,n) 2 VolumeQuota 1612 0 0-1(a,m,n) 3 VolumeThreshold 1613 0-1(b,g) 0-1(b,k,n) 4 DurationQuota 1614 0 0-1(b,m,n) 5 DurationThreshold 1615 0-1(c,g) 0-1(c,k,n) 6 ResourceQuota 1616 0 0-1(c,m,n) 7 ResourceThreshold 1617 0-1(d,g) 0 8 Update-Reason 1618 0-n(e,g) 0-n(e,m,n) 9 PrepaidServer 1619 0-1(g,h,j) 0-1(m,n) 10 Service-ID 1620 0-1(g,h,j) 0-1(m,n) 11 Rating-Group-ID 1621 0 0-1(m,n) 12 Termination-Action 1622 0 0-1(m,n) 13 Pool-ID 1623 0 0-1(f,m,n) 14 Pool-Multiplier 1624 0-1(g) 0 15 Requested-Action 1625 0 0-1(k,m,n) 16 Check-Balance-Result 1626 0 0-1(n) 17 Cost-Information 1628 None of the above-listed SubTypes appears in the Access-Reject nor in 1629 the Access-Challenge. 1631 Notes: 1633 (a) SHALL be present if volume based charging is used. SHALL NOT 1634 be present otherwise. Volume- Threshold is optional. 1636 (b) SHALL be present if duration-based charging is used. SHALL 1637 NOT be present otherwise. Duration- Threshold is optional. 1639 (c) SHALL be present if resource-based charging is used. SHALL 1640 NOT be present otherwise. Resource- Threshold is optional. 1642 (d) SHALL be present in an Authorize-Only Access-Request. 1644 (e) MAY be present in an Access-Accept. If present in Access 1645 Accept it SHALL be present in Access- Request (except for the 1646 first Access-Request). 1648 (f) Pool-Multiplier SHALL be present when Pool-ID is present 1649 otherwise Pool-Multiplier SHALL NOT be present in the PPAQ. 1651 (g) If Requested-Action is present then Service-ID SHALL also be 1652 present and all other attributes SHALL NOT be present. 1654 (h) PPAQ SHALL NOT contain both a Service-ID and a 1655 Rating-Group-ID. 1657 (j) A PPAQ that does not contain a Service-ID or a Rating-Group-Id 1658 refers to the "Access Service"(ISF). 1660 (k) If Balance-Check-Result is present and set to 0 then either 1661 Volume-Quota, Duration-Quota or Resource- Quota SHALL be present. 1663 (m) If Balance-Check-Result is present then Service-ID SHALL also 1664 be present and other attributes (tagged with m) SHALL NOT be 1665 present. 1667 (n) The PPAQ in which a Cost-Information occurs SHALL NOT include 1668 a Quota-Identifier, because no quota is actually reserved by the 1669 PPS. The Service-ID SHALL be present with the Cost-Information 1670 for that Service-ID may not be present if the Cost-Information 1671 cannot be provided. All other attribute SHALL not appear. 1673 In the following subsections the various subtypes of the PPAQ 1674 attribute are specified. 1676 0 1 2 3 1677 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Type | Length | Vendor-Id 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 Vendor-Id (cont) | Vendor type | Vendor length | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Continuation | VALUE ... 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1686 The fields have the following meaning and encoding: 1688 Type: 1690 26 for Vendor-Specific 1692 Length: 1694 6 + 3 + length of SubTypes 1696 Vendor-Id: 1698 The Vendor-Id value for WiMAX is 24757. 1700 Vendor type: 1702 37 for PPAQ 1704 Vendor length: 1706 3 + length of SubTypes 1708 Continuation: 1710 The Continuation Field is defined as follows: 1712 0 1713 0 1 2 3 4 5 6 7 1714 +-+-+-+-+-+-+-+-+ 1715 |C|r|r|r|r|r|r|r| 1716 +-+-+-+-+-+-+-+-+ 1718 The C-bit of the continuation field indicates 1719 if a attribute is being fragmented. When the 1720 C-bit is set to one '1' this indicates that 1721 the attribute is being fragmented that is 1722 the next VSA of the same type is to be appended 1723 to this attribute. When the C-bit is set to zero 1724 '0' this indicates that the next attribute is 1725 not a fragment of this attribute. 1726 An attribute that is not being fragmented will 1727 have the C-bit set to '0'. An attribute that is 1728 being fragmented will have its C-bit set to '1' 1729 for all fragments until the last fragment, which 1730 will have its C-bit set to '0' indicating it's 1731 the last fragment of the attribute. The r-bits 1732 are reserved for future use. They SHALL be set 1733 to zero by the sender and SHALL be ignored by 1734 the receiver. 1736 The value of the C-bit MAY be 0 or 1. 1738 VALUE: 1740 Data type String 1741 Each SubType is then encoded in the following style: 1743 0 1 2 3 1744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | SubType | LENGTH | VALUE ... 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 The fields have the following meaning and encoding: 1751 SubType : 1753 Contains an 8 bit unsigned integer. 1755 LENGTH : 1757 Contains an 8 bit unsigned integer. 1758 The value of the LENGTH field is calculated as the length of the 1759 VALUE field plus two octets (one octet for the length of the 1760 SubType field and another octet for the length of the LENGTH 1761 field). 1763 Figure 11: PPAQ Attribute Encoding Style 1765 4.3.1. Quota Identifier (QID) SubType 1767 The Quota Identifier (QID) is generated by the PPS and subsequently 1768 returned in a PPAQ->QID subtype from the PPC to the PPS. This field 1769 has the semantic of a transaction identifier and therefore changes 1770 with every transaction initiated by the PPS to the PPC. 1772 0 1 2 3 1773 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | SubType | LENGTH | VALUE ... 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | VALUE | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 The fields have the following meaning and encoding: 1782 SubType : Value(1) 1784 LENGTH : 2 + length of VALUE field. 1786 VALUE : Data type String 1788 Quota Identifier (QID) SubType 1790 4.3.2. VolumeQuota SubType 1792 TVolumeQuota SubType is only present when volume-based charging is 1793 used. In a RADIUS Access-Accept message (PPS to PPC direction), it 1794 indicates the volume (in octets) allocated for the session by the 1795 PPS. In a RADIUS Authorize-Only Access-Request message (PPC to PPS 1796 direction), it indicates the totally used volume (in octets) for both 1797 inbound and outbound traffic. The Exponent Field, if present, MUST 1798 NOT encode a negative number or zero. 1800 0 1 2 3 1801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | SubType | LENGTH | VALUE ... 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 The fields have the following meaning and encoding: 1808 SubType : Value(2) 1810 LENGTH : 2 + (8 or 12) 1812 VALUE : Data type String 1814 The content of the VALUE field either contains the 1815 Value-Digits Field (8 octets long) or the Value-Digits Field 1816 plus the Exponent Field (12 octets long). 1818 VolumeQuota SubType 1820 4.3.3. VolumeThreshold SubType 1822 The value of the type field of the VolumeThreshold SubType is TBD and 1823 its length is 10 or 14 octets. This SubType is optionally present if 1824 the VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1825 PPC direction). It is generated by the PPS and indicates the volume 1826 (in octets) that has to be consumed before a new quota is requested. 1827 This threshold MUST NOT be larger than the VolumeQuota. The Exponent 1828 Field, if present, MUST NOT encode a negative number or zero. 1830 0 1 2 3 1831 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | SubType | LENGTH | VALUE ... 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 The fields have the following meaning and encoding: 1838 SubType : Value(3) 1840 LENGTH : 2 + (8 or 12) 1842 VALUE : Data type String 1844 The content of the VALUE field either contains the 1845 Value-Digits Field (8 octets long) or the Value-Digits 1846 SubType plus the Exponent Field 12 octets long). 1848 VolumeThreshold SubType 1850 4.3.4. DurationQuota SubType 1852 The optional DurationQuota SubType is only present if duration-based 1853 charging is used. In a RADIUS Access-Accept message (PPS to PPC 1854 direction), it indicates the duration (in seconds) allocated for the 1855 session by the PPS. In a RADIUS Access-Request message (PPC to PPS 1856 direction), it indicates the total duration (in seconds) since the 1857 start of the accounting session related to the QID subtype of the 1858 PPAQ attribute in which it occurs. 1860 0 1 2 3 1861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | SubType | LENGTH | VALUE ... 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | VALUE | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 The fields have the following meaning and encoding: 1870 SubType : Value(4) 1872 LENGTH : 2 + 4 1874 VALUE : Data type string. 1876 The content of this field contains a 32-bit unsigned integer 1877 (with the values 0 to +4,294,967,295). 1879 DurationQuota SubType 1881 4.3.5. DurationThreshold SubType 1883 The DurationThreshold SubType is optionally present if the 1884 DurationQuota is present in a RADIUS Access-Accept message (PPS to 1885 PPC direction). It represents the duration (in seconds) after which 1886 new quota should be requested. This threshold MUST NOT be larger 1887 than the DurationQuota SubType. 1889 0 1 2 3 1890 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | SubType | LENGTH | VALUE ... 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | VALUE | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 The fields have the following meaning and encoding: 1899 SubType : Value(5) 1901 LENGTH : 2 + 4 1903 VALUE : Data type string. 1905 The content of this field contains a 32-bit unsigned integer 1906 (with the values 0 to +4,294,967,295). 1908 DurationThreshold SubType 1910 4.3.6. ResourceQuota SubType 1912 The optional ResourceQuota SubType is only present if resource-based 1913 or one-time charging is used. In the RADIUS Access-Accept message 1914 (PPS to PPC direction) it indicates the resources allocated for the 1915 session by the PPS. In RADIUS Authorize-Only Access-Request message 1916 (PPC to PPS direction), it indicates the resources used in total, 1917 including both incoming and outgoing chargeable traffic. In one-time 1918 charging scenarios, the subtype represents the number of units to 1919 charge the user. The attribute consists of a Value-Digits Field and 1920 optionally an Exponent Field (as indicated by the length field). 1922 0 1 2 3 1923 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | SubType | LENGTH | VALUE ... 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 The fields have the following meaning and encoding: 1930 SubType : Value(6) 1932 LENGTH : 2 + (8 or 12) 1934 VALUE : Data type String 1936 The content of the VALUE field either contains the 1937 Value-Digits Field (8 octets long) or the Value-Digits Field 1938 plus the Exponent Field (12 octets long). 1940 ResourceQuota SubType 1942 4.3.7. ResourceThreshold SubType 1944 The semantic of the ResourceThreshold SubType follow those of the 1945 VolumeThreshold and DurationThreshold SubType. 1947 0 1 2 3 1948 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | SubType | LENGTH | VALUE ... 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 The fields have the following meaning and encoding: 1955 SubType : Value(7) 1957 LENGTH : 2 + (8 or 12) 1959 VALUE : Data type String 1961 The content of the VALUE field either contains the 1962 Value-Digits Field (8 octets long) or the Value-Digits Field 1963 plus the Exponent Field (12 octets long). 1965 ResourceThreshold SubType 1967 4.3.8. Update-Reason SubType 1969 The Update-Reason SubType is present in a RADIUS Access-Request 1970 message (PPC to PPS direction) and indicates the reason for 1971 initiating the quota update operation. Update reasons (6), (7), (8) 1972 and (9) indicate that the associated resources are released at the 1973 PPC side, and that therefore the PPS MUST NOT allocate a new quota in 1974 the RADIUS Access-Accept message. 1976 0 1 2 3 1977 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 | SubType | LENGTH | VALUE | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 The fields have the following meaning and encoding: 1984 SubType : Value(8) 1986 LENGTH : 2 + 1 1988 VALUE : Data type string 1990 This field contains a byte 1991 (with the values 0 to 255). 1993 Update-Reason SubType 1995 The following values for the Update-Reason SubType are defined: 1997 Value | Description 1998 -------------+-------------------------------------- 1999 0 | Reserved 2000 1 | Pre-initialization 2001 2 | Initial Request 2002 3 | Threshold Reached 2003 4 | Quota Reached 2004 5 | TITSU Approaching 2005 6 | Remote Forced Disconnect 2006 7 | Client Service Termination 2007 8 | "Access Service" Terminated 2008 9 | Service not established 2009 10 | One-Time Charging 2010 11...255 | **Available for IANA registration** 2012 Figure 12: Values for Update-Reason SubType 2014 4.3.9. PrepaidServer SubType 2016 The optional PrepaidServer SubType indicates the address of the 2017 serving PPS. If present, the Home RADIUS server uses this address to 2018 route the message to the serving PPS. Multiple instances of this 2019 subtype MAY be present in a single PPAQ attribute. 2021 If present in the PrepaidServer SubType of an incoming RADIUS Access- 2022 Accept message, the PPC returns this SubType back without modifying 2023 it in the subsequent RADIUS Access-Request message. If multiple 2024 values are present, the PPC MUST NOT change their order. 2026 0 1 2 3 2027 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 | SubType | LENGTH | Address ... 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 The fields have the following meaning and encoding: 2034 SubType : Value(9) 2036 LENGTH : 2 + (4 or 16) 2038 Address : Data type String 2040 For IPv4, the Address field is 4 octets based on the encoding of 2041 the NAS-IP-Address defined in RFC 2138. For IPv6, the Address 2042 field is 16 octets long. 2044 PrepaidServer SubType 2046 4.3.10. Service-ID SubType 2048 The Service-ID SubType is handled as an opaque string that uniquely 2049 describes the service instance for which prepaid metering should be 2050 applied. 2052 A Service-Id could be an IP 5-tuple (source address, source port, 2053 destination address, destination port, protocol). If a Service-ID 2054 SubType is present in the PPAQ, the entire PPAQ attribute refers to 2055 that service. If a PPAQ attribute does not contain a Service-Id or 2056 Rating-Group-ID, then the PPAQ attribute refers to the "Access 2057 Service". 2059 0 1 2 3 2060 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | SubType | LENGTH | Service ... 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 The fields have the following meaning and encoding: 2067 SubType : Value(10) 2069 LENGTH : 2 + length (Service) 2071 Service : Data type String 2073 Service-ID SubType 2075 4.3.11. Rating-Group-ID SubType 2077 The Rating-Group-ID SubType indicates that this PPAQ attribute is 2078 associated with resources allocated to a Rating Group with the 2079 corresponding ID. This SubType is encoded as a string. A single 2080 PPAQ MUST NOT contain more than one Rating-Group-ID. 2082 0 1 2 3 2083 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | SubType | LENGTH | VALUE ... 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 | VALUE | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 The fields have the following meaning and encoding: 2092 SubType : Value(11) 2094 LENGTH : 2 + 4 2096 VALUE : Data type string with a length of 4 octets 2098 Rating-Group-ID SubType 2100 4.3.12. Termination-Action SubType 2102 The value of the type field of the Termination-Action SubType is TBD. 2103 The length of this SubType is 3 octets. This SubType contains an 2104 enumeration of the action to take when the PPS does not grant 2105 additional quota. Valid actions are as follows. 2107 0 1 2 2108 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 | SubType | LENGTH | Action | 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 The fields have the following meaning and encoding: 2115 SubType : Value(12) 2117 LENGTH : 2 + 1 2119 Action : Data type string. 2121 The content is a byte (with the values 0 to +255). 2123 Termination-Action SubType 2125 The following values for the Termination-Action SubType are defined: 2127 Value | Description 2128 -------------+------------------------------------ 2129 0 | Reserved 2130 1 | Terminate 2131 2 | Request More Quota 2132 3 | Redirect/Filter 2133 4..255 | **Available for IANA registration** 2135 Figure 13: Values for the Termination-Action SubType 2137 4.3.13. Pool-ID SubType 2139 The Pool-ID SubType identifies the resource pool. It is encoded as a 2140 string. 2142 0 1 2 3 2143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | SubType | LENGTH | Poolid | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 The fields have the following meaning and encoding: 2150 SubType : Value(13) 2152 LENGTH : 2 + 4 2154 Poolid : Data type string with length of 4 octets. 2156 Pool-ID SubType 2158 4.3.14. Pool-Multiplier SubType 2160 The Pool-Multiplier SubType determines the weight of resources when 2161 they are inserted into the pool that is identified by the 2162 accompanying Pool-ID SubType, and the rate at which resources are 2163 taken out of the pool by the relevant Service or Rating-Group. 2165 0 1 2 3 2166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | SubType | LENGTH | VALUE ... 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 The fields have the following meaning and encoding: 2173 SubType : Value(14) 2175 LENGTH : 2 + (8 or 12) 2177 VALUE : Data type String 2179 The content of the VALUE field either contains the 2180 Value-Digits Field (8 octets long) or the Value-Digits Field 2181 plus the Exponent Field (12 octets long). 2183 Pool-Multiplier SubType 2185 4.3.15. Requested-Action SubType 2187 The Requested-Action SubType is only be present in messages sent from 2188 the PPC to the PPS. It indicates that the PPC desires the PPS to 2189 perform the indicated action and to return the result. The PPAQ in 2190 which a Requested-Action SubType occurs MUST NOT contain a QID, and 2191 MUST contain a Service-Identifier or a Rating-Group-Identifer that 2192 allows the PPS to uniquely identify the service for which the 2193 indicated action is requested. 2195 0 1 2 2196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | SubType | LENGTH | Action | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 The fields have the following meaning and encoding: 2203 SubType : Value(15) 2205 LENGTH : 2 + 1 2207 Action : Data type string. 2209 The content is a byte (with the values 0 to +255). 2210 The values are listed below. 2212 Requested-Action SubType 2214 The following values for the Action field of the Requested-Action 2215 SubType are defined: 2217 Value | Description 2218 -------------+------------------------------------- 2219 0 | Reserved 2220 1 | Balance Check 2221 2 | Price Enquiry 2222 3..255 | **Available for IANA registration** 2224 Figure 14: Values for the Requested-Action SubType 2226 4.3.16. Check-Balance-Result SubType 2228 The Check-Balance-Result SubType can only be present in messages sent 2229 from the PPS to the PPC. It indicates the balance check decision of 2230 the PPS about a previously received Balance Check Request (as 2231 indicated in a Requested-Action SubType). The PPAQ attribute in 2232 which a Check-Balance-Result occurs MUST NOT include a QID beause no 2233 quota is reserved by the PPS. 2235 0 1 2 2236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | SubType | LENGTH | Decision | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 The fields have the following meaning and encoding: 2243 SubType : Value(16) 2245 LENGTH : 2 + 1 2247 Decision : Data type string. 2249 The content is a byte (with the values 0 to +255). 2250 The values are listed below. 2252 Check-Balance-Result SubType 2254 The following values for the Decision field of the Check-Balance- 2255 Result SubType are defined: 2257 Value | Description 2258 -------------+------------------------------------------- 2259 0 | Success; Sufficient funds available 2260 | in the user's prepaid account 2261 1 | Failure; Insufficient funds available 2262 2..255 | **Available for IANA registration** 2264 Figure 15: Values for the Check-Balance-Result SubType 2266 4.3.17. Cost-Information SubType 2268 The Cost-Information SubType is used in order to return the cost 2269 information of a service, which the PPC can transfer transparently to 2270 the end user. This SubType is sent from the PPS to the PPC as a 2271 response to a "Price Enquiry", as indicated by the Requested-Action 2272 SubType. 2274 0 1 2 3 2275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | SubType | LENGTH | VALUE ... 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 The fields have the following meaning and encoding: 2282 SubType : Value(17) 2284 LENGTH : 2 + 12 + 4 + length of the Cost-Unit Field 2286 VALUE : Data type String 2288 The content of the VALUE field contains (in this order) the 2289 Value-Digits Field, Exponent Field, Currency-Code Field 2290 and the Cost-Unit Field. 2292 Cost-Information SubType 2294 For example, the cost of 7.75 Malawi kwacha per hour would be encoded 2295 as follows. Value-Digits = 775, Exponent = -2, Currency Code = 454, 2296 and Cost-Unit = "hour". 2298 The PPAQ that carries a Cost-Information MUST NOT include a QID. 2300 The Currency-Code Field is of type Unsigned32 and used inside the 2301 Check-Balance-Result SubType and contains a currency code that 2302 specifies in which currency the values of AVPs containing monetary 2303 units were given. It is specified by using the numeric values 2304 defined in the ISO 3166-1 standard. 2306 The Cost-Unit Field is used inside the Check-Balance-Result SubType 2307 and contains a human readable UTF8 encoded string that can be 2308 displayed to the end user. It specifies the applicable unit to the 2309 Cost-Information when the service cost is a cost per unit (e.g., cost 2310 of the service is $1 per minute). The Cost-Unit can, for example, be 2311 minutes, hours, days, kilobytes, megabytes, etc. 2313 4.4. Fields 2315 4.4.1. Value-Digits Field 2317 The Value-Digits Field is an Unsigned64 value (with a length of 8 2318 octets) that contains the significant digits of the number. If 2319 decimal values are needed to present the number, the scaling MUST be 2320 indicated with a related Exponent Field, see Section 4.4.2. 2322 For example, the decimal number 0.05 is encoded by a Value-Digits 2323 Field set to 5, and a scaling that is indicated with the Exponent 2324 Field set to -2. 2326 The encoding of this SubType is not done in an TLV format but rather 2327 the encoded value is added to existing subtypes. 2329 4.4.2. Exponent Field 2331 The Exponent field is a Integer32 value that contains the exponent 2332 value that is to be applied to the accompanying Value-Digit Field. 2334 4.5. Prepaid Tariff Switching (PTS) Attribute 2336 This specification defines the PTS attribute, which allows to switch 2337 from one rate to another during service provision. Support for 2338 tariff switching is optional to implement and to use for the PPC and 2339 the PPS. PPCs use the flag "Tariff Switching supported" in the 2340 AvailableInClient field of the PPAC attribute in order to indicate 2341 support for tariff switching. PPSs employ the PTS attribute in order 2342 to announce their support for tariff switching. 2344 If a RADIUS message contains a PTS attribute, it MUST also contain at 2345 least one PPAQ attribute. If a RADIUS Access-Request message 2346 contains a PTS attribute or the "Tariff Switching supported" flag in 2347 the AvailableInClient field of the PPAC attribute, it MUST also 2348 contain an Event-Timestamp RADIUS attribute (see [RFC2869]). 2350 Every PTS attribute MUST include a QID SubType, as specified in 2351 Section 4.3.1. In a RADIUS Access-Request message sent from the PPC 2352 to the PPS, the QID SubType MUST contain the value of the Quota 2353 Identifier SubType that was previously received from the PPS and MUST 2354 be the same as the value carried in the QID SubType of one of the 2355 PPAQ attributes included the same RADIUS message. 2357 If multiple services are supported and if the PPAQ is associated with 2358 a service as indicated by the Service-ID SubType, then the PTS refers 2359 to the tariff switch for that service. If the PPAQ does not have a 2360 Service-ID, then the PTS refers to tariff switch for the "Access 2361 Service". 2363 A PPAQ attribute that is transported along with a PTS attribute and 2364 has the same value as the QID SubType contained in the PTS attribute 2365 in its own QID SubType is referred to as the "accompanying PPAQ 2366 attribute". If a PPS receives an Access-Request message from a PPC, 2367 it associates a unique value for the QID SubType to this request. 2369 The following table summarizes the presence of various SubTypes in 2370 the PTS attribute carried in the Access-Request and Access-Accept 2371 messages. 2373 Request Accept # SubType Name 2374 1 1 1 Quota Identifier 2375 1 0 2 VolumeUsedAfterTariffSwitch 2376 0 0-1 3 TarrifSwitchInterval 2377 0 0-1(a) 4 TimeIntervalAfterTarriffSwitchUpdate 2379 None of the above-listed SubTypes appears in the Access-Reject nor in 2380 the Access-Challenge. 2382 Notes: 2384 (a) The PPS SHALL include this AVP if there is another tariff 2385 switch period after the period that ends as indicated by the TSI 2386 attribute. 2388 0 1 2 3 2389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | Type | Length | Vendor-Id 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 Vendor-Id (cont) | Vendor type | Vendor length | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Continuation | VALUE ... 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2398 The fields have the following meaning and encoding: 2400 Type: 2402 26 for Vendor-Specific 2404 Length: 2406 6 + 3 + length of SubTypes 2408 Vendor-Id: 2410 The Vendor-Id value for WiMAX is 24757. 2412 Vendor type: 2414 38 for PTS 2416 Vendor length: 2418 3 + length of SubTypes 2420 Continuation: 2422 The Continuation Field is defined as follows: 2424 0 2425 0 1 2 3 4 5 6 7 2426 +-+-+-+-+-+-+-+-+ 2427 |C|r|r|r|r|r|r|r| 2428 +-+-+-+-+-+-+-+-+ 2430 The C-bit of the continuation field indicates 2431 if a attribute is being fragmented. When the 2432 C-bit is set to one '1' this indicates that 2433 the attribute is being fragmented that is 2434 the next VSA of the same type is to be appended 2435 to this attribute. When the C-bit is set to zero 2436 '0' this indicates that the next attribute is 2437 not a fragment of this attribute. 2438 An attribute that is not being fragmented will 2439 have the C-bit set to '0'. An attribute that is 2440 being fragmented will have its C-bit set to '1' 2441 for all fragments until the last fragment, which 2442 will have its C-bit set to '0' indicating it's 2443 the last fragment of the attribute. The r-bits 2444 are reserved for future use. They SHALL be set 2445 to zero by the sender and SHALL be ignored by 2446 the receiver. 2448 The value of the C-bit MAY be 0 or 1. 2450 VALUE : Variable length content of data type String containing 2451 one or multiple SubTypes. 2453 Each SubType is then encoding in the following style: 2455 0 1 2 3 2456 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | SubType | LENGTH | VALUE ... 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 The fields have the following meaning and encoding: 2463 SubType: 2465 Contains an 8 bit unsigned integer. 2467 LENGTH: 2469 Contains an 8 bit unsigned integer. 2471 VALUE: 2473 Contains the content of the SubType. 2475 Figure 16: PTS Attribute 2477 4.5.1. VolumeUsedAfterTariffSwitch SubType 2479 The optional VolumeUsedAfterTariffSwitch (VUATS) SubType is used in 2480 the RADIUS Access-Request messages (PPC to PPS direction). It 2481 indicates the volume (in octets) used during a session after the last 2482 tariff switch for the service specified via the QID SubType and the 2483 accompanying PPAQ attribute. 2485 0 1 2 3 2486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | SubType | LENGTH | VALUE ... 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 The fields have the following meaning and encoding: 2493 SubType : Value(23) 2495 LENGTH : variable (8 or 14) 2497 VALUE : Data type String 2499 The content of the VALUE field either contains the 2500 Value-Digits Field or the Value-Digits Field plus the 2501 Exponent Field. The length field indicates whether one or 2502 both subtypes are included. 2504 VolumeUsedAfterTariffSwitch SubType 2506 4.5.2. TariffSwitchInterval SubType 2508 The TariffSwitchInterval (TSI) SubType MUST be present in each PTS 2509 attribute that is part of a RADIUS Access-Accept message (PPS to PPC 2510 direction). It indicates the interval (in seconds) between the value 2511 of Event-Timestamp RADIUS attribute (see [RFC2869]) of the 2512 corresponding RADIUS Access-Request message and the next tariff 2513 switch condition. 2515 0 1 2 3 2516 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | SubType | LENGTH | VALUE ... 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | VALUE | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 The fields have the following meaning and encoding: 2525 SubType : Value(24) 2527 LENGTH : 6 2529 VALUE : Data type string 2531 This field contains a 16-bit unsigned integer 2532 (with the values 0 to +65,535). 2534 TariffSwitchInterval SubType 2536 4.5.3. TimeIntervalafterTariffSwitchUpdate SubType 2538 The PPS MUST include TimeIntervalafterTariffSwitchUpdate (TITSU) 2539 SubType if there is another tariff switch period after the period 2540 that ends as indicated by the TSI SubType. The value of the TITSU 2541 SubType contains the number of seconds of the tariff period that 2542 begins immediately after the period that ends as indicated by the TSI 2543 attribute. If the TITSU SubType is not present, the PPC assumes that 2544 the tariff period, which ends as indicated by the TSI SubType, lasts 2545 until further notice. If TITSU is specified, the PPC MUST send a 2546 quota update before the point in time specified by the TITSU SubType 2547 (see Figure 7). 2549 0 1 2 3 2550 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | SubType | LENGTH | VALUE ... 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | VALUE | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 The fields have the following meaning and encoding: 2559 SubType : Value(25) 2561 LENGTH : 6 2563 VALUE : Data type string 2565 This field contains a 16-bit unsigned integer 2566 (with the values 0 to +65,535). 2568 TimeIntervalafterTariffSwitchUpdate SubType 2570 5. Diameter RADIUS Interoperability 2572 The RADIUS Prepaid extension described in this document may need to 2573 interoperate with the Diameter Credit Control Application. Two 2574 interoperability scenarios exist, as follows. Either the AAA server 2575 is Diameter based and the AAA client is RADIUS based, or the AAA 2576 client is Diameter based and the AAA server is RADIUS based. 2578 The Diameter Credit Control Application [RFC4006] describes how to 2579 implement a prepaid accounting system using a Diameter based 2580 infrastructure. 2582 A possible procedure for accomplishing the translation of the 2583 functionality defined in Diameter Credit Control and in the RADIUS 2584 Prepaid specification is described in Appendix B. 2586 6. Security Considerations 2588 This specification describes the use of RADIUS for purposes of real- 2589 time accounting. Threats and security issues for this application 2590 are described in [RFC3579] and [RFC3580]; security issues encountered 2591 in roaming are described in [RFC2607]. 2593 This document specifies new attributes that can be included in 2594 existing RADIUS packets, which are protected as described in 2595 [RFC3579] and [RFC3576]. See those documents for a more detailed 2596 description. 2598 The security mechanisms supported in RADIUS are focused on preventing 2599 an attacker from spoofing packets or modifying packets in transit. 2600 They do not prevent an authorized RADIUS/Diameter server or proxy 2601 from modifying, inserting, or removing attributes with malicious 2602 intent. When the attributes defined in this document are modified or 2603 removed by a RADIUS proxy they may lead to incorrect accounting 2604 records being delivered to users or wrong resource consumption being 2605 collected. 2607 The described mechanism add the mechanism of capability negotiation, 2608 so that a RADIUS server can automatically discover whether a NAS 2609 supports the real-time accounting features described in this document 2610 (and even more detailed capabilities can be learned by the RADIUS 2611 server). These mechanisms are being added to ensure that neither the 2612 NAS nor the RADIUS server make incorrect assumptions about the 2613 capabilities of the other party; potentially leading to incorrect 2614 accounting and improper access to the network or other services. 2616 7. Table of Attributes 2618 The following table provides a guide which attributes may be found in 2619 which RADIUS messages, and in what quantity. 2621 Request Accept Reject Challenge Accounting # Attribute 2622 Request 2623 0-1 0 0 0 0 35 PPAC 2624 0-1 0 0 0 0 36 Session Termination 2625 Capability 2626 0+ 0+ 0 0 0+ 37 PPAQ 2627 0+ 0+ 0 0 0+ 38 PTS 2629 8. IANA Considerations 2631 This document contains a number of instructions to IANA. 2633 8.1. RADIUS Attributes 2635 This document does not require IANA to register the following four 2636 RADIUS attributes as the code registered by the Wimax Forum is re- 2637 used. The Wimax Forum SMI Network Management Private Enterprise Code 2638 is 24757. 2640 Attribute Name | Attribute Type Value 2641 --------------------------------------+----------------------------- 2642 Prepaid-Accounting-Capability (PPAC) | 35 2643 Session Termination Capability | 36 2644 Prepaid-Accounting-Operation (PPAQ) | 37 2645 Prepaid Tariff Switching (PTS) | 38 2647 8.2. New Registry: PPAC SubTypes 2649 Section 4.1 defines the SubTypes used within the PPAC attribute. 2650 IANA is asked to create a registry for these SubTypes. Each registry 2651 entry consists of a 8 bit number together with a description of the 2652 PPAC SubType. This document creates the following PPAC SubTypes for 2653 this registry: 2655 Value | SubType Name 2656 ---------+----------------------------- 2657 0 | Reserved 2658 1 | AvailableInClient 2659 2..255 | **Available for IANA registration** 2661 The semantic of the above-listed SubType is described in Section 4.1. 2663 Following the policies outline in [RFC3575] the available SubTypes 2664 (i.e., value 0 and values 2-255) with a description of their semantic 2665 will be assigned after the expert review process. Updates can be 2666 provided based on expert approval only. Based on expert approval it 2667 is possible to mark entries as "deprecated". A designated expert 2668 will be appointed by the IESG. 2670 Each registration must include a number for the SubType and the 2671 semantic of the SubType. 2673 8.3. New Registry: PPAQ SubTypes 2675 Section 4.3 defines the SubTypes used within the PPAQ attribute. 2676 IANA is asked to create a registry for these SubTypes. Each registry 2677 entry consists of a 8 bit number together with a description of the 2678 PPAQ SubType. This document creates the following PPAQ SubTypes for 2679 this registry: 2681 Value | SubType Name 2682 ---------+----------------------------- 2683 0 | Reserved 2684 1 | Quota Identifier 2685 2 | VolumeQuota 2686 3 | VolumeThreshold 2687 4 | DurationQuota 2688 5 | DurationThreshold 2689 6 | ResourceQuota 2690 7 | ResourceThreshold 2691 8 | Update-Reason 2692 9 | PrepaidServer 2693 10 | Service-ID 2694 11 | Rating-Group-ID 2695 12 | Termination-Action 2696 13 | Pool-ID 2697 14 | Pool-Multiplier 2698 15 | Requested-Action 2699 16 | Check-Balance-Result 2700 17..255 | **Available for IANA registration** 2702 The semantic of the above-listed SubTypes is described in 2703 Section 4.3. 2705 Following the policies outline in [RFC3575] the available SubTypes 2706 (i.e., value 0 and values 22-255) with a description of their 2707 semantic will be assigned after the expert review process. Updates 2708 can be provided based on expert approval only. Based on expert 2709 approval it is possible to mark entries as "deprecated". A 2710 designated expert will be appointed by the IESG. 2712 Each registration must include a number for the SubType and the 2713 semantic of the SubType. 2715 8.4. New Registry: PTS SubTypes 2717 Section 4.5 defines the SubTypes used within the PTS attribute. IANA 2718 is asked to create a registry for these SubTypes. Each registry 2719 entry consists of a 8 bit number together with a description of the 2720 PTS SubType. This document creates the following PTS SubTypes for 2721 this registry: 2723 Value | SubType Name 2724 ---------+----------------------------- 2725 0 | Reserved 2726 1 | Quota Identifier 2727 2 | VolumeUsedAfterTariffSwitch 2728 3 | TariffSwitchInterval 2729 4 | TimeIntervalafterTariffSwitchUpdate 2730 5..255 | **Available for IANA registration** 2732 The semantic of the above-listed SubTypes is described in 2733 Section 4.5. 2735 Following the policies outline in [RFC3575] the available SubTypes 2736 (i.e., value 0 and values 5-255) with a description of their semantic 2737 will be assigned after the expert review process. Updates can be 2738 provided based on expert approval only. Based on expert approval it 2739 is possible to mark entries as "deprecated". A designated expert 2740 will be appointed by the IESG. 2742 Each registration must include a number for the SubType and the 2743 semantic of the SubType. 2745 8.5. New Registry: Update-Reason 2747 Section 4.3.8 defines the Update-Reason SubType. IANA is asked to 2748 create a registry for the values contained in the Update-Reason 2749 SubType, as shown in Figure 12. Each registry entry consists of a 16 2750 bit number together with a description of the update reason. 2752 Following the policies outline in [RFC3575] the available values 2753 together with a description of their semantic will be assigned after 2754 the expert review process. Updates can be provided based on expert 2755 approval only. Based on expert approval it is possible to mark 2756 entries as "deprecated". A designated expert will be appointed by 2757 the IESG. 2759 8.6. New Registry: Termination-Action 2761 Section 4.3.12 defines the Termination-Action SubType. IANA is asked 2762 to create a registry for the values contained in the Termination- 2763 Action SubType, as shown in Figure 13. Each registry entry consists 2764 of a 8 bit number together with a description of the termination 2765 action. 2767 Following the policies outline in [RFC3575] the available values 2768 together with a description of their semantic will be assigned after 2769 the expert review process. Updates can be provided based on expert 2770 approval only. Based on expert approval it is possible to mark 2771 entries as "deprecated". A designated expert will be appointed by 2772 the IESG. 2774 8.7. New Registry: Requested-Action 2776 Section 4.3.15 defines the Requested-Action SubType. IANA is asked 2777 to create a registry for the values contained in the Requested-Action 2778 SubType, as shown in Figure 14. Each registry entry consists of a 8 2779 bit number together with a description of the requested reason. 2781 Following the policies outline in [RFC3575] the available values 2782 together with a description of their semantic will be assigned after 2783 the expert review process. Updates can be provided based on expert 2784 approval only. Based on expert approval it is possible to mark 2785 entries as "deprecated". A designated expert will be appointed by 2786 the IESG. 2788 8.8. New Registry: Check-Balance-Result 2790 Section 4.3.16 defines the Check-Balance-Result SubType. IANA is 2791 asked to create a registry for the values contained in the Check- 2792 Balance-Result SubType, as shown in Figure 15. Each registry entry 2793 consists of a 8 bit number together with a description of the 2794 requested reason. 2796 Following the policies outline in [RFC3575] the available values 2797 together with a description of their semantic will be assigned after 2798 the expert review process. Updates can be provided based on expert 2799 approval only. Based on expert approval it is possible to mark 2800 entries as "deprecated". A designated expert will be appointed by 2801 the IESG. 2803 9. Acknowledgements 2805 The authors would like to thank Bernard Aboba, Christian Guenther, 2806 Dirk Kroeselberg and John Loughney for their feedback throughout the 2807 development of this document. Additionally, the authors would like 2808 to thank the members of the Wimax Forum and the members of 3GPP2 for 2809 their help with this specification. 2811 10. References 2813 10.1. Normative References 2815 [RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to 2816 Indicate Requirement Levels", March 1997. 2818 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2819 2865: Remote Authentication Dial In User Server (RADIUS)", 2820 June 2000. 2822 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2823 Adoba, "RFC 3576: Dynamic Authorization Extensions to 2824 Remote Authentication Dial-In User Service (RADIUS)", 2825 February 2003. 2827 10.2. Informative References 2829 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2830 Authentication Protocol (EAP)", RFC 2284, March 1998. 2832 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2833 Implementation in Roaming", RFC 2607, June 1999. 2835 [RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2837 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2838 Extensions", June 2000. 2840 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 2841 Authentication Dial In User Service)", RFC 3575, 2842 July 2003. 2844 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2845 Dial In User Service) Support For Extensible 2846 Authentication Protocol (EAP)", RFC 3579, September 2003. 2848 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 2849 "IEEE 802.1X Remote Authentication Dial In User Service 2850 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2852 [RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2853 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2854 June 2004. 2856 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2857 Loughney, "RFC 4006: Diameter Credit Control Application", 2858 August 2005. 2860 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 2861 Rule Attribute", RFC 4849, April 2007. 2863 Appendix A. Example flows 2865 Note: This section is informative. 2867 This section presents certain example flows that involve the RADIUS 2868 prepaid extensions. By no means is the intent of this section to 2869 specify or recommend business logic, rating strategies, and 2870 application-level behaviour. The intent of this section is purely to 2871 illustrate some fictive scenarios and the RADIUS prepaid message 2872 flows that could be associated with these scenarios. The contents of 2873 this section should be regarded as a collection of informative 2874 examples that aim to provide guidance to implementors. 2876 A.1. A simple flow 2878 End user PPC PPS 2880 user logs on 2881 ------(1)---------> 2882 Access Request 2883 {RADIUS BASE AVPS, 2884 PPAC=00...00011} 2885 -------(2)--------> 2887 [allocates 2888 5MB quota] 2890 Access Accept 2891 {RADIUS BASE AVPS, 2892 PPAQ={QID=5, VQ = 5MB, 2893 VTH = 4.5 MB}} 2894 <-------(3)-------- 2896 service provision/metering 2897 -------(4)---------> 2899 4.5 MB consumed 2901 Access Request 2902 {RADIUS BASE AVPS, 2903 PPAQ={QID=5, VQ=4.5MB, 2904 REASON=THRESHOLD REACHED}} 2905 -------(5)---------> 2907 [allocates another 7MB 2908 to the access service] 2910 Access Accept 2911 {RADIUS BASE AVPS, 2912 PPAQ={QID=8, VQ=12MB, 2913 VTH = 11.5 MB}} 2914 <----------(6)-------------- 2915 user logs off 2916 ------(7)------- 2917 Access Request 2918 {RADIUS BASE AVPS, 2919 PPAQ={QID=8, VQ=7 MB, 2920 REASON=ACCESS SERV TERMINATED}} 2921 -------(8)---------> 2923 [reimburses 2924 user account] 2926 AA Accept 2927 {RADIUS BASE AVPS} 2928 <-------(9)-------- 2930 Figure 17: A simple example message flow 2932 The user logs on (1). The PPC sends a RADIUS Access Request message 2933 to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP 2934 indicates that both duration-based and volume-based metering is 2935 supported. However, it also indicated that multiple services, rating 2936 groups and resource pools are not supported. Note that, since this 2937 is not an "Authorize-Only" message, no PPAQ attribute with Update 2938 Reason="initial request" is included (see Section 3.7.1). The PPS 2939 then authenticates the user and authorizes the access service, as is 2940 usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at 2941 least the last message that is sent to the home AAA server during 2942 this possibly multiple-round exchange. 2944 If authentication and authorization is successful (in this example 2945 this is assumed), then the PPS identifies the user's prepaid account 2946 from the included base RADIUS AVPs, and determines the capabilities 2947 of the PPC from the PPAC attribute. Assuming that sufficient funds 2948 are available in the user's prepaid account, the PPS reserves some of 2949 these and rates the service. In this example, the PPS reserves, say, 2950 2 Euros and determines that the access service is rated at 0.4 Euro 2951 per MB. This results in 5 MB of quota being granted. The PPS also 2952 determines that the PPC should ask for this quota to be replenished 2953 once 4.5 MB have been consumed. Thus, it creates an Access Accept 2954 message with a Volume-Threshold indication of 4.5MB. It further 2955 associates the QID=5 to this reservation. This identifier can be 2956 used to later uniquely identify the prepaid session, user, account, 2957 etc. The resulting Access Accept message is sent to the PPC (3). 2959 Upon reception of message (4), the PPC provides the access service to 2960 the user and meters it accordingly. At some point in time, the 2961 threshold is reached, i.e., 4.5MB of "access service" have been 2962 consumed by the user. At that point, the PPC generates an Authorize- 2963 Only Access Request that contains the usual RADIUS attributes and a 2964 PPAQ attributes that reports the amount of consumed quota, and the 2965 request for replenishment, i.e., the Update-Reason= THRESHOLD REACHED 2966 (5). Note that the QID in this message is the same as the one 2967 previously received from the PPS. 2969 Upon reception of message (5), the PPS identifies the user and his 2970 account from the QID. In also determines that a prepaid session is 2971 ongoing, and that enough credit remains in the prepaid account in 2972 order for the access service to continue being provided. Since 4.5 2973 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2974 prepaid account. The PPS decides to reserve another 2.8 euros from 2975 the user's account. (This results in 3 euros being reserved in total 2976 at this point in time.) As the access service is rated at 0.4 euros 2977 per MB, the PPS determines that another 7 MB of quota should be 2978 granted. This results in a total cumulative quota allocation of 12 2979 MB for the access service. The PPS further calculates the new 2980 threshold value of 11.5 MB. Since this is a new quota reservation, 2981 the PPS also allocates a new QID to it, in this example QID=8. The 2982 resulting RADIUS message is sent to the PPC (6). 2984 Upon reception of message (6), the PPC updates its records and 2985 continues provisioning access to the user. At some point the user 2986 logs off (7). The PPC must then report how many resources were 2987 consumed, so that the PPC can subtract the appropriate monetary 2988 amount from the user's prepaid account. To this end the PPC 2989 constructs an Authorize-Only Access Request message with a PPAQ 2990 attributes for the access service. In this example, 7 MB were 2991 consumed by the access service in total. The PPC reports 7 MB its 2992 final message (8). The PPS correlates the report, using the QID, to 2993 the previous session state. It determines, from the previous 2994 records, that the access service had consumed another 4.5 MB before 2995 (as indicated in message (6)). This means that, of the 7 MB, only 2996 3.5 MB have not yet been subtracted from the user's account. Thus, 2997 the PPS subtracts another 1.4 euros from the user's account and, 2998 since the session is to be terminated (REASON=ACCESS SERVICE 2999 TERMINATED), releases any reserved monetary amount. 3001 The PPS responds with an Access Response as required by the RADIUS 3002 base specification (9). 3004 A.2. A flow with prepaid tariff switching 3006 End user PPC PPS 3008 user logs on 3009 ------(1)---------> 3010 Access Request 3011 {RADIUS BASE AVPS, 3012 PPAC=00...00111} 3013 -------(2)--------> 3015 [allocates 3016 20MB quota] 3018 Access Accept 3019 {RADIUS BASE AVPS, 3020 PPAQ={QID=5, VQ = 20MB, 3021 VTH = 18 MB}, PTS={ 3022 QID=5, PTS{TSI=300sec, 3023 TITSU=6000sec}} 3024 <-------(3)------- 3026 service provision/metering 3027 -------(4)---------> 3029 5900 seconds 3030 passed 3031 Access Request 3032 {RADIUS BASE AVPS, 3033 PPAQ={QID=5, VQ=14MB, 3034 REASON=TITSU APPROACH.}, 3035 TSI={QID=5, VUATS=11MB}} 3036 -------(5)---------> 3038 [allocates another 10MB 3039 to the access service] 3041 Access Accept 3042 {RADIUS BASE AVPS, 3043 PPAQ={QID=8, VQ=30MB, 3044 VTH = 28 MB},PTS={ 3045 QUD=8, PTS=95 sec}} 3046 <----------(6)-------------- 3048 user logs off 3050 ------(7)------- 3052 Access Request 3053 {RADIUS BASE AVPS, 3054 PPAQ={QID=8, VQ=17 MB, 3055 REASON=ACCESS SERV TERMINATED}, 3056 PTS={QID=8, VUATS=2.5 MB} 3057 -------(8)---------> 3059 [reimburses 3060 user account] 3062 AA Accept 3063 {RADIUS BASE AVPS} 3064 <-------(9)-------- 3066 Figure 18: Example message flow with Tariff Switch 3068 The user logs on (1). The PPC sends a RADIUS Access Request message 3069 to the home AAA server (2), and includes the prepaid-specific PPAC 3070 AVP. This AVP indicates that both duration-based and volume-based 3071 metering is supported, as well as tariff switching. The home AAA 3072 server then may authenticate and user and authorize the access 3073 service, as is usual in RADIUS. Note that the PPAC AVP is appended 3074 by the PPC in at least the last message that is sent to the PPS 3075 during this possibly multiple-round exchange. 3077 If authentication and authorization is successful (in this example 3078 this is assumed), the PPS identifies the user's prepaid account from 3079 the included base RADIUS AVPs, and determines the capabilities of the 3080 PPC from the PPAC attribute. In this example, it is assumed that a 3081 tariff switch is about to occur in 300 seconds from the current time. 3082 Suppose that the access service is currently rated at 0.5 euros per 3083 MB and in the next tariff period it is rated at 0.6 euros per MB. 3084 Suppose further that a third tariff period is about to start in 6000 3085 seconds from current time and that that access service is rated at 3086 0.8 euros per MB in that period. The PPS then decides to reserve 12 3087 euros from the user's account. Since it is conceivable that the user 3088 may consume all allocated quota in the (more expensive) "0.6-euro" 3089 period, the PPS reserves 20 MB of quota, and determines a threshold 3090 value of 18 MB. It constructs a Radius Access Accept message with a 3091 PPAQ attribute that reflects these choices, and carries a Quota 3092 Identifier QID=5. It further adds a PTS AVP in the message which is 3093 linked to the PPAQ via the common QID value. The PTS AVP contains a 3094 TSI attribute indicating that a tariff switch will occur in 300 3095 seconds. It also includes a TITSU attribute with the value of 6000 3096 seconds. This is included in order to make sure that the PPC will 3097 report the consumed quota before the "2-euro" tariff period will 3098 start. The message is sent to the PPC (3). 3100 Upon reception of message (3), the PPC provides the access service to 3101 the user and meters it accordingly (4). It also keeps track of time. 3102 That is, it remembers how many octets are consumed before and how 3103 many after the tariff switch that will take place in 300 seconds. 3105 In this example it is assumed that the user consumes the allocated 3106 quota rather slowly. In particular, nearly 6000 seconds (the value 3107 indicated by TITSU SubType) pass without the threshold of 18 MB being 3108 reached. The PPC notices this and must therefore report usage and 3109 request the quota to be replenished despite the fact that the 3110 threshold has not been reached. In this example, it decides to do so 3111 100 seconds before the 6000 seconds are reached. To this end, it 3112 constructs an Authorization Access Request message including a PPAQ 3113 that indicates that 14 MB have been consumed up to now. It also 3114 includes a PTS attribute in order to indicate, using the VUATS 3115 SubType, that 11 MB of these were consumed after the tariff switch. 3116 The message is sent to the the PPS (5). 3118 The PPS can link the message to previous session state via the QID. 3119 It now rates the consumed volume as follows. The 11 MB that were 3120 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 3121 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 3122 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 3123 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 3125 The PPS now determines that message (5) was sent in order to 3126 replenish the quota for this prepaid session. This can be deduced 3127 from the UPDATE REASON field, which indicates that the PPC sent this 3128 message because the time indicated by the TITSU SubType is 3129 approacing. The PPS now determines that enough credit remains in the 3130 user's prepaid account in order for the access service to continue 3131 being provided and decides to reserve another 8.9 euros from the 3132 user's account. Since it is conceivable that the user will consume 3133 the 6 unused MB of quota from the previous allocation, as well as the 3134 entire quota that is to be allocated now, entirely in the "0.8-euro" 3135 period, the quota that should now be granted in addition to the 3136 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 3137 are being reserved in order to "cover the worst case scenario". The 3138 fact that 0.9 euros are reserved for this purpose is due to the fact 3139 that the unused 6 MB from the previous allocation correspond to 4.8 3140 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 3141 than the amount of funds that are still "reserved" from the previous 3142 allocation. (After this reservation, the total amount of reserved 3143 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 3144 being consumed in the "0.8-euro" period.) 3145 Since quotas are encoded in a cumulative way in RADIUS, the PPS 3146 includes a VolumeQuota of 30 MB into the Access Accept message (6). 3147 The PPS further calculates the new threshold value of 28 MB. Since 3148 this is a new quota reservation, the PPS also allocates a new QID to 3149 it, in this example QID=8. The resulting RADIUS message is sent to 3150 the PPC (6). 3152 Upon reception of message (6), the PPC updates its records and 3153 continues providing access to the user. At some point the user logs 3154 off (7). The PPC must then report how many resources were consumed, 3155 so that the PPC can subtract the appropriate monetary amount from the 3156 user's prepaid account. To this end the PPC constructs an Authorize- 3157 Only Access Request message with a PPAQ attributes for the access 3158 service. In this example, 17 MB were consumed by the access service 3159 in total. The PPC reports 17 MB its final message (8). The PPS 3160 correlates the report, using the QID, to the previous session state. 3161 It determines, from the previous records, that the access service had 3162 consumed 14 MB before (as indicated in message (5)). This means 3163 that, of the 17 MB, only the monetary equivalent for 3 MB have not 3164 yet been subtracted from the user's account. The PPS calculates how 3165 much should be deducted from the user's account as follows. Since 3166 the VUATS SubType indicates that 2.5MB were consumed after the tariff 3167 switch, only 0.5 MB were consumed before that. Thus, the monetary 3168 equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. That is, the PPS 3169 subtracts 3.6 euros from the user's prepaid account. Since the 3170 session has by now be terminated by the PPC (REASON=ACCESS SERVICE 3171 TERMINATED), the PPS now releases any reserved monetary amount, in 3172 this example 12.8 - 3.6 = 9.2 euros. 3174 The PPS responds with an Access Response as required by the RADIUS 3175 base specification (9). 3177 Remark: In this example, two tariff switches take place. In other 3178 scenarios, of course, only one tariff switch may occur. In such 3179 scenarios the TITSU SubType is not used. 3181 A.3. Resource pools and Rating Groups 3183 End user PPC PPS 3185 user logs on 3186 ------(1)---------> 3188 Access Request 3189 {RADIUS BASE AVPS, 3190 PPAC=00...00101111} 3191 -------(2)--------> 3193 [allocates 3194 5MB quota] 3196 Access Accept 3197 {RADIUS BASE AVPS, 3198 PPAQ={QID=5, VQ = 5MB, 3199 poolID=1,mult=1}} 3200 <-------(3)-------- 3202 service provision/metering 3203 -------(4)---------> 3205 user requests service A 3206 -------(5)---------> 3208 Access Request 3209 {RADIUS BASE AVPS,PPAQ={ 3210 SID="A", RGROUP=1}} 3211 -------(6)--------> 3213 [allocates 50 min 3214 quota] 3216 Access Accept 3217 {RADIUS BASE AVPS, 3218 PPAQ={QID=7, DQ=3000sec 3219 poolID=1,RGROUP=1, SID="A" 3220 mult=1747.63}} 3221 <---------(7)--------------- 3223 user requests service B 3224 -------(8)--------> 3226 Pool 1 close to exhaustion 3228 Access Request 3229 {RADIUS BASE AVPS, 3230 PPAQ={QID=5, VQ=4MB, 3231 REASON=QUOTA REACHED, 3232 PoolID=1, mult=1} 3233 PPAQ={QID=7, DQ=3300sec 3234 REASON=QUOTA REACHED, 3235 PoolID=1, mult=1747.63, 3236 SID="A",RGROUP=1}} 3237 -------(9)---------> 3239 [allocates another 3240 3 MB to access service 3241 and 30 minutes to 3242 service "A"] 3244 Access Accept 3245 {RADIUS BASE AVPS, 3246 PPAQ={QID=8, VQ=8MB, 3247 PoolID=1, mult=1, RGROUP=1}, 3248 PPAQ={QID=9, DQ=4800sec 3249 PoolID=1, mult=1747.63, 3250 SID="A"}} 3251 \ <----------(10)-------------- 3253 user logs off 3254 ------(11)------- 3255 Access Request 3256 {RADIUS BASE AVPS, 3257 PPAQ={QID=8, VQ=6.5MB, 3258 REASON=ACCESS SERV TERMINATED, 3259 PoolID=1, mult=1} 3260 PPAQ={QID=9, DQ=5400sec 3261 REASON=ACCESS SERV TERMINATED, 3262 PoolID=1, mult=1747.63, 3263 SID="A",RGROUP=1}} 3264 -------(12)---------> 3266 [reimburses 3267 user account] 3269 AA Accept 3270 {RADIUS BASE AVPS 3271 <------(13)-------- 3273 Figure 19: Example message flow with resource pools and rating groups 3275 The user logs on (1). The PPC sends a RADIUS Access Request message 3276 to the PPS (2), and includes the prepaid-specific PPAC AVP, 3277 indicating that multiple services, rating groups and resource pools 3278 are supported. Note that, since this is not an "Authorize- Only" 3279 message, no PPAQ attribute with Update Reason="initial request" is 3280 included (see Section 3.7.1). The PPS then may authenticate the user 3281 and authorize the access service, as is usual in RADIUS. Note that 3282 the PPAC AVP is appended by the PPC in at least the last message that 3283 is sent to the PPS during this possibly multiple-round exchange. 3285 If authentication and authorization is successful (in this example 3286 this is assumed), the PPS identifies the user's prepaid account from 3287 the included base RADIUS AVPs, and determines the capabilities of the 3288 PPC from the PPAC attribute. Assuming that sufficient funds are 3289 available in the user's prepaid account, the PPS reserves some of 3290 these and rates the service. In this example, the PPS reserves 5 3291 Euros and determines that the access service is rated at 1 Euro per 3292 MB. In anticipation that the user requests more chargeable services 3293 throughout this prepaid session, and since this is supported by the 3294 PPC, the PPS further associates a resource pool with this 3295 reservation, in this example PoolID=1. The PPC also specifies the 3296 multiplier = 1 for the access service. Note that, since 5MB = 3297 5242880 octets, 1 unit in the resource pool corresponds to 5 / 3298 5242880 euros, which is about 0.000095367431640625 Eurocents. 3299 (However, the PPC does not need to know that.) Moreover, the PPS 3300 associates the QID=5 to this reservation. This identifier can be 3301 used to later uniquely identify the prepaid session, user, account, 3302 etc. The resulting Access Accept message is sent to PPC (3). 3304 Upon reception of message (3), the PPC provides the access service to 3305 the user and meters it accordingly (4). That is, for every octet 3306 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 3307 the resouce pool with PoolID=1. 3309 At some point in time, the user requests another chargeable service, 3310 namely service A (5). The PPC generates an Authorize-Only Access 3311 Request that contains the usual RADIUS attributes and the Service-ID 3312 identifying service A (6). The PPC has determined that service A is 3313 rated in an identical way as at least one more service. Thus, 3314 service A has been configured to belong to a rating group, in this 3315 example the group with Rating-Group-ID=1. This identifier is 3316 included is message (6). 3318 Upon reception of message (6), the PPS identifies the user and his 3319 account from the base RADIUS attributes, the fact that a prepaid 3320 session is ongoing, and determines that enough credit remains in the 3321 prepaid account in order for service A to be provided. The PPS also 3322 determines that service A is rated at 0.10 euros per minute. The PPS 3323 decides to reserve another 5 euros from the users account; this 3324 corresponds to 50 minutes or, as encoded in the DurationQuota 3325 SubType, 3000 seconds. As service A draws from the same prepaid 3326 account as the access service, the PPS associates this reservation 3327 with the same resource pool as the previous reservation (QID=5), 3328 namely the pool with PoolID=1. Note that, in order for the abstract 3329 units in the pool to be consistent, the multiplier has to be 1747.63. 3330 This is because each second corresponds to about 0.10 / 60 = 0.00167 3331 euros, which is about 1747.63 times the value of an abstract resource 3332 pool unit, as this was determined by the first allocation of quota to 3333 the pool (i.e., 0.000095367431640625 Eurocents). Since this is a new 3334 quota reservation, the PPS also allocates a new QID to it, in this 3335 example QID=7. The resulting RADIUS message is sent to the PPC (7). 3337 Upon reception of message (7), the PPC adjusts the units in resource 3338 pool 1. That is, it first determines how much quota had been 3339 allocated to service A in the past, and subtracts this from the quota 3340 reservation found in the message. Since this is the first quota 3341 reservation for service A, there is nothing to subtract. Thus, it 3342 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 3343 3000 seconds have been allocated to service A during this prepaid 3344 session. The PPC then provides service A to the user, and meters it 3345 against resource pool 1. That is, for every second it subtracts 3346 1747.63 units from the pool. 3348 At some point in time, the user requests service B (8). The PPC 3349 determines that service B is rated exactly in the same way as service 3350 A, i.e., that they belong to the same rating group, namely the one 3351 with Rating-Group-ID=1. Since this rating group has been effectively 3352 authorised by the allocation of quota with QID=7, the PPC provides 3353 service B to the user immediately. It is rated in the same way as 3354 service A, i.e., for every second provided, 1747.63 units are 3355 subtracted from credit pool 1. 3357 At some point in time, resource pool 1 is close to exhaustion. (For 3358 example, the PPC may determine that the pool is "close to exhaustion" 3359 when has less than 10% its initial amount of units.) At that point, 3360 the PPC needs to ask for replenishment for the pool. Suppose that, 3361 at that point in time, 4MB of "access service", 45 minutes of 3362 "service A", and 10 minutes of "service B" were provided to the user. 3363 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 3364 + 5767179 = 9961483 abstract service units from the pool. The PPC 3365 constructs an Authorize-Only Access Request message that reports the 3366 usage for the "access service" and "service A". This message 3367 contains two PPAQ attributeS, is sent to the PPS (9). Note that is 3368 the message it appears that "service A" has consumed more than it was 3369 allocated (i.e., 55 minutes although only 50 minutes were initially 3370 allocated to it). This is not a a problem since the PPS knows that 3371 "service A" was drawing from the same pool as the "access service" 3372 and that the "access service" did only consume 4 out of the 5 MB it 3373 was allocated. 3375 Upon reception of message (9), the PPS subtracts 4 euros from the 3376 user's account for the "access service" and another 5.5 euros for 3377 "service A". (This includes the charge incurred by "service B" up to 3378 that point in time, although the PPS is not aware of "service B" 3379 being provisioned to the user.) The PPS then determines that 3380 sufficient funds remain in the prepaid account in order for both 3381 services to be continued. The PPS decides to reserve another 3MB for 3382 the access service and 30 minutes for "service A". This corresponds 3383 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 3384 cumulative manner, the PPAQ attribute that grants the quota for the 3385 "access service" contains a Volume-Quota SubType of 8MB (8388608 3386 octets), which is the 5MB that were initially allocated, plus the 3MB 3387 allocated now. The resource pool identifier is, as previously, 3388 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 3389 quota for "service A" contains 4800 seconds (the initial 3000 plus 3390 1800 that correspond to the 30 additional minutes). Again, the 3391 PoolID=1 and multiplier=1747.63. The resulting Access Response 3392 message is sent to the PPC (10). 3394 When the PPC received message (10) it checks how much quota has been 3395 allocated previously to the "access service". It finds that the 3396 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 3397 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 3398 have not yet been added to resource pool 1. The PPC thus adds 3399 3145728 abstract units to resource pool 1 (since the multiplier is 3400 1). The PPC then acts similarly on the other PPAQ attribute that 3401 exists in message (11). That is, the PPC determines that 3000 3402 seconds of quota for "service A" had already been added to the pool. 3403 Thus only 1800 out of the 4800 should be additionally added to the 3404 pool. Since the applicable multiplier here is 1747.63, the PPC adds 3405 further 3145734 abstract units to the pool 1. 3407 The PPC then continues to provide the access service, "service A" and 3408 "service B" to the user, and meters them against the pool, as 3409 previously. 3411 At some point the user logs off (11). The PPC must then report how 3412 many resources were consumed, so that the PPC can subtract the 3413 appropriate monetary amount from the user's prepaid account. To this 3414 end the PPC constructs an Authorize-Only Access Request message with 3415 two PPAQ attributes; one for the access service and one for "service 3416 A". Suppose that, in total, 6.5MB were consumed by the access 3417 service, 70 minutes were consumed by "service A" and 20 minutes by 3418 "service B". The PPC reports 6.5MB (6815744 octets) and 90 minutes 3419 (5400 seconds) in its final message (12). The PPS determines, from 3420 the previous records, that the access service consumed another 2.5MB 3421 (since 4MB out of the 6.5MB were already reported in message (9), and 3422 that "service A" consumed further 600 seconds. This corresponds to 3423 2.5 + (600/60)*0.1 = 2.5+ 1=3.5 euros. Thus, the PPS only subtracts 3424 2.5 out of the 6 previously reserved euros from the user's prepaid 3425 account and responds with an Access Response as required by the 3426 RADIUS base specification (13). 3428 A.4. One-time charging 3429 End user PPC PPS 3431 user requests ring tone 3432 ------(1)---------> 3434 Access Request 3435 {RADIUS BASE AVPS, 3436 PPAQ={QID=321, SID=X, RQ=650, 3437 REASON=10 (ONE-TIME CHARGING}} 3438 -------(2)---------> 3440 [rates 650 abstract units 3441 deducts from user's account] 3443 Access Accept 3444 {RADIUS BASE AVPS} 3445 <----------(3)-------------- 3447 ring tone is delivered 3448 <------(4)------- 3450 Figure 20: Example message flow with one-time charging 3452 The user requests a chargeable ring tone (1). The PPC sends a RADIUS 3453 Access Request message to the PPS (2), and includes a PPAQ attribute 3454 with Update Reason="one-time charging" is included (see 3455 Section 3.8.6). The Service ID indicates to the PPS that the 3456 charging event is connected to a ring tone, so that the PPS can rate 3457 the event accordingly. The PPAQ also contains a unique Quota 3458 Identifier. 3460 The PPS then may authenticate the user as is usual in RADIUS. If 3461 authentication is successful (in this example this is assumed), the 3462 home AAA server forwards the PPC converts the 650 reported abstract 3463 units into monetary value, according to the service type, and debit 3464 the user's account accordingly. This happens, of course, only if 3465 sufficient funds are available in the user's prepaid account. The 3466 PPC then responds with an an Access Accept message (3). The PPS adds 3467 a "session timeout = 0 AVP" (see Section 3.8.6). 3469 A.5. Price enquiry 3470 End user PPC PPS 3472 user requests AoC 3473 ------(1)---------> 3475 Access Request 3476 {RADIUS BASE AVPS, 3477 PPAQ={SID=X, VQ=10MB, 3478 REQ_ACT=2(PRICE ENQUIRY}} 3479 -------(2)---------> 3481 [rates 10MB for requested 3482 service] 3484 Access Accept 3485 {RADIUS BASE AVPS, 3486 PPAQ={SID=X, VQ=10MB, 3487 COST INFORMATION= 0.6 euros 3488 per MB}} 3489 <----------(3)-------------- 3491 AoC is delivered 3492 <------(4)------- 3494 Figure 21: Example message flow with price enquiry (advice of charge) 3496 Please refer to Section 2.7.3 for an explanation of this message 3497 flow. 3499 A.6. Balance check 3500 End User PPC PPS 3502 Access Request 3503 {RADIUS BASE AVPS, 3504 PPAQ={SID=X, VQ=10MB, 3505 REQ_ACT=BALANCE CHECK}} 3506 -------(2)---------> 3508 [rates requested 3509 Service and checks 3510 remaining funds] 3512 Access Accept 3513 {RADIUS BASE AVPS, 3514 PPAQ={SID=X, VQ=10MB, 3515 BALANCE_CHECK_RESULT}} 3516 <----------(3)-------------- 3518 Figure 22: Example message flow with balance check 3520 Please refer to Section 2.7.4 for an explanation of this message 3521 flow. 3523 Appendix B. Translation between RADIUS Prepaid and Diameter Credit 3524 Control 3526 Note: This section is informative. 3528 In scenarios where the service metering device uses the "RADIUS 3529 prepaid" (RPP) protocol for accounting and prepaid charging while the 3530 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 3531 a translation agent that enables the interoperation of both systems, 3532 is desirable. This also applies vice versa, i.e., in scenarios where 3533 the AAA infrastructure uses RADIUS and the service metering device 3534 uses Diameter. 3536 The idea of such a translation agent would be to convert incoming RPP 3537 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 3538 would be, in principle, desirable for the translation agent to be 3539 stateless. That is, the agent should not be required to internally 3540 maintain information about each ongoing RADIUS or Diameter session. 3541 However, under the current specification of RPP and DCC, this appears 3542 to be impossible due to a number of reasons. These include the 3543 following. 3545 1. The transport mechanism for DCC is TCP, which requires per- 3546 session state to be maintained at both endpoints of the 3547 communication. Note, however, that, in principle, each DCC 3548 message could be sent over a dedicated TCP connection which is 3549 torn down as soon as the message is sent. This, however, is 3550 likely to be unacceptable in terms of efficiency. 3552 2. While RPP messages encode the cumulative amount of consumed/ 3553 requested resources, DCC messages carry the difference from the 3554 previous message. This means that the translation agent has to 3555 maintain the current amount of consumed/requested resources in 3556 order to be able to calculate the correct amount to be put into 3557 an outgoing message. 3559 The translator maps each incoming RPP (resp. DCC) message into an 3560 outgoing DCC (resp. RPP) message, and possibly establishes or updates 3561 local state that is associated with the session. The translated 3562 (i.e., outgoing) message is a function of the incoming message as 3563 well as existing state that is associated with the current session. 3565 Translation occurs on an attribute-by-attribute basis. Certain 3566 attributes are translated without consideration of local per-session 3567 state. Other attributes, namely those that are bound to a particular 3568 session, require such consideration. The translation agent has to 3569 identify the session (and possibly subsession) an incoming message 3570 belongs to in order to consult the appropriate local per-session 3571 state. 3573 Note that certain DCC attributes cannot be translated due to their 3574 semantics not being present in RPP, and vice versa. This results in 3575 the messages, in which these attributes occur, not being delivered to 3576 their intended destination. In such cases it is desirable to inform 3577 the originator about the failure and terminate the session. 3579 In each scenario (i.e., RPP client / DCC AAA infrastructure and DCC 3580 client / RPP AAA infrastructure), the translator operates in two 3581 directions, namely RPP to DCC and vice versa. In the following 3582 sections, the notation c->s means that the attribute in question may 3583 occur only in the direction from the client to the server. The 3584 notation s->c denotes the converse and the notation c<->s denotes 3585 that the attribute may occur in messages that are directed in either 3586 direction. 3588 B.1. Session Identification 3590 The translation agent has to keep per-session state in order to 3591 perform its task. A session may be identified based on the RPP 3592 identifier or the DCC session identifier. That is, the translation 3593 agent should always maintain a pair of (RPP, DCC) session identifiers 3594 and maintain the per-session state in association with that pair. 3595 This per-session state must be addressable by either of these two 3596 identifiers. Moreover, an RPP session identifier must uniquely 3597 correspond to a DCC identifier. (If this holds, the converse also 3598 holds.) Each subsession identifier within an RPP session must also 3599 uniquely correspond to a subsession identifier within its 3600 corresponding DCC session. (If this holds the converse also holds.) 3602 B.2. Translation between RADIUS Prepaid and Diameter Credit Control 3604 This section describes the translator in the "RPP client / DCC AAA 3605 infrastructure" case. In other words, in this section it is assumed 3606 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 3607 The translator is assumed to sit somewhere in the middle and to 3608 mediate between client and server. 3610 For each RPP AVP (i.e., AVPs that are specified in the present 3611 document), the transformation into a semantically equivalent DCC AVP 3612 (if such an AVP exists), along with what per-session state the 3613 translator has to create or consult, is described. For clarity of 3614 exposition, each RPP AVP is addressed in a separate subsection. 3615 Since in this scenario, the PPC is typically the initiator a session, 3616 the focus is on the RPP AVPs. 3618 B.2.1. PPAC (c<->s) 3620 A DCC client is assumed to always support Volume metering, Duration 3621 metering, Resource metering, Pools, Rating groups, and Tariff 3622 Switching. Thus, if a PPAQ that indicates any of the above is sent 3623 client->server, the translator does the following: It lets message go 3624 through but remembers what exactly the client supports. If the 3625 server later requests (servier -> client direction) an unsupported 3626 metering to be performed, send failure to server and cause the 3627 session to be terminated at the client. 3629 If a PPAC indicates support for multiple services (0x00000020), the 3630 translator maps this onto a DCC Multiple-Services- Indicator AVP. 3632 B.2.2. Service Termination Attribute (c->s) 3634 The Diameter base protocol assumes that the client always supports 3635 dynamic session termination. If this AVP is present, the translator 3636 does not need to do anything, i.e., there exists no DCC AVP that this 3637 AVP can be mapped to. If this AVP is absent, the message in which it 3638 appears should either be discarded and originator should be informed 3639 of a failure, or the message can be passed on (without this AVP being 3640 mapped onto a DCC AVP). However, in the latter case, the translator 3641 has to remember that the client does not support dynamic termination. 3642 Thus, the translatior has to initiate the normal session termination 3643 procedure with the client when (if) dynamic termination is later 3644 initiated by the server. 3646 B.2.3. Quota Identifier Attribute (c<->s) 3648 When quota is allocated for the first time by the DCC server, the 3649 translator has to create a QID AVP, as required by this 3650 specification. The translator later uses a QID AVP that is sent in 3651 the client-to-server direction in order to identify the corresponding 3652 DCC session. The QID has to be saved in the translator's per session 3653 state. 3655 B.2.4. Volume Quota Attribute (c<->s) 3657 If this AVP occurs in a message that is sent in the server-to-client 3658 direction, it is translated into a Granted-Service-Unit AVP with an 3659 embedded CC-Total-Octets AVP. 3661 If this AVP occurs in a message that is sent in the client-to-server 3662 direction, then it is translated into a Used-Service-Unit AVP with an 3663 embedded CC-Total-Octets AVP. Note that only the difference between 3664 current cumulative quota for the (sub)session and the quota in 3665 incoming messages is indicated in the translated DCC message. Local 3666 state is updated with cumulative consumed resources. 3668 Conversely, if the server grants quota using the DCC Granted-Service- 3669 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 3670 agent must translate this into a Volume Quota Attribute. Again, 3671 local state must be consulted so that the cumulative amount of octets 3672 is indicated in the Volume Quota attribute. 3674 B.2.5. Duration Quota Attribute (c<->s) 3676 If this AVP occurs in a message that is sent in the server-to-client 3677 direction, it is translated into a Granted-Service-Unit AVP with an 3678 embedded CC-Time AVP. 3680 If this AVP occurs in a message that is sent in the client-to-server 3681 direction, then it is translated into a Used-Service-Unit AVP with an 3682 embedded CC-Time AVP. Note that only the difference between current 3683 cumulative quota for the (sub)session and the quota in incoming 3684 messages is indicated in the translated DCC message. Local state is 3685 updated with cumulative consumed resources (i.e., time). 3687 Conversely, if the server grants quota using the DCC Granted-Service- 3688 Unit AVP with an embedded CC-Time AVP, then the translation agent 3689 must translate this into a Duration Quota attribute. Again, local 3690 state must be consulted so that the cumulative amount of seconds is 3691 indicated in the Duaration Quota attribute. 3693 B.2.6. Resource Quota Attribute (c<->s) 3695 If this AVP occurs in a message that is sent in the server-to-client 3696 direction, it is translated into a Granted-Service-Unit AVP with an 3697 embedded CC-Service-Specific-Units AVP. 3699 If this AVP occurs in a message that is sent in the client-to-server 3700 direction, then it is translated into a Used-Service-Unit AVP with an 3701 embedded CC-Service-Specific-Units AVP. Note that only the 3702 difference between current cumulative quota for the (sub)session and 3703 the quota in incoming messages is indicated in the translated DCC 3704 message. Local state is updated with cumulative consumed resources 3705 (i.e., resources). 3707 Conversely, if the server grants quota using the DCC Granted-Service- 3708 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 3709 translation agent must translate this into a Resource Quota 3710 attribute. Again, local state must be consulted so that the 3711 cumulative amount of resource units is indicated in the Resource 3712 Quota attribute. 3714 Note that the "resource" type is application dependent. This means 3715 that a DCC application unit corresponds to n RPP application units, 3716 where n may be any real number. If n is not 1, then the RPP/DCC 3717 translator must be aware of that and translate resource units 3718 accordingly. 3720 B.2.7. Value Digits Attribute (c<->s) 3722 The encoding of this AVP is similar in RPP and DCC, and the value it 3723 holds may have to be evaluated in conjunction with an acommpanying 3724 "Exponent" AVP. It should be kept in mind that, in RPP the 3725 cumulative amount of granted/consumed quota is typically encoded into 3726 an AVP of this type, while in DCC only the difference from a previous 3727 message. 3729 B.2.8. Exponent Attribute (c<->s) 3731 The encoding of this AVP is similar in RPP and DCC, and the value it 3732 holds may have to be evaluated in conjunction with an acommpanying 3733 "Value Digits" AVP. It should be kept in mind that, in RPP the 3734 cumulative amount of granted/consumed quota is typically encoded into 3735 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 3736 the difference from a previous message is encoded into such a pair. 3738 B.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 3740 In DCC the concept of "threshold" does not exist. Instead, the DCC 3741 client is assumed to ask for the replenishment of quota in good time. 3742 In RPP, on the other hand, the server may optionally include a 3743 threshold AVP, as an indication to the PPC about when to ask for 3744 quota replenishment. 3746 Thus, in this scenario, there is no need for the translator to ever 3747 include a threshold attribute into the messages that it sends to the 3748 PPC. If, however, there is a need for a threshold attribute to be 3749 present in order to avoid a possible service provision 3751 B.2.10. Update Reason Attribute (c->s) 3753 The DCC AVP that is semantically closer to the Update Reason AVP than 3754 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 3755 the message is which it appears is intended to indicate an "initial", 3756 an "intermediate" or a "final interrogation". Morever, in case of 3757 the session being terminated at the client, it indicates the reason 3758 for this termination. 3760 The following list lists the possible values of an "Update Reason" 3761 attribute, along with corresponding values for the CC-Request-Type 3762 AVP. 3764 o Pre-initialization: No action/value defined. 3766 o Initial Request: Typically an "intial interrogation" is triggered 3767 as a result of the reception of the message that contains this 3768 Update Reason AVP. Hence, CC-Request-Type AVP indicates 3769 "INITIAL_REQUEST". 3771 o Threshold Reached: The reception of the message containing this 3772 Update Reason AVP typically triggers an "intermediate 3773 interrogation". Hence, CC-Request-Type AVP indicates 3774 "UPDATE_REQUEST". 3776 o Quota Reached: The reception of the message containing this Update 3777 Reason AVP typically triggers an "intermediate interrogation". 3778 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 3780 o TITSU Approaching: The reception of the message containing this 3781 Update Reason AVP typically triggers an "intermediate 3782 interrogation". Hence, CC-Request-Type AVP indicates 3783 "UPDATE_REQUEST". 3785 o Remote Forced Disconnect: Reception of such an Update Reason 3786 indicates that the client has terminated the session. The 3787 corresponding value for the CC-Request-Type AVP is 3788 "TERMINATION_REQUEST". 3790 o Client Service Termination: Reception of such an Update Reason 3791 indicates that the client has terminated the session. The 3792 corresponding value for the CC-Request-Type AVP is 3793 "TERMINATION_REQUEST". 3795 o "Access Service" Terminated: Reception of such an Update Reason 3796 indicates that the client has terminated the session. The 3797 corresponding value for the CC-Request-Type AVP is 3798 "TERMINATION_REQUEST". 3800 o Service not established: Reception of such an Update Reason 3801 indicates that the client has terminated the session. The 3802 corresponding value for the CC-Request-Type AVP is 3803 "TERMINATION_REQUEST". 3805 o One-Time Charging: Such an Update Reason indicates that a one-time 3806 charging event is initiated by the client. The corresponding 3807 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 3808 "Requested-Action: AVP MUST also be included in the outgoing DCC 3809 message. Typically, this would be of the type "DIRECT_DEBITING", 3810 or "REFUND_ACCOUNT", depending on other AVPs present in the 3811 message. 3813 B.2.11. PrepaidServer Attribute (s<->c) 3815 The PPC typically never sets the value of a PrepaidServer attribute. 3816 Instead, it repeats those values that it receives from the AAA 3817 infrastructure, in this scenario from the translator. This attribute 3818 is therefore not used in a translation scenario. Nevertheless, the 3819 translator must make sure that messages about the same RPP session 3820 are forwarded to the same DCC server, throughout the whole session. 3821 This may be easy to guarantee since the transport of Diameter is TCP. 3823 B.2.12. Service-ID Attribute (s<->c) 3825 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 3826 Service-Context-Id and Service-Identifier AVPs. The translator must 3827 keep a static equivalence table of the RPP Service-ID and the 3828 corresponding DCC combination in order to correctly translate an RPP 3829 service identifier into DCC and back. 3831 B.2.13. Rating-Group-ID Attribute (s<->c) 3833 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 3834 "Rating-Group-ID". Depending on the configuration, this AVP may 3835 contain the same value on both the RPP and the DCC side of the 3836 communication. If, however, static rating groups are configured 3837 between the RCC client and the translator, and different rating 3838 groups between the DCC server and the translator, then the translator 3839 has to maintain a static translation table for the rating group 3840 identifier. In any case, the translation of a rating group AVP, is 3841 not a function of the translator's local per-session state. 3843 B.2.14. Termination-Action Attribute (s->c) 3845 The DCC equivalent of the "Termination-Action" AVP is called the 3846 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 3847 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 3848 "Termination-Action" AVP. The following list contains the possible 3849 "Final-Unit-Action" values along with their "Termination-Action" 3850 equivalent. 3852 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 3853 called "Terminate". 3855 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 3856 AVP, then a "Redirect-Server-Address" AVP must also appear in the 3857 same DCC message. The translator translates these two AVPs into a 3858 "Termination-Action" with value "Redirect/Filter" and an 3859 eqiovalent NAS-Filter-Rule attribute (specified in http:// 3860 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 3862 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 3863 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 3864 in the same DCC message. The translator translates these two AVPs 3865 into a "Termination-Action" with value "Redirect/Filter" and an 3866 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 3867 internet-drafts/draft-ietf-radext-ieee802-00.txt). 3869 o In the absence of a "Final-Unit-Action" AVP, the DCC server 3870 assumes that the DCC client will ask for replenishment of quota at 3871 some suitable time. In RPP, this is explicitly conveyed via a 3872 "Termination-Action" AVP with the value "Request More Quota". 3873 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 3874 in this scenario appends such an AVP into the outgoing RPP 3875 message. 3877 B.2.15. Pool-ID Attribute (s<->c) 3879 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 3880 Typically, no translation needs to be done to the "Pool-ID" 3881 attribute. 3883 B.2.16. Multiplier Attribute (s<->c) 3885 The multiplier attribute, which is a pair of "Value-Digits" and 3886 "Exponent" AVPs, typically needs no translation, since the value it 3887 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 3888 the rating of the service or rating group to which it refers, with 3889 respect to abstract units. As such, the same multiplier value would 3890 typically applyt be conveyed from a DCC server to an PPC, and vice 3891 versa. 3893 B.2.17. Requested-Action Attribute (c->s) 3895 The "Requested Action" AVP can be directly translated into its DCC 3896 equivalent, which carries the same name. 3898 1. Balance Check (PCC): CHECK_BALANCE (DCC) 3900 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 3902 B.2.18. Check-Balance-Result Attribute (s->c) 3904 This attribute carries only a binary value. Hence, its translation 3905 is straightforward. 3907 B.2.19. Cost-Information Attribute (s->c) 3909 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 3910 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 3911 exist in DCC, and carry identical semantics in the context of the 3912 "Cost-Information" AVP. Thus, the translation of this attribute is 3913 straightforward. 3915 B.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 3917 This attribute carries the amount of octets that were consumed after 3918 a tariff change. It always appears in a message with an accompanying 3919 PPAQ attribute in which the total amount of octets (i.e., those that 3920 were consumed both before and after the tariff switch) is reported. 3921 Thus, the translation agent can compute the amount of octets that 3922 were consumed before the tariff change. 3924 In DCC, the two amounts, i.e., the octets that were consumed before a 3925 tariff change and those that were consumed afterwards, are reported 3926 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 3927 have an embedded CC-Total-Octets AVP that indicates the appropriate 3928 amount of octets. Furthermore, the Used-Service-Unit AVP that 3929 carries the amount that was consumed before the tariff switch also 3930 carries an embedded Tariff-Change-Usage AVP with the value 3931 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 3932 that carries the amount that was consumed after the tariff switch 3933 also carries an embedded Tariff-Change-Usage AVP with the value 3934 UNIT_AFTER_TARIFF_CHANGE (1). 3936 Authors' Addresses 3938 Avi Lior 3939 Bridgewater Systems 3940 303 Terry Fox Drive 3941 Ottawa, Ontario Suite 100 3942 Canada 3944 Email: avi@bridgewatersystems.com 3946 Parviz Yegani 3947 Juniper 3949 Email: pyegani@juniper.net 3951 Kuntal Chowdhury 3952 Starent Networks 3953 30 International Place, 3rd Floor 3954 Tewksbury, MA 01876 3955 USA 3957 Email: kchowdhury@starentnetworks.com 3959 Hannes Tschofenig 3960 Nokia Siemens Networks 3961 Linnoitustie 6 3962 Espoo 02600 3963 Finland 3965 Phone: +358 (50) 4871445 3966 Email: Hannes.Tschofenig@gmx.net 3967 URI: http://www.tschofenig.priv.at 3969 Andreas Pashalidis 3970 NEC 3971 Kurfuersten-Anlage 36 3972 Heidelberg 69115 3973 Germany 3975 Email: pashalidis@gmail.com