44  CoAP Methods & Multicast

44.1 Learning Objectives

  • Apply CoAP REST methods (GET, POST, PUT, DELETE) with proper idempotency semantics for IoT resource manipulation
  • Implement CoAP servers and clients using Python (aiocoap) and Arduino (ESP32) for sensor data exchange
  • Configure CoAP multicast addressing for group operations and network-wide resource discovery via /.well-known/core
  • Demonstrate how the CoAP Observe extension enables server-push notifications, reducing energy consumption by up to 99% compared to polling
  • Compare CoAP’s 4-byte header efficiency versus HTTP’s 100+ byte overhead for battery-powered IoT devices
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

44.2 In 60 Seconds

CoAP supports four REST methods mirroring HTTP: GET (retrieve), POST (create), PUT (update/create), and DELETE (remove), with GET, PUT, and DELETE being idempotent. Beyond basic REST, CoAP adds multicast support for group operations (e.g., turning off all lights), resource discovery via /.well-known/core, and the Observe extension that enables server-push notifications – reducing energy consumption by up to 99% compared to polling.

Think about how you communicate with friends. You might send a long email with lots of details, or you might send a quick text message with just the essential information. Both get the message across, but text messages are faster and use less data especially important when you have limited battery or a slow connection.

CoAP is like the text message version of web communication for IoT devices. Regular websites use HTTP, which is like sending detailed emails with lots of extra information in headers and metadata. That works great for powerful computers and smartphones with strong batteries and fast internet. But tiny sensors running on coin batteries can’t afford that luxury. CoAP strips away all the unnecessary extras and keeps just the essential parts: what you want to do, which resource you’re accessing, and the actual data.

The magic is that CoAP still works like the web you know. You can GET data from a sensor, PUT a new setting to a device, or POST a command just like with regular websites. But instead of using hundreds of bytes of overhead like HTTP, CoAP uses just 4 bytes for its header. This means a temperature sensor can report readings for years on a single battery instead of months, and devices can communicate even over slow, unreliable networks where every byte matters.

“CoAP has four magic words that do everything!” announced Max the Microcontroller. “GET means ‘tell me your value.’ PUT means ‘change your setting to this.’ POST means ‘do this action.’ And DELETE means ‘remove this thing.’”

Sammy the Sensor demonstrated: “When the dashboard sends me a GET, I reply with my temperature. When someone sends a PUT to change my sampling rate from 10 to 30 seconds, I update my setting and confirm. It’s just like asking and answering questions!”

“And multicast is the coolest feature!” added Lila the LED. “Instead of asking each sensor one by one – ‘Sammy, what’s your temperature? Bella, what’s your voltage?’ – you shout to ALL sensors at once: ‘Everyone, report your temperature!’ One message, fifty replies. Imagine how much time and energy that saves in a building with hundreds of sensors!”

Bella the Battery loved that. “One multicast GET instead of fifty individual GETs means I save 98% of my radio energy for discovery. It’s like a teacher taking attendance by saying ‘raise your hand if you’re here’ instead of calling each name individually!”

44.3 CoAP Methods

Like HTTP, CoAP uses REST methods:

Method Purpose HTTP Equivalent Idempotent
GET Retrieve resource GET Yes
POST Create resource POST No
PUT Update/Create PUT Yes
DELETE Remove resource DELETE Yes

44.3.1 Examples

GET: Retrieve temperature

coap://sensor.local/temperature

POST: Add new sensor reading

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

PUT: Update configuration

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

DELETE: Remove old data

coap://server.local/readings/old

44.4 💻 Code Examples

44.4.1 Python CoAP Server

import asyncio
from aiocoap import *

class TemperatureResource(resource.Resource):
    """Example resource for temperature readings"""

    async def render_get(self, request):
        """Handle GET requests"""
        temperature = 22.5  # Simulated sensor reading

        payload = f"{temperature}".encode('utf-8')

        return Message(
            code=Code.CONTENT,
            payload=payload,
            content_format=0  # text/plain
        )

    async def render_put(self, request):
        """Handle PUT requests to update config"""
        print(f'Received: {request.payload}')

        return Message(code=Code.CHANGED)

async def main():
    # Create CoAP server
    root = resource.Site()

    # Add temperature resource
    root.add_resource(
        ['temperature'],
        TemperatureResource()
    )

    # Start server
    await Context.create_server_context(root)

    print("CoAP server started on port 5683")
    await asyncio.get_running_loop().create_future()

