Integration von 5G-Experimentierinfrastrukturen in ein MULTI-Site-NFV-Ökosystem

Zusammenfassung

Ziel des beschriebenen Protokolls ist es, die flexible Integration von 5G-Experimentierinfrastrukturen in ein MULTI-Site-NFV-Ökosystem durch eine VPN-basierte Overlay-Netzwerkarchitektur zu unterstützen. Darüber hinaus definiert das Protokoll, wie die Effektivität der Integration validiert werden kann, einschließlich einer vertikalen Servicebereitstellung an mehreren Standorten mit NFV-fähigen kleinen Luftfahrzeugen.

Zusammenfassung

Network Function Virtualization (NFV) gilt als einer der Schlüsselfaktoren für die^5. Generation von Mobilfunknetzen oder 5G. Dieses Paradigma ermöglicht es, die Abhängigkeit von spezialisierter Hardware für die Bereitstellung von Telekommunikations- und vertikalen Diensten zu reduzieren. Zu diesem Zweck stützt es sich auf Virtualisierungstechniken, um Netzwerkfunktionen weich zu machen, ihre Entwicklung zu vereinfachen und die Bereitstellungszeit und -kosten zu reduzieren. In diesem Zusammenhang haben die Universidad Carlos III de Madrid, Telefónica und das IMDEA Networks Institute ein NFV-Ökosystem in 5TONIC entwickelt, einem offenen Netzwerkinnovationszentrum, das sich auf 5G-Technologien konzentriert und die Erstellung komplexer, realitätsnaher Experimentierszenarien über einen verteilten Satz von NFV-Infrastrukturen ermöglicht, die von Interessengruppen an verschiedenen geografischen Standorten zur Verfügung gestellt werden können. Dieser Artikel stellt das Protokoll vor, das definiert wurde, um neue Remote-NFV-Sites in das NFV-Ökosystem mit mehreren Standorten auf der Grundlage von 5TONIC zu integrieren, und beschreibt die Anforderungen an die bestehende und die neu integrierten Infrastrukturen, deren Konnektivität über eine Overlay-Netzwerkarchitektur und die Schritte, die für die Aufnahme neuer Standorte erforderlich sind. Das Protokoll wird durch die Integration einer externen Site in das 5TONIC NFV-Ökosystem veranschaulicht. Anschließend beschreibt das Protokoll die Verifizierungsschritte, die zur Validierung einer erfolgreichen Site-Integration erforderlich sind. Dazu gehört die Bereitstellung eines vertikalen Dienstes an mehreren Standorten unter Verwendung einer Remote-NFV-Infrastruktur mit kleinen unbemannten Luftfahrzeugen (SUAVs). Dies dient dazu, das Potenzial des Protokolls zu demonstrieren, um verteilte Experimentierszenarien zu ermöglichen.

Einleitung

Die Einführung der fünften Generation von Mobilfunknetzen (5G) hat die Telekommunikationsbranche seit Beginn des Jahrzehnts revolutioniert und die Telekommunikationsbetreiber verpflichtet, sich mit den wesentlich anspruchsvolleren Spezifikationen der neuen Netzwerkdienste und -anwendungen zu befassen, die unter dem Dach von 5G entwickelt wurden^1,2 . Zu diesen neuen Spezifikationen gehören unter anderem Die Erhöhung der Datenrate, Verbesserungen der Latenz der drahtlosen Übertragung und die Senkung der Betriebskosten. Unter den Technologien, die die Grundlage für die Verbesserungen dieser neuen Generation bilden, ist Network Functions Virtualization 3 (NFV) zu^einem der Schlüsselfaktoren geworden. NFV bietet die Möglichkeit, Netzwerkfunktionen, die traditionell auf spezialisierter Hardware übertragen werden, zu softwarisieren, indem stattdessen physische Geräte für allgemeine Zwecke verwendet werden, z. B. Servercomputer in einem Rechenzentrum. Mit diesem neuen Paradigma können Telekommunikationsbetreiber und vertikale Branchen Netzwerkfunktionen und -dienste als eine Reihe von Softwarekomponenten bereitstellen und Kosten sowohl bei der Bereitstellung als auch bei der Wartung sparen sowie eine viel höhere Elastizität der Netzwerkinfrastruktur ermöglichen. Dieser Ansatz verringert oder eliminiert die Notwendigkeit, dedizierte (und in der Regel komplexere und weniger wiederverwendbare) Geräte für die meisten netzwerk- und vertikalspezifischen Funktionen zu verwenden, und unterstützt einen viel höheren und dichteren Grad an Betriebsautomatisierung, wodurch die Bereitstellungs- und Wartungskosten gesenkt werden.

Unter Berücksichtigung aller Vorteile, die eine NFV-Umgebung bieten kann, ist es selbstverständlich, dass eine Vielzahl relevanter Stakeholder aus dem Telekommunikationssektor zunehmend an der Erprobung neuer Service-Ideen in NFV-Umgebungen beteiligt sind. In diesem Zusammenhang haben Telefónica und das IMDEA Networks Institute 5TONIC⁴ins Leben gerufen, ein offenes Forschungs- und Innovationslabor, das sich auf 5G-Technologien konzentriert. Dieses Labor mit Sitz in Madrid (Spanien) verfügt über eine breite Palette von Technologien für Forscher und Partner, um die Entwicklung und Validierung von 5G-Diensten voranzutreiben. Insbesondere verfügt dieses Labor über eine experimentelle NFV-Plattform, auf der Entwickler ihre neuen NFV-basierten Anwendungen und Dienste auf einem ETSI-konformen NFV-Ökosystem bereitstellen und testen können⁵. So können experimentelle Schlussfolgerungen über Designentscheidungen und Technologievorschläge in einer realistischen, viel flexibleren Umgebung als Produktionsnetzwerke abgeleitet werden. Diese Plattform wurde entwickelt, um Experimentieraktivitäten über mehrere externe Standorte hinweg zu unterstützen, die über ein klar definiertes Protokoll flexibel mit 5TONIC verbunden werden können.

Die technische Lösung für das 5TONIC NFV-Ökosystem berücksichtigt die Verwendung eines einzelnen NFV-Orchestrators, der mit der von ETSI gehosteten Open Source MANO (OSM) -Software⁶implementiert wurde. Dies ist das Element, das für die Verwaltung und Koordination des Lebenszyklus von Netzwerkdiensten (Network Services, NS) verantwortlich ist. Diese Dienste können als Zusammensetzung aus virtualisierten Netzwerk-/vertikalen Funktionen (VNF) erstellt werden, die an jedem der auf der NFV-Plattform integrierten Standorte bereitgestellt werden können. Das Design des 5TONIC NFV-Ökosystems erfolgte im Rahmen des H2020 5GINFIRE-Projekts^7,8, bei dem die Plattform zur Unterstützung der Durchführung von mehr als 25 Experimenten verwendet wurde, die durch einen wettbewerbsfähigen Open-Call-Prozess in acht vertikal spezifischen experimentellen Infrastrukturen in Europa und einer in Brasilien ausgewählt wurden, wobei letztere über eine transozeanische Verbindung verbunden ist. Darüber hinaus wurde die Plattform genutzt, um ein verteiltes NFV-Testbed auf nationaler Ebene in Spanien aufzubauen, das die Experimentieraktivitäten im Rahmen des spanischen 5GCity-Projekts^9,10unterstützt. In jüngster Zeit wurde ein zusätzlicher brasilianischer Standort in die Plattform integriert, um gemeinsame Demonstrationsaktivitäten im Rahmen einer Forschungs- und Innovationskooperation zwischen Brasilien und Europa (d.h. das 5GRANGE-Projekt^11,12) zu unterstützen. Nicht zuletzt wurde die Infrastruktur genutzt, um Drittexperimente im Rahmen des 5G-VINNI-Projekts^13,14zu unterstützen. Die geografische Verteilung der NFV-Plattform ist in Abbildung 1 dargestellt.

