Analiza symulacyjna protokołu PUMA dla sieci pracujących w konfiguracji ad-hoc

Telekomunikacja Cyfrowa Technologie i Usługi Tom 6. Rok 24 Analiza symulacyjna protokołu PUMA dla sieci pracujących w konfiguracji ad-hoc Marek Natkaniec, Andrzej R. Pach (e-mail: {natkaniec, pach}@kt.agh.edu.pl) Katedra Telekomunikacji Akademii Górniczo-Hutniczej Kraków STRESZCZENIE W publikacji przedstawiono analizę symulacyjną protokołu PUMA (Priority Unavoidable Multiple Access). Protokół PUMA został zaproponowany w celu wyeliminowania głównych wad funkcji DCF standardu IEEE 82.11. Protokół PUMA może być w prosty sposób zaimplementowany w kartach sieci bezprzewodowej. W swych założeniach protokół PUMA jest sprawiedliwy, stabilny i pozwala przy tym na realizację usług z ograniczeniami czasowymi. Poza tym protokół ten jest odporny na działanie stacji ukrytych. Specjalny licznik czasu pozwala na skalowanie proporcji realizowanego ruchu izochronicznego do asynchronicznego. W celu zwiększenia wydajności protokołu podczas transmisji bardzo krótkich pakietów z danymi zastosowano mechanizm jednoczesnego wysyłania wielu pakietów packet-train. W pracy przedstawiono wyniki symulacji wydajności protokołu PUMA dla ruchu asynchronicznego, izochronicznego oraz mieszanego. ABSTRACT Simulation analysis of PUMA protocol for ad-hoc networks In this paper the simulation analysis of the PUMA (Priority Unavoidable Multiple Access) protocol. is presented PUMA protocol was proposed to eliminate the main disadvantages of IEEE 82.11 DCF function. PUMA can easy be implemented in wireless network cards. In it s assumption PUMA protocol is fair, efficient, stable and allows for provision of time-bounded services. Moreover, it is unaffected by hidden stations. The special timer allows for isochronous-asynchronous traffic scaling. The packet-train mechanism was used to improve the protocol efficiency while sending very short data packets. The performance of PUMA for asynchronous, isochronous and mixed traffic is presented in the paper. 1. Wstęp Lokalne sieci bezprzewodowe WLANs (Wireless Local Area Networks) są obecnie najszybszym i najwygodniejszym sposobem łączenia komputerów. Ich łatwa instalacja oraz funkcjonalność mają szczególne znaczenie tam, gdzie wymagana jest duża mobilność użytkowników. Sieci te są także idealnym rozwiązaniem dla posiadaczy urządzeń przenośnych takich jak laptopy lub PDA (Personal Digital Assistants). W lokalnych sieciach bezprzewodowych dominuje asynchroniczny transfer danych, jednak w najbliższych latach oczekuje się wzrostu zainteresowania usługami multimedialnymi. Obecnie, najbardziej rozpowszechnionymi standardami dla sieci WLAN są: IEEE 82.11 opracowany przez jeden z podkomitetów IEEE IEEE 82.11 [9], HI- PERLAN (High Performance Radio LAN) [8] będący przedmiotem prac Europejskiego Instytutu Standardów Telekomunikacyjnych ETSI (European Telecommunications Standards Institute) oraz HomeRF. Standardem, który doczekał się już wielu praktycznych implementacji, jest standard IEEE 82.11. Proponuje on dwa sposoby dostępu do medium. Pierwszy z nich jest obowiązkowy dla każdej implementacji i opiera się na metodzie CSMA/CA. Jest on nazywany DCF (Distributed Coordination Function). Drugi sposób, PCF (Point Coordination Function) jest opcjonalny i może być stosowany tylko w sieci o trybie pracy z infrastrukturą dla usług, na które nałożone są ograniczenia czasowe (time-bounded services). W większości produkowanych obecnie kart sieciowych standardu IEEE 82.11 implementowany jest tylko DCF. Dokładna analiza standardu IEEE 82.11 została przedstawiona w pracach [4, 5, 1, 11, 13, 15]. Niestety, z publikacji tych jasno wynika, że funkcja DCF posiada wiele wad. W sieci ad-hoc (brak punktu dostępu) nie istnieje odgórny podział na szczeliny czasu, a jedynie zarządzanie rozproszone DCF, obsługujące ruch asynchroniczny. Ponieważ usługi izochroniczne są opcjonalne tylko dla sieci z infrastrukturą, w pracy [14] zaproponowano nowy protokół dostępu do medium MAC o nazwie PUMA (Priority Unavoidable Multiple Access), stanowiący rozszerzenie trybu DCF m.in. o możliwość przesyłania pakietów z priorytetem, co umożliwia realizację usług izochronicznych. Autorzy projektujący ten protokół starali się wyeliminować największe wady funkcji DCF standardu IEEE 82.11. Dzięki wprowadzonym modyfikacjom, protokół PUMA umożliwia przesyłanie pakietów z priorytetami, co pozwala na realizację ruchu izochronicznego (należy pamiętać, że funkcja DCF zapewniała jedynie transmisję ruchu asynchronicznego klasy best effort). Wprowadzony mechanizm dodatkowych liczników czasowych umożliwia skalowanie ruchu izochronicznego-asynchronicznego, odgrywając tę samą rolę co superramka 13

