Integrering av 5G-eksperimenteringsinfrastrukturer i et NFV-økosystem med flere områder

Summary

Målet med den beskrevne protokollen er å støtte fleksibel inkorporering av 5G-eksperimenteringsinfrastrukturer i et NFV-økosystem med flere nettsteder, gjennom en VPN-basert overleggsnettverksarkitektur. Videre definerer protokollen hvordan effektiviteten av integrasjonen skal valideres, inkludert en vertikal tjenestedistribusjon på flere områder med NFV-kompatible små luftfartøyer.

Abstract

Network Function Virtualization (NFV) har blitt sett på som en av nøkkelaktiveringene for femte^generasjons mobilnettverk, eller 5G. Dette paradigmet gjør det mulig å redusere avhengigheten av spesialisert maskinvare for å distribuere telekommunikasjon og vertikale tjenester. Til dette formålet er den avhengig av virtualiseringsteknikker for å myke opp nettverksfunksjoner, forenkle utviklingen og redusere distribusjonstid og kostnader. I denne sammenhengen har Universidad Carlos III de Madrid, Telefónica og IMDEA Networks Institute utviklet et NFV-økosystem inne i 5TONIC, et åpent nettverksinnovasjonssenter fokusert på 5G-teknologier, noe som muliggjør opprettelse av komplekse, nær virkelighetseksperimenteringsscenarier på tvers av et distribuert sett med NFV-infrastrukturer, som kan gjøres tilgjengelig av interessenter på forskjellige geografiske steder. Denne artikkelen presenterer protokollen som er definert for å innlemme nye eksterne NFV-områder i NFV-økosystemet med flere områder basert på 5TONIC, som beskriver kravene til både eksisterende og de nylig innlemmede infrastrukturene, tilkoblingen gjennom en overleggsnettverksarkitektur og trinnene som er nødvendige for inkludering av nye områder. Protokollen eksemplifiseres gjennom inkorporering av et eksternt nettsted til 5TONIC NFV-økosystemet. Etterpå beskriver protokollen verifiseringstrinnene som kreves for å validere en vellykket nettstedintegrasjon. Disse inkluderer distribusjon av en vertikal tjeneste på flere områder ved hjelp av en ekstern NFV-infrastruktur med små ubemannede luftfartøyer (SUAVer). Dette tjener til å vise potensialet i protokollen for å muliggjøre distribuerte eksperimenteringsscenarier.

Introduction

Innføringen av femte generasjon mobilnett (5G) har antydet revolusjonering av telekommunikasjonsindustrien siden begynnelsen av tiåret, noe som krever at telekommunikasjonsoperatører adresserer de mye mer krevende spesifikasjonene til de nye nettverkstjenestene og applikasjonene utviklet under 5G-paraplyen^1,2 . Disse nye spesifikasjonene inkluderer, men er ikke begrenset til, datahastighetsøkninger, forbedringer av trådløs overføringsventetid og reduksjon av driftskostnader. Blant teknologiene som utgjør grunnlaget for forbedringene for denne nye generasjonen, har Network Functions Virtualization³ (NFV) blitt en av de viktigste tilretteleggerne. NFV gir kapasitet til å softwarize nettverksfunksjoner, tradisjonelt videresending på spesialisert maskinvare, ved å bruke generisk fysisk utstyr i stedet, for eksempel serverdatamaskiner i et datasenter. Med dette nye paradigmet kan telekommunikasjonsoperatører og vertikale bransjer distribuere nettverksfunksjoner og -tjenester som et sett med programvarekomponenter, og spare kostnader i både tjenestedistribusjon og vedlikehold, samt legge til rette for en mye høyere elastisitet i nettverksinfrastrukturen. Denne tilnærmingen lindrer eller eliminerer nødvendigheten av å bruke dedikerte (og vanligvis mer komplekse og mindre gjenbrukbare) enheter for de fleste nettverks- og vertikalspesifikke funksjoner, og støtter en mye høyere og tettere grad av driftsautomatisering, og reduserer dermed distribusjons- og vedlikeholdskostnadene.

Med tanke på alle fordelene et NFV-miljø er i stand til å gi, er det naturlig at et stort antall relevante interessenter fra telekommunikasjonssektoren i økende grad har vært involvert i testing av nye tjenesteideer på NFV-miljøer. I denne sammenhengen har Telefónica og IMDEA Networks Institute opprettet 5TONIC⁴, et åpent forsknings- og innovasjonslaboratorium fokusert på 5G-teknologier. Basert i Madrid (Spania), har dette laboratoriet et bredt spekter av teknologier tilgjengelig for forskning og partnere for å øke utviklingen og valideringen av 5G-tjenester. Spesielt har dette laboratoriet en eksperimentell NFV-plattform der utviklere er i stand til å distribuere og teste sine nye NFV-baserte applikasjoner og tjenester over på et ETSI-kompatibelt NFV-økosystem⁵. Dermed kan eksperimentelle konklusjoner om designvalg og teknologiforslag utledes i et realistisk mye mer fleksibelt miljø enn produksjonsnettverk. Denne plattformen er designet for å støtte eksperimenteringsaktiviteter på tvers av flere eksterne nettsteder, som kan være fleksibelt sammenkoblet med 5TONIC ved hjelp av en veldefinert protokoll.

Den tekniske løsningen som er vedtatt for 5TONIC NFV-økosystemet, vurderer bruken av en enkelt NFV-orkestrator, implementert ved hjelp av DEN ETSI-vert Open Source MANO (OSM) programvare⁶. Dette er elementet som har ansvaret for å administrere og koordinere livssyklusen til Network Services (NS). Disse tjenestene kan bygges som en sammensetning av virtualiserte nettverks-/vertikale funksjoner (VNF), som kan distribueres på alle stedene som er integrert på NFV-plattformen. Utformingen av 5TONIC NFV-økosystemet er gjort i sammenheng med H2020 5GINFIRE-prosjektet^7,8, der plattformen ble brukt til å støtte utførelsen av mer enn 25 eksperimenter, valgt gjennom en konkurransedyktig åpen samtaleprosess, over åtte vertikalspesifikke eksperimentelle infrastrukturer lokalisert i Europa og en i Brasil, sistnevnte koblet gjennom en transoceanic link. I tillegg ble plattformen utnyttet til å bygge en distribuert NFV-test som ble testet i nasjonal skala, i Spania, og støttet eksperimenteringsaktiviteter i det spanske 5GCity-prosjektet^9,10. Mer nylig har et ekstra brasiliansk nettsted blitt integrert i plattformen, for å støtte felles demonstrasjonsaktiviteter i sammenheng med et forsknings- og innovasjonssamarbeid etablert mellom Brasil og Europa (dvs. 5GRANGE-prosjektet^11,12). Sist, men ikke minst, har infrastrukturen blitt brukt til å støtte tredjepartseksperimenter i omfanget av 5G-VINNI-prosjektet^13,14. Den geografiske fordelingen av NFV-plattformen kan ses i figur 1.

