SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 2554

ANALIZA PERFORMANSI PROTOKOLA

TCP–snoop U BEŽIČNIM LOKALNIM

MREŽAMA

Dejan Jakšić

Zagreb, lipanj 2005.

Mentor rada: prof.dr.sc Alen Bažant Voditelj rada: dr.sc Željko Ilić

Sadržaj

Uvod........................................................................................................................................... 1

1. Protokol TCP - općenito .................................................................................................... 2

1.1. Kratki uvod u protokol TCP ...................................................................................... 2

2. Protokol TCP-snoop........................................................................................................... 9

2.1. Metoda SnoopData()................................................................................................ 12

2.2. Metoda SnoopAck().................................................................................................. 13

2.3. Odnos protokol TCP-snoop - protokol usmjeravanja ............................................. 15

2.4. Alternativna rješenja na sloju linka.......................................................................... 16

2.4.1. Smjer predajnik pokretnog čvora – prijemnik bazne stanice........................... 17

2.4.2. Smjer predajnik bazne stanice – prijemnik pokretnog čvora........................... 17

3. Rezultati simulacije i opis programa................................................................................ 20

3.1. Model rješenja simulatora........................................................................................ 20

3.2. Parametri simulacije i komponente simulatora........................................................ 21

3.2.1. Fritchmanov model bežičnog kanala s gubicima............................................. 23

3.3. Rezultati simulacije.................................................................................................. 24

Zaključak.................................................................................................................................. 31

Literatura.................................................................................................................................. 32

Skraćenice ................................................................................................................................ 33

Popis stranih izraza .................................................................................................................. 34

Dodatak .................................................................................................................................... 35

1

Uvod

Cilj ovog diplomskog zadatka je opis i implementacija poboljšanja protokola TCP (engl.

Transmission Control Protocol) u bežičnom okruženju. Za predmet razmatranja uzet je

protokol TCP snoop kao jedno od rješenja s najboljim rezultatima. Snoop se pridodaje kao

modul mrežnom sloju (engl. Network Layer) referentnog OSI modela (engl. Open System

Interconnection) bez zadiranja u transportni sloj (engl. Transport Layer). Integracija snoop

modula vrijedi za infrastrukturni WLAN (engl. Wireless Local Area Network) kao i za

neovisni WLAN (engl. ad hoc). U ovom radu za razmatranje je uzet infrastrukturni WLAN

jer u takvoj arhitekturi snoop daje najbolje rezultate. Protokol TCP je pouzdani transportni

protokol prvenstveno namijenjen žičnim mrežama gdje njegovi mehanizmi kontrole toka

uredno funkcioniraju. Međutim, njegova implementacija u bežičnom okruženju je malo

problematična te su potrebne određene preinake. Sukladno s time razvila su se razna rješenja i

inačice protokola TCP u bežičnim lokalnim mrežama. Neke od karakteristika bežičnih mreža

su: visoka učestalost pogreške bita (engl. Bit Error Ratio), koji iznosi do čak 10-3, veliko

varijabilno kašnjenje segmenata (engl. jitter), kapacitet i veličina ćelije, interferencija s

drugim elektromagnetskim izvorima, promjena mrežne topologije i osjetno smanjena

propusnost (engl. throughput).

Sve navedene činjenice bitno utječu na kvalitetu usluge, QoS (engl. Quality of Service) ili

drugim riječima na stupanj zadovoljstva korisnika nekom mrežnom uslugom. Najveći

problem predstavlja bežični kanal, odnosno njegova nestabilnost pri prijenosu informacije od

pošiljatelja do primatelja. Snoop je samo jedno od razvijenih rješenja, ali kao takav pokazuje

najbolje rezultate u cilju povećanja propusnosti i efikasnosti rada protokola TCP u WLAN-u.

Napomena: Termin pristupna točka će se u nastavku rada koristiti ravnopravno kao i termin

bazna stanica u ovisnosti o tome dali se govori o WLAN-u ili WMAN-u (engl. Wireless

Metropolitan Area Network).

2

1. Protokol TCP - općenito

1.1. Kratki uvod u protokol TCP

Protokol TCP radi na način opisan u nastavku, a za detaljniju analizu rada protokola TCP

pogledati u (Stevens [1995]).

Protokol TCP je pouzdani transportni protokol i osnova je rada današnje Internet mreže, gdje

se veže uz mrežni protokol IP (engl. Internet Protocol). TCP pruža pouzdani prijenos

podataka i kontrolu toka koji uključuju mehanizme izbjegavanja zagušenja u mreži.

Pouzdanost je ostvarena kroz mehanizme slanja i očekivanja potvrda o ispravnom prijemu za

poslane segmente te korištenjem strategije ponovnog slanja nepotvrđenih segmenata

(retransmisija). Svaka potvrda poslana od primatelja sadrži informaciju o rednom broju

segmenta kojeg sljedećeg očekuje kao i o količini podataka koju je trenutno primatelj spreman

prihvatiti. Nadalje, pošiljatelj prilikom slanja svakog segmenta pokreće vremenski brojač i

izvodi ponovno slanje segmenta ukoliko potvrda o prijemu ne stigne prije isteka brojača

(engl. timeout).

Tri temeljna algoritma na kojima se zasniva rad protokola TCP su :

• Spori start (engl. slow start);

• Izbjegavnje zagušenja (engl. congestion avoidance) i

• Brzo ponovno slanje (engl. fast retransmission).

Navedeni algoritmi vrijede za ''temeljni TCP'', tj. Tahoe TCP dok se u ostalim inačicama

protokola uvode poboljšanja. Tako se za Reno TCP dodaje algoritam ubrzanog oporavka

(engl. fast recovery). Ovaj algoritam omogućuje da se umjesto pokretanja sporog starta nakon

primitka ponovljenih potvrda (uzimaju se u obzir tri potvrde) nastavi s izbjegavanjem

zagušenja. Time se povećava iskoristivost mrežnih resursa jer se ne čeka na istek vremenskog

brojača te ponovnog slanja.

Da bi se razumjela analitika dana u nastavku rada potrebno je opisati neke od temeljnih

varijabli i vrijednosti bitne za rad TCP-a. I pošiljatelj i primatelj imaju varijable prozora

zagušenja (engl. congestion window). Za pošiljatelja je to cwnd te predstavlja mjeru

kapaciteta mreže, a na strani primatelja to je rcvwnd i predstavlja mjeru kapaciteta na

odredišnoj strani. Maksimalni broj nepotvrđenih segmenata izražava se kao min{cwnd,

3

rcvwnd}. Kada primatelj primi segment van redoslijeda šalje ponovljenu potvrdu (obično se

uzimaju 3 ponovljene potvrde) i na taj način signalizira pošiljatelju da je segment na koji

pokazuje potvrda izgubljen te se taj segment ponovno šalje i izvršava se algoritam sporog

starta.

Mehanizam rada samog protokola dan je prvo grafički (Sl. 1-1), a zatim i matematički. Kao

što je vidljivo sa slike (Sl. 1-1) za vrijeme sporog starta vezan je eksponencijalni porast

prozora zagušenja, dok je izbjegavanje zagušenja linearan. Također vrijedi da nakon isteka

brojača spori start traje samo do polovice veličine prozora zagušenja.

Sl. 1-1 Spori start izbjegavanje zagušenja

Analiza i opis varijabli karakterističnih za protokol TCP dani su u nastavku :

Inicijalizacija :

cwnd = 1; // prilikom prijema svake potvrde poveća se za 1

sstresh = 65536; // put od sporog starta do izbjegavanja zagušenja (engl. slow start treshold)

Dolazak potvrde – ACK :

if ( cwnd < sstresh) // spori start

sstresh cwnd += MSS; // maksimalna veličina segmenta

else // izbjegavanje zagušenja (engl. congestion avoidance)

cwnd += MSS * MSS;

Dolazak dupliciranih potvrda – ACK :

cwnd /= 2; // smanjenje veličine prozora za pola te ponovno slanje segmenata počevši od

nepotvrđenog

4

sstresh = cwnd;

Pretpostavlja se za da je došlo do zagušenja u mreži i gubitka segmenta.

Istek vremenskog brojača - timeout :

sstresh = cwnd/2;

cwnd = 1; // ponovno slanje segmenta

Protokol TCP koristi princip klizećih prozora (engl. sliding window) prikazan na slici (Sl.

1-2), gdje veličina prozora pokazuje maksimalni broj segmenata koje mreža može primiti ili

drugim riječima kapacitet mreže. Bitno je naglasiti da i pošiljatelj i primatelj imaju svoje

prozore. U svakoj pristigloj potvrdi primatelj obavještava pošiljatelja o veličini svog prozora.

Prilikom slanja svaki segment podataka se označava rednim brojem (engl. sequence number)

koji se upisuje u zaglavlje segmenta (paketa). Najveća dopuštena veličina segmenta (MSS –

Maximum Segment Size) definiran je kao :

MSS = MTU – IPheader - TCPhedaer .

MTU (engl. Maximum Transfer Unit) je maksimalna veličina jedinice prijenosa za neki tip

mrežne tehnologije, dok se zaglavlja odnose na mrežni odnosno transportni sloj. U tablici

