LoRaWAN, MQTT or NB-IoT: choosing the right connectivity protocol for industrial IoT

Three names come up in nearly every IoT architecture conversation: LoRaWAN, MQTT, NB-IoT. But they are not three alternatives to pick from — this is the most common misconception in the planning phase, and it tends to produce architectures that are incompatible with real deployment constraints.

LoRaWAN and NB-IoT (alongside WiFi, Ethernet, BLE, Zigbee) are wireless radio protocols — they determine how a device connects physically. MQTT is a messaging protocol that runs on TCP/IP — it determines how data is packaged, routed, and delivered once a connection exists. The two layers are independent: MQTT can run over a LoRaWAN gateway, an NB-IoT modem, or WiFi — and a complete IoT system typically uses both.

LoRaWAN — when the battery has to last years and the range has to be wide

LoRa (Long Range) is a radio technology on unlicensed ISM frequencies, and LoRaWAN is the MAC-layer protocol built on top of LoRa. Its defining characteristics: extremely low power consumption and very long range — ideal for battery-powered sensors in outdoor environments.

• Range: 2–10 km in open terrain (line-of-sight), 1–3 km in dense urban environments — per the LoRa Alliance's own technical documentation, a well-placed gateway can reach over 10km in rural areas. A single LoRaWAN gateway placed at the right position can cover an entire industrial zone spanning several km²
• Battery life: a sensor sending 10 bytes every 15 minutes can run 5–10 years on a single cell battery — thanks to an extremely low duty cycle and deep sleep between transmissions
• Data rate: low (250 bps to 50 kbps depending on Spreading Factor) — LoRaWAN is not suited for devices that need to stream high-volume data continuously, such as video, audio, or dense logs
• Infrastructure: requires deploying your own gateways (or using a public network like The Things Network). This is both an advantage — full control — and a drawback — one more component to operate — at the same time

LoRaWAN is best suited for: environmental sensing (temperature, humidity, pressure), water level monitoring, wide-area asset tracking, rural infrastructure monitoring — wherever devices need long battery life, broad coverage, and low data volume.

NB-IoT and LTE-M — when you need carrier-grade SLA

NB-IoT (Narrowband IoT) and LTE-M are LPWAN standards that run on carrier cellular infrastructure — devices use a SIM card instead of connecting to a private gateway. The key differences from LoRaWAN:

• Coverage: relies on carrier network infrastructure — no gateway deployment needed, works anywhere there is 4G/5G signal. Well suited for geographically distributed devices where you don't control the intermediate network
• Data rate: per GSMA's technical comparison, NB-IoT tops out at ~127 kbps downlink (Cat-NB2/3GPP Release 14, up from ~26 kbps in Release 13), LTE-M reaches up to ~1 Mbps (Release 13) and supports voice — significantly higher than LoRaWAN, enough for firmware OTA updates and higher-frequency telemetry
• Mobility: LTE-M supports inter-cell handover — suited for mobile assets (trucks, containers). NB-IoT is better for fixed installations
• Cost: recurring SIM and data plan costs per device — an important factor when running fleets of thousands of devices

NB-IoT is best suited for: smart electricity/water/gas metering, container and pallet monitoring, mobile medical devices, any application requiring carrier SLA without the burden of managing your own gateway.

MQTT — the messaging layer that runs on all of them

MQTT (Message Queuing Telemetry Transport) is not a wireless protocol — it is a publish/subscribe messaging protocol running on TCP/IP, designed for bandwidth-constrained, unreliable connections. Understanding MQTT's correct role prevents a common architectural mistake:

• An MQTT broker (Mosquitto, EMQX, HiveMQ) receives messages from devices and distributes them to subscribers — a database, dashboard, alert engine, or other service
• QoS levels: QoS 0 (at most once, no delivery guarantee), QoS 1 (at least once, may duplicate), QoS 2 (exactly once, highest overhead) — choose based on the data type
• Retain messages: the broker saves the last message on a topic so a new subscriber receives it immediately on connect — useful for device state and last known values
• Last Will and Testament (LWT): the broker automatically publishes a message when a device disconnects unexpectedly — used to trigger alerts or mark a device offline in the dashboard
• Topic hierarchy: the common convention is {project}/{site}/{device_id}/{metric} — designing a clean topic structure upfront avoids an expensive refactor later when the fleet grows

When to use which protocol — four decision questions

Before selecting a protocol, answer four questions about the actual workload:

• Battery or fixed power? → Devices on battery that need to survive years in outdoor environments → LoRaWAN or NB-IoT. Devices with AC power inside a factory or attached to powered machinery → WiFi or Ethernet — no power budget constraint, can send data more frequently
• Data volume and frequency? → Under a few KB/day (temperature, water level, on/off state) → LoRaWAN is enough. Need a few KB/minute (machine logs, detailed telemetry) → NB-IoT or WiFi. Need Mbps (cameras, audio, raw vibration) → WiFi or Ethernet required
• Fixed or mobile? → Fixed devices in a controlled coverage area → LoRaWAN with private gateways. Mobile assets crossing regions → NB-IoT/LTE-M with SIM
• Who controls the network infrastructure? → Want full control, an isolated environment like an industrial park → LoRaWAN private network. Want zero infrastructure, pay-as-you-go → NB-IoT with carrier

Typical architecture: three layers working together

In a mid-scale industrial IoT system (a few hundred to a few thousand devices), the architecture typically has three coordinated layers: a radio layer (LoRaWAN or NB-IoT from device to gateway), a messaging layer (MQTT from gateway to broker), and a data layer (from broker to a database like TimescaleDB or ClickHouse depending on workload). In the water quality monitoring project across 12 districts in Can Tho, this architecture used LoRaWAN sensors for rural coverage and NB-IoT for stations in urban areas, all pushing into a central MQTT broker before flowing into TimescaleDB.

Conclusion

Choosing an IoT protocol is not about picking the "best" one — it is about matching the right layer to the right problem. LoRaWAN and NB-IoT solve the physical connectivity problem at two different points on the battery/data/infrastructure axis; MQTT solves the messaging and routing problem at the layer above. Getting the architecture right from the start — rather than adding gateways or switching protocols once the system has scaled — is one of the least discussed but most consequential architectural decisions affecting long-term operating costs in the IoT & Sensors layer.