Automatisierte Bereitstellung eines Internetprotokoll-Telefoniedienstes für unbemannte Luftfahrzeuge mit Netzwerkfunktionsvirtualisierung

Summary

Das Ziel des beschriebenen Protokolls besteht in zweierlei Hinsicht: Die Konfiguration einer Virtualisierungsumgebung für Netzwerkfunktionen mithilfe unbemannter Luftfahrzeuge als Recheneinheiten, die die zugrunde liegende Struktur für die Ausführung virtualisierter Netzwerkfunktionen bereitstellen und diese Umgebung zur Unterstützung der automatisierten Bereitstellung eines funktionalen Internetprotokolltelefoniedienstes über die Luftfahrzeuge.

Abstract

Das Paradigma der Netzwerkfunktion Virtualisierung (NFV) ist eine der schlüsselnden Technologien für die Entwicklung der^5. Generation von Mobilfunknetzen. Diese Technologie zielt darauf ab, die Abhängigkeit von Hardware bei der Bereitstellung von Netzwerkfunktionen und -diensten zu verringern, indem Virtualisierungstechniken verwendet werden, die die Softwarisierung dieser Funktionalitäten über eine Abstraktionsebene ermöglichen. In diesem Zusammenhang wächst das Interesse, das Potenzial unbemannter Luftfahrzeuge (UAVs) zu erkunden, um eine flexible Plattform zu bieten, die einen kostengünstigen NFV-Betrieb in abgegrenzten geografischen Gebieten ermöglicht.

Um die praktische Durchführbarkeit der Verwendung von NFV-Technologien in UAV-Plattformen zu demonstrieren, wird ein Protokoll zur Einrichtung einer funktionalen NFV-Umgebung auf Basis von Open-Source-Technologien vorgestellt, in der eine Reihe kleiner Drohnen die Rechenressourcen bereitstellt, die die Bereitstellung von mäßig komplexen Netzwerkdiensten. Anschließend werden im Protokoll die verschiedenen Schritte beschrieben, die erforderlich sind, um die automatisierte Bereitstellung eines IP-Telefoniedienstes (Internet Protocol) über ein Netzwerk miteinander verbundener UAVs zu unterstützen und dabei die Kapazitäten der konfigurierten NFV-Umgebung zu nutzen. Die Ergebnisse der Experimente zeigen den ordnungsgemäßen Betrieb des Dienstes nach der Bereitstellung. Obwohl sich das Protokoll auf einen bestimmten Typ von Netzwerkdiensten (d. h. IP-Telefonie) konzentriert, können die beschriebenen Schritte als allgemeiner Leitfaden für die Bereitstellung anderer Netzwerkdienste dienen. Andererseits berücksichtigt die Protokollbeschreibung konkrete Geräte und Software zur Einrichtung der NFV-Umgebung (z. B. spezifische Einplatinencomputer und Open-Source-Software). Die Nutzung anderer Hardware- und Softwareplattformen kann möglich sein, obwohl der spezifische Konfigurationsaspekt der NFV-Umgebung und der Dienstbereitstellung Abweichungen in Bezug auf die im Protokoll beschriebenen darstellen kann.

Introduction

Eines der begehrtesten Ziele in der neuen Ära der Mobilkommunikation (am häufigsten bekannt als die^5. Mobilfunkgeneration oder 5G) besteht darin, robuste IT-Dienste in Situationen anbieten zu können, in denen die primäre Telekommunikationsinfrastruktur möglicherweise nicht verfügbar ist (z. B. aufgrund eines Notfalls). In diesem Zusammenhang erhalten die Drohnen aufgrund ihrer inhärenten Vielseitigkeit zunehmend Aufmerksamkeit von der Forschungsgemeinschaft. Es gibt zahlreiche Werke, die diese Geräte als Eckpfeiler für die Bereitstellung einer Vielzahl von Dienstleistungen verwenden. Zum Beispiel hat die Literatur die Kapazität dieser Geräte analysiert, um eine Luftkommunikationsinfrastruktur für Multimedia-Dienste^1,2,3unterzubringen. Darüber hinaus haben frühere Untersuchungen gezeigt, wie die Zusammenarbeit zwischen mehreren Drohnen die Funktionalität verschiedener Kommunikationsdienste wie Überwachung^4,kollaborative Suche und Rettung^5,6,7,8oder Agribusiness⁹erweitern kann.

Andererseits hat die NFV-Technologie bei den Telekommunikationsbetreibern als einer der 5G-Schlüsselermöglicher an Bedeutung gewonnen. NFV stellt einen paradigmatischen Wandel in Bezug auf die Telekommunikationsinfrastruktur dar, indem die aktuelle Abhängigkeit von Netzwerkgeräten von spezialisierter Hardware durch die Softwarisierung der Netzwerkfunktionalitäten gemildert wird. Dies ermöglicht eine flexible und agile Bereitstellung neuer Arten von Kommunikationsdiensten. Zu diesem Zweck bildete das European Telecommunications Standards Institute (ETSI) eine Spezifikationsgruppe, um den NFV-Architekturrahmen¹⁰zu definieren. Darüber hinaus beherbergt das ETSI derzeit die Open Source Mano (OSM) Gruppe¹¹, die für die Entwicklung eines NFV Management and Orchestration (MANO) Software-Stacks verantwortlich ist, der auf die Definition des ETSI NFV-Architekturframeworks ausgerichtet ist.

