Integrering av 5G-experimentinfrastrukturer i ett NFV-ekosystem med flera platser

Summary

Syftet med det beskrivna protokollet är att stödja flexibel integrering av 5G-experimentinfrastrukturer i ett NFV-ekosystem med flera platser, genom en VPN-baserad överlagringsnätverksarkitektur. Dessutom definieras i protokollet hur integrationens effektivitet ska valideras, inklusive en vertikal servicedistribution med vertikala servicetjänster med NFV-kapabla små luftfarkoster.

Abstract

Network Function Virtualization (NFV) har betraktats som en av de viktigaste möjliggörarna för den^{5: e} generationen av mobilnät, eller 5G. Detta paradigm gör det möjligt att minska beroendet av specialiserad hårdvara för att distribuera telekommunikation och vertikala tjänster. För detta ändamål förlitar den sig på virtualiseringstekniker för att mjuka upp nätverksfunktioner, förenkla deras utveckling och minska distributionstiden och kostnaderna. I detta sammanhang har Universidad Carlos III de Madrid, Telefónica och IMDEA Networks Institute utvecklat ett NFV-ekosystem inom 5TONIC, ett innovationscenter för öppet nätverk med fokus på 5G-teknik, vilket gör det möjligt att skapa komplexa experimentscenarier nära verkligheten över en distribuerad uppsättning NFV-infrastrukturer, som kan göras tillgängliga av intressenter på olika geografiska platser. I den här artikeln presenteras protokollet som har definierats för att införliva nya NFV-fjärrplatser i NFV-ekosystemet med flera platser baserat på 5TONIC, som beskriver kraven för både befintliga och nyligen införlivade infrastrukturer, deras anslutning genom en övergripande nätverksarkitektur och de steg som krävs för att inkludera nya platser. Protokollet exemplifieras genom införlivandet av en extern plats i 5TONIC NFV-ekosystemet. Efteråt beskriver protokollet de verifieringssteg som krävs för att validera en lyckad webbplatsintegration. Dessa inkluderar utbyggnad av en vertikal tjänst med flera platser med hjälp av en fjärrinfrastruktur för NFV med små obemannade luftfarkoster (SUV). Detta tjänar till att visa upp protokollets potential för att aktivera distribuerade experiment scenarier.

Introduction

Införandet av den femte generationens mobilnät (5G) har inneburit en revolution av telekommunikationsindustrin sedan början av decenniet, vilket kräver att telekommunikationsoperatörerna tar itu med de mycket mer krävande specifikationerna för de nya nätverkstjänster och applikationer som utvecklats under 5G-paraplyet^1,2 . Dessa nya specifikationer inkluderar, men är inte begränsade till, datahastighetsökningar, förbättringar av svarstiden för trådlös överföring och minskning av driftskostnaderna. Bland de tekniker som utgör grunden för förbättringarna för denna nya generation har Network Functions Virtualization³ (NFV) blivit en av dess viktigaste möjliggörare. NFV ger kapacitet att mjukgöra nätverksfunktioner, traditionellt vidarebefordra på specialiserad maskinvara, genom att använda fysisk utrustning för generiskt syfte i stället, till exempel serverdatorer i ett datacenter. Med detta nya paradigm kan telekommunikationsoperatörer och vertikala industrier distribuera nätverksfunktioner och tjänster som en uppsättning programvarukomponenter och spara kostnader i både driftsättning och underhåll av tjänster, samt underlätta en mycket högre nätverksinfrastrukturelasticitet. Den här metoden lindrar eller eliminerar behovet av att använda dedikerade (och vanligtvis mer komplexa och mindre återanvändbara) enheter för de flesta nätverks- och vertikalspecifika funktioner och stöder en mycket högre och tätare grad av operativ automatisering, vilket minskar driftsättnings- och underhållskostnaderna.

Med tanke på alla fördelar som en NFV-miljö kan ge är det naturligt att ett stort antal relevanta intressenter från telekommunikationssektorn i allt högre grad har varit involverade i att testa nya tjänsteidéer om NFV-miljöer. I detta sammanhang har Telefónica och IMDEA Networks Institute skapat 5TONIC⁴, ett öppet forsknings- och innovationslaboratorium med fokus på 5G-teknik. Baserat i Madrid (Spanien) har detta laboratorium ett brett utbud av teknik tillgänglig för forskare och partners för att öka utvecklingen och valideringen av 5G-tjänster. I synnerhet har detta laboratorium en experimentell NFV-plattform där utvecklare kan distribuera och testa sina nya NFV-baserade applikationer och tjänster över på ett ETSI-kompatibelt NFV-ekosystem⁵. Experimentella slutsatser om designval och teknikförslag kan därför härledas i en realistisk mycket mer flexibel miljö än produktionsnätverk. Den här plattformen har utformats för att stödja experiment aktiviteter på flera externa platser, som kan vara flexibelt sammankopplade med 5TONIC med hjälp av ett väldefinierat protokoll.

Den tekniska lösningen som antagits för 5TONIC NFV-ekosystemet beaktar användningen av en enda NFV-orchestrator, implementerad med hjälp av ETSI-värd Open Source MANO (OSM) programvara⁶. Detta är den del som ansvarar för att hantera och samordna livscykeln för nätverkstjänster (NS). Dessa tjänster kan byggas som en sammansättning av virtualiserade nätverks-/vertikala funktioner (VNF), som kan distribueras på någon av de platser som är integrerade på NFV-plattformen. Utformningen av 5TONIC NFV-ekosystemet har gjorts inom ramen för H2020 5GINFIRE-projektet^7,8, där plattformen användes för att stödja genomförandet av mer än 25 experiment, utvalda genom en konkurrenskraftig öppen samtalsprocess, över åtta vertikala specifika experimentella infrastrukturer i Europa och en i Brasilien, den senare ansluten via en transoceanisk länk. Dessutom utnyttjades plattformen för att bygga en distribuerad NFV-testbädd på nationell nivå, i Spanien, som stöder experimentaktiviteter inom det spanska 5GCity-projektet^9,10. På senare tid har ytterligare en brasiliansk webbplats integrerats i plattformen för att stödja gemensamma demonstrationsåtgärder inom ramen för ett forsknings- och innovationssamarbete som upprättats mellan Brasilien och Europa (dvs. 5GRANGE-projektet^11,12). Sist men inte minst har infrastrukturen använts för att stödja tredjepartsexperiment inom ramen för 5G-VINNI-projektet^13,14. Den geografiska fördelningen av NFV-plattformen kan ses i figur 1.

