Inter-UAV Routing Scheme Testbeds

Abstract

With the development of more advanced and efficient control algorithms and communication architectures, UAVs and networks thereof (swarms) now find applications in nearly all possible environments and scenarios. There exist numerous schemes which accommodate routing for such networks, many of which are specifically designed for distinct use-cases. Validation and evaluation of routing schemes is implemented for the most part using simulation software. This approach is however incapable of considering real-life noise, radio propagation models, channel bit error rate and signal-to-noise ratio. Most importantly, existing frameworks or simulation software cannot sense physical-layer related information regarding power consumption which an increasing number of routing protocols utilize as a metric. The work presented in this paper contributes to the analysis of already existing routing scheme evaluation frameworks and testbeds and proposes an efficient, universal and standardized hardware testbed. Additionally, three interface modes aimed at evaluation under different scenarios are provided.

1. Introduction

The birth of Mobile Ad hoc Networks (MANETs) has enabled the decentralization of a massive amount of applications and services. Ad hoc networks can now function in a great variety of environments and conditions without necessarily interfacing with the rest of the internet. All cooperating nodes in such networks are considered peers, with a master–slave relationship between them being nonexistent due to the networks fundamental architecture: each node is both an end-device and a router. Vehicular Ad hoc Networks (VANETs) were the first type of MANETs to be deployed, followed by Flying Ad hoc Networks (FANETs) which are the main focus of this paper. Another type of ad hoc networks which present great interest are cooperative VANET-FANET networks, in which UAVs function essentially as relays between vehicles. According to [1,2], FANETs differ from VANETs and other types of (ad hoc) networks in matters of:

• Node mobility (in terms of Velocity/Acceleration/Jerk)
• Topology (FANETs may function in a 3D grid in addition to the more traditional single-layered swarm topology [3]; additionally, a UAV-comprised network shall alter its topology with a significantly higher frequency, due to its nature)
• Availability of energy (arguably the most significant constrain of autonomy in an ad hoc network)

FANETs find application in both military and civilian fields, such as the ones described in [4,5,6,7,8,9,10,11,12,13,14,15]:

• Real time monitoring and surveillance
• Search-and-rescue operations
• Agriculture
• Relaying of communication

As envisioned in [16], while the challenges of swarm formation are numerous (routing, path planning, QoS provision, UAV coordination, etc.), multi-UAV deployments are the future of aerial communications. In surveillance and monitoring applications, routing of information is a means to an end; such is the case in search and rescue-oriented FANET deployments as well as the ones centered around agriculture. High route selection efficiency is mandatory for an acceptable quality of service (QoS) in all mentioned use-cases. As a general rule, routed data shall incorporate desired payload and control messages which forces the scheme developer to take into account the desired application class and packet overhead alike. When considering the relaying of communication between distant parties, routing (and high efficiency thereof) becomes not just a means to an end but rather a goal in itself. Such a use-case, centered around communication relaying as well as VANET-to-FANET cooperation is mentioned in [17]; the researchers have even proposed an application-specific cross-layer routing protocol aimed at enabling close cooperation between VANETs and FANETs, as mentioned previously. The importance of routing efficiency becomes even more highlighted when considering military or emergency/first response operations [4].

There exist a vast number of routing protocols, with many being developed for a very specific use-case and others functioning as a foundation for other schemes. Evaluation of existing/under development protocols is done traditionally using classical simulation software (more often than not, developed for non-ad hoc networks). To counteract the limitations arising from a such approach and obtain usable results, developers resort to the addition of mobile properties to the individual nodes comprising their networks. Thus, in most cases, developed routing schemes are evaluated using conventional networking simulators, which can in many cases, efficiently approximate a mobile ad-hoc behavior. Different mobility models are included as libraries for discreet event network simulators. Support for the following mobility models is inherent in the NS-3 network simulator:

• Constant Position Mobility Model (NS-3 specific mobility model)
• Constant Velocity Mobility Model (NS-3 specific mobility model)
• Constant Acceleration Mobility Model (NS-3 specific mobility model)
• Gauss Markov Mobility Model [18,19]
• Hierarchical Mobility Model (NS-3 specific mobility model; a combination of specified “parent” and “child” mobility models)
• 2D Random Direction Mobility Model [19]
• 2D Random Walk Mobility Model [20]
• Random Waypoint Mobility Model [21]
• Steady State Random Waypoint Mobility Model (NS-3 specific mobility model; uses stationary instead of random distribution for initial speed, pause and position)
• Waypoint Mobility Model (NS-3 specific mobility model)

For the majority of the existing routing protocols, a discreet event network simulator such as the NS series may prove sufficient. However, non-classically layered schemes cannot be as effectively simulated due to inherent limitations of said software. To address this issue, there was developed the FINS framework capable of considering flexibility in the layer stack and thus enable nonadjacent interlayer data exchange during simulation [22,23,24]. Opnet Modeler has also been used by researchers to evaluate routing schemes of both classical and cross-layer architectures in numerous occasions.

Another approach to evaluating routing schemes’ efficiency, is directly using them in a testbed-network, usually comprised of Raspberry Pi modules. Great examples of research incorporating hardware-based testbeds are [25,26,27,28]. Despite the existence of related work in the field of ad-hoc routing and testbed implementation, no published papers present freely available testbed frameworks. The present paper aims to fill this void by:

• Engaging in FANET-specific routing protocol and mobility model analysis
• Proposing a universal routing scheme testbed
• Making said universal testbed completely open-source for other researchers to utilize and improve

Table 1. Related work and papers.

Related Work	FANET-Specific	Routing Protocols	Mobility Models	Testbed	Open-Source
Miya et al. [25]	✕	✓	✕	✓	✕
Kaysina et al. [26]	✓	✓	✕	✓	✕
Hamdaoui et al. [29]	✕	✓	✕	✓	✕
Brown et al. [30]	✓	✕	✕	✓	✕
Kim et al. [27]	✓	✕	✕	✓	✕
Rosati et al. [31]	✓	✓	✕	✓	✕
Our approach	✓	✓	✓	✓	✓

compares the present work to already existing surveys and testbed-oriented papers. The present paper is focused not only on surveying protocols but also on proposing a testbed. Thus, only papers of a similar nature were considered for the following comparison. Our approach proves to be the most complete in covering ad hoc routing and providing an evaluation platform open for all interested researchers to use.

The layout of the rest of this paper is as follows; Section 2 analyzes and explains matters of inter-UAV routing, while considering some of the most important and “influential” routing protocols. Section 3 is divided into two subsections; one surveying existing routing scheme testbeds (Section 3.1) and one proposing the aforementioned prototype testbed (Section 3.2). Section 4 is dedicated to the analysis of the proposed universal routing testbed and its modes of function: standalone, supplementary and stationary mode. Each of the aforementioned modes are explained in full detail in Section 4.1, Section 4.2 and Section 4.3 respectively.

2. Ad Hoc Routing

This section is dedicated to the analysis of the fundamental principles governing ad hoc networking, with an emphasis on FANETs. Additionally, some of the most important ad hoc routing protocols are explained and examined, in the context of evaluating them on a physical level, along with mobility models commonly used either to emulate high-mobility FANETs or as a route computation metric. The way in which mobility models affect route selection and are thus considered a route computation metric is link quality estimation (highly dependent on node mobility) accompanied by node position-awareness, which directly affects next hop selection in geographic or movement-predictive routing protocols (e.g., Greedy Perimeter Stateless Routing (GPSR) [32], Greedy Load Share Routing (GLSR) [33], Mobility Prediction based Geographic Routing (MPGR) [34], Directional Optimized Link State Routing (D-OLSR) [35], Geographic Contention-based Forwarding and Cooperative Communications (CoopGeo) [36] and their derived schemes).

2.1. Testbed-Friendly Ad Hoc Routing Protocols

Amongst the most commonly used ad hoc routing protocols in the scope of emulation of FANET deployments are:

• OLSR (usually implemented via OLSRd)
• Ad-hoc On-demand Distance Vector Routing (AODV)
• Hybrid Wireless Mesh Protocol (HWMP)
• BATMAN

