標準的な Bluetooth Beacon はただ送信するだけだ。タイマーで起きてアドバタイジング・パケットを流し、また眠る。このモデルは、その電波を聞くゲートウェイかスマホが電波到達圏内にいることを前提としている。しかし 40,000 m² の倉庫、多階層の病院、貨物ヤード、トンネル——ゲートウェイ一つですべての隅をカバーできない現場——ではこの前提は崩れる。安価な解決策がリレー型ビーコンだ。他のビーコンのパケットを受信して再送信し、実際に到達可能なゲートウェイへ向けて信号をホップさせるノードである。

本稿では、リレー型ビーコンが本当は何か、なぜ「全員が全てを転送する」素朴な設計が爆発するのか、そしてリレーネットワークを安定させるための設計ルールについて解説する。

リレー型ビーコンが実際に行うこと

リレー型ビーコンはデュアルロール機器である。純粋な送信機と違い、オブザーバー(スキャナ)モードでアドバタイジング・パケットを受信し、次にブロードキャスタモードに切り替えて再送する。3つの明確な役割:

1. スキャン:3つのアドバタイジング・チャネル(37/38/39)で、対象ビーコンや上流リレーからのパケットを待つ。

2. 判定:パケットを転送すべきか(重複排除、ホップ制限、信号強度ルール)を決める。

3. 再送:(通常はそのまま、場合により付加情報付きの)パケットをアドバタイジング・チャネルへ再送する。

リレーはゲートウェイのようにアプリケーションペイロードを解釈しない。通常は生のアドバタイジング PDU——MAC、ペイロード、および自身が測定した RSSI——を変更せず転送する。それが狙いだ。賢いシンクではなく、単純で高速な延長器である。

他の手法との比較

役割 RX必要? TX必要? スリープ? 経路に居る? 典型的消費電力
標準ビーコン いいえ はい はい(99%以上) いいえ 5–50 µA 平均
リレー型ビーコン はい はい めったに はい 1–10 mA 平均
BLE Mesh ノード はい はい いいえ(中継) はい 2–15 mA 平均
ゲートウェイ はい 場合による いいえ 終端 商用電源 / PoE

この表で厳しいのは消費電力だ。送信専用ビーコンは 100 ms のアドバタイジング間隔のうち約 0.5–2 ms だけ電波を出し、後は眠るので平均は数 µA。リレーはパケットを見逃さないよう無線をほぼ常時 RX に保つ必要があり、Cortex-M4 BLE SoC の RX は約 4–6 mA。5 mA 連続で 1 日 120 mAh——CR2032(220 mAh)は 2 日弱で枯渇する。実用リレーノードは商用電源、PoE、USB、あるいは最低でも数年稼働を目標とした D セル / Li-SOCl₂ 電池である。

ブロードキャストストームの罠

リレー設計で最も多い失敗は氾濫(フラッド)だ。すべてのリレーが聞いた全パケットを転送し、その転送を他の全リレーがさらに転送すると、ネットワークは指数関数的に増幅する:

  • ビーコン A が 1 パケット送信。
  • リレー B と C が双方それを聞き、各々 1 つ送信 → 電波上は 2 パケット。
  • B と C が互いの再送を聞き、D/E もそれを聞く → 4、さらに 8 と、チャネルが飽和する。

N 個のリレーが各々 10 Hz で転送すると、電波上のパケットレートは 10 Hz ではなく 10 × N × (N−1) / 不細工な数になる。アドバタイジング・チャネルは 1 Mbit/s だが、BLE アドバタイジング・パケットは約 50–350 µs に 150 µs のフレーム間隔が付く。現実にはチャネルは衝突が支配的になる前に 1 秒あたり数百パケット程度が限界だ。ストームはセグメント全体を崩壊させる。

ストームを防ぐ制御ルール

すべての実運用リレーファームウェアは 4 つの仕組みを実装する:

1. 重複排除キャッシュ。 直近で見た (TxAdd MAC, SeqNum) ペア——64–256 エントリ程度——をリングバッファに保持する。パケットのキーがキャッシュにあれば破棄。これだけでループの 90% を止められる。

2. ホップカウンタ / TTL。 ペイロードにホップ欄(未使用バイトを流用)を刻む。中継ごとにインクリメントし、hop ≥ H(通常 4–8)で破棄。これでネットワーク直径を制限し、A↔B 間の無限ループを防ぐ。

3. ホールドオフ / ジッタ。 転送を決めた後、送信前に 20–100 ms をランダムに待つ。リレー同士が同じスロットで一斉に発信しないようずらし、かつ隣接ノードの重複排除キャッシュが埋まる時間を稼ぐ。

