This review covers CoAP protocol fundamentals: the four message types (CON, NON, ACK, RST) with their energy and reliability tradeoffs, the 4-byte binary header that achieves 87% bandwidth reduction over HTTP, UDP vs TCP transport implications, and DTLS security. Key numbers to remember: CON costs 3.0 mJ per message with 99.99% reliability; NON costs 1.5 mJ with 90-95% reliability.
For Beginners: CoAP Essentials Quick Reference
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
56.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:
TCP Marketing: “Guaranteed delivery” sounds better than “best-effort with retries,” even though both achieve 99.99%+ in practice
Confusion About Retransmission: Developers don’t realize CoAP implements its own reliability layer (exponential backoff: 2s, 4s, 8s, 16s for up to 4 retries)
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.
56.4 Key Concepts
Understanding these core concepts is essential for effective CoAP implementation:
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
56.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.
CoAP Message Types
Figure 56.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)
56.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:
Figure 56.2: CoAP message types: CON, NON, separate response, and RST
Alternative View: Reliability vs Energy Trade-off
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)
Quick Check: Message Types and Response Patterns
56.5.2 Interactive: Message Type Decision Tool
Use this tool to determine which CoAP message type is appropriate for your use case:
Pitfall: 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,608bool is_notification_fresh(uint32_t new_seq,uint32_t last_seq,uint32_t new_time,uint32_t last_time){// Calculate distance with wraparound handlinguint32_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 oldbool 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.
Pitfall: 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)
Label the Diagram
💻 Code Challenge
Order the Steps
Match the Concepts
56.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)
56.9 Knowledge Check
Quiz: CoAP Protocol Fundamentals
Decision Framework: Selecting CoAP Message Type for Different IoT Scenarios
Use this decision framework to choose between CON (Confirmable) and NON (Non-Confirmable) messages:
Scenario
Message Type
Rationale
Energy Impact
Smart lock door command
CON
Security-critical; user must know door is locked/unlocked
3.0 mJ (2× NON, acceptable for infrequent command)
Temperature every 30s
NON
Next reading supersedes missed one; 5% loss acceptable
1.5 mJ (doubles battery life vs CON)
Fire alarm notification
CON
Life-safety critical; 99.99% delivery required
3.0 mJ (negligible for rare but critical event)
Firmware block transfer
CON
Each block must arrive; missing blocks break image
3.0 mJ per block (reliability worth the cost)
Motion sensor event
NON
Frequent events; occasional miss acceptable (next motion detected soon)
1.5 mJ (enables years of battery life)
Configuration change ACK
CON
Device must confirm it applied new config
3.0 mJ (rare operation, confirmation essential)
Heartbeat/keepalive
NON
Periodic liveness check; single miss won’t trigger alarm
1.5 mJ (reduces keepalive overhead by 50%)
HVAC setpoint command
CON
User comfort depends on confirmation; retry if timeout
3.0 mJ (user experience worth reliability)
Quick Decision Rules:
Use CON when:
Delivery confirmation is essential (actuators, commands, alarms)
Data loss causes user-visible failure or safety risk
Messages are infrequent (< 1 per minute)
Application logic needs acknowledgment to proceed
Use NON when:
Frequent periodic telemetry (seconds to minutes)
Next message supersedes previous (sensor readings)
5-15% packet loss is acceptable
Battery life is critical (years on coin cell)
Quantified Example - Soil Moisture Sensor:
Requirement: 5-year battery life on CR2032 (225 mAh @ 3V)
Reporting: Every 30 minutes (48 messages/day)
CON messages:
Energy: 48 msg/day × 3.0 mJ = 144 mJ/day
Battery life: (225 mAh × 3V × 3600 J/Wh) / 144 mJ/day
= 2,430 J / 0.144 J/day = 16,875 days = 46 years
Actual: ~2 years (accounting for sleep current and self-discharge)
NON messages:
Energy: 48 msg/day × 1.5 mJ = 72 mJ/day (50% reduction)
Battery life: 2,430 J / 0.072 J/day = 33,750 days = 92 years
Actual: ~5 years (meets requirement)
Verdict: NON enables the 5-year target. Losing 1-2 moisture readings per month (5% of 1,440 monthly) is acceptable for slow-changing soil conditions.
56.10 Concept Relationships
How CoAP fundamentals connect to broader IoT architecture:
Message Types Build On:
UDP Transport - Best-effort delivery requiring application-layer reliability
Reliability Mechanisms - CON messages provide optional acknowledgment
Energy Trade-offs - CON uses 2x energy of NON for guaranteed delivery
4-Byte Header Relates To:
Protocol Overhead Analysis - Comparing header sizes across IoT protocols
Binary Encoding - Compact representation vs text-based HTTP
