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 프레임워크에는 기기가 Wi-Fi 7을 지원하는지 확인하기 위해 앱이 ScanResults.WIFI_STANDARD_11BE 인수로 호출할 수 있는 WifiManager#isWifiStandardSupported(int standard) API가 포함되어 있습니다.

이 API가 호출되면 Wi-Fi 모듈은 config_wifi11beSupportOverride 구성 오버레이가 재정의로 사용되는지 확인하고 다음을 수행합니다.

  • 오버레이가 true 로 설정된 경우 장치는 nl80211의 응답에 관계없이 Wi-Fi 7을 지원하는 것으로 가정됩니다. 이 재정의는 Wi-Fi 7 지원을 반환하는 드라이버가 없는 장치 제조업체에만 유용합니다.
  • 오버레이가 false (기본값)로 설정된 경우 Wi-Fi 모듈은 nl80211의 정보를 사용합니다. Wi-Fi 모듈은 nl80211 명령 NL80211_CMD_GET_WIPHY 를 호출하는 wificond로부터 정보를 요청합니다. NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY 속성이 드라이버의 응답에 있는 경우 해당 장치는 Wi-Fi 7을 지원하는 것으로 간주됩니다.

스캔된 AP Wi-Fi 7 지원

Android 프레임워크에는 스캔된 액세스 포인트(AP)가 Wi-Fi 7을 지원하는지 여부를 확인하기 위해 앱이 호출할 수 있는 int ScanResult#getWifiStandard() API가 포함되어 있습니다. 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 프레임워크에는 앱이 현재 스테이션(STA) 연결 모드가 Wi-Fi 7인지 확인하기 위해 호출할 수 있는 int WifiInfo#getWifiStandard() API가 포함되어 있습니다. 기기와 연결된 장치가 모두 있을 때 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를 결정합니다. 매개변수 중 하나는 ThroughputPredictor 블록을 사용하여 추정되는 AP의 추정 처리량입니다. ThroughputPredictor 블록은 장치와 검색된 AP 모두의 PHY 매개변수를 사용합니다.

Android 13에서 ThroughputPredictor 계산에 다음 AP 기능을 사용합니다.

  • Wi-Fi 7(802.11be) 지원
  • 320MHz 채널 폭 지원

ThroughputPredictor 로직에 이러한 기능을 포함하면 장치가 이러한 기능을 사용할 수 있을 때 Wi-Fi 7 지원 AP를 선택할 가능성이 높아집니다.

Wi-Fi RTT 기반 범위 지정

Android는 EHT 프리앰블에 대한 API 지원과 Wi-Fi RTT 에 대한 320MHz 채널 폭을 제공합니다. 이를 통해 칩에서 지원할 때마다 RTT 범위에서 Wi-Fi 7 관련 기능을 지원할 수 있습니다.

HAL API

다음 HAL API는 RTT 기반 범위 지정을 위한 Wi-Fi 7 기능을 지원합니다.

아피스

앱은 Wi-Fi 7 RTT 기반 범위 지정을 위해 다음 API를 사용할 수 있습니다.

소프트 AP

안드로이드는 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 모드에서 소프트 AP 시작을 지원합니다.

소프트 AP 정보 보고

Android에는 보고된 소프트 AP 정보에 Wi-Fi 7 및 320MHz 채널 폭 정보를 포함하는 API 지원이 포함되어 있습니다.

HAL API

IHostapdCallback#onApInstanceInfoChanged() 콜백에 보고된 ApInfo 에 사용되는 Hostapd HAL의 Generation.aidl AIDL 인터페이스에 있는 WIFI_STANDARD_11BE 상수는 소프트 AP 정보 보고를 지원합니다.

아피스

앱은 SoftApInfo 에서 다음 방법(시스템 API)을 사용하여 Soft AP 정보를 보고할 수 있습니다.

MLO Wi-Fi 7 기능

