Roaming and Steering

Често възникват въпроси, относно „поощряването“ на клиенти на безжични мрежи да използват по-подходяща точка за достъп. В тази статия документирам настоящите си виждания относно този проблем.

Въведение

Речник

• STA – станция – клиент на дадена безжична мрежа.
• BSS – basic service set, базово множество услуги – точка за достъп и всичките ѝ клиенти.
• ESS – extended service set, разширено множество услуги – няколко BSS-а, свързани чрез система за дистрибуция.
• DS – distribution system, система за дистрибуция – системата, чрез която множество BSS-и са свързани в един ESS. Ще подразбирам Ethernet сегмент.
• Roaming – роуминг – преминаване от един към друг BSS в един и същи ESS.
• Client steering – насочване на клиенти – активно действие от страна на точка за достъп, което кара клиент да се асоциира с определен BSS.
• Band steering – насочване към честотна лента – като client steering, само че насочва клиента към BSS в по-предпочитана честотна лента.

Стандартизация

IEEE 802.11 стандартите изрично отбягват специфицирането на „настойчиви“ действия и логика от страна на точките за достъп, що се отнася за насочване на клиентите. С други думи, когато се говори за избор на BSS, с който да се асоциират, топката е ИЗЦЯЛО в ръцете на STA имплементациите. Отказ от асоциация, на базата на друго, освен липса на правомощия за асоциация, е в разрез със стандартите.

Поправки на IEEE 802.11 с отношение към роуминг и насочване на клиенти – IEEE 802.11f (нестандартизиран), IEEE 802.11r, IEEE 802.11k, IEEE 802.11v, IEEE 802.11ad.

Съществуващи имплементации на насочване на клиенти

Решения със затворен код

Почти всеки сериозен производител на Wi-Fi хардуер, има собствена нестандартизирана имплементация на client и band steering. Няма да навлизам в детайли за Cisco, Aruba, UBNT, защото имплементациите им са затворени и нямам наблюдения над тях, освен за съществуването им.

hostapd

В де-факто стандартната имплементация на точка за достъп за Linux съществуват имплементирани както стандартизирани, така и нестандартизирани методи за насочване на клиенти.

Нестандартизирани подходи за насочване към честотна лента в официалните версии на hostapd

hostapd поддържа два подхода за насочване към честотна лента – отказ от отговор на probe request, ако даден клиент е бил забелязан на интерфейс в 5 ГХц честотна лента, или отказ от асоциация при същото условие[1]. И двата са доста „непохватни“, защото не взимат предвид това дали клиентът не би имал проблем при свързването към BSS-а на другия банд.

Важно е да се отбележи, че гореспоменатите два подхода могат да бъдат използвани само в случай, че една и съща инстанция на hostapd управлява всички физически интерфейси. Това е в разрез с текущата имплементация в OpenWrt и LEDE, при която за всеки физически интерфейс се стартира отделна инстанция на hostapd. Въпросът за изоставяне на сегашната имплементация беше отхвърлен от разработчиците на LEDE, защото би изискал сериозни промени в LEDE и ще направи системата по-малко отказоустойчива – при проблем с hostapd на един интерфейс, ще спре и другия.

Също така, не е имплементиран начин споменатите в [1] таблици от съседи да бъдат споделяни между отдалечени инстанции на hostapd. Това прави описаните в [1] подходи неприложими или поне непредвидими, при използване на повече от едно устройство в един ESS.

Нестандартизиран подход за насочване към честотна лента във форка на hostapd на Google

В доста информативна лекция по темата[2], служител на Google представи собствената им интелигентна имплементация[3] на band steering.

Плюсовете на тази имплементация пред вече съществуващата в hostapd са:

• Взима предвид потенциални проблеми при свързване към BSS-а на 5 ГХц.
• Предвидена е да бъде използвана в сценарий, при който отделна инстанция на hostapd управлява всяки отделен физически интерфейс.

За съжаление обаче е неизползваема в контекста на ESS с повече от една точка за достъп на отделни устройства.

