Artykuł metodologiczny

Zautomatyzowane wdrażanie usługi telefonii protokołu internetowego na bezzałogowych statkach powietrznych z wykorzystaniem wirtualizacji funkcji sieciowych

DOI:

10.3791/60425

⸱

26 listopada 2019

 ,  ,  ,  ,  , 
1Department of Telematic Engineering, Universidad Carlos III de Madrid, 2IMDEA Networks Institute

* These authors contributed equally

W tym artykule

Podsumowanie

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Cel opisanego protokołu jest dwojaki: skonfigurować środowisko wirtualizacji funkcji sieciowych za pomocą bezzałogowych statków powietrznych jako jednostek obliczeniowych dostarczających podstawową strukturę do wykonywania zwirtualizowanych funkcji sieciowych i wykorzystać to środowisko do wsparcia automatycznego wdrażania funkcjonalnej usługi telefonii protokołu internetowego nad statkami powietrznymi.

Streszczenie

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Paradygmat wirtualizacji funkcji sieciowych (NFV) jest jedną z kluczowych technologii wspomagających rozwój sieci komórkowych piątejgeneracji. Technologia ta ma na celu zmniejszenie zależności od sprzętu w dostarczaniu funkcji i usług sieciowych poprzez zastosowanie technik wirtualizacji, które umożliwiają miękką obsługę tych funkcji w warstwie abstrakcji. W tym kontekście rośnie zainteresowanie badaniem potencjału bezzałogowych statków powietrznych (UAV) w celu zaoferowania elastycznej platformy zdolnej do umożliwienia opłacalnych operacji NFV na wyznaczonych obszarach geograficznych.

Aby zademonstrować praktyczną możliwość wykorzystania technologii NFV na platformach UAV, przedstawiono protokół do stworzenia funkcjonalnego środowiska NFV opartego na technologiach open source, w którym zestaw małych UAV dostarcza zasoby obliczeniowe, które wspierają wdrażanie umiarkowanie złożonych usług sieciowych. Następnie protokół szczegółowo opisuje różne kroki potrzebne do obsługi automatycznego wdrażania usługi telefonii protokołu internetowego (IP) w sieci połączonych ze sobą UAV, wykorzystując możliwości skonfigurowanego środowiska NFV. Wyniki eksperymentów pokazują poprawne działanie usługi po jej wdrożeniu. Chociaż protokół koncentruje się na określonym typie usługi sieciowej (tj. telefonii IP), opisane kroki mogą służyć jako ogólny przewodnik do wdrażania innych typów usług sieciowych. Z drugiej strony, opis protokołu uwzględnia konkretny sprzęt i oprogramowanie do konfiguracji środowiska NFV (np. określone komputery jednopłytkowe i oprogramowanie open source). Wykorzystanie innych platform sprzętowych i programowych może być wykonalne, chociaż specyficzny aspekt konfiguracji środowiska NFV i wdrożenia usługi może wykazywać różnice w stosunku do tych opisanych w protokole.

Wprowadzenie

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Jednym z najbardziej pożądanych celów w nowej erze komunikacji mobilnej (najczęściej znanej jako piąta generacjatelefonii komórkowej lub 5G) jest możliwość świadczenia solidnych usług informatycznych w sytuacjach, gdy podstawowa infrastruktura telekomunikacyjna może nie być dostępna (np. z powodu sytuacji awaryjnej). W tym kontekście bezzałogowe statki powietrzne cieszą się coraz większym zainteresowaniem społeczności naukowej ze względu na ich nieodłączną wszechstronność. Istnieje wiele prac, które wykorzystują te urządzenia jako podstawę świadczenia szerokiej gamy usług. Na przykład w literaturze przeanalizowano zdolność tych urządzeń do budowy infrastruktury komunikacji powietrznej w celu obsługi usług multimedialnych1,2,3. Co więcej, wcześniejsze badania wykazały, w jaki sposób współpraca między kilkoma bezzałogowymi statkami powietrznymi może rozszerzyć funkcjonalność różnych usług komunikacyjnych, takich jak surveillance4, Collaborative Search and Rescue5,6,7,8, lub agribusiness9.

Z drugiej strony, technologia NFV zyskała duże znaczenie wśród operatorów telekomunikacyjnych jako jeden z kluczowych czynników umożliwiających 5G. NFV stanowi zmianę paradygmatyczną w odniesieniu do infrastruktury telekomunikacyjnej poprzez zmniejszenie obecnej zależności urządzeń sieciowych od specjalistycznego sprzętu poprzez softwaryzację funkcjonalności sieci. Umożliwia to elastyczne i sprawne wdrażanie nowych typów usług komunikacyjnych. W tym celu Europejski Instytut Norm Telekomunikacyjnych (ETSI) utworzył grupę ds. specyfikacji w celu zdefiniowania struktury architektonicznej NFV10. Ponadto ETSI obsługuje obecnie grupę Open Source Mano (OSM), 11, która jest odpowiedzialna za rozwój stosu oprogramowania NFV Management and Orchestration (MANO) zgodnego z definicją ramy architektonicznej ETSI NFV.

Biorąc pod uwagę wszystkie powyższe rozważania, synergiczna konwergencja między UAV a technologiami NFV jest obecnie badana w rozwoju nowych aplikacji i usług sieciowych. Ilustruje to kilka prac badawczych w literaturze, które wskazują na zalety tego typu systemów14,15,16, identyfikują wyzwania tej konwergencji i jej brakujące aspekty, podkreślają przyszłe kierunki badań na ten temat17, oraz prezentują pionierskie rozwiązania oparte na technologiach open source.

