6 CoAP Message Exchanges

coap

message

types

In 60 Seconds

6.0.1 Match the Envelope to the Consequence

The Constrained Application Protocol (CoAP) is a protocol for small devices and limited links. A protocol is an agreed set of exchange rules. A payload is the useful content carried inside a message.

Picture a freezer sensor sending a routine reading and a door alarm. The next reading can replace a lost routine update. The alarm needs a clear receipt or a safe fallback. Treating both messages alike either wastes battery or leaves the urgent event without proof.

Write the consequence first. Decide whether the sender must know that the receiver got the message. Then test a lost message, a late reply, a duplicate, and a receiver that has restarted. Record what the sender does after each result and when the application may act.

An acknowledgement proves only that a named message reached a message-handling boundary. It does not prove that the reading was true or that the physical action happened. The deeper sections explain the four message types, their timing, and the cost of each exchange.

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.

6.1 Start With the Delivery Choice

Picture one device sending two updates: a freezer-door alarm and a routine temperature sample. The alarm needs proof that someone received it; the sample may be replaced by the next reading in a few seconds. CoAP gives those two messages different envelopes instead of forcing one rule onto both.

Read CON, NON, ACK, and RST as delivery decisions. The rest of the chapter explains what each decision costs in delay, radio time, battery, and failure handling.

Phoebe’s Field Notes: The Microamps Behind This Chapter’s “~8 Years”

Phoebe’s Field Notes: The Sleep Current Hidden Behind CON and NON

The mathematical gist. NON uses 0.0136 mAh/day of active charge and CON uses 0.218 mAh/day, but practical lifetime must add the always-on current: $Q_{day}=Q_{active}+24I_{sleep}/1000$ . With about 13.75 µA asleep, the chapter’s 1000 mAh cell lasts about 8.0 years on NON and 5.0 years on CON. The separate 8 mA transmit pulse through 0.5 ohm sags only 4.0 mV, so the charge comparison is plausible for this fresh-cell case.

6.2 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

Chapter Roadmap

Use this path through the protocol:

First choose CON or NON by asking whether the next reading can replace this one.
Then price that choice with 20-byte readings, 52-byte packets, 50 ms ACK waits, and the 16x energy ratio.
Next separate ACK/RST protocol signals from application errors.
Finally compare piggyback, separate response, retransmission, and quiz scenarios.

Checkpoints recap the decision rules. Calculation audits and simulators are deeper support, optional on a first pass.

Key Concepts

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

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

6.3 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.

Four Ways to Send a Message

“I have four different ways to send my readings?” asked Temperature Terry, confused.

“Think of it like four types of mail!” said 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!’”

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 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!”

6.4 Continue: CoAP Message Reliability and Exchange Contracts

The main chapter below stays focused on CoAP message types, energy tradeoffs, and exchange patterns. For the deeper contract behind CON/NON/ACK/RST layering, named timers, ACK timeout/backoff, Message ID versus Token roles, piggybacked versus separate responses, duplicate suppression, and reset handling, continue to CoAP Message Reliability and Exchange Contracts.

6.5 CoAP Message Types

The first message-type decision is consequence: if loss changes system state, start with CON; if the next sample replaces this one, start with NON. Inspect Figure 6.1 to place ACK and RST around that sender choice.

Comparison diagram for CoAP message types: CON carries critical alerts and commands while waiting for ACK and retransmitting on timeout, NON carries frequent readings without an acknowledgment, ACK confirms a valid CON with the same Message ID and may piggyback a response payload, and RST rejects unexpected or invalid protocol state rather than ordinary missing resources. — Figure 6.1: CoAP message type comparison showing CON and NON as client delivery choices, ACK as the matching response to a valid CON, and RST as the reset signal for unexpected or unprocessable protocol messages.

Read Figure 6.1 from the two sending choices into their outcomes. CON starts a reliability exchange and waits for a matching ACK, while NON spends no acknowledgment traffic and accepts possible loss. ACK is therefore a response type, not a competing delivery policy, and RST reports that a message reached a receiver that could not process its protocol state. The next two sections trace the sender branches separately.

6.5.1 Confirmable (CON)

Reliable transmission - requires acknowledgment:

Use when:

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

To see what “requires acknowledgment” means on the wire, trace one request through Figure 6.2. Keep the Message ID distinct from the Token while following the normal and timeout paths.

Sequence diagram for CoAP confirmable delivery: the client sends CON GET slash temperature with Message ID 0x1234 and Token T7, starts ACK_TIMEOUT, the server replies with ACK 2.05 Content using the same Message ID, and if no ACK arrives the client retransmits the same CON with exponential backoff up to MAX_RETRANSMIT. — Figure 6.2: CoAP confirmable exchange showing a CON request with Message ID and Token, a matching ACK response, and the retransmission path when ACK_TIMEOUT expires.