2.1.1. OLSR

OLSR is one of the most popular proactive routing protocols, mostly due to the open-source nature of OLSRd enabling researchers to utilize it. Due to OLSR’s popularity and configurability, it has become the foundation of a spectrum of routing protocols: Predictive OLSR (POLSR) [37], Directional OLSR (DOLSR) [35], Energy-aware Mobility Prediction OLSR (EMP-OLSR) [38], OLSR Fuzzy Cost (OLSR-FC) [39], Cross-layer OLSR (C-OLSR) [40], QoS Aware Link Defined OLSR (LD-OLSR) [41] and many more.

OLSRd can function either as classical OLSR or additionally consider the Expected Transmission Count (ETX) metric, essentially implementing OLSR-ETX to obtain link quality (LQ, network-wide metric) as well as neighbor link quality (NLQ, node-specific metric) information [29]. The ETX metric is defined as follows:

$$ETX=\frac{1}{1-e_{pt}}$$

(1)

$$e_{pt}=1-LQ\times NLQ$$

(2)

$$ETX=\frac{1}{LQ\times NLQ}$$

(3)

where $e_{pt}$ is the packet error probability.

When used in an actual scenario, OLSRd is responsible for detecting neighboring network nodes and performing a link quality evaluation using received signal strength indication (RSSI) information. It therefore does not handle packet transmissions, yet populates and updates nodes’ routing tables as the network topology is updated by broadcasting HELLO messages and selecting MPRs. In addition to HELLO messages, another type of messages used by OLSRd is Topology Control (TC) messages, responsible for informing the network for each node’s accessibility by an MPR.

Route selection in classical OLSR is implemented by considering the path consisting of the smallest number of hops. Since OLSRd can be configured to consider the ETX metric, in most cases route selection also considers the possibility of packet loss and end-to-end throughput. The ETX metric can be utilized to enable QoS awareness using OLSR [41]. The only drawback stemming from the usage of the ETX metric is the protocol’s inability to sense the difference between links’ data rates (it assumes that all sensed links have an identical throughput). This is counteracted by introducing the Expected Transmission Time (ETT) metric (natively implemented by OLSR-ETT) [42].

$$ETT=ETX\times \frac{S}{B}$$

(4)

where S = packet size in bytes and B = link capacity (measured using packet-pair technique).

2.1.2. AODV

AODV [43] is a reactive topology-based protocol as it calculates packet routes on-demand. It is based on the Destination-Sequenced Distance Vector routing (DSDV) [44]. AODV cannot optimize routes by default. As with OLSR, there exist -ETX variants/extensions of AODV. Researchers in [45] measured and compared the performance of AODV and AODV-ETX; they concluded that compared to AODV, AODV-ETX’s average throughput is increased by 15.84%, packet delivery ratio is increased by 5.80%, average overhead is reduced by 4.31%, at the expense, however, of a 10.19% increased end-to-end delay and a by 3.09% increased route discovery delay. AODV is one of the most popular ad hoc routing protocols. Authors of [46] have compared AODV to Dynamic Source Routing (DSR) in an outdoors environment. They concluded that AODV performs measurably better in terms of packet loss and end-to-end delay. AODV is implemented in Linux kernel v. 3.8 as AODV-UU [47] created by the Uppsala University, hence the suffix.

2.1.3. HWMP

Using AODV as a foundation, a Hybrid Wireless Mesh Protocol (HWMP) has been developed. HWMP is a hybrid routing protocol, capable of using both proactive and reactive path selection algorithms. HWMP offers a higher packet delivery ratio, at the expense of a higher packet overhead. Similarly to AODV, HWMP uses path request (PREQ) messages to obtain optimal packet paths. Authors of [48] engage in performance comparison of AODV, DSDV, DSR, OLSR, AOMDV and HWMP alike: their measurements and simulations prove that under their test conditions, HWMP offers the best performance, followed by OLSR. HWMP’s better performance is comparison to AODV stems from the aforementioned fact: usage of both proactive and reactive route path discovery methods. HWMP can route on layer 2 of the Open Systems Interconnection (OSI) stack using Media Access Control (MAC) instead of Internet Protocol (IP) addresses.

