1220  CoAP Introduction and Protocol Overview

1220.1 Learning Objectives

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

• Explain Why CoAP Exists: Understand the limitations of HTTP for constrained IoT devices
• Describe CoAP’s Design Philosophy: Explain how CoAP provides lightweight RESTful services
• Compare with HTTP and MQTT: Differentiate between web protocols for IoT
• Identify Ideal Use Cases: Recognize when CoAP is the right protocol choice

ImportantThe Challenge: HTTP is Too Heavy for Constrained Devices

The Problem: HTTP was designed for web browsers and servers with abundant resources, not battery-powered sensors with kilobytes of RAM:

• HTTP headers: 200-800 bytes per request (vs. a 10-byte sensor payload)
• TCP connection overhead: 3-way handshake + TLS negotiation = 2-5 seconds setup time
• Persistent connections: Each TCP connection requires ~1KB RAM for state management
• Text parsing: CPU cycles wasted on ASCII header parsing

Why This is Hard for IoT:

• Constrained devices have 2-32KB RAM (not megabytes)
• Batteries must last months or years (not hours)
• Lossy networks drop packets (TCP retransmissions waste precious energy)
• Yet web semantics (REST, URIs, content negotiation) remain valuable for interoperability

What We Need:

• HTTP-like semantics: GET, PUT, POST, DELETE for familiar REST patterns
• UDP-based transport: No connection state to maintain
• Binary encoding: Efficient parsing on 8-bit microcontrollers
• Built-in reliability: Optional confirmations without TCP’s overhead

The Solution: CoAP provides “web services for constrained environments” - all the RESTful goodness of HTTP compressed into a compact binary format running over UDP. This chapter shows you how.

1220.2 Prerequisites

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

• MQTT Protocol: Understanding the alternative publish-subscribe messaging approach helps appreciate CoAP’s request-response model and when to choose each protocol
• Networking Basics: Foundation for understanding RESTful principles, HTTP methods (GET/POST/PUT/DELETE), URIs, and how CoAP adapts these concepts for constrained devices
• UDP/IP Networking: CoAP operates over UDP rather than TCP, requiring knowledge of connectionless communication, packet loss, and reliability trade-offs

NoteCross-Hub Connections: Enhance Your Learning

This chapter connects to multiple learning resources:

Video Resources - Visit the Videos Hub for: - Visual explanations of CoAP message flows and reliability mechanisms - Protocol comparison demonstrations (CoAP vs HTTP vs MQTT) - Real-world deployment case studies with network traffic analysis

Practice Quizzes - Test your understanding at Quizzes Hub: - CoAP message format and header field encoding - Message type selection (CON vs NON) for different scenarios - Response code interpretation and error handling - Block-wise transfer and Observe extension mechanics

Simulations - Explore interactive tools at Simulations Hub: - CoAP Message Builder: Construct and decode CoAP packets byte-by-byte - Reliability Simulator: Compare CON vs NON under different packet loss rates - Protocol Comparator: Side-by-side overhead analysis (CoAP vs HTTP vs MQTT) - Observe Pattern Demo: Visualize server-push notifications in action

Knowledge Gaps - Common misconceptions addressed at Knowledge Gaps Hub: - “CoAP is just compressed HTTP” - See section on UDP vs TCP fundamental differences - “NON messages are unreliable and shouldn’t be used” - Learn when fire-and-forget is optimal - “CoAP can’t handle large files” - Explore block-wise transfer mechanisms

NoteKey Takeaway

CoAP is “HTTP for constrained devices” - it provides familiar RESTful semantics (GET, PUT, POST, DELETE on URIs) but compresses everything into a compact binary format running over UDP. Where HTTP requires hundreds of bytes of headers and a TCP connection, CoAP uses just 4 bytes of fixed header and no connection state. The protocol offers two message types: Confirmable (CON) for reliable delivery with acknowledgments, and Non-confirmable (NON) for fire-and-forget efficiency. If you remember nothing else: CoAP lets your 8-bit microcontroller with 2KB RAM expose web-style APIs, enabling direct integration with cloud services and standard REST tooling without HTTP’s overhead.

1220.3 Getting Started (For Beginners)

TipNew to CoAP? Start Here!

