B ilustracja dzia ł ania sieci typu mesh Wykorzystanie symulatora NS-3 w dydaktyce -

(1)

Streszczenie—W artykule zostały przedstawione wyniki prze-prowadzonych badań mających na celu rozpoznanie możliwości, jakie dają symulacje wykonywane przy pomocy symulatora sieci NS-3 w ilustracji działania różnych sieci telekomunikacyjnych omawianych na zajęciach ze studentami. Przy czym tutaj skon-centrowano się na przykładach symulacji ruchu w sieciach kra-towych (tj. typu MESH). Szczegółowo przeanalizowano wyniki symulacji trzech przykładowych, prostych sieci kratowych, obja-śniając na ich podstawie funkcjonowanie protokołów komunika-cyjnych w tych sieciach. Na koniec przedstawiono propozycję studenckiego ćwiczenia laboratoryjnego dotyczącego sieci MESH, bazującego na symulacjach z wykorzystaniem symulatora NS-3.

Słowa kluczowe - sieci kratowe, sieci mesh, symulator NS-3

I. WSTĘP

EZPRZEWODOWE sieci kratowe (ang. mesh networks,

MESH) to technologia umożliwiająca budowę sieci

kom-puterowych w oparciu o samoorganizujące się urządzenia mobilne [1]. Do obsługi sieci kratowych zaprojektowano de-dykowane protokoły, ponieważ klasyczne protokoły komuni-kacyjne stosowane w sieciach kablowych nie sprawdzają się w takich strukturach. Tematyka sieci MESH zawarta jest w programie studiów inżynierskich na kierunku Informatyka. W niniejszym artykule zaprezentowano ćwiczenia umożliwia-jące symulację działania sieci MESH podczas zajęć laborato-ryjnych. W tym celu wykorzystano symulator NS-3. Wszyst-kie skrypty zostały omówione i przetestowane w ramach reali-zacji pracy dyplomowej [2]. W pracach inżynierskich w PWSZ w Elblągu symulator NS-3 został wykorzystany również do symulacji innych typów technologii i zagadnień z dziedziny sieci IP ([3], [4], [5]). Opierając się na symula-cjach za pomocą symulatora NS-3, można opracować wiele ciekawych studenckich ćwiczeń laboratoryjnych do laborato-rium z sieci teleinformatycznych.

Instalacja symulatora NS-3 (a także jego poprzednika NS-2) na komputerze pracującym pod systemem operacyjnym Windows (np. NT, XP, czy 2000) nie jest banalna i oczywi-sta. Środowisko instalacyjne NS-3 jest wieloelementowe i złożone, każdy szczegół jest istotny i jego wdrożenie może sprawić wiele kłopotów. Proces jego instalacji został

szczegó-P. Kurylak jest absolwentem Instytutu Informatyki Stosowanej Państwo-wej Wyższej Szkoły ZawodoPaństwo-wej w Elblągu, ul. Wojska Polskiego 1, 82-300 Elbląg (email: pkurylak@wp.pl).

K. Wasielewska i A. Borys są pracownikami Instytutu Informatyki Stoso-wanej Państwowej Wyższej Szkoły Zawodowej w Elblągu, ul. Wojska Pol-skiego 1, 82-300 Elbląg (email: k.wasielewska@pwsz.elblag.pl).

łowo opisany w pracy dyplomowej jednego ze współautorów tego artykułu [2].

W rozdziale II zaprezentowano podstawowe architektury, w których pracują sieci typu MESH oraz omówiono sposób realizacji procesów routingu. W rozdziale III zaprezentowano przykładowe scenariusze symulacyjne. Scenariusz prostego ćwiczenia laboratoryjnego omówiono w rozdziale IV, a podsumowanie zawarto w rozdziale V.

II. SIECI TYPU MESH

Poniżej omówiono architektury, protokoły komunikacyjne oraz inne zagadnienia i problemy występujące w sieciach typu MESH, które mogą być przedmiotem eksperymentów symula-cyjnych z wykorzystaniem symulatora NS-3.

