70  802.15.4 Frame Structure

In 60 Seconds

IEEE 802.15.4 MAC frames have a maximum size of 127 bytes with variable overhead (5-44 bytes) depending on addressing mode and security level. Short 16-bit addressing with PAN ID compression minimizes overhead, while AES-128 CCM security (levels 0-7) provides configurable authentication and encryption at the cost of additional frame space.

70.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Deconstruct Frame Structure: Break down each MAC frame field, identifying its size, bit-level encoding, and role in the 127-byte budget
  • Calculate Overhead: Compute addressing and security overhead for any combination of addressing mode, security level, and key identifier mode
  • Evaluate Security Levels: Compare the eight AES-128 CCM security levels and justify which level fits a given application’s threat model and payload constraints
  • Optimize Payload Efficiency: Design frame configurations that maximize usable payload while meeting authentication and encryption requirements

Every 802.15.4 message has a specific structure called a frame, containing the data plus headers for addressing and security. This review examines how frames are constructed, what each field means, and how the security layer protects data. Understanding frames helps you analyze and debug wireless IoT communications.

“Every message we send has a special envelope!” explained Max the Microcontroller, holding up a tiny packet. “It is called a frame, and it has to fit in just 127 bytes – like writing a postcard instead of a long letter.”

Sammy the Sensor peeked inside. “What is all this extra stuff around my temperature reading?” Max pointed to each section. “The first part is the address – who sent it and who should receive it. Then there is your actual data. And finally, a checksum to make sure nothing got scrambled during transmission.”

“But what about security?” asked Bella the Battery nervously. “I do not want strangers reading our messages!” Lila the LED lit up reassuringly. “That is where AES-128 encryption comes in! It is like putting your postcard inside a locked box. Only devices with the right key can open it. The trade-off is that the lock takes up some of our precious 127 bytes, so there is less room for data.”

“So we have to balance security against payload size,” Sammy nodded. “More security means less room for my sensor readings. It is all about picking the right level of protection for each application!”

70.2 Prerequisites

Required Chapters:

  • Frame Control Field: 2-byte bitfield in MAC header specifying frame type, security enabled, pending bit, ACK request, and addressing modes
  • Sequence Number: 1-byte field incremented per frame; used to match ACKs to transmitted frames and detect duplicates
  • Auxiliary Security Header: Added to frame when security is enabled; contains security control byte and frame counter (4B), plus optional key identifier
  • MIC (Message Integrity Code): 4, 8, or 16-byte authentication tag generated by CBC-MAC; verifies data authenticity
  • Encrypted Payload: The MSDU portion encrypted using AES-CTR mode when confidentiality is enabled
  • Frame Type Values: 000=Beacon, 001=Data, 010=ACK, 011=MAC Command; encoded in frame control bits 0-2
  • Security Control Byte: Specifies security level (3 bits) and key identifier mode (2 bits) within the auxiliary security header
  • Anti-Replay Window: Receiver-side counter comparison rejecting frames with counter values below stored maximum

Estimated Time: 15 minutes

70.4 MAC Frame Format

The 802.15.4 MAC frame structure is critical for understanding overhead and efficiency. The maximum frame size is 127 bytes, making efficient use of every byte essential for low-power wireless networks.

Diagram of IEEE 802.15.4 MAC frame structure showing Frame Control, Sequence Number, variable addressing fields, optional security header, payload, and FCS within a 127-byte maximum
Figure 70.1: IEEE 802.15.4 MAC frame structure with variable addressing and optional security

70.4.1 Frame Components

Field Size Purpose
Frame Control 2 bytes Frame type, addressing modes, security flag
Sequence Number 1 byte Frame identification for ACK matching
Addressing Fields 4-20 bytes Destination and source addresses
Security Header 0-14 bytes Security control, frame counter, key ID
Payload 0-102 bytes Application data
FCS 2 bytes 16-bit CRC for error detection

70.4.2 Frame Control Field Breakdown

The 2-byte Frame Control field contains critical information about the frame:

Bits Field Values Purpose
0-2 Frame Type 000=Beacon, 001=Data, 010=ACK, 011=MAC Cmd Identifies frame purpose
3 Security Enabled 0=No, 1=Yes Indicates encryption/auth
4 Frame Pending 0=No, 1=Yes More data available
5 ACK Request 0=No, 1=Yes Sender wants ACK
6 PAN ID Compression 0=No, 1=Yes Reduces overhead
7-9 Reserved - Future use
10-11 Dest Addr Mode 00=None, 10=Short, 11=Extended Address type
12-13 Frame Version 00=2003, 01=2006 Standard version
14-15 Source Addr Mode 00=None, 10=Short, 11=Extended Address type

