Target Wake Time (TWT) Schedule
Wi-Fi 6 introduced TWT so IoT devices can sleep for seconds, minutes, or hours and wake on a schedule. Wi-Fi 7 added r-TWT for latency-guaranteed slots. Pick a mode, tune the wake parameters, and watch the service period cycle play out.
— Shankar K. · Source: IEEE 802.11ax-2021 Section 26.8, 9.4.2.199; 802.11be-2024 Section 35.6 · Wireshark: wlan.twt
TWT is a scheduled agreement between a client (STA) and the access point (AP). The STA sleeps with its radio off, wakes at a target time, sends or receives during its service period (SP), then sleeps again. Two agreement types: Individual (private STA-to-AP) and Broadcast (shared schedule for a group). Wi-Fi 7 adds r-TWT on top of Broadcast for guaranteed latency.
wlan.twt expands the tree; mantissa is at wlan.twt.request_type.wake_interval_mantissa.
Battery-powered smart lock rated for two years of battery life. In the actual deployment, it dies at six weeks. The user blames the manufacturer.
The lock negotiated a Target Wake Time agreement with the AP — wake every 5 minutes, transmit one status update, go back to sleep. The AP accepted the TWT Setup request. But the AP's implementation is buggy: it continues to buffer unicast traffic for the lock between TWT windows and delivers it in a burst during the wake, often requiring retries. The lock's radio stays awake roughly 50 ms longer per wake than designed. Summed across a day, the radio's actual duty cycle ends up several times what the battery was sized for.
When TWT is implemented correctly on both sides, the AP respects the wake window, delivers only what fits, and lets the radio sleep between windows. The lock wakes for milliseconds every 5 minutes, and the battery hits the advertised two years. You can verify by capturing Action frames during a wake window: TWT-cognizant APs honor the schedule and don't push buffered traffic outside the agreed-upon duration.
TWT negotiation happens via TWT Setup Action frames that most vendor management dashboards don't expose. If TWT is failing, you usually won't see it in the AP UI. A PCAP is often the only way to confirm whether TWT was negotiated at all, and whether both sides are honoring the schedule. Budget time for protocol-level troubleshooting when a TWT-dependent device misbehaves.
Target Wake Time (TWT) lets a Wi-Fi 6 or Wi-Fi 7 client device and the access point agree on a schedule: when the device wakes up, how long it stays awake, how often that repeats. Before TWT, a client device had to either stay awake all the time (battery death) or rely on the legacy PS-Poll mechanism that wakes the device at every beacon (about 10 times per second) just in case the AP has something to deliver.
With TWT, a smart plug might wake up for 20 ms every 60 seconds — three wakes per minute instead of 600. That's 200x less radio-on time. A sleep tracker might wake every 5 minutes. An industrial sensor might wake once an hour. And a Wi-Fi 7 AR headset might wake every 5 ms for 1 ms, using a guaranteed r-TWT slot that legacy clients can't interfere with.
The AP manages the schedule. The client requests parameters, the AP accepts or negotiates. Once agreed, the client goes to sleep and wakes exactly when told. The AP knows when each client will be awake, so it can also schedule its downlink transmissions efficiently.
Individual TWT vs Broadcast TWT. Individual is a private contract between one STA and the AP — no other STA knows the schedule. Broadcast is a shared schedule for a group, advertised in every beacon. Use Individual for a device with unique timing needs (your doorbell camera); use Broadcast for a group with a shared rhythm (dozens of smart bulbs on a 100 ms cadence).
Announced vs Unannounced (flow type flag). In Announced mode, the STA signals that it's awake (via a PS-Poll or null frame) before the AP starts transmitting to it — a handshake at the start of every SP. In Unannounced mode, the AP assumes the STA is awake at SP start and transmits immediately. Announced is safer; Unannounced saves one frame per SP.
Trigger-Enabled vs Non-Trigger (trigger flag). In Trigger-Enabled mode, the STA must wait for a Trigger frame from the AP before uplink TX — the AP orchestrates UL OFDMA across many STAs. In Non-Trigger mode, the STA contends for the medium normally (EDCA). Phones and laptops use Non-Trigger when they have irregular traffic. IoT sensors with tight schedules use Trigger-Enabled.
How the AP knows what a client can do: the HE Capabilities element in the client's Association Request carries the TWT Requester Support and TWT Responder Support bits. For r-TWT, the EHT Capabilities element adds additional capability bits.
Mantissa-exponent encoding for Wake Interval. Wake Interval = Mantissa * 2^Exponent microseconds. Mantissa is 16 bits (max 65535). Exponent is 5 bits (max 31). Max interval: 65535 * 2^31 us = approximately 4 years, 5 months. The encoding is not unique — 1024 us = (mantissa=1024, exp=0) = (mantissa=512, exp=1) = (mantissa=256, exp=2). Firmware and packet captures may show any valid encoding; normalize before comparing.
Wake Duration encoding. Nominal Min TWT Wake Duration is 1 octet, multiplied by either 256 us (Control field B5 = 0) or 1 TU = 1024 us (B5 = 1). Max duration using 256-us unit is 65280 us, deliberately kept below the legacy TxOP cap to preserve interop with non-TWT STAs.
TWT Setup command state machine. The Request Type's TWT Setup Command field (3 bits) drives negotiation. Requesting STA sends Request (0) / Suggest (1) / Demand (2) / Grouping (3). Responding STA (AP) sends Accept (4) / Alternate (5) / Dictate (6) / Reject (7). A Demand leaves no room for counter-proposal; Suggest opens the door to Alternate. Dictate is the AP forcing its own schedule regardless of request.
TWT Flow ID. 3-bit field inside Request Type, values 0-7. A single STA may have up to 8 concurrent TWT agreements, each for a different flow. The AP tracks agreements by (STA MAC, Flow ID) tuple.
Implicit vs Explicit. Implicit mode (Request Type B5 = 1): schedule auto-renews; both sides compute next SP from prior SP + Wake Interval. Explicit mode: AP provides Next TWT value for every SP, giving it mid-stream schedule authority. Most implementations use Implicit.
Wi-Fi 7 r-TWT on top of Broadcast TWT. r-TWT requires Broadcast TWT as a prerequisite. The AP advertises a Quiet element in beacons that forces non-r-TWT STAs to stay silent before the r-TWT SP begins. Legacy STAs must back off for the quiet period duration. Inside the SP, only designated r-TWT member STAs transmit, directed by AP Trigger frames. TID-to-link-mapping (Wi-Fi 7 Section 35.3) can steer specific traffic categories (e.g., AC_VO for voice) into r-TWT SPs.
Wireshark. Look for wlan.twt on a Wi-Fi 6/7 capture. The TWT element expands into Control and Parameter Info subtrees. The Request Type is at wlan.twt.request_type, with sub-bits wlan.twt.request_type.trigger, wlan.twt.request_type.flow_type, wlan.twt.request_type.wake_interval_exponent, etc. For r-TWT on EHT captures, check for wlan.ext_tag.number == 78 in the beacon payload.
Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks