Wi-Fi と Bluetooth

24 分で読了
このページの目次

ルーターの公称値が数千メガビットでも、ダウンロードは百メガビットの上り速度で制限される可能性があります。Bluetooth 接続の公称値が 2 Mbit/s でも、センサー通知が毎秒 250 kB を送信するとは限りません。無線性能はまず空中線時間の割り当てに依存し、さらにプロトコルオーバーヘッド、信号条件、ホストおよびアプリケーションの影響を受けます。本稿では、Wi-Fi の空中線予算と BLE の属性転送を用いて、スループット、レイテンシ、消費電力のトレードオフを解説します。

判断すべき事項本稿の入口最初に区別すべき点
Wi-Fi が公称値に達しない理由PHY と airtime物理層レート、共有時間、アプリケーションスループット
OFDMA/MIMO/MLO の違い無線リソースの3つの次元周波数、空間、マルチリンク
BLE 接続後のデータ転送方法GAP、GATT、ATTリンク接続、セキュリティ、サービス操作
Bluetooth デバイスの低レイテンシ・省電力化接続イベントとデューティサイクルピーク電流、平均電流、業務頻度
Wi-Fi 満杯時に Bluetooth が音声切断共存と分離周波数スペクトルの衝突、近端抑圧、スケジューリング、ソフトウェア

Wi-Fi の世代は能力の集合を提供するものであり、単一端末の保証値ではない

名称対応する主要技術体系代表的な変化
Wi-Fi 4802.11nMIMO、より広いチャネルなど
Wi-Fi 5802.11ac5 GHz、高次変調、ダウンリンク MU-MIMO
Wi-Fi 6 / 6E802.11axOFDMA、アップリンク/ダウンリンクのマルチユーザー能力、TWT;6E は 6 GHz への拡張を示す
Wi-Fi 7802.11beMLO、320 MHz などの能力と 4096-QAM

実際の機能は、AP、クライアント、ドライバ、ファームウェア、利用可能な周波数帯域によって共同で決定されます。320 MHz や 6 GHz の機能は特に地域やデバイスのサポートに依存しており、世代名を「すべてのモードが有効になっている」と見なしてはいけません。公式製品仕様でも、空間ストリーム、帯域幅、変調方式は別々に記載されており、マルチバンド AP の合計レートを単一のスマートフォンの利用可能レートと見なしてはいけません。Intel:Wi-Fi 7 能力の説明

2.4 GHz は Bluetooth、802.15.4、その他のデバイスと環境を共有することが多く、5/6 GHz は異なるチャネルリソースを提供しますが、「干渉のない」クリーンなスペクトルではありません。カバレッジは送信電力、アンテナ、受信感度、障害物、ノイズによって共同で決定されます。より高い周波数は通常、伝播と遮蔽に対して異なる要件を課すため、帯域だけで部屋の効果を判断することはできません。利用可能なチャネルと電力は、現地の適用設定とデバイスの規則に基づいて決定され、ここでは一般的なクロスリージョンチャネル表は提供しません。

PHY レートが高いのに、なぜアプリケーションが遅いことがあるのか

PHY レートは、チャネル幅、空間ストリーム数、変調符号化、ガードインターバルなどに依存します。高次 QAM はシンボルあたり多くのビットを伝送しますが、より良い SNR 条件を要求します。信号が悪化すると、レート適応によって変調/符号化レベルが低下するか、再送によって追加の時間が消費されます。RSSI が高くても、干渉が大きいと SNR が不足する可能性があります。

Wi-Fi には、チャネル競争、バックオフ、プレアンブル、フレームヘッダー、確認応答なども必要です。簡略化した例として、1500 B の有効データが仮に 600 Mbit/s の PHY であれば 20 μs で済みますが、1回の交換に追加で 100 μs の固定オーバーヘッドがある場合、アプリケーションの有効効率は 100 Mbit/s になります。10パケットの集約でこの仮定の固定コストを共有すれば、400 Mbit/s に達します。実際のオーバーヘッドは完全に固定されているわけではなく、この例は集約が重複オーバーヘッドを削減するメカニズムを示すものであり、テスト結果ではありません。

単一パケット仮定の固定オーバーヘッド 100 μs20 μs1500 B / 120 μs = 100 Mbit/s集約100 μs10パケットのペイロード合計 200 μs15000 B / 300 μs = 400 Mbit/sPHY は高速だが、小さなパケットでも待機と制御に時間がかかる場合がある2行はそれぞれ総時間でスケーリングされています。固定オーバーヘッドは教育用の仮定であり、実際の集約でもヘッダー、確認応答、再試行、スケジューリングのコストが残ります。

