59  CoAP Review: Knowledge Assessment

In 60 Seconds

This assessment tests your CoAP knowledge through scenario-based questions covering protocol selection (CoAP vs MQTT vs HTTP), message type choices (CON vs NON for specific use cases), energy vs reliability tradeoff calculations, and debugging common implementation issues. Complete the other three review chapters before attempting this quiz.

59.1 Learning Objectives

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

  • Apply CoAP Knowledge: Implement correct protocol selection and configuration for given IoT scenarios
  • Analyze Trade-offs: Calculate and compare energy vs reliability decisions for constrained deployments
  • Diagnose Issues: Distinguish common CoAP failure modes and justify appropriate remediation strategies
  • Design Systems: Evaluate and select between CoAP, MQTT, and HTTP for specific IoT use cases
  • Assess Security: Justify the choice of DTLS and configure secure CoAP communication for sensitive data

Key Concepts

  • CoAP: Constrained Application Protocol — REST-style request/response protocol using UDP instead of TCP
  • Confirmable Message (CON): Requires ACK from recipient — provides reliable delivery over UDP at the cost of one roundtrip
  • Non-confirmable Message (NON): Fire-and-forget UDP datagram — lowest latency, no delivery guarantee
  • Observe Option: CoAP extension enabling publish/subscribe: client registers to receive notifications on resource changes
  • Block-wise Transfer: Fragmentation mechanism for transferring payloads larger than a single CoAP datagram
  • Token: Client-generated value matching responses to requests — enables concurrent request/response pairing
  • DTLS: Datagram TLS — CoAP’s security layer providing encryption and authentication over UDP

59.2 Interactive Energy Calculator

Calculate battery lifetime for CON vs NON message types with your own parameters:

The CON vs NON decision is an energy budget trade-off:

\[ E_{\text{day}} = N_{\text{msg/day}} \times E_{\text{msg}}, \qquad t_{\text{life}} = \frac{E_{\text{battery}}}{E_{\text{day}}} \]

Worked example: A node sends every 5 minutes (\(N_{\text{msg/day}}=288\)) with battery energy \(E_{\text{battery}}=25{,}920\) J. If a CON message costs 30 mJ and NON costs 15 mJ:

\[ E_{\text{day,CON}} = 288 \times 0.03 = 8.64 \text{ J/day} \] \[ E_{\text{day,NON}} = 288 \times 0.015 = 4.32 \text{ J/day} \]

Expected lifetimes are about \(25{,}920/8.64 \approx 3{,}000\) days (8.2 years) for CON and \(25{,}920/4.32 \approx 6{,}000\) days (16.4 years) for NON. This is why NON is preferred for non-critical telemetry.

Quick Check: Energy Trade-offs

Before proceeding, verify your understanding of the CON vs NON energy calculation:

This assessment covers the key CoAP concepts you have learned – message types, observe patterns, block transfers, and security. Think of it as a checkpoint that tests your practical understanding, not just memorization. Each question is designed to help you think like an IoT engineer making real design decisions.

59.3 Prerequisites

Required Reading:

Estimated Time: 30 minutes

This is Part 4 of the CoAP Comprehensive Review:

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

59.4 Interactive Protocol Comparison Calculator

Compare bandwidth and cost between CoAP, MQTT, and HTTP for your deployment:

Test your ability to connect CoAP terms to their definitions and sequence protocol steps correctly.

59.5 Quiz: CoAP Fundamentals

Test your understanding of CoAP protocol with these auto-gradable multiple-choice questions:

## Scenario-Based Knowledge Checks {#coap-quiz-scenarios}

Apply your CoAP knowledge to understand the WHY behind protocol choices:

## Understanding Check: Protocol Design Decisions {#coap-quiz-understanding}

Situation: You’re architecting communication for 50 battery-powered soil moisture sensors that report readings every 10 minutes.

Protocol options:

  • CoAP over UDP: No connection setup, 4-byte header, stateless
  • HTTP over TCP: 3-way handshake, 100+ byte headers, stateful connection

Think about:

  1. What happens every time an HTTP sensor wants to send a 6-byte moisture reading?
  2. How much time and energy is spent on TCP connection setup vs actual data transmission?
  3. Why is UDP’s “unreliable” nature actually acceptable for this use case?

