Rutowanie multikastowe w sieciach ad hoc.

Transkrypt

1 Piotr Rosiński Rutowanie multikastowe w sieciach ad hoc. praca dyplomowa magisterska ( inŝynierska) Promotor: Dr inŝ. Michał Morawski Dyplomant: Piotr Rosiński nr albumu Łódź, grudzień 2007 r.

2 SPIS TREŚCI Wykaz skrótów Wykaz rysunków Słownik pojęć Wstęp Cel i zakres pracy Wprowadzenie do multicastingu Multicasting w sieciach kablowych Ogólna charakterystyka sieci ad hoc i multicastingu w tych sieciach Rutowanie w sieciach bezprzewodowych ad hoc Ruting unicastowy w sieciach MANET Protokoły proaktywne Protokoły reaktywne Ruting multicastowy w sieciach MANET Protokoły drzewo-strukturalne Protokoły siatko-strukturalne Ruting multicastowy w sieciach mobilnych bezprzewodowych ad hoc Protokoły reaktywne Multicast Ad Hoc On-Demand Distance Vector (MAODV) On-Demand Multicast Routing Protocol (ODMRP) Protokoły proaktywne Ad hoc Multicast Routing Protocol (AMRoute) Core-Assisted Mesh Protocol (Camp) Protokoły inteligentne Multicast for Ad hoc Network with Swarm Intelligence(MANSI) Ant-based Symulacje Informacje wstępne Kryteria symulacji Szczegółowe parametry ustawień sieci Wyniki symulacji protokołu ODMRP Liczba nadawców Mobilność Wielkość grupy multicastowej Podsumowanie Bibliografia Dodatek A Zawartość nośnika CD Dodatek B Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl

3 Wykaz skrótów. ABR Associativity Based Routing ACK Acknowledgement AMRIS Adhoc Multicast Routing protocol utilizing Increasing Id numbers AMRoute Adhoc Multicast Routing ARP Address Resolution Protocol CAMP Core-Assisted Mesh Protocol CBT Core Based Tree CBR Constant Bit Rate CRA Core Resolution Algorithm CSMA/CA Carrier Sense Multiple Access with Collision Avoidance DSDV Destination-Sequenced Distance-Vector routing DSR Dynamic Source Routing ERS Expanded Ring Search FORP Flow Oriented Routing Protocol GPS Global Position System GRPH Group Hello IETF Internet Engineering Task Force IP Internet Protocol LCC Least Cluster Change LET Link Expiration Time LL Link Layer LMR Lightweight Mobile Routing MAC Media Access Control MACT Multicast Route Activation MANET Mobile Ad Hoc Network MAODV Multicast Adhoc On-Demand Vector routing protocol MoM Mobile Multicast MRT Multicast Route Table RT Route Table ODMRP On-Demand Multicast Routing Protocol RET Route Expiration Time RPF Reverse Path Forwarding 3

4 RREQ Route Request RREP Route Reply RTS/CTS Request To Send/Clear To Send SSA Signal Stability-based Adaptive Routing TCP Transmission Control Protocol TORA Temporally Ordered Routing Algorithm TTL Time To Live Wykaz tabel. Tabela 1. Porównanie protokołów proaktywnych. Tabela 2. Porównanie protokołów reaktywnych. Tabela 3. Podstawowe parametry protokołu MANSI. Tabela 4. Podstawowe parametry symulacji. Tabela 5. Parametry symulacji zorientowanej na liczbę nadawców. Tabela 6. Parametry symulacji zorientowanej na szybkość poruszania się węzłów. Tabela 7. Parametry symulacji zorientowanej na liczbę węzłów naleŝących do grupy multikastowej. Wykaz rysunków. 1. Schematy rutingu. 2. Przykład mobilnej bezprzewodowej sieci ad hoc. 3. Drzewo najkrótszej ścieŝki.. 4. Procedura dołączania do grupy w protokole CBT. 5. Przykład sieci bezprzewodowej. 6. Sieć ad hoc z zaznaczonym zasięgiem węzłów. 7. Klasyfikacja protokołów unicastowych w sieciach ad hoc. 8. Ruch w sieci ad hoc. 9. Budowa klastra. 10. CGSR: trasowanie od węzła 1 do Wyszukiwanie trasy w DSR. 12. Przykład odpowiedzi na zapytanie o trasę w DSR. 13. Wyszukiwanie trasy do węzła i ścieŝka powrotu w AODV. 14. Przykład trasy przekazywania pakietów w AODV. 15. Przykład grafu DAG. 4

5 16. Klasyfikacja protokołów multicastowych w sieciach ad hoc. 17. Przykład struktury drzewiastej. 18. Przykład struktury siatki. 19. Wyszukiwanie trasy w protokole MAODV. 20. Operacje dołączenia w MAODV. 21. Utworzenie ścieŝki powrotu. 22. Utworzenie ścieŝki przekazywania. 23. Aktywacja trasy multicastowej. 24. Format pakietu MACT. 25. Wiadomości hello lidera grupy. 26. Format GPRH. 27. Usuwanie uczestnika grupy. 28. Operacja naprawiania zerwanego połączenia w drzewie. 29. Połączenie dwóch drzew. 30. Tworzenie siatki z uŝyciem broadcastowego Join Query. 31. Proces dziłania Join Query. 32. Proces pakietu Join Reply. 33. Nagłówek pakietu Join Query. 34. Nagłówek pakietu Join Reply. 35. Rozsyłanie pakietu Join Query. 36. Uformowana tablica multicastowa. 37. Wirtualne drzewo multicastowe. 38. Tworzenie siatki. 39. Tworzenie drzewa. 40. Podział jednej siatki na kilka. 41. Formowanie siatki i drzewa. 42. Formowanie siatki i drzewa cd. 43. Diagram stanów w protokole AMRoute. 44. Przepływ pakietów z rutera h w siatce multicastowej i w drzewie współdzielonym. 45. Przepływ pakietów z węzła nie będącego uczestnikiem grupy w CAMP. 46. Multicastowe połączenie pomiędzy trzema uczestnikami grupy w MANSI. 47. Przykład działania Forward i Backward Ant. 48. Przykład przypisania wysokości do węzłów pośredniczących. 5

6 49. Przykład działania MANSI. 50. Format pakietu Core Announce. 51. Format pakietu Join Request. 52. Format pakietów Forward Ant i Backward Ant. 53. Sieć ilustrująca działanie mechanizmu adaptacji mobilności. 54. Wymagania systemowe. 55. Packet Delivery Ratio jako funkcja liczby nadawców pakietów. 56. Packet Transmssion Ratio jako funkcja liczby nadawców pakietów. 57. Pakiety kontrolne przez pakiety doręczone, jako funkcja liczby nadawców pakietów. 58. Pakiety kontrolne wraz z danymi przez pakiety doręczone, jako funkcja liczby nadawców pakietów. 59. Packet Delivery Ratio jako funkcja mobilności. 60. Packet Transmission Ratio jako funkcja mobilności. 61. Pakiety kontrolne do pakietów doręczonych jako funkcja mobilności. 62. Pakiety kontrolne wraz z pakietami wysłanymi do pakietów doręczonych jako funkcja mobilności. 63. Packet Delivery Ratio, jako funkcja liczby uczestników grupy multicastowej. 64. Packet Transmission Ratio, jako funkcja liczby uczestników grupy multicastowej. 65. Pakiety kontrolne do pakietów doręczonych, jako funkcja liczby uczestników grupy multicastowej. 66. Pakiety kontrolne oraz wysłane pakiety z danymi do pakietów doręczonych, jako funkcja liczby uczestników grupy multicastowej. 6

7 Słownik pojęć. sąsiad (ang. neighbor) pojęcie określające inny węzeł sieci, do którego dane mogą być transmitowane bezpośrednio, wykorzystując dostępne medium transmisji bez pomocy innych pośrednich węzłów. [18][2] sąsiedztwo (ang. neighborhood) zbiór wszystkich węzłów, które mogą otrzymać dane od wybranego węzła bezpośrednio, bez udziału pośredników, niezaleŝnie kiedy będzie on nadawał.[18][2] skok (ang. hop) jest jedną ze stosowanych przez protokoły rutingu jednostek miary odległości w celu określenia jakości drogi prowadzącej do celu. Liczbowo określa ona liczbę ruterów, lub w przypadku sieci bezprzewodowych ad hoc węzłów sieci, przez które musi być przekazywany pakiet, aby dotarł on do Ŝądanego urządzenia docelowego. [18][2] source routing technika trasowania, w której nadawca moŝe określić dokładnie trasę, jaką pakiet powinien pokonać, aby dotrzeć do celu. [18][2] stan łączy (ang. link state) nazwa określająca grupę protokołów rutingu przechowujących kompletną bazę danych o topologii sieci z informacjami o kosztach połączeń i ich stanie. Wszystkie elementy sieci posiadają identyczne dane o sieci.[18][2] ścieŝka powrotna - (ang. reverse path) trasa wyznaczona przez algorytm rutowania prowadząca od węzła docelowego do źródłowego. Przeznaczona jest dla węzła odległego, by mógł odesłać pakiety do węzła źródłowego. [18][2] wektor odległości (ang. distance-vector) określenie protokołów wymieniających z sąsiadami dane z tablic rutingu. Pojęcie to wiąŝe się ze sposobem przedstawiania tych danych. KaŜda trasa to para kierunek i odległość. Kierunek jest to adres sąsiada, do którego naleŝy skierować pakiet, aby dotarł do celu. Odległość jest to wartość wyznaczona na podstawie metryki stosowanej w protokole.[18][2] węzeł ruchomy (ang. mobile node) dynamicznie zmieniający połoŝenie element sieci, najczęściej bezprzewodowej, taki jak np. komputer, telefon. [18][2] lider grupy - (ang. group leader) węzeł, który jest uczestnikiem grupy multicastowej i który najczęściej jest pierwszym węzłem takiej grupy. Odpowiedzialny jest on za inicjalizację i zarządzanie numerem sekwencyjnym grupy multicastowej.[26] tablica lidera grupy (ang. group leader table) tablica w której węzły przechowują informacje o parach grupa multicastowa-lider grupy. W kaŝdej tablicy istnieje 7

8 pojedynczy wpis dla kaŝdej grupy, dla której węzeł otrzymał wiadomość Group Hello. [26] drzewo multicastowe (ang. multicast tree) drzewo skupiające wszystkie węzły, które są uczestnikami grupy multicastowej, i węzły będące tylko przekaźnikami pakietów pomiędzy uczestnikami. [26] multicastowa tablica rutingu (ang. multicast router table) tablica w której węzły przechowują informacje o trasach (równieŝ o następnych skokach) dla róŝnych grup multicastowych. [26] trasa odwrotna - (ang. reverse route) trasa dzięki której moŝliwe jest wysłanie odpowiedzi (RREP) na pakiet z powrotem do źródła jego wysłania przez węzeł docelowy lub przez węzeł znający trasę do celu. [26] 8

9 1. Wstęp. Kilka miesięcy temu zainteresowałem się tematem rutingu multicastowego w sieciach ad hoc. W tamtym czasie pojęcia takie, jak: multicasting, sieci ad hoc, protokoły reaktywne, proaktywne, mrówkowe i wiele innych wydawały się, przynajmniej dla mnie, mało znane, niepotrzebne. Po przeczytaniu dziesiątek artykułów, pozycji naukowych, draftów technicznych, uświadomiłem sobie, w jak duŝym byłem błędzie. Sieci ad hoc to nie jest abstrakcja. Są wszędzie wokół nas. Cały czas jesteśmy pod ich działaniem, chociaŝby w telefonach komórkowych i większość z nas nawet nie zdaje sobie sprawy, jak głęboko wyszukane procesy dzieją się w tak małych urządzeniach. Jeszcze kilka lat temu, nie kaŝdy wiedział co to jest ruter, do czego słuŝy. Dziś praktycznie kaŝdy telefon komórkowy pełni taką rolę. Nikt nawet nie zastanawia się, jak to jest, Ŝe moŝna sobie sprawdzić pocztę internetową w tak małym urządzeniu. śeby móc tego dokonać, urządzenie pokonuje daleką drogę, no właśnie drogę, a skąd wie którą i dlaczego tą, a nie tamtą? Pytań i niewiadomych jest jeszcze więcej i postaram się na nie w tej pracy odpowiedzieć. śeby móc zacząć mówić o sieciach ad hoc, trzeba poznać najpierw trochę jej historii. W ostatnich czasach sieci bezprzewodowe przeŝywają ogromny rozkwit. Na badania nad ich wydajnością, przydatnością, a takŝe moŝliwościami rozwoju w przyszłości, największe koncerny na świecie przeznaczają setki milionów dolarów. NaleŜy przypomnieć, Ŝe pierwsze sieci ad hoc pojawiły się juŝ w latach sześćdziesiątych ubiegłego wieku. Wtedy to, w projekcie ALOHA powstał protokół rozproszonego zarządzania dostępem do kanałów komunikacyjnych. Co prawda wykorzystywano tam węzły stacjonarne, będące w swoim zasięgu (sieci pojedynczego przeskoku ang. single-hop), jednakŝe to zapoczątkowało dalsze prace nad sieciami tworzonymi spontanicznie. W 1973 roku organizacja DARPA zainicjowała projekt PRnet (ang. packet radio network), w którym zaczęto wykorzystywać transmisję radiową typu multi-hop. Oznacza to, Ŝe nie wszystkie węzły biorące udział w transmisji znajdują się w swoim zasięgu i do przekazywania pakietów wykorzystywane były węzły pośredniczące, przekazujące ruch pomiędzy nadawcą a odbiorcą. Prace nad tym projektem wykazały, Ŝe wykorzystanie wielu przeskoków w sieci, w celu osiągnięcia celu, pozwala zwiększyć efektywność działania sieci, poprzez jednoczesną transmisję danych wieloma ścieŝkami, a takŝe pozwala ograniczyć zuŝycie energii. [8] 9

10 W chwili obecnej jednym z największych wyzwań dla sieci bezprzewodowych są mobilne sieci ad hoc (MANET). Sieci te zbudowane są z dynamicznych węzłów, które tworzą wieloskokowe, często zmieniające się topologie, gdzie przepustowości na niektórych odcinkach bezprzewodowych mogą być niskie. Węzły te mogą się dowolnie przemieszczać. MoŜe się równieŝ zdarzyć sytuacja, w której dwa węzły nie będą się znajdować w zasięgu swojej transmisji. Algorytmy realizujące przesyłanie pakietów, powinny więc uwzględniać sytuację, gdzie w celu dostarczenia pakietu, do transmisji danych wykorzystany zostanie węzeł pośredniczący, nie naleŝący do Ŝadnej grupy, a jedynie działający jako ruter.[3].protokoły realizujące ruting w sieciach ad hoc powinny być jak najprostsze, szybkie w działaniu i ograniczające niepotrzebny ruch kontrolny, co przyczynia się do efektywnego ich działania w rzeczywistości.[25] Cechy takie prezentują multicastowe protokoły rutowania w sieciach MANET, w których dane dostarczane są tylko do wybranej grupy zera lub więcej odbiorców.[40] W literaturze polskiej na dzień dzisiejszy trudno byłoby wskazać pozycje, które poruszają zagadnienia będące meritum tej pracy, ze względu na ograniczoną liczbę na rynku tytułów naukowych z zakresu tej problematyki. W przypadku tak dynamicznego rozwoju, jaki moŝemy zaobserwować w chwili obecnej wokół nas, warto tematykę tę zauwaŝyć i przybliŝyć. 10

11 2. Cel i zakres pracy. Celem tej pracy jest przedstawienie i przybliŝenie czytelnikowi zagadnień związanych z rutowaniem multicastowym w sieciach ad hoc poprzez szczegółowe omówienie kilku protokołów z tej grupy, charakterystycznych ze względu na budowę, właściwości i działanie oraz symulacyjne zbadanie efektywności jednego z nich. W celu zrozumienia powyŝszych zagadnień praca ta wprowadza równieŝ czytelnika do sieci ad hoc, zobrazowuje czym tak naprawdę jest multicasting i jakie korzyści pozwala osiągnąć, a takŝe zapoznaje z rutingiem unicastowym w sieciach mobilnych, bezprzewodowych ad hoc, który stanowi formę podrzędną rutingu multicastowego. Zakres pracy stanowią dwie części: teoretyczna i praktyczna. Część teoretyczna została podzielona na kilka rozdziałów opisanych szczegółowo poniŝej. W niej to czytelnik będzie mógł zapoznać się pojęciem multicastingu i realizacją tej transmisji zarówno w sieciach kablowych, jak i ad hoc. W dalszej części przedstawione zostanie ogólne działanie sieci ad hoc, w tym realizacja rutingu w sieciach unicastowych poprzez krótkie charakterystyki wybranych protokołów. Dzięki wiedzy pozyskanej z wcześniejszych rozdziałów, moŝliwe będzie zapoznanie się z kolejnym etapem tej pracy, czyli z rutingiem multikastowym w mobilnych, bezprzewodowych sieciach ad hoc i szczegółowo omówionymi wybranymi protokołami podzielonymi ze względu na swą budowę i metody odświeŝania tras rutingu. Część praktyczną stanowi zasymulowanie działania przykładowego protokołu, jakim jest On-Demand Multicast Ruting Protocol, przy wykorzystaniu narzędzia o nazwie: QualNet. Symulacja ta pozwoli uzyskać nam informacje, na temat przydatności tego protokołu w rzeczywistych implementacjach. Rozdział 3 wprowadza czytelnika w tematykę multicastingu. Po zapoznaniu się z nim czytelnik powinien zrozumieć, na czym polega transmisja multicastowa, czym się charakteryzuje, w jaki sposób jest realizowana w sieciach kablowych, a takŝe czym są sieci MANET i jak ogólnie wygląda multicasting w tych sieciach. Rozdział 4 pozwala zapoznać się z sieciami ad hoc duŝo dokładniej. Oprócz historii powstania tych sieci i dość szerokiego wstępu obejmującego sieci bezprzewodowe. W dalszej części czytelnik, będzie mógł zapoznać się ze sposobami rutowania pakietów w sieciach unicastowych poprzez wybrane protokoły rutowania. Natomiast kwintesencją i niejako podsumowaniem tego rozdziału, będzie wprowadzenie do rutowania multicastowego w sieciach ad hoc, poprzez wybrane 11

12 protokoły, gdzie kilka z nich będzie szeroko rozwiniętych w rozdziale 5 tej pracy. Zarówno protokoły unicastowe, jak i multicastowe zostały podzielone na grupy pod względem metody odświeŝania tablic rutingu. Pozwoli to w sposób jasny dostrzec róŝnice między tymi rodzajami komunikacji. Rozdział 5 to złoŝenie rozdziałów 3 i 4. Czytelnik powinien w tej chwili znać komunikację multicastową i wiedzieć co charakteryzuje sieci ad hoc, jak wygląda rutingu unicastowy w tych sieciach. Dzięki temu będzie mógł w sposób bardziej przejrzysty zapoznać się z obszerną charakterystyką wybranych protokołów, to jest z protokołami: MAODV, ODMRP, AMRoute, CAMP i MANSI, działającymi w ramach mobilnych multicastowych bezprzewodowych sieci ad hoc. Ostatni z nich, protokół MANSI stanowi najnowocześniejsze podejście do rutingu. Jest to protokół inteligentny, odwołujący się niejako do otaczającej nas natury. Protokoły uwzględnione w tym rozdziale nie zostały wybrane przypadkowo. KaŜdy z nich reprezentuje inną grupę, pod względem zarówno budowy, właściwości jak i działania. Pozwola to zrozumieć złoŝoność rutingu w mobilnych bezprzewodowych multicastowych sieciach ad hoc. W pracy tej zawarto równieŝ wyniki symulacji, których celem było zbadanie efektywności działania protokołu ODMRP pod względem takich parametrów, jak packet delivery ratio, packet transmission ratio, control packets per data packet delivered, control and data packets per data packet delivered. 12

13 3. Wprowadzenie do multicastingu. Transmisja multicast jest pośrednią formą komunikacji między powszechnie znaną techniką unicast charakteryzującą połączenie między dwoma punktami (jeden do jednego), gdzie kaŝdemu adresowi docelowemu przypisany jest jeden odbiorca, techniką broadcast (jeden do wielu), gdzie jednemu adresowi przypisanych jest wielu odbiorców, a techniką anycast (jeden do wielu), gdzie równieŝ jednemu adresowi przypisanych jest wielu odbiorców, ale tylko jeden z nich jest wybierany w danej chwili do odebrania danych od nadawcy.[40] Pozwala ona dostarczać dane tylko do wybranej grupy zera lub więcej odbiorców, którzy identyfikowani są za pomocą adresu grupowego (ang. multicast address). PrzynaleŜność do grup jest dynamiczna, oznacza to, Ŝe kaŝdy węzeł sieci moŝe w dowolnej chwili dołączać i opuszczać grupę multicastową. Nie ma Ŝadnych ograniczeń co do lokalizacji w danej grupie, ani co do liczby węzłów do niej naleŝącej.[3] Rys. 1 Schematy rutingu (a)anycast (b)broadcast (c)multicast (d)unicast [40] W sieciach przewodowych moŝna wyróŝnić dwa schematy sieci multicastowych: drzewo najkrótszej ścieŝki (ang. shortest path tree) i drzewo oparte o rdzeń (ang. core-based tree). [3] Pierwszy schemat gwarantuje najkrótszą ścieŝkę do kaŝdego celu, ale wymagane jest zbudowanie odrębnego drzewa dla kaŝdego źródła. Powoduje to utworzenie ogromnej ilości drzew w sieci, co moŝe nieść za sobą pewne konsekwencje np. wydajnościowe. [3] Drugi schemat nie zapewnia, tak jak w pierwszym przypadku, najkrótszej ścieŝki, ale tworzy tylko jedno drzewo dla całej grupy. Dzięki temu liczba drzew, które trzeba skonstruować, jest ograniczona. [3] 13

