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 116772

Łódź, grudzień 2007 r.

2

SPIS TREŚCI

Wykaz skrótów. ............................................................................................................ 3 Wykaz rysunków. ......................................................................................................... 4 Słownik pojęć. .............................................................................................................. 7

1. Wstęp. ....................................................................................................................... 9 2. Cel i zakres pracy.................................................................................................... 11 3. Wprowadzenie do multicastingu. ........................................................................... 13

3.1. Multicasting w sieciach kablowych................................................................14 3.2. Ogólna charakterystyka sieci ad hoc i multicastingu w tych sieciach............ 16

4. Rutowanie w sieciach bezprzewodowych ad hoc................................................... 18 4.1. Ruting unicastowy w sieciach MANET. ........................................................ 21

4.1.1. Protokoły proaktywne............................................................................. 22 4.1.2. Protokoły reaktywne. .............................................................................. 25

4.2. Ruting multicastowy w sieciach MANET. ..................................................... 31 4.2.1. Protokoły drzewo-strukturalne. .............................................................. 33 4.2.2. Protokoły siatko-strukturalne..................................................................37

5. Ruting multicastowy w sieciach mobilnych bezprzewodowych ad hoc................. 39 5.1. Protokoły reaktywne. ...................................................................................... 40

5.1.1. Multicast Ad Hoc On-Demand Distance Vector (MAODV). ................ 40 5.1.2. On-Demand Multicast Routing Protocol (ODMRP). ............................. 49

5.2. Protokoły proaktywne..................................................................................... 56 5.2.1. Ad hoc Multicast Routing Protocol (AMRoute)..................................... 56 5.2.2. Core-Assisted Mesh Protocol (Camp). ................................................... 64

5.3. Protokoły inteligentne – Multicast for Ad hoc Network with Swarm Intelligence(MANSI) – Ant-based.............................................................................. 68

6. Symulacje................................................................................................................ 80 6.1. Informacje wstępne......................................................................................... 80 6.2. Kryteria symulacji........................................................................................... 81 6.3. Szczegółowe parametry ustawień sieci........................................................... 82 6.4. Wyniki symulacji protokołu ODMRP. ........................................................... 84

6.4.1. Liczba nadawców. .................................................................................. 84 6.4.2. Mobilność. .............................................................................................. 87 6.4.3. Wielkość grupy multicastowej................................................................ 90

7. Podsumowanie. ....................................................................................................... 93 8. Bibliografia. ............................................................................................................ 95 Dodatek A. ...................................................................................................................... 98

Zawartość nośnika CD................................................................................................ 98 Dodatek B. ...................................................................................................................... 99

Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl ............... 99

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

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 8.

11. 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.

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.

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.

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

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]

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]

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ć.

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

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.

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]

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]

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

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ł

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]

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 multi-

hop. 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

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. 1-3-4-2 lub 1-5-2.[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]

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.

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]

22

4.1.1. 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]

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

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]

25

4.1.2. 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]

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]

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]

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

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]

30

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

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:

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.

33

4.2.1. 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

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.

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]

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]

37

4.2.2. 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 Routin g (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]

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]

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.

40

5.1. Protokoły reaktywne.

5.1.1. 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]

5.1.1.1. 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

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]

5.1.1.2. 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]

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]

5.1.1.3. Utworzenie ścieŜki przekazywania. (ang. Forward Path Setup)

Rys. 22 Utworzenie ścieŜki przekazywania. [25]

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]

5.1.1.4. 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.

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]

45

5.1.1.5. 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]

46

5.1.1.6. 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]

5.1.1.7. 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

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]

5.1.1.8. 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,

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]

5.1.1.9. 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]

49

5.1.2. 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]

5.1.2.1. 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]

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]

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]

52

Rys. 34 Nagłówek pakietu Join Reply.[27]

5.1.2.2. 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ół 802.11 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]

5.1.2.3. 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

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]

5.1.2.4. 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]

54

5.1.2.5. 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]

5.1.2.6. 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]

5.1.2.7. 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]

5.1.2.8. 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Ŝą

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]

56

5.2. Protokoły proaktywne.

5.2.1. 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]

5.2.1.1. 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]

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]

5.2.1.2. 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

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]

5.2.1.3. 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

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]

5.2.1.4. 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

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]

5.2.1.5. 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]

5.2.1.6. 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]

61

Rys. 40.Podział jednej siatki na kilka [30]

5.2.1.7. 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]

5.2.1.8. 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]

5.2.1.9. 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

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]

63

5.2.1.10. 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]

5.2.1.11. 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]

64

5.2.2. 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]

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. receiver-

initiated) 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ą

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]

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]

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

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]

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ą

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]

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]

