# Control and User Plane Separation

## Summary


In traditional 4G LTE networks, control plane and user plane functionalities were combined into the same network elements. The Serving Gateway (SGW), the PDN Gateway (PGW) and the Traffic Detection Function (TDF) are examples. In Release 14, 3GPP published a modified architecture is which the two planes were separated. Called **Control and User Plane Separation (CUPS)**, SGW got split into SGW-C and SGW-U. Likewise, we obtained PGW-C, PGW-U, TDF-C and TDF-U. CUPS was subsequently adopted in the design of the 5G System, both in the 5G Core and in the NG-RAN.

CUPS leads to better scalability and performance. For the more demanding use cases of 5G, CUPS may play a significant role. Control and user plane specifications can now evolve independently. However, implementing CUPS has its challenges.

## Discussion

### Could you give an overview of CUPS?

The figure shows an example of CUPS as applied in 4G/LTE EPC (Evolved Packet Core). SGW and PGW are split into their respective control plane and user plane parts. These parts communicate via the PFCP protocol. Each plane has a well-defined functionality. For example, packet forwarding and transport level packet marking are exclusively user plane features. 

When a PDU session is established, the CP function gets involved. CP associates with a UP function and configures the latter to process user plane traffic. Subsequently, when user plane traffic flows, UP function is actively involved. UP function occasionally updates CP function as necessary. UP bandwidth per session is in the order of Gbps whereas CP bandwidth requirement is perhaps only a few Mbps. UP latency for URLLC is 1ms whereas for CP its 10ms. With these differing performance requirements, it makes sense to separate CP and UP functions.

In 5G CUPS, SMF takes care of the signalling while UPF is the user plane counterpart. SMF and UPF communicate using PFCP over the N4 interface.  


### Is CUPS applicable for the RAN?

In 5G's Next-Generation Radio Access Network (NG-RAN), gNB is no longer a monolith. It's disaggregated into Central Unit (CU), Distributed Unit (DU) and Radio Unit (RU). Furthermore, the CU is split into CU-CP and CU-UP for the control plane and user plane respectively.  A gNB consists of one CU-CP and one or more CU-UP/DU/RU each.  

Due to CUPS applied to CU, we have these new interfaces: E1 interface between CU-CP and CU-UP, F1-c interface between CU-CP and DU, and F1-u interface between CU-UP and DU. Moreover, old X2, Xn and NG interfaces are disaggregated into X2-C/X2-U, Xn-C/Xn-U and NG-C/NG-U respectively. The E1 interface is purely a control plane interface. 

CU/DU split can be done in many ways. For standardization work, 3GPP adopted what's called *Option 2* in which RRC/PDCP-C are in CU-CP, SDAP/PDCP-U are in CU-UP, and RLC/MAC/PHY are in DU.  

In 4G/LTE, ng-eNB is disaggregated into ng-eNB-CU and ng-eNB-DU. Between these two, W1-C and W1-U interfaces are defined. However, unlike in 5G, ng-eNB-CU is not split into separate control and user plane entities. 


### What are the key benefits of CUPS?

Due to CUPS, CP and UP functions can be scaled independently. During peak periods, more UP nodes can be added without increasing the CP nodes. UP functions can be located closer to UEs that they serve, thus reducing latency. A UE may be served by a single CP function and many UP functions, one for each PDU session. 

For operators, CUPS can result in lower operating cost. By processing data at the edge, backhaul costs can be reduced. Each UP function can be specialized for the application use case it serves. CUPS allows operators deliver new services and handle traffic growth without sacrificing customer experience. 

CP and UP functions can evolve independently. For example, CP nodes may be upgraded without upgrading UP nodes, provided the evolution is backward compatible. 

Likewise, CUPS in NG-RAN gives operators flexibility, and optimize for cost and/or performance. 


### What are the possible deployments due to CUPS?

The figure shows three possible deployments. For low latencies, SGW-U/PGW-U can be deployed closer to cell sites. In urban areas with a large subscriber base, high performance and high capacity SGW-U/PGW-U may be deployed. If we need resilience to disasters and congestion, SGW-U/PGW-U may be deployed with redundancy. In other words, if one SGW-U/PGW-U goes down, another in hot standby mode will take over. For that matter, we can have similar redundancy in the control plane as well. 

In the RAN, we can co-locate CU-CP and CU-UP in the cloud. An alternative is to co-locate CU-UP and DU at the edge while CU-CP remains centralized in the cloud. This can reduce the midhaul latency but at the expense of control plane signalling overhead. 


### How does a CP function select a UP function?

In traditional 4G EPC, MME selects SGW and PGW using DNS. This is based on UE's location and Access Point Name (APN). With CUPS, MME selects SGW-C/PGW-C and the latter select SGW-U/PGW-U. SGW-C/PGW-C will use UE's location, APN, UP performance and load status. Thus, with CUPS, SGW-C/PGW-C uses dynamic information in the selection of SGW-U/PGW-U. 

Suppose a UE has an IMS voice session and a data session. Before CUPS, an EPC wishing to avoid the S5 hop would select the same node for SGW and PGW of both sessions. With CUPS, a combined SGW-C/PGW-C plus two specialized combined SGW-U/PGW-U nodes can be selected. 

In some scenarios, selecting the right SGW-U/PGW-U can be a problem. For example, SGW-C and PGW-C may select UP functions that are not co-located. This results in two hops in the data path. The figure shows a UE in 5G-to-4G handover. SGW-C doesn't know which UP function is being currently used. 


### What's the migration path from traditional deployment to CUPS-based deployment?

A traditional 4G transport network may not get the full benefits of CUPS. Migrating EPC towards CUPS enables smooth evolution towards 5G Core. Cisco has proposed a three-stage migration: inline CUPS where CP and UP functions are logically separated; co-located CUPS where CP and UP functions are separate nodes but co-located in the same data center; remote CUPS where the functions are in different data centers. 

## Milestones

Jul  
2015

At the SA WG2 Meeting #S2-110, a study item titled *Feasibility Study on Control and User Plane Separation of EPC nodes* is proposed. This is subsequently approved in September at the 3GPP TSG SA Meeting #69. The document notes that such a separation shall not affect the functionality of the nodes being split. It shall not affect UE or RAN. New reference points shall be introduced only among the split parts of SGW, PGW and TDF. 

Jun  
2016

3GPP publishes **TR 23.714** titled *Study on control and user plane separation of EPC nodes* as part of Release 14. The document identifies the different issues and possible solutions. The selected solution is a functional split of user plane and control plane functions, including the case of combined SGW/PGW. User plane functions shall be selected by the respective control plane functions. 

Sep  
2016

3GPP publishes **TS 23.214** that specifies the architectural changes to support CUPS in LTE EPC. This is for Release 14. This evolves for other releases: V15.0.0 (Sep 2017), V16.0.0 (Jun 2019) and V17.0.0 (Jun 2021). 

Dec  
2017

3GPP approves the first specifications for 5G, called "early drop" of Release 15. This release specifies CUPS in 5G Core in **TS 29.244** (Jun 2017) and CUPS in NG-RAN in **TS 38.401** (Dec 2017). Thus, unlike in 4G, 5G has adopted CUPS from the outset.

Jan  
2020

The O-RAN Alliance publishes documents detailing the O-RAN architecture. These documents show CUPS applied to the RAN. In particular, the Open Distributed Unit (O-DU) and the Open Central Unit (O-CU) are split. E1 interface connects O-CU-CP and O-CU-UP. F1-c and F1-u interfaces connect O-CU-CP and O-CU-UP to the O-DU. These interfaces are in fact specified by 3GPP and adopted by O-RAN.