Bluetooth Meshは中継を増やすほど、なぜかえって反応が遅くなるのか？

廊下の突き当たりにある照明が、ときどき操作に反応しない。そこで、近くにある数台の照明で中継機能を有効にした。

効果はありそうだ。それならと、Relayに対応する照明をすべて有効にし、再送回数も増やす。「何度か送り直せば、届き損ねることはないだろう」

ところが、グループ全体を調光すると、照明の反応がまた鈍くなる。先に動くものもあれば、遅れて動くものもあり、スマートフォンの状態表示はまだ更新中だ。

問題は「メッセージが届かない」ことから、「同じ無線空間で送信するものが多すぎる」ことに変わっているかもしれない。

中継は通信経路を増やせるが、転送のたびに無線リソースを使う。次に中継を増やすべきか減らすべきか判断するには、足りないものがカバレッジなのか、予備経路なのか、それとも重複トラフィックがすでに多すぎるのかを見極める必要がある。

上記は仮定の例であり、実測記録ではない。本記事では、Advertising Bearer（アドバタイジングベアラ）とManaged Flooding（管理されたフラッディング）を主に用いるSIG Meshネットワークを扱い、すべてのBluetooth製品の実装に当てはまるものではない。特定の機器の遅延、容量、成功率は測定していない。以下の切り分け手順は、エンジニアリング上の提案である。

オフィスと廊下における中継の配置と重複送信の概念図

AI 生成のイラストです。電波の弧は実測したカバレッジ、信号強度、実際の経路を示すものではありません。

一、中継はメッセージを別の場所から送る仕組みであり、電波を「強くする」ものではない

まず、単純な経路を見てみよう。

壁のスイッチ → 廊下の中継ノード → 遠くの照明。

スイッチの電波は遠くの照明に直接届かないが、廊下のノードならメッセージを受信して転送できる。これが中継の価値だ。直接は届かなかった区間を、メッセージが越えられるようになる。

スイッチの送信出力が上がるわけでも、その制御コマンド専用の通信チャネルが確保されるわけでもない。

同じ部屋にRelayを有効にしたノードが多数あれば、転送条件を満たすメッセージをそれぞれが受信し、転送に参加する可能性がある。複数の経路は到達の機会を増やす一方、無線送信も増やす。

Bluetooth SIGのネットワーク設計記事とSilicon Labsのチューニング資料は、いずれも同じ点を強調している。中継は設置場所と役割を考えて使うものであり、対応機器を見つけ次第すべて有効にするものではない。[1][2]

したがって、「中継をもう一つ増やす」前に、次を確認したい。

これまで不安定だった経路の、どの区間をつなげるのか？
既存のノードとは異なる予備経路を提供できるのか？
壁のスイッチと一緒に電源が切れることはないか？

どれにも答えられないなら、増えるのは有効なカバレッジではなく、主に重複送信かもしれない。

二、重複パケットを除去するのに、なぜ通信が混み合うのか？

「Meshは重複パケットを除去するのだから、中継がいくら増えても問題ないのでは？」という誤解が生じやすい。

重複の検出は、あるノードが受信済みのパケットを繰り返し処理することを防げる。しかし、ほかのノードがすでに送信した電波を消すことはできない。

たとえば、中継ノードBとCがどちらもAからのメッセージを受信したとする。それぞれが初めて受信した時点では、両方とも転送条件を満たしうる。その後、DはBとCから届いたコピーを重複と認識できても、二つの送信はすでに行われている。

また、次の二つは区別する必要がある。

中継ノードがほかのノードから重複コピーを受信しても、それをきっかけに際限なく新たな転送を始めるわけではない。
信頼性を高めるため、送信元や中継ノード自身が、設定に従って複数のコピーを送信することがある。

前者はキャッシュなどの仕組みで制約され、後者は設定による反復送信だ。両者は矛盾しない。SIGの入門資料はTTLとメッセージキャッシュをManaged Floodingの制約手段として挙げ、Silicon Labsの資料はNetwork TransmitとRelay Retransmitの設定も説明している。[2][3]

最初に何を調べるべきか？ アプリケーションのログに「コマンドを1件受信」とあるだけで判断しないこと。アプリケーション層への通知が1回でも、無線上の送信が1回だったとは証明できない。プロトコルスタックのカウンター、送信キューの記録、利用可能なパケットキャプチャツールを組み合わせ、どの層で重複しているか確認する。キャプチャ地点が一つだけではパケットを取り逃す可能性もあり、その結果をネットワーク全体のトラフィックとしてそのまま扱うことはできない。

三、四つの異なる調整項目を、すべて「電波を強くする」と呼ばない

現場でパラメーターを調整する際、判断を難しくしやすいのは、中継を増やし、TTLを上げ、再送を増やし、さらにアプリケーションからも再試行することを同時に行うやり方だ。

それぞれの作用は異なる。

調整項目	主に何が変わるか	調整前に確認すること
Relayの有効化と配置	どのノードが転送に参加し、どこに通信経路ができるか	圏外区間を補うのか、既存のカバレッジ内で重複転送を増やすだけなのか？
TTL	メッセージが越えられるホップ数の範囲	制御対象はどこにあり、必要な予備経路はどこまで延びるのか？
Network Transmit / Relay Retransmit	送信元ノードまたは中継ノードがネットワーク層で送るコピーの数と間隔	使用中のSDKのフィールドは再送回数を表すのか、総送信回数を表すのか？
モデルのPublish、照会、アプリケーションの再試行	業務ロジック層が生成するメッセージの量と、再送するタイミング	高頻度の状態報告、一斉照会、重複したコマンド送信はないか？