Interessierte Organisationen, die ihre eigene NFV-Infrastruktur hosten, können sich vorbehaltlich der Genehmigung durch das 5TONIC Steering Board flexibel mit dem 5TONIC NFV-Ökosystem verbinden, Testbed-Anbieter innerhalb des verteilten Ökosystems werden und an gemeinsamen Experimentier- und Demonstrationsaktivitäten beteiligt sein. Zu diesem Zweck müssen sie über einen VIM (Virtual Infrastructure Manager) verfügen, der mit dem OSM-Software-Stack kompatibel ist. Der 5TONIC NFV-Orchestrator ist in der Lage, mit den VIMs an den an einer bestimmten Servicebereitstellung beteiligten Standorten zu interagieren, die Zuweisung und Einrichtung der Rechen-, Speicher- und Netzwerkressourcen zu koordinieren, die für die Instanziierung und Verbindung der VNFs, aus denen ein Netzwerkdienst besteht, erforderlich sind, und seinen Lebenszyklus vom Onboarding bis zur endgültigen Außerbetriebnahme zu steuern.

Um den Austausch von Steuerung und Datenverkehr innerhalb aller miteinander verbundenen Standorte zu steuern, nutzt das 5TONIC NFV-Ökosystem eine Overlay-Netzwerkarchitektur auf Basis von Virtual Private Networks (VPN). Dieser Ansatz bietet einen sicheren PKI-basierten Zugriff auf die externen Standorte, die in das 5TONIC-Ökosystem integriert sind, und ermöglicht den Austausch von NFV-Steuerungsinformationen zwischen dem OSM-Software-Stack und den verschiedenen VIMs, die über die Testbeds verteilt sind, sowie den Austausch von Informationen, die für die Verwaltung und Konfiguration aller VNFs erforderlich sind. Darüber hinaus unterstützt dieses Overlay-Netzwerk die Verbreitung des Datenverkehrs zwischen VNFs, die an verschiedenen Standorten eingesetzt werden.

In diesem Zusammenhang beschreibt dieses Papier das Protokoll, das entwickelt wurde, um eine externe Site in ein NFV-Ökosystem zu integrieren. Das Protokoll geht davon aus, dass das Ökosystem von einem einzelnen NFV-Orchestrator gesteuert wird, der an einem zentralen Standort installiert ist, und dass externe Standorte über eine VIM-Lösung verfügen, die mit dem Orchestrator-Software-Stack kompatibel ist. Das vorgeschlagene Protokoll ermöglicht es, das Ressourcenportfolio des experimentellen Ökosystems durch die flexible Einbeziehung von NFV-Standorten und vertikal spezifischen Infrastrukturen zu erhöhen. Dies ermöglicht die Schaffung einer verteilten MANO-Plattform, die in der Lage ist, neuartige Netzwerk- und vertikale Dienste über mehrere Standorte hinweg unter der Kontrolle eines einzigen NFV-Orchestrators zu testen und zu validieren. Um den inneren Betrieb des Protokolls zu veranschaulichen, wird der Prozess beispielhaft veranschaulicht, indem dem aktuellen 5TONIC NFV-Ökosystem eine externe NFV-Site hinzugefügt wird, die die benötigten Komponenten an der externen Site und 5TONIC sowie alle Schritte beschreibt, die während des Integrationsprozesses zu unternehmen sind. Abbildung 2 gibt einen Überblick über das Ziel der Integration, wobei das neue NFV-basierte Testbed an die 5TONIC-Plattform angeschlossen ist, von wo aus Netzwerkdienste über VPN-Verbindungen zwischen dem zentralen Standort und den übrigen externen Infrastrukturen bereitgestellt werden können.

Um die Wirksamkeit des Protokolls zu demonstrieren, wird außerdem der Einsatz eines einfachen vertikalen Dienstes unter Verwendung des 5TONIC-Ökosystems und eines externen Standorts mit NFV-fähigen kleinen unbemannten Luftfahrzeugen (SUAVs) gezeigt. Das Design des vertikalen Dienstes wurde von einem in Vidal et al.⁹vorgestellten Experiment inspiriert, das für die Illustrationszwecke dieses Papiers vereinfacht wurde. Abbildung 3 zeigt den Dienst, der darauf abzielt, Smart-Farming-Aktivitäten in einem abgelegenen Gebiet zu unterstützen. Der Dienst betrachtet einen Smart-Farming-Dienstleister, der SUAVs verwendet, um die Daten zu sammeln und zu verbreiten, die von meteorologischen Sensoren erzeugt werden, die über ein Getreidefeld verstreut sind. Der Einfachheit halber betrachtet das in der Arbeit vorgestellte Experiment einen einzelnen SUAV und einen Sensor, die Temperatur-, Feuchtigkeits- und Druckmessungen liefern können. Im Experiment hostet der externe NFV-Standort einen Wi-Fi-Zugriffspunkt, der als VNF über den SUAV bereitgestellt wird. Dieser VNF bietet Netzwerkzugriffskonnektivität zum Sensor und leitet die erfassten Daten an eine Gateway-Funktion weiter. Letzteres wird als VNF auf einer Bodenausrüstung (einem Mini-ITX-Computer) eingesetzt. Die Verteilung der Daten vom Sensor an die Gateway-Funktion folgt einem Publish/Subscribe-Ansatz, der auf dem MQTT-Protokoll (Message Queuing Telemetry Transport)¹⁵basiert. Die Gateway-Funktion verarbeitet und verbreitet die Daten anschließend an einen Internet-of-Things (IoT)-Server, der als VNF am zentralen Standort des NFV-Ökosystems auf Basis der Open-Source-Plattform Mainflux¹⁶ zur Verfügung gestellt wird. Schließlich wird in dem Szenario von einem abgelegenen Bereich ausgegangen, in dem die Internetverbindung über ein mobilfunkfähiges Nicht-3GPP-Zugriffsnetzwerk bereitgestellt wird. Daher umfasst der Dienst zwei zusätzliche VNFs: 1) einen Zugangsrouter VNF, der den Protokollstapel der Benutzerebene eines 3GPP-Benutzergeräts implementiert, das mit einem Nicht-3GPP-Zugangsnetzwerk verbunden ist^17; und 2) eine Basisimplementierung eines 5G-Kernnetzwerks, das die Weiterleitung von Informationen zwischen dem Zugriffsrouter und den VNFs des IoT-Servers unterstützt. Zu diesem Zweck bietet der 5G-Kern-VNF eine vereinfachte Implementierung der Benutzerebene einer Nicht-3GPP-Interworking-Funktion und einer Benutzerebenenfunktion, wie in 3GPP¹⁷definiert.

Schließlich stellt Abbildung 4 die wichtigsten Prozesse dar, die an der Entwicklung des Protokolls beteiligt waren, wobei ihre logischen Verbindungen und die für ihre Ausführung verantwortlichen Entitäten hervorgehoben werden.

Protokoll

1. Bereitstellung des zentralen Standorts des NFV-Ökosystems (vorherige Voraussetzungen des Experiments)

