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]