Automatiserad distribution av en Internet Protocol telefonitjänst på obemannade luftfarkoster med nätverksfunktioner virtualisering

Summary

Syftet med det beskrivna protokollet är dubbelt: att konfigurera en virtualiseringsmiljö för nätverksfunktioner med obemannade luftfarkoster som beräkningsenheter som tillhandahåller den underliggande strukturen för att utföra virtualiserade nätverksfunktioner och att använda denna miljö för att stödja automatiserad utbyggnad av en funktionell Internet Protocol telefonitjänst över antenn fordon.

Abstract

Nätverket Function Virtualization (NFV) paradigm är en av de viktigaste möjliggörande teknik i utvecklingen av den 5^{: e} generationen av mobila nät. Denna teknik syftar till att minska beroendet av hårdvara i tillhandahållandet av nätverksfunktioner och tjänster med hjälp av virtualiseringstekniker som tillåter softwarization av dessa funktioner över ett abstraktions skikt. I detta sammanhang finns det ett ökat intresse av att utforska potentialen hos obemannade luftfarkoster (UAV) för att erbjuda en flexibel plattform som kan möjliggöra kostnadseffektiv NFV-verksamhet över avgränsade geografiska områden.

För att visa att det är praktiskt genomförbart att använda NFV Technologies i UAV-plattformar presenteras ett protokoll för att skapa en funktionell NFV-miljö baserad på tekniker med öppen källkod, där en uppsättning små UAV tillhandahåller de beräkningsresurser som stöder användning av måttligt komplicerade nättjänster. Protokollet specificerar sedan de olika steg som krävs för att stödja automatiserad distribution av en IP-telefonitjänst (Internet Protocol) över ett nätverk av sammankopplade UAV, och utnyttjar kapaciteten hos den konfigurerade NFV-miljön. Experimenterande resultat visar att tjänsten fungerar korrekt efter distributionen. Även om protokollet fokuserar på en viss typ av nätverkstjänst (dvs. IP-telefoni), kan de beskrivna stegen fungera som en allmän vägledning för att distribuera andra typer av nätverkstjänster. Å andra sidan beaktar protokoll beskrivningen konkret utrustning och programvara för att ställa in NFV-miljön (t. ex. särskilda datorer med enkel kartong och programvara med öppen källkod). Användningen av andra maskinvaru-och mjukvaruplattformar kan vara möjlig, även om den specifika konfigurations aspekten i NFV-miljön och tjänstdistributionen kan medföra variationer i förhållande till de som beskrivs i protokollet.

Introduction

Ett av de mest eftertraktade målen inom den nya eran av mobil kommunikation (mest känd som den 5^{: e} mobila generationen eller 5G) är att kunna tillhandahålla robusta informationstekniktjänster i situationer där den primära telekommunikationsinfrastrukturen kanske inte är tillgänglig (t. ex. på grund av en nödsituation). I detta sammanhang får UAVs allt större uppmärksamhet från forskarsamfundet på grund av deras inneboende mångsidighet. Det finns många verk som använder dessa enheter som en hörnsten för tillhandahållandet av ett stort utbud av tjänster. Till exempel har litteraturen analyserat kapaciteten hos dessa enheter för att bygga en antenn kommunikationsinfrastruktur för att rymma multimediatjänster^1,2,3. Vidare har tidigare forskning visat hur samarbetet mellan flera UAV kan utvidga funktionaliteten hos olika kommunikationstjänster såsom Surveillance⁴, Collaborative search och Rescue^5,6,7,8eller jordbruksnäringen⁹.

Å andra sidan har NFV-teknologin förvärvat stor betydelse inom telekomoperatörerna som en av 5G-nyckelenablers. NFV representerar en paradigmatisk förändring när det gäller telekommunikation infrastruktur genom att lindra det nuvarande beroendet av nätverksutrustning på specialiserad hårdvara genom softwarization av nätverksfunktioner. Detta möjliggör en flexibel och smidig distribution av nya typer av kommunikationstjänster. För detta ändamål bildade Europeiska institutet för telekommunikationsstandarder (ETSI) en Specifikations grupp för att definiera NFV: s arkitektoniska ramverk¹⁰. Dessutom är ETSI närvarande värd för Open Source mano (OSM) grupp¹¹, som ansvarar för att utveckla en NFV Management and ORCHESTRATION (Mano) programvara stack i linje med definitionen av ETSI NFV arkitektoniska ramverket.