W szczególności, integracja technologii NFV z areną UAV umożliwia szybkie i elastyczne wdrażanie usług sieciowych i aplikacji na wyznaczonych obszarach geograficznych (np. usługa telefonii IP). Zgodnie z tym podejściem, pewna liczba bezzałogowych statków powietrznych może zostać rozmieszczona nad określoną lokalizacją, transportując platformy obliczeniowe jako ładunek (np. małe komputery jednopłytkowe). Te platformy obliczeniowe zapewniałyby programowalną infrastrukturę sieciową (tj. infrastrukturę NFV) na obszarze wdrożenia, obsługując tworzenie instancji usług sieciowych i aplikacji pod kontrolą platformy ANO.

Niezależnie od korzyści, realizacja tego poglądu przedstawia zestaw fundamentalnych wyzwań, które muszą być starannie rozwiązane, takie jak odpowiednia integracja tych platform obliczeniowych jako infrastruktury NFV, przy użyciu istniejącego stosu oprogramowania NFV, tak aby usługa orkiestracji NFV mogła wdrażać wirtualne funkcje na UAV; ograniczenia w zakresie zasobów obliczeniowych dostarczanych przez platformy obliczeniowe, ponieważ transportujące je bezzałogowe statki powietrzne mogą zazwyczaj stwarzać ograniczenia pod względem rozmiaru, masy i mocy obliczeniowej sprzętu do udźwigu; właściwe rozmieszczenie funkcji wirtualnych na bezzałogowych statkach powietrznych (tj. wybór najlepszego kandydata na UAV do wdrożenia określonej funkcji wirtualnej); utrzymanie łączności sterowniczej z bezzałogowymi statkami powietrznymi w celu zarządzania cyklem życia bezzałogowych statków powietrznych pomimo potencjalnie sporadycznej dostępności łączności sieciowej z tymi statkami bezzałogowymi (np. spowodowanej ograniczeniami w zakresie mobilności i akumulatorów); ograniczony czas działania bezzałogowych statków powietrznych ze względu na zużycie baterii; oraz migracja funkcji wirtualnych, gdy UAV musi zostać wymieniony z powodu wyczerpania baterii. Te korzyści i wyzwania zostały szczegółowo opisane w poprzedniej pracy18,19, która obejmuje projekt systemu NFV zdolnego do wspierania automatycznego wdrażania funkcji i usług sieciowych na platformach UAV, a także walidację praktycznej wykonalności tego projektu.

W tym kontekście, ten artykuł skupia się na opisie protokołu umożliwiającego automatyczne wdrażanie umiarkowanie złożonych usług sieciowych przez sieć UAV przy użyciu standardów NFV i technologii open source. Aby zilustrować różne etapy protokołu, przedstawiono ponowne opracowanie eksperymentu przedstawionego w Nogales et al.19, polegającego na wdrożeniu usługi telefonii IP. Aby zwiększyć powtarzalność tej pracy, w przedstawionej procedurze lot rzeczywisty jest uważany za opcjonalny, a wyniki osiągów uzyskuje się za pomocą urządzeń UAV na ziemi. Zainteresowani czytelnicy powinni być w stanie odtworzyć i zweryfikować wykonanie protokołu, nawet w kontrolowanym środowisku laboratoryjnym.

Rysunek 1 ilustruje usługę sieciową zaprojektowaną dla tej procedury. Ta usługa sieciowa jest zbudowana jako kompozycja określonych jednostek softwarization (skategoryzowanych w paradygmacie NFV jako Virtual Network Functions lub VNF) i zapewnia funkcjonalność usługi telefonii IP użytkownikom znajdującym się w pobliżu UAV. VNF wchodzące w skład usługi są zdefiniowane w następujący sposób:

  • Punkt dostępowy VNF (AP-VNF): Ten punkt dostępowy VNF zapewnia punkt dostępowy Wi-Fi do urządzeń użytkowników końcowych (tj. telefonów IP w tym eksperymencie).
  • Serwer telefonii IP VNF (IP-telephony-server-VNF): Odpowiada za zarządzanie komunikatami sygnalizacji połączeń, które są wymieniane między telefonami IP w celu nawiązania i zakończenia połączenia głosowego.
  • System nazw domen VNF (DNS-VNF): Ten system VNF udostępnia usługę rozpoznawania nazw, która jest zwykle potrzebna w usługach telefonii IP.
  • Router dostępowy VNF (AR-VNF): zapewnia funkcje routingu sieciowego, wspierając wymianę ruchu (tj. sygnalizację połączeń w tym eksperymencie) między telefonami IP a domeną operatora telekomunikacyjnego.
  • Router Core VNF (CR-VNF): zapewnia funkcje routingu sieciowego w domenie operatora telekomunikacyjnego, oferując dostęp do usług specyficznych dla operatora (tj. serwera telefonii IP) i zewnętrznych sieci danych.

Ponadto, Rysunek 1 przedstawia fizyczne urządzenia użyte w eksperymencie, sposób ich wzajemnego połączenia oraz konkretny przydział VNF do urządzeń.

Protokół

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

