Cisco Service Control Application for Broadband Introduction to Policy Integration Solution Guide, Release 3.5.5
Available Languages
Table Of Contents
Policy and Service Configuration
Real-Time Subscriber Management and Control
Service Creation Integration Model
Real Time Subscriber Provisioning and Monitoring
Service Creation Integration—Examples
Example I—Periodic-Quota Based Services
Example II—Turbo Button With "Free Usage"
Obtaining Documentation and Submitting a Service Request
Cisco Service Control Solution guide
Cisco Service Control Application for Broadband Introduction to Policy Integration Solution Guide, Release 3.5.5
Revised: August 4, 2009, OL-10609-041 Solution Overview
This section contains the following sections:
•
Policy and Service Configuration
•
This section describes the logical components that make up the Cisco SCA BB solution. The SCA BB solution can serve as a platform for service creation for a service provider.
Figure 1 and Figure 2 illustrate the high level architecture of the SCA BB solution when integrated in a typical service provider environment, showing the major components and the relationships between them. The first diagram shows the SCA BB solution including the Subscriber Manager component. The second diagram shows direct integration with the SCE platform (also known as SM-less integration). In this case, the SM component is not included and the 3rd party Policy Server communicates directly with the SCE platform.
Figure 1 Cisco SCA BB Solution System Including SM
Figure 2 Cisco SCA BB Solution System—Without SM Integration
Cisco SCE Platform
The Cisco SCE platform is a hardware accelerated, deep packet inspection device that forms the core of the solution. In a service creation scenario, the SCE platform is deployed inline on the subscriber IP data path, providing deep packet inspection and application/protocol recognition along with the enforcement of the relevant policies, per subscriber, according to the customer business logic.
The device is configured and monitored through NMS (over CLI, SNMP) and a number of proprietary tools used for service configuration, subscriber management, and multi-unit configuration. All of the tools are combined in the SCA BB Console application. The platform is subscriber aware (see Real-Time Subscriber Management and Control), and can be used for usage-based services, for example, subscriber level quota management and billing. The platform also generates network usage data at various granularities for monitoring and analysis purposes.
More details on the SCE platform and its various configuration interfaces can be found in the Cisco SCE 2000 Installation and Configuration Guide and in the Cisco SCE 2000 Quick Start Guide.
Policy and Service Configuration
Policy and service configuration refers to the static system configuration that defines the way traffic is analyzed and controlled globally, in addition to the various policies available for controlling specific subscriber traffic.
A policy definition according to the customer business logic is a prerequisite for any deployment, and provides the context for the definition of the other aspects of the solution.
Policy and service configuration is created using the SCA BB Console or using the SCA BB Service Configuration API. The service configuration is compiled into a proprietary file format called PQB, which can be applied to the SCE platform through the SCA BB Console or through the "servconf" command line utility.
Note
Service configuration is detailed in the Cisco Service Control Application for Broadband User Guide and in the Cisco SCA BB Service Configuration API Programmer Guide.
Real-Time Subscriber Management and Control
Subscriber management is required to be real-time for a subscriber aware solution in a dynamic-IP or dynamic policy environment. This aspect of the solution provides the capabilities related to:
•
•
•
•
The Cisco Service Control Subscriber Manager component provides most of this subscriber related functionality and APIs.
The SCA BB solution also facilitates subscriber management using direct integration with the SCE platform. In many cases this is beneficial to service providers who may better utilize existing applications (for example, when the provider already invested in a complete Policy Server or similar system). The service provider may also decrease the number of deployed and managed network elements by eliminating the Cisco Service Control Subscriber Manager component and therefore optimize overall operational expenses.
Direct integration generally simplifies the deployment; however, the application that communicates to the SCE platform must implement some functionality that was previously provided by the Cisco Service Control Subscriber Manager. This includes: support for multiple SCE units, addressing high availability issues by supporting redundancy schemes, and different cases of fail-over.
Subscriber management integration can be implemented using two integration modes: Push and Pull. These modes utilize different sequences of events for subscriber logins. In Push mode, the external entity such as the Policy Server triggers a subscriber creation or update and provisions the information to the SCE prior to the subscriber sending data traffic. In Pull mode, the SCE identifies subscribers upon receiving data traffic belonging to an unknown (anonymous) source. It then queries the Policy Server by sending a request to provide the subscriber identity and thus triggering the login operation. The Policy Server will provision the required subscriber information back to the SCE.
Note that subscriber management and quota provisioning functionality may be implemented by two separate applications and in this case the SCE should be integrated with both of them.
Note that subscriber management and quota provisioning functionality may be implemented by two separate applications and in this case the SCE should be integrated with both of them.
More details can be found in the Cisco Service Control Management Suite Subscriber Manager User Guide, the Cisco SCMS Subscriber Manager Java API Programmer Guide, the Cisco SCMS Subscriber Manager C/C++ API Programmer Guide, and the Cisco SCMS SCE Subscriber API Programmer Guide.
Reports
The Cisco SCA BB reporting solution includes the generation, collection, and aggregation of network usage as analyzed by the SCE devices. The data is available in several granularities, and is tailored for use in several scenarios such as: network analysis and trend determination, postpaid billing, and offline auditing.
Cisco SCA BB enables the collection of Raw Data Records (RDRs) through its Collection Manager software. RDRs can be stored in a JDBC compliant database or written to file depending on their type and the use case addressed by the customer. Reporting tools (either proprietary or generic) can be used to present the collected information. The SCA BB solution includes a reporter application as part of the SCA BB Console.
Reporting is a major function in most implementations of the Cisco SCA BB solution. However, it is not directly related to Service Creation, and therefore will not be discussed here.
More details on reporting can be found in the Cisco SCMS Collection Manager User Guide.
2 Service Creation Integration Model
This chapter contains the following sections:
•
In a Service Creation environment, the Cisco SCA BB would typically integrate with a Policy Server (PS) system, which would be a part of the provider's OSS. This system would manage subscriber policies in real time, provision usage quotas for a subscriber (as well as monitor subscriber usage), and handle billing for the solution.
The system can be either an internal system that is closed to the subscriber or an open system. The internal system has no subscriber facing interfaces (assigning subscribers with their predefined service-levels and quotas, as purchased offline). The open system allows subscribers to purchase and provision their own usage policies and quotas (based on the provider definitions) through a self care portal.
The full solution depends on the functionality and capabilities of the Policy Server, with the Cisco SCA BB solution providing the network enforcement and accounting platform within the full solution.
To keep the solution synchronized with the dynamic network mappings of the subscribers, it is necessary to integrate the solution with the provider's back end systems that are responsible for IP mapping (such as DHCP, AAA).
The main aspects of the solution that concern a Policy Server vendor or developer are:
•
•
•
•
Subscriber IP mapping is also a requirement and in many cases the policy server is also responsible for subscriber IP mapping. However, it is not a mandatory functionality for the server since the mapping may also be done by integration with the back end system responsible for IP mapping (for example, DHCP server) rather than through the policy server itself, or as mentioned previously, by intercepting data from RADIUS/DHCP traffic.
Reporting in the SCA BB solution is less relevant to the real-time-integration process - it is relevant only if postpaid billing is to be provided through RDR based interfaces. Further details on integration over the reporting plane can be found in the Cisco SCMS Collection Manager User Guide (for integration using the Cisco Collection Manager software), or in the RDR-Toolkit and the Cisco Service Control Application for Broadband Reference Guide for direct integration using RDRs.
Service Configuration
The Service Configuration is static and defines the various policy profiles available as plans, products, or packages for the service providers' customers. Defining the business logic according to the service provider's policy definitions allows the provider to assign a predefined policy to subscribers according to their subscription type. A policy profile defines:
•
•
•
Service configuration is described in detail in the Cisco Service Control Application for Broadband User Guide and in the Cisco SCA BB Service Configuration API Programmer Guide.
Real Time Subscriber Provisioning and Monitoring
The SCA BB solution provides a number of APIs and interfaces that support real-time subscriber provisioning and monitoring.
•
•
SM-API
The SM-API is used for various subscriber management aspects throughout the SCA BB solution in deployments that use SM rather than direct integration. In such deployments, this API will be used by the Policy Server for defining the policy to be applied to a subscriber. The policy is identified by the policy profile (the package) ID, as defined in the service configuration. There are various use cases for the use of this API including: static introduction of a subscriber, self provisioning, and turbo-button activation.
The SM-API is provided as a client API (both non-blocking and blocking implementations) and is available in Java and C/C++ (Windows, Sparc-Solaris platform, and Red Hat Linux).
The SM-API is provided as a part of the Cisco Service Control Management Suite Subscriber Manager suite. Further details can be found in the Cisco SCMS SM Java API Programmer's Guide and in the Cisco SCMS SM C/C++ API Programmer's Guide.
SCE Subscriber API
The SCE Subscriber API is used by the Policy Server for direct integration with the SCE without involving the SM component. The API supports a variety of functions such as:
•
•
•
Network ID Association
The subscriber mapping API functionality includes the login operation to create the subscriber and, if the subscriber already exists, the modification of the subscriber attributes. This operation is invoked by the Policy Server when it needs to provision the subscriber identity and other information to the SCE. This occurs, for example, upon notification that the subscriber logged in to the network, or when the Policy Server responds to the pull request.
The login operation includes a number of parameters such as:
•
•
•
•
The login operation can be reused in order to update (add or set) the subscriber network ID when the subscriber network ID is modified (e.g. when the DHCP server assigns a different IP address), or when adding IP address instances for a subscriber with multiple IP addresses, or when modifying the subscriber policy after the subscriber is created.
Policy Provisioning
The policy profile can be assigned to a subscriber using the login operation during the initial creation of the subscriber, or when the subscriber is upgraded or downgraded and requires the enforcement of a different policy.
Note
Quota Provisioning
The quota provisioning mechanism is based on the ability to assign a quota to a subscriber for consuming a specific service and to later manage it. The SCE Subscriber API supports quota provisioning events such as:
•
•
•
•
The quota may be provisioned along with subscriber login (see Network ID Association). This can be used, for example, in cases where the Policy Server also supports quota provisioning. When the network operator's ecosystem includes a separate Quota Provisioning system, the quota may be set after and independently on the login operation.
The quota is provisioned in small portions depending on the business logic of the service provider. When the current quota of a certain service/bucket in the SCE falls below a configured threshold (due to consumption of the service by the subscriber), or becomes depleted, the SCE sends a notification event to the Quota Provisioning system. This event may be interpreted as a quota replenishment request from the subscriber. The Quota Provisioning system may respond with a quota setting or adding operation.
The changes in quota reflecting consumption of the service by the subscriber may be reported using periodical or on demand notifications of the value of the remaining quota. It may be used, for example, to show the subscriber the current status of their quota via the portal. Subscribers can optionally be notified when they breach their quota.
The remaining quota is reported to the Quota Provisioning system upon subscriber logout. In order to improve the user-experience for a subscriber accessing a service for the first time (with no quota in place), a grace period can be configured using SCA BB during which time the subscriber will be allowed to access the service until the initial quota provisioning stage is complete.
Further details on quota provisioning can be found in the Cisco Service Control Application for Broadband User Guide.
The SCE Subscriber API is currently implemented in Java.
Further details on the SCE Subscriber API can be found in the Cisco SCMS SCE Subscriber API Programmer Guide.
3 Service Creation Integration—Examples
This section contains examples of particular use cases. The examples are basic, but illustrate the use of the various interfaces for implementing business logic primitives - actual implementations might be more complex and use a larger mixture of the primitives described here.
This section contains the following subsections:
•
•
Example I—Periodic-Quota Based Services
Business Use-Case
Traffic is divided into two services:
•
•
Users have a monthly quota (not accumulated across months) for general internet access. When the quota is depleted, the traffic rate is reduced to a dial-up rate of 64 kbps. Access to the Premium Content is not counted as part of the monthly quota and is not reduced to dial-up rates.
When the quota is depleted, the subscriber is notified using the subscriber-notification event.
Overview
Figure 3 shows an overview of the implementation of this business use case. It is recommended that you return to this section after reading the step-by-step description.
Figure 3 Periodic Quota—Scenario Overview
Step-by-Step Implementation
Step I—Policy Configuration
Defining the Premium Content Service
To define the Premium Content Service:
Step 1
For simplicity, this assumes that the Premium Content service is defined based on a list of servers.
Figure 4 Flavor Settings Window—Flavors Editing Dialog
Step 2
Figure 5 Service Configuration Editor Window—Premium Browsing Service
Assigning Services to Quotas
The business logic used in this example specifies that a subscriber's traffic will be partitioned between General Internet Access and Premium Content. General Internet Access is quota controlled from one bucket (both upstream and downstream consuming from the same bucket). Premium Content traffic will not be quota controlled (but rather post paid charged).
To assign services to quotas:
Step 1
Figure 6 Package Settings Window—General Tab
Step 2
Figure 7 Package Settings Window—Quota Management Tab
The package is created as shown in Figure 8.
Figure 8 Service Configuration Editor Window—Premium Browsing Service
Step 3
Figure 9 Add New Rule to Package—General Tab
The Free Premium Content package now contains two service rules as shown in Figure 10.
Figure 10 Service Configuration Editor Window—Premium Browsing Service
Step 4
Buckets can normally be used to manage upstream volume, downstream volume, and sessions. This example deals only with volume based quota (Figure 11).
Figure 11 Edit Rule for Service Window—Usage Limits Tab
The Premium Browsing service is not associated with a quota bucket, and therefore will not be quota limited. Use of this service will still be reflected in the quota usage notifications using the SCE Subscriber API.
An overview of the monthly quota package is shown in Figure 12.
Figure 12 Service Configuration Editor Window—Premium Browsing Service
Defining a Grace Period
A grace period can be configured in SCA BB to improve the user-experience for a subscriber accessing a service for the first time. The grace period allows the subscriber to access a service until the initial quota provisioning stage is complete. The grace period should be configured to be relatively short because it allows subscribers to get services regardless of the allocated quota amount even when the subscriber does not have available balance. The grace period reflects the willingness of the provider to credit the subscriber with service assuming that the balance is positive. This behavior is fully configurable and depends on the provider business logic.
Step 1
Figure 13 Advanced Service Configuration Options Window
Defining Quota-RDR Settings
Quota RDRs are the internal triggers for quota notifications that are part of the SCE subscriber API. When using the quota functionality, make sure that all RDRs are enabled.
The period of remaining quota RDRs should be set based on the operator's preferences.
The threshold value for RDR generation should be determined by the operator based on the size of the quota chunks provisioned and the expected bandwidth consumed by the service. Quota threshold notifications are intended to allow the policy server to provision a new quota chunk before an existing quota is depleted, thus enabling service continuity while the subscriber has a positive account balance.
The system must be configured to enable the RPC server and to send RDRs - that will be converted into notifications by the SCE Subscriber API - to the internal RDR listener. Configuration is done through the SCE CLI using the following command:
#>RDR-formatter destination 127.0.0.1 port 33001 category number 4 priority 100Defining the Control Scheme
The package BW controllers have to be defined. The total bandwidth allocated to a subscriber will be limited to 1 Mbps.
"Depletion BWC", designed for limiting the breached service traffic must also be defined (upstream and downstream).
Step 1
Figure 14 Package Settings Window—Subscriber BW Controllers Tab
All services will be placed by default under the total BW controller.
After the General-Internet-Access quota is depleted, this service will be mapped to a subscriber BW controller allowing it to consume up to 64 kbps. The subscriber should be notified that their bandwidth has been reduced due to quota depletion (through subscriber-notification).
Using the subscriber notification capability, subscribers can be put automatically into a state where their browsing session is redirected to a predefined web portal. The web portal page informs subscribers that their quota has depleted and therefore their Internet-Access-Speed is reduced.
Step 1
Figure 15 Depletion Window
Step 2
Figure 16 Subscriber Notification Settings Window
Step 3
Step 4
Figure 17 Edit Rule for Service Window—Breach Handling Tab
Note
Step II—Building the Real-Time Quota Provisioning Process
The real-time quota provisioning process for this business use case is based on a subscriber balance manager that allocates subscriber quota upon request (through Quota Below Threshold and Quota Depleted notifications), based on quota availability.
To implement this business logic, the Policy Server uses the SCMS SCE Subscriber API in order to receive quota requests and to provision the quota accordingly through the Quota Update method.
There are two main use cases:
•
•
Further details on using these operations can be found in the Cisco SCMS SCE Subscriber API Programmer Guide.
Step III—Acting Upon Depletion Events
Depletion events are signaled to the Policy Server through the Quota Depleted notification event. The Policy Server is required to receive such notifications to run some predefined logic. In this specific example, where the breach behavior is implemented inside SCA BB, the Policy Server is only required to log the event details.
Handling Cases of Subscriber Log-Out
When subscribers log out of the network, either intentionally or implicitly (for example, due to session expiration), their records are removed from the SCE until they log back in.
In such a case, a notification is triggered. The notification includes the amount of quota left in the subscriber's buckets. This notification allows the Policy Server to add the remaining quota back to the subscriber's balance so that no quota is lost and to process the amount of used quota to prevent revenue leakage.
This sequence of events is shown in Figure 18.
Figure 18 Log-Out Handling Behavior Definition
Example II—Turbo Button With "Free Usage"
Business Use Case
The business use case is a simplified quota based scenario. A subscriber is assigned a policy that allows for a certain access speed. Usage on all services is consumed from a single quota bucket.
Subscribers can use a web interface to boost their access speed for a limited period of time using a "Turbo Button."
During this period, subscribers are granted an increased-speed, with quota-free access. When the time period is over, subscribers are reassigned their regular access plan, and reassigned their remaining quota.
Overview
Figure 19 shows an overview of how this business use case is implemented. It is recommended that you return to this section after reading the step-by-step description.
Figure 19 Turbo Button—Scenario Overview
Figure 19 shows the sequence of events when direct integration is used. The policy provisioning can also be provisioned through the SM API in SM deployments.
Step-by-Step Implementation
Step I: Policy Configuration
Defining the Quota Based Package
The quota based package is built and managed in a similar manner to the previous example. See the Step II—Building the Real-Time Quota Provisioning Process for details on how to build the quota related portion of this policy.
Defining the "Turbo Button" Package
This package will be provisioned to a subscriber once they select a "Turbo button" (and deprovisioned when the "turbo" period is over). This package will boost the subscriber's total access speed and be free of quota charging. All the services of this package must be defined with "unlimited quota."
Step 1
Figure 20 Package Settings Window—Subscriber BW Controllers Tab
The overview of the "Turbo" package is shown in Figure 21.
Figure 21 Service Configuration Editor Window—Premium Browsing Service—Turbo
Step II—The Real-Time Provisioning Process
This section refers to the logic that must be implemented by the Policy Server - using the SCA BB Subscriber APIs, interfaces, and tools - to support the required business logic.
Quota Provisioning
Quota provisioning in this example is identical to that of the previous use case. However, upon a package change, a remaining-quota-notification is generated by the SCE, reflecting the subscriber's remaining quota.
Note
Turbo Button Activation
The vendor must first build the front end for the activation of the turbo button. For this example, this will be a web page where subscribers can authenticate themselves and select to temporarily upgrade their access package using a turbo button.
Step 1
Figure 22 Turbo Button Window
Step 2
Turbo Button Deactivation
The Policy Server is responsible for restoring the original package once the accelerated-speed, free usage period allowed by the turbo button is over.
Step 1
Step 2
Further details can be found in the Cisco SCMS SCE Subscriber API Programmer Guide.
4 Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.
5
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco Ironport, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flip Video, Flip Video (Design), Flipshare (Design), Flip Ultra, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website 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. (0907R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.
Feedback