IoT protocols explained: the radio, network and messaging layers

Lists of IoT protocols are long because they mix things that do different jobs. Zigbee, MQTT, LoRaWAN, CoAP, Bluetooth, IPv6, TLS and Modbus all appear on the same lists, and a reader is left comparing a radio with a message format. The way through is to sort them by layer. Each layer answers one question, a device needs an answer at every layer, and the choices at one layer constrain the next. This article walks the stack from the antenna up.

Why there are so many IoT protocols

A phone or a laptop has one answer at each layer and nobody thinks about it: Wi-Fi or cellular, IP, TCP, HTTPS. Connected devices vary too much for one answer. A water meter in a basement, a bulb in a lamp, a vibration sensor on a pump and a tracker on a lorry differ in range, power, data volume, cost and how many of them share the air. Each combination of those constraints has produced a protocol that fits it, and many of them have survived because they remain the best fit for their corner.

The layers are the tool for making sense of this. From the bottom: the radio and link layer decides how bits get through the air and how nearby devices share it. The network layer decides how a packet finds its way beyond the first hop. The transport layer decides whether delivery is checked. The messaging or application layer decides what a message is, who receives it and what it means. A protocol lives at one layer, or occasionally spans two, and a working device has one choice at each.

Radio and link protocols

The bottom layer decides range, power, data rate, and how many devices can share a channel. It is the choice that constrains everything else, so it comes first.

Wi-Fi (standardized by the IEEE as 802.11 and certified by the Wi-Fi Alliance) gives high bandwidth over tens of meters at high power. It is the right answer for devices with a mains supply and a lot to say, and the wrong answer for anything on a battery. Its sub-1 GHz variant, Wi-Fi HaLow, trades speed for a reach of up to about a kilometer.

Ethernet is the wired equivalent: reliable, fast, no power problem, and the default for anything with a cable nearby. Industrial Ethernet variants add determinism for control.

Bluetooth Low Energy (specified by the Bluetooth SIG) covers a few meters to tens of meters at very low power. It suits wearables, beacons, sensors read by a phone, and anything that talks to a device someone is carrying. Bluetooth mesh extends it to building-scale lighting and sensor networks.

IEEE 802.15.4 is a low-power radio standard that several higher protocols share. Zigbee runs on it with its own mesh and application layers; Thread runs on it carrying IPv6. Range is tens of meters per hop, extended by meshing through mains-powered devices. The Zigbee, Z-Wave and Wi-Fi comparison covers how they behave in a house.

Z-Wave is a proprietary sub-gigahertz mesh radio for home devices, with its own network and application layers and a strict certification program run by the Z-Wave Alliance.

LoRa is a long-range, low-data-rate modulation in unlicensed sub-gigahertz bands; LoRaWAN, specified by the LoRa Alliance, is the network and application protocol on top of it. Kilometers of range at a few bytes per message, as the LoRaWAN explainer sets out.

NB-IoT and LTE-M are cellular low-power wide-area radio technologies for small devices, defined by 3GPP and run by mobile operators. They reach anywhere the network does, at the cost of a module, a subscription and a power budget; the NB-IoT and LTE-M comparison chooses between them.

Choosing here is a matter of three questions: how far to the nearest thing that can hear the device, how much data, and what power is available. The connectivity hub answers them in more detail.

Network and transport protocols

The middle layers decide whether a device is an ordinary node on the internet or a member of a private network that needs a bridge.

IP is the dividing line. A device that speaks IPv4 or IPv6 can be addressed and reached with the same tools as any server, and can use any application protocol that runs over IP. Wi-Fi, Ethernet, cellular and Thread devices all carry IP. Zigbee, Z-Wave and LoRaWAN devices do not; they use their own addressing inside their own network, and a coordinator, gateway or network server translates at the boundary.

6LoWPAN, defined by the IETF in RFC 4944 and refined in RFC 6282, is what lets IPv6 run over small radios like 802.15.4: it compresses the headers so a packet fits in a small frame. Thread is built on it, and it is the reason a Thread bulb has an IPv6 address while a Zigbee bulb does not.

TCP and UDP sit on top of IP. TCP checks delivery, orders packets and retransmits losses, at the cost of a handshake, connection state and more traffic. UDP sends packets and forgets them, which is cheaper and suits small, lossy links where the application handles retries itself. MQTT runs over TCP; CoAP runs over UDP; that single difference explains much of how the two behave, as the MQTT vs CoAP article shows.

