Summary
L'obiettivo del protocollo descritto è duplice: configurare un ambiente di virtualizzazione delle funzioni di rete utilizzando veicoli aerei senza equipaggio come entità computazionali che forniscono la struttura sottostante per eseguire funzioni di rete virtualizzate e utilizzare questo ambiente per supportare l'implementazione automatizzata di un servizio di telefonia di protocollo Internet funzionale sui veicoli aerei.
Abstract
Il paradigma NFV (Network Function Virtualization) è una delle tecnologie abilitanti chiave nello sviluppo dellaquinta generazione di reti mobili. Questa tecnologia mira a ridurre la dipendenza dall'hardware nella fornitura di funzioni e servizi di rete utilizzando tecniche di virtualizzazione che consentono la softwarization di tali funzionalità su un livello di astrazione. In questo contesto, cresce l'interesse nell'esplorare il potenziale dei veicoli aerei senza equipaggio (UAV) per offrire una piattaforma flessibile in grado di consentire operazioni NFV a costi costi su aree geografiche delimitate.
Per dimostrare la fattibilità pratica dell'utilizzo delle tecnologie NFV nelle piattaforme UAV, viene presentato un protocollo per creare un ambiente NFV funzionale basato su tecnologie open source, in cui un insieme di piccoli UAV fornisce le risorse di calcolo che supportano l'implementazione di servizi di rete moderatamente complessi. Quindi, il protocollo descrive in dettaglio i diversi passaggi necessari per supportare la distribuzione automatica di un servizio di telefonia IP (Internet Protocol) su una rete di UAV interconnessi, sfruttando le capacità dell'ambiente NFV configurato. I risultati della sperimentazione dimostrano il corretto funzionamento del servizio dopo la distribuzione. Sebbene il protocollo si concentri su un tipo specifico di servizio di rete, ovvero la telefonia IP, i passaggi descritti possono fungere da guida generale per distribuire altri tipi di servizi di rete. D'altra parte, la descrizione del protocollo considera le attrezzature e i software concreti per configurare l'ambiente NFV (ad esempio, specifici computer a scheda singola e software open source). L'utilizzo di altre piattaforme hardware e software può essere fattibile, anche se l'aspetto di configurazione specifico dell'ambiente NFV e la distribuzione del servizio possono presentare variazioni rispetto a quelle descritte nel protocollo.
Introduction
Uno degli obiettivi più ambiti nella nuova era delle comunicazioni mobili (più comunemente noti come5th mobile generation o 5G) è quello di essere in grado di fornire servizi informatici solidi in situazioni in cui l'infrastruttura di telecomunicazioni primaria potrebbe non essere disponibile (ad esempio, a causa di un'emergenza). In questo contesto, gli UAV stanno ricevendo una crescente attenzione da parte della comunità di ricerca a causa della loro versatilità intrinseca. Ci sono numerose opere che utilizzano questi dispositivi come pietra angolare per la fornitura di una grande varietà di servizi. Ad esempio, la letteratura ha analizzato la capacità di questi dispositivi di costruire un'infrastruttura di comunicazione aerea per ospitare i servizi multimediali1,2,3. Inoltre, ricerche precedenti hanno dimostrato come la cooperazione tra diversi UAV possa estendere la funzionalità di diversi servizi di comunicazione come la sorveglianza4, ricerca collaborativa e soccorso5,6,7,8, o agribusiness9.
D'altra parte, la tecnologia NFV ha acquisito grande importanza all'interno degli operatori di telecomunicazioni come uno dei fattori chiave 5G. NFV rappresenta un cambiamento paradigmatico per quanto riguarda l'infrastruttura delle telecomunicazioni alleviando l'attuale dipendenza delle appliance di rete su hardware specializzato attraverso la softwarization delle funzionalità di rete. Ciò consente una distribuzione flessibile e agile di nuovi tipi di servizi di comunicazione. A tal fine, l'Istituto europeo per gli standard delle telecomunicazioni (ETSI) ha costituito un gruppo di specifiche per definire il quadro architettonico NFV10. Inoltre, l'ETSI ospita attualmente il gruppo Open Source Mano (OSM)11, che ha il compito di sviluppare uno stack software DI gestione e orchestrazione NFV (MANO) in linea con la definizione del framework architettonico ETSI NFV.
Tenuto conto di tutte le considerazioni summenzionate, la convergenza sinergica tra UAV e tecnologie NFV è attualmente allo studio nello sviluppo di nuove applicazioni e servizi di rete. Ciò è illustrato da diversi lavori di ricerca nella letteratura che sottolineano i vantaggi di questi tipi di sistemi14,15,16, identificano le sfide di questa convergenza e dei suoi aspetti mancanti, evidenziano le future linee di ricerca su questo argomento17e presentano soluzioni pionieristiche basate sulle tecnologie open source.
In particolare, l'integrazione delle tecnologie NFV nell'arena UAV consente la distribuzione rapida e flessibile di servizi e applicazioni di rete su aree geografiche delimitate (ad esempio, un servizio di telefonia IP). Seguendo questo approccio, un certo numero di UAV possono essere distribuiti in una posizione specifica, trasportando le piattaforme di calcolo come payload (ad esempio, computer a scheda singola di piccole dimensioni). Queste piattaforme di calcolo fornirebbero un'infrastruttura di rete programmabile (ad esempio, un'infrastruttura NFV) sull'area di distribuzione, supportando la creazione di istanze di servizi e applicazioni di rete sotto il controllo di una piattaforma MANO.
Nonostante i vantaggi, la realizzazione di questa visualizzazione presenta una serie di sfide fondamentali che devono essere affrontate con attenzione, come l'integrazione appropriata di queste piattaforme di calcolo come infrastruttura NFV, utilizzando uno stack software NFV esistente, in modo che un servizio di orchestrazione NFV possa distribuire funzioni virtuali sugli UAV; i vincoli in termini di risorse di calcolo fornite dalle piattaforme di calcolo, poiché gli UAV che li trasportano possono in genere presentare limitazioni in termini di dimensioni, peso e capacità di calcolo delle apparecchiature di carico utile; il corretto posizionamento delle funzioni virtuali sugli UAV (cioè, selezionando il miglior candidato UAV per implementare una particolare funzione virtuale); la manutenzione delle comunicazioni di controllo con gli UAV al fine di gestire il ciclo di vita dei VNF nonostante la disponibilità potenzialmente intermittente delle comunicazioni di rete con loro (ad esempio, causata dalla mobilità e dai vincoli delle batterie); il tempo di funzionamento limitato degli UAV a causa del loro consumo di batteria; e la migrazione delle funzioni virtuali quando un UAV deve essere sostituito a causa della sua esaurimento della batteria. Questi vantaggi e sfide sono descritti in dettaglio nel lavoro precedente18,19 che include la progettazione di un sistema NFV in grado di supportare la distribuzione automatizzata di funzioni e servizi di rete su piattaforme UAV, nonché la convalida della fattibilità pratica di questo progetto.
In questo contesto, questo documento si concentra sulla descrizione di un protocollo per consentire la distribuzione automatizzata di servizi di rete moderatamente complessi su una rete di UAV utilizzando gli standard NFV e le tecnologie open source. Per illustrare le diverse fasi del protocollo, viene presentata una rielaborazione di un esperimento presentato in Nogales et al.19, consistente nella distribuzione di un servizio di telefonia IP. Per facilitare la riproducibilità di questo lavoro, il volo reale è considerato come opzionale nella procedura presentata e i risultati delle prestazioni si ottengono con i dispositivi UAV a terra. I lettori interessati dovrebbero essere in grado di replicare e convalidare l'esecuzione del protocollo, anche in un ambiente di laboratorio controllato.
Nella Figura 1 viene illustrato il servizio di rete progettato per questa procedura. Questo servizio di rete è costruito come una composizione di specifiche unità softwarization (categorizzate all'interno del paradigma NFV come funzioni di rete virtuale, o VNF) e fornisce la funzionalità di un servizio di telefonia IP agli utenti nelle vicinanze degli UAV. Il VNF che compone il servizio è definito come segue:
- Access Point VNF (AP-VNF): questo VNF fornisce un punto di accesso Wi-Fi alle apparecchiature per l'utente finale (ad esempio, telefoni IP in questo esperimento).
- Server di telefonia IP VNF (IP-telephony-server-VNF): è responsabile della gestione dei messaggi di segnalazione delle chiamate scambiati tra i telefoni IP per stabilire e terminare una chiamata vocale.
- Domain Name System VNF (DNS-VNF): questo VNF fornisce un servizio di risoluzione dei nomi, che in genere è necessario nei servizi di telefonia IP.
- Router di accesso VNF (AR-VNF): fornisce funzionalità di routing di rete, supportando lo scambio di traffico (cioè, segnalazione delle chiamate in questo esperimento) tra i telefoni IP e il dominio dell'operatore di telecomunicazioni.
- Core router VNF (CR-VNF): fornisce funzionalità di routing di rete nel dominio dell'operatore di telecomunicazione, offrendo l'accesso a servizi specifici dell'operatore (ad esempio, il server di telefonia IP) e reti di dati esterni.
Inoltre, la Figura 1 presenta i dispositivi fisici utilizzati per l'esperimento, il modo in cui sono interconnessi e l'allocazione specifica dei VNF ai dispositivi.
Protocol
1. Requisiti precedenti per l'esperimento
- Installare lo stack software DI gestione e orchestrazione (MANO) fornito dal progetto Open Source MANO (OSM). In particolare, questo esperimento utilizza OSM Release FOUR20, che può essere eseguito in un singolo computer server o in una macchina virtuale (VM) che soddisfa i requisiti specificati dalla comunità OSM: Ubuntu 16.04 come sistema operativo (immagine variante a 64 bit), due unità di elaborazione centrale (CPU), 8 GB di memoria ad accesso casuale (RAM), un disco di archiviazione da 40 GB e un'unica interfaccia di rete con accesso a Internet. La procedura per installare OSM Release FOUR insieme ai suoi dettagli tecnici è disponibile nella documentazione online fornita dalla community OSM21.
- Configura una piattaforma di cloud computing, fornendo le funzioni di un gestore dell'infrastruttura virtuale (VIM) compatibile con OSM Release FOUR. Per questo esperimento, viene utilizzata la versione OpenStack Ocata22, in esecuzione in una macchina virtuale con Ubuntu 16.04 come sistema operativo, quattro CPU, 16 GB di RAM e disco di archiviazione da 200 GB. Nell'esperimento, il VIM gestisce un'infrastruttura NFV (NFVI) integrata da due computer server di alto profilo, ciascuno con Ubuntu 16,04 come sistema operativo, otto CPU, 128 GB di RAM e disco di archiviazione da 4 TB). Tutte le informazioni su come configurare una piattaforma di cloud computing sono incluse nella guida all'installazione inclusa nella documentazione23di OpenStack. Questa piattaforma cloud viene definita piattaforma cloud principale.
- Configurare una piattaforma di cloud computing aggiuntiva per gli UAV viene definita piattaforma cloud UAV.
- Assicurarsi che questa piattaforma sia dotata di un VIM basato sulla versione OpenStack Ocata. In questo caso, le risorse utilizzate dall'installazione di VIM sono Ubuntu 16.04 come sistema operativo, due CPU, 6 GB di RAM, disco di archiviazione da 100 GB e una scheda USB Wi-Fi esterna.
- NFVI integrato in questa piattaforma cloud è costituito da un singolo server di calcolo fisso (Ubuntu 16.04 come sistema operativo, otto CPU, 8 GB di RAM, disco di archiviazione 128 GB e un adattatore USB Wi-Fi esterno) e tre computer a scheda singola (SBC). Quest'ultimo fornisce una piattaforma hardware che può essere facilmente imbarcata su un UAV. Vedere sezione 3 per la procedura di configurazione di una piattaforma cloud UAV con questi dispositivi come nodi di calcolo.
- Equipaggia ogni SBC con un alimentatore a batteria collegato sulla parte superiore (HAT) per garantire il funzionamento di queste unità anche quando sono in movimento, trasportandoda da un UAV.
NOTA: Il passaggio 1.5 è facoltativo perché la fornitura del servizio di rete nell'esperimento non dipende dalla presenza di UAV. Inoltre, gli SBC sono trasportati come carico utile degli UAV e non sono necessarie altre connessioni aggiuntive (ad esempio, Ethernet o USB), poiché le comunicazioni di rete necessarie per il corretto funzionamento del servizio di telefonia IP sono fornite dagli SBC, attraverso i loro adattatori Wi-Fi e l'alimentazione è fornita dall'alimentatore HAT menzionato nel passaggio 1.4. - Collegare ogni SBC come carico utile di un UAV attraverso un accessorio di fissaggio. In questo esperimento, sono stati scelti tre UAV commerciali per trasportare le unità di calcolo offerte dagli SBC.
- Selezionare due telefoni VoIP (Voice-over-IP) wireless che supportano lo standard di comunicazione wireless IEEE 802.11b; questo modello fornisce comunicazioni wireless tramite Wi-Fi. In alternativa, la chiamata vocale potrebbe essere eseguita utilizzando applicazioni softphone come Linphone24 o Jitsi25.
- Come requisito sperimentale, assicurarsi della disponibilità di: a) comunicazioni di livello 3 tra lo stack software OSM e ciascuno dei VIM per consentire la distribuzione orchestrata del servizio di rete sviluppato per questo esperimento, b) comunicazioni di livello 3 tra l'OSM e i VNF in ogni piattaforma cloud per supportare le procedure di configurazione VNF e c) le comunicazioni di livello 3 tra i VNF in esecuzione ad ogni VIM per consentire il corretto funzionamento del servizio di rete.
- Tutto il contenuto necessario per realizzare l'esperimento è fornito nel repository esperimento pubblico http://vm-images.netcom.it.uc3m.es/JoVE/.
2. Convalidare la funzionalità delle unità di softwarization tramite emulazione
NOTA: per dimostrare il funzionamento appropriato del servizio di rete dell'esperimento (vedere la figura 1) in condizioni di distribuzione realistiche, è stata utilizzata una piattaforma di emulazione specifica specifica basata su contenitori Linux26 e ns-327. Questa piattaforma consente di emulare i collegamenti aerei multi-hop e di definire le caratteristiche di tali collegamenti (ad esempio, la lunghezza dei collegamenti di comunicazione wireless, il modello di perdite dei pacchetti di dati, la tecnologia radio utilizzata nelle comunicazioni wireless, ecc.). Pertanto, questa sezione del protocollo descrive i passaggi da seguire per verificare il funzionamento appropriato del servizio di telefonia IP in condizioni realistiche di collegamento di comunicazione wireless attraverso la piattaforma di emulazione.
- Scaricare la piattaforma di emulazione dal repository dell'esperimento. La piattaforma è disponibile come macchina virtuale, denominata "uav-nfv-jove-experiment.qcow", conforme alla tecnologia di virtualizzazione KVM28. Questa macchina contiene un modello precreato che emula il servizio di rete e lo scenario multi-UAV presentato in Figura 1 e un utente con privilegi di amministratore in grado di eseguire tale modello.
NOTA: per impostazione predefinita, i passaggi seguenti vengono eseguiti automaticamente all'avvio della macchina virtuale della piattaforma di emulazione: a) l'ambiente virtuale è configurato per abilitare l'emulazione di rete (ad esempio, interfacce di rete, bridge Linux29); b) vengono creati i contenitori Linux che rappresentano i diversi componenti fisici del banco di prova (ad esempio, gli SBC e il server di calcolo fisso per la piattaforma cloud UAV e il server di calcolo per la piattaforma cloud di base); e c) le funzioni fornite dai diversi VNF del servizio di telefonia IP (ad esempio, punti di accesso, router, DNS serve e server di telefonia IP) sono distribuite come contenitori Linux sui corrispondenti SBC e server di calcolo emulati. - Prima del processo di convalida, impostare una rete aerea multihop emulata utilizzando il simulatore ns-3, al fine di consentire la connettività tra i diversi partecipanti alla rete. Questa procedura emulerà le comunicazioni wireless realistiche che si svolgono nello scenario illustrato nella Figura 1 (ad esempio, la rete wi-fi ad hoc, che consente lo scambio di dati tra i nodi della piattaforma cloud UAV e le reti wireless offerte dai due punti di accesso Wi-Fi forniti nel servizio).
- Creare la rete aerea multi-hop. A tale scopo, eseguire lo script multi-hop-aerial-net.sh (disponibile all'interno della macchina della piattaforma di emulazione) utilizzando il seguente comando: sudo sh /home/jovevm/scripts/multi-hop-aerial-net.sh > multi-hop-aerial-net-trace.log 2>&1 &. Questo comando ritrae la traccia di simulazione nel file di log specificato per abilitare il debug in caso di errori.
- Verificare se la rete è stata creata correttamente. A tal fine, verificare se i contenitori Linux "IP-phone-a" e "IP-phone-b" (illustrati nella Figura 1 come apparecchiature dell'utente finale che si connettono a un AP-VNF) hanno ottenuto un indirizzo IP tramite il servizio DHCP, che è accessibile solo tramite la rete aerea multi-hop. Lo stato del contenitore Linux eseguito all'interno della macchina di emulazione, così come i loro indirizzi IP, può essere controllato utilizzando il comando lxc list.
- Verificare la capacità del servizio di rete emulato di elaborare i messaggi di segnalazione necessari per configurare la chiamata di telefonia IP. A tale scopo, entrambi i contenitori Linux "IP-phone-a" e "IP-phone-b" hanno installato lo strumento "SIPp"30. "SIPp" fornisce la funzionalità per emulare un telefono IP creando i messaggi di segnalazione menzionati, inviarli a un server di telefonia IP ed elaborare la risposta per verificare il corretto funzionamento di quest'ultimo.
- Eseguire lo script test-signaling.sh in entrambi i contenitori, che esegue lo strumento "SIPp" per generare e inviare messaggi di segnalazione all'IP-telefonia-server-VNF.
- Controllare la schermata dello scenario fornita dall'esecuzione del passaggio precedente. La ricezione della risposta "200" mostra il funzionamento appropriato della telefonia IP-server-VNF.
- Verificare che il servizio di rete sia in grado di elaborare il traffico dati generato durante una chiamata di telefonia IP. A tale scopo, lo strumento di pianificazione del flusso "Trafic"31 viene installato nei contenitori Linux "IP-phone-a" e "IP-phone-b".
- Eseguire il comando seguente per avviare l'agente server di Trafic: lxc exec IP-phone-b sh called-party.sh.
- Quindi, eseguire il comando seguente per avviare l'agente client di Trafic e ottenere le statistiche di rete: lxc exec IP-phone-a sh caller.sh. Il traffico dati che emula una chiamata vocale viene terminato dopo 60 s. Lo script visualizza un messaggio di conferma e le metriche di prestazioni più significative relative al traffico vocale.
- Controllare le metriche ottenute e verificare che il servizio di telefonia IP sia in grado di supportare in modo efficace una conversazione vocale interattiva. A tale scopo, vedere le informazioni incluse nella sezione sui risultati rappresentativi.
3. Costruzione di piattaforme cloud UAV
- Selezionare il modello di SBC in grado di fornire il substrato di virtualizzazione per eseguire VNF leggeri. Le specifiche tecniche dei dispositivi SBC utilizzati durante l'esperimento sono: quattro CPU, 1 GB di RAM e un disco di archiviazione da 32 GB. Inoltre, ogni SBC ha tre interfacce di rete: un'interfaccia Ethernet, un'interfaccia Wi-Fi integrata e un adattatore USB Wi-Fi esterno.
- Preparare gli SBC per essere successivamente integrati nella piattaforma cloud UAV.
- Installare Ubuntu Mate32 16.04.6 come sistema operativo, dato che i pacchetti di installazione OpenStack sono inclusi in questa distribuzione Linux.
- Installare e configurare i pacchetti necessari come indicato nella documentazione33 di OpenStack per consentire agli SBC di fungere da nodi di calcolo della piattaforma cloud UAV. Seguendo la guida precedente, abilitare l'utilizzo dei contenitori Linux nella configurazione dei pacchetti OpenStack. La virtualizzazione dei contenitori viene utilizzata a causa dei vincoli di risorse dei dispositivi che in genere possono essere caricati in UAV di piccole dimensioni.
- In SBC, scaricare ed eseguire lo script rpi-networking-configuration.sh, disponibile all'interno del repository dell'esperimento. Questo script consente le comunicazioni wireless degli SBC, nonché la configurazione necessaria per consentire la creazione di reti virtuali collegate alle interfacce wireless.
- Scaricare ed eseguire lo script VIM-networking-configuration.sh, disponibile all'interno del repository dell'esperimento, nell'host che esegue la piattaforma cloud UAV VIM. Questo script supervisiona la configurazione delle comunicazioni wireless del VIM per consentire lo scambio di informazioni con gli SBC.
NOTA: Una volta che la rete è ben configurata e il VIM ha connettività con gli SBC, il VIM li integra automaticamente nella piattaforma cloud UAV come unità computazionali in grado di eseguire VNF
- Creare una zona di disponibilità OpenStack per ognuno sBC. Ciò consentirà di distribuire ciascuno dei VNF leggeri dell'esperimento in un'unità UAV appropriata. A tale scopo, accedere all'interfaccia utente grafica Web fornita dal VIM con le credenziali di amministratore, creare le zone di disponibilità nella scheda Amministratore > Sistema > Aggregati host e modificare ogni zona di disponibilità per aggiungere l'host appropriato (ad esempio, ogni SBC integrato nella piattaforma cloud UAV).
- Verificare la corretta configurazione della piattaforma cloud UAV. A tale scopo, accedere alla scheda Amministratore > Sistema > Informazioni di sistema con lo stesso account di accesso del passaggio precedente e fare clic nella sezione Servizio di calcolo e Agenti di rete per verificare che lo stato degli elementi visualizzati sia "Alive" e "UP".
4. Configurazione dell'esperimento
- Scaricare le immagini VNF che implementano i diversi componenti del servizio di telefonia IP: AP-VNF, DNS-VNF, IP-telefonia-server-VNF, AR-VNF e CR-VNF. Queste immagini possono essere scaricate dal repository dell'esperimento.
- Caricare le immagini VNF sul loro corrispondente VIM (cioè, l'AP-VNF e il DNS-VNF sulla piattaforma cloud UAV VIM) e il VoIP-VNF alla piattaforma cloud principale VIM. A tale scopo, accedere all'interfaccia utente grafica web fornita da ogni VIM con le credenziali di amministratore, fare clic sul pulsante Crea immagine dell'amministratore > Sistema > scheda Immagini e creare un'immagine utilizzando il modulo visualizzato e selezionare l'immagine appropriata. Questo processo viene eseguito al VIM corrispondente per ogni immagine che è stata scaricata nel passaggio precedente.
- Scaricare i descrittori VNF (VNFD) dell'esperimento dal repository dell'esperimento. Questi descrittori forniscono i modelli che descrivono i requisiti operativi di un VNF, nonché i criteri di posizionamento che indicano la zona di disponibilità incaricata di ospitare il VNF stesso. Ulteriori informazioni sui descrittori NFV sono disponibili nel modello informativo di OSM34.
- Caricare i VNFD. Utilizzare un browser Web per accedere all'interfaccia utente grafica OSM e accedere con le credenziali di amministratore. Quindi, trascinare e rilasciare i VNFD nella scheda Pacchetti VNF.
- Scaricare il descrittore dei servizi di rete (NSD) dal repository dell'esperimento. Questo descrittore è un modello che specifica le VNF che comprendono il servizio, nonché il modo in cui tali VNF sono interconnessi.
- Carica l'NSD. Trascinare e rilasciare l'NSD nella scheda Pacchetti NS dell'interfaccia utente grafica OSM.
- Utilizzando l'interfaccia utente grafica di OSM, aggiungere un account VIM per la piattaforma cloud UAV VIM e per la piattaforma cloud core VIM. Per fare questo, accedere alla scheda Account VIM con le credenziali di amministratore, fare clic sul pulsante - Nuovo VIM e compilare il modulo visualizzato con le informazioni richieste. Ripetere questa azione per entrambi i VIM.
5. Esecuzione dell'esperimento
- Distribuire il servizio di rete. Dalla scheda Pacchetti NS dell'interfaccia utente grafica di OSM, fare clic sul pulsante Crea NS dell'NSD caricato nel passaggio 4.6. Quindi, compilare il modulo visualizzato, indicando il VIM che verrà utilizzato per distribuire ogni VNF che compone il NS. Inoltre, l'OSM è responsabile dell'elaborazione dei criteri di posizionamento indicati nei VNFD per specificare il VIM quale zona di disponibilità (cioè un'unità di calcolo nel nostro banco di prova) è responsabile dell'hosting di ogni VNF. Per questo esperimento, i VNF vengono inseriti nelle unità di calcolo come illustrato nella Figura 1.
NOTA: come metodo alternativo, OSM fornisce un'interfaccia della riga di comando che consente l'interazione diretta dell'utente. Un utente che riproduce questo esperimento può utilizzare questa interfaccia della riga di comando, anziché l'interfaccia grafica, per eseguire i diversi passaggi definiti in questo protocollo, in particolare i passaggi correlati all'onboarding di un vNF o a un descrittore NS, servizio di rete. - Attendere che l'interfaccia utente grafica OSM indichi l'esito positivo della distribuzione del servizio di rete.
NOTA: Il funzionamento del servizio di rete è totalmente indipendente dal volo degli UAV: il servizio di telefonia IP può essere fornito quando gli UAV volano o risparmiano il consumo della batteria appollaiati su una superficie. Pertanto, il passaggio 5.3 è facoltativo. - Togliti gli UAV. Accedere all'applicazione mobile e controllare il volo di ogni UAV per mantenerlo stabilmente in un'altezza intermedia ed evitare la turbolenza causata dalla rotazione dei motori vicino a una superficie.
- Preparare ciascuno dei telefoni IP per effettuare la chiamata.
- Collegare un telefono VoIP wireless a ciascuno dei punti di accesso offerti dal servizio di rete. A tale scopo, specificare il SSID (Service Set Identifier) nel menu > Wireless > scheda SSID e scegliere la modalità infrastruttura nella sezione Menu > Wireless > Modalità di rete. Infine, selezionare la configurazione di rete tramite il protocollo DHCP (Dynamic Host Configuration Protocol) nel menu > Impostazioni di rete > scheda Modalità di rete.
- Configurare i parametri SIP (Session Initiation Protocol) per consentire lo scambio appropriato di messaggi di segnalazione con il server di telefonia IP. In questo contesto, accedere alla scheda Menu > Impostazioni SIP e specificare il nome host del server di telefonia IP VNF ("dronesVoIP.net") nelle schede Funzione di registrazione > IP di registrazione e Server proxy > IP proxy. Inoltre, creare un account utente introducendo il nome dell'utente (ad esempio, chiamante-A) nelle sezioni Account utente > Numero di telefono e Account utente > Nome utente.
- Creare una voce nella rubrica di uno dei telefoni IP fornendo le informazioni dell'utente che deve essere chiamato. A tale scopo, selezionare il Menu > Rubrica > scheda Aggiungi voce e compilare i parametri richiesti che appaiono nella visualizzazione come segue: Nome visualizzato - chiamante-B; Informazioni sull'utente: chiamante-B; IP host - dronesVoIP.net; Porta 5060. Infine, selezionare l'opzione "Proxy" rispetto al P2P (peer-to-peer).
- Avviare la chiamata all'altra parte. A tale scopo, selezionare la parte chiamata utilizzando il Menu > Rubrica > L'opzione di ricerca del telefono IP. Quindi, premere il pulsante di chiamata. Una volta che l'altro telefono IP inizia a squillare, accettare la chiamata in arrivo con il pulsante di chiamata.
6. Procedura per raccogliere risultati sperimentali
- Collegare un computer portatile commodity a uno dei punti di accesso wireless ed eseguire lo strumento della riga di comando ping all'indirizzo IP del telefono collegato all'altro Punto di accesso durante 180 s. L'indirizzo IP può essere controllato nell'opzione Menu > Informazioni > Indirizzo IP del telefono IP una volta stabilita la connessione con le misurazioni AP. Save the Round-Trip Time (RTT), reindirizzando l'output fornito dallo strumento ping in un file.
- Eseguire lo strumento da riga di comando tcpdump in uno dei VNF AP in esecuzione per acquisire il traffico scambiato durante la chiamata IP. Salvare il traffico in un file abilitando il flag di scrittura dello strumento della riga di comando in fase di esecuzione e specificando il nome del file.
- Eseguire una nuova chiamata di telefonia IP. Mantenere la chiamata per il periodo di tempo desiderato (ad es. 1 min). Quindi, terminare la chiamata, premendo il pulsante di riaggancio di uno dei telefoni IP.
- Conservare i file generati dagli strumenti tcpdump e ping per un'ulteriore elaborazione. Vedere Risultati rappresentativi.
Representative Results
Sulla base dei dati ottenuti durante l'esecuzione dell'esperimento, in cui viene eseguita una vera e propria chiamata VoIP e seguendo i passaggi indicati dal protocollo per raccogliere queste informazioni, figura 2 illustra la funzione di distribuzione cumulativa del ritardo end-to-end misurato tra due elementi di apparecchiature dell'utente finale (cioè un computer portatile e un telefono IP). Questa apparecchiatura utente rappresenta due dispositivi interconnessi tramite le vAN AP del servizio di rete distribuito. Più dell'80% delle misurazioni di ritardo end-to-end erano inferiori a 60 ms e nessuna di esse era superiore a 150 ms, il che garantisce metriche di ritardo appropriate per l'esecuzione di una chiamata vocale.
Nella figura 3 viene illustrato lo scambio di messaggi di segnalazione DNS e SIP. Questi messaggi corrispondono alla registrazione di uno degli utenti nel server di telefonia IP (cioè l'utente il cui telefono IP è connesso al VNF AP dove è in esecuzione lo strumento "tcpdump") e alla creazione della chiamata vocale.
Infine, Figura 4 e Figura 5 Mostra il traffico dati acquisito durante la chiamata. In particolare, il primo rappresenta il flusso costante di pacchetti vocali trasmessi e ricevuti da uno dei telefoni wireless durante la chiamata, mentre il secondo illustra il nervosismo in avanti con un valore medio inferiore a 1 ms.
I risultati ottenuti nell'esperimento per le cifre di ritardo (ritardo end-to-end e nervosismo) soddisfano le raccomandazioni specificate dall'International Telecommunication Union - Telecommunication Standardization Sector (ITU-T)35. Di conseguenza, la chiamata vocale progrediva senza difetti e buona qualità del suono. Questo esperimento ha convalidato la fattibilità pratica dell'utilizzo di tecnologie NFV e UAV per distribuire un servizio di telefonia IP funzionale.
Figura 1: Panoramica del servizio di rete, che illustra i VNF, le entità in cui vengono eseguiti e le reti virtuali necessarie per la fornitura del servizio di telefonia IP. Fare clic qui per visualizzare una versione più grande di questa figura.
Figura 2: ritardo end-to-end. Rappresentazione del ritardo end-to-end offerto alle apparecchiature per l'utente finale collegate ai VNF AP. A tale scopo, la funzione di distribuzione cumulativa del ritardo end-to-end è stata calcolata dai campioni RTT misurati ottenuti con lo strumento da riga di comando "ping". Fare clic qui per visualizzare una versione più grande di questa figura.
Figura 3: Messaggi di registrazione utente e di segnalazione delle chiamate. Illustrazione del traffico di segnalazione (DNS e SIP) scambiato per registrare un utente nel server di telefonia IP e per creare e terminare la sessione multimediale che supporta l'esecuzione della chiamata vocale. Fare clic qui per visualizzare una versione più grande di questa figura.
Figura 4: flusso dei pacchetti vocali. Rappresentazione del traffico vocale scambiato durante la chiamata, misurata in uno dei VNF AP. (Abbreviazioni: RX - ricezione, RX , trasmissione, RTP , protocollo di trasporto in tempo reale). Fare clic qui per visualizzare una versione più grande di questa figura.
Figura 5: Evoluzione del jitter di rete durante la chiamata. Rappresentazione del jitter sperimentato dai pacchetti vocali trasmessi in avanti da un telefono all'altro. Fare clic qui per visualizzare una versione più grande di questa figura.
Discussion
Uno degli aspetti più importanti di questo esperimento è l'uso di tecnologie di virtualizzazione e standard NFV con piattaforme UAV. NFV presenta un nuovo paradigma che mira a disaccoppiare la dipendenza hardware delle funzionalità di rete, consentendo così la fornitura di queste funzionalità attraverso la softwarization. Di conseguenza, l'esperimento non dipende dall'uso delle apparecchiature hardware specificate nel protocollo. In alternativa, è possibile selezionare diversi modelli di computer a scheda singola, purché siano in linea con le dimensioni e la capacità di trasporto degli UAV e supportino i contenitori Linux.
Nonostante questa flessibilità in termini di selezione dell'hardware, tutti i contenuti forniti per la riproducibilità dell'esperimento sono orientati verso l'uso di tecnologie open source. In questo contesto, gli aspetti di configurazione e gli strumenti software sono condizionati all'uso di Linux come sistema operativo.
D'altra parte, l'esperimento considera l'interoperabilità di due diverse piattaforme computazionali (ad esempio, la piattaforma cloud UAV e la piattaforma cloud principale) per fornire un servizio di rete moderatamente complesso. Tuttavia, questo non è strettamente necessario e il protocollo potrebbe essere seguito per supportare scenari in cui è coinvolta solo la piattaforma cloud UAV.
Inoltre, la soluzione presentata potrebbe essere potenzialmente utilizzata in altri ambienti, in cui potrebbero essere disponibili piattaforme hardware con risorse limitate con la capacità necessaria per eseguire contenitori di virtualizzazione (ad esempio, l'Internet of Things o IoT, ambienti) In ogni caso, l'applicabilità di questa soluzione a i diversi ambienti e i suoi potenziali adattamenti richiederà un attento studio caso per caso.
Infine, va notato che i risultati presentati sono stati ottenuti in un ambiente di laboratorio e con i dispositivi UAV a terra o seguendo un piano di volo limitato e ben definito. Altri scenari che coinvolgono distribuzioni all'aperto possono introdurre condizioni che influenzano la stabilità del volo degli UAV e quindi le prestazioni del servizio di telefonia IP.
Disclosures
Gli autori non hanno nulla da rivelare.
Acknowledgments
Questo lavoro è stato parzialmente sostenuto dal progetto europeo H2020 5GRANGE (accordo di sovvenzione 777137) e dal progetto 5GCIty (TEC2016-76795-C6-3-R) finanziato dal Ministero spagnolo dell'Economia e della Competitività. Il lavoro di Luis F. Gonzalez è stato parzialmente sostenuto dal progetto europeo H2020 5GinFIRE (accordo di sovvenzione 732497).
Materials
| Name | Company | Catalog Number | Comments |
| AR. Drone 2.0 - Elite edition | Parrot | UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform. | |
| Bebop 2 | Parrot | UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform. | |
| 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 UAV cloud platform. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the UAV cloud platform. | |
| Linux Containers (LXC) | Canonical Ltd. | (Software) Virtualization technology that enables the supply of the Virtual Network Functions detailed in the experiment. Source-code available online: https://linuxcontainers.org | |
| Lithium Battery Pack Expansion Board. Model KY68C-UK | Kuman | Battery-power supply HAT (Hardware Attached on Top) for the computation units of the UAV cloud platform (i.e., the Raspberry Pis). In addition, this equipment encompasses the case used to attach the compute units (i.e., the Raspberry PIs or RPis) to the UAVs. | |
| MacBook Pro | Apple | Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript. | |
| ns-3 Network Simulator | nsnam | (Software) A discrete-event simulator network simulator which provides the underlying communication substrate to the emulation station explained in the "Protocol" section (more specifically in the step "2. Validate the functionality of the softwarization units via Emulation"). Source-code available online: https://www.nsnam.org | |
| 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/wikipub/index.php/OSM_Release_FOUR | |
| OpenStack - Release Ocata | OpenStack - Open source community | (Software) Open source software used for setting up both the UAV cloud platform and the core cloud within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu | |
| Ping | 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 core cloud platform presented in the experiment. | |
| 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 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. | |
| Prestige 2000W | ZyXEL | Voice over IP Wi-FI phone, compatible with the IEEE 802.11b wireless communications standard. This device is utilized to carry out the VoIP call through the network service hosted by platform described for the execution of the experiment. | |
| Raspberry PI. Model 3b | Raspberry Pi Foundation | Selected model of Single Board Computer (SBC) used for providing the computational capacity to the experiment's UAV cloud platform. | |
| SIPp | Open source tool | (Software) An open source test tool, which generates SIP protocol traffic. This tool allows to verify the proper support of the signalling traffic required in an IP telephony service such as the one deployed in the experiment. Source-code available online: http://sipp.sourceforge.net | |
| Tcpdump | Open source tool | (Software) An open source tool that enables the capture and analysis of the network traffic. Source-code available online: https://www.tcpdump.org | |
| Trafic | Open source tool | (Software) An open souce flow scheduler that is used for validating the capacity of the network service deployed to process data traffic generated during an IP telephony call. Source-code available online at: https://github.com/5GinFIRE/trafic |
References
- Sanchez-Aguero, V., Nogales, B., Valera, F., Vidal, I. Investigating the deployability of VoIP services over wireless interconnected Micro Aerial Vehicles. Internet Technology Letters. 1 (5), 40 (2018).
- Maxim, V., Zidek, K. Design of high-performance multimedia control system for UAV/UGV based on SoC/FPGA Core. Procedia Engineering. 48, 402-408 (2012).
- Vidal, I., et al. Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications. Sensors. 18 (10), 3421 (2018).
- Vidal, I., Valera, F., Díaz, M. A., Bagnulo, M. Design and practical deployment of a network-centric remotely piloted aircraft system. IEEE Communications Magazine. 52 (10), 22-29 (2014).
- Jin, Y., Minai, A. A., Polycarpou, M. M. Cooperative real-time search and task allocation in UAV teams. 42nd IEEE International Conference on Decision and Control. 1, IEEE. IEEE Cat. No. 03CH37475 7-12 (2003).
- Maza, I., Ollero, A. Multiple UAV cooperative searching operation using polygon area decomposition and efficient coverage algorithms. Distributed Autonomous Robotic Systems. 6, Springer. Tokyo. 221-230 (2007).
- Quaritsch, M., et al. Collaborative microdrones: applications and research challenges. Proceedings of the 2nd International Conference on Autonomic Computing and Communication Systems. , ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering. 38 (2008).
- Waharte, S., Trigoni, N., Julier, S. Coordinated search with a swarm of UAVs. 2009 6th IEEE Annual Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks Workshops. , IEEE. 1-3 (2009).
- De Freitas, E. P., et al. UAV relay network to support WSN connectivity. International Congress on Ultra-Modern Telecommunications and Control Systems. , IEEE. 309-314 (2010).
- European Telecommunications Standards Institute. Network Functions Virtualisation (NFV); Architectural Framework; Research Report ETSI GS NFV 002 V1.2.1. European Telecommunications Standards Institute. (ETSI). , (2014).
- An Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. ETSI OSM. , Available from: https://osm.etsi.org/ (2019).
- 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).
- Omnes, N., Bouillon, M., Fromentoux, G., Le Grand, O. A programmable and virtualized network & IT infrastructure for the internet of things: How can NFV & SDN help for facing the upcoming challenges. 18th International Conference on Intelligence in Next Generation Networks. , IEEE. 64-69 (2015).
- Rametta, C., Schembra, G. Designing a softwarized network deployed on a fleet of drones for rural zone monitoring. Future Internet. 9 (1), 8 (2017).
- Garg, S., Singh, A., Batra, S., Kumar, N., Yang, L. T. UAV-empowered edge computing environment for cyber-threat detection in smart vehicles. IEEE Network. 32 (3), 42-51 (2018).
- Mahmoud, S., Jawhar, I., Mohamed, N., Wu, J. UAV and WSN softwarization and collaboration using cloud computing. 3rd Smart Cloud Networks & Systems (SCNS). , IEEE. 1-8 (2016).
- González Blázquez, L. F., et al. NFV orchestration on intermittently available SUAV platforms: challenges and hurdles. 1th Mission-Oriented Wireless Sensor, UAV and Robot Networking (MISARN). , IEEE. (2019).
- Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F., Garcia-Reinoso, J. A NFV system to support configurable and automated multi-UAV service deployments. Proceedings of the 4th ACM Workshop on Micro Aerial Vehicle Networks, Systems, and Applications. , ACM. 39-44 (2018).
- Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F. Adaptable and automated small UAV deployments via virtualization. Sensors. 18 (12), 4116 (2018).
- Hoban, A., et al. An ETSI OSM Community White Paper, OSM Release FOUR: A Technical Overview. European Telecommunications Standards Institute. (ETSI). , Whitepaper (2018).
- Quick start installation and use guide. Open Source MANO Release FOUR. , Available from: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR (2019).
- Open Source Software for Creating Private and Public Clouds. OpenStack. , Available from: https://docs.openstack.org/ocata (2019).
- OpenStack Installation Tutorial for Ubuntu. OpenStack. , Available from: https://docs.openstack.org/ocata/install-guide-ubuntu/ (2019).
- Linphone. An Open Source VoIP SIP Softphone for voice/video calls and instant messaging. Linphone. , Available from: https://www.linphone.org (2019).
- An Open Source Project to easily build and deploy secure video-conferencing solutions. Jitsi. , Available from: https://jitsi.org (2019).
- Infrastructure for container projects. Linux Containers (LXC). , Available from: https://linuxcontainers.org (2019).
- A Discrete-Event Network Simulator for Internet Systems. Ns-3. , Available from: https://www.nsnam.org/ (2019).
- Kernel-based Virtual Machine (KVM). A virtualization solution for Linux. Linux. , Available from: https://www.linux-kvm.org (2019).
- Bridging & firewalling. Linux Foundation. , Available from: https://wiki.linuxfoundation.org/networking/bridge (2019).
- An Open Source test tool and/or traffic generator for the SIP protocol. SIPp. , Available from: http://sipp.sourceforge.net/ (2019).
- Trafic. An open source flow scheduler. , Available from: https://github.com/5GinFIRE/trafic (2019).
- Ubuntu Mate for the Raspberry Pi. , Available from: https://ubuntu-mate.org/raspberry-pi/ (2019).
- Enabling LXC (Linux Containers) as virtualization technology. OpenStack. , Available from: https://docs.openstack.org/ocata/config-reference/compute/hypervisor-lxc.html (2019).
- Open Source MANO Information Model. , Available from: https://osm.etsi.org/wikipub/index.php/OSM_Information_Model (2019).
- ITU-T. ITU-T Recommendation G.114. General Recommendations on the transmission quality for an entire international telephone connection; One-way transmission time. International Telecommunication Union - Telecommunication Standardization Sector. , (2003).
