< draft-lior-radius-prepaid-extensions-07.txt   draft-lior-radius-prepaid-extensions-08.txt >
Network Working Group A. Lior Network Working Group A. Lior
INTERNET-DRAFT Bridgewater Systems INTERNET-DRAFT Bridgewater Systems
Category: Informational P. Yegani Category: Informational P. Yegani
draft-lior-radius-prepaid-extensions-07.txt Cisco draft-lior-radius-prepaid-extensions-08.txt Cisco
Expires: 20 July, 2005 K. Chowdhury Expires: 18 January, 2006 K. Chowdhury
Starent Networks Starent Networks
Y. Li H. Tschofenig
Bridgewater Systems
C. Guenther C. Guenther
Siemens Siemens
February 20, 2005 July 17, 2005
PrePaid Extensions to Remote Authentication Dial-In User Service PrePaid Extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance have been or will be disclosed, and any of which he or she becomes
with RFC 3668. 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 and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference 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 July 20, 2005 This Internet-Draft will expire on December 29, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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...................................................4
1.1 Terminology................................................6 1.1 Terminology................................................5
1.2 Requirements language......................................6 1.2 Requirements language......................................5
2. Overview.......................................................6 2. Overview.......................................................6
2.1 PrePaid Charging Model.....................................7 2.1 Prepaid Charging Models....................................6
2.2 Architectural Model........................................7 2.2 Architectural Model........................................6
2.3 Why not existing RADIUS attributes?.......................13 2.3 Motivation................................................11
3. Use-cases.....................................................15 3. Operations....................................................13
3.1 Simple pre-paid access use-case...........................15 3.1 General Requirements......................................13
3.2 Support for Multi-Services................................17 3.1.1 Broker AAA Requirements..............................13
3.3 Resource Pools............................................18 3.2 Authentication and Authorization for Prepaid Enabled SADs.14
3.4 Support for Complex Rating Functions......................20 3.3 Session Start Operation...................................16
3.5 One-Time-based Prepaid Charging...........................21 3.4 Mid-Session Operation.....................................16
3.6 Support for Tariff Switching..............................22 3.5 Dynamic Operations........................................18
3.7 Support for Roaming.......................................24 3.5.1 Unsolicited Session Termination Operation............19
3.8 PrePaid termination.......................................24 3.5.2 Unsolicited Change of Authorization Operation........19
3.9 Querying and Rebalancing Prepaid Resources................25 3.6 Termination Operation.....................................20
4. Operations....................................................25 3.7 Mobile IP Operations......................................20
4.1 General Requirements......................................25 3.8 Operation considerations for Multiple prepaid services....21
4.1.1 Broker AAA Requirements..............................25 3.8.1 Initial Quota Request................................22
4.2 Authentication and Authorization for Prepaid Enabled SADs.26 3.8.2 Quota Update.........................................22
4.3 Session Start Operation...................................28 3.8.3 Termination..........................................23
4.4 Mid-Session Operation.....................................29 3.8.4 Dynamic Operations...................................23
4.5 Dynamic Operations........................................31 3.8.5 Support for Resource Pools...........................23
4.5.1 Unsolicited Session Termination Operation............31 3.8.6 One-Time-Charging....................................24
4.5.2 Unsolicited Change of Authorization Operation........32 3.8.7 Error Handling.......................................24
4.6 Termination Operation.....................................32 3.9 Accounting Considerations.................................25
4.7 Mobile IP Operations......................................33 3.10 SAD Operation............................................25
4.8 Operation consideration for Multi-Services................34 3.11 Interoperability with Diameter Credit Control Application25
4.8.1 Initial Quota Request................................34 4. Attributes....................................................25
4.8.2 Quota Update.........................................35 4.1 PPAC Attribute............................................26
4.8.3 Termination..........................................35 4.2 Session Termination Capability............................27
4.8.4 Dynamic Operations...................................36 4.3 PPAQ Attribute............................................27
4.8.5 Support for Resource Pools...........................36 4.4 Prepaid Tariff Switching (PTS)............................34
4.8.6 One-Time-Charging....................................36 4.5 Table of Attributes.......................................36
4.8.7 Error Handling.......................................37 5. Security Considerations.......................................37
4.9 Accounting Considerations.................................38 5.1 Authentication and Authorization..........................37
4.10 SAD Operation............................................38 5.2 Replenishing Procedure....................................37
4.11 Interoperability with Diameter Credit Control Application38 6. IANA Considerations...........................................37
5. Attributes....................................................38 7. Normative References..........................................38
5.1 PPAC Attribute............................................39 8. Informative References........................................39
5.2 Session Termination Capability............................40 9. Call Flows....................................................39
5.3 PPAQ Attribute............................................40 9.1 Simple Concurrent Services................................40
5.4 Prepaid Tariff Switching (PTS)............................46 9.2 One-time Charging.........................................43
5.5 Table of Attributes.......................................49 Contributor......................................................43
6. Security Considerations.......................................49 Acknowledgments..................................................43
6.1 Authentication and Authorization..........................49 Author's Addresses...............................................43
6.2 Replenishing Procedure....................................50 Intellectual Property Statement..................................44
7. IANA Considerations...........................................50 Disclaimer of Validity...........................................44
8. Normative References..........................................51 Copyright Statement..............................................45
9. Informative References........................................51 Expiration Date..................................................45
10. Call Flows...................................................52 10. Appendix A û use cases.......................................45
10.1 Simple Concurrent Services...............................53 10.1 Simple prepaid use case..................................45
10.2 One-time Charging........................................55 10.2 Support for Multi-Services...............................47
Contributor......................................................56 10.3 Resource Pools...........................................48
Acknowledgments..................................................56 10.4 Support for Complex Rating Functions.....................49
Author's Addresses...............................................56 10.5 One-Time-based Charging..................................50
Intellectual Property Statement..................................57 10.6 Support for Tariff Switching.............................51
Disclaimer of Validity...........................................57 10.7 Support for Roaming......................................53
Copyright Statement..............................................57 10.8 Termination of a prepaid session.........................53
Expiration Date..................................................58 10.9 Querying and Rebalancing Prepaid Resources...............54
1. 1.
Introduction Introduction
This draft describes RADIUS protocol extensions supporting charging This draft describes extensions for the RADIUS protocol. These
for PrePaid Data Services. extensions are meant to enable service providers to charge and bill
their customers using prepaid accounts.
PrePaid data services are cropping up in many wireless and wireline
based networks. A PrePaid Data Service subscriber is one that
purchases a contract to receive a data service for either a period
of time, or a quantity of data. Before providing a prepaid data
service, the service provider checks that the prepaid subscriber has
sufficient funds to cover the particular service request. Only after
confirmation that funds are available is the service provided to the
user.
The subscriber purchases the Data Service using various means such
as buying a PrePaid Card, or online. How the subscriber purchases
their PrePaid Data Service depends on the deployment and is not in
scope for this document.
In some deployments, the PrePaid data service will be combined with
other Prepaid services such as PrePaid circuit voice service. This
is not an issue for this document other than the fact that the
PrePaid Data Services described in this paper should work with other
PrePaid data and or circuit voice services.
The fundamental business driver for a carrier to provide PrePaid A prepaid service subscriber is a user who has purchased a contract
data services is to increase participation (subscriber base) and according to which he will receive a particular data service for
thus to increase revenues. Therefore, it makes sense that PrePaid either a period of time or a quantity of data. In the typical
services meet the following goals: prepaid scenario, the service provider verifies that the subscriber
has sufficient funds in his account before delivering the service.
Only if sufficient funds are available is the service provided to
the user.
- Leverage existing infrastructure, hence reducing capital Note that the means by which the subscriber obtains funds is outside
expenditures typically required when rolling out a new service; the scope of this document. Also note that, in some scenarios, the
- Ability to rate service requests in real-time; subscriber's account may be used to fund multiple services, some of
- Ability to check that the end userÆs account for coverage for the which may use the extensions defined in this documents, and some
requested service charge prior to execution of that service; may use other mechanisms. While the interworking of the mechanisms
- Protect against revenue loss, i.e., prevent an end user from described in this document with other mechanisms should be possible
generating chargeable events when the credit of that account is and straightforward, how this could be done depends on the external
exhausted or expired; mechanisms and is, as such, outside the scope of this
- Protect against fraud; document.
- Be as widely deployable over Dialup, Wireless and WLAN networks.
The protocol described in this document maximizes existing The business driver behind the protocol extensions defined in this
infrastructure as much as possible û hence the use of the RADIUS document is to increase participation (i.e. a service provider's
protocol. The protocol is used in ways to protect against revenue subscriber base) and thus to increase revenues. In particular, the
loss or revenue leakage. This is achieved by defining procedures extensions were designed with the following goals in mind.
for the real-time delivery of service information to a pre-paid
enabled AAA server, to minimize the financial risk, for the pre-paid
enabled AAA server to be able to allocate small quotas to each data
session and having the ability to update the quotas from a central
quota server dynamically during the lifetime of the PrePaid data
session. As well, mechanisms have been designed to be able to
recover from errors that occur from time to time.
Protection against fraud is provided by recording of accounting - Make use of existing infrastructure as much as possible, and
records, and by providing mechanisms to thwart replay attacks. As thereby limit the amount of necessary capital expenditures,
well, mechanisms have been provided to terminate data sessions when - provide the ability to rate service requests in real-time,</t>
fraud is detected. - provide the ability to charge the user's account - charge prior to
service provision,
- protect against revenue loss, i.e. prevent an end user from
obtaining service when the available funds are not sufficient,
- protect against fraud, and
- be as widely deployable over dialup, wireless and WLAN networks.
PrePaid Systems will become more prevalent and sophisticated as the The architecture between the entities that execute the RADIUS
various networks such as Dialup, Wireless and WLAN converge. This protocols with the extensions defined in this document assumes that
protocol extension is designed to meet the challenges of converged rating of chargeable events does not occur in the element
networks. The draft mainly addresses how to use the RADIUS protocol that provides the service. Instead, the rating may be performed at a
to achieve a PrePaid Data Service. The prepaid architecture assumes dedicated server, termed the ôprepaid enabled AAA serverö or simply
that rating of chargeable events does not occur in the element ôprepaid serverö. Alternatively, the actual rating may occur in an
providing the service. This rating could be performed in the prepaid entity behind this prepaid server. Furthermore, business logic may
enabled AAA server or may exist in an entity behind this AAA server. dictate a time-dependent tariff model, for example that the price
Business logic and service rules may define that tariffing of events for a service may switch at 8pm from a high to a low tariff. The
vary in time, e.g., the particular price per megabyte download may extensions defined in this document support such scenarios.
be defined to switch at 8pm from a high tariff to a low tariff. The
RADIUS extensions for prepaid support scenarios enable scalable
implementation of tariff switched prepaid systems.
Furthermore, the prepaid architecture assumes that a quota server is Furthermore, this documents assumes an architecture where a `quota
available which, through co-ordination with the rating entity and server' is available which, through co-ordination with the rating
centralized balance manager is able to provide a quota response in entity and a centralized account balance manager, is able to
response for prepaid data service. This quota server functionality provide a quota indication for a particular user when requested.
could be performed in the prepaid enabled AAA server or may exist in This quota server may or may not coexist in the prepaid server.
an entity behind this AAA server. Finally, the details of the
PrePaid System, such as its persistent store, how it maintains its
accounts are not covered at all. However, in order to define the
RADIUS protocol extensions it is necessary to discuss the functional
behavior of the PrePaid System.
1.1 1.1
Terminology Terminology
Service Access Device Network Access Server As in RADIUS.
PrePaid Client(PPC) The Prepaid Client (PPC) is the entity which (NAS)
triggers the RADIUS message exchange Prepaid Client(PPC) The entity which triggers the RADIUS message
including prepaid extensions defined in this exchange including prepaid extensions
document. Typically the Prepaid Client defined in this document. The PPC typically
Resides in the NAS. resides in the NAS.
PrePaid Server(PPS) The Prepaid Server is the entity that Prepaid Server(PPS) The entity that interacts with the Prepaid
interacts with the Prepaid Client using the Client using the RADIUS prepaid extensions
RADIUS prepaid extensions defined in this defined in this document.
document. Home network The entity which maintains the userÆs
Home network The network which contains the user profile profile and prepaid account.
and the userÆs prepaid account.
WLAN Wireless Local Area Network WLAN Wireless Local Area Network
Service Event Service Event
Access Service The service that is provided to the user Access Service The service that is provided to the user
when the user is authenticated and when the user is authenticated and
authorized. In this document the term is authorized.
used to differentiate between authorization
of services that are explicitly identified
by a Service Identifier. Example of Access
Service would be the Main Service instance
of 3GPP2.
Furthermore, we use the following Mobile IP and AAA terminology: Furthermore, the following terms are used in this document. Mobile
Home agent (HA), Home network, Home AAA (HAAA), Broker AAA (BAAA), IP and AAA terminology: Home agent (HA), Home network, Home AAA
Visited AAA (VAAA) and Foreign Agent (FA) (HAAA), Broker AAA (BAAA), Visited AAA (VAAA) and Foreign Agent (FA)
1.2 1.2
Requirements language Requirements language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
2. 2.
Overview Overview
This section gives a concise overview of the Prepaid Charging models This section provides an overview of the prepaid charging models,
that is supported by this document, and the Architectural model and their associated architectures, that are supported by the
relevant to this draft. extensions proposed in this document.
2.1 2.1
PrePaid Charging Model Prepaid Charging Models
There are several PrePaid Charging models of how to charge customers A number of models of how to charge customers for data services in a
for availing data services: prepaid manner are supported, as follows.
. Volume-based charging (VBC): (e.g., 2 Cents/KiloByte); . Volume-based charging (VBC): (e.g. 2 Cents/KiloByte)
. Duration-based charging (DBC): (e.g., 3 Cents/minute); . Duration-based charging (DBC): (e.g. 3 Cents/minute)
. Subscription-based charging (SBC): (e.g., . Subscription-based charging (SBC): (e.g. Dollars/month)
Dollars/month+service);), . Event-based charging (EBC): (e.g. 7 Cents/URL or email)
. Event-based charging (EBC): (e.g., 7 Cents/URL or email).
Charging models can be further divided into those with debiting of Whether the user account is a dedicated prepaid account or a general
prepaid user accounts and those with debiting of non-prepaid account (such as a current bank account) is outside the scope of
accounts (such as current accounts at banks). From the perspective this document.
of this document all userÆs as treated as userÆs having a prepaid
accounts.
2.2 2.2
Architectural Model Architectural Model
The architectural model supports prepaid clients on a service access The architectural model assumed in this document encompasses the
device. A SAD (e.g. a NAS) typically provides a access to data following entities.
service to end-users. A SAD is a network entity on the data path
that includes a RADIUS client and a PrePaid Client.
When prepaid service is used the SAD collects service event
information and reports it while and/or after services are provided
to the prepaid user. This event information is sent to a prepaid
server by using the prepaid RADIUS extensions.
If real-time credit control is required, the SAD (prepaid client)
contacts the prepaid server with service event information included
before the service is provided. The prepaid server, depending on the
service event information, performs credit check and allocates a
portion of available credit to the service event. The rating entity
converts this credit value into a time and/or volume amount, which
is then returned to the requesting SAD. The rating entity may
determine that during the allocated quota, a tariff switch will
occur in which case the rating entity will include details of the
quota allocated prior to the tariff switch, details of the quota
allocated after the tariff switch together with details of when the
tariff switch will occur.
The requesting SAD then monitors service execution according to the (1) Service Access Device (SAD): This entity provides a data
instructions returned by the prepaid server. After service service to the users, and typically coincides with the NAS. The
completion or on a subsequent request for service, the prepaid SAD executes the RADIUS client which, for the purposes of this
server deducts the reserved allocation of credit from the prepaid document, is termed the PPC. When prepaid service is used the
userÆs account. 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.
(2) The PPS: The RADUIS server. 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.
(3) 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.
Similarly, when a user terminates an on-going prepaid service, the The requesting SAD (PPC) monitors the provision of the service
prepaid client signals the prepaid server with the a value according to the instructions returned by the PPS. After service
corresponding to the unused portion of the allocated quota. The completion or on a subsequent request for service, the PPS deducts
prepaid server is then able to refund unused allocated funds into a the corresponding amount of credit from the user account. When a
userÆs prepaid account. user terminates an on-going service, the PPC informs the PPS with a
suitable indication about the unused portion of the allocated quota.
The PPS is then able to refund the user account appropriately.
There MAY be multiple prepaid servers in the system for reasons of Multiple PPSs MAY be deployed for reasons of redundancy and load
redundancy and load balancing. The system MAY also contain separate balancing. The system MAY also employ multiple rating servers.
rating server(s) and accounts MAY be located in a centralized Prepaid accounts MAY be located in a centralized database. The
database. System internal interfaces can exist to relay messages detailed architecture of the system and its interfaces are outside
between servers and an account manager. However the detailed the scope of this specification.
architecture of prepaid system and its interfaces are implementation
specific and are out of scope of this specification.
accounting accounting
+------------+ +-----------+ protocol +--------------+ +------------+ +-----------+ protocol +--------------+
| Subscriber |<----->| Service | | | | User |<----->| Service | | |
| | | Access |<------------>| Accounting | | | | Access |<------------>| Accounting |
| Device | | Device |<-----+ | Server | | Device | | Device |<-----+ | Server |
+------------+ +-----------+ | +--------------+ +------------+ +-----------+ | +--------------+
| (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
entities. The real configuration MAY combine them into a single
host.
The prepaid server and accounting server in this architecture model The SAD MUST have the ability to meter the usage for a prepaid data
are logical entities. The real configuration MAY combine them into a session. This usage includes time or volume (e.g. number of bytes).
single host.
There MAY exist protocol transparent RADIUS Proxies between prepaid
client and prepaid server. These proxies transparently support the
prepaid RADIUS extensions.
In order to generalize the solution, in this paper we generalize the
SADs, which in reality may be a NAS in Dialup deployments, PDSN
(Packet Data Serving Node) or HA (Home Agent) in CDMA2000
deployments, an 802.11 WLAN Access Points or GGSN (Gateway GPRS
Serving Node) in GPRS/UMTS deployments. To actively participate in
Prepaid procedures outlined here, the SAD MUST have the Prepaid
Client capabilities. Prepaid Client Capabilities include the
ability to meter the usage for a prepaid data session; this usage
includes time or volume (e.g. number of bytes) usage.
In the case of roaming scenarios using mobile IP (in a wireless or
wireline network), the prepaid client functionality may be delegated
to the Home Agent. It may also be possible to deliver limited
prepaid services using RADIUS capabilities specified in RFC2865 and
RFC2866.
Furthermore, the device including the prepaid client functionality
may also have Dynamic Session Capabilities that include the ability
to terminate a data session and/or change the filters associated
with a specific data session by processing Disconnect Messages and
Change of Authorization messages as per [RFC3576].
In this document RADIUS is used as the AAA server. There are three In roaming scenarios using mobile IP the PPC may run on the Home
kinds or categories of AAA servers. The AAA server in the home Agent. Furthermore, the device running the PPC may also have
network, the HAAA, is responsible for authentication of the ôDynamic Session Capabilitiesö such as the ability to terminate a
subscriber and also authorization of the service. In addition, the data session or change the filters associated with a specific data
HAAA communicates with the Prepaid servers using the RADIUS protocol session by processing ôDisconnectö messages and ôChange of
to authorize prepaid subscribers. In AAA based roaming deployments Authorizationö messages as per [RFC3576].
the AAA server in the visited network, the VAAA, is responsible for
forwarding the RADIUS messages to the HAAA. The VAAA may also
modify the messages. In roaming deployments, the visited network
may be separated from the home network by one or more broker
networks. The AAA servers in the broker networks, BAAA are
responsible to route the RADIUS packets transparently and hence
donÆt play an active roll in the Prepaid Data Service delivery.
In this document the Prepaid Server is described in functional terms This document assumes that the PPS is used as the AAA server. There
related to their interface with the HAAA. The Prepaid Server are three types of AAA server, as follows. (i) The AAA server in the
interfaces to entities which: 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.
i) Keep the accounting state of the prepaid subscribers (balance This document assumes that the PPS communicates with the HAAA for
manager); the purposes of authorisation. Additionally, the PPS interfaces to
entities which
ii) Allow access service requests to be rated in real-time (Rating - Keep the subscriberÆs account balance (balance manager),
Engine); and - Rate access service requests in real-time (Rating Engine), and
iii) Allow quota to be managed for a particular pre-paid service - Manage quota for a particular prepaid service (Quota Server).
(Quota Server).
The various deployments for Prepaid are presented in the remainder Three deployment scenarios are presented in the remainder of this
of this section. The first deployment is the basic Prepaid data section. The first scenario is depicted in Figure 2. In this
service and is depicted in figure 2. The SAD, which supports the scenario, the SAD, which runs the PPC, the HAAA, and the PPS are
prepaid client functionality, the HAAA and the Prepaid Server are located in the same provider network.
collocated in the same provider network.
The Subscriber Device establishes a connection with one of several The Subscriber Device establishes a connection with one of possibly
Access Devices in the network. The SAD communicates with one or multiple SADs in the network. The selected SAD communicates with a
more HAAA servers in the network. To provide redundancy more than HAAA server. However, in order to provide redundancy, multiple HAAA
one HAAA may be available to use by a SAD. may be available.
The network will have one or more Prepaid Servers. Multiple Prepaid The network has one or more PPSs. The interface between the HAAA and
Servers may be used to provide redundancy and load sharing. The the PPS is implemented using the RADIUS protocol together with the
interface between the HAAA and the PPS is implemented using the extensions described in this document. However, in cases where the
RADIUS protocol in this specification. However, in cases where the
PPS does not implement the RADIUS protocol, the implementation would PPS does not implement the RADIUS protocol, the implementation would
have to map the requirements defined in this document to whatever have to map the requirements defined in this document to a
protocol is used between the HAAA and the PPS. functionally equivalent protocol.
+------+ +-----+ +------+ +-----+
| | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | | | | | | | | | | | |
| Sub | | 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
Figure 3 shows a static roaming prepaid architecture that is typical The second scenario, depicted in Figure 3, is based on a static
of a wholesale scenario for Dial-Up users or a broker scenario used roaming architecture that is typical of a wholesale scenario for
in Dial-Up or WLAN roaming scenarios. Dial-Up users or a broker scenario used in Dial-Up or WLAN roaming
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 | | Visited | |Broker | | Home |
| Network | |Network| | Network | | 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 As in the basic prepaid architecture the subscriberÆs device
establishes a connection with the SAD (NAS, WLAN Access Point). establishes a connection with the SAD. The SAD communicates with the
The SAD communicates with the Visiting AAA server (VAAA) using the VAAA using the RADIUS protocol. The VAAA, in turn, communicates
RADIUS protocol. Again for redundancy there maybe more then one using the RADIUS protocol with BAAA servers in the broker network.
VAAA. The VAAA communicate using the RADIUS protocol with AAA There maybe more then one Broker Network between the Visited Network
servers in the broker network (BAAA). There maybe more then one and the Home Network. The Home Network is the same as in the
Broker Network between the Visited Network and the Home Network. architecture depicted in Figure 2.
The Home Network is the same as in the simple architecture.
To support dynamic roaming the network will utilize Mobile-Ip as The third scenario is a roaming scenario where the network utilises
illustrated in Figure 4. Note that typically the mobile device Mobile-IP. It is depicted Figure 4. In this scenario the mobile
would be moving between networks that use the same technology such device moves between networks that use different technologies such
as Wireless or WLAN. Increasingly, device will be able to roam as between WLAN and Broadband. Mobile-IP addresses this type of
between networks that use different technology such as between WLAN mobility and therefore we need not be concerned with the underlying
and Wireless and Broadband. Fortunately, Mobile-Ip can address this network technology.
type of roaming and therefore we need not be concerned with the
underlying network technology.
+------+ +-------+ +----+ +----+ +----+ +-----+ +------+ +-------+ +----+ +----+ +----+ +-----+
| | |Service| | | | | | | | | | | |Service| | | | | | | | |
|Sub | |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS | |Subscr| |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS |
| |--|Device | | | | | | | | | | |--|Device | | | | | | | | |
|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
| | | | | | | | | | | |
+------+ +------ + | | +------+ +------ + | |
| | | +----+ | | | +----+
| | | | | | | | | |
|ROAMS +------------------+ HA | |ROAMS +------------------+ HA |
| | | | | | | |
V +----+ | +----+ V +----+ | +----+
+------+ +-------+ | | | | +------+ +-------+ | | | |
| | |Service| +-|VAAA+------+ | | | |Service| +-|VAAA+------+ |
|Sub | |Access | | | | | |Subscr| |Access | | | | |
| |--|Device +-+ +----+ | | |--|Device +-+ +----+ |
|Device| | (FA) | | |Device| | (FA) | |
| | | +------------------------+ | | | +------------------------+
+------+ +-------+ +------+ +-------+
Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs
In figure 4, the Subscriber device establishes a prepaid session In Figure 4, the Subscriber Device establishes a session with the
between the SAD in the foreign network, which has prepaid SAD in the foreign network. The setup for this access service is
capabilities. The subscriberÆs home address will be anchored at the identical to the cases covered above. Note that the SAD may be
Home Agent (HA) in the home network. The setup for this access collocated with the Foreign Agent (FA) if Mobile-IPv4 is being used.
service is identical to the cases covered above. Notice that the As the subscriber device moves, it establishes a connection with
SAD may be collocated with the Foreign Agent (FA) in case of Mobile- another SAD possibly in another foreign network. The prepaid data
IPv4. As the subscriber device moves it establishes a connection service should continue to be available. When a device associates to
with another SAD in the same foreign network or in another foreign another SAD it MUST re-authenticate at the new SAD and de-associate
network. The prepaid data service should continue to be available. or log off from the old SAD. Furthermore, any unused quota at the
When a device associates to another SAD it MUST re-authenticate at old SAD MUST be credited into the subscriberÆs account immediately.
the new SAD and de-associate or logoff from the old SAD. This has to happen immediately because otherwise, if the
Furthermore, any unused quota at the old SAD MUST be promptly subscriberÆs funds are low, he may be denied service at the new SAD.
credited back to the subscribers account. The reason we say
promptly, is because if the subscriber is very low on resources to
start with, the subscriber may not have enough resources to log on
to the new SAD. The speed at which resources can be returned depend
on the type of handoff procedure that is used. Some of the example
of handoffs in wireless networks are dormant handoff, active handoff
and fast handoff.
As well, notice that if the SADs could communicate with each other
then there could be a way to accelerate a faster handoff procedure.
In particular, it could accelerate the return of the unused portion
of the quotas from the old Access Device.
Unfortunately, standards with regards to handoff are evolving with Note that, if the SADs communicate directly with each other then
each network technology creating their own scheme to make the there could be a way to accelerate the handoff procedure. In
handoff procedures more efficient. particular, the subscriber could be refunded more quickly.
Unfortunately, handoff procedures are specific to the underlying
network technologies and vary significantly in terms of delay.
2.3 2.3
Why not existing RADIUS attributes? Motivation
It has been asked ôWhy not use existing RADIUS attributes to build a It has been asked ôWhy not use existing RADIUS attributes to
prepaid solution? This will allow us to have a solution with construct a protocol for prepaid scenarios? This will allow us to
existing devices without code modification.ö have a solution with existing devices without code modification.ö
It is possible to build a prepaid solution using existing RADIUS It is indeed possible to construct a solution for prepaid billing
attributes. The RADIUS server can simply send an Access-Accept scenarios using existing RADIUS attributes. The RADIUS server would
message containing Session-Timeout(27) and set Termination- send an Access-Accept message containing a Session-Timeout(27) and
Action(29) to RADIUS-request. Upon receiving the Access-Accept include a Termination-Action(29) in the RADIUS-request. Upon
message, the NAS will meter the duration of the session and upon receiving the Access-Accept message, the NAS would meter the
termination of the session the NAS generate an Access-Request duration of the session and upon termination of the session the NAS
message again. The RADIUS server would re-authenticate the session would generate an Access-Request message again. The RADIUS server
and reply with an Access-Accept message with additional time in would then re-authenticate the session and reply with an Access-
Session-Timeout(27) or an Access-Reject message if there were no Accept message indicating the amount of additional time in a
more resources in the userÆs account. Session-Timeout(27). Alternatively, it would responds with an
Access-Reject message if there were no more resources in the userÆs
account.
If the user terminates the session before the time expressed in Moreover, if the user terminates the session prematurely, the NAS
Session-Timeout(27). The NAS will recover any unused time from the would recover any unused time from the accounting stream.
accounting stream.
There are several problems with such a solution: There are several problems with such a solution:
-It only allows for time-based prepaid. The solution presented in - It only supports time-based accounting. The solution presented in
this document allows for both time and volume based prepaid. As this document supports both time and volume based prepaid.
well as extensibility for other features such as tarified based
solutions.
-Using accounting messages to recoup unused time may be problematic - Using accounting messages to recoup unused time may be problematic
because RADIUS accounting messages are not real-time. A RADIUS because RADIUS accounting messages are not delivered in real-time.
server may store-and-forward accounting messages in batches. The A RADIUS server may store-and-forward accounting messages in
solution presented in this paper does not rely on Accounting Packets batches. The solution presented in this document does not rely on
at all. It uses Access-Request, messages which do flow through any Accounting Packets at all. It uses Access-Request, messages which do
network in real-time. Delaying accounting messages may cause flow through any network in real-time. Delaying accounting messages
revenue leakage. may cause revenue leakage.
-Session-Timeout(27) is not a mandatory attribute. If a prepaid - 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 will obtain unlimited service. Session-Timeout then that subscriber may use the service for an
undetermined period of time.
-Termination-Action(29) presents its own issues. First the - Termination-Action(29) presents its own issues. Firstly the
behaviour of Termination-Action(29) is not mandatory. Second, behaviour of Termination-Action(29) is not mandatory. Secondly,
according to RFC2865 Termination-Action fires when the Service is according to RFC2865, Termination-Action fires when the provision of
complete. But we should not be terminating the service while the service has completed. However, service should not be terminated
negotiating additional quota. The refreshing of the time quota when negotiating additional quota, because this should happen in a
should be transparent to the user. Because Termination-Action manner transparent to the subscriber. Because Termination-Action
occurs when the Service is complete it is unclear whether or not the occurs when the Service is completed it is unclear whether or not
user experience would be transparent. For example, will the RADIUS user experience would be affected. The RADIUS server might even
server allocate the subscriber a new IP address? Furthermore, the allocate a new IP address to the subscriberÆs device. Furthermore,
RADIUS server has no way of telling why the Access-Request message the RADIUS server has no way of telling why the Access-Request
was generated. The RADIUS server will have to wait for the message was generated. The RADIUS server might have to wait for the
corresponding accounting packet to determine the reason for this corresponding accounting packet to determine the reason for this
Access-Request message. Lastly re-authenticating the subscriber may Access-Request message. Finally, re-authenticating the subscriber
take far too long. The solution presented in this document allows may take too long. The solution presented in this document allows
quota replenishing to occur in an undisruptive manner from the quota replenishing to occur in an undisruptive manner from the user
perspective of the user. No re-authentication is required and perspective. No re-authentication is required and quotas can be
quotas can be negotiated prior to the quotas running out. negotiated prior to the available credit running out.
-Prepaid ambiguity. Implementing prepaid using existing RADIUS
attributes presents another problem. Due to the fact that the
standard RADIUS attributes are not mandatory, then the correct
prepaid operation is really an act of faith on the part of the
RADIUS server. If Session-Timeout(27) and/or Termination-Action(29)
are not supported, the prepaid subscriber will get free access. The
solution described in this document, requires that a prepaid capable
SAD inform the RADIUS server whether or not it supports prepaid
capabilities. The RADIUS server can now determine whether service
should be granted or not. For example, if a prepaid subscriber is
connected to a NAS that does not support prepaid, the RADIUS server
can either instruct the NAS to tunnel the traffic to another entity
in the home network that does support prepaid client function (e.g.
Home Agent) or it may allow the subscriber to get access but
restrict the traffic.
The prepaid solution we present is a robust carrier grade prepaid
solution. It only requires the support of 2 mandatory attributes
and one optional attribute. Furthermore, it does not really
require much code support at the NAS. NASes already support
measurement of time and volume. This solution requires that they
advertise their prepaid capabilities in an Access-Request; that they
generate an Access-Request Authorize-Only packet to obtain more
quota at or before the quota is used up. It also requires that the
NAS send an Access-Request with Authorize-Only when the session
terminates to return any unused quota to the prepaid system.
Lastly the solution provided in this document is extensible. This
document defines the basic exchanges between a prepaid capable NAS
and a RADIUS server. The protocol can easily be extended to support
tariff switching and other prepaid business models.
3.
Use-cases
In this section we present a set of use cases that help establish
the requirements needed to deliver PrePaid data services. These
use-cases donÆt address how the PrePaid account is established or
maintained. It is assumed that the PrePaid subscriber has obtained
a valid account from a service provider such as a wireless operator
or a WLAN operator.
To make the document as general as possible, the use cases cover the
experience from the SAD and not from the UserÆs Device. The
connection between the UserÆs Device, which typically involves
setting up a layer 2 session, e.g., PPP session or GPRS PDP Context,
is specific to a given network technology and the details are not
required to deliver a PrePaid service.
3.1
Simple pre-paid access use-case
A PrePaid subscriber connects to his home network. As usual, the
Access Device that is servicing the subscriber will use the AAA
infrastructure to authenticate and authorize the subscriber.
The SAD sends a RADIUS Access-Request to the AAA system to
authenticate the subscriber, and identify and authorize the service.
The Access-Request includes the subscriberÆs credentials and may
include the PrePaid capabilities of the SAD. PrePaid capabilities
MUST be included if the SAD supports PrePaid functionality.
The AAA System proceeds with the authentication procedure. This may
involve several transactions such as in EAP [RFC2284]. Once the
subscriber has been authenticated, the AAA system determines that
the subscriber is a PrePaid subscriber and requests that the PrePaid
System authorize the PrePaid subscriber. The request MUST include
the PrePaid Capabilities of the serving SAD.
The PrePaid System will validate that the subscriber has a PrePaid
Account; it will validate that the account is active; and will
validate that the SAD has the appropriate PrePaid capabilities. If
all is in order, the PrePaid System will authorize the subscriber to
use the network. Otherwise it will reject the request. The
response is sent back to the AAA System. The response includes
attributes to indicate the allocation of a portion of the
subscriberÆs account called the initial quota (in units of time or
volume) and optionally a threshold value.
The reason we allocate a portion of the userÆs account is that the
user may be engaged in other Services that may draw on the same
Prepaid 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 the involved separate parts of the
system. If the entire quota was allocated to the data session then
the user would have no more funds for a voice session.
The AAA system incorporates the PrePaid attributes received from the
PrePaid System into an Access-Accept message that it sends back to
the SAD. Note 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 allows the PrePaid data
session to start and it starts to meter the session based on time or
volume, as indicated in the returned Quota
Once the usage for the session approaches the allotted quota (as
expressed by the threshold), the SAD will request an additional
quota. The re-authorization for additional quota flows through the
AAA system to the PrePaid System. The PrePaid System revalidates
the subscriberÆs account; it will subtract the previous quota
allocation from the userÆs account balance and if there is a balance
remaining it will reauthorize the request with an additional quota
allotment. Otherwise, the PrePaid System will reject the request.
Note the replenishing of the quotas is a re-authorization procedure
and does not involve re-authentication of the subscriber.
It is important to note that the PrePaid System is maintaining
session state for the subscriber. This state includes how much
account balance was allocated during the last quota allocation for a
particular session and how much is left in the account. Therefore,
it is required that all subsequent messages about the PrePaid
session reach the correct PrePaid System.
Upon receiving a re-allotment of the quota, the SAD will, continue
the data service session until the new threshold is reached. If the
request for additional quota cannot be fulfilled then the SAD will
let the subscriber use up the remaining quota and terminate the
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 their account. This restriction can also be
used to allow new subscribers to purchase their initial PrePaid
Service.
Should the subscriber terminate the session before the quota is used
up, the remaining balance allotted to the session must be credited
back to the subscriberÆs account.
As well, while the Access Device is waiting for the initial quota,
the subscriber may have dropped the session. The initial quota must
be credited back to the subscribers account.
3.2
Support for Multi-Services
Up to now we were looking at session that consisted of a single
service, ôAccess Serviceö. An ôAccess Serviceö is the basic service
that is provided to the user by the SAD after successful
authentication and authorization. When we donÆt differentiate
between different types of services the ôAccess Serviceö aggregates
all the services that the user my be engaged in on a particular SAD.
For example, the user may be browsing the web, and participating in
a VoIP conversation, watching streaming video and downloading a
file.
Some operators may want to distinguish between these services. Some
services are billed at different rates and services maybe 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.
+---------+
| Session |
+---------+
|
V N
+--------------+ +-------+
| Service |------>| Quota |
| (service-Id) | +-------+
+--------------+
As shown in the above diagram, a Session can have 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 stand 5-tuple (Source-IP and Port,
the Destination-IP and Port, and the protocol type). Each service
is allocated an appropriate quota.
3.3
Resource Pools
When working with multiple services that results in multiple quota
allocation another problem arises. Even though quotas are portioned
out in fractional parts of the userÆs prepaid account, there could
be a situation where one Service utilizes its quota faster then
another Service. When the userÆs account is used up, there could be
a situation where one Service is unable to obtain additional quota
while another Service has plenty of quota remaining. Unless the
quotas can be rebalanced, the SAD would then have to terminate that
Service. As well, even before that happens, the existence of
several Services could generate an excessive amount of traffic as
the services update their quotas.
One method to solve these problems is to utilize resource pools.
Resource pools allow us to allocate resources to several 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 runs out, we replenish the
pool.
+-----------+
| Service-A |-----+ +--------+
+-----------+ | Ma | |
+-------->| |
| Pool |
+-------->| (1) |
+-----------+ | Mb | |
| Service-B |-----+ +--------+
+-----------+
As the figure above shows, 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 determines the rate
at which Service-A and Service-B draw from the pool.
The pool is initialized by taking the quota allocated to each
service and multiplying it by Mn. Therefore, the amount of
resources allocated to a pool is given by:
Poolr = Ma*Qa + Mb*Qb + . . .
A Pool is empty if:
Poolr <= Ca*Ma + Cb*Mb + . . .
where:
Ca,Cb are the consumed resources of Service-A and Service-B
respectively.
Note that the resources assigned to the pool are unit less. That
is, Service-A can be rated at $1 per Mbyte and Service-B can rated
at $0.10 per Minute. In this case if we allocate $5 worth of
resources on behalf of service-A to the pool we would set Ma = 10
and place 50 units into the pool. If we allocate $5 on 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.
3.4
Support for Complex Rating Functions
The rate of use of a resource by a service can be very complex.
Some services use resources (e.g. time, volume) linearly. For
example, a service maybe consuming resources at a rate of $1 per
Mbyte.
In some cases an operator may wish to apply a much more complex
rating function. 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. This rating function could be achieved by
repeated message exchanges with the Prepaid System.
To avert the need to exchange many messages and to support even more
complex rating functions we support Rating Groups. 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.
+-----------+
| Service-A |------+
+-----------+ | +--------------+ +-------+
+---->| | | Quota |
| Rating Group |------>| or |
+-----------+ +---->| | | Pool |
| Service-B |------+ +--------------+ +-------+
+-----------+
During authorization of the of a service, if the service is
associated with a Rating Group, the Prepaid Client sends the Rating
Group to the Prepaid Server. The prepaid service authorizes the
Rating Group by assigning it a Quota and optionally assigning it to
a Resource Pool.
When service that belongs to an authorized Rating Group is
instantiated, then the Prepaid Client does not need to authorize
that service. This could greatly reduce the amount of traffic
between the Prepaid Client and the Prepaid Server.
3.5
One-Time-based Prepaid Charging
One-Time-based Prepaid Charging is used for charging of Service
Events where there is no session. That is, the Service Event does
not have a start or an end. An example of a one-time service event
is the purchase of a ring-tone. The one-time event in this case is
the userÆs purchasing the right to use a ring-tone. The actual
downloading of the tone is a separate service event totally distinct
from the right to use the ring tone. For example, the user may have
already downloaded the tone and then after being totally satisfied
with the quality, decides to purchase the right to use the 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 to use a service for a month. While the user uses the
service his usage maybe metered especially if there are limits
associated with the service.
For a given user, One-time-based charging may occur in conjunction
with the other charging models. For example, the prepaid user maybe
accessing a website which is being metered based time or volume
while they purchase 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 exempt from charging.
One-time-based charging occurs when the SAD sends an indication to
the PPS identifying the service, and the units that need to be
debited from the account. The units to be debited from the account
and how those units are rated (if they donÆt represent money) is not
in scope of this specification.
One-time-based charging may occur under two conditions: the SAD may
not have a authenticated context (or access to an authenticated
context for the subscriber); 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 prepaid 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. Authentication of the subscriber and the generation of
the one-time charging event will happen at the same time.
Note that one-time-based charging can be used to credit the prepaid
userÆs account. For example, the SAD can return resources back to
the prepaid subscriber by making a one-time charge request that
includes the amount of resource to be credited back to the user.
3.6
Support for Tariff Switching
The PPC and the PPS may support tariff switching for volume based
prepaid packet service. Tariff switching allows the PPS to signal
the PPC when a change of rating or tariff switch is to occur. For
example as shown in the figure below, traffic before 18:00 hours is
rated at ær1Æ or business rates and traffic after 18:00 hours is
rated at ær2Æ or non-business rates. The PPC will then be able to
report usage before the tariff switch point and usage after the
tariff switch point. Since time is measured in seconds, tariff
switching only makes sense for volume based prepaid service where
the volume is billed at different rates: one rate before the tariff
switch period and another rate after the tariff switch period.
18:00
------------------+-----------------
r1 | r2
------------------+-----------------
^ ^
|<----TSI---> |
| |
Access-Accept Access-Request
When tariff switching is supported by the PPC it indicates support
for tariff switching by setting the appropriate bit in the PPAC. If
the PPS requires to signal a tariff switch time it will send a PTS
attribute which will indicate when the tariff switch period is to
occur as a number of seconds from the current time
(TarrifSwitchInterval TSI).
Sometime after the tariff switch period the PPC will send another
online Access-Request. Either the user has logged off or the volume
threshold has been reached. The PPC will report how much volume was
used using the PPAQ and how much volume was used after the tariff
switch using the PTSÆs VUATS subtype.
If the PPC will send and event before the tariff switch time, say
the Volume threshold has been reached, the PPS will respond with
another PTS with the TSI indicating how many seconds until the
tariff switch time.
In situations where there is going to be another tariff switch
period, as shown below, the PPS MUST specify the length of the
tariff switch period using the TimeIntervalAfterTariffSwitchUpdate
(TITSU) in the PTS attribute.
18:00 23:30
------------------+---------------------+--------------
r1 | r2 | r3
------------------+---------------------+--------------
^ ^ ^
|<----TSI---><-----------|-------->|TITSU
| |
Access-Accept Access-Request
When TITSU is specified in the PTS, the PPC MUST generate an online
Access-Request within the time after TSI and before TITSU expires.
Normally the PPC will be triggered by the Volume Threshold, but
there is no guarantee that the user session will generate any volume
during the period between 18:00 and 23:30 hours. If TITSU was not
specified in this case, then if there was some volume generated
during r2 but not enough to trigger a prepaid update before the next
tariff switch at 23:30. Then the PPC will not be able to report how
much volume was generated during r1, r2, and r3.
When prepaid for multiple flows is supported, then each flow could
have it own tariff switch period. For example, best effort flow may
not have a tariff switch associated with it, yet a voice over IP
call may have a tariff switch period. The Voice over IP call may
bill at one rate for the first 5 minutes and another rate for the
rest of the call.
[EDITORÆS NOTE: Need to consider tariff switching with pools. Is it
worthwhile?]
3.7
Support for Roaming
For some networks it is essential that PrePaid Data Services be
offered to roaming subscribers. Support for static and dynamic
roaming models are needed. Static roaming is where the subscriber
logs onto a foreign network. The foreign network has a roaming
agreement directly with the home network or through a broker network
or networks. The subscriber remains logged into the network until
the subscriber changes location. When changing location a new
connection and a new login procedure is required.
Dynamic roaming allows to subscriber to move between networks while
maintaining a connection with the home network seamlessly. As the
subscriber moves between networks, the data session is handed off
between the networks.
In both roaming scenarios, the subscriber always authenticates with
the home network. PrePaid authorization and quota replenishing for
the session need to be received at the home network and more
specifically at the PrePaid System where state is being maintained.
Dynamic roaming is particularly challenging. A subscriber that
established a PrePaid Data Session may roam to another Access Device
that doesnÆt not support PrePaid functionality. The system should
be capable to continue the PrePaid session.
3.8
PrePaid termination
When fraud is detected by the PrePaid System, or when an error is
detected, it may be beneficial for the PrePaid system to terminate a
specific session for the subscriber or all the sessions of a
subscriber.
Some errors can occur such that the PrePaid System is in a state
where it is not sure whether the session is in progress or not.
Under conditions such as this, the PrePaid system may wish to
terminate the PrePaid data session to make sure that resources are
not being utilized for which it canÆt charge for reliably.
Some handoff procedure used during dynamic roaming may require that
the PrePaid system explicitly terminate the subscribers PrePaid data
session at an SAD. For example, if time based PrePaid service is
being used and the mobile subscriber performs a dormant handoff, the
PrePaid System needs to explicitly terminate the PrePaid session at
the old SAD.
3.9 - Due to the fact that the standard RADIUS attributes are not
Querying and Rebalancing Prepaid Resources mandatory, the correct prepaid operation is really an act of faith
on the part of the RADIUS server. If Session-Timeout(27) and/or
Termination-Action(29) are not supported, the prepaid subscriber
might be able to obtain the service for free. The solution described
in this document requires that a prepaid-aware SAD informs the
RADIUS server, regardless of whether or not the latter supports the
prepaid extensions. The RADIUS server can then determine whether or
not service should be granted. For example, if a prepaid subscriber
is connected to a NAS that does not support prepaid, the RADIUS
server can either instruct the NAS to tunnel the traffic to another
entity in the home network (e.g. the Home Agent) that supports
prepaid, or it provide only a restricted service.]
It should be possible to allow the Prepaid Server to Query the The solution presented in this document requires the support of two
current uses state of a prepaid balance at a SAD and adjust the mandatory and one optional attribute. Furthermore, it does not
prepaid resources. require a great amount of additional code at a NAS that already
supports time or volume metering. The solution requires that RADIUS
entities advertise their prepaid capabilities in an Access-Request
and that they generate an Access-Request Authorize-Only packet to
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
when the session terminates in order to refund the subscriberÆs
account appropriately.
For example, a request to the PPS is made (e.g., a one-time charging The solution provided in this document is extensible. For example,
event) but the userÆs account is depleted but resources have been the protocol can be extended to support tariff switching and other
allocated to the SAD. The PPS should have a the capability to query prepaid business models.
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 doesnÆt 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 The extensions described in this document were designed based on a
occurrence of this scenario by allocated smaller quotas. But the number of use cases and scenarios. An overview of these can be found
result will be many more transactions. The ability to query and to in Appendix A.
rebalance resources provides a good trade-off.
4. 3.
Operations Operations
4.1 3.1
General Requirements General Requirements
4.1.1 3.1.1
Broker AAA Requirements Broker AAA Requirements
Broker AAA servers MUST support the Message-Authenticator(80) Broker AAA (BAAA) servers MUST support the Message-Authenticator(80)
attribute as defined in [RFC2869]. If BAAA servers are used, the attribute as defined in [RFC2869]. If they are used, they forward
BAAA servers function is to forward the RADIUS packets as usual to the RADIUS packets as usual to the appropriate RADIUS servers.
the appropriate RADIUS servers.
Accounting messages are not needed to deliver a PrePaid service. Accounting messages are not needed to deliver a prepaid service.
However, accounting messages can be used to keep the PrePaid Server However, accounting messages can be used to keep the PPS up to date
current as to what is happening with the PrePaid data session. as to what is happening with the prepaid data session. Therefore, a
Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the BAAA SHOULD deliver RADIUS Accounting messages using the pass
pass through mode described in [RFC2866]. through mode described in [RFC2866].
4.2 3.2
Authentication and Authorization for Prepaid Enabled SADs Authentication and Authorization for Prepaid Enabled SADs
The SAD initiates the authentication and authorization procedure by The SAD initiates the authentication and authorization procedure by
sending a RADIUS Access-Request to the HAAA. sending a RADIUS Access-Request to the HAAA.
If the SAD has PrePaid Client capabilities, it MUST include the If the SAD has PPC capabilities, it MUST include the PPAC(TBD)
PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD) attribute
attribute indicates to the PrePaid server the PrePaid capabilities indicates to the PPS which prepaid capabilities are possessed by the
possessed by the SAD. These are required in order to complete the SAD. These are required in order to complete the prepaid
PrePaid authorization procedures. authorization procedure.
If the SAD supports the Disconnect-Message or the Change-of- If the SAD supports the Disconnect-Message or the Change-of-
Authorization capabilities, then it SHOULD include the Dynamic- Authorization capabilities, then it SHOULD include the Dynamic-
Capabilities attribute. Capabilities attribute.
In certain deployments, there may be other ways in which to In certain deployments, there may be other ways to terminate a data
terminate a data session, or change authorization of an active session, or change authorization of an active session. For example,
session. For example, some SADs provide a session termination some SADs provide a session termination service via Telnet or SNMP.
service via Telnet or SNMP. In these cases, the AAA server MAY add In these cases, the AAA server MAY add the Dynamic-Capabilities
the Dynamic-Capabilities message to the Access-Request. Upon message to the Access-Request. Upon receiving the Change-of-
receiving the Change-of-Authorization message, the AAA server would Authorization message, the AAA server would then be responsible for
then be responsible for terminating the session using whatever means terminating the session using the means that are supported by the
that are supported by the device. device.
If the authentication procedure involves multiple Access-Requests 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-Request of the authentication procedure. Access-Request of the authentication procedure.
The Access-Request will be sent as usual to the HAAA. The packet The Access-Request is sent as usual to the HAAA. The packet may pass
may be proxied through zero or more BAAA. through one or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA will Once the Access-Request arrives at the HAAA, the HAAA authenticates
authenticate the subscriber. If the subscriber is cannot be the subscriber. If this fails, the HAAA sends an Access-Reject
authenticated, the HAAA will send an Access-Reject message back to message to the client. If authentication succeeds, the HAAA
the client. If the subscriber is authenticated, the HAAA will determines whether or not the subscriber is a prepaid subscriber.
determine whether or not the subscriber is a PrePaid subscriber. (How this is done is beyond the scope of this document.) If the
The techniques used to determine whether or not a subscriber is a subscriber is not a prepaid subscriber, then the HAAA responds as
PrePaid subscriber is beyond the scope of this document. If the usual with an Access-Accept or an Access-Reject message. If the
subscriber is not a PrePaid subscriber, then the HAAA will respond subscriber is a prepaid subscriber then the HAAA SHALL forward the
as usual with an Access-Accept or Access-Reject message. If the Access-Request to the PPS for further authorization.
subscriber is a PrePaid Subscriber the HAAA SHALL forward the
Access-Request to a PrePaid server for further authorization.
The Access-Request will contain the PPAC(TBD) attribute, the The Access-Request contains the PPAC(TBD) attribute and the Dynamic-
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 would represent the attribute MAY be set to a value that represents the subscriberÆs
SubscriberÆs PrePaid Identity. This attribute is used by the identifier. This attribute is used by the PPS to locate his
PrePaid server to locate the PrePaid SubscriberÆs account. For account. For added security, the HAAA MAY also set the User-
added security, the HAAA MAY also set the User-Password(2) attribute Password(2) attribute to the password used between the HAAA and the
to the password used between the HAAA and the PrePaid server. PPS.
The PrePaid server lookups the subscriberÆs PrePaid account and will The PPS locates the subscriberÆs account and authorizes him. During
authorize the subscriber taking into consideration the SAD PrePaid this procedure, the PPS takes into consideration the SAD PPC
Client Capabilities. Capabilities.
Upon successful authorization, the PrePaid server will generate an Upon successful authorization, the PPS generates an Access-Accept
Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD) containing the PPAC(TBD) attribute and the PPAQ(TBD) attribute.
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(TBD)
attribute includes: attribute includes the following.
- The QUOTA-Id, which is set by the PrePaid server to a unique - The QUOTA-ID, which is set by the PPS to a unique value that is
value that is used to correlate subsequent quota requests; used to correlate subsequent quota requests;
- Volume and/or Time quotas, which are set to a value representing a - Volume and/or Time quotas, which are set to values representing a
portion of the subscribers account; portion of the subscribers credit;
- MAY contain a Time or Volume Threshold that controls when the SAD - It MAY contain a Time or Volume Threshold that controls when the
requests additional quota; SAD should request additional quota;
- The IP address of the Serving PrePaid Server and one or more - The IP address of the Serving PPS and one or more alternative
alternative PrePaid Servers. This is used by the HAAA to route PPSs. This is used by the HAAA to route subsequent quota
subsequent quota replenishing messages to the appropriate PrePaid replenishing messages to the appropriate PPS(s).
server(s).
Note: Idle-Timeout(28) can be used to trigger the premature Note: Idle-Timeout(28) can be used to trigger the premature
termination of a pre-paid service following subscriber inactivity. termination of a prepaid service, for example as a result of
inactivity.
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, after failed authorization, the PPS may
PrePaid server will generate an Access-Reject to terminate the generate an Access-Reject to terminate the session immediately.
session immediately. Alternatively, the PrePaid server may generate Alternatively, the PPS may generate an Access-Accept blocking some
an Access-Accept blocking some or all of the traffic and/or redirect or all of the traffic and/or redirect some or all of the traffic to
some or all of the traffic to a location where the subscriber can a location to a fixed server. (This feature could be used, for
replenish their account for a period of time. Blocking of traffic example, to prompt the user to replenish their account.) Blocking of
is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect traffic is achieved by either Filter-ID(11) or NAS-Filter-Rule(see
I-d). Redirection is achieved by sending Redirect-Id or Redirect- Redirect I-d). Redirection is achieved by sending Redirect-Id or
Rule, HTTP Redirection defined in the Redirect I-d. The period of Redirect-Rule, HTTP Redirection defined in the Redirect I-d. The
time before the blocked/redirected session last can be specified by time period before the session is blocked/redirected is specified by
Session-Timeout(27) attribute. the Session-Timeout(27) attribute.
Upon receiving the Access-Accept from the PrePaid Server, the HAAA Upon receiving an Access-Accept from the PPS, the HAAA appends the
will append the usual service attributes and forward the packet to usual service attributes and forward the packet to the SAD. The
the SAD. The HAAA SHOULD NOT overwrite any attributes already set HAAA SHOULD NOT overwrite any attributes already set by the PPS. If
by the PrePaid server. If the HAAA, receives an Access-Reject the HAAA, receives an Access-Reject message, it will simply forward
message, it will simply forward the packet to its client. Depending the packet to its client. Depending on site policies, if the HAAA
on site policies, if the HAAA fails to receive an Access-Accept or does not receive an Access-Accept or an Access-Reject message from
Access-Reject message from the PrePaid server it MAY do nothing or the PPS it MAY do nothing or send an Access-Reject or an Access-
send an Access-Reject or an Access-Accept message back to its Accept message back to the PPC.
client.
4.3 3.3
Session Start Operation Session Start Operation
The real start of the session is indicated by the arrival of The start of the session is indicated by the arrival of an
Accounting-Request(Start) packet. The Accounting-Request (Start) Accounting-Request(Start) packet. The Accounting-Request (Start) MAY
MAY be routed to the PrePaid Server so that it can confirm the be routed to the PPS such that it can confirm the initial quota
initial quota allocation. allocation.
Note that the PrePaid Server role is not to record accounting Note that the role of the PPS is not to record accounting messages
messages and therefore it SHOULD not respond with an Accounting and therefore it SHOULD not respond with an Accounting Response
Response packet. packet.
If the Prepaid server does not receive the Accounting-Request(start) If the PPS does not receive the Accounting-Request(start) message it
message it will only know that the session has started upon the will only know that the session has started upon the first reception
first reception of a quota replenishment operation. of a quota replenishment operation.
If the Prepaid server does not receive indication directly (via If the PPS does not receive indication directly (via Accounting-
Accounting-Request(start)) or indirectly, it SHOULD after some Request(start)) or indirectly, it SHOULD after some configurable
configurable time, deduce that the Session has not started. If the time, deduce that the Session has not started. If the SAD supports
SAD supports termination capabilities, the PPS SHOULD send a termination capabilities, the PPS SHOULD send a Disconnect Message
Disconnect Message to the SAD to ensure that the session is indeed to the SAD to ensure that the session is indeed dead.
dead.
4.4 3.4
Mid-Session Operation Mid-Session Operation
During the lifetime of a PrePaid data session the SAD will request During the lifetime of a prepaid data session the SAD requests the
to replenish the quotas using Authorize-Only Access-Request replenishment of the quotas using Authorize-Only Access-Request
messages. messages.
Once the allocated quota has been reached or the threshold has been Once either the allocated quota has been exhausted or the threshold
reached, the SAD MUST send an Access-Request with Service-Type(6) has been reached, the SAD MUST send an Access-Request with
set to a value of ôAuthorize Onlyö and the PPAQ(TBD) attribute. Servicetype(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD)
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 those used during the Access- Identifier should be the same as the one used during the Access-
Request. For example, if the User-Name(1) attribute was used in the Request. For example, if the User-Name(1) attribute was used in the
Access-Request it MUST be included in the Authorize Only Access- Access-Request it MUST be included in the Authorize Only Access-
Request especially if the User-Name(1) attribute is used to route Request, especially if the User-Name(1) attribute is used to route
the Access-Request to the Home AAA server. the Access-Request to the Home AAA server.
The Authorize Only Access-Request MUST not include either User The Authorize Only Access-Request MUST NOT include a User Password
Password or Chap Password. In order to authenticate the message, and MUST NOT include a Chap Password. In order to authenticate the
the SAD MUST include the Message-Authenticator(80) attribute. The message, the SAD MUST include a Message-Authenticator(80) attribute.
SAD will compute the value for the Message-Authenticator based on The SAD computes the value for the Message-Authenticator according
[RFC2869]. to [RFC2869].
When the HAAA receives the Authorize-Only Access-Request that When the HAAA receives the Authorize-Only Access-Request that
contains a PPAQ(TBD), it SHALL validate the message using the contains a PPAQ(TBD), it SHALL validate the message using the
Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an Message-Authenticator(80) as per [RFC2869]. 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) but not a
Message-Authenticator(80) it SHALL silently discard the message. An Message-Authenticator(80) it SHALL silently discard the message. An
Authorize Only Access-Request message that does not contain a Authorize Only Access-Request message that does not contain a
PPAQ(TBD) is either in error or belongs to another application (for PPAQ(TBD) is either erroneous or belongs to another application (for
example, a Change of Authorization message [RFC3576]). In this case example, a Change of Authorization message [RFC3576]). In this case
the Authorize Only Access-Request will either be silently discarded the Authorize Only Access-Request is either silently discarded or
or handled by another application (not in scope of this document). 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 SHALL forward the Authorize Only Access-Request to the HAAA SHALL forward the Authorize Only Access-Request to the
appropriate PrePaid Server. The HAAA MUST forward the Authorize appropriate PPS. The HAAA MUST forward the Authorize Only Access-
Only Access-Request to the PrePaid server specified in the Request to the PPS specified in the PPAQ(TBD). The HAAA MUST add an
PPAQ(TBD). The HAAA MUST sign the message using the Message- Message-Authenticator(80) to the message, according to [RFC2869].
Authenticator(80) and the procedures in [RFC2869]. 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 to a value that represents the userÆs internal PrePaid prepaid account in the PPS. Note the PPS may also use the Quota-ID
account in the PrePaid server. Note the PrePaid server could use sub-attribute contained within the PPAQ(TBD) to locate the user
the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate account.
the user account.
Upon receiving the Authorize Only Access-Request containing a Upon receiving the Authorize Only Access-Request containing a
PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- PPAQ(TBD) attribute, the PPS MUST validate the Message-
Authenticator(80) as prescribed in [RFC2869]. If the message is Authenticator(80) as described in [RFC2869]. If validation fails,
invalid, the PrePaid server MUST silently discard the message. If the PPS MUST silently discard the message. If it receives an
it received an Authorize Only Access-Request message that does not Authorize Only Access-Request message that does not contain a
contain a PPAQ(TBD) it MUST silently discard the message. PPAQ(TBD) it MUST silently discard the message.
The PrePaid server will lookup the PrePaid session by using the The PPS locates the prepaid session state using the Quota Id
PrePaid Quota Id contained within the PPAQ(TBD). The PrePaid Server contained within the PPAQ(TBD). The PPS takes the most recently
would, take the last allocated quota and subtract that from the allocated quota and subtracts it from the userÆs balance. If
UserÆs balance. If there is remaining balance, the PrePaid server sufficient balance remains, the PPS authorizes the PPS and allocates
re-authorizes the PrePaid session by allocate an additional quota. additional quota. The PPS may also calculate a new threshold value.
The PrePaid server may want to calculate a different threshold
values as well.
Upon successful re-authorization, the PrePaid server will generate Upon successful re-authorization, the PPS generates an Access-Accept
an Access-Accept containing the PPAQ(TBD) attribute. The Access- containing the PPAQ(TBD) attribute. The Access-Accept message MAY
Accept message MAY contain Service-Type(6) set to Authorize-Only and contain Servicetype(6) set to Authorize-Only and MAY contain the
MAY contain the Message-Authenticator(80). Message-Authenticator(80).
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, upon unsuccessful authorization, the PPS
PrePaid server will generate an Access-Reject or an Access-Accept generates an Access-Reject or an Access-Accept with Filter-Id(11) or
with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute Ascend-Data-Filter (if supported) attribute and the Session-
and the Session-Timeout(27) attribute such that the PrePaid Timeout(27) attribute such that the subscriber can get access to a
subscriber could get access to a restricted set of locations for a restricted set of locations for a short period of time. This feature
short duration to allow them to replenish their account, or create could be used to enable users to replenish their accounts, create
an account; or to browse free content. new accounts, or to browse free content.
Upon receiving the Access-Accept from the PrePaid server, the HAAA Upon receiving the Access-Accept from the PPS, the HAAA SHALL return
SHALL return the packet to its client. If the HAAA, receives an the packet to its client. If the HAAA receives an Access-Reject
Access-Reject message, it will forward the packet. Depending on message, it forwards the packet. Depending on site policies, if the
site policies, if the HAAA fails to receive an Access-Accept or an HAAA does not receive an Access-Accept or an Access-Reject message
Access-Reject message from the PrePaid server it MAY do nothing or from the PPS it MAY do nothing or it MAY send an Access-Reject
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 PrePaid server MAY update the attribute. Note that the PPS MAY update the PrePaidServer
PrePaidServer attribute(s) and these may have to be saved as well. attribute(s) and these may have to be saved as well.
Upon receiving an Access-Accept message containing either Filter- Upon receiving an Access-Accept message that contains an Filter-
Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). Id(11), an Ascend-Data-Filter attribute, or Session Timeout(27), the
The SAD SHALL restrict the subscriber session accordingly. SAD SHALL restrict the subscriber session accordingly.
4.5 3.5
Dynamic Operations Dynamic Operations
The PPS may take advantage of the dynamic capabilities that are
supported by the SAD as advertised in the Dynamic-Capabilities
attribute during the initial Access-Request.
The PrePaid server may want to take advantage of the dynamic There are two types of action that the PPS may perform. Firstly, it
capabilities that are supported by the SAD as advertised in the may request the session to be terminated. Secondly, it may request
Dynamic-Capabilities attribute during the initial Access-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 actions that the PrePaid server can perform:
it can request that the session be terminated; or it can request
that attributes associated with the session be modified. More
specifically, it can modify previously sent PPAQ(TBD)
Both of these actions require that the session be uniquely Both of these actions require that the session be uniquely
identified at the SAD. As a minimum the PrePaid server: identified at the SAD. As a minimum the PPS MUST
-MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) - provide either the NAS-IP-Address(4) or the NAS-Identifier(32)
-MUST provide at least one session identifier such as User-Name(1), - provide at least one session identifier such as User-Name(1),
Framed-IP-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 be used to uniquely identify a prepaid data
session. session.
For a discussion on Dynamic Operations as they related Mutli-Service 3.5.1
operations see further on.
4.5.1
Unsolicited Session Termination Operation Unsolicited Session Termination Operation
At anytime during a session the Prepaid Server may send a Disconnect At anytime during a session the PPS may send a Disconnect Message in
Message to terminate a session. This capability is described in order to terminate a session. This capability is described in
detail in [RFC3576]. The PrePaid server sends a Disconnect Message detail in [RFC3576]. The PPS sends a Disconnect Message that MUST
that MUST contain identifiers that uniquely identify the contain identifiers that uniquely identify the data session and the
subscriberÆs data session and the SAD servicing that session. SAD servicing that session.
If the SAD receives a Disconnect-Message, it will respond with If the SAD receives a Disconnect-Message, it responds with either a
either a Disconnect-ACK packet if it was able to terminate the Disconnect-ACK message (if it is able to terminate the session) or
session or else it will respond with a Disconnect-NAK packet. with a Disconnect-NAK packet (otherwise).
Upon successful termination of a session the SAD MUST return any Upon successful termination of a session the SAD MUST return any
unused quota to the Prepaid Server by issuing an Authorize Only unused quota to the PPS by issuing an Authorize Only Access-Request
Access-Request containing the PPAQ which contains any unused Quota containing the PPAQ which contains any unused Quota and the Update-
and the Update-Reason set to ôRemote Forced Disconnectö. Reason set to ôRemote Forced Disconnectö.
4.5.2 3.5.2
Unsolicited Change of Authorization Operation Unsolicited Change of Authorization Operation
At anytime during the prepaid session the Prepaid Client may receive At any time during the session the PPC may receive a Change of
a Change of Authorization (CoA) message. A Prepaid Server may send Authorization (CoA) message. A PPS may send a new Quota to either
a new Quota to either add additional quota or to remove quota add or to remove quota that is allocated to the service.
already allocated for the service.
If the Change of Authorization contains a PPAQ then that PPAQ will If the Change of Authorization contains a PPAQ then that PPAQ
override a previously received PPAQ. The PPAQ may contain more overrides a previously received PPAQ. The PPS MUST NOT change the
allocated Quota or less allocated quota. The PPS MUST NOT change units used in the PPAQ.
the 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 currently used then the SAD will accept the new PPAQ beyond what is already used then the SAD accepts the new PPAQ and
and act as it normally would when the quota is used up. For act as it normally would when the quota is used up. For example, if
example, if the threshold is reached then is request a quota update; the threshold is reached then is request a quota update.
if the quota received is less then the currently used level then the
SAD would follow the normal procedures followed when a quota is used
up.
4.6 3.6
Termination Operation Termination Operation
The termination phase is initiated when either: the Subscriber logs The termination phase is initiated when (i) the subscriber logs off,
off; the quotas have been consumed, or when the SAD receives a (ii) the subscriberÆs balances is exhausted, or (iii) when the SAD
Disconnect Message. receives a Disconnect Message.
In the case where the user logged off, or the SAD receives a In the case where the user logged off, or the SAD receives a
Disconnect Message, the SAD will send an Authorize-Only Access- Disconnect Message, the SAD sends an Authorize-Only Access-Request
Request message with a PPAQ(TBD) and Update-Reason attribute set to message with a PPAQ(TBD) and Update-Reason attribute set to either
either ôClient Service terminationö or ôRemote Forced disconnectö ôClient Service terminationö or ôRemote Forced disconnectö. This
and the currently used quota. message indicates the already consumed quota.
In the case where the quota has been reached, if the PPAQ(TBD) In the case where the currently allocated quota is exhausted, if the
contained Termination-Action field, the SAD will follow the PPAQ(TBD) contained Termination-Action field, the SAD follows the
specified action which would be to immediately terminate the specified action (which would be to immediately terminate the
service, to request more quota, or to Redirect/Filter the service. service), requests more quota, or redirects/filters the service.
4.7 3.7
Mobile IP Operations Mobile IP Operations
In roaming scenarios using Mobile-IP, as the mobile subscriber roams In roaming scenarios with Mobile-IP, the prepaid data session should
between networks, or between different types of networks such as
between WLAN and CDMA2000 networks, 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 the new SAD (AP or PDSN As the subscriber device associates with the new SAD (AP or PDSN
that supports prepaid client capability), the SAD sends a RADIUS that supports PPC capability), the SAD sends a RADIUS Access-Request
Access-Request and the subscriber is re-authenticated and and the subscriber is re-authenticated and reauthorized. The SAD
reauthorized. The SAD MUST include the PPAC(TBD) attribute in the MUST include the PPAC(TBD) attribute in the RADIUS Access-Request.
RADIUS Access-Request. In this manner the procedure follows the In this manner the procedure follows the Authentication and
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 userÆs prepaid
session does not undergo any change after the handoff because the session does not undergo any change after the handoff because the
Mobile IP session is anchored at the HA and the userÆs Home IP Mobile IP session is anchored at the HA and the userÆs Home IP
address remains the same. address remains the same.
In the case of AP or PDSN acting as the SAD it is likely that the In the case of a wireless access point or PDSN acting as the SAD it
userÆs IP address will change (Care of Address). Therefore, the is likely that the userÆs IP address will change (Care of Address).
ongoing prepaid session will have some impact. In the case the SAD The prepaid session will be affected by this. In this scenario the
shall send an Access-Request. SAD shall send an Access-Request message which is routed to the home
The Access-Request message is routed to the home network and MUST network and MUST reach the prepaid system that is serving this
reach the PrePaid System that is serving the PrePaid session. The session. The prepaid system correlates the new authorization
PrePaid system will then correlate the new authorization request request with the existing active session and assigns a quota to the
with the existing active session and will assign a quota to the new new request. Any outstanding quota at the old SAD MUST be returned
request. Any outstanding quota at the old SAD MUST be returned to to the prepaid system if the Mobile-IP nodes (HA and FA) support
the PrePaid system. If the Mobile-IP nodes (HA and FA) supports registration revocation (Mobile IPv4 only). Specifically, the quota
registration revocation (Mobile IPv4 only). Specifically, the quota
SHOULD be returned when the SAD sends the Authorize Only Access- SHOULD be returned when the SAD sends the Authorize Only Access-
Request with PPAQ(TBD) Update-Reason set to either ôRemote Forced Request with PPAQ(TBD) Update-Reason set to either ôRemote Forced
disconnectö or ôClient Service terminationö. In order to trigger disconnectö or ôClient Service terminationö. In order to trigger
the sending of this last Authorize Only Access-Request, the PrePaid the sending of this last Authorize Only Access-Request, the prepaid
system may issue a Disconnect Message [3576] to the SAD. system may issue a Disconnect Message [3576] to the SAD.
If the subscriber has roamed to an SAD that does not have any Even if the subscriber moves to a SAD that does not have prepaid
PrePaid Capabilities, PrePaid data service may still be possible by capabilities can the prepaid data service continue. This can be done
requesting the Home Agent (providing it has PrePaid Capabilities) to by requesting the Home Agent (assuming that has such capabilities)
assume responsibilities for metering the service. The procedure for to take over the responsibilities of the SAD (i.e. metering). This
this scenario will be given in the next release of this draft. scenario will be discussed in a later version of this document.
4.8 3.8
Operation consideration for Multi-Services Operation considerations for Multiple prepaid services
This section describes the operation for supporting Prepaid for This section describes the support for multiple prepaid services on
multi-services on the same SAD. The operations for multi-services a single SAD. Message flows illustrating the various interactions
are very similar to operations for single service. Message flows are presented at the end of this document.
illustrating the various interactions are presented at the end of
this document.
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 When working with multi-services, we need to differentiate between
the services. A Service-Id attribute is used in the PPAQ(TBD) to the services. A Service-Id attribute is used in the PPAQ(TBD) to
uniquely differentiate between the services. The exact definition uniquely differentiate between the services. The exact definition
of the Service-Id attribute is out of scope for 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 PPAQ that contains a Rating-Group-Id is associated with that A PPAQ that contains a Rating-Group-Id is associated with that
Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a Rating-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ö.
4.8.1 3.8.1
Initial Quota Request Initial Quota Request
When operations with multi-services is desired, the SAD will request When operations with multi-services is desired, the SAD requests the
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 prepaid quota for the Rating-Group by sending a PPAQ request a quota for the Rating-Group by sending a PPAQ containing
containing the Rating-Group-Id. In both cases the Update-Reason the Rating-Group-Id. In both cases the Update-Reason is set to
will be set to ôInitial-Requestö. ôInitial-Requestö.
The Authorize-Only Access-Request packet may contain more than one The Authorize-Only Access-Request message may contain more than one
PPAQ. The Authorize-Only Access-Request MUST include one or more PPAQ. The Authorize-Only Access-Request MUST includes 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 Identifier(s) linked to the original authentication. Which Session Identifiers
is included is up to specific deployments. The Authorize-Only are included is up to specific deployments. The Authorize-Only
message must contain the Message-Authenticator(80) attribute for message must contain the Message-Authenticator(80) attribute for
integrity protection of the Authorize-Only Access-Request message. integrity 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 or more PPAQs the Prepaid System will allocate resources to each one or more PPAQs, the prepaid system allocates resources to each
PPAQ. The resources, can be in units of time, volume as before. PPAQ. Each PPAQ is assigned a unique QID that MUST appear in
Each PPAQ will be assigned a unique QID that MUST appear in a subsequent PPAQ updates for that service or rating-group.
subsequent PPAQ update for that service or rating-group. As well, Additionally, the PPAQ MUST contain the Service-ID or Group-ID,
the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if unless the PPAQ is a generic ôAccess Serviceö.
the PPAQ applies to the ôAccess Serviceö.
4.8.2 3.8.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 reached or no more quota remains). To replenish the quota the PPC
Prepaid Client will send an Authorize-Only Access-Request message sends an Authorize-Only Access-Request message containing one or
containing one or more PPAQs. Each PPAQ MUST contain the more PPAQs. Each PPAQ MUST contain the appropriate QID, Service-ID
appropriate QID, Service-ID or Group-ID (or neither the Service-ID or Group-ID (or neither the Service-ID or Group-Id if the quota
or Group-Id if the quota replenishment is for the ôAccess Serviceö). replenishment is for the ôAccess Serviceö). The Update-Reason filed
The Update-Reason filed will indicate either ôThreshold reachedö(3), indicates either ôThreshold reachedö(3), or ôQuota reachedö(4). The
or ôQuota reachedö(4). The Authorize-Only message must contain Authorize-Only message must contain session identifiers.
identifiers to identify the session.
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 Prepaid Server will respond with a new PPAQ for that more PPAQs the PPS responds with a new PPAQ for that service. The
service. The PPAQ will contain a new QID, the Service-Id or Rating- PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new
Group-Id, a new Quota. If the Prepaid Server does not want to grant Quota. If the PPS does not grant additional quota to the service it
additional quota to the Service it MUST include the Termination- MUST include the Termination-Action subfield in the PPAQ that will
Action subfield in the PPAQ that will instruct the SAD what to do instruct the SAD what to do with the service.
with the service.
4.8.3 3.8.3
Termination Termination
When an allotted quota for the service is used up 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 If the service is to be terminated then the SAD shall send a PPAQ
with the appropriate QID, the Service-Id, the used quota, and with the appropriate QID, the Service-Id, the used quota, and
Update-Reason set to ôClient Service Terminationö. Update-Reason set to ôClient Service Terminationö.
If the ôAccess Serviceö has terminated, then all other services must If the ôAccess Serviceö has terminated, then all other services must
be terminated as well. In this case the SAD must report on all be terminated as well. In this case the SAD MUST report on all
issued quotas for the various services. The Update-Reason field issued quotas for the various services. The Update-Reason field
should be set to ôAccess Service Terminatedö. should be set to ôAccess Service Terminatedö.
Note when sending more then on PPAQ it may be required to send 3.8.4
multiple Authorize Only Access-Requests.
4.8.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 will match the PPAQ to the service using service instance. The SAD matches the PPAQ with the service using
the Service-ID attribute. The new quota could be higher then the the Service-ID attribute. The new quota could differ from the
last allocated value or it could be lower. The SAD must react to previously allocated value. The SAD must react to the new value
the new quota accordingly. accordingly.
A Disconnect message may not be send for a specific service. A A disconnect message terminates the ôAccess Serviceö. As such the
disconnect message terminates the ôAccess Serviceö. As such the SAD SAD MUST report all unused quotas by sending an Authorize Only
must report back all unused quotas by sending an Authorize Only
Access Request message containing a PPAQ for each active service. Access Request message containing a PPAQ for each active service.
The Update-Reason shall indicate that the reason for the update The Update-Reason shall indicate that the reason for the update.
reason.
4.8.5 3.8.5
Support for Resource Pools Support for Resource Pools
If the Prepaid Client supports pools as indicated by setting the If the PPC supports pools as indicated by setting the ôPools
ôPools supportedö bit in the PPAC(TBD) then the Prepaid Server may supportedö bit in the PPAC(TBD) then the PPS may associate a Quota
associate a Quota with a Pool by including the Pool-Id and the Pool- with a Pool by including the Pool-Id and the Pool-Multiplier in the
Multiplier in the PPAQ(TBD). PPAQ(TBD).
When Resource Pools are used, the PPAQ must not use the threshold When Resource Pools are used, the PPAQ must not use the threshold
field. field.
4.8.6 3.8.6
One-Time-Charging One-Time-Charging
To initiate a One-Time charge the PPC include 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 an Access-Request packet. The Access Request packet MUST include a
the Message-Authenticator(80) and Event-Timestamp(55) attributes. Message-Authenticator(80) and an Event-Timestamp(55) attribute.
The Service Id field of the PPAQ identifies the Service that is be The Service Id field of the PPAQ identifies the prepaid service.
charged for. The amount of to be charged is specified using the The amount to be charged is specified using the Resource Quota and
Resource Quota and Resource Quota overflow subtypes. If the value Resource Quota overflow subtypes. If the value specified is
specified is negative then the resources will be credited to the negative then the resources are credited to the userÆs account.
userÆs account.
The QID field MUST be set to a unique value and will be used by the The QID field MUST be set to a unique value and is used by the PPS
PPS to detect duplicates should the packet be retransmitted. to detect duplicates. The Update Reason field MUST be set to One-
The Update Reason field MUST be set to One-Time Charging. Time Charging.
Upon receiving a PPAQ configured as a One-Time charge, the RADIUS Upon receiving a One-Time charge PPAQ, the RADIUS server
server authenticates the user and if authenticated, pass the PPAQ to authenticates the user and, if successful, passes the PPAQ to the
the PPS. The PPS shall locate the subscriber account and debit or PPS. The PPS locates the account and debits or credits it
credit the account accordingly. The PPS MUST repond to the PPS with accordingly. The PPS MUST respond to the PPS with an Access-Accept
an Access-Accept message upon success. Or an Access-Reject message message if successful, or an Access-Reject message otherwise.
if it cant locate the userÆs account or if there is no balance
remaining in the account.
The RADIUS server shall respond back to the SAD with an Access The RADIUS server shall respond to the SAD with an Access Accept
Accept message. Since this is a one-time event charge the SAD must message. Since this is a one-time charge the SAD must not allow the
not allow the session to continue. Therefore, the RADIUS server session to continue. Therefore, the RADIUS server should include in
should include in the Access-Accept a Session-Timeout set to 0. The the Access-Accept a Session-Timeout set to 0. Upon receiving an
Upon receiving an Access-Accept response the SAD shall generate an Access-Accept response the SAD shall generate an Accounting Stop
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 where a session already exists for Access Request. This is the case when the session already exists.
the user. The PPS shall respond back with an Access-Accept to The PPS responds with an Access-Accept to indicate that the userÆs
indicate that the userÆs account has been debited or an Access- account has been debited or an Access-Reject otherwise.
Reject indicating that the account could not be debited.
4.8.7 3.8.7
Error Handling Error Handling
If the Prepaid Server receives a PPAQ with an invalid QID it MUST If the PPS receives a PPAQ with an invalid QID it MUST ignore that
ignore that PPAQ.
If the Prepaid Server receives a PPAQ containing a Service-Id, or a
Rating-Group-Id that it does not recognize, then it MUST ignore that
PPAQ. PPAQ.
If the Prepaid Client receives a PPAQ containing a Service-Id, or a If the PPS receives a PPAQ containing a Service-Id, or a Rating-
Rating-Group-Id that it does not recognize, then it must ignore that Group-Id that it does not recognize, then it MUST ignore that PPAQ.
PPAQ.
If the Prepaid Client receives a PPAQ that contains a Pool-Id If the PPC receives a PPAQ containing a Service-Id, or a Rating-
without a Pool-Multiplier; or a Pool-Multiplier without a Pool-Id it Group-Id that it does not recognize, then it must ignore that PPAQ.
must ignore that PPAQ.
4.9 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
that PPAQ.
3.9
Accounting Considerations Accounting Considerations
Accounting messages are not required to deliver PrePaid Data Although typically generated, accounting messages are not required
Service. Accounting message will typically be generated for PrePaid to deliver a prepaid data service. When generated, accounting
Data Service. This because accounting message are used for auditing messages are used for auditing purposes and for billing.
purposes as well as for bill generation.
Accounting messages associated with PrePaid Data Sessions should Accounting messages associated with prepaid data sessions should
include the PPAQ(TBD) attribute. include the PPAQ(TBD) attribute.
4.10 3.10
SAD Operation SAD Operation
To be completed To be completed
4.11 3.11
Interoperability with Diameter Credit Control Application Interoperability with Diameter Credit Control Application
RADIUS PrePaid solutions need to interoperate with Diameter The RADIUS prepaid extensions need to interoperate with the Diameter
protocol. Two possibilities exist: The AAA infrastructure is protocol. Two possibilities exist: The AAA infrastructure is
Diameter based and the SAD are RADIUS based; or the SAD is Diameter Diameter based and the SAD are RADIUS based, or the SAD is Diameter
based and the AAA infrastructure is RADIUS based. 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 implement a PrePaid using an all Diameter based infrastructure. to implement a prepaid accounting system using an Diameter based
infrastructure.
<This section to be completed.> <This section to be completed.>
5. 4.
Attributes Attributes
This draft is using the RADIUS [RFC2865] namespace. This draft is using the RADIUS [RFC2865] namespace.
5.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 available describe the prepaid capabilities of the NAS. The PPAC is present
to be sent in an Access-Accept message by the Prepaid server to in an Access-Accept message by the PPS to indicate the type of
indicate the type of prepaid metering that is to be applied to this metering that is to be applied to this session.
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 | SUB-TYPE 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:
Sub-Type (=1) : Sub-Type 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 Sub-Type, generated by the PrePaid The optional AvailableInClient Subtype, generated by the PPC,
client, indicates the PrePaid Accounting capabilities of the NAS and indicates the metering capabilities of the NAS and shall be bitmap
shall be bitmap encoded. The possible values are: encoded. The possible values are:
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
5.2 4.2
Session Termination Capability Session Termination Capability
The value shall be bitmap encoded rather than a raw integer. This 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.
5.3 4.3
PPAQ Attribute PPAQ Attribute
One or more PPAQ(TBD) attributes are available to be sent in an One or more PPAQ(TBD) attributes are sent in an Access Request,
Access Request, Authorize Only Access-Request and Access-Accept Authorize Only Access-Request and Access-Accept messages. In an
messages. In an Access Request message, it is used to One-Time Access Request message, the PPAQ attribute is used to facilitate
charging transactions; in Authorize Only Access-Request messages it One-Time charging transactions. In Authorize Only Access-Request
is used to for One-Time charging, report usage and request further messages it is used for One-Time charging, report usage and the
quota or request prepaid quota for a new service instance; in an request for further quota. It is also used to request prepaid quota
Access-Accept message it is used to allocate the quotas (initial for a new service instance. In an Access-Accept message it is used
quota and subsequent quotas). to allocate the (initial and subsequent) quotas.
When concurrent service 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 Service-Id; or a specific service as indicated by the presence of a Service-Id, a
Rating Group, as indicated by the presence of a Rating-Group-Id; or Rating-Group-Id, or the ôAccess Serviceö (as indicated by the
the ôAccess Serviceö as indicated by the absence of a Service-Id or absence of a Service-Id and a Rating-Group-Id).
a Rating-Group-Id.
The attribute consists of a number of subtypes. Subtypes not used The attribute consists of a number of subtypes. Unused subtypes are
are omitted in the message. omitted from the message.
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 | SUB-TYPE 1 | LENGTH | | TYPE | LENGTH | SUBtype 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIdentifier (QID) | | QuotaIdentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Volume Quota | | SUBtype 2 | LENGTH | Volume Quota |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Volume Quota | SUB-TYPE 3 | LENGTH | | Volume Quota | SUBtype 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VolumeQuotaOverflow (VQO) | SUB-TYPE 4 | LENGTH | | VolumeQuotaOverflow (VQO) | SUBtype 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VolumeThreshold (VT) | | VolumeThreshold (VT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 5 | LENGTH | VolumeThresholdOverflow (VTO) | | SUBtype 5 | LENGTH | VolumeThresholdOverflow (VTO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 6 | LENGTH | DurationQuota (DQ) | | SUBtype 6 | LENGTH | DurationQuota (DQ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | | DurationQuota (DQ) | SUBtype 7 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationThreshold (DT) | | DurationThreshold (DT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | | SUBtype 8 | LENGTH | Update-Reason attribute (UR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 9 | LENGTH | PrePaidServer | | SUBtype 9 | LENGTH | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrePaidServer | | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 10 | LENGTH | Service-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBtype 11 | LENGTH | Rating-Group-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 Type : Value of PPAQ
Length: variable, greater than 8 Length: variable, greater than 8
String: The String value MUST be encoded as follows: String: The String value MUST be encoded as follows:
Sub-Type (=1): Sub-Type for QuotaIDentifier attribute Subtype (=1): Subtype for QuotaIDentifier attribute
Length : Length of QuotaIDentifier attribute (= 6 octets) Length : Length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID): QuotaIDentifier (QID):
The QuotaIDentifier Sub-Type is generated by the PrePaid server The QuotaIDentifier subtype is generated by the PPS together with
at allocation of a Volume and/or Duration Quota. The on-line the allocation of a Volume or Duration Quota. The on-line quota
quota update RADIUS Access-Request message sent from the SAD to update RADIUS Access-Request message sent from the SAD to the PPS
the PPS shall include a previously received QuotaIDentifier. shall include a previously received QuotaIDentifier.
Sub-Type (=2): Sub-Type for VolumeQuota attribute Subtype (=2): Subtype for VolumeQuota attribute
Length : length of VolumeQuota attribute (= 6 octets) Length : length of VolumeQuota attribute (= 6 octets)
VolumeQuota (VQ): VolumeQuota (VQ):
The optional VolumeQuota Sub-Type is only present if Volume Based The optional VolumeQuota subtype is only present if Volume Based
charging is used. In RADIUS Access-Accept message (PPS to SAD charging is used. In a RADIUS Access-Accept message (PPS to SAD
direction), it indicates the Volume (in octets) allocated for the direction), it indicates the Volume (in octets) allocated for the
session by the PrePaid server. In RADIUS Authorize Only Access- session by the PPS. In RADIUS Authorize Only Access-Request
Request message (SAD to PPS direction), it indicates the total message (SAD to PPS direction), it indicates the total used
used volume (in octets) for both forward and reverse traffic volume (in octets) for both forward and reverse traffic.
applicable to PrePaid accounting.
Sub-Type (=3): Sub-Type for VolumeQuotaOverflow Subtype (=3): Subtype for VolumeQuotaOverflow
Length : length of VolumeQuotaOverflow attribute (= 4 octets) Length : length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO): VolumeQuotaOverflow (VQO):
The optional VolumeQuotaOverflow Sub-Type is used to indicate how The optional VolumeQuotaOverflow subtype is used to indicate how
many times the VolumeQuota counter has wrapped around 2^32 over many times the VolumeQuota counter has wrapped around 2^32 over
the course of the service being provided. the course of the service being provided.
Sub-Type (=4): Sub-Type for VolumeThreshold attribute Subtype (=4): Subtype for VolumeThreshold attribute
Length : length of VolumeThreshold attribute (= 6 octets) Length : length of VolumeThreshold attribute (= 6 octets)
VolumeThreshold (VT): VolumeThreshold (VT):
The VolumeThreshold Sub-Type shall always be present if The VolumeThreshold Subtype shall always be present if
VolumeQuota is present in a RADIUS Access-Accept message (PPS to VolumeQuota is present in a RADIUS Access-Accept message (PPS to
SAD direction). It is generated by the PrePaid server and SAD direction). It is generated by the PPS and indicates the
indicates the volume (in octets) that shall be used before volume (in octets) that shall be consumed before a new quota
requesting quota update. This threshold should not be larger than should be requested. This threshold should not be larger than the
the VolumeQuota. VolumeQuota.
Sub-Type (=5): Sub-Type for VolumeThresholdOverflow Subtype (=5): Subtype for VolumeThresholdOverflow
Length : Length of VolumeThresholdOverflow attribute Length : Length of VolumeThresholdOverflow attribute
(= 4 octets) (= 4 octets)
VolumeThresholdOverflow (VTO): VolumeThresholdOverflow (VTO):
The optional VolumeThresholdOverflow Sub-Type is used to indicate The optional VolumeThresholdOverflow subtype is used to indicate
how many times the VolumeThreshold counter has wrapped around how many times the VolumeThreshold counter has wrapped around
2^32 over the course of the service being provided. 2^32 over the course of the service being provided.
Sub-Type (=6): Sub-Type for DurationQuota attribute Subtype (=6): Subtype for DurationQuota attribute
Length : length of DurationQuota attribute (= 6 octets) Length : length of DurationQuota attribute (= 6 octets)
DurationQuota (DQ): DurationQuota (DQ):
The optional DurationQuota Sub-Type is only present if Duration The optional DurationQuota Subtype is only present if Duration
Based charging is used. In RADIUS Access-Accept message (PPS to Based charging is used. In RADIUS Access-Accept message (PPS to
SAD direction), it indicates the Duration (in seconds) allocated SAD direction), it indicates the Duration (in seconds) allocated
for the session by the PrePaid server. In on-line RADIUS Access- for the session by the PPS. In on-line RADIUS Access-Accept
Accept message (PPC to PPS direction), it indicates the total message (PPC to PPS direction), it indicates the total Duration
Duration (in seconds) since the start of the accounting session in seconds) since the start of the accounting session related to
related to the QuotaID. the QuotaID.
Sub-Type (=7): Sub-Type for DurationThreshold attribute Subtype (=7): Subtype for DurationThreshold attribute
Length : length of DurationThreshold attribute (= 6 octets) Length : length of DurationThreshold attribute (= 6 octets)
DurationThreshold (DT): DurationThreshold (DT):
The DurationThreshold Sub-Type shall always be present if The DurationThreshold subtype shall always be present if
DurationQuota is present in a RADIUS Access-Accept message (PPS DurationQuota is present in a RADIUS Access-Accept message (PPS
to SAD direction). It represents the duration (in seconds) that to SAD direction). It represents the duration (in seconds) after
shall be used by the session before requesting quota update. This which new quota should be requested. This threshold should not be
threshold should not be larger than the DurationQuota and shall larger than the DurationQuota.
always be sent with the DurationQuota.
Sub-Type (=8): Sub-Type for Update-Reason attribute Subtype (=8): Subtype for Update-Reason attribute
Length : length of Update-Reason attribute (= 4 octets) Length : length of Update-Reason attribute (= 4 octets)
Update-Reason attribute (UR): Update-Reason attribute (UR):
The Update-Reason Sub-Type shall be present in the on-line RADIUS The Update-Reason subtype shall be present in the on-line RADIUS
Access-Request message (SAD to PPS direction). It indicates the Access-Request message (SAD to PPS direction). It indicates the
reason for initiating the on-line quota update operation. Update reason for initiating the on-line quota update operation. Update
reasons 4, 5, 6, 7 and 8 indicate that the associated resources reasons 4, 5, 6, 7 and 8 indicate that the associated resources
are released at the client side, and therefore the PPS shall not are released at the client side, and therefore the PPS shall not
allocate a new quota in the RADIUS Access_Accept message. allocate a new quota in the RADIUS Access_Accept message.
1. Pre-initialization 1. Pre-initialization
2. Initial Request 2. Initial Request
3. Threshold Reached 3. Threshold Reached
4. Quota Reached 4. Quota Reached
5. Remote Forced Disconnect 5. Remote Forced Disconnect
6. Client Service Termination 6. Client Service Termination
7. ôAccess Serviceö Terminated 7. ôAccess Serviceö Terminated
8. Service not established 8. Service not established
9. One-Time Charging 9. One-Time Charging
Sub-Type (=9) : Sub-Type for PrePaidServer attribute Subtype (=9) : Subtype for PrePaidServer attribute
Length : Length of PrePaidServer Length : Length of PrePaidServer
(IPv4 = 6 octets, IPv6= 18 octets (IPv4 = 6 octets, IPv6= 18 octets
PrePaidServer: PrePaidServer:
The optional, multi-value PrePaidServer indicates the address of The optional, multi-value PrePaidServer attribute indicates the
the serving PrePaid System. If present, the Home RADIUS server address of the serving prepaid system. If present, the Home
uses this address to route the message to the serving PrePaid RADIUS server uses this address to route the message to the
Server. The attribute may be sent by the Home RADIUS server. If serving PPS. The attribute may be sent by the Home RADIUS server.
present in the incoming RADIUS Access-Accept message, the PDSN
If present in the incoming RADIUS Access-Accept message, the PDSN
shall send this attribute back without modifying it in the shall send this attribute back without modifying it in the
subsequent RADIUS Access-Request message, except for the first subsequent RADIUS Access-Request message, except for the first
one. If multiple values are present, the PDSN shall not change one. If multiple values are present, the PDSN shall not change
the order of the attributes. their order.
Sub-Type (=10) : Sub-Type for Service ID Subtype (=10) : Subtype for Service ID
Length : Length of Service ID Length : Length of Service ID
Service-Id: Service-Id:
Opaque string that uniquely describes a service instance for which Opaque string that uniquely describes a service instance to which
we want to apply prepaid metering to. A Service-Id could be an IP prepaid metering should be applied. A Service-Id could be an IP
5-tuple (source address, source port, destination address, 5-tuple (source address, source port, destination address,
destination port, protocol). If Service-ID is present in the PPAQ destination port, protocol). If Service-ID is present in the PPAQ
the PPAQ applies to that Service. If a PPAQ does not contain a the PPAQ refers to that service. If a PPAQ does not contain a
Service-Id then the PPAQ applies to the Access Service. Service-Id then the PPAQ refers to the Access Service.
Sub-Type (=11) : Sub-Type for Rating-Group-Id Subtype (=11) : Subtype for Rating-Group-Id
Length : 6 Length : 6
Rating-Group-Id Rating-Group-Id
Identifies that this PPAQ is associated with resources allocated Identifies that this PPAQ is associated with resources allocated
to a Rating Group with the corresponding ID. to a Rating Group with the corresponding ID.
Sub-Type (=12) : Sub-Type for Termination-Action Subtype (=12) : Subtype for Termination-Action
Length : 6 Length : 6
This field is an enumeration of the action to take when the prepaid This field is an enumeration of the action to take when the PPS does
server does not grant additional quota. Valid actions are as not grant additional quota. Valid actions are as follows:
follows:
0 Reserved 0 Reserved
1 Terminate 1 Terminate
2 Request More Quota 2 Request More Quota
3 Redirect/Filter 3 Redirect/Filter
Sub-Type (=13) : Pool-Id Subtype (=13) : Pool-Id
Length : 6 Length : 6
Identifies the Pool that this quota is to be associated with. Identifies the Pool that this quota is to be associated with.
Sub-Type (=14) : Pool-Multiplier Subtype (=14) : Pool-Multiplier
Length : 6 Length : 6
The pool-multiplier determines the weight that resources are The pool-multiplier determines the weight that resources are
inserted into the pool and the rate at which resources are taken out inserted into the pool and the rate at which resources are taken out
of the pool by this Service, or Rating-Group. of the pool by this service or Rating-Group.
Sub-Type (=13) : Sub-Type for Resource Quota Subtype (=15) : Subtype for Resource-Quota
Length : 6 Length : 6
The optional ResourceQuota Sub-Type is only present if Resource The optional Resource-Quota subtype is only present if Resource
Based charging is used or when One-Time charging is being used. Based or one-time charging is used. In the RADIUS Access-Accept
In RADIUS Access-Accept message (PPS to SAD direction), it message (PPS to SAD direction) it indicates the Resources
indicates the Resources allocated for the session by the PrePaid allocated for the session by the PPS. In RADIUS Authorize Only
server. In RADIUS Authorize Only Access-Request message (SAD to Access-Request message (SAD to PPS direction), it indicates the
PPS direction), it indicates the total used resource for both resources used in total, including both incoming and outgoing
forward and reverse traffic applicable to PrePaid accounting. In chargeable traffic. In one-time charging scenarios, the subtype
one-time charging scenarios, the subtype represents the number of represents the number of units to charge or credit the user.
units to charge the user or to credit the user (negative values).
Sub-Type (=14) : Sub-Type for Resource Quota Overflow Subtype (=16) : Subtype for Resource Quota Overflow
Length : 6 Length : 6
Sub-Type (=15) : Sub-Type for ResourceThreshold
Subtype (=18) : Subtype for ResourceThreshold
Length : 6 Length : 6
NOTES: NOTES:
Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear in Volume-Quota, Time-Quota, or Resource-Quota MUST appear in the
the attribute. attribute. If Volume Quota appears, Volume Threshold may also
Volume Threshold may only appear if Volume Quota appears appear.
A PPAQ MUST NOT CONTAIN both a Service-Id and a Rating-Group-Id. A PPAQ MUST NOT contain both a Service-Id and a Rating-Group-Id.
A PPAQ that does not contain a Service-ID or a Rating-Group-Id A PPAQ that does not contain a Service-ID or a Rating-Group-Id
applies to the ôAccess Serviceö. applies to the ôAccess Serviceö.
When the PPAQ contains a Pool-Id it MUST also contain the Pool- When the PPAQ contains a Pool-Id it MUST also contain the Pool-
Multiplier. Multiplier.
5.4 4.4
Prepaid Tariff Switching (PTS) Prepaid Tariff Switching (PTS)
This specification defines the PTS attribute to allow for This specification defines the PTS attribute to allow for
changeovers from one service charge to another during service changeovers from one rate to another during service provision.
execution.
Support for tariff switching is OPTIONAL for both PPC and PPS. PPCs Support for tariff switching is OPTIONAL for both PPC and PPS. PPCs
use the flag "Tariff Switching supported" of the AvailableInClient use the flag "Tariff Switching supported" of the AvailableInClient
subtype of the PPAC attribute to indicate support for tariff subtype of the PPAC attribute to indicate support for tariff
switching; PPSs employ the PTS attribute to announce their support switching. PPSs employ the PTS attribute to announce their support
for tariff switching. Details of this issue are specified later on, for tariff switching. Details of this will be specified after the
when the format of the PTS attribute has been defined. format of the PTS attribute has been defined.
If a RADIUS message contains a PTS attribute, it MUST also contain If a RADIUS message contains a PTS attribute, it MUST also contain
at least one PPAQ attribute. This requirement is related to the at least one PPAQ attribute. If a RADIUS Access-Request message
identification of the service to which tariff switching applies. If contains a PTS attribute or a "Tariff Switching supported" flag, it
a RADIUS Access-Request message contains a PTS attribute or if it MUST also contain an Event-Timestamp RADIUS attribute (see
contains a "Tariff Switching supported" flag, it MUST also contain [RFC2869]).
an Event-Timestamp RADIUS attribute (see [RFC2869]). This
requirement is related to the TariffSwitchInterval subtype of the
PTS attribute (see below).
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 | SUB-TYPE 1 | LENGTH | | TYPE | LENGTH | SUBtype 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIDentifier (QID) | | QuotaIDentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | VolumeUsedAfter- | | SUBtype 2 | LENGTH | VolumeUsedAfter- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitch (VUATS) | SUB-TYPE 3 | LENGTH | | TariffSwitch (VUATS) | SUBtype 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VUATSOverflow (VUATSO) | SUB-TYPE 4 | LENGTH | | VUATSOverflow (VUATSO) | SUBtype 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitchInterval (TSI) | | TariffSwitchInterval (TSI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 5 | LENGTH | TimeIntervalAfter- | | SUBtype 5 | LENGTH | TimeIntervalAfter- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitchUpdate (TITSU) | | TariffSwitchUpdate (TITSU) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PTS Type : Value of PTS
Length: variable, greater than 8 Length: variable, at least 8
Subtype (=1): QuotaIDentifier (QID) Subtype (=1): QuotaIDentifier (QID)
Length : Length of QuotaIDentifier Subtype (= 6 octets) Length : Length of QuotaIDentifier Subtype (= 6 octets)
The QID subtype MUST be present in each PTS attribute. In an The QID subtype MUST be present in each PTS attribute. In an
online RADIUS Access-Request message sent from the PPC to the online RADIUS Access-Request message sent from the PPC to the
PPS, its value MUST be a quota identifier received previously PPS, its value MUST be a quota identifier received previously
from the PPS and MUST be the same as a quota identifier of one of from the PPS and MUST be the same as a quota identifier of one of
the PPAQ attributes included the same RADIUS message. the PPAQ attributes included the same RADIUS message.
A PPAQ attribute that is transported along with a PTS attribute A PPAQ attribute that is transported along with a PTS attribute
and has the same quota identifier value as the PTS attribute in and has the same quota identifier value as the PTS attribute in
its own QID subfield shall be referred to as "accompanying PPAQ its own QID subfield shall be referred to as "accompanying PPAQ
attribute". If a PPS receives an Access-Request message from a attribute". If a PPS receives an Access-Request message from a
PPC, it associates a unique quota identifier to this service PPC, it associates a unique quota identifier to this request.
access request. Thus, a quota identifier also identifies a Thus, a quota identifier also identifies a particular service.
particular service.
Subtype (=2): VolumeUsedAfterTariffSwitch (VUATS) Subtype (=2): VolumeUsedAfterTariffSwitch (VUATS)
Length : Length of VolumeUsedAfterTariffSwitch Subtype Length : Length of VolumeUsedAfterTariffSwitch Subtype
(= 6 octets) (= 6 octets)
The VolumeUsedAfterTariffSwitch subtype SHALL be used in online The VolumeUsedAfterTariffSwitch subtype SHALL be used in online
RADIUS Access-Request messages (PPC to PPS direction). It RADIUS Access-Request messages (PPC to PPS direction). It
indicates the volume (in octets) used during a session after the indicates the volume (in octets) used during a session after the
last tariff switch for the service specified via the QID subfield last tariff switch for the service specified via the QID subfield
and the accompanying PPAQ attribute (see the remarks under and the accompanying PPAQ attribute (see the remarks under
skipping to change at page 48, line 42 skipping to change at page 36, line 19
part of a RADIUS Access-Accept message (PPS to PPC direction). part of a RADIUS Access-Accept message (PPS to PPC direction).
It indicates the interval (in seconds) between the value of It indicates the interval (in seconds) between the value of
Event-Timestamp RADIUS attribute (see [RFC2869]) of the Event-Timestamp RADIUS attribute (see [RFC2869]) of the
corresponding RADIUS Access-Request message and the next tariff corresponding RADIUS Access-Request message and the next tariff
switch condition. switch condition.
Subtype (=5): TimeIntervalafterTariffSwitchUpdate (TITSU) Subtype (=5): TimeIntervalafterTariffSwitchUpdate (TITSU)
Length : Length of TITSU Subtype Length : Length of TITSU Subtype
(= 6 octets) (= 6 octets)
The PPS MUST include the TITSU subtype if there is another tarrif The PPS MUST include the TITSU subtype if there is another tariff
switch period after this period. TITSU represents the length of switch period after this period. The TITSU attributes encodes
the tariff switch period in seconds. If this attribute is the number remaining seconds of current tariff period. If this
omitted or is zero, the tariff period that commences in TSI attribute is zero or omitted, it is assumes that the current
seconds will last indefinitely or until a new PTS is received tariff period lasts until further notice. If TITSU is specified,
with new information. If TITSU is specified, the prepaid client the PPC must send a quota update before the current period ends.
must send a quota update before the end of the tariff switch
period as specified by TITSU.
If a RADIUS message contains a PTS attribute, it MUST also contain If a RADIUS message contains a PTS attribute, it MUST also contain
at least one PPAQ attribute. The PTS will be associated to the PPAQ at least one PPAQ attribute. The PTS is associated with the PPAQ by
by the QID. If multiple services are supported and if the PPAQ is the QID. If multiple services are supported and if the PPAQ is
associated with a service as indicated by the Service-Id sub- associated with a service as indicated by the Service-Id sub-
atrribute of the PPAQ, then the PTS will specify the tarrif switch atrribute of the PPAQ, then the PTS refers to the tariff switch for
for that service. If the PPAQ does not have a Service-Id, then the that service. If the PPAQ does not have a Service-Id, then the PTS
PTS will be the tarrif switch of the Access-Service. 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 the PPAC attribute that is contained in the Access-Request packet of the PPAC attribute that is contained in the Access-Request packet
starting the prepaid session. starting the session.
5.5 4.5
Table of Attributes Table of Attributes
TO BE COMPLETED. TO BE COMPLETED.
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
Authorize_Only Request Accept Reject Authorize_Only Request Accept Reject
6. 5.
Security Considerations Security Considerations
The protocol exchanges described are susceptible to the same The extended RADIUS protocol described in this document is subject
vulnerabilities as RADIUS and it is recommended that IPsec be to a number of potential attacks, in a manner similar to the RADIUS
employed to afford better security. without these extensions. It is recommended that IPsec be employed
to protect against certain of the attacks.
If IPsec is not available the protocol in this draft improves the If IPsec is not available, usage of the extensions described in this
security of RADIUS. The various security enhancements are explained document improve the overall security of RADIUS. The various
in the following sections. security enhancements are explained in the following sections.
6.1 5.1
Authentication and Authorization Authentication and Authorization
RADIUS is susceptible to replay attacks during the Authentication RADIUS is susceptible to replay attacks during the Authentication
and Authorization procedures. A successful replay of the initial and Authorization procedures. A successful replay of the initial
Access-Request could result in an allocation of an initial quota. Access-Request could result in an allocation of an initial quota.
To thwart such an attack... To thwart such an attack...
6.2 5.2
Replenishing Procedure Replenishing Procedure
A successful replay attacks of the Authorize Only Access-Request A successful replay attack of the Authorize Only Access-Request
could deplete the subscribers prepaid account. could deplete the subscribers prepaid account.
To be completed. To be completed.
7. 6.
IANA Considerations 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:
1) Prepaid-Accounting-Capability (PPAC) 1) Prepaid-Accounting-Capability (PPAC)
with subtype: with subtype:
AvailableInClient AvailableInClient
2) Prepaid-Accounting-Operation (PPAQ) 2) Prepaid-Accounting-Operation (PPAQ)
skipping to change at page 51, line 4 skipping to change at page 38, line 21
PrePaidServer (PPS) PrePaidServer (PPS)
ServiceID (SID) ServiceID (SID)
RatingGroupId (RGID) RatingGroupId (RGID)
TerminationAction (TA) TerminationAction (TA)
PoolID (PID) PoolID (PID)
PoolMultiplier (PM) PoolMultiplier (PM)
Cost (COST) Cost (COST)
TariffChangeTime (TCT) TariffChangeTime (TCT)
3) Prepaid-Tariff-Switch (PTS) 3) Prepaid-Tariff-Switch (PTS)
4) Session-Termination-Capability (STC) 4) Session-Termination-Capability (STC)
5) International-Mobile-Subscriber-Identity (IMSI) 5) International-Mobile-Subscriber-Identity (IMSI)
8. 7.
Normative References Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996. Revision 3", RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Server "Remote Authentication Dial In User Server
(RADIUS)", RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
skipping to change at page 51, line 36 skipping to change at page 39, line 14
Holdrege, M., Goyret, I., "RADIUS Attributes for Holdrege, M., Goyret, I., "RADIUS Attributes for
Tunnel Protocol Support" , RFC 2868, June 2000. Tunnel Protocol Support" , RFC 2868, June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D.,
Aboba, B., "Dynamic Authorization Extensions to Aboba, B., "Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service Remote Authentication Dial-In User Service
(RADIUS)", RFC 3576, February 2003. (RADIUS)", RFC 3576, February 2003.
[RFC3748] Aboba, B., et al., "Extensible Authentication [RFC3748] Aboba, B., et al., "Extensible Authentication
Protocol", RFC 3748, June 2004. Protocol", RFC 3748, June 2004.
9. 8.
Informative References Informative References
[DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control [DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control
Application", Internet Draft, AAA WG, April 2004, Application", Internet Draft, AAA WG, April 2004,
Work in Progress. Work in Progress.
[REDIRECT] "RADIUS Redirection", Internet Draft, Work in [REDIRECT] "RADIUS Redirection", Internet Draft, Work in
progress. progress.
10. 9.
Call Flows Call Flows
This section includes call flows illustrating various scenarios This section describes the flows associated with various scenarios
enabled by this specification. that are mentioned in this document. The following fields are used
The following are used in the call flows: in the call flows:
RADIUS packets: RADIUS packets:
AR Access Request AR Access Request
ARA Access Accept ARA Access Accept
AC Accounting Requests AC Accounting Requests
A Authorize-Only Access-Request A Authorize-Only Access-Request
AA Access-Accept for Authorize- AA Access-Accept for Authorize-
Only Access-Request Only Access-Request
skipping to change at page 53, line 5 skipping to change at page 40, line 20
RADIUS RADIUS
MSID Acct-Multi-Session-Id as define MSID Acct-Multi-Session-Id as define
by RADIUS by RADIUS
PPAQ fields: PPAQ fields:
SRVID Service-Id SRVID Service-Id
Reason Update-Reason Reason Update-Reason
QID Quota-Id QID Quota-Id
10.1 9.1
Simple Concurrent Services Simple Concurrent Services
In this scenario the Prepaid Client authenticates and authorizes the In this scenario the PPC authenticates and authorizes the user. The
user. The Prepaid Server responds back with Prepaid Quota for the PSS responds with Quota for the ôAccess Serviceö instance. The NAS
ôAccess Serviceö instance. The NAS then request quota for Service- then request quota for Service-A.
A.
Accounting is turned on. Accounting is turned on.
NAS/ RADIUS/ NAS/ RADIUS/
PPC PPS PPC PPS
=== === === ===
| | | |
| AR{SID,PPAC} | | AR{SID,PPAC} |
A |-------------------------------------------------->| A |-------------------------------------------------->|
| | | |
skipping to change at page 54, line 8 skipping to change at page 41, line 24
| A{SID, | | A{SID, |
| PPAQ(QID=1, Q=100 Reason=Quota), | | PPAQ(QID=1, Q=100 Reason=Quota), |
| PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} | | PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} |
I |-------------------------------------------------->| I |-------------------------------------------------->|
| | | |
| AA{SID, | AA{SID,
| PPAQ(QID=3, Q=200), | | PPAQ(QID=3, Q=200), |
| PPAQ(QID=303, SRVID=SA Q=150)} | | PPAQ(QID=303, SRVID=SA Q=150)} |
J |<--------------------------------------------------| J |<--------------------------------------------------|
A This is the initial Access-Request that indicates the Prepaid A This is the initial Access-Request that indicates the prepaid
Capabilities of the NAS. In this scenario it will indicate capabilities of the NAS. In this example indicates that
that Concurrent Session are supported. Access-Request also Concurrent Sessions are supported. Access-Request also
includes SID (Session Id) which is the Session Identifier includes SID (Session Id) which is the Session Identifier
assigned by this NAS to session. Session Identifier is out of assigned by this NAS to session. The formal of the session
scope in this document. It can be a single attribute such as identifier is outside the scope of this document.
3GPP2 Correlation ID or it could be a set of attributes that B RADIUS authenticates the user and determines that he has a
define a session. prepaid account. RADIUS responds with a PPAQ for the ôAccess
B RADIUS authenticates the user and determines that the user is Serviceö (PPAQ does not contain a Service-ID or Rating-Group-
prepaid. RADIUS responds with a PPAQ for the ôAccess Serviceö ID). The PPAQ has a QID=1 assigned by the Prepaid System and
(PPAQ does not contain a Service-ID or Rating-Group-ID). The Quota of Q=100. The quota could be time or volume and may or
PPAQ has a QID=1 assigned by the Prepaid System and Quota of may not have a threshold associated with it.
Q=100. The quota could be time or volume and may or may not C The NAS starts the Access Service and generates an Accounting-
have a threshold associated with it. Request (Start) message as normal. It includes the Acct-
C NAS starts the Access Service and generates an Accounting-
Request (Start) message as normal. It will include the Acct-
Session-Id and may include the Acct-Multi-Session-Id. Session-Id and may include the Acct-Multi-Session-Id.
D The NAS wants to start a new Service, call it Service-A. It D The NAS is about to start a new Service, call it Service-A.
sends an Authorize-Only access request to RADIUS. The SID It sends an Authorize-Only access request to RADIUS. The SID
links this Authorize-Only access request to the initial links this Authorize-Only access request to the initial
Authentication & Authorization (Step-A and Step-B).The Authentication & Authorization (Step-A and Step-B).The
Authorize-Only message contains a PPAQ requesting quota for Authorize-Only message contains a PPAQ requesting quota for
Service-A, Update-Reason = Initial-Request. Service-A, Update-Reason = Initial-Request.
E PPS checks the resources available to the user and assigns 50
units (time/volume etc) to this service. RADIUS sends an E The PPS checks the resources available to the user and assigns
50 units (time/volume etc) to this service. RADIUS sends an
Access Accept message contain a PPAQ assigning quota Q=50 for Access Accept message contain a PPAQ assigning quota Q=50 for
Service-A. The PPAQ contains a QID = 200. Service-A. The PPAQ contains a QID = 200.
F NAS starts Service-A and sends an Accounting-Request (Start) F The NAS starts Service-A and sends an Accounting-Request
message for that service. Acct-Multi-Session-Id can be used (Start) message for that service. Acct-Multi-Session-Id can be
to tie all of the sessions in the accounting streams together. used to tie all of the sessions in the accounting streams
together.
G Quota for Service-A requires refreshing, the quota was G Quota for Service-A requires refreshing, the quota was
completely used). An Authorize-Only message is sent completely used). An Authorize-Only message is sent
containing a PPAQ with QID = 200 which corresponds to the containing a PPAQ with QID = 200 which corresponds to the
prior QID received for this service. Note QID is sufficient prior QID received for this service. Note QID is sufficient
for the PPS server to link this request to the previous for the PPS server to link this request to the previous
request and hence to the original authentication steps. request and hence to the original authentication steps.
Therefore SID is not really required. The PPAQ will report the Therefore SID is not really required. The PPAQ will report the
used part of the quota (50 units). used part of the quota (50 units).
H RADIUS deducts the used quota from the users accounts and H RADIUS deducts the used quota from the users accounts and
reserves 50 more additional units for a total quota of 100 reserves 50 more additional units for a total quota of 100
(Q=100) for Service-A. It sends back a PPAQ with QID=300. (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. I NAS needs to refresh both the ôAccess Serviceö and Service-A.
It sends an Authorize Only message contain two PPAQs, one for It sends an Authorize Only message contain two PPAQs, one for
the Main Service with QID=1 and one for Service-A with the Main Service with QID=1 and one for Service-A with
QID=300. Each PPAQ reports the used resources so far and the QID=300. Each PPAQ reports the resources that were consumed
reason why the update is being sent. so far and the reason why the update is being sent.
J RADIUS responds back with two PPAQs. The PPAQ without the J RADIUS responds back with two PPAQs. The PPAQ without the
Service-Id grants an additional 100 units for a total of 200 Service-Id grants an additional 100 units for a total of 200
units to the ôAccess Serviceö û QID=3; the other PPAQ, units to the ôAccess Serviceö û QID=3; the other PPAQ,
containing SRVID=SA grants an additional 50 units for a total containing SRVID=SA grants an additional 50 units for a total
quota to service-a of 150 units û QID=303. quota to service-a of 150 units û QID=303.
This step illustrates why SRVID needs to be specified in the This step illustrates why SRVID needs to be specified in the
PPAQ. If it were not, then the NAS would not be able to PPAQ. Without it the NAS would be unable to differentiate
differentiate between the PPAQs. QIDs are not sufficient to between the PPAQs. QIDs are not sufficient to correlate the
correlate the PPAQ to a service since they are changed (and PPAQ to a service since they may be changed by the PPS at
not necessarily sequentially) by the PPS at every transaction. every transaction.
In this scenario, notice how each PPAQ attribute represents a Note how each PPAQ attribute represents a sequential conversation
sequential conversation about a service between the Prepaid Client about a service between the PPC and the PPS in this example. The
and the Prepaid Server. The links between the messages are the QIDs links between the messages are the QIDs and the Service-Ids.
and the Service-Ids.
As well, notice how a SID is needed to tie the Authorize-Only Also note that a SID is needed to tie the Authorize-Only messages to
messages to the Authentication steps. This SID is only really the Authentication steps. This SID is only really needed the first
needed the first time a PPAQ is sent û since the PPAQ does not have time a PPAQ is sent.
a QID.
Accounting messages have an Accounting-Session-ID. But that is not Although accounting messages have an Accounting-Session-ID, that is
enough to allow the back end system to associate that accounting not enough to enable the back end system to associate that
message with a particular Service. We therefore need the PPAQ in accounting message with a particular Service. We therefore need the
the accounting message. PPAQ in the accounting message.
10.2 9.2
One-time Charging One-time Charging
In this One-time charging scenario, the Prepaid Client (PPC) In this One-time charging example, the PPC authenticates and
authenticates and authorizes the user and requests charging for a authorizes the user and requests charging for a service event
service event requested by the user. The PPC already knows the requested by the user. The PPC already knows the price to charge
price to charge for the service event identified by SRVID=SA. for the service event identified by SRVID=SA.
Contributor Contributor
We would like to thank Hannes Tschofenig for his contributions to We would like to thank Hannes Tschofenig for his contributions to
this draft. this draft.
Acknowledgments Acknowledgments
The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala
and Tseno Tsenov for their contribution to this draft. and Tseno Tsenov for their contribution to this draft.
skipping to change at page 56, line 25 skipping to change at page 43, line 38
Author's Addresses Author's Addresses
Avi Lior Parviz Yegani, Ph.D. Avi Lior Parviz Yegani, Ph.D.
Bridgewater Systems Mobile Wireless Group Bridgewater Systems Mobile Wireless Group
303 Terry Fox Drive Cisco Systems 303 Terry Fox Drive Cisco Systems
Suite 100 3625 Cisco Way Suite 100 3625 Cisco Way
Ottawa Ontario San Jose, CA 95134 Ottawa Ontario San Jose, CA 95134
Canada USA Canada USA
avi@bridgewatersystems.com pyegani@cisco.com avi@bridgewatersystems.com pyegani@cisco.com
Kuntal Chowdhury Yong Li Kuntal Chowdhury Hannes Tschofenig
Starent Networks Bridgewater Systems Starent Networks Siemens
30 International Place, 3rd Flr 303 Terry Fox Drive 30 International Place, 3rd Flr Otto-Hahn-Ring 6
Tewksbury, MA 01876 Suite 100 Tewksbury, MA 01876 81739 Munich
kchowdhury@starentnetworks.com Ottawa Ontario kchowdhury@starentnetworks.com Germany
Canada hannes.tschofenig@siemens.com
Yong.li@bridgewatersystems.com
Christian Guenther Christian Guenther
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
christian.guenther@siemens.com christian.guenther@siemens.com
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 57, line 32 skipping to change at page 44, line 40
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an ôAS ISö basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright ¨ The Internet Society (2005). This document is subject to Copyright ¨ The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Expiration Date Expiration Date
This memo is filed as draft-lior-radius-extensions-for-prepaid- This memo is filed as draft-lior-radius-extensions-for-prepaid-
07.txt, and will expire 20 July, 2005. 06.txt, and will expire 20 July, 2005.
10.
Appendix A û use cases
In this appendix we present a set of use cases and scenarios based
on which the extensions in this document were designed. It is
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
communications between the SAD and the network. The connection
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
Simple prepaid use case
A subscriber connects to his home network. As usual, the Access
Device that is servicing the subscriber uses the AAA infrastructure
to authenticate and authorize the subscriber.
The SAD sends a RADIUS Access-Request to the AAA server in order to
authenticate and authorise the subscriber with respect to the
requested service. The Access-Request contains the subscriber
credentials and may contain the prepaid capabilities of the SAD.
Prepaid capabilities MUST be included if the SAD supports them.
The AAA System proceeds with the authentication procedure. This may
involve several message exchanges such as in EAP [RFC2284]. Once
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
that the account is active. It further validates that the SAD has
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
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.
The AAA system incorporates the attributes received from the prepaid
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
session and meters the session based on time or volume, as indicated
in the message.
Once the usage for the session approaches the allocated limit (as
expressed by the threshold), the SAD will request additional quota.
Re-authorization for additional quota flows through the AAA system
to the prepaid System. The prepaid System revalidates the
subscriberÆs 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 prepaid System rejects the request. Note the
replenishing of the quotas is a re-authorization procedure and does
not require the subscriber to authenticate himself again.
It is important to note that the prepaid System is maintaining
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) prepaid
system.
Upon receiving a re-allotment of the quota, the SAD continues to
provide the data service until the new threshold is reached. If the
request for additional quota cannot be fulfilled then the SAD lets
the subscriber use the remaining quota and terminates the 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 their account. This restriction can also be
used to allow new subscribers to set up prepaid accounts in the
first place.
Should the subscriber terminate the session before the quota is
exhausted, the remaining balance allotted to the session MUST be
refunded into the subscriberÆs account.
While the Access Device is waiting for the initial quota, the
subscriber may have dropped the connection/session. The entire
allocated quota MUST be credited back to the subscribers account in
this case.
10.2
Support for Multi-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 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.
+---------+
| Session |
+---------+
|
V N
+--------------+ +-------+
| Service |------>| Quota |
| (service-Id) | +-------+
+--------------+
As shown in the above diagram, a Session may be associated with
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
Resource Pools
When working with multiple services a new problem arises because one
service may utilize its quota faster than another service. When the
userÆs 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 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.
Resource pools enable the allocation of resources to several
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.
+-----------+
| Service-A |-----+ +--------+
+-----------+ | Ma | |
+-------->| |
| Pool |
+-------->| (1) |
+-----------+ | Mb | |
| Service-B |-----+ +--------+
+-----------+
As the figure above shows, 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 each
service and multiplying it by Mn. Therefore, the amount of
resources allocated to a pool is given by:
Poolr = Ma*Qa + Mb*Qb + . . .
A Pool is empty if:
Poolr <= Ca*Ma + Cb*Mb + . . .
where:
Ca,Cb are the consumed resources of 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 Mbyte and
Service-B can rated at $0.10 per Minute. In this case if we allocate
$5 worth of resources on behalf of service-A to the pool we would
set Ma = 10 and place 50 units into the pool. If we allocate $5 on
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
Support for Complex Rating Functions
The rating of a service can be quite complex. While some operators
follow linear charging 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 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
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.
+-----------+
| Service-A |------+
+-----------+ | +--------------+ +-------+
+---->| | | Quota |
| Rating Group |------>| or |
+-----------+ +---->| | | Pool |
| Service-B |------+ +--------------+ +-------+
+-----------+
During consumption of a service that is associated with a Rating
Group, the PPC sends the ID of the Rating Group to the PPS. The
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
instantiated, the PPC does not need to authorize this service. This
limits the amount of traffic between the PPC and the PPS.
10.5
One-Time-based Charging
One-Time-based Charging is used for charging of service events
without an ongoing session. That is, the service is provisioned
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
other charging models. For example, the subscriber may access a
website which is metered (based on time or volume) while he also
purchase 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 exempt from charging.
The SAD signals one-time-based charging to the PPS with an
indication that identifies the service and the units that need to be
debited from the userÆs account.
One-time-based charging may occur under two conditions: the (a) SAD
may not have a authenticated context (or access to an authenticated
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
prepaid userÆs 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.
10.6
Support for Tariff Switching
The PPC and the PPS may support tariff switching as described
earlier. For example, as shown in the figure below, traffic before
18:00 may be rated at ær1Æ and traffic after 18:00 hours is rated at
ær2Æ. The PPC reports usage before and after the switch occurs.
Tariff switching only makes sense for volume based metering where
the volume is billed at different rates.
18:00
------------------+-----------------
r1 | r2
------------------+-----------------
^ ^
|<----TSI---> |
| |
Access-Accept Access-Request
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Æs VUATS subtype.
If the PPC sends this message before the tariff switch, the PPS will
respond with another PTS where the TSI is appropriately updated.
In situations with multiple tariff switches, as shown below, the PPS
MUST specify the length of the tariff switch period using the
TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute.
18:00 23:30
------------------+---------------------+--------------
r1 | r2 | r3
------------------+---------------------+--------------
^ ^ ^
|<----TSI---><-----------|-------->|TITSU
| |
Access-Accept Access-Request
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,
insufficient traffic is generated 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.
10.7
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 prepaid system 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 functionality. Even in this case the system
should be able to continue the prepaid session.
10.8
Termination of a prepaid session
When fraud or an error is detected, the either only the affected
session, or all sessions of the affected subscriber should be
terminated.
It may happen that the prepaid system enters a state where it is
unclear whether or not the data session is in progress. Under such a
condition, the system may wish to terminate the session in order to
make sure that the user is not billed 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.
10.9
Querying and Rebalancing Prepaid Resources
It should be possible for the PPS to Query the current resource
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
event) but the userÆs account is depleted but 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 doesnÆt 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.
 End of changes. 286 change blocks. 
1447 lines changed or deleted 905 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/