4. RSSI ゲート(選択中継)。 測定 RSSI がしきい値(例:< −75 dBm)未満のパケットのみ転送。強いパケットは既にゲートウェイ近くにあり中継不要、弱いものだけが必要だ。これで冗長な再送を 50–80% 削減できる。

最小の判定疑似コード:

on_packet(pkt):

if pkt.hop >= MAX_HOP: drop

if (pkt.mac, pkt.seq) in dedup_cache: drop

dedup_cache.add((pkt.mac, pkt.seq))

if pkt.rssi > RSSI_GATE: drop # 十分強いので不要

pkt.hop += 1

schedule_tx(pkt, random_delay(20,100))

ホップ間の遅延と損失

ストアアンドフォワード型リレーはホップごとに遅延を加える。100 ms のホールドオフ窓と約 5 ms の処理で、1 ホップは約 25–105 ms(平均 ~60 ms)。したがって 3 ホップで位置更新に 150–300 ms の遅延が加わる。資産追跡には許容できるが、リアルタイム制御には致命的だ。

パケット損失も累積する。単一リレーホップの到達確率を p とすると、N ホップ経路の到達確率は p^N。p = 0.9(騒がしい倉庫では既に楽観的)でも 4 ホップ → 0.66。リレーを過剰に配置する(純粋なカバレッジ以上に密に)か、欠落を受け入れるしかない。だから実運用ではリレー深さは通常 3–5 ホップに制限される。

実際の到達距離の計算

リレーはホップ数に応じて到達距離を線形に伸ばすが、各ホップは両リンクの弱い方に制限される。屋内では単一 BLE ホップは壁を挟んで 15–40 m、屋外見通しは 80–150 m が目安。よって:

  • リレー 1 台:単ホップの約 2× ≈ 屋内のデッドゾーン周り 30–80 m をカバー
  • リレー 3 台:単ホップの約 4×、ただし上記の遅延・損失に注意
  • 実用上限:損失・遅延で無意味になるため約 5 ホップ

到達距離はアンテナ、送信電力、チャネルにも依存する。廊下の結節点や階段に置くリレーは、オープンスペースの部屋に置くものよりずっと効く。

ハードウェアとファームウェアの注意点

  • SoC: デュアルロール部品が必要。nRF52840 / nRF5340 や ESP32(HCI モード)はスキャンとアドバタイズの両方が可能。送信専用の nRF52810 は中継できない。
  • スキャン窓と間隔: 100 ms 間隔でアドバタイズするビーコンを捉えるには、リレーのスキャン窓が 3 チャネル合計でビーコンの電波時間以上である必要がある。100% デューティのスキャン(窓=間隔)は見逃しなしだが最大電力、30–50% デューティは欠落率と電池をトレードオフする。
  • チャネル回転: BLE は ch 37/38/39 でアドバタイズする。リレーは 3 つ全てをスキャンせねばならず、1 つ省くとパケットの 3 分の 1 を失う。
  • クロック偏差: リレーが低消費 RC 発振器を使うと、スキャンタイミングが漂移し窓がずれる。TCXO か較正済みスリープクロックで見逃しを減らす。

セキュリティ

リレーは信用境界である。生 PDU を転送するため、攻撃者は以下が可能だ:

  • 注入:リレー経由でゲートウェイへそのまま転送される偽ビーコンを作る(資産位置の偽装)。
  • リプレイ:捕捉したパケットを繰り返し再生し、ストームを起こすか偽の移動を作る。
  • 抑止:チャネルを溢れさせて実パケットを衝突させる。

対策:ビーコンペイロードに署名か暗号化を施し(検証はリレーではなくゲートウェイが行う)、リレーで MAC ごとにレート制限、信頼するビーコン MAC プレフィックスのホワイトリスト。リレーノード自身も物理的に保護し、可能ならネットワークへ認証すべきだ。

リレーを使うべきでない場合

ゲートウェイを約 30 m ごとに置けるなら、そうするべきだ——ゲートウェイは単純でチェーンを終端する。リレーが勝つのは、すべての隅に Ethernet/PoE を引くのが不可能(歴史的建造物、ヤード、トンネル)で、かつカバレッジは必要だが高精度は不要な場合だけだ。高精度 RTLS には、リレーはマルチパスと曖昧さを追加する。より多くのゲートウェイか AoA を推奨する。

まとめ

Bluetooth Beacon リレーは、ゲートウェイの電波の地平を越えてカバレッジを押し広げる最安の手段だが、それは距離の問題に偽装された電力と氾濫の問題である。重複排除キャッシュ、ホップ制限、ホールドオフ・ジッタ、RSSI ゲートを正しく実装し、深さを 3–5 ホップに抑え、ノードは商用電源か大容量電池で給電する。やり方を誤れば、救うはずのセグメントごと沈めることになる。

Comments

No comments yet. Why don’t you start the discussion?

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です