Modeling GNSS Signals in Urban Canyons using Visibility Graphs and 3D Building Models

Transcription

1 Modeling GNSS Signals in Urban Canyons using Visibility Graphs and 3D Building Models Boaz Ben-Moshe 1 Paz Carmi 2 Eran Friedman 2 Matthew J. Katz 2 1 Department of Computer Science, Ariel University Center, Ariel 40700, Israel 2 Department of Computer Science, Ben-Gurion University of the Negev, Beer-Sheva 84105, Israel benmo@g.ariel.ac.il {carmip,eranfrie,matya}@cs.bgu.ac.il Abstract This paper addresses the problem of modeling and simulating RF-signals captured by receivers of Global Navigation Satellite Systems (GNSS) in urban canyons. The presence of tall buildings in urban canyons often block lines of sight between receivers and GNSS satellites, and therefore signals reach the receivers indirectly, after bouncing off buildings. These multi-path and echo-only effects are the major causes for inaccurate location estimations in urban canyons. Simulators for GNSS are essential tools for properly testing positioning algorithms before production. We develop such a simulator utilizing a geometric framework that simulates the paths of the received RF-signals in urban regions. We define a visibility graph over the buildings, then introduce and implement several novel heuristics in order to improve the algorithm s performance. We conduct a set of experiments to examine the effects of these heuristics on the simulation runtime. This research was partially supported by the MatiMop program of the Israel Ministry of Industry and Trade - igalileo consortium. 1

2 1 Introduction A well known problem in the field of Global Navigation Satellite System (GNSS) is that receivers in these systems generate inaccurate location estimations while operating in urban regions [6,8]. This phenomenon is mostly due to the existence of tall buildings, which block lines of sight (LOS) from the receiver to the navigation satellites. As a consequence, the signals reach the receiver indirectly, after bouncing off the buildings. Prior studies have shown that modern GNSS receivers are sensitive enough to acquire and track such no-line-of-sight (NLOS) signals by using longer integration times and data wipe-off [16,21]. This increases satellite availability in weak signal environments, but in an urban canyon comes with positioning errors, resulting from signal cross-correlation, multipath and echo-only signals [13,21]. Figure 1 illustrates such positioning errors caused by wrong pseudoranges in an urban region. Figure 1: Inaccurate positioning results in urban canyons: in yellow the real path, in red the path as computed by a standard GPS. The average error is larger than 20 meters, the maximal error is over 200 meters (Left: above view, Right: perspective view). Most simplistically, a GNSS receiver in systems such as GPS, GLONASS or GALILEO, approximates its position by interpolating the signal from each navigation satellite into a pseudorange, an approximation of the distance between the receiver and the navigation satellite, obtained by multiplying the speed of light by the time needed for the signal to travel the distance. Using four pseudoranges and their associated satellite locations, the GNSS receiver location can be computed simply by intersecting the four spheres (see [7, 11] for more information concerning GNSS principles). A GNSS receiver may distinguish between LOS and NLOS satellites using a simplistic signalstrength algorithm, which correlates strong signals to LOS satellites and weak signals to NLOS satellites. Thus, a GNSS device operating in a non-urban area can simply sort captured signals according to their strength, then use four or more strong-enough signals to compute its location. Since a receiver operating in the country-side typically has LOS with more than four satellites, the majority of location computations in such areas are based on signals originating from LOS satellites, for which pseudoranges tend to be accurate (the error range is typically within 2-5 meters). In urban canyons, however, it is very common for a GNSS device to be surrounded by obstacles such as tall buildings, which block LOS with most, and less frequently all, otherwise available satellites. In such situations, the receiver cannot perform straightforward trilateration computations [14] as described, because even the strongest signals may be echo-only or multipath. 2

