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