Policy and Charging Control

The Policy and Charging Control (PCC) architecture of OpenEPC project consists of a comprehensive set of components and reference points which have been implemented with respect to the 3GPP TS 29.203 recommendations. The PCRF features a policy-based decision engine, which has been extended with the newly proposed Sp interface at the HSS/SPR. The PCRF, PCEF and BBERF functions cooperate in pushing rules from the Application Functions (AF) towards the access gateways where QoS and Charging can be provided. Events are also pushed back towards the AF, such that the application can dynamically react in changes at the access level.

OpenEPC Rel. 3 includes an overhauled set of components which handle the data traffic in the data path gateways enabling flexible routing. This functionally lead to high performance improvement as well as to a high flexibility support for gating and QoS throttling. Additionally, as the data traffic handling is completely controlled by the OpenEPC components, traffic counters and monitoring functionality is sustained.

Additionally, the PCRF sends to the PCEF bearer differentiation and charging correlation information which enables the charging systems to further correlate the charging data records with application information. More information on the charging system as well as on information correlation in OpenEPC is available here.

1. OpenEPC Policy and Charging Rules Function (PCRF)

The PCRF component has been realized according to the  3GPP TS29.203 Policy and charging control Architecture Rel.9. Besides a central part, a modular model is following the specifications based on the respective interface specifications:

• Rx reference point between the PCRF and the AF  3GPP TS29.214, for transport of application level session information from the AF to the PCRF and delivery of IP bearer events in the opposite direction.
• Sp reference point between the PCRF and the SPR (HSS) (not yet standardized, but resembling the HSS Sh interface), for retrieval of subscriber identities and profiles.
• Gx reference point between the PCRF and the PCEF  3GPP TS29.212, for provisioning of charging rules and transmission of IP-CAN resource usage information.
• Gxx reference point between the PCRF and the BBERF  3GPP TS29.212, for provisioning of QoS rules and transmission of IP-CAN binding and event trigger information.

Besides bearer and session binding operations, the PCRF features an integrated Policy Engine, which can check the incoming events and requests and apply specific actions accordingly. These policy rules can be applied at the following 4 levels, based on the functional requirements:

• Push sphere - for Rx provisioning operations
• Pull sphere - for Gx and Gxx rule retrieve operations
• Event sphere - for generated events operations
• Profile sphere - for subscriber profile related operations (implemented, but not yet fully supported by the HSS features)

The input parameters and output actions, although currently limited to the following lists, can be easily extended. These allow for customizations based on subscriber profiles, service profiles, access networks, etc. and provide a dynamic PCC Rule authorization and selection of QoS parameters.

• Supported PCRF Policy Engine parameters:
  • Service Identifier
  • Service Class
  • Subscriber Category
  • APN
  • AF Signaling
  • Media Type
  • Reservation Priority
  • Max-Bandwidth
  • Codec
  • IP-CAN type
  • RAT type
  • Event
• Supported actions:
  • Subscribe to events
  • Setting various values (e.g. QCI, Max-Bandwidth, ARP, precedence, expiration, gate-status, etc.)
  • Abort or Reject session

For the PCRF, PCEF and BBERF the set of predefined PCC rules can be edited through the OpenEPC Web GUI.

Limitations:

• charging, with the respective Gy or Gz reference points, is deferred to the next release
• roaming scenarios, with the respective S9 reference point, is deferred to the next release
• no subscription to SPR information, but on-demand-pull. As a result, although implemented, there are no Profile sphere policies triggered.
• does not differentiate between predefined and dynamic PCC rules
• no interaction with the SPR for provisioning the default EPS bearer
• no support for monitoring keys

top

1.1 PCRF Rx Reference Point

The Rx interface is provided as a submodule of the PCRF with the role of managing the state of the AF sessions based on the available PCC and QoS rules.

The implementation is based on:

•  3GPP TS29.214 Rel. 9 PCC Rx interface
•  3GPP TS29.213 Rel. 9 PCC signalling flows and QoS parameter mapping

Supported features:

• handles requests of creation, update and termination of IP bearer resources over the Rx interface
• provision PCC/QoS rules to the PCEF/BBERF
• session binding for both IPv4 and IPv6 addresses
• basic support for private IP addresses when the AF provides the appropriate APN information
• persistence of the sessions stored in a database
• user plane event notification for events handled by the PCRF module

Limitations:

• no special policies or checking for emergency traffic
• no support for charging correlation between AF and PCRF
• it does not differentiate between preliminary and final service information

top

1.2 PCRF Gx and Gxx Reference Points

The Gx and Gxx interfaces are also implemented as a submodules of the PCRF component.

