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 인수를 사용하여 기기가 Wi-Fi 7을 지원하는지 확인합니다.

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

  • 오버레이가 true로 설정되어 있으면 nl80211의 응답과 관계없이 기기가 Wi-Fi 7을 지원한다고 가정합니다. 이 재정의는 Wi-Fi 7 지원 여부를 반환하는 드라이버가 없는 기기 제조업체에만 유용합니다.
  • 오버레이가 false(기본값)로 설정되어 있으면 Wi-Fi 모듈은 nl80211의 정보를 사용합니다. Wi-Fi 모듈은 wificond에 정보를 요청하고 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 IE가 AssocReq와 AssocRsp 모두에 있는지 확인합니다.

네트워크 선택

Android 13에서 네트워크 선택 시 여러 매개변수를 사용하여 어느 AP에 연결할지 결정합니다. 매개변수 중 하나는 AP의 예상 처리량으로, 이는 ThroughputPredictor 블록을 사용하여 예측됩니다. ThroughputPredictor 블록은 기기와 스캔된 AP 양쪽의 PHY 매개변수를 사용합니다.

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

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

기기가 이러한 기능을 사용할 수 있는 경우 이를 ThroughputPredictor 로직에 포함하면 Wi-Fi 7을 사용할 수 있는 AP를 선택할 가능성이 커집니다.

Wi-Fi RTT 기반 범위 지정

Android는 Wi-Fi RTT용 EHT 프리앰블과 320MHz 채널 대역폭을 지원하는 API를 제공합니다. 이 API를 통해 RTT 범위 지정 시 Wi-Fi 7 관련 기능을 사용할 수 있습니다(칩에서 지원해야 함).

HAL API

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

API

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

소프트 AP

Android는 소프트 AP에서 Wi-Fi 7을 지원하고 다음 기능을 제공합니다.

소프트 AP 시작

Android는 Wi-Fi 7 모드에서 소프트 AP 시작을 지원합니다. 이 기능은 config_wifiSoftapIeee80211beSupported 오버레이 구성에 의해 관리됩니다.

Wi-Fi 모듈은 config_wifiSoftapIeee80211beSupported 오버레이를 사용하여 IHostApd#addAccessPoint() API 호출에 불리언 HwModeParams#enable80211BE를 설정합니다. 이 값은 hostapd AIDL 레이어에서 hostapd.conf 매개변수를 설정하는 데 사용됩니다.

HAL API

이 enable80211BE 드림 hostapd HAL에서 지원하는 HwModeParams의 불리언 Wi-Fi 7 모드에서 소프트 AP를 시작합니다.

소프트 AP 정보 보고

Android는 보고된 소프트 AP 정보에 Wi-Fi 7과 320MHz 채널 대역폭 정보를 포함하는 API를 지원합니다.

HAL API

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

API

앱은 다음 메서드 (시스템 API)를 SoftApInfo 드림 소프트 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: 유휴 상태. 이 링크는 연결되어 있지만, 활성 상태가 아닙니다(링크에 매핑된 트래픽 ID(TID)가 없음).
    • MLO_LINK_STATE_ACTIVE: 활성 상태. 이 링크는 연결되어 있고 활성 상태입니다(하나 이상의 TID가 링크에 매핑됨). 프레임워크가 링크의 전력 상태를 모니터링하지 않으므로 활성 링크가 절전 모드일 수 있습니다.

스캔된 Wi-Fi 7 AP MLO 정보

앱은 Wi-Fi 모듈이 Wi-Fi 모듈인 경우 Wi-Fi 7 AP MLD의 MLO 매개변수를 가져올 수 있음 를 받을 수 있습니다. ScanResult 드림 객체를 삭제합니다. AOSP WifiTracker는 상세 출력 모드로 실행 시 MLO 매개변수를 표시합니다.

Wi-Fi 모듈은 다음을 실행하여 MLO 정보를 수집합니다.

  • 비콘 또는 프로브 응답에 포함된 멀티 링크 정보 요소(ID)를 파싱하여 AP MLD MAC 주소와 현재 링크 ID를 가져옵니다.
  • 비콘이나 프로브 응답에 포함된 RNR(Reduced Neighbor Report) 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 링크 중 일부 스캔 결과만 수신할 수도 있습니다(이러한 링크 신호 중 일부는 펌웨어에서 수신할 수 없기 때문).

공급업체 소프트웨어는 무선 업데이트로 수신한 스캔 결과만 보고하고 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(Dual Band Dual Concurrent) STA와 다릅니다. STA MLD와 연결된 STA는 다중 링크 전송이 동일한 액세스 카테고리(AC)를 갖는 경우 다른 링크에 할당된 데이터 전송용 공통 송신기 시퀀스 넘버(SN)와 공통 공간을 공유합니다.

