Практическое сравнение ячеистых сетей (Thread, ZigBee, BLE Mesh)

Начиная работу с ячеистыми сетями большинство разработчиков задаётся вопросом какую сеть выбрать? Объясняется это наличием на рынке нескольких конкурирующих решений, из которых необходимо выбрать наиболее подходящее под конкретную задачу. На самом деле эта задача не такая простая, как может показаться первоначально по ряду причин.

Связано это с рядом причин, которые не позволяют сравнивать результаты тестов и исcледованний различных сетей между собой. Назовём основные причины:

  • отличия в подходах и метриках между сетями,
  • различная аппаратная реализация устройств,
  • влияние факторов окружающей среды при проведении экспериментов,
  • влияние конфигурации сети (и отдельно взятых узлов)

Рассмотрим их подробнее.

Отсутствие соответствующих метрик для сравнения связано с историческим контекстом развития ячеистых сетей. Различные сети разрабатывались различными компаниями в различное время с применением различных подходов, как следствие, результат также значительно отличается.

Первоначально стоит отметить различный характер ячеистых сетей по своей сути. Одной из основных целей разработки ячеистых сетей было повышение надёжности сети за счёт устранения единой точки отказа. В то же время каждая сеть использовала свои подходы, определяющие характер работы сети.

Первопроходцем был ZigBee, который в 2003 году предложил решения для 3 наиболее массовых применений: освещение, счётчики ресурсов и домашняя автоматизация. Для решение каждой из этих задачи были разработаны свои подстандарты, на основе которых каждая компания-разработчик делала уже своё решение. Стоит отметить, что решения ZigBee были достаточно ограничены функционально, так как были спроектированы под конкретные модели использования, а задачи интеграции с внешними системами зачастую представляли собой отдельную проблему. В итоге решения, хотя, и оставались совместимыми между собой формально, на практике это несло множество ограничений и решения на ZigBee всегда оставались вещами в себе. В значительной степени решению этой проблемы и был посвящён проект 6LoWPAN, на основе которого в дальнейшем был построен Thread. В данном случае разработчики применили кардинально отличающийся подход — в отличие от закрытого ZigBee, практически каждая часть Thread была разработана инженерным советом интернета вещей IETF, состоящего из инженеров множества компаний. В итоге получилось решение открытое, общедоступное, универсальное и, что не менее важно, отлично совместимое с текущими решениями обычного интернета. При этом не были забыты вопросы безопасности, которые становятся всё актуальнее с каждым годом. Третий вариант подхода продемонстрировал Bluetooth SIG представивший Bluetooth Mesh. В отличии от первых двух технологий Bluetooth Mesh использует технологию управляемого наводнения (Managed Flooding), когда каждый узел-ретранслятор принявший пакет пересылает его дальше, если до этого не пересылал его уже. Такой подход позволяет значительно снизить требования к ПО и увеличить количество участников сети по причине практически полного отсутствия обработки на стороне ретрансляторов. Однако, в свою очередь, такой подход несёт и дополнительные ограничения связанные с повышенной ретрансляцией пакетов участниками сети при плотном размещении узлов.

Из важных аспектов стоит отметить также тип подключения к облаку. Наиболее простым и гибким решением, как было сказано выше, является Thread, так как устройства уже зачастую работают на стандартных протоколах адаптированных для обычного интернета, таких как MQTT и COAP и шлюзу необходимо лишь преобразовать один один IP интерфейс в другой, что является типовой задачей для Linux. ZigBee и Bluetooth Mesh используют свои протоколы для передачи данных, не совместимые с IP, что ведёт к необходимости применения шлюзов преобразующих протоколы между различными сетями сразу не нескольких уровнях модели OSI/ISO. К преимуществам Bluetooth Mesh стоит отнести возможность использования смартфонов в качестве шлюза, как временное решение, которое, однако, может быть применимо во многих бытовых применениях.


Zigbee Thread Bluetooth Mesh
Год основания 2003 2015 2017
Основные применения Освещение, счётчики ресурсов, домашняя автоматизация

