An Experimental Framework for 5G Wireless System Integration into Industry 4.0 Applications

Abstract

The fourth industrial revolution, or Industry 4.0 (I4.0), makes use of wireless technologies together with other industrial Internet-of-Things (IIoT) technologies, cyber–physical systems (CPS), and edge computing to enable the optimization and the faster re-configuration of industrial production processes. As I4.0 deployments are ramping up, the practical integration of 5G wireless systems with existing industrial applications is being explored in both Industry and Academia, in order to find optimized strategies and to develop guidelines oriented towards ensuring the success of the industrial wireless digitalization process. This paper explores the challenges arisen from such integration between industrial systems and 5G wireless, and presents a framework applicable to achieve a structured and successful integration. The paper aims at describing the different aspects of the framework such as the application operational flow and its associated tools, developed based on analytical and experimental applied research methodologies. The applicability of the framework is illustrated by addressing the integration of 5G technology into a specific industrial use case: the control of autonomous mobile robots. The results indicate that 5G technology can be used for reliable fleet management control of autonomous mobile robots in industrial scenarios, and that 5G can support the migration of the on-board path planning intelligence to the edge-cloud.

1. Introduction

Seamless system integration is a key aspect of the fourth industrial revolution (Industry 4.0) [1]. In this respect, 5G, one of the most advanced connectivity options, designed to achieve low latency, high reliability, flexibility, and security [2], is expected to be integrated with different cyber–physical systems (CPS), other industrial Internet-of-Things (IIoT) technologies, and cloud computing. This will bring smart factories and other industrial production environments to the next level in terms of optimization of the production processes and flexibility and re-configuration of the industrial manufacturing systems [3]. Common for most of these concepts is that they require extensive knowledge of information technologies (IT) and operational technologies (OT). Furthermore, as such, they should be viewed as a multi-disciplinary venture, making the transition to I4.0 for a particular company, site or factory not an easy task. To assist in this transition, multiple frameworks/methodologies have been proposed, mainly with the aim of defining roadmaps based on the digitalization and technological readiness levels [4,5,6,7].

These frameworks aim mainly at helping industrial manufacturing companies in identifying their levels of digital maturity, as well as guiding their digitalization efforts with the addition of reflective steps throughout the entire process. In general, these frameworks emphasize that reliable wireless connectivity is the key enabler for system interconnection, allowing for tying all the factory assets together in a seamless way, and facilitating the deployment of advanced IT concepts such as big data and artificial intelligence (AI) but also OT concepts such as autonomous mobile robots or matrix production [7]. However, while some of the frameworks include considerations for the underlying communication-specific aspects, mainly in relation to the industrial application requirements, they do not go into details with the integration and performance that specific wireless technologies may have when applied to specific applications. The wireless landscape in industrial scenarios is comprised by multiple different technologies with very different capabilities, with Wi-Fi being today the de facto connectivity option [8]. However, the performance and reliability of Wi-Fi varies largely depending on the specific environment and application scenario due to its operation over unlicensed frequency bands, where the spectrum is shared with other networks. As in such case, it is necessary to “compete” to access the medium for transmission, high reliability and quality-of-service levels might not be fulfilled under certain conditions [9]. As 5G was designed to provide better performance and higher levels of reliability and, since the first commercial 5G networks for industrial use are being deployed [3], it is now time to ensure that the full potential of 5G is properly evaluated and demonstrated within the context of industrial use [10]. However, we are witnessing a lack of proper use case analyses, performance evaluations and development of guidelines addressing the integration of wireless technologies within the different I4.0 applications but also within the overall digitalization processes.

From a 5G perspective, the envisioned flexibility targeted by the I4.0 concept will require a proper assessment of the integration of the networking elements with the individual applications or use cases [11]. Thus, the objective of this paper is to propose an experimental framework for 5G wireless system integration into Industry 4.0 applications. This framework defines an industrial automation operational flow structured in different steps aiming at demonstrating, evaluating and optimizing the feasibility of operating specific industrial use cases over 5G in realistic factory conditions. The framework considers specific needs from factories or industrial entities, industrial-grade hardware, specific communication requirements and protocols, to evaluate the feasibility of operation of selected use cases over 5G and to benchmark it with alternative wireless technologies. In order to achieve that, the experimental framework is complemented by a specific industrial research lab environment and a number of 5G hardware and software prototyping tools. The specific selections of experimental methodology, available in-lab technologies, and even the specific hardware and software prototyping implementations have been partly impacted by generalization of learnings and inputs from our extensive conversations with multiple entities of the Danish manufacturing industry.

The rest of the article is organized as follows: Section 2 discusses a number of framework design considerations based on the learnings from our conversation with the Danish Industry. Section 3 describes the proposed experimental framework, including the operational flow, research lab facilities and hardware and software prototyping implementations. Section 4 illustrates the applicability of the experimental framework for a specific industrial application: autonomous mobile robots (AMRs). Section 5 provides a discussion on the potential considerations for future versions of the framework. Finally, Section 6 concludes the paper.

2. Learnings from Industry and Related Framework Design Considerations

In order to guarantee that our proposed 5G system integration framework is aligned with the needs of industry, the main learnings from four years of numerous conversations and visits to different Danish factories are analyzed and considered directly into the design:

• The manufacturing industry, and especially the small and medium enterprises, has little or no experience with wireless communications. In general, some experience with Wi-Fi (non-optimized in most cases) was observed, but not with 4G, 5G, and the other wireless technologies. This is mainly due to the fact that, until recently, products and business models for their usage in factory were practically nonexistent. Thus, an initial learning process should be expected when introducing these technologies in manufacturing environments.

  -

  Design consideration: a common language and understanding needs to be established. Each factory and operational teams are different from others so, ideally, this should be done on an individual factory and use case basis. Benchmarking the performance of the wireless solution, not only over 5G, but also over other technologies such as Wi-Fi should help in improving the understanding of the different wireless operational possibilities. In this case, disseminating performance test results to manufacturing experts is an important aspect to consider.