The implementations are based on:  3GPP TS29.212 and they support pushing rules towards the PCEF/BBERF components and receiving events from them.

top

2. OpenEPC Policy and Charging Enforcement Function

The PCEF component manages and enforces the PCC rules received from the PCRF, providing gating support by using a separate IP-CAN enforcement module (such an implementation using the Linux kernel is provided in the IPCAN Linux Gateay module - see below). The PCEF module supports pulling for PCC rules from the PCRF and modification of gating rules at IP-CAN session establishment or modification in the PCRF. It can also act upon the messages received from the PCRF regarding IP-CAN session release or installation, modification and removal of PCC rules.

The implementation is based on:  3GPP TS29.212 Policy and Charging Control over the Gx reference point.

The PCEF is extended with monitoring and reporting functionality as well as with the integration with the OpenEPC charging system as described here. The reporting information as received from the flexible data path forwarding module enables the PCEF to transmit to the PCRF a large number of events customized according to the TS 29.213 and further extended to any data path related events.

Limitations:

• no support for monitoring and reporting of the usage threshold for input, output or total data volume for the IP-CAN session

top

3. OpenEPC Bearer Binding and Event Reporting Function

The BBERF component manages and enforces the QoS rules received from the PCRF using the aforementioned flexible data path enforcement module. The BBERF module supports pulling for QoS rules at Gateway Control session establishment or modification to the PCRF. It can also act upon the messages received from the PCRF regarding Gateway Control session release or installation, modification and removal of QoS rules.

The reporting information as received from the data forwarding module enables the BBERF to send to PCRF notifications on a large set of events including the a large number of events customized according to the TS 29.213 and further extended to any data path related events

top

4. OpenEPC Rel. 3 OpenEPC Flexible User-Plane Path Entities

For a more flexible control of the user plane communication, OpenEPC Rel. 3 features a new user space routing module enabling the encapsulation and the forwarding of the data traffic according to the Proxy Mobile IP and GTP established data paths. This module allows the PCEF and the BBERF modules to install the specific PCC and QoS rules as received from the PCRF on the data path for gating and QoS throttling. From the PCC/QoS rules received, this module allocates and deallocates the required bandwidth (for both upload and download link). The identification and classification of the IP flows is done based on the user space packet matching and differentioation.

Supported features:

• dual IPv4 and IPv6 operation
• transport level parameters: type of transport protocol, source and destination port
• triggers data path events

top

5. OpenEPC Rx Client

A sample implementation of the Rx client interface for other applications to use is also part of the OpenEPC. This allows for internal or external Application Functions, as an option, to abstract from the Rx and Diameter details and as such be realized much quicker.

One such example which uses this module, through the console exported functions over TCP, is the adaptations to the  Squid HTTP-proxy. There a small and light external ACL program has been developed, named Rx_auth, as a proof of concept. This is used by Squid to authorize any HTTP request proxies. For this purpose, the Rx_auth program re-uses the Rx Client module to allocate IP bearer resources between the HTTP client and the HTTP proxy.

The Client_Rx module has been implemented based on:

•  3GPP TS29.214 Rel. 9 PCC Rx interface specifications
•  3GPP TS29.213 Rel. 9 PCC signaling flows and QoS parameter mapping

Supported Features:

• requesting of creation, update and termination of IP bearer resources over the Rx interface
• subscription to bearer events and callback triggering on notifications
• internal Wharf usage from other modules, or external through console module exported functions (stdio/stdout, TCP)

Limitations:

• no persistence support yet - Wharf restarts will result in a loss of all sessions in progress.

top

6. Open Source IMS Core PCC implementation

The Proxy-CSCF component of the  The Open IMS Core Project is based upon Open Source software(e.g. the SIP Express Router (SER) or MySQL). We have extended it to fully support the standard PCC procedures on the Rx reference points towards the PCRF instance, in order to manage service authorization and resource reservation. These extensions are and will be supported by the OpenEPC development team such that the Open Source IMS Core will integrate smoothly with the OpenEPC components.

The implementation is based on:

•  3GPP TS29.214 Rel. 9 PCC Rx interface specification
•  3GPP TS29.213 Rel. 9 PCC signaling flows and QoS parameter mapping
•  RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP)

Supported features:

• requests enabling, updating or removing of IP flows for successful IMS registrations and established IMS sessions
• subscription to notification of signaling transmission path status

Limitations:

• does not check if the SDP payloads are proposing to use a circuit-switched bearer
• no support for media traversal of NATs (using a RTP-Proxy)
• no preliminary enabling of registration IP flows, only triggered after successful registration
• no storage of the current IP flows of the sessions and Diameter sessions. The IP flows are created based on the current SIP messages and the associated Diameter session and lost over P-CSCF restarts.