Multi-Objective Optimization of Orchestra Scheduler for Traffic-Aware Networks

Highlights

What are the main findings?

• OPTIMAOrchestra_ch4 achieves 0.72 mA current consumption with 100% reliability in static networks.
• The inmobile networks used in this study, i.e., both OPTIMAOrchestra variants, maintain 100% reliability with 6.36 mA current consumption.

What is the implication of the main finding?

• The proposed scheduler enhances network efficiency, balancing latency–energy trade-offs effectively.
• It supports large-scale, heterogeneous network deployments, crucial for the development of robust smart city infrastructures.

Abstract

The Internet of Things (IoT) presents immense opportunities for driving Industry 4.0 forward. However, in scenarios involving networked control automation, ensuring high reliability and predictable latency is vital for timely responses. To meet these demands, the contemporary wireless protocol time-slotted channel hopping (TSCH), also referred to as IEEE 802.15.4-2015, relies on precise transmission schedules to prevent collisions and achieve consistent end-to-end traffic flow. In the realm of diverse IoT applications, this study introduces a new traffic-aware autonomous multi-objective scheduling function called OPTIMAOrchestra. This function integrates slotframe and channel management, adapts to varying network sizes, supports mobility, and reduces collision risks. The effectiveness of two versions of OPTIMAOrchestra is extensively evaluated through multi-run experiments, each spanning up to 3600 s. It involves networks ranging from small-scale setups to large-scale deployments with 111 nodes. Homogeneous and heterogeneous network topologies are considered in static and mobile environments, where the nodes within a network send packets to the server with the same and different application packet intervals. The results demonstrate that OPTIMAOrchestra_ch4 achieves a current consumption of 0.72 mA while maintaining 100% reliability and 0.86 mA with a 100% packet delivery ratio in static networks. Both proposed Orchestra variants in mobile networks achieve 100% reliability, with current consumption recorded at 6.36 mA. Minimum latencies of 0.073 and 0.02 s are observed in static and mobile environments, respectively. On average, a collision rate of 5% is recorded for TSCH and RPL communication, with a minimum of 0% collision rate observed in the TSCH broadcast in mobile networks. Overall, the proposed OPTIMAOrchestra scheduler outperforms existing schedulers regarding network efficiency, time, and usability, significantly improving reliability while maintaining a balanced latency–energy trade-off.

1. Introduction

Internet of Things has emerged as a groundbreaking technology with notable applications in the domain of smart homes, smart cities, etc., where devices communicate wirelessly [1,2] with each other while operating under constraints such as limited transmission rates and computational power [3], as well as a requirement for low power consumption [4,5]. Due to the sheer amount of devices involved and the requirement to maintain low-power operations, ensuring the desired quality of service in such a situation is complicated [6]. In addition, establishing heterogeneous smart applications is challenging due to their requirements, network architectural heterogeneity, and communication technology. IoT application orchestration, optimal configuration, and holistic monitoring are significant problems for such an environment [7]. Ref. [3] suggested several smart home architectures using IoT technologies, where the best configuration is selected using a trusted third party (TTP). Furthermore, an enhanced smart home system integrates the concept of an event timer to ensure that the most efficient path to the server node is achieved. Inevitably, collisions and data loss rates escalate significantly in vast and sprawling networks, posing a grave challenge to network reliability and data integrity. Although it considers the orchestration and optimization of the performance parameters, it overlooks the number of collisions during communication. The TSCH protocol, standardized by IEEE 802.15.4-2015 [8], offers a robust solution for low-power and lossy networks (LLNs). This link layer protocol ensures high reliability, minimal current consumption, and low latency. Moreover, by employing channel hopping, it enhances resilience against narrow-band interference and multi-path fading, thereby enabling efficient low-power communication.

As low-power networking technology advances, synchronized communication is emerging as the preferred option for critical applications. Slotting has become increasingly prominent as a means to tackle the communication difficulties encountered in dense IoT networks [9]. It involves dividing the network’s available time into discrete slots that serve various purposes, such as data transmission, reception, and other essential operations. Nonetheless, achieving efficiency in slotting requires synchronization of every node in the network. TSCH adds an advanced scheduling layer that greatly enhances communication efficiency and reliability in low-power wireless networks [10], building upon the firm basis of the IEEE 802.15.4 standard. TSCH offers a robust and adaptable framework for implementing different scheduling algorithms, facilitating dependable and effective communication in various low-power wireless applications. Although the IEEE standard requires the use of time-slot scheduling in TSCH networks, creating and maintaining the schedules is not addressed within its scope [11]. For this reason, several TSCH scheduling schemes have been proposed recently, including the minimal configuration schedule [12] of 6TiSCH [13] and Orchestra [14]. The current work extends the work done in [3] to find a suitable scheduler among Orchestra and 6TiSCH minimum scheduling functions. The existing schedulers have multiple open issues, such as cell collision avoidance, adaptive autonomous scheduling, channel estimation, traffic differentiation, mobility support, etc. The proposed scheduler in this work addresses all these challenges.

This research endeavors to significantly improve the performance of modified smart home (MSH) and modified smart home optimized path (MSHOP) protocols in smart home environments by introducing a novel slotting mechanism called OPTIMAOrchestra. Ensuring low end-to-end delay and optimized current consumption while maintaining a high packet delivery ratio under varying traffic rates is crucial for numerous industrial applications [15]. This innovative approach aims to simultaneously achieve multiple critical objectives: minimizing latency, collisions, and current consumption along with maximizing packet delivery ratio while maintaining robust reliability for seamless communication in both homogeneous and heterogeneous networks. The proposed architecture leverages the established foundation of RPL for routing and seamlessly integrates TSCH alongside various schedulers into the TTP and individual nodes. Furthermore, it effectively manages interconnected cells to minimize buffering delays, ensuring smooth data flow. Our contributions focus on several key aspects:

• Development of a custom script: This script generates diverse homogeneous and heterogeneous topologies within a simulated environment, utilizing a trusted third party to facilitate communication within the TSCH-Sim tool.
• Comparative analysis: A comprehensive analysis is conducted to identify the most suitable scheduler, ensuring efficient network operation.
• Optimized scheduling: We introduce an innovative autonomous scheduling function, OPTIMAOrchestra, incorporating an optimized slotframe and packet generation cycle.
• Enhanced cell-level optimization: A specific optimization strategy, OPTIMAOrchestra_ch4, is implemented to improve the transmission and reception of Enhanced Beacon (EB) packets within individual cells. This strategy includes attention shifts to prioritize unmatched broadcast and unicast traffic, followed by regular unicast data, while dynamically adjusting slotframe sizes for efficient resource utilization.
• Enhanced channel-level optimization: OPTIMAOrchestra_ch11 is implemented to enable a multi-channel hopping sequence in the networks to help in proactive cell collision avoidance.

This research aims to establish a highly efficient and reliable communication framework for smart homes, which performs better than the previously designed MSHOP. It also shows the extensive application in dense topologies for industrial IoT (IIoT). The rest of the article is organized as follows. The technical context and summaries of prior research on time-slotted channel hopping, Orchestra scheduling, and the TSCH-Sim tool are presented in Section 2. Section 3 outlines the experimental configuration for the planned task, while Section 4 presents the performance evaluation based on the obtained results. Finally, Section 5 concludes this article and provides insights into future directions.

2. Related Work

This section is divided into three parts. First, we present a brief introduction to the TSCH and 6TiSCH, followed by the state-of-art Orchestra scheduler, and ending with the existing slotting mechanism.

Reference [9] extensively examines the IEEE 802.15.4e standard amendment, covering its objectives, notable features, improvements, and applications. It offers a deep dive into the technical intricacies of IEEE 802.15.4e, mainly focusing on enhancements such as time-slotted channel hopping within the MAC layer. IEFT RFC 7554 [8] addresses the need for IEEE 802.15.4e TSCH devices to coexist harmoniously with other devices, along with managing and configuring IEEE 802.15.4e TSCH networks, including tasks such as network monitoring, configuration updates, and fault management. An architectural framework for deploying IPv6 over the time-slotted channel hopping mode of IEEE 802.15.4, commonly known as 6TiSCH, is described in [13]. 6TiSCH is considered a minimal mode operation, which includes a collection of protocols, including the IPV6 Low-Power Lossy Area Network (6LoWPAN) framework and its routing protocol (RPL) [13]. Reference [16] provides insights into the fundamental principles necessary to understand scheduling in channel hopping MAC for LLNs, underscoring the importance of real-time communication requirements, traffic models, and radio link characteristics as crucial factors influencing scheduling algorithms in IIoT. Moreover, ref. [6] conducts a systematic mapping review focusing on traffic-aware scheduling algorithms in industrial TSCH networks, offering guidance for developing pragmatic traffic-aware scheduling functions and addressing relevant unresolved matters in this domain. Autonomous scheduling methods in TSCH networks are examined in [17], where nodes independently manage communication without a central coordinator. It evaluates various link-level and network-level approaches across diverse traffic and network configurations.

