LoRaWAN vs NB-IoT vs Cellular for Remote IoT Telemetry

The decision is two budgets, not one chip

The most expensive connectivity mistakes we see in remote telemetry do not come from picking the wrong radio. They come from costing the wrong thing. A team benchmarks data rate and range, picks a module, and ships — then a year later the recurring SIM bill dwarfs the entire hardware BOM, or a LoRaWAN deployment stalls because nobody budgeted for the gateway, its solar power, and its backhaul.

So the framing for lorawan vs nb-iot vs cellular is not "which chip wins." It is two budgets that fail for different reasons:

• One-time infrastructure cost — the gateway you may have to own, its antenna and mast, its off-grid power, and the backhaul carrying its traffic. Mostly a LoRaWAN concern.
• Recurring data cost — the per-device SIM and data plan you pay every year, forever, times every node in the fleet. The cellular and NB-IoT concern.

Confuse these two and the cheapest-looking option becomes the most expensive deployment. This guide is built from what GizanTech has actually shipped: LoRaWAN gateways feeding off-grid sensor clusters, GSM/GPRS nodes on legacy networks, and newer NB-IoT and LTE-M telemetry where carrier rollout supports it.

The connectivity comparison table

The numbers below are directional, not datasheet-exact — power and cost vary by module, region, plan, and message size. Treat the ranges as the shape of each trade-off, and verify specifics for your country and carrier before committing a fleet.

A few rows drive most decisions. LoRaWAN is the only option here where you may have to build and own the infrastructure — and the only one whose recurring cost can approach zero. NB-IoT and LTE-M move that cost to a yearly per-SIM plan but need zero infrastructure, if the carrier covers your site. 2G is here only because it still works where nothing newer reaches — never a greenfield choice.

LoRaWAN: cheapest to run, but you own the coverage problem

LoRaWAN's defining feature is that its recurring cost can be near zero. Once a gateway is up, every node in range uploads through it, and you pay for data only once — on the gateway's backhaul — instead of once per device. For a dense cluster of low-rate sensors around a farm, plant, reservoir, or building, nothing beats it on running cost.

The catch teams forget to budget: LoRaWAN needs a gateway, and in remote sites that gateway is yours to deploy, power, and connect. You can join a public or community network where coverage exists, but the whole reason you are doing remote telemetry is usually that none exists out there. So a real LoRaWAN site is rarely just "a gateway." It is:

• A gateway with a clear line-of-sight antenna and mast.
• Off-grid power — solar plus a battery sized for the worst-case overcast stretch. In Bangladesh's monsoon, undersizing that battery is a classic field failure: the gateway browns out during the days you most need data.
• A backhaul uplink — cellular, fibre, or satellite — to your server. That uplink is a recurring cost, so LoRaWAN concentrates the recurring bill into one line per gateway instead of one per node.

The failure LoRaWAN prevents is the runaway per-SIM bill at scale. The failure it introduces is a single point of failure: if the gateway, its power, or its backhaul dies, every node behind it goes dark at once. We design gateway sites for that blast radius — redundant backhaul or store-and-forward on the nodes — not fire-and-forget.

NB-IoT: no gateway, but coverage is the carrier's decision

NB-IoT flips the LoRaWAN trade-off. You deploy no infrastructure — nodes talk straight to the mobile network's towers — and you pay a low per-SIM data plan. For nodes scattered one-per-location, where you could never justify a gateway each, this is often the only economic option. NB-IoT also penetrates deep indoors and underground better than the alternatives, which is why it shines for utility meters in basements and pits.

The gotcha is brutal and outside your control: NB-IoT only exists where the local carrier has rolled it out. Coverage depends on the carrier deploying NB-IoT on their network, in your country, in the specific rural and industrial zones where your nodes live — exactly where rollout is thinnest. We have seen carriers advertise nationwide NB-IoT that evaporates at the site. Designing a whole fleet around a radio that has no signal on the ground is one of the most expensive mistakes possible, because it is discovered after the hardware ships.

Before committing a fleet to NB-IoT:

1. Get written carrier confirmation of NB-IoT band support and tower coverage for each deployment site — not a national marketing map.
2. Confirm the module supports the exact bands that carrier uses in your country.
3. Field-test a real device on a production SIM, at the real install location, across a full day.
4. Have a fallback radio (LTE-M or a LoRaWAN gateway) in the design before mass production, so a coverage surprise is a config change, not a respin.

LTE-M: the mobility and OTA middle ground

LTE-M (Cat-M1) sits between NB-IoT and full cellular. It carries hundreds of kbps, supports mobility and handover (so it works on moving assets where NB-IoT struggles), and tolerates larger payloads — enough for practical firmware OTA. Its per-message energy lands between NB-IoT and full LTE: better than 2G, heavier than LoRaWAN.

Pick LTE-M when nodes move (anything that hands between towers), when you need a few kbps rather than a trickle, or when you want robust over-the-air firmware updates. As with NB-IoT, it is a carrier-coverage decision — confirm LTE-M specifically, since a carrier may have one and not the other. Many cellular IoT modules support both, which is the pragmatic hedge: design for the dual-mode module so the field decides which network it attaches to.

