Automatiseret installation af en internet protokol telefonitjeneste på ubemandede luftfartøjer ved hjælp af netværksfunktioner virtualisering

Summary

Formålet med den beskrevne protokol er dobbelt: at konfigurere en netværksfunktion virtualiseringsmiljø ved hjælp af ubemandede luftfartøjer som beregningsenheder, der leverer den underliggende struktur til at udføre virtualiserede netværksfunktioner og til at bruge dette miljø til at understøtte automatiseret udrulning af en funktionel internetprotokol telefonitjeneste over luft køretøjerne.

Abstract

Network funktion Virtualization (NFV) paradigme er en af de vigtigste støtteteknologier i udviklingen af^{den 5 gene} ration af mobile netværk. Denne teknologi har til formål at mindske afhængigheden af hardware i levering af netværksfunktioner og tjenester ved hjælp af virtualiserings teknikker, der tillader softwarisering af disse funktionaliteter over et abstraktionslag. I denne sammenhæng er der stigende interesse for at udforske potentialet i ubemandede luftfartøjer (UAV'er) for at tilbyde en fleksibel platform, som kan muliggøre omkostningseffektive NFV-operationer over afgrænsede geografiske områder.

For at demonstrere de praktiske muligheder for at udnytte NFV-teknologierne i UAV-platforme præsenteres en protokol for at oprette et funktionelt NFV-miljø baseret på open source-teknologier, hvor et sæt små UAV'er leverer de beregningsressourcer, der understøtter implementeringen af moderat komplekse netværkstjenester. Derefter beskriver protokollen de forskellige trin, der er nødvendige for at understøtte automatiseret udrulning af en IP-telefonitjeneste (Internet Protocol) via et netværk af indbyrdes forbundne UAV'er, som udnytter kapaciteten i det konfigurerede NFV-miljø. Eksperimenter resultater demonstrere den korrekte drift af tjenesten efter dens indsættelse. Selv om protokollen fokuserer på en bestemt type netværkstjeneste (dvs. IP-telefoni), kan de beskrevne trin tjene som en generel vejledning i at implementere andre typer netværkstjenester. På den anden side betragter protokol beskrivelsen beton udstyr og software til at opsætte NFV-miljøet (f. eks. specifikke computere med enkelt bord og open source-software). Det kan være muligt at udnytte andre hardware-og software platforme, selv om det specifikke konfigurations aspekt af NFV-miljøet og tjeneste udrulningen kan medføre variationer i forhold til dem, der er beskrevet i protokollen.

Introduction

Et af de mest eftertragtede mål inden for den nye æra af mobil kommunikation (oftest kendt som^{den 5.} mobile generation eller 5g) er at kunne levere robuste informationsteknologi tjenester i situationer, hvor den primære telekommunikationsinfrastruktur muligvis ikke er tilgængelig (f. eks. på grund af en nødsituation). I denne sammenhæng får UAV'er stigende opmærksomhed fra forskersamfundet på grund af deres iboende alsidighed. Der er talrige værker, der bruger disse enheder som en hjørnesten for levering af et stort udvalg af tjenester. For eksempel har litteraturen analyseret kapaciteten af disse enheder til at bygge en luft kommunikationsinfrastruktur til at rumme multimedietjenester^1,2,3. Desuden har forudgående forskning vist, hvordan samarbejdet mellem flere UAV'er kan udvide funktionaliteten af forskellige kommunikationstjenester som overvågning⁴, samarbejde eftersøgning og redning^5,6,7,8eller Agribusiness⁹.

På den anden side har NFV-teknologien fået stor betydning inden for teleoperatørerne som en af de 5G-nøgle katalysatorer. NFV repræsenterer en paradigmatisk ændring med hensyn til telekommunikationsinfrastrukturen ved at lindre den nuværende afhængighed af netværksapparater på specialiseret hardware gennem softwarisering af netværkets funktionaliteter. Dette muliggør en fleksibel og smidig udrulning af nye typer kommunikationstjenester. Til dette formål dannede det Europæiske Standardiseringsinstitut for telekommunikation (ETSI) en specifikations gruppe, der skulle definere NFV Architectural Framework¹⁰. Desuden er ETSI i øjeblikket vært for open source Mano (OSM) gruppe¹¹, som er ansvarlig for at udvikle en NFV Management and Orchestration (Mano) software stack i overensstemmelse med definitionen af ETSI NFV arkitektoniske ramme.

På baggrund af alle ovennævnte betragtninger undersøges den synergiske konvergens mellem UAVs-og NFV-teknologierne i øjeblikket i udviklingen af nye netapplikationer og-tjenester. Dette illustreres af flere forskningsarbejder i litteraturen, der påpeger fordelene ved disse typer af systemer^14,15,16, identificere udfordringerne i denne konvergens og dens manglende aspekter, fremhæve fremtidige forskningslinjer om dette emne¹⁷, og præsentere pioner løsninger baseret på open source-teknologier.

Især integrationen af NFV-teknologierne i UAV-arenaen muliggør en hurtig og fleksibel udbredelse af netværkstjenester og applikationer over afgrænsede geografiske områder (f. eks. en IP-telefonitjeneste). Efter denne fremgangsmåde kan en række UAV'er implementeres over et bestemt sted ved at transportere beregnings platforme som nyttelast (f. eks. små enkelt bestyrelses computere). Disse databehandlingsplatforme vil give en programmerbar netværksinfrastruktur (dvs. en NFV-infrastruktur) over udrulnings området og understøtte instantiationen af netværkstjenester og applikationer under kontrol af en MANO-platform.

Uanset fordelene, realiseringen af denne opfattelse præsenterer en række grundlæggende udfordringer, der skal håndteres omhyggeligt, såsom en passende integration af disse beregnings platforme som en NFV infrastruktur, ved hjælp af en eksisterende NFV softwarestak, således at en NFV orkestrering tjeneste kan implementere virtuelle funktioner på UAVs; begrænsningerne med hensyn til de beregningsressourcer, som beregnings platformene giver, da de UAVs, der transporterer dem, typisk kan udgøre begrænsninger med hensyn til nyttelast udstyrs størrelse, vægt og databehandlingskapacitet; den korrekte placering af de virtuelle funktioner på UAVs (dvs. vælge den bedste UAV kandidat til at implementere en bestemt virtuel funktion); opretholdelse af kontrol kommunikationen med UAV'er med henblik på at forvalte VNFs-livscyklussen på trods af den potentielt intermitterende tilgængelighed af netværkskommunikation med dem (f. eks. på grund af mobilitet og batteri begrænsninger) den begrænsede driftstid for UAV'er på grund af deres batteriforbrug; og migrering af de virtuelle funktioner, når en UAV skal udskiftes på grund af dens batteri udmattelse. Disse fordele og udfordringer er beskrevet i tidligere arbejde^18,19 , der omfatter udformningen af en NFV system i stand til at støtte automatiseret udrulning af netfunktioner og tjenester på UAV-platforme, samt validering af den praktiske gennemførlighed af dette design.

I denne sammenhæng fokuserer dette dokument på at beskrive en protokol, der muliggør automatiseret udrulning af moderat komplekse netværkstjenester over et netværk af UAV'er ved hjælp af NFV-standarderne og open source-teknologierne. For at illustrere de forskellige trin i protokollen præsenteres en ny udformning af et eksperiment i Nogales et al.¹⁹ , som består i indsættelsen af en IP-telefonitjeneste. For at støtte reproducerbarhed af dette arbejde, Real flyvning anses som frivillig i den præsenterede procedure, og ydeevneresultater opnås med UAV enheder på jorden. Interesserede læsere bør være i stand til at replikere og validere udførelsen af protokollen, selv i et kontrolleret laboratorium miljø.

Figur 1 illustrerer den netværkstjeneste, der er udviklet til denne procedure. Denne netværkstjeneste er bygget som en sammensætning af specifikke softwariseringsenheder (kategoriseret i NFV-paradigmet som virtuelle netværksfunktioner eller VNFs) og giver funktionaliteten af en IP-telefonitjeneste til brugere i nærheden af UAVs. Den VNF komponere tjenesten er defineret som følger:

• Adgangspunkt VNF (AP-VNF): denne VNF giver et Wi-Fi-adgangspunkt til slutbrugerudstyr (dvs. IP-telefoner i dette eksperiment).
• IP-telefoniserver VNF (IP-Telephony-server-VNF): den er ansvarlig for at administrere opkalds signerings meddelelser, der udveksles mellem IP-telefoner, for at oprette og afslutte et taleopkald.
• Domænenavn system VNF (DNS-VNF): denne VNF leverer en Name Resolution service, som typisk er nødvendig i IP-telefonitjenester.
• Access router VNF (AR-VNF): giver netværksrouting funktionaliteter, understøtter udveksling af trafik (dvs. kalde signalering i dette eksperiment) mellem IP-telefoner og teleoperatør domæne.
• Core router VNF (CR-VNF): leverer funktioner til netværksrouting i teleoperatør domænet, der giver adgang til operatørspecifikke tjenester (dvs. IP-telefoniserveren) og eksterne datanetværk.

Desuden viser figur 1 de fysiske enheder, der anvendes til eksperimentet, hvordan de er indbyrdes forbundne, og den specifikke allokering af vnfs til enheder.

Protocol

1. forudgående forudsætninger for forsøget

1. Installer den Management and Orchestration (MANO)-softwarestak, der leveres af open source MANO (OSM)-projektet. Specifikt, dette eksperiment bruger OSM Release fire²⁰, som kan udføres i en enkelt server computer eller i en virtuel maskine (VM), der opfylder de krav, der er angivet af OSM-Fællesskabet: Ubuntu 16,04 som operativsystem (64-bit variant billede), to centrale processor enheder (CPU'er), 8 GB Random Access Memory (RAM), en 40 GB lager disk og en enkelt netværksgrænseflade med Internet adgang. Proceduren for at installere OSM Release fire sammen med dens tekniske detaljer er tilgængelige i onlinedokumentationen fra OSM community²¹.
2. Konfigurer en cloud computing-platform, der leverer funktionerne i en virtuel infrastrukturforvalter (VIM), der er kompatibel med OSM Release fire. Til dette eksperiment bruges OpenStack Release Ocata²² , der kører i en VM med Ubuntu 16,04 som operativsystem, fire CPU'er, 16 GB RAM og 200 GB lager disk. I eksperimentet administrerer VIM en NFV-infrastruktur (NFVI), som er integreret af to højt profilerede Server computere, hver med Ubuntu 16,04 som operativsystem, otte CPU'er, 128 GB RAM og 4 TB Storage disk). Alle oplysninger om, hvordan du konfigurerer en cloud computing-platform, er inkluderet i installationsvejledningen, der er inkluderet i OpenStack-dokumentationen²³. Denne cloudplatform omtales som Core Cloud-platformen.
3. Oprette en ekstra Cloud computing platform til UAVs kaldes UAVs Cloud platform.
   1. Sørg for, at denne platform har en VIM baseret på OpenStack Release Ocata. I dette tilfælde, de ressourcer, der anvendes af VIM installation er Ubuntu 16,04 som operativsystem, to CPU'er, 6 GB RAM, 100 GB lager disk, og en ekstern Wi-Fi USB-adapter.
   2. NFVI integreret i denne Cloud platform består af en enkelt fast Compute server (Ubuntu 16,04 som operativsystem, otte CPU'er, 8 GB RAM, 128 GB lager disk, og en ekstern Wi-Fi USB-adapter) og tre enkelt kort computere (SBCs). Sidstnævnte giver en hardware platform, der nemt kan onboarded på en UAV. Se afsnit 3 for proceduren til opsætning af en UAV-cloudplatform med disse enheder som beregningsnoder.
4. Udstyre hver SBC med en batteri-strømforsyning hardware monteret på toppen (HAT) for at sikre driften af disse enheder, selv når de er i bevægelse, bliver båret af en UAV.
   Bemærk: trin 1,5 er valgfrit, fordi levering af netværkstjeneste i forsøget ikke afhænger af at have UAVs. Desuden er de SBCs transporteres som nyttelasten af UAVs og ingen andre ekstra tilslutninger (f. eks Ethernet eller USB) er nødvendige, fordi den netværkskommunikation, der kræves for korrekt drift af IP-telefonitjeneste leveres af SBCs, via deres Wi-Fi-adaptere, og strømforsyningen leveres af den strømforsynings-HAT, der er nævnt i trin 1,4.
5. Fastgør hver SBC som en UAV'S nyttelast gennem et fastgørelses tilbehør. I dette eksperiment blev tre kommercielle UAV'er valgt til at transportere de beregningsenheder, der blev tilbudt af Sbc'erne.
6. Vælg to trådløse VoIP-telefoner (Voice-over-IP), der understøtter den trådløse IEEE 802.11 b-kommunikationsstandard. denne model giver trådløs kommunikation via Wi-Fi. Alternativt kan taleopkaldet udføres ved hjælp af softphone-applikationer såsom Linphone²⁴ eller jitsi²⁵.
7. Som et eksperimentelt krav skal du sørge for tilgængeligheden af: a) Layer-3-kommunikation mellem OSM-softwarestakken og hver af Vim'er for at muliggøre den orkestrated udrulning af netværkstjenesten, der er udviklet til dette eksperiment, b) Layer-3 Communications mellem OSM og VNFs på hver Cloud platform til at understøtte VNF konfigurationsprocedurer, og c) Layer-3 kommunikation mellem VNFs kører på hver VIM for at muliggøre en velfungerende netværkstjeneste.
8. Alt det indhold, der er nødvendigt for at gennemføre forsøget, findes i det offentlige eksperiment register http://VM-images.Netcom.it.uc3m.es/JoVE/.

2. validering af funktionaliteten af softwariseringsenheder via emulering

Bemærk: for at bevise, at eksperimentets netværkstjeneste fungerer korrekt (Se figur 1) under realistiske anvendelsesbetingelser, blev der anvendt en formåls specifik emuleringsplatform baseret på Linux Containers²⁶ og NS-3²⁷ . Denne platform tillader emulering af multi-hop antenne forbindelser og definere egenskaberne af disse links (f. eks, længden af de trådløse kommunikationsforbindelser, mønster af data Packet tab, Radio teknologi, der anvendes i den trådløse kommunikation, etc.). Denne del af protokollen beskriver således de trin, der skal følges for at verificere, at IP-telefonitjenesten fungerer korrekt under realistiske trådløse kommunikationslink betingelser gennem emuleringplatformen.

1. Download emuleringplatformen fra eksperiment lageret. Platformen er tilgængelig som en virtuel maskine, der hedder "UAV-NFV-Jove-eksperiment. qcow", kompatibel med KVM Virtualization Technology²⁸. Denne maskine indeholder en forudoprettet skabelon, der emulerer netværkstjenesten og multi-UAV-scenariet, som vises i figur 1 , og en bruger med administratorrettigheder, der kan udføre denne skabelon.
   Bemærk: som standard udføres følgende trin automatisk, når emuleringplatformens virtuelle maskine startes: a) det virtuelle miljø er konfigureret til at muliggøre netværks emulering (dvs. netværksgrænseflader, Linux Bridges²⁹); b) de Linux containere, der repræsenterer de forskellige fysiske komponenter i standen (dvs., den SBCS og den faste Compute server for UAV Cloud platform, og Compute server for Core Cloud platform) er oprettet; og c) funktionerne i de forskellige VNFs i IP-telefonitjenesten (dvs. adgangspunkter, routere, DNS-servere og IP-telefoniserver) implementeres som Linux-containere over deres tilsvarende emulerede SBCs-og beregnings servere.
