JoVE Journal > Engineering
Summary
Abstract
Introduction
Protocol
Results
Discussion
Disclosures
Acknowledgements
Materials
References
italiano

Automatically Generated
Please note that all translations are automatically generated. Click here for the English version.
Engineering

Integrazione di infrastrutture di sperimentazione 5G in un ecosistema NFV multisito

Published: February 03, 2021
doi:
10.3791/61946
, , , , , , , , ,
1Department of Telematic Engineering,Universidad Carlos III de Madrid, 2Telefónica I+D, 3IMDEA Networks Institute

Summary

L’obiettivo del protocollo descritto è supportare l’incorporazione flessibile di infrastrutture di sperimentazione 5G in un ecosistema NFV multi-sito, attraverso un’architettura di rete overlay basata su VPN. Inoltre, il protocollo definisce come convalidare l’efficacia dell’integrazione, compresa una distribuzione di servizi verticali multi-sito con piccoli veicoli aerei compatibili con NFV.

Abstract

Network Function Virtualization (NFV) è stato considerato uno dei fattori chiave per la5a generazione di reti mobili, o 5G. Questo paradigma consente di ridurre la dipendenza da hardware specializzato per implementare telecomunicazioni e servizi verticali. A tal fine, si affida a tecniche di virtualizzazione per softwarize delle funzioni di rete, semplificandone lo sviluppo e riducendo i tempi e i costi di implementazione. In questo contesto, Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute hanno sviluppato un ecosistema NFV all’interno di 5TONIC, un centro di innovazione di rete aperto incentrato sulle tecnologie 5G, che consente la creazione di scenari di sperimentazione complessi e vicini alla realtà attraverso un insieme distribuito di infrastrutture NFV, che possono essere rese disponibili dalle parti interessate in diverse località geografiche. Questo articolo presenta il protocollo che è stato definito per incorporare nuovi siti NFV remoti nell’ecosistema NFV multisito basato su 5TONIC, descrivendo i requisiti sia per le infrastrutture esistenti che per quelle di nuova incorporazione, la loro connettività attraverso un’architettura di rete overlay e i passaggi necessari per l’inclusione di nuovi siti. Il protocollo è esemplificato attraverso l’incorporazione di un sito esterno all’ecosistema 5TONIC NFV. Successivamente, il protocollo descrive in dettaglio i passaggi di verifica necessari per convalidare un’integrazione del sito di successo. Questi includono l’implementazione di un servizio verticale multi-sito utilizzando un’infrastruttura NFV remota con piccoli veicoli aerei senza equipaggio (SUAV). Questo serve a mostrare il potenziale del protocollo per consentire scenari di sperimentazione distribuiti.

Introduction

L’introduzione della quinta generazione di reti mobili (5G) ha comportato la rivoluzione del settore delle telecomunicazioni dall’inizio del decennio, richiedendo agli operatori di telecomunicazioni di affrontare le specifiche molto più esigenti dei nuovi servizi e applicazioni di rete sviluppati sotto l’ombrello 5G1,2 . Queste nuove specifiche includono, ma non sono limitate a, aumenti della velocità dei dati, miglioramenti della latenza della trasmissione wireless e riduzione dei costi operativi. Tra le tecnologie che costituiscono le basi dei miglioramenti per questa nuova generazione, Network Functions Virtualization3 (NFV) è diventato uno dei suoi principali abilitatori. NFV fornisce la capacità di softwarize delle funzioni di rete, tradizionalmente inoltrando su hardware specializzato, utilizzando invece apparecchiature fisiche generiche, come i computer server in un data center. Con questo nuovo paradigma, gli operatori di telecomunicazioni e le industrie verticali possono implementare funzioni e servizi di rete come un insieme di componenti software e risparmiare sui costi sia nell’implementazione del servizio che nella manutenzione, oltre a facilitare un’elasticità dell’infrastruttura di rete molto più elevata. Questo approccio allevia o elimina la necessità di utilizzare dispositivi dedicati (e solitamente più complessi e meno riutilizzabili) per la maggior parte delle funzioni specifiche di rete e verticali e supporta un grado molto più elevato e denso di automazione operativa, riducendo così i costi di implementazione e manutenzione.

Prendendo in considerazione tutti i vantaggi che un ambiente NFV è in grado di fornire, è naturale che un gran numero di stakeholder rilevanti del settore delle telecomunicazioni siano stati sempre più coinvolti nella sperimentazione di nuove idee di servizio su ambienti NFV. In questo contesto, Telefónica e IMDEA Networks Institute hanno creato 5TONIC4, un laboratorio aperto di ricerca e innovazione incentrato sulle tecnologie 5G. Con sede a Madrid (Spagna), questo laboratorio ha una vasta gamma di tecnologie disponibili per ricercatori e partner per promuovere lo sviluppo e la convalida dei servizi 5G. In particolare, questo laboratorio ha una piattaforma NFV sperimentale in cui gli sviluppatori sono in grado di distribuire e testare le loro nuove applicazioni e servizi basati su NFV su un ecosistema NFV conforme a ETSI5. Pertanto, le conclusioni sperimentali sulle scelte progettuali e le proposte tecnologiche possono essere derivate in un ambiente realistico molto più flessibile rispetto alle reti di produzione. Questa piattaforma è stata progettata per supportare le attività di sperimentazione su più siti esterni, che possono essere interconnessi in modo flessibile a 5TONIC utilizzando un protocollo ben definito.

La soluzione tecnica adottata per l’ecosistema 5TONIC NFV prevede l’utilizzo di un singolo orchestratore NFV, implementato utilizzando il software Open Source MANO (OSM) ospitato da ETSI6. Questo è l’elemento incaricato di gestire e coordinare il ciclo di vita dei servizi di rete (NS). Questi servizi possono essere costruiti come una composizione di virtualizzate network/vertical functions (VNF), che possono essere implementati in uno qualsiasi dei siti integrati sulla piattaforma NFV. La progettazione dell’ecosistema 5TONIC NFV è stata realizzata nell’ambito del progetto H2020 5GINFIRE7,8,dove la piattaforma è stata utilizzata per supportare l’esecuzione di oltre 25 esperimenti, selezionati attraverso un processo competitivo di open call, su otto infrastrutture sperimentali verticali specifiche situate in Europa e una in Brasile, quest’ultima collegata tramite un collegamento transoceanico. Inoltre, la piattaforma è stata sfruttata per costruire un banco di prova NFV distribuito su scala nazionale, in Spagna, supportando le attività di sperimentazione nell’ambito del progetto spagnolo 5GCity9,10. Più recentemente, un ulteriore sito brasiliano è stato integrato nella piattaforma, per sostenere attività dimostrative congiunte nel contesto di una cooperazione di ricerca e innovazione stabilita tra il Brasile e l’Europa (ad esempio, il progetto 5GRANGE11,12). Ultimo ma non meno importante, l’infrastruttura è stata utilizzata per supportare esperimenti di terze parti nell’ambito del progetto 5G-VINNI13,14. La distribuzione geografica della piattaforma NFV può essere vista nella Figura 1.

