現在生産されているほとんどのBluetoothモジュールは、単一のピアに対応するのではなく、センサー、スマートフォン、ゲートウェイ、アクチュエータに対して3〜20の同時接続を管理しています。マルチ接続管理は、接続間隔、スレーブレイテンシ、MTUサイズ、PHYレート、データ長拡張が独立した設定項目ではなく、密接に結合されたスケジューリング問題であることをエンジニアが発見する場所です。1つでも間違えると、断続的な切断、400 msのレイテンシスパイク、2 Mbps PHYにもかかわらず30 kbpsを超えないスループットが発生します。本記事では、スケジューラモデルを分解し、スループットとレイテンシの予算を第一原理から導出し、実際のシリコンをベンチマークします。
1. BLE接続イベントモデル
BLE接続は連続リンクではなく、定期予約です。マスター（セントラル）とスレーブ（ペリフェラル）は接続間隔（T_interval）で合意し、各間隔内に両方の無線がアクティブになる接続イベントが1つ発生します。マスターが最初に送信し、スレーブが応答し、そのイベント内で複数のPDUをピンポン方式で交換できます。データがなくなるか、接続イベントが割り当て時間を超えると、次の間隔まで無線はスリープします。
LL_CONNECTION_PARAM_REQで定義される主要パラメータ：
- 接続間隔（connInterval）：7.5 ms〜4.0 s、1.25 msステップ。接続イベント間の周期。
- スレーブレイテンシ（connLatency）：0〜499。ペリフェラルは切断されずにこの数の連続イベントをスキップできます。各スキップで約1 msの無線オン時間を節約。
- 監視タイムアウト（supervisionTimeout）：100 ms〜32 s。この時間内にパケットが受信されないとリンクが終了。supervisionTimeout > (1 + connLatency) × connInterval × 2 を満たす必要があります。
2. マルチ接続スケジューリング：時分割
モジュールがN個のペリフェラルを持つセントラルとして動作する場合、スケジューラは各間隔内にN個の接続イベントを配置する必要があります。基本的な制約は、任意の時点で1つの無線トランザクションのみが発生することです。スケジューラは各接続に間隔内のタイムスロットを割り当てます。4接続（30 ms間隔、各5 msイベント）の場合、総アクティブ時間は20 ms / 30 ms = 67%デューティサイクルです。8接続では40 msのイベントが30 ms間隔をオーバーフローし、一部のイベントが次の間隔に押し出されてレイテンシが実質的に2倍になります。
2.1 チップ別最大同時接続数
| チップ | セントラル最大 | ペリフェラル最大 | 合計最大 | 制限要因 |
|---|---|---|---|---|
| nRF52840 | 20 | 20 | 20 | RAM (8 KB/接続) |
| nRF52832 | 7 | 7 | 7 | RAM (64 KB合計) |
| CC2640R2F | 8 | 3 | 8 | TI-RTOSスケジューラ |
| BGM220SC | 8 | 4 | 8 | Geckoスタック制限 |
| ESP32-C3 | 9 | 3 | 9 | Bluedroid/NimBLE |
| ESP32 (デュアルコア) | 15 | 4 | 15 | Bluedroid |
nRF52840の20接続制限はシリコン上限ではなくSoftDeviceのコンパイル最大値です。各接続はリンクレイヤコンテキスト、TX/RXバッファ、L2CAP状態で約8 KBのRAMを消費します。20接続で160 KB、256 KB RAMのうち96 KBがアプリケーションコードに残ります。ESP32-C3 + NimBLEは60 KBヒープで9接続を達成し、メモリ効率が大幅に優れています。
3. スループット予算計算
BLEスループットは「2 Mbps PHY = 2 Mbpsスループット」とよく引用されますが、3〜5倍間違っています。実際のスループットは一連のオーバーヘッドに依存します。各データPDUは10バイトのオーバーヘッド（プリアンブル1 + アクセスアドレス2 + ヘッダ2 + 長さ2 + CRC3）を持ちます。2 Mbps PHYで10バイトは40 μsです。251バイトペイロード（DLE最大）の場合、PDU時間 = (10+251)×8/2,000,000 = 1.044 ms。オーバーヘッドは3.8%ですが、20バイトペイロード（デフォルト）では33%です。
IFS（フレーム間スペース）は150 μsで、マスターPDUとスレーブPDUの間のデッドタイムです。251バイトペイロード2M PHYのサイクル = 1.044+0.150+1.044+0.150 = 2.388 ms。スループット = 251×8/2.388ms = 840 kbps。生2 Mbpsの42%です。4接続30 ms間隔5 msイベントの場合、各接続のスループット = 244×8×3/30ms ≈ 195 kbps、集計780 kbpsです。
4. レイテンシ分析
ベストケース：データが接続イベントの直前に準備完了。レイテンシ ≈ 1-3 ms。ワーストケース：イベント直後に準備完了。レイテンシ ≈ connInterval。平均 = connInterval / 2。スレーブレイテンシ > 0の場合、実効間隔 = connInterval × (1 + connLatency)。マルチ接続のコンテンション下ではワーストケースレイテンシが2× connIntervalに達する可能性があります。4接続30 ms間隔でワーストケース62 ms、7.5 ms間隔で15 msに短縮しますが、無線デューティサイクルは4倍になります。
5. 接続パラメータネゴシエーション
セントラルが初期パラメータを設定しますが、LL_CONNECTION_PARAM_REQでいずれかの側が変更を要求できます。iOSは特に制限が厳しく、15-30 ms間隔、スレーブレイテンシ≤29、監視タイムアウト2-6 sを強制します。Androidは柔軟ですが一部のOEMスタックは10 ms未満の間隔を拒否します。ネゴシエーション手順は：イニシエータがパラメータとinstantを送信 → レスポンダが承認または対案 → 6接続イベント後に有効化。
6. PHY更新とデータ長拡張
LL_PHY_REQ手順でPHY変更を要求できます。Coded PHY（125/500 kbps）はスループットを範囲と交換します。2M PHYは生データレートを2倍にし、PDU通信時間とIFSを半分にします。DLEはPDU最大ペイロードを27→251バイトに増やします。重要：MTUとDLEは独立したネゴシエーションで、両方を増やさなければスループット向上を実現できません。MTUのみ→9フラグメント化で90バイト無駄。DLEのみ→L2CAPが23バイトMTUでフラグメント化。両方→単一PDUで244バイト、最小オーバーヘッド。
7. チャネルマップとアダプティブ周波数ホッピング
BLEは37データチャネルを使用し、接続イベントごとにホップします。セントラルがLL_CHANNEL_MAP_REQでチャネルマップを提供します。Wi-Fi共存シナリオでは、Wi-Fiチャネル1（BLE 0-10）、6（11-20）、11（21-30）と重複するチャネルを未使用にマークします。37チャネルでパケットロス〜2%、7チャネルで〜8%に上昇しますが、Wi-Fi干渉を排除できます。
8. スケジューラ競合解決
| 戦略 | 説明 | 長所 | 短所 |
|---|---|---|---|
| 厳格優先度 | 高優先接続が常に勝つ | クリティカルリンクで予測可能 | 低優先接続のスタベーション |
| 公平ラウンドロビン | スロットを回転 | スタベーションなし | 全接続で予測不能なレイテンシ |
| 最早期限優先 | タイムアウトに最も近い接続を優先 | 切断を最小化 | 複雑、期限追跡が必要 |
nRF52 SoftDeviceは修正公平ラウンドロビンを使用し、短い間隔の接続がより多くのスロットを得ます。ESP32 Bluedroidは厳格優先度で、9番目の接続が1番目の2倍のレイテンシを経験します。NimBLEは最早期限優先を実装し、負荷下で15-20%優れたレイテンシ分布を示します。
9. マルチ接続での消費電力
nRF52840 0 dBm 1M PHY：RX 5.4 mA、TX 4.6 mA。3 msイベントで約15 μC。4接続30 ms間隔で平均電流 = 4×15μC/30ms ≈ 2.0 mA。CR2032（220 mAh）で4.6日。スレーブレイテンシ3、100 ms間隔4接続で平均0.15 mA、61日。ただしワーストケースレイテンシは400 msに増加。温度監視など400 msが許容されるセンサーネットワークに最適。
10. 実測ベンチマーク：4接続ハブ
| 指標 | 1接続 | 2接続 | 4接続 |
|---|---|---|---|
| スループット/接続 | 712 kbps | 681 kbps | 523 kbps |
| 集計 | 712 kbps | 1,362 kbps | 2,092 kbps |
| 平均レイテンシ | 16 ms | 19 ms | 28 ms |
| P99レイテンシ | 31 ms | 45 ms | 72 ms |
| 切断/時 | 0 | 0 | 0.3 |
11. 一般的な設計の落とし穴
- 2M PHYを有効化してもMTUが23のまま → 20バイトペイロードでオーバーヘッド33%、スループット向上は〜15%のみ
- スレーブレイテンシ使用時に監視タイムアウト未確認 → 頻繁な切断
- connIntervalがレイテンシと仮定 → スケジューリングオフセットでワーストケース2×
- データ転送中のパラメータネゴシエーション → 6イベントの調整期間中2×レイテンシ
- iOS制限の忘れ → 15-30 ms間隔必須、7.5 ms要求は拒否
- 全接続をオフセット0にスタック → コンテンション集中、オフセット分散推奨
12. 設計チェックリスト
- [ ] 接続間隔でレイテンシと電力のバランス（15-100 ms）
- [ ] リアルタイムはスレーブレイテンシ0、低電力センサーは3-9
- [ ] 監視タイムアウト ≥ (1+connLatency)×connInterval×3
- [ ] MTU 247を接続確立時にネゴシエート
- [ ] DLE 251を接続確立時にネゴシエート
- [ ] BLE 5.0+対応なら2M PHYを要求
- [ ] 接続イベントオフセットを間隔全体に分散
- [ ] Wi-Fi重複チャネルをチャネルマップから除外
- [ ] iOS互換性確認（15-30 ms間隔）
- [ ] ワーストケースレイテンシ = 2×connInterval×(1+connLatency)で予算化
- [ ] 接続ごとのスループット予算を計算
- [ ] 4接続超で監視タイムアウト増加
- [ ] フル負荷下での消費電流を実測
13. 結論
マルチ接続BLEモジュール設計は本質的にスケジューリング問題です。生PHYレートは最もつまらない数字で、実際のスループットはPDUオーバーヘッド、IFS、イベントパッキング、共有接続数で決まります。レイテンシはconnIntervalではなく、コンテンション下で最大2× connIntervalになり得ます。消費電力はアクティブ接続数に比例し、間隔に反比例します。エンジニアの仕事はconnInterval、connLatency、MTU、DLE、PHYを結合システムとして選択することです。4接続ハブ（30 ms / MTU 247 / DLE 251 / 2M PHY）で接続あたり523 kbps、平均28 msレイテンシを達成します。次回のマルチ接続BLEデプロイでは、スペックシートの見出しではなくスループット公式から始めてください。
