# Understanding the Service Operation

The IPCF provides wireless carriers with a flexible solution for providing extended and intelligent PCRF functionality for 3GPP Policy and Charging Control (PCC) solution.
The system functioning as IPCF is capable of supporting the following types of deployment scenario for IP-CAN sessions:

- Standalone Deployment of IPCF in Networks: In standalone deployment multiple PCEFs connects to a single IPCF through Gx interface and served by the PCC elements through IPCF.
- Co-located Deployment of IPCF with PCEF 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.

Prior to connecting to the command line interface (CLI) and beginning the system's configuration, there are important things to understand about how the system supports these applications. This chapter provides terminology and background information that must be considered before attempting to configure the system.

Terminology

This section defines some of the terms used in the chapters that follow.

Contexts

A context is a logical grouping or mapping of configuration parameters that pertain to various physical ports, logical IP interfaces, and services. A context can be thought of as a virtual private network (VPN).

The system supports the configuration of multiple contexts. Each is configured and operates independently from the others. Once a context has been created, administrative users can then configure services, logical IP interfaces, subscribers, etc. for that context. Administrative users would then bind the logical interfaces to physical ports.

Contexts can also be assigned domain aliases, wherein if a subscriber’s domain name matches one of the configured alias names for that context, then that context is used.
Contexts on the system can be categorized as follows:

- Source context: Also referred to as the “ingress” context, this context provides the subscriber’s point-of-entry in the system. It is also the context in which services are configured. For example, in a 3G UMTS network, the network function containing the PCEF would communicate with the IPCF system via Gx/Gx-like interfaces configured within the source context as part of the PCC-service.
- Destination context: Also referred to as the “egress” context, this context is where a subscriber is provided connectivity to PCC elements (such as access to the SSC, AF etc.) as configured on PCC and related services. For example, the system’s destination context would be configured with the Sp or Rx interfaces facilitating subscriber policy profile and charging rule data traffic to/from the PCC elements or other PDN (Mobile Data Service or Internet.
- Local context: This is the default context on the system used to provide out-of-band management functionality.

Logical Interfaces

This section describes the logical interface supported on PCC-IPCF.

Prior to allowing the flow of user data, the port must be associated with a virtual circuit or tunnel called a logical interface. A logical interface within the system is defined as the logical assignment of a virtual router instance that provides higher-layer protocol transport, such as Layer 3 IP addressing. Interfaces are configured as part of the VPN context and are independent from the physical port that are used to bridge the virtual interfaces to the network.

Logical interfaces are assigned to IP addresses and are bound to a specific port during the configuration process. Logical interfaces are also associated with services through bindings. Services are bound to an IP address that is configured for a particular logical interface. When associated, the interface takes on the characteristics of the functions enabled by the service. For example, if an interface is bound to a PCC-service, it will function as a Gx interface between the PCEF service and the IPCF node.
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 IPCFThe 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 controlThe 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.

Bindings

A binding is an association between “elements” within the system. There are two types of bindings: static and dynamic.
Static binding is accomplished through the configuration of the system. Static bindings are used to associate:

- A specific logical interface (configured within a particular context) to a physical port. Once the interface is bound to the physical port, traffic can flow through the context just as if it were any physically defined circuit. Static bindings support any encapsulation method over any interface and port type.
- A service to an IP address assigned to a logical interface within the same context. This allows the interface to take on the characteristics (i.e., support the protocols) required by the service. For example, a PCC-service bound to a logical interface will cause the logical interface to take on the characteristics of a Gx interface within a 3GPP UMTS network.

Dynamic binding associates a subscriber to a specific egress context based on the configuration of their profile or system parameters. This provides a higher degree of deployment flexibility as it allows a wireless carrier to support multiple services and facilitates seamless connections to multiple networks.

Services and Networks

This section describes the services configured on IPCF to support various functionality.
Services are configured within a context and enable certain functionality. The following services can be configured on the system:

- PCC-services: PCC-services are configured in Context configuration mode to support Policy Charging and Control Function. The PCC-service must be bound to a logical interface within the same context. Once bound, the interface takes on the characteristics of a Gx interface. Multiple services can be bound to the same logical interface. Therefore, a single physical port can facilitate multiple Gx interfaces.It manages the policy logic for the networks. The authorization of resources for a subscriber’s data usage under various conditions and policies are defined in the PCC-service.Only one PCC-service can be configured on a system which is further limited to a maximum of 256 services (regardless of type) configured per system.
- PCC-AF-Service: PCC-AF-Service is configured in Context configuration mode to link, configure, and manage the Application Function endpoints and associated PCC-services over Rx interface for the IPCF services.The PCC-AF service consolidates the provisioning and management required for the PCC-AF services being supported by the network that fall under the PCC regime. The application service handles the Rx interface over which the IPCF may receive media information for the application usage from AF. In case of absence of the Rx interface, the media information is available in the PCC-AF Service statically.Multiple PCC-AF service instances can be configured on a system which is further limited to a maximum of 256 services (regardless of type) configured per system.
- PCC-Policy-Service: PCC-Policy Service configured in Context configuration mode to link, configure, and manage the policy authorization where IPCF acts as a policy server with PCEF/BBERF/AN-GW.The PCC-Policy-service is mainly used to provide a mechanism to manage the external Gx or similar interfaces required for policy authorization purpose. It manages Gx and Gx-like interfaces such as Gxa/Gxc which is based on the dictionary used for PCC-Policy-service.Multiple instances of PCC-Policy-Service may exist in a system which could link with the same PCC-Service that controls the business logic. This service allows for configuration management for peers as well as services related to Gx like functions. Multiple PCC-Policy service instances can be configured on a system which is further limited to a maximum of 256 services (regardless of type) configured per system.
- PCC-Sp-Endpoint: PCC-Sp endpoint configured in Context configuration mode to link, configure, and manage the Sp interface endpoints towards SSC for operational parameter configuration related to its peer.An instance of PCC-Sp-endpoint represents a client end for SSC interactions and facilitates the configuration of the treatment required for the Sp interface as well as manage the connection and operational parameters related to its peer.Only one PCC-Sp-endpoint across a chassis can be configured on a system.
- Event-Notification Interface Endpoint: Event notification endpoint configured in Context configuration mode to enable the event notification interface (Enctrl) mechanism on IPCF and to configure the Event Notification collection server endpoint related parameters.Only one Event Notification interface across a chassis can be configured on a system.

Following figure illustrates the relationship between services, interfaces, and contexts within the IPCF system for PCC service in 3G UMTS networks.

IMPORTANT:

ASR 5000 platform provides a highly flexible configuration model where any service/interface can be configured in any context. Example provided here is for illustration purpose only.
Figure 1. Service, Interface, and Context Relationship Within the System

The source context used to service a subscriber session is the same as the context in which the PCC related services are configured. Each PCC-Policy service is bound to an IP address in a source context. Once a PCEF has established a Gx session with a IPCF, the IPCF continues to use the same address as a Gx node.

The destination context is used to service the Sp interface session to connect with SSC.