特にTTLは誤用されやすい。TTLが制限するのはメッセージの伝播範囲であり、無線の送信出力でも、信頼性のパーセンテージでもない。TTLが0のメッセージは中継されない。中継を経なければ届かない機器に、そのメッセージを届けることはできない。[3]

だからといって、TTLを一律に大きくすればよいわけでもない。「メッセージがより遠くまで進める」ことは、「目の前の照明に届きやすくなる」ことと同じではない。不要な伝播は、ほかのエリアの負荷を増やす可能性もある。[1]

また、設定画面の「3」は、送信3回を意味する場合も、再送3回を意味する場合もある。最初の送信を別に数えるかどうかは、SDKのインターフェースとパラメーターの符号化を確認する必要がある。フィールドの意味を把握する前に、ほかの人の設定値をそのまま使わないこと。

四、カバレッジ不足とメッセージ過多をどう見分けるか？

一度「さっきは動いた」だけで結論を出さない。まず、機器、位置、制御操作を固定して、二組の比較を行う。

第一の比較：低負荷でも、問題は遠くの機器で繰り返し起きるか？

テスト環境で必要な制御は残しつつ、調整可能なバックグラウンドの照会や状態報告を減らす。それでも遠くの機器に繰り返し届かず、狙いを定めて一つの中継位置を変えると明らかに改善するなら、カバレッジや経路の問題を優先して調べる価値がある。

ただし、これだけで確定はできない。アンテナの取り付け、遮蔽物、電源、設定ミスなども結果に影響しうる。

第二の比較：機器の位置を変えず、通信量が増えたときに問題が起きるか？

単発のオン・オフ操作は問題なくても、高頻度の調光、一括照会、定期的な状態報告を始めると遅延が出る。そのうち一種類のトラフィックを減らして改善するなら、すぐに中継を増やすのではなく、無線上の負荷、プロトコルスタックのキュー、ゲートウェイの処理能力を引き続き調べるべきだ。

Silicon Labsは、モデルのPublish頻度が高すぎるとネットワークトラフィックが増え、応答が遅くなると明示している。[2] ただし、「頻度を下げたら改善した」という結果だけで、すべての問題が無線上の衝突によるものだとは証明できない。

もう一つ、見落とされがちな確認がある。遅くなったのは照明の動作か、それとも状態が返ってくるまでの時間か？

前の記事では、送信側による受付、機器のモデル状態、実際の点灯を区別した。チューニング時もそれぞれを記録しないと、「画面の更新が遅い」ことを理由に、問題のない照明制御経路を調整してしまう可能性がある。

五、実際に調整するなら、この順序で記録を残す

以下は実行可能な共同検証の手順であり、プロトコルが定める標準試験ではない。

まずベースラインを保存する。 ファームウェアとSDKのバージョン、機器の位置、中継のオン・オフ、TTL、ネットワーク層の再送、モデルのPublish周期、制御側の照会・再試行方針を記録する。設定をエクスポートするときは鍵を隠す。ベースラインがなければ、「改善した」ことがどの変更に対応するのか分かりにくい。

次に、中継ごとの役割を明記する。 平面図上で、どのノードが部屋をまたぐ通信を担い、どれが廊下を担当し、どれが予備のカバレッジを提供するか示す。まず、それらの役割を担うノードを残し、カバレッジが大きく重なる中継を段階的に評価する。一度に広範囲の中継を無効にしないこと。遠隔設定によって唯一の管理経路を切断することも避け、テスト前に現場で復旧する手段を用意する。

その後は、一度に一種類の変数だけを変える。 まず通信負荷を固定して中継設定を比較し、次に中継の配置を固定して反復送信やPublish頻度を比較する。そうして初めて変更の影響を判断できる。送信量を最小にするために、信頼性を確保する冗長性をすべて取り除く必要はない。

最後に、繁忙時と障害時を測る。 アイドル時に制御できるだけでは、確認は半分しか終わっていない。製品要件に沿った調光、状態報告、照会の負荷でもテストし、中継を担うノードを計画的に一つオフラインにしてから復旧させる。

各回で、少なくとも次の記録を残す。

記録項目	比較に役立つ記録方法
テスト条件	位置、操作、負荷、観測時間をそろえ、その回で変更した点を明記する
制御結果	「対象機器 × 制御操作」ごとに結果を記録する。状態不明は別に分類し、成功が確認されたものに含めない
応答時間	起点と終点を明記する。要求の送信、モデル状態の返信、実際の照明の変化のどれを測ったか区別する
遅い応答と異常	サンプル数、応答が遅かったサンプル、失敗した場所を残し、平均値だけを報告しない
予備経路	重要な中継がオフラインになったときに影響を受けた機器と、復旧後に正常に戻ったかを記録する

実際に照明が変化するまでの時間を比較するには、適切な現場観測または測定手段が必要だ。アプリケーションのログだけでは、物理的な結果の代わりにならない。

この一連の調整の目標は、見かけ上最小のTTLや、最少の中継数を選ぶことではない。通常の負荷と合意した障害条件の下で、十分に信頼できる経路を維持しながら、不要な送信を減らすことが目標だ。

六、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。中継ノードの密度、Publish頻度、ネットワーク層の送信設定の確認に使用した。具体的なインターフェースとパラメーター値は、対象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。本記事ではハードウェア試験を行っておらず、汎用的な最適パラメーター、固定のノード収容数、性能向上の保証は提示しない。