Универсальное ТЗ для Wi-Fi, с пояснениями

ТЗ должно быть простым, понятным и проверяемым.

Вы такое видели?

Каких только ТЗ я не встречал за 12 лет в этой теме. Классические пункты — это “бесшовный роуминг” и “устойчивое 100% покрытие всей площади”. Понятно, что все мы хотим прекрасной связи. Какими же словами описать то, что мы хотим, чтобы это можно было адекватно проверить?

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

Как в значке Wi-Fi три изогнутых линии, основных пунктов тоже будет три.

Тем, кто так или иначе связан с Enterprise Wi-Fi и не только, будет интересно.

Почему уклон в Enterprise или корпоративный Wi-Fi?
Потому что для SOHO ТЗ не нужно, там всё проще.
Чаще в SOHO 1 простое правило: 1 точка доступа 1 стена.
Ставьте точки так, чтобы до клиента было не больше 1 стены.

Если мыслить масштабами ГОСТ 34, то речь пойдет про пункт 4: Требования к системе.
Системой в нашем случае будет беспроводная сеть передачи данных (БСПД), строящаяся на базе оборудования, работающего согласно стандарту IEEE 802.11-2016.

Итак, мы задумали построить беспроводную сеть. Что же мы можем от неё требовать?

Обеспечивать уровень принимаемого сигнала на всех типах приёмных устройств, перечисленных в таблице 1, не менее -67 дБм на всей площади объекта

В народе это называется радиопокрытие. Это самый важный параметр. Заказчики всегда хотят 100% покрытие, но далеко не все понимают, что разница на приёме устройств, которые присутствуют в их зоопарке, может быть больше 20 дБ! (надеюсь, читающие знают, что такое дБ). Также, не все понимают, что за каждый дБ этого параметра они платят деньги, причем немалые.

Важный момент:

Без привязки к конкретным клиентским устройствам можно построить:
1) хороший Wi-Fi, но доказать, что он не соответствует требованиям ТЗ.
2) плохой Wi-Fi и доказать, что он соответствует ТЗ.

Что делать? Обязательно учитывать какие устройства будут работать в сети.

Примеры

Университет. Его IT команда не может сказать, что принесут студенты. Самым правильным в этом случае будет найти least capable but most important (с самой низкой чувствительностью, но важное) устройство и взять его за основу. Иногда (когда мне говорят, что мы всё равно не знаем) я предлагаю взять за основу мой смартфон Samsung S8, средняя разница уровня сигнала на приеме S8 и эталонного измерительного модуля Sidekick равна 15 дБ (на частоте 5 ГГц), чтобы нам было от чего оттолкнуться.

Завод. В его цехах работает весьма ограниченное число устройств, например чувствительные ТСД Zebra TC720L, которые “слышат” сеть всего на 9 дБ хуже эталонного Sidekick. В таком случае нужно привязываться к реальным устройствам. Что будет, если внезапно, уже после построения сети заказчик решит, что вместо Zebra будет Casio? Будет разница в 9 дБ. К чему это приведёт? К тому, что эффективная скорость передачи данных на Casio будет существенно ниже, особенно на границе соты, где на Зебре бы было -67 дБм, а на Casio будет -76 дБм. Насколько это критично? Зависит от числа устройств и их трафика.

Медицинская клиника, где все доктора ходят с Wi-Fi телефонами Cisco 8821 и именно его можно считать за основное устройство, для которого мы строим сеть по всем “Design Guide” производителя и пытаемся обеспечить -65 дБм на приёме. Кстати, это хорошая цифра, так как в тех же областях, где 8821 телефон будет слышать сеть на -65 дБм, на моём Samsung S8 будет уже -72 дБм (в среднем), а то и -78 дБм (например, на канале 44)!

График с уровнем приема сигнала на разных частотных каналах выглядит так:

Ну и что вы теперь скажете про -67 дБм? На канале 36 и 161 это будут разные децибелы! Как же тут писать ТЗ, и как проверять? Нужно брать точный, но усредненный показатель по всем каналам и учитывать (в уме) возможные несоответствия. Прошу вас, не говорите в комментариях про разницу на приёме между одним и тем же типом устройств, с одним и тем же драйвером! Да, это есть, но если начать учитывать и это, можно умом тронуться! Заходите на RSSIcompared, сравнивайте, думайте, но на вашем объекте делайте измерения для ваших устройств.

