Augmentation of low-cost GPS receivers

There are numerous types of GPS receivers in the current international marketplace, ranging from inexpensive, low accuracy handheld devices to expensive, high precision geodetic equipment. By and large, low–cost GPS receivers (whether sold as a plug– in hardware device or as a complete navigation and positioning receiver) have almost assumed mass market status in the consumer electronics industry. Recent advances in micro and wireless technology, reductions in consumer costs, and the apparent growth of the Location Based Services (LBS) industry have somewhat fuelled the need for mobile (information communications and technology) consumers to become “location aware”.

Notwithstanding current levels of maturity in GPS hardware and algorithms, low-cost GPS receivers still suffer from large positioning errors mainly attributable to atmospheric effects, broadcast ephemeris errors, multipath and receiver noise. As a result, they have a limited use in real time applications despite being able to produce positioning and navigation information almost instantaneously. When higher levels of precision and accuracy are required, some form of correction or augmentation must be applied so as to reduce the influence of random and systematic errors on the autonomous positioning solution.

There are a host of augmentation options, in general, that are available for minimising the influence of random and systematic errors in GPS positioning. These include Local Area Augmentation Systems (DGPS, VRS, Network RTK, Pseudolites, US LAAS); Wide Area Augmentation Systems (EGNOS, MSAS, US WAAS, GAGAN); integrated positioning and navigation sensors (gyro, precise clocks, INS, digital compass); various correction algorithms (integrity monitoring, noise filtering, atmospheric modelling, code– carrier phase smoothing, multipath detection); and in the foreseeable future, integrated satellite systems (GPS, Galileo, GLONASS, QZSS). To improve the accuracy of low–cost GPS receivers, the most practicable form of augmentation is via DGPS corrections obtained either from a local broadcasting service or from a nearby reference station. Historically, local area DGPS corrections have been provided through the RTCM protocol over the conventional means of radio transmission.

In recent times, research and development has seen the implementation and analysis of real time Internet based DGPS systems. For instance, the German Federal Agency for Cartography and Geodesy (BKG) together with other partners have developed a dissemination standard called Networked Transport of RTCM via Internet Protocol (NTRIP) for the real time streaming of DGPS or RTK corrections to mobile receivers (Lenz, 2004). Similarly, the Jet Propulsion Laboratory (JPL) has developed a Global Differential GPS (IGDG) system, which facilitates the exchange of corrections to the orbits and clocks of the GPS constellation over the Internet (Muellerschoen et al, 2002). These two developments, together with other independent tests (Gao et al, 2002, Kechine et al, 2003, for example) show that the Internet is able to provide satisfactory levels of accuracy and latency in the dissemination of GPS augmentation information.

In all cases mentioned, the dissemination of corrections is provided over the Internet via constant streaming of data. The purpose of this paper is to examine the XML Web services architecture as an alternative mechanism for exchanging DGPS augmentation information between Continuously Operating Reference Station (CORS) networks and mobile devices over the Internet. The key difference between disseminating data via Internet streaming data and Web services is that the latter requires two–way “request and response” communication. To illustrate the capabilities and performance of an augmentation system based on the Web services architecture, a simple prototype has been developed. The differential positioning technique implemented within the prototype uses the DGPS code range model described by Hofmann–Wellenhof et al (2001). The Web service prototype is consistent with international Internet technology standards established by the Open Geospatial Consortium (OGC) and the World Wide Web Consortium (W3C) and as such, may be accessed and implemented using any standards– compliant software and/or platform.

Principal results from prototype testing confirm that the Web services architecture is a viable option for exchanging GPS augmentation information over the Internet. Tests conducted over peak and off–peak periods using a mobile phone and GPRS show a typical latency of 1–3 seconds in medium– to high–density urban environments. The disadvantages of using the Web services architecture for an Internet based DGPS system relate primarily to the bloat in the message caused from XML tags.

Before the prototype and preliminary test results are discussed in detail, some basic principles concerning Web services and low–cost GPS receivers are outlined.

Web Services

Web services provide a standardised way of interoperating between different software applications, running on various platforms and/or frameworks distributed on a network or over the internet. In particular, a Web service is a piece of application logic residing at a specific network location (or network address) that is accessible to programs via standard internet protocols. When called, a Web service performs one or more functional tasks and then sends a response back to the calling agent. During the process, a Web service may call other Web services and/or run other software applications. The response may be in the form of an entire data set such as a map, a database entry, or simply the result of a computation.

