> Intelligent Policy Control Function Overview
> The Cisco ASR 5000 Platform provides 3GPP PCC solution to network carrier operators with Intelligent Policy Control Function (IPCF) in UTRAN/E-UTRAN/cdma2000-1x/HRPD networks.
> It offers an end-to-end Policy and Charging Control (PCC) solution that provides one of the highly intelligent and high performance solution. Based on the 3rd Generation Partnership Project’s (3GPP’s) PCC standard (Rel-7 and Rel-8 compliant), the Cisco PCC solution allows operators to achieve real-time control of their network resources, control subscriber access to services, and proactively optimize network capacity, while offering compelling new services and applications. It intelligently extends it such as to simplify the complex and diverse requirements of policy and charging management for global operators.
> Along with this solution operators can rapidly deploy a wide variety of standard services or new services to improve the quality of experience for their subscribers and generate additional revenue.
> These benefits are achieved by the implementation and deployment of relevant PCRF functions in a core network with network function capabilities thereby reducing system hardware costs, and providing lower latency and a performance optimized PCC solution.
> This overview provides general information about the Cisco PCC solution including:

> • | Product Description

> • | Product Specification

> • | Network Deployment and Interfaces

> • | Features and Functionality - Base Software

> • | Features and Functionality - Licensed Enhanced Feature Software

> • | How IPCF Works

> • | Supported Standards

> Product Description
> This section provides an overview and describes the building blocks for the PCC solution.
> The PCC solution is comprises of Intelligent Policy Control Function (IPCF), which comprises of extended intelligent PCRF capabilities for policy control function and Subscriber Service Controller (SSC) having centralized PCRF function and subscriber profile repository (SPR) functionality. It also includes a Web-based GUI tool, Policy Provisioning Tool (PPT) to implement and control the policy based subscriber access in the existing wireless network as well as service flow based charging implementation.
> The figure given below describes a high level view of UTRAN/E-UTRAN/cdma2000-1x/HRPD network with IPCF and other components in a deployment scenario.
> PCC Elements in UTRAN/E-UTRAN/cdma2000-1x/HRPD Networks
> The IPCF is built around an intelligent rule configuration and execution system. The IPCF’s policy rules engine is capable of acting on conditions such as the subscriber, the session state or network condition or even time and day, to decide upon the corresponding treatment to be given to the subscriber. All information and rules fetched by querying IPCF’s subscription plan stored in the SSC over Sp interface.
> Cisco PCC solution is well compliant to 3GPP standard in operator’s core network. Services available through Cisco PCC can be grouped in following categories:

> • | Resource management:

> • | fair usage

> • | traffic optimization

> • | time-based differential charging policies

> • | Personalization services:

> • | automated use notification

> • | tiered services

> • | parental control

> • | roaming management policies

> • | New services creation:

> • | turbo service for a dynamic upgrade

> • | location based differential charging

> • | on net preferential charging policies

> Cisco PCC solution empowers operator to deploy a 3GPP Standards based solution ensuring maximum flexibility and derive and authorize the QoS information for the service data flow for session as well as bearer usage
> Important: Some of the features may not be available in this release. Kindly contact your local Cisco representative for more information on supported features.
> PCC Solution Elements
> This section provides the brief description and functionality of various network elements involved in the UTRAN/E-UTRAN/cdma2000-1x/HRPD network. The Policy and Charging Control includes the following functional entities:

> • | Intelligent Policy Control Function (IPCF)

> • | Subscriber Service Controller (SSC)

> • | Policy Provisioning Tool (PPT)

> Intelligent Policy Control Function (IPCF)
> Intelligent Policy Control Function (IPCF) provides policy control and charging rule functions in a core network.
> Apart from standard capabilities Cisco IPCF, provides a unique possibility to deploy key functions in an integrated fashion collocated with the Policy and Charging Enforcement Function (PCEF) on a network function; i.e. GGSN, PDSN, P-GW. Such an integrated PCRF/PCEF capability allows for a further flattened and cost optimized network solution, leveraging Cisco ASR 5000 platform performance and versatility.
> IPCF along with SSC provide complete control of the policy and usage management for subscribers' data usage for any network. With SSC managing subscriber as well as policy related data, the IPCF performs the rules analysis and drives policy actions into the network. In case of PCEF-co-location model this basically translates to extending PCEF capabilities to support dynamic policy and charging functions with reduced latency in Gx/Gxa/Rx interface transactions.
> IPCF acts as a PCRF functions supplemented with usage monitoring capability that enables policies around data consumption. IPCF interfaces with the PCEF over standard Gx/Gxa/Rx interface for policy management and optionally Volume Reporting over standard Gx (VRoGx) interface for getting the usage of IP Connectivity Access Network (IP-CAN) sessions.
> Cisco IPCF is compliant in accordance with 3GPP standard in operator’s core network. Some of the key functions of IPCF are to:

> • | Derive and authorize the QoS information for the service data flow for session as well as bearer usage