Я надеюсь, вы поняли, что без измерений не обойтись, хотя многие любят и делают моделирование сферического коня в вакууме для нужд пресейла. Стоит ли строить сети по такой “модели”? На мой взгляд нет, ибо результат может быть печальным. Если заказчик настаивает, что ему достаточно модели, и денег на измерения нет, я поясняю ему возможные последствия и в договоре появляется такой пункт: Заказчик понимает, что моделирование без предварительного радиообследования не может гарантировать точный результат и является оценочным методом для определения количества точек доступа. Также, можно написать что-то подобное: Риски, связанные с неточностью теоретического метода определения затухания радиосигнала на стенах, заказчик берёт на себя. Суть же в том, что я не могу дать совершенно никаких гарантий, что построенная по абстрактной модели сеть заработает как надо.

Если заказчик продолжает настаивать на том, что модели достаточно, покажите ему это создание, и спросите: «Ничего, если получится что-то такое? Вам же с ним потом лет 10 жить!»

Чем проводить измерения уровня сигнала и как? В апреле этого года я описывал свой основной инструмент для построения Wi-Fi сетей – Ekahau Pro. Моё профессиональное инженерное мнение — Ekahau делает лучший на текущий момент софт и измерительные модули. Вес этому мнению может добавить моя загадочная цифра CWNE #364, но решать и сравнивать вам самим.

Чтобы быть уверенными в этих -67 дБм на приёме, нужно 3 измерения

1. Сравнение реальных устройств с эталонным измерительным адаптером.

Измерения проводим на всех рабочих каналах (выше я объяснил почему).

Уровень сигнала на Sidekick я смотрю в Ekahau, уровни на Android устройствах Aruba Utilities, на Windows устройствах WinFi, а на специфичных ТСД или Wi-Fi телефонах – встроенными средствами.

2. Предварительное радиообследование AP-on-stick на типовых участках.

Не стоит измерять весь объект с точкой-на-палочке, применяйте здравый смысл. Как и в жизни тут нужен баланс, который берется из опыта.

После измерений 1 и 2 можно делать достаточно точную модель сети, которая учитывает как реальные клиентские устройства, так и реальные стены. Без измерений, ваш Wi-Fi это игра в подбрасывание монетки.

Некоторые заказчики любят проводить тендер в условиях, когда измерения 1 и 2 не выполнены. Что же остается интеграторам? Предлагать сферического коня! Ибо сказать наверняка, что вот в это здание нужно ровно 303 точки доступа, можно только после проведения хорошей предварительной работы. Иначе, все делают запас (чаще) и потом заказчик платит за 303 точки (бюджет то уже согласован!). Плюсом идут все лицензии и поддержки, что в итоге даёт круглую сумму! А можно было бы поставить 240 точек, решить задачу и хорошо сэкономить! Если бы была пословица про Wi-Fi, то вот она: 2 раза замерь, один раз спроектируй.

Летом этого года я был в Хельсинки, в офисе Ekahau. Я беседовал с ними и о технической части и о ценах. Мне казалось, что Ekahau это достаточно дорогой софт. Юсси сказал мне:

«Смотри, как мы изначально мыслили, средний Enterprise Wi-Fi это сеть на 100 точек доступа. К ним идут пара контролеров с лицензиями на точки и система управления/мониторинга. Ekahau стоит примерно 5% цены этого набора. Он позволяет поставить именно столько точек, сколько нужно. Ты считаешь это дорого?»

Иногда бывает так, что всего не предусмотреть. Например, в той самой клинике, где после постройки здания я пару раз проводил частичное радиообследование для уточнения модели (которая была, как мне казалось, с запасом) в некоторые лаборатории поставили железные шкафы в полную высоту, в результате сигнал упал до -73 дБм в местах за шкафами. Мог ли я это предусмотреть? Нет. Как я буду действовать в будущем? Закладывать резервную СКС в сомнительные места, ведь проще докупить несколько точек с лицензиями к ним, чем после финишной отделки тянуть витую пару.

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

3. Радиообследование в процессе ПНР и финальное, отчетное радиообследование.

Это измерение проверяет результат работ и обычно указывается в ПМИ.

Чем же проводить измерение? Я пользуюсь Ekahau Pro + Sidekick. Почему? Это даёт самые точные показатели. Недавно, ребята из Ekahau проводили исследование точности и тестировали типовые адаптеры (старичок Proxim 8494 и бюджетный Comfast CF-912AC).

Результаты можно посмотреть тут. Тем, кто не хочет оставлять свой mail, вот pdf в облачке.