1. Weisen Sie einen IP-Adressraum zu, der vom zentralen Standort verwendet werden soll. Für die Zwecke dieses Protokolls wird der private Adressraum 10.4.0.0/16 verwendet.
2. Installieren Sie den MANO-Softwarestapel (Management and Orchestration) am zentralen Standort. Insbesondere verwendet das Experiment, das in diesem Protokoll durchgeführt wird, das Open Source MANO (OSM) Release SEVEN¹⁸, das die folgenden Ressourcen erfordert: Ubuntu 18.04 als Betriebssystem, 2 Central Processing Units (CPUs), 8 GB Random-Access Memory (RAM), 40 GB Festplatte und mindestens eine Netzwerkschnittstelle mit Internetzugang. Befolgen Sie für die Installation die Anweisungen in der OSM Release SEVEN-Dokumentation¹⁸.
3. Richten Sie am zentralen Standort einen mit OSM kompatiblen Virtual Infrastructure Manager (VIM) ein. Insbesondere verwendet das Experiment OpenStack-Release Ocata^20,das auf einer virtuellen Maschine (VM) mit Ubuntu 16.04, 4 CPUs, 16 GB RAM und 200 GB Festplatte ausgeführt wird. Die nfv-Infrastruktur (NFVI), die von diesem VIM verwaltet wird, besteht aus drei Servercomputern mit jeweils Ubuntu 16.04, 8 CPUs, 32 GB RAM und 2 TB Speicher. Für die Installation folgen Sie der Ocata Release Dokumentation²¹.
   1. Stellen Sie ein virtuelles Netzwerk innerhalb der OpenStack-Cloud-Plattform bereit, indem Sie einen IP-Adressbereich aus dem in Schritt 1.1 zugewiesenen Adressraum verwenden. Dieses Netzwerk, das im Folgenden als Verwaltungsnetzwerk bezeichnet wird, wird verwendet, um den Austausch von NFV-Orchestrierungsinformationen zwischen dem OSM und den virtuellen Netzwerkfunktionen (VNFs) zu unterstützen, die am zentralen Standort instanziiert werden.
   2. Konfigurieren Sie ein virtuelles Netzwerk (im Folgenden als Datennetzwerk bezeichnet), um die standortübergreifende Datenkommunikation zwischen den VNFs des zentralen Standorts und anderen VNFs, die an externen Standorten ausgeführt werden, zu unterstützen. Verwenden Sie dazu einen IP-Adressbereich aus dem Adressraum von Schritt 1.1.
      HINWEIS: Die Implementierung der in den Schritten 1.3.1 und 1.3.2 genannten Netzwerke erfolgte über Provider-Netzwerke von OpenStack. Provider-Netzwerke müssen mit der physischen Netzwerkinfrastruktur des zentralen Standorts verbunden sein, um einen ordnungsgemäßen Betrieb zu gewährleisten.
4. Verbinden Sie sowohl virtuelle private Netzwerke (d. h. die Verwaltungs- und Datennetzwerke) als auch die VIM- und OSM-Maschinen mit einem Gerät, das Edge-Routing-Funktionen bereitstellt. Dieser Router dient als Einstiegspunkt zum zentralen Standort des NFV-Ökosystems.
5. Stellen Sie ein öffentliches Experiment-Repository zur Verfügung, um alle Inhalte bereitzustellen, die für die Durchführung des Experiments erforderlich sind. Insbesondere verwendet dieses Protokoll das öffentliche Repository bei²².

2. Konfiguration des virtuellen privaten Netzwerkdienstes

1. Weisen Sie einen IP-Adressraum zu, um den entsprechenden Betrieb des Ökosystems mit mehreren Standorten zu unterstützen, sodass die Netzwerkkommunikation zwischen mehreren Standorten effektiv hergestellt werden kann.
   HINWEIS: Die Aktivierung einer effektiven Netzwerkkommunikation zwischen mehreren Standorten erfordert eine sorgfältige Gestaltung des IP-Adressraums, der vom NFV-Ökosystem sowie von externen Standorten, die eine Verbindung herstellen müssen, verwendet werden soll. Insbesondere sollte der für die standortübergreifende Kommunikation zugewiesene Adressraum nicht mit dem Adressraum kollidieren, der bereits an jedem anderen Standort für andere Zwecke verwendet wird.
   1. Weisen Sie einen IP-Adressraum zu, der von externen Websites verwendet werden soll. Adressen in diesem Block werden NFV-Entitäten (z. B. VIMs) und VNFs der externen Site zugewiesen. Um dieses Protokoll zu veranschaulichen, wird der private Adressraum 10.154.0.0/16 verwendet.
   2. Weisen Sie den virtuellen Links zwischen den externen Sites und dem NFV-Ökosystem einen IP-Adressraum zu. Diese virtuellen Links werden von einem VPN-Dienst unterstützt. Um dieses Protokoll zu veranschaulichen, wird der Adressbereich 10.154.254.0/24 für diese virtuellen Links verwendet.
2. Richten Sie ein Gerät ein, um den VPN-Dienst (Virtual Private Network) bereitzustellen (d. h. einen VPN-Server). Insbesondere verwendet das Experiment einen Servercomputer mit Ubuntu 16.04 (64-Bit-Variantenabbild), sechs unabhängigen CPUs, 16 GB RAM, 1 TB Speicherfestplatte und zwei Netzwerkschnittstellen.
   1. Konfigurieren Sie eine der Netzwerkschnittstellen des VPN-Servers, um den Empfang von Verbindungsanforderungen von externen Standorten über das Internet zu ermöglichen. Zu diesem Zweck ist es notwendig, eine Schnittstelle des Servers zu verwenden, die mit einer öffentlichen IP-Adresse konfiguriert ist.
   2. Konfigurieren Sie die Verbindung zwischen dem VPN-Server und dem Edgerouter des zentralen Standorts. Im Experiment wurde diesem Link der Adressbereich 10.4.255.0/24 zugewiesen. Konfigurieren Sie die entsprechenden Netzwerkrouten auf dem VPN-Server, sodass von externen Standorten, die mit dem VPN-Dienst verbunden sind, auf das NFV-Ökosystem zugegriffen werden kann.
3. Installieren Sie die vom OpenVPN^23-Projekt bereitgestellte VPN-Open-Source-Software auf dem VPN-Server. Insbesondere verwendet dieses Experiment die OpenVPN-Version 2.3.10, und seine Bereitstellung erfolgte mit dem Bash-Skript "openvpn-install.sh", das unter http://github.com/Nyr/openvpn-install verfügbar ist (andere Installationsoptionen sind in der OpenVPN-Dokumentation ²⁴beschrieben). Das Bash-Skript stellt die alternativen Parameter dar, die zur Konfiguration des VPN-Dienstes führen.
   1. Wählen Sie die IP-Adresse aus, um VPN-Verbindungsanforderungen abzuhören (d. h. die öffentliche IP-Adresse).
   2. Entscheiden Sie, welches Protokoll (UDP oder TCP) verwendet werden soll, um die Kommunikation über das VPN zu steuern. In diesem Fall nutzt das Experiment UDP, das empfohlene Protokoll.
   3. Geben Sie den Port an, der das Duple (zusammen mit der öffentlichen IP-Adresse) umfasst, das zum Empfangen der Dienstverbindungsanforderungen verwendet wird. Standardmäßig ist der zugewiesene Wert 1194.
   4. Wählen Sie einen der DNS-Server der Liste aus, der vom Assistenten aufgefordert wird, der die von den Clients des VPN-Diensts ausgeführten Namensauflösungsanforderungen verarbeitet.
   5. Drücken Sie eine beliebige Taste, um die automatische Initiierung des VPN-Dienstinstallationsprozesses zu aktivieren.
4. Bearbeiten Sie die Konfigurationsdatei "server.conf", die sich im Verzeichnis "/etc/openvpn/server/" befindet, und fügen Sie die Direktive "client-to-client" hinzu, um das in Schritt 2.3 bereitgestellte Basis-Setup zu erweitern. So können sich verschiedene Clients, die mit dem VPN-Dienst verbunden sind, gegenseitig erreichen.
5. Aktivieren Sie die individuelle Client-Konfiguration innerhalb des VPN-Setups, um die Routing-Zuweisungen für jeden Client unabhängig verwalten zu können.
   1. Fügen Sie die Direktive "client-config-dir ccd" hinzu und bearbeiten Sie dieselbe Konfigurationsdatei wie in Schritt 2.4.
   2. Erstellen Sie das Verzeichnis "ccd" mit dem Befehl "mkdir /etc/openvpn/ccd/". Dieses Verzeichnis dient im nächsten Abschnitt des Protokolls dazu, die Dateien mit den Routing-Direktiven zu platzieren, die den Clients zugeordnet sind, die in die Plattform integriert werden sollen.