> • | Select the appropriate charging criteria and mechanism apt for the data usage

> • | Provides network control regarding the service data flow detection and gating

> • | Ensure the PCEF user plane traffic treatment is in accordance with the user's subscription profile

> • | Correlate service and charging information across PCEF and AF

> PCC Rule and Charging Rule Report Handling
> IPCF handles operation of PCC Rule and activate/deactivate/install/modify/remove the PCC rules at PCEF. PCC rule operation may fail on PCEF due to various reasons. In such failure cases PCEF sends back a Charging Rule Report containing PCC rules failed and corresponding failure cause.
> The IPCF handles these charging rule report and take appropriate actions based on configuration.
> Charging Rule Report comes through CCA or RAA messages in a call flow used for handling the charging-rule-report.
> IPCF supports following charging rule failure codes in report:

> • | Out-of-credit

> • | Reallocation-of-credit

> • | Unknown rule name

> • | Invalid Rating Group

> • | Invalid Service Identifier

> • | GW/PCEF Malfunction

> • | Limited Resources

> • | Max No. of Bearers Reached

> • | Unknown Bearer Id

> • | Missing Bearer Id

> • | Missing Flow Description

> • | Resource Allocation Failure

> • | QoS Validation Failure

> Charging rule status can any one of the following in this scenario:

> • | Active

> • | Inactive

> • | Temporarily Inactive

> A charging rule report can occur in CCR message multiple times and maximum of 16 charging rule reports per CCR message is supported by IPCF.
> Subscriber Service Controller (SSC)
> SSC is the enhanced subscriber profile repository in Cisco PCC solution.
> Based on standard platforms it provides following major functions:

> • | Subscriber profile storage

> • | Subscriber usage counters management

> • | Centralized network policy control

> • | Supports event manager module

> SSC provides a number of additional PCC functions in the solution, including:

> • | an intelligent database function for the policy services (SPR), acting either as a standalone SPR or as a high-transaction SPR front-end for dynamic policy tracking

> • | a centralized Policy software application engine complementing the IPCF for advanced converged and correlated session handling where required

> • | an event notification module enabling user interaction via SMS and E.-mail, and a policy events and statistics manager, which is key for operational monitoring and analysis of the end-user service usage.

> The centralised policy handling capability set of the SSC is designed to enable session correlation not just across IPCFs, where needed, but also across network domains through coordinated interaction with other network domain policy nodes.
> The SSC interacts with IPCF over Sp (a standard Sh protocol based) interface for given functionality. SSC also supports a proprietary EN interface, which is based on XML-RPC protocol, to receive event notification data from IPCF.
> For more information on SSC function and supported interfaces, refer Subscriber Service Controller Installation and Administration Guide.
> Policy Provisioning Tool (PPT)
> Cisco Policy Provisioning Tool (PPT) is a Web-based client-server GUI application in PCC solution that helps the operator for subscriber policy provisioning and management.
> It provides the user (network operator) a comprehensive use-case design experience. It enables the network operator to design a service plan and subscriber profile data modelling at a time with the help of use case design and configuration.
> For more information on PPT function and supported interfaces, refer Policy Provisioning Tool Installation and Administration Guide.
> Product Specification
> This section describes the hardware and software requirement for IPCF.
> The following information is located in this section:

> • | Licenses

> • | Hardware Requirements

> • | Operating System Requirements

> Licenses
> The IPCF is a licensed product. A session use license key must be acquired and installed to use the IPCF functions on a chassis.
> The following licenses are available for this product:

> • | Cisco PID [ ASR5K-00-PC10SL ] IPCF Session License, 10k Active Sessions, or Starent Part Number [ 600-20-0107 ] IPCF Session License, 10k Active Sessions.

> • | Cisco PID [ LIF5K-00-PC10SL ] IPCF Session License, 10K Active Sessions (Failover), or Starent Part Number [ 600-21-0107 ] Integrated Policy Control Function R3, 10K Sessions (Failover).

> Hardware Requirements
> Information in this section describes the hardware required to enable the IPCF function on a chassis.
> Platforms
> The IPCF function operates on the following platforms:

> • | ASR 5000

> System Hardware Components
> The following application and line cards are required to support IPCF function on the system:

> • | System Management Cards (SMC): Provides full system control and management of all cards within the ASR 5000 platform. Up to two SMC can be installed; one active, one redundant.

> • | Packet Services Cards (PSC/PSC2): Within the ASR 5000 platform, PSCs/PSC2s provide high-speed, multi-threaded bearer context processing capabilities for IP services. Up to 14 PSCs/PSC2s can be installed, allowing for multiple active and/or redundant cards.

> • | Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SPCs/SMCs, SPIOs provide connectivity for local and remote management, central office (CO) alarms. Up to two SPIOs can be installed; one active, one redundant.

> • | Line Cards: The following rear-loaded line cards are currently supported by the system:

> • | Ethernet 10/100 and/or Ethernet 1000 Line Cards: Installed directly behind PSCs, these cards provide the physical interfaces to elements in the UTRAN/E-UTRAN/cdma2000-1x/HRPD network. Up to 26 line cards should be installed for a fully loaded system with 13 active PSCs/PSC2, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSCs/PSC2s do not require line cards.

> • | Quad Gig-E Line Cards (QGLCs): The 4-port Gigabit Ethernet line card is used in the ASR 5000 system only and is commonly referred to as the Quad-GigE Line Card or the QGLC. The QGLC is installed directly behind its associated PSC/PSC2 to provide network connectivity to the packet data network.

> • | 10 Gig-E Line Cards (XGLCs): The 10 Gigabit Ethernet Line Card is used in the ASR 5000 system only and is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ASR 5000 and the packet core network, and reduces the number of physical ports needed on the ASR 5000.

> The one-port XGLC supports the IEEE 802.3-2005 revision which defines full duplex operation of 10 Gigabit Ethernet.
> The XGLC is configured and monitored via the System Management Card (SMC) over the system’s control bus. Both SMCs must be active to maintain maximum forwarding rates.

> • | Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SPCs/SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100/Ethernet 1000/Quad-Gig-E/10-Gig-E line cards and every PSC/PSC2 in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and PSCs/PSC2.

> Important: Additional information pertaining to each of the application and line cards required to support IPCF function is located in the Hardware Platform Overview chapter of the Product Overview Guide and for other PCC elements refer respective Installation and Administration Guides.
> Operating System Requirements
> The IPCF function requires StarOS™ Release 12.1 or later running on ASR 5000 platform.
> Network Deployment and Interfaces
> This section describes the supported interfaces and deployment scenario of IPCF and other components in a core network.
> The following information is provided in this section:

> • | IPCF in UTRAN/E-UTRAN/cdma2000-1x/HRPD Network

> • | Supported Interfaces

> IPCF in UTRAN/E-UTRAN/cdma2000-1x/HRPD Network
> This section describes the deployment scenario of IPCF with Cisco PCC solution
> PCC elements can be deployed in various combination but following are the most common scenario for PCC deployment in UTRAN/E-UTRAN/cdma2000-1x/HRPD network:

> • | Standalone Deployment of IPCF in UTRAN/E-UTRAN/cdma2000-1x/HRPD Networks

> • | Co-located Deployment of IPCF with PCEF in UTRAN/E-UTRAN/cdma2000-1x/HRPD Networks

> Standalone Deployment of IPCF in UTRAN/E-UTRAN/cdma2000-1x/HRPD Networks
> In standalone deployment multiple PCEF (GGSN/PDSN/P-GW) connects to a single IPCF through Gx interface and served by the PCC elements through IPCF.
> The following figure displays simplified network overview of the IPCF deployment in an UTRAN/E-UTRAN Core Network to serve multiple PCEFs.
> Co-located PCEF and IPCF in UTRAN/E-UTRAN Networks
> Co-located Deployment of IPCF with PCEF in UTRAN/E-UTRAN/cdma2000-1x/HRPD Networks
> In co-located deployment IPCF sits with PCEF on the same chassis. It interacts with PCEF through internal connection matching Gx reference and connects to other PCC elements over various interfaces.
> The following figure displays simplified network overview of the co-located PCEF and IPCF deployment in an UTRAN/E-UTRAN Network.
> IPCF in UTRAN/E-UTRAN Network with Multiple PCEFs
> Supported Interfaces
> The IPCF provides the following network interface support to connect to the various network elements in an UTRAN/E-UTRAN/cdma2000-1x/HRPD networks:

> • | Gx: This reference is an interface between IPCF and PCEF. It is a Diameter protocol-based interface over which the IPCF communicates with a PCEF for the provisioning of charging rules. The charging rules are based on the dynamic analysis of flows used for a 3GPP or Non-3GPP IP-CAN subscriber session.

> This is the interface used by the IPCF to communicate with PCEF on the same Public Land Mobile Network (PLMN).
> The Gx reference point enables an IPCF to have dynamic control over the policy and charging control behavior at a PCEF. The Gx reference supports the following functions:

> • | Request for policy and charging control decision from PCEF to IPCF

> • | Provision of policy and charging control decision from IPCF to PCEF

> • | Delivery of IP-CAN-specific parameters from IPCF to PCEF or from PCEF to IPCF

> • | Negotiation of IP-CAN bearer establishment mode (UE-only or UE/NW)

> • | Termination of Gx session (corresponding to an IP-CAN session) by PCEF or IPCF

> Important: The IPCF decision to termination an Gx session is based on situation like removal of a UE subscription etc.
> One or more Gx interfaces can be configured per system context.
> Cisco IPCF supports standard 3GPP Rel. 7, Rel. 8, and Rel. 9 Gx interface to support different access technologies.
> To provide accessibility to PDSN as PCEF in CDMA/HRPD access network for 3GPP IP-CAN type session, Gx interface uses NAI and IMSI as subscriber Id and ESN and MEID for user equipment information.