2. Før valideringsprocessen, oprette et emuleret multi-hop antenne netværk ved hjælp af NS-3 simulator, for at muliggøre forbindelsen mellem de forskellige netværk deltagere. Denne procedure vil emulere den realistiske trådløse kommunikation, der finder sted i scenariet afbildet i figur 1 (dvs. det Wi-Fi ad-hoc-netværk, som muliggør dataudvekslingen mellem noderne på UAV Cloud-platformen og de trådløse netværk, der tilbydes af de to Wi-Fi-adgangspunkter, der leveres i tjenesten).
   1. Oprette et multi-hop antenne netværk. Til dette formål, udføre multi-hop-Aerial-net.sh script (tilgængelig i emulering platform Machine) ved hjælp af følgende kommando: sudo sh/Home/jovevm/scripts/multi-hop-Aerial-net.sh > multi-hop-Aerial-net-Trace. log 2 > & 1 &. Denne kommando portrætterer simulerings sporet i den angivne logfil for at aktivere fejlfinding i tilfælde af fejl.
   2. Kontroller, om netværket er oprettet korrekt. Til dette formål, kontrollere, om Linux containere "IP-telefon-a" og "IP-telefon-b" (illustreret i figur 1 som slutbrugeren udstyr, der forbinder til en AP-VNF) har opnået en IP-adresse via DHCP-tjenesten, som kun er tilgængelig via multi-hop antenne netværk. Status for Linux container henrettet i emuleringmaskinen, samt deres IP-adresser, kan kontrolleres ved hjælp af kommandoen LXC liste.