Web services use standardised protocols (i.e. OGC, W3C) so that raw data can be exchanged between operating systems and software components, whether compatible or not, in a platform independent way. The key to the success of Web service interoperability therefore, is in the implementation of open standards for data encoding, communication and transport protocols. The interoperability stack shown in Figure 1 illustrates the standards based enabling technologies upon which Web services are implemented and deployed.

Universal Discovery Description and Integration (UDDI) enables the publishing of services in a directory (similar in concept to the yellow pages), making it possible for other developers to locate and consume a Web service. A Web service’s interface is described using Web Service Description Language (WSDL). Simple Object Access Protocol (SOAP) is a standardised, lightweight protocol for connecting service endpoints distributed over network environment.

Formats for data encoding are described in a schema language such as XML Schema (XSD) or Document Type Definition (DTD). HyperText Transfer Protocol (HTTP) and Transmission Control Protocol/Internet Protocol (TCP/IP) permit the connectivity between software components and Web services by enabling them to send and receive messages. The lifecycle of a Web service request and response is shown in Figure 2.

The Web service lifecycle is based on the concept of bind–once, consume–
many. Thus, once a Web service has been located (2) and software written
to consume it according to its interface description (3), the software sends a request (4) to a Web service and waits for a response (5) synchronously or asynchronously. Steps (4) and (5) are repeated as many times as required. For every request, raw data is serialized (or encoded) into XML format and bound in a SOAP envelope, which in turn is conveyed over the Internet (or network) using HTTP and TCP/IP.

Low–Cost GPS receivers

For the purposes of this paper, low–cost GPS receivers are regarded as those typically used for general purpose positioning and navigation, low accuracy data capture, reconnaissance, bushwalking, marine and in–car navigation, and the like. With an unobstructed sky, low–cost GPS receivers have an expected horizontal and vertical positioning precision in the range of ±10–20 metres and ±20–30 metres respectively. After applying local DGPS corrections, many spatially correlated (or systematic) errors can be removed and hence, it is not unreasonable to expect some low–cost GPS receivers to achieve a horizontal positioning accuracy better than 5 metres.

A practicable means for augmenting low–cost GPS receivers using the Web
services technique is via custom software which is able to read the output GPS measurement information. The low–cost GPS receiver used in this investigation contains a SiRF chipset and outputs GPS information in the SiRF Binary protocol (SiRF, 2004). The SiRF Binary protocol provides an extensive list of input and output messages concerning the original measurements, the positioning and navigation solution, and commands for configuring the GPS chipset. For instance, the SiRF binary protocol supports the output of pseudorange and (integrated) carrier–phase measurements, subframes 1 to 5 of ICD–GPS–200C, receiver clock bias and drift, and various other observation and navigation messages (SiRF, 2004). The SiRF protocol also provides the ability for receivers to be supplied with DGPS corrections from either the US WAAS or broadcasting beacons in RTCM SC–104 format.

Although a (low–cost) SiRF–based receiver has been used for this investigation, it can be shown that any GPS–enabled device (i.e. which outputs time–stamped pseudorange measurements) capable of reaching the Internet can be used to take advantage of a Web services augmentation system.

Prototype for a web services DGPS system

To demonstrate the feasibility of a Web services DGPS system, a simple prototype has been developed. The prototype is comprised of three components: a GPS and Web enabled client (PDA), a server-enabled PC, and a single CORS receiver. Two Web services are hosted on the server ¾ (1) a CORS Web Service for logging the reference station receiver– determined pseudorange corrections and (2) a DGPS Web Service for disseminating those corrections to roving receivers. Accordingly, software has been developed for the PDA to facilitate the request, response and application of DGPS corrections. The architecture of the prototype is given in Figure 3. The specifications of the prototype components developed for this paper are given in Table 1.

CORS Network and Logging software

For the purposes of demonstration, only a single CORS receiver was used for the prototype. The reference station receiver was configured to output a Type 1 RTCM message (Differential DGPS corrections) via a RS232 serial port every second. Software was developed to read the output RTCM messages and in turn send the corrections to the CORS Web service. Figure 4 shows the flow of tasks performed by the reference station software.

Client Software

The client (or mobile device) software has been developed to perform three basic tasks:

1. Obtain the smoothed pseudoranges and position from the SiRF protocol
2. Handle the request and response of differential GPS corrections
3. Apply the pseudorange corrections and display the augmented GPS position To obtain a set of DGPS corrections, GPS time (t) and an approximate position (f, l) are sent to the Web service. Each request is made asynchronously to allow the client to continue operating without waiting for a response. When a response is received, a new position is computed from the corrected pseudoranges. Prior to making a call to the DGPS Web service, the client verifies whether an internet connection has been established. Figure 5 shows the general flow of the prototype client software.

Differential GPS and CORS Web Services

To provide real time DGPS augmentation, the two Web services (hosted on the server) operate independently to facilitate the logging and dissemination of real time corrections. Firstly, when sent by the custom reference station software, the computed pseudorange corrections are logged by the CORS Web service according to the GPS time and satellite ID. Secondly, when and as requested service retrieves the pseudorange corrections based on the GPS time and sends that data to the roving client.

Although the client’s approximate position is sent to the DGPS Web service, it is not used in this prototype. The purpose of sending the client’s position is simply to illustrate that, given an appropriate mathematical model for multi–station interpolation, the DGPS Web service could be extended to provide a set of location– centric pseudorange corrections.

Preliminary test results

Latency in data Transmission

Critical to real and near real time applications is the delay (or latency) in the time taken for a DGPS correction to be received by the rover. In contrast to the streaming technique, the latency considered in this paper is the time taken for (1) the request to be sent to the DGPS Web service, (2) a correction to be determined and (3) the corresponding corrections to be sent back to the client.

Figure 6 shows the latencies in transmission of DGPS corrections during peak and off–peak periods using a mobile phone and a GPRS connection. The average latencies from various tests show a mean of 1.86 seconds during off–peak periods and 2.12 seconds during peak periods. These results are based on a series of tests conducted over two weeks and are representative of the Melbourne CBD environment only. In all cases, none of the messages were found to be corrupted or degraded in any way. The latencies associated with the sending of reference station information to the CORS Web service (over a 1.5 Mb/s connection) is almost instantaneous and such, is not presented herein.

Previous research and development in Internet–based DGPS systems using data streaming has indicated similar results (Weber et al, 2004, for example). However, the (two–way) Web services architecture generally shows greater latencies over those achieved through (one–way) Internet streaming. Notwithstanding the influence of bandwidth, network congestion, mobile phone infrastructure performance, server performance and the like, the primary cause of the additional latency comes as a result of XML tag bloat and sending data in plain text. If each message were compressed into binary format, the latencies could be reduced. The latency may be further reduced if the entire message was sent as a character delimited string. However, sending multiple data elements in a single string would be contrary to the intention of the OGC and W3C interoperability standards.

DGPS Corrections

Table 2 shows the positioning accuracy results achieved by the Web services DGPS prototype described in this paper. The results show the difference between the average (or expected) values and standard deviations obtained from the autonomous GPS and DGPS–corrected positions over 30 minutes (1 second observations) with a 15° elevation mask.

As shown by Table 2, the effect of the spatially correlated GPS errors are greatly reduced by the DGPS technique. However, as indicated by the standard deviations in both GPS and DGPS estimates, the DGPS–corrected positions still suffer from large random errors.

Web Services for other GPS applications

This paper has focussed on the single baseline (differential) pseudorange correction technique for augmenting autonomous GPS positions. However, the principle of the Web services architecture may be used for exchanging a variety of GNSS related data, and applied to other GNSS positioning applications. Typical applications may include multi–station relative positioning, the dissemination of satellite orbit and clock corrections for Precise Point Positioning (PPP), and the monitoring of CORS network and receiver performance.

The one–way streaming of data over the Internet has been shown by other research to be a satisfactory method of disseminating DGPS corrections. As described in §5, results from this prototype indicate that Internet streaming offers marginally better latencies than the Web services architecture. However, where the method of augmentation requires the specific location of the roving receiver relative to one or more reference stations, two–way communications is needed. For instance, the interpolation of the differential correction for a rover based on the nearest surrounding CORS receivers requires the rover’s approximate location. As indicated by the prototype, the Web services architecture facilitates applications of this nature by enabling the user to supply measurements of any type, such as approximate position, observed pseudoranges and/or carrier– phase measurements. In the interest of multi–station RTK and Virtual Reference Station (VRS) applications, Web services can provide an efficient, secure and reliable source of platform–independent (or receiver independent) communication.

