Integracja infrastruktur eksperymentalnych 5G z ekosystemem NFV obejmującym wiele lokalizacji

Podsumowanie

Celem opisanego protokołu jest wspieranie elastycznego włączania infrastruktur eksperymentalnych 5G do wielostanowiskowego ekosystemu NFV, poprzez architekturę sieci nakładkowej opartej na VPN. Ponadto protokół określa, w jaki sposób można zweryfikować skuteczność integracji, w tym pionowego wdrożenia usług w wielu lokalizacjach z małymi statkami powietrznymi obsługującymi NFV.

Streszczenie

Wirtualizacja funkcji sieciowych (NFV) została uznana za jeden z kluczowych czynników umożliwiających rozwój sieci komórkowych piątej generacji, czyli 5G. Paradygmat ten pozwala na zmniejszenie zależności od specjalistycznego sprzętu do wdrażania usług telekomunikacyjnych i wertykalnych. W tym celu opiera się na technikach wirtualizacji w celu zmiękczenia funkcji sieciowych, upraszczając ich rozwój oraz skracając czas i koszty wdrożenia. W tym kontekście, Universidad Carlos III de Madrid, Telefónica i IMDEA Networks Institute opracowały ekosystem NFV w ramach 5TONIC, otwartego centrum innowacji sieciowych skoncentrowanego na technologiach 5G, umożliwiającego tworzenie złożonych, zbliżonych do rzeczywistości scenariuszy eksperymentalnych w rozproszonym zestawie infrastruktur NFV, które mogą być udostępniane przez interesariuszy w różnych lokalizacjach geograficznych. W tym artykule przedstawiono protokół, który został zdefiniowany w celu włączenia nowych zdalnych lokalizacji NFV do wielolokacyjnego ekosystemu NFV opartego na 5TONIC, opisując wymagania zarówno dla istniejącej, jak i nowo włączonej infrastruktury, ich łączność poprzez architekturę sieci nakładkowej oraz kroki niezbędne do włączenia nowych lokalizacji. Przykładem protokołu jest włączenie zewnętrznej witryny do ekosystemu 5TONIC NFV. Następnie protokół wyszczególnia kroki weryfikacyjne wymagane do walidacji udanej integracji witryny. Obejmują one wdrożenie wielozakładowej usługi pionowej z wykorzystaniem zdalnej infrastruktury NFV z małymi bezzałogowymi statkami powietrznymi (SUAV). Służy to ukazaniu potencjału protokołu w zakresie umożliwiania rozproszonych scenariuszy eksperymentowania.

Wprowadzenie

Wprowadzenie sieci komórkowych piątej generacji (5G) oznaczało zrewolucjonizowanie branży telekomunikacyjnej od początku dekady, wymagając od operatorów telekomunikacyjnych sprostania znacznie bardziej wymagającym specyfikacjom nowych usług sieciowych i aplikacji opracowanych pod parasolem 5G1^,2. Te nowe specyfikacje obejmują między innymi zwiększenie szybkości transmisji danych, poprawę opóźnień transmisji bezprzewodowej i redukcję kosztów operacyjnych. Wśród technologii, które stanowią podstawę ulepszeń dla tej nowej generacji, Network Functions Virtualization³ (NFV) stała się jednym z jej kluczowych elementów. NFV zapewnia możliwość softwaryzacji funkcji sieciowych, tradycyjnie opartych na specjalistycznym sprzęcie, przy użyciu sprzętu fizycznego ogólnego przeznaczenia, takiego jak komputery serwerowe w centrum danych. Dzięki temu nowemu paradygmatowi operatorzy telekomunikacyjni i branże wertykalne mogą wdrażać funkcje i usługi sieciowe jako zestaw komponentów oprogramowania oraz oszczędzać koszty zarówno wdrażania, jak i utrzymania usług, a także ułatwiać znacznie większą elastyczność infrastruktury sieciowej. Takie podejście łagodzi lub eliminuje konieczność używania dedykowanych (i zwykle bardziej złożonych i mniej nadających się do ponownego użycia) urządzeń do większości funkcji specyficznych dla sieci i pionu, a także wspiera znacznie wyższy i gęstszy stopień automatyzacji operacyjnej, zmniejszając w ten sposób koszty wdrożenia i konserwacji.

Biorąc pod uwagę wszystkie korzyści, jakie może zapewnić środowisko NFV, naturalne jest, że duża liczba istotnych interesariuszy z sektora telekomunikacyjnego coraz częściej angażuje się w testowanie nowych pomysłów na usługi w środowiskach NFV. W tym kontekście, Telefónica i IMDEA Networks Institute stworzyły 5TONIC⁴, otwarte laboratorium badawcze i innowacyjne skoncentrowane na technologiach 5G. Laboratorium to, z siedzibą w Madrycie (Hiszpania), dysponuje szeroką gamą technologii dostępnych dla badaczy i partnerów w celu przyspieszenia rozwoju i walidacji usług 5G. W szczególności laboratorium to posiada eksperymentalną platformę NFV, na której programiści mogą wdrażać i testować swoje nowe aplikacje i usługi oparte na NFV w ekosystemie NFV zgodnym z ETSI⁵. W ten sposób wnioski eksperymentalne dotyczące wyborów projektowych i propozycji technologii można uzyskać w realistycznym, znacznie bardziej elastycznym środowisku niż sieci produkcyjne. Platforma ta została zaprojektowana w celu wspierania działań eksperymentalnych w wielu zewnętrznych witrynach, które mogą być elastycznie połączone z 5TONIC za pomocą dobrze zdefiniowanego protokołu.

Rozwiązanie techniczne przyjęte dla ekosystemu NFV 5TONIC uwzględnia wykorzystanie pojedynczego orkiestratora NFV, zaimplementowanego przy użyciu hostowanego przez ETSI oprogramowania Open Source MANO (OSM)⁶. Jest to element odpowiedzialny za zarządzanie i koordynację cyklu życia usług sieciowych (NS). Usługi te mogą być zbudowane jako kompozycja zwirtualizowanej sieci/funkcji pionowych (VNF), które mogą być wdrożone w dowolnej lokalizacji zintegrowanej na platformie NFV. Projekt ekosystemu 5TONIC NFV został wykonany w kontekście projektu H2020 5GINFIRE ^7,8, w ramach którego platforma została wykorzystana do wsparcia realizacji ponad 25 eksperymentów, wybranych w drodze konkurencyjnego procesu otwartego zaproszenia, w ośmiu specyficznych dla pionu infrastrukturach eksperymentalnych zlokalizowanych w Europie i jednej w Brazylii, przy czym ta ostatnia jest połączona łączem transoceanicznym. Ponadto platforma została wykorzystana do zbudowania rozproszonego stanowiska testowego NFV na skalę krajową w Hiszpanii, wspierając działania eksperymentalne w ramach hiszpańskiego projektu 5GCity^9,10. Niedawno do platformy została włączona dodatkowa brazylijska strona internetowa, która wspiera wspólne działania demonstracyjne w kontekście współpracy w zakresie badań naukowych i innowacji ustanowionej między Brazylią a Europą (tj. projekt 5GRANGE^11,12). Wreszcie, co nie mniej ważne, infrastruktura została wykorzystana do wsparcia eksperymentów stron trzecich w ramach projektu 5G-VINNI^13,14. Rozkład geograficzny platformy NFV można zobaczyć w Rysunek 1.