Duquennoy et al. [14] introduce Orchestra as a self-organizing scheduling system for TSCH networks, minimizing transmission collisions and eliminating the need for a central coordinator. This approach achieves highly reliable data delivery, reduced energy consumption, and scalability for large networks. However, this work fails to address the mobility factor in the communication network. To address this, we have proposed a novel slotting mechanism called OPTIMAOrchestra to improve the performance of MSH and MSHOP in smart home environments. It addresses specific challenges in smart home communication, such as minimizing end-to-end delay, optimizing energy consumption, and maximizing packet delivery ratios under varying traffic rates in both static and mobile environments. The key contributions of this work include the development of a custom script for generating smart home topologies, comparative analysis of schedulers, introduction of the autonomous scheduling function OPTIMAOrchestra, and implementation of enhanced cell-level and channel-level optimizations.

An autonomous and adaptive slot allocation scheme that adjusts the number of slots per slotframe according to varying traffic is proposed in [18]. A novel scheduling approach for TSCH networks called Autonomous Link-based Cell Scheduling is proposed in [19]. This self-organizing approach eliminates contention, minimizes collisions, and improves reliability. Jeong et al. present OST, a dynamic scheduling technique for TSCH networks that adapts to fluctuating traffic demands [20]. OST leverages existing data and ACK packets for communication, eliminating the need for additional overhead protocols. A traffic-aware elastic slotframe adjustment scheme is proposed in [21], where each node dynamically adjusts its slotframe size based on the estimated contention level from its neighbors. Traffic-aware elastic slotframe adjustment (TESLA) decreases the slotframe size when there is high traffic, allowing for more frequent communication and reduced packet collisions. The paper acknowledges Orchestra’s potential and suggests further research to improve its performance. The Escalator scheduler proposed in [22] tackles convergecast inefficiency in TSCH networks by offering a novel, fully autonomous scheduling scheme. Each node calculates its own consecutive time slot schedule for faster data delivery, achieving lower delays and higher packet delivery than existing methods. The Optimized Scheduling Cell Allocation Algorithm (OSCAR) for convergecast, an improved scheduling algorithm for convergecast in TSCH networks, is presented in ref. [23]. Unlike existing approaches, OSCAR optimizes slot allocation based on each node’s distance to the root node and traffic load. Overall, all the reference works aim to improve the efficiency and reliability of wireless networks. They target different application domains and employ distinct approaches and optimization strategies tailored to their respective contexts.

Table 1. Existing work on time-slotted channel hopping.

Approach	Advancement	Result
TSCH [24]	Parameterized adaptive and autonomous scheduling	Minimizes latency and energy consumption
TSCH [25]	Comprehensive study on TSCH-minimal and Orchestra	Orchestra outperforms
TSCH [26]	Investigate the use of TSCH protocol with Orchestra scheduling	Orchestra is not convenient for several delay-sensitive IoT applications
TSCH [27]	Performance analysis of Bidirectional Multicast RPL Forwarding (BMRF) over TSCH	BMRF’s LL unicast was found to outperform the LL broadcast
TSCH [28]	Interference Collision-Free Scheduling (ICFS), and Interference Collision-Free Scheduling Without Redundant Data (ICFS-WRD) algorithms are proposed to reduce internal collisions	ICFS saves approximately 23% energy, and ICFS-WRD delivers packets twice as fast as ICFS
TSCH [29]	An effective local channel selection approach for reliable communication scheduling in TSCH networks is proposed	Results demonstrate the efficiency of the proposal in terms of performance parameters
TSCH [30]	An overview of the most relevant decentralized TSCH schedulers is shown	Orchestra outperforms all other schedulers
TSCH [10]	Comparison between layered schedulers, 6TiSCH, and Orchestra	Relationship between TSCH and RPL is governed by queue size and schedule capacity
TSCH [21]	TESLA, a traffic-aware elastic slotframe adjustment scheme for TSCH networks, is proposed	Large-scale 110-node and 79-node evaluation shows 70.2% energy savings
TSCH [4]	Strategy to cope up with idle listening	There is not a single winning strategy, as the behavior depends on specific operating conditions of WSN
TSCH [11]	An Orchestra-based scheduler for applications with unpredictable traffic bursts is proposed	Lower latency and higher packet delivery ratio
TSCH [31]	Time hopping to secure the reliability of coexisting TSCH	50% improvement in collision ratio
TSCH [32]	Probabilistic blacklisting is proposed	Improved performance parameters
6TiSCH [33]	A traffic-aware RPL method that utilizes the cell allocation information of TSCH MAC	Packet delivery ratio and bandwidth utilization are improved by up to 31% and 20%
6TiSCH [34]	Low-latency Distributed Scheduling Function (LDSF) is proposed	Efficiency of the proposed LDSF algorithm is better than the Minimal Scheduling Function, Low-Latency Scheduling Function (LLSF), and Stratum
6TiSCH [12]	Thorough description of the 6TiSCH architecture, the 6TiSCH Operation Sublayer (6top), and MSF is provided	Allocating multiple cells over MSF could exacerbate the problem of over-provisioning
6TiSCH [35]	Outlines the challenges associated with implementing TSCH and 6TiSCH protocols in the Contiki operating system	Provides valuable insights into the design considerations and performance characteristics of TSCH and 6TiSCH protocols in Contiki
6TiSCH [36]	Traffic rate-agnostic distributed link scheduling function (RTDS) for 6TiSCH networks is proposed	RTDS follows a receiver-based cell selection and allocation strategy to reduce a packet’s waiting time in the receiving nodes
6TiSCH [37]	Optimized 6TiSCH scheduling function YSF is proposed	It produces a low end-to-end delay and high-end-to-end reliability

presents an overview of the existing work on TSCH and 6TiSCH.

More detailed information about the notations used throughout the paper is presented in

Table 2. Notations.

Symbols	Meaning
$ASN$	absolute time slot
$nfreq$	number of available radio channels
F	lookup table function
N	total number of time slots
$T_i$	transmission time of the i-th time slot
$\Delta$	duration of each time slot
$\lambda$	average arrival rate of packets
$T{S}_{node}$	time slot of a node
$T_{sec}$	application packet transmission interval
$d_{rate}$	application packets generated per unit time
$BFC$	Beacon Frame Cycle
$SFC$	Shared Frame Cycle
$UFI$	Unicast Frame Interval
$T_{BFC}$	duration of a single time slot for BFC
$T_{SFC}$	duration of a single time slot for SFC
$T_{UFI}$	duration of a single time slot for UFI
$f_{TSCH}$	frequency of time slot in TSCH network
$T_X$	packet transmission
$R_X$	packet reception
$ap{p}_{nl}$	number of lost packets
$ap{p}_{rx}$	number of received packets
$N_s$	total number of application packets sent
$RxTim{e}_i$	reception time of the i-th packet
$TxTim{e}_i$	transmission time of the i-th packet
$I_{\mathrm{total}}$	total current consumption
$P_{\mathrm{total}}$	total power consumption
V	voltage level of the network
$P_{\mathrm{Tx}}$	power consumption during transmission
$P_{\mathrm{Rx}}$	power consumption during reception
$P_{\mathrm{CPU}}$	power consumption of the CPU
$P_{\mathrm{LP}}$	power consumption during low-power mode
d	distance
R	data rate
F	channel condition
$ma{c}_{acked}$	MAC layer packets acknowledged
$ma{c}_{tx}$	MAC layer packets sent
$P_{collision}$	probability of unicast collision
C	number of available channels for communication
U	number of unicast transmissions attempted simultaneously
N	number of packet transmissions
$P_{collision}$	probability of a broadcast collision
p	probability of a node transmitting a broadcast message