3. Bekræft kapaciteten for den emulerede netværkstjeneste til at behandle de signalering-meddelelser, der er nødvendige for at konfigurere IP-telefoni opkaldet. Til dette formål, både "IP-Phone-a" og "IP-telefon-b" Linux containere har installeret "SIPp" værktøj³⁰. "SIPp" indeholder funktionaliteten til at emulere en IP-telefon, som opretter de omtalte signalering-meddelelser, sender dem til en IP-telefoniserver og behandler responsen for at kontrollere, om sidstnævnte fungerer korrekt.
   1. Udfør scriptet test-Signaling.sh i begge containere, som kører "SIPP" værktøj til at generere og sende signalering meddelelser til IP-telefoni-server-VNF.
   2. Kontroller scenarie skærmen, der er angivet ved udførelse af det forrige trin. Modtagelse af "200" svar viser den korrekte funktion af IP-telefoni-server-VNF.
4. Kontroller, at netværkstjenesten kan behandle den datatrafik, der genereres under et IP-telefoni kald. For at gøre dette, er flow planlægning "Trafic" værktøj³¹ installeret i "IP-telefon-a" og "IP-telefon-b" Linux containere.
   1. Udfør følgende kommando for at starte server agenten for Trafic: LXC exec IP-Phone-b sh Called-Party.sh.
   2. Udfør derefter følgende kommando for at starte klient agenten for Trafic og få netværks statistikken: LXC exec IP-Phone-a sh caller.sh. Den datatrafik, der emulerer et taleopkald, afsluttes efter 60 s. Scriptet viser en bekræftelsesmeddelelse og de mest betydningsfulde effektivitetsmålinger vedrørende taletrafikken.
   3. Kontroller de opnåede Metrics, og Bekræft, at IP-telefonitjenesten effektivt kan understøtte en interaktiv stemme samtale. For at gøre dette, se de oplysninger, der indgår i afsnittet om repræsentative resultater.