Бих бил много щастлив, ако някой се заеме и имплементира дистрибутиран списък с клиенти, с който да работи тази имплементация. Нужна ни е за Open Fest.

Насочване към честотна лента чрез специфицираните в IEEE 802.11ad инструменти

IEEE 802.11ad въвежда промени, чиято цел е да улеснят избора на правилния банд от клиенти. В повече детайли – въвежда се MB (като multi-band) информационен елемент в beacon фреймовете на BSS-ите и метод за бързо прехвърляне на клиентска сесия между отделни BSS-и. В hostapd и wpa_supplicant от относително скоро съществува имплементация и за двете, но е скрита за конфигурационен флаг[4].

Положителното на тази имплементация е, че е стандартизирана от IEEE, но носи и редица отрицателни характеристики:

• Изисква поддръжка от клиентска страна.
• Нужно е една инстанция на hostapd да управлява всички физически интерфейси (като при 2.2.1).
• Нова е, неистествана е и преди всичко – не е активирана по подразбиране.

Насочване на клиентите чрез средствата на IEEE 802.11r, k и v.

От Cisco са описали по същество що е то Assisted Roaming чрез използването на горните стандарти[5]. Препоръчвам да прочетете статията за детайли. Обобщено обаче, идеята зад методите за улесняване на решенията за роуминг зад тези поправки, е следната:

Точките за достъп събират информация за използването на радио ефира както от станциите в обхвата им, така и на база на собствените си наблюдения. Тези данни се предоставят на всяка станция и се очаква имплементацията на всяка станция да вземе решение към кой BSS да се асоциира.

В hostapd и wpa_supplicant изглежда съществуват поне частични имплементации[6]. Предстои да ги проуча и тествам преди Open Fest.

Огромният недостатък е, че е нужно клиентите да имплементират дадената логика за избор на BSS.

Насочване на клиентите чрез ограничаване на мощността на излъчване на мрежовите карти на точките за достъп и избор на кодировки за висока производителност

Най-изпитаният и най-широко съвместим метод за „поощряване“ на клиентите да преминат към друг BSS остава внимателното избиране на подходяща мощност на излъчване от страна на точките за достъп. Това, комбинирано с ограничаването на basic rate-овете до 54Mbps исторически винаги е работило доста добре на Open Fest[9].

Особености при роуминг

При преминаване от един BSS към друг в контекста на един и същи Ethernet сегмент съществуват няколко особености, за които трябва да бъдат взети мерки.

Обновяване на кеша на L2 устройствата в Ethernet сегмента

Две точки за достъп могат да бъдат свързани чрез два различни порта на суич или дори чрез отделни суичове. Докато мигриралият от един към друг BSS клиент не изпрати фрейм, която да обнови кешовете на L2 устройствата в мрежата, трафикът, адресиран до него, ще продължи да бъде изпращан до предходната му точка за достъп.

В hostapd съществува частична имплементация на невлязлата в сила поправка IEEE 802.11f, която се грижи при свързване на нова станция да изпрати от нейно име LLC фрейм до целия Ethernet сегмент[7].

С наскоро приет пач, IAPP имплементацията в hostapd вече работи и при двубандови точки за достъп[10][11].

Ускоряване на свързването с новия BSS

IEEE 802.11r дефинира два подхода за ускоряване на свързването с BSS-а, към който даден клиент преминава. Това е нужно, защото началното ръкостискане при WPA и ОСОБЕНО при WPA Enterprise е доста времеемко.

Двата подхода са preauthentication по въздуха и preauthentication по системата за дистрибуция. hostapd поддържа поне ft-over-ds[8] за WPA И за WPA Enterprise.

Бъдещи имплементации

На базата на проучването ми на имплементацията на 802.11r, k и v, може да се oкаже, че от нова имплементация на client steering няма нужда, но това ще стане ясно по всяка вероятност чак след OF, ако изобщо.

Междувременно, ако е нужна нестандартизирана имплементация, бих препоръчал да се надгради форка на Google с дистрибутирано изграждане на съответните списъци от станции и да се добави допълнителна логика, която да взима предвид информация за качеството на връзката със станциите.