w trybie PCF. Kolejna modyfikacja, zapożyczona z protokołu FAMA, pozwala całkowicie rozwiązać problemy wynikające z istnienia stacji ukrytych, tzn. zaimplementowany zostanie mechanizm zapobiegający powstawaniu kolizji, a nie tylko wykrywający je po zakończeniu nadawania. Twórcy protokołu postanowili również maksymalnie zwiększyć wydajność pracy protokołu poprzez stosowanie mechanizmu jednoczesnego wysyłania wielu pakietów. Kolejny wzrost wydajności sieci w warunkach silnego obciążenia ruchem, dla dużej liczby stacji, stał się możliwy dzięki zastosowaniu mechanizmu backoff DIDD [12]. Niewątpliwą zaletą przedstawianego protokołu jest możliwość jego zaimplementowania w istniejących kartach sieci bezprzewodowej za pomocą zmiany firmware u karty sieciowej. Pomimo pewnych zmian w strukturze budowy ramek sygnalizacyjnych zachowane zostały wszystkie pola służące realizacji funkcji: synchronizacji, szyfrowania danych oraz zarządzania zużyciem energii. Celem niniejszej publikacji jest przedstawienie wyników badań wydajności pracy protokołu PUMA dla różnych parametrów protokołu zaimplementowanego w sieci o konfiguracji ad-hoc. W rozdziale 2 dokonano krótkiej charakterystyki wszystkich nowo zaproponowanych mechanizmów protokołu PUMA. Rozdział 3 przedstawia koncepcję budowy samego symulatora. Najobszerniejszą część pracy zajmuje rozdział 4, w którym przedstawiono wyniki badań wydajności pracy protokołu PUMA podczas realizacji ruchu asynchronicznego i izochronicznego. W rozdziale tym znajdują się również badania powiązań między ruchem izochronicznym a asynchronicznym, które są możliwe dzięki zastosowaniu liczników czasowych pozwalających na łatwe skalowanie ich proporcji. 2. Charakterystyka protokołu PUMA Protokół PUMA (Priority Unavoidable Multiple Access) powstał na drodze modyfikacji protokołu realizującego funkcję DCF standardu IEEE 82.11. Protokół PUMA różni się od protokołu funkcji DCF standardu IEEE 82.11 jedynie w nieznaczny sposób, dlatego też możliwa jest jego implementacja w produkowanych obecnie kartach sieciowych poprzez zmianę odpowiednich algorytmów oraz niektórych parametrów pracy zawartych w oprogramowaniu karty (sterownikach, kodach wewnętrznych procesorów). W protokole PUMA wprowadzono następujące modyfikacje, które szczegółowo omówiono w pracy [14]: zapewniono dominację pakietu CTS (Clear to Send) nad RTS (Request to Send) dzięki wydłużeniu długości pakietu CTS w stosunku do długości pakietu RTS; wprowadzono dodatkowy sygnał JAM, umożliwiający realizację transmisji izochronicznej; wprowadzono licznik T2, pozwalający skalować stosunek wielkości realizowanego ruchu izochronicznego do asynchronicznego; zastosowano dwa tryby transmisji: JAM+RTS+ CTS+DATA dla transmisji izochronicznej i RTS+CTS+DATA+ACK dla transmisji asynchronicznej; wprowadzono nowy mechanizm backoff u nazywany Backoff em DIDD pozwalający na zmniejszenie liczby kolizji w warunkach silnego obciążenia ruchem dla dużej liczby stacji; zaproponowano opcjonalne wykorzystanie mechanizmu transmisji packet-train. Pomysł wydłużenia długości pakietu CTS w stosunku do pakietu RTS został po raz pierwszy zaproponowany w protokole FAMA (Floor Acquisition Multiple Access) i przedstawiony w pracy [6]. Ta niewielka zmiana pozwoliła wyeliminować problemy wynikające z istnienia stacji ukrytych. Istnieje wiele innych protokołów wykorzystujących w swym działaniu śledzenie nośnej oraz obustronną wymianę pakietów RTS/CTS, ale żaden z nich nie gwarantuje poprawnej wymiany pakietów w sytuacji występowania stacji ukrytych. Protokół funkcji DCF standardu IEEE 82.11 potrafi jedynie wykryć kolizję po zakończeniu nadawania (wobec braku ACK), ale nie jest w stanie jej zapobiec. Długość pakietu CTS powinna być większa niż sumaryczna długość pakietu RTS + dwukrotna wartość maksymalnego czasu propagacji sygnału w kanale radiowym (round trip time) + czas przełączania nadajnika/odbiornika (Tx/Rx turn around time) + jakiekolwiek czasy przetwarzania sygnału (processing time). Ustalona w ten sposób zależność pomiędzy długością pakietów RTS i CTS pozwala na zachowanie przez pakiet CTS w stosunku do pakietu RTS dominacji w kanale radiowym. Dominujący pakiet CTS odgrywa tę samą rolę, co ton zajętości (busy tone) w przypadku protokołu BTMA (Busy Tone Multiple Access) [16]. Wyjaśnienie tego zjawiska jest następujące: jeżeli stacja rozpoczęła transmisję pakietu CTS, to każda inna stacja leżąca w jej zasięgu, nawet jeśli rozpocznie transmisję pakietu RTS (przez czas opóźnienia propagacji sygnału) usłyszy po powrocie ze stanu nadawania do odbioru fragment dominującego pakietu CTS, co pozwala na wstrzymanie dalszych transmisji i gwarantuje, że nadany w odpowiedzi na CTS pakiet z danymi zostanie poprawnie przesłany do odbiornika (nie wydarzy się kolizja). Ze względu na swą prostotę oraz skuteczność pracy pomysł dominacji w kanale radiowym pakietu CTS nad pakietem RTS został wykorzystany w protokole PUMA zarówno dla zapewnienia transmisji asynchronicznej, jak i izochronicznej. Sposób transmisji asynchronicznej został w protokole PUMA wzbogacony o mechanizm przesyłania potwierdzeń ACK po przesłaniu każdego pakiet z danymi. Ma to na celu zweryfikowanie poprawności transmisji samych danych, które wprawdzie zawsze są przesyłane bezkolizyjnie na skutek pozytywnego działania pakietu CTS, ale z uwagi na właściwości samego medium transmisyj- 14

nego (narażonego na zaniki, interferencje, odbicia itp.) nie zawsze są przesyłane bezbłędnie. Sprawdzenie poprawności transmisji już w warstwie drugiej modelu OSI/ISO (Open Systems Interconnection/ International Standards Organization) powoduje znaczny wzrost wydajności sieci w warunkach występowania wysokiej bitowej stopy błędów w kanale radiowym. Zaniechano stosowania potwierdzeń danych dla transmisji izochronicznej, wychodząc z założenia, że bezsensowna jest retransmisja błędnie odebranych pakietów dla aplikacji czasu rzeczywistego szczególnie wrażliwych na opóźnienie transmisji, a dopuszczających pewien procent strat pakietów [2]. Utrata pakietów objawia się poprzez zniekształcenia głosu lub też niewielkie przekłamania wyświetlanego obrazu. Na przykład dla skompresowanego sygnału wideo standardu MPEG (Moving Picture Experts Group) mogą pojawić się na ułamek sekundy przekłamane makrobloki. Dla takich aplikacji najważniejsze jest bowiem zachowanie płynności przekazu (zawsze można zapytać drugą osobę o powtórzenie słowa lub też zdania, które nie zostało zrozumiane). Procedura transmisji izochronicznej różni się w nieznaczny sposób od transmisji asynchronicznej stosowanej w standardzie IEEE 82.11, aczkolwiek wykorzystuje ona tę samą metodę dostępu CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Każda stacja, przygotowana do transmisji, nasłuchuje medium, sprawdzając czy jakaś inna stacja właśnie nie transmituje. zajęte, stacja oczekuje na zakończenie bieżącej transmisji. W protokole PUMA, tak jak w standardzie IEEE 82.11, wyróżnia się trzy przedziały czasowe: 1) SIFS (Short InterFrame Space), 2) PIFS (Priority InterFrame Space), 3) DIFS (Distributed InterFrame Space). o zależnościach DIFS>PIFS>SIFS. Odmierzane są one przez każdą stację od chwili zakończenia zajętości medium i służą do określenia czasu rozpoczęcia nadawania pakietów przez daną stację. Dla transmisji izochronicznej krytyczny jest czas PIFS. Jeżeli po zakończeniu transmisji medium jest wolne przez czas PIFS, stacje nadające ruch izochroniczny mają obowiązek wysłać tzw. sygnał JAM. Ma on długość jednej szczeliny czasowej, a jego transmisja informuje wszystkie inne stacje (w tym stacje prowadzące transmisję asynchroniczną), że w ich otoczeniu rozpocznie się za chwilę transmisja izochroniczna (muszą się one wstrzymać ze wszystkimi procedurami aż do momentu usłyszenia ramki RTS lub CTS wtedy uaktualniają swój wektor alokacji sieci). Sygnał JAM odgrywa tę samą rolę, co ton zajętości. Stacja rozpoczyna odliczanie backoffu. Jeżeli przed upływem całego okresu backoff zacznie nadawać inna stacja, odliczanie zostaje zawieszone, aż do wykrycia następnego okresu PIFS. Jeżeli medium do tego czasu nie zostało zajęte, rozpoczyna się transmisja pakietu RTS. Dostęp natychmiastowy, gdy medium jest wolne dłużej niż PIFS 2β + l max + ϕ SIFS Równoczesna transmisja sygnału JAM przez wszystkie uczestniczące w rywalizacji stacje JAM Okno współzawodnictwa Medium jest zajęte Okno Backoff Transmisja pakietu RTS Czas jednego slotu Oczekiwanie na dostęp Wybór jednego slotu i odliczanie czasu dopóki medium jest niezajęte Rys. 1. Sposób dostępu do medium dla stacji realizujących transmisję izochroniczną Jeżeli medium nie jest zajęte to przystępuje do transmisji, po odczekaniu czasu 2β l + ϕ, gdzie: β to + max to maksymalne opóźnienie propagacji sygnału w kanale radiowym, l max to maksymalny czas transmisji ramki z danymi, a ϕ to czas przełączania odbiornika/nadajnika. Pozwala to wszystkim stacjom znajdującym się w otoczeniu nowo włączonej stacji na poprawne zakończenie odbieranych właśnie ramek. Jeżeli medium jest Sposób dostępu do medium dla stacji realizujących transmisję izochroniczną został przedstawiony na rysunku 1. Jeżeli do czasu SIFS po wysłaniu przez stację pakietu RTS nie nadejdzie potwierdzający pakiet CTS, oznacza to, że nastąpiła kolizja i stacja musi się wstrzymać z procedurą transmisji do następnego okresu PIFS. Poprawne otrzymanie pakietu CTS gwarantuje bezkolizyjną transmisję pakietu/pakietów z danymi. 15

