Setting a New Standard: Assisting GNSS Receivers That Use Wireless Networks
Receiver manufacturers and mobile phone designers face a plethora of wireless and GNSS standards in their efforts to build user equipment that employs telecommunciations networks to improve positioning accuracy and speed. As a result, telecom engineers are proposing a single, common standard for A-GNSS.
An evolution in GNSS is making new satellite systems and signals available for open-service users. This evolution offers new opportunities to improve the performance of location-based services in mobile terminals by using the increased availability and accuracy of the positioning services.
As the Global Positioning System adds signals and GPS satellites get more company in space, the wireless/cellular standards currently supporting only L1 GPS (assisted-GPS or A-GPS) need to be adapted to reflect changes in the satellite constellations as well as recent innovations and advances in receiver and wireless infrastructure technologies.
Instead of assisting only L1 GPS-receivers over wireless networks, the assistance data service must be extended to a variety of GNSSes. This means working with A-GNSS (Assisted GNSS) instead of A-GPS in the future.
The need for A-GNSS augmentations is steadily approaching as GLONASS and GPS modernizations are proceeding at a fast pace and Galileo deployment starts in the coming years. Together, these developments will multiply the number of satellites and signals available for open-service positioning in the near future.
One should also not forget the deployment of Japan’s Quasi Zenith Satellite System (QZSS), India’s GPS-Aided Geo-Augmented Navigation (GAGAN) system, and various other satellite-based augmentation systems planned towards the end of this decade. Moreover, the recent development in local area augmentation systems (LAAS) could bring GNSS even indoors in the form of GNSS-like pseudolite signals.
If the schedules and plans for the GNSS evolution do not significantly change in near future, L1 A-GPS alone clearly will no longer be sufficient from 2009–2010 onwards.
Development of A-GNSS also enables a face-lift of A-GPS technology by incorporating the latest advances in GNSS receiver and wireless infrastructure technologies. This will allow for a totally new class of applications providing high accuracy, superior availability, and seamless hybrid use of GNSSes and/or terrestrial wireless networks on a global scale.
It seems to us that copy-pasting GNSS Interface Control Documents (ICDs) into cellular standards, similar to the A-GPS concept, may not be the best way to introduce A-GNSS. Instead, the full potential of GNSS could be introduced by novel approaches leaning on increased bandwidths of the near-future radio interfaces and external GNSS monitoring and tracking networks such as the International GNSS Service (IGS). This article explores these possibilities and advances in the context of wireless networks and mobile terminals.
Current Work Towards A-GNSS
These work items have concerned modifying Radio Resource LCS Protocol (RRLP) and Radio Resource Control (RRC) defined for the Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) A-GPS protocols, respectively. Moreover, the Open Mobile Alliance (OMA) forum has work items to modify the Secure User Plane Location (SUPL) Service to add the support for A-GNSS.
The most initiative and activity have come in 3GPP GSM/EDGE Radio-Access Network (GERAN) meetings, where several proposals towards A-GNSS have been presented and discussed. Currently, 3GPP GERAN aims to extend the scope of the work from A-Galileo-only additions towards a more general A-GNSS concept. The group has recognized that A-Galileo–only additions will no longer suffice as other new GNSS signals and services will become available along with the full deployment of the Galileo constellation.
Exploiting the Full Capability of A-GNSS
Extending the lifespan of assistance data. The typical environment for A-GNSS terminals is an urban or indoor area where positioning and navigation needs to be carried out under signal blocking, high signal attenuation, and multipath conditions. High-sensitivity and hybrid uses of GNSS satellites are, therefore, important aspects to enable navigation, time determination, and RAIM from a rather scarce number of satellites and signals.
This means that, in order to operate and maximize the performance under these harsh conditions, the terminals should either have a continuous access to assistance data service or the terminals should have the assistance data already in memory. As the former might sometimes be either limited or unavailable, extension of the lifespan or persistence of the assistance data in the terminals becomes an important consideration, especially for navigation.
Various ways exist to extend the usable lifetime of the assistance data. One of the most promising is long-term orbit (LTO) data for satellite orbit and clock models that could be provided to terminals for full constellations even for several days ahead.
As the GNSS evolution brings along better and more stable satellite clocks, the performance of LTO data will become better in the near future as the satellite clock drifts can be predicted more reliably. (For further discussion of this subject, see the article by David Lundgren and Frank van Diggelen cited in the “Additional Resources” section at the end of this article.)
Maximizing sensitivity in asynchronous networks. Sensitivity depends directly upon the accuracy of the reference time in the terminals.
Naturally, sensitivity is also a function of reference frequency, initial position, and ephemeris, but these elements are typically available either from the terminal itself of from network assistance. For example, coarse location based on the cell ID and ephemeris data from a reference receiver are typical elements of any GPS assistance data protocol.
Accurate time assistance requires either a synchronized network (such as CDMA cellular telephone systems) or deployment of network time-measuring elements to calculate the time differences between the cellular base stations and GNSS (read GPS) system time. The latter is specifically for asynchronous networks such as GSM and UMTS.
Assuming accurate time assistance, the signal search window in the code phase domain can be reduced even down to a few GPS chips (fewer than 10 chips) in typical urban conditions. The sensitivity is improved not only by the possibility of performing coherent integration over the full GPS bit (20 milliseconds) but also by minimizing the probability of false alarms.
Naturally, time to first fix (TTFF) and power consumption will also be minimized, as the fix can be calculated as quickly as possible without the need to carry out exhaustive, full code domain signal searches.
GNSS evolution will open the door for even higher levels of sensitivity by bringing a wide range of pilot signals for open service users. Coherent signal integration can be prolonged to well more than 20 milliseconds, extending the coverage of A-GNSS positioning services beyond that of A-GPS service.
However, accurate time is still needed. The maximum benefit of the new pilot signals will be gained by having reference time accurate within a few microseconds. Nonetheless, reference time accurate within few hundred microseconds will still prove useful for predicting phases of possible secondary codes while keeping the size and cost of the search engine hardware within reasonable limits.
If accurate reference time is not directly available from the network, indirect methods can make use of the network to ensure precise timing. Even though a network is not synchronized, the cellular signals (cellular base stations) typically have very good frequency stabilities that can be employed in the terminals to maintain the relation between GPS/GNSS and cellular system times.
A-GNSS can also come to aid the terminals in this area, for example, by enabling transmission and delivery of GNSS-cellular system time differences from the serving base stations and even from neighboring stations in the form of observed time difference measurements.
Further, time relations and measurements from multiple mobile terminals can be gathered in network servers to improve the accuracy and quality of the measurements transmitted back to terminals. This data helps the terminals to maintain timing relationships accurately during handovers and sleep periods.
Face-lifts. Modern GPS receivers not only track the code, but also the carrier phase. However, carrier phase measurements are not included as such in any A-GPS.
The applications of carrier phase measurements are naturally in the RTK area (see the article by K. Alanen et al in the May/June issue of Inside GNSS).
They also appear in accurate terminal velocity calculations and in precise point positioning (PPP). PPP would improve the standalone positioning accuracy to less than one meter assuming proper assistance data. However, the introduction of PPP evidently requires more than just carrier phase measurements to be available in the network assistance.
Additional assistance elements include Earth orientation parameters (EOP) as well as accurate ionosphere and satellite orbit models. All of these elements are pieces of information that either exist today or are included in the near-future GNSS evolution.
Moreover, although there are bandwidth limitations in today’s radio interfaces, the coming Orthogonal Frequency Division Multiplexing (OFDM) radio interfaces (WiMAX, 3.9G) are capable of delivering high-accuracy satellite orbit data on a frequent basis.
Seamless Use of Assistance Data
In order to achieve this, the format, content, quality and applicability of assistance data needs to be the same regardless of the carrier medium. In fact, one of the greatest current risks is the divergence of A-GNSS implementations. The variety of A-GPS standards is already becoming a challenge for multi-mode terminals needing to support multiple A-GPS implementations, not to mention the issues with interworking and interoperability.
Last, but not the least aspect is the question of backwards compatibility, which has to be maintained so as not to jeopardize the functioning of existing implementations in the future. This almost inevitably leads to a conclusion that the current A-GPS implementation should not be touched and that the A-GNSS is best accomplished as a totally new concept.
This road could also lead to a convergence of A-GNSS standards instead of increasing the complexity and number of assistance data standards by upgrading individually the existing A-GPS standards in different systems at different times into the A-GNSS standard.
A-GNSS Assistance Data Structure
Common assistance data elements. The information elements that are the same regardless of the GNSS include:
• reference time – common system time from wireless network
Any of these data elements are needed whether one or several GNSSes are included in the assistance data, and the data can be applied on any GNSS. An example of this is the troposphere model that can be applied to any GNSS signal. Notably, these elements can be derived or obtained from a variety of sources, including GNSS broadcasts as well as external (commercial) services.
Common system time. One of the challenges in A-GNSS is the reference time. Surely, one possibility would be to include all GNSS-specific system times into A-GNSS. However, this approach not only leads to complexity in implementation due to differences in the terminal and network capabilities supporting various GNSS, but it would also mean rather poor future compatibility with any new GNSS.
One very promising approach for A-GNSS reference time was introduced in in the article by Alexandre Mourdrak et al cited in Additional Resources. That article proposed a common GNSS system time for A-GNSS.
In the suggested approach, the reference time base is changed from a GNSS (read GPS)-specific timing to a Universal Coordinated Time (UTC) base that acts as a virtual time reference convertible to any GNSS-specific time using the UTC-GNSS time relations provided in the reference time–assistance element. Natural benefits of a common system time include:
1) only one time base in assistance data and response messages
Use of a common UTC-based time has one drawback, namely leap seconds. Therefore, in order to keep the system time continuous over the leap second occurrences the following approach could be taken:
• GNSS-specific UTC leap second counts are frozen to the values at January 1, 2006.
In this manner terminals would be capable of maintaining accurate track of the UTC time based on any GNSS time for PPS generation and, for instance, for NMEA messages.
Generic assistance data elements. An A-GNSS standard will also need to carry GNSS-specific elements. Due to the nature of the technology, however,
GNSSes are very similar in some respects. For instance, measurements such as code and carrier phase data available in different systems are the same. This characteristic enables the introduction of generic assistance data elements.
Generic data formats can be applied from system to system and, therefore, reduce the implementation complexity. These elements should include at least the following:
• differential corrections
The most interesting element here is the ephemeris and clock models. GNSS-es share a lot of commonalities here (see, for instance, the GPS and Galileo ICDs), which automatically suggests a generic format that could be applied to any GNSS.
The generic ephemeris and clock model format brings along a very interesting and tempting possibility of using non-native parameter formats for GNSS-es. For example, the Keplerian parameter representation typically employed by GPS could be used for GLONASS when providing LTO data to GLONASS-capable terminals.
The possibility of mixing the formats would allow an A-GNSS standard to equalize the satellite position information across the different GNSSes. It also would make the lifetime of the data elements the same, further simplifying the implementation. Figure 3 illustrates the structure of the proposed A-GNSS approach for the downlink of assistance data and Figure 4, a generic structure for the measurement and position information response suitable for any specific or combination of GNSSes. (To view figures and graphs, download the PDF version, above.)
Native data support. Despite the generic approach, the ephemeris and clock models can be constructed so that the native data parameters can be carried in the messages without any loss of data or precision. This is an important aspect for A-GNSS server implementations, where the assistance data may be derived directly from the satellite broadcast without any LTO processing.
Scalability. The limitations of radio channels in terms of bandwidth and latency vary greatly from network to network, which needs to be taken into account in data formats. For example, the GERAN control plane channel cannot be used to deliver large amounts of ephemeris data in a reasonable amount of time due to bandwidth limitations.
On the other hand, a broadband 3G high speed data packet access (HSDPA) connection can carry ephemeris data for full GNSS constellations in virtually no time. Regardless of the data volume, the most important aspect is to have the same format in all cases and to design scalable assistance data information elements (IEs).
The Way Forward
The natural way forward is a solution supporting seamless hybrid use of any GNSS and wireless network. The solution must also be as future-proof as possible, scalable and addressing all the GNSSes equally. This means that the GNSSes have to be addressed as a whole, not as single, separate systems.
As the data elements are made common and generic, it is equally important to also make them, as much as possible, system- and carrier-independent. This particularly applies when considering the hybrid use of more than one GNSS, because the assistance data quality and the performance of the GNSS signals can now be truly balanced for the first time.
For figures, graphs, and images, please download the PDF of the article, above.
Jari Syrjärinne received his M.Sc. and his Ph.D. from Tampere University of Technology, Finland, majoring in digital signal processing and applied mathematics. Between 1996 and 1998 he worked for the Tampere University of Technology Signal Processing Laboratory in the areas of data fusion and target tracking, and since 1999 he has been with Nokia Inc. He is currently involved in work on A-GNSS and hybrid positioning.
Lauri Wirola received his M.Sc. degree from Tampere University of Technology, Finland, with a major in electrophysics. Since 2005 he has been working on navigation issues with Nokia Technology Platforms. His present research interests include RTK and A-GNSS standardization. He is currently undertaking postgraduate studies in modern electromagnetism and mathematics.
Copyright © 2017 Gibbons Media & Research LLC, all rights reserved.