24  IoT Application Layer Protocols

CoAP vs MQTT and Protocol Comparison

Key Concepts

• Application Layer Protocol: The topmost protocol layer responsible for encoding, transporting, and interpreting application data between devices and services
• MQTT: A publish-subscribe messaging protocol designed for constrained devices; uses a broker to decouple publishers and subscribers
• CoAP: Constrained Application Protocol; a RESTful protocol designed for UDP that mirrors HTTP semantics with minimal overhead
• AMQP: Advanced Message Queuing Protocol; a broker-based protocol with rich routing, reliability, and security features for enterprise IoT
• Publish-Subscribe Pattern: A messaging pattern where senders (publishers) emit messages to named topics, and receivers (subscribers) consume only the topics they register for
• QoS Level: A guaranteed delivery tier; MQTT offers QoS 0 (fire-and-forget), 1 (at-least-once), and 2 (exactly-once)
• Topic Hierarchy: A slash-separated namespace (e.g., building/floor2/room3/temp) used in MQTT to organise and filter messages

24.1 In 60 Seconds

The IoT application layer is dominated by two protocols: CoAP (request-response over UDP, like a lightweight HTTP for constrained devices) and MQTT (publish-subscribe over TCP, ideal for scalable telemetry with a broker). Choose CoAP for direct device-to-device communication with minimal overhead; choose MQTT when you need one-to-many distribution, persistent sessions, and QoS guarantees through a central broker.

Learning Objectives

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

• Compare CoAP and MQTT architectures, overhead, and QoS mechanisms
• Differentiate request-response and publish-subscribe communication patterns
• Apply interactive tools to benchmark protocol characteristics
• Select CoAP or MQTT based on device constraints and deployment requirements
• Evaluate the role of HTTP, AMQP, and WebSocket in IoT systems

Sensor Squad: CoAP or MQTT? The Big Decision!

“I need to send my temperature data to the cloud,” said Sammy the Sensor. “Should I use CoAP or MQTT?” Max the Microcontroller asked two questions. “First, are you talking to one server or broadcasting to many listeners? Second, do you run on batteries or mains power?”

“I am battery-powered and I send directly to one gateway,” said Sammy. “Then CoAP is perfect for you,” Max replied. “It runs on UDP, has only a 4-byte header, and works like a web request – you ask, the server answers. Super lightweight for constrained devices.”

Lila the LED had different needs. “I am a smart light that needs to listen for commands from MULTIPLE sources – a phone app, a voice assistant, and a schedule timer.” Max nodded. “MQTT is your choice. You subscribe to a topic like ‘living-room/lights’ and the broker delivers any message published to that topic. One-to-many communication through a central hub.”

“Think of CoAP as a phone call – direct, one-to-one,” summarized Bella the Battery. “And MQTT as a radio station – one broadcast, many listeners. CoAP uses less energy because UDP has no connection overhead. MQTT is more reliable because TCP guarantees delivery. Match the protocol to your communication pattern!”

24.2 Application Layer: CoAP vs MQTT

The application layer defines how IoT devices exchange meaningful data. Two protocols dominate: CoAP (Constrained Application Protocol) and MQTT (Message Queue Telemetry Transport).

24.2.1 Communication Patterns

Figure 24.1: Request-response (CoAP) vs Publish-subscribe (MQTT) communication patterns

24.2.2 CoAP (Constrained Application Protocol)

Overview: CoAP is “HTTP for IoT” - a RESTful protocol designed for constrained devices and networks.

Characteristic	CoAP	Comparison
Transport	UDP (port 5683)	No connection overhead
Header size	4 bytes fixed	vs HTTP ~200+ bytes
Message types	CON, NON, ACK, RST	Confirmable or fire-and-forget
Methods	GET, PUT, POST, DELETE	Same as HTTP REST
Security	DTLS	Datagram TLS for UDP
Observation	Observe option	Server push notifications

CoAP Message Format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T |  TKL  |      Code     |          Message ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Token (0-8 bytes)           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
|                       Options (if any)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1|    Payload (if any)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CoAP Message Types:

• CON (Confirmable): Requires ACK, provides reliability
• NON (Non-confirmable): Fire-and-forget, no ACK
• ACK (Acknowledgment): Response to CON
• RST (Reset): Reject message or indicate error

24.2.3 MQTT (Message Queue Telemetry Transport)

Overview: MQTT is a lightweight publish-subscribe protocol optimized for unreliable networks.

