Wi-Fi 6 Target Wake Time (TWT)

	Back to main page

1. Target Wake Time (TWT)

Target Wake Time (TWT) is a feature introduced in the Wi-Fi 6 (802.11ax) standard. It provides several benefits, particularly for lowering the power consumption in battery-operated devices, and for enhancing Wi-Fi network efficiency.

• Power consumption improvement

This is especially beneficial for IoT devices. TWT allows devices to negotiate when and how often they wake up to send or receive data. This reduces the amount of time a device's radio needs to be active, significantly conserving battery life.

• Enhanced network efficiency

By scheduling specific wake times for devices, TWT reduces contention and collisions on the network. This leads to a more efficient use of the available spectrum and improves overall network performance.

2. TWT activation

Please refer to ST67W611M1 Wi-Fi® – CLI Projects for more details on the TWT CLI commands mentioned on this page.

To start a new TWT session, the ST67W611M1 STA has to be connected first to an AP that supports TWT. Then the user needs to send the CLI commands below to put the STA in power-save mode and to start the TWT session:

powersave 1

wifi_twt_setup

wifi_twt_setup is the command that configures and starts TWT. It has five arguments as shown below:

wifi_twt_setup setup type flow type Wake Interval Exponent SP Wake Interval mantissa

For example, wifi_twt_setup 1 1 13 128 1000 starts a TWT session with the following configuration:

• Setup type = REQUEST
• Flow type = UNANNOUNCED. ANNOUNCED mode is not supported.
• Wake Interval = $1000\times 2^{13}$= 8192000 µs = 8192 ms. During the wake interval, the STA is in a low power or SLEEP mode, also known as the “doze state”.
• SP (service period defines the time of STA activity) = (256*128) µs + 12 ms time needed to complete SW and HW initialization at wake-up + 2 ms to account for clock drift between the ST67W611M1 clock and the application clock, + 2.25 ms time needed to complete SLEEP preparation and go back to SLEEP at the end of the SP = 49 ms. The "(256*128) µs" part of the equation is known as the AdjustedMinimumTWTWakeDuration in the IEEE802.11-ax standard. A device may stay awake for longer than the AdjustedMinimumTWTWakeDuration based on several factors that influence its communication needs and network conditions. Some key reasons why a device might extend its wake duration:
  • Data traffic volume: If there is a higher volume of data to be transmitted or received than anticipated
  • Quality of Service (QoS) requirements: Certain applications, such as video streaming or online gaming, have specific QoS requirements that might necessitate longer wake durations to maintain performance and minimize latency.
  • Environmental factors: Changes in the wireless environment, such as interference or signal degradation, might necessitate longer communication periods to ensure data integrity and successful transmission.

3. TWT deactivation (teardown)

Stopping a TWT session is done through the following teardown CLI command:

wifi_twt_teardown

4. STA and AP TWT communication

After connecting the ST67W611M1 STA to an AP that supports TWT, the following communication steps happen between the STA and the AP to establish a TWT session:

1^st step: Upon sending the wifi_twt_setup to activate TWT on the ST67W611M1 STA device, the STA sends a frame containing a TWT element. This TWT element includes a TWT request field equal to 1, and a "Request TWT", "Suggest TWT", or "Demand TWT" in the TWT command field.

2^nd step: On the AP side, the TWT element is received by the AP. The AP replies by sending a TWT element to the STA. This TWT element includes a value of Accept TWT, Alternate TWT, Dictate TWT, or Reject TWT.

3^rd step: If the AP TWT command field includes anything other than Accept TWT or Reject TWT (i.e. Alternate TWT or Dictate TWT), the STA should send a new request for TWT (1^st step) with a different TWT configuration.

4^th step: If the ST67W611M1 STA receives an Accept TWT response, that means that the STA has successfully completed the TWT setup, it enters in a Deep Sleep state (also known as "doze state").

5^th step: The ST67W611M1 STA wakes up when the Deep Sleep state comes to an end after a period determined by the wake interval. TWT Wake Interval is explained is next.

6^th step: After waking up from Deep Sleep, the ST67W611M1 stays active (exchange of data with the AP) during what is known as the Service Period (SP).

5. TWT wake interval

In IEEE802.11-2020, Section 9.4.2.199 presents the TWT wake interval as follows:

TWT wake interval =$TWT\ Wake\ Interval\ Mantissa\times 2^{(TWT\ Wake\ Interval\ Exponent)}$ microseconds.

The TWT wake interval Mantissa is a 2-byte field with a maximum value of 65,535. TWT wake interval exponent is a 5-bit field and its maximum value is 31. Consequently, the maximum TWT wake interval $65,535\times 2^{31}$ µsec = 4 years, 5 months, 16 days, 13 hours, 37 minutes, 39.49 seconds.

As demonstrated above, TWT allows for battery life over several years by using long sleep times. However, when configuring long wake intervals, it is important to take into consideration timeouts such as TCP server timeout, and cloud server timeout (Google, Microsoft, etc.).

6. TWT performance testing

The figure below depicts the measurement setup to measure the TWT performance by measuring TWT power consumption print. For more details, refer to the ST67W611M1 power consumption measurement dedicated Wiki page.

The measurement setup is composed of:

• Host: Nucleo U575ZI-Q
• DUT: ST67W611M1
• FW: ST67W611M1 loaded with FW version 2.0.75. STM32U5 loaded with CLI project
• STLINK-V3SET as an ammeter
• Lab PC to send commands to the DUT and to control STLINK-V3SET current measurements
• STLINK-V3SET is connected to the ST67W611M1 board to measure the I_RF (shown in the figure below)

7. TWT performance measurement

This section presents an example of TWT current consumption measurement. The measurement is done in TWT mode between the ST67W611M1 and a Wi-Fi 6 AP.  