Zainteresowane organizacje posiadające własną infrastrukturę NFV mogą elastycznie łączyć się z ekosystemem NFV 5TONIC, pod warunkiem zatwierdzenia przez Radę Sterującą 5TONIC, stać się dostawcami stanowisk testowych w ramach rozproszonego ekosystemu i brać udział we wspólnych eksperymentach i działaniach demonstracyjnych. W tym celu muszą być wyposażone w VIM (Virtual Infrastructure Manager) zgodny ze stosem oprogramowania OSM. Koordynator 5TONIC NFV jest w stanie współdziałać z VIM-ami w lokalizacjach zaangażowanych w dane wdrożenie usługi, koordynując alokację i konfigurację zasobów obliczeniowych, pamięci masowej i sieciowych potrzebnych do tworzenia instancji i wzajemnych połączeń VNF, które składają się na usługę sieciową, oraz kontrolując jej cykl życia, od momentu jej wdrożenia do ostatecznego wycofania z eksploatacji.

W celu zarządzania wymianą kontroli i ruchem danych we wszystkich połączonych ze sobą lokalizacjach, ekosystem 5TONIC NFV wykorzystuje architekturę sieci nakładkowej opartą na wirtualnych sieciach prywatnych (VPN). Takie podejście zapewnia bezpieczny dostęp oparty na PKI do zewnętrznych lokalizacji, które są zintegrowane z ekosystemem 5TONIC, umożliwiając wymianę informacji sterujących NFV między stosem oprogramowania OSM a różnymi VIM-ami rozmieszczonymi na stanowiskach testowych, a także wymianę informacji wymaganych do zarządzania i konfiguracji wszystkich VNF. Co więcej, ta sieć nakładkowa obsługuje rozproszenie ruchu danych między VNF, które są rozmieszczone w różnych lokalizacjach.

W tym kontekście, ten artykuł szczegółowo opisuje protokół zaprojektowany w celu włączenia zewnętrznej strony do ekosystemu NFV. Protokół zakłada, że ekosystem jest zarządzany przez pojedynczy orkiestrator NFV, zainstalowany w centralnej lokalizacji, a lokalizacje zewnętrzne są wyposażone w rozwiązanie VIM zgodne ze stosem oprogramowania orkiestratora. Proponowany protokół pozwala na zwiększenie portfela zasobów ekosystemu eksperymentalnego, z elastycznym włączeniem lokalizacji NFV i infrastruktur specyficznych dla pionu. Umożliwia to stworzenie rozproszonej platformy MANO zdolnej do testowania i walidacji nowatorskich usług sieciowych i pionowych w wielu lokalizacjach, pod kontrolą jednego koordynatora NFV. W celu zobrazowania wewnętrznego działania protokołu, proces ten zostanie zilustrowany poprzez dodanie zewnętrznej strony NFV do obecnego ekosystemu 5TONIC NFV, opisując potrzebne komponenty w zewnętrznej witrynie i 5TONIC, a także wszystkie kroki, które należy podjąć podczas procesu integracji. Rysunek 2 przedstawia ogólny zarys celu integracji, z nowym stanowiskiem testowym opartym na NFV dołączonym do platformy 5TONIC, z której można wdrażać usługi sieciowe, za pomocą połączeń VPN między centralną lokalizacją a resztą infrastruktur zewnętrznych.

Ponadto, aby pokazać skuteczność protokołu, pokazane zostanie wdrożenie prostej usługi pionowej, wykorzystującej ekosystem 5TONIC i zewnętrzną stronę z małymi bezzałogowymi statkami powietrznymi (SUAV) zdolnymi do obsługi NFV. Projekt usługi pionowej został zainspirowany eksperymentem przedstawionym w Vidal et al.⁹, który został uproszczony na potrzeby ilustracji tego artykułu. Rysunek 3 przedstawia usługę, której celem jest wspomaganie działań związanych z inteligentnym rolnictwem na odległym obszarze. Usługa dotyczy dostawcy usług inteligentnego rolnictwa, który wykorzystuje SUAV do zbierania i rozpowszechniania danych generowanych przez czujniki meteorologiczne rozproszone na polu uprawnym. Dla uproszczenia, eksperyment przedstawiony w artykule dotyczy pojedynczego SUAV i czujnika, zdolnego do dostarczania pomiarów temperatury, wilgotności i ciśnienia. W eksperymencie zewnętrzna lokacja NFV hostuje punkt dostępu Wi-Fi, który jest wdrażany jako VNF za pośrednictwem SUAV. Ten VNF oferuje łączność z czujnikiem w celu uzyskania dostępu do sieci, przekazując wykryte dane do funkcji bramy. Ten ostatni jest wdrażany jako VNF na sprzęcie naziemnym (komputer mini-ITX). Dystrybucja danych z czujnika do funkcji bramy jest zgodna z podejściem publikowania/subskrybowania opartym na protokole MQTT (Message Queuing Telemetry Transport)¹⁵. Funkcja bramy przetwarza, a następnie rozpowszechnia dane w kierunku serwera Internetu rzeczy (IoT), który jest udostępniany jako VNF w centralnej lokalizacji ekosystemu NFV, w oparciu o platformę open source Mainflux¹⁶. Na koniec scenariusz zakłada obszar zdalny, w którym łączność z Internetem jest zapewniana przez sieć dostępową inną niż 3GPP. W związku z tym usługa obejmuje dwie dodatkowe funkcje VNF: 1) router dostępowy VNF, który implementuje stos protokołu płaszczyzny użytkownika urządzenia użytkownika 3GPP podłączonego do sieci dostępowej innej niż 3GPP¹⁷; oraz 2) podstawowe wdrożenie sieci szkieletowej 5G, obsługującej przekazywanie informacji między routerem dostępowym a VNF serwera IoT. W tym celu rdzeń 5G VNF zapewnia uproszczoną implementację płaszczyzny użytkownika funkcji współpracującej innej niż 3GPP i funkcji płaszczyzny użytkownika, zgodnie z definicją 3GPP¹⁷.

Na koniec, Rysunek 4 przedstawia najważniejsze procesy zaangażowane podczas opracowywania protokołu, podkreślając ich logiczne powiązania i podmioty odpowiedzialne za ich realizację.

Protokół

1. Zapewnienie centralnego miejsca ekosystemu NFV (wymagania wstępne eksperymentu)

1. Przydziel przestrzeń adresów IP, która ma być używana przez lokację centralną. Na potrzeby tego protokołu zostanie użyta prywatna przestrzeń adresowa 10.4.0.0/16.
2. Zainstaluj stos oprogramowania do zarządzania i orkiestracji (MANO) w lokacji centralnej. W szczególności eksperyment przeprowadzony w ramach tego protokołu wykorzystuje Open Source MANO (OSM) Release SEVEN¹⁸, który wymaga następujących zasobów: Ubuntu 18.04 jako system operacyjny, 2 jednostki centralne (CPU), 8 GB pamięci o dostępie swobodnym (RAM), 40 GB dysku twardego i co najmniej jeden interfejs sieciowy z dostępem do Internetu. W celu instalacji postępuj zgodnie z instrukcjami dostępnymi na stronie OSM Release SEVEN documentation¹⁸.
3. Skonfiguruj Virtual Infrastructure Manager (VIM) kompatybilny z OSM w lokacji centralnej. W szczególności eksperyment wykorzystuje wersję OpenStack Ocata²⁰, działającą na maszynie wirtualnej (VM) z Ubuntu 16.04 , 4 procesorami, 16 GB pamięci RAM i 200 GB dysku twardego. Infrastruktura NFV (NFVI) obsługiwana przez ten VIM składa się z trzech komputerów serwerowych, każdy z systemem Ubuntu 16.04, 8 procesorami, 32 GB pamięci RAM i 2 TB pamięci masowej. Aby przeprowadzić instalację, postępuj zgodnie z dokumentacją wydania Ocata²¹.
   1. Wdróż sieć wirtualną na platformie chmurowej OpenStack, używając zakresu adresów IP z przestrzeni adresowej przydzielonej w kroku 1.1. Sieć ta, zwana dalej siecią zarządzania, będzie używana do obsługi wymiany informacji o orkiestracji NFV między OSM a wirtualnymi funkcjami sieci (VNF) utworzonymi w lokacji centralnej.
   2. Skonfiguruj sieć wirtualną (odtąd nazywaną siecią danych) do obsługi komunikacji danych między funkcjami VNF lokacji centralnej a innymi funkcjami VNF wykonywanymi w lokacjach zewnętrznych. W tym celu należy użyć zakresu adresów IP z przestrzeni adresowej kroku 1.1.
      UWAGA: Implementacja sieci wymienionych w krokach 1.3.1 i 1.3.2 została wykonana przy użyciu sieci dostawców OpenStack. Sieci dostawców muszą być połączone z fizyczną infrastrukturą sieciową ośrodka centralnego, aby zagwarantować prawidłowe działanie.