• Deploying a wireless system is typically not considered in the business models, and is generally perceived as a cost and not as benefit. Moreover, due to the lack of experience with wireless communications, in most cases, a large degree of skepticism about the reliability, capabilities and potential of these technologies was detected.

  -

  Design consideration: In order to build trust and convince the manufacturing industry about the suitability and the potential benefits of wireless applied to production, live demonstrations of wireless-operated industrial use cases are encouraged. This could take form of trials in factories or demos in lab environments, where wireless-integrated production concepts are shown to manufacturing experts.

• In general, current wired industrial factory control networks are not optimized for direct integration with wireless technologies. Integration gaps range from a non-optimal topology, to the use of non-IP traffic or transmission modes, such as broadcast, that may not be directly enabled/supported by wireless technologies. To fully exploit the benefits of wireless applied to industrial production, a re-architecture of such control networks will be an essential step.

  -

  Design consideration: hardware and software prototypes should be flexible enough to cope with modern (IP-based) and old (non-IP-based) communication protocols. Furthermore, the prototypes should be flexible enough to support different control architectures and modes of operation such as infrastructure mode (where end-devices communicate to a centralized entity or controller) and device-to-device communication (where the end-devices can communicate directly among themselves).

• There is a huge hype among the manufacturing industry about cloud control and cloud monitoring, which lead to a noticeable tendency of installing such systems within their production equipment without a proper performance impact assessment, as high capacity communication links available from each device to the cloud are taken for granted. However, this might not always be true, especially when operating over wireless, which could lead to some operational problems.

  -

  Design consideration: a proper data traffic analysis should be done before proceeding with the integration of an application with wireless in order to identify all potential communication flows in a given system. Further, a performance evaluation should be done after the wireless solution is deployed, to ensure operational correctness.

• Legacy is extremely important. Not all companies will have the chance to invest in the most advanced solutions, but still introducing a few wireless components for specific communication needs might result in a considerable gain for them.

  -

  Design consideration: hardware and software prototypes should be able to transport over wireless legacy communication protocols that are conceived for industrial wired setups.

3. Experimental Framework for 5G Integration

The proposed experimental framework is aimed at providing services to industries, and is expected to be technology-unbiased. In this respect, the main actors of the framework can be, in a first moment, academic institutions interested in cross-disciplinary research on wireless and manufacturing. Initiating a dialogue with the manufacturing sector, and bringing wireless solution to factories, can indeed be mutually beneficial. The manufacturing sector can obtain an unbiased view on the wireless technologies and installation types that would better suit their specific needs. Besides, the manufacturing sector can enrich their vision for a wireless factory by leveraging the knowledge of the scientific trends brought by the academic institutions. Our dialogue with Danish factories has revealed that such unbiased view on wireless technologies is of great value for them. On the other hand, academic institutions can acquire extra knowledge on real factories setups, data traffic and production needs, besides identifying shortcomings of current wireless solutions or manufacturing concepts in addressing the factory demands. This can pave the way of future research activities on both wireless and manufacturing domains, and their integration. In the long term, we foresee opportunities where new business entities can act as middlemen between the manufacturing sector and the wireless sector (vendors and operators) for providing adequate recommendations on solutions and installations which are not tight to specific technologies or equipment/service providers and, thus, this framework can be of relevance for them.

The proposed framework is composed of: an operational flow that describes the overall sequential actions to be taken to achieve a successful operation of a given I4.0 application over 5G, an industrial research lab environment where the experimentation will take place, and the 5G hardware and software prototypes tools that are used to integrate the 5G system and the machinery associated with the selected industrial use case.

3.1. Industrial Automation Operational Flow

As illustrated in Figure 1, the proposed experimental framework is based on a sequential operational flow structured in six steps. Each of the steps has a different objective and makes different use of the lab environment and prototyping tools that are described in Section 3.2 and Section 3.3, respectively.

STEP 1.

Understanding the needs of the factory and its current level of digitalization: the factory is visited in order to get a good overview of overall operations and digitalization status. It is important, that during a first visit, common ground and common languages are established. Conversations are typically initiated with management, digitalization, research and innovation responsibles to learn about their views on 5G, the specific applications that they envision to run in their factories in the future, but also about those current applications that they would like to operate over wireless for improving the current production systems. Conversations are also held with IT responsibilities in order to understand the current wired and Wi-Fi network architectures, office and production network splits and network performance. With this information, we can feed the following steps of the operational flow with realistic information about the specific operational conditions required.

STEP 2.

Understanding the exact communication requirements of the wired setup (data traffic analysis): in this step, that also takes place at the factory, a specific targeted I4.0 application is selected and the production area is visited—ideally, together with someone from both the IT and manufacturing departments, in order to have an overview of the exact machinery setting and its control network architecture. Further, a data traffic analysis is performed over relevant interfaces, candidates to be potentially operated over 5G, to understand and characterize the exact communication flows, protocols used, and the volume of data in different parts of the industrial system. This step is essential, as similar applications in different factories might implement very different control communication systems, and thus the more detailed the information, the better. It is important to check with the IT or production engineers about the control-loop latencies implemented in their systems, as well as survival times (sometimes called control failure times). These two parameters, together with the control architectures and the traffic statistics (throughput, packet sizes and inter-packet times) are essential information for evaluating whether the chosen application would be suitable for operation over 5G.

STEP 3.

Selection of the appropriate wireless technology and dimensioning of the solution: based on the information collected in the previous step, we can analyze the suitability of 5G or other wireless technologies for coping with the targeted application and guide the factory about the most appropriate one. These could be done by simple “pen and paper” exercises based on requirements and wireless capabilities or via simulation/emulation. In general, the decision will be made according to capacity and control-loop latency requirements. High throughput time-critical applications could only be supported by 5G, while those applications that are delay-tolerant could be supported by 5G or other alternative technologies such as 4G or Wi-Fi (under very specific and optimized operational conditions) [9]. It should be noted that some of the most demanding applications might still not be supported by 5G, e.g., applications requiring sub-ms latencies, and in that case, legacy wired setups should still be used.

STEP 4.

Deployment: once the wireless technology has been selected, i.e., 5G, the practical system integration begins. One or more of the relevant interfaces identified in STEP 2 are selected for integration of a 5G interface into them. This process is normally not straight forward as the IT integration itself, and the debugging of connectivity and 5G-integrated interface routing schemes, turns typically into a quite time-consuming task. Ideally, at the end of this step, the result is a fully functional 5G-integrated I4.0 application, both in terms of hardware and software, ready to be tested in operational conditions.

