## 4 Methodology  
We have used the OMNEST simulator framework to evaluate HDARP. OMNEST is the commercial version of the well-known simulator framework OMNeT++ [23; 24]. OMNEST uses a modular, component-based approach to build simulations. At the core, OMNEST modules are written in C++, but at a higher level, they can be combined and extended using OMNEST's Network Description (NED) language. We also made use of the INETMANET [25] open-source model library, which contains models for the internet stack, wired and wireless link-layer protocols and more. Historically, INETMANET was forked from the official INET [26] model library in order to address the shortage of MANET protocol components. Nowadays, INET and INETMANET are pretty much aligned in terms of functionality and compatibility with each other. However, INETMANET continues to provide access to additional MANET protocols, which is the reason we preferred it for our study. INETMANET does not have specific versioned releases. The code we use in our simulations comes from Git commit 6708b98344e5 fd5a5e788 da97367 efa9150629a2. Both INET and INETMANET are well described in [27]. We have compared HDARP's performance against five other MANET protocols available in INETMANET: AODV [28], BATMAN [29], DSDV [30], DSR-UU [31], and OLSR [32], respectively. Initially, we included additional MANET routing protocols from INETMANET, AODV-UU [33], Dymo [34; 35] and Dymo-FAU [36], but these crashed multiple times during our simulations and are therefore not included in the results. Notably, DSR-UU and AODV-UU are protocol implementations for the Linux kernel that later were also made operable with the ns-2 and OMNeT++ simulators. For all nodes that are simulated, we used the NED language to inherit generic networking functionality from the AdHocHost component, which provides among other things a TCP/IP stack simulation model, support for mobility models, a loopback interface as well as a wireless interface. In addition, the nodes were configured to use one specific MANET routing protocol from the selection above, including our own HDARP routing protocol. Every node derived from the AdHocHost component can be equipped with an arbitrary number of applications. These simulation modules exploit functionality of the underlying TCP/IP stack to communicate with peer modules application located on other nodes, typically using a socket abstraction. However, the applications can also subscribe for signals from lower layers and other modules, or hook into the functionality of the underlying TCP/IP stack to provide special processing for incoming and outgoing packets, much like the functionality of the Linux netfilter [37]. In our case, we equipped the nodes in the simulation with two applications, InterceptApp and UdpBasicApp, described in Section 4.1 and Section 4.2, respectively. The nodes were also equipped with a mobility model that imports realistic flight path traces provided by our aerospace industry partner. This module was implemented using a combination of C++ and NED. Our mobility model reads data from file where records are indexed by monotonically increasing timestamps. Each record contains the 3D position of a specific node at the time indicated by the timestamp. The module computes instantaneous node velocity and acceleration using the data from the records. In addition, the module interpolates the position of the aircraft between two consecutive timestamps using the computed velocity. The module emits a notification each time a node updates its position, either through interpolation or by advancing to the next record in the data. It is important to note that each node participating in the simulation is equipped with its own mobility model instance that emits notifications for that particular node. HDARP nodes are configured as above with the notable exception that they require an additional SA module to implement situation awareness. Every HDARP node has its own SA module instance that subscribes to mobility notifications from all nodes in the simulation.