5,000 m²の小売スペースに200台のBluetoothビーコンを配置すると、現地調査で最初に明らかになるのはカバレッジの問題ではなく、衝突の問題です。すべてのビーコンは2.4 GHz ISMバンドの同じ3つの広告チャネル（37、38、39）で送信し、ビーコン密度が間隔、ペイロードサイズ、周囲のRFノイズに依存する閾値を超えると、パケット損失が急激に増加します。受信機は信号が弱すぎるためではなく、2つ以上の送信が同じチャネルで時間的に重なるため、広告パケットを見逃し始めます。
本記事では、BLE広告衝突の数学的モデルを分解し、一般的な展開シナリオの実用的な密度限界を導出し、プロトコル拡張に頼らずにRFエンジニアが適用できる共存戦略を提示します。すべての計算はBLE 4.x/5.x非接続広告（ビーコン展開の主要モード）と、一般的な-90 dBm感度の受信機を前提としています。
1. BLE広告チャネルの基礎
BLE広告は、2.4 GHzバンドの最も混雑するWiFiチャネルを避けるため、バンドの端に配置された3つの専用チャネルを使用します：
| 広告チャネル | 周波数（MHz） | WiFi重複 | 典型的ノイズレベル |
|---|---|---|---|
| 37 | 2402 | WiFi Ch 1（2412）— 10 MHz離れる | 中程度 |
| 38 | 2426 | WiFi Ch 1とCh 6の間 | 最低 |
| 39 | 2480 | WiFi Ch 14（2484）— 4 MHz離れる | 最高（Ch 14がアクティブの場合） |
各広告イベントは、同じパケットを3つのチャネル全てに順次送信します。チャネルあたりの通信時間はPHYとペイロード長に依存します：
T_on_air = (1.6 + 0.8 + 0.8 + 0.8 + 0.8 + ceil(payload_bits / 8)) × 1 µs
iBeaconペイロード（PDU合計30バイト）の場合、1 Mbps PHYでのチャネルあたり通信時間は約376 µsです。150 µsのチャネル間間隔を含めると、3チャネル全ての広告イベントは約1.13 msで完了します。
2. 衝突確率モデル
BLE広告は基本的にスロット型ALOHAに類似したシステムですが、明示的なタイムスロットがありません。衝突は、2つ以上の送信機が受信機の検出ウィンドウ内で同じチャネルに重なる場合に発生します。広告間隔T_advでN台のビーコンがある場合、単一チャネルの衝突確率は以下のようにモデル化できます：
P_collision = 1 − (1 − T_on_air / T_adv)^(N−1)
これはビーコンが同期していないことを前提としています（BLE仕様が0〜10 msのランダムadvDelayジッターを義務付けているため、実際には真です）。3チャネルシステムでは、受信機は3つのチャネルのうち1つだけデコードできればよいため、チャネルあたりの有効衝突確率は約3分の1になります：
P_loss_total = P_collision_ch37 × P_collision_ch38 × P_collision_ch39
実際には、チャネル39は日本などでWiFiチャネル14に近接しているため損失が高くなる傾向があり、3つのチャネルは完全には等価ではありません。以下の表は、iBeacon形式広告の様々なビーコン密度における計算パケット損失率を示しています：
| N（ビーコン数） | T_adv = 100ms | T_adv = 200ms | T_adv = 500ms | T_adv = 1000ms |
|---|---|---|---|---|
| 10 | 0.03% | 0.02% | 0.01% | 0.004% |
| 50 | 0.17% | 0.08% | 0.03% | 0.02% |
| 100 | 0.34% | 0.17% | 0.07% | 0.03% |
| 200 | 0.68% | 0.34% | 0.14% | 0.07% |
| 500 | 1.70% | 0.85% | 0.34% | 0.17% |
| 1000 | 3.39% | 1.70% | 0.68% | 0.34% |
これらの数値は一見低く見えます。問題は、理論モデルが時間領域の重複のみを想定していることです。実際の展開では、2つの追加要因が有効パケット損失を劇的に増加させます：受信機のスキャンデューティサイクルとRFキャプチャ効果です。
3. スキャンデューティサイクルと有効損失
ほとんどのBLEスキャナー（スマートフォン、ゲートウェイ、RTLSアンカー）は連続的にリッスンしません。典型的なスマートフォンは4秒間スキャンし、その後システム定義の間隔（iOSでは30〜60秒）で一時停止します。有効パケット損失は：
P_loss_effective = 1 − (1 − P_collision) × D_scan
ここでD_scanはスキャンデューティサイクルです。40秒ごとに4秒のスキャンウィンドウを持つスマートフォン（D_scan = 0.1）の場合、衝突率が0%でもスキャンギャップだけで90%の有効パケット損失が発生します。これが、RTLS展開が連続スキャンを行う専用ゲートウェイを使用する理由です。
連続スキャンゲートウェイ（D_scan = 1.0）の場合、主要な損失メカニズムは衝突に戻ります。200 ms間隔で500台のビーコンにおける測定損失は、通常2〜4%であり、理論値の0.85%より高くなります。この乖離はキャプチャ効果によるものです：2つの送信が重なった場合、強い信号のRSSIが弱い信号より6 dB以上高ければデコード可能な場合があります。しかし、ビーコンが同様の距離にある高密度展開では、このマージンはほとんど存在しません。
4. 広告間隔の選択
広告間隔は衝突管理において最も影響力のあるパラメータです。BLE 4.xは20 msから10.24秒まで、0.625 ms単位で間隔を設定できます。BLE 5.x拡張広告は同じ範囲をサポートしますが、セカンダリチャネルを使用する機能が追加され、利用可能な帯域幅が事実上倍増します。
選択は最大更新レートの要求ではなく、アプリケーションのレイテンシ要件によって駆動されるべきです。主なトレードオフ：
| 間隔 | バッテリー寿命（CR2032、2年） | 最大ビーコン数（1%損失） | 典型的ユースケース |
|---|---|---|---|
| 100 ms | 約4ヶ月 | 約300 | 高速RTLS、近接マーケティング（リアルタイム） |
| 200 ms | 約8ヶ月 | 約600 | 小売ナビゲーション、屋内ナビゲーション |
| 500 ms | 約16ヶ月 | 約1,500 | 資産追跡、在室センシング |
| 1000 ms | 約28ヶ月 | 約3,000 | 環境モニタリング、静的資産タグ |
| 2000 ms | 約30ヶ月以上 | 約6,000 | 駐車センサー、低周期モニタリング |
注意：「最大ビーコン数」は、連続スキャンとiBeaconペイロードを想定した単一チャネル衝突確率が1%に達する理論密度です。RFキャプチャ効果とWiFi同チャネル干渉のため、実際の容量は通常この値の60〜70%です。
5. ジッターとランダム化
BLE仕様は各広告間隔に0〜10 msの疑似ランダムadvDelayの追加を義務付けています。これにより、同じ間隔のビーコンが送信を永久に同期することを防ぎます。ジッターがない場合、1000 msに設定された2台のビーコンが最初の広告で偶発的に一致すると、その後の全ての広告で衝突し、事実上両方とも受信機に見えなくなります。
10 msのジッターは500 ms以上の間隔には十分ですが、短い間隔では問題になります。100 ms間隔では、ジッターは周期の10%を占め、合理的なデコレーションを提供します。ただし、一部のビーコンメーカー（特にCSR1010やnRF51を使用する低コストクローン）は適切なランダム化なしに固定間隔を実装しています。これらのビーコンは高密度展開では避けるべきです。
実用的なテスト：同じメーカーのビーコン20台を2 m半径内に配置し、同じ200 ms間隔に設定し、Nordic nRF52スニファーで10分間監視します。いずれかのビーコンが2%を超えるパケット損失を示す場合、メーカーのランダム化が不十分である可能性が高いです。有名ブランドのビーコン（Minew、Kontakt.io、Estimote）はこのテストを確実にパスしますが、汎用ホワイトラベルビーコンはしばしばパスしません。
6. WiFiとの共存
2.4 GHzバンドはBLEとWiFiで共有されており、その相互作用は非対称です。BLE広告は1 Mbps、2 MHz帯域幅で送信され、WiFiは6〜54+ Mbps、20+ MHz帯域幅で送信されます。単一のWiFiパケットが複数のBLE広告イベントを破壊する可能性があります。
主要な共存要因はBLE広告チャネルとアクティブなWiFiチャネルのスペクトル重複です：
| WiFiチャネル | 中心周波数（MHz） | 帯域幅 | 影響を受けるBLE広告チャネル | BLE損失増加 |
|---|---|---|---|---|
| 1 | 2412 | 20 MHz（2401–2423） | 37（2402）、38の一部（2426） | +3–5% |
| 6 | 2437 | 20 MHz（2426–2448） | 38（2426） | +2–3% |
| 11 | 2462 | 20 MHz（2451–2473） | 直接的な影響なし | +0–1% |
| 14 | 2484 | 20 MHz（2473–2495） | 39（2480） | +5–8% |
推奨事項：ビーコン密度の高い展開では、WiFiアクセスポイントにチャネル1、6、11（標準3チャネルプラン）を使用させるが、チャネル14は完全に避けます。ビーコン密度が非常に高い場合（500台以上）、WiFiをチャネル1と11のみに割り当て、チャネル6（BLEチャネル38と重複）をビーコンフレンドリーなギャップとして残すことを検討します。これはWiFiスループットを犠牲にしますが、BLE信頼性を15〜20%改善できます。
7. 電力ベースの密度管理
展開内のすべてのビーコンが同じ送信電力を必要とするわけではありません。一般的な間違いは「より良い範囲のために」全てのビーコンを+4 dBm以上に設定することです。高密度展開では、これは実際には衝突半径（2つのビーコンが互いに干渉できる範囲）を増加させます。
2つのビーコン間の衝突半径は、信号が受信機に6 dB以内の差で到達する距離として定義されます。同じ送信電力の2台のビーコンの場合、これは単に両方が同等のRSSIになる距離です：
R_collision ≈ 2 × 10^((P_tx − P_rx_threshold) / (10 × n))
ここでnはパスロス指数（自由空間では2.0、屋内環境では2.5〜3.5）です。P_tx = 0 dBm、P_rx_threshold = −90 dBm、n = 2.7の場合：
| P_tx（dBm） | R_collision（m、屋内） | 面積（m²） | 有効密度上限 |
|---|---|---|---|
| +4 | 約48 | 約7,200 | 14 m²に1台（1%損失） |
| 0 | 約35 | 約3,800 | 7.6 m²に1台 |
| −4 | 約26 | 約2,100 | 4.2 m²に1台 |
| −8 | 約18 | 約1,000 | 2.0 m²に1台 |
| −12 | 約13 | 約530 | 1.1 m²に1台 |
| −20 | 約7 | 約154 | 0.3 m²に1台 |
ビーコンが天井タイルに4 m間隔で配置されている小売環境では、送信電力を−4 dBmに設定すると衝突半径が26 mに減少します。これは近くのゲートウェイによる確実な受信には十分ですが、2列離れたビーコンとの干渉を制限します。電力を+4から−4 dBmに下げると空間容量が事実上2倍になることが表からわかります。
8. 間隔スタッガリング技術
BLE仕様は0〜10 msのジッターを義務付けていますが、意図的な間隔スタッガリング（異なるビーコンにわずかに異なる間隔を設定すること）を妨げるものではありません。この技術は時間経過とともに送信パターンの相関を低下させます。
最も効果的なアプローチは素数関連の値から間隔を割り当てることです。例えば、100台のビーコン展開では、全てを200 msに設定する代わりに、5つの値に分散させます：
| グループ | 間隔（ms） | ビーコン数 | 理論的根拠 |
|---|---|---|---|
| A | 190 | 20 | ベース間隔 −5% |
| B | 197 | 20 | 素数由来オフセット |
| C | 200 | 20 | 公称 |
| D | 211 | 20 | 素数 |
| E | 223 | 20 | 素数 |
これらの間隔のLCM（最小公倍数）はパターンが繰り返すまでの時間を決定します：LCM(190, 197, 200, 211, 223)は天文学的に大きく（10^12 msのオーダー）、異なるグループの2台のビーコンが同期することを事実上保証します。この技術による測定パケット損失削減は、全100台を均一200 ms間隔にした場合と比較して30〜45%です。
注意：この技術はビーコンごとの設定を必要とし、プロビジョニング時間が追加されます。大規模展開では、自動分散によるバッチ間隔割り当てをサポートする管理インターフェースが不可欠です。
9. BLE 5.x拡張広告
BLE 5.0は拡張広告を導入し、広告PDUをプライマリ広告（チャネル37/38/39上）とセカンダリ広告（残り37のデータチャネルのいずれか）に分割しました。これにより、ビーコントラフィックを3チャネルではなく40チャネルに分散できます。
理論的な衝突容量改善は約40/3 = 13.3倍ですが、実際の改善はより控えめです：
- プライマリチャネルはAUX_SYNC_INDポインタを運ぶため、プライマリチャネルの衝突は依然としてポインタの損失を引き起こす
- 全ての受信機がBLE 5.x拡張広告をサポートしているわけではない（iOSはiOS 17でサポートを追加、多くのAndroidデバイスはまだレガシースキャンのみ）
- セカンダリチャネルはプライマリPDUで示されるため、受信機はまずプライマリをデコードする必要がある
全ての受信機がBLE 5.x対応の新規展開では、拡張広告により密度容量を5〜8倍増加できます。混在環境では、レガシー広告と併用（デュアルモード）する必要があり、容量の利点が部分的に相殺されます。
10. ゲートウェイとスキャナーの最適化
衝突管理は送信機だけの問題ではありません。受信機のスキャンパラメータも有効パケット受信に大きく影響します。BLEゲートウェイの主要パラメータ：
| パラメータ | デフォルト（スマートフォン） | 推奨（ゲートウェイ） | 影響 |
|---|---|---|---|
| スキャンウィンドウ | 4,096 ms | 連続（ギャップなし） | スキャンギャップ損失を排除 |
| スキャン間隔 | 4,096 ms | 連続 | ウィンドウと同じで100%デューティ |
| アクティブスキャン | はい | いいえ（ビーコン用） | SCAN_RSPによるRX時間消費を削減 |
| 重複フィルタ | OS依存 | 30秒ウィンドウ | ログフラッディングを防止しつつ新データを保持 |
| マルチチャネルデコード | N/A | 3並列受信機 | 異なるチャネルの重複パケットを同時にキャッチ |
3つの独立したBLE受信機（各広告チャネルに1つずつチューニング）を持つゲートウェイは、単一受信機スキャナーより理論的に3倍のスループットを達成できます。Nordic nRF52840およびnRF5340はRADIOペリフェラルの高速チャネル切り替え機能による同時マルチチャネル受信をサポートしていますが、真の並列受信には2つのRADIOインスタンス（nRF5340のみで利用可能）が必要です。
11. 実環境の展開密度ガイドライン
小売、博物館、倉庫、病院展開のフィールド測定に基づき、以下の密度ガイドラインは連続スキャンゲートウェイ、iBeacon形式、−4 dBm送信電力、95%以上のパケット受信率を目標としています：
| シナリオ | 推奨間隔 | ゲートウェイあたり最大ビーコン数 | ゲートウェイ間隔 | 備考 |
|---|---|---|---|---|
| 小売（近接プッシュ） | 200 ms | 400 | 15 m | ゾーン間で間隔をスタッガ |
| 博物館（オーディオガイド） | 300 ms | 350 | 12 m | 部屋あたりの密度を下げる；壁の減衰が有効 |
| 倉庫（RTLS） | 500 ms | 800 | 20 m | 高い天井が衝突半径を減少 |
| 病院（資産追跡） | 500 ms | 600 | 15 m | 医療機器がRFノイズ追加；20%マージンを追加 |
| 駐車（占有率） | 2000 ms | 2,000以上 | 30 m | 低レイテンシ不要；非常に高密度可能 |
| スタジアム（群衆ナビゲーション） | 100 ms | 150 | 10 m | 人体吸収が範囲を減少；40%オーバーラップ損失を計画 |
12. フィールドでの衝突測定
衝突率の検証には制御された測定セットアップが必要です。推奨されるアプローチは、タイムスタンプ、チャネル、RSSI、MACアドレスを含む全ての受信広告をログに記録するカスタムスニファーファームウェアを実行する専用nRF52840ドングルを使用します。
主要メトリックはビーコンごとの受信率（PBRR）です：各ビーコンについて、測定ウィンドウ内で受信した広告数をカウントし、期待数（window_duration / interval）と比較します。PBRRが95%を下回る場合、衝突またはRFカバレッジの問題を示しています。
衝突損失とカバレッジ損失を区別するために、スニファーをビーコンから2 m以内の視通線内に配置します。この距離ではRSSIは−60 dBmを超えるはずで、感度より十分に上です。この範囲でのパケット損失はすべて衝突であり、カバレッジではありません。典型的な測定プロトコル：
- 全てのビーコンを最終位置と設定に配置
- スニファーをゲートウェイ位置に配置、10分間実行
- ビーコンごとのRSSIとタイムスタンプログをエクスポート
- 各ビーコンのPBRRを計算
- PBRRが95%未満のビーコンについて、スニファーを2 m近接に移動して再測定
- 近接でPBRRが98%を超える場合、損失はカバレッジ関連（ゲートウェイを追加）
- 近接でもPBRRが95%未満の場合、損失は衝突関連（密度を下げるか間隔をスタッガ）
13. よくある設計の落とし穴
- 全ビーコンを100 msに設定：「頻繁なほど良い」が最も一般的な間違いです。100 msで500台のビーコンの場合、衝突損失は5%を超え、バッテリー寿命は4ヶ月未満に低下します。レイテンシ予算が許す最も長い間隔を使用してください。
- WiFiチャネル計画の無視：ITチームとWiFiチャネルを調整せずにビーコンを展開。日本でチャネル14の単一WiFi APがBLEチャネル39に8%の追加損失を引き起こす可能性があります。
- あらゆる場所で+4 dBmを使用：最大電力は範囲を最大化しますが、衝突半径も最大化します。電力ゾーン分けを使用：高密度ゾーンは−12 dBm、開放エリアは0 dBm、疎エリアのゲートウェイビーコンのみ+4 dBm。
- 同質展開での間隔スタッガリングなし：同じ間隔の200台の同一ビーコンは10 msジッターのみに依存します。グループ間で間隔をスタッガすると衝突を30〜45%削減します。
- 単一受信機ゲートウェイ：1つのBLE受信機を持つゲートウェイは一度に1つのチャネルしかデコードできません。高密度展開では、マルチチャネルゲートウェイと比較して3倍のボトルネックが生じます。
14. 設計チェックリスト
- ☐ 必要なビーコン数とゾーンごとの密度を計算
- ☐ レイテンシ予算に基づいて広告間隔を選択（長いほど良い）
- ☐ ゲートウェイあたり50台を超える展開で間隔グループ（スタッガされた素数）を割り当て
- ☐ ゾーン密度に基づいて送信電力を設定（高密度は−4〜−12 dBm、疎は0〜+4 dBm）
- ☐ ITとWiFiチャネルを調整（Ch 14を回避、Ch 6よりCh 1/11を優先）
- ☐ 高密度展開にマルチチャネルBLEゲートウェイを指定
- ☐ 30秒重複フィルタリングで連続スキャン用ゲートウェイを設定
- ☐ スニファーでフィールド測定を計画し、ビーコンごとにPBRR ≥95%を検証
- ☐ 将来のトラブルシューティングのために各ビーコンの間隔、電力、チャネル割り当てを文書化
- ☐ BLE 5.xのみの受信機環境では、5〜8倍の密度ヘッドルームのために拡張広告を有効化
結論
広告衝突はビーコン展開密度の目に見えない天井です。理論的ALOHAモデルは低損失率を予測しますが、実際の測定はWiFi干渉、キャプチャ効果、スキャンデューティサイクル制限により2〜4倍上回るのが常です。高密度展開への実用的な道は、より多くの電力やより速い間隔ではなく、規律ある間隔選択、電力ゾーン分け、間隔スタッガリング、マルチチャネルゲートウェイです。2.4 GHzスペクトルを定量化可能な衝突予算を持つ共有リソースとして扱うことで、エンジニアはWiFi飽和環境でも500台以上のビーコンをゲートウェイあたり95%以上のパケット受信率で展開できます。カバレッジゾーンあたり1,000台を超える展開では、BLE 5.x拡張広告が更新レートを犠牲にせずに信頼性を維持するために必要な追加のチャネル多様性を提供します。
少数の近接ビーコンを展開する場合でも、キャンパス全体にBluetoothビーコンを配置する大規模RTLSシステムを設計する場合でも、これらの衝突ダイナミクスの理解は不可欠です。
