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.

What does the agreed accelerated plan for 5G standardization by 3GPP mean for core network evolution?

3GPP agreed an accelerated plan for 5G deployment in the RAN plenary meeting at Dubrovnik, Croatia between 6th and 9th March, 2017. The agreed plan is documented in RP-170741.zip. Stage 3 completion of non stand alone (NSA) mode 5G NR connecting to EPC will be done by Dec 2017 and the ASN.1 completion will be by March 2018 making the standards in a state for 5G-NR to be deployed by end of 2018.

What does this imply for the core network evolution and deployment for 5G?

• By 2018, 5G will be deployed as a non standalone radio enhancement, acting as a secondary cell to E-UTRAN eNBs as specified under option 3 of TR 38.801 under section 7.2 (given below)

• As the purpose of this accelerated time plan is to deploy high bandwidth services (for eMBB) by 2018, using option 3 implies that all 5G traffic from the 5G gNB has to be backhauled to eNB and the S1-U link from eNB to EPC shall have a huge backhaul capacity.
• Though with option 3A, this need to backhaul 5G traffic via eNB is not there, option 3A implies SCG bearer solution is deployed with dual connectivity, which means the core network has to create multiple bearers, with the eNB (acting as MeNB) moving the high bandwidth service bearers towards the gNB. For internet traffic, typically we dont see multiple bearers created. So practically speaking, its hard to see option 3A kind of deployment being used for increased bandwidth and capacity for internet services. Option 3A would rather be used for specialised services that would require multiple bearers (e.g RCS, low latency edge hosted services).
• If option 3 is used for capacity enhancement for internet traffic, then a huge investment in increasing the capacity of the S1U backhaul needs to be done.
• This increased investment in backhaul towards the EPC would make the operators run 5G services using EPC for a longer duration (to justify the investment). 
• Deployment of nexgen core (NG Core) would be rather slow.
• In the meantime, one might see 3GPP working in future to define more of the services of NG Core in EPC also - so that roll out of 5G services can happen with EPC itself. Already control user plane separation (CUPS) is supported in EPC. This would enable hosting the user plane node closer to RAN for edge hosted services. eDECOR allows support for basic network slicing in EPC. All these indicate a potentially longer run for EPC (atleast for few more years) before NG core deployments happen.

Where is SCEF based Non IP Data Delivery Useful?

Having looked at the key system architecture optimizations introduced by 3GPP in release 13 for cellular IoT (here and here), lets now look at where the new SCEF based non IP data delivery (NIDD) is useful.

Most of the IoT applications that run on the IoT devices today directly talk to the application service via public network and security has been highly disregarded in most of these applications. Due to this, in the last year, there have been numerous instances of IoT malwares launching distributed denial of service (DDoS) attacks on many prominent web services. It is not expected that the IoT device manufacturers and application writers become security experts. This is where, for service provider based LPWAN IoT devices, NIDD via SCEF offers a secure solution and narrows down the threat vector. Lets see how.

The SCEF based non IP PDN setup and application configuring for NIDD delivery are explained in sections 5.13.2 and 5.13.1 of TS 23.682.

As can be seen, for the application service to be authorized,  it has to go through an on boarding process, and then for each UE towards which the application needs to communicate, it has to do an NIDD Configuration Request. During the NIDD Configuration Request procedure, the SCEF authorizes whether the application server is allowed to access the UE. This step makes sure that any rogue malware is not directly communicating with the UE and installing malware on it to launch a DDoS attack. Since the PDN uses non IP payload (e.g OMA is discussing LWM2M binding over 3GPP NAS in Annex J of its draft 1.1 release of the LWM2M Technical Specification) and the fact that the NAS is encrypted, no IP based application can directly access UE. The communication between the UE and the SCEF will be non IP while the application can use RESTful HTTP APIs (over IP) to communicate with the SCEF.  SCEF in this case, essentially acts as an IoT application gateway between the IoT devices and the applications. All security policies can be controlled through the SCEF.

But a question arises, where these application oboarding process, API for NIDD configuration request are defined. As of Release 13 and 14, these were not in scope of 3GPP. However 3GPP SA plenary agreed a WID last week (SP‑170240) for SA2 to work on defining northbound APIs from SCEF for NIDD and also a study item (SID) to define a common API framework for northbound APIs (SP‑170279).

In order for secure IoT devices / applications via cellular IoT / LPWAN technologies to be successful, the following are necessary

1. Operators providing SDKs for IoT device manufacturers to write non IP based applications that can communicate with the operator SCEF
2. Standardized APIs northbound of SCEF for application writers to interface with SCEF
3. Viable business agreements between operators and application developers for revenue share and accelerated innovation
1. Possibly an experimental / developer test API interface exposed at limited period free subscription / low cost option could help application developers to quickly experiment an idea.
2. AT&T already provides APIs for writing applications and communicating with the devices - https://m2x.att.com/ and they provide a free trial as well.

Other use cases of SCEF based NIDD:

1. Circuit switch based SMS infrastructure can now be slowly reach a sunset.
2. SMS can be sent as a non IP data via SCEF by an application. Instead of using MSISDN to reach the UE for mobile terminated SMS, the UE external Identifier can be used.
3. However sending SMS via NIDD path requires a non IP PDN to be established by the UE, unlike the traditional SMS, where a PDN is not necessary.