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

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The paper makes a valuable contribution to the field of IoT network optimization by introducing and evaluating the OPTIMAOrchestra scheduler. The results are promising and demonstrate significant improvements over existing schedulers. Below are a few comments of mine:

1. The description of the mobility model algorithm and the scheduling approach could be made more concise and easier to follow. Make the algorithm descriptions more concise and easier to understand.

2. While the figures and tables are informative, most (if not all) of them are quite dense and not clear. Breaking down complex figures into smaller and/or improving their quality could enhance readability.

Comments on the Quality of English Language

Minor Editing

Author Response

[Reviewer #1, comment #1]

The description of the mobility model algorithm and the scheduling approach could be made more concise and easier to follow. Make the algorithm descriptions more concise and easier to understand.
[Author's Reply]

Thank you for your valuable feedback. We have revised the descriptions of the mobility model algorithm and the scheduling approach to be more concise and easier to follow, which is highlighted in yellow colour. To clarify the reference section, it is also added below.

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.        

 

[Reviewer #1, comment #2]

While the figures and tables are informative, most (if not all) of them are quite dense and not clear. Breaking down complex figures into smaller and/or improving their quality could enhance readability.
[Authors' reply]

The authors want to express deep gratitude for valuable comment for improving the quality of the figures. To address this concern, we have taken the following steps.

1. Breaking Down Complex Figures: We have split the more complex figures  into smaller, more focused subfigures, each highlighting specific aspects of the data. Folowing are the figures splited and highlighted.

1. Figure 15: “Collision in Static Evolving Network”
2. Figure 16: “Collision in Mobile Evolving Network”
3. Figure 18: “Collision Rate Comparison in Homogeneous Topology: Static vs. Mobile Environments with Varying Packet Intervals”
4. Figure 20: “Collision Rate Analysis in Static Heterogeneous Topologies: Effect of Variable Packet Intervals”
5. Figure 22 : “Collision Rate Analysis in Static Heterogeneous Topologies: Effect of Variable Packet Intervals”

2. Enhancing Quality: We have improved the resolution and clarity of all figures and tables. Additionally, we have adjusted the font sizes and labels to ensure they are legible and consistent throughout the manuscript.

Reviewer 2 Report

Comments and Suggestions for Authors The article titled Multi-Objective Optimization of Orchestra Scheduler for Traffic Aware Networks presents a new traffic-aware autonomous multi-objective scheduling function called OPTIMAOrchestra as an improvement for TSCH schedulers.   All the sections of this article are well-written, well-balanced, but need more effort to improve presentation and the references related to Current consumption metric.    The authors implemented their methodology, provided two versions of OPTIMAOrchestra, and gave answers to all research objectives.   In more detail, the authors describe the Current consumption metric in line 405 as a power consumption metric Ptotal. For Power, Watt is the unit of measurement. Later, in subsection 4.3.3. Current Consumption, the authors measure the current and provide figures in milliamperes, so I suggest replacing all this data with Power (in Watts), in order to present more clearly the power consumption (energy) and how they maintain a balanced latency-energy trade-off.   My minor comments refer to the low resolution/or stretched Figures 3,4,5,8. Also, in Figure 2 the Schedule specifications arrows to subblocks are confusing.    Finally, a formatting issue, metris Packet collision probability (line 410) does not use bold.  Comments on the Quality of English Language -

Author Response

 [Reviewer #2, comment #1]

In more detail, the authors describe the Current consumption metric in line 405 as a power consumption metric Ptotal. For Power, Watt is the unit of measurement. Later, in subsection 4.3.3. Current Consumption, the authors measure the current and provide figures in milliamperes, so I suggest replacing all this data with Power (in Watts), in order to present more clearly the power consumption (energy) and how they maintain a balanced latency-energy trade-off.
[Author's Reply]

Thank you for your insightful comment. The decision to use current consumption (measured in milliamperes) instead of power consumption (measured in watts) is based on the specific needs and focus of our study. The formula provided,

allows us to directly calculate the average current consumed by the network stack of a non-root node.

By focusing on current consumption, we consider the combined effects of power and voltage, which are critical for understanding the energy usage at the node level. This approach aligns with our objective of evaluating the time-weighted sum of current consumption to accurately represent the energy profile of the nodes. This metric provides a clearer understanding of how the network maintains a balanced latency-energy trade-off, which is central to our analysis.

[Reviewer #2, comment #2]

My minor comments refer to the low resolution/or stretched Figures 3,4,5,8. Also, in Figure 2 the Schedule specifications arrows to subblocks are confusing.    Finally, a formatting issue, metrics Packet collision probability (line 410) does not use bold.
[Authors' reply]

Thank you for your detailed review and for pointing out these issues. We appreciate your careful review and made the necessary corrections to address these issues and highlighted in yellow color.

1. Figures 3, 4, and 5: These figures have been restructured and combined into subfigures under Figure 3 to provide a more cohesive representation. This reorganization should enhance clarity and prevent any issues with resolution or stretching. The changes are highlighted in the revised manuscript.
2. Figure 8: This figure has been redesigned and is now presented as subfigure 6(a). The updated figure is clearer and better represents the data, with the changes also highlighted in the revised manuscript.
3. Figure 2: The blocks in this figure have been enlarged, with larger text to improve readability. Additionally, the arrows have been adjusted to ensure they accurately point to the desired values, addressing the confusion mentioned.
4. Formatting of "Packet collision probability": The formatting for "Packet collision probability" has been corrected, ensuring that all three words are properly formatted in bold as shown in line number 428.

 

Reviewer 3 Report

Comments and Suggestions for Authors

1. The manuscript presents a comprehensive and well-structured analysis of the challenges and solutions related to optimizing scheduling in low-power and lossy networks, focusing particularly on the TSCH protocol and its applications in smart home environments. The introduction effectively outlines the significance of IoT technology and its applications in smart homes and cities, emphasizing the constraints and challenges such as limited transmission rates, computational power, and the necessity for low power consumption. It highlights the complexity of maintaining quality of service due to the vast number of devices and the need for low-power operations, as well as the difficulties in establishing heterogeneous smart applications. The discussion on IoT application orchestration, optimal configuration, and holistic monitoring sets a clear context for the study. The manuscript addresses the limitations of previous approaches, such as the work done on smart home architectures using IoT technologies, and introduces the TSCH protocol as a robust solution for low-power and lossy networks, ensuring high reliability and minimal current consumption. The research focuses on developing a novel scheduler, OPTIMAOrchestra, to improve performance in smart home environments by minimizing latency, collisions, and energy consumption while maximizing packet delivery ratio. The contributions of the manuscript include the development of a custom script for generating diverse topologies, a comparative analysis of schedulers, the introduction of an innovative autonomous scheduling function, and enhanced cell-level and channel-level optimizations. The manuscript aims to establish a highly efficient and reliable communication framework for smart homes and dense industrial IoT topologies, demonstrating the extensive application and improved performance over previously designed protocols. However, certain aspects require further clarification. How does OPTIMAOrchestra specifically handle varying traffic rates and what are the metrics used to measure its performance improvement over existing schedulers? Additionally, more details on the experimental setup and the specific conditions under which the performance evaluation was conducted would be beneficial. The integration of the proposed scheduler with existing network architectures and its scalability in larger and more complex environments also merit further discussion. Moreover, the manuscript could be strengthened by providing a more detailed comparison with other state-of-the-art scheduling algorithms beyond just Orchestra and 6TiSCH, including a broader range of scenarios and traffic patterns. Finally, discussing potential limitations of the proposed approach and outlining future work directions to address these limitations would provide a more comprehensive view of the research contributions and their applicability.

2. I have written down various points.

 2.1 What are the specific objectives and scope of the proposed scheduling mechanism? How will the performance metrics be optimized and measured?

2.2 Can you provide more details on the architectural differences between MSH and MSHOP? How will the proposed scheduler integrate with these architectures and address their unique challenges?

2.3 Could you offer a more detailed explanation of the OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 designs? Can you include diagrams or flowcharts to illustrate the scheduling process and decision-making criteria?

2.4 What are the details of the experimental setup, including hardware and software configurations, network topologies, and traffic conditions? Can you specify the simulation parameters and conditions under which the performance evaluations were conducted?

2.5 Could you provide a comprehensive description of the traffic models and network topologies used in the simulations? What are the details about node density, mobility patterns, and the types of traffic (e.g., periodic, bursty)?

2. 6 What performance metrics are used for evaluation, such as latency, energy consumption, collision rate, and packet delivery ratio? How are these metrics calculated, and why are they relevant?

2.7 Have you conducted a detailed comparison with other state-of-the-art scheduling algorithms beyond just Orchestra and 6TiSCH? Can you include a broader range of scenarios and traffic patterns in the comparison?

2.8 How does the proposed scheduler perform in larger and more complex network environments? What are its limitations, and what potential solutions can address these limitations?

2.9 Can you include pseudo-code or detailed algorithm descriptions for key components of the proposed scheduling mechanism to help readers understand the implementation and operational flow?

2.10 What are the potential future work directions to address the limitations identified? Can you suggest possible improvements or extensions to the proposed scheduler?

2.11 The figures in the manuscript are too small and difficult to interpret. Can they be revised to be larger and more readable to enhance understanding for the readers?

Comments on the Quality of English Language

I apologize for the delay in my response. Upon reviewing the manuscript, I believe that several revisions are necessary to enhance its clarity and comprehensiveness.

Firstly, the manuscript would benefit from a thorough review of English grammar and overall readability. There are several areas where the language could be improved to ensure that the content is clear and professionally presented.

Additionally, the figures in the manuscript are too small and difficult to interpret. They should be revised to be larger and more readable to enhance understanding for the readers.

Overall, while the manuscript presents valuable research, these changes will significantly improve its quality and ensure that it meets the high standards expected for publication.

Thank you for your understanding and consideration.

Author Response

[Reviewer #3, Comment#1]

What are the specific objectives and scope of the proposed scheduling mechanism? How will the performance metrics be optimized and measured?

[Author's reply]

The authors want to thank you for your insightful comment. We have highlighted the objectives and the corresponding optimization and measurement strategies in the revised manuscript. For a better reference, it is highlighted below as well.

The main objective of this study is to develop a traffic-aware autonomous scheduleing 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, which can optimize the identified parameters for improved performance. The proposed OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 are designed by considering various factors such as the packet transmission requirements of nodes, utilization of physical communication channels, slot frame size, traffic types, and the network’s state. Additionally, to enhance the path and optimal configuration selection in smart home scenarios, we utilize our previously proposed approach, MSHOP [3]. Notably, existing application approaches, including our previously published MSHOP, need a dedicated scheduling approach, which is provided by the proposed work.

[Reviewer #3, Comment#2]

Can you provide more details on the architectural differences between MSH and MSHOP? How will the proposed scheduler integrate with these architectures and address their unique challenges?

[Author's reply]

The authors appreciate your interest in understanding the different topologies and their application in the current work.

Architectural Differences:

• MSH (Modified Smart Home): MSH is a smart home architecture that includes a middleware framework known as the Trusted Third Party (TTP). The TTP serves as an intermediary between the client nodes and the server, forwarding data packets from the client nodes to the server. This architecture is designed to enhance data transmission efficiency within smart home environments.
• MSHOP (Modified Smart Home Optimized Path): MSHOP is an enhanced version of the MSH architecture. It integrates an event timer within the TTP, which allows client nodes to send their packets only during specific time windows. This addition optimizes the data transmission process by reducing unnecessary traffic and improving overall network performance.

A detailed design and discussion of both architectures can be found in the following publication: "Panda, N. and Supriya, M., 2022. Efficient data transmission using trusted third party in smart home environments. EURASIP Journal on Wireless Communications and Networking, 2022(1), p.118."

Integration of the Proposed Scheduler:

The proposed scheduler is integrated with the MSHOP architecture, as it is the basis for designing all the topologies in our study. The nodes in these topologies utilize the TSCH (Time Slotted Channel Hopping) protocol, which enables slotting and scheduling mechanisms. This integration significantly reduces packet collisions, lowers latency, and increases reliability, addressing the unique challenges posed by smart home environments as shown in the result section. It is being mentioned and highlighted under methodology section.

[Reviewer #3, Comment #3]

Could you offer a more detailed explanation of the OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 designs? Can you include diagrams or flowcharts to illustrate the scheduling process and decision-making criteria?

[Authors' reply]

The authors would like to thank the Reviewer for requesting more details about the OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 designs and for suggesting a better illustration of the scheduling process. We have provided a detailed explanation in Section 3.3.1: OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 Design, where Algorithm 1 is presented to outline the design specifics. Additionally, the scheduling process is already illustrated in the manuscript through the flowchart shown in Figure 2. For improved clarity, this section has been highlighted in yellow in the revised manuscript.

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 seconds

33: ADJUST Shared Frame Cycle to 11 seconds

34: ADJUST Unicast Frame Interval to 5 seconds

35: ADJUST Application Packet Transmission Interval to 200 seconds

36: END FUNCTION

37: FUNCTION Calculate_Collision_Probability(nodes)

38: FOR each node in nodes DO

39: COMPUTE collision probability using formula (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 seconds

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

[Reviewer #3, comment#4]

What are the details of the experimental setup, including hardware and software configurations, network topologies, and traffic conditions? Can you specify the simulation parameters and conditions under which the performance evaluations were conducted?

[Authors' reply]

The authors would like to thank the Reviewer for pointing out about the experimental setup, simulation parameters. The experimental setup and simulation parameters has been presented under Table 3 namely Experimental settings. For a better clarification it is highlighted in the revised manuscript and added below as well.

 [Reviewer #3, comment#5]

Could you provide a comprehensive description of the traffic models and network topologies used in the simulations? What are the details about node density, mobility patterns, and the types of traffic (e.g., periodic, bursty)?

[Authors' reply]

The authors would like to thank the Reviewer for the point raised here about the traffic model, node density and mobility pattern in the manuscript. The details are mentioned under the Experimental Setting Table 3.

 [Reviewer #3, comment#6]

What performance metrics are used for evaluation, such as latency, energy consumption, collision rate, and packet delivery ratio? How are these metrics calculated, and why are they relevant?

[Authors' reply]

Thank you for your insightful comment regarding the performance metrics used in our evaluation. We have carefully considered the key metrics that directly impact network performance and have included the following in our manuscript highlighted. For better clarity about the parameter it is also added below.

[Reviewer #3, comment#7]

Have you conducted a detailed comparison with other state-of-the-art scheduling algorithms beyond just Orchestra and 6TiSCH? Can you include a broader range of scenarios and traffic patterns in the comparison?

[Authors' reply]

Thank you for your suggestion to expand the comparison to include a broader range of scheduling algorithms and scenarios. In our study, we focused on Orchestra and 6TiSCH as these have been identified by other researchers and through our literature survey as the most promising and widely adopted scheduling mechanisms.

However, we have taken your feedback into account and implemented a broader range of scenarios, including topologies with 551 and 1111 nodes. These expanded scenarios allow us to assess the performance more comprehensively. The details of these topologies are outlined in the Experimental Settings (Table 3), and the results of the comparison are presented in Table 5, under "Comparative Analysis of Topologies with 500 and 1000 Client Nodes."

We appreciate your input, which has helped to enhance the scope of our evaluation.

 [Reviewer #3, comment#8]

 How does the proposed scheduler perform in larger and more complex network environments? What are its limitations, and what potential solutions can address these limitations?

[Authors’ Reply]

The authors would like to express their gratitude for your insightful question, which prompted us to conduct a valuable experiment. To evaluate the performance of the proposed scheduler in large and complex networks, we conducted multiple experiments. The results, limitations, and potential solutions of these experiments have been included in the revised manuscript, with the relevant sections highlighted in yellow. For further clarification, we have detailed the findings below.

To evaluate the proposed scheduler’s performance in larger and more complex network environments, a detailed experiment is conducted in high-interference conditions with large scale node-dense deployments. The results are presented in Table 5. A topology with 50 clusters, each containing ten nodes (totaling 500 client nodes), is simulated for 5 minutes, 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. Additionally, latency decreased from 1.018 seconds to 0.190 seconds. Similarly, a topology with 100 clusters, each containing ten nodes (totaling 1000 client nodes and 101 additional nodes, for a total of 1101 nodes), is simulated for 5 minutes, 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 seconds to 0.194 seconds. A substantial decrease in collision rates is also observed. However, these performance gains were accompanied by increased 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.

 [Reviewer #3, comment#9]

 Can you include pseudo-code or detailed algorithm descriptions for key components of the proposed scheduling mechanism to help readers understand the implementation and operational flow?

[Authors’ Reply]

The authors are very much thankful for your kind suggestions regarding the pseudo-code or detailed algorithm descriptions. Authors have included the Algorithm 1: Orchestra Operational Flow, in the manuscript and highlighted in yellow color, which may help readers understand the implementation of the scheduler.

 [Reviewer #3, comment#10]

 What are the potential future work directions to address the limitations identified? Can you suggest possible improvements or extensions to the proposed scheduler?

[Authors’ Reply]

We sincerely thank you for your valuable comments regarding future work. To address the limitations, potential future work, possible improvements, and extension to the proposed scheduler is mentioned under the conclusion section and highlighted in yellow colour.

As the topologies expand in size, there is a noticeable increase in current consumption, presenting an exciting opportunity for future optimization. Additionally, the collision analysis reveals a certain level of noise, which of- fers 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.

 [Reviewer #3, comment#11]

 The figures in the manuscript are too small and difficult to interpret. Can they be revised to be larger and more readable to enhance understanding for the readers?

[Authors’ Reply]

Thank you for your valuable feedback. We appreciate your attention to the readability of the figures. In response to your feedback, we have revised the figures in the manuscript to improve clarity and readability. For comparisons involving the previous approaches (MSH, MSHOP) and the current approach (Orchestra), we have presented the data in three distinct subplots to enhance clarity. The remaining figures have been split into larger, more detailed images, ensuring better visibility and interpretation. These changes have been highlighted throughout the revised manuscript in yellow for your convenience.

 

Reviewer 4 Report

Comments and Suggestions for Authors

This paper proposes a new scheduling algorithm OPTIMAOrchestra to improve the performance of TSCH networks in smart home and industrial IoT environments. This approach combines adaptive autonomous scheduling capabilities with optimized time slot frames, demonstrating good performance under different network sizes and traffic conditions. The paper verifies the effectiveness of OPTIMA Orchestra through multiple experiments. The experiment range covers small to large network deployments, considers homogeneous and heterogeneous network topologies in static and mobile environments, and demonstrates reliability and energy consumption under different conditions. Performance. Simulation results show that OPTIMAOrchestra has improvements in network efficiency, time, and availability compared to existing scheduling algorithms, especially in terms of trade-offs between collision rate, delay, and energy consumption. However, the article still has improvements in aspects of background review, diversity of experimental environments, algorithm complexity, and network security. It is recommended that relevant content be further improved to improve the academic value and practical application value.

 

The modification suggestions are as follows:

1. The paper provides a brief introduction to the background of existing TSCH scheduling algorithms, especially the lack of in-depth analysis of the detailed mechanisms and shortcomings of scheduling algorithms such as 6TiSCH and Orchestra. It is recommended to add a detailed review of existing research work so that readers can better understand the advantages and improvements of the method proposed in this article.

2. The paper lacks an overall model and a corresponding optimization algorithm, and the proposed method lacks theoretical analysis.

3. The paper lacks verification in more practical application scenarios, such as performance evaluation in high-interference environments or large-scale node-dense deployments that are common in the Industrial Internet of Things.

4. The paper does not discuss the computational complexity and implementation difficulty of the OPTIMAOrchestra algorithm in detail. It is recommended to add relevant analysis to evaluate the feasibility and resource requirements of the algorithm in practical applications.

Comments on the Quality of English Language

This article is difficult to understand. It is recommended to improve the logic and clarity of the article.

Author Response

 [Reviewer #4, Comment#1]

The paper provides a brief introduction to the background of existing TSCH scheduling algorithms, especially the lack of in-depth analysis of the detailed mechanisms and shortcomings of scheduling algorithms such as 6TiSCH and Orchestra. It is recommended to add a detailed review of existing research work so that readers can better understand the advantages and improvements of the method proposed in this article.

[Author's reply]

 Thank you for your thoughtful suggestion. We have carefully selected and included the most relevant and significant works in our literature review to provide a comprehensive background on existing TSCH scheduling algorithms. The existing works, including the detailed mechanisms and shortcomings of algorithms like 6TiSCH and Orchestra, are thoroughly covered in Table 1 and throughout the related work section of the manuscript. We believe that the current references and analysis are sufficient to support the context and highlight the advantages of the proposed method. We hope this explanation addresses your concern.

 [Reviewer #4, Comment#2]

The paper lacks an overall model and a corresponding optimization algorithm, and the proposed method lacks theoretical analysis.

[Author's reply]

Thank you for your valuable feedback regarding the improvement of the overall model and optimization algorithm. In response, we have added an algorithm to illustrate the operational flow of the OPTIMAOrchestra, named Algorithm 1: Orchestra Operational Flow. Additionally, recognizing the importance of theoretical analysis, we have included a detailed assessment of the time complexity for both Orchestra and OPTIMAOrchestra. This theoretical analysis has been summarized in Section 4, Performance Evaluation. The revisions have been highlighted in the manuscript for your convenience, and  provided below for further clarification.

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 ・ (N2 + SOrc ・ ROrc)), where D is the simulation duration, R is the number of simulation runs, N denotes the number of nodes in the topology, SOrc stands for number of slotframe sizes, and ROrc is the number of rules used. Both OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 use only 3 rules, resulting in a time complexity of O(D・ R ・ (N2 +SOrc ・ 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.

[Reviewer #4, Comment #3]

The paper lacks verification in more practical application scenarios, such as performance evaluation in high-interference environments or large-scale node-dense deployments that are common in the Industrial Internet of Things.

[Authors' reply]

Thank you for your insightful comment regarding the need for verification in more practical application scenarios. We have addressed this by conducting performance evaluations in high-interference environments with large-scale, node-dense topologies, which are representative of Industrial Internet of Things (IIoT) deployments. Specifically, we have created two topologies:

1. A topology with 551 nodes, consisting of 500 client nodes arranged in 50 clusters of 10 nodes each, 50 TTPS, and one server. The topological structure is shown under Figure 6 b) 50 clusters 10 nodes
2. A topology with 1,111 nodes, comprising 1,000 client nodes arranged in 100 clusters of 10 nodes each, 100 TTPS, and one server. The topological structure is shown under Figure 6 c) 100 clusters 10 nodes

The topological structures can be found below.

The evaluation results for these scenarios are presented in Table 5: Comparative Analysis of Topologies with 500 and 1,000 Client Nodes, and a detailed explanation is provided in the revised manuscript. Both the table and the corresponding explanation have been highlighted for your reference, and a summary is attached below.

 

To evaluate the proposed scheduler’s performance in larger and more complex network environments, a detailed experiment is conducted in high-interference conditions with large scale node-dense deployments. The results are presented in Table 5. A topology with 50 clusters, each containing ten nodes (totaling 500 client nodes), is simulated for 5 minutes, 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. Additionally, latency decreased from 1.018 seconds to 0.190 seconds. Similarly, a topology with 100 clusters, each containing ten nodes (totaling 1000 client nodes and 101 additional nodes, for a total of 1101 nodes), is simulated for 5 minutes, 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 seconds to 0.194 seconds. A substantial decrease in collision rates is also observed. However, these performance gains were accompanied by increased 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.

[Reviewer #4, Comment #4]

The paper does not discuss the computational complexity and implementation difficulty of the OPTIMAOrchestra algorithm in detail. It is recommended to add relevant analysis to evaluate the feasibility and resource requirements of the algorithm in practical applications.

[Authors' reply]

We are thankful to you for raising this issue. In the revised manuscript computational complexity and implementation difficulty of the OPTIMAOrchestra algorithm are highlighted and mentioned in detail under section 4, which also addresses the resource requirement in practical applications mentioned under conclusion section. For a better clarification it is added below as well.

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 ・ (N2 + SOrc ・ ROrc)), where D is the simulation duration, R is the number of simulation runs, N denotes the number of nodes in the topology, SOrc stands for number of slotframe sizes, and ROrc is the number of rules used. Both OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 use only 3 rules, resulting in a time complexity of O(D・ R ・ (N2 +SOrc ・ 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.

As the topologies expand in size, there is a noticeable increase in current consumption, presenting an exciting opportunity for future optimization. Additionally, the 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.

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The authors provided satisfactory answers, and I accept their approach for measuring the current Ι.

Comments on the Quality of English Language

-

Author Response

Comment 1: The authors provided satisfactory answers, and I accept their approach for measuring the current Ι.

[Authors' reply]

The authors want to express deep gratitude for the valuable response.

Reviewer 3 Report

Comments and Suggestions for Authors

Please find the attached PDF file.

Comments for author File: Comments.pdf

Comments on the Quality of English Language

Revised Version

The English response you provided is well-structured overall, with no major grammatical errors. The main points are clearly organized, and the answers to the reviewer's questions are effectively presented. However, there are some areas where the language could be refined to make the response more natural and persuasive.

Strengths

• Clear Structure

 The responses are clearly structured, with each reviewer's comments addressed in separate sections.

• Direct Response

 The reviewer's comments are addressed directly and clearly, reflecting well the revisions made to the paper.

Areas for Improvement

• Sentence Flow

 Some sentences could flow more naturally. For example, in the sentence "Additionally, to enhance the path and optimal configuration selection in smart home scenarios, we utilize our previously proposed approach, MSHOP," using "Moreover" or "Furthermore" instead of "Additionally" could make the sentence flow more smoothly.

• Vocabulary Choice

 Some words could be replaced with more appropriate synonyms. For instance, instead of "improved clarity," it might sound more natural to say "better clarity." Similarly, using "enhanced" instead of "increased" could be more effective.

• Detailed Explanation

 Adding a bit more detail to your explanations could help readers understand your points more easily. For example, instead of saying, "we have provided a detailed explanation in Section 3.3.1," you might say, "we have provided a more detailed explanation of the design and operational logic in Section 3.3.1."

Overall

 The quality of your written English is high, but some improvements could be made to enhance the naturalness of your sentences and the precision of your vocabulary. These small adjustments will help improve the overall readability and persuasiveness of your paper.

 

Author Response

Comment : 1 (Goals and Performance Metrics):
Improvement: To enhance clarity, consider adding a sentence about how the proposed scheduling mechanism can adapt to varying traffic demands and network conditions. For example, you could include a description like, "This mechanism adapts in real-time to changing network conditions, continuously optimizing performance metrics."

[Author's reply]

Thank you for your valuable feedback. We have carefully considered your suggestion to add a sentence clarifying how the proposed scheduling mechanism adapts to varying traffic demands and network conditions, which is highlighted in yellow colour. To clarify the reference section, it is also added below.

Comment : 2 (Architectural Differences between MSH and MSHOP):
Added Specificity: While you've already explained the differences between the two architectures, it would be beneficial to be more specific about the challenges the proposed scheduler might face when integrated into MSHOP, and the approach you took to address them.

[Author's Reply]

Thank you for your interest in the challenges we faced while integrating MSHOP with the proposed scheduler. The most significant challenge was designing the MSHOP topology within the working tool. Initially, we had to meticulously design the MSH topology and then convert it to MSHOP, ensuring it aligned with the scheduler’s requirements. Once the topology was successfully designed, enabling TSCH was relatively straightforward. However, developing OPTIMAOrchestra required extensive simulations, precise formulation, and detailed analysis to ensure successful integration and optimal performance. These steps were crucial in overcoming the complexities of the integration process and validating the scheduler’s effectiveness within MSHOP. We appreciate your suggestion to delve deeper into this aspect, and we believe this additional detail strengthens the explanation.

Comment : 3 (Design of OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11):
Visual Aids: As requested by the reviewer, it would be helpful to clearly highlight the algorithm and flow diagram added to this section, along with explanations of what each step represents.

[Author's Reply]

Thank you for your suggestion to enhance the clarity of the OPTIMAOrchestra_ch4 and OPTIMAOrchestra_ch11 design section by including visual aids. In response, we have clearly highlighted the algorithm in the revised manuscript. Each step of the algorithm is now explained in detail to provide a better understanding of the process. For a better clarification it is highlighted in the revised manuscript and added below as well.

 

Comment : 8 (Performance in Complex Network Environments):
Limitations and Solutions: You've done well in clearly explaining the limitations of the proposed scheduler and potential solutions. If you could further emphasize the experimental results and the validity of the proposed solutions in this section, the reviewer might view it even more favorably.

[Authors' reply]

Thank you for your positive feedback on our discussion of the limitations and potential solutions of the proposed scheduler. In response to your suggestion, we have further emphasized the experimental results in this section to strengthen the validation of our proposed solutions. This change is highlighted in the revised manuscript and added below for your convenience.

 

 

 

Comment : 11 (Chart Size and Readability):
Specific Changes: You've explained the improvements in chart size and readability well. To strengthen this point, it would be helpful to mention specifically what has improved in the revised charts compared to the previous version.

[Authors’ Reply]

Thank you for your suggestion to enlarge the images and improve clarity. We appreciate your feedback, and after making the suggested changes, the charts now have a more polished appearance. It helped in improved data resolution, enhanced comparability, clearer value points, reduced overlap and clutter.

Comments on the Quality of English Language:

Thank you so much for the suggestion to improve the quality of the English language. We have taken care of sentence flow, vocabulary choice, and detailed explanation as suggested throughout the article.

 

 

Reviewer 4 Report

Comments and Suggestions for Authors The authors have provided a satisfactory response. I have no further comments. Comments on the Quality of English Language The authors have provided a satisfactory response. I have no further comments.

Author Response

Comment 1: The authors have provided a satisfactory response. I have no further comments.

[Author's reply]

 The authors are grateful for your valuable response.