Most IoT connectivity decisions get made backwards. A team picks a radio because it is cheap, or because a chip vendor’s dev kit made it easy to prototype with, and only discovers the constraint it actually needed to solve for once the first hundred units are in the field. By then the protocol is baked into the hardware, the certification, and the firmware update path. Changing it means a second product.
The choice between LoRaWAN, cellular IoT (NB-IoT or LTE-M), and plain Wi-Fi or Ethernet is not really a technology question. It is a question about who controls the site the device lives on, how much power it has to spend, and how much data it genuinely needs to send. Get those three answers first, and the radio picks itself.
The question that decides everything else: who controls the site
If every device in the fleet lives somewhere you or your customer already controls, a warehouse, a farm, a fleet of company-owned vehicles that return to a depot, a building you can wire, you have the option of running your own network. That is the case for LoRaWAN gateways or plain Wi-Fi: no operator in the middle, no SIM inventory, no roaming agreements, no per-device data plan to manage for the life of the product.
If the device ships to a customer’s site you have never seen and will never install infrastructure at, a consumer product, a piece of equipment sold through distributors, an asset tracker that goes wherever the asset goes, you need connectivity that already exists everywhere. That means cellular. NB-IoT and LTE-M ride on networks a mobile operator already built and maintains; you are buying access to it, not building it.
This one question eliminates most of the debate before you get to data rates or power budgets, because it decides whether you are running infrastructure or renting it.
Wi-Fi and Ethernet: still the right answer for a lot of fleets
It gets overlooked because it is not marketed as an IoT technology, but if the device is mains-powered and sits somewhere with existing network coverage, a retail unit, an office, a factory floor already on Wi-Fi, plain Wi-Fi or a wired connection is usually the least risky option. Bandwidth is not a constraint, latency is not a constraint, and firmware updates are trivial to push. The trade-off is that it depends entirely on infrastructure you do not control at the customer’s site, which means your support burden includes their network configuration, guest VLANs, and captive portals. For a product that lives in a building you operate yourself, that trade-off barely matters.
LoRaWAN: your own network, at a bandwidth cost
LoRaWAN runs on unlicensed spectrum, which is what makes it attractive: no operator contract, no per-device SIM cost, and gateways cheap enough that a single site can be covered for the price of a few access points. Devices can run on battery for years because the protocol is built around sending very little data, very rarely, at very low power.
The catch is exactly that trade-off in reverse. Bandwidth tops out low enough that pushing a firmware update over the air to a device with a marginal signal can take an uncomfortably long time, and range comes at the direct cost of data rate. If your payload is a handful of sensor readings every few minutes, temperature, soil moisture, tank level, door open or closed, LoRaWAN fits well. If you are going to want to send diagnostic logs, images, or frequent telemetry once the product matures, you will hit the ceiling and regret the choice. We have written separately about shipping OTA updates without bricking a fleet; on LoRaWAN, the update mechanism has to be designed around the bandwidth from day one, not retrofitted.
Cellular: NB-IoT and LTE-M are not the same decision
Both ride on licensed mobile networks and both are built for IoT rather than repurposed from handset connectivity, but they solve different problems.
- NB-IoT is built for static, low-throughput, power-constrained devices, utility meters, environmental sensors, anything that sends a small payload occasionally and needs to run on a battery for years. It does not support handover between cell towers, so it is a poor fit for anything that moves.
- LTE-M supports mobility and handover, has meaningfully higher throughput, and lower latency, which makes it the sensible choice for anything on a vehicle, anything that needs occasional voice fallback, or anything where you might want to stream more data later without a hardware redesign. It costs more in power and typically in tariff than NB-IoT.
The practical failure mode we see is a team choosing NB-IoT because it is cheaper per device, without checking that the product will never need mobility or a firmware update larger than a few kilobytes. That constraint is fine to accept deliberately. It is not fine to discover after the first field deployment.
Design for the fleet, not the pilot
A pilot of ten devices on a desk with strong signal will work on almost any protocol. The decision that actually matters is what happens at device two hundred, spread across sites with variable signal strength, where someone eventually wants a new feature that assumes more bandwidth than the radio was ever designed to carry. The two questions worth asking before committing to hardware are: what does the worst-case deployment site look like, not the best case, and what is the largest payload this device will plausibly need to send in three years, not this quarter.
Connectivity also shapes the rest of the platform. Alerting thresholds, retry logic, and how you interpret a device that has gone quiet all depend on whether silence means the device is broken or the network dropped a packet it will retry in ten minutes, a distinction we cover in more detail when designing alerting thresholds for IoT fleets.
A checklist before you commit to a radio
- Do you control the physical site, or does the device ship to locations you will never visit?
- Is the device static, or does it need to move between coverage areas without dropping connectivity?
- What is the actual payload size and frequency today, and the largest plausible payload in three years?
- How will firmware updates reach the device, and how long is that acceptable to take over the chosen radio?
- Who is paying for connectivity over the product’s lifetime, a one-off gateway cost, or a recurring per-device tariff, and does that match the business model?
- What happens operationally when a device goes silent: is that distinguishable from a genuine fault, or does the protocol make that ambiguous?
None of these questions has a universally correct answer. They have a correct answer for a specific fleet, on specific sites, with a specific update cadence, which is exactly why the choice needs to be made deliberately, before the hardware is committed, rather than inherited from whichever dev kit was on the desk first.