Characteristic	MQTT	Comparison
Transport	TCP (port 1883, 8883 for TLS)	Reliable delivery
Header size	2 bytes minimum	Very compact
Message types	CONNECT, PUBLISH, SUBSCRIBE…	Full message lifecycle
QoS levels	0, 1, 2	At-most-once to exactly-once
Security	TLS	Standard TCP encryption
Broker	Required	Central message routing

MQTT QoS Levels:

• QoS 0 (At most once): Fire-and-forget, no acknowledgment
• QoS 1 (At least once): Acknowledged delivery, may duplicate
• QoS 2 (Exactly once): Four-way handshake, guaranteed single delivery

MQTT Fixed Header:

 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
| Type  |D|Q|R|  <- Control packet type + flags
+-+-+-+-+-+-+-+-+
| Remaining Length (1-4 bytes, variable)
+-+-+-+-+-+-+-+-+-+-+...

24.2.4 Side-by-Side Comparison

Feature	CoAP	MQTT
Architecture	Client-Server	Publish-Subscribe
Transport	UDP	TCP
Overhead	4 bytes + options	2 bytes + topic
Reliability	Application layer (CON/NON)	Transport layer (TCP) + QoS
Power	Lower (connectionless)	Higher (keep-alive)
Scalability	Direct 1-to-1	Broker handles fan-out
Latency	Lower (no handshake)	Higher (TCP setup)
Multicast	Native support	Requires broker topics
Discovery	CoRE Link Format	Topic conventions
Caching	Built-in (ETag, Max-Age)	Application-level
Best for	Constrained devices, local control	Cloud telemetry, many subscribers

For Beginners: When to Use CoAP vs MQTT

Use CoAP when:

• Device is battery-powered (no TCP keep-alive drain)
• Device has < 32KB RAM (smaller stack)
• You need direct device-to-device communication
• Low latency is critical (no TCP handshake)
• You want RESTful API style (GET/PUT/POST)

Use MQTT when:

• Many devices send to one cloud (fan-in)
• One message goes to many subscribers (fan-out)
• You need guaranteed delivery (QoS 1/2)
• Device is mains-powered (can afford TCP overhead)
• Cloud platform already uses MQTT (AWS IoT, Azure IoT Hub)

Hybrid Approach: Many IoT systems use both:

[Sensor] --CoAP/UDP--> [Gateway] --MQTT/TCP--> [Cloud]

• CoAP for battery-efficient sensor-to-gateway
• MQTT for reliable gateway-to-cloud

24.3 Interactive Protocol Comparison Tool

Use this advanced tool to compare IoT application protocols across multiple dimensions:

protocolData = [
  {
    name: "MQTT",
    description: "Pub/sub, TCP-based, broker architecture",
    transport: "TCP (port 1883)",
    bandwidth: 6,
    latency: 5,
    power: 4,
    security: 8,
    complexity: 7,
    scalability: 9,
    reliability: 9,
    overhead: 7
  },
  {
    name: "CoAP",
    description: "RESTful, UDP-based, client-server",
    transport: "UDP (port 5683)",
    bandwidth: 9,
    latency: 8,
    power: 9,
    security: 7,
    complexity: 8,
    scalability: 6,
    reliability: 6,
    overhead: 9
  },
  {
    name: "HTTP",
    description: "Web standard, text-based, request-response",
    transport: "TCP (port 80/443)",
    bandwidth: 3,
    latency: 4,
    power: 2,
    security: 8,
    complexity: 9,
    scalability: 7,
    reliability: 8,
    overhead: 2
  },
  {
    name: "AMQP",
    description: "Enterprise messaging, complex routing",
    transport: "TCP (port 5672)",
    bandwidth: 5,
    latency: 4,
    power: 3,
    security: 9,
    complexity: 5,
    scalability: 8,
    reliability: 10,
    overhead: 4
  },
  {
    name: "WebSocket",
    description: "Full-duplex, browser-compatible",
    transport: "TCP (port 80/443)",
    bandwidth: 7,
    latency: 7,
    power: 5,
    security: 8,
    complexity: 6,
    scalability: 7,
    reliability: 8,
    overhead: 6
  }
]

viewof selectedProtocols = Inputs.checkbox(
  protocolData.map(p => p.name),
  {
    label: "Select Protocols to Compare:",
    value: ["MQTT", "CoAP"]
  }
)

selectedData = protocolData.filter(p => selectedProtocols.includes(p.name))

