Summary

Geautomatiseerde implementatie van een Internet Protocol Telephony-service op onbemande luchtvaartuigen met behulp van virtualisatie van netwerkfuncties

Published: November 26, 2019
doi:

Summary

Het doel van het beschreven protocol is tweeledig: een virtualisatieomgeving voor netwerkfuncties configureren met onbemande luchtvaartuigen als rekenkundige entiteiten die de onderliggende structuur leveren voor het uitvoeren van gevirtualiseerde netwerkfuncties en het gebruik van deze omgeving ter ondersteuning van de geautomatiseerde implementatie van een functionele Internet Protocol Telephony-service over de luchtvoertuigen.

Abstract

Het NFV-paradigma (Network Function Virtualization) is een van de belangrijkste technologieën voor de ontwikkeling van de 5e generatie mobiele netwerken. Deze technologie heeft tot doel de afhankelijkheid van hardware bij het leveren van netwerkfuncties en-diensten te verminderen door gebruik te maken van virtualisatietechnieken die de softwarisatie van die functionaliteiten via een abstractielaag mogelijk maken. In dit verband is er steeds meer belangstelling voor het verkennen van het potentieel van onbemande luchtvaartuigen (UAVs) om een flexibel platform aan te bieden dat kosteneffectieve NFV-operaties over afgebakende geografische gebieden mogelijk maakt.

Om de praktische haalbaarheid van het gebruik van NFV-technologieën in UAV-platforms aan te tonen, wordt een protocol gepresenteerd om een functionele NFV-omgeving op te zetten op basis van open source-technologieën, waarin een reeks kleine UAVs de computationele bronnen levert die ondersteuning bieden voor de uitrol van matig complexe netwerkdiensten. Vervolgens worden in het protocol de verschillende stappen beschreven die nodig zijn om de geautomatiseerde implementatie van een IP-telefonieservice (Internet Protocol) te ondersteunen via een netwerk van onderling verbonden UAVs, waarbij gebruik wordt maken van de capaciteiten van de geconfigureerde NFV-omgeving. Experimenten resultaten tonen de juiste werking van de service na de implementatie ervan. Hoewel het Protocol zich richt op een specifiek type netwerkservice (d.w.z. IP-telefonie), kunnen de beschreven stappen fungeren als algemene richtlijn voor het implementeren van andere typen netwerkservices. Aan de andere kant, de beschrijving van het protocol beschouwt concrete apparatuur en software voor het opzetten van de NFV-omgeving (bijvoorbeeld specifieke single board computers en open source software). Het gebruik van andere hardware-en software platforms kan mogelijk zijn, hoewel het specifieke configuratie aspect van de NFV-omgeving en de service-implementatie variaties kunnen presenteren met betrekking tot die beschreven in het protocol.

Introduction

Een van de meest begeerde doelen binnen het nieuwe tijdperk van de mobiele communicatie (meestal bekend als de 5e mobiele generatie of 5g) is om robuuste informatietechnologie diensten te kunnen leveren in situaties waarin de primaire telecommunicatie infrastructuur mogelijk niet beschikbaar is (bijvoorbeeld vanwege een noodsituatie). In deze context krijgen de Uavm steeds meer aandacht van de onderzoeksgemeenschap vanwege hun inherente veelzijdigheid. Er zijn tal van werken die deze apparaten gebruiken als hoeksteen voor het leveren van een grote verscheidenheid aan diensten. Zo heeft de literatuur de capaciteit van deze apparaten geanalyseerd om een antenne communicatie-infrastructuur te bouwen voor multimedia-diensten1,2,3. Bovendien is uit voorafgaand onderzoek gebleken hoe de samenwerking tussen verschillende UAVs de functionaliteit van verschillende communicatiediensten kan uitbreiden, zoals surveillance4, Collaboratief zoeken en Rescue5,6,7,8of agribusiness9.

Aan de andere kant, de NFV-technologie heeft grote betekenis verworven binnen de telecom operators als een van de 5G key enablers. NFV vertegenwoordigt een paradigmatische verandering met betrekking tot de telecommunicatie-infrastructuur door het verlichten van de huidige afhankelijkheid van netwerkapparaten op gespecialiseerde hardware via de softwarisatie van de netwerk functionaliteiten. Dit maakt een flexibele en agile implementatie van nieuwe soorten communicatiediensten mogelijk. Daartoe vormde het Europees Instituut voor telecommunicatienormen (ETSI) een specificatie groep om het NFV-architecturale kader10te definiëren. Daarnaast host de ETSI momenteel de open source Mano (OSM) groep11, die belast is met het ontwikkelen van een Nfv Management and ORCHESTRATION (Mano) software stack uitgelijnd met de definitie van het ETSI nfv-architecturale kader.

Gezien alle bovengenoemde overwegingen wordt de synergische convergentie tussen UAVs en NFV-technologieën momenteel bestudeerd bij de ontwikkeling van nieuwe netwerktoepassingen en-diensten. Dit wordt geïllustreerd door verschillende onderzoekswerken in de literatuur die wijzen op de voordelen van dit soort systemen14,15,16, de uitdagingen van deze convergentie en de ontbrekende aspecten ervan te identificeren, toekomstige onderzoekslijnen over dit onderwerp17te benadrukken en Pioneer-oplossingen te presenteren op basis van open source-technologieën.

