PCF — Policy Control Function in 5G NR

Introduction

The Policy Control Function (PCF) is the control-plane network function that holds the operator's policy and hands it to the functions that enforce it. Defined in TS 23.503, it is the 5G core's single, centralized policy decision point: it computes QoS, gating, charging and steering rules and distributes them to the SMF, the AMF and the UE.

You meet the PCF at three moments in the network lifecycle. When a UE registers, the AMF asks the PCF for access and mobility policy. When a PDU session is set up, the SMF asks it for session-management policy. And whenever an application wants special treatment — a voice call that needs a guaranteed bearer — an application function asks the PCF to authorize it. In each case the PCF decides and others act.

It matters because policy is what turns a generic pipe into a differentiated, monetizable, sliced network. QoS tiers, roaming restrictions, fair-use throttling, slice steering, on-demand voice bearers — all of it is operator intent that must be consistent, subscriber-aware and instantly reconfigurable. Centralizing that intent in the PCF is what makes it so. Understand the PCF and you understand how business rules become packet treatment.

Why the PCF is needed

The concrete purpose is to centralize policy so it can be consistent, subscriber-aware and dynamic. Without a single policy authority, every SMF and every AMF would need its own hard-coded rules, and operator intent — QoS entitlements, slice permissions, roaming and RAT restrictions, fair-use caps — could not vary per subscriber or change on the fly. The PCF makes policy a computed decision, grounded in each subscriber's data, rather than static configuration scattered across the core.

It also creates a clean chain of custody. The PCF authors intent; the SMF installs it into the UPF; the UPF and the gNB enforce it. That layering means a single policy decision — "give this video stream a guaranteed bit rate" — can be expressed once at the PCF and propagate all the way to a radio bearer, while the PCF itself stays entirely on the control plane and never forwards a byte.

What the PCF is, and why the core needs a policy brain

The Policy Control Function (PCF) is the 5G core's centralized source of policy. "Policy" here means the operator's business and technical intent expressed as rules: which QoS a flow deserves, whether a flow is allowed to pass at all, how it should be counted for charging, which radio access technology a subscriber may use, and which network slice or data network an application should ride. The PCF computes those rules and distributes them to the functions that actually enforce them. It is enforcement-by-proxy: the PCF decides, others act.

Crucially, the PCF sits entirely on the control plane. It is one of the network functions hanging off the Service-Based Architecture bus, reachable as Npcf, and it never forwards data — the UPF does the forwarding and gating, but only because the SMF programmed it with rules the PCF authored. Keep that chain of custody clear: PCF authors, SMF installs, UPF enforces.

Session Management policy: PCC rules to the SMF over N7

The most detailed and most frequently exercised job of the PCF is Session Management policy — the rules that govern an individual PDU session and its constituent service data flows. These are delivered to the SMF over the N7 reference point (realized in SBA as the SMF calling Npcf_SMPolicyControl). The unit of currency here is the PCC rule — a Policy and Charging Control rule.

A PCC rule binds together everything needed to treat one service data flow: a service data flow template (the packet filters that identify the flow, e.g. the 5-tuple of a video stream), the QoS to apply, a gate status (allow or block), and a charging key so the flow can be metered and billed. When the SMF receives a PCC rule, it derives the corresponding forwarding, QoS-enforcement, gating and usage-reporting rules and installs them into the UPF over N4 using PFCP. The PCF therefore controls the UPF's behaviour indirectly, one layer removed.

Beyond per-flow rules, the SM policy the PCF returns also carries session-level policy: the authorized Session-AMBR (aggregate bit rate across all non-GBR flows), the default 5QI/ARP, and usage-monitoring thresholds for fair-use volume caps. The PCF can also subscribe to events at the SMF — a RAT-type change, a location change — and re-evaluate policy in response, pushing updated PCC rules mid-session. That closed loop is why SM policy is dynamic, not a one-time hand-off at setup.

Access and Mobility policy: to the AMF over N15

The second policy family concerns not a session but the device's access — how it is allowed to use the network overall. This Access and Mobility (AM) policy is delivered to the AMF over the N15 reference point (in SBA, the AMF consumes Npcf_AMPolicyControl). It is requested when a UE registers and updated as the subscriber's context changes.

The headline element of AM policy is the RFSP index (RAT/Frequency Selection Priority). This is a single integer the AMF forwards to the NG-RAN, which the RAN maps to local configuration that steers idle-mode reselection and connected-mode handover toward preferred frequencies or RATs — for example, keeping a premium subscriber on mid-band NR while nudging best-effort traffic to a congested layer. The PCF also authors service area restrictions (allowed and non-allowed tracking areas, defining where the UE may or may not be served) and RAT restrictions (barring a subscriber from, say, NR or from a specific access), plus mobility-management parameters such as the UE-AMBR guidance and subscriber-category policy.

Because AM policy lives at the AMF — the UE's single anchor in the core — it is the natural place for the PCF to also trigger delivery of the third policy family, UE policy, which the AMF relays down to the device.

UE policy and the URSP: steering apps to slices and DNNs

The third family is UE policy — policy that lives inside the device and shapes how the UE itself behaves before a session is even requested. It comes in two parts: the ANDSP (Access Network Discovery and Selection Policy, governing non-3GPP/Wi-Fi selection) and, far more important in exams and in practice, the URSP — the UE Route Selection Policy.

