Login processing...

Trial ends in Request Full Access Tell Your Colleague About Jove

Engineering

Automatisert oppstillingen av en Sykehuslege protokollen telefon service opp på ubemannet antennen kjøretøyer benytter nettverk funksjonene virtualization

doi: 10.3791/60425 Published: November 26, 2019
* These authors contributed equally

Summary

Målet med den beskrevne protokollen er todelt: å konfigurere et nettverk funksjoner virtualisering miljø ved hjelp av ubemannet antenne kjøretøyer som beregningsorientert enheter som gir den underliggende strukturen for å utføre virtualiserte nettverksfunksjoner og å bruke Dette miljøet for å støtte den automatiserte distribusjonen av en funksjonell tjeneste for Internett-protokoller over antenne kjøretøyene.

Abstract

Det nettverk funksjonen Virtualization (NFV) paradigmet er ettall av nøkkelen muliggjør teknologiene inne utviklingen av det 5th generasjon av transportabel nettverk. Denne teknologien tar sikte på å minske avhengigheten av maskinvare i tilbudet av nettverksfunksjoner og tjenester ved hjelp av virtualisering teknikker som gjør at softwarization av disse funksjonene over en abstraksjon lag. I denne sammenheng er det økende interesse i å utforske potensialet i ubemannede luftfartøy (UAVs) for å tilby en fleksibel plattform som kan muliggjøre kostnadseffektiv NFV operasjoner over avgrenset geografiske områder.

Å demonstrere det praktisk gjennomførbarhet av bruker NFV teknologiene inne UAV plattform, en protokollen er forevist sette opp en funksjonell NFV omgivelsene basert på åpen kilde teknologiene, i hvilket en sette av liten UAVs levere det regneark ressursene det oppbacking distribusjon av moderat komplekse nettverkstjenester. Deretter protokollen detaljene de ulike trinnene som trengs for å støtte automatisert distribusjon av en Internet Protocol (IP) telefoni tjeneste over et nettverk av sammenkoblede UAVs, utnytte kapasiteten til det konfigurerte NFV-miljøet. Eksperimentering resultater demonstrere forsvarlig drift av tjenesten etter distribusjonen. Selv om protokollen fokuserer på en bestemt type nettverkstjeneste (dvs. IP-telefoni), kan de beskrevne trinnene fungere som en generell veiledning for å distribuere andre typer nettverkstjenester. På den annen side, protokollen beskrivelsen vurderer konkret utstyr og programvare for å sette opp NFV miljøet (f. eks bestemte enkelt bord datamaskiner og åpen kildekode-programvare). Bruk av andre maskinvare-og programvareplattformer kan være mulig, selv om det spesifikke konfigurasjons aspektet ved NFV-miljøet og tjeneste distribusjonen kan vise variasjoner i forhold til de som er beskrevet i protokollen.

Introduction

En av de mest ettertraktede mål innen den nye æra av mobil kommunikasjon (mest kjent som den 5th mobile generasjon eller 5G) er å kunne gi robust informasjonsteknologi tjenester i situasjoner der den primære infrastruktur for telekommunikasjon ikke kan være tilgjengelig (f. eks på grunn av en nødssituasjon). I denne sammenhengen er UAVs får økende oppmerksomhet fra forskningsmiljøet på grunn av deres iboende allsidighet. Det er mange verker som bruker disse enhetene som en hjørnestein for levering av et stort utvalg av tjenester. For eksempel har litteraturen analysert kapasiteten til disse enhetene for å bygge en antenne kommunikasjon infrastruktur for å imøtekomme multimedia Services1,2,3. Videre har tidligere undersøkelser vist hvordan samarbeidet mellom flere UAVs kan utvide funksjonaliteten til ulike kommunikasjonstjenester som overvåkning4, samarbeids søk og redning5,6,7,8eller agribusiness9.

På den annen side har NFV-teknologien fått stor betydning i teleoperatørene som en av de 5G-viktige Enablers. NFV representerer en paradigmatiske endring i forbindelse med infrastruktur for telekommunikasjon ved å lindre dagens avhengighet av nettverksenheter på spesialisert maskinvare gjennom softwarization av nettverksfunksjonaliteten. Dette gjør det mulig med en fleksibel og smidig distribusjon av nye typer kommunikasjonstjenester. Til dette formålet, den europeiske Telecommunications Standards Institute (ETSI) dannet en spesifikasjon gruppe for å definere NFV arkitektoniske rammeverket10. I tillegg ETSI nå vert for Open Source Mano (OSM) gruppe11, som er ansvarlig for å utvikle en NFV Management og ORCHESTRATION (Mano) programvare stabel på linje med DEFINISJONEN av ETSI NFV arkitektoniske rammeverket.

Gitt alle de nevnte betraktninger, er den synergisk konvergens mellom UAVs og NFV teknologier for tiden studert i utviklingen av romanen nettverksapplikasjoner og tjenester. Dette illustreres av flere forskningsarbeider i litteraturen som påpeker fordelene med disse typer systemer14,15,16, identifisere utfordringene i denne konvergens og dens manglende aspekter, markere fremtidige forsknings linjer på dette emnet17, og presentere Pioneer løsninger basert på åpen kildekode-teknologier.

