Cisco Cisco Packet Data Gateway (PDG) Fehlerbehebungsanleitung

 

▄  Cisco ASR 5000 Series Enhanced Feature Configuration Guide 

The system supports pre-paid billing for subscriber accounts that use RADIUS Accounting. 3GPP2 pre-paid billing 
support is disabled by default and you must obtain and install a license key to enable it. 

 

The system supports two methods of implementing Pre-paid Billing Support; Standard 3GPP2 Pre-paid Billing and 
Custom Pre-paid Billing. The 3GPP2 standard is the recommended implementation. 

 

The prepaid packet data service allows a user to purchase access to the network in advance, based on either volume or 
duration. When a user connects to a service, the Prepaid Client (PPC) contacts the Prepaid Server (PPS) and verifies that 
the user has available credits for the service. When a user runs out of credits, service is terminated until the user 
purchases additional credits. 

The Prepaid Data Service implementation is compliant with 3GPP2 IS-835-C. This solution provides a standards based 
implementation that can effectively interoperate with additional vendors equipment when required. The system 
primarily uses the PPAC (PrePaid Accounting Capability) and PPAQ (PrePaid Accounting Quota) VSAs to implement 
PrePaid service. The PPAC VSA is used to determine the capabilities of the PPC. When the PPC sends the PPAC VSA 
it specifies if it supports duration, volume or both types of PrePaid service. When the PPS sends a PPAC VSA it 
specifies the type of PrePaid service to use for the particular session. The PPAQ VSA specifies the characteristics of the 
PrePaid accounting service. This includes quota & threshold values for both duration and volume PrePaid service. 
Through the use of these VSAs, the PPC and PPS communicate the status of the session and when the user has run out 
of quota, the service can be terminated. 

The PrePaid Client resides on the system and communicates with the PPS through the use of RADIUS messages 
exchanged with the RADIUS server. 

 

In the Access-Accept from the RADIUS server the system receives attributes which indicate the number of byte credits 
available for the subscriber. Byte throughput can be pre-paid for traffic inbound to the system, outbound from the 
system, or an amount that combines both inbound and outbound traffic. Five attributes are used: one for traffic inbound 
to the system, one for traffic outbound from the system, one that combines traffic in both directions, one that only 
indicates that the user should be re-authenticated regardless of the byte counters, and one for the low watermark in 
percent. 

The low watermark value is multiplied by the number of byte credits granted in the Access-Accept to arrive at a 
threshold. Once the number of byte credits remaining is lower than this number, a new Access-Request is issued. If the 
Access-Request is issued because the Low Watermark has been reached, then a new Low Watermark is calculated from 
the number of byte credits granted in the Access-Accept, but only if the number of byte credits granted is a non-zero 
value. If the Access-Request is issued for any other reason, then the Low Watermark is not re-calculated. 

The system re-authorizes an active subscriber that has used up its byte credits by issuing a RADIUS Access-Request to 
the RADIUS server. A valid Access-Reject or a RADIUS timeout results in immediate disconnect of the subscriber 
session. An Access-Accept without attributes that authorize more byte credits allows the subscriber session to continue