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 -
a rule name - the rule name is used to reference a PCC rule during communication between
PCRF and PCEF
service identifier - the service identifier is used to identify a service or service component the
SDF relates to
SDF filter(s) - the SDF filters are used to select the traffic for which the rule applies
precedence - order of the SDF filter; dynamic rule takes precedence over pre-defined rule in
case of same precedence
gate status - whether the SDF detected should be allowed to pass or blocked
QoS parameters - includes the QCI, the ARP and bitrates for uplink and downlink
charging key and charging parameters - online or offline charging
monitoring key - identifies a monitoring control instance that shall be used for usage
monitoring control of the SDFs
https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/PCC
Architecture
non-roaming.png?attredirects=0
https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/PCC
Architecture non-roaming.png?attredirects=0
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
Gsc interface exist between sgw and
pcrf
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.
https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/Sample
SDF
detection.png?attredirects=0
https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/Sample
SDF detection.png?attredirects=0
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.
https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/Sample
SDF detection in Uplink
Direction.png?attredirects=0
https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/Sample
SDF detection in Uplink Direction.png?attredirects=0
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.


https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture/PULL
procedure.png?attredirects=0

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.