方法文章

基于网络功能虚拟化的无人机互联网协议语音服务自动化部署

DOI：

10.3791/60425

⸱

2019年11月26日

 ,  ,  ,  ,  , 
1Department of Telematic Engineering, Universidad Carlos III de Madrid, 2IMDEA Networks Institute

* These authors contributed equally

本文内容

摘要

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

本方案的目标有两个：一是利用无人机作为提供基础架构的计算实体，构建一个网络功能虚拟化环境，以执行虚拟化网络功能；二是利用该环境支持在空中飞行器上自动部署功能完整的互联网协议电话服务。

摘要

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

网络功能虚拟化（NFV）范式是推动第五代（5G）及未来通信网络发展的关键技术之一th 移动网络的演进。该技术旨在通过虚拟化技术，在抽象层上实现网络功能与服务的软件化，从而降低对硬件的依赖。在此背景下，人们日益关注探索无人机（UAV）的潜力，以提供一种灵活的平台，能够在特定地理区域内实现具有成本效益的网络功能虚拟化（NFV）操作。

为了验证在无人机（UAV）平台上应用网络功能虚拟化（NFV）技术的实际可行性，本文提出了一种基于开源技术构建功能性NFV环境的实验方案，该方案利用一组小型无人机提供计算资源，以支持中等复杂度网络服务的部署。随后，该方案详细描述了在相互连接的无人机网络上，利用已配置的NFV环境实现互联网协议（IP）语音电话服务自动化部署所需的各个步骤。实验结果表明，该服务在部署后能够正常运行。尽管本方案聚焦于特定类型的网络服务（即IP语音电话），但所述步骤可作为部署其他类型网络服务的通用指南。另一方面，本方案的描述基于具体的硬件设备和软件来构建NFV环境（例如特定的单板计算机和开源软件）。虽然使用其他硬件和软件平台也是可行的，但NFV环境的具体配置细节以及服务部署过程可能与本方案所述存在差异。

引言

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

移动通信新时代（通常称为5th 移动通信技术或5G的目标是在主要通信基础设施可能无法使用的情况下（例如由于紧急情况）仍能提供可靠的信息化服务。在此背景下，无人机（UAVs）因其固有的多功能性而受到科研界日益增长的关注。已有大量研究将这些设备作为提供多种服务的核心支撑。例如，已有文献分析了这些设备构建空中通信基础设施以支持多媒体服务的能力1,2,3此外，先前的研究表明，多架无人机之间的协作能够扩展多种通信服务的功能，例如监控。4协作式搜救5,6,7,8，或农业综合企业9.

另一方面，网络功能虚拟化（NFV）技术作为5G的关键使能技术之一，在电信运营商中已获得重大意义。NFV通过将网络功能软件化，减轻了当前网络设备对专用硬件的依赖，从而实现了电信基础设施的范式变革，使得新型通信服务能够灵活、敏捷地部署。为此，欧洲电信标准协会（ETSI）成立了专门的规范组，以定义NFV的架构框架10。此外，ETSI目前还托管开源MANO（OSM）小组11，该小组负责开发符合ETSI NFV架构框架定义的NFV管理和编排（MANO）软件栈。

鉴于上述所有因素，目前研究人员正在探索无人机（UAV）与网络功能虚拟化（NFV）技术的协同融合，以开发新型网络应用与服务。文献中已有大量研究工作阐明了此类系统的优势14,15,16，指出了这种融合所面临的技术挑战及其尚不完善之处，强调了该领域未来的研究方向17，并提出了基于开源技术的开创性解决方案。

特别是，将网络功能虚拟化（NFV）技术集成到无人机（UAV）领域，能够实现网络服务和应用在特定地理区域（例如IP语音服务）内的快速且灵活部署。采用这一方法，可在特定位置部署多架无人机，以计算平台作为有效载荷（例如小型单板计算机）。这些计算平台将在部署区域内提供可编程的网络基础设施（即NFV基础设施），并在MANO平台的控制下支持网络服务和应用的实例化。