A. Architektury sieci MESH

W sieciach kratowych wyróżnia się trzy typy architektur [1]: - hierarchiczną, w której urządzenia łączone są w grupy zwane klastrami. W klastrach zaś można wyróżnić trzy rodzaje urzą-dzeń [1]:

1. główne (ang. cluster-head nodes) - wybierane na podstawie kilku statystyk, takich jak np. siła nadawania, mobilność. Spełniają one podobne zadania jak punkty dostępowe, tzn. każde urządzenie w danym klastrze może połączyć się ze swoim urządzeniem głównym;

2. bramy (ang. gateway nodes) - zapewniają połączenia po-między klastrami; mogą łączyć się równocześnie z kilkoma urządzeniami głównymi, dzięki czemu istnieje kilka możli-wych ścieżek do danej bramy;

3. członkowskie (ang. cluster-member nodes) – są to podsta-wowe urządzenia w klastrze. Pakiet przesyłany z jednego klastra do drugiego musi przebyć drogę z urządzenia człon-kowskiego do urządzenia głównego, które przesyła go dalej do bramy. Brama zaś przesyła pakiet do następnego urzą-dzenia głównego, i tak dalej, aż dotrze on do urząurzą-dzenia członkowskiego w klastrze docelowym.

- płaską – nazywana jest tak ze względu na brak jakiegokol-wiek grupowania w niej urządzeń; wszystkie składające się na nią urządzenia spełniają te same funkcje, tzn. spełniają funkcje samokonfigurujących się routerów i jednocześnie są urządze-niami końcowymi. Połączenia w tej sieci są nawiązywane pomiędzy urządzeniami znajdującymi się na tyle blisko, aby zapewnić łączność. Pakiety przesyłane są z jednego urządze-nia do drugiego, aż dotrą do urządzeurządze-nia docelowego.

- hybrydową – stanowi ona połączenie dwóch poprzednich.

Wykorzystanie symulatora NS-3 w dydaktyce

- ilustracja działania sieci typu mesh

Przemysław Kurylak, Katarzyna Wasielewska, Andrzej Borys

(2)

B. Routing w sieciach MESH

Opracowanie sprawnych algorytmów routingu dla sieci kra-towych zawsze sprawiało kłopoty. Powody występowania problemów z poprawnym działaniem protokołów komunika-cyjnych implementowanych w sieciach typu MESH są nastę-pujące [1]:

Częste zmiany topologii sieci – sieci kratowe w porównaniu z innymi sieciami podlegają częstszym i bardziej radykalnym zmianom topologii; można zatem powiedzieć, że zachowują się bardziej dynamiczne. W związku z tym wymagają użycia protokołów komunikacyjnych wykrywających wszelkie zmia-ny w topologii w jak najkrótszym czasie - dzięki temu zapew-nia się w nich szybkie wyznaczenie nowej trasy oraz zacho-wanie nawiązanych sesji lub uniknięcie zbyt dużej utraty na-dawanych pakietów.

Brak gwarancji, że dany pakiet zostanie dostarczony do miejsca docelowego.

Połączenia mogą okazać się jednokierunkowe, tzn. stacja A może nawiązać połączenie z stacją B, ale stacja B nie może nawiązać połączenia ze stacją A. Jest to szczególnie kłopotli-we przy sesjach wymagających potwierdzenia odbioru.

Techniczne ograniczenia urządzeń – głównie ograniczona moc baterii, ograniczona szerokość pasma nadawczego, wolny zegar CPU.

Opracowano wiele protokołów routingu przeznaczonych dla sieci typu MESH. Można je podzielić na następujące kate-gorie [1]:

¾ Protokoły routingu oparte o topologię – w tym przypadku wyróżnia się ich trzy rodzaje:

Protokoły proaktywne (tabelkowe) – wykorzystuje się w nich tzw. tabele routingu. Polega to na tym, że każdy węzeł w sieci aktualizuje w sposób ciągły swój stan i określa możli-we drogi dla pakietów. Zatem w momencie, w którym ma przekazać dany pakiet dalej, nie traci czasu na wyliczanie dla niego drogi – te dane ma już gotowe. W protokołach proak-tywnych ww. tabele są tworzone za pomocą algorytmów stanu łącza lub algorytmów wektora odległości. Takie podejście do operacji routingu jest dobrze znane w klasycznych sieciach przewodowych. Jednakże w sieciach kratowych znajdowanie ścieżek w powyższy sposób ma wiele wad. Dwie największe to: duży pobór energii oraz, ze względu na dużą dynamikę sieci, generowanie sztucznego ruchu przy ciągłych aktualiza-cjach tabel routingu. j

Protokoły reaktywne (na żądanie) – w tych protokołach zrezygnowano z tworzenia tabel routingu. Zamiast tego droga, którą ma być przekazany pakiet, jest określana w momencie, gdy pojawia się taka potrzeba. Urządzenie mające pakiet do wysłania najpierw wysyła zapytanie do wszystkich urządzeń, z którymi jest połączone, one przekazują je w identyczny sposób dalej, aż do momentu dotarcia pakietu do urządzenia docelowego. Urządzenie docelowe wysyła odpowiedź, która wraca do urządzenia nadawczego. Urządzenie docelowe może otrzymać zapytanie z kilku możliwych tras i tymi samymi trasami może na nie odpowiedzieć. Urządzenie nadawcze wybiera najlepszą trasę, po czym wysyła pakiet. Jeżeli w trak-cie wysyłania połączenie zostanie zerwane, urządzenie na-dawcze wybiera następną trasę. Po przesłaniu pakietu infor-macje o ścieżce zostają usunięte. Protokoły działające na tej zasadzie są wykorzystywane głównie w dużych sieciach

kra-towych. Główną wadą tego typu protokołów jest duże opóź-nienie przy tworzeniu trasy z urządzenia nadawczego do doce-lowego.

Protokoły hybrydowe – w tym przypadku w różnym stopniu i w zależności od potrzeb łączone są protokoły proaktywne i reaktywne [1].

¾ Protokoły routingu oparte o wyznaczone położenie geo-graficzne urządzeń. Pozycję geograficzną urządzeń moż-na ustalić za pomocą:

Systemu GPS – główną wadą urządzeń z nadajnikami GPS jest duży pobór mocy, przez co wymagają częstszych wymian baterii.

Siły sygnału – jak wiadomo, im bardziej oddalony jest na-dajnik, tym słabszy odebrany od niego sygnał. Pomimo dość dużych błędów pomiarowych w tej metodzie, jest to najtańszy sposób ustalania pozycji urządzeń.

Czasu przybycia – w tym przypadku protokoły dokonują estymacji odległości od urządzenia na podstawie pomierzone-go czasu transmisji sygnału, uwzględniającepomierzone-go opóźnienie propagacyjne.

Kąta przybycia – korzystając z tej wielkości nie da się usta-lić dokładnej pozycji urządzenia, ale dostarcza ona informacji o kierunku, z którego dochodzi sygnał.

III. PRZYKŁADOWE SCENARIUSZE SYMULACJI SIECI MESH

I ICH ANALIZA

NS-3 jest symulatorem sieci stworzonym do prowadzenia prac badawczych oraz dla celów edukacyjnych z zakresu tele-informatyki w szkołach wyższych. Jest to oprogramowanie na licencji GNU GPLv2 i wymaga podstawowej znajomości dwóch języków programowania: C++ oraz PYTHON.

A. Kompilacja oraz uruchamianie skryptów

Gotowe skrypty można kompilować oraz uruchamiać za pomocą dowolnego kompilatora. Jednak, aby uniknąć niepo-trzebnych komplikacji, zaleca się używanie kompilatora do-starczonego razem z symulatorem. Wszystkie nowe skrypty najlepiej kopiować do folderu ../ns-3-dev/scratch. Do kompi-lacji oraz wykrycia ewentualnych błędów składniowych nale-ży unale-żywać komendy ./waf, podczas gdy skompilowane programy należy uruchamiać za pomocą komendy ./waf – run nazwa_skryptu. Jeżeli w skrypcie przewidziano możliwość podawania nowych wartości parametrów, to robi się to za pomocą komendy:

./waf –run ''nazwa_skryptu -parametr = wartość” .

B. Uruchamianie skryptów i analiza wyników

Skrypty wykorzystane do symulacji przedstawionych w tym podrozdziale są gotowymi skryptami załączonymi do pakietu symulatora NS-3; tutaj zostały one jednakże dostosowane do naszych scenariuszy symulacyjnych. Ich kody są podane w katalogu ns 3- dev/src [4]. Nazwy skryptów zostały przez nas zmienione. Powodem tego jest fakt, że jeżeli skrypt przy-kładowy oraz skrypt znajdujący się w folderze „scratch” mają identyczną nazwę, to w takim przypadku zostaje uruchomiony skrypt przykładowy, a nie ten zmodyfikowany. Zdecydowano się użyć gotowych skryptów z kilku powodów:

(3)

Skrypty te są napisane w jak najprostszy oraz jak najbar-dziej przejrzysty sposób, dzięki czemu są idealne do nauki oraz analizy wygenerowanego w nich ruchu.

Przykładowe skrypty dołączane razem z symulatorem są aktualizowane razem z nim, dzięki czemu nie traci się czasu na aktualizację samemu tych skryptów do najnowszych biblio-tek NS-3.

Powyższe skrypty często służą jako baza i wzór do pisania bardziej skomplikowanych.

Wszystkie ww. skrypty generują pliki z rozszerzeniem .pcap, a tego rodzaju pliki bardzo dobrze dają się analizować przy pomocy oprogramowania ogólnodostępnego pod nazwą Wireshark [5].

W jednym z ww. skryptów symulowana jest sieć kratowa oparta na protokole HWMP (ang. Hybrid Wireless Mesh

Pro-tocol), podczas gdy dwa pozostałe wykorzystują protokoły

OLSR (ang. Optimized Link State Routing Protocol) oraz AODV (ang. Ad hoc On-Demand Distance Vector). Pomimo iż te dwa ostatnie skrypty de facto nie symulują sieci krato-wych, to za ich pomocą można doskonale prześledzić sposób działania protokołów, które są również wykorzystywane w sieciach typu MESH.

Wyżej wymienione protokoły należą do różnych rodzajów protokołów routingu opartych o topologię (opisanych w punkcie 2.2 powyżej).

Wszystkie skrypty posiadają licencję GNU.

B.1. Skrypt mesh1.cc

Skrypt mesh1.cc służy do symulacji sieci kratowych; wyko-rzystuje się w nim protokół komunikacyjny HWMP, który zgodnie ze standardem IEEE 802.11s jest głównym protoko-łem sieci typu MESH. Należy on do grupy hybrydowych pro-tokołów routingu opartych o topologię; bazuje na protokole AODV. W tym protokole każde urządzenie śledzi urządzenia sąsiadujące i na tej podstawie aktualizuje tablice routingu. W sieciach opartych na protokole HWMP nie występują adre-sy IP, do routingu wykorzystywane są adreadre-sy MAC.

Rys. 1. Topologia sieci w skrypcie mesh1.cc

Topologię sieci kratowej zapisaną w skrypcie mesh1.cc przed-stawia rys. 1. W omawianym tutaj przykładzie symulacji z wykorzystaniem tego skryptu z urządzenia nr 1 (U1) za pomocą UDP ping nawiązano połączenie z urządzeniem nr 9 (U9). Przetwarzając otrzymane pliki .pcap uzyskano zamiesz-czone poniżej tabele 1 i 2 oraz wykresy przedstawione na rys. 2 i 3. Ze względu na ograniczone miejsce tabele zostały umieszczone tylko częściowo.

Analiza danych zawartych w tabelach 1 i 2, wykresów z rys. 2 i 3 oraz dziennika aktywności w programie Wireshark pozwala stwierdzić, że:

Największy ruch jest generowany na samym początku pracy skryptu.

TABELA I

LICZBA PAKIETÓW PRZESYŁANYCH PRZEZ URZĄDZENIA

Czas U1 U2 U3 U4 U5 U6 U7 U8 U9 0.0 38 49 39 56 70 50 42 51 38 0.1 0 0 0 0 0 0 0 0 0 0.2 0 0 0 0 0 0 0 0 0 0.3 0 0 0 0 0 0 0 0 0 0.4 0 0 0 0 0 0 0 0 0 0.5 3 4 3 4 5 4 3 4 3

Rys. 2. Liczba pakietów przesyłanych przez urządzenia TABELA II

Czas U1 U2 U3 U4 U5 U6 U7 U8 U9 0.0 1971 2512 2053 3016 3462 2518 2294 2590 1950 0.1 0 0 0 0 0 0 0 0 0 0.2 0 0 0 0 0 0 0 0 0 0.3 0 0 0 0 0 0 0 0 0 0.4 0 0 0 0 0 0 0 0 0 0.5 220 295 220 295 380 295 220 295 220

Rys. 3. Liczba pakietów przesyłanych przez urządzenia

Na większości urządzeń występują dodatkowe transmisje danych, każde urządzenie wysyła ramkę zwaną beacon frame. Ramki beacon frame odbierane są przez wszystkie sąsiadujące z nadawcą urządzenia. Mają one na celu informowanie pobli-skich urządzeń o obecności urządzenia nadawcy w sieci. Jeżeli urządzenie nie informuje o swojej obecności, pobliskie urzą-dzenia wyrzucają je ze swojej tablicy routingu oraz szukają innego urządzenia sąsiadującego bezpośrednio z nimi.

(4)

Największy przepływ danych jest widoczny na urządzeniu nr 5. Spowodowane jest to tym, iż komunikuje się ono z więk-szą liczbą urządzeń niż pozostałe.

Zaobserwowany „systematyczny” ruch, to pakiety ICMP oraz odpowiedzi na nie z urządzenia nr 9.

Połączenie między urządzeniem nr 1 a urządzeniem nr 9 jest realizowane za pośrednictwem kilku różnych tras.

B.2. Skrypt aodv1.cc

Skrypt aodv1.cc służy do symulacji prostej sieci bezprze-wodowej; wykorzystuje się w nim protokół komunikacyjny AODV. Protokół AODV należy do reaktywnych protokołów routingu opartych o topologię. Jak wskazuje nazwa, należy on do grupy protokołów opartych o Ad hoc oraz do grupy wyko-rzystującej wektor odległości do ustalenia trasy. AODV nie utrzymuje tablicy routingu, ustala trasę pomiędzy urządzenia-mi dopiero wtedy, gdy zachodzi taka potrzeba.

Rys. 4. Topologia sieci w skrypcie aodv.cc

Topologię sieci zapisaną w skrypcie aodv1.cc przedstawia rys. 4. W omawianym przykładzie z urządzenia nr 1 (U1) za pomocą komendy ping nawiązano połączenie z urządzeniem nr 4 (U4). Przetwarzając otrzymane pliki .pcap uzyskano za-mieszczone poniżej tabele 3 i 4, wykresy przedstawione na rys. 5 i 6 oraz dziennik aktywności.

TABELA III

Czas U1 U2 U3 U4 Czas U1 U2 U3 U4 0.0 37 61 60 36 4.6 0 0 0 0 0.1 0 0 0 0 4.7 0 0 0 0 0.2 0 0 0 0 4.8 0 0 0 0 0.3 0 0 0 0 4.9 1 2 0 0 0.4 0 0 0 0 5.0 3 2 1 1

Po zakończeniu działania przez skrypt zostaje wyświetlony komunikat:

Creating 4 nodes 100 m apart. Starting simulation for 10 s ... PING 10.0.0.4 56(84) bytes of data.

64 bytes from 10.0.0.4: icmp_seq=0 ttl=62 time=7 ms 64 bytes from 10.0.0.4: icmp_seq=1 ttl=62 time=2 ms

