=Paper=
{{Paper
|id=Vol-3183/135
|storemode=property
|title=Mitigation of GNSS Errors in Urban Canyon Using Wi-Fi RTT
|pdfUrl=https://ceur-ws.org/Vol-3183/paper5.pdf
|volume=Vol-3183
|authors=Miquel Garcia Fernandez,Malgorzata Siutkowska,Aleix Tejada,Marco Antonio Vélez,Jose Javier Vicente,Joan Gemio,Laia Vilalta,Laura Tantinyà,Alberto Gil,Adrián Cardalda,Daniel Baños,Pere Mogas,Joaquín Reyes,Pavel Ivanov,Henri Nurminen,Simo Ali-Löytty,Pasi Raumonen,Lukas Hösch,Filippo Giacomo Rizzi,Lars Grundhöfer,Ralf Ziebold,Daniel Medina,Sanja Miljanovic,Francesco Ardizzon,Laura Crosara,Nicola Laurenti,Luca Canzian,Enrico Lovisotto,Nicola Montini,Oscar Pozzobon,Rigas Ioannides,Liwei Liu,Shuguo Pan,Wang Gao,Chun Ma
|dblpUrl=https://dblp.org/rec/conf/icl-gnss/Garcia-Fernandez22
}}
==Mitigation of GNSS Errors in Urban Canyon Using Wi-Fi RTT==
https://ceur-ws.org/Vol-3183/paper5.pdf
Mitigation of GNSS Errors in Urban Canyon Using Wi-Fi
RTT
Miquel Garcia-Fernandeza , Malgorzata Siutkowskaa and Aleix Tejadaa
a
Rokubun, Llacuna 162, Barcelona 08018, Spain
Abstract
GNSS excels in outdoor environments, in particular with clear sky visibility, where accuracies of
meter to centimeter level can be achieved. However, good accuracy in cities remains a challenge due
to multipath or poor visibility, caused by urban canyons. It is clear that GNSS alone cannot provide
a complete positioning solution in these environments and thus hybridization with other technologies
is necessary. The revision of the Wi-Fi 802.11mc protocol opened the possibility of obtaining Round
Trip Time (RTT): range measurement between the access point and the user equipment (UE). Being
range measurements, RTT is more robust and less environment-dependent than RSS-based position-
ing. Therefore, Wi-Fi RTT ranges collected from access points near the UE (e.g. visible from the
street) can be combined, in a tightly coupled hybridized strategy, in order to mitigate the errors in
GNSS due to a poor visibility or multipath. To assess this potential capability, a data campaign con-
sisting of GNSS and RTT ranges was held in an urban canyon environment and positioning estimates
have been computed using GNSS only and a GNSS+Wi-Fi combined solution.
Keywords
GNSS, Wi-Fi RTT, Tightly coupling hybridization, multipath mitigation
1. Introduction
Wi-Fi based positioning is widely used nowadays for indoor applications using the fingerprint-
ing technology, that consists in using a map of Received Signal Strength (RSS) measurements
to match the ones measured by the user device (see for instance [1]). However, the RSS mea-
surements are highly dependent on the environment and are susceptible to obstructions, walls
or furniture. Positioning methods that use a propagation model to derive range from RSS
have to deal with range errors as high as 5 meters with large variability (see for instance [2]).
The revision of the 802.11mc protocol published in 2016 allows to measure the Round Trip
Time (RTT), also known as Fine Time Measurements (FTT), between the access point and the
user device. These measurements, being time-based measurements, are less susceptible to the
environment (compared to RSS) and open up the possibility of providing meter level indoor
positioning ([3], [4]). In fact, using RTT measurements for positioning brings Wi-Fi closer to
GNSS: both systems use range measurements to estimate the user device position and thus
access points become pseudolites that can be used in combination of GNSS measurements once
the position of these access points are known. The main difference between GNSS and Wi-Fi
RTT is that, while GNSS is a broadcast-based system and the whole system needs to be syn-
chronized (hence the user device requires the computation of its clock deviation relative to each
ICL-GNSS 2022 WiP, June 07–09, 2022, Tampere, Finland
email: miquel.garcia@rokubun.cat (M. Garcia-Fernandez); malgorzata.siutkowska@rokubun.cat (M.
Siutkowska); aleix.tejada@rokubun.cat (A. Tejada)
©
orcid: 0000-0003-4844-6004 (M. Garcia-Fernandez)
2022 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
GNSS system clock), Wi-Fi is a bistatic system and thus there is no synchronization error, but
hardware biases in the measurements are present and need to be somehow accounted for (see
for instance [4]). In fact, for a Wi-Fi RTT system, both access point location and hardware
biases need to be provided to the positioning engine of the user device ([5]), similarly to the
GNSS case in which satellite orbits and clocks need to be provided.
This paper does not focus on Wi-Fi as a standalone positioning system for indoor application,
which has been already researched in the past (see for instance [4] or [6]), but rather in the
benefits that can be obtained when using Wi-Fi as complement to GNSS in urban scenarios to
reduce the impact of buildings, structures and narrow streets found in cities, which dramatically
degrade the performance of satellite-based navigation systems due to lack of visibility and
multipath. Therefore, this paper proposes the usage of Wi-Fi RTT ranges to mitigate the errors
of GNSS in urban environments, when the receiver is able to track Wi-Fi RTT measurements
served by access points that are visible from the streets (e.g. near windows). In this context,
this paper is organized as follows: the first section includes a brief description of the processing
model, followed by the details of the data campaign that has been used for testing and, finally,
a discussion and conclusion section wraps this paper.
2. Processing model
The processing model employed in this work is based on tightly coupling the GNSS raw mea-
surements (pseudoranges) with the RTT measurements obtained from 802.11mc compatible
Wi-Fi devices. The ranges of GNSS can be modelled using the following simplified model as:
sat
RG = ρsat + c · (dtEU − dtsat ) + ε, (1)
where RG sat is the observed range between the user equipment (U E) and the satellite (sat)
(called also pseudorange as it contains not only geometric range but other error terms), ρsat
is the geometric range (i.e. Euclidean distance) between the user equipment and the satellite,
dtEU and dtsat are the clock offsets for U E and sat respectively and ε contains the rest of
the GNSS pseudorange terms (ionospheric delay, tropospheric error, relativity, multipath and
thermal noise). A full description of the GNSS data model is outside the scope of this paper
but can be found in extensive literature (see for instance [7]).
On the other hand, for the Wi-Fi case, the range can be modelled according to the following
expression:
AP
RW = ρAP + bAP + bU E , (2)
where RW AP is the observed range between U E and the access point (AP ) (also pseudorange
because it contains error terms as well), ρAP is the geometric (Euclidean) distance between
AP and the user equipment that, similarly to the GNSS case, needs to be linearized using
Taylor expansion, and finally, bAP and bU E are the hardware biases for the access point and
user equipment respectively (see for instance [8]). Note that in the same way that GNSS
satellite orbits and clocks are required to model the GNSS range, in Wi-Fi both the AP
location and hardware biases are also required. In fact, the quality of WAP position and
biases will ultimately determine the accuracy of the Wi-Fi based positioning and the potential
improvement in the GNSS+Wi-Fi hybridization. For this work, the WAP products (position
and biases) have been surveyed, thus reaching errors in those products on the range of few
centimeters. However, works such as [5] indicate that meter-level accuracies can be reached in
an operational system that uses data from 802.11mc compliant smartphones to automatically
compute those WAP products, without the need of dedicated surveying campaign.
The ranges for both GNSS and Wi-Fi are then fused in a Kalman filter in a measurement
update characterized with the following matrix:
sat1 − Rsat1
psat1 psat1 psat1
⎡ ⎤ ⎡ ⎤
RG G,0 x y z 1 0
.. ..
⎡ ⎤
⎢ ⎥ ⎢ ⎥ ∆x
⎢ . ⎥ ⎢ . ⎥
⎥ ⎢ ∆y ⎥
satN − RsatN
⎥ ⎢ satN
psatN psatN
⎢
⎢ RG G,0
⎥ ⎢ px y z 1 0 ⎥ ⎢ ⎥
⎢ ⎥=⎢ ⎥ · ⎢ ∆z ⎥ (3)
⎢ R bssid1 bssid1
− RW,0 ⎥ ⎢ pAP 1 pAP 1 pAP 1 0 1 ⎥ ⎢ ⎥
⎢ W ⎥ ⎢ x y z ⎥ ⎣ dtU E ⎦
⎢ .. ⎥ ⎢ .. ⎥
⎣ . ⎦ ⎣ . ⎦ bU E
bssidN
RW bssidN
− RW,0 pAP
x
N pAP
y
N pAP
z
N 0 1
where pc is the partial for the c component (i.e. x, y or z), defined as:
c0 − ctx
ptx
c = , (4)
ρtx
0
√︁
and ρtx0 = (x0 − xtx )2 + (y0 − y tx )2 + (z0 − z tx )2 is the geometric range considering the
apriori position for the user receiver and a given transmitter (tx), that can be either a GNSS
satellite (sat) or Wi-Fi access point (AP ). The parameters to be estimated correspond to the
position deltas (relative to the position apriori), ∆x, ∆y, ∆z as well as the GNSS receiver clock
(dtU E ) and the receiver Wi-Fi bias (bU E ). The measurement updates can be solved in a purely
kinematic way by simply applying a Least Mean Squares strategy on every incoming batch
of measurements or apply a Kalman filter that allows to define certain dynamics for the user
equipment. In the case of this work, the latter has been adopted, and it has been assumed
that the UE behaves as a moving device and thus its dynamics are modelled as a random walk
with a generous dynamic (100 m / s), which should cover gently the dynamics of a pedestrian.
In fact, this setting can be tuned in real operations with an estimation of the velocity. For
this work, the wide dynamics stated above have been chosen so that the effective smoothing
of a tighter setting would not mask the improvement due to the combination between GNSS
and Wi-Fi (i.e. the rationale being that if the solution is improved with this wider setting, it
would also benefit a tighter dynamic setting).
3. Data campaign
In order to assess the potential improvement that can be achieved with the proposed fusion
approach, a harsh environment in terms of GNSS has been selected, with multipath and lim-
ited satellite visibility. The test setup has been conducted in Barcelona, in the patio of the
Glòries incubator center, where Rokubun offices are located (approx coordinates 41°24’23.39”N
2°11’32.58”E), see Fig. 1.
The most relevant characteristic of the proposed test setup is its complexity in terms of
GNSS signal. As it can be appreciated, the patio in which the test has been performed is
surrounded by tall buildings and structures. This environment is considered harsh in terms
of GNSS: the surrounding buildings and structures block multitude of GNSS satellites and
increases the noise due to multipath. In fact, it is optimal for the purpose of this work in
Figure 1: Location of test setup. Access points and user equipment were placed in the red square shown in
the top panel, The location of the test points (T*), within the red area are detailed in the bottom panel.
order to assess to what extent Wi-Fi RTT technology can complement GNSS to mitigate those
errors.
The list of equipment used in the execution of the test campaign is collated in Table 1. In
particular, the Rokubun MEDEA navigation computer, based on the u-blox ZED-F9P chipset,
has been modified to incorporate a Wi-Fi capable module in order to record both GNSS and
Wi-Fi measurements (see Fig. 2). In addition, a smartphone compliant with the 802.11mc
protocol has been used. The list of access points used for the campaign are also included in
the table. The table shows also the test points at which the equipment was placed during the
campaign.
Figure 2: User devices used for the testing. Rokubun MEDEA navigation computer has been placed at the
top left side of the table (test point T8). Smartphones such as Google Pixel 4 has been used as well. A
Compulab WILD Access Point has been placed at the top right side of the table (test point T7)
Table 1
List of equipment used in the data campaign and test point at which they have been placed.
Device Type Test point Specifications
Rokubun Medea user equipment T8 GNSS chipset u-blox ZED-F9P
Wi-Fi 802.11mc module u-blox JODY W2
Google Pixel 4 user equipment T8 Dual frequency L1/L5 GNSS
802.11mc compliant
Compulab WILD access point T10, T4, T7 802.11mc compliant
ORBI access point T6 802.11mc compliant, but they do not advertise the capabilities in their
EERO access point T12 802.11mc compliant, but they do not advertise the capabilities in their
4. Results and discussion
The data collected for both the Rokubun MEDEA navigation computer and the Google Pixel
4 has been processed with the model described in earlier section of this paper. The processing
model for GNSS that has been adopted attempts to reproduce the conditions of a mass-market
device, namely: pseudorange only processing and correcting the ionospheric delay with the
Klobuchar model (broadcast in the GNSS ephemeris, see [9]) and using the Saastamoinen model
for the tropospheric delay (see [10]). Given the conditions of the scenario, a high elevation
mask of 15◦ has been adopted. The coordinates generated by the positioning engine have
been then compared against the reference position (surveyed point at which the devices have
been placed) in order to obtain the horizontal deviation (Easting and northing deviation) as
well as the vertical deviation. The results for the different strategies considered (GNSS only,
Wi-Fi only and GNSS+Wi-Fi hybrid solution) are shown for Rokubun MEDEA navigation
computer (see Fig. 3) as well as for Google Pixel 4 (see Fig. 4). The scatter plots of these
figures have been generated using a data set of 32 minutes with a sampling rate of 1 second for
the Google Pixel 4 and 20 minutes with a sampling rate of 1 second for MEDEA. As expected,
the positioning errors are very large, specially for the smartphone case. Similar performance
in positioning has been obtained using third party tools such as RTKlib (see [11]).
Horizontal error in GNSS challenged scenario
Rokubun MEDEA navigation computer
GNSS
GNSS + Wi-Fi
40 Wi-Fi only
20
North component [m]
0
-20
GNSS only (horizontal) 7.4 +/- 3.6 m
GNSS+WiFi (horizontal) 5.8 +/- 2.7 m
-40 GNSS only (vertical) 17.8 +/- 13.4 m
GNSS+WiFi (vertical) 17.1 +/- 13.1 m
-40 -20 0 20 40
East component [m]
Figure 3: Horizontal error for a static test in challenged GNSS conditions for Rokubun MEDEA navigation
computer
All the error values, expressed as bias and standard deviation (σ) for all devices, components
and strategies are collated in Table 2. In all cases, there is a clear benefit in combining
GNSS with Wi-Fi both in bias and standard deviation, which is also evidenced in the figures
shown above. This improvement, mostly in the horizontal dimension, is due to the fact that
Wi-Fi is much less impacted than GNSS in this particular scenario. Note however that the
improvement is much lower in the case of MEDEA than Google Pixel 4. This is due to the
fact that the quality of the GNSS solution for MEDEA is much higher than the smartphone
(due to the dedicated GNSS chipset as well as much better antenna), thus leaving less room
for improvement. Therefore, when using more complex GNSS processing strategies (such as
e.g. Precise Point Positioning or Real Time Kinematics), the relative weighting between GNSS
and Wi-Fi ranges may have to be reviewed. However, considering the typical use case of the
proposed algorithm (i.e. mobile devices whose GNSS chipset and antenna offer observables
with higher noise, but integrate additional data sources for navigation such as Wi-Fi and
Ultra-wideband), the adoption of the proposed algorithm is deemed beneficial.
Regarding the accuracy that can be achieved with Wi-Fi only data, naı̈ve positioning strate-
gies such as centroid computation (i.e. weighted average position of the WAPs seen by the
receiver) yields higher error values. For the case of Google Pixel 4 (whose Wi-Fi only solution
yields 1.6 meter of horizontal error), discrepancies of 3.9 m, 2.6 m and 5.1 m are obtained
respectively for the unweighted average (raw average of WAP positions), weighting based on
RSS and weighting based on the inverse of the RTT measurements. The latter one yields worse
results due to the presence of the hardware biases. These error figures are highly dependent
on the geometry and disposition of the WAPs (in this case the WAPs were surrounding the
receiver in all directions), and can increase if the WAPs positions have a bad geometry relative
Horizontal error in GNSS challenged scenario
Google Pixel 4
GNSS only (horizontal) 28.8 +/- 9.6 m
40 GNSS+WiFi (horizontal) 10.1 +/- 7.3 m
GNSS only (vertical) 58.9 +/- 30.7 m
GNSS+WiFi (vertical) 52.2 +/- 20.7 m
20
North component [m]
0
-20
-40 GNSS
GNSS + Wi-Fi
Wi-Fi only
-40 -20 0 20 40
East component [m]
Figure 4: Horizontal error for a static test in challenged GNSS conditions for Google Pixel 4
Table 2
Horizontal and vertical errors of various processing strategies and various devices. Errors are expressed in
meters.
Device Component Strategy bias σ
Rokubun MEDEA horizontal GNSS 7.4 3.6
Wi-Fi 2.6 1.6
GNSS+Wi-Fi 5.8 2.7
vertical GNSS 17.8 13.4
Wi-Fi -9.5 16.8
GNSS+Wi-Fi 17.1 13.1
Google Pixel 4 horizontal GNSS 28.8 9.6
Wi-Fi 1.6 1.5
GNSS+Wi-Fi 10.1 7.3
vertical GNSS 58.9 30.7
Wi-Fi 10.7 18.6
GNSS+Wi-Fi 52.2 20.7
the receiver (e.g. all in one side). However, a naı̈ve location based on weighted average can
be used as an apriori position to linearize the navigation equations. Actually, this approach
might provide more accurate apriori positions than the Bancroft method typically used in
GNSS, which will reduce the convergence time of the positioning engine.
Another point worth noticing from the figures shown above (Fig. 3) and Fig. 4) is the linear
shape for the Wi-Fi horizontal errors. The reason behind this shape is due to the disposition
of the access points. From the lower panel shown in Fig. 1, the reader might have noticed that
the routers where placed, approximately in the North West to South East direction. Since the
user equipment where placed in the middle, there is an ambiguity in the South West to North
East direction (i.e. the algorithm cannot properly determine the correct position along this
direction), thus leading to this shape. This problem, due to the Dilution of Precision (DOP),
also exists in GNSS and in fact worsens in Wi-Fi because the relative distances of the ranges
and user dynamics is much shorter than in the case of GNSS.
5. Conclusions
The present paper showed to what extent Wi-Fi RTT measurements can benefit and comple-
ment GNSS systems when challenged by multipath in urban scenarios. This benefit applies
to urban outdoor GNSS receivers that are able to track Wi-Fi RTT measurements (from e.g.
access points placed near windows or visible from the street). A clear application field of this
technique is for certain Android smartphones, where GNSS raw measurements are available
to the developer since Android 7 (Nougat, API 24) and Wi-Fi RTT ranging since Android 9
(Pie, API 28 [12]).
The results shown in the paper indicate a clear improvement of at least 1 to 2 meters in
bias and standard deviation, albeit this depends on the device: for a premium-mass-market
receiver such as the Rokubun MEDEA navigation computer (with a dedicated multifrequency
antenna), there is still improvement, but is less noticeable than in the case of the smartphone.
Similarly, benefits are still present when GNSS is working at its full capability (open sky, with
no multipath or problems in terms of visibility), but are much smaller than the case proposed
(reduction of errors less than 1 m).
From the results shown above, Wi-Fi only solution is better than the combined one with
GNSS in a multipath-rich scenario, but might not be the case in a mixed environment (nominal
GNSS visibility and irregular Wi-Fi RTT availability), albeit still benefit from the hybridiza-
tion. In this scenario, the number of available Wi-Fi RTT measurements was plenty, which
allowed for a robust position estimation with Wi-Fi (this could be in fact the typical case in
indoors). In a more generic case, in order to achieve the best possible geolocation solution, the
hybridization strategy will likely have to be properly weighted between GNSS and Wi-Fi tak-
ing into account different factors such as number of available Wi-Fi measurements, potential
GNSS multipath indicators (C/N0, variation of the C/N0), etc.
Unfortunately, the number of Commercial Off The Shelf platforms (both access points and
smartphones) that are fully 802.11mc compatible are rather scarce. Apple, for instance, has no
support for 802.11mc to the best of the author’s knowledge. However, the technique proposed
in this work can be easily applied as well to similar short range location technologies such
as Ultra-wideband (UWB). In fact, smartphone manufacturers are already supporting UWB
and additional systems such as Bluetooth or 5G-based ranging may be supported in the near
future.
“Data availability” The GNSS raw measurements as well as Wi-Fi RTT ranges from
smartphone data are available to the reader upon request to the authors.
Acknowledgments
This work as well as the Article Processing Charges (APC) of this manuscript have been
funded by the European Union Agency for the Space Programme (EUSPA) under grant
GSA/GRANT/04/2019/BANSHEE.
References
[1] S. Xia, Y. Liu, G. Yuan, M. Zhu, Z. Wang, Indoor fingerprint positioning based on Wi-Fi:
An overview, ISPRS International Journal of Geo-Information 6 (5) (2017) 135.
[2] A. Abusara, M. Hassan, Error reduction in distance estimation of RSS propagation models
using Kalman filters, in: 2015 6th International Conference on Modeling, Simulation, and
Applied Optimization (ICMSAO), IEEE, 1–5, 2015.
[3] F. von Diggelen, R. Want, W. Wang, How to achieve 1-meter accuracy in Android, GPS
world URL https://www.gpsworld.com/how-to-achieve-1-meter-accuracy-in-android/.
[4] C. Ma, B. Wu, S. Poslad, D. R. Selviah, Wi-Fi RTT ranging performance characterization
and positioning system design, IEEE Transactions on Mobile Computing .
[5] M. Garcia-Fernandez, I. Hoyas-Ester, A. Lopez-Cruces, M. Siutkowska, X. Banqué-
Casanovas, Accuracy in wifi access point position estimation using round trip time, Sensors
21 (11) (2021) 3828.
[6] Y. Yu, R. Chen, L. Chen, W. Li, Y. Wu, H. Zhou, A Robust Seamless Localization
Framework Based on Wi-Fi FTM/GNSS and Built-In Sensors, IEEE Communications
Letters 25 (7) (2021) 2226–2230.
[7] P. Misra, P. Enge, Global Positioning System-Signals, Measurements and Performance,
Second Edition Ganga-Jamuna Press, 2006.
[8] C. Gentner, M. Ulmschneider, I. Kuehner, A. Dammann, Wifi-RTT indoor positioning, in:
2020 IEEE/ION Position, Location and Navigation Symposium (PLANS), IEEE, 1029–
1035, 2020.
[9] J. A. Klobuchar, Ionospheric effects on GPS, Global positioning system: theory and
application .
[10] J. Spilker Jr, Tropospheric effects on GPS, Global Posiotioning System: Theory and
Applications 1 (1996) 517–546.
[11] T. Takasu, A. Yasuda, Development of the low-cost RTK-GPS receiver with an open
source program package RTKLIB, in: International symposium on GPS/GNSS, vol. 1,
International Convention Center Jeju Korea, 2009.
[12] Android, Android API online documentation, URL https://developer.android.com/
reference/android/net/wifi/rtt/package-summary, 2015.