# Transport-Layer Limitations for NFV Orchestration in Resource-Constrained Aerial Networks
## 4 Practical Evaluation of Transport-Layer Options
It is expected that other network topologies, where the degree of the aerial nodes (i.e., the number of wireless links of node to other neighboring nodes) is reduced, will produce worse performance results. Moreover, the number of aircrafts in the reference scenario has been considered sufficiently large to obtain trustworthy conclusions. In the scenario, we assume there is only a single VIM attached to the GCS, simulating the generation/reception of NFV management traffic to/from the SUAVs using a single MANO pile (i.e., all SUAVs NFVI belong to the same orchestration domain). In our scenario, all aircrafts are provided with a single WiFi interface using IEEE 802.11a, which is configured to create an ad-hoc network with the former topology. In this topology, the GCS can communicate with the SUAV grid through two independent SUAV units. With this configuration, each SUAV and the GCS can communicate with other SUAVs in their vicinity using a single wireless network card. Multi-hop communications over the ad-hoc network built by the SUAVs and the GCS are guaranteed through the use of a network routing protocol. In particular, in our simulations OLSR for this purpose. We want to mention that according to our previous work [5], this approach, based on the use of a WiFi ad-hoc network and a network routing protocol, has proven to be effective to support multi-hop wireless communications in SUAV scenarios. However, this is not the only valid approach to guarantee end-to-end communications, as these could also be performed using alternative approaches, such as cellular device-to-device communications [40]. However, verifying the feasibility of this technology in our reference scenario would still require a detailed analysis, taking into consideration different aspects related to energy consumption, as well as size and weight of the enabling equipment. In our evaluation, we consider the management and orchestration information that is exchanged between the GCS and each SUAV to monitor the status of the computing, networking, and storage resources onboarded on the SUAV. This type of control information is continuously transmitted in NFV scenarios, with the VIM periodically triggering each compute node to get updated information on the status of the resources. Our future work will consider other forms of management and orchestration traffic, such as the traffic needed to support the instantiation and deletion of VNFs over the SUAVs. In typical production-like NFV environments, management and orchestration information is usually exchanged using the HTTP protocol, where the VIM can obtain information regarding the state of the resources at the compute nodes (in our case, the state of the resources onboarded by the aircraft). Because this protocol uses a REST model, aircraft will reply with the requested information to answer the query. This behavior is not required in the tests that we have performed however, since  
Figure 2: 16 SUAV FANET scenario forming a grid topology. SUAVs (1,1) and (1,2) are directly connected to the GCS. we are concerned on studying the overall orchestration traffic throughput on either direction (i.e., from the GCS to each SUAV, and vice versa), rather than precisely emulating the orchestration traffic pattern. Therefore, in our simulations we decoupled the bidirectional exchange of management and orchestration information between the GCS and each SUAV, representing it as two different Constant Bit-Rate (CBR) traffic flows. These CBR flows serve to approximate the periodic exchange of control information in typical VIM-NFVI communications. The transmission rate of each CBR source in our simulations was set to 7 kbps for each SUAV-to-GCS communication, and 5 kbps for the reverse path. Both values were selected to fit the average throughput that is seen in each direction when using a real VIM such as OpenStack, as shown in [5], where authors build a NFV scenario using real SUAV units and OpenStack as its VIM (located in a GCS).