PUMA-TCS nowy protokó³ warstwy MAC ze wsparciem jakoœci œwiadczonych us³ug

Telekomunikacja Cyfrowa Technologie i Us³ugi Tom 10. Rok 2010/2011 PUMA-TCS nowy protokó³ warstwy MAC ze wsparciem jakoœci œwiadczonych us³ug Marek Natkaniec, Katarzyna Kosek-Szott, Szymon Szott (e-mail: {natkaniec, kosek, szott}@kt.agh.edu.pl) AGH Akademia Górniczo-Hutnicza w Krakowie STRESZCZENIE W ostatnich latach obserwujemy rosn¹c¹ potrzebê zapewnienia odpowiedniej jakoœci œwiadczonych us³ug w lokalnych sieciach bezprzewodowych. W tym celu opracowany zosta³ standard IEEE 802.11e. Niestety, jak pokazuj¹ badania naukowe, nie jest on pozbawiony wad. W prezentowanej pracy zaproponowano nowy protokó³ o nazwie PUMA-TCS (Priority Unavoidable Multiple Access with Traffic Category Support) pozwalaj¹cy na lepsze ró nicowanie ruchu oraz wiêksze gwarancje œwiadczenia us³ug z okreœlon¹ jakoœci¹. W pracy zawarto równie wyniki badañ oraz analizê porównawcz¹ obu protoko³ów, przeprowadzonych przy u yciu wybranych symulatorów sieci bezprzewodowych, co pozwoli³o wskazaæ zalety oraz wady badanych metod dostêpu. S³owa kluczowe: protokó³ PUMA, funkcja EDCA, jakoœæ obs³ugi QoS, ró nicowanie ruchu, mechanizm priorytetów, analiza symulacyjna ABSTRACT PUMA-TCS a New MAC Layer Protocol with QoS Support There is a growing interest in QoS provisioning for wireless local area networks in recent years. Because of this, the IEEE 802.11e standard was introduced. Unfortunately, a few research papers show, that it has a number of serious flaws. The presented work describes a new protocol called PUMA-TCS (Priority Unavoidable Multiple Access with Traffic Category Support), that allows for better than IEEE 802.11e traffic differentiation and QoS guarantees. Research results and comparative analysis of protocols using selected simulators are also included in the paper. This allows to reveal a pros and cons of both channel access schemes. Key words: PUMA protocol, EDCA function, quality of service QoS, traffic differentiation, priorities mechanism, simulation analysis 1. Wstêp Lokalne sieci bezprzewodowe WLANs (Wireless Local Area Networks) pozwalaj¹ na szybkie i tanie ³¹czenie komputerów bêd¹cych w sieci teleinformatycznej. Ich ³atwa instalacja oraz du a funkcjonalnoœæ maj¹ ogromne znaczenie w wielu dziedzinach ycia. Sieci te s¹ idealnym rozwi¹zaniem dla posiadaczy urz¹dzeñ przenoœnych, takich jak laptopy, netbooki, nowoczesne telefony komórkowe lub PDA (Personal Digital Assistant). Wiêkszoœæ obecnych zastosowañ lokalnych sieci bezprzewodowych stanowi asynchroniczny transfer danych, jednak oczekuje siê wzrostu zainteresowania us³ugami multimedialnymi. W kanale bezprzewodowym stosunkowo trudno jest zapewniæ odpowiednie parametry strumienia danych. Z³o ony proces sterowania dostêpem do kana³u radiowego oraz zmienne warunki propagacji sygna³ów (charakterystyczne dla ³¹czy radiowych) s¹ powa nym utrudnieniem dla zapewniania odpowiedniej jakoœci us³ug ró nego typu. Wszystkie licz¹ce siê organizacje standaryzacyjne podjê³y odpowiednie kroki w celu opracowania mechanizmów gwarantowania wymaganej jakoœci œwiadczonych us³ug. Jakoœæ œwiadczonych us³ug (ang. Quality of Service, QoS) jest jednym z g³ównych parametrów charakteryzuj¹cych ka dego us³ugodawcê oraz kluczowym elementem branym pod uwagê przez us³ugobiorców. Przek³ada siê ona przede wszystkim na stopieñ zaspokojenia potrzeb klienta. Niestety w rzeczywistoœci okazuje siê, e œwiadczenie jednej us³ugi z odpowiedni¹ jakoœci¹ czêsto wi¹ e siê z koniecznoœci¹ pogorszenia jakoœci œwiadczenia innej us³ugi. Obecnie najbardziej rozpowszechnionym standardem dla sieci WLAN jest standard IEEE 802.11 [1]. Pierwsza wersja tego standardu zosta³a zatwierdzona w 1997 roku przez organizacjê IEEE (Institute of Electrical and Electronics Engineers) i posiada zaimplementowane mechanizmy rywalizacyjnego dostêpu do kana³u (funkcja DCF Distributed Coordination Function) oraz podstawowe wsparcie dla realizacji ruchu izochronicznego (funkcja PCF Point Coordination Function). Standard ten nie by³ tworzony z myœl¹ o gwarantowaniu wszystkich parametrów QoS, niezbêdnych dla œwiadczenia us³ug z okreœlon¹ jakoœci¹. Dopiero standard IEEE 802.11e [2], zatwierdzony w 2005 roku, wprowadzi³ nowe mechanizmy w sposobie dostêpu do kana³u radiowego. To w³aœnie na poziomie dostêpu do medium transmisyjnego nale y rozstrzygn¹æ roszczenia stacji do uzyskania praw do transmisji. Sprawiedliwy, bior¹cy pod uwagê priorytet przesy³anego ruchu, mechanizm kontroli dostêpu do kana³u radiowego powinien pozwalaæ na zapewnienie odpowiedniego poziomu QoS. W standardzie IEEE 802.11e zdefiniowane zosta³y 44