3 A tradeoff therefore exists between: (1) GNSS receivers sensitivity, which enables to capture NLOS signals and incorporate them in location estimations when LOS signals are too few; (2) inherent pseudorange errors resulting from incorporating reflected NLOS signals in location estimations; Considering this tradeoff and the difficulty to estimate pseudorange errors [5], which is most dire in urban environments, it is not surprising that manufacturers of hardware and software for GNSS receivers, aiming to provide best possible location estimations, are shifting away from traditional trilateration of four satellite, towards more heuristic positionings methods. For example, the urban canyon is a challenging environment for GNSS. Nonethless, this environment is plentiful of appartments and offices equipped with WLAN Access Points (APs) that broadcast beacon frames multiple times a second. This can be beneficial for solutions that integrate GNSS and WLAN sensory data [20]. Another approach which can improve the urban canyon problem using external data is to coincide the output of a sensor such as GPS with a road network map. The process is called Map Matching ( MM ) [12,17,23,24] and is often integrated with Dead Reckoning ( DR ), which is the process of estimating one s current position based upon a previously determined position [9, 25]. 1.1 Motivation and Contribution GNSS signal modeling and simulation tools were already suggested by other researchers [3,18,19,22]. In some of these solutions, signals are simulated without considering the obstacles of the urban environment (i.e., the buildings), while in other solutions multi-path signals are being mimicked, either by statistical methods or by using expensive hardware. Our contribution to the field of GNSS modeling and simulation, particularly in urban canyons, derives from a relatively new approach in the field of GNSS analysis, which makes use of 3D building models to analyze LOS/NLOS to each satellite [2, 10, 15]. Thus, in contrast to aforementioned GNSS-improvement methods (e.g., Map Matching), which confront the urban canyon problem by integrating data that is external to the root of the problem, our framework is modeling the problems of limited LOS and reflections, using data corresponding to the very causes of these effects. This, in turn, enables, for each assumed position of a receiver and a group of known satellite positions, better analysis of LOS and NLOS. More importantly, for the latter NLOS signals, this approach enables to analyze the patters of reflected rays and distinguish between: (1) signals that are likely to be captured after one bounce from a building wall; (2) signals that are likely to be captured after two bounces from buildings walls; (3) signals that are not likely to be captured by the receiver, either because they are completely blocked by a building, or require more than two bounces from walls. A notable feature of our signal modeling technique relates to improved detection of two-bounce paths. A two-bounce path is a path that bounces off two walls. We focus on such paths because onebounce paths can be handled relatively efficiently, and signals reaching the receiver after bouncing off more than two walls are too weak. The core enabler of this improvement is the use of a visibility graph of the scene s walls, where the vertices of the graph correspond to the walls, and an edge between two walls represents a potential visibility connection between them. That is, if two walls are joined by an edge in the graph, then there may be a multipath signal containing these two walls and the simulator should consider them when looking for two-bounce paths. Notice that given the models of all buildings in a region of interest (ROI), the visibility graph of the walls needs to be computed only once, durring the preprocessing stage. Therefore, this time-consuming construction phase can be performed in advance and should not inflence the runtime of the algorithm s queries. 3