Time: ~12 min | Difficulty: Intermediate | Unit: P09.C29.U01

If you’re unfamiliar with RESTful protocols or wondering why IoT devices need something different from regular HTTP, this section explains the basics.

1220.3.1 What Problem Does CoAP Solve?

Scenario: You want a temperature sensor to expose its readings via a web API, like a regular website.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'noteTextColor': '#2C3E50', 'noteBkgColor': '#fff9e6', 'textColor': '#2C3E50', 'fontSize': '16px'}}}%%
graph LR
    Sensor["Tiny Sensor<br/>(8 KB RAM)"]
    HTTP["HTTP/TCP<br/>Connection: keep-alive<br/>User-Agent: Mozilla...<br/>Accept-Encoding: gzip...<br/>(200+ bytes overhead)"]
    CoAP["CoAP/UDP<br/>GET /temp<br/>(4-byte header)"]
    App["Mobile App"]

    Sensor -->|"Too heavy!"| HTTP
    Sensor -->|"Perfect!"| CoAP
    CoAP --> App

    style Sensor fill:#2C3E50,stroke:#16A085,color:#fff
    style HTTP fill:#E74C3C,stroke:#C0392B,color:#fff
    style CoAP fill:#16A085,stroke:#16A085,color:#fff
    style App fill:#E67E22,stroke:#D35400,color:#fff

NoteAlternative View: Protocol Stack Comparison

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
graph TB
    subgraph HTTP_Stack["HTTP Stack"]
        H_APP["Application<br/>(HTTP)"]
        H_SEC["Security<br/>(TLS)"]
        H_TRANS["Transport<br/>(TCP)"]
        H_NET["Network<br/>(IP)"]
    end

    subgraph CoAP_Stack["CoAP Stack"]
        C_APP["Application<br/>(CoAP)"]
        C_SEC["Security<br/>(DTLS)"]
        C_TRANS["Transport<br/>(UDP)"]
        C_NET["Network<br/>(IP/6LoWPAN)"]
    end

    H_APP --> H_SEC --> H_TRANS --> H_NET
    C_APP --> C_SEC --> C_TRANS --> C_NET

    style HTTP_Stack fill:#7F8C8D,stroke:#2C3E50
    style CoAP_Stack fill:#16A085,stroke:#2C3E50

This diagram compares the protocol stacks: HTTP uses TCP with TLS, while CoAP uses UDP with DTLS and can run over 6LoWPAN for constrained networks.

1220.3.2 CoAP: “HTTP for Tiny Devices”

Analogy: Full Restaurant vs. Food Truck

Full Restaurant (HTTP)	Food Truck (CoAP)
Waiters, menus, multiple courses	Simple menu, quick service
Reservations, table management	First come, first served
Fine dining experience	Get food, eat, go
High overhead, great experience	Low overhead, efficient

CoAP is like HTTP, but:

• Smaller - 4-byte header vs. 100s of bytes for HTTP
• Faster - UDP (no TCP handshake)
• Simpler - Less code, less memory
• RESTful - Same GET/POST/PUT/DELETE pattern

1220.4 What is CoAP?

TipDefinition

CoAP (Constrained Application Protocol) is a specialized web transfer protocol designed for resource-constrained nodes and networks. It provides a lightweight RESTful interface similar to HTTP, but optimized for IoT devices with limited processing power, memory, and energy.

Designed by: IETF Constrained RESTful Environment (CoRE) Working Group

Key Characteristics:

• Transport: UDP (not TCP like HTTP)
• Architecture: RESTful (like HTTP)
• Security: DTLS (Datagram TLS)
• Overhead: Minimal (4-byte header vs HTTP’s larger headers)
• Network: IPv4 and IPv6 (esp. for IEEE 802.15.4)
• Use Cases: Smart energy, building automation, sensor networks

1220.5 Understanding CoAP vs. MQTT vs. HTTP