低速または再送が多いクライアントは、転送するバイト数が少なくても大量の airtime を消費する可能性があります。スループット分析では、占有時間、再試行、ネゴシエートされたレート、有線上り速度を同時に確認する必要があります。「接続レート」や「信号満タン」だけを単独で見るのは不十分です。インターネット速度は WAN、サーバー、ルーターの性能にも影響を受けるため、インターネット速度テストの結果を無線 PHY のみに起因するものとして直接帰因することはできません。

PHY速度二倍でもスループットが二倍にならない理由は?

600 Mbit/sの一包はデータ20 μsでも合計120 μs。PHYを二倍にしても固定100 μsは不変。十包集約すると別の改善理由が見える。帯は時間比率で周波数幅ではない。

図を準備しています
PHY速度二倍でもスループットが二倍にならない理由は?

PHY高速化はデータ時間だけを短くし、集約は交換固定負担を分散する。

OFDMA、MU-MIMO、MLO はそれぞれ何を解決するのか

OFDM は複数の直交サブキャリアを用いて1回の転送を担います。OFDMA はスケジューリングにおいてサブキャリアをリソースユニット(RU)に分割し、異なるユーザーが同じマルチユーザー転送の周波数リソースを共有できるようにします。OFDMA は OFDM を「単一車線」から「複数車線」に変えるものではなく、OFDM 自体にすでに複数のサブキャリアがあるためです。重要なのは、リソースを複数のユーザーに割り当てることです。AP には対応するスケジューリング情報と制御オーバーヘッドが必要であり、すべてのトラフィックで自動的にレイテンシが低くなるとは限りません。Cisco:OFDMA RU 割り当て

MIMO は空間パスを利用して転送または受信を改善し、アンテナ数が必ずしも利用可能な独立したデータストリームの数に等しいわけではありません。MU-MIMO は空間次元で複数のユーザーを同時にサービスし、その効果はチャネルの分離可能性、推定、スケジューリングに依存します。OFDMA と MU-MIMO は併用可能で、それぞれ周波数と空間リソースを利用し、二者択一ではありません。

MLO は複数のリンクをマルチリンクデバイスの協調管理に組み込み、スループット、スケジューリング、信頼性の改善に使用できます。マルチリンクでの同時送受信が可能かどうか、どの周波数帯域を使用するか、RF リソースをどのように共有するかは、具体的なモードに依存します。「2.4+5+6 GHz の3つの周波数帯が同時に叠加される」や「あらゆる干渉でシームレスに切り替わる」と一概に記述することはできません。別の AP へのローミングも同じ概念ではありません。

TWT はウェイクアップ時間をスケジュールすることを可能にし、不要なリスニングを削減しますが、双方がサポートし、業務周期に一致する必要があります。スリープモード、バッファ、ウェイクアップレイテンシにはトレードオフがあります。継続的な大規模トラフィックや厳格な低レイテンシタスクでは、同様の省電力効果が得られるとは限りません。

BR/EDR と LE:Bluetooth システム内にありながら、同じ無線リンクではない

特徴Bluetooth BR/EDRBluetooth LE
典型的な物理構成2.4 GHz、79 個の 1 MHz チャネル2.4 GHz、40 個の 2 MHz チャネル、役割に応じてブロードキャスト/データ用途を担当
一般的な PHY データレートBR 1 Mbit/s、EDR 2/3 Mbit/sLE 1M、オプションの 2M、オプションの Coded など
一般的な機能モデルA2DP、HFP などのクラシックプロファイルGATT データ、ブロードキャスト、および対応する LE Audio などの体系
消費電力とレイテンシ業務、実装、スケジューリングによって決定固定のワット数やミリ秒値で概括することはできない

LE Coded はより多くの符号冗長を用いて受信能力を改善し、従来の S=2/S=8 モードでそれぞれ 500/125 kbit/s 級のデータレートを実現し、レートとカバレッジのトレードオフを行います。同じ PHY で最高レートと最大通信距離を同時に得られるわけではありません。実際の距離は、アンテナ、環境、電力、受信機に依存します。

Bluetooth Core は 6.x へ進化しています。対応機能は該当仕様と製品の宣言で確認します。ただし、バージョンは利用可能な機能のセットではありません。デバイスを選択する際は、PHY、データ長拡張、ブロードキャスト、測距、オーディオ、システム API のサポートを項目ごとに確認する必要があり、「4.2 で十分」や「5.0 の方が省電力」と単純に言うべきではありません。Bluetooth SIG:コアバージョンと製品開発

