Data
The application payload, such as a sensor reading, command, status event, or query.
15 Encapsulation and PDUs
networking-core
layered
fund
encapsulation
15.1 Start With the Message Getting Wrapped
A sensor reading does not cross the network as bare text. Each layer wraps it with the information that layer needs: application meaning, transport ports, network addresses, link framing, and physical signaling.
Encapsulation is the story of those wrappers being added and removed without losing the payload. When a deployment breaks, the wrapper that is missing, oversized, stale, or misunderstood often tells you where to look first.
Overview: Wrappers Give Each Layer a Job
Encapsulation is the way a network layer turns the data it receives into the unit it can carry. The application creates a message. The transport layer adds delivery context and creates a segment or datagram. The network layer adds network addressing and creates a packet. The link layer adds local delivery and error-check context and creates a frame. The physical layer sends bits.
Decapsulation is the reverse path at the receiver. Each layer checks and removes its own wrapper, then passes the remaining payload upward. The important habit is to name the unit by the outermost wrapper you are inspecting.
For example, a temperature value may begin as a small application reading, but by the time it reaches the radio it is no longer just that value. It may be inside a CoAP message, a UDP datagram, an IP packet, and a Wi-Fi or IEEE 802.15.4 frame. A gateway capture that sees the link wrapper should call the captured unit a frame, even though the frame contains a packet and the packet contains a datagram. That naming discipline prevents a review from mixing application meaning with transport delivery, routing scope, and local-link behavior.
If you only need the intuition, remember this: data is wrapped on the way down, unwrapped on the way up, and the PDU name follows the layer that most recently wrapped it.
Segment or datagram
The transport PDU, with port and delivery context for the application flow.
Packet
The network PDU, with source and destination network addresses plus routing context.
Frame
The data-link PDU, with local link addressing, link type, and frame-check information.
Practitioner: Build a Packet Trace Record
A useful encapsulation review does not stop at naming layers. It records what each wrapper proves, what field or observation supports the claim, and what would make the trace suspicious.
For an IoT message, trace the application payload down the stack at the sender, across the local medium, and back up at the receiver or gateway. Focus on evidence that a reviewer can inspect: capture location, outer PDU, addressing scope, payload owner, and failure clue.
The trace record should also state what changed since the last good capture. A new security wrapper, a different transport, a gateway move, or a larger diagnostic payload can change the outer PDU size without changing the application value. That is why a useful review keeps the raw capture, the decoded layer names, and the release decision together.
Trace point
What to name
What to inspect
Common clue
Application boundary
Data or message
Payload format, method, topic, resource path, or command meaning.
Wrong schema, stale meaning, or missing application context.
Transport boundary
Segment or datagram
Ports, delivery expectation, ordering need, and retry responsibility.
Wrong port, wrong transport choice, or unneeded reliability overhead.
Network boundary
Packet
Source and destination network addresses, routing scope, and hop behavior.
Wrong address, blocked route, or unexpected network translation.
Link boundary
Frame
Local addresses, link type, frame check, and medium-specific constraints.
Local delivery failure, MTU pressure, collision, or link-layer retry.
Name the capture point
A gateway radio capture, Ethernet mirror, browser request, and cloud log expose different wrappers.
Preserve the nesting
Do not call every unit a packet. Write frame containing packet containing datagram containing payload when that is what the trace shows.
Connect to a decision
The trace should answer a review question: delivery boundary, payload overhead, fragmentation risk, retry behavior, or parser ownership.
Record the reopen trigger
Recheck the trace when payload size, transport choice, link type, gateway placement, or security wrapper changes.
Under the Hood: Overhead, MTU, and Compression
Every wrapper has a cost. Headers and trailers carry useful control information, but they also consume airtime, link budget, queue space, and processing effort. This matters most when the payload is small, the link frame budget is tight, or the radio sleeps between messages.
MTU pressure appears when the network packet plus lower-layer wrapper does not fit cleanly into the link frame. Fragmentation can be valid, but it increases failure exposure because losing one fragment can invalidate the whole higher-layer packet. Compression techniques and smaller application payloads are ways to reduce that pressure when they fit the protocol and deployment.
A reviewer should compare wrapper cost with the control value it buys. A few bytes of port, sequence, integrity, or security context may be essential for a command path, while the same overhead may be excessive for a tiny periodic reading. The boundary is not "fewest headers wins"; it is whether the flow can meet its latency, energy, reliability, and observability requirements after all wrappers are counted. When the budget is tight, the options are to compress repeated fields, batch readings, reduce payload verbosity, change the link, or move the work to a gateway that can afford the wrapper stack.
Overhead is not waste by default
Addressing, sequencing, integrity, security context, and type information are useful when they match the flow's needs.
Compression needs context
Header compression is strongest when endpoints share stable context and the deployment can validate decompression behavior.
Fragmentation adds exposure
More fragments mean more opportunities for loss, duplication, reordering, timeout, and retry behavior to affect the message.
Evidence must be measured at the right boundary
Application logs can prove meaning; packet captures prove wrappers; link counters prove local delivery behavior.
15.2 Summary
Encapsulation gives each layer a wrapper it can own. Application data becomes a transport segment or datagram, then a network packet, then a data-link frame, and finally bits on the medium. Decapsulation reverses that process at the receiver. The reviewer should name the outermost visible wrapper, preserve the nesting in packet traces, and connect overhead or fragmentation concerns to evidence from the right boundary.
15.3 Key Takeaway
Name the PDU by the wrapper you are inspecting: frames carry packets, packets carry segments or datagrams, and those carry application data.