Wi-Fi 7

Android 13 以降を実行しているデバイスの場合、Android は Wi-Fi 7 (IEEE 802.11be) 標準をサポートします。このページでは、ベースラインやマルチリンク操作 (MLO) などの Android Wi-Fi 7 の機能について説明します。

Wi-Fi 7 のベースライン機能

このセクションでは、Android 13 以降に含まれる基本的な Wi-Fi 7 機能について説明します。

デバイスのWi-Fi 7のサポート

Android フレームワークにはWifiManager#isWifiStandardSupported(int standard) API が含まれており、アプリがScanResults.WIFI_STANDARD_11BE引数を使用してこの API を呼び出して、デバイスが Wi-Fi 7 をサポートしているかどうかを確認できます。

この API が呼び出されると、 Wi-Fi モジュールはconfig_wifi11beSupportOverride構成オーバーレイがオーバーライドとして使用されているかどうかを確認し、次の処理を実行します。

  • オーバーレイがtrueに設定されている場合、nl80211 からの応答に関係なく、デバイスは Wi-Fi 7 をサポートすると想定されます。このオーバーライドは、Wi-Fi 7 のサポートを返すドライバーを持たないデバイス メーカーにのみ役立ちます。
  • オーバーレイがfalse (デフォルト値) に設定されている場合、Wi-Fi モジュールは nl80211 からの情報を使用します。 Wi-Fi モジュールは wificond からの情報を要求し、nl80211 コマンドNL80211_CMD_GET_WIPHYを呼び出します。 NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY属性がドライバーからの応答に含まれている場合、デバイスは Wi-Fi 7 をサポートしていると想定されます。

スキャンされた AP Wi-Fi 7 のサポート

Android フレームワークには、 int ScanResult#getWifiStandard() API が含まれており、アプリはこの API を呼び出して、スキャンされたアクセス ポイント (AP) が Wi-Fi 7 をサポートしているかどうかを確認できます。AP が Wi-Fi 7 をサポートしている場合、API はScanResults.WIFI_STANDARD_11BEを返します。アプリがこの API を使用するために、デバイスが Wi-Fi 7 をサポートする必要はありません。

この API が呼び出されると、Wi-Fi モジュールは、返された接続スキャンの結果にEHT Capability IE含まれているかどうかを確認します。スキャン結果にEHT Capability IE含まれている場合、スキャンされた AP は Wi-Fi 7 をサポートしています。AOSP WifiTrackerクラスは、冗長モードで実行しているときにユーザー インターフェイスにこのサポート情報を表示します。

STA接続モード

Android フレームワークにはint WifiInfo#getWifiStandard() API が含まれており、アプリはこの API を呼び出して、現在のステーション (STA) 接続モードが Wi-Fi 7 であるかどうかを確認できます。デバイスと接続されているデバイスの両方が STA 接続モードである場合、STA 接続モードは Wi-Fi 7 になります。 AP は Wi-Fi 7 をサポートします。接続モードが Wi-Fi 7 の場合、API はScanResults.WIFI_STANDARD_11BEを返します。

getWifiStandardが呼び出されると、Wi-Fi モジュールはISupplicantStaIface#getConnectionCapabilities() HAL API を呼び出してモードを決定します。 wpa_supplicant AIDL レイヤーでのこの HAL API の実装は、接続セットアップ中にEHT Capability IEがAssocReqとAssocRspの両方にあるかどうかをチェックします。

ネットワーク選択

Android 13 では、ネットワーク選択ではいくつかのパラメーターを使用して、どの AP に接続するかを決定します。パラメーターの 1 つは AP の推定スループットであり、 ThroughputPredictorブロックを使用して推定されます。 ThroughputPredictorブロックは、デバイスとスキャンされた AP の両方の PHY パラメーターを使用します。

Android 13 では、 ThroughputPredictor計算で次の AP 機能を使用します。

  • Wi-Fi 7 (802.11be) のサポート
  • 320 MHz チャネル幅のサポート

