Wi-Fi 7

Android 13 以降を搭載したデバイスの場合、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 かどうかを確認できます。デバイスと接続された AP の両方が Wi-Fi 7 をサポートしている場合、STA 接続モードは 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 IEAssocReqAssocRsp の両方にあるかどうかが確認されます。

ネットワークの選択

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

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

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

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

Wi-Fi RTT ベースの距離測定

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

HAL API

次の HAL API は Wi-Fi 7 の RTT ベースの距離測定機能をサポートしています。

API

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

Soft AP

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

Soft 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 の HwModeParamsenable80211BE ブール値は、Wi-Fi 7 モードでの Soft AP の開始をサポートしています。

Soft AP 情報を報告する

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

HAL API

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

API

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

Wi-Fi 7 の MLO 機能

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

MLO の図

図 1. MLO の図。

図 1 で示すように、AP-MLD と STA-MLD の両方に AP インスタンスまたは STA インスタンスがあり、各リンク上で実行されています。各リンクには個別の AP MAC アドレスまたは 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

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

接続された 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

アプリは次の API を使用して、MLO 接続情報を取得できます。

AP-MLD のスキャン

ベンダー ソフトウェアは、受け取った各ビーコンやプローブ応答のスキャン結果を Wi-Fi フレームワークに提供します。このため Wi-Fi フレームワークは:

  • 同じ AP-MLD から複数の ScanResults オブジェクトを受信する可能性があります(AP が複数のビーコンリンクを持つ場合があるため)。
  • AP-MLD の AP リンクの部分的なスキャン結果のセットのみを受信する可能性があります(リンクシグナルの一部がファームウェアに受信されない場合があるため)。

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

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

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

AP-MLD ネットワーク関連付け

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

関連付けが完了すると、ドライバは AP-MLD のリンクの BSSID とともに ISupplicantStaIfaceCallback#onStateChanged() を報告します。その後、スキャン結果がそのリンクのフレームワークに報告されている場合、ドライバは 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 とは異なります。複数のリンク送信が同じアクセス カテゴリ(AC)を持つ場合、STA MLD に関連する STA は、共通の送信機シーケンス番号(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 x 5
  • 2.4 x 6
  • 5 x 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 アドレス。
  • (AP から受け取る)リンク ID。

つまり、フレームワークが同じ 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 がリンクの 1 つを一時的に無効にすることを、ビーコン、プローブ応答、関連付け応答フレームで送信される TID からリンクへのマッピング要素を通じて通知すると、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.aidlFeatureSetMask にあります。T2LM_NEGOTIATION = 1 << 8 機能は、チップが TID からリンクへのマッピングをサポートしていることを示します。API

AP の機能

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

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 ユーザビリティ統計情報を更新します。

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

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)

アプリは android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() メソッドを呼び出し、利用可能なリンク ID をクエリします。

シングルリンク(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 アクセス ポイントのリンクのうちの一つが再利用されると、AP は MLO リンク再構成を通じてリンクの削除を通知できます。ステーションは、残りのリンクで再関連付けすることなく、AP とのシームレスな接続を維持できます。

ISupplicantStaIfaceCallback.aidl の Wi-Fi サプリカントにある 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 リンク上で同時にデータを送受信できるようになり、低レイテンシ、高帯域幅、低電力など、特定の要件を持つアプリのパフォーマンスを向上できます。チップベンダーは、利用可能なリンクの使用方法に関するアルゴリズムを開発できます。

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

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

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