Ekahau Sidekick и RSSI‑offset: физические ограничения метода и пять независимых причин неточности клиентской модели

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь

Mic Bell · 2026-05-24 · via Все публикации подряд на Хабре

Средний

11 мин

12K

Аннотация. В статье рассматривается физическая основа измерений Ekahau Sidekick и механизм применяемого RSSI‑offset с позиций теории антенн, теории шума радиоприёмных устройств, статистической теории сигналов и стандартов IEEE 802.11. Показано, что scalar RSSI‑offset является линейным сдвигом уровня и не моделирует ни реальный SNR клиентского устройства, ни структуру QAM‑созвездия, ни алгоритм rate adaptation, ни роуминговое поведение. Помимо пяти независимых физических и системных причин неточности, рассматриваются системные упрощения Ekahau, касающиеся MIMO‑усиления, многолучёвости, оценки airtime и визуализации SNR. Приведены верифицированные численные оценки погрешности для конкретных сценариев и практические рекомендации.

1. Введение

Ekahau Sidekick широко применяется в профессиональных Wi‑Fi‑обследованиях как основной измерительный инструмент. Sidekick 1 оснащён семью внутренними антеннами в оптимальной ориентации и двумя двухдиапазонными Wi‑Fi‑радио; Sidekick 2 — девятью кастомными широкополосными 3D‑антеннами и четырьмя трёхдиапазонными радио [1, 2]. Следствием этих преимуществ является систематически более высокий RSSI по сравнению с типичным клиентским устройством в той же точке пространства.

Для компенсации этого расхождения Ekahau реализует механизм device offset — эмпирического скалярного сдвига RSSI:

$\mathrm{RSSI}{\rm corr} = \mathrm{RSSI}{\rm raw} - \Delta \quad$ (1)

где $\Delta$ [dB] определяется пользователем на основе сравнительных измерений Sidekick и целевого клиентского устройства [3].

Важно сразу обозначить цель статьи: это не критика Ekahau как инструмента. Ekahau — профессиональное и широко признанное решение для Wi‑Fi‑обследований. Цель — показать, что именно упрощают разработчики Ekahau, где эти упрощения дают реальную измеримую погрешность, и как правильно интерпретировать результаты с учётом этих ограничений.

2. Физическая основа преимущества Sidekick: эффективная апертура и принятая мощность

2.1 Эффективная апертура антенны

Связь между физическими характеристиками антенны и принятой мощностью описывается через эффективную апертуру $A_{\rm eff}$ [м²]. Для антенны с коэффициентом усиления и рабочей длиной волны $\lambda$ :

$A_{\rm eff} = \frac{\lambda^2}{4\pi} G \quad$ (2)

При плотности потока мощности падающей волны [Вт/м²] принимаемая мощность:

$P_r = S_i \cdot A_{\rm eff} = S_i \cdot \frac{\lambda^2}{4\pi}G \quad$ (3)

2.2 Многолучёвая среда и угловой спектр мощности

В реальной среде с многолучёвостью сигнал приходит с непрерывного множества направлений. Угловое распределение мощности описывается угловым спектром мощности (Angular Power Spectrum, APS) $\mathcal{P}(\theta,\phi)$ [Вт/ср]. Принятая мощность для антенны с нормированной диаграммой направленности $D(\theta,\phi)$ :

$P_r = \int_{0}^{2\pi} \int_{0}^{\pi} \mathcal{P}(\theta,\phi) \frac{\lambda^2}{4\pi} D(\theta,\phi) \sin\theta d\theta d\phi \quad$ (4)

Sidekick с широкой и равномерной диаграммой направленности интегрирует мощность из большего телесного угла. При том же поле $\mathcal{P}(\theta,\phi)$ :

$P_r^{\rm (EK)} > P_r^{\rm (Phone)} \quad$ (5)

поскольку $D_{\rm EK}(\theta,\phi)$ более равномерна по сфере, чем $D_{\rm Phone}(\theta,\phi)$ — диаграмма смартфона с асимметричным расположением антенн.

3. От принятой мощности к SNR: роль шум‑фактора приёмного тракта

3.1 Шумовая модель приёмника

Мощность теплового шума на входе демодулятора в полосе $\Delta f$ [Гц]:

$N = k T_{\rm sys} \Delta f \quad$ (6)

