45  CoAP Communication Patterns

RESTful Communication for Constrained IoT Devices

In 60 Seconds

CoAP provides four RESTful methods (GET, POST, PUT, DELETE) with two reliability modes: Confirmable (CON) for critical commands requiring acknowledgment, and Non-Confirmable (NON) for frequent telemetry where the next reading supersedes missed ones. The Observe pattern transforms CoAP from pure request-response into push-based notifications, reducing bandwidth by 97%+ compared to polling for slowly-changing data.

MVU: Most Valuable Understanding

CoAP’s Observe pattern can reduce bandwidth by 97%+ compared to polling for slowly-changing data. The key insight is that CoAP is NOT “HTTP over UDP” - it has unique optimizations like 4-byte headers (vs 200+ bytes in HTTP), optional reliability via CON/NON message types, and the Observe pattern for push-based updates. Use CON (Confirmable) for critical commands that MUST be acknowledged, and NON (Non-Confirmable) for frequent telemetry where the next reading supersedes missed ones.

45.1 Chapter Overview

Mind map showing the three main topics covered in this chapter: CoAP Methods (GET, POST, PUT, DELETE), Message Types (CON vs NON), and Communication Patterns (Polling vs Observe). IEEE colors: navy for main topics, teal for subtopics, orange for key decisions.

CoAP Methods and Patterns: Chapter Concept Map

45.2 Learning Objectives

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

  • Implement CoAP Methods: Apply GET, POST, PUT, and DELETE operations correctly for RESTful IoT resource management
  • Select Message Types: Justify the choice between Confirmable (CON) and Non-Confirmable (NON) based on reliability, power, and latency requirements
  • Evaluate Polling vs Observe: Analyze bandwidth and power tradeoffs and select the appropriate monitoring pattern for a given scenario
  • Calculate Bandwidth Savings: Quantify Observe pattern efficiency for specific deployments using the bandwidth efficiency formula
  • Distinguish CoAP from HTTP: Explain the specific architectural differences (header size, message types, Observe pattern) that make CoAP unsuitable to be treated as HTTP over UDP

45.3 Prerequisites

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

Core CoAP Knowledge:

Compare with Other Protocols:

Production Deployment:

CoAP (Constrained Application Protocol) uses a RESTful approach similar to HTTP but optimized for constrained devices. This chapter focuses on how to communicate using CoAP.

Key concepts:

Term Simple Explanation
Method The action you want (GET=read, PUT=update, POST=create, DELETE=remove)
CON Confirmable message - “I need to know you received this”
NON Non-Confirmable message - “Fire and forget, no reply needed”
Observe Subscribe to updates - “Tell me when this changes”
Polling Repeatedly asking - “Has it changed yet? How about now?”

Think of CON vs NON like sending a letter (CON = registered mail with tracking, NON = regular mail).

Meet the Sensor Squad! Sammy the Sensor runs a message delivery service in IoT City.

The Problem: Sammy needs to send temperature readings to the Cloud Castle, but there are two ways to do it!

Option 1: Confirmed Delivery (CON) “When I send an important message like ‘THE OVEN IS ON FIRE!’, I use my special red envelope,” explains Sammy. “The Cloud Castle MUST send back a thumbs-up to prove they got it. If I don’t hear back, I keep trying until they do!”

Option 2: Quick Delivery (NON) “But when I send regular updates like ‘Temperature is 22 degrees’, I use my blue envelope. I don’t wait for a reply - I’m already sending the next update! If one message gets lost, no big deal - the next one is coming soon.”

Lila the Light Sensor asks: “But how do you know which to use?”

Sammy’s Rule: “Ask yourself: If this message gets lost, will something bad happen? If YES, use CON (red envelope). If NO, use NON (blue envelope).”

Max the Motion Sensor chimes in: “I use the Observe pattern! Instead of asking ‘Is anyone there?’ every second, I tell the door: ‘Hey, ONLY message me when someone actually shows up.’ That way I can nap between visitors!”

The Lesson: Just like in IoT City, smart sensors choose the right message type for each situation - reliable delivery for emergencies, quick updates for regular readings, and subscriptions for event-driven alerts!