// Radar/spider chart for multi-dimensional comparison
{
  const metrics = ["Bandwidth", "Latency", "Power", "Security", "Complexity", "Scalability", "Reliability", "Overhead"];
  const angleStep = (2 * Math.PI) / metrics.length;

  return Plot.plot({
    width: 640,
    height: 500,
    margin: 60,
    x: {axis: null, domain: [-12, 12]},
    y: {axis: null, domain: [-12, 12]},
    color: {
      domain: protocolData.map(p => p.name),
      range: ["#3498DB", "#16A085", "#7F8C8D", "#E67E22", "#9B59B6"]
    },
    marks: [
      // Background grid circles
      ...Array.from({length: 10}, (_, i) => {
        const r = (i + 1);
        const points = Array.from({length: metrics.length + 1}, (_, j) => {
          const angle = j * angleStep - Math.PI / 2;
          return {x: r * Math.cos(angle), y: r * Math.sin(angle)};
        });
        return Plot.line(points, {
          x: "x",
          y: "y",
          stroke: i === 9 ? "#999" : "#ddd",
          strokeWidth: i === 9 ? 2 : 1
        });
      }),

      // Axis lines from center to edge
      ...metrics.map((_, i) => {
        const angle = i * angleStep - Math.PI / 2;
        return Plot.line([
          {x: 0, y: 0},
          {x: 10 * Math.cos(angle), y: 10 * Math.sin(angle)}
        ], {
          x: "x",
          y: "y",
          stroke: "#999",
          strokeWidth: 1
        });
      }),

      // Protocol data as filled polygons
      ...selectedData.map(protocol => {
        const values = [
          protocol.bandwidth,
          protocol.latency,
          protocol.power,
          protocol.security,
          protocol.complexity,
          protocol.scalability,
          protocol.reliability,
          protocol.overhead
        ];

        const points = metrics.map((_, i) => {
          const angle = i * angleStep - Math.PI / 2;
          const r = values[i];
          return {
            x: r * Math.cos(angle),
            y: r * Math.sin(angle),
            protocol: protocol.name
          };
        });

        // Close the polygon
        points.push({...points[0]});

        return [
          Plot.line(points, {
            x: "x",
            y: "y",
            stroke: protocol.name,
            strokeWidth: 2.5,
            curve: "linear-closed"
          }),
          Plot.dot(points.slice(0, -1), {
            x: "x",
            y: "y",
            fill: protocol.name,
            r: 3
          })
        ];
      }).flat(),

      // Metric labels
      ...metrics.map((label, i) => {
        const angle = i * angleStep - Math.PI / 2;
        const r = 11.5;
        return Plot.text([{
          x: r * Math.cos(angle),
          y: r * Math.sin(angle),
          label: label
        }], {
          x: "x",
          y: "y",
          text: "label",
          fontSize: 12,
          fontWeight: "bold",
          fill: "#2C3E50"
        });
      }),

      // Center dot
      Plot.dot([{x: 0, y: 0}], {r: 3, fill: "#2C3E50"})
    ],
    style: {
      background: "white"
    }
  });
}

// Bar chart comparison
Plot.plot({
  width: 640,
  height: 350,
  marginLeft: 120,
  color: {
    domain: protocolData.map(p => p.name),
    range: ["#3498DB", "#16A085", "#7F8C8D", "#E67E22", "#9B59B6"]
  },
  x: {
    label: "Performance Score (0-10, higher is better) -->",
    domain: [0, 10],
    grid: true
  },
  y: {
    label: "Metrics"
  },
  marks: [
    Plot.barX(
      selectedData.flatMap(p => [
        {protocol: p.name, metric: "Bandwidth Efficiency", value: p.bandwidth},
        {protocol: p.name, metric: "Low Latency", value: p.latency},
        {protocol: p.name, metric: "Power Efficiency", value: p.power},
        {protocol: p.name, metric: "Security Level", value: p.security},
        {protocol: p.name, metric: "Implementation Simplicity", value: p.complexity},
        {protocol: p.name, metric: "Scalability", value: p.scalability},
        {protocol: p.name, metric: "Reliability", value: p.reliability},
        {protocol: p.name, metric: "Low Overhead", value: p.overhead}
      ]),
      {
        x: "value",
        y: "metric",
        fill: "protocol",
        opacity: 0.8,
        tip: true
      }
    ),
    Plot.ruleX([0])
  ]
})