6. Richten Sie die Firewall-Regeln ein, die erforderlich sind, um die Verbindungen mit dem Dienst zuzulassen und gleichzeitig den VPN-Server vor böswilligen Angriffen zu schützen. Zu diesem Zweck nutzt dieses Experiment iptables²⁵, ein Befehlszeilendienstprogramm, das zur Konfiguration der Linux-Kernel-Firewall entwickelt wurde.
   1. Blockieren Sie zunächst den eingehenden Datenverkehr zum VPN-Server mit dem Befehl "iptables -P INPUT DROP".
   2. Erlauben Sie den Empfang von VPN-Verbindungsanforderungen mit den Befehlen "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( ist der Name der VPN-Serverschnittstelle mit der öffentlichen IP-Adresse) und "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Erlauben Sie die Weiterleitung von Datenverkehr zwischen den VPN-Serverschnittstellen (d. h. der öffentlichen Schnittstelle und der vom VPN-Dienst namens tun0erstellten virtuellen Schnittstelle), damit der VPN-Server die Dienstverbindungsanforderung verarbeiten kann. Führen Sie dazu den Befehl "iptables -A FORWARD -i tun+ -o -m state --state RELATED,ESTABLISHED -j ACCEPT && iptables -A FORWARD -i -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT" aus.
   4. Ermöglichen Sie es dem VPN-Server, die NAT-Funktion (Network Address Translation) bereitzustellen, mit dem Ziel, den Internetzugang zum zentralen Standort bereitzustellen, indem Sie Folgendes ausführen: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Einbindung einer externen NFV-Site

1. Rufen Sie einen geeigneten IP-Adressbereich ab, um die Site in das NFV-Ökosystem zu integrieren. Dieser Adressbereich wird vom Network Operations Center des NFV-Ökosystems bereitgestellt. Gemäß Schritt 2.1.1 dieses Protokolls verwendet das Experiment einen Bereich von IP-Adressen für die externe Site innerhalb von 10.154.0.0/16.
2. Erstellen und bereitstellen Sie die Sicherheitsanmeldeinformationen für die Verbindung mit dem NFV-Ökosystem.
   1. Generieren Sie VPN-Anmeldeinformationen, mit denen die neue Infrastruktur eine sichere Verbindung mit dem VPN-Server herstellen kann. Führen Sie dazu den Befehl "bash openvpn-install.sh" im VPN-Server aus, wählen Sie die Option "1) Neuen Client hinzufügen" der eingabeaufforderungsliste und geben Sie den Namen an, der diesen Anmeldeinformationen zugeordnet werden soll, z. B. uc3m_infrastructure. In diesem Schritt wird eine Datei mit den VPN-Anmeldeinformationen generiert (im Beispiel "uc3m_infrastructure.ovpn" genannt).
   2. Erstellen Sie eine Textdatei im Verzeichnis "/etc/openvpn/ccd/" des VPN-Servers, einschließlich der Routing-Direktiven (wie in der OpenVPN-Dokumentation ²⁴angegeben), die vom VPN-Server jedes Mal gepusht werden müssen, wenn eine Verbindung zum VPN-Dienst unter Verwendung der VPN-Anmeldeinformationen hergestellt wird.
      HINWEIS: Der Name der Textdatei muss mit dem Namen übereinstimmen, der bei der Erstellung der VPN-Anmeldeinformationen angegeben wurde (z. B. uc3m_infrastructure), um eine benutzerdefinierte Konfiguration für jeden VPN-Client bereitzustellen.
   3. Stellen Sie die VPN-Anmeldeinformationsdatei dem technischen Personal der externen Site zur Verfügung. Dies muss über einen sicheren und zuverlässigen Kanal erfolgen. In diesem Experiment wird ein manueller Verschlüsselungsprozess verwendet. Um die VPN-Anmeldeinformationen zu verschlüsseln, führen Sie den Befehl "7za a -tzip '-p' -mem=AES256 " aus und setzen Sie als gewünschten Verschlüsselungsschlüssel, al den gewählten Namen für die verschlüsselte Datei und als Dateiname der VPN-Anmeldeinformationsdatei (z. B. uc3m_infrastructure.ovpn).
   4. Stellen Sie die verschlüsselten Anmeldeinformationen dem technischen Personal des neuen Standorts zusammen mit dem Schlüssel, der die Entschlüsselungsverfahren ermöglicht, über einen sicheren Kommunikationskanal zur Verfügung.
      HINWEIS: In diesem Experiment wurden die verschlüsselten Anmeldeinformationen per elektronischer E-Mail bereitgestellt, während der Entschlüsselungsschlüssel über einen separaten Kanal unter Verwendung des Kurznachrichtendienstes (SMS) mit einer Offline-Vereinbarung der Telefonnummer gesendet wurde.