Intresserade organisationer som är värdar för sin egen NFV-infrastruktur kan flexibelt ansluta sig till 5TONIC NFV-ekosystemet, under förutsättning att 5TONIC Steering Board godkänner, blir testbäddsleverantörer inom det distribuerade ekosystemet och deltar i gemensamma experiment- och demonstrationsverksamheter. För detta ändamål måste de ha en VIM (Virtual Infrastructure Manager) som är kompatibel med OSM-programvarustacken. 5TONIC NFV orchestrator kan interagera med VIM:erna på de platser som är involverade i en viss tjänstdistribution, samordna tilldelningen och installationen av de dator-, lagrings- och nätverksresurser som behövs för instansiering och sammankoppling av de virtuella nätverk som utgör en nätverkstjänst och kontrollera dess livscykel, från dess ombordstigning till dess slutliga avveckling.

För att hantera utbytet av kontroll och datatrafik inom alla sammankopplade platser använder 5TONIC NFV-ekosystemet en överlagringsnätverksarkitektur baserad på Virtuella privata nätverk (VPN). Den här metoden ger säker PKI-baserad åtkomst till de externa platser som är integrerade i 5TONIC-ekosystemet, vilket möjliggör utbyte av NFV-kontrollinformation mellan OSM-programvarustacken och de olika VIMs som distribueras över testbäddarna, samt utbyte av information som krävs för att hantera och konfigurera alla virtuella nätverk. Dessutom stöder detta överläggsnätverk spridning av datatrafik mellan virtuella referensnätverk som distribueras på olika platser.

I detta sammanhang beskriver detta dokument protokollet som är utformat för att införliva en extern plats i ett NFV-ekosystem. Protokollet förutsätter att ekosystemet styrs av en enda NFV orchestrator, installerad på en central plats, och externa platser har en VIM-lösning som är kompatibel med orchestrator-programvarustacken. Det föreslagna protokollet gör det möjligt att öka portföljen av resurser i det experimentella ekosystemet, med flexibel integrering av NFV-anläggningar och vertikalspecifik infrastruktur. Detta gör det möjligt att skapa en distribuerad MANO-plattform som kan testa och validera nya nätverk och vertikala tjänster på flera platser, under kontroll av en enda NFV-orchestrator. För att illustrera protokollets inre funktion kommer processen att exemplifieras genom att lägga till en extern NFV-plats till det nuvarande 5TONIC NFV-ekosystemet, som beskriver de nödvändiga komponenterna på den externa platsen och 5TONIC, samt alla steg som ska vidtas under integrationsprocessen. Figur 2 ger en översikt över målet med integrationen, med den nya NFV-baserade testbädden kopplad till 5TONIC-plattformen varifrån nätverkstjänster kan distribueras, genom VPN-anslutningar mellan den centrala platsen och resten av den externa infrastrukturen.

För att visa protokollets effektivitet kommer dessutom införandet av en enkel vertikal tjänst att visas med hjälp av 5TONIC-ekosystemet och en extern plats med NFV-kapabla små obemannade luftfarkoster (SUV). Utformningen av den vertikala tjänsten har inspirerats av ett experiment som presenteras i Vidal et al.⁹, som har förenklats för illustrationsändamålen i detta dokument. I figur 3 beskrivs tjänsten, som syftar till att stödja smart jordbruksverksamhet i ett avlägset område. Tjänsten betraktar en smart leverantör av jordbrukstjänster som använder stadsjeepar för att samla in och sprida data som produceras av meteorologiska sensorer spridda över ett odlingsfält. För enkelhetens skull tar experimentet som presenteras i papperet hänsyn till en enda SUAV och en sensor, som kan ge temperatur-, fuktighets- och tryckmätningar. I experimentet är den externa NFV-platsen värd för en Wi-Fi-åtkomstpunkt som distribueras som VNF över SUAV. Denna VNF erbjuder nätverksåtkomstanslutning till sensorn och vidarebefordrar de avkännade data mot en gateway-funktion. Den senare distribueras som en VNF på en markutrustning (en mini-ITX-dator). Spridningen av data från sensorn till gatewayfunktionen följer en publicerings-/prenumerationsmetod baserad på MQTT-protokollet (Message Queuing Telemetry Transport)^{nr 15}. Gateway-funktionen bearbetar och sprider sedan data mot en IoT-server (Internet-of-Things), som görs tillgänglig som en VNF på den centrala platsen för NFV-ekosystemet, baserat på Mainflux¹⁶ öppen källkodsplattform. Slutligen förutsätter scenariot ett avlägset område där Internetanslutning tillhandahålls av ett mobilt icke-3GPP-åtkomstnätverk. Därför innehåller tjänsten ytterligare två virtuella nr:er: 1) en VNF-åtkomstrouter, som implementerar protokollstacken för användarplan för en 3GPP-användarutrustning ansluten till ett icke-3GPP-åtkomstnätverk¹⁷; och 2) En baslinjeimplementering av ett 5G-stomnät som stöder vidarebefordran av information mellan åtkomstroutern och virtuella IoT-server-nätverk. I detta syfte tillhandahåller VNF-kärnan i 5G-kärnan en förenklad implementering av användarplanet för en icke-3GPP-interworking-funktion och en användarplanfunktion, enligt definitionen i 3GPP¹⁷.

Slutligen representerar figur 4 de mest relevanta processerna under utarbetandet av protokollet och belyser deras logiska sammanlänkningar och de enheter som ansvarar för deras genomförande.

Protocol

1. Tillhandahållande av den centrala platsen för NFV-ekosystemet (tidigare nödvändiga nödvändiga resultat för försöket)

