This is part 7 of my series on Cellular-Internet of Things (CIoT) and NB-IoT. So far I always thought things above layer 2 were simple. There’s IP and that’s it then. But recently I came across an interesting paper by Rhode & Schwarz that suggests that this might not necessarily be the case.
Based on this paper I had a closer look at 3GPP specifications on what is referred to there as CIoT EPS optimizations. In particular, 3GPP TS 23.401 contains an introduction to the topic in Chapter 4.1. Here, three methods are laid out how to transfer small amounts of data as efficiently as possible.
Just to quickly recap, the aim of NB-IoT and CIoT (used synonymously in this post) is to connect small sensors and other devices to the cellular network that only send and receive very little data in the order of a few tens or hundreds of bytes per day. The main challenges that are expected are a disproportionate signaling overhead due to a very high number of devices per base station and the very low signal level experienced by many devices due to their deep in-house or underground use which will require many retransmissions. As a consequence optimizations have been specified to reduce the overhead that is required to establish and tear down a communication channel compared to broadband LTE.
Resuming RRC Connections
A straight forward enhancement that has been specified as part of User Plane CIoT EPS optimisations is that a RRC connection can be suspended and resumed. In LTE an RRC connection is usually released after 10 to 20 seconds of inactivity and a new RRC context has to be established when new IP packets arrive from higher layers of the protocol stack. This is not a problem, the process only takes around 100 milliseconds and the amount of data that is transferred afterward usually far exceeds this overhead. Going through the whole process to transfer just a few bytes in a few small IP packets, however, is very inefficient and hence a method has been specified to preserve the context of an RRC connection and suspend it on the mobile device and network side rather than releasing it.
User Data Over The Signaling Plane
A much more drastic way to reduce the overhead even more is to abandon the separation of user plane and signaling plane. In LTE the signaling plane is used for management tasks such as authentication and communication establishment. From a radio network point of view the Mobility Management Entity (MME) is the main player. User data, i.e. the IP packets are then transmitted over the user plane via the Serving Gateway (S-GW) and from there via the Packet Gateway (P-GW) to the Internet. From a logical point of view this separation is important but creates additional overhead especially on the air interface, as there is signaling required to establish the user data bearer in addition to the signaling bearer. To reduce this overhead, a feature referred to as ‘Control Plane CIoT EPS optimization’ specifies a way to include IP packets in a transparent container in EPS session management messages which are sent to the MME. The MME extracts the data from the container and forwards it to the S-GW which in turn forwards it to the P-GW. From there the IP packets are forwarded to the Internet. The process is reversed in the opposite direction and the network can decide if it wants to forward IP packets to the mobile device from the S-GW over a user data bearer or via the MME and the signaling data bearer. While transferring user data in a transparent container in the signaling message stream is much more efficient for small amounts of data than first establishing a user data bearer, purists probably shudder at the thought.
Non-IP Data Delivery (NIDD)
And to even further optimize small data transfer the standards contain a feature referred to as Non-IP Data Delivery (NIDD). Details can be found in TS 23.682, 4.5.14. Here, the UE embeds the data it wants to send in the transparent container without using an IP stack at all. The MME on the network side forwards such data to a the Service Capability Exposure Function (SCEF). To the outside world, the SCEF then makes this data available via IP based APIs. To send data to an NB-IOT device the SCEF is also the point of contact. Obviously this breaks the end-to-end IP transmission path and puts the network operator between the NB-IoT device and the user or company that has deployed it.
To IP Or Not To IP?
All methods described are complementary so network operators can choose which to implement in the network. In other words it will be interesting to see which network operators will offer direct IP connectivity to NB-IoT devices, which operators will not, and which will offer both.