3. Richten Sie die Umgebung am neuen Standort ein, um die Verbindung mit dem NFV-Ökosystem herzustellen und die Remote-NFVI an den OSM-Stack des zentralen Standorts anzuhängen.
   1. Installieren Sie die von OpenVPN²⁴ bereitgestellte VPN-Software auf einem Computer, um eine virtuelle Verbindung zwischen dem externen Standort und dem zentralen Standort des NFV-Ökosystems zu ermöglichen. Der Computer mit der OpenVPN-Software dient als VPN-Client oder VPN-Endpunkt am externen Standort. Die virtuelle Verbindung wird über einen geschützten VPN-Tunnel zwischen dem VPN-Endpunkt und dem VPN-Server realisiert. Im Experiment wird der VPN-Endpunkt auf einem Servercomputer mit Ubuntu 18.04, 8 CPUs, 8 GB RAM, 128 GB Speicherfestplatte und 3 GbE-Schnittstellen (eine für die Verbindung mit dem VPN-Dienst über das Internet) ausgeführt.
   2. Aktivieren Sie die IP-Weiterleitung im VPN-Endpunkt, um Netzwerkroutingfunktionen zu unterstützen. Fügen Sie zu diesem Zweck die Zeile "net.ipv4.ip_forward=1" in die Systemkonfigurationsdatei ein, die sich im Pfad "/etc/sysctl.conf" befindet, und laden Sie die aktualisierte Konfiguration mit dem Befehl "sudo sysctl -p".
   3. Entschlüsseln Sie die VPN-Anmeldeinformationsdatei mit den in Schritt 3.2.4 erhaltenen Informationen mit dem Befehl "7za e ", wobei die der Dateiname der verschlüsselten VPN-Anmeldeinformationen ist. Geben Sie den Entschlüsselungsschlüssel an, wenn Sie vom Befehl dazu aufgefordert werden.
   4. Starten Sie die OpenVPN-Software mit der entschlüsselten Anmeldeinformationsdatei mit dem Befehl "sudo openvpn --config " ( ist der Dateiname der VPN-Anmeldeinformationen). Damit authentifiziert sich der VPN-Endpunkt beim VPN-Server und empfängt automatisch die entsprechenden VPN-Konfigurationsparameter und Netzwerkrouten. Auf diese Weise verhält sich der VPN-Endpunkt wie ein Edge-Router mit einer virtuellen Verbindung zum zentralen Standort des NFV-Ökosystems.
   5. Überprüfen Sie den ordnungsgemäßen Betrieb des VPN-Endpunkts, indem Sie den Befehl ping verwenden, um die Verfügbarkeit der Konnektivität mit einem der Knoten des zentralen Standorts (z. B. der OSM-Stack-Ausrüstung) zu überprüfen.
   6. Wählen Sie am neuen Standort ein OSM-kompatibles VIM aus, um den Betrieb mit der MANO-Plattform zu ermöglichen. Für dieses Experiment wird die OpenStack-Version Ocata verwendet.
      HINWEIS: OSM Release SEVEN unterstützt die folgenden virtuellen Infrastrukturmanager: OpenStack, OpenVIM^26,VMware vCloud Director^27,Amazon Web Service^28,Microsoft Azure²⁹und Eclipse fog05³⁰ (spezifische Konfigurationsdetails finden Sie in der OSM-Dokumentation^18).
   7. Installieren Sie OpenStack Release Ocata²⁰ (siehe die detaillierten Anweisungen in der Release-Dokumentation²¹).
   8. Stellen Sie die NFV-Infrastruktur am externen Standort bereit, und fügen Sie sie an das VIM an. Insbesondere verwendet dieses Experiment eine NFV-Infrastruktur, die aus drei Single-Board-Computern (SBCs) mit einer Rechenkapazität von jeweils 1 GB RAM, 4 CPUs und 32 GB Speicherplatte besteht. und ein einzelner Mini-ITX-Computer mit 8 CPUs, 8 GB RAM und 128 GB für die Speicherung.
      HINWEIS: Die externe Site, die in diesem Protokoll veranschaulicht wird, basiert auf einer NFV-Infrastruktur von NFV-fähigen kleinen unbemannten Luftfahrzeugen (SUAVs). Die Details, die befolgt werden, um eine solche Infrastruktur zu ermöglichen, sind in Nogales et al^{31 enthalten.} Die Schritte 3.3.6 bis 3.3.8 sind optional, da am externen Standort möglicherweise bereits eine NFV-Infrastruktur vorhanden ist.
   9. Erstellen Sie ein OpenStack-Projekt, um den Satz von Rechenressourcen der externen Site anzugeben, die in das NFV-Ökosystem integriert werden. Greifen Sie dazu auf die von OpenStack bereitgestellte grafische Benutzeroberfläche (GUI) zu, melden Sie sich mit den Administratoranmeldeinformationen am System an, klicken Sie auf die Schaltfläche + Projekt erstellen der Registerkarte Identität -> Projekte und erstellen Sie ein Projekt, das das angezeigte Formular mit den angeforderten Informationen vervollständigt.
   10. Erstellen Sie einen gültigen Benutzer, der das im vorherigen Schritt erstellte Projekt verwaltet. Greifen Sie zu diesem Zweck auf die Registerkarte Identität -> Benutzer mit dem gleichen Login wie im vorherigen Schritt zu, klicken Sie auf + Benutzer erstellen und füllen Sie die erforderlichen Felder des angezeigten Formulars (Benutzername und Kennwort) aus, wählen Sie das neu erstellte Projekt als primäres Projekt aus und wählen Sie die Administratorrolle aus.
   11. Ändern Sie die Sicherheitsregeln, um VNF-Kommunikationsberechtigungen am neuen Standort zuzulassen (insbesondere SSH- und ICMP-Datenverkehr zu aktivieren). Greifen Sie zu diesem Zweck mit den im vorherigen Schritt erstellten Anmeldeinformationen des Benutzers auf die OpenStack-GUI zu, folgen Sie der Reihenfolge: Project -> Network -> Security Groups -> + Add Ruleund wählen Sie die SSH-Option des Dropdown-Menüs Rule aus. Wiederholen Sie den Vorgang, wählen Sie jedoch die Option Alle ICMP aus, die im Dropdown-Menü enthalten ist.
   12. Laden Sie die Bilder eines von der OSM-Community angebotenen Testdienstes, des Ping Pong-Netzwerkdienstes ("Fedora-x86_64-20-20131211.1-sda-ping" und "Fedora-x86_64-20-20131211.1-sda-pong") aus dem öffentlichen Experiment-Repository herunter und laden Sie sie auf das VIM der externen Website hoch. Befolgen Sie dazu die Sequenz Project -> Compute -> Images -> + Create Image, und erstellen Sie die Bilder mit dem angezeigten Formular und wählen Sie jedes Bild aus.
   13. Weisen Sie zwei IP-Adressbereiche innerhalb des Adressraums des externen Standorts zu (zugewiesen in Schritt 3.1). Diese Bereiche werden verwendet, um die Verwaltung der VNFs des externen Standorts zu unterstützen und die standortübergreifende Datenkommunikation zwischen VNFs zu ermöglichen.
   14. Erstellen Sie mit dem VIM einProvider-Netzwerk ( Control-Provider). Dieses Netzwerk unterstützt die NFV-Kommunikation zwischen dem OSM-Stack am zentralen Standort und den VNFs, die am neuen Standort zu Verwaltungszwecken bereitgestellt werden. Diese Art der Kommunikation ermöglicht es dem OSM-Stack auch, VNFs nach ihrer Bereitstellung zu konfigurieren. Um ein Provider-Netzwerk in OpenStack zu erstellen, folgen Sie der Sequenz Admin -> System -> Networks -> + Create Network und geben Sie die Details des neuen Netzwerks mit dem ausgewählten IP-Adressbereich im vorherigen Schritt ein.
   15. Erstellen Sie mit dem VIM ein zweitesProvider-Netzwerk ( Data-Provider). Dieses Netzwerk wird die Datenkommunikation zwischen den VNFs des Standorts und anderen VNFs des NFV-Ökosystems unterstützen. Um dieses Provider-Netzwerk in OpenStack zu erstellen, folgen Sie der Sequenz Admin -> System -> Networks -> + Create Networkund geben Sie die Details des neuen Netzwerks mit dem zugewiesenen Adressbereich ein.
       HINWEIS: Die Anweisungen zum Erstellen virtueller Netzwerke variieren je nach VIM-Software. Weitere Informationen finden Sie in der jeweiligen Softwaredokumentation.
   16. Teilen Sie die VIM-bezogenen Informationen (insbesondere den Benutzernamen/das Kennwort und das in den Schritten 3.3.9 und 3.3.10 erstellte Projekt) mit dem technischen Personal des zentralen Standorts, um das Anhängen des VIM an den OSM-Software-Stack zu ermöglichen.
4. Schließen Sie die externe NFV-Infrastruktur mithilfe der informationen aus Schritt 3.3.16 an den OSM-Software-Stack des zentralen Standorts an.
   1. Überprüfen Sie die Konnektivität zwischen dem OSM-Stack des zentralen Standorts und dem VIM des neuen Standorts mithilfe des Ping-Tools.
   2. Wenn der vorherige Konnektivitätstest erfolgreich ist, fügen Sie das externe VIM an den OSM-Stack des zentralen Standorts an. Verwenden Sie dazu den folgenden Befehl im OSM-Computer: "osm vim-create --name --user --password --auth_url --tenant --account_type ". In diesem Befehl: ist der Name, der ausgewählt wurde, um das VIM innerhalb des OSM-Stacks zu identifizieren, ist der Name des Benutzers, der berechtigt ist, die Ressourcen der externen Site zu verarbeiten (siehe Schritt 3.3.10), ist das Kennwort des angegebenen Benutzers, ist der Link zu der API, die vom VIM zur Verfügung gestellt wird, um Anforderungen vom OSM-Stack zu ermöglichen. ist der in Schritt 3.3.9 definierte Projektname, und ist die verwendete VIM-Software (in diesem Experiment OpenStack).
5. Überprüfen Sie die entsprechende Anfügung des neuen VIM an den OSM-Stack des NFV-Ökosystems.
   1. Führen Sie den Befehl "ro_id=$(docker ps | grep osm_ro | cut -d ' ' -f 1)", um die ID des Containers zu identifizieren, der das Resource Orchestrator (RO)-Modul innerhalb des OSM-Systems implementiert. Dieses Modul ist für die Interaktion mit den VIMs verantwortlich, um die benötigten Ressourcen bei der Bereitstellung nachfolgender Netzwerkdienste zu koordinieren und zuzuweisen.
   2. Greifen Sie mit dem Befehl "docker exec -it $ro_id bash" auf den RO-Container zu. Dieser Befehl verwendet den Bezeichner, der bei der Ausführung des vorherigen Schritts erhalten wurde.
   3. Überprüfen Sie, ob das neue VIM in der Liste der verfügbaren Datencenter enthalten ist, indem Sie den Befehl "openmano datacenter-list" verwenden. Die neue Site sollte in der Liste mit dem gleichen Namen wie die zuvor eingeführte Site in Schritt 3.4.2 mit dem parameter angezeigt werden.
   4. Listen Sie die Bilder auf, die in das VIM der externen Site hochgeladen wurden, mit dem Befehl "openmano vim-image-list --datacenter ". Der Parameter gibt den Namen an, der ausgewählt wurde, um das VIM innerhalb des OSM-Stacks zu identifizieren. Wenn die Ausführung dieses Befehls erfolgreich ist, wurde die Verbindung mit dem externen VIM erfolgreich hergestellt. Überprüfen Sie, ob die Ping Pong-Bilder in der Liste enthalten sind.
   5. Listen Sie die am neuen Standort verfügbaren Netzwerke mit dem Befehl "openmano vim-net-list --datacenter " auf. Überprüfen Sie, ob Control-Provider und Data-Provider vorhanden sind.
