独自Bluetooth広告からMeshへ：マルチホップ化に必要な設計

独自のBluetooth広告で照明を制御できているとします。コントローラーが「点灯」を送り、近くの照明が受信して点く。機器もアプリも自分たちの管理下にあり、プロトコルも単純です。

次は範囲を広げたい。寝室まで届かないので、廊下の照明に転送してもらえばよさそうです。最初の実装は、既知のパケットを受け取って再送するだけに見えます。

しかし廊下に照明が二つあると、双方が転送し、別経路のコピーが届き、近隣ノードから戻ってくることもあります。このメッセージは見たか、さらに転送するか、実行済みか、送信元は結果を知っているか。 判断が増えます。

前回は独自Mesh、SIG Mesh、Xiaomi Meshの関係を整理しました。今回は独自広告方式に本当のマルチホップ機能を加える際に必要な設計を考えます。

以下の「コントローラー—中継—照明」は説明用の仮想ネットワークで、特定製品の実測ではありません。信頼性を検討してから、自前のMeshを維持する価値を判断します。

1．転送しても変わらないメッセージの識別情報

単一ホップでは、どのバイトがオン・オフや明るさを表すかに注目しがちです。中継を加えると、メッセージの識別も同じくらい重要になります。

Aの要求をBとCが転送し、Dが二つのコピーを受信したとき、同じ送信の複製だと分かる必要があります。中継器が自分を発信元とする新しい業務コマンドに変えてしまうと、元のメッセージで重複判定できません。直接の無線送信者が変わっても、元の送信者と識別情報は保持します。

情報	答える問い
ネットワーク／セキュリティ領域	どのシステムか。この値だけで信用はできない
元の送信元と宛先	誰が開始し、個体かグループのどちらへ送るか
シーケンス番号と必要な世代情報	新しい伝送メッセージか、既知のコピーか
転送予算	あと何回の中継を許可するか
業務要求ID	複数の伝送が同じ操作を試みているか
操作、引数、認証情報	何を求め、正当で、改変されていないか

これは責務の整理であり、そのまま実装するパケット形式ではありません。配置、長さ、認証範囲を、アドレス、鍵管理、分割方式と合わせて設計します。

同一パケットのコピーと、同じ操作を再試行するための新しい送信は、必ずしも同じものではありません。 この区別が二重実行の防止に関わります。

2．転送を有限の動作にする

転送予算を中継ごとに減らし、使い切ったら転送を止める方法があります。ループがあっても伝播範囲を制限できます。

ただし、それだけでは一つのノードが同じメッセージを何回処理するかは決まりません。Bが転送後にCから同じコピーを受け取ることがあります。最近のメッセージIDをキャッシュし、同じIDで新たな転送処理を開始しないようにします。

「重複はすべて破棄」で済むわけでもありません。ネットワーク層は重複伝播を抑え、業務層は再試行に保存済み結果を返す場合があります。一つの「既知」フラグだけで両方を代替してはいけません。

キャッシュ期間が短ければ遅いコピーを新規扱いし、長ければメモリを消費して番号再利用も複雑になります。メッセージ発生率、伝播時間、再試行期間から見積もり、負荷試験で確認します。

必要な形式、ネットワーク、認証の検査を済ませてから、信頼できる処理状態へ登録することも重要です。偽のパケットで先に記録を埋められ、本物を重複として捨てることがあってはいけません。

Bluetooth SIGの入門文書には中継とTTLの説明があります。ただし、独自方式の転送予算がSIG MeshのTTLと同じ意味を持つとは限らず、数値をそのまま比較するべきではありません。

3．誰が、いつ中継するかを決める

受信できた機器がすべて即座に転送すると、同時送信による衝突が増える可能性があります。コピーを増やしたのに受信が難しくなることもあります。

中継資格、転送時刻、有限回の繰り返し、キュー上限を一緒に考えます。制御されたランダム遅延で競合の同期を崩し、一つのメッセージが生む送信数を制限してキューの膨張を防ぎます。