3. UAVs Cloud platform byggeri

1. Vælg den model af SBC, der kan give virtualiserings substrat til at udføre letvægts VNFs. De tekniske specifikationer for SBC-enhederne, der udnyttes under eksperimentet, er: fire CPU'er, 1 GB RAM og en 32 GB lager disk. Derudover har hver SBC tre netværksgrænseflader: en Ethernet-grænseflade, en integreret Wi-Fi-grænseflade og en ekstern Wi-Fi USB-adapter.
2. Forbered SBCs til efterfølgende at blive integreret i UAVs Cloud-platformen.
   1. Installer Ubuntu Mate³² 16.04.6 som operativsystemet, da openstack installationspakkerne er inkluderet i denne Linux-distribution.
   2. Installer og Konfigurer de påkrævede pakker som angivet i OpenStack-dokumentationen³³ for at gøre det muligt for sbc'erne at fungere som beregningsnoder for UAV-cloudplatformen. Efter den foregående guide, aktivere udnyttelsen af Linux containere i konfigurationen af OpenStack pakker. Container virtualisering bruges på grund af ressource begrænsningerne for de enheder, der typisk kan onboarded på små UAVs.
   3. I SBC kan du hente og udføre scriptet RPI-networking-Configuration.sh, som er tilgængeligt i eksperiment lageret. Dette script muliggør trådløs kommunikation af Sbc'erne, samt den nødvendige konfiguration for at tillade oprettelse af virtuelle netværk, der er knyttet til de trådløse grænseflader.
   4. Download og Kør scriptet Vim-networking-Configuration.sh, der er tilgængeligt i eksperiment lageret, i værten, der kører UAV Cloud platform Vim. Dette script overvåger opsætning af den trådløse kommunikation af VIM at muliggøre udveksling af oplysninger med SBCs.
      Bemærk: når netværket er godt konfigureret, og VIM har forbindelse til Sbc'erne, integrerer VIM dem automatisk i UAV Cloud-platformen som beregningsmæssige enheder, der kan udføre VNFs