45.4 Common Misconception: “CoAP is just HTTP over UDP”

15 min | Advanced | P09.C30.U01

The Misconception: Many assume CoAP is simply HTTP with UDP transport, leading to incorrect assumptions about message reliability, header structure, and behavior.

Why This Is Wrong:

1. Message Types Are Different:

  • HTTP: Only request/response (no built-in message acknowledgment)
  • CoAP: Four message types - CON (confirmable, requires ACK), NON (non-confirmable), ACK (acknowledgment), RST (reset)
  • Impact: CoAP provides optional reliability at the application layer, not transport layer

2. Header Overhead Drastically Different:

  • HTTP/1.1 GET: Typically 200-500 bytes (text headers: “GET /temp HTTP/1.1: sensor.local-Agent:…”)
  • CoAP GET: 4-byte fixed header + token + options (total ~10-20 bytes)
  • Quantified: 90-95% smaller headers - Critical for battery-powered sensors sending thousands of messages

3. Observe Pattern Has No HTTP Equivalent:

  • HTTP: Client must poll repeatedly (GET /temp every 10s = wasted bandwidth even when no change)
  • CoAP Observe: Client sends GET /temp with Observe option (1 byte), server sends updates ONLY when value changes
  • Impact: In a deployment with 1000 sensors polling every 10s:
    • HTTP polling: 1000 requests/10s = 100 req/s continuously, even if temperature unchanged
    • CoAP observe: 1 request per sensor, then only updates on change (e.g., 5 notifications/hour if temperature stable)
    • Bandwidth saved: 99%+ in stable monitoring scenarios

4. Block Transfer Is Not HTTP Chunked Encoding:

  • HTTP chunked: Server controls chunking, client receives stream
  • CoAP block: Client can request specific blocks (e.g., “send me blocks 0-10”), supports retry of individual blocks
  • Use case: Firmware update interrupted? CoAP resumes from block 47, HTTP restarts entire download

Real-World Example: A smart agriculture deployment monitors 500 soil sensors: - Incorrect HTTP-over-UDP approach: Every sensor polls server every 30s -> 500 x 200 bytes x 2 (req+resp) x 2880 times/day = 576 MB/day - CoAP observe: 500 sensors register once (10 KB total), then 50 notifications/day when moisture changes -> 50 x 20 bytes x 500 = 0.5 MB/day - Result: 99.9% bandwidth reduction by using CoAP correctly, not treating it like HTTP

45.5 CoAP Methods

10 min | Intermediate | P09.C30.U02

Like HTTP, CoAP uses REST methods for resource manipulation, but with critical differences optimized for constrained networks:

45.5.1 Method Comparison: CoAP vs HTTP

Method Purpose HTTP Equivalent Idempotent CoAP Code HTTP Code
GET Retrieve resource GET Yes 0.01 200 OK
POST Create resource POST No 0.02 201 Created
PUT Update/Create PUT Yes 0.03 200/204
DELETE Remove resource DELETE Yes 0.04 200/204

45.5.2 Key Differences from HTTP

Aspect HTTP CoAP Impact
Header Size 200-500 bytes 4 bytes fixed 95% reduction
Transport TCP (reliable) UDP (unreliable) Lower latency
Reliability Transport layer Application layer (CON/NON) Flexible control
Caching HTTP caching headers Max-Age option Simplified
Discovery DNS + HTTP OPTIONS /.well-known/core Resource discovery
Multicast Not supported Native support Device discovery

Sequence diagram showing CoAP client sending GET, PUT, POST, DELETE requests to a CoAP server with corresponding responses. Uses IEEE colors: navy for client, teal for server, orange for data flow.

CoAP Request-Response Flow with Methods

45.5.3 Method Examples

GET: Retrieve temperature reading

coap://sensor.local/temperature

POST: Add new sensor reading (creates new resource)

coap://server.local/readings
Payload: {"temp": 23.5, "time": "2025-10-24T23:30:00Z"}

PUT: Update device configuration (idempotent - same result if repeated)

coap://device.local/config
Payload: {"interval": 60}

DELETE: Remove old data

coap://server.local/readings/old
Idempotency Matters