Interesserte organisasjoner som er vert for sin egen NFV-infrastruktur, kan fleksibelt koble seg til 5TONIC NFV-økosystemet, med forbehold om godkjenning av 5TONIC-styret, bli testbedleverandører i det distribuerte økosystemet og være involvert i felles eksperimenterings- og demonstrasjonsaktiviteter. For dette formål må de ha en VIM (Virtual Infrastructure Manager) kompatibel med OSM-programvarestakken. 5TONIC NFV-orkestratoren er i stand til å samhandle med VIM-ene på stedene som er involvert i en gitt tjenestedistribusjon, koordinere tildelingen og oppsettet av databehandlings-, lagrings- og nettverksressursene som trengs for å starte og koble sammen VNFer som utgjør en nettverkstjeneste, og kontrollere livssyklusen, fra ombordstigning til endelig dekommisjonering.

For å administrere utveksling av kontroll og datatrafikk innenfor alle sammenkoblede nettsteder, bruker 5TONIC NFV-økosystemet en overleggsnettverksarkitektur basert på virtuelle private nettverk (VPN). Denne tilnærmingen gir sikker PKI-basert tilgang til de eksterne områdene som er integrert i 5TONIC-økosystemet, slik at utveksling av NFV-kontrollinformasjon mellom OSM-programvarestakken og de forskjellige VIM-ene som distribueres på tvers av testsengene, samt utveksling av informasjon som kreves for å administrere og konfigurere alle VNFer. Videre støtter dette overleggsnettverket spredning av datatrafikk blant VNFer som distribueres på forskjellige steder.

I denne sammenhengen beskriver dette dokumentet protokollen som er utformet for å innlemme et eksternt område i et NFV-økosystem. Protokollen forutsetter at økosystemet styres av en enkelt NFV-orkestrator, installert på et sentralt sted, og eksterne nettsteder har en VIM-løsning som er kompatibel med orchestrator-programvarestakken. Den foreslåtte protokollen gjør det mulig å øke porteføljen av ressurser i det eksperimentelle økosystemet, med fleksibel innlemmelse av NFV-anlegg og vertikalspesifikke infrastrukturer. Dette gjør det mulig å opprette en distribuert MANO-plattform som er i stand til å teste og validere nye nettverk og vertikale tjenester på tvers av flere nettsteder, under kontroll av en enkelt NFV-orkestrator. For å illustrere den indre driften av protokollen, vil prosessen bli eksemplifisert ved å legge til et eksternt NFV-område i det nåværende 5TONIC NFV-økosystemet, som beskriver de nødvendige komponentene på det eksterne stedet og 5TONIC, samt alle trinnene som skal tas under integrasjonsprosessen. Figur 2 gir en oversikt over målet med integrasjonen, med den nye NFV-baserte testsengen knyttet til 5TONIC-plattformen der nettverkstjenester kan distribueres, ved hjelp av VPN-tilkoblinger mellom det sentrale nettstedet og resten av de eksterne infrastrukturene.

I tillegg, for å vise effektiviteten av protokollen, vil distribusjonen av en enkel vertikal tjeneste bli vist ved hjelp av 5TONIC økosystemet og et eksternt sted med NFV-kompatible små ubemannede luftfartøyer (SUAVs). Utformingen av den vertikale tjenesten er inspirert av et eksperiment presentert i Vidal et al.⁹, som er forenklet for illustrasjonsformålene til dette papiret. Figur 3 skisserer tjenesten, som tar sikte på å hjelpe smarte landbruksaktiviteter på et avsidesliggende område. Tjenesten vurderer en smart leverandør av landbrukstjenester som bruker SUAVer til å samle inn og spre dataene produsert av meteorologiske sensorer spredt over et avlingsfelt. For enkelhets skyld vurderer eksperimentet som presenteres i papiret en enkelt SUAV og en sensor, som er i stand til å gi temperatur-, fuktighets- og trykkmålinger. I eksperimentet er det eksterne NFV-nettstedet vert for et Wi-Fi-tilgangspunkt som distribueres som VNF over SUAV. Denne VNF-en tilbyr nettverkstilgangstilkobling til sensoren, og videresender de sansede dataene mot en gateway-funksjon. Sistnevnte distribueres som en VNF på et bakkeutstyr (en mini-ITX-datamaskin). Spredningen av data fra sensoren til gateway-funksjonen følger en Publish/Subscribe -tilnærming basert på MQTT-protokollen (Message Queuing Telemetry Transport)¹⁵. Gateway-funksjonen behandler og sprer deretter dataene mot en IoT-server (Internet-of-Things), som gjøres tilgjengelig som en VNF på det sentrale stedet i NFV-økosystemet, basert på Mainflux¹⁶ åpen kildekode-plattformen. Til slutt antar scenariet et eksternt område der Internett-tilkobling leveres av et mobilt ikke-3GPP-tilgangsnettverk. Derfor inkluderer tjenesten to ekstra VNFer: 1) en tilgangsruter VNF, som implementerer brukerplanprotokollstakken til et 3GPP-brukerutstyr koblet til et ikke-3GPP-tilgangsnettverk¹⁷; og 2) en grunnleggende implementering av et 5G-kjernenettverk, som støtter videresending av informasjon mellom tilgangsruteren og IoT-serverens VNFer. Til dette formål gir 5G-kjernen VNF en forenklet implementering av brukerplanet til en ikke-3GPP-interworkingfunksjon og en brukerplanfunksjon, som definert av 3GPP¹⁷.

Til slutt representerer figur 4 de mest relevante prosessene som er involvert under utviklingen av protokollen, og fremhever deres logiske forbindelser og enhetene som har ansvaret for utførelsen.

Protocol

1. Levering av det sentrale stedet i NFV-økosystemet (tidligere krav til eksperimentet)