> • | Gxa: This reference is an interface between IPCF and the Bearer Binding and Event Reporting Function (BBERF) at AN-GW. It is a Diameter protocol-based interface and enables an IPCF to have dynamic control over the BBERF behavior at AN-GW.

> The Gxa reference point enables the signalling of QoS control decisions and it supports the following functions:

> • | Establishment of Gxa session by BBERF and termination of Gxa session by BBERF or IPCF

> • | Establishment of Gateway Control Session by the BBERF and termination of Gateway Control Session by the BBERF or IPCF

> • | Request for QoS decision from BBERF to IPCF and provision of QoS decision from IPCF to BBERF

> • | Delivery of IP-CAN-specific parameters from IPCF to BBERF or from BBERF to IPCF

> • | Negotiation of IP-CAN bearer establishment mode (UE-only and UE or network)

> One or more Gxa interfaces can be configured per system context.

> • | Sp: This is a Diameter-based interface resides between Cisco IPCF and SSC. It is based on standard Sh interface.

> This reference point allows the IPCF to request subscription information related to the IP-CAN transport level policies from the SSC based on a subscriber identifier and used by IPCF to retrieve subscriber service policy and subscription profile.
> Only 1 Sp interface can be configured per system context.

> • | Event Notification Interface (EN): The EN interface supports uni-directional transfer of events from IPCF to SSC. This is an XML-RPC protocol based proprietary interface to send outbound event notifications to the SSC and forward these events to an event application module to generate mail/SMS notification to user/subscriber.

> Only 1 EN interfaces can be configured per system context.

> • | Rx: This interface is the reference point between the Application Function (AF); i.e. IMS and the IPCF. This is a Diameter based interface.

> The Rx reference point enables transport of application level session information from AF to IPCF. Such information includes:

> • | IP filter information to identify the service data flow for policy control and/or differentiated charging

> • | Media/application bandwidth requirements for QoS control

> The Rx reference point enables the AF subscription to notifications on signalling path status of AF session in the IP-CAN.
> One or more Rx interfaces can be configured per system context.

> • | CORBA-based Interface: IPCF supports the North-bound CORBA interface support for PPT and WEM management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems. It gives the ability to operator to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.

> Only 1 interface for WEM and 1 for PPT can be configured per system context.
> Features and Functionality - Base Software
> This section describes the features and functions supported by default in base software on IPCF service.
> IPCF along with SSC provide complete control of the policy and usage management for subscribers’ data usage for any network. With SSC managing subscriber as well policy related data, IPCF performs the rules analysis and drives policy actions into the network.
> Following implemented features and supports are provided on Cisco IPCF for PCC function support:

> • | Policy and Charging Control Functions

> • | Policy Definition Mapping Support

> • | Usage Monitoring and Control Support

> • | Event Notification over SMPP Interface Support

> • | WMS support

> • | Policy Provisioning Tool Integration

> Policy and Charging Control Function
> IPCF provides following supports for PCC function:

> • | Predefined PCC Rule Support

> • | Dynamic PCC Rule Support

> • | Policy Re-authorization Support on Profile Modification

> • | Policy Evaluation Support for Session Conditions

> This includes following session conditions for policy evaluation:

> • | Session Events: session setup, bearer setup/update, Policy modification etc.

> • | Network-based Events: Type of RAN, type of Access-Network etc.

> • | Time and Date: Time of day, specific date, specific week day

> • | Mobility: Home or roaming subscriber

> • | Usage based policies

> • | Single User Policy Management Support: It provides policy management across all sessions used by a single user.

> Policy Definition Mapping Support
> Policy definition mapping support is provided on IPCF to manage the PCC policy definition mapping based on subscriber/user identity. It supports policy mapping based on following identities:

> • | IMSI

> • | MSISDN

> • | APN name

> • | NAI

> • | SIP-URI

> Usage Monitoring and Control Support
> IPCF provides subscriber usage monitoring and control mechanism to operator based on different criteria and conditions. IPCF provides usage monitoring and control functions to support:

> • | multiple bearers and multiple sessions for a subscriber

> • | group of subscribers

> • | per service per plan usage thresholds

> • | configurable warning threshold

> • | usage counter reset on start of billing cycle

> Event Notification Interface Support
> The Event Notification module residing at SSC handles the various interfaces that integrate with subscriber for providing notifications related to policy changes imposed by the PCC rules, for application integration, and real-time interactions.
> IPCF’s usage management and profile management module provide triggers along with related information to the SSC.
> The event notification module supports an interface to deliver SMS notifications to subscriber using the subscriber ids from subscriber profile.
> Policy Provisioning Tool Integration
> Cisco Policy Provisioning Tool (PPT) is a Web-based client-server application which provides the user (network operator) a comprehensive use case design experience. It enables the network operator to design a service plan and subscriber profile data modelling at a time with the help of use case design and configuration.
> The Cisco PPT provides the following major functionality to the network operator:

> • | to design highly flexible, easily expandable and manageable use cases.