遅延は長いほどよいわけではなく、ホップごとに応答時間へ加算されます。再送増加も混雑時には逆効果です。「全照明を中継器にする」「損失時は再送を倍増する」を既定方針にはせず、配置、給電、負荷を見ます。

連続スキャンと他機器の中継には電力が必要です。電池スイッチが自分の押下イベントを送れるからといって、常時中継に適するとは限りません。

SIG MeshのLow PowerとFriendでは、Friendが一時保存を担い、低消費電力ノードの常時受信を減らします。独自方式で眠る機器へ命令を届けるなら、受信時間帯、バッファなどの調整が必要です。「電池対応」と書くだけでは完成しません。

4．どの層での成功かを明確にする

これはパケット設計より先に話しておきたい部分です。Bluetoothモジュールの「送信完了」は、モジュールが対応する処理を終えたことを示すだけです。寝室の照明への到着や点灯まで証明しません。

宛先から応答があっても、受信、受理、実行、物理状態の観測のどれなのかを定義します。リレー出力をオンにしたことは報告できても、電流などのフィードバックがなければ負荷が動作したかは分かりません。画面表示も観測能力に合わせます。

中継器が最終機器の成功を代弁してはいけません。それは中間ホップへの到着確認にすぎません。最終状態が必要な操作には、要求と対応付けたエンドツーエンド応答が必要です。

一方、全部に確認応答を付けるとグループ制御で問題になります。一度の消灯命令に全照明が即応し、それが中継されると、戻りの通信が下りより増えかねません。SIG文書も、確認付きメッセージは単一宛先に適する一方、大規模グループでは拡張性が下がると説明しています。

重要設定は個別確認、通常のグループ制御は有限再送と分散した状態照会、全体結果が必要なら集約とタイムアウトを定義する、といった使い分けが考えられます。状態確認を省きながら「全機器が成功」とは表示できません。

5．再試行で点灯が点滅に変わらないようにする

照明は実行したものの応答が失われ、コントローラーが再試行したとします。「状態を反転」なら二回実行して元に戻り、一瞬光って消える可能性があります。

「オン状態に設定」なら通常この問題を避けられます。目標状態の操作では、繰り返しても効果を変えない設計が役立ちます。

しかし「モーターを一歩進める」「一回減算」「タイマーを開始」は副作用が重複し得ます。要求ID、結果記録、復旧方針が必要です。伝送シーケンスと業務要求IDを分ければ、新たな送信は安全規則に従い、業務層は以前の操作と認識して結果を返せます。

さらに、最初に明るさ30%、次に80%を要求した後で、古い30%の再試行が届くと状態が戻ります。どちらも単独では繰り返しに強い目標状態コマンドですが、順序が崩れると正しくありません。

制御フロー内の版管理、要求の期限、新操作による古い再試行の取消など、順序と有効性を扱う必要があります。複数の制御元があるなら上書き規則も必要です。

繰り返せることと正しい結果は別です。動作直後、結果保存前に電源が落ちる機器に、絶対に一度だけの実行を安易に約束してはいけません。

6．再起動で安全状態まで初期化しない

近くで放送を受信できる人は、正当な命令を記録して後から再送できるかもしれません。暗号化だけでは十分ではなく、改変のない古い暗号文も不適切な時点で再投入できます。

短期の重複キャッシュとリプレイ防御状態は別です。メモリ節約のためキャッシュを消しても、古い操作の権限が復活してよいわけではありません。

送信側の再起動でシーケンスやnonceを危険に再利用しないか。受信側が状態を忘れて旧メッセージを受け入れないか。工場出荷リセット、再参加、鍵更新でどう扱うか。両側を考えます。

同一鍵の下でnonceの一意性を要求する認証暗号では、RAM上のカウンターを起動ごとにゼロへ戻すだけでは不十分です。鍵を共有する複数送信者の衝突も避ける必要があります。具体的な構成は、採用するアルゴリズムと成熟したプロトコルの要件に従います。