Idempotent means repeating the operation produces the same result. This is crucial for unreliable networks:

  • GET, PUT, DELETE: Safe to retry on timeout (same result)
  • POST: NOT safe to retry blindly (may create duplicates)

For POST operations on unreliable links, use a token or check-before-create pattern to avoid duplicates.

45.6 Tradeoff: Confirmable (CON) vs Non-Confirmable (NON)

Side-by-side comparison of Confirmable and Non-Confirmable CoAP message flows. CON shows request, ACK, and retry on timeout. NON shows single fire-and-forget transmission. IEEE colors used: navy for devices, teal for success, orange for data.

CON vs NON Message Flow Comparison
Tradeoff: Confirmable (CON) vs Non-Confirmable (NON) CoAP Messages

Option A: Use Confirmable (CON) messages - requires ACK from receiver, automatic retransmission on timeout

Option B: Use Non-Confirmable (NON) messages - fire-and-forget, no acknowledgment, no retries

Decision Factors:

Factor Confirmable (CON) Non-Confirmable (NON)
Reliability Guaranteed delivery (with retries) Best-effort (may be lost)
Latency (success) RTT + processing (50-200ms typical) One-way (<50ms typical)
Latency (failure) Retry timeout x max retries (2-60 seconds) N/A (no retry)
Power consumption 2-10x higher (ACK wait, retries) Minimal (single transmission)
Bandwidth 2x per message (request + ACK) 1x (request only)
Network congestion Higher (ACK traffic + retries) Lower
Implementation Complex (timeout tracking, retry queue) Simple (send and forget)
Loss detection Immediate (ACK timeout) None (silent failure)

Choose Confirmable (CON) when:

  • Actuator commands that must execute (valve open, door unlock, motor start)
  • Configuration changes that must be acknowledged
  • Alert/alarm notifications where silence is dangerous
  • Firmware update packets that cannot be skipped
  • Infrequent but critical messages (1 message/minute or less)
  • Example: Smart lock PUT /lock/state {"locked": false} - must confirm door unlocked

Choose Non-Confirmable (NON) when:

  • High-frequency telemetry where next reading replaces missed one
  • Battery-constrained sensors (each ACK doubles energy per message)
  • Real-time streaming where retries cause stale data
  • Multicast messages (cannot ACK multicast)
  • Lossy networks where retries cause congestion collapse
  • Example: Temperature sensor POST /readings {"temp": 22.5} every 10 seconds - missing one reading is acceptable

Real-world example: Smart agriculture irrigation system: - Soil moisture readings (every 30 min): Use NON - 48 readings/day x 500 sensors = 24,000 messages - NON: 24,000 transmissions, ~0.5mAh per sensor per day - CON: 48,000 transmissions (with ACKs), ~1.0mAh per sensor per day - Battery life: NON = 5 years, CON = 2.5 years - Irrigation valve commands (5 per day): Use CON - 5 commands x 500 valves = 2,500 messages - CON overhead negligible (10 transmissions per valve per day) - Missed valve command = crop damage worth $1000+ - ROI: $0.10 extra battery cost vs $1000 crop loss risk

45.7 Tradeoff: Polling vs Observe Pattern

Comparison diagram showing polling pattern with repeated GET requests versus Observe pattern with single registration and push notifications only on data change. Demonstrates 97% bandwidth reduction for slowly-changing data.

Polling vs Observe Pattern: Message Flow Comparison
Tradeoff: CoAP Polling vs Observe Pattern for Monitoring

Option A: Use polling - client sends periodic GET requests to check resource state

Option B: Use Observe pattern - client registers once, server pushes updates only when value changes

Decision Factors:

Factor Polling Observe
Initial setup None (just GET) Register with Observe option
Message count (stable data) High (every poll interval) Low (only on changes)
Message count (volatile data) Same as observe High (every change notification)
Latency to detect change Poll interval / 2 average Near-instantaneous
Client complexity Simple (timer + GET) Moderate (subscription management)
Server complexity Stateless Stateful (track observers)
Server memory None per client ~50-100 bytes per observer
NAT/firewall handling Client-initiated (NAT-friendly) Server-initiated (may need keep-alive)
Lost notification recovery Next poll catches up Client must re-register

