Policy and Charging Control

The Policy and Charging Control architecture in the Release 1 of the 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 charging and QoS can be provided. Events are also pushed back towards the AF, such that the application can dynamically react in changes at the access level. Experimental QoS enforcing functionality is provided in Release 1, with charging being deferred for a future release on customer demand.

1. OpenEPC Release 1 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 Release 1 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.

Limitations:

• no support for the Gy/Gz reference points for charging in Release 1
• support for event triggering towards the PCRF regarding bearers is limited to the events received from the IPCAN Linux Gw module
• 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 Release 1 Bearer Binding and Event Reporting Function

The BBERF component manages and enforces the QoS rules received from the PCRF using the aforementioned IP-CAN enforcement modules. 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.

Limitations:

• limited event generation capabilities, mainly due to limitations of the Release 1 IP-CAN enforcement modules

top

4. OpenEPC Release 1 IP-CAN Linux Gateway

A module to be used by both PCEF and BBERF modules for the purposes of gating/QoS enforcing and bearer event reporting is provided as part of Release 1, through an implementation based on the Linux kernel and tools. From the PCC/QoS rules received, this module will allocate/deallocate the required bandwidth (for both upload and download link) using the  www.linux.org/docs/ldp/howto/Traffic-Control-HOWTO/index.html Linux kernel Traffic Control mechanisms and operations. The identification and classification of the IP flows, described by the PCC entities through the IPFilterRule conventions, is done using the Linux packet filtering framework  www.netfilter.org/.

The interface of this module is standardized and not specific to the used Linux kernel facilities. As such, for optimizations or support of different platforms, alternative IP-CAN functionality could be used from the PCEF and BBERF functions.

Supported features:

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

Limitations:

• bounded to the Linux operating system
• it does not trigger IPCAN events yet (feature in development, but not part of Release 1)

top

5. OpenEPC Release 1 Rx Client

A sample implementation of the Rx client interface for other applications to use is also part of the Release 1. 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 signalling 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.