Unter Berücksichtigung all der vorgenannten Überlegungen wird derzeit die synergische Konvergenz zwischen Drohnen und NFV-Technologien bei der Entwicklung neuartiger Netzwerkanwendungen und -dienste untersucht. Dies wird durch mehrere Forschungsarbeiten in der Literatur veranschaulicht, die die Vorteile dieser Arten von Systemen^14,15,16aufzeigen, die Herausforderungen dieser Konvergenz und ihre fehlenden Aspekte identifizieren, zukünftige Forschungslinien zu diesem Thema¹⁷aufzeigen und Pionierlösungen auf Basis von Open-Source-Technologien präsentieren.

Insbesondere die Integration von NFV-Technologien in die UAV-Arena ermöglicht die schnelle und flexible Bereitstellung von Netzwerkdiensten und -anwendungen über abgegrenzte geografische Gebiete (z. B. einen IP-Telefoniedienst). Nach diesem Ansatz können eine Reihe von UAVs an einem bestimmten Standort bereitgestellt werden, wodurch Computeplattformen als Nutzlast transportiert werden (z. B. kleine Einzelplatinencomputer). Diese Computeplattformen würden eine programmierbare Netzwerkinfrastruktur (d. h. eine NFV-Infrastruktur) über den Bereitstellungsbereich bereitstellen und die Instanziierung von Netzwerkdiensten und -anwendungen unter der Kontrolle einer MANO-Plattform unterstützen.

Ungeachtet der Vorteile stellt die Verwirklichung dieser Ansicht eine Reihe grundlegender Herausforderungen dar, die sorgfältig angegangen werden müssen, wie z. B. die entsprechende Integration dieser Computeplattformen als NFV-Infrastruktur mithilfe eines vorhandenen NFV-Software-Stacks, sodass ein NFV-Orchestrierungsdienst virtuelle Funktionen auf den Drohnen bereitstellen kann; die Einschränkungen in Bezug auf die Rechenressourcen, die von den Rechenplattformen bereitgestellt werden, da die Drohnen, die sie transportieren, in der Regel Einschränkungen in Bezug auf Größe, Gewicht und Rechenkapazität von Nutzlastgeräten aufweisen können; die ordnungsgemäße Platzierung der virtuellen Funktionen auf Drohnen (d. h. die Auswahl des besten UAV-Kandidaten für die Bereitstellung einer bestimmten virtuellen Funktion); die Aufrechterhaltung der Steuerungskommunikation mit den UAVs, um den Lebenszyklus der VNFs trotz der potenziell intermittierenden Verfügbarkeit der Netzwerkkommunikation mit ihnen zu verwalten (z. B. aufgrund von Mobilitäts- und Batteriebeschränkungen); die begrenzte Betriebszeit der Drohnen aufgrund ihres Batterieverbrauchs; und die Migration der virtuellen Funktionen, wenn ein UAV aufgrund seiner Batterieerschöpfung ausgetauscht werden muss. Diese Vorteile und Herausforderungen werden in früheren Arbeiten^18,19 beschrieben, die das Design eines NFV-Systems umfassen, das die automatisierte Bereitstellung von Netzwerkfunktionen und -diensten auf UAV-Plattformen unterstützen kann, sowie die Validierung der praktischen Durchführbarkeit dieses Entwurfs.

In diesem Zusammenhang konzentriert sich dieses Dokument auf die Beschreibung eines Protokolls, das die automatisierte Bereitstellung von mäßig komplexen Netzwerkdiensten über ein Netzwerk von UAVs unter Verwendung der NFV-Standards und Open-Source-Technologien ermöglicht. Zur Veranschaulichung der verschiedenen Schritte des Protokolls wird eine Neuausarbeitung eines in Nogales et al.¹⁹ vorgestellten Experiments vorgestellt, das aus der Bereitstellung eines IP-Telefoniedienstes besteht. Um die Reproduzierbarkeit dieser Arbeit zu unterstützen, wird der reale Flug im vorgestellten Verfahren als fakultativ betrachtet, und mit den UAV-Geräten am Boden werden Leistungsergebnisse erzielt. Interessierte Leser sollten in der Lage sein, die Ausführung des Protokolls zu replizieren und zu validieren, auch in einer kontrollierten Laborumgebung.

Abbildung 1 zeigt den Netzwerkdienst, der für dieses Verfahren entwickelt wurde. Dieser Netzwerkdienst wird als Eine Komposition spezifischer Softwarisierungseinheiten (innerhalb des NFV-Paradigmas als Virtual Network Functions oder VNFs kategorisiert) erstellt und stellt Benutzern in der Nähe der UAVs die Funktionalität eines IP-Telefoniedienstes zur Verfügung. Der VNF, der den Dienst zusammenstellt, ist wie folgt definiert:

• Access Point VNF (AP-VNF): Dieser VNF bietet einen WLAN-Zugriffspunkt für Endbenutzergeräte (d. h. IP-Telefone in diesem Experiment).
• IP-Telefonieserver VNF (IP-telephony-server-VNF): Er ist für die Verwaltung der Anrufsignalmeldungen verantwortlich, die zwischen IP-Telefonen ausgetauscht werden, um einen Sprachanruf einzurichten und zu beenden.
• Domain Name System VNF (DNS-VNF): Dieser VNF stellt einen Namensauflösungsdienst bereit, der in der Regel in IP-Telefoniediensten benötigt wird.
• Access Router VNF (AR-VNF): bietet Netzwerk-Routing-Funktionalitäten, die den Austausch von Datenverkehr (d. h. Rufsignalisierung in diesem Experiment) zwischen den IP-Telefonen und der Telekommunikationsbetreiberdomäne unterstützen.
• Core-Router VNF (CR-VNF): bietet Netzwerk-Routing-Funktionalitäten in der Telekommunikationsbetreiber-Domäne und bietet Zugriff auf betreiberspezifische Dienste (d. h. den IP-Telefonieserver) und externe Datennetze.

