Одноканальная Архитектура

Одноканальная Архитектура сети стандарта Wi-Fi
Single Channel Architecture (SCA)

Одноканальная Архитектура (один частотный канал на сети Wi-Fi)

Мы много писали о Многоканальной Архитектуре на Wi-Life.ru (Multi Channel Architecture сети WiFi: MCA).  В принципе, практически все подходы и решения не только на нашем сайте, но и в индустрии в целом основаны именно на  технологии MCA. Ведущие вендоры WiFi-технологий разрабатывают MCA-решения, и большинство сетей WiFi построены именно на этой канальной архитектуре. Коммерческую разработку SCA-сетей ведут в основном Extricom и Meru, из которых в РФ, по нашим наблюдениям, частично представлен пока только первый вендор.

В данном модуле будет введена тема Одноканальной Архитектуры сети стандарта Wi-Fi (Single Channel Architecture: SCA). Впоследствии мы будем дополнять и расширять модуль.


SCA-архитектура в общем случае использует один частотный канал WiFi на всех точках доступа в зоне покрытия. Как расширение этой модели существуют решения, где так же растягивается группа непересекающихся частотных каналов WiFi. Фактически это выглядит как параллельные слои.

single channel architecture 

 

Точки с несколькими радиомодулями стандарта Wi-Fi под разные каналы в SCA неизбежно будут значительно более сложными и дорогими (не забываем, что в каждом канале необходимо независимо поддерживать как минимум 802.11n MIMO 2x2:2 или выше).

Если отбросить множество нюансов и деталей, то, вероятно, в качестве наиболее важной задачи, которую SCA решает лучше, чем MCA, можно назвать Мобильность. Точнее речь о выполнении хендоверов в сети Wi-Fi.  Давайте разберем отличия MCA от SCA для такого случая.

Сначала «неизбежное зло»: в архитектуре MCA всегда клиент выбирает, к какой точке доступа выполнить ассоциацию. Алгоритмы у всех производителей мобильных устройств разные. При этом обычно учитываются уровни сигнала от точек доступа на различных каналах, уровни потерь фреймов и т.д.. Производители смартфонов и планшетов с поддержкой радиомодуля стандарта WiFi нередко говорят, что у них свой "секретный соус" для реализации мобильности. Поэтому мы часто наблюдаем совершенно разные результаты при роуминге различных смартфонов на одной и той же сети Wi-Fi MCA. В отличие от MCA в SCA-сети клиент всегда думает, что куда бы он ни ходил, он всегда присоединен к одной и той же точке доступа Wi-Fi.

В архитектуре SCA постоянно в реальном времени отслеживаются состояния клиентов (уровни сигнала и т.п.). Сеть должна предельно точно координировать посылку фреймов как точками доступа вниз, так и клиентам вверх во всей зоне покрытия одновременно. Если на стороне сети возможно применение любых механизмов, то на клиентской все сложнее, т.к. сеть стандарта WiFi 802.11 не может полноценно управлять передачей от клиентов в сторону сети. Здесь один из наиболее очевидных механизмов состоит в использовании параметра NAV (Network Allocation Vector), который передается в каждом фрейме. NAV используется для “передергивания” back off таймеров на устройствах в сети. Один из подходов в сети SCA состоит в передаче длительного NAV с целью относительно долгосрочного “отключения” клиентских устройств от передачи. А затем “разрешать” им передавать в наиболее подходящие моменты времени. Такую модель IEEE не прорабатывал, поэтому не всегда результат является предсказуемым.


В случае MCA-архитектуры сети WiFi хендовер между точками доступа является очень сложной процедурой, которая в общем случае включает в себя такие аспекты как определение целевой точки доступа, переключение на новый частотный канал, выполнение аутентификации с новой точкой доступа (полный или ускоренный процесс в зависимости от реализации вендором).

При этом сеть WiFi SCA-архитектуры обычно проектируется так, чтобы клиенты не могли разделять различные точки доступа WiFi. Таким образом сама сеть формирует условия для выполнения хендоверов и сама ими управляет.
То же касается выполнение хендоверов при наличии текущей активной сессии с передачей данных. Контроллер сети должен определять, что у конкретного клиента возникло состояние, при котором его необходимо переассоциировать на другую точку доступа и сохранить сессию. При этом трафик на первой точке временно буферизуется и перенаправляется на вторую точку, как только закончен хендовер для клиента.

Возвращаясь к вопросу о клиентских мобильных устройствах в сети SCA надо отметить, что большинство таких устройств никогда не проектировалось для работы в сетях SCA. Это самые обычные смартфоны, планшеты, лаптопы и тп. Такая неспециализация под SCA нередко ведет к нестабильности их поведения, когда вокруг точки доступа с одним BSSID. Например, есть информациях о таких проблемах с Wi-Fi наборами Intel Centrino.

Также необходимо отметить, что учитывая наличие многочисленных источников интерференции, сеть SCA будет подвержена их воздействию значительно сильнее, чем сеть MCA. Особенно это касается частотной полосы WiFi 2.4GHz. О возможных источниках интерференции мы писали на Wi-Life.ru здесь. MCA может при наличии соответствующих механизмов достаточно просто и быстро перестраивать частотный план с учетом изменения локальной частотной обстановки, и всегда есть возможность последующей динамической адаптации. В то же время в SCA любые изменения в интерференционной картине неизбежно приведут к воздействию на всю зону покрытия (не забывайте, что Wi-Fi устройства «слушают» не только фреймы Wi-Fi, но и  изменения энергетического уровня в целевом частотном канале WiFi). А если используются разноканальные слои, то это влияет как минимум на целый слой.

Не пропускайте новости Wi-Fi, которые мы публикуем в Новостной Ленте.

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

Присоединяйтесь к нашей группе на Facebook: www.facebook.com/Wi.Life.ru
Мы публикуем интересные новости о Wi-Fi со всего света, информацию о выходе новых статей и расширении контента основных модулей ресурса Wi-Life.ru


Wi-Life.Team

Использование материалов сайта Wi-Life.ru разрешено только с согласия Wi-Life.ru и при наличии прямой ссылки на Wi-Life.ru.

blog comments powered by Disqus