3GPP 5G Control Plane Service Based Architecture

I recently did a workshop session on titled

3GPP 5G Control Plane Service Based Architecture - The Need, Use Cases and the Future @ IEEE Comsoc Bangalore workshop on

Cloudification and Network Slicing in 5G

The presentation is available here

3GPP 5G Control Plane Service Based Architecture from Sridhar Bhaskaran

GSMA - Road to 5G Introduction and Migration

GSMA had released this paper detailing out various options for 5G introduction and the migration path. This is a very good material for those trying to understand how 5G will be deployed.

Road to 5G: Introduction and Migration from GSMA

5G Network Slicing

Just posted a presentation about 5G network slicing based on the 3GPP Release 15 standards here. The slide covers details of how network slicing as a concept evolved in 3GPP from Release 13 onwards with DECOR, eDECOR and then comprehensive end to end network slicing in Release 15.

5G Core Network and The Cloud - A Standards Perspective

I did a presentation at India CloudNxt2017 (https://ccici.in/events/) on the 5G core network standards based on 3GPP release 15 and the architectural enablers for cloud based deployments. This is for general audience and hence its a high level overview only - not delving into details.

It is available here

Feature differences between 5G core and EPC

This post will look at the key feature differences between 5G core and EPC highlighting the new and exciting features available in the 5G core.

The following table provides the list of feature differences between EPC and 5GC that are useful for an end user.

Table 1: Features useful to end users

Sl.No	Feature	Availability in EPC	Availability in 5GC
1	One UE connecting to multiple network slices.	No	Yes
2	One UE connecting to one network slice.	Yes - through eDECOR	Yes
3	Support for Ethernet type PDN / PDU session.	As of this posting not available	Yes Note: There is a ongoing Release 16 study to support full fledged LAN over 5G. The requirements from SA1 based on ongoing study are in TR 22.821
4	Support for uplink branching point / classifier to divert select IP flows of a PDN to specific local network.	No (though SIPTO at a whole PDN level is available - branching of specific flows within a PDN is not available)	Yes
5	Local Area Data Network - Support for Mobile Edge Computing.	Partial - LIPA and SIPTO below the RAN	Yes
6	Multi-homed IPv6.	No	Yes
7	Mobile Originated Communication Only mode (MICO) that allows IoT devices that only send uplink data followed by immediate downlink data to initiate radio bearer setup only by the UE.	No	Yes
8	Enhanced security and privacy including encryption of IMSI using home operator (HPLMN) provided certificates.	No	Yes
9	Same authentication framework and authentication mechanism irrespective of access network (3GPP access and non 3GPP access like WLAN, Fixed network etc)	No	Yes
10	Application influence on traffic steering	PCRF providing traffic steering rules to PCEF is possible to divert traffic via TSSF / TDF. But application directly influencing the 3GPP network is not possible.	Yes
11	Ability of network to control allowed and non-allowed areas of a UE to initiate communication and dynamic update of those areas in the UE by the network.	Only forbidden tracking area (TA) list management is possible.	Yes. Network can page the UE while in non allowed area to update the service area list via a configuration update.
12	Ability of RAN to make the UE use RRC Inactive state while in core network connected state, thus providing signaling savings and energy efficiency to UE, based on core network provided RRC Inactive asistance information.	No	Yes.

The following table provides the list of feature differences between EPC and 5GC that have an impact on the operational aspects of the network for the operators.

Table 2: Features impacting operational aspects for the operators

Sl.No	Feature	Availability in EPC	Availability in 5GC
1	Any node communicating with any node directly through APIs (Service Based Architecture).	No	Yes
2	Selection of a service (API endpoint) to communicate instead of a node by contacting a service repository (NRF).	No	Yes
3	Policy layer influencing mobility policy	No	Yes
4	Standard interface towards network data analytics.	No	Yes

Once 5G phase 1 standards is completed in 3GPP SA2 more detailed analysis of each feature will follow.

Hardware architecture for split user plane of mobile packet core

3GPP Release 14 has specified the architecture for split control and user plane for the mobile packet core enabling the separation of the user plane from control plane for the following network elements

1. SGW (SGW-C and SGW-U)
2. PGW (PGW-C and PGW-U) and
3. TDF (TDF-C and TDF-U)

It begs the following questions

1. What could be the potential architecture for these user plane nodes?
2. Can white box switch silicon be directly used as 3GPP user plane elements?

Before we explore the answers for these, lets have a look at the requirements of a 3GPP user plane node

For PGW-U and/or TDF-U:

1. On the downlink direction, ability to classify a packet and do bearer binding (i.e encapsulate the packet into the right GTPU tunnel).
2. Ability to detect idle flows and report them to the C plane so that the C plane can take actions like terminating the flow / bearer / PDN.
3. Counting the uplink and downlink volume of traffic per flow.
4. Counting the uplink and downlink usage time (i.e count only the time for which the flow is actively involved in forwarding, ignorig the time for which the flow was idle).
5. Support aggregate bit rate enforcement on a group of flows (i.e ability to define meters and associate that meter with multiple flows).
6. Application specific packet classification (optional) - for Application Detection and Control (ADC). This means the user plane supports deep packet inspection for a variety of applications and also supports taking configuration of application ID to its L4-L7 packet filter for matching/classifying the incoming traffic as the application.
7. Ability to configure the packet marking policy per traffic steering policy identifier and the ability to associate a flow against a traffic steering policy.
8. Ability to report to the C plane at a per flow level on set volume and time thresholds. In summary, the user plane should count per flow traffic volume and should also support running timers per flow.

For SGW-U:

1. Ability to buffer packets when the bearer is in IDLE state (due to UE being in EMM-IDLE).
2. Ability to modify the GTPU tunnel header and switch the tunnel from ingress side to the egress

All of the above requirements need to be supported for atleast a few million flows (today's state of the art EPC gateways support few million bearers). In order to hold the bearer binding, traffic classification, timer, volume thresholds at per flow level for millions of flows, the user plane entity should have enough memory. But for line rate forwarding the memory access should not be a bottleneck. Hence if we need to achieve line rate forwarding with white box silicon based forwarders, they should have huge amount of (atleast 2 to 4 GB) on chip SRAM or TCAM to hold the flow classification and bearer binding rules. However on chip SRAM and TCAM in such high capacity will increase the cost of silicon so high, making such customized high capacity silicon just for the sake of mobile packet core, doesnt justify the one of the fundamental premise for control / user separation (i.e) ability to scale the data plane with cheap forwarders. A single TCAM that supports few million entry lookup space will mean it has that many million addressable locations. During TCAM lookup all these locations / cells will be charged and all but one will discharge and this will consume power. Note that a TCAM stores contents and comparators are used to locate stored content based on a given key. So the more the storage, the more the number of cells charged and discharged and hence more the power.  Hence beyond a point adding too many cells on a single chip will heat up the chip to an extent that it burns.  Refer here.

• Quote from the paper - "One of the major issues in TCAM, or in gen- eral any CAM, is their very high dynamic power consumption. The main reason behind this issue is the fully parallel nature of search operation. This fully parallel search operation causes all the match lines in a TCAM block to charge in their precharge phase and allows all but one match line to discharge during their evaluation phase. The one match line which does not discharge during evaluation phase indicates the match in the search oper- at ion.”

However chaining of multiple TCAMs with each looking up few 100 thousand space is possible. But this will increase the cost proportionately.

So, in order to meet the cost, power efficiency and the scale, one has to run the data plane on x86 with forwarding logic in the user space doing a kernel bypass through techniques like DPDK. Memory can be through DRAM, but DRAM access will become the bottleneck for line rate processing. Hence the data structures in DRAM need to be carefully placed to utilize the cache hierarchy - such that frequently used flow rules are placed together in RAM and hence they get a chance to be in the cache most of the time.

In summary:

The hardware architecture for the user plane of mobile packet core requires x86 with enough DRAM. Custom white box switch silicon / silicon supporting PISA (Protocol Independent Switch Architecture) cannot directly support all the requirements of a EPC forwarder, atleast as of now.

Why 3GPP did not choose OpenFlow as the protocol for Sx interface (Control / User plane separation)

3GPP introduced control / user plane separation for the EPC in Release 14 and the protocol work for the Sx interface between the control plane and the user plane is now largely complete (few editor's note still need to be resolved). A question often comes up why 3GPP chose to design the PFCP protocl in TS 29.244 similar to GTP and why it did not adopt OpenFlow. The reason is well captured in this discussion paper presented by me in 3GPP CT4#74 at Tenerife in July, 2016.

The discussion paper is available here

In the same meeting another discussion paper on mapping the list of features on Gx and Sd interfaces to the Sx interface was also presented by me in this paper. This provided the basis for defining the features on the TS 29.244 spec.