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.

User Plane Cellular IoT Optimizations

As part of cellular IoT optimizations introduced by 3GPP in Release 13, user plane optimization is the second mode of optimization. 

So why user plane optimization when control plane optimization is defined?

Control plane IoT optimizations as discussed in previous post can be used only when the data sent by the UE is of smaller size. For scenarios like firmware upgrade, infrequent large data (like sensor readings collected over a period as a file upload), the UE needs a dedicated radio bearer (DRB) and consequently S1U tunnel between the eNB and the EPC. However the existing EUTRAN Service Request procedure for transitioning from IDLE mode to CONNECTED mode and set up of DRB and S1U GTPU tunnel requires elaborate signaling which would drain the battery of UE. Hence the solution is to reduce the amount of signaling involved in Service Request procedure, by preserving the RRC context at the eNB even when the UE is not active in radio transmission. For this the network (eNB) after detecting UE radio inactivity decides to put the UE in an RRC suspended state, preserves the RRC context and S1AP context of the UE, and then sends a S1-AP UE Context Suspend Request to the MME and releases the RRC towards UE by sending a resume Identity.

Later when the UE decides to send an uplink data, instead of going through elaborate service request procedure, it sends an RRC Connection Resume request to the eNB and eNB resumes the S1AP context. There is no elaborate exchange of security context between MME and eNB and no setup of AS security context. The preserved AS and RRC context are just resumed from where they got suspended earlier.

The call flows as given in section 7.3a.3 of TS 36.300 explain the sequence of events.

3GPP has also specified mechanism for the network to change the UE mode of operation from Control Plane Optimization to User Plane Optimization. This change of mode will be useful in the following scenario

1. When UE went into IDLE state while using control plane optimization, the SGW / MME received a large downlink packet. MME pages the UE and UE sends a Control Plane Service Request to MME. In response to that the MME may trigger S1 AP UE Context Setup procedure and initiate DRB radio bearer setup and switch the UE to user plane mode.
2. This is explained in section 5.6.1.4.2 of TS 24.301