> • | to build the provisioning components through libraries containing data related to APN, rules and traffic types.

> • | to configure the data plans that reside on SSC. In the data plans, the user can configure the usage limits and thresholds

> • | to configure the E.-mail and SMS templates that are sent to the subscribers when certain threshold is reached.

> The PPT application has a very comprehensive and user-friendly interface to make the above listed configurations and services.
> System Management Features
> This section describes following features:

> • | Management System Overview

> • | Bulk Statistics Support

> • | Threshold Crossing Alerts (TCA) Support

> • | ANSI T1.276 Compliance

> Management System Overview
> The system's management capabilities are designed around the Telecommunications Management Network (TMN) model for management - focusing on providing superior quality network element (NE) and element management system (Web Element Manager) functions. The system provides element management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems - giving wireless operators the ability to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.
> Operation and Maintenance module of ASR 5000 offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces. These include:

> • | Using the command line interface (CLI)

> • | Remote login using Telnet, and Secure Shell (SSH) access to CLI through SPIO card's Ethernet management interfaces

> • | Local login through the Console port on SPIO card using an RS-232 serial connection

> • | Using the Web Element Manager application

> • | Supports communications through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000

> • | Base-SX (optical gigabit Ethernet) Ethernet management interfaces on the SPIO

> • | Client-Server model supports any browser (i.e. Microsoft Internet Explorer v5.0 and above or Netscape v4.7 or above, and others)

> • | Supports Common Object Request Broker Architecture (CORBA) protocol and Simple Network Management Protocol version 1 (SNMPv1) for fault management

> • | Provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities

> • | Can be easily integrated with higher-level network, service, and business layer applications using the Object Management Group's (OMG’s) Interface Definition Language (IDL)

> The following figure demonstrates these various element management options and how they can be utilized within the wireless carrier network.
> Element Management System
> Important: System management functionality is enabled for console-based access by default. For GUI-based management support, refer Web Element Management System.
> Important: For more information on command line interface based management, refer Command Line Interface Reference.
> Bulk Statistics Support
> The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.
> When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.
> The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. Following is a partial list of supported schemas:

> • | System: Provides system-level statistics

> • | Card: Provides card-level statistics

> • | Port: Provides port-level statistics

> • | PCC-AF: Provides PCC Application Function related statistics

> • | PCC-Policy: Provides PCC Policy related statistics

> • | PCC-Service: Provides statistics collected for PCC service on a chassis endpoint in PCC service

> • | PCC-Sp-Endpoint: Provides statistics collected at Sp interface endpoint in PCC service

> The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the chassis or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.
> The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, chassis host name, chassis uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.
> When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.
> The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.
> Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.
> Threshold Crossing Alerts (TCA) Support
> Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e. high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.
> The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.
> The following thresholding models are supported by the system:

> • | Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

> • | Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.

> Thresholding reports conditions using one of the following mechanisms:

> • | SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.

> Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

> • | Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.

> Logs are supported in both the Alert and the Alarm models.

> • | Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.

> The Alarm System is used only in conjunction with the Alarm model.
> Important: For more information on threshold crossing alert configuration, refer Thresholding Configuration Guide.
> ANSI T1.276 Compliance
> ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures.
> ANSI T1.276 specifies several measures for password security. These measures include:

> • | Password strength guidelines

> • | Password storage guidelines for network elements

> • | Password maintenance, e.g. periodic forced password changes

> These measures are applicable to the ASR 5000 Platforms and the Web Element Manager since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.
> Features and Functionality - Licensed Enhanced Feature Software
> This section describes the optional enhanced features and functions available for IPCF node.
> Important: Some of the following features may require the purchase of an additional license to implement the functionality with the IPCF node.
> This section describes following features:

> • | Session Recovery Support

> • | Web Element Management System