14 3.1. Multicasting w sieciach kablowych. W tym podrozdziale opisane zostaną dwa typy protokołów multicastowych, występujących w sieciach kablowych. Są to wspomniane juŝ wcześniej, drzewo najkrótszej ścieŝki i drzewo zbudowane na rdzeniu.[3] W pierwszym typie kaŝda ścieŝka od początku (korzenia) drzewa, w punkcie nadawcy, do końca drzewa, w punkcie odbiorcy jest tworzona w taki sposób, aby była moŝliwie najkrótsza. W protokole tym, aby zaistniał tryb rutowania multicastowego, kaŝdy węzeł tworzy własne drzewo rozpinające. W ten sposób pokryte są wszystkie hosty w sieci. Na przykład na rysunku 2(a) mamy sieć z dwoma grupami, 1 i 2. Niektóre węzły znajdują się w jednej bądź obydwu grupach na raz. Drzewo rozpinające dla węzła S pokazane jest na rysunku 2(b). [3] Rys. 2 Drzewo najkrótszej ścieŝki (a) sieć (b) spinning tree dla węzła S (c) drzewo grupa multicastowe dla grupy 1 (d) drzewo grupa multicastowe dla grupy 2 [3] Kiedy pakiet zostaje wysłany do grupy, pierwszy węzeł sprawdza swoje drzewo rozpinające usuwając wszystkie linie połączeń, na zakończeniu których znajdują się hosty nie naleŝące do tej grupy. Rysunek 2(c) pokazuje skrócone drzewo dla grupy nr 1, rysunek 2(d) przedstawia to samo drzewo dla grupy 2. Pakiety multicastowe są przesyłane tylko wzdłuŝ zatwierdzonego, sprawdzonego drzewa rozpinającego. Ten mechanizm ma jednak ogromną wadę jeśli chodzi o skalowalność, i kompletnie nie nadaje się do zastosowania w duŝych sieciach.[3] Drugi rodzaj algorytmu to tzw. drzewa oparte o rdzeń (Core-based tree), gdzie istnieje jeden, główny węzeł tzw. rdzeń, od którego odchodzą inne gałęzie drzewa. Na gałęzie te składają się pozostałe węzły, nie będące rdzeniem, które tworzą najkrótsze ścieŝki połączeń pomiędzy hostami uczestnikami tego drzewa. Węzeł tworzący ostatnią gałąź nazywany jest liściem. Rdzeń, topologicznie, nie musi znajdować się w centrum, pomiędzy wszystkimi węzłami tworzącymi dane drzewo. [3] 14

15 CBT wymaga, aby kaŝda grupa multicastowa miała swoje własne drzewo z rdzeniem. Węzeł moŝe dołączyć do grupy poprzez wysłanie pakietu Join Request. Ta wiadomość jest następnie przesyłana dalej po ścieŝce do rdzenia drzewa. Pakiet taki wędruje dopóki nie dotrze do rdzenia lub dopóki nie osiągnie węzła, który tworzy część danej grupy. W tym momencie procedura dołączania węzła kończy się i wysłana zostaje odpowiedź w postaci pakietu Join Ack. Dzięki tej wiadomości powstaje nowa gałąź w drzewie. Rysunek 3 przedstawia procedurę dołączenia węzła do grupy. [3] Rys. 3 Procedura dołączania do grupy w protokole CBT. [3] Węzeł nie będący rdzeniem moŝe opuścić daną grupę wysyłając pakiet Quit Request. Wiadomość ta moŝe zostać wysłana przez węzeł, w celu odłączenia się od drzewa, tylko jeśli nie są do niego dołączeni inni członkowie tej grupy multikastowej i jeśli otrzymał wiadomość Quit Request od wszystkich swoich dzieci w drzewie, dla tej grupy. Wiadomość ta wysyłana jest do rodzica danego węzła. Rodzic po jej otrzymaniu, natychmiast odpowiada pakietem Quit Ack i usuwa to dziecko z drzewa. KaŜdy węzeł nie będący rdzeniem wysyłając Quit Ack w odpowiedzi na otrzymany pakiet Quit Request powinien sam wysłać taką wiadomość wyŝej w hierarchii drzewa. NaleŜy przy tym pamiętać, Ŝe dla pakietu Quit Ack istnieje pewien timeout, po którego upłynięciu, węzeł jest automatycznie usuwany z drzewa.[3] Dla kaŝdego węzła nie będącego rdzeniem, jeśli jego rodzic lub ścieŝka prowadząca do jego rodzica w drzewie ulegną uszkodzeniu, istnieje jedno z dwóch rozwiązań. MoŜe spróbować powtórnie dołączyć do drzewa tworzącego grupę multicastową wysyłając pakiet Join Request do węzła najbliŝej połoŝonego przy rdzeniu, moŝe równieŝ wysłać wiadomość Flush Tree w dół swojej hierarchii, a to spowoduje, Ŝe kaŝdy węzeł, niezaleŝnie, będzie musiał wykonać procedurę przyłączenia 15

16 do drzewa. NaleŜy równieŝ pamiętać, Ŝe awarii ulec moŝe węzeł, pełniący funkcję rdzenia. W takim przypadku zadziała mechanizm podobny do tego z węzłów nie będących rdzeniem. Następuje ponowne zestawienie połączenia w drzewie i ponowne przyłączenie do drzewa. Kiedy rdzeń z restartuje połączenie nie posiada Ŝadnych informacji o drzewie dla którego był dotychczas rdzeniem. Jedynym sposobem, aby uzyskać takie informacje, jest wysyłany okresowo przez inne, naleŝące do danego drzewa, rutery, pakietu CBT Core Ping. Wiadomość ta domyślnie zawiera informacje o wszystkich rdzeniach w danej grupie, identyfikowanych numerem group-id. Rdzeń moŝe ponownie występować w tej roli odpowiadając na wcześniej wspomniany ping pakietem Join Request. [3] 3.2. Ogólna charakterystyka sieci ad hoc i multicastingu w tych sieciach. Najprostszym sposobem na pokazanie działania sieci ad hoc jest jej zobrazowanie poprzez konkretny przykład jej działania. Jeśli dwa węzły znajdują się w swoim zasięgu mogą komunikować się bezpośrednio ze sobą. W przeciwnym wypadku, komunikacja pomiędzy nimi będzie zaleŝała od innych węzłów w sieci. W sieci mobilnej ad hoc pokazanej na rysunku 4, węzły A i B są w swoim zasięgu (okręgi wokół punktów A i B). Jeśli host A potrzebuje wysłać pakiet do hosta B, moŝe to zrobić bezpośrednio. Z kolei węzły A i C nie są w swoim zasięgu, a oznacza to, Ŝe węzeł B posłuŝy w tej komunikacji jako ruter, przekazujący pakiety. Host wyśle najpierw pakiet do hosta B, a ten przekaŝe go dalej do węzła C. Pakiet powrotny będzie przesłany podobnie tyle, Ŝe w odwrotnej kolejności.[3] Rys. 4 Przykład mobilnej bezprzewodowej sieci ad hoc[3] W sieciach MANET istnieją trzy kategorie algorytmów multicastowych. Najprostsze podejście to proste zalewanie sieci pakietami (ang. flooding). KaŜdy węzeł 16

17 odbierając wiadomość zalewa nią wszystkich swoich sąsiadów. Tego typu sieć działa jak reakcja łańcuchowa i w rezultacie, ilość wysyłanych pakietów w krótkim odstępie czasu moŝe się gwałtownie rozrosnąć. Drugą kategorię stanowią algorytmy proaktywne, które starają się juŝ na początku znaleźć wszystkie moŝliwe ścieŝki do celu i przetrzymywać te informacje w swoich tablicach rutingu. Mając na uwadze nieustanne uaktualnianie informacji, co jakiś czas (z góry ustalony) wysyłana jest na całą sieć aktualizacja tablic rutingu. Ostatnią kategorię stanowią algorytmy reaktywne (tworzące ścieŝki do celu na Ŝądanie). Ich ideą jest to, Ŝe ścieŝka do celu tworzona jest w momencie kiedy host źródłowy chce wysłać pakiet. [3] 17

18 4. Rutowanie w sieciach bezprzewodowych ad hoc. Sieci bezprzewodowe, odkąd węzły nie są ograniczone poprzez fizyczną infrastrukturę, pozwalają na bardziej elastyczną komunikację. Istnieją dwie kategorie sieci mobilnych bezprzewodowych:[2] Sieci z pełną infrastrukturą (ang. infrastructured networks)[2] Sieci bez infrastruktury (ang. infrastructureless networks)[2] Pierwsza odmiana tych sieci składa się ze stacjonarnych stacji bazowych i mobilnych, bezprzewodowych stacji końcowych. Stacje bazowe podłączone są na stałe do normalnej sieci kablowej, działając jako bramy i punkty dostępowe dla punktów mobilnych. Hosty mobilne znajdując się w strefie zasięgu działania przynajmniej jednej stacji bazowej, komunikują się za jej pomocą z innymi stacjami i innymi hostami mobilnymi, w celu wymiany informacji. Rysunek 5 ilustruje przykład sieci z pełną infrastrukturą, gdzie BS(Stacja bazowa) i R (rutery dostępowe). Trasa pomiędzy hostami A i B moŝe wyglądać następująco A-BS1-R1-R3-BS2-B, natomiast pomiędzy hostami A i C A-BS1-C.[5] Rys. 5 Przykład sieci bezprzewodowej.[5] Sieci bez infrastruktury, lub sieci mobilne bezprzewodowe ad hoc (MANET) to przede wszystkim sieci, w których ruting oparty jest głównie na transmisji typu multihop. Oznacza to, Ŝe nie wszystkie stacje mogą znajdować się w swoim zasięgu, a zatem moŝe zaistnieć sytuacja, w której transmisja będzie wymagała wykorzystania węzłów pośredniczących, przekazujących ruch od nadawcy w kierunku odbiorcy.[5] Pod pojęciem mobilnej sieci ad hoc kryje się zdecentralizowana sieć bezprzewodowa, umoŝliwiająca przesyłanie danych pakietowych, gdzie mobilne stacje mogą pełnić funkcję zarówno klienta końcowego, jak i rutera. A więc, kaŝda stacja oprócz wykonywania aplikacji moŝe pośredniczyć w przekazywaniu dowolnego ruchu sieciowego. Cechą zaś istotnie odróŝniającą tego typu sieci od tradycyjnych jest to, Ŝe 18

19 do komunikacji nie jest konieczna Ŝadna dodatkowa infrastruktura sieciowa. Nie ma centralnego zarządzania siecią, jak równieŝ Ŝadna stacja nie ma ściśle określonego połoŝenia. Węzły takie mogą zmieniać lokalizacje, są dynamiczne. [8] Rysunek 6 przedstawia przykład sieci MANET. Okrąg wokół kaŝdej cyfry, która reprezentuje węzeł w sieci, wyznacza jego maksymalny zasięg transmisji. MoŜliwy ruting pomiędzy węzłami 1 i 2 to np lub [5] Rys. 6 Sieć ad hoc z zaznaczonym zasięgiem węzłów.[5] Sieci ad hoc mogą być zaimplementowane w róŝnych dziedzinach. Warto tutaj wspomnieć o wojskowości (brak centralnego punktu zarządzania), ratownictwie, czy chociaŝby o sieciach/aplikacjach sensorowych. NajwaŜniejszym jednak w tym wszystkim jest to, Ŝe dla kaŝdego rodzaju aplikacji, w zaleŝności od zastosowania, powstają róŝne wymagania co do protokołów rutingu. Na przykład w aplikacjach wykorzystywanych przez wojsko liczy się przede wszystkim mały wskaźnik wykrywalności i przechwycenia pomimo problemów z siecią, jakie mogą się pojawić w kaŝdej chwili. W aplikacjach sensorowych z kolei waŝna jest przede wszystkim małe zuŝycie energii, a w ratownictwie bezawaryjność i moŝliwość zapewnienia działania pewnych usług na z góry ustalonym poziomie (QoS).[3] Wszystkie aplikacje w sieciach ad hoc mają pewne cechy szczególne, odróŝniające je od siebie, a takŝe wymagania co do algorytmów realizujących ruting. Nie jest tutaj poŝądany bardzo duŝy ruch mogący powodować zatory w sieci, jak równieŝ częste zmiany stanu połączenia (ang.link change) powodujące zasypywanie hostów pakietami kontrolnymi, co powoduje nie potrzebne obciąŝanie łączy. Poza tym, mobilność zwiększa wymagania w komunikacji. RównieŜ ogromnym wyzwaniem staje się ograniczenie zuŝycia energii, gdyŝ jak wiadomo w sieciach MANET urządzenia bazują na zasilaniu bateryjnym.[3] 19

20 Tradycyjne unicastowe i multicastowe protokoły rutingu opierają się na statycznej lub prawie statycznej topologii sieci, gdzie w tablicach rutingu przetrzymywane są wszystkie moŝliwe trasy docelowe. Protokoły realizujące ruting w sieciach komórkowych, takie jak Mobile IP[9], przewidziane są do komunikacji radiowej uwzględniającej jeden przeskok (ang.single-hop), w którym przekazywanie informacji o rutingu uzaleŝnione jest od sieci kablowej. A zatem sieci MANET potrzebują swoich własnych algorytmów realizujących ruting, uwzględniających wszystkie potrzeby takich sieci wspomniane wcześniej.[5] PoniewaŜ węzły w sieciach mobilnych zmieniają swoje połoŝenie, zmienia się równieŝ topologia takiej sieci, a moŝe to następować szybko i dość niespodziewanie. Co więcej, istnieją limity ograniczające przepustowość sieci oraz energię, czerpaną ze źródeł bateryjnych.[3] Tradycyjne protokoły rutingu są przez to bardzo ograniczone, dlatego teŝ wymyślone zostały zupełnie inne algorytmu realizujące poprawną wymianę danych pomiędzy węzłami w sieciach ad hoc. 20

21 4.1. Ruting unicastowy w sieciach MANET. Ruting unicastowy to przesyłanie pakietów z jednego konkretnego węzła, do drugiego konkretnego węzła z moŝliwością wykorzystania węzłów pośredniczących w transmisji. Tradycyjny podział dzieli ten ruting na bazujący na aktualnych tablicach rutingu (ang. table-driven) i na reagujący na zmiany dopiero w momencie kiedy te wystąpią (ang. source-initiated). [5] Protokoły proaktywne(ang. proactive), bo tak inaczej nazywamy protokoły bazujące na aktualnych tablicach rutingu (ang. table-driven), przechowują informacje o topologii sieci, a takŝe trasy rutingu pomiędzy węzłami sieci, niezaleŝnie od tego, czy przesyłane są do nich dane, czy teŝ nie. Takie działanie narzuca pewien wymóg co do częstego, cyklicznego odświeŝania informacji o ścieŝkach w tablicach rutingu, którymi mają biec pakiety, w celu wyeliminowania tras juŝ nieaktualnych. Pozwala to uniknąć straty danych przy zrywaniu połączeń, bądź przy przeciąŝeniach łącz. JednakŜe trzeba pamiętać o tym, Ŝe szybkość aktualizacji tablic rutingu to zwiększona ilość przesyłanych pakietów, a to z kolei wpływa negatywnie na zuŝycie energii, szczególnie w urządzeniach przenośnych.[2][5] Protokoły reaktywne (ang. reactive) nazywane są równieŝ protokołami zainicjowanymi przez źródło, bądź protokołami rutingu na Ŝądanie (ang. on-demand). Jak sama nazwa wskazuje, wykonują one aktualizację trasy, bądź jej wyszukiwanie, w momencie wysyłania pakietu, a operację tę inicjuje źródło wysyłania pakietu. Proces poszukiwania ścieŝki dla pakietu kończy się w momencie znalezienia trasy, bądź w przypadku sprawdzenia wszystkich moŝliwości wysłania tego pakietu. Później zaimplementowany jest mechanizm, który decyduje jak długo takie trasy są aktualne i kiedy moŝna te wpisy usunąć. Taki system działania umoŝliwia w znaczny sposób zmniejszenie ilości danych przepływających przez sieć, co przekłada się równieŝ na oszczędności w energii.[2][5] Rys. 7 Klasyfikacja protokołów unicastowych w sieciach ad hoc.[5] 21

22 Protokoły proaktywne. W podrozdziale tym przedstawione zostaną wybrane protokoły z grupy proaktywnych, dzięki czemu moŝliwe jest przybliŝenie ich zasad i sposobów działania.[5] DSDV (Destination-Sequenced Distance-Vector Routing) [11] Jest on protokołem dystansowo wektorowym bazującym na klasycznym algorytmie Bellmana-Forda [12]. KaŜdy węzeł w sieci, broadcastowo, co pewien z góry ustalony okres czasu, rozsyła informacje na temat aktualnych wpisów w tablicy rutingu. Cechą szczególną tego protokołu jest to, Ŝe kaŝdy węzeł stosuje numer sekwencyjny (ang. Sequence Number). Jest on inkrementowany i wysyłany do sąsiednich węzłów, dzięki czemu, są one w stanie stwierdzić, które informacje, od którego węzła są aktualniejsze. Dany numer sekwencyjny moŝe być modyfikowany tylko przez swojego właściciela. Pozwala to uniknąć pętli w tablicach rutingu. [5] Reasumując węzły w protokole DSDV przesyłają swoim sąsiadom informacje zawarte w swojej tablicy rutingu. Pakiety z aktualizacjami zawierają wspomniany juŝ wcześniej numer sekwencyjny węzła, a takŝe adres docelowy celu, ilość skoków i następny skok do niego, a takŝe jego największy numer sekwencyjny. Węzeł, który otrzyma taki pakiet porównuje przysłane dane z juŝ posiadanymi wpisami w swojej tablicy rutingu i dokonuje w niej zmian, uwzględniając numer sekwencyjny i metrykę. W DSDV moŝemy wyróŝnić dwie tablice rutowania:[2] forwarding table posiada informacje pozwalające kierować ruchem w sieci[2] advertised route table odpowiada za rozsyłanie aktualizacji[2] Działanie protokołu pokazuje poniŝszy przykład. Rys. 8 Ruch w sieci ad hoc.[2] 22

23 CGSR (Cluster-Gateway Switching Routing) [13] Protokół ten uŝywa jako swego rodzaju schemat rutowania mechanizm protokołu DSDV, modyfikując go poprzez uŝycie hierarchicznej architektury i rutingu wykorzystującego tzw. klastry, czyli pewną grupę węzłów, na którą składają się: [5] stacja czołowa (ang. cluster head) zarządza danym klastrem[2] stacja graniczna (ang. gateway) znajduje się w obrębie dwóch, róŝnych klastrów, przekazuje ruch pomiędzy nimi[2] pozostałe węzły[2] Rys. 9 Budowa klastra.[2] Węzły mobilne formują klaster poprzez wybranie jednej stacji jako stacji czołowej, która będzie nim zarządzać. Wszystkie pozostałe węzły, które sformowały dany klaster muszą znajdować się w zasięgu działania stacji zarządzającej. Węzeł, który jest na granicy dwóch lub więcej róŝnych klastrów staje się stacją graniczną i pośredniczy w ruchu pomiędzy dwoma róŝnymi klastrami. Kiedy jakiś węzeł chce przesłać pakiet, najpierw ten wędruje do stacji czołowej. Jeśli cel nie naleŝy do danego klastra, stacja ta przesyła ten pakiet do stacji granicznej, znajdującej się równieŝ w innym klastrze. Następnie pakiet ten wędruje znów do stacji czołowej, tyle, Ŝe zarządzającej innym klastrem. Operacja ta jest powtarzana dopóki cel nie zostanie osiągnięty. Protokół ten korzysta z algorytmu LLC(Least Cluster Change) w celu utrzymania stacji czołowej w stanie niezmienionym tak długo jak to tylko moŝliwe. KaŜdy węzeł posiada tablicę rutingu z listą tras do stacji czołowych w innych klastrach. Pozwala ona znaleźć adres stacji czołowej klastra, do którego naleŝy stacja docelowa pakietu, który chcemy wysłać. Istnieje równieŝ tablica, która posiada wpisy z kolejnymi węzłami na trasie do celu. W CGSR tablica rutowania jest mniejsza, jednakŝe 23

24 przeciąŝenia powodowane przez okresowe rozsyłanie aktualizacji tras, a takŝe tablic członków klastrów, powodują, Ŝe jest on zbliŝony wydajnością do DSDV.[5] Rys. 10 CGSR: trasowanie od węzła 1 do 8[24] WRP (Wireless Routing Protocol) [14] Jest to kolejny proaktywny dystansowo wektorowy protokół rutowania w sieciach MANET. [5] Pojawiają się tutaj aŝ 4 tablice: tablica rutingu, tablica odległości (ang. distance table), tablica kosztów połączeń(ang. link-cost table) i tablica listy wiadomości retransmitowanych (ang. MRL message retransmission list table), które okresowo są rozgłaszane.[2] W tablicy rutingu przechowywane są: odległość od celu, poprzedni (ang. predecessor) węzeł na trasie, następny (ang. successor) węzeł na trasie, a takŝe znacznik, który pozwala zidentyfikować, czy dana trasa jest normalną ścieŝką dla pakietu, pętlą, czy teŝ w ogóle jest nieprawidłowa. Tablica odległości posiada informacje na temat dystansu do węzłów docelowych, a takŝe kombinacji par cel-kaŝdy sąsiad. Przechowuje równieŝ, zgłoszone przez sąsiadów, informacje na temat poprzedników dla kaŝdej z tras. Tablica kosztów połączeń trzyma informacje o wartości połączeń z sąsiadami oraz liczbę wiadomości uaktualniających tablice, które dotarły od ostatniego błędu ich przesłania. Tablica MRL utrzymuje informacje w celu znalezienia sąsiadów, którzy nie otrzymali informacji uaktualniających.[5] Zapisywane jest w niej, które dane powinny zostać wysłane powtórnie i którzy sąsiedzi są odpowiedzialni za ich otrzymanie (potwierdzane pakietem ACK).[2] Protokół ten pozwala nam uniknąć pętli dzięki wykorzystaniu informacji o całej trasie (ang. second-to-lasthop). Przesyłana jest ona do celu wraz zawartą odległością między węzłami. Dzięki temu dla wszystkich węzłów znani są uczestnicy danej trasy. KaŜdy węzeł sprawdza poprzedników na trasach zgłaszanych przez sąsiadów. W momencie zgłoszenia przez sąsiadów, kaŝdy węzeł sprawdza swoich poprzedników na danej trasie. Dzięki takiemu mechanizmowi udaje się przyspieszyć proces rutingu, a takŝe zwiększyć stabilność sieci.[2] 24

