Wi-Fi RTT (IEEE 802.11mc、IEEE 802.11az)

Android 9 的 Wi-Fi 往返時間 (RTT) 功能可讓支援的裝置測量與其他支援裝置的距離,無論這些裝置是存取點 (AP) 或 Wi-Fi Aware 對等裝置 (如果裝置支援 Wi-Fi Aware)。這項功能以 IEEE 802.11mc 和 IEEE 802.11az 通訊協定為基礎 (適用於 Android 15 以上版本),可讓應用程式使用更精確的位置資訊和感知功能。

範例和來源

如要使用這項功能,請實作供應商 HAL 介面。在 Android 14 以上版本中,供應商 HAL 介面是使用 AIDL 定義。在 Android 13 以下版本中,供應商 HAL 介面是使用 HIDL 定義。在 Android 8.0 中,HIDL 取代了先前的硬體抽象層 (HAL) 結構,可指定收集到介面和封裝中的型別和方法呼叫,簡化實作程序。

按照 Wi-Fi 介面操作,即可使用 Wi-Fi RTT 功能。視實作的介面而定,這可以是:

  • AIDL:hardware/interfaces/wifi/aidl
  • HIDL:hardware/interfaces/wifi/1.0 以上版本。

您可以參閱舊版 Wi-Fi HAL,瞭解其與 AIDL 和 HIDL 介面的關聯:hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h

實作

如要實作 Wi-Fi RTT,您必須提供架構和 HAL/韌體支援:

  • 架構:

    • Android 開放原始碼計畫程式碼
    • 啟用 Wi-Fi RTT:需要功能旗標
  • Wi-Fi RTT (IEEE 802.11mc 或 IEEE 802.11az) HAL 支援 (這表示韌體支援)

如要實作這項功能,請實作 Wi-Fi AIDL 或 HIDL 介面,並啟用功能旗標:

  • device/<oem>/<device> 中的 device.mk 內,修改 PRODUCT_COPY_FILES 環境變數,加入 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
    

否則,AOSP 會包含這項功能所需的一切項目。

MAC 隨機化

為提升隱私權,Wi-Fi RTT 交易期間使用的 MAC 位址必須隨機產生,也就是說,不得與 Wi-Fi 介面的內建 MAC 位址相符。不過,如果裝置與 AP 建立關聯,則例外情況是,裝置可能會使用與該 AP 或其他 AP 進行任何 RTT 交易時的關聯 MAC 位址。

驗證

這項功能有 Android Compatibility Test Suite (CTS) 測試。CTS 會偵測功能是否已啟用,並自動納入相關測試。您也可以使用供應商測試套件 (VTS) 測試這項功能。

單元測試

使用下列指令執行 Wi-Fi RTT 套件測試:

服務測試:

atest com.android.server.wifi.rtt

管理員測試:

atest android.net.wifi.rtt

CTS

這項功能有 Android Compatibility Test Suite (CTS) 測試。CTS 會偵測功能是否已啟用,並自動納入相關測試。支援 Wi-Fi RTT (IEEE 802.11mc) 的存取點必須在受測裝置的範圍內。

您可以使用下列方式觸發 CTS 測試:

atest WifiRttTest

校正

如要讓 Wi-Fi RTT 正常運作,802.11mc 或 802.11az 協定傳回的範圍應符合本節所述的主要成效指標 (KPI)。

對於 11mc 協定,在列出的頻寬 (80 MHz、40 MHz、20 MHz) 和 8 的叢發大小下,範圍估計的 KPI 預期會在第 90 個百分位數的誤差達到下列準確度。

  • 80 MHz:2 公尺
  • 40 MHz:4 公尺
  • 20 MHz:8 公尺

對於 11az 協定,天線 MIMO 設定和長訓練欄位 (LTF) 重複次數會影響準確度。以一般手機 (使用 2 根天線) 和存取點 (4 根天線) 來說,系統的 MIMO 設定為 2x4。對於使用 LTF 重複因數為 2 的這類設定,以及所列頻寬 (160 MHz、80 MHz、40 MHz、20 MHz),範圍估計的 KPI 預期在第 90 個百分位數的誤差下,達到下列準確度。

  • 160 MHz:0.5 公尺
  • 80 MHz:1 公尺
  • 40 MHz:2 公尺
  • 20 MHz:4 公尺

如要確認功能實作是否正常運作,請務必進行校正測試。

方法是比較基準真相範圍與 RTT 估計範圍,並增加距離。如要進行基本一致性測試,建議您使用已知已校正 RTT 的裝置驗證解決方案。建議在下列情況下測試範圍校正:

  1. 大型開放式實驗室,或金屬物體不多的走廊,這類環境可能會導致多重路徑異常頻繁發生。
  2. 至少一條視線 (LOS) 軌跡或路徑,長度至少 25 公尺。
  3. 從賽道一端到另一端,每隔 0.5 公尺的標記。
  4. 在距離地面 20 公分的軌道一端,固定一個可支援 RTT 的存取點;在軌道上安裝可移動的支架,用來放置 Android 手機 (或其他受測的 Android 行動裝置),並對齊距離地面 20 公分的 0.5 公尺標記。

  5. 建議您在每個標記處記錄 50 個測距結果,以及與存取點的距離。應針對每個標記位置計算統計資料,例如範圍平均值和變異數。

根據步驟 5 的結果,可以繪製基準真相 (X 軸) 對預估範圍 (Y 軸) 的圖表,並估計最合適的回歸線。理想的裝置校準結果是斜率為 1.0 的線,且 y 軸上的偏移量為 0.0 公尺。如果偏差值在相應頻寬的 KPI 範圍內,則可接受。如果結果超出 KPI 範圍,建議重新校正裝置功能,讓結果符合 KPI 規格。