What Is TWT (Target Wake Time)?

The Power Problem

WiFi has always been power-hungry. A typical WiFi radio consumes 100-300 milliwatts when active - listening for packets, checking for beacons, contending for channel access. For a laptop plugged into the wall, this is negligible. For a battery-powered IoT sensor that needs to run for months on a coin cell, it is a death sentence.

This power cost is why Bluetooth Low Energy (BLE), Zigbee, and Z-Wave dominate the battery-powered IoT market despite WiFi's advantages in bandwidth, range, and IP-native connectivity. A BLE sensor can run for years on a CR2032 coin cell. A WiFi sensor doing the same job might last days or weeks.

Target Wake Time, introduced in WiFi 6 (802.11ax), attacks this problem directly. It lets a device negotiate a sleep schedule with the access point so the device can turn off its radio for extended periods - seconds, minutes, or even hours at a time - and only wake up when it has scheduled communication windows.

Legacy Power Save Mechanisms

WiFi has had power save features since the original 802.11 standard, but they were primitive by modern standards.

Legacy Power Save (PS-Poll): The client tells the AP it is going to sleep. The AP buffers any frames destined for that client. The client wakes up for every beacon interval (typically every 102.4 milliseconds), checks the Traffic Indication Map (TIM) in the beacon, and if the TIM indicates buffered frames, it sends a PS-Poll frame to retrieve them. The problem: waking up every 100ms to check the TIM still consumes significant power, even when there is no pending traffic.

U-APSD (Unscheduled Automatic Power Save Delivery): An improvement introduced with WMM. The client can trigger frame delivery by sending any uplink frame, and the AP responds with all buffered downlink frames. This reduces unnecessary wake-ups but still requires the client to poll periodically.

Both mechanisms assume the client needs to check in frequently. For a device that transmits a temperature reading once per hour, waking up 36,000 times per hour to check beacons is absurdly wasteful.

graph TD
    subgraph "Legacy Power Save - PS-Poll"
        B1[Beacon 1 - No data] --> WAKE1[Client wakes - checks TIM]
        WAKE1 --> SLEEP1[Back to sleep]
        SLEEP1 --> B2[Beacon 2 - No data]
        B2 --> WAKE2[Client wakes - checks TIM]
        WAKE2 --> SLEEP2[Back to sleep]
        SLEEP2 --> B3[Beacon 3 - Data buffered]
        B3 --> WAKE3[Client wakes - sees TIM flag]
        WAKE3 --> POLL[Sends PS-Poll]
        POLL --> DATA[Receives buffered data]
        DATA --> SLEEP3[Back to sleep]
    end
    subgraph "TWT - Scheduled Wake"
        TSLEEP1[Deep sleep - radio off] -->|Hours later| TWAKE[Scheduled TWT wake]
        TWAKE --> TX[Transmit sensor data]
        TX --> RX[Receive any buffered data]
        RX --> TSLEEP2[Deep sleep - radio off]
    end

Legacy power save wakes the client for every beacon - TWT allows deep sleep for extended periods between scheduled windows

TWT Fundamentals

TWT works through a negotiation between the client (STA) and the access point. During association or at any point during a connection, the client sends a TWT Setup frame proposing a schedule. The AP can accept, modify, or reject the proposal.

The agreed schedule defines:

TWT Wake Interval: How often the client wakes up. This can range from milliseconds to hours depending on the application.

TWT Wake Duration: How long the client stays awake during each service period. This must be long enough to exchange any pending data.

TWT Channel: Which channel the communication occurs on during the service period.

Once the schedule is established, the client turns off its radio entirely between service periods. It does not listen for beacons, does not check the TIM, and does not contend for channel access. The AP knows when the client will wake up and buffers any incoming frames until the next service period.

Individual TWT

Individual TWT (iTWT) creates a dedicated schedule between one client and the AP. The client proposes its preferred wake schedule based on its application requirements. A temperature sensor might propose waking once per minute. A door lock might propose waking once every 5 seconds to ensure timely notification of unlock commands.

The AP manages all individual TWT agreements, ensuring that service periods do not overlap excessively and that the channel can accommodate all scheduled wake-ups. The AP can suggest alternative times if the proposed schedule conflicts with other clients' TWT agreements.

Individual TWT provides the most power savings because the schedule is tailored to each device's specific needs. A device with no data to send can sleep through its service period after a brief check-in, while a device with a full buffer can use the entire wake duration for data transfer.

Broadcast TWT

