Fundamentals

Wi-Fi RTT explained without the jargon

What measuring a signal's round-trip time means, how it differs from measuring power, and why that choice decides whether a system works.

Published on 30 June 2026 Metrosafe team

If someone has pitched you an indoor location system, at some point the acronyms RTT or FTM probably appeared and nobody stopped to explain them. This article explains them — and explains why the difference between the two ways of measuring with Wi-Fi is not a technical detail, but the thing that decides whether a deployment works or turns into a permanent pilot.

Two ways to estimate a distance

To know how far you are from a Wi-Fi access point there are only two routes: look at how much signal reaches you, or look at how long it takes to reach you.

Route one: power (RSSI)

This is the classic method, and the more intuitive one. A radio signal weakens with distance according to a known law. If you know the transmit power and measure the received power, you can solve for distance.

In an empty room it works. In the real world, less so, because received power depends on quite a few things that are not distance:

The phone model. Every device has its own antenna, casing and calibration. Two handsets at the same spot report different power levels.
How it is held. A hand over the antenna costs several decibels. A phone in an inside jacket pocket, more.
The people around. The human body is largely water, and water absorbs at 2.4 and 5 GHz. A crowded platform attenuates more than an empty one.
Reflections. Reflected signal adds to or subtracts from the direct path depending on phase, producing swings of several decibels over a few centimetres of movement.

The technique used to compensate is fingerprinting: walking the whole site point by point, recording the power received from each access point, and building a radio map. Later, when a device reports its readings, the system looks for the closest match on that map.

It works better than raw estimation, but it drags two structural problems. The first is that the map has to be walked, for every site. The second, worse: it expires. Move an access point, relocate a vending machine, install a metal advertising panel, and the map stops being valid for that area.

Typical errors with this method run to tens of metres. In a station, that does not distinguish the level.

Route two: time (RTT/FTM)

Here the question changes. Instead of “how much signal arrives”, you measure “how long it takes to go and come back”.

The mechanism, in its simplest form: the terminal sends a frame to the access point and records the exact departure instant. The access point receives it, records when, replies and records when it replied. The terminal receives the reply and records the arrival. From those four timestamps you compute the time of flight, discounting the access point’s processing time.

That is the Round-Trip Time, and the protocol that standardises it is FTM, Fine Timing Measurement, added to IEEE 802.11mc in 2016. In practice it is not a single measurement but a burst, averaged.

The numbers involved are delicate: light travels about 30 centimetres in a nanosecond. For the distance error to stay in the order of a metre, timing has to be good to a few nanoseconds. That requires hardware support in the chip, which is why not every access point and not every phone will do.

What this changes in practice

| | RSSI (power) | RTT / FTM (time) | |---|---|---| | What it measures | How much signal arrives | How long it takes to arrive | | Depends on handset model | Heavily | Barely | | Affected by crowding | Yes, noticeably | Considerably less | | Needs a radio map surveyed on foot | Yes, and it needs maintaining | No | | Survives an access point being moved | No | Yes, by reconfiguring its position | | Typical error cited | Tens of metres | 1-2 m with line of sight |

The row that weighs most in a real deployment is the second to last. A system that has to be recalibrated every time the installation changes ends up abandoned; one that only needs to know where each access point is, does not.

The requirement to check before anything else

All of the above has one condition: the access point must support FTM and have it enabled, and the terminal must be able to use it.

On the terminal side, Android has exposed the capability natively since Android 9, with broader support from Android 10. Most corporate fleets bought since 2019 qualify, but chipsets do not all behave identically, so the approved terminal matrix is closed by testing, not by reading datasheets.

On the network side, most professional-grade 802.11ac and 802.11ax access points support it, but it ships disabled. It has to be enabled from the controller.

That is why, in any project of this kind, the first question is not about accuracy or price. It is: how many of your access points can enable FTM? That determines which stations are in and which are out, and answering it is a matter of an inventory, not a pilot.

What RTT does not solve on its own

Worth saying, because some vendors sell the raw measurement as if it were the whole system.

Measuring time of flight solves the problem of power being unreliable. It does not solve the problem of the signal not travelling in a straight line. When a column, a stationary train or a curve sits between terminal and access point, the signal arrives reflected: it travelled further, the time measurement comes out longer, and the system believes you are further away.

That error is biased. It does not average out, because it always pushes the same way. And on a platform, with metal surfaces and parallel walls, it is the norm rather than the exception.

A system usable in this environment needs three things on top of the measurement:

Detection of reflected measurements, so they lose weight instead of contaminating the result.
A filter with memory, carrying the previous state forward and refusing impossible jumps.
The site layout, which rules out positions that would fall inside a wall or across the track.

Of the three, the one that removes the most error is the third, and it is also the cheapest: the information already exists, it just has to be fed into the estimator.

And what is coming: 802.11az

IEEE 802.11az was published in 2022 as the evolution of all this, known as Next-Generation Positioning. It raises the measurement rate, exploits more bandwidth and handles ambiguity better, with sub-metre accuracy in favourable scenarios. Android exposes it on compatible devices from Android 15.

What matters for anyone deciding today is that it forces no redesign. A well-built fusion engine treats a ranging measurement as an input with an associated uncertainty, and does not care whether it came from 802.11mc or 802.11az. As the terminal fleet refreshes, accuracy improves on its own.