Промышленность и коммерческие продукты, Универсальное решение Освещение, домашняя автоматизация
Осноаная идея (отличие) Первая массовая ячеистая сеть IPv6 Лёгкая интеграция со смартфонами и другими Bluetooth устройствами
Маршрутизация Полная Полная Управляемое наводнение
Подключение к облаку Шлюз с преобразование протокола Граничный шлюз Смартфон (временно) или шлюз с преобразование протокола

Вопрос влияния аппаратного обеспечения связан с тем, что различные решения были реализованы на различных платформах, откуда они исторически пошли. Соответственно возникали вопросы в производительности вычислительного ядра, радио ядра и радио тракта, так как у различных производителей они были свои. Системы на кристалле последнего поколения, как правило включающие Cortex-M4 + IEEE802.15.4 радио + 0.5-1 МБ Flash, позволяют реализовать все три сети на одной микросхеме и соответственно той же самой печатной плате. Однако до недавнего времени практически не существовало лёгкого способа запустить все три сети на одной платформе. TI до сих пор не поддерживает BLE Mesh, ST не поддерживает ZigBee, у Silabs сертифицирован только ZigBee. Решением в данном случае стал Nordic Semiconductor, который сертифицировал все три ячеистые сети осенью прошлого года. Возможно, что для ряда разработок это может стать решающим фактором. Перед новым годом Nordic Semiconductor выпустил сравнительную статью об эффективной дальности различных сетей, результаты которой мы рассмотрим далее.

Сравнение ячеистых сетей дополнительно осложняется необходимостью учитывать расположение узлов сети относительно друг друга и среды передачи радиосигнала между ними. Так как ячеистые сети предназначены для работы в неидеальных условиях (стены, перегородки, отражения сигнала, источники шума и т.д.) и зачастую сложно моделируемых, то результат может значительно отличаться, при перемещении узлов всего на метр. В своё время ячеистые сети были разработаны как раз для уменьшения влияния этого фактора, но полностью устранить его не удалось и скорее всего не получится ввиду физической природы мира. Это необходимо учитывать при развёртывании сетей на конкретном объекте.

Наиболее интересными исследованиями ячеистых сетей являются работы Ericsson и Silabs посвящённые BLE Mesh.

Вопрос дальности работы ячеистых сети наглядно продемонстрировал Nordic Semiconductor в статье вышедшей под самый новый год. Здесь на одинаковых отладочных платах nRF52840-DK были протестированы все 3 сети на 3 режимах выходной мощности с антенной нулевого усиления, была измерена эффективная дальность соединения в метрах.

Протокол Выходная мощность, [дБм]

0 +4 +8
ZigBee 196 231 280
Thread 209 270 328
BLE @ 1Mbps (mesh) 248 276 345
BLE @ 2Mbps 238 273 333
BLE @ 125kbps (long-range) 756

Выводы, который можно сделать в результате анализа таблицы:

  • Наибольшую дальность даёт BLE mesh
  • Thread отстаёт совсем немного — на 2-5%
  • ZigBee показывает наименьшую дальность — на 16-18%

В предыдущей статье мы тестировали BLE Mesh для случая работы в многоэтажном здании.

Отдельно стоит отметить режим BLE Long Range, дающий более, чем двукратное увеличение дальности. К сожалению пока Long Range и Mesh в рамках BLE не совместимы. Однако, этот вопрос задаётся настолько часто, что вполне возможно, что спустя некоторое время он будет реализован.

Рассмотрим пропускную способность ячеистых сетей на примере данных опубликованных компанией Silabs.

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