STEP 5.

Performance analysis: the fully functional 5G-integrated industrial application is thoroughly tested. In this step, typically, reliability tests are executed by monitoring the correct operation of the industrial system during a long period of time (could be from several hours to several days). Performance tests are also done, looking at the communication efficiency in terms of, for example, control-loop latency performance. Other parameters such as throughput or time between failures could be monitored, ensuring that the outcome of the testing is well aligned with the methodology defined in [12], guaranteeing that a fair comparison with future results reported by Industry for similar use cases will possible. Further, the industrial production efficiency could be evaluated, by mapping the empirical wireless performance to the operation of the underlying industrial process [13]. Scalability tests could also be performed, in case they are relevant for the targeted use case. Ideally, similar tests should be done over other suitable wireless technologies (i.e., 4G, Wi-Fi), in order to benchmark their performance with the 5G one and estimate the potential gains achieved by operating the application over 5G.

STEP 6.

Optimization: this final step deals with the potential enhancements in those areas of the system identified based on the analysis of the outcome of the different performance tests. Depending on the results, optimizations could take place in different domains: at the machinery side, in case it is detected that an optimized performance would be feasible by a slight re-architecture of the industrial control network or by a slight tuning of parameters in the control communication protocols; at the 5G network side, by optimizing the radio interface for the specific targeted application by tuning of 5G configuration parameters; or at the 5G-application integration point, in case it is identified that changes in the integration hardware or software are needed.

Once STEP 6 in the applied operational flow is completed for a given application, this should be ready to integrate and deploy with the operational production system within the factory. Then, it is possible to go back to STEP 1 and re-initiate the flow after re-evaluating what the new needs of the factory would be after the successful completion of the previous iteration. The introduction of a wireless link may affect the entire networking ecosystem in a factory (eventually unleashing new opportunities for running wirelessly other applications involved in the same control network infrastructure), and therefore the integration of such other application and their potential conversion to wireless should be considered in the next iteration. This converts our operational flow into a circular loop, and makes the proposed experimental operational framework compatible for direct integration with those digitalization methodologies such as the AAU 360 DMA [6], briefly addressed in Section 1. Our integration methodology is flexible enough to be applied to any application at any level digitalization level. Furthermore, despite the fact that in this paper we illustrate and apply it mainly within a 5G context, our framework is technology-neutral. We believe that multiple wireless technologies will co-exist within the industrial ecosystem, and this makes our integration framework unbiased as compared to, for example, those that specific network providers interested in selling a given technology might suggest.

3.2. Industrial Research Lab Facilities

Ideally, all steps in the proposed operational flow should take place at the operational factory. However, this is not always a possibility as one may need to interrupt the manufacturing process for experimentation, which might have a negative impact on the productivity. In some cases, factories might even not have a 5G network deployed at the time when they begin to get interested in the potentials of 5G and how it could be applied for their manufacturing use cases. Therefore, having an industrial research lab with 5G capabilities where STEP 3 and beyond of our proposed flow could be executed is of paramount importance. In some specific cases, even STEPS 1 and 2 could take place in the lab, as sometimes it might be possible that representatives from the factory will visit the lab, tell about their digitalization plans and bring some of the pieces of their manufacturing system that they would like to integrate with 5G, e.g., robotic arms, programmable logical controllers (PLCs), AMRs, sensors and actuators, etc.

In those cases where 5G is already available in the factory, the practical 5G integration can take place at either place. For example, for the practical work done in STEP 4, initial efforts can be done at the research lab and, once the system is tested to be stable, the integrated version can be deployed in the factory. This will reduce significantly the impact on the manufacturing process as there would be no need for the factory to interrupt the production for experimentation.

The industrial research lab used in connection with the proposed framework is the “Aalborg University 5G Smart Production Lab”, which is a small-scale industrial factory environment composed of two halls, equipped with a wide range of operational industrial-grade manufacturing and production equipment including production lines, welding machines, robotic arms, etc. The key aspect of this research lab is that it is further equipped with a selection of the most advanced wireless technologies from multiple operators and vendors, which are fully available for our integration and testing efforts. Overview pictures of the two industrial halls of the research lab and the different wireless network deployments are shown in Figure 2.

In particular, the industrial research lab is equipped with the following state of the art wireless research networks:

• 1× 5G NR private network (5G pNR), 3 cells.
• 1× 5G NR dedicated operator network slice (5G dNR), 3 cells.
• 2× 4G LTE private networks (4G pLTE), 3 cells each.
• 1× 4G LTE dedicated operator network slice (4G dLTE), 3 cells.
• 2× Wi-Fi 6 networks, 3 cells each.
• 1× industrial wireless LAN network (IWLAN), 3 cells.
• 1× LoRaWAN network, 1 gateway.
• 1× ultra-wideband radio positioning system (UWB), 16 anchors.

Having such a lab with such a selection of industrial equipment and wireless networks is an advantage for us when implementing the integration framework, as it offers a high degree of flexibility and possibilities with respect to choosing where a given step of the operational framework flow should take place. Specifically in STEPS 5, the lab offers a controlled test environment that allows to follow the guidelines from [12] for performance testing of I4.0 use cases over 5G in real-world conditions. Further, the performance achieved over 5G could be benchmarked with that achieved over 4G or Wi-Fi, for example, providing additional input into the suitability of the different wireless technologies for operating a given use case. Similarly for STEP 6, the lab network controlled environments will facilitate performing some optimizations before moving the use case to production in the factory. Further, our research lab can be used an exhibition room where the operational 5G-integrated prototypes can be showcased to Industry, helping in generating trust on wireless when applied to manufacturing.

3.3. 5G Hardware and Software Prototyping Tools

In order to execute our work throughout the different phases of the experimental operational flow, we developed a number of customized hardware and software prototyping tool devices:

• Network traffic sniffer (NTS): intended to log all data passing through an ethernet interface and extract relevant network traffic statistics.
• 5G Emulator (5GE): aimed at introducing controlled delays into an ethernet link to imitate the communication performance of a wireless technology, e.g., 5G.
• Wireless multi-access gateway (WMAGW): designed as the main integration element to enable the wireless transport, e.g., over 5G, of data traffic from a given ethernet-based interface.