Darüber hinaus zeigt Abbildung 1 die für das Experiment verwendeten physischen Geräte, wie sie miteinander verbunden sind, und die spezifische Zuordnung von VNFs zu Geräten.

Protocol

1. Vorherige Voraussetzungen für das Experiment

1. Installieren Sie den Management and Orchestration (MANO) Software-Stack, der vom Open Source MANO (OSM)-Projekt bereitgestellt wird. Insbesondere verwendet dieses Experiment OSM Release FOUR²⁰, das auf einem einzelnen Servercomputer oder in einer virtuellen Maschine (VM) ausgeführt werden kann, die die von der OSM-Community festgelegten Anforderungen erfüllt: Ubuntu 16.04 als Betriebssystem (64-Bit-Variantenabbild), zwei zentrale Verarbeitungseinheiten (CPUs), 8 GB Ram (Random Access Memory), eine 40 GB Speicherfestplatte und eine einzige Netzwerkschnittstelle mit Internetzugang. Das Verfahren zur Installation von OSM Release FOUR zusammen mit seinen technischen Details finden Sie in der Online-Dokumentation der OSM-Community²¹.
2. Richten Sie eine Cloud-Computing-Plattform ein, die die Funktionen eines Virtual Infrastructure Managers (VIM) bereitstellt, der mit OSM Release FOUR kompatibel ist. Für dieses Experiment wird OpenStack-Version Ocata²² verwendet, die in einer VM mit Ubuntu 16.04 als Betriebssystem, vier CPUs, 16 GB RAM und 200 GB Speicherdatenträger ausgeführt wird. Im Experiment verwaltet der VIM eine NFV-Infrastruktur (NFVI), die von zwei hochkarätigen Servercomputern integriert ist, die jeweils Ubuntu 16.04 als Betriebssystem, acht CPUs, 128 GB RAM und 4 TB Speicherdatenträger aufweisen. Alle Informationen zum Einrichten einer Cloud-Computing-Plattform sind im Installationshandbuch enthalten, das in der OpenStack-Dokumentation²³enthalten ist. Diese Cloud-Plattform wird als die Kern-Cloud-Plattform bezeichnet.
3. Einrichten einer zusätzlichen Cloud-Computing-Plattform für die UAVs wird als UAVs-Cloud-Plattform bezeichnet.
   1. Stellen Sie sicher, dass diese Plattform über eine VIM-Version verfügt, die auf OpenStack-Version Ocata basiert. In diesem Fall sind die von der VIM-Installation verwendeten Ressourcen Ubuntu 16.04 als Betriebssystem, zwei CPUs, 6 GB RAM, 100 GB Speicherfestplatte und ein externer WI-Fi-USB-Adapter.
   2. Der in diese Cloud-Plattform integrierte NFVI besteht aus einem einzelnen festen Computeserver (Ubuntu 16.04 als Betriebssystem, acht CPUs, 8 GB RAM, 128 GB Speicherdiskette und einem externen Wi-Fi-USB-Adapter) und drei Single-Board-Computern (SBCs). Letztere bieten eine Hardware-Plattform, die leicht auf einem UAV integriert werden kann. Siehe Abschnitt 3 für das Verfahren zum Einrichten einer UAV-Cloud-Plattform mit diesen Geräten als Computeknoten.
4. Rüsten Sie jeden SBC mit einer oben angebrachten Batterienetzteilhardware (HAT) aus, um den Betrieb dieser Geräte auch dann zu gewährleisten, wenn sie in Bewegung sind und von einem UAV getragen werden.
   ANMERKUNG: Schritt 1.5 ist optional, da die Bereitstellung des Netzwerkdienstes im Experiment nicht von UAVs abhängt. Darüber hinaus werden die SBCs als Nutzlast der UAVs getragen und es werden keine weiteren zusätzlichen Anschlüsse (z. B. Ethernet oder USB) benötigt, da die für den ordnungsgemäßen Betrieb des IP-Telefoniedienstes erforderliche Netzwerkkommunikation von den SBCs über ihre WLAN-Adapter bereitgestellt wird und die Stromversorgung über die in Schritt 1.4 genannte Stromversorgung HAT erfolgt.
5. Befestigen Sie jeden SBC als Nutzlast eines UAV durch ein Befestigungszubehör. In diesem Experiment wurden drei kommerzielle Drohnen ausgewählt, um die von den SBCs angebotenen Recheneinheiten zu transportieren.
6. Wählen Sie zwei drahtlose Voice-over-IP-Telefone (VoIP) aus, die den IEEE 802.11b Wireless-Kommunikationsstandard unterstützen. Dieses Modell bietet drahtlose Kommunikation über Wi-Fi. Alternativ könnte der Sprachanruf mit Softphone-Anwendungen wie Linphone²⁴ oder Jitsi²⁵ausgeführt werden.
7. Stellen Sie als experimentelle Anforderung die Verfügbarkeit von: a) Layer-3-Kommunikation zwischen dem OSM-Software-Stack und jedem der VIMs sicher, um die orchestrierte Bereitstellung des für dieses Experiment entwickelten Netzwerkdienstes zu ermöglichen, b) Layer-3-Kommunikation zwischen dem OSM und den VNFs auf jeder Cloud-Plattform zur Unterstützung von VNF-Konfigurationsprozeduren und c) der Layer-3-Kommunikation zwischen den VNFs, die auf jedem VIM ausgeführt werden, um das ordnungsgemäße Funktionieren des Netzwerkdienstes zu ermöglichen.
8. Alle für die Durchführung des Experiments erforderlichen Inhalte werden im öffentlichen Experimentrepository bereitgestellt http://vm-images.netcom.it.uc3m.es/JoVE/.

2. Validierung der Funktionalität der Softwarisierungseinheiten über Emulation

