Category: SBAS

Using the Augmentation System with GPS-Equipped Mobile Phones

By François Boullete, Boris Kennes, Michaël Mastier, and Lee Banfield

GPS corrections from the European Geostationary Navigation Overlay Service can improve the positioning accuracy and user experience of GPS-enabled mobile phones, even if EGNOS satellites are not visible and even when the GNSS chipset in the phone does not support satellite-based augmentation systems.

Today, more than 20 percent of mobile phones in use in Europe include a GNSS chipset, and the penetration is expected to exceed 50 percent in the next 5 years. Despite its success in other sectors such as agriculture since the launch of its Open Service in October 2009,

EGNOS has received limited adoption in location-based services (LBS) and consumer applications, due to two main obstacles. First, the signals from the three EGNOS geostationary satellites that are easily received in open-sky environments are difficult to receive in cities, due to masking by buildings. Second, most GNSS chipsets embedded in today’s mobile phones are GPS-only without SBAS support, or use SBAS for ranging only, a function not supported by EGNOS at this stage.

The European GNSS Agency (GSA) and the European Commission (EC) supported the work described here to provide mobile phone operating system and application developers with a library of functions to allow them to benefit from EGNOS in all their applications. It works by receiving correction data via mobile communication networks when EGNOS satellites are not visible to the user device and even when using a standard GPS chipset, overcoming these two main obstacles for adoption.

Targeted mobile operating systems now include Nokia Maemo, Google Android, and Microsoft WinMobile. Further work will extend to this list to other compatible platforms.

This article demonstrates the feasibility and shows the performance of a software-based EGNOS solution and seeks to create awareness among mobile operating system and application developers on EGNOS.

User Benefits and Constraints

Although the sources of GPS positioning errors in urban areas are mainly due to multipath and GPS satellites availability, SBAS corrections on GPS satellites clocks and orbits and ionospheric correction model can still add value in case of moderate multipath environment characteristics. Although GPS stand-alone accuracy is nowadays generally sufficient, it is expected to degrade in the next couple of years as solar activity increases. Availability of free EGNOS corrections delivered via the mobile communication network will help maintain accuracy during these high solar activity periods.

The limited visibility of EGNOS satellites in urban areas requires the use of the mobile communication network to retrieve the EGNOS corrections. This can be perceived at the first sight as a drawback to the proposed solution as it involves communication costs. However, the required bandwidth is negligible compared to today’s mobile applications such as music and video streaming; further, mobile operators increasingly offer smartphones with unlimited data-access packages.

Implementation Overview

Implementation of EGNOS in current-generation mobile phones requires the introduction of a new library of functions at the software level that will allow application developers to get the best possible accuracy in their application regardless of the underlying algorithms used for position calculation. Such a library of functions can eventually be integrated directly in the application programming interface (API) of the phone operation system. At this point, application developers will simply request a position using the API, and the API will return the EGNOS improved position.

The main computations performed by this EGNOS library (see Figure 1) can be summarized as:

• Reception: the GPS user position, satellites used, and their elevations and azimuths in NMEA format are requested to the phone’s GPS chipset, and the EGNOS correction message and Klobuchar ionospheric model parameters are received from a distant server (for example, EGNOS Data Access Service EDAS) using the communication link available at the mobile phone;
• Preparation: collected input data are decoded and prepared for next step;
• Calculation: the new position corrected by EGNOS is calculated by re-creating the line-of-sight or design matrix (using user position and satellite geometry), applying the EGNOS fast, long-term (including clock), and ionospheric corrections (included in the EGNOS message) and subtracting the Klobuchar ionospheric correction that was (assumed to be) applied at chipset level;
• Output: the EGNOS corrected position is encoded in NMEA format and returned to the application.

Data Access via the Internet