где $k = 1.38\times10^{-23}$ Дж/К — постоянная Больцмана. Системная шумовая температура:

$T_{\rm sys} = T_{\rm ant} + T_{\rm receiver} = T_{\rm ant} + (F-1) T_0 \quad$ (7)

где— шум‑фактор (noise figure) приёмного тракта, = 290 К.

3.2 SNR на входе демодулятора

$\mathrm{SNR} = \frac{P_r}{N} = \frac{S_i\cdot\tfrac{\lambda^2}{4\pi} G}{k \bigl(T_{\rm ant}+(F-1) T_0\bigr) \Delta f} \quad$ (8)

Выражение (8) явно показывает, что SNR определяется совместно эффективной апертурой $A_{\rm eff}$ и шум‑фактором . Утверждение $\mathrm{SNR}_{\rm EK}>\mathrm{SNR}_{\rm Phone}$ справедливо лишь при сопоставимом обоих устройств. Если клиентский чипсет имеет меньший , разница в апертуре может быть частично скомпенсирована.

3.3 Почему RSSI‑offset не моделирует SNR

RSSI‑offset (1) сдвигает на константу $\Delta$ , но не изменяет — шумовой пол целевого устройства:

$\mathrm{SNR}_{\rm corr} = \frac{P_r^{\rm (EK)}-\Delta}{N^{\rm (EK)}} \neq \frac{P_r^{\rm (Phone)}}{N^{\rm (Phone)}} \quad$ (9)

поскольку $N^{\rm (EK)}\neq N^{\rm (Phone)}$ при различных и $T_{\rm ant}$ устройств. Таким образом, скорректированный RSSI не является оценкой SNR клиентского устройства.

4. От SNR к структуре QAM‑созвездия

4.1 Модель AWGN‑канала для поднесущей OFDM

Для одной поднесущей OFDM при подавленной межсимвольной интерференции стандартная модель AWGN‑канала:

$y_k = \sqrt{\mathrm{SNR}}\cdot x_k + n_k,\quad n_k\sim\mathcal{CN}(0,1) \quad$ (10)

где $x_k\in\mathcal{A}$ — символ из M-QAM алфавита $\mathcal{A}$ , — комплексный гауссовский шум.

4.2 Среднеквадратичное отклонение точек созвездия

СКО принятых символов от идеальных позиций решётки:

$\sigma_{\rm symbol} = \frac{1}{\sqrt{\mathrm{SNR}}} \quad$ (11)

Подставляя (8):

$\sigma_{\rm symbol} = \left(\frac{k T_{\rm sys} \Delta f}{S_i\cdot\tfrac{\lambda^2}{4\pi} G}\right)^{1/2} \quad$ (12)

Из (12) непосредственно следует $\sigma^{\rm(EK)}_{\rm symbol} < \sigma^{\rm(Phone)}_{\rm symbol}$ — созвездие QAM у Sidekick компактнее при одинаковом поле.

4.3 Вероятность ошибки символа

Для -QAM в канале AWGN вероятность ошибки символа (SER) [4]:

$P_s \approx 4 \left(1-\frac{1}{\sqrt{M}}\right)Q \left(\sqrt{\frac{3 \mathrm{SNR}}{M-1}}\right) \quad$ (13)

где $Q(\cdot)$ — Q‑функция. Поскольку scalar offset не восстанавливает реальный SNR клиентского устройства (9), он не позволяет корректно оценить — а следовательно, и реальное качество связи клиента в данной точке.

Оговорка. Модель AWGN (10) является приближением. В реальном Wi‑Fi‑канале остаточная МСИ, фазовые ошибки несущей и нелинейности усилителя вносят дополнительные искажения. Тем не менее AWGN‑модель корректна как качественный ориентир для сравнительного анализа.

5. Пять независимых причин неточности клиентской модели

Причина I. Sidekick — пассивный сенсор, не участвующий в rate adaptation

В режиме пассивного survey Sidekick работает исключительно в режиме прослушивания: декодирует беконы и кадры управления, измеряет RSSI и SNR, но не ассоциируется с точкой доступа [5].

