Wi-Fi networks have long struggled with contention, where multiple devices compete for access, leading to delays and inefficiencies. Target Wake Time (TWT) was introduced to address this by allowing an access point (AP) to schedule transmissions efficiently, ensuring that a station (STA) has a dedicated service period without interference. However, TWT has a significant limitation—it doesn’t guarantee these service periods. If a legacy Wi-Fi STA transmits during an 802.11ax client’s TWT SP slot, the schedule can be disrupted, forcing the AX STA to wait despite its assigned time.

To address this challenge, 802.11be introduces Restricted-TWT (r-TWT)—an improved scheduling mechanism designed to reduce contention and enhance reliability. Unlike traditional TWT, r-TWT imposes stricter control over transmission access, ensuring that scheduled service periods remain undisrupted.

Objective:

This blog will delve into the theoretical aspects of r-TWT, explaining its operational principles and how it refines the scheduling process. This discussion will offer deeper insights into r-TWT’s role in enhancing Wi-Fi performance and addressing the scheduling inefficiencies observed in TWT.

We’ll also discuss how r-TWT enhances scheduling efficiency and enforces stricter transmission control, ensuring that designated service periods remain uninterrupted for the Wi-Fi 7 clients.

Introduction to r-TWT:

RTWT, or Restricted Target Wake Time, is a pivotal feature introduced in Wi-Fi 7 (IEEE 802.11be), building upon the Target Wake Time (TWT) mechanism from Wi-Fi 6. While TWT focuses on power efficiency by scheduling device wake times, RTWT extends this to reserve specific time slots for certain stations, ensuring exclusive channel access. This is crucial for real-time applications requiring low latency and high reliability, such as online gaming, video conferencing, and industrial automation.

Technical enhancements in r-TWT:

The r-TWT feature is an enhanced feature of Broadcast TWT from 802.11ax. With this r-TWT enhancement in the broadcast TWT, the STAs are provided a guaranteed service period.

How to check whether the AP and STA support r-TWT?

• The TWT Requester Support subfield to 1 in the HE Capabilities element that if it supports operating in the role of a TWT requesting STA; otherwise, to 0.
• The TWT Responder Support subfield to 1 in the HE Capabilities elements that if it supports operating in the role of a TWT responding STA(Access Point); otherwise, it is 0.
• The Broadcast TWT Support subfield to 1 in the HE Capabilities element that it transmits if it supports operating in the role of a TWT scheduled STA or in the role of a TWT scheduling AP; otherwise, to 0.

The capabilities field of the STA’s Association Request frame shows support as a TWT requester and support for broadcast TWT.

The actual r-TWT feature support can be found under EHT Capabilities → EHT MAC capabilities

Note: The r-TWT feature requires the support for Broadcast TWT feature. The r-TWT feature will not work if the Broadcast TWT support is disabled.

r-TWT Operation

Before diving into r-TWT, we will first explore how Broadcast TWT functions.

Broadcast TWT:

If the AP supports Broadcast TWT, it includes the TWT-related parameters in the management frame by adding an extra element called “TWT.” Using this information, TWT-supported STAs can send a request to the AP for an opportunity to transmit during the SP. The AP then responds to the STA’s request, indicating whether it is accepted or not.

The TWT request/response messages are similar to the individual TWT Setup frames

TWT Setup Frame: This frame is the initial frame which is exchanged between the STA and AP to initiate the setup process of TWT. The AP will assign/allow a TWT Session period as a response to the STA. In the table below, I have listed all the possible types of TWT agreements sent from the STA and the responses it gets from the AP

During the setup phase, a station can negotiate two key parameters to optimize its wake-up schedule using an individual TWT agreement frame setup:

• Next Target Beacon: Specifies the next scheduled transmission of a Beacon containing TWT information relevant to the station, particularly for the Broadcast TWT session it belongs to.
• Listen Interval: Defines the time interval between consecutive Beacons that carry TWT-related information for the station.

Once these parameters are set, the station enters a doze state, waking only when the next scheduled Beacon is transmitted. These Beacons provide essential details about the Broadcast TWT session, ensuring stations adhere to the session schedule. Additionally, the AP may broadcast updates to the TWT parameter set, allowing all participating stations to stay synchronized.

Similar to Individual TWT agreements, a Broadcast TWT session can operate in a Trigger-enabled or non-Trigger mode and may be implemented as either Announced or Unannounced.

The enhanced version of Broadcast TWT is known as r-TWT. In this mode, the STA can prioritize latency-sensitive traffic using the TID UL/DL bitmap. Key rules to follow during the r-TWT SP include terminating TxOP before the r-TWT SP begins and implementing a Quiet session within the BSS.

The below chart represents the TWT element format, which includes the r-TWT parameters. The same will be added in the management frames (i.e., Beacons, Probe response) by the r-TWT supported AP to indicate the details about the Next TWT session and TID bitmap. The flowchart highlights fields closely related to the r-TWT session, while certain fields like Wake Duration, Mantissa Intervals, and TWT Bitmap Control fields are excluded. These fields are predefined and self-explanatory, whereas the focus here is on r-TWT-specific subfields.

A detailed explanation for the r-TWT subfields is provided below.

Negotiation Type:

The Negotiation Type field represents the type of TWT negotiation mode. The following table provides the bit value for each negotiation type

Note:

A broadcast TWT element advertising broadcast TWT schedules in Beacon frames uses a Negotiation Type value of 2, whereas a broadcast TWT element used in TWT Setup frames for negotiating or managing membership of the broadcast TWT schedules with an individual STA uses a Negotiation Type value of 3.

Target Wake Time: This indicates the start of the next TWT session

Broadcast TWT ID

This field represents the session ID. Each Broadcast TWT schedule is uniquely identified by the combination of the Broadcast TWT ID and the AP MAC address.

An AP can create a Broadcast TWT schedule for all STAs, assigned a Broadcast TWT ID of 0. In contrast, Broadcast TWT schedules meant for specific groups of member STAs have Broadcast TWT ID values greater than 0. To announce one or more Broadcast TWT schedules, the AP includes a Broadcast TWT element in its Beacon frames.

Broadcast TWT persistence:

This field indicates the number of TBTTs where the TWT SP is present or active.

r-TWT Schedule Info:

This r-TWT schedule info field provides details about the r-TWT session (e.g., Active, Full, etc.).

• • A bit value of 0 indicates that the schedule is suspended or idle.
  • A bit value of 1 signifies that the r-TWT schedule is active.
  • A bit value of 2 means the TWT group membership is full, and the AP may reject any r-TWT requests.
  • A bit value of 3 indicates that the session is active for a non-transmitted or co-hosted BSSID.

r-TWT traffic info:

This element specifies the UL/DL TID bitmaps for latency-sensitive traffic. It uses the following sub-fields to inform the STA about traffic prioritization:

• • r-TWT UL TID Bitmap
  • r-TWT DL TID Bitmap

Note:

The Restricted TWT Traffic Info field is included only in individually addressed TWT Setup frames for establishing an R-TWT schedule to negotiate the set of R-TWT UL and/or DL TIDs. This information is not present in R-TWT schedules advertised in the TWT element within Beacon frames.

r-TWT UL/DL TID Bitmap:

The Restricted TWT DL TID Bitmap and Restricted TWT UL TID Bitmap subfields define the TIDs identified by the R-TWT scheduling AP or R-TWT scheduled STA as latency-sensitive traffic streams for downlink and uplink, respectively.

• • A bit value of 1 at position “x” in the bitmap indicates that “TID x” is classified as a latency-sensitive traffic stream.
  • A bit value of 0 at position “x” indicates that “TID x” is not classified as a latency-sensitive traffic stream.

How r-TWT ensures guaranteed SP:

The following rules are followed in the BSS during r-TWT SP

• • All the transmitting r-TWT STAs should stop the transmission before the r-TWT SP starts
  • For the legacy devices, which are incapable of understanding the TWT, the AP will announce the Quiet period in the BSS by adding the Quiet element in management frames (Beacons, Probe, etc)and immediately the AP will start the r-TWT SP in parallel.
  • This mechanism ensures better control over network transmissions, reducing potential interference and improving scheduling efficiency in Wi-Fi 7 networks.

Establishing a r-TWT Session and operation with data transmission

The r-TWT-supported AP includes the TWT element in the management frame, allowing the r-TWT STA to initiate an individual TWT setup using TWT setup request frames. This process prioritizes latency-sensitive traffic based on TIDs. Once the AP sends a TWT accept frame, the STA wakes up during the r-TWT session period to receive data.

Additionally, the AP initiates a Quiet Period within the BSS simultaneously during the r-TWT SP to ensure no other STAs transmit data.

The following diagram [2] explains the r-TWT functionality,

All STAs support r-TWT

• • STA1 initiates r-TWT membership by sending a TWT setup request frame to the AP and receives an Accept frame (TWT response) in return.
  • STA2 retrieves the advertised r-TWT schedule from the management frame (Beacon frame), then sends a TWT setup request and receives an Accept response from the AP.
  • STA3 holds the TxOP but does not participate in the r-TWT setup or membership process.

When r-TWT begins, STA3 halts data transmission, relinquishes its TxOP, and receives a Block ACK from the AP. The AP then initiates the r-TWT SP by sending a Trigger frame to notify STA1 and STA2. Data transmission follows.

For legacy STAs (e.g., 802.11ax STAs), the AP enforces a Quiet Period within the BSS before the r-TWT SP begins, preventing them from transmitting or contending for the medium during the SP session.

Timing and Calculations

1. TWT Time: All TWT time interval calculations are based on the Time Synchronization Function (TSF). The STA listens to the AP’s beacon (TBTT) and synchronizes with the TSF of the frame to accurately determine service periods.

Conclusion

RTWT represents a significant advancement in Wi-Fi 7, addressing the needs of real-time applications by providing exclusive channel access during reserved time periods. It enhances QoS, reduces latency, and improves network efficiency, while also offering power-saving benefits. However, challenges such as compatibility with legacy devices, implementation complexity, and security considerations require careful management. As research and deployment continue, RTWT is poised to play a central role in the future of wireless connectivity, supporting the growing demand for time-sensitive networking in diverse applications.

References

1. IEEE 802.11be [D3.0]
2. WiFi-7 In Depth by Jerome Henry
3. IEEE 802.11ax 2021
4. Dedicated Restricted Target Wake Time for Real-Time Applications in Wi-Fi 7
5. Wi-Fi 7: The Next Frontier in Wireless Connectivity
6. Everything you need to know about Wi-Fi 7