1. Allokera ett IP-adressutrymme som ska användas av den centrala platsen. I detta protokoll används det privata adressutrymmet 10.4.0.0/16.
2. Installera programstacken för hantering och orkestrering (MANO) på den centrala platsen. I experimentet som utförs i hela detta protokoll används särskilt OSM (Open Source Mano) Release SEVEN¹⁸, som kräver följande resurser: Ubuntu 18.04 som operativsystem, 2 processorer (Central Processing Units), 8 GB RAM(Random-Access Memory), 40 GB hårddiskdisk och minst ett nätverksgränssnitt med Internet-åtkomst. För installationen, följ instruktionerna i OSM Release SEVEN dokumentation¹⁸.
3. Konfigurera en virtuell infrastrukturhanterare (VIM) som är kompatibel med OSM på den centrala platsen. Experimentet använder specifikt OpenStack-versionen Ocata²⁰, som körs på en virtuell dator (VM) med Ubuntu 16.04 , 4 PROCESSORER, 16 GB RAM och 200 GB hårddisk. NFV-infrastrukturen (NFVI) som hanteras av denna VIM består av tre serverdatorer, var och en med Ubuntu 16.04, 8 processorer, 32 GB RAM och 2 TB lagring. För installationen, följ Ocata release dokumentation²¹.
   1. Distribuera ett virtuellt nätverk i OpenStack-molnplattformen med hjälp av ett IP-adressintervall från det adressutrymme som allokerades i steg 1.1. Detta nätverk, hädanefter kallat hanteringsnätverk, kommer att användas för att stödja utbytet av NFV-orkestreringsinformation mellan OSM och de virtuella nätverksfunktioner (VNFs) som instansieras på den centrala platsen.
   2. Konfigurera ett virtuellt nätverk (hädanefter denominerat som datanätverk) för att stödja datakommunikation mellan platser, mellan de virtuella nätverken på den centrala platsen och andra virtuella information informationscentraler som körs på externa platser. Använd därför ett IP-adressintervall från adressutrymmet i steg 1.1.
      OBS: Implementeringen av de nätverk som nämns i steg 1.3.1 och 1.3.2 har gjorts med hjälp av leverantörsnätverk för OpenStack. Providernätverk måste vara anslutna till den centrala platsens fysiska nätinfrastruktur för att garantera en lämplig drift.
4. Anslut både virtuella privata nätverk (dvs. hantering och datanätverk), liksom VIM- och OSM-maskinerna, till en utrustning som tillhandahåller kantdirigeringsfunktioner. Denna router kommer att fungera som startpunkt till den centrala platsen för NFV-ekosystemet.
5. Tillgängliggöra en offentlig experimentdatabas för att tillhandahålla allt innehåll som behövs för att utföra experimentet. I detta protokoll används särskilt det offentliga arkivet vid²².

2. Konfiguration av den virtuella privata nätverkstjänsten

1. Allokera ett IP-adressutrymme för att stödja lämplig drift av ekosystemet för flera platser, så att nätverkskommunikation effektivt kan upprättas mellan flera platser.
   OBS: För att möjliggöra effektiv nätverkskommunikation mellan flera platser krävs en noggrann design av IP-adressutrymmet som ska användas av NFV-ekosystemet, liksom av externa webbplatser som behöver ansluta till det. I synnerhet bör det adressutrymme som tilldelats för kommunikation mellan platser inte kollidera med det adressutrymme som redan används på alla andra platser för andra ändamål.
   1. Allokera ett IP-adressutrymme som ska användas av externa webbplatser. Adresser i det här blocket kommer att tilldelas NFV-entiteter (t.ex. VIP-tillverkare) och virtuella ndf:er för den externa webbplatsen. För att exemplifiera det här protokollet används det privata adress utrymmet 10.154.0.0/16.
   2. Allokera ett IP-adressutrymme till de virtuella länkarna mellan de externa platserna och NFV-ekosystemet. Dessa virtuella länkar kommer att stödjas av en VPN-tjänst. För att exemplifiera detta protokoll kommer adressintervallet 10.154.254.0/24 att användas för dessa virtuella länkar.
2. Konfigurera en utrustning för att tillhandahålla VPN-tjänsten (Virtual Private Network) (dvs. en VPN-server). I synnerhet använder experimentet en serverdator med Ubuntu 16.04 (64-bitars variantavbildning), sex oberoende processorer, 16 GB RAM, 1 TB lagringsdiskett och två nätverksgränssnitt.
   1. Konfigurera ett av VPN-serverns nätverksgränssnitt så att anslutningsbegäranden kan ta emot från externa platser via Internet. För detta ändamål är det nödvändigt att använda ett gränssnitt på servern som konfigurerats med en offentlig IP-adress.
   2. Konfigurera länken mellan VPN-servern och edgeroutern på centralplatsen. I experimentet tilldelades denna länk adressintervallet 10.4.255.0/24. Konfigurera lämpliga nätverksvägar på VPN-servern så att NFV-ekosystemet blir tillgängligt från externa platser som är anslutna till VPN-tjänsten.
3. Installera VPN-programvaran med öppen källkod som tillhandahålls av OpenVPN^23-projektet i VPN-servern. Specifikt använder detta experiment OpenVPN version 2.3.10, och dess distribution gjordes med bash-skriptet "openvpn-install.sh", tillgängligt på http://github.com/Nyr/openvpn-install (andra installationsalternativ beskrivs i OpenVPN-dokumentationen ²⁴). Bash-skriptet presenterar de alternativa parametrarna som resulterar i konfigurationen av VPN-tjänsten.
   1. Välj IP-adressen för att lyssna på VPN-anslutningsförfrågningar (dvs. den offentliga IP-adressen).
   2. Bestäm vilket protokoll (UDP eller TCP) som ska användas för att driva kommunikationen över VPN. I det här fallet utnyttjar experimentet UDP som är det rekommenderade protokollet.
   3. Ange den port som ska omfatta duplen (tillsammans med den offentliga IP-adressen) som ska användas för att ta emot begäranden om tjänstanslutning. Som standard är det tilldelade värdet 1194.
   4. Välj en av DNS-servrarna i listan som uppmanas av assistenten och som hanterar de namnmatchningsbegäranden som utförs av VPN-tjänstens klienter.
   5. Tryck på valfri tangent för att aktivera automatisk initiering av INSTALLATIONsprocessen för VPN-tjänster.