Spesielt integreringen av NFV teknologiene inn i UAV Arena muliggjør det rask og fleksibel oppstillingen av nettverk tjenestene og søknadene over avgrenset geografisk arealer (e.g., en IP telefon service). Etter denne tilnærmingen, en rekke UAVs kan distribueres over et bestemt sted, transport databehandlingsplattformer som nyttelast (f. eks liten størrelse enkelt bord datamaskiner). Disse databehandlings plattformene vil gi en programmerbar nettverksinfrastruktur (dvs. en NFV-infrastruktur) over distribusjons området, som støtter oppretting av nettverkstjenester og applikasjoner under kontroll av en MANO-plattform.

Til tross for fordelene, presenterer realisering av denne visningen et sett av grunnleggende utfordringer som må nøye adressert, for eksempel riktig integrering av disse databehandlingsplattformer som en NFV infrastruktur, ved hjelp av en eksisterende NFV programvare stabel, slik at en NFV orchestration tjenesten kan distribuere virtuelle funksjoner på UAVs; begrensningene i forhold til beregningsorientert ressurser som tilbys av databehandlingsplattformer, som UAVs transportere dem kan vanligvis presentere begrensninger i forhold til størrelse, vekt, og databehandling kapasitet av nyttelast utstyr; det lated plasseringen av det virkelig funksjonene onto UAVs (i.e., velger det best UAV kandidaten å oppstille en detalj virkelig funksjonen); vedlikehold av kontroll kommunikasjonen med UAVs for å kunne håndtere livssyklusen til VNFs til tross for den potensielt uregelmessige tilgjengeligheten av nettverkskommunikasjon med dem (f.eks. forårsaket av mobilitet og batteri begrensninger); UAVs begrensede Driftstid på grunn av batteriets forbruk; og det Migration av det virkelig funksjonene når en UAV nødvendig å bli erstattet på grunn av dens akkumulator utmattelse. Disse fordeler og angripe er detaljert inne foregående arbeide18,19 det inkluderer planen av en NFV system dugelig av hjelper det automatisert oppstillingen av nettverk funksjonene og tjenestene opp på UAV plattform, likeledes idet godkjenningen av det praktisk gjennomførbarhet av denne tegning.

I denne sammenhengen fokuserer dette papiret på å beskrive en protokoll for å muliggjøre automatisert distribusjon av moderat komplekse nettverkstjenester over et nettverk av UAVs ved hjelp av NFV-standardene og åpen kildekode-teknologier. For å illustrere de ulike trinnene i protokollen, blir det presentert en re-utarbeidelse av et eksperiment som presenteres i Nogales et al.19 , som består av distribusjonen av en IP-telefoni-tjeneste. Å hjelpe reproduserbarheten av denne arbeide, virkelig flyreise er betraktet som idet frivillig inne det forevist fremgangsmåte, og gjennomførelse resultater er oppnådd med det UAV anordninger på bakken. Interesserte lesere bør være i stand til å gjenskape og validere gjennomføringen av protokollen, selv i et kontrollert laboratorium miljø.

Figur 1 illustrerer nettverkstjenesten som er utformet for denne prosedyren. Denne nettverkstjenesten er bygd som en sammensetning av spesifikke softwarization enheter (kategorisert i NFV-paradigmet som Virtual Network functions, eller VNFs) og gir funksjonaliteten til en IP-telefoni tjeneste til brukere i nærheten av UAVs. VNF som komponerer tjenesten, er definert på følgende måte:

  • Tilgangspunkt VNF (AP-VNF): denne VNF gir et Wi-Fi-tilgangspunkt til sluttbruker utstyr (dvs. IP-telefoner i dette eksperimentet).
  • IP-telefoni server VNF (IP-telefoni-server-VNF): det er ansvarlig for å håndtere samtalen signalnettverk meldinger som utveksles mellom IP-telefoner for å etablere og avslutte et taleanrop.
  • Domenen navnet system VNF (DNS-VNF): denne VNF skaffer en navnet resolution service, hvilke er vanligvis behøvde inne IP telefon tjenestene.
  • Tilgang router VNF (AR-VNF): gir nettverket ruting funksjonalitet, som støtter utveksling av trafikk (dvs. ringesignal nettverk i dette eksperimentet) mellom IP-telefoner og telekommunikasjon operatør domene.
  • Kjernen veien VNF (CR-VNF): skaffer nettverk praksis funksjonaliteten inne det Telecommunication betjene domenen, varer adgang å betjene-spesifikk tjenestene (i.e. det IP telefon server) og ekstern datanettverk.

I tillegg viser figur 1 de fysiske enhetene som brukes for eksperimentet, hvordan de er sammenkoblet, og den bestemte fordelingen av VNFs til enheter.

Protocol