Stacja źródłowa PIFS JAM Backoff RTS SIFS SIFS DANE Stacja docelowa CTS Inne stacje NAV (RTS) NAV (CTS) JAM PIFS Backoff Oczekiwanie na dostęp Rys. 2. Procedura transmisji izochronicznej stosowana w protokole PUMA Protokół PUMA jest także wzbogacony o mechanizm wirtualnego nasłuchiwania i rezerwacji medium do transmisji Virtual CS (Virtual Carrier Sense) / NAV (Net Allocation Vector). Typowy przebieg transmisji pomiędzy stacjami został pokazany na rysunku 2. Protokół PUMA pozwala realizować usługi izochroniczne, narzucające maksymalną granicę czasu, do której określone pakiety muszą zostać dostarczone do odbiorcy. Jeżeli granica czasu zostanie dla danego pakietu przekroczona, a nie dotrze on do odbiorcy, jest traktowany jako niepotrzebny i likwidowany. Usługi izochroniczne charakteryzują się w stosunku do usług asynchronicznych wyższym priorytetem dostarczania. Może jednak zdarzyć się taka sytuacja, w której większość stacji rozpocznie przesyłanie ruchu izochronicznego, co spowoduje brak obsługi ruchu asynchronicznego (przestaną działać np. takie aplikacje, jak: telnet, ftp, www, itp.). Sytuacja taka jest wysoce niepożądana. Konieczne jest zatem wprowadzenie mechanizmu pozwalającego kontrolować minimalną wielkość ruchu asynchronicznego (w protokole IEEE 82.11 problem ten rozwiązuje superramka, ale tylko dla sieci z infrastrukturą). Pomysł polega na wprowadzeniu dodatkowego licznika, nazywanego dalej licznikiem T2, który będzie służyć do odmierzania tzw. czasu życia pakietu asynchronicznego znajdującego się w buforze stacji nadawczej na pozycji pierwszej (liczniki T1 i T3 nie są w proponowanej wersji protokołu PUMA wykorzystywane). Jak wykazały badania, ich standardowe użycie powoduje zmniejszenie się ogólnej wydajności pracy sieci. Jeżeli czas życia pierwszego w kolejce do nadania pakietu asynchronicznego zostanie przekroczony, uzyskuje on wyższy priorytet (równy priorytetowi dla transmisji izochronicznej) i stacja rywalizuje wtedy o uzyskanie praw nadawania ze stacjami przesyłającymi ruch izochroniczny. Zwiększa to prawdopodobieństwo transmisji pakietu asynchronicznego, który po pewnym czasie na pewno zostanie przesłany. Pozostałe pakiety asynchroniczne znajdujące się w tym czasie w buforze stacji nadającej w dalszym ciągu posiadają niski priorytet transmisji, a wartość licznika T2 jest po raz kolejny odliczana dla pakietu znajdującego się w kolejce na pozycji pierwszej. Wprowadzony w protokole PUMA mechanizm pozwala regulować minimalny poziom realizowanego ruchu asynchronicznego dla każdej ze stacji. Oczywiście zależy on od liczby uczestniczących w rywalizacji o dostęp do medium stacji przesyłających ruch izochroniczny. W protokole PUMA wprowadzono dodatkowo regułę uniemożliwiającą stacji asynchronicznej nadawanie zgodnie z mechanizmem packet-train po upływie timeout u odmierzonego przez licznik T2. Stacja asynchroniczna może wtedy przesłać po czasie PIFS tylko jeden pakiet asynchroniczny. Wprowadzenie takiej reguły skutkuje mniejszymi stratami pakietów, co pozwala na uzyskanie większej wydajności dla ruchu izochronicznego. Sama nazwa protokołu PUMA powstała właśnie dzięki pomysłowi wykorzystania licznika T2. Stacja, która pracuje w trybie asynchronicznym, dzięki licznikowi T2 niezależnie od wielkości oferowanego ruchu izochronicznego i tak uzyska po pewnym czasie (określonym przez wartość licznika T2) możliwość ubiegania się o dostęp do medium. Pomysł modyfikacji mechanizmu backoffu narodził się podczas przeprowadzania analizy wyboru szczelin z okna współzawodnictwa przez pracujące w sieci stacje. Zauważono bardzo niekorzystny efekt, który występuje w sieci złożonej z dużej liczby stacji, pracującej pod dużym obciążeniem. Ponieważ dla dużej liczby stacji startowy rozmiar okna CWmin (Contention Window minimum) jest zbyt mały, niezależnie od stosowanej warstwy fizycznej, przy dużej wielkości ruchu oferowanego powstaje duża liczba kolizji (problem odpowiedniego doboru parametrów okna współzawodnictwa w zależności od liczby pracujących w sieci stacji został przedstawiony w pracy [11]). Powoduje to znaczny spadek w wydajności pracy sieci. Stacje, które przesłały poprawnie ramkę z danymi, za każdym razem redukują okno współzawodnictwa do wielkości CWmin. Ponieważ dla przypadku, w którym sieć pracuje pod bardzo dużym obciążeniem, stacja ta ma przygotowaną do transmisji kolejną ramkę (w takim wypadku bufor stacji po pewnym czasie wypełnia się całkowicie ramkami z danymi) i rozpoczyna kolejne próby trans- 16

