CoAP · Study deck

CoAP Message Exchanges

The Constrained Application Protocol (CoAP) is a protocol for small devices and limited links.

Broker Bex is your guide for this deck.

messagetypes

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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

Major section

In 60 Seconds

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.
The next reading can replace a lost routine update.
The alarm needs a clear receipt or a safe fallback.

Major section

In 60 Seconds (continued)

Treating both messages alike either wastes battery or leaves the urgent event without proof.

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.
The example assumes a continuously listening receiver during a 50 ms ACK wait.

Major section

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

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.

Major section

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!'".

Major section

CoAP Message Types

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.
Critical data must arrive.

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.

Major section

CoAP Message Types (continued)

In Figure: CoAP confirmable exchange showing a CON request with, 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.
When a newer reading makes an older one disposable, Figure: CoAP non-confirmable exchange showing a client sending replaceable shows the smaller contract.

Major section

Checkpoint: CON or NON

Decide whether routine readings or urgent freezer alarms need a receipt. Pause for eight seconds.

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.

Major section

Interactive: CoAP Message Energy Calculator

ACKs cost power, but their meaning is narrow: they confirm CON receipt.

Application success still depends on the response code they carry.
RST is a message-layer rejection, not an application error shortcut.
An unknown Message ID or an empty CON ping can therefore produce RST.

Try it: Interactive: CoAP Message Energy Calculator in the chapter

Major section

Message Exchange Patterns

Fast work can ride inside ACK; slow work needs an empty ACK first.

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.
If producing the representation takes longer than the acknowledgment window, the two jobs must separate.

CoAP piggyback response showing a confirmable GET request and an ACK that both stops retransmission and carries a 2.05 Content payload.

Deck summary

Key takeaways

The Constrained Application Protocol (CoAP) is a protocol for small devices and limited links.

Treating both messages alike either wastes battery or leaves the urgent event without proof.
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$ .
"I have four different ways to send my readings?" asked Temperature Terry, confused.
CON starts a reliability exchange and waits for a matching ACK, while NON spends no acknowledgment traffic and accepts possible loss.

Retrieval practice

Recall check 1 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q1A home security company deploys coin-cell window sensors. OPEN/CLOSED state changes are infrequent and must be acknowledged, with an escalation path if delivery is not confirmed. Periodic heartbeats are frequent, and a missed heartbeat can be replaced by the next one. The three-year battery target still needs measurement. Which listed message policy best balances these needs?

AUse NON for all messages to maximize battery life - occasional missed events are acceptable for security systems

BUse CON for all messages to ensure every event is delivered - battery life is less important than security

CUse CON for state changes (OPEN/CLOSED events) and NON for periodic heartbeats - this balances reliability and battery life

DUse NON with application-level retries at the server - this provides reliability without CoAP overhead

Show answer

Answer: C CON acknowledges and retries important state changes, while NON avoids message-layer ACK traffic for replaceable heartbeats.

Retrieval practice

Recall check 2 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q2An industrial IoT gateway sends a CoAP CON request to a sensor asking for a complex diagnostic report. The sensor needs 8 seconds to collect data from multiple subsystems. What is the correct response pattern to avoid timeout issues?

ASend the full response after 8 seconds - CoAP will wait indefinitely for responses to CON messages

BSend an empty ACK immediately, then send the diagnostic data as a separate CON response when ready

CIncrease the client's ACK_TIMEOUT to 10 seconds before sending the request

DSplit the 8-second operation into multiple smaller requests, each completing within the default timeout

Show answer

Answer: B This is the 'separate response' pattern.

Retrieval practice

Recall check 3 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q3A battery-powered temperature sensor sends readings every minute to a server. Occasional loss is acceptable because the next reading replaces a missed one. Which message type should it use?

AConfirmable (CON) - to ensure every reading is delivered

BNon-Confirmable (NON) - for battery conservation with frequent data

CReset (RST) - to notify the server of each reading

DAcknowledgment (ACK) - to confirm receipt at the sensor

Show answer

Answer: B Non-Confirmable (NON) messages are better for this use case.

Retrieval practice

Recall check 4 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q4A CoAP client sends a CON message with Message ID 0x1234, but receives an ACK with Message ID 0x5678. What should the client do?

AAccept the different MID as an ACK for the original exchange.

BIgnore the unrelated ACK and keep the original CON timer active.

CSend RST for every unrelated ACK instead of waiting for the right one.

DRetransmit the original CON immediately without its timer rule.

Show answer

Answer: B RFC 7252 Section 4.2 requires a recipient to silently ignore an invalid ACK. This ACK cannot close the outstanding exchange because its Message ID differs from the CON; do not answer the ACK with RST.

Retrieval practice

Recall check 5 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q5When should a CoAP client send a Reset (RST) message?

AWhen a message was successfully received and processed as expected.

BWhen the client wants to register an Observe subscription.

CWhen the client needs to retransmit a lost CON request.

DWhen a CON arrives but the client lacks usable exchange context.

Show answer

Answer: D RST rejects a CON when the receiver lacks message context needed to process it, such as an Observe notification after a reboot.

Retrieval practice

Recall check 6 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q6Complete the CoAP client that sends a confirmable request and handles the response type:

Arequest = Message(code=GET, mtype=CON, uri='coap://sensor.local/status')

Brequest = Message(code=GET, mtype=NON, uri='coap://sensor.local/status')

Crequest = Message(code=GET, type='confirmable', uri='coap://sensor.local/status')

Drequest = Message(code=GET, reliable=True, uri='coap://sensor.local/status')

Show answer

Answer: A CON (Confirmable) messages are set via mtype=CON.

Print reference

Answers 1 of 2

Answer key.

C · CON acknowledges and retries important state changes, while NON avoids message-layer ACK traffic for replaceable heartbeats.
B · This is the 'separate response' pattern.
B · Non-Confirmable (NON) messages are better for this use case.
B · RFC 7252 Section 4.2 requires a recipient to silently ignore an invalid ACK. This ACK cannot close the outstanding exchange because its Message ID differs from the CON; do not answer the ACK with RST.

With a corrected answer frame visible, check the first five decisions. State changes can merit a receipt; replaceable samples may use N-O-N. A slow diagnostic gets an empty A-C-K before its separate response. A mismatched A-C-K does not close the original exchange: ignore it. A reset belongs to an unexpected message that the recipient cannot process.

Print reference

Answers 2 of 2

Answer key.

D · RST rejects a CON when the receiver lacks message context needed to process it, such as an Observe notification after a reboot.
A · CON (Confirmable) messages are set via mtype=CON.

With the final answer frame visible, the code choice is A: em-type equals C-O-N. That selects a confirmable message. Match the response to the request and inspect its code and content. A message receipt, a paired response, and a successful device action are different observations.