Mot bakgrund av alla ovannämnda överväganden studeras för närvarande synergisk konvergens mellan UAV-och NFV-teknik i utvecklingen av nya nätverkstillämpningar och-tjänster. Detta illustreras av flera forskningsarbeten i litteraturen som pekar ut fördelarna med dessa typer av system^14,15,16, identifiera utmaningarna i denna konvergens och dess saknade aspekter, belysa framtida forskningslinjer om detta ämne¹⁷, och presentera pionjär lösningar baserade på öppen källkod teknik.

I synnerhet integrationen av NFV Technologies i UAV Arena möjliggör en snabb och flexibel utbyggnad av nättjänster och applikationer över avgränsade geografiska områden (t. ex. en IP-telefonitjänst). Efter den här metoden kan ett antal UAV distribueras över en viss plats, transportera beräkningsplattformar som nyttolast (t. ex. små enskilda datorer). Dessa beräkningsplattformar skulle tillhandahålla en programmerbar nätverksinfrastruktur (d.v.s. en NFV-infrastruktur) över distributionsområdet, vilket stöder Instansieringen av nätverkstjänster och program under kontroll av en MANO-plattform.

Oaktat fördelarna, presenterar förverkligandet av denna uppfattning en rad grundläggande utmaningar som måste åtgärdas noggrant, såsom lämplig integration av dessa beräkningsplattformar som en NFV-infrastruktur, med hjälp av en befintlig NFV-programvarustack, så att en NFV-orkestreringstjänst kan distribuera virtuella funktioner på UAVs; begränsningarna i fråga om de beräkningsmässiga resurser som tillhandahålls av beräkningsplattformar, eftersom de UAVs som transporterar dem kan vanligtvis uppvisa begränsningar i fråga om storlek, vikt och beräkningskapacitet för nyttolast utrustning. den korrekta placeringen av de virtuella funktionerna på UAV (dvs. att välja den bästa UAV-kandidaten för att distribuera en viss virtuell funktion); underhåll av kontroll kommunikationen med UAV för att hantera VNFs: s livscykel, trots den potentiellt intermittenta tillgängligheten av nätverkskommunikation med dem (t. ex. orsakad av mobilitet och batteri begränsningar). den begränsade drifttiden för UAVs på grund av deras batteriförbrukning; och migreringen av de virtuella funktionerna när en UAV behöver bytas ut på grund av dess batteri utmattning. Dessa fördelar och utmaningar beskrivs i tidigare arbete^18,19 som omfattar utformningen av ett NFV-system som kan stödja automatiserad utbyggnad av nätverksfunktioner och tjänster på UAV-plattformar, samt validering av den praktiska genomförbarheten av denna konstruktion.

I detta sammanhang fokuserar denna uppsats på att beskriva ett protokoll för att möjliggöra automatiserad utbyggnad av måttligt komplexa nättjänster över ett nätverk av UAV med hjälp av NFV-standarderna och Open Source-teknikerna. För att illustrera de olika stegen i protokollet presenteras en ny utformning av ett experiment som presenteras i Nogales et al.¹⁹ , som består av utbyggnaden av en IP-telefontjänst. För att underlätta reproducerbarheten av detta arbete anses verklig flygning vara frivillig i det presenterade förfarandet, och prestandaresultat erhålls med UAV-enheterna på marken. Intresserade läsare bör kunna replikera och validera utförandet av protokollet, även i en kontrollerad laboratoriemiljö.

Bild 1 illustrerar den nättjänst som utformats för den här proceduren. Denna nättjänst byggs som en sammansättning av specifika softwarization enheter (kategoriseras i NFV-paradigmet som virtuella nätverksfunktioner, eller VNFs) och tillhandahåller funktionaliteten hos en IP-telefontjänst till användare i närheten av UAVs. VNF som komponerar tjänsten definieras enligt följande:

• Åtkomstpunkt VNF (AP-VNF): denna VNF ger en Wi-Fi-åtkomstpunkt till slutanvändarens utrustning (dvs. IP-telefoner i detta experiment).
• IP-telefoniserver VNF (IP-telefoni-Server-VNF): det är ansvarig för att hantera samtalet signalering meddelanden som utbyts mellan IP-telefoner för att upprätta och avsluta ett röstsamtal.
• Domännamnssystemet VNF (DNS-VNF): denna VNF tillhandahåller en namnmatchningstjänst, som normalt behövs i IP-telefonitjänster.
• Access router VNF (AR-VNF): ger nätverksrouting funktioner, stödja utbyte av trafik (dvs, ring signalering i detta experiment) mellan IP-telefoner och tele kommunikationsoperatören domän.
• Core router VNF (CR-VNF): tillhandahåller nätverksroutningsfunktioner inom telekommunikations operatörs domänen, som erbjuder åtkomst till operatörsspecifika tjänster (dvs. IP-telefoniservern) och externa datanätverk.

Dessutom visar figur 1 de fysiska enheter som används för experimentet, hur de är sammankopplade och den specifika allokeringen av vnfs till enheter.

Protocol

1. tidigare förutsättningar för experimentet

1. Installera program stacken Management och Orchestration (MANO) som tillhandahålls av Open Source MANO (OSM)-projektet. Specifikt använder detta experiment OSM release FOUR²⁰, som kan utföras på en enda serverdator eller i en virtuell maskin (VM) som uppfyller de krav som anges av OSM-communityn: Ubuntu 16,04 som operativsystem (64-bitars variant-avbildning), två centralprocessorer (CPU), 8 GB RAM-minne, en lagringsdisk på 40 GB och ett enda nätverksgränssnitt med Internet åtkomst. Proceduren för att installera OSM release FOUR tillsammans med dess tekniska detaljer finns i online-dokumentationen som tillhandahålls av OSM community²¹.
2. Konfigurera en plattform för molnbaserad databehandling och tillhandahålla funktioner för en VIM-kompatibel (Virtual Infrastructure Manager) med OSM release FOUR. För det här experimentet används OpenStack release Ocata²² , som körs i en virtuell dator med Ubuntu 16,04 som operativsystem, fyra processorer, 16 GB RAM och 200 GB lagringsdisk. I experimentet hanterar VIM en NFV-infrastruktur (NFVI) som integreras med två högprofilerade serverdatorer, var och en med Ubuntu 16,04 som operativsystem, åtta processorer, 128 GB RAM och 4 TB lagringsdisk). All information om hur du konfigurerar en plattform för molnbaserad databehandling ingår i installationshandboken som ingår i OpenStack-dokumentationen²³. Den här molnplattformen kallas för molnplattformen Core.
3. Konfigurera en ytterligare plattform för molnbaserad databehandling för UAVs kallas UAVs molnplattform.
   1. Se till att denna plattform har en VIM baserad på OpenStack release Ocata. I det här fallet är de resurser som används av VIM-installationen Ubuntu 16,04 som operativsystem, två processorer, 6 GB RAM, 100 GB lagringsdisk och en extern Wi-Fi USB-adapter.
   2. NFVI integreras i denna molnplattform består av en enda fast Compute Server (Ubuntu 16,04 som operativsystem, åtta processorer, 8 GB RAM, 128 GB lagringsdisk, och en extern Wi-Fi USB-adapter) och tre enda bräde datorer (SBCs). Den senare ger en hårdvaruplattform som lätt kan vara integrerats på en UAV. Se avsnitt 3 för proceduren för att installera en UAV-molnplattform med dessa enheter som beräkningsnoder.
4. Utrusta varje SBC med en batteri-strömförsörjning hårdvara ansluten ovanpå (hatt) för att säkerställa driften av dessa enheter även när de är i rörelse, som bärs av en UAV.
   Anmärkning: steg 1,5 är frivillig eftersom tillhandahållandet av nättjänsten i experimentet inte är beroende av att ha UAV. Dessutom är SBCs transporteras som nyttolasten av UAV och inga andra ytterligare anslutningar (t. ex., Ethernet eller USB) behövs, eftersom den nätverkskommunikation som krävs för korrekt drift av IP-telefonitjänsten tillhandahålls av SBCs, via sina Wi-Fi-adaptrar, och strömförsörjningen tillhandahålls av Power-Supply hatt som nämns i steg 1,4.