Le organizzazioni interessate che ospitano la propria infrastruttura NFV possono connettersi in modo flessibile all’ecosistema 5TONIC NFV, previa approvazione del comitato direttivo 5TONIC, diventare fornitori di banchi di prova all’interno dell’ecosistema distribuito ed essere coinvolte in attività congiunte di sperimentazione e dimostrazione. A tal fine, devono essere dotati di un VIM (Virtual Infrastructure Manager) conforme allo stack software OSM. L’orchestratore NFV 5TONIC è in grado di interagire con le VM nei siti coinvolti in una determinata implementazione del servizio, coordinando l’allocazione e la configurazione delle risorse di calcolo, storage e rete necessarie per l’istanziazione e l’interconnessione delle VNF che compongono un servizio di rete e controllandone il ciclo di vita, dal suo on-boarding al suo decommissioning finale.

Al fine di gestire lo scambio di controllo e traffico dati all’interno di tutti i siti interconnessi, l’ecosistema 5TONIC NFV si avvale di un’architettura di rete overlay basata su Virtual Private Networks (VPN). Questo approccio fornisce un accesso sicuro basato su PKI ai siti esterni integrati nell’ecosistema 5TONIC, consentendo lo scambio di informazioni di controllo NFV tra lo stack software OSM e le diverse VIM distribuite tra i banchi di prova, nonché lo scambio di informazioni necessarie per gestire e configurare tutte le VNF. Inoltre, questa rete di overlay supporta la diffusione del traffico dati tra VNF che vengono distribuiti in siti diversi.

In questo contesto, questo documento descrive in dettaglio il protocollo progettato per incorporare un sito esterno a un ecosistema NFV. Il protocollo presuppone che l’ecosistema sia governato da un singolo agente di orchestrazione NFV, installato in un sito centrale, e che i siti esterni presentino una soluzione VIM conforme allo stack software dell’orchestratore. Il protocollo proposto consente di incrementare il portafoglio di risorse dell’ecosistema sperimentale, con l’incorporazione flessibile di siti NFV e infrastrutture verticali-specifiche. Ciò consente la creazione di una piattaforma MANO distribuita in grado di testare e convalidare nuovi servizi di rete e verticali su più siti, sotto il controllo di un singolo orchestratore NFV. Al fine di illustrare il funzionamento interno del protocollo, il processo sarà esemplificato aggiungendo un sito NFV esterno all’attuale ecosistema 5TONIC NFV, descrivendo i componenti necessari nel sito esterno e 5TONIC, nonché tutti i passaggi da intraprendere durante il processo di integrazione. La Figura 2 fornisce una panoramica dell’obiettivo dell’integrazione, con il nuovo banco di prova basato su NFV collegato alla piattaforma 5TONIC da cui possono essere implementati i servizi di rete, tramite connessioni VPN tra il sito centrale e il resto delle infrastrutture esterne.

Inoltre, per mostrare l’efficacia del protocollo, verrà mostrato l’implementazione di un semplice servizio verticale, utilizzando l’ecosistema 5TONIC e un sito esterno con piccoli veicoli aerei senza equipaggio (SUAV) capaci di NFV. Il design del servizio verticale è stato ispirato da un esperimento presentato in Vidal et al.9, che è stato semplificato ai fini illustrativi di questo articolo. La figura 3 delinea il servizio, che mira ad aiutare le attività di agricoltura intelligente in un’area remota. Il servizio considera un fornitore di servizi di agricoltura intelligente che utilizza i SOCAV per raccogliere e diffondere i dati prodotti dai sensori meteorologici sparsi su un campo coltivato. Per semplicità, l’esperimento presentato nel documento considera un singolo SUAV e un sensore, in grado di fornire misurazioni di temperatura, umidità e pressione. Nell’esperimento, il sito NFV esterno ospita un punto di accesso Wi-Fi distribuito come VNF sul SUAV. Questo VNF offre connettività di accesso alla rete al sensore, inoltrando i dati rilevati verso una funzione gateway. Quest’ultimo è schierato come VNF su un’apparecchiatura di terra (un mini-computer ITX). La diffusione dei dati dal sensore alla funzione gateway segue un approccio Publish/Subscribe basato sul protocollo MQTT (Message Queuing Telemetry Transport)15. La funzione gateway elabora e quindi diffonde i dati verso un server Internet-of-things (IoT), che viene reso disponibile come VNF presso il sito centrale dell’ecosistema NFV, basato sulla piattaforma open source Mainflux16. Infine, lo scenario presuppone un’area remota in cui la connettività Internet è fornita da una rete di accesso cellulare non 3GPP. Quindi, il servizio include due VNF aggiuntivi: 1) un router di accesso VNF, che implementa lo stack di protocollo user-plane di un’apparecchiatura utente 3GPP collegata a una rete di accesso non 3GPP17; e 2) un’implementazione di base di una rete core 5G, che supporta l’inoltro delle informazioni tra il router di accesso e le VNF del server IoT. A tale scopo, il VNF core 5G fornisce un’implementazione semplificata del piano utente di una funzione di interlavoro non 3GPP e di una funzione del piano utente, come definito da 3GPP17.

Infine, la Figura 4 rappresenta i processi più rilevanti coinvolti durante lo sviluppo del protocollo, evidenziando le loro interconnessioni logiche e le entità incaricate della loro esecuzione.

Protocol