1. tidligere forutsetninger for eksperimentet

  1. Installere programvare stabelen Management og orchestration (MANO) som leveres av Open Source MANO (OSM)-prosjektet. Nærmere bestemt bruker dette eksperimentet OSM Release FOUR20, som kan utføres på en enkelt server eller i en virtuell maskin (VM) oppfyller kravene angitt av OSM samfunnet: Ubuntu 16,04 som operativsystem (64-bit variant bilde), to sentrale prosesseringsenheter (CPUer), 8 GB Random Access Memory (RAM), en 40 GB lagringsplass, og et enkelt nettverk grensesnitt med Internett-tilgang. Prosedyren for å installere OSM Release FOUR sammen med de tekniske detaljene er tilgjengelig i den elektroniske dokumentasjonen som tilbys av OSM-fellesskapet21.
  2. Sett opp en Cloud Computing plattform, som gir funksjonene til en virtuell infrastruktur Manager (VIM) kompatibel med OSM Release FOUR. For dette eksperimentet, OpenStack Release Ocata22 brukes, kjører i en VM med Ubuntu 16,04 som operativsystem, fire CPUer, 16 GB RAM, og 200 GB lagringsplass. I forsøket, VIM forvalter en NFV infrastruktur (NFVI) integrert av to høyprofilerte server datamaskiner, hver med Ubuntu 16,04 som operativsystem, åtte CPUer, 128 GB RAM, og 4 TB lagringsplass). All informasjon om hvordan du setter opp en Cloud Computing plattform er inkludert i installasjonsveiledningen inkludert i OpenStack dokumentasjon23. Denne skyplattformen kalles kjerne skyplattformen.
  3. Sett opp en ekstra Cloud Computing plattform for UAVs er referert til som UAVs skyplattform.
    1. Sørg for at denne plattformen har en VIM basert på OpenStack Release Ocata. I dette tilfellet er ressursene som brukes av VIM installasjonen Ubuntu 16,04 som operativsystem, to CPUer, 6 GB RAM, 100 GB lagringsplass, og en ekstern Wi-Fi USB-adapter.
    2. Den NFVI integrert i denne skyen plattformen består av en enkelt fast databehandling server (Ubuntu 16,04 som operativsystem, åtte CPUer, 8 GB RAM, 128 GB lagringsplass, og en ekstern Wi-Fi USB-adapter) og tre enkelt bord datamaskiner (SBC). Det latter skaffe en isenkram plattform det kanne lett være onboarded opp på en UAV. Se del 3 for fremgangsmåten for å sette opp en UAV skyplattform med disse enhetene som databehandlingsknutepunkter.
  4. Utstyre hver SBC med en batteri-strømforsyning maskinvare festet på toppen (HAT) for å sikre driften av disse enhetene selv når de er i bevegelse, blir båret av en UAV.
    Merk: trinn 1,5 er valgfritt fordi bestemmelsen i nettverkstjenesten i eksperimentet ikke er avhengig av å ha UAVs. I tillegg er det SBC bæres som nyttelast av UAVs og ingen andre ekstra tilkoblinger (f. eks Ethernet eller USB) er nødvendig, fordi nettverkskommunikasjon som kreves for forsvarlig drift av IP-telefoni tjenesten er levert av SBC-er, gjennom sine Wi-Fi-adaptere, og strømforsyningen er levert av strømforsyningen HAT nevnt i trinn 1,4.
  5. Fest hver SBC som nyttelast av et UAV gjennom et feste tilbehør. I dette eksperimentet ble tre kommersielle UAVs valgt til å transportere databehandlings enhetene som ble tilbudt av SBC-er.
  6. Velg to trådløse Voice-over-IP (VoIP)-telefoner som støtter IEEE 802.11 b trådløs kommunikasjonsstandard. Denne modellen gir trådløs kommunikasjon via Wi-Fi. Som et alternativ kan taleanropet utføres ved hjelp av PC-programmer som Linphone24 eller Jitsi25.
  7. Som en eksperimentell krav, sørg for tilgjengeligheten av: a) Layer-3 kommunikasjon mellom OSM programvare stabelen og hver av VIMs å muliggjøre orkestrert distribusjon av nettverkstjenesten utviklet for dette eksperimentet, b) Layer-3 kommunikasjon mellom OSM og VNFs på hver skyplattform for å støtte VNF konfigurasjonsprosedyrer, og c) de Layer-3 kommunikasjon mellom VNFs kjører på hver VIM for å muliggjøre riktig funksjon av nettverkstjenesten.
  8. Alt innholdet som trengs for å utføre eksperimentet er gitt i det offentlige eksperimentet depotet http://VM-images.NetCom.it.uc3m.es/JoVE/.

2. validere funksjonaliteten til softwarization enheter via emulering