// Detailed comparison table
md`### Detailed Protocol Characteristics

| Metric | ${selectedData.map(p => `**${p.name}**`).join(' | ')} |
|--------|${selectedData.map(() => '---').join('|')}|
| **Description** | ${selectedData.map(p => p.description).join(' | ')} |
| **Transport** | ${selectedData.map(p => p.transport).join(' | ')} |
| **Bandwidth Efficiency** | ${selectedData.map(p => `${p.bandwidth}/10`).join(' | ')} |
| **Latency** | ${selectedData.map(p => `${p.latency}/10`).join(' | ')} |
| **Power Efficiency** | ${selectedData.map(p => `${p.power}/10`).join(' | ')} |
| **Security** | ${selectedData.map(p => `${p.security}/10`).join(' | ')} |
| **Simplicity** | ${selectedData.map(p => `${p.complexity}/10`).join(' | ')} |
| **Scalability** | ${selectedData.map(p => `${p.scalability}/10`).join(' | ')} |
| **Reliability** | ${selectedData.map(p => `${p.reliability}/10`).join(' | ')} |
| **Low Overhead** | ${selectedData.map(p => `${p.overhead}/10`).join(' | ')} |`

useCaseRecommendations = {
  const recommendations = [];

  if (selectedProtocols.includes("MQTT") && selectedProtocols.includes("CoAP")) {
    recommendations.push({
      title: "MQTT vs CoAP: Classic IoT Comparison",
      content: `**Choose CoAP** for battery-powered sensors (<32KB RAM), direct device control, or multicast needs. Example: Temperature sensors in a building.

**Choose MQTT** for cloud-connected telemetry, many publishers/subscribers, or dashboard integration. Example: Smart home data to cloud platform.

**Hybrid Strategy**: CoAP for sensor-to-gateway (constrained network), MQTT for gateway-to-cloud (reliable network).`
    });
  }

  if (selectedProtocols.includes("CoAP") && selectedProtocols.includes("HTTP")) {
    recommendations.push({
      title: "CoAP vs HTTP: Constrained vs Web",
      content: `**Choose CoAP** when devices are resource-constrained. CoAP is "HTTP for IoT" with RESTful semantics but dramatically lower overhead (4-byte application header + 8-byte UDP vs 200+ byte HTTP headers + 20-byte TCP).

**Choose HTTP** for well-resourced devices needing maximum web compatibility. HTTP/2 improves efficiency but still requires more resources than CoAP.

**Key Difference**: UDP (CoAP) vs TCP (HTTP) - CoAP saves power by avoiding connection setup.`
    });
  }

  if (selectedProtocols.includes("MQTT") && selectedProtocols.includes("AMQP")) {
    recommendations.push({
      title: "MQTT vs AMQP: IoT vs Enterprise",
      content: `**Choose AMQP** for enterprise messaging with complex routing, transactional guarantees, or financial systems. Richer features but higher complexity.

**Choose MQTT** for lightweight IoT telemetry, simpler implementation, or resource-constrained devices. More widely adopted in IoT.

**Use Case Split**: AMQP for business-critical messaging, MQTT for sensor data collection.`
    });
  }

  if (selectedProtocols.includes("WebSocket")) {
    recommendations.push({
      title: "WebSocket for Real-Time IoT",
      content: `**Choose WebSocket** when you need bidirectional real-time communication with web browsers. Perfect for live dashboards, chat-like interactions, or streaming data.

**Advantage**: Full-duplex communication over a single TCP connection after initial HTTP handshake.

**Trade-off**: Persistent connection requires more power than CoAP but less overhead than repeated HTTP requests.`
    });
  }

  // General low-power recommendation
  if (selectedProtocols.includes("CoAP")) {
    recommendations.push({
      title: "Low-Power Applications",
      content: `For battery-powered sensors requiring years of operation, **CoAP over UDP** is optimal:
- 4-byte header (vs 40+ for HTTP)
- No TCP connection overhead
- Connectionless = no keep-alive packets
- Optional confirmable messages only when needed`
    });
  }

  // General cloud recommendation
  if (selectedProtocols.includes("MQTT")) {
    recommendations.push({
      title: "Cloud Integration",
      content: `For cloud-connected IoT with many devices, **MQTT** excels:
- Pub/Sub decouples publishers from subscribers
- Broker handles fan-in from thousands of devices
- Cloud platforms (AWS IoT, Azure IoT Hub) natively support MQTT
- Last Will Testament (LWT) for device offline detection`
    });
  }

  // Security-focused recommendation
  if (selectedData.some(p => p.security >= 8)) {
    recommendations.push({
      title: "Security Considerations",
      content: `**High-security protocols** in your selection:
- **MQTT/HTTP/WebSocket**: Use TLS/SSL for encryption
- **CoAP**: Use DTLS (Datagram TLS) for UDP
- **AMQP**: TLS + SASL authentication

**Trade-off**: Security overhead increases power consumption. For extremely constrained devices, consider application-level encryption.`
    });
  }

  return recommendations;
}

