Wi-Fi RTT（IEEE 802.11mc）

Android 9 では、Wi-Fi ラウンドトリップ時間（RTT）機能により、アクセス ポイント（AP）と Wi-Fi Aware ピア（デバイスが Wi-Fi Aware に対応している場合）のどちらの場合でも、対応デバイスから他の対応デバイスまでの距離を測定できます。この機能は IEEE 802.11mc プロトコルをベースとしており、アプリが使用する位置情報の精度と認知度を向上させます。

例とソース

この機能を使用するには、ベンダー HAL インターフェースを実装します。Android 14 以降では、AIDL を使用してベンダー HAL インターフェースを定義します。Android 13 以前では、HIDL を使用してベンダー HAL インターフェースを定義します。Android 8.0 では、実装の合理化に使用されていた以前の Hardware Abstraction Layer（HAL）構造に代わって HIDL が使用されています。HIDL は、インターフェースとパッケージに収集されるデータの種類とメソッド呼び出しを指定します。

Wi-Fi インターフェースに従って Wi-Fi RTT 機能を使用します。実装するインターフェースに応じて、次のいずれかとなります。

  • AIDL: hardware/interfaces/wifi/aidl
  • HIDL: hardware/interfaces/wifi/1.0 以降

以前の Wi-Fi HAL を参照して、AIDL インターフェースと HIDL インターフェースとの相関関係を確認できます（hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h）。

実装

Wi-Fi RTT を実装するには、フレームワークおよび HAL / ファームウェアについて、次のようにサポートを提供する必要があります。

  • フレームワーク:

    • AOSP コード
    • Wi-Fi RTT を有効にする: 機能フラグが必要です

  • Wi-Fi RTT（IEEE 802.11mc）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） および acts/sl4a（広範な統合テストを行うテストスイート）を使用してテストすることもできます。

単体テスト

Wi-Fi RTT パッケージ テストでは次のテストが実行されます。

サービス テスト:

atest com.android.server.wifi.rtt

マネージャー テスト:

atest android.net.wifi.rtt

統合（ACTS）テスト

/tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md で説明しているように、acts/sl4a テストスイートには機能テスト、パフォーマンス テスト、ストレステストが用意されています。

CTS

Android 互換性テストスイート（Compatibility Test Suite、CTS）のテストは、この機能を対象とします。CTS は機能が有効になったことを検出し、関連するテストを自動的に含めます。Wi-Fi RTT（IEEE 802.11mc）に対応するアクセス ポイントが、テスト対象のデバイスの範囲内に存在する必要があります。

CTS テストは次の方法でトリガーできます。

atest WifiRttTest

調整

Wi-Fi RTT が正常に機能するためには、802.11mc プロトコルで返される距離が重要業績評価指標（KPI）の範囲内であることが理想的です。90% の CDF エラーに関して、以下の帯域幅において距離の推定を行う際に推奨される KPI の許容範囲は次のとおりです。

  • 80MHz: 2 メートル
  • 40 MHz: 4 メートル
  • 20MHz: 8 メートル

機能の実装が正しく動作していることを確認するには、調整テストが必要です。

このテストは、RTT の推定距離に対するグラウンド トゥルースの範囲をより遠くから比較することで調整を行います。基本的な適合性については、RTT キャリブレーション済みのデバイスに対するソリューションを検証する必要があります。距離の調整は、次の条件下でテストする必要があります。

  1. 広々とした大規模な実験室、または通常以上の多重波伝播を発生させる金属物のない廊下。
  2. 25 m 以上の見通しのよいトラックや通路。
  3. トラックの片方の端から他方の端まで 0.5 m 間隔で付けたマーカー。
  4. トラックの片方の端の床上 20cm の高さに取り付けた RTT 対応のアクセス ポイントを設置する場所、およびトラックと 0.5m 間隔のマーカーに沿って床上 20cm で移動可能な Android スマートフォン（またはテスト中の他の Android モバイル デバイス）用の可動マウント。注: このテストで必要となる反復動作は小さなロボットを使用して実行することもできますが、人の手で行うことも可能です。
  5. アクセス ポイントからの距離と、マーカーを付けた 50 か所における測定結果を記録する必要があります。平均距離や分散といった統計値に関しては、マーカーの位置ごとに算出する必要があります。

ステップ 5 の結果から、推定範囲（Y 軸）に対するグラウンド トゥルース（X 軸）と、推定される最適回帰線のグラフを導くことができます。デバイス調整の理想値は、Y 軸のオフセットが 0.0m で、傾きが 1.0 です。この値から逸脱した数値が、対応する帯域幅の KPI 範囲内である場合は許容値と見なされます。結果が KPI 範囲外である場合は、デバイス機能を再調整して、結果が KPI の仕様の範囲内に含まれるようにする必要があります。