4 The visibility graph we describe accelerates the simulator s runtime dramatically. This assists to obtain a simulator that performs well in real-time (more details on the simulator s runtime are presented in Section 4). Recently, it has been shown how to compute the visibility graph of a set of walls in an efficient manner [4]. We build on this work and present three steps to partition the walls and their edges in the graph, so that given a query containing a receiver and satellite locations, the simulator narrows the problem and only tests visibility relations for a sub group of edges in the graph. One noteworthy application of our suggested simulator belongs to the field of improving GNSS accuracy in urban regions [2]. The simulator can assist to detect the buildings that cause the multipath, then recompute virtual pseudoranges that take into account the influence of reflections from walls on the signals time of flight (TOF). Thus, errors caused by multipath (e.g., see Figure 1) can be substantially reduced. 1.2 Paper structure The remainder of this paper is organized as follows: In Section 2 we present a detailed discussion of GNSS signal modeling in urban regions. In Section 3, we present our use of visibility graph for reflection modeling. The section also demonstrates our techniques for accelerating the simulation runtime. In Section 4, we conduct a set of experiments to evaluate the effect of the different techniques on the simulation runtime. In Section 5 we conclude and suggest future research directions. 2 GNSS signal modeling In this section we describe our algorithm for simulating GNSS-signals in urban canyons. We distinguish between the preprocessing stage and the queries stage. The input for the preprocessing stage is a scene of buildings. We refer to the buildings as a set of n walls W (a wall is a simple polygon). A query is specified by a satellite location s and a receiver location r. Given such a query, we would like to report all the legal signal paths from the satellite to the receiver. Due to the sensitivity of GNSS receivers, we only care about paths of at most two bounces. A legal signal path should obey the following rule: The angle between the hitting ray and the normal of the wall is equal to the angle between the reflected ray and the same normal. In order to check whether a one-bounce path from the satellite s to the receiver r, which bounces off a certain wall w W, is legal, the algorithm performs the following steps: Let r be the reflection of r behind w and draw a line segment between s and r (see Figure??). Now there are two cases: (i) The line segment connecting r and s does not intersect w (see Figure 2(a)). In this case, a legal path with w does not exist. (ii) The line segment does intersect w. Denote the intersection point by i (see Figure 2(b)). In this case, the legal path is (r, i, s). Notice that computing a path with a certain wall takes constant time, but this is not enough, before reporting the path, we have to make sure that no other wall w W blocks this path (see Figure 2(c)). This can be implemented simply by traversing all the other walls in the scene and checking whether they intersect the path, or more efficiently, by using a ray-shooting data structure [1]. The algorithm for finding two-bounce paths is very similar to the one for one-bounce paths. Here, we want to find paths that bounce off two different walls w 1 and w 2. The difference is that the algorithm performs two reflections (see Figure 2(d)). That is, after reflecting r behind w 1, it reflects r behind w 2, and then the path is (r, i 1, i 2, s), where i 2 is the intersection point 4

5 s. s. s. r.. r w.i r.. r w r. w w (a) (b) (c) of the line segment r s with w 2, and i 1 is the intersection point of r i 2 with w 1. Again, after detecting whether the path is legal, we must check that no other wall blocks it. In order to report all the two-bounce paths, we should perform the above algorithm on each pair of walls in the scene. Notice that the paths (r, w 1, w 2, s) and (r, w 2, w 1, s) are different (see Figure 2(e)). Algorithm 1 summarizes the above description.. s... r w 1 w 2 i 1 i 2 r r (d) w 1 ṣ w 2. r (e) Figure 2: (a) Finding a two-bounce path with the walls w 1 and w 2. (b) The order of the walls matters (the paths (r, w 1, w 2,s) and (r, w 2, w 1,s) are different). Algorithm 1. Reporting two-bounce paths Input: Set of n walls W, receiver r and satellite s. Output: Reporting all two-bounce paths from s to r. 1: for each ordered pair of walls (w 1, w 2 ) W such that w 1 w 2 do end 2: r the reflection point of r behind w 1 3: r the reflection point of r behind w 2 4: i 2 the intersection point of the line segment r s and the wall w 2 5: i 1 the intersection point of the line segment r i 2 and the wall w 1 6: if i 1 = null or i 2 = null then 7: go to Step 1 8: if no other wall in the scene blocks the computed path then 9: report the path (r, i 1, i 2, s) Runtime complexity of Algorithm 1: There are O(n 2 ) ordered pairs of walls. For each pair, we check if there exists a legal path in constant time and then, in Step 8, we check if no 5

6 other wall blocks the path, this takes O(n) time. The total runtime of the algorithm is O(n 3 ). If we implement Step 8 via ray-shooting, without increasing the space complexity which is O(n 2 ), the cost of a ray-shooting query is O( n log n) time, and the total runtime of the algorithm is O(n 2.5 log n). Figure 3: Snapshots of the simulator. We use Google Earth in order to visualize the algorithm. In blue, the direct paths between the receiver and the satellites; in red, one-bounce paths; in green, two-bounce paths. 3 Improving performance via visibility graph Finding two-bounce paths is the bottleneck of the algorithm, it costs O( n 3 ) time compared to O( n 2 ) time for one-bounce paths and to O(n) time for LOS checking (see Figure 4). In this section we present our use of a visibility graph (Section 3.1) and additional techniques (Section 3.2) to accelerate the two-bounce paths detection. Figure 4: Comparing the runtime of one-bounce paths and two-bounce paths (Notice that the graph for one-bounce paths almost coincides with the x -axis). 6