Key Insight:

TCP Connection overhead:

Setup: SYN -> SYN-ACK -> ACK (150ms, 1.25mAh)
Data: Request + Response (100 bytes each)
Teardown: FIN-ACK, FIN-ACK (100ms, 0.5mAh)
Total per reading: ~400ms, 2mAh

UDP (CoAP) overhead:

No setup: Immediate send (0ms setup)
Data: CON request + ACK (22 bytes total)
Total per reading: ~20ms, 0.11mAh

For 10-minute readings over 1 year:

  • HTTP: 52,560 readings x 2mAh = 105Ah (needs 10x AA batteries!)
  • CoAP: 52,560 readings x 0.11mAh = 5.8Ah (single CR2032 sufficient)

18x energy savings by eliminating connection overhead!

Verify Your Understanding:

  • Can you explain when TCP’s reliability guarantees ARE worth the overhead cost?
  • For which IoT applications would you still choose HTTP over CoAP?
  • How does CoAP achieve reliability (when needed) without TCP?

Situation: You’re transmitting 1 million sensor readings per day across your IoT network. Each reading is 6 bytes (temperature value).

Compare protocols:

  • HTTP: ~165 bytes per transaction (headers + data)
  • CoAP: ~22 bytes per transaction (4-byte header + options + data)

Think about:

  1. How much bandwidth does each protocol consume for 1 million readings?
  2. What’s the cost impact if using cellular data ($10/GB)?
  3. Why is CoAP’s 4-byte header considered “minimal”?

Key Insight:

Bandwidth calculation:

HTTP:

Per reading: 165 bytes (headers) + 6 bytes (data) = 171 bytes
1 million readings: 171 MB/day
Monthly: 5.1 GB
Annual cost ($10/GB): $612

CoAP:

Per reading: 16 bytes (header + options) + 6 bytes (data) = 22 bytes
1 million readings: 22 MB/day
Monthly: 0.66 GB
Annual cost ($10/GB): $79

Savings: $533/year per million messages = 87% bandwidth reduction!

Why 4-byte header matters:

CoAP header breakdown:
- Version (2 bits)
- Type (2 bits): CON/NON/ACK/RST
- Token Length (4 bits): 0-8 bytes
- Code (8 bits): Method (GET/POST) or response (2.05 Content)
- Message ID (16 bits): Duplicate detection

