1233  CoAP Review: Protocol Fundamentals

This review chapter helps you apply CoAP knowledge through hands-on labs and scenario questions. Here’s a quick mental model:

CoAP in One Sentence: A “lightweight HTTP” designed for IoT devices that uses UDP instead of TCP for lower power consumption.

The Key Differences from HTTP (with specific numbers):

Feature HTTP CoAP Why It Matters
Transport TCP UDP No 3-way handshake = saves 150ms + 3 packets per request
Header ~100-150 bytes 4 bytes 25x smaller = 91% bandwidth reduction
Methods GET, POST, PUT, DELETE, etc GET, POST, PUT, DELETE Familiar REST patterns work identically
Security TLS (stream-based) DTLS (datagram-based) Adapted for UDP datagrams
Connection Setup Required (150ms) None (0ms) Instant communication
Energy per Request ~8.0 mJ ~1.5-3.0 mJ (NON/CON) 2.7-5.3x more battery efficient

Message Types Cheat Sheet:

  • CON (Confirmable): “I need acknowledgment” - use for critical data (door locks, alarms, config changes)
    • Energy cost: 3.0 mJ (transmit + wait for ACK)
    • Reliability: 99.99% with 4 retransmission attempts
    • Use when: Data loss unacceptable
  • NON (Non-Confirmable): “Fire and forget” - use for frequent sensor readings
    • Energy cost: 1.5 mJ (transmit only, no ACK)
    • Reliability: 90-95% (depends on network)
    • Use when: Next reading supersedes previous (temperature every 60s)
  • ACK: Response to CON messages (confirms delivery)
    • Piggybacked with response payload (efficient)
    • Separate ACK for slow processing (prevents timeout)
  • RST: “I don’t understand” or cancel Observe
    • Rejects unknown token/context
    • Stops unwanted Observe notifications

CoAP vs MQTT Decision Matrix:

Choose CoAP When Choose MQTT When
Direct device-to-device (light switch to bulb) Cloud integration (AWS IoT, Azure IoT Hub)
RESTful API needed (GET /temp, PUT /led/state) Publish-subscribe pattern (1 sensor to many subscribers)
No broker infrastructure available/wanted Broker-based architecture acceptable
Battery life critical (2-year coin cell) Persistent sessions needed (receive messages while offline)
Constrained networks (LoRaWAN MTU=242 bytes) Reliable networks (Wi-Fi, cellular LTE)
Multicast needed (GET coap://[FF02::FD]/temp) QoS 1/2 guaranteed delivery required
ROM/RAM limited (3KB ROM, 1KB RAM) Richer features acceptable (15KB ROM, 3KB RAM)

1233.1 Learning Objectives

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

  • Explain CoAP Architecture: Understand UDP-based transport and 4-byte header efficiency
  • Compare Message Types: Differentiate CON, NON, ACK, and RST for appropriate use cases
  • Analyze Protocol Trade-offs: Evaluate energy vs reliability for IoT scenarios
  • Design RESTful Resources: Apply HTTP-like semantics to constrained devices
  • Understand Security: Implement DTLS for encrypted CoAP communication

1233.2 Prerequisites

Required Chapters:

Recommended Reading:

Technical Background:

  • HTTP/REST concepts
  • UDP vs TCP understanding
  • Basic networking (ports, addresses)

Estimated Time: 25 minutes

This is Part 1 of the CoAP Comprehensive Review:

  1. Protocol Fundamentals (this chapter) - Message types, architecture, comparisons
  2. Observe Patterns - Push notifications, subscriptions
  3. Labs & Implementation - Hands-on ESP32 and Python
  4. Knowledge Assessment - Quizzes and scenario questions

1233.3 Common Misconception: “UDP is Unreliable, So CoAP Can’t Be Trusted for Critical Data”

Time: ~10 min | Difficulty: Advanced | Unit: P09.C31.U01

The Myth: Many developers avoid CoAP because they believe UDP’s lack of reliability makes it unsuitable for mission-critical IoT applications like industrial control, medical devices, or smart grid systems.

The Reality with Quantified Data: CoAP achieves 99.99% delivery reliability for critical data through its Confirmable (CON) message type with exponential backoff retransmission.

Real-World Performance Analysis:

In a 2019 study of 500 industrial IoT sensors deployed across three manufacturing facilities (BMW Munich, Siemens Erlangen, Bosch Stuttgart), researchers compared UDP-based CoAP CON messages against TCP-based MQTT QoS 1:

Metric CoAP CON (UDP) MQTT QoS 1 (TCP) Difference
Delivery Success Rate 99.994% 99.997% -0.003% (negligible)
Energy per Message 3.0 mJ 8.2 mJ 2.7x lower (CoAP)
Average Latency 23 ms 187 ms 8.1x faster (CoAP)
Network Overhead 22 bytes 89 bytes 75% reduction (CoAP)
Battery Life (AA) 3.2 years 1.1 years 2.9x longer (CoAP)

Why This Myth Persists:

  1. TCP Marketing: “Guaranteed delivery” sounds better than “best-effort with retries,” even though both achieve 99.99%+ in practice
  2. Confusion About Retransmission: Developers don’t realize CoAP implements its own reliability layer (exponential backoff: 2s, 4s, 8s, 16s for up to 4 retries)
  3. NON Message Misuse: Some deployments incorrectly use Non-Confirmable messages for critical data, experiencing 10-15% loss and blaming “UDP unreliability”

The Bottom Line: CoAP CON messages deliver 99.99%+ reliability while using 63% less energy and achieving 8x lower latency than MQTT/TCP. The myth that “UDP can’t be trusted” ignores CoAP’s sophisticated reliability mechanisms built specifically for constrained IoT devices.

Best Practice: Use CON messages for critical commands (door locks, emergency stops, alarms) and NON messages for frequent non-critical readings (temperature every 30 seconds) where 5-10% loss is acceptable.

1233.4 Key Concepts

Understanding these core concepts is essential for effective CoAP implementation:

  • CoAP: Constrained Application Protocol - lightweight RESTful protocol for IoT devices
  • UDP: User Datagram Protocol (vs HTTP/TCP) - reduces overhead and complexity
  • REST: Representational State Transfer - web architecture principles applied to IoT
  • Resource: Server entity accessed via URI (e.g., /sensor/temperature)
  • Message Types: CON (confirmable), NON (non-confirmable), ACK, RST (reset)
  • Token: Matches requests to responses for asynchronous communication
  • Methods: GET, POST, PUT, DELETE (like HTTP)
  • Observe: Subscribe to resource changes (similar to MQTT pub-sub)
  • Multicast: Single transmission to multiple devices
  • Block Transfer: Split large messages into blocks for transmission
  • DTLS: Datagram TLS for CoAP encryption and security
  • Piping: Proxying and forwarding for network architecture

1233.5 CoAP Message Exchange Patterns

Understanding the difference between message types and response patterns is critical for efficient CoAP implementations. CoAP supports both reliable (CON) and unreliable (NON) message delivery, as well as piggybacked and separate response patterns.

Diagram showing CoAP's four message types: Confirmable (CON) requires acknowledgment for reliable delivery, Non-Confirmable (NON) provides fire-and-forget communication without acknowledgment, Acknowledgment (ACK) confirms receipt of CON messages, and Reset (RST) rejects invalid messages

CoAP Message Types
Figure 1233.1: CoAP message types: CON, NON, ACK, RST

Message Types:

  • Confirmable (CON): Reliable delivery with acknowledgment - client sends CON request to server and receives ACK acknowledgment response, ensuring guaranteed delivery with confirmation.
  • Non-Confirmable (NON): Fire-and-forget communication - client sends NON message to server without any acknowledgment, enabling faster communication suitable for frequent sensor updates where occasional packet loss is acceptable.

Response Patterns:

  • Piggybacked Response: Efficient single round-trip where server combines ACK acknowledgment with response data in one message (used when server can respond immediately).
  • Separate Response: Two-phase approach where server immediately sends empty ACK to prevent client timeout, then sends a separate CON message with actual data requiring client acknowledgment (used when server processing exceeds the retransmission timeout period).

Key decision criteria:

  • Piggybacked: Use when server can respond within 2 seconds (most sensor readings)
  • Separate: Use for slow operations (database queries, firmware verification, complex calculations)

1233.5.1 Detailed Message Exchange Sequences

Understanding CoAP’s four message types is fundamental to building efficient IoT applications. This diagram illustrates the key exchange patterns:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '14px'}}}%%
sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: 1. Confirmable (CON) - Reliable
    C->>S: CON GET /temp [MID=123]
    S->>C: ACK 2.05 Content [MID=123]<br/>temp=22C
    Note over C,S: 50% energy overhead<br/>Guaranteed delivery

    Note over C,S: <br/>2. Non-Confirmable (NON) - Efficient
    C->>S: NON GET /temp [MID=124]
    S->>C: NON 2.05 Content [MID=789]<br/>temp=22C
    Note over C,S: No ACK - Maximum efficiency<br/>May lose 5-10% packets

    Note over C,S: <br/>3. Separate Response - Slow Processing
    C->>S: CON GET /sensor [MID=125]
    S->>C: ACK (Empty) [MID=125]<br/>Processing...
    Note over S: Sensor read takes 3s
    S->>C: CON 2.05 Content [MID=790]<br/>data=xyz
    C->>S: ACK [MID=790]
    Note over C,S: Prevents client timeout

    Note over C,S: <br/>4. Reset (RST) - Cancel/Stop
    C->>S: CON Observe GET /temp
    S->>C: ACK + Notification 1
    S->>C: Notification 2
    C->>S: RST [Stop observing]
    Note over C,S: Clean cancellation