4. Redigera konfigurationsfilen "server.conf" som finns under katalogen "/etc/openvpn/server/" och inkludera direktivet "klient-till-klient" som syftar till att utöka den grundläggande installationen som tillhandahålls i steg 2.3. Således kommer olika kunder som är anslutna till VPN-tjänsten att kunna nå varandra.
5. Aktivera den enskilda klient konfigurationen i VPN-installationen för att självständigt kunna hantera routnings tilldelningarna för varje klient.
   1. Lägg till direktivet "client-config-dir ccd" och redigera samma konfigurationsfil som i steg 2.4.
   2. Skapa katalogen "ccd" med kommandot "mkdir /etc/openvpn/ccd/". Den här katalogen kommer att fungera under nästa avsnitt av protokollet för att placera filerna som innehåller de routningsdirektiv som är associerade med de klienter som är avsedda att integreras i plattformen.
6. Ställ in de brandväggsregler som behövs för att tillåta anslutningarna med tjänsten, samtidigt som DU skyddar VPN-servern mot skadlig attack. För detta ändamål utnyttjar detta experiment iptables²⁵, som är ett kommandoradsverktyg som utvecklats för att konfigurera Linux kernel-brandväggen.
   1. Blockera först inkommande trafik till VPN-servern med kommandot "iptables -P INPUT DROP".
   2. Tillåt mottagning av VPN-anslutningsförfrågningar med kommandona "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( är namnet på VPN-servergränssnittet med den offentliga IP-adressen) och "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Tillåt trafik vidarebefordran mellan VPN-servergränssnitten (dvs. det offentliga gränssnittet och det virtuella gränssnittet som skapats av VPN-tjänsten som kallas tun0), för att VPN-servern ska kunna bearbeta begäran om tjänstanslutning. För detta ändamål kör du kommandot "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 möjligt för VPN-servern att tillhandahålla nat-funktionen (Network Address Translation) i syfte att tillhandahålla Internet-åtkomst till den centrala webbplatsen och köra: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integrering av en extern NFV-anläggning

1. Skaffa ett lämpligt IP-adressintervall för att integrera platsen i NFV-ekosystemet. Det här adressintervallet kommer att tillhandahållas av NFV-ekosystemets nätverksoperationscenter. Enligt steg 2.1.1 i detta protokoll kommer experimentet att använda en rad IP-adresser för den externa platsen inom 10.154.0.0/16.
2. Skapa och ange säkerhetsautentiseringsuppgifter för att ansluta till NFV-ekosystemet.
   1. Generera en VPN-autentiseringsuppgift som gör det möjligt för den nya infrastrukturen att upprätta en säker anslutning till VPN-servern. I det här syftet kör du kommandot "bash openvpn-install.sh" på VPN-servern, väljer alternativet "1) Lägg till en ny klient" i den tillfrågade listan och anger namnet som ska associeras med den autentiseringsuppgiften, t.ex. uc3m_infrastructure. Det här steget kommer att generera en fil med VPN-autentiseringsuppgifterna (med namnet "uc3m_infrastructure.ovpn" i exemplet).
   2. Skapa en textfil i "/etc/openvpn/ccd/" katalogen på VPN-servern, inklusive routningsdirektiven (som anges i OpenVPN-dokumentationen ²⁴) som måste skickas av VPN-servern varje gång en anslutning till VPN-tjänsten upprättas med VPN-autentiseringsuppgifter.
      Namnet på textfilen måste matcha det namn som angavs under skapandet av VPN-autentiseringsuppgiften (t.ex. uc3m_infrastructure) för att tillhandahålla en anpassad konfiguration för varje VPN-klient.
   3. Ange VPN-autentiseringsfilen till den tekniska personalen på den externa webbplatsen. Detta måste göras via en säker och pålitlig kanal. I det här experimentet används en manuell krypteringsprocess. Om du vill kryptera VPN-autentiseringsuppgiften kör kommandot "7za a -tzip '-p' -mem=AES256 ", ange är den önskade krypteringsnyckeln, som det valda namnet på den krypterade filen och a filnamnet på DEN >>en kryptografi-fil (e.s. uc3m_infrastructure.ovpn).
   4. Ange den krypterade autentiseringsuppgiften till den tekniska personalen på den nya webbplatsen, tillsammans med nyckeln som tillåter dekrypteringsprocedurerna, via en säker kommunikationskanal.
      I det här experimentet tillhandahölls de krypterade autentiseringsuppgifterna via elektronisk e-post, medan dekrypteringsnyckeln skickades via en separat kanal, med hjälp av sms(short message service), med ett offlineavtal med telefonnumret.
