Journal of Global Positioning Systems (2004)
Vol. 3, No. 1-2: 85-94
Augmentation of Low–Cost GPS Receivers via Web Services and
Wireless Mobile Devices
Roger Fraser, Adam Mowlam, Philip Collier
Department of Geomatics, The University of Melbourne, Australia
e-mail: [e-mail] Tel: 61+ 3 8344 4509; Fax: 61+ 3 9347 2916
Received: 15 Nov 2004 / Accepted: 3 Feb 2005
Abstract. Low–cost GPS receivers can produce positions
almost instantly, however they have a limited use and
application due to the impact of random and systematic
errors associated with real time autonomous positioning.
To achieve higher levels of accuracy and precision, some
other form of correction or augmentation information
must be applied. There are various real time
augmentation alternatives, such as WAAS/LAAS,
integrated sensors and systems, receiver based optimal
estimation algorithms, and potentially, combined GNSS.
To improve the accuracy of low–cost GPS receivers, a
feasible option is Differential GPS (DGPS). A popular
means for transferring real time DGPS corrections is via
the RTCM SC–104 protocol over radio transmission. In
recent times, the Internet has been shown to be an
efficient and reliable form of data communication. In this
paper, the Web services architecture is examined as a
viable protocol and communication alternative for
disseminating DGPS augmentation information over the
Internet. Preliminary results from a simple prototype
indicate that Web services offers a practical, efficient and
secure method for exchanging CORS network data, and
augmenting GPS enabled mobile devices capable of
wirelessly reaching the internet. Web services are further
shown to provide advantages for disseminating other
GPS related data, such as IGS satellite orbit data, carrier–
phase data for location–centric augmentation, and a host
of other LBS information.
Key words: Low–cost GPS, Internet DGPS, Web
Services, Mobile Devices
1 Introduction
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

86 Journal of Global Positioning Systems
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, low–cost GPS receivers and DGPS
augmentation are outlined.
2 Web Services  Interoperability, Lifecycle and
Encryption Concepts
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). A WSDL document
describes everything a developer requires to enable
software to interact with the service, such as input
messages, the format of its responses to those messages,
protocols that the service supports and where to send the
messages.

Fraser et al: Augmentation of Low–Cost GPS Receivers via Web Services and Wireless Mobile Devices 87
Fig. 1 Web services interoperability stack
Simple Object Access Protocol (SOAP) is a standardised,
lightweight protocol for connecting service endpoints
distributed over network environment. The SOAP
envelope is the cornerstone to interoperability as it
enables a Web service to be used by any system capable
of sending and receiving plain text over a distributed
computing framework. With the exception of pure binary
data, the structured data and SOAP envelope are encoded
in XML.
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.
Fig. 2 Web services lifecycle.
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.
A topic of contention that is raised frequently with Web
services is that of security  that is, the unauthorized
viewing and/or manipulation of the transported message.
Standards for the encryption of the data transport layer,
such as SSL/TLS for point–to–point security already
exist. Since these standards only support end–to–end
security, encryption of the data itself must be undertaken
Publish/locate a Web service
UDDI
Web service interface description
WSDL
Binding of request and response
SOAP
Data transport
HTTP, TCP/IP, SSL
Data encoding
XML, XSD/DTD
Web service consumer
LAN/WAN
or
Wireless
4. Web service request
serialized into XML
5. Web service
response parsed
Data binding
SOAP
Data Transport
HTTP
Web service provider
Registry
UDDI
1. Web service
published
2. Web service
located
Web Service
Description
WSDL
3. Get
Web service
interface
description

