// reference · intermediate

802.11 Power Save

Wi-Fi power save is not a single mechanism — it's a progression from Legacy PS-Poll (1997) through WMM-PS and DTIM to TWT in Wi-Fi 6. Each generation solved the previous generation's problems.

— Shankar K. · Source: IEEE 802.11-2020, Clauses 11.2 + 26.8 (TWT)

Original

Legacy PS-Poll

802.11-1997

QoS-aware

WMM-PS / U-APSD

802.11e-2005

HT era

PSMP

802.11n-2009

Wi-Fi 6 / IoT

TWT

802.11ax-2021

Legacy PS-Poll

802.11-1997 · Clause 11.2.1

Client enters doze mode after telling the AP (via Power Management bit in FC field). AP buffers frames for sleeping clients. At each beacon, the TIM IE lists which clients have buffered frames. Client wakes, reads TIM, sends PS-Poll to retrieve one frame at a time.

How it works

1. Client sets PM=1 in frame FC
2. AP starts buffering frames
3. Beacon TIM IE sets client\'s bit
4. Client wakes at TBTT, reads TIM
5. Client sends PS-Poll (control frame)
6. AP sends one buffered frame
7. Repeat for each buffered frame

Problems

One PS-Poll per frame = huge overhead for bursty traffic. Forces client to wake every beacon interval. No QoS awareness — voice and background treated equally. Modern devices avoid PS-Poll in favour of WMM-PS.

Wireshark: wlan.fc.type_subtype == 0x1a (PS-Poll) · wlan.fc.pwrmgt == 1 (PM bit set)

DTIM & TIM

All standards · Beacon IE

TIM (Traffic Indication Map) is present in every infrastructure beacon. It contains a bitmap showing which associated clients have buffered unicast frames. DTIM (Delivery TIM) is a special TIM that also triggers delivery of buffered multicast/broadcast frames — every client must wake for DTIM.

DTIM Count

How many beacons until the next DTIM beacon. Counts down from DTIM Period to 0.

DTIM Period

How many beacon intervals between DTIM beacons. Default=1 (every beacon). Higher=better battery, worse multicast latency.

TIM Bitmap

One bit per AID (Association ID). Bit set = that client has buffered frames waiting.

Field note — DTIM Period choice

DTIM Period 1 = clients wake every beacon (100ms) — best multicast, worst battery. DTIM Period 3 = clients wake every 307ms — good balance for IoT. DTIM Period 10 = clients wake every ~1s — maximum battery, poor real-time multicast. For mDNS-heavy environments (Apple devices, Chromecast) keep DTIM at 1-3 or multicast discovery breaks.

Wireshark: wlan_mgt.tim (TIM IE) · wlan_mgt.tim.dtim_count · wlan_mgt.tim.dtim_period

WMM-PS / U-APSD

802.11e-2005 · QoS-aware

Unscheduled Automatic Power Save Delivery (U-APSD) — the client triggers frame delivery by sending any uplink frame on a delivery-enabled AC. AP responds by sending all buffered downlink frames for that AC, ending with a frame with EOSP=1 (End of Service Period). More efficient than PS-Poll for bursty QoS traffic.

Advantage over PS-Poll

One trigger frame retrieves ALL buffered frames for that AC. Voice (VO) frames can trigger VO delivery without waking the entire PS mechanism. Better for VoIP phones — wake only for voice traffic.

EOSP bit

End of Service Period. AP sets EOSP=1 on the last frame in a delivery burst. Client knows it can return to doze after receiving this frame. If EOSP never comes, client stays awake indefinitely — a common IoT battery drain bug.

Wireshark: wlan.qos.eosp == 1 (end of service period) · wlan_mgt.wmmparams (WMM-PS params in beacon)

TWT — Target Wake Time

802.11ax · Wi-Fi 6

The biggest power save advancement since U-APSD. Client and AP negotiate a specific schedule — wake time, interval, and duration — via TWT Action frames. Instead of waking every beacon interval, an IoT device might wake once every 10 minutes for a 5ms window. Battery life goes from days to months.

Individual TWT

One-to-one negotiation. Client proposes schedule, AP accepts/rejects/counter-proposes. Most flexible. Used by smartphones, laptops.

Broadcast TWT

AP announces a common wake schedule in beacon for all clients. More efficient for large deployments. Clients opt-in.

TWT SP

Service Period — the negotiated window during which the client is awake and can exchange frames. Outside SP: radio off.

Field note — TWT in gateway qualification

TWT negotiation happens via Action frames (S1G Action or HE Action category). A client that supports TWT advertises it in the HE Capabilities IE (TWT Requester bit). The AP must also advertise TWT Responder. If either bit is 0, TWT won't negotiate regardless of driver configuration. In gateway QA I always verify both bits before testing TWT power metrics.

Wireshark: wlan_mgt.he.capabilities.twt_requester · wlan_mgt.he.capabilities.twt_responder · TWT action frames in Action frame category

// interactive frame tree — legacy ps-poll exchange

Click any row to expand · hover for Wireshark filter

// mechanism comparison

Mechanism	Standard	Trigger	Granularity	Best for
Legacy PS-Poll	802.11-1997	TBTT / beacon	One frame per poll	Legacy devices only
DTIM multicast	All	DTIM beacon	All buffered multicast	Multicast/broadcast delivery
WMM-PS / U-APSD	802.11e	Client uplink trigger	All buffered per AC	VoIP phones, QoS-aware clients
TWT (Individual)	802.11ax	Negotiated schedule	Microsecond precision	Smartphones, laptops
TWT (Broadcast)	802.11ax	AP beacon announcement	Common schedule	Dense IoT deployments

Diagnose power save issues in a PCAP

WiFi Analyser detects missing EOSP bits, TWT negotiation failures, and PS-Poll overhead patterns.

try it free ↗

// share this page

// also on this site

← previous

reference

Interframe Spacing

next →

reference

MCS Rate Calculator

SK

— Shankar K., Wi-Fi engineer, Irving TX
 Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks 

// leave a comment