Геолокация внутри помещений на основе BLE маячков (BLE beacons) в момент своего появления на рынке привлекла много внимания, в том числе и здесь, на Хабре. Было написано достаточно много хороших статей (на материал которых я буду периодически ссылаться), однако по мере накопления опыта практического применения и обнаружения подводных камней интерес к этой технологии несколько снизился. Типовые проблемы работы с BLE маячками (см. [4]) показали, что для эффективного использования BLE навигации требуется комплексное решение, включающее как маячки, так и качественно написанный софт. Пример такого решения от известного вендора сетевого оборудования и будет подвергнут анализу в данной статье. Заинтересовавшихся читателей приглашаю под кат.
Решение Aruba Meridian появилось около двух лет назад (см. [3]), однако его активное продвижение на отечественном рынке началось сравнительно недавно. От множества других решений для BLE навигации данный вариант отличается прежде всего интеграцией маячков, карт и приложения для смартфонов под единой управляющей платформой Meridian Editor в облаке (подробнее в [3]). Кроме того, разработка приложения максимально упрощена и может быть реализована в web-редакторе, без необходимости пользоваться SDK (в случаях, когда нет особых требований к кастомизации приложения). Наконец, возможно взаимодействие маячков с Wi-Fi от Aruba (при наличии в точках доступа BLE модуля). Всё вышеперечисленное сподвигло заказать демокомплект (Evaluation Kit) для проведения полноценного тестирования.
Рис. 1. Внешний вид маячка Aruba Beacons LS-BT-20.
Демокомплект представляет собой небольшую коробочку с пятью маячками (см. рис. 1, USB-устройство не является частью маячка) и лицензию для доступа к облаку Meridian сроком на 90 дней. Тестирование решения началось для нас с предоставления карты помещения для специалистов Aruba: загрузка карты напрямую в облако своими силами невозможна, требуется её предварительная обработка специалистами вендора. Важно отметить, что для каждого этажа здания требуется своя карта, подлежащая отдельному лицензированию.
После загрузки обработанной карты этажа в облако настала очередь конфигурации маячков. И здесь хотелось бы сделать большое отступление и поговорить о BLE навигации как таковой. Часть уважаемой аудитории наверняка представляет, хотя бы в общих чертах, как работает BLE навигация, однако не хотелось бы отсылать тех, кто с ней не знаком, в путешествие по просторам Интернета. А потому совершим техническо-исторически экскурс.
Стандарт BLE-Bluetooth Low Energy появился летом 2010 года, когда ряд наработок под общим названием Wibree был интегрирован в Core Specification стандарта Bluetooth версии 4.0. Первым массовым появлением BLE 4.0 на рынке стал выход IPhone 4S в 2011 году, а с 2012 года его поддержка быстро стала общепринятой. Устройства, поддерживающие стандарт BLE, могу работать в двух режимах: connecting mode и advertising mode [6]. Connecting mode представляет собой соединение точка-точка, тогда как advertising mode использует Generic Access Profile (GAP) для широковещательной отправки т.н. advertising packets, формат которых представлен ниже. BLE маячки, как правило, работают именно в режиме advertising mode.
Рисунок 2. Формат BLE advertising packet.
В чистом виде BLE advertising packet не применяются, они служат основой для построения различных реализаций стандарта (псевдо-стандартов). В настоящее время имеются три наиболее популярных реализации [5,7]:
- iBeacon – первый псевдо-стандарт, определяет только один тип advertising packet, отличающийся простой структурой. Разработан в 2013 году компанией Apple и полностью ей контролируется, нативно поддерживается в iOS.
- AltBeacon – разработан консорциумом Radius Networks, с момента появления позиционировался как открытый, доступный каждому и совместимый с любым устройством стандарт. Функционально схож с iBeacon.
- Eddystone – разработан Google, позиционируется как кросс-платформенный стандарт с открытым исходным кодом. Поддерживается как на Android, так и iOS устройствах. В отличии от остальных псевдо-стандартов определяет несколько типов advertising packet.
Далее нас будет интересовать iBeacon, поскольку именно он используется в решении от Aruba. При этом позиция вендора состоит в том, что решение Meridian, хоть и является реализацией iBeacon, не взаимодействует с iBeacon-совместимыми устройствами других производителей. Как уже было указано выше, iBeacon определяет единственный тип advertising packet, имеющий следующий формат (см. рис. 3) [6].
Рисунок 3. Структура iBeacon frame.
В данном фрейме наиболее интересны четыре поля:
- UUID уникальный идентификатор группы маячков. Задаётся производителем.
- Major number определяет некоторую группу (подсеть) маячков.
- Minor number определяет конкретный маячок в группе.
- TX Power показывает мощность сигнала на расстоянии одного метра от устройства. Значение в данном поле устанавливается при изготовлении и/или калибруется при конфигурации маячка.
Содержимое этих 4 полей непосредственно используется программной частью решения. «Слушающее» Bluetooth эфир приложение принимает фрейм, считывает UUID и Major/Minor номера, после чего обращается к облачной базе данных для поиска ассоциированной с указанными значениями информации о маячке. Значение в поле TX Power сравниваются с измеренным значением мощности принятого Bluetooth сигнала, что позволяет определить приближённое расстояние от маячка до смартфона.
Первоначальная настройка маячков Aruba производится при помощи специального приложения Beacons App, которое доступно только на iOS (издержки использования iBeacon). Необходимо «разбудить» маячок, физически разместить его в нужном месте, после чего привязать его к данной точке карты в приложении. UUID задан производителем, Major/Minor номера задаются при конфигурации, а TX Power зависит от режима функционирования маячка.
Маячки Aruba могут работать как в режиме навигации (Blue Dot), так и в режиме посылки уведомлений (Proximity). С точки зрения маячка изменение режима работы влияет только на TX Power, т.к. в режиме навигации оно остаётся на заданном производителем уровне (ниже будут показаны результаты его измерений), а в режиме уведомлений мощность можно настраивать, регулируя тем самым максимальный радиус приёма уведомлений.
Рис. 4. Интерфейс настройки маячков. Режим навигации и режим уведомлений.
 |
 |