これらの機能をThroughputPredictorロジックに組み込むと、デバイスがこれらの機能を利用できる場合に、Wi-Fi 7 対応 AP を選択する可能性が高まります。

Wi-Fi RTT ベースの測距

Android は、EHT プリアンブルとWi-Fi RTTの 320 MHz チャネル幅の API サポートを提供します。これにより、チップでサポートされている場合は常に、RTT 範囲での Wi-Fi 7 関連機能のサポートが可能になります。

HAL API

次の HAL API は、RTT ベースのレンジングの Wi-Fi 7 機能をサポートします。

API

アプリは、Wi-Fi 7 RTT ベースの測距に次の API を使用できます。

ソフトAP

Android は Soft AP で Wi-Fi 7 をサポートし、次の機能を提供します。

ソフトAPを開始する

Android は、Wi-Fi 7 モードでの Soft AP の起動をサポートしています。これは、 config_wifiSoftapIeee80211beSupportedオーバーレイ構成によって管理されます。

Wi-Fi モジュールは、オーバーレイconfig_wifiSoftapIeee80211beSupportedを使用して、 IHostApd#addAccessPoint() API 呼び出しでブール値のHwModeParams#enable80211BEを設定します。 hostapd AIDL レイヤーでは、この値はhostapd.confパラメーターの設定に使用されます。

HAL API

hostapd HAL のHwModeParamsのenable80211BEブール値は、Wi-Fi 7 モードでの Soft AP の起動をサポートします。

Soft AP 情報のレポート

Android には、レポートされる Soft AP 情報に Wi-Fi 7 および 320 MHz のチャネル幅情報を含めるための API サポートが含まれています。

HAL API

hostapd HAL のGeneration.aidl AIDL インターフェイスのWIFI_STANDARD_11BE定数は、 IHostapdCallback#onApInstanceInfoChanged()コールバックでレポートされるApInfoで使用され、Soft AP 情報のレポートをサポートします。

API

アプリは、 SoftApInfoの次のメソッド (システム API) を使用して、Soft AP 情報を報告できます。

MLO Wi-Fi 7 の機能

マルチリンク操作 (MLO) は、Wi-Fi 7 (802.11be) 仕様の主な機能です。 MLO は、同時か非同時かにかかわらず、Wi-Fi 7 で実行されるマルチリンク デバイス (MLD) の必須機能です。

MLO図

図 1. MLO の図。

図 1 に示すように、AP-MLD と STA-MLD の両方には、各リンク上で複数の AP または STA インスタンスが実行されています。各リンクには個別の AP または STA MAC アドレスがあります。 AP または STA には、デバイスを識別するための MLD MAC アドレスもあります。

android.net.wifi.MloLinkクラスは MLO リンクを表します。このクラスには次のパラメータが含まれます。

  • int getLinkId() : AP MLD によってアドバタイズされるリンク ID。
  • MacAddress getApMacAddress() : AP MAC アドレス。そのリンクの AP インスタンスの BSSID。
  • MacAddress getStaMacAddress() : STA MAC アドレス。リンク上の STA インスタンスにローカルに割り当てられた MAC アドレス。
  • int getChannel() : リンクチャネル。リンクのチャネル番号。
  • int getBand() : リンクバンド。リンクのバンド。

  • int getState() : リンク状態。次のいずれかの状態になります。

    • MLO_LINK_STATE_INVALID : 無効です。初期化およびエラーの場合に使用されます。
    • MLO_LINK_STATE_UNASSOCIATED : 関連付けられていません。リンクは AP に関連付けられていません。
    • MLO_LINK_STATE_IDLE : アイドル状態。リンクは関連付けられていますが、アクティブではありません (トラフィック識別子 (TID) がリンクにマップされていません)。
    • MLO_LINK_STATE_ACTIVE : アクティブです。リンクは関連付けられており、アクティブです (少なくとも 1 つの TID がリンクにマッピングされています)。フレームワークはリンクの電力状態を監視しないため、アクティブなリンクは省電力モードになる可能性があります。