1. Tildel et IP-adresseområde som skal brukes av det sentrale området. I denne protokollen brukes det private adresseområdet 10.4.0.0/16.
2. Installer mano-programvarestakken (Management and Orchestration) på det sentrale området. Spesielt bruker eksperimentet som utføres i denne protokollen Open Source MANO (OSM) Release SEVEN¹⁸, som krever følgende ressurser: Ubuntu 18.04 som operativsystem, 2 prosessorenheter (CPUer), 8 GB RAM (Random-Access Memory), 40 GB harddiskdisk og minst ett nettverksgrensesnitt med Internett-tilgang. Følg instruksjonene som er tilgjengelige i OSM Versjon SEVEN-dokumentasjonen¹⁸for installasjonen.
3. Konfigurer en VIM (Virtual Infrastructure Manager) som er kompatibel med OSM på det sentrale området. Spesielt bruker eksperimentet OpenStack release Ocata²⁰, som kjører på en virtuell maskin (VM) med Ubuntu 16.04 , 4 CPUer, 16 GB RAM og 200 GB harddisk. NFV Infrastructure (NFVI) som håndteres av denne VIM består av tre serverdatamaskiner, hver med Ubuntu 16.04, 8 CPUer, 32 GB RAM og 2 TB lagringsplass. Følg ocata-utgivelsesdokumentasjonen²¹for installasjonen.
   1. Distribuer et virtuelt nettverk i OpenStack-skyplattformen ved hjelp av et IP-adresseområde fra adresseområdet som ble tildelt i trinn 1.1. Dette nettverket, heretter kalt administrasjonsnettverk, vil bli brukt til å støtte utveksling av NFV-orkestreringsinformasjon mellom OSM og de virtuelle nettverksfunksjonene (VNFer) som startes på det sentrale området.
   2. Konfigurer et virtuelt nettverk (heretter denominert som datanettverk) for å støtte datakommunikasjon mellom områder, mellom VNFene på det sentrale området og andre VNFer som utføres på eksterne områder. For dette formål bruker du et IP-adresseområde fra adresseområdet i trinn 1.1.
      MERK: Implementeringen av nettverkene nevnt i trinn 1.3.1 og 1.3.2 er gjort ved hjelp av leverandørnettverk av OpenStack. Leverandørnettverk må være koblet til den fysiske nettverksinfrastrukturen på det sentrale området for å garantere en passende operasjon.
4. Koble både virtuelle private nettverk (dvs. ledelsen og datanettverkene), samt VIM- og OSM-maskinene, til et utstyr som gir kantrutingsfunksjoner. Denne ruteren vil fungere som inngangspunkt til det sentrale stedet i NFV-økosystemet.
5. Gjør tilgjengelig et offentlig eksperimentrepositorium for å gi alt innholdet som trengs for å utføre eksperimentet. Denne protokollen bruker spesielt det offentlige repositoriet på²².

2. Konfigurasjon av den virtuelle private nettverkstjenesten

1. Tildel et IP-adresseområde for å støtte riktig drift av økosystemet med flere områder, slik at nettverkskommunikasjon effektivt kan opprettes mellom flere områder.
   MERK: Aktivering av effektiv nettverkskommunikasjon mellom flere nettsteder krever en nøye utforming av IP-adresseområdet som skal brukes av NFV-økosystemet, så vel som av eksterne nettsteder som trenger å koble til det. Spesielt bør adresseområdet som er tildelt for kommunikasjon mellom områder, ikke kollidere med adresseområdet som allerede er i bruk på alle andre områder til andre formål.
   1. Tildel et IP-adresseområde som skal brukes av eksterne områder. Adresser i denne blokken tilordnes NFV-enheter (f.eks. VIMer) og VNFer for det eksterne området. Hvis du vil eksemplifisere denne protokollen, brukes det private adresseområdet 10.154.0.0/16.
   2. Tildel et IP-adresseområde til de virtuelle koblingene mellom de eksterne områdene og NFV-økosystemet. Disse virtuelle koblingene vil bli støttet av en VPN-tjeneste. Adresseområdet 10.154.254.254.0/24 brukes for disse virtuelle koblingene for å eksemplifisere denne protokollen.
2. Sett opp et utstyr for å levere VPN-tjenesten (Virtual Private Network) (dvs. en VPN-server). Spesielt bruker eksperimentet en serverdatamaskin med Ubuntu 16.04 (64-biters variantbilde), seks uavhengige CPUer, 16 GB RAM, 1 TB lagringsdisk og to nettverksgrensesnitt.
   1. Konfigurer et av nettverksgrensesnittene til VPN-serveren for å tillate mottak av tilkoblingsforespørsler fra eksterne områder via Internett. For det formål er det nødvendig å bruke et grensesnitt på serveren som er konfigurert med en offentlig IP-adresse.
   2. Konfigurer koblingen mellom VPN-serveren og kantruteren til det sentrale nettstedet. I eksperimentet ble denne lenken tildelt adresseområdet 10.4.255.0/24. Konfigurer passende nettverksruter på VPN-serveren, slik at NFV-økosystemet blir tilgjengelig fra eksterne nettsteder som er koblet til VPN-tjenesten.
3. Installer VPN åpen kildekode-programvaren levert av OpenVPN^{23-prosjektet} til VPN-serveren. Spesielt bruker dette eksperimentet OpenVPN versjon 2.3.10, og distribusjonen ble gjort med bash-skriptet "openvpn-install.sh", tilgjengelig på http://github.com/Nyr/openvpn-install (andre installasjonsalternativer er beskrevet i OpenVPN-dokumentasjonen ²⁴). Bash-skriptet presenterer de alternative parametrene som vil resultere i konfigurasjonen av VPN-tjenesten.
   1. Velg IP-adressen for å lytte til VPN-tilkoblingsforespørsler (dvs. den offentlige IP-adressen).
   2. Bestem hvilken protokoll (UDP eller TCP) som skal brukes til å drive kommunikasjonen over VPN-et. I dette tilfellet utnytter eksperimentet på UDP som er den anbefalte protokollen.
   3. Angi porten som skal bestå av duple (sammen med den offentlige IP-adressen) som skal brukes til å motta tjenestetilkoblingsforespørslene. Som standard er den tilordnede verdien 1194.
   4. Velg en av DNS-serverne i listen som hjelperen ber om, og som håndterer navneløsingsforespørslene som utføres av klientene til VPN-tjenesten.
   5. Trykk en tast for å aktivere automatisk start av installasjonsprosessen for VPN-tjenesten.
4. Rediger konfigurasjonsfilen "server.conf" som ligger under katalogen "/etc/openvpn/server/" og inkluder "klient-til-klient"-direktivet som tar sikte på å utvide det grunnleggende oppsettet fra trinn 2.3. Dermed vil forskjellige klienter som er koblet til VPN-tjenesten kunne nå hverandre.
5. Aktiver den individuelle klientkonfigurasjonen i VPN-oppsettet for å kunne administrere rutingtilordningene for hver klient uavhengig av hverandre.
   1. Legg til direktivet "client-config-dir ccd", og redigerer den samme konfigurasjonsfilen som i trinn 2.4.
   2. Opprett katalogen "ccd" ved hjelp av kommandoen "mkdir /etc/openvpn/ccd/". Denne mappen vil fungere i løpet av neste del av protokollen for å plassere filene som består av rutingsdirektivene som er knyttet til klientene som er ment å bli integrert i plattformen.