Although there currently exist commercial devices such as network traffic analyzers [14,15,16], network emulators [17,18,19] and 5G industrial devices [20,21,22], with somehow similar purposes and characteristics to the ones custom-developed by us, this was not the case at the time when our 5G integration experimental activities were initiated 4 years back. As it will be explained later for each of the individual prototypes, our custom designs offer us some benefits and flexibility that would not be possible to obtain by using commercial devices.

Our reference designs consider ethernet interfaces for integration to the industrial machinery, as most of the industrial applications that will make use of 5G are currently operating over ethernet cables [23,24]. However, it should be noted, that the design could be slightly adjusted to be integrated with other interfaces such as USB or fieldbuses.

As illustrated in Figure 3, the NTS and the 5GE have a very similar functional structure. Both devices shared an identical hardware (HW) configuration with two bridged ethernet ports that operate by forwarding the data input at one end to the other end. Their software (SW) implementation is, however, different. The NTS (Figure 3a) works as a “man-in-the-middle attack” [25] by executing a SW that logs relevant information from all the L2 and above data traffic packets passing through the bridge interface. Only headers are recorded. No packet inspection is done in order to preserve the confidentiality of the potential business-critical data contained in the payload of the control data messages flowing across the logged ethernet interface. The main use of the NTS box within the operational flow is done in STEP 2, when the data traffic analysis of the selected industrial application is performed. Compared with existing commercial network traffic analyzers, our NTS has similar form factor and functionality to the one developed by ProfiTAP [14]. Other network traffic analyzer solutions such as the ones from CISCO [15] or Solarwinds [16] are much more enterprise-oriented and offer extensive analysis suites, which makes perfect sense for live enterprise network monitoring but would be an overkill for our traffic characterization purpose. The main advantage of building our own analyzer is that the developed SW can be targeted to extract only relevant parameters of our interest such as number of flows, protocols, packets sizes, or packet inter-arrival times, without logging any payload with factory-critical information. This custom and controlled implementation plays in our favor as some of factories would not allow to connect commercial tools that logs and analyzes all their traffic uncontrollably.

The 5GE (Figure 3b) implements a different SW that introduces specific delays to the bridged communication link. The packets received by the 5GE are restrained for a pre-configured delay which is obtained from the uniform sampling of a specific delay distribution pre-loaded from a configuration file. The 5GE can be configured to emulate the delay performance of different wireless technologies by simply loading specific files containing distributions of empirical delay samples for a given technology, e.g., 5G. Such files are generated by storing empirical samples from real-world lab traces such as the private 5G Rel. 15 ones obtained in [9], or from simulations for those technologies that are not available in the lab, e.g., 5G ultra reliable and low latency communication (URLLC). The interval at which the device adjusts the delay values is fully configurable, although it has not yet been possible to adjust it in a per-packet basis, due to HW limitations. The current implementation adds similar delay in both communication directions, although it should be possible to adjust the SW implementation to introduce different delays for different directions. The 5GE can be used mainly in connection with STEP 3 in the operational flow to estimate the performance of the selected use case over a given wireless technology and validate the suitability of the selection. The 5GE constitutes a simplified intermediate solution between a 5G radio channel network emulator like the one from Keysight [17] and an ethernet network emulator such as the ones from Spirent [18] or iTrinegy [19]. The main benefit from the 5GE as compared to those commercial devices is that we can emulate 5G performance over ethernet-based links based on empirical traces obtained by ourselves in realistic and controlled operational conditions, without having to rely on pre-configured delay and jitter settings or standard channel models. To date, our 5GE implementation only allows for emulation of a single 5G link, while commercial tools are capable of emulating larger networks consisting of multiple links.

Both devices are “plug & play” and their operational procedures are very similar. In order to plug the NTS or the 5GE into industrial machinery as shown in Figure 3c, the target ethernet cable should be disconnected from the machinery (e.g., PLC in the picture) and connected to the one of the ports of the device (e.g., the orange cable that spans from the top to the bottom of the picture). Then, the other port is connected back to the machinery with the original PLC Ethernet cable (e.g., the green cable in the middle of the picture that connects to the network switch on the left). Once the device is installed, it should be powered on and it will automatically begin its operation. As a practical recommendation, the NTS and 5GE should be used over the machinery for a time long enough to capture at least one full production cycle in the system as this would ensure that the data traffic analysis or the 5G emulation captures all possible communication states.

The functional architecture of the WMAGW is displayed in Figure 4a. As detailed in the diagram, the WMAGW enables two different modes of connectivity: IP-based mode or L2-tunnel mode. The use or one or the other mode depends on the characteristics of the selected industrial application and its associated communication requirements, and the capabilities of the machinery that the WMAGW device will be plug into. By using the WMAGW in L2-tunnel model, we ensure that all traffic at all layers running over the ethernet interface of the production machinery is transported over wireless, e.g., 5G. This is done by encapsulating the incoming ethernet frames into UDP packets, which are later routed over the wireless port interface of the source WMAGW towards a destination WMAGW. The data sent over 5G is received at the destination WMAGW via its wireless interface, where the UDP packets are decapsulated into ethernet frames and sent over the ethernet port of the device into the ethernet interface of the production machinery. If all data control traffic in the selected application is IP-based and there are no L2 control mechanisms implemented in the system (i.e., broadcast), the IP-based mode can be used instead. This mode simplifies the integration setup and the use of the WMAGW as the SW is more computationally efficient than for the L2-tunnel mode, since we are simply bridging the ethernet and wireless interface of the gateways and establishing routing paths, but its application is not always possible especially when addressing legacy production control systems.

WMAGWs are used from STEP 4 and above of the operational framework flow. When utilizing the WMAGW in device-to-device communication mode, two boxes are needed; one at each of the machinery devices that are to be connected over 5G. In the case of addressing a centralized infrastructure-mode case, e.g., enabling the 5G communication between a production station and a factory controller located in a server room, only one physical WMAGW device is needed and deployed at the machinery side, while at the other end only the SW is deployed to encapsulate/decapsulate the data.

