Under the 3GPP architecture, the Policy and Charging Rules Function (PCRF) makes the policy control decision. The Policy and Charging Enforcement Function (PCEF) enforces it. The PCRF manages the rules on the PCEF over the Gx interface; the PCEF reports usage to billing over Gy and Gz. In our PCEF, deep packet inspection (DPI) identifies the applications in the traffic.
What does the PCRF decide, and what does the PCEF enforce?
Under 3GPP TS 23.203, the PCRF makes the policy control decision: it decides how certain service traffic is treated in the PCEF. The PCEF, located at the gateway, enforces that decision by controlling whether a flow passes and what quality of service (QoS) it gets.
The standard assigns the PCRF the policy control decision and flow-based charging control. It provides network control over service data flow detection, gating, QoS and flow-based charging, except credit management, towards the PCEF. The PCRF sets the treatment of user-plane traffic in the PCEF so that it matches the user’s subscription profile.
Under the 3GPP architecture, the PCEF covers service data flow detection, policy enforcement and flow-based charging. It enforces policy in two ways. Gate enforcement lets a flow pass only if its gate is open, and QoS enforcement applies the authorized QoS to the flow. The PCEF also performs service data flow measurement and handles the online and offline charging interactions.
The PCRF decides, and the PCEF applies the decision to traffic. Our PCEF enforces QoS policies and flexible billing as required by the PCRF.
How the PCEF and PCRF talk to each other: Gx, Gy, and the session flow
The PCEF and the PCRF talk over the Gx interface, a Diameter interface. When a subscriber’s data session is established, the PCEF sends the PCRF a CC-Request (CCR). The PCRF answers with a CC-Answer (CCA) that provides the policy and charging control (PCC) rules for that session. The PCEF reports usage to billing over Gy and Gz.
Diameter carries authentication, authorization and accounting (AAA) messaging over TCP or Stream Control Transmission Protocol (SCTP). See our Diameter protocol glossary entry.
Under the 3GPP architecture, a PCC rule enables the detection of a service data flow and carries parameters for policy control and/or charging control.
| Interface | Connects | What it carries |
|---|---|---|
| Gx | PCEF and PCRF | Dynamic PCC rules, and references to predefined rules, from the PCRF to the PCEF; requests and event reports from the PCEF to the PCRF |
| Gy | PCEF and online charging system (OCS) | Online credit control for flow-based charging, over Diameter |
| Gz | PCEF and offline charging system (OFCS) | Offline charging information for flow-based charging |
| Sy | PCRF and OCS | Policy counter status information on subscriber spending, from the OCS to the PCRF |
Our post DPI System Components describes an example of a data session; we condense it into six steps.
| Example session flow | What happens | Interface |
|---|---|---|
| 1. Session start | The PCEF sends the PCRF a CC-Request with subscriber and service information | Gx |
| 2. Profile | The PCRF requests the subscriber profile from the user data repository (UDR) over Ud; the standard also defines the subscription profile repository (SPR) over Sp for this | Sp or Ud |
| 3. Decision | The PCRF decides whether, and with what quality parameters, to provide the service, and builds the PCC rules | Inside the PCRF |
| 4. Answer | The PCRF returns the rules to the PCEF in a CC-Answer | Gx |
| 5. Credit control | The PCEF opens a credit-control session with the OCS, the session is authorized and traffic starts to flow | Gy |
| 6. Session end | The PCEF closes the Diameter sessions with the PCRF and with the OCS | Gx, Gy |
Subscriber session -> PCEF (our DPI engine)
PCEF –Gx: CC-Request–> PCRF
PCRF –Sp or Ud–> subscription profile repository (SPR) or user data repository (UDR)
PCRF –Gx: CC-Answer with PCC rules–> PCEF
PCEF –Gy–> OCS (online charging)
PCEF –Gz–> OFCS (offline charging)
PCRF <–Sy– OCS The Gx, Ud and Gy links follow the example session; Sp, Gz and Sy come from the standard. The DPI label refers to our PCEF only. In the example above, once the session is authorized and traffic flows, the PCEF applies the received rules to it. The DPI in our PCEF identifies the applications in this traffic. The PCEF limits, blocks or allows the flow and counts its volume for billing over Gy and Gz. Under the 3GPP architecture, the PCRF can also send new rules without a request from the PCEF in a Re-Auth-Request (RAR). The PCEF answers with a Re-Auth-Answer (RAA). The PCEF reports to the PCRF the events the PCRF subscribed to, and some events it always reports. It also reports accumulated usage when a threshold set by the PCRF is reached. Our PCEF connects to the operator’s network on Gi/SGi and works with the PCRF, OCS and OFCS over the standard Gx, Gy and Gz interfaces.
Where DPI fits in, and why the PCEF needs it
Our PCEF is built on our own DPI engine, which scans the traffic that passes through and identifies the applications in it. It classifies traffic by application and protocol, not only by port and IP address, which is what tariffing by service type needs. The PCEF then applies tariff policies that it receives from the PCRF.
Classification comes first: it identifies the applications and protocols in the traffic. Managing, optimizing and prioritizing the traffic follows.
DPI identifies an application mainly by signature analysis. Each application has characteristic features stored in a signature database, which must be updated as new applications appear. Our post on how PCEF and DPI work with ML and AI covers how a PCEF uses DPI.
Encrypted traffic is harder to classify: DPI cannot read the encrypted payload, so it relies on unencrypted metadata and behavioral and heuristic analysis No single method classifies all traffic, so methods are combined. The methods are described in our post Traffic Classification and Deep Packet Inspection.
Under 3GPP TS 23.203, application detection runs in the Traffic Detection Function (TDF) or in a PCEF enhanced with application detection and control (ADC). The standard does not define how applications are detected; this is left to the vendor’s implementation
How a tariff rule becomes an action on traffic in real time
The PCEF applies the charging and QoS policies it receives from the PCRF over Gx to subscriber traffic in real time: it limits speed, blocks or allows traffic, and counts the data volume per service. It passes that volume to billing over Gy and Gz. Without enforcement in a PCEF, the rules defined in the PCRF stay on paper.
Our PCEF supports tariffing at the level of application, traffic category and subscriber profile. The rule logic for rating groups is defined through the PCRF; the PCEF enforces it on traffic.
In a fair usage policy, our PCEF records package usage through Gy integration with the OCS. What happens when the quota is used up depends on whether the OCS and the PCRF are linked over Sy. With Sy, the OCS reports the policy counter status to the PCRF. The PCRF then switches the services or their parameters for the subscriber’s session according to its own logic, for example, lowers the speed.
Without Sy, the OCS sends the PCEF a final unit indication (FUI) over Gy, and the PCEF blocks the service. Depending on the configuration, our PCEF does this in one of two ways. It either stops forwarding the service’s packets, or it activates a charging rule base name (CRBN), a group of rules that implements the block. The second way is commonly used for a captive portal: the subscriber is redirected, and access is limited to the resources needed to reach the operator’s portal and top up the balance.
For zero-rating, our PCEF recognizes a messenger or a video platform by DPI classification, not by an IP address list. It rates that traffic separately, counts it in its own bucket and reports the bucket to billing. Zero-rated traffic does not reduce the main quota. For other tariff scenarios, see our post on how mobile tariffs changed and where PCEF fits.
What happens to the PCEF–PCRF link under load
A PCRF can become a bottleneck. Growth in subscribers, Internet of Things (IoT) devices and Gx sessions loads a PCRF sized for smaller volumes. Diameter over TCP also adds head-of-line (HOL) blocking, where a delay in one session slows the processing of the others.
We use the term PCRF offload for moving part of the decision logic and of the Diameter and Gx message processing to a proxy. The aim is to reduce the load on the main PCRF. PCRF offload does not replace the existing PCRF.
Our PCRF Proxy is placed in a break of the Gx interface between the PCEF and the PCRF as a transparent node. Its Diameter bridge converts TCP sessions into multistream SCTP to remove HOL blocking.
Our PCEF is built on a Control and User Plane Separation (CUPS) architecture. It lets traffic processing (the user plane) scale independently from the policy management logic (the control plane). The split is covered in our post CUPS for PCEF and PGW.
Our PCRF Proxy is deployed in four stages: an audit of the signaling load, embedding the proxy into the Gx break, configuring the offload rules, and monitoring with routing fine-tuning.
How we work with operators on PCEF
The operator fills in a form. We contact the operator, clarify the task, give access to the documentation and answer questions, then discuss the current situation: traffic volume, available equipment and the functionality the operator needs. Our engineers install the selected software and adapt it to the operator’s tasks. The contract comes after a successful test.
The software can be tested on the operator’s own equipment, on a virtual machine or over VPN.
Deployment of our PCEF goes through several stages. They include an audit of the current network and billing system and design of the integration scheme. The Gx and Gy interfaces are configured with the PCRF and the billing system. A pilot on a limited subscriber segment precedes a full-scale rollout with monitoring in Stingray NMS. Our specialists support the project from the pilot through post-launch support.
We provide technical support while the PCEF is connected to the operator’s billing over the standard interfaces. Our PCEF has experience integrating with PCRF, OCS and OFCS from various billing systems. You can read more on the pages of our PCEF, our PCRF Proxy and the PCRF Offload solution.
FAQ
What does PCEF stand for?
PCEF stands for Policy and Charging Enforcement Function in 3GPP. It is located at the gateway and covers detection of service data flows, policy enforcement and flow-based charging. The PCRF is the Policy and Charging Rules Function that manages the rules on it over Gx.
Which node makes policy decisions, the PCEF or the PCRF?
The PCRF makes the policy control decision. Under the 3GPP architecture, it decides how certain service traffic is treated in the PCEF. The PCEF enforces that decision by controlling whether a flow passes and what QoS it gets, using the rules it receives over Gx.
Which interfaces connect the PCEF to the PCRF and to billing?
Gx connects the PCEF to the PCRF. Gy connects it to the OCS, and Gz to the OFCS. Sy links the PCRF and the OCS. Our PCEF uses these standard interfaces: Gx with the PCRF, Gy with the OCS and Gz with the OFCS.
What does DPI do in a PCEF?
In our PCEF, DPI identifies the applications in the traffic passing through it. Classification is the first step, and after it the PCEF sets priorities and applies tariff policies. Our own DPI engine, on which the PCEF is built, sorts traffic by application and protocol.
What is a PCRF Proxy, and how does it work with an existing PCRF?
Our PCRF Proxy is a transparent node on the Gx link between the PCEF and the PCRF. It handles part of the requests itself, and the rest go to the existing PCRF. We call this PCRF offload, and it does not replace the existing PCRF.
How do the PCRF and the PCEF map to 5G?
In the 5G core, the 3GPP architecture maps the PCRF to the Policy Control Function (PCF). It maps the PCEF to the combination of the Session Management Function (SMF) and the User Plane Function (UPF). N7 links the SMF and the PCF.