> Session Recovery Support
> The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.
> Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new instances of “standby mode” session and AAA managers for each active Control Processor (CP) being used.
> Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet processing card to ensure that a double software fault (e.g. session manager and VPN manager fails at same time on same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is reserved by the operating system for this sole use when session recovery is enabled.
> The additional hardware resources required for session recovery include a standby System Processor Card (SPC) and a standby packet processing card.
> There are two modes for Session Recovery.

> • | Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.

> • | Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a packet processing card migration failure happens. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.

> Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager task is paired together. These pairs are started on physically different packet processing cards to ensure task recovery.
> Important: For more information on this feature, refer Session Recovery chapter in System Administration Guide.
> Web Element Management System
> Provides a Graphical User Interface (GUI) for performing Fault, Configuration, Accounting, Performance, and Security (FCAPS) management of the ASR 5000.
> The Web Element Manager is a Common Object Request Broker Architecture (CORBA)-based application that provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) management capability for the system.
> For maximum flexibility and scalability, the Web Element Manager application implements a client-server architecture. This architecture allows remote clients with Java-enabled web browsers to manage one or more systems via the server component which implements the CORBA interfaces. The server component is fully compatible with the fault-tolerant Sun® Solaris® operating system.
> The following figure demonstrates various interfaces between the Cisco Web Element Manager and other network components.
> Web Element Manager Network Interfaces
> Important: For more information on WEM support, refer WEM Installation and Administration Guide.
> How IPCF Works
> This section provides information on the function and procedures of the IPCF in an PCC deployment scenario in an UTRAN/E-UTRAN/cdma2000-1x/HRPD network and presents message flows for different stages of session setup.
> Every time a new IP-CAN session is established through PCEF’s Gx interaction with IPCF, it queries SSC specifically to get subscriber’s profile as well as the usage details during the current billing cycle. After receiving the subscriber profile, it forward the same to PCEF. For remaining duration of the session the subscriber policy profile remains cached with IPCF and no query performed over Sp.
> Moreover, on any changes to the profile or to the subscription plan, SSC notifies IPCF over Sp interface, that is managing the session for the subscriber getting affected. IPCF ensures that the local repository has the most updated profile record for the subscriber at all times.
> Once the subscriber policy profile details are available, IPCF’s rule engine triggered by various interface events as well as internal events, determines the treatment to be given to the session in terms of the applicable QoS traffic management treatment and/or charging policy parameters.
> In the case IPCF is also tracking the usage for deriving policy decision on the basis of same, it would appoint itself for pre-paid usage monitoring through Gx for usage control.
> In the case where IPCF also performs usage monitoring via VRoGx interface, in addition to the session state triggers, additionally the usage can be monitored and operator can define various policy triggers around the usage thresholds for a session or even group of sessions. In the cases where usage is to be monitored across multiple sessions and PCEFs (from same or group of subscribers); e.g. for group policies, IPCF combined with SSC’s usage monitor module, enable the PCC system to track and trigger appropriate treatments required for the multiple sessions. IPCF communicates with SSC over Sp interface which enables a synchronous fetch and update related to usage as well as asynchronous notifications from SSC to the IPCF, handling the sessions which may get impacted due to consumption reported by a session being tracked at a different IPCF.
> The usage monitor at IPCF is capable of tracking aggregate volume and/or time consumption as well as on the basis of the service groups e.g. premium services, non-premium services in the network. This ensures that it is possible to apply different policy logic as well as different warning as well as usage thresholds on individual service or service-group basis, facilitating finer control over data consumption based policies. Further, the consumption during roaming scenarios can be counted differently from the home scenarios, if so desired by operator. The usage counter at IPCF in combination of SSC’s usage manager performs intelligent allocation of usage based on the policy conditions that helps to avoid over usage in case usage policy breach conditions.
> The following procedures are discussed in this section:

> • | IP-CAN Session Setup Procedure

> • | AF Session Setup Procedure

> IP-CAN Session Setup Procedure
> This section describes the call flow for IP-CAN session procedure.
> The following figure and the text that follows describe the message flow for IP-CAN session setup procedure.
> IP-CAN Session Setup Procedure Call Flow

> 1. | The PCEF receives an Establish IP-CAN Session Request.

> The form of the Establish IP-CAN Session Request depends upon the type of the IP-CAN. It can be the first Create PDP Context Request within an IP-CAN session for GPRS or an IPSec tunnel establishment request in an un-secured network.

> 2. | PCEF informs the IPCF of the IP-CAN Session establishment request through Diameter Credit Control Request.

> At this stage the PCEF initiates a new Gx session by sending a Diameter CCR to the IPCF and set the CC-Request-Type AVP to INITIAL_REQUEST.
> In Diameter CC request the PCEF provides following information to IPCF, if available:

> • | UE identity information

> • | PDN identifier

> • | UE IPv4 address and/or UE IPv6 address prefix

> • | PDN connection identifier

> • | IP-CAN type

> • | RAT type

> • | default charging method

> • | Default-EPS-Bearer-QoS

> • | APN-AMBR

> • | types of IP-CAN, where the IPCF can be in control of IP-CAN Bearers; e.g. GPRS.

> • | Bearer identifier and information about the requested bearer, such as QoS

> In this procedure the IPCF associates the Gx session for the new IP-CAN session with the corresponding Gateway Control Session and maintains the aligned set of PCC and QoS rules in the PCEF as applicable for the case.

> 3. | The IPCF stores the information received in the Diameter CC Request message.

> 4. | Optional. If the IPCF needs subscription-related information and does not have it, the IPCF sends a Profile Request to the SSC in order to receive the information.

> 5. | The SSC replies the Profile Request with the profile of subscriber which contains subscription related information; i.e. information about the allowed service(s), QoS information and PCC Rules information.

> 6. | The IPCF selects or generates PCC Rule(s) based on received information in Profile Response to be installed.

> The IPCF can also take a policy decision by deriving an authorized QoS and by deciding whether service flows described in the PCC Rules are to be enabled or disabled.

> 7. | The IPCF stores the selected PCC Rules and selects the Bearer Control Mode that will apply during the IP-CAN session if applicable for the particular IP-CAN.