Merk: for å bevise riktig bruk av nettverkstjenesten for eksperimentet (se figur 1) under realistiske distribusjons betingelser, ble det brukt en formåls spesifikk emulering plattform basert på Linux-beholdere26 og NS-327 . Denne plattformen gjør det mulig å simulere multi-hop flyforbindelser og definere egenskapene til disse koblingene (f. eks lengden på trådløs kommunikasjon koblinger, mønster av datapakketap, Radio teknologien som brukes i trådløs kommunikasjon, etc.). Således, denne avdeling av protokollen beskriver foranstaltningene å bli føle etter å bekrefte det passende operasjon av det IP telefon service under realistisk trådløs kommunikasjon koble sammen vilkårene igjennom det etterligning plattform.

  1. Last ned emulering plattformen fra eksperimentet depotet. Plattformen er tilgjengelig som en virtuell maskin, kalt "UAV-nfv-Jove-Experiment. qcow", kompatibel med KVM virtualization Technology28. Denne maskinen inneholder en mal for precreated som emulerer nettverkstjenesten og multi-UAV-scenarioet som presenteres i figur 1 , og en bruker med administratorrettigheter som kan utføre malen.
    Merk: som standard utføres følgende trinn automatisk når emulering plattformen virtuell maskin er startet: a) det virtuelle miljøet er konfigurert til å aktivere nettverket emulering (dvs. nettverk grensesnitt, Linux broer29); b) Linux-beholdere som representerer de ulike fysiske komponentene i MontenegroGenericName (dvs. SBC-er og den faste databehandlings tjeneren for UAV-skyen, og databehandlings tjeneren for kjerne skyplattformen) opprettes; og c) funksjonene som tilbys av de ulike VNFs av IP-telefoni tjenesten (dvs. tilgangspunkter, rutere, DNS tjene, og IP-telefoni server) er utplassert som Linux-beholdere over deres tilsvarende emulert SBC-er og databehandlings tjenere.
  2. Før valideringsprosessen, sette opp en emulert multi-hop antenne nettverk ved hjelp av NS-3 Simulator, for å muliggjøre tilkobling mellom de ulike nettverks deltakere. Denne fremgangsmåten vil etterligne realistisk trådløs kommunikasjon som finner sted i scenariet avbildet i figur 1 (dvs. Wi-Fi Ad-hoc-nettverk, noe som gjør det mulig for datautveksling blant NODENE i UAV skyplattform og de trådløse nettverkene som tilbys av de to Wi-Fi-tilgangspunkter som tilbys i tjenesten).
    1. Opprett multi-hop antenne nettverk. For dette formålet, effektuere det multi-hop-Aerial-net.sh skriften (anvendelig innen det etterligning plattform apparat) benytter det fulgte kommandere: sudo sh/Home/jovevm/scripts/multi-hop-Aerial-net.sh > multi-hop-Aerial-net-Trace. log 2 > & 1 &. Denne kommandoen skildrer simulerings sporingen i den angitte loggfilen for å aktivere feilsøking i tilfelle feil.
    2. Kontroller om nettverket er opprettet. For å oppnå dette, sjekk om Linux-beholdere "IP-Phone-a" og "IP-Phone-b" (illustrert i figur 1 som sluttbruker utstyr som kobles til en Ap-VNF) har fått en IP-adresse gjennom DHCP-tjenesten, som bare er tilgjengelig via multi-hop antenne nettverk. Statusen for Linux-container utført i emulering maskinen, så vel som deres IP-adresser, kan kontrolleres ved hjelp av kommandoen lxc listen.
  3. Kontroller kapasiteten til den emulert nettverkstjenesten for å behandle signal signalene som kreves for å konfigurere IP-telefoni-kallet. For dette formålet, både "IP-Phone-a" og "IP-Phone-b" Linux beholdere har installert "SIPp" verktøyet30. "SIPp" gir funksjonalitet for å etterligne en IP-telefon opprette nevnte signalering meldinger, sende dem til en IP-telefoni server, og behandle responsen å verifisere riktig drift av sistnevnte.
    1. Utføre skriptet test-Signaling.sh i begge beholdere, som kjører "SIPp"-verktøyet til å generere og sende signalering meldinger til IP-telefoni-server-VNF.
    2. Kontroller scenario skjermbildet som ble levert ved kjøring av forrige trinn. Mottak av "200" svar viser riktig funksjon av IP-telefoni-server-VNF.
  4. Valider at nettverkstjenesten kan behandle datatrafikk som genereres under en IP-telefoni-kall. Å gjøre så, det flyte plan legging "trafic" verktøyet31 er installert inne det "IP-telefon-en" og "IP-telefon-b" Linux beholdere.
    1. Kjør følgende kommando for å starte serveren agent for trafic: lxc exec IP-Phone-b sh Called-Party.sh.
    2. Så, effektuere det fulgte kommandere for å starte klienten agent av trafic og få nettverk statistikken: lxc exec IP-telefon-en sh Caller.sh. Datatrafikk emulere et taleanrop avsluttes etter 60 s. Skriptet viser en bekreftelsesmelding og de mest betydningsfulle resultatberegningene for stemme trafikken.
    3. Sjekk de oppnådde beregningene og kontroller at IP-telefoni-tjenesten effektivt kan støtte en interaktiv stemmesamtale. For å gjøre dette, se informasjonen som er inkludert i avsnittet om representative resultater.

