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 resembles HTTP: a client addresses a resource and a server returns a response. IETF CoAP follows a REST style and provides methods such as GET, PUT, POST, and DELETE, but its UDP messaging, Tokens, asynchronous responses, Observe, and optional multicast semantics are not identical to HTTP. Polling many terminals creates request fan-out and wakeup cost, but not every CoAP request performs a “full handshake.” Security-context reuse, terminal reachability, and the use of Observe jointly determine that cost.
The publish/subscribe model introduces a broker: devices publish to topics, other devices or services subscribe to matching topics, and the broker routes messages. MQTT is a typical example and was designed for narrowband, high-latency, unstable links. It reduces address and topology coupling between publisher and subscriber but does not automatically decouple them completely in time. Offline delivery depends on QoS, persistent sessions, subscription state, message expiry, and broker storage. A publisher can safely sleep only after completing the exchange required by its selected QoS. Any battery-life benefit must be measured against connection maintenance, radio wakeups, and reporting cadence.
The more accurate dividing line is the interaction contract: request/response organizes one exchange around a resource, while publish/subscribe organizes distribution around topics and an intermediary. Both can be implemented asynchronously, and both remain subject to online state, buffering, and timeouts. The former often fits on-demand queries and resource operations; the latter often fits continuous collection and multi-consumer 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 TCP, which provides an ordered byte stream, retransmission, and flow control. Whether application messages continue to be delivered across a disconnection also depends on MQTT QoS, session state, client identity, message expiry, and broker persistence. A long-lived connection can add handshake, keep-alive, and radio-wakeup cost, but its share of energy depends on the access network, Keep Alive, and reporting interval and must be measured. MQTT-SN (MQTT for Sensor Networks) likewise shows why constrained environments may need a different transport and session trade-off.
CoAP commonly uses UDP. UDP is connectionless and offers no delivery guarantee; CoAP then distinguishes CON (Confirmable) and NON (Non-confirmable) exchanges. A CON message is retransmitted with backoff until an ACK or RST arrives or the retry limit is reached, after which it can still fail; NON has no protocol-layer acknowledgment or retransmission. An ACK confirms the CoAP exchange, not completion of a physical action. This design lets a system choose confirmation cost per message, while actual latency, energy, and arrival rate still require measurement on the target network.
LwM2M (Lightweight Machine-To-Machine), defined by OMA SpecWorks, specifies an object/resource model and device-management procedures such as bootstrap, registration, observation, configuration, and firmware update over transport bindings that include CoAP. CoAP supplies request/response and message exchange; LwM2M supplies management semantics. Security and delivery properties still depend on the chosen binding, confirmation mode, and implementation and cannot be inferred from the use of LwM2M alone.
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
Consider a battery-powered pipeline terminal with a multi-year life target. MQTT/TCP may add connection, keep-alive, and session-recovery cost. CoAP/UDP maintains no TCP connection and lets the application select NON or CON per message, so it often belongs on the shortlist for infrequent reports. Yet radio registration, PSM/eDRX behavior, DTLS or OSCORE, security handshakes, retransmissions, and sensor sampling can matter more than a four-byte header. No application protocol promises “zero-power standby.” Choose from current traces, loss measurements, and the battery budget on the target modem and coverage profile.
Memory and compute impose another boundary, but “Cortex-M0” alone does not decide the protocol. RAM and Flash sizes, networking stacks, TLS/DTLS libraries, certificate chains, and buffer settings differ widely. CoAP implementations can be compact, while LwM2M adds an object model and lifecycle management; trimmed MQTT/TCP/TLS stacks also exist for constrained terminals. Compare linked image size, peak stack and heap, handshake memory, and failure recovery on the target firmware instead of excluding a protocol by core name.
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 |
| Better-fit scenarios | Broker-mediated bidirectional messaging that needs QoS and session semantics | Many small packets from constrained terminals that select confirmation per message | Terminals needing standardized remote-management workflows | RESTful APIs and large-object transfer with existing Web infrastructure |
| 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.