< draft-lior-radius-prepaid-extensions-09.txt   draft-lior-radius-prepaid-extensions-10.txt >
RADEXT A. Lior RADEXT A. Lior
Internet-Draft Bridgewater Systems Internet-Draft Bridgewater Systems
Expires: April 26, 2006 P. Yegani Expires: August 17, 2006 P. Yegani
Cisco Cisco
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
H. Tschofenig H. Tschofenig
A. Pashalidis A. Pashalidis
Siemens Siemens
October 23, 2005 February 13, 2006
Prepaid extensions to Remote Authentication Dial-In User Service Prepaid extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
draft-lior-radius-prepaid-extensions-09.txt draft-lior-radius-prepaid-extensions-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2006. This Internet-Draft will expire on August 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This draft presents an extension to the Remote Authentication Dial- This document describes an extension to the Remote Authentication
In User Service (RADIUS) protocol to support charging for prepaid Dial- In User Service (RADIUS) protocol. This extension makes RADIUS
services. The charging models supported are namely: volume-based support charging for prepaid services. The extension is based on a
charging, duration-based charging and one-time-based charging. number of charging models, in particular based on volume, duration
and single (atomic) events.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 8
1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 11 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 12
1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 13 1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 14
2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 15 2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 17
2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 17
2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 17 2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 19
2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 17 2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 20
2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18 2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 20
2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 20 2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 22
2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20 2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 22
2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 20 2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 23
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1. Authentication and Authorization Operation . . . . . . . . 22 3.1. Authentication and Authorization Operation . . . . . . . . 24
3.2. Session Start Operation . . . . . . . . . . . . . . . . . 24 3.2. Session Start Operation . . . . . . . . . . . . . . . . . 26
3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 26
3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 28
3.4.1. Unsolicited Session Termination Operation . . . . . . 26 3.4.1. Unsolicited Session Termination Operation . . . . . . 28
3.4.2. Unsolicited Change of Authorization Operation . . . . 26 3.4.2. Unsolicited Change of Authorization Operation . . . . 29
3.5. Termination Operation . . . . . . . . . . . . . . . . . . 27 3.5. Termination Operation . . . . . . . . . . . . . . . . . . 29
3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 29
3.7. Operation Considerations for Multiple Services . . . . . . 28 3.7. Operation Considerations for Multiple Services . . . . . . 30
3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 30
3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 31
3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 31
3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 32
3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 30 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 32
3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 32
3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 33
3.7.8. Accounting Considerations . . . . . . . . . . . . . . 31 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 33
3.7.9. Interoperability with Diameter Credit Control 3.7.9. Interoperability with Diameter Credit Control
Application . . . . . . . . . . . . . . . . . . . . . 31 Application . . . . . . . . . . . . . . . . . . . . . 33
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 32 4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 34
4.2. Session Termination Attribute . . . . . . . . . . . . . . 33 4.2. Session Termination Attribute . . . . . . . . . . . . . . 35
4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 34 4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 34 4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 36
4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 35 4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 37
4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 35 4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 37
4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 35 4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 37
4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 35 4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 37
4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 36 4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 38
4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 36 4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 38
4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 36 4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 38
4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 36 4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 38
4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 36 4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 38
4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 37 4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 39
4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 37 4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 39
4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 37 4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 39
4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 38 4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 40
4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 38 4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 40
4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 38 4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 40
4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 38 4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 40
4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 39 4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 41
4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 39 4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 41
4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 40 4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 42
4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 40 4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 42
4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 41 4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 43
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 41 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 43
5. Translation between RADIUS prepaid and Diameter Credit 5. Translation between RADIUS prepaid and Diameter Credit
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1. Session Identification . . . . . . . . . . . . . . . . . . 43 5.1. Session Identification . . . . . . . . . . . . . . . . . . 45
5.2. Translation between RADIUS prepaid client and Diameter 5.2. Translation between RADIUS prepaid client and Diameter
Credit Control AAA infrastructure . . . . . . . . . . . . 43 Credit Control AAA infrastructure . . . . . . . . . . . . 45
5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 43 5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 46
5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 44 5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 46
5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 44 5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 46
5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 44 5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 46
5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 45 5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 47
5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 45 5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 47
5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 46 5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 48
5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 46 5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 48
5.2.9. Volume/Duration/Resource Threshold Attributes 5.2.9. Volume/Duration/Resource Threshold Attributes
(s->c) . . . . . . . . . . . . . . . . . . . . . . . . 46 (s->c) . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 46 5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 48
5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 48 5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 50
5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 48 5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 50
5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 48 5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 50
5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 48 5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 50
5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 49 5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 51
5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 49 5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 51
5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 49 5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 51
5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 49 5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 52
5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 50 5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 52
5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 50 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 52
6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 5.3. Translation between Diameter Credit Control client and
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 RADIUS-based AAA infrastructure . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.3.1. CC-Correlation-Id Attribute ( ) . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . . 54 5.3.2. CC-Request-Number Attribute (c <-> s) . . . . . . . . 53
9.2. Informative References . . . . . . . . . . . . . . . . . . 54 5.3.3. CC-Request-Type Attribute ( ) . . . . . . . . . . . . 53
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 55 5.3.4. CC-Session-Failover Attribute ( ) . . . . . . . . . . 53
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 55 5.3.5. CC-Sub-Session-Id Attribute ( ) . . . . . . . . . . . 53
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 58 5.3.6. Check-Balance-Result Attribute ( ) . . . . . . . . . . 53
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 62 5.3.7. Cost-Information Attribute ( ) . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 5.3.8. Unit-Value Attribute ( ) . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 70 5.3.9. Exponent Attribute ( ) . . . . . . . . . . . . . . . . 53
5.3.10. Value-Digits Attribute ( ) . . . . . . . . . . . . . . 54
5.3.11. Currency-Code Attribute ( ) . . . . . . . . . . . . . 54
5.3.12. Cost-Unit Attribute ( ) . . . . . . . . . . . . . . . 54
5.3.13. Credit-Control Attribute ( ) . . . . . . . . . . . . . 54
5.3.14. Credit-Control-Failure-Handling Attribute ( ) . . . . 54
5.3.15. Direct-Debiting-Failure-Handling Attribute ( ) . . . . 54
5.3.16. Multiple-Services-Credit-Control Attribute ( ) . . . . 54
5.3.17. Granted-Service-Unit Attribute ( ) . . . . . . . . . . 54
5.3.18. Requested-Service-Unit Attribute ( ) . . . . . . . . . 54
5.3.19. Used-Service-Unit Attribute ( ) . . . . . . . . . . . 54
5.3.20. Tariff-Time-Change Attribute ( ) . . . . . . . . . . . 54
5.3.21. CC-Time Attribute ( ) . . . . . . . . . . . . . . . . 54
5.3.22. CC-Money Attribute ( ) . . . . . . . . . . . . . . . . 55
5.3.23. CC-Total-Octets Attribute ( ) . . . . . . . . . . . . 55
5.3.24. CC-Input-Octets Attribute ( ) . . . . . . . . . . . . 55
5.3.25. CC-Output-Octets Attribute ( ) . . . . . . . . . . . . 55
5.3.26. CC-Service-Specific-Units Attribute ( ) . . . . . . . 55
5.3.27. Tariff-Change-Usage Attribute ( ) . . . . . . . . . . 55
5.3.28. Service-Identifier Attribute ( ) . . . . . . . . . . . 55
5.3.29. Rating-Group Attribute ( ) . . . . . . . . . . . . . . 55
5.3.30. G-S-U-Pool-Reference Attribute ( ) . . . . . . . . . . 55
5.3.31. G-S-U-Pool-Identifier Attribute ( ) . . . . . . . . . 55
5.3.32. CC-Unit-Type Attribute ( ) . . . . . . . . . . . . . . 55
5.3.33. Validity-Time Attribute ( ) . . . . . . . . . . . . . 55
5.3.34. Final-Unit-Indication Attribute ( ) . . . . . . . . . 56
5.3.35. Final-Unit-Action Attribute ( ) . . . . . . . . . . . 56
5.3.36. Restriction-Filter-Rule Attribute ( ) . . . . . . . . 56
5.3.37. Redirect-Server Attribute ( ) . . . . . . . . . . . . 56
5.3.38. Redirect-Address-Type Attribute ( ) . . . . . . . . . 56
5.3.39. Redirect-Server-Address Attribute ( ) . . . . . . . . 56
5.3.40. Multiple-Services-Indicator Attribute ( ) . . . . . . 56
5.3.41. Requested-Action Attribute ( ) . . . . . . . . . . . . 56
5.3.42. Service-Context-Id Attribute ( ) . . . . . . . . . . . 56
5.3.43. Service-Parameter-Info Attribute ( ) . . . . . . . . . 56
5.3.44. Service-Parameter-Type Attribute ( ) . . . . . . . . . 56
5.3.45. Service-Parameter-Value Attribute ( ) . . . . . . . . 56
5.3.46. Subscription-Id Attribute ( ) . . . . . . . . . . . . 57
5.3.47. Subscription-Id-Type Attribute ( ) . . . . . . . . . . 57
5.3.48. Subscription-Id-Data Attribute ( ) . . . . . . . . . . 57
5.3.49. User-Equipment-Info Attribute ( ) . . . . . . . . . . 57
5.3.50. User-Equipment-Info-Type Attribute ( ) . . . . . . . . 57
5.3.51. User-Equipment-Info-Value Attribute ( ) . . . . . . . 57
6. Security Considerations . . . . . . . . . . . . . . . . . . . 58
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 60
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. Normative References . . . . . . . . . . . . . . . . . . . 61
9.2. Informative References . . . . . . . . . . . . . . . . . . 61
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 62
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 62
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 65
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
Intellectual Property and Copyright Statements . . . . . . . . . . 77
1. Introduction 1. Introduction
This draft describes extentions for the RADIUS protocol. These This draft describes an extension for the RADIUS protocol. This
extensions are meant to enable service providers to charge and bill extension enables service providers to charge their "prepaid
their customers using prepaid accounts. subscribers".
A prepaid service subscriber is a user who has purchased a contract A prepaid subscriber is a user who maintains a prepaid account with
according to which he will receive a particular data service for the service provider. Every time the prepaid subscriber requests a
either a period of time or a quantity of data. In the typical service, the service provider must ensure that sufficient funds
prepaid scenario, the service provider verifies that the subscriber remain in the subsriber's prepaid account before delivering the
has sufficient funds in his account before delivering the service. service. Only if suffiecient funds are available is the service
Only if suffiecient funds are available is the service provided to provided to the subscriber. This is in contrast to post-paid
the user. subscribers, where this "on-line" account check is not always
necessary. In this document, it is assumed that the prepaid
subscriber has a contract with the service provider according to
which he will receive a particular set of services for a specified
period of time, quantity of data, or number of service requests.
The business driver behind the protocol extensions defined in this The business driver behind the extension defined in this document is
document is to increase participation (i.e. a service provider's to increase participation (i.e. a service provider's subscriber base)
subscriber base) and thus to increase revenues. In particular, the and thus to increase revenues. In particular, the extensions were
extensions were designed with the following goals in mind. designed with the following goals in mind.
o Make use of existing infrastructure as much as possible (including o Make use of existing infrastructure as much as possible (including
enabling the interworking of RADIUS-based and Diameter-based the interworking of RADIUS-based and Diameter-based
infrastructures), and thereby limit the amount of necessary infrastructures), and thereby limit the amount of necessary
capital expenditures, capital expenditures,
o provide the ability to rate service requests in real-time, o provide the ability to rate service requests in real-time,
o provide the ability to charge the user's account prior to service o provide the ability to charge the user's account prior to service
provision, provision,
o protect against revenue loss, i.e. to prevent an end user from o protect against revenue loss, i.e. to prevent an end user from
obtaining service when the available funds are not sufficient, obtaining service when the available funds do not suffice,
o protect against fraud, and o protect against fraud, and
o be deployable over dialup, wired and wireless networks. o be deployable over dialup, wired and wireless networks.
The architecture between the entities that execute the RADIUS The architecture between the entities that execute the RADIUS
protocols, with the extensions defined in this document, assumes that protocol, with the extension defined in this document, assumes that
the rating of chargeable events does not occur in the element that the rating of chargeable events does not occur in the element that
provides the service. Instead, the rating may be performed at a provides the service. Instead, the rating is performed at a
dedicated server, termed the "prepaid enabled AAA server" or simply dedicated server, termed the "prepaid-enabled AAA server" or simply
"prepaid server". Alternatively, the actual rating may occur in an "prepaid server". The rating may, of course, occur in an entity
entity behind this prepaid server. Furthermore, business logic may behind this prepaid server. However, for the purposes of exposition,
dictate a time-dependent tariff model, for example that the price for in this document it is assumed that that rating occurs in the prepaid
a service may switch at 8pm from a high to a low tariff. The server. Furthermore, business logic may dictate a time-dependent
extensions defined in this document support such scenarios. tariff model, for example that the price for a service may switch at
20:00 from a high to a low tariff. The extensions defined in this
document support such scenarios.
Furthermore, this documents assumes an architecture where a "quota This documents assumes an architecture where a "quota server" is
server" is available which, through co-ordination with the rating available which, through co-ordination with the rating entity and a
entity and a centralized account balance manager, is able to provide centralized account balance manager, is able to provide a quota
a quota indication for a particular user when requested. This quota indication for a particular user when requested. This quota server
server may or may not coexist in the prepaid server. may or may not coexist in the prepaid server.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
Furthermore, this document uses the following terms: This document also makes use of the following terms:
Network Access Server (NAS): Network Access Server (NAS):
As defined in RADIUS [2]. As defined in RADIUS [2].
Prepaid client (PPC): Prepaid client (PPC):
The entity which triggers the RADIUS message exchange, including The entity which triggers the RADIUS message exchange, including
the prepaid extensions defined in this document. The PPC the prepaid extensions defined in this document. The PPC
typically resides in the NAS. typically resides in the NAS.
Prepaid Server (PPS): Prepaid Server (PPS):
The entity that interacts with the PPC using the RADIUS prepaid The entity that interacts with the PPC using the RADIUS prepaid
extensions defined in this document. extensions defined in this document. It also provides the
functionality of a rating server and a quota server. This is done
either by the PPS itself, or in coordination with dedicated
backend servers. For simplicity of exposition, this document
assumes that the functionality of both the rating and the quota
server is provided by the PPS.
Home Network: Home Network:
The network which contains the user profile and the user's prepaid The network which contains the user profile and the user's prepaid
account. account.
RADIUS Prepaid (RPP):
The RADIUS base protocol together with the extension defined in
this document.
Diameter Credit Control (DCC):
The Diameter Credit Control Application.
1.2. Overview 1.2. Overview
This section provides an overview of the prepaid charging models and This section provides an overview of the prepaid charging models and
architectures, which are supported by the extensions described in architectures, which are supported by the extensions described in
this draft. this draft.
A number of models of how to charge customers for data services in a A number of models of how to charge customers for data services in a
prepaid manner are supported, as follows. prepaid manner are supported, as follows.
o Volume-based charging: (e.g. 2 Cents/KiloByte). o Volume-based charging: (e.g. 2 Cents/KiloByte).
o Duration-based charging: (e.g. 3 Cents/minute). o Duration-based charging: (e.g. 3 Cents/minute).
o Subscription-based charging: (e.g. Dollars/month). o Subscription-based charging: (e.g. Dollars/month).
o Event-based charging: (e.g. 7 Cents/URL or email) . o Event-based charging: (e.g. 7 Cents/URL or email) .
This draft assumes that the user maintains a prepaid account with his This document assumes that the user maintains a prepaid account with
home network. However, whether this account is a dedicated prepaid his home network. However, whether this account is a dedicated
account or not (such as a current bank account) is outside the scope prepaid account or not (such as a current bank account) is outside
of this document. Similarly, the means by which the subscriber the scope of this document. Similarly, the means by which the
obtains funds is also outside the scope of this document. In some subscriber obtains funds is also outside the scope of this document.
scenarios, the subscriber's account may be used to fund multiple In some scenarios, the subscriber's account may be used to fund
services, some of which may use the extensions defined in this multiple services, some of which may use the extensions defined in
documents, and some may use other mechanisms. While the interworking this documents, and some may use other mechanisms. While the
of the mechanisms described in this document with other mechanisms interworking of the mechanisms described in this document with other
should be possible and straightforward, the specification of how this mechanisms should be possible and straightforward, the specification
could be done depends on the external mechanisms and is, as such, of how this could be done depends on the external mechanisms and is,
outside the scope of this document. as such, outside the scope of this document.
1.2.1. Architectural Model 1.2.1. Architectural Model
The protocol extensions described in this draft assumes that the The protocol extensions described in this document assumes that the
following entities are present in the network architecture. following entities are present in the network architecture.
o Service Access Device (SAD): This entity provides a data service o Service Access Device (SAD): This entity provides a data service
to the users, and typically coincides with the NAS. The SAD to the users, and typically coincides with the Network Access
executes the RADIUS client which, for the purposes of this Server (NAS), as this is defined in [2]. The SAD executes the
document, is termed the "PrePaid Client" (PPC). When the prepaid RADIUS client which, for the purposes of this document, is termed
service is used the SAD collects service event information and the "PrePaid Client" (PPC). When the prepaid service is used, the
reports it while or after services are provided to the user. This SAD collects service event information and reports it while or
event information is sent to the PPS using the extensions defined after services are provided to the user. This event information
in this document. is sent to the PPS using the extensions defined in this document.
o The PPS: The RADUIS server that supports the prepaid extensions o The PPS: The RADUIS server that supports the prepaid extensions
defined in this document. If real-time credit control is defined in this document. If real-time credit control is
required, the PPC (SAD) contacts the PPS with service event required, the PPC (SAD) contacts the PPS with service event
information included before the service is provided. The PPS information included before the service is provided. The PPS
performs a credit check and allocates a portion of available performs a credit check and allocates a portion of available
credit to the service event. credit to the service event.
o The rating entity: This entity converts the credit that is o The rating and quota server: This server allocates an amount of
allocated by the PPS into a time or volume amount, called the credit to the user. This credit is converted into an amount of
"quota". This quota is then returned to the requesting PPC (SAD) time or volume, called the "quota". This quota is then returned
(via the PPS). The rating entity may also determine that during to the requesting PPC (SAD) (via the PPS). The rating entity may
service provision a tariff switch will occur. In this case the also determine that during service provision a tariff switch will
rating entity will include details of when exactly tariff switch occur. In this case, the rating entity also includes information
will occur. of when exactly this tariff switch occurs into the message that is
sent to the PPS.
The requesting SAD (PPC) monitors the provision of the service The requesting SAD (PPC) monitors the provision of the service
according to the instructions returned by the PPS. After service according to the instructions returned by the PPS. After service
completion or on a subsequent request for service, the PPS deducts completion or on a subsequent request for service, the PPS deducts
the corresponding amount of credit from the user account. When a the amount of credit that corresponds to the consumed service from
user terminates an on-going service, the PPC informs the PPS with a the user account. When a user terminates an on-going service, the
suitable indication about the unused portion of the allocated quota. PPC informs the PPS with a suitable indication about the unused
The PPS is then able to refund the user account appropriately. portion of the allocated quota. The PPS is then able to refund the
user account appropriately.
Multiple PPSs may be deployed for reasons of redundancy and load Multiple PPSs may be deployed for reasons of redundancy and load
balancing. The system MAY also employ multiple rating servers. balancing. The system MAY also employ multiple rating servers.
Prepaid accounts may be located in a centralized database. The Prepaid accounts may be located in a centralized database. The
detailed architecture of the system and its interfaces are outside detailed architecture of the system and its interfaces are outside
the scope of this specification. the scope of this specification.
accounting accounting
+------------+ +-----------+ protocol +--------------+ +------------+ +-----------+ protocol +--------------+
| User |<---------->| Service | | | | User |<---------->| Service | | |
| | IEEE 802.1x| Access |<------------>| Accounting | | | IEEE 802.1x| Access |<------------>| Accounting |
| Device | PANA | Device |<-----+ | Server | | Device | PANA | Device |<-----+ | Server |
+------------+ IKEv.2 +-----------+ | +--------------+ +------------+ IKEv2 +-----------+ | +--------------+
... etc (PPC) | ... etc (PPC) |
| |
| +--------------+ | +--------------+
+------>| Prepaid | +------>| Prepaid |
prepaid | Server | prepaid | Server |
protocol +--------------+ extension +--------------+
Figure 1: Basic prepaid architecture Figure 1: Basic prepaid architecture
The PPS and the accounting server in this architecture are logical The PPS and the accounting server in this architecture are logical
entities. The real configuration MAY combine them into a single entities. The real configuration MAY combine them into a single
host. host. The SAD must be able to meter the consumption of resources
(e.g. time or volume) for a prepaid data session.
The SAD must have the ability to meter the usage for a prepaid data
session. This usage includes time or volume (e.g. number of bytes).
The device running the PPC may also have "Dynamic Session The device running the PPC may also have "Dynamic Session
Capabilities" such as the ability to terminate a data session or Capabilities" such as the ability to terminate a data session or
change the filters associated with a specific data session by change the filters associated with a specific data session by
processing "Disconnect" messages and "Change of Authorization" processing "Disconnect" messages and "Change of Authorization"
messages as per RFC 3576. messages, as specified in RFC 3576.
This document assumes that the PPS is used as the AAA server. There There exist three types of AAA server, as follows.
are three types of AAA server, as follows.
o The AAA server in the home network (HAAA), which is responsible o The AAA server in the home network (HAAA), which is responsible
for authentication of the subscriber. In addition, the HAAA for authentication of the subscriber. In addition, the HAAA
communicates with the PPS using the RADIUS protocol in order to communicates with the PPS using the RADIUS protocol in order to
authorize subscribers. authorize subscribers.
o The AAA server in the visited network (VAAA) which exists only in o The AAA server in the visited network (VAAA) which exists only in
roaming scenarios and is responsible for forwarding the RADIUS roaming scenarios and is responsible for forwarding the RADIUS
messages to the HAAA. The VAAA may also modify the messages. messages to the HAAA. The VAAA may also modify the messages.
Note that, in certain roaming deployments, the visited network may Note that, in certain roaming deployments, the visited network may
be connected to the home network via one or more broker networks. be connected to the home network via one or more broker networks.
o The AAA server in one of the aforementioned broker networks o The AAA server in one of the aforementioned broker networks
(BAAA), which is responsible for forwarding messages and does not (BAAA), which is responsible for forwarding messages and does not
play an active role in the prepaid data service delivery. A BAAA play an active role in the prepaid data service delivery. A BAAA
obviously exists only in those roaming deployments where the VAAA obviously exists only in those roaming deployments where the VAAA
and the HAAA are connected via the BAAA of a broker network. and the HAAA are connected via the BAAA server of a broker
network.
This document assumes that the PPS communicates with the HAAA for the This document assumes that the PPS is used as the HAAA server. Of
purposes of authorisation. Additionally, the PPS interfaces to course, in reality, the PPC may communicates with the HAAA for the
entities which purposes of authorisation. As mentioned earlier, the PPS is also
assumed to
o keep the subscriber's account balance (balance manager), o keep the subscriber's account balance (balance manager),
o rate access service requests in real-time (Rating Engine), and o rate access service requests in real-time (rating server), and
o manage quota for a particular prepaid service (Quota Server). o manage quota for a particular prepaid service (quota server).
Of course, the balance manager, rating server, and quota server may
be separate entities that have an interface with the PPC and that act
in coordination with the PPC.
Three deployment scenarios are presented in the remainder of this Three deployment scenarios are presented in the remainder of this
section. The first scenario is depicted in Figure 2. In this section. The first scenario is depicted in Figure 2. In this
scenario, the SAD, which runs the PPC, the HAAA, and the PPS are scenario, the SAD (which runs the PPC), the HAAA, and the PPS are
located in the same provider network. located in the same administrative domain.
The subscriber's device establishes a connection with one of possibly The subscriber's device establishes a connection with one of possibly
multiple SADs in the network. The selected SAD communicates with a multiple SADs in the network. The selected SAD communicates with a
HAAA server (directly or indirectly). HAAA server (directly or indirectly).
The interface between the HAAA and the PPS is implemented using the The interface between the HAAA and the PPS is implemented using the
RADIUS protocol together with the extensions described in this RADIUS protocol together with the extensions described in this
document. However, in cases where the PPS does not implement the document. However, in cases where the PPS does not implement the
RADIUS protocol, the implementation would have to map the RADIUS protocol, the implementation would have to map the
requirements defined in this document to a functionally equivalent requirements defined in this document to a functionally equivalent
skipping to change at page 10, line 21 skipping to change at page 11, line 49
| Device | | Device | | +------+ | +-----+ | Device | | Device | | +------+ | +-----+
| | | | | | | | | | | | | | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | |
+------+ +-----+ +------+ +-----+
Figure 2: Basic prepaid access architecture Figure 2: Basic prepaid access architecture
The second scenario, depicted in Figure 3, is based on a static The second scenario, depicted in Figure 3, is based on a static
roaming architecture that is typical of a wholesale scenario for roaming architecture that is typical of a wholesale scenario for
Dial-Up users or a broker scenario used in Dial-Up or WLAN roaming dial-up users or a broker scenario used in dial-up or WLAN roaming
scenarios. scenarios.
+----+ +----+ +----+ +-----+ +----+ +----+ +----+ +-----+
| | | | | | | | | | | | | | | |
+------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Sub | |Service| | +----+ | +----+ | +----+ | +-----+ |Sub | |Service| | +----+ | +----+ | +----+ | +-----+
| |--|Access |-+ | | | | |--|Access |-+ | | |
|Device| |Device | | +----+ | +----+ | +----+ | +-----+ |Device| |Device | | +----+ | +----+ | +----+ | +-----+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
skipping to change at page 11, line 4 skipping to change at page 12, line 32
using the RADIUS protocol with BAAA servers in the broker network. using the RADIUS protocol with BAAA servers in the broker network.
There may be more than one Broker Network between the Visited Network There may be more than one Broker Network between the Visited Network
and the Home Network. The Home Network is the same as in the and the Home Network. The Home Network is the same as in the
architecture depicted in Figure 2. architecture depicted in Figure 2.
Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) Broker AAA (BAAA) servers MUST support the Message-Authenticator(80)
attribute as defined in RFC 2869. If they are used, they forward the attribute as defined in RFC 2869. If they are used, they forward the
RADIUS packets as usual to the appropriate RADIUS servers. RADIUS packets as usual to the appropriate RADIUS servers.
Accounting messages are not needed to deliver a prepaid service. Accounting messages are not needed to deliver a prepaid service.
However, accounting messages can be used to keep the PPS up to date However, accounting messages can be used to keep the PPS up to date
as to what is happening with the prepaid data session. Therefore, a as to what is happening with the prepaid data session. Therefore, a
BAAA SHOULD deliver RADIUS Accounting messages using the pass through BAAA SHOULD deliver RADIUS Accounting messages using the pass through
mode described in RFC 2866. mode described in RFC 2866.
1.2.2. Motivation 1.2.2. Motivation
Why not use existing RADIUS attributes to construct a protocol for Why not use existing RADIUS attributes to construct a protocol for
prepaid scenarios? This could lead to a solution where no code has prepaid charging? This could lead to a solution where no code has to
to be modified at existing devices. be modified at existing devices.
It is indeed possible to construct a solution for prepaid billing It is indeed possible to construct a solution for prepaid charging
scenarios using existing RADIUS attributes. The RADIUS server would scenarios using existing RADIUS attributes. The RADIUS server would
send an Access-Accept message containing a Session-Timeout(27) and send an Access-Accept message containing a Session-Timeout(27) and
include a Termination-Action(29) in the RADIUS-request. Upon include a Termination-Action(29) in the RADIUS-request. Upon
receiving the Access-Accept message, the NAS would meter the duration receiving the Access-Accept message, the NAS would meter the duration
of the session and upon termination of the session the NAS would of the session and upon termination of the session the NAS would
generate an Access-Request message again. The RADIUS server would generate an Access-Request message again. The RADIUS server would
then re-authenticate the session and reply with an Access-Accept then re-authenticate the session and reply with an Access-Accept
message indicating the amount of additional time in a Session- message indicating the amount of additional time in a Session-
Timeout(27). Alternatively, it could respond with an Access-Reject Timeout(27). Alternatively, it could respond with an Access-Reject
message if there were no more resources in the user account. message if there were no more resources in the user account.
Moreover, if the user terminates the session prematurely, the NAS Moreover, if the user terminates the session prematurely, the NAS
could indicate this in the accounting stream so that unused funds can could indicate this in the accounting stream so that unused funds can
be returned into the prepaid user account. be returned into the prepaid user account.
Unfortunately, the above "solution" has a number of problems, Unfortunately, the above "solution" has a number of shortcomings,
including the following. including the following.
o It only supports time-based accounting. The solution presented in o It only supports time-based rating. The solution presented in
this document supports both time and volume based prepaid. this document supports both time and volume based prepaid.
o Using accounting messages to recoup unused time may be problematic o Using accounting messages to recoup unused time may be problematic
because RADIUS accounting messages are not delivered in real-time. because it is not required that RADIUS accounting messages are
A RADIUS server may store-and-forward accounting messages in delivered in real-time. A RADIUS server may store-and-forward
batches. Thus, relying on accounting messages for the purposes of accounting messages in batches. Thus, relying on accounting
prepaid may cause revenue leakage. The solution presented in this messages for the purposes of prepaid charging may cause revenue
document does not rely on Accounting packets at all. It uses leakage. The solution presented in this document does not rely on
Access-Request messages, which are required to flow through any Accounting packets at all. It uses Access-Request messages, which
network in real-time. are required to flow through the network in real-time.
o Session-Timeout(27) is not a mandatory attribute. If a prepaid o Session-Timeout(27) is not a mandatory attribute. If a prepaid
subscriber is being serviced by a NAS that does not adhere to subscriber is being serviced by a NAS that does not adhere to
Session-Timeout then that subscriber may use the service for an Session-Timeout then that subscriber may use the service for an
undetermined period of time. undetermined period of time.
o Termination-Action(29) presents its own issues. Firstly the o Termination-Action(29) presents its own issues. Firstly, the
behaviour of Termination-Action(29) is not mandatory. Secondly, support of Termination-Action(29) is not mandatory. Secondly,
according to RFC 2865, Termination-Action fires when the provision according to RFC 2865, Termination-Action fires when the provision
of the service has completed. However, service should not be of the service has completed. However, service should not be
terminated when negotiating additional quota, because this should terminated when negotiating additional quota, because this should
happen in a manner transparent to the subscriber. Due to the fact happen in a manner transparent to the subscriber. Due to the fact
that Termination-Action occurs when the service is completed, it that Termination-Action occurs when the service is completed, it
is unclear whether or not user experience would be affected if is unclear whether or not the user experience would be affected if
this attribute would be used in a prepaid scenario. The RADIUS this attribute would be used as a means to request additional
server might even allocate a new IP address to the subscriber quota in a prepaid charging context. The RADIUS server might even
device after a Termination-Action. Also, the RADIUS server has no allocate a new IP address to the subscriber device after a
way of telling why a given Access-Request message was generated. Termination-Action. Also, the RADIUS server has no way of telling
The RADIUS server might have to wait for the corresponding why a given Access-Request message was generated. The RADIUS
accounting packet to determine the reason. Finally, re- server might have to wait for the corresponding accounting packet
authenticating the subscriber may take too long. The solution to determine the reason. Finally, re-authenticating the
presented in this document allows quota replenishing to occur subscriber may take too long. The solution presented in this
without affecting user experience. No re-authentication is document allows quota replenishing to occur without affecting user
required and quotas can be negotiated before the available credit experience. No re-authentication is required and quotas can be
actually runs out. negotiated before the available credit actually runs out.
o Due to the fact that the standard RADIUS attributes are not o Due to the fact that the standard RADIUS attributes are not
mandatory, the correct prepaid operation is really an act of faith mandatory, the correct prepaid operation is really an act of faith
on the part of the RADIUS server. If Session-Timeout(27) and/or on the part of the RADIUS server. If Session-Timeout(27) and/or
Termination-Action(29) are not supported, the prepaid subscriber Termination-Action(29) are not supported, the prepaid subscriber
might be able to obtain the service for free. The solution might be able to obtain the service for free. The solution
described in this document requires that a prepaid-aware SAD described in this document requires that a prepaid-aware SAD
informs the RADIUS server, regardless of whether or not the latter informs the RADIUS server, regardless of whether or not the latter
supports the prepaid extensions. The RADIUS server can then supports the prepaid extensions. The RADIUS server can then
determine whether or not service should be granted. For example, determine whether or not service should be granted. For example,
if a prepaid subscriber is connected to a NAS that does not if a prepaid subscriber is connected to a NAS that does not
support prepaid, the RADIUS server can either instruct the NAS to support prepaid, the RADIUS server can either instruct the NAS to
tunnel the traffic to another entity in the home network (e.g. the tunnel the traffic to another entity in the home network (e.g. the
Home Agent) that supports prepaid, or it provide only a restricted Home Agent) that supports prepaid, or to provide only a restricted
service. service.
The solution presented in this document requires the support of two The solution presented in this document requires the support of two
mandatory and one optional attribute. Furthermore, it does not mandatory and one optional attribute. Furthermore, it does not
require a great amount of additional code at a NAS that already require a great amount of additional code at a NAS that already
supports time or volume metering. The solution requires that RADIUS supports time or volume metering. The solution requires that RADIUS
entities advertise their prepaid capabilities in an Access-Request entities advertise their prepaid capabilities in an Access-Request
and that they generate an Access-Request Authorize-Only packet to and that they generate an Access-Request packet in order to obtain
obtain more quota when or before the current quota is used up. It more quota when or before the currently allocated quota is consumed.
also requires the NAS to send an Access-Request with Authorize-Only It also requires the NAS to send an Access-Request when the session
when the session terminates in order to refund the subscriber terminates in order to refund the subscriber account.
account.
1.3. A simple use case 1.3. A simple use case
This section describes the sequence of events in a simple RADIUS This section describes the sequence of events in a simple RADIUS
prepaid transaction. prepaid transaction.
1. When an end host attaches to a network (for example, using PPP or 1. When an end host attaches to a network (for example, using PPP or
PANA), as usual, the NAS (SAD) that is servicing the subscriber PANA), as usual, the NAS (SAD) that is serving the subscriber
uses the AAA infrastructure to authenticate and authorize the uses the AAA infrastructure in order to authenticate and
subscriber (if such network accesss authentication is required). authorize the subscriber (if such network accesss authentication
is required).
2. The SAD sends a RADIUS Access-Request to the AAA server in order 2. The SAD sends a RADIUS Access-Request to the AAA server in order
to authenticate and authorise the subscriber with respect to the to authenticate and authorise the subscriber with respect to the
requested service. The Access-Request contains the subscriber's requested service. The Access-Request contains the subscriber's
credentials and may contain the prepaid capabilities of the SAD. credentials and may contain the prepaid capabilities of the SAD.
Prepaid capabilities MUST be included if the SAD supports them. Prepaid capabilities MUST be included if the SAD supports them.
3. The authentication procedure proceeds. This may involve several 3. The authentication procedure proceeds. This may involve several
message exchanges such as in EAP [RFC2284]. Once the subscriber message exchanges such as in EAP [RFC2284]. Once the subscriber
has been successfully authenticated, the home AAA server has been successfully authenticated, the home AAA server
skipping to change at page 13, line 35 skipping to change at page 15, line 12
requests authorisation from the PPS. The request MUST include requests authorisation from the PPS. The request MUST include
the prepaid capabilities of the serving SAD. the prepaid capabilities of the serving SAD.
4. The PPS validates that the subscriber has a prepaid account and 4. The PPS validates that the subscriber has a prepaid account and
that the account is active. It further validates that the SAD that the account is active. It further validates that the SAD
has the appropriate prepaid capabilities. If all is in order, has the appropriate prepaid capabilities. If all is in order,
the PPS authorises the subscriber to use the network. Otherwise the PPS authorises the subscriber to use the network. Otherwise
it rejects the request. The decision is sent to the AAA system. it rejects the request. The decision is sent to the AAA system.
The response includes attributes to indicate the allocation of a The response includes attributes to indicate the allocation of a
portion of the subscriber credit. This portion is called the portion of the subscriber credit. This portion is called the
"initial quota" (in units of time or volume) and optionally a "initial quota" and is expressed in units of time or volume, and
threshold value. Note that only a portion of the user's funds is may also include an optional threshold value. Note that only a
allocated because the user may be engaged in other services that portion of the user's funds is allocated because the user may be
may draw on the same account. For example, the user may be engaged in other services that may draw on the same account. For
engaged in a data session and a voice session. Although these example, the user may be engaged in a data session and a voice
two services would draw from the same account, they form separate session. Although these two services draw from the same account,
parts of the overall system. If the entire quota was allocated they form separate parts of the overall system. If the entire
to the data session then the user would have no more funds for a quota was allocated to the data session then the user would have
voice session. no more funds for a voice session.
5. The AAA system incorporates the attributes received from the PPS 5. The AAA system incorporates the attributes received from the PPS
into an Access-Accept message that it sends to the SAD. Note into an Access-Accept message that it sends to the SAD. Note
that the AAA system is responsible for authorizing the service that the AAA system is responsible for authorizing the service
whereas the prepaid system is responsible for prepaid whereas the prepaid system is responsible for prepaid
authorization. authorization.
6. Upon receiving the Access-Response, the SAD starts the prepaid 6. Upon receiving the Access-Response, the SAD starts the prepaid
data session and meters the session based on time or volume, as data session and meters the session based on time or volume, as
indicated in the message. indicated in the message.
7. Once the usage for the session approaches the allocated limit (as 7. Once the consumption of the service approaches as certain point
expressed by the threshold), the SAD will request additional (e.g. as expressed by the threshold), the SAD will request
quota. Re-authorization for additional quota flows through the additional quota. Re-authorization for additional quota flows
AAA system to the PPS. The PPS revalidates the subscriber through the AAA system to the PPS. The PPS revalidates the
account and subtracts the previously allocated quota from the subscriber account and subtracts the previously allocated quota
current balance. If there is remaining balance, it reauthorizes from the current balance. If there is remaining balance, it
the request with an additional quota allotment. Otherwise, the authorizes the request with an additional quota allotment.
PPS rejects the request. Note that the replenishment of the Otherwise, the PPS rejects the request. Note that the
quota is a re-authorization procedure and does not require the replenishment of the quota is a re-authorization procedure and
subscriber to authenticate himself again. does not require the subscriber to authenticate himself again.
8. Upon receiving a re-allotment of the quota, the SAD continues to 8. Upon receiving the new quota, the SAD continues to provide the
provide the data service until the new threshold is reached. If data service until the new threshold is reached. If the request
the request for additional quota cannot be fulfilled then the SAD for additional quota cannot be fulfilled then the SAD lets the
lets the subscriber use the remaining quota and terminates the subscriber use the remaining quota and terminates the session.
session. Alternatively, instead of terminating the session, the Alternatively, instead of terminating the session, the SAD may
SAD may restrict the data session such that the subscriber can restrict the data session such that the subscriber can only reach
only reach a particular web server. This web server maybe used a particular web server. This web server may be used to enable
to allow the subscriber to replenish his account. This the subscriber to replenish his account. This restriction can
restriction can also be used to allow new subscribers to set up also be used to allow new subscribers to set up prepaid accounts
prepaid accounts in the first place. in the first place.
9. Should the subscriber terminate the session before the quota is 9. If the subscriber terminates the session before the allocated
exhausted, the remaining balance allotted to the session MUST be quota is entirely consumed, the credit that corresponds to the
refunded into his account. portion of the quota that was not consumed, MUST be refunded into
his account.
Note that the subscriber may have disconnected while the Access Note that the subscriber may have disconnected while the access
Device is waiting for the initial quota. The entire allocated quota device is waiting for the initial quota. The entire allocated quota
will be credited back to the subscribers account in this case. Also must be refunded to the subscribers account in this case. Also note
note that the PPS maintains session state for the subscriber. This that the PPS maintains session state for the subscriber. This state
state includes how much account balance was allocated during the last includes how much account balance was allocated during the last quota
quota enquiry and how much is left in the account. Therefore, it is enquiry and how much is left in the account. Therefore, it is
required that all messages about the session reach the same (and required that all messages about the session reach the same (and
correct) PPS. correct) PPS.
For a simple message flow, along the lines of this use case, please For a simple message flow, along the lines of this use case, see
see Appendix A. Appendix A.
2. Supported Features 2. Supported Features
This section describes the features that are supported by the prepaid This section describes the features that are supported by the prepaid
extensions defined in this draft. extensions defined in this draft.
2.1. Multiple Concurrent Services 2.1. Multiple Concurrent Services
Examples of services that the user may be using are browsing the web, Browsing the web, participating in a VoIP conversation, watching
participating in a VoIP conversation, watching streaming video and streaming video, and downloading a file are examples of services that
downloading a file. Some operators may want to distinguish between the user may wish to use. Some operators may want to distinguish
these services. Some services are chaged at different rates and between these services in terms of charging. Some services may have
services may be metered differently. Therefore, the prepaid solution to be charged at different rates, and may have to be metered
needs to be able to distinguish services, and allocate quota to the differently. Therefore, the prepaid solution needs to be able to
services using different unit types (time, volume) and allow for distinguish services, and allocate quota to the services using
those quotas to be consumed at different rates. different unit types (time, volume) and allow for those quotas to be
consumed at different rates.
+---------+ +---------+
| Session | | Session |
+---------+ +---------+
| 1 | 1
V N V N
+--------------+ 1 : 1 +-------+ +--------------+ 1 : 1 +-------+
| Service |------>| Quota | | Service |------>| Quota |
| (service-Id) | +-------+ | (service-Id) | +-------+
+--------------+ +--------------+
Figure 4: Multiple services within a single session Figure 4: Multiple services within a single session
As shown in Figure 4, a session may be associated with multiple (N) As shown in Figure 4, a single RADIUS prepaid session may be
services. Each service is identified by a service identifier associated with multiple (N) services. Each service is identified by
(Service-ID). The format of the Service-ID is not in the scope of a service identifier (Service-ID). The format of the Service-ID is
this document but it could be expressed as an IP flow using the not in the scope of this document but it could be expressed as an IP
5-tuple {Source-IP and Port, Destination-IP and Port, protocol type}. flow using the 5-tuple {Source-IP and Port, Destination-IP and Port,
Each service is associated with a quota metric. An example message protocol type}. Each service is associated with a quota metric. An
flow that involves multiple such services within a single session is example message flow that involves multiple such services within a
given in the appendix. single session is given in the appendix.
2.2. Resource Pools 2.2. Resource Pools
When working with multiple services a new problem arises because one When working with multiple services a new problem arises because one
service may consume its quota faster than another service. When the service may consume its quota faster than another service. When the
user balance is close to exhaustion, a situation could arise where user balance is close to exhaustion, a situation could arise where
one service is unable to obtain quota while another service has one service is unable to obtain quota while another service has
plenty of quota remaining. Unless the quotas can be rebalanced, the plenty of quota remaining. Unless the quotas can be rebalanced, the
SAD would then have to terminate the former service. Moreover, if SAD would then have to terminate the former service. Moreover, it is
each service generates a certain amount of RADIUS prepaid traffic. likely that each service generates a certain amount of RADIUS prepaid
In an environment with many users and chargarble services, this traffic. In an environment with many users and charged services,
amount of traffic is considerable and could leads inefficiency. this amount of traffic may become a considerable overhead that could
lead to inefficiency.
One method to circumvent the above situation is to use a so-called One method to circumvent the above situation is to use a so-called
"resource pool". Resource pools enable the allocation of resources "resource pool". Resource pools enable the allocation of resources
to multiple services of a session by allocating resources to a pool to multiple services of a session by allocating resources to a pool
and have services draw their quota from the pool at a rate and have services draw their quota from the pool at a rate
appropriate to that service. When the quota that has been allocated appropriate to that service. When the quota that has been allocated
to the pool is close to exhaustion, the entire pool (rather than to the pool is close to exhaustion, the entire pool (rather than
individual services) is replenished. individual services) is replenished.
+-----------+ +-----------+
skipping to change at page 16, line 46 skipping to change at page 18, line 48
Poolr <= Ca*Ma + Cb*Mb + . . ., Poolr <= Ca*Ma + Cb*Mb + . . .,
Figure 6 Figure 6
where Ca and Cb are resources consumed by Service-A and Service-B where Ca and Cb are resources consumed by Service-A and Service-B
respectively. respectively.
Note that the resources assigned to the pool are not associated with Note that the resources assigned to the pool are not associated with
a metric. That is, Service-A can be rated at $1 per MB and Service-B a metric. That is, Service-A can be rated at $1 per MB and Service-B
can rated at $0.10 per minute. In this case if $5 worth of resources can rated at $0.10 per minute. In this case, if $5 worth of
are allocated for service-A to the pool and if Ma = 10, then 50 units resources are allocated for service-A to the pool and if Ma = 10,
would be placed into the pool. If a further $5 are allocated for then 50 units would be placed into the pool. If a further $5 are
service-B to the pool, then M=1 and 50 units are deposited into the allocated for service-B to the pool, then M=1 and 50 units are
pool. The pool would then have a total sum of 100 units to be shared deposited into the pool. The pool would then have a total sum of 100
between the two services. The PPC would then mater the services such units to be shared between the two services. The PPC would then
that each Mbyte used by Service-A will draw 10 units from the pool mater the services such that each Mbyte used by Service-A will draw
and each minute used by Service-B will draw 1 unit from the pool. 10 units from the pool and each minute used by Service-B will draw 1
unit from the pool.
2.3. Complex Rating Functions 2.3. Complex Rating Functions
The rating of a service can be quite complex. While some operators The rating of a service can be quite complex. While some operators
follow linear pricing models, others may wish to apply more complex follow linear pricing models, others may wish to apply more complex
functions. For example, a service provider may wish to rate a functions. For example, a service provider may wish to rate a
service such that the first N MBytes are free, then the next M Mbytes service such that the first N MBytes are free, then the next M Mbytes
are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50
per MB. Such a function could be implemented by repeated message per MB. Such a function could be implemented by repeated message
exchanges with the prepaid system. exchanges with the prepaid system.
skipping to change at page 18, line 17 skipping to change at page 20, line 22
one-time service event is the purchase of a subscription. one-time service event is the purchase of a subscription.
For a given user, one-time-based charging may occur in parallel with For a given user, one-time-based charging may occur in parallel with
other charging models. For example, the subscriber may access a other charging models. For example, the subscriber may access a
website which is metered (based on time or volume) while he also website which is metered (based on time or volume) while he also
purchases the right to use a ring tone (a one-time-based event). purchases the right to use a ring tone (a one-time-based event).
Note: it is up to the service providers to decide whether or not the Note: it is up to the service providers to decide whether or not the
user will be charged for the download of the tone and also be charged user will be charged for the download of the tone and also be charged
for the time and volume required to download the ring-tone. The for the time and volume required to download the ring-tone. The
facilities provided by this document gives the service provider the facilities provided by this document gives the service provider the
capability to achieve their service charging business goals. For ability to achieve their service charging business goals. For
example, should the service provider choose not to charge for the example, should the service provider choose not to charge for the
download volume or time, then they can treat the download IP flow as download volume or time, then they can treat the download IP flow as
a separate service that is not subject to charging. a separate service that is not subject to charging.
The SAD signals one-time-based charging to the PPS with an indication The SAD signals one-time-based charging to the PPS with an indication
that identifies the service and the units that should be debited from that identifies the service and the units that should be debited from
the user account. the user account.
A SAD may decide to perform one-time-based charging for an event that A SAD may decide to perform one-time-based charging for an event that
was triggered by an unauthenticated user. In this case case the SAD was triggered by an unauthenticated user. In this case case the SAD
skipping to change at page 18, line 40 skipping to change at page 20, line 45
Note that one-time-based charging can also be used to credit the Note that one-time-based charging can also be used to credit the
prepaid account. For example, the SAD can return resources to the prepaid account. For example, the SAD can return resources to the
subscriber by issuing a one-time charge request that includes the subscriber by issuing a one-time charge request that includes the
amount of resources to be credited into the account. amount of resources to be credited into the account.
2.5. Tariff Switching 2.5. Tariff Switching
The PPC and the PPS may support tariff switching. For example, as The PPC and the PPS may support tariff switching. For example, as
shown in Figure 8, traffic before 18:00 may be rated at rate r1 and shown in Figure 8, traffic before 18:00 may be rated at rate r1 and
traffic after 18:00 is rated at rate r2. The PPC reports usage traffic after 18:00 is rated at rate r2. The PPC reports two
before and after the switch occurs. Tariff switching does not make indications about the consumed quota: one before and one after the
sense for services that are metered based on time, and the tariff switch occurred.
consumption of which is continuous (i.e. without interruption).
18:00 18:00
------------------+----------------- ------------------+-----------------
r1 | r2 r1 | r2
------------------+----------------- ------------------+-----------------
^ ^ ^ ^
|<----TSI---> | |<----TSI---> |
| | | |
Access-Accept Access-Request Access-Accept Access-Request
(quota allocated) (quota consumed) (quota allocated) (quota consumed)
skipping to change at page 20, line 6 skipping to change at page 22, line 6
When a TITSU is specified in the PTS, the PPC MUST generate an When a TITSU is specified in the PTS, the PPC MUST generate an
Access-Request within the time after TSI and before TITSU expires. Access-Request within the time after TSI and before TITSU expires.
Note that, typically, the PPC will be triggered by the Volume Note that, typically, the PPC will be triggered by the Volume
Threshold. However, it is possible that, during period r2, resources Threshold. However, it is possible that, during period r2, resources
are not entirely consumed and, thus, the threshold is not reached. are not entirely consumed and, thus, the threshold is not reached.
Even in this case PPC MUST generate an Access-Request in good time. Even in this case PPC MUST generate an Access-Request in good time.
Also note that separate services flows may have individual tariff Also note that separate services flows may have individual tariff
periods. periods.
Note that it makes no sense to use this tariff switching mechanism
for services that are charged based on time, and that are consumed
continuously (i.e. without interruption). This is because the PPS
can rate these services without the help of the PPC, i.e. it can
calculate how much of the service was consumed in each tariff period
based on its local clock.
2.6. Support for Roaming 2.6. Support for Roaming
In certain networks it is essential for prepaid data services to be In certain networks it is essential for prepaid data services to be
available to roaming subscribers. Support for both static and available to roaming subscribers. Support for both static and
dynamic roaming models is needed. In a static roaming scenario the dynamic roaming models is needed. In a static roaming scenario the
subscriber connects to a foreign network which has a roaming subscriber connects to a foreign network which has a roaming
agreement either directly with the home network, or through a broker agreement either directly with the home network, or through a broker
network. When the subscriber logs into another foreign network, a network. When the subscriber logs into another foreign network, a
new login procedure has to be executed. new login procedure has to be executed.
skipping to change at page 20, line 37 skipping to change at page 22, line 44
support the prepaid extensions. Even in this case the system should support the prepaid extensions. Even in this case the system should
be able to continue the prepaid session. be able to continue the prepaid session.
2.7. Dynamic Termination 2.7. Dynamic Termination
When fraud or an error is detected, either only the affected session, When fraud or an error is detected, either only the affected session,
or all sessions of the affected subscriber should be immediately or all sessions of the affected subscriber should be immediately
terminated. It may further happen that the prepaid system enters a terminated. It may further happen that the prepaid system enters a
state where it is unclear whether or not the data session is in state where it is unclear whether or not the data session is in
progress. Under certain conditions, the system may wish to terminate progress. Under certain conditions, the system may wish to terminate
the session in order to make sure that the user is not charged for the session in order to ensure that the user is not charged for this
this potential inactivity. potential inactivity.
Certain handoff procedures used in dynamic roaming scenarios require Certain handoff procedures used in dynamic roaming scenarios require
that the system terminates the subscribers prepaid data session at a that the system terminates the subscribers prepaid data session at a
SAD. This is the case, for example, when time-based prepaid is used SAD. This is the case, for example, when time-based prepaid is used
and the mobile subscriber performs a dormant handoff. and the mobile subscriber performs a dormant handoff.
2.8. Querying and Rebalancing 2.8. Querying and Rebalancing
It should be possible for the PPS to Query the current resource It should be possible for the PPS to query the current resource
consumption at a SAD and adjust the user account balance. For consumption at a SAD and adjust the user account balance. For
example, a request to the PPS is made (e.g. a one-time charging example, a request to the PPS is made (e.g. a one-time charging
event), the account is depleted and resources have been allocated to event), the account is depleted and resources have been allocated to
the SAD. The PPS should have the ability to query the SAD and if it the SAD. The PPS should have the ability to query the SAD and if it
has the spare resources to reassign the quotas to the SAD and to the has the spare resources to reassign the quotas to the SAD and to the
pending request. Note that the PPS does not know resource usage pending request. Note that the PPS does not know resource usage
until the SAD request for more resources. This can be a long time. until the SAD request for more resources. This can be a long time.
In the absence of this capability the PPS can minimize the effect of In the absence of this capability the PPS can minimize the effect of
this phenomenon by allocating small quotas, a practice that results this phenomenon by allocating small quotas, a practice that results
skipping to change at page 24, line 7 skipping to change at page 26, line 7
usual service attributes and forward the packet to the SAD. The HAAA usual service attributes and forward the packet to the SAD. The HAAA
SHOULD NOT overwrite any attributes already set by the PPS. If the SHOULD NOT overwrite any attributes already set by the PPS. If the
HAAA receives an Access-Reject message, it will simply forward the HAAA receives an Access-Reject message, it will simply forward the
packet to its client. Depending on site policies, if the HAAA does packet to its client. Depending on site policies, if the HAAA does
not receive an Access-Accept or an Access-Reject message from the PPS not receive an Access-Accept or an Access-Reject message from the PPS
it MAY do nothing or send an Access-Reject or an Access- Accept it MAY do nothing or send an Access-Reject or an Access- Accept
message back to the PPC. message back to the PPC.
3.2. Session Start Operation 3.2. Session Start Operation
The start of the session is indicated by the arrival of an A session is deemed to be 'active' at the home AAA server once the
Accounting-Request(Start) packet. The Accounting-Request (Start) MAY authentication process has been successfully completed. The arrival
be routed to the PPS such that it can confirm the initial quota of an Access Request at the PPS means that authentication has
allocation. successfully completed because otherwise the home AAA server would
not forward it to the PPS. A session being active, however, does not
necessarily mean that the user has actually started using the
service.
Note that the role of the PPS is not to record accounting messages The PPS may deduce that the user has actually consumed some service
and therefore it SHOULD NOT respond with an Accounting Response (i.e. consumed some of the allocated quota) by either the reception
packet. If the PPS does not receive the Accounting-Request(start) of an Accounting-Request(Start) packet, or the reception of an Access
message it will only know that the session has started upon the first Request message that asks for quota replenishment. The Accounting-
reception of a quota replenishment operation. Request (Start) MAY be routed to the PPS such that it can confirm
that the user has started consuming the initial quota. Note,
however, that the role of the PPS is not to record accounting
messages and therefore it SHOULD NOT respond with an Accounting
Response packet.
If the PPS does not receive indication directly (via Accounting- If the PPS does not receive any of the above two indications that the
Request(start)) or indirectly, it SHOULD, after some configurable user has started consuming the service, it SHOULD, after some
time, deduce that the Session has not started. If the SAD supports configurable time, terminate the session. If the SAD supports
termination capabilities, the PPS SHOULD send a Disconnect Message to termination capabilities, the PPS SHOULD send a Disconnect Message to
the SAD as a measure to ensure that the session is indeed dead. the SAD as a measure to ensure that the session is indeed dead.
3.3. Mid-Session Operation 3.3. Mid-Session Operation
During the lifetime of a prepaid data session the SAD may request the During the lifetime of a prepaid data session the SAD may request the
replenishment of the quotas using Authorize-Only Access-Request replenishment of the quotas using a 'mid-session' prepaid-specific
message. Once either the allocated quota has been exhausted or the Access-Request message. Such a message MUST include NAS identifiers,
threshold has been reached, the SAD MUST send an Access-Request with a Session identifier attribute, and at least one PPAQ attribute. The
Servicetype(6) set to a value of "Authorize Only" and the PPAQ(TBD) home AAA server or the PPS that receives such a message classifies it
attribute. as 'mid-session' if it refers to an active session, i.e. the NAS
identifier, session identifier, and possibly other AVPs match those
The SAD MUST also include NAS identifiers, and Session identifier of an active session. Which exactly AVPs are required to match in
attributes in the Authorize Only Access-Request. The Session order to map a message to a session depends on the deployment
Identifier should be the same as the one used during the initial scenario and applicable policies. Certain AVPs are also used to
Access-Request. For example, if the User-Name(1) attribute was used route the message through proxies. For example, if the User-Name(1)
in the Access-Request it MUST be included in the Authorize Only attribute was used in the initial Access-Request, it MUST be included
Access-Request, especially if the User-Name(1) attribute is used to any subsequent Access-Requests, especially if the User-Name(1)
route the Access-Request to the Home AAA server. attribute is used to route the Access-Request to the Home AAA server.
The Authorize Only Access-Request MUST NOT include a User Password The mid-session Access-Request MUST NOT include a User Password and
and MUST NOT include a Chap Password. In order to enable the MUST NOT include a Chap Password. In order to enable the receiver to
receiver to authenticate the message, the SAD MUST include a Message- authenticate the message, the SAD MUST include a Message-
Authenticator(80) attribute. The SAD computes the value for the Authenticator(80) attribute. The SAD computes the value for the
Message-Authenticator according to RFC 2869. Message-Authenticator according to RFC 2869.
When the HAAA receives an Authorize-Only Access-Request that contains When the HAAA receives an Access-Request that contains a PPAQ(TBD),
a PPAQ(TBD), it SHALL validate the message using the Message- it SHALL validate the message using the Message-Authenticator(80),
Authenticator(80), according to RFC 2869. If the HAAA receives an according to RFC 2869. If the HAAA receives an Access-Request that
Authorize Only Access-Request that contains a PPAQ(TBD) and either no contains a PPAQ(TBD) and either no or an invalid Message-
or an invalid Message-Authenticator(80) it SHALL silently discard the Authenticator(80) it SHALL silently discard the message. A mid-
message. An Authorize Only Access-Request message that does not session Access-Request message that does not contain a PPAQ(TBD) is
contain a PPAQ(TBD) is either erroneous or belongs to another either erroneous or belongs to another application (for example, a
application (for example, a Change of Authorization message Change of Authorization message [RFC3576]). In this case the Access-
[RFC3576]). In this case the Authorize Only Access-Request is either Request message is either silently discarded or handled by another
silently discarded or handled by another application. application.
Once the Authorize Only Access-Request message is validated, the HAAA Once the mid-session Access-Request message is validated, the HAAA
SHALL forward the Authorize Only Access-Request to the appropriate SHALL forward it to the appropriate PPS. The HAAA MUST forward the
PPS. The HAAA MUST forward the Authorize Only Access-Request to the Access-Request to the PPS specified in the PPAQ(TBD). The HAAA MUST
PPS specified in the PPAQ(TBD). The HAAA MUST add a Message- add a Message-Authenticator(80) to the message, according to RFC
Authenticator(80) to the message, according to RFC 2869. As with the 2869. As with the initial Access-Request message, the HAAA MAY
Access-Request message, the HAAA MAY modify the User-Name(1) modify the User-Name(1) attribute such that it identifies the user to
attribute such that it identifies the user to the PPS. Note that the the PPS. Note that the PPS may also use the Quota-ID sub-attribute
PPS may also use the Quota-ID sub-attribute contained within the contained within the PPAQ(TBD) to locate the user account.
PPAQ(TBD) to locate the user account.
Upon receiving the Authorize Only Access-Request containing a Upon receiving an Access-Request containing a PPAQ(TBD) attribute,
PPAQ(TBD) attribute, the PPS MUST validate the Message- the PPS MUST validate the Message-Authenticator(80) as described in
Authenticator(80) as described in RFC 2869. If validation fails, the RFC 2869. If validation fails, the PPS MUST silently discard the
PPS MUST silently discard the message. If it receives an Authorize message. If it receives a mid-session Access-Request message that
Only Access-Request message that does not contain a PPAQ(TBD), it does not contain a PPAQ(TBD), it MUST silently discard the message.
MUST silently discard the message.
The PPS locates the prepaid session state using the Quota Id The PPS locates the prepaid session state using the Quota Id
contained within the PPAQ(TBD). The PPS takes the most recently contained within the PPAQ(TBD). The PPS takes the most recently
allocated quota and subtracts it from the user balance. If allocated quota and subtracts it from the user balance. If
sufficient balance remains, the PPS authorizes the PPS and allocates sufficient balance remains, the PPS authorizes the PPS and allocates
additional quota. The PPS may also calculate a new threshold value. additional quota. The PPS may also calculate a new threshold value.
Upon successful re-authorization, the PPS generates an Access-Accept Upon successful re-authorization, the PPS generates an Access-Accept
containing the PPAQ(TBD) attribute. The Access-Accept message MAY containing the PPAQ(TBD) attribute. The Access-Accept message MAY
contain Servicetype(6) set to Authorize-Only and MAY contain the contain a Message-Authenticator(80).
Message-Authenticator(80).
Depending on site policies, upon unsuccessful authorization, the PPS Depending on site policies, upon unsuccessful authorization, the PPS
generates an Access-Reject or an Access-Accept with Filter-Id(11) or generates an Access-Reject or an Access-Accept with Filter-Id(11) or
Ascend-Data-Filter (if supported) attribute and the Session- Ascend-Data-Filter (if supported) attribute and the Session-
Timeout(27) attribute such that the subscriber can get access to a Timeout(27) attribute such that the subscriber can get access to a
restricted set of locations for a short period of time. This feature restricted set of locations for a short period of time. This feature
could be used to enable users to replenish their accounts, create new could be used to enable users to replenish their accounts, create new
accounts, or to browse free content. accounts, or to browse free content.
Upon receiving the Access-Accept from the PPS, the HAAA SHALL return Upon receiving the Access-Accept from the PPS, the HAAA SHALL return
skipping to change at page 26, line 43 skipping to change at page 28, line 46
At anytime during a session the PPS may send a Disconnect Message in At anytime during a session the PPS may send a Disconnect Message in
order to terminate a session. This capability is described in detail order to terminate a session. This capability is described in detail
in [RFC3576]. The PPS sends a Disconnect Message that MUST contain in [RFC3576]. The PPS sends a Disconnect Message that MUST contain
identifiers that uniquely identify the data session and the SAD identifiers that uniquely identify the data session and the SAD
servicing that session. servicing that session.
If the SAD receives a Disconnect-Message, it responds with either a If the SAD receives a Disconnect-Message, it responds with either a
Disconnect-ACK message (if it is able to terminate the session) or Disconnect-ACK message (if it is able to terminate the session) or
with a Disconnect-NAK packet (otherwise). Upon successful with a Disconnect-NAK packet (otherwise). Upon successful
termination of a session the SAD MUST return any unused quota to the termination of a session, the SAD MUST return any unused quota to the
PPS by issuing an Authorize Only Access-Request containing the PPAQ PPS by issuing an Access-Request containing a PPAQ attribute which
which contains any unused Quota and the Update-Reason set to "Remote contains any unused Quota and the Update-Reason set to "Remote Forced
Forced Disconnection". Disconnection".
3.4.2. Unsolicited Change of Authorization Operation 3.4.2. Unsolicited Change of Authorization Operation
At any time during the session the PPC may receive a Change of At any time during the session the PPC may receive a Change of
Authorization (CoA) message. A PPS may send a new Quota to either Authorization (CoA) message. A PPS may send a new Quota to either
add or to remove quota that is allocated to the service. If the add or to remove quota that is allocated to the service. If the
Change of Authorization contains a PPAQ then that PPAQ overrides a Change of Authorization contains a PPAQ then that PPAQ overrides a
previously received PPAQ. The PPS MUST NOT change the units used in previously received PPAQ. The PPS MUST NOT change the units used in
the PPAQ. the PPAQ.
skipping to change at page 27, line 21 skipping to change at page 29, line 26
as it normally would when the quota is used up. For example, if the as it normally would when the quota is used up. For example, if the
threshold is reached then is request a quota update . threshold is reached then is request a quota update .
3.5. Termination Operation 3.5. Termination Operation
The termination phase is initiated when (i) the subscriber logs off, The termination phase is initiated when (i) the subscriber logs off,
(ii) the subscriber balance is exhausted, or (iii) when the SAD (ii) the subscriber balance is exhausted, or (iii) when the SAD
receives a Disconnect Message. receives a Disconnect Message.
In case the user logged off, or the SAD receives a Disconnect In case the user logged off, or the SAD receives a Disconnect
Message, the SAD sends an Authorize-Only Access-Request message with Message, the SAD sends an Access-Request message with a PPAQ and
a PPAQ and Update-Reason attribute set to either "Client Service Update-Reason attribute set to either "Client Service Termination" or
Termination" or "Remote Forced Disconnect". This message indicates "Remote Forced Disconnect". This message indicates the amount of
the amount of consumed quota. consumed quota.
In case the currently allocated quota is exhausted, if the PPAQ In case the currently allocated quota is exhausted, if the PPAQ
contained the Termination-Action field, the SAD follows the specified contained the Termination-Action field, the SAD follows the specified
action (which would be to immediately terminate the service, request action (which would be to immediately terminate the service, request
more quota, or redirect/filter the service). more quota, or redirect/filter the service).
3.6. Mobile IP Operations 3.6. Mobile IP Operations
In roaming scenarios with Mobile-IP, the prepaid data session should In roaming scenarios with Mobile IP, the prepaid data session should
be maintained transparently if the HA is acting as the SAD. As the be maintained transparently if the HA is acting as the SAD. As the
subscriber device associates with a new SAD (AP or PDSN that supports subscriber device associates with a new SAD (AP or PDSN that supports
PPC capability), the SAD sends a RADIUS Access-Request and the PPC capability), the SAD sends a RADIUS Access-Request and the
subscriber is re-authenticated and reauthorized. The SAD MUST subscriber is re-authenticated and reauthorized. The SAD MUST
include the PPAC(TBD) attribute in the RADIUS Access-Request. In include the PPAC attribute in the RADIUS Access-Request. In this
this manner, the procedure follows the Authentication and manner, the procedure follows the Authentication and Authorization
Authorization procedure described earlier. procedure described earlier.
If the HA was acting as the SAD before handoff, the prepaid session If the HA was acting as the SAD before handoff, the prepaid session
does not undergo any change after the handoff because the Mobile IP does not undergo any change after the handoff because the Mobile IP
session is anchored at the HA and the user's Home IP address does not session is anchored at the HA and the user's Home IP address does not
change. change.
In the case of a wireless access point or PDSN acting as the SAD, it In the case of a wireless access point or PDSN acting as the SAD, it
is likely that the user's (care-of) IP address will change. The is likely that the user's (care-of) IP address will change. The
prepaid session will be affected by this. In this scenario the SAD prepaid session will be affected by this. In this scenario the SAD
shall send an Access-Request message which is routed to the home shall send an Access-Request message which is routed to the home
network and MUST reach the PPS that is serving this session. The PPS network and MUST reach the PPS that is serving this session. The PPS
correlates the new authorization request with the existing active correlates the new authorization request with the existing active
session and assigns a quota to the new request. Any outstanding session and assigns a quota to the new request. Any outstanding
quota at the old SAD MUST be returned to the PPS if the Mobile-IP quota at the old SAD MUST be returned to the PPS if the Mobile IP
nodes (HA and FA) support registration revocation (Mobile IPv4 only). nodes (HA and FA) support registration revocation (Mobile IPv4 only).
Specifically, the quota SHOULD be returned when the SAD sends the Specifically, the quota SHOULD be returned when the SAD sends an
Authorize Only Access-Request with PPAQ(TBD) Update-Reason set to Access-Request with PPAQ Update-Reason set to either "Remote Forced
either "Remote Forced Disconnect" or "Client Service Termination". Disconnect" or "Client Service Termination". In order to trigger the
In order to trigger the sending of this last Authorize Only Access- sending of this last Access-Request, the PPS may issue a Disconnect
Request, the PPS may issue a Disconnect Message [3576] to the SAD. Message [3576] to the SAD.
Even if the subscriber moves to a SAD that does not have prepaid Even if the subscriber moves to a SAD that does not have prepaid
capabilities can the prepaid data service continue. This can be done capabilities the prepaid data service can continue. This can be done
by requesting the Home Agent (assuming it has such capabilities) to by requesting the Home Agent (assuming it has such capabilities) to
take over the responsibilities of the SAD (i.e. metering). This take over the responsibilities of the SAD (i.e. metering). This
scenario will be discussed in detail in a later version of this scenario will be discussed in detail in a later version of this
document. document.
3.7. Operation Considerations for Multiple Services 3.7. Operation Considerations for Multiple Services
This section describes the support for multiple prepaid services on a This section describes the support for multiple prepaid services on a
single SAD. Message flows illustrating the various interactions are single SAD. Message flows illustrating the various interactions are
presented in Appendix A. presented in Appendix A.
A SAD that supports prepaid operations for multi-services SHOULD set A SAD that supports prepaid operations for multi-services SHOULD set
the "Multi-Services Supported" bit in the PPAC. When working with the "Multi-Services Supported" bit in the PPAC. When working with
multi-services, we need to differentiate between the services. A multiple services, it is necessary to differentiate these services.
Service-Id attribute is used in the PPAQ(TBD) in order to uniquely A Service-Id attribute is used in the PPAQ for this purpose. The
differentiate between the services. The exact definition of the exact definition of the Service-Id attribute is outside the scope of
Service-Id attribute is outside the scope of this document. this document.
A PPAQ that contains a Service-Id is associated with that Service. A A PPAQ AVP that contains a Service-Id is associated with that
PPAQ that contains a Rating-Group-Id is associated with that Rating- Service. A PPAQ AVP that contains a Rating-Group-Id is associated
Group. A PPAQ MUST not contain both a Rating-Group-Id and a with that Rating-Group. A PPAQ MUST not contain both a
Service-Id. A PPAQ that contains neither a Rating-Group-Id or a Rating-Group-Id and a Service-Id. A PPAQ that contains neither a
Service-Id applies to the Access Service. Rating-Group-Id nor a Service-Id applies to the Access Service.
3.7.1. Initial Quota Request 3.7.1. Initial Quota Request
When operations with multi-services is desired, the SAD requests the When operations with multi-services is desired, the SAD requests the
initial quota for the Service by sending a PPAQ containing the initial quota for the Service by sending a PPAQ containing the
Service-Id for that Service in an Authorize-Only Access-Request Service-Id for that Service in an Access-Request packet. Similarly,
packet. Similarly, if the SAD supports Rating-Groups then it may if the SAD supports Rating-Groups then it may request a quota for the
request a quota for the Rating-Group by sending a PPAQ containing the Rating-Group by sending a PPAQ containing the Rating-Group-Id. In
Rating-Group-Id. In both cases the Update-Reason is set to "Initial- both cases the Update-Reason is set to "Initial-Request".
Request".
The Authorize-Only Access-Request message may contain more than one The Access-Request message may contain more than one PPAQ, and MUST
PPAQ. The Authorize-Only Access-Request MUST include one or more include one or more attributes that serve to identify the session so
attributes that serve to identify the session so that it can be that it can be linked to the original authentication. Which Session
linked to the original authentication. Which Session Identifiers are Identifiers are included is up to specific deployments. The message
included is up to specific deployments. The Authorize-Only message
must contain the Message-Authenticator(80) attribute for integrity must contain the Message-Authenticator(80) attribute for integrity
protection of the Authorize-Only Access-Request message. protection.
Upon receiving an Authorize-Only Access-Accept message containing one Upon receiving an Access-Accept message containing one or more PPAQs,
or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ the PPS allocates resources to each PPAQ. Each PPAQ is assigned a
is assigned a unique QID that MUST appear in subsequent PPAQ updates unique QID that MUST appear in subsequent PPAQ updates for that
for that service or rating-group. Additionally, the PPAQ MUST service or rating-group. Additionally, the PPAQ MUST contain the
contain the Service-ID or Group-ID, unless the PPAQ is the generic Service-ID or Group-ID, unless the PPAQ is the generic "Access
"Access Service". Service".
3.7.2. Quota Update 3.7.2. Quota Update
Once the services start to utilize their allotted quota they will Once the services start to utilize their allotted quota they will
eventually need to replenish their quotas (either the threshold is eventually need to replenish their quotas (either the threshold is
reached or no more quota remains). In order to replenish the quota, reached or no more quota remains). In order to replenish the quota,
the PPC sends an Authorize-Only Access-Request message containing one the PPC sends an Access-Request message containing one or more PPAQs.
or more PPAQs. Each PPAQ MUST contain the appropriate QID, Each PPAQ MUST contain the appropriate QID, Service-ID or Group-ID
Service-ID or Group-ID (or neither the Service-ID or Group-Id if the (or neither the Service-ID or Group-Id if the quota replenishment is
quota replenishment is for the "Access Service"). The Update-Reason for the "Access Service"). The Update-Reason filed indicates either
filed indicates either "Threshold reached"(3), or "Quota reached"(4). "Threshold reached"(3), or "Quota reached"(4). The message must
The Authorize-Only message must contain session identifiers. contain session identifiers.
Upon receiving an Authorize-Only Access-Request packet with one or Upon receiving an Access-Request packet with one or more PPAQs the
more PPAQs the PPS responds with a new PPAQ for that service. The PPS responds with a new PPAQ for that service. The PPAQ contains a
PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new new QID, the Service-Id or Rating-Group-Id, a new Quota. If the PPS
Quota. If the PPS does not grant additional quota to the service it does not grant additional quota to the service it MUST include the
MUST include the Termination-Action subfield in the PPAQ that will Termination-Action subfield in the PPAQ that will instruct the SAD
instruct the SAD what to do with the service. what to do with the service.
3.7.3. Termination 3.7.3. Termination
When the allotted quota for a service is exhausted, the SAD shall act When the allotted quota for a service is exhausted, the SAD shall act
in accordance to the Termination-Action field set in the Quota. If in accordance to the Termination-Action field set in the Quota. If
the Termination-Action field is absent then the service MUST be the Termination-Action field is absent then the service MUST be
terminated. If the service is to be terminated, then the SAD shall terminated. If the service is to be terminated, then the SAD shall
send a PPAQ with the appropriate QID, the Service-Id, the used quota, send a PPAQ with the appropriate QID, the Service-Id, the used quota,
and the Update-Reason set to "Client Service Termination". and the Update-Reason set to "Client Service Termination".
skipping to change at page 30, line 16 skipping to change at page 32, line 16
Dynamic operations for multi-services are similar to dynamic Dynamic operations for multi-services are similar to dynamic
operations described for single service operations. The prepaid operations described for single service operations. The prepaid
system may send a COA message containing a PPAQ for an existing system may send a COA message containing a PPAQ for an existing
service instance. The SAD matches the PPAQ with the service using service instance. The SAD matches the PPAQ with the service using
the Service-ID attribute. The new quota could differ from the the Service-ID attribute. The new quota could differ from the
previously allocated value. The SAD must react to the new value previously allocated value. The SAD must react to the new value
accordingly. accordingly.
A disconnect message terminates the "Access Service". As such the A disconnect message terminates the "Access Service". As such the
SAD MUST report all unused quotas by sending an Authorize Only Access SAD MUST report all unused quotas by sending an Access Request
Request message containing a PPAQ for each active service. The message containing a PPAQ for each active service. The Update-Reason
Update-Reason shall indicate that the reason for the update. shall indicate that the reason for the update.
3.7.5. Support for Resource Pools 3.7.5. Support for Resource Pools
If the PPC supports pools as indicated by setting the "Pools If the PPC supports pools as indicated by setting the "Pools
supported" bit in the PPAC(TBD) then the PPS may associate a Quota supported" bit in the PPAC(TBD) then the PPS may associate a Quota
with a Pool by including the Pool-Id and the Pool-Multiplier in the with a Pool by including the Pool-Id and the Pool-Multiplier in the
PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the
threshold field. threshold field.
3.7.6. One-time Charging 3.7.6. One-time Charging
skipping to change at page 31, line 5 skipping to change at page 33, line 5
accordingly. The PPS MUST respond to the PPS with an Access-Accept accordingly. The PPS MUST respond to the PPS with an Access-Accept
message if successful, or an Access-Reject message otherwise. message if successful, or an Access-Reject message otherwise.
The RADIUS server shall respond to the SAD with an Access Accept The RADIUS server shall respond to the SAD with an Access Accept
message. Since this is a one-time charge the SAD must not allow the message. Since this is a one-time charge the SAD must not allow the
session to continue. Therefore, the RADIUS server should include in session to continue. Therefore, the RADIUS server should include in
the Access-Accept a Session-Timeout set to 0. Upon receiving an the Access-Accept a Session-Timeout set to 0. Upon receiving an
Access-Accept response the SAD shall generate an Accounting Stop Access-Accept response the SAD shall generate an Accounting Stop
message. message.
A PPAQ used for One-Time charging may appear in an Authorize-Only A PPAQ used for One-Time charging may appear in an Access Request.
Access Request. This is the case when the session already exists. This is the case when the session already exists. The PPS responds
The PPS responds with an Access-Accept to indicate that the user with an Access-Accept to indicate that the user account has been
account has been debited or an Access-Reject otherwise. debited or an Access-Reject otherwise.
3.7.7. Error Handling 3.7.7. Error Handling
If the PPS receives a PPAQ with an invalid QID it MUST ignore that If the PPS receives a PPAQ with an invalid QID it MUST ignore that
PPAQ. PPAQ.
If the PPS receives a PPAQ containing a Service-Id, or a Rating- If the PPS receives a PPAQ containing a Service-Id, or a Rating-
Group-Id that it does not recognize, then it MUST ignore that PPAQ. Group-Id that it does not recognize, then it MUST ignore that PPAQ.
If the PPC receives a PPAQ containing a Service-Id, or a Rating- If the PPC receives a PPAQ containing a Service-Id, or a Rating-
skipping to change at page 34, line 22 skipping to change at page 36, line 22
Length: = 4 Length: = 4
String encoded as follows: String encoded as follows:
0x00000001 Dynamic Authorization Extensions (rfc3576) is 0x00000001 Dynamic Authorization Extensions (rfc3576) is
supported. supported.
Figure 11: Session Termination Attribute Figure 11: Session Termination Attribute
4.3. PPAQ Attribute 4.3. PPAQ Attribute
One or more PPAQ attributes are sent in an Access Request, Authorize One or more PPAQ attributes are sent in an Access Request, Access-
Only Access-Request and Access-Accept message. In an Access Request Request and Access-Accept message. In an Access Request message, the
message, the PPAQ attribute is used to facilitate One-Time charging PPAQ attribute is used to facilitate One-Time charging transactions.
transactions. In Authorize Only Access-Request messages it is used In Access-Request messages it is used for One-Time charging, report
for One-Time charging, report usage and the request for further usage and the request for further quota. It is also used in order to
quota. It is also used in order to request prepaid quota for a new request prepaid quota for a new service instance. In an Access-
service instance. In an Access-Accept message it is used in order to Accept message it is used in order to allocate the (initial and
allocate the (initial and subsequent) quotas. subsequent) quotas.
When multiple services are supported, a PPAQ is associated with a When multiple services are supported, a PPAQ is associated with a
specific service as indicated by the presence of a Service-Id, a specific service as indicated by the presence of a Service-Id, a
Rating-Group-Id, or the "Access Service" (as indicated by the absence Rating-Group-Id, or the "Access Service" (as indicated by the absence
of a Service-Id and a Rating-Group-Id). of a Service-Id and a Rating-Group-Id).
The attribute has type TBD (one octet), a variable length (greater The attribute has type TBD (one octet), a variable length (greater
than 8, encoded into one octet), and consists of a variable number of than 8, encoded into one octet), and consists of a variable number of
subtypes. Unused subtypes are omitted from the message. In the subtypes. Unused subtypes are omitted from the message. In the
following subsections the various subtypes of the PPAQ attribute are following subsections the various subtypes of the PPAQ attribute are
skipping to change at page 35, line 11 skipping to change at page 37, line 11
allocation of new quota. The on-line quota update RADIUS Access- allocation of new quota. The on-line quota update RADIUS Access-
Request message that is sent from the SAD to the PPS shall include a Request message that is sent from the SAD to the PPS shall include a
previously received QuotaIdentifier. previously received QuotaIdentifier.
4.3.2. VolumeQuota AVP 4.3.2. VolumeQuota AVP
The type of the VolumeQuota attribute is TBD and its length is 12 or The type of the VolumeQuota attribute is TBD and its length is 12 or
18 octets. This AVP is only present if volume-based charging is 18 octets. This AVP is only present if volume-based charging is
used. In a RADIUS Access-Accept message (PPS to SAD direction), it used. In a RADIUS Access-Accept message (PPS to SAD direction), it
indicates the volume (in octets) allocated for the session by the indicates the volume (in octets) allocated for the session by the
PPS. In an RADIUS Authorize Only Access-Request message (SAD to PPS PPS. In an RADIUS Access-Request message (SAD to PPS direction), it
direction), it indicates the total used volume (in octets) for both indicates the total used volume (in octets) for both inbound and
inbound and outbound traffic. The attribute consists of a Value- outbound traffic. The attribute consists of a Value-Digits AVP and
Digits AVP and optionally an Exponent AVP (as indicated in the length optionally an Exponent AVP (as indicated in the length field). The
field). The Exponent AVP, if present, MUST NOT encode a negative Exponent AVP, if present, MUST NOT encode a negative number or zero.
number or zero.
4.3.3. VolumeThreshold AVP 4.3.3. VolumeThreshold AVP
The type of the VolumeThreshold attribute is TBD and its length is 12 The type of the VolumeThreshold attribute is TBD and its length is 12
or 18 octets. This AVP shall optionally be present if VolumeQuota is or 18 octets. This AVP shall optionally be present if VolumeQuota is
present in a RADIUS Access-Accept message (PPS to SAD direction). It present in a RADIUS Access-Accept message (PPS to SAD direction). It
is generated by the PPS and indicates the volume (in octets) that is generated by the PPS and indicates the volume (in octets) that
shall be consumed before a new quota should be requested. This shall be consumed before a new quota should be requested. This
threshold should not be larger than the VolumeQuota. The attribute threshold should not be larger than the VolumeQuota. The attribute
consists of a Value-Digits AVP and optionally an Exponent AVP (as consists of a Value-Digits AVP and optionally an Exponent AVP (as
skipping to change at page 36, line 11 skipping to change at page 38, line 11
requested. This threshold should not be larger than the requested. This threshold should not be larger than the
DurationQuota. It is encoded as a 32 bit unsigned value, in network DurationQuota. It is encoded as a 32 bit unsigned value, in network
byte order. byte order.
4.3.6. ResourceQuota AVP 4.3.6. ResourceQuota AVP
The type of the ResourceQuota attribute is TBD and its length is 12 The type of the ResourceQuota attribute is TBD and its length is 12
or 18 octets. This optional AVP is only present if resource-based or or 18 octets. This optional AVP is only present if resource-based or
one-time charging is used. In the RADIUS Access-Accept message (PPS one-time charging is used. In the RADIUS Access-Accept message (PPS
to SAD direction) it indicates the resources allocated for the to SAD direction) it indicates the resources allocated for the
session by the PPS. In RADIUS Authorize Only Access-Request message session by the PPS. In a RADIUS Access-Request message (SAD to PPS
(SAD to PPS direction), it indicates the resources used in total, direction), it indicates the resources used in total, including both
including both incoming and outgoing chargeable traffic. In one-time incoming and outgoing chargeable traffic. In one-time charging
charging scenarios, the subtype represents the number of units to scenarios, the subtype represents the number of units to charge or
charge or credit the user. The attribute consists of a Value-Digits credit the user. The attribute consists of a Value-Digits AVP and
AVP and optionally an Exponent AVP (as indicated by the length optionally an Exponent AVP (as indicated by the length field).
field).
4.3.7. ResourceThreshold AVP 4.3.7. ResourceThreshold AVP
The type of the ResourceThreshold AVP is TBD and its length is 12 or The type of the ResourceThreshold AVP is TBD and its length is 12 or
18 octets. The semantics of this AVP follow those of the 18 octets. The semantics of this AVP follow those of the
VolumeThreshold and DurationThreshold AVPs. It consists of a Value- VolumeThreshold and DurationThreshold AVPs. It consists of a Value-
Digits AVP and optionally an Exponent AVP. Digits AVP and optionally an Exponent AVP.
4.3.8. Value-Digits AVP 4.3.8. Value-Digits AVP
skipping to change at page 42, line 44 skipping to change at page 44, line 44
maintain the current amount of consumed/requested resources in maintain the current amount of consumed/requested resources in
order to be able to calculate the correct amount to be put into order to be able to calculate the correct amount to be put into
an outgoing message. an outgoing message.
The translator maps each incoming RPP (resp. DCC) message into an The translator maps each incoming RPP (resp. DCC) message into an
outgoing DCC (resp. RPP) message, and possibly establishes or updates outgoing DCC (resp. RPP) message, and possibly establishes or updates
local state that is associated with the session. The translated local state that is associated with the session. The translated
(i.e. outgoing) message is a function of the incoming message as well (i.e. outgoing) message is a function of the incoming message as well
as existing state that is associated with the current session. as existing state that is associated with the current session.
Translation occurs on an attribute-by-attribute basis. Certain Translation occurs on an attribute-by-attribute basis. In this
attributes are translated without consideration of local per-session document, the translation of only RPP and DCC attributes is
state. Other attributes, namely those that are bound to a particular considered. In reality, this translation has to be performed in
session, require such consideration. The translation agent has to coordination and orchestration with the translation of the attributes
identify the session (and possibly subsession) an incoming message of the base RADIUS and Diameter. Certain attributes are translated
belongs to in order to consult the appropriate local per-session without consideration of local per-session state. Other attributes,
state. namely those that are bound to a particular session, require such
consideration. The translation agent has to identify the session
(and possibly subsession) an incoming message belongs to in order to
consult the appropriate local per-session state.
Note that certain DCC attributes cannot be translated due to their Note that certain DCC attributes cannot be translated due to their
semantics not being present in RPP, and vice versa. This results in semantics not being present in RPP, and vice versa. This may result
the messages, in which these attributes occur, not being delivered to in the messages, in which these attributes occur, not being delivered
their intended destination. In such cases it is desirable to inform to their intended destination. Whenever this would lead to a failure
the originator about the failure and terminate the session. at the destination, it is desirable to inform the originator about
this failure and terminate the session in both directions.
In each scenario (i.e. RPP client / DCC AAA infrastructure and DCC In each of the two scenarios (namely RPP client / DCC AAA
client / RPP AAA infrastructure), the translator operates in two infrastructure and DCC client / RPP AAA infrastructure), the
directions, namely RPP to DCC and vice versa. In the following translator operates in two directions, namely RPP to DCC and vice
sections, the notation c->s means that the attribute in question may versa. In the following sections, the notation c->s means that the
occur only in the direction from the client to the server. The attribute in question may occur only in the direction from the client
notation s->c denotes the converse and the notation c<->s denotes to the server. The notation s->c denotes the converse and the
that the attribute may occur in messages that are directed in either notation c<->s denotes that the attribute may occur in messages that
direction. are directed in either direction.
5.1. Session Identification 5.1. Session Identification
The translation agent has to keep per-session state in order to The translation agent has to keep per-session state in order to
perform its task. A session may be identified based on the RPP perform its task. A session may be identified based on the RPP
identifier or the DCC session identifier. That is, the translation identifier or the DCC session identifier. That is, the translation
agent should always maintain a pair of (RPP, DCC) session identifiers agent should always maintain a pair of (RPP, DCC) session identifiers
and maintain the per-session state in association with that pair. and maintain the per-session state in association with that pair.
This per-session state must be addressable by either of these two This per-session state must be addressable by either of these two
identifiers. Moreover, an RPP session identifier must uniquely identifiers. Moreover, an RPP session identifier must uniquely
skipping to change at page 43, line 46 skipping to change at page 45, line 50
infrastructure" case. In other words, in this section it is assumed infrastructure" case. In other words, in this section it is assumed
that the client "talks" RPP and the AAA inftrastructure "talks" DCC. that the client "talks" RPP and the AAA inftrastructure "talks" DCC.
The translator is assumed to sit somewhere in the middle and to The translator is assumed to sit somewhere in the middle and to
mediate between client and server. mediate between client and server.
For each RPP AVP (i.e. AVP that is specified in the present For each RPP AVP (i.e. AVP that is specified in the present
document), the transformation into a semantically equivalent DCC AVP document), the transformation into a semantically equivalent DCC AVP
(if such an AVP exists), along with what per-session state the (if such an AVP exists), along with what per-session state the
translator has to create or consult, is described. For clarity of translator has to create or consult, is described. For clarity of
exposition, each RPP AVP is addressed in a separate subsection. exposition, each RPP AVP is addressed in a separate subsection.
Since in this scenario, the PPC is typically the initiator a session, Since, in this scenario, the PPC is typically the initiator a
the focus is on the RPP AVPs. session, the focus is on the RPP AVPs.
5.2.1. PPAC (c<->s) 5.2.1. PPAC (c<->s)
A DCC client is assumed to always support Volume metering, Duration A DCC client is assumed to always support Volume metering, Duration
metering, Resource metering, Pools, Rating groups, and Tariff metering, Resource metering, Pools, Rating groups, and Tariff
Switching. Thus, if a PPAQ that indicates any of the above is sent Switching. Thus, if a PPAQ that indicates any of the above is sent
client->server, the translator does the following: It lets message go client->server, the translator does the following: It lets message go
through but remembers what exactly the client supports. If the through but remembers what exactly the client supports. If the
server later requests (servier -> client direction) an unsupported server later requests (servier -> client direction) an unsupported
metering to be performed, send failure to server and cause the metering to be performed, send failure to server and cause the
skipping to change at page 51, line 5 skipping to change at page 52, line 43
in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs
have an embedded CC-Total-Octets AVP that indicates the appropriate have an embedded CC-Total-Octets AVP that indicates the appropriate
amount of octets. Furthermore, the Used-Service-Unit AVP that amount of octets. Furthermore, the Used-Service-Unit AVP that
carries the amount that was consumed before the tariff switch also carries the amount that was consumed before the tariff switch also
carries an embedded Tariff-Change-Usage AVP with the value carries an embedded Tariff-Change-Usage AVP with the value
UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP
that carries the amount that was consumed after the tariff switch that carries the amount that was consumed after the tariff switch
also carries an embedded Tariff-Change-Usage AVP with the value also carries an embedded Tariff-Change-Usage AVP with the value
UNIT_AFTER_TARIFF_CHANGE (1). UNIT_AFTER_TARIFF_CHANGE (1).
5.3. Translation between Diameter Credit Control client and RADIUS-
based AAA infrastructure
This section describes the translator in the "DCC client / RPP AAA
infrastructure" case. In other words, in this section it is assumed
that the client "talks" DCC and the AAA inftrastructure "talks" RPP.
The translator is assumed to sit somewhere in the middle and to
mediate between client and server.
For each DCC AVP (i.e. AVP that is specified in RFC 4006), the
transformation into a semantically equivalent RPP AVP (if such an AVP
exists), along with what per-session state the translator has to
create or consult, is described. For clarity of exposition, each DCC
AVP is addressed in a separate subsection. Since, in this scenario,
the client is typically the initiator a session, the focus is on the
DCC AVPs.
5.3.1. CC-Correlation-Id Attribute ( )
[semantics not clear].
5.3.2. CC-Request-Number Attribute (c <-> s)
This attribute is used to correlate DCC requests and answers. In
RPP, this correlation is achieved by means of the QID. This
attribute is therefore not translated. However, the translation
agent must use it in accordance with the DCC specification.
5.3.3. CC-Request-Type Attribute ( )
Although the CC-Request-Type attribute is not translated, the
translation agent has to include it into the messages it exchanges
with the client, as specified in the DCC specification.
5.3.4. CC-Session-Failover Attribute ( )
TBD.
5.3.5. CC-Sub-Session-Id Attribute ( )
TBD.
5.3.6. Check-Balance-Result Attribute ( )
TBD.
5.3.7. Cost-Information Attribute ( )
TBD.
5.3.8. Unit-Value Attribute ( )
TBD.
5.3.9. Exponent Attribute ( )
TBD.
5.3.10. Value-Digits Attribute ( )
TBD.
5.3.11. Currency-Code Attribute ( )
TBD.
5.3.12. Cost-Unit Attribute ( )
TBD.
5.3.13. Credit-Control Attribute ( )
TBD.
5.3.14. Credit-Control-Failure-Handling Attribute ( )
TBD.
5.3.15. Direct-Debiting-Failure-Handling Attribute ( )
TBD.
5.3.16. Multiple-Services-Credit-Control Attribute ( )
TBD.
5.3.17. Granted-Service-Unit Attribute ( )
TBD.
5.3.18. Requested-Service-Unit Attribute ( )
TBD.
5.3.19. Used-Service-Unit Attribute ( )
TBD.
5.3.20. Tariff-Time-Change Attribute ( )
TBD.
5.3.21. CC-Time Attribute ( )
TBD.
5.3.22. CC-Money Attribute ( )
TBD.
5.3.23. CC-Total-Octets Attribute ( )
TBD.
5.3.24. CC-Input-Octets Attribute ( )
TBD.
5.3.25. CC-Output-Octets Attribute ( )
TBD.
5.3.26. CC-Service-Specific-Units Attribute ( )
TBD.
5.3.27. Tariff-Change-Usage Attribute ( )
TBD.
5.3.28. Service-Identifier Attribute ( )
TBD.
5.3.29. Rating-Group Attribute ( )
TBD.
5.3.30. G-S-U-Pool-Reference Attribute ( )
TBD.
5.3.31. G-S-U-Pool-Identifier Attribute ( )
TBD.
5.3.32. CC-Unit-Type Attribute ( )
TBD.
5.3.33. Validity-Time Attribute ( )
TBD.
5.3.34. Final-Unit-Indication Attribute ( )
TBD.
5.3.35. Final-Unit-Action Attribute ( )
TBD.
5.3.36. Restriction-Filter-Rule Attribute ( )
TBD.
5.3.37. Redirect-Server Attribute ( )
TBD.
5.3.38. Redirect-Address-Type Attribute ( )
TBD.
5.3.39. Redirect-Server-Address Attribute ( )
TBD.
5.3.40. Multiple-Services-Indicator Attribute ( )
TBD.
5.3.41. Requested-Action Attribute ( )
TBD.
5.3.42. Service-Context-Id Attribute ( )
TBD.
5.3.43. Service-Parameter-Info Attribute ( )
TBD.
5.3.44. Service-Parameter-Type Attribute ( )
TBD.
5.3.45. Service-Parameter-Value Attribute ( )
TBD.
5.3.46. Subscription-Id Attribute ( )
TBD.
5.3.47. Subscription-Id-Type Attribute ( )
TBD.
5.3.48. Subscription-Id-Data Attribute ( )
TBD.
5.3.49. User-Equipment-Info Attribute ( )
TBD.
5.3.50. User-Equipment-Info-Type Attribute ( )
TBD.
5.3.51. User-Equipment-Info-Value Attribute ( )
TBD.
6. Security Considerations 6. Security Considerations
[Editor's Note: A future version of this document will provide a [Editor's Note: A future version of this document will provide a
description of the security threats and the countermeasures.] description of the security threats and the countermeasures.]
7. IANA Considerations 7. IANA Considerations
This document requires the assignment of new Radius attributes type This document requires the assignment of new Radius attributes type
numbers for the following attributes: Prepaid-Accounting-Capability numbers for the following attributes: Prepaid-Accounting-Capability
(PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ), (PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ),
skipping to change at page 57, line 7 skipping to change at page 64, line 7
{RADIUS BASE AVPS} {RADIUS BASE AVPS}
<------(16)-------- <------(16)--------
Figure 12: A simple example message flow Figure 12: A simple example message flow
The user logs on (1). The PPC sends a RADIUS Access Request message The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC to the home AAA server (2), and includes the prepaid-specific PPAC
AVP. This AVP indicates that both duration-based and volume-based AVP. This AVP indicates that both duration-based and volume-based
metering is supported. However, it also indicated that multiple metering is supported. However, it also indicated that multiple
services, rating groups and resource pools are not supported. Note services, rating groups and resource pools are not supported. Note
that, since this is not an "Authorize Only" message, no PPAQ AVP with that no PPAQ AVP with Update Reason="initial request" is included
Update Reason="initial request" is included (see Section 3.7.1). The (see Section 3.7.1). The home AAA server then authenticates the user
home AAA server then authenticates the user and authorizes the access and authorizes the access service, as is usual in RADIUS (3). Note
service, as is usual in RADIUS (3). Note that the PPAC AVP is that the PPAC AVP is appended by the PPC in at least the last message
appended by the PPC in at least the last message that is sent to the that is sent to the home AAA server during this possibly multiple-
home AAA server during this possibly multiple-round exchange. round exchange.
If authentication and authorization is successful (in this example If authentication and authorization is successful (in this example
this is assumed), the home AAA server forwards the final Access this is assumed), the home AAA server forwards the final Access
Request to the PPS (4). The PPS identifies the user's prepaid Request to the PPS (4). The PPS identifies the user's prepaid
account from the included base RADIUS AVPs, and determines the account from the included base RADIUS AVPs, and determines the
capabilities of the PPC from the PPAC attribute. Assuming that capabilities of the PPC from the PPAC attribute. Assuming that
sufficient funds are available in the user's prepaid account, the PPS sufficient funds are available in the user's prepaid account, the PPS
reserves some of these and rates the service. In this example, the reserves some of these and rates the service. In this example, the
PPS reserves, say, 2 Euros and determines that the access service is PPS reserves, say, 2 Euros and determines that the access service is
rated at 0.4 Euro per MB. This results in 5 MB of quota being rated at 0.4 Euro per MB. This results in 5 MB of quota being
skipping to change at page 57, line 37 skipping to change at page 64, line 37
quota reservation. This identifier can be used to later uniquely quota reservation. This identifier can be used to later uniquely
identify the prepaid session, user, account, etc. The resulting identify the prepaid session, user, account, etc. The resulting
Access Accept message is sent to the home AAA server (5) and Access Accept message is sent to the home AAA server (5) and
forwarded to the PPC (6). forwarded to the PPC (6).
Upon reception of message (6), the PPC provides the access service to Upon reception of message (6), the PPC provides the access service to
the user and meters it accordingly. the user and meters it accordingly.
At some point in time, the threshold is reached, i.e. 4.5MB of At some point in time, the threshold is reached, i.e. 4.5MB of
"access service" have been consumed by the user. At that point, the "access service" have been consumed by the user. At that point, the
PPC generates an Authorize Only Access Request that contains the PPC generates an Access Request that contains the usual RADIUS
usual RADIUS attributes and a PPAQ AVPs that reports the amount of attributes and a PPAQ AVP that reports the amount of consumed quota,
consumed quota, and the request for replenishment, i.e. the Update- and the request for replenishment, i.e. the Update-Reason= THRESHOLD
Reason= THRESHOLD REACHED (8). Note that the QID in this message is REACHED (8). Note that the QID in this message is the same as the
the same as the one previously received from the user's home AAA one previously received from the user's home AAA server. This
server. This message is forwarded to the PPS (9). message is forwarded to the PPS (9).
Upon reception of message (9), the PPS identifies the user and his Upon reception of message (9), the PPS identifies the user and his
account from the QID. In also determines that a prepaid session is account from the QID. In also determines that a prepaid session is
ongoing, and that enough credit remains in the prepaid account in ongoing, and that enough credit remains in the prepaid account in
order for the access service to continue being provided. Since 4.5 order for the access service to continue being provided. Since 4.5
MB have been consumed, the PPS subtracts 1.8 Euros from the user's MB have been consumed, the PPS subtracts 1.8 Euros from the user's
prepaid account. The PPS decides to reserve another 2.8 euros from prepaid account. The PPS decides to reserve another 2.8 euros from
the user's account. (This results in 3 euros being reserved in total the user's account. (This results in 3 euros being reserved in total
at this point in time.) As the access service is rated at 0.4 euros at this point in time.) As the access service is rated at 0.4 euros
per MB, the PPS determines that another 7 MB of quota should be per MB, the PPS determines that another 7 MB of quota should be
skipping to change at page 58, line 17 skipping to change at page 65, line 17
threshold value of 11.5 MB. Since this is a new quota reservation, threshold value of 11.5 MB. Since this is a new quota reservation,
the PPS also allocates a new QuotaIdentifier to it, in this example the PPS also allocates a new QuotaIdentifier to it, in this example
QID=8. The resulting RADIUS message is sent to the home AAA server QID=8. The resulting RADIUS message is sent to the home AAA server
(10) and forwarded to the PPC (11). (10) and forwarded to the PPC (11).
Upon reception of message (11), the PPC updates its records and Upon reception of message (11), the PPC updates its records and
continues provisioning access to the user. At some point the user continues provisioning access to the user. At some point the user
logs off (12). The PPC must then report how many resources were logs off (12). The PPC must then report how many resources were
consumed, so that the PPC can subtract the appropriate monetary consumed, so that the PPC can subtract the appropriate monetary
amount from the user's prepaid account. To this end the PPC amount from the user's prepaid account. To this end the PPC
constructs an Authorize Only Access Request message with a PPAQ AVPs constructs an Access Request message with a PPAQ AVP for the access
for the access service. In this example, 7 MB were consumed by the service. In this example, 7 MB were consumed by the access service
access service in total. The PPC reports 7 MB its final message in total. The PPC reports 7 MB its final message (13). This is
(13). This is forwarded to the PPS (14) which correlates the report, forwarded to the PPS (14) which correlates the report, using the QID,
using the QID, to the previous session state. It determines, from to the previous session state. It determines, from the previous
the previous records, that the access service had consumed another records, that the access service had consumed another 4.5 MB before
4.5 MB before (as indicated in message (9)). This means that, of the (as indicated in message (9)). This means that, of the 7 MB, only
7 MB, only 3.5 MB have not yet been subtracted from the user's 3.5 MB have not yet been subtracted from the user's account. Thus,
account. Thus, the PPS subtracts another 1.4 euros from the user's the PPS subtracts another 1.4 euros from the user's account and,
account and, since the session is to be terminated (REASON=ACCESS since the session is to be terminated (REASON=ACCESS SERVICE
SERVICE TERMINATED), releases any reserved monetary amount. TERMINATED), releases any reserved monetary amount.
The PPS responds with an Access Response as required by the RADIUS The PPS responds with an Access Response as required by the RADIUS
base specification (15). So does the home AAA server (16). base specification (15). So does the home AAA server (16).
A.2. A flow with prepaid tariff switching A.2. A flow with prepaid tariff switching
End user PPC AAA Server PPS End user PPC AAA Server PPS
user logs on user logs on
------(1)---------> ------(1)--------->
skipping to change at page 62, line 21 skipping to change at page 69, line 21
The PPS further calculates the new threshold value of 28 MB. Since The PPS further calculates the new threshold value of 28 MB. Since
this is a new quota reservation, the PPS also allocates a new this is a new quota reservation, the PPS also allocates a new
QuotaIdentifier to it, in this example QID=8. The resulting RADIUS QuotaIdentifier to it, in this example QID=8. The resulting RADIUS
message is sent to the home AAA server (10) and forwarded to the PPC message is sent to the home AAA server (10) and forwarded to the PPC
(11). (11).
Upon reception of message (11), the PPC updates its records and Upon reception of message (11), the PPC updates its records and
continues providing access to the user. At some point the user logs continues providing access to the user. At some point the user logs
off (12). The PPC must then report how many resources were consumed, off (12). The PPC must then report how many resources were consumed,
so that the PPC can subtract the appropriate monetary amount from the so that the PPC can subtract the appropriate monetary amount from the
user's prepaid account. To this end the PPC constructs an Authorize user's prepaid account. To this end the PPC constructs an Access
Only Access Request message with a PPAQ AVPs for the access service. Request message with a PPAQ AVP for the access service. In this
In this example, 17 MB were consumed by the access service in total. example, 17 MB were consumed by the access service in total. The PPC
The PPC reports 17 MB its final message (13). This is forwarded to reports 17 MB its final message (13). This is forwarded to the PPS
the PPS (14) which correlates the report, using the QID, to the (14) which correlates the report, using the QID, to the previous
previous session state. It determines, from the previous records, session state. It determines, from the previous records, that the
that the access service had consumed 14 MB before (as indicated in access service had consumed 14 MB before (as indicated in message
message (9)). This means that, of the 17 MB, only the monetary (9)). This means that, of the 17 MB, only the monetary equivalent
equivalent for 3 MB have not yet been subtracted from the user's for 3 MB have not yet been subtracted from the user's account. The
account. The PPS calculates how much should be deducted from the PPS calculates how much should be deducted from the user's account as
user's account as follows. Since the VUATS AVP indicates that 2.5MB follows. Since the VUATS AVP indicates that 2.5MB were consumed
were consumed after the tariff switch, only 0.5 MB were consumed after the tariff switch, only 0.5 MB were consumed before that.
before that. Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8 Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros.
= 3.6 euros. That is, the PPS subtracts 3.6 euros from the user's That is, the PPS subtracts 3.6 euros from the user's prepaid account.
prepaid account. Since the session has by now be terminated by the Since the session has by now be terminated by the PPC (REASON=ACCESS
PPC (REASON=ACCESS SERVICE TERMINATED), the PPS now releases any SERVICE TERMINATED), the PPS now releases any reserved monetary
reserved monetary amount, in this example 12.8 - 3.6 = 9.2 euros. amount, in this example 12.8 - 3.6 = 9.2 euros.
The PPS responds with an Access Response as required by the RADIUS The PPS responds with an Access Response as required by the RADIUS
base specification (15). So does the home AAA server (16). base specification (15). So does the home AAA server (16).
Remark: In this example, two tariff switches take place. In other Remark: In this example, two tariff switches take place. In other
scenarios, of course, only one tariff switch may occur. In such scenarios, of course, only one tariff switch may occur. In such
scenarios the TITSU AVP is not used. scenarios the TITSU AVP is not used.
A.3. Resource pools and Rating Groups A.3. Resource pools and Rating Groups
skipping to change at page 65, line 27 skipping to change at page 72, line 27
<------(21)-------- <------(21)--------
AA Response AA Response
{RADIUS BASE AVPS {RADIUS BASE AVPS
<------(22)-------- <------(22)--------
Figure 14: Example message flow with resource pools and rating groups Figure 14: Example message flow with resource pools and rating groups
The user logs on (1). The PPC sends a RADIUS Access Request message The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC to the home AAA server (2), and includes the prepaid-specific PPAC
AVP, indicating that multiple services, rating groups and resource AVP, indicating that multiple services, rating groups and resource
pools are supported. Note that, since this is not an "Authorize pools are supported. Note that no PPAQ AVP with Update
Only" message, no PPAQ AVP with Update Reason="initial request" is Reason="initial request" is included (see Section 3.7.1). The home
included (see Section 3.7.1). The home AAA server then authenticates AAA server then authenticates the user and authorizes the access
the user and authorizes the access service, as is usual in RADIUS service, as is usual in RADIUS (3). Note that the PPAC AVP is
(3). Note that the PPAC AVP is appended by the PPC in at least the appended by the PPC in at least the last message that is sent to the
last message that is sent to the home AAA server during this possibly home AAA server during this possibly multiple-round exchange.
multiple-round exchange.
If authentication and authorization is successful (in this example If authentication and authorization is successful (in this example
this is assumed), the home AAA server forwards the final Access this is assumed), the home AAA server forwards the final Access
Request to the PPS (4). The PPS identifies the user's prepaid Request to the PPS (4). The PPS identifies the user's prepaid
account from the included base RADIUS AVPs, and determines the account from the included base RADIUS AVPs, and determines the
capabilities of the PPC from the PPAC attribute. Assuming that capabilities of the PPC from the PPAC attribute. Assuming that
sufficient funds are available in the user's prepaid account, the PPS sufficient funds are available in the user's prepaid account, the PPS
reserves some of these and rates the service. In this example, the reserves some of these and rates the service. In this example, the
PPS reserves 5 Euros and determines that the access service is rated PPS reserves 5 Euros and determines that the access service is rated
at 1 Euro per MB. In anticipation that the user requests more at 1 Euro per MB. In anticipation that the user requests more
skipping to change at page 66, line 4 skipping to change at page 72, line 49
sufficient funds are available in the user's prepaid account, the PPS sufficient funds are available in the user's prepaid account, the PPS
reserves some of these and rates the service. In this example, the reserves some of these and rates the service. In this example, the
PPS reserves 5 Euros and determines that the access service is rated PPS reserves 5 Euros and determines that the access service is rated
at 1 Euro per MB. In anticipation that the user requests more at 1 Euro per MB. In anticipation that the user requests more
chargeable services throughout this prepaid session, and since this chargeable services throughout this prepaid session, and since this
is supported by the PPC, the PPS further associates a resource pool is supported by the PPC, the PPS further associates a resource pool
with this reservation, in this example PoolID=1. The PPC also with this reservation, in this example PoolID=1. The PPC also
specifies the multiplier = 1 for the access service. Note that, specifies the multiplier = 1 for the access service. Note that,
since 5MB = 5242880 octets, 1 unit in the resource pool corresponds since 5MB = 5242880 octets, 1 unit in the resource pool corresponds
to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents. to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents.
(However, the PPC does not need to know that.) Moreover, the PPS (However, the PPC does not need to know that.) Moreover, the PPS
associates the QuotaIdentifier QID=5 to this quota reservation. This associates the QuotaIdentifier QID=5 to this quota reservation. This
identifier can be used to later uniquely identify the prepaid identifier can be used to later uniquely identify the prepaid
session, user, account, etc. The resulting Access Accept message is session, user, account, etc. The resulting Access Accept message is
sent to the home AAA server (5) and forwarded to the PPC (6). sent to the home AAA server (5) and forwarded to the PPC (6).
Upon reception of message (6), the PPC provides the access service to Upon reception of message (6), the PPC provides the access service to
the user and meters it accordingly. That is, for every octet the user and meters it accordingly. That is, for every octet
consumed, the PPC subtracts 1 unit (since the multiplier is 1) from consumed, the PPC subtracts 1 unit (since the multiplier is 1) from
the resouce pool with PoolID=1. the resouce pool with PoolID=1.
At some point in time, the user requests another chargeable service, At some point in time, the user requests another chargeable service,
namely service A (8). The PPC generates an Authorize Only Access namely service A (8). The PPC generates an Access Request that
Request that contains the usual RADIUS attributes and the Service-ID contains the usual RADIUS attributes and the Service-ID identifying
identifying service A (9). The PPC has determined that service A is service A (9). The PPC has determined that service A is rated in an
rated in an identical way as at least one more service. Thus, identical way as at least one more service. Thus, service A has been
service A has been configured to belong to a rating group, in this configured to belong to a rating group, in this example the group
example the group with Rating-Group-ID=1. This identifier is with Rating-Group-ID=1. This identifier is included is message (9),
included is message (9), which is then forwarded to the PPS (10). which is then forwarded to the PPS (10).
Upon reception of message (10), the PPS identifies the user and his Upon reception of message (10), the PPS identifies the user and his
account from the base RADIUS attributes, the fact that a prepaid account from the base RADIUS attributes, the fact that a prepaid
session is ongoing, and determines that enough credit remains in the session is ongoing, and determines that enough credit remains in the
prepaid account in order for service A to be provided. The PPS also prepaid account in order for service A to be provided. The PPS also
determines that service A is rated at 0.10 euros per minute. The PPS determines that service A is rated at 0.10 euros per minute. The PPS
decides to reserve another 5 euros from the users account; this decides to reserve another 5 euros from the users account; this
corresponds to 50 minutes or, as encoded in the DurationQuota AVP, corresponds to 50 minutes or, as encoded in the DurationQuota AVP,
3000 seconds. As service A draws from the same prepaid account as 3000 seconds. As service A draws from the same prepaid account as
the access service, the PPS associates this reservation with the same the access service, the PPS associates this reservation with the same
skipping to change at page 67, line 24 skipping to change at page 74, line 23
subtracted from credit pool 1. subtracted from credit pool 1.
At some point in time, resource pool 1 is close to exhaustion. (For At some point in time, resource pool 1 is close to exhaustion. (For
example, the PPC may determine that the pool is "close to exhaustion" example, the PPC may determine that the pool is "close to exhaustion"
when has less than 10% its initial amount of units.) At that point, when has less than 10% its initial amount of units.) At that point,
the PPC needs to ask for replenishment for the pool. Suppose that, the PPC needs to ask for replenishment for the pool. Suppose that,
at that point in time, 4MB of "access service", 45 minutes of at that point in time, 4MB of "access service", 45 minutes of
"service A", and 10 minutes of "service B" were provided to the user. "service A", and 10 minutes of "service B" were provided to the user.
Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304
+ 5767179 = 9961483 abstract service units from the pool. The PPC + 5767179 = 9961483 abstract service units from the pool. The PPC
constructs an Authorize Only Access Request message that reports the constructs an Access Request message that reports the usage for the
usage for the "access service" and "service A". This message "access service" and "service A". This message contains two PPAQ
contains two PPAQ AVPS, is sent to the home AAA server (14) and AVPS, is sent to the home AAA server (14) and forwarded to the PPS
forwarded to the PPS (15). Note that is the message it appears that (15). Note that is the message it appears that "service A" has
"service A" has consumed more than it was allocated (i.e. 55 minutes consumed more than it was allocated (i.e. 55 minutes although only 50
although only 50 minutes were initially allocated to it). This is minutes were initially allocated to it). This is not a a problem
not a a problem since the PPS knows that "service A" was drawing from since the PPS knows that "service A" was drawing from the same pool
the same pool as the "access service" and that the "access service" as the "access service" and that the "access service" did only
did only consume 4 out of the 5 MB it was allocated. consume 4 out of the 5 MB it was allocated.
Upon reception of message (15), the PPS subtracts 4 euros from the Upon reception of message (15), the PPS subtracts 4 euros from the
user's account for the "access service" and another 5.5 euros for user's account for the "access service" and another 5.5 euros for
"service A". (This includes the charge incurred by "service B" up to "service A". (This includes the charge incurred by "service B" up to
that point in time, although the PPS is not aware of "service B" that point in time, although the PPS is not aware of "service B"
being provisioned to the user.) The PPS then determines that being provisioned to the user.) The PPS then determines that
sufficient funds remain in the prepaid account in order for both sufficient funds remain in the prepaid account in order for both
services to be continued. The PPS decides to reserve another 3MB for services to be continued. The PPS decides to reserve another 3MB for
the access service and 30 minutes for "service A". This corresponds the access service and 30 minutes for "service A". This corresponds
to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a
skipping to change at page 68, line 26 skipping to change at page 75, line 25
pool. Since the applicable multiplier here is 1747.63, the PPC adds pool. Since the applicable multiplier here is 1747.63, the PPC adds
further 3145734 abstract units to the pool 1. further 3145734 abstract units to the pool 1.
The PPC then continues to provide the access service, "service A" and The PPC then continues to provide the access service, "service A" and
"service B" to the user, and meters them against the pool, as "service B" to the user, and meters them against the pool, as
previously. previously.
At some point the user logs off (18). The PPC must then report how At some point the user logs off (18). The PPC must then report how
many resources were consumed, so that the PPC can subtract the many resources were consumed, so that the PPC can subtract the
appropriate monetary amount from the user's prepaid account. To this appropriate monetary amount from the user's prepaid account. To this
end the PPC constructs an Authorize Only Access Request message with end the PPC constructs an Access Request message with two PPAQ AVPs;
two PPAQ AVPs; one for the access service and one for "service A". one for the access service and one for "service A". Suppose that, in
Suppose that, in total, 6.5MB were consumed by the access service, 70 total, 6.5MB were consumed by the access service, 70 minutes were
minutes were consumed by "service A" and 20 minutes by "service B". consumed by "service A" and 20 minutes by "service B". The PPC
The PPC reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds) reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds) in its
in its final message (19). This is forwarded to the PPS which final message (19). This is forwarded to the PPS which determines,
determines, from the previous records, that the access service from the previous records, that the access service consumed another
consumed another 2.5MB (since 4MB out of the 6.5MB were already 2.5MB (since 4MB out of the 6.5MB were already reported in message
reported in message (15), and that "service A" consumed further 600 (15), and that "service A" consumed further 600 seconds. This
seconds. This corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros. corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros. Thus, the PPS
Thus, the PPS only subtracts 2.5 out of the 6 previously reserved only subtracts 2.5 out of the 6 previously reserved euros from the
euros from the user's prepaid account and responds with an Access user's prepaid account and responds with an Access Response as
Response as required by the RADIUS base specification. required by the RADIUS base specification.
The home AAA server likewise responds with an Access Response. The home AAA server likewise responds with an Access Response.
Authors' Addresses Authors' Addresses
Avi Lior Avi Lior
Bridgewater Systems Bridgewater Systems
303 Terry Fox Drive 303 Terry Fox Drive
Ottawa, Ontario Suite 100 Ottawa, Ontario Suite 100
Canada Canada
skipping to change at page 70, line 41 skipping to change at page 77, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 108 change blocks. 
536 lines changed or deleted 853 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/