658  IoT Application Layer Protocols

CoAP vs MQTT and Protocol Comparison

NoteLearning Objectives

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

• Compare CoAP and MQTT application protocols for IoT
• Understand request-response vs publish-subscribe communication patterns
• Use interactive tools to compare protocol characteristics
• Identify when to use CoAP vs MQTT based on requirements
• Understand the role of HTTP and AMQP in IoT systems

658.1 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).

658.1.1 Communication Patterns

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#E8F6F3'}}}%%
graph TB
    subgraph "Request-Response (CoAP)"
        Client1["Client<br/>(Sensor)"]
        Server1["Server<br/>(Gateway)"]
        Client1 -->|"GET /temperature"| Server1
        Server1 -->|"2.05 Content: 25.5°C"| Client1
    end

    subgraph "Publish-Subscribe (MQTT)"
        Pub["Publisher<br/>(Sensor)"]
        Broker["MQTT Broker"]
        Sub1["Subscriber<br/>(Dashboard)"]
        Sub2["Subscriber<br/>(Logger)"]
        Pub -->|"PUBLISH home/temp: 25.5"| Broker
        Broker -->|"25.5°C"| Sub1
        Broker -->|"25.5°C"| Sub2
    end

    style Client1 fill:#16A085,stroke:#2C3E50,color:#fff
    style Server1 fill:#2C3E50,stroke:#16A085,color:#fff
    style Pub fill:#E67E22,stroke:#2C3E50
    style Broker fill:#2C3E50,stroke:#16A085,color:#fff
    style Sub1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style Sub2 fill:#7F8C8D,stroke:#2C3E50,color:#fff

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

{fig-alt=“Two communication patterns: CoAP showing client-server request-response with GET and Content messages, MQTT showing publisher sending to broker which fans out to multiple subscribers”}

658.1.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

658.1.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)
+-+-+-+-+-+-+-+-+-+-+...

658.1.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

TipFor 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

658.2 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: ["#1976d2", "#16A085", "#7F8C8D", "#E67E22", "#8e44ad"]
    },
    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.area(points, {
            x: "x",
            y: "y",
            fill: protocol.name,
            fillOpacity: 0.15,
            curve: "linear-closed"
          }),
          Plot.line(points, {
            x: "x",
            y: "y",
            stroke: protocol.name,
            strokeWidth: 2.5,
            curve: "linear-closed"
          })
        ];
      }).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: ["#1976d2", "#16A085", "#7F8C8D", "#E67E22", "#8e44ad"]
  },
  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 10x lower overhead (4 bytes vs 40+ bytes).

**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>`

TipHow 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)

658.3 Other Application Protocols

658.3.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

658.3.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

658.3.3 WebSocket

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

NoteKnowledge Check: Application Protocols

Question: An industrial monitoring system compares CoAP (UDP-based, 4-byte header) vs MQTT (TCP-based, 2-byte header + TCP overhead) for 500 sensors sending 10-byte readings every 30 seconds. Network analysis shows 15% packet loss. CoAP uses confirmable messages with exponential backoff averaging 1.2s including retries. MQTT uses TCP retransmission (200ms RTT) but requires 600ms TCP connection setup. Which protocol minimizes latency for real-time alerts while handling packet loss?

Explanation: For real-time industrial monitoring, CoAP’s connectionless UDP provides: (1) No TCP setup delay (600ms savings), (2) Lower total overhead (32 bytes: 6+4+4+10 for 6LoWPAN+UDP+CoAP+data vs 42 bytes: 6+20+2+10 for 6LoWPAN+TCP+MQTT+data), (3) Predictable 1.2s average latency including retries, (4) No connection state management required. Despite MQTT’s smaller application header (2 bytes vs 4), the TCP overhead (20 bytes) makes total packet size larger. CoAP excels for direct sensor-to-gateway communication in lossy industrial environments where sensors sleep/wake intermittently.

Question: A healthcare IoT system transmits ECG data (250 Hz sampling, 2 bytes/sample = 500 bytes/sec) from wearables to monitoring stations. IEEE 802.15.4 provides 250 kbps with 102-byte usable payload. The application requires < 100ms latency for arrhythmia detection. Comparing protocol stacks: HTTP/TCP/IPv4 (162 bytes overhead), MQTT/TCP/6LoWPAN (94 bytes overhead), and CoAP/UDP/6LoWPAN (39 bytes overhead), which minimizes transmission time and meets latency requirements?

Explanation: For real-time medical IoT, CoAP/UDP/6LoWPAN provides: (1) Minimal overhead (39 bytes) allows 63-byte payload in single 102-byte frame, (2) No fragmentation for typical sensor readings, (3) Lowest latency: 1.89ms (CoAP) vs 8.65ms (MQTT with TCP overhead) vs 10.82ms (HTTP), (4) Connectionless operation ideal for intermittent wearable sensors, (5) Best payload efficiency: 33.9% vs 17.5% (MQTT) vs 11.0% (HTTP). HTTP requires 162 bytes overhead needing 2+ frames just for headers. While all technically meet 100ms requirement, CoAP provides 4.6x lower latency than MQTT.

658.4 Summary

TipKey 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]

658.5 What’s Next?

Continue to Protocol Selection Guide for comprehensive decision frameworks and interactive tools to choose the right protocol combination for your IoT deployment.