Target Wake Time Scheduling for Time-sensitive and Energy-efficient Wi-Fi Networks

1 Target Wake Time Scheduling for Time-sensitive and Energy-efficient Wi-Fi Networks Fabio Busacca, Member, IEEE, Corrado Puligheddu, Member, IEEE, Francesco Raviglione, Member, IEEE, Riccardo Rusca, Member, IEEE, Claudio Casetti, Senior Member, IEEE, Carla Fabiana Chiasserini, Fellow, IEEE, and Sergio Palazzo, Senior Member, IEEE Abstract—Time Sensitive Networking (TSN) is fundamental for the reliable, low-latency networks that will enable the Industrial Internet of Things (IIoT). Wi-Fi has historically been considered unfit for TSN, as channel contention and collisions prevent deterministic transmission delays. However, this issue can be overcome by using Target Wake Time (TWT), which enables the access point to instruct Wi-Fi stations to wake up and transmit in non-overlapping TWT Service Periods (SPs), and sleep in the remaining time. In this paper, we first formulate the TWT Acceptance and Scheduling Problem (TASP), with the objective to schedule TWT SPs that maximize traffic throughput and energy efficiency while respecting Age of Information (AoI) constraints. Then, due to TASP being NP-hard, we propose the TASP Efficient Resolver (TASPER), a heuristic strategy to find near-optimal solutions efficiently. Using a TWT simulator based on ns-3, we compare TASPER to several baselines, including HSA, a state-of-the-art solution originally designed for WirelessHART networks. We demonstrate that TASPER obtains up to 24.97% lower mean transmission rejection cost and saves up to 14.86% more energy compared to the leading baseline, ShortestFirst, in a challenging, large-scale scenario. Additionally, when compared to HSA, TASPER also reduces the energy consumption by 34% and reduces the mean rejection cost by 26%. Furthermore, we validate TASPER on our IIoT testbed, which comprises 10 commercial TWT-compatible stations, observing that our solution admits more transmissions than the best baseline strategy, without violating any AoI deadline. Index Terms—Target wake time, time-sensitive networking, traffic scheduling, Industrial Internet of Things I. INTRODUCTION The transformation brought about by technologies like the Industrial Internet of Things (IIoT), Artificial Intelligence (AI), and cyber-physical systems is changing the way industries and production chains operate [1]. In this new industrial paradigm, the traditional boundaries of manufacturing are redefined through smart factories, where real-time data, interconnected systems, and automation are seamlessly integrated. With IIoT at its core, this transformation ushers in a wave of intelligent sensors, actuators, and data-driven decision systems that promise unprecedented efficiency and precision in industrial processes. F. Busacca and S. Palazzo are with University of Catania, Italy. C. Casetti, C. F. Chiasserini, C. Puligheddu, F. Raviglione, and R. Rusca are with Politecnico di Torino, Italy. This work was supported by the European Commission through Grant No. 101095890 (Predict-6G project), and by the EU under the Italian NRRP of NextGenerationEU, through the RESTART program (PE0000001) and the MOST CNMS (CN00000023). This manuscript reflects only the authors’ views and opinions, neither the EU nor the EC can be considered responsible for them. Reliable, low-latency communication is essential in smart factories where deployments may involve even hundreds of IIoT devices exchanging time-sensitive data to monitor production lines, detect anomalies, and coordinate actions across complex processes. As a result, communication delays and network reliability become critical, not only to maintain efficiency but also to avoid costly interruptions that could lead to production downtime, equipment damage, or even safety hazards. However, meeting these communication demands is challenging in a wireless environment, where signals are subject to interference and collisions that can delay critical messages. While ARQ (Automatic Repeat reQuest) mechanisms can sometimes recover lost transmissions, they cannot ensure that data remains relevant. A key challenge is managing the Age of Information (AoI), i.e., the time elapsed between data generation and its reception at the destination. High AoI can make data obsolete, especially in cases where an alert about a production anomaly arrives too late for effective intervention. For example, delayed sensor data could leave operators with no choice but to halt production, leading to significant financial and operational costs. To overcome these challenges, traditional approaches might suggest isolating each device on a dedicated wireless channel, but this is rarely feasible given the limited spectrum and high device density in IIoT settings. Thus, a more sophisticated approach is needed to manage channel access while minimizing latency and ensuring data freshness. Target Wake Time (TWT), a feature introduced with Wi-Fi 6 (IEEE 802.11ax), offers a promising solution for managing time-sensitive communication in the IIoT. TWT allows an access point (AP) to pre-define wake-up times for each station (STA) in the network, scheduling them to transmit and receive data in dedicated slots and enabling them to sleep in the meantime. This level of control provides several critical advantages: •Enhanced energy efficiency: Many IIoT devices run on battery power, and frequent data exchange can quickly drain their energy. With TWT, devices can remain in a low-power mode and only wake up for scheduled transmissions, significantly extending their operational life. •Reduced channel contention: By allocating exclusive transmission times for each device, TWT helps prevent contention, reducing the chances of collisions and network delays. This allows for more deterministic commu- 2 nication, essential for safety-critical and real-time applications in manufacturing. •Improved predictability and network stability: TWT scheduling makes it possible to better anticipate network load and reduce jitter, which can be vital for industrial processes that depend on synchronized device interactions and precise timing. While TWT can address the issues of timing and energyefficient operation in IIoT, it leaves open the question of how to strategically assign wake times to devices to best balance data freshness, energy savings, and throughput. Without a systematic scheduling approach, there is no guarantee that TWT allocations will meet the demanding latency and reliability requirements of time-sensitive applications. Therefore, a robust TWT scheduling mechanism becomes essential for IIoT networks that use IEEE 802.11ax. Such a mechanism should: (i) Ensure that devices wake up only when necessary, reducing energy consumption; (ii) Maximize the admission rate of critical and timely data flows to prevent stale or outdated information; (iii) Minimize AoI, ensuring that time-sensitive information remains fresh and actionable. In this work, we thus focus on making the TWT mechanism suitable to the stringent requirements of IIoT traffic by scheduling device wake times to: optimize energy saving, accommodate as many traffic flows as possible while prioritizing critical data, and guarantee a timely delivery of information. Hence, with this goal in mind, we introduce the TWT Acceptance and Scheduling Problem Efficient Resolver (TASPER), an algorithmic solution for energy-efficient, AoIconstrained TWT scheduling in Wi-Fi networks. Our contributions can be summarized as follows: •We model a TWT-enabled Wi-Fi networks, where STAs generate AoI-constrained traffic. Such a model captures the relationship between the traffic generated and transmitted by the Wi-Fi STAs, the STA power states, and the associated energy consumption. •We build upon this model to define the TWT Acceptance and Scheduling Problem (TASP), whose objective is to minimize the rejected (therefore, not scheduled) traffic and the stations’ energy consumption while satisfying the maximum AoI constraint. Finding a solution to the TASP implies determining (i) whether or not to admit the traffic, and (ii) the target wake time(s) of each STA in the network. Notably, the possibility to reject traffic may allow for a schedule with sufficient room for higher-priority traffic. •As the TASP is NP-hard, to solve it efficiently we devise a novel heuristic strategy that efficiently produces high-quality scheduling decisions while accounting for energy consumption. The algorithm is designed to be lightweight and fast, making it suitable for timely execution in dynamic IIoT environments. •We enhance the ns-3-based simulator for TWT by Venkateswaran et al. [2], introducing several novel features to simulate advanced TWT scheduling approaches such as TASPER. The simulator, that we call ns-3-twt, includes the possibility to simulate deadlines, different classes of devices and multiple TWT networks. •We thoroughly evaluate TASPER and other baselines, leveraging ns-3-twt and show that it offers substantial improvements over the other strategies. Specifically, TASPER obtains up to 24.97% lower mean rejection cost and saves up to 14.86% more energy compared to the best baseline. Additionally, it reduces energy consumption up to 34% and the mean rejection cost of up to 26% when compared to HSA, a state-of-the-art approach originally designed for WirelessHART networks. •We design and implement an IIoT testbed comprising 10 commercial TWT-compatible STAs. Through our testbed, we validate TWT as a means for energy-efficient traffic scheduling without incurring channel contention delays, observing 49% energy saving and 16% lower median AoI. Also, we remark that TASPER admits more transmissions than the best baseline strategy, confirming its effectiveness in scheduling transmissions. The rest of the paper is organized as follows. Sec. II highlights the advantages of the TWT feature and motivates the need for a transmission scheduling that accounts for traffic generation times and deadlines. Sec. III introduces our system model and the TWT scheduling problem, which is shown to be NP-hard. Sec. IV presents the key ideas and principles behind the TASPER scheduling algorithm we propose. After describing in Sec. V our ns-3-based simulation framework and evaluation methodology, and the scheduling baselines considered as benchmarks for TASPER, Sec. VI shows the numerical results we obtained. Sec. VII introduces the experimental testbed we set up with commercial off-the-shelf devices and validates the feasibility and good performance of our solution. Finally, Sec. VIII discusses some relevant related work, and Sec. IX draws our conclusions. II. TWT OPERATIONS: THE NEED FOR A SCHEDULING STRATEGY TWT enables the Wi-Fi STAs to negotiate awake periods with the Access Point (AP) to exchange traffic and to enter a doze mode during the remaining time to save energy [3]. One of the main advantages of TWT is therefore energy efficiency. Indeed, as the STAs are able to enter a sleep mode while not involved in the transmission or reception of data, they can save a substantial amount of energy that would instead be spent turning the radio into receive mode for data that is not destined to them, or in other operations such as Clear Channel Assessment [3], [4]. The advantage of using TWT in terms of energy savings, which is especially important in energyconstrained battery-powered IIoT sensors, is highlighted in Fig. 1. The plots show the output of our ns-3-twt simulator (described in Sec. V-A) in a scenario with 8 STAs, that need to send their traffic to an AP, modeling IIoT sensors of different kinds and with different energy figures. The traffic consists of a 1500-byte UDP packet encoding sensor data to be transmitted to the AP. Each STA m(m=1,...,8) receives a UDP packet from its higher layers at a time equal to (m·5) ms. We also consider that the transmission periodicity of the STAs is known (which is likely to happen for common 3 0 5 10 15 20 25 30 Time [ms] CCA_BUSY idle receivesleep transm. 1.63 mJ (a) With TWT 0 5 10 15 20 25 30 Time [ms] 5.48 mJ CCA_BUSY idle receivesleep transm. (b) Without TWT Fig. 1. Example of the temporal evolution of STA’s power states with (a) and without (b) TWT, over a period of 32 ms. The total energy consumed during the time period is reported at the bottom right. The example includes 8 STAs, each with a 1,500-byte UDP packet to transmit; the considered STA starts transmitting at time 10 ms. IIoT sensors that transmit their data periodically); thus, the STAs can conveniently employ a TWT mechanism in which each TWT SP starts as soon as a UDP packet is received at a STA from its higher layers. Each TWT SP is set to last slightly more than 5 ms, just for the sake of showing a clear illustrative example. Fig. 1 shows the difference with (a) and without (b) TWT, depicting the evolution of the physical layer states of STA 2 over time, and including the total energy consumption in a reference 32-ms period. One can observe that, with TWT, the STA spends most of the time in the very low energy sleep state, except for the time in which it has to receive the beacon from the AP (the receive mode right after the beginning of the simulation) and during its Service Period (SP), in which it transmits its data. Conversely, without TWT, the STA never enters the sleep state, and alternates between the idle and the receive state. Specifically, such states are entered every time the STA is overhearing, i.e., another STA transmits data to the AP. Since the idle state is associated with a higher energy consumption than the sleep state, employing TWT results in a significant 3.4×energy saving over a reference period of just 32 ms. Besides reducing energy consumption, TWT can enable time-sensitive Wi-Fi networks, i.e., it can provide deterministic latency for the traffic generated by the Wi-Fi nodes. Indeed, without TWT, nodes that generate traffic with different requirements and deadlines need to contend for the shared wireless medium. This is especially true when the overall offered traffic is bursty, which will make the nodes more likely to compete for channel access, and possibly defer their transmissions. This makes the timing of channel access and successful data transmissions non-deterministic. Such a level of unpredictability may be unacceptable, especially for timecritical Industry 4.0 use cases often involving the control of time-sensitive machinery. This concept is demonstrated in 5 10 15 20 25 30 35 UDP Payload Size [kB] 2.5 5.0 7.5 10.0 12.5 15.0 17.5 Average Latency [ms] No-TWT TWT Fig. 2. Comparison of the average STA transmission delay measured with and without TWT, when used to avoid channel contention. Error bars show the 95% confidence intervals. Fig. 2, showing the average delay experienced by 8 STAs with TWT enabled and disabled, obtained through our ns-3twt simulator, as the payload size increases. All STAs generate traffic at the same time. By scheduling non-overlapping windows for each STA, the TWT approach yields a data delivery delay that is almost equal to the case where there would not be any contention, with lower jitter and higher determinism (the confidence intervals are indeed very small). When instead TWT is disabled, the data delay becomes much higher, and its variation very evident. In spite of the above advantages, it is important to remark that TWT alone does not provide any guaranteed AoI, as Wi-Fi packets could wait in the transmission queue for more than what the maximum tolerable AoI allows, before they are scheduled in a TWT SP. This is exemplified in Fig. 3, which presents in plot (a) an instance of a problem of TWT acceptance and scheduling at the AP. For a scheduling solution to be feasible, the transmissions (blue bars) cannot overlap in time. Rather, they have to be scheduled sequentially within the white boxes, indicating the transmission ranges that respect the data deadlines. When a naive first-input-first-output (FIFO) approach is used in plot (b), only a few transmissions can be scheduled, while several are not since they would miss their deadline. In contrast, by accounting for the traffic deadlines, the number of transmissions can be maximized (see plot (c)), doubling the number of transmissions that can be accommodated. The above observations highlight that, in the presence of energy-constrained devices like IIoTs and strict latency requirements in data packet delivery, it is imperative to develop a scheduling strategy for Wi-Fi networks that accounts for traffic generation times and deadlines. III. SYSTEM MODEL AND PROBLEM FORMULATION This section first introduces our system model and assumptions, and then presents the TASP optimization problem to be solved at the AP. 4 0 5 10 15 20 25 30 35 40 45 50 55 60 Time [ms] 1 2 3 4 5 6 7 8 TX ID (a) Problem instance 0 5 10 15 20 25 30 35 40 45 50 55 60 Time [ms] 1 2 3 4 5 6 7 8 TX ID (b) FIFO solution 0 5 10 15 20 25 30 35 40 45 50 55 60 Time [ms] 1 2 3 4 5 6 7 8 TX ID (c) Optimum Fig. 3. TASP example (a) and its solution using a FIFO strategy (b) and a strategy maximizing the number of transmissions (c). The blue bars indicate the transmission times, which have to start and end inside the white boxes to meet the traffic deadlines. A. System Model and Assumptions We consider an IEEE Wi-Fi 6 High Efficiency (HE) basic service set (BSS) with an AP and MSTAs1, with STAs having time-sensitive traffic to transmit to the AP. To avoid non-deterministic delays caused by channel contention, the AP leverages the TWT mechanism to multiplex STA transmissions in the time domain, aiming to schedule as many traffic flows as possible. The scheduling period, defined as the time between consecutive scheduling decisions, is bounded by the beacon frame, periodically transmitted every Tbseconds by the AP. Accordingly, each TWT scheduling decision holds valid till the next beacon transmission. A beacon interval is divided into Dslots, each of duration Ts=Tb/D; a slot represents the temporal granularity for TWT scheduling. This implies that the awake period for a STA during which it can send/receive data, also called Service Period (SP), begins at the start of a slot and spans over a discrete number of slots. Additionally, we assume the propagation delay to be negligible. A TWT session between the AP and a STA is composed of one SP or many periodic SPs, if the session is implicit [3]. For efficiency, we focus on implicit sessions, as they do not require new scheduling if the traffic pattern does not change. We remark, however, that such sessions can be modified at every periodic interval if the traffic pattern varies. Also, our solution applies to any of the TWT mechanism configurations foreseen by the Wi-Fi standard. 1We consider individual TWT sessions. However, the standard [3] also defines broadcast TWT, where the AP coordinates shared wake times for multiple STAs simultaneously. Moreover, it does not preclude the possibility of establishing TWT agreements directly between STAs, for instance in an IBSS setting. TXOPs submission and admission BCN BCN TXOPs submission and admission TASPER TWT suggest TWT suggest TWT acceptTWT accept/ reject time Beacon intervalAP Fig. 4. System model overview. At each beacon interval, STAs first request traffic scheduling from TASPER, and then follow its scheduling decisions. Within a beacon interval, each STA m(m=1, . . ., M) may have one or more time-sensitive packets to transfer, possibly belonging to different traffic flows. Based on an experienced signal quality level lm, a STA mcan determine the maximum data rate ρm(lm)at which it can successfully transmit towards the AP. In addition to signal level, this rate depends both on the STA capabilities and on the network configuration (e.g., channel bandwidth, number of MIMO streams). The STA then uses the TWT mechanism to request the scheduling of the data transmission for the computed transmission time, i.e., to request a Transmission Opportunity (TXOP) in a TWT SP. According to the Wi-Fi 6 specifications [3], the STA sends a Suggest TWT message to the AP requesting a desired SP, and the desired Minimum TWT wake duration needed to accommodate the TXOP. Furthermore, we assume that the STA also indicates the class of the traffic flow to which data belongs, so that the AP is aware of the corresponding traffic priority level. We will refer to the data, belonging to a given traffic flow that a STA has to transmit, simply as transmission (TX). The generic j-th TX is characterized by: (i) the source STA id m,(ii) the amount of data in bytes, bj, (iii) the time gjat which those data were generated at the application layer by the STA, (iv) the hard AoI deadline dj within which the TX has to be received, and (v) the traffic priority level pj. It follows that, for each TX j, a STA mwill request a TXOP of duration equal to τj=bj/ρm(lm), where bjdenotes the amount in bytes of data belonging to a traffic flow jto be transmitted and ρm(lm)the achievable data rate that the STA mcan use. For simplicity and without loss of generality, we express gj,dj, and τjin time slots. Note that all these elements are expressed in relative time units within the beacon interval. The AP collects all the TXOP requests at the beginning of the beacon interval and, according to a given strategy, it schedules TWT SP for the requested TXOP by sending to each requesting STA an Accept TWT message (see Fig. 4). Such a message includes some important parameters, namely (i) the Target Wake Time, i.e., the time instant at which the STA should wake up for the TWT session; (ii) the TWT Wake Interval, i.e., the time interval between subsequent SPs for the STA (we assume this value to be constant for all STAs and equal to the beacon interval); and (iii) the Minimum TWT wake duration, i.e., the minimum duration that the STA should stay awake since the SP starts. Let Nbe the set of TXOPs (or, equivalently, TXs) that the AP is requested to schedule within a beacon interval; note that 5 TABLE I MAIN NOTATION Symbol Description NSet of schedulable TXs lmQuality level of the link between AP and STA m ρm(lm)Maximum data rate for STA m τjNo. of time slots needed for TX j D Number of time slots in a beacon frame TbTime interval between consecutive beacon frames TsSlot duration (time granularity) gjGeneration time (in slots) for TX j djAoI deadline (in slots) for TX j pjPriority level of TX j Etx jPer-slot energy consumption of the STA performing TX j Eid jPer-slot energy consumption in idle state of the STA performing TX j Est jPer-slot energy consumption of the STA performing TX jduring mode transitions sij Auxiliary parameter, equal to 1 if TXs jand iare performed by the same STA; 0 otherwise xjTXOP admission binary variable yij TXOP sequence binary variable zjTXOP end time variable eij Total energy consumed by the STA performing TX jwhen jis scheduled immediately after TX i |N|≥M. Then the AP will respond to each request in one of the following ways: (i) accept the TWT suggestion as is; (ii) accept the TWT suggestion with a modification; (iii) reject the TWT suggestion. As for the per-slot energy consumption of an STA m, this is given by Etx m=Ptx m·Tswhere Ptx mis the transmission power of STA m(assumed to be constant for simplicity). A TX of duration τjpertaining to STA mthen implies an energy consumption Etx m·τj. Similarly, let Pid mbe the power consumed by STA mwhen idle, and Eid m=Pid m·Tsbe the corresponding per-slot energy consumption. To save energy, before and after a TX, STA menters the sleep state; we denote with Est mthe energy consumed during the transition from sleep to transmission mode and vice versa. Let jbe a TX held by STA m. For simplicity, in the following we abuse the notation by replacing Etx m,Eid m, and Est m, respectively, with Etx j,Eid j, and Est j. Hence, Etx j,Eid jand Est jrepresent the per-slot energy consumption incurred, respectively, during transmission, in idle state, and while transiting between operational states, by the STA performing TX j. B. TASP Formulation Let us now define the TWT Acceptance and Scheduling Problem (TASP), to be solved at the AP. TASP aims to efficiently leverage the Wi-Fi TWT mechanism to meet the stringent demands of IIoT networks—specifically, minimizing energy consumption, ensuring timely data delivery, and handling concurrent traffic flows with diverse priorities and deadlines. Ideally, the AP should schedule all the requested TXOPs, while keeping the overall energy consumption as low as possible. However, scheduling all TXs may not be possible, in which case the AP can reject one or more TWT suggestions, e.g., those associated with the lowest priority TXs, or the longest ones. Choosing which TWT suggestions to reject enables a trade-off between energy consumption and traffic priority level. In the following, we formulate the TWT Acceptance and Scheduling Problem (TASP), which, depending on the value of a weight coefficient, β, sets the relative importance of two objective components, namely, the cost of rejecting TXs and the STA energy consumption, and aims at minimizing both. The decision variables we consider are as follows: •x=[xj], defined as the transmission acceptance vector, where the generic integer element xj∈{0,1}indicates whether or not the TXOP associated to TX jis admitted; •Y=[yij], defined as the transmission sequence matrix, whose element yij takes on 1 when the TXOP associated to TX jis scheduled right after the TX i, and 0 otherwise; •z=[zj], defined as the end time vector containing the end time of the scheduled TXOPs. Additionally, we introduce two dummy TXs, denoted by α and ω, to allow for a consistent definition of the scheduling sequence of TXOPs, with TX αand ωbeing the first and the last of the sequence (respectively) and being both associated to null generation time, duration, and traffic priority, and an AoI deadline that is equal to the maximum among those of all genuine TXs. We can then write the TASP as: TWT Acceptance and Scheduling Problem (TASP) min x,Y,zX j∈N "β(1−xj)pj+(1−β)xjX i∈N ,i=j eijyij# (1a) s.t. X i,i=j yij=xj∀i∈{N ∪ {α}} ∀j∈{N ∪ {ω}} (1b) X i,i=j yji=xj∀i∈{N ∪ {ω}} ∀j∈{N ∪ {α}} (1c) zi+τjyij+dj(yij−1) ≤zj∀i∈{N ∪ {α}} ∀j∈{N ∪ {ω}}, i=j (1d) (gj+τj)xj≤zj∀j∈{N ∪ {ω}} (1e) zj≤djxj∀j∈{N ∪ {α}∪{ω}} (1f) eij≤Est j+τjEtx j∀j∈{N ∪ {α}∪{ω}} (1g) eij≥yijsij ·minEid j(zj−τj−zi ), Est j+(1−sij)Est j∀i∈{N ∪ {α}} ∀j∈{N ∪ {ω}}, i=j (1h) zα=0, zω= max j∈N {dj}≤D(1i) xα=1, xω=1 (1j) xj∈{0,1}, yij∈{0,1} ∀i∈{N ∪ {α}} ∀j∈{N ∪ {ω}}, i=j (1k) In the above formulation, the cost function (1a) is the weighted sum of two elements: (i) the rejection cost, defined as the sum of the priority of the TXs associated with the rejected TXOPs, and (ii) the energy cost associated with the 6 transmission of the scheduled TXs. Specifically, the energy cost associated with TX jstrictly depends on the scheduling order. Let TX ibe the TX scheduled immediately before TX j, and sij be an auxiliary variable that takes on 1 if TX iand TX jare performed by the same STA, and 0 otherwise. Then we define the energy cost associated with TX j,eij , as: eij=τjEtx j+(1−sij)Est j+sij ·min Eid j·(zj−τj−zi), Est j. (2) Indeed, scheduling TX jobviously implies an energy consumption proportional to the duration of TX j. Additionally, the STA performing TX jincurs a cost that depends on the scheduling order: if TX i(i.e., the preceding TX), is performed by a different STA (sij =0), the STA performing TX jwill need to transit from sleep to transmit state, thus incurring an energy cost Est j. Conversely, if TXs iand jare performed by the same STA (sij =1), the latter can either enter the idle state and wait to perform TX j, or go to sleep and move to transmit state just before performing TX j. Between these options, the STA will select the one that implies the minimum energy consumption. For simplicity and without loss of generality, in the model we neglect the energy consumed by a STA to receive the acknowledgment from the AP (this will instead be accounted for in our performance evaluation). Finally, note that both the priority and the energy cost of each TX are properly normalized between 0 and 1, in order to be comparable. Constraints (1b) and (1c), instead, enforce that the scheduled TXOPs occur sequentially, without overlapping with each other. Constraint (1d) ensures that if the TXOP iprecedes the TXOP j, the latter ends τjslots after the TXOP i. This implies that the end time of TX jmust occur after the end of TX iplus the duration of TX j. Crucially, this ensures that no TX can be scheduled before one of its predecessors [5]. Constraint (1e) imposes that the end time of a scheduled TXOP does not occur earlier than the sum of the generation time and the duration of the associated TX. In other words, if a transmission is generated at time t=gjs and requires τjs, the TXOP cannot end before t=gj+τjs. The AoI deadline constraint (1f) specifies that the end time of a scheduled TXOP must not exceed the deadline of its associated TX. Regarding energy, (1g) upper limits the energy consumption of the STA associated with TX jto the sum of the energy required for transiting from sleep to transmit mode and vice versa, and of the energy consumed while transmitting. Conversely, (1h) provides a lower bound to energy consumption, which depends on whether the considered TXOP is requested by the same STA as the preceding TXOP. As already specified before, if the STA is the same, then such a STA remains in an idle state instead of going back to sleep, thereby conserving energy. Constraints (1i) and (1j) define xand zfor the dummy TXs. In particular, the dummy TX αopens the scheduling chain while the dummy TX ωmarks the end of the chain; both have a duration equal to 0 s and ωmust occur before the end of the beacon interval. It follows that a feasible schedule yields a sequence of TXs that does not exceed the beacon interval. (1k) enforces the elements of xand Yto take a binary value. All notations used so far are summarized in Table I. Importantly, based on [6], we can map the TASP into a single-machine, sequence-independent, completion-dependent batch setup cost scheduling problem with release dates, deadlines, and rejection. Indeed, the batch setup cost can represent the transceiver activation cost for one or more subsequent TXs, accounting for potential idle periods between TXs (completion-dependent), along with the subsequent deactivation cost. Notably, the most related problems are (i) the Order Acceptance and Scheduling (OAS) [7], which includes a job setup cost analogous to the activation and deactivation energy in TASP, and (ii) the single-machine Job Interval Selection Problem (JISP) [8], a special case of the OAS that focuses solely on maximizing the number of accepted tasks. Both problems can model the AoI constraints for TXs (i.e., maximum completion times for jobs); however, they leave out the energy consumption cost. It follows that, to our knowledge, a formulation equivalent to the TASP has not been previously proposed. As far as the TASP complexity is concerned, the following result holds. Theorem 1. The TASP is NP-hard. Proof. The TASP includes both integer and continuous variables, as well as one quadratic constraint (1h), and therefore it is a Mixed Integer Quadratic Constrained Programming (MIQCP) problem, which is known to be NP-hard [9]. ■ It is worth noting that, even when ignoring (1h) and the energy term in (1a), the simplified problem equivalent to the single-machine Job Interval Selection Problem (JISP) is also NP-hard [8]. While MIQCP solvers such as Gurobi and IBM CPLEX can compute the optimal solution for TASP, realtime scheduling decisions must be made on a per-beacon period basis. This requirement, combined with the limited computational resources of low-power APs, makes solving non-trivial instances of TASP impractical. IV. THE TASPER ALGORITHM The NP-hard nature of the TASP problem clearly calls for the design of an efficient heuristic solution that can swiftly solve TASP even in the presence of a large number of transmission requests. We thus propose the TASP Efficient Resolver (TASPER), whose design was inspired by the BALAS algorithm, introduced in [7] to solve the OAS problem (see Sec. III). The key intuition behind TASPER is to treat the TWT-based TXOP scheduling as a best-path search within a decision graph. Also, TASPER efficiently schedules traffic data transmissions and it differentiates from previous work (including BALAS) as it effectively embeds energy saving in the scheduling problem. Specifically, TASPER solves the TX scheduling problem at every beacon interval by implementing the following multistep strategy. The first step consists in building a directed decision graph, which, as shown in Fig. 5, is composed of: •A set of vertices, including: (i) a virtual vertex, α, representing the starting point of the sequence of TXs, (ii) a vertex for each TX to be scheduled and whose AoI deadline has not yet expired, and (iii) a virtual vertex ω, representing the end of the TXs sequence. For simplicity, given a transmission request TX j, we abuse the notation and use it also to denote the corresponding vertex; 7 TX 2 TX 7 TX 6 TX 5 ω TX 4 α TX 1 TX 3 TX 8 Fig. 5. Example of the TASPER graph, referring to the scheduling problem in Fig. 3. For clarity, the outbound edges have the same color as the vertex they exit while their arrow has the same color as the inbound vertex. Notice how the graph is not fully connected: e.g., there is no edge from TX 3 to TX 4, since, if TX 3 is scheduled, its end time would exceed the latest possible start time of TX 4. The solid thick lines, traversing vertices α,2,7,5,8,1,6, and ω, mark the best path, i.e., the one identified by the Optimum solution in Fig. 3. Finally, the dotted thick lines identify the neighborhood of Tx 4with a neighborhood size η=1, including TXs 5 and 7. •A set of edges, each of which connects two possible back-toback TXs. Notice that the edges exiting vertex αand entering vertex ωare as many as the number of possible TXs to be scheduled. Also, each edge exiting vertex iand entering vertex j, is associated with a bi-dimensional weight defined as wij=[τj, vij]where, as mentioned earlier, τjdenotes the duration of TX jand vij is defined according to the TASP objective function, i.e., vij=βpj+(1−β)(1−eij ). (We recall that the priority of TX j,pj, and the energy cost, eij, are normalized within the range [0,1]). Given the above graph, visiting a vertex means scheduling the TXOP needed to fulfill the corresponding transmission request. It follows that scheduling a sequence of TXs can be represented as a path from αto ω. Accordingly, as TASPER schedules TXOPs fulfilling the TX requests, i.e., it builds a path traversing the graph, the second step of the algorithm consists in identifying the feasible scheduling solutions among all the possible ones. To this end, TASPER keeps track of the residual scheduling time available within the given beacon interval. Let t0be the variable tracking the elapsed time. Let TX ibe the last visited vertex, and TX jthe potential next vertex to visit. The latter can be visited (i.e., it is a feasible choice) only if the maximum between t0and gj, plus τj, does not exceed the AoI deadline djof TX j: max t0, gj+τj≤dj. We thus define a feasible path from αto ωas a sequence of edges such that, at any vertex jcomposing the path, the intermediate sum of the TXOP duration allocated for the upstream vertices honors the delay constraint of the TX j. Finally, to enable TASPER to select the best scheduling solution, we define the value of a path as the sum of the values of the traversed edges, which is consistent with the expression of TASP’s objective function. Notice that, given vertex TX j, the value taken by the weight of the edge going from TX i to TX jdepends on whether the STA requesting TX iis the same that is requesting TX j. As pointed out in Sec. III, the energy consumption eij of a TX jis indeed influenced by the specific scheduling order adopted. TASPER’s third step then consists in finding the feasible path from αto ωthat maximizes the path value defined above. To reduce the time complexity of the algorithm, we let TASPER achieve this goal by considering a limited number of candidate paths. To this end, TASPER exploits the concept of neighborhood of a TX and uses the neighborhood size, denoted by η, as a tunable parameter to trade off the algorithm optimality gap with its time complexity. Let us consider the list of not-scheduledyet and not-expired TXOP requests, sorted in ascending order according to their latest start time (the latest start time of a TX jis defined as dj−τj). Then TX jis within the neighborhood of TX iif their respective indexes in the list differ at most by η. An example of a TX’s neighborhood is given in Fig. 5. In such a way, indicating with TX ithe last scheduled transmission, the search for the next TX to schedule is restricted to the closest TX to TX iin the above-mentioned ordered list. In summary, TASPER’s key idea is that, at each vertex i, it selects as next TX to visit the dominant TX choice in the neighborhood Ni, i.e., the one that (i) is associated with the highest value and that, in case of a tie, (ii) yields the shortest completion time. By doing so, it is possible to select the TXs that have both high priority and low completion time, thus leaving more room to schedule additional TXs. This provides a solution that maximizes the terms appearing in the TASP objective function as well as the number of scheduled TXs. We show the pseudocode of TASPER in Algorithm 1. First, the requested TXOPs to be scheduled are sorted according to their latest start time, dj−τj, forming an ordered list of TXs; hence, each TX jis assigned an index indjcorresponding to its position in this list (Lines 1–2). Then TASPER creates an empty Paths list to store the various paths from αto ωand initializes a Path for each available TX j(Line 3 and Lines 4–11). Notice that each path is initialized with a cumulative value equal to the value associated with TX j, calculated as discussed earlier in this section. Finally, the path time is set to gj+τj, i.e., the generation time of the TX plus the TX duration. For each path, TASPER then applies the FINDPATH procedure, as defined in Line 16. This procedure plays a key role. First (Line 17), it finds the neighbors of TX jthrough another auxiliary procedure, FINDNEIGHBORS, which simply applies the neighborhood mechanism previously described. As remarked above, both already scheduled TXs and any TX whose AoI deadline has expired are obviously excluded from the neighborhood. Then, for each TX nidentified as a neighbor of TX j, the procedure checks whether that TX has already been visited in Path P: if so, it moves to the next neighbor TX (Lines 18–21); otherwise, the procedure includes TX n in Path Pand calculates the new path P′’s value and time component (Lines 22–25). Subsequently, the procedure verifies whether P′is dominated by another, already discovered path 8 Algorithm 1 TASPER algorithm Input -List of transmissions L(TX αexcluded) -Neighborhood size η Output -TXOP scheduling Pbest 1: Order List Lby TX latest start time 2: Assign an index indjto each transmission in List L, equal to the position of TX jin List L 3: Create an empty path List P t 4: for TX jin L do 5: Create an empty Path object P 6: Create an empty list P.visited TX 7: P.visited TX.append(α) 8: P.visited TX.append(j) 9: P.cumulative reward ←P.cumulative reward + vα,j 10: P.time ←gj+τj 11: FINDPATH(Job List L, Path P′, Job j, Path List P t) 12: end for 13: Pbest →max {P t, key =cumulative reward} 14: return Pbest 15: 16: procedure FINDPATH(Job List L, Path P, Job j, Path List P t) 17: Nj←FindNeighbors(Job List L,indj,η) 18: for Tx n∈Njdo 19: if n∈P.visited TX then 20: continue 21: end if 22: P′←P 23: P′.visited TX.append(n) 24: P′.cumulative reward ←P′.cumulative reward + vjn 25: P′.time ←max {gn, P ′.time}+τn 26: if isDominated(P′,n.paths) then 27: continue 28: else 29: for Path P′′ ∈n.paths do 30: if isDominated(P′′ ,P′)then 31: n.paths.remove(P′′ ) 32: P t.remove(P′′ ) 33: end if 34: end for 35: n.paths.remove(P) 36: n.paths.append(P′) 37: P t.remove(P) 38: P t.append(P′) 39: FINDPATH(Job List L, Path P′, Job n, Path List P t) 40: return 41: end if 42: end for 43: end procedure that includes the same TX n(Lines 26–28). If so, P′is discarded and the procedure jumps to the next neighbor TX; otherwise, any path dominated by P′is removed from the Path list (Lines 29–34). In such a case, the old path Pis replaced by P′in both the lists including TX n, and the overall Path list (Lines 35–38). Finally, the procedure is called recursively until the path reaches ω(Line 39). After the procedure has identified the feasible paths, the path with the largest cumulative value is selected (Line 13). TASPER Complexity. The time complexity of TASPER can be computed following a similar procedure to [7]. It is given by O(n·η3·σ·4η), where nis the total number of TXs to be scheduled within a given beacon interval, while σ is the so-called slack, i.e., the maximum number of TXs ready for scheduling across the different time instants in the beacon interval. As an example, in Fig. 3, we have σ=3: indeed, after about 4 ms, and, again, at time instant 15 ms, 3 TXs are available for scheduling (namely, TX 2, TX 3, and TX 4 at 4 ms, and TX 4, TX 5, and TX 7 at 15 ms). Also, to better emphasize the scalability of TASPER with the number of STAs N, consider a given beacon interval and traffic pattern such that each STA generates Ppackets per beacon interval. In this case, the total number of transmissions to be scheduled is given by the number of STAs Nmultiplied by the number of packets P. By fixing the algorithm parameter η, the resulting complexity becomes O(N·P·σ), i.e., it increases linearly with the number of STAs. For instance, as the number of STAs grows from 32 to 128, the algorithm complexity increases by a factor of four. V. SIMULATION FRAMEWORK AND EVALUATION METHODOLOGY This section first describes ns-3-twt – the TWT ns-3-based simulation framework we developed and used for our performance evaluation. Then it introduces our evaluation methodology and simulation settings, as well as the benchmark schemes against which we compare the performance of TASPER. A. The ns-3-twt simulation framework Despite the great interest received by TSN, there exist just a few open frameworks that allow for a reliable simulation of such networks, including a realistic model of IEEE 802.11ax with the TWT mechanism. Among these, to our best knowledge, the most complete existing open-source solution was the one developed by Venkateswaran et al. [2] based on the wellestablished ns-3 framework [10], [11], while other network simulators such as MATLAB or OMNeT++ have not been extended yet to include TWT functionalities. We therefore adopted the simulator in [2] and enhanced their solution by realizing an advanced simulation framework for TWT and TSN scenarios. Our simulator, ns-3-twt, is released under an open-source license2. Building on the already existing implementation of a subset of TWT agreement messages (specifically, the implicit and individual agreements), ns-3-twt introduces a range of enhanced features, including: (i) a flexible, complete TWT configuration (e.g., traffic arrival time, TWT Service Period start and duration), (ii) the possibility to set AoI deadlines for the traffic and to log whether they are met or not, (iii) a customized IEEE 802.11ax simulator to easily set up simulation with IEEE 802.11ax and TWT, (iv) the support for multiple classes of STAs, each with a different energy model, (v) the seamless logging of the value and distribution of several performance metrics, (vi) the possibility to set up multiple TWT networks, connecting the different APs through configurable wired links. We also highlight that a relevant feature of our simulator is the computation of the energy consumed by the STAs, leveraging an accurate energy model that differentiates the energy 2https://github.com/riccardo-rusca/ns-3-twt 9 TWT SP Next TWT TWT SP Wake interval = BCN Beacon 1 Beacon 2 𝑡 (a) ns-3-twt TWT scheduling parameters 𝑡 Beacon 1 Beacon 2 0 ms 102.4 ms TWT duration 6 ms TX 1 𝑔1 𝑡1 TWT duration 5 ms TWT duration 7 ms 𝑡2𝑡3 TX 2 𝑔2 TX 3 𝑔3 (b) Illustrative example of a simple TWT application with 3 STAs Fig. 6. ns-3-twt TWT implementation with the main scheduling parameters and an illustrative example of an application with three STAs that have three different transmissions (TX) with different generation times (gj), TWT SP durations and TWT SP start times (tj). The latter are defined through the Next TWT parameter shown on the left. Notice how the TWT scheduling is periodic unless specified otherwise, and the periodicity, also named wake interval, corresponds to the beacon interval (BCN). consumed in the different PHY-layer states (i.e., transmission, reception, Clear Channel Assessment, sleep, idle). The energy model in [2] has been extended to support different classes of STAs in the same simulation. Each class has its own energy figure for each of the PHY layer states mentioned above. The simulator can report the total energy consumed in each of the PHY layer states for each STA, and several other aggregated energy metrics. In ns-3-twt, the AP unilaterally dispatches a TWT Accept frame to all STAs based on a specified TWT schedule, to schedule their awake and sleep times. Within these frames, a crucial part is the next TWT field, indicating the time after the start of the next beacon interval when the STA can exit the sleep mode and access the physical channel within its TWT SP. The window lasts for a specific duration denoted by the TWT duration. Importantly, in our implementation, the TWT SPs are periodic. As exemplified in Fig. 6(a), this means that, unless a new schedule is provided by the AP, the STAs will periodically use the same TWT SP starting time in each beacon interval. Fig. 6(b) gives an illustrative example of a potential TWT application on ns-3-twt. The sample scenario includes an AP and three STAs, each of which has a burst of traffic to transmit; the figure highlights the traffic generation times (gj), the TWT SP start times (tj=zj−τj), and the respective durations for each STA within a single beacon interval. Note that, by default, ns-3-twt considers a scenario with no other interfering networks. Thus, when scheduling only one STA at a time for each SP, no packet losses or retransmissions are expected to occur, unless the STA and the AP are too far away from each other, or TWT is not enabled. Instead, when multiple STAs are scheduled in the same SP, they may contend for the channel and their transmissions may collide. Investigating this scenario, however, is out of scope of our analysis, as we focus on individual TWT sessions. It is also important to distinguish between losses due to channel propagation conditions or channel contention, and those due to traffic that could not be scheduled by its target deadline. We remark that the latter type of losses is taken into account in the simulations. B. Evaluation methodology To assess the performance of TASPER, we follow three main steps: (i) we first focus on generating some non-trivial instances of the TASP; (ii) we then use TASPER, and the selected benchmarks, to derive the solutions to the instances generated in the first step; (iii) we evaluate the actual performance of such solutions using the ns-3 network simulator. To generate non-trivial instances of the TASP, we started by considering three possible scenarios, with 16, 32, and 64 STAs, respectively. In all experiments, each STA jrequests a TXOP associated with a single TX j. The TX parameters follow the criteria applied in [7], with parameters τ=0.2, and R=0.3. However, since the approach in [7] accounts only for the transmission durations, in our case it is necessary to map the TXOP durations into corresponding values of Modulation and Coding Scheme (MCS) and TX frame size. To this end, the frame size is selected by sampling an empirical distribution shown in Fig. 7(a). Given the frame size, the MCS is determined as the one providing the frame transmission duration that best approximates the requested TXOP. For the generated problem instances, Fig. 7(b) and Fig. 7(c), respectively, show the resulting distributions of STA MCSs and of the TXOP durations. Then, we fixed the number of STAs and evaluated all schemes under study over 100 consecutive beacon intervals. By doing so, the TXs not scheduled during a beacon interval can be scheduled in the following beacon intervals, provided that their AoI deadline has not expired. As for running TASPER on the generated problem instances, we set η=9, as we found this value to offer a good trade-off between solving time and optimality gap. Finally, as mentioned, in our simulations there are no other “interfering” networks. The real-world experimental evaluation (Section VII) instead considers a real environment including other interfering networks operating at 2.4 GHz. C. Benchmarks We compare TASPER against the following strategies: •Optimum: it is the solution calculated by Gurobi, a wellknown numerical optimization solver; •ShortestFirst (SF): it prioritizes the shortest TXOP requests. At first, SF initializes the auxiliary variable t0=0 and considers the subset of all requested TXOPs such that duration τjmeets the condition: t0+τj≤djand t0+τj≤Tb. This implies that the TXOP end time exceeds neither the TX AoI deadline djnor the end of the beacon interval Tb. Among these TXOPs, it schedules the one with the shortest requested duration. In case of ties, it selects one TXOP according to the following decision criteria (in descending order of importance): (1) 16 12345678910 STA ID 0 20 40 60 80 100 Time [ms] (a) Problem instance. White boxes denote the period between TX generations and AoI deadlines; blue bars indicate the TX duration. 12345678910 STA ID 0 20 40 60 80 100 Age of Information [ms] Median AoI AoI deadline (b) TASPER: All STAs are scheduled; for each of them, the measured AoI is reported. 12345678910 STA ID 0 20 40 60 80 100 Age of Information [ms] Median AoI AoI deadline (c) ShortestFirst: The AoI is reported for each STA, except for the 2nd, since it cannot be scheduled. Fig. 12. Problem instance and experimental results: On each box of the box plots, the central mark indicates the median, and the bottom and top edges of the box indicate the 25th and 75th percentiles, respectively. The whiskers extend to the 5th and the 95th percentiles. Light green segments denote the AoI deadlines. RaWAN’s purely asynchronous MAC by introducing slotted ALOHA access and lightweight scheduling primitives, with the goal of reducing collisions and supporting soft real-time traffic patterns in dense deployments, which makes it suitable for industrial use cases. While both WirelessHART and RTLoRa represent significant advances in bringing determinism and efficiency to low-power wireless networks, they operate under fundamentally different design assumptions compared to Wi-Fi-based solutions. WirelessHART works over a low-rate PHY, relying over fixed time-slot communications, multi-hop mesh routing, and channel hopping. RTLoRa, instead, targets long-range communication scenarios, trading off latency and throughput for energy efficiency and coverage, and is constrained by strict duty-cycle regulations and limited bandwidth. In contrast, Wi-Fi networks such as those targeted in this work rely on single-hop communication, and are designed to support high data rates and highly dynamic traffic patterns. Concerning Wi-Fi based networks, [31] gives an in-depth overview of the IEEE 802.11 standards evolution to support deterministic communication. IEEE 802.1Qbv for time-aware queue gating, IEEE 802.1CB for frame replication and elimination, and AP-driven OFDMA scheduling, can be leveraged to reduce contention and enhance predictability without relying on restrictive TWT operations. Building upon this, scheduling strategies based on TWT have been investigated by several works. Using broadcast TWT, the scheduler in [25], based on a genetic algorithm, takes advantage of OFDMA to avoid channel contention: by allocating dedicated resources to each STA, no more than one STA is active at any time. Differently from our work, rather than directly allocating SPs, [25] uses TWT to wake up a number of STAs that is lower or equal to the number of disjoint sets of tones (Resource Units, or RUs), so each STA gets its own RU without colliding with others. Also using OFDMA, [30] proposes a traffic-awareness-based TWT scheduling scheme that leverages spatio-temporal traffic prediction and classification to dynamically adjust TWT parameters and optimize resource allocation across time and frequency. Their scheme, leveraging a greedy scheduling algorithm, improves energy efficiency and QoS by tailoring wake-up intervals and durations to predicted traffic patterns. [26], instead, focuses on throughput and fairness, and proposes two TWT schedulers: a max-rate scheduler, which aims to maximize the overall network throughput, and a proportional fair scheduler, which tries to balance network throughput and fairness so that a minimal level of service is guaranteed to all users. Aiming at higher energy efficiency and uplink throughput, [28] presents a power-saving scheme for overlapping BSS. However, such a scheme schedules TWT SPs of the same duration, thus wasting radio resources in case of short transmissions. Still considering high-density scenarios with overlapping BSS, [29] introduces a TWT-based AP coordination scheme to avoid interference. Here, the key idea is to allocate interfering STAs to different TWT SPs, and to give priority to STAs with high traffic volumes, which leads to increased throughput and energy efficiency. As for TWT applied to IIoT scenarios specifically, [27] extends a wired Time Sensitive Networking (TSN) network to the wireless domain, employing broadcast TWT to separate traffic flows according to their priority and then different RUs to isolate each flow. However, experimental results show poor performance, as the TWT SPs are emulated through WoWLAN instead of being natively implemented by the used transceivers. Looking instead at the performance on Commercial Off-the-Shelf (COTS) devices, [32] investigates the performance of TWT, in the case where TWT agreements are statically configured by STAs (Android smartphones) to decrease energy consumption and are not tailored to traffic characteristics. To the best of our knowledge, we are the first to report a performance analysis of TWT on COTS devices where the TWT SPs are dynamically scheduled based on the expected traffic patterns. The imperative to maintain data freshness has spurred significant research on AoI. Various studies have investigated AoI minimization considering aspects such as maximum AoI thresholds and throughput constraints [33], [34]. However, these AoI-centric formulations typically do not incorporate energy consumption as a primary optimization objective or scheduling constraint, which is a core element of our work where TWT is central. Finally, a preliminary version of our work has appeared 17 TABLE V COMPARISON OF TASPER WITH RELATED WORKS ON WIRELESS INDUSTRIAL NETWORKS AND TWT SCHEDULING STRATEGIES Work (Year) [Ref] Optimization Objective Optimization Technique PHY Layer Real-Time Guarantee EnergyAware AoI Support Evaluation Method TASPER [Ours] Maximize traffic acceptance and energy efficiency under AoI constraints MILP model (TASP) solved via heuristic (TASPER) IEEE 802.11ax Soft (AoIbased) Yes Yes ns-3 simulation and real testbed Chen et al. (2018) [12] Minimize weighted end-toend delay Iterative hop-wise scheduling algorithm (HSA) based on MWIS IEEE 802.15.4 Soft No No MATLAB simulation RT-LoRa by Leonardi et al. (2019) [24] Provide bounded end-to-end delay Centralized, superframebased TDMA strategy LoRa Hard Yes (via QoS classes) No OMNeT++/FLoRa simulation Chen et al. (2021) [25] Maximize throughput under delay constraints Genetic algorithm IEEE 802.11ax Soft (delaybound) Yes No Simulation with traffic generator Yang et al. (2021) [26] Maximize uplink throughput and fairness for TWT STAs Heuristic grouping: max-rate and proportional-fair algorithms IEEE 802.11ax None No No ns-3 simulation (OFDMA uplink) Schneider et al. (2022) [27] Minimize latency and jitter for TSN traffic Time-aware scheduling with TWT SP alignment to TAS IEEE 802.11ax Soft (latency/jitter bounds) No No Real hardware testbed Chen et al. (2022) [28] Maximize energy efficiency under delay bounds in OBSS Graph-coloring grouping + deterministic algorithm IEEE 802.11ax Soft (delaybound) Yes No Simulation with traffic generator Peng et al. (2024) [29] Minimize fixed-duration TWT SPs usage under throughput constraints Greedy algorithm IEEE 802.11ax None Yes No Custom simulator Dang et al. (2024) [30] Improve channel efficiency and reduce power consumption under dynamic traffic Deep learning traffic prediction + heuristic TFST scheduler IEEE 802.11ax Soft (servicespecific) Yes No Custom simulator with traffic model in [35], where however we introduced a simpler version of the TASP problem and just sketched the TASPER algorithm, while showing its performance obtained via simulation only and under a smaller-scale scenario. Novelty. In summary, the innovative features of our work are two-fold. First, concerning energy-saving scheduling, ours is the first work on time-sensitive traffic scheduling that addresses energy-saving besides trying to maximize the number of scheduled transmissions. Second, regarding AoI requirements, existing scheduling problems are designed to comply with delay requirements and do not account for information freshness. Instead, our problem considers AoI constraints to guarantee that the delivered data is not outdated and provides new, fresh information. IX. CONCLUSIONS In this paper, we presented a novel solution for efficient TWT scheduling in time-critical IIoT scenarios. First, we provided a set of motivational findings, showing the advantages of TWT in guaranteeing low and deterministic latency as well as in saving energy. We then proposed a mathematical model of a TWT-enabled Wi-Fi network and formulated the TWT Acceptance and Scheduling Problem (TASP), proving its NP-hardness. In light of the problem complexity, we envisioned an efficient heuristic algorithm, named TASPER, and demonstrated its effectiveness with respect to baseline strategies. Numerical results, obtained using a realistic IIoT scenario and through our ns-3-based TWT simulator, show that TASPER achieves a 24.97% lower mean rejection cost, and up to 14.86% lower energy consumption than the best performing baseline. Additionally, TASPER outperforms HSA, a state-of-the-art solution adapted from WirelessHART [12], reducing the mean rejection cost by up to 26%, and the energy consumption by up to 34%. Finally, using our IIoT TWTcompatible testbed, we validated TASPER’s effectiveness as a traffic scheduling strategy, demonstrating that it admits more transmissions than simpler alternatives without incurring any AoI deadline violations. Future work will extend TASPER to an OFDMA scenario, where Wi-Fi transmissions are allocated in Resource Units spanning both the time and frequency dimensions, and further investigate the stations’ energy consumption. REFERENCES [1] S. Munirathinam, “Industry 4.0: Industrial Internet of Things (IIoT),” in Advances in computers. Elsevier, 2020, vol. 117, no. 1, pp. 129–164. [2] S. Krishnan Venkateswaran, C.-L. Tai, R. Garnayak, Y. Ben-Yehezkel, Y. Alpert, and R. Sivakumar, “IEEE 802.11ax Target Wake Time: Design and Performance Analysis in ns-3,” in 2024 Workshop on ns-3 (WNS3 2024), 2024, pp. 1–9. [3] “IEEE Standard for Information Technology–Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks–Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 1: Enhancements for High-Efficiency WLAN,” IEEE Std 802.11ax2021 (Amendment to IEEE Std 802.11-2020), pp. 1–767, 2021. [4] ns-3 community. ns-3-dev Wi-Fi Module Design Documentation [Online]. Available: https://www.nsnam.org/docs/models/html/wifi-design. html. [Accessed: 08 October 2025]. [5] C. Oguz, F. Sibel Salman, and Z. Bilgint¨ urk Yalc¸ın, “Order acceptance and scheduling decisions in make-to-order systems,” International Journal of Production Economics, vol. 125, no. 1, pp. 200–211, 2010. [6] R. Graham, E. Lawler, J. Lenstra, and A. Kan, “Optimization and Approximation in Deterministic Sequencing and Scheduling: a Survey,” in Discrete Optimization II, ser. Annals of Discrete Mathematics, P. Hammer, E. Johnson, and B. Korte, Eds. Elsevier, 1979, vol. 5, pp. 287–326. [Online]. Available: https://www.sciencedirect.com/science/ article/pii/S016750600870356X [7] M. de Weerdt, R. Baart, and L. He, “Single-machine scheduling with release times, deadlines, setup times, and rejection,” European 18 Journal of Operational Research, vol. 291, no. 2, pp. 629–639, 2021. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S0377221720308468 [8] J. Chuzhoy and R. Ostrovsky, “Approximation algorithms for the job interval selection problem and related scheduling problems,” in Proceedings 42nd IEEE Symposium on Foundations of Computer Science, 2001, pp. 348–356. [9] S. Burer and A. Saxena, “The MILP road to MIQCP,” Mixed integer nonlinear programming, pp. 373–405, 2011. [10] T. R. Henderson, M. Lacage, G. F. Riley, C. Dowell, and J. Kopena, “Network simulations with the ns-3 simulator,” SIGCOMM demonstration, vol. 14, no. 14, p. 527, 2008. [11] F. Raviglione, C. R. Carletti, M. Malinverno, C. Casetti, and C. Chiasserini, “ms-van3t: An integrated multi-stack framework for virtual validation of V2X communication and services,” Computer Communications, vol. 217, pp. 70–86, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0140366424000227 [12] G. Chen, X. Cao, L. Liu, C. Sun, and Y. Cheng, “Joint scheduling and channel allocation for end-to-end delay minimization in industrial WirelessHART networks,” IEEE Internet of Things Journal, vol. 6, no. 2, pp. 2829–2842, 2018. [13] International Electrotechnical Commission, “IEC 62591:2016 - Industrial communication networks – Wireless communication network and communication profiles – WirelessHART,” Available from IEC Webstore, 2016, standard. [14] Espressif Systems. ESP32-C6-WROOM-1 & WROOM-1U Datasheet v1.1 [Online]. Available: https://www.espressif.com/sites/default/ files/documentation/esp32-c6-wroom-1 wroom-1u datasheet en.pdf. [Accessed: 08 October 2025]. [15] E. Khorov, A. Kiryanov, A. Lyakhov, and G. Bianchi, “A Tutorial on IEEE 802.11ax High Efficiency WLANs,” IEEE Communications Surveys & Tutorials, vol. 21, no. 1, pp. 197–216, 2019. [16] M. Nurchis and B. Bellalta, “Target Wake Time: Scheduled Access in IEEE 802.11ax WLANs,” IEEE Wireless Communications, vol. 26, no. 2, pp. 142–150, 2019. [17] T. St¨ uber, L. Osswald, S. Lindner, and M. Menth, “A Survey of Scheduling Algorithms for the Time-Aware Shaper in Time-Sensitive Networking (TSN),” IEEE Access, vol. 11, pp. 61 192–61 233, 2023. [18] “IEEE Standard for Low-Rate Wireless Networks,” IEEE Std 802.15.42020 (Revision of IEEE Std 802.15.4-2015), pp. 1–800, 2020. [19] Semtech. LoRa® and LoRaWAN® [Online]. Available: https: //www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf. [Accessed: 08 October 2025]. [20] F. Chen, T. Talanis, R. German, and F. Dressler, “Real-time enabled IEEE 802.15. 4 sensor networks in industrial automation,” in 2009 IEEE International Symposium on Industrial Embedded Systems. IEEE, 2009, pp. 136–139. [21] D. Chen, M. Nixon, S. Han, A. K. Mok, and X. Zhu, “WirelessHART and IEEE 802.15.4e,” in 2014 IEEE International conference on industrial technology (ICIT). IEEE, 2014, pp. 760–765. [22] M. Luvisotto, F. Tramarin, L. Vangelista, and S. Vitturi, “On the use of LoRaWAN for indoor industrial IoT applications,” Wireless Communications and Mobile Computing, vol. 2018, no. 1, p. 3982646, 2018. [23] H. H. R. Sherazi, L. A. Grieco, M. A. Imran, and G. Boggia, “EnergyEfficient LoRaWAN for Industry 4.0 Applications,” IEEE Transactions on Industrial Informatics, vol. 17, no. 2, pp. 891–902, 2021. [24] L. Leonardi, F. Battaglia, and L. Lo Bello, “RT-LoRa: A medium access strategy to support real-time flows over LoRa-based networks for industrial IoT applications,” IEEE Internet of Things Journal, vol. 6, no. 6, pp. 10 812–10 823, 2019. [25] Q. Chen and Y.-H. Zhu, “Scheduling Channel Access Based on Target Wake Time Mechanism in 802.11ax WLANs,” IEEE Transactions on Wireless Communications, vol. 20, no. 3, pp. 1529–1543, 2021. [26] C. Yang, J. Lee, and S. Bahk, “Target Wake Time Scheduling Strategies for Uplink Transmission in IEEE 802.11ax Networks,” in 2021 IEEE Wireless Communications and Networking Conference (WCNC), 2021, pp. 1–6. [27] B. Schneider, R. C. Sofia, and M. Kovatsch, “A Proposal for Time-Aware Scheduling in Wireless Industrial IoT Environments,” in NOMS 20222022 IEEE/IFIP Network Operations and Management Symposium, 2022, pp. 1–6. [28] Q. Chen, “An Energy-Efficient Channel Access With Target Wake Time Scheduling for Overlapping 802.11ax Basic Service Sets,” IEEE Internet of Things Journal, vol. 9, no. 19, pp. 18 973–18 986, 2022. [29] X. Peng, Y. Fang, C. Li, and L. Guo, “Access Point Coordination Based TWT Scheduling for the Next Generation WLAN,” in 2024 13th International Conference on Communications, Circuits and Systems (ICCCAS), 2024, pp. 238–243. [30] Z. Dang, S. Yan, X. Gu, and Y. Chang, “Traffic Awareness-Based Target Wake Time Scheduling in 802.11ax WLANs,” International Journal of High Speed Electronics and Systems, vol. 34, no. 01, p. 2540080, 2025. [31] D. Cavalcanti, C. Cordeiro, M. Smith, and A. Regev, “WiFi TSN: Enabling Deterministic Wireless Connectivity over 802.11,” IEEE Communications Standards Magazine, vol. 6, no. 4, pp. 22–29, 2022. [32] C. Zhao, B. Li, S. Wang, and T. He, “The First Measurement Study of Target Wake Time Mechanism in 802.11ax on COTS Devices,” in ICC 2023 - IEEE International Conference on Communications, 2023, pp. 4695–4700. [33] C. Li, Q. Liu, S. Li, Y. Chen, Y. T. Hou, W. Lou, and S. Kompella, “Scheduling With Age of Information Guarantee,” IEEE/ACM Transactions on Networking, vol. 30, no. 5, pp. 2046–2059, 2022. [34] I. Kadota, A. Sinha, and E. Modiano, “Scheduling Algorithms for Optimizing Age of Information in Wireless Networks With Throughput Constraints,” IEEE/ACM Transactions on Networking, vol. 27, no. 4, pp. 1359–1372, 2019. [35] C. Puligheddu, F. Busacca, R. Rusca, F. Raviglione, C. Casetti, C. F. Chiasserini, and S. Palazzo, “Target Wake Time Scheduling for TimeSensitive Networking in the Industrial IoT,” in 2024 IEEE 35th Annual International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC). IEEE, 2024. Fabio Busacca is an assistant professor at the University of Catania, Italy. His main research interests are LPWAN protocols for the IoT, AI applied to next-generation communication networks, and underwater networks. Corrado Puligheddu is an assistant professor at Politecnico di Torino, Italy. His main area of interest is the application of machine learning to wireless networks, focusing on radio resource management and network orchestration. Francesco Raviglione is an assistant professor at Politecnico di Torino, Italy. His main areas of interest are wireless and vehicular networks. Riccardo Rusca is a research fellow at Politecnico di Torino, Italy. His main areas of interest are crowd monitoring and time sensitive networking. Claudio Casetti is a Full Professor with Politecnico di Torino, Italy. His research interests are vehicular networks, ITS, 5G/6G, and IoT systems. Carla Fabiana Chiasserini is Full Professor with Politecnico di Torino, Italy. Her research interests are in the design, modeling, and performance evaluation of mobile networks and services. Sergio Palazzo is a Full Professor with the Universit` a di Catania, Italy. His research interests include mobile systems, wireless and satellite networks, and traffic engineering.