3. UAVs skyplattform konstruksjon

  1. Velg modell av SBC som kan gi virtualisering underlaget å utføre lette VNFs. De tekniske spesifikasjonene til SBC-enhetene som ble benyttet under eksperimentet, er: fire prosessorer, 1 GB RAM og en lagringsdisk på 32 GB. I tillegg har hver SBC tre nettverksgrensesnitt: et Ethernet-grensesnitt, et integrert Wi-Fi-grensesnitt og en ekstern Wi-Fi USB-adapter.
  2. Klargjør SBC-er som senere integreres i UAVs skyplattform.
    1. Installer Ubuntu mate32 16.04.6 som operativsystem, gitt at OpenStack installasjonspakker er inkludert i denne Linux-distribusjonen.
    2. Installere og konfigurere det krevde pakkene idet angitt inne det OpenStack dokumentasjonen33 å tillate det SBC å fungere som det beregne knutepunktene av det UAV Cloud plattform. Etter forrige guide, aktivere utnyttelse av Linux-beholdere i konfigurasjonen av OpenStack pakker. Container virtualisering brukes på grunn av ressurs begrensningene til enhetene som vanligvis kan onboarded på små-sized UAVs.
    3. I SBC, laste ned og kjøre skriptet RPI-Networking-Configuration.sh, tilgjengelig i eksperimentet depotet. Dette skriptet gjør det mulig for trådløs kommunikasjon av SBC-er, samt den nødvendige konfigurasjonen for å tillate etablering av virtuelle nettverk knyttet til de trådløse grensesnittene.
    4. Last ned og kjøre skriptet Vim-Networking-Configuration.sh, tilgjengelig i eksperimentet depotet, i VERTEN kjører UAV skyplattform Vim. Dette skriptet fører tilsyn med å sette opp trådløs kommunikasjon av VIM å aktivere informasjonsutveksling med SBC.
      Merk: Når nettverk er godt konfigurert og VIM har tilkobling med SBC-er, det VIM automatisk integrerer dem inn i UAV skyplattform som beregningsorientert enheter i stand til å utføre VNFs
  3. Opprett en OpenStack tilgjengelighet sone for hver av SBC-er. Denne ville tillate oppstille hver av det Lightweight VNFs av forsøket inne en passende UAV enhet. For å gjøre dette, logge deg på Web grafisk brukergrensesnitt levert av VIM med administratorrettigheter, opprette tilgjengelighet soner i administrator > system > Host aggregater kategorien, og redigere hver tilgjengelighet sone for å legge til den aktuelle verten (dvs. hver SBC integrert i UAV skyplattform).
  4. Bekrefte det korrekt setup av det UAV Cloud plattform. Å gjøre så, adgang administratoren > system > system beskjed tab med det likt logikk idet inne gårsdagen steg, og falle i staver inne det arbeider service og nettverk agenter avdeling å sjekk det rangen av det vist artikler er "Alive" og "opp".

4. konfigurering av eksperimentet

  1. Last ned VNF-bildene som implementerer de ulike komponentene i IP-telefoni-tjenesten: AP-VNF, DNS-VNF, IP-telefoni-server-VNF, AR-VNF og CR-VNF. Disse bildene kan lastes ned fra eksperiment registeret.
  2. Last opp VNF bilder til deres korrespondent VIM (dvs. AP-VNF og DNS-VNF til UAV skyplattform VIM) og VoIP-VNF til kjernen skyplattform VIM. For å gjøre dette, logge inn på Web grafisk brukergrensesnitt levert av hver VIM med administratorlegitimasjonen, klikk på Opprett bilde knappen av administrator > system > bilder kategorien, og opprette et bilde ved hjelp av det viste skjemaet og velge riktig bilde. Denne prosessen er gjort på tilsvarende VIM for hvert bilde som har blitt lastet ned i det tidligere trinnet.
  3. Last ned VNF-beskrivelsene (VNFDs) for eksperimentet fra eksperiment registeret. Disse beskrivelsene inneholder malene som beskriver de operative kravene til en VNF, i tillegg til plasserings policyene som angir hvilken tilgjengelighets sone som er ansvarlig for å drifte VNF selv. Mer informasjon om NFV beskrivelser finnes i informasjonsmodellen til OSM34.
  4. Last opp VNFDs. Bruk en nettleser for å få tilgang til OSM grafiske brukergrensesnittet, og Logg på med administratorlegitimasjonen. Så, hemsko og miste det VNFDs inn i VNF pakkene tab.
  5. Last ned NSD (Network Services Descriptor) fra eksperiment lageret. Denne beskrivelsen er en mal som angir VNFs som består av tjenesten, i tillegg til hvordan disse VNFs er sammenkoblet.
  6. Last opp NSD. Dra og slipp NSD-feltet i NS-pakker -fanen i det grafiske brukergrensesnittet OSM.
  7. Ved hjelp av det grafiske brukergrensesnittet til OSM, legge til en VIM konto for UAV skyplattform VIM og for kjernen skyplattform VIM. For å gjøre dette, åpne Vim kontoer fanen med administratorrettigheter, klikk på knappen + ny Vim og fyll ut skjemaet som vises med den forespurte informasjonen. Gjenta denne handlingen for begge VIMs.

