3 CoAP and MQTT: Overhead and Reliability

3.1 Overview

This first route compares the protocols from message flow through transport, reliability, packet overhead, and energy arithmetic.

This is part 1 of 2. Continue with CoAP and MQTT: Brokers and Selection Evidence for the second focused route.

3.2 Start Simple: Pick the Conversation Before the Header

Imagine two teams looking at the same soil sensor. One team wants the sensor to wake once a day and report moisture to a nearby gateway. A gateway is a device that passes data between different networks. The sensor then receives an acknowledgment, which confirms arrival, and returns to sleep. The other team wants a dashboard, rules engine, and maintenance app to see every update. Those are different conversations, even if both carry the same small reading.

For the first conversation, CoAP can feel natural because one endpoint asks or reports a resource and then goes quiet. For the second, MQTT can feel natural because a broker can fan out one publication to several subscribers and remember session state. Read the rest of the comparison as a set of proofs for that story: connection cost, reliability, broker ownership, battery impact, and the evidence a reviewer would keep.

3.3 Learning Objectives

By the end of this chapter, you will be able to:

• Compare Architecture Models: Distinguish between CoAP’s request-response and MQTT’s publish-subscribe patterns, explaining the coupling implications of each
• Evaluate Transport Trade-offs: Analyze UDP vs TCP implications for IoT deployments, justifying which is appropriate given device constraints and reliability needs
• Assess QoS Options: Compare reliability mechanisms in both protocols and select the appropriate QoS level for a given use case
• Calculate Protocol Overhead: Compute header sizes, per-message bandwidth, and annual energy expenditure to demonstrate efficiency trade-offs between CoAP and MQTT
• Select Protocols: Apply a decision framework to design protocol selection for real-world IoT deployments based on specific technical requirements
• Diagnose Configuration Errors: Identify and fix common protocol misconfiguration patterns such as persistent MQTT connections for infrequent sensors

3.5 Prerequisites

Before diving into this chapter, you should be familiar with:

• Application Protocols Overview: Basic understanding of MQTT and CoAP roles in IoT
• Transport Fundamentals: TCP vs UDP characteristics

Header size alone cannot choose an application protocol. Figure 3.1 compares transport, minimum wire cost, fan-out, and state ownership for one constrained conversation.

The TRANSPORT row in Figure 3.1 pairs CoAP’s confirmable UDP retry with MQTT’s TCP session and keepalive. The FAN-OUT and STATE OWNER rows reverse the apparent two-byte advantage: a broker can distribute once and preserve session or topic QoS, while a direct client may repeat requests.

3.6 CoAP vs MQTT: Detailed Comparison

Choosing between CoAP and MQTT is not always straightforward. Both protocols excel in different scenarios. Here’s a comprehensive comparison:

3.6.1 Architecture and Communication Model

Before choosing between CoAP and MQTT, separate the interaction pattern from the transport details. Use Figure 3.2 to test whether the workload is a direct resource exchange or a broker-mediated flow, then connect that choice to overhead, reliability, and fan-out.

Aspect	CoAP	MQTT
Pattern	Request-Response (client-server)	Publish-Subscribe (broker-based)
Communication	One-to-One	Many-to-Many
Coupling	Tight (direct connection)	Loose (decoupled via broker)
Discovery	Built-in resource discovery	Topic-based addressing

Table: Detailed CoAP vs MQTT Comparison

FACTOR	CoAP	MQTT
Main transport protocol	UDP	TCP
Typical messaging	Request/response	Publish/subscribe
Effectiveness in LLNs	Excellent	Low/fair (Implementations pairing UDP with MQTT are better for LLNs.)
Security	DTLS	SSL/TLS
Communication model	One-to-one	Many-to-many
Strengths	Lightweight and fast, with low overhead, and suitable for constrained networks; uses a RESTful model that is easy to code to; easy to parse and process for constrained devices; support for multicasting; asynchronous and synchronous messages.	TCP and multiple QoS options provide robust communications; simple management and scalability using a broker architecture.
Weaknesses	Not as reliable as TCP-based MQTT, so the application must ensure reliability.	Higher overhead for constrained devices and networks; TCP connections can drain low-power devices; no multicasting support.

Inspect Figure 3.2 now that the detailed table has named each factor; follow the same rows in the visual from transport and messaging pattern through operational strengths and weaknesses.

Read Figure 3.2 from the messaging row outward. CoAP begins with request-response between known endpoints, whereas MQTT inserts a broker so publishers and subscribers need not know one another. Next compare UDP with TCP: CoAP can keep each exchange small and choose confirmation per message, while MQTT pays for a persistent connection and gains TCP delivery plus broker services. Finally inspect the strengths and weaknesses together; neither column is a universal winner. The right choice follows the workload boundary established here.

Format Discovery: CoAP Negotiates, MQTT Assumes

The “Discovery” row above is about finding a resource. A separate question is whether the two endpoints agree on what format that resource is returned in, and the two protocols answer it differently.

CoAP carries Content-Format and Accept options in its header, so a client can ask which representations a server can return, and the server can label the format it sends back. That built-in negotiation lets constrained devices probe each other for a compatible payload format before committing to one.

MQTT has no equivalent metadata field. A publisher and its subscribers must agree on the message format out of band — through documentation, a schema registry, or plain convention — before anyone uses the topic. MQTT will move whatever bytes a client hands it, but the protocol itself will not tell a receiver what those bytes mean.

Record the format-agreement mechanism alongside the topic or resource map: CoAP’s content negotiation is protocol-level evidence, while MQTT’s format agreement is a design decision that has to be documented and enforced separately.

