Wi-Fi6 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 more efficient use of the available spectrum and improves overall network performance.

2. TWT activation and deactivation (teardown)

Activate the TWT mode on a ST67W611M1 STA by following the steps below. Refer to the page ST67W611M Wi-Fi® – CLI Project for more details on the FW CLI commands of TWT.

• Scan and connect the ST67W611M1 module STA to an AP that supports Wi-Fi6. The OpenWrt must already installed be on the AP ASUS RT-AX53U.

• Send the CLI command wifi_twt_setup to configure TWT. To activate TWT, it is necessary to deactivate DTIM power save mode before starting with wifi_twt_setup. The command sequence is as follows:

powersave 0

dtim 0

wifi_twt_setup

• Send wifi_twt_set to activate TWT.

• TWT Teardown:

wifi_twt_teardown 2

3. TWT configuration

This section explains the wifi_twt_setup command needed to configure TWT.

wifi_twt_setup is a command with five arguments: wifi_twt_setup setup type, flow type, Wake Interval Exponent, SP, Wake Interval mantissa

For example, wifi_twt_setup 1 1 13 128 1000 configures:

• Setup type = REQUEST
• Flow type = UNANNOUNCED. ANNOUNCED mode is not supported.
• Wake Interval = $1000\times 2^{13}$= 8192000 us = 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) us + 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) us" 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.

4. STA and AP TWT communication as a function of the STA setup type and the AP configuration

1^St step: Upon sending the wifi_twt_set to activate TWT on the ST67W611M1 STA device, the STA sends a frame containing a TWT element that contains a value of Request TWT, Suggest TWT, or Demand TWT in the TWT command field and with the TWT request field equal to 1.

2^nd step: The previously mentioned STA TWT element is received by the associated AP that supports TWT. The AP replies by a TWT element to the STA. This AP transmitted TWT element includes a value of Accept TWT, Alternate TWT, Dictate TWT, or Reject TWT in the TWT command field of the response and sets the TWT request field to 0.

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 modified request for TWT while modifying the parameters of the initial request to indicate, for example, an acceptance of a proposed alternate TWT or dictated TWT value.

4^th step: If the STA receives an Accept TWT response to its modified TWT request, then the STA has successfully completed the TWT setup, and it enters the doze state.

5^th step: STA doze state comes to an end when the timing synchronization function TSF timer matches the next TWT value of the STA, knowing that the service period (SP) start time is the value of the timing synchronization function (TSF) at the beginning of SP.

In summary, the setup type can be one of following possibilities:

0: REQUEST: The target wake time field of the TWT element is set to 0 as the responding STA/AP specifies the target wake time value in this case. Other fields are suggested by requesting STA.

1: SUGGEST: TWT requesting STA suggests the target wake time and other parameters during setup. The responding STA may / may not accommodate the suggested value. TWT connection is still be accepted with values suggested by requesting STA or the values provided by responding STA.

2: TWT grouping (detailed in the following section): TWT responding STA suggests TWT group parameters that are different from the suggested or demanded TWT parameters of the TWT requesting STA.

3: Accept TWT: TWT responding STA accepts the TWT request with the TWT parameters indicated in the TWT element transmitted by the responding STA.

4: Alternate TWT: TWT responding STA suggests TWT parameters that are different from TWT requesting STA suggested or demanded TWT parameters.

5: Dictate TWT: TWT responding STA demands TWT parameters that are different from TWT requesting STA TWT suggested or demanded parameters.

6: Reject TWT: TWT responding STA rejects TWT setup. NOTE: TWT Parameters are TWT, Nominal Minimum TWT Wake Duration, TWT Wake Int.

5. TWT grouping

TWT grouping is an enhancement of the above explained normal TWT mechanism. It allows multiple devices to share the same wake time, forming a group. This is particularly useful in environments with many devices, such as smart homes or industrial IoT deployments.

An AP can include an STA as a member of an existing TWT group. This is possible if the STA indicates its support for TWT grouping in its (Re)association request frame. The STA can also signal TWT times to an STA using the TWT group assignment field of the TWT element.

In return, the TWT supporting AP may assign a TWT group ID to the STA, and the AP indicates the TWT value to the STA by transmitting an individually addressed frame containing a TWT element, which includes:

• The value of the assigned group ID in the TWT group ID subfield.
• The TWT value corresponding to the first member of the TWT group that is identified by the TWT group ID.
• A TWT unit value in the TWT unit subfield.
• A positive offset value indicated in the TWT offset subfield. It indicates the STA wake time as an offset relative to the 1^st group member wake time. The allowed values are given in Table 9-298 of IEEE802.11-2020.

The intended recipient of the frame containing the TWT element calculates its TWT from the TWT group assignment field by multiplying the TWT unit interpretation value with the value indicated in the TWT offset subfield. This result is then added to the value in the zero offset of group field corresponding to the TWT group ID subfield in the TWT group assignment field of the TWT element. For more details, refer to Section 10.47.5 of IEEE802.11-2020.

6. TWT sleep time

As indicated in Section 9.4.2.199 of IEEE802.11-2020, the TWT element that was mentioned in paragraph 3 can be presented as follows,

along with the request type:

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

Therefore, 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}$ usec = 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 doze states, it is important to take into consideration timeouts such as TCP server timeout, and cloud server timeout (Google, Microsoft, etc.).

7. TWT performance testing

The figure below depicts the measurement setup to measure the TWT performance by measuring TWT power consumption print. 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)

8. TWT performance measurement

This section presents an example of TWT current consumption measurement. The measurement is done in TWT mode between ST67W611M1 and ASUS RT-AX53U access point.  

The configuration is as follows:

wifi_twt_setup 1 1 17 255 2289

which corresponds to:

1. Doze state duration = 2289*2¹⁷= 300023808 us = 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)
   

9. Clock drift

When testing with long TWT wakeup intervals, 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 ST67W611M1 and the AP. These samples are used to calculate a more accurate wake-up point.

Later, 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.

10. TWT power consumption

The measurements are done in TWT mode between 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 uA when there is no activity (i.e. in deepsleep 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 = 32ms	Average Current consumption SPmax = 64ms	Unit
TWT 1s	2762	4755	uA
TWT 10s	339.3	529	uA
TWT 20s	205.3	312	uA
TWT 30s	159.6	195	uA
TWT 1min	128.3	147.5	uA
TWT 5min	87.3	92	uA
TWT 10min	81	86	uA
TWT 20min	79.6	81.3	uA
TWT 30min	79.2	79.3	uA
TWT 1h	79.1	79.2	uA

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. Here's a general guideline 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 smart phones. 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).

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 health data. This allows for more multiple transmissions and using a low data rate to minimize packet loss.