< draft-lior-radius-prepaid-extensions-12.txt		draft-lior-radius-prepaid-extensions-13.txt >
	RADEXT A. Lior		RADEXT A. Lior
	Internet-Draft Bridgewater Systems		Internet-Draft Bridgewater Systems
	Intended status: Informational P. Yegani		Intended status: Informational P. Yegani
	Expires: December 31, 2007 Cisco		Expires: August 28, 2008 Cisco
	K. Chowdhury		K. Chowdhury
	Starent Networks		Starent Networks
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	A. Pashalidis		A. Pashalidis
	NEC		NEC
	June 29, 2007		February 25, 2008
	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-12.txt		draft-lior-radius-prepaid-extensions-13.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 42 ¶		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 31, 2007.		This Internet-Draft will expire on August 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	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
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11		1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11
	2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14		2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14
	2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14		2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14
	2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14		2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14
	2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16		2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16
	2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17		2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17
	2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18		2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18
	2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19		2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19
	2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19		2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19
	2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19		2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19
	2.7.2. Service Price Enquiry . . . . . . . . . . . . . . . . 20		2.7.2. Resource Consumption Query . . . . . . . . . . . . . . 20
	2.7.3. Balance Check . . . . . . . . . . . . . . . . . . . . 20		2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 20
	2.7.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21		2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 21
			2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21
	3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22		3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22		3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22
	3.2. Authentication and Authorization Operation . . . . . . . . 22		3.2. Authentication and Authorization Operation . . . . . . . . 22
	3.3. Session Start Operation . . . . . . . . . . . . . . . . . 23		3.3. Session Start Operation . . . . . . . . . . . . . . . . . 24
	3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24		3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24
	3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 25		3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26
	3.5.1. Unsolicited Session Termination Operation . . . . . . 26		3.5.1. Unsolicited Session Termination Operation . . . . . . 26
	3.5.2. Unsolicited Change of Authorization Operation . . . . 26		3.5.2. Unsolicited Change of Authorization Operation . . . . 26
	3.6. Termination Operation . . . . . . . . . . . . . . . . . . 26		3.6. Termination Operation . . . . . . . . . . . . . . . . . . 27
	3.7. Operation Considerations for Multiple Services . . . . . . 27		3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27
	3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 27		3.8. Operation Considerations for Multiple Services . . . . . . 28
	3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 27		3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28
	3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 28		3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29
	3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 28		3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29
	3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 28		3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29
	3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 29		3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30
	3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 29		3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30
	3.7.8. Accounting Considerations . . . . . . . . . . . . . . 30		3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30
			3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31
	4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 31		4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 31		4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32
	4.2. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 32		4.2. Session Termination Attribute . . . . . . . . . . . . . . 33
	4.3. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 39		4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 33
			4.4. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 40
	5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 43		5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 43
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 44		6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
	7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 45		7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 45
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	8.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 46		8.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 46
	8.2. New Registry: Prepaid SubTypes . . . . . . . . . . . . . . 46		8.2. New Registry: Prepaid SubTypes . . . . . . . . . . . . . . 46
	8.3. New Registry: Update-Reason . . . . . . . . . . . . . . . 48		8.3. New Registry: Update-Reason . . . . . . . . . . . . . . . 48
	8.4. New Registry: Termination-Action . . . . . . . . . . . . . 48		8.4. New Registry: Termination-Action . . . . . . . . . . . . . 48
	8.5. New Registry: Requested-Action . . . . . . . . . . . . . . 48		8.5. New Registry: Requested-Action . . . . . . . . . . . . . . 48
	8.6. New Registry: Check-Balance-Result . . . . . . . . . . . . 49		8.6. New Registry: Check-Balance-Result . . . . . . . . . . . . 49
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	The requesting PPC meters the consumption of the service according to		The requesting PPC meters the consumption of the service according to
	the instructions provided by the PPS. After service completion, or		the instructions provided by the PPS. After service completion, or
	on reception of a subsequent request for service, the PPS deducts the		on reception of a subsequent request for service, the PPS deducts the
	corresponding amount of credit from the user account. When a user		corresponding amount of credit from the user account. When a user
	terminates an on-going service, the PPC informs the PPS with a		terminates an on-going service, the PPC informs the PPS with a
	suitable indication about the unused portion of the allocated quota.		suitable indication about the unused portion of the allocated 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.
	Service AAA and		Service
	Element Prepaid		Access Device Accounting
	+----------+ +---------+ Protocol +----------+		+----------+ +---------+ Protocol +------------+
	| End |<---->|+-------+|<------------>| Home AAA |		| End |<---->|+-------+|<------------>| Accounting |
	| User | +->|| PCC || | Server |		| User | +->|| PCC || | Server |
	| | | || Client||<----+ | (HAAA) |		| | | || ||<----+ | |
	+----------+ | |+-------+| | +----------+		+----------+ | |+-------+| | +------------+
	| +---------+ | Prepaid ^		| +---------+ |
	+----------+ | | Protocol|		+----------+ | |
	| End |<--+ | v		| End |<--+ |
	| User | | +----------+		| User | | +----------+
	+----------+ +------->| |		+----------+ +------->| |
	Prepapid | PPS |		Prepapid | PPS |
	Protocol | |		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 PPC 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 to		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 [RFC3576].		messages as per RFC 3576 [RFC3576].
	skipping to change at page 14, line 22 ¶		skipping to change at page 14, line 22 ¶
	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 ring tone. Some operators may want to distinguish		downloading a ring tone. Some operators may want to distinguish
	between these services and to charge them at different rates and		between these services and to charge them at different rates and
	meters them differently. Therefore, the prepaid solution needs to be		meters them differently. Therefore, the prepaid solution needs to be
	able to distinguish services, and allocate quota to the services		able to distinguish services, and allocate quota to the services
	using different unit types (time, volume) and allow for those quotas		using different unit types (time, volume) and allow for those quotas
	to be consumed at different rates.		to be consumed at different rates.
	+---------+ +---------+ +-------+		+---------+ +---------+ +-------+
	| | N 1 | | M 1 | |		| | 1 N | | 1 1 | |
	| Session |<---------->| Service |<---------->| Quota |		| Session |<---------->| Service |<---------->| Quota |
	| | | | | |		| | | | | |
	+---------+ +---------+ +-------+		+---------+ +---------+ +-------+
	Figure 2: Multiple services within a single session		Figure 2: Multiple services within a single session
	As shown in Figure 2, a session may be associated with multiple		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. It may, for example, be expressed as a 5-tuple {i.e.,		this document. It may, for example, be expressed as a 5-tuple {i.e.,
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	message flow that involves multiple services within a single session		message flow that involves multiple services within a single session
	is given in the Appendix A.		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
	PPC would then have to terminate the former service. Moreover, each		SAD would then have to terminate the former service. Moreover, it is
	service generates a certain amount of RADIUS prepaid traffic. In an		likely that each service generates a certain amount of RADIUS prepaid
	environment with many users and many chargeable services, this amount		traffic. In an environment with many users and charged services,
	of traffic may be considerable.		this amount of traffic may become a considerable overhead that could
			lead to inefficiency.
	To avoid a situation where several parallel (and typically also
	small) credit reservations must be made on the same account, and also
	to avoid unnecessary load on the prepaid server, it is possible to
	provide service units as a "resource pool". Resource pools enable
	the allocation of resources to multiple services of a session by
	allocating resources to a pool and have services draw their quota
	from the pool at a rate appropriate to that service. When the quota
	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
	parameter, which translates from service units of a specific type to
	the abstract service units in the pool.
	Figure 3 shows the concept of resource pools graphically.		One method to circumvent the above situation is to use a so-called
			"resource pool". Resource pools enable the allocation of resources
			to multiple services of a session by allocating resources to a pool
			and have services draw their quota from the pool at a rate
			appropriate to that service. When the quota that has been allocated
			to the pool is close to exhaustion, the entire pool (rather than
			individual services) is replenished.
	+---------+ +---------+ +----------+		+-----------+
	| | N 1 | | M 1 | |		| Service-A |-----+ +--------+
	| Service |<---------->| Quota |<---------->| Resource |		+-----------+ | Ma | |
	| | | | | Pool |		+-------->| |
	+---------+ +---------+ | |		| Pool |
	+----------+		+-------->| (1) |
			+-----------+ | Mb | |
			| Service-B |-----+ +--------+
			+-----------+
	Figure 3: Resource Pools		Figure 3: Resource pool example
	If S is the total service units within the pool, M1, M2, ..., Mn are		As shown in Figure 3, Service-A and Service-B are bound to Pool(1).
	the multipliers provided for services 1, 2, ..., n, and C1, C2, ...,		Ma and Mb are the pool multipliers (that are associated with
	Cn are the used resources within the session, then the pool credit is		Service-A and Service-B respectively) that determine the rate at
	exhausted and re-authorization MUST be sought when:		which Service-A and Service-B draw from the pool.
	C1*M1 + C2*M2 + ... + Cn*Mn >= S		The pool is initialized by taking the quota allocated to service n
			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
	The total credit in the pool, S, is calculated from the quotas, which		Poolr <= Ca*Ma + Cb*Mb + . . .,
	are currently allocated to the pool as follows:
	S = Q1*M1 + Q2*M2 + ... + Qn*Mn		Figure 4
	For example, if the rating parameter for service 1 is $1/MB and the		where Ca and Cb are resources consumed by Service-A and Service-B
	rating parameter for service 2 is $0.1/min, the multipliers could be		respectively.
	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		Note that the resources assigned to the pool are not associated with
	at $0.10 per minute. In this case if $5 worth of resources are		a metric. That is, Service-A can be rated at $1 per MB and Service-B
	allocated for service 1 to the pool and if Ma = 10, then 50 units		can rated at $0.10 per minute. In this case, if $5 worth of
	would be placed into the pool. If a further $5 are allocated for		resources are allocated for service-A to the pool and if Ma = 10,
	service 2 to the pool, then Mb=1 and 50 units are deposited into the		then 50 units would be placed into the pool. If a further $5 are
	pool. The pool would then have a sum of 100 units to be shared		allocated for service-B to the pool, then M=1 and 50 units are
	between the two services. The PPC would then meter the services such		deposited into the pool. The pool would then have a total sum of 100
	that each Mbyte used by service 1 will draw 10 units from the pool		units to be shared between the two services. The PPC would then
	and each minute used by service 2 will draw 1 unit from the pool.		mater the services such that each Mbyte used by Service-A will draw
			10 units from the pool and each minute used by Service-B will draw 1
			unit from the pool.
	2.3. Rating Groups		2.3. Rating Groups
	A Rating Group gathers a set of services, identified by a service		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/		identifier, and subject to the same cost and rating type (e.g., $0.1/
	minute).		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 concept of the Rating Group was		such complex rating functions, the concept of the Rating Group was
	introduced.		introduced.
	As shown in Figure 6, a Rating Group is associated with one or more		As shown in Figure 5, 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 +-------+ P 1 | |		+-----------+ N 1 | | M 1 | Resource Pool|
	| Service |<----->| Rating |<----->| Quota |<----->| Resource |		| Service-A +---------->| Rating Group |------>| or |
	| | | Group | +-------+ | Pool |		+-----------+ | | | Quota |
	+---------+ | | | |		+--------------+ +--------------+
	+---------+ +----------+
	Figure 6: Rating Group		Figure 5: 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 assign it		authorises the Rating Group by allocating a quota to it and assign it
	to a Resource Pool. When an additional service that belongs to an		to a Resource Pool. When an additional service that belongs to an
	already authorised Rating Group is instantiated, the PPC does not		already authorised Rating Group is instantiated, the PPC does not
	need to re-authorize this service. This effectively means that the		need to re-authorize this service. This effectively means that the
	PPC meters the service such that it draws from the already allocated		PPC meters the service such that it draws from the already allocated
	quota. Therefore, no RADIUS messages need to be exchanged in this		quota. Therefore, no RADIUS messages need to be exchanged in this
	case. This limits the amount of traffic between the PPC and the PPS.		case. This limits the amount of traffic between the PPC and the PPS.
	An example of a flow that uses Rating Groups is given in Appendix A.3		An example of a flow that uses Rating Groups is given in Appendix A.3
	2.4. Tariff Switching		2.4. Tariff Switching
	Tariff is the set of parameters defining the utilization charges for		Tariff is the set of parameters defining the utilization charges for
	the use of a particular service.		the use of a particular service.
	This mechanism is useful if, for example, as shown in Figure 7,		This mechanism is useful if, for example, as shown in Figure 6,
	traffic before 18:00 is rated at rate r1 and traffic after 18:00 is		traffic before 18:00 is rated at rate r1 and traffic after 18:00 is
	rated at rate r2. The mechanism requires the PPC to report usage		rated at rate r2. The mechanism requires the PPC to report usage
	before and after the switch occured.		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 7: Example of Tariff Switching		Figure 6: Example of Tariff Switching
	The PPC 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 that 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 has to specify		In situations with multiple tariff switches, the PPS has to specify
	the length of the tariff switch period using the		the length of the tariff switch period using the
	TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS		TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS
	attribute, as shown in Figure 8.		attribute, as shown in Figure 7.
	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 8: Multiple Tariff Switches		Figure 7: 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.
	For time based services, the quota is continuously consumed at the		For time based services, the quota is continuously consumed at the
	skipping to change at page 19, line 31 ¶		skipping to change at page 19, line 31 ¶
	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
	PPC. 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.7. One Time Event		2.7. One Time Event
	2.7.1. One-Time Charging		2.7.1. One-Time Charging
	One-time charging is a mode of operation of where the RADIUS prepaid		One-time charging is a mode of operation where the RADIUS prepaid
	extensions are used for charging of a service that is provided		extensions are used for charging of a service that is provided
	instansteneously. An example of such an event is the purchase of a		instansteneously. An example of such an event is the purchase of a
	ring tone. Subscription based services can also be modeled as a one-		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		time event. In this case the one-time service event is the purchase
	of a subscription.		of a subscription.
	For a given user, one-time charging may occur in parallel with other		For a given user, one-time charging may occur in parallel with other
	charging models. For example, the subscriber may be connected to the		charging models. For example, the subscriber may be connected to the
	Internet, which is metered (based on time or volume), while he also		Internet, which is metered (based on time or volume), while he also
	purchases a ring tone (a one-time-based event).		purchases a ring tone (a one-time-based event).
	skipping to change at page 20, line 14 ¶		skipping to change at page 20, line 14 ¶
	A PPC may decide to perform one-time charging and the PPC may need to		A PPC may decide to perform one-time charging and the PPC may need to
	authenticate the user before sending the relevant message to the		authenticate the user before sending the relevant message to the
	user's home AAA server (and to the PPS).		user's home AAA server (and to the PPS).
	Note that one-time charging can also be used to credit the prepaid		Note that one-time charging can also be used to credit the prepaid
	account. For example, the PPC can return resources to the subscriber		account. For example, the PPC can return resources to the subscriber
	by issuing a one-time charging request that includes the amount of		by issuing a one-time charging request that includes the amount of
	resources to be credited into the account.		resources to be credited into the account.
	2.7.2. Service Price Enquiry		2.7.2. Resource Consumption Query
			It should be possible for the PPS to query the PPC for the current
			resource consumption and to adjust the users 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 PPC. The PPS should have the ability to query the PPC and, if it
			has the spare resources, to reassign the quotas to the PPC and to the
			pending request. Note that the PPS does not know resource usage
			until the PPC request for more resources. This can be a long time.
			In the absence of this capability the PPS can minimize the effect of
			this phenomenon by allocating small quotas, a practice that results
			in more message exchanges.
			2.7.3. Service Price Enquiry
	The PPC may need to know the price of the service event. Services		The PPC may need to know the price of the service event. Services
	offered by application service providers whose prices are not known		offered by application service providers whose prices are not known
	in the PPC might exist. The end user might also want to get an		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.		estimation of the price of a service event before requesting it.
	A PPC issues a PPAQ to the PPS including the Requested-Action SubType		A PPC issues a PPAQ to the PPS including the Requested-Action SubType
	with the value set to "Price Enquiry" (2). The request includes		with the value set to "Price Enquiry" (2). The request includes
	enough information to identify the service, namely a Service-		enough information to identify the service, namely a Service-
	Identifier or a Rating-Group-Identifer.		Identifier or a Rating-Group-Identifer.
	The PPS calculates the cost of the requested service event, but it		The PPS calculates the cost of the requested service event, but it
	does not perform any account balance check or credit reservation from		does not perform any account balance check or credit reservation from
	the account.		the account.
	The estimated cost of the requested service event is returned to the		The estimated cost of the requested service event is returned to the
	PPS with a PPAQ in the Cost-Information SubType. The PPC may		PPS with a PPAQ in the Cost-Information SubType. The PPC may
	transfer the information to the end user as an advice of charge.		transfer the information to the end user as an advice of charge.
	More information regarding the price enquiry functionality is		More information regarding the price enquiry functionality is
	provided in Section 4.2.17 and in Section 4.2.19.		provided in Section 4.3.17 and in Section 4.3.19.
	2.7.3. Balance Check		2.7.4. Balance Check
	The PPC may only have to verify that the end user's account balance		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		covers the cost of a certain service without reserving any units from
	the account at the time of the inquiry. This method does not		the account at the time of the inquiry. This method does not
	guarantee that credit would be left when the PPC requests the		guarantee that credit would be left when the PPC requests the
	debiting of the account with a separate request.		debiting of the account with a separate request.
	A PPC issues a PPAQ to the PPS including the Requested-Action SubType		A PPC issues a PPAQ to the PPS including the Requested-Action SubType
	with the value set to "Balance Check" (1). The request includes		with the value set to "Balance Check" (1). The request includes
	enough information to identify the service, namely a Service-		enough information to identify the service, namely a Service-
	Identifier or a Rating-Group-Identifer.		Identifier or a Rating-Group-Identifer.
	The PPS makes the balance check, but it does not make any credit-		The PPS makes the balance check, but it does not make any credit-
	reservation from the account.		reservation from the account.
	The result of balance check, namely "Success" (1) or "Failure" (2),		The result of balance check, namely "Success" (1) or "Failure" (2),
	is returned to the PPC in the Check-Balance-Result SubType conveyed		is returned to the PPC in the Check-Balance-Result SubType conveyed
	in the PPAQ attribute from the PPS to the PPC.		in the PPAQ attribute from the PPS to the PPC.
	More information regarding the balance check functionality is		More information regarding the balance check functionality is
	provided in Section 4.2.17 and in Section 4.2.18.		provided in Section 4.3.17 and in Section 4.3.18.
	2.7.4. Refund		2.7.5. Refund
	Some services may refund service units to the end user's account; for		Some services may refund service units to the end user's account; for
	example, gaming services.		example, gaming services.
	To initiate refunding the PPC includes the PPAQ attribute in an		To initiate refunding the PPC includes the PPAQ attribute in an
	Access-Request packet and the amount (as a negative value) to be		Access-Request packet and the amount (as a negative value) to be
	refunded is specified using the Resource Quota and Resource Quota		refunded is specified using the Resource Quota and Resource Quota
	overflow subtypes. This functionality is similar to one-time		overflow subtypes. This functionality is similar to one-time
	charging with the difference that refunding uses negative values		charging with the difference that refunding uses negative values
	Information about the service need to be provided by the PPC to allow		Information about the service need to be provided by the PPC to allow
	service identification, namely the Service-ID field of the PPAQ		service identification, namely the Service-ID field of the PPAQ
	identifies the prepaid service.		identifies the prepaid service.
	Note that a monetary amount itself to be refunded is not provided but		Note that a monetary amount itself to be refunded is not provided but
	rather abstract units. Based on prior out-of-band agreements between		rather abstract units. Based on prior out-of-band agreements between
	the PPC and the PPS these abstract units are translated into a		the PPC and the PPS these abstract units are translated into a
	monetary amount.		monetary amount.
	More information regarding the refund functionality is provided in		More information regarding the refund functionality is provided in
	Section 3.7.6.		Section 3.8.6.
	3. Operations		3. Operations
	This section contains the normative text for the prepaid extension.		This section contains the normative text for the prepaid extension.
	3.1. Capability Discovery		3.1. Capability Discovery
	The PPC initiates the authentication and authorization procedure by		The PPC initiates the authentication and authorization procedure by
	sending a RADIUS Access-Request to the HAAA. Since the PPC MUST		sending a RADIUS Access-Request to the HAAA. Since the PPC MUST
	include a PPAC attribute in the RADIUS Access-Request. The PPAC		include a PPAC attribute in the RADIUS Access-Request. The PPAC
	attribute indicates to the PPS which prepaid capabilities are		attribute indicates to the PPS which prepaid capabilities are
	possessed by the PPC. These are required in order to complete the		possessed by the PPC. These are required in order to complete the
	prepaid authorization procedure.		prepaid authorization procedure.Moreover, if the PPC supports the
			Disconnect-Message or the Change-of-Authorization capabilities, then
			it SHOULD include the Session Termination attribute.
			In certain deployments, there may be other ways to terminate a data
			session, or change authorization of an active session. For example,
			some PPCs provide a session termination service via Telnet or SNMP.
			In these cases, the AAA server MAY add the Dynamic-Capabilities
			message to the Access-Request. Upon receiving the Change-of-
			Authorization message, the AAA server would then be responsible for
			terminating the session using the means that are supported by the
			device.
	If the authentication procedure involves multiple message exchanges		If the authentication procedure involves multiple message exchanges
	(as it is the case with EAP), the PPC MUST include the PPAC attribute		(as it is the case with EAP), the PPC MUST include the PPAC attribute
	in at least the last Access-Request of the authentication procedure.		in at least the last Access-Request of the authentication procedure.
	3.2. Authentication and Authorization Operation		3.2. Authentication and Authorization Operation
	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. If		determines whether or not the subscriber is a prepaid subscriber. If
	the subscriber is not a prepaid subscriber, then the HAAA responds as		the 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 MAY 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 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 PPCs		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 QID, which is set by the PPS to a unique value, is used to		o The QID, which is set by the PPS to a unique value, is used to
	correlate quota requests.		correlate quota requests.
	skipping to change at page 27, line 5 ¶		skipping to change at page 27, line 23 ¶
	In case the user logged off, or the PPC receives a Disconnect		In case the user logged off, or the PPC receives a Disconnect
	Message, the PPC 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 subytype, the PPC follows the		contained the Termination-Action subytype, the PPC follows the
	specified action.		specified action.
	3.7. Operation Considerations for Multiple Services		3.7. Mobile IP Operations
			In roaming scenarios with Mobile-IP, the prepaid data session should
			be maintained transparently if the HA is acting as the access device
			hosting the PPC. As the subscriber device associates with a new
			access service device (AP or PDSN that supports PPC capability), this
			service access device sends a RADIUS Access-Request and the
			subscriber is re-authenticated and reauthorized. The service access
			device SHALL include the PPAC 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 service access device before handoff,
			then 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 service
			access device, 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 service access device shall send an Access-Request
			message which is routed to the home network and SHALL 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 service
			access device SHALL 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 service access
			device sends the Authorize-Only Access-Request with PPAQ 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 service access device.
			Even if the subscriber moves to a service access device 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 service access
			device (i.e. metering). This scenario will be discussed in detail in
			a later version of this document.
			3.8. 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 PPC. 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 PPC 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 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 nor a		Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a
	Service-Id then the default service is used, i.e., the "Access		Service-Id then the default service is used, i.e., the "Access
	Service".		Service".
	3.7.1. Initial Quota Request		3.8.1. Initial Quota Request
	When operations with multiple services is desired then the PPC		When operations with multiple services is desired then the PPC
	requests the initial quota by sending a PPAQ containing the		requests the initial quota by sending a PPAQ containing the
	Service-Id in an Authorize-Only Access-Request packet for that		Service-Id in an Authorize-Only Access-Request packet for that
	service. Similarly, if the PPC 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". The Authorize-Only Access-Request message MAY contain more		Request". The Authorize-Only Access-Request message MAY contain more
	than one PPAQ.		than one PPAQ.
	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 Rating-Group-Id, unless the PPAQ is the		contain the Service-ID or Rating-Group-Id, unless the PPAQ is the
	generic "Access Service".		generic "Access Service".
	3.7.2. Quota Update		3.8.2. Quota Update
	Once the services start to utilize their allotted quota they will		Once the services start to utilize their allotted quota they will
	eventually need to replenish their quotas (either the threshold is		eventually need to replenish their quotas (either the threshold is
	reached or no more quota remains). 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 Rating-Group-Id (or neither the Service-ID or Rating-		Service-ID or Rating-Group-Id (or neither the Service-ID or Rating-
	Group-Id if the quota replenishment is for the "Access Service").		Group-Id if the quota replenishment is for the "Access Service").
	The Update-Reason filed indicates either "Threshold reached"(3), or		The Update-Reason filed indicates either "Threshold reached"(3), or
	"Quota reached"(4).		"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 the Rating-Group-Id, and a		PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a
	new QID. If the PPS does not grant additional quota for the service		new QID. If the PPS does not grant additional quota for the service
	it 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 PPC to take appropriate actions.		instruct the PPC to take appropriate actions.
	3.7.3. Termination		3.8.3. Termination
	When the allotted quota for a service is exhausted, the PPC shall act		When the allotted quota for a service is exhausted, the PPC shall act
	in accordance with the flags set in the Termination-Action subtype.		in accordance with the flags set in the Termination-Action subtype.
	If the Termination-Action subtype 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 PPC 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 "Access Service" has terminated, then all other services must		If the "Access Service" has terminated, then all other services must
	be terminated as well. In this case the PPC 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.8.4. Dynamic Operations
	Dynamic operations for multi-services are similar to dynamic		Dynamic operations for multi-services are similar to dynamic
	operations described for single service operations. The PPS MAY send		operations described for single service operations. The PPS MAY send
	a COA message containing a PPAQ for an existing service instance.		a COA message containing a PPAQ for an existing service instance.
	The PPC matches the PPAQ with the service using the Service-ID or the		The PPC matches the PPAQ with the service using the Service-ID or the
	Rating-Group-Id attribute. The new quota could differ from the		Rating-Group-Id attribute. The new quota could differ from the
	previously allocated value.		previously allocated value.
	A disconnect message terminates the "Access Service". As such the		A disconnect message terminates the "Access Service". As such the
	PPC 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 MAY 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.8.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 then the PPS may associate a quota with a		supported" bit in the PPAC then the PPS may associate a quota with a
	Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ.		Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ.
	When Resource Pools are used, the PPAQ MUST NOT use the threshold		When Resource Pools are used, the PPAQ MUST NOT use the threshold
	field.		field.
	3.7.6. One-time Charging		3.8.6. One-time Charging
	To initiate one-time charging the PPC includes the PPAQ attribute in		To initiate one-time charging the PPC includes the PPAQ attribute in
	an Access-Request packet. The Service-ID field of the PPAQ		an Access-Request packet. The Service-ID field of the PPAQ
	identifies the prepaid service. The amount to be charged is		identifies the prepaid service. The amount to be charged is
	specified using the Resource Quota and Resource Quota overflow		specified using the Resource Quota and Resource Quota overflow
	subtypes. If the value specified is negative then the resources are		subtypes. If the value specified is negative then the resources are
	credited to the user account. This functionality corresponds to		credited to the user account. This functionality corresponds to
	refunding.		refunding.
	The QID subtype MUST be set to a unique value and is used by the PPS		The QID subtype MUST be set to a unique value and is used by the PPS
	skipping to change at page 29, line 35 ¶		skipping to change at page 30, line 43 ¶
	charge the PPC MUST NOT allow the session to continue. Therefore,		charge the PPC MUST NOT allow the session to continue. Therefore,
	the RADIUS server SHOULD include in the Access-Accept a Session-		the RADIUS server SHOULD include in the Access-Accept a Session-
	Timeout set to 0. Upon receiving an Access-Accept response the PPC		Timeout set to 0. Upon receiving an Access-Accept response the PPC
	SHOULD generate an Accounting Stop 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.8.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.8.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		associated with prepaid data sessions should include the PPAQ
	attribute.		attribute.
	4. Attributes		4. Attributes
	This section specifies the attributes that implement the RADIUS		This section specifies the attributes that implement the RADIUS
	skipping to change at page 31, line 36 ¶		skipping to change at page 32, line 36 ¶
	LENGTH: 8		LENGTH: 8
	VALUE : Data type String		VALUE : Data type String
	The value field is encoded as follows:		The value field is encoded as follows:
	SubType : Value (1)		SubType : Value (1)
	Length : 6 or 10 octets		Length : 6 or 10 octets
	AvailableInClient (AiC): The bitmap is encoded as:		AvailableInClient (AiC): The bitmap is encoded as:
	Value | Description		Value | Description
	-------------+-------------------------------------		------------ -+-------------------------------------
	00000001 | Volume metering supported		0x00000001 | Volume metering supported
	00000010 | Duration metering supported		0x00000002 | Duration metering supported
	00000100 | Resource metering supported		0x00000004 | Resource metering supported
	00001000 | Pools supported		0x00000008 | Pools supported
	00010000 | Rating groups supported		0x00000010 | Rating groups supported
	00100000 | Multi-Services supported		0x00000020 | Multi-Services supported
	01000000 | Tariff Switch supported		0x00000040 | Tariff Switch supported
	10000000 | Extended AiC field		Others | Reserved
	If the Extended AiC flag is not set then the length		Figure 8: PPAC Attribute
	of this SubType is 6 octets. If the Extended AiC flag
	is, however, set then the length of this SubType is
	10 octects long and the subsequent 4 octects are
	available as shown below:
	AvailableInClient-Extended (AiC-ext):		4.2. Session Termination Attribute
	The bitmap is encoded as:		The value shall be bitmap encoded rather than a raw integer. This
			attribute shall be included RADIUS Access-Request message to the
			RADIUS server and indicates whether or not the NAS supports Dynamic
			Authorization.
	Value | Description		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
	00000001 | **Available via IANA registration**		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	00000010 | **Available via IANA registration**		| TYPE | LENGTH | String |
	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 9: PPAC Attribute		Type : value of Session Termination Capability
			Length: = 4
			String encoded as follows:
	4.2. Prepaid Accounting Operation (PPAQ) Attribute		0x00000001 Dynamic Authorization Extensions (rfc3576) is
			supported.
			Figure 9: Session Termination Attribute
			4.3. 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 to request further quota. It		for one-time charging, report usage and to request further quota. It
	is also used in order to request prepaid quota for a new service		is also used in order to request prepaid quota for a new 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.
	skipping to change at page 32, line 48 ¶		skipping to change at page 34, line 6 ¶
	Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes MUST		Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes MUST
	appear in the PPAQ attribute, except for the price enquiry message		appear in the PPAQ attribute, except for the price enquiry message
	exchange where these subtypes MUST be absent. A single PPAQ		exchange where these subtypes MUST be absent. A single PPAQ
	attribute MUST NOT contain more than one Service-Id, MUST NOT contain		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		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		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		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		contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST
	also contain a Pool-Multiplier SubType.		also contain a Pool-Multiplier SubType.
	The PPAQ attribute, as shown in Figure 10, has a variable length		The PPAQ attribute has a variable length (greater than 8, encoded
	(greater than 8, encoded into one octet), and consists of a variable		into one octet), and consists of a variable number of subtypes.
	number of subtypes. Unused subtypes are omitted from the message.		Unused subtypes are omitted from the message. In the following
	In the following subsections the various subtypes of the PPAQ		subsections the various subtypes of the PPAQ attribute are specified.
	attribute are specified.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TYPE : value of PPAQ
	LENGTH: variable
	VALUE : Data type String
	Each subattribute is then encoding in the following style:
	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		4.3.1. Quota Identifier (QID) SubType
	The value of the type field of the Quota Identifier (QID) SubType is		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		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		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		a PPAQ->QID subtype from the PPC to the PPS. This field has the
	semantic of a transaction identifier and therefore changes with every		semantic of a transaction identifier and therefore changes with every
	transaction initiated by the PPS to the PPC.		transaction initiated by the PPS to the PPC.
	4.2.2. VolumeQuota SubType		4.3.2. VolumeQuota SubType
	The value of the type field of the VolumeQuota SubType is TBD. The		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		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 PPC 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 (PPC 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 SubType and optionally an		attribute consists of a Value-Digits SubType and optionally an
	Exponent SubType (as indicated in the length field). The Exponent		Exponent SubType (as indicated in the length field). The Exponent
	SubType, if present, MUST NOT encode a negative number or zero.		SubType, if present, MUST NOT encode a negative number or zero.
	4.2.3. VolumeThreshold SubType		4.3.3. VolumeThreshold SubType
	The value of the type field of the VolumeThreshold SubType is TBD and		The value of the type field of the VolumeThreshold SubType is TBD and
	its length is 12 or 18 octets. This SubType 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 PPC		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 has to be consumed before a new quota is requested.		octets) that has to be consumed before a new quota is requested.
	This threshold MUST NOT be larger than the VolumeQuota. The		This threshold MUST NOT be larger than the VolumeQuota. The
	attribute consists of a Value-Digits SubType and optionally an		attribute consists of a Value-Digits SubType and optionally an
	Exponent SubType (as indicated by the length field). The Exponent		Exponent SubType (as indicated by the length field). The Exponent
	SubType, if present, MUST NOT encode a negative number or zero.		SubType, if present, MUST NOT encode a negative number or zero.
	4.2.4. DurationQuota SubType		4.3.4. DurationQuota SubType
	The value of the type field of the DurationQuota SubType is TBD and		The value of the type field of the DurationQuota SubType is TBD and
	its length is 6 octets. This optional SubType is only present if		its length is 6 octets. This optional SubType is only present if
	duration-based charging is used. In a RADIUS Access-Accept message		duration-based charging is used. In a RADIUS Access-Accept message
	(PPS to PPC direction), it indicates the duration (in seconds)		(PPS to PPC direction), it indicates the duration (in seconds)
	allocated for the session by the PPS. It is encoded as an integer.		allocated for the session by the PPS. It is encoded as an integer.
	In a RADIUS Access-Request message (PPC to PPS direction), it		In a RADIUS Access-Request message (PPC to PPS direction), it
	indicates the total duration (in seconds) since the start of the		indicates the total duration (in seconds) since the start of the
	accounting session related to the QID subtype of the PPAQ attribute		accounting session related to the QID subtype of the PPAQ attribute
	in which it occurs.		in which it occurs.
	4.2.5. DurationThreshold SubType		4.3.5. DurationThreshold SubType
	The value of the type field of the DurationThreshold SubType is TBD		The value of the type field of the DurationThreshold SubType is TBD
	and its length is 6 octets. This SubType shall optionally be present		and its length is 6 octets. This SubType shall optionally be present
	if the DurationQuota is present in a RADIUS Access-Accept message		if the DurationQuota is present in a RADIUS Access-Accept message
	(PPS to PPC direction). It represents the duration (in seconds)		(PPS to PPC direction). It represents the duration (in seconds)
	after which new quota should be requested. This threshold MUST NOT		after which new quota should be requested. This threshold MUST NOT
	be larger than the DurationQuota SubType. It is encoded as an		be larger than the DurationQuota SubType. It is encoded as an
	integer.		integer.
	4.2.6. ResourceQuota SubType		4.3.6. ResourceQuota SubType
	The value of the type field of the ResourceQuota SubType is TBD. The		The value of the type field of the ResourceQuota SubType is TBD. The
	length of this SubType is 12 or 18 octets. This optional SubType is		length of this SubType is 12 or 18 octets. This optional SubType is
	only 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 PPC 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 (PPC 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 SubType and optionally an		attribute consists of a Value-Digits SubType and optionally an
	Exponent SubType (as indicated by the length field).		Exponent SubType (as indicated by the length field).
	4.2.7. ResourceThreshold SubType		4.3.7. ResourceThreshold SubType
	The value of the type field of the ResourceThreshold SubType is TBD.		The value of the type field of the ResourceThreshold SubType is TBD.
	The length of this SubType is 12 or 18 octets. The semantics of this		The length of this SubType is 12 or 18 octets. The semantics of this
	SubType follow those of the VolumeThreshold and DurationThreshold		SubType follow those of the VolumeThreshold and DurationThreshold
	SubType. It consists of a Value-Digits SubType and optionally an		SubType. It consists of a Value-Digits SubType and optionally an
	Exponent SubType.		Exponent SubType.
	4.2.8. Value-Digits SubType		4.3.8. Value-Digits SubType
	The value of the type field of the Value-Digits SubType is TBD and		The value of the type field of the Value-Digits SubType is TBD and
	its length is 10 octets. This SubType encodes the most significant		its length is 10 octets. This SubType encodes the most significant
	digits of a number, encoded as an integer. If decimal values are		digits of a number, encoded as an integer. If decimal values are
	needed to present the number, the scaling MUST be indicated with a		needed to present the number, the scaling MUST be indicated with a
	related Exponent SubType. For example, the decimal number 0.05 is		related Exponent SubType. For example, the decimal number 0.05 is
	encoded by a Value-Digits SubType set to 5, and a scaling that is		encoded by a Value-Digits SubType set to 5, and a scaling that is
	indicated with the Exponent SubType set to -2.		indicated with the Exponent SubType set to -2.
	4.2.9. Exponent SubType		4.3.9. Exponent SubType
	The value of the type field of the Exponent SubType is TBD. The		The value of the type field of the Exponent SubType is TBD. The
	length of this SubType is 6 octets. This SubType contains the		length of this SubType is 6 octets. This SubType contains the
	exponent value that is to be applied to the accompanying Value-Digit		exponent value that is to be applied to the accompanying Value-Digit
	SubType. Its value is encoded as an integer.		SubType. Its value is encoded as an integer.
	4.2.10. Update-Reason SubType		4.3.10. Update-Reason SubType
	The value of the type field of the Update-Reason SubType is TBD. The		The value of the type field of the Update-Reason SubType is TBD. The
	length of this SubType is 4 octets. This SubType is present in a		length of this SubType is 4 octets. This SubType is present in a
	RADIUS Access-Request message (PPC to PPS direction) and indicates		RADIUS Access-Request message (PPC to PPS direction) and indicates
	the reason for initiating the quota update operation. Update reasons		the reason for initiating the quota update operation. Update reasons
	(6), (7), (8) and (9) indicate that the associated resources are		(6), (7), (8) and (9) indicate that the associated resources are
	released at the PPC side, and that therefore the PPS MUST NOT		released at the PPC side, and that therefore the PPS MUST NOT
	allocate a new quota in the RADIUS Access Accept message.		allocate a new quota in the RADIUS Access Accept message.
	The following values for the Update-Reason SubType are defined:		The following values for the Update-Reason SubType are defined:
	skipping to change at page 36, line 20 ¶		skipping to change at page 36, line 39 ¶
	3 | Threshold Reached		3 | Threshold Reached
	4 | Quota Reached		4 | Quota Reached
	5 | TITSU Approaching		5 | TITSU Approaching
	6 | Remote Forced Disconnect		6 | Remote Forced Disconnect
	7 | Client Service Termination		7 | Client Service Termination
	8 | "Access Service" Terminated		8 | "Access Service" Terminated
	9 | Service not established		9 | Service not established
	10 | One-Time Charging		10 | One-Time Charging
	11..255 | **Available for IANA registration**		11..255 | **Available for IANA registration**
	Figure 11: Values for Update-Reason SubType		Figure 10: Values for Update-Reason SubType
	4.2.11. PrepaidServer SubType		4.3.11. PrepaidServer SubType
	The value of the type field of the PrepaidServer SubType is TBD. The		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		length of this SubType is 6 or 18 octets, for IPv4 and IPv6 addresses
	respectively. This optional SubType indicates the address of the		respectively. This optional SubType indicates the address of the
	serving PPS. If present, the Home RADIUS server uses this address to		serving PPS. If present, the Home RADIUS server uses this address to
	route the message to the serving PPS. Multiple instances of this		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 MAY be present in a single PPAQ attribute. The value of this
	SubType is encoded as an address.		SubType is encoded as an address.
	If present in the PrepaidServer SubType of an incoming RADIUS Access-		If present in the PrepaidServer SubType of an incoming RADIUS Access-
	Accept message, the PPC returns this SubType back without modifying		Accept message, the PPC returns this SubType back without modifying
	it in the subsequent RADIUS Access-Request message. If multiple		it in the subsequent RADIUS Access-Request message. If multiple
	values are present, the PPC MUST NOT change their order.		values are present, the PPC MUST NOT change their order.
	4.2.12. Service-ID SubType		4.3.12. Service-ID SubType
	The value of the type and length fields of the Service-ID SubType are		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		TBD. The value field of this SubType is encoded as a string. This
	value is handled as an opaque string that uniquely describes the		value is handled as an opaque string that uniquely describes the
	service instance to which prepaid metering should be applied.		service instance to which prepaid metering should be applied.
	A Service-Id could be an IP 5-tuple (source address, source port,		A Service-Id could be an IP 5-tuple (source address, source port,
	destination address, destination port, protocol). If a Service-ID		destination address, destination port, protocol). If a Service-ID
	SubType is present in the PPAQ, the entire PPAQ attribute refers to		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		that service. If a PPAQ attribute does not contain a Service-Id or
	Rating-Group-ID, then the PPAQ attribute refers to the "Access		Rating-Group-ID, then the PPAQ attribute refers to the "Access
	Service".		Service".
	4.2.13. Rating-Group-ID SubType		4.3.13. Rating-Group-ID SubType
	The value of the type field of the Rating-Group-ID SubType is TBD.		The value of the type field of the Rating-Group-ID SubType is TBD.
	The length of this SubType is 6 octets. This SubType indicates that		The length of this SubType is 6 octets. This SubType indicates that
	this PPAQ attribute is associated with resources allocated to a		this PPAQ attribute is associated with resources allocated to a
	Rating Group with the corresponding ID. This SubType is encoded as a		Rating Group with the corresponding ID. This SubType is encoded as a
	string. A single PPAQ MUST NOT contain more than one		string. A single PPAQ MUST NOT contain more than one
	Rating-Group-ID.		Rating-Group-ID.
	4.2.14. Termination-Action SubType		4.3.14. Termination-Action SubType
	The value of the type field of the Termination-Action SubType is TBD.		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		The length of this SubType is 3 octets. This SubType contains an
	enumeration of the action to take when the PPS does not grant		enumeration of the action to take when the PPS does not grant
	additional quota. Valid actions are as follows.		additional quota. Valid actions are as follows.
	The following values for the Termination-Action SubType are defined:		The following values for the Termination-Action SubType are defined:
	Value | Description		Value | Description
	-------------+------------------------------------		-------------+------------------------------------
	0 | Reserved		0 | Reserved
	1 | Terminate		1 | Terminate
	2 | Request More Quota		2 | Request More Quota
	3 | Redirect/Filter		3 | Redirect/Filter
	4..255 | **Available for IANA registration**		4..255 | **Available for IANA registration**
	Figure 12: Values for the Termination-Action SubType		Figure 11: Values for the Termination-Action SubType
	4.2.15. Pool-ID SubType		4.3.15. Pool-ID SubType
	The value of the type field of the Pool-ID SubType is TBD. The		The value of the type field of the Pool-ID SubType is TBD. The
	length of this SubType is 6 octets and it identifies the resource		length of this SubType is 6 octets and it identifies the resource
	pool. It is encoded as a string.		pool. It is encoded as a string.
	4.2.16. Pool-Multiplier SubType		4.3.16. Pool-Multiplier SubType
	The value of the type field of the Pool-Multiplier SubType is TBD.		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		The length of this SubType is 12 or 18 octets. The pool multiplier
	determines the weight that resources are inserted into the pool that		determines the weight that resources are inserted into the pool that
	is identified by the accompanying Pool-ID SubType, and the rate at		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		which resources are taken out of the pool by the relevant Service or
	Rating-Group. The SubType consists of a Value-Digits SubType and		Rating-Group. The SubType consists of a Value-Digits SubType and
	optionally an Exponent SubType (as indicated by the length field).		optionally an Exponent SubType (as indicated by the length field).
	4.2.17. Requested-Action SubType		4.3.17. Requested-Action SubType
	The value of the type field of the Requested-Action SubType is TBD.		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		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		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		desires the PPS to perform the indicated action and to return the
	result. The PPAQ in which a Requested-Action SubType occurs MUST NOT		result. The PPAQ in which a Requested-Action SubType occurs MUST NOT
	contain a QID, and MUST contain a Service-Identifier or a Rating-		contain a QID, and MUST contain a Service-Identifier or a Rating-
	Group-Identifer that allows the PPS to uniquely identify the service		Group-Identifer that allows the PPS to uniquely identify the service
	for which the indicated action is requested.		for which the indicated action is requested.
	The following values for the Requested-Action SubType are defined:		The following values for the Requested-Action SubType are defined:
	Value | Description		Value | Description
	-------------+-------------------------------------		-------------+-------------------------------------
	0 | Reserved		0 | Reserved
	1 | Balance Check		1 | Balance Check
	2 | Price Enquiry		2 | Price Enquiry
	3..255 | **Available for IANA registration**		3..255 | **Available for IANA registration**
	Figure 13: Values for the Requested-Action SubType		Figure 12: Values for the Requested-Action SubType
	4.2.18. Check-Balance-Result SubType		4.3.18. Check-Balance-Result SubType
	The value of the type field of the Check-Balance-Result SubType is		The value of the type field of the Check-Balance-Result SubType is
	TBD. The length of this SubType is 3 octets. This SubType can only		TBD. The length of this SubType is 3 octets. This SubType can only
	be present in messages sent from the PPS to the PPC. It indicates		be present in messages sent from the PPS to the PPC. It indicates
	the balance check decision of the PPS about a previously received		the balance check decision of the PPS about a previously received
	Balance Check Request (as indicated in a Requested-Action SubType).		Balance Check Request (as indicated in a Requested-Action SubType).
	The PPAQ attribute in which a Check-Balance-Result occurs MUST NOT		The PPAQ attribute in which a Check-Balance-Result occurs MUST NOT
	include a QID.		include a QID.
	The following values for the Check-Balance-Result SubType are		The following values for the Check-Balance-Result SubType are
	defined:		defined:
	Value | Description		Value | Description
	-------------+-------------------------------------------		-------------+-------------------------------------------
	0 | Success; Sufficient funds available		0 | Success; Sufficient funds available
	| in the user's prepaid account		| in the user's prepaid account
	1 | Failure; Insufficient funds available		1 | Failure; Insufficient funds available
	2..255 | **Available for IANA registration**		2..255 | **Available for IANA registration**
	Figure 14: Values for the Check-Balance-Result SubType		Figure 13: Values for the Check-Balance-Result SubType
	4.2.19. Cost-Information SubType		4.3.19. Cost-Information SubType
	The value of the type field of the Cost-Information SubType is TBD.		The value of the type field of the Cost-Information SubType is TBD.
	The length of this SubType is variable. This SubType is used in		The length of this SubType is variable. This SubType is used in
	order to return the cost information of a service, which the PPC can		order to return the cost information of a service, which the PPC can
	transfer transparently to the end user. This SubType is sent from		transfer transparently to the end user. This SubType is sent from
	the PPS to the PPC as a response to a "Price Enquiry", as indicated		the PPS to the PPC as a response to a "Price Enquiry", as indicated
	by the Requested-Action SubType. This SubType consists of four		by the Requested-Action SubType. This SubType consists of four
	further SubTypes, as follows:		further SubTypes, as follows:
	Value-Digits SubType:		Value-Digits SubType:
	skipping to change at page 39, line 47 ¶		skipping to change at page 40, line 13 ¶
	service cost is a cost per unit (e.g., cost of the service is $1		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,		per minute). The Cost-Unit can be minutes, hours, days,
	kilobytes, megabytes, etc.		kilobytes, megabytes, etc.
	For example, the cost of 7.75 Malawi kwacha per hour would be encoded		For example, the cost of 7.75 Malawi kwacha per hour would be encoded
	as follows. Value-Digits = 775, Exponent = -2, Currency Code = 103,		as follows. Value-Digits = 775, Exponent = -2, Currency Code = 103,
	and Cost-Unit = "hour".		and Cost-Unit = "hour".
	The PPAQ that carries a Cost-Information MUST NOT include a QID.		The PPAQ that carries a Cost-Information MUST NOT include a QID.
	4.3. Prepaid Tariff Switching (PTS) Attribute		4.4. Prepaid Tariff Switching (PTS) Attribute
	This specification defines the PTS attribute, which allows to switch		This specification defines the PTS attribute, which allows to switch
	from one rate to another during service provision. Support for		from one rate to another during service provision. Support for
	tariff switching is optional to implement and to use for the PPC and		tariff switching is optional to implement and to use for the PPC and
	the PPS. PPCs use the flag "Tariff Switching supported" in the		the PPS. PPCs use the flag "Tariff Switching supported" in the
	AvailableInClient field of the PPAC attribute in order to indicate		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.		to announce their support for tariff switching.
	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 the "Tariff Switching supported" flag in		contains a PTS attribute or the "Tariff Switching supported" flag in
	the AvailableInClient field of the PPAC attribute, it MUST also		the AvailableInClient field of the PPAC attribute, it MUST also
	contain an Event-Timestamp RADIUS attribute (see [RFC2869]).		contain an Event-Timestamp RADIUS attribute (see [RFC2869]).
	Every PTS attribute MUST include a QID SubType, as specified in		Every PTS attribute MUST include a QID SubType, as specified in
	Section 4.2.1. In a RADIUS Access-Request message sent from the PPC		Section 4.3.1. In a RADIUS Access-Request message sent from the PPC
	to the PPS, the QID SubType MUST contain the value of the Quota		to the PPS, the QID SubType MUST contain the value of the Quota
	Identifier SubType that was previously received from the PPS and MUST		Identifier SubType that was previously received from the PPS and MUST
	be the same as the value carried in the QID SubType of one of the		be the same as the value carried in the QID SubType of one of the
	PPAQ attributes included the same RADIUS message.		PPAQ attributes included the same RADIUS message.
	If multiple services are supported and if the PPAQ is associated with		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		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		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-ID, then the PTS refers to tariff switch for the "Access
	Service".		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 value as the QID SubType contained in the PTS attribute		has the same value as the QID SubType contained in the PTS attribute
	in its own QID SubType is referred to as the "accompanying PPAQ		in its own QID SubType is referred to as the "accompanying PPAQ
	attribute". If a PPS receives an Access-Request message from a PPC,		attribute". If a PPS receives an Access-Request message from a PPC,
	it associates a unique value for the QID SubType to this request.		it associates a unique value for the QID SubType to this request.
	The PTS attribute, as shown in Figure 15, contains a number of other		The PTS attribute, as shown in Figure 14, contains a number of other
	subtypes which are specified in the following subsections.		subtypes which are specified in the following subsections.
	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 | VALUE ...		| TYPE | LENGTH | VALUE ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... VALUE |		... VALUE |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 41, line 25 ¶		skipping to change at page 41, line 25 ¶
	VALUE : Variable length content of data type String		VALUE : Variable length content of data type String
	Each SubType is then encoding in the following style:		Each SubType is then encoding in the following style:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SubType | LENGTH | VALUE ...		| SubType | LENGTH | VALUE ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 15: PTS Attribute		Figure 14: PTS Attribute
	4.3.1. VolumeUsedAfterTariffSwitch SubType		4.4.1. VolumeUsedAfterTariffSwitch SubType
	The value of the type field of the VolumeUsedAfterTariffSwitch		The value of the type field of the VolumeUsedAfterTariffSwitch
	(VUATS) SubType is TBD. The length of this SubType is 12 or 18		(VUATS) SubType is TBD. The length of this SubType is 12 or 18
	octets. The VolumeUsedAfterTariffSwitch subtype SHOULD be used in		octets. The VolumeUsedAfterTariffSwitch subtype SHOULD be used in
	the RADIUS Access-Request messages (PPC to PPS direction). It		the RADIUS Access-Request messages (PPC to PPS direction). It
	indicates the volume (in octets) used during a session after the last		indicates the volume (in octets) used during a session after the last
	tariff switch for the service specified via the QID SubType and the		tariff switch for the service specified via the QID SubType and the
	accompanying PPAQ attribute. The attribute consists of a Value-		accompanying PPAQ attribute. The attribute consists of a Value-
	Digits SubType and optionally an Exponent SubType (as indicated in		Digits SubType and optionally an Exponent SubType (as indicated in
	the length field).		the length field).
	4.3.2. TariffSwitchInterval SubType		4.4.2. TariffSwitchInterval SubType
	The type of the TariffSwitchInterval (TSI) SubType is TBD and its		The type of the TariffSwitchInterval (TSI) SubType is TBD and its
	length 6 octets. This SubType MUST be present in each PTS attribute		length 6 octets. This SubType MUST be present in each PTS attribute
	that is part of a RADIUS Access-Accept message (PPS to PPC		that is part of a RADIUS Access-Accept message (PPS to PPC
	direction). It indicates the interval (in seconds) between the value		direction). It indicates the interval (in seconds) between the value
	of Event-Timestamp RADIUS attribute (see [RFC2869]) of the		of Event-Timestamp RADIUS attribute (see [RFC2869]) of the
	corresponding RADIUS Access-Request message and the next tariff		corresponding RADIUS Access-Request message and the next tariff
	switch condition.		switch condition.
	4.3.3. TimeIntervalafterTariffSwitchUpdate SubType		4.4.3. TimeIntervalafterTariffSwitchUpdate SubType
	The value of the type field of the		The value of the type field of the
	TimeIntervalafterTariffSwitchUpdate (TITSU) SubType is TBD. The		TimeIntervalafterTariffSwitchUpdate (TITSU) SubType is TBD. The
	length of this SubType is 6 octets. The PPS MUST include this		length of this SubType is 6 octets. The PPS MUST include this
	SubType if there is another tariff switch period after the period		SubType if there is another tariff switch period after the period
	that ends as indicated by the TSI SubType. The value of the TITSU		that ends as indicated by the TSI SubType. The value of the TITSU
	SubType in encoded as an integer, and contains the number of seconds		SubType in encoded as an integer, and contains the number of seconds
	of the tariff period that begins immediately after the period that		of the tariff period that begins immediately after the period that
	ends as indicated by the TSI attribute. If the TITSU SubType is not		ends as indicated by the TSI attribute. If the TITSU SubType is not
	present, the PPC assumes that the tariff period which ends as		present, the PPC assumes that the tariff period which ends as
	indicated by the TSI SubType lasts until further notice. If TITSU is		indicated by the TSI SubType lasts until further notice. If TITSU is
	specified, the PPC MUST send a quota update before the point in time		specified, the PPC MUST send a quota update before the point in time
	specified by the TITSU SubType (see Figure 8).		specified by the TITSU SubType (see Figure 7).
	5. Diameter RADIUS Interoperability		5. Diameter RADIUS Interoperability
	The RADIUS prepaid extensions need to interoperate with the Diameter		The RADIUS prepaid extensions need to interoperate with the Diameter
	protocol. Two interoperability scenarios exist, as follows. Either		protocol. Two interoperability scenarios exist, as follows. Either
	the AAA infrastructure is Diameter based and the PPC are RADIUS		the AAA infrastructure is Diameter based and the PPC are RADIUS
	based, or the PPC is Diameter based and the AAA infrastructure is		based, or the PPC is Diameter based and the AAA infrastructure is
	RADIUS based.		RADIUS based.
	The Diameter Credit Control Application [RFC4006] describes how to		The Diameter Credit Control Application [RFC4006] describes how to
	skipping to change at page 48, line 7 ¶		skipping to change at page 48, line 7 ¶
	Updates can be provided based on expert approval only. A designated		Updates can be provided based on expert approval only. A designated
	expert will be appointed by the O&M Area Directors. No mechanism to		expert will be appointed by the O&M Area Directors. No mechanism to
	mark entries as "deprecated", or to delete entries from the registry		mark entries as "deprecated", or to delete entries from the registry
	is envisioned.		is envisioned.
	Each registration must include a number for the SubType and the		Each registration must include a number for the SubType and the
	semantic of the SubType.		semantic of the SubType.
	8.3. New Registry: Update-Reason		8.3. New Registry: Update-Reason
	Section 4.2.10 defines the Update-Reason SubType. IANA is asked to		Section 4.3.10 defines the Update-Reason SubType. IANA is asked to
	create a registry for the values contained in the Update-Reason		create a registry for the values contained in the Update-Reason
	SubType, as shown in Figure 11. Each registry entry consists of a 8		SubType, as shown in Figure 10. Each registry entry consists of a 8
	bit number together with a description of the update reason.		bit number together with a description of the update reason.
	Following the policies outline in [RFC3575] the available values		Following the policies outline in [RFC3575] the available values
	together with a description of their semantic will be assigned after		together with a description of their semantic will be assigned after
	Expert Review initiated by the O&M Area Directors in consultation		Expert Review initiated by the O&M Area Directors in consultation
	with the RADEXT working group chairs or the working group chairs of a		with the RADEXT working group chairs or the working group chairs of a
	designated successor working group. Updates can be provided based on		designated successor working group. Updates can be provided based on
	expert approval only. A designated expert will be appointed by the		expert approval only. A designated expert will be appointed by the
	O&M Area Directors. No mechanism to mark entries as "deprecated", or		O&M Area Directors. No mechanism to mark entries as "deprecated", or
	to delete entries from the registry is envisioned.		to delete entries from the registry is envisioned.
	8.4. New Registry: Termination-Action		8.4. New Registry: Termination-Action
	Section 4.2.14 defines the Termination-Action SubType. IANA is asked		Section 4.3.14 defines the Termination-Action SubType. IANA is asked
	to create a registry for the values contained in the Termination-		to create a registry for the values contained in the Termination-
	Action SubType, as shown in Figure 12. Each registry entry consists		Action SubType, as shown in Figure 11. Each registry entry consists
	of a 8 bit number together with a description of the termination		of a 8 bit number together with a description of the termination
	action.		action.
	Following the policies outline in [RFC3575] the available values		Following the policies outline in [RFC3575] the available values
	together with a description of their semantic will be assigned after		together with a description of their semantic will be assigned after
	Expert Review initiated by the O&M Area Directors in consultation		Expert Review initiated by the O&M Area Directors in consultation
	with the RADEXT working group chairs or the working group chairs of a		with the RADEXT working group chairs or the working group chairs of a
	designated successor working group. Updates can be provided based on		designated successor working group. Updates can be provided based on
	expert approval only. A designated expert will be appointed by the		expert approval only. A designated expert will be appointed by the
	O&M Area Directors. No mechanism to mark entries as "deprecated", or		O&M Area Directors. No mechanism to mark entries as "deprecated", or
	to delete entries from the registry is envisioned.		to delete entries from the registry is envisioned.
	8.5. New Registry: Requested-Action		8.5. New Registry: Requested-Action
	Section 4.2.17 defines the Requested-Action SubType. IANA is asked		Section 4.3.17 defines the Requested-Action SubType. IANA is asked
	to create a registry for the values contained in the Requested-Action		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		SubType, as shown in Figure 12. Each registry entry consists of a 8
	bit number together with a description of the requested reason.		bit number together with a description of the requested reason.
	Following the policies outline in [RFC3575] the available values		Following the policies outline in [RFC3575] the available values
	together with a description of their semantic will be assigned after		together with a description of their semantic will be assigned after
	Expert Review initiated by the O&M Area Directors in consultation		Expert Review initiated by the O&M Area Directors in consultation
	with the RADEXT working group chairs or the working group chairs of a		with the RADEXT working group chairs or the working group chairs of a
	designated successor working group. Updates can be provided based on		designated successor working group. Updates can be provided based on
	expert approval only. A designated expert will be appointed by the		expert approval only. A designated expert will be appointed by the
	O&M Area Directors. No mechanism to mark entries as "deprecated", or		O&M Area Directors. No mechanism to mark entries as "deprecated", or
	to delete entries from the registry is envisioned.		to delete entries from the registry is envisioned.
	8.6. New Registry: Check-Balance-Result		8.6. New Registry: Check-Balance-Result
	Section 4.2.18 defines the Check-Balance-Result SubType. IANA is		Section 4.3.18 defines the Check-Balance-Result SubType. IANA is
	asked to create a registry for the values contained in the Check-		asked to create a registry for the values contained in the Check-
	Balance-Result SubType, as shown in Figure 14. Each registry entry		Balance-Result SubType, as shown in Figure 13. Each registry entry
	consists of a 8 bit number together with a description of the		consists of a 8 bit number together with a description of the
	requested reason.		requested reason.
	Following the policies outline in [RFC3575] the available values		Following the policies outline in [RFC3575] the available values
	together with a description of their semantic will be assigned after		together with a description of their semantic will be assigned after
	Expert Review initiated by the O&M Area Directors in consultation		Expert Review initiated by the O&M Area Directors in consultation
	with the RADEXT working group chairs or the working group chairs of a		with the RADEXT working group chairs or the working group chairs of a
	designated successor working group. Updates can be provided based on		designated successor working group. Updates can be provided based on
	expert approval only. A designated expert will be appointed by the		expert approval only. A designated expert will be appointed by the
	O&M Area Directors. No mechanism to mark entries as "deprecated", or		O&M Area Directors. No mechanism to mark entries as "deprecated", or
	to delete entries from the registry is envisioned.		to delete entries from the registry is envisioned.
	8.7. New Registry: AvailableInClient-Extended		8.7. New Registry: AvailableInClient-Extended
	Section 4.2.18 defines the PrePaid Accounting Capability (PPAC)		Section 4.3.18 defines the PrePaid Accounting Capability (PPAC)
	attribute with the AvailableInClient-Extended field. IANA is asked		attribute with the AvailableInClient-Extended field. IANA is asked
	to create a registry for the values contained in the		to create a registry for the values contained in the
	AvailableInClient-Extended field, as shown in Section 4.1. Each		AvailableInClient-Extended field, as shown in Section 4.1. Each
	registry entry consists of a 8 bit number together with a description		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		of the capability. Note that this is a bitmask and only 8 values are
	available for registration via IANA.		available for registration via IANA.
	Following the policies outline in [RFC3575] the available values		Following the policies outline in [RFC3575] the available values
	together with a description of their semantic will be assigned after		together with a description of their semantic will be assigned after
	Expert Review initiated by the O&M Area Directors in consultation		Expert Review initiated by the O&M Area Directors in consultation
	skipping to change at page 53, line 22 ¶		skipping to change at page 53, line 22 ¶
	REASON=ACCESS SERV TERMINATED}}		REASON=ACCESS SERV TERMINATED}}
	-------(8)--------->		-------(8)--------->
	[reimburses		[reimburses
	user account]		user account]
	AA Accept		AA Accept
	{RADIUS BASE AVPS}		{RADIUS BASE AVPS}
	<-------(9)--------		<-------(9)--------
	Figure 19: A simple example message flow		Figure 18: A simple example message flow
	The user logs on (1). The PPC sends a RADIUS Access Request message		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		to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP
	indicates that both duration-based and volume-based metering is		indicates that both duration-based and volume-based metering is
	supported. However, it also indicated that multiple services, rating		supported. However, it also indicated that multiple services, rating
	groups and resource pools are not supported. Note that, since this		groups and resource pools are not supported. Note that, since this
	is not an "Authorize-Only" message, no PPAQ attribute with Update		is not an "Authorize-Only" message, no PPAQ attribute with Update
	Reason="initial request" is included (see Section 3.7.1). The PPS		Reason="initial request" is included (see Section 3.7.1). The PPS
	then authenticates the user and authorizes the access service, as is		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		usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at
	skipping to change at page 56, line 15 ¶		skipping to change at page 56, line 15 ¶
	PTS={QID=8, VUATS=2.5 MB}		PTS={QID=8, VUATS=2.5 MB}
	-------(8)--------->		-------(8)--------->
	[reimburses		[reimburses
	user account]		user account]
	AA Accept		AA Accept
	{RADIUS BASE AVPS}		{RADIUS BASE AVPS}
	<-------(9)--------		<-------(9)--------
	Figure 20: Example message flow with Tariff Switch		Figure 19: Example message flow with Tariff Switch
	The user logs on (1). The PPC sends a RADIUS Access Request message		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		to the home AAA server (2), and includes the prepaid-specific PPAC
	AVP. This AVP indicates that both duration-based and volume-based		AVP. This AVP indicates that both duration-based and volume-based
	metering is supported, as well as tariff switching. The home AAA		metering is supported, as well as tariff switching. The home AAA
	server then may authenticate and user and authorize the access		server then may authenticate and user and authorize the access
	service, as is usual in RADIUS. Note that the PPAC AVP is appended		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		by the PPC in at least the last message that is sent to the PPS
	during this possibly multiple-round exchange.		during this possibly multiple-round exchange.
	skipping to change at page 60, line 34 ¶		skipping to change at page 60, line 34 ¶
	SID="A",RGROUP=1}}		SID="A",RGROUP=1}}
	-------(12)--------->		-------(12)--------->
	[reimburses		[reimburses
	user account]		user account]
	AA Accept		AA Accept
	{RADIUS BASE AVPS		{RADIUS BASE AVPS
	<------(13)--------		<------(13)--------
	Figure 21: Example message flow with resource pools and rating groups		Figure 20: Example message flow with resource pools and rating groups
	The user logs on (1). The PPC sends a RADIUS Access Request message		The user logs on (1). The PPC sends a RADIUS Access Request message
	to the PPS (2), and includes the prepaid-specific PPAC AVP,		to the PPS (2), and includes the prepaid-specific PPAC AVP,
	indicating that multiple services, rating groups and resource pools		indicating that multiple services, rating groups and resource pools
	are supported. Note that, since this is not an "Authorize- Only"		are supported. Note that, since this is not an "Authorize- Only"
	message, no PPAQ attribute with Update Reason="initial request" is		message, no PPAQ attribute with Update Reason="initial request" is
	included (see Section 3.7.1). The PPS then may authenticate the user		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		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		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.		is sent to the PPS during this possibly multiple-round exchange.
	skipping to change at page 64, line 25 ¶		skipping to change at page 64, line 25 ¶
	[rates 650 abstract units		[rates 650 abstract units
	deducts from user's account]		deducts from user's account]
	Access Accept		Access Accept
	{RADIUS BASE AVPS}		{RADIUS BASE AVPS}
	<----------(3)--------------		<----------(3)--------------
	ring tone is delivered		ring tone is delivered
	<------(4)-------		<------(4)-------
	Figure 22: Example message flow with one-time charging		Figure 21: Example message flow with one-time charging
	The user requests a chargeable ring tone (1). The PPC sends a RADIUS		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		Access Request message to the PPS (2), and includes a PPAQ attribute
	with Update Reason="one-time charging" is included (see		with Update Reason="one-time charging" is included (see
	Section 3.7.6). The Service ID indicates to the PPS that the		Section 3.8.6). The Service ID indicates to the PPS that the
	charging event is connected to a ring tone, so that the PPS can rate		charging event is connected to a ring tone, so that the PPS can rate
	the event accordingly. The PPAQ also contains a unique Quota		the event accordingly. The PPAQ also contains a unique Quota
	Identifier.		Identifier.
	The PPS then may authenticate the user as is usual in RADIUS. If		The PPS then may authenticate the user as is usual in RADIUS. If
	authentication is successful (in this example this is assumed), the		authentication is successful (in this example this is assumed), the
	home AAA server forwards the PPC converts the 650 reported abstract		home AAA server forwards the PPC converts the 650 reported abstract
	units into monetary value, according to the service type, and debit		units into monetary value, according to the service type, and debit
	the user's account accordingly. This happens, of course, only if		the user's account accordingly. This happens, of course, only if
	sufficient funds are available in the user's prepaid account. The		sufficient funds are available in the user's prepaid account. The
	PPC then responds with an an Access Accept message (3). The PPS adds		PPC then responds with an an Access Accept message (3). The PPS adds
	a "session timeout = 0 AVP" (see Section 3.7.6).		a "session timeout = 0 AVP" (see Section 3.8.6).
	A.5. Price enquiry		A.5. Price enquiry
	End user PPC PPS		End user PPC PPS
	user requests AoC		user requests AoC
	------(1)--------->		------(1)--------->
	Access Request		Access Request
	{RADIUS BASE AVPS,		{RADIUS BASE AVPS,
	PPAQ={SID=X, VQ=10MB,		PPAQ={SID=X, VQ=10MB,
	skipping to change at page 65, line 28 ¶		skipping to change at page 65, line 28 ¶
	Access Accept		Access Accept
	{RADIUS BASE AVPS,		{RADIUS BASE AVPS,
	PPAQ={SID=X, VQ=10MB,		PPAQ={SID=X, VQ=10MB,
	COST INFORMATION= 0.6 euros		COST INFORMATION= 0.6 euros
	per MB}}		per MB}}
	<----------(3)--------------		<----------(3)--------------
	AoC is delivered		AoC is delivered
	<------(4)-------		<------(4)-------
	Figure 23: Example message flow with price enquiry (advice of charge)		Figure 22: Example message flow with price enquiry (advice of charge)
	Please refer to Section 2.7.2 for an explanation of this message		Please refer to Section 2.7.3 for an explanation of this message
	flow.		flow.
	A.6. Balance check		A.6. Balance check
	End User PPC PPS		End User PPC PPS
	Access Request		Access Request
	{RADIUS BASE AVPS,		{RADIUS BASE AVPS,
	PPAQ={SID=X, VQ=10MB,		PPAQ={SID=X, VQ=10MB,
	REQ_ACT=BALANCE CHECK}}		REQ_ACT=BALANCE CHECK}}
	-------(2)--------->		-------(2)--------->
	skipping to change at page 66, line 22 ¶		skipping to change at page 66, line 22 ¶
	[rates requested		[rates requested
	Service and checks		Service and checks
	remaining funds]		remaining funds]
	Access Accept		Access Accept
	{RADIUS BASE AVPS,		{RADIUS BASE AVPS,
	PPAQ={SID=X, VQ=10MB,		PPAQ={SID=X, VQ=10MB,
	BALANCE_CHECK_RESULT}}		BALANCE_CHECK_RESULT}}
	<----------(3)--------------		<----------(3)--------------
	Figure 24: Example message flow with balance check		Figure 23: Example message flow with balance check
	Please refer to Section 2.7.3 for an explanation of this message		Please refer to Section 2.7.4 for an explanation of this message
	flow.		flow.
	Appendix B. Translation between RADIUS Prepaid and Diameter Credit		Appendix B. Translation between RADIUS Prepaid and Diameter Credit
	Control		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
	skipping to change at page 76, line 33 ¶		skipping to change at page 76, line 33 ¶
	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
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn Ring 6		Linnoitustie 6
	Munich, Bavaria 81739		Espoo 02600
	Germany		Finland
	Email: hannes.tschofenig@nsn.com		Phone: +358 (50) 4871445
			Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Andreas Pashalidis		Andreas Pashalidis
	NEC		NEC
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Email: Andreas.Pashalidis@netlab.nec.de		Email: Andreas.Pashalidis@netlab.nec.de
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 109 change blocks.
	223 lines changed or deleted		278 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/