3. Opret en OpenStack-tilgængelighedszone for hver af Sbc'erne. Dette vil gøre det muligt at implementere hvert af eksperimentets lette VNFs i en passende UAV-enhed. For at gøre dette, skal du logge ind på web grafisk brugergrænseflade, der leveres af VIM med administratorlegitimationsoplysninger, oprette tilgængelighedszoner i administrator > system > vært aggregater fanebladet, og redigere hver tilgængelighedszone for at tilføje den relevante vært (dvs. hver SBC integreret i UAV Cloud platform).
4. Bekræft den korrekte opsætning af UAV Cloud-platformen. Hen til lave altså, adgang den Administrator > ordning > ordning information tab hos den samme login nemlig i den foregående skridt, og klik i den computing service og netværk agenter afdeling hen til indskrive at den status i den DISPLAYED artikler er "levende" og "oppe".

4. Konfigurering af eksperimentet

1. Download VNF billeder, der implementerer de forskellige komponenter i IP-telefonitjeneste: AP-VNF, DNS-VNF, IP-telefoni-server-VNF, AR-VNF, og CR-VNF. Disse billeder kan downloades fra eksperiment lageret.
2. Upload VNF billeder til deres korrespondent VIM (dvs., AP-VNF og DNS-VNF til UAV Cloud platform VIM) og VoIP-VNF til kernen Cloud platform VIM. For at gøre det, logge ind i web grafisk brugergrænseflade, der leveres af hver VIM med administratorlegitimationsoplysninger, skal du klikke på Opret billede knappen for administrator ≫ system > fanen billeder , og oprette et billede ved hjælp af den viste form og vælge det relevante billede. Denne proces udføres på den tilsvarende VIM for hvert billede, der er blevet hentet i det forudgående trin.
3. Hent VNF-deskriptorerne (VNFDs) for eksperimentet fra eksperiment lageret. Disse deskriptorer indeholder de skabeloner, der beskriver de operationelle krav til en VNF, samt de placerings politikker, der angiver tilgængeligheds zonen med ansvar for at være vært for VNF selv. Yderligere oplysninger om NFV-deskriptorer findes i informationsmodellen for OSM³⁴.
4. Upload VNFDs. Brug en webbrowser til at få adgang til den grafiske OSM-brugergrænseflade, og log på med administratorens legitimationsoplysninger. Træk og slip derefter Vnfd'erne til fanen VNF-pakker .
5. Hent netværkstjeneste beskrivelsen (NSD) fra eksperiment lageret. Denne beskrivelse er en skabelon, der angiver den VNFs, som omfatter tjenesten, samt hvordan disse VNFs er forbundet.
6. Upload NSD. Træk og slip NSD i fanen NS-pakker i den grafiske OSM-brugergrænseflade.
7. Brug den grafiske brugergrænseflade i OSM til at tilføje en VIM-konto til UAV Cloud platform VIM og til Core Cloud platform VIM. For at gøre dette, skal du åbne fanen Vim konti med administratorlegitimationsoplysninger, klik på knappen + ny Vim og udfyld den viste formular med de ønskede oplysninger. Gentag denne handling for begge VIMs.