5. utføring av eksperimentet

  1. Distribuer nettverkstjenesten. Fra NS pakker kategorien av OSM grafiske brukergrensesnittet, klikk på Start NS -knappen på NSD lastet opp i trinn 4,6. Deretter fyller det viste skjemaet, indikerer VIM som vil bli brukt til å distribuere hver VNF komponere NS. I tillegg er OSM ansvarlig for å behandle plasserings policyene som er angitt i VNFDs for å spesifisere VIM hvilken tilgjengelighets sone (dvs. en dataenhet i vår MontenegroGenericName) har ansvaret for å være vert for hver VNF. For dette eksperimentet plasseres VNFs i databehandlings enhetene som vist i figur 1.
    Merk: som en alternativ metode gir OSM et kommandolinjegrensesnitt som muliggjør direkte brukermedvirkning. En bruker som gjengir dette eksperimentet, kan bruke dette kommandolinjegrensesnittet, i stedet for det grafiske grensesnittet, til å utføre de ulike trinnene som er definert i denne protokollen, spesielt de trinnene som er relatert til innføring av en VNF eller en NS-beskrivelse, i tillegg til å distribuere en nettverkstjeneste.
  2. Vent til det grafiske brukergrensesnittet OSM angir at distribusjonen av nettverkstjenesten skal lykkes.
    Merk: driften av nettverkstjenesten er helt uavhengig av flyturen til UAVs: IP-telefoni tjenesten kan gis når UAVs flyr eller sparer batteriforbruk plassert på en overflate. Således, steg 5,3 er frivillig.
  3. Ta av UAVs. Stokk inne å det transportabel søknad og administrere det flyreise av hver UAV å stabilt vedlikeholde den inne en mellomliggende høyde og unngå det turbulens forårsaket av rotasjonen av motorene i nærheten av en overflate.
  4. Forbered hver av IP-telefonene til å utføre samtalen.
    1. Koble en trådløs VoIP-telefon til hvert av tilgangspunktene som tilbys av nettverkstjenesten. For dette formålet, spesifiser SSID (Service Set Identifier) i meny > WirelessSSID -fanen og velg infrastruktur modus i menyen > trådløs > nettverksmodus . Til slutt velger du nettverkskonfigurasjonen via DHCP ( Dynamic Host Configuration Protocol ) i menyen > net Settings > kategorien nettverksmodus .
    2. Konfigurer Session Initiation Protocol (SIP)-parameterne for å aktivere riktig utveksling av signal meldinger med IP-telefoni-serveren. I denne konteksten, tilgang til menyen > SIP-innstillinger og angi vertsnavnet til IP telefoni server VNF ("DronesVoIP.net") i registrar > REGISTRAR IP og proxy server > proxy IP tabs. Videre, opprette en brukerkonto introdusere navnet på brukeren (f. eks, Caller-en) i brukerkontoentelefonnummer og brukerkonto > brukernavn seksjoner.
    3. Lag en oppføring i telefonboken til en av IP-telefoner som gir informasjon om brukeren som skal kalles. Hvis du vil gjøre dette, velger du menyentelefonbok > Legg til oppføring -kategorien og fyll ut de forespurte parameterne som vises i displayet på følgende måte: visningsnavn = oppringer-B; Bruker info = oppringer-B; Vert IP = dronesVoIP.net; Port = 5060. Til slutt velger du "proxy" alternativet versus P2P (peer-to-peer).
  5. Start samtalen til den andre parten. Hvis du vil gjøre dette, velger du den ringte parten ved hjelp av menytelefonbok > søke alternativet til IP-telefonen. Trykk deretter på ringeknappen. Når den andre IP-telefonen begynner å ringe, godtar du den innkommende samtalen med anropsknappen.

6. prosedyre for å samle eksperimentelle resultater

  1. Koble en råvare bærbar PC til en av de trådløse APs og kjøre ping kommandolinjeverktøyet til IP-adressen til telefonen som er koblet til den andre AP under 180 s. IP-adressen kan kontrolleres i menyen > informasjon > IP-adresse til IP-telefonen når tilkoblingen er opprettet med Ap. Lagre "Round-Trip time" (RTT) mål, og omdirigere utdataene fra ping -verktøyet til en fil.
  2. Kjør kommandolinjeverktøyet tcpdump i en av de kjørende Ap-VNFs for å fange opp trafikken som utveksles under IP-kallet. Lagre denne trafikken i en fil som gjør det mulig å skrive flagget til kommandolinjeverktøyet ved Kjørings tiden og angi navnet på filen.
  3. Utfør en ny IP-telefoni-samtale. Oppretthold samtalen for den ønskede tidsperioden (f.eks. 1 min). Så, avslutte samtalen, trykker det hang opp knapp av ettall av det IP telefonene.
  4. Behold filene generert av tcpdump og ping verktøy for videre behandling. Se representative resultater.

Representative Results

