Methodenartikel

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

DOI:

10.3791/60425

⸱

26. November 2019

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

* These authors contributed equally

In diesem Artikel

Zusammenfassung

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

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.

Zusammenfassung

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

Das Paradigma der Netzwerkfunktion Virtualisierung (NFV) ist eine der schlüsselnden Technologien für die Entwicklung der5. 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.

Einleitung

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

Eines der begehrtesten Ziele in der neuen Ära der Mobilkommunikation (am häufigsten bekannt als die5. 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-Dienste1,2,3unterzubringen. Darüber hinaus haben frühere Untersuchungen gezeigt, wie die Zusammenarbeit zwischen mehreren Drohnen die Funktionalität verschiedener Kommunikationsdienste wie Überwachung4,kollaborative Suche und Rettung5,6,7,8oder Agribusiness9erweitern 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-Architekturrahmen10zu definieren. Darüber hinaus beherbergt das ETSI derzeit die Open Source Mano (OSM) Gruppe11, 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 Systemen14,15,16aufzeigen, die Herausforderungen dieser Konvergenz und ihre fehlenden Aspekte identifizieren, zukünftige Forschungslinien zu diesem Thema17aufzeigen 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 Arbeiten18,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.19 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.

Protokoll

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

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 FOUR20, 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-Community21.
  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 Ocata22 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-Dokumentation23enthalten 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 Linphone24 oder Jitsi25ausgefü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-Containern26 und ns-327 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 kompatibelist. 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ücken29); 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"-Tool30installiert. "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"31 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 Mate32 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-Dokumentation33 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 OSM34.
  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.

Ergebnisse

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

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)35. 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.

figure-results-1
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.

figure-results-2
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.

figure-results-3
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.

figure-results-4
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.

figure-results-5
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.

Diskussion

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

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.

Offenlegungen

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

Die Autoren haben nichts zu verraten.

Danksagungen

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

Diese Arbeiten wurden teilweise durch das europäische Projekt H2020 5GRANGE (Zuschussvereinbarung 777137) und das vom spanischen Ministerium für Wirtschaft und Wettbewerbsfähigkeit finanzierte Projekt 5GCIty (TEC2016-76795-C6-3-R) unterstützt. Die Arbeit von Luis F. Gonzalez wurde teilweise durch das europäische Projekt H2020 5GinFIRE (Zuschussvereinbarung 732497) unterstützt.

Materialien