1. Wymagania wstępne do eksperymentu

  1. Zainstaluj stos oprogramowania do zarządzania i orkiestracji (MANO) dostarczony przez projekt Open Source MANO (OSM). W szczególności w tym eksperymencie wykorzystano OSM Release FOUR20, który może być wykonany na pojedynczym komputerze serwerowym lub na maszynie wirtualnej (VM) spełniającej wymagania określone przez społeczność OSM: Ubuntu 16.04 jako system operacyjny (64-bitowy obraz wariantu), dwie jednostki centralne (CPU), 8 GB pamięci o dostępie swobodnym (RAM), dysk o pojemności 40 GB, oraz pojedynczy interfejs sieciowy z dostępem do Internetu. Procedura instalacji OSM Release FOUR wraz ze szczegółami technicznymi jest dostępna w dokumentacji online dostarczonej przez społeczność OSM21.
  2. Skonfiguruj platformę przetwarzania w chmurze, zapewniającą funkcje wirtualnego menedżera infrastruktury (VIM) zgodną z OSM Release FOUR. W tym eksperymencie użyto wersji OpenStack Ocata22, działającej na maszynie wirtualnej z systemem operacyjnym Ubuntu 16.04, czterema procesorami, 16 GB pamięci RAM i dyskiem o pojemności 200 GB. W eksperymencie VIM zarządza infrastrukturą NFV (NFVI) zintegrowaną przez dwa wysokiej klasy komputery serwerowe, każdy z systemem operacyjnym Ubuntu 16.04, ośmioma procesorami, 128 GB pamięci RAM i dyskiem o pojemności 4 TB). Wszystkie informacje na temat konfiguracji platformy przetwarzania w chmurze znajdują się w instrukcji instalacji dołączonej do dokumentacji OpenStack23. Ta platforma chmurowa jest określana jako podstawowa platforma chmurowa.
  3. Utworzenie dodatkowej platformy przetwarzania w chmurze dla UAV jest określane jako platforma chmurowa UAV.
    1. Upewnij się, że ta platforma jest wyposażona w VIM oparty na wydaniu OpenStack Ocata. W tym przypadku zasoby używane przez instalację VIM to Ubuntu 16.04 jako system operacyjny, dwa procesory, 6 GB pamięci RAM, dysk 100 GB pamięci masowej i zewnętrzna karta Wi-Fi USB.
    2. NFVI zintegrowany z tą platformą chmurową składa się z jednego stałego serwera obliczeniowego (Ubuntu 16.04 jako system operacyjny, osiem procesorów, 8 GB pamięci RAM, 128 GB dysku pamięci masowej i zewnętrzna karta Wi-Fi USB) oraz trzech komputerów jednopłytkowych (SBC). Te ostatnie zapewniają platformę sprzętową, którą można łatwo zaokrętować na pokładzie UAV. Sekcja 3 zawiera procedurę konfiguracji platformy chmurowej UAV z tymi urządzeniami jako węzłami obliczeniowymi.
  4. Wyposaż każdy kontroler SBC w osprzęt zasilający bateryjny przymocowany na górze (HAT), aby zapewnić działanie tych jednostek nawet wtedy, gdy są w ruchu, przenoszone przez UAV.
    UWAGA: Krok 1.5 jest opcjonalny, ponieważ świadczenie usługi sieciowej w eksperymencie nie zależy od posiadania UAV. Ponadto komputery jednopłytkowe (SBC) są przenoszone jako ładunek użyteczny bezzałogowych statków powietrznych i nie są potrzebne żadne inne dodatkowe połączenia (np. Ethernet lub USB), ponieważ komunikacja sieciowa wymagana do prawidłowego działania usługi telefonii IP jest zapewniana przez kontrolery SBC za pośrednictwem ich adapterów Wi-Fi, a zasilanie jest zapewniane przez zasilacz HAT wspomniany w kroku 1.4.
  5. Przymocuj każdy SBC jako ładunek użyteczny UAV za pomocą akcesorium mocującego. W tym eksperymencie wybrano trzy komercyjne bezzałogowe statki powietrzne (UAV) do transportu jednostek obliczeniowych oferowanych przez kontrolery SBC.
  6. Wybierz dwa telefony bezprzewodowe VoIP (Wireless Voice-over-IP), które obsługują standard komunikacji bezprzewodowej IEEE 802.11b; ten model zapewnia komunikację bezprzewodową za pośrednictwem sieci Wi-Fi. Alternatywnie połączenie głosowe może być wykonywane za pomocą aplikacji softphone, takich jak Linphone24 lub Jitsi25.
  7. Jako wymóg eksperymentalny upewnij się o dostępności: a) komunikacji warstwy 3 między stosem oprogramowania OSM a każdym z VIM-ów, aby umożliwić zorganizowane wdrożenie usługi sieciowej opracowanej na potrzeby tego eksperymentu, b) komunikacji warstwy 3 między OSM a VNF na każdej platformie chmurowej w celu obsługi procedur konfiguracji VNF oraz c) komunikacji warstwy 3 między VNF działającymi na każdym VIM-ie, aby umożliwić prawidłowe funkcjonowanie usługi sieciowej.
  8. Cała zawartość potrzebna do przeprowadzenia eksperymentu znajduje się w publicznym repozytorium eksperymentów http://vm-images.netcom.it.uc3m.es/JoVE/.

2. Walidacja funkcjonalności jednostek softwarization poprzez emulację

