Intelligent Policy Control Function Overview

The Cisco ASR 5x00 Platform provides 3GPP PCC solution to network carrier operators with Intelligent Policy Control Function (IPCF) in UTRAN/E-UTRAN/cdma2000-1x/HRPD/LTE networks.

It offers an end-to-end Policy and Charging Control (PCC) solution that provides one of the highly intelligent and high performance solutions. 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

This section provides an overview and describes the building blocks for the PCC solution.

The PCC solution 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.
Figure 1. 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 are 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)

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 5x00 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 reports 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 be 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 SSC 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 modeling 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.

Licenses

The IPCF is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

Platform Requirements

The IPCF service runs on a Cisco® ASR 5x00 chassis running StarOS Rel. 10 or later. The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, refer to the Installation Guide for the chassis and/or contact your Cisco account representative.

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/LTE Networks

This section describes the deployment scenario of IPCF with Cisco PCC solution.

PCC elements can be deployed in various combinations but following are the most common scenarios for PCC deployment in UTRAN/E-UTRAN/cdma2000-1x/HRPD network:

Standalone Deployment of IPCF

In standalone deployment, multiple PCEFs (GGSN/PDSN/P-GW) connect 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.
Figure 2. Co-located PCEF and IPCF in UTRAN/E-UTRAN Networks

Co-located Deployment of IPCF

In co-located deployment IPCF is placed 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.
Figure 3. 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 terminate 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 signaling 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 residing 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 one 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 one 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 transport notifications on signaling 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 one interface for WEM and one 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 as 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:

Emergency APN/PDN Support

IPCF provides the support of emergency APN or PDN for a IP-CAN subscriber who is not subscribed to any service in network.

Emergency services; e.g. 911 in the US, are those services that are provided via an emergency APN and may or may not require subscription. Since subscription to such services are optional, it implies that fetching subscriber profile information, as is done during canonical session establishment procedures, is not a requirement. Also, the local network to which the UE is currently attached handles such sessions, and therefore the S9 roaming interface is not applicable as well.

IMPORTANT:

Refer IPCF Administration Guide for more information on configuration of this support.

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.

Multiple Time-Slot Support

IPCF provides the support of multiple time slots for day of week, time of the day, and a particular date to support policies based on various combinations of date, day, and time.

Till StarOS release 12.1 only one time period was allowed in implementation of Timedef. With this enhancement multiple time periods can be configured.

Due to single time period in the timedef, it was not possible to support policies; where given actions are to be applied for disjoint time periods. For example, policy that is applicable only on holidays, policy for workday from 8:00 AM to 8:00 PM each day etc.

With this feature support multiple time-slots can be configured with three flavors of start day, start time and start date.

IMPORTANT:

Refer IPCF Administration Guide for more information on configuration of this support.

Policy and Charging Control Function

IPCF provides the 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

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

Roaming Support

IPCF provides roaming and blacklisting support in any access network.

The Cisco PCC solution provides a mechanism to address various operator requirements related to roaming subscriber in their network. All the roaming related requirements are implemented with following function categories:
  • Operator Network definition: This function provides a solution for differentiated billing to subscribers while they are using mobile broadband access in their defined area “Home” versus using the service when they are “Roaming”. This high level function is further broken down into the following sub-functions:
    • Defining Regions/Zones/Circles in the operator's network
    • Supporting operator defined lists of Regions
    • Defining 'Home' for subscribers
  • Supporting White-listing (allowed list) and Black-listing (disallowed list)
  • Persistently storing current/last subscriber session information
  • Current Subscriber Session Information: Till StarOS 12.1 release, the SSC in the Cisco PCC solution did not support storage of dynamic subscriber session information persistently. The only information that falls in this category are the usage monitoring counters (volume and time). Now with StarOS 14.0, the IPCF is allowed to store operator defined subscriber session attributes across sessions.

IMPORTANT:

Refer IPCF Administration Guide for more information on configuration of this support.

System Management Features

This section describes following features:

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 reasons and to maintain system performance.

Operation and Maintenance module of ASR 5x00 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:
Figure 4. 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-Profile: Provides PCC subscriber profile 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.
  • 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.
Thresholding reports conditions using one of the following mechanisms:
  • SNMP traps: SNMP traps are created to 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. 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 5x00 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.

At IPCF, time monitoring over Gx feature enables it to monitor session time usage of a subscriber. With this feature available, IPCF is able to set time-base usage thresholds on Flow-level (PCC Rule level) or Session-Level Basis. The thresholds are communicated to PCEF over Gx interface. As per this implementation the time monitoring can be viewed as a natural extension to volume monitoring over Gx.

When a time-based usage reaches the provisioned threshold, then PCEF will report the usage to IPCF. If the subscriber session terminates before threshold is reached, PCEF will report the usage to IPCF while indicating the termination. The time threshold values provisioned to PCEF can be configured locally at IPCF or may come from SSC through Data Plans translated as Usage monitors at IPCF.

For time usage threshold and monitoring support the IPCF works in following manner:
  1. IPCF receives data plan information along with threshold information from SSC.
  2. Data plan information for a subscriber is treated as usage monitor information at IPCF.
  3. Based on the operator configuration, IPCF can associate monitoring-key(s) with usage monitor(s). While this association is being done, IPCF also calculates the value of the threshold to be sent along with the monitoring key. As per operator configuration, IPCF decides if a particular monitoring-key is being used at Session-Level or PCC Rule-Level.
  4. IPCF calculates and communicates the usage thresholds to PCEF over Gx interface.
  5. IPCF can also enable an event trigger USAGE_REPORT over Gx interface so that it can receive the subscriber time usage information.
  6. When USAGE_REPORT event-trigger is enabled, once a subscriber consumes time and the threshold is reached, then IPCF receives CCR-Update message with the monitoring key and the time consumed. IPCF updates this time usage in all the usage monitors that are associated with this monitoring key.
  7. In order to continue usage counting at PCEF, PCRF sends back threshold values for the reported monitoring-keys in response.
  8. In a case where subscriber session terminates before reaching the threshold, then IPCF will receive the time used in CCR-Termination message.
  9. IPCF conveys the usage updates back to SSC over Sh.

IMPORTANT:

IPCF also have an operator configured policy based on the time usage. This policy can be defined based on the conditions on absolute time usage and the subscription limit of the usage monitor. Refer IPCF Administration Guide for more information on configuration of this support.

Time-Usage Monitoring Over Gx Support

IPCF provides the support of time usage monitoring over Gx interface for subscriber usage thresholds.

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

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

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 to 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 5x00.

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

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.
Figure 6. 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 the 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 provides the 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.
Figure 7. AF Session Setup Procedure Call Flow
  1. 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.
  2. The AF forwards the Service Information to the IPCF by sending a Diameter AA Request for a new Rx Diameter session.
  3. The IPCF stores the received Service Information.
  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 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.
  7. The IPCF sends a Diameter AA Answer to the AF.
  8. The IPCF interacts with the PCEF/V-PCRF and initiates IP-CAN Session Modification Procedure.
  9. When Gxa does not apply for the IP-CAN session, IP-CAN bearer signaling is executed separately for each IP-CAN bearer under the following conditions:
    • All PCC rules bound to a bearer have been removed or deactivated
    • 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

  • 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