3. Ställ in miljön på den nya platsen för att upprätta anslutningen till NFV-ekosystemet och för att låta fjärr-NFVI anslutas till OSM-stacken på den centrala platsen.
   1. Installera VPN-programvaran som tillhandahålls av OpenVPN²⁴ i en dator för att möjliggöra en virtuell länk mellan den externa webbplatsen och den centrala platsen för NFV-ekosystemet. Datorn med OpenVPN-programvaran kommer att fungera som en VPN-klient eller VPN-slutpunkt på den externa webbplatsen. Den virtuella länken kommer att realiseras med hjälp av en skyddad VPN-tunnel mellan VPN-slutpunkten och VPN-servern. I experimentet körs VPN-slutpunkten i en serverdator med Ubuntu 18.04, 8 processorer, 8 GB RAM, 128 GB lagringsdiskett och 3 GbE-gränssnitt (ett för anslutning till VPN-tjänsten via Internet).
   2. Aktivera IP-vidarebefordran i VPN-slutpunkten för att stödja funktioner för nätverksroutning. I detta syfte inkluderar du raden "net.ipv4.ip_forward=1" i systemkonfigurationsfilen som finns i sökvägen "/etc/sysctl.conf" och läser in den uppdaterade konfigurationen med kommandot "sudo sysctl -p".
   3. Dekryptera VPN-autentiseringsfilen med den information som tas emot i steg 3.2.4 med kommandot "7za e ", där är filnamnet på den krypterade VPN-autentiseringsuppgiften. Ange dekrypteringsnyckeln när kommandot uppmanas.
   4. Starta OpenVPN-programvaran med den dekrypterade autentiseringsfilen med kommandot "sudo openvpn --config " ( är filnamnet på VPN-autentiseringsuppgiften). Med detta autentiseras VPN-slutpunkten till VPN-servern och får automatiskt lämpliga VPN-konfigurationsparametrar och nätverksvägar. På så sätt fungerar VPN-slutpunkten som en edge-router med en virtuell länk till den centrala platsen i NFV-ekosystemet.
   5. Verifiera korrekt drift av VPN-slutpunkten med kommandot ping för att verifiera tillgängligheten för anslutning till en av noderna på den centrala platsen (t.ex. OSM-stackutrustningen).
   6. I den nya webbplatsen väljer du en OSM-kompatibel VIM för att tillåta åtgärder med MANO-plattformen. För det här experimentet används OpenStack release Ocata.
      OSM Release SEVEN stöder följande virtuella infrastrukturhanterare: OpenStack, OpenVIM²⁶, VMwares vCloud Director²⁷, Amazon Web Service^28,Microsoft Azure²⁹och Eclipse fog05³⁰ (se OSM-dokumentation¹⁸ för specifik konfigurationsinformation).
   7. Installera OpenStack release Ocata²⁰ (se de detaljerade procedurerna i versionsdokumentationen²¹).
   8. Distribuera NFV-infrastrukturen på den externa platsen och anslut den till VIM. I det här experimentet används särskilt en NFV-infrastruktur som består av tre datorer med ett enda kort (SBC), var och en med en beräkningskapacitet på 1 GB RAM, 4 processorer och 32 GB lagringsdisk. och en enda mini-ITX-dator med 8 processorer, 8 GB RAM och 128 GB för lagring.
      OBS: Den externa plats som exemplifieras i detta protokoll är baserad på en NFV-infrastruktur av NFV-kapabla små obemannade luftfarkoster (SUV) . De uppgifter som följs för att möjliggöra sådan infrastruktur finns i Nogales et al³¹. Steg 3.3.6 till 3.3.8 är valfria, eftersom det redan kan finnas en NFV-infrastruktur på den externa platsen.
   9. Skapa ett OpenStack-projekt för att ange uppsättningen beräkningsresurser för den externa platsen som ska integreras i NFV-ekosystemet. För att göra det, tillgång till det grafiska användargränssnittet (GUI) som tillhandahålls av OpenStack, logga in på systemet med administratörsautentiseringsuppgifter, klicka på knappen + Skapa projekt på fliken Identitet -> projekt och skapa ett projekt som fyller i det visade formuläret med den begärda informationen.
   10. Skapa en giltig användare som hanterar projektet som skapades i föregående steg. I det här syftet öppnar du fliken Identitet -> Användare med samma inloggning som i föregående steg, klickar på + Skapa användare och fyller i de obligatoriska fälten i det visade formuläret (användarnamn och lösenord), väljer det nyskapade projektet som primärt projekt och väljer administratörsrollen.
   11. Ändra säkerhetsreglerna så att VNF-kommunikationsbehörigheter på den nya platsen kan tillåtas (i synnerhet aktivera SSH- och ICMP-trafik). I detta syfte öppnar du OpenStack-gui:n med autentiseringsuppgifterna för den användare som skapades i föregående steg, följer sekvensen: Project -> Network -> Security Groups -> + Add Ruleoch väljer alternativet SSH i listrutan Regel. Upprepa processen men välj alternativet All ICMP som ingår i den nedrullningsbara menyn.
   12. Ladda ner bilderna på en testtjänst som erbjuds av OSM-communityn, Ping Pong-nätverkstjänsten ("Fedora-x86_64-20-20-20131211.1-sda-ping" och "Fedora-x86_64-20-20131211.1-sda-pong") från det offentliga experimentarkivet och ladda upp dem till VIM på den externa webbplatsen. I det här syftet följer du sekvensen Project -> Compute -> Images -> + Create Imageoch skapar bilderna med det visade formuläret och väljer var och en av bilderna.
   13. Tilldela två IP-adressintervall inom adressutrymmet för den externa platsen (allokerat i steg 3.1). Dessa intervall kommer att användas för att stödja hanteringen av de virtuella GF:erna på den externa webbplatsen och för att möjliggöra datakommunikation mellan virtuella plattformar.
   14. Skapa ett providernätverk(kontrollleverantör)med hjälp av VIM. Det här nätverket kommer att stödja NFV-kommunikation mellan OSM-stacken på den centrala platsen och de virtuella nätverk som distribueras på den nya platsen för hanteringsändamål. Den här typen av kommunikation gör det också möjligt för OSM-stacken att konfigurera virtuella etf:er efter distributionen. Om du vill skapa ett providernätverk i OpenStack följer du sekvensen Admin -> System -> Networks -> + Skapa nätverk och fyller i informationen om det nya nätverket med hjälp av det valda IP-adressintervallet i föregående steg.
   15. Skapa ett andra providernätverk(dataprovider)med hjälp av VIM. Detta nätverk kommer att stödja datakommunikation mellan virtuella nätverk av webbplatsen och andra virtuella nätverk i NFV-ekosystemet. Om du vill skapa det här providernätverket i OpenStack följer du sekvensen Admin -> System -> Networks -> + Skapa nätverkoch fyller i informationen om det nya nätverket med hjälp av det tilldelade adressintervallet.
       Instruktioner om hur du skapar virtuella nätverk varierar beroende på VIM-programvaran. Mer information finns i deras respektive programvarudokumentation.
   16. Dela den VIM-relaterade informationen (i synnerhet användarnamnet/lösenordet och projektet som skapades i stegen 3.3.9 och 3.3.10) med den tekniska personalen på den centrala webbplatsen, för att möjliggöra anslutning av VIM till OSM-programvarustacken.
4. Anslut den externa NFV-infrastrukturen till OSM-programvarustacken på den centrala platsen med hjälp av den information som erhålls från steg 3.3.16.
   1. Verifiera anslutningen mellan OSM-stacken på den centrala platsen och VIM på den nya webbplatsen med hjälp av pingverktyget.
   2. Om det tidigare anslutnings testet lyckas ansluter du den externa VIM till OSM-stacken på den centrala platsen. Det gör du genom att använda följande kommando i OSM-datorn: "osm vim-create --name --user --password ---auth_url --tenant --account_type ". I det här kommandot: är det namn som valts för att identifiera VIM i OSM-stacken, är namnet på den användare som är behörig att hantera resurserna på den externa webbplatsen (se steg 3.3.10), är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är länken till API:et som görs tillgängligt av VIM-användarnamnet>är lösenordet för den angivna användaren, är det projektnamn som definieras i steg 3.3.9 och är den VIM-programvara som används (i det här experimentet, OpenStack).