Web services offer significant advantages for platform independent monitoring of CORS network receivers. Notwithstanding the fact that many systems have long been in place for exchanging data between reference station receivers, Web services offer the ability to integrate receiver types of any make, provided that there is a means for sending data over TCP/IP. It follows that Web services can be used to interact with (or configure) remote GPS receivers from a central processing system securely from any location, wirelessly or not. Experience has shown that Web services communications over a (wired) 1.5 Mb/s Internet connection is almost instantaneous, showing that multi–reference station application performance would not be significantly degraded.

Discussion and conclusion

This paper shows that XML Web services are a simple, efficient and secure means for exchanging GPS augmentation information over the Internet. Web services offer some considerable advantages. Web services offer a platform independent way of augmenting GPS and Web enabled mobile devices capable of reaching the Internet (wirelessly or not) with correction information from existing CORS networks. It follows that software to consume a Web service can be developed by almost any programming language. Almost any hardware device capable of sending data over TCP/IP may be used. Since the Web services architecture allows for two– way communication, location–centric applications (i.e. multi–reference station approach) can benefit from this method of Internet augmentation. Web services can further provide opportunities for implementing encryption algorithms, secure transaction monitoring, and user authentication. Typical latencies for Web services communications can, in general, be expected to decline as mobile communications infrastructure is upgraded.

The exchange of GPS augmentation information via the Web services architecture also has its disadvantages. Strictly speaking, Web services architecture introduces larger latencies than streaming methods due to XML–message bloat. Since the Web services architecture disseminates information via two–way “request and consume” communications, additional latencies are introduced. For sub–second applications, Web services offer less than optimal performance over wireless connections. Whilst not necessarily restricted to the Web services approach, the main disadvantages come as a result of:

• Poor wireless/mobile coverage across rural areas which are dominant throughout Australia.

• Network congestion has the potential for introducing large latencies, even for simple data transmission.

• There can be no guarantee that a data packet will arrive by a certain time, if at all.

Acknowledgements

The authors would like to gratefully acknowledge the scholarship funding provided by Natural Resources, Mines and Energy (NRM&E, QLD) and the department of Geomatics, University of Melbourne. All hardware and software development tools used in this investigation have also been provided by NRM&E and the Department of Geomatics.

References

Gao Y and Liu Z (2001), Differential GPS Positioning over Internet, Journal of Geospatial Engineering, Vol. 3, No. 1, 1–7.

Hofmann–Wellenhof B, Lichtenegger H and Collins J (2001) GPS Theory and Practice, 5th edition, revised, Springer–Verlag Wien, New York.

Kechine MO, Tiberius CCJM and van der Marel H (2003) Network Differential GPS: Kinematic Positioning with NASA’s Internetbased Global Differential GPS, Journal of Global Positioning Systems, Vol. 2, No. 2, 139–143

Lenz E (2004) Networked Transport of RTCM via Internet Protocol (NTRIP), Proceedings of the FIG Working Week 2004, Athens, Greece, 22–27 May.

Monteiro LS, Moore T and Hill CJ (2004) What is the Accuracy of DGPS?, Presented at the European Navigation Conference GNSS 2004, Rotterdam, The Netherlands, May.

Muellerschoen R J, Bertiger WI and Lough M (2000), Results of an Internet-Based Dual-Frequency Global Differential GPS System, Proceedings of the IAIN World Congress, San Diego, CA, June.

RTCM SC–104, (2001) RTCM Recommended Standards for Differential GNSS Service, Version 2.3, 20 August, Radio Technical Commission for Maritime Services, Alexandria, Virginia.

Satirapod C, Rizos C and Wang J (2001) GPS Single Point Positioning With SA Off: How Accurate Can We Get? Survey Review, 36(282), 255-262.

SiRF (2004) SiRF Binary Protocol Reference Manual, SiRF Technology, San Jose, CA, Revision 1.1, February 2004.

Weber G, Dettmering D and Gebhard H (2004) Networked Transport of RTCM via Internet Protocol (NTRIP), unpublished, Available online:
http:// igs.ifag.de/pdf/NtripPaper.pdf.

W3C (2002) XML Encryption Syntax and Processing – W3C Recommendation, Eastlake D, Reagle J (eds), 10 December, Available online: http://www.w3.org/TR/xmlenc-core/.
This paper was published in the Journal of Global Positioning Systems, Vol 3, No 1-2, pp 85-94.