misji, kończące się zwykle kolizjami, gdyż okno współzawodnictwa powinno być w tym wypadku znacznie większe. Dopiero po pewnym czasie stacja wybiera odpowiednio duże okno współzawodnictwa i udaje się jej przesłać kolejną ramkę. Modyfikacja mechanizmu backoffu polega na dzieleniu go przez połowę (aż do osiągnięcia wartości CWmin) po każdym prawidłowym przesłaniu ramki z danymi, w identyczny sposób, w jaki jest on zwiększany przy nieudanej próbie transmisji. Wartość backoffu nie zmniejsza się więc gwałtownie do wartości CWmin, tak jak w przypadku backoffu stosowanego w standardzie, lecz fluktuuje w okolicach wartości optymalnych dla prawidłowego przesłania ramki z danymi (zarówno prawdopodobieństwo kolizji jest niewielkie, jak i niewielka jest liczba niewykorzystanych szczelin czasowych w oknie współzawodnictwa). Sytuacja ta została przedstawiona na rysunku 3. Mechanizm ten nazwano backoffem DIDD. W warunkach silnego obciążenia, w sieci, w której pracuje bardzo duża liczba stacji, prowadzi to do znacznego zmniejszenia się liczby kolizji, a więc powinno powodować zwiększenie wydajności pracy sieci. Ponieważ wielkość CWmin jest w standardzie różna dla warstw DSSS (Direct Sequence Spread Spectrum) i FHSS (Frequency Hopping Spread Spectrum), większy zysk powinien być obserwowany dla przypadku, w którym początkowy rozmiar okna jest mniejszy, a więc dla warstwy FHSS. 255 Należy zastanowić się, czy istnieje jakaś sytuacja, w której prezentowany mechanizm mógłby ujemnie wpłynąć na efektywność działania sieci. Otóż sytuacja taka mogłaby powstać, gdyby większość stacji w tym samym momencie przerwała transmisję (w buforach nie pozostałby żaden, przeznaczony do nadania, pakiet). W takim wypadku okno współzawodnictwa mogłoby się okazać zbyt szerokie i duża część czasu pracy sieci zostałaby przeznaczona na odliczanie zbyt dużych wartości backoffu. Sytuacja ta poprawiałaby się wraz z kolejnymi transmisjami i już po odliczeniu kilku backoffów sieć pracowałaby efektywnie. W praktyce, sytuacja taka nie powinna wystąpić z uwagi na fakt uśredniania się ruchu, zwłaszcza przy dużej liczbie aktywnych stacji. Z przeprowadzonych w pracy [1] badań wynika, że w systemach opartych na bezprzewodowym medium transmisja krótkich pakietów z danymi jest nieefektywna. Wpływ na to ma przede wszystkim bardzo duża ilość informacji nadmiarowej w stosunku do właściwych danych. Dodatkowo, z transmisją każdego pakietu wiąże się przeprowadzenie wszystkich procedur rywalizacyjnych, które znacznie obniżają wydajność protokołu. W protokole PUMA wykorzystano mechanizm pozwalający na zwiększenie wydajności pracy sieci, dzięki kilkukrotnej transmisji (liczba transmisji jest ustalana jako parametr protokołu) kolejno po sobie następujących pakietów z danymi pochodzących od tej samej stacji. 255 127 127 127 63 63 CW min 7 15 31 transmisja zakończona sukcesem transmisja zakończona sukcesem 1 retransmisja transmisja zakończona sukcesem 3 retransmisja 2 retransmisja 1 retransmisja 1 próba transmisji Rys. 3. Przykład zwiększania i zmniejszania się okna współzawodnictwa w mechanizmie backoffu DIDD 17