In Figure 6.2, begin with the CON GET and its Message ID 0x1234; the timer starts as that datagram leaves. A matching ACK stops retransmission, and the Token T7 associates returned content with the request. If the ACK is absent, the client retransmits the same CON with backoff rather than inventing a new operation. That extra exchange buys bounded delivery effort for the critical cases above.

6.5.2 Non-Confirmable (NON)

Unreliable transmission - no acknowledgment:

Use when:

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

When a newer reading makes an older one disposable, Figure 6.3 shows the smaller contract. Look for the deliberate absence of both an ACK timer and a retransmission loop.

Sequence diagram for CoAP non-confirmable delivery: the client sends a NON POST slash status datagram with Message ID 0x44A1, does not start an ACK timeout or retransmission loop, the server returns no protocol acknowledgment, and the next NON reading can replace a lost telemetry sample. — Figure 6.3: CoAP non-confirmable exchange showing a client sending replaceable telemetry without an ACK wait, a server processing the datagram only if it arrives, and the next NON reading superseding a lost sample.

Follow Figure 6.3 from the status datagram to the server. If it arrives, the server processes it; if it disappears, neither endpoint opens a reliability exchange, and the next reading becomes the current state. NON reduces traffic because it removes recovery, not because UDP somehow became reliable. That is suitable for replaceable telemetry, but not for a one-off alarm or actuator command.

CON vs NON: The Battery Life Trade-off

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

CON (Confirmable):

Read these points as one connected sequence: start with Waits for ACK response (50-200 ms typical); then Retransmits if no ACK (exponential backoff); then Radio stays on longer → drains battery; and finish with Use for: Critical commands, infrequent updates.

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

NON (Non-Confirmable):

Read these points as one connected sequence: start with Fire-and-forget, no waiting; then Radio on for <10 ms; then 5-10x better battery life than CON; and finish with Use for: Frequent sensor readings where occasional loss is acceptable.

Fire-and-forget, no waiting
Radio on for <10 ms
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.

Checkpoint: CON or NON

CON fits critical data, action-triggering commands, and resource updates such as PUT, POST, and DELETE.
NON fits frequent sensor readings where loss is acceptable and battery conservation is critical.
A 60-second temperature sensor example estimates 2 years with NON versus 3 months with CON.

6.5.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

Putting Numbers to It: Energy Cost Formula for CON vs NON

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.

6.6 ACK Wait Energy Calculation Audit

At 5% packet loss on 802.15.4, NON loses about 144 readings per day but the next one arrives in 30 seconds; CON’s retransmission drops that to about 0.25% after one retry. Decision: use NON for routine 30-second temperature readings (any loss is replaced in 30 seconds), and reserve CON for rare threshold alerts (~2 per day) such as “Temperature exceeded -18C”. This hybrid approach keeps roughly NON’s ~8-year battery life while still guaranteeing critical alerts are delivered.

Checkpoint: Energy Budget

The cold-chain packet is 52 bytes: 20 payload + 4 CoAP + 8 UDP + 20 IPv6.
At 250 Kbps, it takes 1.66 ms to transmit; with startup, NON costs 0.017 mAs.
CON adds the 50 ms ACK wait and 32-byte ACK receive, reaching 0.272 mAs, about 16x NON.

6.7 Interactive: CoAP Message Energy Calculator

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

6.7.1 Acknowledgment (ACK)

ACKs cost power, but their meaning is narrow: they confirm CON receipt. Application success still depends on the response code they carry.

Confirms receipt of confirmable message:

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

6.7.2 Reset (RST)

RST is a message-layer rejection, not an application error shortcut. Send it when a datagram is syntactically recognisable but the endpoint lacks the exchange context needed to process it—for example, a rebooted node receives a confirmable Observe notification it no longer recognises. An unknown Message ID or an empty CON ping can therefore produce RST. A valid GET for a missing resource instead deserves ACK with 4.04 Not Found, and temporary server unavailability belongs in a 5.03 response; those application outcomes must not be collapsed into reset.

Checkpoint: ACK and RST Semantics

ACK confirms a valid CON and can piggyback a normal response such as 4.04 Not Found.
RST rejects invalid, unexpected, or unprocessable protocol messages; it is not for ordinary missing resources.
Ignoring CON causes client retries up to MAX_RETRANSMIT.

6.8 Message Exchange Patterns

After ACK and RST, choose response timing. Fast work can ride inside ACK; slow work needs an empty ACK first.

6.8.1 Piggyback Response

When the representation is already available, the server can combine transport acknowledgment and application response. Figure 6.4 shows how one packet performs both jobs without confusing their identifiers.