6. Konfigurer brannmurreglene som er nødvendige for å tillate tilkoblingene til tjenesten, samtidig som du beskytter VPN-serveren mot ondsinnet angrep. For det formål utnytter dette eksperimentet på iptables²⁵, som er et kommandolinjeverktøy utviklet for å konfigurere Linux-kjernebrannmuren.
   1. Blokker først innkommende trafikk til VPN-serveren med kommandoen "iptables -P INPUT DROP".
   2. Tillat mottak av VPN-tilkoblingsforespørsler med kommandoene "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( er navnet på VPN-servergrensesnittet med den offentlige IP-adressen) og "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Tillat videresending av trafikk mellom VPN-servergrensesnittene (dvs. det offentlige grensesnittet og det virtuelle grensesnittet opprettet av VPN-tjenesten kalt tun0), slik at VPN-serveren kan behandle forespørselen om tjenestetilkobling. Til dette formål utfører du 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. Gjør det mulig for VPN-serveren å gi NAT-funksjonen (Network Address Translation) som mål å gi Internett-tilgang til det sentrale området, og utføre: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integrasjon av et eksternt NFV-nettsted

1. Få et passende IP-adresseområde for å integrere nettstedet i NFV-økosystemet. Dette adresseområdet vil bli levert av nettverksoperasjonssenteret til NFV-økosystemet. I følge trinn 2.1.1 i denne protokollen vil eksperimentet bruke en rekke IP-adresser for det eksterne nettstedet innen 10.154.0.0/16.
2. Opprett og oppgi sikkerhetslegitimasjonen for å koble til NFV-økosystemet.
   1. Generer en VPN-legitimasjon som gjør det mulig for den nye infrastrukturen å opprette en sikker tilkobling til VPN-serveren. Til dette formål, utfør kommandoen "bash openvpn-install.sh" i VPN-serveren, velg alternativet "1) Legg til en ny klient" for denlede listen, og oppgi navnet som skal knyttes til den legitimasjonen, for eksempel uc3m_infrastructure. Dette trinnet vil generere en fil med VPN-legitimasjonen (kalt "uc3m_infrastructure.ovpn" i eksemplet).
   2. Opprett en tekstfil i katalogen "/etc/openvpn/ccd/" på VPN-serveren, inkludert rutingsdirektivene (som angitt i OpenVPN-dokumentasjonen ²⁴) som må skyves av VPN-serveren hver gang en tilkobling til VPN-tjenesten opprettes ved hjelp av VPN-legitimasjonen.
      MERK: Navnet på tekstfilen må samsvare med navnet som er angitt under opprettelsen av VPN-legitimasjonen (f.eks. uc3m_infrastructure) for å gi en tilpasset konfigurasjon for hver VPN-klient.
   3. Gi VPN-legitimasjonsfilen til teknisk personell på det eksterne nettstedet. Dette må gjøres gjennom en sikker og pålitelig kanal. I dette eksperimentet brukes en manuell krypteringsprosess. Hvis du vil kryptere VPN-legitimasjonen, utfører du kommandoen "7za a -tzip '-p' -mem=AES256 ", som den ønskede krypteringsnøkkelen, som det valgte navnet på den krypterte filen og som filnavnet til VPN-legitimasjonsfilen (f.eks. uc3m_infrastructure.ovpn).
   4. Oppgi den krypterte legitimasjonen til teknisk personell på det nye området, sammen med nøkkelen som tillater dekrypteringsprosedyrene, gjennom en sikker kommunikasjonskanal.
      MERK: I dette eksperimentet ble den krypterte legitimasjonen levert via elektronisk e-post, mens dekrypteringsnøkkelen ble sendt gjennom en egen kanal, ved hjelp av den korte meldingstjenesten (SMS), med en offline avtale om telefonnummeret.