4. Podłącz zarówno wirtualne sieci prywatne (tj. sieci zarządzania i sieci danych), jak i maszyny VIM i OSM, do sprzętu zapewniającego funkcje routingu brzegowego. Router ten będzie służył jako punkt wejścia do centralnej lokalizacji ekosystemu NFV.
5. Udostępnij publiczne repozytorium eksperymentów, aby zapewnić całą zawartość potrzebną do przeprowadzenia eksperymentu. W szczególności protokół ten korzysta z publicznego repozytorium at²².

2. Konfiguracja usługi wirtualnej sieci prywatnej

1. Przydziel przestrzeń adresów IP w celu obsługi odpowiedniego działania ekosystemu obejmującego wiele lokalizacji, tak aby można było efektywnie ustanowić komunikację sieciową między wieloma lokacjami.
   UWAGA: Umożliwienie efektywnej komunikacji sieciowej między wieloma lokacjami wymaga starannego zaprojektowania przestrzeni adresów IP, która ma być używana przez ekosystem NFV, a także przez witryny zewnętrzne, które muszą się z nim łączyć. W szczególności przestrzeń adresowa przydzielona do komunikacji między lokacjami nie powinna kolidować z przestrzenią adresową już używaną w każdej innej lokacji do innych celów.
   1. Przydziel przestrzeń adresów IP, która ma być używana przez witryny zewnętrzne. Adresy w tym bloku zostaną przypisane do jednostek NFV (np. VIM-ów) i VNF lokacji zewnętrznej. Aby zilustrować ten protokół, zostanie użyta prywatna przestrzeń adresowa 10.154.0.0/16.
   2. Przydziel przestrzeń adresów IP do łączy wirtualnych między lokacjami zewnętrznymi a ekosystemem NFV. Te łącza wirtualne będą obsługiwane przez usługę VPN. Aby zilustrować ten protokół, zakres adresów 10.154.254.0/24 zostanie wykorzystany dla tych łączy wirtualnych.
2. Skonfiguruj sprzęt do świadczenia usługi wirtualnej sieci prywatnej (VPN) (tj. serwera VPN). W szczególności w eksperymencie wykorzystano komputer serwerowy z systemem Ubuntu 16.04 (64-bitowy obraz wariantu), sześcioma niezależnymi procesorami, 16 GB pamięci RAM, dyskiem o pojemności 1 TB i dwoma interfejsami sieciowymi.
   1. Skonfiguruj jeden z interfejsów sieciowych serwera sieci VPN, aby umożliwić odbieranie żądań połączeń z witryn zewnętrznych za pośrednictwem Internetu. W tym celu konieczne jest skorzystanie z interfejsu serwera skonfigurowanego z publicznym adresem IP.
   2. Skonfiguruj łącze między serwerem sieci VPN a routerem brzegowym lokacji centralnej. W eksperymencie temu linkowi przydzielono zakres adresów 10.4.255.0/24. Skonfiguruj odpowiednie trasy sieciowe na serwerze sieci VPN, tak aby ekosystem NFV był dostępny z lokacji zewnętrznych połączonych z usługą sieci VPN.
3. Zainstaluj na serwerze VPN oprogramowanie typu open source dostarczone przez projekt OpenVPN²³. W szczególności ten eksperyment wykorzystuje OpenVPN w wersji 2.3.10, a jego wdrożenie zostało wykonane za pomocą skryptu bash "openvpn-install.sh", dostępnego pod adresem http://github.com/Nyr/openvpn-install (inne opcje instalacji są opisane w dokumentacji OpenVPN²⁴). Skrypt bash przedstawia alternatywne parametry, które będą skutkowały konfiguracją usługi VPN.
   1. Wybierz adres IP, pod którym chcesz nasłuchiwać żądań połączenia VPN (tj. publiczny adres IP).
   2. Zdecyduj, który protokół (UDP lub TCP) powinien być używany do kierowania komunikacją przez VPN. W takim przypadku eksperyment wykorzystuje protokół UDP, który jest zalecanym protokołem.
   3. Określ port, który będzie zawierał duplikat (wraz z publicznym adresem IP), który będzie używany do odbierania żądań połączenia z usługą. Domyślnie przypisana wartość to 1194.
   4. Wybierz jeden z serwerów DNS z listy wyświetlanej przez asystenta, który będzie obsługiwał żądania rozpoznawania nazw wykonywane przez klientów usługi sieci VPN.
   5. Naciśnij dowolny, aby włączyć automatyczne inicjowanie procesu instalacji usługi VPN.
4. Edytuj plik konfiguracyjny "server.conf", który znajduje się w katalogu "/etc/openvpn/server/" i dołącz dyrektywę "klient-klient" mającą na celu rozszerzenie podstawowej konfiguracji dostarczonej w kroku 2.3. W ten sposób różni klienci połączeni z usługą VPN będą mogli się ze sobą łączyć.
5. Włącz konfigurację indywidualnego klienta w konfiguracji sieci VPN, aby móc niezależnie zarządzać przypisaniami routingu dla każdego klienta.
   1. Dodaj dyrektywę "client-config-dir ccd", edytując ten sam plik konfiguracyjny, co w kroku 2.4.
   2. Utwórz katalog "ccd" za pomocą polecenia "mkdir /etc/openvpn/ccd/". Katalog ten będzie służył w następnej sekcji protokołu do umieszczania plików zawierających dyrektywy routingu skojarzone z klientami, którzy mają być zintegrowani z platformą.
6. Skonfiguruj reguły zapory, które są potrzebne, aby zezwolić na połączenia z usługą, jednocześnie chroniąc serwer VPN przed złośliwym atakiem. W tym celu eksperyment ten wykorzystuje iptables²⁵, które jest narzędziem wiersza poleceń opracowanym do konfiguracji zapory jądra Linuksa.
   1. Najpierw zablokuj ruch przychodzący do serwera VPN za pomocą polecenia "iptables -P INPUT DROP".
   2. Zezwól na odbiór żądań połączeń VPN za pomocą poleceń "iptables -A INPUT -i -m state --state NEW -p udp --dport 1194 -j ACCEPT" ( to nazwa interfejsu serwera VPN z publicznym adresem IP) i "iptables -A INPUT -i tun+ -j ACCEPT".
   3. Zezwalaj na przekazywanie ruchu między interfejsami serwera VPN (tj. interfejsem publicznym i interfejsem wirtualnym utworzonym przez usługę VPN o nazwie tun0), aby umożliwić serwerowi VPN przetworzenie żądania połączenia z usługą. W tym celu wykonaj polecenie "iptables -A FORWARD -i tun+ -o -m state --state RELATED,ESTABLISHED -j ACCEPT && iptables -A FORWARD -i -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT".
   4. Umożliwia serwerowi VPN zapewnienie możliwości translacji adresów sieciowych (NAT) w celu zapewnienia dostępu do Internetu do lokacji centralnej, wykonując: "iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -o -j MASQUERADE & & iptables -A OUTPUT -o tun+ -j ACCEPT".

3. Integracja zewnętrznej strony NFV