1. Messa a disposizione del sito centrale dell’ecosistema NFV (requisiti preliminari dell’esperimento) Allocare uno spazio di indirizzi IP che deve essere utilizzato dal sito centrale. Ai fini di questo protocollo, verrà utilizzato lo spazio di indirizzi privati 10.4.0.0/16. Installare lo stack software mano (Management and Orchestration) nel sito centrale. In particolare, l’esperimento effettuato in tutto questo protocollo utilizza l’Open Source MANO (OSM) Release SEVEN18, che richiede le seguenti risorse: Ubuntu 18.04 come sistema operativo, 2 Central Processing Unit (CPU), 8 GB di Random-Access Memory (RAM), 40 GB hard-drive-disk e almeno un’interfaccia di rete con accesso a Internet. Per l’installazione, seguire le istruzioni disponibili nella documentazione18di OSM Release SEVEN . Configurare un Virtual Infrastructure Manager (VIM) compatibile con OSM nel sito centrale. Nello specifico, l’esperimento utilizza OpenStack release Ocata20, in esecuzione su una macchina virtuale (VM) con Ubuntu 16.04 , 4 CPU, 16 GB di RAM e 200 GB di disco rigido. L’infrastruttura NFV (NFVI) gestita da questo VIM comprende tre computer server, ciascuno con Ubuntu 16.04, 8 CPU, 32 GB di RAM e 2 TB di spazio di archiviazione. Per l’installazione, seguire la documentazione di rilascio di Ocata21. Distribuire una rete virtuale all’interno della piattaforma cloud OpenStack, utilizzando un intervallo di indirizzi IP dallo spazio di indirizzi allocato nel passaggio 1.1. Questa rete, d’ora in poi denominata rete di gestione, sarà utilizzata per supportare lo scambio di informazioni di orchestrazione NFV tra l’OSM e le funzioni di rete virtuale (VNF) istanziate nel sito centrale. Configurare una rete virtuale (d’ora in poi denominata come rete dati) per supportare le comunicazioni di dati tra siti, tra le VNF del sito centrale e altre VNF eseguite in siti esterni. A tal fine, utilizzare un intervallo di indirizzi IP dallo spazio degli indirizzi del passaggio 1.1.NOTA: L’implementazione delle reti menzionate nei passaggi 1.3.1 e 1.3.2 è stata effettuata utilizzando le reti provider di OpenStack. Le reti del provider devono essere collegate all’infrastruttura di rete fisica del sito centrale per garantire un funzionamento appropriato. Connetti sia le reti private virtuali (cioè la gestione e le reti dati), sia le macchine VIM e OSM, a un’apparecchiatura che fornisce funzionalità di edge routing. Questo router fungerà da punto di ingresso al sito centrale dell’ecosistema NFV. Rendere disponibile un repository pubblico di esperimenti per fornire tutto il contenuto necessario per eseguire l’esperimento. In particolare, questo protocollo utilizza il repository pubblico a22. 2. Configurazione del servizio di rete privata virtuale Allocare uno spazio di indirizzi IP per supportare il funzionamento appropriato dell’ecosistema multisito, in modo che le comunicazioni di rete possano essere effettivamente stabilite tra più siti.NOTA: l’abilitazione di comunicazioni di rete efficaci tra più siti richiede un’attenta progettazione dello spazio degli indirizzi IP da utilizzare dall’ecosistema NFV e da siti esterni che devono connettersi ad esso. In particolare, lo spazio di indirizzi assegnato per le comunicazioni tra siti non dovrebbe entrare in conflitto con lo spazio di indirizzi già in uso in ogni altro sito per altri scopi. Allocare uno spazio di indirizzi IP per l’utilizzo da parte di siti esterni. Gli indirizzi in questo blocco verranno assegnati alle entità NFV (ad esempio, VIM) e VNF del sito esterno. Per esemplificare questo protocollo, verrà utilizzato lo spazio di indirizzi privati 10.154.0.0/16. Allocare uno spazio di indirizzi IP ai collegamenti virtuali tra i siti esterni e l’ecosistema NFV. Questi collegamenti virtuali saranno supportati da un servizio VPN. Per esemplificare questo protocollo, l’intervallo di indirizzi 10.154.254.0/24 verrà utilizzato per questi collegamenti virtuali. Configurare un’apparecchiatura per fornire il servizio VPN (Virtual Private Network), ovvero un server VPN. In particolare, l’esperimento utilizza un computer server con Ubuntu 16.04 (immagine variante a 64 bit), sei CPU indipendenti, 16 GB di RAM, disco di archiviazione da 1 TB e due interfacce di rete. Configurare una delle interfacce di rete del server VPN per consentire la ricezione di richieste di connessione da siti esterni tramite Internet. A tal fine, è necessario utilizzare un’interfaccia del server configurata con un indirizzo IP pubblico. Configurare il collegamento tra il server VPN e il router perimetrale del sito centrale. Nell’esperimento a questo collegamento è stato assegnato l’intervallo di indirizzi 10.4.255.0/24. Configurare le route di rete appropriate sul server VPN, in modo che l’ecosistema NFV diventi accessibile da siti esterni connessi al servizio VPN. Installa il software open source VPN fornito dal progetto OpenVPN23 nel server VPN. In particolare, questo esperimento utilizza OpenVPN versione 2.3.10 e la sua distribuzione è stata eseguita con lo script bash “openvpn-install.sh”, disponibile in http://github.com/Nyr/openvpn-install (altre opzioni di installazione sono descritte nella documentazione OpenVPN 24). Lo script bash presenta i parametri alternativi che comporteranno la configurazione del servizio VPN. Selezionare l’indirizzo IP per ascoltare le richieste di connessione VPN (ad esempio, l’indirizzo IP pubblico). Decidi quale protocollo (UDP o TCP) deve essere utilizzato per guidare le comunicazioni tramite la VPN. In questo caso, l’esperimento sfrutta UDP che è il protocollo consigliato. Specificare la porta che comprenderà il duple (insieme all’indirizzo IP pubblico) che verrà utilizzato per ricevere le richieste di connessione al servizio. Per impostazione predefinita, il valore assegnato è 1194. Scegliere uno dei server DNS dell’elenco richiesto dall’assistente che gestirà le richieste di risoluzione dei nomi eseguite dai client del servizio VPN. Premere un tasto qualsiasi per abilitare l’avvio automatico del processo di installazione del servizio VPN. Modificare il file di configurazione “server.conf” che si trova nella directory “/etc/openvpn/server/” e includere la direttiva “client-to-client” che mira ad estendere l’installazione di base fornita dal passaggio 2.3. Pertanto, diversi client connessi al servizio VPN saranno in grado di raggiungersi. Abilitare la configurazione del singolo client all’interno della configurazione VPN per poter gestire in modo indipendente le assegnazioni di routing per ogni client. Aggiungere la direttiva “client-config-dir ccd”, modificando lo stesso file di configurazione del passaggio 2.4. Creare la directory “ccd” utilizzando il comando “mkdir /etc/openvpn/ccd/”. Questa directory servirà durante la sezione successiva del protocollo per posizionare i file che comprendono le direttive di routing associate ai client destinati ad essere integrati all’interno della piattaforma. Impostare le regole del firewall necessarie per consentire le connessioni con il servizio, proteggendo al contempo il server VPN da attacchi dannosi. A tal fine, questo esperimento sfrutta iptables25, che è un’utilità a riga di comando sviluppata per configurare il firewall del kernel Linux. Innanzitutto, blocca il traffico in entrata verso il server VPN con il comando “iptables -P INPUT DROP”. Consentire la ricezione delle richieste di connessione VPN con i comandi “iptables -A INPUT -i -m state –state NEW -p udp –dport 1194 -j ACCEPT” ( è il nome dell’interfaccia server VPN con l’indirizzo IP pubblico) e “iptables -A INPUT -i tun+ -j ACCEPT”. Consentire l’inoltro del traffico tra le interfacce server VPN (ad esempio, l’interfaccia pubblica e l’interfaccia virtuale creata dal servizio VPN denominato tun0), per consentire al server VPN di elaborare la richiesta di connessione al servizio. A tale scopo, eseguire il comando “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”. Consentire al server VPN di fornire la funzionalità NAT (Network Address Translation) con l’obiettivo di fornire l’accesso a Internet al sito centrale, eseguendo: “iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE && iptables -A OUTPUT -o tun+ -j ACCEPT”. 3. Integrazione di un sito NFV esterno Ottenere un intervallo di indirizzi IP appropriato per integrare il sito nell’ecosistema NFV. Questo intervallo di indirizzi sarà fornito dal centro operativo di rete dell’ecosistema NFV. Secondo il passaggio 2.1.1 di questo protocollo, l’esperimento utilizzerà un intervallo di indirizzi IP per il sito esterno entro 10.154.0.0/16. Creare e fornire le credenziali di sicurezza per connettersi all’ecosistema NFV. Generare una credenziale VPN che consentirà alla nuova infrastruttura di stabilire una connessione sicura con il server VPN. A tale scopo, eseguire il comando “bash openvpn-install.sh” nel server VPN, selezionare l’opzione “1) Aggiungi un nuovo client” dell’elenco richiesto e fornire il nome da associare a tale credenziale, ad esempio uc3m_infrastructure. Questo passaggio genererà un file con le credenziali VPN (denominato “uc3m_infrastructure.ovpn” nell’esempio). Creare un file di testo nella directory “/etc/openvpn/ccd/” del server VPN, incluse le direttive di routing (come specificato nella documentazione OpenVPN 24) che devono essere inviate dal server VPN ogni volta che viene stabilita una connessione al servizio VPN utilizzando le credenziali VPN.NOTA: il nome del file di testo deve corrispondere al nome specificato durante la creazione della credenziale VPN (ad esempio, uc3m_infrastructure) per fornire una configurazione personalizzata per ogni client VPN. Fornire il file di credenziali VPN allo staff tecnico del sito esterno. Questo deve essere fatto attraverso un canale sicuro e affidabile. In questo esperimento viene utilizzato un processo di crittografia manuale. Per crittografare le credenziali VPN, eseguire il comando “7za a -tzip ‘-p’ -mem=AES256 “, impostando come chiave di crittografia desiderata, come nome scelto per il file crittografato e come nome file del file di credenziali VPN (ad esempio, uc3m_infrastructure.ovpn). Fornire la credenziale crittografata allo staff tecnico del nuovo sito, insieme alla chiave che consente le procedure di decrittazione, attraverso un canale di comunicazione sicuro.NOTA: In questo esperimento, le credenziali crittografate sono state fornite tramite posta elettronica, mentre la chiave di decrittografia è stata inviata attraverso un canale separato, utilizzando il servizio di messaggi brevi (SMS), con un accordo offline del numero di telefono. Impostare l’ambiente nel nuovo sito, in modo da stabilire la connessione con l’ecosistema NFV e consentire il collegamento dell’NFVI remoto allo stack OSM del sito centrale.Installare il software VPN fornito da OpenVPN24 in un computer, per abilitare un collegamento virtuale tra il sito esterno e il sito centrale dell’ecosistema NFV. Il computer con il software OpenVPN fungerà da client VPN o endpoint VPN nel sito esterno. Il collegamento virtuale sarà realizzato per mezzo di un tunnel VPN protetto tra l’endpoint VPN e il server VPN. Nell’esperimento, l’endpoint VPN viene eseguito in un computer server con Ubuntu 18.04, 8 CPU, 8 GB di RAM, 128 GB di disco di archiviazione e interfacce 3 GbE (una per la connessione con il servizio VPN su Internet). Attivare l’inoltro IP nell’endpoint VPN per supportare le funzionalità di routing di rete. A tal fine, includere la riga “net.ipv4.ip_forward=1” nel file di configurazione del sistema situato nel percorso “/etc/sysctl.conf” e caricare la configurazione aggiornata con il comando “sudo sysctl -p”. Decrittografare il file di credenziali VPN con le informazioni ricevute nel passaggio 3.2.4, utilizzando il comando “7za e “, dove il è il nome del file della credenziale VPN crittografata. Specificare la chiave di decrittografia quando richiesto dal comando. Avviare il software OpenVPN con il file di credenziali decrittografato utilizzando il comando “sudo openvpn –config ” ( è il nome file della credenziale VPN). Con questo, l’endpoint VPN si autenticherà al server VPN e riceverà automaticamente i parametri di configurazione VPN appropriati e le route di rete. In questo modo, l’endpoint VPN si comporterà come un router edge con un collegamento virtuale al sito centrale dell’ecosistema NFV. Verificare il corretto funzionamento dell’endpoint VPN, utilizzando il comando ping per verificare la disponibilità di connettività a uno dei nodi del sito centrale (ad esempio, l’apparecchiatura stack OSM). Nel nuovo sito, selezionare un VIM conforme OSM per consentire le operazioni con la piattaforma MANO. Per questo esperimento, viene utilizzata la versione di OpenStack Ocata.NOTA: OSM Release SEVEN supporta i seguenti gestori di infrastrutture virtuali: OpenStack, OpenVIM26, vCloud Director27di VMware, Amazon Web Service28,Microsoft Azure29ed Eclipse fog0530 (vedere la documentazioneOSM 18 per dettagli specifici sulla configurazione). Installare OpenStack release Ocata20 (vedere le procedure dettagliate nella documentazione di rilascio21). Distribuire l’infrastruttura NFV nel sito esterno e collegarla al VIM. In particolare, questo esperimento utilizza un’infrastruttura NFV composta da tre computer a scheda singola (SBC), ciascuno con una capacità di calcolo di 1 GB di RAM, 4 CPU e 32 GB di disco di archiviazione; e un singolo computer mini-ITX con 8 CPU, 8 GB di RAM e 128 GB per l’archiviazione.NOTA: Il sito esterno esemplificato in questo protocollo si basa su un’infrastruttura NFV di piccoli veicoli aerei senza equipaggio (SUAV) compatibili con NFV. I dettagli seguiti per abilitare tale infrastruttura sono forniti in Nogales et al31. I passaggi da 3.3.6 a 3.3.8 sono facoltativi, poiché un’infrastruttura NFV potrebbe già esistere nel sito esterno. Creare un progetto OpenStack per specificare l’insieme di risorse computazionali del sito esterno che verranno integrate nell’ecosistema NFV. Per fare ciò, accedere all’interfaccia utente grafica (GUI) fornita da OpenStack, accedere al sistema con le credenziali di amministratore, fare clic sul pulsante + Crea progetto della scheda Identità -> Progetti e creare un progetto completando il modulo visualizzato con le informazioni richieste. Creare un utente valido che gestirà il progetto creato nel passaggio precedente. A tale scopo, accedere alla scheda Identità -> Utenti con lo stesso login del passaggio precedente, fare clic su + Crea utente e compilare i campi obbligatori del modulo visualizzato (nome utente e password), selezionando il nuovo progetto creato come progetto principale e scegliendo il ruolo di amministratore. Modificare le regole di sicurezza per consentire le autorizzazioni di comunicazione VNF nel nuovo sito (in particolare, abilitare il traffico SSH e ICMP). A tal fine, accedere alla GUI openStack con le credenziali dell’utente creato nel passaggio precedente, seguire la sequenza: Project -> Network -> Security Groups -> + Add Rulee selezionare l’opzione SSH del menu a discesa Rule. Ripetere il processo ma selezionando l’opzione Tutti ICMP inclusa nel menu a discesa. Scarica le immagini di un servizio di prova offerto dalla comunità OSM, il servizio di rete Ping Pong (“Fedora-x86_64-20-20131211.1-sda-ping” e “Fedora-x86_64-20-20131211.1-sda-pong”) dal repository pubblico degli esperimenti, e caricale sul VIM del sito esterno. A questo scopo, seguire la sequenza Project -> Compute -> Images -> + Create Image, e creare le immagini utilizzando il modulo visualizzato e selezionando ciascuna delle immagini. Assegnare due intervalli di indirizzi IP all’interno dello spazio degli indirizzi del sito esterno (allocati nel passaggio 3.1). Questi intervalli saranno utilizzati per supportare la gestione delle VNF del sito esterno e per consentire la comunicazione dei dati tra siti tra VNF, rispettivamente. Creare una rete provider (control-provider) utilizzando VIM. Questa rete supporterà le comunicazioni NFV tra lo stack OSM nel sito centrale e i VNF distribuiti nel nuovo sito per scopi di gestione. Questo tipo di comunicazioni consentirà inoltre allo stack OSM di configurare le VNF dopo la loro distribuzione. Per creare una rete provider in OpenStack, seguire la sequenza Admin -> System -> Networks -> + Create Network e compilare i dettagli della nuova rete, utilizzando l’intervallo di indirizzi IP selezionato nel passaggio precedente. Creare una seconda rete di provider(data-provider)utilizzando VIM. Questa rete supporterà le comunicazioni di dati tra le VNF del sito e altre VNF dell’ecosistema NFV. Per creare questa rete di provider in OpenStack, seguire la sequenza Admin -> System -> Networks -> + Create Networke compilare i dettagli della nuova rete utilizzando l’intervallo di indirizzi assegnato.NOTA: le istruzioni su come creare reti virtuali variano a seconda del software VIM. Controllare la rispettiva documentazione del software per i dettagli. Condividere le informazioni relative a VIM (in particolare, il nome utente/password e il progetto creato nei passaggi 3.3.9 e 3.3.10) con lo staff tecnico del sito centrale, per consentire l’inserimento del VIM allo stack software OSM. Collegare l’infrastruttura NFV esterna allo stack software OSM del sito centrale, utilizzando le informazioni ottenute dal passaggio 3.3.16. Verificare la connettività tra lo stack OSM del sito centrale e il VIM del nuovo sito, utilizzando lo strumento ping. Se il test di connettività precedente ha esito positivo, collegare il VIM esterno allo stack OSM del sito centrale. A tale scopo, utilizzare il seguente comando nella macchina OSM: “osm vim-create –name –user –password –auth_url –tenant –account_type “. In questo comando: è il nome selezionato per identificare il VIM all’interno dello stack OSM, è il nome dell’utente autorizzato a gestire le risorse del sito esterno (vedi passaggio 3.3.10), è la password dell’utente indicato, è il link all’API resa disponibile dal VIM per abilitare le richieste dallo stack OSM, è il nome del progetto definito nel passaggio 3.3.9 e è il software VIM utilizzato (in questo esperimento, OpenStack). Verificare l’attacco appropriato del nuovo VIM allo stack OSM dell’ecosistema NFV. Eseguire il comando “ro_id=$(docker ps | osm_ro | grep cut -d ‘ ‘ -f 1)” per identificare l’id del contenitore che implementa il modulo Resource Orchestrator (RO) all’interno del sistema OSM. Questo modulo è responsabile dell’interazione con i VIM al fine di coordinare e allocare le risorse necessarie nell’implementazione dei successivi servizi di rete. Accedere al contenitore RO utilizzando il comando “docker exec -it $ro_id bash”. Questo comando utilizza l’identificatore ottenuto nell’esecuzione del passaggio precedente. Verificare che il nuovo VIM sia incluso nell’elenco dei datacenter disponibili, utilizzando il comando “openmano datacenter-list”. Il nuovo sito dovrebbe apparire nell’elenco con lo stesso nome di quello introdotto in precedenza nel passaggio 3.4.2 con il parameter. Elencare le immagini che sono state caricate sul VIM del sito esterno, utilizzando il comando “openmano vim-image-list –datacenter “. Il parametro indica il nome selezionato per identificare il VIM all’interno dello stack OSM. Se l’esecuzione di questo comando ha esito positivo, la connettività con il VIM esterno è stata stabilita correttamente. Controlla che le immagini di Ping Pong siano incluse nell’elenco. Elencare le reti disponibili nel nuovo sito con il comando “openmano vim-net-list –datacenter “. Verificare che siano presenti provider di controllo e provider di dati. Eseguire una validazione preliminare della corretta integrazione del nuovo sito, utilizzando un servizio di prova offerto dalla community OSM (tutti i contenuti al riguardo sono inclusi all’interno del repository dell’esperimento). A tale scopo, i comandi inclusi nei passaggi seguenti verranno eseguiti nell’apparecchiatura che ospita lo stack OSM. Eseguire l’onboarding dei descrittori VNF (VNFD) nello stack OSM eseguendo il comando “osm vnfd-create ” per ciascuno dei VNF che compongono il servizio di prova ( corrisponde al nome file del pacchetto VNFD). Onboarding del descrittore NS (NSD) del servizio di prova con il comando “osm nsd-create “, dove indica il nome del file del pacchetto NSD (in questo esperimento, ping_pong_ns.tar.gz).” Avviare l’istanza di Ping Pong Network Service (NS) sui siti esterni e centrali, utilizzando il comando “osm ns-create –ns_name –nsd_name ping_pong_ns –vim_account –config ‘{vnf: [{member-vnf-index: ‘2’, vim_account: }]}'”. Il parameter identifica il VIM del sito esterno all’interno dello stack OSM. L’opzione “–config” indica che tutte le VNF che compongono il servizio devono essere distribuite sul sito esterno gestito da tale VIM, ad eccezione del VNF identificato dall’indice 2 nel NS, che verrà distribuito nel sito centrale (il VIM del sito centrale è specificato nel parameter). Verificare che NS sia stato distribuito e il suo stato utilizzando il comando “osm ns-list”. Se l’istanza ha esito positivo, lo stato cambierà in “PRONTO”. Controllare l’indirizzo IP di ciascuno dei due VNF con “osm vnf-list” (necessario per accedere alle macchine in seguito). Connettersi a ciascun VNF tramite SSH, utilizzando il comando “ssh fedora@” ( rappresenta l’indirizzo IP del VNF a cui connettersi, ottenuto nel passaggio precedente). Introdurre la password “fedora” quando richiesto da SSH. Una volta effettuato l’accesso a entrambe le macchine, controllare le loro interfacce utilizzando il comando “ip address show” e ottenere gli indirizzi IP sulle loro interfacce collegate alla rete del provider di dati (interfaccia eth1 in entrambe le VNF). Da uno dei VNF, eseguire un ping all’altro VNF, utilizzando l’indirizzo IP remoto nella rete del provider di dati. Se c’è connettività, il test di convalida preliminare sarà considerato riuscito. 4. Validazione della piattaforma multisito NFV con un servizio verticale realistico Scaricare le immagini VNF dal repository pubblico e caricarle nel VIM del sito corrispondente (vedere Figura 3), seguendo la procedura descritta nel passaggio 3.3.12. In particolare, il sito esterno ospiterà Access Point VNF, Router VNF, MQTT Gateway VNF e Access Router VNF. Il sito centrale ospiterà il 5G Core VNF e l’IoT Server VNF. Onboard dei VNFD e NSD del servizio smart farming nello stack OSM (tutti i descrittori possono essere scaricati dal repository dell’esperimento). Onboarding dei VNFD allo stack OSM eseguendo il comando “osm vnfd-create “, per ciascuno dei VNF del servizio di rete. In questo caso, il parametro corrisponde al nome file del pacchetto VNFD. Onboarding dell’NSD nello stack OSM con il comando “osm nsd-create “, dove indica il nome del file del pacchetto NSD (in questo esperimento, jove_uavs_scenario_nsd.tar.gz). Implementa il servizio di rete per l’agricoltura intelligente. A tale scopo, eseguire il seguente comando dall’interfaccia della riga di comando 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 }’.NOTA: come indicato nel passaggio 3.6.3., i parametri e indicano i siti in cui devono essere distribuiti i VNF. In particolare, tutte le VNF che compongono il servizio di smart farming saranno collocate nel nuovo sito esterno, ad eccezione di quelle con indice 5 e 6 (il Core 5G e le VNF server IoT)che saranno allocate al sito centrale. Verificare che il NS sia stato distribuito, seguendo la stessa procedura del passaggio 3.6.4. Accedi al server IoT VNF con il comando “ssh mosquittosubscriber@” e controlla la sua interfaccia configurata per comunicare con MQTT Gateway VNF tramite il comando “ip address show dev eth1”. L’indirizzo IP del VNF () può essere ottenuto eseguendo la “osm vnf-list” nella riga di comando OSM. Seguendo una procedura analoga, accedere al gateway MQTT VNFed eseguire il comando “sudo python3 publisher_MQTT_GW.py -ma -ba ” dove il è ottenuto nel passaggio precedente e il esecuzione del comando “ip address show dev eth1” nel VNF del gateway MQTT. Questo passaggio inizializza il gateway MQTT VNF, che riceverà i dati generati dal sensore utilizzando lo standard MQTT15, trasmettendo questi dati al server IoT VNF utilizzando lo stesso standard. Preparare un Single Board Computer (SBC) che colleghi un sensore meteorologico e con capacità ricetrasmettitore di trasmettere le letture del sensore verso il VNF del gateway MQTT.NOTA: per esemplificare questo protocollo, è stato utilizzato un modello SBC in particolare. Pertanto, potrebbe essere necessario adattare i seguenti passaggi in caso di utilizzo di una piattaforma SBC diversa. Collegare (ad esempio, utilizzando fili di rame saldati a stagno) i pin della scheda del sensore ai pin di ingresso/uscita generici (GPIO) dell’SBC, seguendo lo schema di configurazione della Figura 5. Abilitare il modulo kernel I2C nell’SBC per poter verificare se il sensore viene rilevato. A tale scopo, eseguire il comando “sudo raspi-config”, seguire la sequenza Opzioni di interfacciamento -> I2C -> Sì nel menu visualizzato e riavviare l’SBC per rendere effettive le modifiche. Verificare che il sensore sia rilevato Installazione del software i2c-tools nel SBC ed esecuzione del comando “sudo i2cdetect -y 1”. In tal caso, dovrebbe apparire una griglia che indica la posizione in cui viene rilevato il sensore. Installare le librerie software appropriate per consentire all’SBC di leggere e inviare i dati forniti dal sensore. In particolare, questo esperimento sfrutta le librerie Python RPi.bme28032 e paho-mqtt33. Utilizzando l’applicazione mobile del SUAV, togliere il veicolo aereo che ospita l’Access Point VNFe posizionarlo per fornire copertura wireless al SBC con il sensore.NOTA: Il volo dei SOV compatibili con NFV è indipendente dal comportamento operativo del servizio di rete, che è in grado di operare sia che i SUAV siano in volo o in uno stato di riposo per mitigare il consumo della batteria. Pertanto, il passaggio 4.8 è facoltativo. Collegare l’SBC incaricato di leggere i dati raccolti dal sensore al punto di accesso wireless Wi-Fi fornito dall’Access Point VNF). Dopo un attacco riuscito, un percorso di rete wireless verrà abilitato dal sensore al gateway MQTT VNF. Avviare la trasmissione dei dati rilevati, eseguendo il comando “python3 /home/ubuntu/sensorDataTransmission.py -a ” nel SBC che incorpora il sensore ( è l’indirizzo IP ottenuto nel passaggio 4.6.). Accedi alla web GUI fornita dal server IoT VNF per verificare la corretta ricezione in tempo reale dei dati rilevati. A tal fine, controllare l’indirizzo IP del VNF del server IoT con il comando “osm vnf-list” e digitare il seguente UNIFORM Resource Locator (URL) in un browser Web: http://:3001, dove è l’indirizzo IP del server IoT VNF. Quindi, fai clic sul pulsante Raccolta dati sensori della scheda Home e verifica l’aggiornamento in tempo reale dei grafici inclusi nella dashboard man mano che i dati vengono ricevuti.NOTA: per poter accedere all’URL menzionato nel passaggio 4.12, il dispositivo con il browser Web che tenta di raggiungere tale risorsa deve essere connesso all’ecosistema NFV e disporre di connettività IP con il VNF del server IoT. Il servizio VPN può essere utilizzato anche per questo scopo. Attendere un periodo di tempo adeguato per ottenere risultati rappresentativi dell’esecuzione del servizio di smart farming. Quindi, raccogliere i dati archiviati nel server IoT VNF per ulteriori analisi. Considerando che il sensore incluso in questo esperimento fornisce letture di temperatura, umidità e pressione ogni 5 secondi, il servizio nell’esperimento viene eseguito per un periodo di 10 minuti, risultando in 180 campioni di dati rilevati (60 per ogni tipo di valore meteorologico). Accedere al database del server IoT VNF per recuperare i dati rilevati per ulteriori analisi. A tale scopo, eseguire il comando “id_database=$(sudo docker ps | grep ‘influxdb:’ | cut -d ‘ ‘ -f 1)” sul VNF del server IoT, quindi “sudo docker exec -it $id_database bash” Esportare i dati in un file con valori delimitati da virgole (CSV), eseguendo il comando “influx -database ‘mainflux’ -execute “SELECT * FROM messages WHERE \”name\” = ” ” -format csv > /tmp/.csv”. Modificare il parametro per selezionare il tipo di dati rilevati da esportare con “temperatura”, “umidità” o “pressione” e impostare il parametro per scegliere un nome per il file di output che manterrà i risultati. Salvare i file di dati generati nel passaggio precedente per una successiva rappresentazione (vedere la sezione Risultati rappresentativi) e la verifica del corretto funzionamento del servizio di agricoltura intelligente.