Met name de integratie van NFV-technologieën in de UAV-Arena maakt een snelle en flexibele uitrol van netwerkdiensten en-toepassingen mogelijk via afgebakende geografische gebieden (bijv. een IP-Telefoniedienst). Naar aanleiding van deze aanpak, een aantal UAVs kan worden geïmplementeerd op een specifieke locatie, het transport van Compute-platforms als Payload (bijvoorbeeld kleine single board computers). Deze Compute-platforms zou bieden een programmeerbare netwerkinfrastructuur (dat wil zeggen, een NFV-infrastructuur) over het implementatie gebied, ondersteuning van de instantiëring van netwerkservices en toepassingen onder de controle van een MANO-platform.

Niettegenstaande de voordelen presenteert de realisatie van deze weergave een reeks fundamentele uitdagingen die zorgvuldig moeten worden aangepakt, zoals de juiste integratie van deze Compute-platforms als een NFV-infrastructuur, met behulp van een bestaande NFV-software stack, zodat een NFV-Orchestration-service virtuele functies op de UAVs kan implementeren; de beperkingen in termen van de rekenkundige middelen die door de Compute-platforms, als de UAVs transport van hen kunnen meestal beperkingen in termen van grootte, gewicht en rekencapaciteit van Payload-apparatuur te presenteren; de juiste plaatsing van de virtuele functies op UAVs (d.w.z. het selecteren van de beste UAV-kandidaat om een bepaalde virtuele functie te implementeren); het onderhoud van de controle communicatie met de UAVs om de levenscyclus van het VNFs te beheren, ondanks de mogelijk intermitterende beschikbaarheid van netwerkcommunicatie met hen (bijvoorbeeld veroorzaakt door mobiliteit en batterij beperkingen); de beperkte bedrijfstijd van de UAVs door het batterijverbruik; en de migratie van de virtuele functies wanneer een UAV moet worden vervangen vanwege de uitputting van de batterij. Deze voordelen en uitdagingen worden gedetailleerd beschreven in vorig werk18,19 met het ontwerp van een nfv-systeem dat de geautomatiseerde uitrol van netwerkfuncties en-diensten op UAV-platformen kan ondersteunen, evenals de validatie van de praktische haalbaarheid van dit ontwerp.

In deze context richt deze paper zich op het beschrijven van een protocol om de geautomatiseerde uitrol van matig complexe netwerkdiensten via een netwerk van UAVs met behulp van de NFV-standaarden en open source-technologieën mogelijk te maken. Ter illustratie van de verschillende stappen van het protocol wordt een heruitwerking van een experiment gepresenteerd in Nogales et al.19 , dat bestaat uit de uitrol van een IP-Telefoniedienst. Om de reproduceerbaarheid van dit werk te helpen, wordt echte vlucht beschouwd als optioneel in de gepresenteerde procedure en worden de prestatieresultaten verkregen met de UAV-apparaten op de grond. Geïnteresseerde lezers moeten de uitvoering van het protocol kunnen repliceren en valideren, zelfs in een gecontroleerde laboratoriumomgeving.

Afbeelding 1 illustreert de netwerkservice die is ontworpen voor deze procedure. Deze Netwerkservice is gebouwd als een samenstelling van specifieke softwarisatie-eenheden (gecategoriseerd binnen het NFV-paradigma als virtuele netwerkfuncties of VNFs) en biedt de functionaliteit van een IP-telefonieservice aan gebruikers in de nabijheid van de UAVs. De VNF die de service opstelt, wordt als volgt gedefinieerd:

  • Toegangspunt VNF (AP-VNF): deze VNF biedt een Wi-Fi-toegangspunt voor apparatuur van eindgebruikers (d.w.z. IP-telefoons in dit experiment).
  • IP-telefonieserver VNF (IP-telefonie-server-VNF): het is verantwoordelijk voor het beheer van de oproep signalering van berichten die worden uitgewisseld tussen IP-telefoons om een spraakoproep tot stand te brengen en te beëindigen.
  • Domeinnaam systeem VNF (DNS-VNF): deze VNF biedt een service voornaam omzetting, die meestal nodig is in IP-telefonieservices.
  • Access router VNF (AR-VNF): biedt netwerk routeringsfuncties, ondersteuning van de uitwisseling van verkeer (d.w.z. oproep signalering in dit experiment) tussen de IP-telefoons en de telecommunicatie-operator domein.
  • Core router VNF (CR-VNF): biedt netwerk routeringsfuncties in het domein van de telecommunicatie-operator, die toegang bieden tot operator-specifieke services (d.w.z. de IP-telefonieserver) en externe gegevensnetwerken.

Bovendien presenteert Figuur 1 de fysieke apparaten die worden gebruikt voor het experiment, hoe ze onderling zijn verbonden en de specifieke toewijzing van vnfs aan apparaten.

Protocol