1. Uzyskaj odpowiedni zakres adresów IP, aby zintegrować witrynę z ekosystemem NFV. Ten zakres adresów zostanie dostarczony przez centrum operacji sieciowych ekosystemu NFV. Zgodnie z krokiem 2.1.1 tego protokołu eksperyment użyje zakresu adresów IP dla witryny zewnętrznej w obrębie 10.154.0.0/16.
2. Utwórz i podaj poświadczenia zabezpieczeń, aby nawiązać połączenie z ekosystemem NFV.
   1. Wygeneruj poświadczenie VPN, które umożliwi nowej infrastrukturze nawiązanie bezpiecznego połączenia z serwerem VPN. W tym celu wykonaj polecenie "bash openvpn-install.sh" na serwerze VPN, wybierz opcję "1) Dodaj nowego klienta" z listy podpowiedzi i podaj nazwę, która ma być powiązana z tym poświadczeniem, np. uc3m_infrastructure. Ten krok spowoduje wygenerowanie pliku z danymi uwierzytelniającymi VPN (o nazwie "uc3m_infrastructure.ovpn" w przykładzie).
   2. Utwórz plik tekstowy w katalogu "/etc/openvpn/ccd/" serwera VPN, zawierający dyrektywy routingu (określone w dokumentacji OpenVPN²⁴), które muszą być wypychane przez serwer VPN za każdym razem, gdy nawiązywane jest połączenie z usługą VPN przy użyciu poświadczeń VPN.
      UWAGA: Nazwa pliku tekstowego musi być zgodna z nazwą określoną podczas tworzenia poświadczeń VPN (np. uc3m_infrastructure), aby zapewnić niestandardową konfigurację dla każdego klienta VPN.
   3. Przekaż plik poświadczeń sieci VPN personelowi technicznemu lokacji zewnętrznej. Należy to zrobić za pośrednictwem bezpiecznego i niezawodnego kanału. W tym eksperymencie używany jest ręczny proces szyfrowania. Aby zaszyfrować dane uwierzytelniające VPN, wykonaj polecenie "7za a -tzip '-p' -mem=AES256 ", ustawiając jako żądany klucz szyfrowania, jako wybraną nazwę zaszyfrowanego pliku i jako nazwę pliku uwierzytelniającego VPN (np. uc3m_infrastructure.ovpn).
   4. Przekaż zaszyfrowane dane uwierzytelniające personelowi technicznemu nowej witryny wraz z kluczem umożliwiającym procedury odszyfrowywania za pośrednictwem bezpiecznego kanału komunikacyjnego.
      UWAGA: W tym eksperymencie zaszyfrowane dane uwierzytelniające zostały dostarczone przez elektroniczną wiadomość e-mail, podczas gdy klucz deszyfrujący został wysłany oddzielnym kanałem, przy użyciu usługi krótkich wiadomości tekstowych (SMS), z umową offline dotyczącą numeru telefonu.
3. Skonfiguruj środowisko w nowej lokacji, tak aby ustanowić połączenie z ekosystemem NFV i umożliwić dołączenie zdalnego NFVI do stosu OSM lokacji centralnej.
   1. Zainstaluj oprogramowanie VPN dostarczone przez OpenVPN²⁴ na komputerze, aby umożliwić wirtualne połączenie między witryną zewnętrzną a witryną centralną ekosystemu NFV. Komputer z oprogramowaniem OpenVPN będzie służył jako klient VPN lub punkt końcowy VPN w lokalizacji zewnętrznej. Wirtualne łącze będzie realizowane za pomocą chronionego tunelu VPN pomiędzy punktem końcowym VPN a serwerem VPN. W eksperymencie punkt końcowy sieci VPN działa na serwerze z systemem Ubuntu 18.04, 8 procesorami CPU, 8 GB pamięci RAM, dyskiem pamięci masowej 128 GB i interfejsami 3 GbE (jeden do łączenia się z usługą VPN przez Internet).
   2. Aktywuj przekazywanie adresów IP w punkcie końcowym sieci VPN, aby obsługiwać możliwości routingu sieciowego. W tym celu dołącz wiersz "net.ipv4.ip_forward=1" do pliku konfiguracyjnego systemu znajdującego się w ścieżce "/etc/sysctl.conf" i załaduj zaktualizowaną konfigurację za pomocą polecenia "sudo sysctl -p".
   3. Odszyfruj plik poświadczeń VPN za pomocą informacji otrzymanych w kroku 3.2.4, używając polecenia "7za e ", gdzie to nazwa pliku zaszyfrowanego poświadczenia VPN. Określ klucz odszyfrowywania po wyświetleniu monitu przez polecenie.
   4. Uruchom oprogramowanie OpenVPN z odszyfrowanym plikiem uwierzytelniającym za pomocą polecenia "sudo openvpn --config " ( to nazwa pliku poświadczeń VPN). Dzięki temu punkt końcowy VPN uwierzytelni się na serwerze VPN i automatycznie otrzyma odpowiednie parametry konfiguracyjne VPN oraz trasy sieciowe. W ten sposób punkt końcowy VPN będzie zachowywał się jak router brzegowy z wirtualnym łączem do centralnej lokacji ekosystemu NFV.
   5. Sprawdź poprawność działania punktu końcowego sieci VPN, używając polecenia ping w celu sprawdzenia dostępności łączności z jednym z węzłów lokacji centralnej (np. sprzętem stosu OSM).
   6. W nowej lokacji wybierz VIM zgodny z OSM, aby zezwolić na operacje z platformą MANO. W tym eksperymencie używana jest wersja OpenStack Ocata.
      UWAGA: OSM Release SEVEN obsługuje następujące menedżery infrastruktury wirtualnej: OpenStack, OpenVIM²⁶, VMware's vCloud Director²⁷, Amazon Web Service²⁸, Microsoft Azure²⁹ i Eclipse fog05³⁰ (szczegółowe informacje na temat konfiguracji można znaleźć w dokumentacji OSM¹⁸).
   7. Zainstaluj wersję OpenStack Ocata²⁰ (zobacz szczegółowe procedury w dokumentacji wydania²¹).
   8. Wdróż infrastrukturę NFV w lokacji zewnętrznej i dołącz ją do kontrolera VIM. W szczególności w tym eksperymencie wykorzystano infrastrukturę NFV składającą się z trzech komputerów jednopłytkowych (SBC), z których każdy ma pojemność obliczeniową 1 GB pamięci RAM, 4 procesory i dysk o pojemności 32 GB; oraz pojedynczy komputer mini-ITX z 8 procesorami, 8 GB pamięci RAM i 128 GB do przechowywania.
      UWAGA: Zewnętrzna ośrodek, którego przykładem jest ten protokół, opiera się na infrastrukturze NFV małych bezzałogowych statków powietrznych (SUAV) zdolnych do pracy z NFV. Szczegółowe informacje dotyczące takiej infrastruktury znajdują się w Nogales et al³¹. Kroki od 3.3.6 do 3.3.8 są opcjonalne, ponieważ infrastruktura NFV może już istnieć w lokalizacji zewnętrznej.
   9. Utwórz projekt OpenStack, aby określić zestaw zasobów obliczeniowych witryny zewnętrznej, która zostanie zintegrowana z ekosystemem NFV. Aby to zrobić, uzyskaj dostęp do graficznego interfejsu użytkownika (GUI) dostarczonego przez OpenStack, zaloguj się do systemu za pomocą danych uwierzytelniających administratora, kliknij przycisk + Utwórz projekt w zakładce Tożsamość -> Projekty i utwórz projekt, wypełniając wyświetlony formularz o wymagane informacje.
   10. Utwórz prawidłowego użytkownika, który będzie zarządzał projektem utworzonym w poprzednim kroku. W tym celu należy wejść w zakładkę Tożsamość -> Użytkownicy z tym samym loginem, co w poprzednim kroku, kliknąć + Utwórz użytkownika i wypełnić wymagane pola wyświetlonego formularza (nazwa użytkownika i hasło), wybierając nowo utworzony projekt jako projekt podstawowy i wybierając rolę administratora.
   11. Zmodyfikuj reguły zabezpieczeń, aby zezwolić na uprawnienia do komunikacji VNF w nowej lokacji (w szczególności włącz ruch SSH i ICMP). W tym celu uzyskaj dostęp do graficznego interfejsu użytkownika OpenStack z danymi uwierzytelniającymi użytkownika utworzonego w poprzednim kroku, postępuj zgodnie z sekwencją: Project -> Network -> Security Groups -> + Dodaj regułę i wybierz opcję SSH z listy rozwijanej Reguła. Powtórz proces, ale wybierz opcję Wszystkie ICMP znajdującą się w menu rozwijanym.
   12. Pobierz obrazy testowej usługi oferowanej przez społeczność OSM, usługi sieciowej Ping Pong ("Fedora-x86_64-20-20131211.1-sda-ping" i "Fedora-x86_64-20-20131211.1-sda-pong") z publicznego repozytorium eksperymentów i prześlij je do VIM zewnętrznego serwisu. W tym celu postępuj zgodnie z sekwencją Project -> Compute -> Images -> + Create Image i utwórz obrazy za pomocą wyświetlonego formularza i wybierając każdy z obrazów.
   13. Przypisz dwa zakresy adresów IP w przestrzeni adresowej lokacji zewnętrznej (przydzielone w kroku 3.1). Zakresy te będą wykorzystywane odpowiednio do wspomagania zarządzania VNF w lokalizacji zewnętrznej oraz do umożliwienia komunikacji danych między lokalizacjami VNF.
   14. Utwórz sieć dostawcy (dostawca kontrolny) za pomocą kontrolera VIM. Sieć ta będzie obsługiwać komunikację NFV między stosem OSM w lokalizacji centralnej a funkcjami VNF wdrożonymi w nowej lokalizacji do celów zarządzania. Ten typ komunikacji umożliwi również stosowi OSM konfigurowanie funkcji VNF po ich wdrożeniu. Aby utworzyć sieć dostawcy w OpenStack, postępuj zgodnie z sekwencją Admin -> System -> Networks -> + Create Network i wypełnij szczegóły nowej sieci, używając wybranego zakresu adresów IP w poprzednim kroku.
   15. Utwórz sieć drugiego dostawcy (dostawcę danych) za pomocą kontrolera VIM. Sieć ta będzie obsługiwać transmisję danych między VNF obiektu a innymi VNF ekosystemu NFV. Aby utworzyć tę sieć dostawcy w OpenStack, postępuj zgodnie z sekwencją Admin -> System -> Networks -> + Create Network i wypełnij szczegóły nowej sieci, używając przypisanego zakresu adresów.
       UWAGA: Instrukcje dotyczące tworzenia sieci wirtualnych różnią się w zależności od oprogramowania VIM. Aby uzyskać szczegółowe informacje, zapoznaj się z odpowiednią dokumentacją oprogramowania.
   16. Należy udostępnić informacje związane z VIM (w szczególności nazwę użytkownika/hasło oraz projekt utworzony w krokach 3.3.9 i 3.3.10) personelowi technicznemu ośrodka centralnego, aby umożliwić dołączenie VIM do stosu oprogramowania OSM.
