# An Analytical Method to Configure TWT in WLANs

Esther Guérin, Thomas Begin, Isabelle Guérin-Lassous

► To cite this version:

Esther Guérin, Thomas Begin, Isabelle Guérin-Lassous. An Analytical Method to Configure TWT in WLANs. The 27th International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM 2025), IEEE, Oct 2025, Barcelone, Spain. hal-05401112

HAL Id: hal-05401112

https://hal.science/hal-05401112v1

Submitted on 5 Dec 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Analytical Method to Configure TWT in WLANs

Esther Guérin

Université Claude Bernard Lyon 1,
ENS de Lyon, CNRS, LIP 5668

Lyon, France

esther.guerin@ens-lyon.fr

Thomas Begin

Université Claude Bernard Lyon 1,
ENS de Lyon, CNRS, LIP 5668

Lyon, France

thomasimon@univ-lyon1.fr

Isabelle Guérin Lassous

Université Claude Bernard Lyon 1,
ENS de Lyon, CNRS, LIP 5668

Lyon, France

isabelle.guerin-lassous@univ-lyon1.fr

***Abstract***—Target Wake Time (TWT) is a promising energy-saving mechanism introduced in the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), enabling stations (STAs) to negotiate periodic service periods (SPs) with Access Points (APs) and thereby switch off their radio modules outside these intervals to conserve energy. Despite its potential, the standard lacks clear guidelines for configuring TWT parameters, and the existing literature remains limited. In this paper, we propose an analytical approach to adequately configure TWT parameter settings for individual STAs. We derive closed-form expressions for key performance metrics, namely, mean packet delay, packet loss rate, and average power consumption, based on TWT agreement parameters and the rate of traffic. Our model incorporates batch arrivals in both uplink and downlink directions and is validated through simulation. Building on this model, we present a configuration procedure that meets predefined Quality of Service (QoS) objectives and we illustrate its application through a case study involving video streaming.

***Index Terms***—Wi-Fi, 802.11, energy saving, parameters, performance.

## I. INTRODUCTION

Wireless Local Area Networks (WLANs) have become ubiquitous in our daily lives. In their classical implementation, they operate on the infrastructure mode of the 802.11 standard developed by IEEE. In this setup, every end-user Station (STA) must associate with an Access Point (AP) to obtain its wireless connectivity.

The IEEE 802.11 standard includes various energy-saving mechanisms (e.g., TIM, PS-Poll, U-APSD) with the most recent and currently most promising being Target Wake Time (TWT). In this paper, we focus on individual TWT, and unless stated explicitly, TWT here refers to individual TWT. In the TWT scheme, STAs and APs must first negotiate their TWT agreement for their traffic exchange. Among other things, TWT agreements define the duration and the periodicity at which Service Periods (SPs) between a STA and its AP occur. SPs can be viewed as time windows during which all traffic between the STA and its AP must be performed. Hence, outside these SPs, a STA can turn off the radio module of its Network Interface Card (NIC) to save energy. As often, IEEE provides no guidelines in its 802.11 standards on how

to effectively configure the values of the TWT agreement parameters. Analogously to the Modulation Coding Scheme (MCS) selection, the TWT parameters' configuration is left to the discretion of the NIC manufacturers. However, as pointed out by a recent study [17], an ill-configured TWT may reduce the STA's network performance without a significant energy saving. This may be particularly an issue for non-IoT STAs with intense traffic. We believe that this risk is yet another obstacle to the adoption of TWT in today's WLAN. Furthermore, the scientific literature devoted to TWT configuration is relatively scarce. We believe that this lack of clear guidelines on TWT configuration can be an additional obstacle to the adoption of TWT on today's WLANs.

In this paper, we propose an analytical-based procedure to effectively configure the parameter values of TWT. More specifically, the contributions of this paper are mostly twofold: (i) We derive closed-form expressions to evaluate the mean packet delay and loss packet rate given the parameters of a TWT agreement and the traffic rate between an AP and a STA; (ii) We detail a procedure to configure the parameters of TWT agreements to meet a given Quality of Service (QoS) objective for the traffic exchanged between an AP and a STA.

The remainder of the paper is organized as follows. Section II discusses the recent works related to our study. We use Section III to introduce TWT in detail. Section IV details our analytical performance modeling of a TWT agreement. In Section V, we use simulations to assess the accuracy of our TWT model. Section VI shows how to configure the TWT parameters of a STA given the nature of the traffic exchanged with its AP. Section VII concludes this paper.

## II. STATE OF THE ART

In this section, we survey the main studies on TWT. [11] is one of the first papers to describe the different options of the TWT mechanism and to evaluate a combination of these options (trigger-enabled individual TWT, see Section III-C). With a home-made simulator in C++, the authors evaluate, among others, the packet delay according to the level of load per STA and with fixed non-overlapping SPs, each of 20 ms. In [5], the authors propose an optimization method to configure the parameters of the broadcast TWT mechanism with the aim of maximizing the throughput. They evaluate

This work was funded by the French National Research Agency (ANR) under the project ANR FACTO (ANR-21-CE25-0020).
their solution with MATLAB simulations. In [13], the authors describe an adaptive sizing solution of the TWT parameters based on a traffic classification and a monitoring of the transmitted / received traffic. The proposed solution has been implemented and tested on a real smartphone. In [7], a scheduling solution of the R-TWT SPs (Restricted-TWT expected in IEEE 802.11be) is implemented in the openWiFi software-defined radio platform [8]. R-TWT is also studied in [4]. In this paper, the authors design an analytical model to derive the low-priority flow throughput when R-TWT is used. All these works focus their study on network performance indices like throughput and delay without considering energy consumption, neither in the design of the solutions, nor in their evaluation. TWT is mainly considered here as a mechanism to improve throughput and delay.

The authors of [3], [9], [14], [16] focus their study on the power consumption of the TWT mechanism. In [14], they use the ns-3 simulator to compare TWT, PS-Poll, and wake-up radio mechanisms for varying periodicity of the SPs and with possible clock drifts. The simulated scenario consists of several STAs that receive Poisson traffic from an AP with background traffic in the network. The obtained results tend to indicate that no mechanism outperforms the others in reducing the power consumption for all the tested periodicities of the SPs: each mechanism consumes the least energy within a certain range of periodicity values. Recently, the authors of [16] implemented a TWT model in the simulator ns-3 with the possibility to schedule multi-user transmissions. They study the impact of the TWT parameters with ns-3 on performance metrics like throughput, latency and energy efficiency. In their tested scenarios, the authors only consider upstream traffic.

