## 5 Results and Discussion  
All of the tests turned out to be satisfactory, first, because the overall network functioning was concerned and, then, because tests metrics were good enough to claim such that a network architecture may potentially find a wide application in a vast set of operation scenarios. Test #1 results are shown in Figure 7. As was previously stated, this test aimed to assess the performances of the LoRaWAN-NB-IoT Gateway in terms of successfully forwarded packets from the Sensor Nodes Layer to the Cloud Layer. Throughout the test, 3724 LoRaWAN packets were broadcast by the LoRaWAN Node and 3006 packets were correctly forwarded by the gateway to the Cloud Layer (i.e., a packet loss 19.28% of was experienced). In light of this, the results of this test can be considered satisfactory,thus validating the effectiveness of the LoRaWAN-NB-IoT Gateway, mainly because of two reasons. On the one hand, LoRaWAN technology implicitly implies a minimum amount of data loss. Therefore, the adoption of the LoRaWAN-NB-IoT Gateway caused a packet loss that can be comparable with the one of the LoRaWAN protocol. On the other hand, apart from few data points, packet loss was predominantly experienced in two different circumstances (i.e., from packet number 593 to packet number 1049 and from packet number 2583 to packet number 2826). Such a phenomenon suggests that losses may be ascribed to a lack of cellular coverage rather than a gateway fault. On the contrary, all of data points related to losses lying outside the aforementioned intervals may be due to Gateway faults. However, there are only 20 instances. Therefore, it can be deemed that the LoRaWAN-NB-IoT Gateway can be a valuable alternative to standard LoRaWAN Gateways whenever the application scenario is devoid of Internet connection. The Test #2 results are outlined in Figure 8. Throughout the test, the master node sent 2216 NB-IoT packets, and it received 2074 responses from the slave within the timeout (i.e., the peer-to-peer subnetwork was effective 93.59% of the times). The mean RTT was \(\mu_{RTT}=3.2733\times 10^{3}\) ms, while the RTT standard deviation was \(\sigma_{RTT}=1.1224\times 10^{3}\) ms. From RTT Cumulative Distribution Function (CDF), it can be noticed that RTT is above \(\mu_{RTT}\), with a probability of 0.6. Though this could be undesirable, the CDF also shows that RTT is less than \(3.4338\times 10^{3}\) ms, with a probability of 0.9725, or that it is less than \(5.0258\times 10^{3}\) ms, with probability of 0.9937. Therefore, the majority of RTTs are close to \(\mu_{RTT}\), thus underlying the good repeatability of such a metric. This is also stressed by the RTT Probability Density Function (PDF), which is highly concentrated near \(\mu_{RTT}\) apart from a few outliers, thus being sensibly leptokurtic. Such outliers are also noticeable within the box-and-whisker plot. Finally, the QQ plot confirms the fact that, besides the outliers, the experimental data adequately follow the distribution \(N(\mu_{RTT},\sigma_{RTT}^{2})\). Of course, the experimental data can never be negative since RTTs are involved; therefore, a perfect overlapping with the aforementioned distribution cannot be obtained. Apart from a few  
Figure 7: Test #1 results. RTT samples that were notably longer than the mean, such a test showed the feasibility and the effectiveness of the peer-to-peer subnetwork, especially because of the experienced RTT values, which can be considered adequate for IoT contexts related to, for instance, monitoring issues within widespread and severe environments. The Test #3 results are highlighted in Figure 9. At first glance, a massive variability with respect to the results of Test #2 can be noticed. However, this is reasonable since this test entailed the sequential usage of both the enabling technologies (i.e., LoRaWAN and NB-IoT) and of the three network layers.