30 Encapsulation & PDUs
30.2 Learning Objectives
By the end of this chapter, you will be able to:
- Explain encapsulation: Describe how headers are added as data moves down the protocol stack
- Explain decapsulation: Describe how headers are removed as data moves up the stack
- Classify Protocol Data Units (PDUs): Identify the correct PDU name at each layer (Data, Segment, Packet, Frame, Bits)
- Calculate packet overhead: Determine the byte overhead added by protocol headers for a given payload size
- Compare protocol stacks: Evaluate the overhead efficiency of TCP/IP versus IoT-optimized stacks such as CoAP/6LoWPAN
- Apply header compression rationale: Select appropriate compression techniques (6LoWPAN, SCHC) based on payload size and energy constraints
- Construct an encapsulation trace: Follow an IoT message from application to physical transmission and back, identifying each PDU transformation
MVU: Minimum Viable Understanding
Core concept: Encapsulation is like putting a letter in envelopes – each layer adds its own “envelope” (header) around the data from the layer above. At the destination, each layer removes its envelope and passes the contents up.
Why it matters: Understanding encapsulation explains why small IoT messages become much larger on the wire (header overhead), why protocols like 6LoWPAN compress headers, and how to interpret packet captures in Wireshark.
Key takeaway: Data becomes Segment (Transport) becomes Packet (Network) becomes Frame (Data Link) becomes Bits (Physical). Each transformation adds addressing and control information.
30.3 Prerequisites
- OSI and TCP/IP Models: Understanding of the layered network model structure
For Beginners: Encapsulation = Packaging
Just like a letter gets wrapped:
- Letter (your message) goes in an…
- Envelope (with sender/receiver address) goes in a…
- Mail bag (sorted by region) loaded on a…
- Truck/plane (physical transport)
Each layer adds its “envelope” (header) around the data from the layer above.
At the destination, each layer removes its envelope and passes the contents up.
Sensor Squad: The Great Envelope Relay!
“I just measured the temperature – it is 23.5 degrees!” announced Sammy the Sensor proudly. “But how do I get this tiny number all the way to the cloud server?”
Max the Microcontroller grinned. “Easy! Think of it like wrapping a present. First, I take your reading and put it in an envelope labeled with port numbers – that is the Transport layer making it a Segment. Then I put THAT envelope inside a bigger one with IP addresses – now it is a Packet. Then Lila wraps it again with MAC addresses to make a Frame.”
Lila the LED blinked excitedly. “And I hand the whole thing to the Wi-Fi radio, which turns it into actual radio Bits – ones and zeros flying through the air! Each wrapper adds information so the message knows where to go.”
“But doesn’t all that wrapping make my tiny 4-byte reading really big?” Sammy asked. Bella the Battery sighed, “Yes! Your little temperature reading can become 80 bytes or more with all those headers. That is why I care about encapsulation – every extra byte costs me energy to transmit. Protocols like 6LoWPAN were invented to squish those headers back down and save my power!”
30.4 How Encapsulation Works: Step-by-Step
Think of encapsulation like preparing a package for shipping. Each layer wraps everything it receives from the layer above, adding its own header with control information.
Step 1: Application creates data
- You write “Hello!” (5 bytes)
- Application Layer: This is your raw message
Step 2: Transport adds reliability info
- TCP wraps your message with a header (20 bytes minimum)
- Header contains: source port, destination port, sequence number, acknowledgment
- Now you have a Segment:
[TCP header][Hello!]= 25 bytes
Step 3: Network adds addressing
- IP wraps the segment with routing information (20 bytes for IPv4)
- Header contains: source IP address, destination IP address, TTL, protocol type
- Now you have a Packet:
[IP header][TCP header][Hello!]= 45 bytes
Step 4: Data Link adds local delivery info
- Ethernet wraps the packet with MAC addresses and error checking (14-byte header + 4-byte trailer)
- Header contains: destination MAC (6 bytes), source MAC (6 bytes), EtherType (2 bytes)
- Trailer contains: Frame Check Sequence (4-byte CRC)
- Now you have a Frame:
[Eth header][IP header][TCP header][Hello!][FCS]= 63 bytes
Step 5: Physical transmits as bits
- The frame is converted to electrical signals, light pulses, or radio waves
- Now it is Bits: 63 bytes x 8 = 504 bits transmitted
At the destination, decapsulation reverses this process:
- Physical receives bits and reconstructs Frame
- Data Link checks FCS, strips Ethernet header and trailer, passes Packet up
- Network checks IP address, strips IP header, passes Segment up
- Transport checks sequence, strips TCP header, passes Data up
- Application receives “Hello!” (original 5 bytes)
Key Insight: Your 5-byte message became 63 bytes on the wire – that is 92% overhead (only 8% of the transmitted data is your actual message). This is why IoT uses header compression.
30.5 Protocol Data Units (PDUs)
As data moves through the protocol stack, it receives different names reflecting its structure at each layer.
30.5.1 PDU Names by Layer
| Layer | PDU Name | Contains |
|---|---|---|
| Application | Data | Raw application data (email, file, sensor reading) |
| Transport | Segment (TCP) or Datagram (UDP) | Data + port numbers + sequence/length info |
| Internet | Packet | Segment/datagram + source/destination IP addresses |
| Network Access | Frame | Packet + source/destination MAC addresses + error check |
| Physical | Bits | Electronic, radio, or optical signals |
30.5.2 Visualizing the Data Journey
When you send “Hello!” to a smart device, each layer wraps and unwraps the data:
SENDING (Your Phone) RECEIVING (Smart Device)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
APP: "Hello!" APP: "Hello!"
| add MQTT header ^ remove MQTT
TRANS: [TCP][Hello!] TRANS: [TCP][Hello!]
| add IP header ^ remove IP
NET: [IP][TCP][Hello!] NET: [IP][TCP][Hello!]
| add Wi-Fi header ^ remove Wi-Fi
LINK: [Wi-Fi][IP][TCP][Hello!] LINK: [Wi-Fi][IP][TCP][Hello!]
| ^
PHYS: ~~~radio waves~~~ >>> PHYS: ~~~radio waves~~~
30.6 IoT Example: Temperature Sensor
A temperature sensor sends a reading to the cloud. This example uses a constrained IoT protocol stack with CoAP over UDP (not TCP) to minimize overhead.
| Layer | What Happens | Protocol Used |
|---|---|---|
| Application | Format: {"temp": 72} |
CoAP |
| Transport | Add port numbers, length, checksum | UDP |
| Network | Add compressed IPv6 addresses | 6LoWPAN |
| Data Link | Add device MAC addresses | 802.15.4 MAC |
| Physical | Convert to radio signal | 2.4 GHz radio |
Application Layer Data:
{
"sensor_id": "TEMP-001",
"temperature": 22.5,
"humidity": 45.0,
"timestamp": "2025-10-25T10:30:00Z"
}After each layer adds headers:
- Data: CoAP header (4 bytes) wraps the JSON payload
- Datagram: UDP header (8 bytes) adds source/destination port and checksum
- Packet: 6LoWPAN-compressed IPv6 header (~6 bytes) adds device and gateway addresses
- Frame: 802.15.4 MAC header + FCS (~25 bytes) adds hardware addresses and error check
- Bits: Transmitted as 2.4 GHz radio signals
Total journey: 5 layers down at the sensor, over the air, 5 layers up at the gateway, then through the internet to the cloud.
30.7 Encapsulation and Decapsulation
Encapsulation (sending): Headers and trailers are progressively added as data moves DOWN the layers. Each layer treats everything it receives from above as its payload.
Decapsulation (receiving): Headers and trailers are progressively removed as data moves UP the layers. Each layer strips its own header and passes the contents to the layer above.
30.7.1 The Jacket Analogy
Sending an email – data moves through layers like putting on jackets:
- Each layer puts a “jacket” on the data (with zippers/buttons representing protocol rules)
- The equivalent layer at the destination knows how to remove that jacket
- Only layers at the same level understand each other’s jackets
Headers contain control and management information:
- Addressing (where to send)
- Sequencing (order of packets)
- Error checking (data integrity)
- Protocol identification (what is inside)
30.8 Byte-Level Analysis: Understanding Overhead
30.8.1 Detailed Frame Structure
30.8.2 Header Overhead Calculation
| Component | Size | Purpose |
|---|---|---|
| Ethernet Header | 14 bytes | Dest MAC (6) + Src MAC (6) + EtherType (2) |
| IP Header | 20 bytes min | Version, length, TTL, addresses, etc. |
| TCP Header | 20 bytes min | Ports, sequence numbers, flags, etc. |
| Frame Check Sequence | 4 bytes | Error detection (CRC-32) |
| Total Overhead | 58 bytes | Before any payload! |
For IoT implications:
- A 10-byte sensor reading becomes 68+ bytes on the wire
- That is 85% overhead for small payloads (58 / 68 = 85.3%)
- This is why IoT protocols like 6LoWPAN compress IPv6 headers from 40 bytes down to 2-6 bytes
30.9 Visual Reference Gallery
Additional Protocol Stack Visualizations
30.9.1 Protocol Layers and PDUs
30.9.2 Ethernet Frame Structure
30.9.3 Header Compression Comparison
30.10 Concept Relationships
Understanding how encapsulation concepts relate helps you optimize IoT protocol stacks:
| Concept | Depends On | Affects | Common Tradeoff |
|---|---|---|---|
| Encapsulation | Layer architecture | Total packet size, processing time | More layers = more overhead |
| PDU Naming | Layer position | Documentation clarity, troubleshooting | Different models use different names |
| Header Size | Protocol features | Bandwidth efficiency, battery life | Rich features = larger headers |
| 6LoWPAN Compression | Context knowledge, stable addresses | Payload ratio, processing cost | Compression saves bandwidth but adds CPU cycles |
| Payload Ratio | Header sizes, payload size | Energy per useful byte | Small payloads suffer most from overhead |
| MTU (Maximum Transmission Unit) | Physical layer limits | Fragmentation needs, efficiency | Smaller MTU = more fragmentation |
Key Insight: For a 10-byte sensor reading, standard TCP/IP overhead (58 bytes) means only 15% of transmitted data is useful. This is why IoT protocols like 6LoWPAN (compresses 40-byte IPv6 to 2-6 bytes) and CoAP (4-byte header vs HTTP’s 200+ bytes) are essential for battery-powered devices.
30.11 See Also
Explore related networking concepts:
- IoT Reference Models - How IoT extends traditional networking with edge computing layers
- 6LoWPAN Fundamentals - Header compression techniques for IPv6 over constrained networks
- CoAP Protocol - Lightweight application protocol designed for IoT with minimal overhead
- MQTT Architecture - Pub/sub messaging protocol and its place in the protocol stack
- Transport Protocols - TCP vs UDP tradeoffs for reliability and overhead
Common Pitfalls
1. Confusing Encapsulation Direction With Data Direction
Encapsulation adds headers as data moves DOWN the stack at the sender. Decapsulation strips headers as data moves UP at the receiver. Fix: draw arrows showing both directions on a protocol stack diagram before answering any encapsulation question.
2. Forgetting That Each Layer Only Reads Its Own Header
The IP layer at the receiver reads the IP header but passes the TCP segment inside unchanged to the transport layer. Fix: understand each layer’s scope: it adds/removes its own header and passes the rest intact.
3. Mixing Up PDU Names Across Layers
Calling an IP packet a “frame” or a TCP segment a “packet” suggests a misunderstanding of layer boundaries. Fix: memorise the PDU name for each layer: frame (L2), packet (L3), segment (L4), message (L7).
30.12 Summary
This chapter covered how data is transformed as it moves through the protocol stack:
- Encapsulation adds headers progressively as data moves DOWN the stack (Data to Segment to Packet to Frame to Bits), with each layer wrapping the previous layer’s output
- Decapsulation removes headers progressively as data moves UP the stack, with each layer stripping its header and passing contents to the layer above
- Protocol Data Units (PDUs) have specific names: Application data becomes Transport segment/datagram, then Network packet, then Data Link frame, finally Physical bits
- Header overhead is significant: Standard TCP/IP over Ethernet adds 58 bytes to every message, meaning a 10-byte sensor reading is 85% overhead – this is why IoT uses header compression techniques like 6LoWPAN
- Each header contains control information: addressing (where to send), sequencing (packet order), error checking (integrity), and protocol identification (what is inside)
30.13 Try It Yourself
30.14 What’s Next
Continue your exploration of layered network models and IoT protocol stacks:
| Topic | Chapter | Description |
|---|---|---|
| IoT Reference Models | IoT Reference Models | Explore IoT-specific layered architectures including the ITU-T model and Cisco 7-Level reference model, and how they extend traditional networking |
| OSI and TCP/IP Models | OSI and TCP/IP Models | Deepen your understanding of the OSI 7-layer and TCP/IP 4-layer models that define where encapsulation occurs |
| Labs and Implementation | Layered Models: Labs and Implementation | Hands-on practice with MAC/IP addressing, ARP analysis, and Python socket programming to observe encapsulation in action |
| 6LoWPAN Header Compression | 6LoWPAN Fundamentals | Study the IPHC compression scheme that reduces 40-byte IPv6 headers to 2-6 bytes for constrained IoT networks |
| CoAP Application Protocol | CoAP Fundamentals | Learn how CoAP’s 4-byte header and REST-over-UDP design minimizes application-layer overhead on constrained devices |
| Layered Models Review | Layered Models: Review | Test your understanding of encapsulation, PDU naming, and overhead calculations with comprehensive knowledge checks |