(Tablica 1) su prikazane veličine MTU-a definirani RFC (engl. Request for Comments)

dokumentima.

Tablica 1 Pregled MTU-a za pojedine mrežne tehnologije

RFC # Opis tehnologije MTU (okteta)

1356 X.25, ISDN 68

1055 Serial Line IP (SLIP) 1066

894, 895 Ethernet 1500

1042 4 Mbit/s Token Ring 4464

IBM standard 16 Mbit/s Token

Ring

17914

1374 HIPPI 65535

1390 FDDI 4532

5

Sl. 1-2 Mehanizam klizećeg prozora

Upravo zbog navedenih razloga TCP pruža pouzdani prijenos informacija i kontrolu toka.

Prva polovica klizećeg prozora odnosi se na poslane ali nepotvrđene segmenta dok je druga

polovica za segmente koji se mogu poslati odmah. Prilikom primitka svake potvrde klizeći

prozor se pomiče udesno za jedno mjesto. Bitno je još naglasiti da je protokol TCP pouzdan i

konekcijski orijentiran te kao takav ima ugrađen mehanizam uspostave konekcije. Razlog

tome je u mogućnosti razmjene parametara između pošiljatelja i primatelja te rezervacija

potrebnih resursa.

Postupak uspostave veze (Sl. 1-3) naziva se three-way handshake i karakterizira ga izmjena

sinkronizacijskih segmenata (SYN), dok je postupak raskidanja konekcije vezan uz razmjenu

FIN segmenata. Strana koja pokreće konekciju šalje svoj sinkronizacijski segment s rednim

brojem segmenta koji je slučajno odabran. Nakon primanja SYN segmenta primatelj odgovara

sa svojim SYN segmentom i rednim brojem segmenta kojeg sljedećeg očekuje. Naposljetku

pošiljatelj potvrđuje redni broj segmenta te započinje prijenos prvog podatkovnog segmenta.

Primjer slanja podatkovnih segmenata i načina rada protokola TCP prikazan je slikom (Sl.

1-4), (Kralj [2003]). Za navedeni primjer pošiljatelju je dozvoljeno slanje 5840 okteta

podataka i to od rednog broja 1000 uz pretpostavku da su svi segmenti veličine 1460 okteta.

Prozori na pošiljateljevoj i primateljevoj strani postavljeni su na 5840 okteta, a to znači da

pošiljatelj može poslati maksimalno 4 segmenta prije nego što stigne potvrda koja će ažurirati

njegov klizni prozor i omogućiti nastavak slanja. Nakon slanja svih 5840 okteta, stiže potvrda

koja potvrđuje prva 3 TCP segmenta. Klizeći prozori se ažuriraju te se dozvoljava slanje

dodatna 3 segmenta.

6

SYN seq = X

SYN seq = Y, ACK X+1

ACK Y+1

Strana A Strana B

Sl. 1-3 Three-way handshake

U trenutku kada su poslana sljedeća 3 segmenta pošiljatelj privremeno obustavlja slanje

podataka, veličina prozora je nula, a to traje sve dok ne stigne nova potvrda. Princip rada

klizećih prozora objašnjen je u (Kralj [2003]).

Sl. 1-4 Tok prijenosa TCP segmenata

Kao što se vidi iz prijašnjih objašnjenja protokol TCP koristi proširenu metodu ARQ (engl.

Automatic Repeat Request) Go-back-N uz proračun perioda vremenske kontrole na osnovu

procijenjenog vremenskog kružnog kašnjenja – RTT (engl. Round Trip Time). RTT je vrijeme

koje je proteklo od trenutka slanja segmenta do trenutka primitka potvrde o prijemu segmenta.

7

Protokol TCP na svaki gubitak segmenta ''reagira'' na način:

• Smanjenjem cwnd varijable na polovicu vrijednosti varijable sstresh. Ovo doprinosi

smanjenju količine podataka koji se šalju u mrežu. Na taj način smanjuju se gubici nastali

zagušenjem u mreži;

• Ponovnim postavljanjem varijable cwnd na vrijednost jednog segmenta i ulazak u spori

start te eksponencijalni rast prozora zagušenja do sstresh = cwnd/2 vrijednosti kada

počinje linearno izbjegavanje zagušenja;

• Vraćanje na početnu vrijednost i proračun vremenskog isteka brojača na osnovu

prethodnih vrijednosti i uz pomoć Karnovog algoritma koji kaže da u slučaju ponovnog

slanja segmenta, nova vrijednost vremena isteka brojača računa se množenjem prethodno

izračunate vrijednosti s faktorom γ koji je najčešće iznosa 2, (Stevens [1995]). Često se

ovaj mehanizam naziva i backoff strategija.

U slučaju velike učestalosti pogrešaka prozor zagušenja se smanjuje prije ponovnog slanja

segmenta. Protokol TCP je izvorno razvijan kao transportni protokol vezan uz žičane mreže te

je usko vezan uz mrežni protokol IP i upravo je zbog tih razloga potrebna modifikacija

protokola TCP u bežičnom okruženju.

Ostale inačice protokola TCP biti će samo nabrojane, više u (Stevens [1995]):

• New Reno TCP ;

• SACK TCP ;

• Vegas TCP.

Bitno je za naglasiti da Vegas TCP u odnosu na Reno TCP pokazuje povećanje propusnosti do

čak 70 % uz 50 – 70 % manje retransmisija. Na slici (Sl. 1-5) dana je podjela različitih inačica

protokola TCP u bežičnom okruženju, (Elaarag [2002]). Puni nazivi navedenih kratica

objašnjeni su na kraju rada.

U slučaju gubitaka i velike učestalosti pogrešaka u mreži protokol TCP radi kao i u žičnom

okruženju i tu je izvor problema za rad u bežičnom okruženju. Smanjenjem prozora zagušenja

kao odgovor na nepostojeće zagušenje znatno se smanjuje propusnost i povećava kašnjenje u

WLAN-u. Uzrok navedenih problema je u nestabilnosti bežičnog linka (engl. wireless link) na

kojem nastaju i najveći gubici koji nisu uvijek zbog zagušenja nego, npr. zbog fadinga

(iznenadni propadi snage signala), prekida veze, interferencija s drugim elektromagnetskim

izvorima, višestaznog rasprostiranja signala (engl. multipath propagation), ograničenosti

kapaciteta ćelije itd.

8

Sl. 1-5 Rješenja problema protokola TCP u bežičnim lokalnim mrežama

U suštini postoje dva osnovna pristupa u rješavanju problematike TCP-a u WLAN-u:

• Sakriti od pošiljatelja sve gubitke koji nisu posljedica zagušenja. U tom slučaju nema

promjena u implementaciji mrežne infrastrukture, te

• pokušati ukazati pošiljatelju da je prisutan bežični link na putu do odredišta i tako

smanjiti gubitke u mreži.

Jedno od rješenja iz prve skupine prikazano je u nastavku rada, a to je protokol TCP-snoop.

Usporedbom protokola TCP-snoop s ostalim rješenjima, a misli se na rješenja s kraja na kraj i

rješenja zasnovana na razdvajanju konekcije uočava se da jedino snoop ne napušta osnovnu

funkcionalnost djelovanja protokola TCP. Na primjer za slučaj pristupa razdvajanjem

konekcije ''krši'' se rad protokola TCP s potvrdnim segmentima. Takav pristup bitno utječe na

period potreban za obnavljanje veze prilikom promjene pristupne točke. Za protokol TCP-

snoop to vrijeme se kreće od 5 do 70 ms dok je kod protokola I-TCP to vrijeme čak 1400 ms

ovisno o količini podataka koje je potrebno prenijeti na novu pristupnu točku. Prilikom

prelaženja cilj je što više skratiti vrijeme neaktivnosti TCP konekcije (engl. idle time).

9

2. Protokol TCP-snoop

Za svaki gubitak segmenta protokol TCP smatra da je posljedica zagušenja što u bežičnim

mrežama (WLAN) nije uvijek slučaj kao što je ranije opisano. Protokol TCP-snoop svoje

djelovanje izvodi na razini linka i jedna od njegovih bitnih prednosti su minimalne promjene

u pristupnoj točki. TCP-snoop spada u kategoriju koje podižu performanse mreže koristeći

metodu proxy-ja - PEP (engl. Performance Enhancing Proxy). (Ho Ng et al [1997]).

Djelovanjem ispod transportnog sloja izvodi se lokalna retransmisija (ili ponovno odašiljanje)

izgubljenih segmenata bez pokretanja TCP mehanizama za kontrolu zagušenja.

Ostale metode koje se koriste za prilagodbu TCP-a bežičnom okruženju pripadaju u neku od

sljedeće tri grupe :

• Rješenja s kraja na kraj (engl. End to End) ;

• rješenja na razini linka (engl. Link Layer), te

• rješenja zasnovana na razdvajanju konekcije (engl. Spliting Connection).

Ideja TCP-snoop-a je u tome da se sakriju od pošiljatelja svi gubici nastali na sloju linka. Na

taj način TCP pošiljatelj ne zna za pogreške na bežičnom linku pa tako nema i bespotrebnog

pokretanja mehanizama za kontrolu zagušenja. Sve to dovodi do postizanja zadovoljavajuće

