Zobrazení zdroje stránky Problém skrytých uzlů („hidden nodes“)

== Úvod ==
Tento problém je způsoben faktem, že návrh fyzických protokolů 802.11a/b/g (WiFi) byl veden hlavním předpokládaným způsobem využití bezdrátovým připojením uživatelů uvnitř budov na vzdálenost maximálně desítek metrů, jako doplněk k metalické síťové kabeláži. Typický příklad je připojení desítek notebooků účastníků konference v sále, kde by připojení pomocí kabelů bylo neekonomické, nepraktické a velmi těžko realizovatelné.
*Rozdíl mezi konferenčním sálem a WiFi sítí s externími anténami (na střechách) je ten, že wifi karty všech uživatelů v sále vzhledem k malé vzdálenosti a všesměrovým anténám vzájemně slyší své vysílání. Mohou tak reagovat na stav, kdy před vysíláním vlastních dat zjistí, že kanál je momentálně obsazen vysíláním jiného uživatele. 
*Situace je ale naprosto odlišná v případě externích antén: důvodem je jejich větší směrovost a také členitý venkovní terén s mnoha překážkami (stromy, domy, …), kvůli čemuž se část klientů vzájemně neslyší. Uživatelům, jejichž vysílání je před ostatními uživateli skryto díky překážkám nebo díky velké směrovosti jejich antény, se říká „skryté uzly“. 
*V síti se skrytými uzly dochází s růstem počtu aktivních uživatelů k dramatickému nárustu kolizí při vysílání, kdy se v jednu chvíli snaží vysílat dva nebo více uživatelů, takže přístupový bod jejich vzájemnému „překřikování“ nemůže rozumět. Protože standard 802.11 je postaven na využití poloduplexních rádií, která mohou v daném okamžiku buď pouze přijímat, nebo pouze vysílat, není možná detekce kolizí již v průběhu přenosu (systémem CSMA/CD) jako u kabelového ethernetu. Kolize ve WiFi síti jsou proto pouze jedna z mnoha neidentifikovatelných příčin chyb při přenosu. Celkově se tento jev se projevuje ve chvílích velké zátěže sítě masivními ztrátami packetů u všech uživatelů přístupového bodu bez ohledu na kvalitu jejich signálu, přičemž nejvíce jsou postiženy právě skryté uzly. Z podstaty problému je také zasažen především upload.
*Omezení efektu skrytých uzlů je možné pouze dodržování minimálních vzdáleností uživatelů od přístupového bodu (do 100m) a použitím máloziskových antén s větším úhlem vyzařování, které zajistí, že se většina uživatelů bude vzájemně slyšet. Pokud takovouto konfiguraci nelze docílit, je ještě možné nastavit všem uživatelům daného přístupového bodu povinné používání mechanismu RTS/CTS, kdy každé zařízení musí před vysláním regulérního packetu poslat požadavek RTS („Request to send“) a čekat na odpověď přístupového bodu CTS („Clear to send“). Tento mechanismus omezuje kolize (Collision Avoidance, CSMA/CA), bohužel jej ale nelze zapnout centrálně, musí se nastavit u každého uživatele zvlášť parametrem „RTS Threshold“, který určuje velikost packetu, před jehož vysláním se má čekat na CTS. Nevýhody používání mechanismu RTS/CTS jsou následující:
**	v případě bezdrátových karet vyžaduje znalé a zodpovědné uživatele, kteří jsou schopni nastavení RTS Threshold obnovit i v případě reinstalace operačního systému
**	ve srovnání s ideálním stavem - sítí s žádnými skrytými uzly - čekání na potvrzení CTS způsobuje pokles propustnosti sítě
**	pokud bude většina uživatelů v síti používat RTS/CTS, pak uživatel, který tento mechanismus nemá nastaven, bude nad ostatními uživateli ve výhodě – bude schopen data přenášet rychleji a častěji
**	některé přístupové body (Mikrotik!!!!) tento mechanismus nepodporují nebo podporují chybně

== Chování sítě v závislosti na nastavení RTS Threshold ==
Zatím nejlepší článek, popisující chování WiFi APčka v závislosti na provozu, počtu připojených lidí a nastavení RTS Threshold je k dispozici zde: http://www2.tku.edu.tw/~tkjse/6-1/6-1-8.pdf

Dovolím si vypůjčit a česky okomentovat několik obrázků z tohoto článku:

===Závislost propustnosti na zatížení sítě a hodnotě RTS Threshold pro velké packety=== 
[[Soubor:Propustnost-vs-RT-Lambda.png]]

Figure 6: Tady vidíte, jak se chová propustnost AP s 25 klienty, kteří posílají packety o průměrné velikosti 1000 bajtů, v závislosti na RTS Threshold a míře zátěže &#x3BB;, generované klienty.
* Pro velmi nízkou zátěž &#x3BB;=0.0001 je propustnost AP = 50% maximální reálné propustnosti, nastavení RTS Threshold nemá vůbec žádný vliv, protože nenastávají kolize
* Pro větší zátěž &#x3BB;>=0.0002 ale už má nastavení RTS Thresholdu podstatný vliv na propustnost. Pokud necháte RTS Threshold v defaultní hodnotě (2000 bajtů), je propustnost pouze 48% maximální reálné propustnosti. Pokud nastavíte RTS Threshold na optimální hodnotu (např. 170 bajtů), dostanete propustnost až 75%!!

