Вы должны войти в систему для того, чтобы создавать сообщения и темы.

Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 4 — Handoff

Wi-Fi HandoffHandOFF дословно — передавать. Однако в контексте 802.11 я бы скорее перевёл бы этот термин (применительно к АП) как "руки прочь".

В третьей части цикла мы рассмотрели такую процедуру как handover, которую выполняет клиент для миграции внутри wi-fi сети.

А что делать, если клиент по какой-то причине отказывается инициировать переход? А если клиент вообще не умеет самостоятельно мигрировать?

Вот тут к нам на выручку придёт механизм HandOFF. Как обычно в 802.11, этот механизм не является частью стандарта, не обязателен к реализации и вообще не предусмотрен. Сюрпрайз!

[caption id="attachment_1052" align="alignright" width="300"]wive-ng handoff parametrs Настройки HandOFF в Wive-NG[/caption]

Ну что же, нам не привыкать.

В чём смысл? А смысл прост, АП мониторит уровни от клиентов, и при достижении минимального порога посылает DEAUTH сигнал клиенту.

Клиент благополучно «слетает» с ТД, а дальше…

А дальше выполняет всё то, что мы описывали в первой части. Чаще всего при этом сразу же будут оборваны все соединения локальных приложений. Т.е. так называемой бесшовностью тут не пахнет. Исключение разве что клиенты с модифицированной логикой обработки события прихода DEAUTH фрейма и обработка его как сигнал к форсированию логики handover. К сожалению этот вариант встречается не очень часто, например так умеет радио от Qualcomm (описывал опцию в соседней статье, см опцию gEnableHandoff).

Кто-то разумно заметит, что DEAUTH фрэйм может быть послан с несколькими десятками reason code. Зачем слать StaLeave если можно использовать что-то более «мягкое».

Ну во первых потому что ничего более мягкого по сути и нет. А во вторых в 802.11 как обычно, даже если в стандарте это есть, совсем не факт, что по факту эти reason коды будут обработаны клиентом, т. е. вообще будет присутствовать реализация обработки этих reason`ов.

Как пример вот что об этом говорит CISCO. Смотрим табличку https://supportforums.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055

Нас интересует 802.11 Deauth Reason Codes. Слегка офигиваем от NOT SUPPORTED и успокаиваемся.

Справедливости ради, стоит заметить, что в 802.11 есть нужный reason за номером 12 - Disassociated due to BSS Transition Management. Однако даже CISCO оный ризон не поддерживает. И вообще по факту мне не удалось найти клиента который бы его обрабатывал корректно.

Чаще всего клиент его обрабатывает так же как и 8 (sta leave) или же вовсе игнориурет, и в итоге получаем клиента который до упора будет считать, что подключен к ТД, в то время как ТД считает, что клиент обработав сигнал ушёл на соседнюю АП.

В результате, даже если клиенты умеющие 12 reason и существуют в природе, мы всё равно вынуждены, ради совместимости, слать всё тот же Sta Leave т. к. ТД не знает, что именно реализовано в клиенте.

Так же нет никаких механизмов при этом сказать клеинту куда нужно мигрировать и нужно ли вообще.

Проще говоря мы просто выпинываем (kick out) клиента с ТД и надеемся, что клиент переключиться на более подходящую ТД, что не всегда так. А многие клиенты первым делом пытаются вернуться назад. Или вовсе впадают в ступор и ждут пока пользователь снова ткнёт «подключиться». Благо последний вариант всё же редкость. А против возвращенцев можно использовать временную блокировку на уровне probe/assoc/auth (как например это сделано в Wive).

Подведём итог. Handoff в 802.11 это по сути простое спинывание клиента с ТД в надежде, что клиент перейдёт на соседнюю ТД с лучшими параметрами. Процедура инициируется ТД, что даёт возможность более гибко, исходя из различных параметров линка (но чаще всего тупо из уровня с которым АП слышит клиента) вынуждать клиента мигрировать (не всегда успешно и почти всегда с потерей соединения приложениями).

Безусловно, это лучше чем ничего. И если не стоит задачи получить именно бесшовность, то можно смело использовать для балансировки нагрузки и обеспечения максимальной производительности сети. И/или как подстраховку в бесшовной сети для клиентов не умеющих мигрировать самостоятельно. Правда в этом случае придётся выбрать порог срабатывания настолько низкий, что бы не затронуть нормально мигрирующих клиентов. Что в свою очередь сильно уменьшит эффект от такой балансировки.

В ближайшее время постараюсь расписать как handover реализован у нас (в Wive-NG-MT), как его настроить в зависимости от задачи и т. д.

P.S. По традиции немного веселья из мира Enterprise $). Описание настройки handoff для рукуса https://support.ruckuswireless.com/answers/000002277. Они называют это smart roam. Как всегда в мире Enterprise любой костыль выдаётся за мегадостижение, а т.к. сейчас всё SMART то и костыль должен быть Smart. Так же по ссылке есть рекомендации по отладке роуминга, которые сводятся к обновлению софта (видимо для поддержки RRM) и настройки агрессивности роуминга на клиенте (говорил в первой части о этой опции). Ну и если совсем не помогло, включаем smart roam. =) Ну и обилие опций (аж одна штука) поражает воображение. =)

Часть 3