38  CoAP Overview

In 60 Seconds

This is the learning path index for CoAP (Constrained Application Protocol), a lightweight RESTful protocol for IoT devices. The five-chapter series covers fundamentals and architecture, message types (CON/NON/ACK/RST), methods and multicast features, security with DTLS, and hands-on practice – building from basic concepts to complete implementations on constrained devices.

38.1 Learning Objectives

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

  • Explain CoAP’s architecture including the two-layer design (messaging + request/response) over UDP
  • Compare and Select CoAP message types (CON, NON, ACK, RST) appropriate for each reliability and energy scenario
  • Apply CoAP’s RESTful methods (GET, POST, PUT, DELETE) with resource discovery and multicast to solve IoT integration problems
  • Implement secure CoAP communication using DTLS encryption on constrained devices
  • Design and Construct CoAP applications with ESP32 and Python, justifying architectural decisions through hands-on practice

CoAP (Constrained Application Protocol) brings web-style communication to the world of tiny IoT sensors and devices. Just as your web browser uses HTTP to load websites, IoT devices use CoAP to exchange data – but in a much more lightweight and energy-efficient way designed for devices with limited resources.

“I want to share my data on the internet, but I’m just a tiny sensor with barely any memory!” said Sammy the Sensor, looking worried.

Max the Microcontroller reassured him. “That’s exactly why CoAP exists! It gives you web powers – GET, PUT, POST, DELETE – but in a tiny package. Regular HTTP is like a thick textbook, while CoAP is like a pocket notebook. Same information, fraction of the size.”

“Here’s what makes it special,” added Lila the LED. “CoAP uses UDP instead of TCP, so you skip all that handshaking overhead. And it uses binary headers instead of text – just 4 bytes compared to HTTP’s hundreds. For a sensor that sends thousands of readings a day, those saved bytes really add up!”

Bella the Battery was thrilled: “With CoAP, I can keep Sammy running for years on a single battery. HTTP would drain me in months because of all the extra overhead. CoAP is proof that good things come in small packets!”

38.2 CoAP Protocol Overview

⏱️ ~40 min total | ⭐⭐ Intermediate | 📋 P09.C28

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

This section provides a comprehensive introduction to the Constrained Application Protocol (CoAP), a specialized web transfer protocol designed for resource-constrained IoT devices and networks.

38.3 What You’ll Learn

CoAP brings RESTful web services to constrained devices, providing HTTP-like semantics with minimal overhead. This multi-chapter series covers:

38.3.1 1. CoAP Fundamentals

⏱️ ~8 min

Learn the basics of CoAP and why it’s essential for IoT: - What is CoAP and why was it created? - Why CoAP instead of HTTP for IoT devices? - Understanding the 4-byte header advantage - CoAP’s two-layer architecture (messaging + request/response) - Real-world battery life comparisons

Key Topics: Protocol basics, UDP vs TCP, REST for constrained devices, architecture overview

38.3.2 2. Message Types and Exchange Patterns

⏱️ ~8 min

Master CoAP’s four message types and communication patterns: - Confirmable (CON) messages for reliable delivery - Non-Confirmable (NON) for fire-and-forget efficiency - Acknowledgment (ACK) and Reset (RST) responses - Piggyback vs separate response patterns - CON vs NON battery life trade-offs

Key Topics: Message types, reliability, retransmission, exchange patterns

38.3.3 3. Methods, Multicast, and Features

⏱️ ~10 min

Explore CoAP’s RESTful methods and advanced features: - GET, POST, PUT, DELETE methods - Code examples (Python, Arduino ESP32) - Multicast support (IPv4/IPv6) - Resource discovery with .well-known/core - Interactive tools and protocol comparisons

Key Topics: RESTful methods, multicast, resource discovery, practical code

38.3.4 4. Security, Applications, and Implementation

⏱️ ~10 min

Implement CoAP securely in real-world applications: - Security with DTLS encryption - Smart energy and building automation use cases - Industrial IoT applications - Implementation patterns and best practices - Common pitfalls and troubleshooting

Key Topics: DTLS security, real-world apps, implementation, troubleshooting

38.3.5 5. Practice: Examples, Exercises, and Resources

⏱️ ~8 min

Apply your knowledge with hands-on practice: - Visual reference gallery (protocol diagrams) - Worked examples with calculations - Practice exercises (ESP32, multicast, proxies) - Further reading and academic resources

Key Topics: Worked examples, hands-on labs, exercises, resources

38.4 Prerequisites

Before starting this series, you should understand:

38.5 Learning Path

Recommended Study Order

For best results, follow this order:

  1. Start with CoAP Fundamentals - understand the protocol basics and why CoAP exists
  2. Then Message Types - learn how CoAP achieves reliability over UDP
  3. Next Methods and Features - explore RESTful operations and resource discovery
  4. Study Security and Applications - see CoAP in production systems
  5. Practice with Examples and Exercises - solidify understanding through hands-on work

Estimated total time: 40-50 minutes for initial read-through, plus 2-3 hours for exercises and experiments.

38.6 Interactive Tools

38.6.1 Protocol Overhead Calculator

Compare the bandwidth efficiency of CoAP vs HTTP for your specific use case:

38.6.2 Battery Life Calculator: CON vs NON Messages

Explore the energy trade-offs between reliable (CON) and efficient (NON) message types:

38.7 Quick Reference

38.7.1 When to Use CoAP

Choose CoAP when:

  • Request-response pattern needed (like HTTP GET/POST)
  • RESTful API design important (resources with URIs)
  • Minimal overhead critical (4-byte header)
  • Devices sleep most of the time (stateless, fast reconnect)
  • Integration with web services needed

Choose MQTT when:

  • Publish-subscribe pattern needed (one-to-many)
  • Persistent connections acceptable
  • Network is unreliable (TCP handles retransmissions)
  • Multiple subscribers need same data