尽管存在上述优势，实现这一构想仍面临一系列需要妥善解决的根本性挑战，例如：如何将这些计算平台作为网络功能虚拟化（NFV）基础设施的一部分进行合理整合，并利用现有的NFV软件栈，使得NFV编排服务能够在无人机（UAV）上部署虚拟网络功能；计算平台所提供的计算资源受限的问题，因为运载这些平台的无人机在有效载荷设备的尺寸、重量和计算能力方面通常存在限制；虚拟网络功能在无人机上的合理部署（即选择最适合部署特定虚拟网络功能的无人机候选者）；维持与无人机的控制通信，以便在与无人机的网络通信可能间歇性中断（例如由于移动性或电池限制）的情况下仍能管理虚拟网络功能（VNF）的生命周期；由于电池消耗导致无人机运行时间有限；以及当某架无人机因电量耗尽需要更换时，虚拟网络功能的迁移问题。这些优势与挑战在先前的研究18,19中已有详细阐述，相关研究包括设计一种能够支持在无人机平台上自动部署网络功能与服务的NFV系统，并验证该设计方案实际可行性的实验工作。

在此背景下，本文重点描述一种基于网络功能虚拟化（NFV）标准和开源技术，在无人机（UAV）网络上实现中等复杂度网络服务自动化部署的协议。为说明该协议的各个步骤，本文重新阐述了Nogales等人19所提出实验中的一个案例，即IP语音电话服务的部署。为便于本研究的可重复性，所呈现的流程中将实际飞行视为可选步骤，性能测试结果均通过地面状态的无人机设备获得。感兴趣的读者即使在受控的实验室环境中，也应能够复现并验证该协议的执行过程。

图1 展示了为本实验设计的网络服务。该网络服务由特定的软件化单元（在NFV范式中被归类为虚拟网络功能，即VNFs）组合构建而成，可为无人机（UAV）附近用户提供IP语音电话服务。构成该服务的VNF定义如下：

  • 接入点虚拟网络功能（AP-VNF）：该虚拟网络功能为终端设备（在本实验中即IP电话）提供Wi-Fi接入服务。
  • IP语音服务器虚拟网络功能（IP-telephony-server-VNF）：负责管理IP电话之间为建立和终止语音通话而交换的呼叫信令消息。
  • 域名系统虚拟网络功能（DNS-VNF）：该虚拟网络功能提供域名解析服务，在IP语音通信服务中通常需要此功能。
  • 接入路由器虚拟网络功能（AR-VNF）：提供网络路由功能，支持IP电话与电信运营商域之间的通信流量（在本实验中即呼叫信令）交换。
  • 核心路由器虚拟网络功能（CR-VNF）：在电信运营商域内提供网络路由功能，实现对运营商特定服务（如IP语音服务器）以及外部数据网络的访问。

此外，图1 展示了实验所用的物理设备、设备之间的互连方式，以及虚拟网络功能（VNF）在设备上的具体分配情况。

方案

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