1. voorafgaande vereisten voor het experiment Installeer de software stack Management and Orchestration (MANO) die wordt geleverd door het project open source MANO (OSM). Specifiek, dit experiment maakt gebruik van OSM release vier20, die kan worden uitgevoerd in een enkele Server computer of in een virtuele machine (VM) die voldoet aan de vereisten die zijn gespecificeerd door de Gemeenschap van OSM: Ubuntu 16,04 als het besturingssysteem (64-bits variant afbeelding), twee centrale verwerkingseenheden (cpu’s), 8 GB RAM (Random Access Memory), een opslagschijf van 40 GB en een enkele netwerkinterface met Internet toegang. De procedure voor het installeren van OSM release FOUR samen met de technische details is beschikbaar in de online documentatie die door de OSM community21wordt verstrekt. Opzetten van een cloud computing platform, het verstrekken van de functies van een Virtual Infrastructure Manager (VIM) compatibel met OSM release vier. Voor dit experiment wordt OpenStack release Ocata22 gebruikt, uitgevoerd in een virtuele machine met Ubuntu 16,04 als het besturingssysteem, vier cpu’s, 16 GB RAM en 200 GB opslagschijf. In het experiment beheert het VIM een NFV-infrastructuur (NFVI) die is geïntegreerd met twee high-profile Server computers, elk met Ubuntu 16,04 als het besturingssysteem, acht Cpu’s, 128 GB RAM en 4 TB opslagschijf). Alle informatie over het opzetten van een cloud computing platform is opgenomen in de installatiehandleiding die is opgenomen in de OpenStack-documentatie23. Dit Cloud platform wordt het core Cloud platform genoemd. Een extra Cloud computing platform opzetten voor de UAVs wordt het UAVs Cloud platform genoemd. Zorg ervoor dat dit platform beschikt over een VIM op basis van OpenStack release Ocata. In dit geval zijn de bronnen die worden gebruikt door de VIM-installatie Ubuntu 16,04 als besturingssysteem, twee Cpu’s, 6 GB RAM, 100 GB opslagschijf en een externe Wi-Fi USB-adapter. De in dit Cloud platform geïntegreerde NFVI bestaat uit één vaste Compute-Server (Ubuntu 16,04 als besturingssysteem, acht Cpu’s, 8 GB RAM, 128 GB opslagschijf en een externe Wi-Fi USB-adapter) en drie single board-computers (Sbc’s). De laatste bieden een hardwareplatform dat gemakkelijk kan worden onboarding op een UAV. Zie sectie 3 voor de procedure voor het instellen van een UAV-Cloud platform met deze apparaten als rekenknooppunten. Rusten elke SBC met een batterij-voeding hardware bevestigd op de top (hoed) om de werking van deze eenheden te garanderen, zelfs wanneer ze in beweging, wordt gedragen door een UAV.Opmerking: stap 1,5 is optioneel omdat de levering van de Netwerkservice in het experiment niet afhankelijk is van het hebben van UAVs. Daarnaast worden de Sbc’s meegenomen als de payload van de UAVs en zijn er geen andere extra verbindingen (bijv. Ethernet of USB) nodig, omdat de netwerkcommunicatie die nodig is voor de juiste werking van de IP-Telefoniedienst door de Sbc’s, via hun Wi-Fi-adapters, wordt geleverd en de voeding wordt geleverd door de Power-Supply HAT die wordt vermeld in stap 1,4. Bevestig elke SBC als de payload van een UAV door middel van een bevestigings accessoire. In dit experiment werden drie commerciële UAVs gekozen om de compute units te transporteren die door de Sbc’s worden aangeboden. Selecteer twee draadloze VoIP-telefoons (Voice-over-IP) die de IEEE 802.11 b-standaard voor draadloze communicatie ondersteunen; Dit model biedt draadloze communicatie via Wi-Fi. Als alternatief kan de spraakoproep worden uitgevoerd met softphone-toepassingen zoals linphone24 of jitsi25. Als een experimentele vereiste, zorg ervoor dat de beschikbaarheid van: a) Layer-3 communicatie tussen de OSM software stack en elk van de VIMs om de georkestreerde implementatie van de netwerkdienst ontwikkeld voor dit experiment mogelijk te maken, b) Layer-3 communicatie tussen de OSM en de VNFs op elk cloud platform ter ondersteuning van VNF-configuratieprocedures, en c) de Layer-3-communicatie tussen de VNFs die op elke VIM draait om de goede werking van de Netwerkservice mogelijk te maken. Alle inhoud die nodig is voor het uitvoeren van het experiment wordt geleverd in de openbare experiment opslagplaats http://VM-images.Netcom.it.uc3m.es/JoVE/. 2. valideren van de functionaliteit van de softwarisatie-eenheden via emulatie Opmerking: om de juiste werking van de netwerkdienst van het experiment te bewijzen (Zie Figuur 1) onder realistische implementatie voorwaarden, werd een specifiek emulatie platform gebaseerd op Linux containers26 en NS-327 gebruikt. Dit platform maakt het emuleren van multi-hop luchtverbindingen en het definiëren van de kenmerken van deze links (bijv. lengte van de draadloze communicatielinks, patroon van datapakket verliezen, de radio-technologie die wordt gebruikt in de draadloze communicatie, enz.). Deze sectie van het protocol beschrijft dus de stappen die moeten worden gevolgd om de juiste werking van de IP-telefonieservice te controleren onder realistische voorwaarden voor draadloze communicatiekoppelingen via het emulatie platform. Download het emulatie platform uit de experiment opslagplaats. Het platform is beschikbaar als een virtuele machine, genaamd “UAV-nfv-jove-experiment. qcow”, in overeenstemming met de KVM-virtualisatietechnologie28. Deze machine bevat een precreated-sjabloon die de netwerkservice emuleert en het multi-UAV-scenario dat wordt weergegeven in afbeelding 1 en een gebruiker met beheerdersbevoegdheden die deze sjabloon kan uitvoeren.Opmerking: standaard worden de volgende stappen automatisch uitgevoerd wanneer de emulatie platform virtuele machine wordt gestart: a) de virtuele omgeving is geconfigureerd voor het inschakelen van de netwerk-emulatie (dat wil zeggen, netwerkinterfaces, Linux-bruggen29); b) de Linux-containers die de verschillende fysieke onderdelen van de testbed vertegenwoordigen (d.w.z. de Sbc’s en de vaste Compute-Server voor het UAV-Cloud platform en de Compute-Server voor het core Cloud platform) worden gemaakt; en c) de functies die worden geboden door de verschillende VNFs van de IP-telefonieservice (d.w.z. toegangspunten, routers, DNS serve-en IP-telefonieserver) worden geïmplementeerd als Linux-containers via hun corresponderende geëmuleerde Sbc’s en Compute-servers. Voordat het validatieproces, instellen van een geëmuleerd multi-hop antenne netwerk met behulp van de NS-3-Simulator, om de connectiviteit tussen de verschillende netwerkdeelnemers mogelijk te maken. Deze procedure emuleert de realistische draadloze communicatie die plaatsvindt in het scenario dat wordt afgebeeld in Figuur 1 (D.w.z. het Wi-Fi ad-hoc-netwerk, dat de gegevensuitwisseling mogelijk maakt tussen de nodes van het UAV-Cloud platform en de draadloze netwerken die worden aangeboden door de twee Wi-Fi-toegangspunten in de service). Maak het multi-hop antenne netwerk. Hiertoe voert u het script multi-hop-Aerial-net.sh uit (beschikbaar in de emulatie platform machine) met de volgende opdracht: sudo sh/Home/jovevm/scripts/multi-hop-Aerial-net.sh > multi-hop-Aerial-net-Trace. log 2 > & 1 &. Deze opdracht beeldt de simulatie tracering in het opgegeven logboekbestand uit om foutopsporing in het geval van fouten mogelijk te maken. Controleer of het netwerk met succes is gemaakt. Controleer hiertoe of de Linux-containers “IP-Phone-a” en “IP-Phone-b” (geïllustreerd in Figuur 1 als eindgebruiker-apparatuur die verbinding maakt met een AP-VNF) een IP-adres hebben verkregen via de DHCP-service, die alleen toegankelijk is via het multi hop-netwerk. De status van de Linux-container uitgevoerd binnen de emulatie machine, evenals hun IP-adressen, kan worden gecontroleerd met behulp van de Command lxc lijst. Controleer de capaciteit van de geëmuleerde Netwerkservice voor het verwerken van de signaalberichten die nodig zijn om de IP-telefonie oproep in te stellen. Voor dit doel, zowel de “IP-Phone-a” en “IP-Phone-b” Linux containers hebben de “SIPp” tool geïnstalleerd30. “SIPp” biedt de functionaliteit om een IP-telefoon te emuleren die de genoemde signalerings berichten maakt, ze naar een IP-telefonieserver te sturen en het antwoord te verwerken om de juiste werking van de laatste te controleren. Voer het script test-signaling.sh in beide containers, die wordt uitgevoerd de “SIPP” hulpprogramma voor het genereren en verzenden van signalering van berichten naar de IP-telefonie-server-VNF. Controleer het scenario scherm geleverd door uitvoering van de vorige stap. De ontvangst van “200” antwoord toont de juiste werking van de IP-telefonie-server-VNF. Controleer of de netwerkservice het gegevensverkeer kan verwerken dat tijdens een IP-telefoongesprek wordt gegenereerd. Om dit te doen, de stroom planning “Trafic” tool31 is geïnstalleerd in de “IP-Phone-a” en “IP-Phone-b” Linux-containers. Voer de volgende opdracht uit om de Server Agent van Trafic te starten: lxc exec IP-Phone-b sh called-Party.sh. Voer vervolgens de volgende opdracht uit om de client agent van Trafic te starten en de netwerkstatistieken op te halen: lxc exec IP-Phone-a sh Caller.sh. Het gegevensverkeer dat een spraakoproep emueert, wordt beëindigd na 60 s. Het script geeft een bevestigingsbericht en de belangrijkste metrische gegevens over de prestaties van het spraakverkeer. Controleer de verkregen metrische gegevens en controleer of de IP-telefonieservice effectief een interactief spraakgesprek kan ondersteunen. Zie hiervoor de informatie in het hoofdstuk over representatieve resultaten. 3. UAVs Cloud platform bouw Selecteer het model van SBC die de virtualisatie substraat voor het uitvoeren van lichtgewicht VNFs kan bieden. De technische specificaties van de SBC apparaten gebruikt tijdens het experiment zijn: vier Cpu’s, 1 GB RAM-geheugen en een 32 GB opslagschijf. Bovendien heeft elke SBC drie netwerkinterfaces: een Ethernet-interface, een geïntegreerde Wi-Fi-interface en een externe Wi-Fi USB-adapter. Bereid de Sbc’s voor om vervolgens te worden geïntegreerd in het UAVs Cloud platform. Installeer Ubuntu mate32 16.04.6 als het besturingssysteem, gezien het feit dat de openstack installatiepakketten zijn opgenomen in deze Linux-distributie. Installeer en configureer de vereiste pakketten zoals aangegeven in de OpenStack-documentatie33 , zodat de sbc’s kunnen fungeren als de rekenknooppunten van het UAV-Cloud platform. Volg de vorige handleiding, het gebruik van Linux-containers in de configuratie van de OpenStack-pakketten inschakelen. Container virtualisatie wordt gebruikt als gevolg van de resourcebeperkingen van de apparaten die doorgaans kunnen worden onboarding op kleine UAVs. In de SBC, downloaden en uitvoeren van het script RPI-Networking-Configuration.sh, beschikbaar in de opslagplaats van het experiment. Met dit script u de draadloze communicatie van de Sbc’s, evenals de vereiste configuratie voor het maken van virtuele netwerken die zijn gekoppeld aan de draadloze interfaces toestaan. Download en voer het script vim-Networking-Configuration.shuit, beschikbaar in de experiment opslagplaats, in de host waarop het UAV Cloud platform vim wordt uitgevoerd. Dit script houdt toezicht op het instellen van de draadloze communicatie van het VIM om de uitwisseling van informatie met de Sbc’s mogelijk te maken.Opmerking: zodra het netwerk goed is geconfigureerd en het VIM verbinding heeft met de Sbc’s, integreert het VIM deze automatisch in het UAV-Cloud platform als rekenkundige eenheden die VNFs kunnen uitvoeren Maak een OpenStack-beschikbaarheidszone voor elk van de Sbc’s. Hierdoor kan elk van de lichtgewicht VNFs van het experiment worden geïmplementeerd in een geschikte UAV-eenheid. Om dit te doen, Meld u aan bij de webgrafische gebruikersinterface die door de VIM met de beheerdersreferenties, maak de beschikbaarheidszones in de beheerder > systeem > host aggregaten tabblad, en bewerk elke beschikbaarheidszone om toe te voegen van de juiste host (dat wil zeggen, elke SBC geïntegreerd in het UAV Cloud platform). Controleer de juiste installatie van het UAV-Cloud platform. Hiertoe toegang tot de beheerder > systeem > systeeminformatie tabblad met dezelfde aanmelding als in de vorige stap en klikt u in de computing service en netwerk agenten sectie om te controleren of de status van de weergegeven items ‘ Alive ‘ en ‘ up ‘. 4. het experiment configureren Download de VNF-images die de verschillende onderdelen van de IP-telefonieservice implementeren: de AP-VNF, de DNS-VNF, IP-telephony-server-VNF, de AR-VNF en de CR-VNF. Deze installatiekopieën kunnen worden gedownload van de experiment opslagplaats. Upload de VNF-images naar hun correspondent VIM (d.w.z. de AP-VNF en de DNS-VNF naar het UAV Cloud platform VIM) en de VoIP-VNF naar het core Cloud platform VIM. Om dit te doen, meldt u zich aan bij de webgrafische gebruikersinterface die door elk VIM wordt geleverd met de beheerdersreferenties, klikt u op de knop afbeelding maken van de beheerder ≫ systeem > installatie kopieën tabblad en maakt u een afbeelding met behulp van het weergegeven formulier en het selecteren van de juiste afbeelding. Dit proces wordt uitgevoerd op het bijbehorende VIM voor elke afbeelding die is gedownload in de voorafgaande stap. Download de VNF descriptors (Vnfd’s) van het experiment uit de experiment opslagplaats. Deze descriptors bieden de sjablonen die de operationele vereisten van een VNF beschrijven, evenals de plaatsings beleidsregels die de beschikbaarheidszone aangeven die belast is met het hosten van de VNF zelf. Meer informatie over NFV-descriptors vindt u in het informatie model van OSM34. Upload de Vnfd’s. gebruik een webbrowser om toegang te krijgen tot de grafische gebruikersinterface van OSM en meld u aan met de beheerdersreferenties. Vervolgens sleept u de Vnfd’s naar het tabblad VNF-pakketten en zet u deze neer. Download de Network Services descriptor (NSD) uit de experiment opslagplaats. Deze descriptor is een sjabloon die aangeeft van de VNFs bestaande uit de service, evenals hoe deze VNFs zijn verbonden. Upload de NSD. Sleep de NSD naar het tabblad NS-pakketten van de grafische gebruikersinterface van OSM. Voeg met behulp van de grafische gebruikersinterface van OSM een VIM-account toe voor het UAV Cloud platform VIM en voor het core Cloud platform VIM. Om dit te doen, toegang tot de vim accounts tab met de beheerdersreferenties, klik op de knop + nieuwe vim en vul het weergegeven formulier met de gevraagde informatie. Herhaal deze actie voor beide Vip’s. 5. uitvoering van het experiment Implementeer de netwerkservice. Klik op het tabblad NS-pakketten van de grafische gebruikersinterface van OSM op de knop instantiëren NS van de nsd die is geüpload in stap 4,6. Vul vervolgens het weergegeven formulier, met vermelding van de VIM die wordt gebruikt voor het implementeren van elke VNF componeren van de NS. Bovendien is de OSM verantwoordelijk voor het verwerken van het Plaatsingsbeleid zoals aangegeven in de Vnfd’s om de VIM te specificeren die de beschikbaarheidszone (d.w.z. een rekeneenheid in onze testbed) is belast met het hosten van elke VNF. Voor dit experiment, de VNFs worden geplaatst in de Compute-eenheden zoals geïllustreerd in afbeelding 1.Opmerking: als een alternatieve methode biedt de OSM een opdrachtregelinterface die directe gebruikersinteractie mogelijk maakt. Een gebruiker die dit experiment reproduceren kan deze opdrachtregelinterface gebruiken, in plaats van de grafische interface, voor het uitvoeren van de verschillende stappen die zijn gedefinieerd in dit protocol, met name de stappen die betrekking hebben op het onboarding van een VNF of een NS-descriptor, evenals het implementeren van een Netwerkservice. Wacht tot de grafische gebruikersinterface van OSM het succes van de implementatie van de netwerkservice aangeeft.Opmerking: de werking van de netwerkdienst is volledig onafhankelijk van de vlucht van de UAVs: de IP-telefonieservice kan worden geleverd wanneer de UAVs vliegen of het batterijverbruik op een oppervlak op te slaan. Dus, stap 5,3 is optioneel. Haal de UAVs uit. Log in op de mobiele applicatie en bedien de vlucht van elke UAV om deze stabiel te houden in een tussenliggende hoogte en Vermijd de turbulentie veroorzaakt door de rotatie van de motoren dicht bij een oppervlak. Bereid elk van de IP-telefoons voor het uitvoeren van de oproep. Sluit een draadloze VoIP-telefoon aan op elk van de toegangspunten die door de netwerkdienst worden aangeboden. Specificeer hiervoor de SSID (Service Set Identifier) in het menu > Wireless ≫ SSID tab en kies de infrastructuur modus in het menu > draadloze > netwerkmodus sectie. Selecteer ten slotte de netwerkconfiguratie via het Dynamic Host Configuration Protocol (DHCP) in het menu ≫ net Settings > netwerkmodus tabblad. Configureer de SIP-parameters ( Session Initiation Protocol ) om de juiste uitwisseling van signalerings berichten met de IP-telefoonserver mogelijk te maken. In deze context, toegang tot het Menu ≫ SIP instellingen tabblad en geef de hostnaam van de IP-telefoonserver vnf (“dronesVoIP.net”) in de registrar > registrar IP en proxyserver > Proxy IP- tabbladen. Maak bovendien een gebruikersaccount aan met de naam van de gebruiker (bijvoorbeeld beller-A) in de gebruikersaccount ≫ telefoonnummer en gebruikersaccount > gebruikersnaam secties. Maak een vermelding in het telefoonboek van een van de IP-telefoons die de informatie van de gebruiker die moet worden aangeroepen. Om dit te doen, selecteert u het Menu ≫ telefoonboek > vermelding toevoegen tabblad, en vul de gevraagde parameters die verschijnen in het display als volgt: weergavenaam = beller-B; Gebruikers info = beller-B; Host IP = dronesVoIP.net; Poort = 5060. Selecteer ten slotte de optie “proxy” versus de P2P (peer-to-peer). Start de oproep naar de andere partij. Om dit te doen, selecteert u de opgeroepen partij met behulp van het Menu ≫ telefoonboek > Zoek optie van de IP-telefoon. Druk vervolgens op de gespreksknop. Zodra de andere IP-telefoon begint te rinkelen, accepteer je de inkomende oproep met de belknop. 6. procedure voor het verzamelen van experimentele resultaten Sluit een commodity laptop aan op een van de draadloze toegangspunten en voer het ping Command line tool uit naar het IP-adres van de telefoon die is aangesloten op de andere AP tijdens 180 s. Het IP-adres kan worden gecontroleerd in het Menu > informatie > IP-adres optie van de IP-telefoon zodra de verbinding tot stand is gebracht met het AP. Sla de RTT-metingen op, waarbij de uitvoer van de ping -tool wordt omgeleid naar een bestand. Voer het opdrachtregelprogramma tcpdump uit in een van de actieve AP vnfs om het verkeer dat tijdens de IP-aanroep wordt uitgewisseld, vast te leggen. Sla dit verkeer op in een bestand waarmee de schrijf vlag van het opdrachtregelhulpprogramma op de uitvoeringstijd wordt ingeschakeld en de naam van het bestand wordt opgegeven. Voer een nieuwe IP-telefonie oproep uit. Houd de oproep voor de gewenste tijdsperiode (bijvoorbeeld 1 min). Beëindig vervolgens het gesprek en druk op de knop ‘ hang up ‘ van een van de IP-telefoons. Houd de bestanden die worden gegenereerd door de tcpdump en ping tools voor verdere verwerking. Zie representatieve resultaten.

