# Inter-UAV Routing Scheme Testbeds
## 3 FANET Testbeds
### Existing Routing Scheme Testbeds  
Authors of [25] performed an end-to-end packet delay measurement and evaluation of OLSR using a network comprised of stationary Raspberry Pi Zeros. Their approach proves the significant benefits of the real-life testing approach, as it enables the measurement of CPU load during routing and packet encryption. Furthermore, usage of power efficient Raspberry Pi Zeros gives insight to how a similar network would perform, should it become mobile. Additionally, usage of this platform as a routing testbed constitutes an indirect evaluation of the Linux kernel efficiency and possible bottlenecking. Random \"dummy\" data is generated using the _ipref_ traffic generator and then embedded in a UDP frame. The source node is configured to transmit the randomly generated data to another Raspberry Pi Zeros functioning as a relay between the source and destination. Due to the network being comprised of only three nodes (source, proxy, destination), no actual routing table is being made use of or updated. Therefore, usage of either a reactive/hybrid/proactive protocol has minimal effect on network metrics. Thus, this testbed implementation is more of a kernel bottlenoking evaluation rather than an actual routing protocol one. Nevertheless, repetition of this experiment using the same setup, only with a greater number of nodes would potentially yield rather important results. Similarly to this work, the researchers in [55] used five Raspberry Pis to evaluate OLSR in a content-centric network (CCN). The difference between this testbed and the one described in [25] is the usage of the networking-oriented Open-WRT operating system. Nodes maintained a constant line of sight (LOS) and proved OLSR's potential as an enabler of a CCN overlay in TCP/IP networks. Researchers in [26] implemented a Raspberry Pi-based testbed for the BATMAN protocol. The hardware testbed was accompanied by NS-3 simulations in order for the authors to validate their results. In this case, actual UAVs were used as sources, relays and end devices alike for each tested scenario. The FANET topologies utilized were the following:  
* Infrastructure topology (Figure 1)
* Mesh topology (Figure 2)
* UAV-as-a-relay topology (Figure 3)  
The infrastructure topology (UAVs as end devices) (Figure 1) dictates that an intermediate ground station functions as a relay, forwarding packets to their respective destinations. Computational load of nodes is thus minimized, to the expense of the network's mobility (limited due to it being a direct function of the ground station's maneuverability). UAVs can only reach a strictly defined distance before link quality between themselves and the ground station falls below a usable threshold. The mesh topology (Figure 2) dictates that at least a UAV is constantly connected to the ground station and functions as a gateway. The difference between this topology and the previously described one is that individual UAVs are networked in a such manner that enables inter-UAV packet relaying. This topology enables greater area coverage and a higher node mobility. The UAV-as-a-relay topology (Figure 3) is technically not a FANET topology, rather a direct UAV-enabled relaying use-case which can be extended to a FANET. It is however noteworthy due to the researchers evaluation of a such relaying method's efficiency and possible bandwidth-saving improvements. The authors of [29] used Alix.3C2 modules equipped with a Voyage (Debian-based) Linux distribution. OLSRd was installed onto the modules and the researchers evaluated both OLSR-HOPS and OLSR-ETX, with they enriched using the ETT metric as mentioned in Section 2.1.1 for higher route computation efficiency. Researchers in [30] implemented a fixed-UAV ad hoc networking testbed and tested it using the DSR protocol. The proposed testbed is comprised of the UAVs themselves, fixed ground stations and mobile ground stations as well.