1176  CoAP vs MQTT: Detailed Protocol Comparison

1176.1 Learning Objectives

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

  • Compare Architecture Models: Differentiate between CoAP’s request-response and MQTT’s publish-subscribe patterns
  • Evaluate Transport Trade-offs: Analyze UDP vs TCP implications for IoT deployments
  • Assess QoS Options: Compare reliability mechanisms in both protocols
  • Calculate Protocol Overhead: Understand header sizes and efficiency implications
  • Select Protocols: Make informed decisions based on specific requirements

1176.2 Prerequisites

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

1176.3 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:

1176.3.1 Architecture and Communication Model

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.
Figure 1176.1

Comparison table showing CoAP versus MQTT across dimensions including transport protocol (UDP vs TCP), messaging pattern (request-response vs publish-subscribe), effectiveness in LLNs, security mechanisms (DTLS vs SSL/TLS), and relative strengths and weaknesses for IoT applications

CoAP vs MQTT Protocol Comparison
Figure 1176.2: Visual comparison of CoAP and MQTT protocol characteristics

1176.3.2 Network and Transport

Aspect CoAP MQTT
Transport UDP (User Datagram Protocol) TCP (Transmission Control Protocol)
Reliability Optional confirmable messages TCP ensures delivery
Overhead Very low (4-byte header) Low (2-byte header + TCP)
Connection Connectionless Persistent connection
Latency Lower (no handshake) Slightly higher (TCP handshake)

1176.3.3 Quality of Service and Reliability

Aspect CoAP MQTT
Message Types CON (confirmable), NON (non-confirmable) QoS 0, 1, 2
Acknowledgment Optional ACK messages Depends on QoS level
Retransmission Application handles it QoS 1&2 handle automatically
Duplicate Detection Message IDs Packet identifiers

1176.3.4 Security

Aspect CoAP MQTT
Security Layer DTLS (Datagram TLS) TLS/SSL
Authentication Pre-shared keys, certificates Username/password, certificates
Encryption Yes (with DTLS) Yes (with TLS)
Overhead DTLS adds overhead to UDP TLS integrated with TCP

1176.3.5 Resource Usage

Aspect CoAP MQTT
Memory Footprint Minimal Small
Power Consumption Very low (UDP, sleep modes) Low (keep-alive messages)
Battery Life Excellent Very good
Bandwidth Very efficient Efficient

1176.3.6 Design Philosophy

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

1176.4 Protocol Selection Framework

TipTradeoff: HTTP vs MQTT vs CoAP

Decision context: When selecting an application protocol for IoT communication

Factor HTTP MQTT CoAP
Battery impact High (connection overhead) Medium (persistent TCP) Low (connectionless UDP)
Bandwidth High (verbose headers) Low (2-byte header) Very low (4-byte header)
Latency Medium-High (TCP + headers) Low (persistent connection) Lowest (UDP, no handshake)
Reliability TCP guaranteed QoS 0/1/2 options Optional CON/NON
Complexity Simple (universal) Moderate (broker required) Low (direct communication)
Pattern Request-Response Publish-Subscribe Request-Response + Observe
Ecosystem Universal Strong IoT Growing

Choose HTTP when:

  • Integrating with existing web infrastructure and REST APIs
  • Building mobile/web apps that communicate with gateways or cloud
  • Debugging and development simplicity is priority
  • Bandwidth and battery constraints are not critical (Wi-Fi/Ethernet devices)

Choose MQTT when:

  • Many devices need to publish to or subscribe from a central system
  • Event-driven architecture with multiple consumers per message
  • Devices have intermittent connectivity (store-and-forward via broker)
  • Smart home, telemetry dashboards, industrial monitoring

Choose CoAP when:

  • Constrained devices with limited RAM/flash (8-bit MCUs)
  • Battery-powered sensors on LPWAN (6LoWPAN, Thread)
  • Direct device-to-device or device-to-gateway communication
  • RESTful semantics needed on constrained networks

Default recommendation: MQTT for cloud/broker-based IoT systems, CoAP for constrained edge networks, HTTP only when interfacing with web systems or during prototyping

WarningTradeoff: Broker-Based (MQTT) vs Direct Communication (CoAP/HTTP)