25 Protokoły reaktywne. W podrozdziale tym omówionych zostanie kilka wybranych protokołów aktualizujących tablice rutingu na Ŝądanie (ang. on demand). DSR (Dynamic Source Ruting). [15] Dwie cechy szczególne tego protokołu to kierowanie pakietów przez ruting źródłowy (ang. source routing), i wykorzystanie zestawów tras, przechowywanych w pamięci podręcznej (ang. route cache). Ruting źródłowy umoŝliwia przesyłanie pakietów bez zapętleń, zapobiega potrzebie aktualizacji tras w tablicach rutingu, a takŝe pozwala węzłom przechowywać informacje na temat rutingu w pamięci podręcznej. Zbudowany jest on z dwóch mechanizmów, wykrywania tras (ang. route discovery) i zarządzania trasami (ang. route maintenance). Wykrywanie tras polega na przesyłaniu pakietów, typu RREQ(ang. route request), czyli zapytania o trasę i RREP(ang. route reply), czyli odpowiedzi na Ŝądanie, przez węzeł S(source) chcący wysłać pakiet do celu D (destination), pod warunkiem, Ŝe trasy do węzła docelowego nie znaleziono w pamięci podręcznej. Węzeł S rozgłasza pakiet RREQ w sieci, który zawiera takie pola jak: adres źródłowy hosta wysyłającego pakiet, adres docelowy celu, unikalny identyfikator, który pozwoli rozpoznać dane Ŝądanie, i rekordy trasy, w których dopisywane są kolejne adresy węzłów, pośredniczących w transmisji.[3][31] KaŜdy węzeł, który otrzyma pakiet RREQ moŝe odpowiedzieć do źródła jego wysłania S pakietem RREP, pod warunkiem, Ŝe zna trasę do celu D (posiada odpowiedni wpis w pamięci podręcznej). W takiej sytuacji ścieŝka do celu jest złoŝeniem dwóch tras, trasy od źródła S do węzła, który wysłał pakiet RREP i od tego węzła do celu D. MoŜe równieŝ odrzucić taki pakiet, jeśli juŝ go poprzednio otrzymał. W innym przypadku węzeł taki, dodaje swój identyfikator w rekordzie trasy i rozgłasza pakiet RREQ dalej, do swoich sąsiadów.[3] Węzeł docelowy, który otrzyma pakiet RREQ odpowiada na to Ŝądanie pakietem RREP. Pakiet ten jest przesyłany przez wszystkie węzły, z powrotem do źródła S, których wpisy umieszczone są w rekordzie rutingu, oczywiście w odwrotnej kolejności. Rysunki 11 i 12 przedstawiają wykrywanie trasy w protokole DSR.[3] 25

26 Rys. 11 Wyszukiwanie trasy w protokole DSR[3] Rys. 12 Przykład odpowiedzi na zapytanie o trasę w protokole DSR.[3] Mechanizm utrzymania tras działa w sposób następujący. W momencie kiedy węzeł odkryje problem w łączności z węzłem, będącym następnym skokiem w jego tablicy rutingu, usuwa on wpis, dotyczący takiej trasy, z pamięci podręcznej i wysyła do hosta źródłowego S wiadomość kontrolną z kodem błędu (ang. Router Error). Host źródłowy po otrzymaniu takie wiadomości rozpoczyna na nowo wyszukiwanie trasy do celu.[3] Zarządzanie pamięcią podręczną w protokole DSR jest na bardzo wysokim poziomie, co pozwala uzyskiwać bardzo dobre wyniki wydajnościowe, najlepiej widoczne podczas zwiększonego ruchu sieciowego.[3] W protokole tym zostało zaproponowanych kilka metod optymalizacyjnych, podnoszących jego wydajność. JednakŜe praca ta w swoim załoŝeniu nie ma za zadanie opisywania wszystkich moŝliwych protokołów występujących w sieciach ad hoc, a jedynie pokazanie najciekawszych przykładów, róŝniących się znacznie od siebie.[3] 26

27 AODV(Ad Hoc On Demand Distance Victor)[3] Protokół ten bazuje na mechanizmach zastosowanych w algorytmie DSDV. AODV jest ulepszeniem tego protokołu, poniewaŝ minimalizuje liczbę wysyłanych pakietów broadcastowych dzięki wyszukiwaniu trasy na Ŝądanie.[3] Mechanizm działania tego protokołu pozwala na szybkie odkrywanie tras i umoŝliwia nie przechowywanie informacji o węzłach nieaktywnych. Cechuje go równieŝ szybkie reagowanie na zmiany w topologii sieci. W momencie zerwania połączenia, inne węzły są o tym informowane. Zastosowano tutaj równieŝ numer sekwencyjny do oznaczania tras, dzięki czemu pozwala to uniknąć pętli w trasach rutingu. [2] W momencie kiedy węzeł źródłowy S chce wysłać pakiet do węzła docelowego D i nie posiada aktualnej trasy do celu, inicjuje proces jej wyszukania. Rozsyła Ŝądanie trasy RREQ (ang. route-reuest) do swoich sąsiadów. Ci z kolei przekazują je dalej do swoich sąsiadów, i proces ten trwa dopóki, dopóty nie zostanie odnaleziony węzeł docelowy D, lub nie zostanie znaleziony węzeł, który posiada wpisy w swojej tablicy rutingu, pozwalające zlokalizować węzeł D. Rysunek 13 ilustruje Ŝądanie trasy RREQ w sieci.[2] W pakiecie RREQ zawarte są takie informacje, jak numer sekwencyjny, węzeł docelowy, identyfikator zapytania i dane o węźle źródłowym. Identyfikator zapytania jest liczbą, inkrementowaną dla kaŝdego zapytania RREQ, które węzeł generuje. Tak samo zresztą numer sekwencyjny, to liczba, która przy kaŝdorazowym rozpoczęciu wyszukania trasy lub przy odpowiedzi na takie Ŝądanie jest zwiększana. Wspomniane powyŝej ID(identyfikator) i SN(numer sekwencyjny) pozwalają w sposób jednoznaczny zidentyfikować zapytania RREQ. Dzięki takiemu rozwiązaniu węzły unikają wielokrotnego przetwarzania tych samych informacji.[2] Węzły pośrednio biorące udział w przekazywaniu pakietów RREQ, na podstawie informacji o stacji źródłowej umieszczonych w zapytaniu, uzupełniają dane o trasie do tej stacji, tworząc w ten sposób trasę powrotną (ang. reverse path). [2] Węzeł docelowy po otrzymaniu Ŝądania RREQ odpowiada pakietem RREP (ang. Route Request Replay), umieszczając w nim swój adres i numer sekwencyjny. Pakiet ten przesyłany jest z powrotem do węzła źródłowego wcześniej wspomnianą trasą powrotną. Wszystkie węzły, przez które przechodzi pakiet RREP uaktualniają swoje tablice rutingu o trasę, która przed chwilą została ustalona. W ten sposób powstaje komunikacja dwukierunkowa pomiędzy stacjami. [2] 27

28 W protokole tym pojawia się równieŝ licznik czasu, po upłynięciu którego, usuwana jest trasa z tablicy rutingu i w przypadku ponowionej transmisji, musi ona zostać odkryta od początku. Jeśli ścieŝka ta jest uŝywana, licznik jest aktualizowany.[2] Rys. 13 Wyszukiwanie trasy do węzła i ścieŝka powrotu w AODV.[3] Rys. 14 Przykład trasy przekazywania pakietu w AODV. [3] LMR (Lightweight Mobile Routing) [16] i TORA (Temporally-Ordered Routing Algorithm) [17] Są to protokoły unicastowe, działające na Ŝądanie, bazujące na algorytmie Gafni-Bertsekasa[32], który konstruuje zorientowany na host docelowy graf DAG(Directed Acyclic Graph), pozwalający na utworzenie wielu ścieŝek do jednego celu. Korzeniem tego grafu jest host docelowy. Pakiety przesyłane są w górę lub w dół grafu. Węzły mogą przesyłać dane wzdłuŝ trasy z góry do dołu w grafie DAG, dopóki host docelowy nie zostanie osiągnięty. Tylko węzeł końcowy nie posiada dolnych 28

29 sąsiadów, do których mógłby przesłać pakiet. Taki mechanizm pozwala uniknąć pętli. Oba protokoły posiadają 3 bardzo podobne mechanizmy: konstruowanie tras (ang. Route Construction), utrzymanie tras (ang. Route Maintenance) i niszczenie tras (ang. Route Destruction). Konstruowanie tras jest procesem grafu DAG. Źródło zakłada, Ŝe posiada trasę do celu dopóki istnieje choćby jeden dolny sąsiad. Tylko kiedy węzeł straci ostatnią trasę do węzła docelowego i jeśli węzeł ten nadal jej potrzebuje włącza się mechanizm utrzymania tras. Mechanizm niszczenia tras jest uŝywany do czyszczenia błędnych tras w sieci. W protokole TORA, węzły uŝywają wysokości metryk do ustanowienia grafu DAG. Na podstawie wysokości metryk ustanawiane są kierunki połączeń pomiędzy węzłami. Podczas transmisji, węzeł moŝe przesyłać pakiet tylko do takiego, który ma niŝszą metrykę. Taki sposób rutowania powoduje, Ŝe w przypadku straty jednej trasy, praktycznie natychmiast mamy inną. Tak samo, ograniczony mamy przesył wiadomości kontrolnych, dzięki czemu zwiększa się wydajnośc sieci.[5] Rys. 15 Przykład grafu DAG. [3] Na zakończenie tego podrozdziału porównanie protokołów unicastowych: Tabela 1 Porównanie protokołów proaktywnych.[3] 29

30 Tabela 2 Porównanie protokołów reaktywnych.[3] 30

31 4.2. Ruting multicastowy w sieciach MANET. Protokoły przedstawione powyŝej mają za zadanie tylko przybliŝyć tematykę rutingu w sieciach ad hoc. Podział jaki został pokazany nie był przypadkowy, gdyŝ w przypadku grupy protokołów, która zostanie omówiona za chwilę, będzie podobnie, a więc protokoły zostaną podzielone na proaktywne i reaktywne. Dodatkowo pojawią się równieŝ nowe podziały, które moŝna zaobserwować, ze względu na budowę, tylko w protokołach sieci multicastowych. Multicasting odgrywa bardzo waŝną rolę w komunikacji w sieciach mobilnych bezprzewodowych ad hoc. Poprzez wysyłanie tej samej porcji informacji do wielu odbiorców w sieci moŝemy zredukować przepustowość potrzebną do wysyłania danych, a takŝe ograniczyć zuŝycie energii w punktach mobilnych.[5] Dla multicastingu dana grupa multicastowa zbudowana jest z jednej lub wielu grup uŝytkowników, która odpowiedzialna jest za otrzymywanie i przechowywanie informacji wysyłanych do tej grupy multicastowej. Dodać naleŝy, iŝ kaŝda grupa posiada swój własny identyfikator, którym jest jej adres multicastowy, przypisany do kaŝdej grupy unikatowo, to znaczy niepowtarzalnie. Inną cechą jest to, Ŝe w dowolnym momencie kaŝdy węzeł moŝe dołączyć do grupy multicastowej, lub węzeł juŝ do niej naleŝący moŝe ją opuścić. W sieciach MANET uczestnicy grupy są mobilni, czyli mogą poruszać się w dowolny sposób.[5] W przypadku komunikacji w sieci, głównie poprzez dostarczanie pakietów, a takŝe zarządzanie grupami multicastowymi, moŝe powodować najróŝniejsze problemy. Protokoły multicastowe stworzone na potrzeby MANET-u, mają właśnie tego typu problemy przewidywać i im przeciwdziałać. W chwili obecnej jest ich kilkanaście, jednak w celu wyczerpującego wyjaśnienia tematu wystarczy kilka podstawowych. [5] Przekrój tych protokołów, a takŝe ich przynaleŝność do grup, pod względem funkcjonalności i charakterystyki, przedstawia poniŝszy rysunek: 31

32 Rys. 16 Klasyfikacja protokołów multicastowych w sieciach ad hoc.[5] Pierwszy podział następuje ze względu na strukturę multicastową, drugi ze względu na częstotliwość odświeŝania tablic rutingu. Praca ta koncentruje się, w głównej mierze, właśnie na tych protokołach. W dalszej części pracy omówiona zostanie większa część protokołów widocznych na rysunku powyŝej. Poznamy dzięki temu ich budowę, i schematy działania, a to pozwoli nam z kolei uzyskać informacje na temat róŝnorodności rutingu w sieciach mobilnych bezprzewodowych ad hoc. 32

33 Protokoły drzewo-strukturalne. Istnieją dwie wersje protokołów drzewo-strukturalnych w sieciach MANET: - drzewo źródłowe (ang. Source-based multicast tree)[3] - drzewo współdzielone (ang. Single shared multicast tree )[3] Drzewa źródłowe są tworzone dla kaŝdego węzła naleŝącego do danej grupy multicastowej. Plusem takiego rozwiązania jest to, Ŝe kaŝdy pakiet przesyłany jest najkrótszą, najbardziej wydajną ścieŝką od nadawcy do kaŝdego uczestnika grupy multicastowej. JednakŜe są i minusy takiego rozwiązania. Przede wszystkim pojawiają się problemy z nadmiernym ruchem kontrolnym w sieci, a takŝe protokoły z tej grupy nie są zbyt dobrze przystosowane do pracy z węzłami mobilnymi.[3] Z drugiej jednak strony, drzewa współdzielone są bardziej skalowalne od wspomnianych wcześniej drzew źródłowych. Zamiast budowy wielu drzew w kaŝdej grupie multicastowej, zastosowano jedno drzewo, współdzielone przez wszystkie węzły naleŝące do danej grupy. Pakiety multicastowe są dystrybuowane wzdłuŝ takiego drzewa do wszystkich uczestników grupy. Aby powstało drzewo współdzielone, jeden węzeł wybierany jest jako rdzeń (ang. core node) i odpowiedzialny jest on za tworzenie i zarządzanie tym drzewem. W utworzonym drzewie mogą istnieć połączenia jedno lub wielo kierunkowe. (ang. unidirectional, bidirectional links). W drzewie współdzielonym z połączeniami jednokierunkowymi, pakiety multicastowe przesyłane są unicastowo do rdzenia w drzewie, który jest jednocześnie korzeniem danego drzewa. Dopiero stąd są rozsyłane dalej wzdłuŝ całej struktury.[3] Rys. 17 Przykład struktury drzewiastej.[3] W drzewach współdzielonych z wielokierunkowymi połączeniami nie ma znaczenia, którędy docierają pakiety multicastowe i są one dystrybuowane od razu na 33

34 wszystkie gałęzie w tym drzewie. W grupie tej istnieją mniejsze przeciąŝenia sieci, jednakŝe nie zawsze ścieŝki są tak optymalne jak w drzewach źródłowych.[3] Rysunek 17 przedstawia przykład drzewa współdzielonego z połączeniami jednokierunkowymi. Drzewo składa się z korzenia (r), czterech węzłów pośredniczących(p,q,s,t), siedmiu odbiorców naleŝących do tej samej grupy multicastowej (kolor szary), i z 11 połączeń pomiędzy węzłami. W drzewie współdzielonym, odbiorca co jakiś czas wysyła pakiet Join Request do korzenia, a ten z kolei na podstawie informacji o ścieŝkach, zawartych w tych pakietach, aktualizuje strukturę drzewa multicastowego. Przy procedurze dołączenia węzła wymagane jest wysyłania pakietów Join Request (sender), natomiast w przypadku, gdy jakiś węzeł chce opuścić daną grupę multicastową, nie musi podejmować Ŝadnej akcji. Wspomniano wcześniej o periodycznym wysyłaniu pakietów, które mają na celu aktualizacje stanu faktycznego drzewa. NaleŜy jednak zauwaŝyć, Ŝe czas, który decyduje o częstotliwości wysyłania tych pakietów, powinien być dobrany z duŝą dozą ostroŝności, aby ustrzec się przed zbyt ich częstym wysyłaniem, a co za tym idzie, Ŝeby ustrzec się przed przeciąŝeniem sieci. Jednocześnie czas ten nie moŝe być zbyt długi, gdyŝ trzeba pamiętać, Ŝe węzły mogą zmieniać połoŝenie i informacje o tym, powinny być utrzymywane na bieŝąco.[3] Zaproponowano bardzo zróŝnicowane protokoły drzewo-strukturalne, które zostaną przedstawione poniŝej w sposób bardzo krótki i zwięzły:[3] Adhoc Multicast Routing Protocol (AMRoute) jest proaktywnym drzewo-strukturalnym protokołem multicastowym, uŝywającym unikastowych tuneli IP-IP do stworzenia, a zarazem połączenia w pary uŝytkowników danej grupy. Dzięki temu ruch odbywa się tylko w ramach uczestników danej grupy multicastowej. W protokole tym istnieje przynajmniej jeden logiczny rdzeń w kaŝdej grupie, który odpowiedzialny jest za odkrywanie nowych członków grupy, a takŝe za tworzenie drzewa multicastowego, dzięki któremu moŝliwe będzie przesyłanie danych. Początkowo, w momencie tworzenia grupy multicastowej, kaŝdy uczestnik deklaruje siebie samego jako rdzeń, który okresowo rozgłasza pakiety Join-Req w celu znalezienia innych członków danej grupy. Kiedy pakiet ten osiągnie cel, znaleziony węzeł odpowiada pakietem Join-Ack i zaznacza go jako swojego sąsiada. Węzeł, który z kolei otrzymał odpowiedź, oznacza tego pierwszego jako swojego sąsiada. Dzięki takiemu schematowi postępowania tworzona jest siatka tuneli pomiędzy parami uczestników danej grupy multicastowej. 34

35 W momencie kiedy jakiś uŝytkownik chce opuścić grupę, w której aktualnie się znajduje, rozsyła do swoich sąsiadów pakiet Join-NAK, a takŝe przestaje rozsyłać jakiekolwiek informacje. Podczas, gdy struktura siatki w tym protokole jest stosowana do połączenia uŝytkowników w pary, struktura drzewa uŝywana jest do wymiany danych, a tym samym do rozsyłania informacji. Kiedy siatka zostaje juŝ stworzona, rdzeń okresowo rozsyła pakiet Tree-Create (tł. budowanie drzewa) do swoich sąsiadów poprzez tunele, dzięki czemu buduje współdzielone drzewa (and. shared tree). Kiedy jeden z węzłów otrzyma taki pakiet i nie jest on duplikatem, przesyła go dalej, do wszystkich swoich sąsiadów. Jeśli jednak taki węzęł otrzyma zduplikowany juŝ pakiet Tree-Create, odsyła na drugą stronę tunelu pakiet Tree-Create-NAK. Węzęł będący po drugiej stronie tego tunelu, który otrzyma taką odpowiedź, oznacza go jako niezdolnego do transmisji danych. W ten właśnie sposób tworzona jest struktura drzewa uŝywając jako podzbioru struktury siatki. Reasumując, protokół AMRoute tworząc strukturę siatki w postaci tuneli pomiędzy węzłami, tworzy drzewo multicastowe. Dlatego teŝ, tak długo jak tylko trasy rutingu pomiędzy uczestnikami drzewa istnieją poprzez stworzoną siatkę tuneli, drzewo będzie się w stanie zbudować, nawet w przypadku zmian w topologii. RównieŜ waŝne jest, iŝ węzły, które nie są uczestnikami danej grupy multicastowej nie potrzebują obsługi(znajomości) Ŝadnego protokołu multicastowego. Z drugiej jednak strony, jedną z wad tego protokołu jest to, iŝ istnieje szansa na powstanie pętli pomiędzy tunelami.[3] Ad-hoc On-Demand Distance Vector Multicast Protocol (MAODV) jest protokołem drzewo-strukturalno reaktywnym zdolnym do realizacji komunikacji multicastowej. Trasy rutingu odkrywane są na Ŝądanie przy pomocy mechanizmu rozgłaszania tras.[3] Protokół ten tworzy dwukierunkowe współdzielone multicastowe drzewa łącząc w ten sposób nadawców i odbiorców. UŜywając tego protokołu moŝemy być równieŝ pewni, Ŝe nie będzie on tworzył pętli, dzięki uŝyciu multicastowej liczbowej sekwencji identyfikacyjnej. Cechą tego protokołu jest równieŝ szybkie reagowanie na zmiany w topologii sieci. Szerzej protokół ten będzie omówiony w dalszej części pracy.[26] 35

36 Ad hoc Multicast Routing protocol utilizing Increasing-idS(AMRIS) jest kolejnym protokołem z grupy proaktywnych drzewo-strukturalnych. Jego główną ideą jest to, Ŝe kaŝdy węzeł jest oznaczany (ang. tag) własnym nie powtarzalnym numerem sesji multicastowej (ang. multicast session member ID-msm- ID), który pozwala zbudować drzewo DAG, gdzie korzeniem jest tzw. Sid, czyli specjalny węzeł, najczęściej nadawca, rozgłaszający pakiet New-Session. Jeśli wiadomość ta rozsyłana jest w celu rozpoczęcia nowej sesji multicastowej, w pakiecie New-Session zawierane jest msm-id węzła pełniącego rolę Sid. W przypadku sąsiadów, jeśli pakiet New-Session nie jest duplikatem, msm-id zwiększane jest tak, aby było większe od wartości, która dotarła wraz z tym pakietem. Następnie wiadomość ta jest rozgłaszana ponownie, z odpowiednio zwiększoną wartością msm-id węzła wysyłającego ten pakiet. W ten sposób msm-id jest zwiększane promieniście od Sid i wykluczając sam korzeń, kaŝdy węzeł moŝe mieć potencjalnie rodzica (ang. parent), którego numer sesji multicastowej jest mniejszy od jego własnego. Węzeł moŝe dołączyć do sesji multicastowej poprzez wysłanie unikastowo Join-Req, który wędruje wzdłuŝ trasy rutingu do odpowiednich rodziców z coraz mniejszymi wartościami msm- ID. W momencie, kiedy pakiet dotrze do członka naleŝącego do danej grupy multicastowej odsyłana jest wiadomość w postaci pakietu Join-ACK. Tworzy się w ten sposób para rodzic-dziecko, co w drzewie odzwierciedlone jest jako gałąź. JeŜeli węzeł chcący dołączyć do grupy multicastowej nie otrzyma odpowiedzi rozsyła on pakiet Join-Req, tym razem na adres broadcastowy w poszukiwaniu węzłów mogących być potencjalnymi rodzicami. W momencie zerwania połączenia, węzeł wysyła pakiet Join- Req do wszystkich potencjalnych rodziców. Zasadą działania tego protokołu jest to, Ŝe kaŝdy węzeł moŝe mieć co najwyŝej jednego rodzica, a schemat rozsyłania msm-id i znajdywania swoich rodziców pozwala tworzyć pary rodzic/dziecko, które przekładają się na stworzenie struktury drzewa. Dane przesyłane są przez ścieŝki w drzewie. W sieci, gdzie ilość przesyłanych danych, albo mobilność zwiększa się znacznie, w stosunku do całej sieci, osiągi tego protokołu mogą nie być zadowalające, głównie ze względu na wymóg ustanawiania i utrzymywania relacji pomiędzy węzłami.[5] 36

