Blog · August 4, 2026
NB-IoT or LTE-M: What is the difference, and when do you use which?
If you want to bring a battery-powered device onto the internet without Wi-Fi and without a gateway, you end up with two cellular standards: NB-IoT and LTE-M. Both are made for devices that transmit little and must last for years — but they are built for different cases. We have developed a series-production device that uses both; here is the distinction the way we apply it in practice.
What they have in common
NB-IoT and LTE-M run in licensed cellular spectrum — no gateway of your own, no radio planning of your own; the network belongs to the operator. Both support the two power-saving mechanisms that make long battery life possible in the first place: PSM (the device sleeps deeply while staying registered in the network) and eDRX (the device only listens at long intervals).
Where they differ
| NB-IoT | LTE-M | |
|---|---|---|
| Data rate | Very low — for sensor-sized reports | Considerably higher — enough for larger transfers, such as a firmware update in acceptable time |
| Latency | High, sometimes seconds | Low enough for interactive operations |
| Mobility | Meant for stationary devices — cell handover during operation is not its strength | Handles cell handover like regular LTE — for devices on the move |
| Building penetration | Very good — reaches basements and shafts | Good, but below NB-IoT |
| Voice | No | Possible (VoLTE), rarely needed |
The rule of thumb
NB-IoT when the device stays in one place, rarely reports small amounts of data, and needs to reach deep into buildings — the meter in the basement, the sensor in the shaft.
LTE-M when the device is moved, must respond promptly, or occasionally has to transfer something larger — and an over-the-air firmware update is exactly such a transfer. An update that would take impractically long over NB-IoT transfers in a fraction of the time over LTE-M.
In our series-production case that was precisely the deciding factor: the device — a sensor module carried around inside buildings — reports its data sparingly but must be updatable in the field and must cope with changing location. The connectivity uses both standards; the module takes what the local network offers. Planning both paths from the start paid off twice: in network coverage abroad and in the update path.
Three things to check before committing
- Coverage at the actual deployment sites. Availability of the two standards differs by country and by operator — what works at home may be missing at your customer's site. Verify with the operator, do not trust coverage maps.
- Roaming. If you ship internationally, you need a contract that covers both standards in the target country — that is contract work, not engineering.
- The firmware update. If it is to come over the air, the transfer time per standard belongs in the calculation — before the module is chosen, not after.
What about you?
Are you facing the choice right now — or is there a device in the field where you would decide differently today? Write to us; we are collecting the cases.
Transparency note: This article was written with the help of artificial intelligence and reviewed by the author before publication. The review applies to the German original; this English version is a translation.