html`<div style="margin-top: 20px;">
  <h3 style="color: #2C3E50; border-bottom: 2px solid #16A085; padding-bottom: 10px;">
    Use Case Recommendations
  </h3>
  ${useCaseRecommendations.map(rec => `
    <div style="background: #f8f9fa; border-left: 4px solid #16A085; padding: 15px; margin: 15px 0; border-radius: 4px;">
      <h4 style="margin-top: 0; color: #2C3E50;">${rec.title}</h4>
      <div style="line-height: 1.6; white-space: pre-line;">${rec.content}</div>
    </div>
  `).join('')}
</div>`

How to Use This Protocol Analyzer

1. Select Protocols: Check 2-3 protocols from the list above to compare them
2. Analyze the Radar Chart: The radar chart shows 8 key metrics on a 0-10 scale (higher = better). Each protocol appears as a colored polygon - larger areas indicate better overall performance
3. Review Bar Charts: Compare protocols side-by-side across individual metrics
4. Read Recommendations: Use case-specific guidance appears at the bottom based on your selection

Understanding the Metrics:

• Bandwidth Efficiency: How well the protocol uses available bandwidth (low overhead = high score)
• Latency: Response time (lower latency = higher score)
• Power Efficiency: Battery life impact (lower power consumption = higher score)
• Security: Built-in security features and robustness
• Simplicity: Ease of implementation and understanding
• Scalability: Ability to handle many devices/connections
• Reliability: Message delivery guarantees
• Low Overhead: Header size and protocol overhead (smaller = higher score)

24.4 Worked Example: Choosing a Protocol Stack for a Cold-Chain Logistics Fleet

A pharmaceutical company ships temperature-sensitive vaccines across 200 refrigerated trucks. Each truck has a sensor that measures temperature every 60 seconds and must alert the cloud within 5 seconds if temperature leaves the 2–8 °C safe range. The gateway in each truck has an LTE-M modem (cellular backhaul). Design the protocol stack from sensor to cloud.

Step 1: Characterise the traffic.

Parameter	Value
Normal readings	50 bytes every 60 s (timestamp + temp + humidity + GPS)
Alert messages	Same 50 bytes, but delivery must be confirmed
Fleet size	200 trucks
Uplink bandwidth per truck	50 B / 60 s = 0.83 B/s = 6.7 bps
Fleet aggregate	200 x 6.7 bps = 1,340 bps (~1.3 kbps)

The cloud also needs to push firmware updates (~100 KB) to each truck once per quarter and send configuration changes (100 bytes) ad hoc.

Step 2: Score each candidate.

Requirement	CoAP	MQTT	HTTP
50-byte payload efficiency	4+50 = 54 B (UDP)	2+topic+50 ~= 72 B (TCP)	200+ header + 50 B (TCP)
Confirmed delivery for alerts	CON message + ACK = 2 packets	QoS 1 PUBLISH + PUBACK = 2 packets	POST + 200 OK = 2 packets
Downlink firmware push	Blockwise transfer (RFC 7959)	Broker publish to device topic	Standard HTTP download
Fan-out to monitoring dashboard	Not native (1-to-1)	Broker fans out to N subscribers	Requires polling or SSE
Keep-alive overhead on LTE-M	None (connectionless)	PINGREQ every 30–60 s	TCP keep-alive or reconnect
RAM on sensor MCU (Cortex-M0, 32 KB)	~4 KB stack	~8–12 KB stack (TCP + MQTT)	~20 KB (TCP + HTTP parser)

Step 3: Design the hybrid stack.

The numbers point toward a split architecture:

[Sensor MCU] --CoAP/UDP--> [Truck Gateway] --MQTT/TLS--> [Cloud Broker] --HTTP--> [Dashboard]

• Sensor to gateway (CoAP): The MCU has only 32 KB RAM. CoAP’s 4 KB stack fits comfortably, and UDP’s connectionless design means no keep-alive drain on the MCU’s power budget. Normal readings use NON (non-confirmable) messages; temperature alerts use CON (confirmable) with a 2-second ACK timeout, well within the 5-second alert window.

• Gateway to cloud (MQTT QoS 1): The gateway is a Linux SBC with 512 MB RAM, so MQTT’s TCP overhead is irrelevant. MQTT’s publish-subscribe architecture means the same temperature data reaches both the alert engine and the analytics pipeline without duplication. The gateway publishes to fleet/{truckId}/telemetry and fleet/{truckId}/alerts.