Representative Results

Op basis van de gegevens die zijn verkregen tijdens de uitvoering van het experiment, waarin een echte VoIP-oproep wordt uitgevoerd en volgens de door het protocol aangegeven stappen om deze informatie te verzamelen, ziet u in Figuur 2 de cumulatieve verdelingsfunctie van de eind-tot-eind vertraging, gemeten tussen twee onderdelen van eindgebruikers apparatuur (d.w.z. een basisproduct laptop en een IP-telefoon). Deze gebruikersapparatuur vertegenwoordigt twee apparaten die zijn verbonden via het AP-VNFs van de geïmplementeerde Netwerkservice. Meer dan 80% van de end-to-end delay metingen waren lager dan 60 MS, en geen van hen was hoger dan 150 MS, wat zorgt voor passende vertragings gegevens voor de uitvoering van een spraakoproep. Afbeelding 3 illustreert de uitwisseling van DNS-en SIP-signalerings berichten. Deze berichten corresponderen met de registratie van een van de gebruikers in de IP-telefonieserver (d.w.z. de gebruiker wiens IP-telefoon is aangesloten op de AP-VNF waar het hulpprogrammatcpdumpwordt uitgevoerd) en de instelling van het spraakgesprek. Tot slot tonen Figuur 4 en Figuur 5 het dataverkeer dat tijdens de oproep is vastgelegd. Met name de eerste vertegenwoordigt de constante stroom van de Voice-pakketten verzonden en ontvangen door een van de draadloze telefoons tijdens het gesprek, terwijl de laatste illustreert de jitter in de voorwaartse richting met een gemiddelde waarde lager dan 1 MS. De resultaten die zijn behaald in het experiment voor de vertragings cijfers (eind-tot-eind vertraging en jitter) voldoen aan de aanbevelingen van de Internationale Telecommunicatie-Unie-normalisatie sector voor telecommunicatie (ITU-T)35. Dienovereenkomstig, de spraakoproep vorderde zonder glitches en goede geluidskwaliteit. Dit experiment valideerde de praktische haalbaarheid van het gebruik van NFV-technologieën en UAVs om een functionele IP-telefonieservice te implementeren. Afbeelding 1: overzicht van de netwerkservice, met de VNFs, de entiteiten waarin ze worden uitgevoerd en de virtuele netwerken die nodig zijn voor de levering van de IP-telefonieservice. Klik hier om een grotere versie van dit cijfer te bekijken. Figuur 2: end-to-end vertraging. Weergave van de end-to-end vertraging die wordt aangeboden aan de eindgebruikerapparatuur die is verbonden met het AP-VNFs. Voor dit doel is de cumulatieve verdelingsfunctie van de end-to-end-vertraging berekend op de gemeten RTT-monsters die met het opdrachtregelprogramma “ping” zijn verkregen. Klik hier om een grotere versie van dit cijfer te bekijken. Afbeelding 3: gebruikersregistratie en oproep signalering van berichten. Illustratie van het signaleringsverkeer (DNS en SIP) dat wordt uitgewisseld om een gebruiker te registreren op de IP-telefoonserver en om de multimedia sessie te maken en te beëindigen die de uitvoering van de spraakoproep ondersteunt. Klik hier om een grotere versie van dit cijfer te bekijken. Figuur 4: stream van spraak pakketten. Weergave van het spraakverkeer dat tijdens de oproep wordt uitgewisseld, gemeten bij een van de AP-VNFs. (afkortingen: RX = ontvangen, RX = Transmit, RTP = real-time Transport Protocol). Klik hier om een grotere versie van dit cijfer te bekijken. Figuur 5: evolutie van de netwerk-jitter tijdens de oproep. Representatie van de jitter ervaren door de verzonden Voice pakketten in de voorwaartse richting van de ene telefoon naar de andere. Klik hier om een grotere versie van dit cijfer te bekijken.