BLE:検出、接続、ペアリング、サービスアクセスは別々に考える

Peripheral は接続可能ブロードキャストによって Central に検出されます。アクティブスキャンの Scan Request/Scan Response は追加のブロードキャストデータを取得するために使用されますが、接続確立前に必須のステップではありません。接続不可またはスキャン不可のブロードキャストタイプもあります。接続確立後、データは接続イベントで交換され、ブロードキャストタイミングと接続タイミングは異なる組織方式です。Bluetooth SIG:LE 入門

PeripheralCentral接続可能ブロードキャスト:対向側の検出用接続開始:Scan Request は必須ではないサービス/キャラディスカバリ、必要に応じてセキュリティ接続を確立CCCD への書き込み:通知サポートをサブスクライブNotification:接続イベントに応じて属性値を送信BLE:検出、接続、セキュリティ、サービスサブスクリプションは異なる段階である図は一般的な GATT の使用方法を示しています。Central/Peripheral はリンクの役割であり、GATT Client/Server は役割名によって強制されるものではありません。

GAP は検出、接続、役割などの一般的なプロセスを記述します。GATT はサービス、キャラディスクリプタを用いて属性アクセスを組織し、ATT は基礎となる属性操作を担当します。温度サービスには温度キャラが含まれ、キャラには UUID、値、権限があります。UUID はタイプを記述するものであり、アクセスのたびに使用されるすべてのアドレス情報ではありません。実際の ATT では attribute handle も使用されます。

Central/Peripheral はリンクの役割であり、GATT Client/Server は属性操作の開始と属性の提供の役割です。これらを等号で結ぶことはできません。一般的なセンサーは Peripheral に GATT Server を組み合わせますが、プロトコルはすべてのアプリケーションがこの組み合わせを採用することを強制するものではありません。

ペアリングは対応するセキュリティ関係を確立し、bonding は後続の再利用可能な鍵などの情報を保存することを意味します。接続自体が自動的にペアリング済みまたは暗号化済みであることを意味するわけではありません。特定のキャラでは認証、暗号化、またはアプリケーション権限を要求する場合があります。Just Works は、認証付きの対話方式と同様の中間者攻撃防止を提供しません。機密性の高い業務では、脅威とデバイスの相互作用能力に応じて適切なセキュリティメカニズムを選択する必要があり、「Bluetooth ペアリングが成功した」からといって、すべての操作が承認されたと見なしてはいけません。

Notification、Indication、アプリケーション確認は異なる

Notification は対応する ATT confirmation を要求しませんが、通常は接続リンク層の確認/再送メカニズムがあります。「ATT 確認なし」は「完全に信頼できない裸のブロードキャスト」を意味しません。Indication はクライアントの confirmation を必要としますが、この確認がアプリケーションによる実行、保存、表示を意味するわけではありません。業務処理を保証するには、シーケンス番号、状態、またはアプリケーション確認を設計する必要があります。

一般的なサブスクリプションは CCCD への書き込みによって、デバイスがサポートする通知または指示を有効にします。接続完了後にサービスを検出するだけでサブスクライブしていない場合、アクティブな更新を受け取らないままになる可能性があり、無線接続の障害と直接判断することはできません。属性操作は権限とデバイスのアプリケーション状態によって制限されます。

BLE スループット:MTU、リンクデータ長、イベント予算は別々に計算する

従来の ATT notification の値長さの上限は ATT_MTU−3 で、3バイトは opcode と handle に使用されます。MTU=23 の場合、1回あたり最大 20 B、MTU=247 の場合、最大 244 B です。ATT MTU、リンク層データ長、PHY レートは異なるパラメータであり、大きな ATT PDU はリンク層の断片化を必要とする場合があります。Bluetooth Core:ATT フォーマット

双方が MTU=247 にネゴシエート済みと仮定し、アプリケーションが 30 ms ごとに接続イベントで成功して4つの最大長通知を送信する場合、有効データは 4×244/0.03≈32533 B/s、つまり 260.27 kbit/s になります。イベント内に4つを配置できるかどうかは、PHY、データ長、確認/間隔、コントローライベント長、再試行、システムスケジューリングに依存し、2M PHY の固定効率ではありません。

30 ms ごとに1回イベントが発生することは、サービス機会を刚刚逃したデータは待機が必要であることを意味します。より短い間隔は一部の応答を改善できますが、ウェイクアップコストや占有が増加します。Peripheral latency は条件が満たされた場合にいくつかのイベントをスキップすることを許可し、スーパビジョンタイムアウトはリンクの切断を判断するために使用されますが、アプリケーションが許容するレイテンシと直接等しいわけではありません。新バージョンには追加のスケジューリング能力がある場合があり、具体的な最小/最大パラメータは双方のコントローラとシステムのサポートを確認する必要があります。

