Cisco Service Control Policy Integration Solution Guide, Release 4.0.x
Available Languages
Table Of Contents
Cisco Service Control Policy Integration Solution Guide, Release 4.0.x
Policy and Service Configuration
Real-Time Subscriber Management and Control
Service Creation Integration Model
Real-Time Subscriber Provisioning and Monitoring
Cisco Service Control Subscriber Manager API (SM-API)
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 Policy Integration Solution Guide, Release 4.0.x
Revised: May 27, 2013, OL-29105-01
Note
This document supports all 4.0.x releases.
1 Solution Overview
This chapter describes the logical components that make up the Cisco Service Control Application for Broadband (Cisco SCA BB) solution. The Cisco SCA BB solution can serve as a platform for service creation for a service provider.
This chapter contains these sections:
•
•
Figure 1 and Figure 2 illustrate the high-level architecture of the Cisco SCA BB solution when integrated in a typical service provider environment. These figures show the major components and the relationship between each component. Figure 1 shows the Cisco SCA BB solution including the Subscriber Manager component. Figure 2 diagram shows direct integration with the Cisco Service Control Engine (Cisco SCE) platform (also known as SM-less integration). In this case, the Cisco Service Control Subscriber Manager component is not included and the third-party Policy Server communicates directly with the Cisco SCE platform.
Figure 1 Cisco SCA BB Solution System Including Subscriber Manager
Figure 2 Cisco SCA BB Solution System—Without Subscriber Manager Integration
Cisco SCE Platform
The Cisco SCE platform is a hardware-accelerated, deep packet inspection (DPI) device that forms the core of the solution. In a service-creation scenario, the Cisco SCE platform is deployed inline on the subscriber IP data path. Cisco SCE provides DPI, and application and 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 Network Management System (NMS)—over CLI, SNMP—and a number of proprietary tools used for service configuration, subscriber management, and multi-unit configuration. All the tools are combined in the Cisco SCA BB Console application. The platform is subscriber aware and can be used for usage-based services, for example, subscriber-level quota management and billing. For details on subscriber awareness, see, the "Real-Time Subscriber Management and Control" section. The platform also generates network usage data at various granularities for monitoring and analysis purposes.
For details on the Cisco SCE platform and its various configuration interfaces, see the Cisco SCE 2000 Installation and Configuration Guide and the Cisco SCE 2000 QuickStart 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 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 by using the Cisco SCA BB Console or using the Cisco SCA BB Service Configuration API. The service configuration is compiled into a proprietary file format called PQB. A PQB can be applied to the Cisco SCE platform through the Cisco SCA BB Console or through the servconf command line utility.
Note
For details on the service configuration, see these guides:
•
•
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 Cisco SCA BB solution also facilitates subscriber management by using direct integration with the Cisco SCE platform. In many cases, this direct integration is beneficial to service providers who may better utilize existing applications. For example, when the provider has 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 optimizing overall operational expenses.
Direct integration generally simplifies the deployment; however, the application that communicates to the Cisco SCE platform must implement some functionality that Cisco Service Control Subscriber Manager provided earlier. These include support for multiple Cisco SCE units, addressing high-availability issues by supporting redundancy schemes, and various 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 Cisco SCE before the subscriber starts sending data traffic. In Pull mode, the Cisco 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 provisions the required subscriber information back to the Cisco SCE.
Note
For details, see these guides:
•
•
•
•
Reports
The Cisco SCA BB reporting solution includes the generation, collection, and aggregation of network usage as analyzed by the Cisco SCE devices. The data is available in several granularities. The data is also 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 Java Database Connectivity (JDBC)-compliant database or written to file depending on their type and the instance addressed by the customer. Reporting tools (either proprietary or generic) can be used to present the collected information. The Cisco SCA BB solution includes a reporter application as part of the Cisco 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 hence it is not discussed here.
For more details on reporting, see the Cisco SCMS Collection Manager User Guide.
2 Service Creation Integration Model
This chapter contains these 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 Operations Support System (OSS) of the service provider. 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 entire 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 solution.
To keep the solution synchronized with the dynamic network mappings of the subscribers, it is necessary to integrate the solution with the back-end systems, of the service provider, 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, because, the mapping can be achieved by integrating the Policy Server with the back end system responsible for IP mapping (for example, DHCP server) rather than through the policy server itself. Subscriber IP mapping can also be achieved by intercepting data from RADIUS and DHCP traffic.
Reporting in the SCA BB solution is less relevant to the real-time-integration process. Reporting is relevant only if postpaid billing has to be provided through RDR-based interfaces.
For more details on integration over the reporting plane, see these guides:
•
•
Service Configuration
The service configuration is static and defines the various policy profiles available as plans, products, or packages for the subscribers of a service provider. Defining the business logic, according to the policy definitions created by the service provider, allows the provider to assign a predefined policy to subscribers according to their subscription type. A policy profile defines:
•
•
•
For details on service configuration, see these guides:
•
•
Real-Time Subscriber Provisioning and Monitoring
The Cisco SCA BB solution provides a number of APIs and interfaces that support real-time subscriber provisioning and monitoring.
•
•
Cisco Service Control Subscriber Manager API (SM-API)
The SM-API is used for various subscriber management functions throughout the Cisco SCA BB solution in deployments that use SM rather than direct integration. In such deployments, Policy Server use the SM-API to define the policy to be applied to a subscriber. The policy profile (the package) ID identifies the policy, as defined in the service configuration. This API can be used in various instances, such as, static introduction of a subscriber, self provisioning, and turbo-button activation.
The SM-API is provided as a client API (both nonblocking and blocking implementations) and is available in Java and C/C++ (Windows, Sparc Solaris, and Red Hat Linux).
The SM-API is provided as a part of the Cisco Service Control Management Suite Subscriber Manager suite.
For more details on SM-API, see the Cisco SCMS SM Java API Programmer's Guide and the Cisco SCMS SM C/C++ API Programmer's Guide.
Cisco SCE Subscriber API
The Policy Server use the Cisco SCE Subscriber API for direct integration with the Cisco SCE without involving the Cisco Service Control Subscriber Manager component. The API supports various functions such as:
•
•
•
Network ID Association
The subscriber mapping API functionality includes the login operation to:
•
•
The Policy Server invokes this operation when the server has to provision the subscriber identity and other information to the Cisco SCE. For example, when the server receives a notification that a subscriber has logged in to the network, or when the server responds to a pull request.
The login operation includes a number of parameters, such as:
•
•
•
•
The login operation can be reused to update (add or set) the subscriber network ID in these scenarios:
•
•
•
Policy Provisioning
The policy profile can be assigned to a subscriber by using the login operation in these scenarios:
•
•
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 manage it later. The Cisco SCE Subscriber API supports quota provisioning events, such as:
•
•
•
•
The quota may be provisioned along with subscriber login (see the "Network ID Association" section). This can be used, for example, in cases where the Policy Server also supports quota provisioning. When the ecosystem of the network operator 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 or bucket in the Cisco SCE falls below a configured threshold (due to consumption of the service by the subscriber), or becomes depleted, the Cisco SCE sends a notification event to the Quota Provisioning system. This event is interpreted as a quota replenishment request from the subscriber. The Quota Provisioning system responds with a quota setting or adding operation.
The changes in quota reflecting consumption of the service by the subscriber is reported by using periodical or on-demand notifications of the value of the remaining quota. It may be used, for example, to show the subscriber the status of their quota through 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. To improve the user experience of a subscriber accessing a service for the first time (with no quota in place), a grace period can be configured by using the Cisco SCA BB. During this grace period, the subscriber can be allowed to access the service until the initial quota provisioning stage is complete.
For details on quota provisioning, see the Cisco Service Control Application for Broadband User Guide.
The Cisco SCE Subscriber API is currently implemented in Java.
For details on the Cisco SCE Subscriber API, see the Cisco SCMS SCE Subscriber API Programmer Guide.
3 Service Creation Integration: Examples
This chapter contains examples of particular instances. The examples are basic, but illustrate the use of the various interfaces for implementing business logic primitives. The actual implementations might be more complex and use a larger mixture of the primitives described here.
This chapter contains these subsections:
•
•
Example I: Periodic Quota-Based Services
Business Scenario
Traffic is divided into two services:
•
•
Subscribers 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 by using the subscriber-notification event.
Overview
Figure 3 shows an overview of the implementation of this business scenario. We recommend 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 example 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 the traffic for a subscriber is 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 is not quota controlled (but rather post paid charged).
To assign services to quotas, complete these steps:
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 (see 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 is not quota limited. But use of this service reflects in the quota-usage notifications using the Cisco 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. Configure a relatively short grace period. A short grace period 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.
To define a grace period, use the Advanced Service Configuration window (see Figure 13).
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 Cisco SCE Subscriber API. When using the quota functionality, ensure that all RDRs are enabled.
Set the period of the remaining quota RDRs based on the preferences of the operator.
The operator must determine the threshold value for RDR generation based on the size of the quota chunks provisioned and the expected bandwidth consumed by the service. Quota threshold notifications allow the policy server to provision a new quota chunk before an existing quota is depleted. Hence, these notifications enable service continuity while the subscriber has a positive account balance.
Configure the system to enable the RPC server, and to send RDRs to the internal RDR listener. These RDRs are converted into notifications by the Cisco SCE Subscriber API. Use this command to configure the system using the Cisco SCE CLI:
# RDR-formatter destination 127.0.0.1 port 33001 category number 4 priority 100Defining the Control Scheme
In this section, package bandwidth controllers are defined. The total bandwidth allocated to a subscriber is limited to 1 Mbps. "Depletion BWC", designed for limiting the breached service traffic, is also defined (upstream and downstream).
To define a control scheme, define the package BW controllers and the Depletion BWC by using the Package Settings window (Figure 14).
Figure 14 Package Settings Window—Subscriber BW Controllers Tab
By default, all services are placed 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. Notify the subscriber, through subscriber-notification, that their bandwidth has been reduced because of quota depletion.
Defining 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.
To define a subscriber notification, complete these steps:
Step 1
Figure 15 Depletion Window
Step 2
Figure 16 Subscriber Notification Settings Window
The destination URL directs the subscriber to the web portal page created in Step 1.
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 scenario is based on a subscriber balance manager that allocates subscriber quota upon request (through the Quota Below Threshold and the Quota Depleted notifications), based on quota availability.
To implement this business logic, the Policy Server uses the Cisco SCE Subscriber API to receive quota requests and to provision the quota accordingly by using the Quota Update method.
There are two main scenarios:
•
The Cisco SCE Subscriber API events such as LOGINREQUEST and LOGINPULL-RESPONSE are optimized to allow sending all the subscriber information to the Cisco SCE. If a single Policy Server performs all parts of the subscriber provisioning including quota provisioning, use these events for Policy Profile and Quota Updates.
•
For details on using these operations, see 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 Cisco SCA BB, the Policy Server is required only to log the event details.
Handling Cases of Subscriber Logout
When subscribers log out of the network, either intentionally or implicitly (for example, because of session expiration), their records are removed from the Cisco SCE until they log back in.
In such a case, a notification is triggered. The notification includes the amount of quota left in the bucket of the specific subscriber. This notification allows the Policy Server to:
•
•
This sequence of events is shown in Figure 18.
Figure 18 Logout Handling Behavior Definition
Example II: Turbo Button with "Free Usage"
Business Scenario
This business scenario 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 using a "Turbo Button."
During this period, subscribers are granted 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 scenario is implemented. We recommend that you return to this section after reading the step-by-step description.
Figure 19 Turbo Button Scenario Overview
This figure shows the sequence of events when direct integration is used. Policy provisioning can also be done through the Subscriber Manager API in Subscriber Manager 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 ("Example I: Periodic Quota-Based Services" section). 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
The "Turbo Button" package is provisioned to a subscriber after the subscriber select a "Turbo button". This package boosts the total access speed of the subscriber and frees the subscriber from quota charging for a specific period. All the services of this package must be defined with "unlimited quota." The Turbo Button package is deprovisioned when the "turbo" period is over.
To define Turbo Button package, define the package bandwidth controllers (BWC) by using the Package Settings window (see Figure 20).
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—Real-Time Provisioning Process
This section refers to the logic that the Policy Server must implement—using the Cisco 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 example ("Example I: Periodic Quota-Based Services" section). However, upon a package change, the Cisco SCE generates a remaining-quota-notification, reflecting the remaining quota of the subscriber.
Note
Turbo Button Activation
The vendor must first build the front end for the activation of the Turbo Button. For this example, the front end is a web page, where subscribers can authenticate themselves and select to upgrade their access package temporarily by using a Turbo Button.
To activate the Turbo Button, complete these steps:
Step 1
Figure 22 Turbo Button Front End
Step 2
Turbo Button Deactivation
The Policy Server is responsible for restoring the original package after the accelerated-speed, free usage period allowed by the turbo button is over.
Step 1
Step 2
For more details, see the Cisco SCMS SCE Subscriber API Programmer Guide.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html.
Subscribe to What's New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: 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. (1110R)
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.
© 2013 Cisco Systems, Inc. All rights reserved.
Feedback