Отправить запрос

Внимание! Если вам необходима техническая поддержка создайте заявку в автоматизированной системе

Через 5 секунд вы будете перенаправлены на страницу автоматизированной системы для создания обращения.

1/2 этап заполнения заявки

Выберите тип сотрудничества, чтобы продолжить

2/2 этап заполнения заявки На предыдущий этап

Прикрепить файлы (до 10Мб, до 10 файлов)

Отправляя свои данные я соглашаюсь с Политикой защиты и обработки персональных данных и даю Согласие на обработку персональных данных

О мифическом «бесшовном» роуминге

1. Цель документа

Почему роуминг “мифический”?

Почему слова “бесшовный” и “роуминг” в заглавии поставлены в кавычки?

Это же есть в сетях Wi-Fi!

Или нет?

Что под этим всем понимают Wi-Fi инженеры?

А что хотят видеть пользователи?

Как правильно писать техническое задание в этом аспекте?

И на что оно должно быть нацелено?

И кому адресовано?

Кратко разберем суть в этом документе.

Основные термины и сокращения

БЛВС — беспроводная локальная вычислительная сеть.

КУ — клиентское устройство.

ОСШ — отношение сигнал/шум.

ТД — точка доступа (access point), работающая под управлением контроллера.

ТЗ — техническое задание.

ПНР — пуско-наладочные работы.

2. Введение в проблему

Современное состояние отрасли телекоммуникаций по состоянию на 2026 год таково, что круг сталкивающихся с достаточно сложными инженерными задачами людей широк, а быть хорошим инженером с глубокими знаниями во всех областях телекоммуникаций, очевидно, невозможно. Кроме того, в любой проектной работе есть множество смежных с инженерным делом ролей, в рамках которых специалисты имеют дело с техническими описаниями, даташитами, техническими заданиями, программами и методиками испытаний и тому подобными документами. Поэтому регулярно возникает необходимость увязки разнообразных требований бизнеса с возможностями оборудования. Зачастую процесс проектирования при этом остается за скобками. Дополнительно это усложняется (не всегда добросовестной) конкуренцией между исполнителями, равно как и рисками недопонимания между разнообразными структурами внутри заказчика (например, между бизнесом и эксплуатацией). Отметим, что указанная картина в примерно равной степени характерна и для корпоративных, и для операторских инфраструктур.

Это не хорошо и не плохо – просто такова наша реальность.

В сетях, построенных по технологии семейства стандартов IEEE 802.11, данная картина еще более усугубляется тем, что данная технология использует разделяемую среду передачи, что многократно усложняет работу канального уровня по сравнению с интерфейсами проводного Ethernet. Отсюда следует важный вывод, который зачастую недооценивается всеми сторонами заинтересованными в запуске БЛВС:

В отличие от проводных инфраструктур, при разработке беспроводного решения требуется обоснование его работоспособности с точки зрения характеристик среды передачи.

Разумеется, при этом разработка любого проектного обоснования начинается с описания решаемой задачи. К большому сожалению, в настоящее время при постановке задачи построения беспроводных сетей стандарта IEEE 802.11 в технических заданиях и требованиях (на оборудование!) часто фигурируют понятия “бесшовного роуминга”, “бесшовной сети Wi-Fi”, “бесшовного mesh” и т. п. И давайте с ними разберемся.

Но сначала скажем пару слов о mesh.

3. Mesh в сетях Wi-Fi

Исторически под термином mesh в локальных вычислительных сетях понимается один из видов топологической организации сетевого взаимодействия, среди основных вариантов которых в конце XX века обычно в литературе назывались: шина (bus), звезда (star), двойная звезда, кольцо (ring), двойное кольцо, частично полносвязная (partial mesh) и полноcвязная (full mesh).

Когда же мы говорим о построении традиционной БЛВС, то в первую очередь имеем ввиду распределенную инфраструктуру, состоящую из точек доступа, каждая из которых имеет аплинк в виде проводного ethernet интерфейса, чаще всего – 1000/2500BaseT.

В противовес этому под архитектурой mesh в сетях Wi-Fi понимается способ построения распределенной Wi-Fi сети, содержащей точки доступа (ТД), у которых аплинком может быть беспроводной интерфейс. Такие ТД обычно называются Mesh Point, тогда как ТД с проводным аплинком являются Mesh Root.

Под Wi-Fi Mesh понимается способ организации взаимодействия между Mesh Point и Mesh Root.

На этом можно было бы и остановиться - скажет Wi-Fi инженер. Но мы здесь вынуждены отметить еще две в корне неверных интерпретации понятия Wi-Fi mesh, некорректное и неподходящее использование которых часто является камнем преткновения. А именно:

Под Wi-Fi Mesh неправильно понимается некий режим работы инфраструктуры БЛВС, при котором одна из ТД исполняет функции Wi-Fi контроллера.
Под Wi-Fi Mesh неправильно понимается некое условие пресловутой “бесшовности” радиопокрытия.

Причиной тому на наш взгляд является в первом случае – отсутствие устоявшейся терминологии для режима “ТД в роли контроллера” и обилие разнообразных проприетарных механизмов, решающих эту задачу. Во втором случае причиной является интуитивное отождествление “бесшовности” с динамическим взаимодействием точек доступа между собой в радиосреде.

Подытоживая этот раздел, можно сказать, что все три приведенные выше интерпретации (и корректная и обе неверных) в своей сути не являются взаимоисключающими, а скорее относятся друг к другу примерно, как “теплое, красное и мягкое”, описывая совершенно разные аспекты построения распределенных сетей Wi-Fi.

4. Термин “роуминг” в сетях Wi-Fi

Еще одно понятие, требующее внесения ясности, это “роуминг”.

Термин “роуминг” (от англ. to roam – “бродить“) исторически изначально использовался в мобильных сотовых сетях и описывал способ сетевого взаимодействия, при котором клиентское устройство регистрируется в “чужой сети”, а его пользовательский трафик обрабатывается по заранее определённым правилам (чаще всего – туннелируется в “свою” сеть). При этом процесс переключения клиентского устройства (КУ) между базовыми станциями одной сотовой сети называется хендовером (от англ. handover - “передача чего-либо”).

В сетях Wi-Fi, в противоположность сотовым сетям, организация роуминга в вышеназванном классическом смысле является достаточно редким событием и, во всяком случае, практически нереализуемым между решениями разных производителей.

Тем не менее, именно термин «roaming» де-факто используется в отрасли Wi-Fi, в том числе и в официальных документах. Если же взглянуть с точки зрения механизмов, его обеспечивающих, то можно выделить следующие его виды:

1. Inter-controller roaming, т.е. передача между собой перемещающегося КУ точками доступа различных Wi-Fi контроллеров с сохранением ассоциации с сетью. С позиции модели OSI это можно трактовать как L3-роуминг, т.к. различные контроллеры и их точки доступа чаще всего имеют между собой L3-связность.

2. Intra-controller roaming, т.е. передача между собой перемещающегося КУ между различными точками доступа, управляемыми одним и тем же Wi-Fi контроллером с сохранением ассоциации с сетью. Проводя аналогию, с позиции модели OSI это можно трактовать как L2-роуминг, т.к. здесь почти всегда имеет место (или хотя бы возможна) L2-связность.

3. Наконец, существуют достаточно редкие реализации, при которых клиентское устройство видит всю распределенную инфраструктуру из нескольких точек доступа как одну. В такой архитектуре КУ видит только одну ТД на L2. И в некотором смысле о мобильности клиентского устройства здесь можно говорить как об L1-роуминге. Такие решения не снискали особой популярности на текущем уровне развития технологии ввиду существенных ограничений в их применимости, тем не менее, в обсуждаемом аспекте о них не упомянуть нельзя.

Подытоживая, скажем, что первый и третий сценарии являются (хоть и по разным причинам) для сетей Wi-Fi очень редкими, а обычно имеющий на практике место второй сценарий чаще всего и называют роумингом, хотя намного корректнее использовать термин “хендовер”.

5. Возможные трактовки “бесшовности”

Укрупненно можно выделить три основных трактовки понятия “бесшовности”.

Прежде всего заказчика и пользователя интересует работа конкретного сервиса (приложения), которое должно отвечать требованиям его бизнес-задачи. Поэтому если, скажем, видеопоток не прервется при просмотре в момент хендовера клиента между точками доступа, то с позиции пользователя приложения такая сеть будет “бесшовной”. Очевидно, это достаточно “мягкий” пример приложения, т.к. видеопоток чаще всего кеширован на довольно продолжительное время. Более сложным для хендовера приложением будет являться, например, голосовой звонок. В этом случае – время, за которое клиентское устройство осуществляет хендовер, должно быть существенно короче для обеспечения “бесшовности” для пользователя приложения. В любом случае такой критерий мы отнесем к L7, т.е. к требованиям прикладного уровня.

Второй возможной трактовкой понятия “бесшовности”, с которой Wi-Fi инженер имеет дело намного чаще, – это проверка сетевой связностью. Т.е. условным критерием является примерное число icmp echo-запросов до какого-либо хоста, которые были потеряны и/или насколько менялась при этом задержка в процессе хендовера. Иными словами, мы здесь говорим о критерии, так или иначе связанным с протоколом IP, т.е. с сетевым уровнем (L3).

