Network Working Group P. Francis
Internet Draft J. Brand
Category: Informational B. Gleeson
Tahoe Networks
June 2002
Design Issues for Prepaid Data Service
draft-francis-prepaid-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Prepaid voice services have proven to be extremely successful.
There is a desire to replicate this success for data services.
Prepaid for data presents new technical challenges, primarily due to
the wide range of billing that may be applied to data services---
volume or time billing, differential billing by type of application
(gaming, steaming, browsing, voice), billing by destination, and
even billing of specific content. Furthermore, a single data
prepaid service may need to accomodate simultaneous network access
by multiple devices (phone, laptop, PDA).
This paper discusses design issues for a protocol between a prepaid
application and the data network element. It defines an
architecture and terminology. It describes basic characteristics of
data prepaid service, as well as some advanced features. It
analyzes the main technical issues, especially performance issues.
Finally, this paper describes the semantics of an illustrative
prepaid data service protocol. This document does not, however,
specify such a protocol.
Francis et. al. Informational [Page 1]
Prepaid Data Service Design Issues June 2002
Table of Contents
1 Introduction...................................................2
2 Terminology....................................................3
3 Architecture...................................................5
4 Usage Scenarios................................................7
4.1 Basic Usage Scenarios........................................7
4.2 Advanced Usage Scenarios.....................................8
5 System Capabilities............................................9
5.1 Operational..................................................9
5.2 Performance.................................................11
5.3 Robustness..................................................13
6 Protocol Design Issues........................................14
6.1 The Balance/Quota/Usage Model...............................14
6.2 Identifying Quotas and Usage................................15
6.3 Counting usage with no quota................................15
6.4 The token model of quota/usage management...................16
7 Protocol Semantics............................................17
7.1 quotaRequest(UID, QID, quotaUsage)..........................18
7.2 sessionEnd(UID, QID, quotaUsage)............................18
7.3 quotaAllocate(UID, QID, quotaUsage, serviceState)...........19
7.4 quotaReturnRequest(UID).....................................19
7.5 serviceUpdate(UID, serviceState)............................19
7.6 Example.....................................................19
8 Security Considerations.......................................23
9 Acknowledgements..............................................24
10 References..................................................24
11 AuthorsÆ Addresses..........................................24
12 Copyright...................................................25
13 Intellectual Property.......................................26
1 Introduction
Prepaid voice services have proven to be extremely successful.
There is a desire to replicate this success for data services. Data
billing, however, has a number of significant differences compared
to billing for voice. For instance, billing for data is much more
variable. A data session billed by the byte can go for hours with
virtually no usage, then suddenly without warning consume many
megabytes in a few minutes. Voice usage varies far less, and
furthermore the prepaid billing application has advance warning that
the voice service will be used (i.e. call setup).
Within a data session, different simultaneous data flows can be
rated differently, for instance streaming versus MMS (Multi-media
Messaging Service) versus web browsing. Voice on the other hand has
only a single "flow" at a time.
Francis et. al. Informational [Page 2]
Prepaid Data Service Design Issues June 2002
Data services can potentially have more "sources" of prepaid usage.
If data and voice services are combined in a single prepaid account,
then right away there is an extra source as compared to voice alone.
Further, a data service may involve multiple data connections, for
instance one for VPN access and another for internet access, or one
for the PDA and another for the laptop. An operator may even wish
to attach billing for content or other transactions to a prepaid
account, resulting in even more sources with very high variability.
As described within this document, these differences place new
technical demands on the prepaid application. The prepaid
application has to be smarter about how it allocates the prepaid
account balance to various sources. This in turn puts new demands
on the protocol(s) that operate between the prepaid application and
the network devices and other sources.
Existing prepaid data protocols, such as CAMEL [3] in 3GPP [4] and
early proposals in 3GPP2 TSG-P [5], are patterned after traditional
voice prepaid services and do not account for the richness and
variability of data services. There is a concern that these prepaid
data protocols will become entrenched, and will be inadequate or
scale poorly with richer billing models. In addition, CAMEL runs
over SS7 and therefore cannot easily be used in data environments
other than 3GPP. A prepaid data solution should work equally over
802.11 hotspots, 3G wireless networks, landline networks, and so on.
This memo does not specify a protocol. Rather, it describes the
characteristics of a rich prepaid data service, and discusses design
issues and possible solutions.
2 Terminology
Account: Also called prepaid account. This is the subscription
between the user and the operator. It starts when the user
purchases an account, and ends when the account balance runs out and
the user chooses not to add to the balance.
Balance: Also called prepaid balance. This is the total amount of
money that the user has put into his prepaid account.
Data Session: A session (tunnel) between the User Equipment (UE)
and a Prepaid Usage Point (PUP) that is a data router or switch.
Examples include MIP and PPP (IETF and 3GPP2), PDP Contexts (primary
and secondary) (3GPP), and RP (3GPP2). There can be multiple
sessions between the UE and the PUP.
IP Conversation: This term is used to refer the set of bi-
directional IP flows associated with the instantiation of a given
application flow. For instance, an FTP file transfer consists of an
IP flow associated with the control connection, and an IP flow
associated with the actual data transfer connection. These IP flows
collectively are referred to as an IP conversation.
Francis et. al. Informational [Page 3]
Prepaid Data Service Design Issues June 2002
IP Conversation Spec (IPC Spec): A description of the IP
conversation.
Multi-source prepaid: This is where multiple services (data, voice,
etc.) can be used from the same prepaid account.
Operator: The provider of the prepaid data service.
Prepaid Application Database (PPDB): Conceptually, this is the
database that stores the account balance for the user as well as
which quotas have been allocated to which PUPs.
Prepaid Application Server (PAS): This is the box that runs (or
talks to) the prepaid application and interacts with the PUP---i.e.
allocates quotas to PUPs, tells the PUP whether to allow or deny
service, and so on. There may be multiple PASs. Conceptually, each
PAS interfaces on the back end with a single PPDB.
Prepaid Usage Point (PUP): This is where usage is measured and
enforced. The PUP receives quotas from the PAS, and either allows
or denies usage to the user. For the most part, this memo focuses
on PUPs that are data routers or switches. Other types of PUPs
include those for voice services and "higher level" data services
such as content download, location services, etc.
Quota: This is the amount of usage (time or bytes) that has been
allocated to the PUP.
Rating: This is the act of translating between money and time or
bytes usage.
Replenish: This is where the user adds additional money to the
prepaid account, typically after a depletion warning or actual end
of service.
Usage: Measured as time or bytes (in the case of data or voice
routers/switches), or money (in the case of content or other
transaction servers).
Usage Session: This is usage extended over a period of time, during
which the PAS allocates quotas. It begins with authentication and
an initial allocation, and ends either when no more quotas are
allocated, or when the user terminates usage (ends the data session
or voice call, for instance).
Usage Transaction: This is usage that takes place at a single point
in time. It consists of a single quota allocation for the exact
amount of the transaction. Either the entire transaction is
allowed, or none of it. Examples include content download or a
single directory service lookup.
Francis et. al. Informational [Page 4]
Prepaid Data Service Design Issues June 2002
User: The entity (usually but not necessarily a person) associated
with a prepaid account.
User Equipment (UE): The device (handset, laptop, etc.) the user
uses to access the network. There may be more than one UE active
for a given user.
3 Architecture
Figure 1 shows a reference architecture relative to a single userÆs
prepaid account. It shows three Prepaid Application Servers (PAS)
operating with a single Prepaid Application Database (PADB). The
user has two User Equipments (UE1 and UE2), for instance a laptop
and a phone. UE1 has two data sessions with the first Prepaid Usage
Point (PUP1) and one with PUP2. UE2 has a single data session with
PUP2.
Prepaid
PADB Application
/ | \ Database
/ | \
/ | \
/ | \
/ | \ Prepaid
PAS1 PAS2 PAS3 Application
| | | Servers
| | | Usage
| | | Sessions
| | |
| | |
PUP1 PUP2 ... PUP3 ...
| | / |
| | / | Data
| | / | Sessions
| | / |
| |/ |
UE1 UE2 User Equipment with different UIDs
\ /
\ /
User
Figure 1: Reference Architecture (Single Account)
Although PUP1 has two data sessions with UE1, it can abstract them
as a single usage session with PAS1. In other words, PAS1 need not
be aware of the individual data sessions in the network. If UE1 and
UE2 were using the same User Identifier (UID), then PUP2 could also
abstract its two data sessions as a single usage session. In Figure
1, however, we assume different UIDs. PUP2 does not know that UE1
Francis et. al. Informational [Page 5]
Prepaid Data Service Design Issues June 2002
and UE2 are attached to the same user and prepaid account, and so
creates two usage sessions. Note that the UID could explicitly
identify the user (i.e. an NAI), or the device (i.e. an MS-ISDN
number). We assume that the PAS or PADB is capable of mapping the
UID into the appropriate user prepaid account.
Figure 1 also shows a PUP (PUP3) that does not have a usage session
with a PAS (e.g. because it is a voice switch with no active call
for the user). If the user were to access services on that PUP, the
PUP would then establish a usage session or execute a usage
transaction with one of the PASs.
Multiple PASs are assumed for reasons of redundancy and load
sharing. A single PADB, on the other hand, is assumed because
ultimately there must be a single consistent database for the
account balance and allocated quotas. The PAS can offload low-level
protocol functions (retransmissions, duplication detection) from the
PADB. Note, however, that this memo mainly concerns itself with the
design of the usage session. In particular, it says nothing about
how the PAS/PADB may be implemented, except to say that the PUPs may
interface with multiple PASs. The PADB could for instance consist
of multiple geographically separated systems.
Figure 2 shows details of the architecture related to roaming. It
shows that the PASs, as well as the PADB, are in the home network.
The PUP, on the other hand, may be in the visited network or the
home network. Though not required by this architecture, it is
likely that the protocol used for usage sessions will be AAA (RADIUS
[1,2] or DIAMETER). In this case, the usage session between an PUP
in a visited network and a PAS in the home network may traverse a
broker AAA network.
The primary difference between accessing the PAS from the home
network versus the visited network is in terms of deployment
flexibility. It is easier to deploy separate AAA servers and PASs
if the PUP is in the home network, because the PUP may be configured
with separate PAS and AAA addresses.
If on the other hand the PUP is in a visited network, then the
broker AAA, or if none the visited AAA, must be able to distinguish
between prepaid messages and non-prepaid messages. While this
capability can be implemented, it results in more administrative
coordination. As such, Figure 2 shows separate AAA and PAS only for
the case where the PUP is in the home network.
Finally, note that if AAA is used, then there must be an NAI to
identify the userÆs prepaid account. In some cases, there may be no
explicit NAI in the UE that accesses the network. For instance,
there may only be an IMSI or MS-ISDN (phone) number. In these
cases, the PUP may need to manufacture an NAI out of these other
identifiers. This process is outside the scope of this memo.
Francis et. al. Informational [Page 6]
Prepaid Data Service Design Issues June 2002
+-------------------------------+
| PADB Home|
| / | \ Network|
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| AAA/PAS AAA/PAS PAS AAA |
| | / | | / |
| | / | | / |
| | / | | / |
| | | | | / |
| | | PUP PUP |
+-----|--|----------------------+
| |
+-----|--|------------------+
| | \ Broker|
| | \ Network|
| | \ (optional)|
+-----|------|--------------+
| |
+-----|------|--------------+
| | | Visited|
| AAA AAA Network|
| | | |
| PUP PUP |
+---------------------------+
Figure 2: Reference Architecture showing Roaming
4 Usage Scenarios
This section describes some of the prepaid data service usage
scenarios that distinguish data prepaid from voice prepaid (though
of course there is some overlap). They are divided into two types,
basic and advanced. The basic usage scenarios are those that are
minimally necessary for a prepaid data service.
4.1 Basic Usage Scenarios
U1. The user somehow pays the operator in advance for data and
possibly other services. (The user may pay for and activate the
service without using the data service per se.) When the
purchased services are used, the service is no longer available
to the user. The following represent a number of possible
service options:
a. Data only for a single device and a single data session, as
measured by number of bytes or data session time. Other
possible prepaid services, such as voice, must be purchased
separately.
Francis et. al. Informational [Page 7]
Prepaid Data Service Design Issues June 2002
b. Data only, but for multiple devices and/or multiple data
sessions (for instance, one data session for regular internet
access and another for VPN access).
c. Data and voice are combined within the same prepaid account.
Voice services may include special services such as directory
service etc.
d. Data, voice, and other "higher level" data services such as
content download, location services, etc., are combined
within the same prepaid account.
U2. The latter three service plans above (b, c, and d) are called
multi-source, because there are multiple sources of prepaid
usage. The user is able to use each service as much or as
little as he wishes (to a fine level of granularity). In other
words, say the user buys a $10 prepaid account for voice and
data. The user should be able to use $5 data and $5 voice, $9
data and $1 dollar voice, or $9.90 data and $.10 voice.
U3. The user is able to purchase and activate (i.e. replenish) the
prepaid account through the data service itself. The data usage
related to this activity is "free" in that it is not charged
against the prepaid account per se (which after all may not
exist or may be depleted). (Note that the method of
replenishment per se is out of scope for this memo. It is the
free access to the replenishment application that is in scope.)
a. If the user is accessing the data service when there is no
balance, then the user has access to the replenishment
application (and possibly other free services such as
customer care or emergency services), but no other network
access. This is called limited-service.
4.2 Advanced Usage Scenarios
U4. After replenishing the balance, the user has immediate access to
data service (i.e. he does not have to disconnect and reconnect
to obtain data service).
U5. The prepaid service is able to warn the user when the account is
near depletion. As before, this usage of the data service is
not charged against the account.
U6. As part of the data service, the network is able to end the
userÆs data session when the user has been inactive for a period
of time. When the prepaid service is time charged, the prepaid
service charges the user for only to the time of last active
use, not to the time the data session was actually network-
terminated.
U7. The prepaid data service plan includes differential billing
based on:
a. Time-of-Day (ToD)
b. type of application (i.e. streaming, MMS, etc.)
c. the destination (i.e. premium content),
d. the QoS offered on different data channels (i.e. PDP
Contexts).
Francis et. al. Informational [Page 8]
Prepaid Data Service Design Issues June 2002
5 System Capabilities
This section outlines the capabilities needed in a prepaid data
system to provide the usage scenarios described above. The
capabilities are divided into basic and advanced capabilities
depending on whether they provide for the basic or advanced usage
scenarios. Where it is not self-evident, a rationale for the
capability is provided.
The capabilities are categorized into those that derive from
operational characteristics, those that improve system performance,
and those that provide robustness.
5.1 Operational
Basic capabilities:
BC01. The PUP is able to request authorization for user access from
a PAS when the user initiates a data session. Either the user
must already be authenticated by the PUP, or the PAS may
authenticate the user at the same time. (U1)
BC02. The PUP is able to do firewalling and policy-based forwarding
(steering) in order to implement limited-services. The specific
firewall and steering configuration (i.e. IPC specs) for
limited-services does not need to be explicitly set by the PAS--
-it can be configured in advance by network management because
it does not change often. The PUP, however, must have the
capability to dynamically enable and disable the limited-service
state (i.e. when the quota expires). (U3)
BC03. The PUP is able to identify which packets are going to free
services (based on the IPC spec), and not count those packets
towards the quota. (U3, U5)
Advanced capabilities:
AC01. When the PUP is giving limited-service to a given user, the
PAS is able to command the PUP to switch over to full-service.
This would occur after the user has replenished his account.
(U4)
Rationale:
This is an important capability, but the reason it is considered
advanced and not basic is because there is an alternative approach.
Specifically, the replenishment application can simply instruct the
user to disconnect and reconnect after replenishment. When the user
reconnects, the PAS would be able to allocate a new quota to the
PUP. The disadvantage of this approach, in addition to
inconveniencing the user, is that user network applications that may
have stayed up during the limited-service period (i.e. a file
transfer) would likely be torn down after disconnect.
Francis et. al. Informational [Page 9]
Prepaid Data Service Design Issues June 2002
AC02. When the PUP terminates the data session due to traffic
inactivity, the PUP conveys both the termination time and the
last active time to the PAS. This allows the PAS to calculate
session time from the last active time for the purposes of
returning money to the account. (U6)
AC03. The PUP can be configured with differential rating
information for one or more of the four differential accounting
types under usage scenario U7. The PUP may be configured in one
of two ways:
1. The PAS conveys multiple quotas, one for each type of
differential accounting.
2. The PUP is pre-configured with rating information for each
user (or class of user), and can apply this rating
information to the (single) quota conveyed to the PAS (non-
roaming case only). (This is explained in the following
rationale.)
Rationale:
For the U7 usage scenarios, there are two technical approaches
(corresponding to capabilities AC03.1 and AC03.2 above). In the
first, the PAS can explicitly convey the differential billing
instructions to the PUP---essentially a list of IPC specs and the
quota associated with each. The PUP would keep track of the
fraction of the quota used by each, and when the sum of the
fractions totaled to 1, the PUP would consider the quota expired and
report to the PAS. For this to work, the PAS must be configured
with the appropriate IPC spec and rating information. We can call
this approach the smart-PAS approach.
For instance, assume that streaming is rated at $1/Mbyte, and non-
streaming at $10/Mbyte. Assume also that the user account is $20.
The PAS would convey a list of two quotas:
streaming-IPC Spec; 20 Mbytes
default; 2 Mbytes
Say the user then uses 15 Mbytes of streaming (75% of the quota) and
0.5 Mbytes of non-streaming (25% of the quota). 75% + 25% = 100%,
and so the PUP would expire the quota and report.
In the second approach, the PUP can be configured with the IPC spec
and rating information instead of the PAS. The PAS would simply
send a single quota (as normal), and the PUP would increase or
decrease the quota relative to each IPC spec according to the rating
information. We can call this approach the dumb-PAS approach.
For instance, using the above example, the PUP could be configured
to know that 10 bytes of streaming traffic equals 1 byte of non-
streaming traffic. The PAS would give the PUP a quota of 2 Mbytes,
and the PUP would understand that this means 20 Mbytes of streaming.
Both approaches require the same amount of configuration. The
smart-PAS approach, however, requires a significantly more complex
PUP-PAS protocol, and a more complex PAS. The dumb-PAS approach, on
Francis et. al. Informational [Page 10]
Prepaid Data Service Design Issues June 2002
the other hand, does not particularly increase the complexity of the
PUP, since it must be able to classify traffic and do differential
counting in any event.
The problem with the dumb-PAS approach is that practically speaking
it is limited to the non-roaming case (the PUP is in the home
network). If the PUP is in the visited network, then it needs some
way of obtaining the rating information for a given user. This
creates a coupling between the management systems of the home and
visited network. Such a coupling does not generally exist in
practice.
5.2 Performance
A critical aspect of the design of a real-time prepaid data service
is the load on the PASs, and especially the PADB. It is important
that the number of transactions that result in updates to the PADB
be minimized. In postpaid billing models, the AAA server receiving
the accounting messages can simply dump the messages to a disk for
later processing. The AAA server does not, for instance, have to
deal with detecting duplicate or out-of-order messages in real time,
thus reducing its processing load.
In prepaid, on the other hand, these functions must be done in real
time. This increases performance demands on the PAS (which takes
care of low-level reliability and duplicate-detection) and on the
PADB (which must update the database after a quota allocation or
usage report). These operations are all relatively expensive, and
so it pays to try to reduce the number of such operations.
Basic Capabilities:
BC10. The PAS is able to allocate a quota, as measured in session
time or bytes, to the PUP. The PAS can also tell the PUP what
to do when the quota is reached (in addition to reporting to the
PAS):
a. Continue full service (full-service).
b. Keep the data session up, but limit service to replenishment
and free services (limited-service).
c. Terminate the data session (no-service).
Rationale:
This capability derives from the desire for relative accuracy in
providing the amount of service that has been purchased. A simple
method whereby the PUP provides frequent periodic reports of usage
(sometimes called hot billing) is inadequate because of the large
overhead needed to achieve good accuracy. Even a method whereby the
PAS tells the PUP to report after a specific amount of usage, but
where the PUP then waits for further instructions from the PAS (i.e.
to offer full-service or limited-service) is probably not accurate
enough. There may be significant delays between reporting and
getting further instructions, for instance if the PAS is overloaded.
Francis et. al. Informational [Page 11]
Prepaid Data Service Design Issues June 2002
Because of the variability of data service, a large amount of data
(and therefore prepaid balance) may be used in a relatively short
time.
The need for the PUP to give limited-service (b) or no-service (c)
is obvious: if the quota equals the full amount of the account
balance, then the user must not get full service when the quota
expires. Limited-service is used for scenario U3.
If the quota does not equal the full amount of the balance, then the
PUP must continue full-service. There are a few reasons why the PAS
would allocate a quota for less than the balance. One is the multi-
source cases, where there are other PUPs or PUPs that consume the
prepaid balance (scenarios U1.b, U1.c, and U1.d). Another is where
the PAS wishes to know when the user is nearing account depletion so
that it can warn the user (U5). A third is where the PAS simply
wants to limit the size of the quota so as to limit its losses
should the PUP crash and lose its accounting information (see
advanced capability AC10, however, for a more efficient approach to
the warning notification).
BC11. If a user terminates the data session before the quota has
expired, the PUP is able to report the portion used to the PAS.
This must be reliably acknowledged so that the PAS can insure
that it is returned to the PADB before acknowledging it.
BC12. The PAS is able to reduce the size of a quota already
allocated to an PUP. It can do so without first waiting for the
PUP to contact it.
Rationale:
This capability is derived from the multi-source usage scenarios
U1.b, U1.c, U1.d, and U2. Scenario U2 says that the user should be
able to use each multi-source service as much or as little has he
wants. For usage session services, the PAS does not know in advance
how much usage will occur. For instance, when a user initiates a
data session, he may browse a little bit once an hour, or start a
multi-Mbyte streaming session.
For instance, assume that a user has $20 in his account, good for
either 100 Mbytes of data or 100 minutes of voice (or any
combination). The user starts an always-on data session. Now
assume that the PAS allocates a 25 Mbyte quota ($5 worth) to the
PUP, but that the user uses very little of it. Subsequently the
user makes a number of long phone calls, eventually using up 75
minutes. The user would like to use the phone more, but cannot
unless the PAS can shrink the quota at the PUP and reallocate it to
the voice service.
One way to solve this problem is for the PAS to allocate smaller
quotas to the PUP. For instance, say the PAS allocated only 1 Mbyte
to the ($0.20, or equivalent one minute of voice). If the user uses
very little data, then all is fine---the user can have 99 minutes of
Francis et. al. Informational [Page 12]
Prepaid Data Service Design Issues June 2002
voice. If the user uses a lot of data, however, then the PUP must
quickly request more quotas---100 in total if all $20 are used by
the data service. This puts a large and unnecessary load on the PAS
and PADB.
If on the other hand the PAS is able to shrink the size of an
already allocated quota, it can potentially allocate say 50 Mbytes
to the data session. If a voice call starts, the PAS could then
give 50 minutes to the voice PUP. If the voice call reached 50
minutes, the PAS could take 25 Mbytes away from the data PUP and
give another 25 minutes to the voice PUP, and so on. The best
strategy for how much to give and take depends on the expected
traffic and call patterns (i.e., if users on average use more data
than voice, then the data quotas should probably be larger than the
voice quotas). The best strategy to use is out of scope for this
memo. The point here is simply that the PAS should be able to
shrink quotas so that the most efficient strategy, whatever it is,
may be implemented.
Advanced Capabilities:
AC10. The PAS is able to request interim reports from the PUP to
occur at specified usage levels (bytes or time). These interim
reports do not affect the quota per se. In other words, by
sending the interim report the PUP does not for instance reset
the counters counting against the quota. Nor does the PAS, by
receiving the interim report, modify the balance. (U5)
Rationale:
Since capability BC10.a can be used to satisfy usage scenario U5,
this capability (AC10) is strictly speaking not mandatory. It is
more efficient, however, to notify the PAS at a certain usage level
by merely sending an interim report than by expiring a quota. The
reason is because expiring a quota results in both reconciling the
balance in the PADB and notifying the replenishment function,
whereas the interim report results in only the latter.
5.3 Robustness
For scalability and robustness reasons, we assume that there may be
more than one PAS. The PADB, though modeled as a single database,
may of course also be implemented as multiple platforms, for
instance as a cluster of systems. How this is done is beyond the
scope of this memo.
Advanced Capabilities:
AC20. The prepaid service works properly in the face of PASs
crashing. A PAS failure will at worst result in only a
temporary quota-state mismatch between PUP and PADB. Likewise,
interim reports will not be lost due to a PAS crashing.
AC21. If the PUP has been instructed to continue full-service after
the current quota expires, there is a mechanism to limit the
usage should it be impossible to obtain another quota (either
Francis et. al. Informational [Page 13]
Prepaid Data Service Design Issues June 2002
because all PASs are down, or because the PADB is down). At a
minimum, the mechanism may be a default setting in the PUP.
Optionally, it could be a usage limit conveyed by the PAS at the
time the quota is allocated. For instance, the usage limit
would represent the total balance of the user.
AC22. A crash of an PUP may result in the loss of the quota it was
holding. The PAS/PADB, however, needs to be able to detect that
this quota was lost.
AC23. The crash of an PUP never results in an immediate burst of
activity on the PADB for all affected users (i.e. trying to
reconcile all of the lost quota). At worst, the PAS/PADB may
see increased load due to the affected users attaching to other
PUPs which in turn request quotas.
6 Protocol Design Issues
The PAS-PUP interaction is relatively simple---the PAS allocates
quotas to the PUP, and the PUP measures usage against them and
reports back. Never-the-less, care has to be taken to insure that
quotas donÆt get lost or duplicated, and to keep the protocol as
simple as possible. This section addresses a few such protocol
design issues.
6.1 The Balance/Quota/Usage Model
There are three objects of interest in the design of a prepaid
protocol; the balance, the quota, and the usage (see Figure 3).
The balance, in units of money, resides at the PADB. At any given
time, portions of this balance are allocated to PUPs as quotas. The
PADB of course keeps a record of the quota. The PUP measures usage,
and deducts it from the quota. At some point in time, the PUP
reports the usage to the PADB. The PADB deducts the usage from the
allocated quota. A rating function in the PADB translates between
the balance (money) and the quota (bytes or time).
Except for short transient periods, the PADB and the PUP must agree
on the quota state. This means that the quota cannot be lost or
duplicated when transmitted from PADB to PUP, and that the usage
cannot be lost or duplicated when transmitted from PUP to PADB.
Francis et. al. Informational [Page 14]
Prepaid Data Service Design Issues June 2002
PUP PADB
+-------+
|Balance|
+-------+
| 1. Quotas are deducted
2. Quota is conveyed | from the Balance
to the PUP V
+-------+ +-------+
| Quota |<------------(Rated)| Quota |
+-------+ +-------+
| 3. Usage deducts from |
| the Quota (possible | 5. Usage deducts from the
V slight excess) V Quota (with excess from
+-------+ +-------+ the Balance)
| Usage |------------>(Rated)| Usage |
+-------+ +-------+
4. Usage is conveyed
back to the PADB
Figure 3. Balance/Quota/Usage Model
6.2 Identifying Quotas and Usage
The quotas and usages are being conveyed via the PAS. Although the
PAS may keep state during a given transaction (for instance to
detect duplicates and acknowledge messages), long term it is
stateless. A usage report may go through a different PAS than that
of the preceding quota. Also, the same usage or quota may be
transmitted multiple times by different PASs. For instance, an PUP
may transmit a usage to a PAS, which updates the PADB. Before being
able to acknowledge the usage to the PUP, the PAS may crash.
Eventually, the PUP will try retransmitting via a different PAS,
which will report the same usage to the PADB.
To protect against this sort of failure, quotas and usages must have
unique identifiers. The identifiers must be unique in space
(different PUPs would have to generate different identifiers), and
for a substantial period of time (i.e. if sequence numbers, the
sequence number space should be large). Note that it is somewhat
easier for the PADB to generate a unique identifier than the PUP.
The PADB is centralized whereas there are multiple PUPs. Two PUPs
may have the same IP address, because they are behind different
NATs. They could potentially have the same FQDN (or none at all).
Multiple PUPs could be generating usage for the same user.
6.3 Counting usage with no quota
There may be short periods of time when an PUP may be providing
service and measuring usage even when it has no quota. This can
Francis et. al. Informational [Page 15]
Prepaid Data Service Design Issues June 2002
happen during the period of time after the PUP has expired a quota
and before it receives a new one.
One approach to this might for the PUP to request a new quota before
the current one expires. Even here, however, it is difficult to
absolutely guarantee that the PUP wonÆt sometimes be without a
quota. This is both because the PUP cannot be sure how quickly the
user might consume bandwidth and deplete the quota, and cannot know
for sure how long it will take to obtain the new quota. If there
are packet losses and the PAS/PADB is very busy, it could take 10s
of seconds.
Therefore, any design must include the capability for an PUP to
count usage with no quota, and to apply that usage to the next quota
when it is received. Given that this is true, there seems to be no
reason to try to complicate the protocol by trying to avoid counting
usage with no quota. Rather, as discussed below, it is easier to
treat counting usage with no quota as a systematic occurrence, not
an exceptional case.
Of course, the no-quota periods should be brief, and there should be
a fallback limit to how much usage the PUP will allow with no quota.
6.4 The token model of quota/usage management
The above concerns suggest a token model of quota/usage management.
While this is by no means the only way to manage quotas and usage,
it appears to be a simple and effective approach.
In this model, there is conceptually a single token that is handed
to the PUP with a quota, and handed back to the PADB with a usage
report. The PUP can never report usage unless it has a token to
report with. The unique identifier for the token is generated by
the PADB.
This token model is simpler than a model where the PUP has to
generate its own unique identifiers for usage reports. It avoids
the issue of insuring that different PUPs generate different
identifiers, and that a single PUP doesnÆt reuse a number (for
instance because its clock gets set incorrectly).
In addition, using a single token at a time, rather than allowing
multiple tokens, also simplifies operation without compromising
functionality. (In what follows, to simplify the description, the
terms "token" and "usage report" are not used. Instead we speak in
terms of a quota being handed (or allocated) to the PUP, and the PUP
"returning the quota" to the PADB. The unique identifier is called
the "quota ID". It is understood that when the PUP returns the
quota, the usage is reported.)
There are two ways to design (token-based) quota management:
1. Allow the PUP to have 0, 1, or N quotas.
Francis et. al. Informational [Page 16]
Prepaid Data Service Design Issues June 2002
2. Allow the PUP to have 0 or 1 quotas.
Allowing 0 or 1 quota is simpler, without loss of functionality. It
simplifies the implementation. It simplifies the protocol. It
avoids questions like "When the PADB needs to shrink the quota,
which quotas does it shrink?" (Not that this question would
necessarily be hard to answer, its just easier not to have to ask it
in the first place.) In short, it makes the protocol easier to
reason about, and therefore easier to design, implement, operate,
and debug.
Another simplifying aspect is that the PADB cannot shrink the quota
in the PUP per se. Instead, it must ask the PUP to return the quota
(at whatever usage level exists at the time it is returned). This
causes the PUP to request another quota, which can be smaller than
the previous one. The reason this is simpler than trying to shrink
the quota is that it eliminates the need for the new sequence number
space that would be needed to maintain the ordering of quota
shrinking requests. It also reuses the mechanism of the PUP
requesting a quota, which is in any event needed for when a quota
expires.
One might argue that this simplicity is achieved at the cost of
inefficiency. Simply shrinking the quota requires only two messages
(the "shrink your quota" message and its ack), rather than four (the
"give back the quota" message and its ack, followed by the
subsequent quota request and allocation). In practice, however, it
doesnÆt work this way. The PADB needs to shrink the quota when
another PUP requests some of the balance. In order to know how much
balance it can allocate, the PADB first needs to know how much of
the current quota has been used. Therefore, the shrink message
would in any event need to be preceded by a "what is your usage"
message and its answer. It is therefore no less efficient for the
PADB to ask the PUP to return the quota, and in the process learn
how much of the quota is unused. And, it only requires one new
message ("give back the quota") rather than two ("what is your
usage" and "shrink your quota").
7 Protocol Semantics
This sections outlines the semantics of a protocol between the PAS
and PUP that satisfies all of the basic capabilities put forth in
this document, while taking into consideration the above design
issues. Note that this is by no means a complete protocol
specification. Rather, it serves to clarify and make concrete the
protocol issues described above.
The protocol has five messages with the following semantics:
From the PUP to the PAS:
quotaRequest(UID, QID, quotaUsage)
sessionEnd(UID, QID, quotaUsage)
Francis et. al. Informational [Page 17]
Prepaid Data Service Design Issues June 2002
From the PAS to the PUP:
quotaAllocate(UID, QID, quotaUsage, serviceState)
quotaReturnRequest(UID)
serviceUpdate(UID, serviceState)
In all messages, the UID is the User ID/Device ID (NAI, MS-ISDN,
IMSI, etc.).
The QID is the Quota ID, and may be NULL if there is no quota.
quotaUsage is measured in bytes or seconds. In messages from the
PAS to the PUP, the quotaUsage is the usage at which the quota
should be returned. In messages from the PUP to the PAS, the
quotaUsage is the usage at the time the quota was returned.
serviceState is one of full-service, limited-service, or no-service.
The use of these messages are described in the following sections.
7.1 quotaRequest(UID, QID, quotaUsage)
This message is used by the PUP to both:
1. Return the current quota and report its usage, and
2. Request a new quota
This is the only message that is used to request a quota. This
message is sent under the following conditions:
1. The first data session begins. In this case the QID is NULL.
2. The current quota expires. In this case the quotaUsage is the
same or slightly more that that of the preceding quotaAllocate.
It could be slightly more in the case where the quota was measured
in bytes, and expired midway through a packet. In this case, the
remaining bytes may also be reported.
3. The reception of a quotaReturnRequest command from the PAS. In
this case, the quotaUsage is whatever the usage was when this
quotaRequest is sent.
4. The reception of a serviceUpdate command from the PAS with a
serviceState of full-service. In this case the QID is NULL.
The reply to this message is the quotaAllocate.
7.2 sessionEnd(UID, QID, quotaUsage)
This message is used by the PUP to return the last quota when the
data session is ended by the user. Unless the quotaUsage is 0, it
must contain a non-NULL QID. If the data session ends when the PUP
does not have a quota but has non-0 usage, the PUP must first
request and obtain a quota before sending the sessionEnd.
The reply to the sessionEnd is a simple Ack.
Francis et. al. Informational [Page 18]
Prepaid Data Service Design Issues June 2002
7.3 quotaAllocate(UID, QID, quotaUsage, serviceState)
This message is used by the PAS to both:
1. Allocate a quota to the PUP, and indicate the service that the PUP
should provide when the quota expires.
2. Deny allocation of a quota to the PUP.
This is the only means of allocating a quota to the PUP. It is only
sent in response to a quotaRequest.
Allocation is denied if the QID is NULL. In this case, the
serviceState is limited-service if the PUP should keep the data
session up (but provide access only to replenishment and other free
services), and no-service if the PUP should terminate the data
session.
The PUP does not reply to the quotaAllocate. If the quotaAllocate
is lost in transit, the PUP will generate another quotaRequest.
7.4 quotaReturnRequest(UID)
This message is used by the PAS to command the PUP to return its
current quota. It is used in two cases:
1. When another PUP has requested an allocation, this is used to
shrink the first PUPÆs quota.
2. When the PUP is on its "last quota" (i.e. the service state will
go to limited service or no service upon expiry), but the user has
replenished his account. The PAS uses this message in essence to
change the new service state back to full service. This message
has the side-effect of replacing the quota with a larger one.
Upon reception of this message, the PUP stays in full-service state,
and returns the quota and requests a new one with the quotaRequest
message.
7.5 serviceUpdate(UID, serviceState)
This message is used by the PAS to either:
1. Cause the PUP to request a new quota. This happens when the user
replenishes his account while in limited-service.
2. Cause the PUP to terminate the data session. This happens when
the user fails to replenish his account while in limited-service.
The PUP sends a sessionEnd message.
Note that this message and the quotaReturnRequest message could
easily be combined in the same message.
7.6 Example
This section demonstrates the use of the protocol semantics through
an example. The five messages are abbreviated as follows:
quotaRequest: qReq
Francis et. al. Informational [Page 19]
Prepaid Data Service Design Issues June 2002
sessionEnd: sEnd
quotaAllocate: qAll
quotaReturnRequest: qRet
serviceUpdate: sUpd
The serviceStates are abbreviated as full, limit, and none.
Quotas are measured in bytes, and are rated at $1 = 100Kbytes.
Quotas and usage are shown in units of Kbytes.
The bracketed number on the left {qqqq} shows the quota minus usage
for the PUP (in Kbytes). The bracketed number on the right {$rr}
shows the balance in the PADB (in dollars).
UE PUP PAS
|<----------->| |
|Initiate data| |{$20}
|session |-------------------------------->| a
| {0}| qReq(QID=NULL, use=NULL) |
| | Allocate $19
| | from balance
| |<--------------------------------|{$1} b
| {1900}| qAll(QID=22, use=1900, full) |
~~ | ~~~ ~~~
|
~~ V ~~~ ~~~
| {1500}| |
|<----------->| |
|End data | |{$20}
|session |-------------------------------->| c
| | sEnd(QID=22, use=400) |
| | Return $15
| | to balance
| |<--------------------------------|{$16}
| {0}| Ack |
a. The user (UE) initiates a data session, and the PUP requests
authorization and an initial quota with the quotaRequest message.
b. The user starts with a balance of $20. Assuming that the user has
no other consumers of the account, the PAS assigns as much as
possible to the PUP. In order to have an opportunity to replenish
the prepaid account before the balance depletes, however, the PAS
assigns $19=1900Kbytes. This will cause the PUP to report when
there is 100Kbytes left. Finally, the PAS instructs the PUP to
give the user full service after the quota is depleted because
there will still be some remaining balance. This is all conveyed
in the quotaAllocate message. Note that, had this message been
dropped by the network, the PUP would have retransmitted the
quotaRequest.
c. After the user has used 400Kbytes of data, he ends the data
session. The PUP reports this usage to the PAS in a sessionEnd
Francis et. al. Informational [Page 20]
Prepaid Data Service Design Issues June 2002
message. The PAS rates the usage at $4 and returns $15 to the
balance. The PAS acknowledges the PUP, which can then remove its
record of the quota/usage.
UE PUP PAS
|<----------->| |
|Initiate data| |{$16}
|session |-------------------------------->| d
| {0}| qReq(QID=NULL, use=NULL) | |
| | Allocate $15 |
| | from balance |
| |<--------------------------------|{$1} d
| {1500}| qAll(QID=33, use=1500, full) |
~~ | ~~~ ~~~
|
~~ V ~~~ ~~~
| {0}| |
| | |-------------------------------->| e
| | | qReq(QID=33, use=1500) |
| V | Allocate $1
| {-10}| from balance
| |<--------------------------------|{$0} f
| {90}| qAll(QID=44, use=100, limit) |
| /-------------------------------------------\ |
|/ Replenish Account \| g
|\ to $20 /|{$20}
| \-------------------------------------------/ |
| |<--------------------------------| h
| {40}| qRet() |
| |-------------------------------->| i
| {0}| qReq(QID=44, use=60) |
| | Return $0.40
| | to balance, allocate
| {-15}| $19.40 from balance
| |<--------------------------------|{$1} j
| {1925}| qAll(QID=55, use=1940, full) |
d. Sometime later, the user initiates another data session. Steps a
and b are repeated, but this time with an allocation of
$15=1500Kbytes, since there is a smaller balance.
e. Over time, the user uses 1500Kbytes. The PUP returns the quota
and requests another with the quotaRequest message. The PUP
continues to give the user full service.
f. The PAS allocates the remaining $1=100Kbytes from the balance and
allocates it to the PUP. This time, however, the serviceState is
set to limited-service, because after this quota expires the
balance will be gone.
g. At the same time, the PAS (or some replenishment app) communicates
with the user (using some application---chat, SMS, web, email,
etc.), and the user replenishes its account to $20.
h. At this point, the PUP is programmed to give limited service when
the quota expires. Since the user has replenished, however, this
Francis et. al. Informational [Page 21]
Prepaid Data Service Design Issues June 2002
is no longer appropriate. Therefore, the PAS sends a
quotaReturnRequest command, which causes the PUP to return the
quota but also to stay in full service mode.
i. During account replenishment, the user used an additional
50Kbytes. Therefore, when the PUP returns the quota, it reports a
usage of 60Kbytes. The PAS returns the unused 40Kbytes to the
balance (as $0.40), resulting in a total balance of $20.40.
j. The PAS then allocates all but $1 (i.e., $19.40=1940Kbytes) to the
PUP, similar to step b. Upon reception of the quotaAllocate
message, the user has used 15Kbytes, so this is subtracted from
the allocation of 1940Kbytes, resulting in 1925Kbytes.
UE PUP PAS
| {1925}| |{$1}
| | | Voice PUP requests
| | | an allocation
| V |<--------------------------------| k
| {1900}| qRet() |
| |-------------------------------->| l
| {0}| qReq(QID=55, use=40) |
| | Return $19 to balance
| | allocate $9 each to
| {-10}| voice and data
| |<--------------------------------|{$2}
| {890}| qAll(QID=66, use=900, full) |
~~ | ~~~ ~~~
|
~~ V ~~~ ~~~
| {700}| Voice PUP returns
| | | $5 to balance.
| | | |{$7} m
~~ | ~~~ ~~~
~~ V ~~~ ~~~
| {0}| |
| | |-------------------------------->| n
| | | qReq(QID=66, use=900) |
| V | Allocate $6
| {-10}| from balance
| |<--------------------------------|{$1}
| {590}| qAll(QID=77, use=600, full) |
k. Next, the voice PUP requests an allocation (for instance, because
the user starts a voice call). The PAS commands the voice PUP to
return the quota.
l. At this point, the (data) PUP has used an additional 25Kbytes, and
so reports a usage of 40Kbytes. The PAS returns the remaining $19
to the balance for a total of $20. The PAS allocates half each to
the voice PUP and the (data) PUP, minus $1 each to allow for a
replenishment warning.
Francis et. al. Informational [Page 22]
Prepaid Data Service Design Issues June 2002
m. The voice call ends, and the voice PUP returns $5 to the balance.
The PAS increases the balance to $7, but does not need to do
anything else.
n. Later, the (data) PUP quota expires and the PUP reports 900Kbytes
of usage. The PAS allocates $6=600Kbytes to the PUP.
UE PUP PAS
| {590}| |{$1}
~~ | ~~~ ~~~
|
~~ V ~~~ ~~~
| {0}| |
| | |-------------------------------->| o
| | | qReq(QID=77, use=600) | |
| V | Allocate $1 |
| {-10}| from balance |
| |<--------------------------------|{$0} |
| {90}| qAll(QID=88, use=100, limit) | |
| /-------------------------------------------\ | |
|/ User doesnÆt \| o
|\ replenish account /|
| \-------------------------------------------/ |
| {0}| |
| |-------------------------------->| p
| | qReq(QID=88, use=100) |
| /-------------------------------------------\ |
|/ User chooses not to \|
|\ replenish account /|
| \-------------------------------------------/ |
| |<--------------------------------| q
|<----------->| sUpd(none) |
|End data |-------------------------------->| r
|session | sEnd(QID=NULL, use=NULL) |
o. Later, the quota expires, the PUP reports, the PAS allocates the
remaining balance, and the replenishment application contacts the
user (similar to steps e,f,g). This time, however, the user does
not replenish the account.
p. The PUP quota expires and the PUP reports 100Kbytes of usage. The
PUP starts giving only limited service to the user.
q. The user still does not replenish the account, so the PAS sends a
serviceUpdate message to the PUP telling it to end service to the
user. (Alternatively, the PUP could simply have a timeout.)
r. The PUP terminates the data session, and reports this to the PAS
with the sessionEnd message. Since there is no quota at this
point, the QID is NULL.
8 Security Considerations
Francis et. al. Informational [Page 23]
Prepaid Data Service Design Issues June 2002
The security considerations for prepaid data are similar to those
for AAA accounting. As per the existing AAA model, this prepaid
architecture assumes a chain of trust extending between the PAS and
the PUP, possibly through one or more proxy AAA servers. All PASs,
PUPs, and proxy AAA servers are assumed to have pre-established
trust relationships, using authentication and privacy services
(IPsec) if necessary. Any messages received from such a trusted
system is therefore trusted. We further assume that such trusted
messages cannot be intercepted or observed by non-trusted systems.
As such, it is not necessary to establish pairwise security
associations between PUPs in visited networks and PASs in home
networks.
We assume that the AAA system has authenticated the user to the PUP.
Therefore it is not necessary for the PAS to separately authenticate
the user. For the sake of efficiency, however, the initial quota
may be piggybacked on the authentication.
There are no security requirements above and beyond those already
required by AAA accounting.
9 Acknowledgements
The authors wish to thank Vern Paxson for his comments on this memo.
10 References
[1] RFC 2058: "Remote Authentication Dial In User Service (RADIUS)."
C. Rigney, A. Rubens, W. Simpson, S. Willens. January 1997
[2] RFC 2059: "RADIUS Accounting". C. Rigney. January 1997.
[3] 3GPP TS 22.078, "Customized Applications for Mobile Network
Enhanced Logic (CAMEL)", Stage 1, Rel. 4, December 2001.
[4] 3GPP, www.3gpp.org
[5] 3GPP2, www.3gpp2.org
11 AuthorsÆ Addresses
Joel Brand
Tahoe Networks
3052 Orchard Dr.
San Jose, CA 95134
Phone: +1 408 944 8624
Email: jbrand@tahoenetworks.com
Francis et. al. Informational [Page 24]
Prepaid Data Service Design Issues June 2002
Paul Francis
Tahoe Networks
3052 Orchard Dr.
San Jose, CA 95134
Phone: +1 408 944 8632
Email: francis@tahoenetworks.com
Bryan Gleeson
Tahoe Networks
3052 Orchard Dr.
San Jose, CA 95134
Phone: +1 408 944 8224
Email: bryan@tahoenetworks.com
12 Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERPUPT SOCIETY AND THE INTERPUPT
ENGIPUPERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITPUPSS FOR A PARTICULAR PURPOSE.
Francis et. al. Informational [Page 25]
Prepaid Data Service Design Issues June 2002
13 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Francis et. al. Informational [Page 26]