NB-IoT and LTE-M explained: cellular connectivity built for small devices

Regular LTE was designed for phones: devices that are charged daily, that want tens of megabits per second, and that have room for a capable modem. A water meter in a basement needs none of that. It sends a few bytes a day, has to run for a decade on a battery, and sits behind a wall that attenuates radio signals badly.

NB-IoT and LTE-M are the two 3GPP answers to that gap. Both were standardized in 3GPP Release 13, both run on licensed spectrum owned by mobile operators, and both are carried forward into 5G as the massive machine-type communication part of the standard. They are the licensed-spectrum branch of the LPWAN family, next to unlicensed options such as LoRaWAN.

This guide explains what each technology changes relative to full LTE, how the two differ from each other, and which one fits which device.

What they share

Both technologies are stripped-down LTE profiles that reuse operator infrastructure. An operator typically enables them with a software upgrade on existing base stations, which is why coverage arrived quickly in many countries. Devices use ordinary SIM credentials, including eSIM and iSIM variants, and the traffic goes through the operator core with the same authentication and encryption as a phone.

The shared goals are long battery life, deep indoor coverage, low module cost, and support for very high device density per cell. Two power-saving mechanisms, introduced for both, do most of the work:

• Power Saving Mode (PSM) lets a device tell the network it is going to sleep for hours or days. It stays registered, so it does not need to re-attach when it wakes, but it is unreachable until it decides to send.
• Extended Discontinuous Reception (eDRX) stretches the interval between paging checks from seconds to as long as about 44 minutes on LTE-M and about 3 hours on NB-IoT. The device is reachable for downlink, just not immediately.

A device in PSM for most of the day behaves much like a LoRaWAN Class A node: it speaks when it has something to say, and the network queues anything addressed to it.

NB-IoT: narrow, cheap and patient

NB-IoT uses a single 180 kHz carrier in a 200 kHz channel, which can be placed inside an LTE carrier, in an LTE guard band, or standalone in refarmed 2G spectrum. Narrow bandwidth concentrates transmit power, which, together with heavy repetition of transmissions, gives NB-IoT a link budget considerably better than regular LTE (the 3GPP design target is a maximum coupling loss of 164 dB). That is what gets a signal through to a meter in a basement or a sensor in a manhole.

The price is throughput and flexibility. Data rates are in the tens of kilobits per second at best, often far less at the cell edge, and the air interface is half-duplex. The original release had no connected-mode handover: a device that moves between cells drops the connection and re-establishes it. Later releases added some mobility and positioning features, but NB-IoT remains a technology for things that mostly stay put. Voice is not supported.

Because the modem is simple, module cost and power draw are low. The intended use is a fixed asset sending small, infrequent payloads: metering, parking sensors, environmental monitoring, agricultural soil probes, smart city infrastructure.

LTE-M: a smaller LTE, not a different one

LTE-M (the Cat-M1 device category, with Cat-M2 added later) uses a 1.4 MHz channel inside a normal LTE carrier. It keeps most of what LTE offers: full-duplex operation on capable modules, data rates up to roughly a megabit per second, and connected-mode handover between cells and support for voice over LTE. Latency is comparable to normal LTE and far lower than NB-IoT.

Link budget is improved over regular LTE through repetition, though not to the degree of NB-IoT. Power consumption is higher than NB-IoT during transmission, but a device that sends its data quickly and returns to PSM can still reach multi-year battery life.

The intended use is anything that moves, talks, or needs to react quickly: asset tracking, wearables, fleet telematics, alarm panels, and devices that need firmware updates of meaningful size. An OTA update over NB-IoT is possible but painfully slow; over LTE-M it is routine.

Choosing between them

A short decision list covers most cases:

• The device never moves, sends a few hundred bytes a day, and sits somewhere with poor signal: NB-IoT.
• The device moves at vehicle speed, or must stay connected while moving: LTE-M.
• The device needs voice, or sub-second response to downlink commands: LTE-M.
• Firmware images are large or updates are frequent: LTE-M.
• Cost per module and per connection must be as low as possible and the data profile allows it: NB-IoT.

Coverage is the practical tiebreaker. Operator support is uneven by country and by operator, and some regions committed to one technology much more than the other. Before locking a design to one, check deployed coverage along the actual route your devices will travel, and check roaming agreements if units ship across borders. Many modules support both and let you select at runtime, which is the safe choice for products sold internationally, at the cost of a slightly more expensive IoT module.

5G and what changes

Both technologies were included in 3GPP’s IMT-2020 (5G) submission to the ITU and continue to be served by 5G core networks. For low-end devices that is reassuring: the modules you design in today are expected to remain supported as 2G and 3G networks are switched off. For devices that need more than LTE-M provides but less than full 5G, 5G RedCap, introduced in 3GPP Release 17, fills the middle ground with higher throughput and lower complexity than a phone modem.

What NB-IoT and LTE-M do not get is the low latency and high reliability features of full 5G. They remain what they were designed to be: patient, efficient links for small devices.

Practical notes for designers

Plan for PSM and eDRX from the start; a device that keeps a connection open to save development effort will burn its battery in weeks. Keep payloads small and encode them compactly, using CBOR or a binary format rather than verbose JSON, and send over UDP with CoAP or LwM2M when the network supports it, since TCP handshakes are expensive on a slow, half-duplex link. Expect first-attach times of many seconds in weak coverage and design user feedback around that.

Finally, manage connectivity as a product concern, not just a radio one. A connectivity management platform that shows which SIMs are active, where they roam, and which ones have stopped reporting will save more field visits than any antenna tweak.

Where to go next

• IoT connectivity overview compares cellular IoT with Wi-Fi, BLE, Zigbee, Thread and LoRaWAN.
• LoRaWAN explained covers the main unlicensed alternative for the same class of devices.
• Types of IoT devices and the constraints that shape them explains the power and cost budgets that drive these choices.

Topics: NB-IoT, LTE-M, cellular IoT, LPWAN, 3GPP