Wifi Frame Format - Learning Module

Loading content...

0/228

Duration Field

The Invisible Traffic Cop

In a wireless network, the most critical challenge is coordination: how do dozens or hundreds of devices share a single radio channel without constantly colliding? While physical carrier sensing (listening before transmitting) helps, it's not sufficient—the hidden terminal problem means some stations can't hear each other's transmissions even when they would interfere at the receiver.

The 802.11 Duration field solves this through virtual carrier sensing. Every frame carries a duration value that tells all listeners: "I need the medium for this many microseconds—please stay silent." Stations that hear this update their Network Allocation Vector (NAV)—an internal timer that counts down to zero before they'll attempt transmission.

This elegant mechanism transforms a chaotic shared medium into an orderly system where stations voluntarily defer to ongoing transmissions—even transmissions they cannot directly hear. Understanding the Duration field is essential for WiFi performance optimization, troubleshooting, and security analysis.

What You Will Learn

By the end of this page, you will understand how the Duration field enables virtual carrier sensing, the NAV mechanism and its role in medium access, duration calculations for various frame exchange sequences, the dual use of the Duration/ID field, and security implications including duration-based attacks.

Virtual Carrier Sensing

802.11 employs two complementary carrier sensing mechanisms:

Physical Carrier Sensing (PCS):

Hardware-level detection of RF energy on the channel
Station monitors the medium for signals above a threshold
Clear Channel Assessment (CCA) determines if medium is busy
Limited by radio range—cannot detect transmitters beyond sensing range

Virtual Carrier Sensing (VCS):

Software-level reservation based on Duration field
All frames carry expected transmission duration
Stations update their NAV based on heard durations
Hearing a valid frame = medium busy for specified duration

Why Both Are Needed:

Physical Sensing Alone

•Cannot detect hidden terminals
•May be fooled by non-802.11 interference
•Range limited by receive sensitivity
•Cannot anticipate multi-frame exchanges

Virtual Sensing Addresses

•CTS silences hidden stations
•Only responds to valid 802.11 frames
•RTS/CTS extends reach of coordination
•Duration includes complete exchange time

The Hidden Terminal Solution:

Topology: Station A cannot hear Station C

    Station A              Access Point              Station C
        │      ┌─────────────────┐      │
        │      │    Hearing      │      │
        │◄────►│      Zone       │◄────►│
        │      │                 │      │
        │      └─────────────────┘      │
        │              │                │
        │              │                │
        ▼              ▼                ▼
     Can hear       Can hear         Can hear
       AP           A and C            AP
     Cannot                          Cannot
     hear C                          hear A

Without Virtual Sensing: A and C might transmit simultaneously, colliding at AP.

With RTS/CTS and Virtual Sensing:

