43  CoAP Messages & Exchanges

In 60 Seconds

CoAP defines four message types: Confirmable (CON) requires acknowledgment for reliable delivery of critical commands, Non-Confirmable (NON) provides fire-and-forget efficiency for frequent sensor readings, Acknowledgment (ACK) confirms CON receipt and can piggyback the response payload, and Reset (RST) indicates the receiver cannot process the message. The CON vs NON choice directly trades reliability for energy – CON costs up to 16x the energy of NON (due to ACK wait and RX radio time) but achieves 99.99% delivery.

43.1 Learning Objectives

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

  • Distinguish the four CoAP message types (CON, NON, ACK, RST) and their roles in the protocol
  • Select the appropriate message type based on reliability requirements and battery constraints
  • Explain piggyback vs separate response patterns and when each is used
  • Calculate the energy trade-off between CON and NON messages for battery-powered devices
  • 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

43.2 For Beginners: CoAP Message Types

CoAP uses four message types: Confirmable (requires acknowledgment), Non-confirmable (fire-and-forget), Acknowledgment (confirmation receipt), and Reset (error signal). Think of it like different ways to send a message – sometimes you need a read receipt, sometimes you just want to shout the news without waiting for a reply.

“I have four different ways to send my readings?” asked Sammy the Sensor, confused.

“Think of it like four types of mail!” said Max the Microcontroller. “Confirmable (CON) is like certified mail – you send it and wait for a signed receipt. If you don’t get one, you send it again. Perfect for important alerts like ‘the freezer door is open!’”

Lila the LED continued: “Non-confirmable (NON) is like dropping a flyer in someone’s mailbox – you don’t wait to see if they read it. Great for routine updates like ‘living room light is still on.’ If one update gets lost, another is coming in 10 seconds anyway.”

“Then there’s the Acknowledgment (ACK),” said Bella the Battery. “That’s the signed receipt itself – you’re saying ‘yep, I got your message!’ And Reset (RST) is like returning a letter stamped ‘wrong address’ – it means ‘I don’t understand what you’re asking for.’ Four simple types cover every situation, and they keep the protocol tiny!”

43.3 CoAP Message Types

Four message types provide flexibility for different scenarios:

43.3.1 Confirmable (CON)

Reliable transmission - requires acknowledgment:

Sequence diagram showing CoAP client sending CON request with Message ID to server, server responding with ACK containing same Message ID and response payload, demonstrating reliable delivery with acknowledgment
Figure 43.1: CoAP Confirmable Message Exchange with Acknowledgment

Use when:

  • Critical data must arrive
  • Commands that trigger actions
  • Resource updates (PUT, POST, DELETE)

43.3.2 Non-Confirmable (NON)

Unreliable transmission - no acknowledgment:

Sequence diagram showing CoAP client sending NON request to server with no acknowledgment response, illustrating fire-and-forget pattern for frequent sensor readings where occasional loss is acceptable
Figure 43.2: CoAP Non-Confirmable Fire-and-Forget Message Exchange

Use when:

  • Frequent sensor readings
  • Data loss acceptable
  • Minimizing network traffic
  • Battery conservation critical

CON vs NON: The Battery Life Trade-off

Choosing between Confirmable (CON) and Non-Confirmable (NON) messages dramatically impacts battery life:

CON (Confirmable):

  • Waits for ACK response (50-200ms typical)
  • Retransmits if no ACK (exponential backoff)
  • Radio stays on longer → drains battery
  • Use for: Critical commands, infrequent updates

NON (Non-Confirmable):

  • Fire-and-forget, no waiting
  • Radio on for <10ms
  • 5-10x better battery life than CON
  • Use for: Frequent sensor readings where occasional loss is acceptable

Example: Temperature sensor sending readings every 60 seconds - battery lasts 2 years with NON vs 3 months with CON. For battery-powered devices, default to NON and use CON only when absolutely necessary.

Side-by-side comparison diagram of CON and NON message patterns showing CON with acknowledgment wait time and retransmission capability versus NON with immediate transmission and no acknowledgment, illustrating the energy consumption trade-off
Figure 43.3: Alternative view: CoAP message type comparison showing the flow and resource usage differences between Confirmable (CON) and Non-Confirmable (NON) messages. CON provides reliability through retransmission but consumes 5-10x more battery, while NON offers fire-and-forget efficiency suitable for frequent sensor readings.

43.3.3 Worked Example: CON vs NON Energy Budget for Cold Chain Monitoring

Scenario: A pharmaceutical warehouse uses 200 CoAP sensors monitoring freezer temperatures. Each sensor sends a 20-byte reading every 30 seconds. Sensors use 802.15.4 radios (250 Kbps) with 8 mA TX, 5 mA RX current at 3.0V. Battery: 1,000 mAh CR123A.

