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

Cellular IoT Control Plane Optimization

As seen in earlier posts, the 3GPP release 13 IoT system architecture work done by the SA2 group had 2 key optimizations on the system architecture

1. Control plane optimizations
2. User plane optimizations

This post is a deep dive on the control plane optimizations.

Why is control plane optimization needed?

Today in LTE when the UE needs to send uplink data while in EMM-IDLE state, it has to send a Service Request to the core network, which then triggers radio bearer establishment and setup of S1U GTPU tunnel between eNB and SGW (which involves a Modify Bearer Request signaling from MME to SGW). 

For battery constrained IoT devices that need to send uplink data once in a week or a month and that too a small payload, such elaborate signaling procedures are a waste of unnecessary signaling and energy (battery drain). Instead its much simpler and efficient to send the small data payload over the control plane signaling and let MME that receives the small data over NAS (control plane) send the data to SGW.

Ways of routing data sent over control plane to applications:

For cellular IoT optimizations, 3GPP SA2 introduced a new PDN type - non-IP. Upto release 13 the following PDN types were already supported for LTE

1. IPv4
2. IPv6
3. IPv4v6

From release 13 onwards non-IP PDN type is added as the 4th PDN type. When a UE uses control plane optimization it can establish PDNs with IP PDN types (v4 / v6 or v4v6) or non IP PDN type. An IP PDN can only go through SGW and PGW. 

A non IP PDN established when UE uses control plane optimization has 2 possible paths

1. via MME —> SGW —> PGW
2. via MME —> SCEF

So when data is sent over control plane (NAS), it can either get routed through SGW —> PGW (if its a IP PDN or a non IP PDN which is not an SCEF PDN) or through the SCEF if its a non IP PDN established through SCEF.

How the UE sends uplink data over control plane (NAS) when in EMM-IDLE state?

When the UE is in EMM-IDLE state, the eNodeB has no context about the UE and has no security relationship. For LTE when data is sent over the DRB (user plane), the UE and eNB establish a security context and that security context is used to encrypt the data between the UE and the eNB. Similarly for data sent over NAS, the data has to be encrypted. The UE has an established NAS security context. The UE initiates a new message called CONTROL PLANE SERVICE REQUEST (ref TS 24.301 section 8.2.33) which carries the ESM DATA TRANSPORT inside the ESM Message Container IE and the data is carried inside this ESM DATA TRANSPORT message payload of the CONTROL PLANE SERVICE REQUEST. This data payload is encrypted using the NAS security context that the UE already has. 

So why a new CONTROL PLANE SERVICE REQUEST message is required and why not extend the existing SERVICE REQUEST message? The answer lies in how the UE state machine behaves for the normal SERVICE REQUEST message. As per section 5.6.1.1 of TS 24.301, once the UE sends SERVICE REQUEST, it starts T3417 timer and the timer is stopped when RRC indicates successful establishment of radio bearers. So how to indicate the UE that data sent over NAS is successfully received at MME if its sent over the normal SERVICE REQUEST message? 3GPP CT1 debated about using a new SERVICE ACCEPT message in response to SERVICE REQUEST to indicate the UE. However the UE vendors were not in favour of modifying the existing SERVICE REQUEST state machine to accept a new SERVICE ACCEPT message as yet another condition to stop T3417. Instead a new message called CONTROL PLANE SERVICE REQUEST was introduced with SERVICE ACCEPT as the response to indicate successful handling of data over NAS at MME.

Since only the data sent in the ESM DATA TRANSPORT payload of CONTROL PLANE SERVICE REQUEST is ciphered and not the full NAS message, this introduces a new case of partially ciphered NAS message. As CONTROL PLANE SERVICE REQUEST is an initial NAS message it cant be fully ciphered. It can only be integrity protected. Hence only the data part alone can be partially ciphered. It is important to note that for ciphering the keystream length to be given is the length of the ESM-DATA-TRANSPORT message.

The following picture shows how the CONTROL  PLANE SERVICE REQUEST is encoded and which part of it is ciphered.

Other key aspects of control plane optimization

1. UE can attach without PDN. In LTE an attach without PDN is not possible. However with cellular IoT optimization, attach without PDN was introduced (applicable to both control plane and user plane optimization). To handle this case, the UE shall include a ESM DUMMY MESSAGE instead of the PDN CONNECTIVITY REQUEST in the ESM container (which is a mandatory IE) of the Attach Request
2. MME to use GTP-U (S11U) tunnel towards SGW to send the data received over control plane for PDNs set up through SGW/PGW.
3. Transfer of the S11U GTPU FTEIDs across MMEs during inter MME TAU procedure.
4. Robust Header Compression (RoHC) between MME and UE for IP PDNs data sent over control plane.
5. APN rate control and Serving PLMN rate control
6. Change of PDN from control plane to user plane optimization (for PDNs established through SGW/PGW, all such PDNs of the UE shall either follow control plane optimization or user plane optimization). PDNs established with SCEF shall always use control plane optimization only and that too non IP PDN type only.

Why APN and serving PLMN rate control?

LPWA IoT devices will be sending very minimal data and their bandwidth consumption will be very less. Using consumer PDN tariff (which typically is of the order of few GBs of data per month for X $) will not allow the operators to meaningfully charge for the IoT consumption. For IoT devices the charging should rather be at X number of messages in a week / month. APN rate control is a parameter that enforces this in the form of number of messages per time unit. APN rate control is applicable to both control plane and user plane optimization.

Serving PLMN rate control is a rate of message per 6 minute interval allowed by the serving PLMN and signaled to the HPLMN in case of roaming UEs so that the HPLMN will not bombard the VPLMN with too many messages. Serving PLMN rate control is applicable only for PDNs pinned to control plane (i.e SCEF PDNs). Its not applicable to user plane optimization.

A deep dive into user plane optimization changes in the core network will follow in subsequent posts.