## 3 Materials, Methods, and Scenario  
In this section, we will explain the testbed and tools employed in this study. By using this deployment, we demonstrate the communication capabilities that FANETs can offer, comparing the performance achieved with various proactive routing protocols, specifically OLSR, BATMAN-ADV, and Babel. The 3 protocols were selected based on the criteria of \"state of the art\" technology, experience working with them, suitability for the proposed scenario, and compatibility with the communications module.  
For this purpose, a WiFi network composed of several UAVs was deployed. Each UAV had a specific communication module (WiTi [75]); see Figure 1a. These communication modules had a dual 2.4/5 GHz communication band, using the IEEE 802.11g standard for the 2.4 GHz band and the IEEE 802.11a standard for the 5 GHz band, and 2 antennas for each frequency band. The tool _iperf3_[76] was employed to evaluate the performance of the different routing algorithms, analyzing throughput and packet losses. To analyze packet losses in an efficient way, the UDP communication protocol was used. In the deployed scenario (see Figure 1b), 5 communication nodes were placed: specifically, 2 UAVs (quadcopters), 2 PCs, and 1 ground node. The 2 PCs were located under the UAVs to simulate devices in a coverage extension scenario. They also allowed monitoring of the network status. On the other hand, the ground node operated as a relay base station, acting as an intermediate node between the drones when the distance between the nodes  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Type** & **Subtype** & **Routing Algorithm** \\ \hline \multirow{7}{*}{Topology-Based} & \multirow{3}{*}{Proactive} & \multirow{3}{*}{ICALAD [11], MLHR [12], DCR [13]} \\  & & & OLSR [16], DSDV [17], BATMAN [18], \\  & & BATMAN-ADV [23], DOLSR [19], P-OLSR [5], \\  & & ML-OLSR [25], COLSR [26], M-OLSR [27], \\  & & CE-OISR [28], TBRP [29], PSR [10], Babel [31] \\  & & DSR [32], AODV [33], S-ACOW [34], \\  & & MAODY [35], AODVSEC [36] \\  & & ZRP [37], TORA [38], RTORA [39], \\  & & HWMP [40], SHARP [41], HRP [42] \\ \hline \multirow{7}{*}{Position-Based} & Reactive-Based & RGR [43], GGF [44], ARPAI [45], MUDMG [46] \\  & Greedy-Based & GPMC [48], MSR [46], GLR [50], GPSR [51], \\ \cline{1-1}  & & GHC [52], GRG [53], GDSTR-3D [54], USMP [51] \\ \cline{1-1}  & & & CRUV [55], UVAR [56], PASER [57], \\ \cline{1-1}  & & & XLinGo [58], SUAP [9] \\ \hline \multirow{2}{*}{Clustering/Hierarchical} & \multirow{2}{*}{CAUNI [59], MPCA [60], LANMAR [61],} \\  & & & MMT [62], CBADSR [63], DIM [64] \\ \hline Swarm-Based & \multirow{2}{*}{BeeAdHoc [65], AntiHocNet [66], APAR [67]} \\ \hline Delay-Tolerant & \multirow{2}{*}{LAROD [68], AeroRP [69], GRAA [70], Epidemic} \\  & & [71], Maxprop [72], Spray and Wait [73], Prophet [74] \\ \hline \hline \end{tabular}
\end{table}
Table 2: A summary of routing algorithms and their classes and subclasses.  
required its use. The relay node was located at 35 m from PC1 (UAV1). Whereas UAV1 was kept at a fixed location, UAV2 flew horizontally, stopping every 10 m to take performance measurements. Each measurement had a duration of 60 s and consisted of sending data between the 2 PCs through the UAVs. Both UAVs flew at an altitude of 10 m, calibrating all distances, positions, and heights with the UAVs' GPS modules. A representation of the deployed scenario can be seen in Figure 2a,b. For instance, this scenario could simulate a situation where a coverage extension is required due to an emergency, to solve a specific moment of overload of the communications network, or for remote surveillance.  
Figure 1: (**a**) UAV with WiFi communication module (WiTi). (**b**) Flying field, “Los Halcones de la Rambla”, Murcia, Spain.