Wi-Fi 7

Per i dispositivi con Android 13 o versioni successive, Android supporta lo standard Wi-Fi 7 (IEEE 802.11be). Questa pagina descrive le funzionalità di Android Wi-Fi 7, tra cui il funzionamento di riferimento e multi-link (MLO).

Funzionalità di base di Wi-Fi 7

Questa sezione descrive le funzionalità di base del Wi-Fi 7 incluse in Android 13 e versioni successive.

Supporto del Wi-Fi 7 per i dispositivi

Il framework Android include l'API WifiManager#isWifiStandardSupported(int standard), che le app possono chiamare con l'argomento ScanResults.WIFI_STANDARD_11BE, per verificare se un dispositivo supporta il Wi-Fi 7.

Quando viene chiamata questa API, il modulo Wi-Fi controlla se l'overlay di configurazione config_wifi11beSupportOverride viene utilizzato come override ed esegue le seguenti operazioni:

  • Se l'overlay è impostato su true, si presume che il dispositivo supporti il Wi-Fi 7 indipendentemente dalla risposta di nl80211. Questa impostazione predefinita è utile solo per i produttori di dispositivi che non dispongono di driver che supportano il Wi-Fi 7.
  • Se l'overlay è impostato su false (valore predefinito), il modulo Wi-Fi utilizza le informazioni di nl80211. Il modulo Wi-Fi richiede le informazioni a wificond, che chiama il comando nl80211 NL80211_CMD_GET_WIPHY. Se l'attributo NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY è presente nella risposta del driver, si presume che il dispositivo supporti il Wi-Fi 7.

Supporto del Wi-Fi 7 per gli AP scansionati

Il framework Android include l'API int ScanResult#getWifiStandard() che le app possono chiamare per verificare se un punto di accesso (AP) scansionato supporta il Wi-Fi 7. Se l'AP supporta il Wi-Fi 7, l'API restituisce ScanResults.WIFI_STANDARD_11BE. Per consentire alle app di utilizzare questa API, non è necessario che il dispositivo supporti il Wi-Fi 7.

Quando viene chiamata questa API, il modulo Wi-Fi controlla se EHT Capability IE è presente tra i risultati restituiti della ricerca di connettività. Se EHT Capability IE è presente nei risultati della ricerca, l'AP scansionato supporta il Wi-Fi 7. La classe WifiTracker AOSP mostra queste informazioni di supporto nell'interfaccia dell'utente quando viene eseguita in modalità dettagliata.

Modalità di connessione STA

Il framework Android include l'API int WifiInfo#getWifiStandard(), che le app possono chiamare per verificare se la modalità di connessione della stazione (STA) corrente è Wi-Fi 7. La modalità di connessione STA è Wi-Fi 7 quando sia il dispositivo sia l'AP connesso supportano il Wi-Fi 7. Se la modalità di connessione è Wi-Fi 7, l'API restituisce ScanResults.WIFI_STANDARD_11BE.

Quando viene chiamato getWifiStandard, il modulo Wi-Fi determina la modalità chiamando l'API HAL ISupplicantStaIface#getConnectionCapabilities(). L'implementazione di questa API HAL nel livello AIDL wpa_supplicant controlla se EHT Capability IE è presente sia in AssocReq sia in AssocRsp durante la configurazione della connessione.

Selezione rete

In Android 13, la selezione della rete utilizza diversi parametri per determinare a quale AP connettersi. Uno dei parametri è la velocità effettiva stimata dell'AP, che viene stimata utilizzando il blocco ThroughputPredictor. Il blocco ThroughputPredictor utilizza i parametri PHY sia del dispositivo sia dell'AP scansionato.

In Android 13, ThroughputPredictor utilizza le seguenti funzionalità AP nel calcolo:

  • Supporto del Wi-Fi 7 (802.11be)
  • Supporto della larghezza del canale di 320 MHz

L'inclusione di queste funzionalità nella logica ThroughputPredictor aumenta le probabilità di selezionare AP compatibili con il Wi-Fi 7 quando il dispositivo può utilizzare queste funzionalità.

Rilevamento della distanza basato su RTT Wi-Fi

Android fornisce il supporto dell'API per il preambulo EHT e la larghezza del canale di 320 MHz per RTT Wi-Fi. In questo modo, è possibile supportare le funzionalità correlate al Wi-Fi 7 nella misurazione del tempo di transito RTT ogni volta che è supportata dal chip.

API HAL