Discussion

Een van de belangrijkste aspecten van dit experiment is het gebruik van virtualisatietechnologieën en NFV-standaarden met UAV-platforms. NFV presenteert een nieuw paradigma gericht op het loskoppelen van de hardware afhankelijkheid van de netwerk functionaliteiten, waardoor de levering van deze functionaliteiten door middel van softwarisatie. Het experiment is dus niet afhankelijk van het gebruik van de in het protocol gespecificeerde hardwareapparatuur. Als alternatief kunnen verschillende modellen van single board computers worden geselecteerd, zolang ze in lijn zijn met de afmetingen en de transportcapaciteit van de UAVs en ze ondersteunen Linux-containers.

Niettegenstaande deze flexibiliteit in termen van hardware-selectie, is alle inhoud voor de reproduceerbaarheid van het experiment gericht op het gebruik van open source-technologieën. In deze context, de configuratie aspecten en de software tools zijn geconditioneerd aan het gebruik van Linux als het besturingssysteem.

Aan de andere kant beschouwt het experiment de onderlinge werking van twee verschillende reken platformen (d.w.z. het UAV-Cloud platform en het core Cloud platform) om een redelijk complexe netwerkservice te bieden. Dit is echter niet strikt noodzakelijk en het protocol kan worden gevolgd om scenario’s te ondersteunen waarin alleen het UAV-Cloud platform betrokken is.