В тесте на передачу 100 байт данных можно сделать следующие выводы:

  • Ячеистые сети с маршрутизацией показывают явную зависимость от количества прыжков.
    • Для случая одного прыжка Thread показывает скорость порядка 47 кб/с, что составляет 75% от символьной скорости радиопередатчика (62.5 кб/с), что говорит о крайне высокой эффективности протоколов маршрутизации;
    • При этом даже в самом худшем случае (6 прыжков) такие сети показывают результат в 2-4 раза больше, чем сеть без маршрутизации.
  • Thread показывает примерно в 2 раза большую пропускную способность относительно ZigBee при всех условиях.
  • Пропускная способность Bluetooth Mesh практически не зависит от числа узлов и составляет примерно 2-3 кб/с.
    • Учитывая, что в большинстве применений количество прыжков составляет 2 или 3, то можно говорить о разнице в 4-6 раз для случая ZigBee/BLE Mesh и про 8-12 раз для случая Thread/BLE Mesh.

Задержки передачи данных для сети из 4 прыжков

Задержка в зависимости от размера передаваемых данных

На основе графика можно сделать следующие выводы:

  • На малых передаваемых данных все протоколы обеспечивают примерно одинаковый результат (~50 мс)
  • Практически все сети обеспечивают задержки не заметные для человека (менее 300 мс)
  • Все сети обеспечивают линейную зависимость задержек от размера передаваемых данных
  • Лучший результат показывает Thread.
  • Zigbee показывает хорошую эффективность, но большую фрагментизацию на уровне приложения
  • Задержки в Bluetooth mesh значительно вырастают по мере увеличения передаваемых данных из-за малых размеров пакетов и сегментации.

Стоит отметить, что для решения проблемы сегментации BLE Mesh разработана технологи BLE InstaBurst. Однако результатов в открытом доступе пока нет.

Стоит немного рассказать про сжатие заголовков и фрагментизацию в пакетах Thread. Эти свойства унаследованы из протокола IP и позволяют сжимать заголовочные данные в пакетах для наиболее эффективного использования радиоэфира. Эффект может достигать 2 раз относительно обычного IEEE 802.15.4, размер полезной нагрузки увеличивается с 40 до 80 байт в каждом пакете. Кроме того, если размер передаваемых данных больше максимально допустимого для пакета, то данные будут автоматически разделены на фрагменты и переданы по радио, а на обратной стороне автоматически собраны силами 6LoWPAN . На больших нагрузках это может быть очень востребовано. Стоит отметить, что 6LoWPAN работает на более высоком канальном уровне модели OSI нежели сам IEEE 802.15.4, на котором работает в том числе и ZigBee. Это в значительной степени объясняет преимущество в производительности.

Фрагментизация и пересборка пакетов 6LoWPAN

Рассмотрим влияние размера сети и размера передаваемых данных на задержки. Для малых сетей (сеть из 24 узлов) и малой нагрузки (5-8 байт) все сети показывают отличный результат:

  • Типовое значение до 50 мс,
  • Максимальное до 90 мс
  • Практически нет потери данных
Задержка прихода пакета для сети в 24 узла при посылке 5 байт (8 байт для BLE)

Увеличив нагрузку на сеть до 50 и 32 байт ситуация меняется уже значительно.

  • Thread остаётся в лидерах и лишь немного изменяя форму распределения (более 70% пакетов приходит до 20 мс, и все до 90 мс)
  • ZigBee увеличивает среднее время прихода примерно вдвое — до 80 мс с максимальным значением в 130 мс.
  • BLE Mesh имеет наименее предсказуемый результат, основная часть распределения лежит в области от 40 до 170 мс, с пиками в 20 и 220 мс.
Задержка прихода пакета для сети в 192 узла при посылке 50 байт (32 байта для BLE)

Большая сеть (192 узла) на малой нагрузке (5-8 байт) ведёт себя похожим образом.

  • Thread обеспечивает лучшую задержку, немного увеличивая среднее значение до 40 мс, и гарантированно укладываясь в диапазон до 100 мс
  • Распределение ZigBee становится более равномерным, сохраняя при этом среднее значение порядка 80 мс, при максимальном значении в 190 мс
  • Большинство пакетов Bluetooth Mesh имеет задержку в 60 мс, в то время как максимальное значение увеличивается ещё больше и может достигать более 250 мс.