スキャンされた Wi-Fi 7 AP MLO 情報

Wi-Fi モジュールが AP-MLD からScanResultオブジェクトを受信すると、アプリは Wi-Fi 7 AP MLD の MLO パラメータを取得できます。 AOSP WifiTracker冗長モードで実行すると MLO パラメータを表示します。

Wi-Fi モジュールは、次の手順を実行して MLO 情報を収集します。

  • ビーコンまたはプローブ応答に含まれるマルチリンク情報要素 (IE) を解析して、AP MLD MAC アドレスと現在のリンク ID を読み取ります。
  • ビーコンまたはプローブ応答に含まれる縮小近隣レポート (RNR) IE を解析して、提携リンク情報のリストを読み取ります。

API

スキャンされた AP MLO 情報を取得するには、アプリは次の API を使用できます。

接続された Wi-Fi 7 AP MLO 情報

デバイスが Wi-Fi 7 AP-MLD に接続すると、フレームワークはWifiInfoオブジェクトから接続の MLO パラメータを収集します。 AOSP WifiTrackerオブジェクトは、冗長モードで実行しているときにこの情報を表示します。

デバイスが AP-MLD に接続すると、Wi-Fi モジュールは AP から受信したScanResultオブジェクトから MLO 情報をコピーします。次に、モジュールはISupplicantStaIface#getConnectionMloLinksInfo() HAL API を呼び出して、AP と STA の両方の各リンクの MAC アドレスを読み取り、関連するリンクの状態を更新します。

API

MLO 接続情報を取得するために、アプリは次の API を使用できます。

AP-MLD スキャン

ベンダー ソフトウェアは、受信した各ビーコンまたはプローブ応答のスキャン結果を Wi-Fi フレームワークに提供します。これは、Wi-Fi フレームワークが次のことを意味します。

  • 同じ AP-MLD から複数のScanResultsオブジェクトを受信する可能性があります (AP が複数のビーコン リンクを持つことができるため)。
  • これらのリンク信号の一部はファームウェアによって受信されない可能性があるため、AP-MLD の AP リンクのスキャン結果の部分セットのみを受信する可能性があります。

ベンダー ソフトウェアは、無線で受信したスキャン結果のみを報告し、AP-MLD によってアドバタイズされたリンクに基づいてスキャン結果を作成 (人為的に合成) してはなりません。

ベンダー ソフトウェアは、レポートされるスキャン結果に、AP インスタンスから受信した基本バリアント マルチリンク IE と RNR IE を含める必要があります。関連する AP の詳細がスキャン結果に含まれていない場合、ベンダー ソフトウェアはマルチリンク プローブ リクエスト (プローブ リクエスト マルチリンク要素を含むプローブ リクエスト フレーム) を送信して、機能、パラメータ、および操作要素の完全なセットまたは部分的なセットを含めることができます。応答フレーム内のターゲット AP-MLD を含む AP の情報。

ベンダー ソフトウェアは、必要に応じて ML プローブをトリガーできます (プローブ要求フレーム内のプローブ要求バリアント ML IE を使用)。

AP-MLD ネットワーク アソシエーション

デバイスが AP-MLD ネットワークに参加すると、ベンダー ソフトウェアは選択された AP リンク (関連リンク) をシグナリングに使用します。ベンダー ソフトウェアは、デバイスでサポートされているリンクのすべてまたは一部に関連付けることができます。

アソシエーションが成功すると、ドライバーはISupplicantStaIfaceCallback#onStateChanged() AP-MLD のリンクの BSSID とともに報告します。次に、スキャン結果がそのリンクのフレームワークに報告されている場合、ドライバーは AP-MLD のリンクを選択します。

ネットワークスコアリング

Android 14 以降を実行しているデバイスの場合、 Android Wi-Fi ネットワーク選択はWi-Fi 7 MLO をサポートします。これは、Android が MLO で利用可能なリンクの数に基づいてデバイスに最適な Wi-Fi ネットワークを選択することを意味します。