Le seguenti API HAL supportano le funzionalità Wi-Fi 7 per la misurazione della distanza basata su RTT:

API

Le app possono utilizzare le seguenti API per la misurazione della distanza basata su RTT di Wi-Fi 7:

Soft AP

Android supporta il Wi-Fi 7 in Soft AP e offre le seguenti funzionalità.

Avvia il soft AP

Android supporta l'avvio dell'hotspot soft in modalità Wi-Fi 7. Questo aspetto è regolato dalla configurazione dell'overlay config_wifiSoftapIeee80211beSupported.

Il modulo Wi-Fi utilizza l'overlay config_wifiSoftapIeee80211beSupported per impostare il valore booleano HwModeParams#enable80211BE nella chiamata dell'API IHostApd#addAccessPoint(). Nel livello AIDL di hostapd, questo valore viene utilizzato per impostare i parametri hostapd.conf.

API HAL

Il valore booleano enable80211BE in HwModeParams nell'HAL hostapd supporta l'avvio dell'AP soft in modalità Wi-Fi 7.

Segnalare informazioni sull'hotspot soft

Android include il supporto dell'API per includere le informazioni su Wi-Fi 7 e sulla larghezza del canale di 320 MHz nelle informazioni sull'AP soft registrate.

API HAL

La costante WIFI_STANDARD_11BE nell'interfaccia AIDL Generation.aidl dell'HAL hostapd, utilizzata nel ApInfo riportato nel callback IHostapdCallback#onApInstanceInfoChanged(), supporta la generazione di report sulle informazioni del soft AP.

API

Le app possono utilizzare i seguenti metodi (API di sistema) in SoftApInfo per segnalare le informazioni relative all'hotspot soft.

Funzionalità MLO Wi-Fi 7

Il funzionamento multilink (MLO) è la funzionalità principale della specifica Wi-Fi 7 (802.11be). MLO è una funzionalità obbligatoria per i dispositivi multilink (MLD) che funzionano in Wi-Fi 7, in modo simultaneo o meno.

Diagramma MLO

Figura 1. Diagramma MLO.

Come mostrato nella Figura 1, sia AP-MLD che STA-MLD hanno più istanze AP o STA in esecuzione su ogni link. Ogni link ha un indirizzo MAC AP o STA separato. L'AP o lo STA ha anche un indirizzo MAC MLD per identificare il dispositivo.

La classe android.net.wifi.MloLink rappresenta il link MLO. Questa classe include i seguenti parametri:

  • int getLinkId(): ID link pubblicizzato dall'AMLD del profilo alternativo.
  • MacAddress getApMacAddress(): indirizzo MAC dell'AP. L'BSSID dell'istanza AP per il link.
  • MacAddress getStaMacAddress(): indirizzo MAC della stazione di base. L'indirizzo MAC assegnato localmente per l'istanza STA sul link.
  • int getChannel(): Collega il canale. Il numero del canale del link.
  • int getBand(): Collega il cinturino. La maglia del link.

  • int getState(): stato del link. Può essere uno dei seguenti stati:

    • MLO_LINK_STATE_INVALID: non valido. Utilizzato per l'inizializzazione e i casi di errore.
    • MLO_LINK_STATE_UNASSOCIATED: Non associato. Il link non è associato a un AP.
    • MLO_LINK_STATE_IDLE: inattivo. Il collegamento è associato, ma non attivo (non è associato al collegamento alcun identificatore di traffico (TID)).
    • MLO_LINK_STATE_ACTIVE: attivo. Il collegamento è associato e attivo (almeno un TID è mappato al collegamento). Un link attivo può essere in modalità di risparmio energetico perché il framework non monitora lo stato di alimentazione del link.

Informazioni sull'MLO dell'AP Wi-Fi 7 scansionato

Le app possono ottenere i parametri MLO per un AP MLD Wi-Fi 7 quando il modulo Wi-Fi riceve un oggetto ScanResult dall'AP-MLD. AOSP WifiTracker mostra i parametri MLO quando viene eseguito in modalità dettagliata.

Il modulo Wi-Fi raccoglie le informazioni MLO nel seguente modo:

  • Analizza l'elemento di informazioni su più link (IE) incluso nella risposta del beacon o del probe per leggere l'indirizzo MAC MLD dell'AP e l'ID link corrente.
  • Analizza l'IE RNR (report sui vicini ridotti) incluso nella risposta del beacon o della sonda per leggere l'elenco delle informazioni sui link affiliati.