NON message energy per transmission:

  • TX: 20-byte payload + 4-byte CoAP header + 8-byte UDP + 20-byte IPv6 = 52 bytes
  • TX time: 52 x 8 / 250,000 = 1.66 ms at 8 mA = 0.013 mAs
  • Radio startup: ~0.5 ms at 8 mA = 0.004 mAs
  • Total per NON: 0.017 mAs

The total energy per transmission depends on time-on-air and current draw:

\[ E_{\text{total}} = E_{\text{TX}} + E_{\text{RX}} + E_{\text{startup}} \]

For NON messages (no ACK wait): \[ E_{\text{NON}} = I_{\text{TX}} \cdot t_{\text{TX}} + I_{\text{startup}} \cdot t_{\text{startup}} \]

For CON messages (with ACK wait): \[ E_{\text{CON}} = E_{\text{NON}} + I_{\text{RX}} \cdot t_{\text{ACK\_wait}} + I_{\text{RX}} \cdot t_{\text{ACK\_RX}} \]

Where \(I_{\text{TX}} = 8\text{ mA}\), \(I_{\text{RX}} = 5\text{ mA}\) at \(V = 3.0\text{ V}\) for 802.15.4.

The energy ratio: \[ \frac{E_{\text{CON}}}{E_{\text{NON}}} = \frac{0.272}{0.017} \approx 16\times \]

This 16× multiplier directly translates to battery life reduction when switching from NON to CON for frequent sensor readings.

CON message energy per transmission:

  • TX same as NON: 0.017 mAs
  • Wait for ACK: radio in RX mode ~50 ms at 5 mA = 0.25 mAs (typical RTT on local network)
  • ACK reception: 4-byte header + 8 UDP + 20 IPv6 = 32 bytes at 5 mA = 0.005 mAs
  • Total per CON: 0.272 mAs (16x more than NON)

Battery lifetime comparison:

Metric NON CON
Energy per message 0.017 mAs 0.272 mAs
Messages per day 2,880 2,880
Daily consumption 49 mAs = 0.0136 mAh 784 mAs = 0.218 mAh
Battery lifetime 1,000 / 0.0136 = 73,529 days 1,000 / 0.218 = 4,587 days
Practical lifetime (with sleep current) ~8 years ~5 years

But what about reliability? With 5% packet loss on 802.15.4:

  • NON: 5% of readings lost = 144 per day (but next reading arrives in 30 seconds)
  • CON: 0.0025% loss after retransmission (5% x 5% = 0.25% after one retry)

Decision: Use NON for routine 30-second temperature readings (any loss is replaced in 30 seconds). Use CON only for threshold alerts (“Temperature exceeded -18C”) which happen rarely (~2 per day). This hybrid approach achieves ~8-year battery life while guaranteeing critical alerts are delivered.

43.4 Interactive: CoAP Message Energy Calculator

Explore how message type, transmission frequency, and network parameters affect battery life:

43.4.1 Acknowledgment (ACK)

Confirms receipt of confirmable message:

  • May include response (piggyback)
  • Or just acknowledgment (response comes separately)

43.4.2 Reset (RST)

Rejects invalid message:

  • Unknown message ID
  • Message cannot be processed
  • Server unavailable

43.5 Message Exchange Patterns

43.6 Videos

Application Protocols Overview (from slides)
Application Protocols Overview
From Lesson 4 — placing CoAP among MQTT/HTTP/AMQP; REST patterns and trade-offs.
Protocols and REST in Practice
Protocols and REST in Practice
From Lesson 4 — practical layering and REST interactions relevant to CoAP.

43.6.1 Piggyback Response

Server responds immediately within ACK:

Sequence diagram showing CoAP client sending CON request and server immediately responding with ACK containing both acknowledgment and response payload in a single message, demonstrating efficient single round-trip communication
Figure 43.4: CoAP Piggyback Response: Response Included in ACK Message

Advantage: Single round-trip, efficient

43.6.2 Separate Response

Server needs time to process:

Sequence diagram showing CoAP client sending CON request, server immediately responding with empty ACK to stop retransmission, then later sending a separate CON message with the actual response payload, demonstrating two round-trip pattern for long-running operations
Figure 43.5: CoAP Separate Response: Empty ACK Followed by Delayed Response

Use when: Long processing time required

43.7 Interactive: CoAP Retransmission Timeline

Visualize how CoAP’s exponential backoff algorithm affects retransmission timing and battery life:

Quick Review: Match & Sequence

Test your recall before the detailed knowledge checks below.

Knowledge Check: CoAP Message Types & Patterns Test Your Understanding

43.8 Knowledge Check

Test your understanding of CoAP message types and communication patterns.