2G / GSM-GPRS: legacy only, and a sunset clock

We still run GSM/GPRS nodes in the field, so this is not theoretical. 2G's one remaining advantage is mature, wide coverage where NB-IoT and LTE-M rollout is incomplete — including parts of South Asia where a GPRS node simply works when nothing newer does.

But 2G is the worst option on power: the modem has no modern sleep modes like PSM or eDRX and stays power-hungry, which wrecks battery life for the once-a-day node. Worse, 2G networks are being switched off region by region, so every new 2G deployment ships with a sunset clock attached. The only honest reason to choose it today is a site with no NB-IoT, no LTE-M, and no way to host a LoRaWAN gateway — and even then, design the node so its radio module can be swapped without redoing the whole board.

A decision procedure that costs both budgets

Run these in order and stop at the first one that forces the choice:

1. Map node density against sites you control. Many low-rate nodes clustered around a site you own → LoRaWAN; price one gateway (plus power and backhaul) against the cluster. One node per scattered location → a gateway-free cellular/NB-IoT option is usually cheaper.
2. Confirm carrier coverage on the ground, per site. For any NB-IoT or LTE-M plan, get written band-and-tower confirmation and field-test before committing. No confirmed coverage means the option is off the table, however good on paper.
3. Set the data-rate and mobility floor. Trickle of bytes, stationary → LoRaWAN or NB-IoT. Moving asset, or a few kbps and real OTA → LTE-M. Almost never 2G unless nothing else reaches.
4. Build the two budgets explicitly. One-time: gateway + antenna + off-grid power + backhaul. Recurring: per-SIM plan × node count × years. The cheapest chip with the most expensive recurring bill is not the cheapest deployment.
5. Design in a radio fallback. Use dual-mode NB-IoT/LTE-M modules and a board that tolerates a module swap, so a coverage surprise or a network sunset is a rework change, not a full respin.

When to bring in an engineering partner

The radio is the easy part. The expensive, irreversible parts of remote telemetry are the ones this guide keeps returning to: an off-grid power budget that survives the worst week of local weather, a gateway whose blast radius does not take the whole fleet down, a carrier-coverage assumption that was field-verified before mass production, and a node that can swap radios when a network sunsets. GizanTech designs the node hardware, writes the firmware, and specs the gateway and backhaul as one system — so the trade-offs above are decided once, against the real deployment picture, not discovered after the units ship. If you are scoping a remote telemetry fleet and want the LoRaWAN-versus-cellular decision validated before you commit, talk to our engineering team.

Frequently asked questions

Which is cheapest to run at 500 remote nodes: LoRaWAN, NB-IoT, or cellular?

At 500 nodes clustered around sites you control, LoRaWAN is almost always cheapest to run because the recurring cost is near zero once you own the gateways — the data rides your own backhaul. NB-IoT and cellular each carry a per-device SIM and data plan every year, so 500 nodes means 500 recurring line items regardless of how little data each sends. The break-even depends on density: if the nodes are scattered one-per-remote-location with no shared gateway, the LoRaWAN gateway capex per node explodes and a low-cost NB-IoT plan often wins. Cost the gateways and the SIMs as two separate budgets and the answer falls out.

Do I need to deploy my own gateway for LoRaWAN, and what does that cost?

You need a LoRaWAN gateway in range of your nodes, but it does not have to be yours — you can join a public or community network (such as The Things Network) where coverage exists, or pay a managed network operator. In remote and industrial sites there usually is no existing coverage, so you deploy and own the gateway. Budget for the gateway hardware, a mounting and antenna with clear line of sight, power (often solar plus battery off-grid), and a backhaul uplink (cellular, fibre, or satellite) to reach your server. That backhaul is itself a recurring cost, so a LoRaWAN site is not truly free to run — it concentrates the recurring cost into one uplink instead of one-per-node.

Is NB-IoT available everywhere, or does it depend on the local carrier?

NB-IoT availability depends entirely on the local carrier rolling it out on their network in your country and your specific deployment area — it is not a given. Many regions have strong NB-IoT, others have none, and some carriers advertise it nationally but have gaps in exactly the rural and industrial zones where remote telemetry lives. Before you commit a fleet to NB-IoT, get written confirmation of band support and tower coverage for each deployment site from the carrier, and field-test with a real device on a real SIM. Designing for NB-IoT and discovering no coverage on site is one of the most expensive connectivity mistakes you can make.

Which connectivity option gives the longest battery life for a once-a-day telemetry node?

For a node that wakes once a day, sends a small reading, and sleeps, LoRaWAN typically gives the longest battery life because the radio is on for the shortest time per message and draws the least energy to transmit. NB-IoT can also run for years on a battery thanks to PSM and eDRX power-saving modes, but its attach and transmit bursts are more energy-hungry than a LoRaWAN uplink. LTE-M sits between NB-IoT and full cellular, and 2G/GPRS is the worst because it has no modern sleep modes and a power-hungry always-listening modem. Beyond the radio, sleep current and a clean power-down sequence usually decide whether you hit multi-year life.