70.4.3 Frame Types

IEEE 802.15.4 defines four frame types:

Frame Type Code Purpose Typical Size
Beacon 000 Synchronization, network info 15-25 bytes
Data 001 Application payload Variable
ACK 010 Delivery confirmation 5 bytes
MAC Command 011 Network operations 10-25 bytes

70.5 Addressing Field Variations

The addressing overhead varies significantly based on network configuration. Understanding these variations is essential for optimizing frame efficiency.

70.5.1 Addressing Modes

802.15.4 supports three addressing modes:

Mode Code Size Use Case
No Address 00 0 bytes ACK frames
Short Address 10 2 bytes Network-local addressing
Extended Address 11 8 bytes Globally unique addressing

70.5.2 Addressing Overhead Comparison

Scenario Dest PAN Dest Addr Src PAN Src Addr Total Overhead
Intra-PAN Short 2 bytes 2 bytes Omitted 2 bytes 6 bytes
Intra-PAN Extended 2 bytes 8 bytes Omitted 8 bytes 18 bytes
Inter-PAN Short 2 bytes 2 bytes 2 bytes 2 bytes 8 bytes
Inter-PAN Extended 2 bytes 8 bytes 2 bytes 8 bytes 20 bytes
ACK Frame 0 0 0 0 0 bytes

70.5.3 PAN ID Compression

When bit 6 (PAN ID Compression) is set to 1:

  • Both source and destination are within the same PAN
  • Source PAN ID is omitted from the frame
  • Saves 2 bytes per frame

When to use:

  • Always use within a single PAN
  • Disable only for inter-PAN communication or border routers

70.5.4 Efficiency Calculation

Understanding frame efficiency helps with capacity planning:

Configuration Fixed Overhead Max Payload Efficiency
Minimum (ACK) 5 bytes 0 bytes N/A
Short addr, no security 11 bytes 116 bytes 91.3%
Short addr, max security 32 bytes 95 bytes 74.8%
Extended addr, no security 23 bytes 104 bytes 81.9%
Extended addr, max security 44 bytes 83 bytes 65.4%

Formula:

Available Payload = 127 - FC(2) - Seq(1) - AddrFields - SecHeader - FCS(2)
Efficiency = Payload / 127 * 100%

70.5.5 Knowledge Check: Frame Overhead Calculation

70.6 Security Architecture

IEEE 802.15.4 provides link-layer security using AES-128 encryption. Security is optional but highly recommended for most IoT deployments.

70.6.1 Security Header Format

When security is enabled, additional overhead is added:

Field Size Purpose
Security Control 1 byte Security level and key identifier mode
Frame Counter 4 bytes Replay attack prevention
Key Identifier 0-9 bytes Which key to use (variable)
Message Integrity Code (MIC) 0, 4, 8, or 16 bytes Authentication tag

70.6.2 Security Control Byte

Bits Field Description
0-2 Security Level 0-7, determines encryption and MIC
3-4 Key Identifier Mode 0-3, determines key lookup method
5-7 Reserved Future use

70.6.3 Security Levels

IEEE 802.15.4 defines 8 security levels:

Level Name Encryption MIC Size Security Properties
0 None No 0 None
1 MIC-32 No 4 bytes Auth only
2 MIC-64 No 8 bytes Auth only
3 MIC-128 No 16 bytes Auth only
4 ENC Yes 0 Confidentiality only
5 ENC-MIC-32 Yes 4 bytes Auth + Confidentiality
6 ENC-MIC-64 Yes 8 bytes Auth + Confidentiality
7 ENC-MIC-128 Yes 16 bytes Maximum security

70.6.4 Security Level Selection Guide

Flowchart showing security level selection based on confidentiality and authentication requirements. Level 5 (ENC-MIC-32) recommended for most applications, Level 7 (ENC-MIC-128) for maximum security.
Figure 70.2: Security level selection decision tree for IEEE 802.15.4

70.6.6 Key Identifier Modes

Mode Size Key Source Use Case
0 0 bytes Implicit (from sender address) Simple networks
1 1 byte Key index (0-255) Small key sets
2 5 bytes Key source (4) + index (1) Larger networks
3 9 bytes Full key source (8) + index (1) Cross-network

70.6.7 Security Overhead Summary