UWAGA: Aby udowodnić prawidłowe działanie usługi sieciowej eksperymentu (zobacz Rysunek 1) w realistycznych warunkach wdrażania, użyto platformy emulacji opartej na kontenerach Linux26 i ns-327. Platforma ta umożliwia emulację łączy powietrznych typu multi-hop i definiowanie charakterystyki tych łączy (np. długość łączy komunikacji bezprzewodowej, wzorzec utraty pakietów danych, technologia radiowa stosowana w komunikacji bezprzewodowej itp.). W związku z tym w tej sekcji protokołu opisano kroki, które należy wykonać, aby zweryfikować prawidłowe działanie usługi telefonii IP w realistycznych warunkach łącza komunikacji bezprzewodowej za pośrednictwem platformy emulacji.

  1. Pobierz platformę emulacji z repozytorium eksperymentów. Platforma jest dostępna jako maszyna wirtualna o nazwie "uav-nfv-jove-experiment.qcow", zgodna z technologią wirtualizacji KVM28. Ten komputer zawiera wstępnie utworzony szablon, który emuluje usługę sieciową i scenariusz wielu UAV przedstawiony w Rysunek 1 oraz użytkownika z uprawnieniami administratora, który może wykonać ten szablon.
    UWAGA: Domyślnie następujące kroki są wykonywane automatycznie po uruchomieniu maszyny wirtualnej platformy emulacji: a) środowisko wirtualne jest skonfigurowane do włączania emulacji sieci (tj. interfejsy sieciowe, Linux bridges29); b) tworzone są kontenery Linux reprezentujące różne fizyczne komponenty stanowiska testowego (tj. kontrolery SBC i stały serwer obliczeniowy dla platformy chmurowej UAV oraz serwer obliczeniowy dla podstawowej platformy chmurowej); oraz c) funkcje zapewniane przez różne VNF usługi telefonii IP (tj. punkty dostępowe, routery, serwer DNS i serwer telefonii IP) są wdrażane jako kontenery Linux na odpowiadających im emulowanych kontrolerach SBC i serwerach obliczeniowych.
  2. Przed procesem walidacji należy skonfigurować emulowaną sieć antenową z wieloma przeskokami za pomocą symulatora ns-3, aby umożliwić łączność między różnymi uczestnikami sieci. Ta procedura będzie emulować realistyczną komunikację bezprzewodową, która ma miejsce w scenariuszu przedstawionym na Rysunek 1 (tj. sieć ad-hoc Wi-Fi, która umożliwia wymianę danych między węzłami platformy chmurowej UAV a sieciami bezprzewodowymi oferowanymi przez dwa punkty dostępowe Wi-Fi udostępnione w usłudze).
    1. Utwórz sieć napowietrzną z wieloma przeskokami. W tym celu należy uruchomić skrypt multi-hop-aerial-net.sh (dostępny na maszynie platformy emulacji) za pomocą następującego polecenia: sudo sh /home/jovevm/scripts/multi-hop-aerial-net.sh > multi-hop-aerial-net-trace.log 2>&1 &. To polecenie przedstawia ślad symulacji w określonym pliku dziennika, aby umożliwić debugowanie w przypadku błędów.
    2. Sprawdź, czy sieć została pomyślnie utworzona. W tym celu sprawdź, czy kontenery systemu Linux "IP-phone-a" i "IP-phone-b" (zilustrowane na rysunku Rysunek 1 jako sprzęt użytkownika końcowego, który łączy się z AP-VNF) uzyskały adres IP za pośrednictwem usługi DHCP, która jest dostępna tylko za pośrednictwem sieci antenowej multi-hop. Status kontenera Linuksa wykonywanego w maszynie emulującej, a także ich adresy IP, można sprawdzić za pomocą polecenia lxc list.
  3. Sprawdź zdolność emulowanej usługi sieciowej do przetwarzania komunikatów sygnalizacyjnych potrzebnych do skonfigurowania połączenia telefonii IP. W tym celu zarówno kontenery linuksowe "IP-phone-a" jak i "IP-phone-b" mają zainstalowane narzędzie "SIPp"30. "SIPp" zapewnia funkcjonalność emulacji telefonu IP tworzącego wspomniane komunikaty sygnalizacyjne, wysyłania ich do serwera telefonii IP i przetwarzania odpowiedzi w celu weryfikacji poprawności działania tego ostatniego.
    1. Wykonaj skrypt test-signaling.sh w obu kontenerach, który uruchamia narzędzie "SIPp" w celu generowania i wysyłania komunikatów sygnalizacyjnych do serwera telefonii IP-VNF.
    2. Sprawdź ekran scenariusza udostępniony przez wykonanie poprzedniego kroku. Odbiór odpowiedzi "200" świadczy o prawidłowym funkcjonowaniu serwera telefonii IP-VNF.
  4. Sprawdź, czy usługa sieciowa może przetwarzać ruch danych generowany podczas połączenia telefonii IP. W tym celu w kontenerach Linuxa "IP-phone-a" i "IP-phone-b" zainstalowane jest narzędzie do planowania przepływu "Trafic"31.
    1. Wykonaj następujące polecenie, aby uruchomić agenta serwera Trafic: lxc exec IP-phone-b sh called-party.sh.
    2. Następnie wykonaj następujące polecenie, aby uruchomić agenta klienta Trafic i uzyskać statystyki sieci: lxc exec IP-phone-a sh caller.sh. Ruch danych emulujący połączenie głosowe jest przerywany po 60 sekundach. Skrypt wyświetla komunikat potwierdzający i najważniejsze wskaźniki wydajności dotyczące ruchu głosowego.
    3. Sprawdź uzyskane metryki i zweryfikuj, czy usługa telefonii IP może skutecznie obsługiwać interaktywną rozmowę głosową. W tym celu należy zapoznać się z informacjami zawartymi w sekcji dotyczącej reprezentatywnych wyników.