5. udførelse af eksperimentet

1. Installer netværkstjenesten. Fra fanen NS Packages i osm's grafiske brugergrænseflade, klik på INSTANTIATE NS -knappen på NSD uploadet i trin 4,6. Derefter udfylde den viste form, angiver VIM, der vil blive brugt til at implementere hver VNF komponere NS. Derudover er OSM ansvarlig for at behandle de placerings politikker, der er angivet i VNFDs, for at specificere den VIM, som tilgængeligheds zonen (dvs. en beregningsenhed i vores testbed) har ansvaret for at være vært for hver VNF. I forbindelse med dette eksperiment placeres VNFs i beregnings enhederne som vist i figur 1.
   Bemærk: som en alternativ metode giver OSM en kommandolinjegrænseflade, der muliggør direkte brugerinteraktion. En bruger, der gengiver dette eksperiment, kan bruge denne kommandolinjegrænseflade i stedet for den grafiske brugergrænseflade til at udføre de forskellige trin, der er defineret i denne protokol, især de trin, som er relateret til Onboarding af en VNF eller en NS-deskriptor, samt implementering af en netværkstjeneste.
2. Vent, indtil den grafiske OSM-brugergrænseflade angiver succesen for installationen af netværkstjenesten.
   Bemærk: driften af netværkstjenesten er helt uafhængig af UAVs-flyvningen: IP-telefonitjenesten kan leveres, når UAV'er flyver eller sparer batteriforbrug på en overflade. Således, trin 5,3 er valgfri.