5. Bifoga varje SBC som nyttolasten för en UAV genom ett fästande tillbehör. I det här experimentet har tre kommersiella UAV valts för att transportera de beräkningsenheter som erbjuds av SBCs.
6. Välj två trådlösa röst-över-IP-telefoner (VoIP) som stöder trådlös kommunikationsstandard IEEE 802.11 b. den här modellen ger trådlös kommunikation via Wi-Fi. Som ett alternativ, kan röstsamtalet utföras med hjälp av softphone applikationer såsom linphone²⁴ eller Jitsi²⁵.
7. Som ett experimentellt krav, se till att det finns: a) Layer-3-kommunikation mellan OSM-programvarustacken och var och en av VIMs för att möjliggöra iscensättningen av nättjänsten som utvecklats för detta experiment, b) Layer-3-kommunikation mellan OSM och VNFs vid varje molnplattform för att stödja VNF konfigurationsprocedurer och c) Layer-3 kommunikation mellan VNFs körs på varje VIM för att möjliggöra en väl fungerande nättjänst.
8. Allt innehåll som behövs för att genomföra experimentet finns i den offentliga experiment databasen http://VM-images.Netcom.it.uc3m.es/jove/.

2. validering av funktionaliteten hos softwarization enheter via emulering

Anmärkning: för att bevisa lämplig drift av nätverket tjänsten av experimentet (se figur 1) under realistiska distributionsvillkor, en specialspecifik emuleringsplattform baserad på Linux-containrar²⁶ och ns-3²⁷ användes. Denna plattform tillåter emulera multi-hop antenn länkar och definiera egenskaperna hos dessa länkar (t. ex. längd på den trådlösa kommunikationen länkar, mönster av datapaket förluster, radioteknik som används i den trådlösa kommunikationen, etc.). Det här avsnittet av protokollet beskriver således de steg som ska följas för att kontrollera att IP-telefontjänsten fungerar korrekt under realistiska trådlösa kommunikationslänk villkor via emuleringsplattformen.

1. Hämta emuleringsplattformen från experiment databasen. Plattformen är tillgänglig som en virtuell maskin, som heter "UAV-NFV-jove-experiment. qcow", kompatibel med KVM virtualiseringsteknik²⁸. Den här datorn innehåller en precreated mall som emulerar nätverkstjänsten och multi-UAV scenariot som visas i figur 1 och en användare med administratörsbehörighet som kan köra mallen.
   ANMÄRKNINGAR: som standard körs följande steg automatiskt när den virtuella emuleringsplattformen startas: a) den virtuella miljön är konfigurerad för att aktivera nätverksemulering (d.v.s. nätverksgränssnitt, Linux-bryggor²⁹); b) Linux-behållare som representerar de olika fysiska komponenterna i testbädden (dvs. SBCs och den fasta beräknings servern för UAV-molnplattformen och beräknings servern för molnplattformen Core) skapas. och c) de funktioner som tillhandahålls av den olika VNFs för IP-telefontjänsten (dvs. åtkomstpunkter, routrar, DNS-serve och IP-telefoniserver) distribueras som Linux-containrar över deras motsvarande emulerade SBCs-och beräkningsservrar.
2. Innan valideringsprocessen, ställa in en emulerad multi-hop antenn nätverk med hjälp av ns-3 simulator, för att möjliggöra anslutning mellan de olika nätverks deltagarna. Denna procedur kommer att emulera den realistiska trådlösa kommunikationen som sker i scenariot som visas i figur 1 (d.v.s. Wi-Fi ad-hoc-nätverket, vilket möjliggör datautbytet mellan noderna i UAV-molnplattformen och de trådlösa nätverken som erbjuds av de två Wi-Fi-åtkomstpunkterna som finns i tjänsten).
   1. Skapa multi-hop Aerial-nätverket. För detta ändamål, köra multi-hop-Aerial-net.sh skriptet (finns i emuleringsplattformen maskin) med hjälp av följande kommando: sudo sh/Home/jovevm/scripts/multi-hop-Aerial-net.sh > multi-hop-Aerial-net-trace. log 2 > & 1 &. Det här kommandot beskriver simuleringen spårningen i den angivna loggfilen för att aktivera felsökning i händelse av fel.
   2. Kontrollera om nätverket har skapats. För detta ändamål, kontrollera om Linux-containrar "IP-Phone-a" och "IP-Phone-b" (illustrerad i figur 1 som slutanvändarens utrustning som ansluts till en AP-VNF) har fått en IP-adress via DHCP-tjänsten, som endast är tillgänglig via multi-hop antenn nätet. Status för Linux-behållaren som körs i emuleringsdatorn, samt deras IP-adresser, kan kontrolleras med hjälp av kommandot LXC lista.