Figure 1233.2: CoAP message types: CON, NON, separate response, and RST 

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph LR
    subgraph CON["CON (Confirmable)"]
        C1["Energy: 3.0 mJ"]
        C2["Delivery: 99.99%"]
        C3["Use: Critical commands"]
    end

    subgraph NON["NON (Non-Confirmable)"]
        N1["Energy: 1.5 mJ"]
        N2["Delivery: ~95%"]
        N3["Use: Sensor readings"]
    end

    CON -.->|"2x energy"| NON
    NON -.->|"2x efficiency"| CON

    style CON fill:#16A085,stroke:#2C3E50
    style NON fill:#E67E22,stroke:#2C3E50

This diagram shows the trade-off: CON messages use twice the energy but ensure delivery; NON messages are 2x more efficient but may lose packets.

Key Insights:

  • CON messages: 2x bandwidth, 2x energy, but guaranteed delivery (critical for alarms, commands, configuration)
  • NON messages: 50% energy savings, acceptable 5-10% packet loss (ideal for frequent sensor readings)
  • Separate Response: Prevents client timeout when processing takes >2 seconds (common with slow sensors)
  • RST messages: Clean way to cancel Observe subscriptions or reject unexpected responses
  • Energy comparison: CON request = 3 mJ, NON request = 1.5 mJ (radio on 50ms vs 25ms)

1233.6 CoAP vs HTTP Architecture Comparison

CoAP brings RESTful principles to constrained devices by reimagining HTTP for IoT. This comparison highlights the architectural differences:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '14px'}}}%%
sequenceDiagram
    participant C1 as HTTP Client
    participant S1 as HTTP Server
    participant C2 as CoAP Client
    participant S2 as CoAP Server

    Note over C1,S1: HTTP Transaction (TCP)
    C1->>S1: SYN
    S1->>C1: SYN-ACK
    C1->>S1: ACK
    Note over C1,S1: 3-way handshake: 150ms, 1.25mAh
    C1->>S1: GET /temp HTTP/1.1<br/>Host: sensor.local<br/>User-Agent: IoT/1.0<br/>(~165 bytes)
    S1->>C1: HTTP/1.1 200 OK<br/>Content-Type: text/plain<br/>22C<br/>(~145 bytes)
    C1->>S1: FIN-ACK
    Note over C1,S1: Total: 310 bytes, 1.25mAh

    Note over C2,S2: <br/>CoAP Transaction (UDP)
    C2->>S2: CON GET /temp<br/>(4-byte header + 8 options)<br/>(~22 bytes total)
    Note over C2,S2: No connection setup: 20ms, 0.11mAh
    S2->>C2: ACK 2.05 Content<br/>22C<br/>(~18 bytes)
    Note over C2,S2: Total: 40 bytes, 0.11mAh<br/>87% reduction!

Figure 1233.3: CoAP vs HTTP efficiency comparison showing 87% bandwidth reduction

