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à Wi-Fi 7 di Android, incluse le operazioni di base e multi-link (MLO).

Funzionalità Wi-Fi 7 di base

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

Supporto Wi-Fi 7 del dispositivo

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 Wi-Fi 7.

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

  • Se l'overlay è impostato su true , si presuppone che il dispositivo supporti Wi-Fi 7 indipendentemente dalla risposta di nl80211. Questa sostituzione è utile solo per i produttori di dispositivi che non dispongono di driver che restituiscono il supporto del 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 da wificond, che chiama il comando nl80211 NL80211_CMD_GET_WIPHY . Se nella risposta del driver è presente l'attributo NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY , si presuppone che il dispositivo supporti Wi-Fi 7.

Supporto AP Wi-Fi 7 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 Wi-Fi 7. Se l'AP supporta Wi-FI 7, l'API restituisce ScanResults.WIFI_STANDARD_11BE . Non è necessario che il dispositivo supporti Wi-Fi 7 affinché le app utilizzino questa API.

Quando viene richiamata questa API, il modulo Wi-Fi controlla se EHT Capability IE è presente nei risultati restituiti della scansione della connettività. Se nei risultati della scansione è presente EHT Capability IE , l'AP scansionato supporta Wi-Fi 7. La classe AOSP WifiTracker visualizza queste informazioni di supporto nell'interfaccia 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 corrente (STA) è Wi-Fi 7. La modalità di connessione STA è Wi-Fi 7 quando sia il dispositivo che la connessione L'AP supporta 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 che AssocRsp durante l'impostazione della connessione.

Selezione della rete

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

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

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

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

Portata basata su Wi-Fi RTT

Android fornisce il supporto API per il preambolo EHT e la larghezza del canale di 320 MHz per Wi-Fi RTT . Ciò consente il supporto delle funzionalità relative al Wi-Fi 7 in RTT che vanno ogni volta che è supportato dal chip.

API HAL

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

API

Le app possono utilizzare le seguenti API per la portata basata su Wi-Fi 7 RTT:

AP morbido

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

Avvia Soft AP

Android supporta l'avvio di Soft AP in modalità Wi-Fi 7. Questo è 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 API IHostApd#addAccessPoint() . Nel livello hostapd AIDL, questo valore viene utilizzato per impostare i parametri hostapd.conf .

API HAL

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

Segnala informazioni sul Soft AP

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

API HAL

La costante WIFI_STANDARD_11BE nell'interfaccia AIDL Generation.aidl nell'HAL hostapd, utilizzata ApInfo riportato nel callback IHostapdCallback#onApInstanceInfoChanged() , supporta la segnalazione di informazioni Soft AP.

API

Le app possono utilizzare i seguenti metodi (API di sistema) in SoftApInfo per segnalare informazioni Soft AP.

Funzionalità MLO Wi-Fi 7

Il funzionamento multi-link (MLO) è la caratteristica principale della specifica Wi-Fi 7 (802.11be). MLO è una funzionalità obbligatoria per i dispositivi multi-link (MLD) in esecuzione in Wi-Fi 7, sia contemporaneamente che non contemporaneamente.

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 collegamento ha un indirizzo MAC AP o STA separato. L'AP o la STA hanno anche un indirizzo MAC MLD per identificare il dispositivo.

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

  • int getLinkId() : ID collegamento pubblicizzato dall'AP MLD.
  • MacAddress getApMacAddress() : indirizzo MAC dell'AP. Il BSSID dell'istanza AP per quel collegamento.
  • MacAddress getStaMacAddress() : indirizzo MAC STA. L'indirizzo MAC assegnato localmente per l'istanza STA sul collegamento.
  • int getChannel() : collega il canale. Il numero del canale del collegamento.
  • int getBand() : collega la banda. La fascia del collegamento.

  • 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 collegamento non è associato a un AP.
    • MLO_LINK_STATE_IDLE : inattivo. Il collegamento è associato ma non attivo (nessun identificatore di traffico (TID) è mappato sul collegamento).
    • MLO_LINK_STATE_ACTIVE : attivo. Il collegamento è associato e attivo (almeno un TID è mappato sul collegamento). Un collegamento attivo può essere in modalità di risparmio energetico perché il framework non monitora lo stato di alimentazione del collegamento.

Informazioni MLO Wi-Fi 7 AP scansionate

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 visualizza i parametri MLO durante l'esecuzione in modalità dettagliata.