RFC 5116は認証暗号とnonceを扱い、そのインターフェース自体は完全なリプレイ防御やアクセス制御を提供しないと明示しています。「AESを使った」でこの区別を隠してはいけません。

永続化にはFlash書き込み頻度、電源断時の整合性、復旧の問題もあります。永続化した境界を使ってカウンター範囲を予約する方法は一案ですが、途中の電源断で巻き戻りや再利用が起きないことを示す必要があります。通常の再起動試験だけでは足りません。

鍵のライフサイクルも初版から必要です。安全な追加、紛失・転売時の除外、権限失効を扱います。アプリの機器一覧から削除しても、機器内の鍵は自動では失効しません。

7．まず短いメッセージ、その後に分割と更新

スイッチ命令は短く、試作ではサイズを見落としがちです。大量設定、長い属性、ファームウェアでは、分割識別、再構成、欠落回復、保持期限、同時再構成数が問題になります。

BLE広告、拡張広告、SDKの理論容量を、そのまま業務ペイロードにしてはいけません。ヘッダー、セキュリティ情報、対応機器、ベアラーが容量を制約します。

分割すると一つの操作が複数の無線パケットとなり、それぞれ中継される可能性があります。再試行設計が悪いと、少量の設定でも通常の制御を圧迫します。

私はまず短い制御、状態報告、復旧を固めます。OTAは伝送、流量制御、署名確認、失敗復旧を別途設計します。Meshでデータが運べても、信頼できる更新システムがあることにはなりません。

動くデモを超えたか、どう検証するか

多数ノードを目指す前に、少数で障害経路を露出させます。以下は実施を提案する試験で、測定結果ではありません。

状況	観察点
同じ命令が二つの中継から到着	コピー数の制限と二重実行の有無
実行後に応答を喪失	副作用を繰り返さず、既知の結果を返せるか
新命令の後に古い再試行が到着	新しい状態を上書きしないか
中継器の停電・移動	代替経路があれば継続し、なければ失敗を正しく示すか
一斉報告とグループ応答	遅延、失敗率、再送数、キューの悪化
送受信側の重要時点で電源断	シーケンス、nonce、要求記録、リプレイ防御の復旧
機器の除外・再参加	古い鍵、メッセージ、関係で不正な動作が残らないか

測定の始点と終点も定義します。アプリ要求から無線送信までか、機器の実行報告までか。実負荷を観測するセンサーがなければ、後者を実際の照明応答時間とは呼べません。

平均だけでなく、遅い側の分布、タイムアウト、二重実行、送信数を記録します。中央値やP95には標本数と失敗件数を添え、タイムアウトをすべて除外して成功だけの数字を示さないようにします。配置、電源、Wi-Fi干渉、スキャン設定、業務頻度も記録しなければ、別の日の結果と比較できない可能性があります。

ここまで整理して、自研範囲を決める

広告を一度転送するだけなら数行でも、保守可能なネットワークには、識別、アドレス、有限中継、重複、確認、業務再試行、安全状態、復旧、診断が必要です。

すべての製品がSIG Meshを再実装する必要はありません。用途が限定され、機器を完全管理でき、既存製品が多いなら独自方式にも価値があります。何を省略し、それが要求に合うかを理解することが重要です。

「既存の広告方式が簡単だから」という理由だけなら、試作中に保守費用を見積もりましょう。成熟した既製方式や標準スタックで、製品機能とゲートウェイ業務に時間を残せるかもしれません。

私たちのMatterゲートウェイでは、機器の振る舞い、状態変換、異常処理を自分たちで管理する価値が大きいと考えています。無線層をどこまで作るかは、最初に動くかだけでなく、継続的な検証と保守で決めます。

次回はSIG Meshに戻り、発見、Provisioning、実際のスイッチ操作の間に何が起きるかを扱います。ネットワーク鍵、アプリケーション鍵、モデルのバインド、Publish/Subscribeをつなげて説明します。

既存の独自広告方式があるなら、なぜ中継が必要か、常時給電の機器はどれか、許容できない失敗は何かから整理できます。こちらからぜひ相談してください。