• Firmware downloads: The cloud publishes firmware chunks to fleet/{truckId}/ota using MQTT QoS 1. The gateway assembles chunks and flashes the sensor MCU over SPI.

Step 4: Quantify the overhead savings.

Over 24 hours, one truck sends 1,440 normal readings + ~2 alerts:

Metric	CoAP (sensor-to-GW)	If we used MQTT instead
Packet overhead per reading	4 B (CoAP) + 8 B (UDP) = 12 B	2 B (MQTT) + 20 B (TCP) = 22 B
Daily overhead	1,440 x 12 = 17.3 KB	1,440 x 22 = 31.7 KB
Keep-alive	0 B (stateless)	60 x 4 B PINGREQ/PINGRESP = 240 B/hr = 5.8 KB/day
Total daily overhead	17.3 KB	37.5 KB
TCP connection setup	0 (UDP)	3-way handshake at startup + reconnects

CoAP saves 54% of protocol overhead on the constrained sensor-to-gateway link, and eliminates keep-alive traffic entirely.

Putting Numbers to It

Comparing CoAP versus MQTT overhead requires calculating total bytes transmitted per day, including application headers, transport headers, and keep-alive traffic.

CoAP/UDP (connectionless): \[\text{Per reading} = H_{\text{CoAP}} + H_{\text{UDP}} + H_{\text{IP}} + P\] \[= 4 + 8 + 40 + 50 = 102 \text{ bytes}\]

With 6LoWPAN compression reducing IP header from 40 to 6 bytes: \[\text{Per reading}_{\text{compressed}} = 4 + 8 + 6 + 50 = 68 \text{ bytes}\]

Daily overhead (1,440 readings/day): \[O_{\text{CoAP}} = 1{,}440 \times 68 = 97{,}920 \text{ bytes} = 95.6 \text{ KB/day}\]

MQTT/TCP (connection-oriented): \[\text{Per reading} = H_{\text{MQTT}} + H_{\text{TCP}} + H_{\text{IP}} + P\] \[= 4 + 20 + 40 + 50 = 114 \text{ bytes (MQTT: 2-byte fixed + 2-byte topic length)}\]

Plus PINGREQ/PINGRESP keep-alive every 60 seconds: \[\text{Keep-alive/day} = \frac{86{,}400}{60} \times 2 \times 64 = 184{,}320 \text{ bytes} = 180 \text{ KB/day}\]

\[O_{\text{MQTT}} = (1{,}440 \times 114) + 184{,}320 = 348{,}480 \text{ bytes} = 340.3 \text{ KB/day}\]

Overhead ratio: \[\frac{O_{\text{MQTT}}}{O_{\text{CoAP}}} = \frac{340.3}{95.6} = 3.56\times\]

MQTT uses 3.56× more bandwidth than CoAP for the same sensor-to-gateway link, primarily due to TCP connection overhead and mandatory keep-alive packets. For battery-powered sensors, this translates to proportionally higher radio energy consumption.

Try It: Protocol Overhead Calculator

Adjust your deployment parameters to compare CoAP vs MQTT daily overhead on a sensor-to-gateway link.

viewof payloadSize = Inputs.range([4, 200], {
  label: "Payload size (bytes):",
  value: 50,
  step: 1
})

viewof readingInterval = Inputs.range([5, 600], {
  label: "Reading interval (seconds):",
  value: 60,
  step: 5
})

viewof keepAliveInterval = Inputs.range([15, 300], {
  label: "MQTT keep-alive interval (seconds):",
  value: 60,
  step: 5
})

viewof useCompression = Inputs.toggle({
  label: "Use 6LoWPAN header compression:",
  value: false
})

