## 3 Proposed Approach
### Routing Protocol Description  
Each node participating in the FANET runs an instance of the routing protocol described in Algorithms 1-4. It is assumed that each node is equipped with a mission computer (MC), which contains parameters pre-configured before the start of a mission. Examples of pre-configured parameters may include the node identification, identification of participants in the same squadron, MAC addresses assigned to network interfaces and corresponding IP addresses for all members of squadron, configured cryptographic services  
Figure 1: Two friendly aircraft communicating with each other. Figure 3: Three friendly aircraft communicating with each other, but with an adversary nearby forcing multi-hop routing to be used. Figure 2: Three friendly aircraft communicating with each other, using both single-hop routing and multi-hop routing. and associated cryptographic material, etc. This information is integrated into the node's SA view. When the routing protocol is started, it will begin the bootstrapping procedure described in Algorithm 1. The first step is to interface with the aircraft sensors and on-board auxiliary systems to identify any other nodes, friends or adversaries detectable in the range of the sensors. The information will include the position, velocity and acceleration of the discovered nodes, essentially yielding the node local SA data mentioned in Section 3.1. The local SA data are inserted into the node's SA view, which is an aggregation of SA data from local sensors and SA data obtained from other friendly nodes through routing protocol message exchanges. In bootstrap mode, no such exchanges have taken place yet, and therefore, the node's SA view contains only local SA data. The third step is to call the HDA_Routing procedure (Algorithm 4) to compute routes to any of the friendly nodes discovered. Finally, a timer called _send_SA_update_ is configured. When this timer expires, the node will share its SA view with other nodes located one hop away, which is the procedure outlined in Algorithm 2. ```
1:Identity of node \(n\) running the bootstrap
2:Use aircraft sensors to collect SA data (_local_SA_)
3:Insert local_SA into SA_view
4:HDA_Routing(SA_view, n) \(\triangleright\)Executes Algorithm 4
5:Schedule send_SA_update timer \(\triangleright\)Triggers Algorithm 2 when it expires
```  
**Algorithm 1** Bootstrap at node \(n\). Algorithm 2 is rather straightforward. When the _send_SA_update_ timer expires, this algorithm is invoked, and during its execution, it will prepare a message containing the node's SA view and send it to the one-hop friendly neighbors. Information from the MC is not included in the updates, since it is assumed that each node has access to it from their own MC. After that, it will re-schedule the _send_SA_update_ timer for the next update to the neighbor nodes. ```
1:\(SA\_view\), identity of node \(n\) running the algorithm
2:procedureSend_SA_Update(SA_view, n)
3:for each friendly node \(dst\) in SA_view_ reachable in one hop do
4: Transmit SA_view to \(dst\)
5:endfor
6: Schedule send_SA_update timer \(\triangleright\)Triggers this algorithm when it expires
```  
**Algorithm 2** Update neighbor nodes. Algorithm 3 handles the situation when an SA view is received from a friendly neighbor. First, the node will update its local SA data by interfacing with the aircraft sensors and on-board auxiliary systems. If the new local SA data conflict with data in the node's SA view, for example with SA data received earlier from a friendly node, the information from the local SA data will replace the existing data in the SA view. Our policy is that fresh local SA data are trusted above anything else. The currently received SA view, _record_SA_view_, is merged into the node's SA view using the same policy. Since SA data are timestamped, entries from the _record_SA_view_ will replace the node's existing SA view data only if newer.