In [3], the authors propose mathematical models of these three energy-saving mechanisms for evaluating the power consumption and the average packet delay. The models assume downstream Poisson traffic. In [9], the author proposes an optimization algorithm that jointly adapts the periodicity of the SPs and the scheduling of the STAs among SPs based on the evolution of the STAs' buffer size. However, their study is restricted to the upstream traffic. In [6], we compare by simulation several Wi-Fi energy-saving mechanisms. In this work, we explore multiple configurations of parameters for these mechanisms and show that some of them can be efficient in terms of throughput and energy consumption.

Some Wi-Fi products already include the TWT mechanism and some studies evaluate, via real experiments, the energy gain when TWT is enabled on commercial off-the-shelf devices. In [10], for scenarios with multiple STAs and intensive traffic, the authors show that TWT is significantly more energy efficient than CSMA/CA and Orthogonal Frequency-Division Multiple Access (OFDMA), without Power Save mode. However, the experimental results obtained in [17] show that the use of TWT does not always result in a power consumption reduction. The authors conclude that the static configuration of the TWT parameters, not configurable in the tested devices, is not adapted to a large range of applications with different traffic demands.

To conclude, the work of [17] underlines the importance of adapting the TWT mechanism's parameters to the type of traffic. But, as far as we know, no study provides a solution to configure the TWT parameters considering both packet loss, packet delay and energy consumption according to the type of traffic that the STA exchanges with its AP.

### III. DESCRIPTION OF TWT

#### A. IEEE 802.11

The IEEE 802.11 standard belongs to the family of listen-before-talk protocols. More precisely, devices (be they APs or STAs) apply the so-called *carrier sensing multiple access/collision avoidance* (CSMA/CA) mechanism to avoid collisions when accessing the radio medium. In essence, a device using CSMA/CA must wait for the medium to be free (i.e., without ongoing transmission), and then further wait a backoff period of random duration, before transmitting a pending packet.

#### B. TWT agreements

TWT was primarily designed as a scheduling mechanism and extended to become an energy-saving mechanism. In a nutshell, TWT operates by periodically restricting the upstream, and optionally downstream, traffic of STAs. TWT begins with a TWT agreement between one STA (or a group of STAs) and its associated AP. This agreement defines a sequence of periods called *Service Periods* (SPs), during which the STA is authorized to transmit. Outside these SPs, the STA is prohibited from transmitting. We refer to the periods complementary to SPs as the *Restricted Periods* (RPs). Note that SPs and RPs are mutually exclusive and exhaustive. The AP is in charge of scheduling the SPs of the different TWT agreements, with generally the objective of maximizing the overall throughput of the WLAN. On the other hand, each STA must ensure that the SPs defined in its TWT agreement can meets its specific QoS requirements, and if desired, lead to enable-saving.

In this work, we assume that both upstream and downstream traffic are restricted with TWT. Analogous to upstream traffic, downstream traffic can only be transmitted from the AP to the STA during the SPs defined by a TWT agreement.

Figure 1 illustrates the behavior of TWT for packets generated at the AP and destined for a STA. On the left side of the figure, TWT is not used, allowing the AP to transmit packets immediately, subject only to CSMA/CA-induced delays. On the right side, TWT is enabled for the STA's downstream traffic. Packets 1 and 2 are generated during an RP and must therefore wait until the next SP to be transmitted. In contrast, Packet 3 is generated during a SP and can be transmitted shortly after its generation.

A STA can operate in either active mode or Power Save mode. In active mode, the STA's radio remains constantly on, with no attempt to conserve energy. The primary objective in this mode is to reduce packet collisions among WLAN nodes (i.e., the AP and other STAs). Therefore, TWT restrictions apply only to the STA's upstream traffic.
<figure><img src="image_2.png" /><figcaption>Fig. 1: Transmission of packets without TWT (left part) and with TWT (right part). During the RP, the STA turns off its radio.</figcaption></figure>

Conversely, when operating in Power Save mode, the STA periodically turns off its radio, entering into a *doze state*. During each of its RPs, the STA dozes and cannot transmit or receive packets, allowing it to save energy. As a result, TWT restrictions apply both to upstream and downstream traffic. Note that if the SPs and RPs are poorly configured, the STA may miss downstream packets coming from the AP. This underlines the importance of properly configuring TWT parameters, namely the duration and periodicity of SPs and RPs, to ensure that the STA can safely enter doze states. In this paper, we focus on the case where the STA operates in Power Save mode.

### C. Implicit, non trigger-enabled, individual TWT agreement

TWT includes multiple options that we briefly discuss hereafter. For a detailed description of TWT, we refer the reader to [12].

A STA that is willing to use TWT can choose to either negotiate a new TWT agreement – then referred to as individual TWT agreement – or to join an existing broadcast TWT agreement (shared with other STAs). Note that the broadcast TWT mechanism requires participating devices to use OFDMA for their transmissions. In the case of an individual TWT agreement, the STA must decide if it is trigger-enabled or not. If the trigger-enabled option is selected, the STA must use OFDMA. If not, the STA can access the radio medium using either OFDMA or the regular CSMA/CA. Finally, the individual TWT agreement can be explicit or implicit. If implicit, the time interval between the beginning of two consecutive SPs is constant over time. Otherwise, the AP must notify the STA throughout each SP of the time at which the next SP will begin.

In this study, we focus on implicit, non trigger-enabled, individual TWT agreement (see Figure 2). This enables us to consider CSMA/CA for packet transmissions and to limit the amount of traffic overhead between the AP and its STAs.

### D. Parameters of TWT

Under this TWT setup, the main configuration parameters for a TWT agreement are *TWT Wake Interval* and the *Minimum TWT Wake Duration*, which together define when the SPs, or equivalently the RPs, start and finish. *TWT Wake Interval* determines the periodicity of SPs while *Minimum TWT Wake Duration* specifies the duration of SPs. Note that following the IEEE 802.11 standard's definition of individual TWT, there can be two distinct SPs in a TWT

