Poprawa efektywności roamingu w standardzie IEEE802.11 z

Rok akademicki 2013/2014
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA MAGISTERSKA
Marcin Harasimczuk
Poprawa efektywności roamingu w standardzie
IEEE802.11 z wykorzystaniem interfejsów
równoległych
Opiekun pracy
dr inż. Jacek Wytrębowicz
Ocena: .....................................................
.................................................................
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
Kierunek:
Informatyka
Specjalność:
Inżynieria Systemów Informatycznych
Data urodzenia:
1988.01.28
Data rozpoczęcia studiów:
2012.02.20
Życiorys
Urodziłem się 28 stycznia 1988 roku w Łodzi. Od 2004 roku uczęszczałem do L LO im. Ruy
Barbosy w Warszawie. W 2007 roku ukończyłem szkołę średnią. Od lutego 2008 roku
podjąłem studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej
na kierunku Informatyka i specjalności Inżynieria Systemów Informatycznych. Od lutego
2012 roku podjąłem studia II stopnia na Wydziale Elektroniki i Technik Informacyjnych
Politechniki Warszawskiej na kierunku Informatyka i specjalności Inżynieria Systemów
Informatycznych. Od czerwca 2012 roku rozpocząłem pracę zawodową w firmie Newterm.
.......................................................
Podpis studenta
EGZAMIN DYPLOMOWY
Złożył egzamin dyplomowy w dniu ..................................................................................20__ r
z wynikiem ...................................................................................................................................
Ogólny wynik studiów: ................................................................................................................
Dodatkowe wnioski i uwagi Komisji: ..........................................................................................
.......................................................................................................................................................
.......................................................................................................................................................
STRESZCZENIE
Celem niniejszej pracy jest zbadanie możliwości poprawy efektywności roamingu stacji
klienckiej standardu IEEE802.11 z zastosowaniem interfejsów równoległych. Zastosowanie
interfejsów równoległych polega na zwieloktronieniu komponentów systemu komputerowego
odpowiedzialnych za komunikację w standardzie IEEE802.11. W ramach badań
zaimplementowano modele symulacyjne sterujące zachowaniem dodatkowych interfejsów
komunikacji sieciowej. Celem implementacji jest niwelacja opóźnień wynikających z etapu
sondowania łącza procedury roamingu stacji klienckiej. Praca zawiera analizę porównawczą
wyników symulacyjnych oraz studium wykonalności rzeczywistego rozwiązania.
Słowa kluczowe: standard IEEE802.11, roaming, interfejsy komputerowe
IMPROVING THE EFFICIENCY OF ROAMING IN IEEE802.11
NETWORKS USING PARALLEL INTERFACES
The aim of this study is to investigate the possibility of improving the efficiency of roaming
procedures by using parallel interfaces IEEE802.11. The use of the parallel interfaces consists
of multiplying the number of components of a computer system responsible for
communication in the IEEE802.11 standard. This study describes the implementation of
simulation models used for controlling additional network interface components. The goal of
implementation is to reduce the overhead introduced by scanning procedure performed by a
client station during roaming. This study contains comparative analysis of simulation results
as well as feasibility study of a real-life solution.
Keywords: IEEE802.11 standard, roaming, computer interfaces
Spis treści
1 Cel pracy
7
2 Wieloaspektowa analiza zjawiska roamingu
2.1 Wykorzystywane ramki modelu OSI . . . . . . . . . . . . . . . . . . . .
2.2 Oś czasowa procedury roamingu . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Wyzwalanie procedury roamingu . . . . . . . . . . . . . . . . . .
2.2.2 Sondowanie łącza . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Uwierzytelnianie i przyłączenie w punkcie dostępowym . . . . . .
2.3 Efektywność procedury roamingu . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Pojęcie scenariusza doświadczalnego . . . . . . . . . . . . . . . .
2.3.2 Czas trwania sekwencji roamingu . . . . . . . . . . . . . . . . . .
2.3.3 Ilość sekwencji roamingu w ramach scenariusza doświadczalnego
2.3.4 Efektywność roamingu stacji klienckiej . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
9
9
13
13
15
17
23
23
24
26
28
.
.
.
.
.
30
31
31
32
32
33
.
.
.
.
.
.
36
36
38
42
46
48
49
5 Scenariusze doświadczalne dla modeli symulacyjnych
5.1 Tworzenie scenariuszy doświadczalnych w środowisku OMNet++ . . . . . . .
5.2 Sieć bazowa scenariuszy symulacyjnych . . . . . . . . . . . . . . . . . . . . . .
52
52
54
3 Projekt procedury interfejsów równoległych
3.1 Stos protokołu IEEE802.11 . . . . . . . . . .
3.2 Definicja pojęcia interfejsów równoległych . .
3.3 Projekt metody wyzwalania przez sondowanie
3.3.1 Decyzje projektowe . . . . . . . . . . .
3.3.2 Projekt jednostki zarządzającej SME
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Implementacja modeli interfejsów równoległych w strukturach INET
4.1 Struktura modeli INET . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Implementacja rozwiązania wyzwalania przez sondowanie . . . . . . . . .
4.2.1 Niezbędne modyfikacje modułu Ieee80211MgmtSTA . . . . . . . .
4.2.2 Implementacja modułu Ieee80211AgentScanSTA . . . . . . . . . .
4.2.3 Implementacja modułu Ieee80211AgentCommSTA . . . . . . . . .
4.2.4 Implementacja modułu Ieee80211AgentScanHystSTA . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.3
5.4
Konfiguracje pośrednie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Docelowe scenariusze doświadczalne . . . . . . . . . . . . . . . . . . . . . . .
6 Analiza porównawcza wyników symulacji
6.1 Metodologia analizy porównawczej . . . .
6.1.1 Narzędzie elog-parser . . . . . . .
6.1.2 Skrypt run experiments . . . . . .
6.2 Wyniki dla scenariuszy symulacyjnych . .
62
64
.
.
.
.
67
67
68
69
70
7 Podsumowanie oceny rozwiązania
7.1 Wnioski na temat wyników analizy porównawczej . . . . . . . . . . . . . . . .
7.2 Wnioski z procesu analizy, projektowania i implementacji rozwiązania . . . .
7.3 Kierunki rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
75
76
77
A Załączniki
A.1 Odtworzenie środowiska symulacyjnego. . . . . . . . . . . . . . . . . . . . . .
79
79
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Rozdział 1
Cel pracy
Celem niniejszej pracy jest zbadanie możliwości poprawy efektywności roamingu stacji
klienckiej standardu IEEE802.11 z zastosowaniem interfejsów równoległych. Roaming jest
procedurą przełączania się stacji klienckiej między punktami dostępowymi sieci bezprzewodowej WLAN (ang. wireless local area network ). Pojęcie interfejsów równoległych polega na
zastosowaniu zwielokrotnionych komponentów typu NIC (ang. network interface controller ).
Zwielokrotnienie komponentów NIC pozwala na przekroczenie fizycznych ograniczeń wpływających na efektywność roamingu w standardzie IEEE802.11. Podczas roamingu stacji klienckiej występuje konieczność wielokrotnej zmiany kanału pracy pojedynczego komponentu NIC
w celu odnalezienia nowego punktu dostępowego. Każdy dodatkowy interfejs umożliwia stacji
równoległą pracę na różnych częstotliwościach pasma, co niweluje potrzebę przedwczesnego
przełączania kanału pracy komponentu NIC owocującego zerwaniem połączenia.
Zagadnienie efektywności roamingu jest wyjątkowo istotne dla szeregu urządzeń mobilnych
wykorzystujących standard IEEE802.11 jako narzędzie stałego oraz bezprzewodowego dostępu do zasobów sieciowych. W wyniku daleko idącej komputeryzacji standard IEEE802.11
znajduje zastosowanie nie tylko w przedmiotach osobistych, takich jak telefon lub zegarek,
ale również w samochodach oraz samolotach bezzałogowych typu drone. Biorąc pod uwagę
urządzenia o tak zróżnicowanej mobilności oraz fakt ograniczonego zasięgu anten radiowych,
efektywność roamingu stacji staje się kluczowa dla utrzymania komunikacji sieciowej. Opisane potrzeby znajdują odwzorowanie w tekście standardu IEEE802.11-2012. Zatwierdzony
tekst standardu z 2012 roku opisuje procedury szybkiego roamingu w trybie FT (ang. fast
transition) oraz zawiera poprawkę IEEE802.11p dotyczącą metod przyspieszania uwierzytelniania w punkcie dostępowym dedykowaną dla rozwiązań typu WAVE (ang. wireless access
in vehicular environments).
Zwiększenie liczby interfejsów komunikacji bezprzewodowej urządzenia nie jest ani trudne,
ani kosztowne. Istnieje szeroka gama komputerów typu router board dedykowanych dla klientów technicznych oraz zastosowań przemysłowych. Komputery router board posiadają porty
typu PCI pozwalające na zwiększenie liczby kart radiowych. Zastosowanie interfejsów równoległych jest łatwiejsze w komputerach przenośnych posiadających wejścia kart rozszerzeń
lub pełną obsługę komponentów NIC dla portów USB. Większość popularnych komputerów
7
SBS (ang. single-board computer ) posiada więcej niż jeden port USB. Obsługa komponentów
NIC dla portów USB jest standardem w nowoczesnych systemach operacyjnych.
Centralnym narzędziem, użytym do prezentowanych w pracy badań, jest środowisko symulacyjne OMNet++ oraz zestaw modeli sieci komunikacyjnych INET. Źródła projektu INET
są otwarte i udostępniane na zasadzie GNU LGPL. Modele zostały wybrane ze względu na
możliwość bezpośredniej ingerencji w kod oraz udokumentowaną i potwierdzoną przykładem
symulację zjawiska roamingu mobilnej stacji klienckiej. Poprawności modeli INET dowodzi
publikacja [3]. Symulator OMNet++ bazuje na popularnym środowisku Eclipse oraz udostępnia graficzny interfejs przebiegu symulacji pomocny w pracy z modelami.
Implementację modeli poprzedza projekt procedury interfejsów równoległych osadzony w
ramach możliwych zachowań stacji standardu IEEE802.11. Dodatkowo, moja praca zawiera
studium wykonalności hipotetycznej implementacji rzeczywistego rozwiązania w wybranym
środowisku.
8
Rozdział 2
Wieloaspektowa analiza zjawiska
roamingu
Niniejszy rozdział skupia się na zjawisku roamingu stacji klienckiej w sieciach 802.11.
Prezentuję szczegółowy opis procedury roamingu w oparciu o tekst standardu IEEE802.11
oraz obserwacje przebiegu scenariuszy doświadczalnych. Scenariusze doświadczalne przeprowadzone zostały z użyciem sprzętu rzeczywistego oraz modeli symulacyjnych. Przedstawiona
analiza zjawiska roamingu jest wielopoziomowa oraz wieloaspektowa. Dążę do wyznaczenia
osi czasowej szeregującej następujące po sobie scenariusze wymiany ramek składające się na
ogół procedury. Przebieg roamingu opisuję z punktu widzenia wymiany ramek warstw modelu OSI (ang. Open Systems Interconnection model ). Poszczególne scenariusze zamykam w
bloki opisujące możliwe wariacje wpływu wywieranego na efektywność roamingu. Bazując
na dostępnych źródłach dokonuję jasnego rozgraniczenia między zaleceniami standardu, a
elementami wprowadzonymi przez producentów urządzeń.
2.1
Wykorzystywane ramki modelu OSI
Poszczególne etapy procedury roamingu sprowadzam do diagramów interakcji między stacją kliencką i punktem dostępowym. Diagramy interakcji obrazują wymianę podstawowych
jednostek informacyjnych protokołu warstwy, na której poziomie rozgrywa się dany scenariusz. Jednostki te będę dalej nazywał ramkami. Fakt, iż tekst standardu IEEE802.11 dotyczy
warstwy fizycznej oraz protokołu MAC (ang. media access control ) implikuje opis roamingu
z użyciem ramek protokołu warstwy łącza danych (ang. data link layer ). Należy jednak wziąć
pod uwagę, iż z punktu widzenia modelu OSI można rozróżnić dwa przypadki roamingu:
– Roaming na poziomie łącza danych - w warstwie drugiej (L2 ),
– Roaming na poziomie sieciowym - w warstwie trzeciej (L3 ).
9
Przypadek L2 występuje każdorazowo, a przypadek L3 gdy punkty dostępowe znajdują
się w różnych sieciach (w sensie warstwy trzeciej). Proponuję tutaj określenie świadomości roamingu, które mówi o istnieniu w danej warstwie protokołów opisujących zjawisko roamingu.
Wykorzystując to pojęcie można stwierdzić, iż warstwa trzecia posiada świadomość roamingu,
gdy protokół IP korzysta z rozszerzeń MIP (ang. mobile IP ). Rozszerzenie MIP pozwala stacji klienckiej na zachowanie adresu IP podczas migracji między sieciami. W przeciwnym
przypadku roaming L3 zaowocuje jedynie utratą połączenia (sesji w sensie protokołu TCP ).
Łatwo zauważyć propagację wpływu roamingu L2 i L3 w górę stosu protokołów modelu
OSI. Warstwy pozbawione świadomości roamingu potraktują opisywane zjawisko jako brak
połączenia (w skutek zaimplementowanego mechanizmu niedoczasu) lub utratę ramki (w zależności od protokołu). Wnioskując, określenie efektywności roamingu wymaga analizy jego
wpływu na przestrzeni wszystkich warstw. Poniżej przedstawiam zestawienie typów ramek
protokołu IEEE802.11 MAC 2.1 2.2, WPA2 2.3 2.4 oraz IEEE802.1X 2.5 2.6. Zestawienie zawiera nazwy, którymi posługuję się na diagramach interakcji. Ramki te wybrałem, ze
względu na przydatność w analizie zjawiska roamingu.
Tablica 2.1: Ramki protokołu IEEE802.11 MAC.
Skrót
Nazwa
Opis
Data
Data frame
Ack
Acknowledgement frame
Ramka przenosząca dane
z wyżych warstw modelu.
Ramka potwierdzająca bezbłędne odebranie ramki typu
Data.
Beacon
Beacon frame
Rozgłoszeniowa ramka okresowo wysyłana przez punkt
dostępowy.
AssocReq
Association request frame
Ramka wnosząca o podłączenie do punktu dostępowego
(używana przy powtórnej asocjacji między różnymi BSS ).
AssocRsp
Association response frame
Ramka potwierdzająca połączenie z punktem dostępowym.
Disassoc
Disassociation frame
Ramka wnosząca o rozwiązanie asocjacji z punktem dostępowym (pozwala na zamknięcie połączenia z gracją).
10
Tablica 2.2: Ramki protokołu IEEE802.11 MAC.
Skrót
Nazwa
Opis
AuthReq
Authentication request frame
Ramka wnosząca o uwierzytelnianie w punkcie dostępowym.
AuthRsp
Authentication
frame
Ramka potwierdzająca uwierzytelnianie w punkcie dostępowym.
Deauth
Deauthentication frame
Ramka wnosząca o zamknięcie bezpiecznego kanału wymiany danych.
ProbeReq
Probe request frame
Zapytanie o dostępność i parametry punktu dostępowego
na danym kanale.
ProbeRsp
Probe response frame
Ramka odpowiedzi punktu
dostępowego.
response
Tablica 2.3: Ramki protokołu WPA2.
Skrót
Nazwa
Opis
EAPOL-Key
(ANonce)
Extended authentication protocol over LAN key frame
Ramka protokołu WPA2
przekazująca stacji wnoszącej
o uwierzytelnianie informacje niezbędne do obliczenia
klucza PTK (ang. Pairwise
Transient Key).
EAPOL-Key
(SNonce+MIC)
Extended authentication protocol over LAN key frame
Ramka protokołu WPA2
przekazująca punktowi dostępowemu informacje niezbędne
do zabezpieczenia tożsamości
stacji klienckiej.
11
Tablica 2.4: Ramki protokołu WPA2.
Skrót
Nazwa
Opis
EAPOL-Key
(GTK+MIC)
Extended authentication protocol over LAN key frame)
Ramka protokołu WPA2
przekazująca stacji wnoszącej
o uwierzytelnianie klucz GTK
(ang. Group Transient Key)
oraz informacje niezbędne do
zabezpieczenia tożsamości.
EAPOL-key
(ACK)
Extended authentication protocol over LAN key frame
Ramka protokołu WPA2
przekazująca punktowi dostępowemu
potwierdzenie
odebrania ramki EAPOLKey(GTK+MIC).
Tablica 2.5: Ramki protokołu IEEE802.1X
Skrót
Nazwa
Opis
EAP-Request
(ID)
Extended authentication protocol request frame
Ramka wymuszająca na stacji klienckiej rozpoczęcie negocjacji klucza PMK z serwerem uwierzytelniania poprzez
podanie informacji identyfikującej.
EAP-Response
(ID)
Extended authentication protocol response frame
Ramka przekazująca punktowi dostępowemu informacje służącą do identyfikacji
klienta na serwerze uwierzytelniania.
EAP-Request
(Method)
Extended authentication protocol request frame
Ramka opakowująca wymuszenie metody uwierzytelniania EAP narzuconej przez serwer uwierzytelniania.
EAP-Success
Extended authentication protocol success frame
Ramka opakowująca potwierdzenie powodzenia uwierzytelniania stacji klienckiej na
serwerze.
12
Tablica 2.6: Ramki protokołu IEEE802.1X
Skrót
Nazwa
Opis
Access-Request
(ID)
Ramka przenosząca rozpakowane dane identyfikujące stację kliencką z punktu dostępowego.
Access-Challenge
Ramka wymuszająca konkretną metodę uwierzytelniania EAP.
Access-Accept
Ramka potwierdzająca powodzenie wybranej metody uwierzytelniania EAP.
2.2
Oś czasowa procedury roamingu
Analiza efektywności roamingu jest łatwiejsza po uprzednim podzieleniu zjawiska na następujące po sobie etapy co prowadzi do powstania osi czasowej Rys. 2.1. Podejście to podyktowane jest zmiennością obciążenia nakładanego na procedurę zakończenia lub rozpoczęcia
komunikacji z punktem dostępowym. Obciążenie to zależy od technik lub rozszerzeń standardu IEEE802.11, które mogą znacznie skomplikować lub strywializować poszczególne etapy
roamingu. Procedurę przełączania stacji klienckiej między punktami dostępowymi można
przedstawić w następujących krokach:
– Wyzwalanie procedury roamingu,
– Sondowanie łącza,
– Uwierzytelnianie w punkcie dostępowym,
– Przyłączenie do punktu dostępowego.
Wyzwalanie
Sondowanie
Przyłączenie
Uwierzytelnianie
t
Rysunek 2.1: Oś czasowa zjawiska roamingu.
W dalszej części rozdziału opiszę każdy z tych etapów oraz ocenię jego wpływ na zjawisko
roamingu.
2.2.1
Wyzwalanie procedury roamingu
Sposób podejmowania decyzji o zainicjowaniu roamingu nie jest ujęty w tekście standardu
IEEE802.11. Podejście to otwiera drogę dla szeregu heurystyk stosowanych na tym etapie.
13
W rzeczywistości zastosowana technika zależy od producenta sprzętu lub nawet konkretnego
modelu urządzenia z interfejsem radiowym. Decyzja ta zwykle podejmowana jest w stacji
klienckiej. Do najpopularniejszych [5] metod można zaliczyć:
– Przekroczenie limitu retransmisji ramek,
– Niski poziom odbieranego sygnału RSSI (ang. received signal strength indicator ),
– Niski poziom stosunku sygnału do szumu SNR (ang. signal to noise ratio),
– Utrata określonej liczby ramek typu Beacon.
Oczywiście, w przypadku mniej uniwersalnego podejścia, gdzie celem jest optymalizacja
wyzwalania pod zadanym kątem, ograniczeniem jest jedynie liczba danych dostępnych na
poziomie algorytmu decyzyjnego. Dostępne są propozycje optymalizujące czas przełączania
stacji (z wykorzystaniem danych na temat prędkości i położenia) lub skupiające się na
rozkładzie obciążenia punktów dostępowych (ang. load balancing).
Na tym etapie za efektywne uznaję zerwanie połączenia z punktem dostępowym w sposób,
który minimalizuje wpływ procedury roamingu na wyższe warstwy modelu OSI. Sprowadza
się to do minimalizacji czasu jaki stacja straci w kolejnych krokach procedury. W przypadku
metod bazujących na parametrach RSSI oraz SNR rozsądne wydaje się zastosowanie mechanizmu histerezy. Łatwo zauważyć, że brak histerezy może prowadzić do zbyt pochopnych
reakcji na skoki mocy sygnału. W metodach wykorzystujących ilościowe pomiary utraconych
ramek lub retransmisji, dodatkowo brana jest pod uwagę możliwość wystąpienia błędów ramki
przy dużej mocy sygnału. Podejście to zapewnia możliwość ucieczki z kanałów o wysokim poziomie zakłóceń na danej częstotliwości.
RSSI oraz SNR w standardzie IEEE802.11
Standard IEEE802.11 określa sposób przedstawiania mocy sygnału anteny odbiornika w
postaci liczby całkowitej [1]. Pomiar ten nosi nazwę RSSI oraz należy do zakresu od 0 do
RSSI Max. Standard nie określa wartości RSSI Max co pozwala producentom na ustalenie
podziału o wybranej granularyzacji. Warto zauważyć, że nie podano sposobu tłumaczenia
wartości RSSI na rzeczywiste jednostki mocy takie jak dBm lub mW [2]. Sterowniki interfejsów radiowych mogą wykorzystać parametr RSSI do określenia dwóch ważnych progów
sygnału:
– CCT (ang. clear channel treshold ): Poziom sygnału podczas nasłuchu jest bardzo niski
- kanał można uznać za niezajęty,
– RT (ang. roaming treshold ): Poziom sygnału zmierzonego podczas odbioru ramek z
punktu dostępowego jest niski - należy rozpocząć roaming.
Wartość parametru SNR związana jest ściśle z możliwością pomiaru szumu na interfejsie
radiowym. Za przykład pomiaru szumu mogą posłużyć urządzenia firmy Atheros. Starsza
14
wersja otwartych sterowników urządzeń Atheros zakładała stały poziom szumu o wartości
-95dBm. Oczywiście, z punktu widzenia tak dynamicznego zjawiska jak roaming przemieszczającej się stacji klienckiej stały poziom szumu nie wnosi dodatkowych korzyści. Nowsze
wersje sterowników ath5k oraz ath9k wykorzystują okresowe pomiary wartości szumu oferowane przez obsługiwane karty. Porównywanie precyzji pomiarów zaproponowanych w rozwiązaniach fitmy Atheros, a wynikami oferowanymi przez analizator widma wychodzi poza
zakres tej pracy. Wykorzystanie wartości SNR jako progu wyzwalania roamingu pozwala na
wprowadzenie dodatkowej informacji o otoczeniu przemieszczającej się stacji.
Limit retransmisji i utrata ramek
Wyzwalanie roamingu z użyciem limitu retransmisji polega na sprawdzaniu ilości zgubionych ramek typu Ack dla kolejnych ramek Data. Podejście to może okazać się efektywne
tylko jeśli na stacji klienckiej działają aplikacje, które żądają wysyłania danych z odpowiednim nasileniem i regularnością. Według standardu IEEE802.11 jedynie ramki Data wymagają potwierdzenia. Podejmowanie decyzji na temat roamingu po utraceniu określonej liczby
kolejnych ramek typu Beacon zapewnia możliwość roamingu stacji, która nie wysyła żadnych ramek. Warto zauważyć, że korzystanie z ramek typu Beacon zmusza stację kliencką do
akceptacji interwału wysyłania narzuconego przez parametr beaconInterval punktu dostępowego, który zwykle wynosi 100ms. Można wyobrazić sobie stację kliencką generującą ruch o
dużym natężeniu, która w przypadku podjęcia decyzji na podstawie utraconych ramek Ack
podjęłaby decyzję o roamingu w sposób bardziej efektywny.
2.2.2
Sondowanie łącza
Po podjęciu decyzji o rozwiązaniu połączenia w skutek procedury wyzwalania roamingu
stacja kliencka rozpoczyna poszukiwanie nowego punktu dostępowego. Brak połączenia występujący na tym etapie ma duży wpływ na wyższe warstwy modelu OSI. Częstotliwość
pracy interfejsu radiowego jest ustawicznie zmieniana, a możliwość wymiany danych na pojedynczym kanale skutecznie uniemożliwia utrzymanie stałej komunikacji oraz wymianę ramek
typu Data. Tekst standardu IEEE802.11 określa procedurę sondowania oraz wykorzystywane
typy ramek. Warto zauważyć, że standard nie proponuje żadnej konfiguracji użytych w opisie parametrów czasowych oraz nie wskazuje algorytmu wyboru nowego punktu dostępowego
[4] z listy znalezionych. Scenariusze sondowania łącza składają się z wymiany ramek typu
ProbeReq, ProbeRsp oraz Beacon. Można rozróżnić następujące warianty sondowania łącza:
– Aktywne z ustalonym SSID,
– Aktywne rozgłoszeniowe (ang. broadcast),
– Pasywne.
15
Sondowanie aktywne
Sondowanie aktywne Rys. 2.2 polega na okresowej zmianie częstotliwości pracy interfejsu
radiowego karty, wysłaniu ramki typu ProbeReq oraz oczekiwaniu przez określoną ilość czasu
(limit nie jest określony w standardzie) na odpowiedź punktu dostępowego w postaci ramki
ProbeRsp lub Beacon. Ramka ProbeReq może zostać zaadresowana do konkretnego SSID lub
wysłana w sposób rozgłoszeniowy do wszystkich punktów dostępowych na danym kanale.
Po nadaniu ramki typu ProbeReq stacja kliencka oczekuje na łączu przez okres czasu ograniczony wartością parametru minChannelTime. Brak odbioru ramki ProbeRsp lub Beacon
w czasie minChannelTime pozwala stacji na zmianę częstotliwości pracy interfejsu radiowego. Odebranie ramki ProbeRsp lub Beacon w czasie minChannelTime oznacza, że stacja
pozostanie na danej częstotliwości pracy interfejsu radiowego przez okres czasu ograniczony
wartością parametru maxChannelTime. Pozostawanie na danym kanale ma za zadanie umożliwienie odbioru ramek od innych punktów dostępowych pracujących z tą samą częstotliwością.
Określenie ustalonej nazwy SSID może uprościć działanie ostatecznego algorytmu wyboru.
Klient
AP
ProbeReq
Klient oczekuje nie dłużej
niż minChannelTime.
ProbeRsp
Klient oczekuje jeszcze nie
dłużej niż maxChannelTime.
Rysunek 2.2: Sondowanie aktywne.
Sondowanie pasywne
Sondowanie pasywne Rys. 2.3 polega na okresowym przełączaniu częstotliwości radiowego
interfejsu i oczekiwaniu na ramki typu Beacon. Czas oczekiwania na danym kanale ograniczony jest przez wartość parametru maxChannelTime. Tryb skanowania pasywnego uzależnia
stację kliencką od powszechnie stosowanego interwału wysyłania ramek typu Beacon równego
100ms. Interwał ten staje się, w najgorszym przypadku, czasem jaki stacja musiałaby oczekiwać na danym kanale w celu otrzymania możliwych ramek typu Beacon. Łatwo zauważyć, że
tryb pasywny znacznie zmniejsza ruch w medium transmisyjnym. Zwiększenie częstotliwości
wysyłania ramek typu Beacon mogłoby mieć pozytywny wpływ na efektywność procedury
roamingu, ale powszechnie stosowany interwał zdecydowanie wskazuje na procedurę sondowania aktywnego.
16
Klient
AP
Klient oczekuje na łączu.
Beacon
Klient oczekuje jeszcze
do progu maxChannelTime.
Rysunek 2.3: Sondowanie pasywne.
Zakres częstotliwości
Kolejnym aspektem sondowania jest badany zestaw częstotliwości. Tryb pasywny może
być wykorzystany na częstotliwościach zabronionych dla danego regionu. Sondowanie można
przyspieszyć specyfikując kolejność i ilość częstotliwości. Częstotliwości sondowane w trybie
aktywnym zależą od regionu przypisanego do urządzenia. Niektóre urządzenia takie jak
punkty dostępowe pozwalają na ręczne określenie regionu pracy. Określenie regionu pozwala
na sondowanie tylko dozwolonych częstotliwości. Często sondowaniu podlegają jedynie nie
nakładające się kanały pasma używanego w standardzie IEEE802.11.
Problem wyboru punktu dostępowego
Standard nie porusza kwestii wyboru nowego punktu dostępowego [9]. Podejście to wydaje się unikać zbędnych komplikacji protokołu, gdyż podobnie jak w przypadku wyzwalania
procedury roamingu algorytm może optymalizować wiele różnych parametrów sieci (np. rozkład obciążenia punktów dostępowych). W większości oprogramowania stosuje się podejście
minimalistyczne, które wykorzystuje opisany w standardzie parametr RSSI lub SNR do wyboru najlepszego punktu dostępowego z listy odnalezionych. Łatwo zauważyć, że w punktach
granicznych wpływu dwóch punktów dostępowych poziomy SNR mogą być bardzo zbliżone.
W takich miejscach najczęściej wyzwalana jest decyzja o roamingu co może zaowocować
nieefektywnym wyborem nowego punktu dostępowego.
2.2.3
Uwierzytelnianie i przyłączenie w punkcie dostępowym
Etap uwierzytelniania ma na celu utworzenie bezpiecznego kanału wymiany ramek typu
Data między punktem dostępowym, a stacją kliencką. Podstawowe metody uwierzytelniania wykorzystują procedury wymiany ramek typu AuthReq oraz AuthRsp. W zależności od
skomplikowania metody liczba wymienianych ramek typu AuthReq oraz AuthRsp wzrasta.
Obecnie, metody oferujące zadowalający poziom bezpieczeństwa odkładają uwierzytelnianie
17
na czas po przyłączeniu do punktu dostępowego i stosują ramki typu EAPOL-Key. Sukcesy
kolejnych prób przełamywania protokołów bezpieczeństwa standardu IEEE802.11 inicjowały
wprowadzanie coraz bardziej rozbudowanych metod uwierzytelniania. Znaczne rozbudowanie
niniejszego etapu wpływa szkodliwie na efektywność roamingu stacji klienckiej. Problem nie
został przeoczony w kolejnych wersjach standardu IEEE802.11. Warto tutaj wspomnieć o
rozszerzeniu IEEE802.11r-2008, które zostało włączone do tekstu standardu IEEE802.112012. Rozszerzenie IEEE802.11r pozwala obecnie stosowanym metodom uwierzytelniania na
podłączenie informacji, która wcześniej wymieniana była przy pomocy wspominanych ramek EAPOL-Key do ramek typu AuthReq, AuthRsp, AssocReq oraz AssocRsp. Podejście to
pozwala przeprowadzić rozszerzone uwierzytelnianie z wykorzystaniem liczby ramek odpowiadającej procedurze podstawowej.
Z punktu widzenia wymiany ramek Rys. 2.4 przyłączenie stacji klienckiej do punktu
dostępowego odpowiada wymianie ramek typu AssocReq oraz AssocRsp. Scenariusz ten nie
zmienia się na przestrzeni różnych wersji standardu IEEE802.11. Przyłączenie do punktu
dostępowego może być krokiem uwierzytelniania i powinno być analizowane w kontekście tej
procedury.
Klient
AP
AssocReq
AssocRsp
Rysunek 2.4: Przyłączenie do punktu dostępowego.
Niniejszy rozdział opisuje możliwe scenariusze uwierzytelniania i dąży do analizy ich
wpływu na efektywność roamingu stacji klienckiej. W swoich rozważaniach zdecydowałem
się na pominięcie algorytmu WEP (ang. wired equivalent privacy). Stosowanie algorytmu
WEP nie jest aktualnie zalecane ze względów bezpieczeństwa. Problemy z bezpieczeństwem
zamykają możliwości rozwoju tej metody i powodują, że jej analiza ma obniżoną wartość.
W roku 2006 najnowsze standardy bezpieczeństwa stały się obowiązkowe dla wszystkich
certyfikowanych urządzeń implementujących standard IEEE802.11. Przymusowa certyfikacja oznacza, że metoda uwierzytelniania WPA (ang. Wi-Fi protected access) są spotykane
głównie ze względu na kompatybilność ze starszym sprzętem. Trendy rozwoju zauważalne
w kolejnych wersjach standardu IEEE802.11 wskazują, że prace związane ze zwiększeniem
efektywności roamingu skupiają się rozwoju uwierzytelniania WPA2 (ang. Wi-Fi protected
access II ). Wsparcie dla algorytmów WEP oraz WPA zauważalne w nowoczesnych urządzeniach ma charakter kompatybilności wstecznej. Analizowanie wpływu metod WEP oraz WPA
na zwiększanie efektywności roamingu może mieć znacznie obniżoną wartość badawczą, gdyż
głównym nurtem rozwoju standardu IEEE802.11 jest modyfikacja algorytmu WPA2.
18
Odrzucając opisane mechanizmy skupiam się na opisanej w standardzie IEEE802.112012 gałęzi RSNA (ang. robust security network association). Należy wspomnieć, iż algorytm
WPA2 polega na implementacji podzbioru mechanizmów zebranych w RSNA, do których
można zaliczyć:
– Uwierzytelnianie typu open-system,
– Porozumienie cztero-etapowe (ang. 4-way handshake),
– Porozumienie klucza grupowego (ang. group key handshake),
– Porozumienie cztero-etapowe w wersji FT (ang. fast transition),
– Współdzielenie kluczy na zasadzie PSK (ang. pre-shared key),
– Współdzielenie kluczy na zasadzie IEEE802.1X.
Uwierzytelnianie open-system
Najprostszą metodą jest uwierzytelnianie typu open-system Rys. 2.5. W celu zachowania poprawności należałoby tutaj mówić o procedurze identyfikacji. Metoda open-system nie
służy ustaleniu bezpiecznego kanału wymiany informacji, lecz identyfikacji przy pomocy adresu MAC interfejsu bezprzewodowego. Uwierzytelnianie i przyłączenie wymaga w tym przypadku wymiany jedynie czterech ramek. Opis tej metody jest wartościowy ze względy na fakt,
że jest ona dobrze odseparowanym etapem jako samodzielny algorytm uwierzytelniania oraz
jako element składowy procedury uwierzytelniania WPA2. Metoda uwierzytelniania opensystem jest interesująca, gdyż narzuca pewnego rodzaju dolne ograniczenie na ilość niezbędnych kroków procedury uwierzytelniania i przyłączenia stacji klienckiej. Jest to minimalny
scenariusz pozwalający na wymianę ramek typu Data i zakończenie procesu roamingu.
Klient
AP
AuthReq
AuthRsp
AssocReq
AssocRsp
Rysunek 2.5: Uwierzytelnianie open-system.
19
Porozumienie cztero-etapowe
Uwierzytelnianie z użyciem algorytmu WPA2 zakłada istnienie klucza nadrzędnego PMK
(ang. pairwise master key). Klucz PMK jest sekretem stacji klienckiej oraz punktu dostępowego. Ryzyko związane z bezpośrednim stosowaniem klucza PMK jest wysokie. Porozumienie
cztero-etapowe Rys. 2.6 służy ustaleniu klucza pochodnego PTK, na który składa się:
– Oryginalny klucz PMK,
– Losowa liczba jednorazowa ANonce (ang. authenticator nonce),
– Losowa liczba jednorazowa SNonce (ang. supplicant nonce),
– Adres MAC stacji klienckiej,
– Adres MAC punktu dostępowego.
Dodatkowo, w ramach porozumienia dokonuje się wymiany klucza grupowego GTK
(ang. group transient key), który zabezpiecza komunikaty typu Broadcast oraz Multicast.
Ze względu na okres ważności wymiana klucza grupowego zachodzi częściej. Wymiana klucza
grupowego w postaci odseparowanego porozumienia (ang. group key handshake) może zajść
jedynie po wstępnym porozumieniu cztero-etapowym.
Porozumienie inicjowane jest przez punkt dostępowy, który przyjmuje rolę jednostki decydującej o powodzeniu uwierzytelniania (ang. authenticator ). Stacja kliencka przyjmuje rolę
stacji wnoszącej o uwierzytelnianie (ang. supplicant). Punkt dostępowy wysyła do stacji
klienckiej ramkę typu EAPOL-Key(ANonce) udostępniając swój składnik niezbędny do obliczenia klucza PTK. Stacja kliencka dokonuje obliczenia klucza i wysyła punktowi dostępowego
ramkę typu EAPOL-Key(SNonce+MIC ) pozwalającą punktowi dostępowemu obliczyć PTK
oraz sprawdzić integralność wiadomości przy pomocy liczby kontrolnej MIC. Powodzenie
na tym etapie pozwala punktowi dostępowemu przejść do porozumienia klucza grupowego.
Punkt dostępowy wysyła ramkę typu EAPOL-Key(GTK+MIC) zawierającą klucz grupowy
oraz liczbę kontrolującą integralność MIC. Stacja kliencka potwierdza powodzenie procedury
ramką typu EAPOL-Key(Ack).
20
Klient
AP
Uwierzytelnianie open-system.
EAPOL-Key ANonce
EAPOL-Key SNonce+MIC
EAPOL-Key GTK+MIC
EAPOL-Key ACK
Rysunek 2.6: Porozumienie cztero-etapowe.
Porozumienie klucza grupowego
Jest to osobny scenariusz wymiany ramek Rys. 2.7, którego celem jest wymiana klucza
grupowego między punktem dostępowym i stacją kliencką. Porozumienie jest inicjowane przez
punkt dostępowy po upływie wyznaczonego czasu ważności klucza. Scenariusz składa się z
wymiany dwóch ramek. Punkt dostępowy wysyła ramkę typu EAPOL-Key(GTK+MIC) zawierającą klucz grupowy oraz liczbę kontrolującą integralność MIC. Stacja kliencka potwierdza powodzenie procedury ramką typu EAPOL-Key(Ack).
Klient
AP
Porozumienie cztero-etapowe
oraz upłynęła ważność
klucza grupowego.
EAPOL-Key GTK+MIC
EAPOL-Key ACK
Rysunek 2.7: Porozumienie klucza grupowego.
Porozumienie cztero-etapowe w wersji FT
Zmiany zawarte w poprawce IEEE802.11r-2008 zostały włączone do tekstu standardu
IEEE802.11-2012 pod hasłem FT (ang. fast trasition). Centralnym elementem poprawki jest
redukcja wymiany ramek podczas ponownego uwierzytelniania. Ponowne uwierzytelnianie rozumiem jako przyłączenie do innego punktu dostępowego, który pracuje pod szyldem wspólnego ESS (ang. extended service set). Punkty dostępowe implementujące ESS wymagają
21
określonego w standardzie sposobu komunikacji DS (ang. distribution system). DS oznacza
istnienie bezpośredniego, bliżej nie sprecyzowanego sposobu zestawienia komunikacji między
punktami dostępowymi. Zastosowanie ESS powoduje, że procedura roamingu stacji klienckiej
staje się niewidoczna dla interfejsu LLC (ang. logical link control ), który rozgranicza warstwę
drugą i trzecią modelu OSI. Oczywiście nie należy mylić tej funkcjonalności ze wspomnianym
wcześniej mobilnym adresem IP. Mechanizm ESS zakłada podłączenie punktów dostępowych
do wspólnej sieci. Ramka otrzymana przez punkt dostępowy jest przekierowana z pomocą
DS do innego punktu dostępowego, z którego klient korzysta w danej chwili. Mechanizm FT
rozszerza dodatkowo funkcjonalność ESS przyspieszając procedurę uwierzytelniania podczas
roamingu L2. Pełne porozumienie cztero-etapowe wymagane jest jedynie podczas wstępnego
uwierzytelniania klienta w ESS. Poprawnie uwierzytelniona stacja kliencka wykonująca procedurę roamingu w zakresie ESS może skorzystać z opcji przyłączania FT (ang. fast trasition).
W opcji FT wymiana klucza porozumienia cztero-etapowego odbywa się poprzez podpinanie
potrzebnych informacji do ramek AuthReq, AuthRsp, AssocReq oraz AssocRsp. Uwierzytelnianie stacji klienckiej sprowadza się do scenariusza open-system.
Współdzielenie kluczy na zasadzie PSK
Dystrybucja nadrzędnego klucza uwierzytelniającego PMK na zasadzie PSK polega na
wcześniejszym umieszczeniu go na wszystkich maszynach. Założenie o wcześniejszej dystrybucji klucza pozwala na pomiecie związanego z tym etapu podczas uwierzytelniania. Wcześniejsza dystrybucja klucza jest jednak uciążliwa przy większej ilości maszyn. Brak centralnego
zarządzania kluczami może doprowadzić do dodatkowych utrudnień związanych z utrzymaniem bezpieczeństwa klucza.
Współdzielenie kluczy na zasadzie IEEE802.1X
Metoda współdzielenia opisana w standardzie IEEE802.1X zakłada istnienie centralnej
maszyny zarządzającej kluczami. Punkty dostępowe mają możliwość komunikacji z maszyną
uwierzytelniającą. Zastosowanie tej metody wymusza dodatkowe porozumienie Rys. 2.8 z
udziałem punktu dostępowego, stacji klienckiej oraz serwera uwierzytelniania (ang. authentication server ). Dodatkowe porozumienie zachodzi po uwierzytelnianiu open-system. Powodzenie pozwala na użycie otrzymanego, unikalnego klucza głównego w porozumieniu czteroetapowym ze stacją kliencką. Podczas porozumienia 802.1X serwer uwierzytelniania wymusza
na stacji klienckiej metodę uwierzytelniania EAP (ang. extended authentication protocol ). Istnieje wiele metod EAP pozwalających na uzgodnienie klucza PMK, które wymagają wymiany
dodatkowych ramek. Łatwo zauważyć jak duży jest narzut ilości ramek związanych z współdzieleniem klucza na zasadzie 802.1X. Z punktu widzenia analizy roamingu można założyć, że
kanał komunikacji między punktem dostępowym i serwerem uwierzytelniania zestawiony jest
z pomocą dowolnego medium transmisji. W szczególności może to być kanał pozwalający na
szybszą i pewniejszą wymianę ramek. Jeśli szybkość transmisji byłaby o wiele większa to proces opakowywania ramek w punkcie dostępowym mógłby stać się przeźroczysty dla potrzeb
22
analizy roamingu na łączu radiowym. W takim przypadku możnaby potraktować uzgadnianie
klucza na zasadzie IEEE802.1X jako konieczność dodatkowego porozumienia między stacją
kliencką i punktem dostępowym.
Klient
AP
Serwer
EAP-Request
EAP-Response
Access-Request
Access-Challenge
EAP-Request
Wybrana metoda EAP.
Access-Accept
EAP-Success
Rysunek 2.8: Uwierzytelnianie na zasadzie IEEE802.1X.
2.3
Efektywność procedury roamingu
Ważnym elementem tej pracy jest porównanie wpływu modyfikacji poszczególnych kroków na całość procedury roamingu. Posiadając dobrze zdefiniowaną oś czasową roamingu
Rys. 2.1 mogę wprowadzić pojęcie sekwencji roamingu, które opisuje pojedyncze zajście procedury roamingu w ramach scenariusza doświadczalnego zgodnie z definicją 2.3.1. Porównywanie sekwencji roamingu wymaga wprowadzenia miary, która pozwala rozróżnić scenariusze
bardziej lub mniej udane. Scenariusz udany zawiera sekwencje roamingu o większej efektywności. Niniejszy rozdział definiuje miarę efektywności roamingu, która pozwala przedstawić
ocenę sekwencji roamingu w postaci liczby rzeczywistej. Warto zwrócić uwagę na fakt, iż
wybór miary efektywności jest subiektywny. Dążę do określenia sposobu oceny scenariusza
roamingu, który faworyzuje zjawiska korzystne z punktu widzenia mobilnej stacji klienckiej.
2.3.1
Pojęcie scenariusza doświadczalnego
Ocena pojedynczego zajścia procedury roamingu w postaci sekwencji roamingu nie jest
wystarczająca do ustalenia całościowej miary efektywności zjawiska. Należy zwrócić uwagę,
23
że ruch stacji mobilnej jest bezpośrednim czynnikiem inicjalizującym etap wyzwalania roamingu. Potrzebna jest miara, która uwzględnia ocenę decyzji stacji o rozpoczęciu sekwencji
roamingu. Konieczne jest rozpatrywanie efektywności roamingu na podstawie pojęcia scenariusza doświadczalnego. Scenariusz doświadczalny pozwala wprowadzić opis środowiska oraz
zachodzącego w nim ruchu stacji mobilnej. Wyzwalanie procedury roamingu może zachodzić
wielokrotnie w ramach danego scenariusza.
Środowiskiem nazywam wszystkie elementy scenariusza doświadczalnego, które nie dotyczą mobilnej stacji klienckiej. Do składowych środowiska zaliczam:
– Obszar roboczy scenariusza,
– Punkty dostępowe,
– Architekturę sieciową,
– Dodatkowe artefakty (np. przeszkody).
Środowisko doświadczalne najprostszej postaci składa się z obszaru roboczego oraz rozmieszczonych w nim punktów dostępowych. Obszar roboczy powinien posiadać określony
rozmiar z założeniem pomijania wpływu czynników z poza jego granic. Ilość punktów dostępowych jest znana oraz posiadają one ustalone położenie i zasięg działania. Architektura
sieci stanowi definicję zasobów udostępnianych przez punkty dostępowe. Opis środowiska doświadczalnego powinien zawierać również wszystkie parametry wejściowe swoich składników.
Ilość parametrów zależy od przyjętego stopnia szczegółowości scenariusza.
Definicja stacji mobilnej zawiera opis ruchu oraz pozostałe parametry konfiguracyjne
klienta. Parametry ruchu opisują sposób przemieszczania się stacji w ramach obszaru roboczego środowiska. Parametry konfiguracyjne klienta powinny określać zasięg sygnału oraz
dodatkowe pozycje w zależności od stopnia szczegółowości scenariusza.
2.3.2
Czas trwania sekwencji roamingu
Wybór czasu jako miary efektywności pojedynczego zdarzenia roamingu jest naturalnym
następstwem reprezentacji sekwencji roamingu w postaci osi czasowej. Należy zwrócić uwagę,
że celem wyprowadzania wzorów jest szczegółowa definicja miary efektywności. Niektóre
parametry zostały uznane za stałe i uległy pominięciu. Następujące parametry nie są brane
pod uwagę:
– Czas przełączania kanału radiowego,
– Opóźnienie sygnału w medium transmisji.
Prezentowane równania nie biorą pod uwagę opóźnień powyżej warstwy drugiej modelu OSI.
W najprostszej postaci długość sekwencji roamingu obliczam korzystając z wzoru
tr = tw + ts + tu+p ,
24
(2.1)
gdzie tw oznacza czas wyzwalania, ts czas sondowania łącza, a tu+p sumaryczny czas
podłączenia i uwierzytelniania. Czas sekwencji roamingu tr jest sumą czasów trwania jej poszczególnych kroków. Z punktu widzenia stacji mobilnej najbardziej niekorzystnym okresem
pracy jest etap sondowania łącza ts . Etap sondowania łącza wiąże się z całkowitą utratą
łączności z jakimkolwiek punktem dostępowym. W trakcie wyzwalania sekwencji roamingu
można założyć, że mimo utraty pewnej liczy ramek typu Beacon możliwe jest przekazanie
poprawnej ramki danych (nawet jeśli nie zostanie ona prawidłowo potwierdzona). Etap uwierzytelniania i podłączenia tu+p jest już częścią komunikacji z nowym punktem dostępowym,
gdzie istnieje szansa zaszycia pewnych istotnych danych.
Czas wyzwalania tw opisuje interwał między wystąpieniem pierwszych przesłanek o
spadku jakości połączenia i uruchomieniem procedury sondowania łącza. Warto zwrócić
uwagę, że spadek jakości łącza nie oznacza natychmiastowej utraty komunikacji. Czas wyzwalania jest buforem zapobiegającym podejmowaniu decyzji o roamingu w skutek jednorazowych błędów pomiaru lub transmisji. Większość algorytmów wyzwalania wykorzystuje
metodę zliczania negatywnych przesłanek z zerowaniem licznika w przypadku pozytywnej odpowiedzi. Przekroczenie limitu licznika powoduje uruchomienie procedury sondowania łącza.
Oczywiście decyzja o negatywnej przesłance zapada w skutek niedoczasu, którego wartość
można potraktować jako okres testowania jakości łącza Tt . Korzystając z limitu licznika N
można wyprowadzić wzór
tw = N ∗ Tt
(2.2)
będący rozwinięciem składnika wyzwalania w równaniu 2.1.
Czas sondowania łącza ts opisuje interwał między decyzją o zerwaniu połączenia i odnalezieniem nowego punktu dostępowego. Należy wyprowadzić wzór dla sondowania aktywnego
i pasywnego. Zgodnie z przeprowadzoną analizą czas sondowania aktywnego posiada dwa
niedoczasy:
– Niedoczas minChannelTime,
– Niedoczas maxChannelTime.
Czas oczekiwania na każdym kanale zależy od zdarzenia odebrania ramki typu ProbeRsp,
więc wzór na czas sondowania ma postać sumy
ts =
K
X
rk ∗ maxChannelT ime + (1 − rk ) ∗ minChannelT ime,
(2.3)
k=1
gdzie K to liczba kanałów zlecona do sondowania, k to aktualnie sondowany kanał, rk ∈
{0, 1} oznacza zdarzenie odebrania ramki ProbeRsp na kanale k. W przypadku sondowania
pasywnego wzór upraszcza się do postaci
ts = K ∗ maxChannelT ime.
(2.4)
Wyprowadzenie równania czasu podłączenia i uwierzytelnienia tu+p jest bardziej skomplikowane. W przypadku sekwencji roamingu zakończonej powodzeniem granicami interwału
25
czasu tu są zdarzenia wysłania oraz odebrania ramek protokołu IEEE802.11. Do równania wchodzą dodatkowe składniki związane z bezprzewodową transmisją danych. Procedury
uwierzytelniania oraz podłączania można uprościć do pewnej liczby porozumień. Opóźnienie
zjawiska porozumienia dwu-etapowego (ang. 2-way handshake) można sprowadzić do sumy
czasów udanego nadania ramki ze stacji wiodącej oraz odpowiedzi stacji odpytywanej. Opóźnienie transmisji ramki opisuję wzorem
ttx =
E+1
X
tmedium
+ E ∗ Tout ,
k
(2.5)
k=1
gdzie E oznacza liczbę błędów ramki, tmedium
oznacza opóźnienie dostępu do medium
k
transmisji przy k-tej próbie nadawania oraz Tout oznacza wartość niedoczasu dla oczekiwania
na ramki odpowiedzi danego porozumienia. Decyzja o błędzie ramki wymaga oczekiwania
przez czas Tout dla każdego z błędów. Przy nadawaniu każdej ramki stacja musi uzyskać
dostęp do medium. Należy pamiętać o ostatniej ramce nadanej z powodzeniem. Podobnie jak
we wcześniejszych równaniach pojawia się składnik E ∗Tout , który opisuje wystąpienie pewnej
liczby niedoczasów. Trudności sprawia fakt, iż rozpoczęcie procedury odliczania czasu Tout
wymaga udanego dostępu do medium transmisji związanego z próbą nadania ramki. Zgodnie
z fundamentalnymi cechami MAC protokołu IEEE802.11 można stwierdzić, że czas dostępu
do medium jest niedeterministyczny. Stacja odpytywana odpowiada jedynie pojedynczym
potwierdzeniem co skutkuje dodaniem składnika dostępu do medium tmedium
we wzorze na
rx
opóźnienie porozumienia dwu-etapowego
t2−way =
E+1
X
tmedium
+ E ∗ Tout + tmedium
.
k
rx
(2.6)
k=1
Zakładając najprostszą postać uwierzytelniania, opóźnienie uwierzytelniania i podłączenia jest sumą
tu+p = tu + tp ,
(2.7)
gdzie
tu =
E+1
X
auth
tmedium
+ E ∗ Tout
+ tmedium
k
rx
(2.8)
assoc
tmedium
+ E ∗ Tout
+ tmedium
.
k
rx
(2.9)
k=1
oraz
tp =
E+1
X
k=1
auth oraz T assoc to niedoczasy dla procedury uwierzytelniania i podłączenia.
Stałe Tout
out
2.3.3
Ilość sekwencji roamingu w ramach scenariusza doświadczalnego
Ocena uwarunkowań czasowych pojedynczej sekwencji roamingu nie jest wystarczająca
do analizy zachowania mobilnej stacji klienckiej. Miara efektywności roamingu powinna być
wzbogacona o możliwość porównania scenariuszy doświadczalnych. Scenariusz doświadczalny
może zawierać dowolną ilość sekwencji roamingu. Należy ustalić, czy z przyjętego w pracy
punktu widzenia zwiększanie częstotliwości roamingu jest zjawiskiem negatywnym.
26
Wpływ częstotliwości roamingu na całościową efektywność zjawiska
Rysunek 2.9: Przykładowy scenariusz doświadczalny.
Proponuję rozważenie przykładowego, uproszczonego scenariusza doświadczalnego
Rys. 2.9. Pionowa linia oznacza obszar, w którym siła sygnału punktów dostępowych jest
równa. Białe punkty zaznaczają przybliżone miejsca wyzwalania procedury roamingu (dodatkowo oznaczone literą odpowiadającą metodzie wyzwalania). Przedstawione w rozdziale
2.2.1 metody wyzwalania mają bardzo zbliżone właściwości i potencjał do zwracania identycznej liczby wyzwoleń dla ustalonego scenariusza doświadczalnego. Na potrzeby pracy zakładam istnienie hipotetycznej metody wyzwalania. Hipotetyczna metoda podejmuje decyzję
o wyzwalaniu na podstawie uaktualnianej tablicy mocy punktów dostępowych będących w
zasięgu. Hipotetyczną metodę nazywam dalej wyzwalaniem przez sondowanie. Przykładowy
scenariusz roamingu jest uproszczony i nie wymaga dalszego precyzowania metody wyzwalania przez sondowanie. W przykładzie Rys. 2.9 wykorzystuję następujące metody wyzwalania
roamingu:
– Przypadek A: Wyzwalanie w reakcji na utratę ramek typu Beacon (zachowanie standardowe),
– Przypadek B: Wyzwalanie przez sondowanie (metoda hipotetyczna).
Zakładam, że algorytm wyboru punktu dostępowego wybiera punkt o większej sile sygnału. Procedura sondowania łącza zostaje zakończona przed ponownym wyzwoleniem.
Nawet jeśli procedura wyzwalania przez sondowanie oferuje znaczne zwiększenie efektywności sekwencji roamingu, to w przykładowym scenariuszu doświadczalnym owocuje ona
trzykrotnym wyzwoleniem. Kierując się intuicją można wnioskować, że zmiana punktu dostępowego była potrzebna jedynie w przypadku A. Idąc dalej tropem minimalizacji całkowitego
27
czasu spędzonego na procedurze roamingu można zasugerować sumowanie opóźnień poszczególnych sekwencji roamingu. Podejście to ma wadę, która polega na zatarciu informacji o ilości
wyzwoleń. Łatwo wyobrazić sobie, że duża liczba wyzwoleń z małym opóźnieniem sekwencji
roamingu może być bardzo efektywna biorąc pod uwagę wybrane programy komunikacyjne
działające w wyższych warstwach modelu OSI.
2.3.4
Efektywność roamingu stacji klienckiej
Ostatecznie, proponuję zaakceptowanie dwoistej natury oceny efektywności roamingu
stacji klienckiej. Kierując się dwoistą miarą efektywności wyróżniam następujące przypadki
graniczne:
– Roaming efektywny: minimalne opóźnienie sekwencji roamingu oraz minimalna ilość
wyzwoleń,
– Przypadek pośredni: minimalna ilość wyzwoleń lub minimalne opóźnienie,
– Roaming nieefektywny: opóźnienie sekwencji roamingu oraz liczba wyzwoleń nie są
minimalne.
n
(3, 2)
2
d
3
(0, 0)
t
Rysunek 2.10: Miara efektywności roamingu.
Miarę efektywności roamingu można przedstawić w postaci układu współrzędnych
Rys. 2.10 przy pomocy dwu osi liczbowych:
– Oś n odpowiada liczbie wyzwoleń sekwencji roamingu w ramach scenariusza doświadczalnego,
– Oś t odpowiada sumarycznemu czasowi sekwencji roamingu w ramach scenariusza
doświadczalnego.
Kierując się ustalonymi przypadkami granicznymi staje się oczywiste, że punkty znajdujące się bliżej centrum układu współrzędnych Rys. 2.10 odpowiadają scenariuszom bardziej
efektywnym. Odległość d od centrum jest miarą efektywności roamingu, która nie zaciera
28
informacji o ilość wyzwoleń oraz umożliwia prostą graficzną reprezentację i porównanie scenariuszy doświadczalnych. Efektywność roamingu przykładu Rys. 2.10 można opisać wzorem
d=
q
(n − n0 )2 + (t − t0 )2 .
(2.10)
Punkt (n0 , t0 ) to środek układu, więc efektywność roamingu wynosi
d=
p
n2 − t 2 =
√
4+9=
29
√
13 ≈ 3.6.
(2.11)
Rozdział 3
Projekt procedury interfejsów
równoległych
W niniejszym rozdziale wprowadzam definicję pojęcia interfejsów równoległych. Definicja
bazuje na pomyśle przedstawionym skrótowo w rozdziale wprowadzającym 1. Korzystając z
przesłanek szczegółowej analizy procedury roamingu zawartych w rozdziale 2 tworzę projekt
rozwiązania opartego o metodę interfejsów równoległych. Celem rozwiązania jest poprawa
efektywności roamingu stacji klienckiej w zestawieniu z metodami ujętymi w rozdziale 2.
Terminologia projektu abstrahuje od naleciałości związanych z docelowym środowiskiem implementacji. W celu uogólnienia opisu wykorzystuję pojęcia pochodzące z tekstu standardu
IEEE802.11. W szczególności, posługuję się nazwami poleceń opisujących komunikację między poszczególnymi warstwami protokołu IEEE802.11. Warstwy te stanowią abstrakcję elementów znanych z dziedziny architektury komputerów, do których można zaliczyć:
– Sterowniki urządzeń bezprzewodowych certyfikowanych znakiem Wi-Fi,
– Oprogramowanie typu firmware,
– Aplikacje przestrzeni użytkownika.
30
3.1
Stos protokołu IEEE802.11
Poniższy diagram Rys. 3.1 przedstawia stos protokołu IEEE802.11.
Warstwa łącza danych
MAC
MLME
SAP
SAP
SME
Warstwa fizyczna
PHY
PLME
SAP
Rysunek 3.1: Stos protokołu IEEE802.11.
Standard definiuje działanie protokołu IEEE802.11 posługując się opisem działań i usług
udostępnianych przez warstwy:
– MAC (ang. media access control ): odpowiada warstwie łącza danych modelu OSI,
– PHY (ang. physical ): odpowiada warstwie fizycznej modelu OSI.
Warstwy MAC oraz PHY posiadają wbudowane jednostki zarządzające ME (ang. management entity):
– MLME (ang. MAC layer management entity): jednostka zarządzająca działaniem
warstwy MAC,
– PLME (ang. physical layer management entity): jednostka zarządzająca działaniem
warstwy PHY.
Standard wyróżnia dodatkową jednostkę zarządzającą SME (ang. system management entity). Jednostka SME rezyduje poza modelem OSI odzwierciedlając docelowy system komputerowy wykorzystujący usługi warstw MAC oraz PHY. Usługi reprezentowane są w postaci interfejsów SAP (ang. service access point) modelu OSI. Tekst standardu zakłada, iż jednostka
SME powinna wykorzystywać interfejs SAP udostępniany przez MLME. Zarówno MLME
oraz PLME udostępniają interfejsy SAP. Standard nalega na implementację warstwową, w
której SAP jednostki PLME wykorzystywany jest jedynie z pomocą SAP warstwy MLME.
Standard nie definiuje SAP jednostki SME, gdyż jest ona uogólnieniem wielozadaniowego
systemu komputerowego.
3.2
Definicja pojęcia interfejsów równoległych
Interfejsami równoległymi nazywam dwa lub więcej stosów protokołu IEEE802.11, których warstwy są zależne od ustalonego poziomu. Zależność warstw może polegać na zestawieniu komunikacji skrośnej lub wspólnej warstwie nadrzędnej. W pierwszym przypadku możliwa
31
jest rzeczywista równoległość, w drugim należałoby użyć określenia współbieżność. Niezależność na poziomie sprzętowym pozwala obejść niektóre ograniczenia fizyczne. W szczególności,
każda dodatkowa antena pozwala systemowi działać jednocześnie na dodatkowej częstotliwości medium transmisyjnego.
3.3
Projekt metody wyzwalania przez sondowanie
Moim celem jest opracowanie metody poprawy efektywności roamingu z zastosowaniem
definicji interfejsów równoległych. Procedura sekwencji roamingu opisana w rozdziale 2.2 odbywa się z udziałem jednego stosu protokołu IEEE802.11 znajdującego się na urządzeniu z
pojedynczym interfejsem NIC. Problem sprowadza się do wyboru etapu sekwencji roamingu,
którego wykonanie przez dodatkowy interfejs bezprzewodowy miałoby potencjał poprawy całościowej miary efektywności roamingu stacji klienckiej. Łatwo zauważyć, że cała procedura
roamingu polega na wymuszeniu zerwania połączenia z aktualnym punktem dostępowym w
celu zwolnienia zasobów interfejsu bezprzewodowego. Połączenie musi zostać zerwane, gdyż
etap sondowania łącza wymaga kolejnych zmian częstotliwości pracy karty radiowej. Oczywiście, pojedynczy interfejs bezprzewodowy nie może pracować na wielu częstotliwościach pasma
jednocześnie. Wnioskując, przeniesienie ciężaru procedury sondowania łącza na osobny interfejs mogłoby doprowadzić do sytuacji, w której połączenie zostaje zerwane jedynie w celu
wykonania etapu uwierzytelniania i podłączenia do nowego punktu dostępowego. W tym
przypadku byłoby możliwe wyzwolenie sekwencji roamingu przez wyniki sondowania łącza
prowadzonego przez równoległy interfejs.
3.3.1
Decyzje projektowe
Wstępne decyzje projektowe formułuję w postaci rozwinięcia wymagań:
– W1: Rozwiązanie wykorzystuje dwa stosy protokołu IEEE802.11,
– W1a: Stos sondujący odpowiada za nieustanne przeprowadzanie etapu sondowania łącza,
– W1b: Stos połączeniowy odpowiada za etapy uwierzytelniania i podłączenia oraz
służy wymianie ramek typu Data,
– W2: Stosy protokołów IEEE802.11 są odseparowane w sensie modelu OSI posiadając
wspólną jednostkę SME,
– W3: Jednostka SME podejmuje decyzje o zerwaniu i rozpoczęciu stanu uwierzytelnienia
oraz podłączenia,
– W4: Jednostka SME podejmuje decyzje na bazie wyników sondowania łącza w postaci
listy punktów dostępowych,
32
– W5: Stosy protokołów IEEE802.11 sterowane są wiadomościami interfejsu SAP jednostki MLME.
Wiadomości interfejsu SAP jednostki MLME, których używam w projekcie zawarłem w
Tab. 3.1.
Tablica 3.1: Wiadomości interfejsu SAP jednostki MLME.
Skrót
Nazwa
Opis
MlmeScanReq
MLME-SCAN.request
Zlecenie etapu sondowania łącza.
MlmeScanCon
MLME-SCAN.confirm
Zwrócenie
wyników
sondowania łącza.
MlmeAuthReq
MLME-AUTHENTICATE.request
Zlecenie porozumienia
wstępnego uwierzytelnienia.
MlmeAuthCon
MLME-AUTHENTICATE.confirm
Zwrócenie wyniku porozumienia wstępnego
uwierzytelnienia.
MlmeDeauthReq
MLME-DEAUTHENTICATE.request
Zlecenie zerwania uwierzytelnienia stacji.
MlmeDeauthCon
MLME-DEAUTHENTICATE.confirm
Zwórcenie wyniku zerwania uwierzytelnienia
stacji.
MlmeAssocReq
MLME-ASSOCIATE.request
Zlecenie podłączenia do
punktu dostępowego.
MlmeAssocCon
MLME-ASSOCIATE.confirm
Zwrócenie wyniku podłączenia do punktu dostępowego.
MlmeDisassocReq
MLME-DISASSOCIATE.request
Zlecenie zerwania połączenia z punktem dostępowym.
MlmeDisassocCon MLME-DISASSOCIATE.confirm
3.3.2
Zwrócenie wyniku zerwania połączenia z
punktem dostępowym.
Projekt jednostki zarządzającej SME
Jednostki zarządzające sprowadzam do klas obiektów o określonym interfejsie. Zakładam,
iż jednostki zarządzające MLME istnieją w postaci komponentów zgodnych ze standardem
IEEE802.11. Moim celem jest wykonanie projektu jednostki SME, która sterowałaby zachowaniem niższych warstw w sposób umożliwiający działanie wyzwalania przez sondowanie. Na
bazie decyzji projektowych opracowuję następującą listę odpowiedzialności SME :
33
– O1: Wysyłanie wiadomości typu request z Tab. 3.1,
– O2: Odbieranie wiadomości typu confirm z Tab. 3.1,
– O3: Wykonywanie algorytmu wyboru punktu dostępowego z listy punktów dostępowych.
Łatwo zauważyć, że zachowanie jednostki SME zależy od odpowiedzi MLME na wiadomości request. Jedyną odpowiedzialnością, którą warto wyróżnić na etapie projektu analitycznego jest algorytm wyboru punktu dostępowego. Algorytm wyboru punktu dostępowego
sprowadzam do wywołania metody ChooseAP.
Projekt interakcji między jednostkami zarządzającymi wymaga specyfikacji zachowań jakich oczekuje się od danego stosu protokołu IEEE802.11. W przypadku wyzwalania przez
sondowanie należy rozpatrzyć zachowanie dwu stosów. Na etapie projektu analitycznego niniejszego rozwiązania przydatnym narzędziem jest diagram interakcji między jednostkami
zarządzającymi Rys. 3.2. Diagram przedstawia sytuację, w której wynik wywołania procedury ChooseAP powoduje wyzwolenie sterowania jednostką MLME-Conn. Celem sterowania
jest rozwiązanie istniejących połączeń interfejsu oraz rozpoczęcie etapu podłączenia i uwierzytelnienia w nowym punkcie dostępowym.
Zachowanie stosu IEEE802.11 odpowiedzialnego za sondowanie łącza
Stos odpowiedzialny za sondowanie łącza znajduje się pod kontrolą jednostki zarządzającej, którą będę dalej nazywał MLME-Scan. Jednostka MLME-Scan powinna być pobudzana
do okresowego wykonywania procedury sondowania łącza. Po zakończeniu procedury SME
otrzymuje listę punktów dostępowych. Lista punktów dostępowych jest parametrem wejściowym metody ChooseAP wywoływanej bezpośrednio po otrzymaniu wyników sondowania
łącza. Jeśli wybrany punkt dostępowy jest inny niż aktualny, należy rozpocząć sekwencję
roamingu. W przeciwnym przypadku procedura sondowania łącza powinna być zlecona ponownie.
Zachowanie stosu IEEE802.11 odpowiedzialnego za połączenie
Stos odpowiedzialny za połączenie znajduje się pod kontrolą jednostki zarządzającej, którą
będę dalej nazywał MLME-Conn. Stos ten odpowiedzialny jest za wymianę danych z resztą
modelu OSI oraz przeprowadzanie procedury podłączenia i uwierzytelnienia z punktem dostępowym. Jednostka SME nigdy nie zleca jednostce MLME-Conn wykonania procedury
sondowania łącza. Jednostka MLME-Conn kontrolowana jest tylko, gdy wyniki metody ChooseAP wymuszają zmianę aktualnego punktu dostępowego. Jednostka SME zleca rozwiązanie
połączenia z aktualnym punktem dostępowym i wykorzystuje wynik metody ChooseAP do
zlecenia procedury podłączenia i uwierzytelnienia.
34
MLME Sondujący
SME
MLME Połączeniowy
Pętla sondowania łącza:
MlmeScanReq
MlmeScanCon
ChooseAP
Poniższa procedura jest wykonywana, jeśli wybrano punkt dostępowy inny niż aktualny.
Jeśli stacja jest w stanie uwierzytelnienia, należy go rozwiązać.
MlmeDeauthReq
MlmeDeauthCon
Jeśli stacja jest podłączona, należy zerwać połączenie.
MlmeDisassocReq
MlmeDisassocCon
Należy rozpocząć etap uwierzytelnienia ...
MlmeAuthReq
MlmeAuthCon
... oraz podłączenia do nowego punktu dostępowego.
MlmeAssocReq
MlmeAssocCon
Rysunek 3.2: Interakcja jednostek zarządzających.
35
Rozdział 4
Implementacja modeli interfejsów
równoległych w strukturach INET
Niniejszy rozdział opisuje implementację rozwiązania interfejsów równoległych. Implementacja bazuje na projekcie wyzwalania przez sondowanie przedstawionym w rozdziale 3. Zgodnie z celem pracy, środowiskiem implementacji rozwiązania są struktury INET. Struktury
INET zawierają zestaw modeli przeznaczonych do symulacji działania sieci komunikacyjnych. Decyzja o wyborze struktur INET w implementacji rozwiązania zapadła, ze względu
na następujące zalety:
– Licencja typu open-source umożliwiająca łatwe modyfikacje kodu,
– Udokumentowaną zgodność z opartym o środowisko Eclipse symulatorem OMNet++,
– Udokumentowaną zdolność modeli standardu IEEE802.11 do przeprowadzenia sekwencji roamingu,
– Bogatym zestawem modeli wyższych warstw OSI pozwalającym na szeroki zakres
symulacji wpływu zjawiska roamingu w standardzie IEEE802.11.
Docelowym środowiskiem uruchomieniowym jest symylator OMNet++. Rozdział tłumaczy decyzje implementacyjne związane z umiejscowieniem rozwiązania w strukturach modeli
INET. Za kluczowe uważam utrzymanie świadomości czytelnika co do wpływu implementacji
modelu na działanie rzeczywistego odpowiednika rozwiązania.
4.1
Struktura modeli INET
Decyzja projektowa dotycząca traktowania jednostek MLME jako istniejących komponentów posiadających zdefiniowany interfejs SAP wymusza zastosowanie gotowego zestawu
modeli zgodnych ze standardem IEEE802.11. Konsekwencje implementacyjne takiego podejścia oceniam analizując stos protokołu IEEE802.11 z punktu widzenia rzeczywistej architektury systemów komputerowych. Tab. 4.1 przedstawia warstwy rzeczywistej architektury
36
systemu, które mają potencjał przejęcia funkcjonalności określonych poziomów stosu protokołu IEEE802.11.
Tablica 4.1: Architektura warstwowa protokołu IEEE802.11.
Standard IEEE802.11
System komputerowy
SME
Aplikacja przestrzeni użytkownika (np. NetworkManager w dystrybucjach systemu
Linux )
MAC, MLME
Sterownik urządzenia bezprzewodowego i jego interfejs
PHY, PLME
Firware urządzenia bezprzewodowego i jego interfejs
Kolejnym krokiem jest dopasowanie modeli INET będących odpowiednikami przedstawionych poziomów architektury warstwowej. Modele są w tym przypadku zestawem klas w
sensie języka C++. W strukturach INET pliki źródłowe klas mogą tworzyć moduły będące
podmiotami relacji połączenia lub zawierania się. Moduły są podstawowym budulcem warstwowej architektury modeli INET. Do opisu relacji oraz parametrów modułów służą pliki
NED (ang. network description file). Parametryzacja plików NED odbywa się z pomocą
dodatkowego pliku tekstowego w formacie INI.
Za realizację stosu protokołu IEEE802.11 odpowiada moduł Ieee80211Nic Rys. 4.1. Moduł Ieee80211Nic modeluje elementy interfejsu bezprzewodowej karty sieciowej od fizycznej
anteny po SAP udostępniany warstwie stosu OSI.
agent
Rysunek 4.1: Moduł Ieee80211Nic.
37
Element radio odpowiada modułowi Radio modelującemu błędy, spadek mocy sygnału
oraz siłę anteny. Element mac odpowiada modułowi Ieee80211Mac modelującemu warstwę
dostępu do łącza danych. Element mgmt zajmuje się reakcją na ramki zarządzające i odpowiada określonemu modułowi w zależności od trybu pracy urządzenia:
– Ieee80211MgmtSTA - tryb stacji klienckiej,
– Ieee80211MgmtAP - tryb punktu dostępowego.
Element agent odpowiada modułowi Ieee80211AgentSTA i jest konieczny wyłącznie do
prawidłowego działania modułu Ieee80211MgmtSTA. Moduł Ieee80211AgentSTA odpowiada
za odpowiednie wykorzystanie usług mgmt. Łatwo zauważyć pewne podobieństwo w odpowiedzialnościach poszczególnych modułów i podmienić kolumnę system komputerowy Tab.
4.1 kolumną odpowiadającą strukturom modeli INET Tab. 4.2.
Tablica 4.2: Architektura warstwowa protokołu IEEE802.11.
4.2
Standard IEEE802.11
INET
SME
Ieee80211AgentSTA
MAC, MLME
Ieee80211Mac,
Ieee80211MgmtSTA
PHY, PLME
Radio, Ieee80211Radio
Implementacja rozwiązania wyzwalania przez sondowanie
W celu opisu implementacji rozwiązania stosuję podejście zstępujące (ang. top-down approach), które ułatwia przedstawienie procesu realizacji na tle struktur modeli symulacyjnych
oraz plików konfiguracyjnych. Zmiany wprowadzane w strukturach INET ograniczają się do
modułu stacji klienckiej WirelessHost Rys. 4.2. Moduł ten reprezentuje fizyczne urządzenie posiadające interfejsy NIC oraz komponenty symulujące zachowanie wyższych warstw
modelu OSI. Interfejsy NIC mają postać tablic i stanowią kanały wymiany wiadomości z
pozostałą częścią symulowanej sieci. Moduł WirelessHost modeluje zachowanie warstwy sieciowej. Warstwa transportowa reprezentowana jest przez moduły implementujące protokół
UDP, TCP oraz SCTP. Moduły warstwy transportowej pozwalają na bezpośrednie podłączenie generatorów wiadomości symulujących zachowanie odpowiednich aplikacji.
Interesującym z punktu widzenia wprowadzanych zmian jest element wlan[numRadios]
reprezentujący zestaw interfejsów NIC komunikacji bezprzewodowej. Wszystkie przykładowe symulacje z udziałem modułu WirelessHost korzystają z pojedynczego interfejsu
Ieee80211Nic.
38
WirelessHost
Wyższe warstwy modelu OSI
Interfejsy NIC
Ieee80211Nic
wlan[numRadios]
Rysunek 4.2: Moduł WirelessHost.
W celu inspekcji definicji elementu wlan[numRadios] odwołuję się do listingu 4.1 przedstawiającego fragment pliku NED klasy bazowej NodeBase. Definicja elementu wlan[numRadios]
jest parametryczna. Elementem tablicy wlan[numRadios] może być dowolny moduł implementujący interfejs IWirelessNic. Brak specyfikacji w pliku konfiguracyjnym oznacza użycie
modułu Ieee80211Nic. Właściwość @display definiuje metadane związane z wyświetlaniem
elementu na diagramach symulatora OMNet++.
Listing 4.1: Fragment pliku NodeBase.ned
1
3
wlan [ numRadios ] : <d e f a u l t ( ” I e e e 8 0 2 1 1 N i c ”)> l i k e I W i r e l e s s N i c {
parameters :
@ d i s p l a y ( ”p =216 ,406 , row , 6 0 ; q=queue ” ) ;
}
Realizacja interfejsów równoległych opiera się o implementację dodatkowych modułów
NIC :
– Ieee80211ScanNic: stos sondujący protokołu IEEE802.11,
– Ieee80211CommNic: stos połączeniowy protokołu IEEE802.11.
Przygotowane w ten sposób moduły można wykorzystać przy konfiguracji WirelessHost
używając wzorca typename. Przedstawiony listing 4.2 pliku INI demonstruje konfigurację
stacji klienckiej host wykorzystującej przygotowane interfejsy równoległe. Należy pamiętać o
prawidłowej inicjalizacji parametru numRadios odpowiadającego za rozmiar tablicy interfejsów bezprzewodowych wlan[numRadios].
Listing 4.2: Konfiguracja interfejsów NIC modułu WirelessHost
2
∗ ∗ . h o s t . numRadios = 2
∗ ∗ . h o s t . wlan [ 0 ] . typename = ” I e e e 8 0 2 1 1 S c a n N i c ”
∗ ∗ . h o s t . wlan [ 1 ] . typename = ” Ieee80211CommNic ”
39
Zgodnie z projektem interfejsy równoległe powinny posiadać wspólną jednostkę SME.
Na Tab. 4.2 jednostce SME odpowiada moduł Ieee80211AgentSTA. W przypadku modułu
Ieee80211MgmtSTA element agent jest niezbędny ze względu na sterowanie logiką zachowania
stosu stacji klienckiej. Kluczową częścią implementacji jest hierarchia klas reprezentujących
moduły typu agent. Instancja wybranej klasy z hierarchii modułów typu agent zostaje wybrana do sterowania interfejsem NIC, który zostaje włączony do stacji klienckiej host zgodnie
ze schematem przedstawionym na listingu 4.2. Implementacja pary rozdzielnych modułów
agent pozwala na wprowadzenie pewnej abstrakcji w jednostce SME. Z punktu widzenia
rzeczywistej architektury rozdzielne moduły agent mogą być procesami oraz wątkami pojedynczego systemu komputerowego lub nawet rezydować na różnych maszynach. Komunikaty
uznaję za aspekt systemu komputerowego wykraczający poza zakres modeli symulacyjnych.
W celu zestawienia komunikacji stosuję udostępniany przez symulator OMNet++ mechanizm
sygnałów. Mechanizm sygnałów jest pomocniczym narzędziem środowiska symulacyjnego i
nie wpływa na wyniki pomiarów. Hierarchię klas modułów typu agent stworzoną na potrzeby
tej pracy przedstawia schemat Rys. 4.3.
Klasa bazowa Ieee80211AgentBaseSTA zawiera wszystkie wspólne części implementacji
klas Ieee80211AgentCommSTA oraz Ieee80211AgentScanSTA. Klasa bazowa służy porządkowaniu kodu oraz implementacji metod pomocniczych. Klasa Ieee80211AgentCommSTA
steruje zachowaniem stosu Ieee80211CommNic. Klasa Ieee80211AgentScanSTA steruje zachowaniem stosu Ieee80211ScanNic. Klasa Ieee80211AgentScanHystSTA dziedziczy bezpośrednio
po klasie Ieee80211AgentScanSTA. Poszerzam logikę metody chooseBSS odpowiedzialnej za
wybór najlepszego punktu dostępowego z listy dostępnych. Celem poszerzenia jest wprowadzenie mechanizmu histerezy w procesie wyboru punktu dostępowego. Nowa metoda jest
ściśle dedykowana do zastosowania w rozwiązaniu prezentowanym w niniejszej pracy.
Dodatkowo, przedstawiam tabelę z odpowiednikami wiadomości interfejsów SAP w strukturze INET. Przedstawione nazwy odpowiadają klasom w sensie języka C++. Klasy te modelują wiadomości interfejsu SAP. Tab. 4.3 służy do implementacji projektu sekwencji komunikacji między jednostkami zarządzającymi w strukturze INET.
40
Ieee80211AgentBaseSTA
Ieee80211AgentConnSTA
Ieee80211AgentScanSTA
sendAuthenticateRequest(...)
sendAssociateRequest(...)
processAuthenticateConfirm(...)
processAssociateConfirm(...)
sendScanRequest(...)
processScanConfirm(...)
chooseBSS(...)
Ieee80211AgentScanHystSTA
sendScanRequest(...)
processScanConfirm(...)
chooseBSS(...)
Rysunek 4.3: Hierarchia klas modułów typu agent.
Tablica 4.3: Odpowiedniki wiadomości SAP-MLME w strukturze INET.
SAP-MLME
INET
MLME-SCAN.request
Ieee80211Prim ScanRequest
MLME-SCAN.confirm
Ieee80211Prim ScanConfirm
MLME-AUTHENTICATE.request
Ieee80211Prim AuthenticateRequest
MLME-AUTHENTICATE.confirm
Ieee80211Prim AuthenticateConfirm
MLME-DEAUTHENTICATE.request
Ieee80211Prim DeauthenticateRequest
MLME-DEAUTHENTICATE.confirm
Ieee80211Prim DeauthenticateConfirm
MLME-ASSOCIATE.request
Ieee80211Prim AssociateRequest
MLME-ASSOCIATE.confirm
Ieee80211Prim AssociateConfirm
MLME-DISASSOCIATE.request
Ieee80211Prim DisassociateRequest
MLME-DISASSOCIATE.confirm
Ieee80211Prim DisassociateConfirm
41
4.2.1
Niezbędne modyfikacje modułu Ieee80211MgmtSTA
Moduł Ieee80211MgmtSTA posiada pewne ograniczenia, które nie pozwalają na spełnienie
wymagań projektowych. Podczas implementacji spotkałem się z następującymi problemami:
– Moduł Ieee80211MgmtSTA nie pozwala na podłączenie i uwierzytelnienie w punkcie
dostępowym, który nie został wcześniej odnaleziony na etapie sondowania,
– Moduł Ieee80211MgmtSTA generuje rozgłoszeniowe komunikaty, które nie specyfikują
nadawcy,
– Moduł Ieee80211MgmtSTA rozwiązuje połączenie z punktem dostępowym jedynie poprzez rozpoczęcie procedury sondowania łącza.
Modyfikacje na poziomie MLME odpowiadają zmianom sterowników urządzeń interfejsów bezprzewodowych. Należy zwrócić uwagę, iż powyższe ograniczenia dotyczą modeli
symulacyjnych i nie muszą odzwierciedlać niuansów implementacji rzeczywistych sterowników. W celu umożliwienia realizacji wymagań projektowych dokonałem modyfikacji modułu
Ieee80211MgmtSTA.
Skrośna aktualizacja listy punktów dostępowych
Zestawiłem skrośny kanał komunikacji między modułem Ieee80211AgentScanSTA oraz
modułem Ieee80211MgmtSTA podlegającym kontroli jednostki Ieee80211AgentCommSTA.
Kanał komunikacji ma postać sygnału apList. Listing 4.3 przedstawia definicję oraz rejestrację
sygnału apList. Zmienna apListSignal jest statycznym polem klasy Ieee80211AgentScanSTA.
Nadanie wartości SIMGIGNAL NULL jest konieczne, gdyż zmienna apListSignal jest polem
statycznym klasy, a właściwa rejestracja sygnału ma miejsce dopiero w trakcie inicjalizacji.
Inicjalizacja jest procesem wieloetapowym i zależy od innych modułów środowiska. Nazwa
apList jest identyfikatorem ID sygnału używanym w procesie subskrypcji.
Listing 4.3: Definicja i rejestracja sygnału apList.
1
3
s i m s i g n a l t Ieee80211AgentScanSTA : : a p L i s t S i g n a l = SIMSIGNAL NULL ;
/∗ . . . ∗/
apListSignal = r e g i s t e r S i g n a l (” apList ” ) ;
Emisja sygnału apList przedstawiona na listingu 4.4 ma miejsce po zakończeniu procedury sondowania łącza. Wiadomość typu Ieee80211Prim ScanConfirm zawiera listę punktów
dostępowych. Wiadomość jest przekazywana z modułu Ieee80211MgmtSTA podlegającego
kontroli jednostki Ieee80211AgentScanSTA, która zleciła sondowanie łącza. Wiadomość typu
Ieee80211Prim ScanConfirm jest rzutowana do klasy bazowej cObject w celu przesłania razem z sygnałem apList.
42
Listing 4.4: Emisja sygnału apList.
1
3
5
void Ieee80211AgentScanSTA : :
processScanConfirm ( Ieee80211Prim ScanConfirm ∗ resp )
{
/∗ ∗@hary : Emit d i s c o v e r e d AP l i s t t o Ieee80211AgentConnSTA MGMT l a y e r ∗/
emit ( a p L i s t S i g n a l , ( c O b j e c t ∗ ) r e s p ) ;
/∗ . . . ∗/
Utworzyłem dodatkowy parametr konfiguracyjny pliku Ieee80211MgmtSTA.ned o nazwie
acceptApList. Listing 4.5 przedstawia definicję parametru acceptApList typu całkowitego.
Jeśli parametr nie jest użyty w pliku INI to inicjalizowany jest wartością zero.
Listing 4.5: Parametr acceptApList.
int acceptApList = default ( 0 ) ;
Listing 4.6 przedstawia fragment pliku konfiguracyjnego INI odpowiedzialny za nadanie
parametrowi acceptApList wartości różnej od zera. W tym przypadku konfiguracja wymusi
na module Ieee80211MgmtSTA podlegającym kontroli jednostki Ieee80211AgentCommSTA
(zgodnie z definicją 4.2) subskrybcję sygnału apList.
Listing 4.6: Nadanie wartości parametrowi acceptApList.
1
∗ ∗ . h o s t . wlan [ 1 ] . mgmt . a c c e p t A p L i s t = 1
Nadanie wartości różnej od zera powoduje, że moduł Ieee80211MgmtSTA sunskrybuje
sygnał apList. Listing 4.7 przedstawia fragment kodu odpowiedzialnego za subskrypcję sygnału apList. Konieczna jest subskrypcja w module będącym u szczytu hierarchii, gdyż sygnał
przekazywany jest skrośnie.
Listing 4.7: Subskrypcja sygnału apList.
1
3
5
7
/∗ ∗@hary : C o n f i g u r e MGMT t o a c c e p t AP l i s t c r o s s −update ∗/
void Ieee80211MgmtSTA : : a c c e p t A p L i s t S i g n a l ( ) {
s i m u l a t i o n . getSystemModule()−> s u b s c r i b e ( ” a p L i s t ” , t h i s ) ;
}
/∗ . . . ∗/
i f ( ( i n t ) par ( ” a c c e p t A p L i s t ” ) != 0 )
acceptApListSignal ( ) ;
W reakcji na otrzymanie sygnału apList moduł Ieee80211MgmtSTA czyści lokalną listę punktów dostępowych i używa zawartości wiadomości typu Ieee80211Prim ScanConfirm
do wypełnienia nowej listy symulując zakończenie etapu sondowania łącza. Listing 4.8
przedstawia kod źródłowy metody receiveSignal odpowiedzialnej za aktualizację listy punktów dostępowych. Makro Enter Method Silent() wskazuje, iż dana metoda może być wołana z poziomu innych modułów oraz, że jej wywołanie nie będzie animowane w GUI symulatora. Niezbędne jest rzutowanie obiektu otrzymanego razem z sygnałem apList na
typ Ieee80211Prim ScanConfirm. Obiekt klasy Ieee80211Prim ScanConfirm posiada metodę
43
getBssListArraySize(), której używam do określenia zasięgu iteracji po liście punktów dostępowych. Zmienna apList jest polem klasy Ieee80211MgmtSTA zawierającym listę obiektów
typu APInfo. Klasa APInfo reprezentuje informacje o punkcie dostępowym odnalezionym na
etapie sondowania łącza. Wykorzystując metodę getBssList(...) sięgam po kolejne obiekty
typu Ieee80211Prim BssDescription. Pola obiektów typu Ieee80211Prim BssDescription
służą mi do uzupełniania kolejnych instacji klasy ApInfo.
Listing 4.8: Skrośna aktualizacja listy punktów dostępowych
1
3
/∗ ∗@hary : Manage s i g n a l s ∗/
void Ieee80211MgmtSTA : :
r e c e i v e S i g n a l ( cComponent∗ s o u r c e , s i m s i g n a l t s i g n a l I D , c O b j e c t ∗ o b j ) {
5
Enter Method Silent ( ) ;
7
APInfo ∗ ap ;
clearAPList ( ) ;
9
Ieee80211Prim ScanConfirm ∗ resp = ( Ieee80211Prim ScanConfirm ∗) obj ;
11
for ( i n t i =0; i <( i n t ) r e s p −>g e t B s s L i s t A r r a y S i z e ( ) ; i ++) {
a p L i s t . push back ( APInfo ( ) ) ;
ap = &a p L i s t . back ( ) ;
13
15
I e e e 8 0 2 1 1 P r i m B S S D e s c r i p t i o n& b s s D e s c = r e s p −>g e t B s s L i s t ( i ) ;
ap−>c h a n n e l = b s s D e s c . getChannelNumber ( ) ;
ap−>a d d r e s s = b s s D e s c . getBSSID ( ) ;
ap−>s s i d = b s s D e s c . getSSID ( ) ;
ap−>b e a c o n I n t e r v a l = b s s D e s c . g e t B e a c o n I n t e r v a l ( ) ;
ap−>rxPower = b s s D e s c . getRxPower ( ) ;
17
19
21
}
23
}
Powiązanie modułów agent oraz mgmt identyfikatorem ID
Dodałem dodatkowe parametry konfiguracyjne do plików NED:
– Plik Ieee80211MgmtSTA.ned : parametr mgmtID,
– Plik Ieee80211AgentBaseSTA.ned : parametr agentID.
Skojarzenie modułów należących do tego samego stosu protokołu IEEE802.11 odbywa
się poprzez nadanie odpowienich wartości korzystając z pliku INI. Listing 4.9 przedstawia
kontynuację konfiguracji 4.2. Moduły znajdujące się na tym samym stosie powinny mieć
równe wartości parametrów mgmtID oraz agentID.
44
Listing 4.9: Identyfikacja modułów agent oraz mgmt.
1
3
∗ ∗ . h o s t . wlan [ 0 ] . mgmt . mgmtID =
∗ ∗ . h o s t . wlan [ 0 ] . a g e n t . agentID
∗ ∗ . h o s t . wlan [ 1 ] . mgmt . mgmtID =
∗ ∗ . h o s t . wlan [ 1 ] . a g e n t . agentID
0
= 0
1
= 1
Wartości identyfikatorów wykorzystuję w kodzie modułów do oznaczania wiadomości rozgłoszeniowych. Listing 4.10 przedstawia wysłanie wiadomości o utraceniu ustalonej ilości ramek typu Beacon. Łatwo zauważyć, iż twórcy kodu INET są w trakcie implementacji oznaczania wiadomości rozgłoszeniowych. Wiadomość zostaje wysłana z modułu Ieee80211MgmtSTA
i opatrzona odpowiednim identyfikatorem mgmtID. Metoda par(...) służy do opakowania wartości parametru mgmtID w obiekt typu cPar.
Listing 4.10: Wysyłanie oznaczonej wiadomości rozgłoszeniowej NF L2 BEACON LOST.
2
/∗ ∗@hary : Use ID from INI f o r MGMT d i f f e r e n t i a t i o n ∗/
nb−>f i r e C h a n g e N o t i f i c a t i o n (NF L2 BEACON LOST , &par ( ”mgmtID” ) ) ;
//XXX u s e I n t e r f a c e E n t r y a s d e t a i l , e t c . . .
Odebranie wiadomości rozgłoszeniowej w module agent wymaga dodatkowo porównania
jej identyfikatora z wartością agentID. Listing 4.11 przedstawia różnicowanie odebranych
wiadomości na podstawie identyfikatorów. Makro Enter Method Silent() wskazuje, iż dana
metoda może być wołana z poziomu innych modułów oraz, że jej wywołanie nie będzie
animowane w GUI symulatora. Niezbędne jest rzutowanie wartości details na wkaźnik do
obiektu typu cPar. Wyłuskanie wskaźnika powoduje zwrócenie wartości o prawidłowym typie.
Listing 4.11: Rozróżnienie wiadomości rozgłoszeniowej według identyfikatora ID.
2
void Ieee80211AgentScanSTA : :
r e c e i v e C h a n g e N o t i f i c a t i o n ( i n t c a t e g o r y , const c O b j e c t ∗ d e t a i l s ) {
4
Enter Method Silent ( ) ;
6
i f ( c a t e g o r y == NF L2 BEACON LOST) {
/∗ ∗@hary : Added MGMT d i f f e r e n t i a t i o n f o r multi −i n t e r f a c e modules ∗/
i f ( d e t a i l s != NULL) {
i n t mgmtID = ∗ ( ( cPar ∗ ) d e t a i l s ) ;
i f (mgmtID == agentID ) {
/∗ . . . ∗/
8
10
Rozwiązanie połączenia z punktem dostępowym w skutek żądania uwierzytelnienia
Niezbędne jest zerwanie połączenia modułu Ieee80211MgmtSTA przed kontynuacją uwierzytelniania. Listing 4.12 przedstawia wywołanie metody disassociate() w ramach odbierania
wiadomości Ieee80211Prim AuthenticateRequest. Metoda disassociate() wprowadza moduł
Ieee80211MgmtSTA w stan umożliwiający kontynuację procesu uwierzytelniania i podłączania do innego punktu dostępowego.
45
Listing 4.12: Zerwanie połączenia modułu Ieee80211MgmtSTA w skutek zlecenia uwierzytelniania.
1
3
5
7
void Ieee80211MgmtSTA : :
processAuthenticateCommand ( I e e e 8 0 2 1 1 P r i m A u t h e n t i c a t e R e q u e s t ∗ c t r l )
{
/∗ ∗@hary : MGMT l e v e l d i s s a s o c i a t i o n − b e c a u s e we a r e not s c a n n i n g ∗/
if ( isAssociated )
disassociate ();
/∗ . . . ∗/
4.2.2
Implementacja modułu Ieee80211AgentScanSTA
Moduł Ieee80211AgentScanSTA ma następujące odpowiedzialności:
– Wysyłanie żądania rozpoczęcia sondowania łącza,
– Odbieranie wyników sondowania łącza,
– Wybór punktu dostępowego z listy punktów dostępowych,
– Wymuszanie etapu podłączenia i uwierzytelniania.
Pierwsze żądanie sondowania łącza wysyłane jest po czasie równym wartości parametru
startingTime. Jeśli parametr ten nie jest użyty w pliku INI to pierwsze żądanie wysyłane jest
po losowym czasie o rozkładzie jednostajnym w przedziale (0, maxChannelT ime). Listing
4.13 przedstawia fragment metody initialize(...) odpowiedzialnej za wstępną inicjalizację
parametrów modułu. Metoda scheduleAt(...) służy do wysłania wiadomości zwrotnej (ang.
self-message) po wyznaczonym czasie. Konstruktor wiadomości typu cMessage korzysta z
argumentów odpowiadających nazwie oraz rodzajowi komunikatu.
Listing 4.13: Ustalanie czasu uruchomienia procedury sondowania łącza.
1
3
5
i f ( par ( ” s t a r t i n g T i m e ” ) . d o u b l e V a l u e () >0)
s c h e d u l e A t ( simTime ()+ par ( ” s t a r t i n g T i m e ” ) . d o u b l e V a l u e ( ) ,
new cMessage ( ” s t a r t U p ” , MK STARTUP ) ) ;
else
s c h e d u l e A t ( simTime ()+ u ni for m ( 0 , maxChannelTime ) ,
new cMessage ( ” s t a r t U p ” , MK STARTUP ) ) ;
Listing 4.14 przedstawia odebranie wiadomości MK STARTUP w tym samym module.
Metoda handleTimer(...) wywoływana jest przez przeciążoną metodę handleMessage(...).
Metoda handleMessage(...) wywoływana jest każdorazowo, gdy moduł otrzymuje wiadomość.
Metoda handleTimer(...) jest w tym przypadku wywoływana tylko dla wiadomości zwrotnych.
46
Listing 4.14: Ustalanie czasu uruchomienia procedury sondowania łącza.
2
4
6
void Ieee80211AgentScanSTA : : handleTimer ( cMessage ∗msg )
{
i f ( msg−>getKind ()==MK STARTUP)
{
EV << ” S t a r t i n g up\n” ;
sendScanRequest ( ) ;
/∗ . . . ∗/
Metoda
sendScanRequest()
polega
na
utworzeniu
instancji
klasy
Ieee80211Prim ScanRequest i wysłaniu jej do modułu Ieee80211MgmtSTA. Wysłanie wiadomości Ieee80211Prim ScanRequest inicjalizuje pętle sondowania łącza. Zakończywszy sondowanie łącza moduł Ieee80211MgmtSTA odpowiada wiadomością
Ieee80211Prim ScanConfirm. Symulator ponownie wykorzystuje przeciążoną metodę modułu
handleMessage(...). Przepływ sterowania zostaje przekierowany do metody processScanConfirm(...). Listing 4.15 obrazuje ponowne zlecenie procedury sondowania łącza. Metoda
chooseBSS zawiera algorytm wyboru punktu dostępowego z listy punktów dostępowych
otrzymanych w wyniku sondowania. Zastosowano algorytm dostępny w źródłach projektu
INET owocujący zwróceniem punktu dostępowego o najwyższej sile sygnału. Wynikiem jest
indeks, który pozwala pobrać opis punktu dostępowego z pomocą metody getBssList(...).
Klasa Ieee80211Prim BSSDescription opakowuje informacje o wybranym punkcie dostępowym. Zamiast kontynuacji sekwencji roamingu moduł Ieee80211AgentScanSTA zapamiętuje
wybrany punkt dostępowy jako aktualnie najlepszy w zmiennej bestAP. Aktualnie najlepszy punkt dostępowy bestAP przekazywany jest modułowi Ieee80211AgentCommSTA z
pomocą sygnału forceAuth. Po emisji sygnału forceAuth moduł kontynuuje wykonanie pętli
sondowania łącza.
Listing 4.15: Kontynuacja pętli sondowania łącza.
1
3
5
7
void Ieee80211AgentScanSTA : : p r o c e s s S c a n C o n f i r m ( I e e e 8 0 2 1 1 P r i m S c a n C o n f i r m ∗ r e s p )
{
/∗ . . . ∗/
b s s I n d e x = chooseBSS ( r e s p ) ;
/∗ . . . ∗/
I e e e 8 0 2 1 1 P r i m B S S D e s c r i p t i o n& b s s D e s c = r e s p −>g e t B s s L i s t ( b s s I n d e x ) ;
EV << ” Chosen AP a d d r e s s=” << b s s D e s c . getBSSID ( )
<< ” from l i s t , s t a r t i n g a u t h e n t i c a t i o n \n” ;
9
/∗ ∗@hary : I m m i d i a t e l y f o r c e a u t h e n t i c a t e t o b e t t e r AP∗/
// s e n d A u t h e n t i c a t e R e q u e s t ( b s s D e s c . getBSSID ( ) ) ;
bestAP = b s s D e s c . getBSSID ( ) ;
emit ( f o r c e A u t h S i g n a l , ( c O b j e c t ∗)(& bestAP ) ) ;
/∗ ∗@hary : Continue s c a n n i n g ∗/
sendScanRequest ( ) ;
11
13
15
}
47
4.2.3
Implementacja modułu Ieee80211AgentCommSTA
Moduł Ieee80211AgentCommSTA ma następujące odpowiedzialności:
– Podłączenie i uwierzytelnienie w punkcie dostępowym,
– Wymiana ramek typu Data zgodnie z modelem OSI.
Na etapie inicjalizacji moduł Ieee80211AgentCommSTA subskrybuje sygnał forceAuth.
Listing 4.16 przedstawia subskrybcję sygnału forceAuth w systemowym module nadrzędnym.
Subskrypcja musi być dokonana w module będącym u szczytu hierarchi, gdyż sygnał przekazywany jest skrośnie.
Listing 4.16: Subskrybcja sygnału forceAuth.
s i m u l a t i o n . getSystemModule()−> s u b s c r i b e ( ” f o r c e A u t h ” , t h i s ) ;
Klasa modułu Ieee80211AgentCommSTA wykorzystuje dwie zmienne typu MACAddress
do śledzenia wykorzystywanych punktów dostępowych:
– Zmienna prevAP zawiera adres poprzedniego punktu dostępowego,
– Zmienna currAP zawiera adres aktualnego punktu dostępowego.
Klasa MACAddress reprezentuje adres MAC interfejsu NIC. Zmienna typu MACAddress może przybierać wartość UNSCPECIFIED ADDRESS, która oznacza brak adresu. Użycie wartości UNSPECIFIED ADDRESS pomaga w określeniu stanu modułu
Ieee80211AgentCommSTA.
Odebranie sygnału forceAuth owocuje wywołaniem metody receiveSignal(...) przedstawionej na listingu 4.17. Makro Enter Method Silent() wskazuje, iż dana metoda może być wołana
z poziomu innych modułów oraz, że jej wywołanie nie będzie animowane w GUI symulatora.
Niezbędne jest rzutowanie otrzymanego razem z sygnałem obiektu na wskaźnik klasy MACAddress. Wskaźnik zostaje wyłuskany w celu otrzymania adresu MAC wybranego w module
Ieee80211AgentScanSTA punktu dostępowego. Metoda isUnspecified() wskazuje, czy istnieje
aktualny punkt dostępowy. Jeśli moduł Ieee80211AgentCommSTA nie wykorzystuje żadnego
punktu dostępowego lub zmienna bestAP zawiera inny adres niż aktualnie używany, należy
rozpocząć procedurę uwierzytelniania i podłączenia w nowym punkcie dostępowym.
Wywołanie
metody
sendAuthenticateRequest(...)
powoduje
wysłanie
wiaW
odpowiedzi
na
wiadomość
domości
Ieee80211Prim AuthenticateRequest.
Ieee80211Prim AuthenticateConfirm o pozytywnym rezultacie wysyłana jest wiadomość
Ieee80211Prim AssociateRequest. Odebranie wiadomości Ieee80211Prim AssociateConfirm
o pozytywnym rezultacie świadczy o powodzeniu próby podłączenia i uwierzytelnienia w
nowym punkcie dostępowym.
48
Listing 4.17: Odebranie sygnału forceAuth.
1
void Ieee80211AgentCommSTA : : r e c e i v e S i g n a l ( cComponent∗ s o u r c e ,
s i m s i g n a l t signalID , cObject ∗ obj ) {
3
Enter Method Silent ( ) ;
5
MACAddress bestAP = ∗ ( ( MACAddress ∗ ) o b j ) ;
7
/∗ ∗ @hary : A u t h e n t i c a t e t o new AP i f t h e r e i s no c u r r e n t AP
∗ o r b e t t e r AP i s not c u r r e n t AP
∗/
i f ( currAP . i s U n s p e c i f i e d ( ) | | ! currAP . e q u a l s ( bestAP ) ) {
currAP = bestAP ;
nb−>f i r e C h a n g e N o t i f i c a t i o n (NF L2 DISASSOCIATED , m y If a ce ) ;
s e n d A u t h e n t i c a t e R e q u e s t ( bestAP ) ;
}
9
11
13
15
}
Oczywiście, rezultat może być negatywny na dowolnym etapie. W przypadku negatywnego
rezultatu moduł Ieee80211AgentCommSTA nie inicjalizuje procedury sondowania łącza, lecz
oczekuje na kolejny sygnał forceAuth. Listing 4.18 obrazuje nadanie zmiennej currAP wartości
UNSPECIFIED ADDRESS co powoduje wprowadzenie modułu w stan oczekiwania.
Listing 4.18: Wprowadzenie modułu Ieee80211AgentCommSTA w stan oczekiwania na sygnał
forceAuth.
2
4
/∗ ∗@hary : Do not s t a r t s c a n n i n g − l e t go o f t h i s AP and
∗ w a i t f o r a n o t h e r s i g n a l from Ieee80211AgentScanSTA
∗/
currAP = currAP . UNSPECIFIED ADDRESS ;
4.2.4
Implementacja modułu Ieee80211AgentScanHystSTA
Odpowiedzialnością modułu Ieee80211AgentScanHystSTA jest wybór nowego punktu dostępowego z listy dostępnych wykorzystując mechanizm histerezy. Metoda chooseBSS(...)
otrzymuje na wejściu instancję klasy Ieee80211Prim ScanConfirm zawierającą listę punktów
dostępowych. Metoda zwraca liczbę całkowitą będącą indeksem wybranego punktu dostępowego na otrzymanej liście.
Algorytm rozpoczyna odnalezieniem na liście punktu dostępowego o największej mocy
nadawania. Listing 4.19 przedstawia pętlę przeglądającą. Metoda getBssListArraySize() służy
za warunek końcowy przeglądania. Metoda getBssList(...) klasy Ieee80211Prim ScanConfirm
zwraca instancję klasy Ieee80211Prim BSSDescription reprezentującą punkt dostępowy na
liście. Przy każdym wykonaniu pętla wykorzystuje metodę getRxPower() w celu wybrania
indeksu odpowiadającego punktowi o największej sile sygnału.
49
Listing 4.19: Odnalezienie punktu dostępowego o największej sile sygnału.
2
4
6
int bestIndex = 0;
for ( i n t i =0; i <( i n t ) r e s p −>g e t B s s L i s t A r r a y S i z e ( ) ; i ++) {
i f ( r e s p −>g e t B s s L i s t ( i ) . getRxPower ( ) >
r e s p −>g e t B s s L i s t ( b e s t I n d e x ) . getRxPower ( ) ) {
bestIndex = i ;
}
}
W kolejnym kroku algorytm sprawdza, czy stacja jest podłączona do dowolnego punktu
dostępowego. Jeśli stacja nie ma połączenia to mechanizm histerezy zostaje pominięty i priorytetem staje się związanie z odnalezionym punktem dostępowym. Listing 4.20 wykorzystuje wartość pola lastBest klasy Ieee80211Prim BSSDescription w celu sprawdzenia podłączenia do punktu dostępowego. Pole lastBest reprezentuje ostatnio wybrany punkt dostępowy. Metoda getBSSID() zwraca obiekt typu MACAddres. Obiekt MACAddrss o wartości
UNSPECIFIED ADDRESS oznacza, że ostatnio nie znaleziono żadnego punktu dostępowego. Algorytm zapamiętuje instancję znalezionego punktu dostępowego w postaci obiektu
klasy Ieee80211Prim BSSDescription. Indeks najlepszego punktu dostępowego zwracany jest
natychmiast w celu nawiązania połączenia.
Listing 4.20: Wybór punktu dostępowego z pominięciem histerezy.
1
3
5
/∗ I f s t a t i o n i s not c o n n e c t e d o v e r r i d e h y s t e r e s i s ∗/
i f ( l a s t B e s t . getBSSID ( ) . i s U n s p e c i f i e d ( ) ) {
l a s t B e s t = r e s p −>g e t B s s L i s t ( b e s t I n d e x ) ;
return b e s t I n d e x ;
}
W celu realizacji histerezy algorytm sprawdza, czy adres odnalezionego punktu dostępowego różni się od ostatnio wybranego. Listing 4.21 przedstawia wykorzystanie metody getBSSID() w celu zwrócenia i porównania instancji klasy MACAddress pochodzących z ostatnio
wybranego punktu dostępowego oraz aktualnie najlepszego. Różnica w adresach owocuje
wyzerowaniem licznika histerezy hystCount. Metoda emit(...) służy do emisji sygnału statystycznego, który nie ma wpływu na przebieg symulacji. Metoda zwraca wartość ujemną
wymuszając kontynuację procesu sondowania łącza.
Listing 4.21: Restart histerezy przy odnalezieniu nowego punktu dostępowego.
1
3
5
/∗ I f top AP changed − r e s t a r t h y s t e r e s i s ∗/
i f ( l a s t B e s t . getBSSID ( ) != r e s p −>g e t B s s L i s t ( b e s t I n d e x ) . getBSSID ( ) ) {
l a s t B e s t = r e s p −>g e t B s s L i s t ( b e s t I n d e x ) ;
hystCount = 0 ;
emit ( r o a m i n g T r i g g e r I n i t S i g n a l , 0 ) ;
return −1;
7
}
50
Listing 4.22 przedstawia ostatni krok algorytmu. Jeśli licznik histerezy hystCount dorównał wartość konfigurowalnej hystThreshold następuje restart histerezy oraz metoda zwraca
aktualnie odnaleziony punkt dostępowy jako najlepszy wybrany. Wartość hystThreshold jest
konfigurowalna przy pomocy pliku INI. Jeśli licznik histerezy hystCount jest mniejszy od
wartości progowej to jest on zwiększany oraz zwracana jest wartość ujemna wymuszająca
kontynuację procesu sondowania łącza.
Listing 4.22: Zakończenie histerezy.
2
i f ( hystCount < h y s t T h r e s h o l d ) {
hystCount++;
return −1;
4
6
8
} else {
hystCount = 0 ;
return b e s t I n d e x ;
}
51
Rozdział 5
Scenariusze doświadczalne dla
modeli symulacyjnych
Niniejszy rozdział opisuje scenariusze doświadczalne przygotowane pod kątem badania
efektywności roamingu stacji klienckiej. Głównym celem scenariuszy jest generacja wyników
wystarczających do przeprowadzenia analizy porównawczej dla metody wyzwalania przez sondowanie oraz standardowej procedury roamingu. Posługuję się terminologią zdefiniowaną w
rozdziale 2.3.1. Rozpoczynam od opisu metodyki przygotowania scenariuszy wykorzystującej
narzędzia udostępniane przez środowisko symulacyjne OMNet++. W dalszej części opisuję
środowisko doświadczalne będące podstawą dla każdego z eksperymentów. Przedstawiam opis
bazowych parametrów wejściowych oraz prezentuję sposób dziedziczenia konfiguracji przez
konkretne scenariusze.
5.1
Tworzenie scenariuszy doświadczalnych w środowisku
OMNet++
Doświadczenie w sensie środowiska OMNet++ składa się z definicji sieci oraz pliku konfiguracyjnego. Sieć doświadczalna definiowana jest z pomocą plików NED (ang. network description). Pliki NED opisują relacje między modułami oraz udostępniają dostępne parametry konfiguracyjne. Relacje między modułami reprezentują połączenia sieciowe. Parametry
zdefiniowane przy pomocy nazwy w pliku NED są w pełni konfigurowalne z poziomu pliku
typu INI. Plik typu INI pozwala na stosowanie dodatkowej składni wspomagającej proces
organizacji scenariuszy doświadczalnych. Składnia pliku INI pozwala na definiowanie list wartości parametrów generujących dodatkowe przebiegi oraz tworzenie hierarchii dziedziczenia
parametrów wejściowych.
Łańcuch dziedziczenia sekcji konfiguracyjnych
Scenariusze doświadczalne zostały przygotowane z wykorzystaniem mechanizmu dziedziczenia wbudowanego w składnie pliku INI. Listing 5.1 przedstawia przykładowe sekcje
52
konfiguracyjne. Nazwy konfiguracji wszystkich przygotowanych scenariuszy doświadczalnych
poprzedzone są przedrostkiem Ex w celu odróżnienia od konfiguracji pośrednich. Konfiguracje pośrednie dziedziczą po konfiguracji bazowej i tworzą zestawy umożliwiające konstrukcję
przejrzystych scenariuszy docelowych. W celu odnalezienia wartości danego parametru symulator przeszukuje hierarchię konfiguracji w kolejności: ExLinearMobilityIntersecting, LinearMobility, ApCoverageIntersecting, General.
Listing 5.1: Łańcuch dziedziczenia sekcji konfiguracyjnych.
2
4
6
8
[ General ]
...
[ Config ApCoverageIntersecting ]
...
[ Config LinearMobility ]
...
[ Config ExLinearMobilityIntersecting ]
extends = LinearMobility , ApCoverageIntersecting
Generacja liczb pseudolosowych
Symulacje przedstawione w tym rozdziale korzystają z wbudowanego w środowisko
OMNet++ generatora liczb pseudolosowych na bazie algorytmu Mersenne Twister. Dokumentacja symulatora [11] ustala, iż długość cyklu generatora wynosi 219937 . Wejściowym
ziarnem (ang. seed ) generatora jest numer przebiegu symulacji.
Metodyka eksperyment-pomiar-replikacja
Identyfikacja danego scenariusza symulacyjnego opiera się na trzech wartościach:
– Eksperyment: Nazwa zestawu parametrów wejściowych z pliku INI,
– Pomiar : Aktualne wartość parametrów z list generujących przebiegi,
– Replikacja: Numer przebiegu odpowiadającego ziarnu generatora liczb pseudolosowych.
Nazwy scenariuszy w niniejszym rozdziale nie będą zawierać członu odpowiadającego
replikacji. Ewentualne dodatkowe przebiegi generowane przez listy parametrów są opisywane
w ramach danej nazwy scenariusza. Składnia dziedziczenia konfiguracji dostępna w pliku INI
pozwala na tworzenie kolejnych środowisk symulacyjnych na podstawie sieci bazowej opisanej
plikiem NED.
53
5.2
Sieć bazowa scenariuszy symulacyjnych
Najbardziej nadrzędny plik NED opisuje sieć bazową symulacji. Schemat graficzny pliku
sieci bazowej BasicRoaming.ned przedstawiony jest na diagramie Rys. 5.1.
Rysunek 5.1: Sieć bazowa BasicRoaming.
Graficzna reprezentacja sieci tworzona jest automatycznie przez środowisko OMNet++
na bazie pliku NED. Listing 5.2 przedstawia definicję sieci BasicRoaming w pliku BasicRoaming.ned. Właściwość @display służy jedynie umiejscowieniu modułów na graficznej reprezentacji oraz określeniu rozmiaru środowiska roboczego symulacji. Umiejscowienie modułów
jest nadpisywane w zależności od konfiguracji scenariusza doświadczalnego. Definicja sieci bazowej określa ilość i rodzaj stacji, połączenia komunikacyjne oraz pewne aspekty architektury
wyższych warstw modelu OSI.
Sieć bazowa zawiera trzy stacje. Stacje ap1 oraz ap2 to moduły typu AccessPoint symulujące zachowanie punktów dostępowych. Mobilna stacja kliencka host odpowiada modułowi
WirelessHost opisywanemu w rozdziale dotyczącym implementacji rozwiązania wyzwalania
przez sondowanie 4.2. Abstrakcyjny moduł ChannelControl reprezentuje medium transmisyjne. Moduł ChannelControl określa wzajemną widoczność modułów korzystających z bezprzewodowych interfejsów NIC. Abstrakcyjny moduł IPv4NetworkConfigurator odpowiada
za tworzenie topologii sieci w sensie protokołu IP na bazie zawartości modułów obecnych w
sieci bazowej.
54
Listing 5.2: Definicja sieci BasicRoaming.
2
4
6
8
10
12
14
16
18
20
network BasicRoaming
{
parameters :
@ d i s p l a y ( ”bgb =1500 ,1500 ” ) ;
submodules :
host : WirelessHost {
@ d i s p l a y ( ”p =107 ,301; r = , ,#707070 ” ) ;
}
ap1 : A c c e s s P o i n t {
@ d i s p l a y ( ”p =50 ,300; r = , ,#707070 ” ) ;
}
ap2 : A c c e s s P o i n t {
@ d i s p l a y ( ”p =550 ,300; r = , ,#707070 ” ) ;
}
c h a n n e l C o n t r o l : ChannelControl {
@ d i s p l a y ( ”p=80 ,22 ” ) ;
}
c o n f i g u r a t o r : IPv4NetworkConfigurator {
@ d i s p l a y ( ”p=235 ,23 ” ) ;
}
}
Sekcja General pliku konfiguracyjnego INI przeznaczona jest dla parametrów wejściowych
sieci bazowej. Sekcja ta jest najbardziej rozległa, gdyż konfiguruje w sposób explicite wiele
wybranych parametrów, które określają ogólny stan sieci. Zmiany w podzbiorach parametrów sieci bazowej generują czytelne scenariusze potomne. Dokonałem podziału parametrów
sekcji General na podzbiory związane z konfiguracją określonych aspektów sieci bazowej.
Nazwy parametrów wykorzystują składnię sumulatora OMNet++ dla plików INI. W szczególności, symbol * odpowiada ciągowi znaków z wyłączeniem znaku kropki (.), który daje
dostęp do parametrów danego modułu. Symbol ** odpowiada dowolnemu ciągowi znaków.
Należy pamiętać, iż brak parametru w pliku INI oznacza, że nie został on skonfigurowany.
Nieskonfigurowane parametry inicjalizowane są wartościami typu default. Wartości typu default określane są na poziomie składni plików NED. Konfigurację parametrów sekcji General
podzieliłem na następujące zestawy:
– Parametry wejściowe obszaru roboczego i przebiegu symulacji,
– Parametry wejściowe punktów dostępowych ap1 oraz ap2,
– Parametry wejściowe związane z transmisją ramek typu Data,
– Parametry wejściowe anten kart radiowych,
– Parametry wejściowe mobilnej stacji klienckiej,
– Parametry wejściowe modułów typu agent,
– Parametry wejściowe medium transmisji.
55
Parametry wejściowe obszaru roboczego i przebiegu symulacji
Tab. 5.1 zawiera parametry związane z przebiegiem symulacji oraz definicję obszaru roboczego. Dziennik zdarzeń w postaci pliku tekstowego elog zawiera stemple czasowe. Stemple
czasowe zdarzeń są niezbędne w procesie automatycznej analizy interwałów między wybranymi zdarzeniami. Udostępniany przez symulator OMNet++ widok sekwencji zdarzeń nie
nadaje się do wsadowych obliczeń na interwałach czasowych. Makro EV jest wykorzystywane jak strumień w sensie języka C++. Generacja zdarzeń typu debug odbywa się z pomocą
operatora «.
Tablica 5.1: Parametry konfiguracyjne sieci bazowej - symulacja i obszar roboczy
Parametr
Wartość
Komentarz
network
BasicRoaming
Definicja sieci.
record-eventlog
true
Symulacja będzie generować
dziennik zdarzeń elog.
repeat
10
Ilość możliwych przebiegów
symulacji.
sim-time-limit
120s
Czas trwania przebiegu symulacji.
**.module-eventlog-recording
true
Każdy moduł symulacji będzie generować zdarzenia.
**.debug
true
Możliwość generowania zdarzeń z pomocą makra EV.
**.coreDebug
false
Brak zdarzeń z modułów odpowiedzialnych za pracę symulatora.
**.constraintAreaMinX
0m
Początek obszaru roboczego
względem osi X układu odniesienia.
**.constraintAreaMinY
0m
Początek obszaru roboczego
względem osi Y układu odniesienia.
**.constraintAreaMaxX
1500m
Koniec obszaru roboczego
względem osi X układu
odniesienia.
**.constraintAreaMaxY
1500m
Koniec obszaru roboczego
względem osi Y układu
odniesienia.
56
Parametry wejściowe punktów dostępowych ap1 oraz ap2
Tab. 5.2 demonstruje konfigurację punktów dostępowych będących częścią środowiska
doświadczalnego. Wstępnie tworzone są dwie infrastruktury BSS pracujące na rozdzielnych
częstotliwościach i oferujące uwierzytelnianie w trybie open-system.
Tablica 5.2: Parametry konfiguracyjne sieci bazowej - punkty dostępowe.
Parametr
Wartość
Komentarz
**.ap1.wlan[*].mac.address
00:00:00:00:00:01
Adres MAC punktu
dostępowego ap1.
**.ap2.wlan[*].mac.address
00:00:00:00:00:02
Adres MAC punktu
dostępowego ap2.
**.ap1.wlan[*].mgmt.ssid
AP1
Identyfikator SSID
infrastruktury
punktu dostępowego
ap1.
**.ap2.wlan[*].mgmt.ssid
AP2
Identyfikator SSID
infrastruktury
punktu dostępowego
ap2.
**.ap*.wlan[*].mgmt.beaconInterval
100ms
Interwał
ramek
typu Beacon punktu
dostępowego ap1 i
punktu dostępowego
ap2.
**.ap1.wlan[*].radio.channelNumber 2
Numer kanału pracy
kart
radiowych
punktu dostępowego
ap1.
**.ap2.wlan[*].radio.channelNumber 3
Numer kanału pracy
kart
radiowych
punktu dostępowego
ap2.
**.wlan[*].mgmt.numAuthSteps
Dla wszystkich stacji liczba kroków
uwierzytelniania odpowiada procedurze
open-system.
2
57
Parametry wejściowe związane z transmisją ramek typu Data
Tab. 5.3 przedstawia parametry związane z transmisją ramek typu Data.
Tablica 5.3: Parametry konfiguracyjne sieci bazowej - transmisja danych.
Parametr
Wartość
Komentarz
**.wlan*.bitrate
54Mbps
Wstępna przepływność dla
protokołu wymiany danych.
**.mgmt.frameCapacity
10
Rozmiar kolejki komunikatów
w jednostce mgmt.
**.mac.maxQueueSize
14
Maksymalny rozmiar kolejki
komunikatów w jednostce
mac.
**.mac.rtsThresholdBytes
4000B
Progowy rozmiar pakietu
wyzwalający
procedurę
RTS/CTS.
**.wlan[*].mac.retryLimit
7
Ilość podejść do retransmisji
ramek potwierdzanych o długości mniejszej od rtsTreshold.
Parametry wejściowe anten kart radiowych
Tab. 5.4 przedstawia parametry charakteryzujące anteny kart interfejsów bezprzewodowych. Symulator używa parametrów thermalNoise, sensitivity, pathLossAlpha oraz transmitterPower do wstępnej klasyfikacji ramki. Jeśli ramka jest prawidłowa to dodatkowo używany
jest parametr snirTreshold, który decyduje, czy SNR danej ramki pozwala na prawidłowy
odczyt.
Tablica 5.4: Parametry konfiguracyjne sieci bazowej - antena karty radiowej.
Parametr
Wartość
Komentarz
**.radio.transmitterPower
2.0mW
Moc anteny karty radiowej.
**.radio.thermalNoise
-110dBm
Wstępna wartość bazowe zaszumienie medium transmisyjnego.
**.radio.sensitivity
-85dBm
Czułość odbiornika karty radiowej.
**.radio.pathLossAlpha
2
Spadek mocy sygnału nadajnika karty radiowej.
**.radio.snirThreshold
4dB
Próg wartości SNR poniżej,
którego odebrana ramka nie
może zostać odkodowana.
58
Parametry wejściowe mobilnej stacji klienckiej
Tab. 5.5 przedstawia konfigurację mobilnej stacji klienckiej. Położenie stacji zależy od właściwości @display. Zgodnie z niniejszą konfiguracją stacja porusza się ruchem prostoliniowym
zgodnie z kierunkiem osi X układu odniesienia. Prędkość stacji wynosi 20 [m/s]. Większość
parametrów stacji klienckiej jest przeznaczona do nadpisania przez scenariusze potomne.
Tablica 5.5: Parametry konfiguracyjne sieci bazowej - mobilna stacja kliencka.
Parametr
Wartość
Komentarz
**.host.wlan[*].radio.channelNumber
0
Wstępny numer kanału
pracy kart radiowych
stacji klienckiej.
**.mac.address
auto
Automatyczna generacja brakujących adresów MAC.
**.mobility.initFromDisplayString
true
Wstępne położenie stacji na bazie diagramu
symulacji GUI.
**.host*.mobilityType
LinearMobility
Stacja kliencka porusza
się ruchem prostoliniowym.
**.host*.mobility.speed
20mps
Stacja kliencka porusza
się z prędkością 20 metrów na sekundę.
**.host*.mobility.angle
0
Stacja kliencka porusza
się w kierunku osi X
układu odniesienia.
**.host*.mobility.acceleration
0
Stacja kliencka nie posiada przyspieszenia.
**.host*.mobility.updateInterval
100ms
Interwał
odświeżania położenia stacji
klienckiej.
59
Parametry wejściowe modułów typu agent
Tab. 5.6 przedstawia konfigurację parametrów wykorzystywanych przez moduły typu
agent. Moduły agent są odpowiedzialne za proces sondowanie łącza, uwierzytelniania oraz
podłączenia do punktu dostępowego. Przypisanie parametrowi channelsToScan wartości pustej oznacza wszystkie częstotliwości dostępne w definicji medium transmisyjnego. Parametry
minChannelTime oraz maxChannelTime zostały opisane w rozdziale dotyczącym szczegółowej analizy roamingu 2.
Tablica 5.6: Parametry konfiguracyjne sieci bazowej - moduły typu agent.
Parametr
Wartość
Komentarz
**.wlan[*].agent.activeScan
true
Wszystkie moduły typu agent
używają procedury sondowania aktywnego.
**.wlan[*].agent.channelsToScan
Procedura sondowania łącza
bada wszystkie kanały dostępne w medium transmisyjnym.
**.wlan[*].agent.probeDelay
0.1s
Interwał wysyłania
typu ProbeReq.
**.wlan[*].agent.minChannelTime
0.15s
Ujęty
w
IEEE802.11
ChannelTime.
**.wlan[*].agent.maxChannelTime
0.3s
Ujęty
w
standardzie
IEEE802.11 czas maxChannelTime.
**.wlan[*].agent.authenticationTimeout
5s
Niedoczas dla procedury
uwierzytelniania w punkcie
dostępowym.
**.wlan[*].agent.associationTimeout
5s
Niedoczas dla procedury podłączania do punktu dostępowego.
60
ramek
standardzie
czas
min-
Parametry wejściowe medium transmisji
Tab. 5.7 zawiera parametry modułu ChannelControl. Niniejsze parametry określają
wstępną widoczność stacji. Wstępna widoczność bazuje na podanych wartościach granicznych i jest pierwszym krokiem w stronę poprawnego przesłania wiadomości.
Tablica 5.7: Parametry konfiguracyjne sieci bazowej - medium transmisji.
Parametr
Wartość
Komentarz
*.channelControl.carrierFrequency
2.4GHz
Pasmo pracy medium
transmisyjnego.
*.channelControl.pMax
2.0mW
Maksymalna moc nadawania w medium transmisyjnym.
*.channelControl.sat
-110dBm
Próg zaszumienia medium transmisyjnego.
*.channelControl.alpha
2
Górne
ograniczenie
współczynnika spadku
mocy
sygnału
dla
anten.
*.channelControl.numChannels
5
Liczba dostępnych częstotliwości pracy w medium transmisyjnym.
61
5.3
Konfiguracje pośrednie
Konfiguracje pośrednie dziedziczą po konfiguracji sieci bazowej, ale nie są podawane na
wejściu przebiegów symulacyjnych. Nadpisują one wąskie grupy parametrów w celu wywołania określonego zjawiska. Konfiguracje pośrednie stanowią budulec docelowych scenariuszy
doświadczalnych.
Konfiguracja ApCoverageIntersecting
Celem konfiguracji przedstawionej na listingu 5.3 jest zmiana położenia punktów dostępowych ap1 oraz ap2. Zmiana położenia ma na celu wywołanie zjawiska nakładania się
obszarów zasięgu sygnału anten kart radiowych. Parametr initFromDisplayString musi zostać
zanegowany w celu nadpisania wstępnego położenia punktów dostępowych.
Listing 5.3: Konfiguracja ApCoverageIntersecting.
1
3
5
7
9
[ Config ApCoverageIntersecting ]
∗ ∗ . ap1 . m o b i l i t y . i n i t F r o m D i s p l a y S t r i n g = f a l s e
∗ ∗ . ap2 . m o b i l i t y . i n i t F r o m D i s p l a y S t r i n g = f a l s e
∗ ∗ . ap1 . m o b i l i t y . i n i t i a l X = 600m
∗ ∗ . ap1 . m o b i l i t y . i n i t i a l Y = 750m
∗ ∗ . ap1 . m o b i l i t y . i n i t i a l Z = 0m
∗ ∗ . ap2 . m o b i l i t y . i n i t i a l X = 900m
∗ ∗ . ap2 . m o b i l i t y . i n i t i a l Y = 750m
∗ ∗ . ap2 . m o b i l i t y . i n i t i a l Z = 0m
Konfiguracja ApCoverageSeparate
Szablon konfiguracji jest analogiczny do przykładu 5.3. W tym przypadku celem jest
utworzenie infrastruktur BSS o nienakładających się obszarach zasięgu mocy sygnału.
Konfiguracja ApCoverageBoundary
Szablon konfiguracji jest analogiczny do przykładu 5.3. W tym przypadku celem jest
utworzenie infrastruktur BSS o stykając się obszarach zasięgu mocy sygnału.
Konfiguracja CircleMobility
Konfiguracja przedstawiona na listingu 5.4 dotyczy mobilnej stacji klienckiej. Celem jest
wprowadzenie stacji klienckiej w ruch po okręgu z zadanymi parametrami. Zanegowanie
parametru initFromDisplayString jest niezbędne do nadpisania współrzędnych sieci bazowej.
Nadanie parametrowi mobilityType wartości CircleMoblity umożliwia dalszy opis ruchu z
pomocą:
– współrzędnych środka okręgu cx, cy oraz cz,
– promienia okręgu r,
62
– prędkości stacji speed,
– początkowego położenia stacji startAngle,
– interwału aktualizacji położenia stacji updateInterval.
Listing 5.4: Konfiguracja CircleMoblity.
1
3
5
7
9
[ Config C i r c l e M o b i l i t y ]
∗∗. host . mobility . initFromDisplayString = f a l s e
∗ ∗ . host ∗ . mobilityType = ” C i r c l e M o b i l i t y ”
∗ ∗ . h o s t . m o b i l i t y . cx = 600m
∗ ∗ . h o s t . m o b i l i t y . cy = 750m
∗ ∗ . h o s t . m o b i l i t y . c z = 0m
∗ ∗ . h o s t . m o b i l i t y . r = 180m
∗ ∗ . h o s t ∗ . m o b i l i t y . s p e e d = 20mps
∗ ∗ . h o s t ∗ . m o b i l i t y . s t a r t A n g l e = 180 deg
∗ ∗ . h o s t ∗ . m o b i l i t y . u p d a t e I n t e r v a l = 100ms
Konfiguracja LinearMobility
Ruch prostoliniowy jest elementem konfiguracji sieci bazowej. Jedynym zadaniem sekcji
LinearMobility jest nadanie stacji klienckiej prawidłowego położenia poprzez zanegowanie
parametru initFromDisplayString oraz nadanie parametrom initialX, initialY, initialZ pożądanych wartości.
Konfiguracja DualInterface
Sposób konfiguracji przedstawiony jest na listingu 5.5. Konfiguracja pozwala na użycie
interfejsów Ieee80211ScanNic oraz Ieee80211CommNic wytworzonych w ramach niniejszej
pracy. Konfiguracja sieci bazowej korzysta z pojedynczego interfejsu klasy Ieee80211Nic.
Zwiększenie wartości parametru numRadios udostępnia dodatkowe interfejsy NIC, których
typ można określić z pomocą wzorca typename. Parametry mgmtID oraz agentID służą
związaniu modułów w celu filtrowania wiadomości rozgłoszeniowych.
Listing 5.5: Konfiguracja DualInterface.
2
4
6
8
[ Config DualInterface ]
∗ ∗ . h o s t . numRadios = 2
∗ ∗ . h o s t . wlan [ 0 ] . typename = ” I e e e 8 0 2 1 1 S c a n N i c ”
∗ ∗ . h o s t . wlan [ 0 ] . mgmt . mgmtID = 0
∗ ∗ . h o s t . wlan [ 0 ] . a g e n t . agentID = 0
∗ ∗ . h o s t . wlan [ 1 ] . typename = ” Ieee80211CommNic ”
∗ ∗ . h o s t . wlan [ 1 ] . mgmt . mgmtID = 1
∗ ∗ . h o s t . wlan [ 1 ] . a g e n t . agentID = 1
63
Konfiguracja DualInterfaceHyst
Szablon konfiguracji jest analogiczny do przykładu przedstawionego na listingu 5.5. W
celu wykorzystania przygotowanego interfejsu Ieee80211ScanHystNic wykorzystano wzorzec
typename 5.6.
Listing 5.6: Fragment konfiguracji DualInterfaceHyst.
∗ ∗ . h o s t . wlan [ 0 ] . typename = ” I e e e 8 0 2 1 1 S c a n H y s t N i c ”
5.4
Docelowe scenariusze doświadczalne
Sekcje konfiguracji pliku INI, których nazwy poprzedzone są przedrostkiem Ex opisują
scenariusze docelowe. Scenariusze docelowe przeznaczone są do bezpośredniej parametryzacji przebiegów symulacyjnych. Sekcje konfiguracyjne scenariuszy docelowych wykorzystują
składnię extends w celu konstrukcji pożądanego zestawu zjawisk na bazie scenariuszy pośrednich.
Scenariusz ExCircleMobilityDualInterfaceIntersecting
Diagram 5.2 przedstawia widok scenariusza po uruchomieniu w graficznym środowisku
przebiegu symulacji. Obszary zasięgu sygnału punktów dostępowych ap1 oraz ap2 nakładają się. Mobilna stacja kliencka porusza się ruchem po okręgu wokół punktu dostępowego
ap1. Podczas ruchu w obszarze nakładania się wpływu punktów dostępowych stacja kliencka
zbliża się do punktu dostępowego ap2. W chwili zbliżenia stacja jest nadal w zasięgu punktu
dostępowego ap1. Celem scenariusza jest zbadanie ilości wyzwoleń sekwencji roamingu. Stacja
kliencka korzysta z rozwiązania wyzwalania przez sondowanie utworzonego w ramach niniejszej pracy. Algorytm wyboru najlepszego punktu dostępowego z listy dostępnych pozbawiony
jest mechanizmu histerezy. Scenariusz dziedziczy po konfiguracjach pośrednich DualInterface,
CircleMobility, ApCoverageIntersecting.
Rysunek 5.2: Scenariusz ExCircleMobilityDualInterfaceIntersecting.
64
Scenariusz ExCircleMobilityDualInterfaceHystIntersecting
Szablon doświadczenia jest analogiczny do scenariusza ExCircleMobilityDualInterfaceIntersecting 5.4. Celem scenariusza jest zbadanie ilości wyzwoleń sekwencji roamingu przy
wykorzystaniu algorytmu wyboru najlepszego punktu dostępowego implementującego mechanizm histerezy. Scenariusz dziedziczy po konfiguracjach pośrednich DualInterfaceHyst,
CircleMobility, ApCoverageIntersecting.
Scenariusz ExCircleMobilityIntersecting
Szablon doświadczenia jest analogiczny do scenariusza ExCircleMobilityDualInterfaceIntersecting 5.4. Stacja kliencka korzysta ze standardowego pojedynczego interfejsu
Ieee80211Nic. Celem scenariusza jest porównanie ilości wyzwoleń sekwencji roamingu w zestawieniu z metodą wyzwalania przez sondowanie. Scenariusz dziedziczy po konfiguracjach
pośrednich CircleMobility, ApCoverageIntersecting.
Scenariusz ExLinearMobilityDualInterfaceIntersecting
Diagram 5.3 przedstawia widok przebiegu symulacji ExLinearMobilityDualInterfaceIntersecting. W niniejszym przypadku mobilna stacja kliencka porusza się ruchem prostoliniowym
przecinając dwukrotnie obszar zasięgu sygnału punktów dostępowych ap1 oraz ap2. Celem
scenariusza jest zbadanie efektywności roamingu z wykorzystaniem wyzwalania przez sondowanie w przypadku stacji, która podczas sekwencji roamingu nie opuszcza obszaru wpływu
przynajmniej jednego z punktów dostępowych. Obszary zasięgu sygnały punktów dostępowych ap1 oraz ap2 nakładają się. Scenariusz dziedziczy po konfiguracjach pośrednich DualInterface, LinearMobility, ApCoverageIntersecting.
Rysunek 5.3: Scenariusz ExLinearMobilityDualInterfaceIntersecting.
65
Scenariusz ExLinearMobilityDualInterfaceHystIntersecting
Szablon doświadczenia jest analogiczny do scenariusza ExLinearMobilityDualInterfaceIntersecting 5.4. Algorytm wyboru najlepszego punktu dostępowego z listy dostępnych wykorzystuje mechanizm histerezy. Celem scenariusza jest ocena wpływu mechanizmu histerezy w module Ieee80211ScanHystNic na efektywność roamingu w porównaniu do modułu
Ieee80211ScanNic. Scenariusz dziedziczy po konfiguracjach pośrednich DualInterfaceHyst, LinearMobility, ApCoverageIntersecting.
Scenariusz ExLinearMobilityIntersecting
Szablon doświadczenia jest analogiczny do scenariusza ExLinearMobilityDualInterfaceIntersecting 5.4. W tym przypadku stacja kliencka korzysta ze standardowego pojedynczego
interfejsu Ieee80211Nic. Scenariusz dziedziczy po konfiguracjach pośrednich LinearMobility,
ApCoverageIntersecting.
Scenariusz ExLinearMobilityDualInterfaceSeparate
Obszary zasięgu sygnału punktów dostępowych ap1 oraz ap2 są rozłączne. Celem scenariusza jest zbadanie zachowania metody wyzwalania przez sondowanie w sytuacji chwilowego
braku jakichkolwiek punktów dostępowych. Scenariusz dziedziczy po konfiguracjach pośrednich DualInterface, LinearMobility, ApCoverageSeparate.
Scenariusz ExLinearMobilitySeparate
Szablon doświadczenia jest analogiczny do scenariusza ExLinearMobilityDualInterfaceSeparate 5.4. W tym przypadku stacja kliencka korzysta ze standardowego pojedynczego
interfejsu Ieee80211Nic. Scenariusz dziedziczy po konfiguracjach pośrednich LinearMobility,
ApCoverageSeparate.
Scenariusz ExLinearMobilityDualInterfaceBoundary
W przypadku niniejszego scenariusza obszary zasięgu sygnału punktów dostępowych ap1
oraz ap2 stykają się. Celem scenariusza jest zbadanie zachowania metody wyzwalania przez
sondowanie w sytuacji, gdy stacja kliencka przekracza nienakładające się obszary wpływu
punktów dostępowych. Scenariusz dziedziczy po konfiguracjach pośrednich DualInterface,
LinearMobility, ApCoverageBoundary.
Scenariusz ExLinearMobilityBoundary
Szablon doświadczenia jest analogiczny do scenariusza ExLinearMobilityDualInterfaceBoundary 5.4. W tym przypadku stacja kliencka korzysta ze standardowego pojedynczego
interfejsu Ieee80211Nic. Scenariusz dziedziczy po konfiguracjach pośrednich LinearMobility,
ApCoverageBoundary.
66
Rozdział 6
Analiza porównawcza wyników
symulacji
Niniejszy rozdział dotyczy wyników przebiegów symulacyjnych dla scenariuszy doświadczalnych. Opisuję w nim metodologię obliczania efektywności roamingu na podstawie plików
wynikowych generowanych przez środowisko symulacyjne OMNet++. Przedstawiam zgromadzone wyniki pomiarów dla scenariuszy opisanych w rozdziale 5.4. Przeprowadzam zbiorczą
analizę porównawczą wyników oceniając efektywność roamingu stacji klienckiej korzystającej
z metody wyzwalania przez sondowanie. Ostatecznie porównuję wyniki symulacyjne z rzeczywistymi pomiarami opóźnień ramek sekwencji roamingu. Pomiary rzeczywiste pochodzą
z pracy Pomiar opóźnień ramek standardu 802.11 - narzędzie hop-sniffer [7]. Porównanie
z wynikami rzeczywistymi ma na celu próbę oszacowania realnych korzyści wynikających z
zastosowania rozwiązania interfejsów równoległych.
6.1
Metodologia analizy porównawczej
Środowisko OMNet++ udostępnia zestaw narzędzi służących organizacji i prezentacji wybranych aspektów symulacji. Z punktu widzenia niniejszej pracy najbardziej istotna byłaby
możliwość pomiaru i gromadzenia interwałów czasowych między wybranymi zdarzeniami.
Zdarzenia generowane przez modele symulacyjne zapisywane są do pliku elog pełniącego rolę
dziennika zdarzeń (ang. event log). Każde zdarzenie opatrzone jest stemplem czasowym. Jeśli
chodzi o symulator w wersji 4.3.1 to jedynym sposobem prezentacji zawartości pliku elog jest
widok sekwencji zdarzeń. Widok sekwencji zdarzeń stanowi graficzną reprezentację komunikatów wymienianych podczas przebiegu symulacyjnego. Przydatność graficznej reprezentacji
komunikatów na etapie tworzenia i dostrajania modeli nie przenosi się na ostateczną metodykę gromadzenia wyników. Ze względu na potrzebę wsadowego przetwarzania plików elog
wytworzyłem narzędzie elog-parser. Narzędzie elog-parser pozwala na gromadzenie wyników
kolejnych przebiegów symulacji w postaci możliwych interwałów czasowych między wybranymi zdarzeniami.
67
W celu pełnej automatyzacji procesu gromadzenia wyników wytworzyłem skrypt
run experiments. Zadaniem skryptu run experiments jest uruchomienie wybranych przebiegów zadanych scenariuszy docelowych z pomocą narzędzi linii poleceń symulatora OMNet++.
Skrypt wykorzystuje narzędzie elog-parser w celu gromadzenia wyników symulacji.
6.1.1
Narzędzie elog-parser
Aplikacja elog-parser ma postać skryptu w języku Python. Główną funkcjonalnością
skryptu jest obliczanie interwałów czasowych między wszystkimi permutacjami, kombinacjami lub iloczynem zadanych typów wiadomości. Specyfikacja wiadomości ma postać pliku
XML. Listing 6.1 przedstawia plik konfiguracyjny. Aplikacja udostępnia metody specyfikacji
wiadomości w trybie msg oraz custom.
Listing 6.1: Plik konfiguracyjny aplikacji elog-parser.
1
3
5
7
9
11
13
15
17
19
21
23
25
<?xml v e r s i o n=” 1 . 0 ”?>
<i n t e r v a l >
<!−−
<module name=” h o s t ”
type=” i n e t . nodes . i n e t . W i r e l e s s H o s t ”
c l a s s=”cCompoundModule”>
<module name=” wlan [ 1 ] ”
type=” i n e t . l i n k l a y e r . i e e e 8 0 2 1 1 . Ieee80211CommNic ”
c l a s s=”cCompoundModule”>
<module name=”mgmt”
type=” i n e t . l i n k l a y e r . i e e e 8 0 2 1 1 . mgmt . Ieee80211MgmtSTA”
c l a s s=”Ieee80211MgmtSTA”>
<msg c l a s s=” I e e e 8 0 2 1 1 P r i m A u t h e n t i c a t e R e q u e s t ”/>
</module>
<module name=” a g e n t ”
type=” i n e t . l i n k l a y e r . i e e e 8 0 2 1 1 . mgmt . Ieee80211AgentCommSTA”
c l a s s=”Ieee80211AgentCommSTA”>
<msg c l a s s=” I e e e 8 0 2 1 1 P r i m A s s o c i a t e C o n f i r m ”/>
</module>
</module>
</module>
−−>
<custom c t x=” r o a m i n g T r i g g e r I n i t ”/>
<custom c t x=” r o a m i n g T r i g g e r ”/>
<custom c t x=” r o a m i n g S u c c e s s ”/>
</ i n t e r v a l >
Element typu msg służy do opisywania zdarzeń generowanych przez moduły INET. Element typu msg powinien być umieszczony w drzewiastej strukturze elementów typu module.
Atrybuty name, type oraz class służą odnalezieniu danego modułu w pliku elog. Zastosowanie
struktury drzewiastej jest następstwem hierarchicznej struktury modułów symulacyjnych w
68
środowisku OMNet++. Aplikacja wykorzystuje numery pid (ang. parent identification number ) do odnalezienia właściwej gałęzi modułów, gdyż pojedyncze elementy module nie są unikalne. Numery id modułów wykorzystywane są do filtrowania wiadomości. Do jednoznacznego
określenia wiadomości wystarcza atrybut class zawierający nazwę klasy modułu.
Element typu custom służy do odnajdywania zdarzeń generowanych specjalnie na użytek aplikacji elog-parser. Listing 6.2 przedstawia użycie makra EV w postaci strumienia do generacji zdarzenia typu CUSTOM. Zdarzenie powinno mieć postać CUSTOM
ctx kontekst zdarzenia t aktualny czas symulacji c nazwa modułu generatora id identyfikator modułu generatora. Zdarzenie w tej postaci zostanie wykryte przez aplikację elog-parser
korzystając z atrybutu ctx.
Listing 6.2: Użycie makra EV do generacji zdarzeń typu CUSTOM.
2
4
EV << ”CUSTOM c t x r o a m i n g T r i g g e r ”
<< ” t ” << s i m u l a t i o n . getSimTime ( ) . s t r ( )
<< ” c ” << t h i s −>getClassName ( )
<< ” i d ” << t h i s −>g e t I d ( )
<< ” \n” ;
6.1.2
Skrypt run experiments
Skrypt przeznaczony jest dla powłoki Bash. Listing 6.3 przedstawia dwie główne listy
skryptu. Dla każdej konfiguracji z listy CONFS uruchamiane są przebiegi z listy RUNS.
Skrypt wykorzystuje komendę symulatora OMNet++ o nazwie opp run do uruchamiania
kolejnych przebiegów. Wynikowe dane w postaci plików elog przekazywane są na wejście aplikacji elog-parser, którego konfigurację przedstawia listing 6.1. Aplikacja elog-parser znajduje
w plikach dziennika zdarzeń wszystkie wystąpienia wiadomości roamingTriggerInit, roamingTrigger oraz roamingSuccess. Dla stempli czasowych odnalezionych zdarzeń aplikacja znajduje
możliwe kombinacje i oblicza ich interwały.
Listing 6.3: Fragment skryptu run experiment.
1
3
5
7
9
11
13
RUNS=(1)
CONFS=( \
ExCircleMobilityDualInterfaceIntersecting \
ExCircleMobilityDualInterfaceHystIntersecting \
ExCircleMobilityIntersecting \
ExLinearMobilityDualInterfaceIntersecting \
ExLinearMobilityDualInterfaceHystIntersecting \
ExLinearMobilityIntersecting \
ExLinearMobilityDualInterfaceSeparate \
ExLinearMobilitySeparate \
ExLinearMobilityDualInterfaceBoundary \
ExLinearMobilityBoundary \
)
69
6.2
Wyniki dla scenariuszy symulacyjnych
Wyniki badań efektywności roamingu dla przygotowanych scenariuszy doświadczalnych
przedstawione są w postaci tabel generowanych przez aplikację elog-parser. Kolumna kontekst
nr 1 zawiera nazwę wiadomości jaka rozpoczyna znaleziony interwał. Kolumna kontekst nr
2 zawiera nazwę wiadomości, która zamyka znaleziony interwał. Kolumna interwał zawiera
obliczoną różnicę między stemplami czasowymi zdarzeń. Jednostka czasu 1[sim t] odpowiada
1000[TU] (ang. time unit), czyli około 1[s].
Zmiana numeru przebiegu w ramach pojedynczego scenariusza powoduje wahania na
piątym miejscu po przecinku wartości z kolumny interwał. Ze względu na fakt, iż wahania
dotyczą ułamkowej części milisekundy podjąłem decyzję o porzuceniu metody uśredniania
wyników z przebiegów, gdyż nie wpłynęłaby na wartość prezentowanych rezultatów.
Nazwy kontekstów wiadomości pochodzą z pliku konfiguracyjnego aplikacji elog-parser
6.1. Wiadomości typu CUSTOM generowane są przez przygotowaną w ramach niniejszej
pracy hierarchię modułów typu agent. Znaczenie wiadomości jest następujące:
– roamingTriggerInit: Wystąpienie przesłanek o spadku jakości łącza
– roamingTrigger : Wyzwolenia sekwencji roamingu,
– roamingSuccess: Zakończenie etapu podłączania.
Poszczególne wiersze tablic z wynikami scenariuszy doświadczalnych odpowiadają interwałowi odnalezionemu w pliku elog. W szczególności, liczba odnalezionych interwałów między
zdarzeniami roamingTrigger oraz roamingSuccess odpowiada liczbie wyzwoleń procedury roamingu w ramach scenariusza doświadczalnego.
Należy pamiętać, iż metoda wyzwalania przez sondowanie usuwa z sekwencji roamingu
etap sondowania łącza. W rezultacie wyzwolenie sekwencji roamingu powoduje natychmiastowe przejście do etapu uwierzytelnienia i podłączenia w nowym punkcie dostępowym.
Scenariusz ExCircleMobilityDualInterfaceIntersecting
Tab. 6.1 przedstawia wynikowe interwały czasowe. Ze względu na brak mechanizmu
histerezy w algorytmie wyboru punktu dostępowego sekwencja roamingu wyzwalana jest w
skutek zbliżenia się do punktu dostępowego ap2. Czasy pojedynczych sekwencji roamingu są w
tym przypadku bardzo niskie. Wyniki scenariusza ExCircleMobilityIntersecting 6.2 wskazują,
iż niniejszy przypadek owocuje znacznie mniejszą efektywnością roamingu ze względu na ilość
wyzwoleń.
70
Tablica 6.1: Wyniki scenariusza ExCircleMobilityDualInterfaceIntersecting.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
Interwał [sim t]
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
0.001091401660
0.001082258076
0.001073401660
0.001063945060
0.001055401660
Scenariusz ExCircleMobilityDualInterfaceHystIntersecting
Tab. 6.2 przedstawia wynikowe interwały czasowe. Wiadomość roamingTriggerInit generowana jest przy restarcie mechanizmu histerezy. Pierwszą obserwacją są wyjątkowo długie
czasy wyzwalania sekwencji roamingu. Czas wyzwalania w przypadku interfejsu Ieee80211Nic
wynosi M AX BEACON S M ISSED ∗ beaconInterval, czyli 3.5 ∗ 100 = 350[ms]. Interwał
długości 5-6[s] odpowiada wywołaniu procedury sondowania łącza hystT hreshold + 2 razy.
Na wywołania sondowania łącza składa się restart histerezy, odliczanie oraz wyzwolenie roamingu. Wartości typu default parametru hystThreshold równa 2 nie jest wystarczająca do
eliminacji wyzwoleń w przypadku stopnia nakładania się obszarów zasięgu sygnału punktów
dostępowych równego około 41 . Wartość parametru hystThreshold, która zapewnia całkowitą
eliminację sekwencji roamingu wynosi 5.
Tablica 6.2: Wyniki scenariusza ExCircleMobilityDualInterfaceHystIntersecting.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
Interwał [sim t]
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
6.000000000000
5.400000000000
6.000000000000
5.400000000000
6.001081664850
5.401055401660
6.001054767280
5.401091401660
0.001091401660
0.001081664852
0.001055401660
0.001054767280
0.001091401660
Scenariusz ExCircleMobilityIntersecting
Uruchomienie niniejszego scenariusza nie zaowocowało wystąpieniem sekwencji roamingu.
Stacja nigdy nie opuszcza zasięgu punktu dostępowego ap1. Roamingu w przypadku interfejsu
71
Ieee80211Nic wyzwalany jest przez utratę kolejnych ramek typu Beacon. Stacja kliencka nie
odnotowuje utraty ramek typu Beacon, więc sekwencja nigdy nie jest wyzwalana.
Scenariusz ExLinearMobilityDualInterfaceIntersecting
Tab. 6.3 przedstawia wynikowe interwały czasowe. W tym przypadku porównanie z
wynikami ExLinearMobilityIntersecting 6.5 wypada na korzyść metody wyzwalania przez
sondowanie. W obydwu przypadkach następuje potrójne wyzwolenie sekwencji roamingu. W
przypadku metody wyzwalania przez sondowanie roaming rozpoczyna się jeszcze w obszarze
nakładania się zasięgu sygnału punktów dostępowych.
Tablica 6.3: Wyniki scenariusza ExLinearMobilityDualInterfaceIntersecting.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
Interwał [sim t]
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
0.001064828620
0.001054494364
0.001045414308
Scenariusz ExLinearMobilityDualInterfaceHystIntersecting
Tab. 6.4 przedstawia wynikowe interwały czasowe. Zastosowanie mechanizmu histerezy w
algorytmie wyboru punktu dostępowego powoduje opóźnienie wyzwolenia sekwencji roamingu
o interwał czasu między wiadomościami roamingTriggerInit oraz roamingTrigger. Scenariusz
daje pozytywne rezultaty, o ile wartość parametru hystThreshold jest na tyle niska, że
wyzwolenie zachodzi jeszcze w obszarze nakładania się sygnału punktów dostępowych.
Tablica 6.4: Wyniki scenariusza ExLinearMobilityDualInterfaceHystIntersecting.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
Interwał [sim t]
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTriggerInit
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
roamingSuccess
5.400000000000
5.400000000000
5.401080053370
5.401044160110
0.001064828620
0.001080053368
0.001044160108
Scenariusz ExLinearMobilityIntersecting
Tab. 6.5 przedstawia wynikowe interwały czasowe. Długość sekwencji roamingu wynosi w
tym przypadku około 1.4 + 0.35 = 1.75[s]. Wiersz tabeli z wyjątkowo długim interwałem sekwencji roamingu odpowiada sytuacji, w której stacja zawraca poza zasięgiem jakiegokolwiek
punktu dostępowego. Jest to również scenariusz doświadczalny mający potencjał bezpośredniego porównania z wynikami rzeczywistych pomiarów zawartymi w pracy [7].
72
Tablica 6.5: Wyniki scenariusza ExLinearMobilityIntersecting.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
Interwał [sim t]
1.401035213480
36.551136855300
1.401089213480
Wynik rzeczywistej sekwencji roamingu z pominięciem etapu wyzwalania wynosi około
55[ms]. Ogromna różnica wynika z czasu trwania etapu sondowania łącza. Konkretnie, modele
INET zalecają parametryzację modułu typu agent wartościami minChannelT ime = 0.15[s]
oraz maxChannelT ime = 0.3[s]. Są to wartości bardzo wysokie zważywszy na fakt, iż producenci urządzeń komunikacji bezprzewodowej zalecają wartości minChannelT ime = 0.02[s]
oraz maxChannelT ime = 0.04[s]. Bardziej agresywne metodyki sondowania zalecają nawet wartości na poziomie minChannelT ime = 0.007[s] oraz maxChannelT ime = 0.015[s].
Zastosowanie bardziej agresywnej parametryzacji modeli INET owocuje wynikami przedstawionymi w Tab. 6.6. Łatwo zauważyć, że wyniki na poziomie około 49[ms] są bardzo zbliżone
do wartości rzeczywistych pomiarów pochodzących z pracy [7].
Tablica 6.6: Wyniki scenariusza ExLinearMobilityIntersecting dla agresywnej parametryzacji
sodnowania łącza.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
Interwał [sim t]
0.049071587072
34.817065309000
0.049071587072
Parametryzacja tego typu nie jest jednak stosowana w niniejszych przebiegach symulacyjnych. Zastosowanie agresywanej parametryzacji powoduje częściowe lub, w zależności od
agresywności parametryzacji, całkowite gubienie ramek typu ProbeResp przy większej liczbie
punktów dostępowych. Zebranie wyników 6.6 jest możliwe, gdyż stacja kliencka przeprowadza procedurę sondowania łącza będąc w zasięgu pojedynczego punktu dostępowego ap2.
Zebrane w ten sposób interwały czasowe są wartościowe, gdyż pozwalają szacować, że wyniki
symulacji mają potencjał odzwierciedlania rzeczywistych pomiarów.
Scenariusz ExLinearMobilityDualInterfaceSeparate
Tab. 6.5 przedstawia wynikowe interwały czasowe. W tym przypadku roaming polega
jedynie na nawiązaniu połączenia z odnalezionym punktem dostępowym, gdyż obszary zasięgu
sygnału punktów dostępowych są rozłączne. Należy pamiętać, iż wiadomość roamingTrigger
generowana jest przez wyniki sondowania łącza. Informacja o czasie jaki stacja spędziła poza
zasięgiem punktów dostępowych jest zatarta.
73
Tablica 6.7: Wyniki scenariusza ExLinearMobilityDualInterfaceSeparate.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
Interwał [sim t]
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
0.001090094088
0.001064881992
0.001028908676
Scenariusz ExLinearMobilitySeparate
Tab. 6.8 przedstawia wynikowe interwały czasowe. Należy pamiętać, iż wiadomość roamingTrigger generowana jest w skutek utraty ramek typu Beacon. Na czas sekwencji roamingu składa się również interwał czasu spędzony poza zasięgiem punktów dostępowych.
Tablica 6.8: Wyniki scenariusza ExLinearMobilitySeparate.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
Interwał [sim t]
26.551064828600
26.401073882000
Scenariusz ExLinearMobilityDualInterfaceBoundary
Tab. 6.9 przedstawia wynikowe interwały czasowe. Wyniki są analogiczne do scenariusza
ExLinearMobilityDualInterfaceIntersecting 6.3.
Tablica 6.9: Wyniki scenariusza ExLinearMobilityDualInterfaceBoundary.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
Interwał [sim t]
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
0.001091241548
0.001065068788
0.001073988732
Scenariusz ExLinearMobilityBoundary
Tab. 6.10 przedstawia wynikowe interwały czasowe. Wyniki są analogiczne do scenariusza
ExLinearMobilityIntersecting 6.3. Wiersz tabeli z długim czasem sekwencji roamingu związany jest z zawracaniem stacji klienckiej poza obszarem zasięgu sygnału punktu dostępowego.
Tablica 6.10: Wyniki scenariusza ExLinearMobilityBoundary.
Kontekst nr 1 [nazwa]
Kontekst nr 2 [nazwa]
roamingTrigger
roamingTrigger
roamingTrigger
roamingSuccess
roamingSuccess
roamingSuccess
74
Interwał [sim t]
1.401073881990
26.551109855300
1.401046881990
Rozdział 7
Podsumowanie oceny rozwiązania
Na końcową ocenę metody wyzwalania przez sondowanie składają się wnioski z analizy
porównawczej wyników zawartych w rozdziale 6 oraz najważniejsze przesłanki z procesu wieloaspektowej analizy, projektowania oraz implementacji rozwiązania. Bazując na wynikach
z symulacji scenariuszy doświadczalnych przedstawiam sytuacje zwiększające efektywność
roamingu stacji klienckiej. Nakreślam przypadki, w których metoda wyzwalania przez sondowanie daje gorsze wyniki oraz wskazuję możliwe poprawki. Ostatecznie, określam dalsze
kierunki rozwoju badań w stronę rzeczywistej implementacji rozwiązań bazujących na definicji interfejsów równoległych.
7.1
Wnioski na temat wyników analizy porównawczej
Wyniki scenariuszy symulacyjnych pokazują, iż etap sondowania łącza jest najdłuższym
interwałem czasowym sekwencji roamingu. Zastosowanie interfejsów równoległych w postaci
metody wyzwalania przez sondowanie pozwoliło na zauważalne odciążenie procedury roamingu. Najbardziej pozytywne rezultaty osiągnięto w przypadku ruchu prostoliniowego przecinającego nakładające się obszary zasięgu punktów dostępowych. Scenariusz doświadczalny
ExLinearMobilityDualInterfaceIntersecting wykazał przyspieszenie sekwencji z około 1.75[s]
do pomijalnego czasu około 1[ms]. W tym przypadku czas sekwencji roamingu dla metody
wyzwalania przez sondowanie nie bierze pod uwagę etapu wyzwalania. Metoda wyzwalania przez sondowanie rozpoczyna sekwencję roamingu jeszcze w zasięgu połączenia punktu
dostępowego co powoduje całkowitą niwelację wpływu interwału wyzwalania na całościową
efektywność roamingu.
Uogólniając, metoda wyzwalania przez sondowanie daje bardzo dobre rezultaty w sytuacji, gdy możliwe jest wyzwolenie roamingu jeszcze w zasięgu poprzedniego punktu dostępowego. Przedwczesne porzucanie aktualnego punktu dostępowego ma swoje wady. Stacja
przemieszczająca się na skraju obszarów wpływu dwóch punktów dostępowych będzie nieustannie przełączała się między nimi ze względu na brak mechanizmu histerezy w algorytmie
wyboru najlepszego punktu dostępowego z listy dostępnych. Wyniki symulacyjne z wykorzystaniem konfiguracji pośredniej DualInterfaceHyst wykazują, że użycie wyników sondowania
75
łącza do implementacji histerezy może być problematyczne. Problemy wynikają z wyjątkowo
długiego interwału czasowego jakiego wymaga procedura sondowania aktywnego. Mechanizm
histerezy, który pomaga powstrzymać niepotrzebne wyzwolenia sekwencji roamingu w scenariuszu ExCircleMobilityDualInterfaceHystIntersecting może spowodować znaczne opóźnienie sekwencji roamingu w scenariuszu ExLinearMobilityDualInterfaceHystIntersecting. Należy jednak zwrócić uwagę, iż skuteczność sondowania łącza jako mechanizmu histerezy zależy od progu histerezy histThreshold. Przyjmuję, że stopień nakładania się obszarów zasięgu
punktów dostępowych w przypadku scenariusza ExCircleMobilityDualInterfaceHystIntersecting jest na tyle duży, że wyzwolenie roamingu nie jest zjawiskiem całkowicie negatywnym.
Zawyżone wartości parametrów minChannelTime oraz maxChannelTime sugerowane przez
modele INET pozwalają przypuszczać, że w realnym zastosowaniu proces sondowania byłby
bardziej efektywny. Zakładam, że realne rozwiązanie z dobrze dobranym progiem hystThreshold nie byłoby obarczone negatywnymi aspektami mechanizmu histerezy nawet przy dużych
prędkościach stacji klienckiej.
7.2
Wnioski z procesu analizy, projektowania i implementacji
rozwiązania
Tekst standardu IEEE802.11 nie wymusza ścisłej sekwencji roamingu, lecz udostępnia
opis niezbędnych usług warstw modelu OSI. Udostępnianie usług w postaci poleceń interfejsu
SAP daje pewną swobodę co do projektowania i implementacji procedur zarządzania stosem
protokołu IEEE802.11. Wnioskując, implementacja rozwiązań z wykorzystaniem interfejsów
równoległych nie wymaga ingerencji w implementację stosu protokołu IEEE802.11, lecz
odpowiedniego wykorzystania usług każdego z dostępnych interfejsów SAP.
Architektura warstwowa stosu protokołu IEEE802.11 jest spójna na przestrzeni:
– Jednostek funkcjonalnych standardu IEEE802.11,
– Modułów w hierarchii modeli projektu INET,
– Rzeczywistych elementów architektury komputerów.
Oznacza to, iż projekt metody wyzwalania przez sondowanie opisany z pomocą pojęć
standardu IEEE802.11 może być łatwo rozszerzony do projektu symulacyjnego oraz implementacyjnego.
Proces rozszerzania funkcjonalności modeli INET o metodę wyzwalania przez sondowanie
ujawnił możliwe problemy rzeczywistej implementacji. W szczególności, implementacja stosu
protokołu IEEE802.11 może zawierać pewne założenia co do kolejności wywoływania komend
interfejsu SAP. Założenia co do kolejności wywoływania komend mogą utrudnić podział zadań
między komponenty NIC. W rzeczywistej implementacji opisane ograniczenia mogą oznaczać
konieczność modyfikacji takich elementów stosu jak sterownik urządzenia lub oprogramowanie
typu firmware.
76
7.3
Kierunki rozwoju
Niniejsza praca zawiera wiele przesłanek, które wskazują, iż wykorzystanie interfejsów
równoległych jest możliwe oraz opłacalne z punktu widzenia efektywności roamingu mobilnej
stacji klienckiej. Następujące fakty przemawiają za kierunkiem rozwoju rzeczywistej implementacji metody wyzwalania przez sondowanie:
– Szeroki wybór maszyn umożliwiających zastosowanie wielu komponentów NIC,
– Odzwierciedlenie interfejsu SAP jednostki zarządzającej w rzeczywistych implementacjach (np. interfejs netlink lub ioctl w systemach Linux ),
– Możliwość wykorzystania niektórych rozdziałów pracy w postaci wzorca do implementacji,
– Pozytywne wyniki stworzonych modeli symulacyjnych.
Komendy interfejsu SAP 4.3 użyte w projekcie implementacyjnym modeli symulacyjnych
można łatwo przełożyć na polecenia wykorzystywane przez niektóre narzędzia przestrzeni
użytkownika w systemach Linux. W systemach Linux sterowanie urządzeniami standardu
IEEE802.11 odbywa się z udziałem opartego na mechanizmie gniazd (ang. sockets) interfejsu netlink lub opartego na mechanizmie wywołań systemowych interfejsu ioctl. Polecenia
interfejsu netlink odpowiadają komendom SAP 4.3.
Dobre wyniki dla scenariusza ExLinearMobilityDualInterfaceIntersecting potwierdzają
potencjalną skuteczność w zastosowaniach WAVE (ang. wireless access in vehicular environments). Środowisko scenariusza ExLinearMobilityDualInterfaceIntersecting można przedstawić w postaci wycinka rzeczywistej infrastruktury. Prostoliniowy ruch stacji klienckiej
odpowiada jezdni przecinającej obszary zasięgu kolejnych punktów dostępowych. Obszary
zasięgu nakładają się w celu podtrzymania komunikacji.
Niniejsza praca wykazuje korzyści płynące z zwielokrotnienia komponentów NIC, które
mają potencjał wykraczania poza zagadnienie efektywności roamingu stacji klienckiej. Rozwiązanie interfejsów równoległych może być z powodzeniem zastosowane do przekraczania
fizycznych ograniczeń urządzeń komunikacyjnych z pomocą logiki wyższych warstw systemu
komputerowego.
77
Bibliografia
[1] Joe Bardwell. The Truth About 802.11 Signal And Noise Metrics. Connect802 Corporation, 2004.
[2] Joe Bardwell. Converting Signal Strength Percentage to dBm Values. WildPackets, Inc.,
październik 2002.
[3] Michael Bredel and Martin Bergner. On The Accuracy of IEEE 802.11g Wireless LAN
Simulations Using OMNeT++. OMNeT++ 2009 Workshop, 2009.
[4] German Castignani, Nicolas Montavont, Andres Arcia-Moret, Mohamed Oularbi, and
Sebastien Houcke. IEEE 802.11 Scanning Algorithms: Cross-Layer Experiments. TELECOM Bretagne, 20 październik 2011.
[5] Cisco. Voice over Wireless LAN 4.1 Design Guide. http://www.cisco.com/en/US/
docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan_ch5.html, 18 styczeń
2010.
[6] Projekt open-source. INET framework. http://inet.omnetpp.org/.
[7] M. Harasimczuk. Pomiar opóźnień ramek standardu 802.11 - narzędzie hop-sniffer. Praca
inżynierska, Wydział Elektroniki i Technik Informacyjnych Politechniki Warszawskiej,
2012.
[8] IEEE.
Standard IEEE802.11-2012.
download/802.11-2012.pdf.
http://standards.ieee.org/getieee802/
[9] Glenn Judd and Peter Steenkiste. Fixing 802.11 Access Point Selection. Carnegie Mellon
University, 2002.
[10] Open source wiki. OMNet++ Wiki. http://www.omnetpp.org/pmwiki/.
[11] Andras Varga. OMNet++ User Manual Version 4.3.1. Andras Varga and OpenSim Ltd.,
2011.
78
Dodatek A
Załączniki
A.1
Odtworzenie środowiska symulacyjnego.
Odtwarzanie środowiska symulacyjnego opisywane jest z perspektywy zestawu narzędzi
dostępnych w dystrybucji Ubuntu systemu operacyjnego Linux.
Zawartość płyty CD
Płyta CD zawiera katalog Projekt, w którym znajdują się pliki źródłowe niezbędne do
uruchomienia środowiska symulacyjnego. Ścieżki podawane w dalszej części tego załącznika
zakładają, iż katalog Projekt jest katalogiem bieżącym stosując notację ./.
Katalog ./omnetpp-4.3.1-src.tgz zawiera pliki źródłowe środowiska symulacyjnego
OMNet++ w wersji wykorzystywanej w badaniach. Katalog ./inet.tar.gz zawiera zmodyfikowane źródła projektu INET. Źródła przeznaczone są do kompilacji w dystrybucjach opartych
o system operacyjny Linux.
Katalog Projekt powinien być przekopiowany na nośnik umożliwiający zapis. Katalogi
./inet.tar.gz oraz ./omnetpp-4.3.1-src.tgz powinny zostać rozpakowane z użyciem komendy
tar z opcjami -zxvf.
Kompilacja i instalacja symulatora OMNet++
Należy wejść
który zainstaluje
do prawidłowego
przedstawione na
do katalogu ./omnetpp-4.3.1 i wywołać skrypt sudo ./install-packages,
wszystkie wymagane paczki. Skrypt instaluje również paczki potrzebne
działania aplikacji elog-parser.py. Następnie, należy wykonać polecenia
listingu A.1.
Listing A.1: Polecenia inicjalizacji środowiska kompilacji.
1
. setenv
echo ” e x p o r t PATH=$PATH:$HOME/omnetpp − 4 . 3 . 1 / b i n ” >> ˜ / . b a s h r c
Należy zamknąć i ponownie uruchomić terminal. Po ponownym wejściu do katalogu
./omnetpp-4.3.1 należy wywołać skrypt ./configure. Skrypt sprawdza obecność niezbędnych
79
paczek w systemie. Należy zwrócić uwagę na ostatnie linijki wypisane na standardowe wyjście.
Zgodnie z instrukcją należy dodać reguły export dwóch podanych na standardowym wyjściu
ścieżek do pliku ˜/.profile oraz wylogować się. Po ponownym zalogowaniu należy wejść do
katalogu ./omnetpp-4.3.1 i wywołać skrypt ./configure zwracając uwagę na potwierdzenie
obecności wymaganych ścieżek, którego przykład przedstawia listing A.2.
Listing A.2: Fragment standardowego wyjścia skryptu ./configure
Your PATH c o n t a i n s /home/ hary / S t u d i a / Symulator /omnetpp − 4 . 3 . 1 / b i n . Good !
2
TCL LIBRARY i s s e t . Good !
W kolejnym kroku można rozpocząć kompilację wydając polecenie make. Po zakończeniu
kompilacji i instalacji symulator można uruchomić komendą omnetpp.
Kompilacja źródeł projektu INET
Należy uruchomić symulator OMNet++ pozostawiając standardową ścieżkę do katalogu
roboczego ./omnetpp-4.3.1/samples. Należy załadować projekt INET do środowiska wybierając kolejno File, Import, General, Existing Projects Into Workspace oraz Next. Należy odnaleźć rozpakowany katalog ze źródłami projektu INET, dodać go i zakończyć wybierając
opcję Finish.
W celu kompilacji należy wybrać kolejno menu rozwijane Project oraz pozycję Build
All. Po zakończeniu kompilacji można rozpocząć uruchamianie symulacji. W widoku Project
Explorer należy odnaleźć plik ./inet/simulations/roaming/basic/omnetpp.ini i zaznaczyć go.
Opcja Run z rozwijanego menu Run pozwala na uruchomienie graficznego interfejsu przebiegu
symulacji. Pierwszym otwartym oknem jest okno wyboru scenariusza doświadczalnego oraz
numeru przebiegu. Wybór opcji OK powoduje otwarcie widoku obszaru roboczego. Przycisk
RUN uruchamia symulację scenariusza doświadczalnego.
Wsadowe uruchamianie scenariuszy doświadczalnych
Należy wejść do katalogu ./inet/simulations/roaming/basic. W katalogu znajdują się pliki
niezbędne do uruchomienia symulacji:
– omnetpp.ini : Plik z konfiguracją parametrów opisujących scenariusze doświadczalne,
– conf.xml : Plik konfiguracyjny programu elog-parser.py,
– elog-parser.py: Skrypt programu elog-parser,
– run experiments: Skrypt uruchamiający wybrane scenariusze doświadczalne oraz przekierowujący wyniki działania programu elog-parser na standardowe wyjście.
Proces symulacji uruchamia się wywołaniem skryptu ./run experiments. Należy pamiętać
o wcześniejszej instalacji wymaganych paczek.
80