Both AODV and HWMP exist as installation for Linux-based platforms such as Raspberry pi. Due to AODV’s library age, between the two, HWMP is generally preferred as a routing scheme.

2.1.4. BATMAN

The Better Approach To Mobile Ad hoc Networking (BATMAN) protocol is a decentralized routing protocol whose main selling point is the equal distribution of the optimal route information. This approach eliminates the need to broadcast possible topology changes to the entire network, effectively eliminating overhead. Nodes do not maintain full source-destination route information and instead only know their next hop. Route optimization is implemented in a hop-by-hop approach. Packets are routed to their destination individually, via constantly recomputed routes (that applies to packets comprising a single message as well). The BATMAN-adv variant of this protocol enables layer 2 routing (similarly to HWMP), in contrast to the classical layer-3 routing scheme normally implemented by BATMAN [49]. BATMAN-adv is currently implemented as a kernel driver and improves CPU performance by minimizing the required machine cycles [50].

Periodically, Originator Messages (OGM) are broadcasted to update neighboring node information; they contain the following information [51]:

• Originator (i.e., source) address
• Destination address
• Link flag
• Time To Live (TTL)

The information of the destination address is updated every time the OGM packet is rebroadcasted. Information regarding reachable nodes is stored in an originator table, carried by each node. BATMAN uses the Transmission Quality metric (TQ) to compare link quality between possible next hops and perform route selection [51]. Authors in [26] used BATMAN in a physical Raspberry Pi-based network. They propose a testbed framework for this protocol and additionally tested video content transmission in a BATMAN-enabled ad hoc network.

Table 2. Routing scheme summary table.

Routing Protocol	Proactive	Reactive	Open-Source	Kernel Implementation
OLSR	✓	✕	✓	OLSRd
AODV	✕	✓	✓	AODV-UU
HWMP	✓	✓	✓	HWMP
BATMAN	✓	✕	✓	BATMAN-adv

contains and summarizes the main characteristics of the testable routing protocols which were analyzed in this subsection: OLSR Section 2.1.1, AODV Section 2.1.2, HWMP Section 2.1.3 and BATMAN Section 2.1.4.

2.2. Mobility Models

Of the existing mobility models those supported by the NS3 simulator are mentioned in Section 1. Depending on the requirements set by the simulated UAV network use-case, as well as the behaviour defined by the routing protocol, different, and in some occasions more unique mobility models are used to describe the FANETs mobility; e.g., despite its general effectiveness, the Gauss-Markov Mobility Model does not describe circular swarm mobility (common in monitoring use-cases) as effectively as the Semi Random Circular Mobility Model, which is otherwise of minimal emulative value. Generally, the most effective (and thus popular) ones in terms of accurate FANET mobility emulation are the following:

• Gauss-Markov Mobility Model [18]
• Paparazzi Mobility Model [19]
• Semi Random Circular Mobility Model [52]
• Random Waypoint Mobility Model [18]

2.2.1. Gauss-Markov

Gauss-Markov is a time-dependent mobility model capable of accurately describing a FANET’s movement, with individual node’s paths being independent from one another. Random initial positions are defined for each UAV and the velocity vector is recomputed at each time instance depending solely on previous UAV speed and position [53].

2.2.2. Paparazzi

Paparazzi is a path-planned stochastic mobility model. In order for the model to approximate all possible UAV maneuvers, it supports the following fundamental movements: stay-at, way-point, eight, scan and oval [54].

2.2.3. Semi Random Circular

Semi Random Circular is a path-planned mobility model centered around UAV-enabled surveillance and target monitoring of an already known area [52]. This model makes the examined FANET circulate an area of interest, rendering it realistic for the emulation of e.g., search-and-rescue missions.

2.2.4. Random Waypoint

