idnits 2.17.00 (12 Aug 2021) /tmp/idnits55460/draft-lior-radius-prepaid-extensions-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3821. 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 Copyright Line does not match the current year -- 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 (November 1, 2008) is 4948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TS32240' is mentioned on line 253, but not defined -- Looks like a reference, but probably isn't: '3576' on line 1219 == Unused Reference: 'RFC3748' is defined on line 2655, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT A. Lior 3 Internet-Draft Bridgewater Systems 4 Intended status: Informational P. Yegani 5 Expires: May 5, 2009 Cisco 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Pashalidis 11 NEC 12 November 1, 2008 14 Prepaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 16 draft-lior-radius-prepaid-extensions-15.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 5, 2009. 43 Abstract 45 This document specifies an extension to the Remote Authentication 46 Dial-In User Service (RADIUS) protocol that enables service providers 47 to charge for prepaid services. The supported charging models 48 supported are volume-based, duration-based, and based on one-time 49 events. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 57 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 9 58 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 59 1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11 60 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14 61 2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14 62 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14 63 2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16 64 2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17 65 2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18 66 2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19 67 2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19 68 2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19 69 2.7.2. Resource Consumption Query . . . . . . . . . . . . . . 20 70 2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 20 71 2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 21 72 2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21 73 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22 75 3.2. Authentication and Authorization Operation . . . . . . . . 22 76 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 24 77 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 78 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 79 3.5.1. Unsolicited Session Termination Operation . . . . . . 26 80 3.5.2. Unsolicited Change of Authorization Operation . . . . 26 81 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 27 82 3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 83 3.8. Operation Considerations for Multiple Services . . . . . . 28 84 3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 85 3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 86 3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 87 3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29 88 3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30 89 3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 90 3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30 91 3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31 92 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 93 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32 94 4.2. Session Termination Capability Attribute . . . . . . . . . 33 95 4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 34 96 4.4. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 52 97 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 56 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 57 99 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 58 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 64 105 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 66 106 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 66 107 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 69 108 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 72 109 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 77 110 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 78 111 A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 79 112 Appendix B. Translation between RADIUS Prepaid and Diameter 113 Credit Control . . . . . . . . . . . . . . . . . . . 81 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 115 Intellectual Property and Copyright Statements . . . . . . . . . . 91 117 1. Introduction 119 This document specifies an extension to the RADIUS protocol that 120 enables service providers to perform accounting and charging in an 121 "online" fashion. In particular, they enable the service provider to 123 (a) ensure that subscriber's remaining funds suffice before the 124 service is delivered, and 126 (b) interrupt service provision when the funds are exhausted. 128 Note that these capabilities are typically used in scenarios where 129 the subscriber maintains a prepaid account with the service provider; 130 hence, this extension is called the "prepaid" extension for RADIUS. 131 The functionality described in this document is often referred as 132 "online charging" in comparison to "offline charging" support 133 provided by RFC 2866 [RFC2866]. 135 The extensions were designed with the following goals in mind: 137 o Make use of existing infrastructure as much as possible (including 138 enabling the interworking of RADIUS-based and Diameter-based 139 infrastructures), and thereby limit the amount of necessary 140 capital expenditures, 142 o provide the ability to rate service requests in an "online" 143 fashion, 145 o provide the ability to charge the user's account prior to service 146 provision, 148 o protect against revenue loss, i.e., to prevent an end user from 149 obtaining service when the available funds do not suffice, 151 o protect against fraud, and 153 o be deployable for a number of services independent of the access 154 network technology. 156 The architecture between the entities that execute the RADIUS 157 protocols, with the extensions defined in this document, assumes that 158 the rating of chargeable events does not occur in the element that 159 provides the service. Instead, the rating may be performed at a 160 dedicated server, termed the "prepaid-enabled AAA server" or simply 161 "prepaid server" (PPS). Alternatively, the actual rating may occur 162 in an entity related to this prepaid server. 164 Furthermore, this document assumes that a "quota server" is available 165 which, through co-ordination with the rating entity and an account 166 balance manager, is able to provide a quota indication for a 167 particular user when requested. This quota server may or may not 168 coexist in the prepaid server. 170 1.1. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 Prepaid Client (PPC): 178 The entity which triggers the RADIUS message exchange, including 179 the prepaid extensions defined in this document. The PPC provides 180 the service to the users, and executes the RADIUS client which, 181 for the purposes of this document, is termed the "PrePaid Client" 182 (PPC). When the prepaid service is used the PPC collects service 183 event information and reports it while the services is provided to 184 the user. This event information is sent to the PPS using the 185 extensions defined in this document. 187 Prepaid Server (PPS): 189 The entity that interacts with the PPC using the RADIUS prepaid 190 extensions defined in this document. 192 Rating Entity: 194 This entity converts the credit that is allocated by the PPS into 195 a "quota". This quota is then returned to the requesting PPC via 196 the PPS. The rating entity may also determine that during service 197 provision a tariff switch will occur. In this case the rating 198 entity will include details of when exactly tariff switch will 199 occur. 201 Quota: 203 A quota denotes the amount of granted units to be consumed without 204 performing another credit control interaction. 206 Home Network: 208 The network which contains the user profile and the user's prepaid 209 account. 211 Authorize-Only Access Request: 213 A RADIUS message of type "Access Request" (code field = 1) that 214 contains a "Service-Type" AVP (type = 6) with value "Authorize- 215 Only". 217 Offline Charging: 219 Offline charging is a process where charging information for 220 resource usage is collected concurrently with that resource usage. 221 The charging information is then passed through a chain of logical 222 charging functions. At the end of this process, Charging Data 223 Record (CDR) files are generated, which are then transferred to 224 the operator's billing domain for the purpose of subscriber 225 billing and/or inter-operator accounting (or additional functions, 226 e.g., statistics, at the operator's discretion). The billing 227 domain typically comprises post-processing systems, such as the 228 operator's billing system or billing mediation device. In 229 conclusion, offline charging is a mechanism where charging 230 information does not affect, in real-time, the service rendered. 231 [TS32240] 233 Online Charging: 235 Online charging is a process where charging information for 236 resource usage is collected concurrently with that resource usage 237 in the same fashion as in offline charging. However, 238 authorization for the network resource usage must be obtained 239 prior to the actual resource usage to occur. This authorization 240 is granted by the PPS upon request from the PPC. When receiving a 241 resource usage request, the PPS assembles the relevant charging 242 information and generates a charging event in real-time. The PPS 243 then returns an appropriate resource usage authorization. The 244 resource usage authorization may be limited in its scope (e.g., 245 volume of data or duration), therefore the authorization may have 246 to be renewed from time to time as long as the resource usage 247 persists. Note that the charging information utilized in online 248 charging is not necessarily identical to the charging information 249 employed in offline charging. In conclusion, online charging is a 250 mechanism where charging information can affect, in real-time, the 251 service rendered and therefore a direct interaction of the 252 charging mechanism with the control of resource usage is required. 253 [TS32240] 255 1.2. Overview 257 This section provides an overview of the prepaid charging models and 258 architectures, which are supported by the extensions described in 259 this document. 261 A number of models of how to charge customers for services in a 262 prepaid manner are supported: 264 o Volume-based charging (e.g., 2 Cents/KiloByte). 266 o Duration-based charging (e.g., 3 Cents/minute). 268 o Resource-based charging (e.g., 3 videos for 10 Euros) 270 o Event-based charging (e.g., 7 Cents/ring tone) . 272 This draft assumes that the user maintains a prepaid account with his 273 home network. This account may be used to fund multiple services, 274 some of which may use the extensions defined in this document, and 275 some may use other mechanisms. The interworking of these mechanisms 276 is outside the scope of this document. Similarly, the means by which 277 the subscriber obtains funds is also outside the scope of this 278 document. 280 1.2.1. Architectural Model 282 This section describes the architectural model of the protocol 283 extensions described in this document. Figure 1 describes the 284 involved entities. 286 The end user establishes a connection with one of possibly multiple 287 PPCs during service access. The selected PPC communicates with a 288 HAAA server (directly or indirectly via a broker network). 290 The interface between the HAAA and the PPS is implemented using the 291 RADIUS protocol together with the extensions described in this 292 document. However, in cases where the PPS does not implement the 293 RADIUS protocol, the implementation would have to map the 294 requirements defined in this document to a functionally equivalent 295 protocol. 297 The requesting PPC meters the consumption of the service according to 298 the instructions provided by the PPS. After service completion, or 299 on reception of a subsequent request for service, the PPS deducts the 300 corresponding amount of credit from the user account. When a user 301 terminates an on-going service, the PPC informs the PPS with a 302 suitable indication about the unused portion of the allocated quota. 303 The PPS then refunds the user account accordingly. Note that 304 multiple PPSs may be deployed for reasons of redundancy and load 305 sharing. The system may also employ multiple rating servers. 307 Service 308 Access Device Accounting 309 +----------+ +---------+ Protocol +------------+ 310 | End |<---->|+-------+|<------------>| Accounting | 311 | User | +->|| PCC || | Server | 312 | | | || ||<----+ | | 313 +----------+ | |+-------+| | +------------+ 314 | +---------+ | 315 +----------+ | | 316 | End |<--+ | 317 | User | | +----------+ 318 +----------+ +------->| | 319 Prepapid | PPS | 320 Protocol | | 321 +----------+ 323 Figure 1: Basic Prepaid Architecture 325 The PPS and the accounting server in this architecture MAY be 326 combined. The PPC must have the ability to meter the consumption of 327 a prepaid data session. This metering is typically based on time 328 (i.e., seconds) or volume (i.e., octets). 330 The device running the PPC may also have "Dynamic Session 331 Capabilities", such as the ability to terminate a data session or to 332 change the filters associated with a specific data session by 333 processing "Disconnect" messages and "Change of Authorization" 334 messages as per RFC 3576 [RFC3576]. 336 This document assumes that the PPS is used as the AAA server. There 337 are three types of AAA server, as follows. 339 The AAA server in the home network (HAAA) is responsible for 340 authentication of the subscriber. In addition, the HAAA communicates 341 with the PPS using the RADIUS protocol in order to authorize 342 subscribers. 344 This document assumes that the PPS communicates with the HAAA for the 345 purposes of authentication and authorisation. The PPS, in turn, 346 interfaces to entities which 348 o keep the subscriber's account balance (balance manager), 350 o rate access service requests in real-time (rating engine), and 352 o manage quota for a particular prepaid service (quota server). 354 The balance manager, the rating engine and the quota server belong to 355 the service provider's backend infrastructure and are outside the 356 scope of this specification. In particular, as far as this 357 specification is concerned, they are assumed to exist in the PPS. 359 Accounting messages are not needed to deliver a prepaid service. 360 However, accounting messages can be used to keep the PPS up-to-date 361 as to what is happening with the prepaid data session. 363 1.2.2. Motivation 365 Why not use existing RADIUS attributes to construct a protocol for 366 prepaid scenarios? This could lead to a solution where no code has 367 to be modified at existing devices. 369 It is indeed possible to construct a solution for prepaid scenarios 370 using existing RADIUS attributes. The RADIUS server would send an 371 Access-Accept message containing a Session-Timeout(27) and include a 372 Termination-Action(29) in the RADIUS-request. Upon receiving the 373 Access-Accept message, the NAS would meter the duration of the 374 session and upon termination of the session the NAS would generate an 375 Access-Request message again. The RADIUS server would then re- 376 authenticate the session and reply with an Access-Accept message 377 indicating the amount of additional time in a Session-Timeout(27). 378 Alternatively, it could respond with an Access-Reject message if 379 there were no more resources in the user account. 381 Moreover, if the user terminates the session prematurely, the NAS 382 could indicate this in the accounting stream so that unused funds can 383 be returned into the prepaid user account. 385 Unfortunately, the above "solution" has a number of drawbacks, 386 including the following. 388 o It only supports time-based charging. The solution presented in 389 this document supports multiple charging metrics. 391 o Using accounting messages to recoup unused time may be problematic 392 because RADIUS accounting messages are not delivered in real-time. 393 A RADIUS server may store-and-forward accounting messages in 394 batches. Thus, relying on accounting messages for the purposes of 395 prepaid may cause revenue leakage. The solution presented in this 396 document does not rely on Accounting packets at all. It uses 397 Access-Request messages, which are required to flow through any 398 network in real-time. 400 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 401 subscriber is served by a NAS that does not adhere to Session- 402 Timeout then that subscriber may use the service for an 403 undetermined period of time. 405 o Termination-Action(29) presents its own issues. Firstly, the 406 behaviour of Termination-Action(29) is not mandatory. Secondly, 407 according to RFC 2865 [RFC2865], Termination-Action fires when the 408 provision of the service has completed. However, service should 409 not be terminated when negotiating additional quota, because this 410 should happen in a manner transparent to the subscriber. Due to 411 the fact that Termination-Action occurs when the service is 412 completed, it is unclear whether or not user experience would be 413 affected if this attribute would be used in a prepaid scenario. 414 The RADIUS server might even allocate a new IP address to the 415 subscriber device after a Termination-Action. Also, the RADIUS 416 server has no way of telling why a given Access-Request message 417 was generated. The RADIUS server might have to wait for the 418 corresponding accounting packet to determine the reason. Finally, 419 re-authenticating the subscriber may take too long. The solution 420 presented in this document allows quota replenishing to occur 421 without affecting user experience. No re-authentication is 422 required and quotas can be negotiated before the available credit 423 actually runs out. 425 o Due to the fact that the standard RADIUS attributes are not 426 mandatory, the correct prepaid operation is really an act of faith 427 on the part of the RADIUS server. If Session-Timeout(27) and/or 428 Termination-Action(29) are not supported, the prepaid subscriber 429 might be able to obtain the service for free. The solution 430 described in this document requires that a PPC informs the RADIUS 431 server, regardless of whether or not the latter supports the 432 prepaid extensions. The RADIUS server can then determine whether 433 or not service should be granted. For example, if a prepaid 434 subscriber is connected to a NAS that does not support prepaid, 435 the RADIUS server can either instruct the NAS to tunnel the 436 traffic to another entity in the home network (e.g., an Home 437 Agent) that supports prepaid, or cause it to provide only a 438 restricted service. 440 The solution presented in this document requires the support of two 441 mandatory and one optional attribute. Furthermore, it does not 442 require a great amount of additional code at a NAS (or similar 443 device) that already supports time or volume-based metering. The 444 solution requires that RADIUS entities advertise their prepaid 445 capabilities in an Access-Request and that they generate an Access- 446 Request packet with Service-Type="Authorize-Only" in order to obtain 447 more quota when or before the current quota is used up. It also 448 requires the NAS to send an Access-Request with Service- 449 Type="Authorize-Only" when the session terminates in order to refund 450 the subscriber account. 452 1.3. Assumptions 454 This document makes the following assumptions. 456 o The values carried in the Service Identifiers are pre-configured 457 between the PPC and the PPS. 459 o The decision about the service rating happens at the PPS. 461 o The decision whether credit control requests for two services are 462 placed in a resource pool are made by the PPS. 464 o The decision which services belong to the same rating group are 465 pre-configured at the PPC. Once a rating group is authorized it 466 is not necessary to re-authorize an additional service that 467 belongs to the same rating group at the PPS again. 469 o A price enquiry is done purely for the purpose of providing AoC 470 for the end user, not for processing at the PPC nor to trigger any 471 specific actions. 473 1.4. Example Use Case 475 This section describes the sequence of events in an example RADIUS 476 prepaid transaction. 478 1. When an end host attaches to a network (for example, using IEEE 479 802.1X), as usual, the PPC that is servicing the subscriber uses 480 the AAA infrastructure in order to authenticate and authorize the 481 subscriber with respect to the requested service. In order to do 482 this, it sends a RADIUS Access-Request to the AAA server. This 483 Access-Request contains the subscriber's credentials and may 484 contain the prepaid capabilities of the PPC. 486 2. The authentication procedure proceeds. This may involve several 487 message exchanges, as it is the case with the Extensible 488 Authentication Protocol (EAP) [RFC2284]. Once the subscriber has 489 been successfully authenticated, the home AAA server determines 490 that the subscriber is a prepaid subscriber and requests 491 authorisation from the PPS. This request MUST include the 492 prepaid capabilities of the serving PPC. 494 3. The PPS, possibly with the help of the backend infrastructure, 495 validates that the subscriber has a prepaid account and that the 496 account is active. It further validates that the PPC has the 497 appropriate prepaid capabilities. If all is in order, the PPS 498 authorises the subscriber to use the network. Otherwise it 499 rejects the request. The decision is sent to the AAA system in 500 the form of a response message. In the case of success, this 501 message contains attributes that indicate the allocation of a 502 portion of the subscriber credit. This portion is called the 503 "initial quota" and is expressed in units of time or volume. The 504 response may also include a threshold value. Note that only a 505 portion of the user's funds is allocated because the user may be 506 engaged in other services that may draw on the same account. For 507 example, the user may be engaged in a data session and a voice 508 session. Although these two services would draw from the same 509 account, they form separate parts of the overall system. If the 510 entire quota was allocated to the data session then the user 511 would have no more funds for a voice session. 513 4. The AAA system incorporates the attributes received from the PPS 514 into an Access-Accept message that it sends to the PPC. Note 515 that the AAA system is responsible for authorizing the service 516 whereas the prepaid system is responsible for prepaid 517 authorization. 519 5. Upon receiving the Access-Response, the PPC starts the prepaid 520 data session and meters the session based on time or volume, as 521 indicated in the message. 523 6. Once the consumption approaches the allocated limit (as expressed 524 by the threshold), the PPC will request additional quota. Re- 525 authorization for additional quota flows through the AAA system 526 to the PPS. The PPS revalidates the subscriber account and 527 subtracts the previously allocated quota from the current 528 balance. If there is remaining balance, it reauthorizes the 529 request with an additional quota allotment. Otherwise, the PPS 530 rejects the request. Note that the replenishment of the quota is 531 a re-authorization procedure and does not require the subscriber 532 to authenticate himself again. 534 7. Upon receiving a re-allotment of the quota, the PPC continues to 535 provide the requested service until the new threshold is reached. 536 If the request for additional quota cannot be fulfilled then the 537 PPC lets the subscriber use the remaining quota and terminates 538 the session. Alternatively, instead of terminating the session, 539 the PPC may restrict service access in such a way that the 540 subscriber can only reach a particular web server. This web 541 server maybe used to allow the subscriber to replenish his 542 account. This restriction can also be used to allow new 543 subscribers to set up prepaid accounts in the first place. 545 8. Should the subscriber terminate the session before the quota is 546 exhausted, the remaining balance allotted to the session is 547 refunded into his account. 549 Note that the subscriber may have disconnected while the PPC is 550 waiting for the initial quota. The entire allocated quota will have 551 to be credited back to the subscribers account in this case. Also 552 note that the PPS maintains session state for the subscriber. This 553 state includes how much account balance was allocated during the last 554 quota enquiry and how much is left in the account. Therefore, it is 555 required that all messages about the session reach the same (and 556 correct) PPS. 558 For a simple message flow, along the lines of this use case, please 559 see Appendix A. 561 2. Supported Features 563 This section describes the features that are supported by the 564 extensions specified in this document. 566 2.1. Services and Quotas 568 Examples of services that the user may be using are browsing the web, 569 participating in a VoIP conversation, watching streaming video and 570 downloading a ring tone. Some operators may want to distinguish 571 between these services and to charge them at different rates and 572 meters them differently. Therefore, the prepaid solution needs to be 573 able to distinguish services, and allocate quota to the services 574 using different unit types (time, volume) and allow for those quotas 575 to be consumed at different rates. 577 +---------+ +---------+ +-------+ 578 | | 1 N | | 1 1 | | 579 | Session |<---------->| Service |<---------->| Quota | 580 | | | | | | 581 +---------+ +---------+ +-------+ 583 Figure 2: Multiple services within a single session 585 As shown in Figure 2, a session may be associated with multiple 586 services. Each service is identified by a service identifier 587 (Service-ID). The format of the Service-ID is not in the scope of 588 this document. It may, for example, be expressed as a 5-tuple {i.e., 589 source IP address, destination IP address, source port, destination 590 port, and protocol type}. Each service is associated with a quota 591 whereby a quota might be applicable to multiple services. An example 592 message flow that involves multiple services within a single session 593 is given in the Appendix A. 595 2.2. Resource Pools 597 When working with multiple services a new problem arises because one 598 service may consume its quota faster than another service. When the 599 user balance is close to exhaustion, a situation could arise where 600 one service is unable to obtain quota while another service has 601 plenty of quota remaining. Unless the quotas can be rebalanced, the 602 SAD would then have to terminate the former service. Moreover, it is 603 likely that each service generates a certain amount of RADIUS prepaid 604 traffic. In an environment with many users and charged services, 605 this amount of traffic may become a considerable overhead that could 606 lead to inefficiency. 608 One method to circumvent the above situation is to use a so-called 609 "resource pool". Resource pools enable the allocation of resources 610 to multiple services of a session by allocating resources to a pool 611 and have services draw their quota from the pool at a rate 612 appropriate to that service. When the quota that has been allocated 613 to the pool is close to exhaustion, the entire pool (rather than 614 individual services) is replenished. 616 +-----------+ 617 | Service-A |-----+ +--------+ 618 +-----------+ | Ma | | 619 +-------->| | 620 | Pool | 621 +-------->| (1) | 622 +-----------+ | Mb | | 623 | Service-B |-----+ +--------+ 624 +-----------+ 626 Figure 3: Resource pool example 628 As shown in Figure 3, Service-A and Service-B are bound to Pool(1). 629 Ma and Mb are the pool multipliers (that are associated with 630 Service-A and Service-B respectively) that determine the rate at 631 which Service-A and Service-B draw from the pool. 633 The pool is initialized by taking the quota allocated to service n 634 and multiplying it by Mn. Therefore, the amount of resources 635 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 636 Qn denotes the amount of quota that is allocated to service n. 637 Further, the pool is considered to be empty if 639 Poolr <= Ca*Ma + Cb*Mb + . . ., 641 Figure 4 643 where Ca and Cb are resources consumed by Service-A and Service-B 644 respectively. 646 Note that the resources assigned to the pool are not associated with 647 a metric. That is, Service-A can be rated at $1 per MB and Service-B 648 can rated at $0.10 per minute. In this case, if $5 worth of 649 resources are allocated for service-A to the pool and if Ma = 10, 650 then 50 units would be placed into the pool. If a further $5 are 651 allocated for service-B to the pool, then M=1 and 50 units are 652 deposited into the pool. The pool would then have a total sum of 100 653 units to be shared between the two services. The PPC would then 654 mater the services such that each Mbyte used by Service-A will draw 655 10 units from the pool and each minute used by Service-B will draw 1 656 unit from the pool. 658 2.3. Rating Groups 660 A Rating Group gathers a set of services, identified by a service 661 identifier, and subject to the same cost and rating type (e.g., $0.1/ 662 minute). 664 The rating of a service can be quite complex. While some operators 665 follow linear pricing models, others may wish to apply more complex 666 functions. For example, a service provider may wish to rate a 667 service such that the first N MBytes are free, then the next M Mbytes 668 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 669 per MB. Such a function could be implemented by repeated message 670 exchanges in the prepaid system. 672 To avert the need to exchange many messages while still supporting 673 such complex rating functions, the concept of the Rating Group was 674 introduced. 676 As shown in Figure 5, a Rating Group is associated with one or more 677 services and defines the rate that the services associated with the 678 Rating Group consume an allocated amount of quota. 680 +--------------+ +--------------+ 681 +-----------+ N 1 | | M 1 | Resource Pool| 682 | Service-A +---------->| Rating Group |------>| or | 683 +-----------+ | | | Quota | 684 +--------------+ +--------------+ 686 Figure 5: Rating Group 688 During the usage of a service that is associated with a Rating Group, 689 the PPC sends the ID of the Rating Group to the PPS. The PPS 690 authorises the Rating Group by allocating a quota to it and assign it 691 to a Resource Pool. When an additional service that belongs to an 692 already authorised Rating Group is instantiated, the PPC does not 693 need to re-authorize this service. This effectively means that the 694 PPC meters the service such that it draws from the already allocated 695 quota. Therefore, no RADIUS messages need to be exchanged in this 696 case. This limits the amount of traffic between the PPC and the PPS. 697 An example of a flow that uses Rating Groups is given in Appendix A.3 699 2.4. Tariff Switching 701 Tariff is the set of parameters defining the utilization charges for 702 the use of a particular service. 704 This mechanism is useful if, for example, as shown in Figure 6, 705 traffic before 18:00 is rated at rate r1 and traffic after 18:00 is 706 rated at rate r2. The mechanism requires the PPC to report usage 707 before and after the switch occured. 709 18:00 710 ------------------+----------------- 711 r1 | r2 712 ------------------+----------------- 713 ^ ^ 714 |<----TSI---> | 715 | | 716 Access-Accept Access-Request 717 (quota allocated) (quota consumed) 719 Figure 6: Example of Tariff Switching 721 The PPC indicates support for tariff switching by setting the 722 appropriate bit in the PPAC. If the PPS needs to signal a tariff 723 switch time it will send a PTS attribute that indicates the point in 724 time when the switch will occur. This indication represents the 725 number of seconds from current time (TariffSwitchInterval TSI). 727 At some point after the tariff switch the PPC sends another Access- 728 Request, as a result of either the user having logged off or the 729 volume threshold being reached. The PPC reports how much volume was 730 used in total (in a PPAQ attribute) and how much volume was used 731 after the tariff switch (in a PTS VUATS subtype attribute). 733 In situations with multiple tariff switches, the PPS has to specify 734 the length of the tariff switch period using the 735 TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS 736 attribute, as shown in Figure 7. 738 18:00 23:30 739 ------------------+---------------------+-------------- 740 r1 | r2 | r3 741 ------------------+---------------------+-------------- 742 ^ ^ ^ 743 |<----TSI---><-----------|-------->|TITSU 744 | | 745 Access-Accept Access-Request 747 Figure 7: Multiple Tariff Switches 749 When a TITSU is specified in the PTS, the PPC MUST generate an 750 Access-Request within the time after TSI and before TITSU expires. 751 Note that, typically, the PPC will be triggered by the Volume 752 Threshold. However, it is possible that, during period r2, resources 753 are not entirely consumed and, thus, the threshold is not reached. 754 The TITSU attribute ensures that, even in this case, the PPC will 755 generate the new Access-Request in good time. 757 For time based services, the quota is continuously consumed at the 758 regular rate of 60 seconds per minute. At the time when credit 759 resources are allocated, the server already knows how many units will 760 be consumed before the tariff time change and how many units will be 761 consumed afterward. Similarly, the server can determine the units 762 consumed at the before rate and the units consumed at the rate 763 afterward in the event that the end user closes the session before 764 the consumption of the allotted quota. There is no need for 765 additional traffic between the PPC and the PPS in the case of tariff 766 time changes for continuous time based service. Therefore, the 767 tariff change mechanism is not used for such services. For time- 768 based services in which the quota is not continuously consumed at a 769 regular rate, the tariff change mechanism described for volume and 770 event units may be used. 772 2.5. Support for Roaming 774 In certain networks it is essential for prepaid data services to be 775 available to roaming subscribers. Support for both static and 776 dynamic roaming models is needed. In a static roaming scenario the 777 subscriber connects to a foreign network which has a roaming 778 agreement either directly with the home network, or through a broker 779 network. When the subscriber logs into another foreign network, a 780 new login procedure has to be executed. 782 In a dynamic roaming scenario the subscriber may move between 783 networks while maintaining his connection. In such a scenario the 784 data session is seamlessly handed off between the networks. 786 In both roaming scenarios, the subscriber always authenticates 787 himself to the home network. Authorization for the prepaid session 788 and quota replenishing occurs at the home network and more 789 specifically at the PPS where state is being maintained. 791 Roaming is challenging because a subscriber who established a prepaid 792 data session may move to another PPC that does not support the 793 prepaid extensions. 795 2.6. Dynamic Termination 797 When fraud or an error is detected, either only the affected session, 798 or all sessions of the affected subscriber should be immediately 799 terminated. Under certain conditions, the system may wish to 800 terminate the session in order to make sure that the user is not 801 charged for services it does not use. 803 Certain handoff procedures used in dynamic roaming scenarios require 804 that the system terminates the subscribers prepaid data session at a 805 PPC. This is the case, for example, when time-based prepaid is used 806 and the mobile subscriber performs a dormant handoff. 808 2.7. One Time Event 810 2.7.1. One-Time Charging 812 One-time charging is a mode of operation where the RADIUS prepaid 813 extensions are used for charging of a service that is provided 814 instansteneously. An example of such an event is the purchase of a 815 ring tone. Subscription based services can also be modeled as a one- 816 time event. In this case the one-time service event is the purchase 817 of a subscription. 819 For a given user, one-time charging may occur in parallel with other 820 charging models. For example, the subscriber may be connected to the 821 Internet, which is metered (based on time or volume), while he also 822 purchases a ring tone (a one-time-based event). 824 Note that it is up to the service providers to decide whether or not 825 the user will be charged for the download of, for example, the video 826 and also be charged for the data volume required to download the 827 video. The facilities provided by this document gives the service 828 provider the capability to achieve their service charging business 829 goals. 831 The PPC signals one-time charging to the PPS with an indication that 832 identifies the service and the units that should be debited from the 833 user account. 835 A PPC may decide to perform one-time charging and the PPC may need to 836 authenticate the user before sending the relevant message to the 837 user's home AAA server (and to the PPS). 839 Note that one-time charging can also be used to credit the prepaid 840 account. For example, the PPC can return resources to the subscriber 841 by issuing a one-time charging request that includes the amount of 842 resources to be credited into the account. 844 2.7.2. Resource Consumption Query 846 It should be possible for the PPS to query the PPC for the current 847 resource consumption and to adjust the users account balance. For 848 example, a request to the PPS is made (e.g., a one-time charging 849 event), the account is depleted and resources have been allocated to 850 the PPC. The PPS should have the ability to query the PPC and, if it 851 has the spare resources, to reassign the quotas to the PPC and to the 852 pending request. Note that the PPS does not know resource usage 853 until the PPC request for more resources. This can be a long time. 855 In the absence of this capability the PPS can minimize the effect of 856 this phenomenon by allocating small quotas, a practice that results 857 in more message exchanges. 859 2.7.3. Service Price Enquiry 861 The PPC may need to know the price of the service event. Services 862 offered by application service providers whose prices are not known 863 in the PPC might exist. The end user might also want to get an 864 estimation of the price of a service event before requesting it. 866 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 867 with the value set to "Price Enquiry" (2). The request includes 868 enough information to identify the service, namely a Service- 869 Identifier or a Rating-Group-Identifer. 871 The PPS calculates the cost of the requested service event, but it 872 does not perform any account balance check or credit reservation from 873 the account. 875 The estimated cost of the requested service event is returned to the 876 PPS with a PPAQ in the Cost-Information SubType. The PPC may 877 transfer the information to the end user as an advice of charge. 879 More information regarding the price enquiry functionality is 880 provided in Section 4.3.17 and in Section 4.3.19. 882 2.7.4. Balance Check 884 The PPC may only have to verify that the end user's account balance 885 covers the cost of a certain service without reserving any units from 886 the account at the time of the inquiry. This method does not 887 guarantee that credit would be left when the PPC requests the 888 debiting of the account with a separate request. 890 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 891 with the value set to "Balance Check" (1). The request includes 892 enough information to identify the service, namely a Service- 893 Identifier or a Rating-Group-Identifer. 895 The PPS makes the balance check, but it does not make any credit- 896 reservation from the account. 898 The result of balance check, namely "Success" (1) or "Failure" (2), 899 is returned to the PPC in the Check-Balance-Result SubType conveyed 900 in the PPAQ attribute from the PPS to the PPC. 902 More information regarding the balance check functionality is 903 provided in Section 4.3.17 and in Section 4.3.18. 905 2.7.5. Refund 907 Some services may refund service units to the end user's account; for 908 example, gaming services. 910 To initiate refunding the PPC includes the PPAQ attribute in an 911 Access-Request packet and the amount (as a negative value) to be 912 refunded is specified using the Resource Quota and Resource Quota 913 overflow subtypes. This functionality is similar to one-time 914 charging with the difference that refunding uses negative values 916 Information about the service need to be provided by the PPC to allow 917 service identification, namely the Service-ID field of the PPAQ 918 identifies the prepaid service. 920 Note that a monetary amount itself to be refunded is not provided but 921 rather abstract units. Based on prior out-of-band agreements between 922 the PPC and the PPS these abstract units are translated into a 923 monetary amount. 925 More information regarding the refund functionality is provided in 926 Section 3.8.6. 928 3. Operations 930 This section contains the normative text for the prepaid extension. 932 3.1. Capability Discovery 934 The PPC initiates the authentication and authorization procedure by 935 sending a RADIUS Access-Request to the HAAA. Since the PPC MUST 936 include a PPAC attribute in the RADIUS Access-Request. The PPAC 937 attribute indicates to the PPS which prepaid capabilities are 938 possessed by the PPC. These are required in order to complete the 939 prepaid authorization procedure.Moreover, if the PPC supports the 940 Disconnect-Message or the Change-of-Authorization capabilities, then 941 it SHOULD include the Session Termination attribute. 943 In certain deployments, there may be other ways to terminate a data 944 session, or change authorization of an active session. For example, 945 some PPCs provide a session termination service via Telnet or SNMP. 946 In these cases, the AAA server MAY add the Dynamic-Capabilities 947 message to the Access-Request. Upon receiving the Change-of- 948 Authorization message, the AAA server would then be responsible for 949 terminating the session using the means that are supported by the 950 device. 952 If the authentication procedure involves multiple message exchanges 953 (as it is the case with EAP), the PPC MUST include the PPAC attribute 954 in at least the last Access-Request of the authentication procedure. 956 3.2. Authentication and Authorization Operation 958 Once the Access-Request arrives at the HAAA, the HAAA authenticates 959 the subscriber. If this fails, the HAAA sends an Access-Reject 960 message to the client. If authentication succeeds, the HAAA 961 determines whether or not the subscriber is a prepaid subscriber. If 962 the subscriber is not a prepaid subscriber, then the HAAA responds as 963 usual with an Access-Accept or an Access-Reject message. If the 964 subscriber is a prepaid subscriber then the HAAA MAY forward the 965 Access-Request to the PPS for further authorization. 967 The Access-Request contains the PPAC attribute and the Dynamic- 968 Capabilities attribute if one was included. The User-Name(1) 969 attribute MAY be set to a value that identifies the subscriber. This 970 attribute is used by the PPS to locate his account. For added 971 security, the HAAA MAY also set the User-Password(2) attribute to the 972 password used between the HAAA and the PPS. 974 The PPS locates the subscriber account and authorizes him. During 975 this procedure, the PPS takes into consideration the PPCs 976 capabilities. Upon successful authorization, the PPS generates an 977 Access-Accept containing an PPAC attribute and an PPAQ attribute. 978 The PPAC attribute returned to the client indicates the type of 979 prepaid service to be provided for the session. The PPAQ attribute 980 includes the following information. 982 o The QID, which is set by the PPS to a unique value, is used to 983 correlate quota requests. 985 o Volume and/or Time quota, which is set to a value representing a 986 portion of the subscriber's credit. 988 o Time or Volume Threshold that indicates when the PPC should 989 request additional quota. This information is optional. 991 o The IP address of the serving PPS and one or more alternative 992 PPSs. This is used by the HAAA to route subsequent quota 993 replenishing messages to the appropriate PPS(s). 995 o A State attribute, as defined in RFC 2865 [RFC2865]. This is 996 necessary in order to satisfy the requirements of Section 5.44 of 997 RFC 2865 [RFC2865], which mandates that an Access-Request with 998 Service-Type="Authorize-Only" must contain a State attribute. 999 Since the PPC sends subsequent quota replenishment requests in the 1000 form of such "Authorize-Only" requests, a State attribute MUST be 1001 present in all Access-Accept messages that also carry a PPAQ 1002 attribute. 1004 Note: The Idle-Timeout(28) attribute can be used to trigger the 1005 premature termination of a prepaid service, for example as a result 1006 of inactivity. 1008 Depending on site policies, after failed authorization, the PPS may 1009 generate an Access-Reject in order to terminate the session 1010 immediately. Alternatively, the PPS may generate an Access-Accept 1011 blocking some or all of the traffic and/or redirect some or all of 1012 the traffic to a location to a fixed server. (This feature could be 1013 used, for example, to prompt the user to replenish their account.) 1014 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 1015 Filter-Rule (see [RFC4849]). A description of the redirect 1016 functionality is outside the scope of this document. The time period 1017 before the session is blocked/redirected is specified by the Session- 1018 Timeout(27) attribute. 1020 Upon receiving an Access-Accept from the PPS, the HAAA appends the 1021 usual service attributes and forward the packet to the PPC. The HAAA 1022 SHOULD NOT overwrite any attributes already set by the PPS. If the 1023 HAAA receives an Access-Reject message, it will simply forward the 1024 packet to its client. Depending on site policies, if the HAAA does 1025 not receive an Access-Accept or an Access-Reject message from the PPS 1026 it MAY do nothing or send an Access-Reject or an Access- Accept 1027 message back to the PPC. 1029 3.3. Session Start Operation 1031 The start of the session is indicated by the arrival of an 1032 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 1033 be routed to the PPS such that it can confirm the initial quota 1034 allocation. 1036 Note that the role of the PPS is not to record accounting messages 1037 and therefore it SHOULD NOT respond with an Accounting Response 1038 packet. If the PPS does not receive the Accounting-Request(start) 1039 message it will only know that the session has started upon the first 1040 reception of a quota replenishment operation. 1042 If the PPS does not receive indication directly (via Accounting- 1043 Request(start)) or indirectly, it SHOULD, after some configurable 1044 time, deduce that the session has not started. If the PPC supports 1045 termination capabilities, the PPS SHOULD send a Disconnect Message to 1046 the PPC as a measure to ensure that the session is indeed dead. 1048 3.4. Mid-Session Operation 1050 During the lifetime of a prepaid data session the PPC may request the 1051 replenishment of the quotas using an Authorize-Only Access-Request 1052 message. Once either the allocated quota has been exhausted or the 1053 threshold has been reached, the PPC MUST send an Access-Request with 1054 Service-Type(6) set to a value of "Authorize-Only" and the PPAQ 1055 attribute. 1057 The PPC MUST also include NAS identifiers, and Session Identifier 1058 attributes in the Authorize-Only Access-Request. The Session 1059 Identifier should be the same as the one used during the initial 1060 Access-Request. For example, if the User-Name(1) attribute was used 1061 in the Access-Request it has to be included in the Authorize-Only 1062 Access-Request as well, especially if the User-Name(1) attribute is 1063 used to route the Access-Request to the Home AAA server. 1065 The Authorize-Only Access-Request MUST NOT include a User Password 1066 and MUST NOT include a CHAP Password. In order to enable the 1067 receiver to authenticate the message, the PPC MUST include a Message- 1068 Authenticator(80). In order to satisfy the requirements of Section 1069 5.44 of RFC 2865 [RFC2865], the PPC MUST also include the State 1070 attribute. It is anticipated that the inclusion of the State 1071 attribute will enable the PPS to map the Authorize-Only Access 1072 Request to the authentication context that was established when the 1073 PPC authenticated itself at the beginning of the session. The PPC 1074 computes the value for the Message-Authenticator and the State 1075 attributes according to RFC 2869 [RFC2869] and RFC 2865 [RFC2865] 1076 respectively. 1078 When the HAAA receives an Authorize-Only Access-Request that contains 1079 a PPAQ, it validates the message using the Message-Authenticator(80), 1080 according to RFC 2869. If the HAAA receives an Authorize-Only 1081 Access-Request that contains a PPAQ and either no or an invalid 1082 Message-Authenticator(80) it SHALL silently discard the message. An 1083 Authorize Only Access-Request message that does not contain a PPAQ is 1084 either erroneous or belongs to another application (for example, a 1085 Change of Authorization message [RFC3576]). In this case the 1086 Authorize-Only Access-Request is either silently discarded or handled 1087 by another application. 1089 Once the Authorize-Only Access-Request message is validated, the HAAA 1090 SHALL forward the Authorize-Only Access-Request to the appropriate 1091 PPS. The HAAA MUST forward the Authorize-Only Access-Request to the 1092 PPS specified in the PPAQ. The HAAA MUST add a Message- 1093 Authenticator(80) to the message, according to RFC 2869. As with the 1094 Access-Request message, the HAAA MAY modify the User-Name(1) 1095 attribute such that it identifies the user to the PPS. 1097 When the PPS receives the Authorize-Only Access-Request containing a 1098 PPAQ attribute, it MUST validate the Message-Authenticator(80) as 1099 described in RFC 2869. If validation fails, the PPS MUST silently 1100 discard the message. If it receives an Authorize-Only Access-Request 1101 message that does not contain a PPAQ, it MUST silently discard the 1102 message. 1104 The PPS locates the prepaid session state and uses the QID contained 1105 within the PPAQ to detect replays. The PPS takes the most recently 1106 allocated quota and subtracts it from the user balance. If 1107 sufficient balance remains, the PPS authorizes the PPS and allocates 1108 additional quota. The PPS may also calculate a new threshold value. 1109 Upon successful re-authorization, the PPS generates an Access-Accept 1110 containing the PPAQ attribute. 1112 Depending on site policies, upon unsuccessful authorization, the PPS 1113 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1114 Ascend-Data-Filter attribute (if supported) and the Session- 1115 Timeout(27) attribute such that the subscriber can get access to a 1116 restricted set of locations for a short period of time. This feature 1117 could be used to enable users to replenish their accounts, create new 1118 accounts, or to access free content. 1120 Upon receiving an Access-Accept from the PPS, the HAAA forwards the 1121 message to its client. If the HAAA receives an Access-Reject 1122 message, it forwards the message. Depending on site policies, if the 1123 HAAA does not receive an Access-Accept or an Access-Reject message 1124 from the PPS it MAY do nothing or it MAY send an Access-Reject 1125 message back to its client. 1127 Upon receiving an Access-Accept, the PPC updates its quotas and 1128 threshold parameters with the values contained in the PPAQ attribute. 1129 Note that the PPS MAY update the PrePaidServer attribute(s) and these 1130 may have to be saved as well. If the Access-Accept message contains 1131 a Filter-Id(11), an Ascend-Data-Filter attribute, or Session 1132 Timeout(27), the PPC SHALL restrict the subscriber session 1133 accordingly. 1135 3.5. Dynamic Operations 1137 The PPS may take advantage of the dynamic capabilities that are 1138 supported by the PPC as advertised in the Session Termination and the 1139 PPAC attribute during the initial Access-Request. There are two 1140 types of actions that the PPS may perform. Firstly, it may request 1141 the session to be terminated. Secondly, it may request the 1142 attributes associated with the session to be modified. More 1143 specifically, it may modify a previously sent PPAQ. 1145 Both of these actions require that the session be uniquely identified 1146 at the PPC as described in [RFC3576]. 1148 3.5.1. Unsolicited Session Termination Operation 1150 At anytime during a session the PPS may send a Disconnect Message in 1151 order to terminate a session, see in [RFC3576]. Upon successful 1152 termination of a session the PPC MUST return any unused quota to the 1153 PPS by issuing an Authorize-Only Access-Request containing the PPAQ 1154 which contains any unused quota and the Update-Reason set to "Remote 1155 Forced Disconnection". 1157 3.5.2. Unsolicited Change of Authorization Operation 1159 At any time during the session the PPC may receive a Change of 1160 Authorization (CoA) message. A PPS may send a new quota to either 1161 add or to remove quota that is allocated to the service. If the 1162 Change of Authorization contains a PPAQ then that PPAQ overrides a 1163 previously received PPAQ. The PPS MUST NOT change the units used in 1164 the PPAQ. 1166 If the newly received PPAQ reduces the amount of allocated quota 1167 beyond what is already used then the PPC accepts the new PPAQ and act 1168 as it normally would when the quota is used up. For example, if the 1169 threshold is reached then is request a quota update. 1171 3.6. Termination Operation 1173 The termination phase is initiated when (i) the subscriber logs off, 1174 (ii) the subscriber balance is exhausted, or (iii) when the PPC 1175 receives a Disconnect Message. 1177 In case the user logged off, or the PPC receives a Disconnect 1178 Message, the PPC sends an Authorize-Only Access-Request message with 1179 a PPAQ and Update-Reason attribute set to either "Client Service 1180 Termination" or "Remote Forced Disconnect". This message indicates 1181 the amount of consumed quota. 1183 In case the currently allocated quota is exhausted, if the PPAQ 1184 contained the Termination-Action subytype, the PPC follows the 1185 specified action. 1187 3.7. Mobile IP Operations 1189 In roaming scenarios with Mobile-IP, the prepaid data session should 1190 be maintained transparently if the HA is acting as the access device 1191 hosting the PPC. As the subscriber device associates with a new 1192 access service device (AP or PDSN that supports PPC capability), this 1193 service access device sends a RADIUS Access-Request and the 1194 subscriber is re-authenticated and reauthorized. The service access 1195 device SHALL include the PPAC attribute in the RADIUS Access-Request. 1196 In this manner, the procedure follows the Authentication and 1197 Authorization procedure described earlier. 1199 If the HA was acting as the service access device before handoff, 1200 then the prepaid session does not undergo any change after the 1201 handoff because the Mobile IP session is anchored at the HA and the 1202 user's Home IP address does not change. 1204 In the case of a wireless access point or PDSN acting as the service 1205 access device, it is likely that the user's (care-of) IP address will 1206 change. The prepaid session will be affected by this. In this 1207 scenario the service access device shall send an Access-Request 1208 message which is routed to the home network and SHALL reach the PPS 1209 that is serving this session. The PPS correlates the new 1210 authorization request with the existing active session and assigns a 1211 quota to the new request. Any outstanding quota at the old service 1212 access device SHALL be returned to the PPS if the Mobile-IP nodes (HA 1213 and FA) support registration revocation (Mobile IPv4 only). 1214 Specifically, the quota SHOULD be returned when the service access 1215 device sends the Authorize-Only Access-Request with PPAQ Update- 1216 Reason set to either "Remote Forced Disconnect" or "Client Service 1217 Termination". In order to trigger the sending of this last 1218 Authorize-Only Access- Request, the PPS may issue a Disconnect 1219 Message [3576] to the service access device. 1221 Even if the subscriber moves to a service access device that does not 1222 have prepaid capabilities can the prepaid data service continue. 1223 This can be done by requesting the Home Agent (assuming it has such 1224 capabilities) to take over the responsibilities of the service access 1225 device (i.e. metering). This scenario will be discussed in detail in 1226 a later version of this document. 1228 3.8. Operation Considerations for Multiple Services 1230 This section describes the support for multiple prepaid services on a 1231 single PPC. Message flows illustrating the various interactions are 1232 presented in Appendix A. 1234 A PPC that supports prepaid operations for multi-services SHOULD set 1235 the "Multi-Services Supported" bit in the PPAC. When working with 1236 multi-services, we need to differentiate between the services. A 1237 Service-Id attribute is used in the PPAQ in order to uniquely 1238 differentiate between the services. The exact definition of the 1239 Service-Id attribute is outside the scope of this document. 1241 A PPAQ that contains a Service-Id is associated with that service. A 1242 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1243 Group. A PPAQ MUST NOT contain both a Rating-Group-Id and a 1244 Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a 1245 Service-Id then the default service is used, i.e., the "Access 1246 Service". 1248 3.8.1. Initial Quota Request 1250 When operations with multiple services is desired then the PPC 1251 requests the initial quota by sending a PPAQ containing the 1252 Service-Id in an Authorize-Only Access-Request packet for that 1253 service. Similarly, if the PPC supports rating groups then it may 1254 request a quota for the rating group by sending a PPAQ containing the 1255 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1256 Request". The Authorize-Only Access-Request message MAY contain more 1257 than one PPAQ. 1259 Upon receiving an Authorize-Only Access-Accept message containing one 1260 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1261 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1262 for that service or rating group. Additionally, the PPAQ MUST 1263 contain the Service-ID or Rating-Group-Id, unless the PPAQ is the 1264 generic "Access Service". 1266 3.8.2. Quota Update 1268 Once the services start to utilize their allotted quota they will 1269 eventually need to replenish their quotas (either the threshold is 1270 reached or no more quota remains). In order to replenish the quota, 1271 the PPC sends an Authorize-Only Access-Request message containing one 1272 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1273 Service-ID or Rating-Group-Id (or neither the Service-ID or Rating- 1274 Group-Id if the quota replenishment is for the "Access Service"). 1275 The Update-Reason filed indicates either "Threshold reached"(3), or 1276 "Quota reached"(4). 1278 Upon receiving an Authorize-Only Access-Request packet with one or 1279 more PPAQs the PPS responds with a new PPAQ for that service. The 1280 PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a 1281 new QID. If the PPS does not grant additional quota for the service 1282 it MUST include the Termination-Action subfield in the PPAQ that will 1283 instruct the PPC to take appropriate actions. 1285 3.8.3. Termination 1287 When the allotted quota for a service is exhausted, the PPC shall act 1288 in accordance with the flags set in the Termination-Action subtype. 1289 If the Termination-Action subtype is absent then the service MUST be 1290 terminated. If the service is to be terminated, then the PPC shall 1291 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1292 and the Update-Reason set to "Client Service Termination". 1294 If the "Access Service" has terminated, then all other services must 1295 be terminated as well. In this case the PPC MUST report on all 1296 issued quotas for the various services. The Update-Reason field 1297 should be set to "Access Service Terminated". 1299 3.8.4. Dynamic Operations 1301 Dynamic operations for multi-services are similar to dynamic 1302 operations described for single service operations. The PPS MAY send 1303 a COA message containing a PPAQ for an existing service instance. 1304 The PPC matches the PPAQ with the service using the Service-ID or the 1305 Rating-Group-Id attribute. The new quota could differ from the 1306 previously allocated value. 1308 A disconnect message terminates the "Access Service". As such the 1309 PPC MUST report all unused quotas by sending an Authorize-Only Access 1310 Request message containing a PPAQ for each active service. The 1311 Update-Reason MAY indicate that the reason for the update. 1313 3.8.5. Support for Resource Pools 1315 If the PPC supports pools as indicated by setting the "Pools 1316 supported" bit in the PPAC then the PPS may associate a quota with a 1317 Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ. 1318 When Resource Pools are used, the PPAQ MUST NOT use the threshold 1319 field. 1321 3.8.6. One-time Charging 1323 To initiate one-time charging the PPC includes the PPAQ attribute in 1324 an Access-Request packet. The Service-ID field of the PPAQ 1325 identifies the prepaid service. The amount to be charged is 1326 specified using the Resource Quota and Resource Quota overflow 1327 subtypes. If the value specified is negative then the resources are 1328 credited to the user account. This functionality corresponds to 1329 refunding. 1331 The QID subtype MUST be set to a unique value and is used by the PPS 1332 to detect duplicates. The Update Reason field MUST be set to One- 1333 Time Charging. Upon receiving a One-Time charge PPAQ, the RADIUS 1334 server authenticates the user and, if successful, passes the PPAQ to 1335 the PPS. The PPS locates the account and debits or credits it 1336 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1337 message if successful, or an Access-Reject message otherwise. 1339 In case of a successful operation the HAAA forwards the message to 1340 the PPC with an Access Accept message. Since this is a one-time 1341 charge the PPC MUST NOT allow the session to continue. Therefore, 1342 the RADIUS server SHOULD include in the Access-Accept a Session- 1343 Timeout set to 0. Upon receiving an Access-Accept response the PPC 1344 SHOULD generate an Accounting Stop message. 1346 A PPAQ used for One-Time charging MAY appear in an Authorize-Only 1347 Access Request. This is the case when the session already exists. 1348 The PPS responds with an Access-Accept to indicate that the user 1349 account has been debited or an Access-Reject otherwise. 1351 3.8.7. Error Handling 1353 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1354 PPAQ. 1356 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1357 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1359 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1360 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1362 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1363 Multiplier or a Pool-Multiplier without a Pool-Id it MUST ignore that 1364 PPAQ. 1366 3.8.8. Accounting Considerations 1368 Although typically generated, accounting messages are not required to 1369 deliver a prepaid data service. When generated, accounting messages 1370 are used for auditing purposes and for billing. Accounting messages 1371 associated with prepaid data sessions should include the PPAQ 1372 attribute. 1374 4. Attributes 1376 This section specifies the attributes that implement the RADIUS 1377 extensions for prepaid. 1379 4.1. PrePaid Accounting Capability (PPAC) Attribute 1381 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1382 Access-Request message by a PPC to describe its prepaid capabilities. 1384 0 1 2 3 1385 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 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | TYPE | LENGTH | VALUE ... 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 ... VALUE | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 The fields have the following meaning and encoding: 1394 Type: 1396 PPAC (35) 1398 Length: 1400 8 1402 VALUE : 1404 The content of the subsequent fields are encoded using 1405 the data type String. 1407 The AvailableInClient (AiC) SubType is encoding as follows: 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | SubType | LENGTH | AvailableInClient (AiC) ... 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | AvailableInClient (AiC) | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 The fields have the following meaning and encoding: 1419 SubType : Value (1) 1420 LENGTH : 6 1422 AvailableInClient (AiC): The bitmap is encoded as: 1424 Value | Description 1425 ------------ -+------------------------------------- 1426 0x00000001 | Volume metering supported 1427 0x00000010 | Duration metering supported 1428 0x00000100 | Resource metering supported 1429 0x00001000 | Pools supported 1430 0x00010000 | Rating groups supported 1431 0x00100000 | Multi-Services supported 1432 0x01000000 | Tariff Switch supported 1433 0x10000000 | Reserved 1435 Figure 8: PPAC Attribute 1437 4.2. Session Termination Capability Attribute 1439 The Session Termination Capability attribute is included in the 1440 RADIUS Access-Request message towards the RADIUS server to indicate 1441 whether or not the NAS supports Dynamic Authorization. 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | TYPE | LENGTH | String | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 The fields have the following meaning and encoding: 1451 Type: 1453 Session Termination Capability (36) 1455 Length: 1457 4 1459 String: 1461 This field is encoded as a bitmap. 1463 Value | Description 1464 ---------------+------------------------------------- 1465 0x00000001 | Dynamic Authorization Extensions (RFC 3576) 1466 | is supported. 1467 ... | All further values are reserved. 1469 Figure 9: Session Termination Capability Attribute 1471 4.3. Prepaid Accounting Operation (PPAQ) Attribute 1473 One or more PPAQ attributes are sent in an Access Request, Authorize- 1474 Only Access-Request and Access-Accept message. In an Access Request 1475 message, the PPAQ attribute is used to facilitate one-time charging 1476 transactions. In Authorize-Only Access-Request messages it is used 1477 for one-time charging, report usage and to request further quota. It 1478 is also used in order to request prepaid quota for a new service 1479 instance. In an Access-Accept message it is used in order to 1480 allocate the (initial and subsequent) quotas. 1482 When multiple services are supported, a PPAQ is associated with a 1483 specific service as indicated by the presence of a Service-Id, a 1484 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1485 of both, the Service-Id and the Rating-Group-Id). 1487 Note: Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes 1488 MUST appear in the PPAQ attribute, except for the price enquiry 1489 message exchange where these subtypes MUST be absent. A single PPAQ 1490 attribute MUST NOT contain more than one Service-Id, MUST NOT contain 1491 more than one Rating-Group-Id, and MUST NOT contain both a Service-Id 1492 and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or 1493 a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT 1494 contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST 1495 also contain a Pool-Multiplier SubType. 1497 The PPAQ attribute, as shown in Figure 10, has a variable length 1498 (greater than 8, encoded into one octet), and consists of a variable 1499 number of subtypes. Unused subtypes are omitted from the message. 1500 In the following subsections the various subtypes of the PPAQ 1501 attribute are specified. 1503 0 1 2 3 1504 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Type | Length | VALUE ... 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 ... VALUE | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 The fields have the following meaning and encoding: 1513 Type: 1515 PPAQ (37) 1517 Length: 1519 variable (dependent on the specific sub-type) 1521 VALUE: 1523 Data type String 1525 Each subattribute is then encoded in the following style: 1527 0 1 2 3 1528 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 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | SubType | LENGTH | VALUE ... 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 The fields have the following meaning and encoding: 1535 SubType : 1537 Contains an 8 bit unsigned integer. 1539 LENGTH : 1541 Contains an 8 bit unsigned integer. 1543 Figure 10: PPAQ Attribute Encoding Style 1545 4.3.1. Quota Identifier (QID) SubType 1547 The Quota Identifier (QID) is generated by the PPS and subsequently 1548 returned in a PPAQ->QID subtype from the PPC to the PPS. This field 1549 has the semantic of a transaction identifier and therefore changes 1550 with every transaction initiated by the PPS to the PPC. 1552 0 1 2 3 1553 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 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | SubType | LENGTH | VALUE ... 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | VALUE | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 The fields have the following meaning and encoding: 1562 SubType : Value(1) 1564 LENGTH : 6 1566 VALUE : Data type String 1568 Quota Identifier (QID) SubType 1570 4.3.2. VolumeQuota SubType 1572 TVolumeQuota SubType is only present when volume-based charging is 1573 used. In a RADIUS Access-Accept message (PPS to PPC direction), it 1574 indicates the volume (in octets) allocated for the session by the 1575 PPS. In a RADIUS Authorize-Only Access-Request message (PPC to PPS 1576 direction), it indicates the totally used volume (in octets) for both 1577 inbound and outbound traffic. The Exponent SubType, if present, MUST 1578 NOT encode a negative number or zero. 1580 0 1 2 3 1581 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 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | SubType | LENGTH | VALUE ... 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 The fields have the following meaning and encoding: 1588 SubType : Value(2) 1590 LENGTH : variable (8 or 14) 1592 VALUE : Data type String 1594 The content of the VALUE field either contains the 1595 Value-Digits SubType or the Value-Digits SubType plus the 1596 Exponent SubType. The length field indicates whether one or 1597 both subtypes are included. 1599 VolumeQuota SubType 1601 4.3.3. VolumeThreshold SubType 1603 The value of the type field of the VolumeThreshold SubType is TBD and 1604 its length is 10 or 14 octets. This SubType is optionally present if 1605 the VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1606 PPC direction). It is generated by the PPS and indicates the volume 1607 (in octets) that has to be consumed before a new quota is requested. 1608 This threshold MUST NOT be larger than the VolumeQuota. The Exponent 1609 SubType, if present, MUST NOT encode a negative number or zero. 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | SubType | LENGTH | VALUE ... 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 The fields have the following meaning and encoding: 1619 SubType : Value(3) 1621 LENGTH : variable (8 or 14) 1623 VALUE : Data type String 1625 The content of the VALUE field either contains the 1626 Value-Digits SubType or the Value-Digits SubType plus the 1627 Exponent SubType. The length field indicates whether one or 1628 both subtypes are included. 1630 VolumeThreshold SubType 1632 4.3.4. DurationQuota SubType 1634 The optional DurationQuota SubType is only present if duration-based 1635 charging is used. In a RADIUS Access-Accept message (PPS to PPC 1636 direction), it indicates the duration (in seconds) allocated for the 1637 session by the PPS. In a RADIUS Access-Request message (PPC to PPS 1638 direction), it indicates the total duration (in seconds) since the 1639 start of the accounting session related to the QID subtype of the 1640 PPAQ attribute in which it occurs. 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | SubType | LENGTH | VALUE ... 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | VALUE | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 The fields have the following meaning and encoding: 1652 SubType : Value(4) 1654 LENGTH : 6 1656 VALUE : Data type string. 1658 The content of this field contains a 32-bit unsigned integer 1659 (with the values 0 to +4,294,967,295). 1661 DurationQuota SubType 1663 4.3.5. DurationThreshold SubType 1665 The DurationThreshold SubType is optionally present if the 1666 DurationQuota is present in a RADIUS Access-Accept message (PPS to 1667 PPC direction). It represents the duration (in seconds) after which 1668 new quota should be requested. This threshold MUST NOT be larger 1669 than the DurationQuota SubType. 1671 0 1 2 3 1672 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 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | SubType | LENGTH | VALUE ... 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | VALUE | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 The fields have the following meaning and encoding: 1681 SubType : Value(5) 1683 LENGTH : 6 1685 VALUE : Data type string. 1687 The content of this field contains a 32-bit unsigned integer 1688 (with the values 0 to +4,294,967,295). 1690 DurationThreshold SubType 1692 4.3.6. ResourceQuota SubType 1694 The optional ResourceQuota SubType is only present if resource-based 1695 or one-time charging is used. In the RADIUS Access-Accept message 1696 (PPS to PPC direction) it indicates the resources allocated for the 1697 session by the PPS. In RADIUS Authorize-Only Access-Request message 1698 (PPC to PPS direction), it indicates the resources used in total, 1699 including both incoming and outgoing chargeable traffic. In one-time 1700 charging scenarios, the subtype represents the number of units to 1701 charge the user. The attribute consists of a Value-Digits SubType 1702 and optionally an Exponent SubType (as indicated by the length 1703 field). 1705 0 1 2 3 1706 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 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | SubType | LENGTH | VALUE ... 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 The fields have the following meaning and encoding: 1713 SubType : Value(6) 1715 LENGTH : variable (8 or 14) 1717 VALUE : Data type String 1719 The content of the VALUE field either contains the 1720 Value-Digits SubType or the Value-Digits SubType plus the 1721 Exponent SubType. The length field indicates whether one or 1722 both subtypes are included. 1724 ResourceQuota SubType 1726 4.3.7. ResourceThreshold SubType 1728 The semantic of the ResourceThreshold SubType follow those of the 1729 VolumeThreshold and DurationThreshold SubType. 1731 0 1 2 3 1732 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 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | SubType | LENGTH | VALUE ... 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 The fields have the following meaning and encoding: 1739 SubType : Value(7) 1741 LENGTH : variable (8 or 14) 1743 VALUE : Data type String 1745 The content of the VALUE field either contains the 1746 Value-Digits SubType or the Value-Digits SubType plus the 1747 Exponent SubType. The length field indicates whether one or 1748 both subtypes are included. 1750 ResourceThreshold SubType 1752 4.3.8. Value-Digits SubType 1754 The Value-Digits SubType encodes the most significant digits of a 1755 number, encoded as an integer. If decimal values are needed to 1756 present the number, the scaling MUST be indicated with a related 1757 Exponent SubType. 1759 For example, the decimal number 0.05 is encoded by a Value-Digits 1760 SubType set to 5, and a scaling that is indicated with the Exponent 1761 SubType set to -2. 1763 0 1 2 3 1764 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 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | SubType | LENGTH | VALUE ... 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | VALUE | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 The fields have the following meaning and encoding: 1773 SubType : Value(18) 1775 LENGTH : 6 1777 VALUE : Data type string. 1779 The content of this field contains a 32-bit unsigned integer 1780 (with the values 0 to +4,294,967,295). 1782 Value-Digits SubType 1784 4.3.9. Exponent SubType 1786 The Exponent SubType contains the exponent value that is to be 1787 applied to the accompanying Value-Digit SubType. 1789 0 1 2 3 1790 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 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | SubType | LENGTH | VALUE ... 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | VALUE | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 The fields have the following meaning and encoding: 1799 SubType : Value(19) 1801 LENGTH : 6 1803 VALUE : Data type string. 1805 The content of this field contains a 32-bit signed integer 1806 (with the values -2,147,483,648 to +2,147,483,647). 1808 Exponent SubType 1810 4.3.10. Update-Reason SubType 1812 The Update-Reason SubType is present in a RADIUS Access-Request 1813 message (PPC to PPS direction) and indicates the reason for 1814 initiating the quota update operation. Update reasons (6), (7), (8) 1815 and (9) indicate that the associated resources are released at the 1816 PPC side, and that therefore the PPS MUST NOT allocate a new quota in 1817 the RADIUS Access-Accept message. 1819 0 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | SubType | LENGTH | VALUE | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 The fields have the following meaning and encoding: 1827 SubType : Value(8) 1829 LENGTH : 4 1831 VALUE : Data type string 1833 This field contains a 16-bit unsigned integer 1834 (with the values 0 to +65,535). 1836 Update-Reason SubType 1838 The following values for the Update-Reason SubType are defined: 1840 Value | Description 1841 -------------+-------------------------------------- 1842 0 | Reserved 1843 1 | Pre-initialization 1844 2 | Initial Request 1845 3 | Threshold Reached 1846 4 | Quota Reached 1847 5 | TITSU Approaching 1848 6 | Remote Forced Disconnect 1849 7 | Client Service Termination 1850 8 | "Access Service" Terminated 1851 9 | Service not established 1852 10 | One-Time Charging 1853 11...65,535 | **Available for IANA registration** 1855 Figure 11: Values for Update-Reason SubType 1857 4.3.11. PrepaidServer SubType 1859 The optional PrepaidServer SubType indicates the address of the 1860 serving PPS. If present, the Home RADIUS server uses this address to 1861 route the message to the serving PPS. Multiple instances of this 1862 subtype MAY be present in a single PPAQ attribute. 1864 If present in the PrepaidServer SubType of an incoming RADIUS Access- 1865 Accept message, the PPC returns this SubType back without modifying 1866 it in the subsequent RADIUS Access-Request message. If multiple 1867 values are present, the PPC MUST NOT change their order. 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | SubType | LENGTH | Address ... 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 The fields have the following meaning and encoding: 1877 SubType : Value(9) 1879 LENGTH : variable (6 or 14) 1881 Address : Data type String 1883 For IPv4, the Address field is 4 octets based on the encoding of 1884 the NAS-IP-Address defined in RFC 2138. For IPv6, the Address 1885 field is 16 octets long. 1887 PrepaidServer SubType 1889 4.3.12. Service-ID SubType 1891 The Service-ID SubType is handled as an opaque string that uniquely 1892 describes the service instance for which prepaid metering should be 1893 applied. 1895 A Service-Id could be an IP 5-tuple (source address, source port, 1896 destination address, destination port, protocol). If a Service-ID 1897 SubType is present in the PPAQ, the entire PPAQ attribute refers to 1898 that service. If a PPAQ attribute does not contain a Service-Id or 1899 Rating-Group-ID, then the PPAQ attribute refers to the "Access 1900 Service". 1902 0 1 2 3 1903 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 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | SubType | LENGTH | Service ... 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 The fields have the following meaning and encoding: 1910 SubType : Value(10) 1912 LENGTH : variable 1914 Service : Data type String 1916 Service-ID SubType 1918 4.3.13. Rating-Group-ID SubType 1920 The Rating-Group-ID SubType indicates that this PPAQ attribute is 1921 associated with resources allocated to a Rating Group with the 1922 corresponding ID. This SubType is encoded as a string. A single 1923 PPAQ MUST NOT contain more than one Rating-Group-ID. 1925 0 1 2 3 1926 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 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | SubType | LENGTH | VALUE ... 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | VALUE | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 The fields have the following meaning and encoding: 1935 SubType : Value(11) 1937 LENGTH : 6 1939 VALUE : Data type string 1941 Rating-Group-ID SubType 1943 4.3.14. Termination-Action SubType 1945 The value of the type field of the Termination-Action SubType is TBD. 1946 The length of this SubType is 3 octets. This SubType contains an 1947 enumeration of the action to take when the PPS does not grant 1948 additional quota. Valid actions are as follows. 1950 0 1 2 1951 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | SubType | LENGTH | Action | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 The fields have the following meaning and encoding: 1958 SubType : Value(12) 1960 LENGTH : 3 1962 Action : Data type string. 1964 The content is an 8 bit unsigned integer (with the values 0 to +255). 1966 Termination-Action SubType 1968 The following values for the Termination-Action SubType are defined: 1970 Value | Description 1971 -------------+------------------------------------ 1972 0 | Reserved 1973 1 | Terminate 1974 2 | Request More Quota 1975 3 | Redirect/Filter 1976 4..255 | **Available for IANA registration** 1978 Figure 12: Values for the Termination-Action SubType 1980 4.3.15. Pool-ID SubType 1982 The Pool-ID SubType identifies the resource pool. It is encoded as a 1983 string. 1985 0 1 2 3 1986 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 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 | SubType | LENGTH | Poolid | 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 The fields have the following meaning and encoding: 1993 SubType : Value(13) 1995 LENGTH : 6 1997 Poolid : Data type string 1999 Pool-ID SubType 2001 4.3.16. Pool-Multiplier SubType 2003 The Pool-Multiplier SubType determines the weight of resources when 2004 they are inserted into the pool that is identified by the 2005 accompanying Pool-ID SubType, and the rate at which resources are 2006 taken out of the pool by the relevant Service or Rating-Group. 2008 0 1 2 3 2009 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 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | SubType | LENGTH | VALUE ... 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 The fields have the following meaning and encoding: 2016 SubType : Value(14) 2018 LENGTH : variable (8 or 14) 2020 VALUE : Data type String 2022 The content of the VALUE field either contains the 2023 Value-Digits SubType or the Value-Digits SubType plus the 2024 Exponent SubType. The length field indicates whether one or 2025 both subtypes are included. 2027 Pool-Multiplier SubType 2029 4.3.17. Requested-Action SubType 2031 The Requested-Action SubType is only be present in messages sent from 2032 the PPC to the PPS. It indicates that the PPC desires the PPS to 2033 perform the indicated action and to return the result. The PPAQ in 2034 which a Requested-Action SubType occurs MUST NOT contain a QID, and 2035 MUST contain a Service-Identifier or a Rating-Group-Identifer that 2036 allows the PPS to uniquely identify the service for which the 2037 indicated action is requested. 2039 0 1 2 2040 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | SubType | LENGTH | Action | 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 The fields have the following meaning and encoding: 2047 SubType : Value(15) 2049 LENGTH : 3 2051 Action : Data type string. 2053 The content is a 8 bit unsigned integer (with the values 0 to +255) 2054 with the values listed below. 2056 Requested-Action SubType 2058 The following values for the Action field of the Requested-Action 2059 SubType are defined: 2061 Value | Description 2062 -------------+------------------------------------- 2063 0 | Reserved 2064 1 | Balance Check 2065 2 | Price Enquiry 2066 3..255 | **Available for IANA registration** 2068 Figure 13: Values for the Requested-Action SubType 2070 4.3.18. Check-Balance-Result SubType 2072 The Check-Balance-Result SubType can only be present in messages sent 2073 from the PPS to the PPC. It indicates the balance check decision of 2074 the PPS about a previously received Balance Check Request (as 2075 indicated in a Requested-Action SubType). The PPAQ attribute in 2076 which a Check-Balance-Result occurs MUST NOT include a QID beause no 2077 quota is reserved by the PPS. 2079 0 1 2 2080 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | SubType | LENGTH | Decision | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 The fields have the following meaning and encoding: 2087 SubType : Value(16) 2089 LENGTH : 3 2091 Decision : Data type string. 2093 The content is a 8 bit unsigned integer (with the values 0 to +255) 2094 with the values listed below. 2096 Check-Balance-Result SubType 2098 The following values for the Decision field of the Check-Balance- 2099 Result SubType are defined: 2101 Value | Description 2102 -------------+------------------------------------------- 2103 0 | Success; Sufficient funds available 2104 | in the user's prepaid account 2105 1 | Failure; Insufficient funds available 2106 2..255 | **Available for IANA registration** 2108 Figure 14: Values for the Check-Balance-Result SubType 2110 4.3.19. Cost-Information SubType 2112 The Cost-Information SubType is used in order to return the cost 2113 information of a service, which the PPC can transfer transparently to 2114 the end user. This SubType is sent from the PPS to the PPC as a 2115 response to a "Price Enquiry", as indicated by the Requested-Action 2116 SubType. 2118 0 1 2 3 2119 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 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | SubType | LENGTH | VALUE ... 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 The fields have the following meaning and encoding: 2126 SubType : Value(17) 2128 LENGTH : variable 2130 VALUE : Data type String 2132 The content of the VALUE field contains (in this order) the 2133 Value-Digits SubType, followed by the 2134 Exponent SubType, Currency-Code SubType and the Cost-Unit SubType. 2136 Cost-Information SubType 2138 For example, the cost of 7.75 Malawi kwacha per hour would be encoded 2139 as follows. Value-Digits = 775, Exponent = -2, Currency Code = 454, 2140 and Cost-Unit = "hour". 2142 The PPAQ that carries a Cost-Information MUST NOT include a QID. 2144 4.3.20. Currency-Code SubType 2146 The Currency-Code SubType is used inside the Check-Balance-Result 2147 SubType and contains a currency code that specifies in which currency 2148 the values of AVPs containing monetary units were given. It is 2149 specified by using the numeric values defined in the ISO 3166-1 2150 standard. 2152 0 1 2 3 2153 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 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | SubType | LENGTH | Code | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 The fields have the following meaning and encoding: 2160 SubType : Value(20) 2162 LENGTH : 4 2164 Code : Data type string 2166 The content of the Code field is a 16-bit unsigned integer 2167 (with the values 0 to +65,535). 2169 Currency-Code SubType 2171 4.3.21. Cost-Unit SubType 2173 The Cost-Unit SubType is used inside the Check-Balance-Result SubType 2174 and contains a human readable UTF8 encoded string that can be 2175 displayed to the end user. It specifies the applicable unit to the 2176 Cost-Information when the service cost is a cost per unit (e.g., cost 2177 of the service is $1 per minute). The Cost-Unit can, for example, be 2178 minutes, hours, days, kilobytes, megabytes, etc. 2180 0 1 2 3 2181 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 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | SubType | LENGTH | VALUE ... 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 The fields have the following meaning and encoding: 2188 SubType : Value(22) 2190 LENGTH : variable 2192 VALUE : Data type String 2194 The content of the VALUE field contains a UTF8 encoded string. 2196 Cost-Unit SubType 2198 4.4. Prepaid Tariff Switching (PTS) Attribute 2200 This specification defines the PTS attribute, which allows to switch 2201 from one rate to another during service provision. Support for 2202 tariff switching is optional to implement and to use for the PPC and 2203 the PPS. PPCs use the flag "Tariff Switching supported" in the 2204 AvailableInClient field of the PPAC attribute in order to indicate 2205 support for tariff switching. PPSs employ the PTS attribute in order 2206 to announce their support for tariff switching. 2208 If a RADIUS message contains a PTS attribute, it MUST also contain at 2209 least one PPAQ attribute. If a RADIUS Access-Request message 2210 contains a PTS attribute or the "Tariff Switching supported" flag in 2211 the AvailableInClient field of the PPAC attribute, it MUST also 2212 contain an Event-Timestamp RADIUS attribute (see [RFC2869]). 2214 Every PTS attribute MUST include a QID SubType, as specified in 2215 Section 4.3.1. In a RADIUS Access-Request message sent from the PPC 2216 to the PPS, the QID SubType MUST contain the value of the Quota 2217 Identifier SubType that was previously received from the PPS and MUST 2218 be the same as the value carried in the QID SubType of one of the 2219 PPAQ attributes included the same RADIUS message. 2221 If multiple services are supported and if the PPAQ is associated with 2222 a service as indicated by the Service-ID SubType, then the PTS refers 2223 to the tariff switch for that service. If the PPAQ does not have a 2224 Service-ID, then the PTS refers to tariff switch for the "Access 2225 Service". 2227 A PPAQ attribute that is transported along with a PTS attribute and 2228 has the same value as the QID SubType contained in the PTS attribute 2229 in its own QID SubType is referred to as the "accompanying PPAQ 2230 attribute". If a PPS receives an Access-Request message from a PPC, 2231 it associates a unique value for the QID SubType to this request. 2233 The PTS attribute, as shown in Figure 15, contains a number of other 2234 subtypes which are specified in the following subsections. 2236 0 1 2 3 2237 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 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Type | Length | VALUE ... 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 ... VALUE | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 Type : PTS (38) 2246 Length: variable 2248 VALUE : Variable length content of data type String containing 2249 one or multiple SubTypes. 2251 Each SubType is then encoding in the following style: 2253 0 1 2 3 2254 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 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | SubType | LENGTH | VALUE ... 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 The fields have the following meaning and encoding: 2261 SubType: 2263 Contains an 8 bit unsigned integer. 2265 LENGTH: 2267 Contains an 8 bit unsigned integer. 2269 VALUE: 2271 Contains the content of the SubType. 2273 Figure 15: PTS Attribute 2275 4.4.1. VolumeUsedAfterTariffSwitch SubType 2277 The optional VolumeUsedAfterTariffSwitch (VUATS) SubType is used in 2278 the RADIUS Access-Request messages (PPC to PPS direction). It 2279 indicates the volume (in octets) used during a session after the last 2280 tariff switch for the service specified via the QID SubType and the 2281 accompanying PPAQ attribute. 2283 0 1 2 3 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | SubType | LENGTH | VALUE ... 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 The fields have the following meaning and encoding: 2291 SubType : Value(23) 2293 LENGTH : variable (8 or 14) 2295 VALUE : Data type String 2297 The content of the VALUE field either contains the 2298 Value-Digits SubType or the Value-Digits SubType plus the 2299 Exponent SubType. The length field indicates whether one or 2300 both subtypes are included. 2302 VolumeUsedAfterTariffSwitch SubType 2304 4.4.2. TariffSwitchInterval SubType 2306 The TariffSwitchInterval (TSI) SubType MUST be present in each PTS 2307 attribute that is part of a RADIUS Access-Accept message (PPS to PPC 2308 direction). It indicates the interval (in seconds) between the value 2309 of Event-Timestamp RADIUS attribute (see [RFC2869]) of the 2310 corresponding RADIUS Access-Request message and the next tariff 2311 switch condition. 2313 0 1 2 3 2314 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 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | SubType | LENGTH | VALUE ... 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | VALUE | 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 The fields have the following meaning and encoding: 2323 SubType : Value(24) 2325 LENGTH : 6 2327 VALUE : Data type string 2329 This field contains a 16-bit unsigned integer 2330 (with the values 0 to +65,535). 2332 TariffSwitchInterval SubType 2334 4.4.3. TimeIntervalafterTariffSwitchUpdate SubType 2336 The PPS MUST include TimeIntervalafterTariffSwitchUpdate (TITSU) 2337 SubType if there is another tariff switch period after the period 2338 that ends as indicated by the TSI SubType. The value of the TITSU 2339 SubType contains the number of seconds of the tariff period that 2340 begins immediately after the period that ends as indicated by the TSI 2341 attribute. If the TITSU SubType is not present, the PPC assumes that 2342 the tariff period, which ends as indicated by the TSI SubType, lasts 2343 until further notice. If TITSU is specified, the PPC MUST send a 2344 quota update before the point in time specified by the TITSU SubType 2345 (see Figure 7). 2347 0 1 2 3 2348 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 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | SubType | LENGTH | VALUE ... 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | VALUE | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 The fields have the following meaning and encoding: 2357 SubType : Value(25) 2359 LENGTH : 6 2361 VALUE : Data type string 2363 This field contains a 16-bit unsigned integer 2364 (with the values 0 to +65,535). 2366 TimeIntervalafterTariffSwitchUpdate SubType 2368 5. Diameter RADIUS Interoperability 2370 The RADIUS Prepaid extension described in this document may need to 2371 interoperate with the Diameter Credit Control Application. Two 2372 interoperability scenarios exist, as follows. Either the AAA server 2373 is Diameter based and the AAA client is RADIUS based, or the AAA 2374 client is Diameter based and the AAA server is RADIUS based. 2376 The Diameter Credit Control Application [RFC4006] describes how to 2377 implement a prepaid accounting system using a Diameter based 2378 infrastructure. 2380 A possible procedure for accomplishing the translation of the 2381 functionality defined in Diameter Credit Control and in the RADIUS 2382 Prepaid specification is described in Appendix B. 2384 6. Security Considerations 2386 This specification describes the use of RADIUS for purposes of real- 2387 time accounting. Threats and security issues for this application 2388 are described in [RFC3579] and [RFC3580]; security issues encountered 2389 in roaming are described in [RFC2607]. 2391 This document specifies new attributes that can be included in 2392 existing RADIUS packets, which are protected as described in 2393 [RFC3579] and [RFC3576]. See those documents for a more detailed 2394 description. 2396 The security mechanisms supported in RADIUS are focused on preventing 2397 an attacker from spoofing packets or modifying packets in transit. 2398 They do not prevent an authorized RADIUS/Diameter server or proxy 2399 from modifying, inserting, or removing attributes with malicious 2400 intent. When the attributes defined in this document are modified or 2401 removed by a RADIUS proxy they may lead to incorrect accounting 2402 records being delivered to users or wrong resource consumption being 2403 collected. 2405 The described mechanism add the mechanism of capability negotiation, 2406 so that a RADIUS server can automatically discover whether a NAS 2407 supports the real-time accounting features described in this document 2408 (and even more detailed capabilities can be learned by the RADIUS 2409 server). These mechanisms are being added to ensure that neither the 2410 NAS nor the RADIUS server make incorrect assumptions about the 2411 capabilities of the other party; potentially leading to incorrect 2412 accounting and improper access to the network or other services. 2414 7. Table of Attributes 2416 The following table provides a guide which attributes may be found in 2417 which RADIUS messages, and in what quantity. 2419 Request Accept Reject Challenge Accounting # Attribute 2420 Request 2421 0-1 0 0 0 0 35 PPAC 2422 0-1 0 0 0 0 36 Session Termination 2423 Capability 2424 0+ 0+ 0 0 0+ 37 PPAQ 2425 0+ 0+ 0 0 0+ 38 PTS 2427 8. IANA Considerations 2429 This document contains a number of instructions to IANA. 2431 8.1. RADIUS Attributes 2433 This document does not require IANA to register the following four 2434 RADIUS attributes as the code registered by the Wimax Forum is re- 2435 used. The Wimax Forum SMI Network Management Private Enterprise Code 2436 is 24757. 2438 Attribute Name | Attribute Type Value 2439 --------------------------------------+----------------------------- 2440 Prepaid-Accounting-Capability (PPAC) | 35 2441 Session Termination Capability | 36 2442 Prepaid-Accounting-Operation (PPAQ) | 37 2443 Prepaid Tariff Switching (PTS) | 38 2445 8.2. New Registry: PPAC SubTypes 2447 Section 4.1 defines the SubTypes used within the PPAC attribute. 2448 IANA is asked to create a registry for these SubTypes. Each registry 2449 entry consists of a 8 bit number together with a description of the 2450 PPAC SubType. This document creates the following PPAC SubTypes for 2451 this registry: 2453 Value | SubType Name 2454 ---------+----------------------------- 2455 0 | Reserved 2456 1 | AvailableInClient 2457 2..255 | **Available for IANA registration** 2459 The semantic of the above-listed SubType is described in Section 4.1. 2461 Following the policies outline in [RFC3575] the available SubTypes 2462 (i.e., value 0 and values 2-255) with a description of their semantic 2463 will be assigned after the expert review process. Updates can be 2464 provided based on expert approval only. Based on expert approval it 2465 is possible to mark entries as "deprecated". A designated expert 2466 will be appointed by the IESG. 2468 Each registration must include a number for the SubType and the 2469 semantic of the SubType. 2471 8.3. New Registry: PPAQ SubTypes 2473 Section 4.3 defines the SubTypes used within the PPAQ attribute. 2474 IANA is asked to create a registry for these SubTypes. Each registry 2475 entry consists of a 8 bit number together with a description of the 2476 PPAQ SubType. This document creates the following PPAQ SubTypes for 2477 this registry: 2479 Value | SubType Name 2480 ---------+----------------------------- 2481 0 | Reserved 2482 1 | Quota Identifier 2483 2 | VolumeQuota 2484 3 | VolumeThreshold 2485 4 | DurationQuota 2486 5 | DurationThreshold 2487 6 | ResourceQuota 2488 7 | ResourceThreshold 2489 8 | Update-Reason 2490 9 | PrepaidServer 2491 10 | Service-ID 2492 11 | Rating-Group-ID 2493 12 | Termination-Action 2494 13 | Pool-ID 2495 14 | Pool-Multiplier 2496 15 | Requested-Action 2497 16 | Check-Balance-Result 2498 17 | Cost-Information 2499 18 | Value-Digits 2500 19 | Exponent 2501 20 | CurrencyCode 2502 21 | Cost-Unit 2503 22..255 | **Available for IANA registration** 2505 The semantic of the above-listed SubTypes is described in 2506 Section 4.3. 2508 Following the policies outline in [RFC3575] the available SubTypes 2509 (i.e., value 0 and values 22-255) with a description of their 2510 semantic will be assigned after the expert review process. Updates 2511 can be provided based on expert approval only. Based on expert 2512 approval it is possible to mark entries as "deprecated". A 2513 designated expert will be appointed by the IESG. 2515 Each registration must include a number for the SubType and the 2516 semantic of the SubType. 2518 8.4. New Registry: PTS SubTypes 2520 Section 4.4 defines the SubTypes used within the PTS attribute. IANA 2521 is asked to create a registry for these SubTypes. Each registry 2522 entry consists of a 8 bit number together with a description of the 2523 PTS SubType. This document creates the following PTS SubTypes for 2524 this registry: 2526 Value | SubType Name 2527 ---------+----------------------------- 2528 0 | Reserved 2529 1 | Quota Identifier 2530 2 | VolumeUsedAfterTariffSwitch 2531 3 | TariffSwitchInterval 2532 4 | TimeIntervalafterTariffSwitchUpdate 2533 5..255 | **Available for IANA registration** 2535 The semantic of the above-listed SubTypes is described in 2536 Section 4.4. 2538 Following the policies outline in [RFC3575] the available SubTypes 2539 (i.e., value 0 and values 5-255) with a description of their semantic 2540 will be assigned after the expert review process. Updates can be 2541 provided based on expert approval only. Based on expert approval it 2542 is possible to mark entries as "deprecated". A designated expert 2543 will be appointed by the IESG. 2545 Each registration must include a number for the SubType and the 2546 semantic of the SubType. 2548 8.5. New Registry: Update-Reason 2550 Section 4.3.10 defines the Update-Reason SubType. IANA is asked to 2551 create a registry for the values contained in the Update-Reason 2552 SubType, as shown in Figure 11. Each registry entry consists of a 16 2553 bit number together with a description of the update reason. 2555 Following the policies outline in [RFC3575] the available values 2556 together with a description of their semantic will be assigned after 2557 the expert review process. Updates can be provided based on expert 2558 approval only. Based on expert approval it is possible to mark 2559 entries as "deprecated". A designated expert will be appointed by 2560 the IESG. 2562 8.6. New Registry: Termination-Action 2564 Section 4.3.14 defines the Termination-Action SubType. IANA is asked 2565 to create a registry for the values contained in the Termination- 2566 Action SubType, as shown in Figure 12. Each registry entry consists 2567 of a 8 bit number together with a description of the termination 2568 action. 2570 Following the policies outline in [RFC3575] the available values 2571 together with a description of their semantic will be assigned after 2572 the expert review process. Updates can be provided based on expert 2573 approval only. Based on expert approval it is possible to mark 2574 entries as "deprecated". A designated expert will be appointed by 2575 the IESG. 2577 8.7. New Registry: Requested-Action 2579 Section 4.3.17 defines the Requested-Action SubType. IANA is asked 2580 to create a registry for the values contained in the Requested-Action 2581 SubType, as shown in Figure 13. Each registry entry consists of a 8 2582 bit number together with a description of the requested reason. 2584 Following the policies outline in [RFC3575] the available values 2585 together with a description of their semantic will be assigned after 2586 the expert review process. Updates can be provided based on expert 2587 approval only. Based on expert approval it is possible to mark 2588 entries as "deprecated". A designated expert will be appointed by 2589 the IESG. 2591 8.8. New Registry: Check-Balance-Result 2593 Section 4.3.18 defines the Check-Balance-Result SubType. IANA is 2594 asked to create a registry for the values contained in the Check- 2595 Balance-Result SubType, as shown in Figure 14. Each registry entry 2596 consists of a 8 bit number together with a description of the 2597 requested reason. 2599 Following the policies outline in [RFC3575] the available values 2600 together with a description of their semantic will be assigned after 2601 the expert review process. Updates can be provided based on expert 2602 approval only. Based on expert approval it is possible to mark 2603 entries as "deprecated". A designated expert will be appointed by 2604 the IESG. 2606 9. Acknowledgements 2608 The authors would like to thank Christian Guenther, Bernard Aboba, 2609 and John Loughney for their feedback throughout the development of 2610 this document. Additionally, the authors would like to thank the 2611 members of the Wimax Forum and the members of 3GPP2 for their help 2612 with this specification. 2614 10. References 2616 10.1. Normative References 2618 [RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to 2619 Indicate Requirement Levels", March 1997. 2621 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2622 2865: Remote Authentication Dial In User Server (RADIUS)", 2623 June 2000. 2625 10.2. Informative References 2627 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2628 Authentication Protocol (EAP)", RFC 2284, March 1998. 2630 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 2631 Implementation in Roaming", RFC 2607, June 1999. 2633 [RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2635 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2636 Extensions", June 2000. 2638 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 2639 Authentication Dial In User Service)", RFC 3575, 2640 July 2003. 2642 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2643 Adoba, "RFC 3576: Dynamic Authorization Extensions to 2644 Remote Authentication Dial-In User Service (RADIUS)", 2645 February 2003. 2647 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2648 Dial In User Service) Support For Extensible 2649 Authentication Protocol (EAP)", RFC 3579, September 2003. 2651 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 2652 "IEEE 802.1X Remote Authentication Dial In User Service 2653 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 2655 [RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2656 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2657 June 2004. 2659 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2660 Loughney, "RFC 4006: Diameter Credit Control Application", 2661 August 2005. 2663 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 2664 Rule Attribute", RFC 4849, April 2007. 2666 Appendix A. Example flows 2668 Note: This section is informative. 2670 This section presents certain example flows that involve the RADIUS 2671 prepaid extensions. By no means is the intent of this section to 2672 specify or recommend business logic, rating strategies, and 2673 application-level behaviour. The intent of this section is purely to 2674 illustrate some fictive scenarios and the RADIUS prepaid message 2675 flows that could be associated with these scenarios. The contents of 2676 this section should be regarded as a collection of informative 2677 examples that aim to provide guidance to implementors. 2679 A.1. A simple flow 2681 End user PPC PPS 2683 user logs on 2684 ------(1)---------> 2685 Access Request 2686 {RADIUS BASE AVPS, 2687 PPAC=00...00011} 2688 -------(2)--------> 2690 [allocates 2691 5MB quota] 2693 Access Accept 2694 {RADIUS BASE AVPS, 2695 PPAQ={QID=5, VQ = 5MB, 2696 VTH = 4.5 MB}} 2697 <-------(3)-------- 2699 service provision/metering 2700 -------(4)---------> 2702 4.5 MB consumed 2704 Access Request 2705 {RADIUS BASE AVPS, 2706 PPAQ={QID=5, VQ=4.5MB, 2707 REASON=THRESHOLD REACHED}} 2708 -------(5)---------> 2710 [allocates another 7MB 2711 to the access service] 2713 Access Accept 2714 {RADIUS BASE AVPS, 2715 PPAQ={QID=8, VQ=12MB, 2716 VTH = 11.5 MB}} 2717 <----------(6)-------------- 2718 user logs off 2719 ------(7)------- 2720 Access Request 2721 {RADIUS BASE AVPS, 2722 PPAQ={QID=8, VQ=7 MB, 2723 REASON=ACCESS SERV TERMINATED}} 2724 -------(8)---------> 2726 [reimburses 2727 user account] 2729 AA Accept 2730 {RADIUS BASE AVPS} 2731 <-------(9)-------- 2733 Figure 16: A simple example message flow 2735 The user logs on (1). The PPC sends a RADIUS Access Request message 2736 to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP 2737 indicates that both duration-based and volume-based metering is 2738 supported. However, it also indicated that multiple services, rating 2739 groups and resource pools are not supported. Note that, since this 2740 is not an "Authorize-Only" message, no PPAQ attribute with Update 2741 Reason="initial request" is included (see Section 3.7.1). The PPS 2742 then authenticates the user and authorizes the access service, as is 2743 usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at 2744 least the last message that is sent to the home AAA server during 2745 this possibly multiple-round exchange. 2747 If authentication and authorization is successful (in this example 2748 this is assumed), then the PPS identifies the user's prepaid account 2749 from the included base RADIUS AVPs, and determines the capabilities 2750 of the PPC from the PPAC attribute. Assuming that sufficient funds 2751 are available in the user's prepaid account, the PPS reserves some of 2752 these and rates the service. In this example, the PPS reserves, say, 2753 2 Euros and determines that the access service is rated at 0.4 Euro 2754 per MB. This results in 5 MB of quota being granted. The PPS also 2755 determines that the PPC should ask for this quota to be replenished 2756 once 4.5 MB have been consumed. Thus, it creates an Access Accept 2757 message with a Volume-Threshold indication of 4.5MB. It further 2758 associates the QID=5 to this reservation. This identifier can be 2759 used to later uniquely identify the prepaid session, user, account, 2760 etc. The resulting Access Accept message is sent to the PPC (3). 2762 Upon reception of message (4), the PPC provides the access service to 2763 the user and meters it accordingly. At some point in time, the 2764 threshold is reached, i.e., 4.5MB of "access service" have been 2765 consumed by the user. At that point, the PPC generates an Authorize- 2766 Only Access Request that contains the usual RADIUS attributes and a 2767 PPAQ attributes that reports the amount of consumed quota, and the 2768 request for replenishment, i.e., the Update-Reason= THRESHOLD REACHED 2769 (5). Note that the QID in this message is the same as the one 2770 previously received from the PPS. 2772 Upon reception of message (5), the PPS identifies the user and his 2773 account from the QID. In also determines that a prepaid session is 2774 ongoing, and that enough credit remains in the prepaid account in 2775 order for the access service to continue being provided. Since 4.5 2776 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2777 prepaid account. The PPS decides to reserve another 2.8 euros from 2778 the user's account. (This results in 3 euros being reserved in total 2779 at this point in time.) As the access service is rated at 0.4 euros 2780 per MB, the PPS determines that another 7 MB of quota should be 2781 granted. This results in a total cumulative quota allocation of 12 2782 MB for the access service. The PPS further calculates the new 2783 threshold value of 11.5 MB. Since this is a new quota reservation, 2784 the PPS also allocates a new QID to it, in this example QID=8. The 2785 resulting RADIUS message is sent to the PPC (6). 2787 Upon reception of message (6), the PPC updates its records and 2788 continues provisioning access to the user. At some point the user 2789 logs off (7). The PPC must then report how many resources were 2790 consumed, so that the PPC can subtract the appropriate monetary 2791 amount from the user's prepaid account. To this end the PPC 2792 constructs an Authorize-Only Access Request message with a PPAQ 2793 attributes for the access service. In this example, 7 MB were 2794 consumed by the access service in total. The PPC reports 7 MB its 2795 final message (8). The PPS correlates the report, using the QID, to 2796 the previous session state. It determines, from the previous 2797 records, that the access service had consumed another 4.5 MB before 2798 (as indicated in message (6)). This means that, of the 7 MB, only 2799 3.5 MB have not yet been subtracted from the user's account. Thus, 2800 the PPS subtracts another 1.4 euros from the user's account and, 2801 since the session is to be terminated (REASON=ACCESS SERVICE 2802 TERMINATED), releases any reserved monetary amount. 2804 The PPS responds with an Access Response as required by the RADIUS 2805 base specification (9). 2807 A.2. A flow with prepaid tariff switching 2809 End user PPC PPS 2811 user logs on 2812 ------(1)---------> 2813 Access Request 2814 {RADIUS BASE AVPS, 2815 PPAC=00...00111} 2816 -------(2)--------> 2818 [allocates 2819 20MB quota] 2821 Access Accept 2822 {RADIUS BASE AVPS, 2823 PPAQ={QID=5, VQ = 20MB, 2824 VTH = 18 MB}, PTS={ 2825 QID=5, PTS{TSI=300sec, 2826 TITSU=6000sec}} 2827 <-------(3)------- 2829 service provision/metering 2830 -------(4)---------> 2832 5900 seconds 2833 passed 2834 Access Request 2835 {RADIUS BASE AVPS, 2836 PPAQ={QID=5, VQ=14MB, 2837 REASON=TITSU APPROACH.}, 2838 TSI={QID=5, VUATS=11MB}} 2839 -------(5)---------> 2841 [allocates another 10MB 2842 to the access service] 2844 Access Accept 2845 {RADIUS BASE AVPS, 2846 PPAQ={QID=8, VQ=30MB, 2847 VTH = 28 MB},PTS={ 2848 QUD=8, PTS=95 sec}} 2849 <----------(6)-------------- 2851 user logs off 2853 ------(7)------- 2855 Access Request 2856 {RADIUS BASE AVPS, 2857 PPAQ={QID=8, VQ=17 MB, 2858 REASON=ACCESS SERV TERMINATED}, 2859 PTS={QID=8, VUATS=2.5 MB} 2860 -------(8)---------> 2862 [reimburses 2863 user account] 2865 AA Accept 2866 {RADIUS BASE AVPS} 2867 <-------(9)-------- 2869 Figure 17: Example message flow with Tariff Switch 2871 The user logs on (1). The PPC sends a RADIUS Access Request message 2872 to the home AAA server (2), and includes the prepaid-specific PPAC 2873 AVP. This AVP indicates that both duration-based and volume-based 2874 metering is supported, as well as tariff switching. The home AAA 2875 server then may authenticate and user and authorize the access 2876 service, as is usual in RADIUS. Note that the PPAC AVP is appended 2877 by the PPC in at least the last message that is sent to the PPS 2878 during this possibly multiple-round exchange. 2880 If authentication and authorization is successful (in this example 2881 this is assumed), the PPS identifies the user's prepaid account from 2882 the included base RADIUS AVPs, and determines the capabilities of the 2883 PPC from the PPAC attribute. In this example, it is assumed that a 2884 tariff switch is about to occur in 300 seconds from the current time. 2885 Suppose that the access service is currently rated at 0.5 euros per 2886 MB and in the next tariff period it is rated at 0.6 euros per MB. 2887 Suppose further that a third tariff period is about to start in 6000 2888 seconds from current time and that that access service is rated at 2889 0.8 euros per MB in that period. The PPS then decides to reserve 12 2890 euros from the user's account. Since it is conceivable that the user 2891 may consume all allocated quota in the (more expensive) "0.6-euro" 2892 period, the PPS reserves 20 MB of quota, and determines a threshold 2893 value of 18 MB. It constructs a Radius Access Accept message with a 2894 PPAQ attribute that reflects these choices, and carries a Quota 2895 Identifier QID=5. It further adds a PTS AVP in the message which is 2896 linked to the PPAQ via the common QID value. The PTS AVP contains a 2897 TSI attribute indicating that a tariff switch will occur in 300 2898 seconds. It also includes a TITSU attribute with the value of 6000 2899 seconds. This is included in order to make sure that the PPC will 2900 report the consumed quota before the "2-euro" tariff period will 2901 start. The message is sent to the PPC (3). 2903 Upon reception of message (3), the PPC provides the access service to 2904 the user and meters it accordingly (4). It also keeps track of time. 2905 That is, it remembers how many octets are consumed before and how 2906 many after the tariff switch that will take place in 300 seconds. 2908 In this example it is assumed that the user consumes the allocated 2909 quota rather slowly. In particular, nearly 6000 seconds (the value 2910 indicated by TITSU SubType) pass without the threshold of 18 MB being 2911 reached. The PPC notices this and must therefore report usage and 2912 request the quota to be replenished despite the fact that the 2913 threshold has not been reached. In this example, it decides to do so 2914 100 seconds before the 6000 seconds are reached. To this end, it 2915 constructs an Authorization Access Request message including a PPAQ 2916 that indicates that 14 MB have been consumed up to now. It also 2917 includes a PTS attribute in order to indicate, using the VUATS 2918 SubType, that 11 MB of these were consumed after the tariff switch. 2919 The message is sent to the the PPS (5). 2921 The PPS can link the message to previous session state via the QID. 2922 It now rates the consumed volume as follows. The 11 MB that were 2923 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 2924 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 2925 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 2926 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 2928 The PPS now determines that message (5) was sent in order to 2929 replenish the quota for this prepaid session. This can be deduced 2930 from the UPDATE REASON field, which indicates that the PPC sent this 2931 message because the time indicated by the TITSU SubType is 2932 approacing. The PPS now determines that enough credit remains in the 2933 user's prepaid account in order for the access service to continue 2934 being provided and decides to reserve another 8.9 euros from the 2935 user's account. Since it is conceivable that the user will consume 2936 the 6 unused MB of quota from the previous allocation, as well as the 2937 entire quota that is to be allocated now, entirely in the "0.8-euro" 2938 period, the quota that should now be granted in addition to the 2939 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 2940 are being reserved in order to "cover the worst case scenario". The 2941 fact that 0.9 euros are reserved for this purpose is due to the fact 2942 that the unused 6 MB from the previous allocation correspond to 4.8 2943 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 2944 than the amount of funds that are still "reserved" from the previous 2945 allocation. (After this reservation, the total amount of reserved 2946 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 2947 being consumed in the "0.8-euro" period.) 2948 Since quotas are encoded in a cumulative way in RADIUS, the PPS 2949 includes a VolumeQuota of 30 MB into the Access Accept message (6). 2950 The PPS further calculates the new threshold value of 28 MB. Since 2951 this is a new quota reservation, the PPS also allocates a new QID to 2952 it, in this example QID=8. The resulting RADIUS message is sent to 2953 the PPC (6). 2955 Upon reception of message (6), the PPC updates its records and 2956 continues providing access to the user. At some point the user logs 2957 off (7). The PPC must then report how many resources were consumed, 2958 so that the PPC can subtract the appropriate monetary amount from the 2959 user's prepaid account. To this end the PPC constructs an Authorize- 2960 Only Access Request message with a PPAQ attributes for the access 2961 service. In this example, 17 MB were consumed by the access service 2962 in total. The PPC reports 17 MB its final message (8). The PPS 2963 correlates the report, using the QID, to the previous session state. 2964 It determines, from the previous records, that the access service had 2965 consumed 14 MB before (as indicated in message (5)). This means 2966 that, of the 17 MB, only the monetary equivalent for 3 MB have not 2967 yet been subtracted from the user's account. The PPS calculates how 2968 much should be deducted from the user's account as follows. Since 2969 the VUATS SubType indicates that 2.5MB were consumed after the tariff 2970 switch, only 0.5 MB were consumed before that. Thus, the monetary 2971 equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. That is, the PPS 2972 subtracts 3.6 euros from the user's prepaid account. Since the 2973 session has by now be terminated by the PPC (REASON=ACCESS SERVICE 2974 TERMINATED), the PPS now releases any reserved monetary amount, in 2975 this example 12.8 - 3.6 = 9.2 euros. 2977 The PPS responds with an Access Response as required by the RADIUS 2978 base specification (9). 2980 Remark: In this example, two tariff switches take place. In other 2981 scenarios, of course, only one tariff switch may occur. In such 2982 scenarios the TITSU SubType is not used. 2984 A.3. Resource pools and Rating Groups 2986 End user PPC PPS 2988 user logs on 2989 ------(1)---------> 2991 Access Request 2992 {RADIUS BASE AVPS, 2993 PPAC=00...00101111} 2994 -------(2)--------> 2996 [allocates 2997 5MB quota] 2999 Access Accept 3000 {RADIUS BASE AVPS, 3001 PPAQ={QID=5, VQ = 5MB, 3002 poolID=1,mult=1}} 3003 <-------(3)-------- 3005 service provision/metering 3006 -------(4)---------> 3008 user requests service A 3009 -------(5)---------> 3011 Access Request 3012 {RADIUS BASE AVPS,PPAQ={ 3013 SID="A", RGROUP=1}} 3014 -------(6)--------> 3016 [allocates 50 min 3017 quota] 3019 Access Accept 3020 {RADIUS BASE AVPS, 3021 PPAQ={QID=7, DQ=3000sec 3022 poolID=1,RGROUP=1, SID="A" 3023 mult=1747.63}} 3024 <---------(7)--------------- 3026 user requests service B 3027 -------(8)--------> 3029 Pool 1 close to exhaustion 3031 Access Request 3032 {RADIUS BASE AVPS, 3033 PPAQ={QID=5, VQ=4MB, 3034 REASON=QUOTA REACHED, 3035 PoolID=1, mult=1} 3036 PPAQ={QID=7, DQ=3300sec 3037 REASON=QUOTA REACHED, 3038 PoolID=1, mult=1747.63, 3039 SID="A",RGROUP=1}} 3040 -------(9)---------> 3042 [allocates another 3043 3 MB to access service 3044 and 30 minutes to 3045 service "A"] 3047 Access Accept 3048 {RADIUS BASE AVPS, 3049 PPAQ={QID=8, VQ=8MB, 3050 PoolID=1, mult=1, RGROUP=1}, 3051 PPAQ={QID=9, DQ=4800sec 3052 PoolID=1, mult=1747.63, 3053 SID="A"}} 3054 \ <----------(10)-------------- 3056 user logs off 3057 ------(11)------- 3058 Access Request 3059 {RADIUS BASE AVPS, 3060 PPAQ={QID=8, VQ=6.5MB, 3061 REASON=ACCESS SERV TERMINATED, 3062 PoolID=1, mult=1} 3063 PPAQ={QID=9, DQ=5400sec 3064 REASON=ACCESS SERV TERMINATED, 3065 PoolID=1, mult=1747.63, 3066 SID="A",RGROUP=1}} 3067 -------(12)---------> 3069 [reimburses 3070 user account] 3072 AA Accept 3073 {RADIUS BASE AVPS 3074 <------(13)-------- 3076 Figure 18: Example message flow with resource pools and rating groups 3078 The user logs on (1). The PPC sends a RADIUS Access Request message 3079 to the PPS (2), and includes the prepaid-specific PPAC AVP, 3080 indicating that multiple services, rating groups and resource pools 3081 are supported. Note that, since this is not an "Authorize- Only" 3082 message, no PPAQ attribute with Update Reason="initial request" is 3083 included (see Section 3.7.1). The PPS then may authenticate the user 3084 and authorize the access service, as is usual in RADIUS. Note that 3085 the PPAC AVP is appended by the PPC in at least the last message that 3086 is sent to the PPS during this possibly multiple-round exchange. 3088 If authentication and authorization is successful (in this example 3089 this is assumed), the PPS identifies the user's prepaid account from 3090 the included base RADIUS AVPs, and determines the capabilities of the 3091 PPC from the PPAC attribute. Assuming that sufficient funds are 3092 available in the user's prepaid account, the PPS reserves some of 3093 these and rates the service. In this example, the PPS reserves 5 3094 Euros and determines that the access service is rated at 1 Euro per 3095 MB. In anticipation that the user requests more chargeable services 3096 throughout this prepaid session, and since this is supported by the 3097 PPC, the PPS further associates a resource pool with this 3098 reservation, in this example PoolID=1. The PPC also specifies the 3099 multiplier = 1 for the access service. Note that, since 5MB = 3100 5242880 octets, 1 unit in the resource pool corresponds to 5 / 3101 5242880 euros, which is about 0.000095367431640625 Eurocents. 3102 (However, the PPC does not need to know that.) Moreover, the PPS 3103 associates the QID=5 to this reservation. This identifier can be 3104 used to later uniquely identify the prepaid session, user, account, 3105 etc. The resulting Access Accept message is sent to PPC (3). 3107 Upon reception of message (3), the PPC provides the access service to 3108 the user and meters it accordingly (4). That is, for every octet 3109 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 3110 the resouce pool with PoolID=1. 3112 At some point in time, the user requests another chargeable service, 3113 namely service A (5). The PPC generates an Authorize-Only Access 3114 Request that contains the usual RADIUS attributes and the Service-ID 3115 identifying service A (6). The PPC has determined that service A is 3116 rated in an identical way as at least one more service. Thus, 3117 service A has been configured to belong to a rating group, in this 3118 example the group with Rating-Group-ID=1. This identifier is 3119 included is message (6). 3121 Upon reception of message (6), the PPS identifies the user and his 3122 account from the base RADIUS attributes, the fact that a prepaid 3123 session is ongoing, and determines that enough credit remains in the 3124 prepaid account in order for service A to be provided. The PPS also 3125 determines that service A is rated at 0.10 euros per minute. The PPS 3126 decides to reserve another 5 euros from the users account; this 3127 corresponds to 50 minutes or, as encoded in the DurationQuota 3128 SubType, 3000 seconds. As service A draws from the same prepaid 3129 account as the access service, the PPS associates this reservation 3130 with the same resource pool as the previous reservation (QID=5), 3131 namely the pool with PoolID=1. Note that, in order for the abstract 3132 units in the pool to be consistent, the multiplier has to be 1747.63. 3133 This is because each second corresponds to about 0.10 / 60 = 0.00167 3134 euros, which is about 1747.63 times the value of an abstract resource 3135 pool unit, as this was determined by the first allocation of quota to 3136 the pool (i.e., 0.000095367431640625 Eurocents). Since this is a new 3137 quota reservation, the PPS also allocates a new QID to it, in this 3138 example QID=7. The resulting RADIUS message is sent to the PPC (7). 3140 Upon reception of message (7), the PPC adjusts the units in resource 3141 pool 1. That is, it first determines how much quota had been 3142 allocated to service A in the past, and subtracts this from the quota 3143 reservation found in the message. Since this is the first quota 3144 reservation for service A, there is nothing to subtract. Thus, it 3145 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 3146 3000 seconds have been allocated to service A during this prepaid 3147 session. The PPC then provides service A to the user, and meters it 3148 against resource pool 1. That is, for every second it subtracts 3149 1747.63 units from the pool. 3151 At some point in time, the user requests service B (8). The PPC 3152 determines that service B is rated exactly in the same way as service 3153 A, i.e., that they belong to the same rating group, namely the one 3154 with Rating-Group-ID=1. Since this rating group has been effectively 3155 authorised by the allocation of quota with QID=7, the PPC provides 3156 service B to the user immediately. It is rated in the same way as 3157 service A, i.e., for every second provided, 1747.63 units are 3158 subtracted from credit pool 1. 3160 At some point in time, resource pool 1 is close to exhaustion. (For 3161 example, the PPC may determine that the pool is "close to exhaustion" 3162 when has less than 10% its initial amount of units.) At that point, 3163 the PPC needs to ask for replenishment for the pool. Suppose that, 3164 at that point in time, 4MB of "access service", 45 minutes of 3165 "service A", and 10 minutes of "service B" were provided to the user. 3166 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 3167 + 5767179 = 9961483 abstract service units from the pool. The PPC 3168 constructs an Authorize-Only Access Request message that reports the 3169 usage for the "access service" and "service A". This message 3170 contains two PPAQ attributeS, is sent to the PPS (9). Note that is 3171 the message it appears that "service A" has consumed more than it was 3172 allocated (i.e., 55 minutes although only 50 minutes were initially 3173 allocated to it). This is not a a problem since the PPS knows that 3174 "service A" was drawing from the same pool as the "access service" 3175 and that the "access service" did only consume 4 out of the 5 MB it 3176 was allocated. 3178 Upon reception of message (9), the PPS subtracts 4 euros from the 3179 user's account for the "access service" and another 5.5 euros for 3180 "service A". (This includes the charge incurred by "service B" up to 3181 that point in time, although the PPS is not aware of "service B" 3182 being provisioned to the user.) The PPS then determines that 3183 sufficient funds remain in the prepaid account in order for both 3184 services to be continued. The PPS decides to reserve another 3MB for 3185 the access service and 30 minutes for "service A". This corresponds 3186 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 3187 cumulative manner, the PPAQ attribute that grants the quota for the 3188 "access service" contains a Volume-Quota SubType of 8MB (8388608 3189 octets), which is the 5MB that were initially allocated, plus the 3MB 3190 allocated now. The resource pool identifier is, as previously, 3191 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 3192 quota for "service A" contains 4800 seconds (the initial 3000 plus 3193 1800 that correspond to the 30 additional minutes). Again, the 3194 PoolID=1 and multiplier=1747.63. The resulting Access Response 3195 message is sent to the PPC (10). 3197 When the PPC received message (10) it checks how much quota has been 3198 allocated previously to the "access service". It finds that the 3199 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 3200 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 3201 have not yet been added to resource pool 1. The PPC thus adds 3202 3145728 abstract units to resource pool 1 (since the multiplier is 3203 1). The PPC then acts similarly on the other PPAQ attribute that 3204 exists in message (11). That is, the PPC determines that 3000 3205 seconds of quota for "service A" had already been added to the pool. 3206 Thus only 1800 out of the 4800 should be additionally added to the 3207 pool. Since the applicable multiplier here is 1747.63, the PPC adds 3208 further 3145734 abstract units to the pool 1. 3210 The PPC then continues to provide the access service, "service A" and 3211 "service B" to the user, and meters them against the pool, as 3212 previously. 3214 At some point the user logs off (11). The PPC must then report how 3215 many resources were consumed, so that the PPC can subtract the 3216 appropriate monetary amount from the user's prepaid account. To this 3217 end the PPC constructs an Authorize-Only Access Request message with 3218 two PPAQ attributes; one for the access service and one for "service 3219 A". Suppose that, in total, 6.5MB were consumed by the access 3220 service, 70 minutes were consumed by "service A" and 20 minutes by 3221 "service B". The PPC reports 6.5MB (6815744 octets) and 90 minutes 3222 (5400 seconds) in its final message (12). The PPS determines, from 3223 the previous records, that the access service consumed another 2.5MB 3224 (since 4MB out of the 6.5MB were already reported in message (9), and 3225 that "service A" consumed further 600 seconds. This corresponds to 3226 2.5 + (600/60)*0.1 = 2.5+ 1=3.5 euros. Thus, the PPS only subtracts 3227 2.5 out of the 6 previously reserved euros from the user's prepaid 3228 account and responds with an Access Response as required by the 3229 RADIUS base specification (13). 3231 A.4. One-time charging 3232 End user PPC PPS 3234 user requests ring tone 3235 ------(1)---------> 3237 Access Request 3238 {RADIUS BASE AVPS, 3239 PPAQ={QID=321, SID=X, RQ=650, 3240 REASON=10 (ONE-TIME CHARGING}} 3241 -------(2)---------> 3243 [rates 650 abstract units 3244 deducts from user's account] 3246 Access Accept 3247 {RADIUS BASE AVPS} 3248 <----------(3)-------------- 3250 ring tone is delivered 3251 <------(4)------- 3253 Figure 19: Example message flow with one-time charging 3255 The user requests a chargeable ring tone (1). The PPC sends a RADIUS 3256 Access Request message to the PPS (2), and includes a PPAQ attribute 3257 with Update Reason="one-time charging" is included (see 3258 Section 3.8.6). The Service ID indicates to the PPS that the 3259 charging event is connected to a ring tone, so that the PPS can rate 3260 the event accordingly. The PPAQ also contains a unique Quota 3261 Identifier. 3263 The PPS then may authenticate the user as is usual in RADIUS. If 3264 authentication is successful (in this example this is assumed), the 3265 home AAA server forwards the PPC converts the 650 reported abstract 3266 units into monetary value, according to the service type, and debit 3267 the user's account accordingly. This happens, of course, only if 3268 sufficient funds are available in the user's prepaid account. The 3269 PPC then responds with an an Access Accept message (3). The PPS adds 3270 a "session timeout = 0 AVP" (see Section 3.8.6). 3272 A.5. Price enquiry 3273 End user PPC PPS 3275 user requests AoC 3276 ------(1)---------> 3278 Access Request 3279 {RADIUS BASE AVPS, 3280 PPAQ={SID=X, VQ=10MB, 3281 REQ_ACT=2(PRICE ENQUIRY}} 3282 -------(2)---------> 3284 [rates 10MB for requested 3285 service] 3287 Access Accept 3288 {RADIUS BASE AVPS, 3289 PPAQ={SID=X, VQ=10MB, 3290 COST INFORMATION= 0.6 euros 3291 per MB}} 3292 <----------(3)-------------- 3294 AoC is delivered 3295 <------(4)------- 3297 Figure 20: Example message flow with price enquiry (advice of charge) 3299 Please refer to Section 2.7.3 for an explanation of this message 3300 flow. 3302 A.6. Balance check 3303 End User PPC PPS 3305 Access Request 3306 {RADIUS BASE AVPS, 3307 PPAQ={SID=X, VQ=10MB, 3308 REQ_ACT=BALANCE CHECK}} 3309 -------(2)---------> 3311 [rates requested 3312 Service and checks 3313 remaining funds] 3315 Access Accept 3316 {RADIUS BASE AVPS, 3317 PPAQ={SID=X, VQ=10MB, 3318 BALANCE_CHECK_RESULT}} 3319 <----------(3)-------------- 3321 Figure 21: Example message flow with balance check 3323 Please refer to Section 2.7.4 for an explanation of this message 3324 flow. 3326 Appendix B. Translation between RADIUS Prepaid and Diameter Credit 3327 Control 3329 Note: This section is informative. 3331 In scenarios where the service metering device uses the "RADIUS 3332 prepaid" (RPP) protocol for accounting and prepaid charging while the 3333 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 3334 a translation agent that enables the interoperation of both systems, 3335 is desirable. This also applies vice versa, i.e., in scenarios where 3336 the AAA infrastructure uses RADIUS and the service metering device 3337 uses Diameter. 3339 The idea of such a translation agent would be to convert incoming RPP 3340 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 3341 would be, in principle, desirable for the translation agent to be 3342 stateless. That is, the agent should not be required to internally 3343 maintain information about each ongoing RADIUS or Diameter session. 3344 However, under the current specification of RPP and DCC, this appears 3345 to be impossible due to a number of reasons. These include the 3346 following. 3348 1. The transport mechanism for DCC is TCP, which requires per- 3349 session state to be maintained at both endpoints of the 3350 communication. Note, however, that, in principle, each DCC 3351 message could be sent over a dedicated TCP connection which is 3352 torn down as soon as the message is sent. This, however, is 3353 likely to be unacceptable in terms of efficiency. 3355 2. While RPP messages encode the cumulative amount of consumed/ 3356 requested resources, DCC messages carry the difference from the 3357 previous message. This means that the translation agent has to 3358 maintain the current amount of consumed/requested resources in 3359 order to be able to calculate the correct amount to be put into 3360 an outgoing message. 3362 The translator maps each incoming RPP (resp. DCC) message into an 3363 outgoing DCC (resp. RPP) message, and possibly establishes or updates 3364 local state that is associated with the session. The translated 3365 (i.e., outgoing) message is a function of the incoming message as 3366 well as existing state that is associated with the current session. 3368 Translation occurs on an attribute-by-attribute basis. Certain 3369 attributes are translated without consideration of local per-session 3370 state. Other attributes, namely those that are bound to a particular 3371 session, require such consideration. The translation agent has to 3372 identify the session (and possibly subsession) an incoming message 3373 belongs to in order to consult the appropriate local per-session 3374 state. 3376 Note that certain DCC attributes cannot be translated due to their 3377 semantics not being present in RPP, and vice versa. This results in 3378 the messages, in which these attributes occur, not being delivered to 3379 their intended destination. In such cases it is desirable to inform 3380 the originator about the failure and terminate the session. 3382 In each scenario (i.e., RPP client / DCC AAA infrastructure and DCC 3383 client / RPP AAA infrastructure), the translator operates in two 3384 directions, namely RPP to DCC and vice versa. In the following 3385 sections, the notation c->s means that the attribute in question may 3386 occur only in the direction from the client to the server. The 3387 notation s->c denotes the converse and the notation c<->s denotes 3388 that the attribute may occur in messages that are directed in either 3389 direction. 3391 B.1. Session Identification 3393 The translation agent has to keep per-session state in order to 3394 perform its task. A session may be identified based on the RPP 3395 identifier or the DCC session identifier. That is, the translation 3396 agent should always maintain a pair of (RPP, DCC) session identifiers 3397 and maintain the per-session state in association with that pair. 3398 This per-session state must be addressable by either of these two 3399 identifiers. Moreover, an RPP session identifier must uniquely 3400 correspond to a DCC identifier. (If this holds, the converse also 3401 holds.) Each subsession identifier within an RPP session must also 3402 uniquely correspond to a subsession identifier within its 3403 corresponding DCC session. (If this holds the converse also holds.) 3405 B.2. Translation between RADIUS Prepaid and Diameter Credit Control 3407 This section describes the translator in the "RPP client / DCC AAA 3408 infrastructure" case. In other words, in this section it is assumed 3409 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 3410 The translator is assumed to sit somewhere in the middle and to 3411 mediate between client and server. 3413 For each RPP AVP (i.e., AVPs that are specified in the present 3414 document), the transformation into a semantically equivalent DCC AVP 3415 (if such an AVP exists), along with what per-session state the 3416 translator has to create or consult, is described. For clarity of 3417 exposition, each RPP AVP is addressed in a separate subsection. 3418 Since in this scenario, the PPC is typically the initiator a session, 3419 the focus is on the RPP AVPs. 3421 B.2.1. PPAC (c<->s) 3423 A DCC client is assumed to always support Volume metering, Duration 3424 metering, Resource metering, Pools, Rating groups, and Tariff 3425 Switching. Thus, if a PPAQ that indicates any of the above is sent 3426 client->server, the translator does the following: It lets message go 3427 through but remembers what exactly the client supports. If the 3428 server later requests (servier -> client direction) an unsupported 3429 metering to be performed, send failure to server and cause the 3430 session to be terminated at the client. 3432 If a PPAC indicates support for multiple services (0x00000020), the 3433 translator maps this onto a DCC Multiple-Services- Indicator AVP. 3435 B.2.2. Service Termination Attribute (c->s) 3437 The Diameter base protocol assumes that the client always supports 3438 dynamic session termination. If this AVP is present, the translator 3439 does not need to do anything, i.e., there exists no DCC AVP that this 3440 AVP can be mapped to. If this AVP is absent, the message in which it 3441 appears should either be discarded and originator should be informed 3442 of a failure, or the message can be passed on (without this AVP being 3443 mapped onto a DCC AVP). However, in the latter case, the translator 3444 has to remember that the client does not support dynamic termination. 3445 Thus, the translatior has to initiate the normal session termination 3446 procedure with the client when (if) dynamic termination is later 3447 initiated by the server. 3449 B.2.3. Quota Identifier Attribute (c<->s) 3451 When quota is allocated for the first time by the DCC server, the 3452 translator has to create a QID AVP, as required by this 3453 specification. The translator later uses a QID AVP that is sent in 3454 the client-to-server direction in order to identify the corresponding 3455 DCC session. The QID has to be saved in the translator's per session 3456 state. 3458 B.2.4. Volume Quota Attribute (c<->s) 3460 If this AVP occurs in a message that is sent in the server-to-client 3461 direction, it is translated into a Granted-Service-Unit AVP with an 3462 embedded CC-Total-Octets AVP. 3464 If this AVP occurs in a message that is sent in the client-to-server 3465 direction, then it is translated into a Used-Service-Unit AVP with an 3466 embedded CC-Total-Octets AVP. Note that only the difference between 3467 current cumulative quota for the (sub)session and the quota in 3468 incoming messages is indicated in the translated DCC message. Local 3469 state is updated with cumulative consumed resources. 3471 Conversely, if the server grants quota using the DCC Granted-Service- 3472 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 3473 agent must translate this into a Volume Quota Attribute. Again, 3474 local state must be consulted so that the cumulative amount of octets 3475 is indicated in the Volume Quota attribute. 3477 B.2.5. Duration Quota Attribute (c<->s) 3479 If this AVP occurs in a message that is sent in the server-to-client 3480 direction, it is translated into a Granted-Service-Unit AVP with an 3481 embedded CC-Time AVP. 3483 If this AVP occurs in a message that is sent in the client-to-server 3484 direction, then it is translated into a Used-Service-Unit AVP with an 3485 embedded CC-Time AVP. Note that only the difference between current 3486 cumulative quota for the (sub)session and the quota in incoming 3487 messages is indicated in the translated DCC message. Local state is 3488 updated with cumulative consumed resources (i.e., time). 3490 Conversely, if the server grants quota using the DCC Granted-Service- 3491 Unit AVP with an embedded CC-Time AVP, then the translation agent 3492 must translate this into a Duration Quota attribute. Again, local 3493 state must be consulted so that the cumulative amount of seconds is 3494 indicated in the Duaration Quota attribute. 3496 B.2.6. Resource Quota Attribute (c<->s) 3498 If this AVP occurs in a message that is sent in the server-to-client 3499 direction, it is translated into a Granted-Service-Unit AVP with an 3500 embedded CC-Service-Specific-Units AVP. 3502 If this AVP occurs in a message that is sent in the client-to-server 3503 direction, then it is translated into a Used-Service-Unit AVP with an 3504 embedded CC-Service-Specific-Units AVP. Note that only the 3505 difference between current cumulative quota for the (sub)session and 3506 the quota in incoming messages is indicated in the translated DCC 3507 message. Local state is updated with cumulative consumed resources 3508 (i.e., resources). 3510 Conversely, if the server grants quota using the DCC Granted-Service- 3511 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 3512 translation agent must translate this into a Resource Quota 3513 attribute. Again, local state must be consulted so that the 3514 cumulative amount of resource units is indicated in the Resource 3515 Quota attribute. 3517 Note that the "resource" type is application dependent. This means 3518 that a DCC application unit corresponds to n RPP application units, 3519 where n may be any real number. If n is not 1, then the RPP/DCC 3520 translator must be aware of that and translate resource units 3521 accordingly. 3523 B.2.7. Value Digits Attribute (c<->s) 3525 The encoding of this AVP is similar in RPP and DCC, and the value it 3526 holds may have to be evaluated in conjunction with an acommpanying 3527 "Exponent" AVP. It should be kept in mind that, in RPP the 3528 cumulative amount of granted/consumed quota is typically encoded into 3529 an AVP of this type, while in DCC only the difference from a previous 3530 message. 3532 B.2.8. Exponent Attribute (c<->s) 3534 The encoding of this AVP is similar in RPP and DCC, and the value it 3535 holds may have to be evaluated in conjunction with an acommpanying 3536 "Value Digits" AVP. It should be kept in mind that, in RPP the 3537 cumulative amount of granted/consumed quota is typically encoded into 3538 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 3539 the difference from a previous message is encoded into such a pair. 3541 B.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 3543 In DCC the concept of "threshold" does not exist. Instead, the DCC 3544 client is assumed to ask for the replenishment of quota in good time. 3545 In RPP, on the other hand, the server may optionally include a 3546 threshold AVP, as an indication to the PPC about when to ask for 3547 quota replenishment. 3549 Thus, in this scenario, there is no need for the translator to ever 3550 include a threshold attribute into the messages that it sends to the 3551 PPC. If, however, there is a need for a threshold attribute to be 3552 present in order to avoid a possible service provision 3554 B.2.10. Update Reason Attribute (c->s) 3556 The DCC AVP that is semantically closer to the Update Reason AVP than 3557 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 3558 the message is which it appears is intended to indicate an "initial", 3559 an "intermediate" or a "final interrogation". Morever, in case of 3560 the session being terminated at the client, it indicates the reason 3561 for this termination. 3563 The following list lists the possible values of an "Update Reason" 3564 attribute, along with corresponding values for the CC-Request-Type 3565 AVP. 3567 o Pre-initialization: No action/value defined. 3569 o Initial Request: Typically an "intial interrogation" is triggered 3570 as a result of the reception of the message that contains this 3571 Update Reason AVP. Hence, CC-Request-Type AVP indicates 3572 "INITIAL_REQUEST". 3574 o Threshold Reached: The reception of the message containing this 3575 Update Reason AVP typically triggers an "intermediate 3576 interrogation". Hence, CC-Request-Type AVP indicates 3577 "UPDATE_REQUEST". 3579 o Quota Reached: The reception of the message containing this Update 3580 Reason AVP typically triggers an "intermediate interrogation". 3581 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 3583 o TITSU Approaching: The reception of the message containing this 3584 Update Reason AVP typically triggers an "intermediate 3585 interrogation". Hence, CC-Request-Type AVP indicates 3586 "UPDATE_REQUEST". 3588 o Remote Forced Disconnect: Reception of such an Update Reason 3589 indicates that the client has terminated the session. The 3590 corresponding value for the CC-Request-Type AVP is 3591 "TERMINATION_REQUEST". 3593 o Client Service Termination: Reception of such an Update Reason 3594 indicates that the client has terminated the session. The 3595 corresponding value for the CC-Request-Type AVP is 3596 "TERMINATION_REQUEST". 3598 o "Access Service" Terminated: Reception of such an Update Reason 3599 indicates that the client has terminated the session. The 3600 corresponding value for the CC-Request-Type AVP is 3601 "TERMINATION_REQUEST". 3603 o Service not established: Reception of such an Update Reason 3604 indicates that the client has terminated the session. The 3605 corresponding value for the CC-Request-Type AVP is 3606 "TERMINATION_REQUEST". 3608 o One-Time Charging: Such an Update Reason indicates that a one-time 3609 charging event is initiated by the client. The corresponding 3610 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 3611 "Requested-Action: AVP MUST also be included in the outgoing DCC 3612 message. Typically, this would be of the type "DIRECT_DEBITING", 3613 or "REFUND_ACCOUNT", depending on other AVPs present in the 3614 message. 3616 B.2.11. PrepaidServer Attribute (s<->c) 3618 The PPC typically never sets the value of a PrepaidServer attribute. 3619 Instead, it repeats those values that it receives from the AAA 3620 infrastructure, in this scenario from the translator. This attribute 3621 is therefore not used in a translation scenario. Nevertheless, the 3622 translator must make sure that messages about the same RPP session 3623 are forwarded to the same DCC server, throughout the whole session. 3624 This may be easy to guarantee since the transport of Diameter is TCP. 3626 B.2.12. Service-ID Attribute (s<->c) 3628 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 3629 Service-Context-Id and Service-Identifier AVPs. The translator must 3630 keep a static equivalence table of the RPP Service-ID and the 3631 corresponding DCC combination in order to correctly translate an RPP 3632 service identifier into DCC and back. 3634 B.2.13. Rating-Group-ID Attribute (s<->c) 3636 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 3637 "Rating-Group-ID". Depending on the configuration, this AVP may 3638 contain the same value on both the RPP and the DCC side of the 3639 communication. If, however, static rating groups are configured 3640 between the RCC client and the translator, and different rating 3641 groups between the DCC server and the translator, then the translator 3642 has to maintain a static translation table for the rating group 3643 identifier. In any case, the translation of a rating group AVP, is 3644 not a function of the translator's local per-session state. 3646 B.2.14. Termination-Action Attribute (s->c) 3648 The DCC equivalent of the "Termination-Action" AVP is called the 3649 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 3650 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 3651 "Termination-Action" AVP. The following list contains the possible 3652 "Final-Unit-Action" values along with their "Termination-Action" 3653 equivalent. 3655 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 3656 called "Terminate". 3658 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 3659 AVP, then a "Redirect-Server-Address" AVP must also appear in the 3660 same DCC message. The translator translates these two AVPs into a 3661 "Termination-Action" with value "Redirect/Filter" and an 3662 eqiovalent NAS-Filter-Rule attribute (specified in http:// 3663 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 3665 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 3666 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 3667 in the same DCC message. The translator translates these two AVPs 3668 into a "Termination-Action" with value "Redirect/Filter" and an 3669 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 3670 internet-drafts/draft-ietf-radext-ieee802-00.txt). 3672 o In the absence of a "Final-Unit-Action" AVP, the DCC server 3673 assumes that the DCC client will ask for replenishment of quota at 3674 some suitable time. In RPP, this is explicitly conveyed via a 3675 "Termination-Action" AVP with the value "Request More Quota". 3676 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 3677 in this scenario appends such an AVP into the outgoing RPP 3678 message. 3680 B.2.15. Pool-ID Attribute (s<->c) 3682 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 3683 Typically, no translation needs to be done to the "Pool-ID" 3684 attribute. 3686 B.2.16. Multiplier Attribute (s<->c) 3688 The multiplier attribute, which is a pair of "Value-Digits" and 3689 "Exponent" AVPs, typically needs no translation, since the value it 3690 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 3691 the rating of the service or rating group to which it refers, with 3692 respect to abstract units. As such, the same multiplier value would 3693 typically applyt be conveyed from a DCC server to an PPC, and vice 3694 versa. 3696 B.2.17. Requested-Action Attribute (c->s) 3698 The "Requested Action" AVP can be directly translated into its DCC 3699 equivalent, which carries the same name. 3701 1. Balance Check (PCC): CHECK_BALANCE (DCC) 3703 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 3705 B.2.18. Check-Balance-Result Attribute (s->c) 3707 This attribute carries only a binary value. Hence, its translation 3708 is straightforward. 3710 B.2.19. Cost-Information Attribute (s->c) 3712 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 3713 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 3714 exist in DCC, and carry identical semantics in the context of the 3715 "Cost-Information" AVP. Thus, the translation of this attribute is 3716 straightforward. 3718 B.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 3720 This attribute carries the amount of octets that were consumed after 3721 a tariff change. It always appears in a message with an accompanying 3722 PPAQ attribute in which the total amount of octets (i.e., those that 3723 were consumed both before and after the tariff switch) is reported. 3724 Thus, the translation agent can compute the amount of octets that 3725 were consumed before the tariff change. 3727 In DCC, the two amounts, i.e., the octets that were consumed before a 3728 tariff change and those that were consumed afterwards, are reported 3729 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 3730 have an embedded CC-Total-Octets AVP that indicates the appropriate 3731 amount of octets. Furthermore, the Used-Service-Unit AVP that 3732 carries the amount that was consumed before the tariff switch also 3733 carries an embedded Tariff-Change-Usage AVP with the value 3734 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 3735 that carries the amount that was consumed after the tariff switch 3736 also carries an embedded Tariff-Change-Usage AVP with the value 3737 UNIT_AFTER_TARIFF_CHANGE (1). 3739 Authors' Addresses 3741 Avi Lior 3742 Bridgewater Systems 3743 303 Terry Fox Drive 3744 Ottawa, Ontario Suite 100 3745 Canada 3747 Email: avi@bridgewatersystems.com 3749 Parviz Yegani 3750 Cisco 3751 Mobile Wireless Group, Cisco Systems 3752 3625 Cisco Way, San Jose, California 95134 3753 USA 3755 Email: pyegani@cisco.com 3757 Kuntal Chowdhury 3758 Starent Networks 3759 30 International Place, 3rd Floor 3760 Tewksbury, MA 01876 3761 USA 3763 Email: kchowdhury@starentnetworks.com 3765 Hannes Tschofenig 3766 Nokia Siemens Networks 3767 Linnoitustie 6 3768 Espoo 02600 3769 Finland 3771 Phone: +358 (50) 4871445 3772 Email: Hannes.Tschofenig@gmx.net 3773 URI: http://www.tschofenig.priv.at 3775 Andreas Pashalidis 3776 NEC 3777 Kurfuersten-Anlage 36 3778 Heidelberg 69115 3779 Germany 3781 Email: Andreas.Pashalidis@netlab.nec.de 3783 Full Copyright Statement 3785 Copyright (C) The IETF Trust (2008). 3787 This document is subject to the rights, licenses and restrictions 3788 contained in BCP 78, and except as set forth therein, the authors 3789 retain all their rights. 3791 This document and the information contained herein are provided on an 3792 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3793 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3794 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3795 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3796 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3797 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3799 Intellectual Property 3801 The IETF takes no position regarding the validity or scope of any 3802 Intellectual Property Rights or other rights that might be claimed to 3803 pertain to the implementation or use of the technology described in 3804 this document or the extent to which any license under such rights 3805 might or might not be available; nor does it represent that it has 3806 made any independent effort to identify any such rights. Information 3807 on the procedures with respect to rights in RFC documents can be 3808 found in BCP 78 and BCP 79. 3810 Copies of IPR disclosures made to the IETF Secretariat and any 3811 assurances of licenses to be made available, or the result of an 3812 attempt made to obtain a general license or permission for the use of 3813 such proprietary rights by implementers or users of this 3814 specification can be obtained from the IETF on-line IPR repository at 3815 http://www.ietf.org/ipr. 3817 The IETF invites any interested party to bring to its attention any 3818 copyrights, patents or patent applications, or other proprietary 3819 rights that may cover technology that may be required to implement 3820 this standard. Please address the information to the IETF at 3821 ietf-ipr@ietf.org.