Сравнение ячеистых (mesh) сетей

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

Связано это с рядом причин, назовем основные:

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

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

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

Следует обратить внимание на особенности ячеистых сетей (табл. 1).Кроме реализации одной из первоначальных задач повышения надежности сети в целом, каждая сеть ориентировалась на дополнительные факторы, определявшие характер ее функционирования. Первопроходцем стал ZigBee, в 2003 году предложивший решения для трех наиболее массовых применений: освещение, счетчики ресурсов и домашняя автоматизация. Для выполнения каждой из этих задач были разработаны свои подстандарты, на основе которых компании и создавали уже свои варианты. Например, предложения 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 надо отнести возможность использования смартфонов в качестве шлюза как временное решение, которое, однако, может быть применимо во многих бытовых областях.

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

Особо стоит отметить возможность одновременного запуска двух сетей различного типа на чипах Nordic — например, Thread + BLE, Zigbee + BLE mesh или в других комбинациях. Достигается это за счет разделения времени нахождения в радиоэфире (рис. 1).

Рис. 1. Совместная работа Thread и BLE

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

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

Вопрос дальности работы ячеистых сетей наглядно продемонстрировал Nordic Semiconductor (таблица 2) в статье [2]. Здесь на одинаковых отладочных платах nRF52840-DK были протестированы все три сети на трех режимах выходной мощности с антенной нулевого усиления.

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

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

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

Рассмотрим пропускную способность ячеистых сетей на примере данных, опубликованных компанией Silabs [1] (рис. 2).

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

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

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

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

Задержки передачи данных для сети из 4 прыжков. На основе графика (рис. 3) можно сделать следующие выводы:

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

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

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

Рассмотрим влияние размера сети и размера передаваемых данных на задержки (рис. 5).

Рис. 5. Задержка прихода пакета для сети в 24 узла при посылке 5 байт (8 байт для BLE)

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

• типовое значение: до 50 мс;
• максимальное: до 90 мс;
• практически нет потери данных.

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

Рис. 6. Задержка прихода пакета для сети в 192 узла при посылке 50 байт (32 байта для BLE)

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

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

Рис. 7. Задержка прихода пакета для сети в 192 узла при посылке 5 байт (8 байт для BLE)

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

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

Рис. 8. Задержка прихода пакета для сети в 192 узла при посылке 25 байт (16 байт для BLE)

• Thread демонстрирует стабильный результат в диапазоне 30–70 мс, с максимальной задержкой до 170 мс.
• ZigBee увеличивает среднее время до 100 мс и максимальное до 250 мс.
• Bluetooth увеличивает среднее время примерно в 2,5 раза до 150 мс, а максимальное значение может достигать 800 мс.

Эффект увеличения максимального времени задержки был рассмотрен в статье Ericsson [3], где исследовалась крупная BLE Mesh-сеть в 2000 узлов, расположенных на одном этаже. Объясняется он тем, что слишком большое количество ретрансляторов в сети такого типа может мешать друг другу, если будут постоянно передавать данные. Чтобы избежать этого эффекта, необходимо реорганизовать сеть за счет уменьшения числа ретрансляторов, оптимального их расположения и вариации времени передачи данных (задержка на прыжок) относительно других узлов. В этом случае можно стабильно получить задержку менее 300 мс, что и было подтверждено в лаборатории Ericsson.

В таблице 3представлены результаты влияния оптимизации сети BLE Mesh на время доставки пакета. Рекомендованные значения, полученные по итогам эксперимента, дающие лучший показатель, — 6 ретрансляторов на 1000 кв. м и 1,5% от общего числа узлов в сети.

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 показывает наименьшую скорость передачи данных. Эта сеть также является наименее стабильной и подвержена влиянию как числа узлов, так и размера передаваемых данных. Задержка может достигать в итоге максимального значения более 300 мс.
6. Для оптимальной работы сети BLE Mesh требуется оптимизация количества узлов ретрансляторов, а также их расположения, в то время как Thread и ZigBee имеют встроенные механизмы оптимизации.
7. BLE Mesh — наиболее простая сеть для реализации и, соответственно, требует меньше всего ресурсов, однако это оборачивается дополнительными ограничениями.
8. При выборе сети нужно учитывать дополнительные факторы, такие как решаемая задача, простота интеграции с другими сервисами, возможность дальнейшего развития проекта:

• • основными применениями для BLE Mesh видятся системы освещения, а также решения с максимально простой интеграцией со смартфонами, планшетами и т. п.;
  • Thread — универсальное решение с лучшими показателями скорости передачи данных, минимальными задержками и легкой интеграцией с IP-сетями и «Интернетом вещей»;
  • ZigBee целесообразно применять в случаях, когда необходимо интегрировать новое решение с уже существующей сетью на этом протоколе.