Security Level MIC Size Min Security Header Total Overhead
Level 0 0 0 bytes 0 bytes
Level 1 4 bytes 5 bytes 9 bytes
Level 5 4 bytes 5 bytes 9 bytes
Level 7 16 bytes 5 bytes 21 bytes
Level 7 + Key ID Mode 3 16 bytes 14 bytes 30 bytes

For a 50-byte sensor payload with Security Level 5 (ENC-MIC-32), calculate the total frame size and payload efficiency:

\[ \text{Total Frame} = 2 + 1 + 6 + 5 + 50 + 4 + 2 = 70 \text{ bytes} \]

Where: Frame Control (2) + Sequence (1) + Addressing (6) + Security (5) + Payload (50) + MIC (4) + FCS (2).

Payload efficiency: \(50 / 70 = 71.4\%\). If we used no security, the frame would be 61 bytes, giving \(50/61 = 82\%\) efficiency. The 9-byte security overhead costs 10.6% of efficiency but provides encryption and authenticated delivery critical for IoT actuator control.

70.7 Frame Efficiency Examples

70.7.1 Example 1: Temperature Sensor (Optimized)

A temperature sensor sending 2-byte readings:

Component Size Notes
Frame Control 2 bytes Data frame, short addresses
Sequence Number 1 byte
Dest PAN ID 2 bytes
Dest Short Address 2 bytes Coordinator
Source Short Address 2 bytes PAN ID compression
Payload 2 bytes Temperature reading
FCS 2 bytes
Total 13 bytes 15.4% payload efficiency

70.7.2 Example 2: With Security (Level 5)

Same sensor with ENC-MIC-32 security:

Component Size Notes
Frame Control 2 bytes Security enabled
Sequence Number 1 byte
Addressing 6 bytes Intra-PAN short
Security Control 1 byte Level 5, mode 0
Frame Counter 4 bytes Anti-replay
Payload (encrypted) 2 bytes Temperature
MIC 4 bytes Authentication
FCS 2 bytes
Total 22 bytes 9.1% payload efficiency

70.7.3 Example 3: Maximum Payload

Maximizing data transfer per frame:

Configuration Available Payload
Short addr, no security 116 bytes
Short addr, Level 5 107 bytes
Extended addr, no security 104 bytes
Extended addr, Level 7 83 bytes

70.9 Real-World Deployment: Frame Optimization in Smart Grid

70.9.1 Pacific Gas & Electric (PG&E): 10.4 Million Smart Meters on 802.15.4

PG&E’s SmartMeter program, covering 10.4 million electric and gas meters across Northern California, runs on Silver Spring Networks (now Itron) mesh infrastructure using IEEE 802.15.4 at the MAC layer. The frame optimization decisions made during the 2006-2012 rollout directly reflect the trade-offs covered in this chapter.

Addressing mode selection:

PG&E’s network uses short (16-bit) addressing with PAN ID compression for all intra-mesh communication, saving 14 bytes per frame compared to extended addressing:

Configuration evaluated Address overhead Payload available Result
Extended address, no PAN compression 20 bytes 84 bytes (with Level 5 security) Rejected – insufficient for 96-byte meter reads
Extended address, PAN compression 18 bytes 86 bytes Rejected – still marginal
Short address, PAN compression 6 bytes 98 bytes Deployed – 96-byte reads fit in single frame

The 96-byte meter reading payload includes: 4-byte meter ID, 4-byte timestamp, 48 bytes of interval data (24 hourly readings x 2 bytes each), 32 bytes of power quality metrics, and 8 bytes of tamper detection flags. If this payload required fragmentation into two frames, the mesh network’s 15-20% per-hop loss rate would compound: a single frame over 4 hops at 80% per-hop success has 0.80^4 = 41.0% delivery probability, while a 2-fragment message requires both fragments to arrive, giving (0.804)2 = 16.8% delivery probability – a 59% reduction in reliability.

Security level deployment decision:

PG&E selected Security Level 5 (ENC-MIC-32) rather than Level 7 (ENC-MIC-128), despite California Public Utilities Commission recommendations for maximum security. The engineering rationale:

Security Level Overhead Payload capacity Protection
Level 5 (ENC-MIC-32) 9 bytes 98 bytes AES-128 encryption + 32-bit authentication
Level 7 (ENC-MIC-128) 21 bytes 86 bytes AES-128 encryption + 128-bit authentication
Difference 12 bytes 12 fewer bytes MIC forgery: 1 in 4.3B vs 1 in 3.4x10^38