37 Protokoły siatko-strukturalne. Protokoły o strukturze siatki zapewniając więcej niŝ jedną ścieŝkę rutingu pomiędzy parą uczestników danej grupy multicastowej, tworzą ogromne moŝliwości redundancji połączeń. [5] Rysunek 18 przedstawia przykład struktury siatki multicastowej dla sieci MANET z rysunku 17. MoŜna zauwaŝyć trzy redundantne połączenia (zaznaczone na rysunku charakterystyczną linią przerywaną). Dzięki temu, nawet jeśli połączenie pomiędzy węzłami s i v zostanie przerwane, węzeł v nadal będzie otrzymywał pakiety multicastowe, dzięki redundantnemu połaczeniu z t do v. Protokoły siatko strukturalne są bardziej przystosowane do szeroko pojętej mobilności i zapewniają większą pewność w dostarczeniu pakietu do celu (ang. packet delivery ratio). [3] Rys. 18 Przykład struktury siatki.[3] Oto kilka przykładowych protokołów tej grupy: Multicast Core-Extraction Distributed Ad Hoc Routing (MCEDAR) [19] jest rozszerzeniem protokołu CEDAR.[38] W tym wypadku protokół CEDAR uzyskuje węzły mogące być rdzeniami, MCEDAR z kolei uzyskuje podgrafy, tzw. mgrafy (ang. mgraph) dla kaŝdej grupy multicastowej, składające się wyłącznie z węzłów będących rdzeniami zdolnymi do przesyłania informacji.[3] Clustered Group Multicast (CGM) [20] składa się z agentów zapraszających (ang. advertising agents), w celu zredukowania ruchu sieciowego, którzy działają jednocześnie jako serwer i klient dla obsługi Ŝądań dołączenia. Zarządcy klastra działają jako agenci zapraszający, jeśli jeden lub więcej subskrybentów znajduje się w klastrze. [3] 37

38 Core-Assisted Mesh Protocol (CAMP)[21]. W protokole tym węzeł chcąc dołączyć do multicastowej siatki najpierw negocjuje tablicę rutingu, aby ustalić czy istnieją jego sąsiedzi, naleŝący juŝ do tej siatki. Jeśli tak, węzeł ogłasza swój udział w grupie. W innym wypadku wysyła Ŝądanie dołączenia do najbliŝszej grupy multicastowej lub stara się osiągnąć ruter, który jest członkiem danej grupy multicastowej.[3] On-Demand Multicast Routing Protocol (ODMRP) [27] zbudowany jest na architekturze Ŝądań, które pozwalają uniknąć zatorów w sieci i zwiększają skalowalność. Protokół ten korzysta z koncepcji grup przekazywania (ang. forwarding group), gdzie siatka węzłów odpowiedzialna jest za przekazywanie danych multicastowych po najkrótszej ścieŝce, pomiędzy kaŝdą parą uczestników grupy. Podczas wysyłania wiadomości kontrolnych pomiędzy odbiorcami, a wysyłającymi, węzeł moŝe zdać sobie sprawę, Ŝe jest tylko częścią grupy przekazywania danych.[3] Neighbor Supporting Multicast Protocol (NSMP) [22] redukuje węzły, aby zlikwidować przeciąŝenia procedury odzyskiwania rutingu i zapewnia zarządzanie siatką. Nowe źródło inicjuje transmisję wysyłając pakiet FLOOD REQ(FR) zawierający to co znajduje się wyŝej niego. Kiedy węzeł odbierze taką wiadomość, przechowuje w pamięci podręcznej następny węzeł w hierarchii i aktualizuje pola z własnymi adresami przekierowań. Kiedy odbiorca otrzyma pakiet FR, wysyła z powrotem REP. Węzeł powyŝej w hierarchii otrzymując pakiety REP, uaktualnia tablice rutowania, natomiast sam pakiet jest kierowany dalej do źródła..[3] 38

39 5. Ruting multicastowy w sieciach mobilnych bezprzewodowych ad hoc. Dzięki zapoznaniu się z rozdziałem 3, czyli z pojęciem multicastingu i podstawami działania sieci multicastowych, a takŝe z rozdziałem 4, w którym omówionych zostało kilka waŝnych aspektów sieci ad hoc, a przede wszystkim po uzyskaniu informacji o tym jak realizowany jest ruting unicastowy i co go charakteryzuje, a takŝe po uzyskaniu ogólnych informacji o rutingu multikastowym w sieciach ad hoc, moŝna przejść do kolejnego etapu pracy, czyli rozdziału 5. W rozdziale tym wybrane protokoły multicastowe sieci ad hoc, wspomniane w rozdziale 4, zostaną szczegółowo omówione i przedstawione, dzięki czemu, moŝna będzie zapoznać się z duŝą róŝnorodnością w budowie i działaniu pomiędzy poszczególnymi protokołami, reprezentującymi pewne grupy, z których się wywodzą. KaŜdy protokół to tak naprawdę odrębne podejście do rutowania pakietów w sieciach multicastowych ad hoc, a to przekłada się przede wszystkim na róŝne wyniki w wydajności danego protokołu. Jeden z tych protokołów zostanie zasymulowany, a dzięki wynikom jakie uzyskamy będzie moŝna określić jego przydatność w rzeczywistości. 39

40 5.1. Protokoły reaktywne Multicast Ad Hoc On-Demand Distance Vector (MAODV). Protokół MAODV jest multicastowym rozwinięciem unicastowego protokołu AODV. Trasy rutingu wyszukiwane są na Ŝądanie z uŝyciem mechanizmu broadcastowego. MAODV tworzy dwukierunkowe współdzielone drzewa multicastowe, łącząc w ten sposób nadawców i odbiorców. Dzięki zastosowaniu numeru sekwencyjnego w protokole tym nie występują zapętlenia. Zapewnia on równieŝ duŝą stabilność nawet w przypadku zmian w topologii sieci.[25] Procedura wyszukiwania tras. (ang. Multicast Route Discovery) Rys. 19 Wyszykiwanie trasy w protokole MAODV.[25] Mobilny węzeł w chwili kiedy chce dołączyć do grupy multicastowej, lub kiedy ma dane do wysłania do tej grupy, ale nie zna do niej trasy, wysyła wiadomość Ŝądania trasy (ang. Route Request RREQ). Jeśli dotyczy ona dołączenia do grupy to wiadomość jest wysyłana z ustawioną flagą dołączenia J (ang. join flag). Adres docelowy w pakiecie RREQ jest zawsze ustawiany na adres grupy multicastowej. Jeśli nadawca zna lidera grupy i posiada aktualną trasę do niego, moŝe zamiennie wstawić jego adres, a następnie wysłać unicastowo pakiet RREQ do niego poprzez następny skok, uwzględniony w tablicy rutingu. Jeśli jednak węzeł nie posiada trasy do lidera grupy, lub tym bardziej nie zna jego adresu, wysyła broadcastowo pakiet RREQ. [25] W przypadku, gdy jakiś węzeł otrzyma pakiet RREQ, najpierw sprawdza czy oznaczony jest flagą J (join). Jeśli jest, odpowiedzieć moŝe tylko węzeł będący 40

41 uczestnikiem danej grupy posiadający numer sekwencyjny grupy co najmniej taki, jak zawarty w otrzymanym pakiecie RREQ. Natomiast jeśli nie jest to Ŝądanie dołączenia, odpowiedzieć moŝe kaŝdy węzeł z aktualną trasą do tej grupy, pod warunkiem, Ŝe spełniony jest wymóg, co do numeru sekwencyjnego, wspomniany wcześniej.[25] Jeśli jednak dany węzeł nie spełnia Ŝadnego z tych warunków, rozsyła on na wszystkie swoje interfejsy otrzymaną wcześniej wiadomość RREQ, ale ze zmienionym adresem IP na własny. Aktualizowany jest równieŝ numer sekwencyjny celu (ang. destination sequence number) do maksimum, a takŝe numer sekwencyjny grupy w multicastowej tablicy rutingu (jeśli istnieje). [25] Węzły, które otrzymują pakiet RREQ z flagą J sprawdzają w pierwszej kolejności swoją tablicę Ŝądań szukając wpisu dla danej grupy multicastowej. Jeśli Ŝadnego nie znajdzie, umieszcza w tej tablicy adres poszukiwanej grupy wraz z adresem IP węzła, który tej grupy szuka.[25] Węzeł zawsze tworzy lub aktualizuje, jeśli istnieje, ścieŝkę powrotu na wypadek, gdyby dotarła do niego odpowiedź RREP.[26] Rys. 20 Operacje dołączenia w MAODV.[5] Utworzenie ścieŝki powrotu. (ang. Reverse Path Setup) Jak wiadomo, pakiet RREQ jest rozsyłany po sieci, dopóki nie znajdzie celu. Węzły, przez które przechodzi, ustawiają pewne znaczniki, aby ustalić ścieŝki powrotu w swoich tablicach rutingu. Po otrzymaniu pakietu RREQ najpierw aktualizowana jest tablica rutingu, a zapisywane są: numer sekwencyjny i informacje o następnym skoku dla węzła z którego przyszedł pakiet. Tworzona jest w ten sposób ścieŝka powrotu, która moŝe być potrzebna do przekazania odpowiedzi. Dla pakietu RREQ z flagą J dodatkowy wpis umieszczany jest w multicastowej tablicy rutowania. Trasa ta jest nieaktywna, dopóki nie stanie się częścią drzewa multicastowego.[25] 41

42 Jeśli węzeł otrzyma pakiet RREQ z flagą J, i jest on uczestnikiem danego drzewa multicastowego dla tej grupy, aktualizuje on swoją multicastową tablicę rutingu (ang. multicast route table) i generuje odpowiedź w postaci pakietu RREP. Adresy źródłowy i docelowy zawarte w pakiecie RREQ są kopiowane do odpowiadających im pól w pakiecie RREP. W odpowiedzi tej zawierane są między innymi takie informacje jak aktualny numer sekwencyjny grupy multicastowej, adres IP lidera grupy. Co więcej licznik skoków jest zerowany. Odpowiedź wysyłana jest unicastowo na adres źródłowy z pakietu RREQ. [26] Rys. 21 Utworzenie ścieŝki powrotu. [25] Utworzenie ścieŝki przekazywania. (ang. Forward Path Setup) Rys. 22 Utworzenie ścieŝki przekazywania. [25] 42

43 Jeśli węzeł otrzyma pakiet RREQ z ustawioną flagą J, moŝe na niego odpowiedzieć, pod warunkiem, Ŝe jest uczestnikiem poszukiwanej grupy multicastowej i numer sekwencyjny zapisany dla tej grupy jest co najmniej tak duŝy jak ten zawarty w pakiecie RREQ. Węzeł odpowiadający aktualizuje swoją trasę i multicastową tablicę rutingu zapisując w swoich tablicach informacje o następnym skoku (węzeł z którego przyszła odpowiedź) i wysyła unicastowo odpowiedź w postaci pakietu RREP z powrotem do źródła. Tak długo jak węzły wzdłuŝ ścieŝki powrotu do nadawcy pakietu RREQ otrzymują pakiet RREP, aktualizują tablicę rutingu i multicastową tablicę rutingu wpisem z informacją skąd przyszedł ten pakiet, tworząc w ten sposób ścieŝkę przekazywania pakietu.[25] Dzięki temu, przy powtarzaniu procedury wyszukiwania lidera grupy, istnieje duŝa szansa na to, Ŝe procedura będzie znacznie skrócona.[26] Aktywacja trasy multicastowej. (ang. Multicast Route Activation) Rys. 23 Aktywacja trasy multicastowej. [25] Aktywacja multicastowej trasy jest połączona z selekcją i aktywacją linku, który ma zostać dodany do drzewa multicastowego podczas procedury dołączenia nowego węzła do grupy. Kiedy nadawca pakietu wysyła broadcastowo pakiet RREQ bardzo często zdarza się, Ŝe otrzymuje więcej niŝ jedną odpowiedź. Wtedy dokonuje on pewnej selekcji. Zapisuje otrzymaną trasę biorąc za kryterium największy numer sekwencyjny i najkrótszą trasę w liczbie skoków do najbliŝszego członka w drzewie multicastowym. Pozostałe trasy są odrzucane. Informacje te są przetrzymywane przez pewien ustalony okres czasu. Pod koniec tego okresu, włącza wcześniej wybraną trasę w swojej tablicy MRT, i wysyła unicastowo pakiet MACT do węzła na końcu tej trasy. 43

44 Węzeł ten po otrzymaniu pakietu MACT włącza z kolei swój wpis dla nadawcy tego pakietu w swojej MRT. Jeśli jest on w dodatku uczestnikiem drzewa multicastowego, to nie propaguje pakietu MACT(Multicast Activation) dalej. JednakŜe, jeśli jednak węzeł ten nie jest uczestnikiem tego drzewa, otrzyma jedną lub więcej odpowiedzi w postaci pakietu RREP od swoich sąsiadów. Zatrzymuje on najlepszą trasę do grupy multicastowej i unicastowo wysyła pakiet MACT do następnego węzła, wzdłuŝ tej trasy, aktywując ją w tablicy MRT. Proces ten jest kontynuowany, dopóki nie zostanie osiągnięty uczestnik drzewa multicastowego. Dzięki pakietowi MACT w danym drzewie multicastowym nie istnieje wiele ścieŝek do jednego węzła. Dane przekazywane są tylko wzdłuŝ uprzednio aktywowanych tras w tablicach MRT.[25] Rys. 24 Format pakietu MACT. [26] J flaga dołączenia, ustawiana kiedy węzeł chce dołączyć do grupy multicastowej[26] P flaga usunięcia, ustawiana kiedy węzeł chce opuścić drzewo, likwidowana, kiedy węzeł aktywuje link w drzewie[26] G flaga lidera grupy, ustawiana przez uczestnika grupy, któremu nie udało się naprawić zerwanego połączenia z liderem grupy, ogłasza on w ten sposób siebie, jako nowego lidera grupy[26] U flaga aktualizacji, ustawiana, kiedy zerwane połączenie zostało naprawione, i zmienił się dystans do lidera grupy[26] R flaga restartu, ustawiana kiedy węzeł właśnie się restartował[26] Hop Count dystans pomiędzy nadawcą, a liderem grupy multicastowej. Pole uŝywane tylko w przypadku ustawienia flagi U.[26] Multicast Group IP Address adres grupy multicastowej, dla której szukana jest trasa. Source IP Address adres IP nadawcy.[26] Souce Sequence Number aktualny numer sekwencyjny dla informacji o trasie, generowany przez nadawcę pakietu RREQ.[26] 44

45 Grupowe wiadomości HELLO. (ang.group Hello Messages) Rys. 25 Wiadomości hello lidera grupy. [25] Powszechnie wiadomo, Ŝe pierwszy uczestnik grupy multicastowej staje się liderem grupy. Węzeł ten sprawuje tę funkcję, dopóki nie zdecyduje się opuścić danej grupy, lub dopóki dwie partycje drzewa nie połączą się. Odpowiedzialny jest on za zarządzanie numerem sekwencyjnym danej grupy multicastowej i za rozsyłanie tego numeru do całej grupy. MoŜe tego dokonać dzięki grupowej wiadomości HELLO (GRPH). Wiadomość ta zawiera adres IP grupy multicastowej i numer sekwencyjny (zwiększany z kaŝdą GPRH), dla której węzeł ten jest liderem. Pakiet ten jest wykorzystywany do aktualizacji informacji w tablicy Ŝądań.[25] Rys. 26 Format GPRH. [26] U flaga aktualizacji, ustawiana, kiedy nastąpiła zmiana w informacji o liderze grupy.[26] O flaga Off_Mtree, ustawiana przez węzeł, który otrzymuje GPRH, a nie naleŝy do drzewa multicastowego.[26] 45

46 Usunięcie z drzewa. (ang. Prunning) Uczestnik grupy multicastowej moŝe zdecydować się zakończyć swoje uczestnictwo w danej grupie. Ostatni węzeł w drzewie lub węzeł mający tylko jedno połączenie, zwany w terminologii drzew i grafów, liściem, moŝe usunąć samego siebie z danego drzewa ustawiając flagę P w pakiecie MACT do następnego skoku. Jako, Ŝe liść jest ostatni w danej gałęzi drzewa, oznacza to, Ŝe węzeł ma tylko jeden skok do grupy multicastowej, a więc moŝe wysłać pakiet MACT unicastowo do następnego węzła. Po wysłaniu takiej wiadomości, dany węzeł usuwa ze swojej tablicy MRT wszystkie informacje dotyczące danej grupy multicastowej. Węzeł, będący następnym skokiem po otrzymaniu pakietu MACT odczytuje flagę P i usuwa wszystkie informacje o węźle chcącym opuścić drzewo ze swojej tablicy MRT.[25][26] Rys. 27Usuwanie uczestnika grupy.[5] Przywrócenie zerwanych połączeń. (ang. Repair Broken Links) Awaria połączenia pomiędzy węzłami wykrywana jest w momencie braku odbioru pakietów od swojego sąsiada po upłynięciu pewnego, ustalonego okresu czasu. Kiedy wykryte jest zerwane połączenie, najdalszy węzeł względem odległości od lidera grupy (w dół drzewa) odpowiedzialny jest za naprawienie tego połączenia. Naprawa rozpoczyna się wysłaniem broadcastowo pakietu RREQ z ustawioną flagą J. KaŜdy węzeł będący częścią drzewa multicastowego i posiadający dość aktualny numer sekwencyjny moŝe odpowiedzieć unicastowo pakietem RREP. Jeśli po upływie pewnego, ustalonego czasu, węzeł, który zainicjował naprawienie komunikacji nie otrzyma odpowiedzi w postaci pakietu RREP, przyjmuje się, Ŝe naprawa jest niemoŝliwa i komunikacja z drzewem jest zerwana. W tym momencie pojawia się problem lidera grupy, którego w chwili obecnej, w dół drzewa od zerwanego 46

47 połączenia, nie ma. Trzeba go wybrać na nowo. Jeśli węzeł, który zainicjował odbudowę trasy przesyłania pakietów jest uczestnikiem danej grupy multicastowej, automatycznie staje się nowym liderem grupy. Jeśli jednak węzeł ten nie był uczestnikiem grupy, a jedynie przekazywał pakiety, posiada w tym momencie tylko następny skok w drzewie. Samoczynnie usuwa samego siebie z tego drzewa wysyłając do jedynego posiadanego celu, czyli do następnego skoku w drzewie, pakiet MACT z ustawioną flagą P. Proces ten jest kontynuowany, dopóki następnym skokiem nie okaŝe się uczestnik grupy multicastowej. Wtedy on staje się liderem grupy. W ten sposób jedno drzewo multicastowe zostaje podzielone na dwie partycje, a więc de facto na dwa drzewa nie widzące się wzajemnie.[25][26] Rys. 28Operacja naprawiania zerwanego połączenia w dzewie.[5] Ponowne połączenie podzielonego drzewa. (ang. Reconnect Partitioned Tree) W sytuacji, kiedy zerwanego połączenia nie da się naprawić, drzewo multicastowe zostaje podzielone na dwie części, działające całkowicie niezaleŝnie od siebie, dopóki nie zostaną z powrotem połączone. Węzły z jednej partycji sieci wiedzą o istnieniu drugiej, dzięki róŝnicom występującym w pakiecie GRPH, wysyłanym przez róŝnych liderów grupy. Lider grupy z niŝszym adresem IP odpowiedzialny jest za zainicjowanie naprawy awarii. W dalszej części poniŝszej pracy węzeł ten będzie określany jako GL1. GL1 wysyła unicastowo Ŝądanie RREQ z ustawionymi flagami J i R do lidera grupy drugiej partycji sieci (GL2), uŝywając jako następny skok węzła przez który dotarł do niego pakiet GRPH. Pakiet RREQ wysłany do grupy węzła GL2 zawiera aktualny numer sekwencyjny grupy węzła GL1. KaŜdy węzeł z grupy GL2, 47

48 który otrzyma pakiet RREQ ma obowiązek przesłania go wyŝej wzdłuŝ ścieŝki prowadzącej do lidera grupy GL2. Dzięki takiemu mechanizmowi po ponownym przywróceniu normalnego stanu sieci, moŝna uniknąć powstania pętli. Po otrzymaniu pakietu RREQ z węzła GL1, węzeł GL2 wysyła unicastowo odpowiednio zmodyfikowaną odpowiedź RREP z ustawioną flagą R, która oznacza, Ŝe jest to odpowiedź na Ŝądanie naprawienia połączenia. Liderem grupy po naprawieniu awarii zostaje węzeł, który wysyła odpowiedź RREP.[26] Wracająca do węzła GL1 wiadomość RREP powoduje, Ŝe węzły, które uprzednio były uczestnikami grupy GL1 zmieniają lidera grupy na węzeł GL2. GL1 po otrzymaniu pakietu RREP aktualizuje równieŝ swoje informacje. Drzewo moŝna uznać za zrekonstruowane.[26] Rys. 29 Połączenie dwóch drzew.[25] Podstawowe parametry protokołu MAODV. W drafcie protokołu MAODV poniŝsze parametry są rekomendowane takimi wartościami, jak: GROUP_HELLO_INTERVAL = 5000ms [26] RETRANSMIT_TIME = 750ms [26] 48

