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.

Role of SCEF

3GPP Release 13 introduced a new node in the EPC for exposure of 3GPP network service capabilities to 3rd party applications. This node is the Service Capability Exposure Function (SCEF). This node was introduced as part of the Architectural Enhancements for Service Exposure (AESE) work item in SA2. 

Though the concept of exposing telecom network service capabilities via APIs to 3rd party application is not new and the world has seen where OSA/Parlay went with the circuit switched networks, what makes SCEF compelling and different from OSA/Parlay are the following

1. Deployment and use of cellular technologies for connecting the IoT devices to the network looks imminent.
2. For IoT, the business value is in the applications and gaining actionable insights from the data gathered from the IoT devices, using analytics.
3. This requires the operator to open up their network to tap into the network events and onboard applications.
4. Another key aspect of IoT is security. After the recent large scale DDOS attacks using IoT devices through the Mirai botnet, security has become the key focus. So access to the IoT devices by the applications should be through a controlled and secure environment that first authenticates and authorizes the application during an onboarding process before they gain access to the data from the IoT devices. SCEF provides this key aspect and since the IoT devices connect to the network through the cellular operators, the cellular service providers can make sure these devices are not configured with default credentials and their access to the network is secure.

The following are the key functionalities of SCEF

1. Exposure of 3GPP network events through northbound APIs to applications. 3GPP does not define the northbound APIs in release 13. The northbound APIs are defined by OMA and OneM2M. However in release 15, 3GPP has started a new work item to define northbound APIs from SCEF for the non IP data delivery (NIDD) procedure. This work item is still pending approval at the SA plenary. The work item was triggered by an LS Response from the SA plenary  to OMA and OneM2M copied to SA2 and SA1. This was a response to the LS sent by OneM2M to SA Plenary. The work item description by SA2 is here.
2. Exposure of the following events (defined through the Monitoring Events - MONTE work item in release 13):
1. UE reachability
2. UE loss of connectivity
3. UE location reporting
4. UE roaming status
5. Communication failure 
6. Change of IMEI-IMSI association
3. Registering for UE reachability notification upon DDN failure for high latency communications (defined through the High Latency Communications - HLCom work item in release 13)
4. Non IP Data Delivery (NIDD) through a non IP PDN established through the SCEF. This was defined in the Cellular IoT work item in release 13.

3GPP is also continuously evolving the functionalities of SCEF in release 14 and release 15 and Network Exposure Function (NEF) is a key network function in the NexGen (5G) network architecture as well. In subsequent posts, I will dig into the details of Cellular IoT optimizations and how SCEF is getting used in that.

The difference between NB-IoT, LTE-M and Cellular IoT

There has been lot of confusion among different terminologies that the industry uses for the new features / technologies introduced by 3GPP as part of Release 12 and 13 to support Low Power Wide Area Network (LPWAN) IoT devices.

Martin Sauter has written a series of blogs explaining the differences between Cat-0, Cat-M1 (usually called LTE-M) and Cat-M2 (called the NB-IoT) devices

https://blog.wirelessmoves.com/2016/05/cellular-iot-the-dust-slowly-settles-mtc-nb-iot-and-things-in-between-part-1.html

https://blog.wirelessmoves.com/2016/05/cellular-iot-the-dust-slowly-settles-part-2-cat-1-and-cat-0-devices.html

https://blog.wirelessmoves.com/2016/05/cellular-iot-the-dust-slowly-settles-part-3-cat-m1-devices.html

https://blog.wirelessmoves.com/2016/06/cellular-iot-the-dust-slowly-settles-part-4-cat-m2-devices.html

The Cat-M1 and Cat-M2 (NB-IoT) devices technically address the LPWAN IoT market. Beyond these there is another term that is constantly used - Cellular IoT Optimizations

Cellular IoT Optimizations refers to the work done by the 3GPP SA2 (the System Architecture group) for the optimizations on the EPC (evolved packet core) network to support the Cat-M1 and Cat-M2 devices. The following are the key optimizations

1. Control Plane Optimizations which include
   
   
   • Non IP PDN
   
   
   • Data over NAS which is sent over SRB for both IP and Non IP PDN
   
   
   • Support for Non IP PDN over SCEF path
   
   
   • No need for DRB setup
   
   
   • Serving PLMN Rate Control
   
   
   • APN Rate Control
   
   


2. User Plane Optimizations which Include
   
   
   • Support for RRC Suspend state when UE is in EMM-IDLE
   
   
   • Efficient IDLE-Active state transition
   
   
   • Support for both IP and non IP PDN over user plane path
   
   
   • APN Rate Control
   
   


3. Support for change from CP optimization to UP optimization path at run time

The stage 2 aspects of Cellular IoT Optimizations are defined in 3GPP TS 23.682 spec in release 13. In the subsequent posts I will delve into  the use case and details of the control plane and user plane optimizations.

Which IoT applications look compelling for NB-IoT?

The standardization of Narrow Band IoT (NB-IoT) and the corresponding core network architectural changes, called the Cellular IoT optimizations are completed by 3GPP as of June 2016, with amendments and corrections done during the September, 2016 plenary meeting. This now makes one to see the potential use cases for IoT applications that would run on NB-IoT. As a standards engineer closely involved with the Cellular IoT standardization in 3GPP, this is an attempt to reflect some of my thoughts on that.

NB-IoT being a licensed spectrum technology and service provider owned, it suits best for IoT applications that have the following requirements

1. Seamless connectivity across wide areas
2. Extended coverage at even hard to reach areas
3. Ability to partner with large ecosystem of application developers
4. Strict SLAs and charging associated with the agreed SLA
5. Highly available infrastructure
6. National and/or international roaming

The following are some of the applications that fit these requirements

1. Fleet management and tracking
2. Utilities like power, water supply, piped natural gas supply
3. Garbage management — automatic calling of garbage collection trucks once garbage bins become full
4. Agriculture and Irrigation control
5. Smart cities and city infrastructure management (including garbage management as in /3/ above, traffic control etc)

The key for successful deployment and monetization of such services by the operators lie with the operator providing at least the following basic services:

1. Device management with various enterprises providing one or more of the above IoT applications being able to manage their respective devices through a portal / single pane of glass.
2. Ability for the IoT application provider (enterprises) to onboard the application with the operator and take the device data.

On top of this if the operator provides as a service, running application and analytics in hosted environments, they get to monetize this service as well.

There are lot of questions that I encounter regarding the various architectural options 3GPP cellular IoT optimizations provide and how best to use them. I will write about the use cases and scenarios where one would use each of the cellular IoT optimization in subsequent posts.

Stay tuned.