funkcje HCCA (HCF Controlled Channel Access), przeznaczona do pracy z u yciem centralnego koordynatora i EDCA (Enhanced Distributed Channel Access), przeznaczona dla sieci ad-hoc, które gwarantuj¹ okreœlony poziom QoS. W obecnej wersji standardu IEEE 802.11, z roku 2007 [1], dokonano integracji czêœci rozszerzeñ standardu, w tym równie rozszerzenia IEEE 802.11e. Analizê wydajnoœci pracy standardu IEEE 802.11e mo na odnaleÿæ w wielu pozycjach literaturowych. W pracy [3] przedstawiono badania funkcji EDCA i HCCA z wykorzystaniem symulacji komputerowych. W innej pracy badana by³a sprawiedliwoœæ dostêpu dla przypadku, gdy kilka sieci BSS (Basic Service Set) wspó³dzieli pewien obszar geograficzny u ywaj¹c do pracy tego samego kana³u radiowego [4]. Publikacja [5] równie przedstawia badanie wydajnoœci funkcji EDCA rozszerzone o mo liwoœæ wielokrotnej transmisji w ramach okresu TXOP (Transmission Opportunity). Opracowano i opublikowano równie wiele modeli matematycznych funkcji EDCA [6 9]. Niestety z przeprowadzonych badañ wynika, e tryb EDCA standardu IEEE 802.11e nie jest pozbawiony wad. Odpowiedni poziom QoS mo e byæ bowiem zapewniony tylko w sposób statystyczny, poprzez zmniejszenie prawdopodobieñstwa dostêpu do kana³u radiowego ramkom nale ¹cym do ni szej kategorii ruchowej. Taki sposób rywalizacji nie daje gwarancji, e ramki o wy szym priorytecie bêd¹ zawsze nadane przed ramkami o ni szym priorytecie. Proces ten przyczynia siê do wzrostu wariancji opóÿnienia dla ramek o wysokim priorytecie w warunkach nadawania ramek przez stacje o niskim priorytecie. Kolejny problem wystêpuj¹cy w standardzie IEEE 802.11e jest zwi¹zany z wystêpowaniem d³ugich okresów oczekiwania na dostêp do kana³u radiowego (backoff) dla stacji nadaj¹cych ruch o niskim priorytecie. Okresy spowodowane dzia³aniem licznika backoff s¹ wtedy du o d³u sze ni w przypadku standardowej funkcji DCF, co powoduje degradacjê wydajnoœci pracy sieci. Wady istniej¹cych protoko³ów i standardów przyczyniaj¹ siê do powstawania rozwi¹zañ alternatywnych. Takim przyk³adem jest protokó³ PUMA-TCS (Priority Unavoidable Multiple Access with Traffic Category Support) opracowany w Katedrze Telekomunikacji AGH, który zostanie szczegó³owo przedstawiony w niniejszej pracy. Protokó³ PUMA-TCS wykorzystuje rywalizacyjny dostêp do kana³u radiowego z u yciem tzw. twardych priorytetów i nie posiada g³ównych wad protoko³u EDCA. Przyjêto nastêpuj¹cy uk³ad pracy. W rozdziale drugim opisano protokó³ EDCA. Rozdzia³ trzeci zawiera opis dzia³ania protoko³u PUMA-TCS. W rozdziale czwartym zawarto wyniki badañ symulacyjnych protoko³u PUMA-TCS, które zosta³y porównane z wynikami uzyskanymi dla protoko³u EDCA. Ostatni rozdzia³ zawiera najciekawsze wnioski uzyskane z analizy przeprowadzonych badañ. 2. Funkcja EDCA standardu IEEE 802.11 Architektura warstwy MAC sieci standardu IEEE 802.11e zosta³a zaprojektowana tak, aby zapewniæ maksymaln¹ mo liw¹ kompatybilnoœæ ze starszymi sieciami standardu IEEE 802.11. Podczas standaryzacji zadbano o to, aby ju istniej¹ce na ca³ym œwiecie sieci standardu IEEE 802.11 ³atwo migrowa³y w kierunku standardu IEEE 802.11e. Zasadnicza zmiana w architekturze MAC polega na implementacji funkcji koordynuj¹cej HCF (Hybryd Coordination Function) z dwoma ró nymi mechanizmami dostêpu do kana³u radiowego. Pierwszy z nich to EDCA, bêd¹cy ulepszon¹ wersj¹ podstawowego trybu DCF. Natomiast drugi to odpowiednik dawnego PCF, okreœlany mianem HCCA. Funkcja EDCA jest obowi¹zkowa zarówno dla trybu pracy z infrastruktur¹, jak i dla sieci ad-hoc, podobnie jak funkcja DCF zdefiniowana w podstawowym standardzie IEEE 802.11. Architekturê warstwy MAC standardu IEEE 802.11e przedstawia rysunek 1. Rys. 1. Architektura warstwy MAC standardu IEEE 802.11e 45

Z punktu widzenia modeli QoS dzia³anie trybu EDCA jest analogiczne do architektury us³ug zró nicowanych DiffServ ruch generowany jest agregowany w strumienie zbiorcze (tzw. klasy ruchu) o ró nym priorytecie i przekazywany zgodnie z parametrami obowi¹zuj¹cymi dla danej klasy ruchu. EDCA mo e realizowaæ jedynie miêkkie gwarancje jakoœci (ang., soft QoS). W przypadku trybu HCCA mamy do czynienia z rozwi¹zaniem zbli onym do modelu us³ug zintegrowanych IntServ zapewnienie jakoœci przekazu ramek odbywa siê na poziomie pojedynczych strumieni z wykorzystaniem deskryptorów ruchu TC (Traffic Category). Mechanizm HCCA reprezentuje podejœcie iloœciowe, dziêki czemu zapewnia on œciœlejsze gwarancje jakoœciowe w porównaniu z trybem EDCA. Mechanizm EDCA umo liwia odwzorowanie ruchu wychodz¹cego ze stacji obs³uguj¹cej QoS na maksymalnie cztery zdefiniowane klasy ruchu, okreœlane równie jako kategorie dostêpu AC (Access Categories): G³os AC_VO (Voice) Wideo AC_VI (Video) Ruch bez wymagañ AC_BE (Best Effort) Ruch t³a AC_BK (Background) Ka da klasa ruchu posiada niezale n¹ kolejkê sprzêtow¹, w której s¹ buforowane ramki warstwy MAC przed wys³aniem ich do kana³u radiowego. We wstêpnej fazie ró nicowania ruchu, jednostkom danych pochodz¹cym z warstw wy szych modelu ISO/OSI przypisywany jest jeden z oœmiu dostêpnych priorytetów u ytkownika UP (User Priority). Informacja o UP jest przenoszona przez pole TID (Traffic IDentifier) nag³ówka ramki danych. Dopiero po tej klasyfikacji nastêpuje przypisanie priorytetu u ytkownika do kategorii dostêpu, wed³ug schematu przedstawionego w tabeli 1. Tabela 1 Rekomendowany schemat przypisywania priorytetów u ytkownika do klasy ruchu, zgodnie ze standardem IEEE 802.1D oraz kategoriami dostêpu IEEE 802.11e [1] Priorytet Odpowiednik Kategoria Priorytet priorytetu Oznaczenie dostêpu u ytkownika zgodny z 802.11e 802.11e Najni szy 1 BK AC_BK Background 2 AC_BK Background 0 BE AC_BE Best Effort 3 EE AC_BE Best Effort 4 CL AC_VI Video 5 VI AC_VI Video 6 VO AC_VO Voice Najwy szy 7 NC AC_VO Voice Zró nicowanie parametrów dostêpu do kana³u radiowego dla poszczególnych klas ruchu umo liwi³o nadawanie im priorytetów. Prawdopodobieñstwo rozpoczêcia transmisji przez dan¹ klasê ruchu jest uzale nione od indywidualnego zestawu czterech parametrów: CW MIN [AC]/CW MAX [AC] okreœla minimaln¹/maksymaln¹ d³ugoœæ przedzia³u, z którego losowane jest okno rywalizacji CW[AC] dla danej kategorii dostêpu, wykorzystywanego przez algorytm backoff do losowego opóÿnienia rozpoczêcia transmisji. Mniejsze wartoœci parametrów CW MIN i CW MAX zapewniaj¹ statystycznie krótszy czas oczekiwania na dostêp do kana³u radiowego, dlatego s¹ one charakterystyczne dla klas ruchu o wy szych priorytetach, AIFSN[AC] parametr przyjmuj¹cy wartoœci ca³kowite z przedzia³u [2,?), na podstawie którego wyznaczany jest arbitra owy odstêp miêdzyramkowy AIFS[AC] (Arbitration InterFrame Space), bêd¹cy odpowiednikiem okresu DIFS w trybie podstawowym DCF: AIFS[AC] = SIFS + AIFSN[AC] SlotTime (1) gdzie AIFS[AC] DIFS. Zazwyczaj kategorii dostêpu o najwy szym priorytecie przypisuje siê najmniejsz¹ z mo liwych wartoœci parametru AIFS równ¹ DIFS. W przypadku wspó³istnienia na danym obszarze stacji korzystaj¹cych zarówno z funkcji DCF, jak i EDCA, wystêpuje brak ró nicowania ramek o wy szym priorytecie w stosunku do ramek wysy³anych przez stacje wykorzystuj¹ce DCF. TXOP Limit[AC] okreœla przedzia³ czasu, w którym stacja ma prawo do rozpoczêcia transmisji jednej lub wiêkszej liczby ramek nale ¹cych do danej klasy ruchu, bez koniecznoœci wykonywania ka dorazowo procedury backoff, pod warunkiem, e sumaryczny czas zajêtoœci kana³u radiowego nie przekroczy okresu TXOP Limit [AC]. W przypadku, gdy wartoœæ tego parametru jest zerowa, klasa ruchu mo e wys³aæ tylko jedn¹ ramkê, po czym jest zobowi¹zana do natychmiastowego zwolnienia kana³u radiowego. Standard IEEE 802.11 nie narzuca jednego zestawu wartoœci, jakie powinny przyjmowaæ powy sze parametry dostêpu do kana³u radiowego. Zamiast tego dostarcza formu³y opisuj¹ce zale noœci pomiêdzy parametrami oraz innymi czynnikami, takimi jak np. rodzaj wykorzystywanej warstwy fizycznej (tab. 2). Zaproponowany schemat nadawania priorytetów dostêpu do kana³u radiowego w obrêbie pojedynczej stacji najlepiej obrazuj¹ zale noœci czasowe pomiêdzy poszczególnymi klasami ruchu, przedstawione na rysunku 2. Z uwagi na du o wiêksze wartoœci parametrów CW MIN, CW MAX oraz AIFSN, dla kategorii dostêpu o ni szym priorytecie (BE i BK), w sytuacji pe³nego na- 46