MLO をサポートするために、ネットワーク選択アルゴリズムは Wi-Fi チップの次の MLO 機能を使用します。

  • 最大STRリンク数
  • 最大アソシエーションリンク数
  • 同時バンドの組み合わせ

Wi-Fi MLO ネットワークの選択

図 2. MLO ネットワークの選択。

同時送受信 (STR) は、マルチリンク動作のための Wi-Fi メディア競合方式です。異なるリンク間の信号分離は、リンクが独立して動作し、異なるリンクで同時に送信および受信できるように十分なものです。 STR は、従来のシングル リンク (SL) STA および従来のデュアル バンド デュアル コンカレント (DBDC) STA とは異なります。 STA MLD に所属する STA は、複数のリンク送信が同じアクセス カテゴリ (AC) を持つ場合、共通の送信機シーケンス番号 (SN) と、異なるリンクに割り当てられたデータ送信用の共通スペースを共有します。

使用される STR リンクの最大数は、チップがサポートする無線の最大数と異なる場合があります。図 2 の例では、STR リンクの最大数は 2 です。

次の AIDL HAL インターフェイスは、最大 STR リンク数と最大数のアソシエーション リンク数機能をサポートします。

競合方式である Enhanced Multi-Link Single Radio (eMLSR) を使用して、複数のリンクを単一の無線で動作させることができます。マルチリンク デバイスは、特定の基本制御フレームを受信し、リンクのセット上で同時にクリア チャネル評価（CCA）を実行できる場合、リンクのセット上で eMLSR を使用します。ただし、MLD は一度に 1 つのリンク (各送信機会 (TXOP) 期間で動的に選択されるリンク) でのみデータを送信または受信します。

MLD ステーションは、チップでサポートされている場合は STR と eMLSR を同時に動作させることで、アソシエーション リンクの数を最大化し、信頼性、スループットを向上させ、遅延を（シングル リンクのレガシー ステーションと比較して）低くすることができます。図 2 では、最大関連付けリンク数は 3 です。

次の AIDL HAL インターフェイスは、最大アソシエーション リンク カウント機能をサポートします。

同時バンドの組み合わせ

フレームワークはチップにクエリを実行して、同時に動作できる許可された無線の組み合わせを ( IWifiChip.aidl AIDL インターフェイス経由で) 取得します。この情報から、フレームワークは可能な同時バンドの組み合わせを導き出します。以下は、同時バンドの組み合わせ (GHz) のリストの例です。

  • 2.4
  • 5
  • 6
  • 2.4×5
  • 2.4×6
  • 5×6

次の AIDL HAL インターフェイスは、同時無線の組み合わせをサポートしています。

ネットワーク選択

ネットワーク選択 (MLO) 中に、候補リストは同じ MLD MAC アドレスを持つメンバーによってグループ化されます。最大予測マルチリンク スループット スコアは、最大 STR リンク数とチップがサポートする同時バンドの組み合わせに基づいて、グループごとに計算されます。候補がマルチリンク対応で、チップが STR をサポートしている場合、予測スループット スコアはマルチリンク予測スループット スコアに置き換えられます。これにより、ネットワーク選択時に MLO 候補が後押しされます。

AP-MLD ネットワークに参加すると、フレームワークは、ベンダー ソフトウェアによって報告されたScanResultsオブジェクトで受信した情報に基づいて SSID の選択を実行します。フレームワークによって SSID が選択されると、ベンダー ソフトウェアは、関連付けに使用する最適な AP (または AP リンク) の BSSID を選択する責任を負います。

デバイスの STA MAC アドレスの処理

このセクションでは、デバイスの STA MAC アドレス (MLD MAC アドレスおよびリンクごとの STA MAC アドレス) がどのように処理されるかについて説明します。

MLD MAC アドレス

