Выбор беспроводной технологии для IoT: критерии и практические советы
7 февраля 2020IoT это не только «умный дом», но и масштабные промышленные решения с более жесткими требованиями к протоколам, энергопотреблению и топологии сетей. Владимир Степанченко, Wireless Solutions Product Manager, DSR Corporation, делится богатым практическим опытом работы с беспроводными протоколами для IoT и приводит результаты измерений, полученных в реальных условиях. Вы узнаете, какие критерии стоит учитывать при выборе протокола для IoT-решения и разберетесь с особенностями BLE, Zigbee, Thread, 6LoWPAN и других технологий от профессионала с многолетним опытом.
Согласно оценкам Fortune Business Insights, глобальный рынок «интернета вещей» вырастет со 190 $ млрд в 2018 году до 1,102 $ трлн в 2026 году с совокупными темпами годового роста в 24,7%. Примерно половина выручки приходится на таких гигантов в IoT, как Microsoft, Cisco, IBM, Bosch Software Innovations и Oracle. Однако у рынка значительный потенциал, позволяющий многим компаниям предложить свои IoT-решения.
Одним из ключевых факторов успеха на активно растущем рынке IoT является правильный выбор беспроводного протокола. В нашей статье пойдет речь о сферах применения «интернета вещей», особенностях наиболее популярных протоколов и критериях выбора технологии в зависимости от сферы применения. DSR Corporation также делится результатами практических тестов трех ключевых IoT протоколов.
Оглавление
-
1.1 Умный дом
Критерии выбора протоколов для беспроводных систем
-
3.1 Радиус действия: в теории и на практике
3.3 Размер сети
3.5 Размер пакета
3.6 Структура пакета
-
4.1 Пропускная способность в зависимости от количества сетевых сегментов (короткие пакеты)
4.2 Пропускная способность в зависимости от количества сетевых сегментов (длинные пакеты)
4.3 Задержка и объем полезной информации
4.4 Групповая доставка пакета (Multicast Packet Delivery) (короткий пакет)
4.5 Групповая доставка пакета (Multicast Packet Delivery) (длинный пакет)
Полная версия видео доклада Владимира Степанченко. Подписывайтесь на наш YouTube-канал, чтобы первыми смотреть свежие видео с митапов по IoT, блокчейну, "интернету вещей", frontend-разработке и другим сферам экспертизы DSR Corporation.
1. Сферы применения IoT
Выбор протокола для IoT-решения во многом зависит от его сферы применения. Основные представлены на диаграмме ниже.
«Умный дом»
«Умный дом» обычно управляется через приложение со смартфона или смарт-колонки типа Amazon Alexa. К системе подключено немного устройств — 15-50. Радиус действия небольшой, 20-30 метров, поэтому возможна установка дополнительных повторителей. Нет обязательных строгих требований доставки сообщения/выполнения команды. Добавление новых устройств в систему упрощенное (обычно подключает сам пользователь). Для интеграции сторонних смарт-устройств должна быть использована открытая экосистема.
Коммерческие системы
Гостиницы, больницы, офисные знания. Больше людей, помещения большей площади, иногда в несколько этажей. Необходимый радиус действия увеличивается. Количество устройств, подключенных к системе, может исчисляться сотнями. Как правило, используется закрытая экосистема. Процесс добавления новых устройств сложнее.
Промышленное применение
Автоматизация производственных процессов, железнодорожных станций, транспортных терминалов. Более серьезные требования к безопасности промышленных «умных» систем, чем потребительских. Количество подключенных устройств может достигать нескольких тысяч. Гарантированная доставка данных становится обязательной, а для беспроводных технологий это достаточно сложная задача. Помеха на канале требует поиска решения. У промышленных систем значительный радиус действия.
Кстати, "Лаборатория Касперского" недавно выпустила защищенную операционную систему KasperskyOS, предназначенную в том числе для IoT. Одно из первых применений – крупный железнодорожный узел. Система отслеживает занятость путей, составов с опасными грузами и т.д. Все в режиме реального времени, большой охват, большое количество отслеживающих устройств.
Важный момент – ресурсы, затрачиваемые на поддержку промышленных систем. Старший технический директор Siemens, активно работающей на рынке решений промышленной автоматизации компании, рассказывал, что по их оценкам 20-30% инженерных усилий тратятся на поддержку существующих решений. Таким образом, остается меньше ресурсов на разработку инноваций и развитие бизнеса. Требуется найти способ снизить объем ресурсов, необходимый для поддержки уже созданных решений.
2. Критерии выбора протоколов для беспроводных систем
Следует поделить на две основные группы: функциональные и нефункциональные.
За счет накопленного за два десятка лет опыта работы, DSR Corporation кроме разработки, оказывает еще и консалтинговые услуги. К примеру, компания из Франции делает оборудование по управлению климатом (отопление/кондиционирование) в доме. Задача – создать беспроводное решение. К какой экосистеме его стоит подключить? Если есть уже готовая – то было бы разумно сделать совместимое решение. В данном случае, рынок диктует условия выбора. Если есть экосистема, то есть и процедуры тестирования и сертификации для обеспечения совместимости. Доступна информация, как тот или иной протокол или технология себя зарекомендовали. Проверенное рынком решение позволяет минимизировать риски.
Нефункциональные:
- Стандарт
- Программа сертификации
- Насколько проверенное решение
- Есть ли экосистема
Стандарт выбран. Дальше начинает работать инженерный отдел, решающий технические задачи: насколько качественно будет работать связь, максимальный размер передаваемых сообщений, радиус действия, гарантированная доставка сообщения. Важный момент, который часто упускают даже опытные инженеры – насколько проработан уровень приложения.
Сама сеть может демонстрировать отличные результаты, но уровень приложения либо не развит, либо слаборазвит. В этом случае возможны проблемы с системой взаимодействия на уровне приложений. На сетевом уровне все может работать отлично.
Требования к функциональности и производительности:
- Скорость передачи данных
- Объем полезной информации в пакете (payload)
- Радиус действия
- Гарантированная доставка
- API для приложений
Три уровня: приложение, сеть и физический. Относительно них и строится дальнейший анализ.
DSR Meetup: "Введение в популярные беспроводные протоколы для IoT", Евгений Эксаревский, DSR Corporation
Стандарт и интероперабельность
Выбирать стандарт или нет? Особенно важный критерий для потребительского рынка. Из ключевых упомянем Amazon, Comcast (США), Somfy (Франция). Каждый поддерживает несколько протоколов. Главная особенность – открытая экосистема. Производитель оборудования для управления климатом из примера выше сделал термостат, который можно подключать по Bluetooth или Zigbee, произвел интеграцию с Amazon Alexa. Для такого производителя открываются хорошие возможности продаж, поскольку выбор был сделан в пользу открытой экосистемы.
Компания Control4 (США), также серьезный игрок на IoT рынке, выбрала другой путь развития. Она порядка 15 лет назад взяла стандарт Zigbee, который тогда был достаточно новым. Инженеры Control4 привнесли небольшие изменения для решения собственных задач и построили закрытую экосистему на базе существующего открытого стандарта.
Подключиться к Control4 можно только после подписания с компанией соглашения и выполнения требований совместимости. Изменения, внесенные в этой закрытой экосистеме в протокол Zigbee, затрагивают сетевой уровень и уровень приложения. Прежним остался только физический уровень.
Однако, для тех, кто попал в эту экосистему, открываются хорошие возможности продаж своих устройств с поддержкой проприетарного стандарта Control4. Собственная разработка, расширения стандарта Zigbee. Компания смогла построить успешный бизнес, используя закрытую модель.
Существуют и закрытые стандарты. Например, Z-Wave. Есть физический и сетевой уровень, уровень приложений. Разработан не сообществом, а датской компанией Zensys в 1999 году. В декабре 2008 года Z-Wave был куплен Sigma Design. Этот протокол используется главным образом в решениях для «умного дома». В январе 2018 года технология Z-Wave была куплена Silicon Labs за 240 $ млн.
Silicon Labs работают со всеми основными беспроводными протоколами для IoT: Bluetooth, Zigbee, Thread, Z-Wave, в sub-GHz диапазоне есть собственные проприетарные решения. Компания фактически закрывает сейчас 90% рынка беспроводных технологий.
Z-Wave – закрытый стандарт от одной компании. Чипы для протокола создает единственный производитель. Система работает, причем в своем сегменте хорошо. Однако, стоимость решений на основе Z-Wave выше. В открытых экосистемах, таких как Bluetooth и Zigbee, кто угодно может производить «железо», кто угодно может делать «софт». Для компаний затраты достаточно умеренные.
С Z-Wave ситуация другая. Монополия позволяет диктовать цены на железо. К примеру, чип с поддержкой Bluetooth или Zigbee от китайского производителя можно купить по цене от 1 доллара. От хорошего европейского или американского – 2 – 2,5 доллара. Чип Z-Wave обойдется минимум в 7 долларов.
К примеру, датчик температуры на Zigbee может стоить 10 долларов, а на Z-Wave – уже 15. В масштабах системы, состоящей из десятков или даже сотен устройств, разница в цене может стать решающей при выборе протокола.
Однако, в декабре прошлого года Silicon Labs совместно с Z-Wave Alliance, сообщила о планах сделать стандарт открытым. Во второй половине 2020 года будет опубликована открытая спецификация Z-Wave.
Уровень приложений
- Модель данных
- Объем пересылаемых данных
- Пропускная способность
- Процедуры подключения и конфигурации новых устройств
- Безопасность
- Локальный или с подключением к интернету
- Отсутствие приложения
Модель данных и что это такое. Должны быть API, какие-то сущности, описывающие ту или иную предметную область: освещение, автоматизация офисов и т.д. Исторически сложилось, что в индустрии автоматизации освещения большой популярностью пользуются Bluetooth-решения. Уровень приложений развит очень хорошо.
Суть следующих двух пунктов понятна из названия: объем пересылаемых данных и пропускная способность сети.
Более важный вопрос, к которому стоит отнестись с повышенным вниманием – подключения к сети новых устройств и их конфигурация. На первый взгляд, задача простая. Однако все усложняется, если учесть, что подключение и настройка должны проводится с минимальным участием человека или вовсе без него.
К примеру, при подключении к Wi-Fi необходимо выбрать нужную сеть и ввести пароль. Теперь представьте, что устройства ввода нет, это надо сделать автоматически. Wi-Fi как протокол не решает проблему подключения новых устройств, не предлагая готовых способов для разных вариантов применения. По этой причине Apple выпустили свой протокол, позволяющий Wi-Fi выполнять процедуру конфигурации новых устройств. DSR Corporation разработала собственное решение.
Безопасность. В последнее время об этой проблеме в индустрии начали задумываться. В штате Калифорния (США) вышел закон об обеспечении безопасности «интернета вещей», вступивший в действие уже с января 2020 года. Он обязывает продавцов IoT-устройств в Калифорнии предлагать только защищенные девайсы. В Европе есть похожий закон GDPR (General Data Protection Regulation).
На уровне стран уже принимаются законы, которые регулируют защищенность «интернета вещей». Компании, занимающиеся IoT, очень серьезно к этому относятся. Наихудший из возможных сценариев – взлом облачного IoT сервиса. Однако важно также обеспечить безопасность «умных» домов и других решений на базе беспроводных протоколов. В целом безопасности в IoT в последнее время уделяется все больше внимания.
Локальная сеть или с подключением к интернету на уровне приложения? К примеру, BLE – чисто локальный протокол с радиусом действия в несколько десятков или, в некоторых случаях, сотен метров. Но за пределы радиуса действия сеть на основе BLE выйти не может. Что делать, если нужно подключить, к примеру, соседнее здание, расположенное на превышающем радиус действия расстоянии?
Возьмем протокол Weave от Google. Активно используется в экосистеме Google Nest. Для IoT-устройств реализован на базе протокола Thread, основанном на стандарте IEEE 802.15.4. Сегменты сети на базе Thread соединены по Wi-Fi посредством Weave на уровне приложения. Для разработчика приложения связь бесшовна, удаленные на значительное друг от друга расстояние сегменты сети «общаются» через интернет.
Есть протоколы, не имеющие уровня приложения. Это Wi-Fi и Thread. Они предлагают уровень сети, на базе которого могут быть построены решения. Как создать приложения и обеспечить их интероперабельность? Достаточно сложная задача.
К примеру, Levdance, производитель осветительного оборудование, «умных» ламп, устройств для управления светом. Компания использует протоколы Bluetooth и Zigbee для своих IoT решений и планирует использовать Thread. Это протокол не предлагает уровень приложения, но есть компании, продвигающие протокол Dotdot, реализующий этот уровень. Google продвигает Weave для использования с Thread.Weave сфокусирован на безопасности и бесшовной передаче сообщений. В Dotdot по сравнению с Weave модель данных более развита и проработана. Также стоит отметить Open Connectivity Foundation (OCF), ассоциацию из 300 компаний, работающую над едиными стандартами для «интернета вещей» и реализовавшую спецификации безопасности для IoT.
Производитель, такой как Levdance, хотел бы охватить максимум экосистем. Смарт-лампы должны работать с решениями от Google, Apple и так далее. Получается, что ему придется делать 4 уровня приложений. Соответственно, накладные расходы на разработку вырастают в 4 раза.
Энергопотребление
На стадии изготовления датчика или другого конечного устройства решается, будет ли он получать питание от батареи или подключаться к электросети. Некоторые типы устройств, такие как лампочки и «умные» розетки подключаются к ней по умолчанию, проблем с энергоподключением нет.
В случае работы от батареи – необходимо тщательно просчитывать энергопотребление, чтобы добиться от датчика нескольких месяцев автономной работы. В идеале – несколько лет. Возможны варианты, когда энергия берется из возобновляемых источников (например, солнечные панели).
В IoT сейчас активно используется EnOcean, технология с применением миниатюрных преобразователей механической или тепловой энергии. На ее базе созданы простые переключатели, управление регуляторами яркости, светом и т. д. Работают без батарей, практически вечно.
Уровень сети (требования)
Как соединять устройства в IoT сети? Простейший способ – «шина», наследие проводных соединений. Также применяется «звезда». Самая удобная и простая топология: 1 центральный узел. Если радиуса действия «звезды» не хватает, приходится использовать другую топологию, такую как mesh (ячеистая сеть).
На стадии выбора протокола для IoT необходимо решить, будет ли центральный узел или необходимо построить распределенную сеть. Это сказывается, например, на отказоустойчивости. Альянс Thread Group появился в 2014 году, и вошедшие в него компании начали работать над этой технологией. Спецификация была выпущена в 2015 году. Для сравнения – Zigbee вышел в 2003, а Bluetooth – 1998.
Многие из крупных компаний, активно работавших с Zigbee, стали работать с Thread. Протокол Zigbee gпроверен рынком, работает хорошо. Однако, есть некоторые моменты, которые надо решить. В частности – использование центрального узла, что является распространенной практикой при построении сетей на базе Zigbee. В Thread определенные недостатки этого протокола попытались устранить. Что сейчас представляет собой Thread с точки зрения концепции — распределенная сеть без центрального узла. Нет единого узла отказа, который в случае сбоя обрушивает всю сеть.
В Zigbee обычно используется централизованная сеть с координатором, управляющим всей сетью. В случае отказа координатора – рассыпается вся сеть.
В Thread изначально решен вопрос безопасности: DTLS, сертификаты, обмен ключами. Также решены и другие, менее значимы, но важные моменты. Спецификация достаточно проработана.
При реальном применении возникают различные нюансы. Распределенная сеть имеет свои преимущества и недостатки. Если вы создаете систему управления умным домом, необходим центральный элемент, принимающий решения. Голосовое управление или автоматизированная система, использующая сценарии. В Thread это граничные маршрутизаторы (border routers), позволяющие выйти за пределы локальной сети по IPv6 в облачные системы. Возникает вопрос IP-связности. Нужен ли этот функционал — вопрос остается открытым. Каждая компания отвечает на него сама. Zigbee популярный и активно используемый на IoT рынке протокол, но IP-связности не предлагает, как и BLE. Thread предлагает IPv6.
Проблема возникает при попытке «подружить» IPv4 и IPv6. Компаниям, работающим с промышленными решениями, таким как Siemens и Cisco, важна поддержка IPv6. На этапе развертывания системы и в ходе последующей поддержки IPv6 дает возможность каждому устройству «пробиться» наружу, что позволяет решить ряд проблем. Поэтому крупные игроки на рынке сейчас активно вкладываются в развитие Thread с поддержкой IPv6. Bluetooth SIG также занимается исследованием вопроса реализации IPv6 в протоколе.
Физический уровень (требования)
Выбор частотного диапазона, это sub-GHz, 5 ГГц и 2,4 ГГц. Диапазон 5 ГГц сокращает радиус действия, однако является наименее зашумленным. 2,4 ГГц – открытый диапазон почти во всех странах, поэтому нет необходимости в сертификации и работе с регуляторами. Есть редкие исключения — в некоторых странах определенные каналы закрыты, есть ограничения по мощности передатчика. Однако, в большинстве случаев станет оптимальным выбором. В этом диапазоне работают Wi-Fi и Bluetooth, одни из наиболее популярных беспроводных технологий.
sub-GHz – больше радиус действия, но выбрав этот диапазон, придется столкнуться с массой региональных ограничений и регуляций. Проблемы с сертификацией – получив ее, к примеру, для европейского рынка, для американского рынка придется проходить еще одну процедуру сертификации. Возможно, для выхода на рынок некоторых стран придется поменять радиомодуль в устройствах.
Перестройка частоты (frequency hopping). С ее помощью решается проблема зашумленного канала. Соответственно, есть возможность сделать гарантированную доставку. Активно используется в BLE. Помогает обойти серьезную помеху на канале и решить проблему региональной регуляции для sub-GHz диапазона. К примеру, ограничение на продолжительность включения (duty cycle) – нельзя вещать на одном канале дольше чем, к примеру, 5 минут в течение часа. Frequency-hopping используется многими компаниями.
Передача сообщений в выделенном временном слоте (slotted) и без него (unslotted). Используется в BLE. Последний подход означает возможность отсылать сообщение в произвольный момент времени, не ожидая своего отрезка. Как правило, для не сильно зашумленного канала такой метод подходит хорошо, позволяя быстрее высылать и получать данные. Однако, если необходимо решить проблему QoS, то больше подходит передача сообщений в выделенном временном слоте.
3. Сравнение протоколов
Ключевые беспроводные протоколы. Слева список протоколов, используемых, как правило, в решениях для потребительского рынка, справа – для промышленного.
Сравнение протоколов
Обширный выбор, однако предлагаем остановиться на Zigbee, Bluetooth и Thread. Три этих стандарта способны решить 90% запросов при создании IoT решений.
У всех трех стандартов есть сертификационные программы и пул уже сертифицированных устройств. Бесспорный лидер по их количеству – Bluetooth.
Вспомним, что Bluetooth появился в 1998 году. В классическом варианте это была замена кабелю (COM-порты). Затем появились аудио, видео, handsfree профили. Однако, энергопотребление достаточно высокое.
Поэтому в начале 2010 года в рамках версии Bluetooth 4.0 была реализована энергоэффективная технология Bluetooth Low Energy (BLE), она же Bluetooth Smart.
BLE стал выбором для носимых устройств, сенсоров и других смарт-устройств. Наиболее широко распространенная беспроводная технология в мире IoT. Однако, до выхода в 2017 году BLE Mesh была доступна топология только типа «звезда».
Компании относятся к BLE Mesh с настороженностью, поскольку стандарт вышел всего 2 года назад и проверку рынком пока не прошел.
Как появился BLE Mesh? Множество компаний использовали BLE и начали заниматься разработкой собственных, проприетарных решений BLE с ячеистой топологией (mesh). В итоге появилось более 5 различных реализаций.
После этого Bluetooth SIG провела анализ созданных mesh-решений, выявила плюсы и минусы. Один из наиболее важных критериев – обратная совместимость. В итоге Bluetooth SIG выбрала одну из проприетарных разработок, которая и послужила базой для создания BLE Mesh в 2017 году.
Уровень приложений предлагают все три протокола, хотя с Thread ситуация особенная. Как такого уровня приложений в этой технологии нет, но с ним можно использовать OCF, Dotdot или Weave.
Радиус действия: в теории и на практике
Теоретическая «дальнобойность» Zigbee и Thread в спецификациях — 100 метров. У Bluetooth еще больше – до 400 метров, но с учетом множителей (см. таблицу выше).
Компании, занимающиеся производством чипов с поддержкой беспроводных протоколов, производят собственные измерения радиуса действия.
Результаты одного из таких тестов на таблице справа. Фантастические цифры, однако все дело в методике измерений. Над большим прудом запускаются два квадрокоптера, с помощью которых и меряют радиус действия. Фактически, в идеальных условиях.
В реальных условиях здания, к примеру, радиус действия намного скромнее. На практике удается достичь 30 метров для Zigbee (60 для sub-GHz), 30 для Thread и 40-60 для BLE. Кроме того, радиус действия зависит от ограничений в стране. К примеру, в США и России можно поставить усилители на +20 дБ. В странах ЕС ограничение на усиление сигнала 14 дБ. В результате реальный радиус действия систем для стран Евросоюза снижается с 30 до 15 метров.
Zigbee Alliance предложил свое решение – использование диапазона sub-GHz. Дело в том, что в Великобритании есть программа по установке смарт-счетчиков, охватывающая всю страну. Для связи со считывающими устройствами «умные» счетчики используют беспроводное соединение. Программа стартовала в 00-х, и сейчас идет вторая фаза обновления протоколов и требований. Было проведено исследование, результаты которого показали, что использование sub-GHz диапазона позволит добиться радиуса действия в 50 метров. Этого достаточно, чтобы покрыть 90% домов. Была выбрана топология типа «звезда», чтобы не усложнять систему, используя mesh.
На базе этого масштабного британского решения появился диапазон sub-GHz в Zigbee, позволяющий увеличить реальный радиус действий почти до 60 метров.
Радиус действия BLE long-range в условиях офисов составляет 40-60 метров. К сожалению, в реальных условиях теоретического увеличения «дальнобойности» в 4 раза не происходит. Однако, 60 метров в диапазоне 2,4 ГГц — очень неплохой результат по сравнению с Zigbee и Thread.
Возможности маршрутизации
Часто для масштабных систем при радиусе действия в 15-30 метров топологии типа звезда недостаточно. Допустим, требуется объединить систему освещения в единую сеть в офисе протяженностью 100-150 метров.
Промежуточной топологией можно назвать «дерево», после которого идет mesh (смешанная, ячеистая топология).
Полезно знать, что в описаниях различных протоколов компании могут указывать возможность реализации ячеистой топологии. Практика показывает, что речь идет о топологии типа «дерево». Например, 6LoWPAN в реализации от Contiki предлагает по факту «дерево». При работе с ним выяснилось, что перестройка дерева занимает часы. Т.е. сеть будет сегментирована в течение часов, и устройства будут недоступны. Для многих решений такая реализация не подходит.
В Zigbee и Thread реализована полноценная ячеистая топология. У mesh масса преимуществ, однако в реализации она сложнее. BLE изначально предлагал звезду, но в 2017 году появилась поддержка mesh с некоторыми особенностями.
Ячеистая топология в BLE построена на широковещании. В Zigbee и Thread есть роутеры и механизмы, позволяющие построить маршрут (найти, запомнить его и передать). BLE mesh есть набор устройств. Некоторые являются ретрансляторами. Сигнал может быть ретранслировать определенное количество раз (в виде «волны»). У такой реализации есть минусы. Необходимо очень тщательно подходить к конкретной реализации топологии. Если ретрансляторов будет мало, то сигнал может потеряться. Если их поставить больше, чем нужно, то можно столкнуться с проблемой широковещательного шторма (broadcast storm).
Процедура подключение устройств в BLE в принципе решена, однако самих решение немного.
Размер сети
Как и с реальным радиусом действия, реальные размеры сетей разительно отличаются от теоретических. По спецификациям в сети на базе Thread может быть до 16 000 устройств, Zigbee – 65 000, BLE mesh – 32 000. Теоретические подсчеты выполнены по доступному адресному пространству.
На реальных протестированных сетях цифры другие. Для Thread это 200-300 устройств. На тестовых стендах – до 1000. Есть один пример реально работающей сети на Thread от французского стартапа BLUEGRioT. «Умные» вешалки для одежды с LED-дисплеями, которые в реальном времени соединяются с компьютерной системой 18-этажного французского торгового центра «Галери Лафайет» в Париже. На дисплее отображается цена, размеры, наличие и прочая информация об одежде. В сети BLUEGRioT на базе Thread 2000 устройств. Однако, стартапу пришлось серьезно поработать над реализацией такой масштабной сети.
Thread активно развивается. Несколько лет назад Silicon Labs, Nordic и NXP предлагали свои реализации Thread стека. Потом Google выложил исходный код Thread в открытый доступ и запустил проект Open Thread. После этого альтернативные реализации стали сворачиваться, несмотря на потраченные на проприетарные стеки ресурсы. Компаниям оказалось удобнее работать с единым открытым исходным кодом. В этом году Silicon Labs и NXP последними анонсировали отказ от собственных решений и переход к Open Thread. Осталась только испанская компания Kirale, продолжающая работу над собственным стеком Thread.
Пропускная способность
Заявленные скорости передачи данных для трех протоколов отличаются от реально достижимых. Zigbee и Thread работают на MAC-уровне на скорости 250 кбит/с. У BLE – 125 кбит/c для long range (LE Coded S=8),и 0,5 Мбит/с для LE Coded S=2, 1 Мбит/с для LE 1M и 2 Мбит/с для LE 2M.
Что от пропускной способности остается приложению для передачи данных? Вторая строка в таблице, теоретическая пропускная способность. Как правило, в 2 раза меньше.
Реальные измерения пропускной способности еще меньше. 40-50 кбит/с для Zigbee и Thread, 26 – 262 кбит/с для BLE. Однако, при использовании ячеистой топологии (mesh), скорость передачи данных в BLE сетях падает до 5-7 кбит/с.
Достаточно ли таких скоростей? Вполне может оказаться, что и 5 кбит/с хватит для построения IoT-сети.
Интересная особенность BLE, о которой стоит упомянуть. Если необходима интеграция с мобильным приложением, то, на первый взгляд, без ячеистой топологии скорости достаточные. Однако выясняется, что в iOS и Android есть свои ограничения на использование слотов.
Существует интервал соединения — насколько часто приложение может обращаться к каналу связи. Также ограничение на количество занимаемых приложением слотов. В результате реальная пропускная способность для приложения на iOS составляет 21-56 кбит/с, на Android — 128 кбит/с. При этом, теоретическая составляет 800 кбит/с.
В последние несколько лет компании выпускают чипы с поддержкой нескольких протоколов, работающих параллельно. Например, Zigbee и BLE, или Thread и Zigbee. Использование таких чипов дает возможность обмениваться данными и по Bluetooth и по Thread, к примеру.
Размер пакета
В спецификациях Thread и Zigbee размер пакета на MAC уровне — 127 байт. Для BLE диапазон 27-255 байт. BLE Mesh – 27 байт. Верхняя строчка в таблице — размер передаваемого пакета на уровне сети.
На уровне приложения размер пакета уменьшается примерно в два раза. В условиях фрагментации, когда надо передать 1-2 КБ пакетами по 127 байт, происходит очередное урезание размера пакета. Для Zigbee это 64 байта. В Thread фрагментацию перенесли на уровень сети, объем передаваемых сервисных данных снизился, поэтому размер пакета уменьшился не так значительно – до 92 байт. В условиях фрагментированной передачи данных Thread выигрывает.
В BLE за счет изначально большого пакета (до 265 байт) служебная информация занимает немного полезного объема. В BLE Mesh с работающей фрагментацией размер пакета сокращается до 12 байт.
Структура пакета
Чтобы достичь максимальной скорости передачи данных, необходимо четко понимать, как работает тот или иной протокол, и отменять, например, подтверждения на уровне приложения или дажe MAC. В этом случае придется пожертвовать сообщениями о доставке в пользу увеличения пропускной способности сети.
Временные интервалы MAC 802.15.4
Физический уровень Zigbee и Thread определяется стандартом IEEE 802.15.4. Перед тем, как послать данные, есть интервал, в течение которого происходит прослушивание канала, затем процедура Clear Channel Assessment (CCA), ожидание свободного канала, после этого передача данных, затем подтверждение уровня MAC (192 мкс). На этом уровне теряются проценты скорости.
Неочевидные вещи, с которыми неожиданно приходится сталкиваться, когда нужно добиться максимальной скорости передачи данных.
4. Практические результаты
Выстроена цепочка из устройств. Замеряем скорость. Верхний график — Thread, нижний — BLE mesh. При этих начальных данных Thread и Zigbee ведут себя примерно одинаково. Во время тестов передавался короткий пакет в 10 байтов.
Результаты очевидные — чем больше сетевых сегментов, тем ниже скорость.
Пропускная способность в зависимости от количества сетевых сегментов (длинные пакеты)
Те же три протокола, но размер пакета увеличен до 100 байт. Скорость BLE Mesh падает катастрофически даже с одним «хопом», в разы меньше по сравнению с Zigbee и Thread. Дело в том, что с включенной фрагментацией объем полезной информации в пакете составляет 12 байт.
Делаем вывод, что для передачи большого объема данных BLE mesh – далеко не самый оптимальный выбор. На коротких пакетах приемлемых результатов с BLE mesh добиться значительно проще.
Задержка и объем полезной информации
Задержка актуальна для некоторых областей применения беспроводных сетей. К примеру – при автоматизации освещения. Между нажатием кнопки выключателя и включением лампы в идеале должно пройти не более 200 миллисекунд. Это время реакции человека. Если уложиться в это значение, то мы не замечаем задержки между нажатием кнопки и последующим действием.
Если лампочек в системе несколько и задержка превышает 200 мс, то при последовательном включении возникает т.н. «поп-корн эффект», лампы включаются друг за дружкой. Вывод очевидный — чем меньше задержка при распространении сигнала, тем лучше.
При использовании BLE mesh с увеличением объема передаваемой информации задержка значительно вырастает. Если объем 12-15 байт, то все три протокола демонстрируют примерно одинаковое время задержки. Zigbee и Thread стоит предпочесть, если информации передавать нужно много, а задержку необходимо сделать минимальной.
В целом Thread показывает наилучшие результаты за счет более эффективной фрагментации (вынесена на сетевой уровень, как уже говорилось выше). Фрагментация включается при передачи больших объемов данных.
Групповая доставка пакета (Multicast Packet Delivery) (короткий пакет)
Другой тестовый стенд, состоящий из 192 устройств. Похожим образом работают решения для автоматизации освещения. Отсылаем широковещательное сообщение и измеряем задержку до срабатывания каждого из устройств.
5% устройств включилось за 20-30 мс, за 50-60 – еще 25-30% и далее до 150 мс включается основная масса устройств. Все три протокола продемонстрировали примерно одинаковые результаты с коротким сообщением 5-8 байт. BLE mesh отлично подходит для автоматизации освещения.
Групповая доставка пакета (Multicast Packet Delivery) (длинный пакет)
Увеличиваем размер пакета до 16-25 байт. В BLE mesh заработала фрагментация, вместо одного пакета надо отправить два. Задержка выросла до 200-400 мс. Zigbee и Thread показывают более приемлемые результаты.
5. Выводы
Однозначного победители среди протоколов выявить не удалось. Его попросту нет. Выбор протокола для IoT зависит от сферы применения. У каждого есть свои плюсы и минусы. В случае с передачей небольшого объема данных (до 15 байт в пакете) BLE mesh, Zigbee и Thread примерно одинаковы. Поэтому стоит учитывать экосистему устройств, особенности интеграции, нефункциональные требования (сертификация, продвижение на рынке).