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.