4. Dołącz zewnętrzną infrastrukturę NFV do stosu oprogramowania OSM w ośrodku centralnym, korzystając z informacji uzyskanych w kroku 3.3.16.
   1. Sprawdź łączność między stosem OSM lokacji centralnej a VIM nowej lokacji za pomocą narzędzia ping.
   2. Jeśli poprzedni test łączności zakończy się pomyślnie, podłącz zewnętrzny kontroler VIM do stosu OSM lokacji centralnej. Aby to zrobić, użyj następującego polecenia na maszynie OSM: "osm vim-create --name --user --password --auth_url --tenant --account_type ". W tym poleceniu: to nazwa wybrana do identyfikacji VIM w stosie OSM, to nazwa użytkownika upoważnionego do obsługi zasobów witryny zewnętrznej (patrz krok 3.3.10), to hasło wskazanego użytkownika, to link do API udostępnionego przez VIM w celu umożliwienia żądań ze stosu OSM, to nazwa projektu zdefiniowana w kroku 3.3.9, a to używane oprogramowanie VIM (w tym eksperymencie OpenStack).
5. Sprawdź prawidłowe dołączenie nowego VIM do stosu OSM ekosystemu NFV.
   1. Wykonaj polecenie "ro_id=$(docker ps | grep osm_ro | cut -d ' ' -f 1)", aby zidentyfikować identyfikator kontenera implementującego moduł Resource Orchestrator (RO) w systemie OSM. Moduł ten jest odpowiedzialny za interakcję z VIM-ami w celu koordynowania i przydzielania potrzebnych zasobów przy wdrażaniu kolejnych usług sieciowych.
   2. Uzyskaj dostęp do kontenera RO za pomocą polecenia "docker exec -it $ro_id bash". To polecenie wykorzystuje identyfikator uzyskany podczas wykonywania poprzedniego kroku.
   3. Sprawdź, czy nowy VIM znajduje się na liście dostępnych centrów danych, używając polecenia "openmano datacenter-list". Nowa lokacja powinna pojawić się na liście pod taką samą nazwą, jak poprzednio wprowadzona w kroku 3.4.2 z parametrem
   4. Wyświetla listę obrazów, które zostały przesłane do serwera VIM witryny zewnętrznej, używając polecenia "openmano vim-image-list --datacenter ". Parametr wskazuje nazwę wybraną do identyfikacji VIM w stosie OSM. Jeśli wykonanie tego polecenia zakończy się pomyślnie, oznacza to, że połączenie z zewnętrznym kontrolerem VIM zostało pomyślnie nawiązane. Sprawdź, czy obrazy ping-ponga znajdują się na liście.
   5. Wyświetl listę sieci dostępnych w nowej lokacji za pomocą polecenia "openmano vim-net-list --datacenter ". Sprawdź, czy dostawca kontroli i dostawca danych są obecne.
6. Przeprowadź wstępną walidację poprawności integracji nowej strony, korzystając z próbnej usługi oferowanej przez społeczność OSM (cała zawartość w tym zakresie znajduje się w repozytorium eksperymentów). W tym celu polecenia zawarte w poniższych krokach zostaną wykonane w sprzęcie hostującym stos OSM.
   1. Dołącz deskryptory VNF (VNFD) do stosu OSM, uruchamiając polecenie "osm vnfd-create " dla każdej z funkcji VNF tworzących usługę próbną ( odpowiada nazwie pliku pakietu VNFD).
   2. Dołącz deskryptor NS (NSD) usługi próbnej za pomocą polecenia "osm nsd-create ", gdzie wskazuje nazwę pliku pakietu NSD (w tym eksperymencie ping_pong_ns.tar.gz)".
   3. Uruchom tworzenie instancji usługi sieciowej Ping Pong Network Service (NS) na lokacjach zewnętrznych i centralnych, używając polecenia "osm ns-create --ns_name --nsd_name ping_pong_ns --vim_account --config '{vnf: [{member-vnf-index: '2', vim_account: }]}'". Parametr identyfikuje VIM lokacji zewnętrznej w stosie OSM. Opcja "--config" wskazuje, że wszystkie funkcje VNF tworzące usługę muszą być wdrożone w lokacji zewnętrznej obsługiwanej przez ten kontroler VIM, z wyjątkiem funkcji VNF oznaczonej indeksem 2 w NS, która zostanie wdrożona w lokacji centralnej (VIM lokacji centralnej jest określony w parametrze ).
   4. Sprawdź, czy NS został wdrożony i jego stan za pomocą polecenia "osm ns-list". Jeśli wystąpienie zakończy się pomyślnie, stan zmieni się na "GOTOWY".
   5. Sprawdź adres IP każdego z dwóch VNF za pomocą "osm vnf-list" (niezbędne do późniejszego zalogowania się do maszyn).
   6. Połącz się z każdym VNF przez SSH, używając polecenia "ssh fedora@" ( reprezentuje adres IP VNF, z którym chcesz się połączyć, uzyskany w poprzednim kroku). Wprowadź hasło "fedora", gdy zostaniesz o to poproszony przez SSH. Po zalogowaniu się do obu komputerów sprawdź ich interfejsy za pomocą polecenia "ip address show" i uzyskaj adresy IP na ich interfejsach podłączonych do sieci dostawcy danych (interfejs eth1 w obu VNF). Z jednej z funkcji VNF wykonaj polecenie ping do drugiej funkcji VNF, używając zdalnego adresu IP w sieci dostawcy danych. Jeśli istnieje łączność, wstępny test walidacyjny zostanie uznany za zakończony sukcesem.