7 3.1 Graph dilution The main goal of graph dilution is to avoid checking visibility for each pair of walls. In a reasonable scene of buildings, most such pairs will never produce legal paths. That is because another wall may block the visibility between them, or because they are too far from one another. Therefore, we preprocess the scene of buildings (i.e., walls) and construct a visibility graph V G = (V, E), where the set of vertices V of the graph is associated with the set of walls W, and the set of edges E represents the pairs of walls that may produce legal paths, and should therefore be considered. The goal is to dilute the graph as much as possible, and by that to reduce the number of checks for each satellite-receiver query. One can think of the basic algorithm (i.e., the naive implementation) presented in Section 2 as using the complete graph, where all the pairs of walls are considered. In the exact visibility graph, there is an edge between two walls if and only if there exist two points, one on each wall, such that the line segment connecting these points does not pass through any other wall in the scene. Computing this graph is very complex. Therefore, the graph we compute is a super-graph of the visibility graph, i.e., it contains edges between walls that cannot produce legal paths, but it does not omit edges. We now present two steps to dilute the graph. Step 1: Connecting potentially-visible walls. We assume that the buildings in the scene are closed shapes (i.e., a signal can bounce off a wall only from its outer side). That means that each wall has a direction, and it divides the world into visible and unvisible half-spaces. If this is not the case, a wall with two directions can be represented by two different walls with one direction each. Definition 3.1. We say that wall w 2 is potentially-visible by wall w 1 if at least part of w 2 is located in w 1 s visible half-space. If (part of) w 2 is located in w 1 s visible half-space, then there is a chance that w 1 sees w 2, i.e., that there exists a line segment connecting w 1 and w 2 without passing through any other wall in the scene. Therefore, we state the following observation. Observation 3.2. If two walls w 1 and w 2 are not potentially-visible to each other, then a legal path cannot pass through these walls (see Figure 5(a)). In view of Observation 3.2, the first step of the graph construction is to draw an edge only between pairs of walls that are potentially-visible to each other. This step reduces the size of the graph and improves the simulation runtime. Observe that the graph contains illegal edges, i.e., edges between walls that will never produce a path (for example, see Figure 5(b)), but this step is very easy to implement and it still eliminates many edges from the graph (see Figure 8). Step 2: Minimum angle assumption. After applying the first step to dilute the graph, we add the assumption that the minimum angle between a satellite signal and the ground is 15. This is a very reasonable assumption because of two reasons. First, most of the GNSS receivers ignore lower satellites (usually 15 in open areas and 30 in urban areas). Second, as the angle in urban areas decreases, the probability to have LOS decreases as well. This assumption allows us to consider only pairs of walls that are close enough to each other, since for a pair of distant walls, a ray of angle 15 (or greater) that hits the first wall at its top, will hit the ground and will not reach the second wall (see Figure 6(a)). Notice that this step produces a directed graph (see Figure 6(b)). 7

8 w 1 w 2 w 3 w 2 w 2 (a) (b) Figure 5: (a) w 2 is potentially-visible by w 1, but not vice versa. Therefore, a legal path cannot pass through these two walls. (b) Assume that w 3 is the highest wall. Then, w 1 and w 2 will never produce a legal path, but the graph still contains an edge between them.. w 1 w 2 w 1 15 w 2 (a) ground (b) ground Figure 6: (a) A ray with an angle of 15 (or greater) that hits w 1 at its top does not reach w 2, therefore (w 1, w 2 ) / E. (b) The angle assumption produces a directed graph: (w 1, w 2 ) E, (w 2, w 1 ) / E. 3.2 Graph partitioning After applying the two steps described in Section 3.1, our graph is much smaller than the complete graph (which is conceptually used by the naive implementation), and therefore the simulator performs more efficiently. In this section we present three steps of partitioning the set of edges remaining in the graph, so that for each query, we consider only some of the edges in the graph depending on the specific locations of r and s, and therefore save even more time. Step 1: Dividing the sky into slices. After applying the second step in Section 3.1, each wall is connected only to walls in its close visibility (relative to the wall s height). This reduces the number of edges dramatically for a reasonable scene. In this step, we take advantage of the fact that GNSS satellites may have a greater angle than 15 with the ground, and therefore we divide the sky into k slices ( k is a parameter, in our experimentations we set k = 5 ), where each slice s i has a unique range of angles, denoted by range i. For each slice s i ( 1 i k ), we construct a corresponding visiblity graph V G i = (V, E i ) as described in Section 3.1 (see Figure 7 for illustration). Observe that if an edge connecting two walls belongs to V G i ( 1 i k ), then it also belongs to V G j ( i j k ). Thus, it holds that V G 1 V G 2... V G k, and the space complexity of this step remains the same. Then, given a query, we find the angle α of the satellite with the ground (i.e., elevation angle), and consider the edges of the graphs V G k, V G k 1,..., V G i, where α range i. Obviously α also depends on the receiver and wall locations, but due to the big distance of the satellites (GNSS satellites orbit at an altitude of approximately 20,200 kilometers), this is negligible. 8