49 On-Demand Multicast Routing Protocol (ODMRP). ODMRP jest protokołem siatko strukturalnym, stosującym koncepcję grup przekazywania (ang. forwarding group), w której tylko pewne wybrane węzły przekazują pakiety multicastowe. Budowa tras rutowania i zarządzanie uczestnikami grupy odbywa się dynamicznie, na Ŝądanie. Nie wymagane są wiadomości kontrolne, jeśli węzeł chce opuścić grupę.[25] Protokół ten jest doskonale dopasowany do mobilnych bezprzewodowych sieci ad hoc, gdzie przepustowość jest ograniczona, zmiany w topologii sieci następują często i szybko, a energia, z której korzystają urządzenia jest czasowa bateryjna. [27] Trasa multicastowa i tworzenie siatki. (ang. Multicast Route and Mesh Creation) Rys. 30 Tworzenie siatki z uŝyciem broadcastowego Join Query.[25] W protokole ODMRP jak wspomniano wyŝej, uczestnictwo w grupach i zarządzanie trasami odbywa się na Ŝądanie. Podobnie jak w protokołach unicastowych istnieją fazy Ŝądania i odpowiedzi. Kiedy multicastowy nadawca ma pakiety do wysłania, ale nie zna trasy do grupy multicastowej, wysyła broadcastowo pakiet Join Query. Pakiet ten jest równieŝ wysyłany okresowo w celu odświeŝenia informacji o uczestnictwie w grupie multicastowej i w celu aktualizacji tras.[27] 49

50 Kiedy węzeł otrzymuje pakiet Join Query, przechowuje on adres źródłowy i unikalny ID, zawarte w tym pakiecie w swojej pamięci podręcznej wiadomości (ang. Message Cache), aby zapobiec duplikacji. Tablica rutingu jest aktualizowana odpowiednim numerem ID węzła od którego przyszła wiadomość wracająca po ścieŝce powrotu do źródła nadania pakietu Join Query. Jeśli wiadomość nie jest duplikatem i jej TTL jest większy od zera, odpowiednie pola są aktualizowane i pakiet znów zostaje wysłany na adres rozgłoszeniowy sieci. Dzięki przypisaniu TTL dla wiadomości broadcastowych udało się zredukować znaczne przeciąŝenie sieci.[27] Rys. 31 Proces dziłania Join Query.[25] Kiedy pakiet Join Query osiąga multicastowego odbiorcę, ten tworzy i wysyła broadcastowo pakiet Join Reply do swoich sąsiadów. Kiedy węzeł przez, który przebiega transmisja, otrzymuje pakiet Join Reply, sprawdza czy ID następnego węzła pasuje do jego własnego. Jeśli tak, węzeł uświadamia sobie, Ŝe jest na ścieŝce do źródła wysłania pakietu i staje się częścią grupy przekazującej pakiety.(ustawiana jest flaga FG_FLAG). Następnie węzeł ten wysyła broadcastowo swój własny pakiet Join Reply zbudowany na podstawie własnych wartości. Pole ID następnego węzła wypełniane jest wartością z tablicy rutingu. W taki właśnie sposób pakiet Join Reply jest rozsyłany przez kaŝdego członka naleŝącego do grupy przekazywania pakietów, dopóki nie zostanie osiągnięte źródło wysłania pakietu Join Query. Proces ten tworzy lub aktualizuje trasy od źródła do celu i buduje siatkę węzłów, tzw. grupę przekazywania pakietów.[27] 50

51 Rys. 32Proces pakietu Join Reply.[25] Po ustanowieniu grupy i przeprowadzeniu procesu konstruowania tras rutingu, nadawca moŝe wysłać pakiety multicastowe do odbiorcy poprzez wskazane trasy i poprzez grupy przekazywania pakietów. Dopóki istnieją dane do wysłania, nadawca co pewien interwał czasowy (Refresh Interval) wysyła pakiet Join Query i oczekuje na odpowiedź. Ten proces pozwala odświeŝać trasy rutingu i grupy przekazywania. Kiedy węzeł otrzyma pakiet multicastowy, przekazuje go tylko w przypadku, jeśli nie jest to duplikat i jeśli nie wygasła waŝność FG_FLAG dla tej grupy. Procedura ta pozwala zminimalizować zbyt nadmierny ruch w sieci, a takŝe chroni przed wysyłaniem pakietów w nieistniejące trasy.[27] Rys. 33 Nagłówek pakietu Join Query.[27] 51

52 Rys. 34 Nagłówek pakietu Join Reply.[27] Niezawodność. Niezawodna transmisja pakietów Join Reply odgrywa bardzo waŝną rolę przy ustanawianiu i odświeŝaniu tras multicastowych i rozsyłaniu grup. W protokole ODMRP jeśli wyŝej wspomniane pakiety nie zostaną doręczone, rutowanie multicastowe nie będzie odpowiednio efektywne. Protokół MAC (Medium Access Control), będący standardem w sieciach bezprzewodowych, zapewnia niezawodność transmisji poprzez retransmisję zagubionych, nie doręczonych pakietów.[27] W protokole ODMRP transmisja pakietów Join Reply odbywa się często na adres rozgłoszeniowy, nie tylko do najbliŝszych sąsiadów, ale często równieŝ kilka poziomów wyŝej. W takiej sytuacji weryfikacja dostarczenia skok po skoku i retransmisja pakietu Join Reply nie moŝe być dokonywana w warstwie MAC. Powinna zatem mieć miejsce bezpośrednio w protokole.[27] Tablica rutowania. (ang. Routing Table) Tablica rutowania jest tworzona na Ŝądanie i posiada ją kaŝdy węzeł. Wpis w tablicy jest dokonywany lub aktualizowany w przypadku otrzymania nie zduplikowanego pakietu dołączenia Join Query. Węzeł przechowuje ID nadawcy tego pakietu i trasę do następnego skoku (węzła który ostatnio wysłał ten pakiet). Tablica 52

53 rutowania zapewnia informacje o następnych skokach w sieci przesyłania pakietów odpowiedzi na Ŝądania (Join Reply).[27] Rys. 35 Rozsyłanie pakietu Join Query.[6] Rys. 36.Uformowana tablica multicastowa.[6] Tablica grupy przekazującej pakiety. (ang. Forwarding Group Table) Kiedy węzeł naleŝy do grupy węzłów przekazujących w danej grupie multicastowej zarządza on informacjami przechowywanymi w tablicy FGT, czyli ID grupy multicastowej i czas kiedy nastąpiło ostatnie odświeŝenie.[27] 53

54 Pamięć podręczna wiadomości. (ang. Message Cache) Wykorzystywana jest przez kaŝdy z węzłów do wykrywania duplikatów pakietów. W momencie odebrania pakietu Join Query, węzeł przechowuje jego adres źródłowy oraz unikatowe ID pakietu.[27] Przekazywanie danych. (ang. Data Forwarding) Po zakończeniu procesu konstruowania tras rutingu i utworzeniu grupy przekazywania (ang. forwarding group), nadawca moŝe wysłać pakiety multicastowe do odbiorcy korzystając z tych danych. Dopóki są dane do wysłania, nadawca okresowo wysyła pakiet Join Query, aby odświeŝać trasy i grupy przekazywania pakietów. Kiedy węzeł otrzyma pakiet multicastowy z danymi, przesyła go dalej tylko jeśli nie jest on duplikatem pakietu otrzymanego wcześniej. Ustawia równieŝ flagę FG_FLAG dla tej grupy multicastowej. Procedura ta pozwala zredukować nadmierny ruch sieciowy, a takŝe chroni przed wysyłaniem pakietów nieuŝywanymi, nieaktualnymi trasami.[25] Opuszczanie grupy multicastowej. (ang. Soft State) W protokole ODMRP, aby opuścić grupę multicastową niepotrzebne są pakiety kontrolne, jak w na przykład w przypadku protokołu MAODV. Jeśli węzeł wysyłający pakiety chce opuścić daną grupę po prostu zaprzestaje wysyłania pakietów Join Query. To samo dotyczy węzłów odbierających dane, jeśli tylko zdecydują się opuścić grupę, zaprzestają wysyłania pakietów Join Reply. Jeśli węzły naleŝące do grupy przekazującej pakiety nie odświeŝą danych przed upływem pewnego ustalonego czasu są degradowane do zwykłych węzłów.[27] Przewidywalność mobilności. (ang. Mobility Prediction) Protokół ODMRP wymaga okresowego przesyłania pakietów Join Query, w celu znalezienia i odświeŝenia tras. JednakŜe naleŝy pamiętać o tym, Ŝe nadmierne przesyłanie tych pakietów, moŝe powodować problemy z przepustowością, zatorami i kolizjami w sieci. Ze strony wydajnościowej protokołu ODMRP, znalezienie odpowiedniego interwału czasu (ang. Refresh Interval), co jaki te pakiety miałyby być wysyłane, okazuje się więc krytyczne. W węzłach niezwykle dynamicznie zmieniających swe połoŝenie, wyposaŝonych w system GPS (ang. Global Positioning System) moŝna skorzystać z interwału odświeŝania dla rozsyłanych pakietów, typu Join Query, aby ograniczyć wady wspomniane wcześniej. Dzięki wykorzystaniu informacji o lokalizacji i przemieszczaniu, a takŝe dzięki modelowi, schematowi, pozwalającemu przewidzieć mobilność danego węzła, moŝna znaleźć okres czasu, po jakim trasy okaŝą 54

55 się bezuŝyteczne. A więc pakiety, mogą być przesyłane znanymi trasami, tylko w okresie pewnego, określonego, przewidzianego czasu. Później trasy stają się bezuŝyteczne.[27] W protokole ODMRP istnieje jeszcze inna metoda redukująca liczbę bezuŝytecznych tras, polegająca na róŝnej ich selekcji. (ang. different route selection). Polega to na wykorzystaniu najbardziej stabilnych tras (które posiadają najdłuŝszy status połączenia) zamiast, jak dotychczas, najkrótszych i najszybszych. Odbiorca multicastowy, po otrzymaniu pakietu Join Query, musi często poczekać przez pewien okres czasu, zanim otrzyma pełną informację na temat tras, którymi moŝe wysłać odpowiedź. Po uzupełnieniu tych informacji wybiera trasę najbardziej stabilną i wysyła broadcastowo pakiet Join Reply.[27] 55

56 5.2. Protokoły proaktywne Ad hoc Multicast Routing Protocol (AMRoute). Protokół AMRoute tworzy osobno dla kaŝdej grupy multicastowe drzewa dystrybucyjne przy uŝyciu unicastowych tuneli łączących pojedynczych członków grupy. Protokół ten posiada dwie kluczowe części: tworzenie siatki i tworzenie drzewa. AMRoute tworzy siatkę dwukierunkowych tuneli pomiędzy parą, połoŝonych blisko siebie, uczestników grupy. Tylko logiczny rdzeń moŝe zainicjować utworzenie siatki i drzewa połączeń. NaleŜy przy tym zaznaczyć, Ŝe rdzeń moŝe dynamicznie zmieniać swoją przynaleŝność do grup. Przy uŝyciu dostępnych połączeń w siatce (tuneli), protokół ten, okresowo, tworzy drzewo multicastowe. [29] Multicastowe drzewa dystrybucyjne (ang. User-multicast distribution trees) Rys. 37.Wirtualne drzewo multicastowe [28] Rysunek 37 przedstawia drzewo multicastowe łączące sześciu uczestników danej grupy. Uczestnicy grupy przekazują ruch multicastowy wzdłuŝ gałęzi virtualnego drzewa. Pakiet, który od strony logicznej jest przesłany pomiędzy dwoma sąsiadami, fizycznie moŝe wędrować przez wiele węzłów pośredniczących stanowiących tunel unicastowy pomiędzy tymi sąsiadami. ŚcieŜka utworzona przez tunel moŝe się zmieniać bez Ŝadnego wpływu na drzewo multicastowe. Innymi słowy, tunel będzie jeden i ten sam, natomiast mogą się zmieniać węzły, które go tworzą.[29] Istnieją dwie kluczowe zalety, które przemawiają za implementacją tego protokołu przy uŝyciu tylko uczestników grupy:[29] 56

57 Dzięki zapewnieniu niezmienności ścieŝki pomiędzy wszystkimi węzłami połączonymi za pomocą siatki gałęzi, nie trzeba dokonywać zmian w drzewie multicastowym w przypadku zmian w sieci (np w przypadku poruszania się routerów). Taka niezaleŝność zwiększa niezawodność działania protokołu, a takŝe zmniejsza ilość pakietów sygnalizacyjnych, powodujących często przeciąŝenia na łączach.[29] Nie potrzebne są węzły nie będące uczestnikami grupy, aby moŝliwa była replikacja danych, lub jakiekolwiek wsparcie dla jakiegokolwiek protokołu multicastowego. [29] Ceną, jaką płacimy korzystając z drzewa multicastowego, wspomnianego wcześniej, jest zmniejszona wydajność. Wydajność przepustowości jest ograniczona, odkąd węzły pośredniczące w transmisji nie mogą brać udziału w replikacji pakietów. Opóźnienie bardzo często moŝe się ulegać zmianie. JednakŜe, róŝnica w optymalizacji pomiędzy drzewem, korzystającym z wszystkich moŝliwych węzłów w sieci lub z węzłów będących tylko uczestnikami grupy, jest teoretycznie bardzo ograniczona.[29] W stabilnej sieci, korzystającej z drzewa multicastowego, w najgorszym przypadku, przeciąŝenia na łączu są i tak co najmniej dwukrotnie mniejsze niŝ w drzewie korzystającym z wszystkich dostępnych węzłów w sieci. [28] Rdzenie logiczne i węzły nie będące uczestnikami grupy multicastowej. (ang. Logical core and non-core members ) W protokole AMRoute kaŝda grupa posiada przynajmniej jeden logiczny rdzeń, który odpowiedzialny jest za wykonanie pewnych akcji, w szczególności za dołączanie do siatki (ang. mesh join) (wyszukiwanie nowych członków grupy, odłączanie pewnych segmentów siatki), jak równieŝ za tworzenie drzewa multicastowego (ang. multicast tree creation). Węzeł nie będący rdzeniem nie moŝe zainicjować tych dwóch operacji. Ograniczając liczbę węzłów mogących realizować te funkcje uzyskujemy pewność, Ŝe protokół AMRoute jest skalowalny, nie powodujący nadmiernej sygnalizacji i przeciąŝeń na łączach. Dzięki takiej budowie, węzły nie będące rdzeniem mogą odpowiadać na wiadomości sygnalizacyjne, zainicjowane przez logiczny rdzeń, lecz same nie powodują nadmiernego ruchu w sieci, poprzez wysyłanie takich wiadomości.[29] W protokole AMRoute rdzeń, o którym mowa jest wcześniej, nie jest punktem centralnym dla wszystkich danych przepływających przez sieć. Przekazywanie 57

58 pakietów moŝe odbywać się na działających gałęziach drzewa, niezaleŝnie od statusu dostępności rdzenia i połączeń do niego. WaŜną jego cechą jest równieŝ to, Ŝe rdzeń jest wybierany z pośród węzłów naleŝących do danego segmentu drzewa multicastowego przy uŝyciu algorytmu CRA, którego głównym zadaniem jest zapewnienie tylko jednego węzła w kaŝdym segmencie drzewa, który będzie rdzeniem.[29] Dany segment w protokole AMRoute, moŝe tymczasowo posiadać więcej niŝ jeden rdzeń na grupę, w przypadku połączenia nowo dołączonych węzłów. W przypadku, kiedy dany węzeł jako pierwszy dołącza do grupy, automatycznie desygnuje on samego siebie na rdzeń. Jako logiczny rdzeń, węzeł ten moŝe szybko wyszukać nowych członków grupy, a takŝe przeprowadzić procedurę tworzenia siatki i drzewa ze swoimi najbliŝszymi sąsiadami. [29] MoŜe równieŝ zaistnieć sytuacja, w której okaŝe się, Ŝe rdzeń nagle znikł (np. opuścił grupę) lub jeden segment został podzielony na kilka (np. w skutek awarii połączeń). W takim przypadku, jeden z węzłów, po upływie pewnego losowego czasu od otrzymania ostatniego pakietu Tree Create, desygnuje samego siebie jako rdzeń.[29] Tworzenie siatki. (ang. Mesh Creation) Siatka w protokole AMRoute to graf, w którym kaŝdy węzeł jest członkiem (nadawcą lub odbiorcą) grupy, a kaŝde połączenie jest dwukierunkowym unicastowym tunelem (Rysunek 38). Podczas, gdy siatka odpowiedzialna jest za wszystkie połączenia pomiędzy członkami grupy, drzewo potrzebne jest do przesyłania danych. Proces tworzenia siatki posiada dwa kroki, które naleŝy wykonać, zanim moŝliwe będzie stworzenie drzewa.[28] Aby utworzyć siatkę obejmującą wszystkich członków grupy potrzebny jest mechanizm, który pozwoli uczestnikom grupy odkrywać samych siebie. [29] KaŜdy uczestnik grupy rozpoczyna poprzez zidentyfikowanie samego siebie jako rdzenia, który tworzy, jak na razie, siatkę składającą się tylko z niego samego. Rdzeń wysyła pakiet Join Request ze zwiększonym czasem TTL w celu wykrycia innych członków danej grupy. Kiedy członek danej grupy (rdzeń lub nie) otrzyma taki pakiet, pochodzący z innej siatki, ale z tej samej grupy, odpowie pakietem Join Ack. W tym momencie nawiązany zostanie dwukierunkowy tunel pomiędzy rdzeniem i węzłem odpowiadającym z innej siatki. Podczas łączenia się dwóch siatek, powstanie sytuacja, gdzie będzie istniało kilka węzłów będących rdzeniami. W takiej sytuacji zadziała 58

59 algorytm CRA, i wybrany zostanie, który stanie się rdzeniem dla nowo powstałej siatki.[29] Jeśli dany węzeł opuszcza grupę, wysyła pojedynczy pakiet Join Nak do swoich sąsiadów. Jeśli otrzymuje on nadal dane z tej grupy wysłanie pakietu Join Nak moŝe zostać ponowione.[29] Rys. 38.Tworzenie siatki [30] Tworzenie drzewa. (ang. tree creation) Za tworzenie drzewa odpowiedzialny jest rdzeń. Funkcją drzewa jest przekazywanie danych. [29] Rdzeń okresowo, co jakiś czas, wysyła pakiet Tree Create na wszystkie połączenia w siatce, którą zarządza (naleŝy zwrócić tutaj uwagę na to, Ŝe pakiet Tree Create jest wysyłany poprzez konkretne tunele unicastowe w siatce i są przetwarzane tylko przez uczestników grupy podczas, gdy pakiety Join Request są wysyłane broadcastowo do wszystkich węzłów w sieci). Okresowość wysyłania tego pakietu zaleŝy tutaj od rozmiarów siatki, a takŝe od mobilności jaką te węzły wykazują. Odkąd węzły w sieci są mobilne, liczba skoków pomiędzy sąsiadami równieŝ wykazuje zmienne tendencje. Członkowie grupy multicastowej, którzy otrzymują nie zduplikowane pakiety Tree Create, przesyłają je na wszystkie swoje połączenia w siatce, oprócz tego, z którego przyszedł pakiet. Wszystkie te linki oznaczają jako połączenia w drzewie. Jeśli węzeł posiada pewną kolekcję sąsiadów, oddalonych nie dalej niŝ jeden skok od siebie, to w ramach optymalizacji protokołu moŝe wysłać jeden broadcast do wszystkich.[29] W przypadku, gdyby się okazało, Ŝe dany link nie będzie stanowił części drzewa, pakiet Tree Create jest odrzucany i wysyłana jest odpowiedź w postaci pakietu Tree Create NAK. Po otrzymaniu tego pakietu, uczestnik grupy, oznacza takie 59

60 połączenie w taki sposób, Ŝe zostanie ono dodane do struktury tworzącej siatkę, natomiast nie będzie stanowiło jednej z gałęzi w drzewie.[29] Rys. 39.Tworzenie drzewa[30] Tymczasowe pętle.(ang. transient loops) Drzewo utworzone przez n-ty pakiet Tree Create moŝe nie być takie samo jak utworzone przez (n-1) pakiet. Sytuacja moŝe się pojawić, gdy jakieś węzły będą wysyłać dane, odnosząc się do informacji o starym drzewie, a inne będą wysyłać dane, odnosząc się do nowego. MoŜe to doprowadzić do powstania pętli lub do niekontrolowanej straty danych. W związku z dość dynamiczną naturą sieci ad hoc, takiej sytuacji moŝna spodziewać się dość często. [28] Aby zredukować liczbę pętli korzystamy z numerów sekwencyjnych pakietów danych. Numery te są na grupę multicastową i na wysyłającego, dzięki czemu uczestnik grupy moŝe rozpoznać, czy nie jest do duplikat, i ewentualnie pakiet odrzucić. [28] Awarie węzłów i opuszczanie grupy. (ang. node failures and group leaves) Zdarzają się sytuacje, gdzie pomimo redundantnych połączeń w siatce pomiędzy węzłami, następują ich zerwania, a efektem tego jest uniemoŝliwienie dalszej transmisji. Niektóre awarie powodują podzielenie siatki na kilka bezładnych, mniejszych siatek, z pośród których, tylko jedna moŝe mieć rdzeń.[29] KaŜdy węzeł w siatce oczekuje okresowego otrzymywania pakietu Tree Create. Jeśli wiadomości tej nie ma przez pewien określony czas dany węzeł desygnuje siebie na rdzeń siatki. Węzeł, którego licznik czasu wygaśnie najszybciej, zostaje nowym rdzeniem danej grupy i rozpoczyna on proces wyszukiwania innych siatek, jak równieŝ rozpoczyna tworzenie nowego drzewa. W takiej sytuacji moŝe się zdarzyć, Ŝe powstanie siatka z kilkoma rdzeniami. Zadziała wtedy procedura core resolution.[29] 60