1. Prior requisites for the experiment

  1. Install 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 in a Virtual Machine (VM) fulfilling the requirements specified by the OSM community: Ubuntu 16.04 as the operating system (64-bit variant image), two central processing units (CPUs), 8 GB random access memory (RAM), a 40 GB storage disk, and a single network interface with Internet access. The procedure to install OSM Release FOUR along with its technical details are available in the online documentation provided by the OSM community21.
  2. Set up a cloud computing platform, providing the functions of a virtual infrastructure manager (VIM) compliant with OSM Release FOUR. For this experiment, OpenStack release Ocata22 is used, running in a VM with Ubuntu 16.04 as the operating system, four CPUs, 16 GB RAM, and 200 GB storage disk. In the experiment, the VIM manages an NFV infrastructure (NFVI) integrated by two high-profile server computers, each with Ubuntu 16.04 as the operating system, eight CPUs, 128 GB RAM, and 4 TB storage disk). All the information on how to set up a cloud computing platform is included in the installation guide included in the OpenStack documentation23. This cloud platform is referred to as the core cloud platform.
  3. Set up an additional cloud computing platform for the UAVs is referred to as the UAVs cloud platform.
    1. Ensure that this platform features a VIM based on OpenStack release Ocata. In this case, the resources used by the VIM installation are Ubuntu 16.04 as operating system, two CPUs, 6 GB RAM, 100 GB storage disk, and an external Wi-Fi USB adapter.
    2. The NFVI integrated in this cloud platform consists of a single fixed compute server (Ubuntu 16.04 as operating system, eight CPUs, 8 GB RAM, 128 GB storage disk, and an external Wi-Fi USB adapter) and three single board computers (SBCs). The latter provide a hardware platform that can easily be onboarded on a UAV. See Section 3 for the procedure to setup a UAV cloud platform with these devices as compute nodes.
  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: Step 1.5 is optional because the provision of the network service in the experiment does not depend on having UAVs. In addition, the SBCs are carried as the payload of the UAVs and no other additional connections (e.g., Ethernet or USB) are needed, because the network communications required for the proper operation of the IP telephony service are provided by the SBCs, through their Wi-Fi adapters, and the power supply is provided by the power-supply HAT mentioned in step 1.4.
  5. Attach each SBC as the payload of a UAV through a fixing accessory. In this experiment, three commercial UAVs were chosen to transport the compute units offered by the SBCs.
  6. Select two wireless voice-over-IP (VoIP) phones that support the IEEE 802.11b wireless communications standard; this model provides wireless communications via Wi-Fi. As an alternative, the voice call could be executed using softphone applications such as Linphone24 or Jitsi25.
  7. As an experimental requirement, make sure of 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, b) layer-3 communications between the OSM and the VNFs 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.
  8. All the content needed to carry out the experiment is provided in the public experiment repository http://vm-images.netcom.it.uc3m.es/JoVE/.

2. Validating 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, a purpose-specific emulation platform based on Linux containers26 and ns-327 was used. This platform allows emulating multi-hop aerial links and defining the characteristics of those links (e.g., length of the wireless communication links, pattern of data packet losses, the radio technology used in the wireless communications, etc.). Thus, this section of the protocol describes the steps to be followed to verify the appropriate operation of the IP telephony service under realistic wireless communication link conditions through the emulation platform.

  1. Download the emulation platform from the experiment repository. The platform is available as a virtual machine, named "uav-nfv-jove-experiment.qcow", compliant with the KVM virtualization technology28. This machine contains a precreated 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 bridges29); b) the Linux Containers representing the different physical components of the testbed (i.e., the SBCs and the fixed compute server for the UAV cloud platform, and the compute server for the core cloud platform) are created; and c) the functions provided by the different VNFs of the IP telephony service (i.e., access points, routers, DNS serve, and IP telephony server) are deployed as Linux Containers over their corresponding emulated SBCs and compute servers.
  2. Before the validation process, set up an emulated multi-hop aerial network using the ns-3 simulator, in order to enable the connectivity between the different network participants. This procedure will emulate the realistic wireless communications that take place in the scenario depicted in Figure 1 (i.e., the Wi-Fi ad-hoc network, which enables the data exchange among the nodes of the UAV cloud platform and the wireless networks offered by the two Wi-Fi access points provided in the service).
    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 &. This command portrays the simulation trace in the specified log-file to enable debugging in the case of errors.
    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 Figure 1 as the end-user equipment that connects to an AP-VNF) have obtained an IP address through the DHCP service, which is 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 command lxc list.
  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" tool30. "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 the latter.
    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. Check the scenario screen provided by execution of the previous step. The reception of "200" response shows the appropriate functioning of the IP-telephony-server-VNF.
  4. Validate that the network service can process the data traffic that is generated during an IP telephony call. To do so, the flow scheduling "Trafic" tool31 is installed in the "IP-phone-a" and "IP-phone-b" Linux containers.
    1. Execute the following command to start the server agent of Trafic: lxc exec IP-phone-b sh called-party.sh.
    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.
    3. Check the obtained metrics and verify that the IP telephony service can effectively support an interactive voice conversation. To do so, see the information included in the section on representative results.