The configuration is as follows:

wifi_twt_setup 1 1 17 255 2289

which corresponds to:

1. Doze state duration = 2289*2¹⁷= 300023808 µs = 300 sec = 5 min. This is shown by the green arrows on the first measurement plot of this section.
2. The max service period SP = SP_255 = 81 ms (as shown in the second measurement plot)
   

8. Clock drift

When testing with long TWT wakeup intervals, the ST67W611M1’s clock drifts from the AP’s clock, causing wake-up misalignment.

A least-square linear regression algorithm is used to estimate and adjust this drift. After enabling TWT, the device sends one probe request every 10 seconds for ten times to collect timestamp deviation patterns between the ST67W611M1 and the AP. These samples are used to calculate a more accurate wake-up point.

After this, probe request intervals are extended to 120/180 seconds to gradually update the sample data and maintain clock alignment.

The above explained TWT power consumption measurement shows the behavior of the probe requests used to solve the clock drift issue.

9. STA-Router connection during TWT

In general, in the case of long periods of inactivity, an STA needs to periodically send a KEEP_ALIVE traffic signal to the router in order to prevent disconnection. To guarantee a continuous connection, the router idle timeout needs to be longer than the STA KEEP_ALIVE period.

Many routers perform the KEEP_ALIVE task through a simple traffic detection, without a complete check that the traffic corresponds to a KEEP_ALIVE or not. In some cases, a null-data frame (regular data packet with an empty payload) or even a management frame (such as the probe request that is used during TWT) is sufficient for the router to maintain the connection with the STA. Other routers do not disconnect the STA even if it is inactive and not sending KEEP_ALIVE at all. There are also routers that drop the STA if it remains silent for too long. However, these non-standard behaviors cannot be generalized to all routers. Therefore, it is a good practice to send KEEP_ALIVE during TWT mode (55 sec is a commonly used period for the KEEP_ALIVE).

Notice that the KEEP_ALIVE can be deployed independently from TWT, i.e. TWT STA can send KEEP_ALIVE during or outside the SP.

10. TWT power consumption

The measurements are done in TWT mode between the ST67W611M1 and ASUS RT-AX53U access point.

The following TWT current consumption measurements are done using the X-Nucleo on-board Xtal. The board under test has an average current consumption of 64 µA when there is no activity (i.e. in Deep Sleep and while no hcp_coarse_tmr or probe request activity). Current consumption measurement is done after the initial phase of the probe requests.

Mode	Average Current consumption SP = 32 ms	Average Current consumption SPmax = 64 ms	Unit
TWT 1s	2762	4755	µA
TWT 10s	339.3	529	µA
TWT 20s	205.3	312	µA
TWT 30s	159.6	195	µA
TWT 1min	128.3	147.5	µA
TWT 5min	87.3	92	µA
TWT 10min	81	86	µA
TWT 20min	79.6	81.3	µA
TWT 30min	79.2	79.3	µA
TWT 1h	79.1	79.2	µA

11. Real-life examples

By strategically selecting the service period and wake interval based on application needs, Wi-Fi 6 TWT enhances both power efficiency and network performance, making it a solution for a wide range of modern applications. SP and wake interval (WI) durations are configured based on:

• Data rate requirements: Higher data rates necessitate shorter SPs and WIs.
• Power consumption: Battery-powered devices must benefit from longer WI to extend battery life.
• Latency sensitivity: Applications sensitive to delays require shorter WI to ensure responsiveness.

TWT is particularly useful for battery-powered devices (e.g. Smartphones and IoT), which often have different power and data transmission requirements. The following sections provide general guidelines for setting wake intervals and service period durations for various devices.

11.1. Smartphones

TWT allows for efficient power management that is crucial to extend battery life in smartphones. A performant TWT configuration for smartphones can be as follows,

Wake interval: Short to medium (e.g., 100 ms to 1 second).

Service period duration: Medium to high (above 40 ms).

This configuration is recommended for the following reasons:

• Frequent connectivity needs: Short to medium WI is needed because smartphones require frequent connectivity for various applications, notifications, and real-time updates.
• User experience: Shorter wake intervals ensure that the device remains responsive to user interactions and background tasks.
• Data throughput needs: Smartphones often handle a moderate to high volume of data due to applications, notifications, and background processes. A medium service period ensures that these data needs are met without excessive latency.

11.2. Temperature sensor

Wake interval: Long (e.g., 1 minute to 10 minutes)

Service period duration: Short (e.g., 5 ms to 10 ms)

• Temperature sensors generally and infrequently transmit data and can afford longer sleep periods to conserve battery life.
• Low data volume: The amount of data transmitted is minimal, allowing for shorter service periods.

11.3. Blood pressure sensor

Wake interval: Medium to long (e.g., 30 seconds to 5 minutes)

Service period duration: Medium (e.g., 20 ms to 40 ms)

• Blood pressure sensors might need to transmit data periodically (during health monitoring sessions), but not continuously, allowing for longer wake intervals.
• Data accuracy: The data transmitted by the sensor is very little. However, a medium service period is important to ensure the sensor has a wakeup that is long enough to transmit the life-critical health data. This allows for more multiple transmissions and using a low data rate to minimize packet loss.

11.4. Smoke detector

Wake interval: Very short (few seconds)

Service period duration: medium (e.g., 20 ms to 40 ms)

• Immediate responsiveness: Smoke detectors must be able to send alerts instantly when smoke is detected. A very short wake interval ensures that the device is always ready to transmit critical alerts without delay.

• Data accuracy: As in the case of the blood pressure sensor, the data transmitted by the sensor is very small. However, a medium service period is important to ensure the sensor has a wakeup that is long enough to transmit the life-critical data. This allows for more multiple transmissions and using a low data rate to minimize packet loss.