5.3.1.1. 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 joing(i) Jest ona aktualizowana

kiedy węzeł „i” słyszy pakiety Join Request do siebie. KaŜdy wpis w joing(i) ma

formułę <r,hr>, gdzie r oznacza ID węzła proszącego o dołączenia, a hr 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 joing(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 coreg(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 seqNog(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]

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]

5.3.1.2. 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 coreg(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 coreg(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]

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]

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]

76

5.3.1.3. 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.

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]

5.3.1.4. 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]

78

5.3.1.5. 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]

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

80

6. Symulacje.

6.1. 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. 1.6.0_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.

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.

6.2. 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]

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.

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 10-50

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.

84

6.4. Wyniki symulacji protokołu ODMRP.

6.4.1. 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.

85

Dane dor ęczone/Dane które powinny by ć doręczone w sieci z 50 w ęzłami

00,20,40,60,8

11,2

1 5 10 15 20

Liczba nadawców

PD

R

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

00,5

11,5

22,5

33,5

4

1 5 10 15 20

Liczba nadawców

PT

R

ODMRP

Rys. 56. Packet Transmssion Ratio jako funkcja liczby nadawców pakietów.

86

Pakiety kontrolne/pakiety dor ęczone w sieci z 50 węzłami

0

0,05

0,10,15

0,2

0,25

0,3

1 5 10 15 20

Liczba nadawców

Pak

iety

ko

ntro

lne/

Pak

iety

do

ręcz

one

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

00,5

11,5

22,5

33,5

44,5

1 5 10 15 20

Liczba nadawców

Pak

iety

ko

ntro

lne+

Pak

iety

w

ysła

ne/P

akie

ty

dorę

czon

e

ODMRP

Rys. 58. Pakiety kontrolne wraz z danymi przez pakiety doręczone, jako funkcja liczby

nadawców pakietów.

87

6.4.2. 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.

88

Pakiety dor ęczone/Pakiety które powinny doj ść do celu w sieci z 50 w ęzłami

0

0,2

0,4

0,6

0,8

1

1 5 10 15 20

Prędko ść poruszania si ę [m/s]

PD

R

ODMRP

Rys. 59.Packet Delivery Ratio jako funkcja mobilności.

Dane wysłane/Dane dor ęczone w sieci z 50 węzłami

1,21,25

1,31,35

1,41,45

1,51,55

1,61,65

1 5 10 15 20

Prędko ść poruszania si ę [m/s]

PT

R

ODMRP

Rys. 60. Packet Transmission Ratio jako funkcja mobilności.

89

Pakiety kontrolne/pakiety dor ęczone w sieci z 50 węzłami

0

0,01

0,02

0,03

0,04

0,05

0,06

1 5 10 15 20

Prędko ść poruszania si ę [m/s]

Pak

iety

ko

ntro

lne/

Pak

iety

do

ręcz

one

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

1,251,3

1,351,4

1,451,5

1,551,6

1,651,7

1 5 10 15 20

Prędko ść poruszania si ę [m/s]

Pak

iety

ko

ntro

lne+

Pak

iety

w

ysła

ne/P

akie

ty

dorę

czon

e

ODMRP

Rys. 62. Pakiety kontrolne wraz z pakietami wysłanymi do pakietów doręczonych jako

funkcja mobilności.

90

6.4.3. 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.

91

Pakiety dor ęczone/Pakiety które powinno doj ść do celu w sieci z 50 w ęzłami

0,65

0,7

0,75

0,8

0,85

10 20 30 40 50

Ilość uczestników grupy

PD

R

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,1

1,2

1,3

1,4

1,5

1,6

10 20 30 40 50

Ilość uczestników grupy

PT

R

ODMRP

Rys. 64. Packet Transmission Ratio, jako funkcja liczby uczestników grupy

multicastowej.

92

Pakiety kontrolne/pakiety dor ęczone w sieci z 50 węzłami

0

0,02

0,04

0,06

0,08

0,1

10 20 30 40 50

Ilość uczestników grupy

Pak

iety

ko

ntro

lne/

Pak

iety

do

ręcz

one

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,2

1,3

1,4

1,5

1,6

1,7

10 20 30 40 50

Ilość uczestników grupy

Pak

iety

ko

ntro

lne+

Pak

iety

w

ysła

ne/P

akie

ty

dorę

czon

e

ODMRP

Rys. 66. Pakiety kontrolne oraz wysłane pakiety z danymi do pakietów doręczonych,

jako funkcja liczby uczestników grupy multicastowej.

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

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.

95

8. Bibliografia.

[1] P.Kuosmanen, “Classification of Ad Hoc Routing Protocols”, Finnish Defence

Forces Naval Academy, czerwiec 2002.