Wi-Fi フレームワークは、デバイスの MLD MAC アドレスを管理します。 MLD MAC アドレスは、非 MLD デバイスが独自の MAC アドレスを処理するのと同じ方法で処理されます。 MAC アドレスは、ユーザーの選択に基づいて、ランダム化された MAC アドレスまたはハードウェアによってプロビジョニングされた MAC アドレスになります。 MLD MAC アドレスはIWifiStaIface#setMacAddress() HAL API を使用してフレームワークによって設定されます。

ベンダー ソフトウェアは、インスタンス STA MAC アドレスを (リンクごとに) 管理します。デバイスが AP に関連付けられると、ベンダー ソフトウェアは関連付けられた各リンクにインスタンス MAC アドレスを割り当てます。

ベンダー ソフトウェアは、そのアルゴリズムに基づいてリンクごとの MAC アドレスを割り当てます。アルゴリズムは反復可能であり、次の関数である必要があります。

  • Wi-Fi フレームワークによって設定された STA-MLD MAC アドレス。
  • リンクID（APから受信）

これは、フレームワークが同じ MLD MAC アドレスを再利用する場合、ベンダーは同じ関連付けられたインスタンスごとの MAC アドレスを再利用する必要があり、その逆も同様であることを意味します。これにより、フレームワークで生成された STA-MLD アドレスが SSID に対して永続的である場合、STA ごとの MAC アドレスも永続的であることが保証されます。

以下は、リンクごとの STA MAC アドレス割り当てのアルゴリズムの例です (ベンダーは、アルゴリズム基準を満たす任意のアルゴリズムを実装できます)。

  • オクテット 0: ローカル管理ビットが設定されていることを確認してください
  • オクテット 1 ～ 4: STA-MLD MAC アドレスと同じ
  • オクテット 5: STA ごと = (STA-MLD + リンク ID + 1) MOD (256)

ベンダー ファームウェアは、Wi-Fi フレームワークからの入力なしで、リンクの切り替えを実行し、アクティブ化または非アクティブ化のためのリンクの省電力状態を管理できます。

Wi-Fi フレームワークは、リンク状態が変更されたときの通知を期待しません。

省電力状態の管理

Wi-Fi フレームワークでは、省電力状態がデフォルトで有効になっています。省電力状態では、ベンダー ファームウェアは、トラフィック パターンおよびリンクのアクティブ化または非アクティブ化の決定に基づいて、個々のリンクの省電力状態を管理します。

ただし、Wi-Fi フレームワークはISupplicantStaIface::setPowerSave(false) HAL API を呼び出すことで、省電力状態を強制的に無効にすることができます。フレームワークによって省電力状態が無効になっている場合、ベンダー ファームウェアは少なくとも 1 つのリンクをアクティブ (省電力が無効) に維持する必要があります。この状態では、ファームウェア実装によってどのリンクが設定されるかが決定されます。

データ経路

これは、アップリンクおよびダウンロード トラフィックを処理するためのベンダー ファームウェアの実装について説明します。

ファームウェアは、内部実装に基づいてアップリンク トラフィックを 1 つ (または複数) のリンクにルーティングします。ベンダー ファームウェアは、トラフィック パターンに基づいてトラフィックのロード バランシング、複製、または集約をいつ実行するかを決定します。次の場合には、ファームウェアでトラフィックを複数のリンクに複製することをお勧めします。

  • IWifiChip#setLatencyMode() HAL API を通じて低遅延モードが設定されている場合。
  • ユーザー優先度 6 および 7 のトラフィックがある場合。

ファームウェアは、MAC ヘッダーの (宛先) STA ごとの MAC アドレスを MLD-STA MAC に置き換え、MAC ヘッダーの (送信元) AP ごとの MAC アドレスを MLD-AP MAC アドレスに置き換える必要があります。 APF フィルタ コマンドには MLD MAC アドレスに基づくフィルタがあるため、ファームウェアは APF フィルタを通過する前にこの MAC アドレス置換を実行する必要があります。 AP-MLD のすべてのリンクに対して 1 つの APF フィルタがあります。