razine propusnosti za korisnika. U radu je detaljno opisan protokol snoop te izvedena

simulacija istog u programskom jeziku Java. Bitno je naglasiti da je implementirana tzv.

osnovna inačica protokola TCP-snoop (engl. Basic TCP-snoop).

Implementacija protokola izvodi se uvođenjem modula snoop modula u pristupnu točku (engl.

Access Point-AP). Naglasak je na promatranju infrastrukturnog WLAN-a u centraliziranom

pristupu. To znači da se sva komunikacija između žične i bežične domene odvija preko

pristupne točke, a izravna komunikacija između pokretnih čvorova (engl. wireless hosts) nije

moguća. Slika (Sl. 2-1) prikazuje infrastrukturni WLAN s implementacijom snoop modula u

pristupnoj točki.

Sl. 2-1 Mrežna topologija

10

Snoop modul nadgleda sve segmente koji prolaze TCP konekcijom u oba smjera, te u

spremniku ima pohranjene sve TCP segmente od strane pošiljatelja koji još nisu potvrđeni od

strane primatelja. Ukoliko nastanu gubici tada snoop izvodi lokalnu retransmisiju izgubljenih

segmenata a da to pošiljatelj ne zna.

Snoop modul radi na principu spremi i proslijedi (engl. store and forward) bez unošenja

protokolnog preteka (engl. overhead) koji bi dodatno smanjio propusnost mreže. Kratka

analiza protokola TCP uzeta je u razmatranje zato jer se protokol snoop direktno ''naslanja'' na

njega. Sama implementacija izvedena je negdje između mrežnog i transportnog sloja. Bez

zadiranja u rad protokola TCP. Nove funkcionalnosti se dodaju u pristupnu točku (snoop

modul) i to vezano uz mrežni sloj pristupne točke te male promjene kod mobilnog klijenta.

Prednosti ovakvog pristupa posebno dolaze do izražaja u slučaju prelaženja mobilnog

korisnika (engl. handoff), tj. prelaska u susjednu ćeliju ili drugim riječima promjena pristupne

točke. Tada nastaju veliki gubici, povećanje kašnjenja i smanjenje propusnosti. Taj problem

se rješava grupiranjem trenutne pristupne točke korisnika i susjednih AP-a u multicast

skupinu. U svakoj od stanica multicast skupine pokreće se snoop agent tako da nova pristupna

točka u trenutku prebacivanja već ima kopije izgubljenih segmenata. Problem se javlja u

slučaju kada nova pristupna točka nije član multicast skupine pa je dio segmenata izgubljen za

vrijeme prelaženja. Jedina modifikacija protokolnog složaja je u mijenjanju mrežnog sloja u

pristupnoj točki. Snoop ''motri'' sve segmente koji prolaze kroz pristupnu točku u oba smjera

te radi potrebno pohranjivanje u spremnik. Kada novi segment stigne u pristupnu točku od

strane žičnog čvora snoop ga dodaje u spremnik te ga prosljeđuje kroz bežični kanal do

pokretnog čvora. Nadalje, snoop nadzire i sve potvrde, ACKs (engl. Acknowledgements)

poslane od primatelja (Balakrishnan et al. [1995]).

U slučaju gubitka segmenta u bežičnom kanalu što se otkriva istekom lokalnog brojača (engl.

local timeout) i dupliciranih potvrda (Sl. 2-2) radi se ponovno slanje izgubljenih segmenata.

Na taj način pristupna točka ''skriva'' gubitke segmenata od pošiljatelja te nema pokretanja

mehanizama za izbjegavanje zagušenja karakterističnih za protokol TCP.

Tablica (Tablica 2) prikazuje poboljšanja koja TCP-snoop donosi za problem handoff-a,

(Balakrishnan et al. [1995]). Bitno je uočiti da se unatoč učestalim promjenama pristupne

točke vrijednost propusnosti bitno ne mijenja, što ne bi bio slučaj za protokol TCP bez snoop

modula.

11

1

2

3

4

2

4

3

5

5

Pošiljatelj Primatelj

Prvo slanje

ack1

ack1

ack1

ack1

Duplicirane potvrde iponovno slanje

Sl. 2-2 Otkrivanje gubitka segmenta

Snoop održava visoku razinu propusnosti koja nije sklona naglim propadima. Nadalje,

poboljšanje protokola TCP-snoop u slučaju male učestalosti pogrešaka nije toliko izraženo.

Drugim riječima, uvođenje snoop modula svu svoju efikasnost pokazuje u uvjetima visoke

učestalosti pogrešaka bita - BER.

Tablica 2 Ovisnost propusnosti o vremenu prelaženja

Vrijeme potrebno za

handoff [s]

Propusnost [Mbit/s]

1 1.42

3 1.43

8 1.44

10 1.43

Razlog promjena u mrežnom sloju pristupne točke leži u činjenici da je to jedino mjesto u

WLAN-u gdje korisnik može imati potpunu kontrolu u radu protokola za usmjeravanje paketa

između žične i bežične mreže. U samoj pristupnoj točki mehanizmi transportnog sloja se ne

pokreću. Originalna zamisao rada snoop modula uključuje promjene i kod ostalih mrežnih

elemenata kao što su pokretni i stacionarni čvor. To se radi za slučaj slanja podataka od strane

pokretnog čvora, opisano u radu (Balakrishnan et al. [1995]). Međutim, zbog nedostatka opisa

istog u literaturi u ovom radu to neće biti razmatrano. Sam rad protokola TCP-snoop vezan je

uz dvije metode:

12

• snoopData(). Metoda vezana uz obradu podatkovnih segmenata namijenjenih pokretnom

čvoru kao i za njihovo pohranjivanje u spremnik.

• snoopAck(). Metoda radi obradu potvrdnih segmenata (ACKs) koji putuju prema

stacionarnom čvoru i upravlja ponovnim slanjem izgubljenih segmenata prema

pokretnom čvoru kroz bežični kanal.

2.1. Metoda SnoopData()

Pojednostavljeni pseudokod ove metode prikazan je u nastavku:

ako (novi segment i u rastućem slijedu) {

stavi segment u spremnik;

proslijedi segment na odredište;

} inače ako (segment nije u slijedu a u spremniku postoji isti) {

ako (redni broj segmenta < rednog broja potvrde) {

proslijedi segment na odredište;

} inače {

ponovno pošalji segment;

}

} inače ako (segment nije u rastućem slijedu i u spremniku ne postoji isti) {

proslijedi segment prema pokretnom čvoru;

}

Postoje tri slučaja:

• Segment je u rastućem slijedu (novi segment). Segment se dodaje u spremnik te

prosljeđuje u bežični kanal. Opcionalno se dodaje vremenska oznaka (engl. timestamp) na

neki od segmenata unutar prozora.

• Segment nije u slijedu, tj. isti postoji pohranjen u spremniku. Ovaj slučaj je rijedak a

nastupa zbog isteka brojača na strani pošiljatelja ili u slučaju ubrzanog ponovnog slanja.

Postoje dva podslučaja:

o Redni broj segmenta < broja potvrde. Može nastupiti zbog gubitka prethodne

potvrde a rješava se prosljeđivanjem segmenta.

13

o Redni broj segmenta ≥ broja potvrde. Nastupa zbog gubitka segmenta između

pristupne točke i pokretnog čvora. Segment se prosljeđuje prema pokretnom

čvoru a retransmisija je posljedica isteka vremenskog brojača.

• Segment nije u slijedu i u spremniku ne postoji kao pohranjeni segment. U ovom slučaju

segment je izgubljen u žičnom dijelu mreže ili je isporučen u pogrešnom redoslijedu.

Segment se prosljeđuje prema pokretnom čvoru i označava se kao ponovno poslani.

2.2. Metoda SnoopAck()

Po potrebi ova metoda odbacuje pozitivno potvrđene segmente (ACK) i osvježava potvrdu

RTT-a. Pseudokod metode:

ako (nova potvrda) {

briši potvrđene segmente iz spremnika;

osvježi RTT;

proslijedi potvrdu prema stacionarnom čvoru;

} inače ako (spontana potvrda) {

odbaci tu potvrdu;

} inače ako (dvostruka potvrda) {

ako (segment nije u spremniku, izgubljen u žičnom dijelu mreže )

proslijedi potvrdu prema stacionarnom čvoru;

inače ako (neočekivana duplicirana potvrda)

ponovno pošalji segment uz najviši prioritet;

inače ako (očekivana duplicirana potvrda, AP zna da je segment izgubljen)

odbaci potvrdu;

}

Kao i za prethodnu metodu i ovdje postoje tri slučaja:

• Nova potvrda – ACK. Uobičajeni slučaj, brišu se potvrđeni segmenti iz spremnika,

osvježava se procjena RTT-a i prosljeđuje potvrda prema stacionarnom čvoru.

14

• Spontani (engl. spurious) ACK. Kada neočekivano stigne već viđena potvrda od strane

stacionarnog čvora. Ovaj slučaj je vrlo rijetko nastupa. Odgovor na ovakvo stanje je da se

takva potvrda odbacuje.

• Dvostruki ACK segment (DUPACK). Slučaj kada pristigne potvrda identična onoj

