# An Experimental Framework for 5G Wireless System Integration into Industry 4.0 Applications
## 4 Framework Applicability Example: 5G Autonomous Mobile Robots
### 5G Mobile Edge-Cloud Planner for Autonomous Mobile Robots  
Following the operational flow, after completion of the first iteration, a new one can be started prior re-evaluation of the new digitalization needs for AMRs. In this second iteration, the 5G-integration flow was applied as follows:  
* Once the reliable 5G-control was demonstrated to the AMR manufacturer, they were immediately interested in trying to unleash the full 5G potential by investigating whether other more heavy processes than the FM-based control could be operated over 5G. Moving part of the current on-board intelligence from the AMR to the mobile edge-cloud (MEC) would result in cheaper products and more flexible AMR products as the on-board processing power could be reduced and having a single high-processing power centralized server deployed at infrastructure-side would enable cloud-in-the-loop operation [43] towards all the AMRs, facilitating the exchange of information between AMRs and reducing the burden of having to push SW upgrades to each AMR individually. The specific application selected to be moved to the 5G MEC was the AMR planner. Currently, an AMR navigates by using its on-board planner and does not share any information with other robots. This typically results in sub-optimal navigation routes in the case that the AMR navigates into an obstacle and needs to re-plan its route, even if that same obstacle was previously detected and avoided by another robot. This problem can be mitigated by moving the planner functionalities to the edge-cloud where a centralized virtual shared-world could be built, allowing for the optimization of the navigation for all AMRs at once. * The AMR vendor provided us with an external planner unit and re-architured the AMR communication (mainly the I/O connections) to make use of the external device instead of its on-board planner. The new architecture is illustrated in Figure 10(a), and can be compared for further reference to the standard AMR architecture in Figure 10(a). All internal communication within the AMR happens over ethernet, so the NTS device was used to analyze the data traffic in the I/O-planner communication link. TCP traffic was found with average packet sizes of 128 B and average PIAT of 0.5 ms in both the I/O-planner and planner-I/O communication directions. The overall throughput was 1.3-1.9 Mbit/s (for a single robot), which confirms that, as expected, the I/O-planner commutation is more demanding than AMR-FM one. * _Although more demanding than in the AMR-FM case, the I/O-planner link is also suitable for 5G operation, at least based on the the throughput, packet sizes and inter-packet times values. However, it was questioned what the impact of the higher 5G delays (compared to the cabled ethernet reference) would be on the performance of the robot. Understanding this is of paramount importance, as the timely and reliable operation of the planner is application-critical, and a excessively long I/O-planner communication delay could result in a sub-optimal navigation performance of the robot. In this case, before proceeding to the deployment step, it was decided to make a 5G-based I/O-planner emulation test to understand the potential impact of 5G delays into the functional operation of the AMR. To do that, the 5 GE device was used. As displayed in Figure 11b, the emulator was placed between the I/O of the robot and the external planner device, mirroring the 5G MEC planner configuration illustrated in Figure 11a. A navigation performance and a docking accuracy tests were performed for benchmarking the operation of the reference cabled planner (REF) to the one achieved over 5G. For 5G two different delay distributions were loaded into the 5 GE, one with empirical values obtained over 5G Rel. 15 (current 5G commercial version) with an average delay of 4.9 ms, and one with values from a simulation of 5G URLLC [9] with an average delay of 0.75 ms.