Почему Bluetooth Mesh начинает тормозить, когда ретрансляторов становится больше?

Светильник в конце коридора иногда не реагирует, и вы включаете функцию ретрансляции на нескольких ближайших светильниках.

Похоже, это помогает. Тогда вы включаете её на всех светильниках с поддержкой Relay и увеличиваете число повторных передач: «Если отправить ещё несколько раз, сообщение уж точно дойдёт».

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

Возможно, проблема уже не в том, что сообщение не доходит, а в том, что в одном и том же радиоэфире передаётся слишком много сообщений.

Ретрансляция добавляет маршруты доставки, но каждая пересылка занимает радиоресурсы. Чтобы понять, нужно ли добавить ретрансляторы или сократить их число, сначала определите, чего не хватает: покрытия, резервного маршрута или свободного эфира, перегруженного дублирующим трафиком.

Описанная ситуация — условный пример, а не запись результатов испытаний. В статье рассматриваются преимущественно сети SIG Mesh, использующие широковещательную передачу и Managed Flooding (управляемое лавинное распространение сообщений); выводы не относятся ко всем реализациям продуктов Bluetooth. Задержка, ёмкость сети и доля успешных доставок на конкретных устройствах не измерялись. Предложенный порядок диагностики — инженерная рекомендация.

Расположение ретрансляторов и перекрывающиеся передачи в офисах и коридоре

Иллюстрация создана ИИ. Дуги не обозначают измеренное покрытие, уровень сигнала или реальные маршруты.

1. Ретранслятор передаёт сообщение из другого места, а не «усиливает сигнал до максимума»

Рассмотрим простой маршрут:

Настенный выключатель → ретранслятор в коридоре → удалённый светильник.

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

При этом мощность передатчика выключателя не увеличивается, а для команды управления не выделяется отдельный канал.

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

В статье Bluetooth SIG о проектировании сетей и руководстве Silicon Labs по оптимизации подчёркивается один и тот же принцип: у ретранслятора должны быть обоснованные место установки и задача; включать Relay на каждом поддерживающем его устройстве не следует.[1][2]

Поэтому перед добавлением ретранслятора спросите себя:

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

Если ответов нет, вы, возможно, добавите главным образом повторные передачи, а не полезное покрытие.

2. Почему сеть загружена, если дублирующие пакеты фильтруются?

Легко предположить: «Mesh отбрасывает дубликаты, значит, количество ретрансляторов не имеет значения».

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

Например, ретрансляторы B и C получили сообщение от A. При первом получении каждый из них может удовлетворять условиям пересылки. Узел D затем получит копии от B и C и распознает дубликат, но обе передачи к этому моменту уже состоялись.

При этом важно различать две ситуации:

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

Первую ситуацию ограничивают, в частности, механизмы кэширования; вторая представляет собой повторные передачи, заданные конфигурацией. Противоречия здесь нет. Во вводных материалах SIG TTL и кэш сообщений названы механизмами ограничения Managed Flooding; в документации Silicon Labs отдельно описаны настройки Network Transmit и Relay Retransmit.[2][3]

Что проверить сначала? Не ограничивайтесь записью в журнале приложения о том, что «получена одна команда». Однократная передача команды на уровень приложения не доказывает, что в эфире она отправлялась только один раз. Сопоставьте счётчики стека протоколов, записи очереди отправки и данные доступных средств захвата пакетов, чтобы выяснить, на каком уровне возникают повторы. Один пункт захвата тоже может пропускать пакеты, поэтому его данные нельзя считать полной картиной трафика всей сети.

3. Не называйте четыре разных настройки «усилением сигнала»

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

Эти изменения действуют по-разному:

Настройка	Что главным образом меняется	Что выяснить перед изменением
Включение Relay и размещение ретрансляторов	Какие узлы участвуют в пересылке и где существуют маршруты связи	Устраняется зона без покрытия или добавляются повторные пересылки там, где покрытие уже есть?
TTL	Допустимое число переходов сообщения между узлами	Где находятся управляемые устройства и насколько длинным должен быть необходимый резервный маршрут?
Network Transmit / Relay Retransmit	Число копий, передаваемых исходным узлом или ретранслятором на сетевом уровне, и интервалы между ними	Поле в используемом SDK означает число повторных передач или общее число передач?
Публикация моделей, запросы и повторы на уровне приложения	Сколько сообщений создаёт прикладная логика и когда они отправляются снова	Нет ли частых отчётов о состоянии, массовых запросов или повторной отправки одной и той же команды?

TTL особенно часто используют неверно. Он ограничивает область распространения сообщения, а не задаёт радиомощность или процент надёжности. Сообщение с TTL, равным 0, не ретранслируется; до устройства, доступного только через ретранслятор, такое сообщение не дойдёт.[3]

Но из этого не следует, что TTL всегда нужно устанавливать большим. «Сообщение может уйти дальше» не означает, что «этот светильник с большей вероятностью его получит». Избыточное распространение может дополнительно нагрузить другие зоны.[1]