primljenoj prethodno. Opet postoji nekoliko podslučaja:

o Kada segment nije u spremniku iz razloga što je izgubljen na putu između

stacionarnog čvora i pristupne točke. Takva potvrda se jednostavno prosljeđuje

prema stacionarnom čvoru radi očuvanja stanja TCP-a.

o Neočekivani DUPACK nakon što je segment izgubljen. Odgovor na ovo stanje

je ponovno slanje segmenta u najviši prioritet. Za ovaj slučaj potrebna su dva

reda za slanje, jedan za segmente višeg a drugi za segmente nižeg prioriteta.

Nadalje snoop vodi računa i o maksimalnom broju dupliciranih potvrda za

segment.

o Očekivani DUPACK, koji stiže nakon što pristupna točka sazna da je segment

izgubljen. Takva potvrda se u pravilu odbacuje.

Slanje segmenata s višim prioritetom donosi poboljšanju performansi mreže u uvjetima

visokih pogrešaka bita. Na taj se način omogućuje da ponovno poslani segmenti stignu do

pokretnog čvora u što kraćem vremenu čime se smanjuje broj dupliciranih potvrda te tako

povećava propusnost mreže. Snoop vodi evidenciju o broju lokalnih retransmisija za svaki

segment i resetira brojač u slučaju da neki segment stigne ponovno od pošiljatelja uslijed

isteka brojača na pošiljateljovoj strani ili uslijed ubrzanog ponovnog slanja. Kao što je ranije

rečeno snoop radi i lokalnu retransmisiju za istek lokalnog brojača.

Za slučaj transfera podataka od pokretnog čvora prema stacionarnom, uvode se negativne

potvrde, (NACK) za traženje segmenata koji nedostaju. To se radi u slučaju isteka vremenske

kontrole kod pristupne točke i kada je primljen određeni broj segmenata. U ovom radu

naglasak je na proučavanju rada protokola TCP za smjer prema pokretnom čvoru (engl.

downlink) iz razloga što je za bežične mreže karakteristična asimetrija u prijemu podataka.

Drugim riječima prema klijentu se šalje puno veća količina podataka nego u odlaznom smjeru

prema poslužitelju. Podaci koji se šalju prema poslužitelju uglavnom su vezani uz zahtjeve

određenih resursa sa poslužitelja koji sadrže male količine podataka.

15

2.3. Odnos protokol TCP-snoop - protokol usmjeravanja

Kao što je ranije opisano princip rada protokola TCP-snoop temelji se na pohranjivanju

nepotvrđenih segmenata da bi se poboljšale performanse s kraja na kraj. U pravilu veličina

spremnika s pohranjenim segmentima proporcionalna je veličini klizećeg prozora na strani

primatelja. U nastavku je malo šire opisano ponašanje protokola TCP-snoop za slučaj

prelaženja koje je i ranije dijelom opisano ali u puno manjem opsegu. Pri promjeni pristupne

točke nova pristupna točka mora preuzeti sve nepotvrđene segmente od stare pristupne točke

kako bi se mogla izvršiti lokalna retransmisija. Kada pristupna točka primi zahtjev za

prelaženjem sadržan u poruci beacon, pridružuje se multicast skupini na ranije opisani način.

Nova pristupna točka prima sve segmente namijenjene toj multicast skupini i snoop modul

osvježava informaciju o novim TCP konekcijama u pristupnoj točki. Na taj način snoop

modul gradi novi spremnik s informacijama o svim aktivnim TCP konekcijama.

Kada nastupi prelaženje, pozitivno potvrđeni segmenti počinju prolaziti kroz novu pristupnu

točku. Prvi primljeni potvrdni segment određuje koji su segmenti primljeni na strani

pokretnog čvora do tog trenutka za tu TCP konekciju. Ova informacija služi za ažuriranje

stanja snoop modula i čišćenje spremnika u pristupnoj točki. U stvarnosti, stanje prije i nakon

navedene sinkronizacije nije nikada identično. Razlog tome leži u činjenici da nova pristupna

točka može imati vlastiti spremnik s nekoliko segmenata koji su izgubljeni tijekom samog

prelaženja. Upravo u ovom dijelu do izražaja dolazi sva snaga i robustnost protokola TCP-

snoop. Naime, kako snoop održava semantiku TCP konekcije s kraja na kraj i sakriva gubitke

od pošiljatelja ti se segmenti neće ponovno slati nego će se jednostavno ignorirati ili u slučaju

većih gubitaka zatražiti od prijašnje pristupne točke. U najgorem slučaju ovi segmenti će

uzrokovati kratki i neznatni pad mrežnih performansi koji se i ionako očekuje tijekom

postupka prelaženja. Praktična mjerenja pokazala su da je potrebno svega nekoliko

novoposlanih segmenata da bi snoop modul u novoj pristupnoj točki obnovio informaciju o

novonastalom stanju. Upravo zbog ranije opisanog načina nema uobičajenog preuzimanja

cjelokupnog stanja o TCP konekciji nego se radi nadziranje stanja stare pristupne točke od

strane nove pristupne točke i tako se postupak prelaženja skraćuje i rješava puno efikasnije.

Slika (Sl. 2-3) prikazuje klasičan način prelaženja.

16

segm1

beacon

forward request

segm3

segm4

stronger beacon

segm2

buffer request

segm5

Pristupna točka 1 Pokretni čvor Pristupna točka 2

handoffperiod

Sl. 2-3 Prikaz izmijenjenih poruka za vrijeme postupka prelaženja

2.4. Alternativna rješenja na sloju linka

Radi same usporedbe ukratko je i opisano rješenje pod nazivom AIRMAIL (engl. AsymmetrIc

Reliable Mobile Access In Link-layer). Dvije osnovne metode koje AIRMAIL kombinira su

ranije spomenuti ARQ i FEC (engl. Forward Error Correction). Bitno je naglasiti da

AIRMAIL djeluje dobro ne samo u zatvorenim prostorima nego i u otvorenim (vanjskim)

širokopojasnim bežičnim sustavima kao što je WiMAX, standard IEEE 802.16a ili drugim

riječima WMAN. Asimetrija proizlazi iz činjenice da pokretni čvorovi imaju puno manju

snagu i slabiju mogućnost obrade podataka nego što to imaju bazne stanice (engl. Base

Stations) te da odluku o slanju i primanju paketa donosi bazna stanica. Iz tog razloga težnja je

u ''postavljanju'' što više inteligencije u samu baznu stanicu te da se u pokretnim čvorovima

procesiranja svedu na minimum. Naglasak je u optimalnom iskorištenju prijenosnog pojasa

(engl. bandwith) od strane bazne stanice bez pokretanja nepotrebnih retransmisija te očuvanju

napajanja pokretnog čvora pomoću statusnih poruka izmijenjenih s baznom stanicom. FEC

kao tehnika ispravljanja grešaka kombinira se na razini bita, okteta i paketa. Kombinacija

navedenih triju razina provodi se kao ''kodiranje kanala'' (engl. channel coding) i to pomoću

adaptivnog algoritma temeljenog na automatu s konačnim brojem stanja opisanim u

(Ayanoglu et al. [1994]). Slika (Sl. 2-4) prikazuje tipično ustrojstvo bežične mreže zasnovane

na ćelijskom principu i pokrivanju radio signalom kao što je IEEE 802.16.

U nastavku je ukratko opisano djelovanje protokola AIRMAIL i to za sve smjerove

komunikacije.

17

2.4.1. Smjer predajnik pokretnog čvora – prijemnik bazne stanice

Kontrola toka i slijed zahtijeva provodi se kroz nekoliko koraka:

• Pokretni čvor šalje podatke sve dok se ne dosegne maksimalna veličina spremnika za

slanje (engl. maximum transmit buffer size) koja se računa na osnovu mjerenja RTT-a,

zahtijeva za ponovnim slanjem te dali ima još podataka za slanje. Paketi koji čekaju na

ponovno slanje imaju viši prioritet od ostalih. Kada pokretni čvor više nema paketa za

slanje on postavlja tzv. e-bit u zaglavlje zadnje poslanog paketa.

• Bazna stanica šalje poruke o svome stanju (engl. status messages) periodički kroz bežični

kanal. Te poruke ne nose informaciju o veličini spremnika za slanje kao što je to slučaj u

nekim drugim protokolima. Pomoću vremenskog brojača stanja (engl. status timer) koji

se pokreće prilikom slanja poruke stanja određuje se gubitak paketa u bežičnom kanalu.

Vremenski brojač nalazi se samo na strani bazne stanice. U slučaju da primljeni paket

sadrži e-bit brojač se ne pokreće nego bazna stanica odmah šalje poruku o stanju.

• Pokretni čvor ponovno šalje pakete koji čekaju na retransmisiju prije slanja ostalih

paketa. Za ovaj korak bitno je reći da da je veličina spremnika za slanje kod pokretnog

čvora veća nego veličina ''prozora'' kod bazne stanice i tako se rješavaju problemi vezani

uz gubitak statusnih poruka prema pokretnom čvoru.

Ova činjenica bitno utječe na propusnost koja je ovom slučaju definirana kao broj paketa koji

se prenesu za vrijeme trajanja RTT-a. Ovaj korak je najsloženiji te opis pojedinih detalja nije

