< draft-lior-radius-prepaid-extensions-08.txt   draft-lior-radius-prepaid-extensions-09.txt >
Network Working Group A. Lior RADEXT A. Lior
INTERNET-DRAFT Bridgewater Systems Internet-Draft Bridgewater Systems
Category: Informational P. Yegani Expires: April 26, 2006 P. Yegani
draft-lior-radius-prepaid-extensions-08.txt Cisco Cisco
Expires: 18 January, 2006 K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
H. Tschofenig H. Tschofenig
C. Guenther A. Pashalidis
Siemens Siemens
July 17, 2005 October 23, 2005
PrePaid Extensions to Remote Authentication Dial-In User Service Prepaid extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
draft-lior-radius-prepaid-extensions-09.txt
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
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 December 29, 2005. This Internet-Draft will expire on April 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This draft presents an extension to the Remote Authentication Dial- This draft presents an extension to the Remote Authentication Dial-
In User Service (RADIUS) protocol to support charging for prepaid In User Service (RADIUS) protocol to support charging for prepaid
services. The charging models supported are namely: volume-based services. The charging models supported are namely: volume-based
charging, duration-based charging and one-time-based charging. charging, duration-based charging and one-time-based charging.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Terminology................................................5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Requirements language......................................5 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview.......................................................6 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7
2.1 Prepaid Charging Models....................................6 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Architectural Model........................................6 1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 13
2.3 Motivation................................................11 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15
3. Operations....................................................13 2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 15
3.1 General Requirements......................................13 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Broker AAA Requirements..............................13 2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 17
3.2 Authentication and Authorization for Prepaid Enabled SADs.14 2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 17
3.3 Session Start Operation...................................16 2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18
3.4 Mid-Session Operation.....................................16 2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 20
3.5 Dynamic Operations........................................18 2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20
3.5.1 Unsolicited Session Termination Operation............19 2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 20
3.5.2 Unsolicited Change of Authorization Operation........19 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Termination Operation.....................................20 3.1. Authentication and Authorization Operation . . . . . . . . 22
3.7 Mobile IP Operations......................................20 3.2. Session Start Operation . . . . . . . . . . . . . . . . . 24
3.8 Operation considerations for Multiple prepaid services....21 3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24
3.8.1 Initial Quota Request................................22 3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26
3.8.2 Quota Update.........................................22 3.4.1. Unsolicited Session Termination Operation . . . . . . 26
3.8.3 Termination..........................................23 3.4.2. Unsolicited Change of Authorization Operation . . . . 26
3.8.4 Dynamic Operations...................................23 3.5. Termination Operation . . . . . . . . . . . . . . . . . . 27
3.8.5 Support for Resource Pools...........................23 3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27
3.8.6 One-Time-Charging....................................24 3.7. Operation Considerations for Multiple Services . . . . . . 28
3.8.7 Error Handling.......................................24 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 28
3.9 Accounting Considerations.................................25 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29
3.10 SAD Operation............................................25 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 29
3.11 Interoperability with Diameter Credit Control Application25 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30
4. Attributes....................................................25 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 30
4.1 PPAC Attribute............................................26 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 30
4.2 Session Termination Capability............................27 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31
4.3 PPAQ Attribute............................................27 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 31
4.4 Prepaid Tariff Switching (PTS)............................34 3.7.9. Interoperability with Diameter Credit Control
4.5 Table of Attributes.......................................36 Application . . . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations.......................................37 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1 Authentication and Authorization..........................37 4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Replenishing Procedure....................................37 4.2. Session Termination Attribute . . . . . . . . . . . . . . 33
6. IANA Considerations...........................................37 4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 34
7. Normative References..........................................38 4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 34
8. Informative References........................................39 4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 35
9. Call Flows....................................................39 4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 35
9.1 Simple Concurrent Services................................40 4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 35
9.2 One-time Charging.........................................43 4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 35
Contributor......................................................43 4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 36
Acknowledgments..................................................43 4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 36
Author's Addresses...............................................43 4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 36
Intellectual Property Statement..................................44 4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 36
Disclaimer of Validity...........................................44 4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 36
Copyright Statement..............................................45 4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 37
Expiration Date..................................................45 4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 37
10. Appendix A û use cases.......................................45 4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 37
10.1 Simple prepaid use case..................................45 4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 38
10.2 Support for Multi-Services...............................47 4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 38
10.3 Resource Pools...........................................48 4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 38
10.4 Support for Complex Rating Functions.....................49 4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 38
10.5 One-Time-based Charging..................................50 4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 39
10.6 Support for Tariff Switching.............................51 4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 39
10.7 Support for Roaming......................................53 4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 40
10.8 Termination of a prepaid session.........................53 4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 40
10.9 Querying and Rebalancing Prepaid Resources...............54 4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 41
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 41
5. Translation between RADIUS prepaid and Diameter Credit
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1. Session Identification . . . . . . . . . . . . . . . . . . 43
5.2. Translation between RADIUS prepaid client and Diameter
Credit Control AAA infrastructure . . . . . . . . . . . . 43
5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 43
5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 44
5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 44
5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 44
5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 45
5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 45
5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 46
5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 46
5.2.9. Volume/Duration/Resource Threshold Attributes
(s->c) . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 46
5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 48
5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 48
5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 48
5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 48
5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 49
5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 49
5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 49
5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 49
5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 50
5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 50
6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1. Normative References . . . . . . . . . . . . . . . . . . . 54
9.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 55
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 55
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 58
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . . . . . 70
1. 1. Introduction
Introduction
This draft describes extensions for the RADIUS protocol. These This draft describes extentions for the RADIUS protocol. These
extensions are meant to enable service providers to charge and bill extensions are meant to enable service providers to charge and bill
their customers using prepaid accounts. their customers using prepaid accounts.
A prepaid service subscriber is a user who has purchased a contract A prepaid service subscriber is a user who has purchased a contract
according to which he will receive a particular data service for according to which he will receive a particular data service for
either a period of time or a quantity of data. In the typical either a period of time or a quantity of data. In the typical
prepaid scenario, the service provider verifies that the subscriber prepaid scenario, the service provider verifies that the subscriber
has sufficient funds in his account before delivering the service. has sufficient funds in his account before delivering the service.
Only if sufficient funds are available is the service provided to Only if suffiecient funds are available is the service provided to
the user. the user.
Note that the means by which the subscriber obtains funds is outside
the scope of this document. Also note that, in some scenarios, the
subscriber's account may be used to fund multiple services, some of
which may use the extensions defined in 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, how this could be done depends on the external
mechanisms and is, as such, outside the scope of this
document.
The business driver behind the protocol extensions defined in this The business driver behind the protocol extensions defined in this
document is to increase participation (i.e. a service provider's document is to increase participation (i.e. a service provider's
subscriber base) and thus to increase revenues. In particular, the subscriber base) and thus to increase revenues. In particular, the
extensions were designed with the following goals in mind. extensions were designed with the following goals in mind.
- Make use of existing infrastructure as much as possible, and o Make use of existing infrastructure as much as possible (including
thereby limit the amount of necessary capital expenditures, enabling the interworking of RADIUS-based and Diameter-based
- provide the ability to rate service requests in real-time,</t> infrastructures), and thereby limit the amount of necessary
- provide the ability to charge the user's account - charge prior to capital expenditures,
service provision,
- protect against revenue loss, i.e. prevent an end user from o provide the ability to rate service requests in real-time,
obtaining service when the available funds are not sufficient,
- protect against fraud, and o provide the ability to charge the user's account prior to service
- be as widely deployable over dialup, wireless and WLAN networks. provision,
o protect against revenue loss, i.e. to prevent an end user from
obtaining service when the available funds are not sufficient,
o protect against fraud, and
o be deployable over dialup, wired and wireless networks.
The architecture between the entities that execute the RADIUS The architecture between the entities that execute the RADIUS
protocols with the extensions defined in this document assumes that protocols, with the extensions defined in this document, assumes that
rating of chargeable events does not occur in the element the rating of chargeable events does not occur in the element that
that provides the service. Instead, the rating may be 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ö. Alternatively, the actual rating may occur in an "prepaid server". Alternatively, the actual rating may occur in an
entity behind this prepaid server. Furthermore, business logic may entity behind this prepaid server. Furthermore, business logic may
dictate a time-dependent tariff model, for example that the price dictate a time-dependent tariff model, for example that the price for
for a service may switch at 8pm from a high to a low tariff. The a service may switch at 8pm from a high to a low tariff. The
extensions defined in this document support such scenarios. extensions defined in this document support such scenarios.
Furthermore, this documents assumes an architecture where a `quota Furthermore, this documents assumes an architecture where a "quota
server' is available which, through co-ordination with the rating server" is available which, through co-ordination with the rating
entity and a centralized account balance manager, is able to entity and a centralized account balance manager, is able to provide
provide a quota indication for a particular user when requested. a quota indication for a particular user when requested. This quota
This quota server may or may not coexist in the prepaid server. server may or may not coexist in the prepaid server.
1.1 1.1. Terminology
Terminology
Network Access Server As in RADIUS. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
(NAS) "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Prepaid Client(PPC) The entity which triggers the RADIUS message document are to be interpreted as described in [1].
exchange including prepaid extensions
defined in this document. The PPC typically
resides in the NAS.
Prepaid Server(PPS) The entity that interacts with the Prepaid
Client using the RADIUS prepaid extensions
defined in this document.
Home network The entity which maintains the userÆs
profile and prepaid account.
WLAN Wireless Local Area Network
Service Event
Access Service The service that is provided to the user
when the user is authenticated and
authorized.
Furthermore, the following terms are used in this document. Mobile Furthermore, this document uses the following terms:
IP and AAA terminology: Home agent (HA), Home network, Home AAA
(HAAA), Broker AAA (BAAA), Visited AAA (VAAA) and Foreign Agent (FA)
1.2 Network Access Server (NAS):
Requirements language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2. As defined in RADIUS [2].
Overview
This section provides an overview of the prepaid charging models, Prepaid client (PPC):
and their associated architectures, that are supported by the
extensions proposed in this document.
2.1 The entity which triggers the RADIUS message exchange, including
Prepaid Charging Models 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.
Home Network:
The network which contains the user profile and the user's prepaid
account.
1.2. Overview
This section provides an overview of the prepaid charging models and
architectures, which are supported by the extensions described in
this draft.
A number of models of how to charge customers for data services in a A number of models of how to charge customers for data services in a
prepaid manner are supported, as follows. prepaid manner are supported, as follows.
. Volume-based charging (VBC): (e.g. 2 Cents/KiloByte) o Volume-based charging: (e.g. 2 Cents/KiloByte).
. Duration-based charging (DBC): (e.g. 3 Cents/minute)
. Subscription-based charging (SBC): (e.g. Dollars/month)
. Event-based charging (EBC): (e.g. 7 Cents/URL or email)
Whether the user account is a dedicated prepaid account or a general o Duration-based charging: (e.g. 3 Cents/minute).
account (such as a current bank account) is outside the scope of
this document.
2.2 o Subscription-based charging: (e.g. Dollars/month).
Architectural Model
The architectural model assumed in this document encompasses the o Event-based charging: (e.g. 7 Cents/URL or email) .
following entities.
(1) Service Access Device (SAD): This entity provides a data This draft assumes that the user maintains a prepaid account with his
service to the users, and typically coincides with the NAS. The home network. However, whether this account is a dedicated prepaid
SAD executes the RADIUS client which, for the purposes of this account or not (such as a current bank account) is outside the scope
document, is termed the PPC. When prepaid service is used the of this document. Similarly, the means by which the subscriber
SAD collects service event information and reports it while or obtains funds is also outside the scope of this document. In some
after services are provided to the user. This event information scenarios, the subscriber's account may be used to fund multiple
is sent to the PPS using the extensions defined in this services, some of which may use the extensions defined in this
document. documents, and some may use other mechanisms. While the interworking
(2) The PPS: The RADUIS server. If real-time credit control is of the mechanisms described in this document with other mechanisms
required, the PPC (SAD) contacts the PPS with service event should be possible and straightforward, the specification of how this
information included before the service is provided. The PPS could be done depends on the external mechanisms and is, as such,
performs a credit check and allocates a portion of available outside the scope of this document.
credit to the service event.
(3) The rating entity: This entity converts the credit that is 1.2.1. Architectural Model
allocated by the PPS into a time or volume amount, called the
ôquotaö. This quota is then returned to the requesting PPC The protocol extensions described in this draft assumes that the
(SAD) (via the PPS). The rating entity may also determine that following entities are present in the network architecture.
during service provision a tariff switch will occur. In this
case the rating entity will include details of when exactly o Service Access Device (SAD): This entity provides a data service
tariff switch will occur. to the users, and typically coincides with the NAS. The SAD
executes the RADIUS client which, for the purposes of this
document, is termed the "PrePaid Client" (PPC). When the prepaid
service is used the SAD collects service event information and
reports it while or after services are provided to the user. This
event information is sent to the PPS using the extensions defined
in this document.
o The PPS: The RADUIS server that supports the prepaid extensions
defined in this document. If real-time credit control is
required, the PPC (SAD) contacts the PPS with service event
information included before the service is provided. The PPS
performs a credit check and allocates a portion of available
credit to the service event.
o The rating entity: This entity converts the credit that is
allocated by the PPS into a time or volume amount, called the
"quota". This quota is then returned to the requesting PPC (SAD)
(via the PPS). The rating entity may also determine that during
service provision a tariff switch will occur. In this case the
rating entity will include details of when exactly tariff switch
will occur.
The requesting SAD (PPC) monitors the provision of the service The requesting SAD (PPC) monitors the provision of the service
according to the instructions returned by the PPS. After service according to the instructions returned by the PPS. After service
completion or on a subsequent request for service, the PPS deducts completion or on a subsequent request for service, the PPS deducts
the corresponding amount of credit from the user account. When a the corresponding amount of credit from the user account. When a
user terminates an on-going service, the PPC informs the PPS with a user terminates an on-going service, the PPC informs the PPS with a
suitable indication about the unused portion of the allocated quota. suitable indication about the unused portion of the allocated quota.
The PPS is then able to refund the user account appropriately. The PPS is then able to refund the user account appropriately.
Multiple PPSs MAY be deployed for reasons of redundancy and load Multiple PPSs may be deployed for reasons of redundancy and load
balancing. The system MAY also employ multiple rating servers. balancing. The system MAY also employ multiple rating servers.
Prepaid accounts MAY be located in a centralized database. The Prepaid accounts may be located in a centralized database. The
detailed architecture of the system and its interfaces are outside detailed architecture of the system and its interfaces are outside
the scope of this specification. the scope of this specification.
accounting accounting
+------------+ +-----------+ protocol +--------------+ +------------+ +-----------+ protocol +--------------+
| User |<----->| Service | | | | User |<---------->| Service | | |
| | | Access |<------------>| Accounting | | | IEEE 802.1x| Access |<------------>| Accounting |
| Device | | Device |<-----+ | Server | | Device | PANA | Device |<-----+ | Server |
+------------+ +-----------+ | +--------------+ +------------+ IKEv.2 +-----------+ | +--------------+
(PPC) | ... etc (PPC) |
| |
| +--------------+ | +--------------+
+------>| Prepaid | +------>| Prepaid |
prepaid | Server | prepaid | Server |
protocol +--------------+ 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 are logical
entities. The real configuration MAY combine them into a single entities. The real configuration MAY combine them into a single
host. host.
The SAD MUST have the ability to meter the usage for a prepaid data The SAD must have the ability to meter the usage for a prepaid data
session. This usage includes time or volume (e.g. number of bytes). session. This usage includes time or volume (e.g. number of bytes).
In roaming scenarios using mobile IP the PPC may run on the Home The device running the PPC may also have "Dynamic Session
Agent. Furthermore, the device running the PPC may also have Capabilities" such as the ability to terminate a data session or
ôDynamic Session Capabilitiesö such as the ability to terminate a change the filters associated with a specific data session by
data session or change the filters associated with a specific data processing "Disconnect" messages and "Change of Authorization"
session by processing ôDisconnectö messages and ôChange of messages as per RFC 3576.
Authorizationö messages as per [RFC3576].
This document assumes that the PPS is used as the AAA server. There This document assumes that the PPS is used as the AAA server. There
are three types of AAA server, as follows. (i) The AAA server in the are three types of AAA server, as follows.
home network (HAAA), which is responsible for authentication of the
subscriber. In addition, the HAAA communicates with the PPS using
the RADIUS protocol in order to authorize subscribers. (ii) The AAA
server in the visited network (VAAA) which exists only in roaming
scenarios and is responsible for forwarding the RADIUS messages to
the HAAA. The VAAA may also modify the messages. Note that, in
certain roaming deployments, the visited network may be connected to
the home network via one or more broker networks. (iii) The AAA
server in one of the aforementioned broker networks (BAAA), which is
responsible for forwarding messages and does not play an active role
in the prepaid data service delivery. A BAAA obviously exists only
in those roaming deployments where the VAAA and the HAAA are
connected via the BAAA of a broker network.
This document assumes that the PPS communicates with the HAAA for o The AAA server in the home network (HAAA), which is responsible
the purposes of authorisation. Additionally, the PPS interfaces to for authentication of the subscriber. In addition, the HAAA
communicates with the PPS using the RADIUS protocol in order to
authorize subscribers.
o The AAA server in the visited network (VAAA) which exists only in
roaming scenarios and is responsible for forwarding the RADIUS
messages to the HAAA. The VAAA may also modify the messages.
Note that, in certain roaming deployments, the visited network may
be connected to the home network via one or more broker networks.
o The AAA server in one of the aforementioned broker networks
(BAAA), which is responsible for forwarding messages and does not
play an active role in the prepaid data service delivery. A BAAA
obviously exists only in those roaming deployments where the VAAA
and the HAAA are connected via the BAAA of a broker network.
This document assumes that the PPS communicates with the HAAA for the
purposes of authorisation. Additionally, the PPS interfaces to
entities which entities which
- Keep the subscriberÆs account balance (balance manager), o keep the subscriber's account balance (balance manager),
- Rate access service requests in real-time (Rating Engine), and
- Manage quota for a particular prepaid service (Quota Server). o rate access service requests in real-time (Rating Engine), and
o manage quota for a particular prepaid service (Quota Server).
Three deployment scenarios are presented in the remainder of this Three deployment scenarios are presented in the remainder of this
section. The first scenario is depicted in Figure 2. In this section. The first scenario is depicted in Figure 2. In this
scenario, the SAD, which runs the PPC, the HAAA, and the PPS are scenario, the SAD, which runs the PPC, the HAAA, and the PPS are
located in the same provider network. located in the same provider network.
The Subscriber 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. However, in order to provide redundancy, multiple HAAA HAAA server (directly or indirectly).
may be available.
The network has one or more PPSs. The interface between the HAAA and The interface between the HAAA and the PPS is implemented using the
the PPS is implemented using the RADIUS protocol together with the RADIUS protocol together with the extensions described in this
extensions described in this document. However, in cases where the document. However, in cases where the PPS does not implement the
PPS does not implement the RADIUS protocol, the implementation would RADIUS protocol, the implementation would have to map the
have to map the requirements defined in this document to a requirements defined in this document to a functionally equivalent
functionally equivalent protocol. protocol.
+------+ +-----+ +------+ +-----+
| | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | | | | | | | | | | | |
| Subscr.| | Service| | +------+ | +-----+ | Subscr.| | Service| | +------+ | +-----+
| |---| Access |--+ | | |---| Access |--+ |
| 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 | | +----+ | +----+ | +----+ | +-----+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | |
+----+ +----+ +----+ +-----+ +----+ +----+ +----+ +-----+
| Visited | |Broker | | Home |
| Network | |Network| | Network |
Figure 3 Static Roaming Prepaid Architecture Figure 3: Static roaming prepaid architecture
As in the basic prepaid architecture the subscriberÆs device Like in the basic prepaid architecture, the subscriber device
establishes a connection with the SAD. The SAD communicates with the establishes a connection with the SAD. The SAD communicates with the
VAAA using the RADIUS protocol. The VAAA, in turn, communicates VAAA using the RADIUS protocol. The VAAA, in turn, communicates
using the RADIUS protocol with BAAA servers in the broker network. using the RADIUS protocol with BAAA servers in the broker network.
There maybe more then one Broker Network between the Visited Network There may be more than one Broker Network between the Visited Network
and the Home Network. The Home Network is the same as in the and the Home Network. The Home Network is the same as in the
architecture depicted in Figure 2. architecture depicted in Figure 2.
The third scenario is a roaming scenario where the network utilises Broker AAA (BAAA) servers MUST support the Message-Authenticator(80)
Mobile-IP. It is depicted Figure 4. In this scenario the mobile attribute as defined in RFC 2869. If they are used, they forward the
device moves between networks that use different technologies such RADIUS packets as usual to the appropriate RADIUS servers.
as between WLAN and Broadband. Mobile-IP addresses this type of
mobility and therefore we need not be concerned with the underlying
network technology.
+------+ +-------+ +----+ +----+ +----+ +-----+
| | |Service| | | | | | | | |
|Subscr| |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS |
| |--|Device | | | | | | | | |
|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
| | | | | |
+------+ +------ + | |
| | | +----+
| | | | |
|ROAMS +------------------+ HA |
| | | |
V +----+ | +----+
+------+ +-------+ | | | |
| | |Service| +-|VAAA+------+ |
|Subscr| |Access | | | | |
| |--|Device +-+ +----+ |
|Device| | (FA) | |
| | | +------------------------+
+------+ +-------+
Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs
In Figure 4, the Subscriber Device establishes a session with the Accounting messages are not needed to deliver a prepaid service.
SAD in the foreign network. The setup for this access service is
identical to the cases covered above. Note that the SAD may be
collocated with the Foreign Agent (FA) if Mobile-IPv4 is being used.
As the subscriber device moves, it establishes a connection with
another SAD possibly in another foreign network. The prepaid data
service should continue to be available. When a device associates to
another SAD it MUST re-authenticate at the new SAD and de-associate
or log off from the old SAD. Furthermore, any unused quota at the
old SAD MUST be credited into the subscriberÆs account immediately.
This has to happen immediately because otherwise, if the
subscriberÆs funds are low, he may be denied service at the new SAD.
Note that, if the SADs communicate directly with each other then However, accounting messages can be used to keep the PPS up to date
there could be a way to accelerate the handoff procedure. In as to what is happening with the prepaid data session. Therefore, a
particular, the subscriber could be refunded more quickly. BAAA SHOULD deliver RADIUS Accounting messages using the pass through
Unfortunately, handoff procedures are specific to the underlying mode described in RFC 2866.
network technologies and vary significantly in terms of delay.
2.3 1.2.2. Motivation
Motivation
It has been asked ôWhy not use existing RADIUS attributes to Why not use existing RADIUS attributes to construct a protocol for
construct a protocol for prepaid scenarios? This will allow us to prepaid scenarios? This could lead to a solution where no code has
have a solution with existing devices without code modification.ö to be modified at existing devices.
It is indeed possible to construct a solution for prepaid billing It is indeed possible to construct a solution for prepaid billing
scenarios using existing RADIUS attributes. The RADIUS server would scenarios using existing RADIUS attributes. The RADIUS server would
send an Access-Accept message containing a Session-Timeout(27) and send an Access-Accept message containing a Session-Timeout(27) and
include a Termination-Action(29) in the RADIUS-request. Upon include a Termination-Action(29) in the RADIUS-request. Upon
receiving the Access-Accept message, the NAS would meter the receiving the Access-Accept message, the NAS would meter the duration
duration of the session and upon termination of the session the NAS of the session and upon termination of the session the NAS would
would generate an Access-Request message again. The RADIUS server generate an Access-Request message again. The RADIUS server would
would then re-authenticate the session and reply with an Access- then re-authenticate the session and reply with an Access-Accept
Accept message indicating the amount of additional time in a message indicating the amount of additional time in a Session-
Session-Timeout(27). Alternatively, it would responds with an Timeout(27). Alternatively, it could respond with an Access-Reject
Access-Reject message if there were no more resources in the userÆs message if there were no more resources in the user account.
account.
Moreover, if the user terminates the session prematurely, the NAS Moreover, if the user terminates the session prematurely, the NAS
would recover any unused time from the accounting stream. could indicate this in the accounting stream so that unused funds can
be returned into the prepaid user account.
There are several problems with such a solution: Unfortunately, the above "solution" has a number of problems,
including the following.
- It only supports time-based accounting. The solution presented in o It only supports time-based accounting. The solution presented in
this document supports both time and volume based prepaid. this document supports both time and volume based prepaid.
- Using accounting messages to recoup unused time may be problematic o Using accounting messages to recoup unused time may be problematic
because RADIUS accounting messages are not delivered in real-time. because RADIUS accounting messages are not delivered in real-time.
A RADIUS server may store-and-forward accounting messages in A RADIUS server may store-and-forward accounting messages in
batches. The solution presented in this document does not rely on batches. Thus, relying on accounting messages for the purposes of
Accounting Packets at all. It uses Access-Request, messages which do prepaid may cause revenue leakage. The solution presented in this
flow through any network in real-time. Delaying accounting messages document does not rely on Accounting packets at all. It uses
may cause revenue leakage. Access-Request messages, which are required to flow through any
network in real-time.
- Session-Timeout(27) is not a mandatory attribute. If a prepaid o Session-Timeout(27) is not a mandatory attribute. If a prepaid
subscriber is being serviced by a NAS that does not adhere to subscriber is being serviced by a NAS that does not adhere to
Session-Timeout then that subscriber may use the service for an Session-Timeout then that subscriber may use the service for an
undetermined period of time. undetermined period of time.
- Termination-Action(29) presents its own issues. Firstly the o Termination-Action(29) presents its own issues. Firstly the
behaviour of Termination-Action(29) is not mandatory. Secondly, behaviour of Termination-Action(29) is not mandatory. Secondly,
according to RFC2865, Termination-Action fires when the provision of according to RFC 2865, Termination-Action fires when the provision
the service has completed. However, service should not be terminated of the service has completed. However, service should not be
when negotiating additional quota, because this should happen in a terminated when negotiating additional quota, because this should
manner transparent to the subscriber. Because Termination-Action happen in a manner transparent to the subscriber. Due to the fact
occurs when the Service is completed it is unclear whether or not that Termination-Action occurs when the service is completed, it
user experience would be affected. The RADIUS server might even is unclear whether or not user experience would be affected if
allocate a new IP address to the subscriberÆs device. Furthermore, this attribute would be used in a prepaid scenario. The RADIUS
the RADIUS server has no way of telling why the Access-Request server might even allocate a new IP address to the subscriber
message was generated. The RADIUS server might have to wait for the device after a Termination-Action. Also, the RADIUS server has no
corresponding accounting packet to determine the reason for this way of telling why a given Access-Request message was generated.
Access-Request message. Finally, re-authenticating the subscriber The RADIUS server might have to wait for the corresponding
may take too long. The solution presented in this document allows accounting packet to determine the reason. Finally, re-
quota replenishing to occur in an undisruptive manner from the user authenticating the subscriber may take too long. The solution
perspective. No re-authentication is required and quotas can be presented in this document allows quota replenishing to occur
negotiated prior to the available credit running out. without affecting user experience. No re-authentication is
required and quotas can be negotiated before the available credit
actually runs out.
- 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 described might be able to obtain the service for free. The solution
in this document requires that a prepaid-aware SAD informs the described in this document requires that a prepaid-aware SAD
RADIUS server, regardless of whether or not the latter supports the informs the RADIUS server, regardless of whether or not the latter
prepaid extensions. The RADIUS server can then determine whether or supports the prepaid extensions. The RADIUS server can then
not service should be granted. For example, if a prepaid subscriber determine whether or not service should be granted. For example,
is connected to a NAS that does not support prepaid, the RADIUS if a prepaid subscriber is connected to a NAS that does not
server can either instruct the NAS to tunnel the traffic to another support prepaid, the RADIUS server can either instruct the NAS to
entity in the home network (e.g. the Home Agent) that supports tunnel the traffic to another entity in the home network (e.g. the
prepaid, or it provide only a restricted service.] Home Agent) that supports prepaid, or it provide only a 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 Authorize-Only packet to and that they generate an Access-Request Authorize-Only packet to
obtain more quota when or before the current quota is used up. It obtain more quota when or before the current quota is used up. It
also requires the NAS to send an Access-Request with Authorize-Only also requires the NAS to send an Access-Request with Authorize-Only
when the session terminates in order to refund the subscriberÆs when the session terminates in order to refund the subscriber
account appropriately. account.
The solution provided in this document is extensible. For example, 1.3. A simple use case
the protocol can be extended to support tariff switching and other
prepaid business models.
The extensions described in this document were designed based on a This section describes the sequence of events in a simple RADIUS
number of use cases and scenarios. An overview of these can be found prepaid transaction.
in Appendix A.
3. 1. When an end host attaches to a network (for example, using PPP or
Operations PANA), as usual, the NAS (SAD) that is servicing the subscriber
uses the AAA infrastructure to authenticate and authorize the
subscriber (if such network accesss authentication is required).
3.1 2. The SAD sends a RADIUS Access-Request to the AAA server in order
General Requirements 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.
Prepaid capabilities MUST be included if the SAD supports them.
3.1.1 3. The authentication procedure proceeds. This may involve several
Broker AAA Requirements message exchanges such as in EAP [RFC2284]. Once the subscriber
has been successfully authenticated, the home AAA server
determines that the subscriber is a prepaid subscriber and
requests authorisation from the PPS. The request MUST include
the prepaid capabilities of the serving SAD.
Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) 4. The PPS validates that the subscriber has a prepaid account and
attribute as defined in [RFC2869]. If they are used, they forward that the account is active. It further validates that the SAD
the RADIUS packets as usual to the appropriate RADIUS servers. has the appropriate prepaid capabilities. If all is in order,
the PPS authorises the subscriber to use the network. Otherwise
it rejects the request. The decision is sent to the AAA system.
The response includes attributes to indicate the allocation of a
portion of the subscriber credit. This portion is called the
"initial quota" (in units of time or volume) and optionally a
threshold value. Note that only a 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 example, the user may be
engaged in a data session and a voice session. Although these
two services would draw from the same account, they form separate
parts of the overall system. If the entire quota was allocated
to the data session then the user would have no more funds for a
voice session.
Accounting messages are not needed to deliver a prepaid service. 5. The AAA system incorporates the attributes received from the PPS
However, accounting messages can be used to keep the PPS up to date into an Access-Accept message that it sends to the SAD. Note
as to what is happening with the prepaid data session. Therefore, a that the AAA system is responsible for authorizing the service
BAAA SHOULD deliver RADIUS Accounting messages using the pass whereas the prepaid system is responsible for prepaid
through mode described in [RFC2866]. authorization.
3.2 6. Upon receiving the Access-Response, the SAD starts the prepaid
Authentication and Authorization for Prepaid Enabled SADs data session and meters the session based on time or volume, as
indicated in the message.
The SAD initiates the authentication and authorization procedure by 7. Once the usage for the session approaches the allocated limit (as
sending a RADIUS Access-Request to the HAAA. expressed by the threshold), the SAD will request additional
quota. Re-authorization for additional quota flows through the
AAA system to the PPS. The PPS revalidates the subscriber
account and subtracts the previously allocated quota from the
current balance. If there is remaining balance, it reauthorizes
the request with an additional quota allotment. Otherwise, the
PPS rejects the request. Note that the replenishment of the
quota is a re-authorization procedure and does not require the
subscriber to authenticate himself again.
If the SAD has PPC capabilities, it MUST include the PPAC(TBD) 8. Upon receiving a re-allotment of the quota, the SAD continues to
attribute in the RADIUS Access-Request. The PPAC(TBD) attribute provide the data service until the new threshold is reached. If
indicates to the PPS which prepaid capabilities are possessed by the the request for additional quota cannot be fulfilled then the SAD
SAD. These are required in order to complete the prepaid lets the subscriber use the remaining quota and terminates the
authorization procedure. session. Alternatively, instead of terminating the session, the
SAD may restrict the data session such that the subscriber can
only reach a particular web server. This web server maybe used
to allow the subscriber to replenish his account. This
restriction can also be used to allow new subscribers to set up
prepaid accounts in the first place.
If the SAD supports the Disconnect-Message or the Change-of- 9. Should the subscriber terminate the session before the quota is
Authorization capabilities, then it SHOULD include the Dynamic- exhausted, the remaining balance allotted to the session MUST be
Capabilities attribute. refunded into his account.
Note that the subscriber may have disconnected while the Access
Device is waiting for the initial quota. The entire allocated quota
will be credited back to the subscribers account in this case. Also
note that the PPS maintains session state for the subscriber. This
state includes how much account balance was allocated during the last
quota enquiry and how much is left in the account. Therefore, it is
required that all messages about the session reach the same (and
correct) PPS.
For a simple message flow, along the lines of this use case, please
see Appendix A.
2. Supported Features
This section describes the features that are supported by the prepaid
extensions defined in this draft.
2.1. Multiple Concurrent Services
Examples of services that the user may be using are browsing the web,
participating in a VoIP conversation, watching streaming video and
downloading a file. Some operators may want to distinguish between
these services. Some services are chaged at different rates and
services may be metered differently. Therefore, the prepaid solution
needs to be able to distinguish services, and allocate quota to the
services using different unit types (time, volume) and allow for
those quotas to be consumed at different rates.
+---------+
| Session |
+---------+
| 1
V N
+--------------+ 1 : 1 +-------+
| Service |------>| Quota |
| (service-Id) | +-------+
+--------------+
Figure 4: Multiple services within a single session
As shown in Figure 4, a session may be associated with multiple (N)
services. Each service is identified by a service identifier
(Service-ID). The format of the Service-ID is not in the scope of
this document but it could be expressed as an IP flow using the
5-tuple {Source-IP and Port, Destination-IP and Port, protocol type}.
Each service is associated with a quota metric. An example message
flow that involves multiple such services within a single session is
given in the appendix.
2.2. Resource Pools
When working with multiple services a new problem arises because one
service may consume its quota faster than another service. When the
user balance is close to exhaustion, a situation could arise where
one service is unable to obtain quota while another service has
plenty of quota remaining. Unless the quotas can be rebalanced, the
SAD would then have to terminate the former service. Moreover, if
each service generates a certain amount of RADIUS prepaid traffic.
In an environment with many users and chargarble services, this
amount of traffic is considerable and could leads inefficiency.
One method to circumvent the above situation is to use a so-called
"resource pool". Resource pools enable the allocation of resources
to multiple services of a session by allocating resources to a pool
and have services draw their quota from the pool at a rate
appropriate to that service. When the quota that has been allocated
to the pool is close to exhaustion, the entire pool (rather than
individual services) is replenished.
+-----------+
| Service-A |-----+ +--------+
+-----------+ | Ma | |
+-------->| |
| Pool |
+-------->| (1) |
+-----------+ | Mb | |
| Service-B |-----+ +--------+
+-----------+
Figure 5: Resource pool example
As shown in Figure 5, Service-A and Service-B are bound to Pool(1).
Ma and Mb are the pool multipliers (that are associated with
Service-A and Service-B respectively) that determine the rate at
which Service-A and Service-B draw from the pool.
The pool is initialized by taking the quota allocated to service n
and multiplying it by Mn. Therefore, the amount of resources
allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where
Qn denotes the amount of quota that is allocated to service n.
Further, the pool is considered to be empty if
Poolr <= Ca*Ma + Cb*Mb + . . .,
Figure 6
where Ca and Cb are resources consumed by Service-A and Service-B
respectively.
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
can rated at $0.10 per minute. In this case if $5 worth of resources
are allocated for service-A to the pool and if Ma = 10, then 50 units
would be placed into the pool. If a further $5 are allocated for
service-B to the pool, then M=1 and 50 units are deposited into the
pool. The pool would then have a total sum of 100 units to be shared
between the two services. The PPC would then mater the services such
that each Mbyte used by Service-A will draw 10 units from the pool
and each minute used by Service-B will draw 1 unit from the pool.
2.3. Complex Rating Functions
The rating of a service can be quite complex. While some operators
follow linear pricing models, others may wish to apply more complex
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
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
exchanges with the prepaid system.
To avert the need to exchange many messages while still supporting
such complex rating functions, the notion of a "Rating Group" is
introduced. A Rating Group are typically configured at the SAD. As
shown in Figure 7, a Rating Group is associated with one or more
services and defines the rate that the services associated with the
Rating Group consume an allocated amount of quota.
+--------------+ +--------------+
+-----------+ N 1 | | M 1 | Resource Pool|
| Service-A +---------->| Rating Group |------>| or |
+-----------+ | | | Quota |
+--------------+ +--------------+
Figure 7: Example of a rating group
During the usage of a service that is associated with a Rating Group,
the PPC sends the ID of the Rating Group to the PPS. The PPS
authorises the Rating Group by allocating a quota to it and
optionally assigning it to a Resource Pool. When an additional
service that belongs to an already authorised Rating Group is
instantiated, the PPC does not need to authorize this service. This
effectively means that the PPC meters the service such that it draws
from the already allocated quota. Therefore, no RADIUS messages need
to be exchanged in this case. This limits the amount of traffic
between the PPC and the PPS. An example of a flow that uses Rating
Groups is given in Appendix A.3
2.4. One-time Charging
One-time charging is a mode of operation of where the RADIUS prepaid
extensions are used for charging of a service that is provided
instansteneously, i.e. without an ongoing session. An example of
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
one-time service event is the purchase of a subscription.
For a given user, one-time-based charging may occur in parallel with
other charging models. For example, the subscriber may access a
website which is metered (based on time or volume) while he also
purchases the right to use a ring tone (a one-time-based event).
Note: it is up to the service providers to decide whether or not the
user will be charged for the download of the tone and also be charged
for the time and volume required to download the ring-tone. The
facilities provided by this document gives the service provider the
capability to achieve their service charging business goals. For
example, should the service provider choose not to charge for the
download volume or time, then they can treat the download IP flow as
a separate service that is not subject to charging.
The SAD signals one-time-based charging to the PPS with an indication
that identifies the service and the units that should be debited from
the user account.
A SAD may decide to perform one-time-based charging for an event that
was triggered by an unauthenticated user. In this case case the SAD
will have to authenticate the user before sending the relevant
message to the user's home AAA server.
Note that one-time-based charging can also be used to credit the
prepaid account. For example, the SAD can return resources to the
subscriber by issuing a one-time charge request that includes the
amount of resources to be credited into the account.
2.5. Tariff Switching
The PPC and the PPS may support tariff switching. For example, as
shown in Figure 8, traffic before 18:00 may be rated at rate r1 and
traffic after 18:00 is rated at rate r2. The PPC reports usage
before and after the switch occurs. Tariff switching does not make
sense for services that are metered based on time, and the
consumption of which is continuous (i.e. without interruption).
18:00
------------------+-----------------
r1 | r2
------------------+-----------------
^ ^
|<----TSI---> |
| |
Access-Accept Access-Request
(quota allocated) (quota consumed)
Figure 8: Example of tariff switching
The PPC it indicates support for tariff switching by setting the
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
time when the switch will occur. This indication represents the
number of seconds from current time (TarrifSwitchInterval TSI).
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
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
tariff switch using the PTS VUATS subtype.
In situations with multiple tariff switches, the PPS must specify the
length of the tariff switch period using the
TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as
shown below.
18:00 23:30
------------------+---------------------+--------------
r1 | r2 | r3
------------------+---------------------+--------------
^ ^ ^
|<----TSI---><-----------|-------->|TITSU
| |
Access-Accept Access-Request
Figure 9: Multiple tariff switches
When a TITSU is specified in the PTS, the PPC MUST generate an
Access-Request within the time after TSI and before TITSU expires.
Note that, typically, the PPC will be triggered by the Volume
Threshold. However, it is possible that, during period r2, resources
are not entirely consumed and, thus, the threshold is not reached.
Even in this case PPC MUST generate an Access-Request in good time.
Also note that separate services flows may have individual tariff
periods.
2.6. Support for Roaming
In certain networks it is essential for prepaid data services to be
available to roaming subscribers. Support for both static and
dynamic roaming models is needed. In a static roaming scenario the
subscriber connects to a foreign network which has a roaming
agreement either directly with the home network, or through a broker
network. When the subscriber logs into another foreign network, a
new login procedure has to be executed.
In a dynamic roaming scenario the subscriber may move between
networks while maintaining his connection. In such a scenario the
data session is seamlessly handed off between the networks.
In both roaming scenarios, the subscriber always authenticates
himself to the home network. Authorization for the prepaid session
and quota replenishing occurs at the home network and more
specifically at the PPS where state is being maintained.
Dynamic roaming is challenging because a subscriber who established a
prepaid data session may move to another Access Device that does not
support the prepaid extensions. Even in this case the system should
be able to continue the prepaid session.
2.7. Dynamic Termination
When fraud or an error is detected, either only the affected session,
or all sessions of the affected subscriber should be immediately
terminated. It may further happen that the prepaid system enters a
state where it is unclear whether or not the data session is in
progress. Under certain conditions, the system may wish to terminate
the session in order to make sure that the user is not charged for
this potential inactivity.
Certain handoff procedures used in dynamic roaming scenarios require
that the system terminates the subscribers prepaid data session at a
SAD. This is the case, for example, when time-based prepaid is used
and the mobile subscriber performs a dormant handoff.
2.8. Querying and Rebalancing
It should be possible for the PPS to Query the current resource
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
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
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
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
this phenomenon by allocating small quotas, a practice that results
in more message exchanges.
3. Operations
This section describes the operations that are implemented by a
prepaid-enabled NAS (SAD).
3.1. Authentication and Authorization Operation
The SAD initiates the authentication and authorization procedure by
sending a RADIUS Access-Request to the HAAA. Since the SAD has PPC
capabilities, it MUST include a PPAC attribute in the RADIUS Access-
Request. The PPAC attribute indicates to the PPS which prepaid
capabilities are possessed by the SAD. These are required in order
to complete the prepaid authorization procedure. Moreover, if the
SAD supports the Disconnect-Message or the Change-of-Authorization
capabilities, then it SHOULD include the Dynamic-Capabilities
attribute.
In certain deployments, there may be other ways to terminate a data In certain deployments, there may be other ways to terminate a data
session, or change authorization of an active session. For example, session, or change authorization of an active session. For example,
some SADs provide a session termination service via Telnet or SNMP. some SADs provide a session termination service via Telnet or SNMP.
In these cases, the AAA server MAY add the Dynamic-Capabilities In these cases, the AAA server MAY add the Dynamic-Capabilities
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 Dynamic-Capabilities attribute (if used) in at least the last Access-
Access-Request of the authentication procedure. Request of the authentication procedure.
The Access-Request is sent as usual to the HAAA. The packet may pass The Access-Request is sent as usual to the HAAA, possibly through one
through one or more BAAA. 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.
The Access-Request contains the PPAC(TBD) attribute and the Dynamic- The Access-Request contains the PPAC(TBD) attribute and the Dynamic-
Capabilities attribute if one was included. The User-Name(1) Capabilities attribute if one was included. The User-Name(1)
attribute MAY be set to a value that represents the subscriberÆs attribute MAY be set to a value that identifies the subscriber. This
identifier. This attribute is used by the PPS to locate his attribute is used by the PPS to locate his account. For added
account. For added security, the HAAA MAY also set the User- security, the HAAA MAY also set the User-Password(2) attribute to the
Password(2) attribute to the password used between the HAAA and the password used between the HAAA and the PPS.
PPS.
The PPS locates the subscriberÆs account and authorizes him. During The PPS locates the subscriber account and authorizes him. During
this procedure, the PPS takes into consideration the SAD PPC this procedure, the PPS takes into consideration the SAD PPC
Capabilities. Capabilities. Upon successful authorization, the PPS generates an
Access-Accept containing an PPAC attribute and an PPAQ attribute.
Upon successful authorization, the PPS generates an Access-Accept
containing the PPAC(TBD) attribute and the PPAQ(TBD) attribute.
The PPAC attribute returned to the client indicates the type of The PPAC attribute returned to the client indicates the type of
prepaid service to be provided for the session. The PPAQ(TBD) prepaid service to be provided for the session. The PPAQ attribute
attribute includes the following. includes the following information.
- The QUOTA-ID, which is set by the PPS to a unique value that is o The QUOTA-ID, which is set by the PPS to a unique value that is
used to correlate subsequent quota requests; used to correlate subsequent quota requests.
- Volume and/or Time quotas, which are set to values representing a o Volume and/or Time quota, which is set to a value representing a
portion of the subscribers credit; portion of the subscriber's credit.
- It MAY contain a Time or Volume Threshold that controls 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.
- 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).
Note: Idle-Timeout(28) can be used to trigger the premature Note: The Idle-Timeout(28) attribute can be used to trigger the
termination of a prepaid service, for example as a result of premature termination of a prepaid service, for example as a result
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 to terminate the session immediately. generate an Access-Reject in order to terminate the session
Alternatively, the PPS may generate an Access-Accept blocking some immediately. Alternatively, the PPS may generate an Access-Accept
or all of the traffic and/or redirect some or all of the traffic to blocking some or all of the traffic and/or redirect some or all of
a location to a fixed server. (This feature could be used, for the traffic to a location to a fixed server. (This feature could be
example, to prompt the user to replenish their account.) Blocking of used, for example, to prompt the user to replenish their account.)
traffic is achieved by either Filter-ID(11) or NAS-Filter-Rule(see Blocking of traffic is achieved by either Filter-ID(11) or NAS-
Redirect I-d). Redirection is achieved by sending Redirect-Id or Filter-Rule(see Redirect I-d). Redirection is achieved by sending
Redirect-Rule, HTTP Redirection defined in the Redirect I-d. The Redirect-Id or Redirect-Rule, HTTP Redirection defined in the
time period before the session is blocked/redirected is specified by Redirect I-d. The time period before the session is blocked/
the Session-Timeout(27) attribute. redirected is specified by the Session-Timeout(27) attribute.
Upon receiving an Access-Accept from the PPS, the HAAA appends the Upon receiving an Access-Accept from the PPS, the HAAA appends the
usual service attributes and forward the packet to the SAD. The usual service attributes and forward the packet to the SAD. The HAAA
HAAA SHOULD NOT overwrite any attributes already set by the PPS. If SHOULD NOT overwrite any attributes already set by the PPS. If the
the HAAA, receives an Access-Reject message, it will simply forward HAAA receives an Access-Reject message, it will simply forward the
the packet to its client. Depending on site policies, if the HAAA packet to its client. Depending on site policies, if the HAAA does
does not receive an Access-Accept or an Access-Reject message from not receive an Access-Accept or an Access-Reject message from the PPS
the PPS it MAY do nothing or send an Access-Reject or an Access- it MAY do nothing or send an Access-Reject or an Access- Accept
Accept message back to the PPC. message back to the PPC.
3.3 3.2. Session Start Operation
Session Start Operation
The start of the session is indicated by the arrival of an The start of the session is indicated by the arrival of an
Accounting-Request(Start) packet. The Accounting-Request (Start) MAY Accounting-Request(Start) packet. The Accounting-Request (Start) MAY
be routed to the PPS such that it can confirm the initial quota be routed to the PPS such that it can confirm the initial quota
allocation. allocation.
Note that the role of the PPS is not to record accounting messages Note that the role of the PPS is not to record accounting messages
and therefore it SHOULD not respond with an Accounting Response and therefore it SHOULD NOT respond with an Accounting Response
packet. packet. If the PPS does not receive the Accounting-Request(start)
message it will only know that the session has started upon the first
If the PPS does not receive the Accounting-Request(start) message it reception of a quota replenishment operation.
will only know that the session has started upon the first reception
of a quota replenishment operation.
If the PPS does not receive indication directly (via Accounting- If the PPS does not receive indication directly (via Accounting-
Request(start)) or indirectly, it SHOULD after some configurable Request(start)) or indirectly, it SHOULD, after some configurable
time, deduce that the Session has not started. 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 termination capabilities, the PPS SHOULD send a Disconnect Message to
to the SAD to ensure that the session is indeed dead. the SAD as a measure to ensure that the session is indeed dead.
3.4 3.3. Mid-Session Operation
Mid-Session Operation
During the lifetime of a prepaid data session the SAD requests the During the lifetime of a prepaid data session the SAD may request the
replenishment of the quotas using Authorize-Only Access-Request replenishment of the quotas using Authorize-Only Access-Request
messages. message. Once either the allocated quota has been exhausted or the
threshold has been reached, the SAD MUST send an Access-Request with
Once either the allocated quota has been exhausted or the threshold Servicetype(6) set to a value of "Authorize Only" and the PPAQ(TBD)
has been reached, the SAD MUST send an Access-Request with
Servicetype(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD)
attribute. attribute.
The SAD MUST also include NAS identifiers, and Session identifier The SAD MUST also include NAS identifiers, and Session identifier
attributes in the Authorize Only Access-Request. The Session attributes in the Authorize Only Access-Request. The Session
Identifier should be the same as the one used during the Access- Identifier should be the same as the one used during the initial
Request. For example, if the User-Name(1) attribute was used in the Access-Request. For example, if the User-Name(1) attribute was used
Access-Request it MUST be included in the Authorize Only Access- in the Access-Request it MUST be included in the Authorize Only
Request, especially if the User-Name(1) attribute is used to route Access-Request, especially if the User-Name(1) attribute is used to
the Access-Request to the Home AAA server. route the Access-Request to the Home AAA server.
The Authorize Only Access-Request MUST NOT include a User Password The Authorize Only Access-Request MUST NOT include a User Password
and MUST NOT include a Chap Password. In order to authenticate the and MUST NOT include a Chap Password. In order to enable the
message, the SAD MUST include a Message-Authenticator(80) attribute. receiver to authenticate the message, the SAD MUST include a Message-
The SAD computes the value for the Message-Authenticator according Authenticator(80) attribute. The SAD computes the value for the
to [RFC2869]. Message-Authenticator according to RFC 2869.
When the HAAA receives the Authorize-Only Access-Request that When the HAAA receives an Authorize-Only Access-Request that contains
contains a PPAQ(TBD), it SHALL validate the message using the a PPAQ(TBD), it SHALL validate the message using the Message-
Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an Authenticator(80), according to RFC 2869. If the HAAA receives an
Authorize Only Access-Request that contains a PPAQ(TBD) but not a Authorize Only Access-Request that contains a PPAQ(TBD) and either no
Message-Authenticator(80) it SHALL silently discard the message. An or an invalid Message-Authenticator(80) it SHALL silently discard the
Authorize Only Access-Request message that does not contain a message. An Authorize Only Access-Request message that does not
PPAQ(TBD) is either erroneous or belongs to another application (for contain a PPAQ(TBD) is either erroneous or belongs to another
example, a Change of Authorization message [RFC3576]). In this case application (for example, a Change of Authorization message
the Authorize Only Access-Request is either silently discarded or [RFC3576]). In this case the Authorize Only Access-Request is either
handled by another application. silently discarded or handled by another application.
Once the Authorize Only Access-Request message is validated, the Once the Authorize Only Access-Request message is validated, the HAAA
HAAA SHALL forward the Authorize Only Access-Request to the SHALL forward the Authorize Only Access-Request to the appropriate
appropriate PPS. The HAAA MUST forward the Authorize Only Access- PPS. The HAAA MUST forward the Authorize Only Access-Request to the
Request to the PPS specified in the PPAQ(TBD). The HAAA MUST add an PPS specified in the PPAQ(TBD). The HAAA MUST add a Message-
Message-Authenticator(80) to the message, according to [RFC2869]. Authenticator(80) to the message, according to RFC 2869. As with the
As with the Access-Request message, the HAAA MAY modify the User- Access-Request message, the HAAA MAY modify the User-Name(1)
Name(1) attribute such that it represents the userÆs internal attribute such that it identifies the user to the PPS. Note that the
prepaid account in the PPS. Note the PPS may also use the Quota-ID PPS may also use the Quota-ID sub-attribute contained within the
sub-attribute contained within the PPAQ(TBD) to locate the user PPAQ(TBD) to locate the user account.
account.
Upon receiving the Authorize Only Access-Request containing a Upon receiving the Authorize Only Access-Request containing a
PPAQ(TBD) attribute, the PPS MUST validate the Message- PPAQ(TBD) attribute, the PPS MUST validate the Message-
Authenticator(80) as described in [RFC2869]. If validation fails, Authenticator(80) as described in RFC 2869. If validation fails, the
the PPS MUST silently discard the message. If it receives an PPS MUST silently discard the message. If it receives an Authorize
Authorize Only Access-Request message that does not contain a Only Access-Request message that does not contain a PPAQ(TBD), it
PPAQ(TBD) it MUST silently discard the message. MUST silently discard the message.
The PPS locates the prepaid session state using the Quota Id The PPS locates the prepaid session state using the Quota Id
contained within the PPAQ(TBD). The PPS takes the most recently contained within the PPAQ(TBD). The PPS takes the most recently
allocated quota and subtracts it from the userÆs balance. If allocated quota and subtracts it from the user balance. If
sufficient balance remains, the PPS authorizes the PPS and allocates sufficient balance remains, the PPS authorizes the PPS and allocates
additional quota. The PPS may also calculate a new threshold value. additional quota. The PPS may also calculate a new threshold value.
Upon successful re-authorization, the PPS generates an Access-Accept Upon successful re-authorization, the PPS generates an Access-Accept
containing the PPAQ(TBD) attribute. The Access-Accept message MAY containing the PPAQ(TBD) attribute. The Access-Accept message MAY
contain Servicetype(6) set to Authorize-Only and MAY contain the contain Servicetype(6) set to Authorize-Only and MAY contain the
Message-Authenticator(80). Message-Authenticator(80).
Depending on site policies, upon unsuccessful authorization, the PPS Depending on site policies, upon unsuccessful authorization, the PPS
generates an Access-Reject or an Access-Accept with Filter-Id(11) or generates an Access-Reject or an Access-Accept with Filter-Id(11) or
Ascend-Data-Filter (if supported) attribute and the Session- Ascend-Data-Filter (if supported) attribute and the Session-
Timeout(27) attribute such that the subscriber can get access to a Timeout(27) attribute such that the subscriber can get access to a
restricted set of locations for a short period of time. This feature restricted set of locations for a short period of time. This feature
could be used to enable users to replenish their accounts, create could be used to enable users to replenish their accounts, create new
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
the packet to its client. If the HAAA receives an Access-Reject the packet to its client. If the HAAA receives an Access-Reject
message, it forwards the packet. Depending on site policies, if the message, it forwards the packet. Depending on site policies, if the
HAAA does not receive an Access-Accept or an Access-Reject message HAAA does not receive an Access-Accept or an Access-Reject message
from the PPS it MAY do nothing or it MAY send an Access-Reject from the PPS it MAY do nothing or it MAY send an Access-Reject
message back to its client. message back to its client.
Upon receiving an Access-Accept, the SAD SHALL update its quotas and Upon receiving an Access-Accept, the SAD SHALL update its quotas and
threshold parameters with the values contained in the PPAQ(TBD) threshold parameters with the values contained in the PPAQ(TBD)
attribute. Note that the PPS MAY update the PrePaidServer attribute. Note that the PPS MAY update the PrePaidServer
attribute(s) and these may have to be saved as well. attribute(s) and these may have to be saved as well. If the Access-
Accept message contains a Filter-Id(11), an Ascend-Data-Filter
attribute, or Session Timeout(27), the SAD SHALL restrict the
subscriber session accordingly.
Upon receiving an Access-Accept message that contains an Filter- 3.4. Dynamic Operations
Id(11), an Ascend-Data-Filter attribute, or Session Timeout(27), the
SAD SHALL restrict the subscriber session accordingly.
3.5
Dynamic Operations
The PPS may take advantage of the dynamic capabilities that are The PPS may take advantage of the dynamic capabilities that are
supported by the SAD as advertised in the Dynamic-Capabilities supported by the SAD as advertised in the Dynamic-Capabilities
attribute during the initial Access-Request. attribute during the initial Access-Request. There are two types of
action that the PPS may perform. Firstly, it may request the session
to be terminated. Secondly, it may request the attributes associated
with the session to be modified. More specifically, it may modify a
previously sent PPAQ(TBD).
There are two types of action that the PPS may perform. Firstly, it Both of these actions require that the session be uniquely identified
may request the session to be terminated. Secondly, it may request at the SAD. As a minimum, the PPS MUST provide
the attributes associated with the session to be modified. More
specifically, it may modify a previously sent PPAQ(TBD)
Both of these actions require that the session be uniquely 1. either the NAS-IP-Address(4) or the NAS-Identifier(32), and
identified at the SAD. As a minimum the PPS MUST
- provide either the NAS-IP-Address(4) or the NAS-Identifier(32) 2. at least one session identifier such as User-Name(1), Framed-IP-
- provide at least one session identifier such as User-Name(1), Address(), the Accounting-Session-Id(44).
Framed-IP-Address(), the Accounting-Session-Id(44).
Other attributes could be used to uniquely identify a prepaid data Other attributes could also be used to uniquely identify a prepaid
session. data session.
3.5.1 3.4.1. Unsolicited Session Termination Operation
Unsolicited Session Termination Operation
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 order to terminate a session. This capability is described in detail
detail in [RFC3576]. The PPS sends a Disconnect Message that MUST in [RFC3576]. The PPS sends a Disconnect Message that MUST contain
contain identifiers that uniquely identify the data session and the identifiers that uniquely identify the data session and the SAD
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). with a Disconnect-NAK packet (otherwise). Upon successful
termination of a session the SAD MUST return any unused quota to the
Upon successful termination of a session the SAD MUST return any PPS by issuing an Authorize Only Access-Request containing the PPAQ
unused quota to the PPS by issuing an Authorize Only Access-Request which contains any unused Quota and the Update-Reason set to "Remote
containing the PPAQ which contains any unused Quota and the Update- Forced Disconnection".
Reason set to ôRemote Forced Disconnectö.
3.5.2 3.4.2. Unsolicited Change of Authorization Operation
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. add or to remove quota that is allocated to the service. If the
Change of Authorization contains a PPAQ then that PPAQ overrides a
If the Change of Authorization contains a PPAQ then that PPAQ previously received PPAQ. The PPS MUST NOT change the units used in
overrides a previously received PPAQ. The PPS MUST NOT change the the PPAQ.
units used in the PPAQ.
If the newly received PPAQ reduces the amount of allocated quota If the newly received PPAQ reduces the amount of allocated quota
beyond what is already used then the SAD accepts the new PPAQ and beyond what is already used then the SAD accepts the new PPAQ and act
act as it normally would when the quota is used up. For example, if as it normally would when the quota is used up. For example, if the
the threshold is reached then is request a quota update. threshold is reached then is request a quota update .
3.6 3.5. Termination Operation
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Æs balances 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 the case where the user logged off, or the SAD receives a In case the user logged off, or the SAD receives a Disconnect
Disconnect Message, the SAD sends an Authorize-Only Access-Request Message, the SAD sends an Authorize-Only Access-Request message with
message with a PPAQ(TBD) and Update-Reason attribute set to either a PPAQ and Update-Reason attribute set to either "Client Service
ôClient Service terminationö or ôRemote Forced disconnectö. This Termination" or "Remote Forced Disconnect". This message indicates
message indicates the already consumed quota. the amount of consumed quota.
In the case where the currently allocated quota is exhausted, if the In case the currently allocated quota is exhausted, if the PPAQ
PPAQ(TBD) contained Termination-Action field, the SAD follows the contained the Termination-Action field, the SAD follows the specified
specified action (which would be to immediately terminate the action (which would be to immediately terminate the service, request
service), requests more quota, or redirects/filters the service. more quota, or redirect/filter the service).
3.7 3.6. Mobile IP Operations
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. 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
As the subscriber device associates with the new SAD (AP or PDSN PPC capability), the SAD sends a RADIUS Access-Request and the
that supports PPC capability), the SAD sends a RADIUS Access-Request subscriber is re-authenticated and reauthorized. The SAD MUST
and the subscriber is re-authenticated and reauthorized. The SAD include the PPAC(TBD) attribute in the RADIUS Access-Request. In
MUST include the PPAC(TBD) attribute in the RADIUS Access-Request. this manner, the procedure follows the Authentication and
In this manner the procedure follows the Authentication and
Authorization procedure described earlier. Authorization procedure described earlier.
If the HA was acting as the SAD before handoff, the userÆs prepaid If the HA was acting as the SAD before handoff, the prepaid session
session does not undergo any change after the handoff because the does not undergo any change after the handoff because the Mobile IP
Mobile IP session is anchored at the HA and the userÆs Home IP session is anchored at the HA and the user's Home IP address does not
address remains the same. 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 IP address will change (Care of Address). is likely that the user's (care-of) IP address will change. The
The prepaid session will be affected by this. In this scenario the prepaid session will be affected by this. In this scenario the SAD
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 prepaid system that is serving this network and MUST reach the PPS that is serving this session. The PPS
session. The prepaid system correlates the new authorization correlates the new authorization request with the existing active
request with the existing active session and assigns a quota to the session and assigns a quota to the new request. Any outstanding
new request. Any outstanding quota at the old SAD MUST be returned quota at the old SAD MUST be returned to the PPS if the Mobile-IP
to the prepaid system if the Mobile-IP nodes (HA and FA) support nodes (HA and FA) support registration revocation (Mobile IPv4 only).
registration revocation (Mobile IPv4 only). Specifically, the quota Specifically, the quota SHOULD be returned when the SAD sends the
SHOULD be returned when the SAD sends the Authorize Only Access- Authorize Only Access-Request with PPAQ(TBD) Update-Reason set to
Request with PPAQ(TBD) Update-Reason set to either ôRemote Forced either "Remote Forced Disconnect" or "Client Service Termination".
disconnectö or ôClient Service terminationö. In order to trigger In order to trigger the sending of this last Authorize Only Access-
the sending of this last Authorize Only Access-Request, the prepaid Request, the PPS may issue a Disconnect Message [3576] to the SAD.
system 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 can the prepaid data service continue. This can be done capabilities can the prepaid data service continue. This can be done
by requesting the Home Agent (assuming that has such capabilities) by requesting the Home Agent (assuming it has such capabilities) to
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 a later version of this document. scenario will be discussed in detail in a later version of this
document.
3.8 3.7. Operation Considerations for Multiple Services
Operation considerations for Multiple prepaid services
This section describes the support for multiple prepaid services on This section describes the support for multiple prepaid services on a
a single SAD. Message flows illustrating the various interactions single SAD. Message flows illustrating the various interactions are
are presented at the end of this document. 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. the "Multi-Services Supported" bit in the PPAC. When working with
multi-services, we need to differentiate between the services. A
When working with multi-services, we need to differentiate between Service-Id attribute is used in the PPAQ(TBD) in order to uniquely
the services. A Service-Id attribute is used in the PPAQ(TBD) to differentiate between the services. The exact definition of the
uniquely differentiate between the services. The exact definition Service-Id attribute is outside the scope of this document.
of the Service-Id attribute is outside the scope of this document.
A PPAQ that contains a Service-Id is associated with that Service. A PPAQ that contains a Service-Id is associated with that Service. A
A PPAQ that contains a Rating-Group-Id is associated with that PPAQ that contains a Rating-Group-Id is associated with that Rating-
Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a Group. A PPAQ MUST not contain both a Rating-Group-Id and a
Service-Id. A PPAQ that contains neither a Rating-Group-Id or a Service-Id. A PPAQ that contains neither a Rating-Group-Id or a
Service-Id applies to the ôAccess Serviceö. Service-Id applies to the Access Service.
3.8.1 3.7.1. Initial Quota Request
Initial Quota Request
When operations with multi-services is desired, the SAD requests the When operations with multi-services is desired, the SAD requests the
initial quota for the Service by sending a PPAQ containing the initial quota for the Service by sending a PPAQ containing the
Service-Id for that Service in an Authorize-Only Access-Request Service-Id for that Service in an Authorize-Only Access-Request
packet. Similarly, if the SAD supports Rating-Groups then it may packet. Similarly, if the SAD supports Rating-Groups then it may
request a quota for the Rating-Group by sending a PPAQ containing request a quota for the Rating-Group by sending a PPAQ containing the
the Rating-Group-Id. In both cases the Update-Reason is set to Rating-Group-Id. In both cases the Update-Reason is set to "Initial-
ôInitial-Requestö. Request".
The Authorize-Only Access-Request message may contain more than one The Authorize-Only Access-Request message may contain more than one
PPAQ. The Authorize-Only Access-Request MUST includes one or more PPAQ. The Authorize-Only Access-Request MUST include one or more
attributes that serve to identify the session so that it can be attributes that serve to identify the session so that it can be
linked to the original authentication. Which Session Identifiers linked to the original authentication. Which Session Identifiers are
are included is up to specific deployments. The Authorize-Only included is up to specific deployments. The Authorize-Only message
message must contain the Message-Authenticator(80) attribute for must contain the Message-Authenticator(80) attribute for integrity
integrity protection of the Authorize-Only Access-Request message. protection of the Authorize-Only Access-Request message.
Upon receiving an Authorize-Only Access-Accept message containing Upon receiving an Authorize-Only Access-Accept message containing one
one or more PPAQs, the prepaid system allocates resources to each or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ
PPAQ. Each PPAQ is assigned a unique QID that MUST appear in is assigned a unique QID that MUST appear in subsequent PPAQ updates
subsequent PPAQ updates for that service or rating-group. for that service or rating-group. Additionally, the PPAQ MUST
Additionally, the PPAQ MUST contain the Service-ID or Group-ID, contain the Service-ID or Group-ID, unless the PPAQ is the generic
unless the PPAQ is a generic ôAccess Serviceö. "Access Service".
3.8.2 3.7.2. Quota Update
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). To replenish the quota the PPC reached or no more quota remains). In order to replenish the quota,
sends an Authorize-Only Access-Request message containing one or the PPC sends an Authorize-Only Access-Request message containing one
more PPAQs. Each PPAQ MUST contain the appropriate QID, Service-ID or more PPAQs. Each PPAQ MUST contain the appropriate QID,
or Group-ID (or neither the Service-ID or Group-Id if the quota Service-ID or Group-ID (or neither the Service-ID or Group-Id if the
replenishment is for the ôAccess Serviceö). The Update-Reason filed quota replenishment is for the "Access Service"). The Update-Reason
indicates either ôThreshold reachedö(3), or ôQuota reachedö(4). The filed indicates either "Threshold reached"(3), or "Quota reached"(4).
Authorize-Only message must contain session identifiers. The Authorize-Only message must contain session identifiers.
Upon receiving an Authorize-Only Access-Request packet with one or Upon receiving an Authorize-Only Access-Request packet with one or
more PPAQs the PPS responds with a new PPAQ for that service. The more PPAQs the PPS responds with a new PPAQ for that service. The
PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new
Quota. If the PPS does not grant additional quota to the service it Quota. If the PPS does not grant additional quota to the service it
MUST include the Termination-Action subfield in the PPAQ that will MUST include the Termination-Action subfield in the PPAQ that will
instruct the SAD what to do with the service. instruct the SAD what to do with the service.
3.8.3 3.7.3. Termination
Termination
When the allotted quota for a service is exhausted the SAD shall act When the allotted quota for a service is exhausted, the SAD shall act
in accordance to the Termination-Action field set in the Quota. If in accordance to the Termination-Action field set in the Quota. If
the Termination-Action field is absent then the service MUST be the Termination-Action field is absent then the service MUST be
terminated. 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,
If the service is to be terminated then the SAD shall send a PPAQ and the Update-Reason set to "Client Service Termination".
with the appropriate QID, the Service-Id, the used quota, and
Update-Reason set to ôClient Service Terminationö.
If the ôAccess Serviceö has terminated, then all other services must If the &#65533;Access Service&#65533; has terminated, then all other
be terminated as well. In this case the SAD MUST report on all services must be terminated as well. In this case the SAD MUST
issued quotas for the various services. The Update-Reason field report on all issued quotas for the various services. The Update-
should be set to ôAccess Service Terminatedö. Reason field should be set to "Access Service Terminated".
3.8.4 3.7.4. Dynamic Operations
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 Authorize Only SAD MUST report all unused quotas by sending an Authorize Only Access
Access Request message containing a PPAQ for each active service. Request message containing a PPAQ for each active service. The
The Update-Reason shall indicate that the reason for the update. Update-Reason shall indicate that the reason for the update.
3.8.5 3.7.5. Support for Resource Pools
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). PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the
threshold field.
When Resource Pools are used, the PPAQ must not use the threshold
field.
3.8.6 3.7.6. One-time Charging
One-Time-Charging
To initiate a One-Time charge the PPC includes the PPAQ attribute in To initiate a One-Time charge the PPC includes the PPAQ attribute in
an Access-Request packet. The Access Request packet MUST include a an Access-Request packet. The Access Request packet MUST include a
Message-Authenticator(80) and an Event-Timestamp(55) attribute. Message-Authenticator(80) and an Event-Timestamp(55) attribute. The
Service Id field of the PPAQ identifies the prepaid service. The
The Service Id field of the PPAQ identifies the prepaid service. amount to be charged is specified using the Resource Quota and
The amount to be charged is specified using the Resource Quota and Resource Quota overflow subtypes. If the value specified is negative
Resource Quota overflow subtypes. If the value specified is then the resources are credited to the user account.
negative then the resources are credited to the userÆs account.
The QID field MUST be set to a unique value and is used by the PPS
to detect duplicates. The Update Reason field MUST be set to One-
Time Charging.
Upon receiving a One-Time charge PPAQ, the RADIUS server The QID field MUST be set to a unique value and is used by the PPS to
detect duplicates. The Update Reason field MUST be set to One-Time
Charging. Upon receiving a One-Time charge PPAQ, the RADIUS server
authenticates the user and, if successful, passes the PPAQ to the authenticates the user and, if successful, passes the PPAQ to the
PPS. The PPS locates the account and debits or credits it PPS. The PPS locates the account and debits or credits it
accordingly. The PPS MUST respond to the PPS with an Access-Accept accordingly. The PPS MUST respond to the PPS with an Access-Accept
message if successful, or an Access-Reject message otherwise. message if successful, or an Access-Reject message otherwise.
The RADIUS server shall respond to the SAD with an Access Accept The RADIUS server shall respond to the SAD with an Access Accept
message. Since this is a one-time charge the SAD must not allow the message. Since this is a one-time charge the SAD must not allow the
session to continue. Therefore, the RADIUS server should include in session to continue. Therefore, the RADIUS server should include in
the Access-Accept a Session-Timeout set to 0. Upon receiving an the Access-Accept a Session-Timeout set to 0. Upon receiving an
Access-Accept response the SAD shall generate an Accounting Stop Access-Accept response the SAD shall generate an Accounting Stop
message. message.
A PPAQ used for One-Time charging may appear in an Authorize-Only A PPAQ used for One-Time charging may appear in an Authorize-Only
Access Request. This is the case when the session already exists. Access Request. This is the case when the session already exists.
The PPS responds with an Access-Accept to indicate that the userÆs The PPS responds with an Access-Accept to indicate that the user
account has been debited or an Access-Reject otherwise. account has been debited or an Access-Reject otherwise.
3.8.7 3.7.7. Error Handling
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-
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 that contains a Pool-Id without a Pool- If the PPC receives a PPAQ that contains a Pool-Id without a Pool-
Multiplier or a Pool-Multiplier without a Pool-Id it must ignore Multiplier or a Pool-Multiplier without a Pool-Id it must ignore that
that PPAQ. PPAQ.
3.9
Accounting Considerations
Although typically generated, accounting messages are not required
to deliver a prepaid data service. When generated, accounting
messages are used for auditing purposes and for billing.
Accounting messages associated with prepaid data sessions should
include the PPAQ(TBD) attribute.
3.10 3.7.8. Accounting Considerations
SAD Operation
To be completed Although typically generated, accounting messages are not required to
deliver a prepaid data service. When generated, accounting messages
are used for auditing purposes and for billing. Accounting messages
associated with prepaid data sessions should include the PPAQ(TBD)
attribute.
3.11 3.7.9. Interoperability with Diameter Credit Control Application
Interoperability with Diameter Credit Control Application
The RADIUS prepaid extensions need to interoperate with the Diameter The RADIUS prepaid extensions need to interoperate with the Diameter
protocol. Two possibilities exist: The AAA infrastructure is protocol. Two interoperability scenarios exist, as follows. Either
Diameter based and the SAD are RADIUS based, or the SAD is Diameter the AAA infrastructure is Diameter based and the SAD are RADIUS
based and the AAA infrastructure is RADIUS based. based, or the SAD is Diameter based and the AAA infrastructure is
RADIUS based.
The Diameter Credit Control Application [DIAMETERCC] describes how The Diameter Credit Control Application [DIAMETERCC] describes how to
to implement a prepaid accounting system using an Diameter based implement a prepaid accounting system using a Diameter based
infrastructure. infrastructure.
<This section to be completed.> 4. Attributes
4.
Attributes
This draft is using the RADIUS [RFC2865] namespace. This section specifies the attributes that implement the RADIUS
extensions for prepaid. The namespace for these attributes is the
one specified in the RADIUS base protocol [RFC2865].
4.1 4.1. PPAC Attribute
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 present describe the prepaid capabilities of the NAS. The PPAC is also
in an Access-Accept message by the PPS to indicate the type of present in an Access-Accept message by the PPS in order to indicate
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
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 | SUBtype 1 | LENGTH | | TYPE | LENGTH | SUBtype 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) | | AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : value of PPAC TYPE : value of PPAC
LENGTH: 8 LENGTH: 8
VALUE : String VALUE : String
The value MUST be encoded as follows: The value MUST be encoded as follows:
Subtype (=1) : Subtype for AvailableInClient attribute Subtype (=1) : Subtype for AvailableInClient attribute
Length : Length of AvailableInClient attribute Length : Length of AvailableInClient attribute
(= 6 octets) (= 6 octets)
AvailableInClient (AiC): AvailableInClient (AiC):
The optional AvailableInClient Subtype, generated by the PPC, The optional AvailableInClient Subtype, generated by the PPC,
indicates the metering capabilities of the NAS and shall be bitmap indicates the metering capabilities of the NAS and shall be bitmap
encoded. The possible values are: encoded. The possible values are as follows.
0x00000001 Volume metering supported. 0x00000001 Volume metering supported.
0x00000002 Duration metering supported. 0x00000002 Duration metering supported.
0x00000004 Resource metering supported. 0x00000004 Resource metering supported.
0x00000008 Pools supported 0x00000008 Pools supported
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
4.2 Figure 10: PPAC Attribute
Session Termination Capability
The value shall be bitmap encoded rather than a raw integer. This 4.2. Session Termination Attribute
The value shall be bitmap encoded rather than a raw integer. This
attribute shall be included RADIUS Access-Request message to the attribute shall be included RADIUS Access-Request message to the
RADIUS server and indicates whether or not the NAS supports Dynamic RADIUS server and indicates whether or 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.
4.3 Figure 11: Session Termination Attribute
PPAQ Attribute
One or more PPAQ(TBD) attributes are sent in an Access Request, 4.3. PPAQ Attribute
Authorize Only Access-Request and Access-Accept messages. In an
Access Request message, the PPAQ attribute is used to facilitate One or more PPAQ attributes are sent in an Access Request, Authorize
One-Time charging transactions. In Authorize Only Access-Request Only Access-Request and Access-Accept message. In an Access Request
messages it is used for One-Time charging, report usage and the message, the PPAQ attribute is used to facilitate One-Time charging
request for further quota. It is also used to request prepaid quota transactions. In Authorize Only Access-Request messages it is used
for a new service instance. In an Access-Accept message it is used for One-Time charging, report usage and the request for further
to allocate the (initial and subsequent) quotas. quota. It is also used in order to request prepaid quota for a new
service instance. In an Access-Accept message it is used in order to
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 Rating-Group-Id, or the "Access Service" (as indicated by the absence
absence of a Service-Id and a Rating-Group-Id). of a Service-Id and a Rating-Group-Id).
The attribute consists of a number of subtypes. Unused subtypes are The attribute has type TBD (one octet), a variable length (greater
omitted from the message. than 8, encoded into one octet), and consists of a variable number of
subtypes. Unused subtypes are omitted from the message. In the
following subsections the various subtypes of the PPAQ attribute are
specified.
0 1 2 3 4.3.1. Quota Identifier AVP
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 | SUBtype 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIdentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 2 | LENGTH | Volume Quota |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Volume Quota | SUBtype 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VolumeQuotaOverflow (VQO) | SUBtype 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VolumeThreshold (VT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 5 | LENGTH | VolumeThresholdOverflow (VTO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 6 | LENGTH | DurationQuota (DQ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationQuota (DQ) | SUBtype 7 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationThreshold (DT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 8 | LENGTH | Update-Reason attribute (UR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 9 | LENGTH | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type of the QuotaIDentifier attribute is TBD and its length is 6
| SUBtype 10 | LENGTH | Service-Id | octets. This AVP is generated by the PPS together with the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ allocation of new quota. The on-line quota update RADIUS Access-
| SUBtype 11 | LENGTH | Rating-Group-Id | Request message that is sent from the SAD to the PPS shall include a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ previously received QuotaIdentifier.
| | SUBtype 12 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Termination-Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 13 | LENGTH | Pool-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | SUBtype 14 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pool-Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 15 | LENGTH | Resource-Quota |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | SUBtype 16 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource-Quota-Overflow |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 18 | LENGTH | Resource-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PPAQ 4.3.2. VolumeQuota AVP
Length: variable, greater than 8
String: The String value MUST be encoded as follows: The type of the VolumeQuota attribute is TBD and its length is 12 or
18 octets. This AVP is only present if volume-based charging is
used. In a RADIUS Access-Accept message (PPS to SAD direction), it
indicates the volume (in octets) allocated for the session by the
PPS. In an RADIUS Authorize Only Access-Request message (SAD to PPS
direction), it indicates the total used volume (in octets) for both
inbound and outbound traffic. The attribute consists of a Value-
Digits AVP and optionally an Exponent AVP (as indicated in the length
field). The Exponent AVP, if present, MUST NOT encode a negative
number or zero.
Subtype (=1): Subtype for QuotaIDentifier attribute 4.3.3. VolumeThreshold AVP
Length : Length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID): The type of the VolumeThreshold attribute is TBD and its length is 12
or 18 octets. This AVP shall optionally be present if VolumeQuota is
present in a RADIUS Access-Accept message (PPS to SAD direction). It
is generated by the PPS and indicates the volume (in octets) that
shall be consumed before a new quota should be requested. This
threshold should not be larger than the VolumeQuota. The attribute
consists of a Value-Digits AVP and optionally an Exponent AVP (as
indicated by the length field). The Exponent AVP, if present, MUST
NOT encode a negative number or zero.
The QuotaIDentifier subtype is generated by the PPS together with 4.3.4. DurationQuota AVP
the allocation of a Volume or Duration Quota. The on-line quota
update RADIUS Access-Request message sent from the SAD to the PPS
shall include a previously received QuotaIDentifier.
Subtype (=2): Subtype for VolumeQuota attribute The type of the DurationQuota attribute is TBD and its length is 6
Length : length of VolumeQuota attribute (= 6 octets) octets. This optional AVP is only present if duration-based charging
is used. In RADIUS Access-Accept message (PPS to SAD direction), it
indicates the duration (in seconds) allocated for the session by the
PPS. It is encoded as an 32 bit unsigned value, in network byte
order. In an on-line RADIUS Access-Accept message (PPC to PPS
direction), it indicates the total duration (in seconds) since the
start of the accounting session related to the QuotaID of the PPAQ
AVP in which it occurs.
VolumeQuota (VQ): 4.3.5. DurationThreshold AVP
The optional VolumeQuota subtype is only present if Volume Based The type of the DurationThreshold attribute is TBD and its length is
charging is used. In a RADIUS Access-Accept message (PPS to SAD 6 octets. This AVP shall optionally be present if DurationQuota is
direction), it indicates the Volume (in octets) allocated for the present in a RADIUS Access-Accept message (PPS to PPC direction). It
session by the PPS. In RADIUS Authorize Only Access-Request represents the duration (in seconds) after which new quota should be
message (SAD to PPS direction), it indicates the total used requested. This threshold should not be larger than the
volume (in octets) for both forward and reverse traffic. DurationQuota. It is encoded as a 32 bit unsigned value, in network
byte order.
Subtype (=3): Subtype for VolumeQuotaOverflow 4.3.6. ResourceQuota AVP
Length : length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO): The type of the ResourceQuota attribute is TBD and its length is 12
or 18 octets. This optional AVP is only present if resource-based or
one-time charging is used. In the RADIUS Access-Accept message (PPS
to SAD direction) it indicates the resources allocated for the
session by the PPS. In RADIUS Authorize Only Access-Request message
(SAD to PPS direction), it indicates the resources used in total,
including both incoming and outgoing chargeable traffic. In one-time
charging scenarios, the subtype represents the number of units to
charge or credit the user. The attribute consists of a Value-Digits
AVP and optionally an Exponent AVP (as indicated by the length
field).
The optional VolumeQuotaOverflow subtype is used to indicate how 4.3.7. ResourceThreshold AVP
many times the VolumeQuota counter has wrapped around 2^32 over
the course of the service being provided.
Subtype (=4): Subtype for VolumeThreshold attribute The type of the ResourceThreshold AVP is TBD and its length is 12 or
Length : length of VolumeThreshold attribute (= 6 octets) 18 octets. The semantics of this AVP follow those of the
VolumeThreshold and DurationThreshold AVPs. It consists of a Value-
Digits AVP and optionally an Exponent AVP.
VolumeThreshold (VT): 4.3.8. Value-Digits AVP
The VolumeThreshold Subtype shall always be present if The type of the Value-Digits AVP is TBD and its length is 10 octets.
VolumeQuota is present in a RADIUS Access-Accept message (PPS to This AVP encodes the most significant digits of a number, encoded as
SAD direction). It is generated by the PPS and indicates the a 64 unsigned integer, in network byte order. If decimal values are
volume (in octets) that shall be consumed before a new quota needed to present the number, the scaling MUST be indicated with a
should be requested. This threshold should not be larger than the related Exponent AVP. For example, the decimal number 0.05 is
VolumeQuota. encoded by a Value-Digits AVP set to 5, and a scaling that is
indicated with the Exponent AVP set to -2.
Subtype (=5): Subtype for VolumeThresholdOverflow 4.3.9. Exponent AVP
Length : Length of VolumeThresholdOverflow attribute
(= 4 octets)
VolumeThresholdOverflow (VTO): The type of the Exponent AVP is TBD and its length is 6 octets. This
AVP contains the exponent value that is to be applied to the
accompanying Value-Digit AVP. It contains a 32 bit signed value, in
network byte order.
The optional VolumeThresholdOverflow subtype is used to indicate 4.3.10. Update-Reason AVP
how many times the VolumeThreshold counter has wrapped around
2^32 over the course of the service being provided.
Subtype (=6): Subtype for DurationQuota attribute The type of the Update-Reason AVP is TBD and its length is 4 octets.
Length : length of DurationQuota attribute (= 6 octets) This AVP shall be present in the on-line RADIUS Access-Request
message (PPC to PPS direction). It indicates the reason for
initiating the on-line quota update operation. Update reasons 6, 7,
8 and 9 indicate that the associated resources are released at the
client side, and that therefore the PPS shall not allocate a new
quota in the RADIUS Access Accept message.
DurationQuota (DQ): 1. Pre-initialization
The optional DurationQuota Subtype is only present if Duration 2. Initial Request
Based charging is used. In RADIUS Access-Accept message (PPS to
SAD direction), it indicates the Duration (in seconds) allocated
for the session by the PPS. In on-line RADIUS Access-Accept
message (PPC to PPS direction), it indicates the total Duration
in seconds) since the start of the accounting session related to
the QuotaID.
Subtype (=7): Subtype for DurationThreshold attribute 3. Threshold Reached
Length : length of DurationThreshold attribute (= 6 octets)
DurationThreshold (DT): 4. Quota Reached
The DurationThreshold subtype shall always be present if 5. TITSU Approaching
DurationQuota is present in a RADIUS Access-Accept message (PPS
to SAD direction). It represents the duration (in seconds) after
which new quota should be requested. This threshold should not be
larger than the DurationQuota.
Subtype (=8): Subtype for Update-Reason attribute 6. Remote Forced Disconnect
Length : length of Update-Reason attribute (= 4 octets)
Update-Reason attribute (UR): 7. Client Service Termination
The Update-Reason subtype shall be present in the on-line RADIUS 8. "Access Service" Terminated
Access-Request message (SAD to PPS direction). It indicates the
reason for initiating the on-line quota update operation. Update
reasons 4, 5, 6, 7 and 8 indicate that the associated resources
are released at the client side, and therefore the PPS shall not
allocate a new quota in the RADIUS Access_Accept message.
1. Pre-initialization 9. Service not established
2. Initial Request
3. Threshold Reached
4. Quota Reached
5. Remote Forced Disconnect
6. Client Service Termination
7. ôAccess Serviceö Terminated
8. Service not established
9. One-Time Charging
Subtype (=9) : Subtype for PrePaidServer attribute 10. One-Time Charging
Length : Length of PrePaidServer
(IPv4 = 6 octets, IPv6= 18 octets
PrePaidServer: 4.3.11. PrepaidServer AVP
The optional, multi-value PrePaidServer attribute indicates the The type of the PrepaidServer AVP is TBD and its length is 6 or 18
address of the serving prepaid system. If present, the Home octets, for IPv4 and IPv6 addresses respectively. This optional AVP
RADIUS server uses this address to route the message to the indicates the address of the serving PPS. If present, the Home
serving PPS. The attribute may be sent by the Home RADIUS server. RADIUS server uses this address to route the message to the serving
PPS. The attribute may be sent by the Home RADIUS server. Multiple
instances of this subtype MAY be present in a single PPAQ AVP.
If present in the incoming RADIUS Access-Accept message, the PDSN If present in the incoming RADIUS Access-Accept message, the SAD
shall send this attribute back without modifying it in the shall send this attribute back without modifying it in the subsequent
subsequent RADIUS Access-Request message, except for the first RADIUS Access-Request message, except for the first one. If multiple
one. If multiple values are present, the PDSN shall not change values are present, the SAD shall not change their order.
their order.
Subtype (=10) : Subtype for Service ID 4.3.12. Service-ID AVP
Length : Length of Service ID
Service-Id: The type of the Service-ID AVP is TBD and its length is undefined.
This AVP encodes an opaque string that uniquely describes the service
instance to which prepaid metering should be applied. A Service-Id
could be an IP 5-tuple (source address, source port, destination
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
not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to
the Access Service.
Opaque string that uniquely describes a service instance to which 4.3.13. Rating-Group-ID AVP
prepaid metering should be applied. A Service-Id could be an IP
5-tuple (source address, source port, destination address,
destination port, protocol). If Service-ID is present in the PPAQ
the PPAQ refers to that service. If a PPAQ does not contain a
Service-Id then the PPAQ refers to the Access Service.
Subtype (=11) : Subtype for Rating-Group-Id The type of the Rating-Group-ID is TBD and its length is 6 octets.
Length : 6
Rating-Group-Id This AVP indicates that this PPAQ is associated with resources
allocated to a Rating Group with the corresponding ID. This AVP is
encoded as a 32 bit unsigned value, in network byte order. A PPAQ
MUST NOT contain more than one Rating-Group-ID.
Identifies that this PPAQ is associated with resources allocated 4.3.14. Termination-Action AVP
to a Rating Group with the corresponding ID.
Subtype (=12) : Subtype for Termination-Action The type of the Termination-Action AVP is TBD and its length is 3
Length : 6 octets. This AVP contains an enumeration of the action to take when
the PPS does not grant additional quota. Valid actions are as
follows. (Note that the value 0 is reserved.)
This field is an enumeration of the action to take when the PPS does 1. Terminate
not grant additional quota. Valid actions are as follows:
0 Reserved 2. Request More Quota
1 Terminate
2 Request More Quota
3 Redirect/Filter
Subtype (=13) : Pool-Id 3. Redirect/Filter
Length : 6
Identifies the Pool that this quota is to be associated with. 4.3.15. Pool-ID AVP
Subtype (=14) : Pool-Multiplier The type of the Pool-ID) AVP is TBD and its length is 6 octets. This
Length : 6 AVP identifies the resource pool that the quota included in this PPAQ
is associated with. It is encoded as a 32 bit unsigned value, in
network byte order.
The pool-multiplier determines the weight that resources are 4.3.16. Pool-Multiplier AVP
inserted into the pool and the rate at which resources are taken out
of the pool by this service or Rating-Group.
Subtype (=15) : Subtype for Resource-Quota The type of the Pool-Multiplier AVP is TBD and its length is 12 or 18
Length : 6 octets. The pool-multiplier determines the weight that resources are
inserted into the pool that is identified by the accompanying Pool-ID
AVP, and the rate at which resources are taken out of the pool by the
relevant Service or Rating-Group. The attribute consists of a Value-
Digits AVP and optionally an Exponent AVP (as indicated by the length
field).
The optional Resource-Quota subtype is only present if Resource 4.3.17. Requested-Action AVP
Based or one-time charging is used. In the RADIUS Access-Accept
message (PPS to SAD direction) it indicates the Resources
allocated for the session by the PPS. In RADIUS Authorize Only
Access-Request message (SAD to PPS direction), it indicates the
resources used in total, including both incoming and outgoing
chargeable traffic. In one-time charging scenarios, the subtype
represents the number of units to charge or credit the user.
Subtype (=16) : Subtype for Resource Quota Overflow The type of the Requested-Action AVP is TBD and its length is 3
Length : 6 octets. This AVP can only be present in messages sent from the PPC
to the PPS. It indicates that the user or the PPC desires the PPS to
perform the indicated action and to return the result. The PPAQ in
which a Requested-Action AVP occurs MUST NOT contain a QID, and MUST
contain a Service-Identifier that, possibly in combination with other
AVPS, can be used by the PPS to uniquely identify the service for
which the indicated action is requested. The following actions may
be requested.
Subtype (=18) : Subtype for ResourceThreshold 1. Balance Check
Length : 6
NOTES: 2. Price Enquiry
Volume-Quota, Time-Quota, or Resource-Quota MUST appear in the 4.3.18. Check-Balance-Result AVP
attribute. If Volume Quota appears, Volume Threshold may also
appear.
A PPAQ MUST NOT contain both a Service-Id and a Rating-Group-Id. The type of the Check-Balance-Result AVP is TBD and its length is 3
octets. This AVP can only be present in messages sent from the PPS
to the PPC. It indicates the balance check decision of the PPS about
a previously received Balance Check Request (as indicated in a
Requested-Action AVP). Possible values are 0 for "success" and 1 for
"failure" and mean that sufficient funds are available (resp. are not
available) in the user's prepaid account. The PPAQ in which a Check-
Balance-Result occurs MUST NOT include a QID, because no quota is
reserved by the PPS.
A PPAQ that does not contain a Service-ID or a Rating-Group-Id 4.3.19. Cost-Information AVP
applies to the ôAccess Serviceö.
When the PPAQ contains a Pool-Id it MUST also contain the Pool- The type of the Cost-Information AVP is TBD and its length is
Multiplier. variable. This AVP is used in order to return the cost information
of a service, which the PPC can transfer transparently to the end
user. This AVP is sent from the PPS to the PPC as a response to a
"Price Enquiry", as indicated by the Requested-Action AVP. This AVP
consists of four further AVPs, as follows.
4.4 1. Value-Digits ASP: this encodes the most significant digits of the
Prepaid Tariff Switching (PTS) monetery value that represents the cost in question.
This specification defines the PTS attribute to allow for 2. Exponent AVP: this encodes the exponent that applies to the
changeovers from one rate to another during service provision. Value-Digits AVP.
Support for tariff switching is OPTIONAL for both PPC and PPS. PPCs 3. Currency-Code AVP: the type of this AVP is TBD, and its length is
use the flag "Tariff Switching supported" of the AvailableInClient 4 octets. It encodes the currency code, as defined in the ISO
subtype of the PPAC attribute to indicate support for tariff 4217 standard.
switching. PPSs employ the PTS attribute to announce their support
for tariff switching. Details of this will be specified after the
format of the PTS attribute has been defined.
If a RADIUS message contains a PTS attribute, it MUST also contain 4. Cost-Unit AVP: the type of this AVP is TBD and its length is
at least one PPAQ attribute. If a RADIUS Access-Request message variable. It carries a UTF8String encoded human readable string
contains a PTS attribute or a "Tariff Switching supported" flag, it that can be displayed to the end user. It specifies the
MUST also contain an Event-Timestamp RADIUS attribute (see applicable unit to the Cost-Information when the service cost is
[RFC2869]). a cost per unit (e.g., cost of the service is $1 per minute).
The Cost-Unit can be minutes, hours, days, kilobytes, megabytes,
etc.
0 1 2 3 Example: the cost of 7.75 Malawi kwacha per hour would be encoded as
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 follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cost-Unit = "hour".
| TYPE | LENGTH | SUBtype 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIDentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 2 | LENGTH | VolumeUsedAfter- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitch (VUATS) | SUBtype 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VUATSOverflow (VUATSO) | SUBtype 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitchInterval (TSI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 5 | LENGTH | TimeIntervalAfter- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitchUpdate (TITSU) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PTS The PPAQ in which a Cost-Information occurs MUST NOT include a QID,
Length: variable, at least 8 because no quota is actually reserved by the PPS.
Subtype (=1): QuotaIDentifier (QID)
Length : Length of QuotaIDentifier Subtype (= 6 octets)
The QID subtype MUST be present in each PTS attribute. In an NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear
online RADIUS Access-Request message sent from the PPC to the in the PPAQ attribute. A PPAQ MUST NOT contain more than one
PPS, its value MUST be a quota identifier received previously Service-Id, MUST NOT contain more than one Rating-Group-Id, and MUST
from the PPS and MUST be the same as a quota identifier of one of NOT contain both a Service-Id and a Rating-Group-Id. A PPAQ that
the PPAQ attributes included the same RADIUS message. does not contain a Service-ID or a Rating-Group-Id refers to the
"Access Service". A PPAQ MUST NOT contain more than one Pool-Id. A
PPAQ that contains a Pool-Id MUST also contain a Pool-Multiplier AVP.
A PPAQ attribute that is transported along with a PTS attribute 4.4. Prepaid Tariff Switching Attribute (PTS)
and has the same quota identifier value as the PTS attribute in
its own QID subfield shall be referred to as "accompanying PPAQ
attribute". If a PPS receives an Access-Request message from a
PPC, it associates a unique quota identifier to this request.
Thus, a quota identifier also identifies a particular service.
Subtype (=2): VolumeUsedAfterTariffSwitch (VUATS) This specification defines the PTS attribute which allows for
Length : Length of VolumeUsedAfterTariffSwitch Subtype changeovers from one rate to another during service provision.
(= 6 octets) Support for tariff switching is optional for both the PPC and the
PPS. PPCs use the flag "Tariff Switching supported" of the
AvailableInClient subtype of the PPAC attribute in order to indicate
support for tariff switching. PPSs employ the PTS attribute in order
to announce their support for tariff switching. Details of this will
be specified after the format of the PTS attribute has been defined.
The VolumeUsedAfterTariffSwitch subtype SHALL be used in online If a RADIUS message contains a PTS attribute, it MUST also contain at
RADIUS Access-Request messages (PPC to PPS direction). It least one PPAQ attribute. If a RADIUS Access-Request message
indicates the volume (in octets) used during a session after the contains a PTS attribute or a "Tariff Switching supported" flag, it
last tariff switch for the service specified via the QID subfield MUST also contain an Event-Timestamp RADIUS attribute (see [3]).
and the accompanying PPAQ attribute (see the remarks under
"Subtype 1: QID").
Subtype (=3): VUATSOverflow (VUATSO) The type of the PTS attribute is TBD and its lengh is variable. It
Length : Length of VUATSOverflow Subtype (= 4 octets) contains one or more subtypes, as follows. Every PTS AVP MUST
include a QuotaIdentifier AVP as specified in Section 4.3.1. In an
online RADIUS Access-Request message sent from the PPC to the PPS,
the QuotaIdentifier AVP must contain a quota identifier that was
previously received from the PPS and MUST be the same as a quota
identifier of one of the PPAQ attributes included the same RADIUS
message.
If an online RADIUS Access-Request message contains a VUATS A PPAQ attribute that is transported along with a PTS attribute and
subfield and if the VolumeUsedAfterTariffSwitch has wrapped has the same quota identifier value as the PTS attribute in its own
around 2^32 over the course of provisioning the service QID subfield shall be referred to as the "accompanying PPAQ
identified via the QID subfield, then the VUATSO subfield MUST be attribute". If a PPS receives an Access-Request message from a PPC,
present in the PTS attribute. In this case, it indicates how it associates a unique quota identifier to this request. Thus, a
many times the VolumeUsedAfterTariffSwitch has wrapped around quota identifier also identifies a particular service.
2^32. In all other cases, the VUATSO subfield MUST NOT be
present in the PTS attribute.
Subtype (=4): TariffSwitchInterval (TSI) The PTS AVP contains a number of other subtype AVPs which are
Length : Length of TSI Subtype (= 6 octets) specified in the following subsections.
The TSI subtype MUST be present in each PTS attribute that is 4.4.1. VolumeUsedAfterTariffSwitch AVP
part of a RADIUS Access-Accept message (PPS to PPC direction).
It indicates the interval (in seconds) between the value of
Event-Timestamp RADIUS attribute (see [RFC2869]) of the
corresponding RADIUS Access-Request message and the next tariff
switch condition.
Subtype (=5): TimeIntervalafterTariffSwitchUpdate (TITSU) The type of the VolumeUsedAfterTariffSwitch attribute is TBD and its
Length : Length of TITSU Subtype length is 12 or 18 octets. The VolumeUsedAfterTariffSwitch subtype
(= 6 octets) SHALL be used in online RADIUS Access-Request messages (PPC to PPS
direction). It indicates the volume (in octets) used during a
session after the last tariff switch for the service specified via
the QID subfield and the accompanying PPAQ attribute. The attribute
consists of a Value-Digits AVP and optionally an Exponent AVP (as
indicated in the length field).
The PPS MUST include the TITSU subtype if there is another tariff 4.4.2. TariffSwitchInterval AVP
switch period after this period. The TITSU attributes encodes
the number remaining seconds of current tariff period. If this
attribute is zero or omitted, it is assumes that the current
tariff period lasts until further notice. If TITSU is specified,
the PPC must send a quota update before the current period ends.
If a RADIUS message contains a PTS attribute, it MUST also contain The type of the TariffSwitchInterval is TBD and its length 6 octets.
at least one PPAQ attribute. The PTS is associated with the PPAQ by This AVP MUST be present in each PTS attribute that is part of a
the QID. If multiple services are supported and if the PPAQ is RADIUS Access-Accept message (PPS to PPC direction). It indicates
associated with a service as indicated by the Service-Id sub- the interval (in seconds) between the value of Event-Timestamp RADIUS
atrribute of the PPAQ, then the PTS refers to the tariff switch for attribute (see [3]) of the corresponding RADIUS Access-Request
that service. If the PPAQ does not have a Service-Id, then the PTS message and the next tariff switch condition.
refers to tariff switch for the Access-Service.
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP
The type of the TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is
TBD and its length is 6 octets. The PPS MUST include this AVP if
there is another tariff switch period after the period that ends as
indicated by the TSI attribute. The TITSU attribute encodes the
number seconds of the tariff period that begins immediately after the
period that ends as indicated by the TSI attribute. If the TITSU
attribute is zero or omitted, the PPC assumes that the tariff period
which ends as indicated by the TSI attribute lasts until further
notice. If TITSU is specified, the PPC MUST send 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
least one PPAQ attribute. The PTS is associated with the PPAQ by the
QID. If multiple services are supported and if the PPAQ is
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
does not have a Service-ID, then the PTS refers to tariff switch for
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
(Tariff switching supported) flag of the AvailableInClient subtype (Tariff switching supported) flag of the AvailableInClient subtype of
of the PPAC attribute that is contained in the Access-Request packet the PPAC attribute that is contained in the Access-Request packet
starting the session. starting the session.
4.5 5. Translation between RADIUS prepaid and Diameter Credit Control
Table of Attributes
TO BE COMPLETED. In scenarios where the service metering device uses the "RADIUS
prepaid" (RPP) protocol for accounting and prepaid charging while the
AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol,
a translation agent that enables the interoperation of both systems,
is desirable. This also applies vice versa, i.e. in scenarios where
the AAA infrastructure uses RADIUS and the service metering device
uses Diameter.
Request Accept Reject Challenge # Attribute The idea of such a translation agent would be to convert incoming RPP
(resp. DCC) messages into outgoing DCC (resp. RPP) messages. It
would be, in principle, desirable for the translation agent to be
stateless. That is, the agent should not be required to internally
maintain information about each ongoing RADIUS or Diameter session.
However, under the current specification of RPP and DCC, this appears
to be impossible due to a number of reasons. These include the
following.
Authorize_Only Request Accept Reject 1. The transport mechanism for DCC is TCP, which requires per-
session state to be maintained at both endpoints of the
communication. Note, however, that, in principle, each DCC
message could be sent over a dedicated TCP connection which is
torn down as soon as the message is sent. This, however, is
likely to be unacceptable in terms of efficiency.
5. 2. While RPP messages encode the cumulative amount of consumed/
Security Considerations requested resources, DCC messages carry the difference from the
previous message. This means that the translation agent has to
maintain the current amount of consumed/requested resources in
order to be able to calculate the correct amount to be put into
an outgoing message.
The extended RADIUS protocol described in this document is subject The translator maps each incoming RPP (resp. DCC) message into an
to a number of potential attacks, in a manner similar to the RADIUS outgoing DCC (resp. RPP) message, and possibly establishes or updates
without these extensions. It is recommended that IPsec be employed local state that is associated with the session. The translated
to protect against certain of the attacks. (i.e. outgoing) message is a function of the incoming message as well
as existing state that is associated with the current session.
If IPsec is not available, usage of the extensions described in this Translation occurs on an attribute-by-attribute basis. Certain
document improve the overall security of RADIUS. The various attributes are translated without consideration of local per-session
security enhancements are explained in the following sections. state. Other attributes, namely those that are bound to a particular
session, require such consideration. The translation agent has to
identify the session (and possibly subsession) an incoming message
belongs to in order to consult the appropriate local per-session
state.
5.1 Note that certain DCC attributes cannot be translated due to their
Authentication and Authorization semantics not being present in RPP, and vice versa. This results in
the messages, in which these attributes occur, not being delivered to
their intended destination. In such cases it is desirable to inform
the originator about the failure and terminate the session.
RADIUS is susceptible to replay attacks during the Authentication In each scenario (i.e. RPP client / DCC AAA infrastructure and DCC
and Authorization procedures. A successful replay of the initial client / RPP AAA infrastructure), the translator operates in two
Access-Request could result in an allocation of an initial quota. directions, namely RPP to DCC and vice versa. In the following
sections, the notation c->s means that the attribute in question may
occur only in the direction from the client to the server. The
notation s->c denotes the converse and the notation c<->s denotes
that the attribute may occur in messages that are directed in either
direction.
To thwart such an attack... 5.1. Session Identification
5.2 The translation agent has to keep per-session state in order to
Replenishing Procedure perform its task. A session may be identified based on the RPP
identifier or the DCC session identifier. That is, the translation
agent should always maintain a pair of (RPP, DCC) session identifiers
and maintain the per-session state in association with that pair.
This per-session state must be addressable by either of these two
identifiers. Moreover, an RPP session identifier must uniquely
correspond to a DCC identifier. (If this holds, the converse also
holds.) Each subsession identifier within an RPP session must also
uniquely correspond to a subsession identifier within its
corresponding DCC session. (If this holds the converse also holds.)
A successful replay attack of the Authorize Only Access-Request 5.2. Translation between RADIUS prepaid client and Diameter Credit
could deplete the subscribers prepaid account. Control AAA infrastructure
To be completed. This section describes the translator in the "RPP client / DCC AAA
infrastructure" case. In other words, in this section it is assumed
that the client "talks" RPP and the AAA inftrastructure "talks" DCC.
The translator is assumed to sit somewhere in the middle and to
mediate between client and server.
6. For each RPP AVP (i.e. AVP that is specified in the present
IANA Considerations document), the transformation into a semantically equivalent DCC 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 RPP AVP is addressed in a separate subsection.
Since in this scenario, the PPC is typically the initiator a session,
the focus is on the RPP AVPs.
5.2.1. PPAC (c<->s)
A DCC client is assumed to always support Volume metering, Duration
metering, Resource metering, Pools, Rating groups, and Tariff
Switching. Thus, if a PPAQ that indicates any of the above is sent
client->server, the translator does the following: It lets message go
through but remembers what exactly the client supports. If the
server later requests (servier -> client direction) an unsupported
metering to be performed, send failure to server and cause the
session to be terminated at the client.
If a PPAC indicates support for multiple services (0x00000020), the
translator maps this onto a DCC Multiple-Services- Indicator AVP.
5.2.2. Service Termination Attribute (c->s)
The Diameter base protocol assumes that the client always supports
dynamic session termination. If this AVP is present, the translator
does not need to do anything, i.e. there exists no DCC AVP that this
AVP can be mapped to. If this AVP is absent, the message in which it
appears should either be discarded and originator should be informed
of a failure, or the message can be passed on (without this AVP being
mapped onto a DCC AVP). However, in the latter case, the translator
has to remember that the client does not support dynamic termination.
Thus, the translatior has to initiate the normal session termination
procedure with the client when (if) dynamic termination is later
initiated by the server.
5.2.3. Quota Identifier Attribute (c<->s)
When quota is allocated for the first time by the DCC server, the
translator has to create a QID AVP, as required by this
specification. The translator later uses a QID AVP that is sent in
the client-to-server direction in order to identify the corresponding
DCC session. The QID has to be saved in the translator's per session
state.
5.2.4. Volume Quota Attribute (c<->s)
If this AVP occurs in a message that is sent in the server-to-client
direction, it is translated into a Granted-Service-Unit AVP with an
embedded CC-Total-Octets AVP. [editor's note: this sentence belongs
to the other translation type, i.e. AAA = RPP and client = DCC.]
If this AVP occurs in a message that is sent in the client-to-server
direction, then it is translated into a Used-Service-Unit AVP with an
embedded CC-Total-Octets AVP. Note that only the difference between
current cumulative quota for the (sub)session and the quota in
incoming messages is indicated in the translated DCC message. Local
state is updated with cumulative consumed resources.
Conversely, if the server grants quota using the DCC Granted-Service-
Unit AVP with an embedded CC-Total-Octets AVP, then the translation
agent must translate this into a Volume Quota Attribute. Again,
local state must be consulted so that the cumulative amount of octets
is indicated in the Volume Quota attribute.
5.2.5. Duration Quota Attribute (c<->s)
If this AVP occurs in a message that is sent in the server-to-client
direction, it is translated into a Granted-Service-Unit AVP with an
embedded CC-Time AVP. [editor's note: this sentence belongs to the
other translation type, i.e. AAA = RPP and client = DCC.]
If this AVP occurs in a message that is sent in the client-to-server
direction, then it is translated into a Used-Service-Unit AVP with an
embedded CC-Time AVP. Note that only the difference between current
cumulative quota for the (sub)session and the quota in incoming
messages is indicated in the translated DCC message. Local state is
updated with cumulative consumed resources (i.e. time).
Conversely, if the server grants quota using the DCC Granted-Service-
Unit AVP with an embedded CC-Time AVP, then the translation agent
must translate this into a Duration Quota attribute. Again, local
state must be consulted so that the cumulative amount of seconds is
indicated in the Duaration Quota attribute.
5.2.6. Resource Quota Attribute (c<->s)
If this AVP occurs in a message that is sent in the server-to-client
direction, it is translated into a Granted-Service-Unit AVP with an
embedded CC-Service-Specific-Units AVP. [editor's note: this sentence
belongs to the other translation type, i.e. AAA = RPP and client =
DCC.]
If this AVP occurs in a message that is sent in the client-to-server
direction, then it is translated into a Used-Service-Unit AVP with an
embedded CC-Service-Specific-Units AVP. Note that only the
difference between current cumulative quota for the (sub)session and
the quota in incoming messages is indicated in the translated DCC
message. Local state is updated with cumulative consumed resources
(i.e. resources).
Conversely, if the server grants quota using the DCC Granted-Service-
Unit AVP with an embedded CC-Service-Specific-Units AVP, then the
translation agent must translate this into a Resource Quota
attribute. Again, local state must be consulted so that the
cumulative amount of resource units is indicated in the Resource
Quota attribute.
Note that the "resource" type is application dependent. This means
that a DCC application unit corresponds to n RPP application units,
where n may be any real number. If n is not 1, then the RPP/DCC
translator must be aware of that and translate resource units
accordingly.
5.2.7. Value Digits Attribute (c<->s)
The encoding of this AVP is similar in RPP and DCC, and the value it
holds may have to be evaluated in conjunction with an acommpanying
"Exponent" AVP. It should be kept in mind that, in RPP the
cumulative amount of granted/consumed quota is typically encoded into
an AVP of this type, while in DCC only the difference from a previous
message.
5.2.8. Exponent Attribute (c<->s)
The encoding of this AVP is similar in RPP and DCC, and the value it
holds may have to be evaluated in conjunction with an acommpanying
"Value Digits" AVP. It should be kept in mind that, in RPP the
cumulative amount of granted/consumed quota is typically encoded into
a related "Value Digits" and "Exponent" AVP pair, while in DCC only
the difference from a previous message is encoded into such a pair.
5.2.9. Volume/Duration/Resource Threshold Attributes (s->c)
In DCC the concept of "threshold" does not exist. Instead, the DCC
client is assumed to ask for the replenishment of quota in good time.
In RPP, on the other hand, the server may optionally include a
threshold AVP, as an indication to the PPC about when to ask for
quota replenishment.
Thus, in this scenario, there is no need for the translator to ever
include a threshold attribute into the messages that it sends to the
PPC. If, however, there is a need for a threshold attribute to be
present in order to avoid a possible service provision
5.2.10. Update Reason Attribute (c->s)
The DCC AVP that is semantically closer to the Update Reason AVP than
any other AVP is the CC-Request-Type AVP. This AVP indicates whether
the message is which it appears is intended to indicate an "initial",
an "intermediate" or a "final interrogation". Morever, in case of
the session being terminated at the client, it indicates the reason
for this termination.
The following list lists the possible values of an "Update Reason"
attribute, along with corresponding values for the CC-Request-Type
AVP.
o Pre-initialization: No action/value defined.
o Initial Request: Typically an "intial interrogation" is triggered
as a result of the reception of the message that contains this
Update Reason AVP. Hence, CC-Request-Type AVP indicates
"INITIAL_REQUEST".
o Threshold Reached: The reception of the message containing this
Update Reason AVP typically triggers an "intermediate
interrogation". Hence, CC-Request-Type AVP indicates
"UPDATE_REQUEST".
o Quota Reached: The reception of the message containing this Update
Reason AVP typically triggers an "intermediate interrogation".
Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST".
o TITSU Approaching: The reception of the message containing this
Update Reason AVP typically triggers an "intermediate
interrogation". Hence, CC-Request-Type AVP indicates
"UPDATE_REQUEST".
o Remote Forced Disconnect: Reception of such an Update Reason
indicates that the client has terminated the session. The
corresponding value for the CC-Request-Type AVP is
"TERMINATION_REQUEST".
o Client Service Termination: Reception of such an Update Reason
indicates that the client has terminated the session. The
corresponding value for the CC-Request-Type AVP is
"TERMINATION_REQUEST".
o "Access Service" Terminated: Reception of such an Update Reason
indicates that the client has terminated the session. The
corresponding value for the CC-Request-Type AVP is
"TERMINATION_REQUEST".
o Service not established: Reception of such an Update Reason
indicates that the client has terminated the session. The
corresponding value for the CC-Request-Type AVP is
"TERMINATION_REQUEST".
o One-Time Charging: Such an Update Reason indicates that a one-time
charging event is initiated by the client. The corresponding
value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a
"Requested-Action: AVP MUST also be included in the outgoing DCC
message. Typically, this would be of the type "DIRECT_DEBITING",
or "REFUND_ACCOUNT", depending on other AVPs present in the
message.
5.2.11. PrepaidServer Attribute (s<->c)
The PPC typically never sets the value of a PrepaidServer attribute.
Instead, it repeats those values that it receives from the AAA
infrastructure, in this scenario from the translator. This attribute
is therefore not used in a translation scenario. Nevertheless, the
translator must make sure that messages about the same RPP session
are forwarded to the same DCC server, throughout the whole session.
This may be easy to guarantee since the transport of Diameter is TCP.
5.2.12. Service-ID Attribute (s<->c)
The DCC equivalent of a RPP "Service-ID" AVP is the combination of
Service-Context-Id and Service-Identifier AVPs. The translator must
keep a static equivalence table of the RPP Service-ID and the
corresponding DCC combination in order to correctly translate an RPP
service identifier into DCC and back.
5.2.13. Rating-Group-ID Attribute (s<->c)
The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a
"Rating-Group-ID". Depending on the configuration, this AVP may
contain the same value on both the RPP and the DCC side of the
communication. If, however, static rating groups are configured
between the RCC client and the translator, and different rating
groups between the DCC server and the translator, then the translator
has to maintain a static translation table for the rating group
identifier. In any case, the translation of a rating group AVP, is
not a function of the translator's local per-session state.
5.2.14. Termination-Action Attribute (s->c)
The DCC equivalent of the "Termination-Action" AVP is called the
"Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA
infrastructure), a DCC "Final-Unit-Action" AVP is translated into a
"Termination-Action" AVP. The following list contains the possible
"Final-Unit-Action" values along with their "Termination-Action"
equivalent.
o TERMINATE (DCC): This value has a direct equivalent in RPP, also
called "Terminate".
o REDIRECT (DCC): If this value appears in a "Final-Unit-Action"
AVP, then a "Redirect-Server-Address" AVP must also appear in the
same DCC message. The translator translates these two AVPs into a
"Termination-Action" with value "Redirect/Filter" and an
eqiovalent NAS-Filter-Rule attribute (specified in http://
www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt).
o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit-
Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear
in the same DCC message. The translator translates these two AVPs
into a "Termination-Action" with value "Redirect/Filter" and an
eqiovalent Filter-ID attribute (specified in http://www.ietf.org/
internet-drafts/draft-ietf-radext-ieee802-00.txt).
o In the absence of a "Final-Unit-Action" AVP, the DCC server
assumes that the DCC client will ask for replenishment of quota at
some suitable time. In RPP, this is explicitly conveyed via a
"Termination-Action" AVP with the value "Request More Quota".
Thus, in the absence of a "Final-Unit-Action" AVP, the translator
in this scenario appends such an AVP into the outgoing RPP
message.
5.2.15. Pool-ID Attribute (s<->c)
The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID".
Typically, no translation needs to be done to the "Pool-ID"
attribute.
5.2.16. Multiplier Attribute (s<->c)
The multiplier attribute, which is a pair of "Value-Digits" and
"Exponent" AVPs, typically needs no translation, since the value it
carries (inside a "Value-Digits" and an "Exponent" AVP) represents
the rating of the service or rating group to which it refers, with
respect to abstract units. As such, the same multiplier value would
typically applyt be conveyed from a DCC server to an PPC, and vice
versa.
5.2.17. Requested-Action Attribute (c->s)
The "Requested Action" AVP can be directly translated into its DCC
equivalent, which carries the same name.
1. Balance Check (PCC): CHECK_BALANCE (DCC)
2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC)
5.2.18. Check-Balance-Result Attribute (s->c)
This attribute carries only a binary value. Hence, its translation
is straightforward.
5.2.19. Cost-Information Attribute (s->c)
This attribute consists of a Value-Digits AVP, an Exponent AVP, a
Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise
exist in DCC, and carry identical semantics in the context of the
"Cost-Information" AVP. Thus, the translation of this attribute is
straightforward.
5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s)
This attribute carries the amount of octets that were consumed after
a tariff change. It always appears in a message with an accompanying
PPAQ attribute in which the total amount of octets (i.e. those that
were consumed both before and after the tariff switch) is reported.
Thus, the translation agent can compute the amount of octets that
were consumed before the tariff change.
In DCC, the two amounts, i.e. the octets that were consumed before a
tariff change and those that were consumed afterwards, are reported
in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs
have an embedded CC-Total-Octets AVP that indicates the appropriate
amount of octets. Furthermore, the Used-Service-Unit AVP that
carries the amount that was consumed before the tariff switch also
carries an embedded Tariff-Change-Usage AVP with the value
UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP
that carries the amount that was consumed after the tariff switch
also carries an embedded Tariff-Change-Usage AVP with the value
UNIT_AFTER_TARIFF_CHANGE (1).
6. Security Considerations
[Editor's Note: A future version of this document will provide a
description of the security threats and the countermeasures.]
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: numbers for the following attributes: Prepaid-Accounting-Capability
(PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ),
QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT),
DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR),
PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID),
TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost-
Information (COST), Session-Termination-Capability (STC),
PrepaidTariffSwitch (PTS) and TariffSwitchInterval (TSI).
1) Prepaid-Accounting-Capability (PPAC) 8. Contributors
with subtype:
AvailableInClient
2) Prepaid-Accounting-Operation (PPAQ) The authors would like to thank Christian Guenther and Yong Li for
with subtypes: their contribution to earlier draft versions.
QuotaID (QID)
VolumeQuota (VQ)
VolumeQuotaOverflow (VQO)
VolumeTreshold (VT)
VolumeTresholdOverflow (VTO)
DurationQuota (DQ)
DurationTreshold (DT)
UpdateReason (UR)
PrePaidServer (PPS)
ServiceID (SID)
RatingGroupId (RGID)
TerminationAction (TA)
PoolID (PID)
PoolMultiplier (PM)
Cost (COST)
TariffChangeTime (TCT)
3) Prepaid-Tariff-Switch (PTS) 9. References
4) Session-Termination-Capability (STC) 9.1. Normative References
5) International-Mobile-Subscriber-Identity (IMSI) [1] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
7. [2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865:
Normative References Remote Authentication Dial In User Server (RADIUS)", June 2000.
[RFC2026] Bradner, S., "The Internet Standards Process -- [3] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS
Revision 3", RFC 2026, October 1996. Extensions", June 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Server
(RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June [4] Bradner, S., "RFC 2026: The Internet Standards Process --
2000. Revision 3", October 1996.
[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS [5] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000.
Extensions", RFC 2869, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and
Holdrege, M., Goyret, I., "RADIUS Attributes for I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol
Tunnel Protocol Support" , RFC 2868, June 2000. Support", June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D.,
Aboba, B., "Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service
(RADIUS)", RFC 3576, February 2003.
[RFC3748] Aboba, B., et al., "Extensible Authentication [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba,
Protocol", RFC 3748, June 2004. "RFC 3576: Dynamic Authorization Extensions to Remote
Authentication Dial-In User Service (RADIUS)", February 2003.
8. [8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Informative References Levkowetz, "RFC 3748: Extensible Authentication Protocol",
June 2004.
[DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control 9.2. Informative References
Application", Internet Draft, AAA WG, April 2004,
Work in Progress.
[REDIRECT] "RADIUS Redirection", Internet Draft, Work in [9] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
progress. Loughney, "RFC 4006: Diameter Credit Control Application",
August 2005.
9. Appendix A. Example flows
Call Flows
This section describes the flows associated with various scenarios This section presents certain example flows that involve the RADIUS
that are mentioned in this document. The following fields are used prepaid extensions. By no means is the intent of this section to
in the call flows: specify or recommend business logic, rating strategies, and
application-level behaviour. The intent of this section is purely to
illustrate some fictive scenarios and the RADIUS prepaid message
flows that could be associated with these scenarios. The contents of
this section should be regarded as a collection of informative
examples that aim to provide guidance to implementors.
RADIUS packets: A.1. A simple flow
AR Access Request End user PPC AAA Server PPS
ARA Access Accept
AC Accounting Requests
A Authorize-Only Access-Request
AA Access-Accept for Authorize-
Only Access-Request
RADIUS Attributes: user logs on
------(1)--------->
PPAQ PPAQ as defined in this Access Request
specification {RADIUS BASE AVPS,
SID One or more attributes PPAC=00...00011}
representing the Session that -------(2)-------->
the RADIUS packets is correlated
to.
PPAC PPAC as defined in this
specification
ASID Acct-Session-Id as defined by
RADIUS
MSID Acct-Multi-Session-Id as define
by RADIUS
PPAQ fields: RADIUS authentication
<--------------(3)---------------------->
SRVID Service-Id Access Request
Reason Update-Reason {RADIUS BASE AVPS,
QID Quota-Id PPAC=00...00011}
------(4)--------->
9.1 [allocates
Simple Concurrent Services 5MB quota]
In this scenario the PPC authenticates and authorizes the user. The Access Response
PSS responds with Quota for the ôAccess Serviceö instance. The NAS {RADIUS BASE AVPS,
then request quota for Service-A. PPAQ={QID=5, VQ = 5MB,
VTH = 4.5 MB}}
<-------(5)--------
forwards message
<-----(6)-----------
Accounting is turned on. service provision/metering
-------(7)--------->
NAS/ RADIUS/ 4.5 MB consumed
PPC PPS Access Request
=== === {RADIUS BASE AVPS,
| | PPAQ={QID=5, VQ=4.5MB,
| AR{SID,PPAC} | REASON=THRESHOLD REACHED}}
A |-------------------------------------------------->| -------(8)--------->
| |
| ARA{SID,PPAQ(QID=1,Q=100)} |
B |<--------------------------------------------------|
| |
| AC(start){ASID=25,MSID=13} |
C |-------------------------------------------------->|
| |
| A{SID,PPAQ(SRVID=SA, Reason=Initial} |
D |-------------------------------------------------->|
| |
| AA{SID,PPAQ(QID=200,SRVID=SA, Q=50)} |
E |<--------------------------------------------------|
| |
| AC(start){ASID=30,MSID=13, PPAQ } |
F |-------------------------------------------------->|
| |
| A{SID, PPAQ(QID=200 SRVID=SA, Q=50 Reason=Quota)}|
G |-------------------------------------------------->|
| |
| AA{SID,PPAQ(QID=300,SRVID=SA, Q=100)} |
H |<--------------------------------------------------|
| |
| A{SID, |
| PPAQ(QID=1, Q=100 Reason=Quota), |
| PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} |
I |-------------------------------------------------->|
| |
| AA{SID,
| PPAQ(QID=3, Q=200), |
| PPAQ(QID=303, SRVID=SA Q=150)} |
J |<--------------------------------------------------|
A This is the initial Access-Request that indicates the prepaid forwards message
capabilities of the NAS. In this example indicates that -------(9)------->
Concurrent Sessions are supported. Access-Request also
includes SID (Session Id) which is the Session Identifier
assigned by this NAS to session. The formal of the session
identifier is outside the scope of this document.
B RADIUS authenticates the user and determines that he has a
prepaid account. RADIUS responds with a PPAQ for the ôAccess
Serviceö (PPAQ does not contain a Service-ID or Rating-Group-
ID). The PPAQ has a QID=1 assigned by the Prepaid System and
Quota of Q=100. The quota could be time or volume and may or
may not have a threshold associated with it.
C The NAS starts the Access Service and generates an Accounting-
Request (Start) message as normal. It includes the Acct-
Session-Id and may include the Acct-Multi-Session-Id.
D The NAS is about to start a new Service, call it Service-A.
It sends an Authorize-Only access request to RADIUS. The SID
links this Authorize-Only access request to the initial
Authentication & Authorization (Step-A and Step-B).The
Authorize-Only message contains a PPAQ requesting quota for
Service-A, Update-Reason = Initial-Request.
E The PPS checks the resources available to the user and assigns [allocates another 7MB
50 units (time/volume etc) to this service. RADIUS sends an to the access service]
Access Accept message contain a PPAQ assigning quota Q=50 for
Service-A. The PPAQ contains a QID = 200.
F The NAS starts Service-A and sends an Accounting-Request
(Start) message for that service. Acct-Multi-Session-Id can be
used to tie all of the sessions in the accounting streams
together.
G Quota for Service-A requires refreshing, the quota was
completely used). An Authorize-Only message is sent
containing a PPAQ with QID = 200 which corresponds to the
prior QID received for this service. Note QID is sufficient
for the PPS server to link this request to the previous
request and hence to the original authentication steps.
Therefore SID is not really required. The PPAQ will report the
used part of the quota (50 units).
H RADIUS deducts the used quota from the users accounts and
reserves 50 more additional units for a total quota of 100
(Q=100) for Service-A. It sends back a PPAQ with QID=300.
I NAS needs to refresh both the ôAccess Serviceö and Service-A.
It sends an Authorize Only message contain two PPAQs, one for
the Main Service with QID=1 and one for Service-A with
QID=300. Each PPAQ reports the resources that were consumed
so far and the reason why the update is being sent.
J RADIUS responds back with two PPAQs. The PPAQ without the
Service-Id grants an additional 100 units for a total of 200
units to the ôAccess Serviceö û QID=3; the other PPAQ,
containing SRVID=SA grants an additional 50 units for a total
quota to service-a of 150 units û QID=303.
This step illustrates why SRVID needs to be specified in the Access Response
PPAQ. Without it the NAS would be unable to differentiate {RADIUS BASE AVPS,
between the PPAQs. QIDs are not sufficient to correlate the PPAQ={QID=8, VQ=12MB,
PPAQ to a service since they may be changed by the PPS at VTH = 11.5 MB}}
every transaction. <----------(10)--------------
forwards message
<------(11)--------
Note how each PPAQ attribute represents a sequential conversation user logs off
about a service between the PPC and the PPS in this example. The ------(12)-------
links between the messages are the QIDs and the Service-Ids.
Also note that a SID is needed to tie the Authorize-Only messages to Access Request
the Authentication steps. This SID is only really needed the first {RADIUS BASE AVPS,
time a PPAQ is sent. PPAQ={QID=8, VQ=7 MB,
REASON=ACCESS SERV TERMINATED}}
-------(13)--------->
Although accounting messages have an Accounting-Session-ID, that is forwards message
not enough to enable the back end system to associate that -------(14)------->
accounting message with a particular Service. We therefore need the
PPAQ in the accounting message.
9.2 [reimburses
One-time Charging user account]
In this One-time charging example, the PPC authenticates and AA Response
authorizes the user and requests charging for a service event {RADIUS BASE AVPS}
requested by the user. The PPC already knows the price to charge <------(15)--------
for the service event identified by SRVID=SA. AA Response
{RADIUS BASE AVPS}
<------(16)--------
Contributor Figure 12: A simple example message flow
We would like to thank Hannes Tschofenig for his contributions to The user logs on (1). The PPC sends a RADIUS Access Request message
this draft. to the home AAA server (2), and includes the prepaid-specific PPAC
AVP. This AVP indicates that both duration-based and volume-based
metering is supported. However, it also indicated that multiple
services, rating groups and resource pools are not supported. Note
that, since this is not an "Authorize Only" message, no PPAQ AVP with
Update Reason="initial request" is included (see Section 3.7.1). The
home AAA server then authenticates the user and authorizes the access
service, as is usual in RADIUS (3). Note that the PPAC AVP is
appended by the PPC in at least the last message that is sent to the
home AAA server during this possibly multiple-round exchange.
Acknowledgments If authentication and authorization is successful (in this example
this is assumed), the home AAA server forwards the final Access
Request to the PPS (4). The PPS identifies the user's prepaid
account from the included base RADIUS AVPs, and determines the
capabilities of the PPC from the PPAC attribute. Assuming that
sufficient funds are available in the user's prepaid account, the PPS
reserves some of these and rates the service. In this example, the
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
granted. The PPS also determines that the PPC should ask for this
quota to be replenished once 4.5 MB have been consumed. Thus, it
creates an Access Accept message with a Volume-Threshold indication
of 4.5MB. It further associates the QuotaIdentifier QID=5 to this
quota reservation. This identifier can be used to later uniquely
identify the prepaid session, user, account, etc. The resulting
Access Accept message is sent to the home AAA server (5) and
forwarded to the PPC (6).
The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala Upon reception of message (6), the PPC provides the access service to
and Tseno Tsenov for their contribution to this draft. the user and meters it accordingly.
Author's Addresses 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
PPC generates an Authorize Only Access Request that contains the
usual RADIUS attributes and a PPAQ AVPs that reports the amount of
consumed quota, and the request for replenishment, i.e. the Update-
Reason= THRESHOLD REACHED (8). Note that the QID in this message is
the same as the one previously received from the user's home AAA
server. This message is forwarded to the PPS (9).
Avi Lior Parviz Yegani, Ph.D. Upon reception of message (9), the PPS identifies the user and his
Bridgewater Systems Mobile Wireless Group account from the QID. In also determines that a prepaid session is
303 Terry Fox Drive Cisco Systems ongoing, and that enough credit remains in the prepaid account in
Suite 100 3625 Cisco Way order for the access service to continue being provided. Since 4.5
Ottawa Ontario San Jose, CA 95134 MB have been consumed, the PPS subtracts 1.8 Euros from the user's
Canada USA prepaid account. The PPS decides to reserve another 2.8 euros from
avi@bridgewatersystems.com pyegani@cisco.com 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
per MB, the PPS determines that another 7 MB of quota should be
granted. This results in a total cumulative quota allocation of 12
MB for the access service. The PPS further calculates the new
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
QID=8. The resulting RADIUS message is sent to the home AAA server
(10) and forwarded to the PPC (11).
Kuntal Chowdhury Hannes Tschofenig Upon reception of message (11), the PPC updates its records and
Starent Networks Siemens continues provisioning access to the user. At some point the user
30 International Place, 3rd Flr Otto-Hahn-Ring 6 logs off (12). The PPC must then report how many resources were
Tewksbury, MA 01876 81739 Munich consumed, so that the PPC can subtract the appropriate monetary
kchowdhury@starentnetworks.com Germany amount from the user's prepaid account. To this end the PPC
hannes.tschofenig@siemens.com constructs an Authorize Only Access Request message with a PPAQ AVPs
for the access service. In this example, 7 MB were consumed by the
access service in total. The PPC reports 7 MB its final message
(13). This is forwarded to the PPS (14) which correlates the report,
using the QID, to the previous session state. It determines, from
the previous records, that the access service had consumed another
4.5 MB before (as indicated in message (9)). This means that, of the
7 MB, only 3.5 MB have not yet been subtracted from the user's
account. Thus, the PPS subtracts another 1.4 euros from the user's
account and, since the session is to be terminated (REASON=ACCESS
SERVICE TERMINATED), releases any reserved monetary amount.
Christian Guenther The PPS responds with an Access Response as required by the RADIUS
Siemens base specification (15). So does the home AAA server (16).
Otto-Hahn-Ring 6
81739 Munich
Germany
christian.guenther@siemens.com
Intellectual Property Statement A.2. A flow with prepaid tariff switching
The IETF takes no position regarding the validity or scope of any End user PPC AAA Server PPS
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the IETF's procedures with respect to rights in IETF
Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any user logs on
assurances of licenses to be made available, or the result of an ------(1)--------->
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Access Request
copyrights, patents or patent applications, or other proprietary {RADIUS BASE AVPS,
rights that may cover technology that may be required to implement PPAC=00...00111}
this standard. Please address the information to the IETF at ietf- -------(2)-------->
ipr@ietf.org.
Disclaimer of Validity RADIUS authentication
<--------------(3)---------------------->
This document and the information contained herein are provided on Access Request
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE {RADIUS BASE AVPS,
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE PPAC=00...00011}
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ------(4)--------->
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement [allocates
20MB quota]
Copyright ¨ The Internet Society (2005). This document is subject to Access Response
the rights, licenses and restrictions contained in BCP 78, and {RADIUS BASE AVPS,
except as set forth therein, the authors retain all their rights. PPAQ={QID=5, VQ = 20MB,
VTH = 18 MB}, PTS={
QID=5, PTS{TSI=300sec,
TITSU=6000sec}}
<-------(5)--------
forwards message
<-----(6)-----------
Expiration Date service provision/metering
-------(7)--------->
This memo is filed as draft-lior-radius-extensions-for-prepaid- 5900 seconds have passed
06.txt, and will expire 20 July, 2005.
10. Access Request
Appendix A û use cases {RADIUS BASE AVPS,
PPAQ={QID=5, VQ=14MB,
REASON=TITSU APPROACH.},
TSI={QID=5, VUATS=11MB}}
-------(8)--------->
In this appendix we present a set of use cases and scenarios based forwards message
on which the extensions in this document were designed. It is -------(9)------->
assumed that the subscriber possesses a valid prepaid account with a
service provider, for example a WLAN operator.
In order to maintain generality, the use cases refer to the [allocates another 10MB
communications between the SAD and the network. The connection to the access service]
between the UserÆs Device and the SAD, which typically involves
setting up a layer 2 session, e.g. a PPP session or a GPRS PDP
Context, is specific to a given network technology and the details
do not affect the operation of the prepaid service.
10.1 Access Response
Simple prepaid use case {RADIUS BASE AVPS,
PPAQ={QID=8, VQ=30MB,
VTH = 28 MB},PTS={
QUD=8, PTS=95 sec}}
<----------(10)--------------
forwards message
<------(11)--------
A subscriber connects to his home network. As usual, the Access user logs off
Device that is servicing the subscriber uses the AAA infrastructure ------(12)-------
to authenticate and authorize the subscriber.
The SAD sends a RADIUS Access-Request to the AAA server in order to Access Request
authenticate and authorise the subscriber with respect to the {RADIUS BASE AVPS,
requested service. The Access-Request contains the subscriber PPAQ={QID=8, VQ=17 MB,
credentials and may contain the prepaid capabilities of the SAD. REASON=ACCESS SERV TERMINATED},
Prepaid capabilities MUST be included if the SAD supports them. PTS={QID=8, VUATS=2.5 MB}
-------(13)--------->
The AAA System proceeds with the authentication procedure. This may forwards message
involve several message exchanges such as in EAP [RFC2284]. Once -------(14)------->
the subscriber has been authenticated, the AAA system determines
that the subscriber is a prepaid subscriber and requests
authorisation. The request MUST include the prepaid capabilities of
the serving SAD.
The system validates that the subscriber has a prepaid account and [reimburses
that the account is active. It further validates that the SAD has user account]
the appropriate prepaid capabilities. If all is in order, the
prepaid system authorises the subscriber to use the network.
Otherwise it rejects the request. The decision is sent to the AAA
system. The response includes attributes to indicate the allocation
of a portion of the subscriberÆs credit. This portion is called the
ôinitial quotaö (in units of time or volume) and optionally a
threshold value.
A portion only of the userÆs funds is allocated because the user may AA Response
be engaged in other services that may draw on the same account. For {RADIUS BASE AVPS}
example, the user may be engaged in a data session and a voice <------(15)--------
session. Although these two services would draw from the same AA Response
account, they form separate parts of the overall system. If the {RADIUS BASE AVPS}
entire quota was allocated to the data session then the user would <------(16)--------
have no more funds for a voice session.
The AAA system incorporates the attributes received from the prepaid Figure 13: Example message flow with Tariff Switch
System into an Access-Accept message that it sends to the SAD. Note
that the AAA system is responsible for authorizing the service
whereas the prepaid system is responsible for prepaid authorization.
Upon receiving the Access-Response, the SAD starts the prepaid data The user logs on (1). The PPC sends a RADIUS Access Request message
session and meters the session based on time or volume, as indicated to the home AAA server (2), and includes the prepaid-specific PPAC
in the message. AVP. This AVP indicates that both duration-based and volume-based
metering is supported, as well as tariff switching. The home AAA
server then authenticates and user and authorizes the access service,
as is usual in RADIUS (3). Note that the PPAC AVP is appended by the
PPC in at least the last message that is sent to the home AAA server
during this possibly multiple-round exchange.
Once the usage for the session approaches the allocated limit (as If authentication and authorization is successful (in this example
expressed by the threshold), the SAD will request additional quota. this is assumed), the home AAA server forwards the final Access
Re-authorization for additional quota flows through the AAA system Request to the PPS (4). The PPS identifies the user's prepaid
to the prepaid System. The prepaid System revalidates the account from the included base RADIUS AVPs, and determines the
subscriberÆs account and subtracts the previously allocated quota capabilities of the PPC from the PPAC attribute. In this example, it
from the current balance. If there is remaining balance, it is assumed that a tariff switch is about to occur in 300 seconds from
reauthorizes the request with an additional quota allotment. the current time. Suppose that the access service is currently rated
Otherwise, the prepaid System rejects the request. Note the at 0.5 euros per MB and in the next tariff period it is rated at 0.6
replenishing of the quotas is a re-authorization procedure and does euros per MB. Suppose further that a third tariff period is about to
not require the subscriber to authenticate himself again. start in 6000 seconds from current time and that that access service
is rated at 0.8 euros per MB in that period. The PPS then decides to
reserve 12 euros from the user's account. Since it is conceivable
that the user may consume all allocated quota in the (more expensive)
"0.6-euro" period, the PPS reserves 20 MB of quota, and determines a
threshold value of 18 MB. It constructs a Radius Access Accept
message with a PPAQ attribute that reflects these choices, and
carries a QuotaIdentifier QID=5. It further adds a PTS AVP in the
message which is linked to the PPAQ via the common QID value. The
PTS AVP contains a TSI attribute indicating that a tariff switch will
occur in 300 seconds. It also includes a TITSU attribute with the
value of 6000 seconds. This is included in order to make sure that
the PPC will report the consumed quota before the "2-euro" tariff
period will start. The message is sent to the AAA server (5) and
forwarded to the PPC (6).
It is important to note that the prepaid System is maintaining Upon reception of message (6), the PPC provides the access service to
session state for the subscriber. This state includes how much the user and meters it accordingly (7). It also keeps track of time.
account balance was allocated during the last quota enquiry and how That is, it remembers how many octets are consumed before and how
much is left in the account. Therefore, it is required that all many after the tariff switch that will take place in 300 seconds.
messages about the session reach the same (and correct) prepaid
system.
Upon receiving a re-allotment of the quota, the SAD continues to In this example it is assumed that the user consumes the allocated
provide the data service until the new threshold is reached. If the quota rather slowly. In particular, nearly 6000 seconds (the value
request for additional quota cannot be fulfilled then the SAD lets indicated by TITSU) pass without the threshold of 18 MB being
the subscriber use the remaining quota and terminates the session. reached. The PPC notices this and must therefore report usage and
request the quota to be replenished despite the fact that the
threshold has not been reached. In this example, it decides to do so
100 seconds before the 6000 seconds are reached. To this end, it
constructs an Authorization Access Request message including a PPAQ
that indicates that 14 MB have been consumed up to now. It also
includes a PTS AVP in order to indicate, using the VUATS AVP, that 11
MB of these were consumed after the tariff switch. The message is
sent to the AAA server (8) and forwarded to the PPS (9).
Alternatively, instead of terminating the session, the SAD may The PPS can link the message to previous session state via the QID.
restrict the data session such that the subscriber can only reach a It now rates the consumed volume as follows. The 11 MB that were
particular web server. This web server maybe used to allow the consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros
subscriber to replenish their account. This restriction can also be and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS
used to allow new subscribers to set up prepaid accounts in the subtracts the amount of 6.6+1.5=8.1 euros from the user's account,
first place. which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved.
Should the subscriber terminate the session before the quota is The PPS now determines that message (9) was sent in order to
exhausted, the remaining balance allotted to the session MUST be replenish the quota for this prepaid session. This can be deduced
refunded into the subscriberÆs account. from the UPDATE REASON field, which indicates that the PPC sent this
message because the time indicated by the TITSU AVP is approacing.
The PPS now determines that enough credit remains in the user's
prepaid account in order for the access service to continue being
provided and decides to reserve another 8.9 euros from the user's
account. Since it is conceivable that the user will consume the 6
unused MB of quota from the previous allocation, as well as the
entire quota that is to be allocated now, entirely in the "0.8-euro"
period, the quota that should now be granted in addition to the
previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros
are being reserved in order to "cover the worst case scenario". The
fact that 0.9 euros are reserved for this purpose is due to the fact
that the unused 6 MB from the previous allocation correspond to 4.8
euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more
than the amount of funds that are still "reserved" from the previous
allocation. (After this reservation, the total amount of reserved
money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB
being consumed in the "0.8-euro" period.)
While the Access Device is waiting for the initial quota, the Since quotas are encoded in a cumulative way in RADIUS, the PPS
subscriber may have dropped the connection/session. The entire includes a VolumeQuota of 30 MB into the Access Accept message (10).
allocated quota MUST be credited back to the subscribers account in The PPS further calculates the new threshold value of 28 MB. Since
this case. this is a new quota reservation, 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 (10) and forwarded to the PPC
(11).
10.2 Upon reception of message (11), the PPC updates its records and
Support for Multi-Services continues providing access to the user. At some point the user logs
off (12). The PPC must then report how many resources were consumed,
so that the PPC can subtract the appropriate monetary amount from the
user's prepaid account. To this end the PPC constructs an Authorize
Only Access Request message with a PPAQ AVPs for the access service.
In this example, 17 MB were consumed by the access service in total.
The PPC reports 17 MB its final message (13). This is forwarded to
the PPS (14) which correlates the report, using the QID, to the
previous session state. It determines, from the previous records,
that the access service had consumed 14 MB before (as indicated in
message (9)). This means that, of the 17 MB, only the monetary
equivalent for 3 MB have not yet been subtracted from the user's
account. The PPS calculates how much should be deducted from the
user's account as follows. Since the VUATS AVP indicates that 2.5MB
were consumed after the tariff switch, only 0.5 MB were consumed
before that. Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8
= 3.6 euros. That is, the PPS subtracts 3.6 euros from the user's
prepaid account. Since the session has by now be terminated by the
PPC (REASON=ACCESS SERVICE TERMINATED), the PPS now releases any
reserved monetary amount, in this example 12.8 - 3.6 = 9.2 euros.
Examples of services that the user may be using are browsing the The PPS responds with an Access Response as required by the RADIUS
web, participating in a VoIP conversation, watching streaming video base specification (15). So does the home AAA server (16).
and downloading a file. Some operators may want to distinguish
between these services. Some services are billed at different rates
and services may be metered differently. Therefore, the prepaid
solution needs to be able to distinguish services, and allocate
quotas to the services using different units (e.g. time, volume) and
allow for those quotas to be utilized at different rates.
+---------+ Remark: In this example, two tariff switches take place. In other
| Session | scenarios, of course, only one tariff switch may occur. In such
+---------+ scenarios the TITSU AVP is not used.
|
V N
+--------------+ +-------+
| Service |------>| Quota |
| (service-Id) | +-------+
+--------------+
As shown in the above diagram, a Session may be associated with A.3. Resource pools and Rating Groups
multiple (N) services. Each service is identified by a Service-ID.
The format of the Service-ID is not in the scope of this document
but the Service-ID could be expressed as an IP flow using the 5-
tuple {Source-IP and Port, Destination-IP and Port, protocol type}.
Each service is allocated an appropriate quota metric.
10.3 End user PPC AAA Server PPS
Resource Pools user logs on
------(1)--------->
When working with multiple services a new problem arises because one Access Request
service may utilize its quota faster than another service. When the {RADIUS BASE AVPS,
userÆs balance is close to exhaustion, a situation could arise where PPAC=00...00101111}
one service is unable to obtain quota while another service has -------(2)-------->
plenty of quota remaining. Unless the quotas can be rebalanced, the
SAD would then have to terminate that service. Indeed, even before
that happens, the services could generate an excessive amount of
traffic as the they update their quotas.
One method to solve these problems is to utilize resource pools. RADIUS authentication
Resource pools enable the allocation of resources to several <--------------(3)---------------------->
services of a session by allocating resources to a pool and have
services draw their quota from the pool at a rate appropriate to
that service. When the quota allocated to the pool is close to
exhaustion, the entire pool is replenished.
+-----------+ Access Request
| Service-A |-----+ +--------+ {RADIUS BASE AVPS,
+-----------+ | Ma | | PPAC=00...00101111}
+-------->| | ------(4)--------->
| Pool |
+-------->| (1) |
+-----------+ | Mb | |
| Service-B |-----+ +--------+
+-----------+
As the figure above shows, Service-A and Service-B are bound to [allocates
Pool(1). Ma and Mb are the pool multipliers (that are associated 5MB quota]
with Service-A and Service-B respectively) that determine the rate
at which Service-A and Service-B draw from the pool.
The pool is initialized by taking the quota allocated to each Access Response
service and multiplying it by Mn. Therefore, the amount of {RADIUS BASE AVPS,
resources allocated to a pool is given by: PPAQ={QID=5, VQ = 5MB,
poolID=1,mult=1}}
<-------(5)--------
forwards message
<-----(6)-----------
Poolr = Ma*Qa + Mb*Qb + . . . service provision/metering
-------(7)--------->
A Pool is empty if: user requests service A
-------(8)--------->
Poolr <= Ca*Ma + Cb*Mb + . . . Access Request
{RADIUS BASE AVPS,PPAQ={
SID="A", RGROUP=1}}
-------(9)-------->
forwards message
-----(10)--------->
where: [allocates 50 min
Ca,Cb are the consumed resources of Service-A and Service-B quota]
respectively.
Note that the resources assigned to the pool are not associated with Access Response
a metric. That is, Service-A can be rated at $1 per Mbyte and {RADIUS BASE AVPS,
Service-B can rated at $0.10 per Minute. In this case if we allocate PPAQ={QID=7, DQ=3000sec
$5 worth of resources on behalf of service-A to the pool we would poolID=1,RGROUP=1, SID="A"
set Ma = 10 and place 50 units into the pool. If we allocate $5 on mult=1747.63}}
behalf of Service-B to the Pool, then M=1 and place 50 units into
the Pool. The pool would have a total sum of 100 units to be shared
between the two services. Each Mbyte used by Service-A will draw 10
units from the pool and each minute used by Service-B will draw 1
unit from the pool.
10.4 <---------(11)---------------
Support for Complex Rating Functions forwards message
<----(12)--------
The rating of a service can be quite complex. While some operators user requests service B
follow linear charging models, others may wish to apply more complex -------(13)-------->
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 are rated at $1 per Mbyte and volume above M bytes be rated
at $0.50 per Mbyte. Such a function could be implemented by repeated
message exchanges with the prepaid system.
To avert the need to exchange many messages while still supporting Pool 1 close to exhaustion
such complex rating functions the notion of a ôRating Groupö is
introduced. A Rating Group is provisioned at the SAD. As
illustrated in the figure below, a Rating Group is associated with
one or more services and defines the rate that the services
associated with the Rating Group consume the quota.
+-----------+ Access Request
| Service-A |------+ {RADIUS BASE AVPS,
+-----------+ | +--------------+ +-------+ PPAQ={QID=5, VQ=4MB,
+---->| | | Quota | REASON=QUOTA REACHED,
| Rating Group |------>| or | PoolID=1, mult=1}
+-----------+ +---->| | | Pool | PPAQ={QID=7, DQ=3300sec
| Service-B |------+ +--------------+ +-------+ REASON=QUOTA REACHED,
+-----------+ PoolID=1, mult=1747.63,
SID="A",RGROUP=1}}
-------(14)--------->
During consumption of a service that is associated with a Rating forwards message
Group, the PPC sends the ID of the Rating Group to the PPS. The -------(15)------->
prepaid service authorizes the Rating Group by allocating a quota to
it and optionally assigning it to a Resource Pool.
When service that belongs to an authorized Rating Group is [allocates another
instantiated, the PPC does not need to authorize this service. This 3 MB to access service
limits the amount of traffic between the PPC and the PPS. and 30 minutes to
service "A"]
10.5 Access Response
One-Time-based Charging {RADIUS BASE AVPS,
PPAQ={QID=8, VQ=8MB,
PoolID=1, mult=1, RGROUP=1},
PPAQ={QID=9, DQ=4800sec
PoolID=1, mult=1747.63,
SID="A"}}
<----------(16)--------------
forwards message
<------(17)--------
One-Time-based Charging is used for charging of service events user logs off
without an ongoing session. That is, the service is provisioned ------(18)-------
instantaneously, as far as charging is concerned. An example of
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
one-time service event is the purchase of a subscription
For a given user, one-time-based charging may occur in parallel with Access Request
other charging models. For example, the subscriber may access a {RADIUS BASE AVPS,
website which is metered (based on time or volume) while he also PPAQ={QID=8, VQ=6.5MB,
purchase the right to use a ring tone (a one-time-based event). REASON=ACCESS SERV TERMINATED,
Note: it is up to the service providers to decide whether or not the PoolID=1, mult=1}
user will be charged for the download of the tone and also be PPAQ={QID=9, DQ=5400sec
charged for the time and volume required to download the ring-tone. REASON=ACCESS SERV TERMINATED,
The facilities provided by this document gives the service provider PoolID=1, mult=1747.63,
the capability to achieve their service charging business goals. SID="A",RGROUP=1}}
For example, should the service provider choose not to charge for -------(19)--------->
the download volume or time, then they can treat the download IP
flow as a separate service that is exempt from charging.
The SAD signals one-time-based charging to the PPS with an forwards message
indication that identifies the service and the units that need to be -------(20)------->
debited from the userÆs account.
One-time-based charging may occur under two conditions: the (a) SAD [reimburses
may not have a authenticated context (or access to an authenticated user account]
context) for the subscriber), or (b) the SAD has access to
authenticated context for the subscriber. In the former case the
SAD will have to authenticate the subscriber. For example, the user
maybe authenticated by the SAD providing access service. However
when the user accesses the subscription server to purchase a
subscription, the subscription server may not have access to the
authentication context of the subscriber and thus will have to
authenticate the subscriber from scratch. Authentication of the
subscriber and the generation of the one-time charging event will
happen in conjunction.
Note that one-time-based charging can also be used to credit the AA Response
prepaid userÆs account. For example, the SAD can return resources to {RADIUS BASE AVPS
the subscriber by issuing a one-time charge request that includes <------(21)--------
the amount of resources to be credited into the account. AA Response
{RADIUS BASE AVPS
<------(22)--------
10.6 Figure 14: Example message flow with resource pools and rating groups
Support for Tariff Switching
The PPC and the PPS may support tariff switching as described The user logs on (1). The PPC sends a RADIUS Access Request message
earlier. For example, as shown in the figure below, traffic before to the home AAA server (2), and includes the prepaid-specific PPAC
18:00 may be rated at ær1Æ and traffic after 18:00 hours is rated at AVP, indicating that multiple services, rating groups and resource
ær2Æ. The PPC reports usage before and after the switch occurs. pools are supported. Note that, since this is not an "Authorize
Tariff switching only makes sense for volume based metering where Only" message, no PPAQ AVP with Update Reason="initial request" is
the volume is billed at different rates. included (see Section 3.7.1). The home AAA server then authenticates
the user and authorizes the access service, as is usual in RADIUS
(3). Note that the PPAC AVP is appended by the PPC in at least the
last message that is sent to the home AAA server during this possibly
multiple-round exchange.
18:00 If authentication and authorization is successful (in this example
------------------+----------------- this is assumed), the home AAA server forwards the final Access
r1 | r2 Request to the PPS (4). The PPS identifies the user's prepaid
------------------+----------------- account from the included base RADIUS AVPs, and determines the
^ ^ capabilities of the PPC from the PPAC attribute. Assuming that
|<----TSI---> | sufficient funds are available in the user's prepaid account, the PPS
| | reserves some of these and rates the service. In this example, the
Access-Accept Access-Request PPS reserves 5 Euros and determines that the access service is rated
at 1 Euro per MB. In anticipation that the user requests more
chargeable services throughout this prepaid session, and since this
is supported by the PPC, the PPS further associates a resource pool
with this reservation, in this example PoolID=1. The PPC also
specifies the multiplier = 1 for the access service. Note that,
since 5MB = 5242880 octets, 1 unit in the resource pool corresponds
to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents.
The PPC it indicates support for tariff switching by setting the (However, the PPC does not need to know that.) Moreover, the PPS
appropriate bit in the PPAC. If the PPS needs to signal a tariff associates the QuotaIdentifier QID=5 to this quota reservation. This
switch time it will send a PTS attribute which indicates the point identifier can be used to later uniquely identify the prepaid
in time when the switch will occur. This indication represents the session, user, account, etc. The resulting Access Accept message is
number of seconds from current time (TarrifSwitchInterval TSI). sent to the home AAA server (5) and forwarded to the PPC (6).
At some point after the tariff switch the PPC sends another Access- Upon reception of message (6), the PPC provides the access service to
Request, as a result of either the user having logged off or the the user and meters it accordingly. That is, for every octet
volume threshold being reached. The PPC reports how much volume was consumed, the PPC subtracts 1 unit (since the multiplier is 1) from
used using the PPAQ in total and how much volume was used after the the resouce pool with PoolID=1.
tariff switch using the PTSÆs VUATS subtype.
If the PPC sends this message before the tariff switch, the PPS will At some point in time, the user requests another chargeable service,
respond with another PTS where the TSI is appropriately updated. namely service A (8). The PPC generates an Authorize Only Access
Request that contains the usual RADIUS attributes and the Service-ID
identifying service A (9). The PPC has determined that service A is
rated in an identical way as at least one more service. Thus,
service A has been configured to belong to a rating group, in this
example the group with Rating-Group-ID=1. This identifier is
included is message (9), which is then forwarded to the PPS (10).
In situations with multiple tariff switches, as shown below, the PPS Upon reception of message (10), the PPS identifies the user and his
MUST specify the length of the tariff switch period using the account from the base RADIUS attributes, the fact that a prepaid
TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute. session is ongoing, and determines that enough credit remains in the
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
decides to reserve another 5 euros from the users account; this
corresponds to 50 minutes or, as encoded in the DurationQuota AVP,
3000 seconds. As service A draws from the same prepaid account as
the access service, the PPS associates this reservation with the same
resource pool as the previous reservation (QID=5), namely the pool
with PoolID=1. Note that, in order for the abstract units in the
pool to be consistent, the multiplier has to be 1747.63. This is
because each second corresponds to about 0.10 / 60 = 0.00167 euros,
which is about 1747.63 times the value of an abstract resource pool
unit, as this was determined by the first allocation of quota to the
pool (i.e. 0.000095367431640625 Eurocents). Since this is a new
quota reservation, the PPS also allocates a new QuotaIdentifier to
it, in this example QID=7. The resulting RADIUS message is sent to
the home AAA server (11) and forwarded to the PPC (12).
18:00 23:30 Upon reception of message (12), the PPC adjusts the units in resource
------------------+---------------------+-------------- pool 1. That is, it first determines how much quota had been
r1 | r2 | r3 allocated to service A in the past, and subtracts this from the quota
------------------+---------------------+-------------- reservation found in the message. Since this is the first quota
^ ^ ^ reservation for service A, there is nothing to subtract. Thus, it
|<----TSI---><-----------|-------->|TITSU adds 3000 * 1747.63 = 5242890 units to the pool and remembers that
| | 3000 seconds have been allocated to service A during this prepaid
Access-Accept Access-Request session. The PPC then provides service A to the user, and meters it
against resource pool 1. That is, for every second it subtracts
1747.63 units from the pool.
When a TITSU is specified in the PTS, the PPC MUST generate an At some point in time, the user requests service B (13). The PPC
Access-Request within the time after TSI and before TITSU expires. determines that service B is rated exactly in the same way as service
Note that, typically, the PPC will be triggered by the Volume A, i.e. that they belong to the same rating group, namely the one
Threshold. However, it is possible that, during period r2, with Rating-Group-ID=1. Since this rating group has been effectively
insufficient traffic is generated and thus the threshold is not authorised by the allocation of quota with QID=7, the PPC provides
reached. Even in this case PPC MUST generate an Access-Request in service B to the user immediately. It is rated in the same way as
good time. Also note that separate services flows may have service A, i.e. for every second provided, 1747.63 units are
individual tariff periods. subtracted from credit pool 1.
10.7 At some point in time, resource pool 1 is close to exhaustion. (For
Support for Roaming 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,
the PPC needs to ask for replenishment for the pool. Suppose that,
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.
Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304
+ 5767179 = 9961483 abstract service units from the pool. The PPC
constructs an Authorize Only Access Request message that reports the
usage for the "access service" and "service A". This message
contains two PPAQ AVPS, is sent to the home AAA server (14) and
forwarded to the PPS (15). Note that is the message it appears that
"service A" has consumed more than it was allocated (i.e. 55 minutes
although only 50 minutes were initially allocated to it). This is
not a a problem since the PPS knows that "service A" was drawing from
the same pool as the "access service" and that the "access service"
did only consume 4 out of the 5 MB it was allocated.
In certain networks it is essential for prepaid data services to be Upon reception of message (15), the PPS subtracts 4 euros from the
available to roaming subscribers. Support for both static and user's account for the "access service" and another 5.5 euros for
dynamic roaming models is needed. In a static roaming scenario the "service A". (This includes the charge incurred by "service B" up to
subscriber connects to a foreign network which has a roaming that point in time, although the PPS is not aware of "service B"
agreement either directly with the home network, or through a broker being provisioned to the user.) The PPS then determines that
network. When the subscriber logs into another foreign network, a sufficient funds remain in the prepaid account in order for both
new login procedure has to be executed. services to be continued. The PPS decides to reserve another 3MB for
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
cumulative manner, the PPAQ attribute that grants the quota for the
"access service" contains a Volume-Quota AVP of 8MB (8388608 octets),
which is the 5MB that were initially allocated, plus the 3MB
allocated now. The resource pool identifier is, as previously,
PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants
quota for "service A" contains 4800 seconds (the initial 3000 plus
1800 that correspond to the 30 additional minutes). Again, the
PoolID=1 and multiplier=1747.63. The resulting Access Response
message is sent to the home AAA server (16) and forwarded to the PPC
(17).
In a dynamic roaming scenario the subscriber may move between When the PPC received message (17) it checks how much quota has been
networks while maintaining his connection. In such a scenario the allocated previously to the "access service". It finds that the
data session is seamlessly handed off between the networks. answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets)
that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets)
have not yet been added to resource pool 1. The PPC thus adds
3145728 abstract units to resource pool 1 (since the multiplier is
1). The PPC then acts similarly on the other PPAQ attribute that
exists in message (17). That is, the PPC determines that 3000
seconds of quota for "service A" had already been added to the pool.
Thus only 1800 out of the 4800 should be additionally added to the
pool. Since the applicable multiplier here is 1747.63, the PPC adds
further 3145734 abstract units to the pool 1.
In both roaming scenarios, the subscriber always authenticates The PPC then continues to provide the access service, "service A" and
himself to the home network. Authorization for the prepaid session "service B" to the user, and meters them against the pool, as
and quota replenishing occurs at the home network and more previously.
specifically at the prepaid system where state is being maintained.
Dynamic roaming is challenging because a subscriber who established At some point the user logs off (18). The PPC must then report how
a prepaid data session may move to another Access Device that does many resources were consumed, so that the PPC can subtract the
not support the prepaid functionality. Even in this case the system appropriate monetary amount from the user's prepaid account. To this
should be able to continue the prepaid session. end the PPC constructs an Authorize Only Access Request message with
two PPAQ AVPs; one for the access service and one for "service A".
Suppose that, in total, 6.5MB were consumed by the access service, 70
minutes were consumed by "service A" and 20 minutes by "service B".
The PPC reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds)
in its final message (19). This is forwarded to the PPS which
determines, from the previous records, that the access service
consumed another 2.5MB (since 4MB out of the 6.5MB were already
reported in message (15), and that "service A" consumed further 600
seconds. This corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros.
Thus, the PPS only subtracts 2.5 out of the 6 previously reserved
euros from the user's prepaid account and responds with an Access
Response as required by the RADIUS base specification.
10.8 The home AAA server likewise responds with an Access Response.
Termination of a prepaid session
When fraud or an error is detected, the either only the affected Authors' Addresses
session, or all sessions of the affected subscriber should be
terminated.
It may happen that the prepaid system enters a state where it is Avi Lior
unclear whether or not the data session is in progress. Under such a Bridgewater Systems
condition, the system may wish to terminate the session in order to 303 Terry Fox Drive
make sure that the user is not billed for this potential inactivity. Ottawa, Ontario Suite 100
Canada
Certain handoff procedures used in dynamic roaming scenarios require Email: avi@bridgewatersystems.com
that the system terminates the subscribers prepaid data session at a
SAD. This is the case, for example, when time-based prepaid is used
and the mobile subscriber performs a dormant handoff.
10.9 Parviz Yegani
Querying and Rebalancing Prepaid Resources Cisco
Mobile Wireless Group, Cisco Systems
3625 Cisco Way, San Jose, California 95134
USA
It should be possible for the PPS to Query the current resource Email: pyegani@cisco.com
consumption at a SAD and adjust the userÆs account balance.
For example, a request to the PPS is made (e.g. a one-time charging Kuntal Chowdhury
event) but the userÆs account is depleted but resources have been Starent Networks
allocated to the SAD. The PPS should have the ability to query the 30 International Place, 3rd Floor
SAD and if it has the spare resources to reassign the quotas to the Tewksbury, MA 01876
SAD and to the pending request. Note that the PPS doesnÆt know USA
resource usage 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 Email: kchowdhury@starentnetworks.com
this phenomenon by allocating small quotas û a practice that
results in more message exchanges. Hannes Tschofenig
Siemens
Otto-Hahn Ring 6
Munich, Bavaria 81739
Germany
Email: hannes.tschofenig@siemens.com
Andreas Pashalidis
Siemens
Otto-Hahn Ring 6
Munich, Bavaria 81739
Germany
Email: andreas.pashalidis@siemens.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 396 change blocks. 
1668 lines changed or deleted 2372 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/