Broadcast TWT (bTWT) uses a single schedule announced by the AP that multiple clients follow simultaneously. The AP advertises broadcast TWT parameters in its beacon frames. Clients that want to join the broadcast TWT group simply follow the announced schedule without individual negotiation.

This is simpler to manage than individual TWT when many devices have similar requirements. In a warehouse with 500 WiFi-connected inventory sensors that all report every 30 seconds, broadcast TWT lets the AP announce one schedule that all sensors follow, rather than maintaining 500 individual TWT agreements.

graph TD
    subgraph "Individual TWT"
        AP1[Access Point] -->|iTWT Agreement 1| S1[Sensor - wake every 60s]
        AP1 -->|iTWT Agreement 2| S2[Lock - wake every 5s]
        AP1 -->|iTWT Agreement 3| S3[Camera - wake every 500ms]
    end
    subgraph "Broadcast TWT"
        AP2[Access Point] -->|bTWT Schedule in Beacon| GROUP[All sensors follow same schedule]
        GROUP --> BS1[Sensor 1]
        GROUP --> BS2[Sensor 2]
        GROUP --> BS3[Sensor 3]
        GROUP --> BS4[Sensor N - up to hundreds]
    end

Individual TWT creates per-device schedules - broadcast TWT applies one schedule to many devices at once

Battery Life Impact

The numbers tell the story. A WiFi device using legacy power save with a 100ms beacon interval spends roughly 5-10% of its time with the radio active just for beacon monitoring. At 150mW average radio power, that translates to 7.5-15mW of continuous power draw from beacon checking alone.

With TWT and a 60-second wake interval, the radio is active for perhaps 10 milliseconds every 60 seconds - about 0.017% duty cycle. The average power from radio activity drops to roughly 0.025mW. That is a 300x to 600x reduction in radio-related power consumption.

For a device with a 1000mAh battery at 3.3V (about 3.3Wh), legacy power save might deliver weeks to a few months of battery life depending on the device's other power draws. With TWT and a low duty cycle, the WiFi radio power consumption becomes negligible compared to the microcontroller and sensor power draws, potentially extending total device life to over a year.

These numbers make WiFi competitive with BLE for many IoT applications where it previously could not compete. The advantage of WiFi for IoT is direct IP connectivity - no gateway translation layer needed, standard TCP/UDP/HTTP protocols work directly, and existing network infrastructure can be reused.

Comparison to BLE Power Saving

BLE achieves its low power consumption through a similar principle: scheduled communication windows called connection intervals. A BLE peripheral and central agree on a connection interval (typically 7.5ms to 4 seconds) during which they exchange data. Between intervals, both devices can sleep.

TWT and BLE connection intervals solve the same problem but at different scales. BLE connection intervals are measured in milliseconds to low seconds. TWT intervals can stretch to minutes or hours. BLE's radio consumes roughly 10-15mW when active, while WiFi consumes 100-300mW. But TWT compensates by allowing much longer sleep periods and transmitting more data per wake cycle thanks to WiFi's higher throughput.

For applications that need to transmit large payloads infrequently - firmware updates, image captures, bulk sensor data uploads - WiFi with TWT can be more energy-efficient than BLE because it completes the transfer faster despite the higher radio power. For applications that need frequent small updates, BLE's lower radio power still wins.

The BLEShark Nano and ESP32-C3 Power Modes

The BLEShark Nano uses an ESP32-C3 microcontroller, which supports several power-saving modes for its WiFi radio:

Modem sleep: The WiFi radio turns off between DTIM beacon intervals. The CPU stays active. Power consumption drops from about 130mA to roughly 20mA. This is the ESP32-C3's equivalent of legacy WiFi power save.

Light sleep: Both the WiFi radio and CPU clock are gated. The device wakes on WiFi events or timer interrupts. Power drops to about 130 microamps.

The ESP32-C3 does not support WiFi 6 or TWT - it implements 802.11b/g/n on 2.4GHz. TWT is an access point-side feature that requires WiFi 6 capability on both endpoints. However, understanding TWT is relevant for anyone using the BLEShark Nano to analyze WiFi 6 networks. When scanning for APs, the Nano can detect TWT support advertised in beacon frames through the HE capabilities element. Networks with TWT-enabled clients may show unusual traffic patterns - long periods of silence followed by brief bursts of activity - that reflect the scheduled wake behavior.

The BLEShark Nano's own 500mAh battery benefits from the ESP32-C3's modem sleep and light sleep modes during passive scanning operations, extending operational time beyond what continuous radio activity would allow.