Basert på data innhentet under utførelsen av eksperimentet, der en ekte VoIP samtale er utført og følge trinnene angitt av protokollen for å samle denne informasjonen, figur 2 skildrer den kumulative fordelingen funksjon av ende-til-ende forsinkelse målt mellom to sluttbruker utstyr elementer (dvs. en råvare laptop og en IP-telefon). Dette bruker utstyret representerer to enheter som er koblet sammen via AP-VNFs for den distribuerte nettverkstjenesten. Mer enn 80% av ende-til-ende forsinkelse målingene var under 60 MS, og ingen av dem var høyere enn 150 MS, noe som garanterer passende forsinkelse beregninger for gjennomføring av et taleanrop.

Figur 3 illustrerer utvekslingen av meldinger om DNS-og SIP-signalering. Disse meldingene tilsvarer registrering av en av brukerne i IP-telefoni server (dvs. brukeren som IP-telefonen er koblet til AP VNF hvor "tcpdump" verktøyet kjører) og til etablering av taleanrop.

Til slutt viser Figur 4 og figur 5 datatrafikken som ble registrert under samtalen. Spesielt representerer den første den konstante strømmen av tale pakker overført og mottatt av en av de trådløse telefonene under samtalen, mens sistnevnte illustrerer flimring i fremover retning med en gjennomsnittlig verdi lavere enn 1 MS.

Resultatene som ble oppnådd i eksperimentet for forsinkelse tallene (ende-til-ende forsinkelse og variasjon) tilfredsstiller anbefalingene angitt av International Telecommunication Union-Telecommunication standardisering Sector (ITU-T)35. Følgelig taleanrop kommet uten glitches og god lydkvalitet. Dette eksperimentet validerte den praktiske muligheten til å bruke NFV-teknologier og UAVs til å distribuere en funksjonell IP-telefoni-tjeneste.

Figure 1
Figur 1: oversikt over nettverkstjenesten, som viser VNFs, enhetene der de er utført, og de virtuelle nettverkene som trengs for å levere IP-telefoni-tjenesten. Vennligst klikk her for å se en større versjon av dette tallet.

Figure 2
Figur 2: ende-til-ende-forsinkelse. Representasjon av ende-til-ende-forsinkelsen som tilbys til sluttbruker utstyret som er koblet til AP VNFs. For dette formålet er den kumulative fordelingsfunksjonen til ende-til-ende-forsinkelsen beregnet fra de målte RTT-prøvene innhentet med kommandolinjeverktøyet "ping". Vennligst klikk her for å se en større versjon av dette tallet.

Figure 3
Figur 3: bruker registrering og anrops meldinger. Illustrasjon av signal trafikk (DNS og SIP) som utveksles for å registrere en bruker i IP-telefoni-serveren og til å opprette og avslutte multimedia-økten som støtter utførelsen av taleanropet. Vennligst klikk her for å se en større versjon av dette tallet.

Figure 4
Figur 4: strøm av tale pakker. Representasjon av stemme trafikken som ble utvekslet under samtalen, målt ved en av AP-VNFs. (forkortelser: RX = Receive, RX = Overfør, RTP = sann tids transportprotokoll). Vennligst klikk her for å se en større versjon av dette tallet.

Figure 5
Figur 5: utvikling av nettverks variasjon under samtalen. Representasjon av den overførte tale pakken i retning forover fra den ene telefonen til den andre. Vennligst klikk her for å se en større versjon av dette tallet.

Discussion

Ettall av de fleste betydelig aspektene av denne eksperiment er bruken av virtualization teknologiene og NFV standarder med UAV plattform. NFV presenterer et nytt paradigme sikte på å koble maskinvaren avhengighet av nettverket funksjonalitet, og dermed muliggjør levering av disse funksjonene gjennom softwarization. Eksperimentet er derfor ikke avhengig av bruken av maskinvareutstyret som er angitt i protokollen. Alternativt kan ulike modeller av enkelt bord datamaskiner velges, så lenge de er i tråd med dimensjonene og transportkapasiteten til UAVs og de støtter Linux-beholdere.

Til tross for denne fleksibiliteten når det gjelder maskinvarevalg, er alt innholdet som er gitt for reproduserbarheten til eksperimentet, orientert mot bruken av åpen kildekode-teknologi. I denne sammenhengen er konfigurasjons aspektene og programvare verktøyene betinget av bruk av Linux som operativsystem.

På den andre side, forsøket vurderer det interoperasjon av to annerledes databehandling plattform (i.e., det UAV Cloud plattform og kjernen skyplattform) å skaffe en moderat innviklet nettverk service. Imidlertid, denne er ikke strengt behøvde, og protokollen det kan en føle etter å oppbacking filmmanuskriptet i hvilket bare det UAV Cloud plattform er involvert.

I tillegg kan den presenterte løsningen potensielt brukes i andre miljøer, der maskinvareplattformer med ressurs begrensninger kan være tilgjengelige med den nødvendige kapasiteten til å utføre virtualisering beholdere (for eksempel tingenes Internet t eller IoT, og miljøer). I alle fall vil anvendelsen av denne løsningen til ulike miljøer og dens potensielle tilpasninger krever en grundig studie i et sak-til-sak grunnlag.