if __name__ == "__main__":
    asyncio.run(main())

Install: pip install aiocoap

44.4.2 Python CoAP Client

import asyncio
from aiocoap import *

async def get_temperature():
    """Fetch temperature from CoAP server"""

    # Create CoAP client protocol
    protocol = await Context.create_client_context()

    # Build GET request
    request = Message(
        code=Code.GET,
        uri='coap://localhost/temperature'
    )

    try:
        # Send request
        response = await protocol.request(request).response

        print(f'Response Code: {response.code}')
        print(f'Temperature: {response.payload.decode("utf-8")}°C')

    except Exception as e:
        print(f'Failed to fetch: {e}')

async def update_config():
    """Send PUT request to update configuration"""

    protocol = await Context.create_client_context()

    request = Message(
        code=Code.PUT,
        uri='coap://localhost/config',
        payload=b'{"interval": 30}'
    )

    response = await protocol.request(request).response
    print(f'Update result: {response.code}')

# Run client
asyncio.run(get_temperature())

44.4.3 Arduino ESP32 CoAP Client

#include <WiFi.h>
#include <coap-simple.h>

// WiFi credentials
const char* ssid = "YourWiFi";
const char* password = "YourPassword";

// CoAP client
Coap coap;

// CoAP server details
IPAddress serverIP(192, 168, 1, 100);
int serverPort = 5683;

void callback_response(CoapPacket &packet, IPAddress ip, int port) {
  char payload[packet.payloadlen + 1];
  memcpy(payload, packet.payload, packet.payloadlen);
  payload[packet.payloadlen] = NULL;

  Serial.print("CoAP Response: ");
  Serial.println(payload);
}

void setup() {
  Serial.begin(115200);

  // Connect to WiFi
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("\nWiFi connected");

  // Start CoAP
  coap.response(callback_response);
  coap.start();
}

void loop() {
  // Send GET request every 10 seconds
  int msgid = coap.get(serverIP, serverPort, "temperature");

  Serial.print("Request sent, MID: ");
  Serial.println(msgid);

  delay(10000);

  coap.loop();
}

44.5 📊 Interactive Comparison: CoAP vs MQTT vs HTTP

Key Insights

CoAP Advantages:

  • ✅ Smallest header size (4 bytes) - minimal overhead
  • ✅ Best battery life (UDP, no connection overhead)
  • ✅ RESTful design - familiar to web developers
  • ✅ Low latency - simple request/response

When CoAP Wins:

  • Resource-constrained devices (8-bit microcontrollers)
  • Battery-powered sensors (years not months)
  • Intermittent connectivity (devices sleep often)
  • Integration with web infrastructure (HTTP proxies)

When to Choose Alternatives:

  • MQTT: Publish-subscribe needed, TCP reliability required
  • HTTP: Full web stack needed, rich tooling ecosystem

44.6 💻 Interactive Tool: CoAP Message Size Calculator

Calculate the actual bytes sent over the network for different protocols:

Message Size Optimization

For small payloads (< 100 bytes), protocol overhead dominates. Try adjusting the payload size above to see how CoAP’s efficiency scales.

Recommendation: For sensors sending small readings frequently, CoAP’s low overhead translates to: - 📉 Reduced network congestion - 🔋 Longer battery life (less radio time) - ⚡ Lower latency (smaller packets = faster transmission)

44.7 🔋 Battery Life Calculator: CON vs NON Messages

Critical Battery Life Insights

NON vs CON Performance:

  • NON messages skip acknowledgment, saving approximately 21% energy per transaction (45 bytes vs 57 bytes for CON + ACK round-trip)
  • CON messages require an ACK response, adding 12 bytes of overhead and an additional receive window — increasing per-message energy by ~27% compared to NON
  • For sensors with reliable links, NON can extend battery life by years
  • Use CON only when guaranteed delivery is critical
🎮 Interactive Simulator: CoAP-Style UDP Communication

What This Simulates: ESP32 demonstrating CoAP’s lightweight UDP request/response pattern

CoAP Communication Pattern:

CoAP UDP request/response

CoAP UDP pattern
Figure 44.1: CoAP request/response communication pattern showing lightweight UDP exchange between ESP32 client and server with minimal 4-byte header overhead.

How to Use:

  1. Click ▶️ Start Simulation
  2. Watch Serial Monitor show UDP request/response cycle
  3. Observe message types (CON, NON, ACK)
  4. See CoAP-style resource addressing
  5. Monitor round-trip times (RTT)