3. Sett opp miljøet på det nye stedet, for å etablere forbindelsen med NFV-økosystemet, og for å tillate at den eksterne NFVI-en festes til OSM-stakken på det sentrale området.
   1. Installer VPN-programvaren levert av OpenVPN²⁴ på en datamaskin, for å aktivere en virtuell kobling mellom det eksterne nettstedet og det sentrale nettstedet til NFV-økosystemet. Datamaskinen med OpenVPN-programvaren vil fungere som en VPN-klient eller VPN-endepunkt på det eksterne nettstedet. Den virtuelle lenken vil bli realisert ved hjelp av en beskyttet VPN-tunnel mellom VPN-endepunktet og VPN-serveren. I eksperimentet kjører VPN-endepunktet i en serverdatamaskin med Ubuntu 18.04, 8 CPUer, 8 GB RAM, 128 GB lagringsdisk og 3 GbE-grensesnitt (en for tilkobling til VPN-tjenesten over Internett).
   2. Aktiver IP-videresending i VPN-endepunktet for å støtte nettverksrutingsfunksjoner. Til dette formål inkluderer du linjen "net.ipv4.ip_forward=1" i systemkonfigurasjonsfilen som ligger i banen "/etc/sysctl.conf", og laster inn den oppdaterte konfigurasjonen med kommandoen "sudo sysctl -p".
   3. Dekrypter VPN-legitimasjonsfilen med informasjonen mottatt i trinn 3.2.4, ved hjelp av kommandoen "7za e ", der er filnavnet til den krypterte VPN-legitimasjonen. Angi dekrypteringsnøkkelen når kommandoen ber om det.
   4. Start OpenVPN-programvaren med den dekrypterte legitimasjonsfilen ved hjelp av kommandoen "sudo openvpn --config " ( er filnavnet på VPN-legitimasjonen). Med dette vil VPN-endepunktet godkjennes til VPN-serveren, og vil automatisk motta passende VPN-konfigurasjonsparametere og nettverksruter. På denne måten vil VPN-endepunktet oppføre seg som en kantruter med en virtuell kobling til det sentrale nettstedet til NFV-økosystemet.
   5. Kontroller riktig drift av VPN-endepunktet ved hjelp av ping -kommandoen for å bekrefte tilgjengeligheten av tilkobling til en av nodene på det sentrale området (f.eks. OSM-stakkutstyret).
   6. I det nye området velger du en OSM-kompatibel VIM for å tillate operasjoner med MANO-plattformen. For dette eksperimentet brukes OpenStack release Ocata.
      MERK: OSM Release SEVEN støtter følgende virtuelle infrastrukturadministratorer: OpenStack, OpenVIM²⁶, VMwares vCloud Director²⁷, Amazon Web Service²⁸, Microsoft Azure²⁹og Eclipse fog05³⁰ (se OSM-dokumentasjon¹⁸ for spesifikke konfigurasjonsdetaljer).
   7. Installer OpenStack release Ocata²⁰ (se de detaljerte prosedyrene i utgivelsesdokumentasjonen²¹).
   8. Distribuer NFV-infrastrukturen på det eksterne området og fest den til VIM. Spesielt bruker dette eksperimentet en NFV-infrastruktur som består av tre enkeltkortdatamaskiner (SBO-er), hver med en databehandlingskapasitet på 1 GB RAM, 4 CPUer og 32 GB lagringsdisk; og en enkelt mini-ITX-datamaskin med 8 CPUer, 8 GB RAM og 128 GB for lagring.
      MERK: Det eksterne området som eksemplifiseres i denne protokollen er basert på en NFV-infrastruktur for NFV-kompatible små ubemannede luftfartøyer (SUAVer) . Detaljene som følges for å muliggjøre slik infrastruktur er gitt i Nogales et al³¹. Trinn 3.3.6 til 3.3.8 er valgfrie, da det allerede kan finnes en NFV-infrastruktur på det eksterne stedet.
   9. Opprett et OpenStack-prosjekt for å angi settet med beregningsressurser for det eksterne området som skal integreres i NFV-økosystemet. For å gjøre dette, tilgang til det grafiske brukergrensesnittet (GUI) levert av OpenStack, logg på systemet med administratorlegitimasjonen, klikk på + Opprett prosjekt-knappen i kategorien Identitet -> prosjekter, og opprett et prosjekt som fullfører det viste skjemaet med den forespurte informasjonen.
   10. Opprett en gyldig bruker som skal administrere prosjektet som ble opprettet i forrige trinn. Til dette formålet får du tilgang til kategorien Identitet -> brukere med samme pålogging som i forrige trinn, klikker på + Opprett bruker og fyller ut de nødvendige feltene i det viste skjemaet (brukernavn og passord), velger det nye opprettede prosjektet som det primære prosjektet og velger administratorrollen.
   11. Endre sikkerhetsreglene for å tillate VNF-kommunikasjonstillatelser på det nye området (spesielt aktivere SSH- og ICMP-trafikk). I den forbindelse får du tilgang til OpenStack GUI med legitimasjonen til brukeren som ble opprettet i forrige trinn, følger du sekvensen: Project -> Network -> Security Groups -> + Add Rule, og velg SSH -alternativet for rullegardinlisten Regel . Gjenta prosessen, men velg alternativet All ICMP som er inkludert i rullegardinmenyen.
   12. Last ned bildene av en prøvetjeneste som tilbys av OSM-samfunnet, Ping Pong-nettverkstjenesten ("Fedora-x86_64-20-20131211.1-sda-ping" og "Fedora-x86_64-20-20131211.1-sda-pong") fra det offentlige eksperimentet repository, og last dem opp til VIM på det eksterne nettstedet. Følg sekvensen Prosjekt -> Beregn -> Bilder -> + Opprett bilde, og opprett bildene ved hjelp av skjemaet som vises, og velg hvert av bildene.
   13. Tilordne to IP-adresseområder innenfor adresseområdet for det eksterne området (tildelt i trinn 3.1). Disse områdene vil bli brukt til å støtte administrasjonen av VNFene på det eksterne nettstedet og for å muliggjøre datakommunikasjon mellom områder blant VNFer.
   14. Opprett et leverandørnettverk (kontrollleverandør) ved hjelp av VIM. Dette nettverket vil støtte NFV-kommunikasjon mellom OSM-stakken på det sentrale området og VNFer distribuert på det nye området for administrasjonsformål. Denne typen kommunikasjon vil også gjøre det mulig for OSM-stakken å konfigurere VNFer etter distribusjonen. Hvis du vil opprette et leverandørnettverk i OpenStack, følger du sekvensen Admin -> System -> Networks -> + Create Network og fyller ut detaljene for det nye nettverket ved hjelp av det valgte IP-adresseområdet i forrige trinn.
   15. Opprett et nytt leverandørnettverk (dataleverandør) ved hjelp av VIM. Dette nettverket vil støtte datakommunikasjon mellom VNFene på nettstedet og andre VNFer i NFV-økosystemet. Hvis du vil opprette dette leverandørnettverket i OpenStack, følger du sekvensen Admin -> System -> Networks -> + Create Network, og fyller ut detaljene for det nye nettverket ved hjelp av det tilordnede adresseområdet.
       MERK: Instruksjoner for hvordan du oppretter virtuelle nettverk vil variere avhengig av VIM-programvaren. Se i den respektive programvaredokumentasjonen hvis du vil ha mer informasjon.
   16. Del VIM-relatert informasjon (spesielt brukernavn/passord, og prosjektet som er opprettet i trinn 3.3.9 og 3.3.10) med teknisk personell på det sentrale nettstedet, for å aktivere vedlegg av VIM til OSM-programvarestakken.
4. Fest den eksterne NFV-infrastrukturen til OSM-programvarestakken på det sentrale området ved hjelp av informasjonen som er hentet fra trinn 3.3.16.
   1. Kontroller tilkoblingen mellom OSM-stakken på det sentrale området og VIM for det nye området ved hjelp av pingverktøyet.
   2. Hvis den forrige tilkoblingstesten er vellykket, kobler du den eksterne VIM-en til OSM-stakken på det sentrale området. For å gjøre dette, bruk følgende kommando i OSM-maskinen: "osm vim-create --name --user -passord < < URL>-auth_url --tenant --account_type ". I denne kommandoen: er navnet som er valgt for å identifisere VIM i OSM-stakken, er navnet på brukeren som er autorisert til å håndtere ressursene til det eksterne nettstedet (se trinn 3.3.10), er passordet til den angitte brukeren, er lenken til API gjort tilgjengelig av VIM for å aktivere forespørsler fra OSM-stakken , er prosjektnavnet som er definert i trinn 3.3.9, og is VIM-programvaren som brukes (i dette eksperimentet OpenStack).
