Przedstawiono mechanizmy wykorzystania inżynierii międzywarstwowej do wspomagania routhingu w sieciach ad-hoc. Mechanizmy te ukazują, w jaki sposób można, korzystając z już istniejących rozwiązań, usprawnić działanie sieci z ukierunkowaniem jej na spełnienie wymagań gwarantowania jakości usług.
W ostatnich latach nastąpił znaczny wzrost wykorzystania sieci bezprzewodowych w bardzo wielu dziedzinach życia. Najszybciej rozwijającą się obecnie i najbardziej znaną jest
sieć oparta na standardzie 802.11 i jego odmianach (a, b, g, n, e), tzw. WiFi. Standard ten definiuje różne tryby pracy, z których najczęściej spotykanym jest tryb zarządzany, w którym
nadrzędną kontrolę nad siecią sprawuje osobne urządzenie, tzw. punkt dostępu. Sieci, w których nie ma takowego urządzenia są sieciami typu ad-hoc. Brak odgórnej koordynacji
sprawia, iż zadania zarządzania i utrzymania sieci spadają na barki poszczególnych urządzeń klienckich wchodzących w jej skład. Jest to tym trudniejsze im więcej urządzeń znajduje się
w sieci oraz im większą mobilnością one się wykazują. Co za tym idzie, problemem staje się zapewnienie odpowiedniej jakości usług (Quality of Service – QoS) dla poszczególnych
typów aplikacji (np. VoIP) działających na stacjach klienckich. Jednym z ważniejszych mechanizmów, które w znaczący sposób mogłyby poprawić zaistniałą sytuacje jest wykorzystanie odpowiednich mechanizmów routingu, które gwarantować będą wybór odpowiednich tras z uwzględnieniem wymagań dla usług wymagających odpowiedniego QoS. W klasycznych rozwiązaniach wsparcie takie jest znikome lub żadne, dlatego koniecznym staje się opracowanie nowych mechanizmów routingu ze wsparciem dla jakości usług.
Architektura sieci MANET i problem routingu
Sieci MANET są sieciami bezprzewodowymi opartymi na połączeniach typu ad-hoc pomiędzy pewnym zbiorem stacji bezprzewodowych (w większości mobilnych) rozmieszczonym na pewnym ograniczonym obszarze. Nie posiadają one stałej infrastruktury i wykazują się dużą dynamiką zmian położenia poszczególnych stacji. Brak odgórnego systemu zarządzania sprawia, iż poszczególne stacje muszą polegać na sobie wzajemnie,
a każda z nich musi pełnić funkcję swoistego routera, aby zapewnić współpracę pomiędzy różnymi podsieciami oraz stacjami oddalonymi od siebie o dystans większy niż zasięg
radiowy każdej z nich. Komunikacja pomiędzy stacjami odbywa się za pośrednictwem mechanizmu IEEE 802.11 DCF (Distributed Coordination Function) [1] z wykorzystaniem tego samego kanału radiowego.
Ze względu na brak bezpośredniej widoczności radiowej stacji wchodzących w skład przedstawianej sieci, ważnym problemem staje się routing. W przypadku sieci bezprzewodowych zastosowanie klasycznych protokołów routingu znanych z sieci Ethernet (RIP, OSPF) staje się niemożliwe ze względu na dużą dynamikę zmian medium transmisyjnego oraz mobilność stacji. Warunki te wymuszają odpowiednio częstą aktualizację tablic routingu (aby pozostały one aktualne) oraz ograniczanie do minimum narzutu dodatkowych pakietów wprowadzanego przez przekazywanie informacji routingowych w sieci. Ponadto należałoby również uwzględnić wsparcie dla gwarantowania jakości usług przez stosowany protokół routingu w tego typu sieciach.
Na rysunku 1 przedstawiona została uproszczona topologia sieci MANET wraz z zaznaczeniem omawianego powyżej problemu. Strzałki obrazują aktywne łącza pomiędzy poszczególnymi stacjami.
Istnieje wiele różnych protokołów routingu dla sieci IP.Jednakże dla sieci ad-hoc należało opracować nowe, które spełniałyby przedstawione wyżej wymagania. Obecnie jest ich już dosyć dużo [2], jednak nie wszystkie z nich są zamieszczone w standardach (RFC). Generalnie, dzielą się one na:
1) proaktywne – w których tablice routingu są okresowo uaktualniane i każda ze stacji posiada informację o wszystkich trasach dostępnych na daną chwilę w sieci; ich główną
zaletą jest szybkość przesyłania pakietów, ale okupiona jest ona przez duży narzut związany z utrzymaniem pełnych tablic routingowych oraz wolną reakcją na zmiany w topologii sieci, co w przypadku sieci wysoce mobilnych wpływa niekorzystnie na jakość usług,
2) reaktywne – które znajdują drogę dopiero kiedy zaistnieje taka konieczność; redukuje to natłok w sieci spowodowany działaniem protokołu routingu, jednak wpływa niekorzystnie
na szybkość przesyłania, gdyż należy odczekać pewien czas aż droga do celu zostanie odnaleziona;
3) hybrydowe – łączące zalety protokołów pro- i reaktywnych;
routing w tym przypadku jest inicjowany poprzez proaktywne poszukiwanie tras, a dla każdej dodatkowo dołączanej stacji stosowane są mechanizmy reaktywne; stosowanie tego typu protokołu jest sensowne jedynie w sieciach odznaczających się dużą dynamiką zmian topologii oraz wysoką mobilnością.
Znanych jest jeszcze wiele innych typów mechanizmówroutingu w sieciach ad-hoc, jednakże w artykule ograniczono się jedynie do dwóch z wyżej wymienionych. Jednym z reprezentantów protokołów proaktywnych jest protokół DSDV (Destination Sequenced Distance Vector) [3]. Bazuje on na algorytmie Bellmana-Forda i został opracowany w celu rozwiązania problemu zapętleń. W ogólności, zasada jego działania jest podobna do tej podanej dla protokołów proaktywnych, z tą różnicą, iż w wymienianych tablicach zawarte są numery sekwencyjne, które są parzyste, jeśli łącze istnieje lub nieparzyste w przeciwnym wypadku. Numery te są generowane w stacjach docelowych. Wpis w tablicy zawiera również standardowe dla tego typu protokołu elementy, takie jak: cel, adres następnego skoku i wymagana liczba skoków do osiągnięcia celu. Preferowane są trasy z nowszymi numerami sekwencyjnymi; w przypadku tras z tym samym numerem wybierana jest ta z mniejszą metryką. Aby ograniczyć „zalewanie” sieci przez informacje routingowe zdefiniowano dwa typy pakietów. Pierwsze przenoszą całą dostępną informację o routingu (tzw. full dump – przesyłane rzadziej), drugie zawierają jedynie informację, która uległa zmianie od czasu ostatniego przesłania „full dump” (tzw. incremental – przesyłane częściej).
Reprezentantem protokołów reaktywnych jest protokół AODV (Ad-hoc On-Demand Distance Vector Routing) [4]. Zapewnia on szybką adaptację do dynamicznych warunków działania sieci ad-hoc, szybsze przetwarzanie w stacjach oraz mały narzut dodatkowych pakietów routingu krążących w sieci. Podobnie do DSDV protokół ten używa numerów sekwencyjnych do zapobiegania „zapętlaniu” sieci tak częstej w protokołach opartych na mechanizmie wektora odległości. Droga jest zestawiana na żądanie poprzez wysłanie pakietu rozgłoszeniowego RREQ (Route Request), który jest dalej przesyłany poprzez stacje pośrednie tworzące sieć ad-hoc.
Zanim prześlą one powyższy pakiet dalej tworzą u siebie ścieżkę powrotną do źródła i sprawdzają czy przypadkiem nie posiadają już wpisu o drodze do celu, którego poszukuje
źródło. Jeśli mają takową informację to odsyłają pakiet RREP (Route Reply) do źródła, w przeciwnym przypadku stacja pośrednia przesyła pakiet RREQ dalej. Jeśli żadna stacja
pośrednia nie posiada w swoich wpisach drogi do poszukiwanego celu to pakiet RREQ wędruje do tej pory przez stacje pośrednie aż znajdzie stacje docelową; wtedy stacja ta tworzy
ścieżkę powrotną i przesyła pakiet RREP do źródła, który wędrując w jego kierunku tworzy drogę do stacji docelowej. Warto zauważyć, iż protokół AODV zapewnia automatyczne
odrzucanie pakietów RREQ przez stacje pośrednie, jeśli otrzymają one kolejne duplikaty tego samego zapytania RREQ. Podobnie stacja docelowa, generuje odpowiedź RREP tylko
na pierwszy odebrany pakiet RREQ, kolejne docierające do niej tego typu pakiety są odrzucane.
Zarówno protokół AODV, jak i DSDV korzystają z tej samej metryki opartej na wyznaczaniu dróg za pomocą minimalnej liczby skoków, które należy wykonać, aby dotrzeć do stacji docelowej. Zostało dowiedzione w [5], iż aby tworzyć drogi, dla których można by zapewnić wymaganą jakość usług nie wystarczy oprzeć się na tej metryce. Niektóre usługi takie, jak VoIP, VoD potrzebują określonego zbioru parametrów gwarantowanych przez utworzoną drogę. Są to: wymagana przepustowość, maksymalne opóźnienie, zmienność opóźnienia, pewność dostarczenia do miejsca przeznaczenia i wiele innych, w zależności od wymagań realizowanej usługi. W swoich podstawowych wersjach zaprezentowane protokoły nie gwarantują wsparcia dla QoS, dlatego koniecznym staje się opracowanie nowych rozwiązań bądź też zmodyfikowanie już istniejących. Jednym ze sposobów jest wykorzystanie inżynierii międzywarstwowej do wsparcia tradycyjnych mechanizmów routingowych. Inżynieria ta pozwala między innymi na wykorzystanie informacji z warstwy fizycznej i MAC do podejmowania decyzji o wyborze odpowiedniej trasy, która zapewniłaby odpowiednią jakość wymaganą przez daną aplikację.
Definicja inżynierii międzywarstwowej
Inżynieria międzywarstwowa (Cross-Layer) jest stosowana w celu uwolnienia się od tradycyjnego bazującego na warstwach modelu komunikacyjnego OSI/ISO. Podejście warstwowe mimo swoich zalet (standaryzacja i uproszczenie) ogranicza tworzenie sieci (szczególnie bezprzewodowych), które zapewniałyby maksymalne wsparcie dla jakości usług.W sieciach teleinformatycznych routing realizowany jest według modelu OSI na poziomie warstwy trzeciej (warstwa sieci). Jednakże, jako że warstwa ta nie może się bezpośrednio komunikować z warstwami niższymi, niemożliwe staje się implementowanie bardziej złożonych metryk routingu zapewniających wsparcie dla QoS. Warstwy niższe (PHY/MAC) posiadają bowiem wiele informacji charakteryzujących jakość łącza (poziomy mocy, dostępne przepływności, opóźnienie, czasy CW, itp.). Wykorzystanie tych informacji do wspomagania działania warstw wyższych jest głównym celem stosowania inżynierii międzywarstwowej (w tym przypadku chodzi o wspomaganie procesu routingu w warstwie sieciowej). Na podstawie pozyskanych w ten sposób informacji, stacja może stosować w procesie routingu metryki uwzględniające jakość łącza i tym samym podejmować lepsze decyzje odnośnie do doboru trasy, która spełniać będzie postawione przez daną
usługę wymagania.
Rysunek 2 [9] przedstawia schematycznie model współpracy międzywarstwowej, interakcje pomiędzy warstwami i przepływ danych dla wspomagania mechanizmów routingu.
Podejście międzywarstwowe i odpowiednia jego implementacja umożliwia rozszerzenie możliwości standardowego podziału warstwowego OSI, bez niszczenia funkcjonującej do tej pory struktury komunikacji. Istotą działania takiego schematu jest udostępnianie informacji warstwom wyższym i to w dodatku w miarę szybki sposób, aby były one aktualne, a decyzje na nich oparte słuszne. Dzięki temu nie zachodzi konieczność tworzenia nowych protokołów routingu, ale wystarczy jedynie modyfikacja istniejących rozwiązań.
Dyskusja rozwiązań inżynierii międzywarstwowej dla sieci ad-hoc
Na podstawie przedstawionego modelu współpracy międzywarstwowej zostało zaproponowanych wiele nowych rozwiązań mających na celu wsparcie QoS w sieciach ad-hoc. Duża część z nich wykorzystuje wspomaganie mechanizmów routingu w celu zagwarantowania odpowiedniej jakości.
Poniżej zostaną przedstawione trzy z nich (CLAE, EETD, CLAODV) oraz dodatkowo zostanie przybliżony mechanizm szybkiego przekazywania pakietów we współpracy z inżynierią międzywarstwową.
Protokół CLAE
Rozwiązanie to bazuje na współpracy pomiędzy protokołem routingu AODV a protokołem dostępu do medium MAC IEEE 802.11e (EDCA) [6]. Głównym zadaniem CLAE jest określenie ścieżki z najmniejszym opóźnieniem. Każda stacja w sieci określa średnie opóźnienie zdefiniowane dla każdej z klas usług z osobna w standardzie 802.11e. Następnie informacja ta jest umieszczana w wiadomościach RREQ i RREP podczas przejścia przez poszczególne węzły trasy. Dzięki takiemu mechanizmowi stacja poszukująca ścieżki może ustalić opóźnienia dla każdej z nich i wybrać tę odpowiadającą jej wymaganiom. Mechanizm EDCA jest w przypadku standardu 802.11e rozszerzeniem DCF umożliwiającym rozróżnienie jakości różnych strumieni datagramów generowanych przez różne aplikacje.
W tym przypadku metryką jest suma średnich opóźnień wnoszonych przez poszczególne stacje na danej trasie. Czas ten liczony jest jako różnica czasów wysłania i odebrania odpowiednich ramek. Pierwszy czas to czas wysłania przez warstwę MAC ramki z warstwy routingu, drugi – to czas odebrania ramki MAC ACK dla wysłanego wcześniej pakietu. Różnica tych czasów określa opóźnienie i zawiera czasy kolejkowania, transmisji i propagacji. Opóźnienie tak określone jest liczone dla wszystkich przesłanych ramek podczas tzw. okresu konfiguracji oznaczanego przez T. Na końcu każdego okresu T stacja uaktualnia wartość średniego opóźnienia dla określonego priorytetu usług. Warto zauważyć, iż wyliczony czas opóźnienia uwzględnia również ewentualne retransmisje. Średnie opóźnienie liczymy ze wzoru iteracyjnego [7]:
Wartość IdleTime określa przedział czasu, kiedy medium transmisyjne jest wolne (stan bezczynności). Wartość sumaryczna opóźnienia dla danej ścieżki liczona jest ze wzoru [7]:
Jest ono liczone od źródła s do celu d. Każdy pakiet RREQ zawiera koszt przebytej ścieżki, a każda stacja dołącza ten koszt wraz ze ścieżka wstecz do swojej tablicy routingu. Zanim zostanie wysłany pakiet RREP ze stacji docelowej należy dołączyć do niego wspomniany wyżej koszt trasy. Dodatkową różnicą w stosunku do klasycznego protokołu AODV jest także fakt, iż w tym wypadku tylko stacja docelowa może odpowiedzieć wiadomością RREP; stacje pośrednie mimo znajomości trasy do celu nie powinny odpowiadać pakietami RREP. Związane jest to z koniecznością otrzymywania w miarę aktualnych informacji o trasach, które w przeciwnym wypadku mogłyby być w znacznej mierze niezgodne z aktualnym
stanem sieci, która podlega dynamicznym zmianom.
Dodatkową funkcją wprowadzoną w CLAE jest sposób selekcji ścieżek otrzymanych za pomocą komunikatów RREP; oczywiście pierwszeństwo ma ta wiadomość RREP, która przyszła najwcześniej i to jej drogą przesyłane są dane; jeśli po jakimś czasie przyjdzie kolejna odpowiedź RREP, mająca mniejsze opóźnienie niż obecnie wykorzystywana trasa, to tablica jest uaktualniana i nowa ścieżka jest wykorzystywana do przesyłu dalszej części danych. Taki sposób podejścia redukuje czas oczekiwania na wysłanie danych nie ograniczając zarazem wsparcia QoS.
Przedstawione w [7] wyniki symulacji dla protokołu CLAE dowodzą znacznej poprawy w czasach opóźnień pakietów dla usług audio-video (wrażliwych na wielkość tego parametru QoS), jak również w przepustowości całej sieci w stosunku do tradycyjnego AODV-EDCA. Ponadto ogólność i prostota implementacji sprawia, iż zaproponowany mechanizm można wbudować w każdy inny protokół reaktywny oraz rozszerzyć istniejącą już koncepcję o dodatkowe parametry QoS, takie jak: pasmo, współczynnik strat, stabilność drogi, poziomy mocy, stan baterii itp.
Implementacja metryki EETD w protokole DSDV
Podobnie jak w poprzednim przykładzie, również i tu wprowadzono nowy typ metryki zwanej EETD (Enhanced Expected Transmission Delay) [8], która ma za zadanie zastąpić tradycyjną opartą na liczbie skoków (Minimum Hops – MH). Metryka tu zastosowana ma na celu wzięcie pod uwagę przepływności łącz składowych w sieci bezprzewodowej. W ogólności używa ona zespołu parametrów pozyskanych z warstw PHY/MAC (pojemność kanału, opóźnienie oraz współczynnik dostarczonych poprawnie pakietów), aby określić
jakość łącza, a następnie podjąć decyzję o routingu.
Standardy IEEE 802.11x pozwalają na automatyczną adaptację szybkości transmisji (dla standardu 802.11g skokowo od 1 do 54 Mbit/s). Znany jest fakt, że im większa szybkość
transmisji, tym mniejszy zasięg i odwrotnie, dlatego ważne jest zagwarantowanie tej adaptacji. W celu jej usprawnienia zaproponowano modyfikację mechanizmu RTS/CTS; teraz wiadomość RTS jest wysyłana na tymczasowo dobranej prędkości transmisji, na tej podstawie (pomiar SNR) odbiornik określa najwyższą dostępną przepływność i umieszcza tę informację w wiadomości zwrotnej CTS. Na podstawie tego mechanizmu można zbudować odpowiednie tablice SNR w stacjach i na ich podstawie podejmować decyzję o wyborze szybkości transmisji. Modyfikacja standardu 802.11 pozwala na zdefiniowanie odpowiedniej metryki, która zapewni wsparcie dla QoS. Określono parametr ETC (Expected Transmission Count) dla danego łącza i liczony według formuły [8]:
Pi,r określa współczynnik strat pakietów dla łącza i na określonej przepływności r. Liczony jest on dzieki temu, że każda stacja wysyła okresowo pakiety sondujące, na szybkości transmisji określonej za pomocą wcześniej wymienionego mechanizmu, do swoich sąsiadów zapisanych w trasach tablicy routingu. Sąsiednie stacje otrzymują te pakiety i wysyłają w odpowiedzi ramki ACK do nadawcy na tej samej przepływności, z jaką odebrały zapytanie. Nadawca ramek sondujących zlicza odpowiedzi ACK i na tej podstawie oblicza wyżej wymieniony współczynnik strat pakietów dla określonego łącza. Kolejno zdefiniowano wartość ETD (Expected Transmission Delay) [8] jako:
Wartość Lpkt oznacza tutaj długość pakietu. Tak zdefiniowany współczynnik ETD preferuje łącza o dużej przepływności i małych stratach. Jednak sama wartość ETD nie wystarczy, aby podjąć ostateczną decyzję o wyborze ścieżki. Metryka trasy składa się bowiem z kombinacji metryk składowych łącz stanowiących daną ścieżkę. Zaproponowano więc dwa
podejścia łączące metryki ETD:
• pierwsze polega na prostym dodaniu wszystkich wartości ETD łącz wchodzących w skład trasy według poniższego wzoru i wybraniu ścieżki z najmniejszą wartością SETD [8]:
Współczynnik ten (z ang. Bottleneck Group ETD) określa tzw. wąskie gardło trasy, które będzie determinowało całkowitą przepływność danej ścieżki. Ta największa suma określa metrykę ścieżki i im mniejsza jest ta wartość tym lepiej (wybieramy więc trasę z najmniejszym BG-ETD).
Aby dodatkowo rozszerzyć możliwości powyżej przedstawionych metryk, łączymy je razem w jedną określaną jako EETD (Enhanced Expected Transmission Delay) stosując pewien zmienny parametr η według poniższej formuły [8]:
Tak określona ostatecznie metryka stanowi pewien kompromis pomiędzy opóźnieniem a przepustowością danej trasy. Współczynnik SETD odzwierciedla w pewien sposób całkowite opóźnienie wnoszone przez ścieżkę, a BG-ETD jej możliwości przepustowe. Stosowany parametr η pozwala uzyskać odpowiednie zrównoważenie wpływu obu wymienionych współczynników na metrykę EETD; wyższa jego wartość wymusza preferencję tras o wysokiej przepływności, podczas gdy niższa tych o mniejszym opóźnieniu. Wybór trasy sprowadza się do wybrania ścieżki o najmniejszej wartości metryki EETD.
Końcowym etapem jest implementacja przedstawionego mechanizmu w którymś z opracowanych do tej pory protokole routingu. W [8] został użyty protokół proaktywny DSDV
z uwagi na to, iż analizie podlegała sieć typu WMN (Wireless Mesh Network) charakteryzująca się dosyć małą mobilnością w stosunku do sieci MANET, gdzie lepszym rozwiązaniem byłoby zastosowanie któregoś z protokołów reaktywnych (AODV). Rozważając DSDV zmierzona metryka powinna być dodana do już funkcjonujących wiadomości routingowych, aby nie zużywać niepotrzebnie dodatkowych zasobów sieci (pasmo). Dodatkowa informacja o metryce jest więc dodawana jako mały narzut do istniejącej tablicy routingu i przesyłana podczas odświeżania (uaktualniania) tablic routingowych
w poszczególnych stacjach. Jeśli stacja otrzyma informację o ścieżce z mniejszą wartością EETD, to zastępuje starszy wpis w swojej tablicy nowym.
Wyniki symulacji pokazują znaczny wzrost wydajności systemu dzięki zastosowaniu nowego rodzaju metryki. Rośnie o ok. 50% współczynnik dostarczenia pakietów oraz maleje opóźnienie (End-to-end) o ok. 2-3 razy w zależności od obciążenia sieci w danym momencie.
Protokół CLAODV
Mechanizm CLAODV został zaproponowany w [9] z uwagi na coraz większą różnorodność sieci ad-hoc, a co za tym idzie różnice w parametrach układów transmisji bezprzewodowej poszczególnych stacji w sieci. Znaczącym czynnikiem są różne moce nadawania poszczególnych stacji, co sprawia, że niektóre z nich o mniejszej mocy są w stanie odebrać pakiety od tych o dużej, ale nie są już w stanie wysłać swoich tak, aby druga stacja je odebrała (zostało to przedstawione na rysunku 1). Problem ten powoduje asymetryczność łącz w sieci bezprzewodowej i stanowi wyzwanie dla klasycznych protokołów routingu sieci
ad-hoc, które zostały zaprojektowane do współpracy z łączami symetrycznymi. Protokoły te nie radzą sobie w tego typu sieciach, a jeśli nawet, to ich wydajność jest bardzo mała.
W celu rozwiązania tego problemu w [9] zaproponowano modyfikację mechanizmu AODV w taki sposób, aby identyfikować łącza jednokierunkowe i je odrzucać podczas tworzenia tras routingowych. Ogólnie używany w standardzie 802.11 protokół MAC oparty na mechanizmie DCF sprawdza dwukierunkowość łącz jedynie dla transmisji typu unicast (mechanizm RTS/CTS); w przypadku stosowania transmisji broadcast (tak jest dla protokołów routingu) łącza jednokierunkowe pozostają niewykryte. W takim wypadku protokół routingu taki jak AODV poradzi sobie z odnalezieniem drogi jedynie wtedy, gdy na trasie będzie obecne tylko jedno łącze asymetryczne; w przypadku większej liczby łączy asymetrycznych (powyżej dwóch) mechanizm AODV nie poradzi sobie, co wynika z zasady działania tego protokołu – liczba powtórzeń wiadomości RREQ jest ustalona na dwie, aby nie
przeciążać sieci.
Zaproponowana modyfikacja tego protokołu z użyciem inżynierii międzywarstwowej umożliwia odnalezienie trasy (po łączach symetrycznych) od razu za pierwszym podejściem (jeśli takowa istnieje) bez konieczności powtórzeń. Takie podejście redukuje znacznie opóźnienie związane z poszukiwaniem trasy oraz narzut wprowadzany przez routing. Mechanizm ten korzysta z informacji o sile sygnału zawartej w warstwie fizycznej. W pakiecie RREQ zostały stworzone dwa dodatkowe pola do przenoszenia informacji związanych z mocą nadawania i odbioru. Kiedy stacja (odbiorcza) otrzyma taki pakiet (od stacji nadawczej), oblicza tłumienie w łączu jako [9]:
Korzystając z tej wartości oraz wiedzy na temat progu (mocy) odbiorczego stacji nadawczej, stacja odbiorcza może określić symetryczność bądź nie danego łącza. Dzieje się to na podstawie porównania mocy nadawania tej stacji odbiorczej z sumą tłumienia w łączu i progu odbiorczego stacji nadawczej. Jeśli jest ona większa (moc nadawania stacji odbiorczej), to łącze jest symetryczne i pakiet RREQ jest dalej przesyłany zgodnie z algorytmem dla protokołu AODV; w przeciwnym przypadku wiadomość RREQ jest odrzucana i w ten sposób łącze asymetryczne jest eliminowane z procesu routingu. Takie podejście sprawia, iż nie trzeba w znaczący sposób modyfikować istniejącego protokołu (w AODV ulega modyfikacji tylko pakiet RREQ, natomiast RREP, RERR pozostają bez zmian). Umożliwia to również zwiększenie funkcjonalności tego mechanizmu o inne parametry, które mogą być zróżnicowane w zależności od kierunku transmisji.
Wyniki symulacji [9] świadczą o znacznym wzroście ogólnej wydajności sieci, w której poszczególne stacje mają zróżnicowane parametry nadawczo-odbiorcze. Dzięki zastosowaniu protokołu CLAODV liczba kolizji w sieci spadła nawet o 80%, wzrósł współczynnik dostarczonych pakietów (o ok. 30%); narzut spowodowany działaniem mechanizmów routingu również uległ zmniejszeniu aż o 80%. Poprawa powyższych parametrów miała wpływ na zmniejszenie się opóźnienia (End-to-end) o 2-4 razy w stosunku do standardowego protokołu AODV. Należy mieć jednak na uwadze, iż zaproponowany mechanizm przynosi zysk jedynie wtedy, jeśli mamy do czynienia ze zróżnicowaną pod względem mocy nadawania i odbioru siecią. W przeciwnym wypadku (łącza wyłącznie symetryczne) traci sens stosowanie tego typu udoskonaleń.
Szybkie przekazywanie pakietów
Przedstawione w [10] rozwiązanie zwane PFFMAC (Packet Fast Forward MAC) nie jest bezpośrednio związane z poprzednimi, ale przedstawia ciekawe wykorzystanie inżynierii
międzywarstwowej do zwiększenia ogólnej wydajności sieci ad-hoc.
Przekazywanie pakietów przez warstwę MAC jest tu wspomagane dzięki dynamicznej regulacji z wykorzystaniem informacji zawartych w tablicach routingu. Jednakże główna
siła tego rozwiązania opiera się na modyfikacji mechanizmu RTS/CTS obecnego w klasycznym protokole MAC 802.11 DCF. Podejście klasyczne zakłada, że jeśli stacja ma dane do wysłania to najpierw odczekuje losowy czas, a następnie nasłuchuje medium w celu wykrycia jego dostępności. Jeśli nie jest ono zajęte, to stacja wysyła pakiet RTS (Request-To-
Send); stacja odbiorcza odpowiada po odebraniu RTS pakietem CTS (Clear-To-Send). Gdy stacja nadawcza odbierze wiadomość CTS to może zacząć nadawać; po zakończeniu transmisji pakietu DATA (zawierającego dane) stacja odbiorcza potwierdza poprawne odebranie danych wysyłając pakiet ACK. Ponadto po odebraniu ramki każda stacja musi odczekać czas SIFS (krótszy od DIFS). Mechanizm ten jest konieczny, aby stacje wzajemnie się nie zakłócały.
Funkcjonowanie tego powszechnie obecnego i zestandaryzowanego rozwiązania zostało pokazane na rysunku 3 [10] wraz z tradycyjnym podejściem warstwowym do przekazywania pakietów.
Powodem ograniczenia pasma i wzrostu opóźnienia jest w klasycznej metodzie przekazywania pakietów zaznaczony na rysunku powyżej odstęp czasu pomiędzy ramką ACK
a RTS w stacji B. Protokół PFFMAC pobiera konieczne do przekazania pakietu dalej informacje już wcześniej z warstw wyższych (routing) i dzięki temu można zredukować wspomniany wcześniej odstęp czasu (rys. 4) [10].
Zostało dowiedzione w [10], iż tak zmodyfikowany mechanizm DCF MAC 802.11 umożliwia lepsze wykorzystanie zasobów sieci; pozwala odpowiednio gospodarować pasmem kanału oraz opóźnieniami, których doświadczają wysyłane pakiety. Korzyści płynące z jego zastosowania są tym większe, im większa jest liczba stacji i im większą mobilnością się one wykazują. Zaletą jest także to, iż może on współpracować z każdym z protokołów routingu funkcjonujących w sieciach ad-hoc (zarówno pro- jak i reaktywnym) bez wprowadzania w nich żadnych dodatkowych zmian, korzystając jedynie z informacji zgromadzonych w tablicach routingowych oraz warstwie MAC.
Podsumowanie
Przedstawione w artykule mechanizmy wykorzystania inżynierii międzywarstwowej ukazują, w jaki sposób można, korzystając z już istniejących rozwiązań, usprawnić działanie sieci z ukierunkowaniem jej na spełnienie wymagań gwarantowania jakości usług. Każde z rozwiązań wydatnie wpływało na zmniejszenie opóźnienia pakietów wędrujących w sieci, co ma wielkie znaczenie dla usług wrażliwych na nie takich jak coraz bardziej popularne VoIP oraz Video over IP. Mimo swoich zalet i prostoty działania rozwiązań opartych na inżynierii międzywarstwowej ma ona pewne wady. Jedną z nich jest niekiedy skomplikowana implementacja programowa zaproponowanych rozwiązań, której na przeszkodzie stoi dobrze już ugruntowany w telekomunikacji model OSI/ISO. Przy projektowaniu mechanizmów korzystających z crosslayer należy uważać, aby nie powodować niepożądanych interakcji pomiędzy tradycyjnie funkcjonującymi warstwami. Ponadto przy wprowadzaniu nowych rozwiązań w sieciach bezprzewodowych (szczególnie typu ad-hoc) należy uważać na aspekt bezpieczeństwa wymienianych informacji. Często działanie proponowanych mechanizmów jest sprawdzane jedynie poprzez symulację z wykorzystaniem odpowiednich aplikacji (symulator sieci NS-2) z uwagi na bardzo wysoki koszt budowy sieci testowych opartych na połączeniach ad-hoc, co stanowi pewną przeszkodę we wdrażaniu tego typu rozwiązań.
Przedstawione rozwiązania same w sobie nie gwarantują kompleksowej obsługi wsparcia QoS, a jedynie zapewniają poprawę pojedynczych parametrów charakteryzujących jakość usług w sieciach ad-hoc. Dopiero ich połączenie (oraz ewentualne rozszerzenie o wsparcie dodatkowych czynników determinujących jakość usług) w jedno sprawnie funkcjonujące rozwiązanie może zapewnić gwarancję odpowiedniego QoS dla poszczególnych aplikacji działających w sieci. Tego typu mechanizm znalazłby zastosowanie w sieciach wysoce mobilnych, składających się ze zróżnicowanych (pod względem parametrów transmisji
bezprzewodowej) typów stacji.
Kierunek dalszych prac: inżynieria międzywarstwowa w kierunku minimalizacji ruchu służbowego i rozgłoszeniowego protokołów sieciowych.
Literatura:
[1] Roshan P., Leary J.: Bezprzewodowe sieci LAN 802.11, MIKOM, 2004
[2] Lista protokołów routingu dla sieci ad-hoc http://en.wikipedia.org/w/index.php?title=List_of_ad-hoc_routing_protocols
[3] Perkins C., Bhagwat P.: Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, SIGCOMM, 1994
[4] Perkins C.: Ad hoc on dem and distance vector (AODV) routing, IETF, RFC 3561, 2004
[5] Decouto D., Aguayo D., Chambers B., Morris R.: Performance of multi-hop wireless networks: Shortest path is not enough, Proceedings of First Workshop on Hot Topics in Networks, New Jersey, USA, 2002
[6] IEEE 802.11 Standard, Wireless LAN Medium Access Control (MAC) and Physical layer (PHY) Specifications, 1999
[7] Romdhani L. , Bonnet C.: A Cross-Layer On-Demand Routing Protocol for Delay-Sensitive Applications, IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications, 2005
[8] Xiaoxue Zhang, Zhen Yang, Fenghua Li, A PHY/MAC-Aware Cross-Layer Routing Metric for Wireless Mesh Networks, International Symposium on Intelligent Signal Processing and Communication Systems, 2007
[9] Ramachandran B., Shanmugavel S., Performance Analysis of Cross Layer AODV for Heterogeneously Powered Ad-hoc Networks, IEEE, 2006
[10] Tan Wei, Qin Dan-yang, Sha Xue-jun, Xu Yubin, Cross-layer design for packet fast forward in Mobile Ad Hoc Network, IEEE, 2006
Autor: Gerard Mycek, Wojskowa Akademia Techniczna, Wydział Elektroniki
| REKLAMA |
| REKLAMA |