倉庫全体に数百個のBLEタグを配置するのは簡単な部分です。難しいのは、ゲートウェイが実際にそれらを確実に、スケールに合わせて検出することです。本記事では、スキャン側の要因を分析します。スキャンウィンドウとスキャン間隔がタグのアドバタイズ動作とどう相互作用するか、検出確率をどう計算するか、そして実際のデプロイメント密度に合わせてゲートウェイパラメータをどう調整するかを解説します。

1. スキャン戦略がプロジェクト成功を決定する理由

100 ms間隔でアドバタイズするBLEタグでも、ゲートウェイのスキャナがその送信時にスリープしていれば無意味です。WiFiやクラシックBluetoothのような連続ストリームプロトコルとは異なり、BLEアドバタイジングは一方向のワンショットバーストです。スキャナはタグが送信する瞬間に同じアドバタイズチャネルでアクティブにリスンしていなければなりません。さもなければ、そのパケットは永遠に失われます。

タグアドバタイズメントが捕捉されるかどうかを決定する3つの要因：

要因 制御元 典型的な範囲
アドバタイズ間隔 タグファームウェア 20 ms – 1024 ms
スキャンウィンドウ/間隔 ゲートウェイスキャナ 10 ms – 4096 ms
使用アドバタイズチャネル タグ（37/38/39ローテーション） 3チャネル

検出確率はこの3つすべての関数です。間違えると、検出漏れ（デューティサイクルが低すぎる）または無駄なゲートウェイ電力とチャネル混雑（高すぎるデューティサイクルで収益逓減）のいずれかになります。

2. BLEスキャンの基礎

2.1 スキャンウィンドウとスキャン間隔

BLEスキャナは2つの主要パラメータで動作します：

– スキャン間隔（T_scan）：1つの完全なスキャンサイクルの期間。スキャナが起動し、スキャンウィンドウの間リスンし、次のサイクルまでスリープします。

– スキャンウィンドウ（T_window）：各スキャン間隔内で無線がアクティブに受信している時間。

スキャンデューティサイクルは：

デューティサイクル = T_window / T_scan

120 msのスキャンウィンドウと1000 msのスキャン間隔で12%のデューティサイクルになります。スキャナは時間の12%をリスンしています。

2.2 チャネルスキャン動作

BLEアドバタイジングは3つのチャネル（37, 38, 39）を使用します。各スキャンウィンドウ中、スキャナは1つのチャネルでリスンします。BLE仕様に従い、スキャン間隔をまたいでチャネルをローテーションします。これは以下を意味します：

– チャネル37でアドバタイズするタグは、スキャナがチャネル37でリスンしている時にのみ検出されます。

– 3つのチャネルがあるため、スキャナは各チャネルでアクティブ時間の約1/3を費やします。

これは重要です：12%のデューティサイクルは、チャネルあたりの実効リスン時間がわずか約4%であることを意味します。

3. 検出確率モデル

3.1 基本モデル

アドバタイズ間隔T_advのタグと、スキャンウィンドウT_window、スキャン間隔T_scanのスキャナについて、1スキャン間隔内に少なくとも1つのアドバタイズメントを検出する確率は：

P_detect = 1 - (1 - T_window / T_scan)^n

ここで n = 1スキャン間隔内に発生するアドバタイズメント数：

n = T_scan / T_adv

代入すると：

P_detect = 1 - (1 - T_window / T_scan)^(T_scan / T_adv)

3.2 計算例

500 ms間隔でアドバタイズするタグ、120 msウィンドウ、1000 ms間隔のスキャナを考えます：

n = 1000 / 500 = 2（スキャン間隔あたりのアドバタイズメント数）

P_detect = 1 - (1 - 0.12)^2 = 1 - 0.7744 = 0.2256（22.6%）

これはスキャン間隔あたり77.4%のミス率です。10スキャン間隔（10秒）では：

P_detect_10 = 1 - (1 - 0.2256)^10 = 1 - 0.0635 = 0.9365（93.7%）

10秒以内に93.7%の確率で少なくとも1回の検出があります。これが許容されるかは、アプリケーションのレイテンシ要件次第です。

3.3 チャネルオーバーヘッド補正

スキャナは間隔ごとに3つのチャネルのうち1つのみでリスンするため、実効検出確率はさらに低下します。タグは3つのチャネルすべてでローテーションし、スキャナも独立してローテーションします。両者が同じチャネルにいる確率は、アドバタイズメントあたり約1/3です。

補正モデル：

P_detect_corrected = 1 - (1 - T_window / (3 * T_scan))^(T_scan / T_adv)

例を再計算：

P_detect_corrected = 1 - (1 - 0.04)^2 = 1 - 0.9216 = 0.0784（7.8%）

10秒（10間隔）では：

P_detect_10_corrected = 1 - (1 - 0.0784)^10 = 1 - 0.4355 = 0.5645（56.5%）

10秒で56.5%の検出率ははるかに安心感に欠けます。これが、素朴なパラメータ選択が本番環境で「断続的」なタグを生み出す理由です。

4. スキャンパラメータ最適化

4.1 ターゲット検出レイテンシアプローチ

