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.
iotclass.org

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
iotclass.org

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.
iotclass.org

Major section

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

  • 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.
iotclass.org

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

Key terms

Confirmable (CON)
Confirmable (CON) is like certified mail -- you send it and wait for a signed receipt.
iotclass.org

Major section

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.

  • CON starts a reliability exchange and waits for a matching ACK, while NON spends no acknowledgment traffic and accepts possible loss.
  • Critical data must arrive.

Key terms

If the ACK
If the ACK is absent, the client retransmits the same CON with backoff rather than inventing a new operation.
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.
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.
iotclass.org

Major section

CoAP Message Types (continued)

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.

  • 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.
iotclass.org

Major section

Checkpoint: CON or NON

NON fits frequent sensor readings where loss is acceptable and battery conservation is critical.

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

Numbers to remember

250 KbpsSensors use 802.15.4 radios (250 Kbps) with 8 mA TX
8 mASensors use 802.15.4 radios (250 Kbps) with 8 mA TX
iotclass.org

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

iotclass.org

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.

Key terms

When the representation
When the representation is already available, the server can combine transport acknowledgment and application response.
Piggybacking
Piggybacking is efficient because the response was ready inside the acknowledgment window; it is not a promise that every server operation completes that quickly.
CoAP piggyback response showing a confirmable GET request and an ACK that both stops retransmission and carries a 2.05 Content payload.
CoAP piggyback response showing a confirmable GET request and an ACK that both stops retransmission and carries a 2.05 Content payload.
iotclass.org

Deck summary

Key takeaways

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

  • 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.
  • 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.
  • NON fits frequent sensor readings where loss is acceptable and battery conservation is critical.
iotclass.org

Retrieval practice

Recall check 1 of 5

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

Q1A home security company deploys window sensors that send 'OPEN' or 'CLOSED' events. Each sensor runs on a CR2032 coin cell battery. The product manager wants both 3-year battery life AND guaranteed delivery of every door/window event. Which message type configuration best balances these requirements?

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

iotclass.org

Retrieval practice

Recall check 2 of 5

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

iotclass.org

Retrieval practice

Recall check 3 of 5

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

Q3A battery-powered temperature sensor sends readings every minute to a server. 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.

iotclass.org

Retrieval practice

Recall check 4 of 5

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 ACK as valid and continue processing
BIgnore the mismatch and wait for the correct ACK
CReject with RST unless expecting a separate response
DRetransmit the original CON message immediately
Show answer

Answer: C No, this is invalid - it indicates an error or a separate response pattern.

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

AWhen it successfully receives and processes a message
BWhen it wants to subscribe to resource updates (Observe)
CWhen it needs to retransmit a lost CON message
DWhen it receives invalid, unexpected, or unprocessable messages
Show answer

Answer: D see answers page

iotclass.org

Retrieval practice

Recall check 5 of 5

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.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. C · Correct!
  2. B · Correct!
  3. B · Non-Confirmable (NON) messages are better for this use case.
  4. C · No, this is invalid - it indicates an error or a separate response pattern.
  5. D · RST messages reject invalid or unexpected messages: 1) Unknown Message ID - received ACK for a CON you never sent, 2) Duplicate message - received the same confirmed message twice (duplicate detection failed), 3) Server unavailable - can't process the request, 4) Protocol error - malformed message.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. A · CON (Confirmable) messages are set via mtype=CON.
iotclass.org