61 Rys. 40.Podział jednej siatki na kilka [30] Core resolution. W przypadku połączenia kilku siatek w jedną, moŝe zaistnieć sytuacja, w której jednocześnie działać będzie kilka rdzeni. Węzły w siatce w momencie otrzymania pakietu Tree Create z kilku źródeł uświadamiają sobie istnienie kilku rdzeni. Uruchamiają one algorytm core resolution, który pozwala im zdecydować o unikalności jednego z węzłów będących rdzeniami. Przekazują one pakiet Tree Create tylko pochodzący od unikatowego rdzenia, a odrzucają pakiety przychodzące od innych rdzeni. Jak tylko rdzenie uświadomią sobie istnienie innych rdzeni w siatce uruchamiają równieŝ ten sam algorytm. Wszystkie rdzenie, oprócz tego, który pozostał jako jedyny, degraduja się do stanu zwykłych węzłów, nie będących rdzeniami. Algorytm core resolution, który tutaj stosujemy, wybiera rdzeń z największym adresem IP.[28] Wybieranie gałęzi siatki do drzewa. (ang. Picking which branch to use for the Tree) Istnieje co najmniej kilka algorytmów, pozwalających na decyzję, które gałęzie w siatce mogą zostać wykorzystane w drzewie. Najprostszy mówi, Ŝeby węzeł zaakceptował pierwszy pakiet Tree Create jaki otrzyma, a wszystkie inne duplikaty odrzucił korzystając z numeru sekwencyjnego zawartego w kaŝdym pakiecie Tree Create. Taki mechanizm pozwala na stworzenie dość umiarkowanego drzewa, ale nie zapewniającego zbyt duŝej wydajności (np. nie będzie korzystał z najkrótszej liczby skoków do celu).[29] Graficzny przykład działania protokołu AMRoute. Rysunki 41 i 42 demonstrują formowanie się drzewa w protokole AMRoute. Węzły A i B równocześnie dołączają do grupy multicastowej, i wybierają samych siebie jako logiczne rdzenie. Rozpoczynają transmisję pakietów Join Request z zwiększającym się TTL. Jeśli oba z nich otrzymają pakiet pochodzący od tego drugiego, węzeł B przy pomocy algorytmu core resolution jest relegowany do zwykłego 61

62 uczestnika grupy. W tym momencie zawiązuje się tunel łączący węzeł A z B. Teraz do grupy dołącza węzeł C, który wybiera siebie jako logiczny rdzeń i rozpoczyna transmisję pakietu Join Request ze zwiększonym TTL. Odległość miedzy węzłami B i C jest mniejsza niŝ pomiędzy A i B, a więc węzeł B otrzyma pakiet Join Request od węzła C, zanim pakiet ten osiągnie węzeł A. Powstanie połączenie w siatce pomiędzy węzłami B i C. Algorytm core resolution na węźle B zdecyduje, Ŝe zwycięzcą jest węzeł C, a więc węzeł B przekaŝe pakiet Tree Create z C do A. Węzeł A równieŝ zdecyduje o zwycięstwie węzła C i releguje sam siebie do postaci uczestnika grupy. W tym momencie istnieją połączenia w drzewie pomiędzy węzłami C i B, a takŝe A i B. Jakikolwiek pakiet Join Request z węzła C osiągnie węzeł A, jednakŝe od momentu, gdy węzły A i B są w tej samej siatce, zostanie on zignorowany. Nowy uczestnik grupy w postaci węzła D próbuje teraz dołączyć do istniejącej siatki poprzez wysłanie pakietu Join Request. Pakiet ten w pierwszej kolejności dociera do węzła B.Algorytm core resolution na węźle B decyduje, Ŝe C pozostanie nadal rdzeniem, a węzeł D staje się częścią drzewa. Pakiet Join Request z węzła D moŝe równieŝ zostać odebrany przez węzeł A, jednakŝe węzeł D powinien otrzymać pakiet Tree Create z węzła B zanim otrzyma go od węzła A. Tak więc połączenie w siatce pomiędzy węzłami A i D nie znajduje pokrycia w drzewie.[29] Rys. 41.Formowanie siatki i drzewa [28] Rys. 42.Formowanie siatki i drzewa cd. [28] 62

63 Diagram stanów. Rys. 43.Diagram stanów [28] PowyŜej pokazany jest diagram trzech stanów i przejść, protokołu AMRoute. Stany te mogą zostać zinterpretowane jak następuje:[28] NON_MEMBER uczestnika, który nie naleŝy do grupy multicastowej [28] CORE węzeł, który aktualnie rozpoznaje samego siebie jako logiczny rdzeń [28] NON_CORE węzły, które aktualnie są uczestnikami grupy, ale nie rdzeniami [28] Podstawowe parametry protokołu AMRoute. Join Request Send po upłynięciu tego czasu generowany jest nowy TTL dla pakietu Join Request Tree Create Send timeout po którym przesyłany jest pakiet Tree Create Tree Create Recv uŝywany przez węzły nie będące rdzeniami. Po jego upłynięciu węzeł czeka przez losowo wygenerowany licznik czasu, a następnie desygnuje samego siebie jako logiczny rdzeń [28] 63

64 Core-Assisted Mesh Protocol (Camp). Protokół CAMP został zaprojektowany, aby wspierać multicastowy ruting w bardzo dynamicznych sieciach ad hoc z broadcastowymi połączeniami. NaleŜy on do grupy proaktywnych, a więc okresowo odświeŝających trasy, po których przesyłane są pakiety.[21] Protokół CAMP róŝni się od większości protokołów multicastowych tym, Ŝe multicastowa siatka jest budowana i utrzymywana dla rozprowadzania informacji w kaŝdej grupie multicastowej. Siatka multicastowa jest pewną częścią topologii sieci, w której dla danego nadawcy istnieje przynajmniej jedna ścieŝka do kaŝdego odbiorcy w grupie multicastowej. Protokół CAMP zapewnia najkrótsze ścieŝki od odbiorcy do nadawcy, nazywane odwrotnymi ścieŝkami, są częścią siatki danej grupy. Pakiety są przekazywane wzdłuŝ wcześniej znalezionych ścieŝek przez siatkę. Węzeł utrzymuje informacje o identyfikatorach pakietów, które uprzednio przekazał w swojej pamięci podręcznej, a takŝe przekazuje pakiety multicastowe otrzymane od sąsiadów, jeśli nie posiada o nich informacji w swojej pamięci podręcznej. Podstawową róŝnicą pomiędzy strukturą siatki i drzewa, jak wiadomo, jest podejście do akceptowania pakietów, które mają zostać przetworzone. Węzły zobligowane są do przyjmowania pakietów pochodzących od jakiegokolwiek sąsiada w siatce, przeciwnie jak to miało miejsce w drzewach.[21] PoniewaŜ węzeł będący uczestnikiem grupy multicastowej posiada redundantne ścieŝki do wszystkich innych węzłów w tej samej siatce, jest mniej prawdopodobne, Ŝe zmiany w topologii zakłócą przepływ multicastowych danych i Ŝe wymagana będzie rekonstrukcja struktury rutingu, która wspiera przekazywanie pakietów. Rysunek 44 ilustruje róŝnice pomiędzy multicastową siatką, a multikastowym drzewem współdzielonym. Węzły, które są uczestnikami grupy multicastowej zaznaczone są na kolor czarny. Multicastowe siatka i drzewo pokazane poniŝej zawierają węzły, które mają odbiorców, hosty, które są nadawcami i odbiorcami, oraz węzły będące tylko przekaźnikami (ang. relay).[21] 64

65 Rys. 44.Przepływ pakietów z rutera h w siatce multicastowej (z lewej) i w drzewie współdzielonym (z prawej) [21] PowyŜszy rysunek ilustruje przekazywanie pakietów z węzła h do pozostałej części siatki w protokole CAMP i w drzewie współdzielonym. Na rysunku tym, całe strzałki charakteryzują przepływ ruchu wzdłuŝ odwrotnej najkrótszej ścieŝki w protokole CAMP i wzdłuŝ drzewa współdzielonego. Strzałki przerywane charakteryzują niepotrzebnie generowany ruch, w skutek rozsyłania pakietów broadcastowych. Jak moŝna zauwaŝyć, protokół CAMP korzysta z duŝo krótszych ścieŝek niŝ drzewo współdzielone, a ma to ogromne znaczenie w sieciach ad hoc, gdyŝ węzły korzystają z mniejszej ilości stacji do przekazania pakietów. Co więcej, moŝna zauwaŝyć, Ŝe liczba stacji, które otrzymają pakiety wysłane przez węzeł h, jest taka sama bez względu czy skorzystamy z multicastowej siatki, czy z drzewa współdzielonego, to pozwala stwierdzić fakt, Ŝe uŝycie multicastowych drzew zamiast multicastowej siatki nie koniecznie zmniejszy ilość wysyłanych pakietów kontrolnych związanych z połączeniami broadcastowymi.[21] Protokół CAMP dziedziczy metodę inicjowania odbiorcy (ang. receiverinitiated) przedstawioną w protokole CBT, która odpowiedzialna jest za tworzenie drzew multicastowych umoŝliwiających utworzenie multicastowych siatek. Rdzenie są uŝywane do ograniczenia ruchu kontrolnego, potrzebnego odbiorcom do dołączenia do grupy multicastowej. W porównaniu do CBT, dla kaŝdej siatki moŝe być zdefiniowanych jeden lub wiele rdzeni. Rdzenie muszą być częścią siatki swoich grup, natomiast węzły mogą dołączać do grupy nawet, jeśli wszystkie powiązane z daną 65

66 grupą rdzenie są nieosiągalne. Jeśli Ŝaden z sąsiadów węzła nie jest uczestnikiem danej grupy multicastowej wysyła on Ŝądanie dołączenia do rdzenia, w przeciwnym przypadku, po prostu ogłasza swoje członkostwo korzystając z mechanizmu aktualizacji. Jeśli rdzeń jest nieosiągalny dla węzła, który potrzebuje dołączyć do grupy, wysyła on broadcastowo swoje Ŝądanie dołączenia uŝywając do tego mechanizmu ERS, który pozwola osiągnąć ewentualnych uczestników poszukiwanej grupy. Przy otrzymaniu jednej, bądź większej ilości, odpowiedzi, węzeł chcący dołączyć do grupy multicastowej wybiera jedną z nich w celu utworzenia ścieŝki do siatki.[21] Protokół CAMP zapewnia równieŝ odmienną metodę dołączenia do siatki, dla węzłów połączonych tylko z nadawcami. Jest to tak zwane Ŝądanie dołączenia w trybie simplex. Tego typu pakiet, podobnie jak normalne Ŝądanie dołączenia, podróŝuje do jednego z dostępnych rdzeni w siatce, jak równieŝ dostaje odpowiedź. RóŜnica polega na tym, Ŝe pakiety powinny podróŝować tylko w jednym kierunku, to znaczy od hosta będącego tylko nadawcą pakietów do siatki. Jest to próba zawarcia pakietów danych w okolicach występowania odbiorców w siatce. Węzeł moŝe opuścić grupę multicastową, kiedy nie ma Ŝadnych połączeń z innymi węzłami, zaleŝnymi od niego. Czyni to poprzez prostą zmianę statusu członkostwa w grupie i rozsyłanie tej informacji do swoich sąsiadów.[21] Rys. 45. Przepływ pakietów z węzła nie będącego uczestnikiem grupy w CAMP.[21] 66

67 CAMP uŝywa schematu bazującego na transmisji pakietów typu heartbeat w celu zapewnienia w siatce wszystkich najkrótszych odwrotnych ścieŝek. KaŜdy uczestnik siatki, tymczasowo przechowuje informacje o źródłach ruchu sieciowego, których pakiety przechodziły przez uczestników grupy innych niŝ poprzez wyznaczoną najkrótszą odwrotną ścieŝkę do źródła. Jeśli powstaje taka sytuacja, pakiet heartbeat jest wysyłany do sukcesora w najkrótszej odwrotnej ścieŝce do źródła, znalezionej w unicastowej tablicy rutowania. Pakiet heartbeat powoduje wysłanie wiadomości push join, jeśli sukcesor ten nie jest uczestnikiem danej siatki. Wiadomość ta powoduje dołączenie do siatki wspomnianego wcześniej sukcesora, a takŝe wszystkich ścieŝek do źródła wysłania pakietu.[21] Mapowanie multicastowych adresów do (jednego lub więcej) adresów rdzeni jest rozpowszechniane od kaŝdego rdzenia do sieci jako część rozsyłanych raportów członkostwa grupy.[21] 67

68 5.3. Protokoły inteligentne Multicast for Ad hoc Network with Swarm Intelligence(MANSI) Ant-based. Protokół multicastowy przedstawiony w tym podrozdziale oparty jest o tzw. zbiór inteligencji (ang. swarm intelligence). Technika ta polega na odniesieniu się do pewnych kompleksowych zachowań, które pochodzą z bardzo prostych, indywidualnych zachowań i reakcji, bardzo często obserwowanych w naturze, w szczególności wśród insektów, takich jak mrówki czy pszczoły. ChociaŜ kaŝdy indywidualny obiekt (w tym wypadku, dla odniesienia niech będzie to jedna pojedyncza mrówka) posiada jakąś małą inteligencję i umie postępować zgodnie z pewnym podstawowymi regułami, korzystając z informacji uzyskanych z otoczenia, to pewne globalne osiągnięcia moŝna zauwaŝyć dopiero wtedy, kiedy pracują w grupie. Podobnie w tym protokole, małe pakiety kontrolne moŝna odnieść do mrówek w prawdziwym świecie. Te pakiety, podróŝując po sieci jak mrówki, pozostawiają pewne informacje w węzłach, które odwiedzają, podobnie jak mrówki wyznaczają ścieŝki, którymi się przemieszczają. Te pozostawione informacje, wywierają wpływ na inne pakiet (mrówki). Z taką formą pośredniej komunikacji (znanej jako ang. stigmergy), rozmieszczenie pakietów (mrówek) przypomina system, który jest w stanie sam ewoluować w celu uzyskania bardziej optymalnego stanu, zaleŝnego od środowiska, które go otacza. [23] Dla kaŝdej grupy multicastowej, protokół MANSI określa grupę węzłów pośrednich, nazywanych grupą pośredniczącą (ang. forwarding set), łączących wszystkich członków grupy razem i udostępnianych nadawcom. Grupa pośrednicząca jest inicjowana przez węzły leŝące na najkrótszej ścieŝce pomiędzy rdzeniem i innymi członkami grupy, gdzie rdzeń moŝe być zarówno uczestnikiem grupy, jak i nadawcą danych. Co więcej, podczas okresu Ŝycia sesji multicastowej (dopóki istnieje choćby jeden aktywny nadawca), grupa pośrednicząca cały czas będzie ewoluować. [23] MANSI jest multicastowym reaktywnym protokołem, tworzącym połączenia pomiędzy członkami grupy multicastowej poprzez ustalenie węzłów pośredniczących, które będą przekazywać dane. Takie przekazywanie nazywa się grupą pośredniczącą (ang. forwarding set) i jest współdzielone przez wszystkich nadawców w grupie. Protokół ten wykorzystuje technikę opartą na rdzeniu, gdzie kaŝdy uczestnik dołączając do grupy poprzez rdzeń w celu nawiązania połączenia z innymi uczestnikami grupy. MANSI w ogóle nie korzysta z komunikacji unicastowej. [23] Co więcej, rdzeń kaŝdej 68

69 grupy nie jest przypisany statycznie do jakiegoś szczególnego węzła w sieci i nie jest on znany z wyprzedzeniem przez uczestników danej grupy. W protokole tym, pierwszy uczestnik grupy, który staje się aktywnym źródłem pakietów (wysyła dane do grupy) obejmuje rolę rdzenia i rozgłasza swoją egzystencję wysyłając komunikat do innych w postaci pakietu Core Announce. KaŜdy członek grupy polegając na tym komunikacie stara się zainicjować komunikację wysyłając pakiet Join Request z powrotem do rdzenia wykorzystując do tego odwrotną ścieŝkę (ang. reverse path). Węzły, które otrzymają pakiet Join Request zaadresowany do nich samych stają się węzłami pośredniczącymi grupy multicastowej i odpowiedzialne są za akceptowanie i rebroadcasting nie zduplikowanych pakietów z danymi, bez względu na to skąd te pakiety pochodzą. Rdzeń rozsyła pakiet Core Announce okresowo tak długo, jak długo posiada dane do wysłania. Pozwala to na utrzymywanie istniejących połączeń, a takŝe na dołączanie nowych członków do grupy. W rezultacie, węzły pośredniczące w transmisji formują siatkę, która łączy wszystkich uczestników grupy multicastowej razem, podczas, gdy rdzeń słuŝy jako punkt centralny dla tworzenia i utrzymania grup pośredniczących. Odkąd proces ten jest wywoływany tylko, gdy istnieje aktywne źródło generujące dane do grupy, nie jest marnowana bardzo cenna przepustowość sieci na niepotrzebne utrzymanie stałych połączeń.[23] Podobnie jak w innych protokołach opartych o rdzeń, proces ten tworzy grupę przekazującą pakiety, składającą się z wszystkich węzłów pośredniczących, będących na ścieŝce, na której pakiety Core Announce są akceptowane i rozsyłane od rdzenia do innych członków grupy. ŚcieŜki te najczęściej są najkrótsze, jak pokazano na rysunku 46 (a). JednakŜe, łączność w grupie moŝe być jeszcze bardziej wydajna, jeśli węzeł A wybierze inną ścieŝkę, z której częściowo korzysta węzeł B, w celu zredukowania rozmiaru grupy przekazywania (rysunek 46 (b)), a co za tym idzie do zmniejszenia kosztu przesyłania danych. [23] 69

70 Rys. 46. Multicastowe połączenie pomiędzy trzema uczestnikami grupy, a) grupa przekazywania składająca się najkrótszych ścieŝek utworzonych przez 6 węzłów, b) grupa przekazująca, w której węzeł A korzysta częściowo ze ścieŝki węzła B [23] Swarm intelligence pozwala węzłom na uczenie się lepszych połączeń multicastowych, które pozwalają uzyskać mniejsze koszty przekazywania pakietów. KaŜdy uczestnik grupy, który nie jest rdzeniem okresowo rozsyła mały pakiet, zwany Forward Ant, który przy nadarzających się okazjach, odkrywa róŝne, jak równieŝ lepsze ścieŝki prowadzące w kierunku rdzenia. Proces ten pokazany jest na rysunku 47.[23] Rys. 47. Przykład działania Forward i Backward Ant (1) Forward Ant wybiera węzeł C jako skok do węzła D (2) Forward Ant przekształca się w Backward Ant i powraca odwrotną ścieŝką do węzła A [23] Jeśli pakiet Forward Ant przybędzie do węzła, który aktualnie jest węzłem przekazującym pakiety do grupy multicastowej (węzeł D), włącza siebie jako Backward Ant i wysyła pakiet z powrotem do twórcy poprzez odwrotną ścieŝkę (ang. reverse path). Kiedy Backward Ant przybywa do kaŝdego węzła pośredniczącego, szacuje koszt węzła, który aktualnie jest dołączany do grupy poprzez węzły pośredniczące, które wcześniej znalazł. Obliczony koszt, jak równieŝ ilość feromonów które są 70

71 proporcjonalne do kosztu, są aktualizowane w lokalnej strukturze danych danego węzła. Feromony te są później uŝywane przez późniejsze pakiety Forward Ants w celu podjęcia decyzji o dalszej ich podróŝy, podobnie jak to ma miejsce w naturze. RozwaŜmy przykład z Rysunku 47, kiedy pakiet Backward Ant opuszcza węzeł D i dociera do węzła C. Koszt dołączenia węzła C przez węzeł D wynosi zero odkąd węzeł D jest węzłem pośredniczącym i jest bezpośrednio połączony z węzłem C. Kiedy ant wraca do węzła A, koszt dołączenia węzła A do grupy przez węzeł D jest taki sam jak w przypadku węzła C, poniewaŝ wymagane jest, aby węzeł C stał się pośredniczącym, aby węzeł A mógł dołączyć do grupy poprzez węzeł D. Jeśli węzeł A zauwaŝy, Ŝe ilość feromonów na połączeniu z węzłem C staje się największa w porównaniu do linków z sąsiednimi węzłami, przejdzie na połączenie z grupą poprzez węzeł C wysyłając pakiet Join Request do niego. Konsekwencją tego, Ŝe C stanie się węzłem pośredniczącym, będzie usunięcie węzłów E,F i G z grupy pośredniczącej, i połączenie będzie podobne jak na rysunku 46(b).[23] Aby zapobiec sytuacji, w której dwóch członków grupy będzie próbować ustanowić połączenie w grupie poprzez swoje własne ścieŝki pośredniczące, kaŝdy węzeł pośredniczący jest powiązany z pewną wysokością, która jest adekwatna do największego ID węzła, który uŝywa go do połączenia z rdzeniem. Rdzeń posiada swoją wysokość ustawioną na wartość nieskończoną. Rysunek 48 ilustruje przykład jak wysokości są przypisane do węzłów pośredniczących. Forward Ant musi się zatrzymać i przekształcić w Backward Ant tylko w przypadku, kiedy napotka węzeł pośredniczący, którego wysokość jest większa od ID członka grupy, który jest źródłem pochodzenia anta. Oznacza to, Ŝe uczestnik grupy posiada uprawnienia do połączenia z rdzeniem poprzez istniejące ścieŝki naleŝące do innego uczestnika z większym ID, ale nie na odwrót.[23] Rys. 48. Przykład przypisania wysokości do węzłów pośredniczących, uŝywanych przez węzły z ID 3,6 i 8.[23] 71