64 bytes from 10.0.0.4: icmp_seq=2 ttl=62 time=2 ms 64 bytes from 10.0.0.4: icmp_seq=3 ttl=62 time=2 ms --- 10.0.0.4 ping statistics ---

10 packets transmitted, 4 received, 60% packet loss, time 9999ms

rtt min/avg/max/mdev = 2/3.25/7/2.5 ms TABELA IV

Czas U1 U2 U3 U4 Czas U1 U2 U3 U4 0.0 1536 2528 2516 1524 4.6 0 0 0 0 0.1 0 0 0 0 4.7 0 0 0 0 0.2 0 0 0 0 4.8 0 0 0 0 0.3 0 0 0 0 4.9 88 176 0 0 0.4 0 0 0 0 5.0 256 168 84 84

Analiza danych zawartych w tabelach 3 i 4, wykresów z rys. 5 i 6, dziennika aktywności oraz powyższego komunikatu pozwala stwierdzić, że:

Zgodnie z specyfikacją działania protokołu AODV, wy-szukuje on trasy jedynie, gdy jest to potrzebne. W przypadku powyższego przykładu następuje to zaraz po rozpoczęciu działania skryptu, powodując tym samym większy ruch w sieci.

Przez brak aktualizacji i ciągłego utrzymywania tablicy routingu w czwartej sekundzie doszło do zerwania połączenia, przez co 60% pakietów zostało utraconych.

W powyższym przykładzie doskonale widać problem wy-stępujący w reaktywnych protokołach routingu opartych o topologię. W przykładzie zostały użyte jedynie cztery urzą-dzenia z prostą trasą między nimi i problem się ujawnił. W sieciach kratowych można spotkać setki urządzeń, które w dowolnym momencie mogą zostać wyłączone lub zniknąć z innych powodów. Bez tablicy routingu, która jest na bieżąco monitorowana oraz uaktualniana, bardzo często dochodzi do utraty pakietów. Jest to jeden z głównych powodów wypiera-nia protokołu AODV i zastępowawypiera-nia go protokołem HWMP.

B.3. Skrypt olsr-hna1.cc

Skrypt olsr-hna1.cc służy do symulacji prostej sieci bez-przewodowej; wykorzystuje się w nim protokół komunikacyj-ny OLSR. Należy on do proaktywkomunikacyj-nych protokołów routingu opartych o topologię. Protokół OLSR tworzy swoją tablicę routingu na odległość dwóch urządzeń od urządzenia tworzą-cego tabelę, zalewając regularnie sieć pakietami sprawdzają-cymi.

(5)

Rys. 7. Topologia sieci w skrypcie olsr-hna1.cc

Topologię sieci zapisaną w skrypcie olsr-hna1.cc przedsta-wia rys. 7. W omaprzedsta-wianym przykładzie z urządzenia nr 1 do urządzenia nr 3 zostaje wysłany pakiet UDP. Aby do tego doszło, najpierw urządzenie nr 1 musi otrzymać wiadomość HNA. Jeżeli urządzenie nr 1 nie otrzyma wiadomości HNA, pakiet nie będzie mógł dotrzeć do odbiorcy. Aby to zasymu-lować, należy uruchomić skrypt z wybranym parametrem:

./waf --run "olsr-hna --assocMethod1=1" ./waf --run "olsr-hna –assocMethod2=1"

lub w kodzie skryptu zmienić wartość któregoś z powyższych z false na true (oba parametry są ustawione domyślnie na false). Oba parametry generują identyczne wyniki, dlatego nie ma znaczenia, który z nich zostanie użyty do omówienia przy-kładu. Do komunikacji pomiędzy urządzeniem nr 1 a urządze-niem nr 2 używany jest protokół OLSR, jednak nie jest on używany do komunikacji pomiędzy urządzeniem nr 2 a urządzeniem nr 3. Przetwarzając otrzymane pliki .pcap uzy-skano zamieszczone poniżej tabele (od tab. 5 do tab. 9), wy-kresy (od rys. 8 do rys. 11) oraz dziennik aktywności.