Необходимо разграничить два режима работы Ekahau. При пассивном survey Sidekick слушает эфир без ассоциации с AP. При активном survey к Sidekick подключается реальное тестовое устройство — телефон или ноутбук — которое ассоциируется с AP и генерирует трафик; Ekahau при этом способен визуализировать, с какой AP был ассоциирован клиент в каждой точке маршрута. То есть роуминг конкретного тестового устройства Ekahau показать умеет.

Ключевое ограничение: это всегда роуминг того устройства, с которым проводился survey. Алгоритм rate adaptation (Minstrel, Intel Wireless Adaptation Technology, Qualcomm‑специфичные реализации) специфичен для каждого вендора и не моделируется Ekahau обобщённо. Для другого клиента — с другим чипсетом и прошивкой — данные неприменимы напрямую.

Причина II. Нелинейность разницы RSSI между устройствами

Разница показаний RSSI между двумя устройствами нелинейна по уровню сигнала [6]. На уровне −45 dBm два устройства могут отличаться на 2 dB; на −60 dBm — на 4 dB; на −80 dBm — на 10 dB.

Пусть истинная разница является функцией уровня: $\delta(\mathrm{RSSI})$ . Тогда scalar offset $\Delta=\mathbb{E}[\delta]$ — математическое ожидание, усреднённое по диапазону, использованному при измерении. Систематическая погрешность в произвольной точке:

$\varepsilon(\mathrm{RSSI}) = \delta(\mathrm{RSSI}) - \Delta \quad$ (14)

При типичной нелинейности $\delta(\cdot)$ функция $\varepsilon(\cdot)$ принимает значения от −2 до +8 dB через рабочий диапазон RSSI, что делает границу покрытия на скорректированной карте систематически смещённой.

Причина III. Ориентационная зависимость диаграммы направленности смартфона

Sidekick фиксирован в постоянной ориентации с квазиизотропной диаграммой направленности. Реальный смартфон удерживается пользователем в произвольной и постоянно меняющейся ориентации. Рука оператора является диэлектрическим экраном с $\varepsilon_r\approx50$ и $\sigma\approx1$ См/м, что вызывает значительное поглощение в ближней зоне антенны.

Экспериментальные исследования показывают, что ориентация смартфона и положение источника оказывают существенное влияние на точность RSSI‑измерений [7, 8]. На практике это приводит к вариации эффективного $G(\theta,\phi)$ смартфона в пределах 5–10 dB при изменении ориентации в одной точке пространства — эффект, принципиально не компенсируемый скалярным сдвигом $\Delta$ .

Причина IV. Различие noise figure между чипсетами: разный SNR при одинаковом RSSI

Из выражения (8) следует, что при одинаковом два устройства с различными шум‑факторами $F_1\neq F_2$ имеют различный SNR:

$\frac{\mathrm{SNR}1}{\mathrm{SNR}2} = \frac{T{\rm ant}+(F_2-1) T_0}{T{\rm ant}+(F_1-1) T_0} \quad$ (15)

Разница в noise figure между бюджетными и флагманскими чипсетами Wi‑Fi (Qualcomm FastConnect, MediaTek Dimensity, Apple W‑серия) составляет 3–5 dB. При дБ и $T_{\rm ant}\approx T_0$ отношение SNR из (15) составляет порядка 2 — то есть при одинаковом RSSI реальный SNR может отличаться вдвое. Scalar offset оперирует исключительно с и никак не учитывает целевого устройства.

Причина V. Роуминговое поведение: индивидуальные пороги переключения

Wi‑Fi‑инженеры знают с самых основ: роуминг происходит у разных клиентов при разных условиях. Ekahau позволяет настраивать расчётные зоны перекрытия ячеек, если характеристики целевого клиента известны заранее — но это расчётная модель, а не измерение поведения конкретного устройства.

По данным официальной документации Apple: iPhone и iPad удерживают соединение с текущей AP до достижения порога −70 dBm; Mac‑компьютеры используют порог −75 dBm [10]. Промышленные сканеры на базе Android с консервативными роуминговыми алгоритмами могут удерживать соединение значительно ниже порога роуминга смартфона — классический sticky client.

Следствие: даже с настроенными зонами перекрытия Ekahau не может предсказать роуминговое поведение устройства, с которым survey не проводился. Для верификации роуминга конкретного клиента необходим активный survey именно с этим устройством [9].

6. Системные упрощения Ekahau за пределами RSSI‑offset