3. Budowa platformy chmurowej UAV

  1. Wybierz model kontrolera SBC, który może zapewnić podłoże do wirtualizacji do wykonywania lekkich funkcji VNF. Specyfikacja techniczna urządzeń SBC wykorzystanych podczas eksperymentu to: cztery procesory, 1 GB pamięci RAM i dysk o pojemności 32 GB. Dodatkowo każdy kontroler SBC ma trzy interfejsy sieciowe: interfejs Ethernet, zintegrowany interfejs Wi-Fi i zewnętrzny adapter Wi-Fi USB.
  2. Przygotowanie komputerów jednopłytkowych (SBC) do późniejszej integracji z platformą chmurową UAV.
    1. Zainstaluj Ubuntu Mate32 16.04.6 jako system operacyjny, biorąc pod uwagę, że pakiety instalacyjne OpenStack są zawarte w tej dystrybucji Linuksa.
    2. Zainstaluj i skonfiguruj wymagane pakiety zgodnie z opisem w dokumentacji OpenStack33, aby umożliwić kontrolerom SBC działanie jako węzły obliczeniowe platformy chmurowej UAV. Postępując zgodnie z poprzednim przewodnikiem, włącz wykorzystanie kontenerów Linux w konfiguracji pakietów OpenStack. Wirtualizacja kontenerów jest stosowana ze względu na ograniczenia zasobów urządzeń, które zwykle można wdrażać na małych UAV.
    3. W kontrolerze SBC pobierz i wykonaj skrypt rpi-networking-configuration.sh dostępny w repozytorium eksperymentów. Ten skrypt umożliwia komunikację bezprzewodową kontrolerów SBC, a także wymaganą konfigurację umożliwiającą tworzenie sieci wirtualnych dołączonych do interfejsów bezprzewodowych.
    4. Pobierz i wykonaj skrypt VIM-networking-configuration.sh, dostępny w repozytorium eksperymentu, na hoście z uruchomioną platformą chmurową UAV VIM. Ten skrypt nadzoruje konfigurację komunikacji bezprzewodowej VIM w celu umożliwienia wymiany informacji z kontrolerami SBC.
      UWAGA: Po prawidłowym skonfigurowaniu sieci i nawiązaniu połączenia z kontrolerami SBC, układ VIM automatycznie integruje je z platformą chmurową UAV jako jednostki obliczeniowe zdolne do wykonywania funkcji VNF
  3. Utwórz strefę dostępności OpenStack dla każdego z kontrolerów SBC. Pozwoli to na rozmieszczenie każdego z lekkich VNF eksperymentu w odpowiedniej jednostce UAV. W tym celu zaloguj się do graficznego interfejsu użytkownika udostępnionego przez kontroler VIM za pomocą poświadczeń administratora, utwórz strefy dostępności na karcie Administrator > System > Host Aggregates (Agregacje hostów) i edytuj każdą strefę dostępności, aby dodać odpowiedni host (tj. każdy kontroler SBC zintegrowany z platformą chmurową UAV).
  4. Sprawdź poprawność konfiguracji platformy chmurowej UAV. Aby to zrobić, przejdź do zakładki Administrator > System > System Information, używając tego samego loginu, co w poprzednim kroku, a następnie kliknij w sekcji Computing Service and Network Agents (Usługa obliczeniowa i agenci sieciowi), aby sprawdzić, czy stan wyświetlanych elementów to "Alive" (Aktywny) i "UP".

4. Konfiguracja eksperymentu

  1. Pobierz obrazy VNF, które implementują różne składniki usługi telefonii IP: AP-VNF, DNS-VNF, IP-telefony-server-VNF, AR-VNF i CR-VNF. Obrazy te można pobrać z repozytorium eksperymentów.
  2. Prześlij obrazy VNF do odpowiadającego im VIM (tj. AP-VNF i DNS-VNF do platformy chmurowej UAV VIM), a VoIP-VNF do podstawowej platformy chmurowej VIM. W tym celu należy zalogować się do graficznego interfejsu użytkownika udostępnionego przez każdy z kontrolerów VIM z danymi uwierzytelniającymi administratora, kliknąć przycisk Create Image (Utwórz obraz) na karcie Administrator > System > Images (System Images) i utworzyć obraz, korzystając z wyświetlonego formularza i wybierając odpowiedni obraz. Ten proces jest wykonywany na odpowiednim VIM dla każdego obrazu, który został pobrany w poprzednim kroku.
  3. Pobierz deskryptory VNF (VNFD) eksperymentu z repozytorium eksperymentów. Te deskryptory zawierają szablony opisujące wymagania operacyjne VNF, a także zasady umieszczania, które wskazują strefę dostępności odpowiedzialną za hostowanie samej funkcji VNF. Więcej informacji na temat deskryptorów NFV można znaleźć w modelu informacyjnym OSM34.
  4. Prześlij VNFD. Użyj przeglądarki internetowej, aby uzyskać dostęp do graficznego interfejsu użytkownika OSM i zaloguj się przy użyciu poświadczeń administratora. Następnie przeciągnij i upuść VNFD na kartę Pakiety VNF.
  5. Pobierz deskryptor usług sieciowych (NSD) z repozytorium eksperymentów. Ten deskryptor jest szablonem, który określa VNF składające się na usługę, a także sposób, w jaki te VNF są ze sobą połączone.
  6. Prześlij NSD. Przeciągnij i upuść NSD na zakładkę Pakiety NS w graficznym interfejsie użytkownika OSM.
  7. Korzystając z graficznego interfejsu użytkownika OSM, dodaj konto VIM dla platformy chmurowej UAV VIM i dla podstawowej platformy chmurowej VIM. W tym celu należy wejść na zakładkę Konta VIM z danymi uwierzytelniającymi administratora, kliknąć przycisk + Nowy VIM i wypełnić wyświetlony formularz żądanymi informacjami. Powtórz tę czynność dla obu VIM-ów.