5. Kontroller riktig vedlegg av den nye VIM til OSM-stakken i NFV-økosystemet.
   1. Utfør kommandoen "ro_id=$(docker ps | grep osm_ro | cut -d ' '-f 1)" for å identifisere IDen til beholderen som implementerer RO-modulen (Resource Orchestrator) i OSM-systemet. Denne modulen er ansvarlig for å samhandle med VIM-ene for å koordinere og tildele de nødvendige ressursene i distribusjonen av påfølgende nettverkstjenester.
   2. Få tilgang til RO-beholderen ved hjelp av kommandoen "docker exec -it $ro_id bash". Denne kommandoen bruker identifikatoren som ble oppnådd i utførelsen av forrige trinn.
   3. Kontroller at den nye VIM er inkludert i listen over tilgjengelige datasentre, ved hjelp av kommandoen "openmano datacenter-list". Det nye området skal vises i listen med samme navn som det som tidligere ble introdusert i trinn 3.4.2 med parameter.
   4. Før opp bildene som er lastet opp til VIM på det eksterne nettstedet, ved hjelp av kommandoen "openmano vim-image-list --datacenter ". parameter angir navnet som er valgt for å identifisere VIM i OSM-stakken. Hvis utførelsen av denne kommandoen er vellykket, er tilkoblingen til den eksterne VIM-en knivstukket. Kontroller at Ping Pong-bildene er inkludert i listen.
   5. Før opp nettverkene som er tilgjengelige på det nye nettstedet med kommandoen "openmano vim-net-list --datacenter ". Kontroller at kontrollleverandøren og dataleverandøren finnes.
6. Utfør en foreløpig validering av riktig integrering av det nye nettstedet ved hjelp av en prøvetjeneste som tilbys av OSM-fellesskapet (alt innholdet i denne forbindelse er inkludert i eksperimentrepositoriet). Til dette formålet vil kommandoene som er inkludert i følgende trinn, bli utført i utstyret som er vert for OSM-stakken.
   1. Start VNF-beskrivelsene (VNFDene) i OSM-stakken som kjører kommandoen osm vnfd-create " for hver av VNFF-ene som komponerer prøvetjenesten ( tilsvarer filnavnet til VNFD-pakken).
   2. Ombord på NS-beskrivelsen (NSD) for prøvetjenesten med kommandoen "osm nsd-create ", der indikerer filnavnet til NSD-pakken (i dette eksperimentet, ping_pong_ns.tar.gz)."
   3. Start instansingen av Ping Pong Network Service (NS) på de eksterne og sentrale stedene, ved hjelp av kommandoen osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config {vnf: [{member-vnf-index: '2', vim_account: }]}". parameter identifiserer VIM for det eksterne området i OSM-stakken. Alternativet "--config" angir at alle VNFer som komponerer tjenesten, må distribueres på det eksterne området som håndteres av denne VIM, bortsett fra VNF identifisert av indeks 2 i NS, som skal distribueres på det sentrale området (VIM for det sentrale området er angitt i parameter).
   4. Kontroller at NS er distribuert og at den har status ved hjelp av kommandoen "osm ns-list". Hvis instansieringen er vellykket, endres statusen til "READY".
   5. Kontroller IP-adressen til hver av de to VNF-ene med "osm vnf-list" (nødvendig for å logge inn på maskinene etterpå).
   6. Koble til hver VNF via SSH, ved hjelp av kommandoen "ssh fedora@" ( representerer IP-adressen til VNF å koble til, oppnådd i forrige trinn). Introduser passordet "fedora" når du blir bedt om det av SSH. Når de er logget inn på begge maskinene, sjekk grensesnittene deres ved hjelp av kommandoen "ip address show", og få IP-adressene på grensesnittene deres knyttet til dataleverandørnettverket (grensesnitt eth1 i begge VNFer). Fra en av VNF-ene utfører du en ping til den andre VNF-en ved hjelp av den eksterne IP-adressen i dataleverandørnettverket. Hvis det finnes tilkobling, anses den foreløpige valideringstesten som vellykket.

4. Validering av NFV multi-site plattform med en realistisk vertikal tjeneste

1. Last ned VNF-bildene fra det offentlige repositoriet og last dem opp til VIM på det tilsvarende nettstedet (se figur 3), etter prosedyren som er beskrevet i trinn 3.3.12. Spesielt vil det eksterne området være vert for tilgangspunkt VNF, ruter VNF, MQTT Gateway VNF og tilgangsruter VNF. Det sentrale området vil være vert for 5G Core VNF og IoT Server VNF.
2. Ombord på VNFD-ene og NSD for den smarte oppdrettstjenesten til OSM-stakken (alle beskrivelsene kan lastes ned fra eksperimentrepositoriet).
   1. Ombord på VNFDene til OSM-stakken som utfører kommandoen "osm vnfd-create ", for hver av VNFene til nettverkstjenesten. I dette tilfellet tilsvarer parameter filnavnet på VNFD-pakken.
   2. Ombord på NSD til OSM-stakken med kommandoen "osm nsd-create ", der indikerer filnavnet på NSD-pakken (i dette eksperimentet jove_uavs_scenario_nsd.tar.gz).
3. Distribuer den smarte farming-nettverkstjenesten. Til dette formålet kjører du følgende kommando fra kommandolinjegrensesnittet i OSM: 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 }'.
   MERK: Som angitt i trinn 3.6.3., angir og parametere stedene der VNF-ene skal distribueres. Spesielt vil alle VNF-ene som komponerer den smarte oppdrettstjenesten bli plassert på det nye eksterne nettstedet, bortsett fra de med indeks 5 og 6 (5G Core og IoT-server-VNFer) som vil bli tildelt det sentrale nettstedet.