Choose HTTP when:

  • Web browser clients
  • Rich middleware ecosystem needed
  • Network bandwidth plentiful
  • Standard web technologies required
Check Your Understanding: Protocol Selection

38.7.2 Key Characteristics

Aspect CoAP
Transport UDP (lightweight, connectionless)
Architecture RESTful (like HTTP)
Header Size 4 bytes minimum
Security DTLS (Datagram TLS)
Methods GET, POST, PUT, DELETE
Message Types CON, NON, ACK, RST
Best For Battery-powered sensors, constrained devices

For a 10-byte sensor payload, the total wire overhead for each protocol is:

CoAP total size: \[ S_{\text{CoAP}} = 4\text{ (CoAP hdr)} + 8\text{ (UDP hdr)} + 40\text{ (IPv6 hdr)} + 10\text{ (payload)} = 62\text{ bytes} \]

HTTP/1.1 total size: \[ S_{\text{HTTP}} = 150\text{ (HTTP hdr)} + 20\text{ (TCP hdr)} + 40\text{ (IPv6 hdr)} + 10\text{ (payload)} = 220\text{ bytes} \]

Bandwidth efficiency ratio: \[ \text{Efficiency gain} = \frac{S_{\text{HTTP}} - S_{\text{CoAP}}}{S_{\text{HTTP}}} = \frac{220 - 62}{220} \approx 72\% \]

For 500 devices sending hourly readings (24/day), annual bandwidth saved: \[ \text{Saved/year} = 500 \times 24 \times 365 \times 158\text{ bytes} \approx 660\text{ MB/year} \]

This 72% reduction also translates directly to energy savings, as radio transmission energy is proportional to bytes transmitted.

38.8 Chapter Summary

This CoAP series provides a comprehensive understanding of:

  • Protocol fundamentals: Why CoAP exists and how it works
  • Message reliability: CON vs NON trade-offs for battery life
  • RESTful operations: GET/POST/PUT/DELETE on IoT resources
  • Advanced features: Multicast, resource discovery, observe
  • Security: DTLS encryption for constrained devices
  • Real-world use: Smart energy, buildings, industrial IoT
  • Practical skills: Code examples, troubleshooting, exercises

By the end, you’ll be able to design, implement, and debug CoAP-based IoT systems with confidence.

38.9 Start Learning

Begin with CoAP Fundamentals →

Or jump to a specific topic: - Message Types → - Methods and Features → - Security and Applications → - Practice Exercises →

38.10 Knowledge Check

Common Mistake: Treating CoAP as “Simple HTTP over UDP”

The Misconception: Developers with HTTP experience often implement CoAP as “just replace TCP with UDP and shrink the headers,” leading to incorrect reliability assumptions and missed optimization opportunities.

What’s Wrong:

  1. Reliability is optional, not automatic: HTTP over TCP guarantees delivery. CoAP requires explicit CON messages for reliability, but NON messages intentionally sacrifice reliability for efficiency.

  2. Observe pattern has no HTTP equivalent: HTTP requires polling (GET /temp every 10 seconds). CoAP Observe registers once and receives push notifications only when data changes, saving 95%+ bandwidth.

  3. Multicast discovery is native: CoAP supports GET coap://[FF02::FD]/temp to query all sensors on a subnet with one packet. HTTP requires individual requests to each known device.

Real-World Example:

A developer ported an HTTP-based sensor network to CoAP by changing:

# Old HTTP code
response = requests.get('http://sensor/temp')

to:

# Naive CoAP "port"
response = await coap_client.get('coap://sensor/temp')

Problems encountered:

  • Still polling every 10 seconds (didn’t use Observe) → no bandwidth savings
  • Used CON for all messages (didn’t leverage NON) → no power savings
  • Didn’t implement multicast discovery → no infrastructure simplification
  • Result: Same energy cost as HTTP, just different syntax

Correct CoAP Implementation:

# Use Observe pattern (register once, get push updates)
request = Message(code=GET, uri='coap://sensor/temp', observe=0)
async for response in protocol.request(request).observation:
    process(response)  # Only when temp actually changes

# Use NON for frequent telemetry
telemetry = Message(code=POST, uri='coap://gateway/data',
                    mtype=NON, payload=sensor_data)
protocol.request(telemetry)  # Fire-and-forget, no ACK wait

# Use multicast for discovery
discover = Message(code=GET, uri='coap://[FF02::FD]/.well-known/core')

Result: 97% bandwidth reduction, 5× battery life improvement by using CoAP’s unique features rather than treating it as HTTP-over-UDP.

38.11 Concept Relationships

How this CoAP learning path connects to broader IoT concepts:

CoAP Foundation Concepts:

  • UDP vs TCP Transport - Why CoAP chose connectionless delivery
  • RESTful Architecture - HTTP-like semantics for constrained devices
  • Binary vs Text Protocols - 4-byte binary header efficiency

CoAP Compared to Alternatives:

  • MQTT Pub/Sub Model - Request/response vs broker-based messaging
  • HTTP for IoT - When to use full HTTP stack instead
  • AMQP Enterprise Messaging - Queue-based vs direct device communication

Enabling Technologies:

  • 6LoWPAN Adaptation - CoAP over IEEE 802.15.4 networks
  • DTLS Security - Encrypting CoAP over UDP
  • IPv6 Multicast - Group discovery with FF02::FD

CoAP Powers These Applications:

38.12 See Also

This Learning Path (5 Chapters):

Related Protocol Series:

Implementation Resources:

Specifications & Standards:

Advanced Topics:

  • CoAP Proxy Patterns - HTTP-CoAP translation
  • Resource Directory - Centralized service discovery
  • Group Communication - Multicast coordination