3. UAVs cloud platform construction

  1. Select the model of SBC that can provide the virtualization substrate to execute lightweight VNFs. The technical specifications of the SBC devices utilized during the experiment are: four CPUs, 1 GB RAM, and a 32 GB storage disk. Additionally, each SBC has three network interfaces: an Ethernet interface, an integrated Wi-Fi interface, and an external Wi-Fi USB adapter.
  2. Prepare the SBCs to be subsequently integrated into the UAVs cloud platform.
    1. Install Ubuntu Mate32 16.04.6 as the operating system, given that the OpenStack installation packages are included in this Linux distribution.
    2. Install and configure the required packages as indicated in the OpenStack documentation33 to allow the SBCs to act as the compute nodes of the UAV cloud platform. 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. In the SBC, download and execute the script rpi-networking-configuration.sh, available within the experiment repository. This script enables the wireless communications of the SBCs, as well as the required configuration to allow the creation of virtual networks attached to the wireless interfaces.
    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 oversees setting up the wireless communications of the VIM to enable the information exchange with the SBCs.
      NOTE: Once the networking is well configured and the VIM has connectivity with the SBCs, the VIM automatically integrates them into the UAV cloud platform as computational units capable of executing VNFs
  3. Create an OpenStack availability zone for each of the SBCs. This will allow deploying each of the lightweight VNFs of the experiment in an appropriate UAV unit. To do so, log in to 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 SBC integrated into the UAV cloud platform).
  4. Verify the correct setup of the UAV cloud platform. To do so, access 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 ch­­eck that the status of the displayed items is "Alive" and "UP".

4. Configuring the experiment

  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.
  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. To do so, log in 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 done at the corresponding VIM for each image that has been downloaded in the prior step.
  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 that indicate the availability zone in charge of hosting the VNF itself. More information on NFV descriptors can be found in the information model of OSM34.
  4. Upload the VNFDs. Use a web browser to access the OSM graphical user interface, and sign in with the administrator credentials. Then, drag and drop the VNFDs into the VNF Packages tab.
  5. Download the network services descriptor (NSD) from the experiment repository. This descriptor is a template that specifies the VNFs comprising the service, as well as how those VNFs are interconnected.
  6. Upload the NSD. Drag and drop the NSD into the NS Packages tab of the OSM graphical user interface.
  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 credentials, 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

  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 4.6. Then, fill the displayed form, indicating the VIM that will be used to deploy each VNF composing the NS. In addition, the OSM is responsible for processing the placement policies indicated in the VNFDs to specify the VIM which availability zone (i.e., a compute unit in our testbed) is in charge of hosting each VNF. For this experiment, the VNFs are placed in the compute units as illustrated in Figure 1.
    NOTE: As an alternative method, the OSM provides a command line interface that enables direct user interaction. A user reproducing this experiment can use this command line interface, instead of the graphical interface, to execute the different steps defined in this protocol, particularly those steps related with onboarding a VNF or an NS descriptor, as well as deploying a network service.
  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, step 5.3 is optional.
  3. Take off the UAVs. Log in to the mobile application and control the flight of each UAV to stably maintain it in an intermediate height and avoid the turbulence caused by the rotation of the motors close to a surface.
  4. Prepare each of the IP phones to carry out the call.
    1. Connect a wireless VoIP phone to each of the access points 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 the Dynamic Host Configuration Protocol (DHCP) in the Menu > Net Settings > Network Mode tab.
    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.
    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 do so, 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. Start the call to the other party. To do so, 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 experimental results

  1. Connect a commodity laptop to one of the wireless APs and run the ping command line tool to the IP address of the 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 the output provided by the ping tool into a file.
  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.
  3. Perform a new IP telephony call. Maintain the call for the desired time period (e.g., 1 min). Then, terminate the call, pressing the hang up button of one of the IP phones.
  4. Keep the files generated by the tcpdump and ping tools for further processing. See Representative Results.

结果

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