4. Walidacja wielostanowiskowej platformy NFV z realistyczną obsługą pionową

1. Pobierz obrazy VNF z publicznego repozytorium i prześlij je do VIM odpowiedniej witryny (patrz Rysunek 3), postępując zgodnie z procedurą opisaną w kroku 3.3.12. W szczególności lokacja zewnętrzna będzie hostować punkt dostępu VNF, router VNF, bramę MQTT Gateway VNF i router dostępowy VNF. Centralna lokacja będzie hostować 5G Core VNF i IoT Server VNF.
2. Dołącz VNFD i NSD usługi inteligentnego rolnictwa do stosu OSM (wszystkie deskryptory można pobrać z repozytorium eksperymentów).
   1. Dołącz VNFD do stosu OSM, wykonując polecenie "osm vnfd-create " dla każdej z funkcji VNF usługi sieciowej. W tym przypadku parametr odpowiada nazwie pliku pakietu VNFD.
   2. Dołącz NSD do stosu OSM za pomocą polecenia "osm nsd-create ", gdzie wskazuje nazwę pliku pakietu NSD (w tym eksperymencie jove_uavs_scenario_nsd.tar.gz).
3. Wdróż usługę sieciową inteligentnego rolnictwa. W tym celu uruchom następujące polecenie z interfejsu wiersza poleceń OSM: osm ns-create --ns_name --nsd_name jove_uavs_scenario_nsd --vim_account --config '{vnf: [ {member-vnf-index: "5", vim_account: }, {member-vnf-index: "6", vim_account: } ], wim_account: Fałsz }'.
   UWAGA: Jak wskazano w kroku 3.6.3., parametry i wskazują lokalizacje, w których mają zostać wdrożone funkcje VNF. W szczególności wszystkie VNF składające się na usługę inteligentnego rolnictwa zostaną umieszczone w nowej lokalizacji zewnętrznej, z wyjątkiem tych o indeksie 5 i 6 (VNF rdzenia 5G i serwera IoT), które zostaną przydzielone do lokalizacji centralnej.
4. Sprawdź, czy NS został wdrożony, postępując zgodnie z tą samą procedurą, co w kroku 3.6.4.
5. Dostęp do serwera IoT VNF za pomocą polecenia "ssh mosquittosubscriber@" i sprawdzenie jego interfejsu skonfigurowanego do komunikacji z MQTT Gateway VNF poprzez komendę "ip address show dev eth1". Adres IP VNF () można uzyskać, wykonując polecenie "osm vnf-list" w wierszu poleceń OSM.
6. Postępując zgodnie z analogiczną procedurą, uzyskaj dostęp do bramy MQTT VNF i uruchom polecenie "sudo python3 publisher_MQTT_GW.py -ma -ba ", w którym zostanie uzyskany w poprzednim kroku, a wykonując polecenie "ip address show dev eth1" w MQTT Gateway VNF. Ten krok inicjuje funkcję VNF bramy MQTT, która będzie odbierać dane generowane przez czujnik przy użyciu standardu MQTT ¹⁵, przesyłając te dane do serwera IoT VNF przy użyciu tego samego standardu.
7. Przygotuj komputer jednopłytkowy (SBC) z czujnikiem meteorologicznym i możliwością przesyłania odczytów czujnika w kierunku bramki MQTT VNF.
   UWAGA: Aby zilustrować ten protokół, wykorzystano w szczególności model SBC. W związku z tym w przypadku korzystania z innej platformy SBC może być konieczne dostosowanie poniższych kroków.
   1. Podłącz (np. za pomocą drutów miedzianych lutowanych cyną) piny płytki czujnika do pinów wejścia/wyjścia ogólnego przeznaczenia (GPIO) kontrolera SBC, postępując zgodnie ze schematem konfiguracji Rysunek 5.
   2. Włącz moduł jądra I2C w kontrolerze SBC, aby móc sprawdzić, czy czujnik został wykryty. W tym celu uruchom polecenie "sudo raspi-config", postępuj zgodnie z sekwencją Opcje interfejsu -> I2C -> Tak w wyświetlonym menu i uruchom ponownie kontroler SBC, aby zmiany weszły w życie.
   3. Sprawdź, czy czujnik został wykryty Instalowanie oprogramowania i2c-tools w kontrolerze SBC i wykonywanie polecenia "sudo i2cdetect -y 1". Jeśli tak, powinna pojawić się siatka wskazująca pozycję, w której wykrywany jest czujnik.
   4. Zainstaluj odpowiednie biblioteki oprogramowania, aby umożliwić odczyt i wysłanie przez kontroler SBC danych dostarczonych przez czujnik. W szczególności eksperyment ten wykorzystuje biblioteki Pythona RPi.bme280³² i paho-mqtt³³.
8. Korzystając z aplikacji mobilnej SUAV, zdejmij pojazd powietrzny, w którym znajduje się punkt dostępowy VNF, i ustaw go tak, aby zapewnić zasięg bezprzewodowy do kontrolera SBC za pomocą czujnika.
   UWAGA: Lot SUAV zdolnych do pracy NFV jest niezależny od zachowania operacyjnego usługi sieciowej, która jest w stanie działać niezależnie od tego, czy SUAV lecą, czy są w stanie spoczynku, aby zminimalizować zużycie baterii. W związku z tym krok 4.8 jest opcjonalny
.
9. Podłącz kontroler SBC odpowiedzialny za odczyt danych zebranych przez czujnik do bezprzewodowego punktu dostępowego Wi-Fi dostarczonego przez punkt dostępowy VNF). Po pomyślnym dołączeniu zostanie włączona ścieżka sieci bezprzewodowej od czujnika do funkcji VNF bramy MQTT.
10. Rozpocznij transmisję danych z czujników, uruchamiając polecenie "python3 /home/ubuntu/sensorDataTransmission.py -a " w kontrolerze SBC, który zawiera czujnik ( to adres IP uzyskany w kroku 4.6.).
11. Uzyskaj dostęp do internetowego graficznego interfejsu użytkownika dostarczonego przez serwer IoT VNF, aby sprawdzić poprawny odbiór danych z czujników w czasie rzeczywistym. W tym celu sprawdź adres IP serwera IoT VNF za pomocą polecenia "osm vnf-list" i wpisz następujący adres URL (Uniform Resource Locator) w przeglądarce internetowej: http://:3001, gdzie to adres IP serwera IoT VNF. Następnie kliknij przycisk Zbieranie danych z czujników na karcie Strona główna i sprawdź aktualizację wykresów zawartych w pulpicie nawigacyjnym w czasie rzeczywistym w miarę odbierania danych.
    UWAGA: Aby uzyskać dostęp do adresu URL wymienionego w kroku 4.12, urządzenie z przeglądarką internetową próbującą uzyskać dostęp do tego zasobu musi być połączone z ekosystemem NFV i mieć łączność IP z VNF serwera IoT. Do tego celu można również wykorzystać usługę VPN.