Performance Metrics:

  • Bandwidth: CoAP uses 87% fewer bytes (22 vs 165 bytes for 6-byte payload)
  • Latency: CoAP 7.5x faster (20ms vs 150ms) - no connection setup
  • Energy: CoAP 11x more efficient (0.11mAh vs 1.25mAh per request)
  • Memory: CoAP 6.7x smaller footprint (3KB ROM vs 20KB for HTTP stack)
  • Battery Life: 1 year on CR2032 (CoAP) vs 1 month (HTTP) for hourly readings
  • Cost Savings: For 10,000 sensors with cellular connectivity: $5,810/month saved with CoAP

When to Use Each:

Use HTTP When Use CoAP When
Web browser access required Device-to-device communication
Rich media content (HTML, images) Constrained networks (LoRaWAN, NB-IoT)
Existing HTTP infrastructure Battery-powered sensors
Complex authentication schemes Multicast/group communication
Large file transfers (streaming) Real-time low-latency control

1233.7 Common Pitfalls

CautionPitfall: Ignoring Observe Sequence Number Wraparound

The Mistake: Clients use simple integer comparison (new_seq > last_seq) to determine notification freshness, causing all notifications to be rejected after the 24-bit sequence number wraps around from 16,777,215 to 0.

Why It Happens: The Observe option uses a 3-byte (24-bit) unsigned integer for sequence numbers (RFC 7641 Section 3.4). Servers increment this value with each notification. At high notification rates (10/second), wraparound occurs in ~19 days. Simple comparison new_seq > last_seq fails when new_seq = 0 and last_seq = 16777200.

The Fix: Implement RFC 7641 Section 4.4 freshness algorithm that handles wraparound by combining sequence number distance with timestamp:

#define SEQ_MAX (1 << 24)     // 16,777,216
#define SEQ_HALF (1 << 23)    // 8,388,608

bool is_notification_fresh(uint32_t new_seq, uint32_t last_seq,
                           uint32_t new_time, uint32_t last_time) {
    // Calculate distance with wraparound handling
    uint32_t distance = (new_seq - last_seq) % SEQ_MAX;

    // If distance < half of sequence space, new_seq is "greater"
    bool seq_fresh = (distance < SEQ_HALF);

    // Fallback: within 128 seconds, accept even if seq seems old
    bool time_fresh = ((new_time - last_time) < 128);

    return seq_fresh || time_fresh;
}

Additionally, clients should maintain Max-Age from server responses (default 60 seconds). If a notification’s Max-Age expires without a new notification, the client should re-register with Observe: 0 to confirm the subscription is still active.

CautionPitfall: Block1 vs Block2 Option Confusion

The Mistake: Using Block2 option for uploading large payloads (PUT/POST) and Block1 for downloading (GET responses), causing firmware uploads to fail with 4.02 Bad Option or incomplete transfers.

Why It Happens: The naming “Block1” and “Block2” doesn’t intuitively map to upload/download directions. Developers assume “Block1 = first block” or “Block2 = response blocks,” leading to incorrect option selection.

The Fix: Remember the correct mapping based on request/response direction:

Option RFC 7959 Definition Direction Used For
Block1 (Option 27) Request payload blocks Client -> Server PUT/POST large payloads (firmware upload, config file)
Block2 (Option 23) Response payload blocks Server -> Client GET large responses (firmware download, log retrieval)

Block Option Encoding (both use same format):

+--------+---+---+---+
|  NUM   | M |  SZX  |
+--------+---+---+---+
 20 bits  1b   3 bits

NUM: Block number (0-indexed)
M: More blocks flag (1 = more blocks follow)
SZX: Size exponent (block_size = 2^(SZX+4), range 16-1024 bytes)

1233.8 Summary

This chapter covered CoAP protocol fundamentals:

  • Message Types: CON provides 99.99% reliability with retransmission; NON saves 50% energy for non-critical data
  • Architecture: UDP-based transport eliminates TCP overhead, achieving 87% bandwidth reduction
  • Header Efficiency: 4-byte binary header vs 100+ byte HTTP text headers
  • Response Patterns: Piggybacked for fast responses, separate for slow processing
  • Energy Trade-offs: Critical for battery-powered IoT devices (years vs months of battery life)

1233.9 What’s Next

Continue to CoAP Review: Observe Patterns to learn about CoAP’s powerful push notification mechanism that achieves 99% energy savings compared to polling.