Internet 5G

Wprowadzenie

Ewolucja technologii internetowych zbliżyła się do całej usługi przełączania pakietów IP, która ukształtowała sposób, w jaki żyjemy, pracujemy, uczymy się i bawimy. Dzisiejszy Internet zapewnia bogatą paletę usług, które obejmują między innymi rozrywkę medialną (np. gry audio, wideo i gry wysokiej rozdzielczości), personalizację (np. Haptics, aplikacje oparte na obecności i usługi oparte na lokalizacji) i bardziej wrażliwe oraz aplikacje krytyczne dla bezpieczeństwa (np. e-handel, e-Zdrowie, osoby udzielające pierwszej pomocy itp.). Według statystyk Międzynarodowego Związku Telekomunikacyjnego (ITU), globalny Internet został osiągnięty przez ponad 2,4 miliarda użytkowników na całym świecie w czerwcu 2012 r., A liczba ta stale rośnie. Badanie firmy Ericsson przewiduje 40-krotny wzrost ruchu danych z telefonów komórkowych i przenośnych komputerów osobistych / tabletów w latach 2010-2015 . Ponadto prognoza Cisco dotycząca wykorzystania sieci IP do 2017 r. Ujawniła, że ruch internetowy ewoluuje od bardziej stabilnego do bardziej dynamicznego. Globalny ruch IP będzie odpowiadał 41 milionom płyt DVD na godzinę w 2017 r., A komunikacja wideo będzie nadal w zakresie 80-90% całkowitego ruchu IP. W tym kontekście niemal każdy obiekt fizyczny, który widzimy (np. Ubrania, samochody, pociągi itp.), Również zostanie podłączony do końca dekady, tworząc Internet przedmiotów (IoT). Przykładem jest komunikacja Machine-to-Machine (M2M) wykorzystująca sieci oparte na czujnikach, co skutkuje dodatkowym czynnikiem napędzającym wzrost ruchu. Okazuje się, że sterownikami przyszłego Internetu są wszelkiego rodzaju usługi i aplikacje, od niskich przepustowości (np. Danych czujnika i IoT) do wyższych (np. Strumieniowanie wideo w wysokiej rozdzielczości), które muszą być kompatybilne, aby obsługiwać różne opóźnienia i urządzenia. Na przykład aplikacje oice over IP (VoIP) wymagają co najwyżej 150ms opóźnienia, 30ms jitteru i nie więcej niż 1% utraty pakietów, aby utrzymać optymalną jakość postrzeganą przez użytkownika (QoE). Interaktywne strumienie wideo lub wideokonferencje, osadzają połączenia głosowe, a tym samym mają takie same wymagania dotyczące poziomu usług jak VoIP. Natomiast usługi przesyłania strumieniowego wideo, znane również jako wideo na żądanie, mają mniej rygorystyczne wymagania niż VoIP ze względu na techniki buforowania zwykle wbudowane w aplikacje. Inne usługi, takie jak FTP (File Transfer Protocol) i e-mail, są względnie nieinteraktywne i niewrażliwe. Jednak protokoły kontroli sieci i zarządzania wymagają odpowiedniej gwarancji przepustowości, aby zapewnić, że komunikaty sterujące są prawidłowo dostarczane na czas, aby zapobiec pogorszeniu wydajności. Co więcej, dotychczasowy Internet traktuje usługi jednakowo na zasadzie najlepszych starań. Ponadto sieci obecnych operatorów są wypełnione dużą i rosnącą różnorodnością zastrzeżonych urządzeń sprzętowych. Z tego powodu uruchomienie nowej usługi sieciowej często wymaga znalezienia odpowiedniej przestrzeni i mocy, aby pomieścić nowe skrzynki. Osiągnięcie tego celu jest niezwykle trudne i nadążaj za nowymi trendami, ponieważ innowacje technologiczne i serwisowe przyspieszają i skracają cykl życia sprzętu. Ponadto infrastruktury sieciowe wymagają zautomatyzowanych możliwości kontroli skalowalności, niezawodności i dostępności, szczególnie w dużych środowiskach sieciowych, w celu zmniejszenia wpływu ręcznej interwencji, która staje się kosztownym towarem. Inne obawy obejmują rosnące koszty energii, wyzwania związane z inwestycjami kapitałowymi oraz problemy narzucone przez projektowanie, integrację i działanie coraz bardziej złożonych urządzeń sprzętowych. Te rosnące ograniczenia Internetu w zakresie zarządzania siecią, które jest trudne do wdrożenia, oraz przekazywania najlepszych wyników, które nie spełniły wymagań jakości usług (QoS) dla aplikacji o wartości dodanej, są dobrze znane w społeczności badawczej, czy to w środowisku akademickim, czy w przemyśle. Dlatego powszechnie przyjmuje się, że architektura internetowa musi zostać poddana renowacji, a wiele propozycji, w tym podejście "czystego łupka", zostało zaproponowanych. Jest coraz bardziej oczywiste, że w sieciach komunikacyjnych zbliża się punkt zwrotny dzięki stopniowemu wprowadzaniu sieci definiowanych programowo (SDN) i wirtualizacji funkcji sieciowych, aby zapewnić wymaganą elastyczność i reaktywność. W szczególności SDN sugeruje, że odsprzęgnięcie płaszczyzny sterowania siecią od płaszczyzny danych (np. w chmurze) i wirtualizacja sieci pozwala na tworzenie wielu różnych logicznych funkcji sieciowych na jednej wspólnej wspólnej infrastrukturze sieciowej. W literaturze OpenFlow i GENI próbują zachęcić dostawców sieci do programowalnych przełączników i routerów (np. Wykorzystujących koncepcje wirtualizacji i SDN), które mogą przetwarzać pakiety dla wielu izolowanych sieci eksperymentalnych jednocześnie.

Co więcej, ostatnie wyniki badań dowodzą, że nadmierne dostarczanie zasobów sieciowych, polegające na rezerwowaniu większej ilości zasobów niż może wymagać Klasa usług (CoS), może skutecznie osiągnąć różnicowanie QoS w sposób skalowalny, którego podejście jest fundamentalne dla przyszłego Internetu. Podczas gdy technologie te (tj. SDN, wirtualizacja i nadmierne udostępnianie QoS) obiecują poprawić wydajność sieci w przyszłości, wciąż są w powijakach, a dalsze analizy i badania nadal są uważane za konieczne. Na przykład nadmiar zasobów należy starannie zaprojektować, aby zapobiec marnotrawstwu zasobów. Aspekty te są dodatkowo napędzane przez rosnące uzależnienie od Cloud Computing, gdzie różne modele, takie jak Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) i Infrastructure-as-a-Service (IaaS) oraz inne aspekty operacji sieciowych i usług są wirtualnie hostowane przez Internet. W szczególności SaaS jest modelem usług w chmurze do dostarczania oprogramowania, w którym oprogramowanie i odpowiednie dane są przechowywane w chmurze, a dostęp można wykonać za pomocą prostej nawigacji w przeglądarce internetowej (np. Google Mail i Google Docs). Ponadto model PaaS umożliwia świadczenie usług niższego poziomu, takich jak system operacyjny, serwer WWW lub tłumacz języka komputerowego jako usługi. Wykorzystując na przykład PaaS, programiści mogą tworzyć własne aplikacje bez konieczności instalowania ciężkiego oprogramowania na własnych komputerach (np. Google App Engine). Ponadto model IaaS zapewnia infrastrukturę sieciową, w tym serwery w centrach danych (DC), z których klienci chmury mogą korzystać na zasadzie pay-to-you-go (np. Amazon Elastic Compute Cloud). W związku z tym, ponieważ wirtualizacja umożliwia emulację sprzętu komputerowego w oprogramowaniu, a kilka emulowanych komputerów (wirtualnych komputerów) może działać jednocześnie na jednym fizycznym komputerze, cała infrastruktura i transport sieciowy mogą być efektywnie udostępniane jako usługa, wzmacniając różne scenariusze, począwszy od sieci przedsiębiorstwa rozszerzenie na zarządzanie całym dostawcą usług internetowych. "Chmura" to ogólny termin, który oznacza Internet i przetwarzanie w chmurze, i pozwala na umieszczenie większej ilości materiałów w chmurze, a mniej na urządzeniach klienckich (np. komputerach PC, serwerach i telefonach). Przezwycięża to istniejące bariery, takie jak wzrost pojemności usług, która zamiast wymagać od dostawcy usług fizycznego rozszerzenia zasobów, może raczej polegać na wspólnej wirtualnej rozproszonej puli zasobów sieciowych, przetwarzania i przechowywania. Mapa drogowa badań naukowych FIA (Future Internet Assembly - FIA) dla programu "Horyzont 2020" Komisji Europejskiej (H2020) zawierała pomysły i wkład społeczności FIA w ważne tematy badawcze, które powinny zostać uwzględnione w programach badawczych H2020. Tematy te są podzielone na trzy główne kwestie: interesy gospodarcze i biznesowe; interesy społeczne i wyzwania; oraz techniczne zakłócenia i możliwości. Z perspektywy ekonomicznej i biznesowej, priorytety przyszłych badań internetowych w ramach programu H2020 muszą mieć na celu wpływ na produkty, usługi, możliwości i korzyści za około 10 lat. Z społecznego punktu widzenia musimy wyobrazić sobie sieć, która da obywatelom narzędzia biznesowe do kontrolowania swoich danych, wyrażania swoich praw i wypełniania swoich zobowiązań oraz działania w sposób pewny w cyberprzestrzeni, która jest przeniknięta danymi dotyczącymi wszystkiego i każdego aspektu życia. Jeśli chodzi o aspekty techniczne, jeśli założymy, że konwergencja sieci i chmura już się wydarzyły i patrzymy w przyszłość, będziemy postrzegać przyszły Internet nie jako sieć, chmurę, pamięć masową lub urządzenia, ale jako środowisko wykonawcze dla inteligentnych aplikacji, usług, interakcji, doświadczenie i dane. Przyszła sieć powinna integrować wiele różnych możliwości poza konwergentnymi sieciami czujników infrastruktury, Internetem, hotspotami, siecią bezprzewodową, siecią rdzeniową - aby zapewnić znacznie większą pojemność i zakres potrzebnych usług. Potrzebujemy nowych interfejsów i trybów interakcji z systemami i urządzeniami sieciowymi, ludźmi i społecznościami oraz danymi. Będą one stanowić odskocznię w kierunku nowych modalności i perspektyw zachęcających do przełomowych i innowacyjnych rozwiązań w celu budowania przyszłego Internetu. Wreszcie, potrzebujemy bezpieczeństwa Internetu i bezpieczeństwa jego użytkowników online. Rozpatrując wszystkie te obawy ze środowiska badawczego sieci, ewentualne przyszłe programy badawcze zostały szeroko omówione w źródłach i. W szczególności:

(i) rozwiązania powinny być bardziej ekologiczne dla oszczędności energii; (ii) koncepcja "sieci jako usługi" wymaga ściślejszej współpracy między graczami sieci i usług; (iii) samoorganizacja i autonomia w zarządzaniu złożonością sieci jest kluczowym wymogiem; (iv) wirtualizacja pozwalająca na sieć sieci i współdzielenie infrastruktury musi być głęboko zbadana; oraz (v) Mobile Cloud Computing wymaga bardziej kompleksowego podejścia badawczego. W związku z tym Unia Europejska (UE) zaproponowała program partnerstwa publiczno-prywatnego (PPP), którego celem jest dostarczanie rozwiązań, architektur, technologii i standardów dla wszechobecnych infrastruktur sieciowych 5G w następnej dekadzie. Oczekuje się, że w 2020 r. przyszły Internet, tj. Internet 5G, będzie w stanie połączyć wszystko według wielu specyficznych wymagań aplikacji: ludzi, rzeczy, procesów, centrów obliczeniowych, treści, wiedzy, informacji i towarów, połączonych w elastyczny, prawdziwie mobilny i wydajny sposób. W tym środowisku, z niespotykanymi wciąż rosnącymi wymaganiami użytkowników, wierzymy, że sieć wymaga skalowalnych, niezawodnych, wydajnych kosztowo i energooszczędnych rozwiązań do tworzenia wartości dodanych usług, transportowanych za pomocą zróżnicowanych gwarancji QoS i szerokiego zakresu opcji QoS Dla klientów. W tym sensie ten rozdział ma na celu przedyskutowanie, jaki może być kształt internetowych technologii architektonicznych 5G umożliwiających synergiczne podejście do SDN, wirtualizacji funkcji sieciowych (NFV), mobilności i zróżnicowanej kontroli QoS. Ponadto wprowadzamy internetowy protokół udostępniania zasobów, który jest w stanie zagwarantować zróżnicowane QoS przy zwiększonym wykorzystaniu zasobów, bez ponoszenia nadmiernej sygnalizacji lub marnotrawstwa zasobów. Część jest zorganizowana w następujący sposób. Część 2.2 omawia Internet rzeczy i świadomość kontekstową. Sekcja 2.3 zawiera szczegółowe informacje na temat rekonfiguracji sieci i obsługi wirtualizacji. W sekcji 2.4 przedstawiamy badania z zakresu zarządzania obsesją oparte na podejściu ewolucyjnym i czystym podejściu do Internetu 5G. Sekcja 2.5 omawia obsługę QoS. Ponadto sekcja 2.6 wprowadza nowy mechanizm kontroli QoS z obsługą funkcji SDN.

Internet rzeczy i świadomość kontekstowa

Wraz ze wzrostem liczby rozwiązań łączeniowych w porównaniu z wieloma smartfonami, łączami samochodowymi, czujnikami, urządzeniami domowymi i wieloma innymi rodzajami urządzeń, liczba podmiotów sieciowych osiąga niespotykany dotąd poziom. Ewolucje internetowe są wymagane nie tylko po to, aby umożliwić optymalne działanie w tych środowiskach, ale także, aby umożliwić dalsze rozszerzenie i ulepszenia, biorąc pod uwagę przyszłe przypadki użycia, które wykraczają poza adresowanie rozszerzone, takie jak dostarczane przez IPv6. Niezbędne podstawowe funkcje sieciowe, począwszy od zarządzania, tożsamości, bezpieczeństwa, mobilności i innych, muszą ewoluować w bardziej skalowalny sposób, aby wspierać eksplozję urządzeń, i rzeczywiście stać się Internetem przedmiotów. Podobnym wyzwaniem jest świadomość kontekstowa, która ma na celu wykorzystanie inteligentnych usług i aplikacji, dążąc do wykorzystania wybuchowej ilości danych kontekstowych opisujących użytkowników i ich sytuacje (takie jak lokalizacja, czas itp.) W celu dostosowania ich zachowania (kontekst adaptacja). Oczekuje się, że system internetowy zintegruje funkcje sugerujące użytkownikom elementy, które spełniają ich zainteresowania, oraz optymalne preferencje dla konkretnej sytuacji i kontekstu. Technologie te są jednak wciąż w powijakach i dalsze badania są uważane za konieczne w wielu dziedzinach, w tym personalizacja, kontrola sieci, wyszukiwanie informacji, eksploracja danych i marketing.

Internet przedmiotów

W ciągu ostatnich kilku lat ewolucja miniaturyzacji elektronicznej umożliwiła połączenie i integrację możliwości komunikacyjnych w coraz większej liczbie różnych rodzajów urządzeń, takich jak czujniki. Z kolei dostępność tych możliwości łączności sprzyjała ulepszenie istniejących technologii radiowych, a także rozwój nowych technologii. W szczególności uzupełnienie zestawu skoordynowanych mobilnych sieci bezprzewodowych opartych na makrokomórkach (np. trzeciej generacji - 3G, długoterminowej ewolucji - LTE, ogólnoświatowej interoperacyjności dla dostępu mikrofalowego - WiMAX) oraz łączności bezprzewodowej opartej na rywalizacji (np. bezprzewodowa sieć lokalna - WLAN), widzieliśmy nowe wdrożenia bezprzewodowe ukierunkowane na Personal Area Networks (PAN), takie jak ZigBee, Instytut Inżynierów Elektryków i Elektroników - IEEE 802.15.4, DASH7, WirelessHART i Weightless, dodając do powszechnie dostępnych technologii Bluetooth i podczerwieni. Ten wzrost możliwości komunikacyjnych urządzeń dodał impetu do dobrze zbadanego obszaru bezprzewodowych sieci czujników, zachęcając do ich wdrożenia w bezprecedensową liczbę nowych przypadków użycia, możliwości biznesowych i wkładu społecznego. Co więcej, rozszerzenie to wykracza poza wyłączne zastosowanie sieci czujników bezprzewodowych w szersze środowisko połączeń, obejmujące urządzenia o różnym charakterze, od telefonów komórkowych po samochody, sprzęt monitorujący, monitorowanie mediów, automatyzację produkcji, logistykę, wsparcie biznesowe i wiele innych inni. Wraz z heterogenicznym wyzwaniem równoczesnego dotarcia do tych urządzeń za pomocą różnych technologii dostępu, dla różnych scenariuszy i przypadków użycia, zaczęto opracowywać ramy sterowania wspierające te środowiska, wykorzystując koncepcje IP w celu zapewnienia zdalnych procedur osiągalności. W ten sposób narodził się Internet przedmiotów. Dostęp do platform urządzeń został wzmocniony dzięki dostosowaniom IP, takim jak 6LoWPAN], dzięki czemu zbliżył się on do architektury zorientowanej na usługi, dodając bogate projektowanie aplikacji i integrację z komunikacją typu maszynowego. Wykorzystując te koncepcje nawet w bardzo prostych urządzeniach elektronicznych, poprzez protokoły takie jak CoAP z grupy roboczej Constrained RESTful Environments (CoRE) Internetowej Grupy Zadaniowej ds. Inżynierii Internetowej (IETF), do urządzeń dodano możliwości kontrolowania usług internetowych, co pozwoliło na prawdziwie zintegrowane i inteligentne wdrożenia scenariuszy. Koncepcje te były aktywnie badane w projektach takich jak SODA (Service Oriented Device and Delivery Architecture), SOCRADES (Service-Oriented Cross-layer infrastructure dla Distributed Smart Embedded Systems, SENSEI (Integracja fizyczna z cyfrowym światem sieci przyszłości) i SmartSantander, które pozwoliły zmniejszyć przepaść między światem fizycznym a cyfrowym, i służyły do prawdziwej integracji urządzeń w wielkoskalowe platformy, tworząc Inteligentne Miasto, Inteligentne Rolnictwo i wiele innych scenariuszy, w których informacje uzyskiwane z różnych rodzajów czujniki (np. temperatura, wilgotność, zanieczyszczenie, wideo) zostały połączone z politykami i algorytmami kontrolnymi w celu zautomatyzowania decyzji, które napędzają urządzenia uruchamiające podłączone do platformy (np. zmiana sygnalizacji świetlnej w celu zmniejszenia zanieczyszczenia CO2 w zatłoczonych obszarach w Smart Traffic, optymalizacja zużycia wody w Scenariusze Smart Utilities, a nawet automatyzacja i automatyczna regulacja c nawadnianie rop w scenariuszach inteligentnego rolnictwa).

W wyniku wystawienia architektur IoT na wiele różnych scenariuszy, wpływ na różne obszary badawcze i ich ewolucję, biorąc pod uwagę wyzwania i wymagania ich zastosowania w tych środowiskach. W ten sposób osiągnięto nowe wyniki badań w zakresie bezpieczeństwa, prywatności, efektywności energetycznej i wielu innych obszarów, aby wziąć udział w ich wkładzie w tak bogate i różnorodne środowiska, jak IoT. Jednak efektem ubocznym jest zwiększone rozmieszczenie platform IoT w różnych domenach była nieskoordynowana eksplozja przestrzeni rozwiązania. W szczególności różne platformy, złożone z różnych konfiguracji stosów sieciowych i usługowych, zostały wdrożone w różnych scenariuszach. W ten sposób IoT, zamiast być powszechnie stosowanym materiałem, w rzeczywistości generował różne pionowe silosy na rozwiązania, w których komponenty należące do każdego innego rozwiązania nie były w stanie połączyć się lub być wymienne, lecz raczej działały jako wyodrębnione wyspy. Do tego czynnika przyczyniły się takie aspekty, jak rozbieżność w urządzeniach i interfejsach sieciowych oraz pojemnościach urządzeń, a także różne semantyki zaangażowanych urządzeń (np. Czujników i siłowników). W celu ułatwienia przyjęcia i integracji wdrożeń IoT w coraz większej przestrzeni aplikacji, dokonano zmiany kształtu paradygmatu, zmieniając pionowe rozwiązania w rozmieszczenie poziome, gdzie różne warstwy zapewniają współużytkowane podłoże, które jest interoperacyjne, wielo-technologiczne, multi-platform i multi-scenario. W ten sposób można wykorzystać te same mechanizmy sieciowe, te same platformy połączeń urządzeń i te same warstwy usług, kontroli i zarządzania w różnych scenariuszach. Przyczyniając się do tej zmiany, różne projekty przesuwają się ku badaniom nad IoT, takim jak MINDiT, gdzie jeden ogólny interfejs może być ponownie wykorzystany do sterowania i uzyskiwania informacji z różnych rodzajów urządzeń w heterogenicznych scenariuszach. Te same koncepcje są również badane i rozwijane przez nowe generacje projektów badawczych, takich jak IoT-A (Internet Rzeczy - Architektura), i są podstawą działań normalizacyjnych, takich jak Maszyna do Maszyny Europejskiego Instytutu Norm Telekomunikacyjnych (ETSI) Standardy maszyn, które stanowią podstawę eksploatacji operatorów telekomunikacyjnych przez platformy dostępu oparte na usługach. Zamiast osiągać ostateczne rozwiązanie lub etap badań, Internet przedmiotów wciąż ewoluuje. Oprócz ciągłego ujawniania tych koncepcji w nowych scenariuszach, różne nowe trendy badawcze wpływają również na nowe sposoby myślenia o IoT, pozwalając na odkrywanie nowych przełomowych technologii informacyjnych i komunikacyjnych, takich jak Cloud Computing, SDN lub Big Data.

Świadomość kontekstowa

Świadomość kontekstowa została szeroko zbadana w ramach europejskiego projektu C-CAST, którego głównym celem jest rozwijanie mobilnej multiemisji multimedialnej w celu wykorzystania coraz większej integracji urządzeń mobilnych z naszym codziennym światem fizycznym i środowiskiem. C-CAST zwiększa wykorzystanie środowisk czujników i inteligentnych urządzeń (a.k.a. smart space), aby umożliwić nowe wymiary personalizacji globalnego rynku telekomunikacyjnego. Inteligentną przestrzenią w tym względzie może być każda dobrze zdefiniowana przestrzeń zamknięta, taka jak sala konferencyjna lub szkoła, lub dobrze zaprojektowana otwarta przestrzeń, taka jak plac miejski lub park narodowy. Zazwyczaj składa się z wielu heterogenicznych czujników, inteligentnych urządzeń i kontekstowych zlewów informacji, wraz z serwerami danych z odpowiednimi (lokalnymi publicznymi / środowiskowymi) informacjami, które współdziałają ze sobą, aby zapewnić wzbogacone usługi, a tym samym ułatwić płynne działania użytkowników. W literaturze pokrewnej można wskazać kilka definicji kontekstu. Kontekst może być dowolnym rodzajem informacji, która może być wykorzystana do scharakteryzowania sytuacji jednostek (np. osoby, miejsca, obiektu), które są uważane za istotne dla interakcji między użytkownikiem a aplikacją, w tym użytkownika i samej aplikacji. Przykłady informacji kontekstowych od strony użytkownika sieci to lokalizacja geograficzna użytkownika, prędkość, kierunek, aktywność, moc baterii, możliwości urządzenia, środki transportu, czas bezczynności i tak dalej. Z perspektywy sieci informacje kontekstowe mogą obejmować sytuację przeciążenia, wykorzystanie zasobów, nieprzewidywalną zmianę trasy, dostępne punkty dostępu do sieci, statystyki mapowania QoS i różne modele QoS. Twierdzi się, że system świadomi kontekstu musi być w stanie wyczuć i zrozumieć odpowiedzi na pytania generowane z: kto, co, kiedy, gdzie i dlaczego; podczas gdy świadomość kontekstowa jest stanem, w którym urządzenie lub program jest świadomy środowiska i automatycznie wykonuje produktywne funkcje. Oznacza to, że urządzenia i programy zorientowane kontekstowo nie są już pasywnymi istotami czekającymi na instrukcje lub polecenia, a zamiast tego są żywe i zdolne do inteligentnych zachowań. Sieci i usługi wykorzystywałyby odpowiednie informacje kontekstowe, aby dostosować swoje zachowanie do zmieniających się warunków w bardzo dynamiczny sposób. Szybko rozwija się także wszechobecna technologia komputerowa, a także kilka propozycji wykorzystujących środowiska bogate w czujniki i urządzenia do spersonalizowanego i wszechobecnego przetwarzania zorientowanego na człowieka, jak widać w projektach Aura, Oxygen, BlueSpace i Cooltown. W ten sam sposób w społeczności pojawiło się wiele propozycji oprogramowania warstwy pośredniej zorientowanego na usługi, takich jak Gaia Project, SOCAM, Context Toolkit, CoBrA i CMF. Więcej przykładów aplikacji kontekstowych można również znaleźć w odnośnikach. Świadomość kontekstu sieciowego to zdolność systemu do wykorzystywania informacji o kontekście sieciowym do samodzielnej adaptacji lub do świadczenia usług. Lee i in. użyj serwera kontekstowego i serwera komunikatów Context-Aware i zaproponuj usługę przesyłania wiadomości opartą na kontekście "Dołącz wiadomość" z drzewami multiemisji zbudowanymi odgórnie, podczas gdy oczekują, że format pakietu będzie bardziej elastyczny w przyszłej sieci. Ocampo i in. wykazać klasyfikację przepływu opartą na kontekście i stwierdzić, że obecnie nie jest możliwe wszechstronne uwzględnienie i zaklasyfikowanie przepływów usług pod względem ich szerszego kontekstu, przy jednoczesnym uwzględnieniu parametrów wewnętrznych i zewnętrznych względem samego przepływu (takich jak rodzaj aplikacji, która go wygenerowała) , cechy urządzenia, które będzie go używać, oraz działania użytkownika, który go wygenerował).

