Расходы на трансляцию сетки Xbee

Я разрабатываю ячеистую сеть Xbee, запланированный размер составляет около 10 узлов, расположенных на площади около 200 квадратных метров. Это будет комбинация узлов, сообщающих данные об окружающей среде, с исполнительными механизмами/логгерами. Я намереваюсь иметь один контроллер/регистратор для обработки данных из сети, однако я предсказываю, что его местоположение (и адрес) изменится. Поэтому мне нужно, чтобы широковещательная рассылка периодически отправлялась из текущего регистратора, чтобы гарантировать, что данные отправляются в нужное место.

Я читал, что трансляция в ячеистой сети Xbee действительно может убить производительность, однако мне не удалось найти много подробностей о специфике.

Тогда мой вопрос: возможна ли отправка широковещательной рассылки каждые 60 секунд в сетке из 10 узлов или это создаст нагрузку на сеть?

Ответы (1)

Я бы выделил два типа трансляции:

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

  • Сообщения, которые отправляются всем узлам повсюду

Запрос на отправку широковещательной рассылки первого типа приведет к тому, что она будет передана количество раз, указанное в МТ. По умолчанию установлено четыре передачи, что означает, что сразу же широковещательная рассылка, отправленная с настройками по умолчанию , будет дороже, чем одноадресная. Кроме того, каждый узел, который слышит широковещательную передачу второго типа, в конечном итоге будет передавать ее повторно, даже если к тому времени, когда он передает сообщение, все, кто мог его услышать, уже сделали это.

Я считаю прискорбным, что нет способа указать, следует ли считать отдельную передачу — даже одного из первых типов — достаточно «важной», чтобы заслуживать повторной передачи. Надежное обнаружение сетевого маршрута требует, чтобы широковещательные рассылки повторялись достаточно, чтобы гарантировать, что по крайней мере одна копия пройдет, но диагностика сети была бы более эффективной, если бы можно было указать, что широковещательная рассылка без скачка должна быть отправлена ​​ровно один раз (если отправить 10 посылок). после того, как no-hop сделает широковещательную рассылку узлу по 50% надежному каналу и спросит, сколько он получил, он, вероятно, получит около 5. Если каждый широковещательный запрос на самом деле отправляет сообщение четыре раза, то получатель будет лучше, чем даже шанс получить все 10, что не дает информации о фактической надежности канала). Далее, если каждый узел знает, что онесли нет необходимости поддерживать маршрутизируемый обмен сообщениями или синхронный спящий режим, можно уменьшить объем передаваемой информации на 75% при хороших условиях, отправляя каждое широковещательное сообщение только один раз, сохраняя при этом надежную работу в плохих условиях.

Короче говоря, использование функций ячеистой маршрутизации Digi требует, чтобы параметры, связанные с вещанием, были установлены таким образом, чтобы сделать вещание неэффективным. Если вы реализуете собственную маршрутизацию, повторную передачу и логику управления спящим режимом, широковещательные рассылки могут быть более эффективными.

Возвращаясь к вашему сценарию, одна трансляция в минуту — это достаточно низкий уровень трафика, поэтому вам, вероятно, не стоит об этом беспокоиться. Уровень широковещательных рассылок для насыщения сети с использованием настроек по умолчанию будет составлять где-то около десяти широковещательных передач в секунду, разделенных на размер наибольшей группы узлов, находящихся в пределах досягаемости друг друга.