Option A: Use a broker-based architecture where all messages flow through a central MQTT broker Option B: Use direct device-to-device or device-to-server communication with CoAP or HTTP

Decision Factors:

Factor Broker-Based (MQTT) Direct (CoAP/HTTP)
Coupling Loose (devices don’t know each other) Tight (must know endpoint addresses)
Discovery Topic-based (subscribe to patterns) Requires discovery protocol
Fan-out Built-in (1 publish to N subscribers) Must implement multi-cast or repeat
Single point of failure Broker is critical Distributed, no central point
Latency +1 hop through broker Direct path, minimal latency
Offline handling Broker stores messages Client must retry
Scalability Scales horizontally with broker cluster Scales naturally (peer-to-peer)
Infrastructure Requires broker deployment/management Simpler deployment

Choose Broker-Based (MQTT) when:

  • Multiple consumers need the same data (dashboards, logging, analytics)
  • Devices should not know about each other (decoupled architecture)
  • Message persistence is needed for offline devices
  • Topic-based routing simplifies message organization
  • Enterprise-scale deployments with centralized management

Choose Direct Communication (CoAP/HTTP) when:

  • Latency-critical control loops require minimal hops
  • Simple point-to-point communication between known endpoints
  • Broker infrastructure is impractical (resource-constrained networks, isolated sites)
  • RESTful semantics and HTTP-style resources are natural fit
  • Avoiding single points of failure is priority

Default recommendation: Broker-based (MQTT) for telemetry collection and event distribution; direct communication (CoAP) for device control and local sensor networks

1176.5 Knowledge Check

Test your understanding of protocol comparison concepts.

Question: Why might a system use BOTH CoAP (edge) and MQTT (cloud) in hybrid architecture?

💡 Explanation: Hybrid architectures leverage protocol strengths: (1) Edge: CoAP for battery sensors → gateway (minimal power, direct queries), (2) Cloud: Gateway translates to MQTT → cloud services (pub-sub scalability, cloud platform integration). Example: LoRa sensors use CoAP to gateway, gateway forwards via MQTT to AWS IoT. Best of both worlds.

Question: A factory needs real-time (<100ms) alerts from 200 pressure sensors. Network experiences 5% packet loss. Which protocol configuration is BEST?

💡 Explanation: CoAP CON messages provide: (1) Reliability with retransmission (handles 5% loss), (2) Low latency - ACK within 20-50ms (meets <100ms requirement), (3) Minimal overhead. NON messages would lose 5% of critical alerts. MQTT QoS 2 has 4-way handshake (slower). HTTP polling wastes bandwidth and has higher latency.

Question: Calculate total overhead: Sending “25.3” (4 bytes) via CoAP over UDP/IPv4. What percentage is protocol overhead?

💡 Explanation: Total packet: 4 (payload) + 4 (CoAP) + 8 (UDP) + 20 (IPv4) + 14 (Ethernet) = 50 bytes. Overhead = 46 bytes. Percentage = 46/50 = 92%. Answer C closest at 89%. This shows why IoT protocols optimize every byte - small payloads dominated by protocol overhead.

1176.6 Hybrid Architecture Example

TipCase Study: Smart HVAC System Protocol Design

Requirements: - 500 temperature sensors per building - Real-time alerts for anomalies - Historical data queries - Mobile app control

Solution - Hybrid approach:

# 1. MQTT for telemetry (sensors → cloud)
Topic: buildings/bldg1/floor3/zone-a/temp42/reading
Payload (CBOR): {t:23.5, h:45, ts:1642259400}
QoS: 0 (frequent updates, loss acceptable)

# 2. CoAP for control (app → actuators)
PUT coap://hvac.local/v1/zones/zone-a/setpoint
Payload: {"target":22.0}
Type: CON (confirmable - critical command)

# 3. HTTP REST for historical queries (app → cloud)
GET https://api.example.com/v1/sensors/temp42/history?start=2025-01-01
Response (JSON): [{"timestamp":"2025-01-01T00:00:00Z","value":23.5}...]

Why this works: - MQTT handles high-volume telemetry efficiently - CoAP provides low-latency local control - HTTP enables rich queries from mobile apps - Each protocol optimized for its use case

