Да здравствует Wi-Fi позиционирование в Enterprise
Wi-Fi позиционирование не работает вообще? Совсем нет!
Мои коллеги после прочтения предыдущей статьи «Почему не взлетает позиционирование на основе Wi-Fi» решили, что оно вообще не работает и с ним не стоит связываться. Это совершенно не так!
В этой статье я хочу рассказать, как работает позиционирования в условиях собственной корпоративной Wi-Fi сети, которая построена по требованиям передачи данных и голоса (но не для позиционирования).
Wi-Fi позиционирование «до комнаты»
Да, Wi-Fi не так уж и хорошо приспособлена к позиционированию: многочисленные переотражения, помехи и многое другое. А когда начинаешь добавлять инструменты, повышающие точность, ценник начинает стремительно расти!
Но, допустим, Wi-Fi у Заказчика уже есть, он не готов тратиться на отдельную инфраструктуру для сервиса позиционирования (расставлять отдельные сенсоры, раздавать метки) и даже не хочет модернизировать существующую Wi-Fi сеть, предназначенную для передачи данных (увеличивать количество точек доступа (далее ТД), расставлять их по периметру, ставить модули мониторинга).
На что Заказчик может рассчитывать? С высокой долей вероятности он может рассчитывать на точность «до комнаты». Под точностью «до комнаты» в данном случае я понимаю диапазон в пределах 10 метров.
Увеличить точность позиционирования возможно, но потребует усилий и денег (что, впрочем, не всех останавливает).
Да здравствует Wi-Fi позиционирование в Enterprise!
Кому вообще может понадобиться Wi-Fi позиционирование с точностью «до комнаты»? Может быть это только игрушка администратора? Этой точности недостаточно для работы с уведомлениями, всплывающими на смартфоне при пересечении виртуальной границы.
Моё мнение, что основной драйвер покупки Wi-Fi позиционирования «до комнаты» — это работа в связке с беспроводной системой обнаружения и предотвращения вторжений (wIPS) либо в связке с системой мониторинга.
Для системы wIPS этот сервис, я считаю, необходим и, по-хорошему, должен являться её составной частью (что чаще всего и встречается). Для системы мониторинга это так же достаточно важный сервис, помогающий получить представление о местоположении помех, количестве и местонахождении своих и сторонних клиентов, в частности, для устранения неисправностей.
В связи с этим я считаю, что наряду с системой мониторинга и wIPS в любой Wi-Fi сети корпоративного класса должен присутствовать сервис позиционирования.
Это нам надо раскошелиться на Cisco Hyperlocation или другие дорогие решения?
Перед тем, как переходить к анализу сложных и дорогостоящих решений, типа Cisco Hyperlocation, стоит оценить, как работает стандартное Wi-Fi позиционирование. Под «стандартным» в данном случае я понимаю самый распространенный вариант: когда берут обычную Wi-Fi сеть для передачи данных (и/или голоса) и добавляют один недорогой сервер для просчета позиционирования (без добавления модулей мониторинга, антенн, перемещения точек).
Самый лучший стенд — это собственная корпоративная сеть!
Подумал я и «накатил» сервис позиционирования на свою собственную корпоративную сеть. Сеть строилась по требованиям передачи данных и голоса, но не позиционирования. Пилотной зоной я выбрал часть второго этажа. Ниже представлен план помещения пилотной зоны с нанесенными точками доступа и размерами помещений.
Оборудование существующей беспроводной сети:
— контроллер беспроводного доступа Cisco WLC 2504 (далее WLC), версия ПО 8.0.132.0;
— офисные точки доступа без дополнительных модулей 802.11a/b/g/n MIMO 3×4 Cisco Aironet 3602I-R-K9 со встроенными антеннами;
— система управления Cisco Prime Infrastructure, версия ПО 3.0.0.0.78 с PI 3.0.3 Update 01 (далее PI).
Что было дополнительно установлено для того, чтобы появился сервис позиционирования:
— Cisco CMX, версия ПО 10.2.2–339 (далее CMX).
Насколько наша сеть «обычная»
«Обычная Wi-Fi сеть» — понятие растяжимое. Поэтому я покажу (не без гордости) результаты проведенного радиообследования в пилотной зоне, а вы уже будете решать, насколько оно приемлемо. Измерения проводились в обоих диапазонах (2.4ГГц и 5ГГц) по уровню в -67dBm и SNR 25. Ниже приведу рисунок одного замера в диапазоне 5ГГц с границей по уровню -67dBm.
На нагруженной сети тест производительности (с помощью программы iperf) показал порядка 50–80Мбит/с в диапазоне 5ГГц в середине рабочего дня под большой нагрузкой.
Настройки CMX
Так как планы помещений вместе с расположением точек доступа уже были заведены в PI, то мне нужно было только развернуть виртуальную машину CMX и импортировать в него карты вместе с расположением ТД и данными о затухании стен.
Со стенами есть небольшой нюанс. Импортируются только толстые стены (heavy walls, они же thick walls, 13dB). Я прорисовал толстые стены только по периметру здания, так как в нашем офисе все стены внутри здания не подпадают под определение «толстые».
Можно еще указывать жестко зону, где могут и где не могут находиться клиенты (для того, чтобы исключить клиентов в воздухе за окном второго этажа к примеру, кроме того это может существенно улучшить точность, как в моём случае), но я решил этого не делать, чтобы оценить, как CMX отработает в этой ситуации толстые стены, прорисованные по периметру.
Чтобы ограничить количество отображаемых устройств, я настроил фильтр:
— Отображаются только подключенные устройства (то есть сторонние клиенты вообще не отображаются);
— Отображаются только устройства с уровнем сигнала -85dBm и более.
—
Для тестов я оставил отображение интерференции и меток.
Стендовые испытания
Измерение точности позиционирования
В PI есть такой любопытный инструмент (Inspect Location Readiness), который достаточно прямолинейно, без каких либо измерений, отображает зону, «готовую» для позиционирования. Выглядит она примерно так:
Понятно, что эту информацию можно только принимать к сведению, но основываться на ней нельзя. В CMX есть встроенная функция измерения точности позиционирования (location accuracy test), которая уже замеряет фактическую точность позиционирования: на плане помещения указывается реальное место беспроводного Wi-Fi клиента (далее Клиент) и CMX документирует данные собственных замеров, высчитывает точность. Для измерения точности позиционирования я использовал собственный смартфон. Я заранее выбрал около 5 точек в пилотной зоне (за пределами периметра ТД, между ТД, в коридоре и т.д.). В каждой точке я добивался, чтобы CMX сделал не менее пяти замеров. Ниже результат, который я получил для пилотной зоны:
Основные моменты:
— Точность позиционирования во всех точках была в пределах 10 метров (в 99,2% случаев);
— Средняя точность позиционирования — 4.21 метра;
— Точность позиционирования в 50% случаев составляла до 3.85 метра.
Можно попробовать сравнить эти результаты с официальным руководством Cisco по Wi-Fi позиционированию:
— Accuracy of less than or equal to 10 meters, with 90 percent precision
— Accuracy of less than or equal to 5 meters, with 50 percent precision
Точность позиционирования укладывается в обозначенные рамки, при чем не только по периметру ТД, но и по периметру всей пилотной зоны и это очень хорошо. При этом точки расставлялись без учета требований по позиционированию!
Я связываю такие результаты в частности с удачной конфигурацией здания: длинное узкое здание, по периметру которого проходит толстая стена, не позволяющая Клиентам сильно «вываливаться» за его пределы.
Но все оказалось не настолько радужно.
Совсем немного о частоте обновления позиции
Еще до тестов я обнаружил, что мой смартфон намного чаще некоторых других устройств обновляет свою позицию в CMX. Для того, чтобы разобраться, почему так происходит, я исследовал трафик от смартфона и от других Клиентов. Как выяснилось, мой смартфон делал активное сканирование определенных SSID посредством probe request. Эти запросы посылались последовательно на все каналы, что приводило к тому, что на всех ТД была актуальная информация о мощности (RSSI) сигнала смартфона. Как я в дальнейшем выяснил, это стандартный алгоритм работы активных меток Wi-Fi (они просыпаются, посылают последовательно на все каналы запросы и засыпают). Но в данном случае это были просто забитые вручную профили беспроводных сетей, которые я удалил перед проведением тестов.
Это привело к следующему результату:
— Если смартфон находился на одном месте и не генерировал активно трафик, то его местоположение обновлялось очень редко: в CMX есть такой параметр, как «last seen», то есть когда последний раз Клиент был виден, так вот, он доходил у меня до нескольких минут (в пределах 5 — 10 минут).
— Когда на смартфоне были забиты профили SSID, производящие активное сканирование, этот параметр был в пределах 10 — 15 секунд.
— Если я начинал активно генерировать трафик, то параметр «last seen» так же был в пределах 10–15 секунд.
— Если же я перемещался от точки до точки, то результат был несколько иной. Позиция обновлялась, но точность этой позиции была намного меньше заявленной. Связано, я думаю, это было с тем, что замер RSSI обновлялся только для определенной ТД, а позицию надо было обновлять, но так как данных о RSSI было собрано недостаточно, точность была намного хуже.
—
Более подробно данный эффект я хочу рассмотреть в отдельной статье, которая будет посвящена частоте обновления позиции.
Измерение точности позиционирования при перемещении
Система позиционирования не только отображает текущее местонахождение, но также может показать историю перемещения за день (client movement history playback), что может быть полезно при устранении неисправностей и расследовании инцидентов.
Но в нашем случае я буду использовать этот инструмент для других целей, а именно оценки точности позиционировании при перемещении.
Чтобы быть максимально беспристрастным, я не стал ходить какими-то специальными кругами по офису, а просто взял историю своего перемещения со смартфоном за день.
Вот так выглядит план второго этажа с нанесенными клиентами. Синими кружками отображены ТД, внутри кружков — количество авторизованных Клиентов. Зеленые точки — это Клиенты.
В системе очень удобный поиск Клиентов. Клиента можно любым символам MAC адреса, имени пользователя, SSID. Фильтрация идет автоматическая по каждому введенному символу. Свой смартфон я нашел с трех букв.
Моя позиция указана достаточно точно, я нахожусь в левом отсеке А-03 (а не во втором отсеке, как показано). Ширина отсека — 5 метров, так что точность вполне ничего. Если навести курсор на Клиента, то схематически отображается, на каких ТД есть замер RSSI (который принимается во внимание).
После того, как Клиент выбран, можно переходить к истории перемещений.
Что сразу интересно: время подключение 9.31 — это время прихода в офис (можно отследить время прихода!), точность позиционирования в это время была даже лучше (левый отсек А-03). В районе 10 часов я пошел в район комнаты B-32. И вот тут начинается самое удивительное: на карте это отображено как довольно хаотичное перемещение Клиента:
Хоть и общее направление перемещения угадывается, но я перемещался явно не по периметру здания. Связан такой эффект, как я полагаю, как раз с тем, что я описал чуть ранее: замер RSSI обнавляется только на определенной ТД (к которой идет роуминг), CMX вынуждена обновлять позицию, но точность её крайне мала. Вероятно, CMX вытолкнул бы Клиента за пределы здания, если бы не прорисованные толстые стены, в которых «увязает» Клиент (а если не прорисовывать стены, надо обязательно прорисовывать регионы позиционирования). Как смягчающее обстоятельство можно взять во внимание то, что в отсеке «В» покрытие хуже и, следовательно, позиционирование тоже. А какие результаты в пилотной зоне? Далее я вернулся в комнату А-03. Потом в районе 12.30 я пошел к коллеге в зону А-16, тут можно было прикинуть как раз точность позиционирования в пилотной зоне.
В данном случае отображение прошло более четко, но на обратном пути меня все равно побросало по периметру. Я думаю это может быть связано как с активностью смартфона, так и с более плотным покрытием непосредственно в этом отсеке.
Любопытный факт: перемещение клиента не привязано к одному этажу, а объединяется между всеми помещениями. К примеру, я обнаружил, что в районе трех часов спустился на первый этаж (пошел обедать).
А еще система отображает различные помехи и метки
Есть еще такой приятный момент, отображаться могут не только Wi-Fi клиенты, но и помехи и метки (за счет встроенного в ТД анализатора спектра). В переговорной Альфа у нас стоит сейчас для демонстрации устройство на основе стандарта IEEE 802.15.4 (ZigBee). Система позиционирования его нашла, определила тип и даже с очень хорошей точностью отобразила его местоположение!
Это очень удобно для устранения неисправностей и исследования инцидентов. Мало кто занимается периодическим радиообследованием. А этот инструмент позволяет, не вставая с кресла, выявлять все помехи с точностью до комнаты и проводить с ними все необходимые мероприятия (легализовать, убирать и т.д.).
Общие выводы
Какие выводы можно сделать:
1. Точность позиционирования в Wi-Fi сетях, предназначенных под передачу данных/голос в общем случае будет находиться в пределах 10 метров в 90% замеров (точность «до комнаты»).
2. Вопрос точность позиционирования надо обязательно рассматривать в тандеме с вопросом частоты обновления позиций. Точность стационарного Клиента и точность перемещающегося Клиента могут сильно отличаться. То есть нужно понимать, как и с какой скоростью может перемещаться Клиент.
3. Нужно понимать, какой тип трафика и как часто должен (и может) генерировать требуемый Клиент.
А что дальше?
При подготовке данного материала я получил как ответы, так и новые вопросы, главный из которых — это частота обновления в Wi-Fi позиционировании. По этой причине в следующей статье постараюсь более детально рассмотреть этот вопрос.
Комментарии (2)
DeXPeriX
16 августа 2016 в 21:56
+1↑
↓
Какой алгоритм позиционирования использовали? Fingerprint?17 августа 2016 в 10:36
0↑
↓
Большое спасибо за вопрос. Я ведь для статьи копал в эту сторону и у меня даже есть что сказать, но, пока писал, этот момент я упустил. Я этот момент распишу тогда в следующей статье, тем более к следующей статье это так же имеет отношение.Cisco в своей прошлой версии позиционирования (до версии 8.0) использовало две технологии: триангуляцию и Fingerprint. Благодаря этому в частности до восьмой версии включительно был так же доступен механизм калибровки.
В новой версии (CMX 10) механизм калибровки отсутствует, я спрашивал у консультанта Cisco, ответ был такой, что это потому что технология Fingerprint теперь не используется. К сожалению, документация по 10-й версии пока не такая подробная. Поэтому я пока делаю вывод, что в 10-й версии используется только триангуляция.
Почему отказались от Fingerprint открыто не объясняется. Я подозреваю, либо потому что не сделали (так как 10-я версия — это полностью новый продукт), либо потому что проявились какие-то тяжелорешаемые проблемы. Мне было бы самому интересно узнать ответ на этот вопрос.