9 V G 1 V G 2 V G 3 V G 4 Figure 7: Dividing the sky into slices. Step 2: Dividing the ground into cells. Given a query, where the receiver is located at some point r, it does not make sense to consider walls from the other side of town. In this step we partition the ground by a regular grid. In each grid cell we store a list of walls that are located (or partially located) in it. In experiments that we have conducted, the last segment (of a multi-path signal) from a wall to the receiver is not longer than 250 meters. Thus, we define the size of a grid cell to be square meters. In addition, we reverse the direction of the edges of the graphs computed in the previous sky slices step, i.e., if the original graph contained an edge (w i, w j ), the new graph will contain the edge (w j, w i ). Then, given a query, we find the grid cell that contains the receiver, and consider only the walls stored in this grid cell and in its adjacent cells. That is, for each wall w i stored in these (at most) nine grid cells and for each wall w j connected to w i in the graph (depending on the elevation angle between the satellite and the ground), we check whether the path (s, w j, w i, r) is legal. In order to prevent multiple reporting of the same signal paths, if a wall is located in more than one grid cell, we divide it to disjoint walls, such that each part of the wall is located in a single grid cell. Dividing the ground into cells makes the number of walls being considered by the algorithm constant, no matter how big the scene is (see Figure 10). Step 3: Walls orientation. At this point, for each satellite-receiver query, the algorithm traverses all the walls stored in (at most) nine grid cells, and for each wall w i it checks only some of its edges in the graph (depending on the elevation angle of the satellite). For each such edge, that connects between w i and some other wall w j, it checks whether the path (s, w j, w i, r) exists (and if so, it reports the path). Observe that if the receiver is not located in w i s visible half-space, then it is unnecessary to check w i s edges, because non of them will yield a legal path for this receiver. Therefore, in this step, when traversing all the walls of a grid cell, we first check whether the receiver is located in the wall s visible half-space, if it is, then we consider its edges, otherwise, we continue to the next wall in the grid cell, and avoid unnecessary checks. Implementing this step saves about 50% of the checks (see Figure 10). Notice that for each query, the algorithm still traverses all the walls in nine grid cells and checks whether the receiver is located in their visible half-spaces. We now suggest how to avoid having to traverse all these walls. The walls we wish to consider are only the walls that contain the receiver in their visible half-spaces. We treat the walls as half-planes. The complexity of the union of n half-planes is linear, therefore, we can preprocess the walls in each grid cell and store them in a data structure of size O(n log n), and perform a point intersection searching (PIS) query in time 9