Il modulo Wi-Fi raccoglie le informazioni MLO effettuando le seguenti operazioni:

  • Analizza l'elemento informativo multi-link (IE) incluso nella risposta del beacon o della sonda per leggere l'indirizzo MAC MLD dell'AP e l'ID del collegamento corrente.
  • Analizza il rapporto ridotto dei vicini (RNR) IE incluso nella risposta del beacon o della sonda per leggere l'elenco delle informazioni sui collegamenti affiliati.

API

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

Informazioni MLO 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 visualizza queste informazioni durante l'esecuzione 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 richiama quindi l'API HAL ISupplicantStaIface#getConnectionMloLinksInfo() per leggere gli indirizzi MAC di ciascun collegamento 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 beacon o sonda che riceve. Ciò significa che la struttura Wi-Fi:

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

Il software del fornitore riporta solo i risultati della scansione ricevuti via etere e non deve creare (sintetizzare artificialmente) risultati della scansione basati su collegamenti pubblicizzati dall'AP-MLD.

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

Se necessario, il software del fornitore può attivare il sondaggio ML (utilizzando la variante ML IE della sonda req nel frame sonda req).

Associazione di rete AP-MLD

Quando un dispositivo si unisce a una rete AP-MLD, il software del fornitore utilizza il collegamento AP selezionato (collegamento associato) per la segnalazione. Il software del fornitore può associarsi a tutti o ad alcuni dei collegamenti supportati dal dispositivo.

Una volta effettuata l'associazione con successo, il driver segnala ISupplicantStaIfaceCallback#onStateChanged() con il BSSID di un collegamento per AP-MLD. Il driver seleziona quindi un collegamento dell'AP-MLD a condizione che i risultati della scansione siano stati segnalati al framework per quel collegamento.

Punteggio di rete

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

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

  • Conteggio massimo dei collegamenti STR
  • Conteggio massimo dei collegamenti di associazione
  • Combinazioni di bande simultanee

Selezione della rete Wi-Fi MLO

Figura 2. Selezione della rete MLO.

La trasmissione e ricezione simultanea (STR) è uno schema di contesa media Wi-Fi per il funzionamento multi-link. L'isolamento del segnale tra diversi collegamenti è sufficiente affinché i collegamenti possano funzionare in modo indipendente e siano in grado di trasmettere e ricevere simultaneamente in collegamenti diversi. STR è diverso dalla STA legacy single link (SL) e dalla STA legacy dual band dual concurrent (DBDC). Le STA affiliate a una STA MLD condividono un numero di sequenza del trasmettitore comune (SN) e uno spazio comune per la trasmissione dei dati assegnato a collegamenti diversi se la trasmissione di più collegamenti ha la stessa categoria di accesso (AC).

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

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

Collegamenti multipli possono operare su una singola radio utilizzando lo schema di contesa Enhanced Multi-Link Single Radio (eMLSR). Un dispositivo multi-link utilizza eMLSR su una serie di collegamenti se può ricevere determinati frame di controllo di base ed eseguire simultaneamente la valutazione del canale chiaro (CCA) sulla serie di collegamenti. Tuttavia, l'MLD trasmette o riceve dati su un solo collegamento (il collegamento scelto dinamicamente in ciascun periodo di opportunità di trasmissione (TXOP)) alla volta.

Una stazione MLD può massimizzare il numero di collegamenti di associazione per una migliore affidabilità, migliore produttività e minore latenza (rispetto a una stazione legacy a collegamento singolo) operando contemporaneamente in STR ed eMLSR se supportato dal chip. Nella Figura 2, il numero massimo di collegamenti di associazione è 3.

Le seguenti interfacce HAL AIDL supportano la capacità massima di conteggio dei collegamenti di associazione:

Combinazioni di bande simultanee

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

  • 2.4
  • 5
  • 6
  • 2,4×5
  • 2,4×6
  • 5×6

La seguente interfaccia AIDL HAL supporta combinazioni radio simultanee:

Selezione della rete

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

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

Gestione dell'indirizzo MAC del dispositivo STA

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

Indirizzo MAC dell'MLD

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

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

Il software del fornitore assegna gli indirizzi MAC per collegamento in base al suo 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 associati per istanza e viceversa. Ciò garantisce che quando l'indirizzo STA-MLD generato dal framework è persistente per un SSID, anche gli indirizzi MAC per-STA sono persistenti.

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

  • Ottetto 0: assicurarsi che il bit amministrato localmente sia impostato
  • Ottetto 1-4: uguale all'indirizzo MAC STA-MLD
  • Ottetto 5: Per-STA = (STA-MLD + ID collegamento + 1) MOD (256)

