Integration af 5G-eksperimenteringsinfrastrukturer i et NFV-økosystem med flere websteder

Summary

Formålet med den beskrevne protokol er at understøtte fleksibel inkorporering af 5G-eksperimenteringsinfrastrukturer i et NFV-økosystem med flere websteder gennem en VPN-baseret overlejringsnetværksarkitektur. Desuden definerer protokollen, hvordan man validerer effektiviteten af integrationen, herunder en vertikal tjeneste på flere websteder med NFV-kompatible små luftfartøjer.

Abstract

Netværksfunktionsvirtualisering (NFV) er blevet betragtet som en af de vigtigste katalysatorer for^5. generation af mobilnet eller 5G. Dette paradigme gør det muligt at reducere afhængigheden af specialiseret hardware til at implementere telekommunikation og vertikale tjenester. Til dette formål er den afhængig af virtualiseringsteknikker til at blødgøre netværksfunktioner, forenkle deres udvikling og reducere implementeringstid og omkostninger. I den forbindelse har Universidad Carlos III de Madrid, Telefónica og IMDEA Networks Institute udviklet et NFV-økosystem inden for 5TONIC, et åbent netværksinnovationscenter med fokus på 5G-teknologier, der muliggør oprettelse af komplekse, tæt på reality-eksperimenter på tværs af et distribueret sæt NFV-infrastrukturer, som kan stilles til rådighed af interessenter på forskellige geografiske steder. Denne artikel præsenterer den protokol, der er blevet defineret til at indarbejde nye fjerntliggende NFV-websteder i NFV-økosystemet med flere websteder baseret på 5TONIC, der beskriver kravene til både de eksisterende og de nyligt indarbejdede infrastrukturer, deres forbindelse gennem en overlejringsnetværksarkitektur og de trin, der er nødvendige for at medtage nye websteder. Protokollen eksemplificeret gennem inkorporering af et eksternt websted til 5TONIC NFV økosystem. Derefter beskriver protokollen de bekræftelsestrin, der kræves for at validere en vellykket webstedsintegration. Disse omfatter indsættelse af en vertikal tjeneste med flere websteder ved hjælp af en ekstern NFV-infrastruktur med små ubemandede luftfartøjer (SAV'er). Dette tjener til at fremvise protokollens potentiale til at muliggøre distribuerede eksperimenter scenarier.

Introduction

Indførelsen af femte generation af mobilnet (5G) har betydet en revolution af telekommunikationsindustrien siden begyndelsen af dette årti, hvilket kræver, at teleoperatørerne skal tage fat på de langt mere krævende specifikationer for de nye netværkstjenester og applikationer, der er udviklet under 5G-paraplyen^1,2 . Disse nye specifikationer omfatter, men er ikke begrænset til, stigninger i datahastigheder, forbedringer af ventetiden på trådløs transmission og reduktion af driftsomkostninger. Blandt de teknologier, der udgør grundlaget for forbedringerne for denne nye generation, er Network Functions Virtualization³ (NFV) blevet en af dens vigtigste katalysatorer. NFV giver kapacitet til at blødgøre netværksfunktioner, traditionelt videresendelse på specialiseret hardware, ved hjælp af generisk-formål fysisk udstyr i stedet, såsom servercomputere i et datacenter. Med dette nye paradigme kan telekommunikationsoperatører og vertikale industrier implementere netværksfunktioner og -tjenester som et sæt softwarekomponenter og spare omkostninger i både serviceimplementering og vedligeholdelse samt lette en meget højere netværksinfrastrukturelasticitet. Denne tilgang letter eller eliminerer behovet for at bruge dedikerede (og normalt mere komplekse og mindre genanvendelige) enheder til de fleste netværks- og vertikalspecifikke funktioner og understøtter en meget højere og tættere grad af driftsautomatisering, hvilket reducerer implementerings- og vedligeholdelsesomkostningerne.

I betragtning af alle de fordele, som et NFV-miljø er i stand til at give, er det naturligt, at et stort antal relevante interessenter fra telekommunikationssektoren i stigende grad har været involveret i afprøvning af nye serviceidéer om NFV-miljøer. I den forbindelse har Telefónica og IMDEA Networks Institute oprettet 5TONIC⁴, et åbent forsknings- og innovationslaboratorium med fokus på 5G-teknologier. Baseret i Madrid (Spanien), dette laboratorium har en bred vifte af teknologier til rådighed for forskere og partnere til at øge udviklingen og valideringen af 5G-tjenester. Dette laboratorium har især en eksperimentel NFV-platform, hvor udviklere er i stand til at implementere og teste deres nye NFV-baserede applikationer og tjenester på et ETSI-kompatibelt NFV-økosystem⁵. Således kan eksperimentelle konklusioner om designvalg og teknologiforslag udledes i et realistisk meget mere fleksibelt miljø end produktionsnetværk. Denne platform er designet til at understøtte forsøgsaktiviteter på tværs af flere eksterne websteder, som kan være fleksibelt forbundet med 5TONIC ved hjælp af en veldefineret protokol.

Den tekniske løsning, der er vedtaget for 5TONIC NFV-økosystemet, overvejer udnyttelsen af en enkelt NFV-orkestervært, der implementeres ved hjælp af ETSI-hostet Open Source MANO (OSM) software⁶. Dette er det element, der har til ansvar for at styre og koordinere livscyklussen for netværkstjenester (NS). Disse tjenester kan bygges som en sammensætning af Virtualized Network/Vertical Functions (VNF), som kan implementeres på et hvilket som helst af de steder, der er integreret på NFV-platformen. Udformningen af 5TONIC NFV-økosystemet er udført i forbindelse med H2020 5GINFIRE-projektet^7,8, hvor platformen blev brugt til at understøtte udførelsen af mere end 25 eksperimenter, udvalgt gennem en konkurrencedygtig open-call-proces, på tværs af otte vertikale specifikke eksperimentelle infrastrukturer beliggende i Europa og en i Brasilien, sidstnævnte forbundet via en transoceanisk forbindelse. Derudover blev platformen udnyttet til at bygge et distribueret NFV-testbed på nationalt plan i Spanien, der støttede forsøgsaktiviteter inden for det spanske 5GCity-projekt^9,10. For nylig er et yderligere brasiliansk websted blevet integreret i platformen for at støtte fælles demonstrationsaktiviteter i forbindelse med et forsknings- og innovationssamarbejde mellem Brasilien og Europa (dvs. 5GRANGE-projektet^11,12). Sidst, men ikke mindst, er infrastrukturen blevet anvendt til at støtte tredjepartsforsøg inden for rammerne af 5G-VINNI-projekt^13,14. Den geografiske fordeling af NFV-platformen kan ses i figur 1.

Interesserede organisationer, der er vært for deres egen NFV-infrastruktur, kan fleksibelt oprette forbindelse til 5TONIC NFV-økosystemet, med forbehold for godkendelse fra 5TONIC Steering Board, blive testbed-udbydere inden for det distribuerede økosystem og være involveret i fælles eksperimenter og demonstrationsaktiviteter. Til dette formål skal de have en VIM (Virtual Infrastructure Manager), der er kompatibel med OSM-softwarestakken. 5TONIC NFV-orkesteratoren er i stand til at interagere med VIMs på de steder, der er involveret i en given serviceudrulning, koordinere fordelingen og opsætningen af de computer-, lagrings- og netværksressourcer, der er nødvendige for instantiering og sammenkobling af VNF'erne, der udgør en netværkstjeneste, og kontrollere dens livscyklus fra dens om bord til den endelige nedlukning.

For at styre udvekslingen af kontrol- og datatrafik inden for alle de sammenkoblede websteder gør 5TONIC NFV-økosystemet brug af en overlay-netværksarkitektur baseret på VPN (Virtual Private Networks). Denne tilgang giver sikker PKI-baseret adgang til de eksterne websteder, der er integreret i 5TONIC-økosystemet, hvilket gør det muligt at udveksle NFV-kontroloplysninger mellem OSM-softwarestakken og de forskellige VIMs, der er fordelt på testbedene, samt udveksling af oplysninger, der er nødvendige for at administrere og konfigurere alle VNF'er. Desuden understøtter dette overlejringsnetværk udbredelsen af datatrafik mellem VNF'er, der anvendes på forskellige steder.

I den forbindelse beskriver dette dokument den protokol, der er designet til at inkorporere et eksternt websted i et NFV-økosystem. Protokollen antager, at økosystemet styres af en enkelt NFV orchestrator, installeret på et centralt sted, og eksterne websteder har en VIM-løsning, der er kompatibel med orkestersoftwarestakken. Den foreslåede protokol gør det muligt at øge porteføljen af ressourcer i det eksperimentelle økosystem med fleksibel inkorporering af NFV-lokaliteter og vertikale infrastruktur. Dette gør det muligt at oprette en distribueret MANO-platform, der er i stand til at teste og validere nye netværk og vertikale tjenester på tværs af flere steder under kontrol af en enkelt NFV-orkestertor. For at illustrere protokollens indre funktion vil processen blive eksemplificeret ved at tilføje et eksternt NFV-websted til det nuværende 5TONIC NFV-økosystem, der beskriver de nødvendige komponenter på det eksterne sted og 5TONIC samt alle de skridt, der skal tages under integrationsprocessen. Figur 2 giver et overblik over formålet med integrationen, hvor den nye NFV-baserede testbed er knyttet til 5TONIC-platformen, hvorfra netværkstjenester kan implementeres, ved hjælp af VPN-forbindelser mellem det centrale sted og resten af de eksterne infrastrukturer.

For at fremvise protokollens effektivitet vil der desuden blive vist indsættelse af en simpel vertikal tjeneste ved hjælp af 5TONIC-økosystemet og et eksternt sted med NFV-kompatible små ubemandede luftfartøjer (SUAV'er). Udformningen af den vertikale service er inspireret af et eksperiment præsenteret i Vidal et al.⁹, som er blevet forenklet til illustrationsformål af dette papir. Figur 3 skitserer tjenesten, der har til formål at støtte intelligente landbrugsaktiviteter på et fjerntliggende område. Tjenesten betragter en smart landbrugstjenesteudbyder, der bruger SUAVs til at indsamle og formidle de data, der produceres af meteorologiske sensorer spredt over et afgrødefelt. For nemheds skyld betragter eksperimentet, der præsenteres i papiret, en enkelt SUAV og en sensor, der er i stand til at levere temperatur- og fugtigheds- og trykmålinger. I eksperimentet er det eksterne NFV-websted vært for et Wi-Fi-adgangspunkt, der er installeret som VNF over SUAV' en. Denne VNF tilbyder netværksadgangsforbindelse til sensoren og videresender de sanse data mod en gatewayfunktion. Sidstnævnte er indsat som en VNF på et jordudstyr (en mini-ITX computer). Formidlingen af data fra sensoren til gatewayfunktionen følger en Publicer/Abonner-tilgang baseret på MQTT-protokol (Message Queuing Telemetri Transport)¹⁵. Gateway-funktionen behandler og formidler derefter dataene til en Internet-of-things (IoT)-server, som stilles til rådighed som VNF på det centrale sted for NFV-økosystemet baseret på Mainflux¹⁶ open source-platformen. Endelig forudsætter scenariet et fjernområde, hvor internetforbindelsen leveres af et mobilt ikke-3GPP-adgangsnetværk. Tjenesten omfatter derfor yderligere to VNF'er: 1) en adgangsrouter VNF, som implementerer brugerplanprotokolstakken på et 3GPP-brugerudstyr, der er tilsluttet et ikke-3GPP-adgangsnetværk¹⁷; og 2) en baseline implementering af et 5G-kernenetværk, der understøtter videresendelse af oplysninger mellem adgangsrouteren og IoT-serverens VNF'er. Til dette formål giver 5G-kernen VNF en forenklet implementering af brugerplanet for en ikke-3GPP-interworking-funktion og en brugerplanfunktion som defineret af 3GPP¹⁷.

Endelig repræsenterer figur 4 de mest relevante processer, der er involveret i forbindelse med udviklingen af protokollen, og fremhæver deres logiske sammenkoblinger og de enheder, der er ansvarlige for deres gennemførelse.

Protocol

1. Levering af det centrale område for NFV-økosystemet (eksperimentets forudsætninger)

1. Fordel et IP-adresseområde, der skal bruges af det centrale websted. I forbindelse med denne protokol anvendes den private adresseplads 10.4.0.0/16.
2. Installer MANO-softwarestakken (Management and Orchestration) på det centrale websted. Især det eksperiment, der udføres i hele denne protokol, bruger Open Source MANO (OSM) Release SEVEN¹⁸, som kræver følgende ressourcer: Ubuntu 18.04 som operativsystem, 2 CPU'er (Central Processing Units), 8 GB RAM (Random-Access Memory), 40 GB harddisk-disk og mindst én netværksgrænseflade med internetadgang. I installationen skal du følge vejledningen i dokumentationen til OSM Release SEVEN¹⁸.
3. Konfigurer en VIRTUEL INFRASTRUKTURSTYRING (VIM), der er kompatibel med OSM på det centrale websted. Specifikt, eksperimentet bruger OpenStack udgivelse Ocata²⁰, kører på en Virtual Machine (VM) med Ubuntu 16,04 , 4 CPU'er, 16 GB RAM og 200 GB harddisk. NFV Infrastructure (NFVI), der håndteres af denne VIM, består af tre servercomputere, hver med Ubuntu 16.04, 8 CPU'er, 32 GB RAM og 2 TB lagerplads. I 21 finder du i installationen i ocata-udgivelsesdokumentationen²¹.
   1. Implementer et virtuelt netværk i OpenStack-skyplatformen ved hjælp af et IP-adresseområde fra den adresseplads, der blev allokeret i trin 1.1. Dette netværk, der fremover omtales som forvaltningsnetværk, vil blive anvendt til at støtte udvekslingen af NFV-orkestreringsoplysninger mellem OSM og VNF'er (Virtual Network Functions), der instantieres på det centrale websted.
   2. Konfigurer et virtuelt netværk (fremover denomineret som datanetværk) til understøttelse af datakommunikation mellem websteder mellem VNF'erne på det centrale websted og andre VNF'er, der udføres på eksterne websteder. Til dette formål skal du bruge et IP-adresseområde fra adresseområdet i trin 1.1.
      BEMÆRK: Implementeringen af de netværk, der er nævnt i trin 1.3.1 og 1.3.2, er sket ved hjælp af udbydernetværk af OpenStack. Udbydernettene skal være tilsluttet den fysiske netinfrastruktur på det centrale område for at sikre en passende drift.
4. Tilslut både virtuelle private netværk (dvs. administrationen og datanetværkene) samt VIM- og OSM-maskinerne til et udstyr, der leverer edge routing-funktionaliteter. Denne router vil tjene som indgang til det centrale sted for NFV økosystemet.
5. Stille et offentligt eksperimentlager til rådighed for at levere alt det indhold, der er nødvendigt for at udføre eksperimentet. Denne protokol bruger især det offentlige lager som²²- et .

2. Konfiguration af den virtuelle private netværkstjeneste

1. Tildele en IP-adresseplads til at understøtte en hensigtsmæssig drift af økosystemet med flere websteder, så netværkskommunikation effektivt kan etableres mellem flere steder.
   BEMÆRK: Aktivering af effektiv netværkskommunikation mellem flere websteder kræver et omhyggeligt design af IP-adresseområdet, der skal bruges af NFV-økosystemet, samt af eksterne websteder, der har brug for at oprette forbindelse til det. Navnlig bør den adresseplads, der er afsat til kommunikation mellem websteder, ikke kollidere med det adresserum, der allerede er i brug på alle andre steder til andre formål.
   1. Allokere et IP-adresseområde, der skal bruges af eksterne websteder. Adresser i denne blok tildeles NFV-objekter (f.eks. Hvis du vil eksemplificere denne protokol, bruges det private adresseområde 10.154.0.0/16.
   2. Allokere et IP-adresseområde til de virtuelle forbindelser mellem de eksterne websteder og NFV-økosystemet. Disse virtuelle links understøttes af en VPN-tjeneste. Hvis du vil eksemplificere denne protokol, vil adresseområdet 10.154.254.0/24 blive brugt til disse virtuelle links.
2. Konfigurer et udstyr til at levere VPN-tjenesten (Virtual Private Network) (dvs. en VPN-server). Især bruger eksperimentet en servercomputer med Ubuntu 16.04 (64-bit variantbillede), seks uafhængige CPU'er, 16 GB RAM, 1 TB lagerdisk og to netværksgrænseflader.
   1. Konfigurer en af VPN-serverens netværksgrænseflader, så der kan modtages forbindelsesanmodninger fra eksterne websteder via internettet. Med henblik herpå er det nødvendigt at bruge en grænseflade på serveren, der er konfigureret med en offentlig IP-adresse.
   2. Konfigurer forbindelsen mellem VPN-serveren og kantrouteren på det centrale websted. I eksperimentet blev dette link tildelt adresseområdet 10.4.255.0/24. Konfigurer passende netværksruter på VPN-serveren, så NFV-økosystemet bliver tilgængeligt fra eksterne websteder, der er forbundet til VPN-tjenesten.
3. Installer VPN open source-softwaren fra OpenVPN^23-projektet til VPN-serveren. Specifikt bruger dette eksperiment OpenVPN version 2.3.10, og dets implementering blev udført med bash scriptet "openvpn-install.sh", tilgængelig på http://github.com/Nyr/openvpn-install (andre installationsmuligheder er beskrevet i OpenVPN dokumentation²⁴). Bash-scriptet præsenterer de alternative parametre, der vil resultere i konfigurationen af VPN-tjenesten.
   1. Vælg IP-adressen for at lytte til VPN-forbindelsesanmodninger (dvs. den offentlige IP-adresse).
   2. Beslut, hvilken protokol (UDP eller TCP) der skal bruges til at drive kommunikationen over VPN'en. I dette tilfælde udnytter eksperimentet på UDP, der er den anbefalede protokol.
   3. Angiv den port, der skal omfatte duple (sammen med den offentlige IP-adresse), der skal bruges til at modtage serviceforbindelsesanmodningerne. Den tildelte værdi er som standard 1194.
   4. Vælg en af DNS-serverne på listen, der er bedt om af den assistent, der skal håndtere de anmodninger om navnefortolkning, der udføres af VPN-tjenestens klienter.
   5. Tryk på en vilkårlig tast for at aktivere den automatiske start af VPN-tjenestens installationsproces.
4. Rediger konfigurationsfilen "server.conf", der er placeret under mappen "/etc/openvpn/server/" og medtag "klient-til-klient"-direktivet, der har til formål at udvide den grundlæggende opsætning, der leveres af trin 2.3. Således vil forskellige klienter, der er forbundet til VPN-tjenesten, være i stand til at nå hinanden.
5. Aktiver den individuelle klientkonfiguration i VPN-opsætningen for at kunne administrere routingtildelingerne for hver klient uafhængigt.
   1. Tilføj direktivet "client-config-dir ccd" og redigering af den samme konfigurationsfil som i trin 2.4.
   2. Opret mappen "ccd" ved hjælp af kommandoen "mkdir /etc/openvpn/ccd/". Denne mappe vil tjene i løbet af næste afsnit af protokollen til at placere de filer, der omfatter routing direktiver, der er knyttet til de kunder, der er beregnet til at blive integreret i platformen.
6. Konfigurer de firewallregler, der er nødvendige for at tillade forbindelserne med tjenesten, samtidig med at VPN-serveren beskyttes mod ondsindede angreb. Med henblik herpå udnytter dette eksperiment iptables²⁵, som er et kommandolinjeværktøj udviklet til at konfigurere Linux-kernefirewall.
   1. Først blokere indgående trafik til VPN-serveren med kommandoen "iptables -P INPUT DROP".
   2. Tillad modtagelse af VPN-forbindelsesanmodninger med kommandoerne "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( er navnet på VPN-servergrænsefladen med den offentlige IP-adresse) og "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Tillad trafikoverførsel mellem VPN-servergrænsefladerne (dvs. den offentlige grænseflade og den virtuelle grænseflade, der er oprettet af VPN-tjenesten kaldet tun0), for at gøre det muligt for VPN-serveren at behandle anmodningen om tjenesteforbindelse. Til dette formål skal kommandoen "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".
   4. Gør det muligt for VPN-serveren at levere NAT-funktionen (Network Address Translation) med det formål at levere internetadgang til det centrale websted, og udføre: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integration af et eksternt NFV-websted

1. Få et passende IP-adresseområde til at integrere webstedet i NFV-økosystemet. Dette adresseområde vil blive leveret af netværksoperationscentret i NFV-økosystemet. Ifølge trin 2.1.1 i denne protokol vil eksperimentet bruge en række IP-adresser til det eksterne websted inden for 10.154.0.0/16.
2. Opret og angiv sikkerhedslegitimationsoplysninger for at oprette forbindelse til NFV-økosystemet.
   1. Generer en VPN-legitimationsoplysninger, der gør det muligt for den nye infrastruktur at etablere en sikker forbindelse med VPN-serveren. Til dette formål skal du udføre kommandoen "bash openvpn-install.sh" på VPN-serveren, vælge indstillingen "1) Tilføj en ny klient" på den bedt omliste og angive det navn, der skal knyttes til denne legitimationsoplysninger, f.eks. uc3m_infrastructure. Dette trin vil generere en fil med VPN-legitimationsoplysninger (kaldet "uc3m_infrastructure.ovpn" i eksemplet).
   2. Opret en tekstfil i "/etc/openvpn/ccd/" på VPN-serveren, herunder routingdirektiverne (som angivet i OpenVPN-dokumentationen ^24),der skal skubbes af VPN-serveren, hver gang der oprettes forbindelse til VPN-tjenesten ved hjælp af VPN-legitimationsoplysningerne.
      BEMÆRK: Navnet på tekstfilen skal svare til det navn, der er angivet under oprettelsen af VPN-legitimationsoplysningerne (f.eks. uc3m_infrastructure) for at give en tilpasset konfiguration for hver VPN-klient.
   3. Angiv VPN-legitimationsfilen til det tekniske personale på det eksterne websted. Dette skal ske gennem en sikker og pålidelig kanal. I dette eksperiment bruges en manuel krypteringsproces. Hvis du vil kryptere VPN-legitimationsoplysningerne, skal du udføre kommandoen "7za a -tzip '-p' -mem=AES256 ", indstilling som den ønskede krypteringsnøgle, som det valgte navn på den krypterede fil og som filnavnet på VPN-legitimationsfilen (f.eks. uc3m_infrastructure.ovpn).
   4. Giv de krypterede legitimationsoplysninger til det tekniske personale på det nye websted sammen med den nøgle, der tillader dekrypteringsprocedurerne, via en sikker kommunikationskanal.
      BEMÆRK: I dette eksperiment blev de krypterede legitimationsoplysninger leveret via elektronisk e-mail, mens dekrypteringsnøglen blev sendt via en separat kanal ved hjælp af sms'en (Short Message Service) med en offlineaftale på telefonnummeret.
3. Konfigurer miljøet på det nye sted for at etablere forbindelsen til NFV-økosystemet og gøre det muligt at fastgøre den eksterne NFVI til OSM-stakken på det centrale sted.
   1. Installer VPN-softwaren fra OpenVPN²⁴ i en computer for at muliggøre et virtuelt link mellem det eksterne websted og det centrale sted for NFV-økosystemet. Computeren med OpenVPN-softwaren vil fungere som en VPN-klient eller VPN-slutpunkt på det eksterne site. Det virtuelle link vil blive realiseret ved hjælp af en beskyttet VPN-tunnel mellem VPN-slutpunktet og VPN-serveren. I eksperimentet kører VPN-slutpunktet i en servercomputer med Ubuntu 18.04, 8 CPU'er, 8 GB RAM, 128 GB lagerdisk og 3 GbE-grænseflader (en til tilslutning til VPN-tjenesten via internettet).
   2. Aktiver IP-videresendelse i VPN-slutpunktet for at understøtte netværksrutefunktioner. Med henblik herpå skal du medtage linjen "net.ipv4.ip_forward=1" i systemkonfigurationsfilen, der er placeret i stien "/etc/sysctl.conf", og indlæse den opdaterede konfiguration med kommandoen "sudo sysctl -p".
   3. Dekryptere VPN-legitimationsfilen med de oplysninger, der modtages i trin 3.2.4, ved hjælp af kommandoen "7za e ", hvor er filnavnet på den krypterede VPN-legitimationsoplysninger. Angiv dekrypteringsnøglen, når kommandoen bliver bedt om det.
   4. Start OpenVPN-softwaren med den dekrypterede legitimationsoplysninger fil ved hjælp af kommandoen "sudo openvpn --config " ( er filnavnet på VPN legitimationsoplysninger). Med dette vil VPN-slutpunktet godkende VPN-serveren og vil automatisk modtage passende VPN-konfigurationsparametre og netværksruter. På denne måde vil VPN-slutpunktet fungere som en kantrouter med et virtuelt link til det centrale sted for NFV-økosystemet.
   5. Kontroller, at VPN-slutpunktet fungerer korrekt, ved hjælp af kommandoen ping til at kontrollere tilgængeligheden af tilslutningsmuligheder til en af noderne på det centrale websted (f.eks. OSM-stakudstyret).
   6. På det nye websted skal du vælge en OSM-kompatibel VIM for at tillade operationer med MANO-platformen. Til dette eksperiment bruges OpenStack-udgivelse Ocata.
      BEMÆRK: OSM Release SEVEN understøtter følgende virtuelle infrastrukturadministratorer: OpenStack, OpenVIM²⁶, VMwares vCloud Director²⁷, Amazon Web Service²⁸, Microsoft Azure²⁹og Eclipse fog05³⁰ (se OSM dokumentation¹⁸ for specifikke konfigurationsoplysninger).
   7. Installer OpenStack-udgivelsen Ocata²⁰ (se de detaljerede procedurer i udgivelsesdokumentationen²¹).
   8. Installer NFV-infrastrukturen på det eksterne websted, og knyt den til VIM. Dette eksperiment bruger især en NFV-infrastruktur bestående af tre enkeltpladecomputere (SFC'er), der hver har en beregningskapacitet på 1 GB RAM, 4 CPU'er og 32 GB lagerdisk. og en enkelt mini-ITX-computer med 8 CPU'er, 8 GB RAM og 128 GB til opbevaring.
      BEMÆRK: Det eksterne websted, der er eksemplificeret i denne protokol, er baseret på en NFV-infrastruktur af NFV-kompatible små ubemandede luftfartøjer (SUAVs) . De nærmere oplysninger, der følges for at muliggøre en sådan infrastruktur, findes i Nogales et^{al. 31}. Trin 3.3.6 til 3.3.8 er valgfrie, da der muligvis allerede findes en NFV-infrastruktur på det eksterne websted.
   9. Opret et OpenStack-projekt for at angive det sæt beregningsressourcer på det eksterne websted, der integreres i NFV-økosystemet. Det gør du ved at få adgang til den grafiske brugergrænseflade(GUI), der leveres af OpenStack, logge på systemet med administratorlegitimationsoplysningerne, klikke på knappen + Opret projekt under fanen Identitet -> Projekter og oprette et projekt, der udfylder den viste formular med de ønskede oplysninger.
   10. Opret en gyldig bruger, der skal administrere det projekt, der blev oprettet i forrige trin. Til dette formål skal du åbne fanen Identitet -> Brugere med det samme logon som i forrige trin, klikke på + Opret bruger og udfylde de obligatoriske felter i den viste formular (brugernavn og adgangskode), vælge det nyoprettede projekt som det primære projekt og vælge administratorrollen.
   11. Rediger sikkerhedsbestemmelserne, så VNF-kommunikationstilladelser på det nye websted tillades (aktiver især SSH- og ICMP-trafik). Med henblik herpå skal du åbne OpenStack GUI med legitimationsoplysningerne for den bruger, der blev oprettet i forrige trin, følge sekvensen: Project -> Network -> Security Groups -> + Add Ruleog vælge SSH-indstillingen for rullelisten Regel. Gentag processen, men vælg indstillingen Alle ICMP, der er inkluderet i rullemenuen.
   12. Download billederne af en prøveversionstjeneste, der tilbydes af OSM-fællesskabet, Ping Pong-netværkstjeneste ("Fedora-x86_64-20-20131211.1-sda-ping" og "Fedora-x86_64-20-20131211.1-sda-pong") fra det offentlige eksperimentlager, og upload dem til VIM på det eksterne websted. Til dette formål skal du følge sekvensen Project -> Compute -> Images -> + Create Imageog oprette billederne ved hjælp af den viste formular og vælge hvert af billedet.
   13. Tildel to IP-adresseområder inden for adresseområdet på det eksterne websted (tildelt i trin 3.1). Disse intervaller vil blive brugt til at understøtte forvaltningen af VNF'er på det eksterne websted og til at muliggøre henholdsvis datakommunikation mellem websteder blandt VNF'er.
   14. Opret et providernetværk (kontroludbyder) ved hjælp af VIM. Dette netværk understøtter NFV-kommunikation mellem OSM-stakken på det centrale sted og de VNF'er, der er installeret på det nye sted til forvaltningsformål. Denne type kommunikation gør det også muligt for OSM-stakken at konfigurere VNF'er efter installationen. Hvis du vil oprette et providernetværk i OpenStack, skal du følge sekvensen Admin -> System -> Networks -> + Opret netværk og udfylde detaljerne i det nye netværk ved hjælp af det valgte IP-adresseområde i forrige trin.
   15. Opret et andet providernetværk (dataprovider) ved hjælp af VIM. Dette netværk vil understøtte datakommunikation blandt VNF'erne på webstedet og andre VNF'er i NFV-økosystemet. Hvis du vil oprette dette providernetværk i OpenStack, skal du følge sekvensen Admin -> System -> Networks -> + Create Networkog udfylde detaljerne i det nye netværk ved hjælp af det tildelte adresseområde.
       BEMÆRK: Instruktionerne til, hvordan du opretter virtuelle netværk, varierer afhængigt af VIM-softwaren. Se deres respektive softwaredokumentation for detaljer.
   16. Del de VIM-relaterede oplysninger (især brugernavnet/adgangskoden og det projekt, der blev oprettet i trin 3.3.9 og 3.3.10) med det tekniske personale på det centrale websted for at muliggøre fastgørelse af VIM til OSM-softwarestakken.
4. Fastgør den eksterne NFV-infrastruktur til OSM-softwarestakken på det centrale websted ved hjælp af de oplysninger, der er indhentet fra trin 3.3.16.
   1. Kontroller forbindelsen mellem OSM-stakken på det centrale websted og VIM'en på det nye websted ved hjælp af pingværktøjet.
   2. Hvis den tidligere forbindelsestest lykkes, skal du vedhæfte den eksterne VIM til OSM-stakken på det centrale websted. Det kan du gøre ved at bruge følgende kommando i OSM-maskinen: "osm vim-create --name -user --password --auth_url --tenant --account_type ". I denne kommando: er det navn, der er valgt til at identificere VIM i OSM-stakken, er navnet på den bruger, der er autoriseret til at håndtere ressourcerne på det eksterne websted (se trin 3.3.10), er adgangskoden til den angivne bruger, er linket til API stilles til rådighed af VIM at aktivere anmodninger fra OSM stack , er det projektnavn, der er defineret i trin 3.3.9, og er den ANVENDTE VIM-software (i dette eksperiment, OpenStack).
5. Kontroller, at den nye VIM er vedhæftet den nye VIM til NFV-økosystemets OSM-stak.
   1. Udfør kommandoen "ro_id=$(docker ps | grep osm_ro | cut -d ' ' -f 1)" for at identificere id'et for den container, der implementerer RO-modulet (Resource Orchestrator) i OSM-systemet. Dette modul er ansvarligt for at interagere med VIMs med henblik på at koordinere og allokere de nødvendige ressourcer i forbindelse med udrulningen af efterfølgende netværkstjenester.
   2. Få adgang til RO-objektbeholderen ved hjælp af kommandoen "docker exec -it $ro_id bash". Denne kommando bruger det id, der blev opnået i udførelsen af det forrige trin.
   3. Kontroller, at den nye VIM er inkluderet på listen over tilgængelige datacentre ved hjælp af kommandoen "openmano datacenter-list". Det nye websted skal vises på listen med samme navn som det tidligere introducerede i trin 3.4.2 med parameter.
   4. Liste de billeder, der er blevet uploadet til VIM af det eksterne websted, ved hjælp af kommandoen "openmano vim-image-list --datacenter ". parameter angiver det navn, der er valgt til at identificere VIM'en i OSM-stakken. Hvis udførelsen af denne kommando lykkes, er forbindelsen til den eksterne VIM blevet stukket ned. Kontroller, at Ping Pong-billederne er inkluderet på listen.
   5. Liste de netværk, der er tilgængelige på det nye websted med kommandoen "openmano vim-net-list --datacenter ". Kontroller, at kontroludbyderen og dataprovideren findes.
6. Udfør en foreløbig validering af den korrekte integration af det nye websted ved hjælp af en prøvetjeneste, der tilbydes af OSM-fællesskabet (alt indhold i denne henseende er inkluderet i eksperimentlageret). Til dette formål udføres de kommandoer, der er inkluderet i følgende trin, i det udstyr, der er vært for OSM-stakken.
   1. Ombord på VNF-deskriptorerne (VNFD'er) til OSM-stakken, der kører kommandoen "osm vnfd-create " for hver af de VNF'er, der udgør prøveversionen ( svarer til filnavnet på VNFD-pakken).
   2. Ombord på NS-deskriptoren (NSD) for forsøgstjenesten med kommandoen "osm nsd-create ", hvor indikater filnavnet på NSD-pakken (i dette eksperiment ping_pong_ns.tar.gz)."
   3. Start instantieringen af NS (Ping Pong Network Service) på de eksterne og centrale websteder ved hjælp af kommandoen "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }]}'". parameter identificerer VIM af det eksterne websted i OSM stakken. Indstillingen "--config" angiver, at alle de VNF'er, der udgør tjenesten, skal installeres på det eksterne websted, der håndteres af den pågældende VIM, undtagen den VNF, der er identificeret af indeks 2 i NS, og som installeres på det centrale websted (VIM'en på det centrale websted er angivet i parameter).
   4. Kontroller, at NS er blevet installeret, og at dets status er ved hjælp af kommandoen "osm ns-list". Hvis instantiering er vellykket, ændres status til "READY".
   5. Tjek IP-adressen på hver af de to VNF'er med "osm vnf-liste" (nødvendig for at logge ind på maskinerne bagefter).
   6. Opret forbindelse til hver VNF via SSH ved hjælp af kommandoen "ssh fedora@" ( repræsenterer IP-adressen på den VNF, der skal oprettes forbindelse til, og som blev opnået i forrige trin). Introducer adgangskoden "fedora", når du bliver bedt om det af SSH. Når de er logget ind på begge maskiner, skal du kontrollere deres grænseflader ved hjælp af kommandoen "ip address show" og få IP-adresserne på deres grænseflader, der er knyttet til dataudbydernetværket (grænseflade eth1 i begge VNF'er). Fra en af VNF'erne skal du udføre en ping til den anden VNF ved hjælp af fjern-IP-adressen i dataudbydernetværket. Hvis der er forbindelse, betragtes den foreløbige valideringstest som vellykket.

4. Validering af NFV-multistedsplatformen med en realistisk vertikal service

1. Download VNF-billederne fra det offentlige lager, og overfør dem til VIM på deres tilsvarende websted (se figur 3) efter proceduren i trin 3.3.12. Det eksterne websted vil især være vært for Access Point VNF, Router VNF, MQTT Gateway VNF og Access Router VNF. Det centrale websted vil være vært for 5G Core VNF og IoT Server VNF.
2. Ombord på VNFD'erne og NSD for smart farming-tjenesten til OSM-stakken (alle deskriptorer kan downloades fra eksperimentlageret).
   1. Onboard VNFD'erne til OSM-stakken, der udfører kommandoen "osm vnfd-create " for hver af VNF'erne i netværkstjeneste. I dette tilfælde svarer parameteren til filnavnet på VNFD-pakken.
   2. Ombord på NSD til OSM stakken med kommandoen "osm nsd-create ", hvor indikater filnavnet på NSD-pakken (i dette eksperiment jove_uavs_scenario_nsd.tar.gz).
3. Implementer netværkstjeneste til intelligent landbrug. Til dette formål kør følgende kommando fra OSM-kommandolinjegrænsefladen: 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 }'.
   BEMÆRK: Som angivet i trin 3.6.3.angiver og parameters de steder, hvor VNF'erne skal installeres. Især vil alle VNF'er, der udgør smart farming-tjenesten, blive placeret på det nye eksterne websted, bortset fra dem med indeks 5 og 6 (5G Core og IoT-serveren VNF'er),der vil blive tildelt det centrale websted.
4. Kontroller, at NS er installeret efter samme procedure som i trin 3.6.4.
5. Adgang til IoT-serveren VNF med kommandoen "ssh mosquittosubscriber@" og kontroller dens grænseflade konfigureret til at kommunikere med MQTT Gateway VNF via kommandoen "ip address show dev eth1". IP-adressen på VNF () kan fås ved at udføre "osm vnf-listen" i OSM-kommandolinjen.
6. Efter en tilsvarende procedure skal du have adgang til MQTT Gateway VNFog køre kommandoen "sudo python3 publisher_MQTT_GW.py -ma -ba ", hvor opnås i forrige trin, og executing kommandoen "ip address show dev eth1" i MQTT Gateway VNF. Dette trin initialiserer MQTT Gateway VNF, som modtager data, der genereres af sensoren ved hjælp af MQTT standard¹⁵, og overfører disse data til IoT-serveren VNF ved hjælp af samme standard.
7. Forbered en Single Board Computer (SBC), der vedhæfter en meteorologisk sensor, og med transceiverkapacitet til at overføre sensoraflæsninger mod MQTT Gateway VNF.
   BEMÆRK: For at eksemplificere denne protokol er der især anvendt en SBC-model. Derfor kan det være nødvendigt at tilpasse følgende trin i tilfælde af brug af en anden SBC-platform.
   1. Tilslut (f.eks. ved hjælp af tinloddede kobbertråde) sensorens bordstifter til SBC's generelle input/output-stifter (GPIO) efter konfigurationsordningen i figur 5.
   2. Aktiver I2C-kernemodulet i SBC'en for at kunne kontrollere, om sensoren registreres. Til dette formål skal du køre kommandoen "sudo raspi-config", følge sekvensen Interfacing Options -> I2C -> Ja i den viste menu og genstarte SBC for at gøre ændringerne effektive.
   3. Kontroller, at sensoren registreres Installation af softwaren i2c-værktøjer i SBC og udførelse af kommandoen "sudo i2cdetect -y 1". Hvis det er tilfældet, skal der vises et gitter, der angiver den position, hvor sensoren registreres.
   4. Installer de relevante softwarebiblioteker, så SBC'en kan læse og sende de data, som sensoren har leveret. Især dette eksperiment udnytter på RPi.bme280³² og paho-mqtt³³ Python biblioteker.
8. Brug den mobile anvendelse af SUAV,tage ud af det luftfartøj, der er vært for Access Point VNF, og placere det til at give trådløs dækning til SBC med sensoren.
   BEMÆRK: Flyvningen af de NFV-kompatible SAV'er er uafhængig af nettjenestens operationelle adfærd, som er i stand til at betjene, om SUAV'erne flyver eller i en tilstand af hvile for at afbøde batteriforbruget. Således er trin 4.8 valgfrit.
9. Vedhæft den SBC, der har ansvaret for at læse de data, som sensoren har indsamlet, til det trådløse Wi-Fi-adgangspunkt, der leveres af Adgangspunktet VNF). Når en vellykket vedhæftet fil er lykkedes, aktiveres en trådløs netværkssti fra sensoren til MQTT Gateway VNF.
10. Start overførslen af sansede data, kører kommandoen "python3 /home/ubuntu/sensorDataTransmission.py -a " i SBC, der inkorporerer sensoren ( er ip-adressen opnået i trin 4.6.).
11. Få adgang til den web-GUI, der leveres af IoT-serveren VNF, for at kontrollere den korrekte realtidsmodtagelse af de fornemme data. Med henblik herpå skal du kontrollere IP-adressen på IoT Server VNF med kommandoen "osm vnf-list" og skrive følgende URL-adresse (Uniform Resource Locator) i en webbrowser: http://:3001, hvor er IP-adressen på IoT-serveren VNF. Klik derefter på knappen Sensor dataindsamling under fanen Hjem, og kontroller realtidsopdateringen af de grafer, der er inkluderet i dashboardet, når der modtages data.
    BEMÆRK: For at kunne få adgang til den URL-adresse, der er nævnt i trin 4.12, skal enheden med webbrowseren, der forsøger at nå denne ressource, være tilsluttet NFV-økosystemet og have IP-forbindelse til IoT Server VNF. VPN-tjenesten kan også bruges til dette formål.
12. Vent i en passende periode for at opnå repræsentative resultater af udførelsen af smart farming service. Derefter skal du indsamle de data, der er gemt i IoT-serveren VNF, til yderligere analyse. I betragtning af at sensoren, der er inkluderet i dette eksperiment, giver temperatur, fugtighed og trykaflæsninger hvert 5. sekund, kører tjenesten i eksperimentet i en periode på 10 minutter, hvilket resulterer i 180 prøver af sanset data (60 for hver meteorologisk værditype).
13. Få adgang til databasen for IoT Server VNF for at hente de sanse data til yderligere analyse. Til dette formål skal du udføre kommandoen "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1)" på IoT Server VNF, og derefter "sudo docker exec -it $id_database bash"
14. Eksporter dataene til en CSV-fil (semikolonsepareret værdi) og kør kommandoen "tilstrømning -database 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Rediger parameteren for at vælge, hvilken type sansede data der skal eksporteres med "temperatur", "fugtighed" eller "tryk", og angiv parameteren for at vælge et navn til outputfilen, der beholder resultaterne.
15. Gem de datafiler, der blev genereret i forrige trin, til senere repræsentation (se afsnittet Repræsentative resultater) og kontrol af korrekt drift af smart farming-tjenesten.

Representative Results

Efter nøje at have fulgt protokollen for at indarbejde et nyt websted til den centrale platform og køre en netværkstjeneste for at validere dens korrekte funktionalitet, skildrer figur 6 et skærmbillede af open-vpn-monitor-værktøjet. Det kan observeres, hvordan det nye websted bruger VPN'en til al sin kommunikation, der viser, hvordan dets kommunikation følger VPN'en for at tillade denne dataudveksling og dermed den korrekte tilføjelse af det nye websted til VPN-tjenesten.

Som be skildret i figur 3leverer netværktjenesten oplysninger fra en sensor, der er placeret i en fjerninfrastruktur, til serveren på det centrale websted. Derudover viser Figur 7 den vellykkede implementering af netværkstjeneste fra OSM web GUI, der viser, hvordan eksperimentet kan instantieres korrekt i den nye fjerninfrastruktur fra MANO-stakken, der er placeret på det centrale websted. Desuden er den tid, der kræves i eksperimentet for at fuldføre udrulningen af tjenesten, omkring otte minutter. Denne værdi, sammen med den tid, der er nødvendig for at om bord på servicebeskrivelserne i orkestreringsplatformen (ca. 9 sekunder, med 1,3 sekunder pr. deskriptor, i betragtning af både NS og hver VNF-deskriptor), gør det muligt at opfylde KPI 'en (Key Performance Indicator) på 90 minutter for oprettelsestiden for tjenesten, som angivet i 5G Infrastructure Public Private Partnership³⁴. I den forbindelse indeholder arbejdet i Vidal et al.⁹ en tilbundsgående analyse af tjenesteoprettelsestiden med flere steder ved hjælp af den præsenterede protokol.

Figur 8 viser de data, der indsamles fra sensoren, herunder værdierne for henholdsvis fugtighed, temperatur og tryk. Disse eksempler svarer til alle data, der sendes fra sensoren til en fjernserver i 5TONIC, hvor disse værdier gemmes i en database. Alle disse data viser, at platformen er i stand til at implementere praktiske netværkstjenester efter inddragelsen af en ny infrastruktur samt til korrekt at muliggøre kommunikation mellem websteder.

Figur 1: Distribution af VPN-tjenestewebsteder. Distribution af VPN-tjenesten via platformen og deres linkforbindelse (alle passerer gennem 5TONIC). Klik her for at se en større version af dette tal.

Figur 2. Oversigt over platformen og VPN-tjenesten. Denne figur viser alle elementer på platformen: den centrale placering sammen med sin NFV-infrastruktur, VPN-tjenesten og en ny infrastruktur, der er samlet til systemet. Det omfatter også forbindelserne mellem dens elementer. Klik her for at se en større version af dette tal.

Figur 3: Oversigt over netværkstjeneste. Det skildrer de elementer, der er involveret i netværkstjeneste, dens distribution og dens logiske, og netværk, tilslutningsmuligheder. Klik her for at se en større version af dette tal.

Figur 4: Protokolarbejdsgange. Hver kolonne repræsenterer en del af protokollen, hvor hver handling, der udføres, beskrives, dens logiske forbindelse mellem dem og den komponent, der er ansvarlig for dens udførelse. Klik her for at se en større version af dette tal.

Figur 5: Pin-konfigurationsprogram. Diagram, der repræsenterer, hvordan man laver de fysiske forbindelser mellem sensorernes bordstifter og GPIO-stifterne på SBC, der inkorporerer sensoren. Klik her for at se en større version af dette tal.

Figur 6: OpenVPN-skærm snapshot. Billedet viser, at den aggregerede infrastruktur er forbundet til VPN-tjenesten, herunder nogle af dens detaljer om dens forbindelse. Desuden skildrer figuren også yderligere forbindelser, der tilhører andre fjerninfrastrukturer. Klik her for at se en større version af dette tal.

Figur 7: Osm NS-installationsstatus. OSM grafisk grænseflade, der viser den vellykkede implementering af testnetværkstjenesten i fjerninfrastrukturen. Klik her for at se en større version af dette tal.

Figur 8: Repræsentativ analyse af de data, som sensoren har indsamlet. (B) Grafisk gengivelse af de fugtighedsdata, som sensoren har indsamlet hvert femte sekund. (C) Visuel afbildning af de trykdata, som sensoren har indsamlet hvert femte sekund. Klik her for at se en større version af dette tal.

Discussion

Et af de vigtigste aspekter af den tidligere beskrevne protokol er dens enestående fleksibilitet til at indarbejde nye beregningsinfrastrukturer i et NFV-økosystem, uanset deres fordeling med hensyn til geografisk placering (så længe båndbredde og ventetid af netværkskommunikation med fjerntliggende websteder understøtter det). Dette er muligt gennem en VPN-baseret overlejring netværksarkitektur, som gør det muligt at etablere et virtuelt link til at forbinde fjerntliggende steder til de centrale lokaler i NFV økosystemet. Denne tilgang gør det muligt at tilvejebringe en effektiv og sikker kanal til støtte for NFV og datakommunikation mellem steder i et NFV-økosystem, hvilket reducerer sandsynligheden for, at eksterne parter får adgang til og/eller ændrer følsomme oplysninger om NFV-orkestreringsprocesser og data fra udrullede tjenester. I denne sammenhæng beskriver protokollen også en specifik metode til sikkert at dele VPN-legitimationsoplysningerne med de eksterne websteder, der muliggør integration af nye infrastrukturer. Protokollen er blevet eksemplificeret ved hjælp af NFV økosystem stillet til rådighed på 5TONIC af Universidad Carlos III de Madrid, Telefónica, og IMDEA Networks Institute, selv om det er generisk, der skal anvendes i andre NFV miljøer opfylder de tidligere forudsætninger, der er nævnt i trin 1 i denne protokol.

Derudover er det værd at understrege den eksklusive udnyttelse af open source-værktøjer og software til protokolimplementering. På trods af de potentielt gavnlige funktionaliteter, der kunne tilbydes af forskellige proprietære løsninger (f.eks. Fortinet^35),har brugen af open source-udviklinger lettet integrationen af alle elementer, der er omfattet af protokollen på grund af deres iboende egenskaber såsom omkostningseffektivitet, en omfattende softwaresupport fra open source-samfundet og en høj grad af pålidelighed bare for at nævne nogle få af dem. Desuden kan udnyttelsen af open source-teknologier også fremme synergier mellem komponenter af lignende art. For eksempel, for at overvåge VPN-forbindelsesstatus for de klienter, der bruger platformen, kunne VPN-tjenesten implementeret i hele protokollen stole på open-vpn-skærmværktøjet³⁶ (et python-baseret overvågningsværktøj, der er i stand til at fungere sammen med OpenVPN-servere).

På den anden side overvejer protokolspecifikationen instantiering af netværkstjenester på tværs af forskellige websteder til valideringsformål. I den forbindelse er det vigtigt at understrege, at udrulningen af tjenester på et givet websted er betinget af tilgængeligheden af beregnings-, lager- og netværksressourcer på stedet samt af specialiseret udstyr, der kan være nødvendigt for at udføre udrulningen (f.eks. NFV-aktiverede SUAV'er). Dette er ikke en begrænsning af protokollen og bør tages i betragtning af interessenter, der er interesserede i at gengive det eksperiment, der er beskrevet i dette dokument.

Det skal desuden bemærkes, at den tid, det tager at gennemføre udrulningen af nettjenester, i høj grad afhænger af flere faktorer såsom netværksvejen mellem orkesteret og de forskellige VIMs, udførelsen af datakommunikation mellem VIM og dets forvaltede beregningsknudepunkter og også af disse beregningsknudepunkters iboende karakter (ikke kun på grund af deres tilgængelige computerressourcer, men også de teknologier, der er indarbejdet til at udføre virtualisering af netværksfunktioner).

Endelig vil den i betragtning af den fremragende ydeevne, som denne platform og dens VPN-tjeneste havde på de europæiske projekter og samarbejdsværker, hvor den hidtil er blevet anvendt (f.eks. 5GINFIRE, 5GRANGE eller 5GCity, der er nævnt i indførelsen af dette dokument), blive betragtet som et vigtigt element i nye europæiske projekter, hvor Universidad Carlos III de Madrid, Telefónica og IMDEA Networks Institute deltager, såsom Horizon 2020 LABYRINTH, eller nationale projekter som TRUE-5G.

Materials

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/