CoAP · Study deck

CoAP Messages: Format Foundations

A constrained sensor cannot waste bytes on every request.

Broker Bex is your guide for this deck.

messageformat
Broker Bex assembles a compact message and matches request and reply shapes beside a sensor.
iotclass.org

After studying this chapter

Learning objectives

Read the fixed header before interpreting the rest of a CoAP message.

  • The fixed header has five fields in four bytes.Version, type, token length, code, and Message ID give the receiver its starting information without a long text header.
  • Type and Code have different message-handling jobs.Type selects acknowledgement behaviour, while Code identifies the request method or response status carried by the datagram.
  • Tokens can pair responses with concurrent requests.The controller needs the reply’s token to match an outstanding leak-sensor request rather than assuming the newest arrival answers the newest question.
  • Compact binary fields can leave more space for useful data.The chapter’s 83-byte application budget leaves 79 bytes for tokens, options, and payload after the four-byte fixed header.

I am inspecting a leak-sensor reply while another request is still in flight. I read the compact header first, then check that the response belongs to the request the controller is waiting for.

iotclass.org

Major section

In 60 Seconds

A well-formed header still needs checks before its reply can change application state.

  • A delayed leak-sensor reply can answer an earlier request.Several exchanges can overlap, so four valid header bytes alone do not establish that the response belongs to the current question.
  • The reply token must match an outstanding request.A mismatched response needs rejection rather than a guess about which sensor state the controller should accept.
  • Message identity alone cannot establish the payload’s meaning.Code, source, time, unit, and content type belong in the record alongside the token and accepted application state.
  • Repeated requests and receiver restarts can expose incorrect matching.The chapter also delays a reply and changes content type to test whether the controller accepts only the expected response.

I have sent two requests to the leak sensor and delayed one reply. I check which request each response answers before letting its content change the controller’s accepted state.

iotclass.org

Major section

Start With the First Four Bytes

Follow the packet from its fixed header through token and options to any payload.

  • Type and Code determine the receiver’s initial handling.The gateway needs the Confirmable or Non-confirmable choice and the request or response code before interpreting the rest of the packet.
  • Token length tells the parser how much matching data follows.The token comes immediately after the fixed header, before compressed options and any message body.
  • Message ID supports acknowledgements and duplicate detection.Request-response pairing belongs to the Token instead, which matters when the controller has several sensor requests in flight.
  • The payload marker appears only when a body follows.The chapter’s packet order separates fixed header, token, and options from the optional useful content.

I am at the gateway reading a captured CoAP datagram. I follow its fixed header, token, and compressed options in order, looking for a payload marker only when a body follows.

iotclass.org

Major section

Key Concepts

Separate request matching from the choice of acknowledgement behavior.

  • A Confirmable message requires an acknowledgement from its recipient.This per-message choice provides acknowledgement behaviour over UDP instead of relying on a permanent TCP connection.
  • A Non-confirmable message has no delivery guarantee.The chapter describes this fire-and-forget datagram as the lower-latency choice without a required acknowledgement from its recipient.
  • The client’s Token can distinguish several outstanding requests.Concurrent replies need request-response pairing even when Message IDs already support acknowledgement handling and duplicate detection.
  • Observe lets a client request resource-change notifications.The client registers for changes rather than treating every later notification as an unrelated response to a new question.

I am deciding how to recognise the leak sensor’s reply and how to handle its delivery. I keep token matching separate from acknowledgements, then consider notifications when the resource changes.

iotclass.org

Activity 1 · Match

✎ Match each CoAP job

I want you to separate reply matching from message delivery.

On paper, match Token, Message ID, CON, NON, and Observe to these jobs: duplicate detection; resource-change notifications; request-response pairing; acknowledgement required; no delivery guarantee.

3 minutes · Pen and paper · Answer: Activity 1

Your answer
iotclass.org

Major section

For Beginners: CoAP Message Format