Random Waypoint is a randomized mobility model. At every time instance, each node has a distinct and random velocity, destination and a randomized stop time. The UAVs’ destination and stop time both get re-updated upon each randomization iteration, depending on which event precedes the other: reaching of node destination or timeout of waypoint validity.

When simulating a FANET deployment, it is of utmost importance to select a fitting mobility model. As previously stated, the overall mobility of a node and its network strongly affects networking metrics and route computation-related parameters. Consideration of mobility models as a routing metric is therefore a valid reason to avoid or resort to the usage of a mobility model. Location or prediction-dependent schemes especially, may present an altered/deteriorated or generally false performance, should the UAVs’ locations be altered in an unexpected/rapid manner (e.g., random definition of velocity vectors instead of a collectively coordinated mobility plan and movement path).

3. FANET Testbeds

This section is concerned with surveying existing routing scheme testbeds and the proposal of an open-source hardware testbed. Section 3.1 analyzes the work of researchers who faced the similar challenge of routing scheme performance evaluation in real life and under such environmental conditions. Virtually all existing work is either simulation-focused or uses Raspberry Pis on which the tested protocol is installed. The benefits of implementing a hardware-based evaluation instead of simulating a routing scheme are numerous:

• Measurement of computational capacity required for routing and load balancing
• Measurement of environmental effects on communication and link quality
• Measurement of transmission-related node energy expenditure
• Measurement of mobility-stemming effects on overhead and computational demand
• Measurement of security methods’ and packet encryption/decryption (CPU-intensive tasks) effects on availability of processing power

On a few occasions, researchers resorted to the usage of actual mobile UAVs, which they deployed as a FANET. Respectively, Section 3.2 proposes a multifunctional solution capable of both extending the capabilities of existing testbeds and functioning as a standalone on-board flight controller. The hardware design is explained on a medium abstraction layer and design files are provided.

3.1. 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 Zero 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 bottlenecking 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 wield 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. The utilized hardware is comprised of the Soekris net4511 computer module accompanied by the Orinoco 802.11b Gold radio module which has a small (PCMCIA) form factor. Fidelity Comtech RF amplifiers were used to amplify the radio module’s signal which normally has an approximately 150 m range. The computer modules were equipped with the Click routing software.

3.2. Proposal of an Embedded Routing Scheme Testbed

There exist a variety of routing testbeds, both hardware and software in nature. However, there has been little to no progress in terms of standardization and compartmentalization of said systems. Furthermore, all hardware-based solutions seem to fall under the two following categories:

• Meant for evaluation using stationary nodes
• Specifically designed for a type of UAV the developers saw fit

This subsection is thus dedicated to the proposal of a universal and standardized hardware testbed meant for both stationary and aerial usage. Said testbed shall incorporate:

• A computing platform on which the desired routing protocol shall be installed
• A dedicated 802.11 WiFi antenna
• A gyroscope/accelerometer which shall enable the platform to function as a standalone flight controller
• A companion microcontroller implementing the flight control logic without burdening the main computing platform with unnecessary tasks

Considering the amount of existing work and availability of routing protocol installations for Linux-based operating systems, the Raspberry Pi Zero seems to be the best computing platform for aerial usage; it combines a small and lightweight form factor with impressive computing capabilities. As for the dedicated WiFi antenna and the companion microcontroller, the ESP32 proves more than sufficient in both aspects. The embedded WiFi antenna has a mediocre range, which can be significantly extended (up to approximately 1 km, assuming a direct LOS) using the Epsressif-patented 802.11 LR (long range) mode. This mode in combination with a MAC-layer peer-to-peer transmission handling protocol (e.g., ESP-NOW) can enable low latency and low overhead communication in an impressive range using a small amount of power in comparison to other commercially available 802.11 antenna modules; in this case, packet routing can be implemented using MAC addresses. The networking sacrifice needed to be made is throughput. Entering the LR mode is a simple function call and does not affect program functionality:

• esp_wifi_set_protocol (ifx, WIFI_PROTOCOL_LR);

Table 3. Raspberry Pi Zero W & ESP32 specifications.

	Raspberry Pi Zero W	ESP32
