BLEタグはめったに静止していません。倉庫、病院、キャンパスを移動するにつれて、あるゲートウェイのカバー範囲を抜け、別のゲートウェイへと静かに入ります。うまくいけばこのハンドオフは見えません。位置トラックは滑らかなまま、ダッシュボードがちらつくこともありません。下手だと、タグは瞬間移動したり、重複したり、消えたりします。ローミングとは、トラックを連続させるための規律です。

ゾーンの分割

まず、各ゲートウェイの周りにゾーンを描きますが、データシートの半径ではなく、実測されたカバー範囲に基づきます。重複は意図的なものです。複数のゲートウェイが両方ともBLEタグを聞くハンドオフ領域こそが移行が起きる場所です。重複は適度に保ちます。重複が大きすぎるとスラッシング（激しい切り替え）を招き、小さすぎると死角が生じます。清潔なゾーンマップが安定したローミングの基盤です。

ハンドオフのトリガとヒステリシス

典型的な誤りは、あるRSSIが別のものを上回った瞬間にゲートウェイを切り替えることです。ヒステリシスがないと、RSSIのジッタに応じてタグが2つのゲートウェイ間をバタつき、ジグザグのトラックになります。しきい値にマージンを加えます。新しいゲートウェイのRSSIが現在のものを一定のヒステリシス値（6〜10 dB程度）上回ったときだけハンドオフします。これで決定がデバウンスされ、トラックに慣性が生まれます。

重複排除とジッタ抑制

移動するBLEタグは複数のゲートウェイに同時に見られ、それぞれが独自のRSSIとタイムスタンプを報告します。バックエンドはタグの識別子で重複排除し、ゲートウェイごとに最強または最新の読み取りを選び、鮮度ウィンドウを過ぎた古い報告を抑制しなければなりません。短いウィンドウ（200〜500 ms）でスキャンを集約するとジッタが平滑化され、同じパケットが2回カウントされるのを防ぎます。

ゲートウェイ間の位置連続性

位置を連続させるには、すべてのゲートウェイが1つの座標枠を共有する必要があります。支配的なアンカーが切り替わるとき、ソルバは新しい推定値へスナップするのではなく、古い推定と新しい推定をブレンドして、点が飛ぶのではなく滑るようにすべきです。トラック履歴を保持するアンカーハンドオーバーは、「見失ってから見つかる」というグリッチを避け、地図への信頼を損ないません。

実践的なチューニング

3つのつまみを同時に調整します。ヒステリシスマージン（大きいほどバタつきを減らすがハンドオフが遅れる）、スキャン集約ウィンドウ（大きいほどジッタを平滑化するが遅延を増す）、ゲートウェイのクロック同期（タイムスタンプが多地点測位で揃うように）です。パイロットウォーク中にハンドオフイベントを記録し、瞬間移動がないか監視します。発生する場合はヒステリシスを広げるか重複を縮めます。

まとめ

ローミングは、ゲートウェイの集まりを1つの生きた地図に変えるものです。ゾーン、ヒステリシス、重複排除を正しく行えば、BLEタグはドックからドアまで、画面から一度も消えることなく滑らかに移動します。