.

3. Methodology

The main objective of this study is to develop a traffic-aware autonomous scheduling function adaptable to different traffic demands and network conditions, considering maximum reliability, minimum latency, minimal current consumption, and reduced collision as the optimization parameters. To achieve this goal, we propose an optimized channel selection and cell allocation scheduling mechanism that can dynamically adjust to varying traffic loads and network states, continuously optimizing the performance metrics in real time. The proposed OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 were designed by considering various factors, such as the packet transmission requirements of nodes, utilization of physical communication channels, slotframe size, traffic types, and the state of the network. Furthermore, to enhance the path and optimal configuration selection in smart home scenarios, we utilized our previously proposed approach, MSHOP [3]. Notably, existing application approaches, including our previously published MSHOP, require a dedicated scheduling approach, which is provided in the proposed work. The methodology of the proposed approach is described in the following subsection.

3.1. Architecture Selection

The architecture in [3] for MSH and MSHOP addresses the challenges of increasing network complexity and device mobility in smart home environments. In the MSH architecture, TTPs serve as intermediaries between clusters of smart devices and the sink node, facilitating efficient data transfer and reducing connectivity issues, especially in multi-story homes where direct connections may be impractical. The MSHOP algorithm optimizes data routing by dynamically adjusting transmission and interference ranges based on network topology, ensuring reliable communication even in large-scale deployments with heterogeneous hardware and software. By leveraging TTPs and efficient routing algorithms where an event timer is incorporated, the proposed architecture enhances network performance, current consumption, and reliability, particularly in mobile smart device scenarios, thereby addressing critical challenges in smart home environments.

3.2. Scheduling Approach

The growth of IoT in smart homes, cities, and agriculture demands reliable communication with low power consumption. In these networks, devices aim for short active periods (low-duty cycle) to save energy [27]. The MAC layer controls device access to avoid collisions, balancing reliability and latency. While protocols exist for contention-based and contention-free communication, collisions can still occur. The IEEE 802.15.4-2015 standard introduced TSCH specifically for industrial wireless sensor networks to address this issue [38].

TSCH divides time into distinct time slots. These time slots are lengthy enough to allow for both the transmission of a packet and the receipt of acknowledgment [8]. A slotframe is a sequence of time slots that repeats itself throughout time in a cyclic fashion. The number of time slots that make up a slotframe determines its length. TSCH forms a matrix-like schedule, allowing each time slot to utilize multiple available frequencies [24]. The pair $T{s}_{of}$ and $C{h}_{of}$ represents a particular cell in the slotframe, where $T{s}_{of}$ denotes the time slot position in the slotframe, and $C{h}_{of}$ refers to an integer value in the interval [0–15] that can be mapped to a real channel at each slotframe repetition. Moreover, TSCH offers a slow channel-hopping method to increase dependability when outside interference exists. A node derives the actual frequency to use at the beginning of the time slot to support slow channel hopping with the help of Equation (1):

$$Radiochannel=F\left[\right(ASN+channeloffset)\%nfreq].$$

(1)

Adopting a traffic-aware scheduling algorithm in industrial LLN is worthwhile, as it addresses application needs and enhances network performance. The traffic model, network topology, density, routing topology, and forwarding principle are the most critical factors contributing to traffic-aware scheduling. Different scheduling approaches, such as centralized, distributed, and autonomous, have been proposed, and multiple gaps have been found as an area of scope. Proactive cell collision and avoidance, practical channel estimation and selection, lack of adaptive autonomous scheduling functions, traffic differentiation, mobility support, proactive scheduling, and influence of routing on the schedule are a few of the open issues observed [6].

In the current work, we focus on all the issues mentioned above and propose a solution in the form of the OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 scheduling functions. Initially, we compare the existing state-of-the-art scheduling functions in the previously proposed MSHOP topology. We optimize the scheduling functions while analyzing the differences between their performance parameters and find the best among them. Later, the best scheduler is implemented in a large-density network to prove its efficiency. The entire process of this work can be seen in Figure 1.

3.3. Scheduler Selection

Scheduling in a communication network involves the organization and management of data transmission activities among connected devices within a network. It determines when and how data packets are sent and received, aiming to optimize network performance, resource utilization, current consumption, network scalability, collision avoidance, and quality of service. We consider autonomous scheduling for the current work, as this is one of the research scopes we find in low-power networks.

• Orchestra

The field of autonomous scheduling in time-slotted channel hopping protocols was inaugurated with the release of Orchestra by Duquennoy et al. in 2015 [14]. Orchestra introduces various operational modes, namely receiver-based (RB) and sender-based (SB). In RB mode, unicast cell scheduling relies on routing information, whereas in SB mode, each node utilizes its time slot for packet transmission. The scheduler dynamically adjusts transmission and reception cells in response to changes in routing information provided by the Routing Protocol for Low-Power and Lossy Networks (RPL). Leveraging RPL structures, Orchestra identifies neighboring and parent nodes [25]. It autonomously assigns cells to individual nodes through a hash function that processes either the node’s MAC address or the MAC address of a neighboring node. It also includes slotframes for control packets and uses a node-based channel allocation approach for better performance [17]. Multiple extended Orchestra versions perform better than the original version.

• 6TiSCH Minimal Scheduling Function

The IETF Working Group has established 6TiSCH as a protocol stack for operating IPv6 over IEEE 802.15.4-TSCH [12]. Within this framework, the 6TiSCH Working Group has standardized the 6TiSCH Minimal Scheduling Function (MSF) as a scheduling mechanism for 6TiSCH networks. MSF governs both the behavior of nodes during network entry and the management of communication schedules in a distributed manner. It utilizes autonomous and negotiated cells, allocates one Rx cell for each node, and dynamically adjusts the number of Tx cells based on traffic demand. A tie-breaking mechanism selects the cell with the highest packet count for transmission in scenarios where multiple Tx cells are scheduled in the same time slot. While the MSF is anticipated to deliver comparable performance to the Orchestra Receiver Non-Storing approach with node-based channel offset allocation, differences may exist in the hash function [36]. The process of selecting the best scheduler suitable for the proposed network topology MSHOP is represented with the help of Figure 1.

• OPTIMAOrchestra _ch4 and OPTIMAOrchestra _ch11 Design

Various traffic-aware schedulers have been proposed over time to improve communication network efficiency. However, several gaps exist in these approaches, which motivate the scope of this research. A detailed taxonomy of traffic-aware scheduling, as presented in [6], highlights the need for autonomous schedulers designed for large heterogeneous networks with star topology and nodes exhibiting mobility. These schedulers should also consider periodic traffic models, as limited experimentation has been conducted in these areas. Figure 2 illustrates the taxonomy this research considers for traffic-aware scheduling.

• Slotframe Structure

• Beacon Frame Cycle: This is the slotframe size used for the time-synchronized EB communication. It is responsible for scheduling a single cell for Enhanced Beacon packet transmission and a single cell for EB packet reception from the time source node.
• Shared Frame Cycle: This rule is used for broadcast and unicast traffic. A slot is common for all nodes in the network for broadcast plus unicast for RPL signaling (DIO, DIS, DAO), repeating after certain slots.
• Unicast Frame Interval: This is the slotframe size used for the unicast slots for every node to its RPL preferred parent. This rule allocates slots for unicast packets, including a single cell for the node itself, a single cell to the parent, and a single cell for each neighbor with a direct route installed.
• Application Packet Transmission Interval: This refers to the time interval or duration between consecutive application (APP) packets sent by a node in a wireless network.

• Size Adoption

The slotframe size is crucial in traffic-aware scheduling, especially in managing traffic load within dense networks. The probability of collisions is directly related to the size of the frame [16]. The selection of slotframe sizes is critical and based on optimizing network performance. By default, the Beacon Frame Cycle, Shared Frame Cycle, Unicast Frame Interval, and Application Packet Transmission Interval are set to 397, 31, 17, and 60 s, respectively. However, with the proposed OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11, the slotframe sizes are adjusted to 201, 11, 5, and 200 s. This has been derived based on fine-tuning the parameters for optimal performance. Occasionally, collisions occur between the commonly shared slotframe and TSCH-enhanced beacon slotframes. Nonetheless, with the optimized slotframe sizes for both slotframes, the collision rate is nearly 0% in broadcast communication and less than 5% in unicast communication, even within networks comprising 111 nodes. Furthermore, the interval between packet generations significantly contributes to collision reduction.