88 Journal of Global Positioning Systems
if information is to be kept secure. To support this need, a
draft recommendation exists for XML encryption [W3C,
2002], and relies on client–server encryption algorithms
and symmetric/asymmetric keys schemes. Under the
XML encryption standard, arbitrary data, XML elements,
and/or XML element content can be secured from
unauthorised viewing. Additional checks can be made at
each end to verify whether an encrypted stream has been
manipulated or not.
In the interest of monitoring and charging for Web
service usage in a commercial environment, transaction
monitoring procedures may be easily implemented. In
addition, authentication procedures may be applied so
that a Web service can be protected from unauthorised
usage when publicly exposed over the Internet and
internal networks. XML parsers can be implemented at
both the client and server ends of a Web service
connection to validate the well formed–ness of the SOAP
message. This reduces the risk of a corrupted message
from being sent or received undetected.
3 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. The accuracy and precision
obtainable from low-cost GPS receivers, following the
discontinuation of Selective Availability (SA), is well
known (Satirapod et al, 2001, for example). 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 question that is often raised is: “How can low–cost
GPS receivers be augmented with DGPS corrections via
Web services rather than by conventional radio
transmission?” 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. Low–cost GPS receivers
typically output GPS information in one or more
proprietary protocols, depending on the receiver make
and chipset. Currently, a majority of low–cost GPS
receivers provide positioning information by way of the
National Marine Electronics Association (NMEA)
standard. Under the NMEA–0183 standard, elementary
positioning and navigation information, such as position,
velocity, direction and observed satellites, is provided
through ASCII sentences. In the context of Location
Based Services (LBS) applications, this protocol is
sufficient for low–accuracy (or unaugmented) positioning
requirements. However, where custom augmentation
algorithms are to be implemented to improve the
accuracy and precision of the autonomous positioning
solution, a more extensive protocol (i.e. one that can
provide the original code and/or carrier–phase
observations) is required.
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 capable of reaching the Internet
(wirelessly or not) can be used to take advantage of a
Web services augmentation system. It follows that the
“right” protocol for custom software to implement DGPS
corrections via a Web services augmentation system
ultimately depends on the mathematical model embodied
within the method of augmentation. Since the method of
augmentation used in this paper is based on correcting
pseudoranges, any receiver which outputs time–stamped
pseudorange measurements could be used.
4 Correlated Errors Accounted for by DGPS
Corrections
As discussed previously, to improve the accuracy of real
time autonomous GPS positioning, DGPS corrections
obtained from a local reference station (or CORS
network) may be applied. In principle, the technique of
DGPS minimises the influence of errors which are
spatially correlated between two or more simultaneously
operating receivers. Differential pseudorange corrections
are computed by (stationary) receivers located over
known reference marks and represent the difference
between a computed range and (measured) code
pseudorange. Accordingly, pseudorange corrections
quantify the impact of the errors affecting the code range
measurement at that specific location and time. After
removing the influence of random and site specific errors
contained within the reference receiver’s measurements
(i.e. receiver noise, receiver clock error and multipath),

Fraser et al: Augmentation of Low–Cost GPS Receivers via Web Services and Wireless Mobile Devices 89
the pseudorange corrections are then transmitted and
applied to nearby (roving) receivers to yield a better
estimate of their position.
In general, the spatially correlated GPS errors for which
(differential) pseudorange corrections can compensate
include satellite clock errors, broadcast ephemeris errors,
and signal propagation errors (i.e. ionospheric and
tropospheric refraction). Over short distances in real time
(or after a short latency of around a few seconds), the
effect of these errors can be greatly reduced by DGPS
techniques. However, as the distance between the roving
and reference station receivers increases, there is a natural
degradation in the level of correlation and thus the
accuracy of the pseudorange correction diminishes.
Furthermore, since the correlated errors are subject to
temporal variation (i.e. by changes in the atmosphere,
satellite orbit deviation and clock offset), the level of
correlation may be further reduced as the time separating
the observations increases. Experience has shown that for
low-cost GPS applications, the decorrelation of errors
according to time may be neglected up to a period of
about 10-20 seconds without significantly reducing the
accuracy.
The DGPS corrections disseminated in the prototype
discussed in this paper are based on the RTCM SC–104
(version 2.3) Type 1 message and include a pseudorange
and range rate correction for each measurement at time
(t). At the receiver, the corrected pseudorange ()
j
Bcorr
Rt
is obtained from (Hofmann–Wellenhof et al, 2001):
() () ()=+
jjj
Bcorr B
RtRt PRCt (1)
where ()
j
PRCt is the predicted differential pseudorange
correction and is given by:
000
() () ()(-)=+
jj j
PRC tPRC tRRC ttt (2)
where 0
()
j
PRC t and 0 ()
j
RRC t are the pseudorange
and range rate corrections observed at the reference
station at time 0 ()t and t is the time of measurement at
the roving receiver.
5 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.
Tab. 1 Prototype component specifications
Component Specifications
PDA (client) iPAQ 3850, Bluetooth expansion pack, custom software
Low–cost GPS receiver Pretec CompactGPS (SiRF Binary & NMEA 0183)
Mobile Phone Ericcson Bluetooth phone (GPRS-only internet account)
PC (Web server) 2.0 GHz Pentium 4, MS W2K/IIS 5.0/ASP.NET, custom software
CORS receiver Leica GPS System 500