TABELA V

Czas U1 U2 I1 Czas U1 U2 I1 Czas U1 U2 I1

0.0 2 2 6.0 0 0 12.0 1 1

0.1 0 0 6.1 1 1 12.1 0 0

0.2 0 0 6.2 0 0 12.2 0 0

0.3 0 0 6.3 0 0 12.3 0 0

Rys. 8. Liczba pakietów przesyłanych przez urządzenia TABELA VI

Czas U1 U2 I1 Czas U1 U2 I1 Czas U1 U2 I1 0.0 214 214 6.0 0 0 12.0 114 116 0.1 0 0 6.1 114 116 12.1 0 0 0.2 0 0 6.2 0 0 12.2 0 0

Analiza danych zawartych w tabelach od 5 do 9, wykresów z rys. od 9 do 11 oraz dziennika aktywności pozwala stwierdzić, że:

W przypadku uruchomienia skryptu bez parametru jedyny ruch jest generowany przez protokół OLSR, który poprzez zalewanie sieci pakietami uaktualnia swoją tablicę routingu.

W przypadku uruchomienia skryptu bez parametru nie zostaje wysłana wiadomość HNA, przez co niemożliwe jest przekazanie pakietu UDP na urządzenie nr 3.

Rys. 9. Liczba pakietów przesyłanych przez urządzenia TABELA VII

Rys. 10. Liczba pakietów przesyłanych przez urządzenia TABELA VIII

Czas U2 I2 U3 0.000 1 2 0.001 0 0 0.002 0 0 0.003 0 0 0.004 2 0 0.005 0 1

W przypadku uruchomienia skryptu z parametrem w czternastej sekundzie rozpoczyna się przekazywanie pakietu na urządzenie nr 3.

W przypadku uruchomienia skryptu z parametrem obie podsieci zostały przeanalizowane w osobnych tabelach, wy-kresach oraz dzienniku aktywności, ponieważ podsieć nr 2 pomiędzy urządzeniem nr 2 a urządzeniem nr 3 generuje plik

(6)

.pcap nie od chwili rozpoczęcia pracy skryptu ale od chwili wystąpienia ruchu w danej podsieci. Tym samym przedstawia-jąc obie podsieci w jednej tabeli, na jednym wykresie lub dzienniku aktywności otrzymalibyśmy mylne i błędne wyniki.

W powyższym przykładzie można zauważyć również główną wadę proaktywnych protokołów routingu opartych o topologię, a mianowicie generowanie olbrzymiego ruchu służącego jedynie do utrzymania tabeli routingu. Powoduje to większy pobór mocy z urządzeń, dlatego nie zaleca się używać tego typu protokołów na urządzeniach ze słabym źródłem zasilania.

Rys. 11. Liczba pakietów przesyłanych przez urządzenia TABELA IX

IV. ĆWICZENIE LABORATORYJNE

Aby sprawnie przeprowadzić ćwiczenia, na każdym kom-puterze powinien być już zainstalowany symulator NS-3 oraz oprogramowanie wspomagające (Wireshark). Przed rozpoczę-ciem eksperymentów należy zastanowić się nad wyborem parametrów, z którymi skrypt zostanie uruchomiony. Podsta-wowym parametrem, na który trzeba zwrócić uwagę, jest parametr generujący pliki .pcap. Pomimo, iż w większości skryptów jest on domyślnie ustawiony na „true”, można spo-tkać skrypty, które zapis aktywności generują do innych for-matów, uniemożliwiając tym samym analizę ruchu w progra-mie Wireshark. Kolejnym ważnym parametrem jest czas trwania symulacji. Skrócenie czasu może pomóc w analizie danego przykładu, jednak należy pamiętać, iż jeżeli symulacja będzie trwała za krótko, może ona nie być w stanie wykonać założonych czynności. W przedstawionych w artykule skryp-tach można zmienić jeszcze inne parametry, np. wielkość wysyłanych pakietów, odstęp czasowy pomiędzy kolejnymi pakietami. Niedoświadczonym użytkownikom zaleca się po-zostawienie wartości domyślnych tych parametrów. Autorzy przykładowych skryptów załączonych do symulatora NS-3, starają się ustawić domyślne parametry w taki sposób, aby nie