agreement: one SP for its upstream traffic and one SP for its downstream traffic, denoted by UL SP and DL SP, respectively. While they typically start at the same time, they may finish at different times. Indeed, a DL SP may be interrupted if the AP sends a frame with the “End Of Service Period” (EOSP) flag raised to the STA. Unlike a DL SP, an UL SP unconditionally finishes after *Minimum TWT Wake Duration*. Since our study focuses on the TWT configuration of STAs, we equate the term SP with UL SP throughout the remainder of the paper. Figure 3 illustrates the restrictions applied by *TWT Wake Interval* and *Minimum TWT Wake Duration* on the upstream and downstream traffic of a STA.

<figure><img src="image_3.png" /><figcaption>Fig. 2: Considered options for TWT.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Fig. 3: Example of traffic restrictions with TWT. In the first SP, the AP and the STA exchange multiple packets. Since none of the corresponding frames has the EOSP flag raised, both the DL SP and the UL SP last a duration of *Minimum TWT Wake Duration*. In the second SP, the second frame transmitted by the AP has its EOSP flag raised; this prematurely ends the DL SP.</figcaption></figure>
## IV. PERFORMANCE MODELING

In this section, we develop our performance modeling of TWT. We establish closed-form expressions for key performance indices of a STA as a function of its traffic and the duration of its RPs. Note that we explain in Section VI how to use our performance modeling to configure the TWT Wake Interval and Minimum TWT Wake Duration parameters given a set of constraints on the STA performance indices.

### A. Scenario and main notation

We consider a STA running in Power Save mode and having negotiated an implicit, non trigger-enabled, individual TWT agreement with its AP. We use $T_{SP}$ and $T_{RP}$ to denote the duration of the SPs and RPs, respectively. We assume that the STA has a fixed physical data rate for the transmitting and receiving its packets. For the sake of readiness and without loss of generality, we assume that the two are equal, and we use $r$ to denote these rates. The size of buffers (in packets) for STAs and the APs is given by $l_{STAbuffer}$ and $l_{APbuffer}$, respectively. We model the downstream (resp. upstream) traffic of the STA by a series of packet batches. A batch is a set of multiple packets that are generated at the same time. Note that batches arrivals may be caused by congestion mechanisms (e.g., TCP window) or video bursts (e.g., Netflix, YouTube). The generation of the packet batches follow a Poisson process of parameter $\lambda_{DL}$ (resp. $\lambda_{UL}$) for the downstream (resp. upstream) traffic. With this assumption, downstream and upstream traffic are independent from one another in our modeling. We use $l_{DLbatch}$ (resp. $l_{ULbatch}$) to denote the length of batches (in packets) and $l_{DLpacket}$ (resp. $l_{ULpacket}$) to denote the length of packets (in bytes) within these batches. Note that if $l_{DLbatch} = 1$ (resp. $l_{ULbatch} = 1$), then the packet arrival process at the AP (resp. at the STA) becomes a simple Poisson process. Note also that we implicitly assume that the SPs are long enough to sustain, in the long run, the traffic exchanged between the AP and the STA. Otherwise, this means that the TWT agreement would be wrongly configured (under-dimensioned).

In return, the solution to our model produces estimates of key performance indices such as the average packet loss rate, denoted by $L$, and the average packet delay<fnref n="1" />, denoted by $D$, for the upstream and downstream traffic, as well as the average power consumption of the STA, denoted by $P$. Table I summarizes the main notation of our model.

### B. Model description and its solution

1) A SP as a series of cycles: As discussed previously, any packet generated (arriving) at the AP or at the STA during an RP must be queued in a buffer, with its transmission deferred until the next SP. During this SP, both the STA and the AP will attempt to transmit any queued packets. However, new packets may be generated during this process. This brings us to introduce the concept of a cycle of packet transmissions, which is central to our analysis.

<table><caption>TABLE I: Main notation of this paper.</caption><thead><tr><th>Parameter</th><th>Definition</th></tr></thead><tbody><tr><td>λ<sub>DL/UL</sub></td><td>Poisson parameters followed by the timestamps of the downstream / upstream traffic batches</td></tr><tr><td>l<sub>DL/ULbatch</sub></td><td>Size of the downstream / upstream traffic batches</td></tr><tr><td>l<sub>DL/ULpacket</sub></td><td>Size of the downstream / upstream packets</td></tr><tr><td>l<sub>APbuffer</sub></td><td>Size of the buffer for the AP</td></tr><tr><td>l<sub>STAbuffer</sub></td><td>Size of the buffer for the STA</td></tr><tr><td>r</td><td>MAC-layer data rate for packets transmission</td></tr><tr><td>P<sub>doze</sub></td><td>Power consumption of the NIC in doze state</td></tr><tr><td>P<sub>awake</sub></td><td>Power consumption of the NIC in awake state</td></tr><tr><td>e<sub>switch</sub></td><td>Energy consumed by the NIC when switching from awake to doze state and back</td></tr><tr><td>T<sub>RP</sub></td><td>Duration of the RP</td></tr><tr><td>T<sub>SP</sub></td><td>Duration of the SP</td></tr><tr><td>p(b, k)</td><td>Conditional probability to transition from the node (b, k − 1) to the node (b, k)</td></tr><tr><td>g(b, k)</td><td>Number of packets generated during the previous cycle</td></tr><tr><td>n(b, k)</td><td>Number of packets transmitted during the current cycle</td></tr><tr><td>t(b, k)</td><td>Average duration of the current cycle</td></tr><tr><td>d(b, k)</td><td>Average delay for the packets transmitted during the current cycle</td></tr><tr><td>L</td><td>Average packet loss rate of the considered STA</td></tr><tr><td>D</td><td>Average packet delay of the considered STA</td></tr><tr><td>P</td><td>Average power consumption of the considered STA</td></tr></tbody></table>

A cycle is the time interval within an SP required for the AP and the STA to successfully transmit all the packets queued in their buffer. Given that packet arrivals continue during the SP, one cycle may be immediately followed by another cycle. These cycles are contiguous and collectively they constitute a series of cycles. This series of cycles form a SP.