Tabela 2 Zalecane wartoœci parametrów dostêpu do kana³u radiowego dla trybu EDCA [1] Klasa ruchu CW MIN CW MAX AIFSN TXOP DSSS OFDM Inne AC_BK acw MIN acw MAX 7 0 0 0 AC_BE acw MIN acw MAX 3 0 0 0 AC_VI (acw MIN +1)/2-1 acw MIN 2 6,016 ms 3,008 ms 0 AC_VO (acw MIN +1)/4-1 (acw MIN +1)/2 1 2 3,264 ms 1,504 ms 0 Rys. 2. Zale noœci czasowe pomiêdzy kategoriami dostêpu w trybie EDCA sycenia kana³u radiowego, w przypadku jednoczesnego wystêpowania ruchu o wy szym priorytecie, przepustowoœæ znacznie siê zmniejsza. Efekt ten jest potêgowany przez niezerowe wartoœci parametru TXOP Limit dla kategorii dostêpu VI oraz VO. Dla funkcji EDCA mo liwe s¹ kolizje fizyczne i wirtualne. Kolizja fizyczna wystêpuje wtedy, kiedy dwie lub wiêcej stacji próbuje jednoczeœnie rozpocz¹æ nadawanie w tym samym kanale radiowym, a kolizja wirtualna jest to kolizja wystêpuj¹ca w obrêbie jednej stacji, podczas rywalizacji ramek pochodz¹cych z ró nych klas ruchu (kolejek sprzêtowych). Za rozwi¹zywanie problemu kolizji wirtualnych jest odpowiedzialny specjalny modu³, tzw. Virtual Collision Handler, który decyduje o przyznaniu prawa do transmisji klasie ruchu o wy- szym priorytecie. Natomiast kolejka skojarzona z kategori¹ dostêpu o ni szym priorytecie zachowuje siê tak, jakby wyst¹pi³a kolizja fizyczna, czyli wykonuje standardow¹ procedurê backoff. Wszystkie zdefiniowane regu- ³y oznaczaj¹, e transmisja jednostki danych warstwy MAC przynale nej do okreœlonej klasy ruchu mo e siê rozpocz¹æ tylko i wy³¹cznie wtedy, gdy spe³nione s¹ wszystkie poni sze warunki: Kana³ radiowy by³ w stanie bezczynnoœci przez okres czasu nie krótszy ni wartoœæ parametru AIFS dla danej klasy. Licznik backoff timer zwi¹zany z okreœlon¹ klas¹ ruchu osi¹gn¹³ wartoœæ zerow¹. Nie zosta³a stwierdzona kolizja fizyczna ani wirtualna lub te mia³a miejsce wy³¹cznie kolizja wirtualna, przy czym klasa, dla której wyst¹pi³a kolizja, posiada³a najwy szy priorytet ze wszystkich klas rywalizuj¹cych o dostêp do kana³u radiowego. 3. Zasada dzia³ania protoko³u PUMA-TCS Alternatyw¹ dla funkcji DCF standardu IEEE 802.11 by³o opracowanie protoko³u PUMA, bêd¹cego rozszerzeniem funkcji DCF [10]. Dostêpne badania naukowe pokazuj¹, e funkcja DCF posiada m.in. nastêpuj¹ce wady: mo liwoœæ transmisji tylko ruchu asynchronicznego, ma³¹ wydajnoœæ pracy w przypadku du ej liczby stacji nadaj¹cych du e wielkoœci ruchu, oraz niesprawiedliwy dostêp do kana³u radiowego. Autorzy protoko³u PUMA starali siê usun¹æ te problemy, jednoczeœnie pozwalaj¹c na ³atwe wprowadzenie zmian w kartach bezprzewodowych poprzez zmianê oprogramowania (firmware). Protokó³ PUMA, dedykowany do pracy w sieciach ad-hoc, mo e wykorzystywaæ wszystkie rodzaje technik warstwy fizycznej. G³ówn¹ wad¹ protoko³u PUMA jest wsparcie tylko jednej dodatkowej klasy ruchu. 47