3. Tag UAV'er af. Log ind på den mobile applikation og kontrollere flyvningen af hver UAV til stabilt vedligeholde det i en mellemliggende højde og undgå turbulens forårsaget af rotationen af motorerne tæt på en overflade.
4. Forbered hver af IP-telefoner til at udføre opkaldet.
   1. Tilslut en trådløs VoIP-telefon til hvert af de adgangspunkter, der tilbydes af netværkstjenesten. Til dette formål skal du angive SSID (Service Set Identifier) i menuen > Wireless > ssid og vælge infrastruktur tilstand i menuen > trådløs > netværkstilstand . Til sidst skal du vælge netværkskonfigurationen via DHCP ( Dynamic Host Configuration Protocol ) i menuen ≫ net Settings > Network mode .
   2. Konfigurer SIP-parametrene ( session Initierings protokol ) for at aktivere den relevante udveksling af signalering af meddelelser med IP-telefoniserveren. I denne sammenhæng, adgang til menuen ≫ SIP indstillinger fanen og angive værtsnavnet på IP Telephony server vnf ("DronesVoIP.net") i registratoren ≫ registrator IP og proxyserver > proxy IP tabs. Opret desuden en brugerkonto, der introducerer navnet på brugeren (f. eks. opkalds-A) i brugerkontoen ≫ telefonnummer og brugerkonto > bruger navn sektioner.
   3. Opret en post i telefonbogen af en af de IP-telefoner, der giver oplysninger om den bruger, som skal kaldes. Det gør du ved at vælge menuen > telefonbog > Tilføj indgangs fane og udfylde de ønskede parametre, der vises på displayet på følgende måde: vist navn = caller-B; Bruger info = caller-B; Host IP = dronesVoIP.net; Port = 5060. Endelig skal du vælge "proxy" option versus P2P (peer-to-peer).
5. Start opkaldet til den anden part. Det gør du ved at vælge den kaldte part ved hjælp af menuen > telefonbog > søge indstilling for IP-telefonen. Tryk derefter på opkaldsknappen. Når den anden IP-telefon begynder at ringe, kan du acceptere det indgående opkald med opkaldsknappen.

6. procedure for indsamling af eksperimentelle resultater

1. Tilslut en råvare laptop til en af de trådløse APs og køre ping kommandolinjeværktøj til IP-adressen på telefonen er forbundet til den anden AP under 180 s. Den IP henvende kan kontrollerede i den Menu > information > IP henvende valgmulighed i den IP telefonens når først den slægtskab er etableret hos den AP. opspare den runde-rejse gang (RTT) målinger, omdirigere den udgang givet af den ping værktøj i en fil.
2. Udfør tcpdump -kommandolinjeværktøjet i et af de kørende AP vnfs for at registrere den trafik, der blev udvekslet under IP-opkaldet. Gem denne trafik i en fil, der gør det muligt at skrive flaget for kommandolinjeværktøjet på udførelsestidspunktet og angive navnet på filen.
3. Foretag et nyt IP-telefoni opkald. Opretholde opkaldet for den ønskede tidsperiode (f. eks. 1 min.). Afslut derefter opkaldet ved at trykke på knappen Afbryd på en af IP-telefonerne.
4. Hold de filer, der genereres af tcpdump og ping værktøjer til videre behandling. Se repræsentative resultater.

Representative Results

Baseret på de data, der er indhentet under gennemførelsen af forsøget, hvor en reel VoIP opkald udføres, og efter de skridt, der er angivet i protokollen for at indsamle disse oplysninger, figur 2 skildrer den kumulative fordeling funktion af end-to-end forsinkelse målt mellem to slutbruger udstyr elementer (dvs. en råvare laptop og en IP-telefon). Dette bruger udstyr repræsenterer to enheder, der er forbundet via den installerede netværkstjenestes AP VNFs. Mere end 80% af end-to-end-forsinkelses målingerne var under 60 MS, og ingen af dem var højere end 150 MS, hvilket sikrer passende forsinkelses målinger for udførelse af et taleopkald.

Figur 3 illustrerer UDVEKSLINGEN af DNS-og SIP-signalering-meddelelser. Disse meddelelser svarer til registreringen af en af brugerne i IP-telefoniserveren (dvs. den bruger, hvis IP-telefon er forbundet til den AP VNF, hvor "tcpdump"-værktøjet kører) og til oprettelsen af taleopkaldet.

Endelig viser figur 4 og figur 5 den datatrafik, som er registreret under opkaldet. Især den første repræsenterer den konstante strøm af stemme pakker, der transmitteres og modtages af en af de trådløse telefoner under opkaldet, mens sidstnævnte illustrerer jitter i den fremadrettet retning med en gennemsnitlig værdi lavere end 1 MS.

