Connectivity choice is one of the earliest decisions in a connected-product build, and it's rarely revisited once made — it shapes the MCU or module selection, the antenna and PCB layout, the cloud ingestion architecture, and the ongoing infrastructure cost. Getting it wrong is expensive to undo. The right choice comes down to four questions: how far does the signal need to travel, how much power can the device spare, what does the data-rate and latency need to look like, and who's paying for the network the data rides on.
The four options, at a glance
| Protocol | Range | Power | Data rate | Infrastructure |
|---|---|---|---|---|
| BLE | ~10-100m | Very low | Low-moderate | None (phone/gateway as bridge) |
| Wi-Fi | ~30-100m indoor | Moderate-high | High | Existing home/facility Wi-Fi |
| LoRaWAN | Km-scale | Very low | Very low (bytes/message) | Gateway network required |
| Cellular (LTE-M/NB-IoT/LTE) | Carrier coverage area | Low-moderate | Low-high (variant-dependent) | Carrier network + SIM/data plan |
Bluetooth Low Energy — when a nearby hub can do the relaying
BLE is the right fit when the device is always going to be near a phone, tablet, or gateway that can bridge it to the internet, and range needs are room-scale rather than building- or site-scale. It's extremely power-efficient in its intended use pattern — periodic short connections rather than a sustained link — which is why it dominates wearables, medical patches, and smart-home peripherals that pair with a companion app. Its main constraint is that it isn't internet connectivity by itself; something else (usually a phone or a dedicated gateway) has to be present and willing to relay data onward.
Wi-Fi — when there's already a network and power isn't the constraint
Wi-Fi gives the device direct internet access without a relay, at the cost of meaningfully higher power draw than BLE or LoRaWAN — usually the deciding factor. It's the natural choice for mains-powered or frequently-charged devices in a home or facility that already has Wi-Fi coverage: smart plugs, cameras, hubs, appliances. For a coin-cell or small-battery device expected to last months or years, Wi-Fi's active-mode current draw is usually disqualifying.
LoRaWAN — long range, tiny payloads, and a gateway you have to plan for
LoRaWAN trades data rate for range and power: it can cover kilometers on a coin-cell-class power budget, but at data rates measured in bytes per message, not kilobytes. That makes it a strong fit for infrequent, small-payload telemetry — a soil-moisture reading, a tank level, an occupancy count — spread across a wide area, like agricultural or industrial sites. The catch is infrastructure: unlike cellular, there's no default network already up; the product either needs its own LoRaWAN gateway deployed on-site, or has to rely on a public network operator's coverage in the deployment region, which varies significantly by geography.
Cellular — when there's no local network to rely on at all
Cellular (LTE-M, NB-IoT, or standard LTE depending on the data-rate need) is the choice when a device has to work anywhere, independent of the customer's own network infrastructure — asset trackers, remote industrial monitors, anything shipped to a location the vendor doesn't control. LTE-M and NB-IoT specifically are designed for low-power, low-data-rate IoT use cases and draw far less power than full LTE, though still more than BLE or LoRaWAN. The tradeoff is ongoing cost: a SIM and data plan per device, plus carrier dependency and, in some regions, network-sunset risk as older cellular generations get phased out.
Combining protocols is common, not a compromise
Many real products use more than one protocol deliberately — a wearable using BLE to relay through a phone, with cellular as a fallback path for use cases where the phone might not be present; or a LoRaWAN sensor network reporting into a cellular-connected gateway that aggregates and forwards. The decision isn't always "pick one," it's "pick the right protocol for each hop in the data's path from device to cloud."
How we approach this
We treat connectivity selection as inseparable from the power budget and deployment environment — it gets modeled alongside the MCU and sensor choices, not decided in isolation. See our cloud & device platform work for how connectivity choices flow into fleet management and telemetry architecture.