10 O(log n + k), where k is the number of reported walls [1]. The output of the PIS query is exactly the required walls, so traversing all the walls in a grid cell is not necessary anymore. 3.3 Query description In Section 3.2 we presented three steps to accelerate satellite-receiver queries. We now summarize them and describe how to handle a query. First, find the grid cell that contains the receiver r, and handle this grid cell and each of its adjacent grid cells separately. For each such grid cell, perform a PIS query. The output of the query is the set of walls that the algorithm should consider. For each wall w i, traverse the walls w j connected to w i in the visibility graphs V G 1,..., V G k, where the elevation angle between s and the ground is contained in the range of V G k, and check whether the path (s, w j, w i, r) is legal, i.e., check if tha path exists and if no other wall in the scene blocks it. 4 Experimental results We have conducted a set of experiments to evaluate the effect of the ideas presented in Section 3 on the simulator s runtime. The simulator was developed in C++, and tested on Intel Core i5 CPU, using a 64-bit Windows 7 operating system. As mentioned in Section 3.1, the purpose of the preprocessing is to dilute the visibility graph as much as possible in order to accelerate the simulator s runtime. The table in Figure 8 compares the contribution of the two dilution steps to this goal. The left column shows the number of walls in the scene. Naive implementation is the graph size of the basic algorithm before the dilution steps (i.e., the complete graph). Partially-visible walls is the graph size after applying the first dilution step, and Angle assumption is the graph size after applying the second step. Figure 8: The contribution of the dilution steps to the graph s size. The graph in Figure 9 presents the effects of the dilution steps on the simulator s runtime. Obviously, as the visibility graph contains less edges, the simulator considers less pairs of walls in each query, and so the runtime improves. It can be seen from this graph that the runtime of the simulator after applying the angle assumption step is linear. The explanation for this is that when computing the graph with the angle assumption, we actually connect a wall to walls in its close environment, no matter how big the scene is (of course it depends on the density and height of the buildings). Therefore, if we take a bigger scene, the graph grows linearly, and so does the runtime. The graph in Figure 10 demonstrates the incremental effects of the partitioning steps described in Section 3.2 (i.e., each step is applied after the previous steps have been applied). In the worst case, the sky slicing implementation (Step 1) considers the same pairs of walls as the angle assumption 10

11 Figure 9: Comparing the incremental effects of the dilution steps on the simulator s runtime. (if all the satellites elevation angles are 15 ), but usually the satellites elevation angles are greater than 15 and therefore the sky slicing step considers less edges. If the buildings are uniformly distributed, then the ground cells implementation (Step 2) considers a constant number of walls for each query (walls that are stored in a neighborhood of nine grid cells), and therefore we obtain a constant time per query. It also can be seen from the graph that adding the final walls orientation implementation (Step 3) saves about 50% of the checks compared to this number after Step 2. Figure 10: Comparing the incremental effects of the partitioning steps on the simulator s runtime. 5 Conclusion and Future Work We have proposed a new framework for simulating the reception of GNSS signals in urban canyons. Given an assumed position of a GNSS receiver and known positions of satellites, the proposed algorithm is able to identify LOS/NLOS to each simulated satellite. Moreover, the algorithm is able to identify whether an NLOS signal is: (1) completely blocked by buildings; (2) a multipath signal that is likely to be captured by the receiver after one bounce from a building wall; (3) a 11

12 multipath signal that is likely to be captured by the receiver after two bounces from buildings walls. We have demonstrated that by using a visibility graph and several preprocessing optimization steps, the algorithm s runtime is linear with the number of buildings/walls in the urban canyon. This is important for possible integration of our methodology in GNSS devices that require very quick real-rime queries. The framework s ability to analyze satellite rays derives from the usage of 3D models of buildings. This is a relatively new approach in GNSS research, aiming to address GNSS known difficulties in urban canyons. Because the number of reliable LOS signals is frequently too small in urban canyons, there is a real need to incorporate multipath signals in location computations. Yet, computing pseudoranges from multipath signals, without considering the increase in signals time of flight, caused by one or two bounces from walls, leads to large positioning errors: In the absence of 3D models, GNSS receivers may estimate pseudorange deviations of multipath signals based on signal strength thresholds and other heuristics. It is, however, hard to impossible to track the exact patterns of rays and identify one-bounce and two-bounce paths, without having detailed data concerning obstacles in the receiver s immediate environment. In future work we intend to investigate and test a mechanism for accurate positioning in urban canyons. This goal shall be achieved by correctly compensating for pseudorange errors of multipath signals using the bouncing analysis suggested in this paper. Acknowledgment. The first author wishes to thank Eliyahu Ariel for introducing him to the real world of GPS. 12