HINWEIS: Um den ordnungsgemäßen Betrieb des Netzwerkdienstes des Experiments (siehe Abbildung 1) unter realistischen Bereitstellungsbedingungen nachzuweisen, wurde eine zweckspezifische Emulationsplattform verwendet, die auf Linux-Containern²⁶ und ns-3²⁷ basiert. Diese Plattform ermöglicht die Nachahmung von Multi-Hop-Luftverbindungen und die Definition der Merkmale dieser Verbindungen (z. B. Länge der drahtlosen Kommunikationsverbindungen, Muster von Datenpaketverlusten, Funktechnologie, die in der drahtlosen Kommunikation verwendet wird, usw.). Daher werden in diesem Abschnitt des Protokolls die Schritte beschrieben, die zu befolgen sind, um den geeigneten Betrieb des IP-Telefoniedienstes unter realistischen Bedingungen für drahtlose Kommunikation über die Emulationsplattform zu überprüfen.

1. Laden Sie die Emulationsplattform aus dem Experiment-Repository herunter. Die Plattform ist als virtuelle Maschine mit dem Namen "uav-nfv-jove-experiment.qcow" verfügbar, die mit der KVM-Virtualisierungstechnologie 28 kompatibel^ist. Dieser Computer enthält eine vorgefertigte Vorlage, die den Netzwerkdienst und das in Abbildung 1 dargestellte Multi-UAV-Szenario emuliert, und einen Benutzer mit Administratorrechten, der diese Vorlage ausführen kann.
   HINWEIS: Standardmäßig werden die folgenden Schritte automatisch ausgeführt, wenn die virtuelle Maschine der Emulationsplattform gestartet wird: a) die virtuelle Umgebung ist so konfiguriert, dass die Netzwerkemulation aktiviert wird (d. h. Netzwerkschnittstellen, Linux-Brücken²⁹); b) die Linux-Container, die die verschiedenen physischen Komponenten des Testbed darstellen (d. h. die SBCs und der feste Computeserver für die UAV-Cloud-Plattform und der Computeserver für die Kern-Cloud-Plattform) erstellt werden; und c) die Funktionen, die von den verschiedenen VNFs des IP-Telefoniedienstes bereitgestellt werden (d. h. Access Points, Router, DNS-Dienst und IP-Telefonieserver), werden als Linux-Container über die entsprechenden emulierten SBCs und Computeserver bereitgestellt.
2. Richten Sie vor dem Validierungsprozess ein emuliertes Multi-Hop-Antennennetzwerk mithilfe des Simulators ns-3 ein, um die Konnektivität zwischen den verschiedenen Netzwerkteilnehmern zu ermöglichen. Dieses Verfahren emuliert die realistische drahtlose Kommunikation, die in dem in Abbildung 1 dargestellten Szenario stattfindet (d. h. das Wlan-Ad-hoc-Netzwerk, das den Datenaustausch zwischen den Knoten der UAV-Cloud-Plattform und den drahtlosen Netzwerken ermöglicht, die von den beiden im Dienst bereitgestellten WLAN-Zugriffspunkten angeboten werden).
   1. Erstellen Sie das Multi-Hop-Luftnetzwerk. Führen Sie zu diesem Zweck das multi-hop-aerial-net.sh Skript (verfügbar innerhalb des Emulationsplattform-Rechners) mit dem folgenden Befehl aus: sudo sh /home/jovevm/scripts/multi-hop-aerial-net.sh > multi-hop-aerial-net-trace.log 2>&1 &. Dieser Befehl stellt die Simulationsablaufverfolgung in der angegebenen Protokolldatei dar, um das Debuggen im Fehlerfall zu ermöglichen.
   2. Überprüfen Sie, ob das Netzwerk erfolgreich erstellt wurde. Überprüfen Sie zu diesem Zweck, ob die Linux-Container "IP-phone-a" und "IP-phone-b" (siehe Abbildung 1 als Endbenutzergeräte, die eine Verbindung zu einem AP-VNF herstellen) über den DHCP-Dienst eine IP-Adresse erhalten haben, auf die nur über das Multi-Hop-Antennennetzwerk zugegriffen werden kann. Der Status des im Emulationscomputer ausgeführten Linux-Containers sowie deren IP-Adressen können mit dem Befehl lxc listüberprüft werden.
3. Überprüfen Sie die Kapazität des emulierten Netzwerkdienstes, um die Signalmeldungen zu verarbeiten, die zum Einrichten des IP-Telefonieanrufs erforderlich sind. Zu diesem Zweck haben sowohl die Linux-Container "IP-phone-a" als auch "IP-phone-b" das "SIPp"-Tool³⁰installiert. "SIPp" bietet die Funktionalität, um ein IP-Telefon zu emulieren, das die genannten Signalmeldungen erstellt, sie an einen IP-Telefonieserver sendet und die Antwort verarbeitet, um den korrekten Betrieb der letzteren zu überprüfen.
   1. Führen Sie das Skript test-signaling.sh in beiden Containern aus, wo das Tool "SIPp" zum Generieren und Senden von Signalmeldungen an den IP-Telefonie-Server-VNF ausgeführt wird.
   2. Überprüfen Sie den Szenariobildschirm, der durch die Ausführung des vorherigen Schritts bereitgestellt wird. Der Empfang der Antwort "200" zeigt die angemessene Funktionsweise des IP-Telefonie-Server-VNF.