Rozszerzeniem protoko³u PUMA, pozwalaj¹cym na zdefiniowanie wielu rodzajów kategorii przesy³anego ruchu, jest protokó³ PUMA-TCS. Zmiany wprowadzone w protokole PUMA-TCS w stosunku do pierwotnego PUMA pozwalaj¹ na ³atw¹ implementacjê tego protoko- ³u poprzez dalsze zaktualizowanie oprogramowania firmware kart bezprzewodowych. Protokó³ PUMA-TCS definiuje piêæ ró nych priorytetów oraz klasê ruchu typu best effort priorytet 1 jest najwy szym, a 5 najni szym z mo liwych. Ramki s³u ¹ce do zarz¹dzania sieci¹, jako najistotniejsze, posiadaj¹ priorytet 1. Z kolei ramki przenosz¹ce ruch g³osowy posiadaj¹ priorytet 2. Priorytet 3 jest przeznaczony dla ramek wideo. Aplikacje istotne dla u ytkownika (np. transakcje bankowe) generuj¹ dane traktowane z priorytetem 4. Priorytet 5 zosta³ zdefiniowany dla ruchu typu excellent effort. Tabela 3 przedstawia proponowany przydzia³ priorytetów. Tabela 3 Przydzia³ priorytetów zdefiniowany w protokole PUMA-TCS Priorytet Typ ruchu Opis 1 Zarz¹dzanie sieci¹ 2 G³os 3 Wideo 4 Kontrolowane obci¹ enie 5 Excellent effort Dane s³u ¹ce do utrzymania sieci OpóŸnienie nie wiêksze ni 50 ms, bardzo ma³y jitter OpóŸnienie nie wiêksze ni 150 ms Aplikacje transakcyjne Us³ugi œwiadczone wa nym klientom Best effort Ruch asynchroniczny Podobnie jak w przypadku protoko³u PUMA, jego nastêpca równie wykorzystuje trzy przedzia³y czasowe: SIFS, PIFS, oraz DIFS (DIFS>PIFS>SIFS). Nadawanie priorytetów ramkom realizowane jest za pomoc¹ dodatkowych sygna³ów JAM, których odpowiednia liczba przypisana jest do poszczególnych priorytetów. Wszystkie stacje, które chc¹ wys³aæ ramki, musz¹ zaczekaæ, a kana³ radiowy bêdzie wolny przez czas PIFS. Nastêpnie stacje posiadaj¹ce ramki o okreœlonym priorytecie zaczynaj¹ wysy³aæ sygna³y JAM, których liczba zale y od priorytetu ramki oczekuj¹cej na wys³anie. Im wy szy priorytet, tym liczba wysy³anych sygna³ów JAM jest wiêksza. Dla priorytetu 1 jest to 5 sygna³ów, dla priorytetu 2 s¹ to 4 sygna³y, itd. Wysy³anie sygna³ów JAM s³u y do poinformowania innych stacji o priorytecie ramki, która ma byæ wys³ana. Je eli po wys³aniu sygna³ów JAM kana³ radiowy jest wolny (tzn. adna inna stacja nie wysy³a sygna³ów JAM) oznacza to, e w danym momencie adna inna stacja nie posiada ramki o wy szym priorytecie, zatem stacja o najwy - szym priorytecie mo e zacz¹æ procedurê backoff. Pozosta³e stacje powinny wstrzymywaæ swoje transmisje do momentu otrzymania ramki RTS lub CTS, dziêki którym bêd¹ mog³y uaktualniæ swój wektor zajêtoœci ³¹cza NAV i czekaæ na zakoñczenie bie ¹cej transmisji, eby ponownie wzi¹æ udzia³ w rywalizacji o dostêp do kana³u radiowego. Rysunek 3 przedstawia proces dostêpu do kana³u radiowego z u yciem sygna³ów JAM. Nale y zwróciæ uwagê, e stacji, które wys³a³y tak¹ sam¹ liczbê sygna³ów JAM, a wiêc posiada³y ramki o tym samym priorytecie, mo e byæ wiêcej ni jedna. Rywalizacja miêdzy nimi o dostêp do kana³u radiowego realizowana jest podczas standardowego mechanizmu odczekiwania backoff, czyli losowania odpowiedniej liczby szczelin czasowych, które stacja musi odczekaæ, zanim bêdzie mog³a nadaæ ramkê RTS. Odbiorca tej ramki, po czasie SIFS, przesy³a potwierdzenie w postaci ramki CTS. Nastêpnie pomiêdzy nadawc¹ i odbiorc¹ wymieniane s¹ ramki danych. Równoczeœnie realizowana jest aktualizacja wektora NAV przez wszystkie stacje bêd¹ce w stanie poprawnie odebraæ wymienione ramki. Kolejn¹ zmian¹ w porównaniu z protoko³em PUMA jest wprowadzenie liczników dla ka dej ze zdefiniowanych klas ruchu. Liczniki te, podobnie jak licznik T2 wykorzystywany w protokole PUMA [6], s³u ¹ do skalowania ru- Rys. 3. Dostêp do kana³u radiowego realizowany w przypadku nadawania ramek z priorytetem, stosowany w protokole PUMA-TCS 48

chu dla ró nych priorytetów. Przypisana ramce wartoœæ licznika jest stopniowo zmniejszana. Je eli wartoœæ ta osi¹gnie zero, ramce zostanie podniesiony priorytet (o jeden), co zwiêksza jej szanse na wys³anie podczas kolejnego okresu rywalizacji. Oznacza to, e niezale - nie od obci¹ enia sieci, ramka po pewnym czasie zostanie dopuszczona do rywalizacji z ramkami o wy- szych priorytetach. Protokó³ PUMA-TCS zabrania jednak przekszta³cania w ten sposób ramek priorytetu nr 2 w ramki priorytetu nr 1. Ma to na celu zapewnienie poprawnej pracy sieci i uzyskanie minimalnych wartoœci opóÿnieñ w przypadku przesy³ania ruchu zarz¹dzaj¹cego sieci¹. Podobnie jak w przypadku protoko³u PUMA, zastosowano zmodyfikowany algorytm wyboru szczeliny z okna wspó³zawodnictwa DIDD (Double Increment Double Decrement) [11]. W celu dalszego zwiêkszenia wydajnoœci transmisji, szczególnie podczas nadawania ramek o ma³ej d³ugoœci, w protokole PUMA-TCS, podobnie jak w protokole PUMA, wykorzystano mechanizm packet-train [6]. Jego dzia³anie przypomina realizacjê mechanizmu TXOP stosowanego w trybie EDCA. Asynchroniczny tryb transmisji u yty po czasie DIFS pozosta³ bez zmian i jest zgodny z funkcj¹ DCF standardu IEEE 802.11. 4. Analiza symulacyjna protoko³u PUMA-TCS Rys. 4. Sieæ ad-hoc standardu IEEE 802.11 Do przeprowadzenia analizy symulacyjnej protoko³u PUMA-TCS pos³u ono siê specjalnie do tego celu napisanym symulatorem w jêzyku Java. Symulator skonstruowany zosta³ w oparciu o g³ówn¹ kolejkê zdarzeñ. W kolejce tej przechowywane s¹ dzia³ania, jakie bêd¹ wykonywane w kolejnoœci ustalonej wed³ug pola czasu, które posiada ka de ze zdarzeñ. Przeprowadzone symulacje zosta³y podzielone w taki sposób, aby jak najlepiej ukazaæ podobieñstwa i ró nice dwóch badanych funkcji dostêpu do medium: EDCA i PUMA-TCS. Badania przeprowadzone zosta³y dla sieci ad-hoc, pokazanej na rysunku 4. Rodzaj przesy³anego ruchu oraz liczba stacji uczestnicz¹cych w transmisji zosta³y szczegó- ³owo opisane na pocz¹tku ka dego scenariusza. Wszystkie stacje by³y w swoim zasiêgu radiowym, co oznacza, e w sieci nie wystêpowa³ przypadek stacji ukrytych. Parametry protoko³ów zosta³y ustalone tak, aby odpowiada³y za³o eniom przyjêtym dla warstwy fizycznej standardu IEEE 802.11b. Niektóre z przyjêtych parametrów ulega³y zmianie w trakcie przeprowadzanych symulacji. Najwa niejsze przyjête parametry zosta³y przedstawione w tabeli 4. Pozosta³e wartoœci parametrów by³y zgodne ze standardem IEEE 802.11[1]. Tabela 4 Wartoœci parametrów protoko³ów PUMA-TCS i EDCA przyjête podczas symulacji Parametr PUMA-TCS EDCA Czas trwania szczeliny czasowej Time Slot [ìs] 20 20 Czas trwania odstêpu SIFS [ìs] 10 10 Czas trwania odstêpu PIFS [ìs] 30 30 Czas trwania odstêpu DIFS [ìs] 50 50 Czas trwania sygna³u JAM [ìs] 20 CW MIN dla P1 CW MAX dla P1 CW MIN dla P2 CW MAX dla P2 CW MIN dla P3 CW MAX dla P3 CW MIN dla P4 CW MAX dla P4 CW MIN dla P5 CW MAX dla P5 7 7 15 15 7 15 15 31 15 31 31 1023 31 31 1023 1023 31 1023 Przeprowadzone symulacje prowadzi³y do okreœlenia charakterystyk dla stanu ustalonego. Badania realizowano w taki sposób, aby warunki pocz¹tkowe nie obci¹ a³y b³êdem wyników otrzymanych dla stanu ustalonego. Do okreœlenia charakterystyk stanu ustalonego wykorzystano wartoœæ œredni¹, wariancjê oraz przedzia³y ufnoœci dla wartoœci œredniej. Zastosowano metodê niezale nych podprzebiegów. Stan ustalony zosta³ okreœlony na podstawie porównania wartoœci œrednich z kolejnych podprzebiegów, tzn. je eli wartoœci œrednie z dwóch kolejnych podprzebiegów ró ni³y siê o mniej ni 5%, to przyjmowano, e osi¹gniêty zosta³ stan ustalony systemu. Ka dy z podprzebiegów odpowiada³ 49