These three protocols serve different purposes:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'noteTextColor': '#2C3E50', 'noteBkgColor': '#fff9e6', 'textColor': '#2C3E50', 'fontSize': '14px'}}}%%
graph TB
    subgraph HTTP["HTTP (Request-Response)"]
        Browser["Browser"] -->|GET /api/data| WebServer["Web Server"]
        WebServer -->|200 OK + JSON| Browser
    end

    subgraph CoAP["CoAP (Request-Response)"]
        IoTDevice["IoT Device"] -->|GET /sensor| CoAPServer["CoAP Server"]
        CoAPServer -->|2.05 Content| IoTDevice
    end

    subgraph MQTT["MQTT (Publish-Subscribe)"]
        Sensor1["Sensor"] -->|Publish temp| Broker["MQTT Broker"]
        Sensor2["Sensor"] -->|Publish humidity| Broker
        Broker -->|Subscribe| Dashboard["Dashboard"]
        Broker -->|Subscribe| Analytics["Analytics"]
    end

    style HTTP fill:#3498DB,stroke:#2980B9,color:#fff
    style CoAP fill:#16A085,stroke:#16A085,color:#fff
    style MQTT fill:#E67E22,stroke:#D35400,color:#fff

When to use which:

Use Case	Best Protocol	Why
Sensor reports temperature	MQTT	One-to-many pub/sub
App requests sensor reading	CoAP	Direct request-response
Firmware download	HTTP	Large file transfer
Smart light on/off	CoAP	Direct command
Dashboard updates	MQTT	Real-time streaming

{
  const container = document.getElementById('kc-coap-protocol');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "You're building a smart irrigation system. The controller needs to directly read soil moisture from a sensor and send 'open valve' commands. Which protocol is BEST for this direct device-to-device communication?",
      options: [
        {text: "HTTP - it's the standard web protocol", correct: false, feedback: "HTTP works but has high overhead (TCP handshake, large headers) unsuitable for constrained devices."},
        {text: "MQTT - it's designed for IoT", correct: false, feedback: "MQTT excels for pub/sub (one-to-many) but requires a broker. For direct request-response, it adds unnecessary complexity."},
        {text: "CoAP - lightweight request-response for IoT", correct: true, feedback: "CoAP is ideal: GET /soil-moisture returns the reading, PUT /valve?state=open sends commands - all with minimal overhead."},
        {text: "WebSocket - provides real-time updates", correct: false, feedback: "WebSockets maintain persistent connections, which drain battery on constrained devices."}
      ],
      explanation: "CoAP is designed for direct request-response communication between constrained devices. It uses UDP (no TCP handshake), has a 4-byte header (vs. HTTP's 100s of bytes), and supports RESTful patterns (GET, PUT, POST, DELETE). For direct device commands and queries, CoAP beats MQTT (which needs a broker) and HTTP (which is too heavy).",
      difficulty: "medium",
      topic: "coap-protocol"
    }));
  }
}

1220.6 Why CoAP Instead of HTTP?

1220.6.1 The Problem with HTTP for IoT

HTTP is excellent for the web, but problematic for constrained devices:

Issue	HTTP	CoAP
Protocol	TCP (connection-oriented)	UDP (lightweight)
Header Size	100s of bytes	4 bytes minimum
Power Consumption	High (TCP handshake)	Very low
Overhead	Significant	Minimal
Complexity	Complex parsing	Simple
Best For	Web browsers	Sensors, actuators

WarningCommon Misconception: “CoAP is Just Compressed HTTP”

The Myth: Many developers assume CoAP is simply HTTP with smaller headers, and that you can use the same architecture patterns.

The Reality: CoAP fundamentally differs from HTTP due to UDP vs TCP transport, requiring different design patterns.

Real-World Impact - Smart Building Deployment:

A European smart building company migrated 2,500 sensors from HTTP to CoAP in 2023. Their experience quantifies the differences:

Network Overhead Reduction: - HTTP baseline: Each sensor report = 347 bytes average (TCP handshake: 3 packets x 60 bytes + HTTP GET/response: 227 bytes) - CoAP deployment: Each sensor report = 42 bytes average (UDP: 0 handshake + CoAP GET/response: 42 bytes) - 8.3x reduction in network traffic (347 to 42 bytes per reading) - Annual savings: 2,500 sensors x 8,760 readings/year = 6.7 TB to 0.8 TB (85% bandwidth saved)

Battery Life Extension: - HTTP: 18 months average battery life (CR123A lithium, 1500 mAh) - CoAP with NON: 54 months average battery life (same battery) - 3x battery life due to eliminated TCP handshake overhead (3 extra packets per reading = 26,280 packets/year x 20 mA x 25 ms = 131 mAh wasted)