Representative Results

Dopo aver seguito attentamente il protocollo per incorporare un nuovo sito nella piattaforma centrale ed eseguire un servizio di rete per convalidarne la corretta funzionalità, nella Figura 6 viene illustrato uno screenshot dello strumento open-vpn-monitor. Si può osservare come il nuovo sito stia utilizzando la VPN per tutte le sue comunicazioni, mostrando come le sue comunicazioni seguano la VPN per consentire questo scambio di dati e, di conseguenza, la corretta aggiunta del nuovo sito al servizio VPN. Come illustrato nella Figura 3,il servizio di rete fornisce informazioni da un sensore situato in un’infrastruttura remota al server situato nel sito centrale. Inoltre, la Figura 7 mostra la corretta distribuzione del servizio di rete dalla GUI Web OSM, mostrando come l’esperimento può essere correttamente istanziato nella nuova infrastruttura remota dallo stack MANO situato all’interno del sito centrale. Inoltre, il tempo necessario nell’esperimento per completare la distribuzione del servizio è di circa otto minuti. Questo valore, insieme al tempo necessario per integrare i descrittori di servizio nella piattaforma di orchestrazione (circa 9 secondi, con 1,3 secondi per descrittore, considerando sia il NS che ciascun descrittore VNF), consente di soddisfare il Key Performance Indicator (KPI) di 90 minuti per il tempo di creazione del servizio, come indicato dal 5G Infrastructure Public Private Partnership34. In questo contesto, il lavoro presentato in Vidal et al.9 include un’analisi approfondita del tempo di creazione del servizio con più siti che utilizzano il protocollo presentato. La Figura 8 mostra i dati raccolti dal sensore, inclusi i valori di umidità, temperatura e pressione rispettivamente. Questi campioni corrispondono a tutti i dati inviati dal sensore a un server remoto situato in 5TONIC, dove questi valori sono memorizzati in un database. Tutti questi dati dimostrano che la piattaforma è in grado di implementare servizi di rete pratici dopo l’inclusione di una nuova infrastruttura, nonché di abilitare correttamente le comunicazioni tra i siti. Figura 1: Distribuzione del sito del servizio VPN. Distribuzione del servizio VPN attraverso la piattaforma e la loro connettività di collegamento (tutti passando per 5TONIC). Fare clic qui per visualizzare una versione più grande di questa figura. Figura 2. Panoramica della piattaforma e del servizio VPN. Questa figura mostra tutti gli elementi della piattaforma: la posizione centrale, insieme alla sua infrastruttura NFV, il servizio VPN e una nuova infrastruttura aggregata al sistema. Include anche le connessioni tra i suoi elementi. Fare clic qui per visualizzare una versione più grande di questa figura. Figura 3: Panoramica del servizio di rete. Descrive gli elementi coinvolti nel servizio di rete, la sua distribuzione e la sua connettività logica e di rete. Fare clic qui per visualizzare una versione più grande di questa figura. Figura 4: Flussi di lavoro del protocollo. Ogni colonna rappresenta una sezione del protocollo, dove viene descritta ogni azione eseguita, la sua connessione logica tra loro e il componente incaricato della sua esecuzione. Fare clic qui per visualizzare una versione più grande di questa figura. Figura 5: Schema di configurazione dei pin. Diagramma che rappresenta come effettuare le connessioni fisiche tra i pin della scheda dei sensori e i pin GPIO dell’SBC che incorpora tale sensore. Fare clic qui per visualizzare una versione più grande di questa figura. Figura 6: Snapshot del monitor OpenVPN. L’immagine mostra che l’infrastruttura aggregata è connessa al servizio VPN, inclusi alcuni dei suoi dettagli relativi alla sua connessione. Inoltre, la figura raffigura anche connessioni aggiuntive appartenenti ad altre infrastrutture remote. Fare clic qui per visualizzare una versione più grande di questa figura. Figura 7: Stato di distribuzione di OSM NS. Interfaccia grafica OSM, che mostra la corretta implementazione del servizio di rete di test nell’infrastruttura remota. Fare clic qui per visualizzare una versione più grande di questa figura. Figura 8: Analisi rappresentativa dei dati raccolti dal sensore. (A) Illustrazione dei dati di temperatura raccolti periodicamente dal sensore ogni 5 secondi. (B) Rappresentazione grafica dei dati di umidità raccolti dal sensore ogni 5 secondi. (C) Rappresentazione visiva dei dati di pressione raccolti dal sensore ogni 5 secondi. Fare clic qui per visualizzare una versione più grande di questa figura.