===Závislost propustnosti na počtu klientů a hodnotě RTS Threshold pro malé packety===
[[Soubor:Propustnost-vs-RT-vs-N.png]]

Figure 7: Průměrná délka packetů = 150 bajtů, &#x3BB;=0.001 (vysoké zatížení). Zde se můžete podívat, jak se bude APčko za těchto podmínek chovat pro různý počet klientů (N). Bohužel graf končí u RTS Threshold=1000, tj. abyste viděli, jak se to bude chovat pro defaultní RTS Threshold=2000 (tj. RTS/CTS vypnuto), musíte si graf dokreslit prstem :-)
* Je vidět, že pokud je RTS Threshold nastaven na malou hodnotu (100-300), chová se AP i pro velký počet klientů (N=50) stále snesitelně - rozdíl propustnosti mezi 50ti a 15ti klienty je pouze 8% !!!
* Naopak, pokud je RTS nastaveno na větší hodnoty (nebo na defaultní 2000), je degradace propustnosti tím větší, čím víc klientů je na AP připojeno. U 50ti klientů tak klesá až pod 10%...

===Závislost propustnosti na počtu klientů a hodnotě RTS Threshold pro velké packety===
[[Soubor:Propustnost-vs-RT-vs-N-velke_packety.png]]

Figure 8: Průměrná délka packetů = 1000 bajtů, &#x3BB;=0.001 (vysoké zatížení). 
Tento obrázek nás bude zajímat víc než ten předchozí, protože za normálních podmínek (pokud zrovna na APčko neútočí nějaké viry) tvoří právě velké packety většinu provozu na APčku
* opět je vidět, že pokud je RTS Threshold nastaven na malou hodnotu (100-300), chová se AP i pro velký počet klientů (N=50) stále snesitelně - rozdíl propustnosti mezi 50ti a 5ti klienty je pouze 8% !!!
* Naopak, pokud je RTS nastaveno na velké hodnoty (nebo na defaultní 2000), je degradace propustnosti tím větší, čím víc klientů je na AP připojeno. Bohužel, na grafu opět chybí hodnoty RTS Threshold > 1000, takže výslednou hodnotu - kam to až spadne, pokud RTS Threshold není nastaven - můžeme jen odhadovat

===Závislost propustnosti na délce packetů a hodnotě RTS Threshold pro velkou zátěž===
[[Soubor:Propustnost-vs-MDL-vs-RTS-velke_lambda.png]]

Figure 9: Počet klientů N=25, &#x3BB;=0.001 (vysoké zatížení). 
* Pro malé hodnoty RTS Thresholdu (0-175 bajtů) se závislost propustnosti na délce packetů chová podobně, jako u drátového ethernetu
* Pokud je RTS/CTS vypnut (tj. RT=nekonečno), nejsme schopni překročit hranici propustnosti 30% při žádné velikosti packetů

===Závislost propustnosti na délce packetů a hodnotě RTS Threshold pro velkou zátěž===
[[Soubor:Propustnost-vs-MDL-vs-RTS-male_lambda.png]]

Figure 10: Počet klientů N=25, &#x3BB;=0.0001 (malé zatížení). 
* Pro malé hodnoty RTS Thresholdu (0-175 bajtů) se závislost propustnosti na délce packetů chová podobně, jako u drátového ethernetu
* Pokud je RTS/CTS vypnut (tj. RT=nekonečno), pak od průměrné velikosti packetů = 1000 bajtů začnou kolize snižovat propustnost

==Řešení==
* Jak navrhují autoři těchto grafů (Fun Ye, Shiann-Tsong Sheu, Tobias Chen a Jenhui Chen), nastavení RTS Thresholdu na nízkou hodnotu (např. 175) prudce zlepší chování celé sítě
* Bohužel Mikrotik nepodporuje mechanismus RTS/CTS - pokud jej u klienta aktivujete, Mikrotik mu nikdy nepošle CTS, takže takový klient přestane vysílat.
* Na Mikrotiku se tedy musíte smířit s tím, že s rostoucím počtem klientů bude dramaticky klesat propustnost uploadu - minimálně tak, jak to znázorňuje Figure 9. S tímto vědomím [[Probl%C3%A9m_s_velk%C3%BDm_pingem|musíte nastavit i Qosy v Mikrotiku (viz návod)]], aby klientům, kteří jsou skryté uzly, jela síť vůbec nějak.
* Ideální řešení je místo Mikrotiku nasadit Linux, jehož Madwifi samozřejmě RTS/CTS podporuje. Návod na instalaci [http://wiki.hkfree.org/RouterboardRB500Linux Linuxu na RB532 je zde]