In the considered multi-hop networks, cluster nodes transmit their packets to the TTP, which forwards them to the server, serving as a middle framework. The network topology, ranging from 11 to 111 nodes, employs optimized slotframes for packet forwarding. The determination of slotframes is guided by Equations (2)–(7).

$$\mathrm{Slotframe}\mathrm{Size}=\sum _{i=1}^N{\displaystyle \frac{T_i}{\Delta t}}$$

(2)

$$\mathrm{Collision}\mathrm{Probability}=1-e^{-\lambda T{S}_{node}}$$

(3)

$$T_{\sec }={\displaystyle \frac{1}{d_{\mathrm{rate}}}}$$

(4)

$$\mathrm{BFC}=T_{\mathrm{BFC}}\times f_{\mathrm{TSCH}}$$

(5)

$$\mathrm{SFC}=T_{\mathrm{SFC}}\times f_{\mathrm{TSCH}}$$

(6)

$$\mathrm{UFI}=T_{\mathrm{UFI}}\times f_{\mathrm{TSCH}}$$

(7)

• Hopping Sequence

TSCH utilizes 16 radio channels [8,29]. This multi-channel setup [39] enables nodes to dynamically switch between channels, offering enhanced reliability by mitigating the effects of multi-path fading and external interference [40]. Equation (1) dictates the computation of the physical radio channel to be utilized during each time slot. By default, OPTIMAOrchestra_ch4 employs a hopping sequence of 4 channels. However, to address issues related to collisions in both transmission (Tx) and reception (Rx) packet slots, the channel hopping sequence has been optimized to 11 channels.

In the context of OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11, opting for prime numbers as frame cycle sizes and hopping sequences is a pivotal strategy to bolster the efficiency of communication networks. Firstly, incorporating prime numbers for the size of repetitive slotframes shows a notable enhancement in frequency diversity. This diversity allows Tx and Rx slots with different ASN values to utilize distinct channels when the slotframe size is a prime number. For instance, with a slotframe size of 3 and multiple available channels, leveraging prime numbers ensures that Rx slots span various channels based on ASN values, optimizing spectrum utilization. Secondly, by leveraging prime numbers for the lengths of different slotframes, including those in OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11, network nodes can curtail the overlap of active slots, leading to reduced unintended synchronization effects. This approach fosters more stable and reliable communication within the network by ensuring that active slots rarely and evenly overlap. Therefore, integrating prime numbers for frame cycle sizes in OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 is integral to optimizing network performance and minimizing interference.

Algorithm 1 describes the key components of the proposed scheduling mechanism to help understand the implementation and operational flow. It begins by initializing the simulation parameters, including the number of nodes, slotframe sizes, and channel configurations. The network is then set up by assigning channels and slotframe sizes to each node. Various scheduling functions have been defined to manage beacon frames, shared frames, unicast frames, and application packet intervals. The algorithm also includes steps for optimizing slotframe sizes, calculating collision probabilities, and computing hopping sequences. Finally, the simulation is executed over the defined duration and number of runs, with all functions working together to simulate and optimize the network performance. The accompanying flow diagram visually represents these steps, thereby enhancing the understanding of the operational flow.

Algorithm 1 Orchestra Operational Flow

1: BEGIN   2: SET Simulation duration, number of runs, number of nodes   3: SET SLOTFRAME_SIZES [201, 11, 5, 200]   4: SET CHANNELS_CH4 to 4   5: SET CHANNELS_CH11 to 11   6: FUNCTION Initialize_Network(nodes, channels, slotframe_sizes)   7:    FOR each topology in communication DO   8:       ASSIGN node channels   9:       ASSIGN node slotframe_sizes 10:    END FOR 11: END FUNCTION 12: FUNCTION Schedule_Beacon_Frame_Size(node) 13:    SET BFC_slot = GET_SLOT(BFC_SLOT_SIZE) 14:    ASSIGN BFC_slot to node for Enhanced Beacon transmission 15:    ASSIGN BFC_slot to node for EB packet reception 16: END FUNCTION 17: FUNCTION Schedule_Shared_Frame_Size(node) 18:    SET SFC_slot = GET_SLOT(SFC_SLOT_SIZE) 19:    ASSIGN SFC_slot to node for broadcast and unicast traffic 20: END FUNCTION 21: FUNCTION Schedule_Unicast_Frame_Size(node, parent_node) 22:    SET UFI_slot = GET_SLOT(UFI_SLOT_SIZE) 23:    ASSIGN UFI_slot to node for unicast packets to parent 24:    ASSIGN UFI_slot to parent_node for unicast packets from node 25:    ASSIGN UFI_slot to neighbors with direct routes 26: END FUNCTION 27: FUNCTION Schedule_Application_Packet_Interval(node) 28:    SET APP_interval = APP_PACKET_INTERVAL 29:    SCHEDULE packet transmission at intervals of APP_interval 30: END FUNCTION 31: FUNCTION Optimize_Slotframe_Sizes() 32:    ADJUST Beacon Frame Cycle to 201 s 33:    ADJUST Shared Frame Cycle to 11 s 34:    ADJUST Unicast Frame Interval to 5 s 35:    ADJUST Application Packet Transmission Interval to 200 s 36: END FUNCTION 37: FUNCTION Calculate_Collision_Probability(nodes) 38:    FOR each node in nodes DO 39:    COMPUTE collision probability using Formula (3) Equation (3) 40:    END FOR 41: END FUNCTION 42: FUNCTION Compute_Hopping_Sequence(nodes, channels) 43:    FOR each node in nodes DO 44:       COMPUTE hopping sequence using prime numbers and channels 45:    END FOR 46: END FUNCTION 47: FUNCTION Run_Simulation(nodes, duration, runs) 48:    FOR run in 1 to runs DO 49:    FOR time_step in 1 to duration DO 50:       PERFORM Initialize_Network(nodes, channels, slotframe_sizes) 51:       FOR each node in nodes DO 52:    Schedule_Beacon_Frame_Cycle(node) 53:    Schedule_Shared_Frame_Cycle(node) 54:    Schedule_Unicast_Frame_Interval(node, node.parent) 55:    Schedule_Application_Packet_Transmission(node) 56:    END FOR 57:    Calculate_Collision_Probability(nodes) 58:    Compute_Hopping_Sequence(nodes, channels) 59:    END FOR 60:    END FOR 61: END FUNCTION 62: // Main Execution 63: SET nodes to range from 11 to 111 64: SET duration to 3600 s 65: SET runs to 10 66: CALL Optimize_Slotframe_Sizes() 67: CALL Run_Simulation(nodes, duration, runs) Simulation duration, number of runs, number of nodes 68: END

3.4. Scheduling, Slotting, and Hopping Utilized

This section provides a comprehensive overview of the topological configuration of MSHOP and its clusters comprising 10 nodes each, along with the associated slotting and channel hopping mechanisms. Figure 3a depicts an MSHOP topology featuring 3 clusters, with each cluster comprising 10 client nodes. Nodes 2, 3, and 4 within each cluster function as TTPs, while node 1 serves as the central server responsible for receiving packets forwarded by the respective TTPs from their clusters. Conversely, Figure 3b portrays a dense network configuration, which consists of 111 nodes. In this setup, packet losses occurred in clusters 3, 6, 8, and 11 when employing the Orchestra scheduler with default parameters. There is a heterogeneous topology, T3 shown in Figure 3c, where the number of nodes per cluster is uneven. The T3 topology configuration can be seen in the heterogeneous topology configuration table. Different types of static topologies are shown in Figure 3, where the server node is green, TTPs are yellow, and the remaining nodes are the client nodes.

