Przemysław KORZYŃSKI - student V roku Wojskowa Akademia Techniczna, Wydział Elektroniki, Instytut Telekomunikacji, ul. Gen. S. Kaliskiego 2, 00-908 Warszawa tel.: (+48)(22) 409 72 24, email: pkorzynski@poczta.fm Wstęp KONCEPCJA IMPLEMENTACJI PROTOKOŁU WRCP Z WYKORZYSTANIEM STEROWNIKA MADWIFI Rozwój sieci komputerowych opartych o bezprzewodowe media transmisyjne postępuje w bardzo szybkim tempie. Poszukiwane są nowe możliwości wykorzystania dostępnych pasm radiowych, opracowywane są coraz bardziej efektywne algorytmy modulacji, mające zwiększyć maksymalną przepustowość dostępną dla użytkownika, czy też opracowywane są nowe mechanizmy zapewnienia QoS (Quality of Service) i protokoły routingu, dzięki którym przepływ informacji będzie szybszy i bardziej niezawodny. W Instytucie Telekomunikacji Wydziału Elektroniki Wojskowej Akademii Technicznej zaproponowany został protokół routingu, który wykorzystuje metryki dotąd niewykorzystywane w sieciach WLAN (Wireless Local Area Network). Dzięki temu możliwe będzie sprostanie tym wymaganiom, które do tej pory pozostawały niespełnione. Protokół WRCP (Wireless Relay Control Protocol) został zaprezentowany na konferencji w Bonn [1]. Protokół WRCP został sprawdzony i przetestowany w środowisku symulacyjnym Omnet++, następstwem jest implementacja protokołu w środowisku sieci rzeczywistej. Z pomocą przychodzi tu oprogramowanie do kart sieci bezprzewodowych. Spośród wielu sterowników dostępnych na rynku oprogramowania wybrano sterownik MadWiFi. Jego zaletą jest, że jest to sterownik z otwartym kodem - open-source. Artykuł ten ma przedstawić koncepcję opracowania protokołu WRCP w ramach sterownika MadWiFi, a następnie zaimplementowanie go w MadWiFi. Umożliwiłoby to weryfikację poprawności działania protokołu WRCP w sieciach ad-hoc i potwierdzenie jego przydatności. 1. Analiza i przykłady wykorzystania protokołu WRCP Wielość protokołów routingu wykorzystywanych we współczesnych sieciach bezprzewodowych daje możliwość wyboru i zastosowania tego protokołu, który najlepiej będzie odpowiadał naszym potrzebom. Protokoły te wykorzystują do znajdowania ścieżek między stacjami różnorodne procedury i metryki [3]. Protokół WRCP pod względem działania i wykorzystywanych metryk odbiega od popularnych protokołów routingu. Jako metryki wykorzystuje one bowiem: Moc sygnału odbieranego z poszczególnych stacji (stosunek sygnał-szum, SNR). Stan naładowania baterii danej stacji. Informacje dotyczące połączenia stacji z punktem dostępowym AP (Access Point). Działanie samego protokołu można podzielić na dwie fazy: Wyszukiwanie stacji sąsiednich (Neighbor Discovery). Wybranie optymalnej ścieżki i przesłanie danych. Faza wyszukiwania stacji sąsiednich, podobnie jak w innych protokołach routingu, także w protokole WRCP odgrywa bardzo ważną rolę w poszukiwaniu ścieżki do węzła 1
docelowego. Omawiany protokół wymusza na stacjach mobilnych okresowe generowanie wiadomości żądania informacji o sąsiadach (Neighbor Request). Na podstawie informacji zawartych w odebranej wiadomości stacja uzupełnia własną tabelę, w której znajdują się informacje o stacjach sąsiednich. Następnie następuje generacja odpowiedzi (Neighbor Reply) do stacji, która wysłała wiadomość Neighbor Request. Aby uniknąć problemu kolizji, wysyłanie odpowiedzi następuje po losowo generowanym odcinku czasu (time-out). Po odebraniu wszystkich informacji stacje dzielone są na dwie grupy: stacje dostępne w jednym skoku (one-hop neighbours) oraz stacje dostępne przez stacje odległe o jeden skok (2-hop neighbour). Dodatkowo każdy wpis w tabelach opatrzony jest znacznikiem czasu, dzięki któremu nieodświeżane wpisy o ścieżkach są usuwane. Ważnym atutem protokołu WRCP jest możliwość komunikacji między stacjami z wykorzystaniem stacji pośredniej w przypadku, gdy stacja źródłowa i docelowa znajdują się poza zasięgiem. Osiągane jest to poprzez rozszerzenie funkcjonalności warstwy MAC. Taki sposób komunikacji jest wykorzystywany w rosnącej liczbie rozwiązań, o czym świadczą przykłady [4,5]. Projektowane są również aplikacje pozwalające zmniejszyć zapotrzebowanie urządzeń przenośnych na energię [6,7]. Rysunek 1.1. Przykłady zastosowania protokołu WRCP Przykłady zastosowań protokołu WRCP przedstawione są na rysunku 1.1. Stacja 1 może wymieniać wiadomości ze stacją 4 bezpośrednio. Stacja 5 znajduje się natomiast poza zasięgiem stacji 1. Do komunikacji z tą stacją wykorzystywany jest pośrednik stacja 4. Ta sama stacja umożliwia również stacji 1 dostęp do sieci Internet lub sieci WAN poprzez pośredniczenie w połączeniu z punktem dostępowym AP (Access Point). Należy w tym miejscu zaznaczyć, że protokół WRCP jest przeznaczony głównie do sieci typu Ad-hoc, a więc bez obecnej infrastruktury w postaci np. punktów dostępowych. Możliwa jest oczywiście sytuacja przedstawiona na rysunku 1.1, co dodatkowo poszerza możliwości funkcjonalne protokołu WRCP. 2. MadWifi jako podstawa implementacji protokołu WRCP MadWifi jest sterownikiem kart bezprzewodowych, które wykorzystują chipsety Atheros [8]. Sterownik ten został zaprojektowany do pracy w systemie operacyjnym Linux i rozwijany jest na zasadzie oprogramowania otwartego (Open Source). Oznacza to, że kod źródłowy tego programu (w 80%) jest powszechnie dostępny. Umożliwia to wprowadzanie do niego poprawek przez samych użytkowników oraz wprowadzanie własnych instrukcji o ile pozostaniemy w zgodzie ze standardem IEEE 802.11 [9]. Możliwość wprowadzenia własnych 2
instrukcji jest z naszego punktu widzenia bardzo interesująca chcemy bowiem zaimplementować i przetestować w środowisku rzeczywistym protokół WRCP. Program można podzielić na 4 główne części Stos protokołów 802.11 pobrany bezpośrednio z FreeBSD. Zawiera on wszystkie niezbędne funkcje potrzebne do komunikacji zgodnie ze standardem 802.11. Część ath. Definiuje odwołania do standardu 802.11 specyficzne dla chipsetów Atheros oraz sposoby dostępu do sprzętu poprzez About/HAL. About/HAL (Hardware Abstraction Layer). Przez tę część programu przechodzą wszystkie odwołania sterownika do zasobów sprzętowych. Niestety, ta część sterownika dostarczana jest tylko w postaci skompilowanej i użytkownicy nie posiadają dostępu do kodu źródłowego tej części. Algorytmy obliczeniowe, które służą do wybierania optymalnych parametrów transmisyjnych. Implementacja protokołu WRCP w sterowniku MadWifi stawia przed nami pewne wymagania, które muszą być spełnione dla pełnego i prawidłowego działania sterownika: Dodatkowe elementy (protokół WRCP) nie mogą powodować niestabilnej pracy sterownika i karty. Protokół WRCP powinien być przeźroczysty i dawać możliwość wyboru innych protokołów routingu. Nie może naruszać zasad narzuconych przez standard IEEE 802.11. Musi współpracować z chipsetami firmy Atheros. Implementacja musi być napisana w języku C w takim języku napisany jest cały sterownik. Na rysunku 2.1 przedstawiono strukturę sterownika MadWifi i propozycję umieszczenia w tej strukturze protokołu WRCP. Rysunek 2.1. Proponowane umiejscowienie protokołu WRCP w strukturze sterownika MadWifi Protokół WRCP powinien zostać wkomponowany w sterownik MadWifi tak, by nie zakłócać oryginalnie występujących elementów. Dlatego jest w tej samej części sterownika, co pozostałe protokoły. Jednocześnie wymagana jest wymiana informacji między protokołem WRCP i algorytmami obliczeniowymi. Wynika to z faktu, że algorytm WRCP do wyszukiwania optymalnej drogi wykorzystuje takie informacje, jak poziom baterii stacji sąsiednich i poziom sygnału od nich odbieranego. Protokół WRCP umiejscowiony jest w warstwie łącza danych. Na rysunku 2.2 przedstawiono umiejscowienie sterownika MadWifi na tle warstw modelu ISO. 3
Rysunek 2.2. Wymiana danych między sterownikiem MadWifi i warstwami modelu ISO Na rysunku 2.3 przedstawiono funkcje realizowane przez sterownik kart MadWifi. Rysunek 2.3. Funkcje realizowane przez sterownik MadWifi Funkcje przedstawione na rysunku 2.3 muszą występować w ściśle określonych momentach czasu, a kolejność wykonywania poszczególnych czynności przez sterownik przedstawiona została na rysunku 2.4 4
Rysunek 2.4. Graf stanów sterownika obsługi karty sieci bezprzewodowej Na podstawie przedstawionego grafu stanów można ułożyć przykładowy algorytm działania sterownika MadWifi. Jest to jeden z pierwszych etapów, jakie powinny być wykonane przy tworzeniu nowego oprogramowania lub ulepszaniu oprogramowania już istniejącego. Ułatwia to późniejsze pisanie kodu programu i umożliwia łatwiejsze śledzenie jego zmian. Propozycja algorytmu działania przedstawiona została na rysunku 2.5. Rysunek 2.5. Algorytm działania sterownika MadWifi 5
3. Koncepcja stanowiska do implementacji i badań protokołu WRCP Stanowisko do badań protokołu WRCP zostanie zrealizowane w oparciu o stacjonarne stacje robocze i komputery przenośne. Na stacjach zainstalowany zostanie system Linuks. Sterownik MadWifi, pobrany w postaci plików źródłowych [2], zostanie następnie uzupełniony protokołem WRPC. W celu przeprowadzenia sprawdzenia modułu protokołu WRPC, komputery będą musiały pracować w trybie ad-hoc i wymieniać między sobą określone dane. Szczegółowe badania dotyczące zależności czasowych w ramach realizowanych procedur, jak również opracowane w dalszej części pracy dyplomowej wskaźniki oceniające jakość opracowanych procedur pozwolą na sprawdzenie efektywności pracy protokołu WRPC i jego przydatności w rzeczywistych sieciach. Przykładowa konfiguracja środowiska badawczego przedstawiona została na rysunku 3.1 Umożliwia ona badanie właściwości protokołu WRPC pod względem odkrywania stacji sąsiednich, wyszukiwania zoptymalizowanych ścieżek do stacji docelowej, oraz testowania połączeń uzyskiwanych z wykorzystaniem stacji pośredniczących. Rysunek 3.1. Przykładowe środowisko badawcze dla protokołu WRPC 4. Podsumowanie Implementacja protokołu WRCP może przyczynić się do spojrzenia na problematykę routingu w sieciach ad-hoc z innej perspektywy. Ponieważ w urządzeniach przenośnych bardzo dużą wagę przykłada się do oszczędnego gospodarowania dostępną energią, protokół WRCP, w którym jako jeden z parametrów przy wyszukiwaniu drogi brany jest pod uwagę poziom naładowania baterii, może spotkać się z dużym zainteresowaniem ze strony użytkowników. W najbliższym czasie dokonana zostanie szczegółowa analiza programu sterownika MadWifi, a następnie określona zostanie jego podatność na implementację protokołu WRCP. Zaimplementowanie tego protokołu pozwoli na zbadanie jego skuteczności w warunkach rzeczywistych i przydatność w sieciach ad-hoc. Na implementacji protokołu WRCP oraz jego badaniach oparta będzie praca magisterska autora artykułu. 6
Bibliografia [1]. M.Bednarczyk, M.Amanowicz: Wireless Relay Control Protocol, Military Communications And Information Systems Conference, Bonn, wrzesień 2007r [2]. MadWifi - Multiband Atheros Driver for Wireless Fidelity, www.madwifi.org. [3]. P.Korzyński: Przegląd protokołów routingu stosowanych w mobilnych sieciach ad-hoc; Światowy Dzień Społeczeństwa Informacyjnego 2007, Warszawa, maj 2007r [4]. Hiroyuki Yomo, Elisabeth de Carvalho: A CSI Estimation Method for Wireless Relay Network, IEEE Communications Letters, vol. 11, no. 6, June 2007 [5]. Yi Zhao, Raviraj Adve, Teng Joon Lim: Symbol Error Rate of Selection Amplify-and- Forward Relay Systems, IEEE Communications Letters, vol. 10, no. 11, November 2006 [6]. JuYeop Kim, Taesoo Kwon, Dong-Ho Cho: Resource Allocation Scheme for Minimizing Power Consumption in OFDM Multicast Systems, IEEE Communications Letters, vol. 11, no. 6, June 2007 [7]. Hyu-Dae Kim, Dong-Ho Cho: Enhanced Power-Saving Mechanism for Broadcast and Multicast Service in WLAN, IEEE Communications Letters, vol. 9, no. 6, June 2005 [8]. Atheros Communications, http://www.atheros.com [9]. IEEE Standards Association, http://standards.ieee.org/getieee802/802.11.html 7