Before a single sensor is chosen or a cloud platform selected, the most consequential decision in an IoT product's design has already been made: how the device talks to the outside world. Wireless protocol selection shapes battery life, range, data throughput, certification cost, and monthly operating expense — and unlike most engineering decisions, it's genuinely difficult to reverse once a product ships. Choosing the wrong radio doesn't just mean suboptimal performance; it can mean a product that's locked into a market it can't scale in, or one with coverage gaps exactly where customers need it.
This post compares the main radio options available to IoT hardware teams today — Wi-Fi, BLE, LoRaWAN, LTE-M, and NB-IoT — on the factors that actually determine whether a deployment works.
The First Fork: Short-Range vs. Wide-Area
Before comparing individual protocols, it's worth separating them into two fundamentally different categories, because conflating them is where a lot of protocol-selection mistakes start.
Wi-Fi and BLE are short-range technologies. Wi-Fi depends on existing local network infrastructure and typically covers a building or a home. BLE is shorter-range still — typically effective from a few meters up to around a hundred meters in open space — and unlike the others in this comparison, it's a peer-to-peer, not wide-area, technology, usually pairing with a phone or gateway rather than connecting directly to the internet.
LoRaWAN, NB-IoT, and LTE-M are wide-area technologies, built specifically to move data across long distances — from a sensor buried in a basement or scattered across a field back to a central network — under the broader Low Power Wide Area Network (LPWAN) category.
A product's connectivity requirement usually falls cleanly into one category or the other, which narrows the real decision considerably before getting into the finer trade-offs.
Wi-Fi: High Throughput, Infrastructure-Dependent
Wi-Fi remains the right choice when a device has consistent access to existing network infrastructure and needs to move meaningful amounts of data — video, high-resolution sensor readings, or frequent firmware updates. Its throughput advantage over every other option on this list is substantial, but that comes at the cost of power consumption that makes it a poor fit for battery-powered devices expected to run for months or years unattended, and it offers no coverage at all outside of existing Wi-Fi network range.
BLE: Low Power, Short Range, Gateway-Dependent
Bluetooth Low Energy is the default choice for devices that pair with a smartphone or a nearby gateway rather than connecting to the internet directly — wearables, smart home accessories, and similar personal-area devices. Its power efficiency is excellent for this use case, but the short range means it's structurally unsuited to any application where the device needs to communicate independently over real distance.
LoRaWAN: Long Range, Ultra-Low Power, Infrastructure You Control
LoRaWAN is built for exactly the use case Wi-Fi and BLE can't serve: many devices, spread over a wide area, each sending small amounts of data infrequently, on a battery that needs to last years rather than days. It offers genuinely long range — commonly cited at up to 15 km in rural, unobstructed conditions and 2-5 km in dense urban environments, with one documented rural deployment reaching 11 km and over two years of battery life in real-world testing — at data rates that top out around 50 kbps, reflecting the fundamental trade-off between range, power, and bandwidth that defines LPWAN technology generally.
The distinguishing advantage of LoRaWAN over the cellular LPWAN options is infrastructure ownership: it can be deployed as a fully private network, which matters significantly for remote sites, agricultural monitoring, or facilities where a single owned gateway can cover a large area — one estimate puts a single gateway's coverage at up to 100 hectares, with maintenance-visit savings of 30-50% compared to an equivalent cellular deployment. The trade-off is a real scalability ceiling: published real-world studies note collision limitations above roughly 1,000 devices per gateway, which matters for very dense deployments.
NB-IoT: Deep Indoor Penetration, Carrier-Dependent, Built for Stationary Devices
Narrowband IoT is a 3GPP standard built on licensed LTE spectrum, optimized specifically for stationary sensors that need excellent penetration into basements, meters, and other hard-to-reach indoor locations — a real advantage over LoRaWAN's line-of-sight-sensitive unlicensed-band radio. Real-world commercial network testing has shown NB-IoT maintaining 96-100% packet delivery even at signal levels as low as -127 dBm, and supporting tens of thousands of devices per cell — a meaningfully higher density ceiling than LoRaWAN's per-gateway limits.
The trade-off is dependency on carrier infrastructure and licensed spectrum, meaning coverage is only as good as the carrier's network in a given region, and mobility support is limited — NB-IoT is built for devices that stay in one place, not ones that move between cell towers.
LTE-M: Cellular Mobility, Higher Throughput, More Power Than NB-IoT
LTE-M (also called CAT-M1) sits deliberately between NB-IoT and full LTE. Its defining advantage is mobility support — devices maintain connectivity through cell tower handover as they move, which NB-IoT and LoRaWAN generally don't handle well — making it the natural choice for asset tracking, fleet management, and any application involving a genuinely mobile device.
LTE-M also delivers meaningfully higher throughput, up to roughly 1 Mbps, enabling richer payloads like images, audio, or firmware-over-the-air updates that would be impractical over NB-IoT's or LoRaWAN's narrow data rates — plus sub-200ms latency in real-world testing and, in some deployments, VoLTE voice support, useful for personal safety devices or emergency call buttons. The cost is higher power consumption than NB-IoT due to more frequent network synchronization, and reduced range: one study found LTE-M connectivity failing beyond roughly -113 dBm, a signal threshold at which NB-IoT continues operating reliably.
A Practical Decision Framework
Rather than treating this as five isolated options, it helps to map the decision against a few concrete questions:
Does the device need to move? If yes, LTE-M is generally the right cellular choice; NB-IoT and LoRaWAN are both built primarily for stationary devices.
Do you control the deployment site, or does the device operate on customer/public property? LoRaWAN's private-network option is a major advantage when infrastructure can be owned and controlled directly; cellular options (NB-IoT, LTE-M) make more sense when relying on existing carrier coverage is preferable to deploying gateways.
How much data does each transmission actually need to carry? Small, infrequent telemetry payloads favor LoRaWAN or NB-IoT; anything requiring images, audio, or substantial FOTA payloads points toward LTE-M or Wi-Fi.
How deep indoors or underground does the device sit? NB-IoT's licensed-band penetration is a genuine advantage for basement meters and similarly obstructed locations that challenge LoRaWAN's unlicensed-band signal.
What's the realistic device density per coverage area? LoRaWAN's per-gateway collision ceiling (roughly 1,000 devices) is worth checking against NB-IoT's much higher per-cell capacity for genuinely dense deployments.
Is a hybrid approach worth considering? Some products combine two connectivity options in the same device — LoRaWAN plus cellular, for instance — switching between them to capture each technology's strengths, at the cost of added hardware complexity and BOM cost.
Don't Overlook the Certification and Compliance Angle
Protocol choice has direct downstream consequences for the regulatory process covered in our earlier post on product certification. A pre-certified wireless module keeps a design in the simpler, cheaper FCC SDoC pathway — but that only holds if the antenna and radio design go unmodified. Cellular protocols (NB-IoT, LTE-M) typically require carrier certification on top of standard RF certification, an additional step and cost that Wi-Fi, BLE, and LoRaWAN designs don't carry. This is worth factoring into protocol selection at the same stage as range and power trade-offs, not discovered later as a surprise line item in the certification budget.
Security requirements are converging across protocols too — regulatory frameworks increasingly expect AES-128 encryption or stronger, device attestation, and secure OTA update capability as baseline requirements, covered in more depth in our post on A/B partition OTA architecture, regardless of which radio a device ultimately uses.
Conclusion
There's no universally correct radio protocol — the right choice depends entirely on how a device moves (or doesn't), how much data it needs to send, who owns the deployment infrastructure, and how deep into a building or how far into a field it needs to reach. What's consistent across every option is that this decision needs to be made early and deliberately, with realistic projections for fleet size, mobility, and payload requirements — because unlike many other product decisions, getting the radio wrong is one of the most expensive mistakes to unwind after a design is locked in.
At CoBuild Labs, connectivity selection is one of the first conversations we have on any connected hardware project — matching protocol choice to power, environment, and data needs — then planning certification and RF design together.
Choosing connectivity for a new product? Talk to CoBuild Labs — combine radio selection with certification planning, RF / electronics, and firmware.