12. Poczekaj odpowiedni okres czasu, aby uzyskać reprezentatywne wyniki realizacji usługi inteligentnego rolnictwa. Następnie zbierz dane przechowywane w serwerze IoT VNF w celu dalszej analizy. Biorąc pod uwagę, że czujnik zawarty w tym eksperymencie dostarcza odczyty temperatury, wilgotności i ciśnienia co 5 sekund, usługa w eksperymencie działała przez okres 10 minut, w wyniku czego uzyskano 180 próbek danych z czujników (po 60 dla każdego typu wartości meteorologicznej).
13. Uzyskaj dostęp do bazy danych IoT Server VNF, aby pobrać dane z czujników do dalszej analizy. W tym celu wykonaj polecenie "id_database=$(sudo docker ps | grep 'influxdb:' | cut -d ' ' -f 1)" na IoT Server VNF, a następnie "sudo docker exec -it $id_database bash"
14. Wyeksportuj dane do pliku z wartościami rozdzielanymi przecinkami (CSV), uruchamiając polecenie "influx -database 'mainflux' -execute "SELECT * FROM messages WHERE \"name\" = '' " -format csv > /tmp/.csv". Zmodyfikuj parametr aby wybrać, który typ danych z czujników ma być eksportowany z "temperaturą", "wilgotnością" lub "ciśnieniem", a następnie ustaw parametr aby wybrać nazwę pliku wyjściowego, w którym będą przechowywane wyniki.
15. Zapisz pliki danych wygenerowane w poprzednim kroku w celu późniejszej reprezentacji (patrz sekcja Reprezentatywne wyniki) i weryfikacji poprawnego działania usługi inteligentnego rolnictwa.

Wyniki

Po dokładnym przestrzeganiu protokołu w celu włączenia nowej witryny do centralnej platformy i uruchomieniu jednej usługi sieciowej w celu sprawdzenia jej poprawności działania, Rysunek 6 przedstawia zrzut ekranu narzędzia open-vpn-monitor. Można zaobserwować, w jaki sposób nowa witryna korzysta z VPN do całej swojej komunikacji, pokazując, w jaki sposób jej komunikacja podąża za VPN, aby umożliwić tę wymianę danych, a w konsekwencji prawidłowe dodanie nowej witryny do usługi VPN.

Jak pokazano w Rysunek 3, usługa sieciowa dostarcza informacje z czujnika znajdującego się w zdalnej infrastrukturze do serwera znajdującego się w centralnej lokalizacji. Dodatkowo, Rysunek 7 pokazuje pomyślne wdrożenie usługi sieciowej z graficznego interfejsu użytkownika OSM, pokazując, jak eksperyment może zostać poprawnie zinstancjonowany w nowej infrastrukturze zdalnej ze stosu MANO znajdującego się w centralnej lokacji. Co więcej, czas wymagany w eksperymencie do ukończenia wdrożenia usługi wynosi około ośmiu minut. Ta wartość, wraz z czasem potrzebnym do wdrożenia deskryptorów usług do platformy orkiestracji (około 9 sekund, przy 1,3 sekundy na deskryptor, biorąc pod uwagę zarówno deskryptory NS, jak i każdy deskryptor VNF), umożliwia spełnienie Kluczowego Wskaźnika Wydajności (KPI) wynoszącego 90 minut dla czasu tworzenia usługi, zgodnie ze wskazaniami Partnerstwa Publiczno-Prywatnego Infrastruktury 5G³⁴. W tym kontekście, praca przedstawiona w Vidal et al.⁹ zawiera dogłębną analizę czasu tworzenia usługi z wieloma witrynami korzystającymi z przedstawionego protokołu.

Rysunek 8 przedstawia dane zebrane z czujnika, w tym odpowiednio wartości wilgotności, temperatury i ciśnienia. Próbki te odpowiadają wszystkim danym wysyłanym z czujnika do zdalnego serwera znajdującego się w 5TONIC, gdzie wartości te są przechowywane w bazie danych. Wszystkie te dane pokazują, że platforma jest w stanie wdrożyć praktyczne usługi sieciowe po włączeniu nowej infrastruktury, a także poprawnie umożliwić komunikację między lokalizacjami.

Rysunek 1: Dystrybucja witryny usługi VPN. Dystrybucja usługi VPN za pośrednictwem platformy i ich łącze (wszystkie przechodzą przez 5TONIC). Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 2. Przegląd platformy i usługi VPN. Rysunek ten przedstawia wszystkie elementy platformy: centralną lokalizację wraz z infrastrukturą NFV, usługą VPN i nową infrastrukturą zagregowaną w systemie. Obejmuje również połączenia między jego elementami. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 3: Przegląd usługi sieciowej. Przedstawia elementy związane z usługą sieciową, jej dystrybucję oraz łączność logiczną i sieciową. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 4: Przepływy pracy z protokołem. Każda kolumna reprezentuje jedną sekcję protokołu, w której opisana jest każda wykonana czynność, jej logiczne połączenie między nimi a komponentem odpowiedzialnym za jej wykonanie. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 5: Schemat konfiguracji pinów. Diagram przedstawiający sposób wykonywania fizycznych połączeń między pinami płytki czujników a pinami GPIO kontrolera SBC, który zawiera ten czujnik. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 6: Migawka monitora OpenVPN. Na rysunku widać, że zagregowana infrastruktura jest połączona z usługą VPN, w tym niektóre jej szczegóły dotyczące połączenia. Co więcej, rysunek przedstawia również dodatkowe połączenia należące do innych zdalnych infrastruktur. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 7: Stan wdrożenia OSM NS. Interfejs graficzny OSM, pokazujący pomyślne wdrożenie testowej usługi sieciowej w infrastrukturze zdalnej. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

Rysunek 8: Reprezentatywna analiza danych zebranych przez czujnik. (A) Ilustracja danych o temperaturze zbieranych okresowo przez czujnik co 5 sekund. (B) Graficzne przedstawienie danych dotyczących wilgotności zbieranych przez czujnik co 5 sekund. (C) Wizualny obraz danych o ciśnieniu zbieranych przez czujnik co 5 sekund. Kliknij tutaj aby zobaczyć większą wersję tego rysunku.

Dyskusja

Jednym z najważniejszych aspektów wcześniej opisanego protokołu jest jego wyjątkowa elastyczność w zakresie włączania nowych infrastruktur obliczeniowych do ekosystemu NFV, niezależnie od ich rozmieszczenia pod względem lokalizacji geograficznej (o ile obsługuje to przepustowość i opóźnienia komunikacji sieciowej ze zdalnymi lokalizacjami). Jest to możliwe dzięki architekturze sieci nakładkowej opartej na VPN, która umożliwia ustanowienie wirtualnego łącza łączącego zdalne lokalizacje z centralnymi lokalizacjami ekosystemu NFV. Takie podejście umożliwia zapewnienie skutecznego i bezpiecznego kanału do obsługi NFV i komunikacji danych między lokalizacjami ekosystemu NFV, zmniejszając prawdopodobieństwo, że strony trzecie uzyskają dostęp i/lub zmodyfikują wrażliwe informacje dotyczące procesów orkiestracji NFV i danych z wdrożonych usług. W tym kontekście protokół opisuje również konkretną metodologię bezpiecznego udostępniania danych uwierzytelniających VPN zewnętrznym witrynom, które umożliwią integrację nowej infrastruktury. Przykładem protokołu jest ekosystem NFV udostępniony w 5TONIC przez Universidad Carlos III de Madrid, Telefónica i IMDEA Networks Institute, chociaż jest on uniwersalny do wykorzystania w innych środowiskach NFV spełniających wcześniejsze wymagania wymienione w kroku 1 tego protokołu.