Total: 32 bits = 4 bytes (vs HTTP's 100+ byte text headers)

For 10,000-sensor deployment:

  • HTTP monthly data: 510 GB -> $5,100/month
  • CoAP monthly data: 66 GB -> $660/month
  • Savings: $4,440/month = $53,280/year!

Situation: You have 100 temperature sensors distributed across a building. You want to query “What’s everyone’s current temperature?” without knowing their individual IP addresses.

Traditional approach (unicast):

For each sensor IP in [192.168.1.10 ... 192.168.1.110]:
    Send: GET coap://192.168.1.X/temp
    Receive: 23.5C
Total: 100 requests x 50ms = 5 seconds

Think about:

  1. How could you reduce 100 individual requests to a single message?
  2. What IPv6 feature allows one packet to reach multiple destinations?
  3. How do sensors avoid all responding simultaneously (collision)?

Key Insight:

CoAP Multicast (FF0X::FD):

Single request: GET coap://[FF02::FD]/temp
All sensors on link receive request
Each adds random delay (0-1000ms) before responding
Collect responses over 2-second window

Result: 1 request -> 100 responses (staggered)
Time: ~2 seconds (vs 5 seconds unicast)
Bandwidth: 22 bytes sent (vs 2200 bytes unicast)

Multicast addressing:

  • FF02::FD: Link-local (same network segment)
  • FF05::FD: Site-local (entire building/campus)
  • Scope controls propagation distance

Use cases:

  1. Device discovery: Find all CoAP devices: GET coap://[FF02::FD]/.well-known/core
  2. Group commands: Turn off all lights: POST coap://[FF05::FD]/lights {"state": "off"}
  3. Network diagnostics: Query all devices for status, firmware version

Limitations:

  • Responses may collide (5-10% loss with 100 devices)
  • No guaranteed delivery (multicast + UDP = best-effort)
  • Doesn’t scale beyond ~1000 devices (response flood)

59.6 Interactive Observe Bandwidth Calculator

Compare bandwidth consumption between HTTP polling, basic CoAP Observe, and conditional CoAP Observe:

Scenario: A smart home deployment monitors 50 temperature sensors. You need to compare bandwidth consumption between traditional HTTP polling, basic CoAP Observe, and conditional CoAP Observe (with 0.5°C change threshold).

Given:

  • Monitoring period: 24 hours
  • Actual temperature changes: 6 per day per sensor (HVAC cycling)
  • HTTP polling interval: 30 seconds
  • CoAP message size: 22 bytes (4B header + 2B token + 8B options + 8B payload)
  • HTTP transaction size: 165 bytes (request + response headers + payload)
  • Temperature resolution: 0.1°C
  • Notification threshold: 0.5°C change

Step 1: Calculate HTTP polling bandwidth

Polls per sensor per day: (24 hours × 3600 sec) / 30 sec = 2,880 polls
Total polls: 50 sensors × 2,880 = 144,000 polls/day

Bandwidth per sensor: 2,880 polls × 165 bytes = 475,200 bytes = 464.1 KB
Total bandwidth: 50 × 475,200 = 23,760,000 bytes = 22.66 MB/day

Step 2: Calculate basic CoAP Observe bandwidth

Initial registration: 1 message per sensor
Notifications: 6 per day per sensor (all temp changes reported)

Messages per sensor: 1 + 6 = 7 messages/day
Total messages: 50 × 7 = 350 messages/day

Bandwidth per sensor: 7 × 22 bytes = 154 bytes
Total bandwidth: 50 × 154 = 7,700 bytes = 7.52 KB/day

Reduction vs HTTP: (22.66 MB - 7.52 KB) / 22.66 MB = 99.97%

Step 3: Calculate conditional CoAP Observe (0.5°C threshold)

Temperature drift per change: ±0.1°C to ±2.0°C
Average change magnitude: 0.8°C
Changes exceeding 0.5°C threshold: 4 out of 6 (67%)

Notifications per sensor: 4 significant changes/day
Messages per sensor: 1 registration + 4 notifications = 5/day
Total messages: 50 × 5 = 250 messages/day

Bandwidth per sensor: 5 × 22 bytes = 110 bytes
Total bandwidth: 50 × 110 = 5,500 bytes = 5.37 KB/day

Additional reduction: (7.52 KB - 5.37 KB) / 7.52 KB = 28.6%

Step 4: Calculate monthly and annual costs (cellular data)

Cellular data cost: $10 per GB

HTTP polling:
  Monthly: 22.66 MB/day × 30 = 679.8 MB = 0.68 GB
  Annual cost: 0.68 GB/month × 12 × $10 = $81.60

Basic CoAP Observe:
  Monthly: 7.52 KB/day × 30 = 225.6 KB = 0.00022 GB
  Annual cost: 0.00022 GB/month × 12 × $10 = $0.03

Conditional CoAP Observe:
  Monthly: 5.37 KB/day × 30 = 161.1 KB = 0.00016 GB
  Annual cost: 0.00016 GB/month × 12 × $10 = $0.02

Result Summary:

Approach Messages/Day Bandwidth/Day Annual Cost vs HTTP
HTTP Polling 144,000 22.66 MB $81.60 Baseline
Basic Observe 350 7.52 KB $0.03 99.97% reduction
Conditional Observe 250 5.37 KB $0.02 99.98% reduction

Key Insights:

  1. CoAP Observe achieves 99.97% bandwidth reduction by eliminating 143,650 unnecessary polls per day
  2. Conditional observe adds another 28.6% savings by suppressing insignificant changes (±0.3°C fluctuations)
  3. For 50-sensor deployment, annual savings = $81.58 (switching from HTTP to conditional observe)
  4. For 10,000-sensor deployment, annual savings = $163,160

Recommendation: Always implement conditional observe with application-specific thresholds (0.5°C for temperature, 5% for humidity, etc.) to maximize efficiency while preserving data quality.

59.7 Concept Relationships

How these assessment scenarios connect to IoT design principles:

CoAP vs MQTT vs HTTP Selection:

  • Protocol Comparison Framework - Multi-criteria decision matrices
  • Communication Patterns - Request/response vs pub/sub vs streaming
  • Network Constraints - Bandwidth, latency, reliability trade-offs

Energy vs Reliability Trade-offs:

  • Battery Life Optimization - Calculating CON vs NON impact
  • Retransmission Strategies - Exponential backoff and timeout tuning
  • Power Profiling - Real device energy measurement

Multicast Discovery Patterns:

  • Service Discovery - mDNS, DNS-SD, CoAP multicast comparison
  • IPv6 Multicast - Scope and addressing schemes
  • Zero-Configuration Networking - Plug-and-play device integration

Block Transfer for Firmware:

  • OTA Update Strategies - Reliable delivery over lossy links
  • MTU and Fragmentation - Avoiding IP-layer fragmentation
  • Resumable Transfers - Recovering from interruptions

59.8 Knowledge Check: Matching and Ordering

Match each CoAP concept to its correct definition:

Arrange the following steps of a CoAP Observe interaction in the correct sequential order:

Common Pitfalls

CON messages require an ACK roundtrip — on lossy networks with 20% packet loss, a 4-attempt retry with exponential backoff can delay responses by 45 seconds. Use NON for periodic telemetry where data freshness matters more than guaranteed delivery; reserve CON for actuation commands.

CoAP proxies cache GET responses based on Max-Age option — a sensor returning temperature with Max-Age=60 will serve cached values for 60 seconds even if the physical reading changes. Set Max-Age to match your data freshness requirement, not the default 60 seconds.

DTLS handshake (6-8 roundtrips) dominates latency for short-lived CoAP connections — repeatedly creating new DTLS sessions for each request adds 500-2000ms overhead. Use DTLS session resumption (RFC 5077) to reduce reconnection to 1 roundtrip after the initial handshake.

59.9 Summary

This chapter tested your CoAP knowledge through:

  • 12 Fundamentals Questions: Message types, protocol comparison, transport selection, security
  • 12 Scenario-Based Questions: Real-world decision making for sensor networks, reliability, multicast
  • 3 Understanding Checks: Deep-dive analysis of protocol design decisions with quantified trade-offs
  • 3 Interactive Calculators: Energy budget, protocol comparison, and Observe pattern analysis tools

Key Takeaways:

  • Use CON for critical commands, NON for frequent sensor readings
  • CoAP achieves 87% bandwidth reduction and 18x energy savings vs HTTP
  • Multicast enables efficient one-to-many communication for discovery and group commands
  • Block-wise transfer handles large payloads like firmware updates
  • DTLS provides encryption, authentication, and integrity for secure CoAP
  • Conditional Observe dramatically reduces bandwidth while maintaining data quality

59.10 See Also

Assessment Series Navigation:

Core Learning Resources:

Alternative Protocols:

Design & Architecture:

  • IoT Protocol Selection Tool - Interactive decision guide
  • Edge Computing Patterns - CoAP in edge architectures
  • Security Best Practices - DTLS configuration

Implementation Libraries:

Specifications:

59.11 What’s Next

You have completed the CoAP Comprehensive Review series. Use the table below to continue with related material based on your goals:

Chapter Focus Why Read It
CoAP Review: Protocol Fundamentals Message types, header structure, architecture Revisit the core protocol mechanics that underpin every question in this assessment
CoAP Review: Observe Patterns Push notifications, subscription lifecycle Deepen your understanding of the Observe pattern scenarios tested in Section 3
CoAP Review: Labs and Implementation ESP32 and Python hands-on CoAP Apply the protocol decisions from this quiz to running code on real hardware
MQTT Learning Path Publish-subscribe messaging, broker architecture Compare CoAP’s request-response model against MQTT’s pub-sub model in practice
CoAP Practice Exercises Worked examples and calculations Continue building calculation fluency with additional energy and bandwidth problems
CoAP Implementation Labs Advanced ESP32 and Python lab work Extend assessment knowledge into full CoAP server and client implementation labs

59.12 Further Reading