6. Führen Sie eine vorläufige Validierung der ordnungsgemäßen Integration der neuen Website durch, indem Sie einen von der OSM-Community angebotenen Testdienst verwenden (der gesamte Inhalt in dieser Hinsicht ist im Experiment-Repository enthalten). Zu diesem Zweck werden die in den folgenden Schritten enthaltenen Befehle in der Ausrüstung ausgeführt, die den OSM-Stack hostet.
   1. Integrieren Sie die VNF-Deskriptoren (VNFDs) in den OSM-Stack, indem Sie den Befehl "osm vnfd-create " für jeden der VNFs ausführen, aus denen der Testdienst besteht ( entspricht dem Dateinamen des VNFD-Pakets).
   2. Integrieren Sie den NS-Deskriptor (NSD) des Testdiensts mit dem Befehl "osm nsd-create ", wobei angibt den Dateinamen des NSD-Pakets (in diesem Experiment ping_pong_ns.tar.gz)."
   3. Starten Sie die Instanziierung des Ping Pong Network Service (NS) auf den externen und zentralen Sites mit dem Befehl "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }]}'". Der Parameter identifiziert den VIM der externen Site innerhalb des OSM-Stacks. Die Option "--config" gibt an, dass alle VNFs, aus denen sich der Dienst zusammensetzt, auf dem externen Standort bereitgestellt werden müssen, der von diesem VIM verarbeitet wird, mit Ausnahme des VNF, der durch den Index 2 im NS identifiziert wird, der am zentralen Standort bereitgestellt wird (der VIM des zentralen Standorts wird im parameter angegeben).
   4. Überprüfen Sie mit dem Befehl "osm ns-list", ob der NS bereitgestellt wurde und welchen Status er hat. Wenn die Instanziierung erfolgreich ist, ändert sich der Status in "BEREIT".
   5. Überprüfen Sie die IP-Adresse jedes der beiden VNFs mit "osm vnf-list" (notwendig, um sich anschließend bei den Maschinen anzumelden).
   6. Verbinden Sie sich mit jedem VNF über SSH mit dem Befehl "ssh fedora@" ( stellt die IP-Adresse des VNF dar, mit dem eine Verbindung hergestellt werden soll, erhalten sie im vorherigen Schritt). Geben Sie das Passwort "fedora" ein, wenn Sie von SSH dazu aufgefordert werden. Sobald Sie bei beiden Maschinen angemeldet sind, überprüfen Sie ihre Schnittstellen mit dem Befehl "ip address show" und erhalten Sie die IP-Adressen auf ihren Schnittstellen, die an das Datenanbieternetzwerk angeschlossen sind (Schnittstelle eth1 in beiden VNFs). Führen Sie von einem der VNFs aus einen Ping an den anderen VNF aus, indem Sie die Remote-IP-Adresse im Datenanbieternetzwerk verwenden. Wenn eine Konnektivität besteht, wird der vorläufige Validierungstest als erfolgreich angesehen.

4. Validierung der NFV-Multi-Site-Plattform mit einem realistischen vertikalen Service

1. Laden Sie die VNF-Bilder aus dem öffentlichen Repository herunter und laden Sie sie in das VIM der entsprechenden Site hoch (siehe Abbildung 3), indem Sie das in Schritt 3.3.12 beschriebene Verfahren befolgen. Insbesondere hostet der externe Standort den Access Point VNF, den Router VNF, den MQTT Gateway VNF und den Access Router VNF. Der zentrale Standort wird den 5G Core VNF und den IoT Server VNF hosten.
2. Integrieren Sie die VNFDs und die NSD des Smart-Farming-Dienstes in den OSM-Stack (alle Deskriptoren können aus dem Experiment-Repository heruntergeladen werden).
   1. Integrieren Sie die VNFDs in den OSM-Stack und führen Sie den Befehl "osm vnfd-create " für jeden der VNFs des Netzwerkdiensts aus. In diesem Fall entspricht der Parameter dem Dateinamen des VNFD-Pakets.
   2. Integrieren Sie die NSD in den OSM-Stack mit dem Befehl "osm nsd-create ", wobei den Dateinamen des NSD-Pakets angibt (in diesem Experiment jove_uavs_scenario_nsd.tar.gz).
3. Stellen Sie den Smart Farming-Netzwerkdienst bereit. Führen Sie zu diesem Zweck den folgenden Befehl über die OSM-Befehlszeilenschnittstelle aus: osm ns-create --ns_name --nsd_name jove_uavs_scenario_nsd --vim_account --config '{vnf: [ {member-vnf-index: "5", vim_account: }, {member-vnf-index: "6", vim_account: } ], wim_account: False }'.
   HINWEIS: Wie in Schritt 3.6.3 angegeben, geben die Parameter und die Standorte an, an denen die VNFs bereitgestellt werden sollen. Insbesondere werden alle VNFs, aus denen sich der Smart Farming-Dienst zusammensetzt, an der neuen externen Website platziert, mit Ausnahme derjenigen mit Index 5 und 6 (der 5G Core und die IoT-Server-VNFs),die dem zentralen Standort zugewiesen werden.
4. Überprüfen Sie, ob der NS bereitgestellt wurde, und befolgen Sie dasselbe Verfahren wie in Schritt 3.6.4.
5. Zugriff auf das IoT-Server-VNF mit dem Befehl "ssh mosquittosubscriber@" und Überprüfen der für die Kommunikation mit MQTT Gateway VNF konfigurierten Schnittstelle über den Befehl "ip address show dev eth1". Die IP-Adresse des VNF () kann durch Ausführen der "osm vnf-list" in der OSM-Kommandozeile abgerufen werden.
6. Greifen Sie nach einem analogen Verfahren auf das MQTT Gateway VNFzu und führen Sie den Befehl "sudo python3 publisher_MQTT_GW.py -ma -ba " aus, wobei die im vorherigen Schritt abgerufen wird, und die ausführen des Befehls "ip address show dev eth1" im MQTT Gateway VNF. Dieser Schritt initialisiert den MQTT Gateway VNF, der vom Sensor mit dem MQTT-Standard¹⁵generierte Daten empfängt und diese Daten mit demselben Standard an den IoT-Server VNF überträgt.
7. Bereiten Sie einen Single Board Computer (SBC) vor, der einen meteorologischen Sensor anschließt und über eine Transceiver-Kapazität verfügt, um Sensormesswerte in Richtung MQTT Gateway VNF zu übertragen.
   HINWEIS: Um dieses Protokoll zu veranschaulichen, wurde insbesondere ein SBC-Modell verwendet. Daher müssen die folgenden Schritte möglicherweise im Falle der Verwendung einer anderen SBC-Plattform angepasst werden.
   1. Schließen Sie die Platinenpins des Sensors (z. B. mit zinngelöteten Kupferdrähten) an die GPIO-Pins (Allzweck-Eingang/Ausgang) des SBC an, wobei das Konfigurationsschema in Abbildung 5 befolgt wird.
   2. Aktivieren Sie das I2C-Kernelmodul im SBC, um überprüfen zu können, ob der Sensor erkannt wird. Führen Sie dazu den Befehl "sudo raspi-config" aus, folgen Sie der Reihenfolge Schnittstellenoptionen -> I2C -> Ja im angezeigten Menü und starten Sie den SBC neu, um die Änderungen wirksam zu machen.
   3. Überprüfen Sie, ob der Sensor erkannt wird Installieren Sie die Software i2c-tools im SBC und führen Sie den Befehl "sudo i2cdetect -y 1" aus. Wenn dies der Fall ist, sollte ein Raster angezeigt werden, das die Position angibt, an der der Sensor erkannt wird.
   4. Installieren Sie die entsprechenden Softwarebibliotheken, damit der SBC die vom Sensor bereitgestellten Daten lesen und senden kann. Dieses Experiment nutzt insbesondere die Python-Bibliotheken RPi.bme280³² und paho-mqtt^33.