Choose Polling when:

  • Data changes frequently (>1 change per poll interval makes observe inefficient)
  • Client cannot maintain long-lived state (stateless microservices)
  • NAT/firewall prevents server-initiated connections
  • Simplicity is priority (no observer lifecycle management)
  • Acceptable latency = seconds to minutes
  • Example: Dashboard checking 100 devices every 60 seconds - predictable load pattern

Choose Observe when:

  • Data changes infrequently relative to monitoring frequency
  • Real-time notification required (<1 second latency)
  • Bandwidth/battery critical (agricultural sensors checking hourly but only irrigating daily)
  • Event-driven architecture (actuator waiting for command)
  • Sensor -> gateway communication on local network (no NAT issues)
  • Example: Door sensor reporting open/close events - may be hours between changes

Real-world example: Smart building HVAC monitoring with 200 temperature sensors:

Scenario A: Polling every 10 seconds (traditional approach)

  • Messages: 200 sensors x 6 requests/minute x 60 minutes = 72,000 msg/hour
  • Each request: 20 bytes (GET /temp) + 20 bytes (response) = 40 bytes
  • Bandwidth: 72,000 x 40 = 2.88 MB/hour
  • Battery: ~2.5mAh/hour per sensor (constant wake cycles)

Scenario B: Observe pattern (smart approach)

  • Temperature stable (changes <0.5C): ~2 notifications/hour per sensor
  • Temperature volatile (HVAC cycling): ~20 notifications/hour per sensor
  • Average: 10 notifications/hour per sensor
  • Messages: 200 sensors x 10 = 2,000 msg/hour (97% reduction!)
  • Bandwidth: 2,000 x 20 bytes = 40 KB/hour (99% reduction!)
  • Battery: ~0.1mAh/hour per sensor (sleep between notifications)
  • Battery life improvement: 25x longer

Hybrid approach: Use observe for real-time display, poll every 5 minutes as backup to catch missed notifications or re-establish broken observations.

Bandwidth efficiency \(\eta\) for the Observe pattern versus polling is:

\[\eta = 1 - \frac{N_{\text{observe}}}{N_{\text{poll}}}\]

where \(N_{\text{observe}}\) is notifications sent when values change and \(N_{\text{poll}}\) is the total poll count.

For this HVAC scenario: - Polling: \(N_p = 200 \text{ sensors} \times 6 \text{ polls/min} \times 60 \text{ min} = 72,000 \text{ msg/hr}\) - Observe: \(N_o = 200 \times 10 \text{ changes/hr} = 2,000 \text{ msg/hr}\)

Efficiency: \(\eta = 1 - 2,000/72,000 = 0.972 = 97.2\%\) bandwidth savings.

The key insight: efficiency scales with the ratio of change rate \(r_c\) to polling rate \(r_p\). For stable data where \(r_c \ll r_p\), savings approach 100%. For volatile data where \(r_c \approx r_p\), observe offers minimal benefit.

45.8 Worked Example: Observe Bandwidth Savings

Worked Example: CoAP Observe Bandwidth Savings Calculation

Scenario: A smart building deployment monitors 500 temperature sensors. Management wants to compare the network cost of traditional polling versus CoAP Observe for a 24-hour period.

Given:

  • Number of sensors: 500
  • Polling interval (if used): 30 seconds
  • Average temperature changes per sensor per hour: 4 (HVAC cycles)
  • CoAP GET request size: 18 bytes (4B header + 2B token + 12B options)
  • CoAP response size: 24 bytes (4B header + 2B token + 6B options + 12B JSON payload)
  • Observe notification size: 26 bytes (adds 2B observe sequence number)