[2] J.Słoczyński, “Nietypowe algorytmy rutowania”, Politechnika Łódzka, Łódź,

wrzesień 2004.

[3] M.Ilyas, “The Handbook of Ad Hoc Wireless Networks”, Florida Atlantic

University, Florida, 2003.

[4] Dewan Tanvir Achmed, “Multicasting in Ad Hoc Networks”, University of Ottawa,

Ottawa, 2005.

[5] Y.Zhu, “Pro Active Connection Maintenance in AODV and MAODV by Yufang

Zhu”, Department of Systems and Computer Engineering, Carleton University, Ottawa,

wrzesień 2002.

[6] D.T.Ahmed, S.Shirmohammadi, “Architectural Analysis of Multicast Routing

Protocols for Wireless Ad Hoc Networks”, University of Ottawa, Ottawa, listopad 2006.

[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, 2007.

[8] „Mobilne sieci ad hoc w technologii Bluetooth”, AGH University Of Science,

www.ics.agh.edu.pl/papers/TR-02-4.doc.

[9] L.M. Feeney: “A Taxonomy for Routing Protocols in Mobile Ad Hoc Networks”,

SICS Technical Report T99/07, październik 1999.

[10] Perkins, C. E.; “IP mobility support”, RFC 2002, październik 1996,

http://www.ietf.org/rfc/rfc2002.txt.

[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ń 1994.

[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ń 1997.

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: 0792396979, 1996.

[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-seamobymobility-

terminology-06.txt>, luty 2004.

[19] Sinha, P., Sivakumar, R., Bharghavan, V., “MCEDAR: Multicast Core Extraction

Distributed Ad-hoc Routing”, IEEE Wireless Communications and Networking

Conference (WCNC ’99), 1999.

[20] Lin, C., Chao, S., “A Multicast Routing Protocol for Multihop Wireless Networks”,

IEEE Global Telecomm. Conference (GlobeCom 1999), 1999.

[21] J.J.Garcia-Luna-Aceves, E.L.Madruga, “The Core-Assisted Mesh Protocol”, IEEE

Journal on Selected Areas in Communications, 17, 1380–1394, kwiecień 1999.

[22] Lee, S., Gerla, M., Chiang, C., “On-Demand Multicast Routing Protocol”, IEEE

Wireless Communications and Networking Conference (WCNC ’99), 1999.

[23] C.Shen, C.Jakiaeo, “Ad hoc Multicast Routing Algorithm with Swarm

Intelligence”, University of Delaware, Newark, sierpień 2003.

[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. 46-55.

[25] E.Cheng, “On-Demand Multicast Routing in Mobile Ad Hoc Networks”, Carleton

University, Ottawa, styczeń 2001.

[26] E.M.Royer, “Multicast Ad Hoc On-Demand Distance Vector (MAODV) Routing”,

<draft-ietf-manet-maodv-00.txt>, IETF MANET Working Group, lipiec 2000.

[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 2003.

97

[28] J. Xie, R. Talpade, A. McAuley, M. Liu, “AMRoute: Ad Hoc Multicast Routing

Protocol”, Kluwer Academic Publishers, lipiec 2002.

[29] E.Bommaiah, A.McAuley, R.Talpade, M.Liu, “AMRoute: Ad Hoc Multicast

Routing Protocol”, <draft-talpade-manet-amroute-00.txt>, IETF MANET, sierpień

1998.

[30] R.Talpade, E.Bommaiah, A.McAuley, M.Liu, “AMRoute: Ad Hoc Multicast

Routing Protocol”, http://www3.ietf.org/proceedings/98aug/slides/manet-talpade-slides-

98aug/sld011.htm, sierpień 1998.

[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 2007.

[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 11--18.

[33] C.-K. Toh, “Long-lived Ad Hoc Routing based on the Concept of Associativity”,

IETF MANET Working Group, marzec 1999.

[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 2002.

[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 2002.

[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,

2001.

[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. 1753–1762.

[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ń 1998.

[39] Y.-B. Ko, N.H. Vaidya, “Location-Aided Routing (LAR) in mobile ad hoc

networks”, ACM/IEEE MobiCom 98, Dallas, 1998.

[40] http://en.wikipedia.org/wiki/Multicast.

[41] Scalable Network Technologies, Inc., “QualNet 4.0 User’s Guide”, styczeń 2007.

[42] S. Corson, J.Macker, “Mobile Ad hoc Networking (MANET): Routing Protocol

Performance Issues and Evaluation Considerations”, RFC 2501, IETF, Styczeń 1999.

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)

99

Dodatek B.

Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl,

za pomocą witryny http://www.plagiat.pl.

100

101

102

103

104