LTE-M vs NB-IoT

Written By Greg Terrell

Which fits your product?
A comparison for engineers choosing a cellular IoT protocol — coverage, power draw, data rates, typical use cases for each.

If you're reading this, you've probably already ruled out 2G. You had to — T-Mobile shut down the last GSM network in the US on August 3, 2026, following AT&T (2017) and Verizon (2020), which means every 2G-based IoT device in the country is now dead weight. Whatever you're designing next needs a home on LTE-M or NB-IoT, and that choice is harder to reverse than it looks. Both are Low Power Wide Area (LPWA) standards built into LTE, both run on the same carrier networks, and both get lumped together in spec sheets as if they're interchangeable. They aren't. They trade off coverage, power, and speed in different directions, and picking the wrong one means a board respin down the line.

Here's how the two actually compare, and how to tell which one your product needs.

The short version

LTE-M is the better fit when your device needs to talk in something close to real time, sends more than a few bytes per message, or might need voice fallback. NB-IoT is the better fit when your device reports small amounts of data infrequently and needs to run for years on a coin cell or a small battery pack — and contrary to the old rule of thumb, it doesn't have to sit still to do that; plenty of NB-IoT asset trackers are out there moving around. The mobility question that actually matters is roaming: does the device need a live, uninterrupted connection while crossing cells or borders, or can it wake up, send, and go back to sleep wherever it lands? If your product doesn't cleanly fall into either bucket, the safest move is a modem that supports both and lets you decide (or switch) in firmware rather than in hardware.

Coverage

Both standards were designed for the same problem — reaching devices in basements, meter pits, and rural fringe areas where regular LTE can't get a signal — and both do it by repeating transmissions and narrowing bandwidth to concentrate power. On paper, NB-IoT has a slight edge: its 3GPP-specified maximum coupling loss (MCL) is consistently cited at 164 dB, roughly 14 dB better than plain LTE. LTE-M's baseline Cat-M1 figure is usually put around 156 dB, though newer, 5G-aligned evaluations of LTE-M report it closing the gap to that same 164 dB. Published numbers vary a fair amount between vendors and evaluation conditions, and in practice, field testing tells a messier story — several independent tests have found LTE-M holding up just as well, and sometimes better, than NB-IoT at real-world distances, because coupling loss on paper doesn't fully capture how carriers actually tune their networks. Treat the dB figures as a rough guide, not gospel, and if coverage in a specific location is make-or-break for your product, test both on-site before committing.

What if terrestrial coverage isn't enough?

If your device might land somewhere with no cell tower at all — remote agriculture, pipelines, maritime, backcountry assets — satellite is worth factoring in now rather than retrofitting later. 3GPP standardized satellite IoT in Release 17 as NTN (Non-Terrestrial Network), and the commercial rollouts built on it so far — Skylo's network among them, which several carriers and IoT platforms now resell — run on NB-NTN: essentially the NB-IoT waveform adapted for a satellite link. That's not a coincidence. Satellite links are even more bandwidth- and power-constrained than terrestrial LPWA, so NB-IoT's small, infrequent, delay-tolerant message pattern (Skylo's own limits run around 256 bytes per message, roughly one message every 30 seconds to a couple of minutes) maps naturally onto what a satellite hop can carry. An eMTC/LTE-M NTN variant exists in the standard too, but NB-NTN is what's actually shipping in commercial satellite IoT service today. Practically, this means if satellite fallback is on your roadmap, an NB-IoT-capable device has a shorter path to it than an LTE-M-only one — and it's part of why LooUQ's MTC2-N9151, built on the Nordic nRF9151, carries Skylo satellite certification alongside its terrestrial LTE-M/NB-IoT modes.

Data rate and latency

