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) requests an acknowledgment and permits retransmission, Non-Confirmable (NON) has no CoAP acknowledgment, Acknowledgment (ACK) confirms CON receipt and can piggyback the response payload, and Reset (RST) indicates the receiver cannot process the message. CON asks for an acknowledgment and retries, so use it for commands and alarms; NON is fire-and-forget, so use it for frequent readings. The choice trades reliability for energy: in the worked example below, a CON exchange costs about 16× a NON one. CON improves delivery under loss but cannot guarantee it. The example assumes a continuously listening receiver during a 50 ms ACK wait.

6.1 Start With the Delivery Choice

This section: Start With the Delivery Choice — Picture one device sending two updates: a freezer-door alarm and a routine temperature sample.

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

This section: 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

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

This section: Continue: CoAP Message Reliability and Exchange Contracts — The main chapter below stays focused on CoAP message types, energy tradeoffs, and exchange patterns.

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

This section: CoAP Message Types — Inspect Figure 6.1 to choose CON or NON from the consequence of loss and then place ACK and RST around that sender choice.

Inspect Figure 6.1 to choose CON or NON from the consequence of loss and then 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):

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: NON is fire-and-forget, with no CoAP ACK wait; the radio is on for about 2 ms in the example below (vs ~52 ms for CON); battery savings depend on the radio’s sleep and receive schedule; use NON for frequent sensor readings where occasional loss is acceptable.

Fire-and-forget, no waiting
Radio on for about 2 ms in the example below (vs ~52 ms for CON)
Battery savings depend on the radio’s sleep and receive schedule
Use for: Frequent sensor readings where occasional loss is acceptable

Example: A temperature sensor sending readings every 60 seconds may save receive energy with NON if the application accepts occasional loss. Battery life cannot be inferred from message type alone; measure the whole device’s current profile.

Broker Bex, Messaging and broker domain expert

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.
Battery life needs a full device-current budget; the message type alone does not determine it.

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 + assumed 20-byte compressed IPv6 header = 52 bytes (illustrative 6LoWPAN case; excludes 802.15.4 framing)
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× ratio applies only to the modeled radio energy per exchange with a 50 ms listening wait. Battery-life impact also depends on sleep current, sensing, retries, and other device work.

6.6 ACK Wait Energy Calculation Audit

This section: ACK Wait Energy Calculation Audit — If independent attempts each have 5% loss, 2,880 NON readings per day would lose an expected 144 readings; each lost reading is replaced by the next one 30 s later; one CON retry would leave 0.05² = 0.25% without an ACK.

If independent attempts each have 5% loss, 2,880 NON readings per day would lose an expected 144 readings; each lost reading is replaced by the next one 30 s later; one CON retry would leave 0.05² = 0.25% without an ACK. Decision: use NON for routine 30-second temperature readings if occasional loss is acceptable, and CON for rare threshold alerts (~2 per day) such as “Temperature exceeded -18C”. CON improves the chance of delivery but cannot guarantee an alert arrives; use an application-level escalation if missed alerts are unacceptable.

This section:

Checkpoint: Energy Budget

The illustrative packet is 52 bytes: 20 payload + 4 CoAP + 8 UDP + an assumed 20-byte compressed IPv6 header; 802.15.4 framing is excluded.
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.

This section:

6.7 Interactive: CoAP Message Energy Calculator

This section: 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.

This section:

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.

This section:

6.8 Message Exchange Patterns

This section: Message Exchange Patterns — After ACK and RST, choose response timing.

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

This section: Interactive: CoAP Retransmission Timeline

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

This section:

Quick Review: Match & Sequence

Test your recall before the detailed knowledge checks below.

This section:

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.

This section:

6.10 Videos

This section: Videos — The first case shows an IoT decision platform in a deployed farming context.

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

This section: Knowledge Check — Test your understanding of CoAP message types and communication patterns.

Test your understanding of CoAP message types and communication patterns.

Label the Diagram

Code Challenge

6.12 See Also

This section: See Also — Review CoAP basics first.

