Loading learning content...
Every WiFi transmission, from a simple beacon announcement to a multi-gigabit video stream, is encapsulated within the carefully designed structure of an IEEE 802.11 frame. Unlike Ethernet's relatively simple 14-byte header, the 802.11 MAC header is variable in length (ranging from 24 to 36 bytes) and context-sensitive (fields change meaning based on frame type and direction).
This complexity is not arbitrary—it reflects the fundamental requirements of wireless communication: handling multiple address scenarios (station-to-AP, AP-to-station, WDS links, ad-hoc), supporting quality of service, enabling aggregation and high throughput, and maintaining protocol compatibility across two decades of evolving standards.
Mastering the frame structure enables you to read raw packet captures, understand protocol behavior at the bit level, and diagnose issues that manifest only when examining frame fields directly.
By the end of this page, you will understand every field of the 802.11 MAC header in detail, including the Frame Control field's 16 individual bits, the Duration/ID field's multiple uses, the Sequence Control field's role in reassembly and duplicate detection, and the conditional presence of QoS Control and HT Control fields.
The general structure of an 802.11 frame consists of three main components: the MAC Header, the Frame Body (payload), and the Frame Check Sequence (FCS). The following diagram shows the complete structure:
┌─────────────────────────────────────────────────────────────────────────────────┐│ IEEE 802.11 MAC Frame │├─────────────────────────────────────────────────────────────────────────────────┤│ MAC Header (24-36 bytes) │ Frame Body │ FCS ││ │ (0-7951 bytes) │(4 bytes)│├─────────────────────────────────┼──────────────────┼─────────┤│ ┌─────────────┬──────────────┐ │ │ ││ │Frame Control│Duration/ID │ │ │ ││ │ (2 bytes) │(2 bytes) │ │ │ ││ ├─────────────┼──────────────┤ │ │ ││ │Address 1 │Address 2 │ │ Encrypted or │ CRC-32 ││ │(6 bytes) │(6 bytes) │ │ Unencrypted │ ││ ├─────────────┼──────────────┤ │ Payload │ ││ │Address 3 │Sequence Ctrl │ │ │ ││ │(6 bytes) │(2 bytes) │ │ (Data frames, │ ││ ├─────────────┼──────────────┤ │ Management │ ││ │Address 4* │QoS Control* │ │ frames, etc.) │ ││ │(6 bytes) │(2 bytes) │ │ │ ││ ├─────────────┴──────────────┤ │ │ ││ │HT Control* (4 bytes) │ │ │ ││ └────────────────────────────┘ │ │ │└─────────────────────────────────┴──────────────────┴─────────┘ * Optional fields depending on frame type and flags: - Address 4: Present only when To DS=1 AND From DS=1 (WDS mode) - QoS Control: Present in QoS Data frames (subtype 8-15 of data) - HT Control: Present when Order bit=1 (802.11n+ control information)MAC Header Size Variations:
| Configuration | Header Size | Fields Present |
|---|---|---|
| Minimum (Management, Control) | 24 bytes | FC + Duration + Addr1 + Addr2 + Addr3 + SeqCtrl |
| Standard Data | 24 bytes | Same as above |
| WDS Data | 30 bytes | + Address 4 |
| QoS Data | 26 bytes | + QoS Control |
| QoS WDS | 32 bytes | + Address 4 + QoS Control |
| HT Data | 28-30 bytes | + HT Control |
| Full Header | 36 bytes | All fields present |
Before the MAC frame, the Physical Layer adds its own preamble and header (PLCP). This includes the Short Training Field (STF), Long Training Field (LTF), and Signal field for synchronization and rate indication. These are not part of the MAC layer view but are visible in radio-frequency captures.
The Frame Control (FC) field is the most information-dense field in the 802.11 header. Its 16 bits control every aspect of frame processing. Let's examine each bit position in detail:
Frame Control Field (16 bits / 2 bytes)Note: Transmitted LSB first within each byte Byte 0 (transmitted first): Byte 1:┌───┬───┬───┬───┬───┬───┬───┬───┐ ┌───┬───┬───┬───┬───┬───┬───┬───┐│b0 │b1 │b2 │b3 │b4 │b5 │b6 │b7 │ │b8 │b9 │b10│b11│b12│b13│b14│b15│├───┼───┼───┼───┼───┼───┼───┼───┤ ├───┼───┼───┼───┼───┼───┼───┼───┤│Protocol │Type│ Subtype │ │ToDS│From│More│Retry│Pwr│More│Prot│Ord││Version │ │ │ │ │ DS │Frag│ │Mgt│Data│Frm │er ││ (00) │ │ │ │ │ │ │ │ │ │ │ │└───┴───┴───┴───┴───┴───┴───┴───┘ └───┴───┴───┴───┴───┴───┴───┴───┘ └──┬──┘ └─┬─┘ └──────┬────────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ │ │ │ Direction Frag Retry Pwr More Encrypted │ │ │ Indicators Flag Flag Mgmt Data Flag │ │ │ │ │ └──► Subtype (4 bits): 16 possible subtypes per type │ └─────────────► Type (2 bits): 00=Mgmt, 01=Ctrl, 10=Data, 11=Rsvd └────────────────────► Version (2 bits): Always 00 for current standard| Bits | Field Name | Values/Meaning |
|---|---|---|
| 0-1 | Protocol Version | Always 00 (version 0); other values reserved for future |
| 2-3 | Type | 00=Management, 01=Control, 10=Data, 11=Extension |
| 4-7 | Subtype | 16 subtypes per type (e.g., 0000=Association Request) |
| 8 | To DS | 1 if frame directed to Distribution System (AP) |
| 9 | From DS | 1 if frame originates from Distribution System |
| 10 | More Fragments | 1 if more fragments follow this one |
| 11 | Retry | 1 if this is a retransmission of an earlier frame |
| 12 | Power Management | 1 if station will enter power-save after this frame |
| 13 | More Data | 1 if AP has more buffered frames for this station |
| 14 | Protected Frame | 1 if frame body is encrypted (WEP/TKIP/CCMP) |
| 15 | Order | 1 if HT Control field present (802.11n+) |
Understanding To DS and From DS Bits:
These two bits encode the direction of the frame and determine how to interpret the four address fields:
| To DS | From DS | Scenario | Address Interpretation |
|---|---|---|---|
| 0 | 0 | IBSS (Ad-hoc) or Management | Addr1=DA, Addr2=SA, Addr3=BSSID |
| 0 | 1 | AP to Station | Addr1=DA, Addr2=BSSID, Addr3=SA |
| 1 | 0 | Station to AP | Addr1=BSSID, Addr2=SA, Addr3=DA |
| 1 | 1 | WDS (AP to AP) | Addr1=RA, Addr2=TA, Addr3=DA, Addr4=SA |
Key Insight: In infrastructure mode, the BSSID (AP's MAC address) is always in the frame, but its position changes based on direction. This allows APs to quickly identify frames destined for their BSS.
The Retry bit is critical for duplicate detection. If a receiver gets a frame and sends an ACK that's lost, the sender will retransmit. The receiver uses the Retry bit combined with Sequence Control to identify and discard duplicates. High retry rates in captures indicate RF interference, distance issues, or congestion.
The Duration/ID field serves dual purposes depending on the frame type. Its 16 bits can represent either a duration value for NAV (Network Allocation Vector) calculation or an Association ID for PS-Poll frames.
Bit Interpretation:
Duration/ID Field (16 bits) Bit 15 = 0: Duration Mode┌─────────────────────────────────────────────────────────────────┐│ Bits 0-14: Duration value in microseconds (0-32767 μs) ││ ││ This is the time required to complete the frame exchange. ││ All stations hearing this update their NAV to MAX(NAV, value). ││ ││ Example: For a data frame, duration includes: ││ - Time to transmit remaining fragments ││ - SIFS intervals ││ - ACK transmission time │└─────────────────────────────────────────────────────────────────┘ Bit 15 = 1, Bit 14 = 0: Association ID Mode (PS-Poll frames)┌─────────────────────────────────────────────────────────────────┐│ Bits 0-13: Association ID (1-2007) ││ Bit 14: 0 ││ Bit 15: 1 ││ ││ Used in PS-Poll frames to identify the polling station. ││ AID value matches what AP assigned during association. │└─────────────────────────────────────────────────────────────────┘ Bit 15 = 1, Bit 14 = 1: Fixed Duration┌─────────────────────────────────────────────────────────────────┐│ Value 32768 (0x8000): Duration = 0 (no NAV update) ││ Used in CFP (Contention-Free Period) and some control frames. │└─────────────────────────────────────────────────────────────────┘NAV and Virtual Carrier Sensing:
The Duration field implements virtual carrier sensing. Every station maintains a timer called the Network Allocation Vector (NAV). When a station hears any frame (even not addressed to it), it:
This mechanism is critical for the hidden terminal solution. When Station A sends RTS to the AP, Station B (hidden from A) might not hear the RTS. However, Station B hears the AP's CTS response and updates its NAV accordingly, preventing collision.
Duration Calculation Examples:
| Frame Type | Duration Value Includes |
|---|---|
| RTS | SIFS + CTS + SIFS + Data + SIFS + ACK |
| CTS | SIFS + Data + SIFS + ACK |
| Data (with RTS) | SIFS + ACK |
| Data (without RTS) | SIFS + ACK |
| Data (last fragment) | SIFS + ACK |
| Data (more fragments) | 3×SIFS + next fragment + ACK |
| ACK | 0 (exchange complete) |
Malicious devices can set arbitrarily high Duration values (up to 32767μs ≈ 32ms) to create denial-of-service conditions. This 'Duration Attack' causes all hearing stations to defer indefinitely. Some enterprise APs have protection mechanisms that cap or ignore unreasonable duration values.
The 802.11 frame can contain up to four 6-byte MAC addresses, compared to Ethernet's two. This complexity reflects the three-address scenario required for infrastructure BSS (source, destination, and BSSID) and the four-address scenario for Wireless Distribution System (WDS) bridges.
Address Terminology:
| Abbreviation | Full Name | Definition |
|---|---|---|
| RA | Receiver Address | MAC address of the station that should process this frame |
| TA | Transmitter Address | MAC address of the station that transmitted this frame |
| DA | Destination Address | Final destination of the MSDU (may differ from RA) |
| SA | Source Address | Original source of the MSDU (may differ from TA) |
| BSSID | Basic Service Set ID | Unique identifier for the BSS (typically AP's MAC) |
Why Four Addresses?
In a simple station-to-AP transmission:
But in WDS (AP-to-AP bridging), we need to track:
These are four distinct addresses, hence the need for Address 4.
The next page provides comprehensive coverage of all address field scenarios, including detailed diagrams for each To DS/From DS combination and practical examples.
The Sequence Control field (2 bytes) serves two critical functions: tracking frame order through sequence numbers and managing fragmentation. This field is present in all Management and Data frames but absent from most Control frames.
Field Structure:
Sequence Control Field (16 bits / 2 bytes) ┌──────────────────────────────────────────────────────────────────┐│ Bits 0-3: Fragment Number │ Bits 4-15: Sequence Number │├──────────────────────────────────────────────────────────────────┤│ Fragment Number (4 bits) │ Sequence Number (12 bits) ││ Range: 0-15 │ Range: 0-4095 ││ │ ││ Identifies fragment │ Identifies the MSDU or MMPDU. ││ within an MSDU. │ Increments for each new frame. ││ First fragment = 0. │ Wraps from 4095 to 0. │└──────────────────────────────────────────────────────────────────┘ Example: A 5000-byte frame fragmented into three pieces: Fragment 0: SeqNum=1234, FragNum=0, MoreFrag=1 Fragment 1: SeqNum=1234, FragNum=1, MoreFrag=1 Fragment 2: SeqNum=1234, FragNum=2, MoreFrag=0 All fragments share the same Sequence Number.The last fragment has MoreFrag=0 in Frame Control.Sequence Number Usage:
Duplicate Detection: If a receiver gets a frame with a Retry bit set and the same Sequence Number + Fragment Number as a previously received frame, it discards the duplicate and still sends an ACK.
Ordering: Sequence numbers allow receivers to detect missing frames and request retransmission, and to reorder frames that arrive out of sequence.
Per-QoS Tracking: In QoS-capable stations, each Traffic Identifier (TID) maintains its own sequence counter. This allows frames from different traffic classes to be processed independently.
Block ACK and Sequence Numbers:
With 802.11n Block ACK, the receiver maintains a scoreboard of received sequence numbers within a window. The Block Ack Request (BAR) specifies a Starting Sequence Number, and the Block Ack (BA) response contains a bitmap indicating which of the following 64 or 128 sequence numbers were received successfully.
Block Ack Bitmap Example (64-frame window):
Starting Sequence: 2048
Bitmap: 11111111 11111011 11111111 11111111 ...
↑
Seq 2053 missing (will be retransmitted)
When analyzing captures, sequence number gaps don't always indicate lost frames. Frames to different destinations have independent sequence spaces. Also, if capturing in monitor mode, you may not capture all frames due to RF conditions, creating apparent gaps.
The QoS Control field (2 bytes) is present in QoS Data frames (subtypes 8-15 of type Data). Introduced in 802.11e and mandatory for 802.11n and later, this field enables traffic prioritization and advanced acknowledgment policies.
Field Structure:
QoS Control Field (16 bits / 2 bytes) ┌───────────────────────────────────────────────────────────────────────────┐│ Bits 0-3 │ Bit 4 │ Bits 5-6 │ Bit 7 │ Bits 8-15 ││ TID │ EOSP │ Ack Policy│ Reserved│ TXOP Limit / Queue Size / etc. │└───────────────────────────────────────────────────────────────────────────┘ TID (Traffic Identifier) - 4 bits: Maps to Access Categories and User Priorities: ┌─────┬────────────────────┬──────────────────────────────┐ │ TID │ Access Category │ Description │ ├─────┼────────────────────┼──────────────────────────────┤ │ 1,2 │ AC_BK (Background) │ Bulk data, lowest priority │ │ 0,3 │ AC_BE (Best Effort)│ Default, normal traffic │ │ 4,5 │ AC_VI (Video) │ Video streaming │ │ 6,7 │ AC_VO (Voice) │ VoIP, highest priority │ └─────┴────────────────────┴──────────────────────────────┘ EOSP (End of Service Period) - 1 bit: Used in APSD (Automatic Power Save Delivery). 1 = Last frame in the service period. Ack Policy - 2 bits: 00 = Normal Ack (immediate ACK expected) 01 = No Ack (no acknowledgment expected) 10 = No explicit Ack / block ack (802.11e PSMP) 11 = Block Ack (part of block ack session) Bits 8-15 vary by context: - TXOP Limit during TXOP - Queue Size for buffer status - AP PS Buffer State in certain framesWiFi Multimedia (WMM) is the Wi-Fi Alliance certification for 802.11e QoS. Certified devices support at least the mandatory EDCA (Enhanced Distributed Channel Access) mechanism with four access categories. WMM is required for 802.11n/ac/ax certification.
The HT Control field (4 bytes) was introduced with 802.11n (High Throughput) and extended in 802.11ac (VHT) and 802.11ax (HE). This field is present when the Order bit in Frame Control is set to 1 and contains information for beamforming, link adaptation, and aggregation control.
Field Structure:
HT Control Field (32 bits / 4 bytes) 802.11n (HT) Format:┌─────────────────────────────────────────────────────────────────────────────┐│ Bit 0 │ Bits 1-15 │ Bits 16-17 │ Bit 18 │ Bits 19-20 │ ... ││ VHT/HE│ Link Adaptation │ Calibration │ Position│ CSI/ │ Remaining ││ │ Control │ Position │ │ Steering │ Fields │└─────────────────────────────────────────────────────────────────────────────┘ 802.11ac (VHT) Format (when Bit 0 = 1):┌─────────────────────────────────────────────────────────────────────────────┐│ Bit 0 │ Bit 1 │ Bits 2-25 │ Bits 26-29 │ Bits 30-31 ││ = 1 │ MRQ │ VHT Compressed Beamforming │ MFB │ GID/Remaining ││ │ │ or MU-MIMO Control │ │ │└─────────────────────────────────────────────────────────────────────────────┘ Key Fields:- Link Adaptation Control: MCS feedback, antenna selection- CSI (Channel State Information): For beamforming calibration- MRQ (MCS Request): Requests MCS feedback from receiver- MFB (MCS Feedback): Conveys recommended MCS to sender- NDP Announcement: Indicates NDP (Null Data Packet) for soundingBeamforming and the HT Control Field:
Explicit beamforming (where the beamformer gets feedback from the beamformee) relies heavily on the HT Control field:
Sounding: The beamformer sends NDP (Null Data Packet) or staggered sounding to allow the beamformee to measure the channel.
Feedback: The beamformee sends back compressed beamforming feedback (CSI) in an action frame or using the HT Control field.
Steering Matrix: The beamformer uses feedback to compute steering vectors for focused transmission.
This closed-loop beamforming significantly improves SNR at the receiver, enabling higher MCS rates and better range.
The HT Control field adds 4 bytes to every frame when enabled. For small frames like ACKs or TCP ACKs, this overhead is significant. Some implementations only include HT Control when beamforming feedback or link adaptation signaling is needed, not on every frame.
Frame Body:
The Frame Body contains the actual payload and varies dramatically by frame type:
| Frame Type | Frame Body Contents | Max Size |
|---|---|---|
| Management | Fixed + Information Elements | 2312 bytes |
| Control | Usually empty or minimal | 0 bytes (most), varies |
| Data | LLC/SNAP + MSDU + MIC | 2312 bytes (legacy), 7951 bytes (A-MSDU) |
Management Frame Body Structure:
┌──────────────────────────────────────────────────────────────┐
│ Management Frame Body │
├─────────────────────────┬────────────────────────────────────┤
│ Fixed Fields │ Information Elements (Variable) │
│ (depend on subtype) │ │
├─────────────────────────┼────────────────────────────────────┤
│ Beacon: │ SSID IE (Element ID=0) │
│ - Timestamp (8B) │ Supported Rates IE (ID=1) │
│ - Beacon Interval (2B) │ DS Parameter Set IE (ID=3) │
│ - Capability Info (2B) │ TIM IE (ID=5) │
│ │ Country IE (ID=7) │
│ Association Resp: │ RSN IE (ID=48) │
│ - Capability Info (2B) │ HT Capabilities (ID=45) │
│ - Status Code (2B) │ VHT Capabilities (ID=191) │
│ - Association ID (2B) │ ... and many more │
└─────────────────────────┴────────────────────────────────────┘
Information Element Structure:
┌──────────────┬──────────────┬─────────────────────────────────┐
│ Element ID │ Length │ Element-Specific Data │
│ (1 byte) │ (1 byte) │ (Length bytes) │
└──────────────┴──────────────┴─────────────────────────────────┘
Information Elements (IEs) are the extensibility mechanism of 802.11. New capabilities are added by defining new Element IDs, maintaining backward compatibility.
Frame Check Sequence (FCS):
The FCS is a 4-byte CRC-32 computed over the entire MAC header and Frame Body. It provides error detection (not correction) for the frame contents.
CRC-32 Properties:
FCS Processing:
The FCS is not encrypted even in protected frames—it covers the ciphertext, not plaintext.
FCS only detects errors; it cannot correct them. In wireless networks with high bit error rates, even valid-looking frames may have undetected errors. Upper layer protocols (TCP checksums, application integrity checks) provide additional protection for critical data.
We've dissected every component of the 802.11 MAC frame structure. Let's consolidate the key concepts:
What's Next:
The next page provides an in-depth examination of the Address Fields—the most complex aspect of 802.11 frame structure. We'll explore all four address scenarios in detail, with practical examples showing how addresses are used in infrastructure BSS, IBSS (ad-hoc), and WDS topologies.
You now understand the complete structure of IEEE 802.11 MAC frames, including every header field and its purpose. This knowledge is essential for packet capture analysis, protocol debugging, and understanding wireless network behavior at the frame level.