Bovendien kan de gepresenteerde oplossing mogelijk worden gebruikt in andere omgevingen, waar hardwaregebonden hardwareplatforms mogelijk beschikbaar zijn met de benodigde capaciteit voor het uitvoeren van virtualisatiecontainers (bijvoorbeeld het internet of things, of IoT, omgevingen). In ieder geval zal de toepasselijkheid van deze oplossing op verschillende omgevingen en de mogelijke aanpassingen ervan een zorgvuldige studie vereisen, per geval.

Ten slotte moet worden opgemerkt dat de gepresenteerde resultaten zijn verkregen in een laboratoriumomgeving en dat de UAV-apparaten zijn geaard of volgens een beperkt en goed gedefinieerd vliegplan. Andere scenario’s met betrekking tot buiten implementaties kunnen voorwaarden introduceren die de stabiliteit van de vlucht van de UAVs beïnvloeden, en daarmee de prestaties van de IP-telefonieservice.

Disclosures

The authors have nothing to disclose.

Acknowledgements

Dit werk werd deels gesteund door het European H2020 5GRANGE project (subsidieovereenkomst 777137) en door het 5GCIty project (TEC2016-76795-C6-3-R) gefinancierd door het Spaanse ministerie van economie en concurrentievermogen. Het werk van Luis F. Gonzalez werd deels gesteund door het European H2020 5GinFIRE project (subsidieovereenkomst 732497).