Transmitowane w zarezerwowanym wcześniej medium pakiety są, dzięki dominacji pakietu CTS nad RTS, przesyłane w bezkolizyjny sposób. Taki sposób transmisji (stosowany w niektórych protokołach warstwy MAC (Medium Access Control) dla sieci bezprzewodowych: [6, 7]) jest w literaturze anglojęzycznej nazywany mechanizmem packet-train ciągu pakietów. Przykład użycia mechanizmu packet-train został przedstawiony na rysunku 4. około 1 s, jeżeli dodatkowo w sieci pracuje np. 1 stacji, to każda z nich ma możliwość uzyskania dostępu do medium średnio co 2 minuty sieć będzie wykazywała bardzo dużą wydajność, ale nie będzie zapewniała odpowiedniego komfortu pracy). Stosowanie mechanizmu packet-train można szczególnie polecić w przypadku transmisji krótkich pakietów, ale i wtedy parametr packet-train należy dobrać w rozsądnych granicach. L RTS DANE DANE S RTS CTS DANE CTS DANE ACK R RTS CTS DANE CTS DANE ACK X CTS CTS ACK Kanał RTS CTS DANE CTS DANE ACK Rys. 4. Przykład stosowania mechanizmu packet-train Stacja nadawcza rozpoczyna transmisję od procedury rezerwacji medium poprzez wymianę pakietów RTS/CTS. Jeżeli procedura ta zakończy się powodzeniem, oznacza to, że medium jest zarezerwowane i że można rozpocząć transmisję właściwych danych. Następuje wysłanie pakietu z danymi, który w swoim nagłówku posiada dodatkową flagę MORE informującą wszystkie inne stacje znajdujące się w otoczeniu stacji nadającej o tym, że za pewien czas rozpocznie się transmisja kolejnego pakietu z danymi. Wszystkie stacje, do których dotarła ta informacja, mają obowiązek wstrzymać swoje procedury transmisyjne do czasu rozpoczęcia transmisji kolejnego pakietu z danymi. Stacja docelowa po poprawnym odebraniu pakietu z danymi wysyła pakiet CTS, również z ustawioną flagą MORE, informując stację źródłową o tym, że poprawnie odebrała nadany przez nią pakiet z danymi oraz że może rozpocząć transmisję kolejnego pakietu. Wszystkie inne stacje znajdujące się w otoczeniu stacji odbiorczej, słysząc pakiet CTS mają obowiązek wstrzymać swoje procedury transmisyjne do zakończenia transmisji kolejnego pakietu. Należy pamiętać, że parametr określający liczbę transmisji kolejno po sobie następujących ramek z danymi powinien zostać dobrany w rozsądnych granicach, gdyż może to prowadzić do powstawania dużych opóźnień w uzyskaniu dostępu do medium przez inne stacje (przykładowo: transmisja 1 kolejno po sobie następujących ramek 2-bajtowych przy szybkości transmisji 2 Mbit/s spowoduje zablokowanie medium dla innych stacji na 3. Symulator protokołu PUMA Symulator pracuje na podstawie kalendarza zdarzeń. W kalendarzu przechowywany jest spis działań, jakie każda stacja realizuje. Program wykonuje się według następującego algorytmu. Po wprowadzeniu wszystkich parametrów i uruchomieniu symulacji pobierane jest pierwsze zdarzenie z kalendarza. Program sprawdza, czy warunki zajścia takiego zdarzenia są spełnione. Jeżeli tak, to zdarzenie jest realizowane. Realizacja taka odbywa się zwykle poprzez uaktualnienie pewnych specyficznych dla danego zdarzenia zmiennych. Po niektórych zdarzeniach uaktualniana jest również statystyka przebiegu symulacji. Kolejnym etapem realizacji zdarzenia jest wygenerowanie kolejnych zdarzeń, implikowanych przez to, które jest realizowane. Ostatnim krokiem jest usunięcie realizowanego zdarzenia z kalendarza i realizacja kolejnego zdarzenia. Czas trwania symulacji przeprowadzanych przy wykorzystaniu symulatora opartego na kolejce zdarzeń zależy od liczby stacji uczestniczących w symulacji, a w szczególności od liczby generowanych przez nie zdarzeń. Duża część danych jest przechowywana w symulatorze w sposób dynamiczny. Do późniejszej analizy danych zastosowano opcję zgrywania wszystkich parametrów oraz uzyskanych wyników pracy sieci na dysk. Wyniki symulacji zachowywane są w plikach (w większości w formacie html). Program posiada system graficznego menu pozwalający na łatwą konfigurację zadanej symulacji. Istnieje także 18

możliwość zapisu każdego kroku przeprowadzanej symulacji do pliku tekstowego (opcja szczególnie przydatna w celach diagnostycznych). Symulator umożliwia wszechstronne badanie efektywności pracy protokołu PUMA, a w szczególności: symulację jednego BSS; obsługę trybów: RTS+CTS+DATA+ACK, JAM+RTS+CTS+DATA; generację zgłoszeń zgodnie ze strumieniem Poissona (dla usług asynchronicznych) lub zgodnie z modelem ON-OFF (dla usług izochronicznych transmisji strumieni głosu 32 kbit/s lub 64 kbit/s); zadanie dowolnej szybkości transmisji w sieci; zadanie rozmiaru przesyłanych ramek DATA (stały rozmiar lub wybierany losowo z zadanego przedziału); przesyłanie ramek w asynchronicznym i izochronicznym trybie pracy; zadanie niezależnie parametru packet-train dla trybu izochronicznego i asynchronicznego; zadanie czasu życia pakietów izochronicznych; zadanie wartości parametru T2; zmiany praktycznie dowolnego parametru protokołu PUMA. Do napisania symulatora PUMA posłużono się językiem JAVA przy wykorzystaniu środowiska Java (TM) 2 JDK, Standard Edition Version 1.2.2. 4. Badanie wydajności protokołu PUMA W rozdziale tym przedstawione zostaną wyniki badań wydajności protokołu PUMA uzyskane przy wykorzystaniu opisywanego symulatora. Wykazane zostanie, że protokół PUMA zapewnia wysoki poziom sprawiedliwości w uzyskaniu przez stację dostępu do medium, pozwala na realizację usług z ograniczeniami czasowymi przy zapewnieniu stałej transmisji asynchronicznej, jest bardzo efektywny i stabilny. Dzięki zastosowaniu nowego mechanizmu backoffu DIDD uzyskano znaczne zwiększenie wydajności pracy sieci w warunkach silnego obciążenia ruchem, dla dużej liczby stacji. Dodatkowo, pomimo pewnych zmian w strukturze budowy ramek sygnalizacyjnych zostały zachowane wszystkie pola służące realizacji funkcji: synchronizacji, szyfrowania danych oraz zarządzania zużyciem energii. Obiektem badań była sieć ad-hoc, w której w obrębie jednego obszaru BSS (Basic Service Set) pracowała w zadanych warunkach różna liczba stacji. Podczas wszystkich symulacji przyjęto następujące założenia: Medium było wolne od błędów, tzn. każda ramka wysłana przez nadajnik była poprawnie odebrana i zdekodowana przez odbiornik. Zaniedbano efekt opóźnienia propagacji sygnału (założenie to jest realne przy odległościach pomiędzy stacjami nieprzekraczających kilkudziesięciu metrów). Wszystkie stacje słyszały się wzajemnie. Nie rozpatrywano sytuacji występowania stacji ukrytych. Żadna ze stacji nie przechodziła do trybu oszczędzania poboru energii. Badanymi wskaźnikami oceny wydajności sieci z protokołem PUMA były: wielkość ruchu realizowanego izochronicznego i asynchronicznego dla wszystkich oraz każdej ze stacji, średnie opóźnienie izochroniczne i asynchroniczne transmisji pakietu dla wszystkich oraz każdej ze stacji, procentowy poziom strat pakietów izochronicznych dla wszystkich oraz każdej ze stacji wynikający z przeterminowania ich ważności. Fizyczna przepływność sieci wynosiła 2 Mbit/s. Stacje rozmieszczone były tak, aby mogły słyszeć się wzajemnie. Dla stacji nadających asynchronicznie przybycia nowych pakietów były generowane jako strumień Poissona. Stacje realizujące transmisję strumieni głosu pracowały w oparciu o model ON-OFF. Sieć badano, zwiększając ruch oferowany izochroniczny (poprzez zmianę liczby usług izochronicznych) i asynchroniczny do wartości przekraczającej fizyczną przepływność sieci. Modelowanie symulacyjne prowadziło do określenia charakterystyk dla stanu ustalonego. Badania realizowano w taki sposób, by 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ł przetransmitowaniu w sieci 5 pakietów przez każdą ze stacji, tzn. stacja, która jako pierwsza przetransmitowała 5 pakietów, 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%. 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. 19

4.1. Analiza wydajności protokołu dla transmisji asynchronicznej W podrozdziale tym przedstawiono wyniki badań symulacyjnych pracy protokołu PUMA w asynchronicznym trybie pracy. Analizie poddany został wpływ parametrów warstwy fizycznej, długości pakietu oraz mechanizmu packet-train na wydajność pracy sieci. We wszystkich przypadkach sieć pracowała z szybkością 2 Mbit/s, co pozwala na bezpośrednie porównanie wyników z wynikami uzyskanymi we wcześniejszych pracach przy badaniu wydajności pracy sieci standardu IEEE 82.11. Protokół PUMA pracował w asynchronicznym trybie transmisji: RTS+CTS+DATA+ACK. Wszystkie zdarzenia były generowane jako strumień Poissona. Dla większości z przypadków transmitowane pakiety z danymi miały rozmiar 1 bajtów. Większość przyjętych parametrów symulacji została zebrana w postaci tabel i odpowiada parametrom warstwy fizycznej DSSS. Badania przeprowadzano dla różnej liczby pracujących w obszarze BSS terminali (2, 25), co odpowiada typowemu, średniemu zagęszczeniu stacji. Każda ze stacji posiadała bufor o nieograniczonym rozmiarze, w którym umieszczane były pakiety generowane przez źródło. Podrozdział ten nie zawiera badań wydajności pracy sieci dla różnych wartości licznika T2, pomimo to że jest on stosowany dla trybu asynchronicznego. Wyniki takie zostały przedstawione w podrozdziale omawiającym zależności pomiędzy wielkością realizowanego ruchu izochronicznego i asynchronicznego. Większość badań przeprowadzano, zmieniając wielkość ruchu oferowanego (od zera do wartości znacznie przekraczającej szybkość transmisji sieci) i zbierając przy tym statystyki wielkości ruchu realizowanego i średniego opóźnienia transmisji pakietów. Średnie opóźnienie transmisji wyznaczono dla przedziału, dla którego wielkość realizowanego ruchu asynchronicznego jest równa wielkości ruchu oferowanego. W protokole PUMA, podobnie jak w protokole IEEE 82.11 możliwe jest wykorzystanie trzech typów warstw fizycznych: 1) DSSS, 2) FHSS, 3) IR. Dla każdej z warstw określona grupa parametrów protokołu przyjmuje różne wartości. Są one uzależnione od przedziałów czasowych narzuconych przez użycie określonej warstwy fizycznej oraz wynikają z konstrukcji samego protokołu. Do tej grupy parametrów należą: czas SIFS, czas DIFS, długość szczeliny, początkowy rozmiar okna współzawodnictwa CWmin, maksymalny rozmiar okna współzawodnictwa CWmax, preambuła warstwy fizycznej oraz długość pakietu CTS. Podobnie jak w protokole IEEE 82.11, z wstępnego porównania wszystkich czasów IFS oraz wielkości szczeliny czasowej wynika, że wybór warstwy fizycznej będzie miał znaczący wpływ na wydajność pracy protokołu. Jako pierwsze, przedstawiono badania wydajności pracy protokołu PUMA dla trzech typów warstw fizycznych. Badania przeprowadzono dla 25 stacji. Przeprowadzone symulacje pozwoliły określić wielkości przepustowości osiąganych przez sieć oraz średnie wielkości opóźnień podczas transmisji ramek o długości 1 bajtów przy zmiennej wielkości ruchu oferowanego. Tabela 1 przedstawia przyjęte parametry sieci dla warstw: DSSS, FHSS oraz IR. W tabeli 2 zaprezentowano pozostałe parametry symulacji. Wszystkie parametry (z wyłączeniem wprowadzonych modyfikacji) są zgodne z parametrami zalecanymi przez standard IEEE 82.11. Tabela 1 Parametry warstw: DSSS, FHSS oraz IR Parametr Warstwa DSSS Warstwa FHSS Warstwa IR Czas SIFS 1 µs 28 µs 7 µs Czas DIFS 5 µs 13 µs 23 µs Czas trwania jednej szczeliny 2 µs 5 µs 8 µs Startowy rozmiar okna CW 31 szczelin 15 szczelin 63 szczeliny Maksymalna liczba szczelin w oknie CW 123 szczeliny 123 szczeliny 123 szczeliny Preambuła warstwy fizycznej 18 oktetów 96 µs 2 µs Długość pakietu CTS 23 oktety 27 oktetów 22 oktety 2

