C-SLA-MLO: enhancing SLA compliance in industrial Wi-Fi through cooperative multilink operation

Internet of Things 27 (2024) 101269 Available online 27 June 2024 2542-6605/© 2024 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Contents lists available at ScienceDirect Internet of Things journal homepage: www.elsevier.com/locate/iot Research article C-SLA-MLO: Enhancing SLA Compliance in Industrial Wi-Fi through Cooperative Multilink Operation Suneel Kumar a,∗, Daniel Camps-Mur a, Eduard Garcia-Villegas b ai2CAT Foundation, Barcelona, Spain bUniversitat Politecnica de Catalunya (UPC), Barcelona, Spain ARTICLE INFO Keywords: Multilink operation IEEE 802.11be SLAs Wi-Fi 7 ABSTRACT In the dynamic landscape of Industry 4.0, robust wireless connectivity emerges as a critical enabler for Industrial Internet of Things (IIoT) applications. With the advent of Wi-Fi 7’s multilink operation (MLO), the demand for schedulers capable of meeting diverse Service Level Agreement (SLA) requirements within industrial environments becomes paramount. Addressing this need, this paper introduces Cooperative SLA-MLO (C-SLA-MLO), a novel distributed multilink scheduler that balances data across MLO channels to fulfill the SLA of STAs operating within the same BSS. We provide a simulation-based evaluation where we compare C-SLAMLO with other benchmark approaches, in terms of SLA compliance when varying the SLA characteristics, the level of QoS, or background traffic, showcasing an average reduction of 90% in SLA deviation in the industrial use case. This study contributes practical insights for enhancing wireless connectivity in IIoT, offering potential benefits for industrial network optimization by exploiting the MLO feature brought by the new IEEE 802.11be. 1. Introduction Industrial communication technologies are undergoing a significant transformation to realize the vision of Industry 4.0, with the Industrial Internet of Things (IIoT) playing a pivotal role in providing scalable, sustainable, and intelligent solutions [1,2]. IIoT is defined as the interconnected network of intelligent industrial components that are strategically deployed to enhance production efficiency while lowering operational costs. This is achieved through real-time monitoring, effective management, and control of industrial processes, assets, and operational timelines [3]. IIoT imposes diverse requirements including availability [4], ultralow latency, reliability [5], localization accuracy [4], energy efficiency, and security [6]. Current IIoT communications can be divided into those used for critical operations (e.g. safety, control, and monitoring applications), which are often implemented using custom industrial Ethernet technologies like Profinet and Ethercat [7], and those used for non-critical operations (e.g. alerting, supervisory control, and data-logging tasks), typically implemented using Wi-Fi or other wireless IoT technologies [8]. The future vision of IIoT communications consists of transforming communications for critical operations in two steps. First, replacing custom industrial Ethernet technologies with standardized Ethernet Time Sensitive Networking (TSN) technology, thus reducing costs. Second, extending Ethernet TSN technology with wireless connectivity to gain agility in re-defining manufacturing layouts [9]. Both 5GNR and Wi-Fi 8 are candidate enabling technologies to achieve the vision of wireless TSN. Extending Ethernet TSN concepts to the wireless domain poses challenges in terms of network architecture and performance guarantees. In terms of network architecture, integration of IEEE 802.11 and Ethernet TSN is straightforward, as both technologies ∗Corresponding author. E-mail addresses: [email protected] (S. Kumar), [email protected] (D. Camps-Mur), [email protected] (E. Garcia-Villegas). https://doi.org/10.1016/j.iot.2024.101269 Received 17 May 2024; Received in revised form 16 June 2024; Accepted 23 June 2024 Internet of Things 27 (2024) 101269 2 S. Kumar et al. are based on IEEE 802.1 [10]. In the case of 5G, 3GPP has defined an integration model based on TSN-Translator functions, whereby a set of User Equipment (UEs) and the core network behave as a single Ethernet TSN switch [11]. The primary challenge is to deliver comparable performance assurances through wireless technologies as those offered by Ethernet TSN. For example, the TSN framework includes Time-Aware Scheduling (TAS), as defined in IEEE 802.1Qbv [12], which allows bounded end-to-end latencies by defining a set of scheduled gates at each switch port. Reliability is also enhanced using redundant paths, using the Frame Replication and Elimination for Reliability (FRER) mechanism defined in IEEE 802-1CB [13]. Studies have investigated the implementation of these ideas within the context of 5G applied to industry 4.0 [14]. In the case of Wi-Fi though, given its contention-based access and the use of unlicensed spectrum, the progress towards a deterministic latency and reliability has been more limited. However, various Wi-Fi standards have been developed to address these challenges. Among these, Wi-Fi HaLow (IEEE 802.11ah) [15] stands out, designed specifically for the IoT arena. It prioritizes low-power consumption in long-range transmissions in scenarios containing many connected devices. Although its Restricted Access Window (RAW) mechanism could reduce delay variations, that delay will, in fact, increase because stations must wait for their assigned window to transmit. The primary goal of the RAW mechanism is to reduce energy consumption by allowing stations to stay in power-saving mode for longer periods. In contrast, the IEEE 802.11be, certified as Wi-Fi 7, has set the goal of extremely high throughput, and the recently formed IEEE 802.11bn group, the basis of the future Wi-Fi 8, has set enhanced ultra-high reliability as its main goal. Motivated by IEEE 802.11be and bn, the focus of this paper is to advance the state-of-the-art for reliable, and (quasi) deterministic Wi-Fi for IIoT applications. Wi-Fi emerges as a cost-effective solution for indoor applications, contrasting with 5G’s strengths in outdoor environments, making it well-suited for industrial settings. The IEEE 802.11be amendment introduces multilink operation (MLO) as a key feature to enhance performance. Notably, an advanced feature like Multi AP coordination is postponed until the subsequent IEEE 802.11bn amendment. As discussed throughout this paper, MLO plays a pivotal role in enhancing timeliness for Wi-Fi transmissions by simultaneously leveraging multiple links, thereby reducing latency. Furthermore, MLO contributes to improved reliability by enabling the transmission of duplicated packets across various links, and the aggregation of multiple links results in a noteworthy boost in overall throughput. These characteristics collectively position the MLO feature as a compelling solution for addressing the stringent requirements in industrial applications such as IIoT. In this work, we aim to increase reliability and reduce latency for industrial applications such as PLCs, SCADA systems, robotic arms, industrial cameras, and IoT gateways that do not have significant energy constraints. IIoT applications exhibit diverse Service Level Agreement (SLA) requirements for time-critical applications. These range from safety applications demanding a deterministic delay bound around 10 ms (e.g. emergency actions or leak detection), to control and monitoring applications with more flexible requirements spanning from 10 ms to 100 ms [8]. This diversity of SLAs underscores the critical necessity for wireless standards capable of accommodating the varied delay-related demands prevalent in industrial scenarios. The core challenge addressed in this paper is to effectively meet these diverse demands of various industrial SLA flows. MLO stands out as the suitable candidate technology for achieving this goal. Specifically, we aim to develop a scheduler that explicitly considers the SLAs of industrial flows. As of now, there exists no proposed IEEE 802.11be MLO scheduler specifically tailored to handle the diverse SLAs encountered in industrial contexts. Existing schedulers often employ a greedy approach, prioritizing minimal latency for a single time-critical application. However, this strategy may not be optimal for industrial scenarios with a range of SLA requirements. In [16], we proposed SLA-MLO, the first SLA-driven MLO scheduler that dynamically selects the link based on the SLA of a particular flow. This approach distinguishes itself by not adhering to a greedy strategy and instead aims to align with the diverse nature of IIoT application requirements, ranging from stringent and time-sensitive to highly flexible time constraints. The essential Key Performance Indicator (KPI), optimized by SLA-MLO, is the measurement of SLA deviation, representing the extent to which a flow deviates from its prescribed limits, specifically the delay bound value. Building upon this foundation, the present study presents a cooperative SLA-MLO, that allows STA in the same BSS to exchange information about the SLA compliance status of their flows, to optimize the resources allocated to flows suffering from SLA deviations. C-SLA-MLO is able to further decrease SLA violations up to 90% in industrial use cases. The main contributions of the present work are as follows: •This work provides a comprehensive taxonomy of multilink schedulers proposed to date, analyzing their feasibility in specific scenarios. •This work proposes an extension of SLA-MLO [16] called Cooperative SLA-MLO (C-SLA-MLO), that further improves the SLA deviation of time-critical industrial flows by enabling coordination among STAs, thereby allocating more resources to flows that are not meeting their SLAs. •This work implements C-SLA-MLO in the NS-3 simulator, and benchmark its performance in terms of SLA deviation against SLA-MLO and Least Congestion Control (LCC) [17]. The rest of the paper is organized as follows. In Section 2, we first discuss the basics and architecture of MLO, and present different multilink schedulers proposed in the past. In Section 3, we discuss the design of C-SLA-MLO. In Section 4, we provide a comprehensive performance evaluation through different simulation setups that justify our design choices. Lastly, Section 5 summarizes our conclusions and findings. 2. Background and related work In this section, we discuss the motivation, basic concepts, and architectural details behind MLO. In a second subsection, we provide a related literature review. Internet of Things 27 (2024) 101269 3 S. Kumar et al. Fig. 1. Taxonomy of MLO schedulers proposed in the literature. 2.1. Multilink operation The crowded ISM bands pose limitations on wide-channel transmissions, which impacts the maximum potential of technologies like Wi-Fi 7 supporting up to 320 MHz bandwidth. Nevertheless, through strategic spectrum allocation across various bands, we can capitalize on opportunities for broader channels, leading to enhanced throughput and a significant reduction in latency. MLO plays a crucial role in enabling these advancements by facilitating data transmission and reception across multiple radio interfaces, effectively optimizing spectrum utilization across the 2.4 GHz, 5 GHz, and the newly allocated 6 GHz bands. The architecture of Multilink Devices (MLD), is distinct from legacy devices, featuring two main types: AP-MLD and non-AP MLD (i.e. client STAs) that contain Upper and Lower MAC layers. The Upper MAC is uniform across links, managing tasks like sequence numbering, and common functions. The Lower MAC, replicated for each available link, handles tasks like channel access and packet transmission. Each link runs an independent physical layer. The central concern in MLD is optimizing multilink usage within a device, particularly through scheduling, as discussed in the next section. Depending on the capabilities of the device, MLD can be categorized in different ways, as discussed in [18]. •Multilink Single Radio (MLSR): where a device is capable of transmitting and receiving data over one link at a time. •Enhanced Multilink with Single Radio (EMLSR): where a device is capable of receiving data over multiple links using different MIMO RF chains, while transmitting over one link at a time by tracking channel availability across all links. •Multilink Multi-Radio (MLMR): where a device contains multiple radios and is able to operate on multiple links concurrently. MLMR can be further categorized as: –Non-Simultaneous Transmit and Receive (NSTR): where a device is capable of either receiving or transmitting on multiple links at the same time, requiring alignment or deferral of physical layer protocol data units to prevent overlap and ensure smooth operation. –Simultaneous Transmit and Receive (STR): where a device is capable of concurrent transmission and reception of data asynchronously, but requires careful management to prevent inter-device interference to ensure smooth operation. •Enhanced Multilink Multiple Radio (EMLMR): where a device features the capability to reconfigure MIMO chains on each link for improved performance and flexibility. The first available MLO-capable Wi-Fi 7 devices are expected to support single-radio MLO, leveraging existing Wi-Fi 6 hardware. However, as Wi-Fi 7 advances, new STAs will harness the advantages of incorporating multiple radios. Besides, in the IIoT domain, devices requiring reliable connectivity, such as robots or PLCs, are often power connected and are not resource-constrained. Hence, we can assume that MLO will be introduced through MLMR-STR devices, which support simultaneous transmission and reception through multiple radios. The MLO scheduler is a crucial component in multilink devices, playing a key role in their performance. It usually works at the (Upper) MAC layer and controls the transmission of packets among different radio interfaces. The design of the MLO scheduler influences how effective, adaptable, and reliable MLDs are, especially in challenging IIoT environments. 2.2. MLO schedulers Recently, various methods have emerged for implementing multilink scheduling within IEEE 802.11be networks, aimed at enhancing the latency, reliability, and throughput of time-sensitive data. Fig. 1 depicts a taxonomy of multilink schedulers proposed Internet of Things 27 (2024) 101269 4 S. Kumar et al. Table 1 Overview of proposed schedulers for IEEE 802.11be’s multi-link operation and their applicability. Sn. Method Scenario TSN application KPIs Type SLAAwareness 1 Load balancing (LB) [19] High network load Cyclic industrial traffic of motion control with 100 and 1400 byte packet size and inter-packet gap 1 to 10 ms Latency Static No 2 Packet duplication(PD) [19] Low network load Static No 3 Packet splitting(PS) [19] Low network load Static No 4 Hybrid (LB+PS+PD) based on global information [20] Medium and dynamic network load Dynamic No 5 Least congestion control [17] Dynamic traffic in controlled scenario General traffic flows 2–8 Mbps Channel occupancy and throughput Dynamic No 6 Congestion aware load balancing [17] Uncontrolled and denser scenarios Dynamic No 7 Separate data and signaling channels [21] Large and medium sized packet with high priority Voice traffic Delay quantile and efficiency Static No 8 Allocating a dedicated channel [21] Long transmission Static No 9 Splitting dedicated channel into sub-channel [21] Long transmission with intensive and smaller size packet Static No 10 SLA aware scheduling called SLA-MLO [16] Industrial use case Industrial scenario having stringent SLAs of delay bound of 1 ms and flexible SLAs of up to 10 ms SLA deviation Dynamic Yes in the literature. Each of these approaches is well-suited to a specific scenario. These schedulers have been categorized into two categories, static and dynamic. In a static approach, the scheduling mechanism remains fixed throughout the network’s lifetime, regardless of varying traffic conditions. Conversely, in a dynamic approach, the scheduling undergoes dynamic changes over time. The static scheduler includes load balancing (LB), which distributes load among available links, to reduce latency [19], packet duplication (PD), which duplicates the same packets onto multiple links for improving reliability [19], packet splitting (PS), involves breaking down packets into smaller chunks and transmitting them in parallel across multiple links, thereby enhancing data rate [19]. Additionally, channel segregation [21], is another technique, which can be categorized according to the channel allocation. This includes allocating distinct signaling channels for individual data channels, designating a dedicated channel specifically for timecritical data, or dividing this dedicated channel further into smaller sub-channels for more granular data management. A dedicated channel serves well for long transmissions with stringent latency needs, while splitting it further proves beneficial for smaller, high-volume traffic. For scenarios with a large number of flows having varying traffic profiles, a dedicated resource scheme does not scale well. On the other hand, dynamic approaches adapt link-selection policies using information available at the STA, including both global (network-wide) information, and STA or flow-specific. Dynamic load balancing (LB) schedulers for multi-radio access technology (RAT) multi-connectivity (MC) systems are introduced in [22,23]. In [20], authors propose a scheduler for improving the reliability and latency of industrial cyclic traffic by introducing a hybrid approach that selects links by applying PB, PS, or LB according to global information. In [17], the authors compare different policies that are updated based on a link congestion metric. These policies include least congestion control (LCC) that selects links with lesser congestion, as well as both static and dynamic load balancing approaches that take into account the congestion level at each link, namely Congestion-Aware Load Balancing (CALB). The authors performed simulations considering controlled and uncontrolled traffic scenarios. They concluded that LCC performs well in a controlled environment, while CALB performs better in uncontrolled and dense scenarios. However, note that these policies were fixed for the entire life of a flow. In [24], the same authors extended their prior work and suggested that the above policies can be further improved in terms of latency if they are adapted dynamically. Along with these categories, machine learning techniques have also been applied to investigate multilink scheduling. In [25], the Multi-Headed Recurrent Soft-Actor Critic (MH-RSAC), a Reinforcement Learning (RL) algorithm for traffic distribution, is introduced. Comparative analysis against non RL baselines, LCC and LB, highlights MH-RSAC’s superiority, in terms of Throughput Drop Ratio. In [26] authors introduced a Federated Reinforcement Learning (FRL) framework for optimizing link activation in MLO. By enabling Internet of Things 27 (2024) 101269 5 S. Kumar et al. Fig. 2. Network model considered for this work. Background STA1 to STA3 represent legacy devices with single-link capabilities, while the production line (SLA-STA1) and collaborative robots (SLA-STA2) are equipped with multilink capabilities, featuring SLA flows. The lower diagram illustrates the packet handling process at SLA-STAs. collaborative learning among neighboring APs based on real-time performance feedback, it improves throughput fairness and reliability in dense deployment scenarios. However, those studies lack time-related performance figures. Despite the vast potential of this groundbreaking technology in diverse settings, there is a notable gap in the literature regarding the practical application of IEEE 802.11be’s MLO in industrial and factory-like environments. Specifically, there is a lack of proposals that comprehensively study MLO in scenarios involving multiple flows with varying requirements or SLAs, which are common in IIoT environments. For instance, a collaborative robot may require a tight delay bound of 5 ms [27], while a human-machine interface (H2M) may have a more relaxed delay bound of 50–200 ms [28]. Therefore, a different approach is needed to cater to the specific requirements imposed by different traffic flows. It is worth noting here that MLO schedulers proposed in the literature do not explicitly define an SLA, i.e. they try to improve performance in a best-effort way. However, in [29], the authors emphasize various applications, traffic profiles, and connectivity requirements critical from an IIoT perspective. These include isochronous flows, involving regular data transmission with fixed bandwidth and timing requirements, and cyclic traffic, characterized by a repeating pattern of events but with variable intervals. Such traffic patterns are fundamental for modeling IIoT environments, such as machine-to-machine and human-to-machine interactions using XR (Extended Reality) [30], for instance. In [16] we proposed the first SLA-based scheduler called SLA-MLO, which selects links, based on the SLA of particular flows on a per-packet basis, using locally available delay statistics. It was concluded that, in industrial use cases, i.e. presence of multiple flows having different SLAs, the SLA deviation of SLA-MLO improved by almost 50% when compared with LCC. Table 1 summarizes the suitability of proposed schedulers, KPIs for which they have been tested, and TSN application configuration. 3. Design of C-SLA-MLO 3.1. Network model In Fig. 2, we depict the system model considered in this study. The configuration includes two types of IEEE 802.11be STAs and a multilink-enabled Access Point (AP). •Background STAs: generate non-SLA flows (i.e. non time critical traffic) on legacy Wi-Fi devices with single-link connections. The purpose of these STAs is to create background traffic. In Fig. 2, STA1 to STA3 are background STAs. •SLA-based STAs: MLD-STAs responsible for transmitting a diverse set 𝐹of flows, each denoted as 𝑓∈𝐅, and associated with their specific SLA (such as delay bound and allowed percentage of SLA breach). In Fig. 2, production line and collaborative robots are using MLD-STAs for transmitting data flows to the MLD-AP The lower segment of Fig. 2 provides insight into the internal architecture of an MLD device. The operational sequence initiates with the reception of packets at the MAC layer of the MLD-STA coming from the upper layers. Following this, packets are classified Internet of Things 27 (2024) 101269 6 S. Kumar et al. based on their associated flow 𝑓∈𝐅. Under the influence of the specific SLA linked to that flow, the scheduler steers the packet towards a designated link 𝑖∈𝐋with a probability denoted as 𝑃𝑓,𝑖. The primary objective of the SLA-based scheduler is to dynamically and adaptively determine the values of 𝑃𝑓,𝑖 for each flow 𝑓and link 𝑖. It is important to note that all MLD STAs depicted in Fig. 2 are assumed to be STR-capable. Consequently, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) rules are applied independently in all enabled links. In this work, we consider uplink traffic. 3.2. SLA definition In the realm of IIoT applications, the synchronization of data and control signal flows with the manufacturing process’s cycle time stands as a critical consideration. The efficiency and performance of the process are significantly impacted by latency, with cycle times ranging widely — from less than 1 ms for field bus communications to several hundred milliseconds for controllers communicating with edge devices [28]. We define SLAs as follows: Delay Threshold (𝐷_𝑇 𝐻𝑓): maximum permissible delay from when a packet belonging to flow 𝑓is received from the ingress queue until it receives a successful acknowledgment. In environments characterized by the use of unlicensed spectrum and contention-based access (e.g. Wi-Fi networks), defining SLAs encounters significant obstacles. As a result, an exclusive reliance on stringent delay bounds for SLA definition proves impractical in this context. Hence, we added another concept in SLA, defined as follows: Error Threshold (𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓): percentage of packets in flow 𝑓that are permitted to exceed the delay bound 𝐷_𝑇 𝐻𝑓. This includes both packets that experience a delay above the delay bound, and packets that are lost. The objective of the schedulers is then to ensure that the percentage of packets in flow 𝑓exceeding 𝐷_𝑇 𝐻𝑓remains below 𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓within measurement window 𝑇𝑆𝐿𝐴. 3.3. Working of SLA-MLO and cooperative SLA-MLO 3.3.1. SLA-MLO In [16], we proposed SLA-MLO, designed for MLD-STAs, operates on a per-flow, per-packet basis to optimize communication in alignment with predefined SLAs. When a packet is generated at an STA, the algorithm calculates link probabilities (𝑃𝑓,𝑖). Two critical parameters, the delay bound and SLA breach, guide decision-making. If a flow 𝑓adheres to the delay bound (𝐷_𝑇 𝐻𝑓)and stays below the allowed SLA breach level (𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓), all links receive the same probability. Conversely, if the SLA breach is above the threshold value, links showing a delay within the delay bounds are prioritized. However, if none of the links adheres to the delay bound and the SLA breach exceeds the threshold, the probability 𝑃𝑓,𝑖 becomes a function of link delay, ensuring adaptability to diverse network conditions and minimizing the impact of congestion. Algorithm 1outlines the operation of the MLD-STA scheduler for a specific flow 𝑓. Input parameters include the SLA definition for flow 𝑓denoted by (𝐷_𝑇 𝐻𝑓, 𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓). Internal variables are maintained for each flow, including STA delay (𝑆𝑇 𝐴_𝐷𝑒𝑙𝑎𝑦𝑓), which denotes the total duration of transmitting a packet and receiving an acknowledgment, the link delay (𝐷𝑒𝑙𝑎𝑦𝑓,𝑖), experienced by packets of flow 𝑓in link 𝑖, Exponentially Weighted Moving Average (EWMA) of link delays (𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓,𝑖), and SLA breach metric (𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ𝑓). The algorithm outputs probabilities 𝑃𝑓,𝑖 for transmitting the next packet of flow 𝑓over link 𝑖. The algorithm begins with the Main Scheduler Loop() (line 35) when a packet arrives from the upper layer. Before queuing, probabilities for each link are calculated using Procedure 3 (line 22), involving 𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ𝑓computation from Procedure 1. In Procedure 1 (line 1), to calculate the SLA breach, both 𝑆𝑇 𝐴_𝐷𝑒𝑙𝑎𝑦𝑓and 𝐷𝑒𝑙𝑎𝑦𝑓,𝑖 are measured first. Those delays are updated when the acknowledgment of the last transmitted packet is received. The average link delay (𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓,𝑖) is calculated using an Exponentially Weighted Moving Average (EWMA) filter with 𝛼= 0.8(line 4). Two variabls, namely SLA_NotFollowed and SLA_Followed are updated to track the number of packets that either exceed or meet the delay threshold 𝐷_𝑇 𝐻𝑓, respectively. These counts are then used to calculate the SLA breach (𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ𝑓) metric (line 10). Procedure 3 then calculates probabilities based on two states: •State 1: if the SLA breach is below 𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓, all links receive equal probabilities. This is achieved by calling the 𝐴𝑙𝑔𝑜𝑟𝑖𝑡ℎ𝑚𝑆𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛() function. In case of SLA-MLO, the 𝐵𝑒𝑎𝑐𝑜𝑛_𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ flag is always false, hence, all links are assigned equal probabilities (line 18). •State 2: If SLA breach is above 𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓(line 27 to 31). –Case 1: assigns equal probabilities to links still having delay below 𝐷_𝑇 𝐻𝑓as shown in 𝑃 𝑟𝑜𝑐𝑒𝑑𝑢𝑟𝑒3(), line 27. –Case 2: assigns probabilities inversely proportional to link’s average delay, as shown in 𝑃 𝑟𝑜𝑐𝑒𝑑𝑢𝑟𝑒3(), line 30. After probability calculation, the Main Scheduler Loop() generates a random number 𝑅𝑛(line 39). If the number is less than the cumulative probability, the packet is forwarded to the link’s outbound queue, prioritizing higher probability links (line 41 to line 45). The algorithm’s computational complexity is generally 𝑂(𝐿), but given that the number of links L is typically 2 to 3 in real-world implementations, this can be considered O(1) in practical scenarios. Hence, we argue that our per-packet scheduling is feasible even with the high throughput expected in Wi-Fi 7 devices. In summary, SLA-MLO dynamically adapts to network conditions, prioritizing SLA compliance and favoring links with lower delays during breaches. It offers a flexible approach to real-time traffic distribution based on network state. Internet of Things 27 (2024) 101269 7 S. Kumar et al. Algorithm 1 Algorithm for the SLA-MLO and C-SLA-MLO scheduler. Decision at an MLD-STA for flow 𝑓. 1: procedure 1: Upon Receiving Ack ⊳Invoked when ACK is received 2: Get Ack of the last successful packet 3: Measure 𝑆𝑇 𝐴_𝐷𝑒𝑙𝑎𝑦𝑓&𝐷𝑒𝑙𝑎𝑦𝑓,𝑖 4: 𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓 ,𝑖 ←𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓,𝑖 ⋅𝛼 +𝐷𝑒𝑙𝑎𝑦𝑓,𝑖 ⋅(1 − 𝛼)⊳Calculate EWMA of delay for each link 5: if 𝑆𝑇 𝐴_𝐷𝑒𝑙𝑎𝑦𝑓≤𝐷_𝑇 𝐻𝑓then 6: 𝑆𝐿𝐴_𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑 ←𝑆𝐿𝐴_𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑 + 1 7: else 8: 𝑆𝐿𝐴_𝑁𝑜𝑡𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑 ←𝑆𝐿𝐴_𝑁𝑜𝑡𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑 + 1 9: end if 10: 𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ𝑓←𝑆𝐿𝐴_𝑁𝑜𝑡𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑 𝑆𝐿𝐴_𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑+𝑆𝐿𝐴_𝑁𝑜𝑡𝐹 𝑜𝑙𝑙𝑜𝑤𝑒𝑑 ⊳SLA Breach calculation for each flow 11: end procedure 12: 13: procedure 2: Algorithm Selection ⊳Selecting between SLA-MLO and C-SLA-MLO Algorithms 14: if 𝐁𝐞𝐚𝐜𝐨𝐧_𝐒𝐋𝐀_𝐁𝐫𝐞𝐚𝐜𝐡 =𝑡𝑟𝑢𝑒 then ⊳The flag is true when Algorithm is C-SLA-MLO 15: 𝑘=argmax𝑖∈𝐿{𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓 ,𝑖}⊳Finding link having maximum delay/latency 16: 𝑃𝑓,𝑘 = 1 17: else 18: 𝑃𝑓,𝑖 ←1 |𝐋| 19: end if 20: end procedure 21: 22: procedure 3: Calculate Probability ⊳Calculate probability of each link for flow f 23: 𝐋𝐛𝐞𝐥𝐨𝐰 ←{𝑖∈𝐋|𝐷𝑒𝑙𝑎𝑦𝑓,𝑖 < 𝐷_𝑇 𝐻𝑓}⊳Links having delay less than delay threshold value 24: 𝐋𝐚𝐛𝐨𝐯𝐞 ←{𝑖∈𝐋|𝐷𝑒𝑙𝑎𝑦𝑓,𝑖 ≥𝐷_𝑇 𝐻𝑓}⊳Links having delay greater than delay threshold value 25: if 𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ𝑓≤𝐸𝑟𝑟𝑜𝑟_𝑇 𝐻𝑓then 26: 𝐴𝑙𝑔𝑜𝑟𝑖𝑡ℎ𝑚𝑆𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛() 27: else if |𝐋𝐛𝐞𝐥𝐨𝐰|≠0then 28: 𝑃𝑓,(𝑖|𝑖∈𝐿𝑎𝑏𝑜𝑣𝑒)←0⊳Assigning zero probability to link above delay threshold 29: 𝑃𝑓,(𝑖|𝑖∈𝐿𝑏𝑒𝑙𝑜𝑤) ←1 |𝐿𝑏𝑒𝑙𝑜𝑤|⊳Assigning equal probabilities to links below delay threshold 30: else 31: 𝑃𝑓,(𝑖|𝑖∈𝐿)← 1∕  𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓,𝑖 ∑𝑖∈𝐿 1∕𝐴𝑣𝑔𝐷𝑒𝑙𝑎𝑦_𝐿𝑖𝑛𝑘𝑓,𝑖 ⊳Normalized link probability based on respective delays 32: end if 33: end procedure 34: 35: procedure Main Scheduler Loop ⊳The start point of Algorithm 36: while true do 37: Wait for packet assigned to flow 𝑓 38: 𝑃𝑓,𝑖 ←𝐶𝑎𝑙𝑐𝑢𝑙𝑎𝑡𝑒𝑃 𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦() 39: 𝑅𝑛 ←𝑢𝑛𝑖𝑓𝑜𝑟𝑚(0,1) ⊳Random number creation 40: 𝑝𝑟𝑜𝑏 ←0⊳Initializing prob variable with zero 41: for 𝑖∈𝐋do 42: 𝑝𝑟𝑜𝑏 ←𝑝𝑟𝑜𝑏 +𝑃𝑓,𝑖 43: if 𝑅𝑛 < 𝑝𝑟𝑜𝑏 then ⊳Checking random numbers with cumulative probability 44: forwards the packet to link 𝑖 45: end if 46: end for 47: end while 48: end procedure Internet of Things 27 (2024) 101269 8 S. Kumar et al. Table 2 Overview of general simulation parameters. Feature Simulation parameter Frequency band 6 GHz (channel number 15 & 47) Channel width 160 MHz Standard IEEE 802.11ax Aggregation Mode OFF MCS Minstrel Background STAs throughput 1500 B/ms Simulation time 30 s (per simulation) Packet queue size 500p (per link) Traffic type Uplink Propagation model Log distance propagation loss model 3.3.2. Cooperative SLA-MLO We have enhanced SLA-MLO by introducing modifications in the algorithm, resulting in C-SLA-MLO. When at least one MLD STA is the transmitter of a flow failing to meet its SLA, it notifies the other MLD-capable STAs. Said notification could be accomplished in different ways, by leveraging different procedures outlined in the IEEE standard [31], such as the Transmit Stream/Category Measurement report or Multicast Diagnostics report. To elaborate, when an MLD STA detects that one of its flows is not meeting the SLA, it informs the AP using a triggered report, by setting a certain flag. When SLA violation vanishes, it again notifies the AP by means of another triggered report. Upon receiving these notifications, the MLD-capable AP would trigger a flag (𝐵𝑒𝑎𝑐𝑜𝑛_𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ) in the beacon, indicating that at least one STA is failing to meet its SLAs. All MLD STAs monitor the beacon to be notified about the status of other STAs. If the 𝐵𝑒𝑎𝑐𝑜𝑛_𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ is set in this beacon field, then all MLD STAs activate CSLA-MLO. The key modification can be found in procedure 2 of Algorithm 1. In SLA-MLO, when 𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ𝑓is below the allowed threshold, 𝐵𝑒𝑎𝑐𝑜𝑛_𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ is set as false and hence all links receive the same probability (line 18). However, in C-SLA-MLO, as discussed earlier, 𝐵𝑒𝑎𝑐𝑜𝑛_𝑆𝐿𝐴_𝐵𝑟𝑒𝑎𝑐ℎ is set to be 𝑡𝑟𝑢𝑒 by AP, and for all flows that are adhering their SLAs, the link experiencing the highest congestion is selected with probability 1 (line 14 to 16). This adjustment aims to improve SLA-MLO’s performance by directing more flexible traffic flows to links supporting more congestion, thereby creating additional space for flows with stringent requirements. It is worth mentioning here that the complexity of Algorithm 1remains unchanged, as C-SLA-MLO in procedure 2 involves finding a link with a maximum delay that has a computation complexity of 𝑂(𝐿). The fundamental distinction between SLA-MLO and C-SLA-MLO arises when a network encounters situations where flows with stringent requirements fail to meet their SLAs, while flexible flows adhere to their specified SLAs (i.e. delay bounds and SLA breach are below the threshold). In such instances, SLA-MLO uniformly allocates flows having flexible SLA across all links. In contrast, C-SLA-MLO takes a more strategic approach by directing this traffic specifically to congested links. This strategic adjustment aims to optimize the overall performance by enabling less congested links to handle more traffic from flows with stringent SLAs. On the other hand, C-SLA-MLO also requires an established notification mechanism to trigger the solidarity of flexible flows, whereas in SLA-MLO, STAs operate autonomously without requiring any signaling exchange. 4. Performance evaluation To evaluate the performance of different multi-link schedulers, we used NS-3 (V3.36) [32], a packet-level simulator. This version of NS-3 does not fully implement the multilink operation feature introduced in Wi-Fi 7 (as per IEEE 802.11be), so we modified it to incorporate this capability. Specifically, adaptations were made at the MAC level of NS-3 to accommodate MLO. The MAC-level implementation of NS-3 is structured into upper MAC and lower MAC layers. The upper MAC encompasses common functionalities such as sequence number assignment, active probing, and association-related mechanisms. The lower MAC level consists of three modules: 1. Channel Access Manager (CAM): this module manages channel access, including Distributed Coordination Function (DCF) and Enhanced Distributed Channel Access (EDCA). 2. Frame Exchange Manager (FEM): responsible for handling IEEE 802.11 amendment-specific frame exchange sequences. 3. TXOP (Transmission Opportunity): along with its subclass QOS-TXOP, it manages queueing functionalities. For the implementation of the MLO feature in NS-3, separate channel and frame exchange managers per link are necessary. A unified 𝑇 𝑋𝑂𝑃 with distinct queues for each MLO link was constructed. When the Upper MAC decides to send a packet to a link, based on the scheduler decision, the 𝑇 𝑋𝑂𝑃 assigns the corresponding packet to the corresponding queue. After placing the packet in the designated queue, the corresponding 𝐹 𝐸𝑀 and 𝐶𝐴𝑀 are invoked. Following the execution of lower MAC functionalities, the 𝐹 𝐸𝑀 assigns the frame to a particular Wi-Fi Phy (Wi-Fi physical layer entity). 4.1. General simulation setup Unless specified otherwise, the simulated scenarios presented in this section share the following characteristics. Each scenario contains 𝑁number of STAs and 1 AP. To make the simulation more realistic, nodes were randomly deployed within a 15-meter Internet of Things 27 (2024) 101269 9 S. Kumar et al. radius of the AP in every setup, and by default, MLD nodes included two radios in the 6 GHz band. In IIoT environments, other bands are used for non-critical operations, which is why we focus on the greenfield 6 GHz band to provide guaranteed performance. There are two types of STAs, as discussed in the network model depicted in Fig. 2, i.e. legacy devices transmitting non-SLA flows and MLD-STAs transmitting flows with specific SLAs. To represent the heterogeneity of SLAs across flows in IIoT environments, two types of MLD STAs were employed, each with distinct SLA requirements. •The 𝑆𝑡𝑟𝑖𝑛𝑔𝑒𝑛𝑡 type has a strict delay bound, below 5 ms, used for example in isochronous flows for control loops [29], and a 5% of SLA breach threshold (STA1). •The 𝐹 𝑙𝑒𝑥𝑖𝑏𝑙𝑒 type has a more relaxed delay bound of up to 50 ms, used for example in monitoring applications for industry [8,29], and a 10% of SLA breach threshold. Each scenario includes one stringent STA alongside multiple backgrounds and flexible STAs. All simulations adhered to the system model outlined in Fig. 2. Each simulation has been run for at least 10 different seeds. To benchmark the performance of C-SLA-MLO and SLA-MLO, we use a dynamic approach for congestion control, known as Least Congestion Control (LCC), proposed in [17]. This method keeps track of the congestion levels to select the least congested link. Key Performance Indicator (KPI): based on the SLA definition provided in Section 3.2, we evaluate the level of SLA compliance for a flow in terms of SLA-deviation. The calculation of SLA-deviation is outlined as follows: For each SLA flow 𝑓, we measure the percentage of packets with a delay surpassing 𝐷_𝑇 𝐻𝑓at regular intervals of 𝑡_𝑠𝑎𝑚𝑝𝑙𝑒, resulting in a time-varying signal 𝐸𝑟𝑟𝑜𝑟_𝑓(𝑡). To assess SLA compliance, we compute the moving average of 𝐸𝑟𝑟𝑜𝑟_𝑓(𝑡)within a window of duration 𝑇𝑆𝐿𝐴 using a convolution operation: Avg_error_f(𝑡) = Error_f(𝑡) ∗ (1 TSLA )Sq(𝑡)(1) Here, 𝑆𝑞(𝑡)represents a square signal with a duration of 𝑇𝑆𝐿𝐴 seconds. Subsequently, the SLA deviation for flow 𝑓is computed as: SLA_dev_f(t) = max(Avg_error_f(t) − Error_THf,0) (2) It is important to emphasize that the metric 𝑆𝐿𝐴_𝑑𝑒𝑣_𝑓(𝑡)only increases when flow 𝑓surpasses its SLA’s error threshold. If the flow remains below the error threshold, the metric remains unchanged, as there are no discernible benefits from the application perspective. 4.2. Evaluation scenarios We structure our performance evaluation in six different scenarios that answer the following research questions. •Scenario 1: in the first scenario, we show the dynamics of proposed schedulers. •Scenario 2: the second scenario studies how increasing the number of flexible flows influences the performance of stringent flows under different schedulers. •Scenario 3: in the third scenario, we study the effect of SLA heterogeneity, on the performance of the schedulers. The goal is to study how sensitive SLA-MLO and C-SLA-MLO gains are, to the difference between the strict and the relaxed SLAs. •Scenario 4: the fourth scenario involves the evaluation of different QoS settings. The goal is to study the effect of MLO scheduling combined with EDCA prioritization. •Scenario 5: in the fifth scenario, we introduce a third link on MLD devices. The motivation behind this experiment is to check how MLO schedulers behave when we increase the number of links. •Scenario 6: In the final scenario, we reproduce realistic industrial scenario featuring 6 industrial flows and random background traffic. To substantiate our assertion regarding the effectiveness of a multilink scheduler tailored for IIoT environment, it is imperative to conduct a performance evaluation within a setting closely resembling a practical IIoT environment. Table 2 shows the general parameters of the simulation setup. 4.2.1. Scenario 1: Understanding the dynamics of SLA-MLO & C-SLA-MLO This experiment is intended to show the behavior of both SLA-MLO and C-SLA-MLO under different traffic conditions. Simulation setup: One stringent flow with 0.750 ms of delay bound and an error threshold of 5% and 5 flexible flows with 50 ms of delay bound and 10% of error threshold. SLA flows are transmitting 64B packets every 2.5 ms, i.e. 204.8 kbps, and background STAs are transmitting at the rate of one 1500B packet per ms, i.e. 12 Mbps. Discussion:inFig. 3, we plot the output of Algorithm 1i.e. probabilities of links for stringent flows (Fig. 3(a) for C-SLA-MLO and Fig. 3(b) for SLA-MLO) and for flexible flows (Fig. 3(d)). Fig. 3(c) shows the SLA breach of the stringent flows. The simulation is divided into 3 phases. •During the first 10 s of simulation, there is no background traffic on either link, resulting in near-zero SLA breach for both stringent and flexible flows in both schedulers. Consequently, probabilities of selecting link 1 or link 2 in the stringent flow are 50% for both links (Algorithm 1, line 18). Internet of Things 27 (2024) 101269 16 S. Kumar et al. Table 6 Scenario 5 simulation setup. (a) Flow settings in 3 Links setup Flow # Error threshold Delay Bound 1 5% 2 ms Relaxed flows (2 onwards) 10% 50 ms (b) General settings Feature Simulation parameter SLA flows Data rate 64 B/5 ms Background STAs ratio at start 10:10:5 (Link1:Link2:Link3) Stringent Vs Relaxed Flows at start 1:10 (Stringent : Flexible) Frequency Band 6 GHz (channel number 15, 47 & 79) Access Category for SLA Flows AC_VI - CW(15,63) Access Category for Background flows Default (AC_BK) Table 7 Scenario 6 simulation setup. (a) FLow settings for industrial scenario Flow # Error threshold Delay Bound 1 5% 1 ms 2 to 6 10% 10 ms (b) General settings Feature Simulation parameters Frequency band 6 GHz & 5 GHz Channel width 160 MHz & 20 MHz Rate Control Algorithm Minstrel Flow1 Motion Control (64 B/1 ms) [33] Flow 2 to 6 Close loop Control (64 B/10 ms) [33] Background flow Videos traffic (1500 B packet with data rate of 40 and 46.5 Mbps in total on link1 and link2) [33] Background STAs in Start 5:9 (Link1:Link2) Stringent Vs Relaxed Flows 1:6 (Stringent : Flexible) 4.2.6. Scenario 6: Realistic industrial scenario In the previous scenarios, we have considered artificial traffic patterns that have allowed us to better understand the factors governing the performance of the different MLO schedulers under study. However, in an industrial or factory-like scenario, multiple machines with different traffic patterns and QoS requirements need to interact seamlessly to ensure smooth and efficient operations. The objective of this experiment is to mimic a realistic industrial scenario by simulating real traffic models, data rates, and interference. This experiment is specifically tailored to assess the effectiveness of the proposed scheduler in an industrial context. Simulation Setup: in Table 7, we summarize most relevant parameters. We have chosen six industrial flows, where flow 1 represents motion control traffic and all others represent closed-loop control traffic (through mobile-connected I/O gateways), as proposed in [33]. It is noted here that flow 1 presents the most stringent SLA. In real industrial scenarios, background traffic can be periodic or aperiodic. Hence, we randomly assigned background traffic on and off time, i.e. each background STA will start and stop a background flow randomly, but at a fixed packet inter-arrival time. To test SLA deviation, we increased the number of background STAs while keeping Link 1 slightly less congested than Link 2 ( 40 Mbps and 46 Mbps, respectively). On average, we ensured that background flows last for at least 18 s out of the 30 s of simulation time. Discussion: The SLA deviation for the motion control (stringent) flow in an industrial scenario is depicted in Fig. 9. Notably, SLA-MLO and C-SLA-MLO exhibit remarkable performance compared to LCC in scenarios with dynamic background traffic in the industrial setting. Initially, the improvement is substantial, with C-SLA-MLO showing an average improvement of 73% compared to LCC and 48% compared to SLA-MLO. Additionally, SLA-MLO demonstrates a 60% improvement compared to LCC. The increase in the number of background STA leads to an increase in SLA deviation for all SLA flows. As a consequence, relaxed flows (closed loop control) start failing to meet their SLAs thus moving packets to the faster link, leaving less room for stringent flow transmissions. In such instances, the improvement of C-SLA-MLO diminishes to 36% compared to LCC and 17% compared to SLA-MLO. For SLA-MLO, the improvement decreases to 22% compared to LCC. The improvement in SLA deviation can be understood by looking at the flow percentage graph in Fig. 9(b). Initially, for C-SLAMLO, the average percentage of relaxed flows through the congested link is high and decreases with an increase in background STAs. The number of stringent flows passing through the congested link is initially low but gradually increases over time, when the relaxed flows move away from the congested link. A similar trend is observed for SLA-MLO, where the percentage of flexible flows Internet of Things 27 (2024) 101269 17 S. Kumar et al. is around 50% on average on the congested link initially, but this percentage decreases after reaching a point of 12–16 background STAs. It is worth noting that here SLA deviation for flexible flows is 5% to 10% for C-SLA-MLO and up to 2.5% to 7% for SLA-MLO. In summary, these results demonstrate the ability of C-SLA-MLO to better protect time-sensitive flows in realistic industrial scenarios. However, all schedulers suffer when the amount of background load in the channel exceeds the channel capacity. Admission control, limiting the number of background flows, would be required to limit SLA deviation in all situations. 5. Conclusion In industrial Internet of Things (IIoT) scenarios, ensuring SLA compliance is paramount for maintaining operational efficiency and reliability, especially considering the diverse set of flows with varying SLA requirements prevalent in industrial environments. In this study, we introduced C-SLA-MLO, a cooperative multilink scheduling algorithm aimed at enhancing SLA adherence in industrial WiFi networks leveraging the new MLO feature introduced in IEEE 802.11be. Through rigorous evaluation, we demonstrated significant performance improvements, with C-SLA-MLO achieving up to a 90% enhancement in SLA compliance compared to other approaches in industrial use cases. Our assessment encompassed six scenarios, each tailored to address specific research questions and assess the effectiveness of C-SLA-MLO in diverse network conditions. In Scenario 1, we showcased the dynamic adaptability of the proposed scheduler, highlighting its ability to prioritize flows based on SLA requirements. Scenario 2 explored the effect of augmenting the number of flexible flows on stringent flow performance, resulting in an improvement of up to 50% in SLA deviation. Meanwhile, Scenario 3 delved into SLA heterogeneity and its impact on scheduler gains, with enhancements of up to 35% in SLA deviation observed. Furthermore, Scenario 4 scrutinized the evaluation of diverse Quality of Service (QoS) settings, showing the combined effect of MLO scheduling with EDCA prioritization to optimize performance. Expanding our analysis, Scenario 5 introduced a third link on MLD devices to examine scheduler behavior in the context of increased link diversity, leading to a 30% improvement in SLA deviation. Finally, in Scenario 6, we simulated a realistic industrial environment featuring multiple industrial flows and random background traffic, reaffirming the effectiveness of C-SLA-MLO in practical IIoT settings. In this case up to 90% of improvement in SLA deviation was observed. As for future work, we envision extending C-SLA-MLO to multi-AP scenarios to address larger-scale industrial networks and further enhance its adaptability to evolving network dynamics. Additionally, exploring optimization techniques for resource allocation and traffic management could offer additional insights into improving SLA compliance in complex industrial environments. CRediT authorship contribution statement Suneel Kumar: Writing – original draft, Visualization, Validation, Software, Resources, Methodology, Investigation, Formal analysis, Data curation. Daniel Camps-Mur: Writing – review & editing, Writing – original draft, Validation, Supervision, Resources, Methodology, Investigation, Funding acquisition, Formal analysis, Conceptualization. Eduard Garcia-Villegas: Writing – review & editing, Writing – original draft, Validation, Supervision, Resources, Methodology, Investigation, Funding acquisition, Formal analysis, Conceptualization. Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Data availability No data was used for the research described in the article. Acknowledgments This work is supported by the EU’s H2020 5GSmartFact project under the MSCA, Spain grant agreement ID 956670. This work was also partly supported by the Spanish the MCIN/AEI, Spain/ 10.13039/501100011050 through project PID2019-106808RA-I00 and MINECO, Spain and EU PRTR UNICO I+D number TSI-063000-2021-15-6GSMART-EZ. Disclousre instrutions During the preparation of this work, the authors used ChatGPT 3.5 to enhance the readability of certain paragraphs within this paper. After using this tool, the authors reviewed and edited the content as needed and took full responsibility for the content of the publication. Internet of Things 27 (2024) 101269 18 S. Kumar et al. References [1] S.N. Anbalaga, M. Schwarz, R. Bemthuis, P. Havinga, Assessing factory’s Industry 4.0 readiness: A practical method for IIoT sensor and network analysis, Procedia Comput. Sci. 232 (2024) 2730–2739. [2] Z. Fatima, A.U. Rehman, R. Hussain, S. Karim, M. Shakir, K.A. Soomro, A.A. Laghari, Mobile crowdsensing with energy efficiency to control road congestion in internet cloud of vehicles: a review, Multimedia Tools Appl. 83 (18) (2024) 53949–53974. [3] W.Z. Khan, M.H. Rehman, H.M. Zangoti, M.K. Afzal, N. Armi, K. Salah, Industrial internet of things: Recent advances enabling technologies and open challenges, Comput. Electr. Eng. 81 (2020). [4] J. Mustafa, Kristian O. Sandstr, Niclas Ericsson, L. Rizvanovic, Analyzing availability and QoS of service-oriented cloud for industrial IoT applications, in: 2019 24th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA, IEEE, 2019, pp. 1403–1406. [5] Z. Ma, M. Xiao, Y. Xiao, Z. Pang, H.V Poor, B. Vucetic, High-reliability and low-latency wireless communication for internet of things: Challenges, fundamentals, and enabling technologies, IEEE Internet Things J. 6 (5) (2019) 7946–7970. [6] R. Nazir, A. Laghari, K. Kumar, S. David, M. Ali, Survey on wireless network security, Arch. Comput. Methods Eng. (2021) 1–20. [7] X. Wu, L. Xie, End-to-end delay evaluation of industrial automation systems based on EtherCAT, in: 2017 IEEE 42nd Conference on Local Computer Networks, LCN, IEEE, 2017. [8] E. Artetxe, O. Barambones, I. Calvo, P. Fernández-Bustamante, I. Martin, J. Uralde, Wireless technologies for Industry 4.0 applications, IEEE Trans. Ind. Inform. 16 (3) (2023) 1349. [9] M. Noor-A-Rahim, J. John, F. Firyaguna, H.H.R. Sherazi, S. Kushch, A. Vijayan, E. O’Connell, D. Pesch, B. O’Flynn, W. O’Brien, et al., Wireless communications for smart manufacturing and industrial IoT: Existing technologies, 5G and beyond, Sensors 23 (2023) 73. [10] A. Adame, M. Carrascosa-Zamacois, B. Bellalta, Time-sensitive networking in IEEE 802.11be: On the way to low-latency Wi-Fi 7, Sensors 21 (2021) 4954. [11] L. Martenvormfelde, A. Neumann, L. Wisniewski, L. Schreckenberg, Co-configuration of 5G and TSN enabling end-to-end quality of service in industrial communications, 2021, https://opendata.uni-halle.de//handle/1981185920/41505. [12] Inc. Institute of Electrical and Electronics Engineers, Official website of the 802.1 time-sensitive networking task group, 2016, URL http://www.ieee802. org/1/pages/tsn.html. (Accessed 01 January 2024). [13] IEEE standard for local and metropolitan area networks–frame replication and elimination for reliability, in: IEEE Std 802.1CB-2017, 2017, pp. 1–102. [14] A. Larrañaga, M.C. Lucas-Estañ, I. Martinez, I. Val, J. Gozalvez, Analysis of 5G-TSN integration to support industry 4.0, in: 2020 25th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA, Vol. 1, 2020, pp. 1111–1114. [15] Wi-Fi Alliance, Wi-Fi alliance introduces low power, long range Wi-Fi halow, 2016, www.wi-fi.org. [16] S. Kumar, E. Garcia-Villegas, D. Camps-Mur, SLA-MLO: Congestion-aware SLA-Based scheduling of multiple links in IEEE 802.11be, in: 2024 IEEE 21st Consumer Communications & Networking Conference, CCNC, 2024, pp. 875–880. [17] A. López-Raventós, B. Bellalta, IEEE 802.11be multi-link operation: When the best could be to use only a single interface, in: 2021 19th Mediterranean Communication and Computer Networking Conference, MedComNet, IEEE, Ibiza, Spain, 2021, pp. 1–7. [18] IEEE P802.11 Working Group, IEEE P802.11be™/D5.0, November 2023 (amendment to IEEE P802.11-REVme/™D3.0), Draft Standard IEEE P802.11be™/D5.0, IEEE Computer Society LAN/MAN Standards Committee, Three Park Avenue, New York, New York 10016-5997, USA, 2023, Draft 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 8: Enhancements for extremely high throughput (EHT). [19] M.-T. Suer, C. Thein, H. Tchouankem, L. Wolf, Multi-connectivity as an enabler for reliable low latency communications—an overview, IEEE Commun. Surv. Tutor. 22 (1) (2019) 156–169. [20] S.M. Theres, C. Thein, H. Tchouankem, L. Wolf, Adaptive multi-connectivity scheduling for reliable low-latency communication in 802.11be, in: 2022 IEEE Wireless Communications and Networking Conference, WCNC, IEEE, 2022, pp. 102–107. [21] D.V. Bankov, A.I. Lyakhov, E.M. Khorov, et al., On the use of multilink access methods to support real-time applications in Wi-Fi networks, J. Commun. Technol. Electron. 66 (2021) 1476–1484, URL https://doi-org.recursos.biblioteca.upc.edu/10.1134/S1064226921120056. [22] L. Diez, A. Garcia-Saavedra, V. Valls, X. Li, X. Costa-Perez, R. Agüero, LaSR: A supple multi-connectivity scheduler for multi-RAT OFDMA systems, IEEE Trans. Mob. Comput. 19 (3) (2020) 624–639. [23] C. Roman, P. Ball, S. Ou, Evaluating the benefit of a smart scheduler in a non-cooperative, multi-user heterogeneous wireless ITS environment, in: 2018 11th International Symposium on Communication Systems, Networks & Digital Signal Processing, CSNDSP, 2018, pp. 1–6. [24] A. López-Raven´ tos, B. Bellalta, Dynamic traffic allocation in IEEE 802.11be multi-link WLANs, IEEE Wirel. Commun. Lett. 11 (7) (2022) 1404–1408. [25] P.E. Iturria Rivera, M. Chenier, B. Herscovici, B. Kantarci, M. Erol-Kantarci, RL meets multi-link operation in IEEE 802.11be: Multi-headed recurrent soft-actor critic-based traffic allocation, 2023, arXiv preprint arXiv:2303.08959. URL https://arxiv.org/abs/2303.08959. [26] R. Ali, B. Bellalta, A federated reinforcement learning framework for link activation in multi-link Wi-Fi networks, in: 2023 IEEE International Black Sea Conference on Communications and Networking, BlackSeaCom, 2023, pp. 360–365. [27] S. Sudhakaran, V. Mageshkumar, A. Baxi, D. Cavalcanti, Enabling QoS for collaborative robotics applications with wireless TSN, in: 2021 IEEE International Conference on Communications Workshops, ICC Workshops, 2021, pp. 1–6. [28] M.K. Atiq, R. Muzaffar, O. Seijo, I. Val, H.-P. Bernhard, When IEEE 802.11 and 5G meet Time-Sensitive networking, IEEE Open J. Ind. Electron. Soc. 3 (2021) 14–36. [29] D. Cavalcanti, C. Cordeiro, M. Smith, A. Regev, Wi-Fi TSN: Enabling deterministic wireless connectivity over 802.11, IEEE Commun. Stand. Mag. 6 (2022) 22–29. [30] M. Alsakati, Wi-Fi 7: Multi-Link Operation in XR Industrial Scenarios, (Master’s thesis), KTH Royal Institute of Technology, 2022. [31] IEEE Computer Society, 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, LAN/MAN Standards Committee, 2020, URL https://ieeexplore.ieee.org/document/9109952. IEEE Std 802.11TM -2020 (Revision of IEEE Std 802.11-2016). [32] NS-3 Development Team, NS-3 Wi-Fi Module Design, URL https://www.nsnam.org/docs/models/html/wifi-design.html. NS-3 Documentation. [33] P.M. Rost, T. Kolding, Performance of integrated 3GPP 5g and IEEE TSN networks, IEEE Commun. Stand. Mag. 6 (2) (2022) 51–56.