Суть в том, что разброс показаний зависимости уровня сигнала на приеме от относительного положения устройства и точки доступа в Sidekick минимален. К тому же, все Sidekick калибруются, чтобы обеспечить разницу не более 2 дБ между разными модулями.
У меня в компании 2 Sidekick и, если я провел первичные замеры на одном, а в поле вышел инженер с другим, я уверен в результатах, как ни крути.

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

Я для себя проверил это так. Прошел пару раз по одному цеху c Sidekick и в большей части разница показаний была в пределах 1 дБ (это можно посмотреть по визуализации Difference in Signal Strength). Раньше я пользовался Proxim, потом тремя Comfast, и наблюдал большую разницу. Представьте, что вы протопали 29 км по зданию с пачкой ключей, открывая каждую дверь, и потом поняли, что данные, которые вы собрали, не точны! Каково?

Ну что, можно переходить к осмыслению следующего пункта ТЗ?

Обеспечивать уровень принимаемого сигнала на всех типах приёмных устройств, перечисленных в таблице 1, не менее -75 дБм на всей площади объекта от двух точек доступа*.

*Первой считается точка доступа, обеспечивающая наибольший уровень сигнала на приемном устройстве. Вторая точка доступа обеспечивает следующий по уровню сигнал.
Если заказчик не может спокойно спать, не включив слово роуминг в ТЗ, а этот роуминг весьма нужен для голосового трафика, то пункт может выглядеть вот так:

Обеспечивать техническую возможность быстрого (время переключения менее 50 мс) роуминга между точками доступа БСПД путем обеспечения радиопокрытия от двух точек доступа в каждой точке пространства площади объекта с уровнем сигнала на всех типах приёмных устройств, перечисленных в таблице 1 не менее -75 дБм и поддержкой протоколов IEEE 802.11k/r/v;

Пожалуйста, не пишите “бесшовный роуминг”!
Тот, кто читал Design или Deployment Guide и может быть даже учился на каких-либо курсах по Wi-Fi скажет: “А как же 30% перекрытия между соседними точками?!” Вот же, сама великая Cisco говорит в своем гайде к тому самому телефону 8821:

Signal
The cell edge should be designed to -67 dBm where there is a 20-30% overlap of adjacent access points at that signal level. This ensures that the Cisco Wireless IP Phone 8821 and 8821-EX always have adequate signal and can hold a signal long enough in order to roam seamlessly where signal based triggers are utilized vs. packet loss triggers.

Во всех таких гайдах одна проблема, они не говорят, как это измерить! Не, если нужен Wi-Fi на футбольном поле, мы ставим 2 точки доступа и циркулем рисуем уровни по -67 дБм и вот 30% пересечения этих окружностей будет то, что нам нужно! Это реальный кейс? Нет! В жизни у вас стены, много стен, диаграмма направленности антенны не идеальная окружность (а что уж говорить про направленные антенны)!

Единственный метод убедиться в том, что с роумингом будет все хорошо — это в каждой точке пространства, где эти клиенты бродят, сделать так, чтобы они слышали 2 точки доступа одновременно. При этом ваша сеть обеспечит условия для роуминга клиентских устройств, которые еще могут работать совсем не так, как от них ожидают. Если по-взрослому, то это уровень -67 дБм от второй точки, что выливается в такую плотность точек доступа, что не каждый бюджет выдержит! Поэтому есть компромисс, -75 дБм от второй точки доступа во всех областях и -67 дБм только в тех местах, где постоянно перемещаются, например коридоры.

Этим самым вы еще обеспечите реальную отказоустойчивость сети, ведь в случае отказа одной точки, уровня сигнала соседней будет достаточно для работы сети в аварийном режиме.
Или вы надеетесь на чудо-механизм Coverage Hole Detection, который повысит мощность на точке, в случае необходимости? Во-первых – этого запаса может не быть и повышать некуда. Во-вторых, он срабатывает по определенному триггеру, скажем, если точка слышит 5 клиентов с уровнем хуже порога. Да, она увеличит мощность на 3 дБ, но как быстро? Лучше на это не рассчитывать.

Про роуминг если кто хочет чуть глубже, советую вот с этой статьи разумного человека начать.

Ура, мы добрались до третьего пункта ТЗ!

Обеспечивать пересечение каналов по уровню -85 дБм в частотном диапазоне 5 ГГц не более одной точки доступа на канале, в диапазоне 2,4 ГГц не более трех точек доступа на канале

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