💡 Learning Points

What You’ll Observe:

  1. UDP Transport - Connectionless, lightweight communication
  2. 4-Byte Headers - Minimal overhead compared to HTTP
  3. Request/Response - RESTful pattern like HTTP GET
  4. Message IDs - Tracking requests and responses
  5. No Handshake - Direct communication without TCP overhead

CoAP Message Structure (Simplified):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T |  TKL  |      Code     |          Message ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ver = Version (2 bits)
T   = Type (CON, NON, ACK, RST)
TKL = Token Length
Code = Method (GET) or Response (2.05 Content)

Real-World Applications:

  1. Smart Home - Light bulbs responding to GET/PUT requests
  2. Industrial IoT - Sensors publishing data via RESTful interface
  3. Building Automation - HVAC systems with RESTful control
  4. Energy Management - Smart meters with resource discovery
  5. Wearables - Health sensors with minimal power consumption

Experiments to Try:

  1. Change Request Frequency - Modify delay() to see network load
  2. Add More Resources - Simulate /humidity, /pressure endpoints
  3. Implement Observe - Add subscription pattern (like MQTT subscribe)
  4. Calculate Overhead - Compare 4-byte CoAP vs HTTP headers
  5. Test Reliability - Implement CON (confirmable) message handling

CoAP vs HTTP Power Consumption:

HTTP Request:  ~500 bytes (headers + TCP)
CoAP Request:  ~20 bytes (4-byte header + minimal payload)
Power Savings: ~96% less data transmitted

44.8 Multicast Support

CoAP supports multicast for group communication:

44.8.1 IPv4 Multicast

224.0.1.187

44.8.2 IPv6 Multicast

FF0X::FD

Use cases:

  • Discover devices on network
  • Broadcast commands to group
  • Query multiple sensors simultaneously

Example:

coap://[FF05::FD]/temperature

Sends GET request to all devices in multicast group.

44.8.3 📊 Multicast Efficiency Calculator

44.9 CoAP Features

Key Features
  1. Reduced Overhead: 4-byte header vs 100+ bytes in HTTP
  2. URI Support: Resource addressing like HTTP
  3. Content-Type: Supports JSON, XML, CBOR, etc.
  4. Resource Discovery: Automatic service discovery (/.well-known/core)
  5. Observe Pattern: Subscribe to resources, receive push notifications
  6. Simple Caching: Based on maximum message age
  7. Block-wise Transfer: For large payloads
  8. Security: DTLS encryption

44.9.1 Resource Discovery

Query available resources:

GET coap://device.local/.well-known/core

Response:

</temperature>;ct=0,
</humidity>;ct=0,
</pressure>;ct=0,
</config>;ct=50
🎮 Interactive Simulator: CoAP Resource Discovery

What This Simulates: ESP32 CoAP server with automatic resource discovery via /.well-known/core

Resource Discovery Flow:

Step 1: Client queries server
   GET coap://device/.well-known/core

Step 2: Server responds with resource list
   </temperature>;rt="sensor";if="core.s",
   </humidity>;rt="sensor";if="core.s",
   </led>;rt="actuator";if="core.a"

Step 3: Client accesses specific resource
   GET coap://device/temperature
   Response: "23.5"

How to Use:

  1. Click ▶️ Start Simulation
  2. Watch ESP32 advertise available resources
  3. See resource metadata (resource type, interface)
  4. Observe clients discovering services automatically
  5. Monitor GET requests to discovered resources

💡 Learning Points

What You’ll Observe:

  1. Automatic Discovery - Devices announce capabilities without manual configuration
  2. Standard Endpoint - /.well-known/core is CoAP convention (RFC 6690)
  3. Resource Attributes - Metadata describes resource type and interface
  4. Self-Describing - Servers advertise what they offer
  5. Plug-and-Play - New devices integrate without central registry

Resource Link Format:

</path>;attribute1=value1;attribute2=value2

Common Attributes:
rt = Resource Type (e.g., "temperature-sensor")
if = Interface Description (e.g., "sensor", "actuator")
ct = Content Type (0=text/plain, 50=application/json)
sz = Maximum Size
obs = Observable (supports observe pattern)

Example Resource Advertisement:

CoAP resource link format

CoAP resource format
Figure 44.2: CoAP resource link format showing the structure of a resource advertisement with path, resource type, interface description, observability, and content type attributes.