13 References [1] P. K. Agarwal. Range searching. In Handbook of Discrete and Computational Geometry, 2nd Edition, J. E. Goodman and J. O Rourke, editors, CRC Press LLC, April [2] B. Ben-Moshe, E. Elkin, H. Levi, and A. Weissman. Improving accuracy of GNSS devices in urban canyons. In CCCG 11, [3] P. Berglez, E. Wasle, J. Seybold, and B. Hofmann-Wellenhof. Gnss constellation and performance simulator for testing and certification. In Proceedings of the 22nd International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS 2009), pages , [4] P. Carmi, E. Friedman, and M. J. Katz. Spiderman graph: Visibility in urban regions. Unpublished manuscript, Apr [5] R. Ercek, P. De Doncker, and F. Grenez. Study of pseudo-range error due to non-line-of-sight-multipath in urban canyons. In 18th International Technical Meeting of the Satellite Division of The Institute of Navigation, Long Beach, CA, USA, pages , [6] C. Fouque, P. Bonnifait, et al. Vehicle localization in urban canyons using geo-referenced data and few gnss satellites. In IFAC Symposium on Intelligent Autonomous Vehicle, [7] S. Gleason and D. Gebre-egiabher. GNSS Applications and Methods [8] S. Godha, M. Petovello, and G. Lachapelle. Performance analysis of mems/imu/hsgps/magnetic sensor integrated system in urban canyons. In Proceedings of the ION GNSS, [9] J. S. Greenfeld. Matching GPS observations to locations on a digital map. In Proceedings of the 81th Annual Meeting of the Transportation Research Board, Washington D. C [10] P. Groves. Shadow matching: A new gnss positioning technique for urban canyons. Journal of Navigation, 64(03): , [11] P. D. Groves. Principles of GNSS, Inertial, and Multisensor Integrated Navigation Systems [12] S. Liu, Z. Shi, M. Zhao, W. Xu, and K. Zhang. An urban map matching algorithm using rough sensor data. Power Electronics and Intelligent Transportation System, Workshop on, 0: , [13] G. D. Macgougan. High sensitivity GPS performance analysis in degraded signal environments. M. Sc. Thesis, UCGE Report No, page 20176, [14] D. Manolakis. Efficient solution and performance analysis of 3-d position estimation by trilateration. Aerospace and Electronic Systems, IEEE Transactions on, 32(4): , [15] A. Olesk and J. Wang. Geometric and error analsysis for 3d map-matching. In IGNSS Symp, [16] B. Peterson, D. Bruckner, and S. Heye. Measuring GPS Signals Indoors, Proceedings of ION GPS-1997, The Institute of Navigation, September, Kansas City, Missouri, USA. pp , [17] M. A. Quddus, W. Y. Ochieng, and R. B. Noland. Integrity of map-matching algorithms. Transportation Research Part C: Emerging Technologies, 14(4): , [18] C. Seynat, A. Kealy, and K. Zhang. A performance analysis of future global navigation satellite systems. Journal of Global Positioning Systems, 3(1-2): , [19] A. Simsky, L. Vander Kuylen, and F. Boon. Single-board attitude determination system based on the polarx2@ gps receiver. In Proceedings of ENC GNSS, page 23, [20] R. Singh, M. Guainazzo, and C. Regazzoni. Location determination using wlan in conjunction with gps network (global positioning system). In Vehicular Technology Conference, VTC 2004-Spring IEEE 59th, volume 5, pages IEEE,

14 [21] S. Syed. University of calgary development of map aided gps algorithms for vehicle navigation in urban canyons, [22] E. Timofeev and G. Tsekhanovich. Ins simulator for debugging ins/gnss data. Aerospace and Electronic Systems Magazine, IEEE, 24(1):38 40, [23] C. E. White, D. Bernstein, and A. L. Kornhauser. Some map matching algorithms for personal navigation assistants. Transportation Research Part C: Emerging Technologies, 8(1-6):91 108, [24] Y. Zhang and Y. Gao. A fuzzy logic map matching algorithm. Fuzzy Systems and Knowledge Discovery, Fourth International Conference on, 3: , [25] L. Zhao, W. Y. Ochieng, M. A. Quddus, Noland, and R. B. An Extended Kalman Filter algorithm for Integrating GPS and low-cost Dead reckoning system data for vehicle performance and emissions monitoring. The Journal of Navigation, 56: ,