overheadCalc = {
  const ipHeader = useCompression ? 6 : 40;
  const coapHeader = 4;
  const udpHeader = 8;
  const mqttHeader = 4;  // 2 fixed + 2 topic length
  const tcpHeader = 20;

  const readingsPerDay = Math.floor(86400 / readingInterval);

  // CoAP per-reading total
  const coapPerReading = coapHeader + udpHeader + ipHeader + payloadSize;
  const coapDaily = readingsPerDay * coapPerReading;

  // MQTT per-reading total
  const mqttPerReading = mqttHeader + tcpHeader + ipHeader + payloadSize;
  const mqttReadingsDaily = readingsPerDay * mqttPerReading;

  // MQTT keep-alive: PINGREQ (2B) + PINGRESP (2B), each with TCP+IP headers
  const keepAlivePacketSize = 2 + tcpHeader + ipHeader;
  const keepAlivesPerDay = Math.floor(86400 / keepAliveInterval) * 2;
  const mqttKeepAliveDaily = keepAlivesPerDay * keepAlivePacketSize;
  const mqttDaily = mqttReadingsDaily + mqttKeepAliveDaily;

  const savings = ((mqttDaily - coapDaily) / mqttDaily * 100).toFixed(1);
  const ratio = (mqttDaily / coapDaily).toFixed(2);

  return {
    readingsPerDay, coapPerReading, mqttPerReading,
    coapDaily, mqttDaily, mqttReadingsDaily, mqttKeepAliveDaily,
    keepAlivesPerDay, keepAlivePacketSize, savings, ratio,
    ipHeader, coapHeader, udpHeader, mqttHeader, tcpHeader
  };
}

html`<div style="display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin-top: 12px;">
  <div style="background: #f0faf7; border: 2px solid #16A085; border-radius: 8px; padding: 16px;">
    <h4 style="margin: 0 0 8px 0; color: #16A085;">CoAP/UDP</h4>
    <div style="font-size: 0.95em; line-height: 1.7;">
      <strong>Per reading:</strong> ${overheadCalc.coapPerReading} bytes<br>
      <span style="color: #7F8C8D;">(${overheadCalc.coapHeader} CoAP + ${overheadCalc.udpHeader} UDP + ${overheadCalc.ipHeader} IP + ${payloadSize} payload)</span><br>
      <strong>Readings/day:</strong> ${overheadCalc.readingsPerDay.toLocaleString()}<br>
      <strong>Keep-alive:</strong> 0 bytes (stateless)<br>
      <strong style="font-size: 1.1em; color: #16A085;">Daily total: ${(overheadCalc.coapDaily / 1024).toFixed(1)} KB</strong>
    </div>
  </div>
  <div style="background: #eef4fb; border: 2px solid #3498DB; border-radius: 8px; padding: 16px;">
    <h4 style="margin: 0 0 8px 0; color: #3498DB;">MQTT/TCP</h4>
    <div style="font-size: 0.95em; line-height: 1.7;">
      <strong>Per reading:</strong> ${overheadCalc.mqttPerReading} bytes<br>
      <span style="color: #7F8C8D;">(${overheadCalc.mqttHeader} MQTT + ${overheadCalc.tcpHeader} TCP + ${overheadCalc.ipHeader} IP + ${payloadSize} payload)</span><br>
      <strong>Readings/day:</strong> ${overheadCalc.readingsPerDay.toLocaleString()}<br>
      <strong>Keep-alive:</strong> ${(overheadCalc.mqttKeepAliveDaily / 1024).toFixed(1)} KB/day (${overheadCalc.keepAlivesPerDay.toLocaleString()} packets x ${overheadCalc.keepAlivePacketSize} B)<br>
      <strong style="font-size: 1.1em; color: #3498DB;">Daily total: ${(overheadCalc.mqttDaily / 1024).toFixed(1)} KB</strong>
    </div>
  </div>
</div>
<div style="margin-top: 12px; padding: 12px; background: #fdf6ec; border-left: 4px solid #E67E22; border-radius: 4px;">
  <strong style="color: #E67E22;">Result:</strong> CoAP saves <strong>${overheadCalc.savings}%</strong> of total bandwidth. MQTT uses <strong>${overheadCalc.ratio}x</strong> more bytes than CoAP per day.
</div>`

Connection: Application Protocol Choice meets Transport Protocol Selection

This hybrid CoAP/MQTT architecture mirrors the transport-layer split discussed in TCP vs UDP Fundamentals. At the constrained edge, UDP (and hence CoAP) wins because connectionless operation eliminates keep-alive overhead and reduces MCU RAM requirements. At the gateway-to-cloud boundary, TCP (and hence MQTT) wins because reliable ordered delivery, TLS, and broker fan-out justify the higher overhead on a resource-rich gateway. The protocol boundary at the gateway is where the system transitions from “constrained network” to “reliable network” – a pattern repeated in almost every production IoT deployment.

Quick Check: CoAP vs MQTT Selection

24.5 Other Application Protocols

24.5.1 HTTP for IoT

While not optimized for constrained devices, HTTP remains important for: - Gateway-to-cloud communication: RESTful APIs - Configuration interfaces: Web-based device management - Integration: Connecting to existing web services

HTTP/2 improvements for IoT:

• Header compression (HPACK)
• Multiplexing (multiple requests per connection)
• Server push