The URSP is how the operator tells the device which application traffic should go where. It is an ordered list of rules, each with a traffic descriptor (matching by application ID, DNN, IP tuple, FQDN, or connection capabilities) and a route selection descriptor that specifies the S-NSSAI (the slice), the DNN (the data network name), the SSC mode, the PDU session type and access preference to use. When an app on the UE generates traffic, the UE evaluates its URSP rules in priority order, finds the first matching traffic descriptor, and either binds the traffic to an existing matching PDU session or requests a new one with the specified slice and DNN. That is precisely how "route the enterprise VPN over the private slice, and everything else over the default internet slice" becomes real.

Delivery is the subtle part: the PCF generates the UE policy container but has no direct interface to the UE. It hands the container to the AMF (over N15, via Npcf_UEPolicyControl), and the AMF transports it to the device inside NAS signalling using the UE Policy Delivery procedure — a dedicated NAS transport carried transparently over N1. The AMF does not interpret the policy; it is a courier. The device stores the URSP and applies it to all subsequent application traffic.

Inputs: the Application Function over N5, and subscription data from the UDR

The PCF does not invent policy in a vacuum. It draws on two major sources of input: application functions asking for treatment of specific flows, and the operator's stored policy and subscription data.

An Application Function (AF) is any entity that wants to influence how the network treats an application's traffic. It reaches the PCF over the N5 reference point (the Npcf_PolicyAuthorization service) when it is trusted and inside the operator domain, or via the NEF when it is external. The classic example is the IMS P-CSCF: when a voice-over-NR call is being set up, the P-CSCF acts as an AF and asks the PCF over N5 to authorize dedicated media QoS — a GBR QoS Flow with a voice-grade 5QI (for example 5QI 1) — for the RTP media of that specific call. The PCF translates that request into a PCC rule and pushes it to the SMF over N7, which is how a phone call gets a guaranteed bearer created on demand.

A second AF use case is background data transfer: an AF can negotiate with the PCF (via the NEF) a future time window and volume for bulk, delay-tolerant transfers — software updates to a fleet of devices, say — so the operator can offer a cheaper off-peak rate. The PCF computes candidate transfer policies, stores the agreed one, and applies it when the relevant sessions form.

The PCF's other input is the UDR — the Unified Data Repository — reached over Nudr. The UDR holds the policy subscription data: per-subscriber policy profiles saying which QoS tier this SIM is entitled to, its usage allowances, and its slice and RAT permissions. The PCF is deliberately stateless like the UDM — its durable data lives in the UDR, so instances can be scaled or replaced freely. On each policy request it fetches the relevant data from the UDR, combines it with operator configuration and any live AF input, evaluates its logic, and returns the rules.

The PCF's interfaces and service operations

Because the PCF is a hub, its interface list is the fastest way to memorize its role: each interface is one relationship. Note the split between the point-to-point reference-point names (N5, N7, N15) that appear in call flows and the service-based names (Npcf, Nudr) that appear in SBA diagrams — the same conversations, two views, exactly as elsewhere in the 5GC.

Service operations, precisely. On the SBA bus the PCF produces four services, and knowing the exact operation names is what separates a memorized diagram from real understanding. Npcf_SMPolicyControl offers Create (the SMF requests SM policy at session setup), UpdateNotify (the PCF pushes revised PCC rules mid-session) and Delete. Npcf_AMPolicyControl offers Create/Update/Delete for the AMF's access-and-mobility policy association. Npcf_UEPolicyControl carries the URSP/ANDSP container to the AMF for relay. And Npcf_PolicyAuthorization offers Create/Update/Subscribe/Notify for an AF to authorize application flows. In turn the PCF consumes Nudr_DM (Query/Subscribe) from the UDR and registers with the NRF via Nnrf_NFManagement so other NFs can discover it.

The 5G evolution of LTE's PCRF

If you know 4G policy, the PCF is the direct descendant of the LTE PCRF (Policy and Charging Rules Function) — but redistributed and re-transported for the cloud-native core. The conceptual continuity is strong: the PCRF also produced PCC rules, also authorized dedicated bearers on request from an AF (the P-CSCF, over the Rx interface), and also read subscriber policy from a repository (the SPR/UDR). What changed is how it connects and what it additionally owns.

The two genuinely new responsibilities are worth stressing. First, the PCF gained explicit access and mobility policy toward the AMF (N15) — the PCRF had no clean equivalent because LTE's MME was not a policy consumer in the same way. Second, the standalone LTE ANDSF for network selection was absorbed into the PCF's UE policy, and extended with the URSP to support slice- and DNN-aware application steering — a capability that only makes sense in a sliced network. So the PCF is the PCRF plus mobility policy plus slice-aware device steering, all re-expressed as SBA services.

Summary

The PCF is the policy decision point of the 5G core. It authors three families of policy and hands each to a different consumer: Session Management policy as PCC rules to the SMF over N7 (Npcf_SMPolicyControl); Access and Mobility policy — the RFSP index and service-area/RAT restrictions — to the AMF over N15; and UE policy, chiefly the URSP, generated by the PCF but relayed to the device by the AMF inside NAS. It grounds every decision in two inputs: live requests from an AF over N5 (the P-CSCF asking for a VoNR bearer being the canonical case) and policy subscription data read from the UDR over Nudr, which is where its durable state lives so the PCF itself can stay stateless. It never touches a packet — PCF decides, SMF installs, UPF enforces — and it is the cloud-native evolution of LTE's PCRF, extended with mobility policy and slice-aware device steering.

Quick Q&A

These questions separate knowing the acronym from understanding what the PCF actually decides and who obeys it.