Which Wi-Fi access points support the IEEE 802.11-2016 protocol (a.k.a IEEE 802.11mc FTM RTT)?

1. Google WiFi (original, first offered in 2016) supports the IEEE 802.11mc FTM RTT protocol

   The original Google WiFi advertizes this ability in the beacon frame (since 2018).
   It uses a single Qualcomm IPQ4019 chipset for both 2.4 GHz (no FTM RTT) and 5 GHz (FTM RTT enabled).

2. Nest WiFi supports FTM RTT (as of May 2020).

3. Google Nest Pro WiFi supports FTM RTT.

4. Compulab's Wi-Fi Indoor Location Device (WILD) contains a modified (§) Intel® AC-8260 Wi-Fi chip that is FTM RTT enabled and can act as an access point (AP) (on channels 36, 40, 44, or 48 in the 5 GHz band). Note that an unmodified Intel® AC-8260 cannot be used this way - see Do Intel® Wireless Adapters Support Master or AP Mode:
   “All current Intel® Wireless Adapters are client-only devices and don't support the master or AP mode.
   The Intel Wireless Adapters can support the Wi-Fi Direct (peer-to-peer) or the hotspot features.”

   

   UPDATE: the Compulab WILD web site recently added: “WILD is not recommended for new projects”

5. Some access points can be asked to support FTM RTT in responder mode by changing their profile settings. For example, in the case of Aruba 500 Series access points (running ArubaOS 8.6 or later) change a setting in Configuration > System > Profiles > Wireless LAN > Virtual AP > Advanced. Select “Manually Configuring the Virtual AP Profile”. Scroll down to “Advanced”.

   “ArubaOS 8.7 was released in July 2020 and includes support for 802.11mc on the AP-505 and AP-515 Wi-Fi 6 access points.”

   Further, in Aruba Instant 8.8 and later (for Aruba 500, 510, 530, 550, 560 and 570 Series), you can add ftm-responder-enable to the WLAN SSID-profile to enable support for 802.11mc FTM RTT.

   

6. See also Android Developer's list of access points that support FTM RTT (i.e. those that advertize the capability in the beacon frame).

Some access points respond to the IEEE 802.11mc FTM RTT requests, while not advertizing that capability in the beacon frame (using the EXTENDED_CAPS (127) “Information Element”) (†) For example:

1. ASUS RT-ACRH13 responds to the IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†)
   Note: produces some measurements systematically short by 0.9 meter and sometimes 1.8 meter.
   The ASUS RT-ACRH13 uses Qualcomm IPQ4018 chipset for both 2.4 GHz and 5 GHz bands.
   Note: ASUSTek uses many different Wi-Fi chip sets in its routers, most of which do not support FTM RTT (e.g. ASUS RT-AC66U does not).

2. ASUS RT-ACRH17 responds to the IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†)
   Note: at times produces measurements systematically short by 10.3 meter — or too large by 5.5 meter.
   Note: while being a newer, more expensive successor to the RT-ACRH13, the RT-ACRH17 seems to produce somewhat less reliable, “noisier” ranging results.
   The ASUS RT-ACRH17 uses a Qualcomm IPQ4019 chip set for the 2.4 GHz band and Qualcomm QCA9984 for the 5 GHz band.
   Note: ASUSTek uses many different Wi-Fi chip sets in its routers, most of which do not support FTM RTT (e.g. ASUS RT-AC86U does not).

3. Linksys EA6350 v. 3 AC 1200 responds to the IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†)
   The Linksys EA6350 v. 3 uses Qualcomm IPQ4018 chipsets for both 2.4 GHz and 5 GHz bands.
   Note: the above applies to EA6350 version 3, which uses Qualcomm chips. It is unlikely to be true of versions 1 and 2, which use Broadcomm chips. It may be true of version 4, which uses MediaTek chips (MT7603E and MT7663).
   Note: Linksys uses many different Wi-Fi chip sets in its routers, most of which do not support FTM RTT.

4. Eero Pro responds to IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†). Eero Pro has one radio operating in the lower part of the 5 GHz band and one in the upper part. The first 5GHz radio uses the Qualcomm IPQ4019 chip and the second 5Ghz radio uses the Qualcomm QCA9886 SoC (Not surprisingly then, the offsets and errors of the two channels are different).
   

5. Netgear Orbi (RBR20) responds to IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†). Netgear Orbi has one radio operating in the lower part of the 5 GHz band and one in the upper part. The first 5GHz radio uses the Qualcomm IPQ4019 chip and the second 5GHz radio uses the Qualcomm QCA9984 SoC. (The offsets and errors of the two channels are very different). It supports the DFS channels.