TLS and DTLS are the security layers over TCP and UDP respectively. TLS 1.3 is what protects MQTT and HTTP; DTLS 1.3 does the same for UDP-based protocols such as CoAP. On constrained devices the handshake cost of these is significant, which is one reason session resumption and pre-shared keys matter there.

Devices on non-IP radios still get security, but from their own layers: Zigbee, Z-Wave and LoRaWAN each define their own key management and encryption, and the gateway re-secures traffic with TLS when it enters the IP world.

Messaging and application protocols

The top layer decides what a message is, who receives it, and what the bytes mean. It is where the application lives, and it is what most people mean when they say “IoT protocol”.

MQTT is a lightweight publish-subscribe protocol over TCP, standardized by OASIS (MQTT 5.0; version 3.1.1 remains common). Devices publish messages to topics on a broker and anything that cares subscribes. It is the default for getting readings from many devices to many consumers, and the MQTT explainer covers topics, quality of service and retained messages.

CoAP, the Constrained Application Protocol (RFC 7252), is a REST-like request-response protocol over UDP designed for very small devices, with an observe extension for notifications. It fits device-to-device and device-to-gateway communication where a broker would be overhead.

HTTP is the web’s protocol and works for devices with the capacity for it, mainly for talking to cloud APIs. It is heavier than either MQTT or CoAP and poorly suited to battery devices, but universally supported.

AMQP is a richer message-queuing protocol from enterprise messaging, used where the back end already speaks it. WebSockets carry MQTT or custom messages through web infrastructure.

OPC UA is the industrial information-model protocol: a client browses a server’s structured address space and reads, writes and subscribes to typed values, with built-in security, as the OPC UA and MQTT article describes. Its publish-subscribe extension can carry that structured data over MQTT.

Modbus is the oldest industrial protocol still in daily use: a simple register-reading protocol over serial lines or TCP, with no security and no data types beyond registers, kept alive by the enormous installed base of equipment that speaks it.

Matter is the smart home application layer from the Connectivity Standards Alliance, running over IP on Wi-Fi, Ethernet and Thread, which defines device types and how controllers talk to them; the Matter article explains what it changes. Zigbee and Z-Wave each carry their own application layer, which is why those devices need a bridge to appear as Matter devices.

LoRaWAN’s application layer is minimal by design: small binary payloads whose format the application defines, decoded by the network server, and usually republished as MQTT from there.

The messaging layer also owns the payload format, which no protocol dictates. JSON is readable and verbose; compact binary encodings suit constrained links; standard formats exist for specific domains. Whatever is chosen, units and timestamps belong in the convention.

Which IoT protocols go together

Some combinations are so common they have names, and they are worth recognizing because choosing one at the bottom often settles the rest.

The pattern to notice: IP-carrying radios let the device use standard internet protocols end to end; non-IP radios put a translator at the boundary, and MQTT tends to be what comes out the other side. That translator, whether it is called a coordinator, a gateway or a network server, is part of the design and needs a home.

How to choose IoT protocols for a project

Work up the stack, because each layer narrows the next.

1. Choose the radio from the physical constraints. Distance to the nearest gateway or access point, power source, data volume, whether the device moves. This decision usually eliminates most of the table on its own. The IoT sensors article covers how the output type of the sensor feeds into this.
2. Accept the network layer the radio gives you. An IP radio means standard networking; a non-IP radio means a bridge, so plan the bridge now: where it sits, what powers it, who maintains it.
3. Pick the transport by the link’s character. Reliable, always-on links suit TCP and the protocols built on it. Lossy, constrained or sleepy links suit UDP with application-level retries.
4. Pick the messaging protocol by the shape of the communication. Many devices reporting to many consumers points to MQTT and a broker. Request-response between devices or to a gateway points to CoAP. Structured industrial data with browsing and typing points to OPC UA. A cloud API points to HTTP.
5. Decide the payload convention and write it down. Units, timestamps, identifiers and encoding. This is the part every team skips and every team regrets.
6. Secure every layer that crosses a boundary. Radio-layer keys inside a mesh, TLS or DTLS on the IP side, signed firmware for updates, and credentials per device rather than per fleet. The IoT security hub covers the practical side.

A project rarely needs to invent anything here. The combinations in the table exist because they work, and choosing one of them, then spending the effort on the payload convention and the security, is how a protocol decision stays out of the way for the life of the system.