Following the radio channel allocation rule described in Equation (1), the transmission or reception of packets for each node is determined. Figure 4 depicts a more detailed channel allocation for MSHOP using OPTIMAOrchestra_ch4 as the scheduler. For instance, under ASN 359012, node 2 transmits a packet on channel 15 due to its channel offset 0, resulting in F[4]. In the lookup table [13], index 4 corresponds to radio channel 15. Similarly, channels are assigned for transmission or reception for every other node. Due to limited channel availability, two possibilities arise: fewer nodes are involved in transmission and reception, or collisions occur if all nodes are involved. Despite the reduced collision rate with OPTIMAOrchestra_ch4, some nodes may still experience congestion. Furthermore, OPTIMAOrchestra_ch11 with an 11-hop sequence is introduced for MSHOP, illustrated in Figure 5, demonstrating minimal collisions and maximum participation of each node in communication.

3.5. Enabling the Mobility Parameter

In industrial networks, deployments typically involve static nodes with little consideration for mobility. However, mobility is increasingly significant for many applications. Dynamic topologies pose challenges, as mobile devices introduce frequent topology changes, leading to quickly suboptimal and inefficient schedules [6]. It is crucial for mobile devices to swiftly discover coordinators to obtain the list of scheduled cells and avoid collisions. Before exchanging packets with neighbors, a mobile device must join the network promptly [16]. Establishing schedules for mobile networks has garnered attention because existing mobile networks often only address simplistic scenarios without actual requirements like delay or delivery. Mobility in TSCH networks remains an aspect that is yet to be extensively explored. Designing a schedule to support mobility in autonomous approaches is complex, mainly as RPL topology frequently changes [9].

Considering the challenges posed by mobile nodes in a network, we introduce a multi-hop topology known as MSHOP, initially designed for 3 clusters of 10 nodes each. This architecture includes one TTP in every cluster of 10 nodes, which is responsible for forwarding packets to the server. It is scalable for growing topologies of up to 10 clusters with 10 nodes each. Mobile devices connect to one of these TTPs or edge routers to exchange traffic. While waiting for enhanced beacon reception, mobile nodes leverage channel hopping to probe different channels at different intervals to discover existing nodes, thereby reducing discovery delay. The attachment point of a mobile node also depends on its speed before receiving a response. Optimized slotframes for multiple cycles further reduce collisions among packets sent from multiple mobile nodes within a particular cluster, owing to the availability of various TTPs. Each cluster in the proposed network topology contains six mobile nodes continuously moving for 3600 s, pausing and changing position every 10 s. These mobile nodes have a speed of 0.1 m/s, allowing them to move within a range of 300 m on both the x-axis and y-axis. The pictorial representation of these mobile nodes in Figure 6a illustrates their movement, with nodes from the second cluster gradually approaching the TTP in cluster 11, and with some nodes moving closer to the TTP in cluster 4 from the TTP in cluster 5. Similar instances of movement occur multiple times throughout the simulation. The green nodes represent server, yellow nodes are the aTTPs and the uncolored nodes are the client nodes. A reception of packet is represented with a red arrow and transmission with a blue arrow.

In Figure 6b,c, two network topologies are considered for communication. Figure 6b has 500 client nodes distributed across 50 clusters, whereas there are 1000 client nodes represented in Figure 6c. The green node is the server, whereas the yellow nodes are the TTPs, and the remaining nodes are clients.

Algorithm 2 provides an overview of the model adopted in this proposed work. The Mobility Model Algorithm updates the positions of nodes in a network based on their defined mobility model. It periodically checks the elapsed time and updates the node positions if the current period has changed. Depending on the node’s mobility model (“Line” or “RandomWaypoint”), it calls the appropriate function (update_position_line or update_position_rw) to update the node’s position.

Algorithm 2 Mobility Model Algorithm

1: Input:   2: Network object   3: Configuration file   4: Output:   5: Updates node positions based on mobility model   6: //Network Constructor   7: constructor   8:    this.network ← network   9:    this.current_period_num ← null 10: end constructor 11: // Main update function 12: function update_positions() 13:    period_num ← Math.trunc(time.timeline.seconds/config.MOBILITY_UPDATE_PERIOD_SEC) 14:    if this.current_period_num ≠ period_num then 15:       this.current_period_num ← period_num 16:       for each node in network.nodes do 17:          if node.config.MOBILITY_MODEL = “Line” then 18:             update_position_line(node, time.timeline.seconds) 19:          else if node.config.MOBILITY_MODEL = “RandomWaypoint” then 20:             update_position_rw(node, time.timeline.seconds) 21:          end if 22:       end for 23:    end if 24: end function

4. Performance Evaluation

4.1. Simulation Setup

The details of the experimental setup, including configurations, network topologies, traffic conditions, node density, and mobility patterns under which the performance evaluations are conducted are presented in

Table 3. Experimental settings.

Parameter	Value
Simulation tool	TSCH-Sim
Simulation runs	10
Simulation duration	1 h
Scheduling algorithms	Orchestra, MSF
Number of channels	4, 11
Max packet retransmissions	7
Max queue size	16 packets
TSCH slot duration	10,000 $\mathsf{\mu }$s
MAC keep alive timeout	60 s
MAC EB period	16 s
Routing protocol	RPL
Application packet size	100
App. packet generation interval	10, 40, 50, 60, 150, 200, 300 s
Warm-up period duration	100 s
Number of nodes	11, 21, 34, 45, 56, 64, 66, 67, 69, 75, 78, 80, 89, 100, 111, 551, 1111
Number of mobile nodes	6, 10
Positioning layout	ellipse/star
Beacon frame size	397, 200, 201
Shared frame size	31, 10, 11
Unicast frame size	17, 5
Mobility model	static, RandomWaypoint
Mobility update period	10 s
Mobility range x-axis	300 m
Mobility range y-axis	300 m
Mobility speed	0.1 m/s

. We compare the protocols in simulation [41] settings using TSCH-Sim. This work is an advancement of the work done in [3] and, as such, we use the MSHOP connectivity model. The nodes are connected to form clusters, creating cohesive units. The topologies are divided into the basic smart home (BSH) with 10 client nodes, an average smart home (ASH) with 20 client nodes, and an advanced smart home (AdSH) with 30 client nodes.

In the AdSH, the connectivity approaches vary from standard to MSH and MSH to MSHOP. Node 1 acts as both a root and the network’s traffic sink. The networks are operating with the help of Orchestra and MSF schedulers. The Orchestra scheduler manages several slotframes at every node, each of which is assigned to a particular traffic plane, and the MSF consists of a single-slotframe with a common shared slot. The RPL protocol is used for routing. We run the simulations for the different network topologies in static and mobile environments, the results of which are presented in Section 4.

4.2. Metrics

The following metrics are considered for evaluation of the proposed approaches:

• Reliability, in terms of packet delivery ratio, computed as:

  $$PDR(\%)=100.0\times \left(1-{\displaystyle \frac{ap{p}_{nl}}{ap{p}_{nl}+ap{p}_{rx}}}\right).$$

  (8)
• Latency, as the time between a packet being transmitted from the sender and being successfully received by the destination node:

  $$\mathrm{Latency}={\displaystyle \frac{1}{N_s}}\sum _{i=1}^{N_s}({\mathrm{RxTime}}_i-{\mathrm{TxTime}}_i).$$

  (9)
• Current consumption, defined as the average current consumed by the average non-root node’s network stack, and computed as the time-weighted sum of current consumed by the CPU activity, radio receptions and transmissions, and low-power modes:

  $$I_{\mathrm{total}}={\displaystyle \frac{P_{\mathrm{total}}}{V}},$$

  (10)

  $$P_{\mathrm{total}}=P_{\mathrm{Tx}}+P_{\mathrm{Rx}}+P_{\mathrm{CPU}}+P_{\mathrm{LP}}+f(d,R,F).$$

  (11)
• Packet collision probability, computed as the probability that two or more packets will be transmitted in the same time slot and same channel in an overlapping radio range.

4.3. Scheduler Showdown: Performance in Smart Networks

The main objective of this section is to take several common approaches to scheduling TSCH networks, specifically Orchestra and MSF, and find out which is the best for our target application along the dimensions of reliability, latency, and current consumption.

4.3.1. Reliability

The packet delivery ratio (PDR) provides insights into the successful delivery of the transmitted application packets and their intended recipients, as shown in Equation (8). The concept behind PDR is relatively straightforward: it represents the proportion of sent application packets received correctly by their intended destination nodes. This metric is expressed as a percentage and helps to understand the effectiveness of the communication protocol and network configuration.

• Static