根据实验执行过程中获取的数据，在实际 VoIP 通话中按照协议指示的步骤收集这些信息后，图2展示了在两个终端用户设备（即一台普通笔记本电脑和一部IP电话）之间测得的端到端延迟的累积分布函数。这些用户设备通过已部署网络服务中的AP虚拟网络功能（VNF）相互连接。超过80%的端到端延迟测量值低于60 ms，且没有任何测量值超过150 ms，这保证了语音通话执行时具备合适的延迟指标。

图3展示了DNS和SIP信令消息的交换过程。这些消息对应于IP电话服务器中一个用户的注册（即其IP电话连接到运行“tcpdump”工具的AP VNF上的用户）以及语音呼叫的建立过程。

最后，图4 和 图5 展示了通话期间捕获的数据流量。具体而言，前者表示通话期间由其中一部无线电话发送和接收的语音数据包的稳定流，而后者则显示前向方向的抖动，其平均值低于 1 ms。

实验中获得的延迟数据（端到端延迟和抖动）满足国际电信联盟电信标准化部门（ITU-T）35 所规定的建议值。因此，语音通话过程无异常，音质良好。本实验验证了利用网络功能虚拟化（NFV）技术和无人机（UAV）部署功能性IP语音服务的实际可行性。

无人机云平台网络示意图；虚拟化、Wi-Fi、单板计算机、虚拟机、云基础设施、连接性。
图1：网络服务概览，展示了虚拟化网络功能（VNF）、其执行所依赖的实体，以及提供IP语音服务所需的虚拟网络。 请点击此处查看此图的放大版本。

网络数据传输中端到端延迟（ms）的累积分布函数图分析。
图 2：端到端延迟。 表示连接至 AP VNF 的终端用户设备所经历的端到端延迟。为此，基于使用“ping”命令行工具测得的 RTT 样本数据，计算了端到端延迟的累积分布函数。 请点击此处查看该图的放大版本。

网络吞吐量图，SIP 与 DNS 数据分析，折线图，时间（秒）与比特，结果对比。
图 3：用户注册与呼叫信令消息。 图示在 IP 电话服务器中注册用户以及建立和终止支持语音呼叫执行的多媒体会话过程中交换的信令流量（DNS 和 SIP）。请点击此处查看该图的放大版本。

网络吞吐量图、RTP 数据包分析、时间与吞吐量关系、传输与接收对比
图 4：语音数据包流。 通话期间在其中一个 AP VNF 上测得的语音流量示意图。（缩写：RX = 接收，TX = 发送，RTP = 实时传输协议）。请点击此处查看此图的放大版本。

网络抖动分析图，数据包数量与抖动（ms）关系，数据传输变异性研究。
图 5：通话期间网络抖动的变化情况。 显示语音数据包从一部电话向另一部电话单向传输过程中所经历的抖动情况。请点击此处查看该图的放大版本。

讨论

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

本实验最重要的方面之一是将虚拟化技术和网络功能虚拟化（NFV）标准与无人机（UAV）平台结合使用。NFV 提出了一种新范式，旨在解除网络功能对硬件的依赖性，从而通过软件化方式提供这些功能。因此，本实验不依赖于协议中指定的硬件设备。只要单板计算机的尺寸和承载能力与无人机相匹配，并支持 Linux 容器，即可选用不同型号的单板计算机。

尽管在硬件选择上具有灵活性，但为确保实验可重复性所提供的所有内容均以使用开源技术为导向。在此背景下，配置方面和软件工具均以采用 Linux 作为操作系统为前提条件。

另一方面，该实验考虑了两种不同计算平台（即无人机云平台与核心云平台）之间的协同操作，以提供一种中等复杂度的网络服务。然而，这种双平台协作并非严格必需，本协议也可用于仅涉及无人机云平台的场景。

此外，所提出的解决方案还可能适用于其他环境，例如在资源受限的硬件平台上具备执行虚拟化容器所需能力的场景（如物联网，即 IoT 环境）。无论何种情况，该解决方案在不同环境中的适用性及其潜在的适应性调整，均需针对具体案例进行逐一深入研究。