The implemented functional architecture of the different boxes is the same in all different evolution versions (v). However, the specific choice of HW components has evolved throughout our industrial research and experimentation activities and might be different from version to version, leading to different form factors, as illustrated in Figure 4b,c for two different versions of the WMAGW (v2 and v3). As a reference for the different designs, Table 1 summarizes the main hardware and software components implemented in the latest versions of the different devices.

In the specific case of the WMAGW, the modem and antenna configuration might be different depending on the HW version and the intended use of the device. The WMAGW (v3) allows for the installation of up to four modems, and in its reference design (displayed in Figure 4c) builds up two 5G modems and two Wi-Fi six modems. With this configuration, the WMAGW allows for operation over either of the technologies individually, using one or two paths, or over both technologies enabling multi-access multi-connectivity (for increased reliability) [26]. The flexibility in the choice of operational modems and technologies is a key advantage compared to the industrial devices in the market such as the ones from HMS [20], SIEMENS [21] or Robustel [22] which typically implement and support only closed configurations. Further, the state-of-the-art 5G equipment for industrial use is still undergoing its initial commercialization phase and it is not mature enough yet and might not operate fully as expected. Currently, commercial devices might experience some of the same challenges that we typically encounter in our integration research. Initial interfacing with recently deployed and configured 5G networks typically results in connectivity issues or performance instability that requires dedicated debugging and firmware updates and tuning. Thus, being in control of the full device implementation, as it is the case with the WMAGW, is of great advantage. Being in control of the SW implementation also plays in our favor when, for example, 5G connectivity is stable but debugging is needed for the advanced L2 tunneling or multi-connectivity schemes.

Table 1. Summary of main hardware and software components, and other relevant characteristics for the different prototyping devices.

Prototype	Hardware	Software	Other Characteristics
NTS	Raspberry Pi 4 Model B [27]	tcpdump 4.99 [28]	HW TAP functionality
(v2)	Broadcom BCM2711, [email protected] GHz/4 GB		Network transparent
	OS: Raspberry Pi OS Lite
	NIC: Realtec USB3.0/Gbps ethernet adapter
5GE	Raspberry Pi 4 Model B [27]	netem 2.6 [29]	Multi-technology support
(v2)	Broadcom BCM2711, [email protected] GHz/4 GB	Custom delay generation	Network transparent
	OS: Raspberry Pi OS Lite
	NIC: Realtec USB3.0/Gbps ethernet adapter
WMAGW	Gateworks Newport GW6404 [30]	Custom multi-access tunnel	Auto-network discovery
(v3)	Cavium OcteonTX8, [email protected]/2 GB	Custom IP bridge	Multi-connectivity support
	OS: Ubuntu 20.04.2		Gbps/USB3.0 support
	NIC: Gbps ethernet port		L2 BC/MC support
	5G modem: QUECTEL RM500Q [31]		5G SA/NSA support
	5G modem: SIMCOM 8200 [32]
	5G modem: SIMCOM 8300G [33]
	Wi-Fi 6 modem: Intel AX200NGW [34]

Table 1. Summary of main hardware and software components, and other relevant characteristics for the different prototyping devices.

Prototype	Hardware	Software	Other Characteristics
NTS	Raspberry Pi 4 Model B [27]	tcpdump 4.99 [28]	HW TAP functionality
(v2)	Broadcom BCM2711, [email protected] GHz/4 GB		Network transparent
	OS: Raspberry Pi OS Lite
	NIC: Realtec USB3.0/Gbps ethernet adapter
5GE	Raspberry Pi 4 Model B [27]	netem 2.6 [29]	Multi-technology support
(v2)	Broadcom BCM2711, [email protected] GHz/4 GB	Custom delay generation	Network transparent
	OS: Raspberry Pi OS Lite
	NIC: Realtec USB3.0/Gbps ethernet adapter
WMAGW	Gateworks Newport GW6404 [30]	Custom multi-access tunnel	Auto-network discovery
(v3)	Cavium OcteonTX8, [email protected]/2 GB	Custom IP bridge	Multi-connectivity support
	OS: Ubuntu 20.04.2		Gbps/USB3.0 support
	NIC: Gbps ethernet port		L2 BC/MC support
	5G modem: QUECTEL RM500Q [31]		5G SA/NSA support
	5G modem: SIMCOM 8200 [32]
	5G modem: SIMCOM 8300G [33]
	Wi-Fi 6 modem: Intel AX200NGW [34]

Capabilities and Calibration of the 5G Prototyping Tools

A thorough calibration was done for each of the boxes in order to ensure a correct and reliable performance, quantify their capabilities, and understand their potential limitations. In the following, a number of calibration test results are presented, illustrating mainly the processing delay introduced by the devices in operational conditions. The NTS, 5GE and WMAGW were tested by feeding data traffic into the systems under different configurations of packet sizes and packet inter-arrival times (PIAT) and benchmarking the output against the input in terms of latency and throughput. A total of 18 different realizations with different traffic input configurations were tested for each device by sweeping over the combination of 6 different packet sizes (64, 128, 256, 512, 1024 and 1470) bytes (B) and 3 packet inter-arrival times (PIAT) (1, 10 and 100) ms. Calibration test results were collected over a long-enough time of operation to guarantee that we had enough statistics to claim a reliable accuracy up to the 99.9% level, i.e., 10⁻³ level in the below complementary cumulative distribution functions (CCDF) [35]. To achieve enough statistical confidence at such reliability levels, more than 100,000 samples were collected per realization, fulfilling the requirements set by normal approximation of the Binomial distribution [36]. Further, the results illustrate the statistical distribution when considering all samples from all realizations as well as the difference between best/worse realizations to give an overview of the variability of the system.

As the NTS is typically used in connection with operational industrial machinery, it is important to verify that its use does not impact excessively the performance of the underlying industrial control communication processes while the data traffic is being logged. As illustrated in Figure 5, the processing delay introduced by the NTS device in operational conditions is bounded to 0.45 ms, which would not affect significantly the analyzed control traffic as the introduced latency is deterministic (with small jitter <33 $\mathsf{\mu }$s). This jitter sets the practical limitation to what the minimum possible PIAT measured in with the NTS is. Based on the calibrated performance, it can be concluded that industrial operational machines, over which our NTS box is used, will continue to operate reliably as long as the survival-time of the underlying control protocols can tolerate a small misalignment when our device starts to function.