6.1 MIMO‑усиление не моделируется

Реальная ёмкость канала при MIMO определяется ранговой структурой канальной матрицы $\mathbf{H}$ :

$C = \sum_{i=1}^{\min(N_t,N_r)}\log_2\left(1+\frac{\lambda_i^2\cdot P}{N\cdot N_t}\right) \quad$ (16)

где $\lambda_i$ — сингулярные числа матрицы $\mathbf{H}, N_t$ и — число передающих и принимающих антенн. Ekahau не моделирует ранг канала и не учитывает MIMO‑gain при построении тепловой карты покрытия.

6.2 Многолучёвость и переотражение не моделируются

Ekahau строит карту покрытия на основе модели распространения с затуханием через стены (attenuation-based model). Реальный канал формируется суперпозицией многолучёвых компонент, каждая из которых имеет свою задержку, фазу и амплитуду. В зонах с выраженной многолучёвостью реальный SNR на отдельных поднесущих может существенно отличаться от среднего в обе стороны — Ekahau этого не видит.

6.3 Оценка airtime ограничена точностью модели

Корректная оценка airtime требует учёта MCS каждого клиента, размера MPDU, механизмов агрегации A‑MPDU, overhead протокола и числа активных клиентов. Ekahau моделирует airtime на основе библиотек затухания и заданных параметров клиентского профиля; точность этой модели напрямую зависит от качества калибровки и полноты survey‑данных. В плотных сетях с высокой вариативностью MCS расчётные оценки airtime могут существенно отклоняться от реальных.

6.4 Визуализация SNR отражает шум Sidekick, а не шум клиента

Ekahau Sidekick измеряет шумовой пол через встроенный спектральный анализ. Однако отображаемый SNR отражает шумовую обстановку в точке расположения Sidekick, а не шумовой пол конкретного клиентского чипсета. Разница между ними определяется различием в noise figure устройств (7) и в насыщенных средах может составлять несколько децибел, систематически смещая отображаемый SNR относительно реального SNR клиентского устройства.

7. Масштаб реальной погрешности: верифицированные сценарии

Чтобы у читателя не сложилось впечатления «там опять разговор за 0.5 dB» — приведём конкретные числа, верифицированные по стандартным таблицам 802.11.

Сценарий A. Смещение границы покрытия при −78 dBm

При уровне −78 dBm типичная погрешность scalar offset из-за нелинейности составляет 6–8 dB (причина II). Градиент затухания зависит от типа среды: в открытом офисе типично 0.5–1 dB/м, в коридорах с перегородками — 1.5–3 dB/м.

При погрешности 6–8 dB и градиенте 1.5 dB/м линейное смещение границы покрытия на карте составляет 4–5 метров. При градиенте 3 dB/м — 2–3 метра. При типичном межэлементном расстоянии AP 10–20 метров такое смещение границы напрямую влияет на решения о количестве и расположении точек доступа.

Сценарий B. MCS и реальный throughput на границе покрытия

Рассмотрим клиента в канале 20 МГц (802.11ac, 1 пространственный поток). Пороги SNR и PHY rate по стандартизованной таблице 802.11ac [11]:

VHT MCS	Модуляция	Кодирование	Мин. SNR [dB]	PHY rate [Мбит/с]
MCS 5	64-QAM	2/3	18	52
MCS 6	64-QAM	3/4	20	58.5
MCS 7	64-QAM	5/6	25	65
MCS 8	256-QAM	3/4	29	78

Оговорка к таблице. Приведённые пороги SNR являются референсными значениями стандарта IEEE (PER < 10%). Реальные устройства с MRC‑обработкой нередко достигают тех же MCS при SNR на 3–6 dB ниже табличного. Тем не менее погрешность offset систематически смещает оценку MCS и реального throughput в предсказуемую сторону.

Если реальный SNR клиента составляет 23 dB, а погрешность offset даёт систематическое завышение на 3 dB, Ekahau покажет уровень с запасом выше порога MCS 7 (25 dB). Реальный же клиент работает на MCS 6 (20 dB ≤ SNR < 25 dB). При дополнительной деградации канала на 3 dB (тело человека, переотражение) клиент падает до MCS 5: ожидаемые по карте 65 Мбит/с против реальных 52 Мбит/с — снижение на 20%, систематическое и накапливающееся в плотных сетях.

