11 Packet Anatomy
Read a Transmitted Frame as Fields, Not Bytes
11.1 In 60 Seconds
Read a packet as fields, not as one blob of bytes. First find the boundary, then read the header fields that tell the receiver how to handle the message, then decode the payload with its representation contract, and finally validate the check field against the bytes it covers.
11.2 Start With the Story
Start with a message crossing a link where the receiver must know where the packet starts, what each field means, and whether any byte was corrupted. The core idea in Packet Anatomy is simple: packet and format design is about boundaries, field meaning, compactness, checks, and the evidence that the receiver can parse the payload safely. This page focuses that idea on Packet-anatomy : the header/payload/trailer regions, common header fields, a worked byte-by-byte decode, payload representation contracts. In everyday IoT, JSON, CBOR, Protobuf, custom binary, framing bytes, CRCs, and overhead budgets are practical choices with reliability and debugging costs. Start simple: draw the packet as fields, mark the payload and checks, then justify the format only after the parse path is clear.
11.3 A Packet Is Three Regions
A packet is a structured message, not an undifferentiated string of bytes. Read almost any frame as three regions: a header that tells the receiver how to handle the message, a payload that carries the application data, and a trailer or check field that helps detect corruption or tampering.
Packet anatomy is the skill of seeing those regions in raw bytes. It is what lets you debug a capture, compare protocol overhead, confirm what a payload means, and explain why a receiver accepted or rejected a frame.
In real IoT work, those regions appear in different places depending on the layer you are reading. An IEEE 802.15.4 or Ethernet frame has link-layer addressing and checks. An IPv6 or UDP packet adds network and transport headers. A CoAP, MQTT-SN, BLE advertisement, LoRaWAN MAC frame, or custom serial protocol then adds its own type, length, sequence, flags, or application layout. The names change, but the reading habit is the same: identify control fields before trusting the value bytes.
If you only need the intuition, this layer is enough: think of an addressed parcel. The shipping label (header) says where it goes and how to handle it, the contents (payload) are what you actually wanted, and the tamper seal (check field) tells you whether it arrived intact. You read the label before you trust the contents.
That order matters during debugging. In Wireshark, a logic-analyzer capture, a serial monitor, or a gateway log, a temperature value that looks plausible can still be wrong if the length field points to a different boundary, the message type selects another parser, the byte order is reversed, or the check field fails. Packet anatomy keeps the review mechanical: boundary first, control fields second, payload interpretation third, validation last.
The One-Minute Read
Header — how to handle it
Address, type, length, sequence, flags, version. The receiver reads this first to decide what to do with the rest.
Payload — the data
The sensor reading, command, or nested message. Meaningful only once you know its schema, units, and byte order.
Trailer / check — integrity
Checksum, CRC, or authentication tag. Tells you whether the bytes survived the trip unchanged.
Beginner Example
A tiny sensor message has a type byte, a two-byte temperature value, and a checksum. The type and length belong to the header, the temperature is the payload, and the checksum is the validation field. Same bytes, three different jobs.
Packet Region Knowledge Check
The core review habit is to identify the boundary and control fields before trusting the payload, then validate the check field against the bytes it is supposed to cover.
11.4 Apply It: Read a Packet by Region
The practical workflow turns raw bytes into a decode record. Work in order — boundaries first, then header, then payload, then check — because each step depends on the one before it.
- Find the boundary. Confirm where one packet starts and ends before assigning meaning to any byte.
- Read the header first. Use type, length, address, flags, sequence, or version to decide how the payload should be handled.
- Interpret the payload with a contract. Decode the data only after the schema, units, byte order, and nesting rules are known.
- Check the trailer. Ask which bytes the check covers and what kind of error it can detect.
Worked Decode: AA 03 10 00 EB 7C
Bytes only mean something once a layout assigns boundaries and field roles. Here is one small application frame decoded byte by byte — the hands-on core of this chapter. Try covering the “meaning” column and predicting each field from the layout before you read it.
Change the layout and the same six bytes decode differently. That is the whole point: the receiver and sender must agree on boundaries, field order, and units in advance.
Common Header Fields
Address
Identifies a sender, receiver, device, topic, route, or session depending on the layer.
Length
Tells the receiver how many bytes belong to the payload or frame.
Type
Names the payload behavior so the receiver chooses the right parser.
Sequence
Helps detect missing, repeated, or reordered messages.
Flags
Pack small control states into individual bits.
Version
Protects compatibility when layouts change.
Length Field Knowledge Check
Match Field to Purpose
A useful decode record keeps the raw bytes, boundary rule, header fields, payload contract, check result, and expected accept/reject behavior together.
11.5 Under the Hood: Contracts, Overhead, and Workflow
The Payload Needs a Representation Contract
A payload is not automatically self-describing. The same bytes can be a fixed binary layout, text, a compact structured format, or a nested packet — and each needs its own contract before the values can be trusted.
Overhead Without Hype
Overhead is the non-payload part of a packet. It is not automatically bad — it pays for routing, reliability, security, ordering, or parsing. Measure it against the requirement, not a universal target.
A small payload share can be perfectly acceptable when the extra fields provide needed addressing, integrity, ordering, security, or compatibility. A 6-byte frame that is 50% header may still be the right design for a noisy, security-sensitive link.
The Repeatable Decode Workflow
- Capture raw bytes. Keep the original sequence and the capture context.
- Find boundaries. Use length, delimiter, or capture metadata — never split bytes by eye.
- Apply the layout. Read fields in order from the protocol or application contract.
- Decode the payload. Use the representation rules, not guesses from visible values.
- Validate checks. Confirm the check covers the expected bytes and matches the expected algorithm.
- Record a test vector. Save bytes, field names, decoded values, and the expected accept/reject result.
Order the Packet Decode
Label the Packet Review Record
Common Pitfalls
- Guessing field boundaries. Do not split bytes by eye; use the documented delimiter, length, or frame layout.
- Treating the payload as self-describing. Compact bytes, text, and nested formats each need their contract before interpretation.
- Checking the wrong bytes. Integrity fields cover a specific range; confirm exactly which bytes are included.
- Ignoring version and type. The same payload bytes can mean different things under a different message type or version.
At this depth, a packet is a contract: boundaries, field layout, payload representation, and a check whose coverage is known. A good review records all four as a reusable test vector, so the next capture can be decoded the same way.
Packet diagrams compress a lot of design information into a few boxes. Read them as an engineering record, not as decoration.
- Name every field. Write down each field label, byte count, and position before interpreting behavior.
- Find the boundary rule. Identify whether the format uses a length field, delimiter, fixed size, or lower-layer framing.
- Separate payload from control. Keep application data distinct from addressing, routing, ordering, flags, and validation fields.
- Locate validation. Record what check field exists and when the receiver evaluates it.
- Record assumptions. State byte order, units, optional fields, and what changes when a flag is present.
- Test one example. Walk one realistic byte sequence through the diagram and confirm the parser result.
11.6 Summary
- A packet is read as three regions: header (how to handle it), payload (the data), and trailer/check (integrity).
- Header fields describe how to route, order, parse, or version the packet; the length field is boundary evidence, not proof of payload meaning.
- The payload needs a representation contract — fixed layout, text, structured, or nested — before its bytes can be trusted.
- Overhead is the non-payload share; it is useful when it buys addressing, integrity, ordering, or security, so measure it against the requirement.
- A good decode is repeatable: capture → boundary → layout → payload → check → saved test vector.
A packet is a structured contract between sender and receiver. Headers, payloads, addresses, lengths, flags, sequence fields, and checksums only carry meaning when both sides agree on boundaries, field order, and representation.
11.7 See Also
Packet Framing
How the receiver finds the packet boundary before anatomy can be trusted.
Packet Error Detection
How check fields (checksums, CRCs) support receiver-side validation.
Packet Protocol Overhead
How the regions contribute useful non-payload bytes and how to compare them.
Data Representation
How payload bytes become trusted values through encoding and byte order.