5. Verifiera lämplig bilaga av den nya VIM till OSM-stacken i NFV-ekosystemet.
   1. Kör kommandot "ro_id=$(docker ps | grep osm_ro | cut -d ' -f 1)" för att identifiera id för behållaren som implementerar modulen Resource Orchestrator (RO) i OSM-systemet. Den här modulen ansvarar för att interagera med VIP-tillverkarna för att samordna och allokera nödvändiga resurser i distributionen av efterföljande nätverkstjänster.
   2. Komma åt RO-behållaren med kommandot "docker exec -it $ro_id bash". Det här kommandot använder den identifierare som erhållits vid körningen av föregående steg.
   3. Kontrollera att den nya VIM ingår i listan över tillgängliga datacenter med kommandot "openmano datacenter-list". Den nya webbplatsen ska visas i listan med samma namn som den tidigare introducerade i steg 3.4.2 med parameter.
   4. Lista de bilder som har laddats upp till VIM på den externa webbplatsen med kommandot "openmano vim-image-list --datacenter ". parameter anger det namn som valts för att identifiera VIM i OSM-stacken. Om körningen av det här kommandot lyckas har anslutningen till den externa VIM:et lyckats stablished. Kontrollera att Ping Pong-bilderna finns med i listan.
   5. Lista de nätverk som är tillgängliga på den nya platsen med kommandot "openmano vim-net-list --datacenter ". Kontrollera att det finns en kontrollleverantör och dataprovider.
6. Utför en preliminär validering av korrekt integrering av den nya webbplatsen med hjälp av en utvärderingstjänst som erbjuds av OSM-communityn (allt innehåll i detta avseende ingår i experimentdatabasen). För detta ändamål kommer kommandona som ingår i följande steg att köras i utrustningen som är värd för OSM-stacken.
   1. Registrera VNF-deskriptorerna (VNFDs) till OSM-stacken som kör kommandot "osm vnfd-create " för var och en av de virtuella GF:er som utgör utvärderingstjänsten ( motsvarar filnamnet på VNFD-paketet).
   2. Ombord på NS-deskriptorn (NSD) för utvärderingstjänsten med kommandot "osm nsd-create ", där indikerar NSD-paketets filnamn (i det här experimentet ping_pong_ns.tar.gz)."
   3. Starta instansieringen av Ping Pong Network Service (NS) på de externa och centrala platserna med kommandot "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }}. den parameter identifierar VIM för den externa platsen i OSM-stacken. Alternativet "--config" anger att alla virtuella GF:er som utgör tjänsten måste distribueras på den externa plats som hanteras av den VIM: n, med undantag för den virtuella budget som identifieras av index 2 i NS, som kommer att distribueras på den centrala platsen (VIM för den centrala platsen anges i parameter).
   4. Kontrollera att NS har distribuerats och dess status med kommandot "osm ns-list". Om instansieringen lyckas ändras statusen till "READY".
   5. Kontrollera IP-adressen för var och en av de två virtuella GF:erna med "osm vnf-lista" (nödvändigt för att logga in på maskinerna efteråt).
   6. Anslut till varje virtuellt kommando via SSH med kommandot "ssh fedora@" ( representerar IP-adressen för VNF att ansluta till, som erhölls i föregående steg). Introducera lösenordet "fedora" när SSH uppmanas. När du har loggat in på båda datorerna kontrollerar du deras gränssnitt med kommandot "ip-adressshow" och hämtar IP-adresserna på deras gränssnitt som är anslutna till dataleverantörsnätverket (gränssnittset1 i båda VNF: erna). Från en av de virtuella nätverkarna utför du en ping till den andra virtuella datanf:en med hjälp av fjärr-IP-adressen i dataprovidernätverket. Om det finns anslutning anses det preliminära valideringstestet vara framgångsrikt.

4. Validering av NFV-plattformen med flera platser med en realistisk vertikal tjänst

1. Ladda ned VNF-bilderna från det offentliga arkivet och ladda upp dem till VIM på motsvarande webbplats (se figur 3), enligt förfarandet i steg 3.3.12. I synnerhet kommer den externa webbplatsen att vara värd för Access Point VNF, Router VNF, MQTT Gateway VNF och Access Router VNF. Den centrala platsen kommer att vara värd för 5G Core VNF och IoT Server VNF.
2. Ombord på VNFDs och NSD för den smarta jordbrukstjänsten till OSM-stacken (alla deskriptorer kan laddas ner från experimentarkivet).
   1. Registrera VNFD:erna till OSM-stacken som kör kommandot "osm vnfd-create ", för var och en av de virtuella GF:erna i nätverkstjänsten. I det här fallet motsvarar parametern VNFD-paketets filnamn.
   2. Registrera NSD till OSM-stacken med kommandot "osm nsd-create ", där indicerar filnamnet på NSD-paketet (i det här experimentet jove_uavs_scenario_nsd.tar.gz).
3. Distribuera nätverkstjänsten för smart jordbruk. För detta ändamål kör följande kommando från OSM-kommandoradsgränssnittet: 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 }'.
   OBS: Som anges i steg 3.6.3 anger och parameters de platser där VNF:erna ska distribueras. I synnerhet kommer alla virtuella nr-företag som utgör den smarta jordbrukstjänsten att placeras på den nya externa platsen, med undantag för de med index 5 och 6 (5G Core och IoT-serverns virtuella nr-filer)som kommer att tilldelas den centrala platsen.