wydłużać niepotrzebnie czasu symulacji i zapewnić odpo-wiedni materiał do badań.

Dzięki symulatorowi NS-3 oraz dostępnym w programie Wireshark narzędziom statystycznym, takim jak IO Graphs lub Flow Graph, można doskonale przeanalizować oraz przedstawić sposób, w jaki działają sieci kratowe oraz pro-tokoły w nich operujące.

Przykładowy przebieg prostego ćwiczenia: 1. Omówienie teorii sieci kratowych.

2. Uruchomienie przykładowych skryptów z parametrami domyślnymi (podział studentów na 3 grupy):

- grupa 1 – skrypt mesh1.cc, - grupa 2 – skrypt aodv1.cc, - grupa 3 – skrypt olsr-hna1.cc.

3. Analiza otrzymanych plików w programie Wireshark: - weryfikacja wyników za pomocą IO Graphs,

- stworzenie dziennika aktywności za pomocą Flow Graph. 4. Omówienie wyników, wyciagnięcie wniosków oraz

sporządzenie sprawozdań z ćwiczeń.

Należy pamiętać, że pliki .pcap generowane są dla każdego urządzenia, a nie dla całej sieci. Aby móc stworzyć dziennik aktywności dla całej sieci, i tym samym lepiej zobrazować ruch w niej występujący, należy najpierw scalić pliki .pcap opcją „merge”. Trzeba jednak uważać, ponieważ pliki .pcap mogą rozpocząć zapis od momentu, w którym nastąpi ruch w danym urządzeniu, co może prowadzić do przekłamań w trakcie scalania. Przykładem jest skrypt olsr-hna1.cc, w którym ruch w drugiej podsieci liczony jest od 0s, podczas gdy w rzeczywistości jest to 14s od rozpoczęcia skryptu.

V. PODSUMOWANIE

Celem niniejszego artykułu było wprowadzenie i zaprezentowanie możliwości użycia symulatora NS-3 do analizy działania sieci kratowych oraz stosowanych w nich protokołów. Dzięki programom wspomagającym moni-torowanie i analizę ruchu sieciowego generowane przez symulator wyniki można przedstawić w sposób jasny oraz przejrzysty. Pomimo początkowych trudności, na jakie może napotkać użytkownik, symulator może okazać się bardzo pomocnym narzędziem, zarówno jako pomoc edukacyjna jak i narzędzie do testowania nowych projektow przed ich fizyczną implementacją.

LITERATURA

[1] G. Aggelou, Wireless Mesh Networking, New York: McGraw-Hill, 2009.

[2] P. Kurylak, „Analiza ruchu w sieciach typu mesh za pomocą symulatora NS-3”, Państwowa Wyższa Szkoła Zawodowa w Elblągu, praca inży-nierska, 2013.

[3] M. Alfut, „Porównanie działania protokołów interne-towych TCP i UDP w symulacjach za pomocą symulatora sieci NS-3”, Państwowa Wyższa Szkoła Zawodowa w Elblągu, praca inżynierska, 2012.

[4] M. Pikula, „Symulacja sieci LAN z użyciem symu-latora NS-3”, Pań-stwowa Wyższa Szkoła Zawodowa w Elblągu, praca inżynierska, 2013. [5] M. Mówiński, „Symulator NS-3 i jego wykorzystanie w analize ruchu

internetowego”, Państwowa Wyższa Szkoła Zawodowa w Elblągu, pra-ca inżynierska, 2013.

[6] „Debian”, http://www.debian.org/index.pl.html. [7] „The NS-3 Network Simulator.”, http://www.nsnam. org/. [8] „Wireshark. Go deep”, http://www.wireshark.org/.