6. Netgear Orbi (LBR20) (the LBR20 can also support 4G LTE) responds to IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†). Netgear Orbi has one radio operating in the lower part of the 5 GHz band and one in the upper part. (The offsets and errors of the two channels are very different). It supports the DFS channels.

7. Linksys Velop Tri-Band Home Mesh WiFi System responds to IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†). Linksys Velop Tri-Band has one radio operating in the lower part of the 5 GHz band and one in the upper part. The first 5GHz radio uses the Qualcomm IPQ4019 chip and the second 5GHz radio uses the Qualcomm QCA9986 SoC. Surprisingly, this AP supports 802.11mc on both the 2.4 GHz and 5 GHz bands.

8. Starlink Wifi Router responds to IEEE 802.11mc FTM RTT requests, but does not advertize that capability in the beacon frame (†). It responds in both the 5 GHz and the 2.4 GHz bands. Presently nothing more is known about the radio in the AP that comes with the Starlink satellite system or who makes the RF chips.

Currently, many installed Wi-Fi access points do not advertize support for the IEEE 802.11mc FTM RTT protocol.

1. A fraction (about 3% in Boston's Back Bay – as of fall 2019) do support it, but do not advertize this (†).
   The MAC addresses of devices observed “in the wild” that do are registered to: Google, eero inc, Netgear, Belkin, ASKEY Computer Corp, ASUSTek, TP-LINK Technologies, Ubiquiti, HTC Corporation, Hitron, Ruckus, Open Mesh, Mojo Networks, Synology, Luma Home, CradlePoint, IgniteNet, Xiaomi Communications, OnePlus Technology, and Shenzhen Four Seas Global (in decreasing order of occurrence). Specific models of responding APs are not known (except for those listed in the previous section).

2. Support for FTM RTT is mostly in the 5 GHz band. Wi-Fi signals in the 2.4 GHz band “go further” and penetrate building materials better than those at 5 GHz. At the same time the lower bandwidth available in the 2.4 GHz band (max 40 MHz versus 80 MHz in the 5 GHz band) reduces the accuracy of RTT measurement somewhat. The MAC addresses of some APs observed “in the wild” supporting the 2.4 GHz band are registered to: eero inc, ASKEY Computer Corp, Ubiquiti, HTC Corporation, Synology, and OnePlus Technology. Again, specific model numbers of responding APs are not known.

3. Even fewer APs support the FTM RTT protocol in both 2.4 GHz and 5 GHz bands. One that does is the Linksys Velop Tri-Band Home Mesh WiFi System (see above). Another AP that does has Wi-Fi chips from ASKEY Computer Corp — make and model unknown.

4. Many of the APs that do support FTM RTT are relatively recent designs, typically part of “mesh” configurations.
   The following are some APs which can be part of a mesh configurations
   (Note: Only particular AP models from these vendors may support IEEE 802.11mc FTM RTT — but do not advertize it):

   Google Wifi Dual Band Mesh Router (see above), eero Pro Mesh Wi-Fi System (second generation) (see above), Netgear Orbi Tri-Band Mesh System (see above), Linksys Velop Tri-Band Mesh Wi-Fi System (see above), TP-Link Deco M9 Plus Wi-Fi Mesh System, Ubiquiti AmpliFi HD Dual-Band Mesh Wi-Fi System, ASUS Lyra Tri-Band Whole-Home Mesh WiFi System, Zyxel Multy X tri-band mesh, MeshForce M1 WiFi, Tenda Nova MW3, MW5, MW5s, or MW6 Whole Home Mesh WiFi, D-Link COVR Tri-Band Whole Home WiFi Mesh System, etc. (but see (†))

   NOTE: It is best not to buy access points directly from the manufacturers themselves (particularly NETGEAR and Ubiquity) because of their awkward return policies, and because they may not give you your money back if there is a problem (only offering to replace the product). Instead, order indirectly (e.g. via Amazon) if possible, where a defective product (e.g. one that will not power up, or one that only supports a proprietary extension of IEEE 802.11 such as airMax) can be returned with ease.

(†) Note: Access points that support the IEEE 802.11mc FTM RTT protocol, but do not advertize this capability, are awkward to use because Android API WiFiManager.getScanResults() marks them as non-supporting in the ScanResult, and so the WifiRttManager.startRanging(...) call on the corresponding RangingRequest will fail — without even trying.

One can get around this limitation using "java reflection" to access the "flag" field in the ScanResult — or using java reflection to access the constructor for the ResponderConfig class and using AddResponder in the RangingRequest Builder.

Update: starting in Android 12, the Android API makes it easier to use access points that do not advertize support for IEEE 802.11mc (using “one-sided” RTT).

(‡) Note: some APs that support FTM RTT, but do not advertize this capability, may, in some cases, not support it well, be subject to relatively large measurement errors, frequent outliers, or crash when asked to respond “too often.”