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.