Obsługa rekonfiguracji sieci i wirtualizacji

Wzrost liczby połączeń sieciowych, poczynając od mobilnych smartfonów, a kończąc na światłowodowych dekoderach w domu, a także ciągłym zwiększaniu liczby usług online, obecnie umniejsza starsze technologie wdrażania i strategie operatorów. Chociaż silna baza klientów jest celem biznesowym dla operatorów i dostawców usług, są one kosztowne, tworząc skomplikowane scenariusze jakości usług i zwiększając wydatki kapitałowe (wydatki kapitałowe) i wydatki operacyjne (Opex) na wsparcie nowych partii klientów. Obecnie, aby wspierać tę rosnącą bazę klientów i rozszerzyć łączność online na nowe obszary, należy wdrożyć nowe łącza i zwiększyć przepustowość, a także więcej infrastruktury usługowej i centrów danych, co znacznie zwiększa koszty związane z tymi rozszerzeniami. Nowe technologie wspomagające zostały zbadane i zastosowane do nowych strategii dynamicznego dostosowywania sieci i usług zgodnie z zapotrzebowaniem. W poniższych podrozdziałach skupiamy się na dwóch najbardziej wpływowych mechanizmach dla nadchodzącego 5G, mianowicie na programowaniu sieciowym i wirtualizacji funkcji sieciowych. Pierwszy umożliwia dynamiczną rekonfigurację oprogramowania i aspekty przekazywania sieci poprzez logiczne oddzielenie ścieżek sterowania i danych. W tym drugim przypadku operatorzy sieci i usług korzystają z istniejącej puli zasobów sieciowych i przetwarzających, aby wygenerować niezbędną infrastrukturę bazową w wirtualny sposób, zamiast fizycznie wdrażać nową infrastrukturę sieciową i serwerową.

Sieci zdefiniowane programowo

Ciągła ewolucja technologii sieciowych motywuje pojawianie się nowych mechanizmów kontroli i strategii, z zamiarem nie tylko testowania nowych procedur sieciowych, ale w rzeczywistości ich obsługi, takich jak SDN. Podejście SDN obejmuje logicznie scentralizowaną jednostkę, nazywaną kontrolerem, która zarządza podstawową płaszczyzną danych sieciowych za pomocą zorientowanego na usługi interfejsu API, który pozwala mu skonfigurować tabele przesyłania sprzętu sieciowego (np. Przełączniki) na temat reakcji na przychodzące pakiety i przepływy . Strategia ta zapewnia oddzielenie płaszczyzn danych i sterowania i jest realizowana za pomocą procedur oprogramowania. Rysunek przedstawia przykład działania SDN. W tym scenariuszu kontroler SDN (SDNC) odpowiada za obsługę trzech różnych przełączników OpenFlow.

Podłączony do OpenFlow Switch nr. 1 to dwa generatory informacji. Generator A generuje informacje o "stopniu produkcji" (tj. regularny ruch), którego celem jest konsument A, podczas gdy generator B jest używany do testowania nowego protokołu. W tej koncepcji twórcy tego protokołu chcieli ocenić jego wydajność w sieci produkcyjnej. W ten sposób kontroler został skonfigurowany w taki sposób, że po wykryciu protokołu ruchu generowanego przez Generator B, związane z nim informacje powinny być przekazywane do Konsumenta B. Liczby na rysunku wskazują numery portów przełączników. W tym przykładzie, gdy ruch z Generatora B osiągnie wartość Switch no. 1, kontroler kontaktuje się za pomocą protokołu OpenFlow. Kontroler, dzięki wstępnie skonfigurowanej wiedzy o topologii sieci, jest w stanie określić, że ostatecznym miejscem docelowym dla tego rodzaju ruchu powinien być Konsument B, a nie Konsument A. W ten sposób generuje zestaw poleceń OpenFlow, w kierunku zarówno Przełącznika 1, jak i Przełącznik 2. W pierwszym przypadku sterownik konfiguruje przełącznik za pomocą oprogramowania, aby dodać wirtualny znacznik do wszystkich pakietów o pochodzeniu w Generatorze B. W tym drugim sterownik konfiguruje Przełącznik 2, instruując, że wszystkie pakiety z takim znacznikiem osiągną numer portu 12 należy przekazać do portu numer 8 (zamiast domyślnej zasady wysyłania całego ruchu do portu nr 6). W ten sposób różne mechanizmy sieciowe (tj. Routing, przekazywanie, kontrola dostępu) są konfigurowalne przez kontroler w sieci, obsługując dynamiczne korekty topologii sieci i rekonfigurację. Ponadto ewolucja infrastruktury staje się procesem uproszczonym, ponieważ ręczna rekonfiguracja sieci nie jest już wymagana, jak również łagodzi integrację złożonych procedur obsługi sprzętu. W związku z tym infrastruktura może ewoluować łatwiej przy użyciu ujednoliconej abstrakcji, a także przystosować się do nowych środowisk sieciowych, dzięki powstaniu nowych mechanizmów sieciowych, takich jak Cloud Computing, Internet rzeczy i inne. Ze względu na swój charakter oprogramowania pojawiły się obawy i wątpliwości dotyczące aspektów takich jak skalowalność. Niemniej jednak oceny wykazały, że problemy ze skalowalnością nie są wynikiem samej architektury SDN, co pozwala na rozwiązanie problemów przy jednoczesnym zachowaniu zalet architektury SDN. Dodatkowa elastyczność zapewniona przez jego projekt, jego główny kluczowy atrybut, pozwala sieciom na utrzymanie wydajności przesyłania i wysokiej dynamiki dzięki konfiguracji w locie i wysokiej wydajności dzięki zoptymalizowanemu routingowi i redukcji kosztów. Aspekty te przyciągnęły uwagę nie tylko producentów, ale także operatorów, a nawet centrów danych (np. Google). Niemniej jednak głównym zastosowaniem w ostatnich latach był mechanizm wspierający wielkoskalowe federacyjne urządzenia testowe do badań, wzmacnianie wysiłków, takich jak projekt badawczy OFELIA, GENI (globalne środowisko dla innowacji sieciowych) i sieć testowa nowej generacji JGN- X w Japonii. Wdrożenie środowisk opartych na SDN zostało ponownie wdrożone w postaci implementacji OpenFlow OpenFlow. Pierwotnie zaprojektowany do celów badawczych, pozwalający na testowanie nowych protokołów w rzeczywistych sieciach produkcyjnych, obecnie OpenFlow można znaleźć w wielu produktach komercyjnych. Sieci wyposażone w to oprogramowanie składają się z przełączników OpenFlow i kontrolerów OpenFlow. Ten pierwszy integruje możliwości SDN z przełącznikami, sterowanymi przez API OpenFlow. Ten ostatni używa tego samego API do sterowania przełącznikami OpenFlow pod względem tworzenia i utrzymywania przepływów. Konkretny przykład zastosowania przedstawiono na rysunku,



gdzie OpenFlow jest używany do przechwytywania lub wstrzykiwania wiadomości uwierzytelniających 802.1X, pozwalając kontrolerowi (przy pomocy określonej logiki aplikacji) działać jako 802.1X Authenticator i Radius Client, w sposób specyficzny dla użytkownika. Koncepcje SDN napędzają jednocześnie różne obszary sieciowe i biznesowe, umożliwiając im niezbędną elastyczność w zakresie konfiguracji i kontroli, zapewniając jednocześnie inspirację dla nowych scenariuszy. Na przykład aspekty SDN zaczęły kształtować operacyjny rdzeń aspektów Cloud Computing poprzez integrację protokołu OpenFlow z oprogramowaniem Cloud Computing, takim jak OpenStack. W tym przypadku dynamiczne możliwości oferowane przez OpenFlow API są wykorzystywane do obsługi aspektów sieci wirtualizacji, abstrahowania aplikacji specyficznych dla sieci i obniżenia kosztów operacyjnych przełączania sieci. Inne kierunki badań to także wykorzystanie mechanizmów SDN, które tradycyjnie są stosowane w sieciach z rdzeniem stałym, w sieciach bezprzewodowych, zarówno w sieciach operatorów komórkowych, jak i sieciach WLAN i Mesh. Wreszcie trwają prace, w których SDN jest podstawą nowatorskich przekształceń warstwy sieciowej. Jednak scentralizowany charakter mechanizmów kontrolnych, jak również trudna trakcja przy wdrażaniu SDN w przełączaniu producentów, w połączeniu z istnieniem różnych wersji protokołu OpenFlow obsługiwanych na różnych urządzeniach, utrudniają wysiłki wdrożeniowe i wymagają bardziej płynnej integracji awanse.

Wirtualizacja funkcji sieciowych

W NFV świadczenie usług przechowywania, przetwarzania i obsługi przez sieć wykracza poza to, co jest zwykle oferowane w Cloud Computing, i faktycznie pozwala na dostarczanie wirtualnych funkcji sieciowych w krawędzi sieci, dzieląc aspekty Network-as-a-a-Service ( NaaS). W związku z tym techniki wirtualizacji umożliwiają wdrożenie funkcji sieciowych w oprogramowaniu, które może działać niezależnie od podstawowego sprzętu serwerowego, jak opisano na rysunku