パラメータを推測する代わりに、ターゲットから始めます：「N秒以内に99%の検出が欲しい」。そして逆算します。

500 msアドバタイズタグで10秒以内に99%検出の場合：

P_per_interval = 1 - (1 - 0.99)^(1/10) = 0.369

解く: T_window / (3 * T_scan) >= 0.369 * (T_adv / T_scan)

T_scan = 1000 ms、T_adv = 500 msで：

T_window >= 0.369 * 500 * 3 = 553.5 ms

1000 ms間隔で554 msのスキャンウィンドウ（55.4%デューティサイクル）で10秒以内に99%検出を達成します。これは攻撃的であり、トレードオフを示しています：高検出率は高デューティサイクルを要求します。

4.2 実用的なパラメータマトリクス

下表は500 msアドバタイズ間隔、チャネル補正ありの一般的なパラメータ組合せの検出率です：

スキャンウィンドウ スキャン間隔 デューティサイクル P(1間隔) P(10秒) P(30秒)
60 ms 1000 ms 6% 3.9% 33.0% 69.5%
120 ms 1000 ms 12% 7.8% 56.5% 91.4%
250 ms 1000 ms 25% 15.4% 80.3% 99.2%
500 ms 1000 ms 50% 28.0% 95.7% 99.98%
1000 ms 1000 ms 100% 48.8% 99.6% ~100%
120 ms 500 ms 24% 15.4% 80.3% 99.2%
250 ms 500 ms 50% 28.0% 95.7% 99.98%

重要なポイント：

– 連続スキャン（100%デューティサイクル）でもチャネルローテーションのため間隔あたり約49%の検出率 — しかし30秒で~100%に収束します。

– スキャンウィンドウの倍増は間隔あたりの検出確率をほぼ倍増させます。

– スキャン間隔の半減はウィンドウ倍増と同じ効果がありますが、消費電力への影響が異なります。

4.3 ゲートウェイ消費電力予算

スキャナの消費電力はデューティサイクルにほぼ比例します。アクティブスキャン時60 mA、アイドル時5 mAのゲートウェイ：

デューティサイクル 平均電流 24時間電力（3.3V）
12% 11.8 mA 935 mWh
25% 18.75 mA 1485 mWh
50% 32.5 mA 2574 mWh
100% 60 mA 4752 mWh

商用電源駆動ゲートウェイでは100%デューティサイクルが実現可能です。電池駆動ゲートウェイ（ソーラーまたは一次電池）では12-25%が実用的な上限です。

5. マルチチャネルスキャン戦略

5.1 単一無線逐次スキャン（デフォルト）

標準BLEコントローラは自動的にチャネル37→38→39をサイクルします。これは追加ファームウェア不要ですが、チャネルあたり1/3の実効デューティサイクルが根本的な制限です。

5.2 ピン留めチャネルスキャン

一部のBLEスタックはスキャナを単一チャネル（例：常に37でリスン）に固定できます。タグもチャネル37のみでアドバタイズするよう設定すれば、チャネルローテーションペナルティを排除できます：

P_detect = 1 - (1 - T_window / T_scan)^(T_scan / T_adv)

先の例（120 msウィンドウ、1000 ms間隔、500 msアドバタイズ）を使用：

P_detect = 1 - (1 - 0.12)^2 = 0.2256（22.6%）

これは3チャネルの場合（7.8%）より3倍改善されています。トレードオフ：冗長性を失います。チャネル37に持続的な干渉（例：WiFiチャネル1から）がある場合、検出が完全に崩壊します。

5.3 デュアル無線並列スキャン

ハイエンドゲートウェイ（ESP32 + nRF52など）は2つのBLE無線を同時に動かせます。それぞれを別のチャネルに固定したり、独立したスキャンサイクルを実行できます。ハードウェアコストは倍増しますが：

– 実効スキャンカバレッジが倍増

– 一方の無線でアクティブスキャン、もう一方でパッシブスキャンが可能

– 一方の無線で接続を処理しながらもう一方でスキャン可能

チャネル37と38をカバーするデュアル無線で、タグが3チャネルすべてでアドバタイズする場合：

P_detect = 1 - (1 - 2/3 * T_window / T_scan)^(T_scan / T_adv)

これにより1/3ではなく2/3のチャネルカバレッジ係数が得られます。

6. アクティブスキャン vs パッシブスキャン

6.1 パッシブスキャン

ゲートウェイはサイレントにリスンします。アドバタイジングPDU（ADV_NONCONN_IND、応答なしADV_IND）のみを捕捉します。iBeaconまたはEddystoneフレームをブロードキャストするBLEタグによるアセットトラッキングの標準モードです。

– メリット：アドバタイズメントあたりのゲートウェイ無線時間が最小、アップストリーム干渉なし

– デメリット：アドバタイジングパケットを超えるペイロードなし（最大31バイト）

6.2 アクティブスキャン

ゲートウェイはアドバタイズメント受信後、SCAN_REQを送信します。タグはSCAN_RSP（別の31バイト）で応答します。ペイロード容量が62バイトに倍増します。

– メリット：完全なメーカー固有データ、スキャンレスポンス内のセンサ値