3. Kontrollera kapaciteten för den emulerade nätverkstjänsten för att bearbeta de signal meddelanden som behövs för att konfigurera IP-telefonsamtalet. För detta ändamål, både "IP-telefon-a" och "IP-Phone-b" Linux-containrar har installerat "SIPp" verktyg³⁰. "SIPp" ger funktionalitet för att emulera en IP-telefon skapa de nämnda signalering meddelanden, skicka dem till en IP-telefoniserver, och bearbeta svaret för att kontrollera den korrekta driften av den senare.
   1. Kör skriptet test-Signaling.sh i båda behållarna, som kör "sipp" verktyg för att generera och skicka signalering meddelanden till IP-telefoni-Server-VNF.
   2. Kontrollera scenario skärmen som tillhandahålls av körningen av föregående steg. Mottagningen av svaret "200" visar hur IP-telefoni-Server-VNF fungerar korrekt.
4. Verifiera att nätverkstjänsten kan bearbeta den datatrafik som genereras under ett IP-telefonsamtal. För att göra det, är flödet schemaläggning "trafic" Tool³¹ installeras i "IP-telefon-a" och "IP-Phone-b" Linux-containrar.
   1. Kör följande kommando för att starta Server agenten för trafic: LXC exec IP-Phone-b sh called-Party.sh.
   2. Kör sedan följande kommando för att starta klientagenten för trafic och få nätverksstatistik: LXC exec IP-telefon-en sh Caller.sh. Datatrafiken som emulerar ett röstsamtal avslutas efter 60 s. Skriptet visar ett bekräftelsemeddelande och de mest signifikanta prestandamåtten för rösttrafiken.
   3. Kontrollera de erhållna måtten och kontrollera att IP-telefontjänsten effektivt kan stödja en interaktiv röstkonversation. För att göra detta, se den information som ingår i avsnittet om representativa resultat.

3. UAVs molnplattform konstruktion

1. Välj den modell av SBC som kan tillhandahålla virtualiseringsunderlaget för att köra Lightweight VNFs. De tekniska specifikationerna för SBC-enheter som används under experimentet är: fyra processorer, 1 GB RAM och en 32 GB lagringsdisk. Dessutom har varje SBC tre nätverksgränssnitt: ett Ethernet-gränssnitt, ett integrerat Wi-Fi-gränssnitt och en extern Wi-Fi USB-adapter.
2. Förbered SBCs för att därefter integreras i UAVs molnplattform.
   1. Installera Ubuntu Mate³² 16.04.6 som operativsystem, med tanke på att OpenStack installationspaket ingår i denna Linux-distribution.
   2. Installera och konfigurera de nödvändiga paketen som anges i OpenStack-dokumentationen³³ så att SBCS kan fungera som beräkningsnoder i UAV-molnplattformen. Efter den föregående guiden, aktivera användningen av Linux-behållare i konfigurationen av OpenStack-paket. Behållarvirtualisering används på grund av resursbegränsningarna för de enheter som vanligtvis kan vara påbordade på små UAV.
   3. I SBC hämtar och kör du skriptet RPI-Networking-Configuration.shsom finns tillgängligt i experiment databasen. Det här skriptet aktiverar den trådlösa kommunikationen i SBCs, samt den konfiguration som krävs för att tillåta skapandet av virtuella nätverk som är anslutna till de trådlösa gränssnitten.
   4. Hämta och kör skriptet vim-Networking-Configuration.sh, som finns tillgängligt i experiment databasen, i den värd som kör UAV Cloud Platform vim. Det här skriptet övervakar inrättandet av den trådlösa kommunikationen i VIM för att möjliggöra informationsutbytet med SBCs.
      Anmärkning: när nätverket är väl konfigurerad och VIM har anslutning med SBCs integrerar VIM automatiskt dem i UAV molnplattform som beräkningsenheter som kan köra VNFs