We now discuss several properties of these cycles. (i) By definition, the first cycle starts at the beginning of the SP; (ii) The first cycle may be null if no packets were generated during the previous RP; (iii) If no packets are generated during the first cycle, this cycle becomes the final cycle, thereby terminating the series of cycles for this SP. By doing so, we overlook in our model the possibility of a batch arrival occurring after the last cycle but before the end of the SP. However, as will be shown in Section V, this assumption does not compromise our model accuracy.

Overall, the number of cycles constituting a series of cycles can vary and we conveniently model it as a random variable.

Figure 4 illustrates the concept of cycles in the case of downstream traffic (from the AP to the STA). During the RP, two batches of two packets (representing a total of four packets) are generated (in orange) and must wait until the beginning of the SP. The time interval corresponding to their transmissions marks the first cycle. During this first cycle, two additional packets are generated (in blue), necessitating a second cycle for their transmission. With no further packets generated during the second cycle, the series of cycles finishes.

2) A tree diagram for the series of cycles: Owing to the stochastic nature of the traffic, the number of packets generated during a RP, or during a cycle, can vary. To account for all the possibilities of how the series of cycles within an SP may unfold, we build a probability tree diagram to model them. Figure 5 depicts an example of such a tree diagram.

<footnote n="1">¹Strictly speaking, this corresponds to a frame delay.</footnote>
<figure><img src="image_5.png" /><figcaption>Fig. 4: In this example, one cycle is required to process the packets generated during the RP, and an additional cycle is needed to process generated during the previous cycle. This results in a series composed of two cycles.</figcaption></figure>

Each node of the diagram represents a possible state of the series of cycles making up the SP. The root node of the diagram corresponds to the state following the end of the RP. In this state, the upcoming SP, and a *fortiori* the first cycle, have not yet started. Each child node of a parent node corresponds to a possible evolution of the series following the last cycle of the parent node. If the parent node is the root node, then the child nodes correspond to the different states in which the series of cycles can be after the RP. These states depend on the number of generated packets during the parent node's last cycle (and the RP for the child nodes of the root node). The nodes of the diagram that correspond to a completed series of cycles are leaf nodes in the diagram because no further cycle will occur. The path between the root node to any leaf represents a possible series of cycles.

To navigate the tree diagram, we employ the following state description. Each leaf node is labeled incrementally starting from 1². Every node is then identified by a pair of coordinates: (b, k) where b (b ≥ 1) designates the b-th leaf and k (k ≥ 1) denotes the level of depth along the path from the root node to this leaf. For instance, in Figure 5, (1, 1) identifies leaf 1 and (2, 1) identifies the parent node of leaf 2, namely node A.

For every node (b, k) of the tree diagram, we introduce the following notation:

* $p(b, k)$: the conditional probability to transition from the parent node of (b, k), i.e., (b, k - 1) to the node (b, k),

* $g(b, k)$: the number of packets generated during the previous cycle,

* $n(b, k)$: the number of packets transmitted during the current cycle,

* $t(b, k)$: the average duration of the current cycle,

* $d(b, k)$: the average delay for the packets transmitted during the current cycle.

By construction, $n(b, k) = g(b, k)$ unless packets were dropped due to buffer overflow during the previous cycle. Note also that a same node may correspond to several coordinates, e.g., node A in Figure 5 can be identified as both (2, 1) and (4, 1). Similarly, $p(2, 1)$ and $p(4, 1)$ designate the same condi-

tional probability, namely that from the root node to node A. The probability of occurrence of a series of cycles can be easily computed as the product of the conditional probabilities along the corresponding edges of the path between the root node to the leaf node representing this series of cycles

Figure 5 illustrates a tree diagram example. In this example, for simplicity, we consider batches consisting of exactly two packets and solely downstream traffic (i.e., from the AP to the STA). After the root node of Figure 5, the SP initiates the first cycle, which processes packets queued in the AP's buffer during the previous RP. The number of queued packets at the start of the SP can be any value multiple of two. However, in our example, we detail only the cases where this number is 0 or 2 or 4. If there are 0 queued packet, the cycle concludes immediately (with a duration of 0), marking the end of the series of cycles, and we transition to the leaf node labeled leaf 1. If there are 2 queued packets, the first cycle has a non-zero duration (specifically, the time required to transmit these packets). Hence, additional cycles may follow, and we transition to node A in the tree diagram. A similar process is repeated for node A. If there is 0 batch arrivals during the first cycle, we transition to leaf 2. Conversely, if batches arrive, we transition to a non-leaf node (e.g., node B if there is one batch arrival). Overall, this tree diagram exhibits a pattern where each new level of depth contains an infinite number of nodes, among which a leaf node represents the probability of no batch arrivals in the previous cycle. $p(2, 1)$ designates the conditional probability to transition from the root node to node A, namely that a single batch of packets arrives during the RP. $p(2, 2)$ stands for the conditional probability that no batch of packets arrive during the previous cycle given that the current state of the series of cycles is node A.

3) *Computing tree diagram parameters:* We now detail how we iteratively compute the parameter values of the tree diagram. Let us consider a given node (b, k) which is not a leaf node and assume that we know the duration of its current cycle, namely $t(b, k)$. This node will generate an infinite number of children whose coordinates are denoted by $(c, k+1)$ with $c \ge b$.

For every child node $(c, k+1)$, we carry out the following steps.

Thanks to the independence assumption between the downstream and upstream traffic and denoting by $N_{DL}$ (resp. $N_{UL}$) the number of downstream (resp. upstream) batches arrived during the previous cycle, we can compute the transition probabilities to every child node $(c, k+1)$ as follows, :

$$p(c, k+1) = \mathbb{P}(N_{DL} = i_{DL}) \times \mathbb{P}(N_{UL} = i_{UL}) \quad (1)$$

where the left and right terms of the product represent the probability that $i_{DL}$ ($\ge 0$) downstream batches and $i_{UL}$ ($\ge 0$) upstream batches are generated over $t(b, k)$, respectively.

<footnote n="2">²This label depends on the leafs' order of appearance when computing the tree diagram (see Section IV-B3).</footnote>
<figure><img src="image_6.png" /><figcaption>Fig. 5: The probability tree models the possible states of an ongoing series of cycles. Only leaf nodes correspond to completed series of cycles.</figcaption></figure>

Using the Poisson process properties, we have:

$$ 
\begin{aligned}
\mathbb{P}(N_{\text{DL}} = i_{\text{DL}}) &= \frac{(\lambda_{\text{DL}} \cdot t(b, k))^{i_{\text{DL}}}}{i_{\text{DL}}!} \times e^{-\lambda_{\text{UL}} \cdot t(b, k)} \\
\mathbb{P}(N_{\text{UL}} = i_{\text{UL}}) &= \frac{(\lambda_{\text{UL}} \cdot t(b, k))^{i_{\text{UL}}}}{i_{\text{UL}}!} \times e^{-\lambda_{\text{UL}} \cdot t(b, k)}
\end{aligned}
\quad (2) $$

Note that the child node for which $N_{\text{DL}} = N_{\text{UL}} = 0$ becomes a leaf node.

Next, we calculate the number of generated packets in the downstream, upstream, and both directions for every child node $(c, k+1)$:

$$ 
\begin{aligned}
g_{\text{DL}}(c, k+1) &= i_{\text{DL}} \times l_{\text{DLbatch}} \\
g_{\text{UL}}(c, k+1) &= i_{\text{UL}} \times l_{\text{ULbatch}} \\
g(c, k+1) &= g_{\text{DL}}(c, k+1) + g_{\text{UL}}(c, k+1)
\end{aligned}
\quad (3) $$

To account for the finite size of the buffers (which may cause packet losses due to buffer overflow), we calculate for every child node $(c, k+1)$ the number of transmitted packets in the downstream, upstream, and both directions:

$$ 
\begin{aligned}
n_{\text{DL}}(c, k+1) &= \min(l_{\text{APbuffer}}, g_{\text{DL}}(c, k+1)) \\
n_{\text{UL}}(c, k+1) &= \min(l_{\text{STAbuffer}}, g_{\text{UL}}(c, k+1)) \\
n(c, k+1) &= n_{\text{DL}}(c, k+1) + n_{\text{UL}}(c, k+1)
\end{aligned}
\quad (4) $$

Then, we compute the duration of every child node $(c, k+1)$ as follows:

$$ t(c, k+1) = \frac{n_{\text{DL}}(c, k+1) \times l_{\text{DLpacket}}}{r} + \frac{n_{\text{UL}}(c, k+1) \times l_{\text{ULpacket}}}{r} \quad (5) $$

In the absence of packet losses, the average packet delay for packets generated during the previous cycle would be half the duration of the previous cycle in the parent node, $t(b, k)$, plus half the duration of the current cycle, $t(c, k+1)$. However, packet losses can increase this delay. To compensate for this bias, we adjust the duration of the parent node cycle, $t(b, k)$, by a factor proportional to $1/2 \times \frac{n(c, k+1)}{g(c, k+1)}$ instead of $1/2$.

Note that $\frac{n(c, k+1)}{g(c, k+1)} \in [0, 1]$ and reflects the proportion of packets that are successfully transmitted. Therefore, for every child node $(c, k+1)$, we have:

$$ d(c, k+1) = \left(1 - \frac{1}{2} \times \frac{n(c, k+1)}{g(c, k+1)}\right) \times t(b, k) + \frac{1}{2} \times t(c, k+1) \quad (6) $$

We now address the special case of the first iteration. During this iteration, the current node is the root node, and queued packets in the buffer were generated during the previous RP (not the previous cycle). Hence, we have for $b = 1, \dots$:

$$ p(b, 0) = 1; g(b, 0) = n(b, 0) = d(b, 0) = 0; \text{ and } t(b, 0) = T_{\text{RP}} \quad (7) $$

Having calculated the parameters for all child nodes $(c, k+1)$ of the current node $(b, k)$, we proceed to each child node (excluding the leaf node) and repeat the same steps. This approach naturally results in an iterative procedure.

However, these iterations will never terminate because the tree diagram is infinite both in width (each parent node can generate an infinite number of child nodes), and in depth (the
number of cycles in a series of cycle is also infinite). To address this issue, we focus on the most significant leaf nodes in the tree and prune branches that contribute only marginally to the overall outcome. We implement this pruning in two ways.

a) Width Limitation: To limit the width of the tree, we restrict the number of child nodes a parent node can generate. Starting with the most likely child node, we incrementally add additional children until their cumulative probability exceeds a predefined threshold, $1 - \epsilon_{width}$.

b) Depth Limitation: To limit the depth of the tree, we stop further exploration once the following twofold condition is met: (i) the cumulative probability of the leaf nodes already visited exceeds a threshold, $1 - \epsilon_{depth}$, and (ii) the number of visited leaf nodes exceeds another threshold, $m_{leaves}$. This ensures that the tree is statistically representative of the possible series of cycles while staying at a reasonable size. Recall that each leaf corresponds to a distinct possible series of cycles.

To balance computational efficiency with accuracy, a suitable choice can be to set $\epsilon_{depth} = 20\%$, $\epsilon_{width} = 0.1 \times \epsilon_{depth}$ and $m_{leaves} = 10,000$.

We provide the full implementation of our iterative procedure in Python. The code is available at [2].

4) Deriving the STA performance indices: After iteratively determining the parameters for all nodes in the (truncated) tree diagram, we proceed to compute the performance indices $L$, $D$, and $P$.

First, consider a given leaf node $b$ with coordinates $(b, k)$. Recall that a leaf node corresponds to a completed series of cycles. The total number of packets generated during the entire SP, denoted $g_{tot}(b, k)$, the total number of packets transmitted during the SP, denoted $n_{tot}(b, k)$, the total duration of the completed series of cycles, denoted $t_{tot}(b, k)$, as well as the (unconditional) probability of occurrence for the leaf node $b$, denoted $p_{tot}(b, k)$, can be calculated as follows:

$$ 
\begin{aligned}
g_{tot}(b, k) &= \sum_{i=1}^{k} g(b, i) \\
n_{tot}(b, k) &= \sum_{i=1}^{k} n(b, i) \\
t_{tot}(b, k) &= \sum_{i=1}^{k} t(b, i) \\
p_{tot}(b, k) &= \prod_{i=1}^{k} p(b, i)
\end{aligned} 
\quad (8) $$

Using Equation (8), we can compute the average packet loss rate $L$ and the average packet delay $D$. Denoting by $B$ the set

of leaf nodes, we have:

$$ 
\begin{aligned}
L &= 1 - \frac{\sum_{(b,k) \in B} \left( p_{tot}(b, k) \times n_{tot}(b, k) \right)}{\sum_{(b,k) \in B} \left( p_{tot}(b, k) \times g_{tot}(b, k) \right)} \\
D &= \frac{\sum_{(b,k) \in B} \left( p_{tot}(b, k) \times n_{tot}(b, k) \times D(b, k) \right)}{\sum_{(b,k) \in B} \left( p_{tot}(b, k) \times n_{tot}(b, k) \right)}
\end{aligned} 
\quad (9) $$

$$ \text{with } D(b, k) = \frac{1}{n_{tot}(b, k)} \times \sum_{i=1}^{k} \left( n(b, i) \times d(b, i) \right) $$

Finally, we can calculate the average power consumption for the STA under study as follows. Recall that a STA in Power Save mode can have its NIC in either doze or awake states. We use $P_{doze}$ and $P_{awake}$ to denote the NIC's power consumption in the doze and awake states, respectively. Additionally, we let $e_{switch}$ represent the energy consumed by the NIC when switching from the awake state to the doze state and back to awake state. Then, we evaluate the average power consumption of the STA denoted by $P$, as:

$$ 
\begin{aligned}
P &= \frac{\sum_{(b,k) \in B} \left[ p_{tot}(b, k) \times (t_{tot}(b, k) + T_{RP}) \times P_{leaf}(b, k) \right]}{\sum_{(b,k) \in B} \left[ p_{tot}(b, k) \times (t_{tot}(b, k) + T_{RP}) \right]} \\
\text{with } P_{leaf}(b, k) &= p_{awake} t_{tot}(b, k) + p_{doze} T_{RP} + \frac{e_{switch}}{t_{tot}(b, k) + T_{RP}}
\end{aligned} 
\quad (10) $$

## V. MODEL VALIDATION

To assess the accuracy of our modeling framework, we compare the performance indices produced by our model against those delivered by the discrete-event simulator WE3S [1]. WE3S is specifically designed to simulate Medium Access Control (MAC) energy-saving mechanisms in IEEE 802.11 WLANs and has shown its effectiveness in comparing various energy-saving mechanisms (see [6] for more details about WE3S).

Our evaluation scenario consists of a WLAN with one AP and multiple STAs. Both the STAs and the AP have buffer sizes set to $l_{STAbuffer} = l_{APbuffer} = 5000$ packets, and their physical data rate is fixed to 100 Mbps. We focus on assessing the performance of a specific STA that runs TWT. For this STA, we consider three types of downstream and upstream traffic, each based on real-life traces captured using tcpdump and publicly available at [1]: (i) Voice over Internet (VoIP) using Skype; (ii) Browsing e-commerce websites; (iii) Streaming YouTube videos at 2160p quality. These traffic exhibit distinct characteristics: VoIP traffic is smooth with an almost constant bit rate; browsing traffic is relatively smooth but features occasional packet batches; streaming traffic is
characterized by frequent and large packet batches. Together, these traffic types span a broad range of typical WLAN traffic.

Inspired by [15], we assume the following values for the energy-related parameters: $P_{doze} = 0.1$ watts, $P_{awake} = 1$ watts, and $e_{switch} = 0.582 \times 10^{-3}$ joules (i.e., watt-seconds).

In addition to the monitored STA running TWT, we introduce background STAs that collectively constitute the background traffic. These STAs do not run TWT and produce both downstream and upstream traffic according to Poisson processes. Every background STA generates traffic at a rate of 400 packets per seconds. We use five background STAs for the VoIP and browsing scenarios, and two for the streaming scenario.

To proceed with our performance model of TWT, we configure the numerical values of its traffic model parameters that define the packet batch arrival process. We extract these parameters by parsing the real-life traces for VoIP, browsing and streaming, and approximating them to replicate the observed characteristics as closely as possible. The resulting parameter values for each traffic type are given in Table II. Additionally, we estimate the MAC-layer data rate $r$, which represents the effective data exchange rate between the STA and the AP, to be approximately 75 Mbps, based on a physical data rate of 100 Mbps. This estimation of $r$ accounts for physical and MAC layer overheads, frame aggregation at the MAC layer, and contention with other STAs. For truncating the tree diagram that represents the series of cycles, we use the following thresholds: $\epsilon_{depth} = 20\%$, $\epsilon_{width} = 2\%$, and $m_{leaves} = 10,000$.

<table><caption>TABLE II: Traffic model parameters used by the model for each traffic type.</caption><thead><tr><th></th><th>VoIP</th><th>Browsing</th><th>Streaming</th></tr></thead><tbody><tr><td>1/λ<sub>DL</sub> (ms)</td><td>210</td><td>1780</td><td>400</td></tr><tr><td>l<sub>DLbatch</sub> (packets)</td><td>1</td><td>40</td><td>800</td></tr><tr><td>l<sub>DLpacket</sub> (bytes)</td><td>393</td><td>1462</td><td>1351</td></tr><tr><td>1/λ<sub>UL</sub> (ms)</td><td>198</td><td>1295</td><td>651</td></tr><tr><td>l<sub>ULbatch</sub> (packets)</td><td>1</td><td>23</td><td>21</td></tr><tr><td>l<sub>ULpacket</sub> (bytes)</td><td>371</td><td>58</td><td>70</td></tr></tbody></table>

We run twenty simulations of 100 seconds with the WE3S simulator using each of the real-life trace to obtain the performance indices of the monitored STA. We compare these performance indices with those obtained using our analytical model and the traffic model parameters of Table II. Figure 6 compares the average packet loss rate, average packet delay and power consumption for the three traffic traces, as predicted by our model and as simulated by WE3S, for varying values of $T_{RP}$. For the simulated points, we included 95% confidence intervals around the mean value found with the twenty replications. Note that packet loss rates for VoIP and browsing are not included, as both the simulator and the model consistently predicted a value of zero, regardless of the duration of the restricted periods, $T_{RP}$. Overall, we observe that the model's predictions are in good agreement with the simulator's results.

# VI. PRACTICAL APPLICATION TO A WLAN

## A. Configuring the TWT parameters of a STA

In this section, we explain how our TWT performance model can guide the configuration of TWT parameters for a STA running TWT. Algorithm 1 is a high-level algorithm that describes how to compute the two TWT parameters, namely TWT Wake Interval and Minimum TWT Wake Duration.