8. Nehmen Sie mit der mobilen Anwendung des SUAV das Luftfahrzeug ab, das den Access Point VNFbeherbergt, und positionieren Sie es, um mit dem Sensor eine drahtlose Abdeckung des SBC zu gewährleisten.
   HINWEIS: Der Flug der NFV-fähigen SUAVs ist unabhängig vom Betriebsverhalten des Netzwerkdienstes, der in der Lage ist, unabhängig davon zu arbeiten, ob die SUAVs fliegen oder sich in einem Ruhezustand befinden, um den Batterieverbrauch zu verringern. Somit ist der Schritt 4.8 optional.
9. Schließen Sie den SBC, der für das Lesen der vom Sensor gesammelten Daten verantwortlich ist, an den Wi-Fi Wireless Access Point an, der vom Access Point VNFbereitgestellt wird. Nach einem erfolgreichen Anhang wird ein drahtloser Netzwerkpfad vom Sensor zum MQTT Gateway VNFaktiviert.
10. Starten Sie die Übertragung der erfassten Daten, indem Sie den Befehl "python3 /home/ubuntu/sensorDataTransmission.py -a " im SBC ausführen, der den Sensor enthält ( ist die IP-Adresse, die in Schritt 4.6 erhalten wurde).
11. Greifen Sie auf die vom IoT-Server VNF bereitgestellte Web-GUI zu, um den korrekten Echtzeitempfang der erfassten Daten zu überprüfen. Überprüfen Sie dazu die IP-Adresse des IoT Server VNF mit dem Befehl "osm vnf-list" und geben Sie den folgenden Uniform Resource Locator (URL) in einen Webbrowser ein: http://:3001, wobei die IP-Adresse des IoT-Servers VNFist. Klicken Sie dann auf die Schaltfläche Sensors Data Collection der Registerkarte Home und überprüfen Sie die Echtzeitaktualisierung der im Dashboard enthaltenen Diagramme, wenn Daten empfangen werden.
    HINWEIS: Um auf die in Schritt 4.12 erwähnte URL zugreifen zu können, muss das Gerät mit dem Webbrowser, der versucht, diese Ressource zu erreichen, mit dem NFV-Ökosystem verbunden sein und über eine IP-Verbindung mit dem IoT Server VNF verfügen. Der VPN-Dienst kann auch für diesen Zweck verwendet werden.
12. Warten Sie einen angemessenen Zeitraum, um repräsentative Ergebnisse der Ausführung des Smart-Farming-Dienstes zu erhalten. Sammeln Sie dann die im VNF des IoT-Servers gespeicherten Daten zur weiteren Analyse. In Anbetracht der Tatsache, dass der in diesem Experiment enthaltene Sensor alle 5 Sekunden Temperatur-, Feuchtigkeits- und Druckwerte liefert, läuft der Dienst im Experiment für einen Zeitraum von 10 Minuten, was zu 180 Proben von erfassten Daten führt (60 für jeden meteorologischen Werttyp).
13. Greifen Sie auf die Datenbank des IoT Server VNF zu, um die erfassten Daten zur weiteren Analyse abzurufen. Führen Sie dazu den Befehl "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1)" auf dem IoT Server VNF und dann "sudo docker exec -it $id_database bash"
14. Exportieren Sie die Daten in eine CSV-Datei (Comma-Separated Value) mit dem Befehl "influx -database 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Ändern Sie den Parameter , um auszuwählen, welcher Typ von erfassten Daten mit "temperatur", "feuchtigkeit" oder "druck" exportiert werden soll, und legen Sie den Parameter fest, um einen Namen für die Ausgabedatei auszuwählen, die die Ergebnisse enthält.
15. Speichern Sie die im vorherigen Schritt generierten Datendateien zur späteren Darstellung (siehe Abschnitt Repräsentative Ergebnisse) und zur Überprüfung des ordnungsgemäßen Betriebs des Smart-Farming-Dienstes.

Ergebnisse

Nach sorgfältiger Befolgung des Protokolls, um einen neuen Standort in die zentrale Plattform zu integrieren und einen Netzwerkdienst auszuführen, um seine ordnungsgemäße Funktionalität zu überprüfen, zeigt Abbildung 6 einen Screenshot des Open-VPN-Monitor-Tools. Es kann beobachtet werden, wie der neue Standort das VPN für seine gesamte Kommunikation verwendet, was zeigt, wie seine Kommunikation dem VPN folgt, um diesen Datenaustausch und damit die korrekte Hinzufügung des neuen Standorts zum VPN-Dienst zu ermöglichen.

Wie in Abbildung 3dargestellt, übermittelt der Netzwerkdienst Informationen von einem Sensor in einer Remoteinfrastruktur an den Server am zentralen Standort. Darüber hinaus zeigt Abbildung 7 die erfolgreiche Bereitstellung des Netzwerkdiensts über die OSM-Web-GUI und zeigt, wie das Experiment in der neuen Remote-Infrastruktur vom MANO-Stack innerhalb des zentralen Standorts ordnungsgemäß instanziiert werden kann. Darüber hinaus beträgt die Zeit, die im Experiment benötigt wird, um die Bereitstellung des Dienstes abzuschließen, etwa acht Minuten. Dieser Wert, zusammen mit der Zeit, die benötigt wird, um die Dienstdeskriptoren in die Orchestrierungsplattform einzubauen (etwa 9 Sekunden, mit 1,3 Sekunden pro Deskriptor, unter Berücksichtigung sowohl der NS- als auch der einzelnen VNF-Deskriptoren), ermöglichen es, den Key Performance Indicator (KPI) von 90 Minuten für die Diensterstellungszeit zu erfüllen, wie in der 5G Infrastructure Public Private Partnership³⁴angegeben. In diesem Zusammenhang umfasst die in Vidal et al.⁹ vorgestellte Arbeit eine eingehende Analyse der Diensterstellungszeit mit mehreren Standorten unter Verwendung des vorgestellten Protokolls.

Abbildung 8 zeigt die vom Sensor erfassten Daten, einschließlich der Werte für Feuchte, Temperatur und Druck. Diese Proben entsprechen allen Daten, die vom Sensor an einen Remote-Server in 5TONIC gesendet werden, wo diese Werte in einer Datenbank gespeichert werden. All diese Daten zeigen, dass die Plattform in der Lage ist, nach der Integration einer neuen Infrastruktur praktische Netzwerkdienste bereitzustellen und die Kommunikation zwischen Standorten korrekt zu ermöglichen.

Abbildung 1: VPN-Dienststandortverteilung. Verteilung des VPN-Dienstes über die Plattform und deren Verbindungskonnektivität (alle über 5TONIC). Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 2. Überblick über die Plattform und den VPN-Dienst. Diese Abbildung zeigt alle Elemente der Plattform: den zentralen Standort zusammen mit der NFV-Infrastruktur, den VPN-Dienst und eine neue Infrastruktur, die mit dem System aggregiert ist. Es enthält auch die Verbindungen zwischen seinen Elementen. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 3: Übersicht über den Netzwerkdienst. Es stellt die Elemente dar, die am Netzwerkdienst beteiligt sind, seine Verteilung und seine logische und Netzwerkkonnektivität. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 4:Protokollworkflows. Jede Spalte stellt einen Abschnitt des Protokolls dar, in dem jede ausgeführte Aktion beschrieben wird, ihre logische Verbindung zwischen ihnen und der Komponente, die für ihre Ausführung verantwortlich ist. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 5:Pin-Konfigurationsschema. Diagramm, das darstellt, wie die physischen Verbindungen zwischen den Platinenpins der Sensoren und den GPIO-Pins des SBC hergestellt werden, der diesen Sensor enthält. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 6: OpenVPN-Monitor-Snapshot. Das Bild zeigt, dass die aggregierte Infrastruktur mit dem VPN-Dienst verbunden ist, einschließlich einiger Details zu seiner Verbindung. Darüber hinaus zeigt die Abbildung auch zusätzliche Verbindungen, die zu anderen entfernten Infrastrukturen gehören. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 7:OSM NS-Bereitstellungsstatus. Grafische OSM-Oberfläche, die die erfolgreiche Bereitstellung des Testnetzwerkdienstes in der Remote-Infrastruktur anzeigt. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Abbildung 8: Repräsentative Analyse der vom Sensor gesammelten Daten. (A) Abbildung der Temperaturdaten, die periodisch alle 5 Sekunden vom Sensor erfasst werden. (B) Grafische Darstellung der vom Sensor alle 5 Sekunden erfassten Feuchtedaten. (C) Visuelle Darstellung der vom Sensor alle 5 Sekunden erfassten Druckdaten. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzuzeigen.