We contrast the PDR with the previously proposed BSH configuration, considering the introduction of TSCH for communication facilitated by the Orchestra and MSF schedulers. Each protocol is evaluated at three different points, and this is illustrated in Figure 7a–c. Across all three topologies, employing Orchestra and MSF schedulers yields 100% reliability. Furthermore, there is a notable improvement in PDR, with a 60%, 40%, and 10% increase in BSH, ASH, and AdSH, respectively, when these schedulers are utilized.

• Mobile

As we know, mobility poses significant challenges in communication networks, leading to the potential loss of packets and a decline in packet delivery ratios as nodes move within the network. Our analysis maintains a scenario involving four static nodes and six mobile nodes in each cluster for every topology. In comparing our current work with previously studied protocols, Orchestra and MSF consistently demonstrate superior performance across all three topologies. Notably, basic smart home has a noteworthy increase in PDR ranging from a minimum of 50% to a maximum of 70%, as shown in Figure 8a. Similarly, Figure 8b shows the average smart home scenario with a substantial 50% improvement in PDR. In the case of the AdSH, MSHOP initially performed well, with a PDR of 99%. Following integration of the TSCH protocol, the PDR achieves a perfect score of 100%, as shown in Figure 8c. This observation indicates that both Orchestra and MSF exhibit comparable and commendable performance.

4.3.2. Latency

Latency shows the time between a packet being transmitted from the sender and being successfully received by the destination node, as represented in Equation (9). As it directly affects the responsiveness and effectiveness of communication networks, latency is an important statistic.

• Static

Without slotting, the values at three different points for BSH, ASH, AdSH, MSH, and MSHOP depend on the Tx and Rx range. The latency tends to decrease with a more extensive range. With the introduction of Orchestra, these three values are influenced by the default Orchestra settings, the reduction in Beacon Frame and Shared Frame Cycles, and the optimized prime values for Beacon Frame, Shared Frame, Unicast Frame, and the variable application packet intervals. Simultaneously, with the introduction of MSF, the three values at different points vary based on the modifications in slotframes, specifically 7, 5, and 14, respectively. Regardless of the network type, Orchestra consistently achieves the lowest latency, with a 200-s application packet interval. The latency ranges from a minimum of 0.073 s to a maximum of 0.35 s with the optimized frame cycles and reduced application packet interval in Orchestra. In comparison, MSHOP initially had a minimum latency of 0.9 s, but with the current optimization in the same topology, there is a remarkable 91.89% decrease in latency. MSF records a minimum latency of 0.11 s with a slotframe of 5. The comparative analysis of latency among the different topologies can be seen in Figure 9a–c.

• Mobile

Constant dynamism introduces a challenge, as the nodes require frequent routing path adjustments to align with the evolving connectivity. The inherent dynamic nature of these mobile nodes can give rise to intermittent interruptions in connectivity, resulting in latency as the network dynamically accommodates the nodes’ new locations. Maintaining consistently low latency becomes challenging in such a dynamic scenario. As shown in Figure 10a, in the BSH topology, the optimized Orchestra, operating with a 200 s packet interval, and MSF with slotframe 5 achieved a minimum latency of 0.02 s. In the ASH scenario, the optimized Orchestra resulted in a minimum latency of 0.04 s, as shown in Figure 10b. Similarly, Figure 10c illustrates that optimized Orchestra achieved a minimum latency of 0.02 s in the advanced smart home setup. For the more complex topology of MSHOP with 34 nodes and six mobile nodes, a latency of 0.9 s was observed. However, when the network had 12 mobile nodes distributed among four clusters, the latency was significantly reduced to a minimum of 0.02 s with the optimized Orchestra. This represents an impressive 97.78% decrease in latency with the optimized Orchestra configuration.

4.3.3. Current Consumption

The node’s activity and communication parts use the total electrical current throughout a given time frame. This measure is vital for comprehending the current consumption patterns of network nodes and is essential for assessing the network’s overall effectiveness. Equations (10) and (11) help find the current consumption.

• Static

Figure 11 presents a more detailed analysis of current consumption across different schedulers in various network topologies. Building on the previous observations regarding PDR and latency, it is evident that the Orchestra scheduler yields better results. Similarly, favorable outcomes are achieved for the MSF scheduler when the slotframe is set to 5. In the case of a basic smart home network, previous approaches resulted in a current consumption of 0.1 mA. However, with the integration of the Orchestra scheduler, current consumption increases to 0.6 mA, as depicted in Figure 11a. The previous approach recorded a minimum current consumption of 0.19 mA in an average smart home setting. At the same time, with the Orchestra and MSF schedulers, it reduces to 0.07 mA, as illustrated in Figure 11b. For the MSHOP scenario, the initial current consumption was 0.31 mA, but upon the implementation of schedulers, it rises to a maximum of 0.76 mA with Orchestra and 0.535 mA with MSF, as shown in Figure 11c. There is a marginal difference in current consumption upon introducing schedulers in the same topology proposed by MSHOP.

• Mobile

An analysis is conducted in a mobile environment to determine the scheduler that minimizes current consumption, as depicted in Figure 12. In the basic, average, and advanced smart home scenarios, the Orchestra scheduler demonstrates lower current consumption compared to MSF schedulers. Figure 12a illustrates a 5.5 mA difference in current consumption in a basic smart home network with and without a scheduler. Similarly, Figure 12b indicates a 6 mA difference in an average smart home network with the same number of client nodes, comparing scenarios with and without a scheduler. In the MSHOP scenario, a maximum current consumption of 0.31 mA is recorded, whereas with the Orchestra scheduler in the same topology, the maximum consumption increases to 6.25 mA. Despite the highly mobile nature of the topology, minimal differences in current consumption are observed.

4.4. Tuning the Score in Homogeneous Topologies: Precision in Orchestra Scheduling

We expand our investigation to encompass developing smart home configurations to delve deeper into their influence on communication within expanding topologies in industrial IoT. Figure 7, Figure 8, Figure 9, Figure 10, Figure 11 and Figure 12 illustrate three sets of values for each scheduler, focusing on Orchestra’s performance with the default Orchestra, OrchestraEBSFCSP, and OPTIMAOrchestra_ch4 configurations. While OPTIMAOrchestra_ch4 consistently delivers optimal outcomes across various smart home scenarios, we scrutinize its effectiveness in denser networks. These networks are homogeneous in nature, in which the number of nodes per cluster in a topology is equal. The analysis of collision rates in the evolving topology sheds light on the proposed scheduler’s efficiency. This section shows a comparative analysis between Orchestra, OPTIMAOrchestra_ch4, and OPTIMAOrchestra_ch11.

4.4.1. PDR, Latency, and Current Consumption

• Static

In a static environment employing default Orchestra, there is a decline in PDR as the number of nodes in the network increases. The PDR decreases to 83.97% in the densest network containing 111 nodes. Conversely, OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 achieve a 100% PDR in a network with 10 clusters and 10 nodes each, as shown in Figure 13a. Latency increases with the growing number of clusters, peaking at 0.393 s in the most congested scenario. OPTIMAOrchestra_ch11, utilizing 11 channels, achieves a minimal latency of 0.07 s, with a marginal 0.01 s difference compared to OPTIMAOrchestra_ch4, as illustrated in Figure 13b. Current consumption correlates with the number of communicating devices, optimized frame cycles, application packet generation intervals, and the physical channels utilized. Figure 13c shows that the minimum recorded current is 0.5 mA in a topology with 1 cluster and 10 nodes using default Orchestra, which decreases to 0.35 mA in a topology with 10 clusters and 10 nodes. While OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 ensure 100% reliability and minimal latency, they also exhibit lower current consumption. OPTIMAOrchestra_ch4 consumes 0.72 mA, while OPTIMAOrchestra_ch11 consumes 0.86 mA.

• Mobile

Mobility introduces signal interference, as moving nodes can obstruct or weaken radio signals. In dense networks with numerous nodes nearby, the probability of signal interference rises, impacting communication quality. Achieving 100% reliability and minimal latency with reduced current consumption is a significant challenge. Figure 14 presents a comparative analysis of performance parameters, including packet delivery ratio, latency, and current consumption, in a growing network topology. PDR consistently remains 100%, as depicted in Figure 14a across all 10 different topologies, regardless of the Orchestra scheduler used. We observe an increase in latency and current consumption with the growing number of nodes in the network when the default Orchestra scheduler is employed. However, with the utilization of the proposed Orchestra schedulers, latency decreases to 0.04 s with OPTIMAOrchestra_ch11. A difference of 0.07 s between OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 is evident, as illustrated in Figure 14b. As shown in Figure 14c, OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 exhibit a current consumption of 6.36 mA, higher than the default scheduler. The optimized parameters and enhanced hopping sequences contribute to the higher current consumption.