Real-World Applications:

  1. Smart Building - HVAC units discover sensors automatically
  2. Industrial IoT - Factory machines advertise capabilities
  3. Home Automation - New devices self-register with hub
  4. Healthcare - Medical sensors announce monitoring types
  5. Agriculture - Soil sensors advertise measurement types

Experiments to Try:

  1. Add New Resources - Implement /pressure, /battery endpoints
  2. Resource Attributes - Add obs for observable resources
  3. Content Types - Support JSON (ct=50) and XML (ct=41)
  4. Filtering - Query specific resource types: ?rt=sensor
  5. Observe Pattern - Implement push notifications when resource changes

Discovery vs Hardcoding:

Without Discovery (Hardcoded):
- Client: GET coap://192.168.1.100/temp  ❌ Must know IP & path
- Brittle: Breaks if device IP changes

With Discovery:
- Client: Multicast GET /.well-known/core  ✅ Finds all devices
- Response: Server at 192.168.1.100 offers /temp
- Robust: Adapts to network changes

CoAP Resource Discovery Benefits:

  • Zero configuration networking
  • Dynamic topology adaptation
  • Service versioning support
  • Reduces integration time by ~80%

Knowledge Check: Match and Sequence

Match each CoAP concept to its correct definition or use case:

Arrange the following steps of a CoAP resource discovery and subscription workflow in the correct order:

44.10 Protocol Comparison

44.10.1 CoAP vs HTTP: Concrete Performance Numbers

Feature CoAP HTTP CoAP Advantage
Transport UDP TCP No handshake overhead
Header Size 4 bytes 100-200 bytes 96% reduction
Total On-Wire Size 40-60 bytes 250-600 bytes 85-93% smaller
Connection Setup None (UDP) 3-way handshake Saves 1+ RTT + ~180 bytes
Methods GET, POST, PUT, DELETE Same + more Focused on IoT needs
Discovery Built-in (/.well-known/core) No standard Zero-config networking
Multicast Yes (FF0X::FD) No One-to-many efficiency
Observe Yes (push notifications) Server-Sent Events 99% less polling traffic
Security DTLS TLS UDP-optimized
Power per Message 3-5 mJ 30-50 mJ 10x more efficient
Battery Life Impact 2-5 years 2-6 months 10x longer life

Real Numbers Example - Temperature Reading:

Scenario: Send “22.5C” (5 bytes payload) from sensor to server

Bar chart comparing CoAP and HTTP total message sizes and energy consumption for a small sensor reading, illustrating CoAP's efficiency advantage for battery-powered IoT devices
Figure 44.3: CoAP versus HTTP comparison for a temperature reading showing significantly lower bandwidth and energy usage for CoAP due to its 4-byte header versus HTTP’s verbose header format

Total message overhead directly affects both bandwidth and battery life. For payload \(P\) bytes:

\[B_{\text{total}} = H_{\text{protocol}} + H_{\text{transport}} + P\]

CoAP message: \(B_c = 4\text{ (header)} + 8\text{ (token+options)} + 28\text{ (UDP/IP)} + 5\text{ (payload)} = 45\) bytes

HTTP message: \(B_h = 200\text{ (headers)} + 40\text{ (TCP/IP)} + 5\text{ (payload)} + 180\text{ (handshake)} = 425\) bytes

For 1,000 daily readings at 3V, 200mA peak transmit current (typical for an ESP32 Wi-Fi radio), 250kbps effective link rate: \[E_c = 1000 \times \frac{45 \times 8}{250,000} \times 0.2\text{A} \times 3\text{V} = 0.86\text{ J/day}\]

\[E_h = 1000 \times \frac{425 \times 8}{250,000} \times 0.2\text{A} \times 3\text{V} = 8.16\text{ J/day}\]

With CR2032 battery (675 mWh = 2,430 J): CoAP enables 7.7 years vs HTTP’s 0.8 years of TX-only battery life. The 9.4× overhead ratio translates directly to a 9.4× difference in radio energy per day. Note: real-world battery life will be shorter due to sleep/idle current, MCU processing, and other loads; this model isolates the protocol overhead contribution.

44.10.2 CoAP vs MQTT

Feature CoAP MQTT
Pattern Request/Response Publish/Subscribe
Transport UDP TCP
Discovery Built-in External
QoS Via message type 3 levels (0,1,2)
Broker Optional Required
Best For RESTful IoT Event-driven IoT
Protocol selection tree
Figure 44.4: IoT Protocol Selection Decision Tree: CoAP, MQTT, or HTTP