Cellular IoT – The Dust Slowly Settles – Part 4 – Cat-NB1 Devices

In the three previous parts (here, here and here) on the Internet of Things and 3GPP, I’ve described Cat-1, Cat-0 and Cat-M1 devices. In this post we get down to the really interesting development in 3GPP on this topic: Narrow Band Internet of Things (NB-IoT) and Cat-NB1 devices (previously referred to as Cat M2 devices).

While the previous developments mainly added a bit here and a bit there to the 3GPP LTE specifications, the NB-IoT Work Item takes a more radical approach. Several approaches were studied in 3GPP and the details for all of them can be found in the 500+ pages 3GPP Technical Report TR 45.820. In September 2015 an agreement was reached and one solution was selected. The details of this decision were documented in the NB-IOT work item description contained in RP-151621.

Very Narrow Channels That Fit In Everywhere

Designed for ultra low cost devices where the modem shall cost less than $5 and where data rates can be very low in exchange for power efficiency and deep in-house coverage, the solution makes a revolutionary break from the mobile broadband approach of LTE: The size of a NB-IoT channel is merely 180 kHz. Compare that to mobile broadband LTE channel bandwidths of 20 MHz or even triple that number of Carrier Aggregation devices that can bundle 3 downlink channels today. Despite this, a NB-IoT channel also uses Orthogonal Frequency Division Multiplexing (OFDM) like LTE’s physical layer, the same sub-carrier spacing, OFDM symbol duration, slot format, slot duration and sub-frame duration as well as the RLC, RRC and MAC protocols standardized for LTE.

Deployment Options and Backwards Compatibility

The 180 kHz are also significant as this allows a number of different deployment scenarios in practice. One option is to deploy one or more NB-IoT channels inside a larger LTE channel. The second option is to use the guard band of a full LTE channel. And finally, the 180 kHz bandwidth allows to replace a GSM channel for a NB-IoT channel. All three deployment scenarios are backwards compatible which means that LTE devices (such as smartphones, tablets, etc. etc.) that do not implement the NB-IoT feature  simply do not see NB-IoT channel inside the main LTE channel or slightly outside in the guard band. Legacy GSM devices also won’t see a NB-IoT carrier if used alongside GSM 180 kHz carriers. Such devices will just see noise where NB-IoT is active.

Tens Of Thousands Of Devices and Low Data Rates

Despite its very little spectrum the new NB-IoT channel and access management procedures are designed to support 50.000 devices per cell. Yes, per cell, you read right, so you can imagine that the amount of data to be transmitted per device per day must be really low. According to Qualcomm throughput for devices on the NB-IoT channel can be up to 500 kbit/s in the downlink and 40 kbit/s in the uplink direction in good signal conditions. Those are theoretical values, however, as many devices have to share a channel and the system was specifically designed to also support very low signal conditions at the expense of throughput. One interesting calculation found in an Ericsson paper on the topic for example shows that transferring a small UDP packet can require up to 7 seconds under very low signal conditions where the system repeats each individual transmission for system access, bandwidth assignment, user data transfer and acknowledgement several dozen times. This gives one an idea of where we stand at the other end of the data rate divide.

The Use Of Tones

In the downlink direction, the channel uses OFDM modulation and several 15 kHz sub-carriers, also referred to as “tones”. In the uplink direction, a mobile device can also use the standard 15 kHz spacing and optionally also 3.75 kHz tones in combination with SC-FDMA modulation (also used in LTE). The 3.75 kHz option has been specified for scenarios in which a device is able to receive data from the network but is unable to make itself heard due to its small antenna, low transmission power, distance, signal conditions, etc. By using a 3.75 kHz instead of a 15 kHz tone, the transmission power can be focused on a narrower channel which significantly improves the link budget and chances to be heard at the base station side. Very low signal conditions are referred to as “extreme coverage” and NB-IoT is specified to still work in radio conditions that are 20 dB worse than those that would still be usable with GSM.

For devices that are optimized for power rather than “extreme coverage” scenarios, power class 5 has been specified which limits the maximum power output of a device to 20 dBm (0.1 Watt). Again, depending on radio conditions and speed requirements, data to and from a device can be transmitted in a single tone or in a 3 or 6 multi-tone arrangement. Due to all things described so far it is clear that the traditional LTE signaling channels are not reusable for NB-IoT. While the basics ideas like random access and assigning transmission opportunities remain the same, the format and location of the channels is new.

Radio Security and Backwards Compatibility

From a radio security point of view, LTE’s authentication and ciphering are used for NB-IoT including SIM cards. Small devices might use embedded SIMs (eSIM) which behave like normal SIM cards today but are much smaller and soldered directly on the circuit board. Not supported is backwards compatibility to LTE, GSM to UMTS so a NB-IoT device has to only support the NB-IoT part of the specification. In practice a device could in theory also implement the circuitry necessary for those standards but re-selections and handover between them would not be supported.

Summary

Compared to all other MTC and IoT improvements made over recent years in the 3GPP specifications this is by far the most comprehensive and far reaching approach to date. By optimizing for power, cost and for low data rates it gives hardware manufacturers something to play with for the next couple of years and offers many opportunities to put a radio into many things without requiring a local hub to pick up transmissions.

Not mentioned in my posts so far but also very important is that the Internet Protocol is used on top of the NB-IoT radio stack. With data rates as low as they are specified and delay as long as 7 seconds as described above the use of TCP might not make a lot of sense in many scenarios and UDP might get a popularity boost from the IoT domain. But IP is IP is IP which means that IoT devices do not require an intermediary to connect to the Internet. And that’s important for those people like me who prefer to have smart devices communicate with them directly rather than requiring something in between to translate higher layers of the protocol stack which is the hand of others.