Tabela 2 Pozostałe parametry sieci, przy których badano wpływ warstwy fizycznej na wydajność pracy Parametr Długość pakietu RTS Długość pakietu ACK Nagłówek DATA Długość ramki DATA Packet-train Wielkość bufora każdej ze stacji Licznik T2 Szybkość pracy sieci Liczba stacji 25 Wartość 2 oktetów 14 oktetów 32 oktety 1 bajtów wyłączony 2 Mbit/s Przeprowadzone symulacje pozwoliły na sporządzenie wykresów zależności realizowanej przepustowości od ruchu oferowanego (rys. 5) oraz zależności średniego opóźnienia transmisji od ruchu oferowanego (rys. 6) dla warstw fizycznych: DSSS, FHSS oraz IR dla 25 stacji. Na wykresach, celem porównania, przedstawiono również wyniki uzyskane przy badaniu wydajności funkcji DCF standardu IEEE 82.11. Niezależnie od liczby stacji i typu warstwy fizycznej, dla małych wartości ruchu oferowanego obserwowany jest liniowy wzrost ruchu realizowanego. Po przekroczeniu pewnego poziomu ruchu oferowanego dla każdego z przypadków realizowana przepustowość ustala się na stałym poziomie. W porównaniu z protokołem IEEE 82.11 nie obserwujemy spadku wydajności pracy sieci. Zjawisko to można wyjaśnić w następujący sposób. Największy wpływ na uniezależnienie się od negatywnego wpływu liczby stacji na wydajność pracy sieci przynosi stosowanie mechanizmu potwierdzeń RTS+CTS (szybsze wykrywanie kolizji), zlikwidowanie liczników T1 i T3 (brak zbyt długiego oczekiwania na ramkę będącą potwierdzeniem przed podjęciem kolejnych procedur rywalizacyjnych) oraz wykorzystanie mechanizmu backoffu DIDD (zmniejszenie liczby kolizji). Niezależnie od liczby stacji największą wydajność protokół PUMA osiąga dla warstwy fizycznej pracującej w zakresie podczerwieni IR. W warunkach nasycenia (gdy ruch realizowany osiąga stały poziom) dla 25 stacji poziom ruchu realizowanego wynosi ok. 1765 kbit/s. Dla warstwy fizycznej DSSS wydajność protokołu spada o ok. 115 kbit/s. Dla warstwy FHSS osiąga najniższą wartość 1535 kbit/s. Z przeprowadzonych badań wynika, że wydajność sieci jest silnie uzależniona od parametrów warstwy fizycznej im mniejsze są czasy IFS, odstęp szczeliny czasowej w oknie współzawodnictwa oraz preambuła warstwy fizycznej, tym większa jest ogólna wydajność sieci. Niezależnie od typu warstwy fizycznej, dla małych wartości ruchu oferowanego opóźnienie transmisji kształtuje się na poziomie 5 ms. Początkowy wzrost ruchu oferowanego przynosi niewielkie zmiany średniego opóźnienia transmisji, dalsze zwiększanie wielkości ruchu oferowanego prowadzi jednak do gwałtownego zwiększenia się średniego opóźnienia oraz stałego zwiększania się różnic w zależności od rodzaju zastosowanej warstwy fizycznej. Z uwagi na nieograniczoną pojemność bufora stacji na wykresach przedstawiono krzywe dla których wielkość ruchu oferowanego nie przekracza ruchu realizowanego. Ruch realizowany [kbit/s] 2 18 16 14 12 1 8 6 4 2 5 1 15 2 25 3 Ruch oferowany [kbit/s] warstwa DSSS - PUMA warstwa FHSS - PUMA warstwa IR - PUMA warstwa DSSS - IEEE 82.11 warstwa FHSS - IEEE 82.11 warstwa IR - IEEE 82.11 Rys. 5. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla 25 stacji, trzech warstw fizycznych: DSSS, FHSS oraz IR 21

,3,25 Opóźnienie [s],2,15,1,5 2 4 6 8 1 12 14 Ruch oferowany [kbit/s] warstwa DSSS - PUMA warstwa FHSS - PUMA warstwa IR - PUMA warstwa DSSS - IEEE 82.11 warstwa FHSS - IEEE 82.11 warstwa IR - IEEE 82.11 Rys. 6. Wykres średniego opóźnienia w funkcji ruchu oferowanego dla 25 stacji, trzech warstw fizycznych: DSSS, FHSS oraz IR Protokół PUMA, podobnie jak protokół standardu IEEE 82.11 pozwala na transmisję ramek o wielkości pola danych od do 2312 bajtów. Dla zapewnienia transmisji ramek dłuższych, np. pochodzących z takich sieci, jak FDDI (Fiber Distributed Data Interface), Token Ring etc., niezbędne jest stosowanie fragmentacji. W przypadku transmisji ramek krótkich, np. 53-bajtowych komórek ATM-owych, w celu uzyskania wydajnej transmisji, konieczne może się okazać składanie wielu krótkich ramek w jedną większą ramkę. W analizowanym przykładzie badano osiąganą w sieci przepustowość oraz średnie opóźnienie transmisji. Przyjęto następujące długości transmitowanych ramek: 53, 432, 15, 225 bajtów. Badania zostały przeprowadzone dla 2 stacji rywalizujących o dostęp do medium. Większość parametrów została zaczerpnięta wprost ze standardu IEEE 82.11 i odpowiada parametrom warstwy fizycznej DSSS. Część parametrów sieci była niezmienna dla wszystkich symulacji. W tabeli 3 przedstawiono założone w czasie symulacji wartości poszczególnych parametrów. Przeprowadzone symulacje pozwoliły na otrzymanie serii wykresów zależności realizowanej przepustowości od ruchu oferowanego (rys. 7) oraz średniego opóźnienia transmisji od ruchu oferowanego (rys. 8) dla czterech długości pakietów z danymi: 225, 15, 432 oraz 53 bajtów dla 2 stacji. Podobnie jak w przypadku standardu IEEE 82.11 obserwujemy negatywny wpływ transmisji krótkich pakietów na wydajność pracy sieci. Przyczyną tak małej wydajności sieci jest zbyt duży nadmiar wiadomości kontrolnych (mini-pakiety kontrolne RTS/CTS, preambuła, kod korekcyjny, adresy, sekwencja kontrolna etc.) w stosunku do faktycznej ilości transmitowanych danych. Nieustanna rywalizacja stacji o uzyskanie dostępu do medium przynosi dalszy spadek wydajności pracy sieci. Tabela 3 Wykaz parametrów przyjętych przy badaniu wpływu długości pakietu na wydajność pracy sieci Parametr Wartość Czas SIFS 1 µs Czas DIFS 5 µs Długość pakietu RTS Długość pakietu CTS Długość pakietu ACK Nagłówek DATA Startowy rozmiar okna CW Maksymalna liczba szczelin w oknie CW 2 oktetów 23 oktety 14 oktetów 32 oktety 31 szczelin 123 szczeliny Czas trwania jednej szczeliny 2 µs Preambuła warstwy fizycznej 18 oktetów Wielkość bufora każdej ze stacji Licznik T2 Packet-train Szybkość pracy sieci Wyłączony 2 Mbit/s Liczba stacji 2 Wielkości transmitowanych ramek 53, 432, 15, 225 bajtów Wzrost długości pakietu przynosi zwiększenie się maksymalnego poziomu wielkości ruchu realizowanego. Do pewnej granicy wzrost ruchu realizowanego w funkcji ruchu oferowanego dla każdej długości pakietu narasta liniowo. Po przekroczeniu pewnej granicy, wielkość ruchu realizowanego ustala się i jest niezależna od wielkości ruchu oferowanego. 22