И здесь самое время остановиться и вспомнить, что Wi-Fi – это технология, работающая на L1-L2, а все остальные механизмы обеспечиваются соответствующими верхнеуровневыми протоколами. Т.е., строго говоря, обе вышеперечисленных трактовки не имеют к Wi-Fi на самом деле никакого прямого отношения, т.к. количество посторонних верхнеуровневых (т.е. на уровнях выше, чем Wi-Fi L2) факторов, влияющих на оба вышеперечисленных критерия, может быть очень и очень велико.

Возникает вполне резонный вопрос – а есть ли такой критерий, который бы определялся целиком и полностью работой механизмов, за которые несет ответственность технология Wi-Fi?

Разумеется, есть. Таким критерием может быть, например, факт хендовера без полной новой ассоциации с точкой доступа. В этом случае не тратится время на генерацию нового PMK-ключа, т.к. ключ кеширован. По задумке стандарта это должно обеспечиваться дополнением IEEE 802.11r (Fast Transition). Однако при попытке применить такой критерий на практике порой возникают серьезные сложности. Прежде всего, применимость механизмов кеширования ключа ограничена т.к. не все клиентские устройства работают в этом смысле корректно и иной раз лучшим решением может быть отключить его использование. Поведение КУ при различных режимах WPA2/WPA3 PSK/SAE-Enterprise также отличается. В таком случае критерием может быть время переключения, но его зафиксировать можно только применяя специализированные инструменты для захвата трафика в нескольких каналах одновременно. Эта задача дополнительно усложняется если на клиентском устройстве существенно ограничены возможности по отладке беспроводного интерфейса.

Любопытно, что клиентское устройство не всегда принимает решение осуществлять хендовер с кешированием ключа даже если инфраструктура БЛВС это поддерживает. А приложение не всегда на практике замечает даже относительно продолжительный хендовер (например, до 500 мс). Отметим также что, что хендовер без поддержки 802.11r, т.е. де факто полная переассоциация с новой точкой может быть на практике довольно быстрой и для PSK/SAE режимов занимать существенно менее 100 мс. Иными словами, вариантов много, и на практике, конечно, можно выбрать временной критерий для конкретного режима работы конкретного клиентского устройства – да так обычно и делают, но чаще всего только при отладке. Однако, как проектным критерием – таким подходом пользоваться на практике неудобно.

Дело еще и в том, что поддержка в инфраструктуре любого механизма в Wi-Fi, нацеленного на обеспечение “бесшовности” покрытия (того же IEEE 802.11r), во-первых, не гарантирует быстрый (с позиции L7) хендовер каждого отдельного клиентского устройства. А во-вторых, отсутствие этого же механизма не обязательно приведет к длительному процессу хендовера, и не обязательно приведет к существенному снижению QoE на L7.

Теперь давайте посмотрим на рассмотренные выше сценарии.

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

Это, разумеется, не отменяет того факта, что если можно выделить ключевое клиентское устройство, то параметры сети можно и нужно оптимизировать именно для него, что, разумеется, знают все Wi-Fi инженеры, занимающиеся проектированием инфраструктур БЛВС.

6. Так ЧЕМ же определяется “бесшовность”?

Прежде всего нужно отметить, что решение о хендовере принимает клиентское устройство. И список параметров, которые оно принимает во внимание при этом, – внушителен. Очевидно, здесь обязательно фигурирует имя SSID, уровень мощности принимаемого сигнала, индицируемое ОСШ, анонсы о смене канала точкой доступа, методы шифрования, статистика ошибок в канале, наборы поддерживаемых скоростных режимов, разнообразные недоступные пользователю внутренние черные/белые списки точек доступа, специфичные для производителя КУ эвристические алгоритмы и многое другое. Ну и, разумеется, такие «модные» дополнения стандарта как 802.11r, 802.11k, 802.11v.

В некоторых случаях настройки КУ доступны пользователю. В отдельных случаях возможен даже достаточно тонкий тюнинг. Но что же можно сделать на этапе проектного расчета?

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

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

А это задача в первую очередь проектанта!

7. Зафиксируем ключевые выводы

1. Критерий “бесшовности” задается в подавляющем большинстве случаев требованиями сервиса (т.е. приложения) и возможностями отдельного клиентского устройства (идеально – если его можно определить из формулировки бизнес-задачи).

2. Требование к “бесшовности” Wi-Fi сети – это требование к проектному решению целиком. Иными словами – это пример требования для задания на проектирование или на ПНР/ПМИ, но не для технического задания на оборудование.

3. Инфраструктура Wi-Fi может и должна по возможности обеспечивать поддержку различных дополнений стандарта, улучшающих работу клиентских устройств.

4. Поведение клиентских устройств может на практике вообще никак не зависеть от наличия или отсутствия поддержки в инфраструктуре тех или иных функций.

Автор:

Викулов А.С.

QTECH 2026 г.

Вид оборудования: Беспроводные сети и решения

Возврат к списку