# Performance Evaluation of UAV-Enabled LoRa Networks for Disaster Management Applications
## 4 Performance Evaluation
Furthermore, one can observe that the difference between the packet reception rate of the proposed solution and that of [24] grows for a larger number of UAVs in the network. This is one of the most critical aspects of the proposed solution is that the high packet loss might be too penalizing for a critical application. Even when just 60 GNs divided into three teams are deployed and 12 UAVs are used, the packet loss is above 20%. This is the drive that brought to the development of the CRM and MP algorithms. \begin{table}
\begin{tabular}{c c} \hline \hline
**Simulation Parameter** & **Value** \\ \hline Total simulation time & 2000 s \\ Tx Power & 14 dBm \\ Bandwidth & 125 KHz \\ Packet Size & 10 Bytes \\ GN Speed & 1.3 m/s \\ \(P_{shared}\) & 0.5 \\ \(t_{load}\) & 180 s \\ PHY protocol & IEEE 802.11 g \\ Frequency & 2.4 GHz \\ Receiver sensitivity & \(-\)99 dBm \\ \(\Delta T\) & 10 s \\ \(t_{AG}\) & 40 s \\ \(LB_{req}\) & 20 dBm \\ \(P_{max}\) & 30 \\ \(k_{max}\) & 3 \\ \(s_{thr}\) & 0.6 \\ UAV altitude & 60 m \\ \(t_{lost}\) & 180 s \\ \(t_{r}\) & 40 s \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Simulation parameters and their values. \(K_{p}\) is not only influenced by the number of teams, but also by the number of GNs per team, as it is possible to observe in Figure 6. The figure shows the AE-PRR of two simulation scenarios: one having 3 teams of 10 GNs and the other having 3 teams of 40 GNs. Compared with the results reported in Figure 5, in the scenario with only 10 GNs per team, the system behaves better with a lower \(K_{p}\) (range [5; 10]). On the contrary, in the scenario with 40 GNs per team, the system performs better with a higher \(K_{p}\) (range [45; 50]). This shows that a higher density of GNs moving in the same area requires bigger values of \(K_{p}\) to obtain the best AE-PRR results. Figure 5: Average End-to-End Packet Reception Rate (AE-PRR) versus \(K_{p}\) for (a) 3 teams of 20 GNs (b) 4 teams of 20 GNs (c) 5 teams of 20 GNs. It is also interesting to study the trend of the Average Total Delay (ATD) which is expressed as the average delay of packets sent by GNs to the BS through UAVs. Specifically, it is the sum of the delay experienced in the LoRaWAN network segment and in the WiFi network segment while it also includes the delay caused by buffered packets. In this regard, a plot is shown in Figure 7 for three teams of GNs. The ATD decreases with the number of UAVs and with bigger values of \(K_{p}\). To understand this behavior, it is necessary to remember that the ATD is computed only on packets that are successfully received by the BS and it takes into account also the time that a packet eventually spends in the buffer. Therefore, in scenarios with few UAVs, the mesh is more subject to disconnections and the bigger number of buffered packets contributes in large part to the big delay. Disconnections and buffering time also explains why lower delays are associated with bigger values of \(K_{p}\): a big \(K_{p}\) favors the compactness of the aerial mesh to the detriment of the coverage. Figure 6: AE-PRR against \(K_{p}\) with 3 teams composed of different numbers of GNs. Figure 7: Illustration of Average Total Delay (ATD) with 3 teams of 20 GNs. This is confirmed by the decreasing trend of the average percentage of buffered packets shown in Figure 8, which is an indication of the probability of disconnections in the mesh. \(K_{p}\) must, therefore, be chosen as a compromise between the desired coverage and delay. The analysis of the other QoS metrics produces some minor observations. In conclusion, \(K_{p}\) proved to be an important parameter that greatly influences the performance of the system. It has, therefore, to be chosen properly depending on the number of UAVs, the number of teams and the number of GNs per team. Configuring \(K_{p}\) might be complex in a real system, due to the numerous variables that must be taken into account. A future study of a \(K_{p}\) optimization routine is, therefore, necessary to simplify the configuration process.