4.4.2. Collision

TSCH enables the creation of collision-free communication schedules by allocating dedicated cells so that only one node communicates with a specific neighbor in each channel offset cell. Multiple pairs of neighbors can exchange data simultaneously but on different frequencies. Our network topologies are based on the TSCH protocol, facilitating unicast and broadcast communication. In our previous work, collision rates were not depicted. Therefore, we also incorporate the routing protocol for low-power and lossy networks with its minimum rank with the hysteresis objective function to analyze collision rates for both types of communication. Figure 15 and Figure 16 present a comparative analysis between TSCH and RPL for collision rates across various network topologies, ranging from 1 cluster with 10 nodes to 10 clusters with 10 nodes in static and mobile networks, respectively. In this work, unicast and broadcast collisions are considered to analyze the effectiveness of the scheduler.

Unicast Collision: Unicast communication is a form of message transmission where information is sent from a single sender to a designated individual recipient. In networking, unicast communication operates point to point, with one sender communicating directly with one receiver. As depicted in Equation (12), collisions arise when multiple nodes try to transmit unicast messages concurrently over the same communication channel:

$$P_{\mathrm{collision}}=1-{\left(1-{\displaystyle \frac{1}{C}}\right)}^{U(N-1)}\ast 100.$$

(12)

Broadcast Collision: Broadcast communication involves sending data from one sender to all devices or nodes within a network segment or domain, following a one-to-all communication pattern in computer networking. A broadcast collision occurs when multiple devices attempt to transmit broadcast messages simultaneously on the same network segment, leading to packet overlap and corruption. Equation (13) illustrates the concept of broadcast collision:

$$P_{\mathrm{collision}}=1-{(1-p)}^{N-1}\ast 100.$$

(13)

• Static

In communication systems employing TSCH, the unicast collision rate experiences a noticeable rise from 8.54% to 27.97% as the network density escalates from 11 nodes to 111 nodes under the default Orchestra configuration. However, when OPTIMAOrchestra_ch4 is utilized as the scheduler for the topology with 111 nodes, the collision rate declines to 6.84%, as shown in Figure 15. Furthermore, OPTIMAOrchestra_ch11 achieves an even lower collision rate of 6.15% by leveraging 11 physical channels. The collision rate escalates in correspondence with the network density. Similarly, for TSCH broadcast communication, the collision rate increases with the number of nodes in the topology for the default Orchestra. Nevertheless, when the proposed schedulers are implemented, the optimized collision rates are recorded at 0.05% and 0.03%, respectively, for OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11, as represented in Figure 15 for the topology featuring 10 clusters and 10 nodes.

Even when RPL serves as the communication protocol, both unicast and broadcast collisions are mitigated with the assistance of the proposed schedulers. Attaining minimal collision rates in dense networks remains challenging, yet leveraging multiple physical channels and optimized frame cycles yields promising results in a topology comprising 111 nodes. OPTIMAOrchestra_ch11 results in a notable reduction, with the RPL unicast and broadcast collision rates reaching a minimum of 5.28% and 6%, respectively, as shown in Figure 15.

• Mobile

Collisions are often prevalent in mobile environments. Among TSCH unicast, TSCH broadcast, RPL unicast, and RPL broadcast communications, TSCH broadcast communication tends to have a lower collision rate. However, with the Orchestra scheduler, collisions are notably high across all types of communication. OPTIMAOrchestra_ch4 reduces the TSCH unicast collision rate from 13.25% to 9.45% in the 111-node network, which is further decreased to 0.2% with OPTIMAOrchestra_ch11. In TSCH broadcast communication, regardless of the scheduler used, collisions are nil in mobile environments. For RPL unicast communication, a minimum collision rate of 6.6% is observed, while for broadcast communication, the minimum collision rate is 0.44%, both achieved with the assistance of OPTIMAOrchestra_ch11. Figure 16 illustrates that OPTIMAOrchestra_ch11 achieves minimal collision rates across all topologies with the help of an 11-channel hopping sequence.

4.5. Effects of Different Application Packet Intervals

Thus far, the packet generation interval has been consistent. OPTIMAOrchestra_ch4 and ch11 perform best when the application packet generation interval is 200 s; however, the Orchestra scheduler’s default setup takes 60 s into account. When one considers an actual Internet of Things application, transmission frequency requirements vary depending on the type of device and data. In dynamic situations, shorter intervals might be required to accurately record quick changes, whereas in stable contexts, less frequent updates are possible. We have created both homogeneous and heterogeneous topologies while maintaining the significance of changing packet intervals to demonstrate their usefulness and performance.

4.5.1. Homogeneous Topologies

The performance of homogeneous topologies with increasing network size is examined and contrasted in this section. We have devised a configuration with TTPs involving an approximate packet generation interval of 10 s, taking into account the densest network consisting of 10 clusters and 10 nodes. The first cluster’s three leaf nodes are allotted 50 s, while the following seven are given 200 s. Three nodes in the second cluster are allotted 50 s, while the remaining seven are given 150. The third cluster’s initial two nodes have an approximate packet interval of 40 s, whereas the other nodes in the network have an interval of 200 s.

Figure 17 illustrates the performance of a homogeneous topology with 10 clusters and 10 nodes, comparing the effects of similar and different application packet intervals in static and mobile environments. There are six mobile nodes in each cluster of the topology. In a static environment, using the Orchestra scheduler, the PDR is lower for varying packet intervals compared to similar intervals. However, in mobile environments, the PDR is consistently 100% regardless of packet interval variation. With the OPTIMAOrchestra_ch4 scheduler, the PDR in static networks with different packet intervals is 0.04% lower than with similar intervals, while in mobile environments, the PDR remains 100%. Moreover, when OPTIMAOrchestra_ch11 is used as the scheduler, there is no packet loss in either static or mobile environments, regardless of whether the packet intervals are the same or different. In a mobile environment, latency is always lower than in a static one. When using Orchestra, packets with differing application packet intervals rather than similar ones have a greater delay in packet delivery. While the latency in mobile is the same, in OPTIMAOrchestra_ch4 and ch11, it differs by 0.01 for varying and similar application packet intervals in static environments. In a static environment, current consumption is always lower than in a mobile one. As seen in Figure 17, with varying packet intervals, the current consumption is less than that of the same interval in Orchestra, but it is the same in OPTIMAOrchestra.

Figure 18 demonstrates that the use of OPTIMAOrchestra significantly reduces collision rates compared to the standard Orchestra scheduler. Analysis shows that, for all four types of collisions, the rates are lower when OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 are used. Notably, collision rates with varying application packet intervals are consistently lower than those with uniform intervals. In TSCH unicast and broadcast communications, collision rates are lower in mobile environments compared to static ones. Conversely, RPL unicast collisions are lower in static environments, while RPL broadcast collisions are lower in mobile environments. The collision rates for TSCH and RPL broadcasts are nearly zero, with the lowest recorded values being 4.69 for TSCH unicast and 5.28 for RPL unicast collisions.

4.5.2. Heterogeneous Topologies

In contemporary IoT deployments, smart homes, smart cities, and workplace contexts, where a diverse array of devices and technologies must effectively cohabit and interact, heterogeneous networks are ubiquitous. We set up five distinct heterogeneous topologies, each with a different number of nodes per cluster, in order to demonstrate the usefulness of heterogeneous networks. The improvements are made to create heterogeneous networks in the densest network, which consists of 10 clusters of 10 nodes. The number of nodes in each cluster in the topology is displayed in

Table 4. Heterogeneous topology configuration.

No. of Clusters	Topology Name	Nodes per Cluster
		CL_1	CL_2	CL_3	CL_4	CL_5	CL_6	CL_7	CL_8	CL_9	CL_10
10	T1	0	0	0	6	8	8	7	9	10	10
10	T2	0	2	4	6	8	8	7	9	10	10
10	T3	0	8	0	4	2	3	7	9	10	10
10	T4	10	10	5	5	5	5	5	8	8	8
10	T5	10	8	9	7	6	5	4	3	2	1