This is where the two standards diverge the most. LTE-M was built to carry meaningful payloads: Cat-M1's 3GPP peak spec is around 1 Mbps in each direction, but that's a ceiling, not what you should design around — real-world throughput typically lands in the 200–400 kbps range, since Cat-M1 is half-duplex and adaptive modulation backs off well below peak under normal network conditions. Cat-M2 (Release 14) raises the ceiling further, to roughly 4 Mbps downlink and 7 Mbps uplink, though field throughput scales down from that peak the same way. Latency is low enough — often well under a second, sometimes down to tens of milliseconds — that LTE-M can handle firmware-over-the-air updates, image or audio snippets, and anything that feels closer to a normal cellular connection.

NB-IoT is deliberately narrow. Cat-NB1 tops out around 26 kbps downlink, and Cat-NB2 improves that to roughly 127 kbps downlink and 159 kbps uplink — enough for a handful of sensor readings, not enough for much else. Latency is also higher, typically ranging from a couple of seconds to 10+ seconds depending on network conditions and how aggressively the device sleeps between transmissions. NB-IoT was never meant to feel responsive; it was meant to be cheap and durable.

Power consumption

Both protocols lean on the same two power-saving tools: PSM (Power Saving Mode), which lets a device drop into a near-zero-power sleep state between check-ins, and eDRX (extended Discontinuous Reception), which stretches how often it needs to wake and listen for the network. Used well, either standard can deliver multi-year battery life.

The nuance is in how they get there. NB-IoT's simpler radio and smaller payloads mean lower peak current draw, which tends to win out for the classic "one tiny reading, once a day" workload — a water meter, a soil moisture sensor, a leak detector. LTE-M draws more current while it's transmitting, but it also finishes transmitting faster because it has more bandwidth; for payloads with more than a few bytes, or devices that report more than a few times a day, that shorter radio-on time can actually make LTE-M competitive or even better on average power. The rule of thumb: NB-IoT wins on power for small, infrequent, static payloads; LTE-M closes or reverses that gap as payload size and reporting frequency increase.

Mobility, roaming, and voice

Mobile NB-IoT devices are common — asset trackers on NB-IoT ship in real deployments, including ones that cross national borders on a single roaming SIM. The real distinction isn't "can it move," it's how it moves. LTE-M's mobility management is closer to standard LTE: it can maintain a live, connected session while actively moving between cells, which suits anything that needs continuous, real-time tracking mid-transit. NB-IoT devices typically operate in bursts — wake, connect, transmit, sleep — and reselect whichever cell is available each time they wake, rather than holding one connection through a handover. For a tracker that just needs a location ping every so often, that's a non-issue. For something that needs to stream a live position feed while in motion, it matters. Roaming coverage is a separate, carrier-by-carrier question for both protocols — worth checking directly against the countries and networks your device will actually travel through, since agreements and coverage still vary more than either protocol's spec sheet suggests. LTE-M also supports VoLTE, so it's the only one of the two that can carry a voice call — relevant for panic buttons, alarm panels, and any device that needs a human-audible fallback.

Cost

There are two separate cost lines to weigh here, and it's easy to only budget for one. The first is hardware: NB-IoT chipsets and modules are generally cheaper than LTE-M ones, thanks to a simpler RF front end and lower bandwidth requirements. At scale — thousands or millions of units — that per-unit difference adds up fast, which is part of why NB-IoT dominates utility metering, where margins are thin and device counts are enormous.

The second, easy to overlook, is the ongoing connectivity plan. Both LTE-M and NB-IoT sit in carriers' "massive IoT" pricing tiers, and both are typically far cheaper per connection than a standard LTE (Cat-1/Cat-4) SIM plan — some MVNOs even price them under the same flat, multi-year, low-data plan. Within that tier, NB-IoT plans tend to run cheaper still than LTE-M ones, in line with its smaller data allowances and simpler network footprint, though the gap and the actual dollar figures vary a lot by carrier and volume commitment. If you're weighing LTE-M or NB-IoT against just staying on standard LTE post-2G-sunset because the modules feel more familiar, the line cost — not just the module price — is usually the bigger factor over a multi-year deployment. Get quotes from your actual carrier or MVNO before committing either way; published rate cards move often and vary by region and commitment volume.