4. Überprüfen Sie, ob der Netzwerkdienst den Datenverkehr verarbeiten kann, der während eines IP-Telefonieanrufs generiert wird. Dazu wird das Flow-Scheduling-Tool "Trafic"³¹ in den Linux-Containern "IP-phone-a" und "IP-phone-b" installiert.
   1. Führen Sie den folgenden Befehl aus, um den Server-Agenten von Trafic zu starten: lxc exec IP-phone-b sh called-party.sh.
   2. Führen Sie dann den folgenden Befehl aus, um den Client-Agenten von Trafic zu starten und die Netzwerkstatistiken abrufe: lxc exec IP-phone-a sh caller.sh. Der Datenverkehr, der einen Sprachanruf emuliert, wird nach 60 s beendet. Das Skript zeigt eine Bestätigungsmeldung und die wichtigsten Leistungsmetriken für den Sprachverkehr an.
   3. Überprüfen Sie die abgerufenen Metriken, und stellen Sie sicher, dass der IP-Telefoniedienst eine interaktive Sprachunterhaltung effektiv unterstützen kann. Hierzu finden Sie die Informationen im Abschnitt über repräsentative Ergebnisse.

3. UAVs Cloud-Plattform-Konstruktion

1. Wählen Sie das Modell von SBC aus, das das Virtualisierungssubstrat zum Ausführen leichter VNFs bereitstellen kann. Die technischen Spezifikationen der SBC-Geräte, die während des Experiments verwendet werden, sind: vier CPUs, 1 GB RAM und eine 32 GB Speicherdiskette. Darüber hinaus verfügt jeder SBC über drei Netzwerkschnittstellen: eine Ethernet-Schnittstelle, eine integrierte WLAN-Schnittstelle und einen externen WLAN-USB-Adapter.
2. Bereiten Sie die SBCs vor, die anschließend in die Cloud-Plattform von UAVs integriert werden.
   1. Installieren Sie Ubuntu Mate³² 16.04.6 als Betriebssystem, da die OpenStack-Installationspakete in dieser Linux-Distribution enthalten sind.
   2. Installieren und konfigurieren Sie die erforderlichen Pakete, wie in der OpenStack-Dokumentation³³ angegeben, damit die SBCs als Computeknoten der UAV-Cloud-Plattform fungieren können. Aktivieren Sie im vorherigen Handbuch die Verwendung von Linux-Containern in der Konfiguration der OpenStack-Pakete. Die Containervirtualisierung wird aufgrund der Ressourceneinschränkungen der Geräte verwendet, die normalerweise auf kleinen UAVs eingebunden werden können.
   3. Laden Sie im SBC das Skript rpi-networking-configuration.sh herunterund führen Sie es aus. Dieses Skript ermöglicht die drahtlose Kommunikation der SBCs sowie die erforderliche Konfiguration, um die Erstellung virtueller Netzwerke zu ermöglichen, die an die drahtlosen Schnittstellen angeschlossen sind.
   4. Laden Sie das Skript VIM-networking-configuration.sh herunter,das im Experiment-Repository verfügbar ist, und führen Sie es auf dem Host aus, auf dem die UAV-Cloudplattform VIM ausgeführt wird. Dieses Skript überwacht die Einrichtung der drahtlosen Kommunikation des VIM, um den Informationsaustausch mit den SBCs zu ermöglichen.
      HINWEIS: Sobald das Netzwerk gut konfiguriert ist und der VIM über eine Verbindung mit den SBCs verfügt, integriert der VIM sie automatisch in die UAV-Cloud-Plattform als Recheneinheiten, die VNFs ausführen können.
3. Erstellen Sie eine OpenStack-Verfügbarkeitszone für jeden SBCs. Auf diese Weise können die einzelnen leichten VNFs des Experiments in einer geeigneten UAV-Einheit bereitgestellt werden. Melden Sie sich dazu bei der grafischen Web-Benutzeroberfläche an, die vom VIM mit den Administratoranmeldeinformationen bereitgestellt wird, erstellen Sie die Verfügbarkeitszonen auf der Registerkarte Administrator > System > Host Aggregates, und bearbeiten Sie jede Verfügbarkeitszone, um den entsprechenden Host hinzuzufügen (d. h. jeder InsB-Datenspeicher, der in die UAV-Cloudplattform integriert ist).
4. Überprüfen Sie die korrekte Einrichtung der UAV-Cloud-Plattform. Klicken Sie dazu auf die Registerkarte Administrator > System > Systeminformationen mit derselben Anmeldung wie im vorherigen Schritt, und klicken Sie im Abschnitt Computerdienst und Netzwerk-Agents, um zu überprüfen, ob der Status der angezeigten Elemente "Alive" und "UP" lautet.

4. Konfigurieren des Experiments