72 Podsumowując, stosując kilka prostych reguł, większość Forward Ant pochodzących od uczestników grupy wybierze ścieŝkę, łączącą istniejący węzeł pośredniczący z małym kosztem tej ścieŝki. Węzły na tej ścieŝce są później uŝywane do przekazywania pakietów multicastowych mniejszym kosztem. Ten mechanizm odkrywania i uczenia się pozwala protokołowi MANSI na odkrywanie lepszych grup pośredniczących w kaŝdej grupie multicastowej, zaleŝnych od wyliczenia kosztów węzła, jak równieŝ odróŝnia ten protokół od innych istniejących protokołów rutowania multicastowego w sieciach ad hoc.[23] Lokalne struktury danych. (ang. Local data structures) KaŜdy węzeł w sieci z unikatowym ID - i utrzymuje listę swoich sąsiadów, ntab(i), uzyskanych poprzez protokół odkrywania sąsiadów (ang. neighbor discovery protocol) np. poprzez okresowe wysyłanie pakietów hello. Koszt węzła połączony z i jest reprezentowany przez cost(i), gdzie cost(i)>=0, który powinien być odpowiednio zdefiniowany. Dla kaŝdej grupy multicastowej g MANSI utrzymuje poniŝej opisaną strukturę danych na kaŝdym węźle i.[23] Join Table utrzymuje listę węzłów, które proszą o przyłączenie do grupy multicastowej poprzez węzeł, dla którego ta tablica jest utrzymywana. Tablica dla węzła i dla grupy g oznaczana jest przez join g (i) Jest ona aktualizowana kiedy węzeł i słyszy pakiety Join Request do siebie. KaŜdy wpis w join g (i) ma formułę <r,h r >, gdzie r oznacza ID węzła proszącego o dołączenia, a h r jest jego wysokością. Tablica ta jest po zainicjowaniu pusta dla kaŝdego węzła. Węzeł i jest węzłem pośredniczącym w grupie g tak długo, jak join g (i)/=0. Kiedy sąsiad j jest usuwany z ntab(i) w skutek awarii łącza, węzeł i usunie wszystkie wpisy odnoszące się do niego z tablicy Join Table.[23] ID rdzenia (ang. Core ID) oznaczany przez core g (i) aby wskazać aktualny rdzeń w grupie g, po zainicjowaniu ma wartość INVALID ADDRESS.[23] Numer sekwencyjny rdzenia (ang. Core sequence number) przetrzymuje drogę ostatniego Core Announce sequence number, oznaczany jako seqno g (i) i inicjowany wartością zerową.[23] Wysokość (ang. height) reprezentuje wysokość węzła i, jeśli jest on aktualnie członkiem grupy, lub węzłem pośredniczącym grupy g. Wysokość węzła i jest największą wartością ID, włączając węzeł i równieŝ, jeśli jest on uczestnikiem grupy.[23] 72

73 Tablica feromonów (ang. Pheromone table) mapuje sąsiednie węzły i wysokości na intensywność feromonów. Intensywność feromonów moŝna skojarzyć z wysokością h połączenia (i,j) widzianą przez węzeł i dla grupy multicastowej g.[23] Tablica najlepszych kosztów (ang. Best cost table) - trzyma informacje o tym jak blisko węzeł i znajduje się od węzłów pośredniczących z pewnymi wysokościami, w kategoriach kosztów ścieŝki. Informacje o najlepszej ścieŝce są uŝywane do ustalenia czy pakiet Backward Ant wrócił z dobrej ścieŝki, czy ze złej.[23] Inicjalizacja grup pośredniczących. (ang. Forwarding Set Initialization) Protokół MANSI jest reaktywny, a więc nie wysyła Ŝadnych pakietów kontrolnych (oprócz hello) jeśli nie ma Ŝadnych aktywnych nadawców multicastowego ruchu. Kiedy uczestnik c grupy g posiada dane do wysłania i widzi, Ŝe nie istnieje jeszcze rdzeń dla tej grupy g, ustawia core g (c) na jego własne ID i rozsyła pakiet Core Announce po całej sieci, aby ogłosić siebie nowym rdzeniem. Pakiet Core Announce składa się z ID węzła c, ID grupy multicastowej g, numeru sekwencyjnego, i kosztu, który na początku wynosi zero (rysunek 50). KaŜdy węzeł i, dopóki nie otrzyma pakietu Core Announce, odrzuca wiadomość, jeśli ogłoszenie napływa z tego samego węzła z tym samym numerem sekwencyjnym. Jeśli zdarzy się, Ŝe kilka węzłów w tym samym momencie chce zostać rdzeniem oczywistym jest, Ŝe zduplikowane pakiety Core Announce nie będą przetwarzane i pakiety tylko od jednego węzła są dopuszczany. [23] Procedura Core Announce jest realizowana przez pewien algorytm, który nie będzie tutaj omówiony. Istnieje równieŝ procedura UpdatePheromoneAndCost, która realizuje aktualizację kosztów i feromonów.[23] Dla kaŝdego węzła i wartość ID węzła core g (i) jest resetowana do postaci INVALID ADDRESS jeśli nie pojawiły się Ŝadne pakiety Core Announce w pewnym okresie czasu, ustalonym przez wartość ANNOUNCE INTERVAL. Węzeł będący rdzeniem c równieŝ w czasie ANNOUNCE INTERVAL powinien wysłać wiadomość dla grupy g.[23] 73

74 Tak długo, jak dany uczestnik grupy multicastowej lub węzeł pośredniczący dostaje pakiety Core Announce od rdzenia, okresowo rozsyłane są broadcastowo pakiety Join Request do sąsiadów danego węzła.[23] Rysunek 49 przedstawia inicjalizację grupy pośredniczącej.[23] Jeśli węzeł i jest uczestnikiem grupy lub węzłem pośredniczącym la więcej niŝ jednej grupy, moŝe wkomponować więcej niŝ jeden wpis dołączenia do grupy w jednym pakiecie Join Request (rysunek 51). Kiedy węzeł j otrzyma pakiet Join Request od węzła i i zobaczy swoje ID w pakiecie, to węzeł taki powinien przekształcić się w węzeł pośredniczący w grupie g. Dodaje wtedy ID nadawcy pakietu i jego wysokość w swojej tablicy Join Table. Rozsyła później broadcastowo swój pakiet Join Request z zawartą informacją o następnym skoku. Prośby o dołączenia będą przesłane do rdzenia danej grupy. Jeśli jednak do węzła j dotrze z powrotem pakiet Join Request od węzła i, ale bez jego ID, lub jeśli do węzła j w ogóle nie dotrą pakiety Join Request przez pewien okres czasu, to wpis z tablicy Join Table odnoszący się do węzła j zostaje usunięty. KaŜdy węzeł i będzie węzłem przekazującym, dopóki jest tablica Join Table jest nie pusta.[23] 74

75 Rys. 49. Przykład działania MANSI (a)powstanie sieci z 3 uczestnikami grupy: 1,47,50, gdzie 1 to rdzeń, (b)rozpowszechnienie pakietu Core Announce, (c) zainicjowanie komunikacji multicastowej w oparciu o reverse paths do rdzenia, w wyniku grupa pośrednicząca (hosty szare), (d)grupa pośrednicząca z 4 węzłów wyuczonych przez ants. [23] Rys. 50. Format pakietu Core Announce.[23] Rys. 51. Format pakietu Join Request.[23] 75

76 Ewolucja grupy pośredniczącej. (ang. Forwarding Set Evolution) Jeśli grupa pośrednicząca została juŝ stworzona, kaŝdy uczestnik grupy multicastowej, który nie jest rdzeniem, próbuje znaleźć lepsze połączenie do rdzenia, w celu zminimalizowania ogólnego kosztu grupy pośredniczącej, poprzez wysyłanie Forward Ant co określony czas zwany ANT INTERVAL. Pakiet Forward Ant, którego format moŝemy zobaczyć na rysunku 52 posiada następujące pola:[23] Rys. 52.Format pakietów Forward Ant i Backward Ant.[23] grupa: ID danej grupy multicastowej [23] wysokość: wysokość węzła pośredniczącego znalezionego przez danego Anta. Pole to jest uŝywane tylko, gdy ten Ant został przekształcony w Backward Ant.[23] f: flaga pośrednicząca, która odróŝnia pakiety Forward Ant od Backward Ant.[23] d: deterministyczna flaga, która wskazuje, Ŝe dany ant powinien zawsze podąŝać po najlepszej znanej ścieŝce, bazując na kosztach zawartych w tablicy najlepszych kosztów. Powodem, dla którego stosuje się tą flagę, jest mobilność i dynamiczność węzłów, a co za tym idzie ich kosztów. Dlatego teŝ, wpisy zawarte w tablicy najlepszych kosztów mogą być nie aktualne, jeśli węzły wykazują duŝą mobilność.[23] cost: ogólny koszt wszystkich węzłów, które dany Ant odwiedził.[23] costlimit: limit kosztu jaki moŝe osiągnąć dany Ant na ścieŝce po opuszczeniu swojego źródła.[23] visitednodes: grupa węzłów odwiedzona przez danego Anta.[23] Węzeł rozmieszczający pakiety Forward Ant wywołuje proceduę ReleaseForwardAnt, w celu znalezienia następnego skoku, do którego powędruje Ant. Jeśli zostanie juŝ wybrany następny skok, jego ID jest dodawane na końcu pola visitednodes w pakiecie Anta i jest on rozsyłany broadcastowo.[23] Kiedy węzeł j otrzyma pakiet Forward Ant, w pierwszej kolejności sprawdza czy ID tego pakietu jest zgodne z ID umieszczonym na końcu pola visitednodes. Jeśli nie pakiet jest odrzucany. Jeśli ID są zgodne, to węzeł j wie, Ŝe Ant ten jest zamierzony i akceptuje go. Później węzeł j sprawdza, czy nie jest on węzłem pośredniczącym dla grupy i czy jego wysokość nie jest większa od ID nadawcy Anta. 76

77 Jeśli tak, węzeł j uświadamia sobie, Ŝe członek grupy, który wysłał do niego Anta moŝe dołączyć do grupy multicastowej przez niego samego, czyli przez węzeł j. Ant jest wtedy przekształcany w Backward Ant poprzez zresetowanie flagi f. Jego koszt jest zerowany, aby wyliczyć całkowity koszt drogi powrotnej, a pole height (wysokości) jest ustawione na wartość wysokości węzła j. Usuwany jest równieŝ ostatni wpis z pola visitednodes.[23] Jeśli warunki, które pozwalają przekształcić Anta w Backward Ant nie są satysfakcjonujące, węzeł j zwiększa o swoją wartość koszt zawarty w polu cost. Wywoływana jest procedura ReleaseForwardAnt.[23] Kiedy węzeł k otrzyma pakiet Backward Ant od węzła j, uruchamia procedurę UpdatePheromoneAndCost, które zaktualizują wpisy w tablicy feromonów i tablicy najlepszych kosztów odnosząc się do węzła j i pola wysokości. Jeśli Ant jest deterministyczny, koszt zawarty w pakiecie jest aktualnym kosztem ścieŝki uŝywanym przez nadawcę Anta, w celu dołączenia do grupy multicastowej. Wtedy teŝ, wartość najlepszego kosztu jest aktualizowana do wysokości zawartej w polu height. Jeśli Ant nie jest deterministyczny, najlepszy koszt jest aktualizowany tylko w przypadku, kiedy wartość pola height jest większa od zwróconego kosztu, a oznacza to, Ŝe Ant znalazł lepszą ścieŝkę do grupy multicastowej. Intensywność feromonów na tym połączeniu jest równieŝ aktualizowana do maksymalnie osiągniętej wartości.[23] Po zaktualizowaniu tablicy feromonów i tablicy najlepszych kosztów, węzeł k sprawdza ostatni wpis w polu visitednodes pakietu Backward Ant. Jeśli jego własne ID jest równe wartości tego wpisu, to dodaje swój koszt do pola cost i usuwa ostatni wpis z pola visitednodes, a następnie, broadcastowo, rozsyła ten pakiet. [23] Multicastowe przekazywanie danych. (ang. Multicast Data Forwarding) Jak wiadomo, protokół MANSI jest protokołem siatko strukturalnym, co oznacza, Ŝe węzły pośredniczące i członkowie danej grupy, mogą przyjmować pakiety od dowolnych węzłów. KaŜdemu pakietowi przypisany jest unikalny numer sekwencyjny. Numery te są sprawdzane przez kaŝdy węzeł pośredniczący i członków grupy w celu upewnienia się, Ŝe nie ma jego duplikatów. Kiedy węzeł i otrzyma nie zduplikowany pakiet danych, sprawdza, czy nie jest on węzłem pośredniczącym dla danej grupy. Jeśli tak ponownie rozsyła broadcastowo ten pakiet. Jeśli nie jest on odrzucany. [23] 77

78 Mobilność. (ang. Handling Mobility) W protokole MANSI mobilność jest uznawana za pewien naturalny, nierozłączny element sieci i zmiany w jej topologii nie wywołują trudności uniemoŝliwiających komunikację. Wszelkie zerwania połączeń są korygowane w sposób płynny i elastyczny. Dzięki pakietom Backward Ant i Forward Ant, kaŝda ścieŝka budowana jest w oparciu o grupy pośredniczące, które są wymuszane tak długo, jak długo optymalna ścieŝka jest nieaktywna. NaleŜy jednak pamiętać o tym, Ŝe sieci dynamiczne mogą powodować, Ŝe optymalna komunikacja od czasu do czasu ulega zmianom, nawet jeśli dotychczasowa łączność nie ulega zmianom. Protokół MANSI wykorzystując zróŝnicowanie rozsyłanych pakietów Forward Ant, przy odkrywaniu nowych ścieŝek, moŝe w sposób wydajny reagować na wszelkie zmiany w topologii sieci poprzez rozwijanie konfiguracji multicastowych grup pośredniczących. [23] Kiedy połączenie, które jest aktualnie wykorzystywane do wysłania pakietu Join Request przez jednego z członków grupy lub przez węzeł pośredniczący w transmisji ulegnie awarii, wpis w tablicy feromonów jest równieŝ usuwany. W następstwie tego, wszystkie pakiety Forward Ant będą odsyłane na inne ścieŝki, a większość z nich zostanie wysłanych na następny skok, który miał drugą co do największych wartości przed awarią, w tablicy feromonów. Jeśli następny skok prowadzi do węzła pośredniczącego z większą wysokością, pakiet Backward Ant powróci i zostanie zaktualizowany feromon na nowej ścieŝce. Jeśli jednak pakiet Forward Ant nie znajdzie nowej ścieŝki po wystąpieniu awarii, to rozesłany zostanie pakiet Core Announce, który przywróci łączność.[23] W protokole MANSI zastosowany został mechanizm adaptacji mobilności (ang. mobility-adaptative mechanizm), który powoduje, Ŝe przekazywanie pakietów podczas poruszania się węzłów, jest wyjątkowo efektywne. [23] Na rysunku 53 (a) mamy utworzoną grupę pośredniczącą, stworzoną przez protokół MANSI bez mechanizmu adaptacji mobilności, dla grupy multicastowej złoŝonej z trzech jej uczestników, z pośród pięćdziesięciu, gdzie kaŝdy węzeł porusza się z prędkością 10 m/s. Jak widać na rysunku połączenie tych węzłów stanowi prawie linię prostą i jest bardzo wraŝliwe na wszelkie awarie. Na rysunku 53(b) został włączony mechanizm adaptacji mobilności. MoŜna zaobserwować, Ŝe grupę pośredniczącą, oprócz uczestników grupy i węzłów pośredniczących, stanowią równieŝ ich sąsiedzi, dzięki czemu łączność staje się bardziej stabilna. [23] 78

79 Rys. 53.Sieć ilustrująca działanie mechanizmu adaptacji mobilności, (a) bez mechanizmu, (b) z włączonym mechanizmem. [23] Tabela 3 Podstawowe parametry protokołu MANSI 79

80 6. Symulacje Informacje wstępne. Do wykonania symulacji, zaprezentowanych w tej pracy, został wykorzystany program o nazwie QualNet (wersja 4.0)[41]. Symulacje zostały wykonane na komputerze wyposaŝonym w system Windows XP i bibliotekę JDK ver _03. Przeprowadzenie kaŝdej z tych symulacji związane jest z odpowiednim skonfigurowaniem symulatora, czyli z ustawieniem wszystkich wartości, potrzebnych do wykonania badania sieci. Dokonać tego moŝna na dwa sposoby: pierwszy poprzez ręczną edycję plików konfiguracyjnych, drugi poprzez interfejs graficzny. NajwaŜniejszym plikiem konfiguracyjnym jest plik z rozszerzeniem config. W nim zawarte są wszystkie, potrzebne do zasymulowania sieci, ustawienia, jak równieŝ poprzez jego uruchomienie wywołujemy symulację. Rys. 54. Wymagania systemowe. PoniŜej została umieszczona tabela z wartościami, z jakmi, w zaleŝności od mierzonego kryterium, będzie moŝna się spotkać w programie. 80

81 Przepustowość 2 Mbps Maksymalny czas symulacji 500 s Liczba węzłów 50 Czas przestoju 0 s Szybkość przemieszczania się węzłów 1m/s-20m/s Rozmiar planszy 1000x1000m Rodzaj ruchu sieciowego MCBR Tempo wysyłania pakietów 5 pakietów/s Rozmiar pakietu 512 B Liczba pakietów do wysłania 1000 Maksymalny czas wysyłania pakietów 250 sekund Ilość grup multicastowych 1 Tabela 4 Podstawowe parametry symulacji Kryteria symulacji. PoniŜej wymienione kryteria zostały wykorzystane w celu zbadania wydajności protokołu ODMRP. Jako podstawa do ustalenia metryk, wg których będzie mierzony protokół, uŝyty został dokument wydany przez organizację IETF MANET.[42] Współczynnik Dostarczenia Pakietu. (ang. Packet Delivery Ratio) Jest to współczynnik liczby pakietów doręczonych do odbiorców przez liczbę pakietów jakie powinny dotrzeć do celu. Parametr ten pozwala określić efektywność danego protokołu pod względem doręczania pakietów do celu. Liczbę pakietów jakie powinny dotrzeć do celu tak naprawdę stanowi liczba pakietów wysłanych przez nadawców multicastowych.[25] Współczynnik wysłanych pakietów, podzielony przez liczbę pakietów dostarczonych do celu. (ang. Packet Transmmision Ratio) Liczbę wysłanych pakietów stanowi licznik danych wysłanych z kaŝdego węzła, w tym uwzględnia pakiety, które zostały odrzucone lub które były retransmitowane przez węzły przekazujące. NaleŜy tutaj zwrócić uwagę na fakt, Ŝe w sieciach unicastowych wartość ta jest równa bądź większa od jednego, natomiast w sieciach multicastowych, odkąd dane jednej transmisji mogą być dostarczone do wielu odbiorców, wartość ta moŝe być mniejsza od jednego.[42] 81

82 Wysłane pakiety kontrolne podzielone przez liczbę pakietów dostarczonych do celu. Jest to współczynnik pakietów kontrolnych wysłanych do pakietów, które dotarły do celu. Pozwala on zmierzyć efektywność wykorzystania pakietów kontrolnych do doręczenia danych.[42] Suma wysłanych pakietów kontrolnych wraz z liczbą wysłanych pakietów w ogóle podzielona przez liczbę pakietów dostarczonych do celu. Parametr ten pozwala zmierzyć efektywność warunków decydujących o dostępie do kanału i jest bardzo waŝny w sieciach ad hoc, w których warstwa łącza danych jest zaleŝna od warunków dostępowych do łącza.[42] 6.3. Szczegółowe parametry ustawień sieci. Liczba nadawców. Zbadana zostanie efektywność protokołu ODMRP ze względu na ilość nadawców wysyłających cyklicznie co 0.2s pakiety o wielkości 512B przez czas 250 sekund. Wartości ustawienia symulacji prezentuje poniŝsza tabela: Liczba nadawców 1-20 Liczba uczestników grupy 20 Maksymalna szybkość węzłów 1m/s Rodzaj ruchu sieciowego MCBR Tempo wysyłania pakietów 5p/s Tabela 5 Parametry symulacji zorientowanej na liczbę nadawców. Mobilność. Zbadana zostanie efektywność radzenia sobie protokołu ODMRP z szybkimi i częstymi zmianami topologii ze względu na mobilność węzłów, tzn. z uwzględnieniem poruszania się węzłów podczas transmisji danych.. Wartości ustawienia symulacji prezentuje poniŝsza tabela: Liczba nadawców 5 Liczba uczestników grupy 20 Maksymalna szybkość węzłów 1m/s 20 m/s Przestój węzła 0 Rodzaj ruchu sieciowego MCBR Tempo wysyłania pakietów 5p/s Tabela 6 Parametry symulacji zorientowanej na szybkość poruszania się węzłów. 82

83 Wielkość grupy multicastowej. Zbadana zostanie efektywność protokołu ODMRP ze względu na liczbę uczestników grupy multicastowej, co pozwoli zbadać skalowalność tego protokołu. Wartości ustawienia symulacji prezentuje poniŝsza tabela: Liczba nadawców 5 Liczba uczestników grupy Maksymalna szybkość węzłów 1m/s Rodzaj ruchu sieciowego MCBR Tempo wysyłania pakietów 5p/s Tabela 7 Parametry symulacji zorientowanej na liczbę węzłów naleŝących do grupy multicastowej. 83