We assume that the STA must meet a specific QoS requirement defined by two key criteria: (i) a maximum packet loss $l_{max}$, and (ii) a maximum average packet delay $d_{max}$. Our objective is to configure the TWT parameters in a way that meets the QoS requirements while maximizing the STA's energy savings.

First, we determine the maximum feasible value for the restricted period, $T_{RP}^{max}$, that corresponds to values of $L$ and $D$ meeting the QoS requirements (line 1 of Algo. 1). Using our TWT performance model developed in Equation (9), we identify this value efficiently (e.g., through a dichotomy approach that leverages the monotonic behavior of the performance indices $L$ and $D$ as a function of $T_{RP}$).

Second, we determine the minimum value for the service period, $T_{SP}^{min}$, given the previously selected $T_{RP}^{max}$ (line 2 of Algo. 1). This value corresponds to the longest SP identified in the truncated tree diagram (i.e., the leaf node with the longest series of cycles). Its duration is computed according to Equation (8).

With both the maximum $T_{RP}^{max}$ and minimum $T_{SP}^{min}$ determined, we translate them into TWT configuration parameters as follows (lines 3 and 4 of Algo. 1):

$$ 
\begin{array}{l}
\text{TWT Wake Interval} = T_{SP}^{min} + T_{RP}^{max} \\
\text{and} \\
\text{Minimum TWT Wake Duration} = T_{SP}^{min}
\end{array} 
\qquad (11) $$

### Algorithm 1: Configuring the TWT parameters of a STA

**Data:** QoS requirements in terms of maximum packet loss $l_{max}$ and maximum average packet delay $d_{max}$; Traffic model defined by $\lambda_{DL}$, $l_{DLbatch}$, $l_{DLpacket}$, $\lambda_{UL}$, $l_{ULbatch}$, $l_{ULpacket}$

**Result:** The values for TWT Wake Interval and Minimum TWT Wake Duration

1. $T_{RP}^{max} \leftarrow$ the maximum value of $T_{RP}$, computed with a dichotomy search, such that $L$ and $D$, computed according to Eq. 9, meet the QoS requirements ($L \le l_{max}$ and $D \le d_{max}$);

2. $T_{SP}^{min} \leftarrow \max_{(b,k) \in B}(t_{tot}(b, k));$

3. TWT Wake Interval $\leftarrow T_{SP}^{min} + T_{RP}^{max}$;

4. Minimum TWT Wake Duration $\leftarrow T_{SP}^{min}$;

Note that $T_{RP}$ (and then $T_{RP}^{max}$) cannot be less than 3.6 ms, as this is the minimum time a NIC needs to enter the doze state [15]. If the model determines a maximum feasible $T_{RP}$
<figure><img src="image_7.png" /><figcaption>(a) VoIP - packet delay.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>(b) VoIP - power consumption.</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>(c) Browsing - packet delay.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>(d) Browsing - power consumption.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>(e) Streaming - packet delay.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>(f) Streaming - power consumption.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>(g) Streaming - packet loss rate.</figcaption></figure>

<caption>Fig. 6: Model's predictions vs. simulations for the performance indices.</caption>

below 3.6 ms, it indicates that TWT is not suitable for the STA's current traffic pattern and QoS requirements. In such cases, we advise against using TWT.

## B. Use Case: STA Streaming a YouTube Video

In this section, we apply Algorithm 1 to a scenario in which the STA is streaming a YouTube video. The scenario is identical to that of Section V: a WLAN with one AP, one STA running TWT, and two background STAs; $l_{STAbuffer} = l_{APbuffer} = 5000$ packets; the STA running TWT streams a YouTube video at 2160p quality (publicly available at [1] and discussed in Section V). As in Section V, we set $P_{doze} = 0.1$ watts, $P_{awake} = 1$ watts, and $e_{switch} = 0.582 \times 10^{-3}$ joules (i.e., watt-seconds). Lastly, we set the truncation parameters of the tree diagram used in our model and in Algorithm 1 to $\epsilon_{depth} = 20\%$, $\epsilon_{width} = 2\%$ and $m_{leaves} = 10,000$.

We assume that the STA must meet the specific QoS requirement: (i) zero packet loss, and (ii) an average packet delay below a given threshold of 500 ms. Such a delay requirement is typically compatible with video streaming application. We apply Algorithm 1 to configure the TWT parameters in a way that meets the QoS requirements while maximizing the STA's energy savings.

First, we determine the maximum feasible value for the restricted period, $T_{RP}^{max}$ (line 1 of Algo. 1). Figure 7 shows the evolution of the two performance indices (average packet loss rate $L$ and average packet delay $D$), predicted by our model, according to different values of $T_{RP}$. In our scenario, using

a dichotomy search, the maximum feasible value for $T_{RP}$ is found to be 800 ms. Above this value, our model predicts that the average packet delay will exceed 500 ms.

<figure><img src="image_14.png" /><figcaption>Fig. 7: Evolution of the performance indices for various values of the restrictive period, $T_{RP}$. All points used in the dichotomy search within the interval [0.1s, 5.0s] are labeled with their corresponding $T_{RP}$ values. The search concludes at $T_{RP} = 0.8$s, which is the highest value that ensures both zero packet loss and a mean packet delay below 0.5s.</figcaption></figure>

Next, we determine the minimum feasible value for the service period, $T_{SP}$, given the previously selected $T_{RP}^{max}$ and based on Equation 8 (line 2 of Algo 1). This yields a minimum feasible $T_{SP}^{min}$ of 1.614 s.
With both $T_{\text{RP}}^{\text{max}}$ and $T_{\text{SP}}^{\text{min}}$ determined (equal to 0.8s and 1.1614s, respectively), we translate them into TWT configuration parameters. In our case, this results in *Minimum TWT Wake Duration* = 1.614 s and *TWT Wake Interval* = 2.414 s.

As a final note, by applying Equation (10), our TWT model estimates the STA's energy consumption under this configuration. It predicts a consumption of 0.7 watts with TWT enabled, compared to approximately 1 watts without TWT. This represents a gain of 30%.

<figure><img src="image_15.png" /></figure>