1. Laden Sie die VNF-Images herunter, die die verschiedenen Komponenten des IP-Telefoniedienstes implementieren: AP-VNF, DNS-VNF, IP-Telefonie-Server-VNF, AR-VNF und CR-VNF. Diese Bilder können aus dem Experiment-Repository heruntergeladen werden.
2. Laden Sie die VNF-Bilder auf ihren entsprechenden VIM (d.h. den AP-VNF und den DNS-VNF auf die UAV-Cloud-Plattform VIM) und den VoIP-VNF auf die Kern-Cloud-Plattform VIM hoch. Melden Sie sich dazu in der grafischen Web-Benutzeroberfläche an, die von jedem VIM mit den Administratoranmeldeinformationen bereitgestellt wird, klicken Sie auf die Schaltfläche Bild erstellen auf der Registerkarte Administrator > System > Bilder, und erstellen Sie ein Bild mit dem angezeigten Formular und wählen Sie das entsprechende Bild aus. Dieser Vorgang erfolgt am entsprechenden VIM für jedes Bild, das im vorherigen Schritt heruntergeladen wurde.
3. Laden Sie die VNF-Deskriptoren (VNFDs) des Experiments aus dem Experiment-Repository herunter. Diese Deskriptoren stellen die Vorlagen bereit, die die betrieblichen Anforderungen eines VNF beschreiben, sowie die Platzierungsrichtlinien, die die Verfügbarkeitszone angeben, die für das Hosten des VNF selbst zuständig ist. Weitere Informationen zu NFV-Deskriptoren finden Sie im Informationsmodell von OSM³⁴.
4. Laden Sie die VNFDs hoch. Verwenden Sie einen Webbrowser, um auf die grafische OSM-Benutzeroberfläche zuzugreifen, und melden Sie sich mit den Administratoranmeldeinformationen an. Ziehen Sie dann die VNFDs in die Registerkarte VNF-Pakete.
5. Laden Sie die Netzwerkdienstbeschreibung (Network Services Descriptor, NSD) aus dem Experiment-Repository herunter. Dieser Deskriptor ist eine Vorlage, die die VNFs angibt, die den Dienst umfassen, sowie wie diese VNFs miteinander verbunden sind.
6. Laden Sie die NSD hoch. Ziehen Sie die NSD in die Registerkarte NS-Pakete der grafischen OSM-Benutzeroberfläche.
7. Mit der grafischen Benutzeroberfläche von OSM fügen Sie ein VIM-Konto für die UAV-Cloud-Plattform VIM und für die Kern-Cloud-Plattform VIM hinzu. Um dies zu tun, greifen Sie mit den Administratoranmeldeinformationen auf die Registerkarte VIM-Konten zu, klicken Sie auf die Schaltfläche + Neue VIM und füllen Sie das angezeigte Formular mit den angeforderten Informationen aus. Wiederholen Sie diese Aktion für beide VIMs.

5. Ausführen des Experiments

1. Stellen Sie den Netzwerkdienst bereit. Klicken Sie auf der Registerkarte NS-Pakete der grafischen OSM-Benutzeroberfläche auf die Instantiate NS-Schaltfläche der NSD, die in Schritt 4.6 hochgeladen wurde. Füllen Sie dann das angezeigte Formular aus und geben Sie den VIM an, der zum Bereitstellen jedes VNF verwendet wird, der das NS bildet. Darüber hinaus ist das OSM für die Verarbeitung der in den VNFDs angegebenen Platzierungsrichtlinien verantwortlich, um die VIM anzugeben, welche Verfügbarkeitszone (d. h. eine Recheneinheit in unserem Prüfstand) für das Hosting jedes VNF zuständig ist. Für dieses Experiment werden die VNFs in den Recheneinheiten platziert, wie in Abbildung 1dargestellt.
   HINWEIS: Alternativ stellt das OSM eine Befehlszeilenschnittstelle bereit, die eine direkte Benutzerinteraktion ermöglicht. Ein Benutzer, der dieses Experiment reproduziert, kann diese Befehlszeilenschnittstelle anstelle der grafischen Schnittstelle verwenden, um die verschiedenen in diesem Protokoll definierten Schritte auszuführen, insbesondere die Schritte im Zusammenhang mit dem Onboarding eines VNF- oder NS-Deskriptors sowie der Bereitstellung eines Netzwerkdienst.
2. Warten Sie, bis die grafische OSM-Benutzeroberfläche den Erfolg der Netzwerkdienstbereitstellung angibt.
   HINWEIS: Der Betrieb des Netzwerkdienstes ist völlig unabhängig vom Flug der UAVs: Der IP-Telefoniedienst kann bereitgestellt werden, wenn die Drohnen fliegen oder den Batterieverbrauch auf einer Oberfläche sparen. Daher ist Schritt 5.3 optional.
3. Nehmen Sie die Drohnen ab. Melden Sie sich bei der mobilen Anwendung an und steuern Sie den Flug jedes UAV, um es stabil in einer Zwischenhöhe zu halten und die Turbulenzen zu vermeiden, die durch die Drehung der Motoren in der Nähe einer Oberfläche verursacht werden.
4. Bereiten Sie jedes der IP-Telefone vor, um den Anruf auszuführen.
   1. Verbinden Sie ein drahtloses VoIP-Telefon mit jedem der vom Netzwerkdienst angebotenen Zugriffspunkte. Geben Sie zu diesem Zweck die SSID (Service Set Identifier) im Menü > Wireless > SSID-Registerkarte an, und wählen Sie den Infrastrukturmodus im Abschnitt Menü > Drahtlos > Netzwerkmodus aus. Wählen Sie schließlich die Netzwerkkonfiguration über das Dynamic Host Configuration Protocol (DHCP) auf der Registerkarte Menü > Netzeinstellungen > Netzwerkmodus aus.
   2. Konfigurieren Sie die SIP-Parameter (Session Initiation Protocol), um den entsprechenden Austausch von Signalmeldungen mit dem IP-Telefonieserver zu ermöglichen. In diesem Zusammenhang zugriffe ich auf die Registerkarte Menü > SIP-Einstellungen und gibt den Hostnamen des IP-Telefonieservers VNF ("dronesVoIP.net") in den Registerkarten Registrierungs-IP und Proxyserver > Proxy-IP an. Erstellen Sie außerdem ein Benutzerkonto, das den Namen des Benutzers (z. B. Anrufer-A) in den Abschnitten Benutzerkonto > Telefonnummer und Benutzerkonto > Benutzername einführt.
   3. Erstellen Sie einen Eintrag im Telefonbuch eines der IP-Telefone, das die Informationen des Benutzers bereitstellt, der aufgerufen werden soll. Wählen Sie dazu die Registerkarte Menü > Telefonbuch > Eintrag hinzufügen aus, und füllen Sie die angeforderten Parameter aus, die in der Anzeige wie folgt angezeigt werden: Anzeigename = Aufrufer-B; Benutzerinfo = Anrufer-B; Host-IP = dronesVoIP.net; Anschluss = 5060. Wählen Sie schließlich die Option "Proxy" im Vergleich zum P2P (Peer-to-Peer)aus.