Diskussion

Einer der wichtigsten Aspekte des zuvor beschriebenen Protokolls ist seine herausragende Flexibilität, neue Recheninfrastrukturen in ein NFV-Ökosystem zu integrieren, unabhängig von ihrer Verteilung in Bezug auf den geografischen Standort (solange Bandbreite und Latenz der Netzwerkkommunikation mit Remote-Standorten dies unterstützen). Dies ist durch eine VPN-basierte Overlay-Netzwerkarchitektur möglich, die den Aufbau einer virtuellen Verbindung ermöglicht, um Remote-Standorte mit den zentralen Räumlichkeiten des NFV-Ökosystems zu verbinden. Dieser Ansatz ermöglicht die Bereitstellung eines effektiven und sicheren Kanals zur Unterstützung der NFV- und Datenkommunikation zwischen Standorten eines NFV-Ökosystems, wodurch die Wahrscheinlichkeit verringert wird, dass externe Parteien auf vertrauliche Informationen zu NFV-Orchestrierungsprozessen und Daten aus bereitgestellten Diensten zugreifen und/oder diese ändern. In diesem Zusammenhang beschreibt das Protokoll auch eine spezifische Methodik, um die VPN-Anmeldeinformationen sicher mit den externen Standorten zu teilen, die die Integration neuer Infrastrukturen ermöglichen. Das Protokoll wurde anhand des NFV-Ökosystems veranschaulicht, das bei 5TONIC von der Universidad Carlos III de Madrid, Telefónica und dem IMDEA Networks Institute zur Verfügung gestellt wurde, obwohl es generisch ist, um in anderen NFV-Umgebungen verwendet zu werden, die die in Schritt 1 dieses Protokolls genannten Voraussetzungen erfüllen.

Darüber hinaus ist die ausschließliche Verwendung von Open-Source-Tools und Software für die Protokollimplementierung hervorzuheben. Ungeachtet der potenziell vorteilhaften Funktionalitäten, die von verschiedenen proprietären Lösungen (z. B. Fortinet³⁵⁾angeboten werden könnten, hat der Einsatz von Open-Source-Entwicklungen die Integration aller vom Protokoll erfassten Elemente aufgrund ihrer inhärenten Eigenschaften wie Kosteneffizienz, umfangreiche Softwareunterstützung durch die Open-Source-Community und ein hohes Maß an Zuverlässigkeit erleichtert. um nur einige zu nennen. Darüber hinaus kann der Einsatz von Open-Source-Technologien auch Synergien zwischen Komponenten ähnlicher Art fördern. Um beispielsweise den VPN-Verbindungsstatus für die Clients zu überwachen, die die Plattform verwenden, könnte sich der im gesamten Protokoll implementierte VPN-Dienst auf das Open-VPN-Monitor-Tool³⁶ verlassen (ein Python-basiertes Überwachungstool, das mit OpenVPN-Servern zusammenarbeiten kann).

Auf der anderen Seite berücksichtigt die Protokollspezifikation die Instanziierung von Netzwerkdiensten über verschiedene Standorte hinweg zu Validierungszwecken. In diesem Zusammenhang ist es wichtig hervorzuheben, dass die Bereitstellung von Diensten an einem bestimmten Standort von der Verfügbarkeit von Rechen-, Speicher- und Netzwerkressourcen am Standort sowie von Spezialgeräten abhängt, die für die Bereitstellung erforderlich sein könnten (z. B. NFV-fähige SUAVs). Dies ist keine Einschränkung des Protokolls und sollte von Interessengruppen berücksichtigt werden, die an der Reproduktion des in diesem Papier beschriebenen Experiments interessiert sind.

Darüber hinaus ist darauf hinzuweisen, dass die für die Bereitstellung von Netzwerkdiensten erforderliche Zeit in hohem Maße von mehreren Faktoren abhängt, wie z. B. dem Netzwerkpfad zwischen dem Orchestrator und den verschiedenen VIMs, der Leistung der Datenkommunikation zwischen dem VIM und seinen verwalteten Rechenknoten sowie von der intrinsischen Natur dieser Rechenknoten (nicht nur aufgrund ihrer verfügbaren Rechenressourcen, B. aber auch die Technologien, die zur Virtualisierung von Netzwerkfunktionen integriert sind).

Schließlich und angesichts der herausragenden Leistung, die diese Plattform und ihr VPN-Dienst bei den europäischen Projekten und Kooperationsarbeiten erbracht haben, in denen sie bisher verwendet wurde (z. B. 5GINFIRE, 5GRANGE oder 5GCity, die in der Einleitung dieses Dokuments erwähnt werden), wird sie als ein wichtiges Element in aufstrebenden europäischen Projekten angesehen, bei denen die Universidad Carlos III de Madrid, Telefónica und das IMDEA Networks Institute nehmen teil, wie das Horizon 2020 LABYRINTH oder nationale Projekte wie TRUE-5G.

Materialien

Name	Company	Catalog Number	Comments
Bebop 2	Parrot		UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of external site.
BME280 Sensor	Bosch		Sensor capable of providing readings of the environmental conditions regarding temperature, barometric pressure, and humidity.
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 extternal aite. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the NFV insfrastrucure included in that site.
Iptables	Netfilter - Open source tool		(Software) An open source command line utility for configuring Linux kernel firewall rulset. Source-code available online: https://www.netfilter.org/projects/iptables/
Lithium Battery Pack Expansion Board. Model KY68C-UK	Kuman		Battery-power supply HAT (Hardware Attached on Top) for the UAV computation units composing the NFV infrastructure of the external site.
MacBook Pro	Apple		Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript.
Mainflux	Mainflux Labs - Open source platform		(Software) Open source Internet of Things (IoT) platform used in the experiment for implementing the virtual network function called as IoT Server VNF. In addition, this platform includes an open-source software based on Grafana which allows the visualization and formatting of the metric data. Source code available online: https://www.mainflux.com/
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/docs/user-guide/
OpenStack - Release Ocata	OpenStack - Open source community		(Software) Open source software used for setting up both the NFV infrastrucure of the central site and the NFV infrastructure of external site within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu
OpenVPN - Version 2.3.10	OpenVPN - Open source community		Open source software implementing the VPN service presented in the experiment for the creation of the overlay network that will enable the operations of the NFV ecosystem (providing connectivity among all the sites comprising the ecosystem). Source-code available online: https://openvpn.net/
Openvpn-monitor	Python - Open source software		(Software) Open source program based on Python code that allows the visualization of the state of the VPN service, as well as the representation of the sites that are connected at every instant. For this purpose, the program check priodically the information provided by the VPN server implemented with OpenVPN. Source-code available online: https://github.com/furlongm/openvpn-monitor
Paho-mqtt 1.5.0	Python - Open source library		(Software) Open source library developed in Python code that enables the trasmission of the data read by the sensor through the use of MQTT standard  Source-code available online: https://pypi.org/project/paho-mqtt/
Ping	Debian - 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 central site presented in the experiment.
Power Edge R430	Dell		High-profile computer server in charge of hosting the virtual private network (VPN) service. Note that the computing requirements for provisioning this service are high due to the resource consumption of the encryption operations present in the service.
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 of the central site 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.
Raspberry PI. Model 3b	Raspberry Pi Foundation		Selected model of Single Board Computer (SBC ) used for providing the computational capacity to the experiment's external site. In addition, this SBC model is used during the deployment of the included realistic service for interpreting and sending the data collected by a sensor.
RPi.bme280 0.2.3	Python - Open source library		(Software) Open source library developed in Python code that allows to interface the sensor Bosch BME280, and interpret the readings offered by that sensor. Source-code available online: https://pypi.org/project/RPi.bme280/