Кроме того, значение «3» в интерфейсе настройки может означать три передачи или три повторные передачи. Включена ли в это число первоначальная отправка, нужно выяснять по интерфейсу SDK и кодированию параметра. Пока значение поля неясно, не копируйте чужие числа.

4. Как отличить недостаточное покрытие от избытка сообщений?

Не делайте вывод из одного случая, когда «в этот раз снова сработало». Сначала проведите два сравнения при неизменных устройствах, их расположении и командах управления.

Первое: сохраняется ли проблема на удалённом участке при низкой нагрузке?

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

Это ещё не окончательный диагноз: на результат также могут влиять установка антенны, препятствия, питание и ошибки конфигурации.

Второе: появляется ли проблема при росте нагрузки без изменения расположения устройств?

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

Silicon Labs прямо предупреждает, что слишком частая публикация сообщений модели увеличивает сетевой трафик и замедляет отклик.[2] Но улучшение после снижения частоты лишь сужает область поиска: само по себе оно не доказывает, что все неполадки вызваны коллизиями в радиоэфире.

Есть и ещё один вопрос, который часто упускают: медленнее меняется свет или медленнее приходит информация о состоянии?

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

5. Если менять настройки, сохраняйте данные на каждом шаге

Ниже приведён практический порядок совместной отладки, а не стандартная методика испытаний, установленная протоколом.

Сначала зафиксируйте исходное состояние. Запишите версии прошивки и SDK, расположение устройств, настройки Relay и TTL, повторные передачи на сетевом уровне, период публикации моделей, а также правила запросов и повторных попыток на управляющей стороне. При экспорте конфигурации скройте ключи. Без исходных данных трудно определить, какое именно изменение привело к улучшению.

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

После этого меняйте только одну категорию параметров за раз. При неизменной прикладной нагрузке сравните конфигурации ретрансляторов. Затем, сохранив их расположение и настройки, сравните параметры повторных передач или частоту публикации. Так можно оценить влияние каждого изменения. Не нужно устранять весь запас надёжности ради минимального числа передач.

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

Для каждого этапа сохраняйте как минимум следующие данные:

Что фиксировать	Как записать, чтобы результаты можно было сравнить
Условия проверки	Одинаковые расположение, действия, нагрузка и интервал наблюдения; укажите, что именно изменено на этом этапе
Результат управления	Записывайте результат для каждой пары «целевое устройство × команда управления»; неизвестное состояние выделяйте отдельно, не объединяя с подтверждённым успехом
Время отклика	Указывайте начальное и конечное события: отправка запроса, получение состояния модели или фактическое изменение освещения
Медленные ответы и аномалии	Сохраняйте число наблюдений, данные по медленным ответам и места отказов, а не только среднее значение
Резервный маршрут	Какие устройства затронуты после отключения ключевого ретранслятора и восстановилась ли работа после его включения

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

Цель этого этапа — не найти минимально возможный TTL или наименьшее число ретрансляторов. Цель — сохранить достаточно надёжные маршруты при обычной нагрузке и согласованных условиях отказа, сократив при этом ненужные передачи.

6. Можно ли перейти на Directed Forwarding и больше об этом не думать?

В Bluetooth Mesh также предусмотрен необязательный механизм Directed Forwarding (направленная пересылка). Он позволяет пересылать соответствующие сообщения узлам, участвующим в определённом маршруте, вместо того чтобы задействовать все ретрансляторы, отвечающие условиям Managed Flooding. Это сокращает ненужные радиопередачи.[3]

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

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

Когда удалённое устройство в следующий раз «иногда не ответит», не включайте сразу все ретрансляторы.

Сначала ответьте на вопрос: какой именно участок маршрута дополнит новый ретранслятор?

Если проблема возникает только при высокой нагрузке, задайте другой вопрос: какие сообщения в этой сети не нужно отправлять так много раз?

Источники и область применимости

Bluetooth SIG: How Bluetooth Mesh Networking puts the ‘large’ in large-scale wireless networks, 2018-06-26. В статье использованы принципы проектирования из разделов Relays, TTL и Network retransmissions; приведённые там примеры масштабов сети, интервалов повторной передачи и кратности трафика не используются как показатели для продуктов.
Silicon Labs: Bluetooth Mesh Networking Principles, 11.0.2. Источник использован для проверки рекомендаций о плотности ретрансляторов, частоте публикации и настройках передачи на сетевом уровне; конкретные интерфейсы и значения параметров необходимо сверять с целевым SDK.
Bluetooth SIG: The Bluetooth Mesh Networking primer. Прежде всего использованы разделы 4.18.1, 4.19.2 и 4.19.3 для проверки сведений о TTL, кэшировании, Managed Flooding и Directed Forwarding.

Дата проверки источников: 2026-11-06. Испытания оборудования для этой статьи не проводились; универсальные оптимальные параметры, фиксированная ёмкость сети и гарантии повышения производительности не приводятся.