< draft-lior-radius-prepaid-extensions-10.txt   draft-lior-radius-prepaid-extensions-11.txt >
RADEXT A. Lior RADEXT A. Lior
Internet-Draft Bridgewater Systems Internet-Draft Bridgewater Systems
Expires: August 17, 2006 P. Yegani Expires: December 25, 2006 P. Yegani
Cisco Cisco
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
H. Tschofenig H. Tschofenig
A. Pashalidis A. Pashalidis
Siemens Siemens
February 13, 2006 June 23, 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-10.txt draft-lior-radius-prepaid-extensions-11.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 August 17, 2006. This Internet-Draft will expire on December 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes an extension to the Remote Authentication This document specifies an extension to the Remote Authentication
Dial- In User Service (RADIUS) protocol. This extension makes RADIUS Dial-In User Service (RADIUS) protocol that enables service providers
support charging for prepaid services. The extension is based on a to charge for prepaid services. The supported charging models
number of charging models, in particular based on volume, duration supported are volume-based, duration-based, and based on one-time
and single (atomic) events. events.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 8 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7
1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 10
1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 14 1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 12
2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 17 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15
2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 17 2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 15
2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 17 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 19 2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 17
2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 20 2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 17
2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 20 2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18
2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 22 2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 20
2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 22 2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20
2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 23 2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 20
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Authentication and Authorization Operation . . . . . . . . 24 3.1. Authentication and Authorization Operation . . . . . . . . 22
3.2. Session Start Operation . . . . . . . . . . . . . . . . . 26 3.2. Session Start Operation . . . . . . . . . . . . . . . . . 24
3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 26 3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24
3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 28 3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26
3.4.1. Unsolicited Session Termination Operation . . . . . . 28 3.4.1. Unsolicited Session Termination Operation . . . . . . 26
3.4.2. Unsolicited Change of Authorization Operation . . . . 29 3.4.2. Unsolicited Change of Authorization Operation . . . . 27
3.5. Termination Operation . . . . . . . . . . . . . . . . . . 29 3.5. Termination Operation . . . . . . . . . . . . . . . . . . 27
3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 29 3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27
3.7. Operation Considerations for Multiple Services . . . . . . 30 3.7. Operation Considerations for Multiple Services . . . . . . 28
3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 30 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 29
3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 31 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29
3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 31 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 30
3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 32 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30
3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 32 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 30
3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 32 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 30
3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 33 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31
3.7.8. Accounting Considerations . . . . . . . . . . . . . . 33 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 31
3.7.9. Interoperability with Diameter Credit Control 3.7.9. Interoperability with Diameter Credit Control
Application . . . . . . . . . . . . . . . . . . . . . 33 Application . . . . . . . . . . . . . . . . . . . . . 31
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 34 4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Session Termination Attribute . . . . . . . . . . . . . . 35 4.2. Session Termination Attribute . . . . . . . . . . . . . . 34
4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 36 4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 36 4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 35
4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 37 4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 36
4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 37 4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 36
4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 37 4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 36
4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 37 4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 36
4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 38 4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 36
4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 38 4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 37
4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 38 4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 37
4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 38 4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 37
4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 38 4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 37
4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 39 4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 38
4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 39 4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 38
4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 39 4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 39
4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 40 4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 39
4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 40 4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 39
4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 40 4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 39
4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 40 4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 39
4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 41 4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 40
4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 41 4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 40
4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 42 4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 41
4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 42 4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 42
4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 43 4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 42
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 43 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 42
5. Translation between RADIUS prepaid and Diameter Credit 5. Translation between RADIUS prepaid and Diameter Credit
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1. Session Identification . . . . . . . . . . . . . . . . . . 45 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 . . . . . . . . . . . . 45 Credit Control AAA infrastructure . . . . . . . . . . . . 45
5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 46 5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 45
5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 46 5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 46
5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 46 5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 46
5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 46 5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 46
5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 47 5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 47
5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 47 5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 47
5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 48 5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 48
5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 48 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) . . . . . . . . . . . . . . . . . . . . . . . . 48 (s->c) . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 48 5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 48
5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 50 5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 50
5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 50 5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 50
5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 50 5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 50
5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 50 5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 50
5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 51 5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 51
5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 51 5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 51
5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 51 5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 51
5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 52 5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 51
5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 52 5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 52
5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 52 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 52
5.3. Translation between Diameter Credit Control client and 6. Security Considerations . . . . . . . . . . . . . . . . . . . 53
RADIUS-based AAA infrastructure . . . . . . . . . . . . . 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
5.3.1. CC-Correlation-Id Attribute ( ) . . . . . . . . . . . 53 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2. CC-Request-Number Attribute (c <-> s) . . . . . . . . 53 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.3. CC-Request-Type Attribute ( ) . . . . . . . . . . . . 53 9.1. Normative References . . . . . . . . . . . . . . . . . . . 56
5.3.4. CC-Session-Failover Attribute ( ) . . . . . . . . . . 53 9.2. Informative References . . . . . . . . . . . . . . . . . . 56
5.3.5. CC-Sub-Session-Id Attribute ( ) . . . . . . . . . . . 53 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 57
5.3.6. Check-Balance-Result Attribute ( ) . . . . . . . . . . 53 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 57
5.3.7. Cost-Information Attribute ( ) . . . . . . . . . . . . 53 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 60
5.3.8. Unit-Value Attribute ( ) . . . . . . . . . . . . . . . 53 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 64
5.3.9. Exponent Attribute ( ) . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.10. Value-Digits Attribute ( ) . . . . . . . . . . . . . . 54 Intellectual Property and Copyright Statements . . . . . . . . . . 72
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 an extension for the RADIUS protocol. This This document specifies an extension to the RADIUS protocol that
extension enables service providers to charge their "prepaid enables service providers to perform accounting and charging in an
subscribers". "online" fashion. In particular, they enable the service provider to
(a) ensure that subscriber's remaining funds suffice before the
A prepaid subscriber is a user who maintains a prepaid account with service is delivered, and (b) interrupt service provision when the
the service provider. Every time the prepaid subscriber requests a funds are exhausted. Note that these capabilities are typically used
service, the service provider must ensure that sufficient funds in scenarios where the subscriber maintains a prepaid account with
remain in the subsriber's prepaid account before delivering the the service provider; hence, this extension is called the "prepaid"
service. Only if suffiecient funds are available is the service extension for RADIUS. Also note that the above capabilities are not
provided to the subscriber. This is in contrast to post-paid provided by the base RADIUS protocol.
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 extension defined in this document is It has been observed that subscribers prefer prepaid accounts to
to increase participation (i.e. a service provider's subscriber base) postpaid ones in many circumstances. Indeed, it is expected that
and thus to increase revenues. In particular, the extensions were offering a "prepaid mode of operation" will enabe service providers
designed with the following goals in mind. to expand their existing customer bases. This is the main business
driver behind the extensions defined in this document. The
extensions were 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
the interworking of RADIUS-based and Diameter-based enabling 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 an "online"
fashion,
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 do not suffice, 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
protocol, with the extension defined in this document, assumes that protocols, with the extensions 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 is performed at a provides the service. Instead, the rating may be 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". The rating may, of course, occur in an entity "prepaid server". Alternatively, the actual rating may occur in an
behind this prepaid server. However, for the purposes of exposition, entity behind this prepaid server. Furthermore, business logic may
in this document it is assumed that that rating occurs in the prepaid dictate a time-dependent tariff model, for example that the price for
server. Furthermore, business logic may dictate a time-dependent a service may switch at 8pm from a high to a low tariff. The
tariff model, for example that the price for a service may switch at extensions defined in this document support such scenarios.
20:00 from a high to a low tariff. The extensions defined in this
document support such scenarios.
This documents assumes an architecture where a "quota server" is Furthermore, this document assumes an architecture where a "quota
available which, through co-ordination with the rating entity and a server" is available which, through co-ordination with the rating
centralized account balance manager, is able to provide a quota entity and a centralized account balance manager, is able to provide
indication for a particular user when requested. This quota server a quota indication for a particular user when requested. This quota
may or may not coexist in the prepaid server. 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", o Network Access Server (NAS): As defined in RADIUS.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
This document also makes use of the following terms:
Network Access Server (NAS):
As defined in RADIUS [2].
Prepaid client (PPC):
The entity which triggers the RADIUS message exchange, including
the prepaid extensions defined in this document. The PPC
typically resides in the NAS.
Prepaid Server (PPS):
The entity that interacts with the PPC using the RADIUS prepaid
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:
The network which contains the user profile and the user's prepaid
account.
RADIUS Prepaid (RPP): o Prepaid client (PPC): The entity which triggers the RADIUS message
exchange, including the prepaid extensions defined in this
document. The PPC typically resides in the NAS.
The RADIUS base protocol together with the extension defined in o Prepaid Server (PPS): The entity that interacts with the PPC using
this document. the RADIUS prepaid extensions defined in this document.
Diameter Credit Control (DCC): o Home Network: The network which contains the user profile and the
user's prepaid account.
The Diameter Credit Control Application. o Authorize-Only Access Request: A RADIUS message of type "Access
Request" (code field=1) that contains a "Service-Type" AVP
(type=6) with value "Authorize-Only".
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 document.
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. 10 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 document assumes that the user maintains a prepaid account with This draft assumes that the user maintains a prepaid account with his
his home network. However, whether this account is a dedicated home network. This account may be used to fund multiple services,
prepaid account or not (such as a current bank account) is outside some of which may use the extensions defined in this document, and
the scope of this document. Similarly, the means by which the some may use other mechanisms. The interworking of these mechanisms
subscriber obtains funds is also outside the scope of this document. is outside the scope of this document. Similarly, the means by which
In some scenarios, the subscriber's account may be used to fund the subscriber obtains funds is also outside the scope of this
multiple services, some of which may use the extensions defined in document.
this documents, and some may use other mechanisms. While the
interworking of the mechanisms described in this document with other
mechanisms should be possible and straightforward, the specification
of how this could be done depends on the external mechanisms and is,
as such, outside the scope of this document.
1.2.1. Architectural Model 1.2.1. Architectural Model
The protocol extensions described in this document assumes that the The protocol extensions described in this draft 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 Network Access to the users, and typically coincides with the NAS. The SAD
Server (NAS), as this is defined in [2]. The SAD executes the executes the RADIUS client which, for the purposes of this
RADIUS client which, for the purposes of this document, is termed document, is termed the "PrePaid Client" (PPC). When the prepaid
the "PrePaid Client" (PPC). When the prepaid service is used, the service is used the SAD collects service event information and
SAD collects service event information and reports it while or reports it while services are provided to the user. This event
after services are provided to the user. This event information information is sent to the PPS using the extensions defined in
is sent to the PPS using the extensions defined in this document. 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 the available
credit to the service event. credit to the service event.
o The rating and quota server: This server allocates an amount of o The rating entity: This entity converts the credit that is
credit to the user. This credit is converted into an amount of allocated by the PPS into a time or volume amount, called the
time or volume, called the "quota". This quota is then returned "quota". This quota is then returned to the requesting PPC (SAD)
to the requesting PPC (SAD) (via the PPS). The rating entity may (via the PPS). The rating entity may also determine that during
also determine that during service provision a tariff switch will service provision a tariff switch will occur. In this case the
occur. In this case, the rating entity also includes information rating entity will include details of when exactly tariff switch
of when exactly this tariff switch occurs into the message that is will occur.
sent to the PPS.
The requesting SAD (PPC) monitors the provision of the service
according to the instructions returned by the PPS. After service
completion or on a subsequent request for service, the PPS deducts
the amount of credit that corresponds to the consumed service from
the user account. When a user terminates an on-going service, the
PPC informs the PPS with a suitable indication about the unused
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 The requesting PPC (SAD) meters the consumption of the service
balancing. The system MAY also employ multiple rating servers. according to the instructions provided by the PPS. After service
Prepaid accounts may be located in a centralized database. The completion, or on reception of a subsequent request for service, the
detailed architecture of the system and its interfaces are outside PPS deducts the corresponding amount of credit from the user account.
the scope of this specification. When a user terminates an on-going service, the PPC informs the PPS
with a suitable indication about the unused portion of the allocated
quota. The PPS then refunds the user account accordingly. Note that
multiple PPSs may be deployed for reasons of redundancy and load
sharing. The system MAY also employ multiple rating servers.
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 |
+------------+ IKEv2 +-----------+ | +--------------+ +------------+ IKEv2 +-----------+ | +--------------+
... etc (PPC) | ... etc (PPC) |
| |
| +--------------+ | +--------------+
+------>| Prepaid | +------>| Prepaid |
prepaid | Server | prepaid | Server |
extension +--------------+ protocol +--------------+
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 MAY be
entities. The real configuration MAY combine them into a single combined. The SAD must have the ability to meter the consumption of
host. The SAD must be able to meter the consumption of resources a prepaid data session. This metering is typically based on time
(e.g. time or volume) for a prepaid data session. (i.e. seconds) or volume (i.e. octets).
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 specified in RFC 3576. messages as per RFC 3576.
There exist three types of AAA server, as follows. This document assumes that the PPS is used as the AAA server. There
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 server of a broker and the HAAA are connected via the BAAA of a broker network.
network.
This document assumes that the PPS is used as the HAAA server. Of This document assumes that the PPS communicates with the HAAA for the
course, in reality, the PPC may communicates with the HAAA for the purposes of authentication and authorisation. The PPS, in turn,
purposes of authorisation. As mentioned earlier, the PPS is also interfaces to entities which
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 server), and o rate access service requests in real-time (Rating Engine), and
o manage quota for a particular prepaid service (quota server).
Of course, the balance manager, rating server, and quota server may o manage quota for a particular prepaid service (Quota Server).
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 The above entities belong to the service provider's backend
section. The first scenario is depicted in Figure 2. In this infrastructure and are outside the scope of this specification. In
scenario, the SAD (which runs the PPC), the HAAA, and the PPS are particular, as far as this specification is concerned, they are
located in the same administrative domain. assumed to exist in the PPS. Three deployment scenarios are
presented in the remainder of 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 located in the same provider network.
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 11, line 49 skipping to change at page 9, line 47
| 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 12, line 40 skipping to change at page 10, line 40
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 charging? This could lead to a solution where no code has to prepaid scenarios? This could lead to a solution where no code has
be modified at existing devices. to be modified at existing devices.
It is indeed possible to construct a solution for prepaid charging It is indeed possible to construct a solution for prepaid scenarios
scenarios using existing RADIUS attributes. The RADIUS server would using existing RADIUS attributes. The RADIUS server would send an
send an Access-Accept message containing a Session-Timeout(27) and Access-Accept message containing a Session-Timeout(27) and include a
include a Termination-Action(29) in the RADIUS-request. Upon Termination-Action(29) in the RADIUS-request. Upon receiving the
receiving the Access-Accept message, the NAS would meter the duration Access-Accept message, the NAS would meter the duration of the
of the session and upon termination of the session the NAS would session and upon termination of the session the NAS would generate an
generate an Access-Request message again. The RADIUS server would Access-Request message again. The RADIUS server would then re-
then re-authenticate the session and reply with an Access-Accept authenticate the session and reply with an Access-Accept message
message indicating the amount of additional time in a Session- indicating the amount of additional time in a Session-Timeout(27).
Timeout(27). Alternatively, it could respond with an Access-Reject Alternatively, it could respond with an Access-Reject message if
message if there were no more resources in the user account. 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 shortcomings, Unfortunately, the above "solution" has a number of drawbacks,
including the following. including the following.
o It only supports time-based rating. The solution presented in o It only supports time-based charging. The solution presented in
this document supports both time and volume based prepaid. this document supports multiple charging metrics.
o Using accounting messages to recoup unused time may be problematic o Using accounting messages to recoup unused time may be problematic
because it is not required that RADIUS accounting messages are because RADIUS accounting messages are not delivered in real-time.
delivered in real-time. A RADIUS server may store-and-forward A RADIUS server may store-and-forward accounting messages in
accounting messages in batches. Thus, relying on accounting batches. Thus, relying on accounting messages for the purposes of
messages for the purposes of prepaid charging may cause revenue prepaid may cause revenue leakage. The solution presented in this
leakage. The solution presented in this document does not rely on document does not rely on Accounting packets at all. It uses
Accounting packets at all. It uses Access-Request messages, which Access-Request messages, which are required to flow through any
are required to flow through the network in real-time. 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 served by a NAS that does not adhere to Session-
Session-Timeout then that subscriber may use the service for an 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
support of Termination-Action(29) is not mandatory. Secondly, behaviour 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 the user experience would be affected if is unclear whether or not user experience would be affected if
this attribute would be used as a means to request additional this attribute would be used in a prepaid scenario. The RADIUS
quota in a prepaid charging context. The RADIUS server might even server might even allocate a new IP address to the subscriber
allocate a new IP address to the subscriber device after a device after a Termination-Action. Also, the RADIUS server has no
Termination-Action. Also, the RADIUS server has no way of telling way of telling why a given Access-Request message was generated.
why a given Access-Request message was generated. The RADIUS The RADIUS server might have to wait for the corresponding
server might have to wait for the corresponding accounting packet accounting packet to determine the reason. Finally, re-
to determine the reason. Finally, re-authenticating the authenticating the subscriber may take too long. The solution
subscriber may take too long. The solution presented in this presented in this document allows quota replenishing to occur
document allows quota replenishing to occur without affecting user without affecting user experience. No re-authentication is
experience. No re-authentication is required and quotas can be required and quotas can be negotiated before the available credit
negotiated before the available credit actually runs out. 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. an
Home Agent) that supports prepaid, or to provide only a restricted Home Agent) that supports prepaid, or cause it to provide only a
service. restricted 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 packet in order to obtain and that they generate an Access-Request packet with Service-
more quota when or before the currently allocated quota is consumed. Type="Authorize-Only" in order to obtain more quota when or before
It also requires the NAS to send an Access-Request when the session the current quota is used up. It also requires the NAS to send an
Access-Request with Service-Type="Authorize-Only" when the session
terminates in order to refund the subscriber account. terminates in order to refund the subscriber 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 serving the subscriber PANA), as usual, the NAS (SAD) that is servicing the subscriber
uses the AAA infrastructure in order to authenticate and uses the AAA infrastructure in order to authenticate and
authorize the subscriber (if such network accesss authentication authorize the subscriber with respect to the requested service.
is required). In order to do this, it sends a RADIUS Access-Request to the AAA
server. This Access-Request contains the subscriber's
2. The SAD sends a RADIUS Access-Request to the AAA server in order
to authenticate and authorise the subscriber with respect to the
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 2. 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
determines that the subscriber is a prepaid subscriber and determines that the subscriber is a prepaid subscriber and
requests authorisation from the PPS. The request MUST include requests authorisation from the PPS. This 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 3. The PPS, possibly with the help of the backend infrastructure,
that the account is active. It further validates that the SAD validates that the subscriber has a prepaid account and that the
has the appropriate prepaid capabilities. If all is in order, account is active. It further validates that the SAD has the
the PPS authorises the subscriber to use the network. Otherwise appropriate prepaid capabilities. If all is in order, the PPS
it rejects the request. The decision is sent to the AAA system. authorises the subscriber to use the network. Otherwise it
The response includes attributes to indicate the allocation of a rejects the request. The decision is sent to the AAA system in
the form of a response message. In the case of success, this
message contains attributes that 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" and is expressed in units of time or volume, and "initial quota" and is expressed in units of time or volume. The
may also include an optional threshold value. Note that only a response may also include a threshold value. Note that only a
portion of the user's funds is allocated because the user may be portion of the user's funds is allocated because the user may be
engaged in other services that may draw on the same account. For engaged in other services that may draw on the same account. For
example, the user may be engaged in a data session and a voice example, the user may be engaged in a data session and a voice
session. Although these two services draw from the same account, session. Although these two services would draw from the same
they form separate parts of the overall system. If the entire account, they form separate parts of the overall system. If the
quota was allocated to the data session then the user would have entire quota was allocated to the data session then the user
no more funds for a voice session. would have no more funds for a voice session.
5. The AAA system incorporates the attributes received from the PPS 4. 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 5. 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 consumption of the service approaches as certain point 6. Once the consumption approaches the allocated limit (as expressed
(e.g. as expressed by the threshold), the SAD will request by the threshold), the SAD will request additional quota. Re-
additional quota. Re-authorization for additional quota flows authorization for additional quota flows through the AAA system
through the AAA system to the PPS. The PPS revalidates the to the PPS. The PPS revalidates the subscriber account and
subscriber account and subtracts the previously allocated quota subtracts the previously allocated quota from the current
from the current balance. If there is remaining balance, it balance. If there is remaining balance, it reauthorizes the
authorizes the request with an additional quota allotment. request with an additional quota allotment. Otherwise, the PPS
Otherwise, the PPS rejects the request. Note that the rejects the request. Note that the replenishment of the quota is
replenishment of the quota is a re-authorization procedure and a re-authorization procedure and does not require the subscriber
does not require the subscriber to authenticate himself again. to authenticate himself again.
8. Upon receiving the new quota, the SAD continues to provide the 7. Upon receiving a re-allotment of the quota, the SAD continues to
data service until the new threshold is reached. If the request provide the data service until the new threshold is reached. If
for additional quota cannot be fulfilled then the SAD lets the the request for additional quota cannot be fulfilled then the SAD
subscriber use the remaining quota and terminates the session. lets the subscriber use the remaining quota and terminates the
Alternatively, instead of terminating the session, the SAD may session. Alternatively, instead of terminating the session, the
restrict the data session such that the subscriber can only reach SAD may restrict the data session such that the subscriber can
a particular web server. This web server may be used to enable only reach a particular web server. This web server maybe used
the subscriber to replenish his account. This restriction can to allow the subscriber to replenish his account. This
also be used to allow new subscribers to set up prepaid accounts restriction can also be used to allow new subscribers to set up
in the first place. prepaid accounts in the first place.
9. If the subscriber terminates the session before the allocated 8. Should the subscriber terminate the session before the quota is
quota is entirely consumed, the credit that corresponds to the exhausted, the remaining balance allotted to the session MUST be
portion of the quota that was not consumed, MUST be refunded into refunded into his account.
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
must be refunded to the subscribers account in this case. Also note will have to be credited back to the subscribers account in this
that the PPS maintains session state for the subscriber. This state case. Also note that the PPS maintains session state for the
includes how much account balance was allocated during the last quota subscriber. This state includes how much account balance was
enquiry and how much is left in the account. Therefore, it is allocated during the last quota enquiry and how much is left in the
required that all messages about the session reach the same (and account. Therefore, it is required that all messages about the
correct) PPS. session reach the same (and correct) PPS.
For a simple message flow, along the lines of this use case, see For a simple message flow, along the lines of this use case, please
Appendix A. see 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
extensions defined in this draft. extensions specified in this document.
2.1. Multiple Concurrent Services 2.1. Multiple Concurrent Services
Browsing the web, participating in a VoIP conversation, watching Examples of services that the user may be using are browsing the web,
streaming video, and downloading a file are examples of services that participating in a VoIP conversation, watching streaming video and
the user may wish to use. Some operators may want to distinguish downloading a file. Some operators may want to distinguish between
between these services in terms of charging. Some services may have these services. Some services are charged at different rates and
to be charged at different rates, and may have to be metered services may be metered differently. Therefore, the prepaid solution
differently. Therefore, the prepaid solution needs to be able to needs to be able to distinguish services, and allocate quota to the
distinguish services, and allocate quota to the services using services using different unit types (time, volume) and allow for
different unit types (time, volume) and allow for those quotas to be those quotas to be consumed at different rates.
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 single RADIUS prepaid session may be As shown in Figure 4, a session may be associated with multiple (N)
associated with multiple (N) services. Each service is identified by services. Each service is identified by a service identifier
a service identifier (Service-ID). The format of the Service-ID is (Service-ID). The format of the Service-ID is not in the scope of
not in the scope of this document but it could be expressed as an IP this document but it could be expressed as an IP flow using the
flow using the 5-tuple {Source-IP and Port, Destination-IP and Port, 5-tuple {Source-IP and Port, Destination-IP and Port, protocol type}.
protocol type}. Each service is associated with a quota metric. An Each service is associated with a quota metric. An example message
example message flow that involves multiple such services within a flow that involves multiple such services within a single session is
single session is given in the appendix. 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, it is SAD would then have to terminate the former service. Moreover, if
likely that each service generates a certain amount of RADIUS prepaid each service generates a certain amount of RADIUS prepaid traffic.
traffic. In an environment with many users and charged services, In an environment with many users and chargarble services, this
this amount of traffic may become a considerable overhead that could amount of traffic is considerable and could cause undesirable network
lead to inefficiency. congestion.
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 18, line 48 skipping to change at page 16, line 47
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 can rated at $0.10 per minute. In this case if $5 worth of resources
resources are allocated for service-A to the pool and if Ma = 10, are allocated for service-A to the pool and if Ma = 10, then 50 units
then 50 units would be placed into the pool. If a further $5 are would be placed into the pool. If a further $5 are allocated for
allocated for service-B to the pool, then M=1 and 50 units are service-B to the pool, then M=1 and 50 units are deposited into the
deposited into the pool. The pool would then have a total sum of 100 pool. The pool would then have a sum of 100 units to be shared
units to be shared between the two services. The PPC would then between the two services. The PPC would then meter the services such
mater the services such that each Mbyte used by Service-A will draw that each Mbyte used by Service-A will draw 10 units from the pool
10 units from the pool and each minute used by Service-B will draw 1 and each minute used by Service-B will draw 1 unit from the pool.
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 in the prepaid system.
To avert the need to exchange many messages while still supporting To avert the need to exchange many messages while still supporting
such complex rating functions, the notion of a "Rating Group" is such complex rating functions, the notion of a "Rating Group" is
introduced. A Rating Group are typically configured at the SAD. As introduced. A Rating Group are typically configured at the SAD. As
shown in Figure 7, a Rating Group is associated with one or more shown in Figure 7, a Rating Group is associated with one or more
services and defines the rate that the services associated with the services and defines the rate that the services associated with the
Rating Group consume an allocated amount of quota. Rating Group consume an allocated amount of quota.
+--------------+ +--------------+ +--------------+ +--------------+
+-----------+ N 1 | | M 1 | Resource Pool| +-----------+ N 1 | | M 1 | Resource Pool|
skipping to change at page 20, line 14 skipping to change at page 18, line 10
2.4. One-time Charging 2.4. One-time Charging
One-time charging is a mode of operation of where the RADIUS prepaid One-time charging is a mode of operation of where the RADIUS prepaid
extensions are used for charging of a service that is provided extensions are used for charging of a service that is provided
instansteneously, i.e. without an ongoing session. An example of instansteneously, i.e. without an ongoing session. An example of
such an event is the purchase of a ring-tone. Subscription based such an event is the purchase of a ring-tone. Subscription based
services can also be modeled as a one-time event. In this case the services can also be modeled as a one-time event. In this case the
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 charging may occur in parallel with other
other charging models. For example, the subscriber may access a charging models. For example, the subscriber may access a website
website which is metered (based on time or volume) while he also which is metered (based on time or volume) while he also purchases
purchases the right to use a ring tone (a one-time-based event). the right to use a ring tone (a one-time-based event). Note: it is
Note: it is up to the service providers to decide whether or not the up to the service providers to decide whether or not the user will be
user will be charged for the download of the tone and also be charged charged for the download of the tone and also be charged for the time
for the time and volume required to download the ring-tone. The and volume required to download the ring-tone. The facilities
facilities provided by this document gives the service provider the provided by this document gives the service provider the capability
ability to achieve their service charging business goals. For to achieve their service charging business goals. For example,
example, should the service provider choose not to charge for the should the service provider choose not to charge for the download
download volume or time, then they can treat the download IP flow as volume or time, then they can treat the download IP flow as a
a separate service that is not subject to charging. 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 charging to the PPS with an indication that
that identifies the service and the units that should be debited from identifies the service and the units that should be debited from the
the user account. user account.
A SAD may decide to perform one-time-based charging for an event that A SAD may decide to perform one-time charging for an event that was
was triggered by an unauthenticated user. In this case case the SAD triggered by an unauthenticated user. In this case case the SAD will
will have to authenticate the user before sending the relevant have to authenticate the user before sending the relevant message to
message to the user's home AAA server. the user's home AAA server.
Note that one-time-based charging can also be used to credit the Note that one-time charging can also be used to credit the prepaid
prepaid account. For example, the SAD can return resources to the account. For example, the SAD can return resources to the subscriber
subscriber by issuing a one-time charge request that includes the by issuing a one-time charge request that includes the amount of
amount of resources to be credited into the account. 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 mechanism described
shown in Figure 8, traffic before 18:00 may be rated at rate r1 and in this section. This mechanism is useful if, for example, as shown
traffic after 18:00 is rated at rate r2. The PPC reports two in Figure 8, traffic before 18:00 is rated at rate r1 and traffic
indications about the consumed quota: one before and one after the after 18:00 is rated at rate r2. The mechanism requires the PPC to
tariff switch occurred. report usage before and after the switch occured.
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)
Figure 8: Example of tariff switching Figure 8: Example of tariff switching
The PPC it indicates support for tariff switching by setting the The PPC it indicates support for tariff switching by setting the
appropriate bit in the PPAC. If the PPS needs to signal a tariff appropriate bit in the PPAC. If the PPS needs to signal a tariff
switch time it will send a PTS attribute which indicates the point in switch time it will send a PTS attribute which indicates the point in
time when the switch will occur. This indication represents the time when the switch will occur. This indication represents the
number of seconds from current time (TarrifSwitchInterval TSI). number of seconds from current time (TariffSwitchInterval TSI).
At some point after the tariff switch the PPC sends another Access- At some point after the tariff switch the PPC sends another Access-
Request, as a result of either the user having logged off or the Request, as a result of either the user having logged off or the
volume threshold being reached. The PPC reports how much volume was volume threshold being reached. The PPC reports how much volume was
used using the PPAQ in total and how much volume was used after the used in total (in a PPAQ attribute) and how much volume was used
tariff switch using the PTS VUATS subtype. after the tariff switch (in a PTS VUATS subtype attribute).
In situations with multiple tariff switches, the PPS must specify the In situations with multiple tariff switches, the PPS must specify the
length of the tariff switch period using the length of the tariff switch period using the
TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as
shown below. shown below.
18:00 23:30 18:00 23:30
------------------+---------------------+-------------- ------------------+---------------------+--------------
r1 | r2 | r3 r1 | r2 | r3
------------------+---------------------+-------------- ------------------+---------------------+--------------
skipping to change at page 21, line 50 skipping to change at page 19, line 50
| | | |
Access-Accept Access-Request Access-Accept Access-Request
Figure 9: Multiple tariff switches Figure 9: Multiple tariff switches
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. The TITSU attribute ensures that, even in this case, the PPC will
Also note that separate services flows may have individual tariff generate the new Access-Request in good time.
periods.
Note that it makes no sense to use this tariff switching mechanism Note that it makes no sense to use the tariff switching mechanism
for services that are charged based on time, and that are consumed described in this section for services that are metered based on time
continuously (i.e. without interruption). This is because the PPS and the consumption of which is continuous (i.e. without
can rate these services without the help of the PPC, i.e. it can interruption). Also note that separate services flows may have
calculate how much of the service was consumed in each tariff period individual tariff periods.
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 22, line 44 skipping to change at page 20, line 42
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 ensure that the user is not charged for this the session in order to make sure that the user is not charged for
potential inactivity. this 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 36 skipping to change at page 22, line 36
message to the Access-Request. Upon receiving the Change-of- message to the Access-Request. Upon receiving the Change-of-
Authorization message, the AAA server would then be responsible for Authorization message, the AAA server would then be responsible for
terminating the session using the means that are supported by the terminating the session using the means that are supported by the
device. device.
If the authentication procedure involves multiple message exchanges If the authentication procedure involves multiple message exchanges
(as in EAP), the SAD MUST include the PPAC(TBD) attribute and the (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the
Dynamic-Capabilities attribute (if used) in at least the last Access- Dynamic-Capabilities attribute (if used) in at least the last Access-
Request of the authentication procedure. Request of the authentication procedure.
The Access-Request is sent as usual to the HAAA, possibly through one The Access-Request is sent, as usual, to the HAAA, possibly through
or more BAAA. one or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA authenticates Once the Access-Request arrives at the HAAA, the HAAA authenticates
the subscriber. If this fails, the HAAA sends an Access-Reject the subscriber. If this fails, the HAAA sends an Access-Reject
message to the client. If authentication succeeds, the HAAA message to the client. If authentication succeeds, the HAAA
determines whether or not the subscriber is a prepaid subscriber. determines whether or not the subscriber is a prepaid subscriber.
(How this is done is beyond the scope of this document.) If the (How this is done is beyond the scope of this document.) If the
subscriber is not a prepaid subscriber, then the HAAA responds as subscriber is not a prepaid subscriber, then the HAAA responds as
usual with an Access-Accept or an Access-Reject message. If the usual with an Access-Accept or an Access-Reject message. If the
subscriber is a prepaid subscriber then the HAAA SHALL forward the subscriber is a prepaid subscriber then the HAAA SHALL forward the
Access-Request to the PPS for further authorization. Access-Request to the PPS for further authorization.
skipping to change at page 25, line 28 skipping to change at page 23, line 28
o Volume and/or Time quota, which is set to a value representing a o Volume and/or Time quota, which is set to a value representing a
portion of the subscriber's credit. portion of the subscriber's credit.
o It MAY contain a Time or Volume Threshold that indicates when the o It MAY contain a Time or Volume Threshold that indicates when the
SAD should request additional quota. SAD should request additional quota.
o The IP address of the Serving PPS and one or more alternative o The IP address of the Serving PPS and one or more alternative
PPSs. This is used by the HAAA to route subsequent quota PPSs. This is used by the HAAA to route subsequent quota
replenishing messages to the appropriate PPS(s). replenishing messages to the appropriate PPS(s).
o A State attribute, as defined in RFC 2865. This is necessary in
order to satisfy the requirements of section 5.44 of RFC 2865,
which mandates that an Access-Request with Service-
Type="Authorize-Only" must contain a State attribute. Since the
SAD sends subsequent quota replenishment requests in the form of
such "Authorize-Only" requests, a State attribute MUST be present
in all Access-Accept messages that also carry a PPAQ attribute.
Note: The Idle-Timeout(28) attribute can be used to trigger the Note: The Idle-Timeout(28) attribute can be used to trigger the
premature termination of a prepaid service, for example as a result premature termination of a prepaid service, for example as a result
of inactivity. of inactivity.
Depending on site policies, after failed authorization, the PPS may Depending on site policies, after failed authorization, the PPS may
generate an Access-Reject in order to terminate the session generate an Access-Reject in order to terminate the session
immediately. Alternatively, the PPS may generate an Access-Accept immediately. Alternatively, the PPS may generate an Access-Accept
blocking some or all of the traffic and/or redirect some or all of blocking some or all of the traffic and/or redirect some or all of
the traffic to a location to a fixed server. (This feature could be the traffic to a location to a fixed server. (This feature could be
used, for example, to prompt the user to replenish their account.) used, for example, to prompt the user to replenish their account.)
skipping to change at page 26, line 7 skipping to change at page 24, line 16
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
A session is deemed to be 'active' at the home AAA server once the The start of the session is indicated by the arrival of an
authentication process has been successfully completed. The arrival Accounting-Request(Start) packet. The Accounting-Request (Start) MAY
of an Access Request at the PPS means that authentication has be routed to the PPS such that it can confirm the initial quota
successfully completed because otherwise the home AAA server would allocation.
not forward it to the PPS. A session being active, however, does not
necessarily mean that the user has actually started using the
service.
The PPS may deduce that the user has actually consumed some service Note that the role of the PPS is not to record accounting messages
(i.e. consumed some of the allocated quota) by either the reception and therefore it SHOULD NOT respond with an Accounting Response
of an Accounting-Request(Start) packet, or the reception of an Access packet. If the PPS does not receive the Accounting-Request(start)
Request message that asks for quota replenishment. The Accounting- message it will only know that the session has started upon the first
Request (Start) MAY be routed to the PPS such that it can confirm reception of a quota replenishment operation.
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 any of the above two indications that the If the PPS does not receive indication directly (via Accounting-
user has started consuming the service, it SHOULD, after some Request(start)) or indirectly, it SHOULD, after some configurable
configurable time, terminate the session. If the SAD supports time, deduce that the Session has not started. 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 a 'mid-session' prepaid-specific replenishment of the quotas using an Authorize-Only Access-Request
Access-Request message. Such a message MUST include NAS identifiers, message. Once either the allocated quota has been exhausted or the
a Session identifier attribute, and at least one PPAQ attribute. The threshold has been reached, the SAD MUST send an Access-Request with
home AAA server or the PPS that receives such a message classifies it Service-Type(6) set to a value of "Authorize-Only" and the PPAQ
as 'mid-session' if it refers to an active session, i.e. the NAS attribute.
identifier, session identifier, and possibly other AVPs match those
of an active session. Which exactly AVPs are required to match in
order to map a message to a session depends on the deployment
scenario and applicable policies. Certain AVPs are also used to
route the message through proxies. For example, if the User-Name(1)
attribute was used in the initial Access-Request, it MUST be included
any subsequent Access-Requests, especially if the User-Name(1)
attribute is used to route the Access-Request to the Home AAA server.
The mid-session Access-Request MUST NOT include a User Password and The SAD MUST also include NAS identifiers, and Session identifier
MUST NOT include a Chap Password. In order to enable the receiver to attributes in the Authorize-Only Access-Request. The Session
authenticate the message, the SAD MUST include a Message- Identifier should be the same as the one used during the initial
Authenticator(80) attribute. The SAD computes the value for the Access-Request. For example, if the User-Name(1) attribute was used
Message-Authenticator according to RFC 2869. in the Access-Request it MUST be included in the Authorize-Only
Access-Request, especially if the User-Name(1) attribute is used to
route the Access-Request to the Home AAA server.
When the HAAA receives an Access-Request that contains a PPAQ(TBD), The Authorize-Only Access-Request MUST NOT include a User Password
it SHALL validate the message using the Message-Authenticator(80), and MUST NOT include a Chap Password. In order to enable the
according to RFC 2869. If the HAAA receives an Access-Request that receiver to authenticate the message, the SAD MUST include a Message-
contains a PPAQ(TBD) and either no or an invalid Message- Authenticator(80). In order to satisfy the requirements of section
Authenticator(80) it SHALL silently discard the message. A mid- 5.44 of RFC 2865, the SAD MUST also include the State attribute. It
session Access-Request message that does not contain a PPAQ(TBD) is is anticipated that the inclusion of the State attribute will enable
either erroneous or belongs to another application (for example, a the PPS to map the Authorize-Only Access Request to the
Change of Authorization message [RFC3576]). In this case the Access- authentication context that was established when the PPC
Request message is either silently discarded or handled by another authenticated itself at the beginning of the session. The SAD
application. computes the value for the Message-Authenticator and the State
attributes according to RFC 2869 and 2865 respectively.
Once the mid-session Access-Request message is validated, the HAAA When the HAAA receives an Authorize-Only Access-Request that contains
SHALL forward it to the appropriate PPS. The HAAA MUST forward the a PPAQ(TBD), it SHALL validate the message using the Message-
Access-Request to the PPS specified in the PPAQ(TBD). The HAAA MUST Authenticator(80), according to RFC 2869. If the HAAA receives an
add a Message-Authenticator(80) to the message, according to RFC Authorize-Only Access-Request that contains a PPAQ(TBD) and either no
2869. As with the initial Access-Request message, the HAAA MAY or an invalid Message-Authenticator(80) it SHALL silently discard the
modify the User-Name(1) attribute such that it identifies the user to message. An Authorize Only Access-Request message that does not
the PPS. Note that the PPS may also use the Quota-ID sub-attribute contain a PPAQ(TBD) is either erroneous or belongs to another
contained within the PPAQ(TBD) to locate the user account. application (for example, a Change of Authorization message
[RFC3576]). In this case the Authorize-Only Access-Request is either
silently discarded or handled by another application.
Upon receiving an Access-Request containing a PPAQ(TBD) attribute, Once the Authorize-Only Access-Request message is validated, the HAAA
the PPS MUST validate the Message-Authenticator(80) as described in SHALL forward the Authorize-Only Access-Request to the appropriate
RFC 2869. If validation fails, the PPS MUST silently discard the PPS. The HAAA MUST forward the Authorize-Only Access-Request to the
message. If it receives a mid-session Access-Request message that PPS specified in the PPAQ(TBD). The HAAA MUST add a Message-
does not contain a PPAQ(TBD), it MUST silently discard the message. Authenticator(80) to the message, according to RFC 2869. As with the
Access-Request message, the HAAA MAY modify the User-Name(1)
attribute such that it identifies the user to the PPS. Note that the
PPS may also use the Quota-ID sub-attribute contained within the
PPAQ(TBD) to locate the user account.
Upon receiving the Authorize-Only Access-Request containing a
PPAQ(TBD) attribute, the PPS MUST validate the Message-
Authenticator(80) as described in RFC 2869. If validation fails, the
PPS MUST silently discard the message. If it receives an Authorize-
Only Access-Request message that does not contain a PPAQ(TBD), it
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 a Message-Authenticator(80). contain Servicetype(6) set to Authorize-Only and MAY contain the
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 28, line 46 skipping to change at page 27, line 10
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 Access-Request containing a PPAQ attribute which PPS by issuing an Authorize-Only Access-Request containing the PPAQ
contains any unused Quota and the Update-Reason set to "Remote Forced which contains any unused Quota and the Update-Reason set to "Remote
Disconnection". Forced 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 29, line 26 skipping to change at page 27, line 36
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 Access-Request message with a PPAQ and Message, the SAD sends an Authorize-Only Access-Request message with
Update-Reason attribute set to either "Client Service Termination" or a PPAQ and Update-Reason attribute set to either "Client Service
"Remote Forced Disconnect". This message indicates the amount of Termination" or "Remote Forced Disconnect". This message indicates
consumed quota. the amount of 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 attribute in the RADIUS Access-Request. In this include the PPAC(TBD) attribute in the RADIUS Access-Request. In
manner, the procedure follows the Authentication and Authorization this manner, the procedure follows the Authentication and
procedure described earlier. Authorization 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 an Specifically, the quota SHOULD be returned when the SAD sends the
Access-Request with PPAQ Update-Reason set to either "Remote Forced Authorize-Only Access-Request with PPAQ(TBD) Update-Reason set to
Disconnect" or "Client Service Termination". In order to trigger the either "Remote Forced Disconnect" or "Client Service Termination".
sending of this last Access-Request, the PPS may issue a Disconnect In order to trigger the sending of this last Authorize-Only Access-
Message [3576] to the SAD. Request, the PPS may issue a Disconnect 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 the prepaid data service can continue. This can be done capabilities can the prepaid data service 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
multiple services, it is necessary to differentiate these services. multi-services, we need to differentiate between the services. A
A Service-Id attribute is used in the PPAQ for this purpose. The Service-Id attribute is used in the PPAQ(TBD) in order to uniquely
exact definition of the Service-Id attribute is outside the scope of differentiate between the services. The exact definition of the
this document. Service-Id attribute is outside the scope of this document.
A PPAQ AVP that contains a Service-Id is associated with that A PPAQ that contains a Service-Id is associated with that Service. A
Service. A PPAQ AVP that contains a Rating-Group-Id is associated PPAQ that contains a Rating-Group-Id is associated with that Rating-
with that Rating-Group. A PPAQ MUST not contain both a Group. A PPAQ MUST not contain both a Rating-Group-Id and a
Rating-Group-Id and a Service-Id. A PPAQ that contains neither a Service-Id. A PPAQ that contains neither a Rating-Group-Id or a
Rating-Group-Id nor a Service-Id applies to the Access Service. 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 Access-Request packet. Similarly, Service-Id for that Service in an Authorize-Only Access-Request
if the SAD supports Rating-Groups then it may request a quota for the packet. Similarly, if the SAD supports Rating-Groups then it may
Rating-Group by sending a PPAQ containing the Rating-Group-Id. In request a quota for the Rating-Group by sending a PPAQ containing the
both cases the Update-Reason is set to "Initial-Request". Rating-Group-Id. In both cases the Update-Reason is set to "Initial-
Request".
The Access-Request message may contain more than one PPAQ, and MUST The Authorize-Only Access-Request message may contain more than one
include one or more attributes that serve to identify the session so PPAQ. The Authorize-Only Access-Request MUST include one or more
that it can be linked to the original authentication. Which Session attributes that serve to identify the session so that it can be
Identifiers are included is up to specific deployments. The message linked to the original authentication. Which Session Identifiers are
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. protection of the Authorize-Only Access-Request message.
Upon receiving an Access-Accept message containing one or more PPAQs, Upon receiving an Authorize-Only Access-Accept message containing one
the PPS allocates resources to each PPAQ. Each PPAQ is assigned a or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ
unique QID that MUST appear in subsequent PPAQ updates for that is assigned a unique QID that MUST appear in subsequent PPAQ updates
service or rating-group. Additionally, the PPAQ MUST contain the for that service or rating-group. Additionally, the PPAQ MUST
Service-ID or Group-ID, unless the PPAQ is the generic "Access contain the Service-ID or Group-ID, unless the PPAQ is the generic
Service". "Access 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 Access-Request message containing one or more PPAQs. the PPC sends an Authorize-Only Access-Request message containing one
Each PPAQ MUST contain the appropriate QID, Service-ID or Group-ID or more PPAQs. Each PPAQ MUST contain the appropriate QID,
(or neither the Service-ID or Group-Id if the quota replenishment is Service-ID or Group-ID (or neither the Service-ID or Group-Id if the
for the "Access Service"). The Update-Reason filed indicates either quota replenishment is for the "Access Service"). The Update-Reason
"Threshold reached"(3), or "Quota reached"(4). The message must filed indicates either "Threshold reached"(3), or "Quota reached"(4).
contain session identifiers. The Authorize-Only message must contain session identifiers.
Upon receiving an Access-Request packet with one or more PPAQs the Upon receiving an Authorize-Only Access-Request packet with one or
PPS responds with a new PPAQ for that service. The PPAQ contains a more PPAQs the PPS responds with a new PPAQ for that service. The
new QID, the Service-Id or Rating-Group-Id, a new Quota. If the PPS PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new
does not grant additional quota to the service it MUST include the Quota. If the PPS does not grant additional quota to the service it
Termination-Action subfield in the PPAQ that will instruct the SAD MUST include the Termination-Action subfield in the PPAQ that will
what to do with the service. instruct the SAD 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 with 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".
If the &#65533;Access Service&#65533; has terminated, then all other If the oAccess Serviceoe has terminated, then all other services must
services must be terminated as well. In this case the SAD MUST be terminated as well. In this case the SAD MUST report on all
report on all issued quotas for the various services. The Update- issued quotas for the various services. The Update-Reason field
Reason field should be set to "Access Service Terminated". should be set to "Access Service Terminated".
3.7.4. Dynamic Operations 3.7.4. Dynamic Operations
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 Access Request SAD MUST report all unused quotas by sending an Authorize-Only Access
message containing a PPAQ for each active service. The Update-Reason Request message containing a PPAQ for each active service. The
shall indicate that the reason for the update. Update-Reason 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 33, line 5 skipping to change at page 31, line 18
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 Access Request. A PPAQ used for One-Time charging may appear in an Authorize-Only
This is the case when the session already exists. The PPS responds Access Request. This is the case when the session already exists.
with an Access-Accept to indicate that the user account has been The PPS responds with an Access-Accept to indicate that the user
debited or an Access-Reject otherwise. account has been 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 8 skipping to change at page 33, line 8
based, or the SAD is Diameter based and the AAA infrastructure is based, or the SAD is Diameter based and the AAA infrastructure is
RADIUS based. RADIUS based.
The Diameter Credit Control Application [DIAMETERCC] describes how to The Diameter Credit Control Application [DIAMETERCC] describes how to
implement a prepaid accounting system using a Diameter based implement a prepaid accounting system using a Diameter based
infrastructure. infrastructure.
4. Attributes 4. Attributes
This section specifies the attributes that implement the RADIUS This section specifies the attributes that implement the RADIUS
extensions for prepaid. The namespace for these attributes is the extensions for prepaid. Their general format follow that of the base
one specified in the RADIUS base protocol [RFC2865]. RADIUS [RFC2865] and take also account current design guidelines that
are proposed in the RADEXT working group. The type field of these
attributes contains a value that is drawn from the type value space
specified in [RFC2865]. The exact value for the type field of each
attribute is to be allocated by IANA. Note that, unless otherwise
specified, the format of the value field of each of the AVPs defined
in this section adheres to one of the formats specified in section 5
of [RFC2865]. In particular, the labels "string", "integer", and
"address" are used to indicate the format in the remainder of this
document.
4.1. PPAC Attribute 4.1. PPAC Attribute
The PrepaidAccountingCapability (PPAC) attribute is sent in the The PrepaidAccountingCapability (PPAC) attribute is sent in the
Access-Request message by a prepaid capable NAS and is used to Access-Request message by a prepaid capable NAS and is used to
describe the prepaid capabilities of the NAS. The PPAC is also describe the prepaid capabilities of the NAS. The PPAC is also
present in an Access-Accept message by the PPS in order to indicate present in an Access-Accept message by the PPS in order to indicate
the type of metering that is to be applied to this session. the type of metering that is to be applied to this session.
0 1 2 3 0 1 2 3
skipping to change at page 35, line 42 skipping to change at page 34, line 42
0x00000010 Rating groups supported 0x00000010 Rating groups supported
0x00000020 Multi-Services supported. 0x00000020 Multi-Services supported.
0x00000040 Tariff Switch supported. 0x00000040 Tariff Switch supported.
Others Reserved Others Reserved
Figure 10: PPAC Attribute Figure 10: PPAC Attribute
4.2. Session Termination Attribute 4.2. Session Termination Attribute
The value shall be bitmap encoded rather than a raw integer. This The value is bitmap encoded. This attribute is included in a RADIUS
attribute shall be included RADIUS Access-Request message to the Access-Request message to the RADIUS server and indicates whether or
RADIUS server and indicates whether or not the NAS supports Dynamic not the NAS supports Dynamic Authorization.
Authorization.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | String | | TYPE | LENGTH | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : value of Session Termination Capability Type : value of Session Termination Capability
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, Access- One or more PPAQ attributes are sent in an Access Request, Authorize-
Request and Access-Accept message. In an Access Request message, the Only Access-Request and Access-Accept message. In an Access Request
PPAQ attribute is used to facilitate One-Time charging transactions. message, the PPAQ attribute is used to facilitate One-Time charging
In Access-Request messages it is used for One-Time charging, report transactions. In Authorize-Only Access-Request messages it is used
usage and the request for further quota. It is also used in order to for One-Time charging, report usage and the request for further
request prepaid quota for a new service instance. In an Access- quota. It is also used in order to request prepaid quota for a new
Accept message it is used in order to allocate the (initial and service instance. In an Access-Accept message it is used in order to
subsequent) quotas. allocate the (initial and 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 a variable length (greater than 8, encoded into one
than 8, encoded into one octet), and consists of a variable number of octet), and consists of a variable number of subtypes. Unused
subtypes. Unused subtypes are omitted from the message. In the subtypes are omitted from the message. In the following subsections
following subsections the various subtypes of the PPAQ attribute are the various subtypes of the PPAQ attribute are specified.
specified.
4.3.1. Quota Identifier AVP 4.3.1. Quota Identifier AVP
The type of the QuotaIDentifier attribute is TBD and its length is 6 The value of the type field of the QuotaIDentifier AVP is TBD. The
octets. This AVP is generated by the PPS together with the length of this AVP is 6 octets. Its value is encoded as a string.
allocation of new quota. The on-line quota update RADIUS Access- It is generated by the PPS together with the allocation of new quota.
Request message that is sent from the SAD to the PPS shall include a The online quota update RADIUS Access-Request message that is sent
previously received QuotaIdentifier. from the SAD to the PPS includes a previously received
QuotaIdentifier AVP.
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 value of the type field of the VolumeQuota AVP is TBD. The
18 octets. This AVP is only present if volume-based charging is length of this AVP is 12 or 18 octets. The AVP is only present if
used. In a RADIUS Access-Accept message (PPS to SAD direction), it volume-based charging is used. In a RADIUS Access-Accept message
indicates the volume (in octets) allocated for the session by the (PPS to SAD direction), it indicates the volume (in octets) allocated
PPS. In an RADIUS Access-Request message (SAD to PPS direction), it for the session by the PPS. In an RADIUS Authorize-Only Access-
indicates the total used volume (in octets) for both inbound and Request message (SAD to PPS direction), it indicates the total used
outbound traffic. The attribute consists of a Value-Digits AVP and volume (in octets) for both inbound and outbound traffic. The
optionally an Exponent AVP (as indicated in the length field). The attribute consists of a Value-Digits AVP and optionally an Exponent
Exponent AVP, if present, MUST NOT encode a negative number or zero. AVP (as indicated in the length field). The Exponent AVP, if
present, MUST NOT encode a negative 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 value of the type field of the VolumeThreshold AVP is TBD and its
or 18 octets. This AVP shall optionally be present if VolumeQuota is length is 12 or 18 octets. This AVP is optionally present if
present in a RADIUS Access-Accept message (PPS to SAD direction). It VolumeQuota is present in a RADIUS Access-Accept message (PPS to SAD
is generated by the PPS and indicates the volume (in octets) that direction). It is generated by the PPS and indicates the volume (in
shall be consumed before a new quota should be requested. This octets) that shall be consumed before a new quota should be
threshold should not be larger than the VolumeQuota. The attribute requested. This threshold should not be larger than the VolumeQuota.
consists of a Value-Digits AVP and optionally an Exponent AVP (as The attribute consists of a Value-Digits AVP and optionally an
indicated by the length field). The Exponent AVP, if present, MUST Exponent AVP (as indicated by the length field). The Exponent AVP,
NOT encode a negative number or zero. if present, MUST NOT encode a negative number or zero.
4.3.4. DurationQuota AVP 4.3.4. DurationQuota AVP
The type of the DurationQuota attribute is TBD and its length is 6 The value of the type field of the DurationQuota AVP is TBD and its
octets. This optional AVP is only present if duration-based charging length is 6 octets. This optional AVP is only present if duration-
is used. In RADIUS Access-Accept message (PPS to SAD direction), it based charging is used. In RADIUS Access-Accept message (PPS to SAD
indicates the duration (in seconds) allocated for the session by the direction), it indicates the duration (in seconds) allocated for the
PPS. It is encoded as an 32 bit unsigned value, in network byte session by the PPS. It is encoded as an integer. In an on-line
order. In an on-line RADIUS Access-Accept message (PPC to PPS RADIUS Access-Accept message (PPC to PPS direction), it indicates the
direction), it indicates the total duration (in seconds) since the total duration (in seconds) since the start of the accounting session
start of the accounting session related to the QuotaID of the PPAQ related to the QuotaID of the PPAQ AVP in which it occurs.
AVP in which it occurs.
4.3.5. DurationThreshold AVP 4.3.5. DurationThreshold AVP
The type of the DurationThreshold attribute is TBD and its length is The value of the type field of the DurationThreshold AVP is TBD and
6 octets. This AVP shall optionally be present if DurationQuota is its length is 6 octets. This AVP shall optionally be present if
present in a RADIUS Access-Accept message (PPS to PPC direction). It DurationQuota is present in a RADIUS Access-Accept message (PPS to
represents the duration (in seconds) after which new quota should be PPC direction). It represents the duration (in seconds) after which
requested. This threshold should not be larger than the new quota should be requested. This threshold should not be larger
DurationQuota. It is encoded as a 32 bit unsigned value, in network than the DurationQuota. It is encoded as an integer.
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 value of the type field of the ResourceQuota AVP is TBD. The
or 18 octets. This optional AVP is only present if resource-based or length of this AVP is 12 or 18 octets. This optional AVP is only
one-time charging is used. In the RADIUS Access-Accept message (PPS present if resource-based or one-time charging is used. In the
to SAD direction) it indicates the resources allocated for the RADIUS Access-Accept message (PPS to SAD direction) it indicates the
session by the PPS. In a RADIUS Access-Request message (SAD to PPS resources allocated for the session by the PPS. In RADIUS Authorize-
direction), it indicates the resources used in total, including both Only Access-Request message (SAD to PPS direction), it indicates the
incoming and outgoing chargeable traffic. In one-time charging resources used in total, including both incoming and outgoing
scenarios, the subtype represents the number of units to charge or chargeable traffic. In one-time charging scenarios, the subtype
credit the user. The attribute consists of a Value-Digits AVP and represents the number of units to charge or credit the user. The
optionally an Exponent AVP (as indicated by the length field). attribute consists of a Value-Digits AVP and optionally an Exponent
AVP (as indicated by the length 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 value of the type field of the ResourceThreshold AVP is TBD. The
18 octets. The semantics of this AVP follow those of the length of this AVP is 12 or 18 octets. The semantics of this AVP
VolumeThreshold and DurationThreshold AVPs. It consists of a Value- follow those of the VolumeThreshold and DurationThreshold AVPs. It
Digits AVP and optionally an Exponent AVP. consists of a Value-Digits AVP and optionally an Exponent AVP.
4.3.8. Value-Digits AVP 4.3.8. Value-Digits AVP
The type of the Value-Digits AVP is TBD and its length is 10 octets. The value of the type field of the Value-Digits AVP is TBD and its
This AVP encodes the most significant digits of a number, encoded as length is 10 octets. This AVP encodes the most significant digits of
a 64 unsigned integer, in network byte order. If decimal values are a number, encoded as an integer. If decimal values are needed to
needed to present the number, the scaling MUST be indicated with a present the number, the scaling MUST be indicated with a related
related Exponent AVP. For example, the decimal number 0.05 is Exponent AVP. For example, the decimal number 0.05 is encoded by a
encoded by a Value-Digits AVP set to 5, and a scaling that is Value-Digits AVP set to 5, and a scaling that is indicated with the
indicated with the Exponent AVP set to -2. Exponent AVP set to -2.
4.3.9. Exponent AVP 4.3.9. Exponent AVP
The type of the Exponent AVP is TBD and its length is 6 octets. This The value of the type field of the Exponent AVP is TBD. The length
AVP contains the exponent value that is to be applied to the of this AVP is 6 octets. This AVP contains the exponent value that
accompanying Value-Digit AVP. It contains a 32 bit signed value, in is to be applied to the accompanying Value-Digit AVP. Its value is
network byte order. encoded as an integer.
4.3.10. Update-Reason AVP 4.3.10. Update-Reason AVP
The type of the Update-Reason AVP is TBD and its length is 4 octets. The value of the type field of the Update-Reason AVP is TBD. The
This AVP shall be present in the on-line RADIUS Access-Request length of this AVP is 4 octets. This AVP shall be present in the on-
message (PPC to PPS direction). It indicates the reason for line RADIUS Access-Request message (PPC to PPS direction). It
initiating the on-line quota update operation. Update reasons 6, 7, indicates the reason for initiating the on-line quota update
8 and 9 indicate that the associated resources are released at the operation. Update reasons 6, 7, 8 and 9 indicate that the associated
client side, and that therefore the PPS shall not allocate a new resources are released at the client side, and that therefore the PPS
quota in the RADIUS Access Accept message. shall not allocate a new quota in the RADIUS Access Accept message.
1. Pre-initialization 1. Pre-initialization
2. Initial Request 2. Initial Request
3. Threshold Reached 3. Threshold Reached
4. Quota Reached 4. Quota Reached
5. TITSU Approaching 5. TITSU Approaching
6. Remote Forced Disconnect 6. Remote Forced Disconnect
7. Client Service Termination 7. Client Service Termination
8. "Access Service" Terminated 8. "Access Service" Terminated
9. Service not established 9. Service not established
10. One-Time Charging 10. One-Time Charging
4.3.11. PrepaidServer AVP 4.3.11. PrepaidServer AVP
The type of the PrepaidServer AVP is TBD and its length is 6 or 18 The value of the type field of the PrepaidServer AVP is TBD. The
octets, for IPv4 and IPv6 addresses respectively. This optional AVP length of this AVP is 6 or 18 octets, for IPv4 and IPv6 addresses
indicates the address of the serving PPS. If present, the Home respectively. This optional AVP indicates the address of the serving
RADIUS server uses this address to route the message to the serving PPS. If present, the Home RADIUS server uses this address to route
PPS. The attribute may be sent by the Home RADIUS server. Multiple the message to the serving PPS. The attribute may be sent by the
instances of this subtype MAY be present in a single PPAQ AVP. Home RADIUS server. Multiple instances of this subtype MAY be
present in a single PPAQ AVP. The value of this AVP is encoded as an
address.
If present in the incoming RADIUS Access-Accept message, the SAD If present in the incoming RADIUS Access-Accept message, the SAD
shall send this attribute back without modifying it in the subsequent shall send this attribute back without modifying it in the subsequent
RADIUS Access-Request message, except for the first one. If multiple RADIUS Access-Request message, except for the first one. If multiple
values are present, the SAD shall not change their order. values are present, the SAD shall not change their order.
4.3.12. Service-ID AVP 4.3.12. Service-ID AVP
The type of the Service-ID AVP is TBD and its length is undefined. The value of the type and length fields of the Service-ID AVP are
This AVP encodes an opaque string that uniquely describes the service TBD. The value field of this AVP is encoded as a string. This value
is handled as an opaque string that uniquely describes the service
instance to which prepaid metering should be applied. A Service-Id instance to which prepaid metering should be applied. A Service-Id
could be an IP 5-tuple (source address, source port, destination could be an IP 5-tuple (source address, source port, destination
address, destination port, protocol). If a Service-ID AVP is present address, destination port, protocol). If a Service-ID AVP is present
in the PPAQ, the entire PPAQ refers to that service. If a PPAQ does in the PPAQ, the entire PPAQ refers to that service. If a PPAQ does
not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to
the Access Service. the Access Service.
4.3.13. Rating-Group-ID AVP 4.3.13. Rating-Group-ID AVP
The type of the Rating-Group-ID is TBD and its length is 6 octets. The value of the type field of the Rating-Group-ID is TBD. The
length of this AVP is 6 octets. This AVP indicates that this PPAQ is
This AVP indicates that this PPAQ is associated with resources associated with resources allocated to a Rating Group with the
allocated to a Rating Group with the corresponding ID. This AVP is corresponding ID. This AVP is encoded as a string. A PPAQ MUST NOT
encoded as a 32 bit unsigned value, in network byte order. A PPAQ contain more than one Rating-Group-ID.
MUST NOT contain more than one Rating-Group-ID.
4.3.14. Termination-Action AVP 4.3.14. Termination-Action AVP
The type of the Termination-Action AVP is TBD and its length is 3 The value of the type field of the Termination-Action AVP is TBD.
octets. This AVP contains an enumeration of the action to take when The length of this AVP is 3 octets. This AVP contains an enumeration
the PPS does not grant additional quota. Valid actions are as of the action to take when the PPS does not grant additional quota.
follows. (Note that the value 0 is reserved.) Valid actions are as follows. (Note that the value 0 is reserved.)
1. Terminate 1. Terminate
2. Request More Quota 2. Request More Quota
3. Redirect/Filter 3. Redirect/Filter
4.3.15. Pool-ID AVP 4.3.15. Pool-ID AVP
The type of the Pool-ID) AVP is TBD and its length is 6 octets. This The value of the type field of the Pool-ID AVP is TBD. The length of
AVP identifies the resource pool that the quota included in this PPAQ this AVP is 6 octets. This AVP identifies the resource pool that the
is associated with. It is encoded as a 32 bit unsigned value, in quota included in this PPAQ is associated with. It is encoded as a
network byte order. string.
4.3.16. Pool-Multiplier AVP 4.3.16. Pool-Multiplier AVP
The type of the Pool-Multiplier AVP is TBD and its length is 12 or 18 The value of the type field of the Pool-Multiplier AVP is TBD. The
octets. The pool-multiplier determines the weight that resources are length of this AVP is 12 or 18 octets. The pool-multiplier
inserted into the pool that is identified by the accompanying Pool-ID determines the weight that resources are inserted into the pool that
AVP, and the rate at which resources are taken out of the pool by the is identified by the accompanying Pool-ID AVP, and the rate at which
relevant Service or Rating-Group. The attribute consists of a Value- resources are taken out of the pool by the relevant Service or
Digits AVP and optionally an Exponent AVP (as indicated by the length Rating-Group. The attribute consists of a Value-Digits AVP and
field). optionally an Exponent AVP (as indicated by the length field).
4.3.17. Requested-Action AVP 4.3.17. Requested-Action AVP
The type of the Requested-Action AVP is TBD and its length is 3 The value of the type field of the Requested-Action AVP is TBD. The
octets. This AVP can only be present in messages sent from the PPC length of this AVP is 3 octets. This AVP can only be present in
to the PPS. It indicates that the user or the PPC desires the PPS to messages sent from the PPC to the PPS. It indicates that the user or
perform the indicated action and to return the result. The PPAQ in the PPC desires the PPS to perform the indicated action and to return
which a Requested-Action AVP occurs MUST NOT contain a QID, and MUST the result. The PPAQ in which a Requested-Action AVP occurs MUST NOT
contain a Service-Identifier that, possibly in combination with other contain a QID, and MUST contain a Service-Identifier that, possibly
AVPS, can be used by the PPS to uniquely identify the service for in combination with other AVPS, can be used by the PPS to uniquely
which the indicated action is requested. The following actions may identify the service for which the indicated action is requested.
be requested.
The following actions may be requested.
1. Balance Check 1. Balance Check
2. Price Enquiry 2. Price Enquiry
4.3.18. Check-Balance-Result AVP 4.3.18. Check-Balance-Result AVP
The type of the Check-Balance-Result AVP is TBD and its length is 3 The value of the type field of the Check-Balance-Result AVP is TBD.
octets. This AVP can only be present in messages sent from the PPS The length of this AVP is 3 octets. This AVP can only be present in
to the PPC. It indicates the balance check decision of the PPS about messages sent from the PPS to the PPC. It indicates the balance
a previously received Balance Check Request (as indicated in a check decision of the PPS about a previously received Balance Check
Requested-Action AVP). Possible values are 0 for "success" and 1 for Request (as indicated in a Requested-Action AVP). Possible values
"failure" and mean that sufficient funds are available (resp. are not are 0 for "success" and any other value for "failure" and mean that
available) in the user's prepaid account. The PPAQ in which a Check- sufficient funds are available (resp. are not available) in the
Balance-Result occurs MUST NOT include a QID, because no quota is user's prepaid account. The PPAQ in which a Check-Balance-Result
reserved by the PPS. occurs MUST NOT include a QID, because no quota is reserved by the
PPS.
4.3.19. Cost-Information AVP 4.3.19. Cost-Information AVP
The type of the Cost-Information AVP is TBD and its length is The value of the type field of the Cost-Information AVP is TBD. The
variable. This AVP is used in order to return the cost information length of this AVP is variable. This AVP is used in order to return
of a service, which the PPC can transfer transparently to the end the cost information of a service, which the PPC can transfer
user. This AVP is sent from the PPS to the PPC as a response to a transparently to the end user. This AVP is sent from the PPS to the
"Price Enquiry", as indicated by the Requested-Action AVP. This AVP PPC as a response to a "Price Enquiry", as indicated by the
consists of four further AVPs, as follows. Requested-Action AVP. This AVP consists of four further AVPs, as
follows.
1. Value-Digits ASP: this encodes the most significant digits of the 1. Value-Digits ASP: this encodes the most significant digits of the
monetery value that represents the cost in question. monetery value that represents the cost in question.
2. Exponent AVP: this encodes the exponent that applies to the 2. Exponent AVP: this encodes the exponent that applies to the
Value-Digits AVP. Value-Digits AVP.
3. Currency-Code AVP: the type of this AVP is TBD, and its length is 3. Currency-Code AVP: the value of the type field of this AVP is
4 octets. It encodes the currency code, as defined in the ISO TBD. The length of this AVP is 4 octets. It encodes the
4217 standard. currency code, as defined in the ISO 4217 standard.
4. Cost-Unit AVP: the type of this AVP is TBD and its length is 4. Cost-Unit AVP: the value of the type field of this AVP is TBD.
variable. It carries a UTF8String encoded human readable string The length of this AVP is variable. It carries a UTF8String
that can be displayed to the end user. It specifies the encoded human readable string that can be displayed to the end
applicable unit to the Cost-Information when the service cost is user. It specifies the applicable unit to the Cost-Information
a cost per unit (e.g., cost of the service is $1 per minute). when the service cost is a cost per unit (e.g., cost of the
The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, service is $1 per minute). The Cost-Unit can be minutes, hours,
etc. days, kilobytes, megabytes, etc.
Example: the cost of 7.75 Malawi kwacha per hour would be encoded as Example: the cost of 7.75 Malawi kwacha per hour would be encoded as
follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and
Cost-Unit = "hour". Cost-Unit = "hour".
The PPAQ in which a Cost-Information occurs MUST NOT include a QID, The PPAQ in which a Cost-Information occurs MUST NOT include a QID,
because no quota is actually reserved by the PPS. because no quota is actually reserved by the PPS.
NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear
in the PPAQ attribute. A PPAQ MUST NOT contain more than one in the PPAQ attribute. A PPAQ MUST NOT contain more than one
skipping to change at page 42, line 28 skipping to change at page 41, line 32
Support for tariff switching is optional for both the PPC and the Support for tariff switching is optional for both the PPC and the
PPS. PPCs use the flag "Tariff Switching supported" of the PPS. PPCs use the flag "Tariff Switching supported" of the
AvailableInClient subtype of the PPAC attribute in order to indicate AvailableInClient subtype of the PPAC attribute in order to indicate
support for tariff switching. PPSs employ the PTS attribute in order support for tariff switching. PPSs employ the PTS attribute in order
to announce their support for tariff switching. Details of this will to announce their support for tariff switching. Details of this will
be specified after the format of the PTS attribute has been defined. be specified after the format of the PTS attribute has been defined.
If a RADIUS message contains a PTS attribute, it MUST also contain at If a RADIUS message contains a PTS attribute, it MUST also contain at
least one PPAQ attribute. If a RADIUS Access-Request message least one PPAQ attribute. If a RADIUS Access-Request message
contains a PTS attribute or a "Tariff Switching supported" flag, it contains a PTS attribute or a "Tariff Switching supported" flag, it
MUST also contain an Event-Timestamp RADIUS attribute (see [3]). MUST also contain an Event-Timestamp RADIUS attribute (see
[RFC2869]).
The type of the PTS attribute is TBD and its lengh is variable. It The value of the type field of the PTS AVP is TBD. The length of
contains one or more subtypes, as follows. Every PTS AVP MUST this AVP is variable. It contains one or more subtypes, as follows.
include a QuotaIdentifier AVP as specified in Section 4.3.1. In an Every PTS AVP MUST include a QuotaIdentifier AVP as specified in
online RADIUS Access-Request message sent from the PPC to the PPS, Section 4.3.1. In an online RADIUS Access-Request message sent from
the QuotaIdentifier AVP must contain a quota identifier that was the PPC to the PPS, the QuotaIdentifier AVP must contain a quota
previously received from the PPS and MUST be the same as a quota identifier that was previously received from the PPS and MUST be the
identifier of one of the PPAQ attributes included the same RADIUS same as a quota identifier of one of the PPAQ attributes included the
message. same RADIUS message.
A PPAQ attribute that is transported along with a PTS attribute and A PPAQ attribute that is transported along with a PTS attribute and
has the same quota identifier value as the PTS attribute in its own has the same quota identifier value as the PTS attribute in its own
QID subfield shall be referred to as the "accompanying PPAQ QID subfield is referred to as the "accompanying PPAQ attribute". If
attribute". If a PPS receives an Access-Request message from a PPC, a PPS receives an Access-Request message from a PPC, it associates a
it associates a unique quota identifier to this request. Thus, a unique quota identifier to this request. Thus, a quota identifier
quota identifier also identifies a particular service. also identifies a particular service.
The PTS AVP contains a number of other subtype AVPs which are The PTS AVP contains a number of other subtype AVPs which are
specified in the following subsections. specified in the following subsections.
4.4.1. VolumeUsedAfterTariffSwitch AVP 4.4.1. VolumeUsedAfterTariffSwitch AVP
The type of the VolumeUsedAfterTariffSwitch attribute is TBD and its The value of the type field of the VolumeUsedAfterTariffSwitch AVP is
length is 12 or 18 octets. The VolumeUsedAfterTariffSwitch subtype TBD. The length of this AVP is 12 or 18 octets. The
SHALL be used in online RADIUS Access-Request messages (PPC to PPS VolumeUsedAfterTariffSwitch subtype SHALL be used in online RADIUS
direction). It indicates the volume (in octets) used during a Access-Request messages (PPC to PPS direction). It indicates the
session after the last tariff switch for the service specified via volume (in octets) used during a session after the last tariff switch
the QID subfield and the accompanying PPAQ attribute. The attribute for the service specified via the QID subfield and the accompanying
consists of a Value-Digits AVP and optionally an Exponent AVP (as PPAQ attribute. The attribute consists of a Value-Digits AVP and
indicated in the length field). optionally an Exponent AVP (as indicated in the length field).
4.4.2. TariffSwitchInterval AVP 4.4.2. TariffSwitchInterval AVP
The type of the TariffSwitchInterval is TBD and its length 6 octets. The type of the TariffSwitchInterval is TBD and its length 6 octets.
This AVP MUST be present in each PTS attribute that is part of a This AVP MUST be present in each PTS attribute that is part of a
RADIUS Access-Accept message (PPS to PPC direction). It indicates RADIUS Access-Accept message (PPS to PPC direction). It indicates
the interval (in seconds) between the value of Event-Timestamp RADIUS the interval (in seconds) between the value of Event-Timestamp RADIUS
attribute (see [3]) of the corresponding RADIUS Access-Request attribute (see [RFC2869]) of the corresponding RADIUS Access-Request
message and the next tariff switch condition. message and the next tariff switch condition.
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP
The type of the TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is The value of the type field of the
TBD and its length is 6 octets. The PPS MUST include this AVP if TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is TBD. The length
there is another tariff switch period after the period that ends as of this AVP is 6 octets. The PPS MUST include this AVP if there is
indicated by the TSI attribute. The TITSU attribute encodes the another tariff switch period after the period that ends as indicated
number seconds of the tariff period that begins immediately after the by the TSI attribute. The value of the TITSU AVP in encoded as an
period that ends as indicated by the TSI attribute. If the TITSU integer, and contains the number of seconds of the tariff period that
attribute is zero or omitted, the PPC assumes that the tariff period begins immediately after the period that ends as indicated by the TSI
which ends as indicated by the TSI attribute lasts until further attribute. If the TITSU attribute is not present, the PPC assumes
notice. If TITSU is specified, the PPC MUST send a quota update that the tariff period which ends as indicated by the TSI attribute
before the point in time specified by the TITSU attribute (see lasts until further notice. If TITSU is specified, the PPC MUST send
Figure 9). a quota update before the point in time specified by the TITSU
attribute (see Figure 9).
If a RADIUS message contains a PTS attribute, it MUST also contain at If a RADIUS message contains a PTS attribute, it MUST also contain at
least one PPAQ attribute. The PTS is associated with the PPAQ by the least one PPAQ attribute. The PTS is associated with the PPAQ by the
QID. If multiple services are supported and if the PPAQ is QID. If multiple services are supported and if the PPAQ is
associated with a service as indicated by the Service-ID AVP, then associated with a service as indicated by the Service-ID AVP, then
the PTS refers to the tariff switch for that service. If the PPAQ the PTS refers to the tariff switch for that service. If the PPAQ
does not have a Service-ID, then the PTS refers to tariff switch for does not have a Service-ID, then the PTS refers to tariff switch for
the Access-Service. the Access-Service.
If a PPC supports tariff switching then it MUST set the 0x00000040 If a PPC supports tariff switching then it MUST set the 0x00000040
skipping to change at page 44, 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. In this Translation occurs on an attribute-by-attribute basis. Certain
document, the translation of only RPP and DCC attributes is attributes are translated without consideration of local per-session
considered. In reality, this translation has to be performed in state. Other attributes, namely those that are bound to a particular
coordination and orchestration with the translation of the attributes session, require such consideration. The translation agent has to
of the base RADIUS and Diameter. Certain attributes are translated identify the session (and possibly subsession) an incoming message
without consideration of local per-session state. Other attributes, belongs to in order to consult the appropriate local per-session
namely those that are bound to a particular session, require such state.
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 may result semantics not being present in RPP, and vice versa. This results in
in the messages, in which these attributes occur, not being delivered the messages, in which these attributes occur, not being delivered to
to their intended destination. Whenever this would lead to a failure their intended destination. In such cases it is desirable to inform
at the destination, it is desirable to inform the originator about the originator about the failure and terminate the session.
this failure and terminate the session in both directions.
In each of the two scenarios (namely RPP client / DCC AAA In each scenario (i.e. RPP client / DCC AAA infrastructure and DCC
infrastructure and DCC client / RPP AAA infrastructure), the client / RPP AAA infrastructure), the translator operates in two
translator operates in two directions, namely RPP to DCC and vice directions, namely RPP to DCC and vice versa. In the following
versa. In the following sections, the notation c->s means that the sections, the notation c->s means that the attribute in question may
attribute in question may occur only in the direction from the client occur only in the direction from the client to the server. The
to the server. The notation s->c denotes the converse and the notation s->c denotes the converse and the notation c<->s denotes
notation c<->s denotes that the attribute may occur in messages that that the attribute may occur in messages that are directed in either
are directed in either direction. 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 45, line 50 skipping to change at page 45, line 46
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 Since in this scenario, the PPC is typically the initiator a session,
session, the focus is on the RPP AVPs. 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 52, line 43 skipping to change at page 53, line 5
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 The extended RADIUS protocol described in this document is subject to
description of the security threats and the countermeasures.] a number of potential attacks, in a manner similar to the RADIUS
protocol without these extensions. It is recommended that IPsec be
employed to protect against certain of the attacks.
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),
QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT), QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT),
DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR), DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR),
PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID), PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID),
TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost- TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost-
Information (COST), Session-Termination-Capability (STC), Information (COST), Session-Termination-Capability (STC),
PrepaidTariffSwitch (PTS) and TariffSwitchInterval (TSI). PrepaidTariffSwitch (PTS), TariffSwitchInterval (TSI) and others.
8. Contributors 8. Acknowledgements
The authors would like to thank Christian Guenther and Yong Li for The authors would like to thank Christian Guenther for his valuable
their contribution to earlier draft versions. insight and feedback and his active and ongoing contributions that he
provided throughout the development of this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate [1] Bradner, S., "RFC 2026: The Internet Standards Process --
Revision 3", October 1996.
[2] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865: [3] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865:
Remote Authentication Dial In User Server (RADIUS)", June 2000. Remote Authentication Dial In User Server (RADIUS)", June 2000.
[3] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS [4] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000.
Extensions", June 2000.
[4] Bradner, S., "RFC 2026: The Internet Standards Process --
Revision 3", October 1996.
[5] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. [5] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS
Extensions", June 2000.
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and
I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol
Support", June 2000. Support", June 2000.
[7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba, [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba,
"RFC 3576: Dynamic Authorization Extensions to Remote "RFC 3576: Dynamic Authorization Extensions to Remote
Authentication Dial-In User Service (RADIUS)", February 2003. Authentication Dial-In User Service (RADIUS)", February 2003.
[8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
skipping to change at page 64, line 7 skipping to change at page 59, 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 no PPAQ AVP with Update Reason="initial request" is included that, since this is not an "Authorize-Only" message, no PPAQ AVP with
(see Section 3.7.1). The home AAA server then authenticates the user Update Reason="initial request" is included (see Section 3.7.1). The
and authorizes the access service, as is usual in RADIUS (3). Note home AAA server then authenticates the user and authorizes the access
that the PPAC AVP is appended by the PPC in at least the last message service, as is usual in RADIUS (3). Note that the PPAC AVP is
that is sent to the home AAA server during this possibly multiple- appended by the PPC in at least the last message that is sent to the
round exchange. home AAA server during this possibly 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, 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 64, line 37 skipping to change at page 59, 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 Access Request that contains the usual RADIUS PPC generates an Authorize-Only Access Request that contains the
attributes and a PPAQ AVP that reports the amount of consumed quota, usual RADIUS attributes and a PPAQ AVPs that reports the amount of
and the request for replenishment, i.e. the Update-Reason= THRESHOLD consumed quota, and the request for replenishment, i.e. the Update-
REACHED (8). Note that the QID in this message is the same as the Reason= THRESHOLD REACHED (8). Note that the QID in this message is
one previously received from the user's home AAA server. This the same as the one previously received from the user's home AAA
message is forwarded to the PPS (9). server. This 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 65, line 17 skipping to change at page 60, 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 Access Request message with a PPAQ AVP for the access constructs an Authorize-Only Access Request message with a PPAQ AVPs
service. In this example, 7 MB were consumed by the access service for the access service. In this example, 7 MB were consumed by the
in total. The PPC reports 7 MB its final message (13). This is access service in total. The PPC reports 7 MB its final message
forwarded to the PPS (14) which correlates the report, using the QID, (13). This is forwarded to the PPS (14) which correlates the report,
to the previous session state. It determines, from the previous using the QID, to the previous session state. It determines, from
records, that the access service had consumed another 4.5 MB before the previous records, that the access service had consumed another
(as indicated in message (9)). This means that, of the 7 MB, only 4.5 MB before (as indicated in message (9)). This means that, of the
3.5 MB have not yet been subtracted from the user's account. Thus, 7 MB, only 3.5 MB have not yet been subtracted from the user's
the PPS subtracts another 1.4 euros from the user's account and, account. Thus, the PPS subtracts another 1.4 euros from the user's
since the session is to be terminated (REASON=ACCESS SERVICE account and, since the session is to be terminated (REASON=ACCESS
TERMINATED), releases any reserved monetary amount. SERVICE 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 69, line 21 skipping to change at page 64, 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 Access user's prepaid account. To this end the PPC constructs an Authorize-
Request message with a PPAQ AVP for the access service. In this Only Access Request message with a PPAQ AVPs for the access service.
example, 17 MB were consumed by the access service in total. The PPC In this example, 17 MB were consumed by the access service in total.
reports 17 MB its final message (13). This is forwarded to the PPS The PPC reports 17 MB its final message (13). This is forwarded to
(14) which correlates the report, using the QID, to the previous the PPS (14) which correlates the report, using the QID, to the
session state. It determines, from the previous records, that the previous session state. It determines, from the previous records,
access service had consumed 14 MB before (as indicated in message that the access service had consumed 14 MB before (as indicated in
(9)). This means that, of the 17 MB, only the monetary equivalent message (9)). This means that, of the 17 MB, only the monetary
for 3 MB have not yet been subtracted from the user's account. The equivalent for 3 MB have not yet been subtracted from the user's
PPS calculates how much should be deducted from the user's account as account. The PPS calculates how much should be deducted from the
follows. Since the VUATS AVP indicates that 2.5MB were consumed user's account as follows. Since the VUATS AVP indicates that 2.5MB
after the tariff switch, only 0.5 MB were consumed before that. were consumed after the tariff switch, only 0.5 MB were consumed
Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. before that. Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8
That is, the PPS subtracts 3.6 euros from the user's prepaid account. = 3.6 euros. That is, the PPS subtracts 3.6 euros from the user's
Since the session has by now be terminated by the PPC (REASON=ACCESS prepaid account. Since the session has by now be terminated by the
SERVICE TERMINATED), the PPS now releases any reserved monetary PPC (REASON=ACCESS SERVICE TERMINATED), the PPS now releases any
amount, in this example 12.8 - 3.6 = 9.2 euros. reserved monetary 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 72, line 27 skipping to change at page 67, 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 no PPAQ AVP with Update pools are supported. Note that, since this is not an "Authorize-
Reason="initial request" is included (see Section 3.7.1). The home Only" message, no PPAQ AVP with Update Reason="initial request" is
AAA server then authenticates the user and authorizes the access included (see Section 3.7.1). The home AAA server then authenticates
service, as is usual in RADIUS (3). Note that the PPAC AVP is the user and authorizes the access service, as is usual in RADIUS
appended by the PPC in at least the last message that is sent to the (3). Note that the PPAC AVP is appended by the PPC in at least the
home AAA server during this possibly multiple-round exchange. last message that is sent to the home AAA server during this possibly
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 72, line 49 skipping to change at page 68, line 4
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 Access Request that namely service A (8). The PPC generates an Authorize-Only Access
contains the usual RADIUS attributes and the Service-ID identifying Request that contains the usual RADIUS attributes and the Service-ID
service A (9). The PPC has determined that service A is rated in an identifying service A (9). The PPC has determined that service A is
identical way as at least one more service. Thus, service A has been rated in an identical way as at least one more service. Thus,
configured to belong to a rating group, in this example the group service A has been configured to belong to a rating group, in this
with Rating-Group-ID=1. This identifier is included is message (9), example the group with Rating-Group-ID=1. This identifier is
which is then forwarded to the PPS (10). included is message (9), 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 74, line 23 skipping to change at page 69, line 24
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 Access Request message that reports the usage for the constructs an Authorize-Only Access Request message that reports the
"access service" and "service A". This message contains two PPAQ usage for the "access service" and "service A". This message
AVPS, is sent to the home AAA server (14) and forwarded to the PPS contains two PPAQ AVPS, is sent to the home AAA server (14) and
(15). Note that is the message it appears that "service A" has forwarded to the PPS (15). Note that is the message it appears that
consumed more than it was allocated (i.e. 55 minutes although only 50 "service A" has consumed more than it was allocated (i.e. 55 minutes
minutes were initially allocated to it). This is not a a problem although only 50 minutes were initially allocated to it). This is
since the PPS knows that "service A" was drawing from the same pool not a a problem since the PPS knows that "service A" was drawing from
as the "access service" and that the "access service" did only the same pool as the "access service" and that the "access service"
consume 4 out of the 5 MB it was allocated. did only 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 75, line 25 skipping to change at page 70, line 26
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 Access Request message with two PPAQ AVPs; end the PPC constructs an Authorize-Only Access Request message with
one for the access service and one for "service A". Suppose that, in two PPAQ AVPs; one for the access service and one for "service A".
total, 6.5MB were consumed by the access service, 70 minutes were Suppose that, in total, 6.5MB were consumed by the access service, 70
consumed by "service A" and 20 minutes by "service B". The PPC minutes were consumed by "service A" and 20 minutes by "service B".
reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds) in its The PPC reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds)
final message (19). This is forwarded to the PPS which determines, in its final message (19). This is forwarded to the PPS which
from the previous records, that the access service consumed another determines, from the previous records, that the access service
2.5MB (since 4MB out of the 6.5MB were already reported in message consumed another 2.5MB (since 4MB out of the 6.5MB were already
(15), and that "service A" consumed further 600 seconds. This reported in message (15), and that "service A" consumed further 600
corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros. Thus, the PPS seconds. This corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros.
only subtracts 2.5 out of the 6 previously reserved euros from the Thus, the PPS only subtracts 2.5 out of the 6 previously reserved
user's prepaid account and responds with an Access Response as euros from the user's prepaid account and responds with an Access
required by the RADIUS base specification. Response as 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
 End of changes. 173 change blocks. 
1114 lines changed or deleted 816 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/