Control and User Plane Separation (CUPS)

The requirement of CUPS Architecture:

Cellular network, today, is witnessing an increased variation in resource demands across the control and user planes, while earlier requirements were subject to known and calculated elements of control and user plane.

 

Some devices require high control-plane resources (signaling), while other devices may require very little signaling resources but significant user plane and data resources. With the ever-increasing cellular network requirements, there is an apparent need to further bifurcate and develop the control-plane and user-plane elements individually.

• Large Volume Data Support
• Rich Communication Services
• Customer Experience and
• Low Latency Reduce Latency by selecting User plane close to RAN.
• Data Traffic increase without control plane change.
• Locating and Scaling the CP and UP resources of the EPC nodes independently

 

Control and User Plane Separation (CUPS Architecture:

 

CUPS architecture for EPC was first introduced in 3GPP release 14. All earlier EPC specification follows NON-CUPS architecture. CUPS introduce 3 new interfaces, Sxa, Sxb and Sxc between the CP and UP functions of the SGW, PGW, and TDF respectively.

A Control Plane function can interact with multiple User Plane functions, and a User Plane function can be shared by multiple Control Plane functions.

 

A UE is served by a single SGW-Control Plane but multiple SGW-User Planes can be selected for different PDN connections. A user plane data packet may roam around multiple User Plane functions.

 

The Control Plane function controls the processing of the packets in the User Plane function by provisioning a set of rules in Sx sessions.

 

Charging and Usage Monitoring are supported by directing the User Plane function to quantify and report traffic usage, using Usage Reporting Rules. There is hardly any change expected in the charging and policy control functions.

 

The Control Plane or User Plane function is responsible for GTPU F-TEID allocation.

 

Traditional nodes SGW, PGW, and TDF can be replaced by a split node without affecting connected legacy node.

 

 

The function of CP & UP:

 

User Plane Selection:

Parameters for Selection of PGW-U:

• Relative capacity among PGW-Us supporting the APN.
• Capabilities of the UP function and the Functionality requested by UE.

 

Parameters for Selection of SGW-U:

• SGW-U location and UE location information from MME.
• SGW-U’s Relative capacity.
• Capabilities of the UP function and the Functionality requested by UE.

SGW-U/PGW-U Selection Criteria:

CUPS is bringing some interesting Selection features for both SGW-U and PGW-U selection with a flexibility that was missed in Pre-R14 EPC and I believe that the richness of these features will be one of the main differentiators between Vendors' solutions.

SGW-U is selected by SGW-C following the below scenarios.

• Close to UE; Based on SGW-U Location and the UE Location info sent in the Create Session Request message from MME to SGW.
• SGW-U Dynamic Load which can be reported by SGW-U to SGW-C.
• SGW-U Relative Static Capacity.
• Based on the Functionalities, Features, & capabilities that UE requires/declares together with the info that MME enriches in the Create Session Request to SGW-C. In this scenario, SGW-C can build a logic on the info communicated from UE/MME to SGW.

 An example of this parameters are:

·       CIoT capabilities - Select SGW-U for NB-IoT Terminals.

·       UE Usage Type - Select SGW-U for certain Usage Types (e.g. Smart Meter)

·       APN (for selection of combined SGW/PGW) - with CUPS, SGW-U can be selected for a certain APN/PDN.

On the other, PGW-U is selected by PGW-C following the below options.

• PGW-U dynamic load, either on node level or APN level.
• PGW-U relative static capacity (among PGW-Us supporting the same APN).
• The PGW-U location configured in the PGW-C and the UE location information provided by the MME.
• Based on the Functionalities, Features, & capabilities that UE requires/declares together with the info that MME enriches in the Create Session Request to SGW-C/ PGW-C (e.g. APN, mapped UE Usage Type, UE location information) or from the PCRF (e.g. need to perform DPI) with the capabilities of the UP function so as to fulfill the service for the UE, e.g. if L7 based traffic detection is needed then a certain PGW-U supporting corresponding functionality needs to be selected.

Sx Interface:

Sx Association:

Sx Association shall be set up between the CP function and the UP function prior to establishing Sx sessions.

Only one Sx association shall be setup between a given pair of CP and UP functions.

Sx association initiation can be from CP/UP function. 

Parameters of Sx Session:

The parameters over Sx provided from CP function to UP function are grouped into session related

parameters and four different rules, one "detection" rule and three different "enforcement" rules: 

Packet Detection Rule (PDR) :

    Describe information describing what packets should receive a certain treatment. 

Forwarding Action Rule (FAR)

    Contains information on whether forwarding, dropping or buffering is to be applied to a packet.

Usage Reporting Rule (URR)

    Contains information that defines a certain measurement and how it shall be reported. 

Qos Enforcement Rule (QER)

    Contains information related to QoS enforcement of traffic.

Packet Forwarding Control Protocol (PFCP): 

It is a 3GPP protocol used on the Sx/N4 interface between the control plane and the user plane function, specified in TS 29.244. PFCP and the associated interfaces seek to formalize the interactions between different types of functional elements used in the Mobile Core Networks as deployed by most operators providing 4G, as well as 5G, services to mobile subscribers. 

These 2 types of components are: 

·       The Control Plane (CP) functional elements, handling mostly signaling procedures (e.g. network attachment procedures, management of User-data Plane paths and even delivery of some light-weight services as SMS)

• The User-data Plane (UP) functional elements, handling mostly packet forwarding, based on rules set by the CP elements (e.g. packet forwarding for IPv4, IPv6 - or possibly even Ethernet with future 5G deployments - between the various supported wireless RANs and the PDN representing the Internet or an enterprise network).

Functionality of PFCP:

The Control-Plane functional element (e.g. PGW-C, SMF) controls the packet processing and forwarding in the User-Plane functional elements (e.g. PGW-U, UPF), by establishing, modifying or deleting PFCP Sessions.

User plane packets shall be forwarded between the CP and UP functions by encapsulating the user plane packets using GTP-U encapsulation.
For forwarding data from the UP function to the CP function, the CP function shall provision PDR(s) per PFCP session context, with the PDI identifying the user plane traffic to forward to the CP function and with a FAR set with the Destination Interface "CP function side" and set to perform GTP-U encapsulation and to forward the packets to a GTP-u F-TEID uniquely assigned in the CP function per PFCP session and PDR.

The CP function shall then identify the PDN connection and the bearer to which the forwarded data belongs by the F-TEID in the header of the encapsulating GTP-U packet. For forwarding data from the CP function to the UP function, the CP function shall provision one or more PDR(s) per PFCP session context, with the PDI set with the Source Interface "CP function side" and identifying the GTP-u F-TEID uniquely assigned in the UP function per PDR, and with a FAR set to perform GTP-U decapsulation and to forward the packets to the intended destination. URRs and QERs may also be configured.

Per session multiple PDRs, FARs, QERs, URR and/or BARs are sent.

Here are the main concepts used, organized in their logical association model:

PDRs - Packet Detection Rules - contain information for matching data packets to certain processing rules. Both outer encapsulation and inner user-plane headers can be matched. The following rules can be applied on positive matching:

FARs - Forwarding Action Rules - whether and how the packets matching PDRs should be dropped, forwarded, buffered or duplicated, including a trigger for first packet notification; it includes packet encapsulation or header enrichment rules. In case of buffering, the following rules can be applied:

BARs - Buffering Action Rules - how much data to buffer and how to notify the Control-Plane.

QERs - QoS Enforcement Rules - rules for providing Gating and QoS Control, flow and service level marking.

URRs - Usage Reporting Rules - contain rules for counting and reporting traffic handled by the User-Plane function, generating reports to enable charging functionality in the Control-Plane functions.