In the case of the 5GE, as the device will be used to emulate the performance of a 5G link between two devices, apart from the processing delay of the device itself, the correctness of the generated delay outputs needs to be validated. Figure 6 displays the results of the latency tests for two different configurations: one where no delay was added, so that the processing delay could be determined, and another one where a 1 ms constant offset delay distribution is configured (i.e., values are read from a file containing 100.000 delay samples of equal value of 1 ms), in order to confirm the correct performance at the output over a constant reference. The calibrated processing delay of this device is very similar to the one observed for the NTS. This is, essentially, due to the fact that both devices are built over a similar HW configuration with a slightly different SW implementation due to their different functionalities. When the specific 1 ms delay distribution was applied to the emulator, the output was shifted by 1 ms, as expected, validating the main functionality of the device. A similar deterministic behavior was observed with/without input, although a slightly larger best/worse case variability was observed in the case the specific delay distribution was applied. This is mainly due to the extra SW execution time introduced by the implemented uniform sampling mechanisms at configured delay re-configuration intervals (100 ms in this test case). In any case, this variability is limited (<80 $\mathsf{\mu }$s), which ensures that no excessive artificial jitter is introduced, limiting the potential distortion of the device over the input delay distributions, and resulting in a reliable delay emulation.

Finally, the performance experienced when utilizing the WMAGW devices for transmitting data traffic over the configurable L2-tunnel was examined. The total processing delay introduced by the two devices that set up the ends of the tunnel is considered in Figure 7. In this case, despite of having the combined effect of the processing delay introduced by the encapsulating and decapsulating devices, the delay is bounded by 0.4 ms at the 99.5 percentile (10^−2.5). This reduced delay as compared to the one in the NTS and 5GE devices is explained mainly by the different HW choice as, as indicated in Table 1, the WMAGW (v3) is implemented over a Gateworks Newport GW6404 [30] single board computer, with higher processing power capabilities than the one of the Raspberry Pi Model 4B [27] over which the NTS (v2) and the 5GE (v2) operate. As a reference, the processing delay performance of the L2-tunnel when implemented with the previous Raspberry Pi-based WMAGW HW version (v2) is also displayed in the figure. In that case, as expected, the overall processing delay was bounded by ~0.75 ms (approximately twice the maximum processing delay of the NTS and 5GE). The good average processing delay performance in the WMAGW (v3) is slightly worse in some cases, where the processing delay can increase from 0.5 to up to 1.5–2 ms. This happens, at most for 0.5% of the packets transmitted over the tunnel (out of 1000 packets, only five will experience a slightly increased processing delay). As further implementation-specific details, it is of interest to report that, currently, approximately 60% of the WMAGW L2-tunnel processing delay comes from the transmission side of the tunnel where VLAN tagging and the encapsulation takes place, while the 40% remaining is due to decapsulation and packet forwarding at the reception side. There is still some room for SW enhancements, processing coordination, and execution optimization, and future versions of the WMAGW will improve further the processing delay to ensure deterministic performance at all reliability levels.

As the WMAGWs are connectivity prototype devices, it was also necessary to make a more detailed analysis of the supported traffic characteristics. A maximum throughput test was performed in this case, trying to push as much data traffic as possible through the L2-tunnel by sending constant-size packets of (64, 128, 512, 1024 and 1470) B with short PIAT intervals ranging from 10 to 100 $\mathsf{\mu }$s. Figure 8 displays the results of the maximum throughput test for the different combinations of packet size and PIAT in terms of packet loss. Our WMAGW (v3) devices support reliably the encapsulation/transmission-reception/decapsulation of data packets with sizes of up to 1470 B and a minimum PIAT of 40 $\mathsf{\mu }$s. For more demanding traffic patterns with shorter PIAT, packet loss would start to happen due to HW buffering limitations. Therefore, the maximum throughput supported by the WMAGW devices in L2-tunnel mode is limited to 294 Mbit/s.

It should be emphasized that the reported WMAGW performance applies to the L2-tunnel mode of operation. When the WMAGW is operated in IP-based mode, the overall link processing delays will be shorter as bridging is a much less processing power-demanding operation than the encapsulation and VLAN tagging operations. Further, in the IP-based operation mode, the maximum supported throughput will not be depending on SW, but mainly on the board and wireless modem HW interfaces. Therefore, in IP-based mode, the WMAGW (v3) can support a throughput of up to 480 Mbit/s.

Based on the calibration test results, we guarantee the compatibility of our prototype solutions with most of the IIoT applications in terms of data traffic [37]. For quick reference,

Table 2. Calibrated operational performance specifications of the implemented prototypes.

Prototype	Processing Delay	Jitter	Max. Supported Throughput
NTS (v2)	0.45 ms	33 $\mathsf{\mu }$s	N/A
5GE (v2)	0.47 ms	33 $\mathsf{\mu }$s	N/A
WMAGW (v3) L2-tunnel	<0.4 ms (99.5%)	103 $\mathsf{\mu }$s	294 Mbit/s
WMAGW (v3) IP-mode	N/A	N/A	480 Mbit/s

summarizes the main operational performance specifications of the different prototypes. Commercial devices are typically implemented on very optimized HW/SW platforms, which guarantees an optimized performance and thus, processing time calibration values are, normally, not reported in their specification data-sheets. With respect to maximum supported throughput, commercial network traffic analyzers and emulators are typically subject to the capabilities of the ethernet input interfaces. With respect to the commercial industrial 5G devices, in IP-mode, the limitation is typically imposed by the capabilities of the selected modems. As in our implementation, the maximum supported throughput is also reduced for commercial devices if some extra SW is executed, i.e., to operate in L2-tunnel mode. As a reference, the HMS 5G device [20] supports maximum 70 Mbit/s when a 5G virtual private network (VPN) connection is established. Our WMAGW prototype supports higher throughput in L2-tunnel mode as no extra link encryption is implemented (we rely fully on the 5G encryption for security), which results in a smaller communication protocol overhead than in the VPN case.