Review CoAP basics first. Then see how message types shape reliable exchanges.

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.

CoAP exchanges narrated tour

Narrated audio tour. The full transcript is below.

Play the tour to open the simulator. Pause, replay a beat, or read the full transcript below.

Some beats explain situations this teaching model cannot show; those beats keep the existing frame and provide captions only.

Full transcript — CoAP exchanges (8 beats)

B1 — Receipt versus readiness
You are the engineer responsible for an industrial gateway asking a sensor for a diagnostic report. You need the report to decide whether a machine can keep running safely. A receipt arrives quickly, but the sensor is still collecting data. When can you treat the report as ready?

Model caption: Your diagnostic report is still being prepared. The firmware-status model will illustrate how receipt and a later answer are exchanged.

B2 — CON and ACK
The Constrained Application Protocol, or CoAP, gives small devices rules for exchanging messages. A confirmable message, abbreviated CON, asks for acknowledgment and permits retransmission if acknowledgment is absent. An acknowledgment, abbreviated ACK, confirms receipt of that message. It may also carry the response's useful content, called the payload.

Model caption: Constrained Application Protocol: confirmable requests ask for acknowledgment. An acknowledgment confirms receipt and may carry useful response content.

B3 — NON and RST
Non-confirmable, abbreviated NON, means no CoAP acknowledgment is expected. Reset, abbreviated RST, means the receiver lacks the exchange context needed to process a message. For your diagnostic request, we will follow confirmable delivery, so receipt of the request gets acknowledged while the sensor prepares the report.

Model caption: NON means non-confirmable: no protocol acknowledgment is expected. RST means Reset: the receiver lacks exchange context. The diagnostic example uses confirmable delivery.

B4 — Message ID and token
Two labels do different jobs. The message identifier, called the Message ID, matches an acknowledgment to a message. The token connects an application response to its request. If an answer is ready promptly, the acknowledgment can carry it too. That combined reply is called a piggybacked response.

Model caption: Message identifier matches the acknowledgment. Token matches the answer to its request. A ready answer can travel inside the acknowledgment.

B5 — Empty receipt
Now take the chapter's diagnostic example. Collecting the report takes about eight seconds. Your gateway sends a confirmable request. The sensor promptly sends an empty acknowledgment with the request's message identifier. Request retransmissions stop, while diagnostic work continues. The empty acknowledgment carries no report.

Model caption: Chapter example: diagnostics take about eight seconds. An empty acknowledgment stops request retransmissions before the report is ready. Asset: analogous firmware-status exchange.

B6 — Separate response
After about eight seconds of diagnostic work, the sensor sends the report in a new confirmable message. Its message identifier changes, but its token matches the original request. Your gateway acknowledges the report message using its new message identifier. Each confirmable message gets an acknowledgment, making four messages in total. The result is two messaging exchanges serving one application request and response.

Model caption: Chapter result: about eight seconds of diagnostic work; four messages, two messaging exchanges, one application request and response. The later answer uses a new message identifier and the original token.

B7 — Receipt is not completion
The misconception is that receiving an acknowledgment means the requested report is complete. The empty acknowledgment disproves that: it stops retries while the report is still being prepared. The later response carries the report, and its token associates the report with your request.

Model caption: An empty acknowledgment confirms receipt while work continues. The later response supplies the answer; its token links it to the request.

B8 — Match the labels
Match acknowledgments by message identifier, match answers by token, and treat an empty receipt as a receipt.

Model caption: Match acknowledgments by message identifier, match answers by token, and treat an empty receipt as a receipt.

6.13 Summary

This section: Summary — CoAP message types separate transport reliability from application semantics.

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

This section: Key Takeaway — Choose the CoAP message type from the consequence of loss.

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

This section: Message Exchange Patterns — Inspect Figure 6.6 to separate message type, response timing, method, Message ID, and Token roles before diagnosing a trace.

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.

Find help

Search reviewed answers

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed 2026-10-16

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed 2026-10-16

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed 2026-10-16