Pošto privodim kraju diplomski rad pod radnim nazivom «Merenje performansi na IEEE 802.11b mreži» cijenim da bih mogao da razjasnim zašto su realni protoci značajno manji od deklarisanih brzina prenosa. Pokušaću priču da pojednostavim zbog ljudi koji nisu baš toliko familijarni sa mrežnim protokolima, OSI slojevima i sl. Oni koji jesu ne bi ni trebalo da imaju nedoumice u vezi ovoga.
Za početak, treba razlikovati bitsku brzinu prenosa (eng. air rate) koja se ostvaruje na samom bežičnom medijumu od protoka koji se ostvaruje na nivou aplikacije. Prilikom prenosa, da bi se obezbedilo da poslati paket uspešno stigne na odredište koristi se veći broj protokola. Konkretno, aplikacija predaje podatke za slanje TCP protokolu, ovaj dalje IP-u i na kraju imamo 802.11 u slučaju wireless-a, ili Ethernet, za žične mreže. Slikovito, to izgleda ovako:
Osjenčena polja označavaju zaglavlja. MAC i PLCP su protokoli koji se definišu unutar 802.11. Maksimalna veličina paketa za Ethernet iznosi 1500B, a pošto se bežične mreže najčešće dalje vezuju za Ethernet, to isto važi i za njih. E sad, ovaj PSDU od 1528B se šalje nekom od deklarisanih bitskih brzina. Ako smo postavili «11Mbps only», vreme potrebno za njegov prenos iznosi:
TPSDU=1528*8b/11Mbps~=1100us
I bilo bi krasno da se ovde priča završava, pošto bi u tom slučaju za 1196us preneli 1460*8 bita, odnosno, imali bi protok od
1460*8/1196=9,8Mbps (Wow!)
Vjerujem da se za ovaj skromni gubitak niko nebi bunio...
Za Full duplex Ethernet priča bi se ovde zaista završila. Kod njega bismo imali nekih 5% overheda, pa stoga 10Mbps Ethernet daje oko 9,5Mbps protoka na nivou aplikacije (ako isključimo ostale faktore). Slično je i za Fast Ethernet (100à95Mbps).
Ono što je mnogo važnije jeste način, odnosno kontrola pristupa bežičnom medijumu. Svi klijenti pridruženi jednom AP-u međusobno dijele dati kanal. U jednom trenutku samo jedan klijent može vršiti komunikaciju (ili slati ili primati podatke). Standard 802.11 definiše proceduru pristupa pod nazivom CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Da pojednostavim priču: svaka stanica (uključujući i AP) osluškuje kanal registrujući da li je slobodan ili zauzet. Kada vidi da je kanal slobodan, ukoliko ima spreman paket za slanje, čeka određeni backoff interval. Ovaj interval se slučajno (uniformno) bira u opsegu od 0-620us. Time se obezbeđuje izbegavanje kolizija ukoliko dve ili više stanice istovremeno žele pristup. Ukoliko se pre isteka intervala detektuje zauzet medijum, zamrzava se njegovo stanje i ponovo čeka da se kanal oslobodi. Nakon isteka backoff intervala, počinje sa slanjem. Kao što se vidi, ovaj backoff interval, koji u proseku iznosi 310us već predstavlja značajan overhed. Dodatno, za svaki poslati paket, odmah nakon prijema se šalje potvrda (ACK) sa druge strane. Ovo je još uvijek na nivou WLAN-a. Tako, već sada, uz neke druge intervale koji prethode slanju imamo nekih 1680us zauzeće kanala za slanje jednog paketa maksimalne dužine. To jest, ostvarivi protok iznosi oko:
1460*8/1680~=7Mbps
Ovaj protok se može ostvariti ako se umesto TCP protokola koristi UDP. UDP se koristi pri prenosu slike i/ili zvuka u realnom vremenu. UDP je vrlo jednostavan protokol, koji pošalje svoj datagram i njegova dalja sudbina ga ne interesuje. Za razliku od njega TCP vrši kontrolu toka i greški, tako da obezbeđuje slanje TCP ACK paketa kao potvrdu prijema odnosno, retransmisije u slučaju neuspešnog slanja. Tako da u realnom slučaju, slanje jednog paketa iziskuje i slanje jednog TCP ACK paketa u suprotnom smeru za koji važi sva ova priča od malopre, samo je značajno kraći (sastoji se samo od TCP zaglavlja, tj. ne poseduje deo sa podacima). Tako i on dodatno, «nepotrebno» troši naš bežični medijum, pa se protok svede
na nekih 6,3Mbps, maksimalno. Da ne bi bilo zabune, ovaj rezultat je i praktično verifikovan.
Vezano za priču oko up & downlinka i poludupleksa: Ovo što smo dobili je protok u jednom smeru, bilo kom. Najčešće se komunikacija tako i odvija, npr. kod download-a. U slučaju simultane dvosmerne komunikacije, pod pretpostavkom da obe strane (jedna na wireless-u, druga negde daleko) šalju jednake količine podataka, ukupan protok će se otprilike prepoloviti. Ne protok u jednom trenutku, već ukupna količina poslatih ili primljenih podataka u određenom vremenskom intervalu će biti ekvivalentna protoku od ~3,3Mbps, u naj-naj-boljem slučaju.
Naravno, u zavisnosti od udaljenosti od AP, LOS-a, tj. odnosa S/N na prijemu, interferencije i sl., realan protok dodatno opada, što zbog većeg broja greški/retransmisija, što zbog obaranja brzine prenosa pojedinih paketa, što zbog nekih drugih faktora. Vezano za ovo obaranje brzine: Predajna stanica pokušava da šalje maksimalnom brzinom, međutim, u slučaju višestrukih retransmisija ona obara brzinu slanja. Na manjim brzinama, korišćeni tipovi modulacije su otporniji na šum, pa je i verovatnoća gubitka paketa manja.
U slučaju većeg broja klijenata na jednom AP-u, pošto svi dele jedan isti kanal, protoci po jednom klijentu se umanjuju, približno srazmerno broju korisnika. Naravno, u pitanju je najgori slučaj kada svi istovremeno šalju/primaju podatke.
Ogromne su granice moga neznanja... Pa, nek mi bude oprošteno ako šta i kome sagriješih...
Ne može to bez kabla...