< draft-lior-radius-prepaid-extensions-05.txt   draft-lior-radius-prepaid-extensions-06.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-05.txt Cisco draft-lior-radius-prepaid-extensions-06.txt Cisco
Expires: 17 January, 2005 K. Chowdhury Expires: 24 March, 2005 K. Chowdhury
Nortel Nortel
Y. Li Y. Li
Bridgewater Systems Bridgewater Systems
July 19, 2004 C. Guenther
Siemens
October 25, 2004
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, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance and any of which I become aware will be disclosed, in accordance
with RFC 3668. with RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 41
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 reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005 This Internet-Draft will expire on March 24, 2005
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The draft presents an extension to the Remote Authentication Dial-In This draft presents an extension to the Remote Authentication Dial-
User Service (RADIUS) protocol to support PrePaid data services for In User Service (RADIUS) protocol to support charging for prepaid
a wide range of deployments such as Dial, Wireless, WLAN. services. The charging models supported are namely: volume-based
Consideration for roaming using mobile-ip is also given. 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................................................6
1.2 Requirements language......................................6 1.2 Requirements language......................................6
2. Architectural Model............................................6 2. Overview.......................................................6
2.1 Why not existing RADIUS attributes?.......................12 2.1 PrePaid Charging Model.....................................7
3. Use-cases.....................................................14 2.2 Architectural Model........................................7
2.3 Why not existing RADIUS attributes?.......................13
3. Use-cases.....................................................15
3.1 Simple pre-paid access use-case...........................15 3.1 Simple pre-paid access use-case...........................15
3.2 Support for Multi-Services................................17 3.2 Support for Multi-Services................................17
3.3 Resource Pools............................................18 3.3 Resource Pools............................................18
3.4 Support for Complex Rating Functions......................19 3.4 Support for Complex Rating Functions......................20
3.5 Support for Roaming.......................................20 3.5 One-Time-based Prepaid Charging...........................21
3.6 PrePaid termination.......................................21 3.6 Support for Roaming.......................................22
4. Operations....................................................21 3.7 PrePaid termination.......................................23
4.1 General Requirements......................................21 3.8 Querying and Rebalancing Prepaid Resources................23
4.1.1 Broker AAA Requirements..............................21 4. Operations....................................................24
4.2 Authentication and Authorization for Prepaid Enabled Service 4.1 General Requirements......................................24
Access Devices................................................22 4.1.1 Broker AAA Requirements..............................24
4.3 Session Start Operation...................................24 4.2 Authentication and Authorization for Prepaid Enabled SADs.24
4.4 Mid-Session Operation.....................................25 4.3 Session Start Operation...................................26
4.5 Dynamic Operations........................................27 4.4 Mid-Session Operation.....................................27
4.5.1 Unsolicited Session Termination Operation............27 4.5 Dynamic Operations........................................29
4.5.2 Unsolicited Change of Authorization Operation........28 4.5.1 Unsolicited Session Termination Operation............30
4.6 Termination Operation.....................................28 4.5.2 Unsolicited Change of Authorization Operation........30
4.7 Mobile IP Operations......................................29 4.6 Termination Operation.....................................31
4.8 Operation consideration for Multi-Services................30 4.7 Mobile IP Operations......................................31
4.8.1 Initial Quota Request................................31 4.8 Operation consideration for Multi-Services................32
4.8.2 Quota Update.........................................31 4.8.1 Initial Quota Request................................33
4.8.3 Termination..........................................32 4.8.2 Quota Update.........................................33
4.8.4 Dynamic Operations...................................32 4.8.3 Termination..........................................34
4.8.5 Support for Resource Pools...........................32 4.8.4 Dynamic Operations...................................34
4.8.6 Error Handling.......................................33 4.8.5 Support for Resource Pools...........................35
4.9 Accounting Considerations.................................33 4.8.6 One-Time-Charging....................................35
4.10 Service Access Device Operation..........................33 4.8.7 Error Handling.......................................36
4.11 Interoperability with Diameter Credit Control Application33 4.9 Accounting Considerations.................................36
5. Attributes....................................................34 4.10 SAD Operation............................................36
5.1 PPAC Attribute............................................34 4.11 Interoperability with Diameter Credit Control Application36
5.2 Session Termination Capability............................35 5. Attributes....................................................37
5.3 PPAQ Attribute............................................35 5.1 PPAC Attribute............................................37
5.4 Table of Attributes.......................................41 5.2 Session Termination Capability............................38
6. Security Considerations.......................................41 5.3 PPAQ Attribute............................................38
6.1 Authentication and Authorization..........................41 5.4 Table of Attributes.......................................44
6.2 Replenishing Procedure....................................41 6. Security Considerations.......................................44
7. IANA Considerations...........................................42 6.1 Authentication and Authorization..........................45
8. Normative References..........................................42 6.2 Replenishing Procedure....................................45
9. Call Flows....................................................42 7. IANA Considerations...........................................45
9.1 Simple Concurrent Services................................43 8. Normative References..........................................46
Acknowledgments..................................................46 9. Informative References........................................46
Author's Addresses...............................................46 10. Call Flows...................................................47
Intellectual Property Statement..................................47 10.1 Simple Concurrent Services...............................48
Disclaimer of Validity...........................................47 10.2 One-time Charging........................................50
Copyright Statement..............................................48 Contributor......................................................51
Expiration Date..................................................48 Acknowledgments..................................................51
Author's Addresses...............................................51
Intellectual Property Statement..................................52
Disclaimer of Validity...........................................52
Copyright Statement..............................................52
Expiration Date..................................................53
1. Introduction 1. Introduction
This draft describes RADIUS protocol extensions supporting PrePaid This draft describes RADIUS protocol extensions supporting charging
Data Services. for PrePaid Data Services.
PrePaid data services are cropping up in many wireless and wireline PrePaid data services are cropping up in many wireless and wireline
based networks. A PrePaid Data Service subscriber is one that based networks. A PrePaid Data Service subscriber is one that
purchases a contract to receive a data service for either a period purchases a contract to receive a data service for either a period
of time, or a quantity of data. Before providing a prepaid data of time, or a quantity of data. Before providing a prepaid data
service, the service provider checks that the prepaid subscriber has service, the service provider checks that the prepaid subscriber has
sufficient funds to cover the particular service request. Only after sufficient funds to cover the particular service request. Only after
confirmation that funds are available is the service provided to the confirmation that funds are available is the service provided to the
user. user.
skipping to change at page 5, line 6 skipping to change at page 5, line 6
- Ability to rate service requests in real-time; - Ability to rate service requests in real-time;
- Ability to check that the end userÆs account for coverage for the - Ability to check that the end userÆs account for coverage for the
requested service charge prior to execution of that service; requested service charge prior to execution of that service;
- Protect against revenue loss, i.e., prevent an end user from - Protect against revenue loss, i.e., prevent an end user from
generating chargeable events when the credit of that account is generating chargeable events when the credit of that account is
exhausted or expired; exhausted or expired;
- Protect against fraud; - Protect against fraud;
- Be as widely deployable over Dialup, Wireless and WLAN networks. - Be as widely deployable over Dialup, Wireless and WLAN networks.
The protocol described in this document maximizes existing The protocol described in this document maximizes existing
infrastructure as much as possible û hence the use of the RADIUS infrastructure as much as possible hence the use of the RADIUS
protocol. The protocol is used in ways to protect against revenue protocol. The protocol is used in ways to protect against revenue
loss or revenue leakage. This is achieved by defining procedures loss or revenue leakage. This is achieved by defining procedures
for the real-time delivery of service information to a pre-paid 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 minimize the financial risk, for the pre-paid
enabled AAA server to be able to allocate small quotas to each data 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 session and having the ability to update the quotas from a central
quota server dynamically during the lifetime of the PrePaid data quota server dynamically during the lifetime of the PrePaid data
session. As well, mechanisms have been designed to be able to session. As well, mechanisms have been designed to be able to
recover from errors that occur from time to time. recover from errors that occur from time to time.
Protection against fraud is provided by recording of accounting Protection against fraud is provided by recording of accounting
records, by providing mechanisms to thwart replay attacks. As well, records, and by providing mechanisms to thwart replay attacks. As
mechanisms have been provided to terminate data sessions when fraud well, mechanisms have been provided to terminate data sessions when
is detected. fraud is detected.
PrePaid System will become more prevalent and sophisticated as the PrePaid Systems will become more prevalent and sophisticated as the
various networks such as Dialup, Wireless and WLAN converge. This various networks such as Dialup, Wireless and WLAN converge. This
protocol extension is designed to meet the challenges of converged protocol extension is designed to meet the challenges of converged
networks. The draft mainly addresses how to use the RADIUS protocol networks. The draft mainly addresses how to use the RADIUS protocol
to achieve a PrePaid Data Service. The prepaid architecture assumes to achieve a PrePaid Data Service. The prepaid architecture assumes
that rating of chargeable events does not occur in the element that rating of chargeable events does not occur in the element
providing the service. This rating could be performed in the prepaid providing the service. This rating could be performed in the prepaid
enabled AAA server or may exist in an entity behind this AAA server. enabled AAA server or may exist in an entity behind this AAA server.
Business logic and service rules may define that tariffing of events Business logic and service rules may define that tariffing of events
vary in time, e.g., the particular price per megabyte download may vary in time, e.g., the particular price per megabyte download may
be defined to switch at 8pm from a high tariff to a low tariff. The be defined to switch at 8pm from a high tariff to a low tariff. The
skipping to change at page 6, line 8 skipping to change at page 6, line 8
could be performed in the prepaid enabled AAA server or may exist in could be performed in the prepaid enabled AAA server or may exist in
an entity behind this AAA server. Finally, the details of the an entity behind this AAA server. Finally, the details of the
PrePaid System, such as its persistent store, how it maintains its PrePaid System, such as its persistent store, how it maintains its
accounts are not covered at all. However, in order to define the accounts are not covered at all. However, in order to define the
RADIUS protocol extensions it is necessary to discuss the functional RADIUS protocol extensions it is necessary to discuss the functional
behavior of the PrePaid System. behavior of the PrePaid System.
1.1 Terminology 1.1 Terminology
Service Access Device Service Access Device
PrePaid Client(PPC) PrePaid Client(PPC) The Prepaid Client (PPC) is the entity which
PrePaid Server(PPS) triggers the RADIUS message exchange
Home agent (HA) including prepaid extensions defined in this
Home network document. Typically the Prepaid Client
Home AAA (HAAA) Resides in the NAS.
Broker AAA (BAAA) PrePaid Server(PPS) The Prepaid Server is the entity that
Visited AAA (VAAA) interacts with the Prepaid Client using the
Foreign Agent (FA) RADIUS prepaid extensions defined in this
WLAN document.
Home network The network which contains the user profile
and the userÆs prepaid account.
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. In this document the term is
used to differentiate between authorization used to differentiate between authorization
of services that are explicitly identified of services that are explicitly identified
by a Service Id. Example of Access Service by a Service Identifier. Example of Access
would be the Main Service instance of 3GPP2. Service would be the Main Service instance
of 3GPP2.
Furthermore, we use the following Mobile IP and AAA terminology:
Home agent (HA), Home network, Home AAA (HAAA), Broker AAA (BAAA),
Visited AAA (VAAA) and Foreign Agent (FA)
1.2 Requirements language 1.2 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. Architectural Model 2. Overview
This section gives a concise overview of the Prepaid Charging models
that is supported by this document, and the Architectural model
relevant to this draft.
2.1 PrePaid Charging Model
There are several PrePaid Charging models of how to charge customers
for availing data services:
. Volume-based charging (VBC): (e.g., 2 Cents/KiloByte);
. Duration-based charging (DBC): (e.g., 3 Cents/minute);
. Subscription-based charging (SBC): (e.g.,
Dollars/month+service);),
. Event-based charging (EBC): (e.g., 7 Cents/URL or email).
Charging models can be further divided into those with debiting of
prepaid user accounts and those with debiting of non-prepaid
accounts (such as current accounts at banks). From the perspective
of this document all userÆs as treated as userÆs having a prepaid
accounts.
2.2 Architectural Model
The architectural model supports prepaid clients on a service access The architectural model supports prepaid clients on a service access
device. A service access device (e.g. a NAS) typically provides a device. A SAD (e.g. a NAS) typically provides a access to data
access to data service to end-users. A service access device in an service to end-users. A SAD is a network entity on the data path
entity on the data path that includes a RADIUS client. that includes a RADIUS client and a PrePaid Client.
When pre-paid service is used the service access device collects When prepaid service is used the SAD collects service event
service event information and reports it while and/or after services information and reports it while and/or after services are provided
are provided to the prepaid user. This event information is sent to to the prepaid user. This event information is sent to a prepaid
a prepaid server by using the prepaid RADIUS extensions. server by using the prepaid RADIUS extensions.
If real-time credit control is required, the service access device If real-time credit control is required, the SAD (prepaid client)
(prepaid client) contacts the prepaid server with service event contacts the prepaid server with service event information included
information included before the service is provided. The prepaid before the service is provided. The prepaid server, depending on the
server, depending on the service event information, performs credit service event information, performs credit check and allocates a
check and allocates a portion of available credit to the service portion of available credit to the service event. The rating entity
event. The rating entity converts this credit value into a time converts this credit value into a time and/or volume amount, which
and/or volume amount, which is then returned to the requesting is then returned to the requesting SAD. The rating entity may
service access device. The rating entity may determine that during determine that during the allocated quota, a tariff switch will
the allocated quota, a tariff switch will occur in which case the occur in which case the rating entity will include details of the
rating entity will include details of the quota allocated prior to quota allocated prior to the tariff switch, details of the quota
the tariff switch, details of the quota allocated after the tariff allocated after the tariff switch together with details of when the
switch together with details of when the tariff switch will occur. tariff switch will occur.
The requesting service access device then monitors service execution The requesting SAD then monitors service execution according to the
according to the instructions returned by the prepaid server. After instructions returned by the prepaid server. After service
service completion or on a subsequent request for service, the completion or on a subsequent request for service, the prepaid
prepaid server deducts the reserved allocation of credit from the server deducts the reserved allocation of credit from the prepaid
prepaid userÆs account. userÆs account.
Similarly, when a user terminates an on-going prepaid service, the Similarly, when a user terminates an on-going prepaid service, the
prepaid client signals the prepaid server with the a value prepaid client signals the prepaid server with the a value
corresponding to the unused portion of the allocated quota. The corresponding to the unused portion of the allocated quota. The
prepaid server is then able to refund unused allocated funds into a prepaid server is then able to refund unused allocated funds into a
userÆs prepaid account. userÆs prepaid account.
There MAY be multiple prepaid servers in the system for reasons of There MAY be multiple prepaid servers in the system for reasons of
redundancy and load balancing. The system MAY also contain separate redundancy and load balancing. The system MAY also contain separate
rating server(s) and accounts MAY be located in a centralized rating server(s) and accounts MAY be located in a centralized
skipping to change at page 8, line 29 skipping to change at page 9, line 6
The prepaid server and accounting server in this architecture model The prepaid server and accounting server in this architecture model
are logical entities. The real configuration MAY combine them into a are logical entities. The real configuration MAY combine them into a
single host. single host.
There MAY exist protocol transparent RADIUS Proxies between prepaid There MAY exist protocol transparent RADIUS Proxies between prepaid
client and prepaid server. These proxies transparently support the client and prepaid server. These proxies transparently support the
prepaid RADIUS extensions. prepaid RADIUS extensions.
In order to generalize the solution, in this paper we generalize the In order to generalize the solution, in this paper we generalize the
Service Access Devices, which in reality may be a NAS in Dialup SADs, which in reality may be a NAS in Dialup deployments, PDSN
deployments, PDSN (Packet Data Serving Node) or HA (Home Agent) in (Packet Data Serving Node) or HA (Home Agent) in CDMA2000
CDMA2000 deployments, an 802.11 WLAN Access Points or GGSN (Gateway deployments, an 802.11 WLAN Access Points or GGSN (Gateway GPRS
GPRS Serving Node) in GPRS/UMTS deployments. To actively participate Serving Node) in GPRS/UMTS deployments. To actively participate in
in Prepaid procedures outlined here, the Service Access Device MUST Prepaid procedures outlined here, the SAD MUST have the Prepaid
have the Prepaid Client capabilities. Prepaid Client Capabilities Client capabilities. Prepaid Client Capabilities include the
include the ability to meter the usage for a prepaid data session; ability to meter the usage for a prepaid data session; this usage
this usage includes time or volume (e.g. number of bytes) usage. includes time or volume (e.g. number of bytes) usage.
In the case of roaming scenarios using mobile IP (in a wireless or In the case of roaming scenarios using mobile IP (in a wireless or
wireline network), the prepaid client functionality may be delegated wireline network), the prepaid client functionality may be delegated
to the Home Agent. It may also be possible to deliver limited to the Home Agent. It may also be possible to deliver limited
prepaid services using RADIUS capabilities specified in RFC2865 and prepaid services using RADIUS capabilities specified in RFC2865 and
RFC2866. RFC2866.
Furthermore, the device including the prepaid client functionality Furthermore, the device including the prepaid client functionality
may also have Dynamic Session Capabilities that include the ability may also have Dynamic Session Capabilities that include the ability
to terminate a data session and/or change the filters associated to terminate a data session and/or change the filters associated
skipping to change at page 9, line 27 skipping to change at page 10, line 4
networks. The AAA servers in the broker networks, BAAA are networks. The AAA servers in the broker networks, BAAA are
responsible to route the RADIUS packets transparently and hence responsible to route the RADIUS packets transparently and hence
donÆt play an active roll in the Prepaid Data Service delivery. donÆt play an active roll in the Prepaid Data Service delivery.
In this document the Prepaid Server is described in functional terms In this document the Prepaid Server is described in functional terms
related to their interface with the HAAA. The Prepaid Server related to their interface with the HAAA. The Prepaid Server
interfaces to entities which: interfaces to entities which:
i) Keep the accounting state of the prepaid subscribers (balance i) Keep the accounting state of the prepaid subscribers (balance
manager); manager);
ii) Allow access service requests to be rated in real-time (Rating ii) Allow access service requests to be rated in real-time (Rating
Engine); and Engine); and
iii) Allow quota to be managed for a particular pre-paid service iii) Allow quota to be managed for a particular pre-paid service
(Quota Server). (Quota Server).
The various deployments for Prepaid are presented in the remainder The various deployments for Prepaid are presented in the remainder
of this section. The first deployment is the basic Prepaid data of this section. The first deployment is the basic Prepaid data
service and is depicted in figure 2. Here the Service Access Device service and is depicted in figure 2. The SAD, which supports the
which supports the prepaid client functionality, the HAAA and the prepaid client functionality, the HAAA and the Prepaid Server are
Prepaid Server are collocated 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 several
Access Devices in the network. The Service Access Device Access Devices in the network. The SAD communicates with one or
communicates with one or more HAAA servers in the network. To more HAAA servers in the network. To provide redundancy more than
provide redundancy more than one HAAA may be available to use by a one HAAA may be available to use by a SAD.
Service Access Device.
The network will have one or more Prepaid Servers. Multiple Prepaid The network will have one or more Prepaid Servers. Multiple Prepaid
Servers may be used to provide redundancy and load sharing. The Servers may be used to provide redundancy and load sharing. The
interface between the HAAA and the PPS is implemented using the interface between the HAAA and the PPS is implemented using the
RADIUS protocol in this specification. 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 whatever
protocol is used between the HAAA and the PPS. protocol is used between the HAAA and the PPS.
+------+ +-----+ +------+ +-----+
skipping to change at page 10, line 45 skipping to change at page 11, line 23
+------+ +-------+ +-|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 Service Access Device (NAS, WLAN establishes a connection with the SAD (NAS, WLAN Access Point).
Access Point). The Service Access Device communicates with the The SAD communicates with the Visiting AAA server (VAAA) using the
Visiting AAA server (VAAA) using the RADIUS protocol. Again for RADIUS protocol. Again for redundancy there maybe more then one
redundancy there maybe more then one VAAA. The VAAA communicate VAAA. The VAAA communicate using the RADIUS protocol with AAA
using the RADIUS protocol with AAA servers in the broker network servers in the broker network (BAAA). There maybe more then one
(BAAA). There maybe more then one Broker Network between the Broker Network between the Visited Network and the Home Network.
Visited Network and the Home Network. The Home Network is the same The Home Network is the same as in the simple architecture.
as in the simple architecture.
To support dynamic roaming the network will utilize Mobile-Ip as To support dynamic roaming the network will utilize Mobile-Ip as
illustrated in Figure 4. Note that typically the mobile device illustrated in Figure 4. Note that typically the mobile device
would be moving between networks that use the same technology such would be moving between networks that use the same technology such
as Wireless or WLAN. Increasingly, device will be able to roam as Wireless or WLAN. Increasingly, device will be able to roam
between networks that use different technology such as between WLAN between networks that use different technology such as between WLAN
and Wireless and Broadband. Fortunately, Mobile-Ip can address this and Wireless and Broadband. Fortunately, Mobile-Ip can address this
type of roaming and therefore we need not be concerned with the type of roaming and therefore we need not be concerned with the
underlying network technology. underlying network technology.
skipping to change at page 11, line 40 skipping to change at page 12, line 25
| | | | | | | |
V +----+ | +----+ V +----+ | +----+
+------+ +-------+ | | | | +------+ +-------+ | | | |
| | |Service| +-|VAAA+------+ | | | |Service| +-|VAAA+------+ |
|Sub | |Access | | | | | |Sub | |Access | | | | |
| |--|Device +-+ +----+ | | |--|Device +-+ +----+ |
|Device| | (FA) | | |Device| | (FA) | |
| | | +------------------------+ | | | +------------------------+
+------+ +-------+ +------+ +-------+
Figure 4 Roaming using Mobile-IP and pre-paid enabled Service Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs
Access Devices
In figure 4, the Subscriber device establishes a prepaid session In figure 4, the Subscriber device establishes a prepaid session
between the Service Access Device in the foreign network, which has between the SAD in the foreign network, which has prepaid
prepaid capabilities. The subscriberÆs home address will be capabilities. The subscriberÆs home address will be anchored at the
anchored at the Home Agent (HA) in the home network. The setup for Home Agent (HA) in the home network. The setup for this access
this access service is identical to the cases covered above. Notice service is identical to the cases covered above. Notice that the
that the Service Access Device may be collocated with the Foreign SAD may be collocated with the Foreign Agent (FA) in case of Mobile-
Agent (FA) in case of Mobile-IPv4. As the subscriber device moves IPv4. As the subscriber device moves it establishes a connection
it establishes a connection with another Service Access Device in with another SAD in the same foreign network or in another foreign
the same foreign network or in another foreign network. The prepaid network. The prepaid data service should continue to be available.
data service should continue to be available. When a device When a device associates to another SAD it MUST re-authenticate at
associates to another Service Access Device it MUST re-authenticate the new SAD and de-associate or logoff from the old SAD.
at the new Service Access Device and de-associate or logoff from the Furthermore, any unused quota at the old SAD MUST be promptly
old Service Access Device. Furthermore, any unused quota at the old credited back to the subscribers account. The reason we say
Service Access Device MUST be promptly credited back to the promptly, is because if the subscriber is very low on resources to
subscribers account. The reason we say promptly, is because if the start with, the subscriber may not have enough resources to log on
subscriber is very low on resources to start with, the subscriber to the new SAD. The speed at which resources can be returned depend
may not have enough resources to log on to the new Service Access on the type of handoff procedure that is used. Some of the example
Device. The speed at which resources can be returned depend on the of handoffs in wireless networks are dormant handoff, active handoff
type of handoff procedure that is used. Some of the example of
handoffs in wireless networks are dormant handoff, active handoff
and fast handoff. and fast handoff.
As well, notice that if the Service Access Devices could communicate As well, notice that if the SADs could communicate with each other
with each other then there could be a way to accelerate a faster then there could be a way to accelerate a faster handoff procedure.
handoff procedure. In particular, it could accelerate the return of In particular, it could accelerate the return of the unused portion
the unused portion of the quotas from the old Access Device. of the quotas from the old Access Device.
Unfortunately, standards with regards to handoff are evolving with Unfortunately, standards with regards to handoff are evolving with
each network technology creating their own scheme to make the each network technology creating their own scheme to make the
handoff procedures more efficient. handoff procedures more efficient.
2.1 Why not existing RADIUS attributes? 2.3 Why not existing RADIUS attributes?
It has been asked ôWhy not use existing RADIUS attributes to build a It has been asked "Why not use existing RADIUS attributes to build a
prepaid solution? This will allow us to have a solution with prepaid solution? This will allow us to have a solution with
existing devices without code modification.ö existing devices without code modification."
It is possible to build a prepaid solution using existing RADIUS It is possible to build a prepaid solution using existing RADIUS
attributes. The RADIUS server can simply send an Access-Accept attributes. The RADIUS server can simply send an Access-Accept
message containing Session-Timeout(27) and set Termination- message containing Session-Timeout(27) and set Termination-
Action(29) to RADIUS-request. Upon receiving the Access-Accept Action(29) to RADIUS-request. Upon receiving the Access-Accept
message, the NAS will meter the duration of the session and upon message, the NAS will meter the duration of the session and upon
termination of the session the NAS generate an Access-Request termination of the session the NAS generate an Access-Request
message again. The RADIUS server would re-authenticate the session message again. The RADIUS server would re-authenticate the session
and reply with an Access-Accept message with additional time in and reply with an Access-Accept message with additional time in
Session-Timeout(27) or an Access-Reject message if there were no Session-Timeout(27) or an Access-Reject message if there were no
skipping to change at page 14, line 14 skipping to change at page 14, line 38
perspective of the user. No re-authentication is required and perspective of the user. No re-authentication is required and
quotas can be negotiated prior to the quotas running out. quotas can be negotiated prior to the quotas running out.
-Prepaid ambiguity. Implementing prepaid using existing RADIUS -Prepaid ambiguity. Implementing prepaid using existing RADIUS
attributes presents another problem. Due to the fact that the attributes presents another problem. Due to the fact that the
standard RADIUS attributes are not mandatory, then the correct standard RADIUS attributes are not mandatory, then the correct
prepaid operation is really an act of faith on the part of the prepaid operation is really an act of faith on the part of the
RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) RADIUS server. If Session-Timeout(27) and/or Termination-Action(29)
are not supported, the prepaid subscriber will get free access. The are not supported, the prepaid subscriber will get free access. The
solution described in this document, requires that a prepaid capable solution described in this document, requires that a prepaid capable
Service Access Device inform the RADIUS server whether or not it SAD inform the RADIUS server whether or not it supports prepaid
supports prepaid capabilities. The RADIUS server can now determine capabilities. The RADIUS server can now determine whether service
whether service should be granted or not. For example, if a prepaid should be granted or not. For example, if a prepaid subscriber is
subscriber is connected to a NAS that does not support prepaid, the connected to a NAS that does not support prepaid, the RADIUS server
RADIUS server can either instruct the NAS to tunnel the traffic to can either instruct the NAS to tunnel the traffic to another entity
another entity in the home network that does support prepaid client in the home network that does support prepaid client function (e.g.
function (e.g. Home Agent) or it may allow the subscriber to get Home Agent) or it may allow the subscriber to get access but
access but restrict the traffic. restrict the traffic.
The prepaid solution we present is a robust carrier grade prepaid The prepaid solution we present is a robust carrier grade prepaid
solution. It only requires the support of 2 mandatory attributes solution. It only requires the support of 2 mandatory attributes
and one optional attribute. Furthermore, it does not really and one optional attribute. Furthermore, it does not really
require much code support at the NAS. NASes already support require much code support at the NAS. NASes already support
measurement of time and volume. This solution requires that they measurement of time and volume. This solution requires that they
advertise their prepaid capabilities in an Access-Request; that they advertise their prepaid capabilities in an Access-Request; that they
generate an Access-Request Authorize-Only packet to obtain more generate an Access-Request Authorize-Only packet to obtain more
quota at or before the quota is used up. It also requires that the 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 NAS send an Access-Request with Authorize-Only when the session
terminates to return any unused quota to the prepaid system. terminates to return any unused quota to the prepaid system.
Lastly the solution provided in this document is extensible. This Lastly the solution provided in this document is extensible. This
document defines the basic exchanges between a prepaid capable NAS document defines the basic exchanges between a prepaid capable NAS
and a RADIUS server. The protocol can easily be extended to support and a RADIUS server. The protocol can easily be extended to support
tariff switching and other prepaid business models. tariff switching and other prepaid business models.
3. Use-cases 3. Use-cases
In this section we present a set of use cases that will help In this section we present a set of use cases that help establish
establish the requirements needed to deliver PrePaid data services. the requirements needed to deliver PrePaid data services. These
These use cases donÆt address how the PrePaid account is established use-cases donÆt address how the PrePaid account is established or
or maintained. It is assumed that the PrePaid subscriber has maintained. It is assumed that the PrePaid subscriber has obtained
obtained a valid account from a service provider such as a wireless a valid account from a service provider such as a wireless operator
operator or a WLAN operator. or a WLAN operator.
To make the document as general as possible, the use cases cover the To make the document as general as possible, the use cases cover the
experience from the Service Access Device and not from the UserÆs experience from the SAD and not from the UserÆs Device. The
Device. The connection between the UserÆs Device, which typically connection between the UserÆs Device, which typically involves
involves setting up a layer 2 session, e.g., PPP session or GPRS PDP setting up a layer 2 session, e.g., PPP session or GPRS PDP Context,
Context, is specific to a given network technology and the details is specific to a given network technology and the details are not
are not required to deliver a PrePaid service. required to deliver a PrePaid service.
3.1 Simple pre-paid access use-case 3.1 Simple pre-paid access use-case
A PrePaid subscriber connects to his home network. As usual, the A PrePaid subscriber connects to his home network. As usual, the
Access Device that is servicing the subscriber will use the AAA Access Device that is servicing the subscriber will use the AAA
infrastructure to authenticate and authorize the subscriber. infrastructure to authenticate and authorize the subscriber.
The Service Access Device sends a RADIUS Access-Request to the AAA The SAD sends a RADIUS Access-Request to the AAA system to
system to authenticate the subscriber, and identify and authorize authenticate the subscriber, and identify and authorize the service.
the service. The Access-Request includes the subscriberÆs The Access-Request includes the subscriberÆs credentials and may
credentials and may include the PrePaid capabilities of the Service include the PrePaid capabilities of the SAD. PrePaid capabilities
Access Device. PrePaid capabilities MUST be included if the Service MUST be included if the SAD supports PrePaid functionality.
Access Device supports PrePaid functionality.
The AAA System proceeds with the authentication procedure. This may The AAA System proceeds with the authentication procedure. This may
involve several transactions such as in EAP [RFC2284]. Once the involve several transactions such as in EAP [RFC2284]. Once the
subscriber has been authenticated, the AAA system determines that subscriber has been authenticated, the AAA system determines that
the subscriber is a PrePaid subscriber and requests that the PrePaid the subscriber is a PrePaid subscriber and requests that the PrePaid
System authorize the PrePaid subscriber. The request MUST include System authorize the PrePaid subscriber. The request MUST include
the PrePaid Capabilities of the serving Service Access Device. the PrePaid Capabilities of the serving SAD.
The PrePaid System will validate that the subscriber has a PrePaid The PrePaid System will validate that the subscriber has a PrePaid
Account; it will validate that the account is active; and will Account; it will validate that the account is active; and will
validate that the Service Access Device has the appropriate PrePaid validate that the SAD has the appropriate PrePaid capabilities. If
capabilities. If all is in order, the PrePaid System will authorize all is in order, the PrePaid System will authorize the subscriber to
the subscriber to use the network. Otherwise it will reject the use the network. Otherwise it will reject the request. The
request. The response is sent back to the AAA System. The response response is sent back to the AAA System. The response includes
includes attributes to indicate the allocation of a portion of the attributes to indicate the allocation of a portion of the
subscriberÆs account called the initial quota (in units of time or subscriberÆs account called the initial quota (in units of time or
volume) and optionally a threshold value. volume) and optionally a threshold value.
The reason we allocate a portion of the userÆs account is that the 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 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 Prepaid account. For example the user may be engaged in a data
session and a voice session. Although, these two services would session and a voice session. Although, these two services would
draw from the same account the involved separate parts of the draw from the same account the involved separate parts of the
system. If the entire quota was allocated to the data session then system. If the entire quota was allocated to the data session then
the user would have no more funds for a voice session. the user would have no more funds for a voice session.
The AAA system incorporates the PrePaid attributes received from the The AAA system incorporates the PrePaid attributes received from the
PrePaid System into an Access-Accept message that it sends back to PrePaid System into an Access-Accept message that it sends back to
the Service Access Device. Note the AAA System is responsible for the SAD. Note the AAA System is responsible for authorizing the
authorizing the service whereas the PrePaid System is responsible service whereas the PrePaid System is responsible for PrePaid
for PrePaid authorization. authorization.
Upon receiving the Access-Response, the Service Access Device allows Upon receiving the Access-Response, the SAD allows the PrePaid data
the PrePaid data session to start and it starts to meter the session session to start and it starts to meter the session based on time or
based on time or volume, as indicated in the returned Quota volume, as indicated in the returned Quota
Once the usage for the session approaches the allotted quota (as Once the usage for the session approaches the allotted quota (as
expressed by the threshold), the Service Access Device will request expressed by the threshold), the SAD will request an additional
an additional quota. The re-authorization for additional quota quota. The re-authorization for additional quota flows through the
flows through the AAA system to the PrePaid System. The PrePaid AAA system to the PrePaid System. The PrePaid System revalidates
System revalidates the subscriberÆs account; it will subtract the the subscriberÆs account; it will subtract the previous quota
previous quota allocation from the userÆs account balance and if allocation from the userÆs account balance and if there is a balance
there is a balance remaining it will reauthorize the request with an remaining it will reauthorize the request with an additional quota
additional quota allotment. Otherwise, the PrePaid System will allotment. Otherwise, the PrePaid System will reject the request.
reject the request. Note the replenishing of the quotas is a re- Note the replenishing of the quotas is a re-authorization procedure
authorization procedure and does not involve re-authentication of and does not involve re-authentication of the subscriber.
the subscriber.
It is important to note that the PrePaid System is maintaining It is important to note that the PrePaid System is maintaining
session state for the subscriber. This state includes how much session state for the subscriber. This state includes how much
account balance was allocated during the last quota allocation for a account balance was allocated during the last quota allocation for a
particular session and how much is left in the account. Therefore, particular session and how much is left in the account. Therefore,
it is required that all subsequent messages about the PrePaid it is required that all subsequent messages about the PrePaid
session reach the correct PrePaid System. session reach the correct PrePaid System.
Upon receiving a re-allotment of the quota, the Service Access Upon receiving a re-allotment of the quota, the SAD will, continue
Device will, continue the data service session until the new the data service session until the new threshold is reached. If the
threshold is reached. If the request for additional quota cannot be request for additional quota cannot be fulfilled then the SAD will
fulfilled then the Service Access Device will let the subscriber use let the subscriber use up the remaining quota and terminate the
up the remaining quota and terminate the session. session.
Alternatively, instead of terminating the session, the Service Alternatively, instead of terminating the session, the SAD may
Access Device may restrict the data session such that the subscriber restrict the data session such that the subscriber can only reach a
can only reach a particular web server. This web server maybe used particular web server. This web server maybe used to allow the
to allow the subscriber to replenish their account. This subscriber to replenish their account. This restriction can also be
restriction can also be used to allow new subscribers to purchase used to allow new subscribers to purchase their initial PrePaid
their initial PrePaid Service. Service.
Should the subscriber terminate the session before the quota is used Should the subscriber terminate the session before the quota is used
up, the remaining balance allotted to the session must be credited up, the remaining balance allotted to the session must be credited
back to the subscriberÆs account. back to the subscriberÆs account.
As well, while the Access Device is waiting for the initial quota, As well, while the Access Device is waiting for the initial quota,
the subscriber may have dropped the session. The initial quota must the subscriber may have dropped the session. The initial quota must
be credited back to the subscribers account. be credited back to the subscribers account.
3.2 Support for Multi-Services 3.2 Support for Multi-Services
Up to now we were looking at session that consisted of a single Up to now we were looking at session that consisted of a single
service, ôAccess Serviceö. An ôAccess Serviceö is the basic service service, "Access Service". An "Access Service" is the basic service
that is provided to the user by the Service Access Device after that is provided to the user by the SAD after successful
successful authentication and authorization. When we donÆt authentication and authorization. When we donÆt differentiate
differentiate between different types of services the ôAccess between different types of services the "Access Service" aggregates
Serviceö aggregates all the services that the user my be engaged in all the services that the user my be engaged in on a particular SAD.
on a particular Service Access Device. 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 these Services. Some For example, the user may be browsing the web, and participating in
services are billed at different rates and Services maybe metered 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 differently. Therefore, the prepaid solution needs to be able to
distinguish Services, and allocate quotas to the Services using distinguish services, and allocate quotas to the services using
different units (e.g. time, volume) and allow for those quotas to be different units (e.g. time, volume) and allow for those quotas to be
utilized at different rates. utilized at different rates.
+---------+ +---------+
| Session | | Session |
+---------+ +---------+
| |
V N V N
+--------------+ +-------+ +--------------+ +-------+
| Service |------>| Quota | | Service |------>| Quota |
| (service-Id) | +-------+ | (service-Id) | +-------+
+--------------+ +--------------+
As shown in the above diagram, a Session can have N Services. Each 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 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 is not in the scope of this document but the Service-Id could be
expressed as an IP flow using the IP 5-tuple (Source-IP and Port, expressed as an IP flow using the stand 5-tuple (Source-IP and Port,
the Destination-IP and Port, and the protocol). Each Service is the Destination-IP and Port, and the protocol type). Each service
allocated a Quota appropriate to the service. is allocated an appropriate quota.
3.3 Resource Pools 3.3 Resource Pools
When working with multiple services which results in multiple quota When working with multiple services that results in multiple quota
allocation another problem arises. Even though quotas are portioned allocation another problem arises. Even though quotas are portioned
out in fractional parts of the users prepaid account, there could be out in fractional parts of the userÆs prepaid account, there could
a situation where one Service utilizes its quota faster then another be a situation where one Service utilizes its quota faster then
Service. When the userÆs account is used up, there could be a another Service. When the userÆs account is used up, there could be
situation where one Service is unable to obtain additional quota a situation where one Service is unable to obtain additional quota
while another Service has plenty of quota remaining. Unless the while another Service has plenty of quota remaining. Unless the
quotas can be rebalanced, the Service Access Device would then have quotas can be rebalanced, the SAD would then have to terminate that
to terminate that Service. As well, even before that happens, the Service. As well, even before that happens, the existence of
existence of several Services could generate an excessive amount of several Services could generate an excessive amount of traffic as
traffic as the services update their quotas. the services update their quotas.
One method to solve these problems is to utilize resource pools. One method to solve these problems is to utilize resource pools.
Resource pools allow us to allocate resources to several services of Resource pools allow us to allocate resources to several services of
a session by allocating resources to a pool and have services draw a session by allocating resources to a pool and have services draw
their quota from the pool at a rate appropriate to that service. their quota from the pool at a rate appropriate to that service.
When the quota allocated to the pool runs out, we replenish the When the quota allocated to the pool runs out, we replenish the
pool. pool.
+-----------+ +-----------+
| Service-A |-----+ +--------+ | Service-A |-----+ +--------+
+-----------+ | Ma | | +-----------+ | Ma | |
+-------->| | +-------->| |
| Pool | | Pool |
+-------->| (1) | +-------->| (1) |
+-----------+ | Mb | | +-----------+ | Mb | |
| Service-B |-----+ +--------+ | Service-B |-----+ +--------+
+-----------+ +-----------+
As the above figure shows, Service-A and Service-B is bound to 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 Pool(1). Ma and Mb are the pool multipliers (that are associated
with Service-A and Service-B respectively) that determines the rate with Service-A and Service-B respectively) that determines the rate
at which Service-A and Service-B draw from the pool. at which Service-A and Service-B draw from the pool.
The pool is initialized by taking the quota allocated to each The pool is initialized by taking the quota allocated to each
service and multiplying it by Mn. Therefore, the amount of service and multiplying it by Mn. Therefore, the amount of
resources allocated to a pool is given by: resources allocated to a pool is given by:
Poolr = Ma*Qa + Mb*Qb + . . . Poolr = Ma*Qa + Mb*Qb + . . .
skipping to change at page 20, line 4 skipping to change at page 20, line 27
In some cases an operator may wish to apply a much more complex 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 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 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 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 at $0.50 per Mbyte. This rating function could be achieved by
repeated message exchanges with the Prepaid System. repeated message exchanges with the Prepaid System.
To avert the need to exchange many messages and to support even more To avert the need to exchange many messages and to support even more
complex rating functions we support Rating Groups. A Rating Group complex rating functions we support Rating Groups. A Rating Group
is provisioned at the Service Access Device. As illustrated in the is provisioned at the SAD. As illustrated in the figure below, a
figure below, a Rating Group is associated with one or more Services Rating Group is associated with one or more Services and defines the
and defines the rate that the services associated with the Rating rate that the services associated with the Rating Group consume the
Group consume the quota. quota.
+-----------+ +-----------+
| Service-A |------+ | Service-A |------+
+-----------+ | +--------------+ +-------+ +-----------+ | +--------------+ +-------+
+---->| | | Quota | +---->| | | Quota |
| Rating Group |------>| or | | Rating Group |------>| or |
+-----------+ +---->| | | Pool | +-----------+ +---->| | | Pool |
| Service-B |------+ +--------------+ +-------+ | Service-B |------+ +--------------+ +-------+
+-----------+ +-----------+
skipping to change at page 20, line 29 skipping to change at page 21, line 10
associated with a Rating Group, the Prepaid Client sends the Rating associated with a Rating Group, the Prepaid Client sends the Rating
Group to the Prepaid Server. The prepaid service authorizes the Group to the Prepaid Server. The prepaid service authorizes the
Rating Group by assigning it a Quota and optionally assigning it to Rating Group by assigning it a Quota and optionally assigning it to
a Resource Pool. a Resource Pool.
When service that belongs to an authorized Rating Group is When service that belongs to an authorized Rating Group is
instantiated, then the Prepaid Client does not need to authorize instantiated, then the Prepaid Client does not need to authorize
that service. This could greatly reduce the amount of traffic that service. This could greatly reduce the amount of traffic
between the Prepaid Client and the Prepaid Server. between the Prepaid Client and the Prepaid Server.
3.5 Support for Roaming 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 Roaming
For some networks it is essential that PrePaid Data Services be For some networks it is essential that PrePaid Data Services be
offered to roaming subscribers. Support for static and dynamic offered to roaming subscribers. Support for static and dynamic
roaming models are needed. Static roaming is where the subscriber roaming models are needed. Static roaming is where the subscriber
logs onto a foreign network. The foreign network has a roaming logs onto a foreign network. The foreign network has a roaming
agreement directly with the home network or through a broker network agreement directly with the home network or through a broker network
or networks. The subscriber remains logged into the network until or networks. The subscriber remains logged into the network until
the subscriber changes location. When changing location a new the subscriber changes location. When changing location a new
connection and a new login procedure is required. connection and a new login procedure is required.
skipping to change at page 21, line 15 skipping to change at page 23, line 5
In both roaming scenarios, the subscriber always authenticates with In both roaming scenarios, the subscriber always authenticates with
the home network. PrePaid authorization and quota replenishing for the home network. PrePaid authorization and quota replenishing for
the session need to be received at the home network and more the session need to be received at the home network and more
specifically at the PrePaid System where state is being maintained. specifically at the PrePaid System where state is being maintained.
Dynamic roaming is particularly challenging. A subscriber that Dynamic roaming is particularly challenging. A subscriber that
established a PrePaid Data Session may roam to another Access Device established a PrePaid Data Session may roam to another Access Device
that doesnÆt not support PrePaid functionality. The system should that doesnÆt not support PrePaid functionality. The system should
be capable to continue the PrePaid session. be capable to continue the PrePaid session.
3.6 PrePaid termination 3.7 PrePaid termination
When fraud is detected by the PrePaid System, or when an error is 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 detected, it may be beneficial for the PrePaid system to terminate a
specific session for the subscriber or all the sessions of a specific session for the subscriber or all the sessions of a
subscriber. subscriber.
Some errors can occur such that the PrePaid System is in a state 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. where it is not sure whether the session is in progress or not.
Under conditions such as this, the PrePaid system may wish to Under conditions such as this, the PrePaid system may wish to
terminate the PrePaid data session to make sure that resources are terminate the PrePaid data session to make sure that resources are
not being utilized for which it canÆt charge for reliably. not being utilized for which it canÆt charge for reliably.
Some handoff procedure used during dynamic roaming may require that Some handoff procedure used during dynamic roaming may require that
the PrePaid system explicitly terminate the subscribers PrePaid data the PrePaid system explicitly terminate the subscribers PrePaid data
session at an Service Access Device. For example, if time based session at an SAD. For example, if time based PrePaid service is
PrePaid service is being used and the mobile subscriber performs a being used and the mobile subscriber performs a dormant handoff, the
dormant handoff, the PrePaid System needs to explicitly terminate PrePaid System needs to explicitly terminate the PrePaid session at
the PrePaid session at the old Service Access Device. the old SAD.
3.8 Querying and Rebalancing Prepaid Resources
It should be possible to allow the Prepaid Server to Query the
current uses state of a prepaid balance at a SAD and adjust the
prepaid resources.
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 a the capability 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 occurance
of this scenario by allocated smaller quotas. But the result will
be many more transactions. The ability to query and to rebalance
resources provides a good trade-off.
4. Operations 4. Operations
4.1 General Requirements 4.1 General Requirements
4.1.1 Broker AAA Requirements 4.1.1 Broker AAA Requirements
Broker AAA servers MUST support the Message-Authenticator(80) Broker AAA servers MUST support the Message-Authenticator(80)
attribute as defined in [RFC2869]. If BAAA servers are used, the attribute as defined in [RFC2869]. If BAAA servers are used, the
BAAA servers function is to forward the RADIUS packets as usual to BAAA servers function is to forward 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 PrePaid Server
current as to what is happening with the PrePaid data session. current as to what is happening with the PrePaid data session.
Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the
pass through mode described in [RFC2866]. pass through mode described in [RFC2866].
4.2 Authentication and Authorization for Prepaid Enabled Service Access 4.2 Authentication and Authorization for Prepaid Enabled SADs
Devices
The Service Access Device initiates the authentication and The SAD initiates the authentication and authorization procedure by
authorization procedure by sending a RADIUS Access-Request to the sending a RADIUS Access-Request to the HAAA.
HAAA.
If the Service Access Device has PrePaid Client capabilities, it If the SAD has PrePaid Client capabilities, it MUST include the
MUST include the PPAC(TBD) attribute in the RADIUS Access-Request. PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD)
The PPAC(TBD) attribute indicates to the PrePaid server the PrePaid attribute indicates to the PrePaid server the PrePaid capabilities
capabilities possessed by the Service Access Device. These are possessed by the SAD. These are required in order to complete the
required in order to complete the PrePaid authorization procedures. PrePaid authorization procedures.
If the Service Access Device supports the Disconnect-Message or the If the SAD supports the Disconnect-Message or the Change-of-
Change-of-Authorization capabilities, then it SHOULD include the Authorization capabilities, then it SHOULD include the Dynamic-
Dynamic-Capabilities attribute. Capabilities attribute.
In certain deployments, there may be other ways in which to In certain deployments, there may be other ways in which to
terminate a data session, or change authorization of an active terminate a data session, or change authorization of an active
session. For example, some Service Access Devices provide a session session. For example, some SADs provide a session termination
termination service via Telnet or SNMP. In these cases, the AAA service via Telnet or SNMP. In these cases, the AAA server MAY add
server MAY add the Dynamic-Capabilities message to the Access- the Dynamic-Capabilities message to the Access-Request. Upon
Request. Upon receiving the Change-of-Authorization message, the receiving the Change-of-Authorization message, the AAA server would
AAA server would then be responsible for terminating the session then be responsible for terminating the session using whatever means
using whatever means that are supported by the device. that are supported by the device.
If the authentication procedure involves multiple Access-Requests If the authentication procedure involves multiple Access-Requests
(as in EAP), the Service Access Device MUST include the PPAC(TBD) (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the
attribute and the Dynamic-Capabilities attribute (if used) in at Dynamic-Capabilities attribute (if used) in at least the last
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 will be sent as usual to the HAAA. The packet
may be proxied through zero or more BAAA. may be proxied through zero or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA will Once the Access-Request arrives at the HAAA, the HAAA will
authenticate the subscriber. If the subscriber is cannot be authenticate the subscriber. If the subscriber is cannot be
authenticated, the HAAA will send an Access-Reject message back to authenticated, the HAAA will send an Access-Reject message back to
the client. If the subscriber is authenticated, the HAAA will the client. If the subscriber is authenticated, the HAAA will
determine whether or not the subscriber is a PrePaid subscriber. determine whether or not the subscriber is a PrePaid subscriber.
The techniques used to determine whether or not a subscriber is a The techniques used to determine whether or not a subscriber is a
skipping to change at page 23, line 22 skipping to change at page 25, line 34
The Access-Request will contain the PPAC(TBD) attribute, the The Access-Request will contain the PPAC(TBD) attribute, the
Dynamic-Capabilities attribute if one was included; the User-Name(1) Dynamic-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 would represent the
SubscriberÆs PrePaid Identity. This attribute is used by the SubscriberÆs PrePaid Identity. This attribute is used by the
PrePaid server to locate the PrePaid SubscriberÆs account. For PrePaid server to locate the PrePaid SubscriberÆs account. For
added security, the HAAA MAY also set the User-Password(2) attribute added security, the HAAA MAY also set the User-Password(2) attribute
to the password used between the HAAA and the PrePaid server. to the password used between the HAAA and the PrePaid server.
The PrePaid server lookups the subscriberÆs PrePaid account and will The PrePaid server lookups the subscriberÆs PrePaid account and will
authorize the subscriber taking into consideration the Service authorize the subscriber taking into consideration the SAD PrePaid
Access Device PrePaid Client Capabilities. Client Capabilities.
Upon successful authorization, the PrePaid server will generate an Upon successful authorization, the PrePaid server will generate an
Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD) Access-Accept 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 QUOTA-Id, which is set by the PrePaid server to a unique - The QUOTA-Id, which is set by the PrePaid server to a unique
value that is used to correlate subsequent quota requests; value that is 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 a value representing a
portion of the subscribers account; portion of the subscribers account;
- MAY contain a Time or Volume Threshold that controls when the - MAY contain a Time or Volume Threshold that controls when the SAD
Service Access Device requests additional quota; requests additional quota;
- The IP address of the Serving PrePaid Server and one or more - The IP address of the Serving PrePaid Server and one or more
alternative PrePaid Servers. This is used by the HAAA to route alternative PrePaid Servers. This is used by the HAAA to route
subsequent quota replenishing messages to the appropriate PrePaid subsequent quota replenishing messages to the appropriate PrePaid
server(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 pre-paid service following subscriber inactivity.
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, upon unsuccessful authorization, the
skipping to change at page 24, line 22 skipping to change at page 26, line 33
some or all of the traffic to a location where the subscriber can some or all of the traffic to a location where the subscriber can
replenish their account for a period of time. Blocking of traffic replenish their account for a period of time. Blocking of traffic
is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect
I-d). Redirection is achieved by sending Redirect-Id or Redirect- I-d). Redirection is achieved by sending Redirect-Id or Redirect-
Rule defined in the Redirect I-d. The period of time before the Rule defined in the Redirect I-d. The period of time before the
blocked/redirected session last can be specified by Session- blocked/redirected session last can be specified by Session-
Timeout(27) attribute. Timeout(27) attribute.
Upon receiving the Access-Accept from the PrePaid Server, the HAAA Upon receiving the Access-Accept from the PrePaid Server, the HAAA
will append the usual service attributes and forward the packet to will append the usual service attributes and forward the packet to
the Service Access Device. The HAAA SHOULD NOT overwrite any the SAD. The HAAA SHOULD NOT overwrite any attributes already set
attributes already set by the PrePaid server. If the HAAA, receives by the PrePaid server. If the HAAA, receives an Access-Reject
an Access-Reject message, it will simply forward the packet to its message, it will simply forward the packet to its client. Depending
client. Depending on site policies, if the HAAA fails to receive an on site policies, if the HAAA fails to receive an Access-Accept or
Access-Accept or Access-Reject message from the PrePaid server it Access-Reject message from the PrePaid server it MAY do nothing or
MAY do nothing or send an Access-Reject or an Access-Accept message send an Access-Reject or an Access-Accept message back to its
back to its client. client.
4.3 Session Start Operation 4.3 Session Start Operation
The real start of the session is indicated by the arrival of The real start of the session is indicated by the arrival of
Accounting-Request(Start) packet. The Accounting-Request (Start) Accounting-Request(Start) packet. The Accounting-Request (Start)
MAY be routed to the PrePaid Server so that it can confirm the MAY be routed to the PrePaid Server so that it can confirm the
initial quota allocation. initial quota allocation.
Note that the PrePaid Server role is not to record accounting Note that the PrePaid Server role is not to record accounting
messages and therefore it SHOULD not respond with an Accounting messages and therefore it SHOULD not respond with an Accounting
Response packet. Response packet.
If the Prepaid server does not receive the Accounting-Request(start) If the Prepaid server does not receive the Accounting-Request(start)
message it will only know that the session has started upon the message it will only know that the session has started upon the
first reception of a quota replenishment operation. first reception of a quota replenishment operation.
If the Prepaid server does not receive indication directly (via If the Prepaid server does not receive indication directly (via
Accounting-Request(start)) or indirectly, it SHOULD after some Accounting-Request(start)) or indirectly, it SHOULD after some
configurable time, deduce that the Session has not started. If the configurable time, deduce that the Session has not started. If the
Service Access Device supports termination capabilities, the PPS SAD supports termination capabilities, the PPS SHOULD send a
SHOULD send a Disconnect Message to the Service Access Device to Disconnect Message to the SAD to ensure that the session is indeed
ensure that the session is indeed dead. dead.
4.4 Mid-Session Operation 4.4 Mid-Session Operation
During the lifetime of a PrePaid data session the Service Access During the lifetime of a PrePaid data session the SAD will request
Device will request to replenish the quotas using Authorize-Only to replenish the quotas using Authorize-Only Access-Request
Access-Request messages. messages.
Once the allocated quota has been reached or the threshold has been Once the allocated quota has been reached or the threshold has been
reached, the Service Access Device MUST send an Access-Request with reached, the SAD MUST send an Access-Request with Service-Type(6)
Service-Type(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD) set to a value of "Authorize Only" and the PPAQ(TBD) attribute.
attribute.
The Service Access Device MUST also include NAS identifiers, and The SAD MUST also include NAS identifiers, and Session identifier
Session identifier attributes in the Authorize Only Access-Request. attributes in the Authorize Only Access-Request. The Session
The Session Identifier should be the same as those used during the Identifier should be the same as those used during the Access-
Access-Request. For example, if the User-Name(1) attribute was used Request. For example, if the User-Name(1) attribute was used in the
in the Access-Request it MUST be included in the Authorize Only Access-Request it MUST be included in the Authorize Only Access-
Access-Request especially if the User-Name(1) attribute is used to Request especially if the User-Name(1) attribute is used to route
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 either User
Password or Chap Password. In order to authenticate the message, Password or Chap Password. In order to authenticate the message,
the Service Access Device MUST include the Message-Authenticator(80) the SAD MUST include the Message-Authenticator(80) attribute. The
attribute. The Service Access Device will compute the value for the SAD will compute the value for the Message-Authenticator based on
Message-Authenticator based on [RFC2869]. [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 in error 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 will either be silently discarded
skipping to change at page 27, line 7 skipping to change at page 29, line 16
short duration to allow them to replenish their account, or create short duration to allow them to replenish their account, or create
an account; or to browse free content. an account; or to browse free content.
Upon receiving the Access-Accept from the PrePaid server, the HAAA Upon receiving the Access-Accept from the PrePaid server, the HAAA
SHALL return the packet to its client. If the HAAA, receives an SHALL return the packet to its client. If the HAAA, receives an
Access-Reject message, it will forward the packet. Depending on Access-Reject message, it will forward the packet. Depending on
site policies, if the HAAA fails to receive an Access-Accept or an site policies, if the HAAA fails to receive an Access-Accept or an
Access-Reject message from the PrePaid server it MAY do nothing or Access-Reject message from the PrePaid server it MAY do nothing or
it MAY send an Access-Reject message back to its client. it MAY send an Access-Reject message back to its client.
Upon receiving an Access-Accept, the Service Access Device SHALL Upon receiving an Access-Accept, the SAD SHALL update its quotas and
update its quotas and threshold parameters with the values contained threshold parameters with the values contained in the PPAQ(TBD)
in the PPAQ(TBD) attribute. Note that the PrePaid server MAY update attribute. Note that the PrePaid server MAY update the
the PrePaidServer attribute(s) and these may have to be saved as PrePaidServer attribute(s) and these may have to be saved as well.
well.
Upon receiving an Access-Accept message containing either Filter- Upon receiving an Access-Accept message containing either Filter-
Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27).
The Service Access Device SHALL restrict the subscriber session The SAD SHALL restrict the subscriber session accordingly.
accordingly.
4.5 Dynamic Operations 4.5 Dynamic Operations
The PrePaid server may want to take advantage of the dynamic The PrePaid server may want to take advantage of the dynamic
capabilities that are supported by the Service Access Device as capabilities that are supported by the SAD as advertised in the
advertised in the Dynamic-Capabilities attribute during the initial Dynamic-Capabilities attribute during the initial Access-Request.
Access-Request.
There are two types of actions that the PrePaid server can perform: There are two types of actions that the PrePaid server can perform:
it can request that the session be terminated; or it can request it can request that the session be terminated; or it can request
that attributes associated with the session be modified. More that attributes associated with the session be modified. More
specifically, it can modify previously sent PPAQ(TBD) 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 Service Access Device. As a minimum the PrePaid identified at the SAD. As a minimum the PrePaid server:
server:
-MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32)
-MUST provide at least one session identifier such as User-Name(1), -MUST 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 For a discussion on Dynamic Operations as they related Mutli-Service
operations see further on. operations see further on.
skipping to change at page 28, line 4 skipping to change at page 30, line 9
-MUST provide at least one session identifier such as User-Name(1), -MUST 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 For a discussion on Dynamic Operations as they related Mutli-Service
operations see further on. operations see further on.
4.5.1 Unsolicited Session Termination Operation 4.5.1 Unsolicited Session Termination Operation
At anytime during a session the Prepaid Server may send a Disconnect At anytime during a session the Prepaid Server may send a Disconnect
Message to terminate a session. This capability is described in Message to terminate a session. This capability is described in
detail in [RFC3576]. The PrePaid server sends a Disconnect Message detail in [RFC3576]. The PrePaid server sends a Disconnect Message
that MUST contain identifiers that uniquely identify the that MUST contain identifiers that uniquely identify the
subscriberÆs data session and the Service Access Device servicing subscriberÆs data session and the SAD servicing that session.
that session.
If the Service Access Device receives a Disconnect-Message, it will If the SAD receives a Disconnect-Message, it will respond with
respond with either a Disconnect-ACK packet if it was able to either a Disconnect-ACK packet if it was able to terminate the
terminate the session or else it will respond with a Disconnect-NAK session or else it will respond with a Disconnect-NAK packet.
packet.
Upon successful termination of a session the Service Access Device Upon successful termination of a session the SAD MUST return any
MUST return any unused quota to the Prepaid Server by issuing an unused quota to the Prepaid Server by issuing an Authorize Only
Authorize Only Access-Request containing the PPAQ which contains any Access-Request containing the PPAQ which contains any unused Quota
unused Quota and the Update-Reason set to ôRemote Forced and the Update-Reason set to "Remote Forced Disconnect".
Disconnectö.
4.5.2 Unsolicited Change of Authorization Operation 4.5.2 Unsolicited Change of Authorization Operation
At anytime during the prepaid session the Prepaid Client may receive At anytime during the prepaid session the Prepaid Client may receive
a Change of Authorization (CoA) message. A Prepaid Server may send a Change of Authorization (CoA) message. A Prepaid Server may send
a new Quota to either add additional quota or to remove quota a new Quota to either add additional quota or to remove quota
already allocated for 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 will
override a previously received PPAQ. The PPAQ may contain more override a previously received PPAQ. The PPAQ may contain more
allocated Quota or less allocated quota. The PPS MUST NOT change allocated Quota or less allocated quota. The PPS MUST NOT change
the 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 Service Access Device will beyond what is currently used then the SAD will accept the new PPAQ
accept the new PPAQ and act as it normally would when the quota is and act as it normally would when the quota is used up. For
used up. For example, if the threshold is reached then is request a example, if the threshold is reached then is request a quota update;
quota update; if the quota received is less then the currently used if the quota received is less then the currently used level then the
level then the Service Access Device would follow the normal SAD would follow the normal procedures followed when a quota is used
procedures followed when a quota is used up. up.
4.6 Termination Operation 4.6 Termination Operation
The termination phase is initiated when either: the Subscriber logs The termination phase is initiated when either: the Subscriber logs
off; the quotas have been consumed, or when the Service Access off; the quotas have been consumed, or when the SAD receives a
Device receives a Disconnect Message. Disconnect Message.
In the case where the user logged off, or the Service Access Device In the case where the user logged off, or the SAD receives a
receives a Disconnect Message, the Service Access Device will send Disconnect Message, the SAD will send an Authorize-Only Access-
an Authorize-Only Access-Request message with a PPAQ(TBD) and Request message with a PPAQ(TBD) and Update-Reason attribute set to
Update-Reason attribute set to either ôClient Service terminationö either "Client Service termination" or "Remote Forced disconnect"
or ôRemote Forced disconnectö and the currently used quota. and the currently used quota.
In the case where the quota has been reached, if the PPAQ(TBD) In the case where the quota has been reached, if the PPAQ(TBD)
contained Termination-Action field, the Service Access Device will contained Termination-Action field, the SAD will follow the
follow the specified action which would be to immediately terminate specified action which would be to immediately terminate the
the service, to request more quota, or to Redirect/Filter the service, to request more quota, or to Redirect/Filter the service.
service.
4.7 Mobile IP Operations 4.7 Mobile IP Operations
In roaming scenarios using Mobile-IP, as the mobile subscriber roams In roaming scenarios using Mobile-IP, as the mobile subscriber roams
between networks, or between different types of networks such as between networks, or between different types of networks such as
between WLAN and CDMA2000 networks, the PrePaid data session should between WLAN and CDMA2000 networks, the PrePaid data session should
be maintained transparently if the HA is acting as the Service be maintained transparently if the HA is acting as the SAD.
Access Device.
As the subscriber device associates with the new Service Access As the subscriber device associates with the new SAD (AP or PDSN
Device (AP or PDSN that supports prepaid client capability), the that supports prepaid client capability), the SAD sends a RADIUS
Service Access Device sends a RADIUS Access-Request and the Access-Request and the subscriber is re-authenticated and
subscriber is re-authenticated and reauthorized. The Service Access reauthorized. The SAD MUST include the PPAC(TBD) attribute in the
Device MUST include the PPAC(TBD) attribute in the RADIUS Access- RADIUS Access-Request. In this manner the procedure follows the
Request. In this manner the procedure follows the Authentication Authentication and Authorization procedure described earlier.
and Authorization procedure described earlier.
If the HA was acting as the Service Access Device before handoff, If the HA was acting as the SAD before handoff, the userÆs prepaid
the userÆs prepaid session does not undergo any change after the session does not undergo any change after the handoff because the
handoff because the Mobile IP session is anchored at the HA and the Mobile IP session is anchored at the HA and the userÆs Home IP
userÆs Home IP address remains the same. address remains the same.
In the case of AP or PDSN acting as the Service Access Device it is In the case of AP or PDSN acting as the SAD it is likely that the
likely that the userÆs IP address will change (Care of Address). userÆs IP address will change (Care of Address). Therefore, the
Therefore, the ongoing prepaid session will have some impact. In the ongoing prepaid session will have some impact. In the case the SAD
case the Service Access Device shall send an Access-Request. shall send an Access-Request.
The Access-Request message is routed to the home network and MUST The Access-Request message is routed to the home network and MUST
reach the PrePaid System that is serving the PrePaid session. The reach the PrePaid System that is serving the PrePaid session. The
PrePaid system will then correlate the new authorization request PrePaid system will then correlate the new authorization request
with the existing active session and will assign a quota to the new with the existing active session and will assign a quota to the new
request. Any outstanding quota at the old Service Access Device request. Any outstanding quota at the old SAD MUST be returned to
MUST be returned to the PrePaid system. If the Mobile-IP nodes (HA the PrePaid system. If the Mobile-IP nodes (HA and FA) supports
and FA) supports registration revocation (Mobile IPv4 only). registration revocation (Mobile IPv4 only). Specifically, the quota
Specifically, the quota SHOULD be returned when the Service Access SHOULD be returned when the SAD sends the Authorize Only Access-
Device sends the Authorize Only Access-Request with PPAQ(TBD) Request with PPAQ(TBD) Update-Reason set to either "Remote Forced
Update-Reason set to either ôRemote Forced disconnectö or ôClient disconnect" or "Client Service termination". In order to trigger
Service terminationö. In order to trigger the sending of this last the sending of this last Authorize Only Access-Request, the PrePaid
Authorize Only Access-Request, the PrePaid system may issue a system may issue a Disconnect Message [3576] to the SAD.
Disconnect Message [3576] to the Service Access Device.
If the subscriber has roamed to an Service Access Device that does If the subscriber has roamed to an SAD that does not have any
not have any PrePaid Capabilities, PrePaid data service may still be PrePaid Capabilities, PrePaid data service may still be possible by
possible by requesting the Home Agent (providing it has PrePaid requesting the Home Agent (providing it has PrePaid Capabilities) to
Capabilities) to assume responsibilities for metering the service. assume responsibilities for metering the service. The procedure for
The procedure for this scenario will be given in the next release of this scenario will be given in the next release of this draft.
this draft.
4.8 Operation consideration for Multi-Services 4.8 Operation consideration for Multi-Services
This section describes the operation for supporting Prepaid for This section describes the operation for supporting Prepaid for
multi-services on the same Service Access Device. The operations multi-services on the same SAD. The operations for multi-services
for multi-services are very similar to operations for single are very similar to operations for single service. Message flows
service. Message flows illustrating the various interactions are illustrating the various interactions are presented at the end of
presented at the end of this document. this document.
A Service Access Device that supports prepaid operations for multi- A SAD that supports prepaid operations for multi-services SHOULD set
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 out of scope for 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 Initial Quota Request 4.8.1 Initial Quota Request
When operations with multi-services is desired, the Service Access When operations with multi-services is desired, the SAD will request
Device will request the initial quota for the Service by sending a the initial quota for the Service by sending a PPAQ containing the
PPAQ containing the Service-Id for that Service in an Authorize-Only Service-Id for that Service in an Authorize-Only Access-Request
Access-Request packet. Similarly, if the Service Access Device packet. Similarly, if the SAD supports Rating-Groups then it may
supports Rating-Groups then it may request a prepaid quota for the request a prepaid quota for the Rating-Group by sending a PPAQ
Rating-Group by sending a PPAQ containing the Rating-Group-Id. In containing the Rating-Group-Id. In both cases the Update-Reason
both cases the Update-Reason will be set to ôInitial-Requestö. will be set to "Initial-Request".
The Authorize-Only Access-Request packet may contain more than one The Authorize-Only Access-Request packet may contain more than one
PPAQ. The Authorize-Only Access-Request MUST include one or more PPAQ. The Authorize-Only Access-Request MUST include one or more
attributes that serve to identify the session so that it can be attributes that serve to identify the session so that it can be
linked to the original authentication. Which Session Identifier(s) linked to the original authentication. Which Session Identifier(s)
is included is up to specific deployments. The Authorize-Only is 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 will allocate resources to each
PPAQ. The resources, can be in units of time, volume as before. PPAQ. The resources, can be in units of time, volume as before.
Each PPAQ will be assigned a unique QID that MUST appear in a Each PPAQ will be assigned a unique QID that MUST appear in a
subsequent PPAQ update for that service or rating-group. As well, subsequent PPAQ update for that service or rating-group. As well,
the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if
the PPAQ applies to the ôAccess Serviceö. the PPAQ applies to the "Access Service".
4.8.2 Quota Update 4.8.2 Quota Update
Once the services start to utilize their allotted quota they will Once the services start to utilize their allotted quota they will
eventually need to replenish their quotas (either the threshold is eventually need to replenish their quotas (either the threshold is
reached or no more quota remains). To replenish the quota the reached or no more quota remains). To replenish the quota the
Prepaid Client will send an Authorize-Only Access-Request message Prepaid Client will send an Authorize-Only Access-Request message
containing one or more PPAQs. Each PPAQ MUST contain the containing one or more PPAQs. Each PPAQ MUST contain the
appropriate QID, Service-ID or Group-ID (or neither the Service-ID appropriate QID, Service-ID or Group-ID (or neither the Service-ID
or Group-Id if the quota replenishment is for the ôAccess Serviceö). or Group-Id if the quota replenishment is for the "Access Service").
The Update-Reason filed will indicate either ôThreshold reachedö(3), The Update-Reason filed will indicate either "Threshold reached"(3),
or ôQuota reachedö(4). The Authorize-Only message must contain or "Quota reached"(4). The Authorize-Only message must contain
identifiers to identify the session. 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 Prepaid Server will respond with a new PPAQ for that
service. The PPAQ will contain a new QID, the Service-Id or Rating- service. The PPAQ will contain a new QID, the Service-Id or Rating-
Group-Id, a new Quota. If the Prepaid Server does not want to grant Group-Id, a new Quota. If the Prepaid Server does not want to grant
additional quota to the Service it MUST include the Termination- additional quota to the Service it MUST include the Termination-
Action subfield in the PPAQ that will instruct the Service Access Action subfield in the PPAQ that will instruct the SAD what to do
Device what to do with the service. with the service.
4.8.3 Termination 4.8.3 Termination
When an allotted quota for the service is used up the Service Access When an allotted quota for the service is used up the SAD shall act
Device shall act in accordance to the Termination-Action field set in accordance to the Termination-Action field set in the Quota. If
in the Quota. If the Termination-Action field is absent then the the Termination-Action field is absent then the Service MUST be
Service MUST be terminated. terminated.
If the Service is to be terminated then the Service Access Device If the Service is to be terminated then the SAD shall send a PPAQ
shall send a PPAQ with the appropriate QID, the Service-Id, the used with the appropriate QID, the Service-Id, the used quota, and
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 Service Access Device must be terminated as well. In this case the SAD must report on all
report on all issued quotas for the various services. The Update- issued quotas for the various services. The Update-Reason field
Reason field should be set to ôAccess Service Terminatedö. should be set to "Access Service Terminated".
Note when sending more then on PPAQ it may be required to send Note when sending more then on PPAQ it may be required to send
multiple Authorize Only Access-Requests. multiple Authorize Only Access-Requests.
4.8.4 Dynamic Operations 4.8.4 Dynamic Operations
Dynamic operations for multi-services are similar to dynamic Dynamic operations for multi-services are similar to dynamic
operations described for single service operations. The prepaid operations described for single service operations. The prepaid
system may send a COA message containing a PPAQ for an existing system may send a COA message containing a PPAQ for an existing
service instance. The Service Access Device will match the PPAQ to service instance. The SAD will match the PPAQ to the service using
the service using the Service-ID attribute. The new quota could be the Service-ID attribute. The new quota could be higher then the
higher then the last allocated value or it could be lower. The last allocated value or it could be lower. The SAD must react to
Service Access Device must react to the new quota accordingly. the new quota accordingly.
A Disconnect message may not be send for a specific service. A A Disconnect message may not be send for a specific service. A
disconnect message terminates the ôAccess Serviceö. As such the disconnect message terminates the "Access Service". As such the SAD
Service Access Device must report back all unused quotas by sending must report back all unused quotas by sending an Authorize Only
an Authorize Only Access Request message containing a PPAQ for each Access Request message containing a PPAQ for each active service.
active service. The Update-Reason shall indicate that the reason The Update-Reason shall indicate that the reason for the update
for the update reason. reason.
4.8.5 Support for Resource Pools 4.8.5 Support for Resource Pools
If the Prepaid Client supports pools as indicated by setting the If the Prepaid Client supports pools as indicated by setting the
ôPools supportedö bit in the PPAC(TBD) then the Prepaid Server may "Pools supported" bit in the PPAC(TBD) then the Prepaid Server may
associate a Quota with a Pool by including the Pool-Id and the Pool- associate a Quota with a Pool by including the Pool-Id and the Pool-
Multiplier in the PPAQ(TBD). Multiplier in the 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 Error Handling 4.8.6 One-Time-Charging
To initiate a One-Time charge the PPC include the PPAQ attribute in
an Access-Request packet. The Access Request packet MUST include
the Message-Authenticator(80) and Event-Timestamp(55) attributes.
The Service Id field of the PPAQ identifies the Service that is be
charged for. The amount of to be charged is specified using the
Resource Quota and Resource Quota overflow subtypes. If the value
specified is negative then the resources will be credited to the
userÆs account.
The QID field MUST be set to a unique value and will be used by the
PPS to detect duplicates should the packet be retransmitted.
The Update Reason field MUST be set to One-Time Charging.
Upon receiving a PPAQ configured as a One-Time charge, the RADIUS
server authenticates the user and if authenticated, pass the PPAQ to
the PPS. The PPS shall locate the subscriber account and debit or
credit the account accordingly. The PPS MUST repond to the PPS with
an Access-Accept message upon success. Or an Access-Reject message
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
Accept message. Since this is a one-time event charge the SAD must
not allow the session to continue. Therefore, the RADIUS server
should include in the Access-Accept a Session-Timeout set to 0. The
Upon receiving an Access-Accept response the SAD shall generate an
Accounting Stop message.
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
the user. The PPS shall respond back with an Access-Accept to
indicate that the userÆs account has been debited or an Access-
Reject indicating that the account could not be debited.
4.8.7 Error Handling
If the Prepaid Server receives a PPAQ with an invalid QID it MUST If the Prepaid Server receives a PPAQ with an invalid QID it MUST
ignore that PPAQ. ignore that PPAQ.
If the Prepaid Server receives a PPAQ containing a Service-Id, or a 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 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 Prepaid Client receives a PPAQ containing a Service-Id, or a
Rating-Group-Id that it does not recognize, then it must ignore that Rating-Group-Id that it does not recognize, then it must ignore that
skipping to change at page 33, line 39 skipping to change at page 36, line 35
4.9 Accounting Considerations 4.9 Accounting Considerations
Accounting messages are not required to deliver PrePaid Data Accounting messages are not required to deliver PrePaid Data
Service. Accounting message will typically be generated for PrePaid Service. Accounting message will typically be generated for PrePaid
Data Service. This because accounting message are used for auditing Data Service. This because accounting message are used for auditing
purposes as well as for bill generation. 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 Service Access Device Operation 4.10 SAD Operation
To be completed To be completed
4.11 Interoperability with Diameter Credit Control Application 4.11 Interoperability with Diameter Credit Control Application
RADIUS PrePaid solutions need to interoperate with Diameter RADIUS PrePaid solutions need to interoperate with Diameter
protocol. Two possibilities exist: The AAA infrastructure is protocol. Two possibilities exist: The AAA infrastructure is
Diameter based and the Service Access Device are RADIUS based; or Diameter based and the SAD are RADIUS based; or the SAD is Diameter
the Service Access Device is Diameter based and the AAA based and the AAA infrastructure is RADIUS based.
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 using an all Diameter based infrastructure.
<This section to be completed.> <This section to be completed.>
5. Attributes 5. Attributes
This draft is using the RADIUS [RFC2865] namespace. This draft is using the RADIUS [RFC2865] namespace.
skipping to change at page 35, line 40 skipping to change at page 38, line 36
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 PPAQ Attribute 5.3 PPAQ Attribute
One or more PPAQ(TBD) attributes are available to be sent in One or more PPAQ(TBD) attributes are available to be sent in an
Authorize Only Access-Request and Access-Accept messages. In Access Request, Authorize Only Access-Request and Access-Accept
Authorize Only Access-Request messages it is used to report usage messages. In an Access Request message, it is used to One-Time
and request further quota or request prepaid quota for a new service charging transactions; in Authorize Only Access-Request messages it
instance; in an Access-Accept message it is used to allocate the is used to for One-Time charging, report usage and request further
quotas (initial quota and subsequent quotas). quota or request prepaid quota for a new service instance; in an
Access-Accept message it is used to allocate the quotas (initial
quota and subsequent quotas).
When concurrent service are supported a PPAQ is associated with a When concurrent service 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 Service-Id; or a
Rating Group, as indicated by the presence of a Rating-Group-Id; or Rating Group, as indicated by the presence of a Rating-Group-Id; or
the ôAccess Serviceö as indicated by the absence of a Service-Id or the "Access Service" as indicated by the absence of a Service-Id or
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. Subtypes not used
are omitted in the message. are omitted in 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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 37, line 4 skipping to change at page 39, line 43
| DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationThreshold (DT) | | DurationThreshold (DT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 9 | LENGTH | PrePaidServer | | SUB-TYPE 9 | LENGTH | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrePaidServer | | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Sub-Type (=1): Sub-Type 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 Sub-Type is generated by the PrePaid server
at allocation of a Volume and/or Duration Quota. The on-line at allocation of a Volume and/or Duration Quota. The on-line
quota update RADIUS Access-Request message sent from the Service quota update RADIUS Access-Request message sent from the SAD to
Access Device to the PPS shall include a previously received the PPS shall include a previously received QuotaIDentifier.
QuotaIDentifier.
Sub-Type (=2): Sub-Type for VolumeQuota attribute Sub-Type (=2): Sub-Type 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 Sub-Type is only present if Volume Based
charging is used. In RADIUS Access-Accept message (PPS to Service charging is used. In RADIUS Access-Accept message (PPS to SAD
Access Device direction), it indicates the Volume (in octets) direction), it indicates the Volume (in octets) allocated for the
allocated for the session by the PrePaid server. In RADIUS session by the PrePaid server. In RADIUS Authorize Only Access-
Authorize Only Access-Request message (Service Access Device to Request message (SAD to PPS direction), it indicates the total
PPS direction), it indicates the total used volume (in octets) used volume (in octets) for both forward and reverse traffic
for both forward and reverse traffic applicable to PrePaid applicable to PrePaid accounting.
accounting.
Sub-Type (=3): Sub-Type for VolumeQuotaOverflow Sub-Type (=3): Sub-Type 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 Sub-Type 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 Sub-Type (=4): Sub-Type 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 Sub-Type 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
Service Access Device direction). It is generated by the PrePaid SAD direction). It is generated by the PrePaid server and
server and indicates the volume (in octets) that shall be used indicates the volume (in octets) that shall be used before
before requesting quota update. This threshold should not be requesting quota update. This threshold should not be larger than
larger than the VolumeQuota. the VolumeQuota.
Sub-Type (=5): Sub-Type for VolumeThresholdOverflow Sub-Type (=5): Sub-Type 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 Sub-Type 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 Sub-Type (=6): Sub-Type 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 Sub-Type 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
Service Access Device direction), it indicates the Duration (in SAD direction), it indicates the Duration (in seconds) allocated
seconds) allocated for the session by the PrePaid server. In on- for the session by the PrePaid server. In on-line RADIUS Access-
line RADIUS Access-Accept message (PPC to PPS direction), it Accept message (PPC to PPS direction), it indicates the total
indicates the total Duration (in seconds) since the start of the Duration (in seconds) since the start of the accounting session
accounting session related to the QuotaID. related to the QuotaID.
Sub-Type (=7): Sub-Type for DurationThreshold attribute Sub-Type (=7): Sub-Type 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 Sub-Type 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 Service Access Device direction). It represents the duration to SAD direction). It represents the duration (in seconds) that
(in seconds) that shall be used by the session before requesting shall be used by the session before requesting quota update. This
quota update. This threshold should not be larger than the threshold should not be larger than the DurationQuota and shall
DurationQuota and shall always be sent with the DurationQuota. always be sent with the DurationQuota.
Sub-Type (=8): Sub-Type for Update-Reason attribute Sub-Type (=8): Sub-Type 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 Sub-Type shall be present in the on-line RADIUS
Access-Request message (Service Access Device to PPS direction). Access-Request message (SAD to PPS direction). It indicates the
It indicates the reason for initiating the on-line quota update reason for initiating the on-line quota update operation. Update
operation. Update reasons 4, 5, 6, 7 and 8 indicate that the reasons 4, 5, 6, 7 and 8 indicate that the associated resources
associated resources are released at the client side, and are released at the client side, and therefore the PPS shall not
therefore the PPS shall not allocate a new quota in the RADIUS allocate a new quota in the RADIUS Access_Accept message.
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
Sub-Type (=9) : Sub-Type for PrePaidServer attribute Sub-Type (=9) : Sub-Type 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 indicates the address of
the serving PrePaid System. If present, the Home RADIUS server the serving PrePaid System. If present, the Home RADIUS server
uses this address to route the message to the serving PrePaid uses this address to route the message to the serving PrePaid
skipping to change at page 40, line 44 skipping to change at page 43, line 39
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 Sub-Type (=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.
NOTES: Sub-Type (=13) : Sub-Type for Resource Quota
Length : 6
Either Volume-Quota or Time-Quota MUST appear in the attribute. The optional ResourceQuota Sub-Type is only present if Resource
Based charging is used or when One-Time charging is being used.
In RADIUS Access-Accept message (PPS to SAD direction), it
indicates the Resources allocated for the session by the PrePaid
server. In RADIUS Authorize Only Access-Request message (SAD to
PPS direction), it indicates the total used resource for both
forward and reverse traffic applicable to PrePaid accounting. In
one-time charging scenarios, the subtype represents the number of
units to charge the user or to credit the user (negative values).
Sub-Type (=14) : Sub-Type for Resource Quota Overflow
Length : 6
Sub-Type (=15) : Sub-Type for ResourceThreshold
Length : 6
NOTES:
Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear in
the attribute.
Volume Threshold may only appear if Volume Quota appears Volume Threshold may only appear if Volume Quota appears
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 Table of Attributes 5.4 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
skipping to change at page 42, line 7 skipping to change at page 45, line 26
6.2 Replenishing Procedure 6.2 Replenishing Procedure
A successful replay attacks of the Authorize Only Access-Request A successful replay attacks 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. IANA Considerations 7. IANA Considerations
To be completed. This document requires the assignment of new Radius attributes type
numbers for the following attributes:
This draft does create RADIUS attributes. However, the authors 1) Prepaid-Accounting-Capability (PPAC)
recognize that it may not be possible to obtain such attributes. with subtype:
Therefore, in subsequent drafts it will be proposed to use a Vendor AvailableInClient
space as an Application Space.
2) Prepaid-Accounting-Operation (PPAQ)
with subtypes:
QuotaID (QID)
VolumeQuota (VQ)
VolumeQuotaOverflow (VQO)
VolumeTreshold (VT)
VolumeTresholdOverflow (VTO)
DurationQuota (DQ)
DurationTreshold (DT)
UpdateReason (UR)
PrePaidServer (PPS)
ServiceID (SID)
RatingGroupId (RGID)
TerminationAction (TA)
PoolID (PID)
PoolMultiplier (PM)
Cost (COST)
TariffChangeTime (TCT)
3) Session-Termination-Capability (STC)
4) International-Mobile-Subscriber-Identity (IMSI)
8. Normative References 8. 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 42, line 38 skipping to change at page 46, line 37
Extensions", RFC 2869, June 2000. Extensions", RFC 2869, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
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.
[DIAMETERCC] Work in Progress. [RFC3748] Aboba, B., et al., "Extensible Authentication
[REDIRECT] RADIUS Redirection Internet Draft. Work in progress. Protocol", RFC 3748, June 2004.
RFC 2284 EAP
9. Informative References
[DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control
Application", Internet Draft, AAA WG, April 2004,
Work in Progress.
[REDIRECT] "RADIUS Redirection", Internet Draft, Work in
progress.
10. Call Flows
9. Call Flows
This section includes call flows illustrating various scenarios This section includes call flows illustrating various scenarios
enabled by this specification. enabled by this specification.
The following are used in the call flows: The following are used 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
skipping to change at page 43, line 38 skipping to change at page 48, line 5
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
9.1 Simple Concurrent Services 10.1 Simple Concurrent Services
In this scenario the Prepaid Client authenticates and authorizes the In this scenario the Prepaid Client authenticates and authorizes the
user. The Prepaid Server responds back with Prepaid Quota for the user. The Prepaid Server responds back with Prepaid Quota for the
ôAccess Serviceö instance. The NAS then request quota for Service- "Access Service" instance. The NAS 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 45, line 11 skipping to change at page 49, line 19
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 scenario it will indicate
that Concurrent Session are supported. Access-Request also that Concurrent Session 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. Session Identifier is out of
scope in this document. It can be a single attribute such as scope in this document. It can be a single attribute such as
3GPP2 Correlation ID or it could be a set of attributes that 3GPP2 Correlation ID or it could be a set of attributes that
define a session. define a session.
B RADIUS authenticates the user and determines that the user is B RADIUS authenticates the user and determines that the user is
prepaid. RADIUS responds with a PPAQ for the ôAccess Serviceö prepaid. RADIUS responds with a PPAQ for the "Access Service"
(PPAQ does not contain a Service-ID or Rating-Group-ID). The (PPAQ does not contain a Service-ID or Rating-Group-ID). The
PPAQ has a QID=1 assigned by the Prepaid System and Quota of PPAQ has a QID=1 assigned by the Prepaid System and Quota of
Q=100. The quota could be time or volume and may or may not Q=100. The quota could be time or volume and may or may not
have a threshold associated with it. have a threshold associated with it.
C NAS starts the Access Service and generates an Accounting- C NAS starts the Access Service and generates an Accounting-
Request (Start) message as normal. It will include the Acct- 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 wants to start a new Service, call it Service-A. It
sends an Authorize-Only access request to RADIUS. The SID 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
skipping to change at page 45, line 43 skipping to change at page 50, line 10
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 used resources so far and the
reason why the update is being sent. 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. If it were not, then the NAS would not be able to
differentiate between the PPAQs. QIDs are not sufficient to differentiate between the PPAQs. QIDs are not sufficient to
correlate the PPAQ to a service since they are changed (and correlate the PPAQ to a service since they are changed (and
not necessarily sequentially) by the PPS at every transaction. not necessarily sequentially) by the PPS at every transaction.
In this scenario, notice how each PPAQ attribute represents a In this scenario, notice how each PPAQ attribute represents a
sequential conversation about a service between the Prepaid Client sequential conversation about a service between the Prepaid Client
and the Prepaid Server. The links between the messages are the QIDs and the Prepaid Server. The 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 As well, notice how a SID is needed to tie the Authorize-Only
messages to the Authentication steps. This SID is only really messages to the Authentication steps. This SID is only really
needed the first time a PPAQ is sent û since the PPAQ does not have needed the first time a PPAQ is sent since the PPAQ does not have
a QID. a QID.
Accounting messages have an Accounting-Session-ID. But that is not Accounting messages have an Accounting-Session-ID. But that is not
enough to allow the back end system to associate that accounting enough to allow the back end system to associate that accounting
message with a particular Service. We therefore need the PPAQ in message with a particular Service. We therefore need the PPAQ in
the accounting message. the accounting message.
10.2 One-time Charging
In this One-time charging scenario, the Prepaid Client (PPC)
authenticates and authorizes the user and requests charging for a
service event requested by the user. The PPC already knows the
price to charge for the service event identified by SRVID=SA.
Contributor
We would like to thank Hannes Tschofenig for his contributions to
this draft.
Acknowledgments Acknowledgments
The authors would like to thank Mark Grayson (Cisco) and Nagi The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala
Jonnala for their contribution to this draft. and Tseno Tsenov for their contribution to this draft.
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 Yong Li
Nortel Networks Bridgewater Systems Nortel Networks Bridgewater Systems
2221, Lakeside Blvd, 303 Terry Fox Drive 2221, Lakeside Blvd, 303 Terry Fox Drive
Richardson, TX-75082 Suite 100 Richardson, TX-75082 Suite 100
chowdury@nortelnetworks.com Ottawa Ontario chowdury@nortelnetworks.com Ottawa Ontario
Canada Canada
Yong.li@bridgewatersystems.com Yong.li@bridgewatersystems.com
Christian Guenther
Siemens
Otto-Hahn-Ring 6
82739 Munich
Germany
Christian.guenther@siemens.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the IETF's procedures with respect to rights in IETF Information on the IETF's procedures with respect to rights in IETF
Documents can be found in BCP 78 and BCP 79. Documents can be found in BCP 78 and BCP 79.
skipping to change at page 47, line 42 skipping to change at page 52, line 31
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
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 (2004). This document is subject to Copyright ¨ The Internet Society (2004). 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-
05.txt, and will expire 17 January, 2005. 06.txt, and will expire 24 March, 2005.
 End of changes. 134 change blocks. 
470 lines changed or deleted 673 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/