przes³aniu 10 000 ramek przez ka d¹ ze stacji, tzn. stacja, która jako pierwsza przes³a³a 10 000 ramek, koñczy³a okres podprzebiegu. Po osi¹gniêciu stanu ustalonego przeprowadzano dziesiêæ podprzebiegów symulacyjnych, z których wyliczano wartoœci œrednie, wariancje oraz przedzia³y ufnoœci na poziomie 95%. Na wykresach przedstawiono krzywe, dla których dla zadanego przedzia³u ufnoœci na poziomie 95% poziom b³êdu nie przekracza 1% (wartoœci b³êdów s¹ zbyt ma³e, aby mog³y byæ widoczne na wykresach). Jako podprzebieg przyjêto realizacjê sta³ego ci¹gu zdarzeñ przez ka d¹ ze stacji, co pozwoli³o uniezale niæ wyniki symulacji od wielkoœci ruchu oferowanego i liczby stacji. 4.1. Scenariusz 1 Badanie wydajnoœci protoko³ów z u yciem jednego priorytetu W scenariuszu 1 w sieci pracowa³y dwie stacje wysy³aj¹ce ramki wzajemnie do siebie. Stacja 1 wysy³a³a strumieñ CBR (Constant Bit Rate) o najwy szym priorytecie. Przyjêta wielkoœæ ramki wynosi³a 250 bajtów. Dodatkowo dla protoko³u PUMA-TCS zmieniany by³ parametr packet-train i wynosi³ on odpowiednio 2 i 5 ramek. Protokó³ PUMA-TCS zak³ada sta³e u ycie mechanizmu RTS/CTS, jednak e funkcjê EDCA przebadano dla dwóch przypadków: z w³¹czonym (parametr Rys. 5. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla scenariusza 1 Rys. 6. Wykres œredniego opóÿnienia w funkcji ruchu oferowanego dla scenariusza 1 50

RTS_Threshold=0) oraz wy³¹czonym mechanizmem RTS/CTS. Wykresy zmian ruchu realizowanego oraz œredniego opóÿnienia transmisji w funkcji ruchu oferowanego przedstawiono na rysunkach 5 i 6. Obserwacja uzyskanych wyników pozwala na wyci¹gniêcie kilku wniosków. Pierwszym zjawiskiem, które mo na zaobserwowaæ na rysunku 5, jest brak zwiêkszania przep³ywnoœci strumienia od pewnej granicy ruchu oferowanego. Jest to spowodowane nasyceniem sieci zwi¹zanym z przepe³nieniem kolejki ramek oczekuj¹cych na wys³anie do danej stacji. Najni sz¹ wartoœæ ruchu realizowanego w stanie nasycenia osi¹ga strumieñ nadawany z wykorzystaniem PUMA-TCS, który wynosi ok. 4140 kbit/s. Jest to spowodowane dzia³aniem mechanizmu RTS/CTS, który obni a wartoœæ ruchu realizowanego poprzez wymianê ramek RTS i CTS przed wys³aniem ramek DATA. W tym przypadku, kiedy nie mamy do czynienia z problemem stacji ukrytych, mechanizm RTS/CTS okazuje siê byæ ca³kowicie zbêdny. Ruch realizowany z wykorzystaniem PUMA-TCS przyjmuje ni sze wartoœci ni realizowany z wykorzystaniem funkcji dostêpu EDCA z w³¹czonym mechanizmem RTS/CTS. Dzieje siê tak dlatego, e w pierwszym przypadku czas oczekiwania na wys³anie ramki jest wyd³u ony w stosunku do EDCA. Czas potrzebny na wys³anie sygna³ów JAM, z u yciem protoko³u PUMA-TCS, jest d³u szy od czasu AIFS, jaki oczekuje ramka nadawana z u yciem funkcji EDCA. Zdecydowanie wy sze wartoœci ruchu realizowanego w stanie nasycenia osi¹ga funkcja EDCA bez w³¹czonego mechanizmu RTS/CTS (ok. 6100 kbit/s). Najwy sz¹ wartoœæ ruchu realizowanego osi¹ga protokó³ PUMA-TCS z ustawionym parametrem packet-train na wartoœæ 5 (ok. 6960 kbit/s). Gdy packet-train ustawiony zosta³ na wartoœæ 2, osi¹gniête wartoœci ruchu realizowanego dla protoko³u PUMA-TCS by³y zbli one do osi¹ganych przez funkcjê EDCA z wy³¹czonym mechanizmem RTS/CTS. PUMA-TCS zdecydowanie lepiej radzi sobie ze œrednim opóÿnieniem transmisji, co dobrze obrazuje rys. 6. Œrednie opóÿnienia ramek osi¹gane dla PUMA- TCS s¹ ni sze od osi¹ganych dla EDCA. W przypadku EDCA widoczny jest te niekorzystny wp³yw stosowania mechanizmu RTS/CTS. Dla EDCA wykorzystuj¹cej RTS/CTS opóÿnienia transmisji wzrastaj¹ gwa³townie przy znacznie mniejszych wartoœciach ruchu oferowanego ni dla EDCA bez RTS/CTS. 4.2. Scenariusz 2 Badanie wydajnoœci protoko³ów z u yciem dwóch priorytetów W scenariuszu 2 badana sieæ sk³ada³a siê z trzech stacji. Stacje o numerach 2 i 3 generuj¹ strumienie ruchu CBR i wysy³aj¹ je do stacji 1. Strumieniowi nadawanemu ze stacji 2 przydzielony zosta³ priorytet 1 (najwy - szy), strumieniowi nadawanemu ze stacji 3 przydzielono priorytet 2. Pozosta³e parametry symulacji by³y takie, jak zdefiniowano w tabeli 4 oraz w scenariuszu 1. Mechanizm packet-train zosta³ wy³¹czony. Funkcjê EDCA przebadano dla dwóch przypadków: z w³¹czonym oraz wy³¹czonym mechanizmem RTS/CTS. Wykresy zmian ruchu realizowanego oraz œredniego opóÿnienia transmisji w funkcji ruchu oferowanego przedstawiono na rysunkach 7 i 8. Na rysunku 7 mo na zaobserwowaæ dzia³anie mechanizmu nadawania priorytetów dla obu funkcji dostêpu do medium. Gdy sumaryczna wartoœæ ruchu oferowanego dla strumieni z priorytetami 1 i 2 przekroczy wartoœæ nasycenia siê sieci, wartoœæ ruchu realizowanego przez priorytet 2 musi zmniejszyæ siê tak, aby strumieñ z priorytetem wy szym (priorytet 1) móg³ przenosiæ ca- ³oœæ ruchu oferowanego. Dzieje siê to oczywiœcie kosztem ruchu z priorytetem ni szym (priorytet 2). Ciekawym zjawiskiem jest to, e dla PUMA-TCS, po uzyskaniu stanu nasycenia (sumarycznie dla obu strumieni ok. 4000 kbit/s), nastêpuje gwa³towny spadek ruchu realizowanego dla strumienia o ni szym priorytecie. Dzieje siê tak, poniewa podczas rywalizacji o dostêp do medium wygrywa zawsze strumieñ z priorytetem 1, co prowadzi do zag³odzenia ruchu o priorytecie 2 przy wzroœcie ruchu oferowanego dla strumienia z priorytetem 1. Jest to dzia³anie zgodne z za³o eniami PUMA-TCS, które zak³adaj¹ nadawanie dla ruchu o priorytecie najwy szym tzw. strict priority, czyli bezwzglêdnego pierwszeñstwa w dostêpie do medium transmisyjnego. Inaczej zosta³a zaprojektowana funkcja EDCA. W momencie, kiedy sumaryczny ruch obu priorytetów osi¹gn¹³ stan nasycenia (ok. 6000 kbit/s), wartoœæ ruch realizowanego z priorytetem 2 spad³a, podobnie jak dla PUMA-TCS. Nie jest to jednak spadek tak gwa³towny i nie prowadzi do zag³odzenia ruchu z priorytetem 2. Maksymalna wartoœæ ruchu, który mo e byæ obs³ugiwany przez sieæ za poœrednictwem funkcji EDCA, zosta³a podzielona pomiêdzy dwa strumienie ruchu z zachowaniem priorytetów. Po osi¹gniêciu stanu nasycenia przy wykorzystaniu funkcji EDCA bez w³¹czonego mechanizmu RTS/CTS, strumienie ruchu osi¹gaj¹ odpowiednio: ok. 4050 kbit/s dla strumienia 1 i ok. 2100 kbit/s dla strumienia 2. Po w³¹czeniu mechanizmu RTS/CTS, maksymalne osi¹gane wartoœci ruchu realizowanego malej¹ dla obu strumieni, poniewa wysy³anie danych poprzedzane jest wymian¹ ramek RTS/CTS. Wszystkie opisywane wczeœniej w³asnoœci funkcji EDCA (bez w³¹czonego mechanizmu RTS/CTS) zachodz¹ i w tym przypadku. Na rysunku 8, przedstawiaj¹cym œrednie wartoœci opóÿnienia transmisji ramek w funkcji ruchu oferowanego, mo na zaobserwowaæ nastêpuj¹ce prawid³owoœci w dzia³aniu poszczególnych priorytetów. Niezale nie od rodzaju funkcji dostêpu do kana³u radiowego, strumieñ o ni szym priorytecie uzyskuje wy sze wartoœci œredniego opóÿnienia. OpóŸnienia strumieni 51