.

All heterogeneous networks operate with the same application packet interval for all nodes within the clusters. These configurations are then compared to the same networks using different application packet intervals in both static and mobile environments.

• Static

In a static environment, heterogeneous networks demonstrate improved performance with uniform packet intervals across all nodes within a cluster, compared to varying intervals. The Orchestra scheduler achieves higher PDR in networks with consistent application packet intervals than in those with differing intervals. However, when the proposed OPTIMAOrchestra is used, the PDR remains at 100% for all configurations, as illustrated in Figure 19. Latency is lower in networks with uniform packet intervals using the Orchestra scheduler, but with the OPTIMAOrchestra, latency is less in networks with varying application packet intervals, with a minimum record of 0.06 s. The total number of nodes in configurations T1 to T5 are 69, 75, 64, 80, and 66, respectively, indicating that networks with fewer nodes exhibit lower latency and reduced current consumption. Figure 19 also shows that current consumption increases with OPTIMAOrchestra_ch4 and ch11, with networks using uniform application intervals consuming less power than those with varying intervals.

Higher TSCH and RPL collision values in Orchestra with varying application intervals indicate enhanced network costs and usage. Particularly in networks with variable application packet intervals, OPTIMAOrchestra setups typically perform better with lower utilization, suggesting more effective network functioning with less control traffic, as shown in Figure 20. Outliers are data points that differ significantly from the rest of the data; these are indicated by the circle markers in the graphs. They show unpredictability and extraordinary cases that are outside the whiskers’ typical range of data. In terms of TSCH broadcast count, it is nearly nil.

• Mobile

In this environment, the number of mobile nodes per cluster is typically six. However, in a heterogeneous topology, the number of nodes can range from 0 to 10, as shown in Table 4. Consequently, the number of mobile nodes may be fewer than six if the cluster does not have a total of six client nodes. All configurations maintain high PDR of 100%, with OPTIMAOrchestra variants ensuring perfect packet delivery in all scenarios. OPTIMAOrchestra configurations significantly reduce latency compared to Orchestra, especially with same application packet intervals, with a value of 0.02 s. Orchestra tends to consume less current with similar application intervals, while OPTIMAOrchestra configurations consume slightly more current but offer better latency and PDR, as shown in Figure 21.

In terms of TSCH unicast collisions, the OPTIMAOrchestra configurations generally exhibit lower utilization counts compared to Orchestra, indicating more efficient usage of the TSCH protocol. No TSCH broadcast collisions are observed across all configurations and scenarios, highlighting the absence of control traffic issues. Regarding RPL unicast collisions, Orchestra shows higher utilization counts, particularly in the different application scenarios, suggesting greater overhead. The OPTIMAOrchestra configurations demonstrate lower and more stable counts. Moreover, Orchestra experiences higher RPL broadcast collisions, especially in the same application scenarios. The OPTIMAOrchestra configurations consistently show lower counts, indicating more efficient routing, particularly under varying application packet intervals. Figure 22 provides a comparative analysis of different types of collisions in mobile environments.

Finally, the homogeneous topology consisting of 10 clusters with 10 nodes is analyzed, where all nodes are mobile and share the same application packet interval, while the server remains static. Utilizing the best proposed scheduling function, OPTIMAOrchestra_ch11, a PDR of 100%, latency of 0.078 s, and current consumption of 0.98 mA are recorded. The TSCH unicast and broadcast collision rates are 0.96 and 0.02. Similarly, the RPL unicast and broadcast collision rates are 5.30 and 7.08, respectively.

4.6. Effect of OPTIMAOrchestra in Complex Environments

To evaluate the proposed scheduler’s performance in larger and more complex network environments, a more detailed experiment is conducted in high-interference conditions with large-scale, node-dense deployments. The results are presented in

Table 5. Comparative analysis of topologies with 500 and 1000 client nodes.

Topology	Scheduler	PDR (%)	Latency (s)	Current (mA)	TSCH_UC (%)	TSCH_BC (%)	RPL_UC (%)	RPL_BC (%)
50_10	Orchestra	40.22	1.018	1876.7	31.10	1.98	46.58	34.57
50_10	OPTIMAOrchestra_ch4	78.27	0.257	1839	31.01	1.70	37.82	18.00
50_10	OPTIMAOrchestra_ch11	88.93	0.190	2398.2	22.75	0.49	27.68	13.10
100_10	Orchestra	21.48	2.568	4389.1	38.00	1.51	42.27	34.00
100_10	OPTIMAOrchestra_ch4	23.08	0.607	3426.6	32.47	3.60	41.87	31.44
100_10	OPTIMAOrchestra_ch11	42.15	0.194	5156.2	25.70	1.48	38.14	28.16

. A topology with 50 clusters, each containing 10 nodes (totaling 500 client nodes), is simulated for 5 min, as illustrated in Figure 6b. The results show an increase in PDR from 40.22% to 88.93% when comparing Orchestra against OPTIMAOrchestra using 11 channels. Furthermore, latency decreased from 1.018 s to 0.190 s. Similarly, a topology with 100 clusters, each containing 10 nodes (totaling 1000 client nodes and 101 additional nodes, for a total of 1101 nodes), is simulated for 5 min, as shown in Figure 6c. Despite the potential for significant interference, the PDR improved from 21.48% to 42.15% for Orchestra and OPTIMAOrchestra, respectively, with a latency reduction from 2.568 s to 0.194 s. A substantial decrease in collision rates is also observed. However, these performance gains were accompanied by enhanced current consumption, highlighting a trade-off that must be considered in battery-operated IIoT environments. To mitigate this, adaptive channel usage could be implemented to balance performance improvements with current consumption efficiency.

Lastly, a theoretical analysis is being done among Orchestra, OPTIMAOrchestra_ch4, and OPTIMAOrchestra_ch11 to analyze the optimized scheduling mechanism. The proposed schedulers OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 offer significant improvements in time complexity compared to the default Orchestra scheduler due to a reduction in the number of scheduling rules. The default Orchestra scheduler has a complexity of $O(D·R·(N^2+S_{Orc}·R_{Orc}))$, where D is the simulation duration, R is the number of simulation runs, N denotes the number of nodes in the topology, $S_{Orc}$ stands for the number of slotframe sizes, and $R_{Orc}$ is the number of rules used. Both OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 use only three rules, resulting in a time complexity of $O(D·R·(N^2+S_{Orc}·3))$. This simplification leads to more efficient scheduling, particularly in high-interference and large-scale, node-dense deployments, making them well-suited for the industrial Internet of Things.

5. Conclusions

TSCH has gained traction for its ability to support low-duty cycle solutions. However, several areas still require attention, particularly in dense communication networks. Our proposed solution, OPTIMAOrchestra, is an autonomous scheduling of TSCH in RPL networks that works in both static and mobile networks. Our comprehensive evaluation of the optimized scheduler has demonstrated remarkable improvements compared to previously proposed solutions. Specifically, it has shown a substantial 10% increase in packet delivery ratio, signifying its superior reliability in transmitting data across the network. Furthermore, it has achieved an impressive 97.78% decrease in latency, ensuring faster and more responsive communication. Moreover, it has exhibited an outstanding reduction in current consumption, emphasizing its energy-efficient design, which is paramount in resource-constrained networks.

In conclusion, the proposed approaches of OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 help in achieving 100% reliability and latency close to 0 s, with a minimum current consumption of 0.86 mA and a minimum of 0% TSCH broadcast collision rate in the most dense topology. The performance is consistently remarkable even in heterogeneous topology and in nodes with different application packet intervals. These results underscore the significant advancements brought by OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11, positioning them as a promising solution for enhancing the efficiency and performance of wireless networks. As topologies expand in size, there is a noticeable increase in current consumption, presenting an exciting opportunity for future optimization. Furthermore, collision analysis reveals a certain level of noise, which offers a valuable area for further refinement and enhancement. Deploying OPTIMAOrchestra in IIoT environments involves addressing several implementation complexities, including scalability, interference management, current consumption, real-time data requirements, security, mobility, and integration with existing systems. By carefully designing and optimizing the scheduling algorithm to address these challenges, it is possible to achieve a robust and efficient IIoT communication system.