Задержка прихода пакета для сети в 192 узла при посылке 5 байт (8 байт для BLE)

Наиболее интересные результаты показывают крупные сети (192 узла) на умеренных нагрузках (25 байт для Thread/ZigBee или 16 байт для BLE Mesh).

  • Thread показывает стабильный результат в диапазоне 30-70 мс, при максимальной задержке до 170 мс,
  • ZigBee увеличивает среднее время до 100 мс и максимальное до 250 мс,
  • Bluetooth увеличивает среднее время примерно в 2.5 раза до 150 мс, в то время, как максимальное значение может достигать 800 мс.
Задержка прихода пакета для сети в 192 узла при посылке 25 байт (16 байт для BLE)

Эффект увеличения максимального времени задержки был рассмотрен в статье Ericcson, где исследовалась крупная BLE Mesh сеть в 2000 узлов расположенных на одном этаже. Объясняется он тем, что слишком большое количество ретрансляторов в сети этого типа может мешать друг-другу, если будут постоянно передавать данные. Чтобы избежать этого эффекта необходимо оптимизировать сеть за счёт уменьшения числа ретрансляторов, оптимального их расположения и вариации времени передачи данных (задержки на прыжок) относительно других узлов. В этом случае можно стабильно получить задержку менее 300 мс, что и было подтверждено в лаборатории Ericsson. В таблице ниже представлены результаты оптимизации сети BLE Mesh на время доставки пакета. Рекомендованные значения полученные в результате эксперимента, дающий лучший результат — 6 ретрансляторов на 1000 кв. м. и 1.5% от общего числа узлов в сети.


Базовое решение Оптимизированное решение
Плотность расположения узлов Низкий трафик Средний трафик Высокий трафик Низкий трафик Средний трафик Высокий трафик
Низкая 99.1 95.4 84.3 >99.9 >99.9 >99.9
Высокая 97.5 88.7 69.2 >99.9 >99.9 99.1

Стоит отметить, что Thread динамически определяет роли узлов в сети и назначает ретрансляторами наиболее эффективные узлы.

Выводы, которые можно сделать в итоге:

  1. Bluetooth Mesh обеспечивает максимальную дальность среди рассматриваемых сетей. С незначительным отставаниев в 2-5% за ним следует Thread. Дальность покрытия ZigBee меньшая из рассматриваемых сетей — на 16-18% относительно лидера.
  2. BLE Mesh поддерживает наибольшее количество узлов в сети (теоретически до 32 тыс., на практике используются сети до 1-2 тыс.) и ориентирован на передачу малых объёмов информации.
  3. Thread обеспечивает наибольшую пропускную способность сети и наименьшие задержки, а также наиболее стабильный результат — среднее время до 50 мс.
  4. ZigBee отстаёт примерно в 2 раза относительно Thread по пропускной способности и задержке передачи данных практически во всех тестах.
  5. BLE Mesh показывает наименьшую скорость передачи данных. Эта сеть также наиболее подвержена влиянию, как числа узлов, так и размера передаваемых данных. Задержка может достигать значения ощутимого человеком.
  6. Для оптимальной работы сети BLE Mesh требуется оптимизация количества узлов ретрансляторов, а также их расположения. В то время как Thread и Zigbee имеют встроенные механизмы оптимизации.
  7. BLE Mesh — наиболее простая сеть для реализации и соответственно требует меньше всего ресурсов, однако это оборачивается дополнительными ограничениями.
  8. При выборе сети стоит учитывать дополнительные факторы, такие как решаемую задачу, простоту интеграции с другими сервисами, возможность дальнейшего развития проекта:
    1. Основными применениями для BLE Mesh видится системы освещения, а также решения с максимально простой интеграцией со смартфонами, планшетами и т.п.,
    2. Thread — универсальное решение с лучшими показателями скорости передачи данных, минимальными задержками и лёгкой интеграцией с IP сетями и интернетом вещей.
    3. Zigbee целесообразно применять в случаях, когда необходимо интегрировать новое решение с уже существующей сетью на этом протоколе.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s