The 4-byte MIC (Level 5) provides 1 in 4.3 billion forgery probability per packet. Given the network processes approximately 150 million frames per day, a brute-force MIC forgery attack would succeed on average once every 28 days – but the frame counter (4-byte anti-replay) invalidates any forged frame with a stale counter, adding a second defense layer. Level 7’s 128-bit MIC offers theoretically superior protection but costs 12 bytes of payload, which would have forced the 96-byte meter reading into two fragments and reduced network capacity by approximately 40%.

Lesson learned: Frame counter rollover planning:

The 4-byte frame counter (2^32 = 4.29 billion frames) created an unexpected operational challenge. High-traffic relay nodes in the mesh forward 2,000-5,000 frames per hour. At 5,000 frames/hour, the counter exhausts in:

4,294,967,296 / 5,000 / 24 / 365 = 98 years (no problem)

But during network recovery events (storm outages, firmware upgrades), relay nodes can burst 50,000 frames/hour, and some relay nodes in dense urban areas accumulate 1.8 billion counter values over their 15-year deployment life. PG&E’s solution: re-key relay nodes at 1 billion frame counter (approximately 50% of capacity), triggered by the network management system monitoring frame counter values reported in monthly diagnostic packets.

Scenario: An industrial vibration sensor needs to send 80 bytes of FFT spectrum data every second using 802.15.4 with Security Level 5 (ENC-MIC-32) for authenticated encryption.

Frame budget calculation:

Note: The 127-byte maximum is the MAC frame size (MPDU). PHY overhead (preamble, SFD, length byte) is added by the physical layer and is not counted against the 127-byte limit.

Maximum 802.15.4 MAC frame:    127 bytes
Frame Control:                  -2 bytes
Sequence Number:                -1 byte
Dest PAN ID:                    -2 bytes
Dest Short Address:             -2 bytes
Source Short Address:           -2 bytes (PAN ID compression)
Security Control:               -1 byte
Frame Counter:                  -4 bytes
MIC-32:                         -4 bytes
FCS:                            -2 bytes
─────────────────────────────────────────
Available payload:              107 bytes

Result: 80 bytes fits in a single frame with 27 bytes to spare. No fragmentation needed.

Efficiency calculation:

  • Security overhead = 1 + 4 + 4 = 9 bytes
  • Without security, overhead would be 11 bytes (addressing + FC + seq + FCS)
  • Security adds only 9 bytes (7.1% of frame) but provides AES-128 encryption + 32-bit authentication

Comparison to Security Level 7 (ENC-MIC-128):

  • Level 7 MIC: 16 bytes instead of 4 bytes
  • Available payload: 107 - 12 = 95 bytes (would still fit the 80-byte payload)
  • Level 7 adds 12 bytes of overhead (forgery probability 1 in 3.4×10^38 vs 1 in 4.3 billion for Level 5)

Takeaway: For this 80-byte payload, both Level 5 and Level 7 fit in a single frame, but Level 5’s 4-byte MIC is sufficient for most industrial applications where frame counters prevent replay attacks.

Application Recommended Security Level Reasoning
Non-critical monitoring (weather station, parking sensors) Level 0 (None) or Level 1 (MIC-32 auth only) Low-value data; energy cost of encryption not justified
Home automation (lights, switches, HVAC) Level 5 (ENC-MIC-32) Balance: AES-128 encryption + 32-bit auth (1 in 4.3B forgery), only 9-byte overhead
Industrial control (actuators, motor controllers) Level 6 or 7 (ENC-MIC-64/128) High-stakes operations where unauthorized commands could cause equipment damage or safety hazards; stronger MIC justified
Healthcare/medical (patient monitors, insulin pumps) Level 7 (ENC-MIC-128) Regulatory compliance (FDA requires strong encryption); 16-byte MIC prevents forgery attacks on life-critical commands
Financial/metering (smart meters, payment devices) Level 7 (ENC-MIC-128) Billing data integrity crucial; utilities face financial fraud if meters can be tampered with
Multi-hop mesh (Zigbee, Thread networks) Level 5 Balance security with re-transmission overhead in mesh; each hop adds latency and energy cost

PG&E case study validation: PG&E’s choice of Level 5 for 10.4 million smart meters aligns with the framework: encryption protects billing data, 32-bit MIC provides 1 in 4.3 billion forgery probability per frame, and frame counter (4-byte anti-replay) adds a second defense layer. Level 7’s 128-bit MIC would have forced the 96-byte meter reading into two fragments, reducing network capacity by ~40% without meaningful security improvement given the frame counter protection.

Common Mistake: Ignoring Key Identifier Mode Impact on Security Overhead