Ruch realizowany [kbit/s] 2 18 16 14 12 1 8 6 4 2 5 1 15 2 25 3 Ruch oferowany [kbit/s] 225 bajtów - PUMA 15 bajtów - PUMA 432 bajty - PUMA 53 bajty - PUMA 225 bajtów - IEEE 82.11 15 bajtów - IEEE 82.11 432 bajty - IEEE 82.11 53 bajty - IEEE 82.11 Rys. 7. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla 2 stacji Opóźnienie [s],7,6,5,4,3,2,1 2 4 6 8 1 12 14 16 18 Ruch oferowany [kbit/s] 225 bajtów - PUMA 15 bajtów - PUMA 432 bajty - PUMA 53 bajty - PUMA 225 bajtów - IEEE 82.11 15 bajtów - IEEE 82.11 432 bajty - IEEE 82.11 53 bajty - IEEE 82.11 Rys. 8. Wykres średniego opóźnienia transmisji w funkcji ruchu oferowanego dla 2 stacji Wielkość ruchu realizowanego ustala się na poziomie: 183 kbit/s dla pakietów o długości 225 bajtów, 175 kbit/s dla pakietów 1 bajtowych, 1345 kbit/s dla pakietów 432 bajtowych i 45 kbit/s dla pakietów 53 bajtowych. Wpływ długości pakietu na wydajność ruchu realizowanego jest silnie nieliniowy. W zależności od długości przesyłanych pakietów dla małych wartości ruchu oferowanego opóźnienie transmisji zmienia się od 1 (dla pakietów 53 bajtowych) do 1 ms (dla pakietów 225 bajtowych). Początkowy wzrost ruchu oferowanego przynosi niewielkie zmiany średniego opóźnienia transmisji, dalszy wzrost wielkości ruchu oferowanego prowadzi w końcu do gwałtownego zwiększenia się średniego opóźnienia. Dla krótszych ramek wzrost ten jest obserwowany znacznie wcześniej. Jak pokazują badania, transmisja krótkich pakietów z danymi przynosi drastyczny spadek wydajności pracy sieci. Aby temu zapobiec, w protokole PUMA wykorzystano mechanizm packet-train. W tej części pracy przedstawiono wyniki badań wpływu mechanizmu packet-train zastosowanego w protokole PUMA na wydajność pracy sieci. Transmitowane pakiety z danymi miały wielkość 53 bajtów. Parametr packet-train podczas przeprowadzania symulacji przyjmował wartości: 2, 4, 8, co odpowiada transmisji: 3, 5, 9 kolejno po sobie następujących pakietów z danymi (poprzedzonych oczywiście poprawnie zakończoną wymianą pakietów RTS+CTS). 23

7 6 Ruch realizowany [kbit/s] 5 4 3 2 1 5 1 15 2 25 3 Ruch oferowany [kbit/s] 53B - bez packet train 53B - 2 packet train 53B - 4 packet train 53B - 8 packet train Rys. 9. Wykres ruchu realizowanego w funkcji ruchu oferowanego dla 25 stacji,12,1 Opóźnienie [s],8,6,4,2 5 1 15 2 25 3 35 4 45 5 Ruch oferowany [kbit/s] 53B - bez packet train 53B - 2 packet train 53B - 4 packet train 53B - 8 packet train Rys. 1. Wykres średniego opóźnienia transmisji w funkcji ruchu oferowanego dla 25 stacji Wyniki zostały porównane z przypadkiem, dla którego mechanizm packet-train został wyłączony. Badania przeprowadzono dla 25 stacji. Podczas symulacji przyjęto wartości parametrów zgodne z tabelą 3. Na rysunkach 9 i 1 przedstawiono odpowiednio wyniki badań ruchu realizowanego i średniego opóźnienia transmisji w funkcji ruchu oferowanego. Na każdym z wykresów znajdują się 4 krzywe, uzyskane dla parametru packet-train:, 2, 4, 8. Dla małych wartości ruchu oferowanego obserwowany jest liniowy wzrost ruchu realizowanego. Po przekroczeniu pewnego poziomu ruchu oferowanego, realizowana przepustowość osiąga stały poziom. W normalnym trybie pracy (bez użycia mechanizmu packet-train) protokół PUMA pozwala na uzyskanie ruchu realizowanego na poziomie 4 kbit/s. Zastosowanie mechanizmu packet-train powoduje wzrost przepustowości od 18 kbit/s dla packet-train=2 do 285 kbit/s dla packet-train=8. Dla małych wartości ruchu oferowanego opóźnienie transmisji wynosi 1 ms. Początkowy wzrost ruchu oferowanego przynosi niewielkie zmiany średniego opóźnienia transmisji, dalsze zwiększanie wielkości ruchu oferowanego prowadzi w końcu do gwałtownego zwiększenia się średniego opóźnienia. Użycie mechanizmu packet-train nie przynosi wielkich zmian w wielkościach uzyskiwanych opóźnień im większy jest parametr packet-train, tym większy jest poziom ruchu realizowanego i tym mniejsze średnie opóźnienie transmisji. 24