Materials

AR. Drone 2.0 – Elite edition Parrot UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform.
Bebop 2 Parrot UAV used in the experiment to transport the RPis and thus, provide mobility to the compute units of the UAV cloud platform.
Commercial Intel Core Mini-ITX Computer Logic Suppy Computer server which hosts the OpenStack controller node (being executed as a VM) of the experiment's UAV cloud platform. In addition, another unit of this equipment (along with the RPis) conforms the computational resources of the UAV cloud platform.
Linux Containers (LXC) Canonical Ltd. (Software) Virtualization technology that enables the supply of the Virtual Network Functions detailed in the experiment. Source-code available online: https://linuxcontainers.org
Lithium Battery Pack Expansion Board. Model KY68C-UK Kuman Battery-power supply HAT (Hardware Attached on Top) for the computation units of the UAV cloud platform (i.e., the Raspberry Pis). In addition, this equipment encompasses the case used to attach the compute units (i.e., the Raspberry PIs or RPis) to the UAVs.
MacBook Pro Apple Commodity laptop utilized during the experiment to obtain and gather the results as described in the manuscript.
ns-3 Network Simulator nsnam (Software) A discrete-event simulator network simulator which provides the underlying communication substrate to the emulation station explained in the "Protocol" section (more specifically in the step "2. Validate the functionality of the softwarization units via Emulation"). Source-code available online: https://www.nsnam.org
Open Source MANO (OSM) – Release FOUR ETSI OSM – Open source community (Software) Management and Orchestration (MANO) software stack of the NFV system configured in the experiment. Source-code available online: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack – Release Ocata OpenStack – Open source community (Software) Open source software used for setting up both the UAV cloud platform and the core cloud within the experiment. Source-code available online: https://docs.openstack.org/ocata/install-guide-ubuntu
Ping Open source tool (Software) An open source test tool, which verifies the connectivity between two devices connected through a communications network. In addition, this tool allows to assess the network performance since it calculates the Round Trip Time (i.e., the time taken to send and received a data packet from the network). Source-code available online: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430 Dell High-profile computer server which provides the computational capacity within the core cloud platform presented in the experiment.
Power Edge R630 Dell Equipment used for hosting the virtual machine (VM) on charge of executing the MANO stack. In addition, the OpenStack controller node is also executed as a VM in this device. Note that the use of this device is not strictly needed. The operations carried out by this device could be done by a lower performance equipment due to the non-high resource specifications of the before mentioned VMs.
Prestige 2000W ZyXEL Voice over IP Wi-FI phone, compatible with the IEEE 802.11b wireless communications standard. This device is utilized to carry out the VoIP call through the network service hosted by platform described for the execution of the experiment.
Raspberry PI. Model 3b Raspberry Pi Foundation Selected model of Single Board Computer (SBC) used for providing the computational capacity to the experiment's UAV cloud platform.
SIPp Open source tool (Software) An open source test tool, which generates SIP protocol traffic. This tool allows to verify the proper support of the signalling traffic required in an IP telephony service such as the one deployed in the experiment. Source-code available online: http://sipp.sourceforge.net
Tcpdump Open source tool (Software) An open source tool that enables the capture and analysis of the network traffic. Source-code available online: https://www.tcpdump.org
Trafic Open source tool (Software) An open souce flow scheduler that is used for validating the capacity of the network service deployed to process data traffic generated during an IP telephony call. Source-code available online at: https://github.com/5GinFIRE/trafic

References

  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, 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, 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. , 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. , 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. , 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. , 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). , 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). , (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. , 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). , (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. . Trafic. An open source flow scheduler Available from: https://github.com/5GinFIRE/trafic (2019)
  31. . Ubuntu Mate for the Raspberry Pi Available from: https://ubuntu-mate.org/raspberry-pi/ (2019)
  32. Enabling LXC (Linux Containers) as virtualization technology. OpenStack Available from: https://docs.openstack.org/ocata/config-reference/compute/hypervisor-lxc.html (2019)
  33. . Open Source MANO Information Model Available from: https://osm.etsi.org/wikipub/index.php/OSM_Information_Model (2019)
  34. 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).

Play Video

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).

View Video