The EGNOS correction message and Klobuchar ionospheric model parameters are requested by the mobile phone to a distant server. Although the parameters and ephemeris data are stored on the phone’s GPS chipset once it has decoded the messages from GPS satellites, this data is not made available to other phone applications, hence the need to recover it from a remote source. Today, two alternative servers are available: the EGNOS Data Access Server (EDAS) developed by the EC and Signal-in-Space through the Internet (SISNeT) developed by the European Space Agency (ESA).

SISNeT’s advantage is the simplicity of the message (hundreds of bits per second) and the availability of specific functions that allow requesting all the necessary data for our application. However, SISNeT messages are produced from EGNOS signals in space, not from the ground segment: an EGNOS receiver installed at ESA’s ESTEC center receives the signals, demodulates them, extracts the correction message, and re-broadcasts it via the Internet. The reliability and availability of this approach depend upon the good reception of EGNOS signals at this site. Interference or EGNOS broadcast failure could disrupt service.

Unlike SISNeT, EDAS takes the EGNOS correction message directly from the EGNOS system, which guarantees higher service reliability and availability. Nevertheless, the EDAS message is complex and contains much more than the data required for the present application (hundreds of kilobits per second). Therefore a direct connection to EDAS would be inadequate. As a result an EDAS proxy needs to be interfaced between the EDAS server and the mobile platform in order to filter the data flow and extract only the required data. This proxy provides the same kind of messages and functions as SISNeT, whose specifications are ideal for such an application, however it is using data directly from the EGNOS system and not from EGNOS signals in space, improving reliability. In addition, planned EDAS improvements include the provision of such a simplified service directly from the server, removing the need for a proxy.

Independently of the data server used, the mobile platform must retrieve the EGNOS correction messages, and the Klobuchar ionospheric model parameters. The correction message is composed of a number of different message types (MT) as defined in the SBAS standard established by the International Civil Aviation Organization. For our application, the most important messages are:

• MT1, the PRN mask that shows to which satellites (PRN) the data contained in the other, subsequent messages are related;
• MT2-5, containing data to correct rapid variations in the ephemeris and clock errors of the GPS satellites. The important bits for us in these messages are the fast corrections for each satellite used to calculate the user position;
• MT25, with data to correct long-term vari
  ations in the ephemeris errors and clock errors of the GPS satellites;
• MT18, the ionospheric grid points (IGP) mask that associates ionospheric corrections in MT26 with the IGPs to which they relate;
• MT26, providing data to compute the ionospheric corrections for the IGPs present in the IGP mask. In particular it contains the grid ionospheric vertical delay.

The eight Klobuchar ionospheric model parameters must also be obtained from the distant server (using, for example, the GPS_IONO request with SISNeT).

Corrections from GNSS Chipset

The correction algorithm on the phone takes the original position provided by GNSS chipset and identifies the GPS satellite measurements which were used in this computation. It then determines a pseudorange correction for each of the GPS satellites used, and using knowledge of the user-satellite geometry, translates these to a combined position-domain correction.

Most mobile phones’ operating systems allow access to the NMEA sentences from the GNSS chipset using native API functions, for example, onNmeaReceived() with Google’s Android. In order to apply the EGNOS correction algorithms developed in this paper, the minimum required NMEA sentences are GGA, GSA, and GSV.

To construct pseudorange corrections, the Design matrix containing of line-of-sight vectors to the satellites is reconstructed using the elevation and azimuth data. All EGNOS corrections for the satellite orbit and clock errors and the ionospheric delay are applied in this range domain. The algorithm assumes that the Klobuchar model will have been applied to correct for the ionospheric delay in the original GNSS chipset positioning solution. Therefore it provides an adjustment to this original correction to exploit the greater accuracy of the EGNOS ionospheric data. Finally these range corrections are propagated into the position domain using the Design matrix. This provides a 3-dimensional position shift to apply to the original chipset position.

Implementation with Google’s Android