Discussion

Uno degli aspetti più importanti del protocollo precedentemente descritto è la sua eccezionale flessibilità di incorporare nuove infrastrutture computazionali in un ecosistema NFV, indipendentemente dalla loro distribuzione in termini di posizione geografica (purché la larghezza di banda e la latenza delle comunicazioni di rete con siti remoti lo supportino). Ciò è possibile attraverso un’architettura di rete overlay basata su VPN, che consente la creazione di un collegamento virtuale per connettere siti remoti ai locali centrali dell’ecosistema NFV. Questo approccio consente la fornitura di un canale efficace e sicuro per supportare la NFV e le comunicazioni di dati tra i siti di un ecosistema NFV, riducendo la probabilità che parti esterne accedano e/o modifichino informazioni sensibili relative ai processi di orchestrazione NFV e ai dati provenienti dai servizi distribuiti. In questo contesto, il protocollo descrive anche una metodologia specifica per condividere in modo sicuro le credenziali VPN con i siti esterni che consentirà l’integrazione di nuove infrastrutture. Il protocollo è stato esemplificato utilizzando l’ecosistema NFV reso disponibile a 5TONIC da Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute, sebbene sia generico per essere utilizzato in altri ambienti NFV che soddisfano i requisiti precedenti menzionati nella fase 1 di questo protocollo.

