> 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 ASR 5000 platform and the Policy Provisioning Tool (PPT).
> This chapter contains following sections:

> • | PCC Solution Elements

> • | SSC Introduction

> • | SSC Architecture

> • | SSC Deployment and Interfaces

> • | SSC System Requirements

> • | Licenses

> • | Features and Functionality

> • | 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 Rating 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 is the subscriber profile repository for Cisco PCC solution. Based on standard platform it performs following key functions:

> • | Subscriber Profile Storage.

> • | Subscriber Service Usage Management.

> • | Centralized Network Policy Control.

> • | Event Manager Module Support.

> It 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 centralized PCRF functions 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 network components 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.

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

> • | Storage of policy related data for subscriber as well as operator.

> • | Centralized policy management for your network.

> • | Centralized storage of subscriber, subscription and operator specific preferences.

> • | Managing subscriber service usage.

> • | Bulk loading of subscription records using Comma Separated Value (CSV) files.

> • | Periodical updates of entire subscriber database as well as updates for specific subscriber profile.

> • | 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 for subscriber profile and service usage information.

> • | Exchanging profile and service usage data with Customer Relationship Management (CRM) systems, using Ud interface, even if CRM is storing data in different database format.

> Following figure describes a high level view of SSC deployment scenario along with other components of in a PCC solution.
> SSC Deployment Scenario
> The multi-layer distributed architecture of SSC provides carrier grade reliability, by providing high availability for single site. 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.
> SSC Architecture
> A multi-layer and distributed SSC architecture constitute following layers:

> • | Data storage layer containing storage arrays.

> • | Highly available database layer containing clusters of database servers in active –standby mode.

> • | High speed cache grid layer providing fault tolerance and higher transaction rates for the database.

> • | An application layer that is used to access data from the database by various components of PCC solution such as IPCF, PPT, OSS/BSS.

> 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 exchange data with SSC. Users with administrative privilege can use a console based User Interface (UI) as well as system management applications such as Web Element Manager (WEM) 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 process failure.

> • | Logging Daemon (Logd): This task controls the amount of logs generated.

> 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 IPCF and other PCC elements in a PCC network.
> SSC Deployment Scenario
> Interfaces
> SSC supports following network interfaces for communication with PCC elements:

> • | 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 the data related to usage and balance. Sp interface uses a standard Sh protocol.

> • | XML-RPC over HTTP: This interface is used by SSC to exchange information with PPT. This interface is used over HTTP protocol.

> • | 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 alarms 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/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 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 or OSS/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: This interface is used by CRM systems and web portals to connect to SSC and provision the subscriber profile related information using SOAP /XML. The interface also controls the catch management and request queue.

> 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 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 platform or IBM HS22 Blade Sever.

> Operating Environment:

> • | The Cisco MITG RHEL v5.5, a 64- bit operating system customized to run on selected hardware platform

> Licenses
> This section identifies licensing requirements for SSC.
> Important: SSC is a licensed product, for more information regarding licenses contact your local representative.
> Features and Functionality
> This section describers the features and functions supported by the base SSC deployment.
> 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
> 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 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 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.
> Depending upon your subscriber profile, the CSV file contains 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 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 used, where as value 0 or N indicates that the option is not 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
> SSC acts as a centralized repository for data pertaining to subscriber, 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.
> SSC provides centralized policy handling capacity. Such capacity enables session co-relation across various instances of IPCF as well as across network domains using coordinated interactions with other domain policy nodes.
> SSC also works as an intelligent database function for the policy services. In this capacity SSC can work as a standalone Subscriber Profile Repository (SPR) or as a high transaction SPR front end for dynamically tracking the policies. SSC also works as a policy events and statistics manager, by providing data for operational monitoring and analysis of the subscriber service usage. SSC also provides an event notification module, allowing the interaction with subscribers using e-mail and SMS.
> Redundancy and Fault Tolerance
> 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. SSC replicates all subscriber and session processing tasks with its corresponding peer system 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
> 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 the 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.
> Event Notification Management
> This section briefly describes the event notification support.
> The SSC uses event notification module to provide notifications to the subscriber. These notifications are mostly related with subscriber’s usage scenario or policy changes imposed by PCC rules. SSC generates this information by exchanging the subscriber profile as well as usage information with other components of PCC solution such as IPCF or PPT as well as OSS and BSS systems. The SSC event notification module receives change triggers from service usage as well as policy management modules of IPCF. The change triggers are 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.

> 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.
> SSC can generate event notifications when the subscriber session is not active i.e. subscriber is not connected using 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.

> 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.
> You may need to notify subscribers under following circumstances:

> • | 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 like 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 interface 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 offered.
> SSC stores subscriber account information such as profile and service usage data, along with information regarding service 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 it 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.
> The High Availability (HA) feature is implemented for a multi-host SSC cluster deployment. This feature ensures the 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 or OCS.
> If an SSC node supporting any of these interfaces fails, then the HA feature allows initialization of supported interfaces from any other node in the SSC cluster.
> HA can be used to protect interfaces for 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 two geographically distant sites and ensures availability of subscriber data in case of catastrophic failure at any of the sites. Same version of SSC 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 utilizes 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 processes.

> • | Database processes and IMDB private interface processes.

> • | Network related processes such as Sh link monitoring.

> How SSC Works
> This section briefly describes the working of SSC.
> SSC manages subscriber’s profile as well as service usage information such as subscription plan and usage account:

> • | 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 subscriber of your network.

> • | Usage Account: A usage account stores current status of the subscriber's service usage, using service units such as volume and time.

> SSC also keeps track of other attributes associated with the subscriber such as, current service usage or last visited country.
> SSC is modeled on Subscriber Profile Repository (SPR). Different PCC component applications such as IPCF, PPT, WEM and OSS/BSS access application layer of SSC using appropriate interfaces. These applications exchange different type of data such as subscriber profile or service usage as well as system management data with SSC. These applications access data from database, deployed in a cluster environment. This data is further stored using storage arrays and Storage Area Network (SAN).
> SSC provides this data to other components of PCC solution, using processes that:

> • | Take care of application logic. For example, there is only one AppMgr process per application, such as IPCF or PPT, that is interacting with SSC.

> • | Exchange subscriber’s profile and service usage information with external applications. Number of such processes depend upon number of SSC host machines in the entire deployment.

> SSC provides an administrative interface to manage the subscriber profile for 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 subscriber 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 also provides a configuration interface that can be used to configure service level policies and subscriber profiles for Cisco PCC solution. This interface can be used to:

> • | Create, update and delete individual subscriber profiles.

> • | Allow bulk loading of subscriber profiles.

> • | Create as well as update subscription plan data.

> Important: For detail description of supported user interface and related administration as well as configuration procedures, refer SSC Administration chapter.
> 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 in 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, 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.

> 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