Side-by-side

LTE-M NB-IoT
Data rate ~200–400 kbps typical (Cat-M1; 1 Mbps peak spec); higher on Cat-M2 (~4/7 Mbps DL/UL peak) ~26 kbps (Cat-NB1); up to ~127/159 kbps DL/UL peak (Cat-NB2)
Latency Low — often <100 ms Higher — roughly 1.6–10+ seconds
Max coupling loss ~156 dB baseline; up to 164 dB on 5G-aligned evaluations 164 dB
Handover while connected Yes — live connection can move between cells No — reselects a cell each time it wakes; fine for burst reporting, not continuous tracking
Roaming Generally broader, more mature support Improving, but check carrier coverage for your specific routes/borders
Voice (VoLTE) Yes No
Power profile Best for moderate/frequent payloads Best for tiny, infrequent payloads
Typical battery life Multi-year, workload-dependent Multi-year, often the longer of the two for minimal payloads
Module/chipset cost Higher Lower
Connectivity plan cost Lower than standard LTE, higher than NB-IoT Cheapest of the three, in the same "massive IoT" tier as LTE-M
Satellite (NTN) fallback Standardized (eMTC-NTN) but rarely deployed commercially yet NB-NTN is what's actually shipping (e.g., Skylo)
Best-fit device class Real-time/continuous tracking, higher-bandwidth, voice fallback Burst reporting (static or mobile), low-bandwidth, cost-sensitive

When LTE-M is the right call

Reach for LTE-M when your device needs a continuous connection while it's actually moving (live fleet tracking, in-transit telematics, wearables reporting in near-real-time), when it needs to send more than a trivial payload (image snapshots, diagnostic logs, larger telemetry batches, OTA firmware updates), when responsiveness matters (POS terminals, alarm panels, anything a person is actively waiting on), or when you need a voice fallback. It's also the safer bet in the US right now — LTE-M has strong support across all three national carriers, while NB-IoT's US buildout has been more uneven than its footprint in Europe and Asia.

When NB-IoT is the right call

Reach for NB-IoT when your device reports small amounts of data on a slow, bursty cadence — whether or not it moves in between. That covers the classic static cases (water, gas, and electric meters, environmental and soil sensors, smart parking and waste-bin sensors) as well as mobile ones that don't need a live connection in transit, like asset tags that wake up periodically to report a location. If you're deploying at massive scale and every cent of module cost matters, or if the device needs to survive a decade on a single battery with minimal servicing, NB-IoT is usually the more economical fit — provided your carrier has solid NB-IoT coverage, and roaming agreements if relevant, where the devices will actually operate.

Don't want to choose yet? You don't have to.

A growing number of modules — including LooUQ's own MTC.2 and LTEm lines — support both LTE-M and NB-IoT on the same hardware, so the network mode becomes a firmware and SIM provisioning decision rather than a board-layout decision. That's especially useful if you're migrating off 2G/3G under deadline pressure and don't have time for a full field study before you commit, or if your product line covers both static and mobile deployments and you'd rather standardize on one module SKU. You can ship now on whichever protocol clears your immediate coverage and power targets, and adjust in software as you learn more from the field.

The practical checklist

Before you lock in a protocol, get straight answers to five questions: does the device need a live connection while it's moving, or just a periodic burst wherever it happens to be; how many bytes does it send and how often; how long does it need to run unattended on its power source; what does coverage and roaming actually look like — measured, not modeled — at the deployment sites and routes that matter most; and could this device ever end up somewhere with no terrestrial signal at all. Those five answers will point you to LTE-M or NB-IoT far more reliably than any spec sheet comparison, including this one.

Sources:

Greg Terrell
Next

SWD: You have options