The described prototype tools have been successfully used in connection with different industrial production systems. The NTS has been used for recording several industrial control data traffic traces for various machines such as production cells, or quality inspection systems or in operational factories [9]. Based on those measurements, we could further validate the correct and reliable operation of the sniffer prototype. Data flow from protocols such as delay-tolerant industrial control protocols like OPC-UA or CIP, but also other more time-critical such as PROFINET, were successfully logged for several hours without detecting any disruption in the operation of the machinery [38]. To date, the WMAGW devices have been used to successfully operate, over 5G (also Wi-Fi and 4G), the control of an operational production line by providing over 5G wireless the connectivity between a factory manufacturing execution system (MES) controller and the different programmable logical controllers (PLC) present inside of each of the stations of the line [9,39,40].

4. Framework Applicability Example: 5G Autonomous Mobile Robots

In this paper, we exemplify the application of the proposed experimental framework on the integration of 5G technology to one of the most important IIoT applications: autonomous mobile robots [41].

4.1. 5G-Connected Autonomous Mobile Robots

Following the steps of the proposed industrial automation research flow, the 5G-integration of AMRs was done as follows:

STEP 1.

An AMR manufacturer would like to start exploring the integration of their products with 5G technology. For mobility reasons, autonomous mobile robots are wireless-native elements. However, as current AMR products operate over Wi-Fi, which presents issues in terms of reliability and scalability when applied to mobile applications [42], optimized alternative are to be explored. AMR vendors are, in general, aware of the techniques for optimizing Wi-Fi performance, however, the products that they sell to their customers will operate over the Wi-Fi networks of the customers, which status remains unknown and might be unoptimized in many cases. Apart from the increased reliability, having 5G-compatible versions of their products would create new business opportunities for AMR vendors.

STEP 2.

In this case, our industrial partner brought some of their AMR products and related control elements such as the fleet manager (FM) to our lab. The control elements and system architecture were open for us so that we could perform a thorough data traffic analysis of its mode of operation. The targeted AMRs are managed from the centralized FM deployed at infrastructure-side (typically in a server room) and accessible via the Wi-Fi network. From the FM, it is possible to send specific missions with automated paths or set waypoints to navigate to for the AMRs. Although, as wireless-native components, AMRs are based on a wireless-wired hybrid architecture, different from that of the standard static production industrial use cases based only on a wired architecture, the framework can still be applied by identifying the relevant communication interfaces that are subject to be integrated into 5G. In this case, thus interface was the standard AMR communication interface (the same that is used currently in the Wi-Fi version of the product), over which the data traffic flowing was analyzed with the help of the NTS device. We observed that control-loops between the AMR and the FM are executed once per second, and they make use of the TCP protocol with average packets sizes of 4 kB and 100 B, in FM-AMR and AMR-FM communication direction, respectively. The total throughput of the AMR application is, therefore, approximately 32 kbit/s (for a single robot).

STEP 3.

Based on the throughput, packet sizes and inter-packet times values, it was clear that the current AMR implementation is suitable for operation over 5G and its better mobility and reliability support should result in an improved performance of the AMRs in standard mobility operation conditions than when operated over Wi-Fi.

STEP 4.

To integrate the AMR with 5G, a WMAGW (v3) was used. The prototype device was interfaced to the standard communication interface of the AMR by following the 5G-integrated architecture illustrated in Figure 9a. The WMAGW was configured in IP-mode to operate in infrastructure mode to route the control data traffic between the AMR and the FM. In this case, as the architecture of the use case is quite simple, and there are not many communication flows, the IT integration and debugging of the 5G-integrated solution was quite quick. A picture of the deployed 5G-integrated AMR solution is shown in Figure 9b.

STEP 5.

To validate the correct operation of the 5G-integrated application, a performance test was carried out. The test was performed by having the AMR automatically navigating within the lab over the measurement route indicated in Figure 9c. This specific route was chosen to ensure that the AMR was navigating across the multiple 5G cells and guarantee that a proper assessment of the attachment/re-attachment to multiple cells and the connection reliability in mobility conditions was done. The performance of the control of the AMR over 5G was compared to the one over different Wi-Fi configurations. The performance tests focused on two main different domains: control-loop latency performance and packet error rate. The results from the tests are displayed in Figure 10. Given the communication requirements of the AMR, with expected control loops every 1 s, all control-loops with latency higher than that will make the AMR stop and enter in a momentary outage. As indicated in the results, no outage was experienced for the 5G-integrated solution, which exhibited a reliable deterministic performance with median control-loop latency of 11 ms and lower than 25 ms at the 99.9 percentile (10⁻³). This was, however, not the case for Wi-Fi 5/6, over which control-loop latencies higher than 1 s were experienced during 0.1–0.3% of the time in those cases where no frequency planning was considered (which resembles the typical Wi-Fi deployment situation in operational factories where the AMRs are expected to operate). During these outage occurrences, control-loop latencies close to up to 10 s were observed. These long control-loop latencies will keep the AMR stopped and non-operational for a few seconds every time they happen, which will have an impact of the underlying industrial production process in which AMRs are involved. The performance of the AMR over optimized Wi-Fi 6 and ideal frequency planning (i.e., dedicated spectrum channels per access point) was also observed to fulfill the control-loop requirements for the given use case. However, such performance was less deterministic than the one observed for the 5G-integrated solution. While a median control-loop latency, better than the 5G one, of 5 ms was observed; the value at the 99.9 percentile is increased to over 0.5 s, illustrating the higher reliability of 5G as compared to Wi-Fi. Further, the 5G-integrated solution experienced no packet loss, while in the Wi-Fi case, the PER was 0.4–0.26%.

STEP 6.

Once it was verified that it is possible to operate AMRs over 5G, the next step would be to look into potential optimizations. Based on the experimental results and the practical observations done along the different operational steps, the potential areas of optimization for the 5G-integrated solution could be: the parametrization of the 5G network configuration to optimize the control-loop latency and reduce the tails of the distribution, or the re-design of the AMR communication schemes to make them more efficient and scalable when operated over wireless in general, or over 5G in particular.

By completion of the operational flow, it was demonstrated the 5G-integration of AMRs. Apart from the commented optimizations, having 5G-connected AMRs opens for new possibilities within the same application ecosystem, such as making use of the 5G capacity and contained latency to migrate some of the intelligence from the AMR to the 5G mobile edge-cloud (MEC).