最后需要指出的是，本文所呈现的结果均在实验室环境中获得，且无人机设备处于接地状态或遵循有限且明确定义的飞行计划。其他涉及室外部署的场景可能会引入影响无人机飞行稳定性的条件，从而影响IP语音服务的性能。

披露

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

作者无任何利益冲突需要披露。

致谢

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

本工作部分得到了欧洲H2020 5GRANGE项目（资助协议编号777137）以及西班牙经济与竞争力部资助的5GCIty项目（TEC2016-76795-C6-3-R）的支持。Luis F. Gonzalez的工作部分得到了欧洲H2020 5GinFIRE项目（资助协议编号732497）的支持。

材料

本文使用的材料清单
姓名公司目录编号评论
AR. Drone 2.0 - 精英版鹦鹉用于实验的无人机，负责运输树莓派（RPis），从而为无人机云平台的计算单元提供移动性。
Bebop 2鹦鹉用于实验中的无人机，以运输树莓派（RPis），从而为无人机云平台的计算单元提供移动性。
商用英特尔酷睿 Mini-ITX 计算机逻辑电源用于托管实验无人机云平台的 OpenStack 控制节点（以虚拟机形式运行）的计算机服务器。此外，该设备的另一台单元（与树莓派共同组成）构成了无人机云平台的计算资源。
Linux 容器（LXC）Canonical Ltd.（软件）虚拟化技术，可实现本实验中所述虚拟网络功能的供应。源代码可在线获取：https://linuxcontainers.org
锂电池组扩展板。型号 KY68C-UKKuman用于无人机云平台计算单元（即树莓派）的电池供电HAT（硬件附加模块），此外，该设备还包括用于将计算单元（即树莓派或RPis）安装固定到无人机上的外壳组件。
MacBook Pro苹果实验过程中使用普通笔记本电脑获取并收集手稿中所述结果。
ns-3 网络模拟器nsnam（软件）一种离散事件模拟器网络模拟器，为前述仿真站提供底层通信基质 "实验方案" 部分（更具体地说是在步骤中） "2. 通过仿真验证软硬件化单元的功能性"）。源代码可在线获取：https://www.nsnam.org
开源MANO（OSM）- FOUR版本ETSI OSM - 开源社区（软件）实验中配置的网络功能虚拟化（NFV）系统的管理与编排（MANO）软件栈。源代码可在线获取：https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Ocata 版本发布OpenStack - 开源社区（软件）用于搭建实验中的无人机云平台和核心云的开源软件。源代码可在线获取：https://docs.openstack.org/ocata/install-guide-ubuntu
Ping开源工具（软件）一种开源测试工具，用于验证通过通信网络连接的两个设备之间的连通性。此外，该工具还可用于评估网络性能，因为它能够计算往返时间（即发送数据包并从网络接收响应所需的时间）。源代码可在线获取：https://packages.debian.org/es/sid/iputils-ping
Power Edge R430戴尔提供实验中所述核心云平台计算能力的高性能计算机服务器。
Power Edge R630戴尔用于托管执行MANO栈的虚拟机（VM）的设备。此外，OpenStack控制器节点也作为虚拟机在此设备上运行。需要注意的是，该设备的使用并非严格必需，由于上述虚拟机的资源需求不高，这些操作也可由性能较低的设备完成。
Prestige 2000WZyXEL支持 IEEE 802.11b 无线通信标准的网络电话（VoIP Wi-Fi 电话）。该设备用于通过实验所用平台提供的网络服务进行网络电话（VoIP）呼叫。
树莓派 3b 型号Raspberry Pi 基金会用于为实验的无人机云平台提供计算能力的单板计算机（SBC）选型模型。
SIPp开源工具（软件）一种开源测试工具，可生成SIP协议流量。该工具可用于验证IP电话服务中所需信令流量的正确支持，例如本实验中部署的服务。源代码可在线获取：http://sipp.sourceforge.net
Tcpdump开源工具（软件）一款开源工具，可实现网络流量的捕获与分析。源代码可在线获取：https://www.tcpdump.org
交通开源工具（软件）一种开源的流调度器，用于验证部署的网络服务处理IP语音通话期间产生数据流量的能力。源代码可在线获取：https://github.com/5GinFIRE/trafic