Inoltre, vale la pena sottolineare l’utilizzo esclusivo di strumenti e software open source per l’implementazione del protocollo. Nonostante le funzionalità potenzialmente vantaggiose che potrebbero essere offerte da diverse soluzioni proprietarie (ad esempio, Fortinet35), l’uso di sviluppi open source ha facilitato l’integrazione di tutti gli elementi racchiusi nel protocollo grazie alle loro caratteristiche intrinseche come l’economicità, un ampio supporto software fornito dalla comunità open source e un elevato livello di affidabilità, solo per citarne alcuni. Inoltre, l’utilizzo di tecnologie open source può anche promuovere sinergie tra componenti di natura simile. Ad esempio, al fine di monitorare lo stato della connessione VPN per i client che utilizzano la piattaforma, il servizio VPN implementato in tutto il protocollo potrebbe fare affidamento sullo strumento di monitoraggio open-VPN36 (uno strumento di monitoraggio basato su Python in grado di interagire con i server OpenVPN).

D’altra parte, la specifica del protocollo considera l’istanza dei servizi di rete tra diversi siti a scopo di convalida. A questo proposito, è importante sottolineare che l’implementazione di servizi su un determinato sito è soggetta alla disponibilità di risorse di elaborazione, archiviazione e rete nel sito, nonché di apparecchiature specializzate che potrebbero essere necessarie per eseguire la distribuzione (ad esempio, SUAV abilitati NFV). Questa non è una limitazione del protocollo e dovrebbe essere presa in considerazione dalle parti interessate interessate a riprodurre l’esperimento descritto in questo documento.