4.2. 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:

STEP 1.

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.

STEP 2.

The AMR vendor provided us with an external planner unit and re-architectured 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 11a, and can be compared for further reference to the standard AMR architecture in Figure 9a. 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.

STEP 3.

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 5GE 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 5GE, 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. In the navigation test, a mission was configured to make the AMR navigate over an obstructed route between two selected waypoints within the lab, ensuring that the robot needed to re-plan its path upon detection of the obstacle. The route was covered 40 times in order to ensure that the overall mission times were long enough to observe any potential differences between the reference operation with cabled planner and the 5G-emulated one. For the docking accuracy test, the robot was set to execute a docking maneuver into its charging station from a starting point located at 1 m distance. This test was repeated 15 times in order to obtain an insight into the average experienced accuracy over 5G as compared to the REF. The docking accuracy was evaluated with the assistance of an external optical positioning system with mm-accuracy [44]. The results from the navigation performance tests are presented in Figure 12a, and they indicate that a very small increase in navigation time of 1.5% is expected in the worst case with the 5G MEC planner as compared to its reference operation with the on-board planner. For the docking accuracy test, the results are shown in Figure 12b, and they illustrate that the use of the 5G MEC planner would result in a slight loss of accuracy of maximum 1–3 mm, which would be negligible for reliable operation of the AMRs.

Upon completion of STEP 3, where it was demonstrated by emulation that the AMR would continue to operate in an accurate and reliable manner when having its planner operating in 5G edge-cloud configuration, it would be time to move to the 5G-integration and deployment in STEP 4. However, no further details will be reported for this specific case as the work is still ongoing.

5. Considerations for Future Framework Versions

It has been demonstrated that applying the experimental framework leads to successful integration of 5G into industrial applications. In its current shape, the considered operational flow, prototyping tools and research lab environments, provides enough capabilities for compatibility with 5G Rel 15. However, for future 5G releases, such as those introducing URLLC features and close-to-ms control-loop supports [45], the hardware and software of the prototypes (especially the WMAGW) would need to be adjusted in order to improve, mainly, the processing delays. To achieve this, the HW prototypes will be evolved from the current central processing unit (CPU)-based designs to field-programmable gate array (FPGA) architectures to ensure an optimized processing performance. Using FPGA-based HW elements will require the development of new dedicated SW, as not all the functionalities of the CPU-based SW will be compatible with the new architecture. Such upgrade to high-end performance devices will also ensure that our future HW prototypes will be capable of supporting the integration with time-sensitive networks (TSN) aimed at the control of real-time streams with deterministic delay support [46].

The research lab would also need to be upgraded, in order to include all those 5G network release upgrades. In particular for the lab, 5G base stations with mm-wave FR2 support is seen as an essential evolution step. Under the current 5G lab deployments, operating in sub-6 GHz FR1 spectrum, available capacity might be limited for certain I4.0 applications, especially those demanding high uplink throughput for many devices, e.g., the industrial visual quality inspection based on computer vision [47]. In terms of operational flow, no updates are foreseen in the near future. The operational integration steps are described in a detailed, flexible and technology-unbiased style, which ensures the compatibility with different technologies, industrial use cases, and other reference frameworks.

Security has not been explicitly addressed in our experimental framework, as our main focus is on the 5G integration and connectivity aspects, while security is mainly addressed at higher levels [48]. 5G security in I4.0 application scenarios will depend on various aspects such as the specific flavor of 5G network deployment. A fully private 5G network deployment will have the security advantage of being isolated from the exterior (although Internet access might exist via a secure firewall), while other 5G deployments for industrial use, such as dedicated network slices, will rely on several external network elements, and as such extra security measures need to be taken [48]. 5G radio communication makes use of encryption and is secure by design, and thus the main security challenges arise mainly from the networking perspective of the integrated end-to-end 5G-operational technology networks [49]. In this respect, our WMAGW will play a role and, thus, should be a secure interface at a similar level of current critical industrial networking infrastructure such as router or switches. Therefore, control access through physical and remote-logical interfaces should be protected by strong credentials. In terms of operation, our WMAGW should be already capable of transmitting ethernet traffic protected by high-layer cryptographic protocols such as DTLS over 5G. However, future developments in terms of industrial networking will be followed in order to ensure that our device continues to perform reliably when operating new secure ethernet protocols such as OPC-UA.

Although not related to the current integration framework itself, the experimentation could lead to identifying and highlighting potential bottlenecks of current 5G networks and, therefore, provide input to wireless, manufacturing and also automation&control engineers and researchers. Wireless researchers could then address such limitations in future radio technologies, e.g., 6G [50], while manufacturing and automation&control researchers could adapt their application and control algorithms to the wireless capabilities. Furthermore, joint manufacturing, communication and control co-design is to be explored.

6. Conclusions

This paper presented an experimental framework for 5G wireless system integration into industrial applications, aimed at providing service to industries, motivated from the lack of digitalization reference models considering in depth wireless performance integration and performance. The presented experimental framework consists on an operational flow that describes the different steps to be applied to move from the understanding of the needs of a factory, to the deployment and optimization of 5G-integrated applications. The framework is complemented by a number of prototyping tools: a network traffic sniffer, a 5G emulator, and a wireless multi-access gateway, which are of a great utility throughout the integration process. The prototyping devices have been carefully designed and calibrated to ensure an optimal behavior and a negligible impact when interconnected with operation industrial machines.

Further, this paper exemplifies the application of the framework on a real industrial use case: the 5G-integration of autonomous mobile robots. Two looped runs of the operational flow are applied: the first focusing on the overall 5G control of the robots, and the second one focusing on the 5G mobile edge-cloud operation of the robot path planner. In both cases, the potential of 5G for operating reliably the use case of autonomous mobile robots was demonstrated. It was also shown how the 5G operation of the robots was superior in terms of control-loop reliability to the one of Wi-Fi 6, which resulted in several robot outages of a few seconds.

The current flow, prototyping tools and lab environment are proven to be effective at current, but the experimental framework will need to continue evolving in order to support the integration of future 5G releases, time-sensitive networks, ultra-low latency control-loop features, or even future more advanced wireless technologies such as 6G.