4. Kontroller at NS er distribuert ved å følge samme fremgangsmåte som i trinn 3.6.4.
5. Tilgang til IoT-serveren VNF med kommandoen "ssh mosquittosubscriber@" og sjekk grensesnittet som er konfigurert til å kommunisere med MQTT Gateway VNF gjennom kommandoen "ip address show dev eth1". IP-adressen til VNF () kan hentes ved å utføre "osm vnf-listen" i OSM-kommandolinjen.
6. Etter en analog prosedyre, tilgang til MQTT Gateway VNF, og kjør kommandoen "sudo python3 publisher_MQTT_GW.py -ma -ba " der er oppnådd i forrige trinn, og utføring av kommandoen "ip address show dev eth1" i MQTT Gateway VNF. Dette trinnet initialiserer MQTT Gateway VNF, som vil motta data generert av sensoren ved hjelp av MQTT standard¹⁵, og overfører disse dataene til IoT-serveren VNF ved hjelp av samme standard.
7. Forbered en enkeltkorts datamaskin (SBC) som fester en meteorologisk sensor, og med transceiverkapasitet til å overføre sensoravlesninger mot MQTT Gateway VNF.
   MERK: For å eksemplifisere denne protokollen har spesielt en SBC-modell blitt brukt. Derfor kan følgende trinn måtte tilpasses i tilfelle du bruker en annen SBC-plattform.
   1. Koble (f.eks. ved hjelp av tinn loddede kobberledninger) bordpinnene på sensoren til gpiopinnene (general-purpose input/output) i SBC, etter konfigurasjonsskjemaet til figur 5.
   2. Aktiver I2C-kjernemodulen i SBC for å kunne bekrefte om sensoren oppdages. Til dette formål kjører du kommandoen "sudo raspi-config", følger sekvensen Interfacing Options -> I2C -> Ja i menyen som vises, og starter SBC på nytt for å gjøre endringene effektive.
   3. Kontroller at sensoren oppdages Installere programvaren i2c-verktøy i SBC, og utføre kommandoen "sudo i2cdetect -y 1". I så fall skal det vises et rutenett som angir posisjonen der sensoren registreres.
   4. Installer de aktuelle programvarebibliotekene for å tillate SBC-lesing og sending av dataene fra sensoren. Spesielt utnytter dette eksperimentet på RPi.bme280³² og paho-mqtt³³ Python biblioteker.
8. Bruk den mobile applikasjonen til SUAV, ta av luftfartøyet som er vert for tilgangspunktet VNF, og plasser det for å gi trådløs dekning til SBC med sensoren.
   MERK: Flyvningen til NFV-kompatible SUAVer er uavhengig av nettverkstjenestens operative oppførsel, som er i stand til å betjene om SUAVene flyr eller i en tilstand av repose for å redusere batteriforbruket. Dermed er trinn 4.8 valgfritt.
9. Fest SBC med ansvar for å lese dataene som samles inn av sensoren, til det trådløse Wi-Fi-tilgangspunktet fra tilgangspunktet VNF). Etter et vellykket vedlegg aktiveres en trådløs nettverksbane fra sensoren til MQTT Gateway VNF.
10. Start overføringen av sensordata ved å kjøre kommandoen "python3 /home/ubuntu/sensorDataTransmission.py -a " i SBC som inkorporerer sensoren ( er IP-adressen som er oppnådd i trinn 4.6.).
11. Få tilgang til web-GUI levert av IoT-serveren VNF for å sjekke riktig sanntidsmottak av de sansede dataene. Til dette formål kontrollerer du IP-adressen til IoT Server VNF med kommandoen "osm vnf-list", og skriver inn følgende URL-adresse (Uniform Resource Locator) i en nettleser: http://:3001, der er IP-adressen til IoT-serveren VNF. Klikk deretter på Sensor datainnsamling-knappen på Hjem-fanen, og bekreft sanntidsoppdateringen av grafene som er inkludert i dashbordet etter hvert som data mottas.
    MERK: For å kunne få tilgang til URL-adressen som er nevnt i trinn 4.12, må enheten med nettleseren som prøver å nå den ressursen, være koblet til NFV-økosystemet og ha IP-tilkobling med IoT Server VNF. VPN-tjenesten kan også brukes til dette formålet.
12. Vent i en passende tidsperiode for å få representative resultater av utførelsen av den smarte oppdrettstjenesten. Samle deretter inn dataene som er lagret i IoT-serveren VNF for videre analyse. Tatt i betraktning at sensoren som er inkludert i dette eksperimentet gir temperatur-, fuktighets- og trykkavlesninger hvert 5.
13. Få tilgang til databasen til IoT Server VNF for å hente de fornemme dataene for videre analyse. Til dette formålet, utfør kommandoen "id_database = $ (sudo docker ps | grep 'influxdb:' | klipp ut -d ' '-f 1)" på IoT Server VNF, og deretter "sudo docker exec -it $id_database bash"
14. Eksporter dataene til en kommadelt fil (CSV), som kjører kommandoen "tilstrømning -database "mainflux" -execute "SELECT * FROM messages WHERE \"name\" = "" -format csv > /tmp/.csv". Endre parameteren for å velge hvilken type sensordata som skal eksporteres med "temperatur", "fuktighet" eller "trykk", og angi parameter for å velge et navn for utdatafilen som beholder resultatene.
15. Lagre datafilene som ble generert i forrige trinn for senere representasjon (se delen Representative Resultater) og verifisering av riktig drift av den smarte oppdrettstjenesten.

Representative Results

Etter nøye å ha fulgt protokollen for å innlemme et nytt nettsted til den sentrale plattformen og kjøre en nettverkstjeneste for å validere riktig funksjonalitet, viser Figur 6 et skjermbilde av verktøyet for åpen VPN-skjerm. Det kan observeres hvordan det nye nettstedet bruker VPN-en for all kommunikasjon, og viser hvordan kommunikasjonen følger VPN-en for å tillate denne datautvekslingen og følgelig riktig tillegg av det nye nettstedet til VPN-tjenesten.

Som vist i figur 3,leverer nettverkstjenesten informasjon fra en sensor som er plassert i en ekstern infrastruktur, til serveren på det sentrale området. I tillegg viser figur 7 den vellykkede distribusjonen av nettverkstjenesten fra OSM-web-GUI, som viser hvordan eksperimentet kan startes riktig i den nye eksterne infrastrukturen fra MANO-stakken som ligger på det sentrale området. Videre er tiden som kreves i eksperimentet for å fullføre distribusjonen av tjenesten rundt åtte minutter. Denne verdien, sammen med tiden det tar å ombord tjenestebeskrivelsene i orkestreringsplattformen (omtrent 9 sekunder, med 1,3 sekunder per beskrivelse, med tanke på både NS- og hver VNF-beskrivelse), gjør det mulig å tilfredsstille KPI (Key Performance Indicator) på 90 minutter for tjenesteopprettingstiden, som angitt av 5G Infrastructure Public Private Partnership³⁴. I denne sammenhengen inkluderer arbeidet som presenteres i Vidal et al.⁹ en grundig analyse av tjenesteopprettingstiden med flere steder ved hjelp av den presenterte protokollen.

Figur 8 viser dataene som samles inn fra sensoren, inkludert verdiene for henholdsvis fuktighet, temperatur og trykk. Disse prøvene tilsvarer alle data som sendes fra sensoren til en ekstern server i 5TONIC, der disse verdiene er lagret i en database. Alle disse dataene viser at plattformen er i stand til å distribuere praktiske nettverkstjenester etter inkludering av en ny infrastruktur, samt å muliggjøre kommunikasjon mellom nettsteder på riktig måte.