CPU	ARM1176JZF-S (1 GHz, single-core)	Xtensa LX6 (240 MHz, dual-core)
Memory	RAM 512 MB (LPDDR2)	520 KB (SRAM) 4 MB (flash)

showcases the specifications of both the computer and complementary microcontroller of choice. The gyroscope/accelerometer module of choice is the MPU6050 due to the amount and quality of existing libraries enabling it to interface with ESP32. More technical details and design choices are thoroughly explained below.

The proposed testbed architecture makes use of affordable networking and computing equipment to create a mobile ad hoc network and evaluate routing efficiency of a given scheme. In addition to route computation and transmission handling, this implementation can be used as a standalone flight controller. The embedded gyroscope/accelerometer enables each module to not only function as a self-contained flight controller but also consider orientation and angular velocity of each axis as a routing metric; this enables support for location-predictive routing protocols. Since the module is centered around and uses the Raspberry Pi as a computing unit, all the respectively supported routing protocols may be used with this design. Each module is a functional node in itself and does not require additional components.

The hardware has been designed so that each one of said testbed modules can be directly attached to an existing UAV. The main board complies to the PC/104 standard, which is the hardware specification many UAV autopilots aim to conform to as well, as mentioned in [56]. Conformity to this electromechanical standard ensures flawless mechanical interfacing and even safe physical stacking of said modules onto the same UAV. PC/104 is commonly used in specialized high-reliability embedded applications, aiming for a small and rugged form-factor. The PC/104 standard dictates the following:

• Usage of a (traditionally 104-pin) connector
• Strictly defined PCB dimensions (90 × 96 mm) with 13 mm optional extra space for additional connectors
• Four mounting holes in predefined positions

4. Findings and Discussion

The Findings and Discussion section is dedicated to the explanation of the three main modes in which the proposed module shall operate. The first mode is a result of direct usage of the proposed module as both a flight controller and a routing evaluation medium. As for the second mode, it likely constitutes the most directly usable mode of operation: the module only implements routing (and the evaluation thereof), while an external flight controller, native to the UAV, handles all aircraft control, PID tuning and external sensor interfacing. Similarly, the last mode of operation is the one in which no aircraft is utilized for scheme evaluation, rather a stationary set of networked modules. The last mode is suitable for both VANET deployments as well as stationary (e.g., sensor network) networks. Figure 4 showcases a 3D render of the design.

The design files for the proposed testbed module have been made publicly available in GitHub: [57]. The design software used is KiCAD. Along with the design files are the production file, which can be used for fast prototyping and testing. The work of engineers in [58] was utilized as a PC/104 template.

4.1. Standalone Aerial Mode

In standalone aerial mode, mesh modules are directly attached to each UAV comprising a FANET. The main concept behind the design is the compartmentalization of task handling so as to avoid unnecessary computational burden of each component. This design idea is directly translated to hardware design implementation. The Raspberry Pi Zero is attached directly to the main board with an exposed header configured to match its pinout. As seen in Figure 5, one of the PC/104 holes and two extra nonplated 3.2 mm Ømounting holes offer extra mechanical stability to the interconnection of the main components. As the Raspberry Pi is placed onto the main board, it is internally powered by the main board’s regulator. The module has full support for an amplitude of commercially available GNSS modules. Node location can therefore be used as a route selection metric, in addition to node velocity and acceleration as previously mentioned. Thus, in addition to predictive routing schemes, evaluation/implementation of location aware or location-based routing is made possible.

Figure 6 illustrates the interfacing between the Raspberry Pi and the ESP32 as well as tasks each module handles.

The Raspberry Pi Zero shall only implement route-related computations. After a route has been established, the packet shall be serially transmitted to the ESP32, which shall in turn implement transmission handling. In turn, upon packet reception, the ESP32 shall serially transmit the data to the Raspberry Pi. Packet transmission/reception handling shall constitute a distinct nonblocking RTOS task, so that the ESP32 can simultaneously implement the flight control logic. It becomes obvious that the ESP32 now has two functions, which are defined as distinct RTOS tasks handled by the two cores of the Xtensa LX6 microprocessor. All packet transmission and reception is done via the embedded WiFi antenna which ensures a low power consumption as well as the possibility of interfacing with conventional 802.11 networks. The Raspberry Pi is thus successfully only occupied with route handling.