Steps:

  1. Calculate polling traffic (traditional approach):
    • Polls per sensor per day = (24 hours x 60 min x 60 sec) / 30 sec = 2,880 polls
    • Bytes per poll = 18 (request) + 24 (response) = 42 bytes
    • Total per sensor = 2,880 x 42 = 120,960 bytes/day
    • Total for 500 sensors = 500 x 120,960 = 60,480,000 bytes/day (57.7 MB)
  2. Calculate Observe traffic (CoAP approach):
    • Registration per sensor = 18 (GET with Observe:0) + 26 (initial response) = 44 bytes
    • Changes per sensor per day = 4 changes/hour x 24 hours = 96 notifications
    • Notification bytes per sensor = 96 x 26 = 2,496 bytes/day
    • Total per sensor = 44 + 2,496 = 2,540 bytes/day
    • Total for 500 sensors = 500 x 2,540 = 1,270,000 bytes/day (1.21 MB)
  3. Calculate bandwidth savings:
    • Reduction = (60,480,000 - 1,270,000) / 60,480,000 = 97.9% savings
    • Absolute savings = 60,480,000 - 1,270,000 = 59.21 MB/day
  4. Estimate power impact (assuming 20 mA transmit, 200 ms per message):
    • Polling: 2,880 messages × 500 sensors × 0.2 s × 20 mA ÷ 3,600 s/hr ÷ 1,000 mA/A = 1.60 Ah/day
    • Observe: (1 + 96) notifications × 500 sensors × 0.2 s × 20 mA ÷ 3,600 s/hr ÷ 1,000 mA/A = 0.054 Ah/day
    • Power reduction: 96.6%

Result: CoAP Observe reduces network traffic from 57.7 MB/day to 1.21 MB/day (97.9% reduction) and power consumption by 96.6%. The building’s IoT gateway average bandwidth requirement drops from 5.3 kbps (polling) to 0.11 kbps (Observe).

Key Insight: Observe pattern efficiency scales with the ratio of monitoring frequency to actual data changes. For slowly-changing data (temperature, humidity) with high monitoring frequency, savings exceed 95%. For rapidly-changing data (vibration sensors, power meters), polling may be more appropriate as notifications would approach polling frequency anyway.

45.9 Common Pitfall: Using CON for High-Frequency Telemetry

Pitfall: Using Confirmable Messages for High-Frequency Telemetry

The Mistake: Configuring all sensor readings to use CON (Confirmable) messages because “reliability is important,” causing a soil moisture sensor network to drain batteries in 6 months instead of the designed 5-year lifespan.

Why It Happens: Developers confuse “data importance” with “delivery confirmation need.” CON messages require acknowledgment within 2-second ACK_TIMEOUT, triggering up to 4 retransmissions with exponential backoff (2s, 4s, 8s, 16s) on packet loss. Each retransmission doubles energy consumption.

The Fix: Use NON (Non-Confirmable) messages for periodic telemetry where the next reading supersedes the previous one. Reserve CON for:

  • Actuator commands: PUT /valve/state {"open": true} - must confirm execution
  • Alert notifications: POST /alarm {"type": "intrusion"} - cannot be missed
  • Configuration changes: PUT /config {"interval": 60} - must acknowledge receipt
  • Firmware blocks: Block2 transfers with CON ensure no gaps in firmware image

For a sensor sending temperature every 30 seconds, missing one reading is acceptable (next reading in 30s). Energy comparison:

Message Type Packets/Reading Energy (mJ) 5-Year Battery
NON 1 1.5 Achievable
CON (no loss) 2 3.0 2.5 years
CON (10% loss) 2.4 avg 3.6 2.1 years

Use application-level aggregation with NON: if 3 consecutive readings fail to reach the gateway (detected via heartbeat), trigger a single CON recovery message with recent readings.

45.10 Visual Reference: CoAP Message Types

Decision tree diagram for selecting CoAP message types. Shows branching logic based on reliability requirements, frequency, and data criticality. CON path leads to actuator commands and critical alerts (orange boxes), NON path leads to high-frequency telemetry and multicast (teal boxes). IEEE color palette with navy decision nodes.

CoAP Message Type Decision Flow

Understanding when to use each message type is essential for designing efficient IoT communication: - CON: When you must know the message was received (commands, alerts) - NON: When delivery confirmation isn’t worth the overhead (frequent telemetry) - Observe: When you need real-time updates without polling

45.11 Decision Framework: Choosing the Right Pattern

Use this flowchart to select the appropriate CoAP message type and pattern for your use case:

Flowchart guiding CoAP design decisions. Starts with 'Is delivery confirmation critical?' leading to CON vs NON choice, then 'Is data event-driven?' leading to Observe vs Polling choice. IEEE colors: navy boxes, teal for yes paths, orange for no paths.

