Why Separate Control and User Planes
In the 4G EPC, the Serving Gateway (SGW) and PDN Gateway (PGW) handled both control-plane signaling (GTPv2-C for session management, bearer modification) and user-plane data forwarding (GTP-U for tunneled traffic) within the same node. This coupling meant that scaling data throughput required scaling the entire gateway, including its control-plane processing -- an expensive and inflexible approach.
3GPP introduced CUPS (Control and User Plane Separation) in Release 14 (TS 23.214) for EPC, splitting the SGW into SGW-C and SGW-U, and the PGW into PGW-C and PGW-U, connected by the Sx interface. The 5G Core in Release 15 (TS 23.501) was designed with CUPS as a foundational principle from day one: the SMF handles session control, and the UPF handles user-plane forwarding, connected by the N4 interface using PFCP.
This separation is not merely architectural elegance -- it enables operators to deploy UPFs at the network edge for low-latency services while keeping SMFs centralized, to scale user-plane capacity independently of signaling load, and to select different UPFs for different traffic types.
Control Plane vs User Plane Function Mapping
| Function | Control Plane | User Plane |
|---|---|---|
| PDU session establishment | SMF processes NAS-SM, interacts with PCF/UDM | UPF receives PFCP rules, allocates TEIDs |
| QoS policy decision | PCF generates PCC rules, SMF maps to QoS flows | UPF enforces MBR/GBR via QER |
| Packet detection | SMF creates PDR rules in PFCP | UPF executes PDR matching on every packet |
| Forwarding decision | SMF creates FAR rules | UPF forwards, drops, or buffers per FAR |
| Charging | CHF/SMF define charging triggers via URR | UPF measures volume/time, reports via PFCP |
| Lawful intercept | SMF signals LI activation | UPF duplicates packets to LI target |
| Traffic steering | SMF computes traffic steering rules | UPF applies steering via FAR destinations |
| Buffering (idle UE) | SMF signals buffer action in FAR | UPF buffers DL packets until paging completes |
| IP address allocation | SMF allocates or delegates to UPF | UPF may allocate from local pool |
| Usage monitoring | SMF defines thresholds in URR | UPF monitors and triggers reports |
Benefits of CUPS Architecture
| Benefit | Description | Impact |
|---|---|---|
| Independent scaling | UPF scales by throughput; SMF scales by session count | 40--60% cost reduction in user-plane scaling (Ericsson estimate) |
| Edge deployment | UPF placed at cell site or edge DC; SMF stays centralized | Sub-5 ms latency for edge applications |
| Flexible topology | Multiple UPFs per SMF; UPF chaining (I-UPF + PSA) | Traffic steering without control-plane changes |
| Vendor independence | Different vendors for SMF and UPF | Multi-vendor core deployments via standard PFCP |
| Technology evolution | Upgrade UPF hardware (DPDK, SmartNIC) without SMF changes | Hardware acceleration without software refactoring |
| Traffic offload | Local breakout at UPF without traversing central core | Reduced backhaul utilization by 30--50% (Deutsche Telekom data) |
| Resilience | UPF failure affects only anchored sessions; SMF failure affects only signaling | Blast radius containment |
| Charging flexibility | UPF reports usage; SMF/CHF decide charging actions | Online/offline charging without user-plane overhead |
N4/PFCP Message Flow Deep Dive
The N4 interface between SMF and UPF uses PFCP (Packet Forwarding Control Protocol, TS 29.244). Below is the complete message flow for a PDU session lifecycle.
Session Establishment
1. PFCP Session Establishment Request (SMF -> UPF):Key information elements:
- Node ID: SMF identifier
- F-SEID: Fully qualified Session Endpoint Identifier (SMF-side SEID)
- Create PDR #1 (Uplink):
- PDI: Source Interface = Access, Local F-TEID (UPF allocates), Network Instance = "internet"
- Outer Header Removal: GTP-U/UDP/IPv4
- FAR ID: points to FAR #1
- QER ID: points to QER #1
- Create PDR #2 (Downlink):
- PDI: Source Interface = Core, UE IP Address = 10.0.1.50
- FAR ID: points to FAR #2
- QER ID: points to QER #1
- Create FAR #1 (Uplink forward):
- Apply Action: Forward
- Forwarding Parameters: Destination Interface = Core
- Create FAR #2 (Downlink forward -- initially buffer):
- Apply Action: Buffer + Notify
- (gNB TEID not yet known)
- Create QER #1:
- Gate Status: Open
- MBR (UL): 100 Mbps, MBR (DL): 300 Mbps
- QFI: 1
- Create URR #1:
- Measurement Method: Volume
- Reporting Triggers: Volume Threshold (1 GB)
2. PFCP Session Establishment Response (UPF -> SMF):- Cause: Request Accepted
- Created PDR #1: Local F-TEID = 0x00A1B2C3, UPF N3 IP = 10.200.1.1
- UP F-SEID: UPF-side Session Endpoint Identifier
- Update FAR #2: Apply Action = Forward, Outer Header Creation: GTP-U, TEID = 0x80000001, Peer Address = gNB N3 IP
Worked Example -- PFCP Rule Calculation for Multi-QoS Session
A UE establishes a PDU session with two QoS flows: a default flow (5QI=9, best effort internet) and a voice flow (5QI=1, GBR 150 kbps UL/DL).
PFCP rules required:- PDR #1: Uplink access, match all traffic from UE -> FAR #1, QER #1 (default)
- PDR #2: Uplink access, match QFI=1 (voice) -> FAR #1, QER #2 (voice)
- PDR #3: Downlink core, match UE IP, QFI=9 -> FAR #2, QER #1
- PDR #4: Downlink core, match UE IP, QFI=1 -> FAR #2, QER #2
- FAR #1: Forward to Core (N6)
- FAR #2: Forward to Access (N3), GTP-U encapsulation
- QER #1: MBR UL=50 Mbps, MBR DL=150 Mbps, non-GBR
- QER #2: GBR UL=150 kbps, GBR DL=150 kbps, MBR UL=300 kbps, MBR DL=300 kbps
- URR #1: Volume measurement for default flow (charging)
- URR #2: Time measurement for voice flow (charging)
For an operator with 1 million active PDU sessions averaging 1.5 QoS flows each, the UPF must maintain approximately 6 million PDRs in its forwarding table -- a significant memory and lookup performance requirement.
UPF Selection Criteria
The SMF selects UPFs based on multiple criteria defined in TS 23.501 Section 6.3.3.2. The selection algorithm considers:
| Criterion | Description | Weight (typical) |
|---|---|---|
| DNN support | UPF must serve the requested DNN | Mandatory filter |
| S-NSSAI support | UPF must belong to the requested slice | Mandatory filter |
| UE location (TAI) | Closest UPF to the serving gNB | High |
| UPF load | Current CPU/memory/session utilization reported via NRF | High |
| Supported features | DPI, header enrichment, LI, IPv6 prefix delegation | Medium |
| Data network access | UPF must have N6 connectivity to the target DN | Mandatory |
| Edge computing affinity | For LADN or MEC, select UPF at the edge site | High (if applicable) |
| Inter-UPF topology | Prefer PSA UPF with minimal I-UPF hops | Medium |
| Priority and capacity | NRF profile priority and capacity values | Medium |
Worked Example -- Edge Computing with Distributed UPF
Scenario: A manufacturing plant deploys a private 5G network with an enterprise slice (SST=1, SD=0x000100) and a local DNN "factory-floor". The operator places an edge UPF at the factory site to minimize latency for industrial IoT control loops. Architecture:- Central DC: AMF, SMF, NRF, PCF, UDM (all control-plane NFs)
- Factory edge site: UPF-Edge (local breakout for "factory-floor" DNN)
- Regional DC: UPF-Central (anchor for internet DNN)
- UE requests PDU session: DNN = "factory-floor", S-NSSAI = {SST=1, SD=0x000100}
- SMF queries NRF for UPFs matching DNN + S-NSSAI + UE location (TAI of factory gNB)
- NRF returns UPF-Edge (priority=5, load=20%) and UPF-Central (priority=15, load=40%)
- SMF selects UPF-Edge based on proximity and priority
- SMF establishes PFCP session with UPF-Edge
- Traffic path: UE -> gNB -> UPF-Edge -> Factory application server (all on-premises)
- Round-trip latency: 2 ms (radio) + 0.5 ms (N3 transport) + 0.5 ms (UPF processing) = 3 ms
- Traffic path: UE -> gNB -> UPF-Central (regional DC, 80 km away) -> back to factory server
- Round-trip latency: 2 ms (radio) + 8 ms (N3 backhaul) + 1 ms (UPF) + 8 ms (N6 return) = 19 ms
This 84% latency reduction demonstrates why CUPS-enabled edge UPF deployment is critical for industrial 5G.
PDU Session for internet access on same device:The same UE can establish a second PDU session with DNN = "internet" anchored at UPF-Central. The SMF manages both sessions independently, routing factory traffic locally and internet traffic centrally. This is the ULCL (Uplink Classifier) or branching point architecture defined in TS 23.501 Section 5.6.4.
CUPS Evolution from 4G to 5G
| Aspect | EPC CUPS (Release 14) | 5GC Native CUPS (Release 15+) |
|---|---|---|
| Specification | TS 23.214 | TS 23.501 |
| Interface | Sx (Sxa, Sxb, Sxc) | N4 |
| Protocol | PFCP (first defined here) | PFCP (enhanced) |
| CP entities | SGW-C, PGW-C | SMF |
| UP entities | SGW-U, PGW-U | UPF |
| Adoption | Optional retrofit | Mandatory by design |
| Edge support | Limited | Native ULCL, I-UPF, MEC integration |
| Discovery | Static configuration | Dynamic NRF-based UPF discovery |
Summary
CUPS is the architectural foundation that makes 5G Core flexible, scalable, and edge-ready. By separating the SMF (control plane) from the UPF (user plane) and connecting them through the well-defined N4/PFCP interface, operators can independently scale data throughput, distribute UPFs to the edge for low-latency services, and evolve user-plane hardware without touching session management logic.
Key Takeaway: CUPS in 5G is not optional -- it is the fundamental design principle. The SMF decides what the UPF should do (via PFCP rules), and the UPF executes at line rate. This separation enables the distributed, edge-native architectures that make industrial IoT, autonomous vehicles, and real-time applications viable on 5G.