# An Experimental Framework for 5G Wireless System Integration into Industry 4.0 Applications
## 3 Experimental Framework for 5G Integration
### 5G Hardware and Software Prototyping Tools
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 \(\sim\)0.75 ms (approximately twice the maximum processing delay of the NTS and 5 GE). 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. Figure 6: CCDF of the processing delay introduced by the 5 GE device in operational conditions. Figure 7: CCDF of the total processing delay experienced in L2-tunneling operational conditions (with two WMAGW devices). 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 \(\upmu\)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 \(\upmu\)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 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.