CoAP Message Type and Pattern Decision Flowchart

Quick Reference Table:

Use Case Message Type Pattern Example
Door lock command CON Request-Response PUT /lock {"state": "unlocked"}
Fire alarm CON Observe Subscribe to /alarm resource
Temperature reading (5min) NON Polling Gateway polls sensors
Motion detection NON Observe Push on movement detected
Firmware update CON Block Transfer Block2 with reliable delivery
Device discovery NON Multicast .well-known/core query

45.12 Practical Example: Smart Thermostat CoAP Design

10 min | Intermediate | P09.C30.U03

Let’s apply the concepts from this chapter to design the CoAP communication for a smart thermostat system.

Architecture diagram showing a smart thermostat using different CoAP patterns: NON for temperature readings every 5 minutes, CON for HVAC commands, and Observe for user app subscriptions. IEEE colors: navy for devices, teal for NON paths, orange for CON paths.

Smart Thermostat CoAP Communication Design

45.12.1 Design Decisions Explained

Resource Method Type Pattern Rationale
/readings POST NON Push High-frequency data, next reading supersedes missed one
/thermostat/current GET CON Observe Real-time UI updates, occasional re-registration acceptable
/thermostat/setpoint PUT CON Request-Response Critical command, must confirm user intent was executed
/hvac/mode PUT CON Request-Response Safety-critical, heating/cooling must be confirmed
/.well-known/core GET NON Discovery Device discovery, occasional miss is acceptable
Design Pattern: Hybrid Reliability

The thermostat example demonstrates a common pattern:

  1. Telemetry (temperature): NON messages - saves battery, next reading fixes any loss
  2. Subscriptions (app display): Observe with CON initial registration - ensures app gets updates
  3. Commands (setpoint change): CON with application confirmation - user sees immediate feedback
  4. Safety-critical (HVAC control): CON + application-level verification - multiple confirmation layers

This hybrid approach optimizes for both reliability and power efficiency.

Scenario: You’re designing a battery-powered parking space occupancy sensor that reports status changes. Management wants to know the battery life difference between using CON (reliable) vs NON (efficient) messages.

Given:

  • Sensor: CR2032 coin cell battery (225 mAh capacity, 3V nominal)
  • Reporting: Status change every 2 hours on average (12 messages/day)
  • Radio: 20 mA transmit current, 15 mA receive current at 3V
  • Message transmission time: 10 ms (CoAP message at 250 kbps)
  • ACK wait time: 40 ms (typical RTT on local network)

Step 1: Calculate NON message energy

Energy per NON message (P × t, expressed in mJ):
  - Transmit (10 ms @ 20 mA @ 3V):  60 mW × 10 ms = 0.60 mJ
  - No ACK wait (radio off immediately)
  - Total per message = 0.60 mJ

Daily energy (12 messages):
  12 × 0.60 mJ = 7.2 mJ/day

Battery life (225 mAh × 3V = 675 mWh = 2,430,000 mJ):
  2,430,000 mJ / 7.2 mJ/day = 337,500 days
  Note: At this low duty cycle, idle (sleep) current dominates.
  With a realistic 10 µA sleep current:
    Idle energy: 10 µA × 3V × 24 hr = 0.72 mWh/day = 2,592 mJ/day
    Total daily ≈ 2,600 mJ/day → battery life ≈ 935 days ≈ 3.1 months (sleep-limited)

Step 2: Calculate CON message energy

Energy per CON message (P × t, in mJ):
  - Transmit (10 ms @ 20 mA @ 3V):   60 mW × 10 ms = 0.60 mJ
  - Wait for ACK (40 ms @ 15 mA @ 3V): 45 mW × 40 ms = 1.80 mJ
  - Receive ACK (10 ms @ 15 mA @ 3V): 45 mW × 10 ms = 0.45 mJ
  - Total per message = 2.85 mJ