Rys. 7. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla scenariusza 2 Rys. 8. Wykres œredniego opóÿnienia w funkcji ruchu oferowanego dla scenariusza 2 wykorzystuj¹cych PUMA-TCS s¹ o ponad po³owê mniejsze od œrednich opóÿnieñ osi¹ganych przez strumienie wykorzystuj¹ce funkcjê EDCA. Charakterystyczne jest równie to, opóÿnienie dla ruchu z najwy - szym priorytetem nie roœnie skokowo. 4.3. Scenariusz 3 Skalowanie ruchu w protokole PUMA-TCS Celem badañ przeprowadzonych dla scenariusza 3 by³o pokazanie dzia³ania licznika odpowiadaj¹cego za przejœcie ramek z priorytetu ni szego na wy szy. Licznik T1 (umo liwiaj¹cy przejœcie ramek z priorytetu 3 na priorytet 2) zosta³ ustawiony na wartoœæ 10, co spowodowa³o, e ka dej ramce o priorytecie 3, która czeka³a na wys³anie w buforze przez 10 milisekund, by³ nadawany wy szy priorytet (drugi). Sieæ sk³ada³a siê z dwóch stacji, z których jedna wysy³a ramki do drugiej stacji wykorzystuj¹c trzy ró ne priorytety. Scenariusz ten mia³ odzwierciedlaæ sytuacjê, w której u ytkownik sieci bezprzewodowej korzysta³ z us³ugi multimedialnej, np. z³o onej z trzech strumieni o ró nych priorytetach (dla lepszego zobrazowania dzia³ania protoko³u PUMA-TCS celowo dokonano zmian w przypisaniu ró - nych rodzajów ruchu do zdefiniowanych wczeœniej klas priorytetów protoko³u PUMA-TCS): 52

strumienia wideo o sta³ej przep³ywnoœci 2 Mbit/s, przesy³anego w tym scenariuszu jako ruch zarz¹dzaj¹cy na priorytecie najwy szym, symulowanego jako Ÿród³o ruchu typu CBR, generuj¹cego ramki o wielkoœci 250 bajtów, strumienia g³osowego o przep³ywnoœci 64 kbit/s, symulowanego jako Ÿród³o ruchu typu ON-OFF, generuj¹cego ramki o priorytecie drugim, strumienia danych transakcyjnych, generowanych w tym scenariuszu z priorytetem 3, symulowanego jako Ÿród³o ruchu CBR, generuj¹cego ramki o wielkoœci 1000 bajtów, którego przep³ywnoœæ ulega³a zmianom w kolejnych seriach symulacji. Dostêp do medium transmisyjnego odbywa³ siê wy³¹cznie z u yciem protoko³u PUMA-TCS (EDCA nie pozwala bowiem na realizacjê strategii skalowania ruchu). Wykresy zmian ruchu realizowanego oraz œredniego opóÿnienia transmisji w funkcji ruchu oferowanego przedstawiono na rysunkach 9 i 10. Na podstawie wyników uzyskanych w scenariuszu 3 mo na zauwa yæ, e licznik T1 zadzia³a³ prawid³owo. W sytuacji, gdy ruch oferowany dla priorytetu 3 osi¹gn¹³ wartoœæ ok. 1500 kbit/s (rys. 9), liczba ramek dostarczonych w jednostce czasu przez Ÿród³o do bufora jest tak du a, e wiêkszoœæ ramek jest w nim przetrzymywana d³u ej ni czas okreœlony przez licznik T1 Rys. 9. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla scenariusza 3 Rys. 10. Wykres œredniego opóÿnienia w funkcji ruchu oferowanego dla scenariusza 3 53

