< draft-lior-radius-prepaid-extensions-11.txt   draft-lior-radius-prepaid-extensions-12.txt >
RADEXT A. Lior RADEXT A. Lior
Internet-Draft Bridgewater Systems Internet-Draft Bridgewater Systems
Expires: December 25, 2006 P. Yegani Intended status: Informational P. Yegani
Cisco Expires: December 31, 2007 Cisco
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
H. Tschofenig H. Tschofenig
Nokia Siemens Networks
A. Pashalidis A. Pashalidis
Siemens NEC
June 23, 2006 June 29, 2007
Prepaid extensions to Remote Authentication Dial-In User Service Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
draft-lior-radius-prepaid-extensions-11.txt draft-lior-radius-prepaid-extensions-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 25, 2006. This Internet-Draft will expire on December 31, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies an extension to the Remote Authentication This document specifies an extension to the Remote Authentication
Dial-In User Service (RADIUS) protocol that enables service providers Dial-In User Service (RADIUS) protocol that enables service providers
to charge for prepaid services. The supported charging models to charge for prepaid services. The supported charging models
supported are volume-based, duration-based, and based on one-time supported are volume-based, duration-based, and based on one-time
events. events.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7
1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 10 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 9
1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 12 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11
2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15 1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11
2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 15 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15 2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14
2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 17 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14
2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 17 2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16
2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18 2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17
2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 20 2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18
2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20 2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19
2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 20 2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19
2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19
2.7.2. Service Price Enquiry . . . . . . . . . . . . . . . . 20
2.7.3. Balance Check . . . . . . . . . . . . . . . . . . . . 20
2.7.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1. Authentication and Authorization Operation . . . . . . . . 22 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22
3.2. Session Start Operation . . . . . . . . . . . . . . . . . 24 3.2. Authentication and Authorization Operation . . . . . . . . 22
3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 23
3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24
3.4.1. Unsolicited Session Termination Operation . . . . . . 26 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 25
3.4.2. Unsolicited Change of Authorization Operation . . . . 27 3.5.1. Unsolicited Session Termination Operation . . . . . . 26
3.5. Termination Operation . . . . . . . . . . . . . . . . . . 27 3.5.2. Unsolicited Change of Authorization Operation . . . . 26
3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 26
3.7. Operation Considerations for Multiple Services . . . . . . 28 3.7. Operation Considerations for Multiple Services . . . . . . 27
3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 29 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 27
3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 27
3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 30 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 28
3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 28
3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 30 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 28
3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 29
3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 29
3.7.8. Accounting Considerations . . . . . . . . . . . . . . 31 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 30
3.7.9. Interoperability with Diameter Credit Control
Application . . . . . . . . . . . . . . . . . . . . . 31
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Session Termination Attribute . . . . . . . . . . . . . . 34
4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 35
4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 36
4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 36
4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 36
4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 36
4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 36
4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 37
4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 37
4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 37
4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 37
4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 38
4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 38
4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 39
4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 39
4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 39
4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 39
4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 39
4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 40
4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 40
4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 41
4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 42
4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 42
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 42
5. Translation between RADIUS prepaid and Diameter Credit
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1. Session Identification . . . . . . . . . . . . . . . . . . 45
5.2. Translation between RADIUS prepaid client and Diameter
Credit Control AAA infrastructure . . . . . . . . . . . . 45
5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 45
5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 46
5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 46
5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 46
5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 47
5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 47
5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 48
5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 48
5.2.9. Volume/Duration/Resource Threshold Attributes
(s->c) . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 48
5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 50
5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 50
5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 50
5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 50
5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 51
5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 51
5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 51
5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 51
5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 52
5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 52
6. Security Considerations . . . . . . . . . . . . . . . . . . . 53 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 4.2. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . . 56 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . . 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 57 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 45
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 60 8.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 46
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 64 8.2. New Registry: Prepaid SubTypes . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 8.3. New Registry: Update-Reason . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 72 8.4. New Registry: Termination-Action . . . . . . . . . . . . . 48
8.5. New Registry: Requested-Action . . . . . . . . . . . . . . 48
8.6. New Registry: Check-Balance-Result . . . . . . . . . . . . 49
8.7. New Registry: AvailableInClient-Extended . . . . . . . . . 49
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.1. Normative References . . . . . . . . . . . . . . . . . . . 51
10.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 52
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 52
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 54
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 58
A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 63
A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 64
A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Translation between RADIUS Prepaid and Diameter
Credit Control . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
Intellectual Property and Copyright Statements . . . . . . . . . . 77
1. Introduction 1. Introduction
This document specifies an extension to the RADIUS protocol that This document specifies an extension to the RADIUS protocol that
enables service providers to perform accounting and charging in an enables service providers to perform accounting and charging in an
"online" fashion. In particular, they enable the service provider to "online" fashion. In particular, they enable the service provider to
(a) ensure that subscriber's remaining funds suffice before the
service is delivered, and (b) interrupt service provision when the
funds are exhausted. Note that these capabilities are typically used
in scenarios where the subscriber maintains a prepaid account with
the service provider; hence, this extension is called the "prepaid"
extension for RADIUS. Also note that the above capabilities are not
provided by the base RADIUS protocol.
It has been observed that subscribers prefer prepaid accounts to (a) ensure that subscriber's remaining funds suffice before the
postpaid ones in many circumstances. Indeed, it is expected that service is delivered, and
offering a "prepaid mode of operation" will enabe service providers
to expand their existing customer bases. This is the main business (b) interrupt service provision when the funds are exhausted.
driver behind the extensions defined in this document. The
extensions were designed with the following goals in mind. Note that these capabilities are typically used in scenarios where
the subscriber maintains a prepaid account with the service provider;
hence, this extension is called the "prepaid" extension for RADIUS.
The functionality described in this document is often referred as
"online charging" in comparison to "offline charging" support
provided by RFC 2866 [RFC2866].
The extensions were designed with the following goals in mind:
o Make use of existing infrastructure as much as possible (including o Make use of existing infrastructure as much as possible (including
enabling the interworking of RADIUS-based and Diameter-based enabling the interworking of RADIUS-based and Diameter-based
infrastructures), and thereby limit the amount of necessary infrastructures), and thereby limit the amount of necessary
capital expenditures, capital expenditures,
o provide the ability to rate service requests in an "online" o provide the ability to rate service requests in an "online"
fashion, fashion,
o provide the ability to charge the user's account prior to service o provide the ability to charge the user's account prior to service
provision, provision,
o protect against revenue loss, i.e. to prevent an end user from o protect against revenue loss, i.e., to prevent an end user from
obtaining service when the available funds do not suffice, obtaining service when the available funds do not suffice,
o protect against fraud, and o protect against fraud, and
o be deployable over dialup, wired and wireless networks. o be deployable for a number of services independent of the access
network technology.
The architecture between the entities that execute the RADIUS The architecture between the entities that execute the RADIUS
protocols, with the extensions defined in this document, assumes that protocols, with the extensions defined in this document, assumes that
the rating of chargeable events does not occur in the element that the rating of chargeable events does not occur in the element that
provides the service. Instead, the rating may be performed at a provides the service. Instead, the rating may be performed at a
dedicated server, termed the "prepaid-enabled AAA server" or simply dedicated server, termed the "prepaid-enabled AAA server" or simply
"prepaid server". Alternatively, the actual rating may occur in an "prepaid server" (PPS). Alternatively, the actual rating may occur
entity behind this prepaid server. Furthermore, business logic may in an entity related to this prepaid server.
dictate a time-dependent tariff model, for example that the price for
a service may switch at 8pm from a high to a low tariff. The
extensions defined in this document support such scenarios.
Furthermore, this document assumes an architecture where a "quota Furthermore, this document assumes that a "quota server" is available
server" is available which, through co-ordination with the rating which, through co-ordination with the rating entity and an account
entity and a centralized account balance manager, is able to provide balance manager, is able to provide a quota indication for a
a quota indication for a particular user when requested. This quota particular user when requested. This quota server may or may not
server may or may not coexist in the prepaid server. coexist in the prepaid server.
1.1. Terminology 1.1. Terminology
o Network Access Server (NAS): As defined in RADIUS. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
o Prepaid client (PPC): The entity which triggers the RADIUS message Prepaid Client (PPC):
exchange, including the prepaid extensions defined in this
document. The PPC typically resides in the NAS.
o Prepaid Server (PPS): The entity that interacts with the PPC using The entity which triggers the RADIUS message exchange, including
the RADIUS prepaid extensions defined in this document. the prepaid extensions defined in this document. The PPC provides
the service to the users, and executes the RADIUS client which,
for the purposes of this document, is termed the "PrePaid Client"
(PPC). When the prepaid service is used the PPC collects service
event information and reports it while the services is provided to
the user. This event information is sent to the PPS using the
extensions defined in this document.
o Home Network: The network which contains the user profile and the Prepaid Server (PPS):
user's prepaid account.
o Authorize-Only Access Request: A RADIUS message of type "Access The entity that interacts with the PPC using the RADIUS prepaid
Request" (code field=1) that contains a "Service-Type" AVP extensions defined in this document.
(type=6) with value "Authorize-Only".
Rating Entity:
This entity converts the credit that is allocated by the PPS into
a "quota". This quota is then returned to the requesting PPC via
the PPS. The rating entity may also determine that during service
provision a tariff switch will occur. In this case the rating
entity will include details of when exactly tariff switch will
occur.
Quota:
A quota denotes the amount of granted units to be consumed without
performing another credit control interaction.
Home Network:
The network which contains the user profile and the user's prepaid
account.
Authorize-Only Access Request:
A RADIUS message of type "Access Request" (code field = 1) that
contains a "Service-Type" AVP (type = 6) with value "Authorize-
Only".
Offline Charging:
Offline charging is a process where charging information for
resource usage is collected concurrently with that resource usage.
The charging information is then passed through a chain of logical
charging functions. At the end of this process, Charging Data
Record (CDR) files are generated, which are then transferred to
the operator's billing domain for the purpose of subscriber
billing and/or inter-operator accounting (or additional functions,
e.g., statistics, at the operator's discretion). The billing
domain typically comprises post-processing systems, such as the
operator's billing system or billing mediation device. In
conclusion, offline charging is a mechanism where charging
information does not affect, in real-time, the service rendered.
[TS32240]
Online Charging:
Online charging is a process where charging information for
resource usage is collected concurrently with that resource usage
in the same fashion as in offline charging. However,
authorization for the network resource usage must be obtained
prior to the actual resource usage to occur. This authorization
is granted by the PPS upon request from the PPC. When receiving a
resource usage request, the PPS assembles the relevant charging
information and generates a charging event in real-time. The PPS
then returns an appropriate resource usage authorization. The
resource usage authorization may be limited in its scope (e.g.,
volume of data or duration), therefore the authorization may have
to be renewed from time to time as long as the resource usage
persists. Note that the charging information utilized in online
charging is not necessarily identical to the charging information
employed in offline charging. In conclusion, online charging is a
mechanism where charging information can affect, in real-time, the
service rendered and therefore a direct interaction of the
charging mechanism with the control of resource usage is required.
[TS32240]
1.2. Overview 1.2. Overview
This section provides an overview of the prepaid charging models and This section provides an overview of the prepaid charging models and
architectures, which are supported by the extensions described in architectures, which are supported by the extensions described in
this document. this document.
A number of models of how to charge customers for data services in a A number of models of how to charge customers for services in a
prepaid manner are supported, as follows. prepaid manner are supported:
o Volume-based charging (e.g. 2 Cents/KiloByte). o Volume-based charging (e.g., 2 Cents/KiloByte).
o Duration-based charging (e.g. 3 Cents/minute). o Duration-based charging (e.g., 3 Cents/minute).
o Subscription-based charging (e.g. 10 Dollars/month). o Resource-based charging (e.g., 3 videos for 10 Euros)
o Event-based charging (e.g. 7 Cents/URL or email) . o Event-based charging (e.g., 7 Cents/ring tone) .
This draft assumes that the user maintains a prepaid account with his This draft assumes that the user maintains a prepaid account with his
home network. This account may be used to fund multiple services, home network. This account may be used to fund multiple services,
some of which may use the extensions defined in this document, and some of which may use the extensions defined in this document, and
some may use other mechanisms. The interworking of these mechanisms some may use other mechanisms. The interworking of these mechanisms
is outside the scope of this document. Similarly, the means by which is outside the scope of this document. Similarly, the means by which
the subscriber obtains funds is also outside the scope of this the subscriber obtains funds is also outside the scope of this
document. document.
1.2.1. Architectural Model 1.2.1. Architectural Model
The protocol extensions described in this draft assumes that the This section describes the architectural model of the protocol
following entities are present in the network architecture. extensions described in this document. Figure 1 describes the
involved entities.
o Service Access Device (SAD): This entity provides a data service
to the users, and typically coincides with the NAS. The SAD
executes the RADIUS client which, for the purposes of this
document, is termed the "PrePaid Client" (PPC). When the prepaid
service is used the SAD collects service event information and
reports it while services are provided to the user. This event
information is sent to the PPS using the extensions defined in
this document.
o The PPS: The RADUIS server that supports the prepaid extensions The end user establishes a connection with one of possibly multiple
defined in this document. If real-time credit control is PPCs during service access. The selected PPC communicates with a
required, the PPC (SAD) contacts the PPS with service event HAAA server (directly or indirectly via a broker network).
information included before the service is provided. The PPS
performs a credit check and allocates a portion of the available
credit to the service event.
o The rating entity: This entity converts the credit that is The interface between the HAAA and the PPS is implemented using the
allocated by the PPS into a time or volume amount, called the RADIUS protocol together with the extensions described in this
"quota". This quota is then returned to the requesting PPC (SAD) document. However, in cases where the PPS does not implement the
(via the PPS). The rating entity may also determine that during RADIUS protocol, the implementation would have to map the
service provision a tariff switch will occur. In this case the requirements defined in this document to a functionally equivalent
rating entity will include details of when exactly tariff switch protocol.
will occur.
The requesting PPC (SAD) meters the consumption of the service The requesting PPC meters the consumption of the service according to
according to the instructions provided by the PPS. After service the instructions provided by the PPS. After service completion, or
completion, or on reception of a subsequent request for service, the on reception of a subsequent request for service, the PPS deducts the
PPS deducts the corresponding amount of credit from the user account. corresponding amount of credit from the user account. When a user
When a user terminates an on-going service, the PPC informs the PPS terminates an on-going service, the PPC informs the PPS with a
with a suitable indication about the unused portion of the allocated suitable indication about the unused portion of the allocated quota.
quota. The PPS then refunds the user account accordingly. Note that The PPS then refunds the user account accordingly. Note that
multiple PPSs may be deployed for reasons of redundancy and load multiple PPSs may be deployed for reasons of redundancy and load
sharing. The system MAY also employ multiple rating servers. sharing. The system may also employ multiple rating servers.
accounting Service AAA and
+------------+ +-----------+ protocol +--------------+ Element Prepaid
| User |<---------->| Service | | | +----------+ +---------+ Protocol +----------+
| | IEEE 802.1x| Access |<------------>| Accounting | | End |<---->|+-------+|<------------>| Home AAA |
| Device | PANA | Device |<-----+ | Server | | User | +->|| PCC || | Server |
+------------+ IKEv2 +-----------+ | +--------------+ | | | || Client||<----+ | (HAAA) |
... etc (PPC) | +----------+ | |+-------+| | +----------+
| | +---------+ | Prepaid ^
| +--------------+ +----------+ | | Protocol|
+------>| Prepaid | | End |<--+ | v
prepaid | Server | | User | | +----------+
protocol +--------------+ +----------+ +------->| |
Prepapid | PPS |
Protocol | |
+----------+
Figure 1: Basic prepaid architecture Figure 1: Basic Prepaid Architecture
The PPS and the accounting server in this architecture MAY be The PPS and the accounting server in this architecture may be
combined. The SAD must have the ability to meter the consumption of combined. The PPC must have the ability to meter the consumption of
a prepaid data session. This metering is typically based on time a prepaid data session. This metering is typically based on time
(i.e. seconds) or volume (i.e. octets). (i.e., seconds) or volume (i.e., octets).
The device running the PPC may also have "Dynamic Session The device running the PPC may also have "Dynamic Session
Capabilities" such as the ability to terminate a data session or Capabilities", such as the ability to terminate a data session or to
change the filters associated with a specific data session by change the filters associated with a specific data session by
processing "Disconnect" messages and "Change of Authorization" processing "Disconnect" messages and "Change of Authorization"
messages as per RFC 3576. messages as per RFC 3576 [RFC3576].
This document assumes that the PPS is used as the AAA server. There This document assumes that the PPS is used as the AAA server. There
are three types of AAA server, as follows. are three types of AAA server, as follows.
o The AAA server in the home network (HAAA), which is responsible The AAA server in the home network (HAAA) is responsible for
for authentication of the subscriber. In addition, the HAAA authentication of the subscriber. In addition, the HAAA communicates
communicates with the PPS using the RADIUS protocol in order to with the PPS using the RADIUS protocol in order to authorize
authorize subscribers. subscribers.
o The AAA server in the visited network (VAAA) which exists only in
roaming scenarios and is responsible for forwarding the RADIUS
messages to the HAAA. The VAAA may also modify the messages.
Note that, in certain roaming deployments, the visited network may
be connected to the home network via one or more broker networks.
o The AAA server in one of the aforementioned broker networks
(BAAA), which is responsible for forwarding messages and does not
play an active role in the prepaid data service delivery. A BAAA
obviously exists only in those roaming deployments where the VAAA
and the HAAA are connected via the BAAA of a broker network.
This document assumes that the PPS communicates with the HAAA for the This document assumes that the PPS communicates with the HAAA for the
purposes of authentication and authorisation. The PPS, in turn, purposes of authentication and authorisation. The PPS, in turn,
interfaces to entities which interfaces to entities which
o keep the subscriber's account balance (balance manager), o keep the subscriber's account balance (balance manager),
o rate access service requests in real-time (Rating Engine), and o rate access service requests in real-time (rating engine), and
o manage quota for a particular prepaid service (Quota Server).
The above entities belong to the service provider's backend
infrastructure and are outside the scope of this specification. In
particular, as far as this specification is concerned, they are
assumed to exist in the PPS. Three deployment scenarios are
presented in the remainder of this section. The first scenario is
depicted in Figure 2. In this scenario, the SAD, which runs the PPC,
the HAAA, and the PPS are located in the same provider network.
The subscriber's device establishes a connection with one of possibly
multiple SADs in the network. The selected SAD communicates with a
HAAA server (directly or indirectly).
The interface between the HAAA and the PPS is implemented using the
RADIUS protocol together with the extensions described in this
document. However, in cases where the PPS does not implement the
RADIUS protocol, the implementation would have to map the
requirements defined in this document to a functionally equivalent
protocol.
+------+ +-----+
| | | |
+--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | |
| Subscr.| | Service| | +------+ | +-----+
| |---| Access |--+ |
| Device | | Device | | +------+ | +-----+
| | | | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS |
| | | |
+------+ +-----+
Figure 2: Basic prepaid access architecture
The second scenario, depicted in Figure 3, is based on a static
roaming architecture that is typical of a wholesale scenario for
Dial-Up users or a broker scenario used in Dial-Up or WLAN roaming
scenarios.
+----+ +----+ +----+ +-----+
| | | | | | | |
+------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | |
|Sub | |Service| | +----+ | +----+ | +----+ | +-----+
| |--|Access |-+ | | |
|Device| |Device | | +----+ | +----+ | +----+ | +-----+
| | | | | | | | | | | | | | | |
+------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | |
+----+ +----+ +----+ +-----+
Figure 3: Static roaming prepaid architecture
Like in the basic prepaid architecture, the subscriber device o manage quota for a particular prepaid service (quota server).
establishes a connection with the SAD. The SAD communicates with the
VAAA using the RADIUS protocol. The VAAA, in turn, communicates
using the RADIUS protocol with BAAA servers in the broker network.
There may be more than one Broker Network between the Visited Network
and the Home Network. The Home Network is the same as in the
architecture depicted in Figure 2.
Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) The balance manager, the rating engine and the quota server belong to
attribute as defined in RFC 2869. If they are used, they forward the the service provider's backend infrastructure and are outside the
RADIUS packets as usual to the appropriate RADIUS servers. scope of this specification. In particular, as far as this
specification is concerned, they are assumed to exist in the PPS.
Accounting messages are not needed to deliver a prepaid service. Accounting messages are not needed to deliver a prepaid service.
However, accounting messages can be used to keep the PPS up to date However, accounting messages can be used to keep the PPS up-to-date
as to what is happening with the prepaid data session. Therefore, a as to what is happening with the prepaid data session.
BAAA SHOULD deliver RADIUS Accounting messages using the pass through
mode described in RFC 2866.
1.2.2. Motivation 1.2.2. Motivation
Why not use existing RADIUS attributes to construct a protocol for Why not use existing RADIUS attributes to construct a protocol for
prepaid scenarios? This could lead to a solution where no code has prepaid scenarios? This could lead to a solution where no code has
to be modified at existing devices. to be modified at existing devices.
It is indeed possible to construct a solution for prepaid scenarios It is indeed possible to construct a solution for prepaid scenarios
using existing RADIUS attributes. The RADIUS server would send an using existing RADIUS attributes. The RADIUS server would send an
Access-Accept message containing a Session-Timeout(27) and include a Access-Accept message containing a Session-Timeout(27) and include a
skipping to change at page 11, line 32 skipping to change at page 10, line 17
Access-Request messages, which are required to flow through any Access-Request messages, which are required to flow through any
network in real-time. network in real-time.
o Session-Timeout(27) is not a mandatory attribute. If a prepaid o Session-Timeout(27) is not a mandatory attribute. If a prepaid
subscriber is served by a NAS that does not adhere to Session- subscriber is served by a NAS that does not adhere to Session-
Timeout then that subscriber may use the service for an Timeout then that subscriber may use the service for an
undetermined period of time. undetermined period of time.
o Termination-Action(29) presents its own issues. Firstly, the o Termination-Action(29) presents its own issues. Firstly, the
behaviour of Termination-Action(29) is not mandatory. Secondly, behaviour of Termination-Action(29) is not mandatory. Secondly,
according to RFC 2865, Termination-Action fires when the provision according to RFC 2865 [RFC2865], Termination-Action fires when the
of the service has completed. However, service should not be provision of the service has completed. However, service should
terminated when negotiating additional quota, because this should not be terminated when negotiating additional quota, because this
happen in a manner transparent to the subscriber. Due to the fact should happen in a manner transparent to the subscriber. Due to
that Termination-Action occurs when the service is completed, it the fact that Termination-Action occurs when the service is
is unclear whether or not user experience would be affected if completed, it is unclear whether or not user experience would be
this attribute would be used in a prepaid scenario. The RADIUS affected if this attribute would be used in a prepaid scenario.
server might even allocate a new IP address to the subscriber The RADIUS server might even allocate a new IP address to the
device after a Termination-Action. Also, the RADIUS server has no subscriber device after a Termination-Action. Also, the RADIUS
way of telling why a given Access-Request message was generated. server has no way of telling why a given Access-Request message
The RADIUS server might have to wait for the corresponding was generated. The RADIUS server might have to wait for the
accounting packet to determine the reason. Finally, re- corresponding accounting packet to determine the reason. Finally,
authenticating the subscriber may take too long. The solution re-authenticating the subscriber may take too long. The solution
presented in this document allows quota replenishing to occur presented in this document allows quota replenishing to occur
without affecting user experience. No re-authentication is without affecting user experience. No re-authentication is
required and quotas can be negotiated before the available credit required and quotas can be negotiated before the available credit
actually runs out. actually runs out.
o Due to the fact that the standard RADIUS attributes are not o Due to the fact that the standard RADIUS attributes are not
mandatory, the correct prepaid operation is really an act of faith mandatory, the correct prepaid operation is really an act of faith
on the part of the RADIUS server. If Session-Timeout(27) and/or on the part of the RADIUS server. If Session-Timeout(27) and/or
Termination-Action(29) are not supported, the prepaid subscriber Termination-Action(29) are not supported, the prepaid subscriber
might be able to obtain the service for free. The solution might be able to obtain the service for free. The solution
described in this document requires that a prepaid-aware SAD described in this document requires that a PPC informs the RADIUS
informs the RADIUS server, regardless of whether or not the latter server, regardless of whether or not the latter supports the
supports the prepaid extensions. The RADIUS server can then prepaid extensions. The RADIUS server can then determine whether
determine whether or not service should be granted. For example, or not service should be granted. For example, if a prepaid
if a prepaid subscriber is connected to a NAS that does not subscriber is connected to a NAS that does not support prepaid,
support prepaid, the RADIUS server can either instruct the NAS to the RADIUS server can either instruct the NAS to tunnel the
tunnel the traffic to another entity in the home network (e.g. an traffic to another entity in the home network (e.g., an Home
Home Agent) that supports prepaid, or cause it to provide only a Agent) that supports prepaid, or cause it to provide only a
restricted service. restricted service.
The solution presented in this document requires the support of two The solution presented in this document requires the support of two
mandatory and one optional attribute. Furthermore, it does not mandatory and one optional attribute. Furthermore, it does not
require a great amount of additional code at a NAS that already require a great amount of additional code at a NAS (or similar
supports time or volume metering. The solution requires that RADIUS device) that already supports time or volume-based metering. The
entities advertise their prepaid capabilities in an Access-Request solution requires that RADIUS entities advertise their prepaid
and that they generate an Access-Request packet with Service- capabilities in an Access-Request and that they generate an Access-
Type="Authorize-Only" in order to obtain more quota when or before Request packet with Service-Type="Authorize-Only" in order to obtain
the current quota is used up. It also requires the NAS to send an more quota when or before the current quota is used up. It also
Access-Request with Service-Type="Authorize-Only" when the session requires the NAS to send an Access-Request with Service-
terminates in order to refund the subscriber account. Type="Authorize-Only" when the session terminates in order to refund
the subscriber account.
1.3. A simple use case 1.3. Assumptions
This section describes the sequence of events in a simple RADIUS This document makes the following assumptions.
o The values carried in the Service Identifiers are pre-configured
between the PPC and the PPS.
o The decision about the service rating happens at the PPS.
o The decision whether credit control requests for two services are
placed in a resource pool are made by the PPS.
o The decision which services belong to the same rating group are
pre-configured at the PPC. Once a rating group is authorized it
is not necessary to re-authorize an additional service that
belongs to the same rating group at the PPS again.
o A price enquiry is done purely for the purpose of providing AoC
for the end user, not for processing at the PPC nor to trigger any
specific actions.
1.4. Example Use Case
This section describes the sequence of events in an example RADIUS
prepaid transaction. prepaid transaction.
1. When an end host attaches to a network (for example, using PPP or 1. When an end host attaches to a network (for example, using IEEE
PANA), as usual, the NAS (SAD) that is servicing the subscriber 802.1X), as usual, the PPC that is servicing the subscriber uses
uses the AAA infrastructure in order to authenticate and the AAA infrastructure in order to authenticate and authorize the
authorize the subscriber with respect to the requested service. subscriber with respect to the requested service. In order to do
In order to do this, it sends a RADIUS Access-Request to the AAA this, it sends a RADIUS Access-Request to the AAA server. This
server. This Access-Request contains the subscriber's Access-Request contains the subscriber's credentials and may
credentials and may contain the prepaid capabilities of the SAD. contain the prepaid capabilities of the PPC.
Prepaid capabilities MUST be included if the SAD supports them.
2. The authentication procedure proceeds. This may involve several 2. The authentication procedure proceeds. This may involve several
message exchanges such as in EAP [RFC2284]. Once the subscriber message exchanges, as it is the case with the Extensible
has been successfully authenticated, the home AAA server Authentication Protocol (EAP) [RFC2284]. Once the subscriber has
determines that the subscriber is a prepaid subscriber and been successfully authenticated, the home AAA server determines
requests authorisation from the PPS. This request MUST include that the subscriber is a prepaid subscriber and requests
the prepaid capabilities of the serving SAD. authorisation from the PPS. This request MUST include the
prepaid capabilities of the serving PPC.
3. The PPS, possibly with the help of the backend infrastructure, 3. The PPS, possibly with the help of the backend infrastructure,
validates that the subscriber has a prepaid account and that the validates that the subscriber has a prepaid account and that the
account is active. It further validates that the SAD has the account is active. It further validates that the PPC has the
appropriate prepaid capabilities. If all is in order, the PPS appropriate prepaid capabilities. If all is in order, the PPS
authorises the subscriber to use the network. Otherwise it authorises the subscriber to use the network. Otherwise it
rejects the request. The decision is sent to the AAA system in rejects the request. The decision is sent to the AAA system in
the form of a response message. In the case of success, this the form of a response message. In the case of success, this
message contains attributes that indicate the allocation of a message contains attributes that indicate the allocation of a
portion of the subscriber credit. This portion is called the portion of the subscriber credit. This portion is called the
"initial quota" and is expressed in units of time or volume. The "initial quota" and is expressed in units of time or volume. The
response may also include a threshold value. Note that only a response may also include a threshold value. Note that only a
portion of the user's funds is allocated because the user may be portion of the user's funds is allocated because the user may be
engaged in other services that may draw on the same account. For engaged in other services that may draw on the same account. For
example, the user may be engaged in a data session and a voice example, the user may be engaged in a data session and a voice
session. Although these two services would draw from the same session. Although these two services would draw from the same
account, they form separate parts of the overall system. If the account, they form separate parts of the overall system. If the
entire quota was allocated to the data session then the user entire quota was allocated to the data session then the user
would have no more funds for a voice session. would have no more funds for a voice session.
4. The AAA system incorporates the attributes received from the PPS 4. The AAA system incorporates the attributes received from the PPS
into an Access-Accept message that it sends to the SAD. Note into an Access-Accept message that it sends to the PPC. Note
that the AAA system is responsible for authorizing the service that the AAA system is responsible for authorizing the service
whereas the prepaid system is responsible for prepaid whereas the prepaid system is responsible for prepaid
authorization. authorization.
5. Upon receiving the Access-Response, the SAD starts the prepaid 5. Upon receiving the Access-Response, the PPC starts the prepaid
data session and meters the session based on time or volume, as data session and meters the session based on time or volume, as
indicated in the message. indicated in the message.
6. Once the consumption approaches the allocated limit (as expressed 6. Once the consumption approaches the allocated limit (as expressed
by the threshold), the SAD will request additional quota. Re- by the threshold), the PPC will request additional quota. Re-
authorization for additional quota flows through the AAA system authorization for additional quota flows through the AAA system
to the PPS. The PPS revalidates the subscriber account and to the PPS. The PPS revalidates the subscriber account and
subtracts the previously allocated quota from the current subtracts the previously allocated quota from the current
balance. If there is remaining balance, it reauthorizes the balance. If there is remaining balance, it reauthorizes the
request with an additional quota allotment. Otherwise, the PPS request with an additional quota allotment. Otherwise, the PPS
rejects the request. Note that the replenishment of the quota is rejects the request. Note that the replenishment of the quota is
a re-authorization procedure and does not require the subscriber a re-authorization procedure and does not require the subscriber
to authenticate himself again. to authenticate himself again.
7. Upon receiving a re-allotment of the quota, the SAD continues to 7. Upon receiving a re-allotment of the quota, the PPC continues to
provide the data service until the new threshold is reached. If provide the requested service until the new threshold is reached.
the request for additional quota cannot be fulfilled then the SAD If the request for additional quota cannot be fulfilled then the
lets the subscriber use the remaining quota and terminates the PPC lets the subscriber use the remaining quota and terminates
session. Alternatively, instead of terminating the session, the the session. Alternatively, instead of terminating the session,
SAD may restrict the data session such that the subscriber can the PPC may restrict service access in such a way that the
only reach a particular web server. This web server maybe used subscriber can only reach a particular web server. This web
to allow the subscriber to replenish his account. This server maybe used to allow the subscriber to replenish his
restriction can also be used to allow new subscribers to set up account. This restriction can also be used to allow new
prepaid accounts in the first place. subscribers to set up prepaid accounts in the first place.
8. Should the subscriber terminate the session before the quota is 8. Should the subscriber terminate the session before the quota is
exhausted, the remaining balance allotted to the session MUST be exhausted, the remaining balance allotted to the session is
refunded into his account. refunded into his account.
Note that the subscriber may have disconnected while the Access Note that the subscriber may have disconnected while the PPC is
Device is waiting for the initial quota. The entire allocated quota waiting for the initial quota. The entire allocated quota will have
will have to be credited back to the subscribers account in this to be credited back to the subscribers account in this case. Also
case. Also note that the PPS maintains session state for the note that the PPS maintains session state for the subscriber. This
subscriber. This state includes how much account balance was state includes how much account balance was allocated during the last
allocated during the last quota enquiry and how much is left in the quota enquiry and how much is left in the account. Therefore, it is
account. Therefore, it is required that all messages about the required that all messages about the session reach the same (and
session reach the same (and correct) PPS. correct) PPS.
For a simple message flow, along the lines of this use case, please For a simple message flow, along the lines of this use case, please
see Appendix A. see Appendix A.
2. Supported Features 2. Supported Features
This section describes the features that are supported by the This section describes the features that are supported by the
extensions specified in this document. extensions specified in this document.
2.1. Multiple Concurrent Services 2.1. Services and Quotas
Examples of services that the user may be using are browsing the web, Examples of services that the user may be using are browsing the web,
participating in a VoIP conversation, watching streaming video and participating in a VoIP conversation, watching streaming video and
downloading a file. Some operators may want to distinguish between downloading a ring tone. Some operators may want to distinguish
these services. Some services are charged at different rates and between these services and to charge them at different rates and
services may be metered differently. Therefore, the prepaid solution meters them differently. Therefore, the prepaid solution needs to be
needs to be able to distinguish services, and allocate quota to the able to distinguish services, and allocate quota to the services
services using different unit types (time, volume) and allow for using different unit types (time, volume) and allow for those quotas
those quotas to be consumed at different rates. to be consumed at different rates.
+---------+ +---------+ +---------+ +-------+
| Session | | | N 1 | | M 1 | |
+---------+ | Session |<---------->| Service |<---------->| Quota |
| 1 | | | | | |
V N +---------+ +---------+ +-------+
+--------------+ 1 : 1 +-------+
| Service |------>| Quota |
| (service-Id) | +-------+
+--------------+
Figure 4: Multiple services within a single session Figure 2: Multiple services within a single session
As shown in Figure 4, a session may be associated with multiple (N) As shown in Figure 2, a session may be associated with multiple
services. Each service is identified by a service identifier services. Each service is identified by a service identifier
(Service-ID). The format of the Service-ID is not in the scope of (Service-ID). The format of the Service-ID is not in the scope of
this document but it could be expressed as an IP flow using the this document. It may, for example, be expressed as a 5-tuple {i.e.,
5-tuple {Source-IP and Port, Destination-IP and Port, protocol type}. source IP address, destination IP address, source port, destination
Each service is associated with a quota metric. An example message port, and protocol type}. Each service is associated with a quota
flow that involves multiple such services within a single session is whereby a quota might be applicable to multiple services. An example
given in the appendix. message flow that involves multiple services within a single session
is given in the Appendix A.
2.2. Resource Pools 2.2. Resource Pools
When working with multiple services a new problem arises because one When working with multiple services a new problem arises because one
service may consume its quota faster than another service. When the service may consume its quota faster than another service. When the
user balance is close to exhaustion, a situation could arise where user balance is close to exhaustion, a situation could arise where
one service is unable to obtain quota while another service has one service is unable to obtain quota while another service has
plenty of quota remaining. Unless the quotas can be rebalanced, the plenty of quota remaining. Unless the quotas can be rebalanced, the
SAD would then have to terminate the former service. Moreover, if PPC would then have to terminate the former service. Moreover, each
each service generates a certain amount of RADIUS prepaid traffic. service generates a certain amount of RADIUS prepaid traffic. In an
In an environment with many users and chargarble services, this environment with many users and many chargeable services, this amount
amount of traffic is considerable and could cause undesirable network of traffic may be considerable.
congestion.
One method to circumvent the above situation is to use a so-called To avoid a situation where several parallel (and typically also
"resource pool". Resource pools enable the allocation of resources small) credit reservations must be made on the same account, and also
to multiple services of a session by allocating resources to a pool to avoid unnecessary load on the prepaid server, it is possible to
and have services draw their quota from the pool at a rate provide service units as a "resource pool". Resource pools enable
appropriate to that service. When the quota that has been allocated the allocation of resources to multiple services of a session by
to the pool is close to exhaustion, the entire pool (rather than allocating resources to a pool and have services draw their quota
individual services) is replenished. from the pool at a rate appropriate to that service. When the quota
that has been allocated to the pool is close to exhaustion, the
entire pool (rather than individual services) is replenished.
+-----------+ The reference includes a multiplier derived from the rating
| Service-A |-----+ +--------+ parameter, which translates from service units of a specific type to
+-----------+ | Ma | | the abstract service units in the pool.
+-------->| |
| Pool |
+-------->| (1) |
+-----------+ | Mb | |
| Service-B |-----+ +--------+
+-----------+
Figure 5: Resource pool example Figure 3 shows the concept of resource pools graphically.
As shown in Figure 5, Service-A and Service-B are bound to Pool(1). +---------+ +---------+ +----------+
Ma and Mb are the pool multipliers (that are associated with | | N 1 | | M 1 | |
Service-A and Service-B respectively) that determine the rate at | Service |<---------->| Quota |<---------->| Resource |
which Service-A and Service-B draw from the pool. | | | | | Pool |
+---------+ +---------+ | |
+----------+
The pool is initialized by taking the quota allocated to service n Figure 3: Resource Pools
and multiplying it by Mn. Therefore, the amount of resources
allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where
Qn denotes the amount of quota that is allocated to service n.
Further, the pool is considered to be empty if
Poolr <= Ca*Ma + Cb*Mb + . . ., If S is the total service units within the pool, M1, M2, ..., Mn are
the multipliers provided for services 1, 2, ..., n, and C1, C2, ...,
Cn are the used resources within the session, then the pool credit is
exhausted and re-authorization MUST be sought when:
Figure 6 C1*M1 + C2*M2 + ... + Cn*Mn >= S
where Ca and Cb are resources consumed by Service-A and Service-B The total credit in the pool, S, is calculated from the quotas, which
respectively. are currently allocated to the pool as follows:
Note that the resources assigned to the pool are not associated with S = Q1*M1 + Q2*M2 + ... + Qn*Mn
a metric. That is, Service-A can be rated at $1 per MB and Service-B
can rated at $0.10 per minute. In this case if $5 worth of resources For example, if the rating parameter for service 1 is $1/MB and the
are allocated for service-A to the pool and if Ma = 10, then 50 units rating parameter for service 2 is $0.1/min, the multipliers could be
10 and 1 for services 1 and 2, respectively.
That is, service 1 can be rated at $1 per MB and service 2 can rated
at $0.10 per minute. In this case if $5 worth of resources are
allocated for service 1 to the pool and if Ma = 10, then 50 units
would be placed into the pool. If a further $5 are allocated for would be placed into the pool. If a further $5 are allocated for
service-B to the pool, then M=1 and 50 units are deposited into the service 2 to the pool, then Mb=1 and 50 units are deposited into the
pool. The pool would then have a sum of 100 units to be shared pool. The pool would then have a sum of 100 units to be shared
between the two services. The PPC would then meter the services such between the two services. The PPC would then meter the services such
that each Mbyte used by Service-A will draw 10 units from the pool that each Mbyte used by service 1 will draw 10 units from the pool
and each minute used by Service-B will draw 1 unit from the pool. and each minute used by service 2 will draw 1 unit from the pool.
2.3. Complex Rating Functions 2.3. Rating Groups
A Rating Group gathers a set of services, identified by a service
identifier, and subject to the same cost and rating type (e.g., $0.1/
minute).
The rating of a service can be quite complex. While some operators The rating of a service can be quite complex. While some operators
follow linear pricing models, others may wish to apply more complex follow linear pricing models, others may wish to apply more complex
functions. For example, a service provider may wish to rate a functions. For example, a service provider may wish to rate a
service such that the first N MBytes are free, then the next M Mbytes service such that the first N MBytes are free, then the next M Mbytes
are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50
per MB. Such a function could be implemented by repeated message per MB. Such a function could be implemented by repeated message
exchanges in the prepaid system. exchanges in the prepaid system.
To avert the need to exchange many messages while still supporting To avert the need to exchange many messages while still supporting
such complex rating functions, the notion of a "Rating Group" is such complex rating functions, the concept of the Rating Group was
introduced. A Rating Group are typically configured at the SAD. As introduced.
shown in Figure 7, a Rating Group is associated with one or more
As shown in Figure 6, a Rating Group is associated with one or more
services and defines the rate that the services associated with the services and defines the rate that the services associated with the
Rating Group consume an allocated amount of quota. Rating Group consume an allocated amount of quota.
+--------------+ +--------------+ +---------+ +---------+ +----------+
+-----------+ N 1 | | M 1 | Resource Pool| | | N 1 | | M 1 +-------+ P 1 | |
| Service-A +---------->| Rating Group |------>| or | | Service |<----->| Rating |<----->| Quota |<----->| Resource |
+-----------+ | | | Quota | | | | Group | +-------+ | Pool |
+--------------+ +--------------+ +---------+ | | | |
+---------+ +----------+
Figure 7: Example of a rating group Figure 6: Rating Group
During the usage of a service that is associated with a Rating Group, During the usage of a service that is associated with a Rating Group,
the PPC sends the ID of the Rating Group to the PPS. The PPS the PPC sends the ID of the Rating Group to the PPS. The PPS
authorises the Rating Group by allocating a quota to it and authorises the Rating Group by allocating a quota to it and assign it
optionally assigning it to a Resource Pool. When an additional to a Resource Pool. When an additional service that belongs to an
service that belongs to an already authorised Rating Group is already authorised Rating Group is instantiated, the PPC does not
instantiated, the PPC does not need to authorize this service. This need to re-authorize this service. This effectively means that the
effectively means that the PPC meters the service such that it draws PPC meters the service such that it draws from the already allocated
from the already allocated quota. Therefore, no RADIUS messages need quota. Therefore, no RADIUS messages need to be exchanged in this
to be exchanged in this case. This limits the amount of traffic case. This limits the amount of traffic between the PPC and the PPS.
between the PPC and the PPS. An example of a flow that uses Rating An example of a flow that uses Rating Groups is given in Appendix A.3
Groups is given in Appendix A.3
2.4. One-time Charging
One-time charging is a mode of operation of where the RADIUS prepaid
extensions are used for charging of a service that is provided
instansteneously, i.e. without an ongoing session. An example of
such an event is the purchase of a ring-tone. Subscription based
services can also be modeled as a one-time event. In this case the
one-time service event is the purchase of a subscription.
For a given user, one-time charging may occur in parallel with other
charging models. For example, the subscriber may access a website
which is metered (based on time or volume) while he also purchases
the right to use a ring tone (a one-time-based event). Note: it is
up to the service providers to decide whether or not the user will be
charged for the download of the tone and also be charged for the time
and volume required to download the ring-tone. The facilities
provided by this document gives the service provider the capability
to achieve their service charging business goals. For example,
should the service provider choose not to charge for the download
volume or time, then they can treat the download IP flow as a
separate service that is not subject to charging.
The SAD signals one-time charging to the PPS with an indication that
identifies the service and the units that should be debited from the
user account.
A SAD may decide to perform one-time charging for an event that was
triggered by an unauthenticated user. In this case case the SAD will
have to authenticate the user before sending the relevant message to
the user's home AAA server.
Note that one-time charging can also be used to credit the prepaid 2.4. Tariff Switching
account. For example, the SAD can return resources to the subscriber
by issuing a one-time charge request that includes the amount of
resources to be credited into the account.
2.5. Tariff Switching Tariff is the set of parameters defining the utilization charges for
the use of a particular service.
The PPC and the PPS may support tariff switching mechanism described This mechanism is useful if, for example, as shown in Figure 7,
in this section. This mechanism is useful if, for example, as shown traffic before 18:00 is rated at rate r1 and traffic after 18:00 is
in Figure 8, traffic before 18:00 is rated at rate r1 and traffic rated at rate r2. The mechanism requires the PPC to report usage
after 18:00 is rated at rate r2. The mechanism requires the PPC to before and after the switch occured.
report usage before and after the switch occured.
18:00 18:00
------------------+----------------- ------------------+-----------------
r1 | r2 r1 | r2
------------------+----------------- ------------------+-----------------
^ ^ ^ ^
|<----TSI---> | |<----TSI---> |
| | | |
Access-Accept Access-Request Access-Accept Access-Request
(quota allocated) (quota consumed) (quota allocated) (quota consumed)
Figure 8: Example of tariff switching Figure 7: Example of Tariff Switching
The PPC it indicates support for tariff switching by setting the The PPC indicates support for tariff switching by setting the
appropriate bit in the PPAC. If the PPS needs to signal a tariff appropriate bit in the PPAC. If the PPS needs to signal a tariff
switch time it will send a PTS attribute which indicates the point in switch time it will send a PTS attribute that indicates the point in
time when the switch will occur. This indication represents the time when the switch will occur. This indication represents the
number of seconds from current time (TariffSwitchInterval TSI). number of seconds from current time (TariffSwitchInterval TSI).
At some point after the tariff switch the PPC sends another Access- At some point after the tariff switch the PPC sends another Access-
Request, as a result of either the user having logged off or the Request, as a result of either the user having logged off or the
volume threshold being reached. The PPC reports how much volume was volume threshold being reached. The PPC reports how much volume was
used in total (in a PPAQ attribute) and how much volume was used used in total (in a PPAQ attribute) and how much volume was used
after the tariff switch (in a PTS VUATS subtype attribute). after the tariff switch (in a PTS VUATS subtype attribute).
In situations with multiple tariff switches, the PPS must specify the In situations with multiple tariff switches, the PPS has to specify
length of the tariff switch period using the the length of the tariff switch period using the
TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS
shown below. attribute, as shown in Figure 8.
18:00 23:30 18:00 23:30
------------------+---------------------+-------------- ------------------+---------------------+--------------
r1 | r2 | r3 r1 | r2 | r3
------------------+---------------------+-------------- ------------------+---------------------+--------------
^ ^ ^ ^ ^ ^
|<----TSI---><-----------|-------->|TITSU |<----TSI---><-----------|-------->|TITSU
| | | |
Access-Accept Access-Request Access-Accept Access-Request
Figure 9: Multiple tariff switches Figure 8: Multiple Tariff Switches
When a TITSU is specified in the PTS, the PPC MUST generate an When a TITSU is specified in the PTS, the PPC MUST generate an
Access-Request within the time after TSI and before TITSU expires. Access-Request within the time after TSI and before TITSU expires.
Note that, typically, the PPC will be triggered by the Volume Note that, typically, the PPC will be triggered by the Volume
Threshold. However, it is possible that, during period r2, resources Threshold. However, it is possible that, during period r2, resources
are not entirely consumed and, thus, the threshold is not reached. are not entirely consumed and, thus, the threshold is not reached.
The TITSU attribute ensures that, even in this case, the PPC will The TITSU attribute ensures that, even in this case, the PPC will
generate the new Access-Request in good time. generate the new Access-Request in good time.
Note that it makes no sense to use the tariff switching mechanism For time based services, the quota is continuously consumed at the
described in this section for services that are metered based on time regular rate of 60 seconds per minute. At the time when credit
and the consumption of which is continuous (i.e. without resources are allocated, the server already knows how many units will
interruption). Also note that separate services flows may have be consumed before the tariff time change and how many units will be
individual tariff periods. consumed afterward. Similarly, the server can determine the units
consumed at the before rate and the units consumed at the rate
afterward in the event that the end user closes the session before
the consumption of the allotted quota. There is no need for
additional traffic between the PPC and the PPS in the case of tariff
time changes for continuous time based service. Therefore, the
tariff change mechanism is not used for such services. For time-
based services in which the quota is not continuously consumed at a
regular rate, the tariff change mechanism described for volume and
event units may be used.
2.6. Support for Roaming 2.5. Support for Roaming
In certain networks it is essential for prepaid data services to be In certain networks it is essential for prepaid data services to be
available to roaming subscribers. Support for both static and available to roaming subscribers. Support for both static and
dynamic roaming models is needed. In a static roaming scenario the dynamic roaming models is needed. In a static roaming scenario the
subscriber connects to a foreign network which has a roaming subscriber connects to a foreign network which has a roaming
agreement either directly with the home network, or through a broker agreement either directly with the home network, or through a broker
network. When the subscriber logs into another foreign network, a network. When the subscriber logs into another foreign network, a
new login procedure has to be executed. new login procedure has to be executed.
In a dynamic roaming scenario the subscriber may move between In a dynamic roaming scenario the subscriber may move between
networks while maintaining his connection. In such a scenario the networks while maintaining his connection. In such a scenario the
data session is seamlessly handed off between the networks. data session is seamlessly handed off between the networks.
In both roaming scenarios, the subscriber always authenticates In both roaming scenarios, the subscriber always authenticates
himself to the home network. Authorization for the prepaid session himself to the home network. Authorization for the prepaid session
and quota replenishing occurs at the home network and more and quota replenishing occurs at the home network and more
specifically at the PPS where state is being maintained. specifically at the PPS where state is being maintained.
Dynamic roaming is challenging because a subscriber who established a Roaming is challenging because a subscriber who established a prepaid
prepaid data session may move to another Access Device that does not data session may move to another PPC that does not support the
support the prepaid extensions. Even in this case the system should prepaid extensions.
be able to continue the prepaid session.
2.7. Dynamic Termination 2.6. Dynamic Termination
When fraud or an error is detected, either only the affected session, When fraud or an error is detected, either only the affected session,
or all sessions of the affected subscriber should be immediately or all sessions of the affected subscriber should be immediately
terminated. It may further happen that the prepaid system enters a terminated. Under certain conditions, the system may wish to
state where it is unclear whether or not the data session is in terminate the session in order to make sure that the user is not
progress. Under certain conditions, the system may wish to terminate charged for services it does not use.
the session in order to make sure that the user is not charged for
this potential inactivity.
Certain handoff procedures used in dynamic roaming scenarios require Certain handoff procedures used in dynamic roaming scenarios require
that the system terminates the subscribers prepaid data session at a that the system terminates the subscribers prepaid data session at a
SAD. This is the case, for example, when time-based prepaid is used PPC. This is the case, for example, when time-based prepaid is used
and the mobile subscriber performs a dormant handoff. and the mobile subscriber performs a dormant handoff.
2.8. Querying and Rebalancing 2.7. One Time Event
It should be possible for the PPS to Query the current resource 2.7.1. One-Time Charging
consumption at a SAD and adjust the user account balance. For
example, a request to the PPS is made (e.g. a one-time charging
event), the account is depleted and resources have been allocated to
the SAD. The PPS should have the ability to query the SAD and if it
has the spare resources to reassign the quotas to the SAD and to the
pending request. Note that the PPS does not know resource usage
until the SAD request for more resources. This can be a long time.
In the absence of this capability the PPS can minimize the effect of One-time charging is a mode of operation of where the RADIUS prepaid
this phenomenon by allocating small quotas, a practice that results extensions are used for charging of a service that is provided
in more message exchanges. instansteneously. An example of such an event is the purchase of a
ring tone. Subscription based services can also be modeled as a one-
time event. In this case the one-time service event is the purchase
of a subscription.
3. Operations For a given user, one-time charging may occur in parallel with other
charging models. For example, the subscriber may be connected to the
Internet, which is metered (based on time or volume), while he also
purchases a ring tone (a one-time-based event).
This section describes the operations that are implemented by a Note that it is up to the service providers to decide whether or not
prepaid-enabled NAS (SAD). the user will be charged for the download of, for example, the video
and also be charged for the data volume required to download the
video. The facilities provided by this document gives the service
provider the capability to achieve their service charging business
goals.
3.1. Authentication and Authorization Operation The PPC signals one-time charging to the PPS with an indication that
identifies the service and the units that should be debited from the
user account.
The SAD initiates the authentication and authorization procedure by A PPC may decide to perform one-time charging and the PPC may need to
sending a RADIUS Access-Request to the HAAA. Since the SAD has PPC authenticate the user before sending the relevant message to the
capabilities, it MUST include a PPAC attribute in the RADIUS Access- user's home AAA server (and to the PPS).
Request. The PPAC attribute indicates to the PPS which prepaid
capabilities are possessed by the SAD. These are required in order
to complete the prepaid authorization procedure. Moreover, if the
SAD supports the Disconnect-Message or the Change-of-Authorization
capabilities, then it SHOULD include the Dynamic-Capabilities
attribute.
In certain deployments, there may be other ways to terminate a data Note that one-time charging can also be used to credit the prepaid
session, or change authorization of an active session. For example, account. For example, the PPC can return resources to the subscriber
some SADs provide a session termination service via Telnet or SNMP. by issuing a one-time charging request that includes the amount of
In these cases, the AAA server MAY add the Dynamic-Capabilities resources to be credited into the account.
message to the Access-Request. Upon receiving the Change-of-
Authorization message, the AAA server would then be responsible for 2.7.2. Service Price Enquiry
terminating the session using the means that are supported by the
device. The PPC may need to know the price of the service event. Services
offered by application service providers whose prices are not known
in the PPC might exist. The end user might also want to get an
estimation of the price of a service event before requesting it.
A PPC issues a PPAQ to the PPS including the Requested-Action SubType
with the value set to "Price Enquiry" (2). The request includes
enough information to identify the service, namely a Service-
Identifier or a Rating-Group-Identifer.
The PPS calculates the cost of the requested service event, but it
does not perform any account balance check or credit reservation from
the account.
The estimated cost of the requested service event is returned to the
PPS with a PPAQ in the Cost-Information SubType. The PPC may
transfer the information to the end user as an advice of charge.
More information regarding the price enquiry functionality is
provided in Section 4.2.17 and in Section 4.2.19.
2.7.3. Balance Check
The PPC may only have to verify that the end user's account balance
covers the cost of a certain service without reserving any units from
the account at the time of the inquiry. This method does not
guarantee that credit would be left when the PPC requests the
debiting of the account with a separate request.
A PPC issues a PPAQ to the PPS including the Requested-Action SubType
with the value set to "Balance Check" (1). The request includes
enough information to identify the service, namely a Service-
Identifier or a Rating-Group-Identifer.
The PPS makes the balance check, but it does not make any credit-
reservation from the account.
The result of balance check, namely "Success" (1) or "Failure" (2),
is returned to the PPC in the Check-Balance-Result SubType conveyed
in the PPAQ attribute from the PPS to the PPC.
More information regarding the balance check functionality is
provided in Section 4.2.17 and in Section 4.2.18.
2.7.4. Refund
Some services may refund service units to the end user's account; for
example, gaming services.
To initiate refunding the PPC includes the PPAQ attribute in an
Access-Request packet and the amount (as a negative value) to be
refunded is specified using the Resource Quota and Resource Quota
overflow subtypes. This functionality is similar to one-time
charging with the difference that refunding uses negative values
Information about the service need to be provided by the PPC to allow
service identification, namely the Service-ID field of the PPAQ
identifies the prepaid service.
Note that a monetary amount itself to be refunded is not provided but
rather abstract units. Based on prior out-of-band agreements between
the PPC and the PPS these abstract units are translated into a
monetary amount.
More information regarding the refund functionality is provided in
Section 3.7.6.
3. Operations
This section contains the normative text for the prepaid extension.
3.1. Capability Discovery
The PPC initiates the authentication and authorization procedure by
sending a RADIUS Access-Request to the HAAA. Since the PPC MUST
include a PPAC attribute in the RADIUS Access-Request. The PPAC
attribute indicates to the PPS which prepaid capabilities are
possessed by the PPC. These are required in order to complete the
prepaid authorization procedure.
If the authentication procedure involves multiple message exchanges If the authentication procedure involves multiple message exchanges
(as in EAP), the SAD MUST include the PPAC(TBD) attribute and the (as it is the case with EAP), the PPC MUST include the PPAC attribute
Dynamic-Capabilities attribute (if used) in at least the last Access- in at least the last Access-Request of the authentication procedure.
Request of the authentication procedure.
The Access-Request is sent, as usual, to the HAAA, possibly through 3.2. Authentication and Authorization Operation
one or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA authenticates Once the Access-Request arrives at the HAAA, the HAAA authenticates
the subscriber. If this fails, the HAAA sends an Access-Reject the subscriber. If this fails, the HAAA sends an Access-Reject
message to the client. If authentication succeeds, the HAAA message to the client. If authentication succeeds, the HAAA
determines whether or not the subscriber is a prepaid subscriber. determines whether or not the subscriber is a prepaid subscriber. If
(How this is done is beyond the scope of this document.) If the the subscriber is not a prepaid subscriber, then the HAAA responds as
subscriber is not a prepaid subscriber, then the HAAA responds as
usual with an Access-Accept or an Access-Reject message. If the usual with an Access-Accept or an Access-Reject message. If the
subscriber is a prepaid subscriber then the HAAA SHALL forward the subscriber is a prepaid subscriber then the HAAA MAY forward the
Access-Request to the PPS for further authorization. Access-Request to the PPS for further authorization.
The Access-Request contains the PPAC(TBD) attribute and the Dynamic-
Capabilities attribute if one was included. The User-Name(1)
attribute MAY be set to a value that identifies the subscriber. This
attribute is used by the PPS to locate his account. For added
security, the HAAA MAY also set the User-Password(2) attribute to the
password used between the HAAA and the PPS.
The PPS locates the subscriber account and authorizes him. During The PPS locates the subscriber account and authorizes him. During
this procedure, the PPS takes into consideration the SAD PPC this procedure, the PPS takes into consideration the PPCs
Capabilities. Upon successful authorization, the PPS generates an capabilities. Upon successful authorization, the PPS generates an
Access-Accept containing an PPAC attribute and an PPAQ attribute. Access-Accept containing an PPAC attribute and an PPAQ attribute.
The PPAC attribute returned to the client indicates the type of The PPAC attribute returned to the client indicates the type of
prepaid service to be provided for the session. The PPAQ attribute prepaid service to be provided for the session. The PPAQ attribute
includes the following information. includes the following information.
o The QUOTA-ID, which is set by the PPS to a unique value that is o The QID, which is set by the PPS to a unique value, is used to
used to correlate subsequent quota requests. correlate quota requests.
o Volume and/or Time quota, which is set to a value representing a o Volume and/or Time quota, which is set to a value representing a
portion of the subscriber's credit. portion of the subscriber's credit.
o It MAY contain a Time or Volume Threshold that indicates when the o Time or Volume Threshold that indicates when the PPC should
SAD should request additional quota. request additional quota. This information is optional.
o The IP address of the Serving PPS and one or more alternative o The IP address of the serving PPS and one or more alternative
PPSs. This is used by the HAAA to route subsequent quota PPSs. This is used by the HAAA to route subsequent quota
replenishing messages to the appropriate PPS(s). replenishing messages to the appropriate PPS(s).
o A State attribute, as defined in RFC 2865. This is necessary in o A State attribute, as defined in RFC 2865 [RFC2865]. This is
order to satisfy the requirements of section 5.44 of RFC 2865, necessary in order to satisfy the requirements of Section 5.44 of
which mandates that an Access-Request with Service- RFC 2865 [RFC2865], which mandates that an Access-Request with
Type="Authorize-Only" must contain a State attribute. Since the Service-Type="Authorize-Only" must contain a State attribute.
SAD sends subsequent quota replenishment requests in the form of Since the PPC sends subsequent quota replenishment requests in the
such "Authorize-Only" requests, a State attribute MUST be present form of such "Authorize-Only" requests, a State attribute MUST be
in all Access-Accept messages that also carry a PPAQ attribute. present in all Access-Accept messages that also carry a PPAQ
attribute.
Note: The Idle-Timeout(28) attribute can be used to trigger the Note: The Idle-Timeout(28) attribute can be used to trigger the
premature termination of a prepaid service, for example as a result premature termination of a prepaid service, for example as a result
of inactivity. of inactivity.
Depending on site policies, after failed authorization, the PPS may Depending on site policies, after failed authorization, the PPS may
generate an Access-Reject in order to terminate the session generate an Access-Reject in order to terminate the session
immediately. Alternatively, the PPS may generate an Access-Accept immediately. Alternatively, the PPS may generate an Access-Accept
blocking some or all of the traffic and/or redirect some or all of blocking some or all of the traffic and/or redirect some or all of
the traffic to a location to a fixed server. (This feature could be the traffic to a location to a fixed server. (This feature could be
used, for example, to prompt the user to replenish their account.) used, for example, to prompt the user to replenish their account.)
Blocking of traffic is achieved by either Filter-ID(11) or NAS- Blocking of traffic is achieved by either Filter-ID(11) or NAS-
Filter-Rule(see Redirect I-d). Redirection is achieved by sending Filter-Rule (see [I-D.ietf-radext-filter-rules]). A description of
Redirect-Id or Redirect-Rule, HTTP Redirection defined in the the redirect functionality is outside the scope of this document.
Redirect I-d. The time period before the session is blocked/ The time period before the session is blocked/redirected is specified
redirected is specified by the Session-Timeout(27) attribute. by the Session-Timeout(27) attribute.
Upon receiving an Access-Accept from the PPS, the HAAA appends the Upon receiving an Access-Accept from the PPS, the HAAA appends the
usual service attributes and forward the packet to the SAD. The HAAA usual service attributes and forward the packet to the PPC. The HAAA
SHOULD NOT overwrite any attributes already set by the PPS. If the SHOULD NOT overwrite any attributes already set by the PPS. If the
HAAA receives an Access-Reject message, it will simply forward the HAAA receives an Access-Reject message, it will simply forward the
packet to its client. Depending on site policies, if the HAAA does packet to its client. Depending on site policies, if the HAAA does
not receive an Access-Accept or an Access-Reject message from the PPS not receive an Access-Accept or an Access-Reject message from the PPS
it MAY do nothing or send an Access-Reject or an Access- Accept it MAY do nothing or send an Access-Reject or an Access- Accept
message back to the PPC. message back to the PPC.
3.2. Session Start Operation 3.3. Session Start Operation
The start of the session is indicated by the arrival of an The start of the session is indicated by the arrival of an
Accounting-Request(Start) packet. The Accounting-Request (Start) MAY Accounting-Request(Start) packet. The Accounting-Request (Start) MAY
be routed to the PPS such that it can confirm the initial quota be routed to the PPS such that it can confirm the initial quota
allocation. allocation.
Note that the role of the PPS is not to record accounting messages Note that the role of the PPS is not to record accounting messages
and therefore it SHOULD NOT respond with an Accounting Response and therefore it SHOULD NOT respond with an Accounting Response
packet. If the PPS does not receive the Accounting-Request(start) packet. If the PPS does not receive the Accounting-Request(start)
message it will only know that the session has started upon the first message it will only know that the session has started upon the first
reception of a quota replenishment operation. reception of a quota replenishment operation.
If the PPS does not receive indication directly (via Accounting- If the PPS does not receive indication directly (via Accounting-
Request(start)) or indirectly, it SHOULD, after some configurable Request(start)) or indirectly, it SHOULD, after some configurable
time, deduce that the Session has not started. If the SAD supports time, deduce that the session has not started. If the PPC supports
termination capabilities, the PPS SHOULD send a Disconnect Message to termination capabilities, the PPS SHOULD send a Disconnect Message to
the SAD as a measure to ensure that the session is indeed dead. the PPC as a measure to ensure that the session is indeed dead.
3.3. Mid-Session Operation 3.4. Mid-Session Operation
During the lifetime of a prepaid data session the SAD may request the During the lifetime of a prepaid data session the PPC may request the
replenishment of the quotas using an Authorize-Only Access-Request replenishment of the quotas using an Authorize-Only Access-Request
message. Once either the allocated quota has been exhausted or the message. Once either the allocated quota has been exhausted or the
threshold has been reached, the SAD MUST send an Access-Request with threshold has been reached, the PPC MUST send an Access-Request with
Service-Type(6) set to a value of "Authorize-Only" and the PPAQ Service-Type(6) set to a value of "Authorize-Only" and the PPAQ
attribute. attribute.
The SAD MUST also include NAS identifiers, and Session identifier The PPC MUST also include NAS identifiers, and Session Identifier
attributes in the Authorize-Only Access-Request. The Session attributes in the Authorize-Only Access-Request. The Session
Identifier should be the same as the one used during the initial Identifier should be the same as the one used during the initial
Access-Request. For example, if the User-Name(1) attribute was used Access-Request. For example, if the User-Name(1) attribute was used
in the Access-Request it MUST be included in the Authorize-Only in the Access-Request it has to be included in the Authorize-Only
Access-Request, especially if the User-Name(1) attribute is used to Access-Request as well, especially if the User-Name(1) attribute is
route the Access-Request to the Home AAA server. used to route the Access-Request to the Home AAA server.
The Authorize-Only Access-Request MUST NOT include a User Password The Authorize-Only Access-Request MUST NOT include a User Password
and MUST NOT include a Chap Password. In order to enable the and MUST NOT include a CHAP Password. In order to enable the
receiver to authenticate the message, the SAD MUST include a Message- receiver to authenticate the message, the PPC MUST include a Message-
Authenticator(80). In order to satisfy the requirements of section Authenticator(80). In order to satisfy the requirements of Section
5.44 of RFC 2865, the SAD MUST also include the State attribute. It 5.44 of RFC 2865 [RFC2865], the PPC MUST also include the State
is anticipated that the inclusion of the State attribute will enable attribute. It is anticipated that the inclusion of the State
the PPS to map the Authorize-Only Access Request to the attribute will enable the PPS to map the Authorize-Only Access
authentication context that was established when the PPC Request to the authentication context that was established when the
authenticated itself at the beginning of the session. The SAD PPC authenticated itself at the beginning of the session. The PPC
computes the value for the Message-Authenticator and the State computes the value for the Message-Authenticator and the State
attributes according to RFC 2869 and 2865 respectively. attributes according to RFC 2869 [RFC2869] and RFC 2865 [RFC2865]
respectively.
When the HAAA receives an Authorize-Only Access-Request that contains When the HAAA receives an Authorize-Only Access-Request that contains
a PPAQ(TBD), it SHALL validate the message using the Message- a PPAQ, it validates the message using the Message-Authenticator(80),
Authenticator(80), according to RFC 2869. If the HAAA receives an according to RFC 2869. If the HAAA receives an Authorize-Only
Authorize-Only Access-Request that contains a PPAQ(TBD) and either no Access-Request that contains a PPAQ and either no or an invalid
or an invalid Message-Authenticator(80) it SHALL silently discard the Message-Authenticator(80) it SHALL silently discard the message. An
message. An Authorize Only Access-Request message that does not Authorize Only Access-Request message that does not contain a PPAQ is
contain a PPAQ(TBD) is either erroneous or belongs to another either erroneous or belongs to another application (for example, a
application (for example, a Change of Authorization message Change of Authorization message [RFC3576]). In this case the
[RFC3576]). In this case the Authorize-Only Access-Request is either Authorize-Only Access-Request is either silently discarded or handled
silently discarded or handled by another application. by another application.
Once the Authorize-Only Access-Request message is validated, the HAAA Once the Authorize-Only Access-Request message is validated, the HAAA
SHALL forward the Authorize-Only Access-Request to the appropriate SHALL forward the Authorize-Only Access-Request to the appropriate
PPS. The HAAA MUST forward the Authorize-Only Access-Request to the PPS. The HAAA MUST forward the Authorize-Only Access-Request to the
PPS specified in the PPAQ(TBD). The HAAA MUST add a Message- PPS specified in the PPAQ. The HAAA MUST add a Message-
Authenticator(80) to the message, according to RFC 2869. As with the Authenticator(80) to the message, according to RFC 2869. As with the
Access-Request message, the HAAA MAY modify the User-Name(1) Access-Request message, the HAAA MAY modify the User-Name(1)
attribute such that it identifies the user to the PPS. Note that the attribute such that it identifies the user to the PPS.
PPS may also use the Quota-ID sub-attribute contained within the
PPAQ(TBD) to locate the user account.
Upon receiving the Authorize-Only Access-Request containing a When the PPS receives the Authorize-Only Access-Request containing a
PPAQ(TBD) attribute, the PPS MUST validate the Message- PPAQ attribute, it MUST validate the Message-Authenticator(80) as
Authenticator(80) as described in RFC 2869. If validation fails, the described in RFC 2869. If validation fails, the PPS MUST silently
PPS MUST silently discard the message. If it receives an Authorize- discard the message. If it receives an Authorize-Only Access-Request
Only Access-Request message that does not contain a PPAQ(TBD), it message that does not contain a PPAQ, it MUST silently discard the
MUST silently discard the message. message.
The PPS locates the prepaid session state using the Quota Id The PPS locates the prepaid session state and uses the QID contained
contained within the PPAQ(TBD). The PPS takes the most recently within the PPAQ to detect replays. The PPS takes the most recently
allocated quota and subtracts it from the user balance. If allocated quota and subtracts it from the user balance. If
sufficient balance remains, the PPS authorizes the PPS and allocates sufficient balance remains, the PPS authorizes the PPS and allocates
additional quota. The PPS may also calculate a new threshold value. additional quota. The PPS may also calculate a new threshold value.
Upon successful re-authorization, the PPS generates an Access-Accept Upon successful re-authorization, the PPS generates an Access-Accept
containing the PPAQ(TBD) attribute. The Access-Accept message MAY containing the PPAQ attribute.
contain Servicetype(6) set to Authorize-Only and MAY contain the
Message-Authenticator(80).
Depending on site policies, upon unsuccessful authorization, the PPS Depending on site policies, upon unsuccessful authorization, the PPS
generates an Access-Reject or an Access-Accept with Filter-Id(11) or generates an Access-Reject or an Access-Accept with Filter-Id(11) or
Ascend-Data-Filter (if supported) attribute and the Session- Ascend-Data-Filter attribute (if supported) and the Session-
Timeout(27) attribute such that the subscriber can get access to a Timeout(27) attribute such that the subscriber can get access to a
restricted set of locations for a short period of time. This feature restricted set of locations for a short period of time. This feature
could be used to enable users to replenish their accounts, create new could be used to enable users to replenish their accounts, create new
accounts, or to browse free content. accounts, or to access free content.
Upon receiving the Access-Accept from the PPS, the HAAA SHALL return Upon receiving an Access-Accept from the PPS, the HAAA forwards the
the packet to its client. If the HAAA receives an Access-Reject message to its client. If the HAAA receives an Access-Reject
message, it forwards the packet. Depending on site policies, if the message, it forwards the message. Depending on site policies, if the
HAAA does not receive an Access-Accept or an Access-Reject message HAAA does not receive an Access-Accept or an Access-Reject message
from the PPS it MAY do nothing or it MAY send an Access-Reject from the PPS it MAY do nothing or it MAY send an Access-Reject
message back to its client. message back to its client.
Upon receiving an Access-Accept, the SAD SHALL update its quotas and Upon receiving an Access-Accept, the PPC updates its quotas and
threshold parameters with the values contained in the PPAQ(TBD) threshold parameters with the values contained in the PPAQ attribute.
attribute. Note that the PPS MAY update the PrePaidServer Note that the PPS MAY update the PrePaidServer attribute(s) and these
attribute(s) and these may have to be saved as well. If the Access- may have to be saved as well. If the Access-Accept message contains
Accept message contains a Filter-Id(11), an Ascend-Data-Filter a Filter-Id(11), an Ascend-Data-Filter attribute, or Session
attribute, or Session Timeout(27), the SAD SHALL restrict the Timeout(27), the PPC SHALL restrict the subscriber session
subscriber session accordingly. accordingly.
3.4. Dynamic Operations 3.5. Dynamic Operations
The PPS may take advantage of the dynamic capabilities that are The PPS may take advantage of the dynamic capabilities that are
supported by the SAD as advertised in the Dynamic-Capabilities supported by the PPC as advertised in the Dynamic-Capabilities
attribute during the initial Access-Request. There are two types of attribute during the initial Access-Request. There are two types of
action that the PPS may perform. Firstly, it may request the session actions that the PPS may perform. Firstly, it may request the
to be terminated. Secondly, it may request the attributes associated session to be terminated. Secondly, it may request the attributes
with the session to be modified. More specifically, it may modify a associated with the session to be modified. More specifically, it
previously sent PPAQ(TBD). may modify a previously sent PPAQ.
Both of these actions require that the session be uniquely identified Both of these actions require that the session be uniquely identified
at the SAD. As a minimum, the PPS MUST provide at the PPC as described in [RFC3576].
1. either the NAS-IP-Address(4) or the NAS-Identifier(32), and
2. at least one session identifier such as User-Name(1), Framed-IP-
Address(), the Accounting-Session-Id(44).
Other attributes could also be used to uniquely identify a prepaid
data session.
3.4.1. Unsolicited Session Termination Operation 3.5.1. Unsolicited Session Termination Operation
At anytime during a session the PPS may send a Disconnect Message in At anytime during a session the PPS may send a Disconnect Message in
order to terminate a session. This capability is described in detail order to terminate a session, see in [RFC3576]. Upon successful
in [RFC3576]. The PPS sends a Disconnect Message that MUST contain termination of a session the PPC MUST return any unused quota to the
identifiers that uniquely identify the data session and the SAD
servicing that session.
If the SAD receives a Disconnect-Message, it responds with either a
Disconnect-ACK message (if it is able to terminate the session) or
with a Disconnect-NAK packet (otherwise). Upon successful
termination of a session the SAD MUST return any unused quota to the
PPS by issuing an Authorize-Only Access-Request containing the PPAQ PPS by issuing an Authorize-Only Access-Request containing the PPAQ
which contains any unused Quota and the Update-Reason set to "Remote which contains any unused quota and the Update-Reason set to "Remote
Forced Disconnection". Forced Disconnection".
3.4.2. Unsolicited Change of Authorization Operation 3.5.2. Unsolicited Change of Authorization Operation
At any time during the session the PPC may receive a Change of At any time during the session the PPC may receive a Change of
Authorization (CoA) message. A PPS may send a new Quota to either Authorization (CoA) message. A PPS may send a new quota to either
add or to remove quota that is allocated to the service. If the add or to remove quota that is allocated to the service. If the
Change of Authorization contains a PPAQ then that PPAQ overrides a Change of Authorization contains a PPAQ then that PPAQ overrides a
previously received PPAQ. The PPS MUST NOT change the units used in previously received PPAQ. The PPS MUST NOT change the units used in
the PPAQ. the PPAQ.
If the newly received PPAQ reduces the amount of allocated quota If the newly received PPAQ reduces the amount of allocated quota
beyond what is already used then the SAD accepts the new PPAQ and act beyond what is already used then the PPC accepts the new PPAQ and act
as it normally would when the quota is used up. For example, if the as it normally would when the quota is used up. For example, if the
threshold is reached then is request a quota update . threshold is reached then is request a quota update.
3.5. Termination Operation 3.6. Termination Operation
The termination phase is initiated when (i) the subscriber logs off, The termination phase is initiated when (i) the subscriber logs off,
(ii) the subscriber balance is exhausted, or (iii) when the SAD (ii) the subscriber balance is exhausted, or (iii) when the PPC
receives a Disconnect Message. receives a Disconnect Message.
In case the user logged off, or the SAD receives a Disconnect In case the user logged off, or the PPC receives a Disconnect
Message, the SAD sends an Authorize-Only Access-Request message with Message, the PPC sends an Authorize-Only Access-Request message with
a PPAQ and Update-Reason attribute set to either "Client Service a PPAQ and Update-Reason attribute set to either "Client Service
Termination" or "Remote Forced Disconnect". This message indicates Termination" or "Remote Forced Disconnect". This message indicates
the amount of consumed quota. the amount of consumed quota.
In case the currently allocated quota is exhausted, if the PPAQ In case the currently allocated quota is exhausted, if the PPAQ
contained the Termination-Action field, the SAD follows the specified contained the Termination-Action subytype, the PPC follows the
action (which would be to immediately terminate the service, request specified action.
more quota, or redirect/filter the service).
3.6. Mobile IP Operations
In roaming scenarios with Mobile-IP, the prepaid data session should
be maintained transparently if the HA is acting as the SAD. As the
subscriber device associates with a new SAD (AP or PDSN that supports
PPC capability), the SAD sends a RADIUS Access-Request and the
subscriber is re-authenticated and reauthorized. The SAD MUST
include the PPAC(TBD) attribute in the RADIUS Access-Request. In
this manner, the procedure follows the Authentication and
Authorization procedure described earlier.
If the HA was acting as the SAD before handoff, the prepaid session
does not undergo any change after the handoff because the Mobile IP
session is anchored at the HA and the user's Home IP address does not
change.
In the case of a wireless access point or PDSN acting as the SAD, it
is likely that the user's (care-of) IP address will change. The
prepaid session will be affected by this. In this scenario the SAD
shall send an Access-Request message which is routed to the home
network and MUST reach the PPS that is serving this session. The PPS
correlates the new authorization request with the existing active
session and assigns a quota to the new request. Any outstanding
quota at the old SAD MUST be returned to the PPS if the Mobile-IP
nodes (HA and FA) support registration revocation (Mobile IPv4 only).
Specifically, the quota SHOULD be returned when the SAD sends the
Authorize-Only Access-Request with PPAQ(TBD) Update-Reason set to
either "Remote Forced Disconnect" or "Client Service Termination".
In order to trigger the sending of this last Authorize-Only Access-
Request, the PPS may issue a Disconnect Message [3576] to the SAD.
Even if the subscriber moves to a SAD that does not have prepaid
capabilities can the prepaid data service continue. This can be done
by requesting the Home Agent (assuming it has such capabilities) to
take over the responsibilities of the SAD (i.e. metering). This
scenario will be discussed in detail in a later version of this
document.
3.7. Operation Considerations for Multiple Services 3.7. Operation Considerations for Multiple Services
This section describes the support for multiple prepaid services on a This section describes the support for multiple prepaid services on a
single SAD. Message flows illustrating the various interactions are single PPC. Message flows illustrating the various interactions are
presented in Appendix A. presented in Appendix A.
A SAD that supports prepaid operations for multi-services SHOULD set A PPC that supports prepaid operations for multi-services SHOULD set
the "Multi-Services Supported" bit in the PPAC. When working with the "Multi-Services Supported" bit in the PPAC. When working with
multi-services, we need to differentiate between the services. A multi-services, we need to differentiate between the services. A
Service-Id attribute is used in the PPAQ(TBD) in order to uniquely Service-Id attribute is used in the PPAQ in order to uniquely
differentiate between the services. The exact definition of the differentiate between the services. The exact definition of the
Service-Id attribute is outside the scope of this document. Service-Id attribute is outside the scope of this document.
A PPAQ that contains a Service-Id is associated with that Service. A A PPAQ that contains a Service-Id is associated with that service. A
PPAQ that contains a Rating-Group-Id is associated with that Rating- PPAQ that contains a Rating-Group-Id is associated with that Rating-
Group. A PPAQ MUST not contain both a Rating-Group-Id and a Group. A PPAQ MUST NOT contain both a Rating-Group-Id and a
Service-Id. A PPAQ that contains neither a Rating-Group-Id or a Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a
Service-Id applies to the Access Service. Service-Id then the default service is used, i.e., the "Access
Service".
3.7.1. Initial Quota Request 3.7.1. Initial Quota Request
When operations with multi-services is desired, the SAD requests the When operations with multiple services is desired then the PPC
initial quota for the Service by sending a PPAQ containing the requests the initial quota by sending a PPAQ containing the
Service-Id for that Service in an Authorize-Only Access-Request Service-Id in an Authorize-Only Access-Request packet for that
packet. Similarly, if the SAD supports Rating-Groups then it may service. Similarly, if the PPC supports rating groups then it may
request a quota for the Rating-Group by sending a PPAQ containing the request a quota for the rating group by sending a PPAQ containing the
Rating-Group-Id. In both cases the Update-Reason is set to "Initial- Rating-Group-Id. In both cases the Update-Reason is set to "Initial-
Request". Request". The Authorize-Only Access-Request message MAY contain more
than one PPAQ.
The Authorize-Only Access-Request message may contain more than one
PPAQ. The Authorize-Only Access-Request MUST include one or more
attributes that serve to identify the session so that it can be
linked to the original authentication. Which Session Identifiers are
included is up to specific deployments. The Authorize-Only message
must contain the Message-Authenticator(80) attribute for integrity
protection of the Authorize-Only Access-Request message.
Upon receiving an Authorize-Only Access-Accept message containing one Upon receiving an Authorize-Only Access-Accept message containing one
or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ
is assigned a unique QID that MUST appear in subsequent PPAQ updates is assigned a unique QID that MUST appear in subsequent PPAQ updates
for that service or rating-group. Additionally, the PPAQ MUST for that service or rating group. Additionally, the PPAQ MUST
contain the Service-ID or Group-ID, unless the PPAQ is the generic contain the Service-ID or Rating-Group-Id, unless the PPAQ is the
"Access Service". generic "Access Service".
3.7.2. Quota Update 3.7.2. Quota Update
Once the services start to utilize their allotted quota they will Once the services start to utilize their allotted quota they will
eventually need to replenish their quotas (either the threshold is eventually need to replenish their quotas (either the threshold is
reached or no more quota remains). In order to replenish the quota, reached or no more quota remains). In order to replenish the quota,
the PPC sends an Authorize-Only Access-Request message containing one the PPC sends an Authorize-Only Access-Request message containing one
or more PPAQs. Each PPAQ MUST contain the appropriate QID, or more PPAQs. Each PPAQ MUST contain the appropriate QID,
Service-ID or Group-ID (or neither the Service-ID or Group-Id if the Service-ID or Rating-Group-Id (or neither the Service-ID or Rating-
quota replenishment is for the "Access Service"). The Update-Reason Group-Id if the quota replenishment is for the "Access Service").
filed indicates either "Threshold reached"(3), or "Quota reached"(4). The Update-Reason filed indicates either "Threshold reached"(3), or
The Authorize-Only message must contain session identifiers. "Quota reached"(4).
Upon receiving an Authorize-Only Access-Request packet with one or Upon receiving an Authorize-Only Access-Request packet with one or
more PPAQs the PPS responds with a new PPAQ for that service. The more PPAQs the PPS responds with a new PPAQ for that service. The
PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a
Quota. If the PPS does not grant additional quota to the service it new QID. If the PPS does not grant additional quota for the service
MUST include the Termination-Action subfield in the PPAQ that will it MUST include the Termination-Action subfield in the PPAQ that will
instruct the SAD what to do with the service. instruct the PPC to take appropriate actions.
3.7.3. Termination 3.7.3. Termination
When the allotted quota for a service is exhausted, the SAD shall act When the allotted quota for a service is exhausted, the PPC shall act
in accordance with the Termination-Action field set in the Quota. If in accordance with the flags set in the Termination-Action subtype.
the Termination-Action field is absent then the service MUST be If the Termination-Action subtype is absent then the service MUST be
terminated. If the service is to be terminated, then the SAD shall terminated. If the service is to be terminated, then the PPC shall
send a PPAQ with the appropriate QID, the Service-Id, the used quota, send a PPAQ with the appropriate QID, the Service-Id, the used quota,
and the Update-Reason set to "Client Service Termination". and the Update-Reason set to "Client Service Termination".
If the oAccess Serviceoe has terminated, then all other services must If the "Access Service" has terminated, then all other services must
be terminated as well. In this case the SAD MUST report on all be terminated as well. In this case the PPC MUST report on all
issued quotas for the various services. The Update-Reason field issued quotas for the various services. The Update-Reason field
should be set to "Access Service Terminated". should be set to "Access Service Terminated".
3.7.4. Dynamic Operations 3.7.4. Dynamic Operations
Dynamic operations for multi-services are similar to dynamic Dynamic operations for multi-services are similar to dynamic
operations described for single service operations. The prepaid operations described for single service operations. The PPS MAY send
system may send a COA message containing a PPAQ for an existing a COA message containing a PPAQ for an existing service instance.
service instance. The SAD matches the PPAQ with the service using The PPC matches the PPAQ with the service using the Service-ID or the
the Service-ID attribute. The new quota could differ from the Rating-Group-Id attribute. The new quota could differ from the
previously allocated value. The SAD must react to the new value previously allocated value.
accordingly.
A disconnect message terminates the "Access Service". As such the A disconnect message terminates the "Access Service". As such the
SAD MUST report all unused quotas by sending an Authorize-Only Access PPC MUST report all unused quotas by sending an Authorize-Only Access
Request message containing a PPAQ for each active service. The Request message containing a PPAQ for each active service. The
Update-Reason shall indicate that the reason for the update. Update-Reason MAY indicate that the reason for the update.
3.7.5. Support for Resource Pools 3.7.5. Support for Resource Pools
If the PPC supports pools as indicated by setting the "Pools If the PPC supports pools as indicated by setting the "Pools
supported" bit in the PPAC(TBD) then the PPS may associate a Quota supported" bit in the PPAC then the PPS may associate a quota with a
with a Pool by including the Pool-Id and the Pool-Multiplier in the Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ.
PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the When Resource Pools are used, the PPAQ MUST NOT use the threshold
threshold field. field.
3.7.6. One-time Charging 3.7.6. One-time Charging
To initiate a One-Time charge the PPC includes the PPAQ attribute in To initiate one-time charging the PPC includes the PPAQ attribute in
an Access-Request packet. The Access Request packet MUST include a an Access-Request packet. The Service-ID field of the PPAQ
Message-Authenticator(80) and an Event-Timestamp(55) attribute. The identifies the prepaid service. The amount to be charged is
Service Id field of the PPAQ identifies the prepaid service. The specified using the Resource Quota and Resource Quota overflow
amount to be charged is specified using the Resource Quota and subtypes. If the value specified is negative then the resources are
Resource Quota overflow subtypes. If the value specified is negative credited to the user account. This functionality corresponds to
then the resources are credited to the user account. refunding.
The QID field MUST be set to a unique value and is used by the PPS to The QID subtype MUST be set to a unique value and is used by the PPS
detect duplicates. The Update Reason field MUST be set to One-Time to detect duplicates. The Update Reason field MUST be set to One-
Charging. Upon receiving a One-Time charge PPAQ, the RADIUS server Time Charging. Upon receiving a One-Time charge PPAQ, the RADIUS
authenticates the user and, if successful, passes the PPAQ to the server authenticates the user and, if successful, passes the PPAQ to
PPS. The PPS locates the account and debits or credits it the PPS. The PPS locates the account and debits or credits it
accordingly. The PPS MUST respond to the PPS with an Access-Accept accordingly. The PPS MUST respond to the PPS with an Access-Accept
message if successful, or an Access-Reject message otherwise. message if successful, or an Access-Reject message otherwise.
The RADIUS server shall respond to the SAD with an Access Accept In case of a successful operation the HAAA forwards the message to
message. Since this is a one-time charge the SAD must not allow the the PPC with an Access Accept message. Since this is a one-time
session to continue. Therefore, the RADIUS server should include in charge the PPC MUST NOT allow the session to continue. Therefore,
the Access-Accept a Session-Timeout set to 0. Upon receiving an the RADIUS server SHOULD include in the Access-Accept a Session-
Access-Accept response the SAD shall generate an Accounting Stop Timeout set to 0. Upon receiving an Access-Accept response the PPC
message. SHOULD generate an Accounting Stop message.
A PPAQ used for One-Time charging may appear in an Authorize-Only A PPAQ used for One-Time charging MAY appear in an Authorize-Only
Access Request. This is the case when the session already exists. Access Request. This is the case when the session already exists.
The PPS responds with an Access-Accept to indicate that the user The PPS responds with an Access-Accept to indicate that the user
account has been debited or an Access-Reject otherwise. account has been debited or an Access-Reject otherwise.
3.7.7. Error Handling 3.7.7. Error Handling
If the PPS receives a PPAQ with an invalid QID it MUST ignore that If the PPS receives a PPAQ with an invalid QID it MUST ignore that
PPAQ. PPAQ.
If the PPS receives a PPAQ containing a Service-Id, or a Rating- If the PPS receives a PPAQ containing a Service-Id, or a Rating-
Group-Id that it does not recognize, then it MUST ignore that PPAQ. Group-Id that it does not recognize, then it MUST ignore that PPAQ.
If the PPC receives a PPAQ containing a Service-Id, or a Rating- If the PPC receives a PPAQ containing a Service-Id, or a Rating-
Group-Id that it does not recognize, then it must ignore that PPAQ. Group-Id that it does not recognize, then it MUST ignore that PPAQ.
If the PPC receives a PPAQ that contains a Pool-Id without a Pool- If the PPC receives a PPAQ that contains a Pool-Id without a Pool-
Multiplier or a Pool-Multiplier without a Pool-Id it must ignore that Multiplier or a Pool-Multiplier without a Pool-Id it MUST ignore that
PPAQ. PPAQ.
3.7.8. Accounting Considerations 3.7.8. Accounting Considerations
Although typically generated, accounting messages are not required to Although typically generated, accounting messages are not required to
deliver a prepaid data service. When generated, accounting messages deliver a prepaid data service. When generated, accounting messages
are used for auditing purposes and for billing. Accounting messages are used for auditing purposes and for billing. Accounting messages
associated with prepaid data sessions should include the PPAQ(TBD) associated with prepaid data sessions should include the PPAQ
attribute. attribute.
3.7.9. Interoperability with Diameter Credit Control Application
The RADIUS prepaid extensions need to interoperate with the Diameter
protocol. Two interoperability scenarios exist, as follows. Either
the AAA infrastructure is Diameter based and the SAD are RADIUS
based, or the SAD is Diameter based and the AAA infrastructure is
RADIUS based.
The Diameter Credit Control Application [DIAMETERCC] describes how to
implement a prepaid accounting system using a Diameter based
infrastructure.
4. Attributes 4. Attributes
This section specifies the attributes that implement the RADIUS This section specifies the attributes that implement the RADIUS
extensions for prepaid. Their general format follow that of the base extensions for prepaid.
RADIUS [RFC2865] and take also account current design guidelines that
are proposed in the RADEXT working group. The type field of these
attributes contains a value that is drawn from the type value space
specified in [RFC2865]. The exact value for the type field of each
attribute is to be allocated by IANA. Note that, unless otherwise
specified, the format of the value field of each of the AVPs defined
in this section adheres to one of the formats specified in section 5
of [RFC2865]. In particular, the labels "string", "integer", and
"address" are used to indicate the format in the remainder of this
document.
4.1. PPAC Attribute 4.1. PrePaid Accounting Capability (PPAC) Attribute
The PrepaidAccountingCapability (PPAC) attribute is sent in the The PrepaidAccountingCapability (PPAC) attribute is sent in the
Access-Request message by a prepaid capable NAS and is used to Access-Request message by a PPC to describe its prepaid capabilities.
describe the prepaid capabilities of the NAS. The PPAC is also
present in an Access-Accept message by the PPS in order to indicate
the type of metering that is to be applied to this session.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | SUBtype 1 | LENGTH | | TYPE | LENGTH | SubType (1) | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) | | AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient-Extended (AiC-ext) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : value of PPAC TYPE : IANA registered value of PPAC attribute
LENGTH: 8 LENGTH: 8
VALUE : String VALUE : Data type String
The value MUST be encoded as follows:
Subtype (=1) : Subtype for AvailableInClient attribute
Length : Length of AvailableInClient attribute
(= 6 octets)
AvailableInClient (AiC):
The optional AvailableInClient Subtype, generated by the PPC,
indicates the metering capabilities of the NAS and shall be bitmap
encoded. The possible values are as follows.
0x00000001 Volume metering supported. The value field is encoded as follows:
0x00000002 Duration metering supported.
0x00000004 Resource metering supported.
0x00000008 Pools supported
0x00000010 Rating groups supported
0x00000020 Multi-Services supported.
0x00000040 Tariff Switch supported.
Others Reserved SubType : Value (1)
Length : 6 or 10 octets
Figure 10: PPAC Attribute AvailableInClient (AiC): The bitmap is encoded as:
4.2. Session Termination Attribute Value | Description
-------------+-------------------------------------
00000001 | Volume metering supported
00000010 | Duration metering supported
00000100 | Resource metering supported
00001000 | Pools supported
00010000 | Rating groups supported
00100000 | Multi-Services supported
01000000 | Tariff Switch supported
10000000 | Extended AiC field
The value is bitmap encoded. This attribute is included in a RADIUS If the Extended AiC flag is not set then the length
Access-Request message to the RADIUS server and indicates whether or of this SubType is 6 octets. If the Extended AiC flag
not the NAS supports Dynamic Authorization. is, however, set then the length of this SubType is
10 octects long and the subsequent 4 octects are
available as shown below:
0 1 2 3 AvailableInClient-Extended (AiC-ext):
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : value of Session Termination Capability The bitmap is encoded as:
Length: = 4
String encoded as follows:
0x00000001 Dynamic Authorization Extensions (rfc3576) is Value | Description
supported. -------------+-------------------------------------
00000001 | **Available via IANA registration**
00000010 | **Available via IANA registration**
00000100 | **Available via IANA registration**
00001000 | **Available via IANA registration**
00010000 | **Available via IANA registration**
00100000 | **Available via IANA registration**
01000000 | **Available via IANA registration**
10000000 | **Available via IANA registration**
Figure 11: Session Termination Attribute Figure 9: PPAC Attribute
4.3. PPAQ Attribute 4.2. Prepaid Accounting Operation (PPAQ) Attribute
One or more PPAQ attributes are sent in an Access Request, Authorize- One or more PPAQ attributes are sent in an Access Request, Authorize-
Only Access-Request and Access-Accept message. In an Access Request Only Access-Request and Access-Accept message. In an Access Request
message, the PPAQ attribute is used to facilitate One-Time charging message, the PPAQ attribute is used to facilitate one-time charging
transactions. In Authorize-Only Access-Request messages it is used transactions. In Authorize-Only Access-Request messages it is used
for One-Time charging, report usage and the request for further for one-time charging, report usage and to request further quota. It
quota. It is also used in order to request prepaid quota for a new is also used in order to request prepaid quota for a new service
service instance. In an Access-Accept message it is used in order to instance. In an Access-Accept message it is used in order to
allocate the (initial and subsequent) quotas. allocate the (initial and subsequent) quotas.
When multiple services are supported, a PPAQ is associated with a When multiple services are supported, a PPAQ is associated with a
specific service as indicated by the presence of a Service-Id, a specific service as indicated by the presence of a Service-Id, a
Rating-Group-Id, or the "Access Service" (as indicated by the absence Rating-Group-Id, or the "Access Service" (as indicated by the absence
of a Service-Id and a Rating-Group-Id). of both, the Service-Id and the Rating-Group-Id).
The attribute has a variable length (greater than 8, encoded into one Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes MUST
octet), and consists of a variable number of subtypes. Unused appear in the PPAQ attribute, except for the price enquiry message
subtypes are omitted from the message. In the following subsections exchange where these subtypes MUST be absent. A single PPAQ
the various subtypes of the PPAQ attribute are specified. attribute MUST NOT contain more than one Service-Id, MUST NOT contain
more than one Rating-Group-Id, and MUST NOT contain both a Service-Id
and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or
a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT
contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST
also contain a Pool-Multiplier SubType.
4.3.1. Quota Identifier AVP The PPAQ attribute, as shown in Figure 10, has a variable length
(greater than 8, encoded into one octet), and consists of a variable
number of subtypes. Unused subtypes are omitted from the message.
In the following subsections the various subtypes of the PPAQ
attribute are specified.
The value of the type field of the QuotaIDentifier AVP is TBD. The 0 1 2 3
length of this AVP is 6 octets. Its value is encoded as a string. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
It is generated by the PPS together with the allocation of new quota. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The online quota update RADIUS Access-Request message that is sent | TYPE | LENGTH | VALUE ...
from the SAD to the PPS includes a previously received +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
QuotaIdentifier AVP. ... VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2. VolumeQuota AVP TYPE : value of PPAQ
LENGTH: variable
VALUE : Data type String
The value of the type field of the VolumeQuota AVP is TBD. The Each subattribute is then encoding in the following style:
length of this AVP is 12 or 18 octets. The AVP is only present if
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PPAQ Attribute
4.2.1. Quota Identifier (QID) SubType
The value of the type field of the Quota Identifier (QID) SubType is
TBD. The length of this SubType is 6 octets. Its value is encoded
as a string. It is generated by the PPS and subsequently returned in
a PPAQ->QID subtype from the PPC to the PPS. This field has the
semantic of a transaction identifier and therefore changes with every
transaction initiated by the PPS to the PPC.
4.2.2. VolumeQuota SubType
The value of the type field of the VolumeQuota SubType is TBD. The
length of this SubType is 12 or 18 octets. It is only present if
volume-based charging is used. In a RADIUS Access-Accept message volume-based charging is used. In a RADIUS Access-Accept message
(PPS to SAD direction), it indicates the volume (in octets) allocated (PPS to PPC direction), it indicates the volume (in octets) allocated
for the session by the PPS. In an RADIUS Authorize-Only Access- for the session by the PPS. In an RADIUS Authorize-Only Access-
Request message (SAD to PPS direction), it indicates the total used Request message (PPC to PPS direction), it indicates the total used
volume (in octets) for both inbound and outbound traffic. The volume (in octets) for both inbound and outbound traffic. The
attribute consists of a Value-Digits AVP and optionally an Exponent attribute consists of a Value-Digits SubType and optionally an
AVP (as indicated in the length field). The Exponent AVP, if Exponent SubType (as indicated in the length field). The Exponent
present, MUST NOT encode a negative number or zero. SubType, if present, MUST NOT encode a negative number or zero.
4.3.3. VolumeThreshold AVP 4.2.3. VolumeThreshold SubType
The value of the type field of the VolumeThreshold AVP is TBD and its The value of the type field of the VolumeThreshold SubType is TBD and
length is 12 or 18 octets. This AVP is optionally present if its length is 12 or 18 octets. This SubType is optionally present if
VolumeQuota is present in a RADIUS Access-Accept message (PPS to SAD VolumeQuota is present in a RADIUS Access-Accept message (PPS to PPC
direction). It is generated by the PPS and indicates the volume (in direction). It is generated by the PPS and indicates the volume (in
octets) that shall be consumed before a new quota should be octets) that has to be consumed before a new quota is requested.
requested. This threshold should not be larger than the VolumeQuota. This threshold MUST NOT be larger than the VolumeQuota. The
The attribute consists of a Value-Digits AVP and optionally an attribute consists of a Value-Digits SubType and optionally an
Exponent AVP (as indicated by the length field). The Exponent AVP, Exponent SubType (as indicated by the length field). The Exponent
if present, MUST NOT encode a negative number or zero. SubType, if present, MUST NOT encode a negative number or zero.
4.3.4. DurationQuota AVP 4.2.4. DurationQuota SubType
The value of the type field of the DurationQuota AVP is TBD and its The value of the type field of the DurationQuota SubType is TBD and
length is 6 octets. This optional AVP is only present if duration- its length is 6 octets. This optional SubType is only present if
based charging is used. In RADIUS Access-Accept message (PPS to SAD duration-based charging is used. In a RADIUS Access-Accept message
direction), it indicates the duration (in seconds) allocated for the (PPS to PPC direction), it indicates the duration (in seconds)
session by the PPS. It is encoded as an integer. In an on-line allocated for the session by the PPS. It is encoded as an integer.
RADIUS Access-Accept message (PPC to PPS direction), it indicates the In a RADIUS Access-Request message (PPC to PPS direction), it
total duration (in seconds) since the start of the accounting session indicates the total duration (in seconds) since the start of the
related to the QuotaID of the PPAQ AVP in which it occurs. accounting session related to the QID subtype of the PPAQ attribute
in which it occurs.
4.3.5. DurationThreshold AVP 4.2.5. DurationThreshold SubType
The value of the type field of the DurationThreshold AVP is TBD and The value of the type field of the DurationThreshold SubType is TBD
its length is 6 octets. This AVP shall optionally be present if and its length is 6 octets. This SubType shall optionally be present
DurationQuota is present in a RADIUS Access-Accept message (PPS to if the DurationQuota is present in a RADIUS Access-Accept message
PPC direction). It represents the duration (in seconds) after which (PPS to PPC direction). It represents the duration (in seconds)
new quota should be requested. This threshold should not be larger after which new quota should be requested. This threshold MUST NOT
than the DurationQuota. It is encoded as an integer. be larger than the DurationQuota SubType. It is encoded as an
integer.
4.3.6. ResourceQuota AVP 4.2.6. ResourceQuota SubType
The value of the type field of the ResourceQuota AVP is TBD. The The value of the type field of the ResourceQuota SubType is TBD. The
length of this AVP is 12 or 18 octets. This optional AVP is only length of this SubType is 12 or 18 octets. This optional SubType is
present if resource-based or one-time charging is used. In the only present if resource-based or one-time charging is used. In the
RADIUS Access-Accept message (PPS to SAD direction) it indicates the RADIUS Access-Accept message (PPS to PPC direction) it indicates the
resources allocated for the session by the PPS. In RADIUS Authorize- resources allocated for the session by the PPS. In RADIUS Authorize-
Only Access-Request message (SAD to PPS direction), it indicates the Only Access-Request message (PPC to PPS direction), it indicates the
resources used in total, including both incoming and outgoing resources used in total, including both incoming and outgoing
chargeable traffic. In one-time charging scenarios, the subtype chargeable traffic. In one-time charging scenarios, the subtype
represents the number of units to charge or credit the user. The represents the number of units to charge or credit the user. The
attribute consists of a Value-Digits AVP and optionally an Exponent attribute consists of a Value-Digits SubType and optionally an
AVP (as indicated by the length field). Exponent SubType (as indicated by the length field).
4.3.7. ResourceThreshold AVP 4.2.7. ResourceThreshold SubType
The value of the type field of the ResourceThreshold AVP is TBD. The The value of the type field of the ResourceThreshold SubType is TBD.
length of this AVP is 12 or 18 octets. The semantics of this AVP The length of this SubType is 12 or 18 octets. The semantics of this
follow those of the VolumeThreshold and DurationThreshold AVPs. It SubType follow those of the VolumeThreshold and DurationThreshold
consists of a Value-Digits AVP and optionally an Exponent AVP. SubType. It consists of a Value-Digits SubType and optionally an
Exponent SubType.
4.3.8. Value-Digits AVP 4.2.8. Value-Digits SubType
The value of the type field of the Value-Digits AVP is TBD and its The value of the type field of the Value-Digits SubType is TBD and
length is 10 octets. This AVP encodes the most significant digits of its length is 10 octets. This SubType encodes the most significant
a number, encoded as an integer. If decimal values are needed to digits of a number, encoded as an integer. If decimal values are
present the number, the scaling MUST be indicated with a related needed to present the number, the scaling MUST be indicated with a
Exponent AVP. For example, the decimal number 0.05 is encoded by a related Exponent SubType. For example, the decimal number 0.05 is
Value-Digits AVP set to 5, and a scaling that is indicated with the encoded by a Value-Digits SubType set to 5, and a scaling that is
Exponent AVP set to -2. indicated with the Exponent SubType set to -2.
4.3.9. Exponent AVP 4.2.9. Exponent SubType
The value of the type field of the Exponent AVP is TBD. The length The value of the type field of the Exponent SubType is TBD. The
of this AVP is 6 octets. This AVP contains the exponent value that length of this SubType is 6 octets. This SubType contains the
is to be applied to the accompanying Value-Digit AVP. Its value is exponent value that is to be applied to the accompanying Value-Digit
encoded as an integer. SubType. Its value is encoded as an integer.
4.3.10. Update-Reason AVP 4.2.10. Update-Reason SubType
The value of the type field of the Update-Reason AVP is TBD. The The value of the type field of the Update-Reason SubType is TBD. The
length of this AVP is 4 octets. This AVP shall be present in the on- length of this SubType is 4 octets. This SubType is present in a
line RADIUS Access-Request message (PPC to PPS direction). It RADIUS Access-Request message (PPC to PPS direction) and indicates
indicates the reason for initiating the on-line quota update the reason for initiating the quota update operation. Update reasons
operation. Update reasons 6, 7, 8 and 9 indicate that the associated (6), (7), (8) and (9) indicate that the associated resources are
resources are released at the client side, and that therefore the PPS released at the PPC side, and that therefore the PPS MUST NOT
shall not allocate a new quota in the RADIUS Access Accept message. allocate a new quota in the RADIUS Access Accept message.
1. Pre-initialization The following values for the Update-Reason SubType are defined:
2. Initial Request
3. Threshold Reached Value | Description
-------------+--------------------------------------
0 | Reserved
1 | Pre-initialization
2 | Initial Request
3 | Threshold Reached
4 | Quota Reached
5 | TITSU Approaching
6 | Remote Forced Disconnect
7 | Client Service Termination
8 | "Access Service" Terminated
9 | Service not established
10 | One-Time Charging
11..255 | **Available for IANA registration**
4. Quota Reached Figure 11: Values for Update-Reason SubType
5. TITSU Approaching 4.2.11. PrepaidServer SubType
6. Remote Forced Disconnect The value of the type field of the PrepaidServer SubType is TBD. The
length of this SubType is 6 or 18 octets, for IPv4 and IPv6 addresses
respectively. This optional SubType indicates the address of the
serving PPS. If present, the Home RADIUS server uses this address to
route the message to the serving PPS. Multiple instances of this
subtype MAY be present in a single PPAQ attribute. The value of this
SubType is encoded as an address.
7. Client Service Termination If present in the PrepaidServer SubType of an incoming RADIUS Access-
Accept message, the PPC returns this SubType back without modifying
it in the subsequent RADIUS Access-Request message. If multiple
values are present, the PPC MUST NOT change their order.
8. "Access Service" Terminated 4.2.12. Service-ID SubType
9. Service not established The value of the type and length fields of the Service-ID SubType are
TBD. The value field of this SubType is encoded as a string. This
value is handled as an opaque string that uniquely describes the
service instance to which prepaid metering should be applied.
10. One-Time Charging A Service-Id could be an IP 5-tuple (source address, source port,
destination address, destination port, protocol). If a Service-ID
SubType is present in the PPAQ, the entire PPAQ attribute refers to
that service. If a PPAQ attribute does not contain a Service-Id or
Rating-Group-ID, then the PPAQ attribute refers to the "Access
Service".
4.3.11. PrepaidServer AVP 4.2.13. Rating-Group-ID SubType
The value of the type field of the PrepaidServer AVP is TBD. The The value of the type field of the Rating-Group-ID SubType is TBD.
length of this AVP is 6 or 18 octets, for IPv4 and IPv6 addresses The length of this SubType is 6 octets. This SubType indicates that
respectively. This optional AVP indicates the address of the serving this PPAQ attribute is associated with resources allocated to a
PPS. If present, the Home RADIUS server uses this address to route Rating Group with the corresponding ID. This SubType is encoded as a
the message to the serving PPS. The attribute may be sent by the string. A single PPAQ MUST NOT contain more than one
Home RADIUS server. Multiple instances of this subtype MAY be Rating-Group-ID.
present in a single PPAQ AVP. The value of this AVP is encoded as an
address.
If present in the incoming RADIUS Access-Accept message, the SAD 4.2.14. Termination-Action SubType
shall send this attribute back without modifying it in the subsequent
RADIUS Access-Request message, except for the first one. If multiple
values are present, the SAD shall not change their order.
4.3.12. Service-ID AVP The value of the type field of the Termination-Action SubType is TBD.
The length of this SubType is 3 octets. This SubType contains an
enumeration of the action to take when the PPS does not grant
additional quota. Valid actions are as follows.
The value of the type and length fields of the Service-ID AVP are The following values for the Termination-Action SubType are defined:
TBD. The value field of this AVP is encoded as a string. This value
is handled as an opaque string that uniquely describes the service
instance to which prepaid metering should be applied. A Service-Id
could be an IP 5-tuple (source address, source port, destination
address, destination port, protocol). If a Service-ID AVP is present
in the PPAQ, the entire PPAQ refers to that service. If a PPAQ does
not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to
the Access Service.
4.3.13. Rating-Group-ID AVP Value | Description
-------------+------------------------------------
0 | Reserved
1 | Terminate
2 | Request More Quota
3 | Redirect/Filter
4..255 | **Available for IANA registration**
The value of the type field of the Rating-Group-ID is TBD. The Figure 12: Values for the Termination-Action SubType
length of this AVP is 6 octets. This AVP indicates that this PPAQ is
associated with resources allocated to a Rating Group with the
corresponding ID. This AVP is encoded as a string. A PPAQ MUST NOT
contain more than one Rating-Group-ID.
4.3.14. Termination-Action AVP 4.2.15. Pool-ID SubType
The value of the type field of the Termination-Action AVP is TBD. The value of the type field of the Pool-ID SubType is TBD. The
The length of this AVP is 3 octets. This AVP contains an enumeration length of this SubType is 6 octets and it identifies the resource
of the action to take when the PPS does not grant additional quota. pool. It is encoded as a string.
Valid actions are as follows. (Note that the value 0 is reserved.)
1. Terminate 4.2.16. Pool-Multiplier SubType
2. Request More Quota The value of the type field of the Pool-Multiplier SubType is TBD.
The length of this SubType is 12 or 18 octets. The pool multiplier
determines the weight that resources are inserted into the pool that
is identified by the accompanying Pool-ID SubType, and the rate at
which resources are taken out of the pool by the relevant Service or
Rating-Group. The SubType consists of a Value-Digits SubType and
optionally an Exponent SubType (as indicated by the length field).
3. Redirect/Filter 4.2.17. Requested-Action SubType
4.3.15. Pool-ID AVP The value of the type field of the Requested-Action SubType is TBD.
The length of this SubType is 3 octets and it is only be present in
messages sent from the PPC to the PPS. It indicates that the PPC
desires the PPS to perform the indicated action and to return the
result. The PPAQ in which a Requested-Action SubType occurs MUST NOT
contain a QID, and MUST contain a Service-Identifier or a Rating-
Group-Identifer that allows the PPS to uniquely identify the service
for which the indicated action is requested.
The value of the type field of the Pool-ID AVP is TBD. The length of The following values for the Requested-Action SubType are defined:
this AVP is 6 octets. This AVP identifies the resource pool that the
quota included in this PPAQ is associated with. It is encoded as a
string.
4.3.16. Pool-Multiplier AVP Value | Description
-------------+-------------------------------------
0 | Reserved
1 | Balance Check
2 | Price Enquiry
3..255 | **Available for IANA registration**
The value of the type field of the Pool-Multiplier AVP is TBD. The Figure 13: Values for the Requested-Action SubType
length of this AVP is 12 or 18 octets. The pool-multiplier
determines the weight that resources are inserted into the pool that
is identified by the accompanying Pool-ID AVP, and the rate at which
resources are taken out of the pool by the relevant Service or
Rating-Group. The attribute consists of a Value-Digits AVP and
optionally an Exponent AVP (as indicated by the length field).
4.3.17. Requested-Action AVP 4.2.18. Check-Balance-Result SubType
The value of the type field of the Requested-Action AVP is TBD. The The value of the type field of the Check-Balance-Result SubType is
length of this AVP is 3 octets. This AVP can only be present in TBD. The length of this SubType is 3 octets. This SubType can only
messages sent from the PPC to the PPS. It indicates that the user or be present in messages sent from the PPS to the PPC. It indicates
the PPC desires the PPS to perform the indicated action and to return the balance check decision of the PPS about a previously received
the result. The PPAQ in which a Requested-Action AVP occurs MUST NOT Balance Check Request (as indicated in a Requested-Action SubType).
contain a QID, and MUST contain a Service-Identifier that, possibly The PPAQ attribute in which a Check-Balance-Result occurs MUST NOT
in combination with other AVPS, can be used by the PPS to uniquely include a QID.
identify the service for which the indicated action is requested.
The following actions may be requested. The following values for the Check-Balance-Result SubType are
defined:
1. Balance Check Value | Description
-------------+-------------------------------------------
0 | Success; Sufficient funds available
| in the user's prepaid account
1 | Failure; Insufficient funds available
2..255 | **Available for IANA registration**
2. Price Enquiry Figure 14: Values for the Check-Balance-Result SubType
4.3.18. Check-Balance-Result AVP 4.2.19. Cost-Information SubType
The value of the type field of the Check-Balance-Result AVP is TBD. The value of the type field of the Cost-Information SubType is TBD.
The length of this AVP is 3 octets. This AVP can only be present in The length of this SubType is variable. This SubType is used in
messages sent from the PPS to the PPC. It indicates the balance order to return the cost information of a service, which the PPC can
check decision of the PPS about a previously received Balance Check transfer transparently to the end user. This SubType is sent from
Request (as indicated in a Requested-Action AVP). Possible values the PPS to the PPC as a response to a "Price Enquiry", as indicated
are 0 for "success" and any other value for "failure" and mean that by the Requested-Action SubType. This SubType consists of four
sufficient funds are available (resp. are not available) in the further SubTypes, as follows:
user's prepaid account. The PPAQ in which a Check-Balance-Result
occurs MUST NOT include a QID, because no quota is reserved by the
PPS.
4.3.19. Cost-Information AVP Value-Digits SubType:
The value of the type field of the Cost-Information AVP is TBD. The The Value-Digits SubType encodes the most significant digits of
length of this AVP is variable. This AVP is used in order to return the monetery value that represents the cost in question.
the cost information of a service, which the PPC can transfer
transparently to the end user. This AVP is sent from the PPS to the
PPC as a response to a "Price Enquiry", as indicated by the
Requested-Action AVP. This AVP consists of four further AVPs, as
follows.
1. Value-Digits ASP: this encodes the most significant digits of the Exponent SubType:
monetery value that represents the cost in question.
2. Exponent AVP: this encodes the exponent that applies to the The Exponent SubType encodes the exponent that applies to the
Value-Digits AVP. Value-Digits SubType.
3. Currency-Code AVP: the value of the type field of this AVP is Currency-Code SubType:
TBD. The length of this AVP is 4 octets. It encodes the
currency code, as defined in the ISO 4217 standard.
4. Cost-Unit AVP: the value of the type field of this AVP is TBD. the value of the type field of this SubType is TBD. The length of
The length of this AVP is variable. It carries a UTF8String this SubType is 4 octets. It encodes the currency code, as
encoded human readable string that can be displayed to the end defined in the ISO 4217 standard.
user. It specifies the applicable unit to the Cost-Information
when the service cost is a cost per unit (e.g., cost of the
service is $1 per minute). The Cost-Unit can be minutes, hours,
days, kilobytes, megabytes, etc.
Example: the cost of 7.75 Malawi kwacha per hour would be encoded as Cost-Unit SubType:
follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and
Cost-Unit = "hour".
The PPAQ in which a Cost-Information occurs MUST NOT include a QID, the value of the type field of this SubType is TBD. The length of
because no quota is actually reserved by the PPS. this SubType is variable. It carries a UTF8String encoded human
readable string that can be displayed to the end user. It
specifies the applicable unit to the Cost-Information when the
service cost is a cost per unit (e.g., cost of the service is $1
per minute). The Cost-Unit can be minutes, hours, days,
kilobytes, megabytes, etc.
NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear For example, the cost of 7.75 Malawi kwacha per hour would be encoded
in the PPAQ attribute. A PPAQ MUST NOT contain more than one as follows. Value-Digits = 775, Exponent = -2, Currency Code = 103,
Service-Id, MUST NOT contain more than one Rating-Group-Id, and MUST and Cost-Unit = "hour".
NOT contain both a Service-Id and a Rating-Group-Id. A PPAQ that
does not contain a Service-ID or a Rating-Group-Id refers to the
"Access Service". A PPAQ MUST NOT contain more than one Pool-Id. A
PPAQ that contains a Pool-Id MUST also contain a Pool-Multiplier AVP.
4.4. Prepaid Tariff Switching Attribute (PTS) The PPAQ that carries a Cost-Information MUST NOT include a QID.
This specification defines the PTS attribute which allows for 4.3. Prepaid Tariff Switching (PTS) Attribute
changeovers from one rate to another during service provision.
Support for tariff switching is optional for both the PPC and the This specification defines the PTS attribute, which allows to switch
PPS. PPCs use the flag "Tariff Switching supported" of the from one rate to another during service provision. Support for
AvailableInClient subtype of the PPAC attribute in order to indicate tariff switching is optional to implement and to use for the PPC and
the PPS. PPCs use the flag "Tariff Switching supported" in the
AvailableInClient field of the PPAC attribute in order to indicate
support for tariff switching. PPSs employ the PTS attribute in order support for tariff switching. PPSs employ the PTS attribute in order
to announce their support for tariff switching. Details of this will to announce their support for tariff switching.
be specified after the format of the PTS attribute has been defined.
If a RADIUS message contains a PTS attribute, it MUST also contain at If a RADIUS message contains a PTS attribute, it MUST also contain at
least one PPAQ attribute. If a RADIUS Access-Request message least one PPAQ attribute. If a RADIUS Access-Request message
contains a PTS attribute or a "Tariff Switching supported" flag, it contains a PTS attribute or the "Tariff Switching supported" flag in
MUST also contain an Event-Timestamp RADIUS attribute (see the AvailableInClient field of the PPAC attribute, it MUST also
[RFC2869]). contain an Event-Timestamp RADIUS attribute (see [RFC2869]).
The value of the type field of the PTS AVP is TBD. The length of Every PTS attribute MUST include a QID SubType, as specified in
this AVP is variable. It contains one or more subtypes, as follows. Section 4.2.1. In a RADIUS Access-Request message sent from the PPC
Every PTS AVP MUST include a QuotaIdentifier AVP as specified in to the PPS, the QID SubType MUST contain the value of the Quota
Section 4.3.1. In an online RADIUS Access-Request message sent from Identifier SubType that was previously received from the PPS and MUST
the PPC to the PPS, the QuotaIdentifier AVP must contain a quota be the same as the value carried in the QID SubType of one of the
identifier that was previously received from the PPS and MUST be the PPAQ attributes included the same RADIUS message.
same as a quota identifier of one of the PPAQ attributes included the
same RADIUS message. If multiple services are supported and if the PPAQ is associated with
a service as indicated by the Service-ID SubType, then the PTS refers
to the tariff switch for that service. If the PPAQ does not have a
Service-ID, then the PTS refers to tariff switch for the "Access
Service".
A PPAQ attribute that is transported along with a PTS attribute and A PPAQ attribute that is transported along with a PTS attribute and
has the same quota identifier value as the PTS attribute in its own has the same value as the QID SubType contained in the PTS attribute
QID subfield is referred to as the "accompanying PPAQ attribute". If in its own QID SubType is referred to as the "accompanying PPAQ
a PPS receives an Access-Request message from a PPC, it associates a attribute". If a PPS receives an Access-Request message from a PPC,
unique quota identifier to this request. Thus, a quota identifier it associates a unique value for the QID SubType to this request.
also identifies a particular service.
The PTS AVP contains a number of other subtype AVPs which are The PTS attribute, as shown in Figure 15, contains a number of other
specified in the following subsections. subtypes which are specified in the following subsections.
4.4.1. VolumeUsedAfterTariffSwitch AVP 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the type field of the VolumeUsedAfterTariffSwitch AVP is TYPE : value of PTS
TBD. The length of this AVP is 12 or 18 octets. The LENGTH: variable
VolumeUsedAfterTariffSwitch subtype SHALL be used in online RADIUS VALUE : Variable length content of data type String
Access-Request messages (PPC to PPS direction). It indicates the
volume (in octets) used during a session after the last tariff switch
for the service specified via the QID subfield and the accompanying
PPAQ attribute. The attribute consists of a Value-Digits AVP and
optionally an Exponent AVP (as indicated in the length field).
4.4.2. TariffSwitchInterval AVP Each SubType is then encoding in the following style:
The type of the TariffSwitchInterval is TBD and its length 6 octets. 0 1 2 3
This AVP MUST be present in each PTS attribute that is part of a 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RADIUS Access-Accept message (PPS to PPC direction). It indicates +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the interval (in seconds) between the value of Event-Timestamp RADIUS | SubType | LENGTH | VALUE ...
attribute (see [RFC2869]) of the corresponding RADIUS Access-Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message and the next tariff switch condition.
4.4.3. TimeIntervalafterTariffSwitchUpdate AVP Figure 15: PTS Attribute
4.3.1. VolumeUsedAfterTariffSwitch SubType
The value of the type field of the VolumeUsedAfterTariffSwitch
(VUATS) SubType is TBD. The length of this SubType is 12 or 18
octets. The VolumeUsedAfterTariffSwitch subtype SHOULD be used in
the RADIUS Access-Request messages (PPC to PPS direction). It
indicates the volume (in octets) used during a session after the last
tariff switch for the service specified via the QID SubType and the
accompanying PPAQ attribute. The attribute consists of a Value-
Digits SubType and optionally an Exponent SubType (as indicated in
the length field).
4.3.2. TariffSwitchInterval SubType
The type of the TariffSwitchInterval (TSI) SubType is TBD and its
length 6 octets. This SubType MUST be present in each PTS attribute
that is part of a RADIUS Access-Accept message (PPS to PPC
direction). It indicates the interval (in seconds) between the value
of Event-Timestamp RADIUS attribute (see [RFC2869]) of the
corresponding RADIUS Access-Request message and the next tariff
switch condition.
4.3.3. TimeIntervalafterTariffSwitchUpdate SubType
The value of the type field of the The value of the type field of the
TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is TBD. The length TimeIntervalafterTariffSwitchUpdate (TITSU) SubType is TBD. The
of this AVP is 6 octets. The PPS MUST include this AVP if there is length of this SubType is 6 octets. The PPS MUST include this
another tariff switch period after the period that ends as indicated SubType if there is another tariff switch period after the period
by the TSI attribute. The value of the TITSU AVP in encoded as an that ends as indicated by the TSI SubType. The value of the TITSU
integer, and contains the number of seconds of the tariff period that SubType in encoded as an integer, and contains the number of seconds
begins immediately after the period that ends as indicated by the TSI of the tariff period that begins immediately after the period that
attribute. If the TITSU attribute is not present, the PPC assumes ends as indicated by the TSI attribute. If the TITSU SubType is not
that the tariff period which ends as indicated by the TSI attribute present, the PPC assumes that the tariff period which ends as
lasts until further notice. If TITSU is specified, the PPC MUST send indicated by the TSI SubType lasts until further notice. If TITSU is
a quota update before the point in time specified by the TITSU specified, the PPC MUST send a quota update before the point in time
attribute (see Figure 9). specified by the TITSU SubType (see Figure 8).
If a RADIUS message contains a PTS attribute, it MUST also contain at 5. Diameter RADIUS Interoperability
least one PPAQ attribute. The PTS is associated with the PPAQ by the
QID. If multiple services are supported and if the PPAQ is
associated with a service as indicated by the Service-ID AVP, then
the PTS refers to the tariff switch for that service. If the PPAQ
does not have a Service-ID, then the PTS refers to tariff switch for
the Access-Service.
If a PPC supports tariff switching then it MUST set the 0x00000040 The RADIUS prepaid extensions need to interoperate with the Diameter
(Tariff switching supported) flag of the AvailableInClient subtype of protocol. Two interoperability scenarios exist, as follows. Either
the PPAC attribute that is contained in the Access-Request packet the AAA infrastructure is Diameter based and the PPC are RADIUS
starting the session. based, or the PPC is Diameter based and the AAA infrastructure is
RADIUS based.
5. Translation between RADIUS prepaid and Diameter Credit Control The Diameter Credit Control Application [RFC4006] describes how to
implement a prepaid accounting system using a Diameter based
infrastructure.
The translation functionality between a Diameter Credit Control and a
RADIUS prepaid protocol interaction is described in Appendix B.
6. Security Considerations
The extended RADIUS protocol described in this document is subject to
a number of potential attacks, in a manner similar to the RADIUS
protocol without these extensions. It is recommended that IPsec be
employed to protect against certain of the attacks.
[Editor's Note: This section is freaking short. We should add
something here.]
7. Table of Attributes
The following table provides a guide which attributes may be found in
which RADIUS messages, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute
Request
0-1 0 0 0 0 TBD PPAC
0+ 0+ 0 0 0+ TBD PPAQ
0+ 0+ 0 0 0+ TBD PTS
8. IANA Considerations
This document contains a number of instructions to IANA.
8.1. New RADIUS Attributes
This document requires the assignment of new RADIUS attributes type
numbers for the following attributes:
Attribute Name | Attribute Type Value
--------------------------------------+-----------------------------
Prepaid-Accounting-Capability (PPAC) | TBD
Prepaid-Accounting-Operation (PPAQ) | TBD
Prepaid Tariff Switching (PTS) | TBD
8.2. New Registry: Prepaid SubTypes
Section 4 defines the SubTypes used within newly defined attributes.
IANA is asked to create a registry for these SubTypes. Each registry
entry consists of a 8 bit number together with a description of the
SubType. This document creates the following SubTypes for this
registry:
Value | SubType Name
---------+-----------------------------
0 | Reserved
1 | AvailableInClient
2 | Quota Identifier
3 | VolumeQuota
4 | VolumeThreshold
5 | DurationQuota
6 | DurationThreshold
7 | ResourceQuota
8 | ResourceThreshold
9 | Value-Digits
10 | Exponent
11 | Update-Reason
12 | PrepaidServer
13 | Service-ID
14 | Rating-Group-ID
15 | Termination-Action
16 | Pool-ID
17 | Pool-Multiplier
18 | Requested-Action
19 | Check-Balance-Result
20 | Cost-Information
21 | Currency-Code
22 | Cost-Unit SubType
23 | VolumeUsedAfterTariffSwitch
24 | TariffSwitchInterval
25 | TimeIntervalafterTariffSwitchUpdate
26..255 | **Available for IANA registration**
The semantic of the above-listed SubTypes is described in Section 4.
Following the policies outline in [RFC3575] the available SubTypes
(i.e., value 0 and values 26-255) with a description of their
semantic will be assigned after Expert Review initiated by the O&M
Area Directors in consultation with the RADEXT working group chairs
or the working group chairs of a designated successor working group.
Updates can be provided based on expert approval only. A designated
expert will be appointed by the O&M Area Directors. No mechanism to
mark entries as "deprecated", or to delete entries from the registry
is envisioned.
Each registration must include a number for the SubType and the
semantic of the SubType.
8.3. New Registry: Update-Reason
Section 4.2.10 defines the Update-Reason SubType. IANA is asked to
create a registry for the values contained in the Update-Reason
SubType, as shown in Figure 11. Each registry entry consists of a 8
bit number together with a description of the update reason.
Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned.
8.4. New Registry: Termination-Action
Section 4.2.14 defines the Termination-Action SubType. IANA is asked
to create a registry for the values contained in the Termination-
Action SubType, as shown in Figure 12. Each registry entry consists
of a 8 bit number together with a description of the termination
action.
Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned.
8.5. New Registry: Requested-Action
Section 4.2.17 defines the Requested-Action SubType. IANA is asked
to create a registry for the values contained in the Requested-Action
SubType, as shown in Figure 13. Each registry entry consists of a 8
bit number together with a description of the requested reason.
Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned.
8.6. New Registry: Check-Balance-Result
Section 4.2.18 defines the Check-Balance-Result SubType. IANA is
asked to create a registry for the values contained in the Check-
Balance-Result SubType, as shown in Figure 14. Each registry entry
consists of a 8 bit number together with a description of the
requested reason.
Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned.
8.7. New Registry: AvailableInClient-Extended
Section 4.2.18 defines the PrePaid Accounting Capability (PPAC)
attribute with the AvailableInClient-Extended field. IANA is asked
to create a registry for the values contained in the
AvailableInClient-Extended field, as shown in Section 4.1. Each
registry entry consists of a 8 bit number together with a description
of the capability. Note that this is a bitmask and only 8 values are
available for registration via IANA.
Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned.
9. Acknowledgements
The authors would like to thank Christian Guenther, Bernard Aboba,
and John Loughney for their feedback throughout the development of
this document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to
Indicate Requirement Levels", March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC
2865: Remote Authentication Dial In User Server (RADIUS)",
June 2000.
10.2. Informative References
[I-D.ietf-radext-filter-rules]
Congdon, P., "RADIUS Attributes for Filtering and
Redirection", draft-ietf-radext-filter-rules-03 (work in
progress), July 2007.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS
Extensions", June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Adoba, "RFC 3576: Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service (RADIUS)",
February 2003.
[RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "RFC 3748: Extensible Authentication Protocol",
June 2004.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "RFC 4006: Diameter Credit Control Application",
August 2005.
Appendix A. Example flows
This section presents certain example flows that involve the RADIUS
prepaid extensions. By no means is the intent of this section to
specify or recommend business logic, rating strategies, and
application-level behaviour. The intent of this section is purely to
illustrate some fictive scenarios and the RADIUS prepaid message
flows that could be associated with these scenarios. The contents of
this section should be regarded as a collection of informative
examples that aim to provide guidance to implementors.
A.1. A simple flow
End user PPC PPS
user logs on
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00011}
-------(2)-------->
[allocates
5MB quota]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ = 5MB,
VTH = 4.5 MB}}
<-------(3)--------
service provision/metering
-------(4)--------->
4.5 MB consumed
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ=4.5MB,
REASON=THRESHOLD REACHED}}
-------(5)--------->
[allocates another 7MB
to the access service]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=12MB,
VTH = 11.5 MB}}
<----------(6)--------------
user logs off
------(7)-------
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=7 MB,
REASON=ACCESS SERV TERMINATED}}
-------(8)--------->
[reimburses
user account]
AA Accept
{RADIUS BASE AVPS}
<-------(9)--------
Figure 19: A simple example message flow
The user logs on (1). The PPC sends a RADIUS Access Request message
to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP
indicates that both duration-based and volume-based metering is
supported. However, it also indicated that multiple services, rating
groups and resource pools are not supported. Note that, since this
is not an "Authorize-Only" message, no PPAQ attribute with Update
Reason="initial request" is included (see Section 3.7.1). The PPS
then authenticates the user and authorizes the access service, as is
usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at
least the last message that is sent to the home AAA server during
this possibly multiple-round exchange.
If authentication and authorization is successful (in this example
this is assumed), then the PPS identifies the user's prepaid account
from the included base RADIUS AVPs, and determines the capabilities
of the PPC from the PPAC attribute. Assuming that sufficient funds
are available in the user's prepaid account, the PPS reserves some of
these and rates the service. In this example, the PPS reserves, say,
2 Euros and determines that the access service is rated at 0.4 Euro
per MB. This results in 5 MB of quota being granted. The PPS also
determines that the PPC should ask for this quota to be replenished
once 4.5 MB have been consumed. Thus, it creates an Access Accept
message with a Volume-Threshold indication of 4.5MB. It further
associates the QID=5 to this reservation. This identifier can be
used to later uniquely identify the prepaid session, user, account,
etc. The resulting Access Accept message is sent to the PPC (3).
Upon reception of message (4), the PPC provides the access service to
the user and meters it accordingly. At some point in time, the
threshold is reached, i.e., 4.5MB of "access service" have been
consumed by the user. At that point, the PPC generates an Authorize-
Only Access Request that contains the usual RADIUS attributes and a
PPAQ attributes that reports the amount of consumed quota, and the
request for replenishment, i.e., the Update-Reason= THRESHOLD REACHED
(5). Note that the QID in this message is the same as the one
previously received from the PPS.
Upon reception of message (5), the PPS identifies the user and his
account from the QID. In also determines that a prepaid session is
ongoing, and that enough credit remains in the prepaid account in
order for the access service to continue being provided. Since 4.5
MB have been consumed, the PPS subtracts 1.8 Euros from the user's
prepaid account. The PPS decides to reserve another 2.8 euros from
the user's account. (This results in 3 euros being reserved in total
at this point in time.) As the access service is rated at 0.4 euros
per MB, the PPS determines that another 7 MB of quota should be
granted. This results in a total cumulative quota allocation of 12
MB for the access service. The PPS further calculates the new
threshold value of 11.5 MB. Since this is a new quota reservation,
the PPS also allocates a new QID to it, in this example QID=8. The
resulting RADIUS message is sent to the PPC (6).
Upon reception of message (6), the PPC updates its records and
continues provisioning access to the user. At some point the user
logs off (7). The PPC must then report how many resources were
consumed, so that the PPC can subtract the appropriate monetary
amount from the user's prepaid account. To this end the PPC
constructs an Authorize-Only Access Request message with a PPAQ
attributes for the access service. In this example, 7 MB were
consumed by the access service in total. The PPC reports 7 MB its
final message (8). The PPS correlates the report, using the QID, to
the previous session state. It determines, from the previous
records, that the access service had consumed another 4.5 MB before
(as indicated in message (6)). This means that, of the 7 MB, only
3.5 MB have not yet been subtracted from the user's account. Thus,
the PPS subtracts another 1.4 euros from the user's account and,
since the session is to be terminated (REASON=ACCESS SERVICE
TERMINATED), releases any reserved monetary amount.
The PPS responds with an Access Response as required by the RADIUS
base specification (9).
A.2. A flow with prepaid tariff switching
End user PPC PPS
user logs on
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00111}
-------(2)-------->
[allocates
20MB quota]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ = 20MB,
VTH = 18 MB}, PTS={
QID=5, PTS{TSI=300sec,
TITSU=6000sec}}
<-------(3)-------
service provision/metering
-------(4)--------->
5900 seconds
passed
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ=14MB,
REASON=TITSU APPROACH.},
TSI={QID=5, VUATS=11MB}}
-------(5)--------->
[allocates another 10MB
to the access service]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=30MB,
VTH = 28 MB},PTS={
QUD=8, PTS=95 sec}}
<----------(6)--------------
user logs off
------(7)-------
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=17 MB,
REASON=ACCESS SERV TERMINATED},
PTS={QID=8, VUATS=2.5 MB}
-------(8)--------->
[reimburses
user account]
AA Accept
{RADIUS BASE AVPS}
<-------(9)--------
Figure 20: Example message flow with Tariff Switch
The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC
AVP. This AVP indicates that both duration-based and volume-based
metering is supported, as well as tariff switching. The home AAA
server then may authenticate and user and authorize the access
service, as is usual in RADIUS. Note that the PPAC AVP is appended
by the PPC in at least the last message that is sent to the PPS
during this possibly multiple-round exchange.
If authentication and authorization is successful (in this example
this is assumed), the PPS identifies the user's prepaid account from
the included base RADIUS AVPs, and determines the capabilities of the
PPC from the PPAC attribute. In this example, it is assumed that a
tariff switch is about to occur in 300 seconds from the current time.
Suppose that the access service is currently rated at 0.5 euros per
MB and in the next tariff period it is rated at 0.6 euros per MB.
Suppose further that a third tariff period is about to start in 6000
seconds from current time and that that access service is rated at
0.8 euros per MB in that period. The PPS then decides to reserve 12
euros from the user's account. Since it is conceivable that the user
may consume all allocated quota in the (more expensive) "0.6-euro"
period, the PPS reserves 20 MB of quota, and determines a threshold
value of 18 MB. It constructs a Radius Access Accept message with a
PPAQ attribute that reflects these choices, and carries a Quota
Identifier QID=5. It further adds a PTS AVP in the message which is
linked to the PPAQ via the common QID value. The PTS AVP contains a
TSI attribute indicating that a tariff switch will occur in 300
seconds. It also includes a TITSU attribute with the value of 6000
seconds. This is included in order to make sure that the PPC will
report the consumed quota before the "2-euro" tariff period will
start. The message is sent to the PPC (3).
Upon reception of message (3), the PPC provides the access service to
the user and meters it accordingly (4). It also keeps track of time.
That is, it remembers how many octets are consumed before and how
many after the tariff switch that will take place in 300 seconds.
In this example it is assumed that the user consumes the allocated
quota rather slowly. In particular, nearly 6000 seconds (the value
indicated by TITSU SubType) pass without the threshold of 18 MB being
reached. The PPC notices this and must therefore report usage and
request the quota to be replenished despite the fact that the
threshold has not been reached. In this example, it decides to do so
100 seconds before the 6000 seconds are reached. To this end, it
constructs an Authorization Access Request message including a PPAQ
that indicates that 14 MB have been consumed up to now. It also
includes a PTS attribute in order to indicate, using the VUATS
SubType, that 11 MB of these were consumed after the tariff switch.
The message is sent to the the PPS (5).
The PPS can link the message to previous session state via the QID.
It now rates the consumed volume as follows. The 11 MB that were
consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros
and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS
subtracts the amount of 6.6+1.5=8.1 euros from the user's account,
which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved.
The PPS now determines that message (5) was sent in order to
replenish the quota for this prepaid session. This can be deduced
from the UPDATE REASON field, which indicates that the PPC sent this
message because the time indicated by the TITSU SubType is
approacing. The PPS now determines that enough credit remains in the
user's prepaid account in order for the access service to continue
being provided and decides to reserve another 8.9 euros from the
user's account. Since it is conceivable that the user will consume
the 6 unused MB of quota from the previous allocation, as well as the
entire quota that is to be allocated now, entirely in the "0.8-euro"
period, the quota that should now be granted in addition to the
previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros
are being reserved in order to "cover the worst case scenario". The
fact that 0.9 euros are reserved for this purpose is due to the fact
that the unused 6 MB from the previous allocation correspond to 4.8
euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more
than the amount of funds that are still "reserved" from the previous
allocation. (After this reservation, the total amount of reserved
money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB
being consumed in the "0.8-euro" period.)
Since quotas are encoded in a cumulative way in RADIUS, the PPS
includes a VolumeQuota of 30 MB into the Access Accept message (6).
The PPS further calculates the new threshold value of 28 MB. Since
this is a new quota reservation, the PPS also allocates a new QID to
it, in this example QID=8. The resulting RADIUS message is sent to
the PPC (6).
Upon reception of message (6), the PPC updates its records and
continues providing access to the user. At some point the user logs
off (7). The PPC must then report how many resources were consumed,
so that the PPC can subtract the appropriate monetary amount from the
user's prepaid account. To this end the PPC constructs an Authorize-
Only Access Request message with a PPAQ attributes for the access
service. In this example, 17 MB were consumed by the access service
in total. The PPC reports 17 MB its final message (8). The PPS
correlates the report, using the QID, to the previous session state.
It determines, from the previous records, that the access service had
consumed 14 MB before (as indicated in message (5)). This means
that, of the 17 MB, only the monetary equivalent for 3 MB have not
yet been subtracted from the user's account. The PPS calculates how
much should be deducted from the user's account as follows. Since
the VUATS SubType indicates that 2.5MB were consumed after the tariff
switch, only 0.5 MB were consumed before that. Thus, the monetary
equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. That is, the PPS
subtracts 3.6 euros from the user's prepaid account. Since the
session has by now be terminated by the PPC (REASON=ACCESS SERVICE
TERMINATED), the PPS now releases any reserved monetary amount, in
this example 12.8 - 3.6 = 9.2 euros.
The PPS responds with an Access Response as required by the RADIUS
base specification (9).
Remark: In this example, two tariff switches take place. In other
scenarios, of course, only one tariff switch may occur. In such
scenarios the TITSU SubType is not used.
A.3. Resource pools and Rating Groups
End user PPC PPS
user logs on
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00101111}
-------(2)-------->
[allocates
5MB quota]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ = 5MB,
poolID=1,mult=1}}
<-------(3)--------
service provision/metering
-------(4)--------->
user requests service A
-------(5)--------->
Access Request
{RADIUS BASE AVPS,PPAQ={
SID="A", RGROUP=1}}
-------(6)-------->
[allocates 50 min
quota]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=7, DQ=3000sec
poolID=1,RGROUP=1, SID="A"
mult=1747.63}}
<---------(7)---------------
user requests service B
-------(8)-------->
Pool 1 close to exhaustion
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ=4MB,
REASON=QUOTA REACHED,
PoolID=1, mult=1}
PPAQ={QID=7, DQ=3300sec
REASON=QUOTA REACHED,
PoolID=1, mult=1747.63,
SID="A",RGROUP=1}}
-------(9)--------->
[allocates another
3 MB to access service
and 30 minutes to
service "A"]
Access Accept
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=8MB,
PoolID=1, mult=1, RGROUP=1},
PPAQ={QID=9, DQ=4800sec
PoolID=1, mult=1747.63,
SID="A"}}
\ <----------(10)--------------
user logs off
------(11)-------
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=6.5MB,
REASON=ACCESS SERV TERMINATED,
PoolID=1, mult=1}
PPAQ={QID=9, DQ=5400sec
REASON=ACCESS SERV TERMINATED,
PoolID=1, mult=1747.63,
SID="A",RGROUP=1}}
-------(12)--------->
[reimburses
user account]
AA Accept
{RADIUS BASE AVPS
<------(13)--------
Figure 21: Example message flow with resource pools and rating groups
The user logs on (1). The PPC sends a RADIUS Access Request message
to the PPS (2), and includes the prepaid-specific PPAC AVP,
indicating that multiple services, rating groups and resource pools
are supported. Note that, since this is not an "Authorize- Only"
message, no PPAQ attribute with Update Reason="initial request" is
included (see Section 3.7.1). The PPS then may authenticate the user
and authorize the access service, as is usual in RADIUS. Note that
the PPAC AVP is appended by the PPC in at least the last message that
is sent to the PPS during this possibly multiple-round exchange.
If authentication and authorization is successful (in this example
this is assumed), the PPS identifies the user's prepaid account from
the included base RADIUS AVPs, and determines the capabilities of the
PPC from the PPAC attribute. Assuming that sufficient funds are
available in the user's prepaid account, the PPS reserves some of
these and rates the service. In this example, the PPS reserves 5
Euros and determines that the access service is rated at 1 Euro per
MB. In anticipation that the user requests more chargeable services
throughout this prepaid session, and since this is supported by the
PPC, the PPS further associates a resource pool with this
reservation, in this example PoolID=1. The PPC also specifies the
multiplier = 1 for the access service. Note that, since 5MB =
5242880 octets, 1 unit in the resource pool corresponds to 5 /
5242880 euros, which is about 0.000095367431640625 Eurocents.
(However, the PPC does not need to know that.) Moreover, the PPS
associates the QID=5 to this reservation. This identifier can be
used to later uniquely identify the prepaid session, user, account,
etc. The resulting Access Accept message is sent to PPC (3).
Upon reception of message (3), the PPC provides the access service to
the user and meters it accordingly (4). That is, for every octet
consumed, the PPC subtracts 1 unit (since the multiplier is 1) from
the resouce pool with PoolID=1.
At some point in time, the user requests another chargeable service,
namely service A (5). The PPC generates an Authorize-Only Access
Request that contains the usual RADIUS attributes and the Service-ID
identifying service A (6). The PPC has determined that service A is
rated in an identical way as at least one more service. Thus,
service A has been configured to belong to a rating group, in this
example the group with Rating-Group-ID=1. This identifier is
included is message (6).
Upon reception of message (6), the PPS identifies the user and his
account from the base RADIUS attributes, the fact that a prepaid
session is ongoing, and determines that enough credit remains in the
prepaid account in order for service A to be provided. The PPS also
determines that service A is rated at 0.10 euros per minute. The PPS
decides to reserve another 5 euros from the users account; this
corresponds to 50 minutes or, as encoded in the DurationQuota
SubType, 3000 seconds. As service A draws from the same prepaid
account as the access service, the PPS associates this reservation
with the same resource pool as the previous reservation (QID=5),
namely the pool with PoolID=1. Note that, in order for the abstract
units in the pool to be consistent, the multiplier has to be 1747.63.
This is because each second corresponds to about 0.10 / 60 = 0.00167
euros, which is about 1747.63 times the value of an abstract resource
pool unit, as this was determined by the first allocation of quota to
the pool (i.e., 0.000095367431640625 Eurocents). Since this is a new
quota reservation, the PPS also allocates a new QID to it, in this
example QID=7. The resulting RADIUS message is sent to the PPC (7).
Upon reception of message (7), the PPC adjusts the units in resource
pool 1. That is, it first determines how much quota had been
allocated to service A in the past, and subtracts this from the quota
reservation found in the message. Since this is the first quota
reservation for service A, there is nothing to subtract. Thus, it
adds 3000 * 1747.63 = 5242890 units to the pool and remembers that
3000 seconds have been allocated to service A during this prepaid
session. The PPC then provides service A to the user, and meters it
against resource pool 1. That is, for every second it subtracts
1747.63 units from the pool.
At some point in time, the user requests service B (8). The PPC
determines that service B is rated exactly in the same way as service
A, i.e., that they belong to the same rating group, namely the one
with Rating-Group-ID=1. Since this rating group has been effectively
authorised by the allocation of quota with QID=7, the PPC provides
service B to the user immediately. It is rated in the same way as
service A, i.e., for every second provided, 1747.63 units are
subtracted from credit pool 1.
At some point in time, resource pool 1 is close to exhaustion. (For
example, the PPC may determine that the pool is "close to exhaustion"
when has less than 10% its initial amount of units.) At that point,
the PPC needs to ask for replenishment for the pool. Suppose that,
at that point in time, 4MB of "access service", 45 minutes of
"service A", and 10 minutes of "service B" were provided to the user.
Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304
+ 5767179 = 9961483 abstract service units from the pool. The PPC
constructs an Authorize-Only Access Request message that reports the
usage for the "access service" and "service A". This message
contains two PPAQ attributeS, is sent to the PPS (9). Note that is
the message it appears that "service A" has consumed more than it was
allocated (i.e., 55 minutes although only 50 minutes were initially
allocated to it). This is not a a problem since the PPS knows that
"service A" was drawing from the same pool as the "access service"
and that the "access service" did only consume 4 out of the 5 MB it
was allocated.
Upon reception of message (9), the PPS subtracts 4 euros from the
user's account for the "access service" and another 5.5 euros for
"service A". (This includes the charge incurred by "service B" up to
that point in time, although the PPS is not aware of "service B"
being provisioned to the user.) The PPS then determines that
sufficient funds remain in the prepaid account in order for both
services to be continued. The PPS decides to reserve another 3MB for
the access service and 30 minutes for "service A". This corresponds
to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a
cumulative manner, the PPAQ attribute that grants the quota for the
"access service" contains a Volume-Quota SubType of 8MB (8388608
octets), which is the 5MB that were initially allocated, plus the 3MB
allocated now. The resource pool identifier is, as previously,
PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants
quota for "service A" contains 4800 seconds (the initial 3000 plus
1800 that correspond to the 30 additional minutes). Again, the
PoolID=1 and multiplier=1747.63. The resulting Access Response
message is sent to the PPC (10).
When the PPC received message (10) it checks how much quota has been
allocated previously to the "access service". It finds that the
answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets)
that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets)
have not yet been added to resource pool 1. The PPC thus adds
3145728 abstract units to resource pool 1 (since the multiplier is
1). The PPC then acts similarly on the other PPAQ attribute that
exists in message (11). That is, the PPC determines that 3000
seconds of quota for "service A" had already been added to the pool.
Thus only 1800 out of the 4800 should be additionally added to the
pool. Since the applicable multiplier here is 1747.63, the PPC adds
further 3145734 abstract units to the pool 1.
The PPC then continues to provide the access service, "service A" and
"service B" to the user, and meters them against the pool, as
previously.
At some point the user logs off (11). The PPC must then report how
many resources were consumed, so that the PPC can subtract the
appropriate monetary amount from the user's prepaid account. To this
end the PPC constructs an Authorize-Only Access Request message with
two PPAQ attributes; one for the access service and one for "service
A". Suppose that, in total, 6.5MB were consumed by the access
service, 70 minutes were consumed by "service A" and 20 minutes by
"service B". The PPC reports 6.5MB (6815744 octets) and 90 minutes
(5400 seconds) in its final message (12). The PPS determines, from
the previous records, that the access service consumed another 2.5MB
(since 4MB out of the 6.5MB were already reported in message (9), and
that "service A" consumed further 600 seconds. This corresponds to
2.5 + (600/60)*0.1 = 2.5+ 1=3.5 euros. Thus, the PPS only subtracts
2.5 out of the 6 previously reserved euros from the user's prepaid
account and responds with an Access Response as required by the
RADIUS base specification (13).
A.4. One-time charging
End user PPC PPS
user requests ring tone
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=321, SID=X, RQ=650,
REASON=10 (ONE-TIME CHARGING}}
-------(2)--------->
[rates 650 abstract units
deducts from user's account]
Access Accept
{RADIUS BASE AVPS}
<----------(3)--------------
ring tone is delivered
<------(4)-------
Figure 22: Example message flow with one-time charging
The user requests a chargeable ring tone (1). The PPC sends a RADIUS
Access Request message to the PPS (2), and includes a PPAQ attribute
with Update Reason="one-time charging" is included (see
Section 3.7.6). The Service ID indicates to the PPS that the
charging event is connected to a ring tone, so that the PPS can rate
the event accordingly. The PPAQ also contains a unique Quota
Identifier.
The PPS then may authenticate the user as is usual in RADIUS. If
authentication is successful (in this example this is assumed), the
home AAA server forwards the PPC converts the 650 reported abstract
units into monetary value, according to the service type, and debit
the user's account accordingly. This happens, of course, only if
sufficient funds are available in the user's prepaid account. The
PPC then responds with an an Access Accept message (3). The PPS adds
a "session timeout = 0 AVP" (see Section 3.7.6).
A.5. Price enquiry
End user PPC PPS
user requests AoC
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB,
REQ_ACT=2(PRICE ENQUIRY}}
-------(2)--------->
[rates 10MB for requested
service]
Access Accept
{RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB,
COST INFORMATION= 0.6 euros
per MB}}
<----------(3)--------------
AoC is delivered
<------(4)-------
Figure 23: Example message flow with price enquiry (advice of charge)
Please refer to Section 2.7.2 for an explanation of this message
flow.
A.6. Balance check
End User PPC PPS
Access Request
{RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB,
REQ_ACT=BALANCE CHECK}}
-------(2)--------->
[rates requested
Service and checks
remaining funds]
Access Accept
{RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB,
BALANCE_CHECK_RESULT}}
<----------(3)--------------
Figure 24: Example message flow with balance check
Please refer to Section 2.7.3 for an explanation of this message
flow.
Appendix B. Translation between RADIUS Prepaid and Diameter Credit
Control
In scenarios where the service metering device uses the "RADIUS In scenarios where the service metering device uses the "RADIUS
prepaid" (RPP) protocol for accounting and prepaid charging while the prepaid" (RPP) protocol for accounting and prepaid charging while the
AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol,
a translation agent that enables the interoperation of both systems, a translation agent that enables the interoperation of both systems,
is desirable. This also applies vice versa, i.e. in scenarios where is desirable. This also applies vice versa, i.e., in scenarios where
the AAA infrastructure uses RADIUS and the service metering device the AAA infrastructure uses RADIUS and the service metering device
uses Diameter. uses Diameter.
The idea of such a translation agent would be to convert incoming RPP The idea of such a translation agent would be to convert incoming RPP
(resp. DCC) messages into outgoing DCC (resp. RPP) messages. It (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It
would be, in principle, desirable for the translation agent to be would be, in principle, desirable for the translation agent to be
stateless. That is, the agent should not be required to internally stateless. That is, the agent should not be required to internally
maintain information about each ongoing RADIUS or Diameter session. maintain information about each ongoing RADIUS or Diameter session.
However, under the current specification of RPP and DCC, this appears However, under the current specification of RPP and DCC, this appears
to be impossible due to a number of reasons. These include the to be impossible due to a number of reasons. These include the
skipping to change at page 44, line 41 skipping to change at page 67, line 42
2. While RPP messages encode the cumulative amount of consumed/ 2. While RPP messages encode the cumulative amount of consumed/
requested resources, DCC messages carry the difference from the requested resources, DCC messages carry the difference from the
previous message. This means that the translation agent has to previous message. This means that the translation agent has to
maintain the current amount of consumed/requested resources in maintain the current amount of consumed/requested resources in
order to be able to calculate the correct amount to be put into order to be able to calculate the correct amount to be put into
an outgoing message. an outgoing message.
The translator maps each incoming RPP (resp. DCC) message into an The translator maps each incoming RPP (resp. DCC) message into an
outgoing DCC (resp. RPP) message, and possibly establishes or updates outgoing DCC (resp. RPP) message, and possibly establishes or updates
local state that is associated with the session. The translated local state that is associated with the session. The translated
(i.e. outgoing) message is a function of the incoming message as well (i.e., outgoing) message is a function of the incoming message as
as existing state that is associated with the current session. well as existing state that is associated with the current session.
Translation occurs on an attribute-by-attribute basis. Certain Translation occurs on an attribute-by-attribute basis. Certain
attributes are translated without consideration of local per-session attributes are translated without consideration of local per-session
state. Other attributes, namely those that are bound to a particular state. Other attributes, namely those that are bound to a particular
session, require such consideration. The translation agent has to session, require such consideration. The translation agent has to
identify the session (and possibly subsession) an incoming message identify the session (and possibly subsession) an incoming message
belongs to in order to consult the appropriate local per-session belongs to in order to consult the appropriate local per-session
state. state.
Note that certain DCC attributes cannot be translated due to their Note that certain DCC attributes cannot be translated due to their
semantics not being present in RPP, and vice versa. This results in semantics not being present in RPP, and vice versa. This results in
the messages, in which these attributes occur, not being delivered to the messages, in which these attributes occur, not being delivered to
their intended destination. In such cases it is desirable to inform their intended destination. In such cases it is desirable to inform
the originator about the failure and terminate the session. the originator about the failure and terminate the session.
In each scenario (i.e. RPP client / DCC AAA infrastructure and DCC In each scenario (i.e., RPP client / DCC AAA infrastructure and DCC
client / RPP AAA infrastructure), the translator operates in two client / RPP AAA infrastructure), the translator operates in two
directions, namely RPP to DCC and vice versa. In the following directions, namely RPP to DCC and vice versa. In the following
sections, the notation c->s means that the attribute in question may sections, the notation c->s means that the attribute in question may
occur only in the direction from the client to the server. The occur only in the direction from the client to the server. The
notation s->c denotes the converse and the notation c<->s denotes notation s->c denotes the converse and the notation c<->s denotes
that the attribute may occur in messages that are directed in either that the attribute may occur in messages that are directed in either
direction. direction.
5.1. Session Identification B.1. Session Identification
The translation agent has to keep per-session state in order to The translation agent has to keep per-session state in order to
perform its task. A session may be identified based on the RPP perform its task. A session may be identified based on the RPP
identifier or the DCC session identifier. That is, the translation identifier or the DCC session identifier. That is, the translation
agent should always maintain a pair of (RPP, DCC) session identifiers agent should always maintain a pair of (RPP, DCC) session identifiers
and maintain the per-session state in association with that pair. and maintain the per-session state in association with that pair.
This per-session state must be addressable by either of these two This per-session state must be addressable by either of these two
identifiers. Moreover, an RPP session identifier must uniquely identifiers. Moreover, an RPP session identifier must uniquely
correspond to a DCC identifier. (If this holds, the converse also correspond to a DCC identifier. (If this holds, the converse also
holds.) Each subsession identifier within an RPP session must also holds.) Each subsession identifier within an RPP session must also
uniquely correspond to a subsession identifier within its uniquely correspond to a subsession identifier within its
corresponding DCC session. (If this holds the converse also holds.) corresponding DCC session. (If this holds the converse also holds.)
5.2. Translation between RADIUS prepaid client and Diameter Credit B.2. Translation between RADIUS Prepaid and Diameter Credit Control
Control AAA infrastructure
This section describes the translator in the "RPP client / DCC AAA This section describes the translator in the "RPP client / DCC AAA
infrastructure" case. In other words, in this section it is assumed infrastructure" case. In other words, in this section it is assumed
that the client "talks" RPP and the AAA inftrastructure "talks" DCC. that the client "talks" RPP and the AAA inftrastructure "talks" DCC.
The translator is assumed to sit somewhere in the middle and to The translator is assumed to sit somewhere in the middle and to
mediate between client and server. mediate between client and server.
For each RPP AVP (i.e. AVP that is specified in the present For each RPP AVP (i.e., AVPs that are specified in the present
document), the transformation into a semantically equivalent DCC AVP document), the transformation into a semantically equivalent DCC AVP
(if such an AVP exists), along with what per-session state the (if such an AVP exists), along with what per-session state the
translator has to create or consult, is described. For clarity of translator has to create or consult, is described. For clarity of
exposition, each RPP AVP is addressed in a separate subsection. exposition, each RPP AVP is addressed in a separate subsection.
Since in this scenario, the PPC is typically the initiator a session, Since in this scenario, the PPC is typically the initiator a session,
the focus is on the RPP AVPs. the focus is on the RPP AVPs.
5.2.1. PPAC (c<->s) B.2.1. PPAC (c<->s)
A DCC client is assumed to always support Volume metering, Duration A DCC client is assumed to always support Volume metering, Duration
metering, Resource metering, Pools, Rating groups, and Tariff metering, Resource metering, Pools, Rating groups, and Tariff
Switching. Thus, if a PPAQ that indicates any of the above is sent Switching. Thus, if a PPAQ that indicates any of the above is sent
client->server, the translator does the following: It lets message go client->server, the translator does the following: It lets message go
through but remembers what exactly the client supports. If the through but remembers what exactly the client supports. If the
server later requests (servier -> client direction) an unsupported server later requests (servier -> client direction) an unsupported
metering to be performed, send failure to server and cause the metering to be performed, send failure to server and cause the
session to be terminated at the client. session to be terminated at the client.
If a PPAC indicates support for multiple services (0x00000020), the If a PPAC indicates support for multiple services (0x00000020), the
translator maps this onto a DCC Multiple-Services- Indicator AVP. translator maps this onto a DCC Multiple-Services- Indicator AVP.
5.2.2. Service Termination Attribute (c->s) B.2.2. Service Termination Attribute (c->s)
The Diameter base protocol assumes that the client always supports The Diameter base protocol assumes that the client always supports
dynamic session termination. If this AVP is present, the translator dynamic session termination. If this AVP is present, the translator
does not need to do anything, i.e. there exists no DCC AVP that this does not need to do anything, i.e., there exists no DCC AVP that this
AVP can be mapped to. If this AVP is absent, the message in which it AVP can be mapped to. If this AVP is absent, the message in which it
appears should either be discarded and originator should be informed appears should either be discarded and originator should be informed
of a failure, or the message can be passed on (without this AVP being of a failure, or the message can be passed on (without this AVP being
mapped onto a DCC AVP). However, in the latter case, the translator mapped onto a DCC AVP). However, in the latter case, the translator
has to remember that the client does not support dynamic termination. has to remember that the client does not support dynamic termination.
Thus, the translatior has to initiate the normal session termination Thus, the translatior has to initiate the normal session termination
procedure with the client when (if) dynamic termination is later procedure with the client when (if) dynamic termination is later
initiated by the server. initiated by the server.
5.2.3. Quota Identifier Attribute (c<->s) B.2.3. Quota Identifier Attribute (c<->s)
When quota is allocated for the first time by the DCC server, the When quota is allocated for the first time by the DCC server, the
translator has to create a QID AVP, as required by this translator has to create a QID AVP, as required by this
specification. The translator later uses a QID AVP that is sent in specification. The translator later uses a QID AVP that is sent in
the client-to-server direction in order to identify the corresponding the client-to-server direction in order to identify the corresponding
DCC session. The QID has to be saved in the translator's per session DCC session. The QID has to be saved in the translator's per session
state. state.
5.2.4. Volume Quota Attribute (c<->s) B.2.4. Volume Quota Attribute (c<->s)
If this AVP occurs in a message that is sent in the server-to-client If this AVP occurs in a message that is sent in the server-to-client
direction, it is translated into a Granted-Service-Unit AVP with an direction, it is translated into a Granted-Service-Unit AVP with an
embedded CC-Total-Octets AVP. [editor's note: this sentence belongs embedded CC-Total-Octets AVP.
to the other translation type, i.e. AAA = RPP and client = DCC.]
If this AVP occurs in a message that is sent in the client-to-server If this AVP occurs in a message that is sent in the client-to-server
direction, then it is translated into a Used-Service-Unit AVP with an direction, then it is translated into a Used-Service-Unit AVP with an
embedded CC-Total-Octets AVP. Note that only the difference between embedded CC-Total-Octets AVP. Note that only the difference between
current cumulative quota for the (sub)session and the quota in current cumulative quota for the (sub)session and the quota in
incoming messages is indicated in the translated DCC message. Local incoming messages is indicated in the translated DCC message. Local
state is updated with cumulative consumed resources. state is updated with cumulative consumed resources.
Conversely, if the server grants quota using the DCC Granted-Service- Conversely, if the server grants quota using the DCC Granted-Service-
Unit AVP with an embedded CC-Total-Octets AVP, then the translation Unit AVP with an embedded CC-Total-Octets AVP, then the translation
agent must translate this into a Volume Quota Attribute. Again, agent must translate this into a Volume Quota Attribute. Again,
local state must be consulted so that the cumulative amount of octets local state must be consulted so that the cumulative amount of octets
is indicated in the Volume Quota attribute. is indicated in the Volume Quota attribute.
5.2.5. Duration Quota Attribute (c<->s) B.2.5. Duration Quota Attribute (c<->s)
If this AVP occurs in a message that is sent in the server-to-client If this AVP occurs in a message that is sent in the server-to-client
direction, it is translated into a Granted-Service-Unit AVP with an direction, it is translated into a Granted-Service-Unit AVP with an
embedded CC-Time AVP. [editor's note: this sentence belongs to the embedded CC-Time AVP.
other translation type, i.e. AAA = RPP and client = DCC.]
If this AVP occurs in a message that is sent in the client-to-server If this AVP occurs in a message that is sent in the client-to-server
direction, then it is translated into a Used-Service-Unit AVP with an direction, then it is translated into a Used-Service-Unit AVP with an
embedded CC-Time AVP. Note that only the difference between current embedded CC-Time AVP. Note that only the difference between current
cumulative quota for the (sub)session and the quota in incoming cumulative quota for the (sub)session and the quota in incoming
messages is indicated in the translated DCC message. Local state is messages is indicated in the translated DCC message. Local state is
updated with cumulative consumed resources (i.e. time). updated with cumulative consumed resources (i.e., time).
Conversely, if the server grants quota using the DCC Granted-Service- Conversely, if the server grants quota using the DCC Granted-Service-
Unit AVP with an embedded CC-Time AVP, then the translation agent Unit AVP with an embedded CC-Time AVP, then the translation agent
must translate this into a Duration Quota attribute. Again, local must translate this into a Duration Quota attribute. Again, local
state must be consulted so that the cumulative amount of seconds is state must be consulted so that the cumulative amount of seconds is
indicated in the Duaration Quota attribute. indicated in the Duaration Quota attribute.
5.2.6. Resource Quota Attribute (c<->s) B.2.6. Resource Quota Attribute (c<->s)
If this AVP occurs in a message that is sent in the server-to-client If this AVP occurs in a message that is sent in the server-to-client
direction, it is translated into a Granted-Service-Unit AVP with an direction, it is translated into a Granted-Service-Unit AVP with an
embedded CC-Service-Specific-Units AVP. [editor's note: this sentence embedded CC-Service-Specific-Units AVP.
belongs to the other translation type, i.e. AAA = RPP and client =
DCC.]
If this AVP occurs in a message that is sent in the client-to-server If this AVP occurs in a message that is sent in the client-to-server
direction, then it is translated into a Used-Service-Unit AVP with an direction, then it is translated into a Used-Service-Unit AVP with an
embedded CC-Service-Specific-Units AVP. Note that only the embedded CC-Service-Specific-Units AVP. Note that only the
difference between current cumulative quota for the (sub)session and difference between current cumulative quota for the (sub)session and
the quota in incoming messages is indicated in the translated DCC the quota in incoming messages is indicated in the translated DCC
message. Local state is updated with cumulative consumed resources message. Local state is updated with cumulative consumed resources
(i.e. resources). (i.e., resources).
Conversely, if the server grants quota using the DCC Granted-Service- Conversely, if the server grants quota using the DCC Granted-Service-
Unit AVP with an embedded CC-Service-Specific-Units AVP, then the Unit AVP with an embedded CC-Service-Specific-Units AVP, then the
translation agent must translate this into a Resource Quota translation agent must translate this into a Resource Quota
attribute. Again, local state must be consulted so that the attribute. Again, local state must be consulted so that the
cumulative amount of resource units is indicated in the Resource cumulative amount of resource units is indicated in the Resource
Quota attribute. Quota attribute.
Note that the "resource" type is application dependent. This means Note that the "resource" type is application dependent. This means
that a DCC application unit corresponds to n RPP application units, that a DCC application unit corresponds to n RPP application units,
where n may be any real number. If n is not 1, then the RPP/DCC where n may be any real number. If n is not 1, then the RPP/DCC
translator must be aware of that and translate resource units translator must be aware of that and translate resource units
accordingly. accordingly.
5.2.7. Value Digits Attribute (c<->s) B.2.7. Value Digits Attribute (c<->s)
The encoding of this AVP is similar in RPP and DCC, and the value it The encoding of this AVP is similar in RPP and DCC, and the value it
holds may have to be evaluated in conjunction with an acommpanying holds may have to be evaluated in conjunction with an acommpanying
"Exponent" AVP. It should be kept in mind that, in RPP the "Exponent" AVP. It should be kept in mind that, in RPP the
cumulative amount of granted/consumed quota is typically encoded into cumulative amount of granted/consumed quota is typically encoded into
an AVP of this type, while in DCC only the difference from a previous an AVP of this type, while in DCC only the difference from a previous
message. message.
5.2.8. Exponent Attribute (c<->s) B.2.8. Exponent Attribute (c<->s)
The encoding of this AVP is similar in RPP and DCC, and the value it The encoding of this AVP is similar in RPP and DCC, and the value it
holds may have to be evaluated in conjunction with an acommpanying holds may have to be evaluated in conjunction with an acommpanying
"Value Digits" AVP. It should be kept in mind that, in RPP the "Value Digits" AVP. It should be kept in mind that, in RPP the
cumulative amount of granted/consumed quota is typically encoded into cumulative amount of granted/consumed quota is typically encoded into
a related "Value Digits" and "Exponent" AVP pair, while in DCC only a related "Value Digits" and "Exponent" AVP pair, while in DCC only
the difference from a previous message is encoded into such a pair. the difference from a previous message is encoded into such a pair.
5.2.9. Volume/Duration/Resource Threshold Attributes (s->c) B.2.9. Volume/Duration/Resource Threshold Attributes (s->c)
In DCC the concept of "threshold" does not exist. Instead, the DCC In DCC the concept of "threshold" does not exist. Instead, the DCC
client is assumed to ask for the replenishment of quota in good time. client is assumed to ask for the replenishment of quota in good time.
In RPP, on the other hand, the server may optionally include a In RPP, on the other hand, the server may optionally include a
threshold AVP, as an indication to the PPC about when to ask for threshold AVP, as an indication to the PPC about when to ask for
quota replenishment. quota replenishment.
Thus, in this scenario, there is no need for the translator to ever Thus, in this scenario, there is no need for the translator to ever
include a threshold attribute into the messages that it sends to the include a threshold attribute into the messages that it sends to the
PPC. If, however, there is a need for a threshold attribute to be PPC. If, however, there is a need for a threshold attribute to be
present in order to avoid a possible service provision present in order to avoid a possible service provision
5.2.10. Update Reason Attribute (c->s) B.2.10. Update Reason Attribute (c->s)
The DCC AVP that is semantically closer to the Update Reason AVP than The DCC AVP that is semantically closer to the Update Reason AVP than
any other AVP is the CC-Request-Type AVP. This AVP indicates whether any other AVP is the CC-Request-Type AVP. This AVP indicates whether
the message is which it appears is intended to indicate an "initial", the message is which it appears is intended to indicate an "initial",
an "intermediate" or a "final interrogation". Morever, in case of an "intermediate" or a "final interrogation". Morever, in case of
the session being terminated at the client, it indicates the reason the session being terminated at the client, it indicates the reason
for this termination. for this termination.
The following list lists the possible values of an "Update Reason" The following list lists the possible values of an "Update Reason"
attribute, along with corresponding values for the CC-Request-Type attribute, along with corresponding values for the CC-Request-Type
skipping to change at page 50, line 7 skipping to change at page 73, line 7
"TERMINATION_REQUEST". "TERMINATION_REQUEST".
o One-Time Charging: Such an Update Reason indicates that a one-time o One-Time Charging: Such an Update Reason indicates that a one-time
charging event is initiated by the client. The corresponding charging event is initiated by the client. The corresponding
value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a
"Requested-Action: AVP MUST also be included in the outgoing DCC "Requested-Action: AVP MUST also be included in the outgoing DCC
message. Typically, this would be of the type "DIRECT_DEBITING", message. Typically, this would be of the type "DIRECT_DEBITING",
or "REFUND_ACCOUNT", depending on other AVPs present in the or "REFUND_ACCOUNT", depending on other AVPs present in the
message. message.
5.2.11. PrepaidServer Attribute (s<->c) B.2.11. PrepaidServer Attribute (s<->c)
The PPC typically never sets the value of a PrepaidServer attribute. The PPC typically never sets the value of a PrepaidServer attribute.
Instead, it repeats those values that it receives from the AAA Instead, it repeats those values that it receives from the AAA
infrastructure, in this scenario from the translator. This attribute infrastructure, in this scenario from the translator. This attribute
is therefore not used in a translation scenario. Nevertheless, the is therefore not used in a translation scenario. Nevertheless, the
translator must make sure that messages about the same RPP session translator must make sure that messages about the same RPP session
are forwarded to the same DCC server, throughout the whole session. are forwarded to the same DCC server, throughout the whole session.
This may be easy to guarantee since the transport of Diameter is TCP. This may be easy to guarantee since the transport of Diameter is TCP.
5.2.12. Service-ID Attribute (s<->c) B.2.12. Service-ID Attribute (s<->c)
The DCC equivalent of a RPP "Service-ID" AVP is the combination of The DCC equivalent of a RPP "Service-ID" AVP is the combination of
Service-Context-Id and Service-Identifier AVPs. The translator must Service-Context-Id and Service-Identifier AVPs. The translator must
keep a static equivalence table of the RPP Service-ID and the keep a static equivalence table of the RPP Service-ID and the
corresponding DCC combination in order to correctly translate an RPP corresponding DCC combination in order to correctly translate an RPP
service identifier into DCC and back. service identifier into DCC and back.
5.2.13. Rating-Group-ID Attribute (s<->c) B.2.13. Rating-Group-ID Attribute (s<->c)
The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a
"Rating-Group-ID". Depending on the configuration, this AVP may "Rating-Group-ID". Depending on the configuration, this AVP may
contain the same value on both the RPP and the DCC side of the contain the same value on both the RPP and the DCC side of the
communication. If, however, static rating groups are configured communication. If, however, static rating groups are configured
between the RCC client and the translator, and different rating between the RCC client and the translator, and different rating
groups between the DCC server and the translator, then the translator groups between the DCC server and the translator, then the translator
has to maintain a static translation table for the rating group has to maintain a static translation table for the rating group
identifier. In any case, the translation of a rating group AVP, is identifier. In any case, the translation of a rating group AVP, is
not a function of the translator's local per-session state. not a function of the translator's local per-session state.
5.2.14. Termination-Action Attribute (s->c) B.2.14. Termination-Action Attribute (s->c)
The DCC equivalent of the "Termination-Action" AVP is called the The DCC equivalent of the "Termination-Action" AVP is called the
"Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA
infrastructure), a DCC "Final-Unit-Action" AVP is translated into a infrastructure), a DCC "Final-Unit-Action" AVP is translated into a
"Termination-Action" AVP. The following list contains the possible "Termination-Action" AVP. The following list contains the possible
"Final-Unit-Action" values along with their "Termination-Action" "Final-Unit-Action" values along with their "Termination-Action"
equivalent. equivalent.
o TERMINATE (DCC): This value has a direct equivalent in RPP, also o TERMINATE (DCC): This value has a direct equivalent in RPP, also
called "Terminate". called "Terminate".
skipping to change at page 51, line 23 skipping to change at page 74, line 23
internet-drafts/draft-ietf-radext-ieee802-00.txt). internet-drafts/draft-ietf-radext-ieee802-00.txt).
o In the absence of a "Final-Unit-Action" AVP, the DCC server o In the absence of a "Final-Unit-Action" AVP, the DCC server
assumes that the DCC client will ask for replenishment of quota at assumes that the DCC client will ask for replenishment of quota at
some suitable time. In RPP, this is explicitly conveyed via a some suitable time. In RPP, this is explicitly conveyed via a
"Termination-Action" AVP with the value "Request More Quota". "Termination-Action" AVP with the value "Request More Quota".
Thus, in the absence of a "Final-Unit-Action" AVP, the translator Thus, in the absence of a "Final-Unit-Action" AVP, the translator
in this scenario appends such an AVP into the outgoing RPP in this scenario appends such an AVP into the outgoing RPP
message. message.
5.2.15. Pool-ID Attribute (s<->c) B.2.15. Pool-ID Attribute (s<->c)
The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID".
Typically, no translation needs to be done to the "Pool-ID" Typically, no translation needs to be done to the "Pool-ID"
attribute. attribute.
5.2.16. Multiplier Attribute (s<->c) B.2.16. Multiplier Attribute (s<->c)
The multiplier attribute, which is a pair of "Value-Digits" and The multiplier attribute, which is a pair of "Value-Digits" and
"Exponent" AVPs, typically needs no translation, since the value it "Exponent" AVPs, typically needs no translation, since the value it
carries (inside a "Value-Digits" and an "Exponent" AVP) represents carries (inside a "Value-Digits" and an "Exponent" AVP) represents
the rating of the service or rating group to which it refers, with the rating of the service or rating group to which it refers, with
respect to abstract units. As such, the same multiplier value would respect to abstract units. As such, the same multiplier value would
typically applyt be conveyed from a DCC server to an PPC, and vice typically applyt be conveyed from a DCC server to an PPC, and vice
versa. versa.
5.2.17. Requested-Action Attribute (c->s) B.2.17. Requested-Action Attribute (c->s)
The "Requested Action" AVP can be directly translated into its DCC The "Requested Action" AVP can be directly translated into its DCC
equivalent, which carries the same name. equivalent, which carries the same name.
1. Balance Check (PCC): CHECK_BALANCE (DCC) 1. Balance Check (PCC): CHECK_BALANCE (DCC)
2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC)
5.2.18. Check-Balance-Result Attribute (s->c) B.2.18. Check-Balance-Result Attribute (s->c)
This attribute carries only a binary value. Hence, its translation This attribute carries only a binary value. Hence, its translation
is straightforward. is straightforward.
5.2.19. Cost-Information Attribute (s->c) B.2.19. Cost-Information Attribute (s->c)
This attribute consists of a Value-Digits AVP, an Exponent AVP, a This attribute consists of a Value-Digits AVP, an Exponent AVP, a
Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise
exist in DCC, and carry identical semantics in the context of the exist in DCC, and carry identical semantics in the context of the
"Cost-Information" AVP. Thus, the translation of this attribute is "Cost-Information" AVP. Thus, the translation of this attribute is
straightforward. straightforward.
5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) B.2.20. VolumeUsedAfterTariffSwitch attribute (c->s)
This attribute carries the amount of octets that were consumed after This attribute carries the amount of octets that were consumed after
a tariff change. It always appears in a message with an accompanying a tariff change. It always appears in a message with an accompanying
PPAQ attribute in which the total amount of octets (i.e. those that PPAQ attribute in which the total amount of octets (i.e., those that
were consumed both before and after the tariff switch) is reported. were consumed both before and after the tariff switch) is reported.
Thus, the translation agent can compute the amount of octets that Thus, the translation agent can compute the amount of octets that
were consumed before the tariff change. were consumed before the tariff change.
In DCC, the two amounts, i.e. the octets that were consumed before a In DCC, the two amounts, i.e., the octets that were consumed before a
tariff change and those that were consumed afterwards, are reported tariff change and those that were consumed afterwards, are reported
in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs
have an embedded CC-Total-Octets AVP that indicates the appropriate have an embedded CC-Total-Octets AVP that indicates the appropriate
amount of octets. Furthermore, the Used-Service-Unit AVP that amount of octets. Furthermore, the Used-Service-Unit AVP that
carries the amount that was consumed before the tariff switch also carries the amount that was consumed before the tariff switch also
carries an embedded Tariff-Change-Usage AVP with the value carries an embedded Tariff-Change-Usage AVP with the value
UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP
that carries the amount that was consumed after the tariff switch that carries the amount that was consumed after the tariff switch
also carries an embedded Tariff-Change-Usage AVP with the value also carries an embedded Tariff-Change-Usage AVP with the value
UNIT_AFTER_TARIFF_CHANGE (1). UNIT_AFTER_TARIFF_CHANGE (1).
6. Security Considerations
The extended RADIUS protocol described in this document is subject to
a number of potential attacks, in a manner similar to the RADIUS
protocol without these extensions. It is recommended that IPsec be
employed to protect against certain of the attacks.
7. IANA Considerations
This document requires the assignment of new Radius attributes type
numbers for the following attributes. Prepaid-Accounting-Capability
(PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ),
QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT),
DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR),
PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID),
TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost-
Information (COST), Session-Termination-Capability (STC),
PrepaidTariffSwitch (PTS), TariffSwitchInterval (TSI) and others.
8. Acknowledgements
The authors would like to thank Christian Guenther for his valuable
insight and feedback and his active and ongoing contributions that he
provided throughout the development of this document.
9. References
9.1. Normative References
[1] Bradner, S., "RFC 2026: The Internet Standards Process --
Revision 3", October 1996.
[2] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[3] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865:
Remote Authentication Dial In User Server (RADIUS)", June 2000.
[4] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000.
[5] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS
Extensions", June 2000.
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and
I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol
Support", June 2000.
[7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba,
"RFC 3576: Dynamic Authorization Extensions to Remote
Authentication Dial-In User Service (RADIUS)", February 2003.
[8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "RFC 3748: Extensible Authentication Protocol",
June 2004.
9.2. Informative References
[9] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "RFC 4006: Diameter Credit Control Application",
August 2005.
Appendix A. Example flows
This section presents certain example flows that involve the RADIUS
prepaid extensions. By no means is the intent of this section to
specify or recommend business logic, rating strategies, and
application-level behaviour. The intent of this section is purely to
illustrate some fictive scenarios and the RADIUS prepaid message
flows that could be associated with these scenarios. The contents of
this section should be regarded as a collection of informative
examples that aim to provide guidance to implementors.
A.1. A simple flow
End user PPC AAA Server PPS
user logs on
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00011}
-------(2)-------->
RADIUS authentication
<--------------(3)---------------------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00011}
------(4)--------->
[allocates
5MB quota]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ = 5MB,
VTH = 4.5 MB}}
<-------(5)--------
forwards message
<-----(6)-----------
service provision/metering
-------(7)--------->
4.5 MB consumed
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ=4.5MB,
REASON=THRESHOLD REACHED}}
-------(8)--------->
forwards message
-------(9)------->
[allocates another 7MB
to the access service]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=12MB,
VTH = 11.5 MB}}
<----------(10)--------------
forwards message
<------(11)--------
user logs off
------(12)-------
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=7 MB,
REASON=ACCESS SERV TERMINATED}}
-------(13)--------->
forwards message
-------(14)------->
[reimburses
user account]
AA Response
{RADIUS BASE AVPS}
<------(15)--------
AA Response
{RADIUS BASE AVPS}
<------(16)--------
Figure 12: A simple example message flow
The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC
AVP. This AVP indicates that both duration-based and volume-based
metering is supported. However, it also indicated that multiple
services, rating groups and resource pools are not supported. Note
that, since this is not an "Authorize-Only" message, no PPAQ AVP with
Update Reason="initial request" is included (see Section 3.7.1). The
home AAA server then authenticates the user and authorizes the access
service, as is usual in RADIUS (3). Note that the PPAC AVP is
appended by the PPC in at least the last message that is sent to the
home AAA server during this possibly multiple-round exchange.
If authentication and authorization is successful (in this example
this is assumed), the home AAA server forwards the final Access
Request to the PPS (4). The PPS identifies the user's prepaid
account from the included base RADIUS AVPs, and determines the
capabilities of the PPC from the PPAC attribute. Assuming that
sufficient funds are available in the user's prepaid account, the PPS
reserves some of these and rates the service. In this example, the
PPS reserves, say, 2 Euros and determines that the access service is
rated at 0.4 Euro per MB. This results in 5 MB of quota being
granted. The PPS also determines that the PPC should ask for this
quota to be replenished once 4.5 MB have been consumed. Thus, it
creates an Access Accept message with a Volume-Threshold indication
of 4.5MB. It further associates the QuotaIdentifier QID=5 to this
quota reservation. This identifier can be used to later uniquely
identify the prepaid session, user, account, etc. The resulting
Access Accept message is sent to the home AAA server (5) and
forwarded to the PPC (6).
Upon reception of message (6), the PPC provides the access service to
the user and meters it accordingly.
At some point in time, the threshold is reached, i.e. 4.5MB of
"access service" have been consumed by the user. At that point, the
PPC generates an Authorize-Only Access Request that contains the
usual RADIUS attributes and a PPAQ AVPs that reports the amount of
consumed quota, and the request for replenishment, i.e. the Update-
Reason= THRESHOLD REACHED (8). Note that the QID in this message is
the same as the one previously received from the user's home AAA
server. This message is forwarded to the PPS (9).
Upon reception of message (9), the PPS identifies the user and his
account from the QID. In also determines that a prepaid session is
ongoing, and that enough credit remains in the prepaid account in
order for the access service to continue being provided. Since 4.5
MB have been consumed, the PPS subtracts 1.8 Euros from the user's
prepaid account. The PPS decides to reserve another 2.8 euros from
the user's account. (This results in 3 euros being reserved in total
at this point in time.) As the access service is rated at 0.4 euros
per MB, the PPS determines that another 7 MB of quota should be
granted. This results in a total cumulative quota allocation of 12
MB for the access service. The PPS further calculates the new
threshold value of 11.5 MB. Since this is a new quota reservation,
the PPS also allocates a new QuotaIdentifier to it, in this example
QID=8. The resulting RADIUS message is sent to the home AAA server
(10) and forwarded to the PPC (11).
Upon reception of message (11), the PPC updates its records and
continues provisioning access to the user. At some point the user
logs off (12). The PPC must then report how many resources were
consumed, so that the PPC can subtract the appropriate monetary
amount from the user's prepaid account. To this end the PPC
constructs an Authorize-Only Access Request message with a PPAQ AVPs
for the access service. In this example, 7 MB were consumed by the
access service in total. The PPC reports 7 MB its final message
(13). This is forwarded to the PPS (14) which correlates the report,
using the QID, to the previous session state. It determines, from
the previous records, that the access service had consumed another
4.5 MB before (as indicated in message (9)). This means that, of the
7 MB, only 3.5 MB have not yet been subtracted from the user's
account. Thus, the PPS subtracts another 1.4 euros from the user's
account and, since the session is to be terminated (REASON=ACCESS
SERVICE TERMINATED), releases any reserved monetary amount.
The PPS responds with an Access Response as required by the RADIUS
base specification (15). So does the home AAA server (16).
A.2. A flow with prepaid tariff switching
End user PPC AAA Server PPS
user logs on
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00111}
-------(2)-------->
RADIUS authentication
<--------------(3)---------------------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00011}
------(4)--------->
[allocates
20MB quota]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ = 20MB,
VTH = 18 MB}, PTS={
QID=5, PTS{TSI=300sec,
TITSU=6000sec}}
<-------(5)--------
forwards message
<-----(6)-----------
service provision/metering
-------(7)--------->
5900 seconds have passed
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ=14MB,
REASON=TITSU APPROACH.},
TSI={QID=5, VUATS=11MB}}
-------(8)--------->
forwards message
-------(9)------->
[allocates another 10MB
to the access service]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=30MB,
VTH = 28 MB},PTS={
QUD=8, PTS=95 sec}}
<----------(10)--------------
forwards message
<------(11)--------
user logs off
------(12)-------
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=17 MB,
REASON=ACCESS SERV TERMINATED},
PTS={QID=8, VUATS=2.5 MB}
-------(13)--------->
forwards message
-------(14)------->
[reimburses
user account]
AA Response
{RADIUS BASE AVPS}
<------(15)--------
AA Response
{RADIUS BASE AVPS}
<------(16)--------
Figure 13: Example message flow with Tariff Switch
The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC
AVP. This AVP indicates that both duration-based and volume-based
metering is supported, as well as tariff switching. The home AAA
server then authenticates and user and authorizes the access service,
as is usual in RADIUS (3). Note that the PPAC AVP is appended by the
PPC in at least the last message that is sent to the home AAA server
during this possibly multiple-round exchange.
If authentication and authorization is successful (in this example
this is assumed), the home AAA server forwards the final Access
Request to the PPS (4). The PPS identifies the user's prepaid
account from the included base RADIUS AVPs, and determines the
capabilities of the PPC from the PPAC attribute. In this example, it
is assumed that a tariff switch is about to occur in 300 seconds from
the current time. Suppose that the access service is currently rated
at 0.5 euros per MB and in the next tariff period it is rated at 0.6
euros per MB. Suppose further that a third tariff period is about to
start in 6000 seconds from current time and that that access service
is rated at 0.8 euros per MB in that period. The PPS then decides to
reserve 12 euros from the user's account. Since it is conceivable
that the user may consume all allocated quota in the (more expensive)
"0.6-euro" period, the PPS reserves 20 MB of quota, and determines a
threshold value of 18 MB. It constructs a Radius Access Accept
message with a PPAQ attribute that reflects these choices, and
carries a QuotaIdentifier QID=5. It further adds a PTS AVP in the
message which is linked to the PPAQ via the common QID value. The
PTS AVP contains a TSI attribute indicating that a tariff switch will
occur in 300 seconds. It also includes a TITSU attribute with the
value of 6000 seconds. This is included in order to make sure that
the PPC will report the consumed quota before the "2-euro" tariff
period will start. The message is sent to the AAA server (5) and
forwarded to the PPC (6).
Upon reception of message (6), the PPC provides the access service to
the user and meters it accordingly (7). It also keeps track of time.
That is, it remembers how many octets are consumed before and how
many after the tariff switch that will take place in 300 seconds.
In this example it is assumed that the user consumes the allocated
quota rather slowly. In particular, nearly 6000 seconds (the value
indicated by TITSU) pass without the threshold of 18 MB being
reached. The PPC notices this and must therefore report usage and
request the quota to be replenished despite the fact that the
threshold has not been reached. In this example, it decides to do so
100 seconds before the 6000 seconds are reached. To this end, it
constructs an Authorization Access Request message including a PPAQ
that indicates that 14 MB have been consumed up to now. It also
includes a PTS AVP in order to indicate, using the VUATS AVP, that 11
MB of these were consumed after the tariff switch. The message is
sent to the AAA server (8) and forwarded to the PPS (9).
The PPS can link the message to previous session state via the QID.
It now rates the consumed volume as follows. The 11 MB that were
consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros
and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS
subtracts the amount of 6.6+1.5=8.1 euros from the user's account,
which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved.
The PPS now determines that message (9) was sent in order to
replenish the quota for this prepaid session. This can be deduced
from the UPDATE REASON field, which indicates that the PPC sent this
message because the time indicated by the TITSU AVP is approacing.
The PPS now determines that enough credit remains in the user's
prepaid account in order for the access service to continue being
provided and decides to reserve another 8.9 euros from the user's
account. Since it is conceivable that the user will consume the 6
unused MB of quota from the previous allocation, as well as the
entire quota that is to be allocated now, entirely in the "0.8-euro"
period, the quota that should now be granted in addition to the
previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros
are being reserved in order to "cover the worst case scenario". The
fact that 0.9 euros are reserved for this purpose is due to the fact
that the unused 6 MB from the previous allocation correspond to 4.8
euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more
than the amount of funds that are still "reserved" from the previous
allocation. (After this reservation, the total amount of reserved
money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB
being consumed in the "0.8-euro" period.)
Since quotas are encoded in a cumulative way in RADIUS, the PPS
includes a VolumeQuota of 30 MB into the Access Accept message (10).
The PPS further calculates the new threshold value of 28 MB. Since
this is a new quota reservation, the PPS also allocates a new
QuotaIdentifier to it, in this example QID=8. The resulting RADIUS
message is sent to the home AAA server (10) and forwarded to the PPC
(11).
Upon reception of message (11), the PPC updates its records and
continues providing access to the user. At some point the user logs
off (12). The PPC must then report how many resources were consumed,
so that the PPC can subtract the appropriate monetary amount from the
user's prepaid account. To this end the PPC constructs an Authorize-
Only Access Request message with a PPAQ AVPs for the access service.
In this example, 17 MB were consumed by the access service in total.
The PPC reports 17 MB its final message (13). This is forwarded to
the PPS (14) which correlates the report, using the QID, to the
previous session state. It determines, from the previous records,
that the access service had consumed 14 MB before (as indicated in
message (9)). This means that, of the 17 MB, only the monetary
equivalent for 3 MB have not yet been subtracted from the user's
account. The PPS calculates how much should be deducted from the
user's account as follows. Since the VUATS AVP indicates that 2.5MB
were consumed after the tariff switch, only 0.5 MB were consumed
before that. Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8
= 3.6 euros. That is, the PPS subtracts 3.6 euros from the user's
prepaid account. Since the session has by now be terminated by the
PPC (REASON=ACCESS SERVICE TERMINATED), the PPS now releases any
reserved monetary amount, in this example 12.8 - 3.6 = 9.2 euros.
The PPS responds with an Access Response as required by the RADIUS
base specification (15). So does the home AAA server (16).
Remark: In this example, two tariff switches take place. In other
scenarios, of course, only one tariff switch may occur. In such
scenarios the TITSU AVP is not used.
A.3. Resource pools and Rating Groups
End user PPC AAA Server PPS
user logs on
------(1)--------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00101111}
-------(2)-------->
RADIUS authentication
<--------------(3)---------------------->
Access Request
{RADIUS BASE AVPS,
PPAC=00...00101111}
------(4)--------->
[allocates
5MB quota]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ = 5MB,
poolID=1,mult=1}}
<-------(5)--------
forwards message
<-----(6)-----------
service provision/metering
-------(7)--------->
user requests service A
-------(8)--------->
Access Request
{RADIUS BASE AVPS,PPAQ={
SID="A", RGROUP=1}}
-------(9)-------->
forwards message
-----(10)--------->
[allocates 50 min
quota]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=7, DQ=3000sec
poolID=1,RGROUP=1, SID="A"
mult=1747.63}}
<---------(11)---------------
forwards message
<----(12)--------
user requests service B
-------(13)-------->
Pool 1 close to exhaustion
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=5, VQ=4MB,
REASON=QUOTA REACHED,
PoolID=1, mult=1}
PPAQ={QID=7, DQ=3300sec
REASON=QUOTA REACHED,
PoolID=1, mult=1747.63,
SID="A",RGROUP=1}}
-------(14)--------->
forwards message
-------(15)------->
[allocates another
3 MB to access service
and 30 minutes to
service "A"]
Access Response
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=8MB,
PoolID=1, mult=1, RGROUP=1},
PPAQ={QID=9, DQ=4800sec
PoolID=1, mult=1747.63,
SID="A"}}
<----------(16)--------------
forwards message
<------(17)--------
user logs off
------(18)-------
Access Request
{RADIUS BASE AVPS,
PPAQ={QID=8, VQ=6.5MB,
REASON=ACCESS SERV TERMINATED,
PoolID=1, mult=1}
PPAQ={QID=9, DQ=5400sec
REASON=ACCESS SERV TERMINATED,
PoolID=1, mult=1747.63,
SID="A",RGROUP=1}}
-------(19)--------->
forwards message
-------(20)------->
[reimburses
user account]
AA Response
{RADIUS BASE AVPS
<------(21)--------
AA Response
{RADIUS BASE AVPS
<------(22)--------
Figure 14: Example message flow with resource pools and rating groups
The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC
AVP, indicating that multiple services, rating groups and resource
pools are supported. Note that, since this is not an "Authorize-
Only" message, no PPAQ AVP with Update Reason="initial request" is
included (see Section 3.7.1). The home AAA server then authenticates
the user and authorizes the access service, as is usual in RADIUS
(3). Note that the PPAC AVP is appended by the PPC in at least the
last message that is sent to the home AAA server during this possibly
multiple-round exchange.
If authentication and authorization is successful (in this example
this is assumed), the home AAA server forwards the final Access
Request to the PPS (4). The PPS identifies the user's prepaid
account from the included base RADIUS AVPs, and determines the
capabilities of the PPC from the PPAC attribute. Assuming that
sufficient funds are available in the user's prepaid account, the PPS
reserves some of these and rates the service. In this example, the
PPS reserves 5 Euros and determines that the access service is rated
at 1 Euro per MB. In anticipation that the user requests more
chargeable services throughout this prepaid session, and since this
is supported by the PPC, the PPS further associates a resource pool
with this reservation, in this example PoolID=1. The PPC also
specifies the multiplier = 1 for the access service. Note that,
since 5MB = 5242880 octets, 1 unit in the resource pool corresponds
to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents.
(However, the PPC does not need to know that.) Moreover, the PPS
associates the QuotaIdentifier QID=5 to this quota reservation. This
identifier can be used to later uniquely identify the prepaid
session, user, account, etc. The resulting Access Accept message is
sent to the home AAA server (5) and forwarded to the PPC (6).
Upon reception of message (6), the PPC provides the access service to
the user and meters it accordingly. That is, for every octet
consumed, the PPC subtracts 1 unit (since the multiplier is 1) from
the resouce pool with PoolID=1.
At some point in time, the user requests another chargeable service,
namely service A (8). The PPC generates an Authorize-Only Access
Request that contains the usual RADIUS attributes and the Service-ID
identifying service A (9). The PPC has determined that service A is
rated in an identical way as at least one more service. Thus,
service A has been configured to belong to a rating group, in this
example the group with Rating-Group-ID=1. This identifier is
included is message (9), which is then forwarded to the PPS (10).
Upon reception of message (10), the PPS identifies the user and his
account from the base RADIUS attributes, the fact that a prepaid
session is ongoing, and determines that enough credit remains in the
prepaid account in order for service A to be provided. The PPS also
determines that service A is rated at 0.10 euros per minute. The PPS
decides to reserve another 5 euros from the users account; this
corresponds to 50 minutes or, as encoded in the DurationQuota AVP,
3000 seconds. As service A draws from the same prepaid account as
the access service, the PPS associates this reservation with the same
resource pool as the previous reservation (QID=5), namely the pool
with PoolID=1. Note that, in order for the abstract units in the
pool to be consistent, the multiplier has to be 1747.63. This is
because each second corresponds to about 0.10 / 60 = 0.00167 euros,
which is about 1747.63 times the value of an abstract resource pool
unit, as this was determined by the first allocation of quota to the
pool (i.e. 0.000095367431640625 Eurocents). Since this is a new
quota reservation, the PPS also allocates a new QuotaIdentifier to
it, in this example QID=7. The resulting RADIUS message is sent to
the home AAA server (11) and forwarded to the PPC (12).
Upon reception of message (12), the PPC adjusts the units in resource
pool 1. That is, it first determines how much quota had been
allocated to service A in the past, and subtracts this from the quota
reservation found in the message. Since this is the first quota
reservation for service A, there is nothing to subtract. Thus, it
adds 3000 * 1747.63 = 5242890 units to the pool and remembers that
3000 seconds have been allocated to service A during this prepaid
session. The PPC then provides service A to the user, and meters it
against resource pool 1. That is, for every second it subtracts
1747.63 units from the pool.
At some point in time, the user requests service B (13). The PPC
determines that service B is rated exactly in the same way as service
A, i.e. that they belong to the same rating group, namely the one
with Rating-Group-ID=1. Since this rating group has been effectively
authorised by the allocation of quota with QID=7, the PPC provides
service B to the user immediately. It is rated in the same way as
service A, i.e. for every second provided, 1747.63 units are
subtracted from credit pool 1.
At some point in time, resource pool 1 is close to exhaustion. (For
example, the PPC may determine that the pool is "close to exhaustion"
when has less than 10% its initial amount of units.) At that point,
the PPC needs to ask for replenishment for the pool. Suppose that,
at that point in time, 4MB of "access service", 45 minutes of
"service A", and 10 minutes of "service B" were provided to the user.
Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304
+ 5767179 = 9961483 abstract service units from the pool. The PPC
constructs an Authorize-Only Access Request message that reports the
usage for the "access service" and "service A". This message
contains two PPAQ AVPS, is sent to the home AAA server (14) and
forwarded to the PPS (15). Note that is the message it appears that
"service A" has consumed more than it was allocated (i.e. 55 minutes
although only 50 minutes were initially allocated to it). This is
not a a problem since the PPS knows that "service A" was drawing from
the same pool as the "access service" and that the "access service"
did only consume 4 out of the 5 MB it was allocated.
Upon reception of message (15), the PPS subtracts 4 euros from the
user's account for the "access service" and another 5.5 euros for
"service A". (This includes the charge incurred by "service B" up to
that point in time, although the PPS is not aware of "service B"
being provisioned to the user.) The PPS then determines that
sufficient funds remain in the prepaid account in order for both
services to be continued. The PPS decides to reserve another 3MB for
the access service and 30 minutes for "service A". This corresponds
to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a
cumulative manner, the PPAQ attribute that grants the quota for the
"access service" contains a Volume-Quota AVP of 8MB (8388608 octets),
which is the 5MB that were initially allocated, plus the 3MB
allocated now. The resource pool identifier is, as previously,
PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants
quota for "service A" contains 4800 seconds (the initial 3000 plus
1800 that correspond to the 30 additional minutes). Again, the
PoolID=1 and multiplier=1747.63. The resulting Access Response
message is sent to the home AAA server (16) and forwarded to the PPC
(17).
When the PPC received message (17) it checks how much quota has been
allocated previously to the "access service". It finds that the
answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets)
that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets)
have not yet been added to resource pool 1. The PPC thus adds
3145728 abstract units to resource pool 1 (since the multiplier is
1). The PPC then acts similarly on the other PPAQ attribute that
exists in message (17). That is, the PPC determines that 3000
seconds of quota for "service A" had already been added to the pool.
Thus only 1800 out of the 4800 should be additionally added to the
pool. Since the applicable multiplier here is 1747.63, the PPC adds
further 3145734 abstract units to the pool 1.
The PPC then continues to provide the access service, "service A" and
"service B" to the user, and meters them against the pool, as
previously.
At some point the user logs off (18). The PPC must then report how
many resources were consumed, so that the PPC can subtract the
appropriate monetary amount from the user's prepaid account. To this
end the PPC constructs an Authorize-Only Access Request message with
two PPAQ AVPs; one for the access service and one for "service A".
Suppose that, in total, 6.5MB were consumed by the access service, 70
minutes were consumed by "service A" and 20 minutes by "service B".
The PPC reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds)
in its final message (19). This is forwarded to the PPS which
determines, from the previous records, that the access service
consumed another 2.5MB (since 4MB out of the 6.5MB were already
reported in message (15), and that "service A" consumed further 600
seconds. This corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros.
Thus, the PPS only subtracts 2.5 out of the 6 previously reserved
euros from the user's prepaid account and responds with an Access
Response as required by the RADIUS base specification.
The home AAA server likewise responds with an Access Response.
Authors' Addresses Authors' Addresses
Avi Lior Avi Lior
Bridgewater Systems Bridgewater Systems
303 Terry Fox Drive 303 Terry Fox Drive
Ottawa, Ontario Suite 100 Ottawa, Ontario Suite 100
Canada Canada
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
skipping to change at page 71, line 32 skipping to change at page 76, line 32
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
30 International Place, 3rd Floor 30 International Place, 3rd Floor
Tewksbury, MA 01876 Tewksbury, MA 01876
USA USA
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Hannes Tschofenig Hannes Tschofenig
Siemens Nokia Siemens Networks
Otto-Hahn Ring 6 Otto-Hahn Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: hannes.tschofenig@siemens.com Email: hannes.tschofenig@nsn.com
URI: http://www.tschofenig.com
Andreas Pashalidis Andreas Pashalidis
Siemens NEC
Otto-Hahn Ring 6 Kurfuersten-Anlage 36
Munich, Bavaria 81739 Heidelberg 69115
Germany Germany
Email: andreas.pashalidis@siemens.com Email: Andreas.Pashalidis@netlab.nec.de
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 72, line 29 skipping to change at page 77, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 319 change blocks. 
1878 lines changed or deleted 2054 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/