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

В этой части мы поговорим о такой «технологии» как Band Steering. Это необходимое для понимания работы миграции в Dual Band сетях отступление.

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

Поясню. На заре появления 802.11a, т.е. варианта 802.11, работающего в 5ГГц диапазоне, никто (как обычно) не задумывался о совместном использовании двух диапазонов, и о возникающих проблемах. В итоге вся логика, используемая на клиентах для 2.4ГГц, плавно перекочевала в 5ГГц.

В первой части статьи мы выяснили, что именно клиент, на первом этапе сканируя эфир, выясняет и выбирает, куда будет пытаться подключиться. И именно тут появляется проблема выбора рабочего диапазона.

Т.к. «стандарт» 802.11 не требует никакой специальной логики для dual band сетей, то выбор осуществляется просто по уровню сигнала (RSSI).

Но тут существует несколько моментов:
1) чем выше частота — тем выше затухание сигнала с отдалением от передатчика
2) чем выше частота — тем выше затухание в преградах

Т.е. при той же мощности передатчика (что на практике зачастую именно так) мы крайне часто, даже находясь в одном помещении, будем иметь ситуацию, когда RSSI в 5ГГц диапазоне будет заметно ниже. И наш клиент, несмотря на то, что умеет 5ГГц, будет стремиться соединиться в 2.4ГГц.

Проблема усугубляется с ростом расстояния от AP.

Почему это, собственно, вообще проблема? Какая, казалось бы, разница, в каком диапазоне будет работать клиент.

Тут всё просто. В 2.4ГГц очень тесно. В том смысле, что нет ни одного непересекающегося канала для полосы 40МГц (если посмотреть на спектр, который, как известно, не заканчивается резким обрывом). А 80МГц (и более) полосы вообще не доступны.

Плюс уже работает море устройств, не только wifi, и в т.ч. у соседей. Всё это приводит к значительному падению SNR (соотношению сигнал/шум). А именно SNR, а не RSSI, важен. Т.е., можно орать сколько угодно громко, но если рядом соседи будут кричать со сравнимыми уровнями, то клиент просто не сможет разобрать, что ему пытаются сказать.

В 5ГГц всё иначе. Диапазон более чистый, т. к. устройств там не так много, и в основном это такие же wifi устройства. Также, заметно более низкое влияние оказывают соседи, т.к. заметно выше затухание сигнала в преградах (читай стенах). Т.е., SNR даже при заметно более низком RSSI будет заметно выше, а передача данных быстрее и стабильнее. Плюс, доступна как минимум в четыре раза большая полоса (в случае с РФ), нежели чем в 2.4ГГц.

С точки зрения логики и здравого смысла, а также физики, имеет смысл пытаться использовать 5ГГц диапазон, если клиент его умеет, даже если уровень сигнала от конкретной AP заметно ниже, чем от неё же в 2.4ГГц.

И вот тут мы вспоминаем, что клиентские устройства у нас поголовно “тупые” и выбирают, куда будут соединяться, исключительно ориентируясь в RSSI.

Т.е. при одинаковых SSID в обоих диапазонах, большинство dual band клиентов банально будет использовать грязный и узкий 2.4ГГц диапазон, вместо того, чтобы работать в 5ГГц.

Правильным решением было бы наличие на клиенте логики, которая позволяет пользователю задать приоритет выбора диапазона.

И такие клиенты есть. Например, многие радиокарты от Intel позволяют выбрать preffered band (предпочтительный диапазон). Плюс большинство радиокарт в ПК и ноутбуках позволяют просто отключить поддержку того или иного диапазона, что также можно использовать для решения проблемы. Обычно все эти настройки доступны в настройках драйвера (Windows) или на уровне wpa_supplicant (Linux).

С мобильными устройствами в виде смартфонов дела обстоят иначе. В 99% случаев нет не то что band preffered, но и даже возможности банально отключить поддержку 2.4ГГц диапазона. И именно с ними проблема встаёт в полный рост.

Казалось бы, проблема решается элементарно, путём внесения в следующую итерацию «стандарта» и сопутствующих спецификаций требования реализации логики «preffered band» для всех клиентов, претендующих пройти сертификацию на совместимость с очередным 802.11AN/AC/AX и т.д…

К сожалению, Wi-Fi альянс считает иначе, поэтому требования не было и нет. Т.е. с 1999 года, когда был представлен вариант 802.11a «стандарта» wi-fi, проблема хоть и была выявлена, но никаких действий для её решения ни со стороны WiFi Aliance, ни со стороны большинства производителей клиентского оборудования, сделано не было.