Inoltre, va notato che il tempo necessario per eseguire la distribuzione dei servizi di rete dipende in larga misura da diversi fattori quali il percorso di rete tra l’orchestratore e le diverse VIM, le prestazioni delle comunicazioni di dati tra il VIM e i suoi nodi computazionali gestiti, e anche nella natura intrinseca di questi nodi computazionali (non solo a causa delle loro risorse di calcolo disponibili, ma anche le tecnologie incorporate per condurre la virtualizzazione delle funzioni di rete).

Infine, e date le eccezionali prestazioni che questa piattaforma e il suo servizio VPN hanno avuto sui progetti europei e sulle opere collaborative in cui è stata utilizzata finora (ad esempio, 5GINFIRE, 5GRANGE o 5GCity, menzionati nell’introduzione di questo documento), sarà considerato un elemento importante nei progetti europei emergenti in cui Universidad Carlos III de Madrid, Telefónica e IMDEA Networks Institute partecipano, come Horizon 2020 LABYRINTH, o progetti nazionali, come TRUE-5G.

Disclosures

The authors have nothing to disclose.

Acknowledgements

Questo lavoro è stato parzialmente supportato dal progetto europeo H2020 LABYRINTH (convenzione di sovvenzione H2020-MG-2019-TwoStages-861696) e dal progetto TRUE5G (PID2019-108713RB-C52PID2019-108713RB-C52 / AEI / 10.13039/501100011033) finanziato dall’Agenzia nazionale spagnola per la ricerca. Inoltre, il lavoro di Borja Nogales, Ivan Vidal e Diego R. Lopez è stato parzialmente supportato dal progetto europeo H2020 5G-VINNI (numero di convenzione di sovvenzione 815279). Infine, gli autori ringraziano Alejandro Rodríguez García per il suo supporto durante la realizzazione di questo lavoro.