Figur 1: Distribusjon av VPN-tjenesteområde. Distribusjon av VPN-tjenesten gjennom plattformen og deres koblingstilkobling (alle passerer gjennom 5TONIC). Klikk her for å se en større versjon av denne figuren.

Figur 2. Oversikt over plattformen og VPN-tjenesten. Denne figuren viser alle elementene i plattformen: den sentrale beliggenheten, sammen med NFV-infrastrukturen, VPN-tjenesten og en ny infrastruktur samlet til systemet. Det inkluderer også forbindelsene mellom elementene. Klikk her for å se en større versjon av denne figuren.

Figur 3: Oversikt over nettverkstjenesten. Den skildrer elementene som er involvert i nettverkstjenesten, dens distribusjon og dens logiske, og nettverk, tilkobling. Klikk her for å se en større versjon av denne figuren.

Figur 4: Protokollarbeidsflyter. Hver kolonne representerer én del av protokollen, der hver handling som utføres, beskrives, den logiske forbindelsen mellom dem og komponenten som har ansvaret for utførelsen. Klikk her for å se en større versjon av denne figuren.

Figur 5: Feste konfigurasjonsoppsett. Diagram som representerer hvordan du lager de fysiske forbindelsene mellom kortpinnene på sensorene og GPIO-pinnene til SBC som inkorporerer sensoren. Klikk her for å se en større versjon av denne figuren.

Figur 6: Øyeblikksbilde av OpenVPN-skjerm. Bildet viser at den aggregerte infrastrukturen er koblet til VPN-tjenesten, inkludert noen av detaljene angående tilkoblingen. Videre skildrer figuren også flere tilkoblinger som tilhører andre eksterne infrastrukturer. Klikk her for å se en større versjon av denne figuren.

Figur 7: OSM NS-distribusjonsstatus. OSM grafisk grensesnitt, som viser vellykket distribusjon av testnettverkstjenesten i den eksterne infrastrukturen. Klikk her for å se en større versjon av denne figuren.

Figur 8: Representativ analyse av dataene som samles inn av sensoren. (A) Illustrasjon av temperaturdataene som sensoren regelmessig har samlet inn hvert 5. (B) Grafisk fremstilling av fuktighetsdataene som samles inn av sensoren hvert 5. (C) Visuell fremstilling av trykkdataene sensoren samlet inn hvert 5. Klikk her for å se en større versjon av denne figuren.

Discussion

En av de viktigste aspektene ved den tidligere beskrevne protokollen er dens enestående fleksibilitet til å innlemme nye databehandlingsinfrastrukturer i et NFV-økosystem, uavhengig av distribusjon når det gjelder geografisk plassering (så lenge båndbredde og ventetid for nettverkskommunikasjonen med eksterne nettsteder støtter den). Dette er mulig gjennom en VPN-basert overleggsnettverksarkitektur, som gjør det mulig å opprette en virtuell kobling for å koble eksterne nettsteder til de sentrale lokalene til NFV-økosystemet. Denne tilnærmingen gjør det mulig for en effektiv og sikker kanal å støtte NFV og datakommunikasjon mellom nettsteder i et NFV-økosystem, noe som reduserer sannsynligheten for at eksterne parter får tilgang til og/eller endrer sensitiv informasjon om NFV-orkestreringsprosesser og data fra distribuerte tjenester. I denne sammenhengen beskriver protokollen også en spesifikk metodikk for å dele VPN-legitimasjonen sikkert med de eksterne nettstedene som vil muliggjøre integrering av nye infrastrukturer. Protokollen har blitt eksemplifisert ved hjelp av NFV-økosystemet som er gjort tilgjengelig ved 5TONIC av Universidad Carlos III de Madrid, Telefónica og IMDEA Networks Institute, selv om den er generisk å bli brukt i andre NFV-miljøer som tilfredsstiller de tidligere forutsetningene nevnt i trinn 1 i denne protokollen.

I tillegg er det verdt å understreke den eksklusive bruken av open source-verktøy og programvare for protokollimplementeringen. Til tross for de potensielt fordelaktige funksjonene som kan tilbys av forskjellige proprietære løsninger (f.eks. Fortinet³⁵), har bruken av åpen kildekode-utvikling lagt til rette for integrering av alle elementer som omfattes av protokollen på grunn av deres iboende egenskaper som kostnadseffektivitet, en omfattende programvarestøtte levert av åpen kildekode-samfunnet, og et høyt pålitelighetsnivå, bare for å nevne noen av dem. Videre kan bruken av åpen kildekode-teknologier også fremme synergier mellom komponenter av lignende art. For eksempel, for å overvåke VPN-tilkoblingsstatusen for klientene som bruker plattformen, kan VPN-tjenesten implementert i hele protokollen stole på open-vpn-skjermverktøyet³⁶ (et pythonbasert overvåkingsverktøy som er i stand til å interoperere med OpenVPN-servere).

På den annen side vurderer protokollspesifikasjonen forekomst av nettverkstjenester på tvers av forskjellige områder for valideringsformål. I denne forbindelse er det viktig å fremheve at distribusjon av tjenester på et gitt område er avhengig av tilgjengeligheten av databehandlings-, lagrings- og nettverksressurser på stedet, samt av spesialisert utstyr som kan være nødvendig for å utføre distribusjonen (f.eks. NFV-aktiverte SUAVer). Dette er ikke en begrensning i protokollen, og bør tas i betraktning av interessenter som er interessert i å reprodusere eksperimentet beskrevet i dette dokumentet.

Videre bør det bemerkes at tiden som kreves for å utføre distribusjonen av nettverkstjenester, avhenger sterkt av flere faktorer som nettverksbanen mellom orkestratoren og de forskjellige VIM-ene, ytelsen til datakommunikasjon mellom VIM og dens administrerte beregningsnoder, og også i den iboende karakteren av disse beregningsnodene (ikke bare på grunn av deres tilgjengelige databehandlingsressurser, men også teknologiene som er innlemmet for å utføre virtualisering av nettverksfunksjoner).

Til slutt, og gitt den enestående ytelsen som denne plattformen og VPN-tjenesten hadde på de europeiske prosjektene og samarbeidsarbeidene der den har blitt brukt så langt (f.eks. 5GINFIRE, 5GRANGE eller 5GCity, nevnt i innføringen av dette dokumentet), vil det bli ansett som et viktig element i fremvoksende europeiske prosjekter der Universidad Carlos III de Madrid, Telefónica og IMDEA Networks Institute deltar, for eksempel Horizon 2020 LABYRINTH, eller nasjonale prosjekter, 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/