|
Cisco Service Center Release |
Part Number |
Publication Date |
|---|---|---|
|
Release 3.0.5 |
OL-10609-02 |
November, 2006 |
Description of Changes
Updated documentation for Release 3.0.5. No major changes or new features were added to this release.
|
Release 3.0.3 |
OL-10609-01 |
May, 2006 |
Description of Changes
The Cisco SCA BB Introduction to Policy Integration is a new guide to aid service providers and system integrators in Service Creation.
This document is for service providers and system integrators who will be integrating the Cisco Service Control Application for Broadband solution (referred to as Cisco SCA BB) with external components belonging to the customer ecosystem in order to provide a complete Service Creation solution. This document covers only the policy integration aspect. The document assumes that the reader is familiar with the Cisco SCA BB solution.
This guide covers the following topics:
|
Chapter |
Title |
Description |
|---|---|---|
|
Chapter 1 |
Describes the SCA BB solution and how it can serve as a platform for service creation for a service provider | |
|
Chapter 2 |
Describes the model used for service creation integration solution creation | |
|
Chapter 3 |
Describes the service integration use case examples |
This document provides an overview of the relevant interfaces. For more detailed descriptions please refer to the relevant user guides.
This application note makes reference to several documents and software that the reader should have.
SCMS SM Software Package: Cisco SCMS Subscriber Manager User Guide
Cisco SCMS SCE Subscriber API Programmer Guide
SCA BB Software Package: Cisco Service Control Application for Broadband User Guide, Cisco SCA BB Service Configuration API Programmer Guide, and Cisco SCMS Collection Manager User Guide
RDR Toolkit: For RDR Integration if needed
Subscriber Integration White Paper: Paper on subscriber integration concepts
This document uses the following conventions:
|
Convention |
Description |
|---|---|
|
boldface font |
Commands and keywords are in boldface. |
|
italic font |
Arguments for which you supply values are in italics. |
|
[ ] |
Elements in square brackets are optional. |
|
{x | y | z} |
Alternative keywords are grouped in braces and separated by vertical bars. |
|
[x | y | z] |
Optional alternative keywords are grouped in brackets and separated by vertical bars. |
|
string |
A nonquoted set of characters. Do not use quotation marks around the string, or the string will include the quotation marks. |
|
|
Terminal sessions and information that the system displays are in |
|
|
Information you must enter is in |
|
|
Arguments for which you supply values are in |
|
® |
This pointer highlights an important line of text in an example. |
|
< > |
Nonprinting characters, such as passwords, are in angle brackets. |
|
[ ] |
Default responses to system prompts are in square brackets. |
|
!, # |
An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line. |
Note
Means reader take note. Notes contain helpful suggestions or references to materials not covered in this manual.
Caution
Means reader be careful. In this situation, you might do something that could result in loss of data.
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Cisco documentation and additional literature are available in a CD-ROM package that ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Cisco documentation is available in the following ways:
Registered Cisco Direct Customers can order Cisco Product documentation from the networking Products MarketPlace:
Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Attn Document Resource Connection Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-9883
We appreciate your comments.
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at any time, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to http://www.cisco.com.
The Cisco Technical Assistance Center (TAC) website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website http://www.cisco.com/tac.
P3 and P4 level problems are defined as follows:
P3—Your network is degraded. Network functionality is noticeably impaired, but most business operations continue.
P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to http://tools.cisco.com/RPF/register/register.do.
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at http://www.cisco.com/tac/caseopen.
If you have a priority level 1 (P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml.
P1 and P2 level problems are defined as follows:
P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.
P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.
This chapter 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.
The following two diagrams 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.
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 4xGBE Installation and Configuration Guide and in the Cisco SCE 2000 4xGBE Quick Start Guide.
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
For policy enforcement, the policy and service configuration needs to be applied prior to subscriber traffic coming through the SCE.
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.
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:
Mapping network IP addresses, or other network identifiers, to managed subscriber entities
Real-time control of the policy applied to a subscriber
Application of usage-quota restrictions
Using other aspects of dynamic policy management such as self-care portals, turbo-buttons, etc.
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 (e.g. 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 thereby 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.
The SCE is also able to extract subscriber identity information by intercepting RADIUS or DHCP traffic (when it comes through the box), which allows for a level of "automatic" provisioning of the subscribers. It may significantly simplify the initial login process of subscribers while further actions for policy update and quota management are done by the Policy Server and the Quota Management system.
More details can be found in the Cisco SCMS Subscriber Manager User Guide, the Cisco SCMS Subscriber Manager Java API Programmer's Guide, the Cisco SCMS Subscriber Manager C/C++ API Programmer's Guide, and the Cisco SCMS SCE Subscriber API Programmer's Guide.
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.
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 backend 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:
The service-configuration plane
The real-time subscriber policy profile mapping
Quota provisioning
Monitoring plane
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 backend system responsible for IP mapping (e.g. 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.
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:
The per-service and overall QoS allocated to a subscriber
The definitions of allowed and restricted (blocked) services that the subscription includes
The structure of quotas on which the policy is based (i.e. which services are consumed from which quota, which services are not accounted for usage, etc.) and the corresponding definitions to be applied when subscribers' usage exceeds their allowed quota.
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.
The SCA BB solution provides a number of APIs and interfaces that support real-time subscriber provisioning and monitoring.
Subscriber Manager API (SM-API)—Used for updating, querying, and configuring the SCMS Subscriber Manager in deployments that include the SM component.
SCE Subscriber API—Used for SM-less deployments and for quota management purposes.
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 apply 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.
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—An association between a unique subscriber identifier, subscriber network identifier, and policy profile or package assigned to the subscriber.
Policy provisioning—An association between a unique subscriber identifier and a policy profile or package assigned to the subscriber.
Quota provisioning—An association between a unique subscriber identifier and a quota amount that is available for service consumption.
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. The Policy Server invokes this operation 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:
Subscriber identifier (OSS ID)—Uniquely identifies the subscriber
Subscriber network ID—Can represent multiple instances of IP address, IP range, VLAN, and tunnel ID
(Optional) Policy profile identifier—The identifier of the policy profile assigned by the Policy Server and preconfigured during Service Configuration phase
(Optional) Initial service quota—The initial service quota, if available, for the subscriber
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.
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
The policy may be provisioned this way regardless of the integration mode, i.e. push or pull.
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:
Quota setting and addition
Notification that the quota falls below a configurable threshold
Notification that the quota is completely depleted
Notification of the value of the remaining quotas
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 of 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.
This chapter 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.
Traffic is divided into two services:
General Internet Access—General broadband Internet access.
Premium Content—Access to specific content sites that the broadband operator is marketing as 'premium content'.
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.
The following figure 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.
To define the Premium Content Service:
Define the list of servers for the Premium Content service using the Flavors Settings dialog.
For simplicity, this assumes that the Premium Content service is defined based on a list of servers.
Modify the services of the Premium Browsing service such that it is based on the HTTP protocol together with the PremiumContent flavor that contains the list of designated servers defined in Step 1.
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:
Add a new package to the Premium Browsing service called Free Premium Content:
Set quota management to external control using the Quota Management tab:
The package is created:
Add a new rule to the Premium Browsing service:
The Free Premium Content package now contains two service rules.
Use the Edit Rule for Service dialog box and the Usage Limits tab to define all other services (except PremiumBrowsing) as consuming quota from bucket number 1 for both upstream and downstream traffic.
Buckets can normally be used to manage upstream volume, downstream volume, and sessions. This example deals only with volume based quota:
The PremiumBrowsing 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 the following figure.
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.
Use the Advanced Service Configuration Dialog box to define the grace period.
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 100
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).
Define the package BW controllers and the Depletion BWC using the Package Settings dialog box.
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.
Design an appropriate web page.
Define a subscriber notification using the Subscriber Notifications Settings dialog box.
The destination URL directs the subscriber to the web portal page created in step 1.
Select the action to be taken upon breach. This action maps all the services that consume from the General-Internet-Traffic Quota (bucket 1) to the Depletion Bandwidth Controller. The subscriber notification also needs to be selected for activation.
Note
The implementation brought here (using SCA BB breach-handling behavior) is useful for implementing a simplified quota breach behavior. For implementing more complex control logic, the Policy Server can use the quota-depletion-notification as a trigger for changing the subscriber package. This allows the Policy Server a higher flexibility in the nature of control that is enforced over a subscriber upon quota depletion.
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:
A subscriber logs in with no quota—The Policy Server provisions the quota based on the subscriber's balance in response to a Quota Depleted event that is generated by the SCE. If the Policy Server handles both subscriber mapping and quota provisioning, the quota may be provisioned along with the login operation. The SCE Subscriber API events such as LOGIN-REQUEST event and LOGINPULL-RESPONSE event are optimized to allow sending all the subscriber information to the SCE. It is recommended to use these events for Policy Profile and Quota updates when all parts of the subscriber provisioning including quota provisioning are performed by a single Policy Server.
Quota chunk allocated to a subscriber is about to run out—The Policy Server provisions quota based on the subscriber's balance and in response to a Quota Below Threshold event generated by the SCE.
Further details on using these operations can be found in the Cisco SCMS SCE Subscriber API Programmer Guide.
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.
When subscribers log out of the network, either intentionally or implicitly (e.g. 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 the following diagram.
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.
The following figure 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.
The previous diagram shows the sequence of events when direct integration is used. The policy provisioning can also be provisioned through the SM API in SM deployments.
The quota based package is built and managed in a similar manner to the previous example - see Step II: Building the real-time quota provisioning process for details on how to build the quota related portion of this policy.
This package will be provisioned to a subscriber once they select a "Turbo button" (and de-provisioned 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".
Define the package BW controllers using the Package Settings dialog box.
The overview of the "Turbo" package is shown in the following figure.
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 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
Upon package change, the subscriber's balance is not changed. This means that when the "Turbo time" is over, the quota buckets are in the same state as they were before the "Turbo time".
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.
Build the front end for subscriber activation.
After the turbo button is selected, the Policy Server should provision the "Turbo Button" package for the subscriber to the SCA BB solution (this is done through the SCE Subscriber API in the case of direct integration, or using the SM-API otherwise).
The Policy Server is responsible for restoring the original package once the accelerated-speed, free usage period allowed by the turbo button is over.
The Policy Server restores the original package. This is done using the SCE Subscriber API in the case of direct integration or using the SM-API otherwise.
The Policy Server re-provisions quota/s when it is needed. Note that during the Turbo Button active period, the quota is not changed; the subscriber has the same amount of quota when the Turbo Button period ends. When the subscriber accesses the service after the Turbo Button period, the quota starts to be consumed as usual and may need to be replenished in the normal way. This is done using the SCE Subscriber API (set primitive) triggered by the Quota Below Threshold or Quota Depleted notification.
Further details can be found in the Cisco SCSM SCE Subscriber API Programmer Guide.