84 6.4. Wyniki symulacji protokołu ODMRP Liczba nadawców. Pierwszą grupę przeprowadzonych symulacji stanowi uwzględnienie zróŝnicowania pod względem liczby źródeł nadawania pakietów do grupy multicastowej. Pozwala to określić skalowalność danego protokołu, w tym wypadku ODMRP, czyli moŝliwości jego wykorzystania w rzeczywistości. Na rysunku 55 zbadana została zaleŝność pomiędzy doręczonymi pakietami, a pakietami, które w rzeczywistości powinny dotrzeć do adresata. Jak widać, w przypadku jednego źródła nadawania pakietów sieć, składająca się z pięćdziesięciu węzłów, radzi sobie bardzo dobrze. Współczynnik doręczenia paczki do adresata w tym wypadku wynosi prawie 100%. Zwiększając liczbę stacji mających dane do wysłania moŝna zauwaŝyć, Ŝe skuteczność w doręczaniu pakietów do celu zaczyna dramatycznie spadać i w przypadku 15 stacji nadających pakiety, współczynnik doręczania pakietu do celu wynosi poniŝej 40%, idąc dalszym krokiem jest on jeszcze niŝszy. Na rysunku 56 z kolei podany jest koszt doręczenia pojedynczego pakietu do celu. Dla 15 stacji nadających wynosi on prawie 300%, co oznacza, Ŝe aby doręczyć jeden pakiet do celu, trzeba wysłać aŝ trzy inne. Na rysunku 57 moŝna zaobserwować jak duŝą skalę stanowią pakiety kontrolne i tak dla 15 stacji nadających liczba wysyłanych pakietów kontrolnych jest trzy razy większa niŝ dla 5 stacji, natomiast dla większej liczby stacji nadających, ilość pakietów kontrolnych zaczyna być bardzo duŝa. Podsumowaniem tej symulacji jest rysunek 58, na którym doskonale widać, Ŝe na jeden doręczony pakiet do celu przypadają cztery inne, a więc wyjaśnia, dlaczego na rysunku 55 tak diametralnie malała skuteczność doręczania pakietów do celu. Podsumowując, na podstawie przeprowadzonej symulacji, moŝna śmiało stwierdzić, Ŝe protokół ODMRP nie wykazuje zbyt duŝej skalowalności dla doręczanych pakietów, nawet przy niezbyt duŝej liczbie stacji nadających. W protokole ODMRP kaŝda stacja nadająca wysyła okresowo, w zaleŝności od dobranego parametru, Ŝądanie odświeŝenia trasy przez sieć. Jak moŝna zauwaŝyć, efektem zwiększania liczby stacji nadających są zatory w sieci i nadmierny ruch kontrolny, a co za tym idzie współczynnik doręczanych pakietów do celu bardzo szybko maleje. 84

85 Dane doręczone/dane które powinny być doręczone w sieci z 50 węzłami PDR 1,2 1 0,8 0,6 0,4 0, Liczba nadawców ODMRP Rys. 55. Packet Delivery Ratio jako funkcja liczby nadawców pakietów. Dane wysłane/dane doręczone w sieci z 50 węzłami PTR 4 3,5 3 2,5 2 1,5 1 0, Liczba nadawców ODMRP Rys. 56. Packet Transmssion Ratio jako funkcja liczby nadawców pakietów. 85

86 Pakiety kontrolne/pakiety doręczone Pakiety kontrolne/pakiety doręczone w sieci z 50 węzłami 0,3 0,25 0,2 0,15 0,1 0, Liczba nadawców ODMRP Rys. 57. Pakiety kontrolne przez pakiety doręczone, jako funkcja liczby nadawców pakietów. Pakiety kontrolne + Pakiety wysłane / Pakiety doręczone w sieci z 50 węzłami Pakiety kontrolne+pakiety wysłane/pakiety doręczone 4,5 4 3,5 3 2,5 2 1,5 1 0, Liczba nadawców ODMRP Rys. 58. Pakiety kontrolne wraz z danymi przez pakiety doręczone, jako funkcja liczby nadawców pakietów. 86

87 Mobilność. W drugiej grupie symulacji uwzględniona została jedna z najwaŝniejszych cech sieci ad hoc, a mianowicie mobilność węzłów, która pozwala określić zdolność danego protokołu do reagowania na zmiany w topologii sieci, a co za tym idzie, na zmiany tras przesyłania pakietów. Na rysunku 59 widać, Ŝe przemieszczanie się węzłów, a takŝe zmienna ich prędkość nie robi praktycznie Ŝadnego wraŝenia na protokole ODMRP. Skuteczność w doręczaniu pakietów do celu zmienia się nieznacznie w stosunku do prędkości uzyskiwanych przez węzły. Dla węzłów poruszających się z prędkością 1m/s wynosi ona 78 %, a dla prędkości 20m/s 65%, a więc jest bardzo duŝa. Na rysunku 60 moŝna zauwaŝyć, Ŝe ilość pakietów potrzebnych do dostarczenia pojedynczego pakietu do celu zmienia się nie znacznie i jest na bardzo niskim poziomie, biorąc pod uwagę szybko zmieniającą się topologię. RóŜnica pomiędzy węzłami poruszającymi się z prędkością 1m/s, a 20m/s wynosi zaledwie 17%. Na rysunku 61 doskonale widać, Ŝe liczba pakietów kontrolnych, pomimo zmiany szybkości poruszania się węzłów, praktycznie się nie zmienia i jest na tym samym poziomie, co w przypadku węzłów poruszających się duŝo wolniej. Rysunek 62 jest podsumowaniem tej grupy symulacji. Wynika z niego, Ŝe koszt dostarczenia pojedynczego pakietu zwiększa się o zaledwie 17%, a biorąc pod uwagę, Ŝe prędkość poruszającego się węzła wzrasta dwudziestokrotnie (z 1m/s do 20m/s), to wzrost tego kosztu jest praktycznie nie zauwaŝalny. Symulacje te pozwalają śmiało stwierdzić, Ŝe protokół ODMRP doskonale radzi sobie z mobilnością węzłów. Jego struktura siatki posiada wiele alternatywnych ścieŝek, którymi moŝe zostać przesłany pakiet, co czyni go dość mocno odpornym, a co za tym idzie, równieŝ wydajnym, na zmiany w topologii sieci. 87

88 Pakiety doręczone/pakiety które powinny dojść do celu w sieci z 50 węzłami PDR 1 0,8 0,6 0,4 0, Prędkość poruszania się [m/s] ODMRP Rys. 59.Packet Delivery Ratio jako funkcja mobilności. Dane wysłane/dane doręczone w sieci z 50 węzłami PTR 1,65 1,6 1,55 1,5 1,45 1,4 1,35 1,3 1,25 1, Prędkość poruszania się [m/s] ODMRP Rys. 60. Packet Transmission Ratio jako funkcja mobilności. 88

89 Pakiety kontrolne/pakiety doręczone w sieci z 50 węzłami Pakiety kontrolne/pakiety doręczone 0,06 0,05 0,04 0,03 0,02 0, Prędkość poruszania się [m/s] ODMRP Rys. 61.Pakiety kontrolne do pakietów doręczonych jako funkcja mobilności. Pakety kontrolne + Pakiety wysłane / Pakiety doręczone w sieci z 50 węzłami Pakiety kontrolne+pakiety wysłane/pakiety doręczone 1,7 1,65 1,6 1,55 1,5 1,45 1,4 1,35 1,3 1, Prędkość poruszania się [m/s] ODMRP Rys. 62. Pakiety kontrolne wraz z pakietami wysłanymi do pakietów doręczonych jako funkcja mobilności. 89

90 Wielkość grupy multicastowej. Kolejna grupa symulacji jest uzaleŝniona od rozmiarów grupy multicastowej. Na rysunku 63 moŝna zauwaŝyć, Ŝe zwiększenie liczby uczestników danej grupy multicastowej praktycznie nie ma wpływu na współczynnik skuteczności dostarczania pakietów do celu. RóŜnica pomiędzy dziesięcioma, a pięćdziesięcioma uczestnikami waha się w granicach 10% i nie spada poniŝej 70%, a więc moŝna jasno stwierdzić, Ŝe liczba uczestników grupy nie powoduje większych perturbacji w sieci. Rysunek 64 podkreśla, Ŝe koszt doręczenia pakietu do celu równieŝ nie ulega drastycznym zmianom. Dla grupy multicastowej skupiającej 50 węzłów, wynosi ok. 150%, a więc średnio na dwa doręczone pakiety przypada jeden wysłany dodatkowo, na przykład w skutek retransmisji. Na rysunku 65 moŝemy zaobserwować zmiany w ilości wysyłanych pakietów kontrolnych. W przypadku zwiększania liczby uczestników danej grupy multicastowej z 10 do 50, liczba pakietów kontrolnych zwiększa się dwukrotnie, ale nadal pozostaje na bardzo niskim poziomie, w stosunku do pakietów dostarczonych do celu. Na rysunku 66 widać, Ŝe róŝnica w wysyłanej ilości pakietów, pomiędzy małą i dość duŝą grupą mobilnych węzłów(10-50), jest niewielka i nie przekracza 25%. Z symulacji tych wynika, Ŝe protokół ODMRP jest dość dobrze przystosowany do zmian w rozmiarach grupy multicastowej. Współczynnik dostarczenia pakietu do celu utrzymuje się na dość stałym i duŝym poziomie, a to przekłada się równieŝ na niewielki wzrost w ruchu kontrolnym i kolizjach. 90

91 Pakiety doręczone/pakiety które powinno dojść do celu w sieci z 50 węzłami 0,85 0,8 PDR 0,75 0,7 0, Ilość uczestników grupy ODMRP Rys. 63.Packet Delivery Ratio, jako funkcja liczby uczestników grupy multicastowej. Dane wysłane/dane doręczone w sieci z 50 węzłami 1,6 PTR 1,5 1,4 1,3 1,2 1, Ilość uczestników grupy ODMRP Rys. 64. Packet Transmission Ratio, jako funkcja liczby uczestników grupy multicastowej. 91

92 Pakiety kontrolne/pakiety doręczone w sieci z 50 węzłami Pakiety kontrolne/pakiety doręczone 0,1 0,08 0,06 0,04 0, Ilość uczestników grupy ODMRP Rys. 65. Pakiety kontrolne do pakietów doręczonych, jako funkcja liczby uczestników grupy multicastowej. Pakety kontrolne + Pakiety wysłane / Pakiety doręczone w sieci z 50 węzłami 1,7 Pakiety kontrolne+pakiety wysłane/pakiety doręczone 1,6 1,5 1,4 1,3 1, Ilość uczestników grupy ODMRP Rys. 66. Pakiety kontrolne oraz wysłane pakiety z danymi do pakietów doręczonych, jako funkcja liczby uczestników grupy multicastowej. 92

93 7. Podsumowanie. Na początku pracy mowa była o nielicznych pozycjach w literaturze polskiej, które mogłyby pomóc w rozwinięciu tematu rutingu multicastowego w sieciach ad hoc. Jednak ma to szansę się zmienić. Ciągłe prace nad sieciami ad hoc, a takŝe rozwój technologiczny wraz z potrzebami zwykłych uŝytkowników sprawiają, Ŝe w niedalekiej przyszłości sieci multicastowe mają szanse rozwoju. Jednak wszystko zaleŝy od algorytmów trasowania, które pozwalają zwiększać efektywność, wydajność i skalowalność sieci. Poprzez analizę wybranych protokołów multicastowych w sieciach ad hoc moŝemy zauwaŝyć, Ŝe kaŝdy z nich cechują pewne specyficzne właściwości, które czynią je przydatne w określonych warunkach. Jak moŝna zauwaŝyć w przekroju całej pracy dyplomowej algorytmy, realizujące ruting w sieciach ad hoc, wykazują ogromne zróŝnicowanie. Jedne konstruują drzewa multicastowe, które pozwalają zredukować opóźnienia, z kolei inne budują siatki, aby zapewnić efektywność i wydajność. Gdyby naszym celem była jak najefektywniejsza mobilność węzłów, to doskonale w tym przypadku sprawdzą się protokoły siatko strukturalne, z grupy reaktywnych, dzięki redundantnym połączeniom w siatce. Z kolei, jeŝeli istotny będzie fakt sprawnej obsługi duŝej liczby nadawców, to lepiej sprawdzą się protokoły o strukturze drzewa, które swoją budową będą hamować zbyt nadmierny ruch kontrolny. W całej pracy jest mowa o mobilności, a urządzenia te są nieodłącznie związane z oszczędzaniem energii. JeŜeli istotne będzie oszczędzanie energii to lepiej sprawdzą się protokoły o strukturze drzewa, gdyŝ protokoły siatko strukturalne w swojej komunikacji broadcastowej korzystają ze zbyt duŝej liczby węzłów pośredniczących. JeŜeli będziemy chcieli ograniczyć w danej sieci liczbę węzłów, które biorą udział w komunikacji, to moŝna dokonać tego za pomocą protokołów inteligentnych. JeŜeli będziemy chcieli, aby pakiety były przesyłane przede wszystkim szybko to lepszym wyborem byłyby protokoły proaktywne, z kolei jeśli waŝne dla nas jest oszczędzanie energii urządzeń, to swoją rolę mogą spełnić tutaj protokoły proaktywne. Na podstawie przeprowadzonych symulacji moŝna wywnioskować, Ŝe ruting multicastowy w sieciach ad hoc, o budowie siatkowej i działający reaktywnie, charakteryzuje się dość duŝą efektywnością i wydajnością. Jak moŝna zauwaŝyć, protokół ODMRP, dzięki swojej budowie, zapewnia redundantne połączenia, które jak 93

94 wykazała symulacja sprawiają, Ŝe pakiet ma duŝe szanse na dotarcie do celu, nawet w przypadku braku dostępności głównych tras rutowania pakietów. Symulacje wykazały równieŝ, Ŝe protokół ten jest odporny na częste zmiany połoŝenia, a tym samym topologii sieci, co ma znaczenie podczas przemieszczania urządzeń mobilnych. Natomiast główną wadą tego protokołu jest skalowalność ze względu na liczbę nadawców danych. Procent dotarcia pakietów do celu (PDR) dramatycznie wtedy spada. Wynika to z konieczności utrzymania połączeń pomiędzy nadawcami i odbiorcami. Jeśli liczba węzłów wysyłających dane wzrasta, okresowo wysyłany pakiet Join Request, generowany przez kaŝdego nadawcę, powoduje zwiększenie liczby zatorów w sieci, jak równieŝ wysyłanych pakietów kontrolnych. Ma to ogromny wpływ, jeśli chcielibyśmy zastosować taki protokół do komunikacji wielu urządzeń mobilnych, połączonych w jedną lub wiele grup multicastowych. Biorąc pod uwagę całość rozwaŝań nasuwa się wniosek, Ŝe ruting multicastowy w sieciach ad hoc stanowi przyszłość i warto tę dziedzinę rozwijać. Technologia ulega ciągłemu rozwojowi i dzięki temu moŝna spróbować wyeliminować pewne błędy z niektórych protokołów po to, aby stały się mniej zawodne, bardziej wydajne i efektywne. 94

95 8. Bibliografia. [1] P.Kuosmanen, Classification of Ad Hoc Routing Protocols, Finnish Defence Forces Naval Academy, czerwiec [2] J.Słoczyński, Nietypowe algorytmy rutowania, Politechnika Łódzka, Łódź, wrzesień [3] M.Ilyas, The Handbook of Ad Hoc Wireless Networks, Florida Atlantic University, Florida, [4] Dewan Tanvir Achmed, Multicasting in Ad Hoc Networks, University of Ottawa, Ottawa, [5] Y.Zhu, Pro Active Connection Maintenance in AODV and MAODV by Yufang Zhu, Department of Systems and Computer Engineering, Carleton University, Ottawa, wrzesień [6] D.T.Ahmed, S.Shirmohammadi, Architectural Analysis of Multicast Routing Protocols for Wireless Ad Hoc Networks, University of Ottawa, Ottawa, listopad [7] Z.M.Alfawaer, GuiWei Hua, N.Ahmed, A Novel Multicast Routing Protocol for Mobile Ad Hoc Networks, School of Information Sciences and Engineering Central South University, Kuantan, Pahang, Malaysia, [8] Mobilne sieci ad hoc w technologii Bluetooth, AGH University Of Science, [9] L.M. Feeney: A Taxonomy for Routing Protocols in Mobile Ad Hoc Networks, SICS Technical Report T99/07, październik [10] Perkins, C. E.; IP mobility support, RFC 2002, październik 1996, [11] Perkins, C. E., Bhagwat, P.; "Highly Dynamic Destination-Sequenced Distance- Vector Routing (DSDV) for Mobile Computers", Proceedings of the ACM SIGCOMM.94 Conference on Communications Architectures, Protocols and Applications, London, UK, sierpień [12] Jubin, J., Tornow, J. D.; The DARPA Packet Radio Network Protocols, Proceedings of the IEEE, styczeń 1987, Vol. 75, No. 1. [13] Chiang, C.-C.; Wu, H.-K.; Liu, W., Gerla, M.; Routing in Clustered Multihop Mobile Wireless Networks with Fading Channel, Proceedings of IEEE Singapore International Conference on Networks (SICON'97), Singapore, kwiecień

96 [14] Murthy, S., Garcia-Luna-Aceves, J. J.; An Efficient Routing Protocol for Wireless Networks, ACM Mobile Networks and Applications Journal (MONET), Special Issue on Routing in Mobile Communication Networks, październik 1996, Vol.1, No. 2. [15] Johnson, D. B., Maltz, D. A.; "Dynamic Source Routing in Ad Hoc Wireless Networks", Mobile Computing, edited by Tomas Imielinski and Hank Korth, Kluwer Academic Publishers, ISBN: , [16] Corson, S., Ephremides. A.; A distributed routing algorithm for mobile wireless networks, ACM/Baltzer Journal of Wireless Networks, February 1995, Vol. 1, No. 1. [17] Park, V. D., Corson, M. S. A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks, Proceedings of the16th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'97), Kobe, Japan, kwiecień 1997, Vol. 3. [18] J.Manner, M.Kojo, Mobility related terminology, <draft-ietf-seamobymobilityterminology-06.txt>, luty [19] Sinha, P., Sivakumar, R., Bharghavan, V., MCEDAR: Multicast Core Extraction Distributed Ad-hoc Routing, IEEE Wireless Communications and Networking Conference (WCNC 99), [20] Lin, C., Chao, S., A Multicast Routing Protocol for Multihop Wireless Networks, IEEE Global Telecomm. Conference (GlobeCom 1999), [21] J.J.Garcia-Luna-Aceves, E.L.Madruga, The Core-Assisted Mesh Protocol, IEEE Journal on Selected Areas in Communications, 17, , kwiecień [22] Lee, S., Gerla, M., Chiang, C., On-Demand Multicast Routing Protocol, IEEE Wireless Communications and Networking Conference (WCNC 99), [23] C.Shen, C.Jakiaeo, Ad hoc Multicast Routing Algorithm with Swarm Intelligence, University of Delaware, Newark, sierpień [24] E.M. Royer, C-K. Toh, A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks, IEEE Personal Communications Magazine, kwiecień 1999, pp [25] E.Cheng, On-Demand Multicast Routing in Mobile Ad Hoc Networks, Carleton University, Ottawa, styczeń [26] E.M.Royer, Multicast Ad Hoc On-Demand Distance Vector (MAODV) Routing, <draft-ietf-manet-maodv-00.txt>, IETF MANET Working Group, lipiec [27] Y.Yi,S.Lee,W.Su,M.Gerla, On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks, <draft-ietf-manet-odmrp-04.txt>, IETF MANET, luty

97 [28] J. Xie, R. Talpade, A. McAuley, M. Liu, AMRoute: Ad Hoc Multicast Routing Protocol, Kluwer Academic Publishers, lipiec [29] E.Bommaiah, A.McAuley, R.Talpade, M.Liu, AMRoute: Ad Hoc Multicast Routing Protocol, <draft-talpade-manet-amroute-00.txt>, IETF MANET, sierpień [30] R.Talpade, E.Bommaiah, A.McAuley, M.Liu, AMRoute: Ad Hoc Multicast Routing Protocol, 98aug/sld011.htm, sierpień [31] D. Johnson, D. Maltz, and Y. Hu, The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4, RFC4728, IETF MANET, luty [32] Gafni, E., Bertsekas, D.; Distributed algorithms for generating loop-free routes in networks with frequently changing topology, IEEE Transactions on Communications, styczeń 1981, Vol. 29. No. 1, pages [33] C.-K. Toh, Long-lived Ad Hoc Routing based on the Concept of Associativity, IETF MANET Working Group, marzec [34] Z.J.Haas, M.R.Pearlman, P.Samar, The Zone Routing Protocol (ZRP) for Ad Hoc Networks, <draft-ietf-manet-zone-zrp-04.txt>, Internet Draft, czerwiec [35] M.Gerla, X.Hong, G.Pei, Fisheye State Routing Protocol (FSR) for Ad Hoc Networks,<draft-ietf-manet-fsr-03.txt>, IETF MANET Internet Draft, czerwiec [36] P.Jacquet, P.Mühlethaler, T.Clausen, A.Laouiti, A.Qayyum, L.Viennot, Optimized link state routing protocol for ad hoc networks, IEEE INMIC, Pakistan, [37] R.V. Boppanam and S.P. Konduru, An Adaptive Distance Vector Routing Algorithm for Mobile Ad Hoc Networks, Proceedings of IEEE INFOCOM 2001, Anchorage, AK, kwiecień 22 26, Vol. 3, 2001, pp [38] P. Sinha, R. Sivakumar, V. Bharghavan, Core Extraction Distributed Ad Hoc Routing (CEDAR) Specification, Internet Draft <draft-ietf-manet-cedar-spec-00.txt>, wrzesień [39] Y.-B. Ko, N.H. Vaidya, Location-Aided Routing (LAR) in mobile ad hoc networks, ACM/IEEE MobiCom 98, Dallas, [40] [41] Scalable Network Technologies, Inc., QualNet 4.0 User s Guide, styczeń [42] S. Corson, J.Macker, Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations, RFC 2501, IETF, Styczeń

98 Dodatek A. Zawartość nośnika CD. Praca magisterska tekst pracy w dwóch wersjach: plik DOC (katalog PracaMagisterska\DOC plik PDF (katalog PracaMagisterska\PDF) Materiały Elektroniczne materiały elektroniczne, z których korzystano w tej pracy (katalog Materiały Elektroniczne) Rysunki wykorzystane w pracy rysunki wykorzystane w tej pracy (katalog Rysunki) Symulator QualNet instalacja symulatora (Symulator\Instalacja) dokumentacja (Symulator\Dokumentacja) Symulacje przeprowadzone symulacje, wraz z plikami konfiguracyjnymi, wynikami symulacji i arkuszem styli z obliczeniami (katalog Symulacje) 98

99 Dodatek B. Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl, za pomocą witryny 99

100 100

101 101

102 102

103 103

104 104