先月、12,000 m2の物流センターを設備担当者と一緒に歩いた。ゲートウェイは端にある事務所に置いてあった。一番遠い荷捌き口では、Beaconがゲートウェイで-92 dBm――復号のぎりぎり下限を下回っていた。彼の最初の考えは、もう2台のゲートウェイを1台約800ドルで入れることだった。サインする前に、私は通路の真ん中の棚にリレー専用のBeaconを1つ置いた。その角が再び見えるようになった。
リレー方式Bluetooth Beaconは、ただ一つだけ癖が違う、ふつうのBeaconだ。それは「聞く」。通常のBeaconは自分のペイロードを一方的に発信するだけだが、リレーは近くのBeaconのアドバタイズパケットも拾って、コピーを再送する。ゲートウェイはリレーが「何かを見つけた」とは知らない――ただ、遠くのBeaconのデータを、もっと近い口から受け取るだけだ。
実際に得られるもの
メリットは単純なカバー範囲だ。冷蔵室のBeaconがゲートウェイで-90 dBm――かろうじて読めているが、こっそりパケットを落としているとする。その部屋とゲートウェイの両方から-68 dBmで届く場所にリレーBeaconを置けば、ゲートウェイは冷蔵室のBeaconの-68 dBmのきれいなコピーを受け取る。ケーブルを引くことも、2台目のゲートウェイを買うこともなく、1つのリレーで死角をネットワークに引き戻せる。
コストは電池だ。1 Hzで-8 dBm発信する受動的なBeaconは平均15〜20マイクロアンペアを吞み、CR2032で18ヶ月持つ。同じことをしつつ、2 Hzで聞いて再送するリレーは典型的に2.5〜4倍の電流を食う。同じ電池で5〜7ヶ月になり、1年半ではなくなる。リレーを差し込める場所――USBアダプタ付きの荷捌き口や、給電済みセンサノード――なら、この計算はひっくり返り、リレーはほぼタダになる。
誰も言わない遅延
リレーは瞬時ではない。リレーはソースのBeaconのパケットを聞いてからでないと、それを繰り返せない。1 Hz発信なら平均500 msの待ちだが、大半のファームウェアはもっと短いリスニング窓を持ち、フレームを拾えば20〜80 ms以内に再送する。パレットが「どこにあるか」にはこの遅延は見えない。フォークリフトのリアルタイム衝突防止なら話は別だ。自分がどちらを作っているかを知れ。
ホップ数はいくつまで
2つ、せいぜい3つ。各ホップは自分なりのパケットロスと遅延を加え、それらは掛け合わされる。ホップごとにきれいな1〜3%のロスなら、3つのリレーのチェーンですでに約9%のフレームを失う。それを超えると、真ん中で静かに壊れるシステムを作ったことになる。誰も文書化せず、誰もが恐れる「仮の」リレーが5つつながっているのを見たことがある。2ホップを設計上限とし、3ホップは実際にトラブルシュートできる例外としろ。
手を出すべきでない場合
リレーBeaconは、電池がついたバンドエイドだ。ゲートウェイを10メートル動かせるなら、あるいはもう1つ静的Beaconを足せるなら、あるいはカバーが本当に dense な場所に2台目のゲートウェイを通すなら、まずそっちをやれ。リレーは、壊れる可能性のある2台目のデバイスと、追跡すべき2つ目の電池と、「リレーが死んで、遠くのBeaconが『消えた』のではなく『リレーが消えた』」という失敗モードを追加する。この混乱だけで、ハードウェアが節約した以上のトラック出動を食っている。
うっかり起こすストーム
落とし穴はこれだ。すべてのBeaconがすべてのBeaconを中継し始めると、空気が埋まる。10個のBeaconがそれぞれ9つの隣を繰り返すと、サイクルあたり90個の余計な送信になり、チャネルは飽和する。まともなファームウェアはそれを制限する――特定のソースIDだけをリレーする、あるいはゾーンあたりN個のリレーに制限する――が、「とりあえず繰り返させとけ」モードの既製モジュールは、パケットレートを喜んで溶かす。サポート電話の後ではなく、展開前に許可リストを設定しろ。
結論
リレー方式Bluetooth Beaconが居場所を得るのは、ゲートウェイの価値がないたった一つの角――非常階段、遠いラック、電源のない荷捌き場――をカバーするときだ。そう使えば12ドルの直しだ。カバー範囲のアーキテクチャとして使えば、それは永久に交換し続ける電池だ。リレーは両端が見える場所に置き、チェーンは短く保ち、聞くのはゲートウェイに任せろ。