24.5.2 AMQP (Advanced Message Queuing Protocol)

Enterprise-grade messaging with: - Complex routing rules - Transactional guarantees - Message acknowledgments - Queue persistence

Best for: Industrial automation, financial systems, enterprise IoT

24.5.3 WebSocket

Full-duplex communication for: - Real-time dashboards - Live data streaming - Browser-based IoT interfaces

Knowledge Check: Application Protocols

Matching Exercise: Protocol Characteristics

Ordering Exercise: Hybrid Protocol Stack Design

Common Pitfalls

1. Using MQTT QoS 2 for All Messages “to be Safe”

QoS 2 requires four-message handshakes per publish, tripling network traffic. For high-frequency sensor readings, this exhausts bandwidth and broker resources. Fix: use QoS 0 for telemetry and QoS 1 only for commands or alarms.

2. Designing Flat MQTT Topic Namespaces

Publishing everything to a single topic like sensors makes filtering impossible and causes all subscribers to receive all messages. Fix: design a hierarchical topic namespace (e.g., site/building/floor/device/metric) from the start.

3. Choosing CoAP Over MQTT Without Considering Broker Availability

CoAP is peer-to-peer and works without a broker, but loses publish-subscribe fan-out capabilities. Fix: use CoAP when direct device-to-device or device-to-server REST semantics are needed; use MQTT when fan-out to multiple consumers is required.

4. Ignoring Payload Encoding Efficiency

JSON payloads are human-readable but expensive: a reading of {"temperature": 23.5} is 22 bytes; the same in CBOR is 5 bytes. Fix: use binary encoding (CBOR, MessagePack) for high-frequency sensor data on constrained links.

Label the Diagram

Code Challenge

24.6 Summary

Key Takeaways

CoAP (Constrained Application Protocol):

• RESTful semantics (GET/PUT/POST/DELETE) like HTTP
• UDP transport with 4-byte header
• Confirmable (CON) or Non-confirmable (NON) messages
• Best for: constrained devices, low power, direct communication

MQTT (Message Queue Telemetry Transport):

• Publish-subscribe pattern with broker
• TCP transport with 2-byte minimum header
• QoS 0/1/2 for delivery guarantees
• Best for: cloud telemetry, many subscribers, reliable delivery

Protocol Selection:

• Battery-powered sensors: CoAP (no keep-alive overhead)
• Cloud dashboards: MQTT (broker scales subscribers)
• Web integration: HTTP (universal compatibility)
• Enterprise messaging: AMQP (transactional guarantees)
• Real-time browser: WebSocket (full-duplex)

Hybrid Architecture: Most IoT systems use multiple protocols:

[Sensor] --CoAP--> [Gateway] --MQTT--> [Cloud] --HTTP--> [App]

24.7 Concept Relationships

Understanding how application layer protocol concepts interconnect:

• Communication patterns (request-response vs publish-subscribe) determine protocol architecture — CoAP client-server vs MQTT broker-based
• Transport layer choice (UDP vs TCP) directly impacts power consumption — CoAP connectionless saves battery vs MQTT keep-alive drain
• Protocol overhead (4-byte CoAP vs 2-byte MQTT headers) interacts with transport overhead (8-byte UDP vs 20+ byte TCP) to determine total packet size
• QoS levels (MQTT 0/1/2) trade reliability for latency and power — exactly-once delivery uses 4-way handshake
• Hybrid architectures leverage protocol strengths: CoAP for sensor-to-gateway (constrained network), MQTT for gateway-to-cloud (reliable network)

24.8 See Also

Application Protocol Deep Dives:

• MQTT Fundamentals - Publish-subscribe messaging
• CoAP Fundamentals - RESTful for constrained devices
• Application Protocols Overview - HTTP, AMQP comparison

Protocol Selection:

• Protocol Selection Guide - Decision frameworks and tools
• IoT Protocols Fundamentals - Protocol stack architecture

Transport Layer:

• TCP vs UDP Fundamentals - Connection vs connectionless trade-offs

Design Patterns:

• REST API Design Patterns - API versioning and best practices
• Real-time Protocols - WebSocket, SIP, RTP

24.9 What’s Next?

Direction	Chapter	Description
Next	Protocol Selection Guide	Decision frameworks and interactive tools for choosing protocols
Previous	IoT Protocols Fundamentals	Protocol stack architecture and layering concepts
Deep Dive	MQTT Fundamentals	Detailed MQTT publish-subscribe messaging
Deep Dive	CoAP Fundamentals	Detailed CoAP RESTful protocol architecture