But Reliability Challenges Emerged: - Wi-Fi packet loss averaged 12% in production environment - CON retransmissions consumed 15% more power than expected - Solution: Hybrid approach - NON for frequent updates (every 60s), CON for alerts (threshold exceeded) - Result: 2.8x battery life improvement with 99.7% reliability

Key Lesson: CoAP’s stateless UDP model requires application-level reliability design (CON/NON selection), unlike HTTP’s automatic TCP retransmission. You gain efficiency but must handle reliability explicitly.

Source: IoT Analytics Report, Smart Building Protocols 2023 - Real deployment data from 87 European commercial buildings

WarningUDP Means No Reliability Guarantees

CoAP uses UDP, which has critical implications for IoT deployments:

UDP characteristics: - No connection - packets can arrive out-of-order or be lost - No automatic retransmission - application must handle with CON messages - No congestion control - can overwhelm networks if not careful - Firewall/NAT challenges - many networks block UDP traffic

When this causes problems: - Lossy Wi-Fi/cellular networks: 10-30% packet loss means frequent retransmissions - Firewall traversal: Corporate networks often block UDP, preventing CoAP communication - NAT timeout: UDP “connections” expire faster than TCP (30-60 seconds typical)

Solutions: - Use CON messages for important data (adds reliability) - Implement exponential backoff for retransmissions - Consider MQTT (TCP-based) for unreliable networks - Use CoAP over DTLS for secure, more reliable communication - Test thoroughly in production network conditions

TipWhen to Choose CoAP Over MQTT

Both are lightweight IoT protocols, but serve different use cases:

Choose CoAP when: - You need request-response pattern (like HTTP GET/POST) - RESTful API design is important (resources with URIs) - Minimal overhead is critical (4-byte header vs MQTT’s 2-byte minimum + TCP overhead) - Devices sleep most of the time (CoAP stateless, reconnects fast) - Integration with web services (CoAP to HTTP proxies exist)

Choose MQTT when: - You need publish-subscribe (one-to-many communication) - Persistent connections are acceptable - Network is unreliable (TCP handles retransmissions automatically) - Multiple subscribers need same data - Broker-based architecture fits your deployment

Example: Smart thermostat that responds to user commands - CoAP. Temperature sensor publishing to dashboard and logging service - MQTT.

1220.6.2 REST for Constrained Devices

REST (Representational State Transfer) is the standard interface between HTTP clients and servers. CoAP brings REST to IoT:

HTTP Method	CoAP Method	Purpose	Example
GET	GET	Retrieve resource	Get sensor reading
POST	POST	Create resource	Submit new data
PUT	PUT	Update resource	Change actuator state
DELETE	DELETE	Remove resource	Clear sensor log

CoAP Resource Example:

coap://sensor.local/temperature
coap://sensor.local/humidity
coap://actuator.local/led/status

WarningCommon Misconception: “CoAP is Just HTTP for IoT”

The Misconception: CoAP is a lightweight version of HTTP with the same semantics.

Why It’s Wrong: - CoAP uses UDP (not TCP) - completely different reliability model - CoAP has Observe (server push) - HTTP doesn’t natively - CoAP supports multicast - HTTP is point-to-point - Message model differs: CON/NON/ACK/RST vs request/response - Caching and proxy behavior are different

Real-World Example: - HTTP polling: Client asks “temperature?” every second - CoAP Observe: Client registers once, server pushes changes - HTTP: 86,400 requests/day for 1-second updates - CoAP: 1 registration + ~100 notifications (on change) - Result: 99.9% less traffic with Observe pattern

The Correct Understanding: | Feature | HTTP | CoAP | |———|——|——| | Transport | TCP | UDP | | Server push | No (needs WebSocket) | Yes (Observe) | | Multicast | No | Yes | | Message types | 1 (request) | 4 (CON/NON/ACK/RST) | | Proxying | HTTP proxy | CoAP proxy (different) |

CoAP is inspired by REST but designed for constrained networks. Don’t assume HTTP patterns work.

1220.7 Worked Example: Protocol Overhead Comparison