(ustawiony na bardzo nisk¹ wartoœæ 10 milisekund). W efekcie ramkom oczekuj¹cym w buforze nadawany by³ wy szy priorytet (priorytet 2), co zwiêkszy³o ich szansê uzyskania dostêpu do kana³u radiowego. Proces ten mia³ degraduj¹cy wp³yw na QoS strumienia nadawanego pierwotnie z priorytetem 2. Ramki przenosz¹ce us³ugê g³osow¹ musia³y zacz¹æ rywalizowaæ o dostêp do medium z ramkami przeniesionymi z ni - szego priorytetu, co spowodowa³o znaczny wzrost ich opóÿnieñ. W efekcie prowadzona rozmowa g³osowa nie mog³a byæ zrealizowana. Oczywiœcie, wartoœæ licznika T1 przyjêta w scenariuszu by³aby zbyt ma³a w warunkach rzeczywistych. Scenariusz ten pokazuje wiêc, jak ostro nym trzeba byæ w dobieraniu prawid³owych wartoœci tego parametru. Jakoœæ transmisji realizowanej z priorytetem 1 nie uleg³a zmianie z uwagi na sposób dzia³ania protoko³u PUMA-TCS, który ramkom o ni - szych priorytetach nie pozwala przechodziæ na najwy - szy priorytet. 4.4. Scenariusz 4 Badanie wydajnoœci protoko³ów dla ró nej liczby stacji Scenariusz 4 prezentuje pozytywny wp³yw mechanizmów stosowanych w protokole PUMA-TCS, takich jak backoff typu DIDD oraz sta³e u ycie mechanizmu RTS/CTS (zw³aszcza podczas transmisji stosunkowo d³ugich ramek) w sieciach o ma³ej (5), œredniej (25) i du ej (100) liczbie stacji. Stacje wysy³a³y ruch typu CBR, wielkoœæ ramek by³a ustawiona na 1000 bajtów. Wykresy zmian ruchu realizowanego oraz œredniego opóÿnienia transmisji w funkcji ruchu oferowanego przedstawiono na rysunkach 11 16. Przeprowadzone symulacje pokazuj¹, e sieæ wykorzystuj¹ca protokó³ PUMA-TCS osi¹ga znacznie wiêksz¹ wydajnoœæ pracy ni dla EDCA. Jak mo na zaobserwowaæ na rysunku 11, punkt œwiadcz¹cy o nasyceniu sieci zosta³ osi¹gniêty dla funkcji EDCA ju przy wartoœci ok. 5 Mbit/s ruchu oferowanego, podczas gdy dla PUMA-TCS punkt ten zosta³ osi¹gniêty dopiero dla wartoœci ok. 8 Mbit/s. Takie ró nice zwi¹zane s¹ ze zmianami, jakie wprowadza protokó³ PUMA-TCS do mechanizmu backoff. PUMA-TCS wykorzystuje algorytm DIDD, którego dzia³anie przek³ada siê na mniejsz¹ liczbê kolizji, co z kolei pozwala uzyskaæ wy sze wartoœci ruchu realizowanego. Rysunek 11 pokazuje jeszcze jedn¹ istotn¹ cechê zró nicowanie efektywnoœci pracy sieci w zale noœci od priorytetu nadawanego ruchu. Poniewa w ka dej z przeprowadzonych serii symulacji przesy³any by³ ruch tylko o jednym priorytecie, mo - na zauwa yæ ró nice w efektywnoœci wykorzystania kana³u radiowego zarówno w protokole PUMA-TCS jak i funkcji EDCA. Dla PUMA-TCS, najlepsze rezultaty osi¹gn¹³ ruch o najni szym z symulowanych priorytetów, osi¹gaj¹c przepustowoœæ ok. 7,9 Mbit/s. Ruch realizowany z priorytetem trzecim osi¹gn¹³ ok. 7,7 Mbit/s, z priorytetem drugim ok. 7,6 Mbit/s, a z priorytetem pierwszym ok. 7,4 Mbit/s. Jest to spowodowane wykorzystywaniem ró nej liczby sygna³ów JAM, w zale noœci od priorytetu, w trakcie rywalizacji o dostêp do medium. Stacje maj¹ce do wys³ania ramkê o priorytecie czwartym musz¹ zasygnalizowaæ to wys³aniem dwóch sygna³ów JAM (rys. 3). W porównaniu do stacji maj¹cych do wys³ania ramki o priorytecie pierwszym, które musz¹ wys³aæ piêæ sygna³ów JAM, zyskuj¹ okres trzech szczelin czasowych. Przek³ada siê to bezpoœrednio na ró nice w osi¹ganych maksymalnych wartoœciach ruchu realizowanego. Ró nice w osi¹ganych wartoœciach maksymalnego ruchu realizowanego s¹ widoczne równie dla funkcji EDCA. Ró nice w tym przypadku wyni- Rys. 11. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla scenariusza 4 (5 stacji) 54

kaj¹ z ró nych d³ugoœci czasów AIFS przypisanych ró - nym priorytetom. Takie zasady dzia³ania przek³adaj¹ siê na lepsz¹ efektywnoœæ wykorzystania kana³u radiowego przez ruch realizowany z wy szym priorytetem. W przypadku wykorzystania mechanizmu RTS/CTS w funkcji EDCA w sieci o ma³ej liczbie stacji, opóÿnienia œrednie wzrastaj¹, a maksymalny ruch realizowany spada. Powodowane jest to nadmiarowoœci¹ informacji kontrolnych. W przypadku sieci, w której pracowa³o 25 stacji, ró nice miêdzy protoko³ami s¹ jeszcze wiêksze. Protokó³ PUMA-TCS ponownie uzyska³ znacznie wiêksze wartoœci ruchu realizowanego. Jest to spowodowane dzia³aniem mechanizmów backoff typu DIDD i RTS/CTS. Jak mo na zauwa yæ na rysunku 13, w³¹czenie mechanizmu RTS/CTS dla funkcji EDCA wp³ywa na poprawê osi¹ganych maksymalnych wartoœci ruchu realizowanego. Ruch realizowany z priorytetem pierwszym, bez w³¹czonego mechanizmu RTS/CTS, osi¹gn¹³ maksymaln¹ wartoœæ ok. 3,7 Mbit/s, natomiast z w³¹czonym mechanizmem RTS/CTS osi¹gn¹³ wartoœæ 3,9 Mbit/s. Rys. 12. Wykres œredniego opóÿnienia w funkcji ruchu oferowanego dla scenariusza 4 (5 stacji) Rys. 13. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla scenariusza 4 (25 stacji) 55

By³o to spowodowane wiêksz¹ liczb¹ kolizji ni w przypadku 5 stacji oraz znacznie szybszym ich wykryciem w przypadku stosowania mechanizmu RTS/CTS. Kolejnym ciekawym zjawiskiem, które mo na zaobserwowaæ w sieci ze œredni¹ liczb¹ stacji, jest wp³yw rozmiaru okna CW na wartoœci ruchu realizowanego. Na rysunku 12 obrazuj¹cym œrednie opóÿnienia ramek przesy³anych w sieci z³o onej z 5 stacji zaobserwowano, e im wy szy priorytet transmitowanych ramek, tym ich opóÿnienia by³y mniejsze, co t³umaczy mniejszy czas AIFS dla tych priorytetów. Natomiast rysunek 14, przedstawiaj¹cy opóÿnienia w sieci z 25 stacjami, pokazuje, e im wy szy priorytet przesy³anych ramek, tym opóÿnienia s¹ wiêksze. Jest to wynikiem zró nicowanej wielkoœci okien CW przypisanych ró nym priorytetom. Zgodnie z za³o eniami standardu IEEE 802.11e, im wy szy priorytet, tym mniejsze okno rywalizacji, zatem przy wiêkszej liczbie stacji i du ym ruchu oferowanym czêœciej pojawia siê sytuacja, w której kilka stacji wylosuje tak¹ sam¹ wartoœæ licznika backoff, co skutkuje czêstszymi kolizjami w medium transmisyjnym. Wiêksze okna rywalizacji, przypisane z definicji do ni szych priorytetów, sprawiaj¹, e kolizji jest mniej, opóÿnienia ramek w zwi¹zku z tym s¹ mniejsze, a maksymalny ruch realizowany z ni szymi priorytetami jest wy szy. Rys. 14. Wykres œredniego opóÿnienia w funkcji ruchu oferowanego dla scenariusza 4 (25 stacji) Rys. 15. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla scenariusza 4 (100 stacji) 56