To obtain NMEA strings from an Android phone requires the ‘onNmeaReceived’ function, a function of the LocationManager class. The LocationManager uses the function ‘requestLocationUpdates’ to get a continuous update of the position input, which in this case is GPS. To implement the LocationManager, a LocationListener must be implemented either by the current activity or as a variable. The ‘onNmeaRecieved’ function will be called every second from the instant the Android’s GPS is switched on. The function provides the NMEA strings with a timestamp using the phone internal clock. This timestamp is not derived from GPS and should be used only for logging.

The HTC Legend produces the $GPGSV, $GPGGA and $GPGSA messages that are needed for the application. The Legend also produces $GPRMC and $GPVTG strings. The $GPGSV provides the elevations and azimuths needed for the algorithm, the $GPGGA provides the time, original position and number of satellites in the fix and the $GPGSA provide the PRN numbers of the satellites used in the fix.

For the present testing, necessary data are received via a TCP/IP connection to the SISNeT server (the EDAS proxy server described previously can be used in exactly the same way). For a snapshot solution a continuous connection is not needed and all the information is collected via ‘GETMSG’ and ‘GPS_IONO’ calls. ‘GETMSG’ calls get the last of a specific message type going back up to 30 messages. The types 0,1,2,3,4,5,18,24 and 26 were needed to provide the information for the position domain correction matrices. Only the last message types 0,1,2,3,3,4,5 were needed with type 18 needing 4 and many more of type 24 and 26.

The ‘GPS_IONO’ message gets the current Klobuchar values. By asking for all of the specific message types, almost instantly all the information is gained without having to wait for the 3 minutes Ionospheric grid cycle (message types 18 and 26) and the variable speed, dependant on number of satellites, complete slow correction set. Once the data has been downloaded from the server the connection is closed.

A streamed input could be used with the above approach by continuing to receive data after the initial connection and not closing the connection until the application using the service requested. This would require a continuous stable connection to a high speed mobile network and a limited use of the internet from other applications. As mobile technology improves this will not be a problem but is difficult to achieve with GPRS and 3G networks at present.

Figure 2 shows the current application running on the HTC Legend phone with corrected positions displayed alongside the original GPS positions.

Test Results

Before testing the implementation of the concept on a mobile platform, some initial tests were performed on an offline basis in order to assess the impact of the position correction and verify the approach. This was achieved through the use of 30s data recorded at continuously operating IGS reference stations, freely available over the internet. The data was processed using an in-house PVT engine designed to be representative of LBS implementations, in order to produce stand-alone and conventional EGNOS solutions. The algorithm described in this paper was then applied to the stand-alone solutions, after downloading EGNOS data from ESA’s EGNOS Message Server (EMS) which allows access to past broadcast messages, to produce a third set of solutions. The accuracy of each solution set was then computed based on the precise coordinates of the reference station made available by the IGS. Whilst this approach replicates the mobile phone correction algorithm it should be noted that there is less uncertainty involved in this offline approach as we can ensure that the assumptions made regarding the original PVT solution are valid. We must assume that the phone chipset PVT is a snapshot solution (no filtering) using the Klobuchar ionospheric model and an elevation-dependent weighting scheme.

The plots from Figures 3, 4, and 5 show the errors in position estimates obtained from a 24-hour dataset recorded at the HUEG IGS station in Huegelheim, Germany on May 5, 2010. Table 1 shows the statistics associated with the figures.

The results demonstrate that the conventional EGNOS solution improves the horizontal positioning performance of GPS, with an improvement in the 95th percentile of around 2 meters in this example. Importantly, it can be seen that the position domain EGNOS algorithm achieves a similar level of performance to conventional EGNOS. This can be seen more clearly by comparing the instantaneous horizontal error over this period from the three alternative solutions, as shown in Figure 6. It is clear that the position-domain EGNOS correction shown in yellow reduces the horizontal error of the GPS solution (red) in a similar way to conventional EGNOS (blue).