This worked example demonstrates the dramatic difference in network overhead between CoAP, HTTP, and MQTT for a real IoT deployment scenario. Understanding these calculations helps you make informed protocol choices for constrained devices.

NoteWorked Example: IoT Sensor Protocol Overhead Analysis

Context: A smart agriculture deployment with soil moisture sensors sending temperature and humidity readings to a gateway.

Given:

• Sensor readings: 1,000 readings per day (approximately 1 reading every 86 seconds)
• Payload size: 24 bytes per reading ({"temp":22.5,"hum":65.2})
• Network: 6LoWPAN mesh network with limited bandwidth

Protocol Specifications:

Protocol	Transport	Header Overhead	Connection Setup
CoAP	UDP	4 bytes (fixed header)	None (stateless)
HTTP/1.1	TCP	~200-400 bytes	3-way handshake + TLS
MQTT	TCP	2 bytes (fixed) + variable	TCP handshake + CONNECT/CONNACK

---

1220.7.1 Step 1: CoAP Overhead Calculation

CoAP per-message overhead:

• Fixed header: 4 bytes
• Token: 2 bytes (typical for matching requests)
• Uri-Path option: ~15 bytes (/sensor/data with option delta encoding)
• Payload marker: 1 byte (0xFF)
• Total CoAP overhead: 22 bytes per message

UDP/IP overhead (transport layer):

• UDP header: 8 bytes
• IPv6 header: 40 bytes (or IPv4: 20 bytes)
• Total transport: 48 bytes (IPv6) or 28 bytes (IPv4)

Daily CoAP calculation (IPv6):

\[ \text{CoAP daily} = 1000 \times (22 + 24 + 48) = 1000 \times 94 = \textbf{94,000 bytes/day} \]

Monthly total: \(94,000 \times 30 = \textbf{2.82 MB/month}\)

---

1220.7.2 Step 2: HTTP/1.1 Overhead Calculation

HTTP per-message = 192 (request headers) + 24 (payload) + 120 (response) + 60 (TCP/IP headers) + 2 (connection amortized) = 398 bytes

Daily HTTP calculation:

\[ \text{HTTP daily} = 1000 \times 398 = \textbf{398,000 bytes/day} \]

Monthly total: \(398,000 \times 30 = \textbf{11.94 MB/month}\)

---

1220.7.3 Step 3: Final Comparison

Metric	CoAP (NON/UDP)	MQTT (QoS 0/TCP)	HTTP/1.1 (TCP)
Total per message	94 bytes	113 bytes	398 bytes
Daily (1000 messages)	94 KB	113 KB	398 KB
Monthly	2.82 MB	3.39 MB	11.94 MB
Relative efficiency	1.0x (baseline)	1.2x	4.2x

Conclusion: For resource-constrained IoT devices sending small, frequent sensor readings, CoAP provides the best balance of efficiency and simplicity.

1220.8 Self-Check: Understanding the Basics

Before continuing, make sure you can answer:

1. Why not just use HTTP for IoT? - HTTP is too heavy (large headers, TCP overhead, high power consumption)
2. What’s the main advantage of CoAP? - Lightweight (4-byte header), uses UDP, perfect for constrained devices
3. CoAP vs. MQTT: when to use each? - CoAP for request-response (like HTTP); MQTT for publish-subscribe (event streams)
4. What are the two main message types? - CON (confirmable, reliable) and NON (non-confirmable, fast but unreliable)

1220.9 Summary

CoAP provides a lightweight RESTful protocol optimized for constrained IoT devices:

• UDP-based: Lower overhead than TCP-based HTTP
• RESTful: Familiar GET/POST/PUT/DELETE methods
• Compact: 4-byte header vs HTTP’s hundreds of bytes
• Flexible reliability: Choose between CON (reliable) and NON (fast)

CoAP lets your 8-bit microcontroller with 2KB RAM expose web-style APIs, enabling direct integration with cloud services without HTTP’s overhead.

1220.10 What’s Next

Now that you understand why CoAP exists and how it compares to HTTP and MQTT:

• Message Format Details: CoAP Message Format - Learn the binary header structure, options encoding, and response codes
• Reliability Patterns: CoAP Message Types - Master CON vs NON message selection and retransmission behavior
• See All CoAP Topics: CoAP Fundamentals and Architecture - Complete chapter index