Materials

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/
DOWNLOAD MATERIALS LIST

References

  1. Gupta, A., Jha, R. K. A Survey of 5G Network: Architecture and Emerging Technologies. IEEE Access. 3, 1206-1232 (2015).
  2. Yu, H., Lee, H., Jeon, H. What is 5G? Emerging 5G Mobile Services and Network Requirements. Sustainability. 9, 1848 (2017).
  3. Yi, B., Wang, X., Li, K., Huang, M. A comprehensive survey of network function virtualization. Computer Networks. 133, 212-262 (2018).
  4. An Open Research and Innovation Laboratory Focusing on 5G Technologies. 5TONIC Available from: https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf (2020)
  5. ETSI. ETSI GS NFV 002. Network Functions Virtualization: Architectural Framework. ETSI. , (2014).
  6. An Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. ETSI OSM Available from: https://osm.etsi.org (2020)
  7. Silva, A. P., et al. 5GinFIRE: An end-to-end open5G vertical network function ecosystem. Ad Hoc Networks. 93, 101895 (2019).
  8. Nogales, B., et al. Design and deployment of an open management and orchestration platform for multi-site nfv experimentation. IEEE Communications Magazine. 57 (1), 20-27 (2019).
  9. Vidal, I., et al. Multi-Site NFV Testbed for Experimentation With SUAV-Based 5G Vertical Services. IEEE Access. 8, 111522-111535 (2020).
  10. Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F. Adaptable and automated small uav deployments via virtualization. Sensors. 18 (12), 4116 (2018).
  11. Gonzalez, L. F., et al. Transport-Layer Limitations for NFV Orchestration in Resource-Constrained Aerial Networks. Sensors. 19 (23), 5220 (2019).
  12. Sanchez-Aguero, V., Valera, F., Nogales, B., Gonzalez, L. F., Vidal, I. VENUE: Virtualized Environment for multi-UAV network emulation. IEEE Access. 7, 154659-154671 (2019).
  13. Kalogiros, C., et al. The potential of 5G experimentation-as-a-service paradigm for operators and vertical industries: the case of 5G-VINNI facility. IEEE 2nd 5G World Forum (5GWF). , 347-352 (2019).
  14. Ordonez-Lucena, J., Tranoris, C., Rodrigues, J., Contreras, L. M. Cross-domain Slice Orchestration for Advanced Vertical Trials in a Multi-Vendor 5G Facility. 2020 European Conference on Networks and Communications (EuCNC). , 40-45 (2020).
  15. OASIS. ISO/IEC 20922:2016 Information technology — MQ Telemetry Transport (MQTT) v3.1.1. International Organization for Standardization. , (2016).
  16. An Open source IoT Platform Edge computing and Consulting services. Mainflux Available from: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144 (2020)
  17. 3rd Generation Partnership Project. System architecture for the 5g system; stage 2. Technical Specification Group Services and System Aspects. 3GPP Technical Specification 23.501, version 16.2.0. , (2019).
  18. . Open Source MANO Release SEVEN user-guide documentation Available from: https://osm.etsi.org/docs/user-guide (2020)
  19. Open Source Software for Creating Private and Public Clouds. OpenStack Available from: https://www.openstack.org (2020)
  20. OpenStack release Ocata Documentation. OpenStack Available from: https://docs.openstack.org/ocata (2019)
  21. OpenStack release Ocata Installation Tutorial for Ubuntu. OpenStack Available from: https://docs.openstack.org/ocata/install-guide-ubuntu (2019)
  22. A full-featured, open, and cost-effective VPN solution. OpenVPN Available from: https://openvpn.net (2020)
  23. OpenVPN How to Installation Guide. OpenVPN Available from: https://openvpn.net/community-resources/how-to/#installing-openvpn (2020)
  24. A Linux kernel firewall implementation. Iptables Available from: https://wiki.archlinux.org/index.php/Iptables (2020)
  25. An NFV VIM implementation contributed to the open source community project ETSI OSM. OpenVIM Available from: https://osm.etsi.org/gitweb/?p=osm/openvim.git (2020)
  26. A cloud service-delivery platform to operate and manage cloud-service businesses. VMware Cloud Director Available from: https://www.vmware.com/uk/products/cloud-director.html (2020)
  27. A broadly adopted cloud platform offering services from datacenters globally. Amazon Web Services (AWS) Available from: https://aws.amazon.com (2020)
  28. Microsoft cloud computing service for developing and managing services and applications through Microsoft-managed datacenters. Microsoft Azure Available from: https://azure.microsoft.com/en-us (2020)
  29. Eclipse fog05, The End-to-End Compute, Storage and Networking Virtualization solution. Eclipse Foundation Available from: https://fog05.io (2020)
  30. Nogales, B., et al. Automated Deployment of an Internet Protocol Telephony Service on Unmanned Aerial Vehicles Using Network Functions Virtualization. Journal of Visualized Experiments. (153), e60425 (2019).
  31. RPi.bme280 0.2.3. A Python library to drive BME280 sensor over I2C. PYPI Available from: https://pypi.org/project/RPi.bme280/ (2020)
  32. Paho-mqtt 1.5.0. A Python library implementing the MQTT client version 3.1.1. PYPI Available from: https://pypi.org/project/paho-mqtt/ (2020)
  33. Public Private Partnership in Horizon 2020. Creating a Smart Ubiquitous Network for the Future Internet. Advanced 5G Network Infrastructure for the Future Internet. , (2013).
  34. Deliver Network Security Digital Transformation. Fortinet Available from: https://www.fortinet.com (2020)
  35. Open source tool to monitor the status of the service offered by an OpenVPN server. Openvpn-monitor Available from: https://github.com/furlongm/openvpn-monitor (2020)

Tags

5GExperimentationInfrastructureNFVEcosystemVPNCredentialEncryptionOpenStackIntegration

Play Video
PDF
DOI
DOWNLOAD MATERIALS LIST
Cite This Article
Nogales, B., Gonzalez, L. F., Vidal, I., Valera, F., Garcia-Reinoso, J., Lopez, D. R., Rodríguez, J., Gonzalez, N., Berberana, I., Azcorra, A. Integration of 5G Experimentation Infrastructures into a Multi-Site NFV Ecosystem. J. Vis. Exp. (168), e61946, doi:10.3791/61946 (2021).
Download Citation
Reprints and Permissions

View Video

✖

To prove you're not a robot, please enter the text in the image below

CAPTCHA Image
Play CAPTCHA Audio
Refresh Image