Overview
Every IoT product eventually asks the same question: how should the device talk to the outside world? There's no universal answer — a battery-powered sensor reporting once an hour has almost nothing in common with a real-time positioning tag or a factory floor gateway streaming continuous data. Picking the wrong protocol early is one of the most common and expensive mistakes in embedded product design, because it's rarely a firmware-only decision — it shapes antenna placement, power budget, enclosure design, and even the business model around subscription data plans. This guide walks through the protocols that matter most for connected products today, grouped by what they're actually built for.
Short-Range Wireless: Wi-Fi, BLE, and Zigbee
Wi-Fi remains the default choice when a device needs high bandwidth and already sits within range of a router — video streaming, firmware-over-the-air updates with large payloads, or anything that needs to move real data volume quickly. Its cost is power: association and TCP/IP overhead make Wi-Fi one of the most power-hungry common radios, which is why it rarely appears in coin-cell or long-life battery products. ESP32-based designs handle Wi-Fi well when mains or rechargeable power is available.
Bluetooth Low Energy trades bandwidth for efficiency and is the natural fit for phone-paired devices — wearables, fitness trackers, and any product whose primary interface is a mobile app over short range. Zigbee sits in a similar power class but adds mesh routing at the protocol level, which makes it a strong choice for smart-home and building-automation networks where dozens of nodes need to relay data to each other without a central Wi-Fi access point covering every corner.
Long-Range, Low-Power: LoRa, NB-IoT, and LTE-M
When a device needs to reach kilometres rather than metres, the short-range radios above stop being viable and the choice shifts to LoRa, NB-IoT, or LTE-M. LoRa uses a proprietary modulation scheme that trades data rate for exceptional range and very low power draw, and it can run on a private gateway with no carrier subscription at all — see our LoRa vs Wi-Fi comparison and a real ESP32 LoRa gateway-and-node system for how this plays out in practice. It's the right call for remote agriculture, pipeline, or asset-tracking deployments where running new infrastructure isn't practical.
NB-IoT and LTE-M are the cellular alternatives, riding on existing carrier networks instead of a private gateway. NB-IoT is optimised for very small, infrequent payloads and deep power savings — smart metering and static sensors are typical fits. LTE-M supports higher data rates and, critically, handles mobility and handoff between cell towers, which makes it the better option for anything that moves, like vehicle or asset trackers that need continuous connectivity across a wide area. Both come with recurring SIM data costs that LoRa avoids, which matters for total cost of ownership on large deployments.
UWB and the Application Layer: MQTT
Ultra-wideband solves a different problem entirely: precise indoor positioning. Where GPS fails indoors and Wi-Fi/BLE signal-strength estimates are only accurate to a few metres, UWB time-of-flight ranging can locate a tag to within tens of centimetres — useful for asset tracking inside warehouses, hospitals, or factories. It's worth reading in more depth if indoor location is part of your product; see our dedicated piece on UWB indoor positioning.
None of the above protocols specify how application data is structured once it reaches a server, which is where MQTT comes in. It's a lightweight publish/subscribe messaging protocol built for constrained devices and unreliable links, and it's become the de facto standard for carrying sensor data from an IoT device — over Wi-Fi, cellular, or a gateway bridging LoRa — up to a cloud dashboard or mobile app. Choosing MQTT (versus a heavier REST API) for the last hop is usually the right call whenever bandwidth or device resources are limited.
Choosing the Right Protocol for Your Product
In practice, the decision comes down to three questions: how far does the signal need to travel, how much energy is available, and how much data actually needs to move. A device with mains power and high bandwidth needs almost always points to Wi-Fi. A battery-powered sensor with a small, infrequent payload points to LoRa, NB-IoT, or BLE depending on whether infrastructure already exists. A product that needs to track location indoors is really asking a different question altogether, and belongs in UWB. Many real products end up using two protocols together — BLE for phone pairing and configuration, LoRa or cellular for the long-range uplink — rather than forcing a single radio to do everything.
How PAK-EL LAB Can Help
PAK-EL LAB designs the hardware and firmware for connected products across this entire range — Wi-Fi and BLE-based ESP32 designs, LoRa gateways and nodes, cellular IoT, and UWB positioning systems — and can help you weigh these trade-offs before a single line is committed to a schematic.
Related services: RF, LoRa & Satellite Communication · ESP32 & UWB Development · IoT Product Development