5. Starten Sie den Anruf an die andere Partei. Wählen Sie dazu die angerufene Partei mit der Option Menü > Telefonbuch > Suchen des IP-Telefons aus. Drücken Sie dann die Anruftaste. Sobald das andere IP-Telefon zu klingeln beginnt, nehmen Sie den eingehenden Anruf mit der Anruftaste an.

6. Verfahren zur Erfassung experimenteller Ergebnisse

1. Schließen Sie einen Standard-Laptop an einen der drahtlosen APs an, und führen Sie das Ping-Befehlszeilentool an die IP-Adresse des Telefons aus, das während 180 s mit dem anderen AP verbunden ist. Die IP-Adresse kann in der Menü-> -Informationsoption > IP-Adresse des IP-Telefons überprüft werden, sobald die Verbindung mit dem AP hergestellt ist. Speichern Sie die ROUND-Trip Time (RTT)-Messungen und leiten Sie die vom Ping-Tool bereitgestellte Ausgabe in eine Datei um.
2. Führen Sie das Befehlszeilentool tcpdump in einer der ausgeführten AP-VNFs aus, um den während des IP-Aufrufs ausgetauschten Datenverkehr zu erfassen. Speichern Sie diesen Datenverkehr in einer Datei, in der das Schreibkennzeichen des Befehlszeilentools zur Ausführungszeit aktiviert und der Name der Datei angegeben wird.
3. Führen Sie einen neuen IP-Telefonieanruf aus. Halten Sie den Anruf für den gewünschten Zeitraum (z. B. 1 min). Beenden Sie dann den Anruf und drücken Sie die Aufhängetaste eines der IP-Telefone.
4. Bewahren Sie die von den tools tcpdump und ping generierten Dateien zur weiteren Verarbeitung auf. Siehe Repräsentative Ergebnisse.

Representative Results

Auf der Grundlage der während der Durchführung des Experiments gewonnenen Daten, bei denen ein echter VoIP-Aufruf ausgeführt wird, und nach den im Protokoll angegebenen Schritten zur Erfassung dieser Informationen zeigt Abbildung 2 die kumulative Verteilungsfunktion der End-to-End-Verzögerung, gemessen zwischen zwei Endbenutzergeräten (d. h. einem Standard-Laptop und einem IP-Telefon). Diese Benutzerausrüstung stellt zwei Geräte dar, die über die AP-VNFs des bereitgestellten Netzwerkdienstes miteinander verbunden sind. Mehr als 80 % der End-to-End-Verzögerungsmessungen lagen unter 60 ms, und keine von ihnen war höher als 150 ms, was angemessene Verzögerungsmetriken für die Ausführung eines Sprachanrufs garantiert.

Abbildung 3 zeigt den Austausch von DNS- und SIP-Signalnachrichten. Diese Meldungen entsprechen der Registrierung eines der Benutzer im IP-Telefonieserver (d. h. dem Benutzer, dessen IP-Telefon mit dem AP VNF verbunden ist, wo das "tcpdump"-Tool läuft) und der Einrichtung des Sprachanrufs.

Schließlich zeigen Abbildung 4 und Abbildung 5 den während des Anrufs erfassten Datenverkehr. Insbesondere stellt das erste den konstanten Strom von Sprachpaketen dar, die während des Anrufs von einem der drahtlosen Telefone übertragen und empfangen werden, während letztereden den Jitter in Vorwärtsrichtung mit einem Durchschnittswert von weniger als 1 ms veranschaulicht.

Die Ergebnisse, die im Experiment für die Verzögerungszahlen (End-to-End-Verzögerung und Jitter) erzielt wurden, entsprechen den Empfehlungen der Internationalen Fernmeldeunion - Telekommunikationsstandardisierung (ITU-T)³⁵. Dementsprechend ging der Sprachanruf ohne Störungen und gute Klangqualität voran. Dieses Experiment bestätigte die praktische Durchführbarkeit der Verwendung von NFV-Technologien und UAVs zur Bereitstellung eines funktionalen IP-Telefoniedienstes.

Abbildung 1: Übersicht über den Netzwerkdienst, die Darstellung der VNFs, der Entitäten, in denen sie ausgeführt werden, und der virtuellen Netzwerke, die für die Bereitstellung des IP-Telefoniedienstes erforderlich sind. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 2: End-to-End-Verzögerung. Darstellung der End-to-End-Verzögerung, die den mit den AP-VNFs verbundenen End-user-Geräten angeboten wird. Zu diesem Zweck wurde die kumulative Verteilungsfunktion der End-to-End-Verzögerung aus den gemessenen RTT-Samples berechnet, die mit dem Befehlszeilenwerkzeug "ping" erhalten wurden. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 3: Benutzerregistrierung und Anrufsignalmeldungen. Abbildung des Signalverkehrs (DNS und SIP), der ausgetauscht wurde, um einen Benutzer auf dem IP-Telefonieserver zu registrieren und die Multimediasitzung zu erstellen und zu beenden, die die Ausführung des Sprachanrufs unterstützt. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 4: Stream von Sprachpaketen. Darstellung des während des Anrufs ausgetauschten Sprachverkehrs, gemessen an einem der AP-VNFs. (Abkürzungen: RX = empfangen, RX = übertragen, RTP = Echtzeit-Transportprotokoll). Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 5: Entwicklung des Netzwerk-Jitters während des Anrufs. Darstellung des Jitters, den die übertragenen Sprachpakete in Vorwärtsrichtung von einem Telefon zum anderen erfahren. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Discussion

