9.1 Overview of IoT Application-Layer Protocols
9.1.1 Classification of IoT Application-Layer Protocols
Between the field and the cloud, every protocol layer that sensor data passes through is doing one thing: defining the shape of the data and the rules for exchanging it. As the layer of the four-layer architecture closest to the business, the application layer carries the role of converting physical signals into business semantics. Faced with fragmented device types, communication media, and power constraints, engineers must make the first trade-off in protocol selection.
Communication Model: Two Basic Interaction Patterns
By communication model, IoT application-layer protocols fall into two categories — request/response and publish/subscribe — and the two start from fundamentally different design points.
The request/response model follows the same lineage as HTTP (HyperText Transfer Protocol): the client initiates a request and the server replies with a response. CoAP (Constrained Application Protocol), defined by the IETF (Internet Engineering Task Force), is built on the REST (Representational State Transfer) architecture and supports the four methods GET, PUT, POST, and DELETE, corresponding one-to-one with the methods of HTTP. Engineers moving from Web development into IoT barely need to relearn the interaction semantics. The drawback is that every interaction requires the client to know "whom to ask," and one request fetches only one response — unsuitable for one-to-many data distribution. If a monitoring center polls a thousand temperature sensors, every poll triggers a full handshake.
The publish/subscribe model is designed entirely differently. A device publishes messages to a broker, other devices or services subscribe to specific topics on the broker, and the broker takes care of forwarding the messages. MQTT (Message Queuing Telemetry Transport) is the typical representative of this model; it was originally designed for narrow-channel, high-latency, unreliable scenarios such as oil pipelines and remote monitoring. Sender and receiver are fully decoupled in both time and space — a publisher can go to sleep right after publishing, the broker holds the message, and it is pushed once the subscriber comes online. For battery-powered sensors this means fewer wake-ups of the radio transceiver, and therefore longer battery life.
The fundamental difference between the two models falls on the dividing line of "synchronous vs. asynchronous." Request/response requires both parties to be online at the same time; publish/subscribe allows the sending side to be offline. The former suits on-demand queries; the latter suits continuous collection and distribution.
Transport Layer and Device Capability: TCP or UDP?
The second fork in protocol selection comes from the transport layer: TCP (Transmission Control Protocol) versus UDP (User Datagram Protocol).
MQTT runs on top of TCP, relying on TCP's three-way handshake, keep-alive, retransmission, and flow control to guarantee reliability. The price is the continuous energy cost of maintaining a long-lived connection — for a small sensor that uploads data only a few times a day, the TCP keep-alive heartbeat may consume more energy than the data itself. This constraint already showed up in the early MQTT-SN (MQTT for Sensor Networks) attempts: carrying the TCP-based design over unchanged is not economical in resource-constrained environments.
CoAP chooses UDP as its foundation. UDP is connectionless and does not guarantee delivery, but its overhead is extremely low. CoAP distinguishes reliability levels through its two message types, CON (Confirmable) and NON (Non-Confirmable): a CON message requires the receiver to reply with an ACK (acknowledgment) within a bounded time, or the sender will retransmit; a NON message is sent and forgotten. This design lets CoAP select reliability on demand over UDP, instead of shouldering the entire TCP keep-alive chain.
LwM2M (Lightweight Machine-To-Machine) occupies a more special position. Defined by the OMA (Open Mobile Alliance), it is an application-layer protocol oriented toward device management and data collection, yet at the bottom it depends entirely on CoAP. Seen from the protocol-stack perspective, LwM2M defines "how messages are orchestrated, how reliable delivery must be, and how device state is managed," while CoAP is responsible for sending and receiving the messages. The two layers stack — CoAP on top of UDP, LwM2M on top of CoAP — forming a complete protocol stack for resource-constrained devices.
Classification Map: The Protocol Layout at a Glance
The layered figure below shows where the major protocols sit, from the sensing layer to the application layer. At the bottom are the sensing layer's sensors and actuators; above them sit the wireless access technologies (Wi-Fi, BLE (Bluetooth Low Energy), Zigbee, LoRa, NB-IoT (Narrowband IoT), 5G); higher still comes the transport layer (TCP/UDP); and at the very top are the application-layer protocols. Within the application layer, MQTT falls into the publish/subscribe category, CoAP and HTTP into the request/response category, and LwM2M appears as a special branch above CoAP.
Given this classification, what engineers need to do is not memorize protocol parameters but build a line of selection logic: if a sensor only reports, requires no downstream control, and must live on a battery for more than three years, CoAP (with a layer of LwM2M management where necessary) has an energy advantage over MQTT holding a long TCP connection; if the platform needs two-way control and command dispatch, or already depends on mature message-queue infrastructure, MQTT's publish/subscribe model is the safer choice. There is no universal protocol — only the one that best matches device constraints and communication needs.
9.1.2 Factors Influencing Protocol Selection
We have seen the divide between MQTT and CoAP on the communication model, but when the decision lands on real engineering — a gas meter reporting its reading once a day, smart lighting demanding responses at the hundred-millisecond level, a factory PLC that must connect to the OPC UA (OPC Unified Architecture) unified address space — which one do you choose? The communication model alone is not enough. Protocol selection is in essence a search for balance across three constraint dimensions: network constraints (bandwidth, latency, reliability), device constraints (power, memory, compute), and ecosystem constraints (standard maturity, toolchain, community support). The intersection of the three is often the option that is "not the most advanced, but the most fitting." The following takes them apart one by one.
Network Constraints: Bandwidth, Latency, and Reliability
Bandwidth first. The unlock command of a shared bike: a single report carries only a status code and a lock identifier, so a single exchange is usually just a few bytes of data. CoAP's packet overhead is extremely low — a fixed header of only a few bytes, running over UDP, with no handshake and no keep-alive. Replace it with HTTP REST polling and every request must carry the full textual header; for a message like "lock state 0x01," the vast majority of the traffic is protocol overhead. When a city deploys tens of thousands of shared bikes, that cost lands directly on operating expenses.
Latency next. In "human-in-the-loop" scenarios such as smart lighting, the perceived delay from the user pressing the switch to the light responding must stay within an imperceptible range. MQTT is based on TCP — three-way handshake plus long-connection keep-alive — and meets the requirement on a stable local network. But when devices attach over cellular networks and go through frequent disconnects and reconnects, TCP's handshakes and timeout retransmissions instead become a source of delay and stutter. CoAP's NON (Non-Confirmable) message type lets a device "send and forget," pulling end-to-end latency assurance out of the transport layer and leaving the business layer to define its own reliability policy.
Device Constraints: Power, Memory, and Compute
A natural-gas pipeline monitoring terminal runs on battery and is required to work continuously for more than five years. Power is the true hard cutoff boundary. MQTT was designed with constrained environments in mind, but keeping a TCP connection alive means sending heartbeat packets at regular intervals. For an always-online gateway with a stable power supply this hardly matters; for a sensor that must run for years on a coin cell, every transmission and reception drains the battery. CoAP is based on UDP and carries no connection-maintenance overhead — the device sends its message and drops into deep sleep. This is the model that genuinely approaches "zero-power standby." It is also why, in battery-powered, low-frequency reporting scenarios, CoAP is often a better fit than MQTT.
Memory and compute likewise press against the ceiling. A Cortex-M0 MCU has no more than a dozen-odd KB of RAM in total; running a complete MQTT protocol stack on it (including TCP/IP and the TLS encryption stack) is nearly impossible. CoAP's design goal is precisely this class of MCU: the protocol stack is lean enough to fit into limited flash space. LwM2M layers a device-management object model on top of CoAP — one more level of abstraction, but the resource-overhead advantage of CoAP is preserved at the bottom.
Ecosystem Constraints: Standard Maturity and Toolchain
However perfect a protocol is in theory, without mature open-source implementations and debugging tools it is hard to land in production. MQTT's ecosystem is relatively mature: implementations such as Eclipse Paho, Mosquitto, and EMQX have been validated at large scale and cover the mainstream languages; debugging tools are complete (GUI clients such as MQTTX, Wireshark's MQTT dissector). Engineers pushing a feature from prototype to production line are rarely blocked by the toolchain. All of this rests on the OASIS standards (MQTT v3.1.1 and v5.0).
CoAP's ecosystem is relatively "young." It has IETF RFC 7252 as its standard and mature implementations such as Californium (Java) and libcoap (C), but its debugging toolbox does not match MQTT in depth and breadth. If you choose LwM2M, it sits on top of CoAP and standardizes device management, firmware upgrade, and remote configuration into object models; it is increasingly common in carrier-grade terminals such as NB-IoT modules and smart meters. The price is a steeper learning curve: developers must understand the three-level "object / object instance / resource" tree structure, not merely send a message. Whether this extra abstraction layer is needed depends on whether management functions such as remote firmware upgrade and device-configuration reading are genuinely required — do not put the cart before the horse.
Security Considerations
No protocol escapes the security layer once it reaches actual deployment. HTTP has HTTPS (TLS); MQTT can run TLS over TCP (commonly called MQTTS); CoAP encrypts with DTLS (Datagram Transport Layer Security); and LwM2M likewise protects communication through CoAP's DTLS. Beyond that, device authentication — pre-shared keys, X.509 certificates, or tokens — is supported at different depths by different protocols and brokers, which directly shapes the design of the overall security architecture for device access.
Selection Framework: A Simplified Decision Comparison
Pull these dimensions into a single comparison table and the decision becomes clearer.
Table 9-1 Selection Comparison of Mainstream IoT Application-Layer Protocols
| Dimension | MQTT | CoAP | LwM2M | HTTP |
|---|---|---|---|---|
| Transport layer | TCP | UDP | CoAP/UDP + DTLS (the default form) | TCP |
| QoS levels | 0 / 1 / 2 | CON / NON (mapped to 0/1) | Same as CoAP, plus object acknowledgment | TCP's own retransmission |
| Typical latency profile | Moderate (TCP handshake + keep-alive) | Low (no connection maintenance) | Low | Relatively high (heavy header overhead) |
| Power consumption profile | Medium | Low | Low | High |
| Typical application scenarios | Smart home, connected vehicles, industrial monitoring | Low-frequency sensor reporting, geomagnetic parking-space detection, farmland monitoring | NB-IoT modules, smart meters, remote device management | Third-party API data retrieval, bulk gateway uplink, configuration management |
| Best-fit scenarios | Two-way control, situations requiring highly reliable delivery | Large numbers of small packets, battery-powered deep-sleep terminals | Carrier-grade terminals that need remote management | RESTful API calls with no real-time requirement |
| Worst-fit scenarios | Deep-sleep, ultra-low-power terminals | Applications requiring strict message ordering and persistence | Development speed first, teams short on CoAP experience | Massive high-frequency small-packet reporting |
Note: the qualitative judgments in each dimension of this table are engineering generalizations based on protocol design specifications and typical deployment experience, not precise measurements. Under different deployment conditions, the conclusions may shift.
Additional note: "CoAP/UDP + DTLS" in the LwM2M column is the default form, not the only choice — since LwM2M 1.2, OSCORE (RFC 8613, which provides end-to-end encryption and integrity protection at the CoAP message layer; the mechanism is covered in Section 8.3.2 of Chapter 8) has been supported, and in scenarios where the DTLS handshake overhead is hard to bear or end-to-end protection across proxies is required, it can serve as an alternative security path.
This table can serve as the starting point of a decision. As you move into the chapters that follow and see how each protocol performs in concrete cases, you can come back to it at any time and check: why did this scenario choose CoAP rather than MQTT? Why does the smart-home gateway use MQTT while the sensors themselves speak CoAP? The selection framework will help you connect the answers.