> Following scenarios are considered while IPCF stores the selected PCC rule:

> • | If the IPCF controls the binding of IP-CAN Bearers, the IPCF stores information about the IP-CAN Bearer to which the PCC Rules have been assigned.

> • | If the BBERF/PCEF controls the binding of IP-CAN bearers, the IPCF may derive the QoS information per QCI applicable to that IP-CAN session for non-GBR bearers.

> 8. | The IPCF provisions the PCC Rules to the PCEF using Diameter CC Answer.

> In Diameter CC Answer the IPCF can provides following information to PCEF, if available:

> • | Selected Bearer Control Mode for the particular IP-CAN

> • | the QoS information per QCI

> • | List of event triggers for which the IPCF desires PCC Rule Requests

> • | authorized QoS (APN-AMBR, Default-EPS-Bearer-QoS, etc.)

> • | User Location Information

> • | usage monitoring status and applicable thresholds for usage monitoring control

> If online charging is applicable then the PCEF requests credit information from the OCS over the Gy interface.

> 9. | The PCEF installs the received PCC Rules. The PCEF also enforces the authorized QoS and enables or disables service flows according to the flow status of the corresponding PCC Rules.

> If QoS information is received per QCI, PCEF sets the upper limit accordingly for the MBR that the PCEF assigns to the non-GBR bearer(s) for that QCI.

> 10. | The PCEF sends a response to the Establish IP-CAN Session Request.

> For GPRS, the GGSN accepts the PDP Context Request based on the results of the authorisation policy decision enforcement. If the requested QoS parameters do not correspond to the authorized QoS, the GGSN adjusts (downgrades /upgrades) the requested UMTS QoS parameters to the authorized values.
> NOTE: The IPCF can reject the IP-CAN session establishment, e.g. the IPCF cannot obtain the subscription-related information from the SSC and the IPCF cannot make the PCC rule decisions.
> AF Session Setup Procedure
> This section describes the Application Function session setup procedure between IPCF and AF.
> This procedure is applicable for establishment of Rx connection between IPCF and AF (IMS) in core network.
> The following figure and the text that follows describe the message flow for an Rx connection establishment procedure.
> AF Session Setup Procedure Call Flow

> • | IP-CAN session is active and the AF receives an internal or external trigger to set-up a new AF session and provides Service Information; i.e. IP address of IP flow, Port numbers, media types, etc.

> • | The AF forwards the Service Information to the IPCF by sending a Diameter AA Request for a new Rx Diameter session.

> • | The IPCF stores the received Service Information.

> • | Optional. If the IPCF needs subscription-related information and does not have it, the IPCF sends a Profile Request to the SSC in order to receive the information.

> • | The SSC replies the Profile Request with the profile of subscriber which contains subscription related information; i.e. information about the allowed service(s), QoS information and PCC Rules information.

> • | The IPCF identifies the affected established IP-CAN Session(s) using the information previously received from the PCEF/V-PCRF and the Service Information received from the AF.

> • | The IPCF sends a Diameter AA Answer to the AF.

> • | The IPCF interacts with the PCEF/V-PCRF and initiates IP-CAN Session Modification Procedure.

> • | When Gxa does not apply for the IP-CAN session, IP-CAN bearer signalling is executed separately for each IP-CAN bearer under the following conditions:

> • | All PCC rules bound to a bearer have been removed or deactivate

> • | One or more bearers have to be modified

> • | The PCEF needs to establish a new bearer

> Supported Standards
> The IPCF complies with the following standards for UTRAN/E-UTRAN/cdma2000-1x/HRPD networks services.

> • | 3GPP References

> • | IETF References

> • | Object Management Group (OMG) Standards

> 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 signaling 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.215 V8.2.0 (2009-05): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control (PCC) over S9 reference point; (Stage 3) 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; Signaling flows and message contents (Release 8)

> IETF References

> • | RFC-768, User Datagram Protocol (UPD), August 1980

> • | RFC-791, Internet Protocol (IP), September 1982

> • | RFC-793, Transmission Control Protocol (TCP), September 1981

> • | RFC-894, A Standard for the Transmission of IP Datagrams over Ethernet Networks, April 1984

> • | RFC-1089, SNMP over Ethernet, February 1989

> • | RFC-1144, Compressing TCP/IP headers for low-speed serial links, February 1990

> • | RFC-1155, Structure & identification of management information for TCP/IP-based internets, May 1990

> • | RFC-1157, Simple Network Management Protocol (SNMP) Version 1, May 1990

> • | RFC-1212, Concise MIB Definitions, March 1991

> • | RFC-1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, March 1991

> • | RFC-1215, A Convention for Defining Traps for use with the SNMP, March 1991

> • | RFC-1224, Techniques for managing asynchronously generated alerts, May 1991

> • | RFC-1256, ICMP Router Discovery Messages, September 1991

> • | RFC-1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis, March 1992

> • | RFC-1398, Definitions of Managed Objects for the Ethernet-Like Interface Types, January 1993

