Хэндовер (англ. Handover) — в сотовой связи процесс передачи обслуживания абонента во время вызова или сессии передачи данных от одной базовой станции к другой.
Вот мы и подобрались непосредственно к миграции. В т.ч. в случае так называемого бесшовного роуминга.
Попробуем дать определение этой процедуре применительно к сетям 802.11 (да-да, в 802.11 как всегда всё наизнанку, привыкайте).
Handover — процедура миграции между точками доступа, инициируемая и осуществляемая клиентом исходя из определённых (одному ему известных), не регламентированных “стандартом” критериев.
Самое важное в этом определении – то, что именно клиент инициирует процедуру перехода, и именно он решает когда, куда, как и по какой причине он решил мигрировать.
Когда клиент запускает процедуру handover? На этот вопрос нет однозначного ответа, т. к. «стандарт» 802.11 не определяет ни самой процедуры, ни критериев.
В самом простом (однако в самом часто встречающемся) случае происходит буквально следующее:
При каждом возникновении события RSSI changed происходит проверка уровня сигнала. И если сигнал низкий (обычно на клиентах низким считается RSSI < -75dB), то клиент:
– запускает процедуру сканирования,
– просматривает данные фонового сканирования, выполненного недавно,
– проводит опрос текущей станции по RRM на предмет наличия соседей с более высоким (обычно используется дельта порядка 5-10dB) уровнем сигнала. Собственно уровень сигнала в данном случае и является критерием выбора кандидата.
Также могут использоваться и другие критерии (например, драйвера Qualcomm для каждого кандидата начисляют очки исходя из данных загруженности, поддержки WMM, совпадения MDIE и др.). Пороги срабатывания handover могут быть динамическими или форсировать запуск handover исходя из оценки каких-либо критериев (например, ситуация, когда уровень и сейчас с большим запасом, но рядом есть точка доступа с уровнем многократно выше).
Однако, чаще всего критерий ровно один — падение уровня на текущей AP ниже порогового значения, которое чаще всего задано как -75dB.
Опять-таки, т. к. требования со стороны «стандарта» не определены, каждый чипмэйкер реализует это по-своему.
Настройка агрессивности роуминга у Intel
Зачастую нет даже регулировок порога срабатывания на клиенте. За исключением, разве что Intel`а, который традиционно предоставляет такую возможность в своём драйвере, называя её “Агрессивность роуминга“. Эта крутилка меняет частоту фоновых сканирований и порог, по которому будет инициирована процедура миграции.
Многие производители клиентских устройств вообще не заморачиваются и не включают поддержку handover при сборке (благо, сейчас почти всегда в SDK как минимум этот механизм включен по умолчанию).
Но вернёмся к вопросу.
Когда кандидат для миграции выбран, мы попросту инициируем новое соединение с ним, проходя все те же этапы, что и при обычном соединении. Разумеется, не забыв при этом попрощаться с текущей AP, послав ей STA_LEAVE (опять же, не все клиенты это делают).
Тут может использоваться схема с преаутентификацией. Т.е. мы не шлём STA_LEAVE текущей АП, а сперва выполняем процедуру подключения к новой, и только если она удалась, посылаем STA_LEAVE той с которой мигрировали. Если не удалась, мы можем как ни в чём не бывало вернуться на старую станцию и продолжить работать.
Это самый правильный вариант. Из всех возможных.
Для ускорения этой процедуры используются следующие механизмы:
– если клиент уже ранее был на этой AP, и в кэше (PMK Chache) есть запись для него, то 4 шага аутентификации будут сокращены до двух, и клиент пройдёт по упрощённой процедуре реассоциации (Reassoc).
– также будет использована всё та же короткая процедура при использовании FT(802.11R)/OKC.
– процедура выявления кандидатов может быть ускорена с помощью (RRM)802.11K за счёт запроса у текущей AP списка работающих соседей без выполнения процедуры сканирования.
Однако, подавляющее число клиентов умеет разве что PMK Cache и OKC. Последний применим только в WPA2 Enterprise сетях.
Но сейчас не об этом. Да и основная проблема в другом.
Основной нюанс для осуществления именно бесшовности (на этом уровне, на L2,L3 есть свои не менее важные нюансы) – то, что в момент миграции клиент должен уложиться в тайм-аут TCP соединений системы, и что ещё важнее не сбрасывать эти соединения, т. е. на уровне операционной системы при успешной миграции не должно генерироваться событие link beat (Link down/up).
К сожалению, около 70% клиентов всегда генерят link beat и всегда сбрасывают соединения приложений. Именно это основная проблема при миграции на стадии переключения. Т.к. даже если всё прошло гладко, но система сбросила состояния соединения пользовательских приложений, то вместо кратковременного «квака» (например в VOIP) из-за небольшой потери пакетов получим гарантированную необходимость перезвонить.
На таких клиентах бесшовная миграция не возможна в принципе.
На других клиентах порог уровня, по которому инициируется Handover, задан ниже -80dB, и часто происходит так, что AP гораздо раньше перестаёт слышать клиента и отстреливает его, нежели клиент сам инициирует процедуру handover`а. И повлиять на это можно только одним способом — понижать уровень сигнала со стороны AP, чтобы AP не теряла клиента до момента срабатывания handover. Обычно уровень в 2.4ГГц при этом приходится выбирать ниже 16дБм, что заметно сказывается на SNR и приводит к заметной деградации сервиса (к сожалению мы не одни в эфире).
Вот так, в двух словах, можно описать всё, что происходит на L1 уровне в процессе handover и основных проблемах. Крайне упрощённо, но достаточно для понимания. В одной из частей мы вернёмся к проблемам (их значительно больше и не только на L1 уровне) и рассмотрим их подробнее.
Что из сказанного обязательно к запоминанию:
1) handover всегда инициирует клиент исходя из собственных соображений;
2) в 802.11 нет ни одного механизма сказать клиенту форсировать процедуру handover или просто внепланово «посмотреть вокруг», выполнив сканирование; ОБНОВЛЕНИЕ: В новых редакциях 802.11v предусмотрен механизм BTM, но поддерживается увы менее чем на 50% клиентов собственно умеющих этот самый 802.11v.
3) в 802.11 нет чёткого набора требований к алгоритмам реализации handover — всё отдано на откуп третьим лицам, потому существует далеко не одна реализация разной степени кривости;
4) на весьма большом числе клиентов процедура handover не подразумевает бесшовности, т. е. всегда приводит к сбросу соединений приложений;
5) немалый пласт клиентов вообще не умеет процедуры handover, и попытка соединения к новой AP будет выполнена только тогда, когда соединение с текущей будет утеряно, или же текущая AP пошлёт клиенту DEAUTH фрэйм;
6) единственное критичное требование к AP для функционирования процедуры хэндовер на клиенте – это её нормальная работа. Грубо говоря, она просто должна гарантированно пустить нового клиента без каких-либо аномалий.
Для решения проблемы миграции у клиентов, о которых сказано в пункте 5, производители AP изобрели ещё один костыльный механизм. Называется он HandOFF и о нём мы поговорим в следующей статье.
Исследование CISCO на тему критериев запуска процедуры handover можно увидеть тут https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html
Исследование CISCO стадии сканирования в процессе миграции и использование 802.11k (RRM) для сокращения этой фазы https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html на примере iphone6
Определение роуминга от wi-fi alliance https://www.wi-fi.org/knowledge-center/faq/how-does-a-client-roam