API

Per ottenere le informazioni scansionate dell'MLO AP, le app possono utilizzare le seguenti API:

Informazioni sull'MLO dell'AP Wi-Fi 7 connesso

Quando un dispositivo si connette a un AP-MLD Wi-Fi 7, il framework raccoglie i parametri MLO della connessione dall'oggetto WifiInfo. L'oggetto AOSP WifiTracker mostra queste informazioni quando viene eseguito in modalità dettagliata.

Quando il dispositivo si connette all'AP-MLD, il modulo Wi-Fi copia le informazioni MLO dall'oggetto ScanResult ricevuto dall'AP. Il modulo chiama quindi l'ISupplicantStaIface#getConnectionMloLinksInfo()API HAL per leggere gli indirizzi MAC di ogni link sia per l'AP sia per lo STA e per aggiornare lo stato dei link associati.

API

Per ottenere le informazioni di connessione dell'MLO, le app possono utilizzare le seguenti API:

Scansione AP-MLD

Il software del fornitore fornisce al framework Wi-Fi i risultati della scansione per ogni risposta del beacon o della sonda che riceve. Ciò significa che il framework Wi-Fi:

  • Potrebbe ricevere più oggetti ScanResults dallo stesso AP-MLD (poiché l'AP può avere più link di beaconing).
  • Potrebbe ricevere solo un insieme parziale dei risultati della ricerca per i link AP di un AP-MLD perché alcuni di questi indicatori di collegamento potrebbero non essere ricevuti dal firmware.

Il software del fornitore segnala solo i risultati della scansione ricevuti via etere e non deve creare (sintesi artificiale) i risultati della scansione in base ai link pubblicizzati dall'AP-MLD.

Il software del fornitore deve includere gli IEI di RNR e multilink della variante di base ricevuti dalle istanze AP nei risultati della scansione segnalati. Se i dettagli dell'AP affiliato mancano nei risultati della scansione, il software del fornitore può inviare richieste di probe multilink (frame di richiesta di probe che include un elemento di richiesta di probe multilink) per includere l'insieme completo o parziale di funzionalità, parametri ed elementi di funzionamento dell'AP con l'AP-MLD target nel frame di risposta.

Se necessario, il software del fornitore può attivare il monitoraggio ML (utilizzando la variante ML IE della richiesta di ispezione nel frame della richiesta di ispezione).

Associazione di rete AP-MLD

Quando un dispositivo si connette a una rete AP-MLD, il software del fornitore utilizza il link AP selezionato (link associato) per l'indicatore. Il software del fornitore può essere associato a tutti o ad alcuni dei link supportati dal dispositivo.

Al termine dell'associazione, il driver segnalaISupplicantStaIfaceCallback#onStateChanged() con il BSSID di un link per AP-MLD. Il driver seleziona quindi un link dell'AP-MLD, a condizione che i risultati della scansione siano stati segnalati al framework per quel link.

Punteggio della rete

Per i dispositivi con Android 14 o versioni successive, la selezione della rete Wi-Fi di Android supporta MLO Wi-Fi 7. Ciò significa che Android seleziona la migliore rete Wi-Fi per il dispositivo in base al numero di link disponibili per MLO.

Per supportare MLO, l'algoritmo di selezione della rete utilizza le seguenti funzionalità MLO del chip Wi-Fi:

  • Numero massimo di link STR
  • Numero massimo di link di associazione
  • Combinazioni di bande simultanee

Selezione della rete MLO Wi-Fi

Figura 2. Selezione della rete MLO.

La trasmissione e la ricezione simultanee (STR) sono uno schema di contesa del mezzo Wi-Fi per il funzionamento su più link. L'isolamento del segnale tra i diversi link è sufficiente perché i link possano funzionare in modo indipendente e siano in grado di trasmettere e ricevere contemporaneamente in link diversi. L'STR è diverso dagli STA legacy con un solo link (SL) e dagli STA legacy dual band dual concurrent (DBDC). Gli STA affiliati a un MLD STA condividono un numero di sequenza del trasmettitore (SN) e uno spazio comuni per la trasmissione di dati allocati a diversi link se la trasmissione di più link ha la stessa categoria di accesso (AC).

Il numero massimo di link STR utilizzati può essere diverso dal numero massimo di radio supportate dal chip. Nell'esempio della Figura 2, il numero massimo di link STR è 2.

Le seguenti interfacce HAL AIDL supportano il numero massimo di link STR e il numero massimo di funzionalità di conteggio dei link di associazione:

Più link possono operare su una singola radio utilizzando lo schema di contesa Enhanced Multi-Link Single Radio (eMLSR). Un dispositivo multilink utilizza eMLSR su un insieme di link se può ricevere determinati frame di controllo di base ed eseguire contemporaneamente la valutazione del canale libero (CCA) sull'insieme di link. Tuttavia, l'MLD trasmette o riceve dati su un solo link (il link scelto dinamicamente in ogni opportunità di trasmissione (TXOP)) alla volta.

Una stazione MLD può massimizzare il numero di link di associazione per una maggiore affidabilità, un maggiore throughput e una latenza inferiore (rispetto a una stazione legacy con un solo link) operando contemporaneamente in STR ed eMLSR, se supportato dal chip. Nella Figura 2, il numero massimo di link di associazione è 3.

Le seguenti interfacce HAL AIDL supportano la funzionalità di conteggio massimo dei link di associazione:

Combinazioni di bande simultanee

Il framework esegue query sul chip per ottenere le combinazioni radio consentite (tramite l'interfaccia IWifiChip.aidl AIDL) che possono funzionare contemporaneamente. Da queste informazioni, il framework ricava le possibili combinazioni di bande simultanee. Di seguito è riportato un esempio di combinazioni di bande simultanee (GHz):

  • 2.4
  • 5
  • 6
  • 2,4 x 5
  • 2,4 x 6
  • 5 x 6

La seguente interfaccia HAL AIDL supporta combinazioni di radio simultanee:

Selezione rete

Durante la selezione della rete (MLO), l'elenco dei candidati viene raggruppato in base ai membri con lo stesso indirizzo MAC MLD. Il punteggio di velocità in multilink massima prevista viene calcolato per ogni gruppo in base al numero massimo di link STR e alle combinazioni di bande simultanee supportate dal chip. Se il candidato è compatibile con il multi-link e il chip supporta STR, il punteggio di throughput previsto viene sostituito con il punteggio di throughput previsto per il multi-link. Ciò dà un vantaggio ai candidati MLO durante la selezione della rete.

Quando si connette a una rete AP-MLD, il framework esegue la selezione dell'SSID in base alle informazioni ricevute nell'oggetto ScanResults, come indicato dal software del fornitore. Dopo la selezione dell'SSID da parte del framework, il software del fornitore è responsabile della selezione del BSSID per l'AP (o il link AP) migliore da utilizzare per l'associazione.

Gestione dell'indirizzo MAC STA del dispositivo

Questa sezione descrive come vengono gestiti gli indirizzi MAC STA del dispositivo (indirizzi MAC MLD e indirizzi MAC STA per link).

Indirizzo MAC MLD

Il framework Wi-Fi gestisce l'indirizzo MAC MLD del dispositivo. L'indirizzo MAC del Media Library Device viene gestito nello stesso modo in cui un dispositivo non Media Library Device gestisce il proprio indirizzo MAC. L'indirizzo MAC può essere un indirizzo MAC casuale o un indirizzo MAC provisioning hardware in base alla scelta dell'utente. L'indirizzo MAC MLD viene impostato dal framework utilizzando l'IWifiStaIface#setMacAddress()API HAL.

Il software del fornitore gestisce gli indirizzi MAC STA dell'istanza (per ogni link). Quando un dispositivo si associa a un AP, il software del fornitore assegna un indirizzo MAC dell'istanza per ogni collegamento associato.

Il software del fornitore assegna indirizzi MAC per link in base al proprio algoritmo. L'algoritmo deve essere ripetibile ed essere una funzione di quanto segue:

  • Indirizzo MAC STA-MLD impostato dal framework Wi-Fi.
  • ID collegamento (ricevuto dall'AP)

Ciò significa che se il framework riutilizza lo stesso indirizzo MAC MLD, il fornitore deve riutilizzare gli stessi indirizzi MAC per istanza associati e viceversa. In questo modo, si garantisce che, quando l'indirizzo STA-MLD generato dal framework è permanente per un SSID, lo siano anche gli indirizzi MAC per STA.

Di seguito è riportato un esempio di algoritmo per l'assegnazione dell'indirizzo MAC STA per link (i fornitori possono implementare qualsiasi algoritmo che soddisfi i criteri dell'algoritmo):

  • Ottetto 0: assicurati che il bit di amministrazione locale sia impostato
  • Ottetti 1-4: come l'indirizzo MAC STA-MLD
  • Ottetto 5: Per-STA = (STA-MLD + ID link + 1) MOD (256)

Il firmware del fornitore può eseguire il passaggio da un link all'altro e gestire lo stato di risparmio energetico delle maglie per l'attivazione o la disattivazione senza input dal framework Wi-Fi.

Il framework Wi-Fi non si aspetta una notifica quando lo stato del link viene modificato.

Gestione dello stato di risparmio energetico

Lo stato di risparmio energetico è attivo per impostazione predefinita nel framework Wi-Fi. In stato di risparmio energetico, il firmware del fornitore gestisce lo stato di risparmio energetico dei singoli link in base ai pattern di traffico e alle decisioni di attivazione o disattivazione dei link.

Tuttavia, il framework Wi-Fi può forzare la disattivazione dello stato di risparmio energetico chiamando l'ISupplicantStaIface::setPowerSave(false)API HAL. Se lo stato di risparmio energetico è disattivato dal framework, il firmware del fornitore deve mantenere attivo almeno un collegamento (risparmio energetico disattivato). In questo stato, l'implementazione del firmware decide quale link viene impostato.

Percorso dei dati

Questa sezione descrive l'implementazione del firmware del fornitore per la gestione del traffico in uplink e in download.

Il firmware instrada il traffico in uplink a uno (o più) link in base alla sua implementazione interna. Il firmware del fornitore decide quando eseguire il bilanciamento del carico, la duplicazione o l'aggregazione del traffico in base ai relativi modelli. Consigliamo di duplicare il traffico del firmware su più link nei seguenti casi:

  • Quando la modalità a bassa latenza è impostata tramite l'IWifiChip#setLatencyMode() API HAL.
  • Quando è presente traffico con priorità utente 6 e 7.

Il firmware deve sostituire l'indirizzo MAC per STA (destinazione) dell'intestazione MAC con l'indirizzo MAC MLD-STA e l'indirizzo MAC per AP (origine) dell'intestazione MAC con l'indirizzo MAC MLD-AP. Il firmware deve eseguire questa sostituzione dell'indirizzo MAC prima di passare attraverso il filtro APF perché i comandi del filtro APF hanno filtri basati sugli indirizzi MAC MLD. Esiste un singolo filtro APF per tutti i link di un AP-MLD.

Concorrenza

Gli scenari di concorrenza, in cui una radio viene utilizzata per una nuova interfaccia, devono avere la priorità rispetto alla dedica di più radio per i link della stessa interfaccia. Gli scenari di concorrenza devono avere la priorità anche sull'MLO, indipendentemente da quale sia stato creato per primo. L'utilizzo di più link per una singola interfaccia è opportunistico, il che significa che più link vengono utilizzati solo quando:

  • L'MLO è obbligatorio in base alla decisione del firmware per il bilanciamento del carico, l'aggregazione o la duplicazione.
  • MLO è disponibile, il che significa che una radio non è richiesta da un'altra interfaccia.

Per i dispositivi con Android 14 o versioni successive, quando l'AP Wi-Fi 7 annuncia la disattivazione temporanea di uno dei link tramite un elemento di mappatura TID-to-link trasmesso nei frame beacon, di risposta alla sonda e di risposta all'associazione, la stazione Wi-Fi 7 continua la connessione con l'AP utilizzando i link rimanenti configurati, senza eseguire un'altra associazione.

Per i dispositivi con Android 13 o versioni precedenti, il framework Wi-Fi non supporta la ricezione di notifiche quando lo stato del collegamento cambia a causa della mappatura TID-to-link, anche se il collegamento associato non è collegato a un TID.

Il supplicant Wi-Fi notifica al framework Wi-Fi le modifiche alla mappatura TID-to-link tramite le seguenti interfacce AIDL:

Le app possono ottenere informazioni sulle modifiche alla mappatura TID-to-link utilizzando le seguenti API:

Per i dispositivi con Android 14 o versioni successive, sono disponibili le seguenti API per ottenere le funzionalità di negoziazione della mappa TID-to-link per la stazione e l'AP.

Capacità del chip

Le seguenti interfacce supportano la funzionalità del chip per la negoziazione del mapping TID-to-link.

AIDL HAL

L'interfaccia AIDL per la negoziazione della mappatura TID-to-link è in FeatureSetMask in hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. La funzionalità T2LM_NEGOTIATION = 1 << 8 indica che il chip supporta la mappatura TID-to-link. API

Funzionalità AP

Le seguenti interfacce supportano la funzionalità AP per la negoziazione della mappatura TID-to-link.

HAL AIDL

Il framework esegue query sulla funzionalità AP del supplicant insieme alla funzionalità di connessione corrente.

API

Le statistiche del livello di collegamento includono dettagli specifici del collegamento Wi-Fi, come RSSI, vari contatori di pacchetti TX e RX e statistiche radio. Il framework Wi-Fi esegue periodicamente il polling delle statistiche del livello di collegamento e dell'RSSI per selezionare la rete migliore o per valutare la qualità della rete connessa. Per i dispositivi con Android 14 o versioni successive, le statistiche del livello di collegamento includono il supporto del multilink. Per supportare il Wi-Fi 7, Android supporta MLO sia nelle statistiche del livello di collegamento sia nel polling del segnale.

Le statistiche specifiche del link si trovano nelle seguenti interfacce AIDL del livello di collegamento:

L'API di sistema android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() ascolta tutte le statistiche del livello link. Il framework richiama periodicamente questa API per aggiornare le statistiche di usabilità del Wi-Fi.

Nel servizio android.net.wifi.WifiUsabilityStatsEntry sono disponibili le seguenti API specifiche per i link.

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)

Per eseguire query sugli ID link disponibili, le app possono chiamare il metodo android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

Le API in android.net.wifi.WifiUsabilityStatsEntry per un singolo link (non MLO) restituiscono le statistiche aggregate per le connessioni MLO. Di seguito sono riportati i criteri di aggregazione:

  • Le seguenti statistiche aggregate dei pacchetti utilizzano la somma delle statistiche per link:

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

  • Le seguenti statistiche utilizzano i dati del link con l'RSSI più elevato:

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

Per i dispositivi con Android 13, le statistiche del livello di collegamento non tengono conto dell' utilizzo di più link per una singola interfaccia. Per supportare MLO, il software del fornitore deve applicare la seguente logica di aggregazione quando genera report su LinkLayerStats tramite l'API HAL IWifi# getLinkLayerStats_1_6(). Il link migliore è quello con l'RSSI più elevato.

  • StaLinkLayerStats.iface.beaconRx: indica il numero di beacon per il link migliore utilizzato per l'interfaccia.
  • StaLinkLayerStats.iface.avgRssiMgmt: report avgRssiMgmt per il miglior link utilizzato per l'interfaccia.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): genera un report sulle statistiche aggregate dei pacchetti (totali) sui link dell'interfaccia.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): genera un report sulle statistiche relative al tempo di contesa per il link migliore utilizzato sull'interfaccia (statistiche sul tempo di contesa più basso).

Quando uno dei link del punto di accesso Wi-Fi 7 viene riutilizzato, l'AP può annunciare la rimozione del link tramite la riconfigurazione del link MLO. Le stazioni possono supportare una connettività senza interruzioni con l'AP senza una nuova associazione sui link rimanenti.

L'interfaccia AIDL onMloLinksInfoChanged, situata nel supplicant Wi-Fi in ISupplicantStaIfaceCallback.aidl, supporta la ricofigurazione del link (rimozione del link dall'AP).

Quando il framework Wi-Fi elabora la rimozione di un link, lo stato del link viene impostato su MLO_LINK_STATE_UNASSOCIATED. Il framework attiva quindi ConnectivityManager.NetworkCallback#onCapabilitiesChanged() per una modifica dello stato del collegamento.

Il metodo WifiInfo#getAffiliatedMloLinks restituisce i link degli operatori di marketing affiliati. Il metodo MloLink#getState restituisce lo stato del collegamento. Se il link viene rimosso, lo stato del link restituito è MLO_LINK_STATE_UNASSOCIATED.

Strategia MLO per i chip

MLO consente ai dispositivi di inviare e ricevere dati su più link Wi-Fi contemporaneamente, il che può migliorare le prestazioni delle app con requisiti specifici come bassa latenza, larghezza di banda elevata e basso consumo energetico. I fornitori di chip possono sviluppare algoritmi su come utilizzare i link disponibili.

Le app con privilegi possono modificare questi algoritmi utilizzando il metodo setMloMode in Wifimanager e impostare le seguenti modalità:

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

Il framework utilizza setMloMode nell'interfaccia AIDL di IWifiChip per impostare la modalità MLO.