# Round-Trip Time Ranging to Wi-Fi Access Points Beats GNSS Localization
## 9 Which of the APs Should Be Used for Ranging? When using FTM RTT for localization, one needs a strategy for selecting APs. It takes time to perform RTT measurement; so one typically cannot afford to request RTT responses from all of the responders in an area of interest. In addition, the Android API limits the number of BSSIDs in a given ranging request (maxPeers=10). To address more APs, multiple ranging requests have to be used, with considerable associated overhead. A tempting strategy is to include in the current set of APs just the ones that have a high probability of responding again. One could, for example, range to the APs that have responded recently, are nearby, and have good signal strength. But this means that, as the ranging process is repeated, the number of APs in the current \"ranging set\" can only go down. This creates a problem when one moves away from those APs, since once far enough away, no responses will be received at all. There must be a mechanism for adding \"new\" APs into the \"current set\" (and for retiring \"old\" ones). One way to attack this problem is to perform frequent Wi-Fi scans to see which APs are \"within range\". But, as discussed below, Wi-Fi scans are slow and may interfere with ranging. Another approach is to sort APs on their distance and select the nearest ones. The distance can be calculated for all APs--including ones not in the current set--using an estimate of the current position of the UE. However, if the APs come in clusters rather than being uniformly distributed, then the APs nearest to the old estimate of the UE position may form a group, none of which responds once the UE is far enough away. When moving away from such a cluster, all ranging requests may be for \"old\" APs that eventually are too far away to respond. An alternative is to \"probe\" APs that, while not in the current set, are likely to respond. There is a cost associated with ranging to APs. As a result, there is a trade-off between addressing mostly APs that are expected to respond--in order to obtain the highest localization accuracy--versus adding in some \"range probes\"--to avoid losing contact and becoming stuck ranging to a cluster of non-responsive APs. What criterion to use? We already discussed selection based on distance (see also [27]). We can also use signal strength and the time since a response was last obtained. Some of these criteria only apply to APs that have been \"seen\" recently. One alternative is to sort on a \"quality\" factor that incorporates all available information. A simple version of a quality factor is a linear weighted combination of distance, time since last seen, and the signal strength when last seen (the stored signal strength of an AP not seen recently is not trustworthy, so should be forced to algorithmically \"fade away\" with time). Other factors may be included, some with positive weights and some negative. Examples include whether the frequency of the AP is known or whether it is yet to be determined (see below). Higher weight can be given to an AP whose frequency has already been found. The directions from the UE to the APs are also important, in that a set of APs lying in more or less the same direction do not provide a strong constraint on the position of the UE. The best is a set of directions spread all around the compass. A criterion based on this notion is harder to incorporate since it is not dependent on just the direction to an individual AP. One approach is to first determine the set of directions of all APs currently responding (since these are likely to respond again to the next ranging request) and then compute some criterion favoring directions that are _different_ from those in the current set of directions, i.e., favor APs that lie in large gaps in the set of current directions to APs. There may also be prior information about how reliable the information from a particular AP is (e.g., a radio with different accuracy may be used in waterproof APs installedoutdoors than those installed indoors, e.g., [27]).