Для 80 МГц канала или 2SS граница MCS 8/MCS 7 проходит при SNR 35/31 dB; PHY rate 390/292.5 Мбит/с — разница уже ~100 Мбит/с на поток при той же погрешности offset.

Сценарий C. Промышленный сканер в зоне перекрытия ячеек

Промышленный сканер со sticky client поведением удерживает соединение с AP1 до −85 dBm. Карта Sidekick показывает, что в данной точке уровень от AP2 составляет −65 dBm — достаточный для высокого MCS. Однако сканер не переключится на AP2, пока уровень от AP1 не упадёт до его порога роуминга.

В этой зоне сканер работает с AP1 на MCS 1–2 и получает реальный throughput в разы ниже ожидаемого по карте. Карта Sidekick покажет наличие покрытия и хороший SNR от AP2 — но не покажет, что клиент физически ассоциирован с AP1 и работает на деградировавшем MCS. Offset к этому сценарию отношения не имеет вовсе.

8. Формальные границы применимости RSSI‑offset

Scalar offset даёт приемлемую точность только при одновременном выполнении четырёх условий:

C1 (линейность диапазона). Offset $\Delta$ измерялся в диапазоне $[\mathrm{RSSI}_{\rm min},\mathrm{RSSI}_{\rm max}]$ , и рабочая зона обследования целиком находится в этом диапазоне: $\varepsilon(\mathrm{RSSI})\approx0$ .

C2 (сопоставимость NF). Шум‑факторы Sidekick и целевого устройства сопоставимы: $|F_{\rm EK}-F_{\rm Phone}|\ll1$ dB.

C3 (стабильность ориентации). Целевое устройство используется в фиксированной или детерминированной ориентации.

C4 (отсутствие критичного роуминга). Зона обследования не содержит областей перекрытия ячеек, критичных для поведения конкретного клиентского устройства.

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

9. Рекомендации по корректному применению

9.1 Измеряйте offset в диапазоне уровней, актуальном для вашей задачи. Если граница покрытия проходит при −70 dBm — измеряйте offset при −70 dBm, а не при −50 dBm вблизи AP. Это минимизирует $\varepsilon(\mathrm{RSSI}_{\rm target})$ из выражения (14).

9.2 Для критичных клиентов проводите активный survey с реальным устройством. Только так вы получите фактические данные о MCS, throughput и поведении при роуминге для конкретного чипсета и алгоритма rate adaptation.

9.3 Верифицируйте роуминг с целевым устройством. Прогулка по периметру зоны с мониторингом BSSID и MCS — единственный способ увидеть реальное роуминговое поведение клиента. Расчётные зоны перекрытия в Ekahau дают лишь приближение.

9.4 Учитывайте ориентационную зависимость для специфических устройств. Для устройств с выраженной ориентационной зависимостью (телефон у уха при VoIP, планшет горизонтально, сканер в рабочем положении) offset должен измеряться в рабочей ориентации целевого устройства.

9.5 Помните об ограничениях MIMO‑модели в специфических средах. В зонах с высокой пространственной корреляцией (длинные узкие коридоры, помещения с металлическими конструкциями) реальный MIMO rank может быть ниже расчётного.

10. Заключение

Ekahau — профессиональный и широко признанный инструмент, разработчики которого в ряде мест сознательно упрощают реальность ради практичности. Понимание этих упрощений позволяет использовать инструмент правильно.

RSSI‑offset (1) является линейным сдвигом уровня. Он не моделирует: реальный SNR клиентского устройства с его специфическим noise figure (причина IV); вероятность ошибки и достижимый MCS (уравнения 11–13); ориентационную зависимость диаграммы направленности смартфона (причина III); роуминговое поведение с индивидуальными порогами переключения (причина V); нелинейность разницы RSSI через динамический диапазон (причина II).

За пределами RSSI‑offset Ekahau не учитывает MIMO‑усиление, не моделирует многолучёвость, работает с ограниченной моделью airtime и отображает SNR Sidekick, а не SNR конкретного клиентского чипсета.

Масштаб погрешности — не академический:

На границе покрытия при −78 dBm смещение границы на карте составляет 2–5 метров в зависимости от градиента затухания среды.
Погрешность SNR в 3 dB на границе MCS 7 смещает клиента на MCS 6; при дальнейшей деградации — на MCS 5: падение с ожидаемых 65 до реальных 52 Мбит/с (−20%). В 80 МГц канале аналогичный переход даёт разницу ~100 Мбит/с на поток.
Промышленный sticky client в зоне перекрытия ячеек работает на MCS 1–2 там, где карта Sidekick показывает хорошее покрытие от соседней AP.

Ekahau как инструмент быстрой ориентации по покрытию при соблюдении условий C1–C4 остаётся практически ценным. Для задач, требующих точного предсказания поведения конкретного клиентского устройства, scalar offset должен дополняться активным survey с реальным целевым устройством — и пониманием того, что именно и почему упрощает инструмент.

Список литературы

Ekahau Sidekick Data Sheet. Ekahau Inc., 2020.
Ekahau Sidekick 2 Data Sheet. Ekahau Inc., 2023.
ToDSFromDS. Thoughts About Offsets in Ekahau Pro, 2019. todsfromds.com
Proakis J.G., Salehi M. Digital Communications, 5th ed. McGraw‑Hill, 2008. Ch. 6.
Wi‑Fi Vitae. Data Collected During an Active Survey, 2024. wifivitae.com
ToDSFromDS. A Deep Dive Into RF Offsets, 2023. todsfromds.com
Boussad et al. Evaluating Smartphone Accuracy for RSSI Measurements. IEEE Transactions on Instrumentation and Measurement, 2021.
Boussad et al. Evaluating Smartphone Accuracy for RSSI Measurements. INRIA HAL, 2020.
Mysteries of Client Roaming Revealed. 7SIGNAL Whitepaper, 2020.
Apple Inc. Wi‑Fi Roaming Support in Apple Devices. Apple Support HT203068, 2022.
802.11n/HT and 802.11ac/VHT MCS, SNR and RSSI Reference Table. WLAN Professionals, 2014.

Примечания к терминологии

«Промышленный сканер» — в контексте данной статьи собирательный термин, обозначающий любой корпоративный Wi‑Fi клиент с нестандартным роуминговым алгоритмом: терминал сбора данных (ТСД — Zebra, Honeywell, Datalogic), VoIP-трубка (Cisco, Spectralink), медицинское устройство, POS-терминал. Конкретный порог роуминга у каждого устройства индивидуален и нередко конфигурируется — цифра −85 dBm приведена как иллюстративный пример консервативного поведения, а не как типовое значение для всего класса устройств.

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

Все публикации подряд на Хабре

1. Введение

2. Физическая основа преимущества Sidekick: эффективная апертура и принятая мощность

2.1 Эффективная апертура антенны

2.2 Многолучёвая среда и угловой спектр мощности

3. От принятой мощности к SNR: роль шум‑фактора приёмного тракта

3.1 Шумовая модель приёмника

3.2 SNR на входе демодулятора

3.3 Почему RSSI‑offset не моделирует SNR

4. От SNR к структуре QAM‑созвездия

4.1 Модель AWGN‑канала для поднесущей OFDM

4.2 Среднеквадратичное отклонение точек созвездия

4.3 Вероятность ошибки символа

5. Пять независимых причин неточности клиентской модели

Причина I. Sidekick — пассивный сенсор, не участвующий в rate adaptation

Причина II. Нелинейность разницы RSSI между устройствами

Причина III. Ориентационная зависимость диаграммы направленности смартфона

Причина IV. Различие noise figure между чипсетами: разный SNR при одинаковом RSSI

Причина V. Роуминговое поведение: индивидуальные пороги переключения

6. Системные упрощения Ekahau за пределами RSSI‑offset

6.1 MIMO‑усиление не моделируется

6.2 Многолучёвость и переотражение не моделируются

6.3 Оценка airtime ограничена точностью модели

6.4 Визуализация SNR отражает шум Sidekick, а не шум клиента

7. Масштаб реальной погрешности: верифицированные сценарии

Сценарий A. Смещение границы покрытия при −78 dBm

Сценарий B. MCS и реальный throughput на границе покрытия

Сценарий C. Промышленный сканер в зоне перекрытия ячеек

8. Формальные границы применимости RSSI‑offset

9. Рекомендации по корректному применению

10. Заключение

Список литературы

Примечания к терминологии