Daily energy (12 messages):
  12 × 2.85 mJ = 34.2 mJ/day
  With sleep current (same 2,592 mJ/day idle): total ≈ 2,626 mJ/day
  Battery life: 2,430,000 / 2,626 ≈ 925 days ≈ 3.1 months (sleep-limited)

  For clarity on the CON overhead ratio (ignoring identical idle component):
  Transmit energy ratio CON/NON = 2.85 / 0.60 = 4.75×

Step 3: Account for 10% packet loss and retransmissions

NON with loss (no retry):
  - 10% messages lost but not retried
  - Radio energy unchanged; delivery rate: 90%

CON with loss (single retry):
  - 10% of messages require retransmission (+2.85 mJ extra)
  - Average radio energy per message:
    (0.9 × 2.85) + (0.1 × 5.70) = 2.565 + 0.570 = 3.135 mJ
  - Delivery rate: 99%
  - Radio energy increase vs no-loss CON: 3.135 / 2.85 = 1.10× (10% overhead)

Result (radio energy comparison — sleep current excluded for clarity):

  • NON radio energy: 0.60 mJ/message
  • CON radio energy (no loss): 2.85 mJ/message → 4.75× higher than NON
  • CON radio energy (10% loss): 3.14 mJ/message → 5.2× higher than NON
  • Trade-off: 10% message loss (NON) vs 5.2× more radio energy per message (CON)

Recommendation for parking sensor: Use NON messages. Missing 1 occupancy update every 10 changes is acceptable (next update arrives in ~2 hours). The 5× radio-energy reduction per message significantly extends battery life for infrequent-reporting sensors where idle current dominates. Reserve CON messages for critical configuration commands (update rate, calibration).

:

45.13 Concept Relationships

Understanding how CoAP message types and patterns relate to broader IoT concepts:

CoAP Methods build on:

  • HTTP REST Architecture - RESTful principles adapted for constrained devices
  • UDP Transport - Connectionless communication enabling low overhead

CON/NON message types connect to:

  • Energy Management - Message type choice directly impacts battery life (2x difference)
  • Network Reliability - Application-layer reliability compensates for UDP’s best-effort delivery

Observe pattern relates to:

  • MQTT Pub/Sub - Similar push notification model but different architecture
  • Event-Driven Design - Server-initiated updates reduce polling overhead

These concepts enable:

  • Smart Home Systems - Efficient device control with minimal overhead
  • Industrial Monitoring - Battery-powered sensors lasting years on coin cells
  • Healthcare IoT - Low-latency vital sign monitoring with DTLS security

45.14 See Also

Related CoAP Chapters:

Alternative Protocols:

Design & Architecture:

  • Protocol Selection Guide - Decision frameworks for CoAP vs MQTT vs HTTP
  • Edge Computing Patterns - CoAP in edge-to-cloud architectures
  • Battery Life Optimization - Quantifying energy savings from NON messages

Practical Resources:

45.15 What’s Next

Chapter Focus Why Read It
CoAP Implementation Labs Hands-on Python and ESP32/Arduino CoAP code Translate the CON/NON/Observe concepts from this chapter into working code with real sensors
CoAP Observe Extension Deep dive into push notification mechanics, sequence numbers, and freshness Understand the full Observe protocol lifecycle including re-registration, Max-Age expiry, and error recovery
CoAP Security & DTLS Securing CoAP with DTLS, certificate management, and access control Learn how to protect CON and NON messages in production deployments without sacrificing the efficiency gains from this chapter
MQTT Fundamentals Publish-subscribe protocol comparison Compare CoAP’s request-response and Observe patterns against MQTT’s broker-based pub/sub to choose the right protocol for your deployment
IoT Protocols Overview Side-by-side comparison of CoAP, MQTT, AMQP, HTTP, and LwM2M Apply the decision framework from this chapter in a broader protocol selection context
Edge Computing Patterns CoAP in edge-to-cloud architectures See how the bandwidth savings quantified in this chapter translate into gateway and edge-node design decisions

Key Takeaways:

  • Use CON for commands, NON for telemetry — not all messages need confirmation
  • Observe pattern provides 97%+ bandwidth savings for slowly-changing data
  • CoAP is NOT just HTTP over UDP — it has unique features optimized for constrained devices
  • Idempotency of PUT/GET/DELETE enables safe retries on unreliable networks