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

  • GET: Retrieve a resource. HTTP equivalent: GET. Idempotent: Yes. CoAP code: 0.01. Typical HTTP response: 200 OK.
  • POST: Create a new resource or submit data. HTTP equivalent: POST. Idempotent: No. CoAP code: 0.02. Typical HTTP response: 201 Created.
  • PUT: Update a known resource or create it at a known URI. HTTP equivalent: PUT. Idempotent: Yes. CoAP code: 0.03. Typical HTTP response: 200 or 204.
  • DELETE: Remove a resource. HTTP equivalent: DELETE. Idempotent: Yes. CoAP code: 0.04. Typical HTTP response: 200 or 204.

45.5.2 Key Differences from HTTP

  • Header size: HTTP commonly spends 200 to 500 bytes on headers, while CoAP starts with a 4-byte fixed header. Impact: about 95 percent less overhead.
  • Transport: HTTP relies on TCP reliability. CoAP uses UDP and keeps the exchange lighter.
  • Reliability control: HTTP gets reliability from the transport layer. CoAP chooses it at the application layer with CON or NON.
  • Caching and discovery: HTTP uses standard cache headers and DNS plus OPTIONS. CoAP uses Max-Age and /.well-known/core.
  • Multicast: HTTP does not support it natively. CoAP does, which helps with device discovery.

Sequence diagram showing CoAP client sending GET, PUT, POST, and DELETE requests to a CoAP server with corresponding responses. Uses navy for the client, teal for the server, and orange for command flows.

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 a single fire-and-forget transmission. IEEE colors used: navy for devices, teal for successful delivery, and orange for retry logic.

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:

  • Reliability: CON guarantees delivery with retries. NON is best-effort and may be lost.
  • Latency: CON adds round-trip time and retry delays on failure. NON is a one-way send with no retry pause.
  • Power and bandwidth: CON usually costs 2x to 10x more energy because it waits for ACKs and may retransmit. NON uses one transmission.
  • Congestion: CON adds ACK traffic and retry bursts. NON keeps the network quieter.
  • Implementation: CON needs timeout tracking and retry queues. NON is much simpler to send.
  • Loss detection: CON spots failure when the ACK times out. NON fails silently unless the application adds heartbeat logic.

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 with repeated GET requests versus Observe with one registration and change-driven notifications. A footer callout highlights roughly 97 percent bandwidth savings 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:

  • Initial setup: Polling starts immediately with GET. Observe needs one registration request.
  • Stable data: Polling keeps sending requests even when nothing changed. Observe stays quiet until a change happens.
  • Volatile data: If the value changes constantly, Observe can approach the same message volume as polling.
  • Latency: Polling detects a change roughly halfway through the poll interval on average. Observe is close to immediate.
  • Complexity: Polling keeps the client simple. Observe adds subscription state, server memory, and re-registration logic.
  • Networking: Polling is naturally client-initiated and NAT-friendly. Observe can need keep-alives or local-network deployment to stay reliable.
  • Recovery: Polling catches up on the next request. Observe clients must notice loss and 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 guide for selecting CoAP message types. It starts with delivery criticality, then checks whether the traffic is state changing or high frequency. CON ends at commands, alerts, and firmware blocks while NON ends at telemetry and discovery.

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. It first asks whether delivery confirmation is critical to choose CON or NON, then asks whether updates are event-driven to choose Observe or Polling. Terminal nodes include command path, real-time events, periodic telemetry, and discovery.

CoAP Message Type and Pattern Decision Flowchart

Quick Reference Guide:

  • Door lock command: Message type CON, pattern Request-Response, example PUT /lock {"state": "unlocked"}.
  • Fire alarm: Message type CON, pattern Observe, example Subscribe to /alarm.
  • Temperature reading (5 min): Message type NON, pattern Polling, example Gateway polls sensors.
  • Motion detection: Message type NON, pattern Observe, example Push on movement detected.
  • Firmware update: Message type CON, pattern Block Transfer, example Block2 with reliable delivery.
  • Device discovery: Message type NON, pattern Multicast, example /.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 with three CoAP paths: NON telemetry from thermostat to gateway, CON commands between gateway and HVAC, and an Observe subscription from the phone app to the thermostat current-state resource.

Smart Thermostat CoAP Communication Design

45.12.1 Design Decisions Explained

  • /readings: Method POST, type NON, pattern Push. Rationale: High-frequency data where the next reading supersedes a missed one.
  • /thermostat/current: Method GET, type CON, pattern Observe. Rationale: The app needs live updates, and occasional re-registration is acceptable.
  • /thermostat/setpoint: Method PUT, type CON, pattern Request-Response. Rationale: A user command must confirm that the new setpoint was applied.
  • /hvac/mode: Method PUT, type CON, pattern Request-Response. Rationale: Heating and cooling mode changes are safety-critical.
  • /.well-known/core: Method GET, type NON, pattern Discovery. Rationale: Discovery can tolerate an occasional missed response.
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

  • CoAP Implementation Labs: Hands-on Python and ESP32/Arduino CoAP code. Why read it: Translate the CON, NON, and Observe concepts from this chapter into working code with real sensors.
  • CoAP Observe Extension: Deep dive into push notification mechanics, sequence numbers, and freshness. Why read it: Understand the full Observe lifecycle, including re-registration, Max-Age expiry, and error recovery.
  • CoAP Security & DTLS: Securing CoAP with DTLS, certificate management, and access control. Why read it: Protect CON and NON traffic in production without losing the efficiency gains from this chapter.
  • MQTT Fundamentals: Publish-subscribe protocol comparison. Why read it: Compare CoAP request-response and Observe with MQTT broker-based pub/sub.
  • IoT Protocols Overview: Side-by-side comparison of CoAP, MQTT, AMQP, HTTP, and LwM2M. Why read it: Reuse this chapter’s decision framework in a broader protocol-selection context.
  • Edge Computing Patterns: CoAP in edge-to-cloud architectures. Why read it: See how the bandwidth savings from this chapter affect gateway and edge-node design.

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