1176.7 Protocol Overhead Comparison (Visual)

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph Header["Protocol Message Overhead (20-byte payload)"]
        direction LR
        H1["Lower Overhead"]
        H2["→"]
        H3["Higher Overhead"]
    end

    subgraph Minimal["Minimal Overhead"]
        COAP_OH["CoAP:<br/>4-byte header<br/>24 bytes total<br/>83% efficiency"]
        MQTT_OH["MQTT (QoS 0):<br/>2-byte header + topic<br/>~30 bytes total<br/>67% efficiency"]
    end

    subgraph Moderate["Moderate Overhead"]
        MQTT_Q1["MQTT (QoS 1):<br/>~35 bytes total<br/>57% efficiency<br/>+ ACK message"]
        AMQP_OH["AMQP:<br/>8-byte header + framing<br/>~50 bytes total<br/>40% efficiency"]
    end

    subgraph Heavy["Heavy Overhead"]
        HTTP_OH["HTTP:<br/>~200+ bytes headers<br/>~220 bytes total<br/>9% efficiency"]
        XMPP_OH["XMPP:<br/>~280+ bytes XML<br/>~300 bytes total<br/>7% efficiency"]
    end

    subgraph Impact["Battery/Bandwidth Impact"]
        I1["Low power sensors:<br/>Use CoAP or MQTT QoS 0<br/>Minimize TX time"]
        I2["Reliable delivery:<br/>MQTT QoS 1/2 or AMQP<br/>Accept overhead"]
        I3["Web integration:<br/>HTTP at gateway<br/>Not on sensors"]
    end

    Minimal --> Impact
    Moderate --> Impact
    Heavy --> Impact

    style Header fill:#f9f9f9,stroke:#2C3E50
    style Minimal fill:#16A085,color:#fff
    style Moderate fill:#E67E22,color:#fff
    style Heavy fill:#c0392b,color:#fff
    style Impact fill:#7F8C8D,color:#fff
    style COAP_OH fill:#d4efdf,color:#2C3E50
    style MQTT_OH fill:#d4efdf,color:#2C3E50
    style MQTT_Q1 fill:#fdebd0,color:#2C3E50
    style AMQP_OH fill:#fdebd0,color:#2C3E50
    style HTTP_OH fill:#fadbd8,color:#2C3E50
    style XMPP_OH fill:#fadbd8,color:#2C3E50
    style I1 fill:#e8e8e8,color:#2C3E50
    style I2 fill:#e8e8e8,color:#2C3E50
    style I3 fill:#e8e8e8,color:#2C3E50

Figure 1176.3: Protocol overhead comparison for 20-byte payload showing efficiency ranges from CoAP (83%) to XMPP (7%)

1176.8 Summary Table: Quick Reference

Criterion CoAP MQTT
Best Use Case Direct device queries Event distribution
Communication Request-Response Publish-Subscribe
Transport UDP (lightweight) TCP (reliable)
Power Ultra-low Low
Reliability Optional Built-in (QoS)
Scalability Good Excellent
Complexity Low Medium
Browser Support Limited Good (WebSockets)
Setup No broker needed Requires broker
Latency Low Medium
Data Type Sensor data Events/telemetry

1176.9 Key Takeaways

NoteSummary

Core Concepts: - CoAP uses UDP with request-response pattern; MQTT uses TCP with publish-subscribe - CoAP has 4-byte minimum header; MQTT has 2-byte minimum header (plus TCP overhead) - CoAP offers optional reliability (CON/NON); MQTT provides QoS 0/1/2 levels - Both protocols target constrained environments but with different design philosophies

Practical Applications: - Use CoAP for battery sensors, direct device control, and constrained networks - Use MQTT for telemetry dashboards, event-driven systems, and cloud integration - Hybrid architectures combine both protocols for optimal efficiency

Design Considerations: - Evaluate latency requirements, power constraints, and communication patterns - Consider broker infrastructure costs for MQTT vs direct communication for CoAP - Factor in existing ecosystem and tooling support for your platform

1176.10 What’s Next?

Continue to HTTP and Modern Protocols for IoT for a deep dive into HTTP/2, HTTP/3, and common pitfalls when using traditional web protocols in IoT environments.