Choosing between LTE-M and NB-IoT should be straightforward.
Both were designed for low-power cellular devices. Both offer better coverage than conventional LTE. Both can use features such as Power Saving Mode and extended Discontinuous Reception to keep devices asleep for long periods.
The usual comparison says:
- Choose NB-IoT for small, infrequent messages and maximum battery life.
- Choose LTE-M for mobility, higher data rates and more responsive communications.
That summary is broadly correct, but it misses the part that matters when you build a real product.
For a simple sensor that wakes, transmits a reading and returns to sleep, NB-IoT can be technically superior. Its narrow bandwidth, coverage enhancements and optimisation for small data transfers make it an excellent fit for constrained devices.
However, low power is not the only requirement in an IoT system.
As soon as the server needs to communicate back to the device, or the product needs firmware updates, remote commands or an established TCP session, the practical advantages of LTE-M become much more significant.
What are LTE-M and NB-IoT?
LTE-M and NB-IoT are both cellular technologies developed by 3GPP for machine-to-machine and Internet of Things applications.
Unlike conventional LTE, they are designed for devices that:
- Send relatively small amounts of data
- Spend most of their time asleep
- Operate from batteries
- Need better coverage in difficult locations
- May remain deployed for many years
They achieve this with narrower bandwidths, reduced modem complexity and network features that allow devices to disconnect from active communication without completely losing their registration.
The two technologies solve similar problems, but they make different compromises.
Where NB-IoT has the technical advantage
NB-IoT uses a channel bandwidth of only 180 kHz. LTE-M uses considerably more bandwidth, typically 1.4 MHz.
That narrow NB-IoT carrier allows the system to concentrate on transmitting small amounts of data efficiently. It also supports extensive repetitions when signal conditions are poor, improving the probability that a message will reach the network.
For a stationary device that sends a few bytes several times a day, that is an attractive design.
Typical applications include:
- Utility meters
- Environmental sensors
- Tank-level monitors
- Parking sensors
- Alarm systems
- Agricultural sensors
- Fixed infrastructure monitoring
These devices normally spend nearly all their time asleep. They wake, measure something, connect to the network, send a small message and return to sleep.
NB-IoT also has a link-budget advantage over LTE-M. In practice, this can help a device connect from locations such as basements, service cupboards or meter cabinets where ordinary cellular coverage is marginal.
There is a cost to that coverage improvement. Repetitions consume time and energy, so a device operating at the edge of coverage may remain connected for much longer than expected. Better maximum coverage does not automatically mean lower energy consumption in every deployment.
Nevertheless, when the application consists predominantly of small, infrequent uplink messages, NB-IoT is arguably the more focused technology.
It removes capabilities the device does not need and optimises heavily for the ones it does.
Why LTE-M often feels easier
LTE-M provides higher data rates, lower latency and better support for mobility than NB-IoT.
It is better suited to devices such as:
- Asset trackers
- Mobile monitoring equipment
- Wearable devices
- Payment terminals
- Products requiring regular firmware updates
- Devices with interactive remote control
- Applications sending larger or more frequent messages
LTE-M also behaves more like the conventional IP connectivity that developers and cloud platforms already understand.
That matters more than it may initially appear.
A technically efficient radio interface is only one part of an IoT system. The device also needs a modem, a protocol stack, a server, security, device management and a reliable way to recover when something fails.
LTE-M frequently provides the path of least resistance through that complete system.
NB-IoT is not technically UDP-only
One important distinction needs to be made: NB-IoT is not inherently limited to UDP.
An NB-IoT connection can carry IP traffic, including TCP, where the module, network and connectivity provider support it. It may also support Non-IP Data Delivery, which avoids a conventional IP session entirely.
However, UDP is commonly preferred for NB-IoT because it has less connection overhead than TCP.
TCP normally requires a connection to be established before application data is exchanged. It acknowledges transmitted data, maintains state, controls the transmission rate and retransmits missing packets. These features make TCP extremely useful, but they also cost bytes, radio time, memory and energy.
UDP has no connection-establishment handshake and maintains much less transport-layer state. A device can potentially wake, send one datagram and return to sleep.
For an application sending a 20-byte sensor reading, that simplicity is compelling.
The difficulty is that many real applications need more than one-way delivery.
Sending data is easy; receiving it is harder
A sleeping device cannot listen to the network.
This sounds obvious, but it creates one of the most important design constraints in low-power cellular IoT. A server cannot send a command to a device whenever it likes if the modem is in Power Saving Mode.
The device must first wake and become reachable.
There are several ways to handle this:
- The device can poll the server each time it wakes.
- It can remain reachable for an active-time window after transmitting.
- It can use eDRX and listen periodically for paging.
- The server can queue commands until the next device connection.
- The device can maintain a longer-lived session at the expense of power.
None of these approaches is unique to NB-IoT, but its long sleep periods, lower data rate and potentially higher latency make the trade-off more visible.
UDP adds another complication. It does not create a durable, bidirectional connection in the same way as TCP. Mobile networks also commonly place devices behind carrier-grade NAT or private addressing. A server may therefore be unable to initiate a new UDP exchange directly with the device.
The application must usually arrange reachability itself, for example by having the device send first and keeping the resulting network mapping alive long enough to receive a response.
Once retries, acknowledgements, duplicate detection, message ordering and command queues are added, a simple UDP protocol can begin to resemble a transport protocol implemented inside the application.
CoAP helps, but the ecosystem is different
CoAP, the Constrained Application Protocol, was designed for constrained devices and networks. It brings a REST-like request-and-response model to small embedded systems and commonly runs over UDP.
CoAP includes useful concepts such as confirmable messages, retransmission, duplicate detection and observation of resources. It is much better than inventing an unstructured UDP protocol from scratch.
Lightweight M2M, or LwM2M, builds device-management functionality on top of CoAP. It defines standard ways to handle:
- Device registration
- Configuration
- Telemetry
- Firmware updates
- Security credentials
- Remote commands
- Device monitoring
Modern LwM2M is not restricted to UDP. OMA’s transport specification also defines CoAP over TCP, along with other bindings. Its original and most familiar deployment model, however, is CoAP over UDP with DTLS.
Technically, CoAP and LwM2M are well suited to constrained devices.
Practically, the development ecosystem may not feel as mature or as familiar as the alternatives built around HTTP and MQTT. Library availability varies between platforms, server choices are less familiar to many development teams, and diagnosing a stateful LwM2M exchange can be more involved than watching messages arrive at an MQTT broker.
That does not make LwM2M a poor protocol. It means its advantages come with an integration cost that should be included in the technology decision.
Why MQTT is so attractive
MQTT is popular because its operating model is easy to understand.
A device connects to a broker, publishes messages to topics and subscribes to topics from which it wants to receive commands. The broker handles routing between devices and applications.
MQTT normally operates over TCP, which provides an ordered, reliable, bidirectional byte stream. MQTT then adds its own session and delivery features, including selectable quality-of-service levels. See the OASIS MQTT 5.0 specification.
The ecosystem is mature:
- Embedded client libraries are widely available.
- Cloud platforms commonly support it.
- Brokers are easy to obtain and operate.
- Diagnostic tools are plentiful.
- Many engineers already understand it.
- Publish-and-subscribe communication fits telemetry and remote commands naturally.
A device can publish its latest measurement and remain connected briefly to receive queued instructions. Persistent MQTT sessions can also allow a broker to retain subscription state and hold messages while a client is disconnected.
This does not remove the fundamental reachability problem. A modem in deep sleep still cannot receive data, but MQTT gives developers a familiar framework for managing it.
The disadvantage is overhead.
TCP connection establishment, TLS negotiation and MQTT session setup may require several exchanges before useful application data is sent. On an NB-IoT link with high latency, packet loss or coverage repetitions, this can take considerable time and energy.
TLS can be especially expensive if a fresh handshake is required on every wake cycle. Session resumption and longer-lived connections can reduce that cost, but keeping a connection alive can conflict with the objective of returning to deep sleep as quickly as possible.
MQTT is therefore convenient, but it is not automatically efficient.
Low power depends on the whole transaction
It is tempting to compare LTE-M and NB-IoT using their advertised sleep currents.
That is rarely enough.
When the modem is in a deep power-saving state, both technologies can achieve extremely low current consumption. The larger difference often comes from what happens while the device is awake.
A useful comparison must include:
- Time required to find and register with a network
- Signal quality at the installation location
- Number of coverage repetitions
- Time required to establish security
- DNS lookup time
- TCP and application handshakes
- Payload size
- Retransmissions
- Time spent waiting for a server response
- Active-time and paging configuration
- Network release behaviour
- Frequency of firmware updates
A modem drawing very little current during sleep can still produce poor battery life if every upload keeps the radio awake for two minutes.
Conversely, LTE-M’s higher instantaneous data rate may allow it to complete a larger transfer and return to sleep sooner. For small messages in good coverage, NB-IoT may use less energy. For a firmware download or a multi-stage secure transaction, LTE-M may finish so much faster that it consumes less total energy.
The correct measurement is not peak current or even average connected current. It is energy per completed application task.
Mobility changes the decision
NB-IoT is best suited to stationary or mostly stationary devices.
LTE-M has better support for connected-mode mobility and handover between cells. That makes it the safer choice for trackers, vehicles and equipment that communicates while moving.
An NB-IoT tracker may work while travelling, depending on its modem and network, but cell changes can interrupt communication and force the device to reselect or reconnect. A technology being capable of reconnecting after movement is not the same as being designed for continuous mobile operation.
For a utility meter bolted to a wall, this difference is irrelevant.
For an asset tracker travelling through several coverage areas, it may be decisive.
Firmware updates expose the difference
A device may send only a few bytes per day during normal operation, making NB-IoT look like the obvious choice.
Then it needs a 500 KB firmware update.
At that point, data rate, latency, connection reliability and recovery from interrupted downloads become far more important. The update may take much longer over NB-IoT, particularly in enhanced-coverage conditions.
That extended radio time costs energy. It also creates more opportunities for the connection to fail.
Delta updates, resumable downloads and carefully sized blocks can make firmware updates practical over NB-IoT, but they require deliberate engineering. LTE-M provides considerably more breathing room.
The expected telemetry traffic should therefore not be the only input to the radio decision. Maintenance traffic across the complete product lifetime also matters.
Which should you choose?
Choose NB-IoT when the device is:
- Stationary
- Extremely power constrained
- Sending small and infrequent messages
- Primarily uplink driven
- Able to receive commands only during planned wake windows
- Deployed where maximum coverage depth is important
- Supported by confirmed NB-IoT roaming or local network agreements
- Using a protocol stack designed around intermittent connectivity
Choose LTE-M when the device:
- Moves between cells
- Requires lower latency
- Transfers larger payloads
- Needs frequent two-way communication
- Uses MQTT, HTTPS or another TCP-oriented protocol
- Requires substantial firmware updates
- Must respond within predictable time windows
- Benefits from a more familiar IP development ecosystem
There is also a strong argument for LTE-M when requirements are still evolving. It provides more performance headroom if message sizes grow, update requirements change or the product later needs more interactive behaviour.
Test the complete application, not just the radio
The best choice cannot be made from a comparison table alone.
Before committing, test both technologies using:
- The intended modem and firmware
- The actual SIM and connectivity provider
- The production protocol and security configuration
- Realistic payload sizes
- Poor-signal conditions
- Network loss and recovery
- Mobile operation, if applicable
- A full firmware update
- Real server response times
- The intended sleep and paging settings
Measure the energy required for a complete operation, from waking the modem to returning it to sleep.
Also confirm what the network actually supports. A module datasheet may list NB-IoT, TCP, PSM or eDRX without guaranteeing that every combination is supported by its firmware, the SIM provider and the visited network.
“Supported” at one layer does not mean the complete system will work as expected.
The simple answer
NB-IoT is technically elegant for devices that send tiny amounts of data and spend almost all their lives asleep. For that specific job, it can offer better coverage and potentially better battery life than LTE-M.
But most production devices need more than an efficient uplink.
They need remote configuration, acknowledgements, firmware updates, failure recovery and some form of two-way communication. UDP-based protocols such as CoAP and LwM2M can provide these features, but they may demand more specialist integration than familiar TCP-based systems built around MQTT.
LTE-M uses more bandwidth and offers less extreme coverage enhancement, but it is faster, more responsive, better suited to mobility and often easier to integrate with established cloud infrastructure.
The decision is therefore not simply, “Which radio uses less power?”
Which technology completes the device’s real work using the least energy, risk and engineering effort?
For a fixed sensor sending one reading a day, the answer may be NB-IoT.
For a product that must be remotely managed throughout its life, LTE-M is often the more practical choice, even when NB-IoT looks better on the datasheet.