5. Przeprowadzanie eksperymentu

  1. Wdróż usługę sieciową. Na karcie Pakiety NS w graficznym interfejsie użytkownika OSM kliknij przycisk Utwórz instancję NS w NSD przesłanym w kroku 4.6. Następnie wypełnij wyświetlony formularz, wskazując VIM, który będzie używany do wdrożenia każdego VNF składającego się na NS. Ponadto OSM jest odpowiedzialny za przetwarzanie zasad umieszczania wskazanych w VNFD w celu określenia VIM-a, która strefa dostępności (tj. jednostka obliczeniowa w naszym środowisku testowym) jest odpowiedzialna za hostowanie każdej VNF. W tym eksperymencie VNF są umieszczane w jednostkach obliczeniowych, jak pokazano na Rysunek 1.
    UWAGA: Jako alternatywną metodę, OSM zapewnia interfejs wiersza poleceń, który umożliwia bezpośrednią interakcję z użytkownikiem. Użytkownik odtwarzający ten eksperyment może użyć tego interfejsu wiersza polecenia, zamiast interfejsu graficznego, do wykonania różnych kroków zdefiniowanych w tym protokole, szczególnie tych związanych z dołączaniem deskryptora VNF lub NS, a także wdrażaniem usługi sieciowej.
  2. Poczekaj, aż graficzny interfejs użytkownika OSM wskaże powodzenie wdrożenia usługi sieciowej.
    UWAGA: Działanie usługi sieciowej jest całkowicie niezależne od lotu UAV: Usługa telefonii IP może być świadczona, gdy UAV latają lub oszczędzają zużycie baterii siedząc na powierzchni. W związku z tym krok 5.3 jest opcjonalny
    3. .
  3. Wystartuj z UAV. Zaloguj się do aplikacji mobilnej i kontroluj lot każdego UAV, aby stabilnie utrzymać go na pośredniej wysokości i uniknąć turbulencji spowodowanych obrotem silników blisko powierzchni.
  4. Przygotuj każdy z telefonów IP do przeprowadzenia połączenia.
    1. Podłącz bezprzewodowy telefon VoIP do każdego z punktów dostępowych oferowanych przez usługę sieciową. W tym celu należy określić SSID (Service Set Identifier) w zakładce Menu > Wireless > SSID oraz wybrać tryb Infrastructure w sekcji Menu > Wireless > Network Mode. Na koniec wybierz konfigurację sieci za pomocą protokołu DHCP (Dynamic Host Configuration Protocol) w menu > zakładki Ustawienia sieci > Tryb sieciowy.
    2. Skonfiguruj parametry protokołu SIP (Session Initiation Protocol), aby umożliwić odpowiednią wymianę komunikatów sygnalizacyjnych z serwerem telefonii IP. W tym kontekście, przejdź do zakładki Menu > Ustawienia SIP i określ nazwę hosta serwera telefonii IP VNF ("dronesVoIP.net") w zakładkach Registrar > Registrar IP oraz Proxy Server > Proxy IP (Adres IP serwera proxy). Ponadto utwórz konto użytkownika, wprowadzając nazwę użytkownika (np. dzwoniący-A) w sekcjach Konto użytkownika > Numer telefonu oraz Konto użytkownika > Nazwa użytkownika.
    3. Utwórz wpis w książce telefonicznej jednego z telefonów IP zawierający informacje o użytkowniku, który ma zostać wywołany. W tym celu wybierz zakładkę Menu > Książka telefoniczna > Dodaj wpis i wprowadź żądane parametry, które pojawią się na wyświetlaczu, w następujący sposób: Nazwa wyświetlana = dzwoniący-B; Informacje o użytkowniku = dzwoniący-B; Adres IP hosta = dronesVoIP.net; Port = 5060. Na koniec wybierz opcję "Proxy" kontra P2P (peer-to-peer).
  5. Rozpocznij rozmowę z drugą stroną. W tym celu należy wybrać rozmówcę, korzystając z opcji Menu > Książka telefoniczna > Wyszukiwanie telefonu IP. Następnie naciśnij przycisk połączenia. Gdy drugi telefon IP zacznie dzwonić, zaakceptuj połączenie przychodzące za pomocą przycisku połączenia.

6. Procedura zbierania wyników eksperymentów

  1. Podłącz zwykły laptop do jednego z bezprzewodowych punktów dostępowych i uruchom narzędzie wiersza poleceń ping na adres IP telefonu podłączonego do drugiego punktu dostępowego przez 180 s. Adres IP można sprawdzić w opcji Menu > Informacje > Adres IP telefonu IP po nawiązaniu połączenia z punktem dostępowym. Zapisz pomiary czasu podróży w obie strony (RTT), przekierowując dane wyjściowe dostarczone przez narzędzie ping do pliku.
  2. Uruchom narzędzie wiersza poleceń tcpdump w jednym z uruchomionych funkcji VNF punktu dostępowego, aby przechwycić ruch wymieniany podczas wywołania IP. Zapisz ten ruch do pliku, włączając flagę zapisu narzędzia wiersza poleceń w czasie wykonywania i określając nazwę pliku.
  3. Wykonaj nowe połączenie telefonii IP. Utrzymuj połączenie przez żądany czas (np. 1 minuta). Następnie zakończ połączenie, naciskając przycisk rozłączania na jednym z telefonów IP.
  4. Zachowaj pliki wygenerowane przez narzędzia tcpdump i ping do dalszego przetwarzania. Zobacz reprezentatywne wyniki.

Wyniki

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Na podstawie danych uzyskanych podczas przeprowadzania eksperymentu, w którym wykonywane jest prawdziwe połączenie VoIP i zgodnie z krokami wskazanymi przez protokół w celu zebrania tych informacji, Rysunek 2 przedstawia funkcję skumulowanego rozkładu opóźnienia od końca do końca mierzonego między dwoma urządzeniami użytkownika końcowego (tj. laptopem i telefonem IP). Ten sprzęt użytkownika reprezentuje dwa urządzenia, które są połączone ze sobą za pośrednictwem funkcji VNF punktów dostępowych wdrożonej usługi sieciowej. Ponad 80% pomiarów opóźnień end-to-end było poniżej 60 ms, a żaden z nich nie był wyższy niż 150 ms, co gwarantuje odpowiednie metryki opóźnień dla wykonania połączenia głosowego.

Rysunek 3 ilustruje wymianę komunikatów sygnalizacyjnych DNS i SIP. Wiadomości te odpowiadają rejestracji jednego z użytkowników na serwerze telefonii IP (tj. użytkownika, którego telefon IP jest podłączony do punktu dostępowego VNF, na którym uruchomione jest narzędzie "tcpdump") i nawiązaniu połączenia głosowego.