W tym przykładzie operator sieci zapewnia funkcję zwirtualizowaną (np. Serwer aplikacji) klientowi (np. Dostawcy usług). Aby operować takim scenariuszem w podejściu NFV, operator wykorzystuje swoje podstawowe zasoby sieci, przetwarzania i pamięci w tak zwanej warstwie zasobów fizycznych. Ta warstwa stanowi bardziej związane ze sprzętem aspekty udostępniania funkcji przez operatora. Jednak w tej warstwie zasoby te pojawiają się jako surowe agregaty elementów obliczeniowych i sieciowych. Korzystając z interfejsów rezerwacji, można zażądać tych zasobów za pośrednictwem środowiska wykonawczego wirtualizacji i zarezerwować na sprzęcie. Ta warstwa, nazwana Warstwą Wirtualnego Substratu, jest w stanie zastosować kolejność logiczną dla różnych zasobów sprzętowych, udostępnioną przez Warstwę Zasobów Fizycznych. W ten sposób takie zasoby można logicznie agregować w jedną lub kilka maszyn wirtualnych (tj. Komponując wirtualny typ elementu obliczeniowego, w którym funkcje mogą być przechowywane i obsługiwane), a także sieci wirtualne (tj. Zapewniając niezbędną strukturalną łączność dla maszyn wirtualnych, biorąc pod uwagę różne polityki routingu i biznesowe). Ten poziom zwirtualizowanych zasobów zapewnia ponadto interfejs wirtualizacji, umożliwiający wdrażanie różnych wirtualizowanych funkcji w tzw. Sieciowej funkcji wirtualizacji. W związku z tym podstawowy sprzęt dostarczany przez operatora może zostać zwirtualizowany w logiczną strukturę, zarówno pod względem sieci, jak i przetwarzania, w której można wirtualizować różne usługi i funkcje. W ten sposób rzeczywiste podmioty działające w sieci mogą być wirtualizowane w wielu wersjach i na wiele sposobów, umożliwiając szybkie skalowanie usług i funkcji zgodnie z wymaganiami, przy jednoczesnym zmniejszeniu dojrzewania i czasu do wprowadzenia na rynek dzięki obniżkom Capex. W rezultacie pokonywane są bariery związane z zastrzeżonym sprzętem, co znacznie upraszcza wdrażanie nowych usług sieciowych. Aby jeszcze bardziej pomóc w konsolidacji tego poglądu, ETSI stworzyło NFV Industry Specification Group, co zaowocowało stworzeniem pięciu specyfikacji (tj. Przypadków użycia, ram architektonicznych, terminologii, wymagań wirtualizacji i dowodów koncepcji), a także wcześniejszej białej księgi identyfikującej główne korzyści i punkty odniesienia [ W tym kontekście wspierająca rola mechanizmów SDN we wdrożeniach NFV jest wyraźnie określona jako wsparcie dla usprawnienia integracji różnych rodzajów sieci przełączających i kontrolowania ich zachowań związanych z przekazywaniem poprzez wykorzystanie specyfikacji abstrakcji zdefiniowanych przez oprogramowanie. W ten sposób, jak pokazano na rysunku



Zasoby sieciowe są budowane jako reprezentacje działające na warstwie zwirtualizowanej zapewniane przez zasoby sprzętowe w fizycznych lokalizacjach. Pozwala to na większą elastyczność wdrażania i działania sieci, umożliwiając dodawanie lub usuwanie usług (które również mogą być same w sobie infrastrukturą i mechanizmami sieciowymi) na żądanie.

Ten wstępny etap specyfikacji, oparty na zainteresowaniu wielu stron, motywuje do opracowania genialnych nowatorskich wyników badań, takich jak przyjęcie mechanizmów NFV w architekturach operatorów mobilnych. Jednak prawdziwa siła tej inicjatywy polega na przełomowych możliwościach, co przekłada się na nowe możliwości współpracy biznesowej i współpracy z przewoźnikami, a także na zwiększenie możliwości współpracy między sektorami IT i telekomunikacyjnym. Na przykład interakcja (zarówno w zakresie federacji, jak i polityk między domenami) między różnymi dostawcami NFV będzie musiała dodać dodatkową warstwę złożoności w stosunku do ogólnego projektu NFV, który może nie być łatwy do wdrożenia w istniejących modelach biznesowych.

Mobilność

Obecny Internet jest ograniczony pod względem mobilności usług, ponieważ architektura internetowa nie uwzględniła skutecznie dostępu mobilnego. Jednak znaczenie mobilności staje się coraz bardziej wyraźne, ponieważ inteligentne urządzenia są wypełniane zaawansowanymi funkcjami przetwarzania procesorów mobilnych i funkcjami wielomodowymi, aby wspierać interoperacyjność w szerokim zakresie technologii heterogenicznego dostępu, takich jak 3G / LTE i WiMAX, a także WiFi. Wyzwaniem dla wsparcia mobilności w obecnym projekcie internetowym jest sposób obsługi adresowania IP, a wiele wysiłków badawczych zmierzających do rozwiązania tego dylematu opierało się głównie na dwóch podejściach: z jednej strony, aby rozszerzyć architekturę Internetu poprzez wprowadzenie nowych jednostek wsparcia mobilności i protokoły graniczące bardziej z podejściem ewolucyjnym; z drugiej strony, aby przebudować paradygmat sieciowy, przyjmując podejście czysto-łupkowe. Pierwszy z nich koncentruje się na zapewnieniu realistycznych i odpowiednich rozwiązań w zakresie mobilności w obecnej architekturze Internetu, tak aby zbliżyć się do wykorzystania na rynku, podczas gdy ten drugi stara się skupić na rozwiązaniu fundamentalnego problemu wynikającego z obecnej architektury internetowej, z nowym paradygmatem. Jednak oba podejścia projektowe zmierzają w kierunku Internetu 5G, ale grają na różnych poziomach.

Podejście ewolucyjne z bieżącego Internetu

W tym podejściu dobrze znanym rozwiązaniem jest Mobile IPv6 (MIPv6), który wprowadza agenta macierzystego (HA) do zarządzania informacjami o powiązaniach między węzłem mobilnym (MN) a adresem macierzystym (HoA) i opieką nad adresami ( CoA). MIPv6 przedstawił przełomowy sposób rozszerzenia architektury Internetu na wsparcie mobilności. Aby wyeliminować zaangażowanie gospodarza w aktualizację mobilności, Proxy Mobile IPv6 (PMIPv6) pojawił się z koncepcją zarządzania mobilnością opartą na sieci, wykazując doskonałą wydajność mobilności i przyjęty w kilku organach normalizacyjnych. Badania nad rozszerzeniem oparte na PMIPv6 są obecnie kontynuowane w celu zwiększenia jakości usług użytkownika podczas mobilnego. Obecnie tendencja badawcza w zakresie mobilności IP zmienia się w kierunku projektowania mobilności opartej na płaskiej zasadzie, zwracając uwagę na problemy wprowadzone przez podejście do zarządzania mobilnością scentralizowaną (CMM), na którym zbudowano MIP i PMIPv6. CMM definiuje się tak, aby korzystała z centralnie rozmieszczonych kotwic mobilności, gdzie ogromny ruch MN w sieci operatora jest zarządzany przez tę samą kotwicę. Powoduje to poważne problemy z wydajnością, takie jak pojedynczy punkt awarii spowodowany nadmiernym obciążeniem przetwarzania, nieoptymalny routing przez zawsze podróżowanie przez punkt kontrolny i niepotrzebne rezerwowanie zasobów w celu ustanowienia i utrzymania tuneli IP dla MN, nawet nie mobilne. Pomysł dotyczący wyżej wymienionych problemów logicznie czyni obecną architekturę komórki "bardziej płaską", zasadniczo zmniejszająca obciążenie ruchem i umożliwiająca niezawodne działanie sieci, a także poprawiająca wrażenia użytkownika podczas przemieszczania się. Pomysł ten podzielony jest na dwa kierunki technologiczne: pierwszym podejściem jest wykorzystanie wewnętrznego protokołu routingu IP, na przykład Border Gateway Protocol (BGP), który aktualizuje ścieżkę routingu poprzez reklamowanie nowo przypisanego adresu IP dołączonego MN; drugie podejście polega na rozłożeniu funkcji kotwiczenia mobilności na krawędzie. W pierwszym przypadku osiągalność MN jest zapewniona podczas przebywania w domenie bez użycia zakotwiczenia mobilności. Jednak wydajność przełączania zależy od operacji routingu, więc na opóźnienie przełączania ma wpływ czas konwergencji routingu wewnątrz domeny, a częste aktualizacje routingu wprowadzają burzę rozgłoszeniową w domenie, jak wskazano w odnośniku. Jeśli chodzi o to drugie podejście, przedstawiono wiele propozycji i ponownie można sklasyfikować rozwiązania za pomocą częściowo rozproszonych i w pełni rozproszonych modeli, jak pokazano na rysunku, w zależności od tego, czy płaszczyzna sterowania jest dystrybuowana w celu uzyskania profilu mobilności MN, czy nie



Zbadano rozproszoną architekturę mobilną i metody aplikacji oparte na rozproszonym zarządzaniu mobilnością (DMM) - zaproponowane przez IETF DMM WG (grupa robocza ds. Rozproszonego zarządzania mobilnością w Internet Engineering Task Force) - koncepcja była głównie analizowana w projektach finansowanych przez UE 7PR, takich jak MEDIEVAL (Transport multimedialny dla mobilnych aplikacji wideo) i MEVICO (Ewolucja sieci mobilnych dla doświadczenia w komunikacji indywidualnej). W MEDIEVAL, rozproszona architektura mobilna została zaprojektowana przy wsparciu między warstwami, szczególnie skupiając się na skutecznym dostarczaniu wideo z interaktywnymi transmisjami wideo i osobistymi, itd. W MEVICO, rozproszona architektura mobilności dostosowana do Projektu Partnerskiego 3rd Generation (3GPP) Evolved Packet System (EPS) został omówiony i zaprezentowany w synergii z inteligentnym sterowaniem ruchem, z uwzględnieniem przeniesienia PDN GW (Packet Data Network Gateway) lub P-GW, jako opcja osiągnięcia optymalnego routingu w prezentowanej architekturze. Dla znormalizowanej architektury IETF DMM WG zakończył definiowanie wymagań dla DMM i badanie analizy luk w istniejących protokołach mobilności IP z wymienionymi wymaganiami. Wszelkie dalsze rozwiązania będą oparte na wynikach analizy luk. Aby pokazać dowód koncepcji wpływu ruchu rozproszonego na sieci DMM, przeprowadziliśmy symulację danej topologii sieci przy użyciu Matlab. Proxy Mobile IPv6 (PMIPv6) jest porównywany jako docelowy protokół mobilności IP zgodnie z podejściem CMM. Rysunek pokazuje topologię sieci zastosowana w naszej symulacji.

Pokazane węzły reprezentują routery wykonujące zarządzanie mobilnością zdefiniowane odpowiednio przez DMM i PMIPv6. Nazywamy routerami węzłów rozróżnienie od węzłów mobilnych lub węzłów korespondencyjnych. Bardzo ważne jest, aby mieć topologię do badania obciążenia sieci nałożonego na mobilne sieci szkieletowe. Dana topologia dobrze radzi sobie z bardzo gęstym środowiskiem mobilnym, w którym użytkownicy są bardzo zatłoczeni przez stan mobilny i są otoczone przez wiele budynków składających się z dużej liczby mikrokomórek. Dla PMIPv6, MAG (mobilne bramy dostępu) są umieszczone na krawędziach (od 1 do 8), a LMA (lokalna kotwica mobilności) (węzeł 9) jest umieszczony w centrum topologii, podczas gdy DMM zabiera wszystkie routery brzegowe jako mobilność kotwice, które są nazywane Rozproszonym Ruterem Mobilności (DMR) z węzła 1 do węzła 9. W celu uczciwego porównania pod względem wpływu routingu mobilności, węzeł 9 jest używany do zwykłego celu routingu pakietów IP. CN znajdują się na dowolnych routerach krawędziowych. Linie przerywane pokazują wszystkie dostępne ścieżki routingu do wysyłania pakietów między routerami. Jednak pakiety są przesyłane z najkrótszą ścieżką routingu między routerami brzegowymi MN i CN. Przykłady dostarczania pakietów dla PMIPv6 i DMM są następujące. CN i MN są dołączone odpowiednio do routerów 1 i 4, a MN przechodzi do routerów 5, a następnie 6. W PMIPv6 pakiet wysłany przez CN przechodzi przez routery 1 → 9 → 4, więc gdy MN porusza się do routera 5, ścieżka routingu zostanie zmieniona w ten sposób, 1 → 9 → 5. W DMM pakiet wysłany przez CN jest kierowany bezpośrednio z routerów 1 do 4 (1 → 4) przez regularny routing IP. Gdy MN przejdzie do routera 5, pakiet przejdzie przez routery 1 → 4 → 5. Z symulowanej operacji routingu w topologii zmierzyliśmy liczby zakotwiczonych pakietów i niepotwierdzonych pakietów, w których nie zakotwiczone pakiety są zdefiniowane jako pakiety dostarczane przez regularny routing IP, nie opierając się na punkcie kontrolnym mobilności. W naszej symulacji modelowanie matematyczne jest częściowo wykorzystywane do modelowania efektu dłuższego routingu, ponieważ węzeł MN oddala się bardziej od swojej kotwicy, co powinno zostać uwzględnione w rozwiązaniu zarządzania mobilnością opartym na kotwicy poprzez umieszczenie innego współczynnika wagi na ścieżkach routingu . Więcej szczegółów dotyczących ustawień symulacji i modelu kosztów zdefiniowanych można znaleźć w. Następujące wartości parametrów z literatury są używane domyślnie w symulacji; rozmiar pakietu wynosi 1500 bajtów, całkowita liczba CN wynosi 10, a szybkość odbioru pakietu w sesji jest ustawiona na 200 (pkt / s). Koszt dostarczenia pakietu jest wyrażony jako iloczyn długości wiadomości i odległości przeskoku routingu, a następnie jednostka wynosi KB × chmiel. Średni czas przebywania MN wynosi 600 sekund, a średni czas trwania sesji MN to 360 sekund. Wyniki uzyskuje się średnio z 10 000 przebiegów symulacji. Stosunek zakotwiczonych pakietów jest uzyskiwany jako liczba zakotwiczonych pakietów w stosunku do całkowitej liczby pakietów kierowanych lub przetwarzanych w węźle. PMIPv6 umożliwia lokalne trasowanie MAG dla końcowych terminali mobilnych, gdzie są one połączone z tym samym MAG. Gdy dwa terminale mobilne są pod tym samym MAG pod lokalnym routingiem MAG włączonym przez sieć PMIPv6, pakiet wysłany przez MN nie przechodzi przez LMA, ale jest przesyłany lokalnie. Tak więc wszystkie niepotwierdzone pakiety uzyskane w PMIPv6 są zliczane przez lokalny routing MAG PMIPv6. Liczba niepotwierdzonych pakietów (wynikających z lokalnego routingu MAG w PMIPv6) jest agregowana i wyświetlana na pozycji routera 9, aby zapewnić lepsze porównanie wizualne w wyrażaniu stosunku pakietów niepotwierdzonych przez badanie wszystkich routerów z perspektywy kotwicy. W DMM nie zakotwiczone pakiety są zliczane, gdy MN pozostaje na routerze kotwiczącym każdej sesji, z którą związany jest MN. Stosunek pakietów zakotwiczonych waha się od 0,035 do 0,066 we wszystkich DMR, podczas gdy stosunek wynosi 0,8768 na pojedynczej LMA w PMIPv6. Biorąc pod uwagę, że liczba routerów zakotwiczonych w DMM wynosi 8, możemy po prostu wyobrazić sobie, że stosunek kosztu zakotwiczonego pakietu na pojedynczym DMR byłby 0,1096 średnio (po prostu dzieląc 0,8768 przez 8). Jednak stosunek pakietów zakotwiczonych w każdym DMR w DMM jest 13 do 25 razy niższy niż stosunek na LMA w PMIPv6. Ta poprawa w zmniejszaniu liczby zakotwiczeń pakietów jest wynikiem większej liczby niepotwierdzonych pakietów w porównaniu z zakotwiczonymi pakietami w DMR. To pokazuje, że DMM ma duży wpływ na zmniejszenie zakotwiczenia pakietu dzięki dynamicznemu kotwiczeniu mobilności. Ponadto pokazuje, że stosunek pakietów zakotwiczonych jest siedmiokrotnie większy niż współczynnik niezakotwiczonego kosztu pakietu w PMIPv6, mimo że routing lokalny MAG jest włączony. Pośrednio pokazuje, że lokalny routing MAG PMIPv6 na scentralizowanym podejściu do mobilności nie jest tak skalowalny w redukcji kosztów kotwiczenia jak DMM. Zwiększenie czasu przebywania oznacza, że MN porusza się z niższym wskaźnikiem mobilności. W PMIPv6 liczba zakotwiczonych pakietów i niepotwierdzonych pakietów nie zmienia się znacząco w podanym zakresie średniego czasu pobytu, podczas gdy w DMM liczba zakotwiczonych pakietów stopniowo maleje, a liczba niezakotwiczonych pakietów wzrasta. Dzieje się tak, ponieważ MN spędzał więcej czasu na routerach, gdzie odległości trasowania są stosunkowo krótsze od kotwic, co prowadzi do wyższego średniego czasu przebywania i zmniejszonej liczby przekazań.

Podejście "czysto-łupkowe"

Ewolucyjne podejście z obecnego Internetu opiera się na stylu "łatania", co powoduje rozszerzenie funkcjonalne na żądanie o nowe usługi lub technologie dostępu. To dodaje potknięcia blokujące obecną architekturę Internetu, co utrudnia innowacje i zrównoważony rozwój usług internetowych. Z tego powodu podejście "czystego łupu" jest znacznie uwzględniane i przyjmowane w różnych przyszłych internetowych projektach badawczych. Future Internet (FI) ogólnie uważa, że kwestie mobilności oraz ogólne wyzwania związane z Internetem są rozwiązywane. Istnieje wiele projektów FI opartych na podejściu "czystego łupu", ale skupiamy się na projektach ukierunkowanych na mobilność, krótko wprowadzając główne zasady projektów w zakresie wsparcia mobilności. MobilityFirst został przeprowadzony w Stanach Zjednoczonych w ramach przyszłych badań nad architekturą internetową, szczególnie ze względu na fakt, że obecny Internet jest przeznaczony do łączenia stałych punktów końcowych. MobilityFirst rozważa mobilność urządzeń, treści i sieci. MobilityFirst integruje domeny sieci heterogenicznej, takie jak sieć Ad-hoc i sieć opóźniająca opóźnienia (DTN), które mogą być również zapewnione dla płynnej mobilności. Zgodnie z podstawowymi zasadami MobilityFirst proponuje podejście routingu hybrydowego ID-LOC, które jest stosowane adaptacyjnie, w zależności od dynamiki sieci. Podejście to ma zasadniczo charakter LOC, aczkolwiek istnieje nieodłączna możliwość wykonywania routingu opartego na ID, również z powodu pewnej zmiany topologii sieci. MobilityFirst dodaje możliwości przechowywania do routerów. Za pomocą funkcji routera proponowany jest protokół routingu z pamięcią masową (STAR) i segmentowy transport hop-by-hop, który rozwiązuje problemy z dostarczaniem danych z podejścia opartego na hostingu zorientowanego na końcowy model komunikacji i ostatecznie zapewnia lepszą QoE użytkownika. 4WARD - europejski projekt badawczy 7PR - przedstawił nowy paradygmat o nazwie "Sieć informacji", w którym obiekty informacyjne nie są związane z komunikacją opartą na hostach. Części badawcze składają się z wirtualizacji sieci (VNet), zarządzania siecią (INM), sieci informacji (NetInf) oraz przekazywania i multipleksowania dla ścieżki ogólnej (ForMux). W szczególności, w odniesieniu do wsparcia mobilności, ForMux zaproponował zakotwiczenie dynamicznej mobilności (DMA), mobilność bez zakotwiczenia (AM) i wielopoziomowe End-to?End Mobility (MEEM), które są projektowane indywidualnie dla sesji krótkotrwałych, ruchu multiemisji i ruchu "koniec do końca" w czasie rzeczywistym za pośrednictwem heterogenicznych technologii. DMA opiera się na pełnej dystrybucji funkcji wspierających mobilność między węzłami dostępowymi (AN) i terminalami, co może być podobne do koncepcji zarządzania rozproszoną mobilnością, o której mowa w sekcji 2.5.1. Gdy terminal z wieloma interfejsami porusza się w sieci heterogenicznej, jego przepływy ruchu są zakotwiczone na początkowej obsługującej sieci AN, która następnie zapewnia niezbędne pośrednie połączenia z AN, do których terminal jest obecnie podłączony. AM używa różnych adresów dla lokalizacji i identyfikatorów hostów w sieci oraz właściwego schematu adresowania i nazewnictwa, który implementuje podział lokalizatora / identyfikatora przez użycie różnych punktów końcowych (EP). Główną zasadą jest komunikowanie się między EP wzajemnie poprzez zdefiniowaną funkcję bindowania. Gdy pojawia się ruchliwość, ustanawiane jest nowe wiązanie, czyli wiązanie między EP2 i EP5 . W porównaniu z metodami tunelowania dostarczanymi przez różne protokoły mobilności, takie jak MIP i PMIPv6, koncepcja AM umożliwia lokalny routing, a tym samym prowadzi do zmniejszenia opóźnienia transmisji i mniejszego wykorzystania przepustowości. MEEM to mechanizm zarządzania mobilnością zdefiniowany w architekturze Generic Path (GP), w której mobilność jest obsługiwana przez terminale wielopunktowe. Terminale mobilne wyposażone w multi-interfejs mogą jednocześnie łączyć się z różnymi sieciami za pomocą kilku interfejsów. Dlatego też końcowy GP składa się z kilku sub-GP-GP. Mobilność związana z tymi interfejsami jest obsługiwana w sposób kompleksowy, wykorzystując multi-homing. Gdy mobilność odbywa się za pośrednictwem interfejsu, bezproblemowe przekazanie można łatwo osiągnąć, przełączając ruch na wtórny interfejs przed przekazaniem, a następnie z powrotem do początkowego interfejsu. Inne projekty badawcze oparte na czystym podejściu do mobilności przeprowadzono w następujący sposób. Kontynuując projekt 4WARD, projekt Scalable and Adaptive Internet Solutions (SAIL) bada dostępny projekt przyszłej architektury Internetu i daje sposoby ułatwienia płynnego przejścia z obecnego Internetu, więc nie jest to w pełni tzw. podejście "czystej łupki". Mobilność hosta zapewnia proponowany system NRS (Name Resolution System) do mapowania nazw obiektów na lokalizatory i utrzymywania informacji topologicznych dla hostów. Gdy występuje mobilność, MN aktualizuje swoje informacje topologiczne do lokalnego NRS w pobliżu swojej lokalizacji. Projekt MOFI (Mobile ? Oriented Future Internet) [90], realizowany w Korei Południowej, przyjmuje rozproszony system mapowania ID-LOC i proponuje globalną komunikację opartą na ID oraz lokalny routing oparty na LOC w domenie lokalnej. Proponuje także pierwszy pakiet zapytań transmisji dla zoptymalizowanej komunikacji ścieżki. W Japonii projekt AKARI ma na celu wdrożenie podstawowej technologii sieci nowej generacji do roku 2015. Główna zasada projektowania AKARI opiera się na oddzielnych strukturach fizycznych i logicznych w systemie adresowania do obsługi mobilności.

Kontrola jakości usług

Tradycyjnie Internet traktuje cały ruch w jednakowy sposób, czyli bez żadnej gwarancji QoS pod względem przepustowości, opóźnienia, jittera i utraty pakietów. Jednak niektóre aplikacje (np. Wideo i audio) mają bardziej rygorystyczne wymagania QoS niż inne (np. Dane). Dlatego głównym celem kontroli QoS jest zdefiniowanie narzędzi i technik zapewniających przewidywalne, mierzalne i zróżnicowane gwarancje jakości dla aplikacji w oparciu o ich charakterystykę i wymagania, zapewniając wystarczające zasoby (przepustowość) i kontrolując opóźnienia pakietów, fluktuacje i parametry strat.

Dostarczanie zasobów sieciowych

Korelacje między ścieżkami komunikacji a współdzieleniem zasobów narzuconym przez konwergencję sieci są głównymi wyzwaniami, które należy starannie uwzględnić, aby włączyć QoS w Internecie. Mówi się, że dwie ścieżki są skorelowane, gdy zdarzają się, że dzielą co najmniej jeden interfejs wychodzący na węźle w sieci. Rysunek poniższy służy do ułatwienia zrozumienia tych problemów poprzez przedstawienie głównej sieci dostawcy usług internetowych (ISP) składającej się z trzech routerów wewnętrznych (IR), trzech routerów Egress (ER) i siedmiu rdzeni routerów (Cs).

W tym przykładzie łącze L3 między C3 i C4 jest współdzielone przez ścieżki 2, 5 i 6 (trzy skorelowane ścieżki), pochodzące z różnych węzłów wejściowych, odpowiednio IR1, IR2 i IR3. Jako takie, strumienie ruchu, które mogą być mapowane do tych ścieżek, muszą mieć trudności z uzyskaniem zasobu (np. Przepustowości), którego potrzebują na współdzielonym łączu (linkach) / interfejsie (interfejsach) wzdłuż ścieżek. Z tego powodu rezerwacja zasobów i kontrola dostępu były badane od wielu lat jako podstawowe funkcje w projektach kontroli sieci, mające na celu umożliwienie Internetowi obsługi QoS. IETF opracował zintegrowane usługi (IntServ) , architekturę kontroli QoS, aby zapewnić kompleksową obsługę QoS dla każdej usługi indywidualnie przez Internet. IntServ gwarantuje QoS dla każdego przepływu przez jawne rezerwowanie (np. Poprzez konfigurację programów planujących) ilości zasobów wymaganych przez przepływ w każdym węźle na ścieżce, którą przepływ będzie przenosił ze źródła do miejsca przeznaczenia. Operacje zwykle opierają się na sygnalizacji RSVP (Resource Reservation Protocol), jak opisano szczegółowo w odnośniku. Ilekroć żądanie usługi jest odbierane w architekturze z obsługą IntServ, sieć jest najpierw sygnalizowana do sondowania (sondowania zdarzeń) dostępnych zasobów. Następnie, w przypadku wystarczającej ilości dostępnego zasobu, sieć jest ponownie sygnalizowana, więc wymagany zasób jest zarezerwowany (zdarzenia rezerwacji), a stany powiązane są utrzymywane na wszystkich węzłach na odpowiedniej ścieżce komunikacyjnej. Ponadto rezerwacja jest zwalniana (zdarzenia zwalniające) po sygnalizacji, gdy odpowiednia sesja zakończy się. W ten sposób stany kontrolne i operacje sygnalizacyjne są wykonywane na zasadzie przepływu, a podejście zostało poważnie skrytykowane z powodu braku skalowalności. Jako alternatywa dla IntServ, IETF wprowadził usługę Differentiated Service (DiffServ), jako standard architektury QoS oparty na klasie usług (CoS) dla Internetu. W DiffServ, znanym również jako podejście agregacyjne, węzły krawędziowe sieci lub stacje centralne (np. Brokerzy przepustowości) są zwykle używane do utrzymywania stanów ruchu na przepływ i klasyfikowania przepływów do ograniczonej liczby CoS zgodnie z wcześniej zdefiniowanymi zasadami, takimi jak, ale nie ogranicza się do QoS, protokołów i typów aplikacji. Ponieważ przepływy są klasyfikowane do CoS, węzły rdzeń / wnętrze mogą utrzymywać stany i przetwarzać je na CoS, a nie na przepływ. Główną ideą jest przesunięcie złożoności sterowania IntServ i obciążenia na krawędź sieci dla skalowalności. Ponadto DiffServ implementuje statyczną rezerwację zasobów, przy czym każdemu CoS w interfejsie przypisany jest stały procent pojemności interfejsu. Innymi słowy, rezerwacje nie są regulowane dynamicznie w czasie działania sieci. Narzut sygnalizacji RSVP został również usunięty z DiffServ. Chociaż rezerwacja zasobów statycznych jeszcze bardziej zwiększa skalowalność, nie optymalizuje wykorzystania sieci, ponieważ wymagania ruchu są dynamiczne i w większości nieprzewidywalne. W związku z tym rezerwację zasobów należy przeprowadzać dynamicznie, uwzględniając bieżące warunki zasobów sieci i zmieniające się wymagania ruchu, aby poprawić wykorzystanie zasobów. Z tego powodu dynamiczne mechanizmy kontroli QoS zostały przywrócone do DiffServ, jak opisano w dalszej części.

Łączne udostępnianie zasobów

W społeczności badawczej argumentuje się, że łączne dostarczanie zasobów napędzane przez sygnalizację perflow w celu zwiększenia lub zwolnienia rezerwacji na CoS na każde żądanie, tak jak w przypadku odniesienia, nie jest skalowalne z powodu nadmiernego narzutu sygnalizacji. W tym sensie IETF wprowadził standard protokołu zbiorczej rezerwacji zasobów, rezerwację zasobu ponad rezerwę, aby umożliwić rezerwowanie większej ilości zasobów niż rzeczywiste wymagania CoS, więc kilka zgłoszeń serwisowych może być przetwarzanych bez natychmiastowej sygnalizacji tak długo, jak poprzednia rezerwacja nadwyżka jest wystarczająca do przyjęcia przychodzących żądań. W ten sposób zarówno stany kontroli QoS, jak i narzut sygnalizacji mogą zostać zredukowane ze względu na skalowalność. W tym rozdziale, nazywane również nadmiarowaniem zasobów, od wielu lat badano podejście jako obiecującą metodę osiągnięcia zróżnicowanego QoS w sposób skalowalny. Jednak główne obawy dotyczą wpływu marnotrawstwa zasobów, które może wystąpić w przypadku nieefektywnej redystrybucji zasobów rezydualnych (nadmiernie zarezerwowanych, ale niewykorzystanych) wśród CoS. Pan i in. zaproponowano nadmierną rezerwę nadwyżki przepustowości jako wielokrotność ustalonej liczby całkowitej, a mianowicie "kwantyzacji", i opóźnienia zdarzeń uwalniania zasobów w protokole rezerwacji Gateway Gateway (BGRP) dla przepływów zagregowanych przeznaczonych do określonej domeny - na podstawie Sink-Tree Protokół agregacji. To rozwiązanie nie jest zgodne z zachowaniami dynamicznymi ruchu, a zatem nie może efektywnie wykorzystywać zasobów sieciowych. Sofia i in. zademonstrował również wykorzystanie nadmiernej rezerwy zasobów w celu zmniejszenia narzutu sygnalizacji związanego z protokołem SICAP (ang. Shared-segment-segment). Co ważniejsze, autorzy przeanalizowali wpływ systemów nadmiernej rezerwacji na marnotrawstwo zasobów w szerokim zakresie ustawień i porównań. Głównym ograniczeniem tych podejść (np. BGRP i SICAP) jest brak wiedzy w czasie rzeczywistym na temat statystyk wykorzystania zasobów sieciowych, ponieważ polegają one na okresowych technikach sondowania ścieżki w celu uzyskania informacji o sieci. W konsekwencji rozwiązania te zapobiegają nadmiernemu rezerwowaniu zbyt dużej nadwyżki zasobów w celu zmniejszenia ilości odpadów w cenie większych obciążeń sygnalizacyjnych. Inne propozycje, takie jak prosty protokół sygnalizacji między domenami (SIDSP) i dynamiczna agregacja rezerwacji dla usług internetowych (DARIS) również wykazały ograniczenia pod względem efektywnej redystrybucji zasobów rezydualnych. Pamiętając o wyzwaniach opisanych powyżej, Zagregowana Alokacja Zasobów dla Wielu Użytkowników (MARA) wprowadza zestaw funkcji z dynamiczną redystrybucją zasobów rezydualnych wśród CoS wewnątrz sieci, próbując rozwiązać otwarte problemy. Niemniej jednak MARA opiera się również na okresowych i na żądanie technikach sondowania ścieżek i zapobiega rezerwowaniu zbyt dużej nadwyżki (podobnie jak w SICAP), co nie pozwala na optymalizację redukcji narzutu sygnalizacji, podczas gdy wciąż napotyka się niepożądane marnotrawstwo zasobów. Praca referencyjna proponuje rozwiązanie polegające na nadmiernym zasilaniu i sterowaniu ładunkiem i równowagą, zwane QoS-RRC (Routing i kontrola zasobów), z wykorzystaniem protokołów MARA. Oprócz centralnego serwera o nazwie Fabryka Ścieżek Ogólnych (GP) w rozwiązaniu QoS-RRC, każdy router wejściowy (np. IR) powinien samodzielnie decydować i dostosowywać parametry nadmiaru zasobów niezależnie od łączy współdzielonych przez wszystkie ingresy i nie ma mechanizmu współpracy między routery wejściowe. Jak wspomniano w pracy, chociaż agregacja QoS i Resource Over-Provisioning pozwalają na zmniejszenie nakładów kontroli, jest to dość trudne, ponieważ nieefektywne rozwiązanie powoduje straty, podczas gdy liczba agregatów do utrzymania może być bardzo duża w sieci z wieloma granicami routery jak na rysunku powyżej. Badania i analizy tego kompromisu między redukcją narzutu sygnalizacji a marnotrawstwem zasobów można znaleźć w odnośniku. Ogólnie rzecz biorąc, im więcej zasobów jest nadmiernie zarezerwowanych, tym bardziej prawdopodobne jest zmniejszenie narzutu sygnalizacyjnego, ale z drugiej strony prowadzi do potencjalnie większych strat. W odniesieniu do tych wyzwań, ostatnie odkrycia, takie jak przepustowość w oparciu o rezerwację klasy (COR), twierdzą, że skuteczny mechanizm nadmiernej rezerwy zdecydowanie wymaga odpowiedniej: (i) architektury, aby skutecznie uwzględniać wzorce korelacji ścieżki komunikacyjnej i dynamikę ruchu na ścieżkach ; (iii) algorytmy do obliczania odpowiedniej szerokości pasma w celu zwiększenia rezerwy dla każdego CoS, aby umożliwić optymalizację redukcji narzutu sygnalizacji; (iii) systemy właściwego ponownego wykorzystania pozostałej przepustowości w celu zminimalizowania wpływu odpadów. Dlatego inteligentne udostępnianie zbiorczych zasobów jest bardzo potrzebne, aby skutecznie wspierać konwergencję usług w Internecie 5G. Ma to kluczowe znaczenie ze względu na dużą ilość danych, które będą zaangażowane w komunikację, heterogeniczność charakterystyk ruchu i wymagania terminali użytkowników, a także kontekst użytkowników, taki jak preferencje i lokalizacje. Aby pokazać dowód na wyższość nadmiernej rezerwacji zasobów w stosunku do podejść przepływowych pod względem skalowalności, przeprowadziliśmy symulację przy użyciu topologii sieci przedstawionej na rysunku powyżej i symulatora sieci (ns-2). Dla uproszczenia każdy interfejs sieciowy został skonfigurowany z przepustowością C = 1 Gbps i 4 CoS, na przykład jednym kontrolnym CoS (dla pakietów kontrolnych), jednym przyspieszonym przekazywaniem (EF), jednym Assured Forwarding (AF) i jednym Best-? Effort (BE ), w ramach dyscypliny harmonogramowania Ważona Fair Queuing (WFQ). Ponadto 20 000 żądań sesji należących do trzech różnych typów ruchu, takich jak stała szybkość transmisji bitów (CBR), Pareto i wykładniczy, zostało losowo wygenerowanych i zmapowanych do różnych CoS w oparciu o procesy Poissona. Żądania dotyczące przepustowości ruchu zostały wygenerowane przy użyciu równomiernego rozkładu między 128 Kb / s a 8 Mb / s i zostały zmapowane na pary wejścia-wyjścia w oparciu o procesy Poissona. Aby pokazać bardziej stabilne wyniki, przeprowadziliśmy symulację pięć razy z różnymi nasionami losowego mapowania żądań do CoS. Następnie wykreślono średnie wartości dla wszystkich nasion z przedziałem ufności 95% (dalsze szczegóły dotyczące konfiguracji symulacji są dostępne w odniesieniu). Rysunek powyżej pokazuje, że numery sondowania zasobów i zdarzenia rezerwacji nakładają się, gdy sieć jest mniej zatłoczona (numer żądania poniżej 4000). Niemniej jednak liczba zdarzeń sondowania przekracza rezerwację przepływu, ponieważ liczba żądań wzrasta powyżej 4000. Oznacza to, że dostępność zasobów sieciowych zmniejsza się wraz ze wzrostem liczby aktywnych sesji w sieci, ponieważ niektóre żądania są odrzucane, gdy nie ma wystarczającej liczby zasób gwarantujący wymagane QoS. Po zakończeniu sesji uruchamiana jest odpowiednia sygnalizacja, aby zwolnić powiązane rezerwacje do wykorzystania w przyszłości. Ogólny numer zdarzeń sygnalizacyjnych dla podejścia przepływowego (sondowanie + rezerwacja + zwolnienie) jest również wykreślony na rysunku. Poza wynikami na przepływ, wydajność ponad rezerwacją jest także wykreślony. W związku z tym zauważamy, że skuteczna nadmierna rezerwacja może potencjalnie zmniejszyć liczbę sygnalizacyjną kontroli QoS, a tym samym związany z nią narzut przetwarzania. Co ważniejsze, można zauważyć, że sygnalizacja sterująca nadmierną rezerwacją nie jest wyzwalana, gdy sieć jest mniej zatłoczona, z liczbą żądań sesji poniżej 4000. Rzeczywiście, każdy CoS jest inicjalizowany z pewną ilością nadmiernej rezerwacji, a sygnalizacja jest wywoływany tylko wtedy, gdy nadmiernie zarezerwowane parametry zasobów wymagają ponownego dostosowania, aby zapobiec głodowaniu CoS. Zasadniczo nadmierna rezerwacja pozwala na ograniczenie zdarzeń sygnalizacyjnych powyżej 90% w przypadku podejścia "przepływowego", w zależności od poziomu przeciążenia sieci.

Pojawiające się podejście do nadmiernego udostępniania zasobów

Celem tej sekcji jest opisanie ogólnego mechanizmu, który jest w stanie zintegrować SDN i NFV w celu efektywnej kontroli nad rezerwacją zasobów w celu obsługi zróżnicowanego QoS przez Internet 5G bez zbędnej sygnalizacji i związanych z tym kosztów przetwarzania (np. Wymagania procesora, pamięci i energii) lub marnotrawstwo zasobów. W celu ułatwienia zrozumienia. Rysunek poniżej przedstawia scenariusz sieci wielu operatorów obejmujący operatora sieci I, operatora sieci II i inne sieci, wszystkie uważane za chmurę chmur.

Każda sieć stanowi sieć rdzeniową, do której dołączone są różne sieci dostawców dostępu i usług. Na przykład w sieci operatora I sieć rdzeniowa A jest podłączona do sieci dostępowych A (za pośrednictwem routera Customer Edge (CE)), sieci dostępowej B i DC A. Ponieważ jest to szczegółowo opisane w referencjach, technologie wirtualizacji mogą być zastosowane w kontrolerach domeny, aby umożliwić wielu dzierżawcom współużytkowanie tej samej fizycznej infrastruktury DC. Umożliwia także współdzielenie infrastruktury sieciowej z dostępem do rdzenia / sieci szkieletowej i DC. Ponadto ogólna kontrola w sieci każdego operatora jest regulowana za pomocą SDNC znajdującego się w centrum operacji sieciowych. W szczególności SDNC jest odpowiedzialny za udzielanie lub odmawianie dostępu do sieci i powiązanych zasobów w taki sposób, aby zapewnić, że każdy dopuszczony użytkownik otrzyma zakontraktowane QoS. Funkcje SDNC obejmują między innymi równoważenie obciążenia ruchem, aby uniknąć niepotrzebnego występowania przeciążenia w sieci, podczas gdy połączenia między domenami są wykonywane zgodnie z wcześniej zdefiniowanymi umowami o poziomie usług (SLA) między operatorami ze względu na skalowalność. W tym celu SDNC jest włączony do definiowania odpowiednich zasad sterowania i dyktowania egzekwowania elementów transportowych (np. Przełączników i routerów) za pomocą odpowiednich protokołów sygnalizacyjnych (np. Protokołu zgodnego z OpenFlow). Dzięki temu każda aplikacja zostanie skutecznie powstrzymana przed głodem innych aplikacji swoich zasobów w sieci. Włączenie tych funkcji wymaga, aby SDNC utrzymywał dobrą znajomość topologii sieci i powiązanych statystyk zasobów łącza w czasie rzeczywistym w celu ukierunkowania na efektywną wydajność. Dlatego SDNC osadza zestaw komponentów kontrolnych, takich jak, ale nie ograniczając się do: (i) Repozytorium informacji kontrolnych (CIR) jako bazy danych do przechowywania informacji topologicznych sieci i profili użytkowników; (ii) Zasady kontroli dostępu do usług (SACP), jako podmiot odpowiedzialny za definiowanie odpowiednich zasad kontroli i zarządzanie dostępem do zasobów sieciowych; oraz (iii) Network Resource Provisioning (NRP), który można wykorzystać do zaawansowanej alokacji zasobów. Dalsze szczegóły na temat tych komponentów pod względem funkcji i interakcji znajdują się w następnych sekcjach

Repozytorium informacji sterujących

CIR jest wykorzystywany przez SDNC do utrzymania topologii sieci i powiązanych statystyk zasobów łącza, w tym ścieżek komunikacyjnych, które mogą być tworzone w sieci wraz z identyfikatorami wychodzących interfejsów, które należą do ścieżek. Topologia sieci i ścieżki mogą być wstępnie zdefiniowane lub dynamicznie wykrywane lub obliczane w sposób referencyjny. Co więcej, CIR rejestruje całkowitą pojemność każdego interfejsu sieciowego i ilość zarezerwowanej przepustowości i wykorzystywanej w każdym CoS w interfejsie. Ponadto sesje użytkowników mapowane na CoS skonfigurowane w sieci są utrzymywane wraz z powiązanymi informacjami. Informacje o sesji aktywnej obejmują między innymi wymagania QoS sesji (np. Przepustowość, opóźnienie, jitter i utrata pakietów), identyfikator sesji, identyfikatory przepływów składających się na sesję, identyfikator CoS do do której należy sesja, identyfikatory źródłowe i docelowe przepływów (np. IP i Media Access Control - adresy MAC -) oraz identyfikatory portów. Inne informacje o profilu użytkownika, takie jak parametry rozliczeniowe i personalizacyjne, mogą być również przechowywane w CIR. Podsumowując, specyficzna konstrukcja i konfiguracje SDNC zależałyby od preferencji operatorów, które mogą się różnić w zależności od operatora.

Zasady kontroli dostępu do usługi

SACP umożliwia SDNC dopuszczenie lub odmówienie dostępu do usługi sieci poprzez dynamiczne uwzględnienie wymagań QoS żądania usługi przychodzącej (np. Przepustowości) i dostępności zasobów sieciowych możliwych do uzyskania z lokalnej bazy danych CIR. Zapewnia interfejs umożliwiający interakcje z użytkownikami końcowymi w celu odbierania żądań z jednej strony, a także z węzłami sieci (np. Routerami) w celu wysyłania instrukcji sterujących, które mają być egzekwowane w całej sieci, z drugiej strony. Stąd, po przyjęciu, zakończeniu lub ponownym dostosowaniu wymagań QoS sesji w CoS na ścieżce komunikacyjnej, informacje związane z sesją (np. Wykorzystanie zasobów) muszą być aktualizowane w lokalnym CIR w czasie rzeczywistym. W sytuacji, w której nadmierna rezerwacja zasobów jest realizowana w sposób referencyjny, SACP jest w stanie przyjmować, kończyć lub dostosowywać wymagania QoS bez nadmiernego narzutu sygnalizacji lub marnotrawstwa zasobów. Od statystyki sieci wykorzystania zasobów są utrzymywane w czasie rzeczywistym w CIR, informacje mogą być wykorzystane do poprawy funkcji równoważenia obciążenia ruchu w elastyczny sposób bez niepożądanego sondowania ścieżki i związanego z tym narzutu sygnalizacji. Jednak zawsze, gdy nadmierna rezerwacja żądanego CoS zostanie wyczerpana, komponent KPR musi zostać uruchomiony, aby prawidłowo obliczyć nowe parametry rezerwacji w celu ich ponownego dostosowania w ramach CoS na odpowiedniej ścieżce. W ten sposób zasoby rezydualne mogą być dynamicznie ponownie wykorzystywane, aby zapobiec marnotrawstwu, jak szczegółowo opisano w następnej części.

Dostarczanie zasobów sieciowych

Główną rolą komponentu KPR jest określenie ilości zasobów, które mają być rezerwowane, oraz parametrów, takich jak progi rezerwacji, które należy skonfigurować dla każdego CoS na każdym interfejsie w sieci zgodnie z lokalnymi zasadami kontroli. Komponent ten musi być wystarczająco inteligentny, aby umożliwić integrację istniejących algorytmów i zasad rezerwacji poza rezerwacją, tak jak w referencjach, w tym przyszłych algorytmów. Jest to ważne, ponieważ NRP jest wywoływany dynamicznie przez funkcje kontroli dostępu, tak że parametry rezerwacji mogą być ponownie dostosowane na potrzeby zapobiegania nieefektywnemu wykorzystaniu zasobów przy jednoczesnym zmniejszeniu częstotliwości sygnalizacji. Okazuje się, że ten komponent może być również używany do tworzenia i zarządzania deterministycznymi ścieżkami komunikacji wewnątrz sieci (np. Ścieżki przełączania etykiet, jak w Multi-protocol Label Switching - MPLS). Dlatego też, gdy NRP pomyślnie obliczą nowe parametry rezerwacji, SDNC powinien przekazać nowe wymagania konfiguracyjne do danych węzłów na odpowiednich ścieżkach egzekwowania. Zasady kontroli są wymuszane na węzłach za pomocą komponentu CPE (Control Policies Enforcement), który jest szczegółowo opisany w następnej podsekcji.

Funkcje egzekwowania sterowania

Każdy węzeł sieci (np. routery) implementuje zestaw komponentów, podstawowych funkcji sterowania wymaganych we wszystkich węzłach sieci w celu wykonania instrukcji sterujących, które mogą być odbierane z SDNC. Te funkcje obejmują między innymi bazę informacji zarządzania (MIB) i komponenty CPE. Baza MIB oznacza wszystkie starsze bazy danych kontroli, zazwyczaj dostępne we wszystkich węzłach sieci, tj. Bazę informacji o routingu (RIB), bazę informacji o routingu multiemisji (MRIB) oraz bazę informacji o przekazywaniu (FIB) i tabelę OpenFlow. Ponadto CPE wykorzystuje podstawowe funkcje transportowe, aby umożliwić rozpoznawanie portów UDP (routery stale nasłuchują na określonym porcie UDP) lub opcję routera IP (RAO) w węzłach, aby poprawnie przechwytywać, interpretować i przetwarzać komunikaty sterujące. CPE jest odpowiedzialny za interakcję z funkcjami zarządzania zasobami (RMF) w celu prawidłowego skonfigurowania programów planujących w węzłach, zapewniając tym samym, że każdy CoS otrzymuje przydzieloną szerokość pasma. Ponadto łączy się z MIB i starszymi protokołami (np. Protokołami routingu i protokołami zarządzania) na węzłach, aby ponownie wykorzystać istniejące i przyszłe funkcje sieciowe. CPE można również wykorzystać do wymuszenia deterministycznych ścieżek przy użyciu etykiety MPLS lub kanału multiemisji na podstawie instrukcji SDNC. Pomaga także SDNC, wypełniając komunikaty kontrolne odpowiednimi informacjami, umożliwiając na przykład gromadzenie identyfikatorów wychodzących interfejsów i ich pojemności jako obiektu trasy zapisu (RRO) na ścieżkach. Gdy CPE jest wdrożony na granicy sieci, zawiera dodatkowe funkcje do operacji przesyłania i routingu między domenami, które mogą być oparte na danych wejściowych z tradycyjnego BGP. Kontrola ruchu i warunkowanie ruchu (np. Kształtowanie ruchu i nadzorowanie ruchu) muszą być również zapewnione na granicy sieci, aby wymusić, aby dopuszczone strumienie ruchu były zgodne z umowami SLA.

Konfiguracje sieciowe

SDNC jest w stanie dynamicznie odkrywać topologię sieci w miarę uruchamiania nowych węzłów w sieci. Można użyć istniejących mechanizmów wykrywania topologii, importując informacje z protokołów routingu w stanie łącza. Stąd, przyjmując topologię sieci i odpowiedni algorytm (np. Dijkstra) jako dane wejściowe, SDNC jest w stanie obliczyć wszystkie możliwe ścieżki, zwłaszcza ścieżki "od krawędzi do krawędzi" wewnątrz sieci rdzeniowej pod jej kontrolą. Połączenie ścieżek może prowadzić do wszystkich możliwych rozgałęzionych tras, jak w przypadku odniesienia, a najlepsze ścieżki mogą być filtrowane, na przykład w oparciu o liczbę przeskoków lub przepustowości wąskiego gardła. Warto przypomnieć, że wykorzystanie deterministycznych ścieżek jest bardzo ważne dla poprawy kontroli zasobów sieciowych. W naszym przypadku użycia, deterministyczną ścieżkę można uzyskać za pomocą etykiety MPLS lub przypisując unikalny kanał multiemisji (S, G). W tym scenariuszu S (źródło) może być adresem IP wejściowego routera granicznego (BR), z którego pochodzi ścieżka, a G (grupa) może być adresem multiemisji. Po obliczeniu przez SDNC ścieżki i początkowych parametrów nadmiernej rezerwacji dla każdego interfejsu na ścieżce, hermetyzuje informacje w komunikacie sterującym i wysyła je do wszystkich węzłów na ścieżce. Ponieważ komunikat kontrolny przemieszcza się wzdłuż ścieżki, każdy odwiedzany węzeł przechwytuje wiadomość i odpowiednio konfiguruje swoje lokalne interfejsy (np. Tabele OpenFlow, tabele przekazywania / routingu i parametry rezerwacji ponad zasobami).

2.6.6 Operacje sieciowe Operacje sieci na rysunku powyżej są zilustrowane, przy użyciu wykresu sekwencji na rysunku



Ponadto podkreślono korzyści, jakie połączenie SDN i nadmiernej rezerwy zasobów może wnieść do Internetu 5G. W związku z tym, gdy sieć jest inicjalizowana i ustawiana do uruchamiania, każde żądanie usługi musi być przetwarzane przez SDNC. Ma to na celu wykonywanie funkcji, ale nie wyłącznie, uwierzytelniania usług, autoryzacji i rozliczania (AAA), QoS i kontroli dostępu w celu odróżnienia kontroli i umożliwienia optymalnego wykorzystania zasobów sieciowych. Stąd żądanie usługi powinno określać pożądaną QoS (np. Przepustowość, opóźnienie, jitter, utratę pakietów i bufor), preferencje personalizacji usługi i związane z nią charakterystyki ruchu (np. Źródłowy i docelowy adres IP i porty, obsługiwane kodeki itp.) . Ta informacja ma zasadnicze znaczenie dla właściwej negocjacji sesji, gdzie transakcje sterujące mogą być obsługiwane za pomocą protokołu inicjowania sesji - SIP lub dowolnego innego protokołu sygnalizacji (np. Protokołu zgodnego z sygnalizacją następnego kroku (NSIS)) określonego przez operatora. Należy zauważyć, że żądanie usługi może być również wyzwalane przez SDNC, w zależności od trybów operacji specyficznych dla usług i sieci, to znaczy albo trybu ściągania (od strony użytkownika końcowego), albo trybu push (od strony sieci). Aby ułatwić zrozumienie, załóżmy, że użytkownik A chce korzystać z usługi wideo 3D od dostawcy DC B (centrum danych B) w chmurze. W związku z tym użytkownik wydaje żądanie usługi, które jest kierowane do SDNC przez bramę BR1 (krok 1). Żądanie usługi zawiera wymagania QoS użytkownika (np. Przepustowość) i związane z nim charakterystyki ruchu (np. Kodek). W związku z tym, w oparciu o otrzymane informacje, SDNC I wykonuje kontrolę dostępu zgodnie ze wstępnie zdefiniowanymi lokalnymi zasadami sterowania i księguje najlepszą ścieżkę z wystarczającą dostępną szerokością pasma do połączenia bramy BR1 i wyjścia BR3 w kierunku DC B. Jest zatem bardzo ważne, aby zauważ, że SDNC jest w stanie to zrobić bez sondowania ścieżki lub dodatkowej sygnalizacji QoS do sieci, ponieważ zakładamy, że integruje ona rozwiązanie rezerwowania zasobów opisane w odnośniku. W przypadku powodzenia tych operacji serwer przekierowuje żądanie do SDNC II (sieć operatora B), jako kolejną domenę na końcowej ścieżce do DC B. Gdy SDNC II odbiera żądanie, rezerwuje również najlepsza ścieżka (BR5 do BR8) bez dodatkowego narzutu sygnalizacji i sprawdza dostępność żądanej usługi w DC B. Następnie, po otrzymaniu pomyślnej odpowiedzi z DC B, SDNC II wymusza zarezerwowaną ścieżkę poprzez prawidłowe skonfigurowanie routerów granicznych na ścieżce (BR5 i BR8). Przykłady konfiguracji obejmują grupę multiemisji wybranej ścieżki (w domenie z obsługą multiemisji) lub etykietę MPLS (w domenie MPLS) i parametry warunkujące ruch (np. Klasyfikacja, kształtowanie i nadzorowanie). Zapewni to, że przychodzące pakiety multimedialne zostaną poprawnie zamknięte w routerach krawędziowych wejściowych, aby podążać pożądanymi ścieżkami, więc będą cieszyć się zarezerwowanym dla nich QoS. Pakiety są dekapulowane na odpowiednich routerach krawędziowych wyjściowych w celu dostarczenia do użytkownika końcowego lub następującej domeny. Jak wyjaśniliśmy wcześniej, tylko BR są skonfigurowane, ponieważ zakłada się, że rezerwowane zasoby są nadal dostępne na węzłach rdzeń / wnętrze ścieżki. Jak szczegółowo omówiliśmy wcześniej, węzły rdzeniowe są sygnalizowane w celu rekonfiguracji parametrów rezerwacji dopiero po wyczerpaniu rezerwowanego zasobu i nie są wystarczające dla przychodzącego żądania. W ten sposób można nie tylko znacznie zmniejszyć częstotliwość sygnalizacji, ale również skrócić czas konfiguracji sesji. Następnie SDNC II odpowiada na SDNC I, a także wymusza ścieżkę zarezerwowaną dla usługi (patrz krok 7). Wreszcie SDNC I powiadamia użytkownika A o sukcesie operacji (patrz krok 8). W tym samym czasie SDNC I wysyła komunikat potwierdzenia (ACK) do SDNC II, którego wiadomość jest przekazywana do DC B (patrz krok 9) w celu wyzwolenia nośnika streaming. W rezultacie ścieżka koniec-koniec jest budowana w sposób skalowalny jako konkatenacja ścieżek podrzędnych świadomych przepustowości zbudowanych niezależnie w domenach na ścieżce. Ma to ogromne znaczenie, aby umożliwić każdemu operatorowi wdrożenie własnego protokołu kontroli. Jeśli chodzi o kontrolę łączności w sieciach dostępowych przedstawionych w tej sekcji, zakłada się, że każda sieć dostępowa lub DC jest dołączona do sieci rdzeniowej za pomocą odpowiedniej ścieżki pasma zgodnie z umowami SLA między użytkownikami końcowymi a dostawcami usług.

Podsumowanie

Ważnym aspektem jest określenie ram i procedur, które mogą obejmować ogromną liczbę heterogenicznych urządzeń podłączanych do Internetu za pośrednictwem niezliczonej liczby technologii przewodowych i bezprzewodowych. Aspekty łączności muszą być nie tylko ulepszone, aby umożliwić i zoptymalizować sposób obsługi tych połączeń, biorąc pod uwagę specyfikę każdej dostępnej technologii dostępu, ale także sposób, w jaki urządzenia te są połączone przez usługi (i interfejs) (np. Aplikacje sensoryczne linkowanie do czujników) musi być uogólnione. W ten sposób obecne architektury i ramy przechodzą od ograniczonego wdrożenia wertykalnego do bardziej elastycznego wdrożenia poziomego, pozwalając na wdrażanie ich w różnych obszarach i przypadkach użycia, zgodnie z podejściem "zbuduj, używaj wielokrotnie, wielokrotnie". Ponadto złożoność wymuszana nowatorskimi scenariuszami musi uwzględniać dynamikę działania sieci, która obecnie przekształca się w piekło Capex i Opex dla operatorów i dostawców usług. W tym sensie technologie wspomagające, takie jak SDN, umożliwiają działanie sieci kontrolowane w sposób wydajny i dynamiczny, pozwalając sieci reagować na zmiany w sieci, jak również wzmacniając nowatorskie scenariusze eksperymentalne z możliwością odróżnienia ruchu eksperymentalnego od sieci produkcyjnych. Co więcej, takie koncepcje mogą być dodatkowo wzmocnione poprzez ich integrację z aspektami wirtualizacji. W ten sposób podstawowa fizyczna sieć i tkanina przetwarzania operatora mogą być formowane na żądanie w sieci logiczne i przetwarzać węzły emulujące różne funkcje sieciowe w funkcji wirtualizacji funkcji sieciowych. W związku z tym operatorzy mogą łatwo i dynamicznie korzystać z zasobów sieciowych i przetwarzania oraz łatwo wdrażać nowe procedury sieciowe, gdy sieć zmienia się i / lub rośnie. W tym trudnym środowisku przewidzianym na przyszłość Internet nie może zagwarantować użytkownikom jakości usług w zakresie heterogeniczności, o ile nie jest wspomagana przez odpowiednie mechanizmy adaptacyjne, które mogą dostosować różnorodne wymagania aplikacji do obecnych warunków sieciowych. Uważa się, że pojawienie się SDN i NFV zapewni elastyczność i inteligencję w projekcie sterowania, aby umożliwić łatwą parametryzację sieci i aplikacji na żądanie w taki sposób, aby oferować zwiększona satysfakcja użytkowników i osiągnięcie efektywnego wykorzystania zasobów sieciowych. Jednak ta koncepcja świadomości zasobów wymusza stosowanie sygnalizacji sterującej i technik utrzymania stanu, które wymagają skalowalnych rozwiązań, aby zapewnić dobrą wydajność dla szybkiej konfiguracji sesji i efektywnego zużycia procesora, pamięci i energii. Chociaż nadmierna rezerwacja zasobów sieciowych wydaje się najbardziej obiecującym podejściem w tym kontekście, wymaga wiedzy w czasie rzeczywistym na temat topologicznych informacji sieciowych i powiązanych statystyk zasobów łącza w celu rozwiązania problemu kompromisu między skalowalnością (redukcja narzutów sterowania) a efektywnym wykorzystaniem zasobów. Dlatego też dalsze dochodzenia nadal uważane są za konieczne. Mamy nadzieję, że ten rozdział przyczyni się do zrozumienia trendów w rozwoju i wyzwań stojących przed sieciami nowej generacji i utoruje drogę do dalszych innowacji na tej szybko rozwijającej się arenie, aby dostarczyć Internet 5G.