– デメリット：スキャンレスポンスごとに150-200 μs追加、チャネルエアタイム増加、密なタグデプロイメントで衝突の可能性

6.3 密度閾値

単一チャネルで間隔T_advでアドバタイズするN個のタグのデプロイメントで、チャネル占有率は：

占有率 = N * (T_adv_pdu + T_scan_req_rsp) / T_adv

T_adv_pdu ≈ 376 μs（37バイト @ 1 Mbps）、T_scan_req_rsp ≈ 376 μs（リクエスト+レスポンス）。

パッシブスキャン（スキャンレスポンスなし）、200タグ @ 1s間隔：

占有率 = 200 * 0.376ms / 1000ms = 7.5%

アクティブスキャン：

占有率 = 200 * 0.752ms / 1000ms = 15.0%

15%の占有率で衝突確率が無視できなくなります。30%を超える（アクティブスキャン @ 1sで約400タグ）と、衝突率がスキャンで補償できないほど検出を劣化させます。

7. ゲートウェイ配置と密度計画

7.1 カバレッジオーバーラップ

各ゲートウェイの有効範囲は、タグTX電力、アンテナゲイン、環境減衰により決まります。典型的な倉庫（天井15 m、金属ラック）では：

タグTX電力 実用範囲 ゲートウェイあたりタグ数（1000 m²床）
+4 dBm 15-20 m ~200-300
0 dBm 10-15 m ~100-200
-12 dBm 5-8 m ~50-80

7.2 ゲートウェイ密度公式

ターゲット検出レイテンシT_target秒、タグ数N、アドバタイズ間隔T_advの場合：

ゲートウェイ数 = ceil(N * T_scan_window / (T_target * T_adv * P_threshold))

P_thresholdは必要な間隔あたり検出確率。これは簡略化されています — 実際の計画では空間分布とRF伝播も考慮します。

7.3 実用的なデプロイメントルール

500 msアドバタイズ間隔で10秒以内95%検出の場合：

– オフィス: 400 m²あたり1ゲートウェイ、25%スキャンデューティサイクル

– ラック付き倉庫: 250 m²あたり1ゲートウェイ、50%スキャンデューティサイクル

– 混在環境（壁、機械）: 150 m²あたり1ゲートウェイ、50%スキャンデューティサイクル

タグTX電力+4 dBm、両端標準ダイポールアンテナを想定。

8. 実環境での検出率ベンチマーク

以下のベンチマークは2000 m²の倉庫で100個のBLEタグ（500 msアドバタイズ間隔、+4 dBm TX電力）、8ゲートウェイ（ESP32、120 msウィンドウ、500 ms間隔、24%デューティサイクル）で測定：

指標 値 備考
タグあたり月平均検出回数 8.3 期待値：~12（24%デューティサイクル、500 msアドバタイズ）
検出率<95%のタグ 7/100 すべてラックシャドーゾーン内
検出率<80%のタグ 2/100 金属エンクロージャの背後
検出パケットの平均RSSI -67 dBm 範囲：-45 ～ -89 dBm
スキャンチャネル衝突率 3.2% 8つのオーバーラップゲートウェイから

チューニング後（デューティサイクル50%に増加、シャドーゾーンにゲートウェイ2台追加）：

指標 チューニング前 チューニング後
検出率<95%のタグ 7 1
検出率<80%のタグ 2 0
タグあたり月平均検出回数 8.3 14.7
ゲートウェイ消費電力 18.7 mA avg 32.5 mA avg

改善のコスト：ゲートウェイ電力73%増、ハードウェア25%増。このトレードオフが正当化されるかは、特定のアプリケーションでの検出漏れのコスト次第です。

9. まとめと推奨事項

シナリオ スキャンウィンドウ スキャン間隔 デューティサイクル 期待P(10秒で95%)
商用電源、高密度タグ 500 ms 1000 ms 50% ~96%
商用電源、低密度タグ 250 ms 1000 ms 25% ~80%
電池ゲートウェイ、高密度タグ 250 ms 500 ms 50% ~96%
電池ゲートウェイ、低密度タグ 120 ms 1000 ms 12% ~57%
超低電力ゲートウェイ 60 ms 2000 ms 3% ~15%

経験則：

1. タグのアドバタイズ間隔から始める — 通常、タグの消費電力予算によって固定されています。スキャン戦略をそれに合わせて構築します。

2. 本番デプロイメントでは50%デューティサイクルをターゲット — 検出確率が急激に上昇し、過剰な電力コストなしに済むカーブの変曲点です。

3. チャネルローテーションを考慮 — チャネルあたりの実効デューティサイクルは生の数値の1/3です。スキャン設計で最も見落とされる要因です。

4. 実際の環境でベンチマーク — 倉庫や工場のRF伝播は純理論モデルには複雑すぎます。数台のゲートウェイを配置し、検出率を測定してからスケールします。

5. 制御環境ではピン留めチャネルスキャンを検討 — タグとゲートウェイの両方のファームウェアを制御できる場合。3倍の検出改善は、ほとんどの屋内環境でチャネル多様性の喪失に見合う価値があります。