Data-Driven, Real-Time Diagnostics of 5G and Wi-Fi Networks Using Mobile Robotics
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsThe paper designs a platform that integrates mobile robots, dual path networks, real-time data collection, and visualization analysis for performance diagnosis of 5G and WiFi in industrial environments. The paper is innovative and practical, but the writing is cumbersome, the content is redundant, and there are still some issues that have not been deeply analyzed, which need to be further improved.
- The abstract is written quite well, with clear structure, but some sentences are too long, making it difficult for readers to read.
- Introduction and related work sections, from the research background to the limitations of existing methods, and to the solution proposed in this article, point out that existing work only studies a single network and lacks integration with mobile robot platforms and real-time spatial diagnosis. But the depth of the discussion can be further expanded:
Explore the fundamental differences in protocols and timing between 5G and WiFi roaming, and explain from the working principle why 5G is more stable in experimental results.
Add the comparison of mobile network measurement methods, including unmanned aerial vehicles, driving, multi person perception, and other measurement methods.
A forward-looking discussion on the collaborative work of 5G and WiFi, including heterogeneous networks.
- The Methodology section is detailed in content, but there are issues with cumbersome narration and bloated structure, resulting in the core innovation points not being highlighted. Suggest re planning chapter content according to logical modules.
Suggest drawing a high-level data flow as the core of Section 3.1, such as the data acquisition layer: Jetson is responsible for SLAM and navigation, Raspberry Pi is responsible for network diagnosis, and other layers.
Sections 3.1.1 and 3.1.2 have devoted a significant amount of space to describing power supply and configuration, and can be merged into one section: Robot Platform and Hardware Integration.
Sections 3.4.1, 3.4.2, and 3.4.3 use a lot of text to describe parameters including AT commands or ipconfig. It is recommended to create a summary table to replace the lengthy text description.
It is recommended to start with a general framework diagram, summarize indicators and methods using tables, replace command lists with processes, strengthen design logic and motivation, and make the structure clearer.
- The Results section is not only quite cumbersome in content, but also has some issues:
The reasons for UDP packet loss and the impact of packet loss on specific applications have not been thoroughly analyzed.
The sample size is small and the statistical significance is limited, so an explanation should be provided.
The experiment was conducted in a real factory environment, but the impact of equipment interference and personnel movement in the factory was not explained.
The bandwidth testing of 5G and WiFi is conducted separately and does not simulate the scenario of multiple devices using the network concurrently in real scenarios.
The experimental time is relatively short and the stability of the system under long-term operation has not been verified.
Relying on Grafana for visualization, it is recommended to discuss how the platform can automatically diagnose.
Author Response
Comment 1: The abstract is written quite well, with clear structure, but some sentences are too long, making it difficult for readers to read.
Response 1: Thank you for the suggestion. The abstract has been revised to shorten overly long sentences and improve readability while preserving the original technical content.
Comment 2: Explore the fundamental differences in protocols and timing between 5G and WiFi roaming, and explain from the working principle why 5G is more stable in experimental results.
Response 2: We appreciate this comment. The manuscript has been updated to better explain why 5G exhibited more stable behaviour. In the Related Work sections, we now reference empirical studies on private 5G performance and roaming, and (ii) clarify that in our deployment the private 5G system operates as a single-frequency network with network-controlled mobility, resulting in seamless handover and minimal interruption. In contrast, Wi-Fi roaming relies on client-driven AP reassociation, which can briefly interrupt connectivity and, for UDP traffic without retransmission, directly results in packet loss. This explanation is now explicitly linked to the observed stability differences in Section 4.4.3.
Comment 3: Add the comparison of mobile network measurement methods, including unmanned aerial vehicles, driving, multi person perception, and other measurement methods.
Response 3: We have expanded the Related Work section to include and contrast multiple mobile measurement approaches: (i) drive-test based evaluations of public LTE/5G, (ii) UAV-based measurements illustrating altitude-dependent degradation, and (iii) distributed AGV-based measurements in industrial environments. We explain how our approach differs by using a SLAM-capable mobile robot with tightly integrated Wi-Fi and 5G diagnostics, spatial correlation, and a unified telemetry stack.
Comment 4: A forward-looking discussion on the collaborative work of 5G and WiFi, including heterogeneous networks.
Respone 4: A forward-looking discussion on heterogeneous and collaborative use of Wi-Fi and 5G has been added to the Related Work section. We highlight multi-connectivity as an important emerging strategy, discuss how parallel use of Wi-Fi and 5G can enhance reliability, and position our platform as a practical testbed for evaluating such heterogeneous deployments by operating both technologies in parallel on the same mobile node.
Comment 5: The Methodology section is detailed in content, but there are issues with cumbersome narration and bloated structure, resulting in the core innovation points not being highlighted. Suggest re planning chapter content according to logical modules.
Suggest drawing a high-level data flow as the core of Section 3.1, such as the data acquisition layer: Jetson is responsible for SLAM and navigation, Raspberry Pi is responsible for network diagnosis, and other layers.
Sections 3.1.1 and 3.1.2 have devoted a significant amount of space to describing power supply and configuration, and can be merged into one section: Robot Platform and Hardware Integration.
Sections 3.4.1, 3.4.2, and 3.4.3 use a lot of text to describe parameters including AT commands or ipconfig. It is recommended to create a summary table to replace the lengthy text description.
It is recommended to start with a general framework diagram, summarize indicators and methods using tables, replace command lists with processes, strengthen design logic and motivation, and make the structure clearer.
Response 5: We agree and have substantially restructured the Methodology section:
- Introduced Section 3.1 Robot Platform and Hardware Integration to concisely describe the Mecabot, Jetson, and Raspberry Pi hardware.
- Introduced Section 3.2 System Overview and Data Flow Architecture with a high-level three-layer framework and a dedicated data flow diagram.
- Organized the remaining content into three logical layers:
- 3 Perception and Control Layer (Jetson Orin Nano)
- 4 Edge Data Acquisition and Network Diagnostics Layer (Raspberry Pi 5)
- 5 Data Management and Visualization Layer (On-Premise Server & Dashboard)
- Replaced long command descriptions and parameter lists with summary tables for Wi-Fi, 5G, and neighbouring network metrics.
- Removed redundant low-level configuration details or integrated them briefly where strictly necessary.
Comment 6: The reasons for UDP packet loss and the impact of packet loss on specific applications have not been thoroughly analyzed.
Response 6: We have extended Section 4.4.3 to explicitly analyze the causes and implications of UDP packet loss. By correlating loss events with Wi-Fi roaming, signal strength, band changes, and robot position via the integrated dashboard, we show that most UDP loss events on Wi-Fi coincide with AP handovers or operation in more interference-prone 2.4 GHz channels. In contrast, no loss is observed on the 5G paths in our deployment. We further discuss the relevance of these findings for different classes of applications, noting that such roaming-induced gaps are problematic for safety-critical and time-sensitive control traffic, with reference to 3GPP TS 22.104 service performance requirements for mobile robotics (e.g., 99.9% reliability), and must be mitigated via redundancy or protocol design.
Comment 7: The sample size is small and the statistical significance is limited, so an explanation should be provided.
Response 7: We acknowledge the limited number of full experimental runs and have clarified this in the Results section. The study is positioned as a detailed feasibility and characterization exercise for data-driven diagnostics in a representative industrial IIoT scenario, rather than a broad statistical survey. The measurement setup and traffic pattern are aligned with 3GPP TS 22.104 service performance requirements for mobile robotics (Table A.2.2.3-1), in particular the periodic communication use case (Use Case 3), which specifies a small payload of 40 bytes at transmission intervals in the 40-500 ms range, and a target reliability of 99.9%. Our IIoT streaming configuration is consistent with these parameters and is used to evaluate whether the underlying wireless infrastructure can support such requirements in practice. In addition, the active duration of each run was dictated by realistic constraints: the time required for the robot to fully traverse and characterize the factory floor (approximately 40 minutes) and the available battery capacity.
Comment 8: The experiment was conducted in a real factory environment, but the impact of equipment interference and personnel movement in the factory was not explained.
Response 8: This point has been addressed by explicitly describing the experimental environment at the beginning of the Methodology. We now state that measurements were taken during normal operation in an electronics manufacturing facility with active machinery, metal structures, and personnel movement, and we note that these factors introduce realistic interference, and transient variability.
Comment 9: The bandwidth testing of 5G and WiFi is conducted separately and does not simulate the scenario of multiple devices using the network concurrently in real scenarios.
Response 9: We agree that the current experiments do not emulate a fully loaded multi-device scenario. This is an inherent limitation of the study and is left intentionally out of scope. The goal of this work is to evaluate how a single mobile robotic probe, representative of an IIoT/robotics endpoint, experiences Wi-Fi and 5G connectivity while moving through a real factory environment, with spatial correlation of network and robot state.
Multi-device loading patterns, user densities, and traffic mixes are highly deployment-specific and typically determined by the factory’s overall infrastructure design and production requirements. Accurately reproducing such conditions would require coordinated control over many additional devices and services in the facility.
Our platform is designed as a diagnostic tool, not as the load generator for all endpoints, it can be used alongside existing devices or external traffic generators to observe the effect of concurrent load on a real mobile robot in future studies, but in this paper we focus on clearly characterizing link behaviour and roaming effects for a single robotic client.
Comment 10: The experimental time is relatively short and the stability of the system under long-term operation has not been verified.
Response 10: We have clarified the experimental timeline and platform behaviour in Section 4.2. Initial runs were affected by a misconfigured power supply to the Raspberry Pi 5, which has since been corrected (Section 3.1). The final two runs, using the corrected configuration, operated stably for at least 42 minutes under high-load conditions; data collection was stopped because the robot had completed coverage of the target area and the battery level had dropped, not due to system failure.
Comment 11: Relying on Grafana for visualization, it is recommended to discuss how the platform can automatically diagnose.
Response 11: The current implementation does not perform automatic diagnosis. The primary goal of the proposed platform is to provide a unified, time-synchronized, and spatially contextualized view of wireless and robotic telemetry so that engineers can make informed, data-driven decisions. Grafana is used as an operator-facing tool to correlate events such as roaming, packet loss, latency variation, and signal degradation with robot position and network conditions.
Reviewer 2 Report
Comments and Suggestions for Authors 1. In the field of wireless communication research, most studies focus on either Wi-Fi or 5G connectivity performance individually. However, this article implements Wi-Fi and 5G in parallel and conducts a performance comparison. Please explain what technical challenges exist when using Wi-Fi and 5G in parallel, as opposed to implementing them separately.
2. Suppose there are two technical approaches. Scheme 1: Wi-Fi and 5G are used in parallel for performance testing, and their connectivity performance is directly compared—this is the approach adopted in the article. Scheme 2: Wi-Fi and 5G performance are tested separately, and their signal performance is compared afterward. The signal performance comparison effect between these two approaches appears to show little difference. Please clarify.
3. The article uses a mobile robot to conduct experimental measurements, and it can operate stably for at least 42 minutes under high-load conditions such as bandwidth testing. Under normal operating conditions, what is the fault-free operational time of the robot?
4. Due to mismatched power configuration, the mobile robot failed to record complete logs in four of the experiments, resulting in the first four experimental results being discarded, with only the final two results being adopted. Can these two experimental results be considered representative of the final outcome? Is it necessary to supplement the results with data from the first four experiments?
5. The robot used in the article experienced operational anomalies during the experiment, leading to incomplete data recording. Is it possible to add an alert system to provide early warning of robot measurement failures, in order to avoid invalid experimental measurements?
Author Response
Comment 1: In the field of wireless communication research, most studies focus on either Wi-Fi or 5G connectivity performance individually. However, this article implements Wi-Fi and 5G in parallel and conducts a performance comparison. Please explain what technical challenges exist when using Wi-Fi and 5G in parallel, as opposed to implementing them separately.
Response 1: We thank the reviewer for this comment. In Section 3.4, we now clarify the specific challenges of operating Wi-Fi and 5G in parallel on a single mobile node. The system must:
- use interface-specific routing and dual IP addressing so that traffic is correctly sent over the intended interface,
- apply strict tagging of all measurements and time-synchronized telemetry so that each sample is unambiguously associated with the correct access technology,
- and avoid routing ambiguity and cross-contamination of results.
We also state that this design helps mitigate bias from differing infrastructure densities (e.g., more Wi-Fi access points or additional 5G radio heads in separate setups). These points are explicitly described in the added paragraph in Section 3.4.
Comment 2: Suppose there are two technical approaches. Scheme 1: Wi-Fi and 5G are used in parallel for performance testing, and their connectivity performance is directly compared—this is the approach adopted in the article. Scheme 2: Wi-Fi and 5G performance are tested separately, and their signal performance is compared afterward. The signal performance comparison effect between these two approaches appears to show little difference. Please clarify.
Response 2: As clarified in Section 3.4, the proposed platform uses parallel measurements over Wi-Fi and 5G to enable direct comparison of both technologies under identical spatial and timing conditions. By combining interface-specific routing, dual IP addressing, strict tagging, and time-synchronized telemetry, the framework:
- ensures that traffic and events are unambiguously associated with the correct interface, and
- mitigates bias that could arise if Wi-Fi and 5G were evaluated in separate deployments with different infrastructure densities.
We further note in that passage that this concurrent operation also aligns with emerging multi-connectivity strategies, where Wi-Fi and 5G are intentionally used together. Thus, Scheme 1 is not equivalent to running two separate tests: it provides controlled, side-by-side evaluation in the same environment and is directly supported by the mechanisms described in Section 3.4.
Comment 3: The article uses a mobile robot to conduct experimental measurements, and it can operate stably for at least 42 minutes under high-load conditions such as bandwidth testing. Under normal operating conditions, what is the fault-free operational time of the robot?
Response 3: Thank you for this question. The reported ≥42 minutes corresponds to time required in our deployment to cover the full production area. We have clarified in Section 4.2 that the end of the reported runs was due to mission completion and battery level, not system instability.
Comment 4: Due to mismatched power configuration, the mobile robot failed to record complete logs in four of the experiments, resulting in the first four experimental results being discarded, with only the final two results being adopted. Can these two experimental results be considered representative of the final outcome? Is it necessary to supplement the results with data from the first four experiments?
Response 4: We agree that this requires explicit clarification and have updated Section 4.2 accordingly. The first four runs were affected by an incorrect power configuration for the Raspberry Pi 5, which caused instability and incomplete logging under peak load. This reflects a temporary platform misconfiguration, not the behaviour of the networks under test. The issue was resolved via the hardware and firmware changes described in Section 3.1.
The final two runs were performed after this correction, using the finalized and stable system configuration, and completed without logging failures. Only these post-fix runs are reported, as they are representative of the intended operation of the platform. Including the earlier, datasets which were collected under a different hardware configuration would not provide a fair or meaningful basis for evaluation. We state this explicitly in the manuscript.
Comment 5: The robot used in the article experienced operational anomalies during the experiment, leading to incomplete data recording. Is it possible to add an alert system to provide early warning of robot measurement failures, in order to avoid invalid experimental measurements?
Response 5: This is a valuable suggestion. In the current work, the platform does not implement a dedicated automatic alert system. However, the architecture is well-suited to support alerts, metrics such as logging activity, interface status, power levels, and packet loss are already ingested into InfluxDB and visualized in Grafana. Grafana alerts could be determined based of the existing telemetry without architectural changes.
Reviewer 3 Report
Comments and Suggestions for AuthorsThis is one of the best papers I have read — it is well written and follows a sound research methodology. It should be accepted for publication as it is, except for minor improvements required in the diagrams/chart visualizations, as the print/view resolution may not be adequate. The research is particularly valuable for industries where a high concentration of metallic and water droplets in the air affects signal penetration.
Although the content selected for this paper is adequately addressed within its defined scope, I hope the authors will consider exploring handover mechanisms within 5G RUs in future work, as this remains a complex and important topic. Additionally, although unlikely to have a significant effect in the selected test case, SBC platforms such as the Raspberry Pi can be quite limited when it comes to pushing the network to its performance limits
Author Response
Comment 1: This is one of the best papers I have read — it is well written and follows a sound research methodology. It should be accepted for publication as it is, except for minor improvements required in the diagrams/chart visualizations, as the print/view resolution may not be adequate. The research is particularly valuable for industries where a high concentration of metallic and water droplets in the air affects signal penetration.
Response 1: We thank the reviewer for the very positive feedback and for highlighting the practical relevance of the work. All diagrams and charts have been regenerated at higher resolution and with improved layout to ensure clarity in print and on-screen.
Comment 2: Although the content selected for this paper is adequately addressed within its defined scope, I hope the authors will consider exploring handover mechanisms within 5G RUs in future work, as this remains a complex and important topic. Additionally, although unlikely to have a significant effect in the selected test case, SBC platforms such as the Raspberry Pi can be quite limited when it comes to pushing the network to its performance limits
Response 2: We agree with the reviewer that single-board computers such as the Raspberry Pi can become a bottleneck when approaching the upper limits of network performance. In the context of this study, the Raspberry Pi 5 provided sufficient capability for measurement, logging, and parallel interface monitoring within the targeted operating range. However, in our more recent work we have begun migrating to Intel-based mini PCs as the edge node, which offer significantly higher CPU, I/O, and NIC performance and are better suited for stress-testing links closer to their theoretical limits. This evolution is fully compatible with the proposed architecture.
Round 2
Reviewer 1 Report
Comments and Suggestions for AuthorsThe paper has been revised very well. All issues have been addressed, the technical principles have been deepened, the literature review has been expanded, the system architecture description has become clearer, and the academic rigor and foresight of the article have been improved.
The English quality of the paper is very high, with very few errors. But it is still recommended that the author conduct a thorough proofreading. For example, page 2: In contrast, the private 5G network in this testbed which is deployed on a Nokia Radio Access Network (RAN). ‘Which’ in the sentence can be removed. Page 4: Many IoT telemetry streams appear to use TCP rather than UDP as a communication medium. TCP UDP is a network protocol, and it would be better to change the protocol to medium.