同時実行性

無線が新しいインターフェイスに使用される同時実行シナリオは、同じインターフェイスのリンク専用の複数の無線よりも優先される必要があります。また、どちらが先であっても、同時実行シナリオは MLO よりも優先される必要があります。単一のインターフェイスに複数のリンクを使用することは便宜的です。つまり、複数のリンクは次の場合にのみ使用されます。

  • MLO は、ロード バランシング、集約、または複製のためのファームウェアの決定に基づいて必要です。
  • MLOが利用可能です。これは、別のインターフェイスで無線が必要ないことを意味します。

Android 14 以降を実行しているデバイスの場合、Wi-Fi 7 AP がビーコン、プローブ応答、およびアソシエーション応答フレームで送信される TID からリンクへのマッピング要素を通じてリンクの 1 つを一時的に無効にすることを通知すると、Wi-Fi 7ステーションは、別のアソシエーションを実行せずに、セットアップされている残りのリンクを使用して AP との接続を継続します。

Android 13 以前を実行しているデバイスの場合、Wi-Fi フレームワークは、関連付けられたリンクが TID にリンクされていない場合でも、TID からリンクへのマッピングによってリンク状態が変更されたときの通知の受信をサポートしません。

Wi-Fi サプリカントは、次の AIDL インターフェイスを通じて、TID からリンクへのマッピングの変更を Wi-Fi フレームワークに通知します。

アプリは、次の API を使用して、TID からリンクへのマッピングの変更に関する情報を取得できます。

Android 14 以降を実行しているデバイスの場合、次の API を使用して、ステーションと AP の TID からリンクへのマップ ネゴシエーション機能を取得できます。

チップの能力

次のインターフェイスは、TID からリンクへのマッピング ネゴシエーションのチップ機能をサポートします。

AIDL HAL

TID からリンクへのマッピング ネゴシエーション用の AIDL インターフェイスhardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidlのFeatureSetMaskにあります。 T2LM_NEGOTIATION = 1 << 8機能は、チップが TID からリンクへのマッピングをサポートしていることを示します。 API

AP の機能

次のインターフェイスは、TID からリンクへのマッピング ネゴシエーションの AP 機能をサポートします。

AIDL HAL

フレームワークは、現在の接続機能とともにサプリカントから AP 機能を照会します。

  • apTidToLinkMapNegotiationSupported : AP が TID からリンクへのマップ ネゴシエーション機能をサポートしているかどうかを確認します。

API

リンク層の統計には、RSSI、さまざまな TX および RX パケット カウンタ、無線統計などの Wi-Fi リンク固有の詳細が含まれます。 Wi-Fi フレームワークは、リンク層の統計情報と RSSI を定期的にポーリングして、最適なネットワークを選択するか、接続されたネットワークの品質を評価します。 Android 14 以降を実行しているデバイスの場合、リンク層の統計にはマルチリンクのサポートが含まれます。 Wi-Fi 7 をサポートするために、Android はリンク層統計と信号ポーリングの両方で MLO をサポートします。

リンク固有の統計は、次のリンク層 AIDL インターフェイスにあります。

android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener()システム API は、すべてのリンク層の統計をリッスンします。フレームワークはこの API を定期的に呼び出して、Wi-Fi ユーザビリティ統計を更新します。

次のリンク固有の API は、 android.net.wifi.WifiUsabilityStatsEntryで利用できます。

int getRssi(int linkId)
int getLinkState(int linkId)
int getRadioId(int linkId)
int getTxLinkSpeedMbps(int linkId)
long getTotalTxSuccess(int linkId)
long getTotalTxRetries(int linkId)
long getTotalTxBad(int linkId)
long getTotalRxSuccess(int linkId)
long getTotalBeaconRx(int linkId)
int getRxLinkSpeedMbps(int linkId)
int getTimeSliceDutyCycleInPercent(int linkId)
ContentionTimeStats getContentionTimeStats(int linkId, @WmeAccessCategory int ac)
List<RateStats> getRateStats(int linkId)

