idnits 2.17.00 (12 Aug 2021) /tmp/idnits2687/draft-lior-radius-prepaid-extensions-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (December 27, 2009) is 4527 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TS32240' is mentioned on line 266, but not defined -- Looks like a reference, but probably isn't: '3576' on line 1232 == Unused Reference: 'RFC3748' is defined on line 2856, 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 Network Working Group A. Lior 3 Internet-Draft Bridgewater Systems 4 Intended status: Informational P. Yegani 5 Expires: June 30, 2010 Juniper 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Pashalidis 11 KUL 12 December 27, 2009 14 Prepaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 16 draft-lior-radius-prepaid-extensions-17.txt 18 Abstract 20 This document specifies an extension to the Remote Authentication 21 Dial-In User Service (RADIUS) protocol that enables service providers 22 to charge for prepaid services. The supported charging models 23 supported are volume-based, duration-based, and based on one-time 24 events. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on June 30, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 70 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 9 71 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 72 1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11 73 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14 74 2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14 75 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14 76 2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16 77 2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17 78 2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18 79 2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19 80 2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19 81 2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19 82 2.7.2. Resource Consumption Query . . . . . . . . . . . . . . 20 83 2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 20 84 2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 21 85 2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21 86 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22 88 3.2. Authentication and Authorization Operation . . . . . . . . 22 89 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 24 90 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 91 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 92 3.5.1. Unsolicited Session Termination Operation . . . . . . 26 93 3.5.2. Unsolicited Change of Authorization Operation . . . . 26 94 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 27 95 3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 96 3.8. Operation Considerations for Multiple Services . . . . . . 28 97 3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 98 3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 99 3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 100 3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29 101 3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30 102 3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 103 3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30 104 3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31 105 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32 107 4.2. Session Termination Capability Attribute . . . . . . . . . 34 108 4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 36 109 4.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 52 110 4.5. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 53 111 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 59 112 6. Security Considerations . . . . . . . . . . . . . . . . . . . 60 113 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 61 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 117 10.1. Normative References . . . . . . . . . . . . . . . . . . . 67 118 10.2. Informative References . . . . . . . . . . . . . . . . . . 67 119 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 69 120 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 69 121 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 72 122 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 75 123 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 80 124 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 81 125 A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 82 126 Appendix B. Translation between RADIUS Prepaid and Diameter 127 Credit Control . . . . . . . . . . . . . . . . . . . 84 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 130 1. Introduction 132 This document specifies an extension to the RADIUS protocol that 133 enables service providers to perform accounting and charging in an 134 "online" fashion. In particular, they enable the service provider to 136 (a) ensure that subscriber's remaining funds suffice before the 137 service is delivered, and 139 (b) interrupt service provision when the funds are exhausted. 141 Note that these capabilities are typically used in scenarios where 142 the subscriber maintains a prepaid account with the service provider; 143 hence, this extension is called the "prepaid" extension for RADIUS. 144 The functionality described in this document is often referred as 145 "online charging" in comparison to "offline charging" support 146 provided by RFC 2866 [RFC2866]. 148 The extensions were designed with the following goals in mind: 150 o Make use of existing infrastructure as much as possible (including 151 enabling the interworking of RADIUS-based and Diameter-based 152 infrastructures), and thereby limit the amount of necessary 153 capital expenditures, 155 o provide the ability to rate service requests in an "online" 156 fashion, 158 o provide the ability to charge the user's account prior to service 159 provision, 161 o protect against revenue loss, i.e., to prevent an end user from 162 obtaining service when the available funds do not suffice, 164 o protect against fraud, and 166 o be deployable for a number of services independent of the access 167 network technology. 169 The architecture between the entities that execute the RADIUS 170 protocols, with the extensions defined in this document, assumes that 171 the rating of chargeable events does not occur in the element that 172 provides the service. Instead, the rating may be performed at a 173 dedicated server, termed the "prepaid-enabled AAA server" or simply 174 "prepaid server" (PPS). Alternatively, the actual rating may occur 175 in an entity related to this prepaid server. 177 Furthermore, this document assumes that a "quota server" is available 178 which, through co-ordination with the rating entity and an account 179 balance manager, is able to provide a quota indication for a 180 particular user when requested. This quota server may or may not 181 coexist in the prepaid server. 183 1.1. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119]. 189 Prepaid Client (PPC): 191 The entity which triggers the RADIUS message exchange, including 192 the prepaid extensions defined in this document. The PPC provides 193 the service to the users, and executes the RADIUS client which, 194 for the purposes of this document, is termed the "PrePaid Client" 195 (PPC). When the prepaid service is used the PPC collects service 196 event information and reports it while the services is provided to 197 the user. This event information is sent to the PPS using the 198 extensions defined in this document. 200 Prepaid Server (PPS): 202 The entity that interacts with the PPC using the RADIUS prepaid 203 extensions defined in this document. 205 Rating Entity: 207 This entity converts the credit that is allocated by the PPS into 208 a "quota". This quota is then returned to the requesting PPC via 209 the PPS. The rating entity may also determine that during service 210 provision a tariff switch will occur. In this case the rating 211 entity will include details of when exactly tariff switch will 212 occur. 214 Quota: 216 A quota denotes the amount of granted units to be consumed without 217 performing another credit control interaction. 219 Home Network: 221 The network which contains the user profile and the user's prepaid 222 account. 224 Authorize-Only Access Request: 226 A RADIUS message of type "Access Request" (code field = 1) that 227 contains a "Service-Type" AVP (type = 6) with value "Authorize- 228 Only". 230 Offline Charging: 232 Offline charging is a process where charging information for 233 resource usage is collected concurrently with that resource usage. 234 The charging information is then passed through a chain of logical 235 charging functions. At the end of this process, Charging Data 236 Record (CDR) files are generated, which are then transferred to 237 the operator's billing domain for the purpose of subscriber 238 billing and/or inter-operator accounting (or additional functions, 239 e.g., statistics, at the operator's discretion). The billing 240 domain typically comprises post-processing systems, such as the 241 operator's billing system or billing mediation device. In 242 conclusion, offline charging is a mechanism where charging 243 information does not affect, in real-time, the service rendered. 244 [TS32240] 246 Online Charging: 248 Online charging is a process where charging information for 249 resource usage is collected concurrently with that resource usage 250 in the same fashion as in offline charging. However, 251 authorization for the network resource usage must be obtained 252 prior to the actual resource usage to occur. This authorization 253 is granted by the PPS upon request from the PPC. When receiving a 254 resource usage request, the PPS assembles the relevant charging 255 information and generates a charging event in real-time. The PPS 256 then returns an appropriate resource usage authorization. The 257 resource usage authorization may be limited in its scope (e.g., 258 volume of data or duration), therefore the authorization may have 259 to be renewed from time to time as long as the resource usage 260 persists. Note that the charging information utilized in online 261 charging is not necessarily identical to the charging information 262 employed in offline charging. In conclusion, online charging is a 263 mechanism where charging information can affect, in real-time, the 264 service rendered and therefore a direct interaction of the 265 charging mechanism with the control of resource usage is required. 266 [TS32240] 268 1.2. Overview 270 This section provides an overview of the prepaid charging models and 271 architectures, which are supported by the extensions described in 272 this document. 274 A number of models of how to charge customers for services in a 275 prepaid manner are supported: 277 o Volume-based charging (e.g., 2 Cents/KiloByte). 279 o Duration-based charging (e.g., 3 Cents/minute). 281 o Resource-based charging (e.g., 3 videos for 10 Euros) 283 o Event-based charging (e.g., 7 Cents/ring tone) . 285 This draft assumes that the user maintains a prepaid account with his 286 home network. This account may be used to fund multiple services, 287 some of which may use the extensions defined in this document, and 288 some may use other mechanisms. The interworking of these mechanisms 289 is outside the scope of this document. Similarly, the means by which 290 the subscriber obtains funds is also outside the scope of this 291 document. 293 1.2.1. Architectural Model 295 This section describes the architectural model of the protocol 296 extensions described in this document. Figure 1 describes the 297 involved entities. 299 The end user establishes a connection with one of possibly multiple 300 PPCs during service access. The selected PPC communicates with a 301 HAAA server (directly or indirectly via a broker network). 303 The interface between the HAAA and the PPS is implemented using the 304 RADIUS protocol together with the extensions described in this 305 document. However, in cases where the PPS does not implement the 306 RADIUS protocol, the implementation would have to map the 307 requirements defined in this document to a functionally equivalent 308 protocol. 310 The requesting PPC meters the consumption of the service according to 311 the instructions provided by the PPS. After service completion, or 312 on reception of a subsequent request for service, the PPS deducts the 313 corresponding amount of credit from the user account. When a user 314 terminates an on-going service, the PPC informs the PPS with a 315 suitable indication about the unused portion of the allocated quota. 316 The PPS then refunds the user account accordingly. Note that 317 multiple PPSs may be deployed for reasons of redundancy and load 318 sharing. The system may also employ multiple rating servers. 320 Service 321 Access Device Accounting 322 +----------+ +---------+ Protocol +------------+ 323 | End |<---->|+-------+|<------------>| Accounting | 324 | User | +->|| PCC || | Server | 325 | | | || ||<----+ | | 326 +----------+ | |+-------+| | +------------+ 327 | +---------+ | 328 +----------+ | | 329 | End |<--+ | 330 | User | | +----------+ 331 +----------+ +------->| | 332 Prepapid | PPS | 333 Protocol | | 334 +----------+ 336 Figure 1: Basic Prepaid Architecture 338 The PPS and the accounting server in this architecture MAY be 339 combined. The PPC must have the ability to meter the consumption of 340 a prepaid data session. This metering is typically based on time 341 (i.e., seconds) or volume (i.e., octets). 343 The device running the PPC may also have "Dynamic Session 344 Capabilities", such as the ability to terminate a data session or to 345 change the filters associated with a specific data session by 346 processing "Disconnect" messages and "Change of Authorization" 347 messages as per RFC 3576 [RFC3576]. 349 This document assumes that the PPS is used as the AAA server. There 350 are three types of AAA server, as follows. 352 The AAA server in the home network (HAAA) is responsible for 353 authentication of the subscriber. In addition, the HAAA communicates 354 with the PPS using the RADIUS protocol in order to authorize 355 subscribers. 357 This document assumes that the PPS communicates with the HAAA for the 358 purposes of authentication and authorisation. The PPS, in turn, 359 interfaces to entities which 361 o keep the subscriber's account balance (balance manager), 363 o rate access service requests in real-time (rating engine), and 365 o manage quota for a particular prepaid service (quota server). 367 The balance manager, the rating engine and the quota server belong to 368 the service provider's backend infrastructure and are outside the 369 scope of this specification. In particular, as far as this 370 specification is concerned, they are assumed to exist in the PPS. 372 Accounting messages are not needed to deliver a prepaid service. 373 However, accounting messages can be used to keep the PPS up-to-date 374 as to what is happening with the prepaid data session. 376 1.2.2. Motivation 378 Why not use existing RADIUS attributes to construct a protocol for 379 prepaid scenarios? This could lead to a solution where no code has 380 to be modified at existing devices. 382 It is indeed possible to construct a solution for prepaid scenarios 383 using existing RADIUS attributes. The RADIUS server would send an 384 Access-Accept message containing a Session-Timeout(27) and include a 385 Termination-Action(29) in the RADIUS-request. Upon receiving the 386 Access-Accept message, the NAS would meter the duration of the 387 session and upon termination of the session the NAS would generate an 388 Access-Request message again. The RADIUS server would then re- 389 authenticate the session and reply with an Access-Accept message 390 indicating the amount of additional time in a Session-Timeout(27). 391 Alternatively, it could respond with an Access-Reject message if 392 there were no more resources in the user account. 394 Moreover, if the user terminates the session prematurely, the NAS 395 could indicate this in the accounting stream so that unused funds can 396 be returned into the prepaid user account. 398 Unfortunately, the above "solution" has a number of drawbacks, 399 including the following. 401 o It only supports time-based charging. The solution presented in 402 this document supports multiple charging metrics. 404 o Using accounting messages to recoup unused time may be problematic 405 because RADIUS accounting messages are not delivered in real-time. 406 A RADIUS server may store-and-forward accounting messages in 407 batches. Thus, relying on accounting messages for the purposes of 408 prepaid may cause revenue leakage. The solution presented in this 409 document does not rely on Accounting packets at all. It uses 410 Access-Request messages, which are required to flow through any 411 network in real-time. 413 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 414 subscriber is served by a NAS that does not adhere to Session- 415 Timeout then that subscriber may use the service for an 416 undetermined period of time. 418 o Termination-Action(29) presents its own issues. Firstly, the 419 behaviour of Termination-Action(29) is not mandatory. Secondly, 420 according to RFC 2865 [RFC2865], Termination-Action fires when the 421 provision of the service has completed. However, service should 422 not be terminated when negotiating additional quota, because this 423 should happen in a manner transparent to the subscriber. Due to 424 the fact that Termination-Action occurs when the service is 425 completed, it is unclear whether or not user experience would be 426 affected if this attribute would be used in a prepaid scenario. 427 The RADIUS server might even allocate a new IP address to the 428 subscriber device after a Termination-Action. Also, the RADIUS 429 server has no way of telling why a given Access-Request message 430 was generated. The RADIUS server might have to wait for the 431 corresponding accounting packet to determine the reason. Finally, 432 re-authenticating the subscriber may take too long. The solution 433 presented in this document allows quota replenishing to occur 434 without affecting user experience. No re-authentication is 435 required and quotas can be negotiated before the available credit 436 actually runs out. 438 o Due to the fact that the standard RADIUS attributes are not 439 mandatory, the correct prepaid operation is really an act of faith 440 on the part of the RADIUS server. If Session-Timeout(27) and/or 441 Termination-Action(29) are not supported, the prepaid subscriber 442 might be able to obtain the service for free. The solution 443 described in this document requires that a PPC informs the RADIUS 444 server, regardless of whether or not the latter supports the 445 prepaid extensions. The RADIUS server can then determine whether 446 or not service should be granted. For example, if a prepaid 447 subscriber is connected to a NAS that does not support prepaid, 448 the RADIUS server can either instruct the NAS to tunnel the 449 traffic to another entity in the home network (e.g., an Home 450 Agent) that supports prepaid, or cause it to provide only a 451 restricted service. 453 The solution presented in this document requires the support of two 454 mandatory and one optional attribute. Furthermore, it does not 455 require a great amount of additional code at a NAS (or similar 456 device) that already supports time or volume-based metering. The 457 solution requires that RADIUS entities advertise their prepaid 458 capabilities in an Access-Request and that they generate an Access- 459 Request packet with Service-Type="Authorize-Only" in order to obtain 460 more quota when or before the current quota is used up. It also 461 requires the NAS to send an Access-Request with Service- 462 Type="Authorize-Only" when the session terminates in order to refund 463 the subscriber account. 465 1.3. Assumptions 467 This document makes the following assumptions. 469 o The values carried in the Service Identifiers are pre-configured 470 between the PPC and the PPS. 472 o The decision about the service rating happens at the PPS. 474 o The decision whether credit control requests for two services are 475 placed in a resource pool are made by the PPS. 477 o The decision which services belong to the same rating group are 478 pre-configured at the PPC. Once a rating group is authorized it 479 is not necessary to re-authorize an additional service that 480 belongs to the same rating group at the PPS again. 482 o A price enquiry is done purely for the purpose of providing AoC 483 for the end user, not for processing at the PPC nor to trigger any 484 specific actions. 486 1.4. Example Use Case 488 This section describes the sequence of events in an example RADIUS 489 prepaid transaction. 491 1. When an end host attaches to a network (for example, using IEEE 492 802.1X), as usual, the PPC that is servicing the subscriber uses 493 the AAA infrastructure in order to authenticate and authorize the 494 subscriber with respect to the requested service. In order to do 495 this, it sends a RADIUS Access-Request to the AAA server. This 496 Access-Request contains the subscriber's credentials and may 497 contain the prepaid capabilities of the PPC. 499 2. The authentication procedure proceeds. This may involve several 500 message exchanges, as it is the case with the Extensible 501 Authentication Protocol (EAP) [RFC2284]. Once the subscriber has 502 been successfully authenticated, the home AAA server determines 503 that the subscriber is a prepaid subscriber and requests 504 authorisation from the PPS. This request MUST include the 505 prepaid capabilities of the serving PPC. 507 3. The PPS, possibly with the help of the backend infrastructure, 508 validates that the subscriber has a prepaid account and that the 509 account is active. It further validates that the PPC has the 510 appropriate prepaid capabilities. If all is in order, the PPS 511 authorises the subscriber to use the network. Otherwise it 512 rejects the request. The decision is sent to the AAA system in 513 the form of a response message. In the case of success, this 514 message contains attributes that indicate the allocation of a 515 portion of the subscriber credit. This portion is called the 516 "initial quota" and is expressed in units of time or volume. The 517 response may also include a threshold value. Note that only a 518 portion of the user's funds is allocated because the user may be 519 engaged in other services that may draw on the same account. For 520 example, the user may be engaged in a data session and a voice 521 session. Although these two services would draw from the same 522 account, they form separate parts of the overall system. If the 523 entire quota was allocated to the data session then the user 524 would have no more funds for a voice session. 526 4. The AAA system incorporates the attributes received from the PPS 527 into an Access-Accept message that it sends to the PPC. Note 528 that the AAA system is responsible for authorizing the service 529 whereas the prepaid system is responsible for prepaid 530 authorization. 532 5. Upon receiving the Access-Response, the PPC starts the prepaid 533 data session and meters the session based on time or volume, as 534 indicated in the message. 536 6. Once the consumption approaches the allocated limit (as expressed 537 by the threshold), the PPC will request additional quota. Re- 538 authorization for additional quota flows through the AAA system 539 to the PPS. The PPS revalidates the subscriber account and 540 subtracts the previously allocated quota from the current 541 balance. If there is remaining balance, it reauthorizes the 542 request with an additional quota allotment. Otherwise, the PPS 543 rejects the request. Note that the replenishment of the quota is 544 a re-authorization procedure and does not require the subscriber 545 to authenticate himself again. 547 7. Upon receiving a re-allotment of the quota, the PPC continues to 548 provide the requested service until the new threshold is reached. 549 If the request for additional quota cannot be fulfilled then the 550 PPC lets the subscriber use the remaining quota and terminates 551 the session. Alternatively, instead of terminating the session, 552 the PPC may restrict service access in such a way that the 553 subscriber can only reach a particular web server. This web 554 server maybe used to allow the subscriber to replenish his 555 account. This restriction can also be used to allow new 556 subscribers to set up prepaid accounts in the first place. 558 8. Should the subscriber terminate the session before the quota is 559 exhausted, the remaining balance allotted to the session is 560 refunded into his account. 562 Note that the subscriber may have disconnected while the PPC is 563 waiting for the initial quota. The entire allocated quota will have 564 to be credited back to the subscribers account in this case. Also 565 note that the PPS maintains session state for the subscriber. This 566 state includes how much account balance was allocated during the last 567 quota enquiry and how much is left in the account. Therefore, it is 568 required that all messages about the session reach the same (and 569 correct) PPS. 571 For a simple message flow, along the lines of this use case, please 572 see Appendix A. 574 2. Supported Features 576 This section describes the features that are supported by the 577 extensions specified in this document. 579 2.1. Services and Quotas 581 Examples of services that the user may be using are browsing the web, 582 participating in a VoIP conversation, watching streaming video and 583 downloading a ring tone. Some operators may want to distinguish 584 between these services and to charge them at different rates and 585 meters them differently. Therefore, the prepaid solution needs to be 586 able to distinguish services, and allocate quota to the services 587 using different unit types (time, volume) and allow for those quotas 588 to be consumed at different rates. 590 +---------+ +---------+ +-------+ 591 | | 1 N | | 1 1 | | 592 | Session |<---------->| Service |<---------->| Quota | 593 | | | | | | 594 +---------+ +---------+ +-------+ 596 Figure 2: Multiple services within a single session 598 As shown in Figure 2, a session may be associated with multiple 599 services. Each service is identified by a service identifier 600 (Service-ID). The format of the Service-ID is not in the scope of 601 this document. It may, for example, be expressed as a 5-tuple {i.e., 602 source IP address, destination IP address, source port, destination 603 port, and protocol type}. Each service is associated with a quota 604 whereby a quota might be applicable to multiple services. An example 605 message flow that involves multiple services within a single session 606 is given in the Appendix A. 608 2.2. Resource Pools 610 When working with multiple services a new problem arises because one 611 service may consume its quota faster than another service. When the 612 user balance is close to exhaustion, a situation could arise where 613 one service is unable to obtain quota while another service has 614 plenty of quota remaining. Unless the quotas can be rebalanced, the 615 SAD would then have to terminate the former service. Moreover, it is 616 likely that each service generates a certain amount of RADIUS prepaid 617 traffic. In an environment with many users and charged services, 618 this amount of traffic may become a considerable overhead that could 619 lead to inefficiency. 621 One method to circumvent the above situation is to use a so-called 622 "resource pool". Resource pools enable the allocation of resources 623 to multiple services of a session by allocating resources to a pool 624 and have services draw their quota from the pool at a rate 625 appropriate to that service. When the quota that has been allocated 626 to the pool is close to exhaustion, the entire pool (rather than 627 individual services) is replenished. 629 +-----------+ 630 | Service-A |-----+ +--------+ 631 +-----------+ | Ma | | 632 +-------->| | 633 | Pool | 634 +-------->| (1) | 635 +-----------+ | Mb | | 636 | Service-B |-----+ +--------+ 637 +-----------+ 639 Figure 3: Resource pool example 641 As shown in Figure 3, Service-A and Service-B are bound to Pool(1). 642 Ma and Mb are the pool multipliers (that are associated with 643 Service-A and Service-B respectively) that determine the rate at 644 which Service-A and Service-B draw from the pool. 646 The pool is initialized by taking the quota allocated to service n 647 and multiplying it by Mn. Therefore, the amount of resources 648 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 649 Qn denotes the amount of quota that is allocated to service n. 650 Further, the pool is considered to be empty if 652 Poolr <= Ca*Ma + Cb*Mb + . . ., 654 Figure 4 656 where Ca and Cb are resources consumed by Service-A and Service-B 657 respectively. 659 Note that the resources assigned to the pool are not associated with 660 a metric. That is, Service-A can be rated at $1 per MB and Service-B 661 can rated at $0.10 per minute. In this case, if $5 worth of 662 resources are allocated for service-A to the pool and if Ma = 10, 663 then 50 units would be placed into the pool. If a further $5 are 664 allocated for service-B to the pool, then M=1 and 50 units are 665 deposited into the pool. The pool would then have a total sum of 100 666 units to be shared between the two services. The PPC would then 667 mater the services such that each Mbyte used by Service-A will draw 668 10 units from the pool and each minute used by Service-B will draw 1 669 unit from the pool. 671 2.3. Rating Groups 673 A Rating Group gathers a set of services, identified by a service 674 identifier, and subject to the same cost and rating type (e.g., $0.1/ 675 minute). 677 The rating of a service can be quite complex. While some operators 678 follow linear pricing models, others may wish to apply more complex 679 functions. For example, a service provider may wish to rate a 680 service such that the first N MBytes are free, then the next M Mbytes 681 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 682 per MB. Such a function could be implemented by repeated message 683 exchanges in the prepaid system. 685 To avert the need to exchange many messages while still supporting 686 such complex rating functions, the concept of the Rating Group was 687 introduced. 689 As shown in Figure 5, a Rating Group is associated with one or more 690 services and defines the rate that the services associated with the 691 Rating Group consume an allocated amount of quota. 693 +--------------+ +--------------+ 694 +-----------+ N 1 | | M 1 | Resource Pool| 695 | Service-A +---------->| Rating Group |------>| or | 696 +-----------+ | | | Quota | 697 +--------------+ +--------------+ 699 Figure 5: Rating Group 701 During the usage of a service that is associated with a Rating Group, 702 the PPC sends the ID of the Rating Group to the PPS. The PPS 703 authorises the Rating Group by allocating a quota to it and assign it 704 to a Resource Pool. When an additional service that belongs to an 705 already authorised Rating Group is instantiated, the PPC does not 706 need to re-authorize this service. This effectively means that the 707 PPC meters the service such that it draws from the already allocated 708 quota. Therefore, no RADIUS messages need to be exchanged in this 709 case. This limits the amount of traffic between the PPC and the PPS. 710 An example of a flow that uses Rating Groups is given in Appendix A.3 712 2.4. Tariff Switching 714 Tariff is the set of parameters defining the utilization charges for 715 the use of a particular service. 717 This mechanism is useful if, for example, as shown in Figure 6, 718 traffic before 18:00 is rated at rate r1 and traffic after 18:00 is 719 rated at rate r2. The mechanism requires the PPC to report usage 720 before and after the switch occured. 722 18:00 723 ------------------+----------------- 724 r1 | r2 725 ------------------+----------------- 726 ^ ^ 727 |<----TSI---> | 728 | | 729 Access-Accept Access-Request 730 (quota allocated) (quota consumed) 732 Figure 6: Example of Tariff Switching 734 The PPC indicates support for tariff switching by setting the 735 appropriate bit in the PPAC. If the PPS needs to signal a tariff 736 switch time it will send a PTS attribute that indicates the point in 737 time when the switch will occur. This indication represents the 738 number of seconds from current time (TariffSwitchInterval TSI). 740 At some point after the tariff switch the PPC sends another Access- 741 Request, as a result of either the user having logged off or the 742 volume threshold being reached. The PPC reports how much volume was 743 used in total (in a PPAQ attribute) and how much volume was used 744 after the tariff switch (in a PTS VUATS subtype attribute). 746 In situations with multiple tariff switches, the PPS has to specify 747 the length of the tariff switch period using the 748 TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS 749 attribute, as shown in Figure 7. 751 18:00 23:30 752 ------------------+---------------------+-------------- 753 r1 | r2 | r3 754 ------------------+---------------------+-------------- 755 ^ ^ ^ 756 |<----TSI---><-----------|-------->|TITSU 757 | | 758 Access-Accept Access-Request 760 Figure 7: Multiple Tariff Switches 762 When a TITSU is specified in the PTS, the PPC MUST generate an 763 Access-Request within the time after TSI and before TITSU expires. 764 Note that, typically, the PPC will be triggered by the Volume 765 Threshold. However, it is possible that, during period r2, resources 766 are not entirely consumed and, thus, the threshold is not reached. 767 The TITSU attribute ensures that, even in this case, the PPC will 768 generate the new Access-Request in good time. 770 For time based services, the quota is continuously consumed at the 771 regular rate of 60 seconds per minute. At the time when credit 772 resources are allocated, the server already knows how many units will 773 be consumed before the tariff time change and how many units will be 774 consumed afterward. Similarly, the server can determine the units 775 consumed at the before rate and the units consumed at the rate 776 afterward in the event that the end user closes the session before 777 the consumption of the allotted quota. There is no need for 778 additional traffic between the PPC and the PPS in the case of tariff 779 time changes for continuous time based service. Therefore, the 780 tariff change mechanism is not used for such services. For time- 781 based services in which the quota is not continuously consumed at a 782 regular rate, the tariff change mechanism described for volume and 783 event units may be used. 785 2.5. Support for Roaming 787 In certain networks it is essential for prepaid data services to be 788 available to roaming subscribers. Support for both static and 789 dynamic roaming models is needed. In a static roaming scenario the 790 subscriber connects to a foreign network which has a roaming 791 agreement either directly with the home network, or through a broker 792 network. When the subscriber logs into another foreign network, a 793 new login procedure has to be executed. 795 In a dynamic roaming scenario the subscriber may move between 796 networks while maintaining his connection. In such a scenario the 797 data session is seamlessly handed off between the networks. 799 In both roaming scenarios, the subscriber always authenticates 800 himself to the home network. Authorization for the prepaid session 801 and quota replenishing occurs at the home network and more 802 specifically at the PPS where state is being maintained. 804 Roaming is challenging because a subscriber who established a prepaid 805 data session may move to another PPC that does not support the 806 prepaid extensions. 808 2.6. Dynamic Termination 810 When fraud or an error is detected, either only the affected session, 811 or all sessions of the affected subscriber should be immediately 812 terminated. Under certain conditions, the system may wish to 813 terminate the session in order to make sure that the user is not 814 charged for services it does not use. 816 Certain handoff procedures used in dynamic roaming scenarios require 817 that the system terminates the subscribers prepaid data session at a 818 PPC. This is the case, for example, when time-based prepaid is used 819 and the mobile subscriber performs a dormant handoff. 821 2.7. One Time Event 823 2.7.1. One-Time Charging 825 One-time charging is a mode of operation where the RADIUS prepaid 826 extensions are used for charging of a service that is provided 827 instansteneously. An example of such an event is the purchase of a 828 ring tone. Subscription based services can also be modeled as a one- 829 time event. In this case the one-time service event is the purchase 830 of a subscription. 832 For a given user, one-time charging may occur in parallel with other 833 charging models. For example, the subscriber may be connected to the 834 Internet, which is metered (based on time or volume), while he also 835 purchases a ring tone (a one-time-based event). 837 Note that it is up to the service providers to decide whether or not 838 the user will be charged for the download of, for example, the video 839 and also be charged for the data volume required to download the 840 video. The facilities provided by this document gives the service 841 provider the capability to achieve their service charging business 842 goals. 844 The PPC signals one-time charging to the PPS with an indication that 845 identifies the service and the units that should be debited from the 846 user account. 848 A PPC may decide to perform one-time charging and the PPC may need to 849 authenticate the user before sending the relevant message to the 850 user's home AAA server (and to the PPS). 852 Note that one-time charging can also be used to credit the prepaid 853 account. For example, the PPC can return resources to the subscriber 854 by issuing a one-time charging request that includes the amount of 855 resources to be credited into the account. 857 2.7.2. Resource Consumption Query 859 It should be possible for the PPS to query the PPC for the current 860 resource consumption and to adjust the users account balance. For 861 example, a request to the PPS is made (e.g., a one-time charging 862 event), the account is depleted and resources have been allocated to 863 the PPC. The PPS should have the ability to query the PPC and, if it 864 has the spare resources, to reassign the quotas to the PPC and to the 865 pending request. Note that the PPS does not know resource usage 866 until the PPC request for more resources. This can be a long time. 868 In the absence of this capability the PPS can minimize the effect of 869 this phenomenon by allocating small quotas, a practice that results 870 in more message exchanges. 872 2.7.3. Service Price Enquiry 874 The PPC may need to know the price of the service event. Services 875 offered by application service providers whose prices are not known 876 in the PPC might exist. The end user might also want to get an 877 estimation of the price of a service event before requesting it. 879 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 880 with the value set to "Price Enquiry" (2). The request includes 881 enough information to identify the service, namely a Service- 882 Identifier or a Rating-Group-Identifer. 884 The PPS calculates the cost of the requested service event, but it 885 does not perform any account balance check or credit reservation from 886 the account. 888 The estimated cost of the requested service event is returned to the 889 PPS with a PPAQ in the Cost-Information SubType. The PPC may 890 transfer the information to the end user as an advice of charge. 892 More information regarding the price enquiry functionality is 893 provided in Section 4.3.15 and in Section 4.3.17. 895 2.7.4. Balance Check 897 The PPC may only have to verify that the end user's account balance 898 covers the cost of a certain service without reserving any units from 899 the account at the time of the inquiry. This method does not 900 guarantee that credit would be left when the PPC requests the 901 debiting of the account with a separate request. 903 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 904 with the value set to "Balance Check" (1). The request includes 905 enough information to identify the service, namely a Service- 906 Identifier or a Rating-Group-Identifer. 908 The PPS makes the balance check, but it does not make any credit- 909 reservation from the account. 911 The result of balance check, namely "Success" (1) or "Failure" (2), 912 is returned to the PPC in the Check-Balance-Result SubType conveyed 913 in the PPAQ attribute from the PPS to the PPC. 915 More information regarding the balance check functionality is 916 provided in Section 4.3.15 and in Section 4.3.16. 918 2.7.5. Refund 920 Some services may refund service units to the end user's account; for 921 example, gaming services. 923 To initiate refunding the PPC includes the PPAQ attribute in an 924 Access-Request packet and the amount (as a negative value) to be 925 refunded is specified using the Resource Quota and Resource Quota 926 overflow subtypes. This functionality is similar to one-time 927 charging with the difference that refunding uses negative values 929 Information about the service need to be provided by the PPC to allow 930 service identification, namely the Service-ID field of the PPAQ 931 identifies the prepaid service. 933 Note that a monetary amount itself to be refunded is not provided but 934 rather abstract units. Based on prior out-of-band agreements between 935 the PPC and the PPS these abstract units are translated into a 936 monetary amount. 938 More information regarding the refund functionality is provided in 939 Section 3.8.6. 941 3. Operations 943 This section contains the normative text for the prepaid extension. 945 3.1. Capability Discovery 947 The PPC initiates the authentication and authorization procedure by 948 sending a RADIUS Access-Request to the HAAA. Since the PPC MUST 949 include a PPAC attribute in the RADIUS Access-Request. The PPAC 950 attribute indicates to the PPS which prepaid capabilities are 951 possessed by the PPC. These are required in order to complete the 952 prepaid authorization procedure.Moreover, if the PPC supports the 953 Disconnect-Message or the Change-of-Authorization capabilities, then 954 it SHOULD include the Session Termination attribute. 956 In certain deployments, there may be other ways to terminate a data 957 session, or change authorization of an active session. For example, 958 some PPCs provide a session termination service via Telnet or SNMP. 959 In these cases, the AAA server MAY add the Dynamic-Capabilities 960 message to the Access-Request. Upon receiving the Change-of- 961 Authorization message, the AAA server would then be responsible for 962 terminating the session using the means that are supported by the 963 device. 965 If the authentication procedure involves multiple message exchanges 966 (as it is the case with EAP), the PPC MUST include the PPAC attribute 967 in at least the last Access-Request of the authentication procedure. 969 3.2. Authentication and Authorization Operation 971 Once the Access-Request arrives at the HAAA, the HAAA authenticates 972 the subscriber. If this fails, the HAAA sends an Access-Reject 973 message to the client. If authentication succeeds, the HAAA 974 determines whether or not the subscriber is a prepaid subscriber. If 975 the subscriber is not a prepaid subscriber, then the HAAA responds as 976 usual with an Access-Accept or an Access-Reject message. If the 977 subscriber is a prepaid subscriber then the HAAA MAY forward the 978 Access-Request to the PPS for further authorization. 980 The Access-Request contains the PPAC attribute and the Dynamic- 981 Capabilities attribute if one was included. The User-Name(1) 982 attribute MAY be set to a value that identifies the subscriber. This 983 attribute is used by the PPS to locate his account. For added 984 security, the HAAA MAY also set the User-Password(2) attribute to the 985 password used between the HAAA and the PPS. 987 The PPS locates the subscriber account and authorizes him. During 988 this procedure, the PPS takes into consideration the PPCs 989 capabilities. Upon successful authorization, the PPS generates an 990 Access-Accept containing an PPAC attribute and an PPAQ attribute. 991 The PPAC attribute returned to the client indicates the type of 992 prepaid service to be provided for the session. The PPAQ attribute 993 includes the following information. 995 o The QID, which is set by the PPS to a unique value, is used to 996 correlate quota requests. 998 o Volume and/or Time quota, which is set to a value representing a 999 portion of the subscriber's credit. 1001 o Time or Volume Threshold that indicates when the PPC should 1002 request additional quota. This information is optional. 1004 o The IP address of the serving PPS and one or more alternative 1005 PPSs. This is used by the HAAA to route subsequent quota 1006 replenishing messages to the appropriate PPS(s). 1008 o A State attribute, as defined in RFC 2865 [RFC2865]. This is 1009 necessary in order to satisfy the requirements of Section 5.44 of 1010 RFC 2865 [RFC2865], which mandates that an Access-Request with 1011 Service-Type="Authorize-Only" must contain a State attribute. 1012 Since the PPC sends subsequent quota replenishment requests in the 1013 form of such "Authorize-Only" requests, a State attribute MUST be 1014 present in all Access-Accept messages that also carry a PPAQ 1015 attribute. 1017 Note: The Idle-Timeout(28) attribute can be used to trigger the 1018 premature termination of a prepaid service, for example as a result 1019 of inactivity. 1021 Depending on site policies, after failed authorization, the PPS may 1022 generate an Access-Reject in order to terminate the session 1023 immediately. Alternatively, the PPS may generate an Access-Accept 1024 blocking some or all of the traffic and/or redirect some or all of 1025 the traffic to a location to a fixed server. (This feature could be 1026 used, for example, to prompt the user to replenish their account.) 1027 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 1028 Filter-Rule (see [RFC4849]). A description of the redirect 1029 functionality is outside the scope of this document. The time period 1030 before the session is blocked/redirected is specified by the Session- 1031 Timeout(27) attribute. 1033 Upon receiving an Access-Accept from the PPS, the HAAA appends the 1034 usual service attributes and forward the packet to the PPC. The HAAA 1035 SHOULD NOT overwrite any attributes already set by the PPS. If the 1036 HAAA receives an Access-Reject message, it will simply forward the 1037 packet to its client. Depending on site policies, if the HAAA does 1038 not receive an Access-Accept or an Access-Reject message from the PPS 1039 it MAY do nothing or send an Access-Reject or an Access- Accept 1040 message back to the PPC. 1042 3.3. Session Start Operation 1044 The start of the session is indicated by the arrival of an 1045 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 1046 be routed to the PPS such that it can confirm the initial quota 1047 allocation. 1049 Note that the role of the PPS is not to record accounting messages 1050 and therefore it SHOULD NOT respond with an Accounting Response 1051 packet. If the PPS does not receive the Accounting-Request(start) 1052 message it will only know that the session has started upon the first 1053 reception of a quota replenishment operation. 1055 If the PPS does not receive indication directly (via Accounting- 1056 Request(start)) or indirectly, it SHOULD, after some configurable 1057 time, deduce that the session has not started. If the PPC supports 1058 termination capabilities, the PPS SHOULD send a Disconnect Message to 1059 the PPC as a measure to ensure that the session is indeed dead. 1061 3.4. Mid-Session Operation 1063 During the lifetime of a prepaid data session the PPC may request the 1064 replenishment of the quotas using an Authorize-Only Access-Request 1065 message. Once either the allocated quota has been exhausted or the 1066 threshold has been reached, the PPC MUST send an Access-Request with 1067 Service-Type(6) set to a value of "Authorize-Only" and the PPAQ 1068 attribute. 1070 The PPC MUST also include NAS identifiers, and Session Identifier 1071 attributes in the Authorize-Only Access-Request. The Session 1072 Identifier should be the same as the one used during the initial 1073 Access-Request. For example, if the User-Name(1) attribute was used 1074 in the Access-Request it has to be included in the Authorize-Only 1075 Access-Request as well, especially if the User-Name(1) attribute is 1076 used to route the Access-Request to the Home AAA server. 1078 The Authorize-Only Access-Request MUST NOT include a User Password 1079 and MUST NOT include a CHAP Password. In order to enable the 1080 receiver to authenticate the message, the PPC MUST include a Message- 1081 Authenticator(80). In order to satisfy the requirements of Section 1082 5.44 of RFC 2865 [RFC2865], the PPC MUST also include the State 1083 attribute. It is anticipated that the inclusion of the State 1084 attribute will enable the PPS to map the Authorize-Only Access 1085 Request to the authentication context that was established when the 1086 PPC authenticated itself at the beginning of the session. The PPC 1087 computes the value for the Message-Authenticator and the State 1088 attributes according to RFC 2869 [RFC2869] and RFC 2865 [RFC2865] 1089 respectively. 1091 When the HAAA receives an Authorize-Only Access-Request that contains 1092 a PPAQ, it validates the message using the Message-Authenticator(80), 1093 according to RFC 2869. If the HAAA receives an Authorize-Only 1094 Access-Request that contains a PPAQ and either no or an invalid 1095 Message-Authenticator(80) it SHALL silently discard the message. An 1096 Authorize Only Access-Request message that does not contain a PPAQ is 1097 either erroneous or belongs to another application (for example, a 1098 Change of Authorization message [RFC3576]). In this case the 1099 Authorize-Only Access-Request is either silently discarded or handled 1100 by another application. 1102 Once the Authorize-Only Access-Request message is validated, the HAAA 1103 SHALL forward the Authorize-Only Access-Request to the appropriate 1104 PPS. The HAAA MUST forward the Authorize-Only Access-Request to the 1105 PPS specified in the PPAQ. The HAAA MUST add a Message- 1106 Authenticator(80) to the message, according to RFC 2869. As with the 1107 Access-Request message, the HAAA MAY modify the User-Name(1) 1108 attribute such that it identifies the user to the PPS. 1110 When the PPS receives the Authorize-Only Access-Request containing a 1111 PPAQ attribute, it MUST validate the Message-Authenticator(80) as 1112 described in RFC 2869. If validation fails, the PPS MUST silently 1113 discard the message. If it receives an Authorize-Only Access-Request 1114 message that does not contain a PPAQ, it MUST silently discard the 1115 message. 1117 The PPS locates the prepaid session state and uses the QID contained 1118 within the PPAQ to detect replays. The PPS takes the most recently 1119 allocated quota and subtracts it from the user balance. If 1120 sufficient balance remains, the PPS authorizes the PPS and allocates 1121 additional quota. The PPS may also calculate a new threshold value. 1122 Upon successful re-authorization, the PPS generates an Access-Accept 1123 containing the PPAQ attribute. 1125 Depending on site policies, upon unsuccessful authorization, the PPS 1126 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1127 Ascend-Data-Filter attribute (if supported) and the Session- 1128 Timeout(27) attribute such that the subscriber can get access to a 1129 restricted set of locations for a short period of time. This feature 1130 could be used to enable users to replenish their accounts, create new 1131 accounts, or to access free content. 1133 Upon receiving an Access-Accept from the PPS, the HAAA forwards the 1134 message to its client. If the HAAA receives an Access-Reject 1135 message, it forwards the message. Depending on site policies, if the 1136 HAAA does not receive an Access-Accept or an Access-Reject message 1137 from the PPS it MAY do nothing or it MAY send an Access-Reject 1138 message back to its client. 1140 Upon receiving an Access-Accept, the PPC updates its quotas and 1141 threshold parameters with the values contained in the PPAQ attribute. 1142 Note that the PPS MAY update the PrePaidServer attribute(s) and these 1143 may have to be saved as well. If the Access-Accept message contains 1144 a Filter-Id(11), an Ascend-Data-Filter attribute, or Session 1145 Timeout(27), the PPC SHALL restrict the subscriber session 1146 accordingly. 1148 3.5. Dynamic Operations 1150 The PPS may take advantage of the dynamic capabilities that are 1151 supported by the PPC as advertised in the Session Termination and the 1152 PPAC attribute during the initial Access-Request. There are two 1153 types of actions that the PPS may perform. Firstly, it may request 1154 the session to be terminated. Secondly, it may request the 1155 attributes associated with the session to be modified. More 1156 specifically, it may modify a previously sent PPAQ. 1158 Both of these actions require that the session be uniquely identified 1159 at the PPC as described in [RFC3576]. 1161 3.5.1. Unsolicited Session Termination Operation 1163 At anytime during a session the PPS may send a Disconnect Message in 1164 order to terminate a session, see in [RFC3576]. Upon successful 1165 termination of a session the PPC MUST return any unused quota to the 1166 PPS by issuing an Authorize-Only Access-Request containing the PPAQ 1167 which contains any unused quota and the Update-Reason set to "Remote 1168 Forced Disconnection". 1170 3.5.2. Unsolicited Change of Authorization Operation 1172 At any time during the session the PPC may receive a Change of 1173 Authorization (CoA) message. A PPS may send a new quota to either 1174 add or to remove quota that is allocated to the service. If the 1175 Change of Authorization contains a PPAQ then that PPAQ overrides a 1176 previously received PPAQ. The PPS MUST NOT change the units used in 1177 the PPAQ. 1179 If the newly received PPAQ reduces the amount of allocated quota 1180 beyond what is already used then the PPC accepts the new PPAQ and act 1181 as it normally would when the quota is used up. For example, if the 1182 threshold is reached then is request a quota update. 1184 3.6. Termination Operation 1186 The termination phase is initiated when (i) the subscriber logs off, 1187 (ii) the subscriber balance is exhausted, or (iii) when the PPC 1188 receives a Disconnect Message. 1190 In case the user logged off, or the PPC receives a Disconnect 1191 Message, the PPC sends an Authorize-Only Access-Request message with 1192 a PPAQ and Update-Reason attribute set to either "Client Service 1193 Termination" or "Remote Forced Disconnect". This message indicates 1194 the amount of consumed quota. 1196 In case the currently allocated quota is exhausted, if the PPAQ 1197 contained the Termination-Action subytype, the PPC follows the 1198 specified action. 1200 3.7. Mobile IP Operations 1202 In roaming scenarios with Mobile-IP, the prepaid data session should 1203 be maintained transparently if the HA is acting as the access device 1204 hosting the PPC. As the subscriber device associates with a new 1205 access service device (AP or PDSN that supports PPC capability), this 1206 service access device sends a RADIUS Access-Request and the 1207 subscriber is re-authenticated and reauthorized. The service access 1208 device SHALL include the PPAC attribute in the RADIUS Access-Request. 1209 In this manner, the procedure follows the Authentication and 1210 Authorization procedure described earlier. 1212 If the HA was acting as the service access device before handoff, 1213 then the prepaid session does not undergo any change after the 1214 handoff because the Mobile IP session is anchored at the HA and the 1215 user's Home IP address does not change. 1217 In the case of a wireless access point or PDSN acting as the service 1218 access device, it is likely that the user's (care-of) IP address will 1219 change. The prepaid session will be affected by this. In this 1220 scenario the service access device shall send an Access-Request 1221 message which is routed to the home network and SHALL reach the PPS 1222 that is serving this session. The PPS correlates the new 1223 authorization request with the existing active session and assigns a 1224 quota to the new request. Any outstanding quota at the old service 1225 access device SHALL be returned to the PPS if the Mobile-IP nodes (HA 1226 and FA) support registration revocation (Mobile IPv4 only). 1227 Specifically, the quota SHOULD be returned when the service access 1228 device sends the Authorize-Only Access-Request with PPAQ Update- 1229 Reason set to either "Remote Forced Disconnect" or "Client Service 1230 Termination". In order to trigger the sending of this last 1231 Authorize-Only Access- Request, the PPS may issue a Disconnect 1232 Message [3576] to the service access device. 1234 Even if the subscriber moves to a service access device that does not 1235 have prepaid capabilities can the prepaid data service continue. 1236 This can be done by requesting the Home Agent (assuming it has such 1237 capabilities) to take over the responsibilities of the service access 1238 device (i.e. metering). This scenario will be discussed in detail in 1239 a later version of this document. 1241 3.8. Operation Considerations for Multiple Services 1243 This section describes the support for multiple prepaid services on a 1244 single PPC. Message flows illustrating the various interactions are 1245 presented in Appendix A. 1247 A PPC that supports prepaid operations for multi-services SHOULD set 1248 the "Multi-Services Supported" bit in the PPAC. When working with 1249 multi-services, we need to differentiate between the services. A 1250 Service-Id attribute is used in the PPAQ in order to uniquely 1251 differentiate between the services. The exact definition of the 1252 Service-Id attribute is outside the scope of this document. 1254 A PPAQ that contains a Service-Id is associated with that service. A 1255 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1256 Group. A PPAQ MUST NOT contain both a Rating-Group-Id and a 1257 Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a 1258 Service-Id then the default service is used, i.e., the "Access 1259 Service". 1261 3.8.1. Initial Quota Request 1263 When operations with multiple services is desired then the PPC 1264 requests the initial quota by sending a PPAQ containing the 1265 Service-Id in an Authorize-Only Access-Request packet for that 1266 service. Similarly, if the PPC supports rating groups then it may 1267 request a quota for the rating group by sending a PPAQ containing the 1268 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1269 Request". The Authorize-Only Access-Request message MAY contain more 1270 than one PPAQ. 1272 Upon receiving an Authorize-Only Access-Accept message containing one 1273 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1274 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1275 for that service or rating group. Additionally, the PPAQ MUST 1276 contain the Service-ID or Rating-Group-Id, unless the PPAQ is the 1277 generic "Access Service". 1279 3.8.2. Quota Update 1281 Once the services start to utilize their allotted quota they will 1282 eventually need to replenish their quotas (either the threshold is 1283 reached or no more quota remains). In order to replenish the quota, 1284 the PPC sends an Authorize-Only Access-Request message containing one 1285 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1286 Service-ID or Rating-Group-Id (or neither the Service-ID or Rating- 1287 Group-Id if the quota replenishment is for the "Access Service"). 1288 The Update-Reason filed indicates either "Threshold reached"(3), or 1289 "Quota reached"(4). 1291 Upon receiving an Authorize-Only Access-Request packet with one or 1292 more PPAQs the PPS responds with a new PPAQ for that service. The 1293 PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a 1294 new QID. If the PPS does not grant additional quota for the service 1295 it MUST include the Termination-Action subfield in the PPAQ that will 1296 instruct the PPC to take appropriate actions. 1298 3.8.3. Termination 1300 When the allotted quota for a service is exhausted, the PPC shall act 1301 in accordance with the flags set in the Termination-Action subtype. 1302 If the Termination-Action subtype is absent then the service MUST be 1303 terminated. If the service is to be terminated, then the PPC shall 1304 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1305 and the Update-Reason set to "Client Service Termination". 1307 If the "Access Service" has terminated, then all other services must 1308 be terminated as well. In this case the PPC MUST report on all 1309 issued quotas for the various services. The Update-Reason field 1310 should be set to "Access Service Terminated". 1312 3.8.4. Dynamic Operations 1314 Dynamic operations for multi-services are similar to dynamic 1315 operations described for single service operations. The PPS MAY send 1316 a COA message containing a PPAQ for an existing service instance. 1317 The PPC matches the PPAQ with the service using the Service-ID or the 1318 Rating-Group-Id attribute. The new quota could differ from the 1319 previously allocated value. 1321 A disconnect message terminates the "Access Service". As such the 1322 PPC MUST report all unused quotas by sending an Authorize-Only Access 1323 Request message containing a PPAQ for each active service. The 1324 Update-Reason MAY indicate that the reason for the update. 1326 3.8.5. Support for Resource Pools 1328 If the PPC supports pools as indicated by setting the "Pools 1329 supported" bit in the PPAC then the PPS may associate a quota with a 1330 Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ. 1331 When Resource Pools are used, the PPAQ MUST NOT use the threshold 1332 field. 1334 3.8.6. One-time Charging 1336 To initiate one-time charging the PPC includes the PPAQ attribute in 1337 an Access-Request packet. The Service-ID field of the PPAQ 1338 identifies the prepaid service. The amount to be charged is 1339 specified using the Resource Quota and Resource Quota overflow 1340 subtypes. If the value specified is negative then the resources are 1341 credited to the user account. This functionality corresponds to 1342 refunding. 1344 The QID subtype MUST be set to a unique value and is used by the PPS 1345 to detect duplicates. The Update Reason field MUST be set to One- 1346 Time Charging. Upon receiving a One-Time charge PPAQ, the RADIUS 1347 server authenticates the user and, if successful, passes the PPAQ to 1348 the PPS. The PPS locates the account and debits or credits it 1349 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1350 message if successful, or an Access-Reject message otherwise. 1352 In case of a successful operation the HAAA forwards the message to 1353 the PPC with an Access Accept message. Since this is a one-time 1354 charge the PPC MUST NOT allow the session to continue. Therefore, 1355 the RADIUS server SHOULD include in the Access-Accept a Session- 1356 Timeout set to 0. Upon receiving an Access-Accept response the PPC 1357 SHOULD generate an Accounting Stop message. 1359 A PPAQ used for One-Time charging MAY appear in an Authorize-Only 1360 Access Request. This is the case when the session already exists. 1361 The PPS responds with an Access-Accept to indicate that the user 1362 account has been debited or an Access-Reject otherwise. 1364 3.8.7. Error Handling 1366 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1367 PPAQ. 1369 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1370 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1372 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1373 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1375 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1376 Multiplier or a Pool-Multiplier without a Pool-Id it MUST ignore that 1377 PPAQ. 1379 3.8.8. Accounting Considerations 1381 Although typically generated, accounting messages are not required to 1382 deliver a prepaid data service. When generated, accounting messages 1383 are used for auditing purposes and for billing. Accounting messages 1384 associated with prepaid data sessions should include the PPAQ 1385 attribute. 1387 4. Attributes 1389 This section specifies the attributes that implement the RADIUS 1390 extensions for prepaid. 1392 4.1. PrePaid Accounting Capability (PPAC) Attribute 1394 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1395 Access-Request message by a PPC to describe its prepaid capabilities. 1397 0 1 2 3 1398 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 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Type | Length | Vendor-Id 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 Vendor-Id (cont) | Vendor type | Vendor length | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Continuation | VALUE ... 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1407 The fields have the following meaning and encoding: 1409 Type: 1411 26 for Vendor-Specific 1413 Length: 1415 6 + 3 + length of SubTypes 1417 Vendor-Id: 1419 The Vendor-Id value for WiMAX is 24757. 1421 Vendor type: 1423 35 for PPAC 1425 Vendor length: 1427 3 + length of VALUE 1429 Continuation: 1431 The Continuation Field is defined as follows: 1433 0 1434 0 1 2 3 4 5 6 7 1435 +-+-+-+-+-+-+-+-+ 1436 |C|r|r|r|r|r|r|r| 1437 +-+-+-+-+-+-+-+-+ 1439 The C-bit of the continuation field indicates 1440 if a attribute is being fragmented. When the 1441 C-bit is set to one '1' this indicates that 1442 the attribute is being fragmented that is 1443 the next VSA of the same type is to be appended 1444 to this attribute. When the C-bit is set to zero 1445 '0' this indicates that the next attribute is 1446 not a fragment of this attribute. 1447 An attribute that is not being fragmented will 1448 have the C-bit set to '0'. An attribute that is 1449 being fragmented will have its C-bit set to '1' 1450 for all fragments until the last fragment, which 1451 will have its C-bit set to '0' indicating it's 1452 the last fragment of the attribute. The r-bits 1453 are reserved for future use. They SHALL be set 1454 to zero by the sender and SHALL be ignored by 1455 the receiver. 1457 The value of the C-bit MUST be 0. 1459 VALUE : 1461 The content of the AvailableInClient (AiC) SubType fields 1462 are encoded using the data type String. 1464 Figure 8: PPAC Attribute 1466 The AvailableInClient (AiC) SubType is encoding as follows: 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | SubType | LENGTH | AvailableInClient (AiC) ... 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | AvailableInClient (AiC) | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 The fields have the following meaning and encoding: 1478 SubType : Value (1) 1480 LENGTH : 2 + 4 1482 AvailableInClient (AiC): The bitmap is encoded as: 1484 Value | Description 1485 ------------ -+------------------------------------- 1486 0x00000001 | Volume metering supported 1487 0x00000010 | Duration metering supported 1488 0x00000100 | Resource metering supported 1489 0x00001000 | Pools supported 1490 0x00010000 | Rating groups supported 1491 0x00100000 | Multi-Services supported 1492 0x01000000 | Tariff Switch supported 1493 0x10000000 | Reserved 1495 Figure 9: AvailableInClient (AiC) SubType 1497 4.2. Session Termination Capability Attribute 1499 The Session Termination Capability attribute is included in the 1500 RADIUS Access-Request message towards the RADIUS server to indicate 1501 whether or not the NAS supports Dynamic Authorization. 1503 0 1 2 3 1504 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 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Type | Length | Vendor-Id 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Vendor-Id (cont) | Vendor type | Vendor length | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | Continuation | String ... 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1513 The fields have the following meaning and encoding: 1515 Type: 1517 26 for Vendor-Specific 1519 Length: 1521 6 + 3 + 4 1523 Vendor-Id: 1525 The Vendor-Id value for WiMAX is 24757. 1527 Vendor type: 1529 36 for Session Termination Capability 1531 Vendor length: 1533 3 + 4 1535 Continuation: 1537 The Continuation Field is defined as follows: 1539 0 1540 0 1 2 3 4 5 6 7 1541 +-+-+-+-+-+-+-+-+ 1542 |C|r|r|r|r|r|r|r| 1543 +-+-+-+-+-+-+-+-+ 1545 The C-bit of the continuation field indicates 1546 if a attribute is being fragmented. When the 1547 C-bit is set to one '1' this indicates that 1548 the attribute is being fragmented that is 1549 the next VSA of the same type is to be appended 1550 to this attribute. When the C-bit is set to zero 1551 '0' this indicates that the next attribute is 1552 not a fragment of this attribute. 1553 An attribute that is not being fragmented will 1554 have the C-bit set to '0'. An attribute that is 1555 being fragmented will have its C-bit set to '1' 1556 for all fragments until the last fragment, which 1557 will have its C-bit set to '0' indicating it's 1558 the last fragment of the attribute. The r-bits 1559 are reserved for future use. They SHALL be set 1560 to zero by the sender and SHALL be ignored by 1561 the receiver. 1563 The value of the C-bit MUST be 0. 1565 String: 1567 This field is encoded as a bitmap. 1569 Value | Description 1570 ---------------+------------------------------------- 1571 0x00000000 | Reserved 1572 0x00000001 | Dynamic Authorization Extensions 1573 | (RFC 3576) is supported. 1574 ... | All further values are reserved. 1576 Figure 10: Session Termination Capability Attribute 1578 4.3. Prepaid Accounting Operation (PPAQ) Attribute 1580 One or more PPAQ attributes are sent in an Access Request, Authorize- 1581 Only Access-Request and Access-Accept message. In an Access Request 1582 message, the PPAQ attribute is used to facilitate one-time charging 1583 transactions. In Authorize-Only Access-Request messages it is used 1584 for one-time charging, report usage and to request further quota. It 1585 is also used in order to request prepaid quota for a new service 1586 instance. In an Access-Accept message it is used in order to 1587 allocate the (initial and subsequent) quotas. 1589 When multiple services are supported, a PPAQ is associated with a 1590 specific service as indicated by the presence of a Service-Id, a 1591 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1592 of both, the Service-Id and the Rating-Group-Id). 1594 Note: Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes 1595 MUST appear in the PPAQ attribute, except for the price enquiry 1596 message exchange where these subtypes MUST be absent. A single PPAQ 1597 attribute MUST NOT contain more than one Service-Id, MUST NOT contain 1598 more than one Rating-Group-Id, and MUST NOT contain both a Service-Id 1599 and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or 1600 a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT 1601 contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST 1602 also contain a Pool-Multiplier SubType. 1604 The PPAQ attribute, as shown in Figure 11, has a variable length 1605 (greater than 8, encoded into one octet), and consists of a variable 1606 number of subtypes. Unused subtypes are omitted from the message. 1608 The following table summarizes the presence of various SubTypes in 1609 the PPAQ attribute carried in the Access-Request and Access-Accept 1610 messages. 1612 Request Accept # SubType Name 1614 0-1(g) 0-1(m,n) 1 Quota Identifier 1615 0-1(a,g) 0-1(a,k,n) 2 VolumeQuota 1616 0 0-1(a,m,n) 3 VolumeThreshold 1617 0-1(b,g) 0-1(b,k,n) 4 DurationQuota 1618 0 0-1(b,m,n) 5 DurationThreshold 1619 0-1(c,g) 0-1(c,k,n) 6 ResourceQuota 1620 0 0-1(c,m,n) 7 ResourceThreshold 1621 0-1(d,g) 0 8 Update-Reason 1622 0-n(e,g) 0-n(e,m,n) 9 PrepaidServer 1623 0-1(g,h,j) 0-1(m,n) 10 Service-ID 1624 0-1(g,h,j) 0-1(m,n) 11 Rating-Group-ID 1625 0 0-1(m,n) 12 Termination-Action 1626 0 0-1(m,n) 13 Pool-ID 1627 0 0-1(f,m,n) 14 Pool-Multiplier 1628 0-1(g) 0 15 Requested-Action 1629 0 0-1(k,m,n) 16 Check-Balance-Result 1630 0 0-1(n) 17 Cost-Information 1632 None of the above-listed SubTypes appears in the Access-Reject nor in 1633 the Access-Challenge. 1635 Notes: 1637 (a) SHALL be present if volume based charging is used. SHALL NOT 1638 be present otherwise. Volume- Threshold is optional. 1640 (b) SHALL be present if duration-based charging is used. SHALL 1641 NOT be present otherwise. Duration- Threshold is optional. 1643 (c) SHALL be present if resource-based charging is used. SHALL 1644 NOT be present otherwise. Resource- Threshold is optional. 1646 (d) SHALL be present in an Authorize-Only Access-Request. 1648 (e) MAY be present in an Access-Accept. If present in Access 1649 Accept it SHALL be present in Access- Request (except for the 1650 first Access-Request). 1652 (f) Pool-Multiplier SHALL be present when Pool-ID is present 1653 otherwise Pool-Multiplier SHALL NOT be present in the PPAQ. 1655 (g) If Requested-Action is present then Service-ID SHALL also be 1656 present and all other attributes SHALL NOT be present. 1658 (h) PPAQ SHALL NOT contain both a Service-ID and a 1659 Rating-Group-ID. 1661 (j) A PPAQ that does not contain a Service-ID or a Rating-Group-Id 1662 refers to the "Access Service"(ISF). 1664 (k) If Balance-Check-Result is present and set to 0 then either 1665 Volume-Quota, Duration-Quota or Resource- Quota SHALL be present. 1667 (m) If Balance-Check-Result is present then Service-ID SHALL also 1668 be present and other attributes (tagged with m) SHALL NOT be 1669 present. 1671 (n) The PPAQ in which a Cost-Information occurs SHALL NOT include 1672 a Quota-Identifier, because no quota is actually reserved by the 1673 PPS. The Service-ID SHALL be present with the Cost-Information 1674 for that Service-ID may not be present if the Cost-Information 1675 cannot be provided. All other attribute SHALL not appear. 1677 In the following subsections the various subtypes of the PPAQ 1678 attribute are specified. 1680 0 1 2 3 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Type | Length | Vendor-Id 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Vendor-Id (cont) | Vendor type | Vendor length | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Continuation | VALUE ... 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1690 The fields have the following meaning and encoding: 1692 Type: 1694 26 for Vendor-Specific 1696 Length: 1698 6 + 3 + length of SubTypes 1700 Vendor-Id: 1702 The Vendor-Id value for WiMAX is 24757. 1704 Vendor type: 1706 37 for PPAQ 1708 Vendor length: 1710 3 + length of SubTypes 1712 Continuation: 1714 The Continuation Field is defined as follows: 1716 0 1717 0 1 2 3 4 5 6 7 1718 +-+-+-+-+-+-+-+-+ 1719 |C|r|r|r|r|r|r|r| 1720 +-+-+-+-+-+-+-+-+ 1722 The C-bit of the continuation field indicates 1723 if a attribute is being fragmented. When the 1724 C-bit is set to one '1' this indicates that 1725 the attribute is being fragmented that is 1726 the next VSA of the same type is to be appended 1727 to this attribute. When the C-bit is set to zero 1728 '0' this indicates that the next attribute is 1729 not a fragment of this attribute. 1730 An attribute that is not being fragmented will 1731 have the C-bit set to '0'. An attribute that is 1732 being fragmented will have its C-bit set to '1' 1733 for all fragments until the last fragment, which 1734 will have its C-bit set to '0' indicating it's 1735 the last fragment of the attribute. The r-bits 1736 are reserved for future use. They SHALL be set 1737 to zero by the sender and SHALL be ignored by 1738 the receiver. 1740 The value of the C-bit MAY be 0 or 1. 1742 VALUE: 1744 Data type String 1745 Each SubType is then encoded in the following style: 1747 0 1 2 3 1748 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | SubType | LENGTH | VALUE ... 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 The fields have the following meaning and encoding: 1755 SubType : 1757 Contains an 8 bit unsigned integer. 1759 LENGTH : 1761 Contains an 8 bit unsigned integer. 1762 The value of the LENGTH field is calculated as the length of the 1763 VALUE field plus two octets (one octet for the length of the 1764 SubType field and another octet for the length of the LENGTH 1765 field). 1767 Figure 11: PPAQ Attribute Encoding Style 1769 4.3.1. Quota Identifier (QID) SubType 1771 The Quota Identifier (QID) is generated by the PPS and subsequently 1772 returned in a PPAQ->QID subtype from the PPC to the PPS. This field 1773 has the semantic of a transaction identifier and therefore changes 1774 with every transaction initiated by the PPS to the PPC. 1776 0 1 2 3 1777 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 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | SubType | LENGTH | VALUE ... 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | VALUE | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 The fields have the following meaning and encoding: 1786 SubType : Value(1) 1788 LENGTH : 2 + length of VALUE field. 1790 VALUE : Data type String 1792 Quota Identifier (QID) SubType 1794 4.3.2. VolumeQuota SubType 1796 TVolumeQuota SubType is only present when volume-based charging is 1797 used. In a RADIUS Access-Accept message (PPS to PPC direction), it 1798 indicates the volume (in octets) allocated for the session by the 1799 PPS. In a RADIUS Authorize-Only Access-Request message (PPC to PPS 1800 direction), it indicates the totally used volume (in octets) for both 1801 inbound and outbound traffic. The Exponent Field, if present, MUST 1802 NOT encode a negative number or zero. 1804 0 1 2 3 1805 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 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | SubType | LENGTH | VALUE ... 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 The fields have the following meaning and encoding: 1812 SubType : Value(2) 1814 LENGTH : 2 + (8 or 12) 1816 VALUE : Data type String 1818 The content of the VALUE field either contains the 1819 Value-Digits Field (8 octets long) or the Value-Digits Field 1820 plus the Exponent Field (12 octets long). 1822 VolumeQuota SubType 1824 4.3.3. VolumeThreshold SubType 1826 The value of the type field of the VolumeThreshold SubType is TBD and 1827 its length is 10 or 14 octets. This SubType is optionally present if 1828 the VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1829 PPC direction). It is generated by the PPS and indicates the volume 1830 (in octets) that has to be consumed before a new quota is requested. 1831 This threshold MUST NOT be larger than the VolumeQuota. The Exponent 1832 Field, if present, MUST NOT encode a negative number or zero. 1834 0 1 2 3 1835 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 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | SubType | LENGTH | VALUE ... 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 The fields have the following meaning and encoding: 1842 SubType : Value(3) 1844 LENGTH : 2 + (8 or 12) 1846 VALUE : Data type String 1848 The content of the VALUE field either contains the 1849 Value-Digits Field (8 octets long) or the Value-Digits 1850 SubType plus the Exponent Field 12 octets long). 1852 VolumeThreshold SubType 1854 4.3.4. DurationQuota SubType 1856 The optional DurationQuota SubType is only present if duration-based 1857 charging is used. In a RADIUS Access-Accept message (PPS to PPC 1858 direction), it indicates the duration (in seconds) allocated for the 1859 session by the PPS. In a RADIUS Access-Request message (PPC to PPS 1860 direction), it indicates the total duration (in seconds) since the 1861 start of the accounting session related to the QID subtype of the 1862 PPAQ attribute in which it occurs. 1864 0 1 2 3 1865 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 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | SubType | LENGTH | VALUE ... 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | VALUE | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 The fields have the following meaning and encoding: 1874 SubType : Value(4) 1876 LENGTH : 2 + 4 1878 VALUE : Data type string. 1880 The content of this field contains a 32-bit unsigned integer 1881 (with the values 0 to +4,294,967,295). 1883 DurationQuota SubType 1885 4.3.5. DurationThreshold SubType 1887 The DurationThreshold SubType is optionally present if the 1888 DurationQuota is present in a RADIUS Access-Accept message (PPS to 1889 PPC direction). It represents the duration (in seconds) after which 1890 new quota should be requested. This threshold MUST NOT be larger 1891 than the DurationQuota SubType. 1893 0 1 2 3 1894 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 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | SubType | LENGTH | VALUE ... 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | VALUE | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 The fields have the following meaning and encoding: 1903 SubType : Value(5) 1905 LENGTH : 2 + 4 1907 VALUE : Data type string. 1909 The content of this field contains a 32-bit unsigned integer 1910 (with the values 0 to +4,294,967,295). 1912 DurationThreshold SubType 1914 4.3.6. ResourceQuota SubType 1916 The optional ResourceQuota SubType is only present if resource-based 1917 or one-time charging is used. In the RADIUS Access-Accept message 1918 (PPS to PPC direction) it indicates the resources allocated for the 1919 session by the PPS. In RADIUS Authorize-Only Access-Request message 1920 (PPC to PPS direction), it indicates the resources used in total, 1921 including both incoming and outgoing chargeable traffic. In one-time 1922 charging scenarios, the subtype represents the number of units to 1923 charge the user. The attribute consists of a Value-Digits Field and 1924 optionally an Exponent Field (as indicated by the length field). 1926 0 1 2 3 1927 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 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | SubType | LENGTH | VALUE ... 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 The fields have the following meaning and encoding: 1934 SubType : Value(6) 1936 LENGTH : 2 + (8 or 12) 1938 VALUE : Data type String 1940 The content of the VALUE field either contains the 1941 Value-Digits Field (8 octets long) or the Value-Digits Field 1942 plus the Exponent Field (12 octets long). 1944 ResourceQuota SubType 1946 4.3.7. ResourceThreshold SubType 1948 The semantic of the ResourceThreshold SubType follow those of the 1949 VolumeThreshold and DurationThreshold SubType. 1951 0 1 2 3 1952 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 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | SubType | LENGTH | VALUE ... 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 The fields have the following meaning and encoding: 1959 SubType : Value(7) 1961 LENGTH : 2 + (8 or 12) 1963 VALUE : Data type String 1965 The content of the VALUE field either contains the 1966 Value-Digits Field (8 octets long) or the Value-Digits Field 1967 plus the Exponent Field (12 octets long). 1969 ResourceThreshold SubType 1971 4.3.8. Update-Reason SubType 1973 The Update-Reason SubType is present in a RADIUS Access-Request 1974 message (PPC to PPS direction) and indicates the reason for 1975 initiating the quota update operation. Update reasons (6), (7), (8) 1976 and (9) indicate that the associated resources are released at the 1977 PPC side, and that therefore the PPS MUST NOT allocate a new quota in 1978 the RADIUS Access-Accept message. 1980 0 1 2 3 1981 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 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | SubType | LENGTH | VALUE | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 The fields have the following meaning and encoding: 1988 SubType : Value(8) 1990 LENGTH : 2 + 1 1992 VALUE : Data type string 1994 This field contains a byte 1995 (with the values 0 to 255). 1997 Update-Reason SubType 1999 The following values for the Update-Reason SubType are defined: 2001 Value | Description 2002 -------------+-------------------------------------- 2003 0 | Reserved 2004 1 | Pre-initialization 2005 2 | Initial Request 2006 3 | Threshold Reached 2007 4 | Quota Reached 2008 5 | TITSU Approaching 2009 6 | Remote Forced Disconnect 2010 7 | Client Service Termination 2011 8 | "Access Service" Terminated 2012 9 | Service not established 2013 10 | One-Time Charging 2014 11...255 | **Available for IANA registration** 2016 Figure 12: Values for Update-Reason SubType 2018 4.3.9. PrepaidServer SubType 2020 The optional PrepaidServer SubType indicates the address of the 2021 serving PPS. If present, the Home RADIUS server uses this address to 2022 route the message to the serving PPS. Multiple instances of this 2023 subtype MAY be present in a single PPAQ attribute. 2025 If present in the PrepaidServer SubType of an incoming RADIUS Access- 2026 Accept message, the PPC returns this SubType back without modifying 2027 it in the subsequent RADIUS Access-Request message. If multiple 2028 values are present, the PPC MUST NOT change their order. 2030 0 1 2 3 2031 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 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | SubType | LENGTH | Address ... 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 The fields have the following meaning and encoding: 2038 SubType : Value(9) 2040 LENGTH : 2 + (4 or 16) 2042 Address : Data type String 2044 For IPv4, the Address field is 4 octets based on the encoding of 2045 the NAS-IP-Address defined in RFC 2138. For IPv6, the Address 2046 field is 16 octets long. 2048 PrepaidServer SubType 2050 4.3.10. Service-ID SubType 2052 The Service-ID SubType is handled as an opaque string that uniquely 2053 describes the service instance for which prepaid metering should be 2054 applied. 2056 A Service-Id could be an IP 5-tuple (source address, source port, 2057 destination address, destination port, protocol). If a Service-ID 2058 SubType is present in the PPAQ, the entire PPAQ attribute refers to 2059 that service. If a PPAQ attribute does not contain a Service-Id or 2060 Rating-Group-ID, then the PPAQ attribute refers to the "Access 2061 Service". 2063 0 1 2 3 2064 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 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | SubType | LENGTH | Service ... 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 The fields have the following meaning and encoding: 2071 SubType : Value(10) 2073 LENGTH : 2 + length (Service) 2075 Service : Data type String 2077 Service-ID SubType 2079 4.3.11. Rating-Group-ID SubType 2081 The Rating-Group-ID SubType indicates that this PPAQ attribute is 2082 associated with resources allocated to a Rating Group with the 2083 corresponding ID. This SubType is encoded as a string. A single 2084 PPAQ MUST NOT contain more than one Rating-Group-ID. 2086 0 1 2 3 2087 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 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | SubType | LENGTH | VALUE ... 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | VALUE | 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 The fields have the following meaning and encoding: 2096 SubType : Value(11) 2098 LENGTH : 2 + 4 2100 VALUE : Data type string with a length of 4 octets 2102 Rating-Group-ID SubType 2104 4.3.12. Termination-Action SubType 2106 The value of the type field of the Termination-Action SubType is TBD. 2107 The length of this SubType is 3 octets. This SubType contains an 2108 enumeration of the action to take when the PPS does not grant 2109 additional quota. Valid actions are as follows. 2111 0 1 2 2112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | SubType | LENGTH | Action | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 The fields have the following meaning and encoding: 2119 SubType : Value(12) 2121 LENGTH : 2 + 1 2123 Action : Data type string. 2125 The content is a byte (with the values 0 to +255). 2127 Termination-Action SubType 2129 The following values for the Termination-Action SubType are defined: 2131 Value | Description 2132 -------------+------------------------------------ 2133 0 | Reserved 2134 1 | Terminate 2135 2 | Request More Quota 2136 3 | Redirect/Filter 2137 4..255 | **Available for IANA registration** 2139 Figure 13: Values for the Termination-Action SubType 2141 4.3.13. Pool-ID SubType 2143 The Pool-ID SubType identifies the resource pool. It is encoded as a 2144 string. 2146 0 1 2 3 2147 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 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | SubType | LENGTH | Poolid | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 The fields have the following meaning and encoding: 2154 SubType : Value(13) 2156 LENGTH : 2 + 4 2158 Poolid : Data type string with length of 4 octets. 2160 Pool-ID SubType 2162 4.3.14. Pool-Multiplier SubType 2164 The Pool-Multiplier SubType determines the weight of resources when 2165 they are inserted into the pool that is identified by the 2166 accompanying Pool-ID SubType, and the rate at which resources are 2167 taken out of the pool by the relevant Service or Rating-Group. 2169 0 1 2 3 2170 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 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | SubType | LENGTH | VALUE ... 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 The fields have the following meaning and encoding: 2177 SubType : Value(14) 2179 LENGTH : 2 + (8 or 12) 2181 VALUE : Data type String 2183 The content of the VALUE field either contains the 2184 Value-Digits Field (8 octets long) or the Value-Digits Field 2185 plus the Exponent Field (12 octets long). 2187 Pool-Multiplier SubType 2189 4.3.15. Requested-Action SubType 2191 The Requested-Action SubType is only be present in messages sent from 2192 the PPC to the PPS. It indicates that the PPC desires the PPS to 2193 perform the indicated action and to return the result. The PPAQ in 2194 which a Requested-Action SubType occurs MUST NOT contain a QID, and 2195 MUST contain a Service-Identifier or a Rating-Group-Identifer that 2196 allows the PPS to uniquely identify the service for which the 2197 indicated action is requested. 2199 0 1 2 2200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | SubType | LENGTH | Action | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 The fields have the following meaning and encoding: 2207 SubType : Value(15) 2209 LENGTH : 2 + 1 2211 Action : Data type string. 2213 The content is a byte (with the values 0 to +255). 2214 The values are listed below. 2216 Requested-Action SubType 2218 The following values for the Action field of the Requested-Action 2219 SubType are defined: 2221 Value | Description 2222 -------------+------------------------------------- 2223 0 | Reserved 2224 1 | Balance Check 2225 2 | Price Enquiry 2226 3..255 | **Available for IANA registration** 2228 Figure 14: Values for the Requested-Action SubType 2230 4.3.16. Check-Balance-Result SubType 2232 The Check-Balance-Result SubType can only be present in messages sent 2233 from the PPS to the PPC. It indicates the balance check decision of 2234 the PPS about a previously received Balance Check Request (as 2235 indicated in a Requested-Action SubType). The PPAQ attribute in 2236 which a Check-Balance-Result occurs MUST NOT include a QID beause no 2237 quota is reserved by the PPS. 2239 0 1 2 2240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | SubType | LENGTH | Decision | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 The fields have the following meaning and encoding: 2247 SubType : Value(16) 2249 LENGTH : 2 + 1 2251 Decision : Data type string. 2253 The content is a byte (with the values 0 to +255). 2254 The values are listed below. 2256 Check-Balance-Result SubType 2258 The following values for the Decision field of the Check-Balance- 2259 Result SubType are defined: 2261 Value | Description 2262 -------------+------------------------------------------- 2263 0 | Success; Sufficient funds available 2264 | in the user's prepaid account 2265 1 | Failure; Insufficient funds available 2266 2..255 | **Available for IANA registration** 2268 Figure 15: Values for the Check-Balance-Result SubType 2270 4.3.17. Cost-Information SubType 2272 The Cost-Information SubType is used in order to return the cost 2273 information of a service, which the PPC can transfer transparently to 2274 the end user. This SubType is sent from the PPS to the PPC as a 2275 response to a "Price Enquiry", as indicated by the Requested-Action 2276 SubType. 2278 0 1 2 3 2279 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 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | SubType | LENGTH | VALUE ... 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 The fields have the following meaning and encoding: 2286 SubType : Value(17) 2288 LENGTH : 2 + 12 + 4 + length of the Cost-Unit Field 2290 VALUE : Data type String 2292 The content of the VALUE field contains (in this order) the 2293 Value-Digits Field, Exponent Field, Currency-Code Field 2294 and the Cost-Unit Field. 2296 Cost-Information SubType 2298 For example, the cost of 7.75 Malawi kwacha per hour would be encoded 2299 as follows. Value-Digits = 775, Exponent = -2, Currency Code = 454, 2300 and Cost-Unit = "hour". 2302 The PPAQ that carries a Cost-Information MUST NOT include a QID. 2304 The Currency-Code Field is of type Unsigned32 and used inside the 2305 Check-Balance-Result SubType and contains a currency code that 2306 specifies in which currency the values of AVPs containing monetary 2307 units were given. It is specified by using the numeric values 2308 defined in the ISO 3166-1 standard. 2310 The Cost-Unit Field is used inside the Check-Balance-Result SubType 2311 and contains a human readable UTF8 encoded string that can be 2312 displayed to the end user. It specifies the applicable unit to the 2313 Cost-Information when the service cost is a cost per unit (e.g., cost 2314 of the service is $1 per minute). The Cost-Unit can, for example, be 2315 minutes, hours, days, kilobytes, megabytes, etc. 2317 4.4. Fields 2319 4.4.1. Value-Digits Field 2321 The Value-Digits Field is an Unsigned64 value (with a length of 8 2322 octets) that contains the significant digits of the number. If 2323 decimal values are needed to present the number, the scaling MUST be 2324 indicated with a related Exponent Field, see Section 4.4.2. 2326 For example, the decimal number 0.05 is encoded by a Value-Digits 2327 Field set to 5, and a scaling that is indicated with the Exponent 2328 Field set to -2. 2330 The encoding of this SubType is not done in an TLV format but rather 2331 the encoded value is added to existing subtypes. 2333 4.4.2. Exponent Field 2335 The Exponent field is a Integer32 value that contains the exponent 2336 value that is to be applied to the accompanying Value-Digit Field. 2338 4.5. Prepaid Tariff Switching (PTS) Attribute 2340 This specification defines the PTS attribute, which allows to switch 2341 from one rate to another during service provision. Support for 2342 tariff switching is optional to implement and to use for the PPC and 2343 the PPS. PPCs use the flag "Tariff Switching supported" in the 2344 AvailableInClient field of the PPAC attribute in order to indicate 2345 support for tariff switching. PPSs employ the PTS attribute in order 2346 to announce their support for tariff switching. 2348 If a RADIUS message contains a PTS attribute, it MUST also contain at 2349 least one PPAQ attribute. If a RADIUS Access-Request message 2350 contains a PTS attribute or the "Tariff Switching supported" flag in 2351 the AvailableInClient field of the PPAC attribute, it MUST also 2352 contain an Event-Timestamp RADIUS attribute (see [RFC2869]). 2354 Every PTS attribute MUST include a QID SubType, as specified in 2355 Section 4.3.1. In a RADIUS Access-Request message sent from the PPC 2356 to the PPS, the QID SubType MUST contain the value of the Quota 2357 Identifier SubType that was previously received from the PPS and MUST 2358 be the same as the value carried in the QID SubType of one of the 2359 PPAQ attributes included the same RADIUS message. 2361 If multiple services are supported and if the PPAQ is associated with 2362 a service as indicated by the Service-ID SubType, then the PTS refers 2363 to the tariff switch for that service. If the PPAQ does not have a 2364 Service-ID, then the PTS refers to tariff switch for the "Access 2365 Service". 2367 A PPAQ attribute that is transported along with a PTS attribute and 2368 has the same value as the QID SubType contained in the PTS attribute 2369 in its own QID SubType is referred to as the "accompanying PPAQ 2370 attribute". If a PPS receives an Access-Request message from a PPC, 2371 it associates a unique value for the QID SubType to this request. 2373 The following table summarizes the presence of various SubTypes in 2374 the PTS attribute carried in the Access-Request and Access-Accept 2375 messages. 2377 Request Accept # SubType Name 2378 1 1 1 Quota Identifier 2379 1 0 2 VolumeUsedAfterTariffSwitch 2380 0 0-1 3 TarrifSwitchInterval 2381 0 0-1(a) 4 TimeIntervalAfterTarriffSwitchUpdate 2383 None of the above-listed SubTypes appears in the Access-Reject nor in 2384 the Access-Challenge. 2386 Notes: 2388 (a) The PPS SHALL include this AVP if there is another tariff 2389 switch period after the period that ends as indicated by the TSI 2390 attribute. 2392 0 1 2 3 2393 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 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Type | Length | Vendor-Id 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 Vendor-Id (cont) | Vendor type | Vendor length | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Continuation | VALUE ... 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2402 The fields have the following meaning and encoding: 2404 Type: 2406 26 for Vendor-Specific 2408 Length: 2410 6 + 3 + length of SubTypes 2412 Vendor-Id: 2414 The Vendor-Id value for WiMAX is 24757. 2416 Vendor type: 2418 38 for PTS 2420 Vendor length: 2422 3 + length of SubTypes 2424 Continuation: 2426 The Continuation Field is defined as follows: 2428 0 2429 0 1 2 3 4 5 6 7 2430 +-+-+-+-+-+-+-+-+ 2431 |C|r|r|r|r|r|r|r| 2432 +-+-+-+-+-+-+-+-+ 2434 The C-bit of the continuation field indicates 2435 if a attribute is being fragmented. When the 2436 C-bit is set to one '1' this indicates that 2437 the attribute is being fragmented that is 2438 the next VSA of the same type is to be appended 2439 to this attribute. When the C-bit is set to zero 2440 '0' this indicates that the next attribute is 2441 not a fragment of this attribute. 2442 An attribute that is not being fragmented will 2443 have the C-bit set to '0'. An attribute that is 2444 being fragmented will have its C-bit set to '1' 2445 for all fragments until the last fragment, which 2446 will have its C-bit set to '0' indicating it's 2447 the last fragment of the attribute. The r-bits 2448 are reserved for future use. They SHALL be set 2449 to zero by the sender and SHALL be ignored by 2450 the receiver. 2452 The value of the C-bit MAY be 0 or 1. 2454 VALUE : Variable length content of data type String containing 2455 one or multiple SubTypes. 2457 Each SubType is then encoding in the following style: 2459 0 1 2 3 2460 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 2461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2462 | SubType | LENGTH | VALUE ... 2463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 The fields have the following meaning and encoding: 2467 SubType: 2469 Contains an 8 bit unsigned integer. 2471 LENGTH: 2473 Contains an 8 bit unsigned integer. 2475 VALUE: 2477 Contains the content of the SubType. 2479 Figure 16: PTS Attribute 2481 4.5.1. VolumeUsedAfterTariffSwitch SubType 2483 The optional VolumeUsedAfterTariffSwitch (VUATS) SubType is used in 2484 the RADIUS Access-Request messages (PPC to PPS direction). It 2485 indicates the volume (in octets) used during a session after the last 2486 tariff switch for the service specified via the QID SubType and the 2487 accompanying PPAQ attribute. 2489 0 1 2 3 2490 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 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | SubType | LENGTH | VALUE ... 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 The fields have the following meaning and encoding: 2497 SubType : Value(23) 2499 LENGTH : variable (8 or 14) 2501 VALUE : Data type String 2503 The content of the VALUE field either contains the 2504 Value-Digits Field or the Value-Digits Field plus the 2505 Exponent Field. The length field indicates whether one or 2506 both subtypes are included. 2508 VolumeUsedAfterTariffSwitch SubType 2510 4.5.2. TariffSwitchInterval SubType 2512 The TariffSwitchInterval (TSI) SubType MUST be present in each PTS 2513 attribute that is part of a RADIUS Access-Accept message (PPS to PPC 2514 direction). It indicates the interval (in seconds) between the value 2515 of Event-Timestamp RADIUS attribute (see [RFC2869]) of the 2516 corresponding RADIUS Access-Request message and the next tariff 2517 switch condition. 2519 0 1 2 3 2520 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 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | SubType | LENGTH | VALUE ... 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 | VALUE | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 The fields have the following meaning and encoding: 2529 SubType : Value(24) 2531 LENGTH : 6 2533 VALUE : Data type string 2535 This field contains a 16-bit unsigned integer 2536 (with the values 0 to +65,535). 2538 TariffSwitchInterval SubType 2540 4.5.3. TimeIntervalafterTariffSwitchUpdate SubType 2542 The PPS MUST include TimeIntervalafterTariffSwitchUpdate (TITSU) 2543 SubType if there is another tariff switch period after the period 2544 that ends as indicated by the TSI SubType. The value of the TITSU 2545 SubType contains the number of seconds of the tariff period that 2546 begins immediately after the period that ends as indicated by the TSI 2547 attribute. If the TITSU SubType is not present, the PPC assumes that 2548 the tariff period, which ends as indicated by the TSI SubType, lasts 2549 until further notice. If TITSU is specified, the PPC MUST send a 2550 quota update before the point in time specified by the TITSU SubType 2551 (see Figure 7). 2553 0 1 2 3 2554 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 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | SubType | LENGTH | VALUE ... 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | VALUE | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 The fields have the following meaning and encoding: 2563 SubType : Value(25) 2565 LENGTH : 6 2567 VALUE : Data type string 2569 This field contains a 16-bit unsigned integer 2570 (with the values 0 to +65,535). 2572 TimeIntervalafterTariffSwitchUpdate SubType 2574 5. Diameter RADIUS Interoperability 2576 The RADIUS Prepaid extension described in this document may need to 2577 interoperate with the Diameter Credit Control Application. Two 2578 interoperability scenarios exist, as follows. Either the AAA server 2579 is Diameter based and the AAA client is RADIUS based, or the AAA 2580 client is Diameter based and the AAA server is RADIUS based. 2582 The Diameter Credit Control Application [RFC4006] describes how to 2583 implement a prepaid accounting system using a Diameter based 2584 infrastructure. 2586 A possible procedure for accomplishing the translation of the 2587 functionality defined in Diameter Credit Control and in the RADIUS 2588 Prepaid specification is described in Appendix B. 2590 6. Security Considerations 2592 This specification describes the use of RADIUS for purposes of real- 2593 time accounting. Threats and security issues for this application 2594 are described in [RFC3579] and [RFC3580]; security issues encountered 2595 in roaming are described in [RFC2607]. 2597 This document specifies new attributes that can be included in 2598 existing RADIUS packets, which are protected as described in 2599 [RFC3579] and [RFC3576]. See those documents for a more detailed 2600 description. 2602 The security mechanisms supported in RADIUS are focused on preventing 2603 an attacker from spoofing packets or modifying packets in transit. 2604 They do not prevent an authorized RADIUS/Diameter server or proxy 2605 from modifying, inserting, or removing attributes with malicious 2606 intent. When the attributes defined in this document are modified or 2607 removed by a RADIUS proxy they may lead to incorrect accounting 2608 records being delivered to users or wrong resource consumption being 2609 collected. 2611 The described mechanism add the mechanism of capability negotiation, 2612 so that a RADIUS server can automatically discover whether a NAS 2613 supports the real-time accounting features described in this document 2614 (and even more detailed capabilities can be learned by the RADIUS 2615 server). These mechanisms are being added to ensure that neither the 2616 NAS nor the RADIUS server make incorrect assumptions about the 2617 capabilities of the other party; potentially leading to incorrect 2618 accounting and improper access to the network or other services. 2620 7. Table of Attributes 2622 The following table provides a guide which attributes may be found in 2623 which RADIUS messages, and in what quantity. 2625 Request Accept Reject Challenge Accounting # Attribute 2626 Request 2627 0-1 0 0 0 0 35 PPAC 2628 0-1 0 0 0 0 36 Session Termination 2629 Capability 2630 0+ 0+ 0 0 0+ 37 PPAQ 2631 0+ 0+ 0 0 0+ 38 PTS 2633 8. IANA Considerations 2635 This document contains a number of instructions to IANA. 2637 8.1. RADIUS Attributes 2639 This document does not require IANA to register the following four 2640 RADIUS attributes as the code registered by the Wimax Forum is re- 2641 used. The Wimax Forum SMI Network Management Private Enterprise Code 2642 is 24757. 2644 Attribute Name | Attribute Type Value 2645 --------------------------------------+----------------------------- 2646 Prepaid-Accounting-Capability (PPAC) | 35 2647 Session Termination Capability | 36 2648 Prepaid-Accounting-Operation (PPAQ) | 37 2649 Prepaid Tariff Switching (PTS) | 38 2651 8.2. New Registry: PPAC SubTypes 2653 Section 4.1 defines the SubTypes used within the PPAC attribute. 2654 IANA is asked to create a registry for these SubTypes. Each registry 2655 entry consists of a 8 bit number together with a description of the 2656 PPAC SubType. This document creates the following PPAC SubTypes for 2657 this registry: 2659 Value | SubType Name 2660 ---------+----------------------------- 2661 0 | Reserved 2662 1 | AvailableInClient 2663 2..255 | **Available for IANA registration** 2665 The semantic of the above-listed SubType is described in Section 4.1. 2667 Following the policies outline in [RFC3575] the available SubTypes 2668 (i.e., value 0 and values 2-255) with a description of their semantic 2669 will be assigned after the expert review process. Updates can be 2670 provided based on expert approval only. Based on expert approval it 2671 is possible to mark entries as "deprecated". A designated expert 2672 will be appointed by the IESG. 2674 Each registration must include a number for the SubType and the 2675 semantic of the SubType. 2677 8.3. New Registry: PPAQ SubTypes 2679 Section 4.3 defines the SubTypes used within the PPAQ attribute. 2680 IANA is asked to create a registry for these SubTypes. Each registry 2681 entry consists of a 8 bit number together with a description of the 2682 PPAQ SubType. This document creates the following PPAQ SubTypes for 2683 this registry: 2685 Value | SubType Name 2686 ---------+----------------------------- 2687 0 | Reserved 2688 1 | Quota Identifier 2689 2 | VolumeQuota 2690 3 | VolumeThreshold 2691 4 | DurationQuota 2692 5 | DurationThreshold 2693 6 | ResourceQuota 2694 7 | ResourceThreshold 2695 8 | Update-Reason 2696 9 | PrepaidServer 2697 10 | Service-ID 2698 11 | Rating-Group-ID 2699 12 | Termination-Action 2700 13 | Pool-ID 2701 14 | Pool-Multiplier 2702 15 | Requested-Action 2703 16 | Check-Balance-Result 2704 17..255 | **Available for IANA registration** 2706 The semantic of the above-listed SubTypes is described in 2707 Section 4.3. 2709 Following the policies outline in [RFC3575] the available SubTypes 2710 (i.e., value 0 and values 22-255) with a description of their 2711 semantic will be assigned after the expert review process. Updates 2712 can be provided based on expert approval only. Based on expert 2713 approval it is possible to mark entries as "deprecated". A 2714 designated expert will be appointed by the IESG. 2716 Each registration must include a number for the SubType and the 2717 semantic of the SubType. 2719 8.4. New Registry: PTS SubTypes 2721 Section 4.5 defines the SubTypes used within the PTS attribute. IANA 2722 is asked to create a registry for these SubTypes. Each registry 2723 entry consists of a 8 bit number together with a description of the 2724 PTS SubType. This document creates the following PTS SubTypes for 2725 this registry: 2727 Value | SubType Name 2728 ---------+----------------------------- 2729 0 | Reserved 2730 1 | Quota Identifier 2731 2 | VolumeUsedAfterTariffSwitch 2732 3 | TariffSwitchInterval 2733 4 | TimeIntervalafterTariffSwitchUpdate 2734 5..255 | **Available for IANA registration** 2736 The semantic of the above-listed SubTypes is described in 2737 Section 4.5. 2739 Following the policies outline in [RFC3575] the available SubTypes 2740 (i.e., value 0 and values 5-255) with a description of their semantic 2741 will be assigned after the expert review process. Updates can be 2742 provided based on expert approval only. Based on expert approval it 2743 is possible to mark entries as "deprecated". A designated expert 2744 will be appointed by the IESG. 2746 Each registration must include a number for the SubType and the 2747 semantic of the SubType. 2749 8.5. New Registry: Update-Reason 2751 Section 4.3.8 defines the Update-Reason SubType. IANA is asked to 2752 create a registry for the values contained in the Update-Reason 2753 SubType, as shown in Figure 12. Each registry entry consists of a 16 2754 bit number together with a description of the update reason. 2756 Following the policies outline in [RFC3575] the available values 2757 together with a description of their semantic will be assigned after 2758 the expert review process. Updates can be provided based on expert 2759 approval only. Based on expert approval it is possible to mark 2760 entries as "deprecated". A designated expert will be appointed by 2761 the IESG. 2763 8.6. New Registry: Termination-Action 2765 Section 4.3.12 defines the Termination-Action SubType. IANA is asked 2766 to create a registry for the values contained in the Termination- 2767 Action SubType, as shown in Figure 13. Each registry entry consists 2768 of a 8 bit number together with a description of the termination 2769 action. 2771 Following the policies outline in [RFC3575] the available values 2772 together with a description of their semantic will be assigned after 2773 the expert review process. Updates can be provided based on expert 2774 approval only. Based on expert approval it is possible to mark 2775 entries as "deprecated". A designated expert will be appointed by 2776 the IESG. 2778 8.7. New Registry: Requested-Action 2780 Section 4.3.15 defines the Requested-Action SubType. IANA is asked 2781 to create a registry for the values contained in the Requested-Action 2782 SubType, as shown in Figure 14. Each registry entry consists of a 8 2783 bit number together with a description of the requested reason. 2785 Following the policies outline in [RFC3575] the available values 2786 together with a description of their semantic will be assigned after 2787 the expert review process. Updates can be provided based on expert 2788 approval only. Based on expert approval it is possible to mark 2789 entries as "deprecated". A designated expert will be appointed by 2790 the IESG. 2792 8.8. New Registry: Check-Balance-Result 2794 Section 4.3.16 defines the Check-Balance-Result SubType. IANA is 2795 asked to create a registry for the values contained in the Check- 2796 Balance-Result SubType, as shown in Figure 15. Each registry entry 2797 consists of a 8 bit number together with a description of the 2798 requested reason. 2800 Following the policies outline in [RFC3575] the available values 2801 together with a description of their semantic will be assigned after 2802 the expert review process. Updates can be provided based on expert 2803 approval only. Based on expert approval it is possible to mark 2804 entries as "deprecated". A designated expert will be appointed by 2805 the IESG. 2807 9. Acknowledgements 2809 The authors would like to thank Bernard Aboba, Christian Guenther, 2810 Dirk Kroeselberg and John Loughney for their feedback throughout the 2811 development of this document. Additionally, the authors would like 2812 to thank the members of the Wimax Forum and the members of 3GPP2 for 2813 their help with this specification. 2815 10. References 2817 10.1. Normative References 2819 [RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to 2820 Indicate Requirement Levels", March 1997. 2822 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2823 2865: Remote Authentication Dial In User Server (RADIUS)", 2824 June 2000. 2826 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2827 Adoba, "RFC 3576: Dynamic Authorization Extensions to 2828 Remote Authentication Dial-In User Service (RADIUS)", 2829 February 2003. 2831 10.2. Informative References 2833 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2834 Authentication Protocol (EAP)", RFC 2284, March 1998. 2836 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2837 Implementation in Roaming", RFC 2607, June 1999. 2839 [RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2841 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2842 Extensions", June 2000. 2844 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 2845 Authentication Dial In User Service)", RFC 3575, 2846 July 2003. 2848 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2849 Dial In User Service) Support For Extensible 2850 Authentication Protocol (EAP)", RFC 3579, September 2003. 2852 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 2853 "IEEE 802.1X Remote Authentication Dial In User Service 2854 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2856 [RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2857 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2858 June 2004. 2860 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2861 Loughney, "RFC 4006: Diameter Credit Control Application", 2862 August 2005. 2864 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 2865 Rule Attribute", RFC 4849, April 2007. 2867 Appendix A. Example flows 2869 Note: This section is informative. 2871 This section presents certain example flows that involve the RADIUS 2872 prepaid extensions. By no means is the intent of this section to 2873 specify or recommend business logic, rating strategies, and 2874 application-level behaviour. The intent of this section is purely to 2875 illustrate some fictive scenarios and the RADIUS prepaid message 2876 flows that could be associated with these scenarios. The contents of 2877 this section should be regarded as a collection of informative 2878 examples that aim to provide guidance to implementors. 2880 A.1. A simple flow 2882 End user PPC PPS 2884 user logs on 2885 ------(1)---------> 2886 Access Request 2887 {RADIUS BASE AVPS, 2888 PPAC=00...00011} 2889 -------(2)--------> 2891 [allocates 2892 5MB quota] 2894 Access Accept 2895 {RADIUS BASE AVPS, 2896 PPAQ={QID=5, VQ = 5MB, 2897 VTH = 4.5 MB}} 2898 <-------(3)-------- 2900 service provision/metering 2901 -------(4)---------> 2903 4.5 MB consumed 2905 Access Request 2906 {RADIUS BASE AVPS, 2907 PPAQ={QID=5, VQ=4.5MB, 2908 REASON=THRESHOLD REACHED}} 2909 -------(5)---------> 2911 [allocates another 7MB 2912 to the access service] 2914 Access Accept 2915 {RADIUS BASE AVPS, 2916 PPAQ={QID=8, VQ=12MB, 2917 VTH = 11.5 MB}} 2918 <----------(6)-------------- 2919 user logs off 2920 ------(7)------- 2921 Access Request 2922 {RADIUS BASE AVPS, 2923 PPAQ={QID=8, VQ=7 MB, 2924 REASON=ACCESS SERV TERMINATED}} 2925 -------(8)---------> 2927 [reimburses 2928 user account] 2930 AA Accept 2931 {RADIUS BASE AVPS} 2932 <-------(9)-------- 2934 Figure 17: A simple example message flow 2936 The user logs on (1). The PPC sends a RADIUS Access Request message 2937 to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP 2938 indicates that both duration-based and volume-based metering is 2939 supported. However, it also indicated that multiple services, rating 2940 groups and resource pools are not supported. Note that, since this 2941 is not an "Authorize-Only" message, no PPAQ attribute with Update 2942 Reason="initial request" is included (see Section 3.7.1). The PPS 2943 then authenticates the user and authorizes the access service, as is 2944 usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at 2945 least the last message that is sent to the home AAA server during 2946 this possibly multiple-round exchange. 2948 If authentication and authorization is successful (in this example 2949 this is assumed), then the PPS identifies the user's prepaid account 2950 from the included base RADIUS AVPs, and determines the capabilities 2951 of the PPC from the PPAC attribute. Assuming that sufficient funds 2952 are available in the user's prepaid account, the PPS reserves some of 2953 these and rates the service. In this example, the PPS reserves, say, 2954 2 Euros and determines that the access service is rated at 0.4 Euro 2955 per MB. This results in 5 MB of quota being granted. The PPS also 2956 determines that the PPC should ask for this quota to be replenished 2957 once 4.5 MB have been consumed. Thus, it creates an Access Accept 2958 message with a Volume-Threshold indication of 4.5MB. It further 2959 associates the QID=5 to this reservation. This identifier can be 2960 used to later uniquely identify the prepaid session, user, account, 2961 etc. The resulting Access Accept message is sent to the PPC (3). 2963 Upon reception of message (4), the PPC provides the access service to 2964 the user and meters it accordingly. At some point in time, the 2965 threshold is reached, i.e., 4.5MB of "access service" have been 2966 consumed by the user. At that point, the PPC generates an Authorize- 2967 Only Access Request that contains the usual RADIUS attributes and a 2968 PPAQ attributes that reports the amount of consumed quota, and the 2969 request for replenishment, i.e., the Update-Reason= THRESHOLD REACHED 2970 (5). Note that the QID in this message is the same as the one 2971 previously received from the PPS. 2973 Upon reception of message (5), the PPS identifies the user and his 2974 account from the QID. In also determines that a prepaid session is 2975 ongoing, and that enough credit remains in the prepaid account in 2976 order for the access service to continue being provided. Since 4.5 2977 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2978 prepaid account. The PPS decides to reserve another 2.8 euros from 2979 the user's account. (This results in 3 euros being reserved in total 2980 at this point in time.) As the access service is rated at 0.4 euros 2981 per MB, the PPS determines that another 7 MB of quota should be 2982 granted. This results in a total cumulative quota allocation of 12 2983 MB for the access service. The PPS further calculates the new 2984 threshold value of 11.5 MB. Since this is a new quota reservation, 2985 the PPS also allocates a new QID to it, in this example QID=8. The 2986 resulting RADIUS message is sent to the PPC (6). 2988 Upon reception of message (6), the PPC updates its records and 2989 continues provisioning access to the user. At some point the user 2990 logs off (7). The PPC must then report how many resources were 2991 consumed, so that the PPC can subtract the appropriate monetary 2992 amount from the user's prepaid account. To this end the PPC 2993 constructs an Authorize-Only Access Request message with a PPAQ 2994 attributes for the access service. In this example, 7 MB were 2995 consumed by the access service in total. The PPC reports 7 MB its 2996 final message (8). The PPS correlates the report, using the QID, to 2997 the previous session state. It determines, from the previous 2998 records, that the access service had consumed another 4.5 MB before 2999 (as indicated in message (6)). This means that, of the 7 MB, only 3000 3.5 MB have not yet been subtracted from the user's account. Thus, 3001 the PPS subtracts another 1.4 euros from the user's account and, 3002 since the session is to be terminated (REASON=ACCESS SERVICE 3003 TERMINATED), releases any reserved monetary amount. 3005 The PPS responds with an Access Response as required by the RADIUS 3006 base specification (9). 3008 A.2. A flow with prepaid tariff switching 3010 End user PPC PPS 3012 user logs on 3013 ------(1)---------> 3014 Access Request 3015 {RADIUS BASE AVPS, 3016 PPAC=00...00111} 3017 -------(2)--------> 3019 [allocates 3020 20MB quota] 3022 Access Accept 3023 {RADIUS BASE AVPS, 3024 PPAQ={QID=5, VQ = 20MB, 3025 VTH = 18 MB}, PTS={ 3026 QID=5, PTS{TSI=300sec, 3027 TITSU=6000sec}} 3028 <-------(3)------- 3030 service provision/metering 3031 -------(4)---------> 3033 5900 seconds 3034 passed 3035 Access Request 3036 {RADIUS BASE AVPS, 3037 PPAQ={QID=5, VQ=14MB, 3038 REASON=TITSU APPROACH.}, 3039 TSI={QID=5, VUATS=11MB}} 3040 -------(5)---------> 3042 [allocates another 10MB 3043 to the access service] 3045 Access Accept 3046 {RADIUS BASE AVPS, 3047 PPAQ={QID=8, VQ=30MB, 3048 VTH = 28 MB},PTS={ 3049 QUD=8, PTS=95 sec}} 3050 <----------(6)-------------- 3052 user logs off 3054 ------(7)------- 3056 Access Request 3057 {RADIUS BASE AVPS, 3058 PPAQ={QID=8, VQ=17 MB, 3059 REASON=ACCESS SERV TERMINATED}, 3060 PTS={QID=8, VUATS=2.5 MB} 3061 -------(8)---------> 3063 [reimburses 3064 user account] 3066 AA Accept 3067 {RADIUS BASE AVPS} 3068 <-------(9)-------- 3070 Figure 18: Example message flow with Tariff Switch 3072 The user logs on (1). The PPC sends a RADIUS Access Request message 3073 to the home AAA server (2), and includes the prepaid-specific PPAC 3074 AVP. This AVP indicates that both duration-based and volume-based 3075 metering is supported, as well as tariff switching. The home AAA 3076 server then may authenticate and user and authorize the access 3077 service, as is usual in RADIUS. Note that the PPAC AVP is appended 3078 by the PPC in at least the last message that is sent to the PPS 3079 during this possibly multiple-round exchange. 3081 If authentication and authorization is successful (in this example 3082 this is assumed), the PPS identifies the user's prepaid account from 3083 the included base RADIUS AVPs, and determines the capabilities of the 3084 PPC from the PPAC attribute. In this example, it is assumed that a 3085 tariff switch is about to occur in 300 seconds from the current time. 3086 Suppose that the access service is currently rated at 0.5 euros per 3087 MB and in the next tariff period it is rated at 0.6 euros per MB. 3088 Suppose further that a third tariff period is about to start in 6000 3089 seconds from current time and that that access service is rated at 3090 0.8 euros per MB in that period. The PPS then decides to reserve 12 3091 euros from the user's account. Since it is conceivable that the user 3092 may consume all allocated quota in the (more expensive) "0.6-euro" 3093 period, the PPS reserves 20 MB of quota, and determines a threshold 3094 value of 18 MB. It constructs a Radius Access Accept message with a 3095 PPAQ attribute that reflects these choices, and carries a Quota 3096 Identifier QID=5. It further adds a PTS AVP in the message which is 3097 linked to the PPAQ via the common QID value. The PTS AVP contains a 3098 TSI attribute indicating that a tariff switch will occur in 300 3099 seconds. It also includes a TITSU attribute with the value of 6000 3100 seconds. This is included in order to make sure that the PPC will 3101 report the consumed quota before the "2-euro" tariff period will 3102 start. The message is sent to the PPC (3). 3104 Upon reception of message (3), the PPC provides the access service to 3105 the user and meters it accordingly (4). It also keeps track of time. 3106 That is, it remembers how many octets are consumed before and how 3107 many after the tariff switch that will take place in 300 seconds. 3109 In this example it is assumed that the user consumes the allocated 3110 quota rather slowly. In particular, nearly 6000 seconds (the value 3111 indicated by TITSU SubType) pass without the threshold of 18 MB being 3112 reached. The PPC notices this and must therefore report usage and 3113 request the quota to be replenished despite the fact that the 3114 threshold has not been reached. In this example, it decides to do so 3115 100 seconds before the 6000 seconds are reached. To this end, it 3116 constructs an Authorization Access Request message including a PPAQ 3117 that indicates that 14 MB have been consumed up to now. It also 3118 includes a PTS attribute in order to indicate, using the VUATS 3119 SubType, that 11 MB of these were consumed after the tariff switch. 3120 The message is sent to the the PPS (5). 3122 The PPS can link the message to previous session state via the QID. 3123 It now rates the consumed volume as follows. The 11 MB that were 3124 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 3125 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 3126 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 3127 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 3129 The PPS now determines that message (5) was sent in order to 3130 replenish the quota for this prepaid session. This can be deduced 3131 from the UPDATE REASON field, which indicates that the PPC sent this 3132 message because the time indicated by the TITSU SubType is 3133 approacing. The PPS now determines that enough credit remains in the 3134 user's prepaid account in order for the access service to continue 3135 being provided and decides to reserve another 8.9 euros from the 3136 user's account. Since it is conceivable that the user will consume 3137 the 6 unused MB of quota from the previous allocation, as well as the 3138 entire quota that is to be allocated now, entirely in the "0.8-euro" 3139 period, the quota that should now be granted in addition to the 3140 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 3141 are being reserved in order to "cover the worst case scenario". The 3142 fact that 0.9 euros are reserved for this purpose is due to the fact 3143 that the unused 6 MB from the previous allocation correspond to 4.8 3144 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 3145 than the amount of funds that are still "reserved" from the previous 3146 allocation. (After this reservation, the total amount of reserved 3147 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 3148 being consumed in the "0.8-euro" period.) 3149 Since quotas are encoded in a cumulative way in RADIUS, the PPS 3150 includes a VolumeQuota of 30 MB into the Access Accept message (6). 3151 The PPS further calculates the new threshold value of 28 MB. Since 3152 this is a new quota reservation, the PPS also allocates a new QID to 3153 it, in this example QID=8. The resulting RADIUS message is sent to 3154 the PPC (6). 3156 Upon reception of message (6), the PPC updates its records and 3157 continues providing access to the user. At some point the user logs 3158 off (7). The PPC must then report how many resources were consumed, 3159 so that the PPC can subtract the appropriate monetary amount from the 3160 user's prepaid account. To this end the PPC constructs an Authorize- 3161 Only Access Request message with a PPAQ attributes for the access 3162 service. In this example, 17 MB were consumed by the access service 3163 in total. The PPC reports 17 MB its final message (8). The PPS 3164 correlates the report, using the QID, to the previous session state. 3165 It determines, from the previous records, that the access service had 3166 consumed 14 MB before (as indicated in message (5)). This means 3167 that, of the 17 MB, only the monetary equivalent for 3 MB have not 3168 yet been subtracted from the user's account. The PPS calculates how 3169 much should be deducted from the user's account as follows. Since 3170 the VUATS SubType indicates that 2.5MB were consumed after the tariff 3171 switch, only 0.5 MB were consumed before that. Thus, the monetary 3172 equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. That is, the PPS 3173 subtracts 3.6 euros from the user's prepaid account. Since the 3174 session has by now be terminated by the PPC (REASON=ACCESS SERVICE 3175 TERMINATED), the PPS now releases any reserved monetary amount, in 3176 this example 12.8 - 3.6 = 9.2 euros. 3178 The PPS responds with an Access Response as required by the RADIUS 3179 base specification (9). 3181 Remark: In this example, two tariff switches take place. In other 3182 scenarios, of course, only one tariff switch may occur. In such 3183 scenarios the TITSU SubType is not used. 3185 A.3. Resource pools and Rating Groups 3187 End user PPC PPS 3189 user logs on 3190 ------(1)---------> 3192 Access Request 3193 {RADIUS BASE AVPS, 3194 PPAC=00...00101111} 3195 -------(2)--------> 3197 [allocates 3198 5MB quota] 3200 Access Accept 3201 {RADIUS BASE AVPS, 3202 PPAQ={QID=5, VQ = 5MB, 3203 poolID=1,mult=1}} 3204 <-------(3)-------- 3206 service provision/metering 3207 -------(4)---------> 3209 user requests service A 3210 -------(5)---------> 3212 Access Request 3213 {RADIUS BASE AVPS,PPAQ={ 3214 SID="A", RGROUP=1}} 3215 -------(6)--------> 3217 [allocates 50 min 3218 quota] 3220 Access Accept 3221 {RADIUS BASE AVPS, 3222 PPAQ={QID=7, DQ=3000sec 3223 poolID=1,RGROUP=1, SID="A" 3224 mult=1747.63}} 3225 <---------(7)--------------- 3227 user requests service B 3228 -------(8)--------> 3230 Pool 1 close to exhaustion 3232 Access Request 3233 {RADIUS BASE AVPS, 3234 PPAQ={QID=5, VQ=4MB, 3235 REASON=QUOTA REACHED, 3236 PoolID=1, mult=1} 3237 PPAQ={QID=7, DQ=3300sec 3238 REASON=QUOTA REACHED, 3239 PoolID=1, mult=1747.63, 3240 SID="A",RGROUP=1}} 3241 -------(9)---------> 3243 [allocates another 3244 3 MB to access service 3245 and 30 minutes to 3246 service "A"] 3248 Access Accept 3249 {RADIUS BASE AVPS, 3250 PPAQ={QID=8, VQ=8MB, 3251 PoolID=1, mult=1, RGROUP=1}, 3252 PPAQ={QID=9, DQ=4800sec 3253 PoolID=1, mult=1747.63, 3254 SID="A"}} 3255 \ <----------(10)-------------- 3257 user logs off 3258 ------(11)------- 3259 Access Request 3260 {RADIUS BASE AVPS, 3261 PPAQ={QID=8, VQ=6.5MB, 3262 REASON=ACCESS SERV TERMINATED, 3263 PoolID=1, mult=1} 3264 PPAQ={QID=9, DQ=5400sec 3265 REASON=ACCESS SERV TERMINATED, 3266 PoolID=1, mult=1747.63, 3267 SID="A",RGROUP=1}} 3268 -------(12)---------> 3270 [reimburses 3271 user account] 3273 AA Accept 3274 {RADIUS BASE AVPS 3275 <------(13)-------- 3277 Figure 19: Example message flow with resource pools and rating groups 3279 The user logs on (1). The PPC sends a RADIUS Access Request message 3280 to the PPS (2), and includes the prepaid-specific PPAC AVP, 3281 indicating that multiple services, rating groups and resource pools 3282 are supported. Note that, since this is not an "Authorize- Only" 3283 message, no PPAQ attribute with Update Reason="initial request" is 3284 included (see Section 3.7.1). The PPS then may authenticate the user 3285 and authorize the access service, as is usual in RADIUS. Note that 3286 the PPAC AVP is appended by the PPC in at least the last message that 3287 is sent to the PPS during this possibly multiple-round exchange. 3289 If authentication and authorization is successful (in this example 3290 this is assumed), the PPS identifies the user's prepaid account from 3291 the included base RADIUS AVPs, and determines the capabilities of the 3292 PPC from the PPAC attribute. Assuming that sufficient funds are 3293 available in the user's prepaid account, the PPS reserves some of 3294 these and rates the service. In this example, the PPS reserves 5 3295 Euros and determines that the access service is rated at 1 Euro per 3296 MB. In anticipation that the user requests more chargeable services 3297 throughout this prepaid session, and since this is supported by the 3298 PPC, the PPS further associates a resource pool with this 3299 reservation, in this example PoolID=1. The PPC also specifies the 3300 multiplier = 1 for the access service. Note that, since 5MB = 3301 5242880 octets, 1 unit in the resource pool corresponds to 5 / 3302 5242880 euros, which is about 0.000095367431640625 Eurocents. 3303 (However, the PPC does not need to know that.) Moreover, the PPS 3304 associates the QID=5 to this reservation. This identifier can be 3305 used to later uniquely identify the prepaid session, user, account, 3306 etc. The resulting Access Accept message is sent to PPC (3). 3308 Upon reception of message (3), the PPC provides the access service to 3309 the user and meters it accordingly (4). That is, for every octet 3310 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 3311 the resouce pool with PoolID=1. 3313 At some point in time, the user requests another chargeable service, 3314 namely service A (5). The PPC generates an Authorize-Only Access 3315 Request that contains the usual RADIUS attributes and the Service-ID 3316 identifying service A (6). The PPC has determined that service A is 3317 rated in an identical way as at least one more service. Thus, 3318 service A has been configured to belong to a rating group, in this 3319 example the group with Rating-Group-ID=1. This identifier is 3320 included is message (6). 3322 Upon reception of message (6), the PPS identifies the user and his 3323 account from the base RADIUS attributes, the fact that a prepaid 3324 session is ongoing, and determines that enough credit remains in the 3325 prepaid account in order for service A to be provided. The PPS also 3326 determines that service A is rated at 0.10 euros per minute. The PPS 3327 decides to reserve another 5 euros from the users account; this 3328 corresponds to 50 minutes or, as encoded in the DurationQuota 3329 SubType, 3000 seconds. As service A draws from the same prepaid 3330 account as the access service, the PPS associates this reservation 3331 with the same resource pool as the previous reservation (QID=5), 3332 namely the pool with PoolID=1. Note that, in order for the abstract 3333 units in the pool to be consistent, the multiplier has to be 1747.63. 3334 This is because each second corresponds to about 0.10 / 60 = 0.00167 3335 euros, which is about 1747.63 times the value of an abstract resource 3336 pool unit, as this was determined by the first allocation of quota to 3337 the pool (i.e., 0.000095367431640625 Eurocents). Since this is a new 3338 quota reservation, the PPS also allocates a new QID to it, in this 3339 example QID=7. The resulting RADIUS message is sent to the PPC (7). 3341 Upon reception of message (7), the PPC adjusts the units in resource 3342 pool 1. That is, it first determines how much quota had been 3343 allocated to service A in the past, and subtracts this from the quota 3344 reservation found in the message. Since this is the first quota 3345 reservation for service A, there is nothing to subtract. Thus, it 3346 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 3347 3000 seconds have been allocated to service A during this prepaid 3348 session. The PPC then provides service A to the user, and meters it 3349 against resource pool 1. That is, for every second it subtracts 3350 1747.63 units from the pool. 3352 At some point in time, the user requests service B (8). The PPC 3353 determines that service B is rated exactly in the same way as service 3354 A, i.e., that they belong to the same rating group, namely the one 3355 with Rating-Group-ID=1. Since this rating group has been effectively 3356 authorised by the allocation of quota with QID=7, the PPC provides 3357 service B to the user immediately. It is rated in the same way as 3358 service A, i.e., for every second provided, 1747.63 units are 3359 subtracted from credit pool 1. 3361 At some point in time, resource pool 1 is close to exhaustion. (For 3362 example, the PPC may determine that the pool is "close to exhaustion" 3363 when has less than 10% its initial amount of units.) At that point, 3364 the PPC needs to ask for replenishment for the pool. Suppose that, 3365 at that point in time, 4MB of "access service", 45 minutes of 3366 "service A", and 10 minutes of "service B" were provided to the user. 3367 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 3368 + 5767179 = 9961483 abstract service units from the pool. The PPC 3369 constructs an Authorize-Only Access Request message that reports the 3370 usage for the "access service" and "service A". This message 3371 contains two PPAQ attributeS, is sent to the PPS (9). Note that is 3372 the message it appears that "service A" has consumed more than it was 3373 allocated (i.e., 55 minutes although only 50 minutes were initially 3374 allocated to it). This is not a a problem since the PPS knows that 3375 "service A" was drawing from the same pool as the "access service" 3376 and that the "access service" did only consume 4 out of the 5 MB it 3377 was allocated. 3379 Upon reception of message (9), the PPS subtracts 4 euros from the 3380 user's account for the "access service" and another 5.5 euros for 3381 "service A". (This includes the charge incurred by "service B" up to 3382 that point in time, although the PPS is not aware of "service B" 3383 being provisioned to the user.) The PPS then determines that 3384 sufficient funds remain in the prepaid account in order for both 3385 services to be continued. The PPS decides to reserve another 3MB for 3386 the access service and 30 minutes for "service A". This corresponds 3387 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 3388 cumulative manner, the PPAQ attribute that grants the quota for the 3389 "access service" contains a Volume-Quota SubType of 8MB (8388608 3390 octets), which is the 5MB that were initially allocated, plus the 3MB 3391 allocated now. The resource pool identifier is, as previously, 3392 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 3393 quota for "service A" contains 4800 seconds (the initial 3000 plus 3394 1800 that correspond to the 30 additional minutes). Again, the 3395 PoolID=1 and multiplier=1747.63. The resulting Access Response 3396 message is sent to the PPC (10). 3398 When the PPC received message (10) it checks how much quota has been 3399 allocated previously to the "access service". It finds that the 3400 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 3401 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 3402 have not yet been added to resource pool 1. The PPC thus adds 3403 3145728 abstract units to resource pool 1 (since the multiplier is 3404 1). The PPC then acts similarly on the other PPAQ attribute that 3405 exists in message (11). That is, the PPC determines that 3000 3406 seconds of quota for "service A" had already been added to the pool. 3407 Thus only 1800 out of the 4800 should be additionally added to the 3408 pool. Since the applicable multiplier here is 1747.63, the PPC adds 3409 further 3145734 abstract units to the pool 1. 3411 The PPC then continues to provide the access service, "service A" and 3412 "service B" to the user, and meters them against the pool, as 3413 previously. 3415 At some point the user logs off (11). The PPC must then report how 3416 many resources were consumed, so that the PPC can subtract the 3417 appropriate monetary amount from the user's prepaid account. To this 3418 end the PPC constructs an Authorize-Only Access Request message with 3419 two PPAQ attributes; one for the access service and one for "service 3420 A". Suppose that, in total, 6.5MB were consumed by the access 3421 service, 70 minutes were consumed by "service A" and 20 minutes by 3422 "service B". The PPC reports 6.5MB (6815744 octets) and 90 minutes 3423 (5400 seconds) in its final message (12). The PPS determines, from 3424 the previous records, that the access service consumed another 2.5MB 3425 (since 4MB out of the 6.5MB were already reported in message (9), and 3426 that "service A" consumed further 600 seconds. This corresponds to 3427 2.5 + (600/60)*0.1 = 2.5+ 1=3.5 euros. Thus, the PPS only subtracts 3428 2.5 out of the 6 previously reserved euros from the user's prepaid 3429 account and responds with an Access Response as required by the 3430 RADIUS base specification (13). 3432 A.4. One-time charging 3433 End user PPC PPS 3435 user requests ring tone 3436 ------(1)---------> 3438 Access Request 3439 {RADIUS BASE AVPS, 3440 PPAQ={QID=321, SID=X, RQ=650, 3441 REASON=10 (ONE-TIME CHARGING}} 3442 -------(2)---------> 3444 [rates 650 abstract units 3445 deducts from user's account] 3447 Access Accept 3448 {RADIUS BASE AVPS} 3449 <----------(3)-------------- 3451 ring tone is delivered 3452 <------(4)------- 3454 Figure 20: Example message flow with one-time charging 3456 The user requests a chargeable ring tone (1). The PPC sends a RADIUS 3457 Access Request message to the PPS (2), and includes a PPAQ attribute 3458 with Update Reason="one-time charging" is included (see 3459 Section 3.8.6). The Service ID indicates to the PPS that the 3460 charging event is connected to a ring tone, so that the PPS can rate 3461 the event accordingly. The PPAQ also contains a unique Quota 3462 Identifier. 3464 The PPS then may authenticate the user as is usual in RADIUS. If 3465 authentication is successful (in this example this is assumed), the 3466 home AAA server forwards the PPC converts the 650 reported abstract 3467 units into monetary value, according to the service type, and debit 3468 the user's account accordingly. This happens, of course, only if 3469 sufficient funds are available in the user's prepaid account. The 3470 PPC then responds with an an Access Accept message (3). The PPS adds 3471 a "session timeout = 0 AVP" (see Section 3.8.6). 3473 A.5. Price enquiry 3474 End user PPC PPS 3476 user requests AoC 3477 ------(1)---------> 3479 Access Request 3480 {RADIUS BASE AVPS, 3481 PPAQ={SID=X, VQ=10MB, 3482 REQ_ACT=2(PRICE ENQUIRY}} 3483 -------(2)---------> 3485 [rates 10MB for requested 3486 service] 3488 Access Accept 3489 {RADIUS BASE AVPS, 3490 PPAQ={SID=X, VQ=10MB, 3491 COST INFORMATION= 0.6 euros 3492 per MB}} 3493 <----------(3)-------------- 3495 AoC is delivered 3496 <------(4)------- 3498 Figure 21: Example message flow with price enquiry (advice of charge) 3500 Please refer to Section 2.7.3 for an explanation of this message 3501 flow. 3503 A.6. Balance check 3504 End User PPC PPS 3506 Access Request 3507 {RADIUS BASE AVPS, 3508 PPAQ={SID=X, VQ=10MB, 3509 REQ_ACT=BALANCE CHECK}} 3510 -------(2)---------> 3512 [rates requested 3513 Service and checks 3514 remaining funds] 3516 Access Accept 3517 {RADIUS BASE AVPS, 3518 PPAQ={SID=X, VQ=10MB, 3519 BALANCE_CHECK_RESULT}} 3520 <----------(3)-------------- 3522 Figure 22: Example message flow with balance check 3524 Please refer to Section 2.7.4 for an explanation of this message 3525 flow. 3527 Appendix B. Translation between RADIUS Prepaid and Diameter Credit 3528 Control 3530 Note: This section is informative. 3532 In scenarios where the service metering device uses the "RADIUS 3533 prepaid" (RPP) protocol for accounting and prepaid charging while the 3534 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 3535 a translation agent that enables the interoperation of both systems, 3536 is desirable. This also applies vice versa, i.e., in scenarios where 3537 the AAA infrastructure uses RADIUS and the service metering device 3538 uses Diameter. 3540 The idea of such a translation agent would be to convert incoming RPP 3541 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 3542 would be, in principle, desirable for the translation agent to be 3543 stateless. That is, the agent should not be required to internally 3544 maintain information about each ongoing RADIUS or Diameter session. 3545 However, under the current specification of RPP and DCC, this appears 3546 to be impossible due to a number of reasons. These include the 3547 following. 3549 1. The transport mechanism for DCC is TCP, which requires per- 3550 session state to be maintained at both endpoints of the 3551 communication. Note, however, that, in principle, each DCC 3552 message could be sent over a dedicated TCP connection which is 3553 torn down as soon as the message is sent. This, however, is 3554 likely to be unacceptable in terms of efficiency. 3556 2. While RPP messages encode the cumulative amount of consumed/ 3557 requested resources, DCC messages carry the difference from the 3558 previous message. This means that the translation agent has to 3559 maintain the current amount of consumed/requested resources in 3560 order to be able to calculate the correct amount to be put into 3561 an outgoing message. 3563 The translator maps each incoming RPP (resp. DCC) message into an 3564 outgoing DCC (resp. RPP) message, and possibly establishes or updates 3565 local state that is associated with the session. The translated 3566 (i.e., outgoing) message is a function of the incoming message as 3567 well as existing state that is associated with the current session. 3569 Translation occurs on an attribute-by-attribute basis. Certain 3570 attributes are translated without consideration of local per-session 3571 state. Other attributes, namely those that are bound to a particular 3572 session, require such consideration. The translation agent has to 3573 identify the session (and possibly subsession) an incoming message 3574 belongs to in order to consult the appropriate local per-session 3575 state. 3577 Note that certain DCC attributes cannot be translated due to their 3578 semantics not being present in RPP, and vice versa. This results in 3579 the messages, in which these attributes occur, not being delivered to 3580 their intended destination. In such cases it is desirable to inform 3581 the originator about the failure and terminate the session. 3583 In each scenario (i.e., RPP client / DCC AAA infrastructure and DCC 3584 client / RPP AAA infrastructure), the translator operates in two 3585 directions, namely RPP to DCC and vice versa. In the following 3586 sections, the notation c->s means that the attribute in question may 3587 occur only in the direction from the client to the server. The 3588 notation s->c denotes the converse and the notation c<->s denotes 3589 that the attribute may occur in messages that are directed in either 3590 direction. 3592 B.1. Session Identification 3594 The translation agent has to keep per-session state in order to 3595 perform its task. A session may be identified based on the RPP 3596 identifier or the DCC session identifier. That is, the translation 3597 agent should always maintain a pair of (RPP, DCC) session identifiers 3598 and maintain the per-session state in association with that pair. 3599 This per-session state must be addressable by either of these two 3600 identifiers. Moreover, an RPP session identifier must uniquely 3601 correspond to a DCC identifier. (If this holds, the converse also 3602 holds.) Each subsession identifier within an RPP session must also 3603 uniquely correspond to a subsession identifier within its 3604 corresponding DCC session. (If this holds the converse also holds.) 3606 B.2. Translation between RADIUS Prepaid and Diameter Credit Control 3608 This section describes the translator in the "RPP client / DCC AAA 3609 infrastructure" case. In other words, in this section it is assumed 3610 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 3611 The translator is assumed to sit somewhere in the middle and to 3612 mediate between client and server. 3614 For each RPP AVP (i.e., AVPs that are specified in the present 3615 document), the transformation into a semantically equivalent DCC AVP 3616 (if such an AVP exists), along with what per-session state the 3617 translator has to create or consult, is described. For clarity of 3618 exposition, each RPP AVP is addressed in a separate subsection. 3619 Since in this scenario, the PPC is typically the initiator a session, 3620 the focus is on the RPP AVPs. 3622 B.2.1. PPAC (c<->s) 3624 A DCC client is assumed to always support Volume metering, Duration 3625 metering, Resource metering, Pools, Rating groups, and Tariff 3626 Switching. Thus, if a PPAQ that indicates any of the above is sent 3627 client->server, the translator does the following: It lets message go 3628 through but remembers what exactly the client supports. If the 3629 server later requests (servier -> client direction) an unsupported 3630 metering to be performed, send failure to server and cause the 3631 session to be terminated at the client. 3633 If a PPAC indicates support for multiple services (0x00000020), the 3634 translator maps this onto a DCC Multiple-Services- Indicator AVP. 3636 B.2.2. Service Termination Attribute (c->s) 3638 The Diameter base protocol assumes that the client always supports 3639 dynamic session termination. If this AVP is present, the translator 3640 does not need to do anything, i.e., there exists no DCC AVP that this 3641 AVP can be mapped to. If this AVP is absent, the message in which it 3642 appears should either be discarded and originator should be informed 3643 of a failure, or the message can be passed on (without this AVP being 3644 mapped onto a DCC AVP). However, in the latter case, the translator 3645 has to remember that the client does not support dynamic termination. 3646 Thus, the translatior has to initiate the normal session termination 3647 procedure with the client when (if) dynamic termination is later 3648 initiated by the server. 3650 B.2.3. Quota Identifier Attribute (c<->s) 3652 When quota is allocated for the first time by the DCC server, the 3653 translator has to create a QID AVP, as required by this 3654 specification. The translator later uses a QID AVP that is sent in 3655 the client-to-server direction in order to identify the corresponding 3656 DCC session. The QID has to be saved in the translator's per session 3657 state. 3659 B.2.4. Volume Quota Attribute (c<->s) 3661 If this AVP occurs in a message that is sent in the server-to-client 3662 direction, it is translated into a Granted-Service-Unit AVP with an 3663 embedded CC-Total-Octets AVP. 3665 If this AVP occurs in a message that is sent in the client-to-server 3666 direction, then it is translated into a Used-Service-Unit AVP with an 3667 embedded CC-Total-Octets AVP. Note that only the difference between 3668 current cumulative quota for the (sub)session and the quota in 3669 incoming messages is indicated in the translated DCC message. Local 3670 state is updated with cumulative consumed resources. 3672 Conversely, if the server grants quota using the DCC Granted-Service- 3673 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 3674 agent must translate this into a Volume Quota Attribute. Again, 3675 local state must be consulted so that the cumulative amount of octets 3676 is indicated in the Volume Quota attribute. 3678 B.2.5. Duration Quota Attribute (c<->s) 3680 If this AVP occurs in a message that is sent in the server-to-client 3681 direction, it is translated into a Granted-Service-Unit AVP with an 3682 embedded CC-Time AVP. 3684 If this AVP occurs in a message that is sent in the client-to-server 3685 direction, then it is translated into a Used-Service-Unit AVP with an 3686 embedded CC-Time AVP. Note that only the difference between current 3687 cumulative quota for the (sub)session and the quota in incoming 3688 messages is indicated in the translated DCC message. Local state is 3689 updated with cumulative consumed resources (i.e., time). 3691 Conversely, if the server grants quota using the DCC Granted-Service- 3692 Unit AVP with an embedded CC-Time AVP, then the translation agent 3693 must translate this into a Duration Quota attribute. Again, local 3694 state must be consulted so that the cumulative amount of seconds is 3695 indicated in the Duaration Quota attribute. 3697 B.2.6. Resource Quota Attribute (c<->s) 3699 If this AVP occurs in a message that is sent in the server-to-client 3700 direction, it is translated into a Granted-Service-Unit AVP with an 3701 embedded CC-Service-Specific-Units AVP. 3703 If this AVP occurs in a message that is sent in the client-to-server 3704 direction, then it is translated into a Used-Service-Unit AVP with an 3705 embedded CC-Service-Specific-Units AVP. Note that only the 3706 difference between current cumulative quota for the (sub)session and 3707 the quota in incoming messages is indicated in the translated DCC 3708 message. Local state is updated with cumulative consumed resources 3709 (i.e., resources). 3711 Conversely, if the server grants quota using the DCC Granted-Service- 3712 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 3713 translation agent must translate this into a Resource Quota 3714 attribute. Again, local state must be consulted so that the 3715 cumulative amount of resource units is indicated in the Resource 3716 Quota attribute. 3718 Note that the "resource" type is application dependent. This means 3719 that a DCC application unit corresponds to n RPP application units, 3720 where n may be any real number. If n is not 1, then the RPP/DCC 3721 translator must be aware of that and translate resource units 3722 accordingly. 3724 B.2.7. Value Digits Attribute (c<->s) 3726 The encoding of this AVP is similar in RPP and DCC, and the value it 3727 holds may have to be evaluated in conjunction with an acommpanying 3728 "Exponent" AVP. It should be kept in mind that, in RPP the 3729 cumulative amount of granted/consumed quota is typically encoded into 3730 an AVP of this type, while in DCC only the difference from a previous 3731 message. 3733 B.2.8. Exponent Attribute (c<->s) 3735 The encoding of this AVP is similar in RPP and DCC, and the value it 3736 holds may have to be evaluated in conjunction with an acommpanying 3737 "Value Digits" AVP. It should be kept in mind that, in RPP the 3738 cumulative amount of granted/consumed quota is typically encoded into 3739 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 3740 the difference from a previous message is encoded into such a pair. 3742 B.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 3744 In DCC the concept of "threshold" does not exist. Instead, the DCC 3745 client is assumed to ask for the replenishment of quota in good time. 3746 In RPP, on the other hand, the server may optionally include a 3747 threshold AVP, as an indication to the PPC about when to ask for 3748 quota replenishment. 3750 Thus, in this scenario, there is no need for the translator to ever 3751 include a threshold attribute into the messages that it sends to the 3752 PPC. If, however, there is a need for a threshold attribute to be 3753 present in order to avoid a possible service provision 3755 B.2.10. Update Reason Attribute (c->s) 3757 The DCC AVP that is semantically closer to the Update Reason AVP than 3758 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 3759 the message is which it appears is intended to indicate an "initial", 3760 an "intermediate" or a "final interrogation". Morever, in case of 3761 the session being terminated at the client, it indicates the reason 3762 for this termination. 3764 The following list lists the possible values of an "Update Reason" 3765 attribute, along with corresponding values for the CC-Request-Type 3766 AVP. 3768 o Pre-initialization: No action/value defined. 3770 o Initial Request: Typically an "intial interrogation" is triggered 3771 as a result of the reception of the message that contains this 3772 Update Reason AVP. Hence, CC-Request-Type AVP indicates 3773 "INITIAL_REQUEST". 3775 o Threshold Reached: The reception of the message containing this 3776 Update Reason AVP typically triggers an "intermediate 3777 interrogation". Hence, CC-Request-Type AVP indicates 3778 "UPDATE_REQUEST". 3780 o Quota Reached: The reception of the message containing this Update 3781 Reason AVP typically triggers an "intermediate interrogation". 3782 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 3784 o TITSU Approaching: The reception of the message containing this 3785 Update Reason AVP typically triggers an "intermediate 3786 interrogation". Hence, CC-Request-Type AVP indicates 3787 "UPDATE_REQUEST". 3789 o Remote Forced Disconnect: Reception of such an Update Reason 3790 indicates that the client has terminated the session. The 3791 corresponding value for the CC-Request-Type AVP is 3792 "TERMINATION_REQUEST". 3794 o Client Service Termination: Reception of such an Update Reason 3795 indicates that the client has terminated the session. The 3796 corresponding value for the CC-Request-Type AVP is 3797 "TERMINATION_REQUEST". 3799 o "Access Service" Terminated: Reception of such an Update Reason 3800 indicates that the client has terminated the session. The 3801 corresponding value for the CC-Request-Type AVP is 3802 "TERMINATION_REQUEST". 3804 o Service not established: Reception of such an Update Reason 3805 indicates that the client has terminated the session. The 3806 corresponding value for the CC-Request-Type AVP is 3807 "TERMINATION_REQUEST". 3809 o One-Time Charging: Such an Update Reason indicates that a one-time 3810 charging event is initiated by the client. The corresponding 3811 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 3812 "Requested-Action: AVP MUST also be included in the outgoing DCC 3813 message. Typically, this would be of the type "DIRECT_DEBITING", 3814 or "REFUND_ACCOUNT", depending on other AVPs present in the 3815 message. 3817 B.2.11. PrepaidServer Attribute (s<->c) 3819 The PPC typically never sets the value of a PrepaidServer attribute. 3820 Instead, it repeats those values that it receives from the AAA 3821 infrastructure, in this scenario from the translator. This attribute 3822 is therefore not used in a translation scenario. Nevertheless, the 3823 translator must make sure that messages about the same RPP session 3824 are forwarded to the same DCC server, throughout the whole session. 3825 This may be easy to guarantee since the transport of Diameter is TCP. 3827 B.2.12. Service-ID Attribute (s<->c) 3829 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 3830 Service-Context-Id and Service-Identifier AVPs. The translator must 3831 keep a static equivalence table of the RPP Service-ID and the 3832 corresponding DCC combination in order to correctly translate an RPP 3833 service identifier into DCC and back. 3835 B.2.13. Rating-Group-ID Attribute (s<->c) 3837 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 3838 "Rating-Group-ID". Depending on the configuration, this AVP may 3839 contain the same value on both the RPP and the DCC side of the 3840 communication. If, however, static rating groups are configured 3841 between the RCC client and the translator, and different rating 3842 groups between the DCC server and the translator, then the translator 3843 has to maintain a static translation table for the rating group 3844 identifier. In any case, the translation of a rating group AVP, is 3845 not a function of the translator's local per-session state. 3847 B.2.14. Termination-Action Attribute (s->c) 3849 The DCC equivalent of the "Termination-Action" AVP is called the 3850 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 3851 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 3852 "Termination-Action" AVP. The following list contains the possible 3853 "Final-Unit-Action" values along with their "Termination-Action" 3854 equivalent. 3856 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 3857 called "Terminate". 3859 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 3860 AVP, then a "Redirect-Server-Address" AVP must also appear in the 3861 same DCC message. The translator translates these two AVPs into a 3862 "Termination-Action" with value "Redirect/Filter" and an 3863 eqiovalent NAS-Filter-Rule attribute (specified in http:// 3864 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 3866 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 3867 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 3868 in the same DCC message. The translator translates these two AVPs 3869 into a "Termination-Action" with value "Redirect/Filter" and an 3870 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 3871 internet-drafts/draft-ietf-radext-ieee802-00.txt). 3873 o In the absence of a "Final-Unit-Action" AVP, the DCC server 3874 assumes that the DCC client will ask for replenishment of quota at 3875 some suitable time. In RPP, this is explicitly conveyed via a 3876 "Termination-Action" AVP with the value "Request More Quota". 3877 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 3878 in this scenario appends such an AVP into the outgoing RPP 3879 message. 3881 B.2.15. Pool-ID Attribute (s<->c) 3883 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 3884 Typically, no translation needs to be done to the "Pool-ID" 3885 attribute. 3887 B.2.16. Multiplier Attribute (s<->c) 3889 The multiplier attribute, which is a pair of "Value-Digits" and 3890 "Exponent" AVPs, typically needs no translation, since the value it 3891 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 3892 the rating of the service or rating group to which it refers, with 3893 respect to abstract units. As such, the same multiplier value would 3894 typically applyt be conveyed from a DCC server to an PPC, and vice 3895 versa. 3897 B.2.17. Requested-Action Attribute (c->s) 3899 The "Requested Action" AVP can be directly translated into its DCC 3900 equivalent, which carries the same name. 3902 1. Balance Check (PCC): CHECK_BALANCE (DCC) 3904 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 3906 B.2.18. Check-Balance-Result Attribute (s->c) 3908 This attribute carries only a binary value. Hence, its translation 3909 is straightforward. 3911 B.2.19. Cost-Information Attribute (s->c) 3913 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 3914 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 3915 exist in DCC, and carry identical semantics in the context of the 3916 "Cost-Information" AVP. Thus, the translation of this attribute is 3917 straightforward. 3919 B.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 3921 This attribute carries the amount of octets that were consumed after 3922 a tariff change. It always appears in a message with an accompanying 3923 PPAQ attribute in which the total amount of octets (i.e., those that 3924 were consumed both before and after the tariff switch) is reported. 3925 Thus, the translation agent can compute the amount of octets that 3926 were consumed before the tariff change. 3928 In DCC, the two amounts, i.e., the octets that were consumed before a 3929 tariff change and those that were consumed afterwards, are reported 3930 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 3931 have an embedded CC-Total-Octets AVP that indicates the appropriate 3932 amount of octets. Furthermore, the Used-Service-Unit AVP that 3933 carries the amount that was consumed before the tariff switch also 3934 carries an embedded Tariff-Change-Usage AVP with the value 3935 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 3936 that carries the amount that was consumed after the tariff switch 3937 also carries an embedded Tariff-Change-Usage AVP with the value 3938 UNIT_AFTER_TARIFF_CHANGE (1). 3940 Authors' Addresses 3942 Avi Lior 3943 Bridgewater Systems 3944 303 Terry Fox Drive 3945 Ottawa, Ontario Suite 100 3946 Canada 3948 Email: avi@bridgewatersystems.com 3950 Parviz Yegani 3951 Juniper 3953 Email: pyegani@juniper.net 3955 Kuntal Chowdhury 3956 Starent Networks 3957 30 International Place, 3rd Floor 3958 Tewksbury, MA 01876 3959 USA 3961 Email: kchowdhury@starentnetworks.com 3963 Hannes Tschofenig 3964 Nokia Siemens Networks 3965 Linnoitustie 6 3966 Espoo 02600 3967 Finland 3969 Phone: +358 (50) 4871445 3970 Email: Hannes.Tschofenig@gmx.net 3971 URI: http://www.tschofenig.priv.at 3973 Andreas Pashalidis 3974 K.U.Leuven, ESAT/SCD/COSIC 3975 Kasteelpark Arenberg 10, bus 2446 3976 Leuven-Heverlee B-3001 3977 Belgium 3979 Email: andreas.pashalidis@esat.kuleuven.be