Это не уникально для 802.11. Скорее даже наоборот. Очень многие проблемы этого протокола могли бы быть решены простым прописыванием разумных требований при прохождении сертификации. Но, к сожалению, картина обратная. И бардак в части поддержки 802.11 достиг уже поистине космических размеров.

Но это лирика. Вернёмся к Band Steering.

Т.к. Wi-Fi альянс решил проблемой не заниматься, пришлось производителям беспроводных решений изобретать свой велосипед.

Первыми на лоне решения этой проблемы была Meraki. Именно они предложили первый в своём роде костыль и назвали его Band Steering https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview

Основной смысл на тот момент заключался в том, что для нового клиента мы не сразу начинаем отвечать на probe request при активном сканировании и на стадии предшествующей ассоциации в 2.4ГГц диапазоне. А поставим клиента на hold и будем ждать несколько секунд, пока либо клиент не подключится к 5ГГц модулю, либо ничего не произойдёт, и тогда мы будем считать, что клиент у нас умеет только 2.4ГГц, и тогда мы его пустим.

И казалось бы, всё красиво. НО! Появился неприятный эффект. Достаточно много клиентов теперь всегда имеет задержку в несколько секунд при подключении и переключении между AP, т. к. продолжает усиленно стучаться к 2.4ГГц AP, видя более высокий RSSI с её стороны (маяки-то клиент как слышал, так и слышит, а значит знает о существовании более подходящей с его точки зрения AP с более высоким уровнем).

Ок, подумали в Meraki и решили расширить логику. А давайте, AP будут слушать все probe req для всех AP от клиента, а не только для себя, и на основании этих данных мы сможем достаточно достоверно определить (еще до подключения клиента), умеет ли клиент 5ГГц, и если умеет, то вообще не отвечать на probe этому клиенту в 2.4ГГц. Тем самым, заранее сможем определить куда пускать, а куда нет.

И это был прорыв… Подход сработал (ну почти), это позволило даже как-то сожительствовать band steering совместно с бесшовным роумингом и всё было прекрасно, пока…

Пока в один прекрасный день, параноики из Apple и Google не задумались о том, что ведь на основании прослушивания эфира можно отслеживать положение того или иного устройства по mac в probe. И просто начали рандомизировать MAC адреса в probe запросах.

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

Плюс, клиенты почти поголовно научились использовать фоновое сканирование, а там на стадии сканирования вообще никакие probe не шлются, а значит клиент в любом случае будет видеть оба диапазона, и “спрятаться” от него не выйдет. И опять-таки, в лоб сравнивая RSSI, будет пытаться соединиться в 2.4ГГц.

Хорошо, сказали Meraki, раз решить проблему теперь исключительно на уровне probe не удаётся, давайте будем, как последний барьер, использовать assoc/auth req. Да, это не решает проблем с задержками при подключении/миграции, но позволяет хотя бы большую часть клиентов насильно заставить соединиться в 5ГГц.

Вот на этом уровне реализация Band Steering остановилась.

Конечно существуют и расширенные реализации, которые например разрешают клиентам переключаться в 2.4ГГц при падении уровня (как в Wive) или могут насильно спинывать (слать DEAUTH что приведёт к обрыву связи и с определённой долей вероятности переключения клиента на другой диапазон) клиента с 5ГГц диапазона при падении уровня ниже порога (как у MTK), но основной смысл от этого не меняется.

По факту, применять Band Steering сейчас имеет смысл разве что на хотспотах, где не критично, что часть клиентов получит проблемы, и где нет возможности использовать разные SSID для разных диапазонов, заставляя административными мерами пользователей с dual band устройствами использовать 5ГГц.

Во всех остальных случаях (особенно, когда строится сеть для прозрачной миграции) от использования Band Steering следует отказаться.

Исходя из этого, если на клиенте нет возможность задать приоритетный диапазон – стоит воспользоваться вариантом с разными SSID для разных диапазонов. И в самом крайнем случае – Band Steering. А если вы строите сеть с прозрачной миграцией, и ключевым аспектом является именно миграция, то band steering строго противопоказан.

Можно конечно понизить мощность в 2.4ГГц настолько, чтобы уровень сигнала на клиентском устройстве в 2.4ГГц всегда был ниже 5ГГц, но в этом случае в реальном эфире (где в 2.4ГГц из-за соседей топор в воздухе зависает) рассчитывать на нормальную работу, особенно вне прямой видимости, не стоит.

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

Продолжение следует…

Первая часть. Третья часть.