Til slutt bør det bemerkes at resultatene presentert har blitt innhentet i et laboratorium miljø og med UAV enheter jordet eller etter en begrenset og veldefinert fly plan. Andre scenarier som involverer utendørs distribusjoner kan innføre forhold som påvirker stabiliteten av flyturen av UAVs, og dermed ytelsen til IP-telefoni tjenesten.

Disclosures

Forfatterne har ingenting å avsløre.

Acknowledgments

Dette arbeidet ble delvis støttet av European H2020 5GRANGE prosjektet (Grant avtalen 777137), og av 5GCIty prosjektet (TEC2016-76795-C6-3-R) finansiert av den spanske departementet for økonomi og konkurranseevne. Arbeidet til Luis F. Gonzalez ble delvis støttet av European H2020 5GinFIRE prosjektet (gi avtalen 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

DOWNLOAD MATERIALS LIST

References

  1. 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).
  2. 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).
  3. Vidal, I., et al. Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications. Sensors. 18, (10), 3421 (2018).
  4. 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).
  5. 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).
  6. 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).
  7. 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).
  8. 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).
  9. 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).
  10. 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).
  11. An Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. ETSI OSM. Available from: https://osm.etsi.org/ (2019).
  12. 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).
  13. 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).
  14. Rametta, C., Schembra, G. Designing a softwarized network deployed on a fleet of drones for rural zone monitoring. Future Internet. 9, (1), 8 (2017).
  15. 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).
  16. 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).
  17. 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).
  18. 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).
  19. Nogales, B., Sanchez-Aguero, V., Vidal, I., Valera, F. Adaptable and automated small UAV deployments via virtualization. Sensors. 18, (12), 4116 (2018).
  20. Hoban, A., et al. An ETSI OSM Community White Paper, OSM Release FOUR: A Technical Overview. European Telecommunications Standards Institute. (ETSI). Whitepaper (2018).
  21. Quick start installation and use guide. Open Source MANO Release FOUR. Available from: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR (2019).
  22. Open Source Software for Creating Private and Public Clouds. OpenStack. Available from: https://docs.openstack.org/ocata (2019).
  23. OpenStack Installation Tutorial for Ubuntu. OpenStack. Available from: https://docs.openstack.org/ocata/install-guide-ubuntu/ (2019).
  24. Linphone. An Open Source VoIP SIP Softphone for voice/video calls and instant messaging. Linphone. Available from: https://www.linphone.org (2019).
  25. An Open Source Project to easily build and deploy secure video-conferencing solutions. Jitsi. Available from: https://jitsi.org (2019).
  26. Infrastructure for container projects. Linux Containers (LXC). Available from: https://linuxcontainers.org (2019).
  27. A Discrete-Event Network Simulator for Internet Systems. Ns-3. Available from: https://www.nsnam.org/ (2019).
  28. Kernel-based Virtual Machine (KVM). A virtualization solution for Linux. Linux. Available from: https://www.linux-kvm.org (2019).
  29. Bridging & firewalling. Linux Foundation. Available from: https://wiki.linuxfoundation.org/networking/bridge (2019).
  30. An Open Source test tool and/or traffic generator for the SIP protocol. SIPp. Available from: http://sipp.sourceforge.net/ (2019).
  31. Trafic. An open source flow scheduler. Available from: https://github.com/5GinFIRE/trafic (2019).
  32. Ubuntu Mate for the Raspberry Pi. Available from: https://ubuntu-mate.org/raspberry-pi/ (2019).
  33. Enabling LXC (Linux Containers) as virtualization technology. OpenStack. Available from: https://docs.openstack.org/ocata/config-reference/compute/hypervisor-lxc.html (2019).
  34. Open Source MANO Information Model. Available from: https://osm.etsi.org/wikipub/index.php/OSM_Information_Model (2019).
  35. 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).
Automatisert oppstillingen av en Sykehuslege protokollen telefon service opp på ubemannet antennen kjøretøyer benytter nettverk funksjonene virtualization
Play Video
PDF DOI DOWNLOAD MATERIALS LIST

Cite this Article

Nogales, B., Vidal, I., Sanchez-Aguero, V., Valera, F., Gonzalez, L. F., Azcorra, A. Automated Deployment of an Internet Protocol Telephony Service on Unmanned Aerial Vehicles Using Network Functions Virtualization. J. Vis. Exp. (153), e60425, doi:10.3791/60425 (2019).More

Nogales, B., Vidal, I., Sanchez-Aguero, V., Valera, F., Gonzalez, L. F., Azcorra, A. Automated Deployment of an Internet Protocol Telephony Service on Unmanned Aerial Vehicles Using Network Functions Virtualization. J. Vis. Exp. (153), e60425, doi:10.3791/60425 (2019).

Less
Copy Citation Download Citation Reprints and Permissions
View Video

Get cutting-edge science videos from JoVE sent straight to your inbox every month.

Waiting X
simple hit counter