naveden iz razloga prelaska granica tematike samog rada.

2.4.2. Smjer predajnik bazne stanice – prijemnik pokretnog čvora

• Bazna stanica šalje nove pakete u slučaju da je veličina prozora različita od nule, sve dok

dolaze zahtjevi za ponovnim slanjem te sve dok ne ponestane paketa za slanje. Kao i za

slučaj slanja pokretnog čvora ukoliko nema više paketa za slanje šalje se e-bit na način

opisan ranije. Vremenski brojač se pokreće nakon slanja cijelog bloka paketa ili nakon

slanja paketa s e-bitom. Uz to šalje se i eksplicitni zahtjev za statusom (engl. Explicit

status request message) ukoliko bazna stanica ne primi poruku od pokretnog čvora prije

isteka vremenskog brojača. Pod pojmom bloka smatra se fiksni broja paketa određen

samim algoritmom AIRMAIL-a.

18

Sl. 2-4 Ćelijska organizacija mrežne infrastrukture

• Pokretni čvor šalje poruku o statusu nakon što primi cijeli blok paketa. Na primjer biti

pokazuje dali je paketi unutar bloka ispravno primljen. Biti = 1 znači da je paket i

primljen a biti = 0 znači da nije primljen. Radi uštede predajne snage pokretni čvor ne

šalje poruke o statusu periodički kako to radi bazna stanica, isto tako ih ne šalje ni nakon

prijema svakog paketa. Poruke o statusu šalje samo nakon prijema cijelog bloka paketa ili

nakon prijema e-bita.

• Slučaj kada bazna stanica ponovno šalje tražene pakete. Bitna činjenica je da se šalju

samo izgubljeni paketi unutar bloka a ne cijeli blok i tako se štedi na širini prijenosnog

pojasa. Nadalje, bazna stanica također i pokreće vremenski brojač radi otkrivanja dali je

pokretni čvor poslao poruku o statusu koja potvrđuje prijenos bloka paketa u nekom

vremenu intervalu određenim brojačem. Ukoliko poruka o statusu ne stigne prije isteka

brojača, bazna stanica šalje šalje eksplicitni zahtjev za statusom. Ukoliko ni nakon

nekoliko slanja eksplicitnih poruka o statusu odgovor ne stigne bazna stanica raskida

konekciju ili postavlja vezu u stanje hibernacije

Pouzdanost protokola temelji se na uštedi resursa i principu ponovnog slanja izgubljenih

paketa. Odluka o prisutnosti pogrešaka unutar paketa temelji se na dobro poznatom

mehanizmu CRC (engl. Cyclic Redudancy Check). Optimizacijom koda koji se dodaje na

pakete može se smanjiti broj retransmisija te ispraviti pogreške. Za stvarnovremenske

aplikacije kao što su audio i video mehanizam retransmisije nije dobar jer unosi prevelika

kašnjenja. U tom slučaju rabi se FEC koji osigurava dobar QoS. Dobrim podešavanjem

19

parametara FEC-a iskoristivost kanala raste kao što se i smanjuje kašnjenje tijekom promjene

bazne stanice. AIRMAIL je kao i snoop još jedna od inačica protokola za poboljšanje TCP-a

u bežičnom okruženju. Svoje djelovanje temelji na retransmisijama i uštedi prijenosnog

pojasa na razini sloja linka, bez zadiranja u transportni sloj. Međutim za promatranu

problematiku vezanu uz TCP u WLAN-u snoop daje puno bolje rezultate, osobito za

propusnost, nego AIRMAIL. Međutim za slučaj WMAN-ova AIRMAIL je jedno od najboljih

rješenja.

Prednost rješenja s retransmisijom na sloju linka su u tome da je rješenje nevidljivo od sloja

IP na više, te da protokol TCP zadržava svoj značaj s kraja na kraj. Neki od nedostataka koji

se pojavljuju su: problemi ukoliko TCP i protokol sloja linka rade retransmisiju istovremeno,

pojava promijene redoslijeda segmenata, uslijed velikih kašnjenja i kolebanja kašnjenja (engl.

jitter), problemi vezani uz duže periode prekida konekcije te problemi tzv. uskog grla

pristupne točke (engl. bottleneck) ili drugim riječima problem višestrukih TCP konekcija

između dvaju domena (Jang et al. [2003]). Još je bitno naglasiti da protokol sloja linka koristi

''poznavanje'' rada protokola TCP kako bi se gubici sakrili od pošiljatelja. Treba naglasiti da je

ovdje više naglasak na održavanju iznosa propusnosti konstantnim s obzirom na

karakteristiku bežičnog kanala.

20

3. Rezultati simulacije i opis programa

Za potrebe diplomskog rada razvijen je simulator protokola TCP-snoop – ''TCP Snoop

Simulator''. Simulator je izveden u programskom jeziku Java radi objektne orijentiranosti

samog jezika i mogućnosti realizacije pojedinih komponenata mrežne topologije. Cilj

diplomskog zadatke bio je pokazati poboljšanja koje unosi integracija snoop modula u

pristupnu točku u WLAN-u na neke od osnovnih komponenti protokola TCP kao što su

veličina prozora zagušenja, broj poslanih segmenata u jedinici vremena, propusnost, itd.

Komponente mrežne topologije sa slike (Sl. 2-1) implementirane su kao klase u simulatoru.

3.1. Model rješenja simulatora

Slika (Sl. 3-1) daje prikaz grafičkog sučelja prema korisniku – GUI (engl. Graphical User

Interface).

Sl. 3-1 Korisničko grafičko sučelje

21

Kao što je vidljivo sa slike (Sl. 3-1) grafičko sučelje sastoji se od nekoliko dijelova:

• Simulation Log. U ovom prozoru se pri početku i završetku simulacije ispisuje datoteka

log.txt koja opisuje tijek simulacije i bitne događaje vezane uz simulaciju (npr. da li je

uspostavljena konekcija između komunicirajućih entiteta, broj poslanih i izgubljenih

segmenata i sl.).

• Result options. Prikaz rezultat je dan kao funkcija vremena. Postoji mogućnost biranja

prikaza veličine prozora zagušenja, rednih brojeva segmenata te propusnosti sve u

ovisnosti o trenutku simulacije. Nadalje, u ovom dijelu je dio vezan za aktivaciju snoop

modula u pristupnoj točki kao poboljšanja u radu protokola TCP u bežičnom okruženju.

Naposlijetku, postoji mogućnost provedbe paralelne simulacije za razne algoritme i

mogućnost usporedbe rezultata na istom grafu. Ovdje je bitno za reći da se svi rezultati

ispisuju u tekstualnu datoteku u stupčastom obliku upravo radi lakše obrade rezultata. Za

prikaz rezultata može se uzeti bilo koji alat za iscrtavanje grafova kao što je Microsoft

Excel ili besplatni program Gnuplot te je taj dio ostavljen korisniku na izbor.

• Channel options. Dio predviđen za podešavanje karakteristika bežičnog kanala kao što je

model kanala, vrijeme propagacije kroz bežični kanal, vjerojatnost gubitaka segmenata.

• Server options. Najbitniji dio simulatora u kojem se unose parametri ključni za

simulaciju, odnosno rad protokola TCP. Implementirana su 2 mehanizma protokola TCP,

i to Tahoe i Reno.

Rad simulatora predstavljen je kroz vremenske cikluse. U jednom vremenskom ciklusu klijent

i pristupna točka mogu primiti, obraditi te poslati samo jedan TCP segment. Svi TCP

segmenti koji se izmjenjuju između entiteta postavljeni su na korisnički zadanu vrijednost

MSS i kao takvi se šalju.

3.2. Parametri simulacije i komponente simulatora

Za izvođenje simulacije korištene su sljedeće vrijednosti TCP parametara:

• MSS je postavljen na 40 okteta;

• sstresh ima vrijednost 65536 okteta;

• vrijeme propagacije segmenata bežičnim kanalom iznosi 100 ms;

• veličina datoteke koja se prenosi je 1600 okteta;

• vrijeme propagacije segmenata po žičnom linku postavljeno je na 10 ms i pretpostavka je

da gubici segmenata na žičnom linku nisu mogući (engl. error free link).

22

Unutar simulatora sam žični link nije implementiran kao klasa nego se simulira na način da se

slanje svakog segmenta odgađa za period vremena od 10 ms. Tako se opisuje propagacija

žičnim linkom na putu do pristupne točke. Što se bežičnog kanala tiče, u simulatoru postoji

mogućnost biranja razdiobe gubitaka između tzv. Fritchmanovog modela kanala i uniformne

razdiobe gubitaka segmenata u bežičnom kanalu, (Kralj [2003]). Sve simulacije izvedene u

radu odnose se na Fritchmanov model kanala koji je ukratko opisan u nastavku rada i

predstavlja poopćeni Gilbertov model bežičnog kanala s gubicima. Slučaj s uniformnom

razdiobom ne preporučuje se za simulacije s aktivnim snoop modulom jer daje izrazito loše

rezultate i implementiran je u simulatoru samo radi usporedbe. Maksimalna veličina prozora

zagušenja i kod pošiljatelja i kod primatelja iznosi 65536 okteta. Također, definira se i

