Most teams know there are several ways to connect IoT devices. LoRaWAN, NB-IoT, LTE-M, 4G, 5G, and even satellite all show up in the same vendor pitches. The options are not a secret.
But teams often pick a network by hype, or by whatever a single vendor happens to sell. That is where projects go sideways. The wrong network choice is expensive, and it is slow to reverse once you have already shipped sensors into the field. Swapping radios after deployment means truck rolls, re-certification, and in some cases buying the hardware twice.
So the better approach is to compare networks by the factors that actually decide whether a project works: range, power and battery life, bandwidth and payload size, cost at scale, who owns the infrastructure, and latency. Then map those factors to your use case before you buy anything. This guide does that, and at the end it connects the network decision to the layer most teams forget about until late: the application platform that turns raw packets into something you can act on.
The factors that actually matter
Forget the marketing for a minute. When you strip a connectivity decision down, six things drive it.
Range. How far can a device sit from the nearest gateway or tower and still report reliably?
Power and battery life. Can the device run for years on a coin cell or a small battery, or does it need mains power or frequent recharging?
Bandwidth and payload size. How much data per message, and how often? A soil moisture reading is a few bytes. A camera feed is not.
Cost at scale. Not the cost of one device. The cost of a thousand or ten thousand, including connectivity subscriptions over the device lifetime.
Who owns the infrastructure. Do you rent coverage from a mobile operator, or do you build and own your own network?
Latency. How fast does a message need to get from the device to your system and back? Seconds are fine for most monitoring. Some control loops need sub-second response.
No single network wins on all six. That is the whole point. You are trading one against another.
LoRaWAN
LoRaWAN is a low-power, long-range protocol that runs on unlicensed spectrum. It is built for tiny messages sent infrequently.
Range is its headline strength. In open rural conditions you can see several kilometers from a single gateway, and in dense urban settings still a useful distance through buildings. Battery life is the other strength. A well-designed LoRaWAN sensor sending a few readings a day can run for years on a small battery.
The trade-off is bandwidth. Payloads are small, often tens of bytes, and duty-cycle rules limit how often a device can transmit. LoRaWAN is not for streaming, firmware-over-the-air at scale, or anything time-critical.
The big structural advantage is ownership. You can run a private LoRaWAN network using a stack like The Things Stack or ChirpStack, put up your own gateways, and pay nothing per message after the hardware. For a fixed site with many devices, that changes the cost math completely.
NB-IoT
NB-IoT (Narrowband IoT) is a licensed-spectrum, low-power standard operated by mobile carriers. It targets the same low-data, long-battery-life jobs as LoRaWAN, but over the carrier network rather than your own.
It handles deep indoor and underground coverage well, which is why it shows up in metering: water meters in basements, gas meters in pits. Battery life is good, in the range of years for low-frequency reporting.
The trade-offs are latency and ownership. NB-IoT was not designed for fast round trips, so it suits reporting rather than control. And because it runs on a carrier network, you pay a per-device subscription and you depend on that carrier’s coverage and roaming agreements. Coverage is also uneven by country and region, so check it for every market you plan to deploy in.
Cellular: LTE-M, 4G, and 5G
Cellular is the broad family. It splits by how much data and how much power you need.
LTE-M sits close to NB-IoT but supports more bandwidth, lower latency, and mobility (handoff between towers), which makes it good for asset tracking and wearables. Battery life is shorter than NB-IoT but still measured in months to years for many designs.
4G LTE is the workhorse when you need real bandwidth: gateways aggregating many sensors, connected vehicles, video at modest quality. Power draw is high, so these devices usually have mains power or large batteries.
5G adds high bandwidth and low latency, with the practical caveat that coverage and module cost are still maturing for many IoT use cases. Reach for 5G when you genuinely need its capacity or its latency, not because it is the newest.
Across all cellular, you are renting infrastructure from operators. That is convenient, you do not build anything, but you carry a per-device data cost for the life of the fleet.
Satellite, briefly
For sites with no terrestrial coverage at all, pipelines in remote terrain, offshore equipment, agriculture far from any tower, satellite IoT is now a real option. Newer low-earth-orbit services support small periodic messages at costs that were not viable a few years ago. Latency and per-message cost are higher than terrestrial networks, so treat satellite as the answer for the locations nothing else reaches, not as a default.
Side-by-side comparison
| Factor | LoRaWAN | NB-IoT | LTE-M | 4G LTE | 5G | Satellite |
|---|---|---|---|---|---|---|
| Range per node | Very long (km) | Long, deep indoor | Long | Cellular coverage | Cellular coverage | Global |
| Battery life | Years | Years | Months to years | Short (often powered) | Short (often powered) | Varies |
| Payload / bandwidth | Very small | Small | Small to medium | High | Very high | Very small |
| Latency | High | High | Medium | Low | Very low | High |
| Mobility | Limited | Limited | Good | Good | Good | Varies |
| Infrastructure owner | You (private) or public | Carrier | Carrier | Carrier | Carrier | Satellite operator |
| Cost model | Hardware, then near-zero per msg | Per-device subscription | Per-device subscription | Data plan | Data plan | Per-message, higher |
| Best for | Dense low-power sensing | Static metering | Tracking, wearables | Gateways, video | High-throughput, low-latency | Remote sites |
Use this as a starting filter, not a final answer. Coverage and pricing vary by country and carrier, so confirm both for your specific markets.
A decision framework by use case
Instead of starting from the network, start from the job.
Many fixed low-power sensors on one site or campus. Agriculture fields, a factory, a building. If you control the location and want to avoid per-device fees, a private LoRaWAN network with The Things Stack or ChirpStack is usually the strongest option. You own the coverage and the cost per message drops to near zero.
Static meters spread across a city. Water, gas, electricity. You do not control the locations and you need deep indoor reach. NB-IoT over a carrier is built for exactly this.
Things that move and report often. Fleet tracking, logistics, wearables. You need mobility and reasonable latency, so LTE-M fits well, with 4G as the step up when payloads grow.
Gateways, video, or real-time control. Anything bandwidth-heavy or time-critical needs 4G or 5G. Do not try to force this onto a low-power network.
Sites with no coverage. If there is no tower and no practical way to backhaul, satellite is the honest answer.
Where each network is the wrong choice
This is the part vendors skip, so here it is plainly.
If you need sub-second latency, or you are moving video and other high-bandwidth data, LoRaWAN is the wrong choice. It cannot carry that load and the duty-cycle rules will fight you. Use cellular instead, LTE-M for lighter real-time work and 4G or 5G when you need the bandwidth.
Going the other way: if you run a dense private campus with many tiny low-power devices and you want to own the network rather than pay a carrier per device forever, public cellular is the wrong choice. A private LoRaWAN network on The Things Stack or ChirpStack will usually beat it on total cost and give you control over coverage.
Picking the wrong side of either of these is the mistake that costs the most to undo.
The network is only half the project
Here is the part that gets decided too late. Whichever network you choose, the radio only moves bytes. It does not store your data, show it to anyone, alert someone when a reading goes out of range, or trigger an action. Those jobs live at the application layer.
That is where TagoIO fits. TagoIO sits above the connectivity layer. Once you have chosen your network, TagoIO ingests the data from LoRaWAN, NB-IoT, or cellular devices, stores it, visualizes it in dashboards, and lets you build alerts and automated actions on top. You can change or mix networks underneath without rebuilding your application, which matters because most real fleets end up mixing more than one.
If you are running a private LoRaWAN deployment, TagoIO connects to your network server and takes the data from there. If you are on a carrier, the data flows in over their connectivity. Either way, the platform stays the same.
To see how the ingestion side works, the device and data input documentation at https://docs.tago.io is the place to start, and you can size a deployment against the plans at https://tago.io/pricing.
The short version
There is no best IoT network, only the right one for a given job. Decide by range, power, payload, cost at scale, ownership, and latency, in that order of whatever matters most to your project. Use LoRaWAN for dense low-power sensing you want to own, NB-IoT for static metering, LTE-M and cellular for mobility and bandwidth, and satellite for the places nothing else reaches. Then put a platform on top so the data you worked to collect actually turns into decisions.
Get the network right before the sensors ship. It is the one choice that is genuinely hard to take back.