Почему -85 дБм? Это условно средний уровень, при котором клиентское устройство может декодировать преамбулу кадра, которая всегда идет на самой медленной модуляции. Если быть точнее, то уровень Signal Detect определяется уровнем шума и должен быть выше него на 5 дБ.
Или вы всё ещё думаете, что увеличив Basic Rate до 12 Mbps вы уменьшили размер соты?

Почему не более одной точки доступа на 5 ГГц? Потому, что в большинстве случаев 15-16 доступных в РФ каналов вам будет достаточно. При этом могут быть случаи, где у вас будет небольшое пересечение, но не больше 2х точек. В диапазоне 2.4ГГц вы прекрасно знаете, сколько каналов доступно. 3. Тут не разгуляться, в пространствах типа аэропортов может быть и 5, и 10 и 15 точек доступа на одной частоте, если проектировщик почему-то решил, что точки с всенаправленными антеннами — это лучший выбор для такой площадки.

Я надеюсь, вы понимаете, что 3 точки доступа на частоте значат то, что суммарная ёмкость вашей “соты” делится на 3 (грубо). Допустим, у вас 50 точек на складе и там 10 ТСД-шек работает. Если 5 точек на одном частотном канале и все клиенты в этой области, то ёмкости сети хватит. А если у вас 10 Wi-Fi телефонов на 1 точку садятся в среднем и будет пересечение с соседней, на том же частотном канале, то ёмкости запросто может не хватить. Видите, Wi-Fi строить это вам не гайки закручивать!

Возвращаясь к нашему ТЗ,

основных требований к Wi-Fi всего 3:

1. Обеспечивать уровень принимаемого сигнала на всех типах приёмных устройств, перечисленных в таблице 1, не менее -67 дБм на всей площади объекта
2. Обеспечивать уровень принимаемого сигнала на всех типах приёмных устройств, перечисленных в таблице 1, не менее -75 дБм на всей площади объекта от двух точек доступа
3. Обеспечивать пересечение каналов по уровню -85дБм в частотном диапазоне 5ГГц не более одной точки доступа на канале, в диапазоне 2,4ГГц не более трех точек доступа на канале

Числа в этих требованиях могут слегка меняться, в зависимости от задачи, но суть остается.

Есть еще 4-е требование, которое технически актуально, но адекватно проверять его крайне трудно.

4. Обеспечивать одновременное подключение не менее N беспроводных клиентских устройств, равномерно распределенных по площади объекта.

В идеале, рисуются области, где будут находиться эти пользователи. Выясняется, какой тип трафика будет преобладать (если есть рабочий пример, скажем офис, где активно используют Skype for Business с видео, то берется перехватчик и анализатор кадров, например Omnipeek или EyePA, ловится типовой видео разговор и становится понятна скорость, что нам реально нужна). Потом эти данные заводятся в Ekahau где мы теоретически проверяем, хватит ли ёмкости сети, при таких условиях. Если не хватает, даже когда покрытие от 2х точек по -67 дБм, то добавляются еще точки. При этом не забываем про важный пункт 3, пересечение каналов и балансируем на грани ёмкости/пересечения. А вот для проверки реальной вам нужны десятки устройств или какая-нибудь страшная кандела.

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

Ну вот и всё. Как говорит мой хороший знакомый Леонид Теканов, “Wi-Fi это просто!”
Трудно лишь учится. В обучении есть маленький секрет. Если вы учитесь у того, кто очень хорошо знает свой предмет, вы усваиваете материал намного легче! Поэтому выбирайте у кого и чему учится.

Приглашаю вас на учебный курс Ekahau Wi-Fi Design, который в РФ будет проводится впервые. Курс точно состоится. Несколько мест еще осталось. Подумайте хорошо и записывайтесь.

И напоследок, о наболевшем.

Маркетинг иногда любит наплести заказчикам про чудеса-чудесные, позиционирование точное, супер-безопасность и прочее. Ребята, пожалейте единорожку, не рассказывайте сказки!

Вместо того, чтобы поиграть с маленькой дочкой пару часов, инженер в письме объясняет ИТ-директору крупной компании, что то, что он написал в ТЗ, наслушавшись «Эффективных менеджеров» это чушь и она не заработает адекватно, так как условия не соблюсти на их конкретном объекте. Объяснять это надо мягко, сдержанно, а это требует времени! Пожалейте единорожку!

Буду рад интересным вопросам, которые помогут всем лучше понять тему.

Автор: nuearth

Источник