A sends RTS to AP (C doesn't hear—outside range)
AP sends CTS to A (C does hear this)
C reads Duration in CTS, sets NAV, and defers
A transmits data safely
AP sends ACK
C's NAV expires, and C may now contend

NAV Is Conservative

Stations set NAV = max(current NAV, new Duration). They never reduce NAV based on new frames. This ensures a multi-frame exchange (like RTS-CTS-Data-ACK) remains protected even if intermediate frames are shorter than expected.

Network Allocation Vector (NAV)

The Network Allocation Vector is a timer maintained by each station that indicates when the medium will become available. NAV is the core data structure for virtual carrier sensing.

NAV Operation Rules:

NAV Update and Usage Rules

•Update on reception: When receiving a valid frame, compare Duration with current NAV. If Duration is larger, set NAV = Duration.
•Countdown continuously: NAV decrements in real-time (typically microsecond precision).
•Medium busy when NAV > 0: Station treats medium as busy regardless of physical carrier sensing.
•Never decrease early: A new frame cannot reduce NAV; it can only extend it.
•Reset on CF-End: In PCF mode, a CF-End frame resets NAV to zero.
•Ignore own frames: A station does not update NAV based on its own transmissions.

NAV State Machine
NAV Timer Operation:
 
Initial State: NAV = 0 (medium idle from VCS perspective)
 
┌───────────────────────────────────────────────────────────────────────────┐
│                          NAV State Updates                                 │
├───────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│   Frame Received ──►  Duration Field = D                                  │
│                            │                                               │
│                            ▼                                               │
│                    ┌───────────────┐                                       │
│                    │ D > NAV ?     │                                       │
│                    └───────┬───────┘                                       │
│                     Yes    │    No                                         │
│                      │     │     │                                         │
│                      ▼     │     ▼                                         │
│              NAV := D      │   NAV unchanged                               │
│                            │                                               │
│   Continuous:              │                                               │
│   NAV := max(0, NAV - Δt)  │   (Δt = elapsed time)                        │
│                            │                                               │
│   Medium Assessment:       │                                               │
│   IF NAV > 0: Medium BUSY (virtual)                                        │
│   IF NAV = 0: Check Physical Carrier Sensing                               │
│                                                                            │
└───────────────────────────────────────────────────────────────────────────┘

Combined Carrier Assessment:

Before transmitting, a station performs Clear Channel Assessment (CCA) which combines:

Component	Condition for Busy	Purpose
Physical CS	Energy detected above CCA threshold	Detect nearby transmitters
Virtual CS	NAV > 0	Honor ongoing exchanges

Medium is clear only when BOTH physical carrier sensing shows idle AND NAV = 0.

Medium Status = (Physical_CS_Busy OR Virtual_CS_Busy) ? BUSY : IDLE

Physical_CS_Busy = (Received_Signal_Strength > CCA_Threshold)
Virtual_CS_Busy  = (NAV > 0)

NAV in QoS Stations

QoS-capable stations (802.11e+) may maintain multiple NAV timers—one per Access Category. This allows higher-priority traffic to ignore NAV set by lower-priority frames in certain conditions. However, basic NAV operation remains the same.

Duration/ID Field Format

The Duration/ID field is 16 bits (2 bytes) and can represent three distinct things based on bit patterns:

Interpretation Based on Bit 15:

Duration/ID Field Interpretation
Duration/ID Field (16 bits):
 
┌──────────────────────────────────────────────────────────────────────────┐
│ Case 1: Duration Value (Bit 15 = 0)                                       │
├──────────────────────────────────────────────────────────────────────────┤
│ Bit 15 │ Bits 14-0                                                       │
│   0    │ Duration in microseconds (0 - 32767 μs)                         │
│        │                                                                  │
│ Example: 0x00C8 = 200 μs                                                 │
│         Binary: 0 000 0000 1100 1000                                     │
│         This reserves medium for 200 microseconds                        │
└──────────────────────────────────────────────────────────────────────────┘
 
┌──────────────────────────────────────────────────────────────────────────┐
│ Case 2: Association ID (Bit 15 = 1, Bit 14 = 0)                          │
├──────────────────────────────────────────────────────────────────────────┤
│ Bit 15 │ Bit 14 │ Bits 13-0                                              │
│   1    │   0    │ Association ID (1 - 16383, typically 1-2007)           │
│        │        │                                                         │
│ Used in: PS-Poll frames from power-saving stations                       │
│ Example: 0x8005 = AID 5                                                  │
│         Binary: 1 0 00 0000 0000 0101                                    │
└──────────────────────────────────────────────────────────────────────────┘
 
┌──────────────────────────────────────────────────────────────────────────┐
│ Case 3: Fixed/Reserved (Bit 15 = 1, Bit 14 = 1)                          │
├──────────────────────────────────────────────────────────────────────────┤
│ Bit 15 │ Bit 14 │ Bits 13-0                                              │
│   1    │   1    │ Reserved values                                         │
│        │        │                                                         │
│ 0x8000: Duration = 0, used in CF period                                  │
│ 0xFFFF: Reserved                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Duration/ID Field Value Ranges
Value Range (Hex)	Value Range (Decimal)	Meaning
0x0000 - 0x7FFF	0 - 32767	Duration in microseconds
0x8001 - 0xBFFF	32769 - 49151	Association ID (bit 14=0)
0x8000	32768	Fixed duration (CFP)
0xC000 - 0xFFFF	49152 - 65535	Reserved

Maximum Duration

The maximum duration value is 32,767 microseconds (~32.8 ms). This may seem short, but remember that 802.11 uses CSMA/CA—stations must frequently release the medium. A single TXOP (Transmission Opportunity) might have shorter limits, and aggregation helps pack more data into each access opportunity.

Duration Calculation for Frame Exchanges

The Duration field must be calculated precisely to reserve the medium for the complete frame exchange. Different frame types require different calculations.

RTS/CTS/Data/ACK Exchange:

Duration Calculation for RTS/CTS Exchange
Complete RTS → CTS → Data → ACK Exchange:
 
Timeline:
┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│  ├─RTS─┤ SIFS ├─CTS─┤ SIFS ├───Data Frame───┤ SIFS ├─ACK─┤                │
│                                                                              │
│  ◄─────────────── Duration in RTS ────────────────────────►                 │
│         ◄───────────── Duration in CTS ───────────────────►                 │
│                       ◄──────── Duration in Data ─────────►                 │
│                                                   Duration │                 │
│                                                    in ACK  │                 │
│                                                     = 0    │                 │
└─────────────────────────────────────────────────────────────────────────────┘
 
Duration Formulas:
 
RTS Duration = CTS_time + SIFS + Data_time + SIFS + ACK_time + (3 × SIFS)
             = SIFS + CTS_time + SIFS + Data_time + SIFS + ACK_time
 
CTS Duration = RTS_Duration - SIFS - CTS_time
             = Data_time + SIFS + ACK_time + SIFS
 
Data Duration = SIFS + ACK_time
 
ACK Duration = 0 (exchange complete)

Practical Example Calculation:

Assume 802.11g at 54 Mbps:

SIFS = 10 μs
CTS transmission time = 10 μs (14 bytes at lowest rate)
Data frame = 1500 bytes → ~222 μs at 54 Mbps
ACK = 10 μs

RTS Duration:

= SIFS + CTS + SIFS + Data + SIFS + ACK
= 10 + 10 + 10 + 222 + 10 + 10
= 272 μs

CTS Duration:

= SIFS + Data + SIFS + ACK
= 10 + 222 + 10 + 10 = 252 μs

Data Duration:

= SIFS + ACK
= 10 + 10 = 20 μs

Duration Field Values for Different Frame Types
Frame Type	Duration Value
RTS	SIFS + CTS + SIFS + Data + SIFS + ACK
CTS	SIFS + Data + SIFS + ACK
Data (single, no RTS)	SIFS + ACK
Data (with more fragments)	3×SIFS + NextFragment + ACK
ACK	0
Beacon	0 (no ack expected)
Block Ack Request	SIFS + Block_ACK
PS-Poll	Carries AID, not duration

Rate-Dependent Duration

Frame transmission times depend on the data rate used. Control frames (RTS, CTS, ACK) are typically sent at the basic rate (low rate for reliability), while data frames use the negotiated rate. Duration calculations must account for these different rates.

Fragmentation and Duration

When a frame is fragmented into multiple pieces, the Duration field plays a critical role in reserving the medium for the entire fragment burst. Each fragment must include duration sufficient for all remaining fragments.

Fragment Exchange Timeline:

Fragmented Frame Duration
Three-Fragment Exchange:
 
┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│ ├─Frag0─┤SIFS├ACK┤SIFS├─Frag1─┤SIFS├ACK┤SIFS├─Frag2─┤SIFS├ACK┤            │
│                                                                              │
│ ◄───────────── Duration in Fragment 0 ─────────────────────►                │
│                    ◄──────── Duration in Fragment 1 ────────►               │
│                                        ◄─── Duration Frag2───►              │
│                                                          = SIFS+ACK         │
└─────────────────────────────────────────────────────────────────────────────┘
 
Duration in Fragment 0 (with MoreFrag=1):
  = 3×SIFS + ACK + Frag1 + ACK + SIFS + Frag2 + ACK
  = Reserved time for ALL remaining fragments
 
Duration in Fragment 1 (MoreFrag=1):  
  = 3×SIFS + ACK + Frag2 + ACK
  = Reserved time for remaining fragment
 
Duration in Fragment 2 (MoreFrag=0):
  = SIFS + ACK
  = Only need time to receive acknowledgment

Why This Matters:

The duration reservation ensures that once a station begins a fragment burst, it can complete the entire sequence without interference. Any station that hears Fragment 0 sets its NAV high enough to cover all subsequent fragments.

Fragment Failure Handling:

If an ACK is not received for a fragment:

The sender waits for a timeout
The sender may retransmit from the failed fragment
Other stations' NAV may expire during retry backoff
The sender must compete for access again

This is why fragmentation increases airtime and reduces efficiency—each fragment adds overhead and retry risk.

Fragmentation Threshold

Frames larger than the fragmentation threshold are automatically fragmented. Default is 2346 bytes (effectively disabled). When enabled (iwconfig wlan0 frag 1500), frames exceeding the threshold are split. Lower thresholds may improve reliability in noisy environments but significantly reduce throughput.

Power Save: Association ID Mode

When a station in power-save mode sends a PS-Poll frame to request buffered data from the AP, the Duration/ID field carries the station's Association ID (AID) rather than a duration value.

PS-Poll Frame Structure:

PS-Poll Duration/ID Field
PS-Poll Frame from Power-Saving Station:
 
┌─────────────────────────────────────────────────────────────────────────────┐
│ Frame Control  │ Duration/ID (AID) │ BSSID (Addr1) │ TA (Addr2) │ FCS      │
│   (2 bytes)    │   (2 bytes)       │  (6 bytes)    │ (6 bytes)  │(4 bytes) │
└─────────────────────────────────────────────────────────────────────────────┘
 
Duration/ID Field in PS-Poll:
┌─────────────────────────────────────────────────────────────────────────────┐
│ Bit 15 │ Bit 14 │ Bits 13-0                                                │
│   1    │   0    │ Association ID (AID)                                      │
└─────────────────────────────────────────────────────────────────────────────┘
 
Example: Station with AID = 5
  Duration/ID = 0x8005
  Binary: 1000 0000 0000 0101
 
The AP reads the AID to:
1. Identify which station is polling
2. Retrieve buffered frames for that station
3. Respond with buffered data (or ACK if none)

Power Save Workflow:

Station Associates: AP assigns Association ID (1-2007)
Station Enters Sleep: Sends Null Data frame with PM bit = 1
AP Buffers Frames: Any frames for sleeping station are queued
Beacon Advertisement: AP sets bit in TIM (Traffic Indication Map) for stations with buffered data
Station Wakes for Beacon: Checks TIM for its AID bit
PS-Poll Sent: If TIM indicates buffered data, station sends PS-Poll with its AID
AP Delivers Data: Responds with buffered frame(s)
More Data Flag: If more frames buffered, Data frame has MoreData=1
Station Continues/Sleeps: Either sends more PS-Polls or returns to sleep

U-APSD: Efficient Power Save

Unscheduled Automatic Power Save Delivery (U-APSD), part of WMM Power Save, improves on PS-Poll. Instead of polling after each beacon, stations send trigger frames (usually QoS Null or QoS Data) that prompt the AP to deliver all buffered frames in a service period. This reduces round-trips and improves VoIP battery life.

NAV Reset and Special Cases

While NAV typically counts down naturally, certain conditions can reset or modify NAV behavior:

CF-End Frame (NAV Reset):

CF-End NAV Reset
Contention-Free Period Ending:
 
During PCF (Point Coordination Function):
  - AP polls stations in turn during CF period
  - All non-polled stations set NAV high
  
When CF period ends:
  - AP sends CF-End frame
  - Duration/ID in CF-End = 0
  - All stations RESET NAV to 0
  - Normal contention resumes immediately
 
CF-End Frame:
┌──────────────────┬────────────────┬───────────┬───────────┬─────┐
│ Frame Control    │ Duration = 0   │  BSSID    │   RA      │ FCS │
│ Subtype = 1110   │                │           │ (Bcast)   │     │
└──────────────────┴────────────────┴───────────┴───────────┴─────┘
 
NAV Reset Logic:
  IF frame_type == CF-End:
      NAV := 0   // Immediate reset
      // Stations may now contend normally

TXOP (Transmission Opportunity):

802.11e introduced TXOP—a bounded time interval during which a station may transmit multiple frames. TXOP management involves special duration handling:

TXOP Behavior	Duration Field Handling
TXOP Holder	Sets duration for remaining TXOP time
Multiple frames in TXOP	Each frame updates duration for remaining time
TXOP ends early	Send CF-End to release medium
TXOP Limit	Maximum duration varies by Access Category

TXOP Limits by Access Category (typical):

AC_BK (Background): 0 (single frame only)
AC_BE (Best Effort): 0 (single frame only)
AC_VI (Video): 3.008 ms
AC_VO (Voice): 1.504 ms

NAV and CTS-to-Self

CTS-to-Self is a protection mechanism where a station sends a CTS addressed to itself. This sets NAV in all hearing stations without the overhead of RTS. It's commonly used for 802.11g protection (allowing 11b stations to hear the reservation) but provides no hidden terminal protection since there's no CTS from the receiver's location.

Duration-Based Attacks

The Duration field, while essential for fair medium access, can be abused by malicious actors. Understanding these attacks helps in both detection and mitigation.

Duration Attack (NAV Attack):

A malicious station continuously transmits frames with maximum duration values (32,767 μs), forcing all compliant stations to defer indefinitely.

Duration Attack Mechanism
Duration Attack Scenario:
 
Normal Operation:
┌─────────────────────────────────────────────────────────────────┐
│ Time │ Station A      │ Station B      │ Malicious Station    │
├─────────────────────────────────────────────────────────────────┤
│  t0  │ Transmit Data  │ NAV = 200μs    │ NAV = 200μs           │
│  t1  │ Receive ACK    │ Countdown...   │ Countdown...          │
│  t2  │ Idle           │ NAV = 0        │ NAV = 0               │
│  t3  │ Contend        │ Contend        │ Contend               │
│  t4  │ May win access │ May win access │ May win access        │
└─────────────────────────────────────────────────────────────────┘
 
Under Duration Attack:
┌─────────────────────────────────────────────────────────────────┐
│ Time │ Station A      │ Station B      │ Malicious Station    │
├─────────────────────────────────────────────────────────────────┤
│  t0  │ Waiting...     │ NAV = 32767μs  │ Transmit (Dur=32767) │
│  t1  │ NAV = 32767μs  │ Countdown...   │ Transmit (Dur=32767) │
│  t2  │ Cannot send    │ Cannot send    │ Transmit (Dur=32767) │
│  t3  │ NAV refreshed  │ NAV refreshed  │ Transmit (Dur=32767) │
│  ... │ ... forever    │ ... forever    │ Repeat indefinitely  │
└─────────────────────────────────────────────────────────────────┘
 
Effective DoS: All stations except attacker are silenced.

Detection and Mitigation:

Duration Attack Countermeasures
Countermeasure	Description	Effectiveness
Duration Capping	AP/switch ignores durations > threshold	High—limits attack impact
Duration Monitoring	IDS flags excessive duration values	Detection only
Physical Layer Detection	Detect transmission pattern anomalies	Can identify attacker location
NAV Reset on Error	Reset NAV if expected frame not received	Partial—attacker can repeat
802.11w MFP	Authenticated management frames	Prevents some related attacks

Selfish Behavior Variants

Beyond malicious attacks, 'greedy' devices may use inflated duration values to gain unfair medium access. Some cheap IoT devices have been found with buggy duration implementations that unintentionally cause similar effects. Enterprise wireless IDS systems should monitor for duration anomalies.

Duration in Modern WiFi (802.11ax/be)

Modern WiFi standards have evolved duration handling to support new capabilities:

802.11ax (WiFi 6):

OFDMA Multi-User: AP schedules multiple stations simultaneously on different resource units. Duration covers the entire OFDMA transmission.
BSS Coloring: Helps distinguish between overlapping networks, but NAV is still set for interfering transmissions.
Target Wake Time (TWT): Stations negotiate specific wake times, reducing need for continuous NAV monitoring.

802.11be (WiFi 7):

Multi-Link Operation: Device can transmit on multiple bands simultaneously. Duration handled per-link.
Preamble Puncturing: Unused channels within wide bands can be punctured, affecting duration calculations.
Latency Improvements: Prioritized Access and Emergency Service aims for deterministic latency alongside traditional duration-based access.

OFDMA and Duration

In 802.11ax OFDMA downlink, multiple stations receive simultaneously. The trigger frame from AP sets duration for the entire transmission, and all receiving stations process their assigned resource units. Uplink OFDMA uses trigger-based access where the AP's trigger frame duration covers all responding stations.

Summary: Mastering the Duration Field

We've explored the Duration field's critical role in 802.11 operation. Here are the essential takeaways:

Key Takeaways

•Virtual carrier sensing via NAV complements physical carrier sensing to solve the hidden terminal problem.
•Duration values are in microseconds (0-32,767 μs when bit 15 = 0), representing time needed to complete frame exchanges.
•NAV is set to max(current, new) — stations never reduce NAV based on new frames, ensuring ongoing exchanges remain protected.
•PS-Poll uses AID mode — when bit 15=1 and bit 14=0, the field carries the Association ID instead of duration.
•Duration calculations must include SIFS intervals, response frame times, and time for any remaining fragments.
•CF-End resets NAV to zero — this is the only mechanism for early NAV release.
•Duration attacks can create denial-of-service conditions; enterprise systems should monitor for anomalies.
•Modern WiFi (802.11ax/be) extends duration concepts for OFDMA and multi-link operation.

What's Next:

The final page of this module covers Fragmentation — the mechanism by which large frames are split into smaller pieces for transmission. We'll explore fragment structure, reassembly, the role of fragment numbers and sequence numbers, and when fragmentation helps versus hurts performance.

Page Complete

You now have comprehensive knowledge of the IEEE 802.11 Duration field and virtual carrier sensing mechanism. This understanding is essential for WiFi performance analysis, security assessment, and protocol debugging.