maksimalni broj retransmisija, nakon kojega se konekcija između entiteta raskida i ispisuje

poruka o isteku vremenske kontrole.

Simulator se sastoji od nekoliko komponenti a to su:

• Klijent – pokretni čvor. Rad klijenta zasniva se na dobro poznatim mehanizmima rada

protokola TCP. Za svaki primljeni segment od strane pošiljatelja šalje potvrdni segment s

rednim brojem segmenta kojeg sljedećeg očekuje. Prilikom ponovnog slanja segmenta ne

računa se RTT (koristi se pojednostavljeni mehanizam retransmisije) i to samo za

segmente koji iniciraju (SYN) odnosno raskidaju konekciju (FIN), (Kralj [2003]).

• Bežični kanal s gubicima. Implementiran kao zasebna klasa u Javi te povezuje klijenta s

poslužiteljem, odnosno s pristupnom točkom. Model kanala i način funkcioniranja opisan

je u nastavku rada.

• Pristupna točka. Bitna komponenta simulatora jer obavlja funkciju mosta (engl. bridge)

između dvaju domena. Za vrijeme uspostave konekcije između klijenta i poslužitelja

pristupna točka je transparentna ili drugim riječima svoju funkciju počinje obavljati tek

kod slanja podatkovnih segmenata i aktivnog snoop modula. Svi segmenti poslani od

poslužitelja kao i potvrdni segmenti, poslani od klijenta, prolaze kroz tu komponentu.

Nadalje, upravo je u pristupnoj točki implementiran snoop modul koji pohranjuje potvrde

i segmente lokalno u spremnik. Također, u slučaju aktivnog snoop modula računa se

vrijednost lokalnog vremenskog brojača za slučaj lokalne retransmisije. U originalnom

modelu protokola TCP-snoop uvode se prioriteti za pakete koji čekaju na ponovno slanje

u spremniku pristupne točke. Navedeni prioriteti za ponovno slanje paketa nisu

razmatrani u ovom radu.

23

• Poslužitelj – stacionarni čvor. Ima ulogu pošiljatelja i svi mehanizmi bitni za rad

protokola TCP, kao što su algoritmi kontrole zagušenja, dinamičko računanje

vremenskog brojača implementirani su upravo u ovoj komponenti.

• TCP segment. Pojednostavljeni model TCP segmenta bez dodatnih zaglavlja, preuzet iz

rada (Kralj [2003]). Slika (Sl. 3-2) prikazuje strukturu TCP segmenta korištenog u

simulaciji. Polje ‘’Duljina segmenta’’ odnosi se na podatkovni dio TCP segmenta i to u

oktetima. Prilikom prijema segmenta, dotični se odmah obrađuje bez pohranjivanja u

spremnik, osim u slučaju aktivnog snoop modula.

• Engine simulatora. Jedina klasa s main metodom. Kreira grafičko sučelje prema

korisniku, određuje razmještaj komponenti unutar grafičkog sučelja, omogućuje unos

korisničkih parametara za pojedine metode unutar simulatora te ispis bitnih događaja

vezanih uz simulaciju. Navedeno ne znači da se kompletan tijek simulacije ispisuje

unutar grafičkog sučelja, za to služi konzola (engl. console) unutar samog Java razvojnog

okruženja.

Sl. 3-2 TCP segment implementiran u simulatoru

3.2.1. Fritchmanov model bežičnog kanala s gubicima

Navedeni model opisuje se kao Markovljev lanac prvog reda s dva stanja, (Pan et al. [2000]).

Svako od dva stanja odgovara stanju bežičnog kanala na putu između pošiljatelja i primatelja,

odnosno između pristupne točke i bežičnog klijenta. Markovljev lanac ima stanja ON i OFF.

Dok je bežični kanal u stanju ON svi segmenti se ispravno prenose do bežičnog klijenta, a u

slučaju stanju OFF svi poslani segmenti su izgubljeni u kanalu. Gubici koji nastaju u

bežičnom kanalu su usnopljeni, što znači da se na segmente gleda kao na uzastopni niz koji

tvori jedinstveni tok podataka. Za Fritchmanov model bitno je reći da su gubici u dolaznom i

odlaznom smjeru (engl. uplink) u potpunosti neovisni te da je prijelaz iz jednog stanja u drugo

moguć samo na razini cijelog segmenta odnosno na kraju vremenskog odsječka. Ovaj podatak

vezan je uz polje unutar simulatora ''Average Loss Length'' koje predstavlja duljinu snopa

gubitaka kao broj vremenskih odsječaka.

24

Prosječna vremena zadržavanja u stanjima opisana su varijablama Ton i Toff te se ravnaju po

geometrijskoj razdiobi. Za slučaj da je u slučajni broj između 0 i 1 i da je z vjerojatnost

napuštanja stanja, duljina zadržavanja x u jednom od stanja računa se kao:

xzu )1( −=

xzu )1log()log( −=

)1log()log( zxu −⋅=

)1log(

)log(

z

ux

−=

Prilikom pokretanja simulacije korisnik unosi vrijednost Toff i vjerojatnost pogreške Pb.

Varijabla Pb drugim riječima predstavlja stacionarnu vjerojatnost boravka bežičnog kanala u

stanju OFF. Vrijednost varijable Pb računa se na način:

offon

offb TT

TP

+=

Pošto je vjerojatnost Pb poznata iz navedenog izraza, lako je izračunati stacionarnu

vjerojatnost boravka u stanju ON, pomoću izraza:

bg PP −= 1

Bitno je još naglasiti da su uvjetima u kanalu izloženi ne samo segmenti nego i potvrde koje

klijent šalje poslužitelju. Uvjeti simulacije za slučaj kada je snoop modul aktivan u pristupnoj

točki i kada nije su isti upravo da bi se uočila poboljšanja koja unosi snoop modul na rad

protokola TCP u bežičnom okruženju. Ovdje je potrebno napomenuti da je problem

određivanja modela koji bi dobro opisivao bežični kanal poseban problem i opisan je s raznim

matematičkim modelima.

3.3. Rezultati simulacije

Za potrebe prikaza rezultata simulacije pokrenuto je nekoliko simulacijskih postupaka, te su u

radu prikazani ponajbolji dobiveni rezultati. Slika (Sl. 3-3) pregledno predočava poboljšanja

koje unosi aktivnost snoop modula u pristupnoj točki na veličinu prozora zagušenja. Jasno se

vidi poboljšanje vezano uz broj segmenata koje pošiljatelj može poslati u mrežu, a da ne mora

čekati prijem potvrdnog segmenta od strane primatelja. Poboljšanje je znatno jer u trenutku

oko 1500 milisekunde pošiljatelj može u slučaju aktivnog snoop modula poslati čak 70-ak

25

TCP segmenata, dok je u suprotnom slučaju taj broj nešto veći od 40 TCP segmenata.

Obzirom da veličina prozora zagušenja predstavlja na neki način trenutnu mjeru kapaciteta

mreže, navedeno poboljšanje dobiva još više na svome značaju. Kao što je vidljivo sa slike

(Sl. 3-3) nakon isteka vremenske kontrole započinje period sporog starta sve do perioda

izbjegavanja zagušenja. Trajanje vremena isteka vremenskog brojača isto je za slučaj bez

aktivnog snoop modula i s aktivnim snoop modulom. Može se uočiti da protokol TCP-snoop

''poznaje'' i ''slijedi'' mehanizme rada protokola TCP uz znatan porast ukupnih performansi

sustava. Još treba dodati da su sve simulacije i prikazani rezultati napravljeni za referentni

protokol Tahoe TCP zato što od svih inačica protokola TCP u WLAN-u pokazuje najlošije

rezultate.

0

500

1000

1500

2000

2500

3000

3500

0 500 1000 1500 2000 2500 3000 3500

Vrijeme [ms]

CW

ND

[okt

et]

Regular TCP TCP Snoop

Sl. 3-3 Tahoe TCP – veličina prozora zagušenja

Iz svega navedenog može se zaključiti da protokol TCP-snoop sprječava istek vremenskog

brojača na strani pošiljatelja i održava povećanu vrijednost veličine prozora zagušenja u

svakom vremenskom trenutku simulacije. Upravo su ova dva čimbenika ključna za

održavanje konstantne vrijednosti propusnosti, što osobito dolazi do izražaja za vrijeme

prelaženja između susjednih pristupnih točaka. U ovom radu propusnost je uzeta kao predmet

razmatranja vezana uz rad protokola TCP bez aktivnog snoop modula i to za protokole TCP

Tahoe i Reno radi usporedbe. Razlog za to je što problem prelaženja nije uzet u detaljnije

razmatranje, tj. nije predmet razmatranja diplomskog rada.

Obzirom da protokol TCP-snoop najbolje funkcionira u uvjetima učestalih pogrešaka,

poželjno je kod simulacije povećati vjerojatnost boravka bežičnog kanala u OFF stanju. U

simulaciji se ne razmatra BER, ali treba reći da je utjecaj snoop modula u slučaju malih iznosa

26

BER-a na performanse WLAN-a gotovo neznatan, čak i degradirajući, (Balakrishnan et al.

[1995]). Za primijetiti (Sl. 3-3) je da je poboljšanje vezano za veličinu prozora zagušenja u

simulaciji trenutno. U stvarnosti to nije slučaj zato što protokol TCP-snoop ima svojstvo spore

konvergencije na poboljšanje performansi unutar WLAN-a, te se smatra jednim od

nedostataka protokola.

Analizom simulacije utvrđeno je da je da u slučaju gubitaka većeg broja potvrda poslužitelj i

dalje nastavlja sa slanjem podatkovnih segmenata. Međutim, slučaj gubitka samo jednog

podatkovnog segmenta uslijed trenutnog stanja bežičnog kanala za posljedicu ima niz

retransmisija. Slika (Sl. 3-4) prikazuje ovisnost rednog broja segmenta (engl. sequence

number) o vremenu simulacije opet za dva slučaja, bez aktivnog snoop modula i s aktivnim

snoop modulom u pristupnoj točki. Uočava se nagli porast rednih brojeva poslanih TCP

segmenata oko trenutka t = 305 ms za slučaj aktivnog snoop modula što znači da pošiljatelj

''ne zna'' za gubitke u bežičnom kanalu i ne radi retransmisiju segmenata. Redni broj segmenta

računa se na način da je svaki sljedeći redni broj jednak zbroju maksimalne veličine segmenta

i prethodnog rednog broja TCP segmenta. Inicijalni redni broj prvog TCP segmenta koji se

šalje postavljen je na 1 radi boljeg prikaza pri iscrtavanju rezultata. U slučaju kada snoop

modul nije aktivan neki od segmenta s istim rednim brojem šalju se više puta, što znači da se

pokreću mehanizmi kontrole zagušenja koji izrazito degradiraju performanse WLAN-a. U

radu (Vangala [2002]) navedeni su podaci za ostale inačice protokola TCP, tako Tahoe, Reno,

New Reno pokazuju osjetno poboljšanje u broju poslanih segmenata u slučaju aktivnog snoop

modula dok najveće poboljšanja pokazuje TCP Vegas.

0200400600800

100012001400160018002000

0 1000 2000 3000 4000 5000 6000 7000 8000

Vrijeme [ms]

Red

ni b

roj s

egm

enta

[okt

et]

Regular TCP Snoop TCP

Sl. 3-4 Tahoe TCP – ovisnost rednog broja segmenta o vremenu simulacije

27

Zanimljivo je da protokol TCP SACK koji pokazuje najbolje rezultate bez prisutnosti snoop

modula, za slučaj njegove prisutnosti postaje najlošije rješenje za implementaciju u WLAN-u.

Slika (Sl. 3-5) predočava vrijednost veličine prozora zagušenja za slučaj kada se maksimalna

vrijednost lokalnog brojača u pristupnoj točki smanji. Uočava se manji broj TCP segmenata

koje pošiljatelj može poslati u mrežu, (Sl. 3-5). Način na koji se računa vrijednost lokalnog

brojača je dobro poznati Karnov algoritam, (Stevens [1995]). Princip određivanja vrijednosti

brojača opisan je slikom (Sl. 3-6). Isti se princip primjenjuje na poslužitelju kao i na

pošiljatelju i u pristupnoj točki. Ovaj pristup daje dobre rezutate i u uvjetima učestalih

pogreški što je karakteristično za bežični kanal. Ukratko, kada stigne potvrda za prvi sljedeći

segment koji nije ponovno poslan iznos vremenskog brojača računa se na način opisan slikom

(Sl. 3-6).

0

500

1000

1500

2000

2500

3000

0 500 1000 1500 2000 2500 3000 3500

Vrijeme [ms]

CW

ND

[ok

tet]

Regular TCP TCP Snoop

Sl. 3-5 Tahoe TCP – veličina prozora zagušenja

Kao što je ranije navedeno pristupna točka je transparentna za sve TCP segmente sve do

trenutka aktiviranja snoop modula. Razlog tome leži u pretpostavci da u žičnom dijelu mreže,

tj. na putu između poslužitelja i pristupne točke gubici nisu mogući. Također, pretpostavka je

da pristupna točka ne unosi dodatno kašnjenje ako snoop modul nije aktivan.

''Problem'' koji unosi snoop na rezultate simulacije je povećanje kašnjenja s kraja na kraj

(engl. end-to-end) uslijed spremanja segmenata u spremnik pristupne točke te uslijed

pretraživanja i usporedbe segmenta koji se obrađuje sa segmentima unutar spremnika. Bitno

je naglasiti problem proračuna vrijednosti lokalnog brojača na strani pristupne točke, koji se

često postavlja na fiksnu vrijednost, tako da su moguća i daljnja poboljšanja. U simulatoru je

pokušana realizacija s ugrađenom Java funkcijom random() koja bi računala vrijednost

28

vremenskog brojača u odnosu na neku maksimalnu vrijednost, međutim opisani postupak nije

se pokazao kao najbolji jer ne uzima u obzir vrijednost vremena propagacije TCP segmenta

kroz bežični kanal, ne sprječava istek vremenskog brojača na poslužitelju i ponekad daje

izrazito lošu razdiobu vrijednosti lokalnog brojača.

Sl. 3-6 Eksponencijalni backoff algoritam za proračun vremenskog brojača

Na slikama (Sl. 3-7, Sl. 3-8) dan je prikaz rezultata za jedan te isti simulacijski postupak, tj

analizirani su propusnost i veličinu prozora zagušenja za slučaj kada snoop modul nije

aktivan. Svi parametri simulacije ostaju isti za sve simulacijske postupke. Vrijednosti iznosa

propusnosti su apsolutne što znači da nemaju praktičnu vrijednost nego samo služe za prikaz

rezultata. Na grafu propusnosti uočava se da u pojedinim trenucima vrijednost propusnosti

pada na vrijednost nula.

0

1

2

3

4

5

6

0 2000 4000 6000 8000 10000

Vrijeme [ms]

Pro

pusn

ost

[se

gm

ent/m

s]

Sl. 3-7 Tahoe TCP – graf propusnosti na klijentskoj strani

Uzrok stanja propada iznosa propusnosti na vrijednost nula je u činjenici da za vrijeme dok se

čeka na istek vremenskog brojača podatkovni segmenti ne šalju ili je bežični kanal u stanju

OFF. To za klijenta u simulaciji znači da ne prima nikakve segmente jer su svi poslani

29

segmenti izgubljeni u bežičnom kanalu na putu do odredišta, npr trenuci simulacije od t = 790

ms do t = 2209 ms (Sl. 3-7). Nastavak slanja novih segmenata uvjetovan je stanjem u mreži i

na opisani način provodi se kontrola toka. Naime kako je ranije opisano i potvrdni segmenti

izloženi su gubicima u bežičnom kanalu, tada su svi segmenti koji se šalju izgubljeni i ovaj

slučaj u stvarnoj mreži nastupa samo kod izrazito izraženog fadinga odnosno iznenadnih i

snažnih propada radio signala.

0

50

100

150

200

250

300

0 2000 4000 6000 8000 10000

Vrijeme [ms]

CW

ND

[okt

et]

Sl. 3-8 Tahoe TCP – veličina prozora zagušenja

Slika (Sl. 3-9) prikazuje iznos propusnosti o vremenu uz napomenu da se razmatra protokol

TCP Reno i to samo radi usporedbe. Uočava se nešto bolja karakteristika grafa propusnosti

nego za slučaj Tahoe TCP. To se dešava zbog novog algoritma koji uvodi TCP Reno, a to je

algoritam ubrzanog oporavka (engl. fast recovery). Pomoću navedenog algoritma izbjegava se

period sporog starta nakon primitka 3 ponovljene potvrde koje bi ukazivale de je segment na

kojeg pokazuje potvrda izgubljen.

Umjesto sporog starta nastavlja se linearno izbjegavanje zagušenja. Tako se efikasnije koriste

mrežni resursi jer se ne troši vrijeme na čekanje isteka vremenske kontrole, a vrijednost

veličine prozora zagušenja ne smanjuje se na 1 segment nego na polovicu čime je omogućen

brzi oporavak veze nakon gubitaka pojedinačnih segmenata, (Stevens [1995]).

Na kraju rada valja spomenuti još jednu manjkavost protokola TCP-snoop, a to je slučaj kada

je na pristupnu točku vezan veći broj bežičnih klijenata. Osobito je to izraženo za slučaj

istovremenog slanja veće količine podataka poslužitelju (engl. upload) kada je snoop modul

aktivan.

30

0

1

2

3

4

5

6

7

8

0 1000 2000 3000 4000 5000 6000

Vrijeme [ms]

Pro

pusn

ost

[se

gm

ent/m

s]

Sl. 3-9 Reno TCP - graf propusnosti na klijentskoj strani

Tada se zauzima više prijenosnog pojasa (engl. bandwith) u bežičnom kanalu zbog

retransmisija segmenata i zauzeće medija od pojedinog klijenta se produžuje, (Ho Ng et al.

[1997]). Međutim, ovakav slučaj rijetko nastupa, a postoje i posebni programski alati i

protokoli koji omogućuju i ispravljaju navedeni nedostatak protokola TCP-snoop.

31

Zaključak

Protokol TCP kao temeljni transportni protokol neizbježan je u svijetu modernih

komunikacijskih tehnologija. Bežične mreže danas zauzimaju sve veći postotak kao

najprihvatljivije i najisplativije rješenje vezano uz prijenos informacije. Osobito to dolazi do

izražaja u uvjetima kada instalacija žične infrastrukture nije moguća ili neisplativa. Svakim

danom javljaju se novi IEEE 802.11x standardi vezani uz WLAN-ove koji sa sobom donose i

nove usluge za korisnika.

Današnji WLAN-ovi uglavnom se ostvaruju kao bežične mreže s radioprijenosom i koriste

tehniku proširenog spektra DSSS (engl. Direct Sequence Spread Spectrum) na fizičkom sloju.

Naravno, za pouzdani prijenos podataka koristi se protokol TCP, ali u raznim inačicama

opisanim u radu. Najbitnija prednost protokola TCP je u prilagodljivosti koju posjeduje za

različite prijenosne sustave. Međutim neki njegovi temeljni principi nisu prilagođeni za rad u

bežičnom okruženju. Razlog tome su veliki gubici koji nastaju u bežičnom kanalu. Upravo

zato uvode se poboljšanja namijenjena isključivo radu protokola TCP u WLAN-u. U radu je

detaljno opisana jedna od takvih inačica protokola TCP, a to je TCP-snoop. Analiza samog

protokola TCP-snoop napravljena je koristeći vlastiti simulator razvijen u programskom

jeziku Java. Upravo je taj protokol u raznim radovima naveden kao najprihvatljivije rješenje

za WLAN-ove, (Vangala et al. [2002]). Kada se kaže najprihvatljivije, onda se misli na

performanse i isplativost rješenja. Protokol Tahoe TCP bio je predmet promatranja u radu sa i

bez snoop modula u pristupnoj točki. Isti na gubitke reagira smanjenjem veličine prozora i

manjim brojem segmenata koje pošiljatelj može poslati u jedinici vremena. S obzirom da

protokol TCP-snoop djeluje ispod transportnog sloja on ne pokreće algoritme kontrole

zagušenja. Isto tako protokol TCP-snoop pripada skupini protokola koji dobro ''poznaju''

mehanizme rada protokola TCP. Osnovna zamisao rada protokola TCP-snoop je

pohranjivanje segmenata namijenjenih pokretnom čvoru i obavljanje lokalne retransmisije

segmenata izgubljenih u bežičnom kanalu.

Simulacije izvedene u radu pokazale su neka od poboljšanja koja protokol TCP-snoop unosi

u poboljšanje rada protokola TCP u bežičnoj okolini. Prvenstveno se ta poboljšanja odnose na

činjenicu da nema smanjenja veličine prozora zagušenja na strani pošiljatelja u slučaju

gubitka segmenata i na to da se od pošiljatelja ''sakriju'' gubici nastali u bežičnom kanalu.

32

Literatura

[1] BALAKRISHNAN, H. SESHAN, S. KATZ , H. R. 1995. Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks. ACM Wireless Communications Magazine, Vol. 1, Number 4.

[2] STEVENS, W.R. 1995. TCP/IP Illustrated: The protocols, Volume 1.Adisson Wesley Longman Inc.

[3] VANGALA, S. LABRADOR, A. M. 2002. Performance of TCP over Wireless Networks with the Snoop Protocol. In Proceedings of IEEE LCN, Tampa – Florida, pp. 600 – 601, November 2002.

[4] HO NG, C. CHOW, J. TRAJKOVIĆ, LJ. 2002. Performance Evaluation of TCP over WLAN 802.11 with the Snoop Performance Enhancing Proxy. OPNETWORK Conference 2002, Washington, DC, August 2002.

[5] XYLOMENOS, G. POLYZOS, G. SAARANEEN, M. 2001. TCP Performance Issues over Wireless Links.IEEE Communications Magazine, Volume 39, pp. 52 - 58.

[6] ELAARAG, H. 2002. Improving TCP Performance over Mobile Networks. ACM Computing Surveys, Vol. 34, pp. 357 – 374, November 2002.

[7] SCHILLER, J. 2003. Mobile Communications 2nd edition.Adisson Wesley Inc.

[8] JANG, H. SUH, Y. 2003. A Flow Control Scheme for Improving TCP Throughput and Fairness for Wireless Networks. Proceedings of IEEE Wireless Communications and Networking Conference (WCNC 2003), March 2003.

[9] PAN, J. MARK, W. J. and SHEN, X. 2000. TCP Performance and Its Improvement Over Wireless Links. GLOBECOM 2000 – IEEE Telecomunnications Conference no.1, San Francisco, pp. 62 – 66, November 27 – 30, 2000.

[10] BAŽANT, A. i dr. 2003. Osnovne arhitekture mreža. Element, Zagreb.

[11] KRALJ, Z. 2003. Tehnike upravljanja zagušenjem u bežičnim lokalnim mrežama. Diplomski rad, ZZT – FER, Zagreb.

33

Skraćenice

ARQ Automatic Repeat reQuest

ATM Asynchronous Transfer Mode

BER Bit Error Ratio

BER Bit Error Ratio

B-ISDN Broadband ISDN

CRC Cyclic Redudancy Check

DSSS Direct Sequence Spread Spectrum

EBSN Explicit Bad State Notification

FDDI Fiber Distributed Data Interface

FEC Forward Error Corection

GBN Go-Back-N

GUI Graphical User Interface

HIPPI High Performance Parallel Interface

IP Internet Protocol

ISDN Integrated Services Digital Network

I-TCP Indirect TCP

MSS Maximum Segment Size

MTCP Mobile Host TCP

MTU Maximum Transfer Unit

OSI Open System Interconnection

PEP Performance Enhancing Proxy

PSTN Public Switched Telephone Network

QoS Quality of Service

RFC Request for Comments

RLP Radio Link Protocol

RTO Retransmission TimeOut

RTT Round Trip Time

SACK Selective Acknowledgement

TCP Transmission Control Protocol

WAP Wireless Application Protocol

WLAN Wireless Local Area Network

WMAN Wireless Metropolitan Area Network

34

Popis stranih izraza

ad hoc nezavisan, samostalan

bandwith širina prijenosnog pojasa

beacon poruka, zraka

bottleneck usko grlo

burst snop

congestion avoidance izbjegavanje zagušenja

congestion window prozor zagušenja

downlink dolazni smjer

end to end s kraja na kraj

engine jezgra simulatora

fast recovery ubrzani oporavak

fast retransmission ubrzano ponovno slanje

handoff prelaženje, prekapčanje

idle time vrijeme neaktivnosti

jitter kolebanje kašnjenja

link layer sloj linka

multicast višeodredišno razašiljanje

multipath propagation višestazno rasprostiranje signala

router usmjerivač

slow start spori start

splitting connection razdvajanje konekcije

three-way handshake trostruko rukovanje

throughput propusnost

uplink odlazni smjer

wireless link bežični link

35

Dodatak

Upute za korištenje programske podrške

Za pokretanje simulatora potrebno je kreirati novi direktorij te kopirati cijeli Java projekt u taj

direktorij, npr. C:\temp\TCPSnoop. Uz sam projekt potrebno je kopirati i Engine.bat skriptu

koju treba pokrenuti. Nakon toga otvara se grafičko sučelje u kojem korisnik unosi željene

parametre potrebne za simulaciju. Sama simulacija pokreće se klikom na dugme ''Start''. Po

završetku simulacije vidi se ispis događaja u Command prompt-u a u samom grafičkom

sučelju neki bitni podaci vezani uz simulaciju kako je prikazano slikom (Sl. 3-1). Treba

naglasiti da ovo vrijedi za slučaj kada je projekt već preveden (engl. compile) tj. postoje

.class datoteke za pojedine klase. Ukoliko to nije slučaj potrebno je prvo program prevesti u

byte codove (datoteke s ekstenzijom .class) i to pomoću naredbe javac.

Slika (Sl. 1) predočava internu blok-shemu simulatora i prikaz komunikacijskih ruta između

pojedinih objekata u simulaciji

Sl. 1 Arhitektura TCP-snoop simulatora

Primjer konfiguracije .bat skripte koja služi za pokretanje simulatora:

@ECHO OFF

java -cp C:\temp\TCPSnoop hr.fer.tel.jaksic.Engine

pause

Slijedi prikaz dijela događaja koji se ispisuju u konzolu:

Server: ESTABLISHED - Sending Data Segment Download burst length = 23 Download state = 0 // ON state of wireless channel

36

Engine: segment delivered to access point t = 507 Engine: segment delivered to client t = 607 Channel: fromServer.seqNum = 82 Channel: fromServer.length = 40 Channel: fromServer.ackNum = 301 Client: receivedSegment.ackNum = 301 Client: state ESTABLISHED – 2 // number of state Client RCV_NXT = 42 Client: receivedSegment.seqNum = 42 Client: receivedSegment.length = 40 Client: Expected segment received! Client RCV_NXT = 82 Loss Distribution = 1 Upload burst length = 36 Upload state = 0 Channel: fromClient.seqNum = 301 Channel: fromClient.ackqNum = 82 Channel: fromClient.length = 0 // ACK segment Engine: segment delivered to client t = 608