Na koniec, Rysunek 4 i Rysunek 5 pokazuje ruch danych przechwycony podczas rozmowy. W szczególności pierwszy z nich reprezentuje stały strumień pakietów głosowych przesyłanych i odbieranych przez jeden z telefonów bezprzewodowych podczas połączenia, podczas gdy drugi ilustruje jitter w kierunku do przodu ze średnią wartością niższą niż 1 ms.

Wyniki, które uzyskano w eksperymencie dla danych dotyczących opóźnień (opóźnienie end-to-end i jitter) spełniają zalecenia określone przez Międzynarodowy Związek Telekomunikacyjny - Sektor Standaryzacji Telekomunikacji (ITU-T)35. W związku z tym połączenie głosowe przebiegało bez zakłóceń i dobrej jakości dźwięku. Eksperyment ten potwierdził praktyczną wykonalność wykorzystania technologii NFV i UAV do wdrożenia funkcjonalnej usługi telefonii IP.

figure-results-1
Rysunek 1: Przegląd usługi sieciowej, przedstawiający VNF, jednostki, w których są one wykonywane, oraz sieci wirtualne potrzebne do świadczenia usługi telefonii IP. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-2
Rysunek 2: Opóźnienie typu end-to-end. Przedstawienie całkowitego opóźnienia oferowanego urządzeniom użytkownika końcowego podłączonym do punktów dostępowych VNF. W tym celu funkcja skumulowanego rozkładu opóźnienia typu end-to-end została obliczona na podstawie zmierzonych próbek RTT uzyskanych za pomocą narzędzia wiersza poleceń "ping". Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-3
Rysunek 3: Komunikaty dotyczące rejestracji użytkownika i sygnalizacji połączeń. Ilustracja ruchu sygnalizacyjnego (DNS i SIP) wymienianego w celu zarejestrowania użytkownika na serwerze telefonii IP oraz utworzenia i zakończenia sesji multimedialnej obsługującej wykonanie połączenia głosowego. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-4
Rysunek 4: Strumień pakietów głosowych. Reprezentacja ruchu głosowego wymienianego podczas połączenia, mierzonego na jednym z punktów dostępowych VNF (skróty: RX = odbiór, RX = transmisja, RTP = protokół transportu w czasie rzeczywistym). Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-5
Rysunek 5: Ewolucja fluktuacji sieci podczas połączenia. Reprezentacja fluktuacji doświadczanej przez przesyłane pakiety głosowe w kierunku przekierowania z jednego telefonu do drugiego. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Dyskusja

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Jednym z najważniejszych aspektów tego eksperymentu jest wykorzystanie technologii wirtualizacji i standardów NFV z platformami UAV. NFV prezentuje nowy paradygmat mający na celu oddzielenie zależności sprzętowej od funkcjonalności sieciowych, umożliwiając w ten sposób dostarczanie tych funkcji poprzez softwaryzację. W związku z tym eksperyment nie jest uzależniony od użycia sprzętu sprzętowego określonego w protokole. Alternatywnie można wybrać różne modele komputerów jednopłytkowych, o ile są one zgodne z wymiarami i zdolnością transportową UAV i obsługują kontenery Linux.

Niezależnie od tej elastyczności w zakresie wyboru sprzętu, cała treść dostarczana w celu odtworzenia eksperymentu jest zorientowana na wykorzystanie technologii open source. W tym kontekście, aspekty konfiguracyjne i narzędzia programowe są uwarunkowane korzystaniem z Linuksa jako systemu operacyjnego.

Z drugiej strony, eksperyment uwzględnia współdziałanie dwóch różnych platform obliczeniowych (tj. platformy chmurowej UAV i podstawowej platformy chmurowej) w celu zapewnienia umiarkowanie złożonej usługi sieciowej. Nie jest to jednak bezwzględnie konieczne, a protokół może być stosowany w celu obsługi scenariuszy, w których zaangażowana jest tylko platforma chmurowa UAV.

Ponadto zaprezentowane rozwiązanie może potencjalnie znaleźć zastosowanie w innych środowiskach, w których mogą być dostępne platformy sprzętowe o ograniczonych zasobach o wymaganej pojemności do uruchamiania kontenerów wirtualizacyjnych (np. środowiska Internetu Rzeczy lub IoT). W każdym razie możliwość zastosowania tego rozwiązania w różnych środowiskach i jego potencjalne adaptacje będą wymagały starannego zbadania każdego przypadku z osobna.

Na koniec należy zauważyć, że przedstawione wyniki zostały uzyskane w środowisku laboratoryjnym i przy urządzeniach UAV uziemionych lub zgodnie z ograniczonym i dobrze zdefiniowanym planem lotu. Inne scenariusze zakładające rozmieszczenie na zewnątrz mogą wprowadzać warunki wpływające na stabilność lotu BSP, a co za tym idzie na wydajność usługi telefonii IP.

Oświadczenia

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Autorzy nie mają nic do ujawnienia.

Podziękowania

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Ta praca była częściowo wspierana przez europejski projekt H2020 5GRANGE (umowa o grant 777137), oraz przez projekt 5GCIty (TEC2016-76795-C6-3-R) finansowany przez hiszpańskie Ministerstwo Gospodarki i Konkurencyjności. Prace Luisa F. Gonzaleza były częściowo wspierane przez europejski projekt 5GinFIRE w ramach programu H2020 (umowa o grant 732497).

Materiały

