Moving 4G EPC to the Cloud
CUPS — Control and User Plane Separation
Facilitating 4G EPC transition to a centralized cloud
Vendors are moving the 4G EPC to the cloud. This lowers the network deployment and maintenance cost. Moving to the cloud, however, increases the user plane latency. All user plane data must be carried all the way to the cloud provider before it hits the Internet (Refer to the following figure).
Separating the control and data plane functions of PGW and SGW into separate entities gives the service providers more flexibility in dealing with user plane latency. The following figure shows that the SGW/PGW control functions have been moved to the cloud. The data plane has been separated out giving the service provider flexibility in routing data plane traffic.
- A distributed SGW-PGW user plane function may be placed closed in an edge cloud that is located very close to the radio network. Latency sensitive traffic can take this route.
- Regular traffic can still be routed via the SGW-PGW user plane functions located in the centralized cloud.
CUPS — Control and User Plane Separation
The EPC architecture did separate out the primary control plane functions in to the MME. However, SGW and PGW still perform many control plane functions during session establishment. 3GPP Release 14 carves out the control plane functions from the SGW and PGW into PGW-C and SGW-C as shown in the figure below.
Separating the control plane and user plane functions requires a new standardized interface for session management (see figure below).
Control plane and data plane scaling
Since the control plane and data plane have been separated, the SGW-C/PGW-C and SGW-U/PGW-U can scale differently.
- Increase in long duration data sessions (Netflix?) might require addition of SGW-U and PGW-U as the bandwidth requirements have increased. The signaling is not significantly impacted.
- Increase in short duration frequent chat sessions might require addition of SGW-C and PGW-C to handle the signaling load.
Optimizing the data plane
Each SGW-C/PGW-C manages multiple SGW-U/PGW-U. The control plane components can select the corresponding data plane based on:
- The location of the UE. The SGW-U/PGW-U will offer the lowest latency. Low latency data plane selection is extremely important when the complete control plane of the EPC has been moved into a cloud platform.
- Load on the SGW-U/PGW-U. The control plane can load balance the traffic between the data plane components it manages.
An additional advantage of this split is that SGW-C and PGW-C may decide to use a separate SGW-U/PGW-U for different bearers of the same UE. This permits local breakout for delay sensitive traffic.
Separating the control plane and the data plane requires a standardized interface so that SGW-C/PGW-C from one vendor can talk to SGW-U/PGW-U from another vendor. The 3GPP has defined a Packet Forwarding Control Protocol (PFCP) as the CP-UP interface standard (refer to the figure below). The interface defines the Sx reference point.
The Sx reference point supports:
- Managing associations between control plane and data plane.
- PFCP heartbeat.
- Packet flow descriptor management.
- Session establishment, modification and deletion.
- Session reports containing traffic usage reports.
- Encapsulating RA, RS and DHCP signaling between the UE and the PGW-C.
The following article describes CUPS in detail and refers to the 3GPP specifications defining the CUPS architecture.
Core Network Evolution — How CUPS changes the Call Flow?
Control and User Plane Separation of EPC nodes (CUPS) is one of the main Work Items of 3GPP Release 14. An…
3GPP article describing CUPS.
Control and User Plane Separation of EPC nodes (CUPS)
Many mobile operator's user data traffic has been doubling on an annual basis in recent years. The reasons for this…
This Nokia demo shows the latency reduction that can be achieved by splitting the control and user planes.
The following video from the 3g4g blog explains the control and user plane separation in detail.
If you found this post useful, please let us know by clicking the 👏 below.
This blog was brought to you by VisualEther. VisualEther helps you generate call flow diagrams from Wireshark output.