The Error: A developer configures Security Level 7 (ENC-MIC-128) but overlooks that the selected Key Identifier Mode adds 9 bytes of overhead, consuming 30 bytes total and fragmenting what should have been a single-frame payload.

Configuration that failed:

securityControl = {
    .securityLevel = 7,        // ENC-MIC-128: 1 + 4 + 16 = 21 bytes
    .keyIdMode = 3             // Full key source (8) + index (1) = 9 bytes
};
// Total security overhead: 21 + 9 = 30 bytes

Why it matters:

  • Payload was 95 bytes
  • Available space: 127 - 11 (MAC) - 30 (security) - 2 (FCS) = 84 bytes
  • 95-byte payload requires fragmentation into 2 frames
  • Fragmentation adds 4-byte header to second frame
  • Airtime doubles, energy consumption increases 2x, reliability drops (single lost fragment fails entire message)

The fix: Use Key ID Mode 0 (implicit key from source address):

securityControl = {
    .securityLevel = 7,        // ENC-MIC-128: 21 bytes
    .keyIdMode = 0             // Implicit: 0 bytes
};
// Total security overhead: 21 bytes
// Available payload: 127 - 11 - 21 - 2 = 93 bytes (95-byte payload still needs fragmentation)

Better fix for this payload size: Drop to Security Level 6 (ENC-MIC-64) with Key ID Mode 0:

securityControl = {
    .securityLevel = 6,        // ENC-MIC-64: 1 + 4 + 8 = 13 bytes
    .keyIdMode = 0             // Implicit: 0 bytes
};
// Available payload: 127 - 11 - 13 - 2 = 101 bytes (fits the 95-byte payload!)

Lesson: Security level alone doesn’t determine overhead. Key Identifier Mode can add 0-9 bytes. Always calculate total security header size before selecting configuration.

70.10 Concept Relationships

Understanding how frame components relate to each other:

Concept Builds On Enables
Frame Control Field MAC header structure Addressing mode selection, security flag
Short Addressing 16-bit addresses PAN ID compression, minimal overhead
Security Level 5 AES-128 CCM Frame counter, 32-bit MIC
Payload Efficiency Addressing + security overhead Maximum application data
Frame Counter Security header Replay attack prevention

Common Pitfalls

The pending bit in frame control indicates the sender has more data for the recipient. End devices must send a Data Request frame after receiving a frame with pending=1 to retrieve the next queued message. Ignoring this bit causes data to pile up at the coordinator.

Frame type is encoded in bits [2:0] of frame control — not the full byte. When parsing raw frames, masking only bits [2:0] before comparing to frame type constants is critical. Using the full byte for comparison yields incorrect frame type identification.

The auxiliary security header length varies: always 5 bytes for security control + frame counter, plus 0, 1, 5, or 9 bytes for key identifier depending on key identifier mode. Assuming a fixed 5-byte security header causes incorrect payload offset calculations.

802.15.4 security levels 1-3 provide MIC only (no encryption); levels 5-7 add encryption. Level 4 is encryption without authentication — the least secure mode that includes encryption. Confusing these leads to incorrect security overhead calculations and false assumptions about confidentiality.

70.11 Summary

This chapter covered the frame structure and security mechanisms of IEEE 802.15.4:

  • Frame Structure: Maximum 127 bytes with variable overhead (5-44 bytes) depending on addressing and security
  • Addressing Modes: Short (2 bytes), Extended (8 bytes), or None; PAN ID compression saves 2 bytes for intra-PAN
  • Security Levels: Eight levels (0-7) providing various combinations of encryption and authentication
  • AES-128: All encryption uses AES-128 in CCM mode for authenticated encryption
  • Overhead Trade-offs: Security Level 5 (ENC-MIC-32) offers good balance for most applications
  • Frame Counter: 4-byte counter prevents replay attacks but limits to ~4 billion frames per key

70.12 Knowledge Check

70.12.1 Knowledge Check: PAN ID Compression

70.12.2 Knowledge Check: Security Level Selection

70.13 See Also

Related Topics:

70.14 What’s Next

Chapter Focus
Network Operations Device types (FFD vs RFD), network topologies, and CSMA-CA channel access mechanism
Protocols and Performance Higher-layer protocols (Zigbee, Thread, 6LoWPAN) built on 802.15.4 and real-world throughput analysis
802.15.4 Topic Review Comprehensive review hub with practice questions across all 802.15.4 topics
IoT Security Fundamentals Broader IoT threat landscape and security principles beyond link-layer protection