Wi-Fi RTT (IEEE 802.11mc)

La funzione Wi-Fi Round Trip Time (RTT) in Android 9 consente ai dispositivi di supporto di misurare una distanza da altri dispositivi di supporto: siano essi punti di accesso (AP) o peer Wi-Fi Aware (se Wi-Fi Aware è supportato sul dispositivo). Questa funzione, basata sul protocollo IEEE 802.11mc, consente alle app di utilizzare una maggiore precisione e consapevolezza della posizione.

Esempi e fonte

Per utilizzare questa funzione, implementa il Wi-Fi Hardware Interface Design Language (HIDL) fornito nell'Android Open Source Project (AOSP). In Android 8.0, HIDL sostituisce la precedente struttura HAL (Hardware Abstraction Layer) utilizzata per semplificare le implementazioni specificando tipi e chiamate di metodo raccolte in interfacce e pacchetti.

Segui il Wi-Fi HIDL per utilizzare la funzione Wi-Fi RTT: hardware/interfaces/wifi/1.0 o successivo.

Puoi fare riferimento all'HAL Wi-Fi legacy per vedere come si correla con la nuova interfaccia HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

Implementazione

Per implementare Wi-Fi RTT, è necessario fornire sia il framework che il supporto HAL/firmware:

• Struttura:

  • codice AOSP
  • Abilita Wi-Fi RTT: richiede un flag di funzionalità

• Supporto HAL Wi-Fi RTT (IEEE 802.11mc) (che implica il supporto del firmware)

Per implementare questa funzione, implementa il Wi-Fi HIDL e abilita il flag della funzione:

• In device.mk situato in device/<oem>/<device> , modifica la variabile di ambiente PRODUCT_COPY_FILES per includere il supporto per la funzionalità Wi-Fi RTT:

  PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.rtt.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.rtt.xml
  

In caso contrario, tutto ciò che è necessario per questa funzionalità è incluso in AOSP.

Randomizzazione MAC

Per migliorare la privacy, l'indirizzo MAC utilizzato durante le transazioni Wi-Fi RTT deve essere casuale, ovvero non deve corrispondere all'indirizzo MAC nativo dell'interfaccia Wi-Fi. Tuttavia, in via eccezionale, quando un dispositivo è associato a un AP, può utilizzare l'indirizzo MAC a cui è associato per qualsiasi transazione RTT con quell'AP o con altri AP.

Convalida

Esistono test Android Compatibility Test Suite (CTS) per questa funzione. CTS rileva quando la funzione è abilitata e include automaticamente i test associati. Questa funzione può anche essere testata utilizzando Vendor Test Suite (VTS) e acts/sl4a , una suite di test che conduce test di integrazione approfonditi.

Test unitari

I test del pacchetto Wi-Fi RTT vengono eseguiti utilizzando:

Test di servizio:

atest com.android.server.wifi.rtt

Test manager:

atest android.net.wifi.rtt

Test di integrazione (ACTS).

La suite di test acts/sl4a, descritta in /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md , fornisce test funzionali, prestazionali e di stress.

CTS

Esistono test Android Compatibility Test Suite (CTS) per questa funzione. CTS rileva quando la funzione è abilitata e include automaticamente i test associati. Un punto di accesso che supporti Wi-Fi RTT (IEEE 802.11mc) deve trovarsi nel raggio del dispositivo sottoposto a test.

I test CTS possono essere attivati ​​utilizzando:

atest WifiRttTest

Calibrazione

Affinché Wi-Fi RTT funzioni bene, gli intervalli restituiti nel protocollo 802.11mc sono idealmente accurati all'interno del Key Performance Indicator (KPI). Per l'errore CDF del 90%, alle larghezze di banda elencate, si prevede che il KPI consigliato per una stima dell'intervallo abbia le seguenti tolleranze:

• 80 MHz: 2 metri
• 40 MHz: 4 metri
• 20 MHz: 8 metri

Per garantire che l'implementazione della funzione funzioni correttamente, è necessario il test di calibrazione.

Ciò può essere ottenuto confrontando un intervallo di verità al suolo con l'intervallo stimato RTT a distanze crescenti. Per la conformità di base, dovresti convalidare la tua soluzione rispetto a un dispositivo noto per essere calibrato RTT. La calibrazione della portata deve essere testata nelle seguenti condizioni:

1. Un grande laboratorio aperto, o un corridoio che non ha molti oggetti metallici che possono portare a occorrenze insolitamente elevate di percorsi multipli.
2. Almeno una pista/percorso in linea di vista (LOS) che si estende per 25 m.
3. Indicatori con incrementi di 0,5 metri da un'estremità all'altra del binario.
4. Un posto per fissare un punto di accesso compatibile con RTT a un'estremità del binario montato a 20 cm dal pavimento e un supporto mobile per un telefono Android (o altro dispositivo mobile Android in prova) che può essere spostato lungo il binario e allineato con il Indicatori di 0,5 m, anche a 20 cm dal pavimento. Nota: questo compito ripetitivo può essere eseguito da un piccolo robot, ma va bene anche un operatore umano.
5. 50 risultati di intervallo devono essere registrati su ciascun marker, insieme alla distanza dal punto di accesso. Le statistiche, come la media e la varianza dell'intervallo, devono essere calcolate per ciascuna posizione del marker.

Dai risultati nel passaggio 5, è possibile tracciare un grafico per la verità fondamentale (asse x) rispetto all'intervallo stimato (asse y) e stimare una linea di regressione migliore. La calibrazione ideale del dispositivo risulterà in una linea di pendenza 1,0, con offset 0,0 m sull'asse y. Le deviazioni da questi valori sono accettabili se rientrano nel KPI per la larghezza di banda corrispondente. Se i risultati sono al di fuori del KPI, la funzione del dispositivo deve essere ricalibrata per portare i risultati all'interno della specifica KPI.