4. Kontrollera att NS har distribuerats enligt samma procedur som i steg 3.6.4.
5. Åtkomst till IoT-servern VNF med kommandot "ssh mosquittosubscriber@" och kontrollera dess gränssnitt konfigurerat för att kommunicera med MQTT Gateway VNF genom kommandot "ip-adress show dev eth1". IP-adressen för VNF () kan erhållas genom att köra "osm vnf-listan" på OSM-kommandoraden.
6. Efter en analog procedur, tillgång till MQTT Gateway VNFoch kör kommandot "sudo python3 publisher_MQTT_GW.py -ma -ba " där erhålls i föregående steg och executing "ip-address show dev eth1" -kommandot i MQTT Gateway VNF. Det här steget initierar MQTT Gateway VNF, som tar emot data som genereras av sensorn med MQTT-standarden¹⁵, som överför dessa data till IoT-serverns VNF med samma standard.
7. Förbered en enkortsdator (SBC) som ansluter en meteorologisk sensor och med sändtagares kapacitet för att överföra sensoravläsningar mot MQTT Gateway VNF.
   OBS: För att exemplifiera detta protokoll har en SBC-modell i synnerhet använts. Därför kan följande steg behöva anpassas vid användning av en annan SBC-plattform.
   1. Anslut (t.ex. med hjälp av tennlödade koppartrådar) sensorns brädastift till de allmänna ingångs-/utgångsstiften (GPIO) i SBC, enligt konfigurationsschemat i figur 5.
   2. Aktivera I2C-kärnmodulen i SBC för att kunna verifiera om sensorn upptäcks. För detta ändamål kör du kommandot "sudo raspi-config", följer sekvensen Interfacing Options -> I2C -> Ja på menyn som visas och startar om SBC för att göra ändringarna effektiva.
   3. Kontrollera att sensorn är identifierad Installera programvaran i2c-verktyg i SBC och köra kommandot "sudo i2cdetect -y 1". I så fall ska ett rutnät visas som anger den position där sensorn detekteras.
   4. Installera lämpliga programvarubibliotek så att SBC kan läsa och skicka data som tillhandahålls av sensorn. I synnerhet utnyttjar detta experiment RPi.bme280³² och paho-mqtt³³ Python-bibliotek.
8. Använd den mobila applikationen av SUAV, ta av flygfordonet som är värd för Access Point VNFoch placera den för att ge trådlös täckning till SBC med sensorn.
   OBS: Flygningen av de NFV-kapabla stadsjeeparen är oberoende av nättjänstens operativa beteende, som kan fungera oavsett om stadsjeepar flyger eller är i vila för att minska batteriförbrukningen. Steg 4.8 är alltså valfritt.
9. Anslut SBC som ansvarar för att läsa av de data som samlas in av sensorn till den trådlösa Wi-Fi-åtkomstpunkten som tillhandahålls av accesspunkten VNF). Efter en lyckad bifogad fil aktiveras en sökväg för trådlöst nätverk från sensorn till MQTT Gateway VNF.
10. Starta överföringen av avkända data och kör kommandot "python3 /home/ubuntu/sensorDataTransmission.py -a " i SBC som innehåller sensorn ( är IP-adressen som erhålls i steg 4.6.).
11. Gå till webb-GUI som tillhandahålls av IoT-servern VNF för att kontrollera korrekt realtidsmottagning av de avkända data. Kontrollera därför IP-adressen för IoT Server VNF med kommandot "osm vnf-list" och skriv följande URL (Uniform Resource Locator) i en webbläsare: http://:3001, där är IP-adressen för IoT-servern VNF. Klicka sedan på knappen Insamling av sensorer på fliken Start och verifiera realtidsuppdateringen av graferna som ingår i instrumentpanelen när data tas emot.
    Obs: För att kunna komma åt webbadressen som nämns i steg 4.12 måste enheten med webbläsaren som försöker nå den resursen vara ansluten till NFV-ekosystemet och ha IP-anslutning till IoT Server VNF. VPN-tjänsten kan också användas för detta ändamål.
12. Vänta en lämplig tidsperiod för att få representativa resultat av genomförandet av den smarta jordbrukstjänsten. Samla sedan in data som lagras i IoT-serverns VNF för ytterligare analys. Med tanke på att sensorn som ingår i detta experiment ger temperatur-, fuktighets- och tryckavläsningar var 5: e sekund, körs tjänsten i experimentet under en period av 10 minuter, vilket resulterar i 180 prover av avkännade data (60 för varje meteorologisk värdetyp).
13. Gå till databasen för IoT Server VNF för att hämta de avkända data för ytterligare analys. I det här syftet kör du kommandot "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' -f 1)" på IoT Server VNF och sedan "sudo docker exec -it $id_database bash"
14. Exportera data till en CSV-fil (kommaavgränsad värde) med kommandot "influx -database 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Ändra parametern för att välja vilken typ av avkänningsdata som ska exporteras med "temperatur", "fuktighet" eller "tryck" och ställ in parameter för att välja ett namn på utdatafilen som ska behålla resultaten.
15. Spara de datafiler som genererades i föregående steg för senare representation (se avsnittet Representativa resultat) och verifiering av korrekt drift av den smarta jordbrukstjänsten.

Representative Results

Efter att noggrant ha följt protokollet för att införliva en ny webbplats till den centrala plattformen och köra en nätverkstjänst för att validera dess korrekta funktionalitet, visar figur 6 en skärmdump av verktyget för öppen vpn-bildskärm. Det kan observeras hur den nya webbplatsen använder VPN för all sin kommunikation, som visar hur dess kommunikation följer VPN för att tillåta detta datautbyte och följaktligen korrekt tillägg av den nya webbplatsen till VPN-tjänsten.

Enligt figur 3levererar nätverkstjänsten information från en sensor som finns i en fjärrinfrastruktur till servern på den centrala platsen. Dessutom visar figur 7 den lyckade distributionen av nätverkstjänsten från OSM-webb-GUI: n, som visar hur experimentet kan instansieras korrekt i den nya fjärrinfrastrukturen från MANO-stacken som finns på den centrala platsen. Dessutom är den tid som krävs i experimentet för att slutföra distributionen av tjänsten cirka åtta minuter. Det här värdet, tillsammans med den tid som krävs för att ombord på tjänstbeskrivningarna i orkestreringsplattformen (cirka 9 sekunder, med 1,3 sekunder per beskrivning, med tanke på både NS- och VNF-deskriptorerna), gör det möjligt att uppfylla KPI (Key Performance Indicator) på 90 minuter för tjänstens skapandetid, vilket anges i 5G Infrastructure Public Private Partnership³⁴. I detta sammanhang innehåller det arbete som presenteras i Vidal et al.⁹ en djupgående analys av tjänstens skapande tid med flera platser med hjälp av det presenterade protokollet.

Figur 8 visar de data som samlas in från sensorn, inklusive värdena för luftfuktighet, temperatur respektive tryck. Dessa exempel motsvarar alla data som skickas från sensorn till en fjärrserver i 5TONIC, där dessa värden lagras i en databas. Alla dessa data visar att plattformen kan distribuera praktiska nätverkstjänster efter införandet av en ny infrastruktur, samt för att korrekt möjliggöra kommunikation mellan platser.