MLO(Multi-link Operation)는 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 : 활성. 링크가 연결되어 활성화되어 있습니다(적어도 하나의 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(Reduced Neighbor Report) IE를 구문 분석하여 연결된 링크 정보 목록을 읽습니다.

아피스

스캔된 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 주소를 읽고 연결된 링크의 상태를 업데이트합니다.

아피스

MLO 연결 정보를 얻기 위해 앱은 다음 API를 사용할 수 있습니다.

AP-MLD 스캐닝

공급업체 소프트웨어는 Wi-Fi 프레임워크에 수신되는 각 비콘 또는 프로브 응답에 대한 스캔 결과를 제공합니다. 이는 Wi-Fi 프레임워크가 다음을 의미합니다.

  • 동일한 AP-MLD에서 여러 ScanResults 개체를 수신할 수 있습니다(AP에 여러 비커닝 링크가 있을 수 있기 때문).
  • AP-MLD의 AP 링크에 대한 스캔 결과 중 일부만 수신할 수 있습니다. 이러한 링크 신호 중 일부는 펌웨어에서 수신되지 않을 수 있기 때문입니다.

공급업체 소프트웨어는 무선으로 수신된 스캔 결과만 보고하며 AP-MLD가 광고한 링크를 기반으로 스캔 결과를 생성(인위적으로 합성)해서는 안 됩니다.

공급업체 소프트웨어는 보고된 스캔 결과에 AP 인스턴스로부터 수신된 기본 변형 다중 링크 및 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와 다릅니다. STA MLD에 소속된 STA들은 다중 링크 전송이 동일한 액세스 카테고리(AC)를 갖는 경우 서로 다른 링크에 할당된 공통 SN(Transmitter Sequence Number)과 데이터 전송을 위한 공통 공간을 공유합니다.

사용되는 최대 STR 링크 수는 칩이 지원하는 최대 무선 수와 다를 수 있습니다. 그림 2의 예에서 최대 STR 링크 수는 2입니다.

다음 AIDL HAL 인터페이스는 최대 STR 링크 수 및 최대 연결 링크 수 기능을 지원합니다.

다중 링크는 경쟁 방식인 eMLSR(Enhanced Multi-Link Single Radio)을 사용하여 단일 무선에서 작동할 수 있습니다. 다중 링크 장치는 특정 기본 제어 프레임을 수신하고 링크 세트에서 CCA(Clear Channel Assessment)를 동시에 수행할 수 있는 경우 링크 세트를 통해 eMLSR을 사용합니다. 그러나 MLD는 한 번에 하나의 링크(각 전송 기회(TXOP) 기간에 동적으로 선택된 링크)에서만 데이터를 전송하거나 수신합니다.

MLD 스테이션은 칩에서 지원하는 경우 STR 및 eMLSR에서 동시에 작동하여 더 나은 안정성, 더 나은 처리량 및 낮은 대기 시간(단일 링크 레거시 스테이션과 비교)을 위해 연결 링크 수를 최대화할 수 있습니다. 그림 2에서 최대 연관 링크 수는 3입니다.

다음 AIDL HAL 인터페이스는 최대 연결 링크 수 기능을 지원합니다.

동시 밴드 조합

프레임워크는 칩에 쿼리하여 동시에 작동할 수 있는 허용된 무선 조합( IWifiChip.aidl AIDL 인터페이스를 통해)을 가져옵니다. 이 정보로부터 프레임워크는 가능한 동시 대역 조합을 도출합니다. 다음은 동시 대역 조합(GHz) 목록의 예입니다.

  • 2.4
  • 5
  • 6
  • 2.4x5
  • 2.4x6
  • 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를 호출하여 절전 상태를 강제로 비활성화할 수 있습니다. 프레임워크에 의해 절전 상태가 비활성화된 경우 공급업체 펌웨어는 하나 이상의 링크를 활성 상태로 유지해야 합니다(절전 비활성화). 이 상태에서 펌웨어 구현은 어떤 링크가 설정되는지 결정합니다.

데이터 경로

이는 업링크 및 다운로드 트래픽을 처리하기 위한 공급업체 펌웨어 구현을 설명합니다.

펌웨어는 내부 구현에 따라 업링크 트래픽을 하나 이상의 링크로 라우팅합니다. 공급업체 펌웨어는 트래픽 패턴을 기반으로 트래픽 로드 밸런싱, 복제 또는 집계를 수행할 시기를 결정합니다. 다음과 같은 경우에는 여러 링크에 대한 펌웨어 중복 트래픽을 권장합니다.

  • 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의 모든 링크에는 단일 APF 필터가 있습니다.

동시성

새로운 인터페이스에 라디오가 사용되는 동시성 시나리오는 동일한 인터페이스의 링크에 대해 여러 라디오를 전용으로 사용하는 것보다 우선순위가 높아야 합니다. 동시성 시나리오는 어느 것이 먼저 나오든 MLO보다 우선순위를 가져야 합니다. 단일 인터페이스에 여러 링크를 사용하는 것은 기회주의적입니다. 즉, 다음과 같은 경우에만 여러 링크가 사용됩니다.

  • 로드 밸런싱, 집계 또는 복제에 대한 펌웨어 결정에 따라 MLO 가 필요합니다 .
  • MLO를 사용할 수 있습니다 . 즉, 다른 인터페이스에는 라디오가 필요하지 않습니다.

Android 14 이상을 실행하는 기기의 경우 Wi-Fi 7 AP가 비컨, 프로브 응답, 연결 응답 프레임에서 전송되는 TID-링크 매핑 요소를 통해 링크 중 하나의 일시적인 비활성화를 알리면 Wi-Fi 7은 스테이션은 다른 연결을 수행하지 않고 설정된 나머지 링크를 사용하여 AP와의 연결을 계속합니다.

Android 13 이하를 실행하는 기기의 경우 Wi-Fi 프레임워크는 연결된 링크가 TID에 연결되지 않은 경우에도 TID-링크 매핑으로 인해 링크 상태가 변경될 때 알림 수신을 지원하지 않습니다.

Wi-Fi 신청자는 다음 AIDL 인터페이스를 통해 Wi-Fi 프레임워크에 TID-링크 매핑 변경 사항을 알립니다.

앱은 다음 API를 사용하여 TID-링크 매핑 변경 사항에 대한 정보를 얻을 수 있습니다.

Android 14 이상을 실행하는 장치의 경우 스테이션 및 AP에 대한 TID-링크 맵 협상 기능을 가져오는 데 다음 API를 사용할 수 있습니다.

칩 성능

다음 인터페이스는 TID-링크 매핑 협상을 위한 칩 기능을 지원합니다.

AIDL HAL

TID-링크 매핑 협상을 위한 AIDL 인터페이스는 hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl 의 FeatureSetMask 에 있습니다. T2LM_NEGOTIATION = 1 << 8 기능은 칩이 TID-링크 매핑을 지원함을 나타냅니다. 아피스

AP 기능

다음 인터페이스는 TID-링크 매핑 협상을 위한 AP 기능을 지원합니다.

AIDL HAL

프레임워크는 현재 연결 기능과 함께 신청자의 AP 기능을 쿼리합니다.

아피스

링크 레이어 통계에는 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 액세스 포인트의 링크 중 하나가 용도 변경되면 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 링크에서 데이터를 보내고 받을 수 있으므로 짧은 대기 시간, 높은 대역폭, 저전력과 같은 특정 요구 사항이 있는 앱의 성능을 향상시킬 수 있습니다. 칩 공급업체는 사용 가능한 링크를 사용하는 방법에 대한 알고리즘을 개발할 수 있습니다.

권한 있는 앱은 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 모드를 설정합니다.