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

Это первая статья из цикла посвящённых миграции (роумингу) в сетях wi-fi (802.11).

Давайте разберёмся, как это происходит и кто ответственен за результат. В том числе рассмотрим как обеспечивается бесшовность покрытия.

Для начала стоит определиться с тем, как вообще происходит соединение в wi-fi. Точнее, что именно ему предшествует.

Первое, что мы должны сделать – это выяснить, какие точки доступа (далее , access point – AP) ведут вещание. Данная процедура может быть осуществлена двумя способами:

1) активное сканирование
2) пассивное сканирование.

Процедура активного сканирования сама состоит из нескольких фаз:
1) Смена канала
2) Посылка probe request
3) Ожидание ответа

Т.е. клиент должен по очереди перебрать все поддерживаемые им каналы, отправить probe запросы, дождаться ответа.

Сканирование одного канала (включая ожидание ответа) занимает около 20мс. Так, например, активное сканирование 2.4ГГц диапазона, доступного в РФ (1-13 каналы), займёт 260мс.

Сканирование всего 5ГГц диапазона, доступного в РФ (36-48, 52-64, 132-144 , 149-165), – 960мс.

Понимание этого будет важно в будущем. Потому обязательно следует запомнить эти цифры.

Также следует запомнить, что запуск фазы активного сканирования делает невозможной какую-либо передачу данных, если вы подключены к AP.

Вариант пассивного сканирования сводится к прослушиванию эфира на предмет маяков, которые рассылает AP (обычно раз в 100мс). Никакие запросы в этот момент клиент не посылает. Это крайне важно понять и запомнить.

Т.е., нам нужно опять-таки перебрать все каналы, на каждом находиться и слушать эфир минимум 100мс (на самом деле больше, чтобы гарантированно услышать все AP, ведущие вещание).

Исходя из этого мы можем посчитать время, затрачиваемое на такой вариант сканирования – оно будет минимум в 5 раз больше (100/20), нежели в активном режиме. В 2.4ГГц – 1300мс, в 5ГГц – 4800мс.

Казалось бы, такой режим не имеет права на существование, т.к. в разы уступает варианту активного сканирования. Но это только кажется. ;)

Эти 2 варианта доступны нам, когда клиент ещё не подключен к AP.

Если мы подключены к AP, то нам становится доступен ещё один – третий способ определения того, какие AP ведут вещание. А именно, мы можем послать текущей AP, к которой подключены, запрос neighbor report request, используя протокол 802.11k radio resource management (RRM). В ответ мы получим как минимум список соседних AP.

К сожалению, этот протокол поддерживается, на текущий момент, лишь небольшим числом AP. Хорошая новость в том, что Wive-NG имеет поддержку RRM. Подробнее о RRM мы поговорим при рассмотрении средств ускорения миграции в сетях 802.11. Пока просто запомним, что такой механизм у нас есть, и он, в отличии от сканирования, не требует остановки передачи данных с текущей AP, а также занимает минимум эфирного времени.

Кроме добавления этого механизма, можно использовать и уже известные нам варианты сканирования с небольшой модификацией.

Модификация добавляет в схемы сканирования ещё 2 шага к уже имеющимся.

А именно:
1) перед сменой канала мы должны перейти в режим PSM (Power Saving Mode), что заставит текущую AP начать буферизацию данных в сторону нашего клиента;
2) переключить канал и выполнить один из вариантов сканирования, описанных выше, вернуться на свой канал;
3) выйти из PSM режима, после чего AP очень быстро должна сгрузить нам данные.

Дополнительные шаги нужны для того, что бы не получить обрыв соединения с текущей AP, т.к. во время выполнения сканирования мы не можем обмениваться данными с AP, к которой подключены. Потеря части данных тут не так важна, как потеря самого соединения.

Для пассивного режима существует исключение. Если нам требуется получить данные только об AP на том же канале, на котором работаем и мы, то необходимость в шагах 1 и 3 отпадает, как и переключение канала. Как результат, в пассивном режиме мы можем получать данные о соседних AP, работающих на том же канале, без остановки передачи данных с текущей AP. Это очень полезное свойство пассивного режима.

Итак, используя один или все методы, мы получили данные об AP, ведущих вещание. Что дальше?

А дальше мы должны выбрать кандидата для подключения.

Обычно это происходит просто банально выбором AP с максимальным уровнем и SSID, совпадающим с выбранным пользователем. Различия тут будут лишь при использовании каких-либо дополнительных механизмов. Например, band preffered или 802.11r, который добавляет, кроме SSID ещё поле MDIE. Но об этом в следующих статьях.

Как только кандидат определён, мы посылаем ему probe req с указанием MAC клиентского устройства, т.е. такой целевой probe запрос. Во-первых, на этом этапе мы проверяем готова ли эта AP нас принять и/или жива ли она вообще, во-вторых, получаем дополнительные данные о режимах работы (алгоритм аутентификации, алгоритм шифрования).

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

Время на фазы ассоциации+аутентификации (в случае, если всё прошло без проблем) в режиме WPA2 PSK составляет около 110мс.
Для режима WPA2 FT-PSK (с использованием 802.11r) время сокращается примерно до 10-20мс.

WPA2 802.1x (WPA Enterprise) без использования FT (802.11r) или OKC (opportunistic key caching) зависит от загруженности radius сервера, к которому AP должна обращаться, чтобы выяснить, пустить или не пустить пользователя. В особо тяжёлых случаях может занимать секунды.

При использовании WPA2 802.1x (WPA Enterprise) + FT/OKC время сокращается примерно до тех же 10-20мс, что и в режиме FT-PSK.

Опять-таки, хорошая новость для пользователей Wive-NG. Мы умеем 802.11r для всех режимов, что гарантирует минимальное время, затрачиваемое на аутентификацию.

Но важно не это. Важно, что фаза аутентификации, на фоне фазы сканирования во всех случаях, кроме голого WPA Enterprise без FT/OKC, достаточно короткая, чтобы добавить проблем с миграцией, или чтобы пользователь заметил этот момент.

Банальное сканирование 2.4ГГц диапазона – 260мс. А если нужно оба диапазона (радиомодуль в клиенте обычно один), то это уже все 260мс + 960мс = 1220мс в лучшем случае при активном сканировании.

Плюс есть ложка дёгтя. Для работы механизмов FT/RRM (802.11r/k) требуется их поддержка как на клиенте, так и на AP.

По факту же, AP, умеющих эти протоколы, в SOHO сегменте почти не наблюдается, а клиентов с их поддержкой – вообще минимум. Из более-менее массовых устройств, это свежие Samsung Galaxy S и A серий, а также свежие устройства от Apple.

Проверить, умеет ли ваше устройство хотя бы один из этих протоколов (замечу, один другого не заменяет), можно косвенно, попытавшись найти ваше устройство на сайте Wi-Fi Альянса и убедиться, что он прошёл сертификацию по программе “Voice-Enterprise: Voice quality and bandwidth management tools for the enterprise”.

Подробнее: https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-voice-programs

Однако, нахождение устройства в списках сертификации не гарантирует фактическую работу (часто ломают после первых же обновлений). И наоборот, отсутствие устройства в списках не говорит о том, что оно 100% не умеет 802.11k/r. Однако, если у вас устройство под Android и его нет в списке программы сертификации, то это 99%, что устройство не умеет ни K, ни R.

Напомню, что Wive-NG умеет 802.11 K/R, хотя мы и не проходили сертификации у альянса.

Исследование 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

Часть 2.