Bild 1: Distribution av VPN-tjänster. Distribution av VPN-tjänsten via plattformen och deras länkanslutning (alla passerar genom 5TONIC). Klicka här för att se en större version av den här figuren.

Figur 2. Översikt över plattformen och VPN-tjänsten. Denna siffra visar alla delar av plattformen: den centrala platsen, tillsammans med dess NFV-infrastruktur, VPN-tjänsten och en ny infrastruktur aggregerad till systemet. Det innehåller också kopplingarna mellan dess element. Klicka här för att se en större version av den här figuren.

Bild 3: Översikt över nätverkstjänsten. Den visar de element som är involverade i nätverkstjänsten, dess distribution och dess logiska och nätverksanslutning. Klicka här för att se en större version av den här figuren.

Bild 4: Protokollarbetsflöden. Varje kolumn representerar ett avsnitt i protokollet, där varje utförd åtgärd beskrivs, dess logiska koppling mellan dem och den komponent som ansvarar för körningen. Klicka här för att se en större version av den här figuren.

Bild 5:Konfigurationsschema för stift. Diagram som representerar hur man gör de fysiska anslutningarna mellan sensorernas brädstift och GPIO-stiften i SBC som innehåller den sensorn. Klicka här för att se en större version av den här figuren.

Bild 6: Ögonblicksbild av OpenVPN-skärmen. Bilden visar att den aggregerade infrastrukturen är ansluten till VPN-tjänsten, inklusive några av dess detaljer om dess anslutning. Dessutom visar figuren också ytterligare anslutningar som tillhör annan fjärrinfrastruktur. Klicka här för att se en större version av den här figuren.

Bild 7: OSM NS-distributionsstatus. OSM-grafiskt gränssnitt som visar en lyckad distribution av testnätverkstjänsten i fjärrinfrastrukturen. Klicka här för att se en större version av den här figuren.

Bild 8: Representativ analys av de data som samlas in av sensorn. (A) Illustration av temperaturdata som regelbundet samlas in av sensorn var 5:e sekund. (B) Grafisk representation av de fuktighetsdata som samlas in av sensorn var 5:e sekund. (C) Visuell bild av de tryckdata som samlas in av sensorn var 5:e sekund. Klicka här för att se en större version av den här figuren.

Discussion

En av de viktigaste aspekterna av det tidigare beskrivna protokollet är dess enastående flexibilitet att införliva nya beräkningsinfrastrukturer i ett NFV-ekosystem, oavsett deras fördelning när det gäller geografisk plats (så länge bandbredd och svarstid för nätverkskommunikationen med fjärrplatser stöder det). Detta är möjligt genom en VPN-baserad nätverksarkitektur för överlägg, som gör det möjligt att upprätta en virtuell länk för att ansluta fjärrplatser till de centrala lokalerna i NFV-ekosystemet. Detta tillvägagångssätt gör det möjligt att tillhandahålla en effektiv och säker kanal för att stödja NFV och datakommunikation mellan platser i ett NFV-ekosystem, vilket minskar sannolikheten för att externa parter får tillgång till och/eller ändrar känslig information om NFV-orkestreringsprocesser och data från distribuerade tjänster. I det här sammanhanget beskriver protokollet också en specifik metod för att säkert dela VPN-autentiseringsuppgifterna med de externa webbplatser som möjliggör integrering av nya infrastrukturer. Protokollet har exemplifierats med hjälp av NFV-ekosystemet som gjorts tillgängligt på 5TONIC av Universidad Carlos III de Madrid, Telefónica och IMDEA Networks Institute, även om det är generiskt att användas i andra NFV-miljöer som uppfyller de tidigare krav som nämns i steg 1 i detta protokoll.

Dessutom är det värt att betona det exklusiva användningen av verktyg och programvara med öppen källkod för protokollimplementering. Trots de potentiellt fördelaktiga funktioner som skulle kunna erbjudas av olika proprietära lösningar (t.ex. Fortinet³⁵⁾har användningen av utveckling med öppen källkod underlättat integrationen av alla element som omfattas av protokollet på grund av deras inneboende egenskaper, såsom kostnadseffektivitet, ett omfattande programvarustöd från öppen källkod och en hög grad av tillförlitlighet. Bara för att nämna några av dem. Dessutom kan användningen av teknik med öppen källkod också främja synergieffekter mellan komponenter av liknande karaktär. För att till exempel övervaka VPN-anslutningsstatusen för de klienter som använder plattformen kan VPN-tjänsten som implementeras i hela protokollet förlita sig på det öppna vpn-övervakningsverktyget³⁶ (ett python-baserat övervakningsverktyg som kan samverka med OpenVPN-servrar).

Å andra sidan tar protokollspecifikationen hänsyn till instansiering av nätverkstjänster på olika platser för valideringsändamål. I detta avseende är det viktigt att betona att distributionen av tjänster på en viss plats är beroende av tillgången till beräknings-, lagrings- och nätverksresurser på platsen samt av specialiserad utrustning som kan behövas för att utföra distributionen (t.ex. NFV-aktiverade stadsjeepar). Detta är inte en begränsning av protokollet och bör beaktas av intressenter som är intresserade av att reproducera det experiment som beskrivs i detta dokument.

Det bör dessutom noteras att den tid som krävs för att genomföra utbyggnaden av nätverkstjänster i hög grad beror på flera faktorer, såsom nätverksvägen mellan orchestrator och de olika VIMs, utförandet av datakommunikation mellan VIM och dess hanterade beräkningsnoder, och även av dessa beräkningsnodernas inneboende karaktär (inte bara på grund av deras tillgängliga datorresurser. men också den teknik som ingår för att genomföra virtualiseringen av nätverksfunktioner).

Slutligen, och med tanke på den enastående prestanda som denna plattform och dess VPN-tjänst hade på de europeiska projekt och samarbetsarbeten där den hittills har använts (t.ex. 5GINFIRE, 5GRANGE eller 5GCity, som nämns i införandet av detta dokument), kommer den att betraktas som en viktig del i framväxande europeiska projekt där Universidad Carlos III de Madrid, Telefónica och IMDEA Networks Institute deltar, såsom Horizon 2020 LABYRINTH, eller nationella projekt, 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/