От собственного Bluetooth-вещания к Mesh: что нужно для многоскачковой сети

Допустим, у вас уже есть управление через Bluetooth-рекламу: контроллер передаёт «включить», ближайшие лампы принимают команду и загораются. Устройства и приложение под вашим контролем, протокол прост.

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

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

В первой части мы разобрали отношения собственного Mesh, SIG Mesh и Xiaomi Mesh. Теперь рассмотрим, что требуется добавить к собственному широковещательному протоколу для настоящей многоскачковой связи.

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

Шаг 1. Идентичность сообщения не должна меняться при пересылке

В односкачковом управлении внимание обычно уделяют байтам включения и яркости. С ретрансляцией идентичность сообщения становится не менее важной.

Контроллер A отправляет запрос, B и C пересылают его, D получает две копии. D должен распознать одну исходную передачу. Ретранслятор не должен превращать её в новую прикладную команду от своего имени. Непосредственный радиопередатчик меняется, но исходный отправитель и идентификатор сохраняются.

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

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

Копия одного пакета и новая передача для повторной попытки той же операции — не обязательно одно и то же. От этого зависит защита от двойного исполнения.

Шаг 2. Сделать пересылку конечной

Бюджет пересылки уменьшается на каждом ретрансляторе; после исчерпания сообщение дальше не идёт. Это ограничивает распространение даже при петлях.

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

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

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

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

В руководстве Bluetooth SIG описаны ретрансляция и TTL. Собственный бюджет решает похожие задачи, но не обязательно имеет ту же семантику; напрямую сравнивать численные значения нельзя.

Шаг 3. Решить, кто и когда ретранслирует

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

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

Большая задержка увеличивает время реакции, накапливаясь по пути. Дополнительные повторы при перегрузке могут вытеснять полезный трафик. «Сделать все лампы ретрансляторами» и «удваивать повторы при потерях» — плохие универсальные правила. Нужны данные о размещении, питании и нагрузке.

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

Механизмы SIG Mesh Low Power и Friend распределяют обязанности: Friend временно хранит сообщения, позволяя малопотребляющему узлу не слушать постоянно. Собственному решению для спящих устройств нужны окна приёма, буферы или иная координация. Надписи «поддерживает батарейки» недостаточно.

Шаг 4. Определить, на каком уровне наступает успех

Это стоит обсудить ещё до формата пакета. Ответ Bluetooth-модуля «передача завершена» описывает работу модуля. Он не доказывает, что лампа в спальне получила команду или действительно загорелась.

Даже ответ адресата требует определения: получено, принято, выполнено или физически подтверждено? Контроллер реле может сообщить об установке выхода. Без измерения тока или иной обратной связи он не знает, сработала ли нагрузка. Интерфейс должен отражать наблюдаемые возможности.

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

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

Важные настройки можно подтверждать индивидуально; обычное групповое управление — ограниченно повторять и постепенно сверять состояния; для полного результата определить агрегацию и тайм-ауты. Гарантия должна быть явной. Без проверки состояния нельзя показывать «все устройства успешно выполнили».

Шаг 5. Повтор не должен включать и тут же выключать лампу

Лампа выполнила команду, но ответ потерялся. Контроллер повторяет запрос после тайм-аута. Если команда означает «переключить», два исполнения возвращают исходное состояние: пользователь видит вспышку и темноту.

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

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

Остаётся тонкая ошибка: сначала запрошено 30% яркости, затем 80%, но старый повтор приходит последним и возвращает 30%. Обе команды по отдельности безопасны к повторению, однако состояние откатилось.

Поэтому нужны порядок и актуальность: версии в одном потоке управления, срок действия, отмена старых повторов новой операцией. При нескольких контроллерах требуется правило перезаписи.

Повторяемость не равна правильности. Нельзя безоговорочно обещать exactly-once устройству, которое может потерять питание после действия, но до записи результата.

Шаг 6. Перезапуск не должен обнулять безопасность

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

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

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

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

RFC 5116 рассматривает аутентифицированное шифрование и nonce, прямо отделяя свой интерфейс от полноценных механизмов anti-replay и контроля доступа. Фраза «у нас AES» может скрывать эту разницу.

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

Жизненный цикл ключей нужен с первой версии: безопасное добавление, исключение потерянного или проданного устройства и отзыв полномочий. Удаление строки в приложении не отзывает ключи внутри устройства.

Шаг 7. Сначала короткие сообщения, потом фрагментация и обновления

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

Теоретический размер BLE-рекламы, расширенной рекламы или возможностей SDK не равен полезным данным приложения. Заголовки, безопасность, поддержка устройств и транспорт накладывают ограничения.

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

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

Как проверить, что это больше, чем работающий демонстратор

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

Сценарий	Что наблюдать
Команда приходит через два ретранслятора	Ограничение копий и отсутствие двойного исполнения
Ответ потерян после исполнения	Повтор без новых побочных эффектов, возврат известного результата
Новая команда приходит раньше старого повтора	Не перезаписывается ли актуальное состояние
Ретранслятор выключен или перемещён	Работа при запасном пути и честный отказ без пути
Одновременные отчёты и групповые ответы	Задержки, ошибки, передачи и давление на очереди
Питание отправителя и получателя отключается в важных точках	Восстановление последовательностей, nonce, запросов и anti-replay
Устройство удалено или заново введено в сеть	Не дают ли старые ключи, сообщения и связи лишних полномочий

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

Кроме среднего нужны хвост распределения, тайм-ауты, двойные исполнения и число передач. Медиану и P95 сопровождают размером выборки и отдельной статистикой отказов. Исключать все тайм-ауты ради красивых успешных результатов нельзя.

Фиксируйте размещение, питание, помехи Wi-Fi, сканирование и частоту трафика. Иначе результаты разных дней могут быть несопоставимы.

После этого решите, сколько разрабатывать самостоятельно

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

Не каждый продукт обязан заново реализовывать SIG Mesh. Узкая задача, управляемые устройства и большая установленная база могут оправдать собственное решение. Важно знать, какие возможности исключены и соответствуют ли эти ограничения требованиям.

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

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

Далее вернёмся к SIG Mesh: что происходит между обнаружением устройства, Provisioning и реальным управлением выключателем? Сетевые и прикладные ключи, привязка моделей, публикации и подписки дадут конкретные примеры.

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