Subscriber Service Controller (SSC) Overview

SSC is an integral part of Cisco’s Policy Control and Charging (PCC) solution. It is designed to be used in conjunction with Intelligent Policy Control Function (IPCF) on Cisco© chassis and the Policy Provisioning Tool (PPT) on Cisco© UCS or Solaris platform.

This chapter contains following sections:

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 Introduction

SSC is an application that complements and extends the functionality of PCRF in Cisco PCC solution.

SSC uses Policy Charging and Rules Function (PCRF) along with Subscriber Profile Repository (SPR) data store, to implement the usage control policies in a centralized manner. It also handles account details as well as session state information of the subscriber. SSC can manage the event notification function for PCC, by sending e-mails or text messages to subscribers. SSC provides storage facility for subscriber profile along with centralized management of subscriber policy and service usage for your deployment.

SSC works in conjunction with IPCF for PCC functionality and interfaces with PPT and other components of PCC solution to provide following functionality:

An intelligent database for service policies by acting either as a standalone SPR or a high-transaction SPR front end for dynamic policy tracking.
A centralized policy software application engine complementing IPCF for advanced converged and co-related session handling.
Customized integration with IPCF for managing subscriber usage plans.
An event notification module that enables user interactions using e-mail and text messages.
Policy events and statistics management, which can be used for operational monitoring and analysis of subscriber service usage.
Centralized storage of subscriber, subscription and operator specific preferences along with centralized policy management.
Managing subscriber service usage.
Bulk loading of subscriber profile data using Comma Separated Value (CSV) files.
Provisioning of policy as well as usage monitoring functions for multiple IPCF systems in your network.
Provisioning of application interfaces with Operations Support System (OSS) or Billing Support System (BSS) as well as with IPCF and PPT components of PCC solution, for subscriber profile and service usage information.
Exchanging profile and service usage data with Customer Relationship Management (CRM) systems, using Ud interface, if CRM is storing data in different database format.

Following figure describes high level overview of a deployment scenario involving SSC along with other components of PCC solution.

Figure 1. SSC Deployment Scenario

The multi-layer distributed architecture of SSC provides carrier grade reliability, by ensuring high availability of the subscriber and subscription data, for the deployment. SSC architecture ensures that there is no single point of failure that may render your deployment unstable for operations. This is achieved by supporting geographical redundancy for disaster recovery.

In a typical SSC deployment a Cisco UCS or IBM Blade Center chassis can contain multiple instances of database manager (RDBMS) along with multiple instances of SSC application and its corresponding In Memory Database (IMDB) application. The IMDB pushes data to RDBMS. Sensitive data such as provisioning information can be pushed immediately where as other information that is being cached can be pushed to database using time-based policies.

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.

SSC System Requirements

This section identifies the minimum system requirements for SSC.

Hardware Requirements:

You can use either Cisco Unified Computing System (UCS) General Purpose Rack Mounted server, or an IBM Blade Center for SSC deployment.

Cisco UCS Requirements:

2 Intel Xenon X5670 series processors.
96 Gb of DDR3 Memory.
Small Form Factor (SFF) SAS or SATA disk drivers,1 TB or more.

IMPORTANT:

Refer Cisco UCS documentation, for detailed system requirements.

IBM Blade Center Requirements:

IBM Blade Center HT Chassis, embedded Cisco 3110G GE, FC.
IBM Blade HS22, E5645 6C 2.40GHz, 96GB, 300GB.
IBM DS3500 Storage Array 1.8TB.

IMPORTANT:

ReferIBM Blade Center documentation for detailed Blade server system requirements regarding IBM Blade Center HT chassis and IBM HS22 blade.

Software Requirements:

SSC 14.0 Software for Database Manager and PCC functions on Cisco UCS or IBM Blade Center platform. Cisco MITG SSC RHEL v5.5 is a 64- bit operating system customized to run on selected hardware platform.

IMPORTANT:

The Cisco MITG SSC RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG software applications. Users must not install any other applications on servers running the Cisco MITG RHEL v5.5 OS. For detailed software compatibility information, refer Cisco MITG RHEL v5.5 OS Application Note.

Licenses

This section identifies licensing requirements for SSC.

SSC is a licensed Cisco product. Separate feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements.

Licenses may be required for following SSC software components:

SSC Software for Database Manager.
SSC Software for PCC functions.

Licenses may be required for following session categories:

SSC session license for SPR.
SSC session license for decision center.

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.

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.

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.

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.

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.

SSC Architecture

Following layers constitute a multi-layered and distributed SSC architecture:

Data storage layer containing storage arrays.
Highly Available (HA) database layer containing clusters of database servers in active –standby mode, on the top of data storage layer.
High speed cache grid layer providing fault tolerance and higher transaction rates for the database on the top of HA database layer.
An application layer that is used by various components of PCC solution such as IPCF, PPT as well as OSS or BSS to access data from the database.

Following figure describes layered architecture for multi host, highly available SSC deployment running on Cisco UCS or IBM Blade center platforms:

Figure 3. SSC Architecture

Main components of the SSC are:

Database: SSC stores the subscriber data using RDBMS servers in highly available i.e. active- standby mode. Database can be configured using local hard disk or an external storage array.
Applications: SSC provides various application interfaces such as Sp, SOAP-XML and Open Ud. Using these interfaces applications such as CRM,OSS, BSS or other components of PCC solution such as IPCF and PPT exchange data with SSC. Users with administrative privilege can use a console based User Interface (UI) to administer an SSC deployment.

SSC application layer is made up of various processes or tasks such as:

System Management Controller (SysCtrl) and System Manager (SysMgr) Tasks: These manage resource sharing for individual hosts as well as entire SSC deployment.
Heart Beat daemon (HBd): This task monitors all SSC processing tasks and re-starts a failed task in case of a process failure.
Logging Daemon (Logd): This task controls log generation for the SSC deployment.

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.

Supported Standards and References

This section lists supported standards and references for SSC.

The SSC complies with the following standards for PCC functionality:

3GPP References

3GPP References

3GPP TS 23.203 V8.6.0 (2009-06): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and charging control architecture (Release 8)
3GPP TS 29.212 V8.4.0 (2009-05): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 8)
3GPP TS 29.213 V8.4.0 (2009-05): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control signalling flows and QoS parameter mapping; (Release 8)
3GPP TS 29.214 V8.5.0 (2009-05): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Rx reference point (Release 8)
3GPP TS 29.328 V8.5.0 (2009-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents (Release 8)
3GPP TS 29.329 V7.3.0 (2006-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details (Release 7)
3GPP TS 23.335 V9.2.0 (2010-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; User Data Convergence (UDC); Technical realization and information flows; Stage 2 (Release 9)
3GPP TS 32.182 V9.0.0 (2010-03): 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; User Data Convergence (UDC); Common Baseline Information Model (CBIM) (Release 9)