> Subscriber Service Controller (SSC) Overview
> 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.
> 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

> • | SSC Introduction

> • | SSC Deployment and Interfaces

> • | SSC System Requirements

> • | Licenses

> • | Features and Functionality

> • | SSC Architecture

> • | How SSC Works

> • | Supported Standards and References

> 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)

> • | Subscriber Service Controller (SSC)

> • | Policy Provisioning Tool (PPT)

> 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 policy services 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.
> 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.
> 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.

> • | SPR-API: SPR-APIs are used by web portals to connect to SSC and provision the subscriber profile data using SOAP /XML interface. The APIs can also be used to control catch management and request queue. The web portals can be used by subscribers to view plan or usage related data. Subscribers can also view the volume, time or currency usage associated with their account. SSC provisioning frame-work provides appropriate web services. Using specific URLs subscribers can connect to the server that provides these web services and view as well as update the information.

> SSC System Requirements
> This section identifies the minimum system requirements for SSC.
> Hardware Requirement
> You can use either Cisco Unified Computing System (UCS) C210 M2 General Purpose Rack Mounted server, or an IBM Blade Center for SSC deployment.
> Cisco UCS C210 M2:

> • | 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 to Cisco UCS C210 M2 documentation, for detailed system requirements.
> IBM Blade Center:

> • | 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: Refer to IBM Blade Center documentation for detailed Blade server system requirements regarding IBM Blade Center HT chassis and IBM HS22 blade.
> Software Requirement
> SSC 12.1 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 to 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

> • | Usage Monitoring Functions

> • | Redundancy and Fault Tolerance

> • | SSC Bulk Statistics Support

> • | Event Notification Management

> • | Service Usage Management

> • | SSC Application High Availability in Multi Host Cluster Deployment

> • | Subscriber Database Geo-redundancy

> Bulk Load Provisioning
> This section briefly describes bulk load provisioning for subscriber profile.
> Subscriber profiles need to be available in SSC, so that IPCF can process policy rules based on these profiles. Hence, to enable the subscriber specific policy control, such profile information needs to be loaded in bulk into the SSC database, from the legacy database. SSC provides a mechanism to bulk load the data related to subscriber profile, provided that such data is stored in the specified Comma Separated Value (CSV) format, with following naming convention:
> ssc_<batchnumber>_bulk_load_subscriber<YYYYMMDDHH24MISS>.csv
> The source data file is stored as external table in the database, the BulkLoad_sub script executes SQL statements that load actual data into database tables. This script can be scheduled to execute during the low activity period.
> The bulkload_sub script creates a log file that stores the execution status as well as errors. If your bulkload data requires multiple CSV files, you can name such files as ssc_<batchnumber>_bulk_load_subscriber<YYYYMMDDHH24MISS>_<n>.csv, where <n> indicates the number of files.
> Important: This script is located in SSC/tools directory. Bulk load script has been enhanced to support latest schema changes. For more information, refer Bulk Loading Subscriber Data topic, from Before You Begin SSC Administration section in SSC Administration chapter of this guide.
> 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.

> • | Sub Type: A numeric data type that indicates subscription category. Value 1 indicates default, 2 indicates Group and 3 indicates Admin category of subscription.

> • | Tire Name: A character data type that indicates the subscription tire associated with this subscriber.

> • | Enable E-mail Flag: 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 flag: A numeric data type that indicates SMS is being used to send notifications to this subscriber.

> • | Subscription 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.

> • | Flag Name: A character data type that indicates the flag name associated with subscriber.

> • | Flag Value: A character data type that indicates whether the flag option has been used or not. Value 1 or Y indicates that the option is being used, where as value 0 or N indicates that the option is not being used.

> • | 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.

> 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.
> 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.
> 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.

> Important: Refer appendices A,B and C for detailed schema information.
> 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.
> 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.
> 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.
> SSC Application High Availability in Multi Host Cluster Deployment
> This feature briefly describes high availability of SSC interfaces for a cluster deployment.
> High Availability (HA) feature is implemented for a multi-host SSC cluster deployment. This feature ensures availability of application and management interfaces of SSC in case of a catastrophic event at any of the SSC nodes. These interfaces are used by SSC to exchange data with other components of PCC solution such as IPCF,PPT and OSS or BSS. If an SSC node supporting any of these interfaces fails, then the HA feature allows initialization of supported interfaces from one of the remaining nodes in the SSC cluster.
> Using Red Hat Cluster Service (RHCS) component of the operating system, HA architecture ensures availability of SSC application under following circumstances:

> • | Application failure

> • | Database failure

> • | In Memory Database (IMDB) failure

> 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.

> • | Link failure

> • | Blade failure.

> HA can be used to protect interfaces related to following SSC components:

> • | Services such as system controller, log daemon or scheduler that are being used to manage the SSC deployment.

> • | Sh controller.

> • | Event controller.

> • | Profile controller.

> • | Ud controller.

> 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 primary 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.

> 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:
> 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 an 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.

> • | 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.

> • | 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.

> 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.

> Current SSC version supports a flexible user profile schema which can be extended by using dynamic attributes. These dynamic attributes can be used to:

> • | Identify the individual subscriber as white listed or black listed subscriber.

> • | Configure appropriate policy condition rules.

> SSC Startup
> This section briefly describes startup process for an SSC instance.
> Following steps describe the start-up of an SSC instance:

> 1. | Heart Beat daemon (HBd) is spawned on management application blade, all instance ids of applications or facilities will be on management blade.

> 2. | Heart Beat daemon then initiates Logd and SysCtrl (instance id – 1) on management blade.

> 3. | SSC startup script starts HBd on all sscblade<number>, with instance id starting from 2 up to n-2.

> 4. | HBd then spawns Logd and SysMgr on slave blades.

> 5. | 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>).

> 6. | 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.

> 7. | SysMgr then requests HBd to start list of applications. HBd starts AppMgr along with all the mentioned components, and informs status to SysMgr.

> 8. | 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)

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883