4.2. Analiza wydajności protokołu dla transmisji izochronicznej Podrozdział ten przedstawia wyniki badań protokołu PUMA pracującego w izochronicznym trybie pracy. Analizowano wpływ parametrów warstwy fizycznej oraz czasu życia pakietu izochronicznego na wydajność pracy sieci dla różnej liczby stacji realizujących ruch izochroniczny (różnej liczby usług transmisji głosu) i przepustowości pracy kodeka głosu 64 kbit/s. We wszystkich przypadkach sieć pracowała z szybkością 2 Mbit/s. Protokół PUMA zawsze wykorzystywał izochroniczny tryb transmisji: JAM+RTS+CTS+DATA. Do wygenerowania ruchu izochronicznego posłużyły źródła głosu, które zostały zamodelowane jako strumień zdarzeń ON-OFF. W dwustanowym łańcuchu Markowa opisującym źródło głosu istnieją dwa stany: 1) rozmowa, 2) cisza. Czas przebywania źródła w tych stanach jest określony rozkładem wykładniczym o wartościach średnich, odpowiednio 1, s dla stanu rozmowy oraz 1,35 s dla stanu ciszy. Stosowany model ON-OFF pracuje zgodnie z zaleceniem G.711 i co 2 ms generowany jest przez źródło znajdujące się w stanie ON pakiet o wielkości 16 bajtów. Pakiet jest traktowany jako spóźniony, jeżeli od momentu wygenerowania upłynęło 15 ms i w czasie tym nie został on wysłany do odbiornika. Podczas przeprowadzania symulacji dopuszczono losową utratę części pakietów, wynikającą z przeterminowania ich ważności. Podobnie jak w przypadku badania protokołu PUMA dla ruchu asynchronicznego, ze wstępnego porównania wszystkich czasów IFS, wielkości szczeliny czasowej oraz preambuły warstwy fizycznej wynika, że wybór warstwy fizycznej będzie miał znaczący wpływ na wydajność pracy protokołu. Badania przeprowadzono dla 2, 4, 6,..., 2n pracujących w sieci stacji, co odpowiada odpowiednio transmisji 1, 2, 3,..., n dupleksowych usług transmisji głosu. Dla każdego z przypadków sprawdzano liczbę przeterminowanych pakietów izochronicznych. Jeżeli przekraczała ona 1% (dopuszczalny przyjęty procent utraty pakietów izochronicznych), oznaczało to, że w sieci pracuje już maksymalna liczba stacji nadających w trybie izochronicznym. Źródła ruchu zbudowane były w oparciu o model ON- OFF. Zdarzenia były generowane zgodnie z przyjętym przez Brady ego modelem głosu [3]. Zebrane wyniki przedstawiają statystyki wielkości ruchu realizowanego izochronicznego, średniego opóźnienia izochronicznego transmisji oraz procentowego poziomu strat pakietów. Przyjęte wartości parametrów sieci dla warstw: DSSS, FHSS oraz IR są zgodne z tabelą 1. Pozostałe wartości parametrów sieci zostały przedstawione w tabeli 4. Przeprowadzone badania pozwoliły na otrzymanie wykresów ruchu realizowanego, średniego opóźnienia oraz procentowej straty pakietów w funkcji liczby stacji dla różnych warstw fizycznych (DSSS, FHSS, IR) (rys. 11 i 12). Dla małej liczby stacji (usług) wzrost ruchu realizowanego jest liniowy. Nie zaobserwowano także strat pakietów. Po przekroczeniu pewnego progu liczby stacji (usług) wielkość ruchu realizowanego dąży do osiągnięcia stałej wartości. Rozpoczyna się także gwałtowny wzrost procentowej liczby odrzucanych w wyniku przeterminowania pakietów. W zależności od typu stosowanej warstwy fizycznej sieć może zrealizować różną liczbę usług. Podczas transmisji strumieni głosu najlepsze rezultaty osiąga sieć, pracując z wykorzystaniem warstwy fizycznej IR, najgorsze z FHSS. 12 12 Ruch realizowany [kbit/s] 1 8 6 4 2 1 8 6 4 2 Straty pakietów [%] 2 4 6 8 1 12 14 16 18 222242628332343638442444648 Liczba stacji DSSS - ruch realizowany FHSS - ruch realizowany IR - ruch realizowany DSSS - straty pakietów FHSS - straty pakietów IR - straty pakietów Rys. 11. Wykres ruchu realizowanego oraz procentowa strata pakietów w funkcji liczby stacji (usług) 25

Opóźnienie [s],7,6,5,4,3,2,1 12 1 8 6 4 2 Straty pakietów [%] 2 4 6 8 1 12 14 16 18 222242628332343638442444648 Liczba stacji DSSS - opóźnienie FHSS - opóźnienie IR - opóźnienie DSSS - straty pakietów FHSS - straty pakietów IR - straty pakietów Rys. 12. Wykres średniego opóźnienia oraz procentowa strata pakietów w funkcji liczby stacji (usług) Tabela 4 Wykaz pozostałych parametrów przyjętych przy badaniu wydajności pracy sieci Parametr Długość pakietu RTS Długość pakietu ACK Nagłówek DATA Długość ramki DATA Packet-train Szybkość pracy sieci Liczba stacji Wielkość bufora stacji Czas życia pakietu izochronicznego Wartość 2 oktetów 14 oktetów 32 oktety 16 bajtów dla 64 kbit/s Wyłączony 2 Mbit/s 2, 4, 6,..., n,15 s Stosując warstwę fizyczną IR można zaimplementować 24 usługi transmisji głosu (usługa dupleksowa pomiędzy dwoma stacjami), dla DSSS wartość ta wynosi 19, a dla warstwy FHSS jest ona równa 16. Dla wszystkich przypadków maksymalne straty pakietów (dla maksymalnych wartości możliwych do zrealizowania usług) są na poziomie 1%. Dla małej liczby stacji (usług) niezależnie od typu stosowanej warstwy fizycznej opóźnienie kształtuje się na poziomie 1 2 ms. Po przekroczeniu pewnego poziomu ruchu oferowanego (liczby usług, stacji) obserwujemy stosunkowo gwałtowny wzrost średniego opóźnienia transmisji oraz procentowej straty pakietów. Maksymalne wielkości średnich opóźnień transmisji (dla maksymalnych wartości strat pakietów) są na poziomie kilkudziesięciu milisekund niezależnie od typu stosowanej warstwy fizycznej (różna jest jedynie maksymalna liczba możliwych do realizacji usług). Określenie wymagań dotyczących opóźnienia transmisji dla usługi głosowej nie jest sprawą prostą i w dużej mierze zależy od konkretnego użytkownika. Zadanie to zostało usystematyzowane w zaleceniu G.114, z którego wynika, że granicznym opóźnieniem gwarantującym jeszcze wysoki komfort rozmowy jest opóźnienie przekazu na poziomie 2 ms. Dla przypomnienia, opóźnienie przekazu przekraczające 3 ms przypomina transmisję półdupleksową lub rozmowę z wykorzystaniem przycisku wciśnij aby mówić. Do przeprowadzenia symulacji postanowiono przyjąć trzy, znacznie różniące się od siebie, graniczne wartości opóźnień przekazu. Czas życia pakietów izochronicznych został więc ustalony odpowiednio na poziomie: 5 ms, 15 ms oraz 5 ms. Pierwsza wielkość opóźnienia (wartość 5 ms) zapewnia bardzo wysoki komfort przekazu opóźnienie transmisji pakietów między nadawcą a odbiorcą jest praktycznie niezauważalne. Opóźnienie na poziomie 15 ms stanowi graniczną wartość opóźnienia gwarantującą jeszcze wysoką jakość rozmowy. Ostatnia, przyjęta wartość opóźnienia (5 ms) oznacza bardzo niski komfort rozmowy, akceptowalny jedynie w wyjątkowych sytuacjach. Transmitowane pakiety z danymi miały podobnie jak w poprzednim przypadku wielkość 16 bajtów (przepływność 64 kbit/s). Przeprowadzone badania pozwoliły określić wielkości ruchu realizowanego (rys. 13) (w tym maksymalną liczbę usług transmisji głosu) oraz średnie wielkości opóźnień transmisji pakietów z danymi (rys. 14). Badania przeprowadzono dla zmiennej liczby stacji: 2, 4, 6,..., 2n (1, 2, 3,..., n usług izochronicznych). 26