Inside GNSS: Engineering Solutions from the Global Navigation Satellite System Community
GPS Galileo Glonass BeiDou Regional/Augmentation
Inside Unmanned Systems
Thought Leadership Series

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.

Share via: SlashdotSlashdot   TechnoratiTechnorati   Setting a New Standard: Assisting GNSS Receivers That Use Wireless Networks (Inside GNSS)TwitterTwitter   FacebookFacebook

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
During the past three years new work items to add A-GNSS functionality to cellular assistance data have been approved and launched in Third Generation Partnership Project (3GPP) standardization bodies.

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
The main benefit of A-GNSS should not merely be an increased number of satellites available to GNSS-capable wireless terminals. Instead, A-GNSS should be an enabler for technologies and services that will make it possible to exploit the full potential of GNSS. A well-formulated A-GNSS standard could help extend GNSS service into new applications and operating environments, especially, to the applications and use scenarios that were not seriously considered 10 years ago for A-GPS.

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
Arguably an optimal and future-proof A-GNSS solution can only be achieved by creating a generic, scalable, and flexible assistance data format that not only fits all the existing or soon-to-be-deployed GNSSes but also has reservations for coming systems. Moreover, the planned tangible performance improvements compared to A-GPS ensure fast deployment.

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
The assistance data elements may be divided in two categories based upon whether they are GNSS-independent or GNSS-specific. GNSS-independent elements are called common elements, which are summarized below.

Common assistance data elements. The information elements that are the same regardless of the GNSS include:

•    reference time –  common system time from wireless network
•    reference location – initial location of the receivers
•    atmosphere models – troposphere and ionosphere models for atmosphere error correction
•    base station/access point timing models
•    Earth orientation parameters

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
2)    PPS generation from any GNSS or combination of GNSSes, which is important to maintain reference time in the terminal and to synchronize wireless terminals with a common time
3)    seamless hybrid use of GNSS as per the article by Moudrak et al
4)    ease in adding new GNSS and time bases
5)    UTC will be available for terminal resident LBS and time-based applications such as validation and timing of financial transactions.

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.
•    The reference time information element in the assistance data has two parameters for the leap seconds that occur after January 1, 2006: one that indicates the current number of leap seconds since January 1, 2006 and another that indicates the next occurrence of the UTC leap second. (Terminals would increment the number of leap seconds by one, when the next leap second occurs.)

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
•    real-time integrity
•    data bit assistance
•    subframes and so forth to enable receiver processing techniques such as data wipe-off
•    reference measurements — code and carrier phase measurements from a reference station for high-accuracy positioning
•    GNSS – common system time relationship
•    almanac models
•    ephemeris and clock models (Note that the utilization of LTO models makes almanacs unnecessary.)
•    satellite clock and orbit data in a suitable format.

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
In formulating an A-GNSS standard, we need to have an open-minded approach to ensure that the principles and features selected will exploit the full potential of the future GNSS signals, services, and wireless networks, not forgetting the growing terminals capabilities.

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.

Additional Resources
[1] Averin, Sergey V., “GLONASS System: Present Day and Prospective Status and Performance,” European Navigation Conference GNSS-2006, Manchester, UK, May 7-10, 2006.  
[2] Lundgren, David, and Frank van Diggelen, “Assistance When There’s No Assistance,” GPS World, October 2005, pages 32-36.
[3] Moudrak, A., and A. Konovaltsev,  J. Furthner,  J. Hammesfahr,  P. Defraigne,  A. Bauch,  S. Bedrich, and  Arno Schroth, “Interoperability on Time,” GPS World, March 2005.
[4] “Background for starting a new Study Item “LCS Evolution,” GP-061463, 3GPP TSG-GERAN Meeting #30, Lisbon, Portugal, 26-30 June, 2006.
[5] ICD-GPS-200, Revision D, Navstar GPS Space Segment/Navigation User Interfaces, December 7, 2004.
[6] ICD-GPS-800, Draft, Navstar GPS Space Segment/User Segment L1C Interfaces, April 19, 2006.

Author Profiles

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 © 2018 Gibbons Media & Research LLC, all rights reserved.

Jammer Dectector
globe Copyright © Inside GNSS Media & Research LLC. All rights reserved.
157 Broad Street, Suite 318 | Red Bank, New Jersey USA 07701
Telephone (732) 741-1964

Problems viewing this page? Contact our webmaster.