Similar behavior was found in other datasets tested. With the ability of the algorithm to replicate conventional EGNOS performance verified, we assessed the performance when integrated on an HTC Legend phone. The key differences here were the real-time connection to the EGNOS data server and the uncertainty in the assumptions made regarding the chipset positioning algorithm.

Testing began by assessing the performance of the application over a static point. Two precisely surveyed points were used for this purpose at four separate time periods. The test method simply involved holding the phone over the point (vertical accuracy was not assessed) and requesting a corrected solution from the application, along with the original GPS chipset solution. The chipset applies stand-still detection to avoid generating multiple GPS positions for a single user location which would be unnecessary in typical phone applications. To generate a sample of position estimates therefore the phone was repeatedly moved away from the reference point then returned to it over the test period. This makes the collection of very large datasets over extended periods impractical. The samples from the four test periods were combined in order to generate results with greater statistical significance. 261 samples were collected to produce the results shown in Figures 7 and 8, and the statistics in Table 2.

The results indicate a small improvement in horizontal accuracy as a result of the position domain EGNOS correction. The statistical significance of these results is perhaps questionable given the limitations of the test method and relative small sample size. The reduced level of improvement compared to the offline tests is thought to be due to imperfect assumptions made about the chipset positioning algorithm. The correction algorithm must make many assumptions about the way in which the original GPS position has been computed by the phone chipset. These include assumptions on the measurement weightings used, an assumption that a filtered solution is not applied, assumptions that no additional sensors or systems (accelerometers, digital compass or cellular positioning) influence the computed position, and also assumptions that all information reported in the NMEA strings is accurate. Further work seeks to determine if the algorithm can be improved to better replicate the processes applied in the initial GPS solution in order to make a more significant improvement.

The phone GPS positioning achieves similar levels of accuracy to processing single-frequency data collected at an IGS station. This level of accuracy would be more than adequate for most LBS applications in which the main requirement is to be able to reliably relate a user location to a map or imagery feature. With increasing solar activity over the next few years, leading to larger ionospheric delays on satellite signals, the performance of standard GPS solutions will degrade, making the benefits of the more accurate and timely EGNOS corrections more significant.

Conclusions and Way Forward

By a relatively simple translation method, EGNOS data may be mapped into the position domain, allowing a user position solution to be corrected for signal-in-space (satellite orbit and clock) and ionospheric errors detected and predicted by EGNOS. User position solution provided by the phone chipset may be corrected in near-real time based on data downloaded from a distant server.

The method replicates conventional EGNOS performance (corrections applied at the pseudorange level) when all assumptions regarding the stand-alone GPS user position are valid. Ongoing work seeks to determine if the correction algorithm can be enhanced to provide a greater level of improvement to GPS positions on the phone platform. Ideally, it should be able to provide improvements similar to those produced when EGNOS data is applied in a conventional manner in the position solution. Developers would need to judge the significance of any potential improvement for their intended application.

The EC has launched a project to port this EGNOS library to other mobile platforms and complement it with additional functions that are needed by the application developers and that can bring user benefits. The software library can be obtained free upon request to [email protected].

Acknowledgments

Special thanks to Nottingham Scientific Ltd. for its work on this topic and cooperation in preparing this paper. This article is based on a paper presented at ION-GNSS 2010.

François Boullete was market development officer at the European GNSS Agency at the time of this work. He holds a diploma in project management from HEC and a diploma in engineering from Ecole Centrale.

Boris Kennes is R&D and market monitoring officer at the European GNSS Agency. He has a background in engineering and strategy consulting.

Michaël Mastier is policy officer at the European Commission in the Galileo/EGNOS applications unit. He has an engineering education and diploma in public works from ENTPE in Lyon, and a computer science post-graduate diploma from Saint-Etienne University, France.

Lee Banfield is a software engineer at Nottingham Scientific Limited (NSL) in the UK. He has developed applications which use EDAS data to provide EGNOS corrections, GNSS assistance messages and GNSS performance metrics for a range of road and LBS applications.