July 03, 2017

By Peter Schmitt (Huawei), Bruno Landais (Nokia), Frank Yong Yang (Ericsson)

At the recent CT#76 meeting (June 2017), 3GPP has completed the Release 14 specification of CUPS – set to be a key core network feature for many operators.

CUPS stands for Control and User Plane Separation of EPC nodes and provides the architecture enhancements for the separation of functionality in the Evolved Packet Core’s SGW, PGW and TDF. This enables flexible network deployment and operation, by distributed or centralized deployment and the independent scaling between control plane and user plane functions - while not affecting the functionality of the existing nodes subject to this split.

Triggers for the work

Many mobile operator’s user data traffic has been doubling on an annual basis in recent years. The reasons for this growth in traffic are the rapidly increasing use of smart devices, the proliferation of video and other applications that they support and the use of USB modem dongles & personal hotspots using 3GPP networks.

As the penetration of these terminals increases worldwide and the interest in content-rich multi-media services (e.g. OTT video streaming services, Person to person video, content sharing) rises, this trend of rapidly increasing data traffic is expected to continue and accelerate.

At the same time, there is a strong consumer demand for user experience improvements, with lower latency being one of the critical KPIs to be met on the way.

CUPS allows for:

• Reducing Latency on application service, e.g. by selecting User plane nodes which are closer to the RAN or more appropriate for the intended UE usage type without increasing the number of control plane nodes.
• Supporting Increase of Data Traffic, by enabling to add user plane nodes without changing the number of SGW-C, PGW-C and TDF-C in the network.
• Locating and Scaling the CP and UP resources of the EPC nodes independently.
• Independent evolution of the CP and UP functions.
• Enabling Software Defined Networking to deliver user plane data more efficiently.

Architecture principles (Working Group SA2)

CUPS introduces 3 new interfaces, Sxa, Sxb and Sxc between the CP and UP functions of the SGW, PGW and TDF respectively. 

The following high-level principles were adopted:

• The CP function terminates the Control Plane protocols: GTP-C, Diameter (Gx, Gy, Gz).
• A CP function can interface multiple UP functions, and a UP function can be shared by multiple CP functions.
• An UE is served by a single SGW-CP but multiple SGW-UPs can be selected for different PDN connections. A user plane data packet may traverse multiple UP functions.
• The CP function controls the processing of the packets in the UP function by provisioning a set of rules in Sx sessions, i.e. Packet Detection Rules for packets inspection, Forwarding Action Rules for packets handling (e.g. forward, duplicate, buffer, drop), Qos Enforcement Rules to enforce QoS policing on the packets, Usage Reporting Rules for measuring the traffic usage.
• All the 3GPP features impacting the UP function (PCC, Charging, Lawful Interception, etc) are supported, while the UP function is designed as much as possible 3GPP agnostic. For example, the UPF is not aware of bearer concept.
• Charging and Usage Monitoring are supported by instructing the UP function to measure and report traffic usage, using Usage Reporting Rule(s). No impact is expected to OFCS, OCS and the PCRF.
• The CP or UP function is responsible for GTP-u F-TEID allocation.
• A legacy SGW, PGW and TDF can be replaced by a split node without effecting connected legacy nodes.

Protocol Design (Working Group CT4)

CT4 assessed candidate protocols such as OpenFlow, FoRCES, Diameter, IETF DMM FPC and 3GPP native protocol. The criteria identified for the selection process included;

• ease of implementation on simple forwarding devices,
• no transport Head-Of-Line blocking,
• low latency,
• capabilities to support all the existing 3GPP features
• ease to extend and maintain the protocols to support 3GPP features,
• backward compatibility across releases

Based on these criteria, CT4 decided to define a 3GPP native protocol with TLV encoded messages over UDP/IP, called Packet Forwarding Control Plane (PFCP) protocol, for the Sxa, Sxb and Sxc interfaces.

Details on the protocol on Sx

PFCP has the following main properties:

• One Sx Association shall be setup between a CP function and a UP function before being able to establish Sx sessions on the UP function. The Sx association may be established by the CP function (mandatory support) or by the UP function (optional support).
• An Sx session is established in the UP function to provision rules instructing the UP function how to process a certain traffic. An Sx Session may correspond to an individual PDN connection, TDF session or this can be a standalone session not tied to any PDN connection/TDF session, e.g. for forwarding DHCP/RADIUS/DIAMETER signalling between the PGW-C and PDN (SGi).
• Sx Node related procedures:
  - Sx Association Setup / Update / Release procedures;
  - Heartbeat procedure to check that a PFCP peer is alive;
  - Load Control and Overload Control procedures to balance the load across UP functions and reduce signalling towards UP function in overload;
  - Sx PFD Management procedure to provision PFDs (Packet Flow Descriptions) for one or more Application Identifiers in the UP function (SDCI).
• Sx Session related procedures:
  - Sx Session Establishment / Modification / Deletion procedures;
  - Sx Session Report procedure to report traffic usage or specific events (e.g. arrival of a DL data packet, start of an application).
• Data Forwarding between the CP and UP functions is supported by GTP-U encapsulation, e.g. for forwarding RS/RA/DHCP signalling between UE and PGW-C, or forwarding user plane data to the SGW-C when buffering of DL packets is done in the CP function. 
• PFCP supports reliable delivery of messages.
• New DNS procedures are defined for UP function selection. The CP function selects a UP function based on DNS or local configuration, the capabilities of the UP function and the overload control information provided by the UP function.

Restoration procedures

CT4 has analysed the possible error scenarios with split EPC nodes and defined corresponding restoration solutions in TS 23.007.

Further Reading:

Stage 2 – Functional Architecture and Procedures

• TS 23.214 Architecture enhancements for control and user plane separation of EPC nodes.

Stage 3 – Protocols

• TS 29.244 Interface between the Control Plane and the User Plane of EPC Nodes.
• TS 23.007 Restoration procedures
• TS 29.303 DNS procedures for UP function selection  

Contact for this article: Kevin FLYNN, Marketing and Communications Officer, 3GPP