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 verifica 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. L'override è utile solo per i produttori di dispositivi che non dispongono di driver che restituiscono il supporto di 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 Wi-Fi 7 AP scansionato

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 tra i 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 verifica 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 usa diversi parametri per stabilire a quale punto di accesso 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 per una larghezza del canale da 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 API per il preambolo EHT e la larghezza del canale a 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, se 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 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 parametro enable80211BE booleano in HwModeParams nell'HAL hostapd supporta l'avvio di Soft AP in modalità Wi-Fi 7.

Segnalare informazioni sull'hotspot soft

Android include il supporto API per includere le informazioni sulla larghezza del canale Wi-Fi 7 e 320 MHz nelle informazioni del soft AP segnalate.

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

L'operazione multi-link (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 ciascun collegamento. Ogni link ha un indirizzo AP o STA MAC 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. Il BSSID dell'istanza AP per quel 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 collegamento. 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 punto di accesso.
    • MLO_LINK_STATE_IDLE: Inattivo. Il collegamento è associato, ma non attivo (nessun identificatore traffico (TID) è mappato al collegamento).
    • 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. L'WifiTracker AOSP mostra i parametri MLO quando viene eseguito in modalità dettagliata.

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

  • Analizza l'elemento informativo multilink (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 quindi chiama l'API HAL ISupplicantStaIface#getConnectionMloLinksInfo() per leggere gli indirizzi MAC di ogni link sia per AP che per STA e per aggiornare lo stato dei collegamenti associati.

API

Per ottenere informazioni sulla connessione 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 dell'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 over-the-air e non deve creare (sintetizzare artificialmente) i risultati della scansione in base ai link pubblicizzati dall'AP-MLD.

Il software del fornitore deve includere nei risultati della scansione segnalati la variante di base multi-link e gli IE RNR ricevuti dalle istanze AP. 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 della richiesta di prova ML IE nel frame della richiesta di prova).

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) è 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 segnali radio supportati 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 possibili combinazioni di bande simultanee. Di seguito è riportato un esempio di elenco di combinazioni di bande simultanee (GHz):

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

La seguente interfaccia AIDL HAL supporta combinazioni radio simultanee:

Selezione rete

Durante la selezione della rete (MLO), l'elenco dei candidati viene raggruppato per membri con lo stesso indirizzo MAC MLD. Il punteggio di velocità in multilink massima previsto 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 supporta la funzionalità multi-link e il chip supporta STR, il punteggio della velocità effettiva previsto viene sostituito con il punteggio relativo alla velocità effettiva predicato con più link. Ciò dà un vantaggio ai candidati MLO durante la selezione della rete.

Quando entra a far parte di una rete AP-MLD, il framework esegue la selezione dell'SSID in base alle informazioni ricevute nell'oggetto ScanResults come riportate 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 MLD viene gestito allo stesso modo in cui un dispositivo non MLD 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'API IWifiStaIface#setMacAddress() 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, viene garantito che, quando l'indirizzo STA-MLD generato dal framework è persistente 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):

  • Ott 0: assicurati che il bit amministrato localmente sia impostato
  • Ottetti 1-4: come l'indirizzo MAC STA-MLD
  • Ott 5: Per-STA = (STA-MLD + ID collegamento + 1) MOD (256)

Il firmware del fornitore può eseguire il cambio di collegamento e gestire lo stato di risparmio energetico dei collegamenti per l'attivazione o la disattivazione senza input dal framework Wi-Fi.

Il framework Wi-Fi non prevede una notifica quando lo stato del collegamento 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'API HAL ISupplicantStaIface::setPowerSave(false). 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 pattern di traffico. Consigliamo di duplicare il traffico del firmware su più link nei seguenti casi:

  • Quando la modalità a bassa latenza è impostata tramite l'API HAL IWifiChip#setLatencyMode().
  • 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. È presente un unico filtro APF per tutti i link di un file 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 il punto di accesso Wi-Fi 7 annuncia una disattivazione temporanea di uno dei link tramite un elemento di mappatura TID-to-link trasmesso nei frame di risposta di beacon, risposta del probe e associazione, la stazione Wi-Fi 7 continua la connessione con il punto di accesso utilizzando i restanti link 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 delle mappe da TID a link per la stazione e l'AP.

Capacità del chip

Le seguenti interfacce supportano la funzionalità dei chip per la negoziazione della mappatura da TID a link.

AIDL HAL

L'interfaccia AIDL per la negoziazione della mappatura da TID a 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.

AIDL HAL

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 collegamento 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 sui pacchetti utilizzano la somma delle statistiche per collegamento:

    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 miglior link 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 collegamenti del punto di accesso Wi-Fi 7 viene riproposto, l'AP può annunciare la rimozione del collegamento mediante la riconfigurazione del collegamento MLO. Le stazioni possono supportare una connettività senza interruzioni con l'AP senza una nuova associazione sui link rimanenti.

L'interfaccia onMloLinksInfoChanged AIDL, situata nel supplicante Wi-Fi all'indirizzo ISupplicantStaIfaceCallback.aidl, supporta la riconfigurazione dei link (rimozione del collegamento tramite AP).

Quando il framework Wi-Fi elabora la rimozione di un link, lo stato del collegamento è 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 collegamento viene rimosso, lo stato del collegamento 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.