Table 4. Raspberry Pi Zero W—ESP serial interfacing.

Raspberry Pi Zero W		ESP32
Serial Tx	Serial Rx	Serial Tx	Serial Rx
Packet to be transmitted	Received packet	Received packet	Packet to be transmitted
	Gyroscope/accelerometer (processed data)	Gyroscope/accelerometer (processed data)
	RSSI	RSSI
	GNSS data	GNSS data

showcases the serial interface between said modules in standalone aerial mode. The mentioned gyroscope/accelerometer processed data shall only be transmitted to the Raspberry Pi if the evaluated routing protocol requires them as a metric. Similarly, RSSI (measured between) shall be shared if link quality or power-awareness is desired and considered by the respective protocol. GNSS data is again, optional and shall be transmitted in the case geolocation-based routing is implemented.

4.2. Supplementary Aerial Mode

In supplementary aerial mode, the module does not function as a fight controller. It may be attached to an already existing flight controller/autopilot and solely implement routing to other networked nodes on-board. The authors of [56] survey a number of UAV autopilots, a substantial number of whom offer serial interface connectivity. Flight controllers typically transmit telemetry data to a ground station, which can be made available to a serially connected interface on demand. Telemetry data can be forwarded to the Raspberry Pi to be used in route calculations. In this case, the ESP does not need to handle two distinct RTOS tasks and can fully commit to the task of transmission handling. The interfacing node components can be described as seen in Figure 7.

As virtually all flight controller inherently implement interfacing with GNSS modules, and contain an on-board gyroscope/accelerometer module, those components need not be placed/connected to the main board.

4.3. Stationary/VANET Mode

In stationary/VANET mode, the data from the MPU6050 gyroscope/accelerometer module may be utilized to form packets of a given length, defined by the protocol’s structure. In this mode, the modules shall function independently from an external flight controller. With no connection to a flight controller or an embedded flight control RTOS task, the module can still implement routing and be used as a means of evaluation thereof. This may prove to be a useful implementation for non MANET-specific ad hoc routing schemes. The advantages stemming from the usage of a compartmentalized device and a standard form factor are still there, though exploited to a lesser degree. Usage of this mode is also a possibility for the evaluation of routing schemes in nonaerial ad hoc networks.

5. Conclusions and Future Work

This paper has discussed industrial, military and agricultural use-cases for FANETs, surveyed directly applicable mobile ad hoc routing protocol to be used in such deployments, as well as existing testbed/simulation frameworks which can be used to evaluate the efficiency of routing protocols. Additionally, matters of network topology and mobility modeling are addressed in the context of scheme simulation. This work is concluded with the presentation of:

• A standardized hardware prototype capable of supporting all routing protocols currently implemented in the Linux kernel
• Component interface modes as a function of desired evaluation framework

Figure 8 constitutes the result of the proposed testbed module’s evaluation using an ESP-Now link and the embedded PCB antenna of the ESP. Even when using the PCB antenna, power consumption was kept below 2.5 Watts, while the link did not fail to maintain maximum bandwidth at 85 m with a direct and constant LOS. The module’s evaluation consisted of:

• Link establishment between two modules
• Formation of ESP-Now packets using dummy data harvested from the MPU6050 gyroscope/accelerometer
• Communication between a constantly increasing distance (5 m–85 m)
• Measurement of the transmitting module’s power consumption at 5-m intervals

Future work shall be constituted of test results originating from the usage of the proposed testbed with OLSRd and BATMAN. A comparison between said routing schemes in terms of: (a) scalability and (b) mobility shall be part of said future work. NS-3 simulations shall be used to validate the performance of the proposed testbed under the mobility models mentioned in Section 2.2. Due to the current lack of functional open-source flight controllers meant to be used with the ESP-series, such firmware shall be developed and made openly available, as is the case with the proposed module’s hardware.