IoT connectivity: LoRaWAN, cellular and MQTT

Start from three questions: how far the device is from something that can hear it, how much data it needs to send, and what power it has. A device inside a building with mains power and a lot to say can use Wi-Fi. A battery sensor that sends a few bytes a few times an hour, possibly kilometers from the nearest gateway, is what LoRaWAN was designed for. A device that moves, or sits somewhere you cannot put your own gateway, needs cellular, and the choice between NB-IoT and LTE-M is covered in its own article.

The mistake to avoid is picking the radio before answering those questions, usually because a module was to hand. Range, data rate and power are traded against each other in every radio design, so a technology that is excellent on one axis is usually poor on another. The LoRaWAN article shows that trade-off in the spreading factor table, and it applies in some form to every option on this hub.

A radio protocol decides how bits get through the air: the frequency, the modulation, how devices share the channel and how far a signal reaches. LoRaWAN, NB-IoT, Zigbee and Wi-Fi are all radio-level choices. A messaging protocol decides how data is organized once a link exists: what a message is, who it is addressed to, whether delivery is confirmed, and how a reader finds the messages it cares about. MQTT is a messaging protocol, and it does not care what radio carried the packets.

The two are chosen separately, which is why a plant can run MQTT over Ethernet, Wi-Fi and a cellular modem at the same time and treat the results identically at the broker. The MQTT article explains topics, quality-of-service levels and retained messages, which are the parts of the messaging layer that most affect how a system behaves. LoRaWAN is the exception in the sense that it defines its own small application layer, so MQTT usually appears only after a LoRaWAN network server has decoded the packets.

Very little, most of the time. A temperature and humidity reading fits in a handful of bytes, a GPS position in a few tens of bytes, and a status flag in one. What makes the difference is how often the device sends and how much protocol overhead surrounds each payload. A LoRaWAN uplink carries a small payload with a small header; an MQTT message over TCP over cellular carries the same payload wrapped in several layers, each with its own headers and acknowledgments.

That overhead is why battery devices on constrained radios send compact binary payloads rather than readable text, and why they send less often than the sensor could be read. The connectivity articles avoid quoting a single figure because the answer depends on the payload format and the interval, both of which you control. Work out the bytes per message, multiply by messages per day, and the radio choice usually becomes obvious.