平均消費電力は活動時間の積分で算出する

あるセンサーが 100 ms ごとに 2 ms 活動し、電流が 8 mA、残りの 98 ms が 5 μA と仮定すると、平均電流は約 0.1649 mA になります。220 mAh の理想容量をこの電流で割ると、約 1334 時間になります。これは極めて簡略化された電力計算であり、サンプリング、CPU、レギュレータの損失、再送、接続確立、バッテリーの自己放電と容量変化は含まれておらず、製品の連続使用時間を保証するものではありません。

より長い間隔が必ずしも常に省電力になるとは限りません。再接続やバックログ処理が増加すると、全体のエネルギー消費が増加する可能性があります。無線送信の瞬時電力を「BLE の一般的な消費電力」表に埋め込むのではなく、完全な使用サイクルの電流軌跡を測定する必要があります。

オーディオと位置情報はコアバージョンだけでなく機能を調べる

クラシックオーディオは通常 A2DP/HFP を使用します。LE Audio には独自のオーディオアーキテクチャ、LC3、アイソクロナス転送、サービス/構成要件があります。Bluetooth 5.2 は必要なコアメカニズムの1つを導入しましたが、5.2 以上のすべてのデバイスが完全な LE Audio を備えているわけでも、すべての TWS イヤホンが LE Audio を使用しているわけでもありません。スマートフォン、イヤホン、コントローラ、ドライバ、システムオーディオスタックは連携する必要があります。Bluetooth SIG:LE Audio FAQ

AoA/AoD はアンテナアレイと角度処理に依存し、Channel Sounding は別の測距能力のカテゴリーに属します。「Bluetooth 5.1」だけでセンチメートル単位の位置決めが保証されるわけではありません。角度、距離、最終的な位置精度は異なる出力であり、環境のマルチパス、キャリブレーション、設置が結果に影響を与えます。

同一デバイスでの共存:2つのソフトウェアプロセスが交互にパケットを送るだけではない

Wi-Fi と Bluetooth が共用または近接アンテナを使用する場合、本机の強力な送信により、もう一方の受信機が抑圧される可能性があります。これは、リンク自体の遠端信号が弱いわけではない場合でも同様です。改善手段には、アンテナ分離、周波数帯域の割り当て、周波数ホッピングの適応、PTA などの調整メカニズムがあります。PTA はリクエスト、優先度、承認に基づいて送受信ウィンドウをスケジュールし、任意の Bluetooth パケットが Wi-Fi を無条件に停止させるわけではありません。Silicon Labs:無線共存

組み合わせモジュールでは、Wi-Fi が PCIe/SDIO/USB を介してホストに接続し、Bluetooth が USB/UART を介して HCI を公開することがありますが、具体的な接続はモジュールの設計に従います。ドライバ、ファームウェア、RF、電源、アンテナの問題が切断を引き起こす可能性があり、証拠なしに特定のモデルの障害を「共存メカニズムの機能不全」として記述することはできません。

観察有用な対照分離したい要因
Wi-Fi 負荷下で Bluetooth が音声欠落アイドルとローカル負荷、異なる利用可能な周波数帯同周波数競争とホスト処理負荷
信号は強いが Wi-Fi が遅い再試行、チャネル占有、上り速度干渉とシステムボトルネック
BLE は接続できるが通知がないサービス権限、CCCD、MTU、イベントログ業務構成と空中線の問題
近距離では正常、遠距離で異常レート適応、再試行、アンテナ位置リンク予算であり、単なるバージョン差ではない

スループットと平均電流の再計算

from math import isclose

packet_bits = 1500*8
single_time = packet_bits/600e6 + 100e-6
aggregate_time = packet_bits*10/600e6 + 100e-6
assert isclose(packet_bits/single_time, 100e6)
assert isclose(packet_bits*10/aggregate_time, 400e6)
assert (23-3, 247-3) == (20, 244)
ble_bytes_per_s = 4*(247-3)/0.030
assert isclose(ble_bytes_per_s*8, 260266.6666666667)
avg_ma = 8*(2/100)+0.005*(98/100)
assert isclose(avg_ma, 0.1649)
assert 1334 < 220/avg_ma < 1335
print('空中線オーバーヘッド、ATT 通知、平均電流の教育用予算チェック通過')

継続的な参照