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