GA

Friday, 22 December 2017

CUPS – Set to be a key core network feature for many operators. 3GPP Release 14.



Control and User Plane Separation of EPC nodes (CUPS). 

CUPS being the 3GPP Relase 14 standards, but most fundamental aspect in evolution of Next Generation Networks Architecture, As we since last 3-4 years have been in continuous support of complete separation of control and user plan for bringing capability in network for required flexibility in terms of service creation and required scalability.

Though all IP paradigm shif since the inception of 4G has taken the first step towards it but recent advancement on virtualisation like of cloud and NFV has taken the troll ahead. 

in terms of 3GPP word..

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.

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. 
 cups 500px

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.
cups image3 

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  

commercials