Lista materiałów użytych w tym artykule
NazwaFirmaNumer katalogowyKomentarze
Drone 2.0 - Elite editionParrotUAV wykorzystany w eksperymencie do transportu RPi, a tym samym zapewnienia mobilności jednostkom obliczeniowym platformy chmurowej UAV.
Bebop 2Parrotwykorzystany w eksperymencie do transportu RPi, a tym samym zapewnienia mobilności jednostkom obliczeniowym platformy chmurowej UAV.
Core Mini-ITX ComputerLogic SuppyComputer, który hostuje węzeł kontrolera OpenStack (wykonywany jako maszyna wirtualna) platformy chmurowej UAV eksperymentu. Ponadto inna jednostka tego sprzętu (wraz z RPis) jest zgodna z zasobami obliczeniowymi platformy chmurowej UAV.
Kontenery Linux (LXC)Canonical Ltd.(Oprogramowanie) Technologia wirtualizacji, która umożliwia dostarczanie funkcji sieci wirtualnej wyszczególnionych w eksperymencie. Kod źródłowy dostępny online: https://linuxcontainers.org
Lithium Battery Pack Expansion Board. Model KY68C-UKKumanZasilanie bateryjne HAT (Hardware Attached on Top) do jednostek obliczeniowych platformy chmurowej UAV (tj. Raspberry Pis). Ponadto wyposażenie to obejmuje obudowę służącą do podłączania jednostek obliczeniowych (tj. Raspberry PI lub RPis) do UAV.
MacBook ProAppleCommodity wykorzystany podczas eksperymentu w celu uzyskania i zebrania wyników zgodnie z opisem w manuskrypcie.
ns-3 Network Simulatornsnam(Oprogramowanie) Symulator sieci symulatora zdarzeń dyskretnych, który dostarcza podstawowy substrat komunikacyjny do stacji emulacyjnej wyjaśnionej w sekcji "Protokół" (bardziej szczegółowo w kroku "2. Sprawdź poprawność funkcjonalności jednostek softwarization za pomocą emulacji"). Kod źródłowy dostępny online: https://www.nsnam.org
Open Source MANO (OSM) - Release Four ETSIOSM - Open source community(Software) Management and Orchestration (MANO) software stack systemu NFV skonfigurowanego w eksperymencie. Kod źródłowy dostępny online: https://osm.etsi.org/wikipub/index.php/OSM_Release_FOUR
OpenStack - Release OcataOpenStack - Społeczność(Oprogramowanie) Oprogramowanie open source używane do konfiguracji zarówno platformy chmurowej UAV, jak i podstawowej chmury w ramach eksperymentu. Kod źródłowy dostępny online: https://docs.openstack.org/ocata/install-guide-ubuntu
PingNarzędzie(oprogramowanie) Narzędzie testowe typu open source, które weryfikuje łączność między dwoma urządzeniami połączonymi siecią komunikacyjną. Ponadto narzędzie to pozwala ocenić wydajność sieci, ponieważ oblicza czas podróży w obie strony (tj. czas potrzebny na wysłanie i odebranie pakietu danych z sieci). Kod źródłowy dostępny online: https://packages.debian.org/es/sid/iputils-ping
Power Edge R430Wysokiej klasy serwer komputerowy Dell, który zapewnia moc obliczeniową w ramach podstawowej platformy chmurowej przedstawionej w eksperymencie.
Power Edge R630Sprzęt firmy Dellużywany do hostowania maszyny wirtualnej (VM) za zadanie wykonania stosu MANO. Ponadto węzeł kontrolera OpenStack jest również wykonywany jako maszyna wirtualna w tym urządzeniu. Należy pamiętać, że korzystanie z tego urządzenia nie jest bezwzględnie konieczne. Operacje wykonywane przez to urządzenie mogą być wykonywane przez sprzęt o niższej wydajności ze względu na niezbyt wysokie specyfikacje zasobów wyżej wymienionych maszyn wirtualnych.
Prestige 2000WZyXELTelefon Voice over IP Wi-FI, kompatybilny ze standardem komunikacji bezprzewodowej IEEE 802.11b. To urządzenie jest wykorzystywane do przeprowadzania połączenia VoIP za pośrednictwem usługi sieciowej hostowanej przez platformę opisaną do wykonania eksperymentu.
Malina PI. Model 3bRaspberry Pi FoundationWybrany model komputera jednopłytkowego (SBC) służącego do dostarczania mocy obliczeniowej do platformy chmurowej UAV eksperymentu.
SIPpOpen Source(Oprogramowanie) Narzędzie testowe typu open source, które generuje ruch protokołu SIP. Narzędzie to pozwala na weryfikację poprawności obsługi ruchu sygnalizacyjnego wymaganego w usłudze telefonii IP, takiej jak ta wykorzystana w eksperymencie. Kod źródłowy dostępny online: http://sipp.sourceforge.net
TcpdumpNarzędzie(Oprogramowanie) Narzędzie typu open source, które umożliwia przechwytywanie i analizę ruchu sieciowego. Kod źródłowy dostępny online: https://www.tcpdump.org
TraficNarzędzie(oprogramowanie) Otwarty harmonogram przepływu souce, który służy do sprawdzania poprawności wydajności usługi sieciowej wdrożonej do przetwarzania ruchu danych generowanego podczas połączenia telefonii IP. Kod źródłowy dostępny online pod adresem: https://github.com/5GinFIRE/trafic
Bezzałogowy statek powietrzny Komercyjny serwer Intel Laptop open source open source Narzędzie Open Source Open Source

Bibliografia

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  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).

Przedruki i uprawnienia

Poproś o pozwolenie na ponowne wykorzystanie tekstu lub ilustracji tego artykułu JoVE

Poproś o pozwolenie

Tagi

Wirtualizacja funkcji sieciowychus uga telefonii IPobrazy VNFinterfejs graficzny OSMkonfiguracja konta VIMchmurowa platforma UAVVoice Over IPop nienie end to end

Powiązane artykuły