CoAP · Study deck
CoAP Messages: Codes, Tokens, and Options
Sensor temperature request → CoAP message → reply. Message ID tracks the message exchange; token links the reply to its request.
Broker Bex is your guide for this deck.

After studying this chapter
Learning objectives
Decode the packet before interpreting the application result.
- Read the fixed header, token, options, and payload in order.
- Match Message ID to the exchange and token to the response.
- Compare byte costs only under the stated model assumptions.
Major section
Start With the Decision
A CoAP message exchange pairs a message with its acknowledgment or reset, if one is used.
- A Message ID helps detect duplicates and match that acknowledgment; it does not match a response to a request.
Major section
Minimum Viable Understanding: CoAP Message Structure
The fixed header contains version, message type, token length, method/response code, and message ID.
- Key Takeaway: CoAP's 4-byte fixed header carries message type, code, token length, and Message ID.
- The following token field, which can be zero bytes long, matches a response to its request; the header alone does not.
Major section
The 4-Byte Fixed Header
Choosing between CON and NON is one of the most important decisions in a CoAP implementation.
- The wrong choice either wastes battery on unnecessary retransmissions or silently loses critical commands.
- Rule of thumb: If losing the message would require human intervention to notice or correct, use CON.
Major section
Message in a Bottle
The CoAP header is like the label you put on the bottle.".
- Code: What you want - "Can I have the temperature?" (GET).
- Just like how a bottle label is tiny compared to the letter inside, CoAP's header is tiny (4 bytes!) compared to HTTP's headers (hundreds of bytes!).
Major section
Token Security Consideration
In secure deployments (DTLS), tokens should be unpredictable (randomly generated) to prevent response spoofing attacks.
- A malicious actor who can predict tokens could inject fake responses.
Major section
CoAP Options
Extended delta: 0, 1, or 2 extra bytes when the delta does not fit in 4 bits.
- Option 1: Uri-Path = "sensors" uses delta 11, length 7, and encodes as 0xB7 | "sensors".
- Option 2: Uri-Path = "temp" uses delta 0, length 4, and encodes as 0x04 | "temp".
Major section
CoAP Options (continued)
The Content-Format option tells the receiver how to decode the payload, so select it as part of the resource contract rather than after serialization.
- 0 text/plain fits a human-readable scalar, while 50 application/json supports familiar structured objects.
- On constrained links, 60 application/cbor carries structured data in a compact binary representation; 40 application/link-format has the separate job of encoding discovery links.
- A receiver must interpret the numeric code before parsing payload bytes.
Major section
Worked Example: GET /sensors/temp with JSON Response
Real-world HTTP requests with cookies, user-agent, and other headers typically reach 300-800 bytes.
- The ACK + response is piggybacked -- one message serves as both "I received your request" and "here is the data.".
Major section
Putting Numbers to It
Compare modeled byte costs while keeping battery life a separate measurement.
- The example uses 175,200 readings.
- The stated byte-cost model gives about 5,606 joules versus 28,032 joules.
- The larger modeled transmit term is five times the smaller.
- Battery life also depends on receive, idle, retries, conversion loss, and usable cell energy.
Deck summary
Key takeaways
A CoAP message exchange pairs a message with its acknowledgment or reset, if one is used.
- The fixed header contains version, message type, token length, method/response code, and message ID.
- Choosing between CON and NON is one of the most important decisions in a CoAP implementation.
- The CoAP header is like the label you put on the bottle.".
- In secure deployments (DTLS), tokens should be unpredictable (randomly generated) to prevent response spoofing attacks.
Retrieval practice
Recall check 1 of 3

Broker Bex says: answer from memory, then check your reasoning.
Q1A CoAP client sends PUT /actuator/valve {"position": 50} to set a valve to 50% open. The server successfully updates the valve. What response code should the server return?
Show answer
Answer: B 2.04 Changed is the proper response for successful PUT operations. The resource existed and was modified.
Retrieval practice
Recall checks 2 and 3 of 4

Broker Bex says: answer from memory, then check your reasoning.
Q2A CoAP client has two in-flight requests: GET /temperature (Token=0xAA, MsgID=0x0001) and GET /humidity (Token=0xBB, MsgID=0x0002). The CON for temperature times out and is retransmitted. What values should the retransmission carry?
Show answer
Answer: A On retransmission of a CON, both the Token AND the Message ID stay the same.
Q3Complete the CoAP message construction:
Show answer
Answer: A CoAP messages use mtype=CON for confirmable (reliable) delivery.
Retrieval practice
Recall check 4 of 4

Broker Bex says: answer from memory, then check your reasoning.
Q4You capture a CoAP packet with first byte 0x50. What can you determine about this message?
Show answer
Answer: A 0x50 = 0101 0000.
Print reference
Answers
Answer key.
- B · 2.04 Changed is the proper response for successful PUT operations. The resource existed and was modified.
- A · On retransmission of a CON, both the Token AND the Message ID stay the same.
- A · CoAP messages use mtype=CON for confirmable (reliable) delivery.
- A · 0x50 = 0101 0000.