Fig. 8: Power consumption of the monitored STA as a function of restricted periods, $T_{\text{RP}}$, and service periods, $T_{\text{SP}}$. The hatched squares represent TWT configurations (i.e., $T_{\text{RP}}$ and $T_{\text{SP}}$) that fail to meet the QoS requirements. The white square and the asterisk represent the TWT configurations found by our solution and by the optimal solution, respectively.

To assess the goodness of the proposed TWT configuration for the given scenario and QoS requirements, we use the simulator WE3S to compare the proposed configuration against a wide range of alternative TWT configurations, i.e., different values of ($T_{\text{RP}}$, $T_{\text{SP}}$). Figure 8 reports the obtained results with WE3S. Each square in the figure corresponds to a specific TWT configuration. The color indicates the power consumption of the monitored STA, while hatching marks configurations that fail to meet the QoS requirements. Our proposed configuration, ($T_{\text{RP}}$, $T_{\text{SP}}$) = (0.8, 1.6), lies in the area highlighted by the white square. It satisfies the QoS requirements (no hatching), while featuring one of the lowest power consumption, namely 0.7 watts, among the QoS-compliant configurations. The area highlighted with a white asterisk denotes the QoS-compliant configuration with the lowest power consumption (0.61 watts). We observe that both solutions yield the same value for $T_{\text{RP}}$ while our solution results in a slightly larger value for $T_{\text{SP}}$. Overall, this figure demonstrates the ability of our solution to propose an adequate TWT configuration that closely approaches the optimal.

## VII. CONCLUSIONS

In this paper, we address the configuration of TWT parameters for a STA with the goal of reducing energy consumption while satisfying a given QoS requirement. We develop a

performance model for TWT that accounts for batch arrivals in both uplink and downlink traffic, and we derive closed-form expressions for key performance metrics, namely mean packet delay, packet loss rate, and average power consumption of the STA. We validate the accuracy of our model against simulated results. We also introduce a procedure to configure the main TWT parameters for a STA and illustrate it using the scenario of a STA streaming video content. In future work, we aim to explore how the size of buffers and the nature of the traffic may affect the performance of TWT and how APs themselves can utilize TWT to reduce their own energy consumption.

## REFERENCES

[1] WE3S, 2023. Available at https://github.com/EstGue/WE3S.

[2] Performance modeling of TWT, 2025. Available at https://github.com/EstGue/Performance_modeling_TWT/.

[3] DV Bankov, AI Lyakhov, EA Stepanova, and EM Khorov. Mathematical Models of Modern Power Save Mechanisms in Wi-Fi Networks. *Journal of Communications Technology and Electronics*, 68(Suppl 2):S224-S238, 2023.

[4] DV Bankov, AI Lyakhov, EA Stepanova, and EM Khorov. Performance Evaluation of Wi-Fi 7 Networks with Restricted Target Wake Time. *Problems of Information Transmission*, 60(3):233-254, 2024.

[5] Qinghua Chen and Yi-Hua Zhu. Scheduling channel access based on target wake time mechanism in 802.11 ax WLANs. *IEEE Transactions on Wireless Communications*, 20(3):1529-1543, 2020.

[6] Esther Guérin, Thomas Begin, Isabelle Guérin Lassous, and Anthony Busson. Performance analysis of MAC energy-saving strategies for WLANs. In *Proceedings of the Int'l ACM Conference on Modeling Analysis and Simulation of Wireless and Mobile Systems*, pages 119-126, 2023.

[7] Jetmir Haxhibeqiri, Xianjun Jiao, Xiaoman Shen, Chun Pan, Xingfeng Jiang, Jeroen Hoebeke, and Ingrid Moerman. Coordinated SR and restricted TWT for time sensitive applications in WiFi 7 networks. *IEEE Communications Magazine*, 62(8):118-124, 2024.

[8] Xianjun Jiao, Wei Liu, Michael Mehari, Havinga Thijs, and Aslam Muhammad. open-source IEEE802.11/Wi-Fi baseband chip/FPGA design, 2023.

[9] Mehmet Karaca. Joint optimization of target wake time mechanism and scheduling for IEEE802. 11ax. *Turkish Journal of Electrical Engineering and Computer Sciences*, 29(3):1659-1671, 2021.

[10] Ruofeng Liu and Nakjung Choi. A first look at Wi-Fi 6 in action: Throughput, latency, energy efficiency, and security. *Proceedings of the ACM on Measurement and Analysis of Computing Systems*, 7(1):1-25, 2023.

[11] Maddalena Nurchis and Boris Bellalta. Target wake time: Scheduled access in IEEE 802.11 ax WLANs. *IEEE Wireless Communications*, 26(2):142-150, 2019.

[12] Maddalena Nurchis and Boris Bellalta. Target Wake Time: Scheduled access in IEEE 802.11ax WLANs. *IEEE Wireless Communications*, 26(2):142-150, 2019.

[13] Wenxun Qiu, Guanbo Chen, Khuong N Nguyen, Abhishek Sehgal, Peshal Nayak, and Junsu Choi. Category-based 802.11 ax target wake time solution. *IEEE Access*, 9:100154-100172, 2021.

[14] EA Stepanova, DV Bankov, EM Khorov, and AI Lyakhov. Influence of the Clock Drift on the Efficiency of the Power Save Mechanisms in Wi-Fi Networks. *Journal of Communications Technology and Electronics*, 67(Suppl 1):S167-S175, 2022.

[15] Shyam Krishnan Venkateswaran, Ching-Lun Tai, Yoav Ben-Yehezkel, Yaron Alpert, and Raghupathy Sivakumar. IEEE 802.11 PSM in ns-3: A Novel Implementation and Evaluation under Channel Congestion. In *Proceedings of the 2022 Workshop on ns-3*, pages 33-40, 2022.

[16] Shyam Krishnan Venkateswaran, Ching-Lun Tai, Roshni Garnayak, Yoav Ben-Yehezkel, Yaron Alpert, and Raghupathy Sivakumar. IEEE 802.11 ax Target Wake Time: Design and performance analysis in ns-3. In *Proceedings of the 2024 Workshop on ns-3*, pages 10-18, 2024.

[17] Chengqing Zhao, Borui Li, Shuai Wang, and Tian He. The First Measurement Study of Target Wake Time Mechanism in 802.11 ax on COTS Devices. In *ICC 2023-IEEE International Conference on Communications*, pages 4695-4700. IEEE, 2023.