Rys. 16. Wykres œredniego opóÿnienia w funkcji ruchu oferowanego dla scenariusza 4 (100 stacji) Najwiêksze ró nice w pracy obu protoko³ów mo na zaobserwowaæ w sieci, sk³adaj¹cej siê ze 100 stacji (rys. 15 i 16). Analizuj¹c dzia³anie protoko³u PUMA-TCS, w porównaniu do sieci ma³ych i œrednich, nie ma istotnych zmian w wielkoœciach ruchu realizowanego. OpóŸnienia, jakim podlegaj¹ ramki, zwiêkszaj¹ siê wraz ze zwiêkszeniem siê liczby stacji transmisji nadaj¹cych jednoczeœnie. Na rysunku 16 mo na zaobserwowaæ, e w sieci z³o onej ze 100 stacji opóÿnienie œrednie kszta³tuje siê na poziomie 51 milisekund. Znacznie bardziej istotne zmiany zachodz¹ dla funkcji EDCA (w przypadku du ej sieci). Na rysunku 15 mo na zauwa yæ, e wzrost ruchu realizowanego nie jest liniowy nawet dla niewielkich wartoœci ruchu oferowanego. Takie zjawisko nie mia³o miejsca w sieciach o ma³ej i œredniej liczbie stacji. Równie opóÿnienia, jakim podlegaj¹ ramki w tej sieci (rzêdu kilkuset milisekund), s¹ niedopuszczalne przy realizacji us³ug g³osowych i wideo. Równoczeœnie mo na zauwa yæ spadek maksymalnych wartoœci ruchu realizowanego dla tej sieci, w porównaniu z sieciami o mniejszej liczbie stacji. 5. Wnioski Praca przedstawia analizê symulacyjn¹ protoko³u PUMA-TCS opracowanego w Katedrze Telekomunikacji AGH. Po teoretycznym przedstawieniu protoko³ów PUMA-TCS oraz funkcji EDCA zaprezentowano ich porównanie. Badania przeprowadzono dla czterech ró - nych scenariuszy. W dzia³aniu protoko³u PUMA-TCS mo na by³o zaobserwowaæ funkcjonowanie mechanizmu strict priority. W sytuacji, kiedy liczniki przejœæ pomiêdzy priorytetami s¹ wy³¹czone i wartoœæ ruchu oferowanego jest du a, nastêpuje degradacja ruchu o ni - szym priorytecie na rzecz ruchu o priorytecie wy szym. Rygorystyczne dzia³anie mechanizmu strict priority mo na zmniejszaæ poprzez umiejêtne stosowanie liczników przejœæ pomiêdzy poszczególnymi priorytetami. Nale y jednak pamiêtaæ, e stosowane liczników przejœæ zawsze poci¹ga za sob¹ degradacje ruchu o wy szym priorytecie. Niedopuszczalne jest przeniesienie wiêkszoœci lub ca³oœci ruchu oferowanego z priorytetu ni szego na wy szy, poniewa mo e to doprowadziæ do sytuacji, w której o dostêp do medium bêd¹ rywalizowa³y równorzêdnie na przyk³ad: rozmowa g³osowa (priorytet 2) i ruch wideo (priorytet 3). W takiej sytuacji ruch oferowany zostanie wprawdzie przeniesiony, ale opóÿnienia mog¹ wzrosn¹æ powy ej akceptowalnego dla danej klasy ruchu poziomu. Kolejnym pomys³em na usprawnienie funkcji dostêpu do medium PUMA-TCS jest sta³e stosowanie mechanizmu RTS/CTS. Jest to podejœcie odwrotne ni prezentowane w standardzie IEEE 802.11e, gdzie w³¹czenie tego mechanizmu uzale nia siê od przekroczenia przez rozmiar ramki danych pewnej wartoœci granicznej. Jak pokazuj¹ badania, mechanizm RTS/CTS nie sprawdza siê przy niewielkiej liczbie stacji znajduj¹cych siê w sieci ad-hoc, gdy jego dzia³anie zajmuje dodatkowo pasmo i wprowadza dodatkowe opóÿnienia. Mechanizm ten sprawdza siê doskonale w przypadku, kiedy w sieci znajduje siê œrednia lub du a liczba stacji lub stacje ukryte. Funkcjonalnoœci¹, która bardzo pozytywnie wyró nia protokó³ PUMA-TCS, w przypadku sieci z du- ¹ liczb¹ stacji w warunkach silnego obci¹ enia, jest algorytm DIDD. Mechanizm ten pozwala na znaczne 57

zwiêkszenie wartoœci ruchu realizowanego dziêki redukcji liczby kolizji. Dla sieci z³o onej ze 100 stacji skutkowa³o to nawet dwukrotnie wiêkszym ruchem realizowanym, w porównaniu do sieci wykorzystuj¹cej z funkcji EDCA i nie wykorzystuj¹cej mechanizmu DIDD. Zwiêkszenie efektywnoœci wysy³ania danych przy zastosowaniu funkcji PUMA-TCS mo na tak e uzyskaæ poprzez stosowanie mechanizmu packet-train. Uzyskano w ten sposób zwiêkszenie wartoœci ruchu realizowanego o ponad 50% w stosunku do wartoœci osi¹ganych przez protokó³ PUMA-TCS, dla którego mechanizm packet-train by³ wy³¹czony. Kolejne prace bêd¹ siê koncentrowa³y na dalszej optymalizacji parametrów protoko³u PUMA-TCS, umo liwiaj¹cej zwiêkszenie maksymalnej wartoœci ruchu realizowanego oraz zmniejszenie œredniego opóÿnienia transmisji. Badaniami zostan¹ objête tak e sieci, w których wystêpuj¹ stacje ukryte. Literatura [1] IEEE Std 802.11 Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE 802.11 2007 [2] IEEE Std 802.11e Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment: Medium Access Control (MAC) Quality of Service Enhancements, 2005 [3] Mangold S., Choi S., May P., Klein O., Hiertz G., Stibor L.: IEEE 802.11e Wireless LAN for Quality of Service. Proc. European Wireless, vol. 1, s. 32 39, Florence, Italy, February 2002 [4] Mangold S., Choi S., May P., Hiertz G.: IEEE 802.11e Fair Resource Sharing between Overlapping Basic Service Sets. [w:] Proceedings of the PIMRC 2002, s. 166 171, Lisbon, Portugal, September 2002 [5] Choi S., del Prado J., S. Shankar N, Mangold S.: IEEE 802.11e contention-based channel access (EDCF) performance evaluation. IEEE International Conference on Communications, 2003 [6] Wu H., Wang X., Zhang Q., Shen X.: IEEE 802.11e Enhanced Distributed Channel Access (EDCA) Throughput Analysis. [w:] Proc. of IEEE International Conference on Communications, June 2006 [7] Hwang I.-S., Chang H.-H.: Performance Assessment of IEEE 802.11e EDCF Using Three-dimension Markov Chain Model. Applied Mathematical Sciences, vol. 2, No. 3, s. 139 151, 2008 [8] Gas M., Kosek-Szott K., Natkaniec M., Pach A.R.: 3D Markov chain-based saturation throughput model of IEEE 802.11 EDCA. Electronics Letters, vol. 47, No. 14, 2011 [9] Kosek-Szott K., Natkaniec M., Pach A.R.: A simple but accurate throughput model for IEEE 802.11 EDCA in saturation and non-saturation conditions. Computer Networks, Elsevier, vol. 55 issue 3, 21 Feb. 2011 [10] Natkaniec M., Pach A.R.: PUMA A New Channel Access Protocol for Wireless LANs. WPMC 2002 Wireless Personal Multimedia Communications, Honolulu, Hawaii, U.S.A, 27 30 October 2002 [11] Natkaniec M., Pach A.R.: An Analysis of Modified Backoff Mechanism in IEEE 802.11 Networks. Polish German Teletraffic Symposium 2000, Dresden, Germany, 24 26 September 2000 58