Every LPWAN decision we've been pulled into starts the same way: someone has a working prototype on Wi-Fi, a pilot deployment planned for a few hundred devices, and a spreadsheet with three columns labelled LoRaWAN, NB-IoT and LTE-M. The columns are usually filled in from vendor datasheets, which is exactly the problem. Datasheets tell you what the radio can do in a lab. They don't tell you whether your device will get a message out of a basement meter room in Manchester, or whether the operator in Riyadh has switched on the band your module supports.
So this is the comparison we'd actually walk you through in a technical call — what each technology is good at, where each one quietly fails, and the four or five questions that usually settle the argument before you get to the radio specs at all.
What you're really choosing between
These three are often listed as peers. They aren't. Two of them are 3GPP cellular standards running on licensed spectrum owned by mobile operators. One is an open specification running on unlicensed spectrum that you can deploy yourself. That single distinction shapes almost everything downstream — cost model, coverage risk, who you depend on, and how long certification takes.
LoRaWAN
LoRa is a chirp spread-spectrum physical layer in sub-GHz unlicensed bands — 868 MHz in Europe, 915 MHz in the US, other allocations elsewhere. LoRaWAN is the MAC layer and network architecture on top: end devices talk to gateways, gateways forward everything to a network server, and the network server handles deduplication, adaptive data rate and keys. Data rates run roughly 0.3 to 50 kbps depending on spreading factor. Payloads are small — from around 51 bytes at the slowest settings up to about 222–242 bytes at the fastest, and regional duty-cycle rules (1% per sub-band in much of Europe) cap how often you can transmit at all.
NB-IoT (Cat-NB1/NB2)
NB-IoT occupies a single 180 kHz carrier and was designed for one thing: getting a few hundred bytes out of a difficult location on a battery. It trades throughput for link budget, using message repetitions to claw back roughly 20 dB of coverage over legacy GSM. Practical throughput is tens of kbps. Latency is measured in seconds, not milliseconds. Early releases had no connected-mode handover, so it was never intended for fast-moving assets.
LTE-M (eMTC, Cat-M1)
LTE-M uses 1.4 MHz, delivers a few hundred kbps up to around 1 Mbps depending on release and duplex mode, supports proper handover between cells, and can carry voice. It's the middle child: more capable than NB-IoT, far cheaper in power and module cost than full LTE. If your device moves, needs sub-second responsiveness, or needs to pull down firmware images, LTE-M is usually where the cellular conversation lands.
Coverage: the only spec that matters on day one
A device that can't reach the network has no power budget and no data rate. Coverage is where deployments die, and it fails differently for each technology.
- LoRaWAN coverage is yours to fix. If a site is dead, you add a gateway. Rural line-of-sight links of 10–15 km are realistic; dense urban ranges of 1–3 km are more typical, and deep indoor coverage often needs a gateway inside the building. The upside is total control. The downside is that you now own site access, mounting, power and backhaul for every gateway.
- NB-IoT coverage is the operator's to fix, and you cannot fix it. Where it's properly deployed, its indoor and sub-grade penetration is the best of the three — basements, meter cupboards, underground chambers. Where the operator hasn't lit up NB-IoT in that band, or in that country, you have nothing.
- LTE-M coverage tracks the operator's LTE footprint with roughly 15 dB of extra link budget. Broadly excellent outdoors, weaker than NB-IoT at the extreme edge of the cell or three floors down.
Regional availability is the trap. Broadly, North American carriers pushed LTE-M first, several European and Middle Eastern operators pushed NB-IoT first, and plenty of markets now have both — but coverage, roaming agreements and supported bands vary per operator, per country and per year. Never take a global coverage map as fact. Get test SIMs, get a modem, and drive the actual sites. We've seen a two-week field survey change a whole architecture, and it was cheap at the price.
Power: run the arithmetic, not the marketing
All three claim ten-year battery life. All three can achieve it, and all three routinely miss it, because battery life is set by your duty cycle and your protocol overhead — not by the radio's headline sleep current.
Some rough physics to anchor the estimate. A LoRa uplink at 14 dBm draws roughly 30–45 mA while transmitting. At the fastest spreading factor a short payload is on air for tens of milliseconds; at the slowest it can be well over a second for the same bytes. That's a 20x-plus swing in transmit energy caused purely by link quality, which is why gateway placement is a battery-life decision, not just a coverage decision.
Cellular modules have higher peak currents — commonly a few hundred milliamps — and, more importantly, session overhead. Waking from Power Saving Mode, reattaching, running security procedures and getting an acknowledged message out can take several seconds of radio-on time even for a 20-byte payload. Get eDRX and PSM timers wrong, or let the modem sit in connected mode after each report, and you'll burn a year of budget in a month. Two practical consequences:
- For very infrequent, tiny, uplink-only reports — a water meter reading once a day — LoRaWAN usually wins on energy per message, sometimes by a wide margin.
- For anything that needs acknowledgements, downlink control or occasional larger transfers, the gap narrows fast, and LTE-M's faster transmit can offset its higher peak draw.
- Sleep current dominates for very low duty cycles. If your device reports twice a day, the modem's 2 µA versus 8 µA idle draw matters more than anything else in the datasheet.
Data rates, payloads and the firmware update problem
This is the question teams underestimate most. Ask not "how much data do I send?" but "how do I fix a bug in the field in three years?"
LoRaWAN is not a firmware delivery mechanism in any practical sense. Multicast FUOTA exists in the specification, but pushing a 200 KB image over a duty-cycle-limited link to battery devices is a multi-day operation with real failure modes. If you choose LoRaWAN, design as though the application firmware is nearly frozen: keep the payload format versioned, keep configuration parameters changeable over a couple of downlink bytes, and put your complexity in the server, where you can redeploy it on a Tuesday afternoon.
NB-IoT can do FOTA, slowly and painfully — it's usually a delta-update-and-patience exercise. LTE-M handles firmware updates comfortably, which is often the single strongest argument for it. If your device is a controller rather than a sensor, or the product roadmap expects new features after shipping, that changes the calculus more than any power figure.
What it actually costs
Compare total cost over the deployment lifetime, not bill of materials. The shapes of the two cost curves are completely different.
- LoRaWAN: cheap modules, no per-device subscription if you run your own network, but real capex and operations in gateways, backhaul, site access and a network server (self-hosted ChirpStack, a community network, or a commercial platform). Cost per device falls as you scale; cost per site does not.
- Cellular: no infrastructure to own, but a SIM or eSIM and a data plan per device forever. IoT tariffs for small monthly payloads are typically low single-digit dollars per device per year at volume, higher for small fleets — get written quotes, because the spread between operators and aggregators is large.
- Certification: this one surprises people. Cellular devices generally need regulatory approval plus GCF/PTCRB and often carrier-specific acceptance. Budget weeks to months of calendar time and a meaningful test-lab bill. Using a pre-certified module with an approved antenna reference design cuts this down dramatically. LoRaWAN has optional certification and no carrier gatekeeper — for a small fleet on a private network, that alone can decide it.
A rough rule of thumb: at a few hundred devices spread across many sites, cellular usually wins on total cost. At thousands of devices concentrated on a campus, factory, farm or utility network you control, LoRaWAN usually wins — and keeps winning, because you're not renting the network.
Mobility, latency and control
If your asset moves at vehicle speed and needs continuous connectivity, LTE-M is the straightforward answer — it's the only one of the three with proper connected-mode handover. LoRaWAN handles nomadic mobility acceptably, since any gateway that hears the device can forward the frame, but built-in geolocation is coarse and downlink to a moving Class A device is unreliable. NB-IoT is fine for devices that are stationary or move slowly between reports; it was never designed for anything else.
On latency: LoRaWAN Class A devices only receive during short windows after an uplink, so command-and-control means waiting for the device to check in. Class C removes that at the cost of much higher power, which usually means mains power. NB-IoT latency lands in the seconds. LTE-M can be sub-second in connected mode. If a human is going to press a button and expect something to happen, plan accordingly.
The decision path we use
In order, because the early answers tend to eliminate options outright:
- Where, physically, will the devices sit — and can you get a gateway within range? If you control the sites, LoRaWAN is on the table. If devices scatter across a country in places you'll never visit, it isn't.
- Does it move, and does it need low-latency downlink? Yes to either, and you're looking at LTE-M.
- What's in the field survey? Test the actual bands and operators at the actual sites. This kills more assumptions than any other step.
- What's the realistic message profile — bytes, frequency, acknowledgement needs? Now the power arithmetic becomes meaningful.
- How will you update firmware and rotate keys over ten years?
- Then, and only then, total cost of ownership at your target fleet size.
And a hybrid is often the honest answer. We've seen sensible designs where battery sensors speak LoRaWAN to a mains-powered gateway that carries an LTE-M backhaul, giving you cheap dense sensing plus a reliable managed path to the cloud. It's more moving parts, but it puts each technology where it's strong.
When none of these is right
Worth saying plainly, because the answer is sometimes "don't use LPWAN":
- If devices are mains-powered and sit near infrastructure, Wi-Fi or Ethernet is cheaper, faster and less work than any of the above.
- If you need images, audio or high-frequency telemetry, LPWAN will fight you the whole way. Look at LTE Cat-1 bis or 5G RedCap instead.
- For very short-range personal or building devices, BLE or Thread with a gateway is usually the better fit.
- For remote sites with no terrestrial coverage at all, satellite NB-IoT over 3GPP non-terrestrial networks is maturing and worth a look before you write off the site.
Finally, remember that the radio is the small part of the project. The network server, device provisioning and key management, payload decoding, time-series storage, alerting and the dashboards people actually use will consume more of your budget than the modules — and if you plan to do anomaly detection or predictive maintenance on the resulting data, that's a separate design exercise with its own data and model requirements.
If you're at the point of choosing between these three and want a second pair of eyes on the field survey plan, the power budget or the backend architecture, get in touch and tell us about the deployment. If you'd rather add embedded and backend capacity to a team you already have, we also work as an embedded and integrated engineering team alongside in-house engineers.