利用可能なリンク ID をクエリするために、アプリはandroid.net.wifi.WifiUsabilityStatsEntry#getLinkIds()メソッドを呼び出すことができます。

単一リンク (MLO ではない) のandroid.net.wifi.WifiUsabilityStatsEntryの API は、MLO 接続の集約された統計を返します。集計基準は次のとおりです。

  • 次の集約されたパケット統計では、リンクごとの統計の合計が使用されます。

    public long getTotalTxSuccess()
public long getTotalTxRetries()
public long getTotalTxBad()
public long getTotalRxSuccess()
public int getRxLinkSpeedMbps()

  • 次の統計では、RSSI が最も高いリンクからのデータが使用されます。

    public int getRssi()
public int getLinkSpeedMbps()
public long getTotalBeaconRx()
public int getTimeSliceDutyCycleInPercent()
public ContentionTimeStats getContentionTimeStats(@WmeAccessCategory int ac)
public List<RateStats> getRateStats()

Android 13 を実行しているデバイスの場合、リンク層の統計では、単一のインターフェイスに対する複数のリンクの使用状況が考慮されません。 MLO をサポートするには、ベンダー ソフトウェアはIWifi# getLinkLayerStats_1_6() HAL API を通じてLinkLayerStats報告するときに、次の集計ロジックを適用する必要があります。最良のリンクは、RSSI が最も高いリンクです。

  • StaLinkLayerStats.iface.beaconRx : インターフェイスに使用される最適なリンクのビーコン数を報告します。
  • StaLinkLayerStats.iface.avgRssiMgmt : インターフェイスに使用される最適なリンクのavgRssiMgmtをレポートします。
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo、Vi、Be、Bk): インターフェイスのリンク上の集約されたパケット統計 (合計) をレポートします。
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo、Vi、Be、Bk): インターフェイスで使用されている最適なリンクの競合時間統計 (最低の競合時間統計) をレポートします。

Wi-Fi 7 アクセス ポイントのリンクの 1 つが再利用されると、AP は MLO リンク再構成を通じてリンクの削除を通知できます。ステーションは、残りのリンクで再接続することなく、AP とのシームレスな接続を維持できます。

Wi-Fi サプリカントのISupplicantStaIfaceCallback.aidlにあるonMloLinksInfoChanged AIDL インターフェイスは、リンクの再構成 (AP によるリンクの削除) をサポートします。

Wi-Fi フレームワークがリンクの削除を処理するとき、リンク状態はMLO_LINK_STATE_UNASSOCIATEDに設定されます。次に、フレームワークは、リンク状態の変更のためにConnectivityManager.NetworkCallback#onCapabilitiesChanged()をトリガーします。

WifiInfo#getAffiliatedMloLinksメソッドは、関連付けられた MLO リンクを返します。 MloLink#getStateメソッドはリンクの状態を返します。リンクが削除された場合、返されるリンク状態はMLO_LINK_STATE_UNASSOCIATEDです。

チップMLO戦略

MLO を使用すると、デバイスが複数の Wi-Fi リンク上で同時にデータを送受信できるようになり、低遅延、高帯域幅、低電力などの特定の要件を持つアプリのパフォーマンスを向上させることができます。チップ ベンダーは、利用可能なリンクの使用方法に関するアルゴリズムを開発できます。

特権アプリは、 WifimanagerのsetMloModeメソッドを使用してこれらのアルゴリズムを変更し、次のモードを設定できます。

  • MLO_MODE_DEFAULT = 0
  • MLO_MODE_LOW_LATENCY = 1
  • MLO_MODE_HIGH_THROUGHPUT = 2
  • MLO_MODE_LOW_POWER = 3

フレームワークは、 IWifiChip AIDL インターフェイスのsetMloMode使用して MLO モードを設定します。