PCC Architecture

PCC Architecture

Policy Control and Charging (PCC) functionality comprises of Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), Bearer Binding and Event Reporting Function (BBERF), Online Charging System (OCS), Offline Charging System (OFCS), Subscription Profile Repository (SPR) and Application Function (AF). These functional entities are shown in Figure 1 with their logical reference points. PCC enables a centralized control to ensure that the service sessions (also called IP-CAN sessions, more in other article) are provided with appropriate bandwidth and QoS. PCC also provides a means to control charging on a per-service basis.

PCC Rules and its Purposes

The purpose of the PCC rule is-

• to detect a packet belonging to an SDF to map that packet to proper IP-CAN bearer in downlink and uplink direction
• to identify the service
• to provide appropriate applicable charging
• to provide policy control

There are 2 different types of PCC rules -

• Dynamic PCC rules - These PCC rules are dynamically provisioned by PCRF to PCEF over Gx interface.
• Pre-defined PCC rules - These PCC rules are pre-configured in the PCEF. The PCRF can advise the PCEF to activate a set of PCC rules over Gx interface.

A PCC rules consists of -

1. a rule name - the rule name is used to reference a PCC rule during communication between PCRF and PCEF
2. service identifier - the service identifier is used to identify a service or service component the SDF relates to
3. SDF filter(s) - the SDF filters are used to select the traffic for which the rule applies
4. precedence - order of the SDF filter; dynamic rule takes precedence over pre-defined rule in case of same precedence
5. gate status - whether the SDF detected should be allowed to pass or blocked
6. QoS parameters - includes the QCI, the ARP and bitrates for uplink and downlink
7. charging key and charging parameters - online or offline charging
8. monitoring key - identifies a monitoring control instance that shall be used for usage monitoring control of the SDFs

The Application Function (AF) (eg. P-CSCF for IMS solution, or Video Streaming Server for non-IMS solution) interacts with applications or services that require dynamic PCC. The AF extracts session information from the application signalling and provides it to the PCRF. The Rx reference point resides between AF and PCRF. The AF provides the following application session related information to the PCRF-

• Subscriber Identifier
• IP address of the UE
• Media Type and Format
• Bandwidth
• Flow description eg. Source and Destination IP addresses and the protocol
• AF Application Identifier
• AF Communication Service Identifier
• AF Application Event Identifier
• AF Record Information
• Flow Status
• Priority Indicator
• Emergency Indicator

The Subscription Profile Repository (SPR) contains subscriber/subscription information. This information is per-PDN basis and includes-

• Subscriber's allowed services
• Information on subscriber's allowed QoS (MBR and GBR)
• Subscriber's charging related information
• Subscriber category

The Sp reference point resides between SPR and PCRF. It allows the PCRF to request subscription information related to a subscriber's service/session.

The Online Charging System (OCS) is a credit management system for pre-paid charging. Within OCS lies a functional entity called Service Data Flow Based Credit Control Function which performs online credit control function. The PCEF interacts with OCS to check out credit and report credit status over Gy interface.

The Offline Charging System (OFCS) is used for offline charging. The OFCS receives charging events from PCEF over Gz interface and generates Charging Data Records (CDRs) which are sent to the billing system.

For EPS, the Policy Charging and Enforcement Function (PCEF) is always located in the PDN-GW. The Bearer Binding and Event Reporting Function (BBERF) location depends on the access technology. For 3GPP, the BBERF is located in the Serving-GW, whereas for eHRPD, the BBERF is located in the HSGW.

The Policy Charging and Rules Function (PCRF) provides network control regarding service data flow detection, gating (blocking or allowing packets), QoS control and flow-based charging towards the PCEF. It can also apply security procedures before accepting information from the AF. The PCRF ensures that the PCEF user plane traffic mapping and treatment is in accordance with the user's subscription profile which it receives from SPR over Sp interface. The PCRF may reject the request received from the AF when the service information is not consistent with subscription information (either locally configured or received from SPR) and the PCRF responds to the AF with appropriate reason.

The PCRF accepts input for PCC decision making from the PCEF over Gx interface, the BBERF (if available), the SPR and the AF (if available) as well as its own pre-defined information. These nodes provide the following information to the PCRF-

• Subscriber Identifier
• IP address of the UE
• IP-CAN bearer attributes
• Request Type (Initial, Modification, etc)
• Type of IP-CAN (GPRS, etc)
• Location of Subscriber
• PDN ID
• PLMN Identifier
• IP-CAN bearer establishment mode

The PCEF encompasses Service Data Flow detection, policy enforcement and flow based charging functionalities. It provides Service Data Flow detection, user plane traffic handling, triggering control plane session management, QoS handling, service data flow measurement and online/offline charging interactions.

The PCEF will allow a particular service data flow to pass through a PCEF only if the gating function allows. The PCEF is able to convert a QCI value to IP-CAN specific QoS attribute values and determine QCI value from a set of IP-CAN specific QoS attribute values. The PCEF enforces the authorized QoS of a service data flow according to an active PCC rule, and that authorized QoS is mapped to the IP-CAN specific QoS attributes.

For a service data flow that is subject to charging control, the PCEF will allow the service data flow to pass through the PCEF if and only if there is corresponding PCC rule, and for online charging, the OCS has authorized credit for the charging key.