Einer der wichtigsten Aspekte dieses Experiments ist der Einsatz von Virtualisierungstechnologien und NFV-Standards mit UAV-Plattformen. NFV präsentiert ein neues Paradigma, das darauf abzielt, die Hardwareabhängigkeit der Netzwerkfunktionalitäten zu entkoppeln und so die Bereitstellung dieser Funktionalitäten durch Softwarisierung zu ermöglichen. Dementsprechend hängt das Experiment nicht von der Verwendung der im Protokoll angegebenen Hardwareausrüstung ab. Alternativ können verschiedene Modelle von Einzelplatinencomputern ausgewählt werden, sofern sie den Abmessungen und der Transportkapazität der UAVs entsprechen und Linux-Container unterstützen.

Ungeachtet dieser Flexibilität bei der Hardwareauswahl sind alle Inhalte, die für die Reproduzierbarkeit des Experiments bereitgestellt werden, auf den Einsatz von Open-Source-Technologien ausgerichtet. In diesem Zusammenhang sind die Konfigurationsaspekte und die Software-Tools auf die Verwendung von Linux als Betriebssystem konditioniert.

Andererseits betrachtet das Experiment die Zusammenarbeit zweier unterschiedlicher Rechenplattformen (d.h. der UAV-Cloud-Plattform und der Kern-Cloud-Plattform) als einen mäßig komplexen Netzwerkdienst. Dies ist jedoch nicht unbedingt erforderlich, und das Protokoll könnte befolgt werden, um Szenarien zu unterstützen, in denen nur die UAV-Cloud-Plattform beteiligt ist.

Darüber hinaus könnte die vorgestellte Lösung möglicherweise in anderen Umgebungen verwendet werden, in denen ressourcenbeschränkte Hardwareplattformen mit der erforderlichen Kapazität zum Ausführen von Virtualisierungscontainern (z. B. Internet der Dinge oder IoT, Umgebungen). In jedem Fall erfordert die Anwendbarkeit dieser Lösung auf unterschiedliche Umgebungen und ihre möglichen Anpassungen eine sorgfältige Untersuchung von Fall zu Fall.

Schließlich ist darauf hinzuweisen, dass die vorgelegten Ergebnisse in einer Laborumgebung und mit den uAV-Geräten, die geerdet sind oder einem begrenzten und genau definierten Flugplan folgen, erzielt wurden. Andere Szenarien, die Bereitstellungen im Freien beinhalten, können Bedingungen mit sich bringen, die die Stabilität des Fluges der Drohnen und damit die Leistung des IP-Telefoniedienstes beeinträchtigen.

Materials

Name	Company	Catalog Number	Comments
AR. Drone 2.0 - Elite edition	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform.
Bebop 2	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform.
Commercial Intel Core Mini-ITX Computer	Logic Suppy		Computer server which hosts the OpenStack controller node (being executed as a VM) of the experiment's UAV cloud platform. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the UAV cloud platform.
Linux Containers (LXC)	Canonical Ltd.		(Software) Virtualization technology that enables the supply of the Virtual Network Functions detailed in the experiment. Source-code available online: https://linuxcontainers.org
Lithium Battery Pack Expansion Board. Model KY68C-UK	Kuman		Battery-power supply HAT (Hardware Attached on Top) for the computation units of the UAV cloud platform (i.e., the Raspberry Pis). In addition, this equipment encompasses the case used to attach the compute units (i.e., the Raspberry PIs or RPis) to the UAVs.
MacBook Pro	Apple		Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript.
ns-3 Network Simulator	nsnam		(Software) A discrete-event simulator network simulator which provides the underlying communication substrate to the emulation station explained in the "Protocol" section (more specifically in the step "2. Validate the functionality of the softwarization units via Emulation"). Source-code available online: https://www.nsnam.org
Open Source MANO (OSM) - Release FOUR	ETSI OSM - Open source community		(Software) Management and Orchestration (MANO) software stack of the NFV system configured in the experiment. Source-code available online: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Release Ocata	OpenStack - Open source community		(Software) Open source software used for setting up both the UAV cloud platform and the core cloud within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu
Ping	Open source tool		(Software) An open source test tool, which verifies the connectivity between two devices connected through a communications network. In addition, this tool allows to assess the network performance since it calculates the Round Trip Time (i.e., the time taken to send and received a data packet from the network). Source-code available online: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430	Dell		High-profile computer server which provides the computational capacity within the core cloud platform presented in the experiment.
Power Edge R630	Dell		Equipment used for hosting the virtual machine (VM) on charge of executing the MANO stack. In addition, the OpenStack controller node is also executed as a VM in this device. Note that the use of this device is not strictly needed. The operations carried out by this device could be done by a lower performance equipment due to the non-high resource specifications of the before mentioned VMs.
Prestige 2000W	ZyXEL		Voice over IP Wi-FI phone, compatible with the IEEE 802.11b wireless communications standard. This device is utilized to carry out the VoIP call through the network service hosted by platform described for the execution of the experiment.
Raspberry PI. Model 3b	Raspberry Pi Foundation		Selected model of Single Board Computer (SBC) used for providing the computational capacity to the experiment's UAV cloud platform.
SIPp	Open source tool		(Software) An open source test tool, which generates SIP protocol traffic. This tool allows to verify the proper support of the signalling traffic required in an IP telephony service such as the one deployed in the experiment. Source-code available online: http://sipp.sourceforge.net
Tcpdump	Open source tool		(Software) An open source tool that enables the capture and analysis of the network traffic. Source-code available online: https://www.tcpdump.org
Trafic	Open source tool		(Software) An open souce flow scheduler that is used for validating the capacity of the network service deployed to process data traffic generated during an IP telephony call. Source-code available online at: https://github.com/5GinFIRE/trafic