3. Skapa en tillgänglighetszon för OpenStack för varje SBCs. Detta gör det möjligt att distribuera var och en av Lightweight VNFs för experimentet i en lämplig UAV-enhet. Om du vill göra det loggar du in på det grafiska webbgränssnittet som tillhandahålls av VIM med administratörsautentiseringsuppgifter, skapar tillgänglighetszonerna på fliken administratör > system > värd aggregeringar och redigerar varje tillgänglighetszon för att lägga till lämplig värddator (dvs. varje SBC integreras i UAV-molnplattformen).
4. Kontrollera korrekt inställning av UAV-molnplattformen. Det gör du genom att öppna fliken administratör > system > system information med samma inloggning som i föregående steg och klicka i avsnittet dator tjänst och nätverks agenter för att kontrollera att status för de objekt som visas är "Alive" och "up".

4. Konfigurera experimentet

1. Ladda ner VNF-bilderna som implementerar de olika komponenterna i IP-telefontjänsten: AP-VNF, DNS-VNF, IP-telefoni-Server-VNF, AR-VNF och CR-VNF. Dessa avbildningar kan hämtas från experiment databasen.
2. Ladda upp VNF bilder till deras korrespondent VIM (dvs AP-VNF och DNS-VNF till UAV Cloud Platform VIM) och VoIP-VNF till kärnan molnplattform VIM. För att göra detta loggar du in i det grafiska användargränssnittet för webben som tillhandahålls av varje VIM med administratörsautentiseringsuppgifterna, klickar på knappen Skapa bild på fliken administratör > system > bilder och skapar en bild med hjälp av det formulär som visas och väljer lämplig bild. Den här processen görs på motsvarande VIM för varje avbildning som har hämtats i föregående steg.
3. Hämta VNF beskrivningar (vnfds) av experimentet från experiment databasen. Dessa beskrivningar innehåller mallar som beskriver de operativa kraven för en VNF, samt placeringsprinciper som anger tillgänglighetszonen som ansvarar för värd för VNF själv. Mer information om NFV beskrivningar finns i informationsmodellen för OSM³⁴.
4. Ladda upp VNFDs. Använd en webbläsare för att komma åt OSM grafiskt användargränssnitt och logga in med administratörsautentiseringsuppgifter. Dra och släpp sedan VNFDs i VNF-paketen fliken.
5. Hämta NSD (Network Services Descriptor) från experiment databasen. Den här beskrivningen är en mall som anger VNFs som omfattar tjänsten, samt hur dessa VNFs är sammankopplade.
6. Ladda upp NSD. Dra och släpp NSD på fliken ns-paket i det grafiska ANVÄNDARGRÄNSSNITTET OSM.
7. Använd det grafiska användargränssnittet i OSM, Lägg till ett VIM-konto för UAV Cloud Platform VIM och för Core Cloud Platform VIM. Till gör den här, tillträde den vim räkenskapen tab med det administratören credentials, klick på det knapp + ny vim och komplett den förvisat form med det begäret informationen. Upprepa denna åtgärd för båda VIMs.

5. exekvera experimentet

1. Distribuera nätverkstjänsten. På fliken ns-paket i det grafiska ANVÄNDARGRÄNSSNITTET OSM klickar du på knappen INSTANSIERA ns för NSD som laddades upp i steg 4,6. Fyll sedan i formuläret som visas, vilket indikerar den VIM som kommer att användas för att distribuera varje VNF komponera NS. Dessutom är OSM ansvarig för att behandla placeringsprinciper som anges i VNFDs att ange VIM som tillgänglighetszon (dvs en beräkningsenhet i vår testbädd) ansvarar för värd för varje VNF. För det här experimentet placeras VNFs i beräknings enheterna enligt illustrationen i figur 1.
   Obs: som en alternativ metod ger OSM ett kommandoradsgränssnitt som möjliggör direkt användarinteraktion. En användare som återger det här experimentet kan använda det här kommandoradsgränssnittet, i stället för det grafiska gränssnittet, för att utföra de olika stegen som definieras i det här protokollet, särskilt de steg som rör onboarding av en VNF eller en NS-beskrivare, samt att distribuera en nättjänst.
2. Vänta tills OSM grafiskt användargränssnitt visar framgången för distributionen av nätverkstjänsten.
   Anmärkning: driften av nättjänsten är helt oberoende av flygningen av UAV: IP-telefonitjänsten kan tillhandahållas när UAV flyger eller spara batteriförbrukningen uppe på en yta. Sålunda, steg 5,3 är valfri.
