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

The Wi-Fi Round Trip Time (RTT) feature in Android 9 enables supporting devices to measure a distance to other supporting devices: whether they are Access Points (APs) or Wi-Fi Aware peers (if Wi-Fi Aware is supported on the device). This feature, built upon the IEEE 802.11mc and IEEE 802.11az protocol (available from Android 15), enables apps to use enhanced location accuracy and awareness.

Examples and source

To use this feature, implement the Vendor HAL interface. In Android 14 and higher, the Vendor HAL interface is defined using AIDL. In Android 13 and lower, the Vendor HAL interface is defined using HIDL. In Android 8.0, HIDL replaced the previous Hardware Abstraction Layer (HAL) structure used to streamline implementations by specifying types and method calls collected into interfaces and packages.

Follow the Wi-Fi interface to employ the Wi-Fi RTT feature. Depending on which interface is implemented, this is:

• AIDL: hardware/interfaces/wifi/aidl
• HIDL: hardware/interfaces/wifi/1.0 or later.

You can refer to the legacy Wi-Fi HAL to see how it correlates with the AIDL and HIDL interfaces: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.

Implementation

To implement Wi-Fi RTT, you must provide both framework and HAL/firmware support:

• Framework:

  • AOSP code
  • Enable Wi-Fi RTT: requires a feature flag

• Wi-Fi RTT (IEEE 802.11mc or IEEE 802.11az) HAL support (which implies firmware support)

To implement this feature, implement the Wi-Fi AIDL or HIDL interface, and enable the feature flag:

• In device.mk located in device/<oem>/<device>, modify the PRODUCT_COPY_FILES environment variable to include support for the Wi-Fi RTT feature:

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

Otherwise, everything required for this feature is included in AOSP.

MAC randomization

To enhance privacy, the MAC address used during Wi-Fi RTT transactions must be randomized, that is, it must not match the native MAC address of the Wi-Fi interface. However, as an exception, when a device is associated with an AP, it may use the MAC address with which it is associated for any RTT transactions with that AP or with other APs.

Validation

Android Compatibility Test Suite (CTS) tests exist for this feature. CTS detects when the feature is enabled and automatically includes the associated tests. This feature can also be tested using the Vendor Test Suite (VTS).

Unit tests

The Wi-Fi RTT package tests are executed using:

Service tests:

atest com.android.server.wifi.rtt

Manager tests:

atest android.net.wifi.rtt

CTS

Android Compatibility Test Suite (CTS) tests exist for this feature. CTS detects when the feature is enabled and automatically includes the associated tests. An Access Point which supports Wi-Fi RTT (IEEE 802.11mc) must be within range of the device-under-test.

The CTS tests can be triggered using:

atest WifiRttTest

Calibration

For Wi-Fi RTT to perform well, the ranges returned in the 802.11mc or 802.11az protocols should be accurate within the key performance indicators (KPIs) as described in this section.

For the 11mc protocol, at the bandwidths listed (80 MHz, 40 MHz, 20 MHz) and a burst size of 8, the KPI for a range estimate is expected to achieve the following accuracy at the 90th percentile of error.

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

For the 11az protocol, the antenna MIMO configuration and the long training field (LTF) repetition affect accuracy. With a typical mobile phone (using 2 antennas) and access point (4 antennas), the system has a 2x4 MIMO configuration. For such a configuration using an LTF repetition factor of two and at the listed bandwidths (160 MHz, 80 MHz, 40 MHz, 20 MHz), the KPI for a range estimate is expected to achieve the following accuracy at the 90th percentile of error.

• 160 MHz: 0.5 meters
• 80 MHz: 1 meter
• 40 MHz: 2 meters
• 20 MHz: 4 meters

Note: There is no ranging burst for the 11az protocol because ranging is a single transmit operation (TXOP), which has a shorter exchange time than the 11mc protocol.

To ensure the implementation of the feature is working correctly, calibration testing is necessary.

This can be achieved by comparing a ground truth range against the RTT estimated range at increasing distances. For basic conformance, you should validate your solution against a device known to be RTT calibrated. Range calibration should be tested under the following conditions:

1. A large open laboratory, or a corridor that does not have a lot of metal objects that may result in unusually high occurrences of multi-path.
2. At least a Line-Of-Sight (LOS) track or path extending for 25 m.
3. Markers of 0.5 meter increments from one end of the track to the other.

4. A place to secure an RTT capable access point at one end of the track mounted 20 cm above the floor, and a movable mount for an Android phone (or other Android mobile device under test) that can be moved along the track, and aligned with the 0.5 m markers, also at 20 cm above the floor.

   Note: This repetitive task can be performed by a small robot, but a human operator is also fine.

5. 50 ranging results should be recorded at each marker, along with the distance from the access point. Statistics, such as range mean and variance, should be calculated for each marker position.

From the results in step 5, a chart can be drawn for ground truth (x-axis) against estimated range (y-axis) and a best fit regression line estimated. Ideal device calibration will result in a line of gradient 1.0, with offset 0.0m on the y-axis. Deviations from these values are acceptable if they are within the KPI for the corresponding bandwidth. If the results are outside of the KPI, the device feature should be recalibrated to bring the results within the KPI specification.