Итогом настройки маячка служит запись в облачной базе данных Meridian, связывающая UUID, Major/Minor номера с картой помещения, координатами на ней и режимом работы маячка.
После настройки всех 5 маячков демокомплекта в режим навигации и расстановки на карте отметок (placemark) необходимо было собрать приложение для смартфона в том же Meridian Editor и сгенерировать ссылку для его скачивания, что заняло не более получаса. Первыми тестовыми устройствами стали IPhone 4S и IPhone 6S и на них навигация работала без проблем. Точка перемещалась по карте вслед за смартфоном, маршруты строились-в общем, решение делало именно то, что от него ожидалось.
Рис. 5. Пример режима навигации Blue Dot и построения маршрута.
Пришло время проверить работоспособность решения на Android устройствах. Были использованы Sony Z1 Compact, Samsung Galaxy S8, Xiaomi Mi 4c, Digma Optima — устройства разных ценовых диапазонов, возраста и возможностей. Результаты оказались достаточно неожиданными: качество навигации стало хуже по сравнению с IPhone обоих моделей, хоть и отличалось от модели к модели, более новые устройства справлялись лучше. Отмечу, что на тот момент мы не углублялись в нюансы работы маячков и ещё не знали, что в данном решении используется iBeacon. Именно зависимость качества навигации от используемого мобильного устройства сподвигла «копать глубже».
Возникла идея провести серию тестов на Z1 Compact и IPhone 4S для выяснения причины, по которой устройства взаимодействуют с маячками настолько по-разному. Во-первых, была измерена мощность принимаемого Bluetooth сигнала. В таблице 1 даны результаты измерений для одной из офисных локаций. Схожие данные были получены и в других местах: устройства принимали физический сигнал одинаково эффективно.
Таблица 1. Результаты измерений мощности принимаемого устройствами сигнала.
Стало ясно, что проблема связана не с физическим уровнем. Возникло предположение, что Android устройства не вполне корректно декодируют полученный сигнал. Соответственно, были установлены сторонние приложения для сканирования Bluetooth эфира: Beacon Scanner и nRF Connect. Результаты их использования приведены на рис. 6 и показывают, что в принципе устройство вполне способно декодировать iBeacon протокол, равно как и достаточно точно определять расстояние до маячков.
Рис. 6. Результаты декодирования принятого BLE сигнала в приложениях
Bluetooth Scanner и nRF Connect.
 |
  |
В попытке узнать что-то ещё полезное мы изучили трассу сигнального обмена смартфона с маячками в Wireshark (рис. 7). К сожалению, никаких дополнительных сведений это не дало.
Рис. 7. Трассировка сигнального обмена Sony Z1 Compact c маячками.
Обнаружилось, что Wireshark может декодировать iBeacon протокол, но в настоящее время некорректно определяет Major/Minor номера, а UUID получил прибавку в виде двух цифр в старших разрядах, по-видимому, из-за неверно заданных границ полей фрейма. Возможно представители сообщества, имеющие опыт тонкой подстройки Wireshark, подскажут, как скорректировать полученные результаты.
Комплекс проведённых тестов убедил нас в том, что в настоящий момент проблема разного качества навигации на устройствах с iOS и Android OS лежит прежде всего в плоскости софта и нюансов поддержки iBeacon протокола в Android. К похожим выводам пришло и официальное сообщество Aruba.
Триангуляция при использовании Meridian происходит непосредственно на устройстве [8], а соответственно существенно зависит как от софта Meridian, так и от драйверов для Bluetooth адаптера. Любые проблемы хотя бы в одном из этих компонентов, либо в их взаимодействии приводят к сильному снижению качества навигации на конкретном устройстве, что мы и наблюдали.
Надеюсь, что не утомил читателя «копанием во внутренностях» маячков Aruba. Отмечу, что в целом решение оставило у нас приятное впечатление, подарив также много забавных моментов. Особенно запомнились расстановка отметок на карте офиса и последующее прокладывание маршрута от электрощитка «Не влезай, убьёт !» до цветов в главной комнате одного из департаментов.
Достаточно интересными оказались функции сбора статистики в Meridian Editor: согласно политике конфиденциальности, решение не может собирать и передавать координаты пользователей в облако, однако запоминает наиболее часто прокладываемые маршруты, марки и ОС пользовательских устройств.
Детального тестирования заслуживала бы кастомизация приложения с помощью SDK и/или встраивание элементов навигационного софта Meridian в сторонние приложения, но это требует подключения квалифицированных программистов (ваш покорный слуга-сетевик) и в случае реализации достойна отдельной статьи.
Благодарю всех читателей за внимание, надеюсь на обратную связь в комментариях в виде интересных вопросов, пожеланий и споров.
Список литературы
- Опыт выбора и заказа iBeacon
- iBeacon: Руководство к действию
- Настройка системы внутренней навигации при помощи инструментов Aruba
- iBeacon. Мифы и реальность
- Концепция Physical web. Bluetooth маячки. Сравнение стандартов iBeacon, AltBeacon и Eddystone
- Understanding the different types of BLE Beacons
- Bluetooth BLE Beacon Standards from iBeacon, Eddystone, and AltBeacon
- Официальное сообщество Aruba
Автор: Bezrukov-Oberon