参考文献

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  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), 40(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., et al. 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. 42nd IEEE International Conference on Decision and Control. 1, IEEE. IEEE Cat. No. 03CH37475 7-12 (2003).
  6. Maza, I., Ollero, A. Multiple UAV cooperative searching operation using polygon area decomposition and efficient coverage algorithms. Distributed Autonomous Robotic Systems. 6, Springer. Tokyo. 221-230 (2007).
  7. Quaritsch, M., et al. Collaborative microdrones: applications and research challenges. Proceedings of the 2nd International Conference on Autonomic Computing and Communication Systems. , ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering. 38(2008).
  8. Waharte, S., Trigoni, N., Julier, S. Coordinated search with a swarm of UAVs. 2009 6th IEEE Annual Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks Workshops. , IEEE. 1-3 (2009).
  9. De Freitas, E. P., et al. UAV relay network to support WSN connectivity. International Congress on Ultra-Modern Telecommunications and Control Systems. , IEEE. 309-314 (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. An Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. ETSI OSM. , Available from: https://osm.etsi.org/ (2019).
  12. Nogales, B., et al. 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. 18th International Conference on Intelligence in Next Generation Networks. , IEEE. 64-69 (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. 3rd Smart Cloud Networks & Systems (SCNS). , IEEE. 1-8 (2016).
  17. González Blázquez, L. F., et al. NFV orchestration on intermittently available SUAV platforms: challenges and hurdles. 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. Proceedings of the 4th ACM Workshop on Micro Aerial Vehicle Networks, Systems, and Applications. , ACM. 39-44 (2018).
  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. European Telecommunications Standards Institute. (ETSI). , Whitepaper (2018).
  21. Quick start installation and use guide. Open Source MANO Release FOUR. , Available from: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR (2019).
  22. Open Source Software for Creating Private and Public Clouds. OpenStack. , Available from: https://docs.openstack.org/ocata (2019).
  23. OpenStack Installation Tutorial for Ubuntu. OpenStack. , Available from: https://docs.openstack.org/ocata/install-guide-ubuntu/ (2019).
  24. Linphone. An Open Source VoIP SIP Softphone for voice/video calls and instant messaging. Linphone. , Available from: https://www.linphone.org (2019).
  25. An Open Source Project to easily build and deploy secure video-conferencing solutions. Jitsi. , Available from: https://jitsi.org (2019).
  26. Infrastructure for container projects. Linux Containers (LXC). , Available from: https://linuxcontainers.org (2019).
  27. A Discrete-Event Network Simulator for Internet Systems. Ns-3. , Available from: https://www.nsnam.org/ (2019).
  28. Kernel-based Virtual Machine (KVM). A virtualization solution for Linux. Linux. , Available from: https://www.linux-kvm.org (2019).
  29. Bridging & firewalling. Linux Foundation. , Available from: https://wiki.linuxfoundation.org/networking/bridge (2019).
  30. An Open Source test tool and/or traffic generator for the SIP protocol. SIPp. , Available from: http://sipp.sourceforge.net/ (2019).
  31. Trafic. An open source flow scheduler. , Available from: https://github.com/5GinFIRE/trafic (2019).
  32. Ubuntu Mate for the Raspberry Pi. , Available from: https://ubuntu-mate.org/raspberry-pi/ (2019).
  33. Enabling LXC (Linux Containers) as virtualization technology. OpenStack. , Available from: https://docs.openstack.org/ocata/config-reference/compute/hypervisor-lxc.html (2019).
  34. Open Source MANO Information Model. , Available from: https://osm.etsi.org/wikipub/index.php/OSM_Information_Model (2019).
  35. ITU-T. 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).

重印与许可

申请许可以重复使用本 JoVE 文章的文本或图表

申请许可

标签

IP VNF OSM VIM

相关文章