A compact fixed beginning makes the optional parts easier to locate.

  • The header is the postcard’s small fixed beginning.Its four bytes are the chapter’s address-and-stamp area, leaving constrained devices room for the rest of the message.
  • The following token can link a response to its request.A controller with overlapping sensor requests needs that pairing value before it can accept a delayed reply.
  • Binary options can carry metadata without long text header lines.The worked Content-Format example describes JSON in three CoAP bytes compared with a 32-byte HTTP header line.
  • An optional payload carries content after its marker.The receiver still needs content metadata and application checks to interpret the useful data after locating its boundary.

I picture the CoAP message as the chapter’s postcard: a small fixed beginning followed by the message. I use that comparison to locate the token, metadata, and optional payload without losing their different jobs.

iotclass.org

Major section

Why CoAP's Format Exists: Design Rationale

The application shares a small frame with several lower-layer headers.

  • The chapter’s frame budget starts at 127 bytes.Its IEEE 802.15.4 example must fit lower-layer headers and application data inside that small shared space.
  • MAC and 6LoWPAN headers need 23 and 13 bytes respectively.Those deductions occur before the UDP header or any CoAP header, token, option, or payload enters the budget.
  • The eight-byte UDP header leaves 83 bytes for the application.Subtracting 23, 13, and 8 from the 127-byte frame shows why long text headers compete directly with useful content.
  • CoAP’s fixed header needs four bytes of the application budget.The remaining 79 bytes must accommodate the token, compressed options, and payload rather than carrying payload alone.

I am spending the chapter’s 127-byte frame budget on its headers. I subtract each lower-layer cost before deciding how much space remains for the CoAP message.

iotclass.org

Major section

Tokens and binary metadata save space

Binary fields save space without dropping the information needed to interpret a message.

  • Tokens, options, and payload share the space after the fixed header.The chapter’s 83-byte application allowance becomes 79 bytes after the four-byte CoAP header, before any variable fields are included.
  • The token can accompany the message without TCP connection setup.The gateway can use this pairing field instead of maintaining a TCP socket for every sensor connection in the chapter’s comparison.
  • The worked JSON metadata comparison needs three CoAP bytes.Its option delta, length, and value can represent the JSON metadata carried by the chapter’s 32-byte HTTP Content-Type line.
  • Compact encoding can reduce transmitted bytes and their energy cost.The sensor’s binary header and metadata use less of the small frame, where every transmitted byte consumes airtime and battery energy.

I am comparing the chapter’s two ways to say that a payload contains JSON. I keep the three-byte CoAP option and 32-byte HTTP line beside the remaining frame budget to see their cost.

iotclass.org

Deck summary

Key takeaways

Decode structure and verify meaning before accepting a CoAP reply.

  • The fixed header tells the receiver where parsing begins.Its version, type, token length, code, and Message ID fit in four bytes before the token and compressed options.
  • Tokens and Message IDs have different matching responsibilities.The Token pairs request and response; Message ID supports message-layer acknowledgements and duplicate detection during the exchange.
  • Confirmable and Non-confirmable messages have different acknowledgement rules.The first requires an acknowledgement, while the second avoids that requirement and provides no delivery guarantee.
  • Payload acceptance needs metadata and application checks.A well-formed reply can still have the wrong content type, source, time, or unit for the controller’s current question.

I return to the delayed leak-sensor response with its header decoded. I still need the correct token, acknowledgement interpretation, and payload checks before the controller can accept its state.

iotclass.org

Retrieval practice

Recall check

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

Q1A CoAP client has several requests in flight and uses Message ID alone to match responses. What should the reviewer correct?

AUse the Token to correlate request and response.
BUse Message ID as the application payload identifier for every request
CIgnore Content-Format because CoAP options are optional
DReplace token matching with a permanent TCP session
Show answer

Answer: A CoAP message-format review should distinguish header fields, options, tokens, and payload interpretation.

iotclass.org

Print reference

Answers

Answer key.

  1. A · CoAP message-format review should distinguish header fields, options, tokens, and payload interpretation.
iotclass.org

Print reference

Activity 1 answer

Model answer.

Match: Token: request-response pairing. Message ID: duplicate detection. CON: acknowledgement required. NON: no delivery guarantee. Observe: resource-change notifications.

iotclass.org