3. Ta av UAVs. Logga in på mobilapplikationen och kontrollera varje UAV-flygning för att hålla den i en mellanliggande höjd och undvika den turbulens som orsakas av att motorerna roterar i närheten av en yta.
4. Förbered var och en av IP-telefonerna för att utföra samtalet.
   1. Anslut en trådlös VoIP-telefon till var och en av de åtkomstpunkter som erbjuds av nättjänsten. För detta ändamål, ange SSID (Service Set Identifier) i menyn > Wireless > SSID fliken och välj infrastruktur läge i menyn > trådlöst > nätverksläge sektion. Välj slutligen nätverkskonfigurationen via DHCP Dynamic Host Configuration Protocol () i menyn > net Settings > fliken nätverksläge .
   2. Konfigurera SIP-parametrarna ( Session Initiation Protocol ) för att aktivera lämpligt utbyte av signal meddelanden med IP-telefoniservern. I detta sammanhang, tillgång till menyn > SIP-inställningar fliken och ange värdnamnet för IP-telefoniserver vnf ("DronesVoIP.net") i registratorn > registrar IP och Proxy Server > proxy IP flikar. Dessutom skapa ett användarkonto som introducerar namnet på användaren (t. ex. uppringare-A) i användarkontot > telefonnummer och användarkonto > användarnamn avsnitt.
   3. Skapa en post i telefonboken för en av IP-telefonerna som ger information om den användare som ska anropas. För att göra detta, Välj menyn ≫ Telefonbok > Lägg till post fliken och fyll i de begärda parametrarna som visas på displayen enligt följande: visningsnamn = Caller-B; User info = uppringare-B; Värd IP = dronesVoIP.net; Port = 5060. Slutligen väljer du alternativet "proxy" kontra P2P (peer-to-peer).
5. Starta samtalet till den andra parten. Det gör du genom att välja den uppringda parten med hjälp av meny ≫ telefon boks > Sökalternativ för IP-telefonen. Tryck sedan på samtalsknappen. När den andra IP-telefonen börjar ringa, godkänn det inkommande samtalet med samtalsknappen.

6. förfarande för att samla experimentella resultat

1. Anslut en bärbar dator till en av de trådlösa åtkomstpunkter och kör ping kommandoradsverktyget till IP-adressen för den telefon som är ansluten till den andra AP under 180 s. IP-adressen kan kontrolleras i menyn > information > IP-adressalternativ för IP-telefonen när anslutningen har upprättats med AP. Spara rund turs tiden (RTT) mätningar, omdirigera utdata från ping -verktyget till en fil.
2. Exekvera tcpdump kommandoradsverktyget i en av de kör AP vnfs att fånga den trafik som utbyts under IP-samtal. Spara den här trafiken i en fil som aktiverar kommandorads verktygets Skriv flagga vid körningstiden och ange filens namn.
3. Utför ett nytt IP-telefonsamtal. Underhåll samtalet för önskad tidsperiod (t. ex. 1 min). Avsluta samtalet och tryck på knappen för att hänga upp en av IP-telefonerna.
4. Behåll filerna som genereras av tcpdump och ping verktyg för vidare bearbetning. Se representativa resultat.

Representative Results

Baserat på de data som erhållits under utförandet av experimentet, där ett riktigt VoIP-samtal utförs och efter de steg som anges av protokollet för att samla in denna information, visar figur 2 den kumulativa fördelningsfunktionen för slutpunkt till slutpunkt-fördröjning mätt mellan två slutanvändarutrustning (dvs. en bärbar dator och en IP-telefon). Den här användarutrustningen representerar två enheter som är sammankopplade via AP VNFs för den distribuerade nätverkstjänsten. Mer än 80% av slutpunkt till slutpunkt-fördröjning mätningar var under 60 MS, och ingen av dem var högre än 150 ms, vilket garanterar lämplig fördröjning mått för utförandet av ett röstsamtal.

Figur 3 illustrerar utbytet av DNS-och SIP-signaleringsmeddelanden. Dessa meddelanden motsvarar registreringen av en av användarna i IP-telefoniserver (dvs, den användare vars IP-telefon är ansluten till AP VNF där "tcpdump" verktyget körs) och till inrättandet av röstsamtal.