> • | RFC-1418, SNMP over OSI, March 1993

> • | RFC-1570, PPP LCP Extensions, January 1994

> • | RFC-1643, Definitions of Managed Objects for the Ethernet-like Interface Types, July 1994

> • | RFC-1701, Generic Routing Encapsulation (GRE), October 1994

> • | RFC-1850, OSPF Version 2 Management Information Base, November 1995

> • | RFC 1823, LDAPv2 Application Program Interface, August 1995

> • | RFC-1901, Introduction to Community-based SNMPv2, January 1996

> • | RFC-1902, Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1903, Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1904, Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1906, Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2), January 1996

> • | RFC-1908, Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework, January 1996

> • | RFC-1918, Address Allocation for Private Internets, February 1996

> • | RFC-1919, Classical versus Transparent IP Proxies, March 1996

> • | RFC-2002, IP Mobility Support, May 1995

> • | RFC-2003, IP Encapsulation within IP, October 1996

> • | RFC-2004, Minimal Encapsulation within IP, October 1996

> • | RFC-2005, Applicability Statement for IP Mobility Support, October 1996

> • | RFC-2118, Microsoft Point-to-Point Compression (MPPC) Protocol, March 1997

> • | RFC 2131, Dynamic Host Configuration Protocol

> • | RFC-2136, Dynamic Updates in the Domain Name System (DNS UPDATE)

> • | RFC-2211, Specification of the Controlled-Load Network Element Service

> • | RFC-2246, The Transport Layer Security (TLS) Protocol Version 1.0, January 1999

> • | RFC-2328, OSPF Version 2, April 1998

> • | RFC-2344, Reverse Tunneling for Mobile IP, May 1998

> • | RFC-2394, IP Payload Compression Using DEFLATE, December 1998

> • | RFC 2401, Security Architecture for the Internet Protocol

> • | RFC 2402, IP Authentication Header (AH)

> • | RFC 2406, IP Encapsulating Security Payload (ESP)

> • | RFC 2409, The Internet Key Exchange (IKE)

> • | RFC-2460, Internet Protocol Version 6 (IPv6)

> • | RFC-2461, Neighbor Discovery for IPv6

> • | RFC-2462, IPv6 Stateless Address Autoconfiguration

> • | RFC-2486, The Network Access Identifier (NAI), January 1999

> • | RFC-2571, An Architecture for Describing SNMP Management Frameworks, April 1999

> • | RFC-2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), April 1999

> • | RFC-2573, SNMP Applications, April 1999

> • | RFC-2574, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), April 1999

> • | RFC-2597, Assured Forwarding PHB Group, June 1999

> • | RFC-2598, Expedited Forwarding PHB, June 1999

> • | RFC-2618, RADIUS Authentication Client MIB, June 1999

> • | RFC-2620, RADIUS Accounting Client MIB, June 1999

> • | RFC-2661, Layer Two Tunneling Protocol “L2TP”, August 1999

> • | RFC-2697, A Single Rate Three Color Marker, September 1999

> • | RFC-2698, A Two Rate Three Color Marker, September 1999

> • | RFC-2784, Generic Routing Encapsulation (GRE) - March 2000, IETF

> • | RFC-2794, Mobile IP Network Access Identifier Extension for IPv4, March 2000

> • | RFC-2809, Implementation of L2TP Compulsory Tunneling via RADIUS, April 2000

> • | RFC-2845, Secret Key Transaction Authentication for DNS (TSIG), May 2000

> • | RFC-2865, Remote Authentication Dial In User Service (RADIUS), June 2000

> • | RFC-2866, RADIUS Accounting, June 2000

> • | RFC-2867, RADIUS Accounting Modifications for Tunnel Protocol Support, June 2000

> • | RFC-2868, RADIUS Attributes for Tunnel Protocol Support, June 2000

> • | RFC-2869, RADIUS Extensions, June 2000

> • | RFC 2960, Stream Control Transmission Protocol, October 2000

> • | RFC-3007, Secure Domain Name System (DNS) Dynamic Update, November 2000

> • | RFC-3012, Mobile IPv4 Challenge/Response Extensions, November 2000

> • | RFC-3056, Connection of IPv6 Domains via IPv4 Clouds, February 2001

> • | RFC-3101 OSPF-NSSA Option, January 2003

> • | RFC-3143, Known HTTP Proxy/Caching Problems, June 2001

> • | RFC-3193, Securing L2TP using IPSEC, November 2001

> • | RFC-3314, Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, September 2002

> • | RFC-3316, Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts, April 2003

> • | RFC-3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, February 2004

> • | RFC-3543, Registration Revocation in Mobile IPv4, August 2003

> • | RFC 3588, Diameter Base Protocol, September 2003

> • | RFC 4006, Diameter Credit-Control Application, August 2005

> • | RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol, June 2006

> Object Management Group (OMG) Standards

> • | CORBA 2.6 Specification 01-09-35, Object Management Group

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