Liste der in diesem Artikel verwendeten Materialien
NameUnternehmenKatalognummerKommentare
AR. Drone 2.0 - Elite EditionDasim Experiment verwendete Parrot UAV wurde verwendet, um die RPis zu transportieren und so den Recheneinheiten der UAV-Cloud-Plattform Mobilität zu verleihen.
Bebop 2ParrotUAV, das im Experiment verwendet wurde, um die RPis zu transportieren und so den Recheneinheiten der UAV-Cloud-Plattform Mobilität zu bieten.
Kommerzieller Intel Core Mini-ITX ComputerLogic SuppyComputer-Server, der den OpenStack-Controller-Knoten (der als VM ausgeführt wird) der UAV-Cloud-Plattform des Experiments hostet. Darüber hinaus entspricht eine weitere Einheit dieser Ausrüstung (zusammen mit dem RPis) den Rechenressourcen der UAV-Cloud-Plattform.
Linux-Container (LXC)Canonical Ltd.(Software) Virtualisierungstechnologie, die die Bereitstellung der im Experiment beschriebenen virtuellen Netzwerkfunktionen ermöglicht. Quellcode online verfügbar: https://linuxcontainers.org
Lithium Battery Pack Expansion Board. Modell KY68C-UKKumanBatterie-Netzteil HAT (Hardware Attached on Top) für die Recheneinheiten der UAV-Cloud-Plattform (d.h. Raspberry Pis). Darüber hinaus umfasst diese Ausrüstung das Gehäuse, mit dem die Compute Units (d. h. die Raspberry PIs oder RPis) an die UAVs angeschlossen werden.
MacBook Pro: AppleCommodity Laptop, der während des Experiments verwendet wurde, um die Ergebnisse zu erhalten und zu sammeln, wie im Manuskript beschrieben.
ns-3 Network Simulatornsnam(Software) Ein Discrete-Event-Simulator Netzwerksimulator, der das zugrunde liegende Kommunikationssubstrat für die Emulationsstation bereitstellt, wie im Abschnitt "Protokoll" erläutert (genauer gesagt im Schritt "2. Validieren Sie die Funktionalität der Softwarization-Einheiten über Emulation"). Quellcode online verfügbar: https://www.nsnam.org
Open Source MANO (OSM) - Release FOURETSI OSM - Open Source Community(Software) Management and Orchestration (MANO) Software-Stack des im Experiment konfigurierten NFV-Systems. Quellcode online verfügbar: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Release OcataOpenStack - Open source community(Software) Open-Source-Software, die sowohl für die Einrichtung der UAV-Cloud-Plattform als auch der Core-Cloud innerhalb des Experiments verwendet wird. Quellcode online verfügbar: https://docs.openstack.org/ocata/install-guide-ubuntu
PingOpen Source Tool(Software) Ein Open-Source-Testtool, das die Konnektivität zwischen zwei Geräten überprüft, die über ein Kommunikationsnetzwerk verbunden sind. Darüber hinaus ermöglicht dieses Tool die Bewertung der Netzwerkleistung, da es die Round Trip Time berechnet (d. h. die Zeit, die benötigt wird, um ein Datenpaket aus dem Netzwerk zu senden und zu empfangen). Quellcode online verfügbar: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430DellHigh-Profile-Computerserver, der die Rechenkapazität innerhalb der im Experiment vorgestellten Kern-Cloud-Plattform bereitstellt.
Power Edge R630Dell-Gerätedie zum Hosten der virtuellen Maschine (VM) verwendet werden, die für die Ausführung des MANO-Stacks verantwortlich ist. Darüber hinaus wird der OpenStack-Controller-Knoten auch in diesem Gerät als VM ausgeführt. Beachten Sie, dass die Verwendung dieses Geräts nicht unbedingt erforderlich ist. Die von diesem Gerät ausgeführten Vorgänge können aufgrund der nicht hohen Ressourcenspezifikationen der zuvor genannten VMs von einem leistungsschwächeren Gerät ausgeführt werden.
Prestige 2000WZyXELVoice over IP Wi-Fi-Telefon, kompatibel mit dem drahtlosen Kommunikationsstandard IEEE 802.11b. Diese Vorrichtung wird verwendet, um den VoIP-Anruf über den Netzwerkdienst durchzuführen, der von der Plattform gehostet wird, die für die Ausführung des Experiments beschrieben wurde.
Raspberry PI. Modell 3bRaspberry Pi FoundationAusgewähltes Modell eines Single Board Computers (SBC), das für die Bereitstellung der Rechenkapazität für die UAV-Cloud-Plattform des Experiments verwendet wird.
SIPpOpen Source Tool(Software) Ein Open-Source-Testtool, das SIP-Protokollverkehr generiert. Dieses Tool ermöglicht es, die ordnungsgemäße Unterstützung des Signalisierungsverkehrs zu überprüfen, der für einen IP-Telefondienst wie den im Experiment eingesetzten erforderlich ist. Quellcode online verfügbar: http://sipp.sourceforge.net
TcpdumpOpen Source Tool(Software) Ein Open-Source-Tool, das die Erfassung und Analyse des Netzwerkverkehrs ermöglicht. Quellcode online verfügbar: https://www.tcpdump.org
TraficOpen Source Tool(Software) Ein Open-Source-Flow-Scheduler, der zur Validierung der Kapazität des Netzwerkdienstes verwendet wird, der zur Verarbeitung des Datenverkehrs eingesetzt wird, der während eines IP-Telefonieanrufs generiert wird. Der Quellcode ist online verfügbar unter: https://github.com/5GinFIRE/trafic
,

Referenzen

$$\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).

Nachdrucke und Genehmigungen

Genehmigung beantragen, um den Text oder die Abbildungen dieses JoVE-Artikels zu verwenden

Genehmigung beantragen

Schlagwörter

NetzwerkfunktionsvirtualisierungIP TelefoniedienstVNF ImagesOSM grafische Benutzeroberfl cheVIM KontokonfigurationUAV Cloud PlattformVoice over IPEnde zu Ende Verz gerung

Verwandte Artikel