If an IP-CAN session is modified, the PCEF first uses the event trigger to determine whether to request the PCC rules for the modified IP-CAN session from the PCRF. Then upon reception of updated PCC rules from the PCRF, the PCEF activates, modifies or removes the PCC rules as indicated by the PCRF.

Bearer Binding

The PCC rule needs to be mapped to a particular IP-CAN bearer to ensure the packets receive the appropriate QoS treatment. The association between PCC rule and a bearer is referred to as bearer binding. The bearer binding is done by the Bearer Binding Function (BBF). The BBF is located either in the PCEF (if GTP is used as the protocol on S5/S8 interface aka. on-path model) or the BBERF (if Mobile IP is used as the protocol on S5/S8 interface aka. off-path model).

When the PCRF sends new or modified PCC rules to the PCEF or BBERF (depending upon the location of BBF), the BBF evaluates whether it is possible to use one of the existing IP-CAN bearers and initiate IP-CAN Bearer Modification procedure or initiate a new IP-CAN Bearer Establishment procedure. The binding is created between the Service Data Flow(s) and the IP-CAN bearer which has the same QoS Class Identifier (QCI - applies to user plane) and Allocation and Retention Priority (ARP - applies to control plane).

Event Triggers

The Event Reporting Function (ERF) performs event trigger detection. When an event matching the event trigger occurs, the ERF report the occurred event to the PCRF. The ERF is located either at the PCRF (on-path model) or BBERF (off-path model). Event triggers determine when the ERF shall signal to the PCRF that an IP-CAN bearer has been modified. The following are some of the event triggers that the ERF can react-

• PLMN change - The UE has moved to another operator's network
• QoS change - IP-CAN bearer QoS change
• Location change - serving cell/area/core-node change of the UE
• Enforced PCC rule change - PCEF is performing a PCC rule request as instructed by the PCRF
• UE IP address change

Service Data Flow Detection

Service Data Flow (SDF) - An aggregate set of packet flows that matches a service data flow template.

Service Data Flow Template - The set of Service Data Flow Filters in a PCC rule, required for defining a service data flow.

Service Data Flow Filter - A set of packet flow header parameter values/ranges used to identify one or more of the packet flows constituting a service data flow.

Service Data Flow Filter Identifier - A scalar that is unique for a specific service data flow filter within an IP-CAN session.

Once the service session is setup and media traffic is flowing, the PCEF/BBERF use the packet filters of installed PCC rules to classify IP packets to authorized SDFs. This process is called SDF detection. Each PCC rule contains a SDF template, which defines the data for SDF detection. Each SDF template may contain any number of SDF filters. SDF filters are unidirectional, so detection is applied independently for downlink and uplink direction.

The SDF filter may be a pattern matching (IP 5 tuple) Source and Destination IP address/range, Source and Destination Port number/range, and Protocol ID of the protocol above IP. It can also include ToS (IPv4) or Traffic-Class (IPv6). The SDF filter is also called a Traffic Flow Template (TFT).

Figure 2 shows an example SDF detection and mapping of packets to IP-CAN bearers in downlink direction. In downlink direction, all the SDF templates associated with the IP-CAN session for the destination address are candidates for matching in the detection process.

Note that the SDF filters in an SDF template are assigned a preference value and the packet is matched with the SDF filter with the highest preference at the PCEF. If the packet does not match any SDF filter, it is discarded.

The following figure 3 shows an example SDF detection and mapping to IP-CAN Bearers in uplink direction. This is done at the UE.

PCC Procedures over Gx Interface

Please note PCC procedures over Gxx interface will not be covered in this article.

There are 2 procedures through which the PCRF can communicate PCC rules to PCEF over Gx interface. They are -

• Pull Procedure: In this procedure the PCEF request for PCC rules from PCRF in following instances.
  • At IP-CAN Session Establishment - The PCEF sends a Credit Check Request (CCR) message with CCR-Type value set to "Initial_Request" . It also includes user subscription and IP-CAN session related information to allow the PCRF to identify the rules to be applied. The PCRF validates the request message and responds with a Credit Check Answer (CCA) message. If the PCRF rejects the request, it includes the Error cause in the CCA message.
  • At IP-CAN Session Modification - This can occur when an IP-CAN bearer is being established/modified/terminated, or UE requests network resources to be modified, or an event triggers. The PCEF sends a Credit Check Request (CCR) message with CCR-Type value set to "Update_Request". The PCEF also includes the Event Trigger (could be UE requested) that caused the IP-CAN bearer modification, any previously provisioned PCC rules that needs to be modified and charging information. The PCRF validates the request message and responds with a Credit Check Answer (CCA) message.

• Push Procedure: In this procedure, the PCRF may decide to provision PCC rules without obtaining any request from the PCEF. This could be in response to information provided by AF over Rx interface, or internal trigger within the PCRF. The PCRF sends these PCC rules in Re-Auth Request (RAR) message. The RAR message also includes the Event Trigger and Event Report indications for the session. The PCEF sends Re-Auth Answer (RAA) message in response to the RAR message.

PCC related 3GPP Technical Specifications are 23.203 and 29.212.