Sequence diagram for a CoAP piggyback response: the client sends a CON GET slash temp request with Message ID 0x44A2 and Token T9, the server has the temperature value ready, and it replies with ACK 2.05 Content using the same Message ID while the original token matches the payload to the request. — Figure 6.4: CoAP piggyback response showing a confirmable GET request and an ACK that both stops retransmission and carries a 2.05 Content payload.

Read Figure 6.4 as a single round trip. The ACK repeats Message ID 0x44A2, which stops retransmission of that CON, while Token T9 tells the client which request owns the 2.05 Content payload. Piggybacking is efficient because the response was ready inside the acknowledgment window; it is not a promise that every server operation completes that quickly.

6.8.2 Separate Response

If producing the representation takes longer than the acknowledgment window, the two jobs must separate. Inspect the sequence diagram in Figure 6.5 to trace that split for an eight-second diagnostic operation.

Sequence diagram for a CoAP separate response: the gateway sends a CON GET diagnostics request with Message ID 0x6A10 and Token T7, the sensor sends an empty ACK with the same Message ID before timeout, spends about eight seconds collecting diagnostics, sends a new CON response with Message ID 0x72C4 and the original Token T7, and the gateway acknowledges that response. — Figure 6.5: CoAP separate response showing an industrial gateway request, immediate empty ACK, delayed diagnostic work, separate CON response using the original token, and final ACK.

Reading the sequence diagram in Figure 6.5 from top to bottom, the empty ACK first repeats Message ID 0x6A10 and stops request retransmissions without pretending the result is ready. After the diagnostic work, the sensor sends a new CON with a new Message ID but the original Token T7; that token reconnects the delayed payload to the request. The gateway then acknowledges the response’s Message ID, completing two messaging exchanges around one request-response operation.

6.9 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.

Checkpoint: Exchange Patterns

Piggyback response finishes a fast CON request in one round trip by carrying payload inside ACK.
Separate response sends an empty ACK first, then later returns payload as a new CON for slower work such as an 8-second diagnostic report.
Retransmission starts after ACK_TIMEOUT and uses exponential backoff plus ACK_RANDOM_FACTOR jitter.

6.10 Videos

The first case shows an IoT decision platform in a deployed farming context. Use it to identify where constrained field devices hand observations to a higher-level application; the video is context for the boundary, not a CoAP protocol demonstration.

The second video explains MQTT. Compare its brokered publish/subscribe model with the request/response and message-type behavior developed in this chapter; it is a comparison point rather than a lesson on CoAP REST exchanges.

6.11 Knowledge Check

Test your understanding of CoAP message types and communication patterns.

Label the Diagram

Code Challenge

6.12 See Also

Read these points as one connected sequence: start with CoAP Fundamentals and Architecture: Review where message types fit in the client/server architecture; then CoAP Message Reliability and Exchange Contracts: Go deeper on CON/NON/ACK/RST layering, named retransmission timers, Message ID versus Token roles, and duplicate handling; then CoAP Methods and Features: Connect CON, NON, ACK, and RST behavior to GET, POST, PUT, DELETE, and resource discovery; then CoAP Observe Extension: See how notifications use confirmable and non-confirmable messages over time; and finish with CoAP Security Applications: Relate message handling to DTLS, OSCORE, and constrained-device security choices.

CoAP Fundamentals and Architecture: Review where message types fit in the client/server architecture.
CoAP Message Reliability and Exchange Contracts: Go deeper on CON/NON/ACK/RST layering, named retransmission timers, Message ID versus Token roles, and duplicate handling.
CoAP Methods and Features: Connect CON, NON, ACK, and RST behavior to GET, POST, PUT, DELETE, and resource discovery.
CoAP Observe Extension: See how notifications use confirmable and non-confirmable messages over time.
CoAP Security Applications: Relate message handling to DTLS, OSCORE, and constrained-device security choices.

6.13 Summary

CoAP message types separate transport reliability from application semantics. Confirmable and non-confirmable messages control acknowledgement behavior, while request methods and response codes describe the resource operation.

6.14 Key Takeaway

Choose the CoAP message type from the consequence of loss. Use confirmable messages for commands and state changes that must be acknowledged, and non-confirmable messages for replaceable telemetry where the next reading can supersede a lost one.

6.15 Message Exchange Patterns

Inspect Figure 6.6 to separate message type, response timing, method, Message ID, and Token roles before diagnosing a trace.

Four CoAP timelines for piggybacked CON and ACK, separate response, NON POST and response, and RST, followed by Message ID and Token definitions and request methods. — Figure 6.6: CoAP piggybacked, separate, non-confirmable, and reset exchanges with Message ID and Token role cards.

Read Figure 6.6 by comparing PIGGYBACKED with SEPARATE: the latter uses an empty ACK before the later content response. MESSAGE ID supports duplicate and ACK/RST matching, while TOKEN continues to associate a request with its separate response; GET, POST, PUT, DELETE, and multicast discovery remain application operations.