[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Wi-Fi RTT (IEEE 802.11mc, IEEE 802.11az)\n\nThe\n[Wi-Fi Round Trip Time (RTT)](https://developer.android.com/guide/topics/connectivity/wifi-rtt)\nfeature in Android 9 enables supporting devices to\nmeasure a distance to other supporting devices: whether they are Access Points\n(APs) or Wi-Fi Aware peers (if [Wi-Fi Aware](/docs/core/connect/wifi-aware)\nis supported on the device). This feature, built upon the IEEE 802.11mc\nand IEEE 802.11az protocol (available from Android 15),\nenables apps to use enhanced location accuracy and awareness.\n\nExamples and source\n-------------------\n\nTo use this feature, implement the Vendor HAL interface.\nIn Android 14 and higher,\nthe Vendor HAL interface is defined using AIDL.\nIn Android 13 and lower,\nthe Vendor HAL interface is defined using HIDL.\nIn Android 8.0, HIDL\nreplaced the previous Hardware Abstraction Layer (HAL) structure used to\nstreamline implementations by specifying types and method calls collected into\ninterfaces and packages.\n\nFollow the Wi-Fi interface to employ the Wi-Fi RTT feature.\nDepending on which interface is implemented, this is:\n\n- AIDL: `hardware/interfaces/wifi/aidl`\n- HIDL: `hardware/interfaces/wifi/1.0` or later.\n\nYou can refer to the legacy Wi-Fi HAL to see how it correlates with the\nAIDL and HIDL interfaces:\n[hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h](https://android.googlesource.com/platform/hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h).\n\nImplementation\n--------------\n\nTo implement Wi-Fi RTT, you must provide both framework and HAL/firmware\nsupport:\n\n- Framework:\n\n - AOSP code\n - Enable Wi-Fi RTT: requires a feature flag\n- Wi-Fi RTT (IEEE 802.11mc or IEEE 802.11az) HAL support (which implies\n firmware support)\n\nTo implement this feature, implement the Wi-Fi AIDL or HIDL interface,\nand enable the feature flag:\n\n- In `device.mk` located in `device/\u003coem\u003e/\u003cdevice\u003e`, modify the\n `PRODUCT_COPY_FILES` environment variable to include support for the Wi-Fi\n RTT feature:\n\n PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.rtt.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.rtt.xml\n\nOtherwise, everything required for this feature is included in AOSP.\n\nMAC randomization\n-----------------\n\nTo enhance privacy, the MAC address used during Wi-Fi RTT transactions must be\nrandomized, that is, it must not match the native MAC address of the Wi-Fi\ninterface. However, as an exception, when a device is associated with an AP, it\nmay use the MAC address with which it is associated for any RTT transactions\nwith that AP or with other APs.\n\nValidation\n----------\n\nAndroid Compatibility Test Suite (CTS) tests exist for this feature. CTS detects\nwhen the feature is enabled and automatically includes the associated tests.\nThis feature can also be tested using the\n[Vendor Test Suite (VTS)](/docs/compatibility/vts).\n\n### Unit tests\n\nThe Wi-Fi RTT package tests are executed using:\n\nService tests: \n\n atest com.android.server.wifi.rtt\n\nManager tests: \n\n atest android.net.wifi.rtt\n\n### CTS\n\nAndroid Compatibility Test Suite (CTS) tests exist for this feature. CTS detects\nwhen the feature is enabled and automatically includes the associated tests. An\nAccess Point which supports Wi-Fi RTT (IEEE 802.11mc) must be within range of\nthe device-under-test.\n\nThe CTS tests can be triggered using: \n\n atest WifiRttTest\n\nCalibration\n-----------\n\nFor Wi-Fi RTT to perform well, the ranges returned in the 802.11mc or 802.11az\nprotocols should be accurate within the key performance indicators (KPIs) as\ndescribed in this section.\n\nFor the 11mc protocol, at the bandwidths listed (80 MHz, 40 MHz,\n20 MHz) and a burst size of 8, the KPI for a range estimate is expected to\nachieve the following accuracy at the 90th percentile of error.\n\n- **80 MHz:** 2 meters\n- **40 MHz:** 4 meters\n- **20 MHz:** 8 meters\n\nFor the 11az protocol, the antenna MIMO configuration and the long training\nfield (LTF) repetition affect accuracy. With a typical mobile phone (using 2\nantennas) and access point (4 antennas), the system has a 2x4 MIMO\nconfiguration. For such a configuration using an LTF repetition factor of two\nand at the listed bandwidths (160 MHz, 80 MHz, 40 MHz,\n20 MHz), the KPI for a range estimate is expected to achieve the following\naccuracy at the 90th percentile of error.\n\n- **160 MHz:** 0.5 meters\n- **80 MHz:** 1 meter\n- **40 MHz:** 2 meters\n- **20 MHz:** 4 meters\n\n| **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.\n\nTo ensure the implementation of the feature is working correctly, calibration\ntesting is necessary.\n\nThis can be achieved by comparing a ground truth range against the RTT estimated\nrange at increasing distances. For basic conformance, you should validate your\nsolution against a device known to be RTT calibrated. Range calibration should\nbe tested under the following conditions:\n\n1. 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.\n2. At least a Line-Of-Sight (LOS) track or path extending for 25 m.\n3. Markers of 0.5 meter increments from one end of the track to the other.\n4. A place to secure an RTT capable access point at one end of the track\n mounted 20 cm above the floor, and a movable mount for an Android phone\n (or other Android mobile device under test) that can be moved along the\n track, and aligned with the 0.5 m markers, also at 20 cm above\n the floor.\n\n | **Note:** This repetitive task can be performed by a small robot, but a human operator is also fine.\n5. 50 ranging results should be recorded at each marker, along with the\n distance from the access point. Statistics, such as range mean and variance,\n should be calculated for each marker position.\n\nFrom the results in step 5, a chart can be drawn for ground truth (x-axis)\nagainst estimated range (y-axis) and a best fit regression line estimated. Ideal\ndevice calibration will result in a line of gradient 1.0, with offset 0.0m on\nthe y-axis. Deviations from these values are acceptable if they are within the\nKPI for the corresponding bandwidth. If the results are outside of the KPI, the\ndevice feature should be recalibrated to bring the results within the KPI\nspecification."]]
