Intelligent Services Gateway Configuration Guide, Cisco IOS Release 15.1S
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuring ISG Support for Prepaid Billing
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Contents
Configuring ISG Support for Prepaid BillingLast Updated: May 27, 2011
Intelligent Services Gateway (ISG) is a Cisco IOS software feature set that provides a structured framework in which edge devices can deliver flexible and scalable services to subscribers. ISG prepaid billing support allows an ISG to check a subscriber's available credit to determine whether to allow the subscriber access to a service and how long the access can last. ISG prepaid billing works on a repeated reauthorization model in which fragments of credit, called quotas , are allotted by a prepaid billing server. This model allows a subscriber to be connected to multiple simultaneous prepaid services, each with a different billing rate. ISG supports time- and volume-based prepaid billing. This module provides information about how to configure ISG support for prepaid billing.
Finding Feature InformationYour software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Prerequisites for ISG Prepaid Billing SupportThe tasks in this document assume that a subscriber session has been created and a method of service activation is in place. Restrictions for ISG Prepaid Billing Support
Information About ISG Prepaid Billing Support
Overview of ISG Support for Prepaid BillingISG prepaid billing support allows ISG to check the available credit for a subscriber to determine whether to activate the service for the subscriber and how long the session can last. The subscriberâs credit is administered by a prepaid billing server as a series of quotas representing either a duration of use (in seconds) or an allowable data volume (in bytes). A quota is an allotment, or fragment, of available credit. Allocating quotas in fragments rather than providing all the credit at once enables ISG to support the use of credit for multiple simultaneous prepaid sessions. ISG uses the RADIUS protocol to facilitate interaction between ISG and external authentication, authorization, and accounting (AAA) servers and prepaid billing servers. A single device can serve as the AAA server and the billing server. To obtain the first quota for a session, ISG submits an authorization request to the AAA server. The AAA server contacts the prepaid billing server, which forwards the quota values to ISG. ISG then monitors the session to track the quota usage. When the quota runs out or a specified limit is reached, ISG performs reauthorization. During reauthorization, the prepaid billing server may provide ISG with an additional quota if there is available credit. If no further quota is provided, ISG will log the user off from the service or perform some other specified action. When a service is deactivated, the cumulative usage is provided to the prepaid billing server in an Accounting-Stop message. Tips for Preventing ISG from Allocating More Volume Quota than Subscriber is EntitledThe Cisco IOS prepaid volume monitor polling timer determines when ISG will initiate a prepaid reauthorization. The polling timer value is (15 seconds < polling-monitor-time < 300 seconds). This value is calculated dynamically based on the quota volume (QV) value, actual rate and the configured volume threshold. The prepaid volume monitor polling timer is not directly configurable. To avoid revenue leak during the first authorization (when usage rate is unknown), the QV value should be a minimum of (15 x access-rate). In cases in which the usage rate is known, the QV value should be at least (15 x usage-rate). In cases in which the input access-rate is much higher than the QV value, it is recommended that the correct QV value be calculated using the following formula: access-rate x 15 > QV < access-rate x 300. For example, an ADSL2 or VDSL user access-rate can be up to 20 Mbps. That is approximately 2.5 megabytes of data in one second. Calculate the QV value by using the following formula: 2.5 MB x 15 seconds > QV < 2.5 MB x 300 seconds. This calculation results in a QV value between 37.5 and 750 MB. We recommend avoiding the boundaries, so for this example you might pick a value of QV = 100MB ISG Prepaid ThresholdBy default, ISG sends reauthorization requests to the billing server when a subscriberâs quota is exhausted. ISG prepaid thresholds allow ISG to send reauthorization requests before a quota is used up. When a prepaid threshold is configured, ISG sends a reauthorization request to the billing server when the amount of remaining quota is equal to the value of the threshold. Prepaid thresholds can be configured for both time and volume. For example, if the prepaid threshold is configured for 10 seconds, and the prepaid billing server sends ISG a quota of 30 seconds, ISG will send a reauthorization request to the prepaid billing server when the subscriber has used up 20 seconds of the quota and has 10 seconds remaining. ISG Prepaid Idle TimeoutThe ISG prepaid idle timeout can be used to suspend a prepaid service session if no traffic is received for a specified period of time. ISG keeps the session up during the suspension but releases all quota previously received for the prepaid session. Subsequent traffic on the session will cause ISG to send a reauthorization request and download a new quota for the session. ISG Prepaid Tariff SwitchingPrepaid tariff switching allows changes in tariffs during the lifetime of a session. Typically, a service provider uses prepaid tariff switching to offer different tariffs to an end user during an active connection; for example, changing a user to a less expensive tariff during off-peak hours.
ISG supports prepaid tariff switching by using two quotas that correspond to the time before and the time after the switch point. In the authorization response to ISG, the prepaid billing server specifies the tariff switch point and the quotas for the periods before and after the tariff switch. ISG uses the pre-tariff switch quota until the tariff switch occurs. If the pre-tariff switch quota is exhausted (or the threshold is reached) prior to the tariff switch, reathorization occurs as usual. Upon tariff switch, ISG starts using the post-tariff switch quota for prepaid session monitoring. Reauthorization occurs only when either of these quotas is exhausted, not when a tariff change occurs. This dual-quota approach to accounting for prepaid tariff switching staggers reauthorization requests according to the usage of the subscriber and prevents the billing server from being overwhelmed with reauthorization requests at the time of a tariff switch. Benefits of ISG Prepaid BillingConcurrent Prepaid Service AccessThe ISG Support for Prepaid Billing feature is capable of supporting concurrent prepaid service access while maintaining the same pool of quota at the prepaid billing server. ISG services can be configured for concurrent or sequential access. Concurrent access allows users to log on to a service while simultaneously connected to other services. Real-Time BillingThe ISG Support for Prepaid Billing feature allows for real-time billing with maximum flexibility, regardless of the type of service and billing scheme. Users can be billed on a flat rate, air-time, or volume basis. Redirection Upon Exhaustion of QuotaWhen a user runs out of quota, ISG can redirect the user to a portal where the user can replenish the quota without being disconnected from the service. Returning Residual QuotaISG can return residual quota to the billing server from services that a user is logged into but not actively using. The quota that is returned to the billing server can be applied to other services that the user is actively using. Threshold ValuesISG enables you to configure threshold values that cause prepaid sessions to be reauthorized before the subscriber completely consumes the allotted quota for a service. Traffic Status During ReauthorizationYou can prevent revenue leaks by configuring ISG to drop connected traffic during reauthorization of a service. The user remains connected to the service and does not need to log in to the service again, but no traffic is forwarded during the reauthorization process. This prevents a user from continuing to use a service for which the user has run out of quota while ISG sends a reauthorization request to the billing server. Simultaneous Volume-Based and Time-Based Prepaid BillingISG supports rating on both time and volume simultaneously for prepaid services. The prepaid billing server may allocate quotas in both time and volume, and ISG monitors the session on both these parameters. ISG performs a reauthorization whenever either of these quota types is exhausted. How to Configure ISG Support for Prepaid Billing
Configuring RADIUS Attribute Support for ISG Prepaid BillingPerform this task to enable ISG to include RADIUS attribute 44 in Access-Request packets and attribute 55 in Accounting-Request packets. DETAILED STEPS
Creating an ISG Prepaid Billing ConfigurationPerform this task to create or modify an ISG prepaid billing configuration. This configuration can be referenced in service profiles or service policy maps in which ISG prepaid support is enabled. A default prepaid configuration exists with the following parameters: subscriber feature prepaid default threshold time 0 seconds threshold volume 0 bytes method-list authorization default method-list accounting default password cisco The default configuration will not show up in the output of the show running-config command unless you change any one of the parameters. The parameters of named prepaid configurations are inherited from the default configuration, so if you create a named prepaid configuration and want only one parameter to be different from the default configuration, you have to configure only that parameter. Before You Begin
SUMMARY STEPS
This task assumes that AAA method lists, server groups, and servers have been configured. See the Cisco IOS Security Configuration Guide: Securing User Services for more information. DETAILED STEPS Enabling ISG Prepaid BillingPerform one of the following tasks to enable prepaid billing in a service policy map or a remote service profile:
Enabling ISG Prepaid Billing in a Service Policy MapBefore You Begin
SUMMARY STEPS
ISG prepaid billing is enabled in a traffic class within a service policy map. This task assumes that you have defined the traffic class map and associated IP access lists. See the module "Configuring ISG Subscriber Services" for more information. DETAILED STEPS Enabling ISG Prepaid Billing in Service Profile on the AAA ServerPerform this task to enable ISG support for prepaid billing in a service profile that is configured on a remote AAA server.
DETAILED STEPS
Redirecting Subscriber Traffic upon Exhaustion of CreditService providers often want to offer subscribers an opportunity to recharge their accounts when they have run out of credit for their prepaid services. The tasks in this section enable you to redirect a subscriberâs Layer 4 traffic to a specified server when the subscriber has run out of credit. Before you configure ISG Layer 4 Redirect for exhaustion of credit, you should understand the following concept: Perform the following tasks to redirect a subscriberâs Layer 4 traffic upon exhaustion of credit:
Credit-Exhausted EventThe ISG credit-exhausted event occurs when the prepaid server responds with an Access-Accept packet with a quota value of zero (time or volume) and an idle timeout greater than zero. In this case, the prepaid server has determined for certain that the subscriber does not have enough credit, but the idle timeout provides a grace period in which the subscriber could recharge the account. Typically, a service provider would want to redirect the subscriberâs traffic to a web portal where the subscriber could recharge the account. At the end of the idle-timeout interval, ISG will send a reauthorization request. The default ISG behavior is to drop subscriber packets when the credit-exhausted event occurs.
Configuring L4 Redirection in a Service Policy MapPerform this task to configure ISG Layer 4 redirection in a service policy map. The ISG Layer 4 Redirect feature can also be configured in a service profile on a AAA server. For more information about redirecting Layer 4 subscriber traffic, see the "Redirecting Subscriber Traffic Using ISG Layer 4 Redirect" module. Before You Begin
SUMMARY STEPS
The ISG Layer 4 Redirect feature is configured under a traffic class within the service policy map. This task assumes that you have defined the traffic class map. See the "Configuring ISG Subscriber Services" module for more information. Traffic can be redirected to a server or server group. If you are redirecting traffic to a server group, this task assumes that the server group has been configured. See the "Configuring ISG Subscriber Services" module for more information about configuring server groups. DETAILED STEPS
Applying a Service Policy Map to Subscriber Traffic upon Exhaustion of CreditPerform this task to configure a control policy and apply a service policy map to subscriber traffic upon exhaustion of credit. Before You Begin
SUMMARY STEPS
If you specify a named control class map, this task assumes that the class map has been configured. See the "Configuring ISG Control Policies" module for information about configuring control class maps. DETAILED STEPS
Forwarding Subscriber Traffic upon Depletion of QuotaBy default, ISG drops subscriber packets when a subscriberâs quota has been depleted. This task enables you override the default and forward subscriber traffic when the quota-depleted event occurs. Before you perform this task you should understand the concept described in the "Quota-Depleted Event" below. Quota-Depleted EventA quota-depleted event occurs when a subscriberâs quota is exhausted and ISG has not yet received a reauthorization response from the billing server. This event can occur in two situations:
The quota-depleted event is not necessarily an indication that a subscriber does not have any more credit. ISG does not know for certain whether the subscriber has any more credit until a reauthorization response is returned from the billing server. For this reason, some service providers may choose to forward subscriber packets upon quota depletion until a reauthorization response is returned. The default ISG behavior is to drop subscriber packets when a quota-depleted event occurs. Before You Begin
SUMMARY STEPS
If you specify a named control class map, this task assumes that the class map has been configured. See the module "Configuring ISG Control Policies" for information about configuring control class maps. DETAILED STEPS
Troubleshooting ISG Prepaid Billing Support
SUMMARY STEPS
1. Use the show subscriber session command to make sure the service in which prepaid billing support is configured has been activated. 2. If the service requires service authentication, make sure the authentication succeeded. 3. Make sure the AAA method list referred to in the prepaid billing configuration is valid and has been configured with the aaa accounting network command. 4. Use the test aaa command to make sure the AAA server is reachable from ISG. 5. Use the debug subscriber policy prepaid command to display debug messages about prepaid operation. DETAILED STEPS
Configuration Examples for ISG Prepaid Billing Support
ISG Prepaid Billing Support ExampleThe following example shows ISG prepaid billing support configured with the following parameters:
! aaa authorization network default local aaa authorization network ap-mlist group sg2 aaa authentication login cp-mlist group sg1 aaa accounting network cp-mlist start-stop group sg1 aaa accounting network ap-mlist start-stop group sg2 service-policy type control RULEA ! class-map type traffic match-any CLASS-ALL ! class-map type traffic match-any CLASS-ACL-101 match access-group input 101 ! policy-map type control RULEA class type control always event credit-exhausted 1 service-policy type service name redirectprofile ! policy-map type service redirectprofile class type traffic CLASS-ALL redirect to group redirect-sg policy-map type service mp3 class type traffic CLASS-ACL-101 accounting aaa list cp-mlist ! authenticate aaa list cp-mlist ! subscriber feature prepaid conf-prepaid method-list accounting ap-mlist method-list authorization default password cisco threshold time 20 threshold volume 1000 bytes ISG Policies for Handling Credit-Exhausted and Quota-Depleted Prepaid Billing Events ExampleIn the following example, a single control policy called âRULEAâ has been defined to override the ISG prepaid default behavior by forwarding subscriber packets after a quota-depleted event and redirecting subscriber packets after a credit-exhausted event: !class-map type traffic match-any CLASS-ALL ! policy-map type control RULEA class type control always event quota-depleted 1 set-param drop-traffic false class type control always event credit-exhausted 1 service-policy type service name l4redirect ! policy-map type service l4redirect class type traffic CLASS-ALL redirect to group SESM ! subscriber feature prepaid conf-prepaid threshold time 100 threshold volume 1000 bytes method-list author prepaidlist method-list accounting default password cisco Additional ReferencesRelated DocumentsMIBsTechnical Assistance
Feature Information for ISG Support for Prepaid BillingThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||