Slutligen, figur 4 och figur 5 visar datatrafik som fångas under samtalet. I synnerhet den första representerar den ständiga strömmen av röst paket som sänds och tas emot av en av de trådlösa telefonerna under samtalet, medan den senare illustrerar jitter i framåtriktningen med ett genomsnittligt värde lägre än 1 MS.

De resultat som erhölls i experimentet för fördröjnings siffrorna (slutpunkt till slutpunkt-fördröjning och jitter) uppfyller de rekommendationer som anges av den internationella standardiserings sektorn (ITU-T)³⁵. Följaktligen utvecklades röstsamtalet utan problem och god ljudkvalitet. Detta experiment validerade den praktiska genomförbarheten av att använda NFV Technologies och UAVs att distribuera en funktionell IP-telefonitjänst.

Bild 1: översikt över nättjänsten, som skildrar VNFs, de enheter i vilka de utförs och de virtuella nätverk som behövs för tillhandahållandet av IP-telefontjänsten. Vänligen klicka här för att se en större version av denna siffra.

Bild 2: fördröjning vid punkt Representation av slutpunkt till slutpunkt-fördröjning som erbjuds slutanvändarens utrustning som är ansluten till AP VNFs. För detta ändamål har den kumulativa fördelningsfunktionen för slutpunkt till slutpunkt-fördröjning beräknats från de uppmätta RTT-exemplen som erhålls med kommandoradsverktyget "ping". Vänligen klicka här för att se en större version av denna siffra.

Figur 3: användarregistrering och samtal signal meddelanden. Illustration av signal trafiken (DNS och SIP) utbytt för att registrera en användare i IP-telefoniservern och för att skapa och avsluta multimedie sessionen som stöder utförandet av röstsamtalet. Vänligen klicka här för att se en större version av denna siffra.

Bild 4: ström av röst paket. Representation av rösttrafiken utbytt under samtalet, mätt vid en av AP VNFs. (förkortningar: RX = Receive, RX = Sänd, RTP = Real-Time Transport Protocol). Vänligen klicka här för att se en större version av denna siffra.

Figur 5: nätverks Jitters evolution under samtalet. Representation av jitter upplevs av de överförda röst paketen i framåtriktningen från en telefon till en annan. Vänligen klicka här för att se en större version av denna siffra.

Discussion

En av de viktigaste aspekterna av detta experiment är användningen av virtualiseringstekniker och NFV-standarder med UAV-plattformar. NFV presenterar ett nytt paradigm som syftar till att frikoppla hårdvaran beroendet av nätverksfunktioner, vilket möjliggör tillhandahållandet av dessa funktioner genom softwarization. Experimentet är därför inte beroende av användningen av den maskin varu utrustning som anges i protokollet. Alternativt kan olika modeller av enskilda kartong datorer väljas, så länge de är i linje med dimensionerna och transportkapaciteten hos UAVs och de stöder Linux-containrar.

Oaktat denna flexibilitet när det gäller val av maskinvara, är allt innehåll som tillhandahålls för reproducerbarheten av experimentet inriktat på användning av tekniker med öppen källkod. I det här sammanhanget är konfigurations aspekterna och programvaruverktygen villkorat av att Linux används som operativsystem.

Å andra sidan, försöket anser att samverkan mellan två olika beräkningsplattformar (dvs, den UAV molnplattform och kärnan molnplattform) för att ge en måttligt komplicerad nättjänst. Detta är dock inte strikt behövs, och protokollet kan följas för att stödja scenarier där endast UAV molnplattform är inblandad.

Dessutom kan den presenterade lösningen potentiellt användas i andra miljöer, där resursbegränsade maskinvaruplattformar kan vara tillgängliga med den kapacitet som krävs för att köra virtualiseringscontainrar (t. ex. Sakernas Internet eller IoT, miljöer). I vilket fall som helst kommer tillämpligheten av denna lösning på olika miljöer och dess potentiella anpassningar att kräva en noggrann undersökning i varje enskilt fall.

Slutligen bör det noteras att de presenterade resultaten har erhållits i laboratoriemiljö och med UAV-anordningar som är jordade eller följer en begränsad och väl definierad färdplan. Andra scenarier som inbegriper utomhusbruk kan införa villkor som påverkar stabiliteten i UAVs-flygningen, och därmed prestandan för IP-telefontjänsten.

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