De resultater, der blev opnået i forsøget for forsinkelses tallene (end-to-end-forsinkelse og-jitter), opfylder de anbefalinger, der er fastsat af den internationale telekommunikations Union-standardiserings sektor for telekommunikation (ITU-T)³⁵. I overensstemmelse hermed, den stemme Hidkalde skred uden glitches og artig klang seriøs. Dette eksperiment validerede de praktiske muligheder for at anvende NFV Technologies og UAVs til at implementere en funktionel IP-telefonitjeneste.

Figur 1: oversigt over netværkstjenesten, der afbilder VNFs, de enheder, hvor de udføres, og de virtuelle netværk, der er nødvendige for levering af IP-telefonitjenesten. Venligst klik her for at se en større version af dette tal.

Figur 2: slut-til-slut-forsinkelse. Repræsentation af slut-til-slut-forsinkelsen, der tilbydes slutbrugerens udstyr, som er tilsluttet AP VNFs. Til dette formål er den kumulative fordelingsfunktion for end-to-end-forsinkelsen blevet beregnet ud fra de målte RTT-prøver, som er opnået med kommandolinjeværktøjetping. Venligst klik her for at se en større version af dette tal.

Figur 3: brugerregistrering og opkald signalering meddelelser. Illustration af den signalerings trafik (DNS og SIP), der udveksles for at registrere en bruger i IP-telefoniserveren og for at oprette og afslutte multimedie sessionen, som understøtter afviklingen af taleopkaldet. Venligst klik her for at se en større version af dette tal.

Figur 4: strøm af stemme pakker. Repræsentation af taletrafikken, som blev udvekslet under opkaldet, målt ved et af AP VNFs. (forkortelser: RX = Receive, RX = transmission, RTP = real-time Transport Protocol). Venligst klik her for at se en større version af dette tal.

Figur 5: udviklingen i netværkets jitter under opkaldet. Repræsentation af jitter opleves af de transmitterede stemme pakker i den fremadrettet retning fra en telefon til den anden. Venligst klik her for at se en større version af dette tal.

Discussion

Et af de vigtigste aspekter af dette eksperiment er brugen af virtualiseringsteknologier og NFV standarder med UAV-platforme. NFV præsenterer et nyt paradigme, der har til formål at afkoble hardware afhængighed af netværkets funktionaliteter, hvilket gør det muligt at leve op til disse funktionaliteter gennem softwarisering. Eksperimentet afhænger derfor ikke af anvendelsen af det hardware udstyr, der er specificeret i protokollen. Alternativt kan der vælges forskellige modeller af computere med en enkelt bestyrelse, så længe de er i overensstemmelse med Uav's dimensioner og transportkapacitet, og de understøtter Linux-containere.

Uanset denne fleksibilitet med hensyn til hardware udvælgelse er alt det indhold, der er indeholdt i eksperimentets reproducerbarhed, orienteret mod brugen af open source-teknologier. I denne sammenhæng er konfigurations aspekterne og softwareværktøjerne betinget af brugen af Linux som operativsystem.

På den anden side betragter eksperimentet samarbejdet mellem to forskellige databehandlingsplatforme (dvs. UAV Cloud-platformen og Core Cloud-platformen) for at levere en moderat kompleks netværkstjeneste. Dette er dog ikke strengt nødvendigt, og protokollen kan følges for at støtte scenarier, hvor kun UAV Cloud-platformen er involveret.

Desuden kunne den præsenterede løsning potentielt bruges i andre miljøer, hvor ressource begrænsede hardwareplatforme kan være tilgængelige med den nødvendige kapacitet til at udføre virtualiserings beholdere (f. eks. tingenes internet eller IoT, miljøer). Under alle omstændigheder vil anvendeligheden af denne løsning på forskellige miljøer og dens potentielle tilpasninger kræve en omhyggelig undersøgelse i hvert enkelt tilfælde.

Endelig skal det bemærkes, at de forelagte resultater er opnået i et laboratoriemiljø og med UAV-enhederne jordet eller efter en begrænset og veldefineret flyveplan. Andre scenarier, der involverer udendørs installationer kan indføre betingelser, der påvirker stabiliteten af flyvningen af UAVs, og dermed udførelsen af IP-telefonitjeneste.

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