This chapter
provides an overview of the Subscriber Service Controller (SSC)
which provides extended centralized PCRF and SPR functionality in
Cisco PCC solution and manages data related to service usage and subscriber
profile for IP-CAN session.
PCC Solution Elements
This section
provides a brief overview of PCC solution components.
The Cisco Policy and
Charging Control (PCC) solution includes following functional entities:
Intelligent Policy
Control Function (IPCF)
This section
briefly describes IPCF.
IPCF provides policy
control and charging rule functions in a core network. IPCF acts
as a Policy Charging and Rules Function (PCRF) supplemented with
usage monitoring capability that enables policies around data consumption.
IPCF interfaces with Policy Charging and Enforcement Function (PCEF)
over standard Gx interface.
Cisco IPCF is compliant
with 3GPP standard in operator’s core network. It performs following
key functions:
- Derive and authorize
the QoS information for the service data flow for session as well
as bearer use.
- Select appropriate
charging criteria and mechanism apt for data usage.
- Provide network control
regarding the service data flow detection and gating.
- Ensure that the PCEF
user plane traffic treatment is in accordance with user’s subscription
profile.
- Correlate service and
charging information across PCEF and Application Function (AF).
IMPORTANT:
For more information
on IPCF function and supported interfaces, refer Cisco ASR 5000 Series
Intelligent Policy Control Function Administration Guide.
Subscriber Service
Controller (SSC)
This section
briefly describes SSC.
SSC provides the SPR
functionality for the Cisco PCC solution that is compliant with
3GPP R8, and uses an extended implementation of 3GPP Sh messaging
for exchanging static as well as dynamic subscriber profile data
with IPCF. SSC allows the enforcement of aggregate rules supporting
volume usage across groups of subscribers sharing common account.
It also provides optional decision center functionality.
SSC provides a centralized
and simplified policy management for the network. It interfaces with
IPCF over Sp interface
which is based on standard Sh protocol,
for subscriber profile and usage related transactions. SSC also
supports a proprietary interface to receive event notification data
from IPCF.
Policy Provisioning
Tool (PPT)
This section
briefly describes PPT.
The PPT is a GUI-based
policy and profile management tool in the PCC solution that allows
operators to perform subscriber policy provisioning and management functions.
The PPT interfaces
with IPCF as well as SSC to provide centralized policy management interface
for operators.
IMPORTANT:
For more information
on PPT function and supported interfaces, refer PolicyProvisioning
Tool Installation and Administration Guide.
SSC Deployment and
Interfaces
This section describes
SSC deployment in a network and various interfaces it uses to communicate
with other components of PCC solution and external applications
in the network.
SSC in PCC Environment
In a given PCC environment
SSC can be deployed along with other components of Cisco PCC solution,
such as IPCF and PPT.
Following figure describes
a network scenario where SSC is deployed with other PCC components
and external applications.
Figure 2. SSC Deployment Scenario
Interfaces
SSC supports following
network interfaces for communication with PCC components and other
external applications such as OSS, BSS or CRM:
- Sp: This interface
is used by SSC to communicate with IPCF for subscriber profile operations.
Such as getting or updating the subscriber profile, periodically
or at the end of session. Subscribing to profile change notifications,
the Sp interface is also used by SSC to query data related to usage
and balance. Sp interface uses a standard Sh protocol. SSC uses
Sp interface to exchange information such as QoS profile, dynamic
rules and time of day objects with IPCF.
- XML-RPC over HTTP:
This interface is used by SSC to exchange information with PPT application.
This interface is used over HTTP protocol. SSC uses the XML-RPC
interface to exchange information such as data plans, SMS and e-mail
notification templates, subscription tires and dynamic profile attributes
with PPT application.
- SOAP/XML:
This interface is used by SSC to connect to external Operation Support
Systems (OSS) or Billing Support Systems (BSS) and exchange profile
and usage data.
- FTP/SNMP:
This interface is used by SSC to connect to Web Element Manager
(WEM) and exchange SNMP traps for SSC as well as administrative
data.
- SMTP: This interface
is used by SSC to send the e-mails containing event notification
information, to subscribers thru an e-mail server.
- SMPP: This interface
is used by SSC to send the text messages containing event notification
information, to subscribers thru the Short Message Service Center (SMSC).
- Telnet or SSH:
These interfaces are used by SSC to provide administration and configuration
functionality using Command Line Interface (CLI). These are deployed
over RS-232 connection.
- Open Ud: This interface
allows SSC to query data from other nodes or LDAP servers including
User Data Repository (UDR). It allows SSC to integrate in the network by
supporting transactions with multiple third party databases.Using
this interface data can be written or read from existing Light weight
Directory Access Protocol (LDAP) or 3GPP R9 Ud compliant databases.
SSC can act as Ud server or Ud client for other PCC solution components. When
acting as Ud server, SSC allows other components of PCC solution
such as CRM and OSS or BSS to query data stored in SSC. It can also
send notifications to these components when this data is updated.
When acting as Ud client, SSC can query and fetch data from other
PCC solution components.
- Management Interface:
This interface is used by SSC for configuration and scheduling of
nodes in a deployment cluster. The system controller component of
this interface is used for configuration and management of the SSC
deployment. The scheduler component is used to push the SSC performance
data to Web Element Manager (WEM). The log daemon component is used
to log important SSC host parameters.
- EN: This is the
Event Notification interface and used by SSC to receive a notification
trigger from IPCF upon execution of certain actions, such as provisioning
rules to Policy Charging and Enforcement Function (PCEF). SSC can
communicate with primary and backup interface for notifying the
event to subscriber using either e-mail or SMS. Primary interface
is used for delivering the notification, where as backup interface
can be used as a temporary provision in case of failure of primary interface.
Features and Functionality
This section
describers the features and functions supported by SSC.
Following features
are described in this section:
Bulk Load Provisioning
This section
briefly describes bulk load provisioning for subscriber profile.
SSC database needs
to provision subscriber profiles, so that IPCF can process the policy
rules using these profiles from SSC and enable the subscriber specific policy
control. SSC provides a mechanism to bulk load this profile data,
provided that such data is available in specified CSV format as
shown below.
<MSISDN,IMSI,TIER_NAME,ENABLE_EMAIL,SUB_EMAIL,ENABLE_SMS,SUB_STATUS,PLAN_NAME,SUB_OPT_OUT,BILL_START_DT,SUB_TYPE,SUB_ORDER,SUB_START_DT,FLAG_LIST
>
The bulk load script
Bulk_load_sub is located in localhome/ssc/tools folder.
You need to execute this script with administrative user privileges,
ensuring that Oracle is up and running during the provisioning process.
Depending upon composition
of the subscriber profile, CSV file may contain fields similar to
following fields:
- Mobile Subscriber ISDN
Number (MSISDN): A character data type that indicates subscriber’s
MSISDN.
- International Mobile
Subscriber Identity (IMSI): A character data type that indicates
subscribers IMSI.
- Tire Name: A character
data type that indicates the subscription tire associated with this
subscriber.
- Enable E-mail: A
numeric data type that indicates e-mail is being used to send the
notifications to this subscriber.
- Sub E-mail: A Character
data type that indicates e-mail address of the subscriber.
- Enable SMS: A numeric
data type that indicates SMS is being used to send notifications
to this subscriber.
- Sub status: A numeric
data type that indicates current status of the subscriber. Value
1 indicates active status value 0 indicates in-active status. Depending
upon your business model, you can use additional values to indicate
current status of the subscriber.
- Service or Data Plan
Name: A character data type that identifies name of service
or data plan associated with the subscriber.
- Sub Opt Out: This
is a numeric data type.
- Billing Start Date:
A date data type that indicates the date on which billing is started
for this subscriber.
Following is a sample
of bulk load in CSV format for above mentioned configuration:
77777777777777,777777777777777,GOLD,0,Bye,0,10,VOD,1,21-Apr-2012,10,1,22-Apr-2012,URL=Rediff;URL=Facebook;URL=Google
Where
URL is attribute name and Rediff,Facebook,Google are attribute values.
Dynamic Twenty Four
Hours Allowance Support
This section
briefly describes dynamic twenty four hours plans.
PCC solution supports
dynamic twenty four hour allowance support for plans. Such plans:
- Are post-paid plans
hence applicable only to post-paid subscribers.
- Support lifetime validity,
until terminated by subscriber or operator.
- Support volume quota
of 10 Mb that is valid for twenty four hours from the activation. Plans
are considered active when first byte of data is consumed. After
activation subscriber can consume data until all the volume quota
is exhausted or time duration is elapsed.
- After exhaustion of
volume quota, the plan can be renewed again automatically. New billing
cycle will be activated when the first byte of data is consumed.
- After activation of
new billing cycle, if there is still some volume quota remaining
from earlier billing cycle, then such quota will not be carried
forward to new cycle.
- There is no limit on
the number of quota renewals, quota can be renewed perpetually until
subscriber opts out of this plan.
- Features such as grace
period or prorating are not applicable for this plan category.
Event Notification
Management
This section
briefly describes the event notification support.
SSC uses event notification
module to provide usage and policy notifications to the subscriber.
These notifications are mostly related with subscriber’s
service usage scenario or policy changes imposed by PCC rules that
might affect subscriber. SSC generates this information by exchanging
subscriber profile as well as usage information with other components
of PCC solution such as IPCF or PPT as well as with OSS and BSS
systems.
SSC event notification
module receives change triggers from service usage as well as policy management
modules of IPCF. Change triggers are the events on whose execution,
notifications are sent to subscribers regarding changes in their
service usage or profile status. Notifications can be sent as an
SMS or e-mail using subscriber’s Mobile Subscriber ISDN
Number (MSISDN) or registered e-mail id.
Change triggers can
be on-line or off-line events. Examples of on-line events are:
- Start of subscriber
session.
- Termination of subscriber
session.
- When a threshold is
breached.
Examples of off-line
events are:
- A plan is activated
or de-activated for a subscriber.
- A plan is associated
or de-associated with a subscriber.
- When a plan is recharged
by a subscriber.
You can use event
notifications to inform subscribers, regarding changes in their
service usage or profile status. SSC initiates these notifications
after confirming changes in subscriber profile. SSC allows customizing
as well as throttling of notification messages as per the category of
message and capacity of notification gateway.
IMPORTANT:
A notification template
can contain maximum 2000 characters.
SSC can generate event
notifications even if the subscriber session is not active i.e. subscriber
is not connected using a PDP context. Such notifications are needed
in following scenarios:
- A plan is activated
or de-activated for the subscriber.
- A plan is associated
or de-associated with the subscriber.
- Usage top-up is completed
for the subscriber.
Event Notification
Templates
This section
briefly describes the event notification templates.
You can use event
notification templates to inform subscribers regarding specific
network or service related events or thresholds that may affect
their service usage or billing.
Following scenarios
may warrant a notification to be sent to the subscriber:
- Subscriber belongs
to a specific class such platinum or gold, and as per his or her profile
in Subscriber Profile Repository (SPR) is entitled to receive specific notifications.
- Subscriber is using
specific service or class of service such as VoIP restricted tariffs.
- Detection of specific
event regarding usage pattern of this subscriber, such as usage
of specific application or application class such as Skype or VoIP.
- Subscriber is about
to cross the threshold of the Fair Usage Policy (FUP) for their subscribed
services.
SSC allows you to
choose event specific notification method. For certain events you
can send the notification thru e-mail to subscriber’s registered
mail address, for remaining categories of events you can send notification
thru SMS to subscriber’s registered number.
Depending upon your
access privilege, you can customize these templates.
IMPORTANT:
Notification templates
can be configured using PPT application, a component of PCC solution.
Grace Period or Pre-paid
Parking Support
This section briefly
describes grace period or pre-paid handing support.
PCC solution supports
grace period or additional duration for subscription, after expiry
of the plan. The duration of this period varies from plan to plan.
The grace period feature allows service provides:
- More control on subscriptions
in this period, by allowing to retain or apply different policies
related to throttling or charging.
- Provisioning additional
time to the subscriber for manually renewing the subscription before
its expiry.
The grace period is be
categorized as:
- Activation Grace Period:
This is the period when the subscription expires for the first time
before the renewal of the plan.
- Renewal Grace Period:
This is the period when the subscription expires after first plan
renewal.
IMPORTANT:
Grace period is applicable
to pre-paid data plans only.
Plan Categories and
Add-on Support
This section
describes the plan categories and available add-on.
A plan defines the
services that are being rendered to the subscriber. This feature
allows SSC to configure various categories of plan. Depending upon
their payment method i.e. either pre-paid or post-paid, different
categories of plans can be associated with a subscriber.Following are
various plan categories:
- Data Plan: This
is the basic category that has an independent existence. A subscriber
can be associated with single or multiple data plans.
- Service Plan: A
service plan is always associated with a data plan. A service plan
cannot have an independent existence from its parent data plan.
- Service Pack: This
is a service plan that needs to be explicitly subscribed by the
subscriber.
An add–on
is always associated with the data or service plan or pack. Add
on is used to render the customized services by enhancing the attributes
of existing plans. Following are the add-on categories:
- Service Add-on:
Used to enable tethering.
- Allowance Add-on:
Used to increment volume or time usage
- Validity Add-on:
Used to increment subscription validity.
Plan Prorating
This section
briefly describes prorating support for plans.
PCC solution can support
proportional assignment of volume or time usage as well as volume
and time usage for the post paid subscriber. This feature is known
as prorating. All the proportional calculations for the prorating
are done based on the calendar units. For example the same monthly
plan will be pro-rated differently for the month of February with
28 days and for the month of March with 31 days.
Prorating can be implemented
in following scenarios:
- Subscriber’s
first time subscription to data plan :When the post paid subscriber
subscribes for the first time to a data plan, first validity period
for the plan will be over by the end of existing billing cycle and
data volume and price will be prorated based on the time difference
between the subscription and the end of first billing cycle.
- Subscription expiry
is beyond the billing date for the plan: This scenario can occur
when the plan is valid beyond the billing date or due to plan restart,
new plan cycle is extending beyond the billing period. This scenario
can also occur if the subscriber changes the billing data using
the provisioning interface.
- Subscriber disassociates
a plan: This scenario occurs when the subscriber dis –associates
the plan before the end of subscription. In such scenario prorating
is forcefully implemented based on the subscription end date for
this plan.
IMPORTANT:
Prorating is applicable
to post-paid subscribers only. This feature cannot be implemented for
dynamic 24 hour plans.
Redundancy and Fault
Tolerance
This section
briefly describes inherent redundancy and fault tolerance of SSC
architecture.
SSC provides carrier
grade reliability by ensuring that there is no single point of failure
in the system. It also supports the geographical redundancy for
any catastrophic failures that may render the system unstable. SSC
also supports high availability of database, providing multiple
levels of high availability and data preservation capacity.
Multi-layered, distributed
SSC architecture ensures that process faults are contained, by providing
the capability to re-start the process with minimum or no service
impact. In a multi-host geo-redundant deployment, SSC can replicate
all subscriber and session processing tasks with its corresponding
peer SSC instances using active- active model.
In a clustered deployment,
more than one SSC instances can be active on multiple blade servers.
At least two blade servers can be configured as active –standby
database system using shared storage or disk arrays.
Roaming Determination
Support
This section
briefly describes home and roaming region support for differentiated
billing.
PCC solution can now
support differentiated billing for subscribers when they are accessing the
network either in their defined home region or while roaming out
of home region. A home region is defined using certain geographical
as well as network entities such as
- Mobile Country Code (MCC)
- Mobile Network Code (MNC)
- Serving GRS Support Node
(SGSN) using IP address and subnet mask.
- Serving Gateway (SGW)
using IP address and subnet mask.
- Location Area Code (LAC).
- Routing Area Code (RAC).
- Serving Area Code (SAC).
- Cell Identity (CI).
- E-UTRAN Cell Identity
(ECI).
- Tracking Area Code (TAC).
This
information is used to associate a home region with the subscriber,
if home region is not defined, then while provisioning subscriber
profile, a default region is associated with the subscriber.
This feature uses information
such as 3GPP ULI, SGSN IP or other Gx attribute value pair during
the session initiation to determine whether the subscriber is in
the home region. This feature also determines event triggers to
be registered with the PCEF to track subscriber’s location.
During session establishment or termination whenever the subscriber
location is changed, SSC can now store the last location.
Service Usage Management
This section
briefly describes service usage management.
SSC along with IPCF
provides policy control for subscribers based on their usage of
various services that are being offered.
SSC stores subscriber
account information such as profile and service usage data, along
with subscription tires and plans. SSC acts as a centralized location
for managing subscriber’s service usage. This information
is synchronized between SSC and IPCF using Sp interface and Sh protocol.
If service usage is shared between multiple Policy Charging Control
(PCC) sessions, then SSC performs session binding using, Mobile
Subscriber ISDN Number (MSISDN) or suitable subscription account
attribute such as group id.
SSC provides subscriber
profile information such as International Mobile Subscriber Identity
(IMSI), MSISDN as well as subscriber group. It also provides service
usage associated with the subscriber as well as subscriber status
flags such as whether the subscriber is a VIP or is blacklisted.
This information is used by IPCF for monitoring the service usage
of subscribers.
Subscriber Database
Geo-redundancy
This section
briefly describes the geo-redundancy feature available for the subscriber
data stored in SSC.
The geo-redundancy feature
allows SSC to be deployed in more than one, geographically distant
sites and ensures availability of subscriber data in case of catastrophic
failure at any of these sites. Same version of an SSC instance can
be deployed in an active–standby mode by using distant
geographic sites, and by sharing the database.
For the subscriber data
stored in SSC, this feature supports failover to a redundant data storage
site. Geo-redundancy utilizes a database technology supported by
the RDBMS that allows maintaining stand-by or secondary database
repository for the primary database. This feature also uses active-active
cache of the In Memory Database (IMDB) application that is being
used to provide the database grid.The IMDB application always fetches
data from the primary data base. The stand-by database is always
running in a limited mode and periodically being synchronized with
primary database.
IMPORTANT:
Currently database
redundancy is supported using the stand-by database either at local
site in cluster configuration or at a geographically distant site.
Both categories of stand-by database instances cannot co-exist in
a given deployment.
In a multi-host environment,
geo-redundancy feature supports the failure detection and recovery
of:
- SSC application processes
such as log daemon, scheduler and various controller as well as
manager processes such as Udr controller and Udr manager.
- Database and IMDB
private interface processes.
- Network related processes
such as Sh link monitoring.
For IBM Blade Center
platform with one chassis per site, GR feature supports following configurations:
- Two sites each with
one blade, one for active or primary database and other for secondary
or stand-by database.
- Two sites each with
two blades, primary site with primary database and an active-stand-by
IMDB pair. Secondary site with secondary database and an active-stand-by
IMDB pair.
- Two sites with two blades,
primary site with database Real Active Cluster (RAC) as primary
database and an active-stand-by IMDB pair. Secondary site with database
RAC as stand-by database and an active stand-by IMDB pair.
For UCS rack mounted
servers, GR feature supports a configuration with two sites, each with
one UCS C series server. A primary site for primary database and
a secondary site for secondary database.
SSC Application High
Availability in Multi Host Cluster Deployment
This feature
briefly describes High Availability (HA) implementation in an SSC
cluster.
High Availability (HA)
can be implemented for an SSC cluster deployment. It ensures availability
of subscriber data by managing failure detection and recovery of
all the components of SSC deployment such as:
- SSC Application Software:
Application failure detection and recovery is implemented using
heart beat daemon. SSC components send heart beats at a configured
interval. The daemon re-starts a component if it fails to receive
any heart beat from that component in defined consecutive intervals.
SSC application components such as Sh, event, ud and profile controller
as well as system controller, scheduler and log daemon can be made highly
available using this method
- In Memory Database (IMDB)
Application: IMDB failure detection and recovery is implemented
using the second blade in active –standby mode. The data
base blade hosts database and IMDB in active mode, where as the
application blade hosts IMDB in standby mode. Automatic failover
is performed in case of un-availability of active IMDB node. Active sessions
are maintained in IMDB and are replicated between active and stand
by nodes.
CAUTION:
In the current release,
IMDB failure recovery requires manual intervention in form of attaching
working blade to grid and cleaning up entries in database, this
may introduce a down time of up to 60 minutes.
- SSC Persistent Database
(RDBMS): In a two node active stand-by configuration, persistent
data in the database is protected by performing periodic back-ups.
- Hardware such as UCS
or IBM Blade center Blades: In a blade failure scenario, the
recovery is implemented using Red Hat Cluster. In case of un-availability
of application blade, the application is migrated to the data
base blade using floating IPs that is transparent to other PCC components
such as IPCF.
SSC Bulk Statistics
Support
This section
briefly describes the bulk statistics frame-work provided by SSC.
SSC provides a bulk
statistics framework which can be used to record various system
related statistics such as counters, gauges and fixed value strings
from various SSC schema of your deployment.
This framework can
be used for recording as well as monitoring of such bulk statistics.
The user can configure
and monitor bulk statistics for following SSC schema:
- ShApp Schema:
Bulk statistics schema for Sh application.
- EnApp Schema:
Bulk statistics schema for Event Notification application.
- ProfApp Schema:
Bulk statistics schema for Profile application.
Statistical counters
provide a snapshot of the system at any given instant. The bulk
statistics collected over a regular and configurable time interval
can be used for administering SSC deployment as well as for troubleshooting
purpose. User can compare values of such counters on a discrete
time line specified by the sampling period, to diagnose the system
health.
By default the Bulk
statistics is stored in a .txt file
and then can be transferred to Web Element Manager (WEM) to parse
and archive for further analysis where WEM provides graphical interface
for data representation.
SSC RAC Support
This section
briefly describes the RAC support in the enhanced architecture.
This support is required for High Availability (HA) and Geo Redundancy
(GR) features.
The limiting factor
for HA and GR features in the previous SSC architecture was the
single instance of Oracle database, which used to act as a single
point of failure. This has been mitigated by incorporating RAC support.
Enhanced SSC architecture supports Oracle Real Application Cluster
(RAC). The RAC allows Oracle database to run any packaged or custom
application un-changed across the server pool. It provides a facility
to add more servers and instances to the pool without taking users
off-line.
In previous SSC architecture,
the data base could become single point of failure as well as performance
bottle neck as it used to be deployed on a single blade in any of
the site. With the RAC feature, Oracle de-couples the database instance
i.e. the processes and memory structure that are running on the
server to access the data from the data files i.e. the physical
structure that is actually storing the data. A clustered database
can now be accessed by multiple database instances running on separate
servers.
IMPORTANT:
In a non-RAC deployment,
when the database server fails in the first site the fail-over occurs in
the second site. In a RAC deployment, after failure of one database
instance another data base instance from the same site takes over.
SPR - API Provisioning
Interface
This section briefly
describes usage of SPR- API provisioning interface.
SPR – API is
one of the provisioning interfaces used by SSC mostly for provisioning
profile information. Depending upon the business model and system
configuration, this interface can also be used for:
- Managing Network Definition:
By performing add, modify and delete operations on the logical entities
such as region or region lists in the network.
- Managing Plans :
By performing add, modify and delete operations on various data
plans, service plans, service packs and add-on.
- Managing Subscribers:
By performing add, modify and delete operations on groups of subscribers
and associating and disassociating a subscriber from group.
- Managing Subscriptions:
By associating or disassociating data or service plans and add-on
with subscriber groups.
- Managing Subscriber Notifications :
By performing add, modify and delete operations on templates for
e-mail as well as SMS notifications.
SPR – API interface
supports backward compatibility, thus allowing other components
of PCC solution such as OSS and BSS to continue to exchange data
with SSC application.
Depending upon the business
model and system configuration following SPR-APIs are now available:
- Parent Plan Attachment.
- Parent Plan Renewal.
- Parent Plan Removal.
- Service Activation using
Service Add on or Secondary Pack.
- Service Renewal using
Service Add on or Secondary Pack.
- Service Removal using
Service Add on or Secondary Pack.
- Allowance Add on.
- Subscriber Query.
- Bulk File Handling.
- Bulk File Format.
- Subscriber Deletion.
Time monitoring
over Gx
This section
briefly describes enhancements in SSC to support time monitoring
over Gx
Duration based usage
data plans can be implemented using this time monitoring over Gx feature.
SSC can store data plans containing available and used quota for
time in seconds as well as for volume in bytes. SSC can send this
quota along with other subscription and usage information as well
as configured thresholds to IPCF.
Enhanced architecture
of PCC solution can allow monitoring of subscriber’s service
usage based on time or volume as well as both on time and volume.
Time monitoring over Gx feature allows monitoring of session time
for a subscriber. Using this feature time based thresholds can be configured
for flow level or session level by the IPCF and then this information
can be communicated to PCEF over Gx.
When threshold is
reached for time based usage, it is reported by PCEF to IPCF. If subscriber
session is terminated before usage is reached, PCEF indicates termination
along with usage. The time threshold value provisioned to PCEF can
be configured locally on IPCF or can be extracted from associated
data plans available on SSC.
Usage Monitoring
Functions
This section
briefly describes the usage monitoring capabilities of SSC.
SSC acts as a centralized
repository for data pertaining to subscriber profile, policy and
service usage. As per your network configuration and business model,
you can configure SSC to exchange this data between IPCF and various
Operation Support Systems (OSS) as well as Billing Support Systems
(BSS). Thus extending the data monitoring capacity of IPCF.
OSS software applications
are used to administer operational processes related to network infrastructure
and services such as QoS monitoring, network and server performance.
OSS applications also provide logical or element and physical or
network management of the deployed resources. Provisioning function
can also be handled by OSS applications. BSS software applications
are used to administer external business operations such as billing,
rating, sales or customer management. BSS application can also be
used to administer customer databases.
How SSC Works
This section
briefly describes the working of SSC.
SSC manages subscriber’s
profile as well as service usage information using following data
objects:
- Subscriber Profile:
A subscriber profile identifies various subscription plans associated
with subscriber along with their privileges and entitlements that
can be availed by the profile owner.
- Subscription Plan:
A subscription plan identifies the treatment regarding the service
usage to be made available to the user of your network. A subscription
plan can be categorized as data plan, service plan, service pack
or add-on for the plan.
- Usage Account:
A usage account stores current status of the subscriber's service
usage, using service units such as volume and time.
Depending upon your
business model and network configuration, SSC keeps track of other subscriber
attributes such as, current service usage or last visited country.
SSC is modeled on Subscriber Profile Repository (SPR). In a PCC
deployment an SSC provisions:
- Static as well as dynamic
attributes of subscriber profile.
- Data or service plans
along with service packages and add-on.
- Notification information.
- Subscription tires.
SSC performs this
provisioning using a combination of following methods:
- SSC console.
- PPT application using
XML-RPC interface.
- External LDAP using
Ud interface.
- SPR provisioning APIs
using SOAP/XML.
- Bulk-loading of subscriber
profiles using shell script and CSV files.
- Auto provisioning templates.
Different PCC component
applications such as IPCF, PPT, WEM and OSS or BSS access application
layer of SSC using appropriate interfaces. These applications exchange
different categories of data such as subscriber profile or service
usage as well as system management data with SSC. This data is accessed
from the database that is deployed in a cluster environment using Storage
Area Network (SAN).
SSC provides a console
based administrative interface to manage the subscriber, subscription
and services related data for the Cisco PCC solution. This interface
can be used to:
- Start and stop specified
SSC components in the system.
- Manage interfaces
with other application components of a PCC solution, for sharing data.
- View the logs generated
by the system.
- View application counters.
- Monitor overall system
health using various processes.
- Set-up and fine tune
various parameters for the system components.
SSC Data Model
This section
briefly describes schematic considerations of the database containing
subscriber and subscription information.
SSC database schema
categorizes the subscriber, subscription and service related information.
Depending upon your business model and deployment architecture the
data model can have following components:
- Subscriber Group Profile:
A subscriber group profile contains group name, subscriber Id such
as IMSI or MISDIN, e-mail address, a flag to enable e-mail, and
a flag to enable SMS.
- Subscriber Profile:
A subscriber profile is a separate component it is not a part of
subscriber group profile. It contains subscriber profile Id such
as IMSI or MSISDN, subscriber name, subscription tire and other
executable profile attributes.Current version of
SSC supports a flexible subscriber profile schema that can be extended using
dynamic attributes. These attributes can later on be used to configure
appropriate policy condition rules and identify the subscriber individually
as either white listed or black listed.
- Data Plan: A data
plan contains subscriber profile Id, plan Id, volume usage, time
usage, start date, end date, and a flag to enable notifications.
- Service Plan: A
service plan contains subscriber profile Id, plan Id, volume balance,
time balance, recharge day, recharge duration, and usage monitoring
key.
- Service Pack: This
is a subscribe able service plan. A service pack is associated with
a data plan subscription.
- Threshold: A threshold
contains threshold id, template id, absolute and percentage value
of service usage.
- Notification Template:
A notification template contains notification template id, subscriber
id such as MSISDN and e-mail address.
- Area: This is the
smallest configurable entity. An area can be defined using network
entities such as MCC, MNC, LAC.
- Region: A region
contains one or more areas. A single region can accommodate maximum
sixteen areas.
- Region List: A region
list contains one or more regions.
These components
are related with each other as follows:
- A single subscriber
group profile can be associated with multiple data plans as well
as multiple subscriber profiles.
- A single subscriber
profile can be associated with multiple data plans.
- A single data plan
can be associated with multiple service plans.
- A single service plan
can be associated with multiple thresholds.
- A threshold is associated
with a single notification template.
SSC Startup
This section
briefly describes startup process for an SSC instance.
Following steps describe
the start-up of an SSC instance:
- Heart Beat daemon
(HBd) is spawned on management application blade, all instance ids
of applications or facilities will be on management blade.
- Heart Beat daemon
then initiates Logd and SysCtrl (instance id – 1) on management blade.
- SSC startup script
starts HBd on all sscblade<number>, with
instance id starting from 2 up to n-2.
- HBd then spawns Logd
and SysMgr on slave blades.
- When SysMgr is up
and running, it notifies SysCtrl with its own facility id, instance
id, and blade server name on private network (sscblade<number>).
- In response SysCtrl
sends the list of SSC components to SysMgr. SysCtrl keeps track of
which applications are on which blade.SysCtrl accepts the
information regarding which component is running on which blade(s), from
console user interface.This configuration
information is stored in SSC configuration database. SysCtrl refers
to this configuration and uses it to start application on blades.
- SysMgr then requests
HBd to start list of applications. HBd starts AppMgr along
with all the mentioned components, and informs status to SysMgr.
- SysMgr then informs
SysCtrl about failure or success of application start-up.
IMPORTANT:
In a cluster deployment,
SSC start-up script can be executed from any blade. In case of a node
failure, high availability of various SSC tasks such as SysCtrl,
ShCtrl, Logd and Scheduler is ensured by the cluster deployment.