3.6.6 Design Philosophy

Read the comparison by separating provenance from operating model. CoAP takes HTTP’s resource-oriented approach into the IETF constrained-node stack, so a client addresses a resource and exchanges a request and response. MQTT comes from SCADA-oriented messaging and standardisation through OASIS, so publishers and subscribers meet through a broker. The target row then explains the practical consequence: constrained direct interactions favour CoAP, while telemetry distribution and messaging favour MQTT. This is a difference in conversation shape, not a claim that one standards body or protocol is universally better.

Aspect	CoAP	MQTT
Inspired By	HTTP (RESTful)	MQTT for SCADA
Paradigm	Resource-oriented	Message-oriented
Standards Body	IETF (RFC 7252)	OASIS (ISO/IEC 20922)
Target	Constrained nodes	Telemetry and messaging

Checkpoint: Transport and Reliability

You now know:

• CoAP is UDP-based and request/response oriented; MQTT is TCP-based and publish/subscribe oriented through a broker.
• CoAP reliability is a per-message choice between CON and NON; MQTT reliability is selected with QoS 0, QoS 1, or QoS 2.
• A daily report on a 2% loss network favors CoAP CON when battery life matters, while many consumers and durable fan-out favor MQTT.

Putting Numbers to It: CoAP vs MQTT Packet Overhead

Scenario: A sensor sends a 10-byte temperature reading every 60 seconds for 1 year.

CoAP NON message (UDP):

$$\begin{align} \text{CoAP header} &= 4 \text{ bytes} \\ \text{Token + options} &= 6 \text{ bytes} \\ \text{Payload} &= 10 \text{ bytes} \\ \text{UDP header} &= 8 \text{ bytes} \\ \text{IPv6 header} &= 40 \text{ bytes} \\ \text{Total} &= 68 \text{ bytes per message} \end{align}$$

MQTT QoS 0 message (TCP):

$$\begin{align} \text{MQTT fixed header} &= 2 \text{ bytes} \\ \text{Topic length + topic} &= 2 + 20 = 22 \text{ bytes} \\ \text{Payload} &= 10 \text{ bytes} \\ \text{TCP header} &= 20 \text{ bytes} \\ \text{IPv6 header} &= 40 \text{ bytes} \\ \text{TCP ACK (return)} &= 60 \text{ bytes} \\ \text{Total} &= 154 \text{ bytes per message} \end{align}$$

Annual bandwidth:

$$\begin{align} \text{Messages/year} &= \frac{365 \times 24 \times 3600}{60} = 525{,}600 \\ \text{CoAP annual} &= 525{,}600 \times 68 = 35.7 \text{ MB} \\ \text{MQTT annual} &= 525{,}600 \times 154 = 80.9 \text{ MB} \\ \text{Savings} &= \frac{80.9 - 35.7}{80.9} \times 100\% = 56\% \end{align}$$

Battery impact (10 mW TX power, 250 kbps data rate):

$$\begin{align} \text{TX time (CoAP)} &= \frac{68 \times 8}{250{,}000} = 2.2 \text{ ms} \\ \text{TX time (MQTT)} &= \frac{154 \times 8}{250{,}000} = 4.9 \text{ ms} \\ \text{Energy per message} &: \text{CoAP } 22 \mu\text{J vs MQTT } 49 \mu\text{J (2.2×)} \end{align}$$

3.6.7 Calculation Audit

The estimate uses decimal megabytes and treats the MQTT TCP acknowledgment as radio-on airtime under the same 250 kbps link budget. The raw arithmetic is:

Read these points as one connected sequence: start with One year at a 60-second interval is 365 x 24 x 3600 / 60 = 525,600 messages; then CoAP traffic is 525,600 x 68 = 35,740,800 bytes, or 35.7 MB using 1 MB = 1,000,000 bytes; then MQTT traffic is 525,600 x 154 = 80,942,400 bytes, or 80.9 MB on the same decimal basis; then The byte reduction is 80,942,400 - 35,740,800 = 45,201,600 bytes, so the saving is 45,201,600 / 80,942,400 = 0.558, about 56%; then CoAP airtime is 68 x 8 / 250,000 = 0.002176 s; at 10 mW = 0.010 J/s, that is 0.010 x 0.002176 = 0.00002176 J, or 21.76 uJ; and finish with MQTT airtime is 154 x 8 / 250,000 = 0.004928 s; at the same power, that is 49.28 uJ.

• One year at a 60-second interval is 365 x 24 x 3600 / 60 = 525,600 messages.
• CoAP traffic is 525,600 x 68 = 35,740,800 bytes, or 35.7 MB using 1 MB = 1,000,000 bytes.
• MQTT traffic is 525,600 x 154 = 80,942,400 bytes, or 80.9 MB on the same decimal basis.
• The byte reduction is 80,942,400 - 35,740,800 = 45,201,600 bytes, so the saving is 45,201,600 / 80,942,400 = 0.558, about 56%.
• CoAP airtime is 68 x 8 / 250,000 = 0.002176 s; at 10 mW = 0.010 J/s, that is 0.010 x 0.002176 = 0.00002176 J, or 21.76 uJ.
• MQTT airtime is 154 x 8 / 250,000 = 0.004928 s; at the same power, that is 49.28 uJ.

For a measured device budget, split transmit, receive, idle-listen, retries, and connection setup into separate states. This panel is a protocol-overhead comparison, not a battery-life proof for every radio.

3.7 Interactive Protocol Overhead Calculator

3.8 Protocol Selection Framework

3.9 Continue to Part 2

Continue with CoAP and MQTT: Brokers and Selection Evidence.