turn off anonymous marking

This is a preview of the print version of your report. Please click "print" to continue or "done" to close this window.

TITLE: Automated deployment of an IP telephony service on Unmanned Aerial Vehicles using Network Functions Virtualization AUTHORS AND AFFILIATIONS: Borja Nogales1,*, Ivan Vidal1,*, Victor Sanchez-Aguero1,2,*, Francisco Valera1,*, Luis F. Gonzalez1,*, Arturo Azcorra1,2,* 1Department of Telematic Engineering, University Carlos III of Madrid, Madrid, Spain 2IMDEA Networks Institute, Madrid, Spain *These authors contributed equally. Email addresses of co-authors: Borja Nogales (bdorado@pa.uc3m.es) Victor Sanchez- Aguero (victor.sanchez @imdea.org) Francisco Valera (fvalera@it.uc3m.es) Luis F. Gonzalez (luisfgon@it.uc3m.es) Arturo Azcorra (azcorra @it.uc3m.es) Corresponding author: Ivan Vidal (ividal@it.uc3m.es) KEYWORDS: Unmanned Aerial Vehicles (UAVs), Network Functions Virtualization (NFV), Management and Orchestration (MANO), Cloud computing platform, Virtual Network Function (VNF), IP telephony service, open source, 5G. SUMMARY: The objective of the described protocol is twofold: to configure an NFV environment using unmanned aerial vehicles, as computational entities providing the underlaying substrate to execute virtualized network functions; and to use this environment to support the automated deployment of a functional IP telephony service over the aerial vehicles. ABSTRACT: The Network Function Virtualization (NFV) paradigm has currently consolidated as one of the key enabling technologies in the development of the 5th Generation of mobile networks. This technology aims at alleviating the hardware dependencies in the provision of network functions and services, using virtualization techniques that allow the softwarization of those functionalities over an abstraction layer. In this context, there is an increasing research interest in exploring the potential of unmanned aerial vehicles, or UAVs, to offer a flexible platform capable of enabling cost-effective NFV operations over delimited geographic areas. To demonstrate the practical feasibility of utilizing NFV technologies in UAV platforms, we present a protocol to set up a functional NFV environment, based on open-source technologies, in which a set of small UAVs supply the computational resources that support the deployment of moderately complex network services. Then the protocol details the different steps needed to support the automated deployment of an IP telephony service over a network of interconnected UAVs, leveraging the capacities of the configured NFV environment. Our experimentation results demonstrate the proper operation of the service after its deployment. We want to highlight that, although the protocol focuses on a specific type of network service (i.e., IP telephony), the described steps may serve as a general guide to deploy other type of network services. On the other hand, the protocol description considers concrete equipment and software to set up the NFV environment (e.g., specific single board computers and open source software). The utilization of other hardware and software platforms may be feasible, although the specific configuration aspect of the NFV environment and the service deployment may present variations with respect to those described in the protocol. INTRODUCTION: One of the most promising ambitions within the new era of the mobile communications (most commonly known as the 5th mobile generation or 5G) is to be able to provide robust Information technology services even in situations where the primary telecommunications infrastructure may not be available due to, for example, an emergency situation. In this context, the unmanned aerial vehicles (UAVs) are receiving increasing attention from the research community due to their inherent versatility. There are numerous works that use this type of devices as a cornerstone in the provision of a large variety of services. For instance, the literature has analyzed the capacity of these devices to build an aerial communication infrastructure to accommodate multimedia services1-3. Furthermore, prior research has presented how the cooperation among several UAVs can extend the functionality of different communication services such as surveillance4, collaborative search and rescue5-8, or agribusiness9. On the other hand, the Network Functions Virtualization (NFV) technology has acquired a great significance within the telecom operators as one of the 5G key-enablers. NFV represents a paradigmatic change regarding the telecommunications infrastructure, by alleviating the current dependency of the network appliances on specialized hardware through the softwarization of the network functionalities. This enables a flexible and agile deployment of new types of communication services. To this purpose, the European Telecommunications Standards Institute (ETSI) formed a specification group to define the NFV architectural framework10. Additionally, the ETSI currently hosts the Open Source Mano (OSM) group11, which is in charge of developing an NFV Management and Orchestration (MANO) software stack aligned with the definition of the ETSI NFV architectural framework. Given all the aforementioned considerations, the synergic convergence between UAVs and NFV technologies is currently being studied as a promising enabler in the development of novel network applications and services. This is illustrated by several research works in the literature, which point out the advantages of these types of systems14-16, identify the challenges of this convergence and the missing aspects, highlighting future research lines on this topic17, and present pioneer solutions based on open source technologies. Regarding the latter, our prior work18,19 includes the design of an NFV system capable of supporting the automated deployment of network functions and services on UAV platforms, as well as the validation of the practical feasibility of this design. In this context, the objective of this paper is to showcase a protocol that enables the integration of UAVs in an NFV environment, and uses this environment to support the automated deployment of a real network service, in particular an IP telephony service. To this purpose, different softwarization units (categorized within the NFV paradigm as Virtual Network Functions or VNFs) are defined to compose the mentioned service: • • Access Point VNF (AP-VNF): this VNF provides a Wi-Fi access point to end-user equipment (i.e., IP phones in our experiment). IP telephony server VNF (IP-telephony-server-VNF): it is responsible of managing the call signaling messages that are exchanged between IP phones to establish and terminate a voice call. • • Domain Name System VNF (DNS-VNF): this VNF provides a name resolution service, which is typically needed in IP telephony services. Access router VNF (AR-VNF): provides network routing functionalities, supporting the exchange of traffic (i.e., call signaling in our experiment) between the IP phones and the telecommunication operator domain. • Core router VNF (CR-VNF): provides network routing functionalities in the telecommunication operator domain, offering access to operator-specific services (i.e., the IP Telephony server) and external data networks. Figure 1 illustrates the network service designed for this experiment. This network service is built as a composition of the aforementioned VNFs, and provides the functionality of an IP telephony service to users in the vicinity of the UAVs. Moreover, the figure presents the physical devices used for the experiment, how they are interconnected, and the specific allocation of VNFs to devices. PROTOCOL: 1. Prior Requisites for the Experiment 1.1. An installation of the Management and Orchestration (MANO) software stack provided by the Open Source MANO (OSM) project. Specifically, this experiment uses OSM Release FOUR20, which can be executed in a single server computer or a in a Virtual Machine (VM) fulfilling the requirements specified by the OSM community: Ubuntu 16.04 as Operating System (64-bit variant image), 2 Central Processing Units (CPUs), 8 GB Random-access memory (RAM), 40 GB storagedisk, and a single network interface with Internet access. 1.2. A cloud computing platform, providing the functions of a Virtual Infrastructure Manager (VIM) compliant with OSM Release FOUR. In particular, for this experiment, OpenStack release Ocata21 is used, running in a VM with Ubuntu 16.04 as Operating System, 4 CPUs, 16 GB RAM, and 200 GB storage disk. In the experiment, the VIM manages an NFV Infrastructure (NFVI) integrated by 2 high-profile server computers (each with Ubuntu 16.04 as Operating System, 8 CPUs, 128 GB RAM, and 4 TB storage disk). In the following, we denominate this cloud platform as the core cloud platform. 1.3. An additional cloud computing platform for the UAVs (hereafter referred to as UAVs cloud platform). The platform must feature a VIM based on OpenStack release Ocata. In this case, the resources used by the VIM installation are: Ubuntu 16.04 as Operating System, 2 CPUs, 6 GB RAM, 100 GB storage disk, and an external Wi-Fi USB adapter. On the other hand, the NFVI integrated in this cloud platform consists of a single fixed compute server mini-ITX (Ubuntu 16.04 as Operating System, 8 CPUs, 8 GB RAM, 128 GB storage disk, and an external Wi-Fi USB adapter) and 3 Single Board Computers (SBCs). These latter provide a hardware platform that can easily be onboarded on a UAV. The procedure to setup a UAV cloud platform with these devices as compute nodes is detailed in 3. 1.4. Equip each SBC with a battery-power supply Hardware Attached on Top (HAT) to ensure the operation of these units even when they are in motion being carried by a UAV. NOTE: The next step, 1.5, is optional since the provision of the network service in the experiment do not depend on having UAVs. 1.5. Attach each RPi as the payload of a UAV. In this experiment, two different UAVs model are used: Parrot AR Drone 2.0 and Parrot Bebop 2. 1.6. Two wireless voice-over-IP phones model ZyXEL Prestige 2000 W, which support the IEEE 802.11b wireless communications standard (i.e., this model provides wireless communications via Wi-Fi). As an alternative, the voice call could be executed using softphone applications such as Linphone22 or Jitsi23. 1.7. The experiment requires the availability of: a) layer-3 communications between the OSM software stack and each of the VIMs, to enable the orchestrated deployment of the network service developed for this experiment; and b) layer-3 communications between the OSM and the VNFs instantiated at each cloud platform, to support VNF configuration procedures; and c) the layer-3 communications among the VNFs running at every VIM to enable the proper functioning of the network service. 1.8. All the content needed to carry out the experiment is provided in the following public repository, hereafter referred to as the experiment repository: http://vm- images.netcom.it.uc3m.es/jove/. 2. Validate the functionality of the softwarization units via Emulation NOTE: To prove the appropriate operation of the network service of the experiment (see Figure 1) under realistic deployment conditions, we use a purpose-specific emulation platform based on Linux containers24 and ns-325. This platform can be used to evaluate the behavior of the VNFs and network services as a prior step to their deployment on real equipment. To this end, the emulator supports the configuration of multi-hop aerial network topologies and emulates the exchange of data among the VNFs via wireless communications. This section of the protocol describes the steps to be followed to verify the appropriate operation of the IP telephony service. 2.1. Download the emulation platform from the experiment repository. The platform is available as a virtual machine, with name “uav-nfv-jove-experiment.qcow”, compliant with the KVM virtualization technology26. This machine contains a pre-created template that emulates the network service and the multi-UAV scenario presented in Figure 1 and a user with administrator privileges capable of executing that template. NOTE: By default, the following steps are automatically executed when the emulation platform virtual machine is started: a) the virtual environment is configured to enable the network emulation (i.e., network interfaces, Linux bridges27); and b) the Linux Containers that represent each of the physical devices of the scenario are started. All the Linux containers include the required default configurations to have a complete and operational network scenario. 2.2. Before the validation process, an emulated multi-hop aerial network needs to be created using the ns-3 simulator, in order to enable the connectivity between the different network participants. 2.2.1. Create the multi-hop aerial network. For this purpose, execute the “multi-hop- aerial-net.sh” script (available within the emulation platform machine) using the following command: “sudo sh /home/jovevm/scripts/multi-hop-aerial-net.sh > multi-hop-aerial-net-trace.log 2>&1 &”. In addition, this command portrays the simulation trace in the specified log-file to enable the debugging in the case of failures. 2.2.2. Check if the network has been successfully created. To this end, verify if the Linux Containers "IP-phone-a" and "IP-phone-b" (illustrated in the Figure 1 as the end-user equipment that connect to an AP-VNF) have obtained an IP address through the DHCP service (only accessible through the multi-hop aerial network). The status of the Linux container executed within the emulation machine, as well as their IP addresses, can be checked using the next command: "lxc list". 2.3. Verify the capacity of the emulated network service to process the signaling messages needed to set up the IP telephony call. For this purpose, both the "IP-phone-a" and "IP- phone-b" Linux containers have installed the “SIPp” tool28. “SIPp” provides the functionality to emulate an IP phone creating the mentioned signaling messages, send them to an IP telephony server and process the response to verify the correct operation of this latter. 2.3.1. Execute the script “test-signaling.sh” in both containers, which runs the “SIPp” tool to generate and send signaling messages to the IP-telephony-server-VNF. 2.3.2. Check the scenario screen provided by execution of the previous step. The reception of a “200” response points out the appropriate functioning of the IP- telephony-server-VNF. 2.4. Validate that the network service is capable of processing the data traffic that is generated during an IP telephony call. With this purpose, the flow scheduling “Trafic” tool29 is installed in the "IP-phone-a" and "IP-phone-b" Linux containers. 2.4.1. Execute the following command to start the server agent of Trafic: “lxc exec IP- phone-b sh called-party.sh”. 2.4.2. Then, execute the following command to start the client agent of “Trafic” and get the network statistics: “lxc exec IP-phone-a sh caller.sh”. The data traffic emulating a voice call is terminated after 60 s. The script displays a confirmation message and the most significant performance metrics concerning the voice traffic. 2.4.3. Check the obtained metrics and verify that the IP telephony service can effectively support an interactive voice conversation (to this purpose, see the information included in the section on representative results). 3. UAVs Cloud Platform Construction 3.1. For the experiment, the Raspberry Pi (RPi) Model 3B has been chosen as an SBC capable of providing the virtualization substrate to execute lightweight VNFs. The technical specifications of this device are: 4 CPUs, 1 GB RAM, and 32 GB storage disk. Additionally, each RPi has three network interfaces: an Ethernet interface, an integrated Wi-Fiinterface, and an external Wi-Fi USB adapter. 3.2. Prepare the RPis to be subsequently integrated into the UAVs cloud platform. 3.2.1. Install Ubuntu Mate30 16.04.6 as Operating System, given that the OpenStack installation packages are included in this Linux distribution. 3.2.2. Install and configure the required packages as indicated in the OpenStack documentation31, to allow the RPis act as the compute nodes of the UAV cloud platform. In particular, and following the previous guide, enable the utilization of Linux containers in the configuration of the OpenStack packages (container virtualization is used due to the resource constraints of the devices that can typically be onboarded on small-sized UAVs). 3.2.3. Download and execute in the RPI the script “rpi-networking-configuration.sh”, available within the experiment repository. This script enables the wireless communications of the RPis, as well as the required configuration to allow the creation of virtual networks attached to the wireless interfaces. 3.2.4. Download and execute the script “VIM-networking-configuration.sh”, available within the experiment repository, in the host running the UAV cloud platform VIM. This script is in charge of setting up the wireless communications of the VIM to enable the information exchange with the RPis. NOTE: once the networking is well configured and the VIM has connectivity with the RPis, the VIM automatically integrates them into the UAV cloud platform as computational units capable of executing VNFs 3.3. Create an OpenStack availability zone for each of the RPIs. This will allow deploying each of the lightweight VNFs of the experiment in an appropriate UAV unit. More specifically, login into the web graphical user interface provided by the VIM with the administrator credentials, create the availability zones in the “Administrator > System > Host Aggregates” tab, and edit each availability zone to add the appropriate host (i.e., each RPi integrated into the UAV Cloud). 3.4. Verify the correct setup of the UAV cloud platform. With this purpose, access to the “Administrator > System > System Information” tab (with the same login as in the previous step), and click in the “Computing Service and Network Agents“ section to check that the status of the displayed items is “Alive” and “UP”. 4. Configuring the Experiment 4.1. Download the VNF images that implement the different components of the IP telephony service: the AP-VNF, the DNS-VNF, IP-telephony-server-VNF, the AR-VNF, and the CR- VNF. These images can be downloaded from the experiment repository. 4.2. Upload the VNF images to their correspondent VIM, i.e., the AP-VNF and the DNS-VNF to the UAV cloud platform VIM; and the VoIP-VNF to the core cloud platform VIM. More specifically, login into the web graphical user interface provided by each VIM with the administrator credentials, click on the “Create Image” button of the “Administrator > System > Images” tab, and create an image using the displayed form and selecting the appropriate image. This process is to be done at the corresponding VIM for each image that has been downloaded in the prior step. 4.3. Download the VNF descriptors (VNFDs) of the experiment from the experiment repository. These descriptors provide the templates that describe the operational requirements of a VNF, as well as the placement policies which indicate the availability zone in charge of hosting the VNF itself (more information on NFV descriptors can be found in the information model of OSM32). 4.4. Upload the VNFDs. Use a web browser to access the OSM graphical user interface, and sign with the administrator credentials. Then, drag and drop the VNFDs into the “VNF Packages” tab. 4.5. Download the NS descriptor (NSD) of the experiment from the experiment repository. This descriptor is a template that specifies the VNFs comprising the service, as well as how those VNFs are interconnected. 4.6. Upload the NSD. Drag and drop the NSD into the “NS Packages tab” of the OSM graphical user interface. 4.7. Using the graphical user interface of OSM, add a VIM account for the UAV cloud platform VIM and for the core cloud platform VIM. To do this, access the “VIM accounts” tab with the administrator user, click on the button “+ New VIM” and complete the displayed form with the requested information. Repeat this action for both VIMs. 5. Executing the Experiment 5.1. Deploy the network service. From the “NS packages tab” of the OSM graphical user interface, click on the “Instantiate NS” button of the NSD uploaded in step 5.6. Then, fill the displayed form, indicating the VIM that will be used to deploy each VNF composing the NS. In addition, OSM is responsible for processing the placement policies indicated in the VNFDs to specify the VIM which compute unit is in charge of hosting each VNF. For this experiment, the VNFs are placed in the compute units as illustrated in Figure 1. 5.2. Wait until the OSM graphical user interface indicates the success on the network service deployment. NOTE: The operation of the network service is totally independent from the flight of the UAVs (the IP telephony service can be provided when the UAVs are flying or saving battery- consumption perched on a surface). Thus, the step 5.3 is optional. 5.3. Take off the UAVs. Login into the mobile application and control the flight of each UAV to be maintained stabilized in an intermedium high and avoid the turbulences caused by the rotation of the motors close to a surface. 5.4. Prepare each of the IP phones to carry out the call. 5.4.1. Connect a wireless VoIP phone to each of the access point offered by the network service. For this purpose, specify the SSID (Service Set Identifier) in the “Menu > Wireless > SSID” tab and choose the Infrastructure mode in the “Menu > Wireless > Network Mode” section. Finally, select the networking configuration through Dynamic Host Configuration Protocol (DHCP) in the “Menu > Net Settings > Network Mode” tab. 5.4.2. Configure the Session Initiation Protocol (SIP) parameters to enable the appropriate exchange of signaling messages with the IP telephony server. In this context, access to the “Menu > SIP Settings” tab and specify the host name of the IP telephony server VNF (“dronesVoIP.net”) in the “Registrar > Registrar IP” and “Proxy Server > Proxy IP” tabs. Furthermore, create a user account introducing the name of the user (e.g., caller-A) in the “User Account > Phone Number” and “User Account > Username” sections. 5.4.3. Create an entry in the phonebook of one of the IP phones providing the information of the user that is to be called. To that end, select the “Menu > Phonebook > Add Entry“ tab, and fill in the requested parameters that appear in the display as follows: Display name: caller-B; User Info: caller-B; Host IP: dronesVoIP.net; Port: 5060. Finally select the “Proxy” option versus the P2P (peer- to-peer). 5.5. Start the call with the called-party. To that end, select the called-party using the “Menu > Phonebook > Search” option of the IP phone. Then, press the call button. Once the other IP phone starts ringing, accept the incoming call with the call button. 6. Procedure to gather experiment results 6.1. Connect a commodity laptop to one of the wireless APs and run the “ping” command line tool to the IP address of phone connected to the other AP during 180 s. The IP address can be checked in the “Menu > Information > IP address” option of the IP phone once the connection is established with the AP. Save the Round-Trip Time (RTT) measurements redirecting towards a file the output provided by the “ping” tool. 6.2. Execute the “tcpdump” command line tool in one of the running AP VNFs to capture the traffic exchanged during the IP call. Save this traffic into a file enabling the writing flag of the command line tool at the execution time and specifying the name of the file. 6.3. Perform a new IP telephony call. Maintain the call for the desired time period, e.g., 1 minute. Then, terminate the call, pressing the hang up button of one of the IP phones. 6.4. Keep the files generated by “tcpdump” and “ping” tools for further processing (see section on Representative Results). REPRESENTATIVE RESULTS: Based on the data obtained during the execution of the experiment, in which a real VoIP call is executed, and following the steps indicated by the protocol to gather this information, Figure 2 depicts the Cumulative Distribution Function of the end-to-end delay measured between two end-user equipment (i.e., a commodity laptop and an IP telephone). This user equipment represents two devices that are interconnected through the AP VNFs of the deployed network service. As it can be observed, more than 80% of the end-to-end delay measurements are below 60 ms, and none of them are higher than 150 ms, which guarantees appropriate delay metrics for the execution of a voice call. On the other hand, Figure 3 illustrates the exchange of DNS and SIP signaling messages. These messages correspond to the registration of one of the users in the IP telephony server (the user whose IP phone is connected to the AP VNF where the “tcpdump” tool is running), and to the establishment of the voice call. Finally, Figure 4 and Figure 5 show the data traffic captured during the call. In particular, the first one represents the constant stream of voice packets transmitted and received by one of the wireless phones during the call, whereas the latter illustrates the jitter in the forward direction with an average value lower than 1 ms. The results that have been obtained in the experiment for the delay figures (end-to-end delay and jitter) satisfy the recommendations specified by the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) 33. Accordingly, the voice call progressed with no glitches and good sound quality. This experiment has served to validate the practical feasibility of using NFV technologies and UAVs to deploy a functional IP telephony service. FIGURE AND TABLE LEGENDS: Figure 1. Overview of the network service, depicting the VNFs, the entities in which they are executed, and the virtual networks needed for the provision of the IP telephony service. Figure 2. End-to-end delay. Representation of the end-to-end delay offered to the end-user equipment connected to the AP VNFs. For this purpose, the Cumulative Distribution Function of the end-to-end delay has been computed from the measured RTT samples obtained with the “ping” command line tool. Figure 3. User registration and Call signalling messages. Illustration of the signalling traffic (DNS and SIP) exchanged to register a user in the IP telephony server, and to create and terminate the multimedia session that supports the execution of the voice call. Figure 4. Stream of Voice packets. Representation of the voice traffic exchanged during the call, measured at one of the AP VNFs. Figure 5. Evolution of the network Jitter during the call. Representation of the jitter endured by the transmitted voice packets in the forward direction from one phone to the other. DISCUSSION: One of the most relevant aspects presented during the development of this experiment is the use of virtualization technologies and NFV standards with UAV platforms. NFV presents a new paradigm aiming at decoupling the hardware dependency of the network functionalities, and thus enabling the provision of these functionalities through softwarization. Accordingly, the experiment does not imperatively depend on the use of the hardware equipment specified in the protocol. Alternatively, different models of single board computers can be selected, as long as they are in line with the dimensions and the transport capacity of the UAVs and they support Linux containers. Notwithstanding this flexibility in terms of hardware selection, all the content provided for the reproducibility of the experiment is oriented towards the use of open source technologies. In this context, the configuration aspects and the software tools are conditioned to the use of Linux as Operating System. On the other hand, the experiment considers the interoperation of two different computational platforms (i.e., the UAV cloud platform and the core cloud platform) to provide a moderately complex network service. However, this is not strictly needed, and the protocol could be followed to support scenarios in which only the UAV cloud platform is involved. Finally, it should be noted that the results presented have been obtained in a laboratory environment and with the UAV devices grounded or following a limited and well-defined flight plan. Other scenarios involving outdoor deployments may introduce conditions affecting the stability of the flight of the UAVs, and hence the performance of the IP telephony service. ACKNOWLEDGMENTS: This work was partially supported by the European H2020 5GRANGE project (grant agreement 777137), and by the 5GCIty project (TEC2016-76795-C6-3-R) funded by the Spanish Ministry of Economy and Competitiveness. The work of Luis F. Gonzalez was partially supported by the European H2020 5GinFIRE project (grant agreement 732497). DISCLOSURES: The authors have nothing to disclose. REFERENCES: 1. Sanchez‐Aguero, V., Nogales, B., Valera, F., & Vidal, I. Investigating the deployability of VoIP services over wireless interconnected Micro Aerial Vehicles. Internet Technology Letters, 1(5), e40 (2018). 2. Maxim, V., & Zidek, K. Design of high-performance multimedia control system for UAV/UGV based on SoC/FPGA Core. Procedia Engineering, 48, 402-408 (2012). 3. Vidal, I., Bellavista, P., Sanchez-Aguero, V., Garcia-Reinoso, J., Valera, F., Nogales, B., & Azcorra, A. Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications. Sensors, 18(10), 3421 (2018). 4. Vidal, I., Valera, F., Díaz, M. A., & Bagnulo, M. Design and practical deployment of a network- centric remotely piloted aircraft system. IEEE Communications Magazine, 52(10), 22-29 (2014). 5. Jin, Y., Minai, A. A., & Polycarpou, M. M. Cooperative real-time search and task allocation in UAV teams. In 42nd IEEE International Conference on Decision and Control (IEEE Cat. No. 03CH37475) (Vol. 1, pp. 7-12). IEEE (2003). 6. Maza, I., & Ollero, A. Multiple UAV cooperative searching operation using polygon area decomposition and efficient coverage algorithms. In Distributed Autonomous Robotic Systems 6 (pp. 221-230). Springer, Tokyo (2007). 7. Quaritsch, M. et al. Collaborative microdrones: applications and research challenges. In Proceedings of the 2nd International Conference on Autonomic Computing and Communication Systems (p. 38). ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering) (2008). 8. Waharte, S., Trigoni, N., & Julier, S. Coordinated search with a swarm of UAVs. In 2009 6th IEEE Annual Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks Workshops (pp. 1-3). IEEE (2009). 9. De Freitas, E. P. et al. UAV relay network to support WSN connectivity. In International Congress on Ultra-Modern Telecommunications and Control Systems (pp. 309-314). IEEE (2010). 10. European Telecommunications Standards Institute. Network Functions Virtualisation (NFV); Architectural Framework; Research Report ETSI GS NFV 002 V1.2.1; European Telecommunications Standards Institute (ETSI) (2014). 11. ETSI OSM. An Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. Available online: https://osm.etsi.org/ (last access on 3 June 2019). 12. Nogales, B., Vidal, I., Lopez, D. R., Rodriguez, J., Garcia-Reinoso, J., & Azcorra, A. Design and Deployment of an Open Management and Orchestration Platform for Multi-Site NFV Experimentation. IEEE Communications Magazine, 57(1), 20-27 (2019). 13. Omnes, N., Bouillon, M., Fromentoux, G., & Le Grand, O. A programmable and virtualized network & IT infrastructure for the internet of things: How can NFV & SDN help for facing the upcoming challenges. In the 18th International Conference on Intelligence in Next Generation Networks (pp. 64-69). IEEE (2015). 14. Rametta, C., & Schembra, G. Designing a softwarized network deployed on a fleet of drones for rural zone monitoring. Future Internet, 9(1), 8 (2017). 15. Garg, S., Singh, A., Batra, S., Kumar, N., & Yang, L. T. UAV-empowered edge computing environment for cyber-threat detection in smart vehicles. IEEE Network, 32(3), 42-51 (2018). 16. Mahmoud, S., Jawhar, I., Mohamed, N., & Wu, J. UAV and WSN softwarization and collaboration using cloud computing. In the 3rd Smart Cloud Networks & Systems (SCNS) (pp. 1-8). IEEE (2016). 17. González Blázquez, L. F., Vidal, I., Valera, F., Sanchez-Aguero, V., Nogales, B., & Lopez, D. R. NFV orchestration on intermittently available SUAV platforms: challenges and hurdles. In 1th Mission-Oriented Wireless Sensor, UAV and Robot Networking (MISARN). IEEE (2019). 18. Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F., & Garcia-Reinoso, J. A NFV system to support configurable and automated multi-UAV service deployments. In Proceedings of the 4th ACM Workshop on Micro Aerial Vehicle Networks, Systems, and Applications (pp. 39-44). ACM (2018, June). 19. Nogales, B., Sanchez-Aguero, V., Vidal, I., & Valera, F. Adaptable and automated small UAV deployments via virtualization. Sensors, 18(12), 4116 (2018). 20. Hoban, A. et al. An ETSI OSM Community White Paper, OSM Release FOUR: A Technical Overview; Whitepaper; European Telecommunications Standards Institute (ETSI) (2018). 21. OpenStack. Open Source Software for Creating Private and Public Clouds. Available online: https://docs.openstack.org/ocata (last access on 3 June 2019). 22. Linphone. An Open Source VoIP SIP Softphone for voice/video calls and instant messaging. Available online: https://www.linphone.org (last access on 3 June 2019). 23. Jitsi. An Open Source Project to easily build and deploy secure video-conferencing solutions. Available online: https://jitsi.org (last access on 3 June 2019). 24. Linux Containers (LXC). Infrastructure for container projects. Available online: https://linuxcontainers.org (last access on 3 June 2019). 25. Ns-3. A Discrete-Event Network Simulator for Internet Systems. Available online: https://www.nsnam.org/ (last access on 3 June 2019). 26. Kernel-based Virtual Machine (KVM). A virtualization solution for Linux. Available online: https://www.linux-kvm.org (last access on 3 June 2019). 27. Bridging & firewalling. Available online: https://wiki.linuxfoundation.org/networking/bridge (last access on 3 June 2019). 28. SIPp. An Open Source test tool and/or traffic generator for the SIP protocol. Available online: http://sipp.sourceforge.net/ (last access on 3 June 2019). 29. Trafic. An open source flow scheduler. Available online: https://github.com/5GinFIRE/trafic (last access on 3 June 2019). 30. Ubuntu Mate for the Raspberry Pi. Available online: https://ubuntu-mate.org/raspberry-pi/ (last access on 3 June 2019). 31. OpenStack Installation Tutorial for Ubuntu. Available online: https://docs.openstack.org/ocata/install-guide-ubuntu/ (last access on 3 June 2019). 32. Open Source MANO Information Model. Available online: https://osm.etsi.org/wikipub/index.php/OSM_Information_Model (last access on 3 June 2019). 33. ITU-T Recommendation G.114. General Recommendations on the transmission quality for an entire international telephone connection; One-way transmission time. International Telecommunication Union - Telecommunication Standardization Sector (2003). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505