사용된 STR 링크의 최대 개수는 칩에서 지원하는 무선 통신 장치의 최대 개수와 다를 수 있습니다. 그림 2의 예에서 최대 STR 링크 수는 2입니다.

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

멀티 링크는 단일 무선 통신 장치에서 경합 스키마, eMLSR(Enhanced Multi-Link Single Radio)을 사용하여 작동할 수 있습니다. 멀티 링크 기기는 특정 기본 제어 프레임을 수신하고 동시에 링크 세트에서 CCA(Channel Assessment)를 실행할 수 있는 경우 링크 세트를 통해 eMLSR을 사용합니다. 그러나, MLD는 한 번에 하나의 링크(각 전송 기회(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 주소
  • 링크 ID(AP에서 수신)

즉, 프레임워크가 동일한 MLD MAC 주소를 재사용하면 공급업체는 연결된 인스턴스별 MAC 주소를 같은 것으로 재사용해야 하며 반대의 경우도 마찬가지입니다. 이는 프레임워크에서 생성한 STA-MLD 주소가 SSID에 대해 영속적일 때 STA별 MAC 주소 또한 영속적임을 보장합니다.

다음은 링크별 STA MAC 주소 할당에 대한 알고리즘의 예입니다(공급업체는 알고리즘 기준을 충족하는 다른 알고리즘을 구현해도 됨).

  • 옥텟 0: 로컬에서 관리하는 비트가 설정되었는지 확인
  • 옥텟 1~4: STA-MLD MAC 주소와 동일
  • 옥텟 5: Per-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는 필수입니다.
  • MLO를 사용할 수 있습니다. 즉, 다른 인터페이스에서 무선 통신 장치가 필요하지 않습니다.

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

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

Wi-Fi 서플리컨트는 다음의 AIDL 인터페이스를 통해 Wi-Fi 프레임워크에 TID-링크 매핑 변경사항을 알립니다.

앱은 다음 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 기능을 쿼리합니다.

API

링크 레이어 통계에는 RSSI, 다양한 TX 및 RX 패킷 카운터, 무선 통신 통계 등 Wi-Fi 링크별 세부사항이 포함됩니다. Wi-Fi 프레임워크는 주기적으로 링크 레이어 통계과 RSSI를 폴링하여 최적의 네트워크를 선택하고 연결된 네트워크의 품질을 평가합니다. Android 14 이상을 실행하는 기기의 경우 링크 레이어 상태에 멀티 링크 지원이 포함됩니다. Wi-Fi 7을 지원하기 위해 Android는 링크 레이어 통계와 신호 폴링 모두에서 MLO를 지원합니다.

링크별 통계는 다음 링크 레이어 AIDL 인터페이스에서 알아볼 수 있습니다.

이 android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() 드림 system 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() 드림 메서드를 사용하여 축소하도록 요청합니다.

API android.net.wifi.WifiUsabilityStatsEntry 드림 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와 원활하게 연결을 유지할 수 있습니다.

이 onMloLinksInfoChanged 드림 Wi-Fi 서플리컨트에 있는 AIDL 인터페이스 ISupplicantStaIfaceCallback.aidl님, 링크 재구성 (링크의 AP 삭제)을 지원합니다.

Wi-Fi 프레임워크가 링크 삭제를 처리할 때 링크 상태는 MLO_LINK_STATE_UNASSOCIATED로 설정됩니다. 그런 다음 프레임워크는 링크 상태 변경에 대해 ConnectivityManager.NetworkCallback#onCapabilitiesChanged()를 트리거합니다.

WifiInfo#getAffiliatedMloLinks 메서드는 연결된 MLO 링크를 반환합니다. MloLink#getState 메서드는 링크 상태를 반환합니다. 링크가 삭제되면 반환된 링크 상태는 MLO_LINK_STATE_UNASSOCIATED입니다.

칩 MLO 전략

MLO를 사용하면 기기에서 동시에 여러 Wi-Fi 링크에 데이터를 송수신할 수 있습니다. 이는 낮은 지연 시간, 고대역폭, 저전력과 같이 특별한 요구사항을 가진 앱의 성능을 향상할 수 있습니다. 칩 공급업체는 가용한 링크를 사용하는 방법에 대해 알고리즘을 개발하면 됩니다.

권한이 있는 앱은 setMloMode 드림 Wifimanager 메서드를 사용하고 다음과 같은 모드를 지원합니다.

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

이 프레임워크는 setMloMode 드림 (IWifiChip AIDL 인터페이스) MLO 모드를 설정합니다