90 Journal of Global Positioning Systems
Fig. 3 Architecture of the Web services DGPS augmentation prototype
5.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.
Fig. 4 Flow of tasks performed by the reference station receiver software
Transmission via GPRS
GPS / Web enabled device
Wireless
Internet access
Server
1. CORS Web service
2. DGPS Web service
Broadcast Observation and Navigation data
User’s ISP
LAN
CORS Network
Bluetooth
t
φ, λ
t0
PRC1–n
RRC1–n
STN ID, t0
SV ID1–n
PRC1–n
RRC1–n
UDRE1–n
Verification
Obtain corrections (t0) for
reference station
Prepare XML Web
service re
q
ues
t
CORS Web service
STN ID
t0
PRC1–n
RRC1–n
UDRE1–n
Send SOAP message to
Web service

Fraser et al: Augmentation of Low–Cost GPS Receivers via Web Services and Wireless Mobile Devices 91
5.2 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 (φ, λ) 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 via equations (1) and
(2). 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.
Fig. 5 Flow of tasks performed by the client software
5.3 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 as described in §5.1 and §5.2. 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 by the
roving client, the DGPS Web 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. This is discussed further in §7.
6. Preliminary Test Results
6.1 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.
Prepare XML Web
se
r
vice re
q
ues
t
Apply corrections and
compute position
Check Internet connection
availabilit
y
Dial ISP
DGPS Web service
t0
PRC 1–n
RRC 1–n
UDRE 1–n
t
φ, λ
Send SOAP message to
Web service
Obtain position and
pseudoranges (φ, λ, ρ1-n)

92 Journal of Global Positioning Systems
Fig. 6 Latency in request/response of DGPS pseudorange corrections for 6 satellites using a mobile phone (over GPRS) during peak and off–peak
periods
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.
6.2 DGPS Corrections
Table 2 shows the positioning accuracy results achieved
by the DGPS Web service 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 is 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.

Fraser et al: Augmentation of Low–Cost GPS Receivers via Web Services and Wireless Mobile Devices 93
Tab. 2 Comparison of results from Autonomous GPS and DGPS–corrected positions.
Easting Northing E height
∆E ∆N ∆h
µ 320469.61 5814432.62 79.52 2.34 –0.43 16.17
GPS
σ 1.73 2.56 3.74
µ 320466.70 5814432.98 66.13 -0.57 -0.07 2.77
DGPS
σ 1.67 2.58 3.64
7 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 §6,
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.
In certain environments where the effects of spatial
decorrelation are at relatively high levels, the differential
correction approach described here may provide little or
no improvement to positioning accuracy. To improve
positioning quality in this instance, a practicable
alternative is the integration of precise satellite orbit and
clock parameters, rather than the less–precise broadcast
ephemeris commonly used in the positioning solution. It
is well known that, given the availability of precise orbit
and clock parameters from IGS, the influence of
broadcast ephemeris errors on an absolute positioning
solution can be significantly reduced. Though not
included in this paper, in conjunction with the
developments undertaken for this prototype, a Web
service for downloading and disseminating SP3 ultra
rapid orbit information has also been developed. Whilst it
has not been implemented as yet, this work indicates that
an “ultra–rapid clock and orbit” Web service would be a
viable option for Web–enabled receivers located in areas
where local CORS network corrections are unavailable.
Finally, 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.
8 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

94 Journal of Global Positioning Systems
algorithms, secure transaction monitoring, and user
authentication. Being a transactional service, the user
pays only for what data is requested and received. Hence,
where DGPS corrections are shown to be stable over
longer periods (i.e. 10–20 seconds), the user may opt to
restrict the number of calls made to the Web service.
Typical latencies for Web services communications can,
in general, be expected to decline as mobile
communications infrastructure is upgraded.
However, 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 Ed., revised). Springer–
Verlag Wien, New York.
Kechine MO, Tiberius CCJM and van der Marel H (2003):
Network Differential GPS: Kinematic Positioning with
NASA’s Internet-based 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/.