Il firmware del fornitore può eseguire la commutazione dei collegamenti 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 è abilitato per impostazione predefinita sul framework Wi-Fi. Nello stato di risparmio energetico, il firmware del fornitore gestisce lo stato di risparmio energetico dei singoli collegamenti in base ai modelli di traffico e alle decisioni di attivazione o disattivazione dei collegamenti.

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

Percorso dati

Descrive l'implementazione del firmware del fornitore per la gestione del traffico di uplink e download.

Il firmware instrada il traffico uplink a uno (o più) collegamenti 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 modelli di traffico. Consigliamo al firmware di duplicare il traffico su più collegamenti nei seguenti casi:

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

Il firmware deve sostituire l'indirizzo MAC per-STA (di destinazione) dell'intestazione MAC con il 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 poiché i comandi del filtro APF dispongono di filtri basati sugli indirizzi MAC MLD. Esiste un unico filtro APF per tutti i collegamenti 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 dedicazione di più radio per i collegamenti della stessa interfaccia. Anche gli scenari di concorrenza devono avere la priorità sull’MLO, indipendentemente da quale si sia verificato per primo. L'utilizzo di più collegamenti per una singola interfaccia è opportunistico, nel senso che più collegamenti vengono utilizzati solo quando:

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

Per i dispositivi con Android 14 o versioni successive, quando l'AP Wi-Fi 7 annuncia una disattivazione temporanea di uno dei collegamenti tramite un elemento di mappatura TID-to-link trasmesso in beacon, risposta sonda e frame di risposta di associazione, il Wi-Fi 7 la stazione continua la connessione con l'AP utilizzando i rimanenti collegamenti impostati, 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 viene modificato a causa della mappatura da TID a collegamento, anche se il collegamento associato non è collegato a un TID.

Il richiedente Wi-Fi notifica al framework Wi-Fi le modifiche alla mappatura da TID a collegamento attraverso le seguenti interfacce AIDL:

Le app possono ottenere informazioni sulle modifiche alla mappatura da TID a collegamento 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 della mappatura da TID a collegamento.

AIDL HAL

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

Funzionalità AP

Le seguenti interfacce supportano la funzionalità AP per la negoziazione della mappatura da TID a collegamento.

AIDL HAL

Il framework interroga la capacità AP del richiedente insieme alla capacità 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 multi-link. Per supportare Wi-Fi 7, Android supporta MLO sia nelle statistiche del livello di collegamento che nel polling del segnale.

Le statistiche specifiche del collegamento 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 di collegamento. Il framework richiama periodicamente questa API per aggiornare le statistiche sull'usabilità Wi-Fi.

Le seguenti API specifiche del collegamento sono disponibili in 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)

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

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

  • Le seguenti statistiche sui pacchetti aggregati 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 collegamento con l'RSSI più alto:

    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ù collegamenti per una singola interfaccia. Per supportare MLO, il software del fornitore deve applicare la seguente logica di aggregazione quando segnala LinkLayerStats tramite l'API HAL IWifi# getLinkLayerStats_1_6() . Il collegamento migliore è il collegamento con l'RSSI più alto.

  • StaLinkLayerStats.iface.beaconRx : riporta il conteggio dei beacon per il miglior collegamento utilizzato per l'interfaccia.
  • StaLinkLayerStats.iface.avgRssiMgmt : segnala avgRssiMgmt per il miglior collegamento utilizzato per l'interfaccia.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): riporta le statistiche dei pacchetti aggregati (totali) sui collegamenti dell'interfaccia.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): segnala le statistiche sul tempo di conflitto per il miglior collegamento utilizzato sull'interfaccia (statistiche sul tempo di conflitto più basso).

Quando uno dei collegamenti del punto di accesso Wi-Fi 7 viene riproposto, l'AP può annunciare la rimozione del collegamento tramite la riconfigurazione del collegamento MLO. Le stazioni possono sostenere una connettività continua con l'AP senza riassociazione sui collegamenti rimanenti.

L'interfaccia AIDL onMloLinksInfoChanged , situata nel richiedente Wi-Fi su ISupplicantStaIfaceCallback.aidl , supporta la riconfigurazione del collegamento (rimozione AP del collegamento).

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

Il metodo WifiInfo#getAffiliatedMloLinks restituisce i collegamenti MLO 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 Chip MLO

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

Le app privilegiate 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 IWifiChip AIDL per impostare la modalità MLO.