Ponadto warto podkreślić wyłączne wykorzystanie narzędzi i oprogramowania open-source do implementacji protokołu. Niezależnie od potencjalnie korzystnych funkcjonalności, które mogą być oferowane przez różne rozwiązania zastrzeżone (np. Fortinet³⁵), wykorzystanie rozwiązań open source ułatwiło integrację wszystkich elementów objętych protokołem ze względu na ich nieodłączne cechy, takie jak opłacalność, szerokie wsparcie oprogramowania zapewniane przez społeczność open source oraz wysoki poziom niezawodności. żeby wymienić tylko kilka z nich. Co więcej, wykorzystanie technologii open source może również sprzyjać synergii między komponentami o podobnym charakterze. Na przykład, aby monitorować stan połączenia VPN dla klientów korzystających z platformy, usługa VPN zaimplementowana w całym protokole może polegać na narzędziu do monitorowania open-vpn³⁶ (narzędzie do monitorowania oparte na Pythonie, które może współpracować z serwerami OpenVPN).

Z drugiej strony specyfikacja protokołu uwzględnia tworzenie wystąpień usług sieciowych w różnych lokacjach w celu walidacji. W związku z tym należy podkreślić, że wdrożenie usług w danej lokacji jest uzależnione od dostępności zasobów obliczeniowych, pamięci masowej i sieciowej w danej lokalizacji, a także specjalistycznego sprzętu, który może być potrzebny do przeprowadzenia wdrożenia (np. SUAV z obsługą NFV). Nie jest to ograniczenie protokołu i powinno być brane pod uwagę przez interesariuszy zainteresowanych odtworzeniem eksperymentu opisanego w tym artykule.

Ponadto należy zauważyć, że czas wymagany do wdrożenia usług sieciowych w dużym stopniu zależy od kilku czynników, takich jak ścieżka sieciowa między koordynatorem a różnymi VIM-ami, wydajność transmisji danych między VIM a jego zarządzanymi węzłami obliczeniowymi, a także od wewnętrznej natury tych węzłów obliczeniowych (nie tylko ze względu na ich dostępne zasoby obliczeniowe, ale także technologie wykorzystywane do prowadzenia wirtualizacji funkcji sieciowych).

Wreszcie, biorąc pod uwagę znakomite wyniki, jakie ta platforma i jej usługa VPN osiągnęły w europejskich projektach i wspólnych pracach, w których była dotychczas wykorzystywana (np. 5GINFIRE, 5GRANGE lub 5GCity, wspomniane we wstępie do niniejszego dokumentu), będzie ona uważana za ważny element powstających projektów europejskich, w których Universidad Carlos III de Madrid, Telefónica i IMDEA Networks Institute uczestniczą w projektach, takich jak LABYRINTH w ramach programu Horyzont 2020, lub w projektach krajowych, takich jak TRUE-5G.

Materiały

Lista materiałów użytych w tym artykule

Nazwa	Firma	Numer katalogowy	Komentarze
Bebop 2	Parrot		wykorzystany w eksperymencie do transportu RPi, a tym samym zapewnienia mobilności jednostkom obliczeniowym placówki zewnętrznej.
Czujnik BME280	Bosch		zdolny do dostarczania odczytów warunków środowiskowych dotyczących temperatury, ciśnienia atmosferycznego i wilgotności.
Komercyjny serwer Intel Core Mini-ITX Computer	Logic Suppy		Computer, który hostuje węzeł kontrolera OpenStack (wykonywany jako maszyna wirtualna) zewnętrznego interfejsu eksperymentu. Ponadto inna jednostka tego sprzętu (wraz z RPis) jest zgodna z zasobami obliczeniowymi zakładu NFV zawartego w tym miejscu.
Iptables	Netfilter - Narzędzie		(Oprogramowanie) Narzędzie wiersza poleceń typu open source do konfiguracji zestawu zapory sieciowej jądra Linux. Kod źródłowy dostępny online: https://www.netfilter.org/projects/iptables/
Lithium Battery Pack Expansion Board. Model KY68C-UK	Kuman		Zasilanie bateryjne HAT (Hardware Attached on Top) dla jednostek obliczeniowych UAV składających się na infrastrukturę NFV obiektu zewnętrznego.
MacBook Pro	Laptop Apple		Commodity wykorzystany podczas eksperymentu do uzyskania i zebrania wyników zgodnie z opisem w manuskrypcie.
Mainflux	Mainflux Labs - Platforma		(oprogramowanie) Platforma Internetu rzeczy (IoT) typu open source wykorzystana w eksperymencie do implementacji funkcji sieci wirtualnej o nazwie IoT Server VNF. Ponadto platforma ta zawiera oprogramowanie typu open source oparte na narzędziu Grafana, które umożliwia wizualizację i formatowanie danych metrycznych. Kod źródłowy dostępny online: https://www.mainflux.com/
Open Source MANO (OSM) - Release FOUR	ETSI OSM - Open source community		systemu NFV skonfigurowany w eksperymencie. Kod źródłowy dostępny online: https://osm.etsi.org/docs/user-guide/
OpenStack - Release Ocata	OpenStack - Społeczność		(Oprogramowanie) Oprogramowanie open source używane do konfiguracji zarówno infrastruktury NFV w ośrodku centralnym, jak i infrastruktury NFV w ośrodku zewnętrznym w ramach eksperymentu. Kod źródłowy dostępny online: https://docs.openstack.org/ocata/install-guide-ubuntu
OpenVPN - Version 2.3.10	OpenVPN - Open source community		Oprogramowanie open source implementujące usługę VPN przedstawioną w eksperymencie w celu stworzenia sieci nakładkowej, która umożliwi działanie ekosystemu NFV (zapewniając łączność między wszystkimi lokalizacjami składającymi się na ekosystem). Kod źródłowy dostępny online: https://openvpn.net/
Openvpn-monitor	Python - Oprogramowanie		(Oprogramowanie) Program typu open source oparty na kodzie Pythona, który umożliwia wizualizację stanu usługi VPN, a także reprezentację witryn, które są połączone w każdej chwili. W tym celu program sprawdza przede wszystkim informacje dostarczane przez serwer VPN zaimplementowany za pomocą OpenVPN. Kod źródłowy dostępny online: https://github.com/furlongm/openvpn-monitor
Paho-mqtt 1.5.0	Python - Biblioteka		(Oprogramowanie) Biblioteka Open source opracowana w kodzie Pythona, która umożliwia transmisję danych odczytywanych przez czujnik za pomocą standardu MQTT  Kod źródłowy dostępny online: https://pypi.org/project/paho-mqtt/
Ping	Debian - Narzę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 R430	Wysokoprofilowy serwer komputerowy Dell, który zapewnia moc obliczeniową w centralnej lokalizacji przedstawionej w eksperymencie.
Power Edge R430	Dell		Wysokiej klasy serwer komputerowy odpowiedzialny za hostowanie usługi wirtualnej sieci prywatnej (VPN). Należy pamiętać, że wymagania obliczeniowe dotyczące aprowizacji tej usługi są wysokie ze względu na zużycie zasobów przez operacje szyfrowania obecne w usłudze.
Power Edge R630	Sprzęt firmy Dell		używany do hostowania maszyny wirtualnej (VM) za zadanie wykonania stosu MANO. Ponadto węzeł kontrolera OpenStack lokacji centralnej 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.
Malina PI. Model 3b	Raspberry Pi Foundation		Wybrany model komputera jednopłytkowego (SBC) służącego do dostarczania mocy obliczeniowej do zewnętrznego ośrodka eksperymentu. Ponadto ten model SBC jest używany podczas wdrażania dołączonej realistycznej usługi do interpretowania i wysyłania danych zebranych przez czujnik.
RPi.bme280 0.2.3	Python - Biblioteka		(Oprogramowanie) Biblioteka open source opracowana w kodzie Pythona, która pozwala na połączenie czujnika Bosch BME280 i interpretację odczytów oferowanych przez ten czujnik. Kod źródłowy dostępny online: https://pypi.org/project/RPi.bme280/