Server-Side-GPS and Assited-GPS

Server-Side GPS and
Assisted-GPS in Java™
DISCLAIMER OF WARRANTY
The technical descriptions, procedures, and computer programs in this book have
been developed with the greatest of care and they have been useful to the author in a
broad range of applications; however, they are provided as is, without warranty of
any kind. Artech House, Inc. and the author and editors of the book titled
Server-Side GPS and Assisted-GPS in Java™ make no warranties, expressed or
implied, that the equations, programs, and procedures in this book or its associated
software are free of error, or are consistent with any particular standard of mer-
chantability, or will meet your requirements for any particular application. They
should not be relied upon for solving a problem whose incorrect solution could
result in injury to a person or loss of property. Any use of the programs or proce-
dures in such a manner is at the user’s own risk. The editors, author, and publisher
disclaim all liability for direct, incidental, or consequent damages resulting from use
of the programs or procedures in this book or the associated software.
For a listing of recent titles in the

Artech House GNSS Technologies and Applications Series,
turn to the back of this book.
Server-Side GPS and
Assisted-GPS in Java™
Neil Harper
artechhouse.com
Library of Congress Cataloging-in-Publication Data
A catalog record for this book is available from the U. S. Library of Congress.
Disclaimer:
This eBook does not include the ancillary media that was
packaged with the original printed version of the book.
British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library.
ISBN-13: 978-1-60783-985-9
Cover design by Igor Valdman
© 2010 ARTECH HOUSE

685 Canton Street
Norwood, MA 02062
Trademarks
Sun, Sun Microsystems, the Sun Logo, and Java are trademarks or registered trademarks of
Sun Microsystems, Inc. in the United States and other countries.
All rights reserved. Printed and bound in the United States of America. No part of this book
may be reproduced or utilized in any form or by any means, electronic or mechanical, includ-
ing photocopying, recording, or by any information storage and retrieval system, without
permission in writing from the publisher.
All terms mentioned in this book that are known to be trademarks or service marks have
been appropriately capitalized. Artech House cannot attest to the accuracy of this informa-
tion. Use of a term in this book should not be regarded as affecting the validity of any trade-
mark or service mark.
10 9 8 7 6 5 4 3 2 1
To my wife, Tracey,
our children, Kate, Emma, and Adam,
and my parents, Barry and Brigit,
who have made this, and everything else, possible.
Contents
Preface xiii
Acknowledgments xvii
CHAPTER 1
Introduction 1
1.1 Overview 1
1.2 Terminology 2
1.3 Global Navigation Satellites Systems (GNSS) 2
1.4 GNSS Augmentations 3
1.5 GPS from a High Level 3
1.6 Assisted-GNSS from a High Level 5
1.7 A-GNSS Protocols and Standards 9
1.8 Why Is an Accurate Location Required? 10
1.9 Location Market 11
1.9.1 E9-1-1 11
1.9.2 Location-Based Services 11
1.9.3 Lawful Intercept Services 12
1.10 Java and Software Design for A-GNSS Applications 12
1.10.1 Coding in Java 13
1.11 Organization of This Book 14
References 14
CHAPTER 2
Coding for GNSS and the Coordinate Reference Frame 17
2.1 Coordinate Reference Frame 17
2.2 World Geodetic System 1984 18
2.3 Source Code Structure and Management 22
2.4 WGS 84 Implementation 23
2.5 Unit Testing 27
2.6 Debugging 29
2.7 Performance Testing and Benchmarking 29
2.8 Code Coverage Analysis 30
2.9 Configuration Management 32
References 32
vii
viii Contents
CHAPTER 3
GPS 35
3.1 GPS Constellation and Segments 35
3.2 GPS Services 36
3.3 Satellites 36
3.4 Ranging Codes 36
3.5 PRN Codes 37
3.6 GPS C/A Code 37
3.7 GPS L1 Signal 38
3.8 GPS L2 Signal 38
3.9 GPS Time 39
3.10 Broadcast Information Navigation Message Structure (NAV) 39
3.11 Decoding and Storing the Navigation Model 46
3.11.1 Storing the Raw NAV Data 46
3.11.2 Running the Classes to Store the Raw Data 47
3.11.3 Other Sources of Raw NAV Data 49
3.11.4 Decoding the NAV Data into Useful Information 49
3.11.5 RINEX as a Data Source for the Navigation Message 50
3.11.6 Implementation of Methods Using the NAV Model 51
3.12 GPS Signal Acquisition 54
3.13 Receiver Positioning 54
3.13.1 Uncertainty and Confidence 56
3.14 Factors Affecting Location Accuracy 58
3.15 Geometry and Dilution of Precision 59
3.16 Differential-GPS 59
3.17 Software Projects 60
References 62
CHAPTER 4
Assisted-GPS and Assistance Data 63
4.1 The Assistance Model 63
4.2 GNSS Reference Server (GRS) 65
4.2.1 GPS Reference Receiver Configuration for a GRS 66
4.2.2 GRS Interface 69
4.2.3 Open Source GNSS Reference Server (OSGRS) 70
4.3 Location Server (LS) 72
4.4 Location-Based Application (LBA) 73
4.5 Emergency Services Messaging Entity 75
4.6 The Handset 76
4.7 Assistance Data Types 76
4.7.1 Reference Time 77
4.7.2 Reference Location 79
4.7.3 Navigation Model 79
4.7.4 Ionosphere Model 79
4.7.5 UTC Model 80
4.7.6 Acquisition Assistance 81
4.7.7 Real-Time Integrity 86
Contents ix
4.7.8 Almanac 86
4.7.9 DGPS Corrections 86
4.8 Assistance Data Type Sizes 87
References 88
CHAPTER 5
Assisted-GPS Location Within a Network 91
5.1 Location Architectures 91
5.2 A-GPS Protocols and Messaging 92
5.3 RRLP 92
5.3.1 RRLP Procedures 93
5.3.2 RRLP Messages 94
5.3.3 RRLP Encoding and ASN.1 Packed Encoding Rules 95
5.3.4 RRLP Implementation 104
5.3.5 Testing the RRLP Classes 110
5.3.6 Communication Across Sockets with RRLP 110
5.4 PCAP and RRC 114
5.4.1 PCAP Procedures 115
5.4.2 PCAP Messages and Encoding 117
References 118
CHAPTER 6
Position Calculation 121
6.1 Position Calculation and Handset-Assisted A-GPS 121
6.2 The Accuracy and Yield Trade-Off 122
6.3 Positioning Using GPS Code Phase Measurements 123
6.3.1 Data Preparation 126
6.3.2 Worked Example 127
6.3.3 Satellite Health 129
6.3.4 Calculate the Location of Each Satellite 130
6.3.5 Satellite Clock Correction 130
6.3.6 Group Delay Differential 132
6.3.7 Geometric Range Correction 132
6.3.8 Substituting in a Pseudomeasurement 134
6.3.9 Pruning Bad Satellite Measurements 134
6.3.10 Pruning Low Elevation Satellites 134
6.3.11 Pruning Weak Measurements 136
6.3.12 Ionosphere Correction 136
6.3.13 Troposphere Correction 137
6.3.14 Position Calculation 138
6.3.15 Uncertainty 143
6.3.16 Quality Measures 145
6.4 Doppler-Based Position Calculation 146
6.5 Hybrid Position Calculation 149
References 150
x Contents
CHAPTER 7
GPS Position Calculation with Time Recovery 153
7.1 The Time Determination Problem 153
7.2 Iterative Time Recovery 156
7.2.1 Iterative Time Recovery: Accuracy 160
7.2.2 Iterative Time Recovery: Performance 160
7.3 Integrated Time Recovery 163
7.3.1 Integrated Time Recovery: Accuracy 165
7.3.2 Integrated Time Recovery: Performance 165
7.4 Software Project 166
References 166
CHAPTER 8
Hybrid Location 167
8.1 Hybrid Positioning Overview 167
8.3 Hybrid Position Calculation Implementation 170
8.4 Hybrid Position Calculation Accuracy 172
8.4.1 Simulation Background 172
8.4.2 Location Calculation in Difficult Situations 174
8.4.3 Hybrid Location with Ideal Ranges 175
8.4.4 Hybrid Location with Ranges Using Error-Corrupted Ranges 177
References 182
CHAPTER 9
Other Server-Side Improvements and Controls 183
9.1 Improved Error Modeling 183
9.1.1 Orbit Modeling 183
9.1.2 Troposphere Modeling 184
9.1.3 Ionosphere Modeling 184
9.2 Location Integrity 185
9.2.1 Location Assurance 185
9.2.2 Antispoofing 186
References 190
CHAPTER 10
Assisted-GNSS 193
10.1 Assisted-GNSS 193
10.1.1 GLONASS 194
10.1.2 Galileo 194
10.1.3 Compass 195
10.1.4 QZSS 195
10.1.5 WAAS 196
10.1.6 EGNOS 196
Contents xi
10.1.7 Others 197

10.2 Protocols 197
10.2.1 GANSS Position Request 197
10.2.2 GANSS Position Response 201
10.3 Using Multiple GNSSs and Signals 202
References 202
Appendix A
Relevant Standards and Documents 203
Appendix B
Accompanying Source Code 207
Appendix C
Source Code Object Model 211
Appendix D
Sample RRLP Messages 215
D.1 Measure Position Request (with Acquisition Assistance) 215
D.2 Measure Position Response (GPS Measurements) 217
D.3 Assistance Data (Reference Location and Navigation Model) 218
D.4 Measure Position Response (Location) 221
List of Acronyms and Abbreviations 223

List of Symbols 229
Glossary 231
About the Author 235
Index 237
Preface
Assisted-GNSS is an interesting field to work in at present. Demand for accurate
location is increasing and new satellites and signals are coming online through the
GPS modernization program and the emergence of new GNSSs.
This book is a practical exploration of A-GNSS with particular focus on A-GPS.
It provides some theoretical background, but mainly concentrates on the design and
implementation from the server’s point of view. It explores all of the practical
aspects of the server-side A-GPS from messaging protocols, assistance data prepara-
tion and generation, and the position calculation. Aspects of positioning that are
unique to the server-side position calculation, such as hybrid location and GPS time
recovery, are also discussed.
This book contains the implementation of key aspects of the algorithms with
the remaining code accompanying this book. The software on the accompanying
CD is written in the Java™ programming language and contains more complete code
and example applications that can be used to enhance learning. Java has significant
advantages for implementing A-GNSS software. Its primary advantage is its sim-
plicity and, hence, maintainability. It has the power of an object-oriented language
with a very fast write-build-run cycle. It runs on many different platforms with high
performance. In addition, there are many development tools available that were
used during development of the code for this book.
This work was conceived in late 2007 when Mark Walsh at Artech House
wrote to me after my presentation at ION GNSS 2007 in Fort Worth.
After replying to Mark requesting some initial information, I became bogged
down helping out with designing and implementing software related to encoding,
decoding, and reassembling segmented SCCP messages over SIGTRAN SS7 proto-
col for our SAS product. Several items of correspondence were exchanged, I lifted
my head out of the details of the SCCP messaging, and eventually this project was
launched, thanks to Mark’s persistence and the support of my wife and family.
Most of the other detailed work in the Assisted-GPS field is focused on the engi-
neering aspects of handset development and how the handsets operate. There is
some coverage of the server side, but most of the information is focused on how the
handsets work and ways of improving their operation.
Understanding how the server works allows buyers to make informed purchas-
ing decisions, engineers to make educated decisions when implementing their
A-GPS capable handsets, and students to gain a good understanding of the field.
This work is also helpful for software engineers who are interested in applied Java.
The purpose of this book is not to simply present the details of how things work
but to apply the alogorithms practically with source code. The goal of the source
code provided in this book and on the accompanying media is to demonstrate key
xiii
xiv Preface
points and allow the interested person to modify and run the code. The user is
encouraged to run, modify, and dissect the code in order to get a thorough under-
standing. UML class and sequence diagrams are provided where they are helpful for
explanation.
Chapter 1 introduces the field of Assisted-GNSS and A-GPS and its primary
advantages over autonomous GPS. It discusses the main application areas and con-
tains an introduction to the software design and Java that is covered in this book.
Chapter 2 introduces the Java source code that accompanies this book and
works through some of the classes. This is done in the context of the GPS coordinate
reference frame and WGS 84 coordinates. The coordinate system is introduced and
the equations for converting between the Cartesian and the geodetic representations
are given. The project mode of the source code and how to modify and build the
source code are discussed.
Chapter 3 introduces the key operations of GPS. This includes the GPS signals,
GPS time, satellite broadcast information and models, and key calculations such as
calculating the location of the satellites at a specific time. It also introduces GPS sig-
nal acquisition and receiver positioning. Factors affecting the accuracy of a GPS fix
are discussed as well as geometry and dilution of precision (DOP).
Chapter 4 describes the Assisted-GPS model and the assistance data. It discusses
the architecture in detail and each component in the network including the GNSS
Reference Server (GRS), the location server (LS), the location-based application
(LBA), the Emergency Services Messaging Entity (ESME), and the handset. Each
assistance data type is introduced, the methods to calculate it are explained, and its
use is outlined.
Chapter 5 discusses the standards-based architectures and protocols used for
A-GPS in a network. It discusses how the LS fits into the location services architec-
tures and the specific protocols used for A-GPS such as RRLP, PCAP, RRC, and
TIA-801. The RRLP protocol is discussed in detail with an explanation of ASN.1
and PER encoding as well as message examples and the Java code for encoding and
decoding RRLP messages.
Chapter 6 discusses the position calculation with a particular reference to it
being performed on the server. It introduces the mathematical theory at a high level
and the models used for the calculations. It also discusses the implementation with
the source code and object model. It is done from the perspective of a walkthrough
of the Java code that accompanies this book with an example position calculation.
Chapter 7 introduces GPS time recovery as a way that the GPS time can be
determined as part of the position calculation solution. Time recovery is introduced
and two different algorithms are discussed: iterative time recovery and integrated
time recovery. Results of the two different methods are compared, accuracy and
performance of both methods are reported, and the implementation of iterative
time recovery is outlined.
Chapter 8 discusses hybrid GPS and ranging measurements in order to calculate
a location where one would not otherwise be able to be calculated. It discusses the
algorithm and steps through the implementation. It then outlines a series of experi-
ments and results that use simulated range measurements to calculate a location.
Chapter 9 introduces some of the techniques available to the LS for improving
the accuracy and yield of location calculations by using improved error models. It
Preface xv
also introduces location integrity and the mechanism for location assurance. There
is also a brief introduction location spoofing.
Chapter 10 generalizes the previous work in the book to A-GNSS and discusses
some of the issues associated with an A-GNSS server compared to an A-GPS server.
This chapter discusses the differences in the protocols and how the server can make
use of measurements from more than one GNSS.
Source code and updates are available at http://www.artechhouse.com/static/
reslib/harper/harper1.html.
Acknowledgments
Writing this book was not an individual effort, but did require the support of many
people during the time I wrote it and the years preceding the writing of this book.
First, I would like to thank the Andrew Corporation managers who have supported
my work over the years: Martin Dawson, David Evans, and Stewart Needham. I
also thank my colleague Peter Nicholson for many in-depth brainstorming sessions
and time spent working through problems in the early days of developing our MLC
product. I also thank Martin Thomson and Khiem Tran for their more recent input.
Darren Pawson helped me to put my suggestions for the book cover together and
gave me many insights into the nuances of RRLP encoding over the years. Peter
Rhodes helped me with some of the code.
I would also like to acknowledge all of my colleagues at Andrew Corporation in
both the Wollongong and Ashburn labs for contributing to my practical knowledge.
In addition, I thank the various handset manufacturers with whom I have interacted
and experienced interoperability testing with over the years; I have gained valuable
insights from them.
I am deeply grateful to Chris Rizos from UNSW for all of his invaluable assis-
tance over the last eight years and for the GPS course that he ran here in the lab that
started me on this journey. I thank the other individuals at UNSW who have con-
tributed to this path, including Peter Mumford, Andrew Dempster, and Binghao Li.
I thank my father for reviewing all of the chapters as I wrote them and for pro-
viding a lot of encouragement throughout the process. I would also like to thank the
technical reviewers who provided a lot of valuable feedback and Lindsey Gendall
from Artech House for helping to keep things on track.
I have relied on the encouragement from many of my friends while writing this
book including Phillip, David, Andrew, and the rest of the gang from The Friday
Group. I also thank my running friends Heidi and Glenn, who have regularly
encouraged me and inquired about progress, quite often when we have been out
running on bush tracks or down to the beach. I thank my good friend Lusi, who
reviewed some of the early chapters and helped with some of the MLP and RRLP
messages, but, more significantly, provided ongoing encouragement and enthusi-
asm for this project.
Finally, and most importantly, I would like to thank my wife, Tracey, and our
children, Kate, Emma, and Adam, for their love, support, and encouragement. The
credit goes to the Lord Jesus Christ through whom all things are created.
xvii
CHAPTER 1
Introduction
The basic task of a Global Navigation Satellite System (GNSS) assistance data
server is to provide assistance data to a GNSS-enabled handset in order to improve
the time to first fix (TTFF) and the yield. In addition, it often provides the position
calculation functionality in order to conserve battery power in the handset, reduce
the amount of assistance data that needs to be sent over the network, and allow inte-
gration with other measurements available in the network.
This book is a practical introduction to understanding, designing, and imple-
menting Assisted-GNSS (A-GNSS) server-side software with examples in the Java
programming language. Most of the practical worked examples use the Global
Positioning System (GPS) GNSS since that is presently fully operational and widely
used. Existing protocols for GNSS and GPS are introduced and discussed in detail.
Note that this book provides the practical details of server-side A-GPS implementa-
tion. For the detailed background theory and mathematics, the reader should con-
sult a general GPS book such as [1–3].
1.1 Overview
The two significant modes of Assisted-GNSS are handset-based (where the handset
performs the position calculation) and handset-assisted (where the server performs
the position calculation). In both modes, the server provides assistance data to the
handset that is specific to its approximate location. In handset-based A-GPS, the
handset uses this information to lock onto the satellites and perform a position cal-
culation. For handset-assisted A-GPS, the handset locks onto the satellites and
returns the measurements to the server.
When the calculation is performed on the server, much less assistance data
needs to be transferred to the handset. This is because the handset only has to lock
onto the satellites and return the measurements to the server, where the calculation
is made. The server can also make use of additional information and perform a
hybrid calculation. This includes improved error models and measurements from
sources other than those that can be made by the handset.
This book is focused on single-frequency, single point positioning (SPP). Mea-
surements are considered for a single time and are considered in isolation to other
measurements. This is the cold-start case where the handset has no prior informa-
tion about the GNSS constellation.
In this chapter, the field of GNSS is introduced and Assisted-GNSS is described
from a high level. Location accuracy is discussed with requirements and different
applications are considered. The software that accompanies the book is introduced
1
2 Introduction
along with some discussion about the choice of programming language and soft-
ware development issues in general.
1.2 Terminology
Traditionally, a GPS receiver has had a recognizable form-factor. This could be as a

stand-alone unit or as embedded in another device such as a cell phone. However,
the receiver circuitry could be inside all manner of devices such as any handheld
computer or even a laptop computer. Throughout this text, all of these devices are
referred to as a handset.
1.3 Global Navigation Satellites Systems (GNSS)
A Global Navigation Satellite System (GNSS) is a system, or technology, with

global coverage that allows a handset to make measurements of signals that have
been transmitted from satellites to accurately determine its own location. A side
effect is that the handset can also accurately determine the time. The satellites trans-
mit ranging codes that can be detected by a receiver and allow the receiver to deter-
mine the range to each of the satellites. In addition, the satellites also transmit
information that allows the receiver to calculate the location of the satellite, account
for some biases in the measurements, and obtain some information about other sat-
ellites in the constellation.
The GPS is only one of several GNSSs that are in various stages of planning and
deployment. Presently, GPS is the only GNSS that is at full operational capability
(FOC). Other GNSSs that are partially operating or are in planning include
GLONASS, Galileo, and Compass.
The GPS is a United States Department of Defense (DoD)–developed GNSS that
reached FOC in April 1995. It provides the standard positioning service (SPS) and
the precise positioning service (PPS). The SPS is available to all users, while the PPS
is designed for U.S. (and NATO) military use. The GPS is presently undergoing a
modernization program with the addition of new civilian frequencies. GPS handsets
have achieved a significant penetration worldwide.
The GLONASS system is developed and managed by the Russian Federal Space
Agency. It is a GNSS that requires 24 satellites for FOC and is presently running
below that. It is undergoing a modernization effort that includes transmitting in
CDMA, which is similar to the other GNSSs. The modernization includes the devel-
opment of augmentation systems to improve the real-time accuracy.
The Galileo GNSS is presently being built and deployed by the European Union
(EU). It consists of 30 satellites when fully deployed operating in several frequency
bands and will provide different services for civilian and commercial use and safety
of life.
Compass is a system that is presently in planning and development by the Chi-
nese government. It consists of satellites in both medium Earth orbit and geostation-
ary orbit.
1.4 GNSS Augmentations 3
1.4 GNSS Augmentations
A GNSS augmentation is a system that can be used to improve the performance of a

GNSS by providing information from another source that is external to the GNSS.
This can be in the form of corrections, measurement models, or reliability
information.
A Satellite-Based Augmentation System (SBAS) is an augmentation system that
consists of a set of distributed reference stations at precisely known locations, a cen-
tral processing system that determines the integrity and regional ionosphere correc-
tions, and one or more geostationary satellites that can provide the information to
users [4].
The reference stations make ranging measurements from the satellites and pro-
vide them to the central processing system. The central system determines the integ-
rity of individual satellites and determines corrections based on the measurements
and the precisely known location of the reference station’s antenna. This informa-
tion is then available to users via a signal separate to the GNSS that is being aug-
mented. The information normally provides corrections to the GNSS satellite’s
position and clock error as well as location-dependent ionospheric delay
information.
The US SBAS is known as the Wide Area Augmentation System (WAAS), which
consists of receiver stations deployed in North America, several wide-area master
stations, and geostationary satellites. Position and clock error corrections are rele-
vant to the entire coverage of the SBAS, so a user handset can make use of these cor-
rections immediately and perform a position calculation. It can then use the
ionospheric corrections that are specific to its approximate location in order to
improve the accuracy of the location.
Other SBASs include the European Geostationary Navigation Overlay Service
(EGNOS), Multifunctional Satellite Augmentation System (MSAS), and the
GPS-Aided Geo Augmentation Navigation (GAGAN). The SBASs are compatible
with each other and are discussed in more detail in Chapter 10.
A Ground Based Augmentation System (GBAS) is similar to an SBAS except the
transmitter(s) are terrestrial and are often Local Area Augmentation Systems
(LAAS). The Ground-Based Regional Augmentation System (GRAS) is an augmen-
tation system that is specifically designed for navigation of aircraft on their
approach to an airport. Both of them transmit local differential corrections over
VHF.
1.5 GPS from a High Level
The GPS consists of three segments: the control segment, the space segment, and the
user segment [2]. The GPS constellation consists of a minimum of 24 satellites that
orbit the Earth in just under 12 hours.
The GPS satellites continuously transmit signals on several different frequen-
cies. The primary civilian frequency is GPS L1, which is transmitted at 1,575.42
MHz. Each satellite transmits at the same frequency using a spread-spectrum
code-division multiple-access (CDMA) technique, and the handset distinguishes
4 Introduction
between them because each one transmits a different pseudorandom (PRN)

sequence.
The GPS satellites broadcast a ranging signal that a handset can use to deter-
mine how far the satellite is away from the handset. Each satellite also modulates a
navigation message (NAV) on top of the ranging signal. The NAV message can be
demodulated in order to determine the time and ultimately the location of the satel-
lite at the time of transmission. The NAV data is uploaded to each satellite by the
control segment regularly.
The NAV message includes satellite ephemerides, system time, satellite clock
behavior data, and status messages [5]. A summary of the format of the NAV mes-
sage is shown in Figure 1.1 (summarized from [6]). The NAV message is transmitted
as a series of subframes that include the satellite accuracy and health and satellite
clock correction, the ephemeris, and the almanac. The ephemeris contains a set of
parameters that describe the Keplerian orbit of the satellite. These parameters allow
the location of the handset to be calculated. A stand-alone (autonomous) GPS hand-
set needs to demodulate the first three subframes of each satellite to have enough
information to calculate the location of the satellite. The minimum amount of time
that it needs to do that is 18 seconds, but that is only possible if it starts demodulat-
ing right at the start of the new frame. The subframes are being continuously trans-
mitted and it is more likely that the handset will need the full 30 seconds plus the
time that it took to acquire the signal in the first place.
A GPS handset will generally allocate a different satellite search to each chan-
nel. When the handset is in a cold-start situation, that is, it does not have any cached
information about the constellation, it does not have information in order to choose
how to select the satellite that it assigns to each channel, so the TTFF is poor.
Once the handset has locked onto enough satellites, it can calculate its own
location using the location of each satellite and the measured range to each of them.
The process of calculating the handset’s location is known as geometric
trilateration.
300 bits at 50 bits per second—6s per subframe
Subframe 1– Satellite accuracy and health and satellite clock correction

6 subframes—30s per frame
Subframe 2 – Ephemeris
Subframe 3 – Ephemeris continued
Subframe 4 – Alamac, Special messages, Ionosphere and UTC model Pages 1-25
Subframe 5 – Almanac Pages 1-25
Figure 1.1 NAV message structure.

In a time-synchronized system, calculating a three-dimensional location would

require the location and distance to three satellites. A GPS receiver, however, is not
perfectly synchronized to GPS time, so four satellites are required in order to solve
for the receiver’s x, y, and z locations and the clock offset or clock bias t. The mea-
sured ranges to satellites are called pseudoranges because they are subject to the
clock biases of the handset and the satellites. A high-level model of the trilateration
process is shown in Figure 1.2. The position of the satellites S1 to S4 is known (calcu-
lated using the ephemeris) and the pseudoranges ρ1 to ρ4 have been measured. The
calculation process will then apply corrections in order to minimize the measure-
ment error. The trilateration determines the location of the GPS handset and its
clock bias (x, y, z, t). Figure 1.2 also shows an additional range measurement r1
from a terrestrial transmitter T1. This may be used as an additional input to the
trilateration. It is important to note that this is not a GPS measurement, so is not
subject to the same clock bias. The range r1 may have a different clock bias that
depends on the wireless system and the methods of measurement and synchroniza-
tion being used. The position calculation is discussed in detail in Chapter 5.
It is important to note that GPS measurements are subject to various errors and
the effect on the resulting location from some of these factors can be minimized by
modeling. Some inaccuracy can be introduced by errors in the ephemeris data or the
satellite clock, errors introduced by signal dispersion in the ionosphere, refraction
delay in the troposphere, multipath signals, and receiver measurement error. It is
important that the position calculation corrects for these factors or the accuracy of
the resulting location will be compromised.
1.6 Assisted-GNSS from a High Level
An Assisted-GPS server provides data to a wireless handset that is specific to the

approximate location of the handset in order to minimize the TTFF and maximize
the yield. The approximate location of the handset can be determined by various
means. If the handset is in a cellular network, it may come from the location of the
cell tower, it may have been entered by the user by selecting a city from a map, it
S 2 (x, y, z)
S 3 (x, y, z)
ρ2
ρ3 S 4 (x, y, z)
ρ4
S1(x, y, z) ρ1
r1
GPS handset
x, y, z, t T1 (x, y, z)
Figure 1.2 Geometric trilateration.

6 Introduction
may have been calculated using another location technology, or it may come from a
previously stored location in the handset.
The assistance data helps the handset lock onto satellites quickly in several
ways. It eliminates the need for the handset to demodulate and reconstruct the
broadcast navigation model. This is a significant saving because it takes 30 seconds
to decode the ephemeris for each satellite or longer when there are data bit errors or
weak signals. In addition, it may be impossible to demodulate the navigation model
from weak signals. Since the server provides information about the specific satellites
that are in view from the approximate location, the handset can constrain its satel-
lite search space. This constrained search space means that the handset can spend
more time detecting weaker signals from the satellites.
The handset uses the assistance data to lock onto the satellite signals and per-
form the position calculation (handset-based) or optionally returns the measure-
ments to the server to perform the calculation (handset-assisted). When the
calculation is performed on the server, it can make use of additional measurements
in order to improve both the accuracy and the yield of the location. Additional
range measurements may come from the wireless network such as uplink time dif-
ference of arrival (UTDOA) measurements, round-trip timing (RTT) measurements
in a UMTS network, timing advance (TA) measurements in a GSM network, digital
TV measurements (DTV), or measurements from any other terrestrial transmitters.
These additional measurements are particularly helpful in low signal environments
when there are not enough GPS satellite measurements.
Assisted Global Navigation Satellite System (A-GNSS) extends the concept to
other satellite navigation systems beside GPS. There may be a large number of
GNSS satellites orbiting the Earth within 10 years, all transmitting a variety of sig-
nals. This will give a receiver access to many more satellites and improve both accu-
racy and yield. More satellites means that position accuracy is less susceptible to
satellite geometry problems and provides greater redundancy when performing the
position calculation.
The simplified A-GNSS architecture is shown in Figure 1.3. A GNSS Reference
Server (GRS) collates information from the satellite broadcasts. It then provides this
information on request to an A-GNSS server so that it is available for the A-GNSS
handset. The time server provides accurate time to the A-GNSS server. This will
normally be done using Network Time Protocol (NTP).
The GRS is connected to a sparse network of GNSS receivers that are placed
geographically over the coverage area of the wireless network, and the central
server collates all of the information. The receivers are placed such that they can
receive information from each satellite that is in view of any of the handsets in the
network. This is because the ephemeris information is transmitted by each satellite
but is specific to the satellite that is transmitting it. A GRS that is covering continen-
tal United States, for example, may need receivers at each “corner” of the country to
receive the broadcast message from rising and setting satellites, but will generally
have more than that for redundancy. Note that in order to provide differen-
tial-GNSS (DGNSS) corrections, the receiver network would need to be much
denser than one designed to provide assistance data alone.
The A-GNSS server is a node in a wireless network that collates the data from
the GRS and exchanges data with the A-GNSS handset in order to calculate a
GNSS Reference
Server (GRS)
A-GNSS handset
Time server
A-GNSS Server Initial uncertainty area
(NTP)
Figure 1.3 A simplified A-GNSS architecture.
timely, accurate location. The protocol between the server and the handset is nor-
mally standards-based but may be proprietary. The A-GNSS server will establish a
connection to the GRS and periodically cache the data in order to serve it up to a
handset in whatever protocol is required to be compatible with the handset.
When an A-GNSS user in a cellular network makes an emergency call, or a ser-
vice is invoked that requires location, a message is sent to the A-GNSS server. The
A-GNSS server calculates the GNSS assistance data required using the location of
the radio access tower as the approximate location and provides it to the handset.
The handset locks onto as many satellites as it can within the time limit specified by
the server and calculates the location or optionally provides the measurements to
the A-GNSS server to calculate the location of the handset.
An example of messaging between an A-GNSS server and a handset is shown in
the scenario in Figure 1.4. Note that this is only an indicative message flow as the
standards support other mechanisms. The scenario could be initiated from
messaging through the cellular network, for example, if the A-GNSS user makes an
emergency call, or from an entity within the network. The entity within the network
A-GNSS Server A-GNSS Handset
A Measure position request
B Measure position response
C Measure position request
D Measure position response
Figure 1.4 Simplified A-GNSS messaging.

8 Introduction
would be a location-based application (LBA). The LBA may be a tracking applica-

tion or a find-a-friend service.
A location request is received at an A-GNSS Server and in step A in Figure 1.4,
the A-GNSS server sends a measure position request message to the handset. If the
handset has sufficient, current, cached GNSS assistance data, then, in the case of
handset-based GNSS, the handset will lock onto the satellites, perform the position
calculation and return the location in the measure position response message (step
B). In the case of handset-assisted GNSS, the handset will lock onto the satellites and
return the satellite measurements to the server to do the position calculation.
Generally, however, the A-GNSS handset will not have sufficient assistance
data and will send a response to the A-GNSS server with an indication of the assis-
tance data types that it requires in order to make the fix (step B). The A-GNSS server
will then send another request to the handset with the requested assistance data
types that are specific to the handsets location (step C). The handset’s location that
is used to determine the assistance data will often come from a database containing
the location and uncertainty of the serving cell in the cellular network. The handset
will then make the measurements and return them or return the result that it has
calculated (step D).
In the case of handset-based A-GNSS, the primary assistance data type is the
navigation model, which contains the ephemeris. The handset uses the information
in the ephemeris to calculate where the satellites are and how they are moving, in
order to refine its search and as an input to its position calculation. Other hand-
set-based assistance data types include the reference time, reference location, iono-
sphere model, UTC model, and the real-time integrity. These assistance data types
are shown in Table 1.1 and are discussed further in Chapter 4.
In the case of handset-assisted A-GNSS, the primary data type is the much more
compact acquisition assistance data type. The acquisition assistance data tells the
handset which satellites to search for and provides a search window in the time and
frequency domains for each satellite. The handset treats the search windows as rela-
tive search windows once the handset locks onto the first satellite. In this mode, the
handset has no need to calculate where the satellites are since it is not performing a
position calculation; instead, it returns the GNSS measurements to the A-GNSS
server in the response. The measurement includes the approximate time, the
code-phase chip measurements, the Doppler, the RMS error of the measurements,
and a multipath indicator. The server can then perform a self-contained position
calculation or make use of additional measurements and perform a hybrid location.
The assistance data types are discussed in detail in Chapter 4 and are shown in
Table 1.1. The assistance data types either are considered as global in nature or are
determined by selecting the satellites that are in view of the initial uncertainty area.
For example, the ionosphere model applies to the whole planet, so it is considered
global. Navigation model, in contrast, is only sent for each satellite that is in view of
the handset’s approximate location.
Table 1.1 shows a list of the primary A-GNSS assistance data types. It shows the
name of the assistance data type, a description of what it is used for, whether it is
global, and an indication of whether it is normally used for handset-assisted or
handset-based A-GNSS.
1.7 A-GNSS Protocols and Standards 9
Table 1.1 Primary A-GNSS Assistance Data Types

Assistance Data Handset- Handset-
Type Description Global Assisted Based
Reference time This data type allows the server to provide N Y Y
time to the handset. The handset can then
use that as the approximate time. This data
type may also contain the relationship
between the cellular network time and the
GPS time. In some protocols, GPS subframe
header information is also provided for sat-
ellites in view.
Reference location This field contains the approximate location Y N Y
of the handset and uncertainty of the loca-
tion to the handset in order for it to con-
strain its search space. In a cellular network,
this will normally be the location of the cell
and the uncertainty will be the boundary of
the cell coverage area.
Navigation model This field contains the per-satellite naviga- N N Y
tion model.
Ionosphere model The ionosphere model contains the fields Y N Y
that model the delays in the propagation of
the radio signals through the ionosphere.
UTC model The UTC model contains the fields that Y N Y
allow the user to determine the relationship
between UTC time and GPS time.
Acquisition assistance This data type provides the uncertainty N Y N
search windows for the satellites in view. It
provides the search windows in the time and
frequency domains, information about the
current NAV bit, and the azimuth and ele-
vation of the satellites.
Real-time integrity This data type contains a list of satellites Y N Y
that are presently considered bad and
should not be used by the handset.
Almanac The almanac is the coarse long-term model Y N N
of the satellite position and clocks.
D-GNSS This data type allows the server to provide N N N
per-satellite differential corrections based on
the initial uncertainty.
1.7 A-GNSS Protocols and Standards
A mobile location center (MLC) is a node that runs in various networks and can act
as a serving mobile location center (SMLC) [7], gateway mobile location center
(GMLC) [7], stand-alone SMLC (SAS) [7], SUPL location platform (SLP) [8], or
location information server (LIS) [9].
There are several different standards for the A-GNSS messaging between the
server and the handset. RRLP [10] is used by the SMLC and SLP, PCAP [11], and
RRC [12] in UMTS networks and TIA-801 [13] in CDMA networks. These proto-
cols are different ways of encoding the same basic information, but are specific to
the radio access technology.
10 Introduction
The secure user plane location (SUPL) architecture [8] is defined by the Open
Mobile Alliance (OMA) and allows the bypass of many of the traditional telecom-
munication elements by relying on SUPL functionality within the target device. This
makes network interoperability simpler. The SUPL-enabled terminal (SET) makes a
secure TCP/IP connection directly with the SUPL location platform (SLP). The SET
and the SLP exchange messages using the UserPlane Location Protocol (ULP) [14],
which is the transport for the underlying assistance data messaging. ULP supports
RRLP and optionally RRC and the TIA-801 [13]. Many operators have deployed
SLPs and many different SETs are available.
The assistance data standards (RRLP, PCAP, RRC, TIA-801) have had support
for GPS L1 C/A code assistance data for quite some time. Recently, support has
been added for the modernized GPS and other GNSS signals. This has been termed
Galileo and Additional Navigation Satellite Systems (GANSS). The SUPL specifica-
tion also facilitates Assisted-GNSS (A-GNSS).
The GANSS components allow an A-GNSS server to provide assistance data to
different types of handsets (for example, a Galileo handset-assisted-Galileo) and
handsets that have receivers capable of detecting satellites from multiple GNSSs (for
example, a combined GPS and Galileo receiver).
Standards are also being developed for providing location in Voice over Internet
Protocol (VoIP) networks. VoIP allows users to make telephone calls over the IP
network instead of the switched circuit network. Some VoIP providers presently do
not even provide access to emergency services such as 911 in the United States. The
National Emergency Number Association (NENA) and Internet Engineering Task
Force (IETF) are developing the architecture and standards for delivery of the loca-
tion within VoIP. It is likely that the handset will talk to the LIS using a protocol
that will encapsulate RRLP or some derivative messaging at its deepest layer.
1.8 Why Is an Accurate Location Required?
A GNSS-based location is generally represented as a latitude, longitude, and alti-

tude on a reference ellipsoid with an uncertainty at a given confidence (horizontal
and altitude). The GPS system uses the World Geodetic System 1984 (WGS 84) as
the coordinate reference frame, which models the Earth as an ellipsoid. Latitude and
longitude are points on the surface of the ellipsoid, altitude is relative to the surface
of the ellipsoid, and the uncertainty is expressed as an ellipse on the surface of the
ellipsoid with an altitude uncertainty. This type of location is often referred to as an
ellipsoid point with altitude and uncertainty ellipsoid, for example, in the Geo-
graphical Area Description (GAD) specification [15]. The uncertainty is provided at
a certain confidence level and is often unspecified, in which case, it is assumed to be
67%. The size of the calculated uncertainty ellipse depends on the geometry of the
measurements. and the larger the confidence, the larger the ellipse.
The major driver for A-GNSS in the marketplace is the accuracy that it can pro-
duce compared to other wireless location techniques and the improved yield. There
is a general perception from users that when they use their mobile device, it will pro-
vide them with a high-accuracy location and they may rely on the location as being
accurate even when it is not. If the location is calculated from a technology that is
1.9 Location Market 11
inferior to A-GNSS and the user is expecting A-GNSS technology, then expectations
will not be met.
The primary need to determine an accurate location is for emergency services
when the location of injured people is required to a high accuracy in order to dis-
patch aid to them. Another example of an application that requires high accuracy is
a navigation application that provides walking directions from the user’s current
location to the nearest service, such as the local doughnut shop.
It is important to note that A-GNSS is not the only high-accuracy location tech-
nology and that there are areas where the accuracy of the location that it provides is
poor. This includes indoors and areas with obstructions of the view of the sky, such
as in urban canyons.
1.9 Location Market
As devices have become more mobile and contain more features, users are expecting
them to be location-aware in order to maximize their utility. Many devices are
available today that already support A-GPS [16], and applications available for the
user are increasing on a daily basis. At the time of this writing, three out of four
smartphones support GPS and it is predicted that in only a few years, 9 out of 10
smartphones will have this capability [17].
1.9.1 E9-1-1
The deployment of A-GPS for cellular phone location has taken off in the United
States as a result of the Federal Communications Commissions (FCC) Enhanced
9-1-1 mandate (E9-1-1). This mandate requires for network-based solutions a
100-meter accuracy for 67% of calls, a 300-meter accuracy for 95% of calls and for
handset-based solutions, a 50-meter accuracy for 67% of calls and a 150-meter
accuracy for 95% of calls [18].
When an emergency call is initiated, a request for location for a particular hand-
set is received on the MLC. The required messaging is initiated and the resulting
location is cached on the platform. In the United States, the emergency services
coordination center, the public safety answering point (PSAP), will query the loca-
tion from the cache and may request updated locations. The location information
available to the PSAP operator allows the dispatch of the emergency services
response to the correct place.
1.9.2 Location-Based Services

There are many examples of LBAs in the marketplace today. Digital navigation is
one application where directions are provided to a specific service such as the near-
est pizza restaurant or cellular phone recharging service. The application may pro-
vide turn-by-turn directions in real time or show the desired location on a map
relative to the user’s current position.
A find-a-friend service is a service in which the user is provided with the location
of a configured group of friends in order to make contact with them. Loca-
12 Introduction
tion-based gaming is also becoming popular where the location of the user is a com-
ponent of the game.
Knowing a location also facilitates location-based charging and billing or
restrictions where a particular service may be restricted in certain regions. For
example, the digital television broadcast of a football match may be restricted from
users within a certain range of the stadium, for example, 50 kilometers, in order to
encourage them to attend the game. Alternatively, the users within the vicinity of
the stadium may be required to pay a premium to receive the broadcast.
Location-based messaging is an application where messages are triggered based
on the user’s proximity. For example, targeted advertising can be triggered. A sub-
scriber to a certain retail outlet approaches the vicinity of the outlet and is provided
with a voucher to entice him or her into the store. Another example is when a mes-
sage is received, alerting the user to the proximity of one of the user’s preconfigured
friends.
Tracking applications for both commercial and security applications are
another area where A-GPS has penetration. Knowing the location of goods or a
child is a service that can generate revenue.
1.9.3 Lawful Intercept Services

Lawful intercept services include services that are used by law-enforcement agencies
to determine the location of offenders. This may be in the form of tracking their
handset. GNSS is commonly used by law enforcement in the form of ankle bracelets
for parolees.
1.10 Java and Software Design for A-GNSS Applications
The Java programming language is a high-level language that has significant advan-
tages for implementing A-GNSS software. Its primary advantage is its simplicity,
which also leads to maintainability. Java contains the power of an object-oriented
language that can be implemented in a multithreaded nature and has high perfor-
mance. The automatic garbage collection is a useful feature. It is also portable, so
the hardware platform is flexible, and it facilitates rapid development and
prototyping, which result in the early testing of concepts and ultimately a better
product.
Java is very intuitive and comes with a library of preexisting code. There are
many tools available for Java development, including powerful (and free) integrated
development environments (IDEs). There were concerns about speed with earlier
versions of Java, but that is no longer an issue, as the speed has improved signifi-
cantly over recent releases [19].
All of these factors make Java a good basis on which to develop A-GNSS soft-
ware and to demonstrate the concepts explained in this book.
Java code fragments are shown to illustrate key points and algorithms through-
out the text. This book contains class and sequence diagrams in Unified Modeling
Language (UML) where they are helpful for explanation. The accompanying soft-
1.10 Java and Software Design for A-GNSS Applications 13
ware contains complete example code and applications that can be used to enhance
learning.
This book assumes that you are familiar with object-oriented (OO) design and
Java programming but have not developed software for A-GPS (or A-GNSS). It uses
standard OO conventions. A class is a collection of fields and methods and an
instance of the class represents an object. Objects interact to form an application.
Standard UML is used for class and sequence diagrams [20].
Online resources including updates will be available from [21]. The code was
developed for this book using Java SE 1.6, which can be downloaded [22]. It is also
a good idea to download the documentation. The code is compiled using Maven
[23], which is a tool to simplify the build process for software projects and is used to
build the source code and jar files. The Eclipse IDE [24] has been used throughout
development, but there is no requirement to use it.
Code and data files are organized in the Maven project into packages. An expla-
nation of each class and package and how to run them will be provided within the
Javadoc (Java’s documentation tool).
1.10.1 Coding in Java

Writing software is a creative process in which there are often many ways to achieve
the goal. The aim of a competent programmer is to make the software understand-
able by someone unfamiliar with the application area. This is achieved by coding
the simplest, most efficient solution. Other factors are consistency in the format and
layout of the code, clear code documentation and program element naming, and fol-
lowing object-oriented practices where objects encapsulate their own states and
behaviors.
A-GNSS software often requires heavy numerical computations. It is important
to have a good understanding of Java’s primitive data types in order that precision is
not lost. The key numeric data types are shown in Table 1.2. When choosing a data
type, the minimum and maximum possible values should be considered. When the
data is being represented in a large data structure, such as a large array, using the
smallest possible data type can result in a more efficient execution. Many GNSS cal-
culations will require the use of floating point numbers. The float and double primi-
tive data types in Java are the single precision (32 bit) and double precision (64 bit)
IEEE 754 values [25], and the ranges are shown in Table 1.2. The double and float
Table 1.2 Java Numeric Primitive Data Types

Number
Data Type Format of Bits Minimum Value Maximum Value
447Byte Twos complement 8 −128 127
Short Twos complement 16 −32,768 32,767
Int Twos complement 32 −2,147,483,648 2,147,483,647
Long Twos complement 64 −9,223,372,036,854,775,808 9,223,372,036,854,775,807
Float 32-bit IEEE 32 1.401298464324817E-45 3.4028234663852886E38
754 floating point
Double 64-bit IEEE 64 4.9E-324 1.7976931348623157E308
754 floating point
14 Introduction
Table 1.3 Java Bit Manipulation Operations Used Regularly for A-GPS
Operator Description Example Explanation of Example
> Shift the specified byte result = toc > 5 Shifts the bits in toc, 5 to the right,
toc = 1111 1000
number of bits to result = 0000 0111 and puts 0s in the MSBs.
the right.
< Shift the specified byte result = toe < 5 Shifts the bits in toe, 5 to the left,
toe = 0011 1111
number of bits to result = 1110 0000 and puts 0s in the LSBs.
the left.
| Bitwise OR. byte result = cus | crs The cus and the crs are combined
cus = 1010 1010
crs = 1001 1000 in a bitwise OR.
result = 1011 1010
& Bitwise AND. byte result = crc & mask The crc and the mask are combined
crc = 0110 0101
mask = 0000 1111 in a bitwise AND.
result = 0000 0101
data types can hold special values such as NaN (not a number), positive infinity,
and negative infinity. These are explained further in the Java SE Javadoc.
Bit manipulation is also an area of Java that is used heavily for A-GPS. This is
generally for encoding and decoding messages that are being sent to and from other
entities in the network. The bitwise AND, bitwise OR, and bit shifting operations
are an area where particular care is needed. The bit manipulation commands used
regularly while encoding and decoding messages are shown in Table 1.3 with some
examples. The most significant bits (MSB) are the higher bits (towards the left of the
bit string), while the least significant bits (LSB) are the lower bits (towards the right
of the bit string).
1.11 Organization of This Book
The rest of the chapters of this book contain a practical exploration of A-GNSS with
a particular focus on A-GPS. Some theoretical background is provided, but the text
is more focused on the design and implementation of an A-GPS server. Source code
is provided that illustrates the key algorithms involved in the provision of assistance
data and the calculation of the location. The location protocols are discussed in
detail, including the support for all of the GNSSs and not just GPS.
References
[1] Parkinson, B., et al., Global Positioning System: Theory and Applications, Vol. 1, Washing-
ton, D.C.: American Institute of Aeronautics and Astronautics, Inc., 1996.
[2] Kaplan, E. D., and C. J. Hegarty, (eds.), Understanding GPS: Principles and Applications,
2nd ed., Norwood, MA: Artech House, 2006.
[3] Misra, P., and P. Enge, Global Positioning System: Signals, Measurements, and Perfor-
mance, 2nd ed., Lincoln, MA: Ganga-Jamuna Press, 2006.
[4] Conley, R., et al., “Performance of Stand-Alone GPS,” in Understanding GPS: Principles
and Applications, 2nd ed., E. D. Kaplan and C. J. Hegarty, (eds.), Norwood, MA: Artech
House, 2006.
1.11 Organization of This Book 15
[5] GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User Inter-
faces, Interface Specification, IS-GPS-200, Navstar GPS Joint Program Office, El Segundo,
CA, 2004.
[6] GPS Navstar Joint Program Office, Global Positioning System Standard Positioning Service
Signal Specification, 4th ed., December 2008.
[7] 3GPP TS 23.271 Third Generation Partnership Project; Technical Specification Group Ser-
vices and System Aspects; Functional stage 2 description of Location Services (LCS), 2009.
[8] Secure User Plane Location Architecture, Open Mobile Alliance, OMA-AD-SUPL, 2009.
[9] Dawson, M., J. Winterbottom, and M. Thomson, IP Location, New York: McGraw-Hill/
Osborne Media, 2006.
[10] 3GPP TS 44.031 Third Generation Partnership Project; Technical Specification Group
GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (MS) - Serv-
ing Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP), 2009.
Radio Access Network; UTRAN Iupc interface Positioning Calculation Application Part
(PCAP) signaling, 2009.
Radio Access Network; Radio Resource Control (RRC); Protocol Specification, 2009.
[13] 3GPP2 C.S0022 Position Determination Service Standard for Dual Mode Spread Spectrum
Systems, 2004.
[14] UserPlane Location Protocol, Open Mobile Alliance, OMA-TS-ULP, 2009.
[15] Colwell, S., “Flying Off the Shelves: A White-Hot Market for Consumer GPS,” GPS World,
April 1, 2007.
[16] ABI Research, GPS-Enabled Handsets, Market, Technology and Business Factors Driving
the Growth of GPS, A-GPS and Hybrid Positioning for Mobile Handset Location, January
20, 2009.
vices and System Aspects; Universal Geographical Area Description (GAD), 2008.
[18] Federal Communications Commission (FCC) OET Bulletin 71, Guidelines for Testing and
Verifying the Accuracy of Wireless E911 Location Systems, April 12, 2000.
[19] Java Performance Tuning, http://www.javaperformancetuning.com
[20] Fowler, M., UML Distilled, 3rd ed., Reading, MA: Addison-Wesley, 2004.
[21] Artech House, http://artechhouse.com/static/reslib/harper/harper1.html.
[22] Java SE Overview, http://java.sun.com/javase/.
[23] Maven software project management and comprehension tool, http://maven.apache.org/
index.html.
[24] Eclipse IDE, http://www.eclipse.org/.
[25] IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985, IEEE,
New York, 1985.
CHAPTER 2
Coding for GNSS and the Coordinate

Reference Frame
This chapter introduces the Java source code that accompanies this book and works
through some of the classes. This is done in the context of the GPS coordinate refer-
ence frame and WGS 84 coordinates. The coordinate system is introduced and the
equations for converting between the Cartesian and the geodetic representation are
given. The project mode of the source code is discussed and the modification and
building of the source code is described. The WGS 84 implementation is studied in
detail along with its unit tests. Performance benchmarking, code coverage, and con-
figuration management are also discussed.
2.1 Coordinate Reference Frame
Coordinates are a set of numbers that define position in relation to an origin. The
coordinate reference frame (CRF) or coordinate reference system (CRS) is the origin
and axes and a set of transformations that define the location. The CRF includes
both a coordinate system and a reference frame. There are many different coordi-
nate systems and reference frames. This section introduces the reference frames that
are used throughout this book. They are the Cartesian coordinate system, the spher-
ical coordinate system, and the ellipsoidal coordinate system. The ellipsoidal
coordinate system is often called a geodetic system.
A Cartesian coordinate system is a linear system with the origin at a certain
fixed point with three axes defined that are perpendicular to each other. A point in
space in the Cartesian coordinate system is defined relative to the origin and is in the
form of (x, y, z). The Cartesian coordinates make it easy to understand and calcu-
late geometric quantities. The Cartesian coordinate system is illustrated in Figure
2.1. The point P is shown at coordinates (x, y, z) in the Cartesian coordinate system.
Spherical coordinates are also called spherical polar coordinates and are used
for defining positions on a sphere. As shown in Figure 2.2, the point P(r, θ, φ) is
defined by the distance r from the origin, θ is the azimuth angle in the x-y plane, and
φ is the altitude angle from the x-y plane.
The relationship between the point P in the Cartesian coordinate system and the
spherical coordinate system is given by
x = r cos φ cos θ
y = r cos φ sin θ (2.1)
z = r sin φ
17
18 Coding for GNSS and the Coordinate Reference Frame
z-axis
P (x,y,z)
y-axis
x
x-axis
Figure 2.1 Cartesian coordinate system.
z-axis
P(r, θ, φ)
θ y-axis
x-axis
Figure 2.2 Spherical coordinate system.
r= x 2 + y2 + z 2
⎛ z ⎞
φ = sin −1 ⎜ ⎟ (2.2)
⎜ x 2 + y2 + z 2 ⎟
⎝ ⎠
⎛ y⎞
θ = tan −1 ⎜ ⎟
⎝ x⎠
2.2 World Geodetic System 1984
The World Geodetic System 1984 [1] is a standard coordinate frame and reference
surface that is used for GPS. The origin of the coordinate frame (0, 0, 0) is at the
Earth’s center of mass. The reference frame consists of Cartesian and ellipsoidal
coordinates.
GPS calculations are generally performed in the Earth-centered Earth-fixed
(ECEF) Cartesian coordinate system shown in Figure 2.3. This Cartesian reference
frame is a reference frame that rotates as the Earth rotates. The x and y axes are
coplanar with the equator, with x pointing in the direction of where the prime
meridian intersects the equator and z being normal to the x-y plane in the direction
of the geographic North Pole. The scale along the axes is in meters. Most of the cal-
culations described in this book are performed in the ECEF Cartesian coordinate
system, but are often transformed into ellipsoidal coordinates for presentation to
the user or end application (latitude, longitude, and altitude). The latitude is a mea-
sure from the equator in degrees from 0 at the equator to 90 at the North Pole; it is a
negative value towards the South Pole, so the range is −90 to +90. The longitude is
similarly measured in degrees around the z-axis from −180 to +180. The end user or
application is normally responsible for converting the data from the WGS 84 refer-
ence frame to the local reference frame.
In order to represent a location as coordinates on an ellipsoid, a model of the
ellipsoid is needed. There have been many models used and improved over time but
the GPS system uses the World Geodetic System 1984 (WGS 84) [1]. The model of
the ellipsoid is shown in Figure 2.4. The longer axis of the ellipsoid is from the
Earth’s center through the equator, and the smaller one is through the pole.
The ellipsoid uses the parameters in [1] as the basis for the WGS 84 model.
WGS 84 constants that are used in calculations shown in this book and the accom-
panying source code are shown in Table 2.1.
z-axis
P (x, y, z)
Prime
meridian
Equator y-axis
x-axis
Figure 2.3 Earth-centered Earth-fixed coordinate system.

Pole
Semiminor axis
Semimajor axis
Equator
Figure 2.4 Ellipsoid model.
Table 2.1 WGS 84 Parameters

Parameter name Symbol Constant
Semimajor axis a 6,378,137.0 meters
Flattening f 1/298.257223563
Semiminor axis b 6,356,752.3142 meters
Earth’s rotation rate Ωe 7.2921151467 × 10−5 rad/sec
2.99792458 × 10 meters/sec
8
Speed of light c
Universal gravitation parameter μ 3.986005 × 10 meters /sec
14 3 2
Figure 2.5 shows how latitude, longitude, and height are represented on the
ellipsoid as geodetic coordinates. The longitude λ is the angle between the user and
the x-axis, measured in the xy-plane. It is normally specified in degrees and ranges
from −180° to +180° where 0 represents the prime meridian. The latitude ϕ is the
angle between the xy-plane and the projection of the normal to the ellipsoid. The
height h, or altitude, is the minimum distance between P and the reference ellipsoid.
Note that h is the height from the reference ellipsoid and not sea level.
The widely used method to convert from ECEF to geodetic coordinates is a
method described by Bowring [2] and the equations are shown in (2.3). It is a
noniterative solution and provides centimeter accuracy for heights less than 1,000
kilometers. An iterative version of the calculation is provided in [3]; the noniterative
version is based on the fact that the single first approximation of θ is very accurate.
In (2.3), x, y, z are the WGS 84 ECEF coordinates and ϕ, λ, h is the WGS 84 latitude,
longitude, and height (or altitude) above the ellipsoid. a is the semimajor axis and b
is the semiminor axis. e′2 is the second eccentricity squared, N(ϕ) is the radius of
curvature in prime vertical, e2 is the eccentricity squared, and f is the flattening.
z-axis
P (x, y, z)
h
Normal to ellipsoid
ϕ (latitude)
y-axis
Equator λ (longitude)
x-axis
Figure 2.5 Geodetic coordinates.
⎛ z + e' 2 b sin 3 ζ ⎞
ϕ = a tan ⎜ ⎟
⎝ p − e 2 a cos 3 ζ ⎠
λ = a tan( y, x )
p
h= − N( ϕ)
cos ϕ
where
p= x 2 + y2
⎛ za ⎞ (2.3)
θ = a tan ⎜ ⎟
⎝ pb ⎠
a2 − b2
e' 2 =
b2
a
N( ϕ) =
1 − e sin 2 ϕ
2
e 2 = 2f − f
a−b
f =
a
Converting geodetic coordinates to ECEF is performed using (2.4). The vari-

ables are the same as those defined for (2.3).
x = (N( ϕ) + h) cos ϕ cos λ

y = (N( ϕ) + h) cos ϕ sin λ (2.4)
z= ((N( ϕ)(1 − e ) + h))sin ϕ

2
2.3 Source Code Structure and Management
The Java code accompanying this book is built into a project using Maven [4].
Maven is described in Appendix B and has been designed for ease of use. It has a few
simple commands described next that will allow you to make use of the source code.
It is also a very powerful tool for managing larger projects, but for this project, we
are only using its basic functionality. Before using it, you will need to download it
and do the necessary installation by following the installation instructions. In addi-
tion, you will need to have the Java SE SDK installed.
The source is organized using a standard project structure. This is so that a
developer familiar with one project will immediately feel at home when moving to a
new project. The project directory structure for the accompanying source code
including the WGS 84 classes is shown in Figure 2.6. Throughout this book, the
accompanying software is referred to as the project.
At the highest level, the directories are split between src, which contains the
source code, target, which includes the files that are the results of the build, and
batch, which contains some batch files to invoke the targets. The source code is split
between the main classes and the test classes. The main source code classes are in
project directories under the ServerAgps directory. Figure 2.6 only shows the WGS
84 classes, but there are many more directories under ServerAgps. The target direc-
tory contains the project’s jar file, the classes directory, which contains the classes
that have been built, and the test-classes, which contain the classes built from the
test directory. The reports directory contains the reports of the unit test results and
the apidocs contains the Javadoc.
To build the code, you will need to use the command line interface of your
machine. Note that Maven is integrated into the major IDEs and can be invoked
from there depending on which one you are using, but is discussed in terms of the
Figure 2.6 Project structure.

command line interface in this book. To build the Maven project, use the following
command from the highest level in the archive, that is, the serverAgps directory:
mvn package
This command will build all of the source code in the project, run all of the tests
defined in the test classes, and build the jar file. The tests in the test classes are writ-
ten using the JUnit [5] unit testing framework.
Once built, the classes are run directly from the jar file. There are some batch
files in the batch directory that run certain classes that are discussed later in this
book.
2.4 WGS 84 Implementation
The Java class Wgs84Coordinate (com.ServerAgps.wgs84.Wgs84Coordinate)

implements the code to encapsulate the WGS 84 functionality. The complete code
for the class is in the project and some segments of code are reproduced and dis-
cussed here. An instance of Wgs84Coordinate is constructed without any parame-
ters and can be set with either WGS 84 ECEF coordinates or WGS 84 geodetic
coordinates. It has accessors to retrieve the components of the coordinates, that is,
the latitude, longitude, altitude, x, y, z. It also contains some calculation methods
that can be used by other classes, such as the straight line distances between two
points or elevation from one point to another, and some private methods that
perform intermediate calculations.
To create an instance of this class and set it to a specific Cartesian ECEF loca-
tion, the following code is used:
Wgs84Coordinate coord = new Wgs84Coordinate();
coord.setEcef(-2508506.07, -4637174.91, 3579499.9);
The first line of code creates an instance of the class (instantiates it), and the sec-
ond line sets its value to the specified x, y, and z by invoking its setEcef() method. The
algorithm for the setEcef() method was shown in (2.3) and the code is shown here.
1. /**
2. *Settor for wgs84 instance passed Cartesian ECEF coordinates. This method is
3. *passed the WGS 84 ECEF x, y and z. It saves the coordinates in ECEF Cartesian
4. *format and also as Geodetic coordinates. To do that it needs to convert the
5. *coordinates and it does that using the non-iterative solution described in: 
6. *Bowring, B., July 1976, “Transformation from spatial to geographical coordinates”,
7. *Survey Review, XIII, 181, July 1976, pg 323-327.
8. *
9. *@param _x the x coordinate.
10. *@param _y the y coordinate.
11. *@param _z the z coordinate.
12. */
13. public void setEcef(double _x, double _y, double _z)
14. {
15. this.x = _x;
16. this.y = _y;
17. this.z = _z;
18.
19. // If it is one of the poles then set it straight away and return
20. if ((this.x == 0) && (this.y == 0))
21. {
22. this.longitude = 0;
23. if (this.z > 0)
24. {
25. this.latitude = 90;

26. this.altitude = this.z - B_SEMI_MINOR;
27. }
28. else
29. {
30. this.latitude = -90;
31. this.altitude = this.z + B_SEMI_MINOR;
32. }
33. return;
34. }
35.
36. //p is an intermediate step in the calculation
37. double p = Math.sqrt((this.x * this.x) + (this.y * this.y));
38.
39. //theta is the parametric parametric latitude of the point P’
40. double theta = Math.atan((this.z * A_SEMI_MAJOR)/(p * B_SEMI_MINOR));
41.
42. //the latitude is calculated in radians so we need to convert it to degrees
43. this.latitude = Math.toDegrees(Math.atan(
44. (this.z + (SECOND_ECCENTRICITY_SQUARED * B_SEMI_MINOR * Math.pow(Math.sin(theta),
3)))
45. /
46. (p - (E_SQUARED * A_SEMI_MAJOR * Math.pow(Math.cos(theta), 3)))
47. ));
48.
49. this.longitude = Math.toDegrees(Math.atan2(this.y, this.x));
50.
51. this.altitude=(p/Math.cos(Math.toRadians(this.latitude))) - this.calculateN(this.
latitude);
52. }
The first thing you will notice is that the method is documented using Javadoc
(lines 1–12) [6]. Javadoc is a method for documenting source code and a tool for
generating source code documentation in HTML. Javadoc is used for documenting
the code at the package level, class level, and method level and is considered to be a
good practice by Java developers. The Javadoc is delimited by the special string
“/**”. The method comment shown includes a free-form description of what it does
and a description of each variable with the @param keyword. To generate the
Javadoc in the Java API form from your source code, use the Maven command:
mvn javadoc:javadoc
The Javadoc is generated in the apidocs directory (see Figure 2.6).

Considering the setEcef() method, the parameters that are passed in the method
have been prefixed with a “_” character so that they do not shadow the class level
variables that have the same name. A variable is shadowed if there is another vari-
able with the same name that is closer in scope. In this case, if the _x parameter, for
example, was passed in as x, this would shadow the class level x. This may be con-
fusing to someone reading or modifying the code, who may end up using the x that
was passed into the method instead of the class level x. Another way of ensuring
that this does not happen is by using the this qualifier to qualify access to all class-
level fields and methods.
The setEcef() method initially saves the passed ECEF coordinates in member
variables (lines 15–17). It then performs a check to determine whether the input val-
ues indicate that the location is at the North or South Poles (line 20). This will be the
case if both x and y are zero. If so, there is no need to calculate the geodetic coordi-
nates, but they can be set directly. The only thing that needs to be set is the altitude.
This will depend on the value of z relative to the distance from the center of the
Earth to the WGS 84 ellipsoid at the pole. This is the length of the semiminor axis
(see Figure 2.4). The WGS 84 semiminor axis is stored as a class level constant. It is
defined as protected so that it can be used by other classes in the same package, as
static so that there is only ever one instance of this variable no matter how many
instances of the class are instantiated, and as final so that it cannot be changed once
it is defined. The name is prefixed with a B since the semiminor axis is often referred
to as b in equations, for example, in (2.3). Its definition is:
/** The semi-minor axis of the ellipsoid as defined by WGS 84. */
protected static final double B_SEMI_MINOR = 6356752.3142;
In order to start the numerical conversion from ECEF to geodetic coordinates,

some of the intermediate variables need to be calculated. As shown in (2.3), p is cal-
culated as the square root of the sum of x squared and y squared (line 37). To per-
form the square root operation, we are using Java’s built-in function from its Math
class. The Math class contains methods for various basic numeric operations such as
trigonometric functions, converting between numerical formats, simple random
numbers and rounding. Performance of the methods in the Math class may not be
optimized for each platform on which Java can run, but using this class will ensure
that your code will produce similar results on each platform.
The square root method Math.sqrt() is a public method, which means that it can
be called from any package, it is static, which means that it can be invoked without
needing to create an instance of the Math class to invoke the method on it, and it
returns a value of the primitive type double. It is worth being familiar with the Java
API, which contains the details of all of Java’s supplied classes and the methods
available in the classes.
Calculating the intermediate variable, theta (θ) on line 40, makes use of
Math.atan() and it uses the WGS 84 constants for the semimajor and semiminor
axes. Finally, setEcef() calculates the latitude and longitude in degrees and the alti-
tude in meters using the defined formula (lines 43–49). When writing code, it is
important to consider the units of the variables that are used for the calculations.
The trigonometric methods in the Math class take values that are in radians and not
degrees. For this reason, the Math.toRadians() and Math.toDegrees() methods are
used to perform the conversions to and from the values.
To calculate the altitude (line 51), the N(ϕ) needs to be calculated. It could be
calculated directly in the setEcef() method; however, it is also required in (2.4) and
used in the setGeodetic method which is described in detail later. For this reason, it
is extracted out into a method by itself. The method to calculate N(ϕ) is:
/**
*This method calculates N. It is an intermediate variable that is used to translate between ECEF
*Cartesian coordinates and Geodetic coordinates. It is the radius of curvature in prime vertical.
*
*@param _latitude the latitude in degrees.
*
* @return the calculated value of N.
*/
private double calculateN(double _latitude)
{
double N = A_SEMI_MAJOR/Math.sqrt(1 - (E_SQUARED * Math.pow(Math.sin(Math.toRadians
(_latitude)),2)));
return N;
}
The calculateN() method returns the value of N and that is indicated in the
Javadoc with the @return keyword and a description of what is returned. The
method is private since it is only used within this class. This method calculates N
using some of the methods from the Math class and returns the result.
The other significant piece of functionality in the Wgs84Coordinate class is the
procedure to create a location using a latitude, a longitude, and an altitude. This is
done using the setGeodetic() method as shown next. Note that the setGeodetic()
method returns a Java primitive type called a Boolean which will be true if the coor-
dinate was created successfully, so it needs to be checked by the calling class.
Wgs84Coordinate coord = new Wgs84Coordinate();
boolean success = coord.setGeodetic(33.61041480,-114.71485132, 85.9185);
if(success)
{
//coordinate is ok
}
The algorithm for the setGeodetic() method was shown previously in (2.4) and
the Java code is shown here:
1. /**
2. *Settor for wgs84 instance passed Geodetic coordinates. This method is passed the latitude,
longitude and
3. *altitude in WGS 84 geodetic coordinates. It does some range checking and stores the coor-
dinates locally. It
4. *also saves the coordinates in ECEF Cartesian format. To do that it needs to convert the
coordinates.
5. *
6. * @param _latitude the latitude in degrees.
7. * @param _longitude the longitude in degrees.
8. * @param _altitude the altitude in meters.
9. *
10. * @return true if the coordinate is successfully set.
11. */
12.public boolean setGeodetic(double _latitude, double _longitude, double _altitude)
13. {
14. //Do some range checking to determine whether the inputs are valid.
15. if(_latitude < -90 || _latitude > 90 || _longitude < -180 || _longitude > 180)
16. {
17. //There is a problem with one of the parameters
18. return false;
19. }
20.
21. //Set the values
22. this.latitude = _latitude;
23. this.longitude = _longitude;
24. this.altitude = _altitude;
25.
26. //Call a method to perform this intermediate calculation
27. double N = this.calculateN(_latitude);
28.
29. //Calculate x,y and z using the non-iterative method
30. this.x = (N + _altitude) * Math.cos(Math.toRadians (_latitude)) *
Math.cos(Math.toRadians(_longitude));
31. this.y = (N + _altitude) * Math.cos(Math.toRadians (_latitude)) *
Math.sin(Math.toRadians(_longitude));
32. this.z = ((N * (1 - E_SQUARED)) + _altitude) * Math.sin(Math.toRadians(_latitude));
33.
34. return true;
35.}
This method first checks to see if the latitude and longitude are within the valid
limits of their range (line 15). The latitude range is from 0 at the equator to +90 at
the North Pole and −90 in the other direction at the South Pole. The longitude range
starts at 0 at the prime meridian and goes to +180 in the easterly direction or −180
in the westerly direction from the meridian. The method returns false to indicate
2.5 Unit Testing 27
that the coordinate was not set up correctly (line 18). If the latitude and longitude
are in range, the remaining code is executed and the method returns true (line 34).
The implementation described does not provide much information to the calling
class and relies on the calling class checking the result. Another way to implement
this method would be by using Java exception handling. To do this, the
setGeodetic() method declares that it can throw a specific exception, and it throws
that exception if the latitude or longitude is invalid and the exception must be
caught and processed by the calling method. The advantage of that method is that
more information can be provided in the exception about which input value is
incorrect and the onus is on the calling method to implement the code to catch the
exception.
The rest of the method steps through and calculates the conversion to ECEF
coordinates. It is worth noting that when a calculation is performed in Java, the
result will be of the same precision as the operand with the greatest precision. For
example, when calculating z, there is an expression 1 – E_SQUARED. The defini-
tion of E_SQUARED is:
/** The eccentricity squared derived from flattening WGS 84. */
private static final double E_SQUARED = (2 * FLATTENING) - (FLATTENING * FLATTENING);
As shown, E_SQUARED is double precision, 1 is an integer, and the result of

subtracting a double from an integer is a double.
2.5 Unit Testing
Unit testing is the process of testing each individual unit of software that makes up
an application. A unit is the smallest testable part of an application. This is normally
method level testing and the aim is to test each type of input for each method in
order to determine whether (or confirm that) the code successfully handles the
input. The goal of unit testing is to test that each individual component of the soft-
ware is correct so that when it is combined with other software, it is more likely to
work. Unit tests are also useful for developers to see how the code works by provid-
ing examples of how to use the class.
When writing the unit test cases, you do not need to write a test case for every
possible input, but for each case that needs to be handled.
The aim is to test successful cases as well as the error conditions. For example,
when testing the Wgs84Coordinate class, you would probably want to test the fol-
lowing things:
• Convert a known location from ECEF to geodetic coordinates.

• Convert a known location from geodetic to ECEF coordinates.
• Validate the above for locations in both the Northern and Southern hemi-
spheres and the Eastern and Western hemispheres.
• Validate the conversion at the North and South Poles.
• Validate the conversion at some locations around the equator (0° latitude)
and extremes of longitude (0, −180, +180).
• Verify that the class will not accept invalid values or latitude.
• Verify that the class will not accept invalid values for longitude.
There are significant advantages to automating the test cases so that they can be
run on a regular basis in order to detect any problems that may have been inadver-
tently been introduced by changes in the code.
Maven is integrated with the open source JUnit framework [5], which handles
the administration of the automated testing, which leaves us to concentrate on
developing the test cases. When the source code is built, the test cases are run and a
report is produced that contains the success or failure of each test.
The Wgs84CoordinateTest class contains a set of tests that validate the correct oper-
ation of the Wgs84Coordinate class. The Wgs84CoordinateTest class is in the wgs84
directory within the test source code of the project. The full path name to the source code
is: serverAgps/src/test/java/com/ServerAgps/wgs84/Wgs84CoordinateTest.java.
The Wgs84CoordinateTest class extends JUnit’s TestCase class. Each test case
is in its own separate method and it uses the assert method to indicate success or fail-
ure of the test. For example, here is the method with the test case to test conversion
of a known ECEF location into a geodetic location:
1. /**
2. * Tests a known conversion from ECEF to Geodetic.
3. * Fire Camp 9, Sylmar, Los Angeles, California, USA
4. * Geodetic coordinates:
5. * 34.35317990 -118.41142498 1137.9958
6. * Cartesian ECEF coordinates:
7. * -2508506.07 -4637174.91 3579499.9
8. */
9. public void testConversionForKnownLocationEcefToGeodetic()
10. {
11. Wgs84Coordinate coord = new Wgs84Coordinate();
12. coord.setEcef(-2508506.07, -4637174.91, 3579499.9);
13.
14. assertTrue(“Conversion from ECEF to Geodetic for known location”,
15. matchDouble(coord.getLatitude(),34.35317990,PRECISION_5_DEC) &&
16. matchDouble(coord.getLongitude(),-118.41142498,PRECISION_5_DEC) &&
17. matchDouble(coord.getAltitude(),1137.9958,PRECISION_1_DEC));
18. }
The test method checks the conversion of the coordinates at Sylmar, LA. The
method constructs an instance of the Wgs84Coordinate class and then calls its
setEcef() method with the ECEF coordinates (line 12). The assertTrue() method is
part of the JUnit framework and is passed a string that labels the test case and the
conditions under which to pass the test case. The matchDouble() is a private
method that determines whether the values match to the given precision. In this
case, we are checking the latitude and longitude to 5 decimal places and the altitude
to 1 decimal place. The latitude, longitude, and altitude are retrieved from the WGS
84 object using its accessors.
If the values match, then success is passed as the second parameter to the assert()
and the test case passes. If the test case fails, the unsuccessful result is written to the
report and standard output with the string provided to the assert().
The test class contains a set of other test cases that are run each time that the
package is built and cover most of the tests listed earlier. It is worth browsing
through the test cases.
2.6 Debugging 29
2.6 Debugging
When unit tests fail or something goes wrong when running the software, a
debugger is the software developer’s best friend. A full-screen symbolic debugger is
standard with most IDEs and is very helpful when diagnosing problems with soft-
ware. Typical functionality of a good debugger includes the facilities to run code
step by step, setting certain points for the code to stop (break-points), allowing
access to variables, and even changing variables on the fly. The debugger is one of
the most powerful tools that a developer can use.
In addition, Java also provides many tools to aid debugging such as the Java
heap analysis tool, Java monitoring and management console, Java memory map,
and the JVM statistical monitoring tool.
2.7 Performance Testing and Benchmarking
Performance was a particular issue in earlier versions of Java, where it developed a

poor reputation for speed of processing. Since those early days, the performance of
Java has improved enormously and it is now almost on par with other programming
languages. Software that implements GNSS algorithms is highly mathematical and
numerically expensive. Traditionally, GNSS software has been implemented in plat-
form-specific, compiled languages such as C or C++.
One of the key goals of developing software is for clarity and maintainability.
The focus during development should be on producing correct, bug-free code. It is
best not to performance-tune your code unless it is required and should only be
done once the code is functionally correct. This does not mean that performance
should be ignored throughout development; it just means that it should not be the
primary focus. Once the functionally correct code has been developed, it can be
benchmarked in order to determine whether performance tuning is required.
The performance requirement may come from a user experience or, for a mes-
sage-processing system such as an A-GPS server, from predicted traffic load. It is not
unusual for an A-GPS server to be specified to run several hundred transactions per
second; each one of these transactions may be a position calculation, each of which
requires a large number of calculations.
Once you decide that performance tuning is required, it is a matter of measuring
what the code is presently doing in order to make improvements. One way to do this
is by using a profiling tool in order to identify the bottlenecks [7].
In order to determine how the WGS 84 code is performing, a benchmark can be
established. A benchmark test runs a specific set of calculations a large number of
times while recording the overall amount of time that the run took. This benchmark
can be used as a baseline for improvements or may act as a unit test that is run occa-
sionally to validate that it is performing well, assuming that the hardware platform
stays the same. The following is the code that is in the main() method of the
Wgs84CoordinateTest class. The main components of a benchmark measurement
are a mechanism to run for a period of time to minimize affects of other transitory
processes that are running on the CPU, recording the start (line 13) and finish times
(line 23) as close as possible to the iteration loop (lines 14–22), and some output to
report on the results (lines 26–27). Inside the iteration loop for the WGS 84 bench-
mark test are calls to the methods to set the different types of coordinates (lines
16–21). The set methods both convert to the other type of coordinate format so that
the benchmark test is running all of the key code.
1. /**
2. * This is the main method of the test class and is being used to run a benchmarking
3. * test for performance
4. *
5. * @param args the command line arguments.
6. */
7. public static void main(String[] args)
8. {
9. Wgs84Coordinate coord = new Wgs84Coordinate();
10. System.out.println(“WGS 84 benchmarking tests starting...”);
11.
12. int numberOfIterations = Wgs84CoordinateTest.NO_ITS_PERFORMANCE_TEST;
13. long startTimeMs = System.currentTimeMillis();
14. for(int i = 0; i < numberOfIterations; i++)
15. {
16. coord.setGeodetic(-34.4, 150.1, 32);
17. coord.setGeodetic(-34.4, -30, 32);
18. coord.setGeodetic(34.4, -30, 32);
19. coord.setGeodetic(34.4, 150.1, 32);
20. coord.setEcef(-2508506.07, -4637174.91, 3579499.9);
21. coord.setEcef(-2223206.72, -4830299.8, 3510587.59);
22. }
23. long endTimeMs = System.currentTimeMillis();
24. double transactionsPerSecond = numberOfIterations/((endTimeMs - startTimeMs)/1000.0);
25.
26. System.out.println(“Total time for test : ” + ((endTimeMs -startTimeMs)/1000.0) +
“ seconds”);
27. System.out.println(“TPS: ” + transactionsPerSecond);
28.}
This benchmark test can be run from the batch job wgs84test.bat in the batch
directory of the project.
2.8 Code Coverage Analysis
Code coverage analysis is a mechanism that allows the developer to determine

whether all of the paths through a piece of software have been tested by unit test
cases. It operates on the source code and records the lines of code that have been
executed throughout the unit testing period. It is very useful to determine whether
all of the functionality that has been written has been tested by the unit test cases. It
can also identify code that is no longer needed.
On the other hand, however, code coverage analysis cannot determine whether
all of the functionality is tested by the test cases. For example, if there is no checking
for invalid input for a particular method and there is no corresponding test case
with invalid input, then that problem will not be exposed through code coverage
analysis.
A code coverage tool will normally report on the execution of the code at a
method level and show the paths that have and have not been tested, along
with reporting on the overall percentage of the code that has been tested by the unit
tests.
EMMA [8] is a freely available code coverage tool that measures and reports
code coverage and is available as a Maven plug-in. It generates reports in HTML
format that can be browsed in order to view the statistics and the exact lines of code
2.8 Code Coverage Analysis 31
that have not been executed. To run code coverage on the project, the following
Maven command is used:
mvn emma:emma
This command runs the unit tests while the code coverage tool measures the
lines of code that are executed. The results are stored in the emma directory (refer to
the project structure in Figure 2.6). The report is formatted so that it provides the
overall code coverage figures and allows you to browse down to the code coverage
of individual classes within the project.
The code coverage report for the Wgs84Coordinate class is shown in Figure 2.7.
It shows that 12 of the 13 methods in the class have been invoked (or 92% of the
methods). It also shows that 99% of code blocks have been executed and 95% of
the lines of code have been executed. The listing of methods shows that the main
method is two lines long, but has not been invoked by the unit tests. The code cover-
age tool allows you to select the name of the method and the code is displayed with
the lines that have not been executed as highlighted.
The code coverage tool raises awareness to the developer of areas that may be a
potential problem. Once you are aware of the issue, it is then up to you to make a
decision on whether and how to address the problem.
Generally, code that has not been executed by the test suite will result in one of
the following actions:
• A test case is added to test the condition highlighted by the test case.
• The code may be removed if it is not being used.
• No action taken if the code is considered trivial enough not to test or is too
hard to test and the effort of testing it is not worth the benefit achieved in test-
ing it.
In the case of the Wgs84Coordinate class, the code coverage tool is indicating
that the main method is not being invoked by the unit tests. Inspection of the code
reveals that it is not doing anything useful so it can be removed.
Figure 2.7 Code coverage report for Wgs84Coordinate.

2.9 Configuration Management
Software configuration management is the process of managing the versioning of

software as well as tracking and controlling changes. Configuration management
allows each individual component of a software project including classes, directo-
ries, and data files to be managed, versioned, and traced. The software is normally
stored in a repository, or archive, which is managed by a configuration manage-
ment tool. The tool maintains the versioning of each individual element in the
repository and can be used to track changes and allow access to a set of files that
represent the project at a given time or files tagged with a given label such as a
release identifier.
A software configuration management tool will also allow several streams of
development off a main branch and will allow multiple users to edit their own ver-
sion of the code and return their changes into the repository so that the updated files
are available for others to use. When the software is being developed on a smaller
scale, such as with the code accompanying this book, configuration management
still has its merits because it allows traceability of each piece of source code, direc-
tory, and file in the repository. Version-controlled files facilitate a comparison
between different versions of each file. This allows the developer to scrutinize each
change made to the code in order to discover when and how a problem was intro-
duced into the code. In addition, version-controlled files allow the developer to
recover earlier versions of files and/or directories.
The general process of working with files under configuration management is to
initially create a repository and import a directory structure into it. Individual users
are then able to check out their own version of the repository. Every now and then,
users may want to incorporate the changes of others into their own local copy so
they will use a command to update their local copy of the files. They will make
changes to their code and when it is ready, they will submit their files. In addition,
they may want to add, delete, or move files within the repository. They may want to
run a diff command to check on the changes between their local copy and the
archive or revert a file to a previous version from the repository.
The code developed for this book is managed using the open source Subversion
[9] version control system. The source code is held in a Subversion repository and,
at regular intervals, changes are committed to the repository.
References
[1] National Imagery and Mapping Agency, Technical Report TR8350 Department of Defense
World Geodetic System 1984: Its Definition and Relationships with Local Geodetic Sys-
tems, Third Edition, Amendment 1 January 2000, NIMA Bethesda, MD.
[2] Bowring, B., “Transformation from Spatial to Geographical Coordinates,” Survey Review,
XIII, 181, July 1976, pp. 323–327.
[3] Kaplan, E. D., et al., “Fundamentals of Satellite Navigation,” in Understanding GPS: Prin-
ciples and Applications, 2nd ed., E. D. Kaplan and C. J. Hegarty, (eds.), Norwood, MA:
Artech House, 2006.
[4] Maven software project management and comprehension tool, http://maven.apache.org/
index.html.
2.9 Configuration Management 33
[5] JUnit, www.junit.org.

[6] Javadoc, http://java.sun.com/j2se/javadoc/.
[7] Shirazi, J., Java Performance Tuning, 2nd ed., Sebastapol, CA: O’Reilly & Associates, Inc.,
2003.
[8] EMMA Java code coverage tool, http://emma.sourceforge.net/index.html.
[9] Subversion version control system, http://subversion.tigris.org/.
CHAPTER 3
GPS
The GPS is a space-based radionavigation system that is owned by the U.S. govern-
ment and operated by the U.S. Air Force (USAF). It reached initial operation capa-
bility in 1993 [1] and is widely used today by both the military and civilians. The
satellites transmit information that allows a handset to determine its location, its
velocity, and the precise time. This chapter introduces the key operations of GPS via
an exploration of the navigation message, including the satellite broadcast informa-
tion and models, GPS time, and factors affecting the accuracy of a GPS fix.
The fundamental technique of the GPS is the use of one-way ranging from the
GPS satellites to measure the distance to each satellite and calculate the location of
each satellite and, from that, the location of the handset.
This chapter introduces the key operations of GPS, including the GPS signals,
GPS time, satellite broadcast information and models, and key calculations such as
calculating the location of the satellites at a specific time. This chapter also intro-
duces GPS signal acquisition and receiver positioning. Factors affecting the accu-
racy of a GPS fix are discussed, as well as geometry and dilution of precision (DOP).
3.1 GPS Constellation and Segments
Historically, the GPS system consisted of three segments: the space segment (SS), the
control segment (CS), and the user segment (US) [2, 3].
The space segment consists of a minimum of 24 operational satellites that trans-
mit on several frequencies. Each satellite transmits a radio frequency (RF) ranging
code and a navigation message.
The control segment consists of a network of monitor stations that track and
monitor the satellites, the master control station (MCS) that gets the information
from each of the monitor stations and determines the data to upload to the satellites,
and the ground antennas that transmit the information to the satellites. Some other
responsibilities of the MCS are satellite status monitoring, maintenance, and
detection of service failures.
The user segment consists of handsets (radio receivers) that are specifically
designed to receive and process the signals from the space segment. The user hand-
sets come in many different forms and can be embedded in various types of devices.
The U.S. government owns the control and space segments that are operated by
the USAF. There are millions of receivers in use today in the user segment, including
more than 300 million receivers in cell phones. The user segment is no longer part of
the GPS since the development of the receivers is no longer under the control of the
35
36 GPS
GPS Joint Program Office (JPO) [1]. The GPS provides the GPS IS [4], which is the
interface between the space and the user segments.
Ranging codes are transmitted by the satellites, which allow the handset to
determine the time of flight (TOF) between the satellite and the receiver and hence
calculate the range. The navigation data message allows the handset to calculate the
position of the satellite at the time that the code was transmitted. The location of the
handset is calculated using this information by solving the point of intersection of
spheres.
Since GPS met initial operational capability, it has continuously met and
exceeded the minimum accuracy performance levels specified in the Standard Posi-
tioning Service Performance Standard (GPS SPS PS) [1]. GPS receivers have been
achieving a horizontal accuracy of 3 meters or better and a vertical accuracy of 5
meters or better 95% of the time [1] in open sky conditions.
3.2 GPS Services
There are two levels of service enabled by the GPS. The Precise Positioning Service
(PPS) is a precise service that is intended for military purposes. Access to the PPS is
controlled using cryptography and is not covered in detail in this book.
The GPS Standard Positioning Service (SPS) is intended for civilian use; this ser-
vice is presently available via the GPS L1 signal. The GPS SPS is described in the GPS
SPS Signal Specification (GPS SPS SS) [2] and the GPS SPS PS [1].
3.3 Satellites
The GPS satellites are organized into six geometrically spaced orbital planes with at
least four satellites in each plane. There is a minimum of four satellites, but there are
often more for redundancy. The satellites have an average altitude of approximately
20,180 kilometers above the Earth and orbit the Earth in approximately 11 hours
and 58 minutes.
The satellites are positioned in the orbital plane so that four satellites are visible
from every point of the Earth with a good geometric separation. The satellites trans-
mit towards the Earth with a beamwidth of 27.8°. The beam covers 38% of the
Earth’s surface.
3.4 Ranging Codes
The GPS signals and standard codes are summarized in Table 3.1. The satellites
transmit several ranging codes: the precision code (P-code), the Y-code, which is
used instead of the P-code under the antispoofing (encrypted) mode, and the
coarse/acquisition (C/A) code, which is used to acquire the P-code or Y-code and
also as a civil ranging signal. The P-code is often referred to as the P(Y) code.
The L2 civil-moderate (L2 CM) and L2 civil-long (L2 CL) codes are presently
being commissioned and are intended for civil use. The L2 civil (L2C) codes have
3.5 PRN Codes 37
better cross-correlation performance, which means that the reception of weak GPS
signals is much less affected by simultaneously received strong GPS signals. L2 will
allow a civilian dual-frequency receiver to completely account for ionosphere
errors, hence improving the accuracy, and is defined in GPS IS 800 [5]. GPS L5 is
also being commissioned and is intended for civilian safety-of-life applications and
is defined in GPS IS 705 [6]. New codes and frequencies are coming online through-
out the GPS modernization program [7].
The P-code is 7 days long and is transmitted at 10.23 MHz. It is used by military
grade receivers. The C/A code is 1 millisecond in length at a chipping rate of 1.023
MHz. The L2 CM code is 20 milliseconds in length at a chipping rate of 511.5 Kbps,
while the L2 CL is 1.5 seconds in length with a chipping rate of 511.5 Kbps.
Note that in the case of a problem with a satellite’s hardware, it may also trans-
mit an “incorrect” version of each of the codes in order to protect the handset from
receiving incorrect data. The nonstandard codes are not shown in Table 3.1.
3.5 PRN Codes
Each satellite has a unique pseudorandom noise (PRN) signal number that is trans-
mitted by the satellite. For GPS L1, for example, it is 1,023 bits in length and pro-
vides the method to identify each individual satellite. Each sequence is a 1,023-bit
gold code and is described in [4].
PRNs are numbered from 1 to 37. PRNs 1 to 32 are used to identify satellites.
PRNs 33 to 37 are reserved for other uses, such as ground-based transmitters. PRNs
34 and 37 share the same PRN code.
3.6 GPS C/A Code
The C/A code consists of the satellite’s PRN modulated with a navigation message.
It is 1,023 bits long and repeats each millisecond. This short code length enables the
receiver to acquire the satellite signals very quickly.
Code-division-multiplexing techniques allow the handset to differentiate
between the satellites even though they transmit on the same frequency. The C/A
code is the PRN with the Modulo-2 addition of the navigation data bits, which are
Table 3.1 GPS Signals and Codes

Code GPS Signal Code Length Rate Message Notes
C/A L1 1,023 bits 1.023 MHz NAV
P-code L1, L2 6,187,104 bits 10.23 MHz NAV Encrypted
Y-code L1, L2 6,187,104 bits 10.23 MHz NAV Used instead of P-code
under antispoofing
L2 CM L2 10,230 bits 511.5 kHz CNAV The message could be
CNAV, NAV, or none
L2 CL L2 767,250 bits 511.5 kHz CNAV The message could be
CNAV, NAV, or none
L5 L5 10,230 bits 10.23 MHz L5 CNAV
38 GPS
included in the sequence at 50 bps. There is normally a bit transition every 20 milli-
seconds. The navigation message is described in detail in subsequent sections.
3.7 GPS L1 Signal
GPS Link 1 (L1) is used for civilian applications and is the only civil signal that has
reached full operational capability (FOC) and hence is the primary signal consid-
ered in this book. It is transmitted at 1,575.42 MHz as right-hand circularly polar-
ized (RHCP) and is biphase shift key (BPSK) modulated with the C/A signal. The
C/A signal (described in Section 3.6) is the PRN sequence with a Modulo-2 addition
of the 50-Hz navigation message.
On L1, each satellite has a unique PRN coarse/acquisition (C/A) code sequence,
which is 1,023 bits in length and provides the method to identify each individual
satellite. The satellite generates a navigation message (NAV) that is determined
from data that is periodically uploaded from the control segment. The navigation
message is added to the 1.023-MHz PRN C/A sequence at 50 bits per second (bps),
and the satellite modulates the resulting code sequence onto the L1 carrier to create
the spread spectrum ranging signal. The spread spectrum ranging signal is continu-
ously transmitted by each satellite.
Figure 3.1 shows the model of GPS L1. The PRN code is added to the NAV data
to generate the C/A code. The C/A code is then modulated onto the L1 carrier and
transmitted.
3.8 GPS L2 Signal
On L2, there are two ranging codes transmitted: L2 civil-moderate (L2 CM) and L2
civil-long (L2 CL) codes. These codes have the civil navigation (CNAV) signal mod-
ulated on them. Similar to L1, the L2 signal is BPSK modulated by one of the two bit
trains (L2 CM or L2 CL), depending on what is selected by ground command. It is
also possible that L2 may not have a broadcast signal modulated on it at all.
L1 carrier –1575.42 MHz
GPS L1
PRN –1.023 MHz x
C/A code
+
Modulo 2
NAV data –50 Hz
Figure 3.1 GPS L1 signal.

3.9 GPS Time 39
The CNAV allows up to 63 different navigation message types, which will be

incrementally phased in over time. It may also be modulated on the ranging signal at
a different rate. It is described further in [4].
3.9 GPS Time
GPS time is controlled by the control segment and is the time reference for all GPS
operations. It is referenced to UTC time and commenced at midnight on January 5,
1980 (the morning of January 6, 1980). GPS time is specified with a week number and
the number of seconds in the week. In the 10-bit representation used by the navigation
message, the GPS week ranges from 0 to 1,023; at the expiration of week 1,023, the
week number rolls over to 0. The number of seconds in each GPS week is 604,800.
GPS time differs from UTC time because it is a continuous time scale. UTC time,
on the other hand, has leap seconds introduced to it as a periodic correction. Each
time that a leap second is added to UTC, the GPS time goes ahead another second.
There is also a drift between the GPS and UTC time scales, which is controlled to be
within 1 microsecond of UTC [4]. The relationship between GPS and UTC time can
be determined using the information in the navigation message described in the next
section.
3.10 Broadcast Information Navigation Message Structure (NAV)
Each satellite provides data to the handset to facilitate the position determination
process. On L1, this information is known as the NAV message. The navigation
message includes the GPS time information, satellite accuracy and health, satellite
clock correction terms, ephemeris, almanac, ionosphere model, and the UTC
model. It allows the handset to determine the status of the constellation, the satel-
lite’s time of transmission, its health, its clock correction, its position, and the time
conversion from GPS to UTC. The NAV message is part of the C/A code and the P-
and Y-codes. It may also be transmitted on L2 under certain circumstances.
Once the handset calculates the location of the satellites, it can then use that in
conjunction with range measurements that it makes in order to calculate the loca-
tion of the handset. The navigation message structure repeated from Chapter 1 is
shown in Figure 3.2.
Figure 3.2 shows that each frame of data (1,500 bits) is transmitted as five
subframes, each of which is 300 bits in length. Subframes 1 to 3 are transmitted in
each frame, while subframes 4 and 5 are split across 25 frames using “paging.”
The 25 versions of subframes 4 and 5 are known as pages. To get the complete
almanac information, the receiver needs to decode all 25 frames of the navigation mes-
sage. At the data rate of 50 bps, each 300-bit subframe takes 6 seconds to transmit,
which leads to 30 seconds for an entire frame. In order for the receiver to get the com-
plete almanac information, it will need to wait for 25 × 30 seconds, or 12.5 minutes.
The complete specification of the message content can be found in the GPS IS
[4], and some key information is included here. The subframes are made up of spe-
cific data and some parity information. There is also a default navigation data trans-
40 GPS
300 bits at 50 bits per second–6s per subframe
Subframe 1– Satellite accuracy and health and satellite clock correction

6 subframes– 30 s per frame
Subframe 2 – Ephemeris
Subframe 3 – Ephemeris continued
Subframe 4 – Alamac, Special messages, Ionosphere and UTC model Pages 1-25
Subframe 5 – Almanac Pages 1-25
Figure 3.2 NAV message structure for a frame.
mission where words 3 through 10 contain a pattern of alternating 1s and 0s. Note
that the satellite does not need to transmit its satellite identifier in the NAV model
because the satellite is differentiated based on its PRN.
Each subframe begins with a header that contains the telemetry (TLM) word
and a handover word (HOW). The TLM contains the preamble, which is set to
0×8B, some reserved bits, and parity. The HOW contains the time of week (TOW)
count, the subframe ID (1 – 5), some flags, and parity bits. The significant fields are
shown in Table 3.2. The parameters have the specified number of bits and start at
the specified bit within the 300-bit frame. The bits are numbered increasing from
the MSB.
Table 3.2 contains a column that specifies where the field starts within an 8-bit
byte and the bit offset within that byte. This information about the byte and bit
number is very useful when we are decoding the bit string in code in the next section.
The bytes are numbered from 1 as the most significant byte and increasing in num-
ber. For example, the subframe ID starts at bit 50 within the 300 bits, which is bit
number 2 within byte number 7. The methods to calculate the byte and bit offsets
are shown in (3.1).
Table 3.2 Subframe Header

Starting Byte and Bit
Bit Number Number Number Within
Parameter (of 300 bits) of Bits the Byte: Byte (Bit) Notes
Preamble 1 8 1 (1) Hardcoded to 0×8B
TOW-count truncated 31 17 4 (7)
Momentum or alert 48 1 6 (8)
Synchronization or 49 1 7 (1)
antispoof
Subframe ID 50 3 7 (2) From 1 to 5
⎛ startingBitNumber − 1⎞
byteNumber = trunc ⎜ ⎟ +1
⎝ 8 ⎠ (3.1)
bitNumber = startingBitNumber − ((byteNumber − 1) * 8)
Under a normal operation, subframe 1 contains the satellite clock and health
data; this is shown in Table 3.3. The satellite health data indicates the health of the
satellite. If the MSB is set to 1, then some or all navigation data is bad, and the rest
of the bits indicate the problem that can be determined from a look-up table speci-
fied in [4]. TGD is the estimated group delay differential. It is a term used to account
for the satellite group delay differential. TGD is applied to the measured code phase
to calculate an updated satellite time difference. The issue of data, clock (IODC)
indicates the issue number of the data set. This allows detection of a change of trans-
mitted parameters and will be unique within a 7-day period. The satellite clock cor-
rection terms toc, af2, af1, and af0 allow the user to correct for the satellite clock errors.
Depending on the type, age, and condition of the clock in the satellite, it will have
a specific drift from true GPS time. The clock is regularly monitored by the MCS,
which regularly updates the satellite clock correction parameters for each clock.
The time of transmission of the signal from the satellite is corrected using (3.2).
Note that the first two equations are coupled, but the GPS time, t, can be substituted
with tsv in the second equation. af0, af1, af2, and toc are parameters from subframe 1, F
is a constant, and e, A, and Ek are orbit parameters that are calculated from the
ephemeris; these are defined in Table 3.4 and (3.3).
t = t SV − Δt SV
where
Δt SV = a f 0 + a f 1 (t − t oc ) + a f 2 (t − t oc ) + Δt r
2
(3.2)
Δt r = Fe A sin E k
−2 μ
F = = −4.442807633 × 10 −10
c2
Table 3.3 Subframe 1 Parameters

Starting Bit Byte and Bit
Number (of Number Number Within Scale
Parameter 300 Bits) of Bits the Byte: Byte (Bit) Notes Factor Units
Week number 61 10 8 (5) 1 GPS week
Satellite accuracy 73 4 10 (1)
Satellite health 77 6 10 (5) 1
–31
TGD 197 8 22 (5) Two’s complement 2 Seconds
IODC 83 (2 MSBs) 10 11 (3) and
211 (8 LSBs) 27 (3)
4
toc 219 16 28 (3) 2 Seconds
–55 2
af2 241 8 31 (1) Two’s complement 2 Sec/sec
–43
af1 249 16 32 (1) Two’s complement 2 Sec/sec
42 GPS
Consideration must be given for beginning or end of week boundaries and t is

adjusted if required as shown in
t = t − 604,800 if t − t oc > 302,400

(3.3)
t = t + 604,800 if t − t oc < −302,400
Ephemeris is the name given to a set of parameters that give the position of an
object in the sky at a given time. The GPS ephemeris provides the information about
the position of GPS satellites using terminology typical of Keplerian orbital parame-
ters. The parameters allow the best trajectory fit in ECEF coordinates. Subframes 2
and 3 contain the satellite ephemeris data. Once the ephemeris parameters are
decoded, they can be provided to a set of equations that are used to calculate the
location of the satellites in ECEF coordinates. Table 3.4 shows the parameters of
subframe 2 and Table 3.5 shows the parameters of subframe 3. The issue of data,
ephemeris (IODE) is an 8-bit number that is the 8 LSBs of the issue of data, clock
(IODC) from subframe 1 and it appears in both subframes 2 and 3. The user can
compare the IODE with the 8 LSBs of the IODC, and if it is different, then a naviga-
tion data cutover has occurred and the user should ensure that the same issue of
navigation data is being used by recollecting the navigation message.
To calculate the location of the satellite in WGS 84 ECEF coordinates, the ele-
ments of (3.4) are used. It is simply a matter of plugging in the ephemeris parameters
for a particular satellite in order to determine x, y, and z. In (3.4), t is the GPS time at
transmission and μ is the WGS 84 value of the Earth’s gravitational parameter as
discussed in Chapter 2.

Starting Bit Number Byte and Bit Scale Units
Number of Bits Number Within Factor
Parameter (of 300 Bits) the Byte: Byte (Bit) Notes
IODE 61 8 8 (5)
Crs 69 16 9 (5) Two’s complement 2–5 Meters
–43
Δn 91 16 12 (3) Two’s complement 2 Semicircles/
sec
–31
M0 107 (8 MSBs) 32 14 (3) Two’s complement 2 Semicircles
121 (22 LSBs) 16 (2)
Cuc 151 16 19 (7) Two’s complement 2–29 Radians
–33
e 159 (8 MSBs) 20 (7) 2
181 (24 LSBs) 23 (5)
–29
Cus 211 16 27 (3) Two’s complement 2 Radians
1/2 –19 1/2
A 227 (8 MSBs) 32 29 (3) 2 Meters
241 (24 LSBs) 31 (1)
4
toe 271 16 34 (7) 2 Seconds

Starting Bit Number Byte and Bit
Number (of of Bits Number Within the Scale
Parameter 300 Bits) Byte: Byte (Bit) Notes Factor Units
Cic 61 16 8 (5) Two’s complement 2–29 Radians
–31
Ω0 77 (8 MSBs) 32 10 (5) Two’s complement 2 Semicircles
91 (24 LSBs) 12 (3)
–29
Cis 121 16 16 (1) Two’s complement 2 Radians
–31
i0 137 (8 MSBs) 32 18 (1) Two’s complement 2 Semicircles
151 (24 LSBs) 19 (7)
–5
Crc 161 16 21 (1) Two’s complement 2 Meters
ω
–31
197 (8 MSBs) 32 25 (5) Two’s complement 2 Semicircles
211 (24 LSBs) 27 (3)
–43
Ω 241 24 31 (1) Two’s complement 2 Semicircles/sec
IODE 271 8 34 (7)
–43
IDOT 279 14 35 (7) Two’s complement 2 Semicircles/sec
( A)
2
A=
μ
n0 =
A3
t k = t − t oe
n = n 0 + Δn
M k = M 0 + nt k
M k = E k − e sin E k
⎛ sin v k ⎞ ⎛ 1 − e 2 sin E (1 − e cos E )⎞

−1 ⎜ k ⎟
v k = tan −1 ⎜ ⎟ =
k
tan
⎝ ( )( k) ⎠
⎝ cos v k⎠
⎜ cos E k − e 1 − e cos E ⎟
⎛ e + cos v k ⎞
E k = cos −1 ⎜ ⎟
⎝ 1 + e cos v k ⎠
Φk = vk + ω
δu k = c us sin 2Φ k + C uc cos 2Φ k
δrk = c rc cos 2Φ k + C rs sin 2Φ k (3.4)
δi k = c ic cos 2Φ k + C is sin 2Φ k
u k = Φ k + δu k
rk = A(1 − e cos E k ) + δrk
i k = i 0 + δi k + ( IDOT )t k
x k′ = rk cos u k
y k′ = rk sin u k
Ω k = Ω 0 + ( Ω − Ω e )t k − Ω e t oe
x = x k′ cos Ω k − y k′ cos i k sin Ω k
y = x k′ sin Ω k + y k′ cos i k cos Ω k
z = y k′ sin i k
44 GPS
Subframes 4 and 5 are split across 25 frames as numbered pages. The contents
of subframes 4 and 5 have different formats depending on the page numbers.
Subframes 4 and 5 have the page number encoded as 8 bits at an offset of 63 (byte 8,
bit 7). The pages contain almanac and other information.
The almanac is a coarse, longer-term model of the satellite orbits, which allows
a handset to calculate the location of a satellite with low precision. The ephemeris
information is useful for a few hours, but the almanac is useful over a longer
period—approximately 1 month. The almanac is helpful for the case in which a
handset is switched on after being off for some time. In this case, the handset has no
current ephemeris information. In order to determine for which satellites to search,
the handset can then use the almanac to determine the satellites that should be in
view from the last stored location.
Table 3.6 Subframe 4 Page 18 Parameters

Starting Bit Number Byte and Bit
Number (of of Bits Number Within Scale
Parameter 300 Bits) the Byte: Byte (Bit) Notes Factor Units
Page number 63 6 8 (7) The parameters below
are for when this is 18.
Ionosphere Model Parameters
–30
α0 69 8 9 (5) Two’s complement 2 Seconds
α1
–27
77 8 10 (5) Two’s complement 2 Seconds per
semicircle
α2 91 8 12 (3) Two’s complement 2–24 Seconds per
2
semicircle
α3
–24
3
semicircle
β0
11
87 8 11 (7) Two’s complement 2 Seconds
β1
14
semicircle
β2 129 8 17 (1) Two’s complement 216 Seconds per
2
semicircle
β3
16
3
semicircle
UTC Model Parameters
–50
A1 151 24 19 (7) Two’s complement 2 Sec/sec
–30
A0 181 32 23 (5) Two’s complement 2 Seconds
(24 MSBs) 27 (3)
211
(8 LSBs)
12
tot 219 8 28 (3) 2 Seconds
WNt 227 8 29 (3) 1 Weeks
ΔtLS 241 8 31 (1) 1 Seconds
WNLSF 219 8 28 (3) 1 Weeks
DN 227 8 29 (3) Right justified 1 Days
ΔtLSF 271 8 34 (7) Two’s complement Seconds
Some of the more interesting information, the Universal Coordinated Time

(UTC) parameters and ionospheric model parameters, are shown in Table 3.6 in
subframe 4 on page 18.
The UTC parameters provide the fields to convert from GPS to UTC time and
vice versa. The ionospheric parameters allow the user to correct for some of the
errors in the measurements due to propagation delays of the radio signal through
the ionosphere.
The GPS measurements can be corrected using the ionosphere model. The
Klobuchar model [8] is estimated to remove about half of the error due to iono-
spheric propagation effects. The correction is applied as given in (3.5) and (3.6).
Note that some of the parameters used in the equation are based on those calculated
in (3.4).
⎧ ⎡ ⎛ x2 x 4 ⎞⎤ ⎫
⎪ ⎢
F * 5.0 * 10 −9
+ ( AMP ) ⎜1 − + ⎟ ⎥, x < 157
. ⎪
Tiono =⎨ ⎣ ⎝ 2 24 ⎠ ⎦ ⎬
⎪ ⎪
⎩ ( −9
)
F * 5.0 * 10 , x ≥ 157 .
⎭
where
⎧ 3 ⎫
AMP = ⎨ n∑
⎪ α n φ m , AMP ≥ 0 ⎪
n
=0 ⎬
⎪ if AMP < 0, AMP = 0⎪
⎩ ⎭
2 π(t − 50,400)
x =
PER
⎧ 3 ⎫
⎪ ∑ β n φ m , PER ≥ 72,000
n
⎪
PER = ⎨ n = 0 ⎬
⎪ if PER < 72,000, PER = 72,000⎪
⎩ ⎭
. (053
. − E)
3
F = 1 + 160
φ m = φ l + 0064
. cos( λ l − 1.617 ) (3.5)
ψ sin A
λl = λu +
cos φ l
⎧ φ u + ψ cos A, φ l ≤ 0.416 ⎫
⎪ ⎪
φ l = ⎨ if φ l > 0.416, then φ l = 0.416 ⎬
⎪ if φ < −0.416, then φ = −0.416⎪
⎩ l l ⎭
0.00137
ψ= − 0022
.
E + 011.
t = 432
. * 10 4 λ l + GPStime
The calculated time is then corrected using
t = t − 86,400 if t ≥ 86,400
t = t + 86,400 if t < 0 (3.6)

46 GPS
Subframe 4, page 18, also contains the information to convert the time between
GPS time and UTC time. When the time indicated by WNLSF and the DN is not in
the past, and the present time does not fall in the time span, which starts at DN + 3/4
and ends at DN + 5/4, then (3.7) is used to convert GPS time to UTC time. Equation
(3.7) determines the UTC time in seconds in the current week where t is the GPS
time in seconds, WN is the current week number, and the other fields are from
subframe 4, page 18.
t utc = (t − Δt utc ) mod 86,400

where (3.7)
Δt utc = Δt LS + A 0 + A1 (t − t ot + 604,800(WN − WNt ))
When the time span falls between DN + 3/4 and DN + 5/4, then (3.8) is used:
t utc = W (mod(86,400 + Δt LSF − Δt LS ))

where (3.8)
W = (t − Δt utc − 43,200) mod 86,400 + 43,200
When the time is in the past, (3.7) is used, except that the value of ΔtLSF is substi-
tuted for ΔtLS.
3.11 Decoding and Storing the Navigation Model
The broadcast package com.serverAgps.broadcast contains the Java code associ-

ated with the broadcast navigation message. It contains classes to store the naviga-
tion message and decode it.
3.11.1 Storing the Raw NAV Data

The UML class diagram for the raw navigation message data is shown in Figure 3.3.
The NavMessage class holds a collection of per-satellite navigation messages as
instances of the SatelliteNavMessage class. In turn, the SatelliteNavMessage holds
information for up to three subframes and up to 25 instances of
SatNavMessagePage. The 25 instances are for each of the 25 possible pages of
subframes 4 and 5.
The code using this class creates an instance of NavMessage. The NavMessage
constructor creates an instance of SatelliteNavMessage and SatNavMessagePage.
The UML sequence diagram for putting data into these classes is shown in Figure
3.4. When new data arrives (1), the application calls the newData() of NavMessage
and passes in the PRN and the byte array with 300 bits of data. The newData
method instantiates a Subframe and calls the subframe’s newData() method (2) to
put the raw data into it. It then calls the newData() method of the
SatelliteNavMessage class, passing in the subframe. The newData() method adds
the subframe to its collection if it is subframes 1, 2, or 3. If it is not, then it calls the
newData() method on the SatelliteNavMessagePage (4), which decodes the page
NavMessage
-satellites[] : SatelliteNavMessage
+getSatellite(in prn : int) : SatelliteNavMessage
+newData(in prn : int, in data : byte[])
1
SatelliteNavMessage
Subframe
-prn : int
-data : byte[]
-subframes[] : Subframe
+newData(in data : byte[])
+newData(in data : Subframe)
0..* 1 0..3 +getSubframeId() : int
+getSubframe() : Subframe
+getPageId() : int
+getPage() : SatNavMessagePage
1
0..25
SatNavMessagePage Subframe
-pageNumber : int -data : byte[]
-subframes[] : Subframe +newData(in data : byte[])
+getSubFrame() : Subframe 1 0..2 +getSubframeId() : int
+newData(in data : Subframe) +getPageId() : int
Figure 3.3 Raw navigation message classes.
number, allocates the subframe, and adds it to the appropriate page. The dashed
lines in the sequence diagram indicate the return of control to the calling object.
As shown in Table 3.2, the subframe ID is in bit 50 and is of length 3, or byte 7,
bit 2. Since arrays are indexed from 0 in Java, byte 7 becomes array index 6. The
code to extract the subframe ID from the Subframe class is shown here:
/**
* This method extracts the Subframe Id from the subframe byte buffer
*
* @param subFrame the 300 bit, byte array that contains the subframe.
* @return the subframe id. This will be 1,2,3,4 or 5.
*/
private int getSubframeId(byte[] subFrame)
{
int subFrameId = (subFrame[6] & 0x70) >> 4;
return subFrameId;
}
A bit mask is used to mask out the bits of interest (bits 2, 3, and 4 when num-
bered from the MSB). Once the bits are masked out, the result is right shifted so that
the subframe ID has the correct magnitude. This is illustrated further in Figure 3.5.
An example of the bits in byte 7 of a subframe are shown in Figure 3.5(a); the bit
mask shown in Figure 3.5(b) aims to isolate bit numbers 2, 3, and 4. When a bitwise
and is invoked with the example in Figure 3.5(a), the masked out bits shown in Fig-
ure 3.5(c) are the result. The bits in Figure 3.5(c) are then right shifted by 4 to give
the result shown in Figure 3.5(d).
3.11.2 Running the Classes to Store the Raw Data

The classes to process the raw NAV data are run every time that the source package
is built. This is because the unit test cases in the test directory of the project contain
test cases to test each of the classes in the broadcast package described in the previ-
48 GPS
navMessage subframe satNavMessage satNavMsgPage
1.: newData(prn, data)
2.: newData(data)
3.: newData(data)
4. [subframe = 4 or 5]: newData(data)
Figure 3.4 Raw navigation sequence diagram.
Subframe ID
(a) Subframe [6] 0 0 1 1 1 0 1 0
& (bitwise and)
(b) Mask 0x70 0 1 1 1 0 0 0 0
(c) Masked out bits 0 0 1 1 0 0 0 0
>> 4
(d) Shifted bits 0 0 0 0 0 0 1 1
Subframe ID = 3
Figure 3.5 (a–d) Bit manipulation used in the getSubframeId() method.
ous section. The test classes are in the broadcast directory of the test directory.
As with the unit test classes described in Chapter 2, the classes are named the same
as the class that they are trying to test with the suffix of test. Thus, the
classes are NavMessageTest, SatelliteMessageTest, SatNavMessagePageTest, and
SubframeTest.
There is also an application class that can be run to invoke the NavMessage
class. It is in the app package and is called serverAgps.app.Ch3NavMessage. There
is a batch file that can be used to invoke it in the batch directory of the project
(ch3Navessage.bat).
The Ch3NavMessage class has a hardcoded array of raw NAV data as strings
with their corresponding PRN. When the class is run, it creates an instance of the
NavMessage and repeatedly calls its newData method with each item of NAV data.
Once it has loaded up the class, then it calls the toString method of the NavMessage
class in order to display the information in a human readable format.
3.11.3 Other Sources of Raw NAV Data

The application class described in the previous section has hardcoded GPS data that
was previously captured. It is much more fun working with real data. Many com-
mercial grade GPS receivers have an interface that allows an application to connect
via TCP/IP or a serial connection and obtain the GPS data stream as it is received.
This may be in the form of a raw data stream or as data that has been
semiprocessed.
Extending the concept of the example application, Ch3NavMessage, it could
connect to the GPS receiver and request the raw broadcast message to be streamed.
As the data is received from each satellite, the NavMessage instance is built up and
maintained with the up-to-date navigation model as it is received. An alternative is
to capture the output from the receiver as a text file and process it off-line.
There are some sample files collected from a NovAtel receiver in the directory in
the accompanying code:
serverAgps/novatel/data
The format of the logs is described in the NovAtel log specification [9]. The log
files contain various different logs in text format. The novatel package contains sev-
eral classes to process data from these logs. The NovatelLogParser class reads
through the file and calls the appropriate class to parse each type of log. For exam-
ple, if the log is a raw navigation message log, then it invokes the
NovatelRawEphemeris class to parse the subframe data out of the log.
The Ch3NavMessageFromLog class in the app package reads its navigation
message from the log file using the classes from the novatel package to get the infor-
mation for the log.
3.11.4 Decoding the NAV Data into Useful Information

The classes defined earlier can store the current broadcast model and the Subframe
class has the capability of decoding each field from the subframe. However, they
cannot be used to perform operations that we require such as calculating the loca-
tion of the satellites or determining the UTC offset. In order to do that, we need to
decode the broadcast message from the appropriate subframes.
The UML class diagrams for the classes that deal with the decoded ephemeris
are shown in Figure 3.6.
50 GPS
SatelliteInfoHandler
-sateInfoCollection
1
Utc
0..* -utcParameters
+getUtcTime(in gpsTime : double) : double
SatelliteInformation
-satellites[] : Satellite
+getSatellite() : Satellite
IonosphereModel
1
-ionosphereParameters
0..* +getCorrection(in location : Wgs84Coordinate) : double
Satellite
-clockCorrectionParameters
-Ephemeris
+Satellite(in navMessage : SatelliteNavMessage)
+calculateLocation() : Wgs84Coordinate
+calculateVelocity()
Figure 3.6 Classes that deal with decoded broadcast message.
Instances of these classes are populated from RINEX files (see Section 3.11.5).
The SatelliteInfoHandler class contains a collection of SatelliteInformation objects.
The SatelliteInformation instances hold the Satellite instances for all of the satellites
at a particular time, while the SatelliteInfoHandler contains a collection of
SatelliteInformation objects for different times. One application of the
SatelliteInfoHandler class is to store a whole day’s worth of ephemeris information.
3.11.5 RINEX as a Data Source for the Navigation Message

The Receiver Independent Exchange Format (RINEX) is a commonly used file for-
mat for GPS and GLONASS information [10]. The file format consists of six differ-
ent file types. The file format consists of a header, which contains information that
is relevant to the whole file, and a set of data lines. The header lines contain labels in
columns 61–80. The navigation message file format contains the ionosphere and
UTC parameters as well as most of the parameters from subframes 1, 2, and 3 for
each satellite at each time.
RINEX file formats can be generated directly from commercial grade GPS
receivers and are available for download. One example of a large database is the
Scripps Orbit and Permanent Array Center (SOPAC) [11]. SOPAC provides RINEX
and other files for a large number of GPS receivers located around the world. It also
provides the navigation message as an “auto” file, which is a collation of the mes-
sages from all of the satellites for the whole day.
The code in the rinex package (serverAgps.rinex) parses a RINEX file and calls
the methods in the Satellite, UTC, and Ionosphere classes described in Section
3.11.4 to decode the lines that are specific to those objects. The RINEX file can con-
tain the ephemeris for one particular time or could be a collection of data for a
whole day, so the rinex parsing classes return an instance of SatelliteInfoHandler.
For example, the RinexNavFile.readData() method returns an instance of the

SatelliteInfoHandler.
3.11.6 Implementation of Methods Using the NAV Model

This section describes the method to calculate the location of the satellites and the
method to test it. The class diagram for the classes discussed in this section is given
in Figure 3.6. The location of each satellite is calculated from the ephemeris data
using (3.4). The calculation code is in the Satellite class. It precalculates some of the
intermediate values used for the equation that are purely based on the ephemeris
information. An excerpt from the code in the constructor is as follows:
//Calculate A, n0 and n using the formulas from the GPS IS
this.A = Math.pow(this.sqrtA, 2);
this.n0 = Math.sqrt(Wgs84Coordinate.WGS84_MU_EARTHS_GRAV_PARAMETER/Math.pow(this.A, 3));
this.n = this.n0 + this.deltaN;
It is common practice to perform precalculation like this so that the variables

are calculated once and not each time that the location calculation method is called.
The method to calculate the location given a specific time of week in seconds,
calculateLocation(), is shown here.
1. /**
2. * This method calculates the location of the satellites at a given time of the week in
seconds using
3. * the formulas straight out of the GPS IS. Note that A, n0 and n are precalculated in the
constructor.
4. *
5. * @param timeOfWeekSeconds the time to calculate the satellite location.
6. *
7. * @return the location of the satellite in WGS 84 Coordinates.
8. */
9. public Wgs84Coordinate calculateLocation(double timeOfWeekSeconds)
10. {
11. //A, n0 and n are precalculated in the constructor
12.
13. double tk = calculateTimeFromEpoch(timeOfWeekSeconds);
14. double mk = this.m0 + this.n * tk; //mean anomaly
15. double ek = calculateEccentricAnomaly(mk); // calculate the eccentric anomaly
16.
17. //True anomaly
18. double vk = Math.atan2((Math.sqrt(1 - Math.pow(this.e, 2))*Math.sin(ek))/(1-this.e *
Math.cos(ek)),
19. (Math.cos(ek) - this.e)/(1 - this.e * Math.cos(ek)));
20. if (vk < 0)
21. {
22. vk += 2 * Satellite.PI;
23. }
24.
25. double phiK = vk + this.omega; //argument of latitude
26.
27. double duk = this.cus * Math.sin(2 * phiK) + this.cuc * Math.cos(2 * phiK); // argument of
latitude correction
28. double drk = this.crc * Math.cos(2 * phiK) + this.crs * Math.sin(2 * phiK); // raduis
correction
29. double dik = this.cic * Math.cos(2 * phiK) + this.cis * Math.sin(2 * phiK); // correction
to inclination
30.
31. double uk = phiK + duk; //corrected argument of latitude
32.
33. double rk = this.A * (1 - this.e * Math.cos(ek)) + drk; //corrected radius
34. double ik = this.i0 + dik + (this.idot * tk);//corrected inclination
35.
36. double xk = rk * Math.cos(uk); //position x in orbital plane
37. double yk = rk * Math.sin(uk); //position y in orbital plane
38.
39. //Corrected longitude of ascending node
40. double omegak = this.omega0 +
41. ((this.omegadot - Satellite.OMEGA_EARTHS_ROTATION_RATE_RADIANS_SECOND) * tk) -
52 GPS
42. Satellite.OMEGA_EARTHS_ROTATION_RATE_RADIANS_PER_SECOND * this.toe;

43.
44. double x = xk * Math.cos(omegak) - yk * Math.cos(ik) * Math.sin(omegak); //ECEF x
45. double y = xk * Math.sin(omegak) + yk * Math.cos(ik) * Math.cos(omegak); //ECEF y
46. double z = yk * Math.sin(ik); //ECEF z
47.
48. Wgs84Coordinate thisSatelliteCoordinate = new Wgs84Coordinate();
49. thisSatelliteCoordinate.setEcef(x, y, z);
50. return thisSatelliteCoordinate;
51. }
This method is passed the time of the GPS week in seconds (line 9) and returns
an instance of a Wgs84Coordinate as the result (line 50). The method is written to
illustrate the steps in (3.4) and has no optimizations or error checking. The code
simply steps through the lines in (3.4) to calculate the location of a satellite at a
given time. The only step of the process that is not sequential is the method to calcu-
late Ek (the eccentric anomaly) that is called on line 15. It is calculated iteratively by
the calculateEccentricAnomaly() method as shown here:
1. /**
2. * This method determines Ek through iteration. Ek is the eccentric
3. * anomaly and is defined in the GPS SS and the GPS IS as one of the
4. * calculations used for calculating the location of the satellite.
5. * It normally converges in 5 to 8 iterations.
6. *
7. * @param mk this is the mean anomaly.
8. *
9. * @return the calculated eccentric anomaly.
10. */
11. private double calculateEccentricAnomaly(double mk)
12. {
13. double ek = mk;
14. double oldEk;
15.
16. //This loop normally converges within 8 iterations but we have a counter in the loop to
17. //guard it from getting into an endless loop.
18. int numberOfIterations = 0;
19. do
20. {
21. oldEk = ek;
22. ek = mk + this.e * Math.sin(ek);
23. numberOfIterations++;
24. }
25. while(Math.abs(ek - oldEk) >= Satellite.SMALL_DIFFERENCE_IN_ESTIMATE &&
26. numberOfIterations < Satellite.MAX_NUM_ITERATIONS_CALCULATING_EK);
27.
28. //We should check to make sure that the iteration converged
29. if(numberOfIterations == Satellite.MAX_NUM_ITERATIONS_CALCULATING_EK)
30. {
31. System.out.println(“calculateEccentricAnomaly ek did not converge”);
32. //Do something here to indicate that there is a problem.
33. //Throwing an exception might be the best thing to do.
34. }
35. return ek;
36. }
The calculateEccentricAnomaly() method iteratively calculates Ek until the dif-

ferent between subsequent iterations is sufficiently small (lines 19–26). There is also
a guard on the loop to ensure that the loop converges (line 26). If the loop does not
terminate within a reasonable number of iterations, then something has gone
wrong. As the comments note (lines 32–33), correct behavior would be to handle
the error condition instead of just allowing the value that has been calculated for Ek
to be returned (line 35). Throwing an exception is a method commonly used in Java
for this situation. The calling method will then need to catch the exception and per-
form an action to report the error.
The Satellite class is unit-tested using the SatelliteTest class. Like all classes in
the test directories, the test cases are run each time that the package is built. The
entire position calculation (discussed in Chapter 5) depends on the location of the

satellites being calculated correctly so it is critical to correctly validate this part of
the code. In order to test the satellite location calculation, real satellite location
information is required.
The International GNSS Service (IGS) publishes postprocessed accurate satellite
locations that can be downloaded for any particular day [12]. The files are in
SP3 format [13] and provide the WGS 84 ECEF location of each satellite at 15-min-
ute intervals. They can be used to validate the locations calculated by the Satellite
class.
The test case method testSatelliteLocationCalculation() is shown next. It reads
a RINEX navigation file from March 16, 2009, (line 6), which populates an
instance of SatelliteInfoHandler and associated classes. It then iterates through the
satellites that it has a ground truth for (lines 16–38) and calculates the location of
each satellite at time 0:00 (line 28). The calculated location of each satellite is com-
pared against the accurate location provided by the IGS (line 31) and the test case is
failed if the locations differ by more than 5 meters. The test class contains a data
structure named satelliteGroundTruthTable that holds the information about the
satellite locations from the SP3 file.
1. /** Correctly calculated the satellite locations. */

2. public void testSatelliteLocationCalculation()
3. {
4. //Grab the satellite data from a Rinex file
5. RinexNavFile rnf = new
RinexNavFile(“src\\main\\java\\com\\ServerAgps\\rinex\\data\\auto0750.09n”);
6. SatelliteInfoHandler sih = rnf.readData();
7.
8. //Put the satellite information out for the given time
9. GpsTime time = new GpsTime(2009, 03, 16, 0, 0, 0);
10. SatelliteInformation satInfo = sih.getSatInfo(time);
11.
12. Wgs84Coordinate expectedLocation = new Wgs84Coordinate();
13. boolean success = true;
14.
15. //Go through the table and check that all of the satellites are calculated in the
specified locations
16. for(int i = 0; i < satelliteGroundTruthTable.length; i++)
17. {
18. short prn = (short)satelliteGroundTruthTable[i][0];
19.
20. //Set up the expected location from the table. the table has the xyz in kn so need to
convert to m.
21. expectedLocation.setEcef(satelliteGroundTruthTable[i][1] * 1000,
22. satelliteGroundTruthTable[i][2] * 1000,
23. satelliteGroundTruthTable[i][3] * 1000);
24.
25. Satellite theSat = satInfo.getSatellite(prn);
26. if(theSat != null)
27. {
28. Wgs84Coordinate satLocation = theSat.calculateLocation(time.getGpsSecondsOfWeek());
29. double distanceBetween = satLocation.distanceTo(expectedLocation);
30.
31. if(distanceBetween > SatelliteTest.MAXIMUM_DIST_BETWEEN_CALC_AND_MEASURED_LOCN)
32. {
33. success = false;
34. break;
35. }
36. }
37. }
38. assertTrue(“Correctly calculated the satellite locations”, success);
39. }
40.}
54 GPS
3.12 GPS Signal Acquisition
A typical tracking sequence begins with the receiver determining which satellites to
track [14]. It normally does this by using its previously stored location, the almanac,
and the time from a real-time clock. The almanac is used to determine the approxi-
mate position of the satellites. The handset then determines the satellites that are in
view from the previously stored location by calculating which satellites are above
some predetermined elevation mask, for example, 5°. If the handset has no informa-
tion about which satellites for which to search, it engages in an open sky search
where it searches all PRN codes. Once each satellite is tracked, the handset immedi-
ately attempts to demodulate the navigation message data. Once it demodulates the
navigation message, it is stored so that it can be used to calculate the location of the
satellite.
One method for satellite signal acquisition is to use code correlation. An inter-
nal replica of the transmitted signal is used (the predefined PRN code) and aligned
with the received signal. The receiver shifts its generated signal until it aligns with
the received signal. The delay in the receiver-generated code is a measure of the time
of flight between the satellite and the handset, and hence the range between the sat-
ellite and the handset.
3.13 Receiver Positioning
This section introduces receiver positioning at a geometric level. The position calcu-
lation is discussed in more detail in Chapter 6.
GPS is a time-synchronized system that uses the time of arrival (TOA) of signals
from several transmitters in order to determine the location of the handset. Since the
time of transmission (TOT) can be determined, the propagation time can be con-
verted into a range measurement. Note, however, that the handset is not precisely
synchronized to GPS time, so the range measurements are really pseudorange
measurements.
Consider the two-dimensional system shown in Figure 3.7. An often-used
example of TOA-based positioning is that of a vessel determining its position based
on hearing the sound of a foghorn being blown [15]. The vessel and the foghorn
have accurately synchronized clocks and the foghorn, at a known location, is
sounded on the minute mark. The captain notes the time from the minute mark until
it is heard onboard the vessel. The time of flight (TOF) is the propagation time from
when the tone leaves the horn until it is received on the vessel and it can be con-
verted to a distance (or a range to the vessel) by multiplying it by the speed of sound.
This can be considered as a range from a single transmitter. Consider only one
transmitter (Tx1) in Figure 3.7. If r1 is the only measurement available, the vessel
could be anywhere around the circle that is range r1 from Tx1. Consider the situa-
tion of two foghorns (or two transmitters) Tx1 and Tx2 and the range from them to
the vessel. The possible vessel locations have been significantly narrowed to the two
intersection points of the circles, which are shown as x and y. In two dimensions, a
unique solution cannot be established unless there is a third measurement, such as
r3
Tx 3
Tx 1
x
r1
r2 Tx 2
Figure 3.7 Two-dimensional location using range measurements.
that from Tx3. The intersection of all three circles is the location of the vessel at the
point x.
Consider the situation where there is some uncertainty in the measurement. An
example could be that the clock of the vessel is not perfectly synchronized to the
time used by the foghorns or there is some error inherent in each measured range.
This is shown in Figure 3.8. Each range measurement is shown with an associated
error band. The location of the vessel is no longer at a point, but is somewhere
within the area of intersecting arc bands. This is the uncertainty area.
GPS employs TOA for user position determination however instead of a fog-
horn; each satellite transmits a characteristic ranging signal, which travels at the
speed of light. The range can be determined by multiplying the TOF with the speed
of light. In addition, since the transmitters are not in the same plane as the user, the
problem is moved into three dimensions instead of two. This means that the solu-
tion of the user location is now the intersection of spheres and not circles. The inter-
section of three spheres result in two intersection points, but normally, one of them
will not be near the Earth so it can be eliminated. Note that in practice the location
is not calculated as a linear intersection of spheres but as an adjustment of an a pri-
ori position as described in Chapter 6. In addition, the GPS location calculation is
56 GPS
r3
Tx 3
Tx 1
x
r1
r2 Tx 2
Figure 3.8 Two-dimensional location with measurement error.
slightly more complicated because the user’s clock is not synchronized to GPS, so an
additional satellite measurement is required to solve for the handset clock error.
3.13.1 Uncertainty and Confidence

When a location is calculated, there is an inherent uncertainty associated with the
resulting position. The uncertainty is related to the quality of the individual mea-
surements and the geometry of the transmitters relative to the calculated location.
The uncertainty is calculated along with the location and is normally described as
an error ellipsoid on the surface of the WGS 84 ellipsoid at a given confidence.
The uncertainty is specified as an ellipse with a specific orientation, a semimajor
axis length, a semiminor axis length, and altitude uncertainty. A location and its
uncertainty ellipsoid are shown in Figure 3.9. Generally, a GPS location has a much
smaller uncertainty in the plane parallel to the ground (horizontal uncertainty) than
it does to the perpendicular plane (altitude uncertainty).
Note that uncertainty is different from accuracy. Accuracy is the distance from
the ground truth to a calculated location where uncertainty is the uncertainty of the
calculated location given the set of input measurements and the geometry of the
North
Orientation
Semimajor axis
Lat, long, alt
(a) Aerial view
Semiminor axis
Altitude uncertainty
(b) Plane view
Figure 3.9 Uncertainty ellipsoid: (a) aerial view and (b) plane view.
transmitters from which the measurements are taken. Accuracy can only be deter-
mined if the ground truth of the handset is known.
Confidence is the measure of how certain we can be that the location is inside a
given area. A location specified at a higher confidence will have a higher uncertainty
(a larger uncertainty ellipsoid) than one specified at a lower confidence. Confidence
is a statistical measure of the size of the uncertainty and is based on a normal proba-
bility distribution [16]. The position calculation is discussed in more detail in Chap-
ter 6 but you will see that the least squares process calculates the uncertainty ellipse
at a specific confidence. This ellipse is then scaled using a Gaussian scaling in order
for its size to reflect the desired confidence.
The Gaussian scaling is performed using the inverse error function [17] and the
scaled uncertainty is given by
58 GPS
⎛ 1
⎞
erfinv⎜⎜ desiredConfidence n ⎟⎟
⎝ ⎠
scaledUncert = initialUncert × (3.9)
⎛ 1
⎞
erfinv⎜⎜Confidence n ⎟⎟
⎝ ⎠
where scaledUncert is the uncertainty at the desiredConfidence, initialUncert is the

uncertainty as Confidence, and n is the number of dimensions, which is normally 2.
3.14 Factors Affecting Location Accuracy
The major sources of error when calculating a GPS-based location are shown in
Table 3.7.
The ionosphere is the uppermost part of the atmosphere and stretches from a
height of about 50 kilometers to more than 1,000 kilometers. As the GPS signal is
transmitted through the ionosphere, it is dispersed by the free electrons that are in
the ionosphere. The ionosphere varies significantly from day to day, and also within
a day as a result of solar conditions [18]. The typical global average ionosphere
delay errors for L1 vary from 9.8-meter 95% for benign ionospheric conditions, to
19.6-meter 95% for disturbed ionospheric conditions [1]. The errors can be as large
as 100 meters in some solar conditions. The largest errors are seen during solar
storms.
The GPS ionosphere model will typically remove about half of the ionosphere
error from the measurement [2]. The effect of the ionosphere is more significant for
the satellites lower to the horizon. One way to reduce the impact is to apply a mask
angle so that satellites below a certain angle are removed from the position
calculation.
The troposphere is the region that exists from the surface of the Earth to an alti-
tude of about 50 kilometers. GPS signals traveling through the troposphere will be
affected by a tropospheric refraction delay. The bias can be up to 20 meters for sig-
nals from satellites that are low on the horizon. Dry atmospheric effects are easily
modeled and account for 90% of the troposphere [18]. The wet atmosphere is
highly variable and difficult to model. The tropospheric delay is a function of tem-
perature, pressure and relative humidity. A troposphere model is a model that pre-
dicts the delay in the signal reaching the handset from the satellite due to the
troposphere. The delay is calculated according to the slant path from the satellite to
Table 3.7 Major Sources of Range Error

Error source Error magnitude
Ionosphere 20 meters (low elevation satellites)
Troposphere 6 meters (low elevation satellites)
Ephemeris error 1–2 meters
Satellite clock error 1–2 meters
Multipath 5 meters (highly dependent on environment)
Measurement error 1 meter
3.15 Geometry and Dilution of Precision 59
the point on the ground. An example is a seasonal based model, which models tem-
perature, pressure, and humidity at different times of the year.
Other errors that contribute to the overall error in the calculated location
include ephemeris error, satellite clock error, multipath, and measurement error.
Ephemeris error is inaccuracy in the predicted model. Satellite clock error is due to
errors in the satellite clock even after the satellite clock correction is applied.
Multipath is also known as nonline-of-sight error (NLOS) and occurs when a signal
does not take a direct path to the receiver, but reflects off one of more objects.
NLOS errors are common among built-up areas.
3.15 Geometry and Dilution of Precision
One of the major factors in the accuracy of a location is the geometry of the trans-
mitters. When the transmitters are very close together, the area of overlap of the sig-
nals is larger and hence the area of uncertainty is larger. Consider Figure 3.10,
where signals from two transmitters are shown, each with the corresponding con-
stant range error. When the transmitters are spread such as they are in Figure
3.10(a), the area of uncertainty is relatively small. Figure 3.10(b) shows the situa-
tion where the errors in the range measurements are the same as Figure 3.10(a);
however, because the transmitters are relatively close together, the area of
uncertainty has become much larger.
A measure of the spread of the transmitters is called the dilution of precision
(DOP). It is a measure that can be calculated to determine how uncertain the result-
ing location will be. The smaller the number, the smaller the uncertainty area;
hence, a more accurate location. Details of calculating the DOP are shown in Chap-
ter 6. Figure 3.11 shows an example of good DOP and poor DOP. In general, the
more spread that the transmitters (satellites) are, the better the resulting location.
3.16 Differential-GPS
Differential-GPS (DGPS) was developed for high-accuracy applications. The hand-

set can calculate a highly accurate location by using differential corrections pro-
vided by an external source. DGPS is based on the fact that receivers in the same
area will experience common errors in the range measurement to a particular satel-
lite. These are the errors generated by the propagation of the RF signal through the
medium between the satellite and the handset, the satellite clock, and ephemeris
errors. The accuracy of DGPS degrades as the distance from the reference station
increases. It will generally be accurate when the handset is within 100 kilometers of
the receiver that is used to provide the corrections [18].
A simplified DGPS architecture is shown in Figure 3.12. A GPS reference
receiver is located at an accurately surveyed location (R1). It makes range measure-
ments to the satellites in view, and using its accurately known location, it deter-
mines the amount of error in each satellite measurement. When a GPS handset in the
vicinity of R1 is calculating its location, it applies the corrections that were calcu-
lated by the reference station to each of the measurements before calculating the
60 GPS
(a) Uncertainty area for well

disrtibuted transmitters
Range error from Tx2
Range error from Tx 1

Tx 2
Tx 1
(b) Uncertainty area for

colocated transmitters
Tx 1 Tx 2
Figure 3.10 Effect of DOP.
location. When a larger coverage of an area is required, a network of GPS reference

receivers is used to generate the corrections and the handset is provided with correc-
tions that have been generated by the nearest reference receiver and high accuracy
can be obtained within the larger coverage area.
3.17 Software Projects
The following are software projects for this chapter:
1. What is the unit test case code coverage for the broadcast package?
Good DOP Poor DOP
Figure 3.11 Good DOP and poor DOP.
Corrections
GPS handset
GPS reference x, y, z, t
receiver
R 1 (x, y, z)
Figure 3.12 Differential-GPS architecture.
2. Consider the classes in the novatel package. Access the specification for a
different receiver and download some logs from one. Write the code to
process the navigation data into a NavMessage object. Try to achieve 100%
code coverage.
3. Write an application to see when the NAV message changes and report on
the changes by satellite throughout a day.
4. Write code to report on unhealthy satellites throughout a day.
5. Write some code to calculate the current UTC offset.
6. The satellite location calculation method is tested using some hardcoded
data extracted from an SP3 file that calculates the locations of the
satellites at one instant in time. Enhance the code so that it reads a real
62 GPS
SP3 file and, for each set of satellite locations, calls the Satellite class to
calculate the location of the satellite. The test class then compares the
calculated locations and fails the test if the locations are further than the
configured distance apart.
References
Performance Standard, 4th ed., September 2008.
Signal Specification, 2nd ed., June 2005.
[3] Parkinson, B. W., “Introduction and Heritage of NAVSTAR, the Global Positioning Sys-
tem,” in Global Positioning System: Theory and Applications, Vol. 1, Washington, D.C.:
American Institute of Aeronautics and Astronautics, Inc., 1996.
faces, Interface Specification, IS-GPS-200, Revision D, Navstar GPS Joint Program Office,
El Segundo, CA, 2004.
[5] GPS Navstar Joint Program Office, Navstar GPS Space Segment/User Segment L1C Inter-
faces, IS-GPS-800, Space and Missile Systems Center, Navstar GPS Joint Program Office, El
Segundo, CA, 2006.
[6] GPS Navstar Joint Program Office, Navstar GPS Space Segment/User Segment L5 Inter-
faces, IS-GPS-705, Space and Missile Systems Center, Navstar GPS Joint Program Office, El
Segundo, CA, 2005.
[7] International Committee on Global Navigation Satellite Systems (ICG),
http://www.oosa.unvienna.org/oosa/SAP/gnss/icg.html.
[8] Klobuchar, J. A., “Ionospheric Effects on GPS,” in Global Positioning System: Theory and
Applications, Vol. 1, Washington, D.C.: American Institute of Aeronautics and Astronau-
tics, Inc., 1996.
[9] The NovAtel log format specification, http://www.novatel.com/.
[10] Gurtner, W., RINEX: The Receiver Independent Exchange Format, Version 2.10, Astro-
nomical Institute, University of Berne, June 8, 2001.
[11] SOPAC, Scripps Orbit and Permanent Array Center, http://sopac.ucsd.edu/.
[12] The International GNSS Service, http://igscb.jpl.nasa.gov/.
[13] Hilla, S., The Extended Standard Product 3 Orbit Format (SP3-c), National Geodetic Sur-
vey, National Ocean Service, NOAA, Silver Spring, MD, 2007.
[14] GPS Navstar Joint Program Office, Navstar GPS User Equipment Introduction, September
1996.
[15] GPS Navstar Joint Program Office, Global Positioning System User’s Overview,
YEE-82-009D, GPS JPO, El Segundo, CA, March 1991.
[16] Weisstein, E. W., “Confidence Interval,” in MathWorld: A Wolfram Web Resource,
http://mathworld.wolfram.com/ConfidenceInterval.html, 2009.
[17] Weisstein, E. W. “Inverse Erf,” in MathWorld: A Wolfram Web Resource,
http://mathworld.wolfram.com/InverseErf.html, 2009.
[18] Spilker, J. J., and B. W. Parkinson, “Overview of GPS Operation and Design,” in Global
Positioning System: Theory and Applications, Vol. 1, Washington, D.C.: American Insti-
tute of Aeronautics and Astronautics, Inc., 1996.
CHAPTER 4
Assisted-GPS and Assistance Data

The primary limitation of stand-alone GPS, discussed in the previous chapter, is the
amount of time that it takes to download the navigation message. In addition, the
handset is restricted to using signals that are strong enough to allow the navigation
message to be demodulated. This may cause a problem in low signal environments
where weak signals are expected and in situations where a very fast location is
required such as in an emergency.
The goal of Assisted-GPS (A-GPS) is to improve the TTFF and the yield com-
pared to stand-alone GPS by removing the need to demodulate the navigation mes-
sage from the broadcast signal. This means that the handset does not need to wait
for the navigation message and can make use of much weaker signals. In addition,
the A-GPS server can perform calculations that mean that the handset has less to do
and can conserve its battery. Also, the assistance data focuses the search so that the
handset can lock onto the satellites much faster.
This chapter describes the Assisted-GPS model and the assistance data. It dis-
cusses the architecture in detail and each component in the network, including the
GNSS Reference Server (GRS), the location server (LS), the location-based applica-
tion (LBA), the Emergency Services Messaging Entity (ESME), and the handset.
Each assistance data type is introduced, the methods to calculate it are explained,
and its use is outlined. Note that this book provides the practical details of server
side A-GPS implementation. For the detailed background theory and mathematics,
the reader should consult a general GPS book such as [1, 2].
4.1 The Assistance Model
As introduced in Chapter 1, the LS is a component in a wireless network that

retrieves reference information from a GRS and provides assistance data to an
A-GPS capable handset on-demand. The general A-GPS architecture is shown in
Figure 4.1.
The GNSS Reference Server (GRS) connects to a sparse network of GNSS
receivers (GPS receivers for this discussion) that are spread either across the cover-
age area of the wireless network or geographically over the Earth for global cover-
age. Note that only one is shown in the diagram for illustration, but there is a
network of them. The GRS is a central system that collates all of the information
and provides it to the LS on request. The GRS is discussed in more detail in the
following section.
The LS requests GPS data from the GRS and caches that data on a regular basis.
The LS will generally request the navigation model, the ionosphere model, the UTC
63
64 Assisted-GPS and Assistance Data
GNSS Reference
Server (GRS)
GPS receiver
A-GPS handset
Serving cell
Network
Time server
Location Server (LS) Initial uncertainty area
(NTP)
Emergency Services
Location-based
Messaging Entity
application (LBA)
(ESME)
Figure 4.1 A-GPS architecture.
model, and some subframe header information. The protocol between the LS and
the GRS is proprietary, but often consists of an HTTP wrapper with either raw
binary data or a standards-based encoding such as RRLP [3].
When a request is received from a handset for assistance data, the LS uses the
approximate location and uncertainty of the handset to package up assistance data
that is relevant for that location. The approximate location generally comes from
the location of the cell in a cellular network. The handset uses the provided assis-
tance data to lock on to the satellites and either calculate its own location or pass the
measurements back to the LS to perform the position calculation.
The protocol between the LS and the handset is standards-based and generally
depends on the radio access network type. For example, for GERAN, the protocol is
RRLP [3] and for UTRAN the protocol is PCAP [4]. The LS is discussed in more
detail in Section 4.3. Note that in a UTRAN network, the LS is a stand-alone SMLC
(SAS) and uses PCAP to talk to an intermediate node called the radio network con-
troller (RNC). The RNC does some manipulation of the data and uses Radio
Resource Control (RRC) Protocol [5] to interact with the handset.
The time server is a component that provides accurate time to the LS. This
allows the LS to provide the most accurate time possible when it is providing time to
the handset in the reference time data type. The time server will normally be in the
same local network as the LS. The interface between the time server and the LS is via
the Network Time Protocol (NTP) [6]. NTP is a protocol for synchronizing clocks
over a variable latency, packet-switched network, which can achieve accuracies of
200 microseconds in local area networks.
The location-based application (LBA) is an entity that connects to the LS in
order to request the location of a handset in the network. The LBA is normally sub-
ject to strict privacy controls and uses the Mobile Location Protocol (MLP) [7] to
interact with the LS. MLP is an XML-based protocol that allows the LBA to request
the location of a specific handset and receive the result. The result is a location with
a given uncertainty at a specific confidence and it is subject to the quality of position
(QoP) parameters provided in the request.
In the United States, the North American Emergency Services (NAES) model is
used to deliver the location to the Public Safety Answering Point (PSAP) via an
Emergency Services Messaging Entity (ESME) using the National Emergency Num-
ber Association’s (NENA) E2 interface [8]. The E2 interface is applicable to the
GMLC or MPC and is defined with a binary protocol. The ESME connects to the
MLC over the E2 interface and requests the location of specific handsets. Note that
the emergency services architecture is different in other parts of the world, which
means that the LBAs outside the United States will normally be sending in both
emergency and nonemergency requests over the MLP interface.
4.2 GNSS Reference Server (GRS)
The GRS caches data from GPS receivers and makes it available to the LS on a client
interface. The architecture of a global coverage GRS is shown in Figure 4.2.
Figure 4.2 shows an example network of GPS reference receivers that are
sparsely distributed around the Earth, with a connection from the GRS to each fixed
receiver. The receivers are considered as part of the GRS and are likely to be con-
nected to the GRS using TCP/IP, but may use any appropriate protocol. If TCP/IP is
used, each receiver may have its own terminal server or may directly support
TCP/IP.
The receivers are likely to have their own proprietary data format for supplying
the GPS data back to the GRS. Some GPS receivers may use a proprietary version of
a well-known format such as RINEX [9]. The GPS receivers may be configured to
continually stream the data to the GRS, or they may work using a request/response
model where the GRS requests the data it requires. The important thing is that the
information is provided back to the GRS in near real time. This means that the data
in the GRS is fresh and some of the more time-critical information, such as the
subframe header information, is available to the LS, and hence the handset, very
quickly.
Figure 4.2 shows that all of the receivers are connected back to the GRS via
some sort of network. The task of the GRS is to collate the most up-to-date informa-
tion from all of the GPS receivers and make that information available over a client
interface.
Each GPS receiver in the network receives per-satellite information from all of
the satellites that are visible to it. The per-satellite information includes subframe
headers, satellite accuracy and health information, satellite clock correction fields,
and the ephemeris. If there is any overlap in the field of view of the receivers, the
GRS will receive multiple copies of the ephemeris for each satellite. The GRS needs
to check the timestamp (and the IODE and IODC) of each set of ephemeris for a
particular satellite and store the most recent copy of the data.
Satellite
broadcast
information
Fixed GPS
receiver
GNSS Connections to GPS
Reference reference receivers
Server
(GRS)
Client Earth
interface
Figure 4.2 GRS architecture.
Almanac and other subframe 4 information are visible to all of the reference
receivers since they are transmitted by all of the satellites. The GRS only needs to
keep a single copy of the most up-to-date version of this.
Once the data is collated, the GRS will normally open a port to allow clients (for
example, the LS) to connect over the client interface in order to request and receive
GPS data.
4.2.1 GPS Reference Receiver Configuration for a GRS

The purpose of spreading the GPS reference receivers around the coverage area is so
that the GRS has the data for all of the possible satellites that are in view from all
regions within the coverage area. Each satellite transmits ephemeris information
about itself, so to get information about all of the satellites, the GRS needs to have a
geographically spread network of GPS receivers.
The GPS satellites are oriented towards the Earth and the antenna patterns are
such that the main beam covers the Earth and extends beyond the surface of the
Earth [10]. From the point of view of the GPS satellite, the Earth subtends an angle
of approximately 27.74°. The half-beamwidth of GPS L1 is 21.3° (covers an angle
of 42.6°) and the half-beamwidth of GPS L2 is 23.4° (covers an angle of 46.8°). This
means that objects above the surface of the Earth or even a satellite on the far side of
the Earth with a GPS receiver can measure the signals, provided that it is not in the
Earth’s shadow.
Figure 4.3 shows a cross-sectional view of the Earth with two GPS reference
receivers on the surface and one satellite in orbit.
For simplicity, in Figure 4.3, the Earth is modeled as a circle with its radius a
equal to the semimajor axis of the WGS 84 ellipsoid. The outer circle is the plane in
which the satellites orbit, approximately 20,180 kilometers above the surface of the
WGS 84 ellipsoid. The range from the surface of the Earth to the satellite is shown
as r.
One GPS satellite is shown that is in the periphery of the field of view of both of
the GPS receivers. The arc on the surface of the Earth between the two GPS receivers
is the maximum distance that two GPS receivers can be separated in order for the
satellite to be detected by at least one of the receivers. If the receivers are separated
by a greater distance, then there will be a gap in the coverage where the satellite is
not being measured and the GRS will not have access to the current subframe
header information, or possibly even the updated ephemeris, if there is a change in
the ephemeris when the satellite is in the area of no coverage.
The figure shows that the angle 2α gives the maximum angular separation
between the receivers in order to ensure coverage. Using the cos rule, α is given by
⎛ a ⎞
α = cos −1 ⎜ ⎟ = 761
. degrees (4.1)
⎝ a + r⎠
GPS
Reference
receiver
α
a + r
r
GPS
Reference
Earth
receiver
Approximate satellite orbit
Figure 4.3 GPS reference receiver separation.

where r is the approximate elevation of the satellite, which is 20,180,000 meters,

and a is the semimajor axis of the WGS 84 ellipsoid, which is 6,378,137.0 meters.
The maximum separation d on the surface of the Earth is given by converting
the distance around the circumference of the circle to a distance in (4.2).
2α
d = 2 πa = 16,945,0233
. meters (4.2)
360
The maximum separation on the surface of the Earth is 16,945 kilometers.

Note, however, that there is no overlap in the coverage at all and no redundancy.
An improved design is to have some overlap so that the GRS can provide extra cov-
erage (redundancy) at the points where the coverage areas meet. This is shown in
Figure 4.4.
In Figure 4.4, the amount of overlap as seen by the GPS reference receiver is
given by β. The angular separation between the receivers is given by α + χ where α is
the same as calculated above (76.1°). The angle χ is calculated using the sine rule to
determine δ and then use the sum of the angles of a triangle. Using the sine rule and
simple manipulation gives δ as shown in
⎛ a sin( β + 90)⎞
δ = sin −1 ⎜⎜ ⎟⎟ (4.3)
⎝ a+r ⎠
GPS
Reference
receiver δ
β
χ
a+r
r α
GPS
Reference
receiver
Earth
Approximate satellite orbit
Figure 4.4 Two-dimensional view of field of view with overlapping field of view.
and χ is given by
χ = 180 − (( β + 90) + δ) (4.4)
In the case where the overlap (β) is 5°, δ is 13.8°, χ becomes 71.2°, and the angu-
lar separation (α + χ) becomes 147.34°. The maximum distance d on the surface of
the Earth becomes 16,348,941.2 meters, or 16,349 kilometers. Furthermore, when
the overlap is 10°, the separation becomes 142.53°, which translates to a distance of
15,816 kilometers.
To cover a local area of the Earth, such as mainland United States, we would
simply need to put receivers at the extremities of the coverage area since the distance
between two points is less than 15,816 kilometers (using the example 10° overlap).
The reason for putting the receivers as close to the perimeter as possible is to
ensure that the GRS has the most up-to-date information from the rising and setting
satellites.
The discussion up to this point has focused on the minimum requirements to
laying out a GPS receiver network. However, redundancy is an important consider-
ation when planning a network. Redundancy includes duplicating equipment
within a site and duplicating sites within the network. The designer of the GRS
should consider the availability requirements when deciding where to site the
receivers and other network equipment. A high availability GRS may use a hot
standby or a round-robin system within each site or may even consider each GPS
receiver in the network as an independent unit that is collecting data. In this case,
the GRS simply takes a feed from all of the receivers in the network and collates the
information. It is important that the GRS performs integrity monitoring of the
receivers in the network.
If the GRS is providing differential corrections, the network of reference receiv-
ers needs to be significantly denser. As discussed in Chapter 3, the corrections will
be most accurate when the handset is within 100 kilometers of the reference station
that is used to provide the corrections. Comprehensive discussion about the refer-
ence network can be found in [11].
4.2.2 GRS Interface

There is presently no standard defined for the interface between the GRS and the LS
despite work in standards bodies including a recent push in the Open Mobile Alli-
ance (OMA) Location group. This has lead to a proliferation of proprietary inter-
faces that have been implemented by the GRS suppliers. They fall into two main
categories of HTTP-based interfaces and a proprietary RINEX-based format.
The general procedure of the HTTP-based interface is to use an HTTP GET and
specify the assistance data types and the required format. The proprietary
RINEX-based format involves retrieving RINEX files using FTP. The reason that
the RINEX format needs proprietary extensions is because RINEX does not sup-
port all of the fields required for A-GPS. For example, RINEX does not support
subframe header information and several of the ephemeris parameters.
It would be very helpful to both network operators and LS vendors to have a
standard interface defined for this part of the network. The advantage to the net-
work operator is that the network operator does not need to have changes made to
the LS each time that they want to change GRS providers. The advantage to the LS
providers is that they do not need to support a multitude of different interfaces to
GRS providers. GNSS Reference Interface Protocol (GRIP) [12] is presently the only
open protocol that has been defined between and LS and the GRS and it is discussed
in the next section.
4.2.3 Open Source GNSS Reference Server (OSGRS)

The OSGRS is an open source project to develop a GRS [13] in Java with a com-
pletely open protocol called GRIP [12]. The OSGRS is being developed at the Uni-
versity of New South Wales (UNSW), Australia, to support researchers developing
A-GNSS algorithms and to enable testing of GRIP clients.
The OSGRS is a GRS that connects to one or more data sources to collect the
GNSS data and then opens up an interface for clients that can make requests using
GRIP. The OSGRS architecture is shown in Figure 4.5. The OSGRS shown has a
GPS data source that retrieves data from the GPS satellites. The data source is a Java
source code package that connects to some hardware. The data source is pluggable
into the OSGRS architecture by implementing the Java DataSource interface. For
example, the OSGRS supports a GPS data source that consists of one or more
NovAtel OEM2, OEM3, and/or OEM4 receivers that are deployed in the area of
interest.
The OSGRS is configured with the data source to use. Each data source may
have an extra configuration associated with it. For example, the NovAtel data
source requires configuration of a list of one or more IP addresses with the associ-
ated terminal server port and COM port. On start-up, the data source connects to
all of the configured receivers, collects the GPS data, and caches it. Once it has col-
lected the data, it provides notification to the main class of the OSGRS that it is
ready to supply data. The OSGRS periodically retrieves the updated data from the
data source so that it can provide the most up-to-date and relevant information to
clients. The OSGRS also performs integrity checking of the data to ensure that it is
up to date and also checks data source to ensure that it is operating correctly.
The client (in Figure 4.5 this is an LS) makes requests to the OSGRS for GNSS
assistance data using GRIP. GRIP is an XML schema based protocol that uses
HTTP to transport the requests and responses. The request contains the list of data
types required and the response contains the data or an appropriate error code.
GRIP defines the structure of the HTTP POST that is initiated by the client and also
the structure of the XML document in the body of the request and response.
The GRIP requests and responses are defined by a set of XML schemas. An
example request is shown next. The request is asking for the GPS assistance data
Open Source
Location
GNSS Reference GPS
Server GRIP Data
Server
(LS) source
(OSGRS)
Figure 4.5 Example OSGRS architecture.

types listed: navigation model, ionosphere model, real-time integrity, UTC model,
and reference time. Note that the request shown is only for GPS assistance data
(GNSSType parameter); however, GRIP is not restricted to GPS.
<?xml version="1.0" encoding="UTF-8"?>
<GNSSRequest GNSSType="GPS"
xmlns="http://www.gmat.unsw.edu.au/snap/grip/1.5"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<AssistTypeAllSats data="NavModel IonoModel RTI UTC RefTime"/>
</GNSSRequest>
The response provided from the OSGRS is shown next. Note that it is only
showing two satellites for the per-satellite assistance data types to be concise, but
the client expects to receive assistance data for all satellites that are in view of the
data source. If the data source consists of a stand-alone receiver in open sky, for
example, then the client would expect to see the assistance data for 10 to 12 satel-
lites or more. If the data source is from a global network such as a commercial pro-
vider or a Web-based RINEX data source, then the assistance data for all satellites
would contain the full constellation of satellites. A-GPS assistance data types and
their contents are discussed later in this chapter.
<?xml version="1.0" encoding="UTF-8"?>
<GNSSResponse GNSSType="GPS"
xmlns="http://www.gmat.unsw.edu.au/snap/grip/1.5"xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<AssistTypeAllSats>
<NavModel>
<sat
number="2">8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190EFA448B065C8CA12AA50
91B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B065C8CA1AC0079F86A32C9FFF0269127BC14675
EF1C04CFFAB23A5E094</sat>
<sat
number="4">8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF80143D38B065C8CA12A870
A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B065C8CA1ACFFFBF9331B37FFA6268B1C9813770
AD0980CFFAB4C87E6B3</sat>
</NavModel>
<IonoModel>
<Data>0602FFFE2906FFF8</Data>
</IonoModel>
<RTI>
<badSats>3 6 8 24</badSats>
</RTI>
<UTC>
<Data>00001F0000000890970E4B070E</Data>
</UTC>
<RefTime>
<sat number="2">407 5410671 2 407 1 0 0</sat>
<sat number="4">407 5410671 4 407 1 0 0</sat>
</RefTime>
</AssistTypeAllSats>
</GNSSResponse>
In addition to the all-satellites data, GRIP also supports the concept of satellites
in view. This means that the client can request the assistance data for a certain lati-
tude, longitude, and altitude, and the OSGRS will only return the satellites that are
in view from that location.
The OSGRS can be downloaded as Java source code and documentation from
the OSGRS Web page [12]. As well as source code, the OSGRS consists of the GRIP
specification and design documentation with the classes described using UML.
4.3 Location Server (LS)
The LS is the node that receives a request from the LBA, the ESME, or the handset to
determine a location. Depending on the capabilities of the handset, the LS packages
assistance data into the format required by the protocol that is being used and pro-
vides the assistance data to the handset. The handset may use the assistance data to
lock onto the satellites and calculate its own location, or it may return the measure-
ments to the server to calculate the location.
As outlined in Chapter 1, the protocol used by the LS to communicate with the
handset often depends on the radio access network (RAN). The LS is often an MLC
that is a node that runs in various networks and can act as stand-alone mobile location
center (SMLC), gateway mobile location center (GMLC), stand-alone SMLC (SAS)
[14], SUPL location platform (SLP) [15], or location information server (LIS) [16].
There are several different standards for the A-GPS messaging with the handset.
RRLP [3] is used by the SMLC and SLP, PCAP [4], and RRC [5] in UTRAN net-
works and TIA-801 [16] in CDMA networks and may also be used by the SLP.
These protocols are different ways of encoding the same basic information but are
specific to the radio access technology.
The secure user plane location (SUPL) architecture [15] is an alternative proto-
col that allows the bypass of many of the traditional telecommunication elements by
allowing the handset to make a TCP/IP connection directly with the SLP.
The specific protocol and details of the messaging is discussed in Chapter 5.
However, the basic message flow for an LBA-initiated nonemergency A-GPS loca-
tion is shown in Figure 4.6 and described next. The numbers in the following steps
relate to the numbers shown in Figure 4.6.
1. An LBA requires the location of a handset and sends in a location request.

2. The LS sends a position request to the handset.
3. The handset responds with its capabilities. If it is GPS-capable, it will have a
list of the assistance data types that it requires
4. The LS packages up the required assistance data and sends it to the handset.
5. In the case of handset-based A-GPS, the handset locks onto the satellites and
calculates its location. It returns the location to the LS.
6. The LS forwards the location to the LBA.
There are other messaging scenarios such as pushing the assistance data in the
initial message in (2) and when the messaging is initiated by another entity such as
the handset. The LS often performs additional functions such as logging and billing.
In order to determine the assistance data to send to the handset, the approxi-
mate location of the handset is required. The cell identifier is provided in the
messaging and the LS retrieves information about the cell from its internal cell data-
base. This information includes the latitude and longitude of the cell and the size of
the cell (a cell is normally described with a range, an orientation from the North,
and an opening angle). Since the handset can be anywhere inside the cell, the loca-
tion of the center of the cell area is used as the location from which to calculate the
satellites in view. If the initial area is very large, more complex mechanisms are
required to determine the satellites in view from the entire uncertainty area.
4.4 Location-Based Application (LBA) 73
MLC
periodically
requests data
from the GRS
using GRIP or
a proprietary
GNSS reference
protocol
server (GRS)
Time is
synched using
NTP protocol
Time server Location server 2. Position request

(NTP) (LS)
A-GPS handset
3. Required assistance data

6. Location response
1. Location request
4. Assistance data
5. Location
Initial uncertainty area
Location-based
application (LBA)
Figure 4.6 General A-GPS message flows.
In order to determine the assistance data, the first step is to determine which sat-
ellites are in view of the approximate location. The LS uses the ephemeris to calcu-
late the location of all of the satellites in WGS 84 ECEF coordinates. It then
calculates the elevation between the initial location and each satellite. All of the sat-
ellites that are above a certain mask angle are considered to be in view of that loca-
tion. The mask angle may be 0° or 5°.
Given the list of satellites that are in view, the LS pieces together the assistance
data message with all of the required assistance data types for that set of satellites.
In this section we have described the basic operation of an LS in terms of GPS.
However, the LS may support other GNSSs in conjunction with GPS or alterna-
tively to GPS. Other GNSSs and A-GNSS are discussed further in Chapter 10.
4.4 Location-Based Application (LBA)
The LBA is an entity in the network that connects to the MLC in order to request the
location of a handset. The LBA connects and requests locations using the MLP pro-
tocol [7]. In the LCS architecture [14] this interface is known as the Le interface.
MLP requests for location can be either emergency or standard requests. In the
NAES model, the E2 interface is used for emergency requests instead of MLP; this is
discussed in the next section.
Some examples of LBAs include tracking applications, child-finder applica-
tions, applications that provide directions to services or facilities, and geo-games.
They all require the location of the handset at a given time.
The MLP protocol is an application-level request/response protocol that is

defined by OMA, which allows the LBA to request the position of a handset. The
MLP is independent of the underlying network technology. In order to issue MLP
requests, the LBA makes a connection to the GMLC or MPC component of the LS.
The MLP is defined as a set of XML documents, each of which is described by a
document type definition (DTD). The transport may be one of several, including
HTTP, Wireless Session Protocol (WSP), and Simple Object Access Protocol
(SOAP), and there are several different types of requests. An MLP immediate
request is a request from the LBA to the LS to retrieve a single response within a set
time. There are variants of the MLP message for emergency and nonemergency
requests. There is also a reporting service where the LS can deliver the location of
the handset to the LBA without previously receiving a request, and a triggered
reporting service where the location of the handset is reported to the LBA on a given
time interval or in response to a specific event.
The following example is a standard location immediate request (SLIR) to
request the location of a particular handset that is identified by a Mobile Station
ISDN (MSISDN) of 0800000000. The connection between the LBA and the LS
would normally use transport layer security (TLS) for authentication; however, the
client ID can also be specified in the MLC request. Alternatively, the LBA may con-
nect though a virtual private network (VPN). The ID is a string defining the name of
a registered user performing a location request and is used by the LS as a log-in
mechanism. The quality of position (QoP) parameters (eqop) specify the require-
ments on the calculated location. In this case, the response time attribute is set to
DELAY_TOL (delay tolerant) which means that the fulfillment of the accuracy
requirement takes precedence over the fulfillment of the response time requirement.
The horizontal and altitude accuracy requirements are 100 and 50 meters, respec-
tively, with a maximum location age of 30,000 milliseconds, or 30 seconds.
<?xml version="1.0" ?>
<!DOCTYPE svc_init SYSTEM “MLP_SVC_INIT_300.DTD”>
<svc_init ver="3.0.0">
<hdrver="3.0.0">
<client>
<id>2</id>
<pwd>hummer</pwd>
</client>
</hdr>
<slir ver="3.0.0" res_type="SYNC">
<msid type="MSISDN">0800000000</msid>
<gsm_net_param></gsm_net_param>
<eqop>
<resp_req type="DELAY_TOL"/>
<hor_acc>100</hor_acc>
<alt_acc>50</alt_acc>
<max_loc_age>30000</max_loc_age>
</eqop>
<loc_type type="CURRENT"/>
<prio type="NORMAL"/>
</slir>
</svc_init>
The corresponding response is shown next in the standard location immediate

answer (SLIA). The location is provided as an ellipse with the coord parameter
defining the latitude and longitude. The uncertainty of the location is defined as an
ellipse with a semimajor axis and a semiminor axis and an altitude and altitude
uncertainty. The uncertainty ellipse is also specified with a confidence of 80%.
4.5 Emergency Services Messaging Entity 75
<?xml version = “1.0" ?>

<!DOCTYPE svc_result SYSTEM “MLP_SVC_RESULT_300.DTD”>
<svc_result ver="3.0.0">
<slia ver="3.0.0">
<pos>
<msid type="MSISDN" enc="ASC">0800000000</msid>
<pd>
<time utc_off="1000">20090407141422</time>
<shape>
<EllipticalArea srsName="www.epsg.org#63266405">
<coord>
<X>-34.41599786281586</X>
<Y>150.8734953403473</Y>
</coord>
<angle>45.0</angle>
<semiMajor>23.0</semiMajor>
<semiMinor>15.0</semiMinor>
<angularUnit>Degrees</angularUnit>
<distanceUnit>meter</distanceUnit>
</EllipticalArea>
</shape>
<alt>41</alt>
<alt_acc>29</alt_acc>
<lev_conf>80</lev_conf>
</pd>
</pos>
</slia>
</svc_result>
4.5 Emergency Services Messaging Entity
The interface between the ESME and the LS for NAES (used in the United States) is
specified in the J-STD-036 [19]. The details of the protocol are defined by the E2
interface [8]. Emergency Services Protocol (ESP) messages flow over the E2 inter-
face between the ESME and the LS and enable the ESME to request the location of a
particular handset. In a redundant system, the PSAP will generally be linked to one
or more ESMEs that, in turn, have connections to one or more LSs.
The ESP messages are in a binary format that allows the ESME to query for
an initial cached location, an updated location, or a last known location. The
ESP request contains the parameters to identify the handset and the position
request type required (initial, updated, or last known). The ESP request response
contains the location or if the request was not fulfilled, and the LS returns an ESP
request response error. The ESP protocol has a restricted set of shapes that are
returned compared to the GAD specification. The following shapes are supported
by E2:
• Ellipsoid point, which is a point on the WGS 84 ellipsoid (latitude and longi-
tude);
• Ellipsoid point with uncertainty, which is a circle on the ellipsoid (latitude,
longitude, uncertainty in meters, and confidence);
• Point with altitude and uncertainty, which is the same as the circle but also
includes altitude and altitude uncertainty.
The result of a GPS position calculation is normally an ellipsoid point with alti-
tude and uncertainty ellipsoid. In order to convert the location into something that
can be sent over E2, the uncertainty ellipse is converted to a circle.
4.6 The Handset
The handset contains a GPS receiver that is specifically designed to receive GPS sig-
nals. It will also have certain enhancements in order to make use of the assistance
data, and it will have a component that can connect to the wireless network in order
to exchange information and receive assistance data from the LS. It may be a cellu-
lar handset or could be a laptop computer or any other type of networked device
such as a camera or a scientific instrument. The handset will be running an applica-
tion that knows the protocol to use for the RAN that it is connected to, may be using
ULP to communicate with an SLP, or may be using some proprietary protocol to
talk to a custom LS.
The handset may initiate the location request, for example, by invoking an LBA
or by dialing the emergency number. Alternatively, the location may be initiated by
the network. Regardless, the A-GPS capable handset will request the assistance data
that it needs to commence a GPS location calculation.
When the handset receives and decodes the assistance data message, it starts
searching for the specific satellites. Once it acquires the first satellite, the offset of
the local oscillator can be determined and accounted for. The acquisition of the
other satellites can be performed very rapidly since the information is provided in
the assistance data. Once the satellites are acquired, the receiver does not need to
demodulate the NAV message but can use the information transmitted through the
wireless network to aid the calculation process. The NAV model is used to correct
for different factors and to calculate the clock offset and location of the satellites in
order to facilitate the location calculation in a handset-based A-GPS operation.
An alternative mode of operation of the handset is to run in handset-assisted
mode. In this mode, more compact assistance data is provided to the handset in
order for it to lock onto the satellites. The handset just makes the measurements and
returns them to the server in order for it to do the calculation. This frees the handset
up from performing battery-consuming calculations and allows the server to per-
form hybrid calculations by using other terrestrial-based measurements in addition
to the satellite measurements.
A more detailed description how an A-GPS handset operates can be found in
[20].
4.7 Assistance Data Types
This section describes the significant GPS assistance data types. A summary of the
different assistance data types was provided in Table 1.1. It is worth noting that
there are some assistance data types that apply to the entire GPS and some that are
per satellite.
The two significant modes of A-GPS are handset-based A-GPS and hand-
set-assisted A-GPS. For handset-based A-GPS, the handset performs the location
calculation, whereas for handset-assisted, the calculation is performed on the
server.
Handset-based A-GPS requires a significant amount of information to be trans-
mitted to the handset compared to handset-assisted. This is because the handset
needs to determine where the satellites are in order to restrict its search space and
calculate the location of the measured satellites once the measurements have been
made. Finally, it performs the position calculation using the measurements cor-
rected using the ionosphere model.
Handset-assisted A-GPS, on the other hand, relies on the LS to use the assistance
data to calculate the search space for the measurement acquisition and finally calcu-
late the location. This means that the navigation model does not need to be trans-
mitted to the handset.
It is worth noting that the protocols normally identify each satellite with a satel-
lite ID, which is in the range of 0–63. To convert the satellite ID to a PRN, 1 is added
to it for GPS.
Most of the assistance data types are restricted to send 16 satellites for the
per-satellite information. This is because they are intended to contain the assistance
data for the satellites in view of the approximate location. The approximate loca-
tion will normally come from the location of the cell and includes the area that the
cell covers. There is an assistance data type described next called real-time integrity,
which is a list of satellites that have an integrity problem as detected by the GRS.
When the LS determines the satellites in view, it will generally remove all of the sat-
ellites that are on the real-time integrity list.
The assistance data types are discussed with reference to the RLRP and the
PCAP specifications. It may be useful to have them available when you are looking
at this section.
4.7.1 Reference Time

This data type allows the server to provide the GPS time and subframe header infor-
mation to the handset. The handset can then use that as the approximate time and
synchronize its clock. It can use the per-satellite subframe header information to
identify the start of the subframe in the broadcast message bit string. This assistance
data type applies to both handset-based and handset-assisted A-GPS since a handset
running in either mode benefits from this.
For any cold-start location calculation, the handset’s local clock is likely to have
drifted from true GPS time and this data type can be used by the handset to help this.
The reference time data type is subject to network delay so it may be that time
recovery is required for the position calculation. Time recovery is discussed in detail
in Chapter 7. There is another field known as reference time uncertainty that allows
the server to specify the predicted uncertainty of the time and this is outlined in
Section 4.6.1.1.
The common fields in the reference time assistance data type are shown in Table
4.1, which shows that the time is provided with some per-satellite information. The
per-satellite information is specific fields from the subframe header that will allow
the handset to reconstruct the bit string that it is expecting from that satellite. If the
handset knows when it expects the phase change for the next bit then it can use that
information to integrate over a longer period and detect weaker signals. The TOW
assist includes fields from the TLM and HOW words. Note that the TOW assist
field can hold the information for a maximum of 16 satellites (restricted by the pro-
Table 4.1 GPS Reference Time

Field Description
GPS week This is the GPS week.
GPS time of week The time of week in milliseconds.
GPS TOW assist This field contains the per-satellite information from the GPS
subframe header as described in the following fields.
GPS TOW assist
Satellite ID This is the satellite ID which is in the range of 0 to 63.
PRN = Satellite ID + 1.
TLM message This is the 14 bits of the TLM from the NAV message subframe
header that is currently being transmitted by the satellite. Note
that this is not the TLM word that contains the TLM message.
Antispoof This is the antispoof flag from the HOW of the subframe header.
Alert This is the alert flag from the HOW of the subframe header.
TLM reserved This is the 2 reserved bits from the TLM reserved.
tocols). For this reason, the server normally provides the information for the satel-
lites that are in view from the approximate location.
The reference time data type also contains optional fields that describe the rela-
tionship between the cellular network time and the GPS time. In RRLP, there are
fields that describe the state of the GSM frame number, the timeslot number, and
the bit number of the reference BTS. In PCAP there are fields that describe the
UTRAN GPS time relationship. For further information, see the individual protocol
specifications.
When the LS receives a request for the GPS reference time, it extracts the GPS
TOW assist information from the data that it has cached from the GRS. It then gen-
erates the GPS week and the GPS time of week. Since the LS is synchronized to UTC
time (as a result of its connection to the NTP server), an LS written in Java would
make a call to the Java System class to determine the current time by invoking Sys-
tem.currentTimeMillis(). This system call returns the UTC time in milliseconds.
This is the current time on the LS; however, there will normally be some delay
between when the LS determines a time and the handset receives and decodes the
reference time data type. The most significant part of the delay is the network delay.
The LS will normally apply an offset to the time that is an estimate of the latency
between itself and the handset.
The LS then uses the GPS UTC model to convert the time from UTC to GPS
time. This results in the GPS week and the GPS time of week in milliseconds. The
Java code to calculate the offset between UTC and GPS time was shown and dis-
cussed in Chapter 3. Once the time is calculated, it is encoded in the format specific
to the protocol being used.
4.7.1.1 Reference Time Uncertainty

This data type allows the server to give an indication to the handset about how
accurate the supplied time is. This field contains the uncertainty expressed in micro-
seconds and can be in the range from 0 to 3 seconds. When the network is subject to
variably latency, the uncertainty will be a large number.
4.7.2 Reference Location

The reference location data type is applicable to handset-based A-GPS. It provides
the handset with its approximate location. That location is normally determined by
the LS by looking up the cell table given the cell ID information. The handset uses
the reference location in order to determine its own acquisition information. This is
the limits of the search that it needs to perform on each satellite in the time and fre-
quency domains in order to lock onto the satellite.
The reference location is provided by the LS as a shape in a form described by
the Geographic Area Description (GAD) specification [21]. The GAD specification
defines many different shapes that the LS can provide. If the initial location comes
from the definition of a cell, then the most appropriate shape type to describe that is
the ellipsoid arc. This is because a cell is normally described in the database with a
latitude, longitude, orientation, and opening angle.
The handset uses the reference location and uncertainty in order to determine
the size of the time- and frequency-domain search. A more suitable shape from
which to determine the search space is an ellipse. For this reason, the LS will nor-
mally supply the reference location as an ellipsoid point with an altitude and an
uncertainty ellipsoid. To convert the arc to an ellipse, the LS will normally draw an
ellipse that encapsulates the entire arc.
4.7.3 Navigation Model

This field contains the per-satellite navigation model. The navigation model con-
tains some control bits, satellite clock corrections, and the ephemeris for up to 16
satellites. The LS selects the satellites to include in this field based on the approxi-
mate location of the handset. From the approximate location of the handset, the LS
determines the satellites that are in view from anywhere within that uncertainty
area. It then pieces together the assistance data for those satellites and encodes it
into the format specific to the protocol being used. This assistance data type is only
applicable to handset-based A-GPS. The fields are shown in Table 4.2 and are
defined in the GPS IS [22].
4.7.4 Ionosphere Model

The ionosphere model contains the fields that allow a single frequency user to cor-
rect for some of the error introduced by the propagation of the radio signals through
the ionosphere. This was discussed in detail in Chapter 3.
The fields in the ionosphere model GPS assistance data type are shown in Table
4.3. This data is considered to be global in nature because it is not specific to any
particular satellites. The LS simply uses the data that it has cached from the GRS
and encodes it into the format specific to the protocol being used. Instead of encod-
ing this data type on a per-request basis, the LS will generally encode it as a changed
version is received from the GRS. That way, it does not need to be encoded for every
request, but is just copied to the appropriate place in the bit buffer for the message
being composed by the LS. This data type is only applicable to handset-based
A-GPS, which uses it for part of the position calculation and may also use it to
calculate acquisition data.
Table 4.2 GPS Navigation Model

Field Description
Satellite ID This is the satellite ID that is in the range of 0 to 63.
Satellite status This is an indicator of whether this is a new or existing satellite
and whether the navigation model is new or the same.
C/A or P on L2 Code(s) on L2 channel
URA Index User range accuracy
SV Health Satellite health
IODC Issue of data, clock
L2 P Data Flag
SF 1 Reserved
TGD Estimated group delay differential
toc Apparent clock correction
af2 Apparent clock correction
Crs Amplitude of the sine harmonic correction term to the orbit
radius (meters)
Δn Mean motion difference from computed value (semicircles/sec)
M0 Mean anomaly at reference time (semicircles)
Cuc Amplitude of the cosine harmonic correction term to the argu-
ment of latitude (radians)
e Eccentricity
Cus Amplitude of the sine harmonic correction term to the argu-
ment of latitude (radians)
1/2 1/2
(A) Semimajor axis (meters)
toe Reference time ephemeris
Fit Interval Flag
AODO Age of data offset
Cic Amplitude of the cosine harmonic correction term to the angle
of inclination (radians)
OMEGA0 Longitude of ascending node of orbit plane at weekly epoch
(semicircles)
Cis Amplitude of the sine harmonic correction term to the angle of
inclination (radians)
i0 Inclination angle at reference time (semicircles)
Crc Amplitude of the cosine harmonic correction term to the orbit
radius (meters)
ω Argument of perigee (semicircles)
OMEGAdot Rate of right ascension (semicircles/sec)
Idot Rate of inclination angle (semicircles/sec)
4.7.5 UTC Model

The UTC model contains the fields that allow the handset to determine the time dif-
ference between the UTC time scale and the GPS time scale (Table 4.4). Similarly to
the ionosphere model, it is a global data type and would be pre-encoded instead of
Table 4.3 GPS Ionosphere Model

Field Description
α0 Coefficient 0 of vertical delay
β0 Coefficient 0 of period of the model
Table 4.4 GPS UTC Model

Field Description
A1 Drift coefficient of GPS time scale
relative to UTC time scale
A0 Bias coefficient of GPS time scale rel-
ative to UTC time scale
tot Time data reference time of week
ΔtLS Current or past leap second count
WNt Time data reference week number
WNLSF Leap second reference week number
DN Leap second reference day number
ΔtLSF Current of future leap second count
being encoded for each request. The application of the UTC model was discussed in
Chapter 3.
4.7.6 Acquisition Assistance

GPS acquisition assistance is the primary data type used for handset-assisted
A-GPS. It contains the parameters that allow the handset to constrain its satellite
search in both the time and frequency domain. This means that the handset does not
need to perform its own acquisition calculations. Compared to stand-alone GPS, it
means that the handset can lock onto signals much faster and can also lock onto
weaker signals.
A conventional GPS receiver searches discrete frequency/time-domain incre-
ments known as bins. Acquisition assistance data for A-GPS narrows the search
space by specifying for which satellites to look and where to look in frequency
(Doppler) and time (code phase). This is defined by a search position and a window.
Figure 4.7(a) shows the full three-dimensional search space that a stand-alone
GPS receiver has to perform. The receiver needs to search across multiple satellites
and for each satellite needs to search in the time domain (code phase) and the fre-
quency domain (Doppler) until it can get a match. Note that a receiver will generally
search for the satellites in parallel, but it may only be able to search for a limited
number in parallel at one time.
Reduced
Bin search space
Doppler −5 kHz to 5 kHz

kHz
to 5
Satellite ID
kHz
−5
ler
pp
Do
Code phase 0 to 1,023 chips Code phase 0 to 1,023 chips
(a) (b)
Figure 4.7 (a, b) GPS search space and search space reduced by acquisition.
The code phase is the offset between the measured C/A code and the replica gen-
erated by the handset, which is between 0 and 1,023 chips. The Doppler is the
received frequency that has been shifted from the transmitted frequency. The size of
the frequency shift depends on whether the satellite is approaching or receding from
the handset and also on the rate of the relative motion and the local oscillator offset.
The Doppler will be within 5 kHz on either side of the transmitted frequency, not
counting the user motion and the handset oscillator offset. The Doppler will gener-
ally be zero when the satellite is at the zenith and will be at its maximum when the
satellite is on the horizon, which is traveling at its maximum radial velocity.
The GPS acquisition assistance data type narrows the search down to the
two-dimensional search space shown in Figure 4.7(b). The GPS acquisition assis-
tance contains the estimated code phase and Doppler for each satellite as well as the
size of the search required for each side of the estimated values. The size of the
search window is a function of the uncertainty of the estimated location. If the esti-
mated location has a very small uncertainty, then the search windows will be small,
but if it has a large uncertainty, the search area will be large.
Note that since the receiver’s clock is not perfectly synchronized with GPS, the
code phase and Doppler shift search windows are not absolute. This means that a
broad search is attempted for each of the satellites for which assistance data is pro-
vided, and once the first satellite is found, the remaining satellites use the search
windows from the acquisition assistance relative to that of the first satellite
measured.
The GPS acquisition assistance is calculated by the LS using the assistance data
from the GRN and the handset’s estimated location and uncertainty. The GPS
acquisition assistance information consists of the time at which the data was calcu-
lated and the per-satellite information. The per-satellite information is shown in
Table 4.5.
In order to calculate the expected Doppler shift, an estimate of the difference
between the satellite and the user motion is determined. Since the motion of the
handset is unknown, the LS assumes that it is at rest and the velocity is set to zero.
Table 4.5 GPS Acquisition Assistance

Field Description
Satellite ID This is the satellite ID, which is in the range of 0 to 63.
Doppler (0th order term) This field contains the expected Doppler value in hertz. A
positive value indicates an increase in the satellite signal
frequency due to the velocity of the satellite towards the
handset.
Doppler (first-order term) This field contains the Doppler first-order term in hertz
per second. It is the rate of change of the Doppler.
Doppler uncertainty This is the uncertainty of the predicted Doppler value.
The true value is expected to be between Doppler – Dopp-
ler Uncertainty and Doppler + Doppler Uncertainty.
Code phase This is the predicted code phase in units of chips. It is the
expected size of the C/A offset between the replica and the
transmitted C/A code.
Integer code phase This is the number of code periods that have elapsed since
the latest GPS bit boundary.
GPS bit number This contains the latest bit number transmitted.
Code phase search window This is the uncertainty of the predicted code phase valued.
The true value is expected to be between Code Phase –
Code Phase Search Window and Code Phase + Code
Phase Search Window.
Azimuth This field contains the azimuth of the satellite.
Elevation This field contains the elevation of the satellite.
The Doppler shift in hertz is calculated from the dot product of the difference in
the velocities and the estimated line of sight vector as shown in (4.5) [23]:
⎛ v − vr $ ⎞
D = −⎜ s ⋅ls⎟f (4.5)
⎝ c ⎠
where vs is the velocity of the satellite, vr is the velocity of the receiver, c is the speed
of light, l$s is the estimated line of sight unit vector, and f is the transmitted frequency
(1,575.42 MHz for GPS L1).
The line-of-sight vector is calculated as the difference between the satellite and
receiver location divided by the norm of the difference as shown in
r − r$r
l$s = s (4.6)
rs − r$r
where rs is the location of the satellite in WGS 84 ECEF coordinates and rr is the esti-
mated location of the receiver.
Xu [24] introduced a correction to the frequency to account for the clock error
of the satellite and the receiver. The satellite clock error introduces a phase error as
shown in
c * satelliteClockError
phaseError = (4.7)
λ
where λ is the wavelength transmitted by the satellite. This satellite phase error is
equivalent to the frequency error given by
satFrequencyError = f * satelliteClockError (4.8)
To compensate for the frequency error, the frequency used in (4.5) is manipu-
lated as shown in
usedFrequency = f − ( f * satelliteClockError ) (4.9)
where f is the transmitted frequency (1,575.42 MHz for GPS L1) and
usedFrequency is used as input to (4.5). In practice this is only a small correction
because the satellite clock error is in the range of 1E-05 to 1E-08 milliseconds, or in
percentage terms, the frequency is adjusted by less than 1%.
Since we are working in the ECEF coordinate frame, which rotates with the
Earth, the receiver velocity vr is set to zero. The velocity of the satellite is calculated
using the formulas in Bate [25]. An alternative is to calculate the location of the sat-
ellites 1 second apart and determine the distance vectors or differentiate the equa-
tion of the satellite position in the GPS IS.
As shown previously in Table 4.5, the LS provides the Doppler shift and the
Doppler search window size in the GPS acquisition assistance data type for each sat-
ellite that is in view of the estimated location.
For each satellite, the limits of the Doppler search can be found by calculating
the Doppler shift at the boundary of the initial uncertainty area that is closest to the
satellite and at the boundary of the initial uncertainty area that is farthest from the
satellite. Figure 4.8 shows a two-dimensional view of the relationship between the
initial uncertainty area and one satellite for two different uncertainty shapes. In Fig-
ure 4.8(a) the initial uncertainty area is a circle. The Doppler is calculated at the
point on the circle closest to the satellite and at the point on the circle that is farthest
from the satellite. In Figure 4.8(b) the initial uncertainty area is an ellipse. The
points to calculate the Doppler at are the ones that intersect the tangent to the ellipse
at a right angle.
Normally, the initial location will have an altitude and an altitude uncertainty
associated with it, so the LS actually needs to calculate the point on the surface of
the volume of uncertainty that is nearest the satellite and the point on the surface of
the volume that is farthest from the satellite. Once the LS has determined the Dopp-
ler values at the two points, it uses that to set the values in the GPS acquisition
assistance.
The following steps are used by the LS to calculate the Doppler fields:
1. Calculate the satellites in view from the center of the initial uncertainty area
and for each satellite perform the following steps.
2. Calculate the Doppler shift at the point on the perimeter of the uncertainty
area that is closest to the satellite.
3. Calculate the Doppler shift at the point on the perimeter of the uncertainty
area that is farthest from the satellite.
Maximum range
Minimum range
A-GPS handset
(a)
Maximum range
Minimum range
A-GPS handset
(b)
Figure 4.8 (a, b) Model for determining search windows.
4. The Doppler is the average of the Doppler at the two locations and the
Doppler uncertainty is half of the difference between the Doppler
calculated at the two locations.
One way to calculate the Doppler first-order term is to calculate the Doppler at
a point in time a few seconds ahead of the current time and then, using the original
calculation, convert that to the rate of change in hertz per second. This is shown in
Dt 2 − Dt 1
doppler1st = (4.10)
t 2 − t1
where Dt 1 is the Doppler calculated at time t1 and Dt 2 is the Doppler calculated at

time t2.
The LS calculates the expected code phase field from the estimated range to the
satellite. The range is calculated as the difference between the estimated location
and the WGS 84 ECEF coordinates of the satellite at the given time. Note that simi-
lar to the Doppler window calculation, the code phase is calculated at the point on
the uncertainty volume nearest the satellite and then at the point on the uncertainty
volume farthest from the satellite.
The code phase is the chip number within the C/A code and is in the range of 0
to 1,023 chips. It is calculated using
r%rCA
codePhase = 1023
, (4.11)
rCA
where r is the range or the estimated distance between the initial location and the
satellite and rCA is the resolution of the 1,023-bit C/A code in meters and the % indi-
cates the mod function. rCA is given by
CACodeLength
rCA = c = 299,792.458 (4.12)
GPSChippingRate
where the C/A code length in bits is 1,023, the GPS chipping rate is 1.023 MHz, and
c is the speed of light.
The procedure to calculate the code phase and the search window for the code
phase component of the GPS acquisition assistance is similar to the Doppler. That
is, the code phase is calculated at the points on the surface of the initial uncertainty
volume that are the nearest and farthest from the satellite. The code phase is the
average of the code phase at the two locations and the code phase search window is
half of the difference between the code phases calculated at the two locations.
4.7.7 Real-Time Integrity

The real-time integrity data type is simply a list of satellites that the handset should
not use. It is a mechanism in which the LS can provide information to the handset
about satellites that have an integrity problem. This information comes from the
GRS, which has an integrity monitoring function. The LS will not normally supply
assistance data for satellites that are in the bad satellite list; however, providing this
assistance data type to the handset ensures that it is not using cached data to lock
onto and use the bad satellites.
4.7.8 Almanac
The almanac is a coarse, long-term model of the satellite positions and clocks. It is a
per-satellite assistance data type. The key difference between this and the other
per-satellite data types is that it is provided for the entire constellation of satellites.
Almanac is not normally requested by A-GPS enabled handsets.
4.7.9 DGPS Corrections

It is possible to provide differential-GPS corrections over the major A-GPS proto-
cols. In order to provide differential corrections, the receivers that are part of the
GRS need to be geographically dense. Differential corrections are normally used for
high precision applications and there is presently little demand for them over
A-GPS.
4.8 Assistance Data Type Sizes
Table 4.6 is reproduced from Table 1.1 and has the size of the different assistance
data types in bits tacked on as an additional column. The sizes indicate the number
of bits to store the data types as binary based on the sizes of the fields. The per-satel-
lite satellites-in-view data types are assumed to have 10 satellites in view and the
almanac size is based on 30 satellites. The reference time parameter has optional
fields describing the relationship between GPS time and the cellular time, and they
are omitted. The size of the real-time integrity data type is for three bad satellites.
The reference location is encoded as an ellipsoid point with altitude and an uncer-
tainty ellipsoid using the encoding specified in the GAD spec.
Note that when the data is encoded in the protocol particular to the RAN, the
size will be larger depending on the formatting in that protocol such as encoding of
Table 4.6 GPS Assistance Data Types

Assistance Handset- Handset- Size
Data Type Description Global Assisted Based in Bits
Reference time This data type allows the server to provide time to N Y Y 273
the handset. The handset can then use that as the
approximate time. This data type may also contain
the relationship between the cellular network time
and the GPS time. In some protocols, the GPS
subframe header information is also provided for
satellites in view.
Reference location This field contains the approximate location of the Y N Y 112
handset and uncertainty of the location to the
handset in order for it to constrain its search space.
In a cellular network, this will be the location of
the cell and the uncertainty will be the boundary of
the cell coverage area.
Navigation model This field contains the per-satellite navigation N N Y 5524
model.
Ionosphere model The ionosphere model contains the fields that Y N Y 64
model the delays in the propagation of the radio
signals through the ionosphere.
UTC model The UTC model contains a set of fields that allow Y N Y 104
the user to determine the relationship between
UTC time and GPS time.
Acquisition This data type provides the uncertainty search N Y N 587
assistance windows for the satellites in view. It provides the
search windows in the time and frequency domain,
information about the current nav bit, and the
azimuth and elevation of the satellites.
Real-time integrity This data type contains a list of satellites that are Y N Y 18
presently considered bad and should not be used
by the handset.
Almanac The almanac is the coarse long-term model of the Y N N 5,654
satellite position and clocks.
DGPS This data type allows the server to provide per- N N N 627
satellite differential corrections based on the
initial uncertainty.
fields, segmentation of messages over a certain size, or octet alignment. The proto-
cols are discussed in more detail in Chapter 5.
The almanac and navigation model assistance data types are by far the largest
data types that need to be transmitted. The larger the messages, the longer it takes
for the message to be sent over the radio interface and be decoded by the handset. In
addition, longer messages result in segmentation requirements that introduce addi-
tional overhead to the handset because it needs to reassemble the messages before it
can decode the assistance data.
The total number of bits required for a handset-assisted location is 860 (or 108
bytes). This is for the reference time and acquisition assistance.
The total number of bits required for a handset-based location is 15,095 (or
1,887 bytes). This is for reference time, reference location, navigation model, iono-
sphere model, UTC model, and real-time integrity.
The amount of data transmitted for handset-based A-GPS is more than 17 times
more than for that of handset-assisted A-GPS.
References
[1] Parkinson, B., et al., (eds.), Global Positioning System: Theory and Applications, Vol. 1,
Washington, D.C.: American Institute of Aeronautics and Astronautics, Inc., 1996.
[2] Kaplan, E. D., and C. J. Hegarty, (eds.), Understanding GPS: Principles and Applications,
2nd ed., Norwood, MA: Artech House, 2006.
GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (MS)—Serv-
ing Mobile Location Center (SMLC) Radio Resource LCS Protocol (RRLP), 2009.
Radio Access Network; UTRAN Iupc Interface Positioning Calculation Application Part
(PCAP) Signaling, 2007.
[6] Mills, D. L., Network Time Protocol Version 4 Reference and Implementation Guide, NTP
Working Group, Technical Report 06-6-1, University of Delaware, June 2006.
[7] Mobile Location Protocol, Open Mobile Alliance, LIF-TS-101 Specification, 2009.
[8] NENA Standard for the Implementation of the Wireless Emergency Service Protocol E2
Interface, 2003.
[9] Gurtner, W., RINEX: The Receiver Independent Exchange Format, Version 2.10, Astro-
nomical Institute, University of Berne, June 8, 2001.
[10] Spilker, J. J., “GPS Signal Structure and Theoretical Performance,” in Global Positioning
System: Theory and Applications, Vol. I, B. Parkinson et al., (eds.), Washington D.C.:
American Institute of Aeronautics and Astronautics, Inc., 1996, pp. 84–86.
[11] van Diggelen, F., A-GPS: Assisted GPS, GNSS, and SBAS, Norwood, MA: Artech House,
2009.
[12] GRIP, Open Source GNSS Reference Server GNSS Reference Interface Protocol (GRIP)
Interface Document, 2008, http://sourceforge.net/projects/osgrs.
[13] Yan, T., et al., “Open Source GNSS Reference Server,” 20th Int. Tech. Meeting of the Satel-
lite Division of the U.S. Inst. of Navigation, Fort Worth, TX, September 25–28, 2007, pp.
2224–2229.
vices and System Aspects; Functional Stage 2 Description of Location Services (LCS), 2009.
[16] Dawson, M., J. Winterbottom, and M. Thomson, IP Location, New York: McGraw-Hill
Osborne Media, 2006.
[17] 3GPP2 C.S0022, Position Determination Service Standard for Dual Mode Spread Spectrum
Systems, 2004.
[18] UserPlane Location Protocol, Open Mobile Alliance, OMA-TS-ULP, 2009.
[19] TIA/EIA/IS-TIA/EIA/J-STD-036-A-A—Enhanced Wireless 9-1-1 Phase 2, March 2002.
[20] Bullock, J., et al, “Integration of GPS with Other Sensors and Network Assistance,” in
Understanding GPS: Principles and Applications, 2nd ed., E. D. Kaplan and C. J. Hegarty,
(eds.), Norwood, MA: Artech House, 2006.
CA, 2004.
[23] Axelrad, P., and R. G. Brown, “GPS Navigation Algorithms” in Global Positioning System:
Theory and Applications, Vol. I, B. Parkinson et al., (eds.), Washington, D.C.: American
Institute of Aeronautics and Astronautics, Inc., 1996.
[24] Xu, G., GPS Theory, Algorithms, and Applications, New York: Springer, 2003.
[25] Bate, R., D. Mueller, and J. E. White, Fundamentals of Astrodynamics, New York: Dover
Publications, 1971.
CHAPTER 5
Assisted-GPS Location Within a Network

An Assisted-GPS server is part of a location server (LS) and its purpose is to provide
assistance data to an A-GPS or an A-GNSS-capable handset in order to improve the
TTFF and the yield compared to stand-alone GPS. The LS will normally use a stan-
dards-based protocol to deliver the assistance data to the handset and receive the
measurements or location, or it may use its own particular protocol (proprietary
protocol). A proprietary protocol will generally only work on very specific handsets
or handsets with a certain software package installed. This is in contrast to a stan-
dards-based protocol, which is normally widely available on handsets.
This chapter discusses the standards-based architectures and protocols used for
A-GPS in a network. It discusses how the LS fits into the location services architec-
tures and the specific protocols used for A-GPS such as RRLP [1], PCAP [2], RRC
[3], and TIA-801 [4]. The RRLP protocol is discussed in detail with an explanation
of ASN.1 and PER encoding, as well as message examples and the Java code for
encoding and decoding RRLP messages.
5.1 Location Architectures
As mentioned earlier, there are proprietary protocols for A-GPS which may have
application in specific closed networks. This book, however, explores the stan-
dards-based protocols that are widely used and facilitate A-GPS location of
handsets.
In this book, we consider the major cellular architectures for the GSM/Edge
Radio Access Network (GERAN), UMTS Terrestrial Radio Access Network
(UTRAN), and ANSI-41 networks, as well as the SUPL location platform (SLP) and
the location information server (LIS). The emergency services architectures for
GERAN, UMTS, and ANSI-41 are also introduced.
The location services (LCS) description [5] outlines the architecture for GERAN
and UTRAN LCS. The CDMA LCS document describes the architecture for CDMA
[6].
A mobile location center (MLC) is a node that runs in various networks and can
act as a gateway mobile location center (GMLC) [5], a serving mobile location cen-
ter (SMLC) [7], a stand-alone SMLC (SAS) [8], an SLP [9], a mobile positioning cen-
ter (MPC) [6], or a location information server (LIS) [10].
The emergency architecture for NAES LCS is described in J-STD-026 [11]. The
GMLC and MPC are required to implement the E2 interface [12]. The E2 defines
the interface for the Emergency Services Messaging Entity (ESME) to request the
location of an emergency caller. It is a binary request response protocol. The ESME
91
92 Assisted-GPS Location Within a Network
connects to the MLC and makes requests and receives responses over the binary
emergency services protocol.
The Canadian Wireless E9-1-1 requirements have recently been released [13].
The Automatic Location Identification (ALI) connects to the GMLC over the Le
interface using the MLP protocol (discussed in Chapter 4). The ALI makes request
using the MLP emergency messages and receives responses with a location as a
CircularArea. The Canadian requirements place some other minor requirements in
addition to those already defined by MLP, such as application level heart beating
and location specified at 90% confidence.
At the A-GPS (or A-GNSS) level, each protocol transports the same basic infor-
mation, but has different encodings, procedures, and naming.
5.2 A-GPS Protocols and Messaging
This section contains the details of some of the standards-based A-GPS protocols
and the messaging between the LS and the handset. I have chosen to discuss RRLP
in the greatest level of detail, simply because it is used for both GERAN and com-
monly for the SLP. The RRLP messages and field contents are discussed in detail
along with the encoding rules and binary encoding. In addition, the Java code for
RRLP messaging is discussed in detail. PCAP is discussed in conjunction with RRC
at a relatively high level: the message level. TIA-801 is another protocol for deliver-
ing A-GPS information, but it is only discussed briefly.
Most of the standards-based protocols were initially developed for single-fre-
quency code-phase GPS L1 handsets. Recently, more signals have been added to
GPS and other GNSSs have been replenished and proposed. In order to be back-
wardly compatible with existing handset implementations, a new classification of
assistance data and measurements was added to the protocols as a separate infor-
mation element. This new classification is known as Galileo and Additional Naviga-
tion Satellite Systems (GANSS). It is used to define assistance data and
measurements for the other GNSSs and SBASs as well as modernized GPS (for
example, L2 and L5).
5.3 RRLP
The Radio Resource Location Protocol (RRLP) [1] is used to provide a handset with
assistance data in order for the SMLC to receive either the location of the handset
for handset-based A-GPS, or the GPS measurement for handset-assisted A-GPS.
RRLP also supports other GNSSs and modernized GPS by defining data types
within a GANSS information element (IE). In addition to GPS, RRLP can also be
used for enhanced observed time difference (EOTD) messaging, which is not dis-
cussed in this book.
RRLP is used as the protocol between the stand-alone mobile location center
(SMLC) and the mobile station (MS) in a GERAN network. It is also used on both
the Lup and Llp interfaces in secure user plane location (SUPL)–enabled networks.
In the case of a SUPL location platform (SLP), the RRLP is in the positioning pay-
5.3 RRLP 93
load IE for the UserPlane Location Protocol (ULP) on the Lup interface. It is used in
the positioning payload IE for the Internal Location Protocol (ILP) on the Llp inter-
face between the remote SUPL location center (SLC) and the SUPL positioning cen-
ter (SPC). The only required protocol for the positioning payload for A-GPS for
GSM and WCDMA for SUPL is RRLP. RRC [3] and TIA-801 [4] may also
optionally be used for A-GPS.
When used over control plane (between the SMLC and the MS), the amount of
data in an RRLP message is subject to a maximum of 242 octets (an octet is 8 bits).
If the data is larger than that, RRLP pseudosegmentation is used. It is possible that
legacy MSs may send data larger than that; in which case, lower level segmentation
is used [14]. Note that when the data is in the positioning payload for SUPL, there is
no such limit.
In RRLP, messages are known as components and fields in the message are
known as information elements (IEs).
5.3.1 RRLP Procedures

RRLP contains several different procedures:
• Position measurement procedure;

• Assistance data delivery procedure;
• Position capability transfer procedure.
The position measurement procedure allows the SMLC to request the location
or location measurement data from the MS and may be preceded by an assistance
data delivery or position capability transfer. The measure position request is sent
from the SMLC to the MS and contains session information, some control fields,
and possibly assistance data. The position measurement procedure is shown in Fig-
ure 5.1. Note that there are other network nodes that the message goes through
before getting to the MS but these are not shown for simplicity.
The measure position request may be sent as a single message or may be seg-
mented if there are more than 242 octets of data. The RRLP message contains a flag
that indicates whether there are more components of this message still to come, and
the MS uses that to determine whether to decode the data or wait for the rest of the
message.
When the MS receives a request for a location (the measure position request
message), it determines whether it has enough information to process the request. If
SMLC MS
Measure Position Request
Measure Position Response
Figure 5.1 Position measurement procedure.

it does, then it uses the information that it has to lock onto the satellites and return
either a location or the measurements for the server to calculate the location.
In the case where the MS does not have enough assistance data, it returns a mea-
sure position response to the SMLC with a location information error element indi-
cating that it needs more assistance data and a list of the assistance data types
required. It may also provide the details of the ephemeris that it already has cached
so that the SMLC does not send the ephemeris for those satellites again. The SMLC
then sends another measure position request to the MS with the assistance data that
the MS has requested.
The position measurement procedure is a very efficient way of getting assistance
data to a handset since the MS only requests the assistance data types that it needs
from the SMLC; however, there is a trade-off due to the back-and-forth
communication.
The assistance data delivery procedure is an alternate way to get the assistance
data to the MS and may precede the position measurement procedure. It is a mecha-
nism for the SMLC to provide assistance data directly to the MS without it being
requested within RRLP. The assistance data message is sent by the SMLC to the MS
and contains assistance data that can be used for making measurements and poten-
tially for calculating the location of a handset. The MS sends an acknowledgment
back to the SMLC on receipt of each assistance data message.
The assistance data delivery procedure is generally used when the server knows
which assistance data types that a handset will need in advance. One example is that
if the SMLC knows that a handset will always need certain data types, for example,
reference time and reference location, then those data types can be sent in the assis-
tance data message. Alternatively, there could be situations where the SMLC needs
to minimize the number of messages that are sent to the MS. For example, the oper-
ator of the SMLC may find that emergency calls are mostly made from a cold-start
situation. In this case, they may configure their SMLC to use the assistance data
delivery procedure to send a complete set of assistance data and hence prevent any
unnecessary additional messaging such as multiple measure position request
messages.
The other procedure available in RRLP is the positioning capability transfer
procedure. This procedure is used by the SMLC to request the capability of the MS
and the assistance data types that it supports. The MS returns the information to the
SMLC in a position capability response message. The SMLC can use this to deter-
mine whether the MS supports A-GPS and which modes of A-GPS it supports
(MS-based or MS-assisted).
Each procedure includes an error handling component. If there is a problem in
the message that the MS receives, it replies with a protocol error message. The pro-
tocol error message contains information that indicates the problem.
5.3.2 RRLP Messages

The RRLP specification [1] is divided into several sections that describe the proce-
dures, the message structure, the individual components, and the elements of the
components. There is also an extensive informative annex that describes the mes-
sages and fields in order to provide the detail of each field. In this section, the mes-
5.3 RRLP 95
sages are introduced along with the information in some of the important fields.
The encoding and decoding of the messages are described in the next section along
with code.
The important information elements (IEs) from the measure position request
message are described in Table 5.1. There are other fields that are not present in the
table but are available in the RRLP specification. The measure position request is
sent to the MS to initiate a location calculation or to request that it provides mea-
surements back to the SMLC. It contains the positioning instructions and may
include assistance data for GPS and/or GANSS.
The measure position response message is sent by the MS to the SMLC in
response to a measure position request and it contains the results of the location
attempt. It may contain a location, an error, or a request for additional assistance
data. Table 5.2 shows the important fields from the measure position response mes-
sage. The measure position response must contain one of the IEs containing mea-
surement data or location information.
If the measure position response contains an error, then the SMLC may send
another measure position request with additional assistance data.
The assistance data message includes assistance data for calculating the location
of the MS or for returning the measurements to the SMLC. The important fields are
shown in Table 5.3. It is initiated on the SMLC and sent to the MS. It is subject to
the RRLP pseudosegmentation and the more assistance data to be sent IE will be set
to true if this is not the last segment of this message. The MS responds to each assis-
tance data message with an assistance data acknowledgment message. The assis-
tance data component contains no information but serves to indicate to the SMLC
that the segment has been received.
The positioning capability request can be sent from the SMLC to the MS to
request the capability of the handset, the assistance data types supported, and any
assistance data types that are required. The MS responds with a positioning capabil-
ity response that details each GANSS that it supports and each assistance data type.
It may also optionally indicate the assistance data that it requires to perform a
location.
The protocol error message is sent from the MS to the SMLC to indicate that
there is a problem with the request that it just sent. The protocol error message con-
tains an error code that indicates the problem to the SMLC.
5.3.3 RRLP Encoding and ASN.1 Packed Encoding Rules

The RRLP specification [1] defines how the messages are encoded for transmission
on a communications link. The message structure section describes the encoding
and general format of the message, the components are also described, and the ele-
ments of the components are shown in detail. The RRLP messages are described
using ASN.1 notation. The ASN.1 notation is described in [19]. The notation allows
the protocol to be described without concern for the binary representation of the
messages. ASN.1 is used extensively in the specification to describe all of the mes-
sages, components, and elements that make up the messages. In order to represent
the data in binary form for transmission, RRLP uses ASN.1 Packed Encoding Rules
(PER) [20]. It uses the BASIC-PER UNALIGNED variant.
Table 5.1 Important Fields from the Measure Position Request

Information Element Description
Positioning This field specifies the type of positioning to perform. It can be either MS-assisted,
instructions MS-based, MS-based preferred but MS-assisted allowed, or MS-assisted preferred but
MS-based allowed. MS-based positioning includes calculating the final location on the
handset where MS-assisted involves calculating the location on the server. The posi-
tioning instructions element also contains the requested accuracy, the response time,
whether the MS is requested to send multiple sets, and the environment
characterization.
GPS assistance The GPS assistance data types were described in Chapter 4. The following assistance
data data types are supported for RRLP: reference time, reference location, DGPS correc-
tions, navigation model, ionospheric model, UTC model, almanac, acquisition assis-
tance, and real-time integrity. Note that real-time integrity is always sent if this IE is
included.
Additional GPS This field contains the extended ephemeris. They are fields that extend the ephemeris
assistance data so that it can be used longer. The server calculates them based on the orbit model of
the satellites and the ephemeris information. It is essentially a set of correction terms
that can be applied to the ephemeris. The extended ephemeris may be useful to save
bandwidth or to enable an accurate location when the MS does not have access to the
network.
GPS reference This field contains the uncertainty of the reference time data type.
time uncertainty
GANSS carrier-phase If this component is present, the MS is requested to return carrier-phase measurements
measurement request in the GANSS measurement information IE.
GANSS common The GANSS common assistance data contains IEs that can be used with any GNSS
assistance data constellation. It is present once in each request (at most). It contains the following
fields: GANSS reference time, GANSS reference location, GANSS ionospheric model,
GANSS additional ionospheric model, and GANSS Earth orientation parameters. The
reference time and location parameters specify the reference time and the reference
location associated with the request. The GANSS ionospheric model is the one defined
in the Galileo ICD [15]. The GANSS additional atmospheric model is defined in the
QZSS IS [16]. The GANSS Earth orientation parameters define the ECI and ECEF
coordinate transformation as defined in the GPS IS 200 [17].
GANSS generic The GANSS generic assistance data is included once for each GNSS for which infor-
assistance data mation is included. It contains IEs that are specific to one GNSS at a time as defined
by the GANSS ID.
GANSS ID The identifier of the GNSS or an indication that this data is for an
SBAS. The possible identifiers are: SBAS, modernized GPS, QZSS, and
GLONASS. Note that this is an optional field and, if it is missing, then
the GNSS is Galileo. Note that if this indicates SBAS, then the SBAS ID
is included.
GANSS This is a model to relate the GNSS time to the time of another GNSS.
time model This can be sent for more than one GNSS. For example, if the SMLC
wants to provide the relationship between this GNSS to both GPS and
Galileo, then it will send two time models.
DGANSS This field specifies the differential corrections that the MS can use for
corrections this GNSS.
GANSS The GANSS navigation model consists of per-satellite information that

navigation can be used to calculate the location of the satellite. The navigation
model model includes some common fields and then fields that depend on the
satellite signal under consideration. For example, the interpretation of
the health bits depends on the GNSS or SBAS or even the frequency
within the GNSS. There are several clock models, and the clock model
can be present multiple times depending on whether the MS supports
multiple signals. The clock model can be either the standard clock
model, the NAV clock model, the CNAV-CNAV-2 clock model, the
5.3 RRLP 97
Table 5.1 (continued)

GANSS generic GANSS GLONASS satellite clock model, or the SBAS clock model. The parame-
assistance data navigation ters for the different GNSSs or signals are defined in the relevant inter-
(continued) model face specifications. The GANSS orbital model IE contains several
(continued) possible formats depending on the GNSS and the signal. The formats
are the satellite navigation model using Keplerian parameters, the satel-
lite navigation model using NAV Keplerian parameters, the satellite nav-
igation model using CNAV/CNAV-2 Keplerian parameters, the satellite
navigation model using GLONASS ECEF parameters, and the satellite
navigation model using SBAS ECEF parameters.
GANSS This field indicates the satellites and signals that have any problems and
real-time that the MS should not use.
integrity
GANSS This field contains the details of the data bits for specific signals for this
data bit GNSS so that the MS can perform data wipe-off. The data bits depend
assistance on the satellite and the signal on that satellite.
GANSS This is the acquisition assistance data type for the different GNSSs or
reference SBAS. It contains the code and frequency search windows in order for
measure- the receiver to narrow its search space.
ment
information
GANSS The almanac represents the coarse, long-term model of the satellite loca-
almanac tions and clock models. It consists of per-satellite information that is dif-
model ferent for each GNSS as defined by their interface specifications. The
formats of this data type are the GANSS almanac model using Keplerian
parameters, the GANSS almanac model using NAV Keplerian parame-
ters, the GANSS almanac model using reduced Keplerian parameters,
the GANSS almanac model using midi Keplerian parameters, the
GANSS almanac model using GLONASS Keplerian parameters, and the
GANSS almanac model using SBAS ECEF parameters.
GANSS The UTC model parameters relate the GANSS to UTC. The parameters
UTC are specific to the GANSS ID. That is, if the GANSS ID is QZSS, then
model the parameters are used to relate QZSS time to UTC.
GANSS This contains the extended ephemeris parameters for each satellite for
ephemeris the GANSS.
extension
GANSS This field contains information about the validity of the extended
ext check ephemeris that the MS holds. A satellite’s extended ephemeris can be
deemed invalid if an unforeseen event occurred with a satellite.
SBAS ID This field indicates the specific SBAS for which the GANSS assistance
data is supplied. This can be WAAS, EGNOS, MSAS, or GAGAN.
GANSS This field contains the UTC model specific to the GNSS as defined by
additional the GNSSs interface document. The fields of this data type can be the
UTC model GPS model, the GLONASS model, or the WAAS model.
GANSS This field contains information about signals and channels for the
auxiliary GANSS.
information
Required response This field indicates the maximum response time that the MS has available to perform
time the location. The MS shall return a measure position response before this time has
elapsed.
The ASN.1 provides a way of defining the elements of the messages that make
up the protocol. The ASN.1 allows the protocol to be described in terms of mes-
sages, components, and elements. Table 5.4 shows some of the primary constructs
Table 5.2 Important Fields from the Measure Position Response

Multiple sets This field contains the number of measurement sets returned from the MS to the
SMLC. If this field is absent, then one set of measurements is included in the response.
Location information This field provides the location estimate from the MS to the SMLC for MS-based
A-GPS. It contains the GPS TOW and whether the fix was a two-dimensional or a
three-dimensional fix. The location is provided as a shape as specified by the GAD
specification [18] in one of the following: ellipsoid point, ellipsoid point with uncer-
tainty circle, ellipsoid point with uncertainty ellipse, ellipsoid point with altitude, and
uncertainty ellipsoid.
GPS measurement This field includes the measurements of time, code phase, and Doppler. The SMLC
information uses the measurements for MS-assisted A-GPS to calculate the location. Note that the
MS only sends the 24 LSBs of the GPS TOW. The most significant bits are derived
from the SMLC’s system time (which is synched to NTP).
Location information This field provides an indication of the error and an error code. It may also indicate
error additional GPS or GANSS assistance data required to complete the location. When
requesting additional assistance data, the assistance data types required are specified
using the GPS assistance data and GANSS assistance data fields of the BSSAP-LE [14]
protocol. These data types allow the MS to specify which assistance data types are
required and also allow the MS to inform the SMLC of the ephemeris that it presently
has cached. For GPS, the MS specifies the IODE of the ephemeris for each satellite
that it has cached. The SMLC checks this list when putting together the assistance
data for the next measure position request and does not send duplicate information to
the MS in order to save bandwidth.
GANSS location This field provides the GANSS location estimate from the MS to the SMLC for an
information MS-based location calculation. It contains the GPS TOW and whether the fix was a
two-dimensional or a three-dimensional fix. It provides a list of positioning methods
and satellite systems that were used to determine the location. The location is pro-
vided as a shape as specified by the GAD specification [18] in one of the following
forms: ellipsoid point, ellipsoid point with uncertainty circle, ellipsoid point with
uncertainty ellipse, ellipsoid point with altitude, and uncertainty ellipsoid.
GANSS measurement This field includes the measurements of time, code phase, and Doppler. The SMLC
information uses the measurements to calculate an MS-assisted location. The GANSS information
element also allows the handset to return the code phase ambiguity, which means that
the SMLC does not need to solve the millisecond ambiguity problem. In addition, it
enables the handset to return carrier phase measurements to the SMLC.
of ASN.1 notation and how they are encoded using ASN.1 PER. Examples are
shown using the RRLP ASN.1 definitions. Further details can be found in [19, 20].
Items within each component in the ASN.1 notation include a list of
subcomponents, some of which may be optional and some of which may be exten-
sions. Extensions are components that have been added through revisions of the
original RRLP specification. The first version of RRLP did not have any extensions.
The ASN.1 includes an ellipsis (…) to indicate that the subsequent components are
extensions.
An extract from the RRLP specification [1] that describes the RRLP message
format is shown here:
PDU ::= SEQUENCE {
referenceNumber INTEGER (0..7),
component RRLP-Component
}
RRLP-Component ::= CHOICE {
msrPositionReq MsrPosition-Req,
msrPositionRsp MsrPosition-Rsp,
5.3 RRLP 99
Table 5.3 Important Fields from the Assistance Data Message

GPS assistance data The GPS assistance data types were described in Chapter 4. The following
assistance data types are supported for RRLP: reference time, reference loca-
tion, GDPS corrections, navigation model, ionospheric model, UTC model,
almanac, acquisition assistance, and real-time integrity.
Additional GPS assistance data This field contains the extended ephemeris as described above in the
description of the measure position request message.
GPS reference time uncertainty This field contains the uncertainty of the reference time data type.
More assistance data to be sent This indicator is used to indicate to the MS whether this is the final segment
of the message or whether more will be sent. The MS uses this to reassemble
the complete message.
GANSS assistance data This is the GANSS assistance data and contains the GANSS common and
generic assistance data as described above in the measure position request.
Table 5.4 Primary Constructs of ASN.1 Notation

Notation Description
SEQUENCE A sequence is a list of components that are part of the entity being defined. In PER, the
sequence begins with a bit map that indicates the presence or absence of optional compo-
nents. If there is no extension marker, then it is a fixed length bit field with 1 bit for each
optional field in the component as an indicator of whether it is present. If there is an
extension marker, there is a single bit before the bit map that indicates whether any of the
extensions are present in this message. The bit map is followed by the fields that encode
each of the components. If there are extensions, then immediately before the first one is a
count of the number of extensions followed by a bit map that indicates the presence or
absence of each of the extensions in this encoding.
CHOICE A choice is the place where one of the components of the choice is encoded. It is encoded
by specifying an index of the alternative with the first component being 0. This is fol-
lowed by encoding the chosen alternative. The index is normally encoded as a constrained
integer, but if there is an extension selected in the choice, then it is a normally small
nonnegative whole number. If the choice has an extension marker, then a single bit field
will be added before the choice selection to indicate whether the extension addition is
present in the encoding.
… This is the extension marker. It indicates that there are or may be fields at the end of this
component that were not in the original component, and are hence called extensions. In
the PER, there is a 1-bit field that precedes the bit mask that indicates the presence or
absence of optional fields. The 1-bit field indicates whether there are any extensions pres-
ent in this encoding.
OPTIONAL This is a tag associated with a component that indicates that the component is optional.
In PER encoding there is a bit mask that indicates which of the optional fields are
included in the encoding.
ENUMERATED An enumerated type is generally encoded as if it were a constrained integer. It will nor-
mally be encoded as the smallest number of bits to express every enumeration.
INTEGER This is a number. If the number fits into one octet (8 bits) or less, then it is encoded as a
minimum-size bit field with no length count. Ranges that allow the number to fit into two
octets go into two octets in an octet aligned bit field with no length field. Larger numbers
are encoded with a length value and in 2’s complement format.
assistanceData AssistanceData,
assistanceDataAck NULL,
protocolError ProtocolError,
...,
posCapabilityReq PosCapability-Req,
posCapabilityRsp PosCapability-Rsp
}
The ASN.1 shows that the RRLP protocol is made up of a SEQUENCE (an
ordered list) of two items; they are the referenceNumber and the component. The
first item on each line of the notation is the name of the item and the name on the
right is the data type. For example, the first item of the SEQUENCE is the
referenceNumber, which is an INTEGER from 0 to 7. The second item is compo-
nent, which is an RRLP-Component. In a simple analogy to a software programming
language, the first item is the variable and the second is the type.
To encode the RRLP message, the first item (PDU) is a SEQUENCE of two
items and it has no optional components or extension marker. This means that it
does not require any bit mask or extension bit. The first bits encoded will be the
referenceNumber, which is a number from 0 to 7. This number fits into 3 bits,
which is less than one octet (see the description for INTEGER in Table 5.4), so it is
encoded as a minimum-size bit field of 3 bits.
The next item to include is the RRLP-Component, which is specified as a
CHOICE, and has an extension marker. This means that the next bit encoded is the
extension marker, which indicates whether the choice is one of the components
before the marker or is in one of the extension components that is after the exten-
sion marker. After that, the choice is encoded as an index that starts from 0. In the
example above, 0 corresponds to the measure position request, 1 corresponds to
measure position response, and so forth. If the chosen alternative is one of the com-
ponents in the root (one of the components before the extension marker), then the
choice is encoded as an integer.
Consider, for example, encoding the first byte of a measure position request
message as ASN.1 PER as shown in Figure 5.2. The reference number IE field is set
to 1 and occupies the first 3 bits. The extension bit is required because there is an
extension bit in the definition, but it is set to 0 since the measure position request is
not one of the extensions (the measure position request is in the root). The choice is
then encoded as an integer in the minimum number of bits to allow the selection of
one of the five choices, which is 3 bits. The measure position request is the first ele-
ment in the choice, which corresponds to index 0, so that is put into the choice field.
The ASN.1 notation for the measure position request component from [1] is
shown here.
— Measurement Position request component
MsrPosition-Req ::= SEQUENCE {
positionInstruct PositionInstruct,
referenceAssistData ReferenceAssistData OPTIONAL,
msrAssistData MsrAssistData OPTIONAL,
Reference Number IE Choice
0 0 1 0 0 0 0 0
MSB LSB
Extension bit
Figure 5.2 referenceNumber and RRLP-Component fields for a measure position request.
5.3 RRLP 101
systemInfoAssistData SystemInfoAssistData OPTIONAL,

gps-AssistData GPS-AssistData OPTIONAL,
extensionContainer ExtensionContainer OPTIONAL,
...,
— Release 98 extension element
rel98-MsrPosition-Req-extension Rel98-MsrPosition-Req-Extension OPTIONAL,
rel5-MsrPosition-Req-extension Rel5-MsrPosition-Req-Extension OPTIONAL,
rel7-MsrPosition-Req-extension Rel7-MsrPosition-Req-Extension OPTIONAL
}
The definitions of some of the important elements are shown here:

— Position instructions
PositionInstruct ::= SEQUENCE {
— Method type
methodType MethodType,
positionMethod PositionMethod,
measureResponseTime MeasureResponseTime,
useMultipleSets UseMultipleSets,
environmentCharacter EnvironmentCharacter OPTIONAL
—
MethodType ::= CHOICE {
msAssisted AccuracyOpt, — accuracy is optional
msBased Accuracy, — accuracy is mandatory
msBasedPref Accuracy, — accuracy is mandatory
msAssistedPref Accuracy — accuracy is mandatory
}
— Accuracy of the location estimation

AccuracyOpt ::= SEQUENCE {
accuracy Accuracy OPTIONAL
}
— The values of this field are defined in 3GPP TS 23.032 (Uncertainty code)
Accuracy ::= INTEGER (0..127)
— Position Method
PositionMethod ::= ENUMERATED {
eotd (0),
gps (1),
gpsOrEOTD (2)
}
— Measurement request response time

MeasureResponseTime ::= INTEGER (0..7)
— useMultiple Sets
UseMultipleSets ::= ENUMERATED {
multipleSets (0), — multiple sets are allowed
oneSet (1) — sending of multiple is not allowed
}
An example of an encoded measure position request that is defined based on the

ASN.1 above is shown in Figure 5.3. The figure shows the individual bits in octet
groupings with the individual fields as indicated above. The callouts along the top
are an indication of what the values in the fields represent. Below the data are the
names of the ASN.1 components, elements, and fields.
The first 7 bits (starting from the MSB on the left) are as described previously
for the referenceNumber and the RRLP-component, with the reference number IE
set to 1, and the message type of measure position request (also shown in Figure
5.2). The ASN.1 definition shows that the measure position request
102
1 Measure Position Request MS Assisted 57.3 metres GPS 32s 1 set
Reference Position Response Mult

Choice
Number IE ext Choice ext Option bitmask Option Option Accuracy code method time sets
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 0 0 0 1 1 0 1 1
MSB LSB
Accuracy Optional
Method Type Position Measure Multiple
Method Response sets
Time
Position Instructions
RRLP -Component Measure Position Request
Figure 5.3 Example measure position request PER encoding.

Assisted-GPS Location Within a Network
5.3 RRLP 103
(MsrPosition-Req) element contains both extensions and optional components.

This means that the first bit is an extension bit and is followed by a bit mask that
indicates which of the five optional parameters are included in the encoding. In the
example, the extension bit is set to 0 to indicate that none of the extension parame-
ters are included. The option bit mask is also set to 0 to indicate that none of the
optional fields are included.
The only element included is the mandatory one: position instructions. The
position instructions SEQUENCE has one optional field, so there is 1 bit to indicate
whether the environment characterization optional parameter is present. For the
example, the option bit is set to 0 to indicate that there is no environment character-
ization information in the encoded message.
The first field of the position instructions is the method type. It is a CHOICE of
four different methods. Since there are four options, they can be uniquely repre-
sented by 2 bits as shown in the example. In the example, the choice is set to 0,
which indicates MS-assisted as the method type. The MS-assisted positioning type is
defined by AccuracyOpt, which contains one optional field. For this reason, there is
an optional bit that is set to one in the example. The accuracy code is an INTEGER
from 0 to 127, which can be represented in 7 bits. The accuracy code represents an
uncertainty as specified in the GAD specification [18]. The relationship between the
uncertainty in meters r and the uncertainty code K is shown here:
(
r = C (1 + x ) − 1
K
) (5.1)
where C and x are constants: C is 10 and x is 0.1. K is the accuracy code that is
encoded into 7 bits in the message. Rearranging the equation, the accuracy code is
given by (5.2). Note that some resolution in the number is lost when encoding it, so
the value that the receiver decodes will be different to the value encoded by the
sender.
⎛r ⎞
ln ⎜ + 1⎟
⎝C ⎠
K= (5.2)
ln(1 + x )
where ln is the natural logarithm (base e), although any logarithm could be used as
long as it is the same in both the numerator and the denominator. To encode accu-
racy in meters to an accuracy code, (5.2) is used. To decode accuracy code to accu-
racy in meters, (5.1) is used.
The positioning method is the next field in the position instructions elements.
The positioning method is an ENUMERATED type that can take on the values 0, 1,
or 2. In the example it is set to 1 for GPS. The measure response time is an
INTEGER from 0 to 7, which means that it requires 3 bits.
The response time is 2N where N is the value of this field. The example is set to
5, which represents 32 seconds. Equation (5.3) shows how to calculate N, given a
response time in seconds.
ln( responseTime)
N= (5.3)
ln(2 )
The use multiple sets element is an enumerated type that indicates whether to
use one set or multiple sets and occupies 1 bit. The example is encoded to use one
set.
The example message from Figure 5.3 is shown next in a different representa-
tion. It is the output of a text-based message decode tool. More example RRLP mes-
sages are provided in Appendix D. Note that the uncertainty on the request is not
really encoded, as the number shown rather reflects the resolution of the process to
encode and decode the value.
RRLP
0000 001——- Reference Number: 1
—-0—— Extension: false
——000- Measure Position Request
———-0 20 Extension: false
Options:
0001 0———- Reference Assist Data: false
-0——— MSR Assist Data: false
—0——- System Info Assist Data: false
—-0—— GPS Assist Data: false
——0—- Extension Container: false
Options:
——-0— EnvironmentCharacter: false
Method Type
———00 00 Choice: MS Assisted
Options:
0002 1———- Accuracy: true
Accuracy
-0010100 94 Uncertainty: 57.2749994933 meters
Position Method:
0003 01——— GPS
Measurement Response Time:
—101—- MeasureResponseTime: 5
Use Multiple Sets:
——-1— One set
———00 6C
5.3.4 RRLP Implementation

The RRLP code is in the protocol/rrlp directory in the project (and tested with the
classes in the corresponding test directory). The sample code is not a complete
RRLP implementation, but is demonstration code that implements some basic
encoding and decoding for the measure position request message and an application
that sends RRLP messages between a client and a server class over a network con-
nection. The class diagram for the RRLP classes is shown in Figure 5.4.
The RrlpMessage class is an abstract class that provides definitions of methods
that all subclasses need to implement and also code that is common to all RRLP
messages. An abstract class is one that cannot be instantiated, but is instantiated by
subclassing it and then instantiating the subclass. The RrlpMessage class is declared
as abstract since it will always be overridden by the class for the individual RRLP
message. The RrlpMessage class provides some implementation for the encode()
and decode() methods by providing the code to encode and decode the common
header information that is in the start of each RRLP message. The subclasses over-
ride the encode() and decode() methods, but they first call the method in the super
class.
The MeasurePositionRequest and MeasurePositionResponse classes extend the
RrlpMessage abstract class and implement the encode() and decode() methods. The
encode() method is called by an application class with a fresh byte array and returns
the number of bits in the encoded message. The decode() method is called with a
5.3 RRLP 105
RrlpMessage
+encode(in data : byte[]) : int

+decode(in data : byte[]) : bool
MeasurePositionRequest MeasurePositionResponse
+encode(in data : byte[]) : int +encode(in data : byte[]) : int

+decode(in data : byte[]) : bool +decode(in data : byte[]) : bool
Figure 5.4 RRLP classes.
byte array, which is decoded into the instance and returns the Java primitive
boolean to indicate success or failure of the decode.
In this section we will consider the encode() and decode() methods of the mea-
sure position request message. The encode() method of the MeasurePositonRequest
class is shown next and described at a high level in its Javadoc in lines 1–9. Note that
the line numbers are not part of the code but are shown here in order to reference
them in this text.
The MeasurePositionRequest.encode() method is shown here:
1. /**
2. * This method encodes a measure position request from this instance. It creates a binary
3. * message in ASN.1 PER in a byte buffer. It uses the contents of the member variables to
4. * encode the elements. 
5. * Note that the encode does not encode the Extended Reference ID.
6. *
7. * @param the byte buffer to encode the message into.
8. *
9. * @return the number of bits in the byte buffer.
10. */
11. public int encode(byte[] messageBuffer)
12. {
13. //Call the super method to encode the RRLP message header
14. int bitOffset = super.encode(messageBuffer);
15.
16. //The start of the Measure Position Request component
17.
18. //The LSB of the first byte is the extension bit and since we are not using the
extensions
19. //then we just leave that as 0.
20. bitOffset++;
21.
22. //The sequence bitmask for the 5 optional fields.
23. //They are for eotd except for one for gps assist data
24. //but we arent sending that in the measure position request
25. bitOffset += MeasurePositionRequest.MEASURE_POS_OPTIONAL_BITMASK_LENGTH;
26.
27. //Now we are on to the Positioning Instructions sequence
28.
29. //1 bit describing whether the optional environment parameter is present
30. //We arent including this parameter so it stays as 0 in the buffer and we skip over it
31. bitOffset++;
32.
33. //The positioning method type
34. bitOffset = Utility.putBits(this.methodType, messageBuffer, bitOffset,
35. MeasurePositionRequest.METHOD_TYPE_LENGTH);
36.
37. //If methodType is MS assisted, the accuracy is optional so we need to set the bit to
38. //indicate that we are specifying the accuracy
39. if(this.methodType == MeasurePositionRequest.METHOD_MS_ASSISTED)
40. {
41. bitOffset = Utility.putBits(1, messageBuffer, bitOffset, 1);
42. }
43.
44. //Calculate the code for the accuracy
45. int accuracyCode = this.encodeUncertainty(this.requestedAccuracyMeters);
46.
47. //Put the accuracy code into the buffer
48. bitOffset = Utility.putBits(accuracyCode, messageBuffer, bitOffset,
49. MeasurePositionRequest.ACCURACY_CODE_LENGTH);
50.
51. //Put the position method into the buffer
52. bitOffset = Utility.putBits(this.positionMethod, messageBuffer, bitOffset,
53. MeasurePositionRequest.POSITION_METHOD_LENGTH);
54.
55. //Response time = 2^N, so N = ln (respTime)/ln (2)
56. int responseTimeCode = 0;
57. if (this.responseTime > 0)
58. {
59. responseTimeCode = (int)Math.floor(Math.log(this.responseTime)/Math.log(2));
60. }
61.
62. //Put the response time into the buffer
63. bitOffset = Utility.putBits(responseTimeCode, messageBuffer, bitOffset,
64. MeasurePositionRequest.RESPONSE_TIME_LENGTH);
65.
66. //Put the indicator whether to use multiple sets
67. bitOffset = Utility.putBits(this.useMultipleSets, messageBuffer, bitOffset,
68. MeasurePositionRequest.MULTIPLE_SETS_LENGTH);
69.
70. return bitOffset;
71. }
The first thing that this method does is create the header bits and that is done by
the super class, so we call the encode() method of the super class (RrlpMessage) to
do that (line 14). The encode() method in the super class creates the first 7 bits of
data which is common to all of the RRLP messages. This includes the reference
number ID, the extension bit, and the choice field, which indicates the message that
is being encoded. The encode() method returns the bitOffset, which is the offset in
bits of the next bit for data to be added into the byte buffer. At this point in the
method, the bitOffset will be 7.
The RrlpMessage.encode() method is shown here:
1. /**
2. * This method creates the header for encoding an RRLP message. The header is 7 bits.
3. * It is the following format from MSB to LSB: 
4. * referenceNumber INTEGER(0..7) -> 3 bits 
5. * RRLP-Component extension marker -> 1 bit 
6. * RRLP-Component choice -> 3 bits 
7. * 
8. * Note that this implementation does not support the position capability request and
response because
9. * we are not setting the extension marker. It is being set to 0.
10. *
11. * @param buffer the buffer to put the RRLP header into.
12. *
13. * @return the bit offset of the next bit to go into the buffer.
14. */
15. protected int encode(byte[] buffer)
16. {
17. //The first field is the reference Number IE and it goes in at bitOffset 0 for a length of
REF_ID_LENGTH
18. int bitOffset = Utility.putBits(this.referenceNumberIE, buffer, 0,
RrlpMessage.REF_ID_LENGTH);
19.
20. //We are not supporting the extension messages so we’ll leave that as 0 for now
21. bitOffset++;
22.
23. //The next field is the RRLP component choice which is the message
24. bitOffset = Utility.putBits(this.rrlpComponentChoice, buffer, bitOffset,
RrlpMessage.CHOICE_LENGTH);
25.
5.3 RRLP 107
26. return bitOffset;

27. }
The RrlpMessage.encode() method has Javadoc that describes what is being

inserted into the header and it also describes the contents of the passed fields (lines
1–14). Similar to the MeasurePositionRequest.encode(), this method makes use of
the static method Utility.putBits(). The putBits() method is passed the data that
needs to go into the buffer, the buffer, the offset in bits from the start of the buffer
where the bits should be put, and the number of bits to put into the buffer. The
putBits() method can be defined as static in the Utility class since it makes no use of
any member variables of the Utility class. This also means that we do not have to
create an instance of the Utility class to use it. The generated Javadoc for the
putBits() method is shown here:
putBits
public static int putBits(long bits,

byte[] buffer,
int overallBitOffset,
int numBits)
Insert the numBits least significant bits from a long (bits) into a byte array (buffer) at
an offset of overallBitOffset. The byte array is newly created or zero-filled.
Parameters:
bits - the bits to put into the byte buffer.
buffer - the destination array.
overallBitOffset - bit offset in the byte array.
numBits - number of bits to pack from the bits field (between 1 and 64).
Returns:
the bit offset that is available for subsequent bits.
The first thing that the RrlpMessage.encode() does is encode the reference num-
ber IE into the start of the buffer (line 18). The referenceNumberIE is put into the
buffer starting at index 0 for a length defined by the constant
RrlpMessage.REF_ID_LENGTH. The REF_ID_LENGTH is the length of the ref-
erence ID field and the definition is shown next. It is declared to be private since it is
only used within this class, final so that it can not be modified once it is initialized,
and static so that it is only created once in memory and not for each instance of the
class.
/** The length of the reference id field in bits. */
protected static final int REF_ID_LENGTH = 3;
The format of the message being encoded is based on the ASN.1 definition spec-
ified in the previous section. The sample code does not support the RRLP messages
after the extension, so this bit it left as 0 and the bit offset is incremented to skip over
the field in the buffer (line 21). Note that this method assumes that the buffer is
zero-filled otherwise we would need to put the 0 into the buffer. Finally, the choice
is inserted into the buffer and the bit offset is returned to the calling method (lines 24
and 26).
Returning to the MeasurePositionRequest.encode() method shown previously,
refer to the ASN.1 in the previous section as well as Figure 5.2. Consider the com-
ment on line 16 in the code where we are up to the start of the measure position
request component. Since the sample code is relatively limited and does not support
any extensions or optional fields, then we skip over them as shown in lines 20 and
25. We now get to the only mandatory field (as defined in the ASN.1) of the
MsrPosition-Req component, which is the PositionInstruct element. The
PositionInstruct sequence contains several mandatory fields and one optional field
(environmentCharacter). We are not including the optional field, so we leave the
optional bit as 0 and skip forward to the next bit (line 31). The methodType is a rel-
atively straightforward CHOICE and is a 2-bit number that indicates the type of the
positioning requested. The field following the methodType is the Accuracy. The
only exception is if the methodType is MS-assisted, in which case the Accuracy is
optional because it is defined by the element AccuracyOpt. As shown in lines
39–42, if the methodType is MS-assisted, the optional bit is inserted and set to 1
(line 41) to indicate that the Accuracy field is included. A more complete implemen-
tation for MS-assisted would be to check if the requestedAccuracyMeters is a valid
number and if the optional bit would be set to 1 and the accuracy encoded.
The rest of the encode method involves encoding the remaining position
instructions fields and using (5.2) and (5.3) to calculate the accuracy and response
time codes.
The MeasurePositionRequest.decode() method is shown next. It is passed a byte
buffer and returns a Java primitive boolean, which indicates whether the message
was successfully decoded.
1. /**
2. * This method decodes a Measure Position Request into this instance.
3. *
4. * @param message the rrlp message in a byte buffer.
5. *
6. * @return whether the message was successfully decoded.
7. */
8. public boolean decode(byte[] message)
9. {
10. if(!super.decode(message))
11. {
12. return false;
13. }
14.
15. //Measure Position Request component
16.
17. //Set the bit offset to be after the header
18. int bitOffset = RrlpMessage.OFFSET_AFTER_HEADER;
19.
20. //get the measure position request extension and check that it is 0. Otherwise we don’t
support it.
21. int extension = (int)Utility.getBits(message,
bitOffset++,RrlpMessage.EXTENSION_BIT_LENGTH);
22. if(extension != 0)
23. {
24. return false;
25. }
26.
27. //Get the optional bit mask.
28. int options = (int)Utility.getBits(message, bitOffset,
29. MeasurePositionRequest.MEASURE_POS_OPTIONAL_BITMASK_LENGTH);
30. bitOffset += MeasurePositionRequest.MEASURE_POS_OPTIONAL_BITMASK_LENGTH;
31.
32. //This code does not support any of the options
33. if(options > 0)
34. {
35. return false;
36. }
37.
38. //Position Instructions element
39.
40. //Get the position instructions option flag we don’t support options it needs to be 0
41. int option = (int)Utility.getBits(message, bitOffset++, 1);
42. if(option != 0)
43. {
44. return false;
45. }
46.
47. //Method Type element.
48. this.methodType = (byte)Utility.getBits(message, bitOffset,
5.3 RRLP 109
MeasurePositionRequest.POSITION_METHOD_LENGTH);
49. bitOffset += MeasurePositionRequest.POSITION_METHOD_LENGTH;
50.
51. //Accuracy is read for all method types except for method type 0 (MS-Assisted) where it
is optional
52. byte readAccuracy = 1;
53.
54. //If the method type is MS-assisted then we read the option which is set to 1 if accuracy
is included
55. if(this.methodType == MeasurePositionRequest.METHOD_MS_ASSISTED)
56. {
57. readAccuracy = (byte)Utility.getBits(message, bitOffset++, 1);
58. }
59.
60. //If accuracy is included then read the accuracy
61. this.requestedAccuracyMeters = 0;
62. int accuracyCode = 0;
63. if(readAccuracy == 1)
64. {
65. accuracyCode = (byte)Utility.getBits(message, bitOffset,
MeasurePositionRequest.ACCURACY_CODE_LENGTH);
66. bitOffset += MeasurePositionRequest.ACCURACY_CODE_LENGTH;
67. this.requestedAccuracyMeters = this.decodeUncertainty (accuracyCode);
68. }
69.
70. //The position method
71. this.positionMethod = (int)Utility.getBits(message, bitOffset,
MeasurePositionRequest.POSITION_METHOD_LENGTH);
72. bitOffset += MeasurePositionRequest.POSITION_METHOD_LENGTH;
73.
74. //The response time
75. int responseTimeCode = (int)Utility.getBits(message, bitOffset,
MeasurePositionRequest.RESPONSE_TIME_LENGTH);
76. bitOffset += MeasurePositionRequest.RESPONSE_TIME_LENGTH;
77. this.responseTime = (int)Math.pow(2, responseTimeCode); //respTime = 2^N
78.
79. //use multiple sets
80. this.useMultipleSets = (byte)Utility.getBits(message, bitOffset,
MeasurePositionRequest.MULTIPLE_SETS_LENGTH);
81. bitOffset += MeasurePositionRequest.MULTIPLE_SETS_LENGTH;
82.
83. return true;
84. }
You can see that the decode method is longer than the encode method because it
is checking for the presence of options and choices and making decisions based on
them. In addition, it is keeping track of the bit offset. The decode() method makes
use of the Utility.getBits() method to extract the bit fields from the byte array. The
getBits() method returns the data extracted from the byte array as a long and that
data type is then cast to the required data type of the result. One important thing to
note is that the decode() method needs to maintain and keep track of the bit offset in
the buffer. This is due to the implementation of the getBits() method, which does
not return the bitOffset (like the putBits() method) because it is returning the con-
tents of the requested bit field from the encoded message. You can see in the code
that after each call to the getBits() method, there is a line to bump the bitOffset
along to the end of the field that has just been extracted.
The decode() method starts by calling the super class (RrlpMessage) to encode
the header bits that are common to all RRLP messages (line 10). If the super class
cannot decode the header fields, then an unsuccessful result is returned (line 12). It
then sets up the bitOffset to be at the offset after the header bits, as defined by the
constant that is in the RrlpMessage class (line 18). Referring to the ASN.1 descrip-
tion and Figure 5.2, the first bit after the header is the extension bit and we use the
Utility.getBits() method to extract that bit out of the byte array (line 21). The sam-
ple code does not support any extensions, so if the extension bit is set, we return an
unsuccessful result (lines 22–25). We similarly check the bit mask for the optional
bits, and if any of the bits are set, then this sample code does not decode them, so an
unsuccessful result is returned (line 35). We are now onto the position instructions
element and similarly check the option bit mask (line 42).
The rest of the fields are decoded sequentially except for the position method
where we check if it is MS-assisted (line 55) and, if so, read the option bit to deter-
mine whether or not we need to read the accuracy.
5.3.5 Testing the RRLP Classes

Like all of the other classes in the project, the RRLP classes are unit tested by test
classes that use the JUnit framework and are automatically run when the package is
built in Maven. The RrlpMessage class is abstract so it cannot be instantiated
directly by the testing class. This means that a dummy concrete class is created that
extends the RrlpMessage class. The class is called ConcreteRrlpMessage and is in
the test directory structure. It is shown next and has a constructor so that it can be
instantiated within a test case (line 15). The test case can instantiate
ConcreteRrlpMessage, and the methods of the super class (RrlpMessage) are then
available to be tested.
1. package com.ServerAgps.protocol.rrlp;
2.
3. /**
4. * This is a concrete RRLP Message that extends the abstract class RrlpMessage
5. * so that we can test the methods of the RrlpMessage class
6. */
7. public class ConcreteRrlpMessage extends RrlpMessage
8. {
9. /**
10. * Constructor that just calls the super class.
11. *
12. * @param referenceNumber the reference number for this message.
13. * @param choice the rrlp component choice which is the RRLP message.
14. */
15. public ConcreteRrlpMessage(int referenceNumber, byte choice)
16. {
17. super(referenceNumber, choice);
18. }
19.}
A test case that tests the RrlpMessage.encode() method is shown next. It creates
an instance of ConcreteRrlpMessage and is then able to call the encode() method of
the RrlpMessage class.
/** Validate that the header is encoded ok for ref 1 seq 1. */
public void testMessageHeaderEncodeRef1Seq1()
{
byte[] message = new byte[1];
ConcreteRrlpMessage rrlpMsg = new ConcreteRrlpMessage(1, (byte)1);
int offset = rrlpMsg.encode(message);
assertEquals(“Header is as expected for Reference ID 1 Sequence 1", message[0],

RrlpMessageTest.EXPECTED_HEADER_FOR_REFID_1_SEQUENCE_1);
}
5.3.6 Communication Across Sockets with RRLP

There are two classes in the app directory in the archive that are used to demon-
strate simple network communications with RRLP messages being created,
encoded, transmitted, received, and decoded between a client and a server. There
are also corresponding batch jobs in the batch directory to invoke the classes.
5.3 RRLP 111
The server (RrlpServer) is encoding a measure position request message and

transmitting it over a TCP/IP socket to a client (RrlpClient) that decodes the mes-
sage, displays it, and sends it back to the server. Note that RRLP is normally
wrapped in other network protocols; however, the example is provided to introduce
network programming.
A socket is an end-point of a communication link between two processes run-
ning on a network. A server runs and is bound to a particular port number on the
host. When the server starts, it waits listening to the socket for a client to make a
connection request. The other side of the application is the client process. A client
connects to a specific port on a specific host and the server accepts the connection.
The client and server can then communicate on the socket. The Java platform pro-
vides classes that can be invoked by the server and client to establish and maintain
the connections.
The RrlpServer.run() method is shown here:
1. /**
2. * Run the rrlp server.
3. */
4. public void run()
5. {
6. //Set up the server socket
7. System.out.println(“RrlpServer.run setting up server socket”);
8. ServerSocket serverSocket = null;
9. try
10. {
11. serverSocket = new ServerSocket(this.portNumber);
12. }
13. catch (IOException e)
14. {
15. System.err.println(“Could not listen on port e:” + e);
16. return;
17. }
18.
19. //Set up the client socket. This will block until a single client connects
20. System.out.println(“RrlpServer.run waiting for client to connect...”);
21. Socket clientSocket = null;
22. try
23. {
24. clientSocket = serverSocket.accept();
25. }
27. {
28. System.err.println(“Accept failed for client e: ” + e);
29. return;
30. }
31.
32. //Run the simulation. Transmit some made up messages
33. System.out.println(“RrlpServer.run connected...”);
34. try
35. {
36. DataOutputStream out = new DataOutputStream(clientSocket.getOutputStream());
37. DataInputStream in = new DataInputStream(clientSocket.getInputStream());
38.
39. for(int i = 0; i < 5; i++)
40. {
41. System.out.println(“************* ” + i + “ *************”);
42.
43. //Send a message out to the client
44. this.sendSampleMessage(out, i);
45.
46. //Read back the reply
47. this.readMessageFromConnection(in);
48.
49. //Sleep for a second
50. Thread.sleep(1000);
51. }
52. in.close();
53. out.close();
54. clientSocket.close();
55. serverSocket.close();
56. }
57. catch(IOException ioe)
58. {
59. System.err.println(“Caught exception while processing data e:” + ioe);
60. }
61. catch(InterruptedException ie) // this is thrown by the sleep
62. {
63. System.err.println(“Interrupted during the sleep e:” + ie);
64. }
65. }
The run() method begins by creating a ServerSocket to listen on a specific port

(line 11). The port number was previously passed in as an argument on the com-
mand line and read in the main method of RrlpServer. The ServerSocket class will
throw an IOException if it cannot listen on the specified port (for example, if the
port is already in use) and the method will return (lines 13–17). If the ServerSocket
is created successfully, the next step is to wait until a client connects. That is done
using the accept() method of the ServerSocket (line 24). Once the connection is
accepted, the new socket can be used for the communication between the server and
the client.
The server opens an input and output stream reader that is an instance of
DataOutputStream and DataInputStream classes (lines 36–37). These classes are
used for binary communication. The RrlpServer has a loop that sends five messages
to the client and, after each one, reads the response back from the client. On com-
pletion of sending the five messages, it closes the streams and the sockets.
The MeasurePositionRequest is instantiated in the sendSampleMessage()
method. The instance is encoded and sent as shown here:
//Encode the MeasurePositionRequest into the byte buffer
int numBits = mpr.encode(message);
//Write the encoded message onto the buffer
out.write(message, 0, (int)Math.ceil(numBits/8.0));
The encode() method of MeasurePositionRequest returns the number of bits in

the message. The write() method of the DataOutputStream class writes the specified
number of bytes at offset 0 from the message buffer to the underlying output stream.
Details of the DataOutputStream can be found in the Java API.
To read bytes from the DataInputStream, the following code in
RrlpServer.readMessageFromConnection() is used:
1. int noBytes = in.read(data);
2. System.out.println(“Received byte data: ” + Utility.toHexString(data, noBytes));
3. //Decode it as a Measure Position Request
4. MeasurePositionRequest mpr = new MeasurePositionRequest();
5. if(mpr.decode(data))
6. {
7. System.out.println(“Decoded message:\n” + mpr);
8. }
The DataInputStream.read() method reads bytes from the underlying input

stream into a byte buffer and returns the number of bytes read (line 1). An instance
of a MeasurePositionRequest is created (line 4) and the data is decoded into the
instance (line 5). If the message can be decoded (line 5), it is written to standard out-
put (line 7). Note that this server class is a single threaded application for simplicity
of the demonstration. The ServerSocket can accept more than one connection and
the server application can create a thread for each client and work with them in
parallel.
5.3 RRLP 113
The other part of the client/server pair is the client. The RrlpClient.run()
method is shown here:
9. /**
10. * Run the rrlp client.
11. */
12. public void run()
13. {
14. Socket socket = null;
15. DataOutputStream out = null;
16. DataInputStream in = null;
17.
18. System.out.println(“RrlpClient.run connecting to server...”);
19. try
20. {
21. socket = new Socket(“localhost”, this.portNumber);
22. out = new DataOutputStream(socket.getOutputStream());
23. in = new DataInputStream(socket.getInputStream());
24. }
25. catch (UnknownHostException e)
26. {
27. System.err.println(“Dont know about host: localhost e: ” + e);
28. return;
29. }
31. {
32. System.err.println(“Couldn’t get I/O for the connection ” + e);
33. return;
34. }
35.
36. MeasurePositionRequest mpr = new MeasurePositionRequest();
37. byte[] data = new byte[RRLP_MESSAGE_BUFFER_SIZE];
38.
39. System.out.println(“RrlpClient.run connection established. waiting for data...”);
40. try
41. {
42. int noBytes = in.read(data);
43. while(noBytes > 0)
44. {
45. System.out.println(“Received byte data: ” + Utility.toHexString(data, noBytes));
46. if(mpr.decode(data))
47. {
48. System.out.println(“Decoded message:\n” + mpr);
49.
50. //Send it back to the server
51. out.write(data, 0, noBytes);
52. }
53. else
54. {
55. System.out.println(“Could not decode message”);
56. }
57. noBytes = in.read(data);
58. }
59.
60. out.close();
61. in.close();
62. socket.close();
63. }
64. catch(Exception e)
65. {
66. System.err.println(“Exception on the connection ” + e);
67. }
68. }
The RrlpClient.run() method creates an instance of a Socket to connect to the

server. It specifies the host, which is the name of a machine on the network and also
the port that the server is listening on. For this example, the localhost, which is the
name for your local machine, is used. The socket makes a connection to the server
(line 21) and then, similar to the server, creates the streams for reading and writing
the byte buffers (line 23). Any exceptions thrown are handled by writing a message
to standard output and returning (lines 25–34). The class then makes some declara-
tions and then enters attempts to read from the input stream (line 42). It then enters
the while loop (line 43), which will continue until the number of bytes returned
from the stream is less than 0, which indicates that the connection has gone away.
The client calls the decode method (line 46) of the MeasurePositionRequest to
decode the message, and if it is successfully decoded, then it is written to standard
output (line 51).
To complete the sample code, the data is written back onto the connection to
the server (line 51) and then waits for the next message to arrive from the server (line
57). It is important to note that this class is hardcoded to expect and decode the
measure position request message, but other messages may arrive from a server that
is using the RRLP protocol.
5.4 PCAP and RRC
In a UTRAN network, the handset is known as user equipment (UE). The Position
Calculation Application Part (PCAP) [2] Protocol is used to provide a UE with
GNSS assistance data or to perform the position calculation using measurement
made by the UE. The relevant entities of a UTRAN network are shown in Figure 5.5
along with the connections labeled with the protocols. PCAP is the protocol
between the SAS and the RNC and radio resource control (RRC) [3] is the protocol
between the radio network controller (RNC) and the UE.
The RRC protocol handles the control plane signaling between the UE and
other elements in a UTRAN network, performs connection management and
release, and handles the broadcast of system information, mobility procedures,
power control, and location determination. The PCAP protocol contains messages
for location determination only. Many of the location determination messages have
the same fields in PCAP as they do in RRC, so converting a message from RRC to
PCAP (and vice versa) in the RNC is relatively straightforward.
Historically, the RNC was the node in a UTRAN network that performed the
function of location determination in addition to the signaling and call handling. In
order to simplify the RNC, some of the functions were moved out of the RNC to a
new node called the SAS. Initially the RNC was responsible for coordinating the
location calculation and used the SAS to perform the A-GPS functions of providing
assistance data given a reference location or of performing the location calculation
given a set of GPS measurements. This mode of operation is known as RNC-centric
mode. In RNC-centric mode the RNC determines, initiates, and controls the posi-
tioning method to be used. Later, the overall control of the location determination
was moved out of the RNC to the SAS. This mode is called the SAS-centric mode of
operation where the SAS determines, initiates, and controls the positioning.
Radio
Stand alone network
PCAP RRC Node B RRC
SMLC (SAS) controller UE
(RNC)
Figure 5.5 UTRAN elements involved in location.

5.4 PCAP and RRC 115
RNC SAS
Position Calculation Request [approx location,

measurements]
Position Calculation Response [location]

Or
Position Calculation Failure [cause]
(a)
RNC SAS
Information Exchange Initiation Request [approx

location, assistance data required]
Information Exchange Initiation Response

[assistance data]
Or
Information Exchange Initiation Failure [Cause]
(b)
Figure 5.6 (a, b) RNC-centric procedures.
5.4.1 PCAP Procedures

The two functions for RNC-centric operation are the position calculation and infor-
mation exchange elementary procedures (EPs) and are described here.
The position calculation procedure allows the RNC to query the SAS for a posi-
tion estimate of a UE. The message flow is shown in Figure 5.6(a). The position cal-
culation request contains the approximate location as well as measurements that
can be used to perform the location calculation. The measurements can be one or
more of the following types of measurements: GPS measurements, measurements
from other GNSSs, observed time difference of arrival (OTDOA) measurements, or
round-trip timing (RTT) measurements. Note that the approximate location can be
geographic coordinates or an identification of the cell. If the SAS successfully calcu-
lates the location by using the measurements from one location technology or by a
hybrid location calculation, it returns a position calculation response with the
results of the calculation. Alternatively, if there is a problem calculating the loca-
tion, it returns a position calculation failure message with a cause IE that indicates
the reason why the location could not be calculated.
The information exchange procedure allows the RNC to query the SAS for
GNSS assistance data for a UE and is shown in Figure 5.6(b). The RNC sends an
information exchange initiation request message to the SAS with the approximate
location and the assistance data types required. If the RNC sends the flag to indicate
that the assistance data types are “implicit,” then the SAS selects the data types to
send. Which data types to send for an implicit request will normally be predeter-
mined based on provisioning the SAS. The SAS responds with an information
exchange initiation response with the required assistance data types (or the
provisioned set of assistance data types). If the SAS cannot provide one or more of
the required assistance data types, then it responds with an information exchange
initiation failure with the cause IE set to indicate the reason for the failure. There are
several other messages associated with periodic reporting of assistance data for
RNC-centric operations that are described in detail in the PCAP specification.
In SAS-centric mode, the positioning is controlled by the SAS. The fundamental
message flow is shown in Figure 5.7. The RNC sends a position initiation request to
the SAS (A), which includes the capabilities of the UE, the approximate location,
and quality of position (QoP) requirements. The capabilities of the UE indicate
which GNSSs are supported by the UE, whether it supports UE-based or
UE-assisted modes of operation, and whether RTT is supported. The QoP require-
ments are the requested horizontal and vertical accuracy and the time available to
do the location. The approximate location can be geographic coordinates or an
identification of the cell.
If the SAS can satisfy the QoP using the location of the cell, then it will use that
as the location and send back a position initiation response (E). If the cell does not
satisfy the QoP, then the SAS will determine which positioning method to use and
send a position activation request (B) to the RNC. The position activation request
may contain assistance data. The RNC will return a position activation response (C)
to the SAS with the location or measurements to calculate the location. Alterna-
tively, it may contain a list of the assistance data required to complete the location.
The RNC may also send a position activation failure (D) with the cause IE set to
indicate the problem. If the position activation response (C) contains a list of
required assistance data, then the SAS may send another position activation request
to the RNC with the requested assistance data and receive a position activation
RNC SAS
Position Initiation Request [UE capabilities, approx

A location, QoP]
B Position Activation Request [positioning method,

assistance data]
Position Activation Response [location or

C measurements]
Or
Position Activation Failure [cause]
D
E Position Initiation Response [location]

Or
F Position Initiation Failure [cause]
Figure 5.7 SAS-centric procedures.

response back. If the SAS receives measurements, then it can calculate the location
of the UE and provide that (or the UE-calculated location) back to the RNC in the
position initiation response (E). The position initiation response will also contain
the accuracy fulfillment indicator, which indicates whether the response meets the
requested QoP criteria. If, however, there is an error, then the SAS will send the
RNC a position initiation failure (F). Note that the SAS-centric procedure is subject
to a timer that is set based on the positioning response time IE that is in the position
initiation request message.
5.4.2 PCAP Messages and Encoding

From a GPS or GNSS point of view, the PCAP messages contain the same basic
information as the RRLP, which was described in detail in the previous section. The
PCAP provides GPS and GANSS data to a handset that is capable of locking onto
satellite signals from one or more GNSS. There is a mechanism in the protocol for
the UE to report the required assistance data, the location, or the GNSS measure-
ments to the SAS.
Similar to RRLP, PCAP uses ASN.1 [19] as the notation to describe the protocol
in detail. It uses ASN.1 PER [20]. It also uses the BASIC-PER variant; however, the
significant difference is that it uses the ALIGNED Variant. For the ALIGNED vari-
ant, some of the IEs are aligned to octet boundaries or octet-aligned. This means
that padding bits are inserted from time to time to restore octet alignment. Note that
in the UNALIGNED variant, no padding bits are ever inserted.
1. Modify the encode and decode method of the MeasurePositionRequest class

so that the accuracy field is truly optional for MS-assisted. If the requested
accuracy in meters is less than 0, then the accuracy field should not be
included in the encoded message.
2. Write test cases to test the change made above.
3. Run the code coverage using Emma and see which of the methods of the
RRLP classes are not fully tested. Write test cases to improve the coverage of
the unit testing. Aim for 100% coverage.
4. Implement the encode and decode and any other necessary methods for the
MeasurePositionResponse class to be able to encode and decode the
mandatory fields.
5. Write the MeasurePositionResponseTest class to test the new methods. Use
the code coverage tool to ensure that good coverage is achieved.
6. Update the RrlpClient so that it sends a MeasurePositionResponse back to
the server when it receives a measure position request.
7. Update the RrlpClient and RrlpServer classes so that they can decode a
general RRLP message. At present, they assume that the message that they
receive is a measure position request and try to decode it as that message

type.
8. Develop a message decode tool that outputs the RRLP data and the
individual IEs for inspection, similar to the output shown at the end of
Section 5.3.3, which shows a decoded measure position request message.
9. Update the MeasurePositionRequest so that it supports the extended
reference IE. As specified in the procedures section of the RRLP
specification, even though the extended reference IE is in an extension, it is a
mandatory field.
10.Implement the RRLP protocol error message and some of the other
messages, for example, the assistance data message.
11.Update the MeasurePositionRequest class so that it supports GPS
assistance data.
References
ing Mobile Location Center (SMLC) Radio Resource LCS Protocol (RRLP), 2009.
Radio Access Network; UTRAN Iupc Interface Positioning Calculation Application Part
(PCAP) Signaling, 2009.
[4] 3GPP2 C.S0022/TIA IS-801, Position Determination Service Standard for Dual Mode
Spread Spectrum Systems, 2004.
vices and System Aspects; Functional Stage 2 Description of Location Services (LCS), 2009.
[6] 3GPP2 X.S0002/TIA PN-4747 (IS-881) Third Generation Partnership Project; MAP Loca-
tion Services Enhancements, 2002.
GSM/EDGE Radio Access Network; Functional Stage 2 Description of Location Services
(LCS) in GERAN, 2008.
Radio Access Network; Stage 2 Functional Specification of User Equipment (UE) Position-
ing in UTRAN, 2008.
[10] Dawson, M., J. Winterbottom, and M. Thomson, IP Location, New York:
McGraw-Hill/Osborne Media, 2006.
[11] TIA/EIA/IS-TIA/EIA/J-STD-036-A-A—Enhanced Wireless 9-1-1 Phase 2, March 2002.
[12] NENA, NENA Standard for the Implementation of the Wireless Emergency Service Proto-
col E2 Interface, 2003.
[13] Canadian Radio—Television and Telecommunications Commission, Wireless E9-1-1
Phase 2 Stage 1 Technical Specification Recommendation, 2009.
[14] 3GPP TS 49.031, Third Generation Partnership Project; Technical Specification Group
GSM/EDGE Radio Access Network; Location Services (LCS); Base Station System Appli-
cation Part LCS Extension (BSSAP-LE), 2008.
[15] European Space Agency/Galileo Joint Undertaking, Galileo Open Service, Signal In Space
Interface Control Document, OS SIS ICD, 2008.
[16] Japan Aerospace Exploration Agency, Quasi-Zenith Satellite System Navigation Service,
Interface Specification for QZSS (IS-QZSS), 2008.
CA, 2009.
[19] ITU-T X.680; Series X: Data Networks and Open System Communications; OSI Network-
ing and System Aspects—Abstract Notation One (ASN.1); Information Technol-
ogy—Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, 2008.
[20] ITU-T X.691; Series X: Data Networks and Open System Communications; OSI Network-
ing and System Aspects—Abstract Notation One (ASN.1); ASN.1 Encoding Rules—Speci-
fication of Packed Encoding Rules (PER), 1999.
CHAPTER 6
Position Calculation
The GPS satellites transmit a ranging code that ultimately allows the handset to
determine the distance between the satellite and the handset. When combined with
measurements from other satellites, knowledge of the location of each satellite, and
application of error correction, the location of the handset can be calculated.
When the handset is A-GPS enabled and connected to a network, the position
calculation may be performed on the handset or the server. When running in hand-
set-assisted mode, the A-GPS server provides the handset with a compact set of
assistance data (normally reference time and acquisition assistance) and the handset
locks onto the satellites and returns the measurements to the server. This allows the
position calculation to be performed on the server that has more processing power
and can optionally include other measurements that have been made by the network
to calculate a hybrid location.
This chapter discusses the position calculation with particular reference to it
being performed on the server. It introduces the mathematical theory at a high level,
and the models used for the calculations and discusses the implementation with the
source code and object model. It is done from the perspective of a walk-through of
the Java code that accompanies this book with a worked example position
calculation.
6.1 Position Calculation and Handset-Assisted A-GPS
For handset-based A-GPS, the encoding of the measurements depends on the proto-
col that delivers the measurements. Table 6.1 shows the measurements that the
handset returns to the server. It returns the GPS time and the remaining fields are
returned for each satellite measured by the handset.
The location of the handset can be calculated using the code phase measure-
ments (whole chips and fractional chips) or using the Doppler measurements. The
other measurements that the handset makes provide information about the quality
of the measurements that the handset has made. Those quality measurements are
the carrier-to-noise ratio (C/N0), the multipath indicator, and the pseudorange RMS
error.
The location of the handset can be calculated using either the code phase or the
Doppler shift measurements made by the handset. A code phase based calculation
for a given set of measurements may calculate the location within a few meters
where a Doppler-based calculation will calculate an inferior location that will be
within several thousand meters.
121
122 Position Calculation
Table 6.1 GPS Measurement Parameters

Parameter Range Units Notes
GPS TOW The GPS time of week.
Satellite ID 0–63 The identifier of the satellite. To convert it to PRN,
add 1 to it.
C/N0 0–63 dB-Hz The handset’s estimate of the carrier to noise ratio.
Doppler +/− 6,553.6 Hz The Doppler shift measured by the handset for the
particular satellite signal.
Whole chips 0–1,022 chips The whole value of the code phase measurement in
units of 1 chip.
Fractional chips 0 to < 1 chips The fractional value of the code phase measurement.
Multipath indicator An indicator of the multipath as measured by the
handset and set to low, medium, or high.
Pseudorange RMS error 0 to 112 meters The measured RMS error in meters.
The code phase calculation will generally be successful if the initial location is
within 100 kilometers and there are sufficient GPS measurements. When the hand-
set is in a cellular network, the initial location comes from the location of the cell
tower. For a stand-alone GPS, the location may be cached from previous location
fixes.
The alternative to knowing the initial location is to initially perform a Doppler
shift-based position calculation to determine the seed location, followed by a code
phase-based position calculation to determine the more accurate location.
In this chapter we initially discuss the code phase-based position calculation
and work through an example with real data from a GPS reference station. The
Doppler shift-based location and the use of hybrid measurements are discussed.
6.2 The Accuracy and Yield Trade-Off
The position calculation steps described next are required in order to calculate the
location of the handset. There are some optional steps that may improve the accu-
racy of a location, but these may result in a position calculation failure if not applied
carefully (decrease the yield). When considering which optimizations to include in
the position calculation process, two important factors need to be weighed:
accuracy and yield.
Accuracy is the distance of a calculated location from the ground truth. Yield is
an indication of whether a location is successful or not and is often expressed as a
statistical measure of the percentage of successful position calculations over time.
They are somewhat mutually exclusive goals. For example, achieving the highest
possible accuracy means that sometimes a satellite may be pruned (or dropped)
from the calculation process due to it having a high measurement error; however,
the position calculation may ultimately fail if the remaining satellites do not allow
the position calculation function to converge on a solution. Similarly, achieving a
higher yield may require the inclusion of measurements to satellites that have a high
measurement error and the result may be less accurate than it could have been by
removing the satellite from the calculation.
Some optimizations may be made by performing multiple position calculations.

For example, if a location fails where a satellite has been pruned due to a high mea-
surement error, then another calculation can be made with the measurement
included. Provided that the uncertainty of that location is within certain bounds, the
resulting location could be used.
One example of the trade-off is when considering whether to remove satellites
that are low on the horizon. Low-elevation satellites are generally subject to more
error than those at higher elevations; this is discussed in detail in Section 6.3.11.
Even though the low elevation satellites may have more measurement errors,
removing them can adversely affect the geometry (measured by DOP). Reducing the
quality of the geometry will, in turn, have an effect on the uncertainty, so it may not
always be wise to prune the low elevation satellite. The position calculation dis-
cussed in Section 6.3 does not have this optimization, but is a single run through a
6.3 Positioning Using GPS Code Phase Measurements
In Chapter 3, GPS and A-GPS were introduced along with the geometric model of
receiver positioning (Section 3.13). Geometrically, the problem involves determin-
ing the point of intersection of spheres. The centers of the spheres are the location of
the satellites and the radius of the spheres are the respective measured ranges to the
satellites. The point of intersection is the location of the handset.
The GPS ranging signals that are measured by the handset allow calculation of
the range to the satellites. These range measurements, however, are corrupted by
the offset of the handset and the offset of the satellite clock from GPS time and are
hence referred to as pseudorange measurements. Note that the measurements are
also corrupted by measurement errors, but these are insignificant compared to the
clock offsets. The equations shown in this section are based on the description in
[1].
Consider Figure 6.1, which shows a three-dimensional coordinate frame. Our
ultimate goal is to determine the location of the handset (or the user) u (xu, yu, zu),
and we do this in the WGS 84 ECEF coordinate system. The location of the satellite
s (xs, ys, zs) is also shown and is separated from the user by the range vector r.
The magnitude of the vector r is given by
r = s−u (6.1)
this can be expanded to that shown in
(xs − x u ) + (ys − yu ) + (z s − z u )
2 2 2
r= (6.2)
The location of the satellite s is calculated using the ephemeris information

using the algorithm described in Chapter 3. The distance r is calculated from the
time that it takes for the signal to travel from the satellite to the user multiplied by
the speed of light. Using the signal transmit and receipt times, the range r is given by
s (x s , y s , zs )
zs
u (x u ,y u ,zu)
ys
xs
y
zu
xu
yu
x
Figure 6.1 User and satellite model.
r = c(t − t SV ) (6.3)
where c is the speed of light, t is the time of signal reception by the handset, and tSV is
the time of transmission of the signal from the satellite.
As noted earlier, the clocks onboard the satellite and receiver are not synchro-
nized with each other and the clocks on the satellites are not synchronized to the
clocks on the other satellites. Each satellite has a free running clock, which is gener-
ally offset from the GPS system time. This satellite clock offset ΔtSV, however, can be
calculated using the information from the broadcast NAV message. The receiver
clock offset tu is recovered by solving for it in the position calculation process by
using redundant satellite measurements.
The pseudorange (ρ) can be defined based on (6.3) with the clock error terms
introduced as shown in (6.4) from [1].
[
ρ = c (t + t u ) − (t SV + Δt SV ) ]
= ct + ct u − ct SV − cΔt SV (6.4)
= c(t − t SV ) + c(t u − Δt SV )
where t is the time of receipt by the handset, tu is the handset clock error, tSV is the
time on the satellite, and ΔtSV is the satellite clock error. Substituting r back into
(6.4), and ignoring the satellite clock error since it can be calculated using broadcast
information, the pseudorange can be defined as shown in
ρ = r + ct u (6.5)
Substituting the expression for the geometric range from u to s from (6.2) into
(6.5), the result is
(xx − x u ) + ( y s − y u ) + ( z s − z u ) + ct u
2 2 2
ρ= (6.6)
Since ρ is measured, the location of the satellite can be calculated (xs, ys, zs) from
the ephemeris and c is a constant, and we have an equation with four unknowns.
These unknowns are the three coordinates of the handset (xu, yu, zu) and the handset
clock error (tu). The nonlinear equations can be solved when the handset makes
measurements to at least four satellites, that is, four nonlinear equations to solve for
four unknowns.
As described in [2], the measurements can be combined into a set of normal
equations as shown in (6.7).
Δρ = HΔx + ε (6.7)
where Δρ is the difference between the predicted and actual measurement, H is the
geometry matrix, Δx is the error in the last estimated location and error in the esti-
mated handset clock error, and ε is the residual error. The contents of each element
of Δρ when there are four satellite measurements are shown in
⎡
⎢
(ρ 1
) (
− Δt 1SV × c − r 1 + t r × c ⎤
⎥
)
⎢ (ρ 2
− Δt SV2
) (
× c − r2 + tr × c ⎥ )
Δρ = ⎢ ⎥ (6.8)
⎢
⎢
(ρ 3
− Δt SV
3
) (
× c − r3 + tr × c ⎥
⎥
)
⎢
⎣ (ρ 4
− Δt SV
4
) (
× c − r4 + tr × c ⎥
⎦ )
where ρ is the measured pseudorange to satellite n, ΔtSVn is satellite clock error for
n
satellite n, c is the speed of light, rn is the calculated range to satellite n from the cur-
rent estimate location, and tr is the handset clock offset. H is frequently referred to
as the geometry matrix (it is referred to as G in [2]). The contents of H are shown in
⎡ x 1s − x u y1s − y u ⎤
z 1s − z u
⎢− 1
− 1
− c ⎥ 1
⎢ r r r ⎥
⎢ x s2 − x u y s2 − y u z s2 − z u ⎥
⎢− r2
−
r2
−
r2
c⎥
H=⎢ ⎥ (6.9)
⎢ x s3 − x u y s3 − y u z s3 − z u ⎥
⎢− r3
−
r3
−
r3
c⎥
⎢ ⎥
⎢ x s4 − x u y s4 − y u z s4 − z u ⎥
⎢⎣− r
−
r4
−
r4
c⎥
⎦
where (x sn , y sn , z sn ) is the coordinate of satellite n, (xu, yu, zu) is the last estimated
coordinate of the user, and rn is the range from the estimated location to satellite n.
As shown in (6.10), Δx is the estimate of the error in the present location and the
error in the handset clock error.
⎡Δx u ⎤
⎢Δy ⎥
Δx = ⎢ u ⎥ (6.10)
⎢Δz u ⎥
⎢Δt ⎥
⎣ u⎦
The weighted least squares solution to the equation is shown in
( )
−1
x$ = H T WH H T WΔρ (6.11)
where x$ is the estimate of the change to apply to x and W is the weight matrix. The
weight matrix W is generally satellite elevation dependent, which means that satel-
lites at higher elevations are given a higher weight; this also accounts for measure-
ment errors. The implementation of the least squares solution is discussed later in
this chapter.
Generally, the process of calculating the handset location consists of prepro-
cessing the data and then performing the least squares process by iteratively refining
the solution to (6.11). At each iteration, the H, W, and Δρ matrices are recalculated
since the estimate x of the user location has been updated.
The next section describes the preparation of the data and that is followed by
the position calculation in Section 6.3.15.
6.3.1 Data Preparation

Once the measurements to each satellite have been made, the following steps are
often used to calculate the location of the handset:
• Check health of the satellites and prune measurements that are from
unhealthy satellites or are from satellites for which we do not have the
ephemeris.
• Calculate the pseudoranges to use for the measurements given the code
phases.
• Calculate the location of each satellite at the measurement’s time of transmis-
sion.
• Calculate the satellite clock correction for each satellite.
• Adjust the clock correction for the satellites group delay.
• Apply the geometric range correction to each satellite location.
• Prune bad satellite measurements.
• Prune satellites based on their elevation.
• Check and prune satellites based on their measured SNR and RMS error.
• Correct measurements for ionosphere propagation.
• Correct measurements for troposphere propagation.
• Solve the equations to determine the location of the handset.
• Perform location integrity checking.
These steps are outlined in the following sections with the code that implements
the algorithm. The GpsPositionCalculation Java class contains the code to calcu-
late the location given a set of GPS measurements, the ephemeris, an initial loca-
tion estimate, and the current ionosphere model. The class, using the
GpsPositionCalculation, instantiates it and calls the calculatePosition() method
with the appropriate parameters. Note that the initial location will often come from
the location of the cell tower. The calculatePosition() method makes a series of
method calls to the methods described in the following sections to set up the infor-
mation required to solve the equations to determine the location of the handset.
The code is not exhaustive and is simplified for ease of understanding. No
optimizations have been applied to the code such as memory pooling or precalculat-
ing intermediate calculations that are made several times during the process. There
is limited error checking. If an error occurs during the position calculation, then no
error code is set. Some of the steps have been simplified or implemented as stubs
only. In addition, no quality measure or uncertainty of the location is returned to
the calling method. These are parts of the implementation that have been left as an
exercise for the reader (see Section 6.6).
There is a batch job called PosCalc.bat in the batch directory that runs the posi-
tion calculation for all of the records in a RINEX file. It has command line parame-
ters that indicate the file name of the RINEX observation file (containing the GPS
measurements), the file name of the RINEX navigation file (containing the
ephemeris), and an initial location estimate. It runs a position calculation for each
measurement in the file and outputs statistics of the yield and accuracy.
6.3.2 Worked Example

In this chapter we work our way through a position calculation example. The obser-
vation data comes from a RINEX file for the “mia3” CORS station [3]. It is a per-
manent GPS site called “Miami 3” and is located in Miami, Florida. The ground
truth for the site in WGS 84 is:
• Latitude: 25.73280998;
• Longitude: −80.16017092;
• Altitude: −16.1466.
The RINEX observation file name is mia30750.09o and contains observations

at 30-second intervals for the whole day of March 16, 2009. The RINEX navigation
file is auto0750.09n and both of the files are included in the rinex/data directory.
The GPS measurement that we are using for the example is the first one in the
file. It is for March 16, 2009, at the time 0:00:0.00 which is midnight between
March 15 and 16. The output of the SatelliteInformation.toString() for that mea-
surement is shown next. The GPS time is normally specified as the number of weeks
from the start of the GPS and the number of seconds since the start of the week. The
measurement is for GPS week 1,523 and the seconds of the week are 86,400. Note
that the GPS week is modulo 1,024 when it is part of the ephemeris, so the GPS
week in the NAV message would be 499. The GPS measurement contains
pseudoranges to six satellites.
GPS Measurement 16/03/2009 12:00:00 AM wk: 1523 gpsSecondsOfWeek: 86400.0 fractionsOfSeconds:

0.0
PRN: 32 pseudorange: 23318037.10
Note that the RINEX observation contains the pseudorange measurements.

The pseudoranges have been constructed from the original code phase measure-
ments. The measurements are not normally presented to the position calculation
method as pseudoranges, but are actually code phase measurements, that is, the off-
set within the 1,023-bit-long C/A code. To preserve this and make the position cal-
culation code more generic, when the data is read from the RINEX file, the
constructor of the SatGpsMeasurement class converts the measurements into the
code phase equivalent: whole and fractional chips. It essentially discards the abso-
lute measurements and preserves the submillisecond component of the
pseudorange. The measurement is shown here with the code phase equivalent to the
pseudorange:
GPS Measurement 16/03/2009 12:00:00 AM wk: 1523 gpsSecondsOfWeek: 86400.0 fractionsOfSeconds:
0.0
PRN: 32 wholeChips: 798 fracChips: 0.55
The worked example is run each time that the package is built from the source
code. This is because it is a test case in the method
GpsPositionCalculationTest.testPositionCalculationCh6WorkedExample(). The
test method uses methods in the RinexObsFile and RinexNavFile classes to read in
the RINEX navigation and observation files, respectively. The
testPositionCalculationCh6WorkedExample() method sets up the data for the posi-
tion calculation by using the RinexNavFile.getSatInfo() method to get the
ephemeris for all of the satellites at the given time (March 16, 2009, at time
0:00:0.00). It uses the RinexObsFile.getMeasurement() method to get the first GPS
measurement from the observation file and it sets up an initial location estimate.
The initial location estimate is about 5,000 meters from the ground truth location.
An initial estimate will normally be within the range of 0 to 20,000 meters from the
ground truth depending on how it is determined. For example, in a cellular network
it will depend on the size of the cell.
The initial location is set to:
InitialLocation lat: 25.77846 long: −80.15094 alt: −16.15

x: 983046.58 y: -5662323.88 z: 2756974.22
The GpsPositionCalculation.calculateLocation() method calls the

performPosCalcPreprocessing() method to perform all of the preprocessing steps
up to solving the weighted least squares.
6.3.3 Satellite Health

The navigation model has details of the health of the satellite in a 6-bit field. It is
also present in the almanac for the other satellites in the constellation. The health
bits in the ephemeris should always be used in preference to those in the almanac,
which are updated less regularly.
The MSB of the 6-bit field indicates whether the satellite is completely healthy
or it has an error. The five LSBs have a code that indicates the problem with the sat-
ellite. If the code indicates that the problem does not affect the L1 C/A, then we can
still include the satellite measurement (for that satellite) as part of the position cal-
culation. Table 20-VIII in the GPS IS [4] gives the complete set of health codes from
0 to 31. Many of the codes are related to L1 C and L2 P, but as single frequency GPS
L1 users, we are only interested in those relating to GPS L1. If the code is from 4 to
15 or from 25 to 27, then the code is indicating a problem that is not for GPS L1;
otherwise, there may be a problem with GPS L1.
The isSatelliteHealthyL1() method of the Satellite class illustrates this health
checking:
1. /**
2. * Returns true if this satellite is healthy for GPS L1.
3. * Health is a 6 bit field with the MSB indicating whether all of the
4. * data is ok. If this is set to 1 then we need to check if the other
5. * bits indicate that the problem is with L1. The errors relating to
6. * L1 are given in the GPS IS table 20-VIII
7. *
8. * @return true if this satellite is healthy for GPS L1.
9. */
10. public boolean isSatelliteHealthyL1()
11. {
12. //The MSB of the 6 bits indicate whether the satellite is completely healthy
13. // 0 means that all NAV data is ok, 1 means that some or all NAV data is bad
14. if((this.satelliteHealth & 0x20) == 0)
15. {
16. return true;
17. }
18.
19. //else there is something wrong and we need to check it isnt L1
20. //It does NOT affect L1 if the 5 LSBs are from 4 to 15 OR from 25 to 27.
21.
22. //Pull out the 5 LSBs
23. int satelliteHealthCode = this.satelliteHealth & 0x1F;
24.
25. //Now check if it is one of the codes that do not apply to GPS L1
26. if((satelliteHealthCode >= 4 && satelliteHealthCode <= 15) ||
27. (satelliteHealthCode >= 25 && satelliteHealthCode <= 27))
28. {
29. return true;
30. }
31. return false;
32. }
The method first uses a bit mask to check if the MSB of the 6 bit field is set by
isolating that bit with the bitmask 0×20 (or 0010 0000) (line 14). If the bit is not set,
then the satellite is completely healthy, so we return true. Otherwise, we pull out the
five LSBs (line 23) to check if the error code is one that does not affect L1 (lines
26–27). If it does not affect L1, then we return that the satellite is healthy (line 29);
otherwise, we fall through to line 31 and return false.
Code in the GpsPositionCalculation class calls this method for each of the mea-
sured satellites. If a satellite fails the health test, then it should be excluded from the
Note that for A-GPS, it is not expected that a handset would make a measure-
ment to a satellite that is not healthy. This is because the LS does not provide assis-
tance data to a handset for a satellite that is not healthy. In addition, the server
provides a list of the bad satellites to the handset using the real-time integrity (RTI)
assistance data type as discussed in Chapter 4. It is possible, however, that a handset
has cached information about a satellite that has gone bad and may choose to
ignore the RTI information, or alternatively the satellite health has changed in the
time between when assistance data was sent to the handset and the response was
received on the LS. Regardless, it is worth checking the health of the satellite
because handsets in the field have been shown to occasionally provide measure-
ments to satellites that have a bad health indicator. If measurements from satellites
that are bad are included in the position calculation, the location may fail or a less
accurate location may be calculated.
6.3.4 Calculate the Location of Each Satellite

The satellite locations are calculated at the time that they transmit the measured sig-
nal. The time of transmission is calculated using
ρ
t SV = t − (6.12)
c
where tSV is the time that the satellite transmitted the signal in seconds from the start
of the week, t is the time that the measurement was made by the handset, ρ is the
measured pseudorange to the satellite, and c is the speed of light. The Satel-
lite.calculateSatelliteLocation() method (discussed in Chapter 3) is called to calcu-
late the location of the satellite at that time and it returns an instance of a
Wgs84Coordinate for each satellite. The location calculated for the satellites for the
worked example are shown here as x, y, z ECEF coordinates.
PRN: 32 satLocation: -11501772.43 -11195805.97 21600295.49
PRN: 31 satLocation: -1452139.21 -19791493.85 17799129.73
PRN: 14 satLocation: 13580826.41 -14259715.37 17887352.18
PRN: 16 satLocation: 60483.65 -23829334.95 -11422170.12
PRN: 30 satLocation: 16300474.85 -8989815.78 18552206.96
PRN: 22 satLocation: 11669760.39 -23488115.02 -3820602.87
6.3.5 Satellite Clock Correction

The satellite correction was discussed in Chapter 3. Equation (3.2) showed how the
satellite clock correction (ΔtSV) is determined. The satellite clock correction is
applied to the measured pseudorange and is part of the functional model described
later. The code to calculate the satellite clock correction is relatively straightforward
as shown here:
1. /**
2. * Calculate the satellite clock correction. This is defined in section
3. * 2.5.5.2 of the GPS Signal Specification or 20.3.3.3.3.1 of the GPS IS.
4. *
5. * @param gpsTimeOfWeek the time to calculate the correction for
6. *
7. * @return the correction in seconds.
8. */
9. public double calculateSatelliteClockCorrection(double gpsTimeOfWeek)
10. {
11. double tk = this.calculateTimeFromEpoch(gpsTimeOfWeek);
12. double mk = this.m0 + (this.n * tk); //mean anomaly
13. double ek = this.calculateEccentricAnomaly(mk);
14.
15. // Calculate the Relativity time correction as specified in the spec
16. double deltaTr = Satellite.F * this.e * this.sqrtA * Math.sin(ek);
17.
18. // Calculate the clock correction and add the relativity time correction
19. double dtsv = this.af0 + (this.af1 * tk) + (this.af2 * (tk * tk)) + deltaTr;
20.
21. return dtsv;
22. }
The Satellite.calculateSatelliteClockCorrection() method implements (3.2).

Lines 11–12 set up the data needed to calculate the eccentric anomaly (Ek). In line
11, a method call is made to calculate tk (the time from the reference epoch), since
that operation is common to the code that calculates the satellite location. Similarly,
the call to the method to calculate Ek (line 13) is also used by the satellite location
calculation. In line 16, the relativity time correction is calculated. Note that some
implementations consider that as a separate item from the clock correction.
The calculateEccentricAnomaly() method is shown next. It is interesting
because it contains an iterative step to calculate Ek in lines 19–26. The loop contin-
ues until the difference between the calculation of Ek from this iteration and the pre-
vious iteration is very small. Note also that the loop has a mechanism to break out
in the case where the solution fails to converge (line 26). It performs a check to
determine whether the solution failed to converge (line 29). If it did fail to converge,
then it should perform some action to indicate the failure to the calling method.
Throwing an exception is the obvious candidate solution.
1. /**
2. * This method determines Ek through iteration. Ek is the eccentric
3. * anomaly and is defined in the GPS SS and the GPS IS as one of the
4. * calculations used for calculating the location of the satellite.
5. * It normally converges in 5 to 8 iterations.
6. *
7. * @param mk this is the mean anomaly.
8. *
9. * @return the calculated eccentric anomaly.
10. */
11. private double calculateEccentricAnomaly(double mk)
12. {
13. double ek = mk;
14. double oldEk;
15.
16. //This loop normally converges within 8 iterations but we have a counter in the loop to
17. //guard it from getting into an endless loop.
19. do
20. {
21. oldEk = ek;
22. ek = mk + this.e * Math.sin(ek);
24. }
25. while(Math.abs(ek - oldEk) >= Satellite.SMALL_DIFFERENCE_IN_ESTIMATE &&
26. numberOfIterations < Satellite.MAX_NUM_ITERATIONS_CALCULATING_EK);
27.
28. //We should check to make sure that the iteration converged
29. if(numberOfIterations == Satellite.MAX_NUM_ITERATIONS_CALCULATING_EK)
30. {
31. System.out.println(“calculateEccentricAnomaly ek did not converge”);
32. //Do something here to indicate that there is a problem.
33. //Throwing an exception might be the best thing to do.
34. }
35. return ek;
36. }
The satellite clock corrections for the worked example are shown here:
PRN: 32 satClockCorrectionSec: -0.00028607
PRN: 31 satClockCorrectionSec: 0.00005484
PRN: 14 satClockCorrectionSec: 0.00014040

6.3.6 Group Delay Differential

The satellite group delay differential term TGD is part of the NAV model and is a
correction term that is applied to the satellite clock correction (ΔtSV). It is specified in
the GPS IS [4] and the GPS SPS [5] as shown in (6.13) and only applies to single-fre-
quency users.
( Δt sv ) L1 = Δt sv − TGD (6.13)
The group delay is applied to the satellite clock correction in the

GpsPositionCalculation.calcSatLocationsAndCorrections() method.
The group delays for the example are shown here:
PRN: 32 TGD: -0.000000003260
PRN: 31 TGD: -0.000000013039
PRN: 14 TGD: -0.000000009313
PRN: 16 TGD: -0.000000009779
PRN: 30 TGD: -0.000000007916
PRN: 22 TGD: -0.000000018161
These are added to the satellite clock correction and the overall satellite clock
correction in seconds and meters that include the group delay differential becomes:
PRN: 32 satClockCorrectionSec: -0.00028607 satClockCorrMeters: -85760.25882810
PRN: 31 satClockCorrectionSec: 0.00005485 satClockCorrMeters: 16444.73363056
PRN: 14 satClockCorrectionSec: 0.00014041 satClockCorrMeters: 42093.99616495
6.3.7 Geometric Range Correction

The satellite coordinates calculated in Section 6.2.2 are the ECEF coordinates of the
satellite at the time of transmission of the signal from the satellite. Since the Earth is
rotating, however, we require the coordinates in a rotating reference frame at the
time of reception at the handset, that is, at the time when the measurements are
made. The ECEF reference frame is rotating about the z-axis (as the Earth is) during
the time taken for the signal to travel from the satellite to the receiver. The rotation
is applied to the ECEF coordinate of the satellite as shown in
X S′ = R z Ω e(
& Δt X
S ) (6.14)
where Rz is the rotation matrix about the z axis, Ω& is the rotation rate of the Earth
e
(and hence the rotation of the ECEF CRF), Δt is the time for the signal to travel to
the Earth, XS is the uncorrected location of the satellite, and XS′ is the corrected sat-
ellite location. Equation (6.15) is the expanded form of the rotation matrix with the
signal travel time and Earth rotation rate terms included.
& Δt
⎡ cos Ω & Δt 0⎤
sin Ω
e e
Rz (
& Δt = ⎢− sin Ω
Ω e )
⎢
& Δt
e
& Δt 0⎥
cos Ω e ⎥
(6.15)
⎢⎣ 1 1 1⎥⎦
which gives the corrected satellite coordinates as specified by
x ′ = cos Ω & Δtx + sin Ω

& Δty
e e
& &
y ′ = − sin Ω Δtx + cos Ω Δty (6.16)
e e
z′ = z
The equivalent Java code from the GpsPositionCalculation class is shown here:
1. /**
2. * This method applies geometric range correction to a satellite location. This is the
correction
3. * for the rotation of the earth.
4. *
5. * @param satLocation the location of the satellite to apply the correction for.
6. * @param satSignalPropagationTimeSec this is the signal propagation time for the
measurement
7. * from the satellite to the handset in seconds.
8. */
9. public void applyGeometricRangeCorrection(Wgs84Coordinate satLocation,
10. double satSignalPropagationTimeSec)
11. {
12. double omegaDeltatT = Satellite.OMEGA_EARTHS_ROTATION_RATE_RADIANS_PER_SECOND *
13. satSignalPropagationTimeSec;
14.
15. double newX = Math.cos(omegaDeltatT) * satLocation.getX() + Math.sin(omegaDeltatT)*
satLocation.getY();
16. double newY = -1 * Math.sin(omegaDeltatT) * satLocation.getX() + Math.cos(omegaDeltatT)*
satLocation.getY();
17.
18. satLocation.setEcef(newX, newY, satLocation.getZ());
19. }
The applyGeometricRangeCorrection() method is passed the location of the

satellite and the signal propagation time. The propagation time passed into this
method is calculated from the measured pseudorange. The corrections are calcu-
lated using (6.3) and are applied to the satLocation instance passed in to the
method. In practice the geometric range correction per satellite is in the range of
about 80 to 150 meters. Satellites lower on the horizon have further distance to
travel to the handset, and the Earth rotates further than it does for closer satellites;
hence, they have the largest correction applied to them. The corrected satellite loca-
tions in ECEF coordinate along with the magnitude of the correction in meters is
shown here:
PRN: 32 correctedSatLocn:-11501835.93 -11195740.73 21600295.49 correctionSizeMeters: 91.04
PRN: 31 correctedSatLocn: -1452239.96 -19791486.46 17799129.73 correctionSizeMeters: 101.02
PRN: 14 correctedSatLocn: 13580751.29 -14259786.92 17887352.18 correctionSizeMeters: 103.74
PRN: 16 correctedSatLocn: 60349.37 -23829335.30 -11422170.12 correctionSizeMeters: 134.29
PRN: 30 correctedSatLocn: 16300425.99 -8989904.38 18552206.96 correctionSizeMeters: 101.18
PRN: 22 correctedSatLocn: 11669635.47 -23488177.09 -3820602.87 correctionSizeMeters: 139.49
As seen above, the correction in the location is in the vicinity of 100 meters.
Note that if this correction is not applied, the locations calculated will be in error.
For the RINEX sample data set from Miami 3, the average distance of locations
from the ground truth is 2.5 meters, but that average is over 33 meters if geometric
range correction is not applied.
6.3.8 Substituting in a Pseudomeasurement

This step involves checking that there are enough satellites to perform the position
calculation. If there are only three measurements, it puts in a pseudomeasurement
given the initial location. A pseudomeasurement is a fake measurement from the
center of the Earth to the initial location. It allows a location to be calculated when
there are only three measurements available for the location calculation. The
assumption is that the handset is at the altitude provided in the initial location. The
fake satellite is defined at the ECEF coordinates (0, 0, 0) and the range r is given by
r= x 2 + y2 + z 2 (6.17)
where (x, y, z) is the coordinate of the estimated location. The accuracy of the result
produced by this method will be reduced when the initial estimate of the altitude dif-
fers significantly from the altitude of the handset.
Note that since the pseudomeasurement is a direct measurement, it is not sub-
ject to the handset clock offset like a GPS measurement is; when populating the H
matrix, the last column is set to 0.
An alternative to using the altitude in the initial location estimate is to use a digi-
tal elevation model (DEM) of the terrain. The DEM is an accurate model of the
Earth’s surface and provides the ground height for a given latitude and longitude.
6.3.9 Pruning Bad Satellite Measurements

It is possible for the handset to make incorrect measurements for one or more of the
satellites. It only takes one incorrect measurement to cause the position calculation
to fail. Thus, it is important to make every attempt to sanity check the
measurements.
One method to prune bad measurements is by sanity checking the code phase
measurements. This is done by comparing the predicted C/A chips with the mea-
sured chips and discarding the satellites with large inconsistencies. The predicted
range is calculated using the estimate location and (6.2) and also considering the
satellite clock offset. Since the chips reported in the measurements are all affected by
the clock error of the handset, they cannot be compared directly. The relative differ-
ences between the chips are what is important. If the GPS measurements are all
valid, the code phase measurement for each satellite will be offset from the predicted
number of chips for that satellite by the same amount.
In addition, the initial estimated location contains an amount of uncertainty.
The size of this uncertainty combined with the elevation of the individual satellite
determines how far the measured chips may be from the predicted chips and still be
a valid measurement. Invalid measurements can be detected by their deviation from
the median difference between the measured chips and the predicted chips.
6.3.10 Pruning Low Elevation Satellites

The position calculation steps described earlier are required in order to calculate a
correct location. There are some optional steps that may improve the accuracy of a
location and pruning low-elevation satellites is one of them. This step involves cal-
culating the elevation of the satellites that have been measured and removing mea-
surements that are from satellites that are too low on the horizon from the
perspective of the initial location. The satellite elevation mask may be configured,
that is, passed in to the position calculation class, or hardcoded to be a constant 5°.
The size of the elevation mask needs to be considered carefully during system test-
ing. Also consider that satellite measurements should only be pruned if there are
redundant measurements, that is, more than four satellite measurements.
The reason that low-elevation satellites are considered for removal is that they
suffer the most from both ionosphere delay and multipath effects. Due to the low
elevation, the signal from the satellite has much more ionosphere to travel through
than a satellite that is directly overhead, for example. This means that there is more
uncertainty in the measurement. Similarly, the signals are more likely to suffer from
multipath or NLOS effects from objects on the surface of the Earth such as buildings
and natural features.
Whether to prune a satellite needs to be considered carefully because even
though the low elevation satellites may have more measurement error, they can also
significantly affect the DOP.
Once the locations of the satellites have been calculated, the elevation is calcu-
lated as the elevation between two instances of the Wgs84Location class by calling
its elevation() method. The elevation of the satellites for the worked example is
shown here:
PRN: 32 elevation: 28.60
The Java code to prune satellite elevations is in the

pruneSatellitesBasedOnElevation() method. It iterates through the satellites and
calculates the elevation of the satellite from the initial location estimate in line 15.
The satellite elevation is checked against the mask that is defined at the class level on
line 17. Note that it does the checking but does not actually do the pruning. That is
left as a software project in the list at the end of the chapter.
1. /**
2. * This method prunes satellites from the measurement list that are below the elevation
defined by
3. * the satellite elevation mask. The elevation is the elevation from the estimated location
of the
4. * handset to the calculated location of the satellite.
5. *
6. * @param measurement the GPS measurement.
7. * @param satelliteLocations the location of the satellites.
8. * @param estimatedPresentLocation the location to calculate the elevation from.
9. */
10. private void pruneSatellitesBasedOnElevation(GpsMeasurement measurement, Wgs84Coordinate[]
satelliteLocations,
11. Wgs84Coordinate estimatedPresentLocation)
12. {
13. for (int i = 0; i < measurement.getNumSatsMeasured(); i++)
14. {
15. double satElevationRadians = estimatedPresentLocation.eleva-
tion(satelliteLocations[i]);
16.
17. if(Math.toDegrees(satElevationRadians) < this.satelliteElevationMask)
18. {
19. //prune out the satellite because it is below the elevation mask
20. //this sample code does not do the pruning

21. }
22. }
23. }
6.3.11 Pruning Weak Measurements

The handset returns the quality measures associated with each satellite measure-
ment as described in Section 6.1. Those quality measurements are the
carrier-to-noise ratio (C/N0), the multipath indicator, and the pseudorange RMS
error. If they indicate that the measurements are sufficiently weak, then the
measurements may be discarded from the position calculation. The
pruneWeakSatelliteMeasurements() method exists as a stub in the implementation.
6.3.12 Ionosphere Correction

As discussed in Section 3.4, the ionosphere is a significant source of error in the
measurements to individual GPS satellites. The ionosphere is highly variable, so
range errors are difficult to model [6]; however, the single frequency L1 user can use
the ionosphere model to eliminate 50% of the ionosphere errors. The ionosphere
delay varies depending on many factors, including season, time of day, latitude, and
the level of solar activity at the time. The way to account for all of the ionospheric
delay is by using Differential GPS (DGPS) corrections.
The ionospheric propagation delay of the code signals will cause the measured
range to be larger than the actual range to the satellite. This is because the signal is
dispersed by the free electrons in the ionosphere. The delay depends on the angle of
the satellite as that affects the amount of ionosphere through which the signal has to
travel. The delay can be up to 150 meters on the horizon.
The method for the single-frequency user to correct measurements for iono-
sphere was given in (3.5). The ionospheric delay coefficients come from subframes 4
and 5 of the broadcast navigation message. The ionosphere correction method, Ion-
osphere.getIonosphereDelay(), is passed the latitude and longitude of the user’s esti-
mated location on the ground as well as the time and the azimuth and elevation of
the satellite. It simply steps through the equations, with the result being an estimate
of the ionospheric delay in meters. Note that in contrast to the algorithms for calcu-
lating the satellite location, the GPS IS and SS present the equations with the final
step shown first. This means that the first equation implemented in the code is the
one shown as the final step in the description of the algorithm. As you step through
the code line by line from top to bottom, you step through the documented
algorithm description from bottom to top.
The following is an extract of the start of the code which starts by calculating
psi (ψ) on line 1. This is the Earth’s central angle between user position and the
Earth’s projection of the ionospheric intersection point. The next step is to calculate
phi (φ). It is evaluated per the equation in the specification (line 4) and then range
limited to make sure that it is in the range from −0.416 to +0.416 (lines 7–14). Note
that the latitude is converted to semicircles since they are the specified units of φ.
1. double psi = (0.0137/(elevationSemiCircles + 0.11)) - 0.022;
2.
3. double latitudeSemiCirc = Satellite.radsToSemiCircles(Math.toRadians(latitudeDegrees));
4. double phi = latitudeSemiCirc + (psi * Math.cos(azimuthRadians));
5.
6. //phi is limited so it is set to the boundary value if it is outside the range
7. if (phi > +0.416)
8. {
9. phi = +0.416;
10. }
11. if (phi < -0.416)
12. {
13. phi = -0.416;
14. }
15.
16. double lambdaI = Satellite.radsToSemiCircles (Math.toRadians(longitudeDegrees)) +
17. (psi * Math.sin(azimuthRadians)/Math.cos(Satellite.semiCirclesToRadians(phi)));
The ionosphere corrections applied to the satellites measured for the example
are shown next in meters. The corrections are quite small for that particular time. In
addition, none of the satellites are low on the horizon, which would require a larger
correction.
PRN: 32 ionoCorrection: 4.29
6.3.13 Troposphere Correction

As discussed in Chapter 3, the troposphere is another source of error that affects the
range measurement and is a function of the temperature, pressure, and humidity.
One simple model is the Hopfield troposphere model [7], which combines the con-
tribution of the wet and dry atmosphere. For this implementation we do not have a
measurement of the atmosphere at the location of the handset, so we use standard
values for some of the parameters. The ambient air temperature is 15°C, the air
pressure is 101.325 kPa and the vapor pressure is 0.85 kPa. The tropospheric delay
is then calculated in meters as shown in [7]:
2.312 0084
.
d = + (6.18)
−1
sin θ + 194
2
. x 10 sin θ + 06854
2
. x 10 −3
where θ is the elevation of the satellite from the estimated location in radians. The
tropospheric corrections for the satellites in the example are shown here:
PRN: 32 tropoCorrection: 4.99
The class diagram for the troposphere classes are shown in Figure 6.2. The
TroposphereModel class is an abstract class which means that it cannot be
instantiated; only its subclasses can be instantiated. It contains one abstract method,
getTroposphereDelay(). An abstract method is one that all of the subclasses must
implement. Figure 6.2 shows that there is presently only one troposphere model
class: the Hopfield model. It implements getTroposphereDelay().
TroposphereModel
+getTroposphereDelay(in elevation : double) : double
HopfieldTroposphereModel
Figure 6.2 Class diagram for the troposphere classes.
The GPS position calculation class is shown in Figure 6.3. The position calcula-
tion class has an instance of a TroposphereModel as shown. This will actually be a
subclass of the TroposphereModel.
6.3.14 Position Calculation

Equation (6.11) showed the weighted least squares equation. The implementation
described here is the least squares process without the weighting. The position cal-
culation involves iterating until the change from one iteration to the next is suffi-
ciently small. The least squares solution to the equations was shown in (6.11). The
weight matrix W is the inverse of the matrix that has the diagonals set to the eleva-
tion of the satellite from the estimated location.
The least squares estimate of the location x is given by (6.19). The solution iter-
ates until the amount of change in the location becomes sufficiently small.
x = x 0 + x$ (6.19)
The method GpsPositionCalculation.calculatePosition() makes the method

calls to perform the data preparation described in the previous sections and then
invokes the least squares process. The Matrix class has the code to perform the
matrix operations and that is used extensively. The calculatePosition() method
returns a Wgs84Coordinate instance that has the location of the handset or null if
the location could not be calculated. The calculatePosition() method is shown next.
It initially calls the method to perform the position calculation preprocessing steps
discussed previously in this chapter. If that succeeds, then we set up the matrices for
the position calculation. The code is discussed in the context of the following
worked example.
1. public PosCalcResult calculatePosition(GpsMeasurement measurement, RangeMeasurementSet
rangeMeasurements,
2. SatelliteInformation ephemeris, Wgs84Coordinate initialLocation,
3. IonosphereModel iono)
poscalc::GpsPositionCalculation 1 1 TroposphereModel
-tropo : TroposphereModel
+calculatePosition() : Wgs84Coordinate +getTroposphereDelay(in elevation : double) : double
Figure 6.3 Class diagram for the GPS position calculation.

4. {
5. //Calculate the location
6.
7. //call the method to perform the preprocessing
8. Wgs84Coordinate[] satelliteLocations = performPosCalcPreprocessing(measure-
ment,ephemeris,
9. initialLocation, iono);
10. if(satelliteLocations == null)
11. {
12. return null;
13. }
14.
15. //Now lets set up the matrices.
16.
17. //x is the estimate of the location. it is initialized to the initial location and is
updated
18. //each time we go through the iteration loop
19. Matrix x = new Matrix(4,1);
20. x.setElement(0, 0, initialLocation.getX());
21. x.setElement(1, 0, initialLocation.getY());
22. x.setElement(2, 0, initialLocation.getZ());
23. x.setElement(3, 0, 0);
24. //System.out.println(“x: ” + x);
25.
26. //Some variables that are used inside the loop
28.
29. Wgs84Coordinate estimatedPresentLocation = new Wgs84Coordinate();
30. estimatedPresentLocation.setEcef(initialLocation.getX(),initialLocation.getY(),
initialLocation.getZ());
31.
32. //Set up some of the matrices used inside the loop. It is probably not that efficient
33. //to be allocating all of this memory each time this method is invoked so memory
34. //pooling or another mechanism would be better for high throughput applications
35.
36. //H s the geometry matrix
37. Matrix H = null;
38. //p is the delta p matrix
39. Matrix p = null;
40. //xHat is the change to apply to the x matrix
41. Matrix xHat = null;
42. //The residuals
43. Matrix v = null;
44.
45. double variance;
46.
47. //This is the main interation loop
48. do
49. {
50. //Set up the H matrix which is the geometry matrix
51. H = this.setUpHmatrix(measurement, rangeMeasurements, satelliteLocations,
estimatedPresentLocation);
52.
53. Matrix W = this.setUpWmatrix(measurement, rangeMeasurements, satelliteLocations,
54.
55. //Set up the delat p matrix
56. p = this.setUpPmatrix(measurement, rangeMeasurements, satelliteLocations, x,
57.
58. //calculate the new estimate of x = (HtWH)^-1 * HtWP
59.
60. Matrix Ht = H.transpose();
61. Matrix HtW = Ht.multiply(W);
62. Matrix HtWH = HtW.multiply(H);
63. Matrix HtWHinv = HtWH.invert();
64. if(HtWHinv == null)
65. {
66. return null;
67. }
68.
69. Matrix HtWHinvHt = HtWHinv.multiply(Ht);
70. Matrix HtWHinvHtW = HtWHinvHt.multiply(W);
71. xHat = HtWHinvHtW.multiply(p);
72.
73. //xHat is the estimate change this time through the loop now add it to the estimate
74. x = xHat.add(x);
75.
76. //Put this into the WGS 84 coordinate object
77. estimatedPresentLocation.setEcef(x.get(0,0), x.get(1,0), x.get(2,0));

78.
79. //increment the iteration counter. It is used as a last resort to break the iteration
81.
82. //Break out of the loop when the estimate has not changed much or we hit the iteration
limit
83. }
84. while(xHat.norm() > 1 && numberOfIterations < GpsPositionCalculation.MAX_ITERATIONS);
85.
86. //set up the result and return it
87. PosCalcResult result = new PosCalcResult(estimatedPresentLocation);
88. return result;
89. }
0
Considering the example data, x is set to the initial location provided in Section
6.3.2 with the estimated clock error set to 0; this is shown next. This Matrix
instance is initialized in lines 16–19 of the calculatePosition() method.
⎡ 983,04658
. ⎤
⎢−5,662,32388. ⎥
x0 =⎢ ⎥
⎢ 2,756,97422
. ⎥
⎢ ⎥
⎣ 00
. ⎦
The code declares some variables and then enters the main iteration loop on line
48. It then calls the setUpHmatrix() method to set up the H matrix. In order to com-
plete the matrix, we first calculate the range from the estimated location x0 to satel-
lite n using (6.2). The satellite coordinates for the worked example are shown in
Section 6.3.4. The ranges to each satellite are calculated and are shown here:
1
r : 23271479.32
2
r: 20780526.90
3
r: 21483641.96
4
r: 23063820.33
5
r: 22252736.49
6
r: 21799741.86
The geometry matrix H is then calculated using (6.9) and is shown next with the
example data. Note that compared to (6.9), this instance of H has six rows since
there are measurements to six satellites.
⎡− −11501772.43 − 983046.58 −
. + 566232388
1119580597 .
−
21600295.49 − 2756974.22
2.99792458 × 10 8 ⎤
⎢ 23271479.32 23271479.32 23271479.32 ⎥
⎢ −142139.21 − 983046.58 . + 566232388
1979149385 . 17799129.73 − 2756974.22 ⎥
⎢ − − − 2.99792458 × 10 8 ⎥
2078052690
⎢ 13580826 . 2078052690. 2078052690
.
.41 − 983046.58 −14259715.37 + 566232388
. 17887352.18 − 2756974.22 ⎥
⎢ − − − 2.99792458 × 10 8 ⎥
H=⎢ 2148364196. 2148364196
. 2148364196. ⎥
⎢ − 60483.65 − 983046.58 −
−23829334.95 + 5662323.88
−
−11422170.12 − 2756974.22
2.99792458 × 10 8 ⎥
⎢ 23063820.33 23063820.33 23063820.33 ⎥
⎢ 16300474.85 − 983046.58 −898981578
. + 566232388
. . − 2756974.22
1855220696 ⎥
⎢ − − − 2.99792458 × 10 8 ⎥
22252736.49 22252736.49 22252736.49
⎢ 11669760.39 − 983046.58 −23488115.02 + 566232388
. −3820602.87 − 2756974.22 ⎥
⎢− − − 2.99792458 × 10 8 ⎥
⎣ 2179974186. 2179974186
. 2179974186. ⎦
and the resulting H matrix for the first iteration is shown as the output of the fol-
lowing Matrix.toString() method. Note that the H matrix is recalculated each itera-
tion as the location is refined.
H: Matrix size: (6, 4)

0.5364885635911322 0.23777675557667408 −0.8097173801045364 2.99792458E8
0.11719079854128966 0.679923211043823 −0.7238582346158065 2.99792458E8
−0.586385899354948 0.40018647925537915 -0.7042743491416346 2.99792458E8
0.04000626095527544 0.787684397310103 0.6147786506691642 2.99792458E8
−0.6883368890305347 0.14953578843670645 −0.7098108023807316 2.99792458E8
−0.4902163042645664 0.8177093713517571 0.30172729249556474 2.99792458E8
The code to calculate H is shown next. The setUpHMatrix() method sets up the
matrix and returns it. The matrix is allocated on line 13 with the number of rows to
be the number of measurements and four columns. The method then loops through
and calculates the row for each measurement. On line 16 it calculates the range
from the estimated location of the handset to the satellite and then fills in the rest of
the elements of the H matrix.
1. /**
2. * This method sets up the H matrix and returns it.
3. *
4. * @param measurement the measurement from the satellites.
5. * @param satelliteLoc the location of the satellites.
6. * @param handsetLocEstimate the estimated location of the handset.
7. *
8. * @return the H matrix.
9. */
10. private Matrix setUpHmatrix(GpsMeasurement measurement, Wgs84Coordinate[] satelliteLoc,
11. Wgs84Coordinate handsetLocEstimate)
12. {
13. Matrix H = new Matrix(measurement.getNumSatsMeasured(), 4);
15. {
16. double satRange = handsetLocEstimate.distanceTo (satelliteLoc[i]);
17. H.setElement(i, 0, -1 * (satelliteLoc[i].getX() -
handsetLocEstimate.getX())/satRange);
18. H.setElement(i, 1, -1 * (satelliteLoc[i].getY() -
handsetLocEstimate.getY())/satRange);
19. H.setElement(i, 2, -1 * (satelliteLoc[i].getZ() -
handsetLocEstimate.getZ())/satRange);
20. H.setElement(i, 3, Satellite.C_SPEED_OF_LIGHT);
21. }
22. return H;
23. }
The weight matrix W is calculated using a satellite elevation model, where

lower elevation satellites are modeled with more error. The intermediate matrix C is
calculated with the diagonal element set to the cosecant of the elevation and this C
matrix is inverted.
This is shown in the code snippet from the setUpWMatrix() method next. The
intermediate matrix C is created as a square matrix whose size is dependent on the
overall number of satellite measurements. The method then iterates through each
row and calculates the value to go into the diagonal as the cosecant (one over sine).
The result is the matrix W, which is the result of inverting C (line 9).
1. Matrix C = new Matrix(measurement.getNumSatsMeasured(),

2. measurement.getNumSatsMeasured());
3.
5. {
6. double satElevation = handsetLocEstimate.elevation(satelliteLoc[i]);
7. C.setElement(i, i, 1/Math.sin(satElevation));
8. }
9. Matrix W = C.invert();
The weight matrix W is updated each time through the loop in the
setUpWMatrix() method. Its values from the first iteration are shown here:
W: Matrix size: (6, 6)
0.4787 0.0 0.0 0.0 0.0 0.0
0.0 0.8990 0.0 0.0 0.0 0.0
0.0 0.0 0.7506 0.0 0.0 0.0
0.0 0.0 0.0 0.4276 0.0 0.0
0.0 0.0 0.0 0.0 0.5460 0.0
0.0 0.0 0.0 0.0 0.0 0.6715
The next matrix to set up is the Δρ matrix as defined by (6.8) and is shown next
with the sample data. Similar to the previous matrix, this one also has six rows
because there are six satellite measurements.
⎡(23,318,037.10 + 000028607
. × c ) − (23,271,47932
. + 00. × c) ⎤
⎢ ⎥
⎢(20,928,086.44 − 000005484
. × c ) − (20,780,52690 . × c) ⎥
. + 00
⎢(2165 . − 000014040
, 7,79322 . × c ) − (21,483,64196
. + 00. × c) ⎥
Δρ = ⎢ ⎥
⎢(23,168,462.59 + 000006731
. × c ) − (23,063,82033 . × c) ⎥
. + 00
⎢ ⎥
⎢(22,345,695.94 + 000013265
. × c ) − (22,252,736.49 + 00. × c )⎥
⎢ ⎥
⎣(21865
, . + 00
,20873 . 0020342 × c ) − (21799
, . × c) ⎦
. + 00
,74186
and the resulting Δρ matrix becomes:

p: Matrix size: (6, 1)
132308.76099038124
131109.64953574538
132051.34105573595
124807.03071095422
132715.95096670836
126439.82961118594
The code to calculate Δρ is shown next. It sets up the p matrix on line 12 and
goes through each satellite in the measurement. For each measurement, it calculates
out the result using (6.8).
1. /**
2. * This method sets up and returns the p matrix.
3. *
4. * @param measurement the satellite matrix
5. * @param satelliteLoc the location so the satellites
6. * @param x the current estimate of x.
7. * @param handsetLocEstimate the current estimate of the handsets location.
8. */
9. private Matrix setUpPmatrix(GpsMeasurement measurement, Wgs84Coordinate[] satelliteLoc,
Matrix x,
10. Wgs84Coordinate handsetLocEstimate)
11. {
12. Matrix p = new Matrix(measurement.getNumSatsMeasured(), 1);
14. {
15. double estimatedSatRange = handsetLocEstimate.distanceTo(satelliteLoc[i]);
16. SatGpsMeasurement satMeasurement = measurement.getSatelliteMeasurement(i);
17.
18. p.setElement(i, 0,
19. (satMeasurement.getCorrectedPseudorange() -
satMeasurement.getAssociatedSatClockErrorMeters()) -
20. (estimatedSatRange + (x.get(3, 0) * Satellite.C_SPEED_OF_LIGHT)));
21. }
22. return p;
23. }
Now, returning to the position calculation method calculatePosition() shown

earlier, in lines 58–74 it steps through the matrix operations required to determine
the amount that the estimated present location and the handset clock error (x) has
to change as specified by (6.11). At line 74, it adds the change of location ( x$ ) to the
current estimated location as specified by (6.23). To complete this iteration, some
quality measures are calculated (discussed in the next section) and the loop counter
is incremented. As can be seen on line 84, the loop will terminate if the norm of x$ is
less than 1 (if the iteration results in change in the estimated location of less than 1
meter). There is an additional loop guard condition to check whether a maximum
number of iterations have been completed, in which case the iteration process
completes.
The ECEF location calculated by the position calculation is:
Calculated location: lat: 25.73277 long: -80.16017 alt: -0.55
x: 982512.59 y: -5664663.24 z: 2752421.97
This distance between the calculated location and the ground truth reported for
the Miami 3 reference station is 4.97 meters. The clock error of the receiver is
0.000432 second, and the least squares process completed in two iterations.
6.3.15 Uncertainty
When considering any calculated location, it is very important to understand the
uncertainty and the confidence level of the uncertainty. The ellipse calculated by the
least squares process is related to the geometry of the satellites and the handset and
also the quality of the individual measurements that the handset makes. The
semimajor axis lies in the direction of the lowest precision (or highest deviation),
and the semiminor axis lies in the direction of the highest precision (lowest devia-
tion). A model of a horizontal error ellipse is shown in Figure 6.4. The ellipse is off-
set from North by the orientation defined by the angle β. The semimajor axis is in
the direction of the largest deviation σmax and the semiminor axis is in the direction
of σmin.
The error ellipse is calculated using the VCV matrix [8]. To calculate it, we cal-
culate the covariance matrix of the parameters as shown in
( )
−1
C x$ = H T WH (6.20)
This is then converted to the ENH coordinate system using
C xlocal
$ = RC x$ R T (6.21)
where R is the rotation defined in (6.22)

σmax
σmin
Figure 6.4 Error ellipse.
⎡− sin φ cos λ − sin φ sin λ cos φ⎤

R = ⎢ − sin λ cos λ 0 ⎥ (6.22)
⎢ ⎥
⎢⎣ cos φ cos λ cos φ sin λ sin φ ⎥⎦
where φ is the latitude and λ is the longitude. The resulting local covariance matrix
is given by
⎡ σ e2 σ en σ eh ⎤
C xlocal
$ = ⎢⎢σ ne σ 2
n σ nh ⎥⎥ (6.23)
⎢⎣σ he
2
σ 2
hn σ h2 ⎥⎦
The VCV is then calculated by multiplying the variance factor (discussed in Sec-
tion 6.3.16.2) by the covariance matrix. The altitude uncertainty is then calculated
at one standard deviation as the square root of the up element as shown in
altUncert = σ 2h (6.24)
The VCV for the two-dimensional horizontal error ellipse is calculated from the
2 × 2 submatrix of the covariance matrix starting from its upper left hand corner.
Thus, the VCV becomes that shown in
⎡σ2 σ en ⎤
VCV = ⎢ e (6.25)
⎣σ ne σ 2n ⎥⎦
The orientation of the ellipse (β) can be calculated using

1 ⎛ 2σ ⎞
β= tan −1 ⎜ 2 en 2 ⎟ (6.26)
2 ⎝σn − σe ⎠
The major axis at 39.4% confidence is given by
1⎛ 2 2 ⎞
(σ ) + 4( σ en ) ⎟
2
semiMajor = ⎜σ e + σ n +
2 2
− σ 2n (6.27)
2⎝ ⎠
e
and the minor axis is given by
1⎛ 2 2 ⎞
(σ ) + 4( σ en ) ⎟
2
semiMinor = ⎜σ e + σ n −
2 2
− σ 2n (6.28)
2⎝ ⎠
e
For the worked example, the uncertainty is calculated as shown here. Note that
it is not scaled but is shown at the default confidence of 39.4%.
altUncert:10.088292696055293
orientation:6.913790565263772
semiMajor:3.8018920778395326
semiMinor:2.9511686165097015
6.3.16 Quality Measures

There are several quality measures that can be used to assess the quality of the posi-
tion calculation. In this section, the residuals and the DOP are considered.
6.3.16.1 Residuals
The residuals are a measure of how much the observations need to be adjusted to fit
the calculated location [8]. They are calculated as shown in
v$ = Hx + Δρ (6.29)
The residuals are calculated in the GpsPositionCalculation.calculateResiduals()

method and are as follows after the completion of the least squares:
v: Matrix size: (6, 1)
1.616757207792696
-0.3873202279250576
-1.231445493755364
-2.923513495394535
0.06279228269319126
2.5547657214301056
The position calculation sanity checks them by making sure that the sum of the
squared residuals (SSR) is less than a preconfigured maximum value. For the given
data, the SSR is 18.46.
6.3.16.2 Variance Factor

The variance factor [8] is defined by
v$ T Wv$
vf = (6.30)
n −u
where v$ is the residuals, n is the number of observations, and u is the number of

unknowns that we are solving for (which is 4). The variance factor is a measure of
the quality of the result and results may be discarded depending on the value of this
factor. It is expected to be a small number (around 1).
6.3.16.3 Dilution of Precision

The DOP is a measure of the geometry of the satellites for which the handset has
measurements. A smaller number indicates better geometry and it is calculated as
specified in (6.32).
The different forms of the DOP equation are outlined in [2]. The DOP measures
are calculated from the covariance matrix, which was shown in (6.20). Equation
(6.31) shows the equations to calculate the PDOP and the HDOP. The subscript
numbers represent the row and column index within the covariance matrix
PDOP = C x$ 11 + C x$ 22 + C x$ 33
(6.31)
HDOP = C x$ 11 + C x$ 22
The PDOP and HDOP values for the example are shown here:
pdop: 3.59
hdop: 3.29
6.4 Doppler-Based Position Calculation
The Doppler shift measurements made by a handset allow a position to be calcu-

lated directly. A code phase-based position calculation is far more accurate [9], but
the Doppler shift-based position calculation does not suffer from the millisecond
ambiguity problem. The millisecond ambiguity problem arises because we only
know about the code phase chips within the present millisecond.
There are situations where the initial location will be unknown. When the
server is performing the calculation, this may be because the cell is missing from the
cell database, or the subscriber is using the SLP and has roamed to another network
whose cells are not in the database. In this situation, the position is determined using
a two-step process. The initial step involves calculating the location of the handset
using Doppler shift measurements. This Doppler shift-based location is then used as
the seed location for the code phase-based location calculation described in Section
6.3. The Doppler shift-based location generally calculates the handset within 5 to
10 kilometers and is inferior to a location calculated based on range
measurements [9].
6.4 Doppler-Based Position Calculation 147
A GPS antenna in open-sky on the roof of our laboratory logs GPS measure-
ments on a regular basis. The statistics for the horizontal error (distance from
ground truth) for calculating a code phase-based location for all of the records for
one day are:
Total records: 155,043 average: 2.38 stdev: 1.52 minimum: 0.00 maximum: 24.68
The statistics for calculating a Doppler shift-based location are:

Total records: 155,043 average: 796.8 stdev: 255.2 minimum: 174.6 maximum: 5,691.4
Doppler shift occurs because the GPS signal travels at the speed of light and the
rate of change of the range between the satellite and the receiver stretches or com-
presses the wavelength that is effectively measured at the receiver. When a satellite is
approaching the receiver, the frequency will be increased slightly and when the sat-
ellite is receding, the frequency is reduced. We assume a stationary receiver and,
using the measured Doppler shift values from the satellites, can calculate a location.
The difference between a Doppler shift-based position calculation and a code
phase-based calculation is that for the code phase calculation, H and Δρ are sourced
from the position of the satellites and the measured code phases. Alternatively, for
the Doppler shift-based calculation, H and Δρ are sourced from the velocity of the
satellites and the measured Doppler shift. The complete Doppler shift-based posi-
tion calculation is outlined by Hill [9].
For the following description, I have kept the same notation as used for the code
phase-based position calculation. The geometry matrix H is set up as shown in
⎡ v1x v1y v1z s1 ⎤

⎢ 2 ⎥
⎢v x v y2 v z2 s2 ⎥
H=⎢ 3 (6.32)
v v y3 v z3 s3 ⎥
⎢ x ⎥
⎢ v x4 v y4 v z4 s4 ⎥
⎣ ⎦
n n
where (vx, vy, vz) is the velocity of satellite n and ||s || is the norm of the location of
satellite n, s (xs, ys, zs)n.
The velocity of the satellite can be calculated using the formulas in [10]. The
velocity is calculated in the perifocal coordinate system (inertial) and then converted
back to the ECEF coordinate system. The polar equation of a conic is used to deter-
mine ρ (the semilatus rectum). A rearrangement of 1.5-4 from [10] is shown in
ρ = r(1 + e cos v) (6.33)
where r is the norm of the difference between the location of the satellite and the
handset as given in (6.2), e is the eccentricity from the satellite ephemeris, and v is
the true anomaly at epoch from the ephemeris. We can then use equation 2.5-4 from
[10] to derive (6.34), which gives the velocity with respect to the P and Q unit vec-
tors of the perifocal coordinate system.
μ
vp = (i sin v)
ρ
(6.34)
μ
vq = ( e + cos v)
ρ
where μ is the WGS 84 universal gravitational parameter. We then convert velocity

from the perifocal coordinate frame to the geocentric-equatorial frame (vi, vj, vk)
using the rotation matrix R as shown in
⎡v i ⎤ ⎡v p ⎤
⎢ ⎥ ~⎢ ⎥
⎢v j ⎥ = R ⎢v q ⎥ (6.35)
⎢⎣v k ⎥⎦ ⎢⎣v w ⎥⎦
Note that vw is 0 because we are working in a perifocal coordinate system and

the W axis is in the orbit plane. The velocity of the satellite is 0 in this direction. The
rotation matrix R is given by
⎡cos Ω cos ω − sin Ω sin ω cos i − cos Ω sin ω − sin Ω cos ω cos i sin Ω sin i ⎤
R = ⎢sin Ω cos ω + cos Ω sin ω cos i − sin Ω sin ω + cos Ω cos ω cos i − cos Ω sin i⎥ (6.36)
⎢ ⎥
⎢⎣ sin ω sin i cos ω sin i cos i ⎥⎦
where ω is the argument of perigee from the ephemeris, Ω is the longitude of the
ascending node which is calculated form the ephemeris, and i is the corrected incli-
nation which is also calculated from the ephemeris.
Combining (6.39) and (6.40), it is possible to multiply this out to determine an
expression for vi, vj, and vk. We are still in the geocentric equatorial reference frame
and vi, vj, and vk expanded are shown in
v i = ( cos Ω cos ω − sin Ω sin ω cos i)v p + ( − cos Ω sin ω − sin Ω cos ω cos i)v q + 0
v j = (sin Ω cos ω + cos Ω sin ω cos i)v p + ( − sin Ω sin ω + cos Ω cos ω cos i)v q + 0 (6.37)
v k = (sin ω sin i)v p + ( cos ω sin i)v q + 0
Note that the last term is 0 because vw is zero. Finally, we need to convert the
velocity back to the ECEF reference frame (vx, vy, vz) from the present inertial refer-
ence frame. This is given by
⎡v x ⎤ ⎡v i ⎤ ⎡− Ω & y⎤
⎢ ⎥ ⎢ ⎥ ⎢ & ⎥
⎢v y ⎥ = ⎢v j ⎥ − ⎢ Ωx ⎥ (6.38)
⎢v z ⎥ ⎢v ⎥ ⎢⎣ 0 ⎥⎦
⎣ ⎦ ⎣ k⎦
The Δx matrix has the same meaning as used for the code phase-based calcula-
tion as shown in (6.10). The significant difference is that it does not need to be
within 100 kilometers of the initial location and it is quite reasonable to set it to (0,
0, 0).
The matrix should probably be renamed, but I have left it with the same name
for consistency with the code phase least squares calculation. It is modified as
shown in
⎡ ΔF r1 ⎤
⎢ F c × r + s ⋅v +tu
1 1 1
(s 1
⎥)
−r
⎢ t ⎥
⎢ ΔF r2 ⎥
⎢
F
c × r 2 + s 2 ⋅ v2 + t u (s2 − r ⎥ )
Δρ = ⎢ 3 t ⎥ (6.39)
⎢ ΔF ⎥
⎢ r c × r 3 + s 3 ⋅ v3 + t u
⎢ Ft
( s3 − r ⎥
⎥
)
⎢ 4 ⎥
⎢ ΔF r c × r 4 + s 4 ⋅ v 4 + t u
( s4 − r ⎥ )
⎢⎣ Ft ⎥⎦
where ΔFrn is the measured Doppler shift for satellite n, Ft is the transmitted fre-
quency which is 1,575.42 MHz for GPS L1, rn is the range from satellite n to the
user as specified by (6.2), sn is the ECEF coordinates (x,y,z) of satellite n, vn is the x,
y, and z components of the velocity for satellite n, tu is the receiver clock error, and
||sn|| is the norm of the location of satellite n.
The least squares defined by (6.11) is then used to calculate the location of the
handset.
6.5 Hybrid Position Calculation
The position calculation discussed in the previous sections describes calculating the
position using GPS measurements only. There are many situations where a handset
may not be able to make measurements to at least four satellites. In these situations,
it is helpful to include range measurements from other sources. The primary differ-
ence between range measurements and GPS measurements is that they are not sub-
ject to the clock offset against GPS time. When range measurements are available,
they are included in the calculation by modifying the H matrix so that the fourth
column is 0. This is set to 0 because the measurement is not subject to clock error.
Hybrid position calculation is discussed in detail in Chapter 8.
1. The position calculation code does not prune any measurements when it
determines that they are bad (for example, from an unhealthy satellite or a
low-elevation satellite), it just aborts the calculation. Enhance the code so
that it has a mechanism to prune measurements from unhealthy satellites.
One way to do it may be to mark the satellite measurement as being invalid
and then check whether the measurement is valid before putting into the
matrices for the least squares process.
2. The SatelliteGpsMeasurement.calculateApproximateSignalPropagationTime()
method over uses the Java Math.toRadians() and Math.toDegrees()
methods to do conversions to and from radians. Improve the method so that
it does any required conversions to radians up front and then works in
radians.
3. During the position calculation, some of the required information is
calculated multiple times, for example, the satellite elevations are calculated
in several places. Update the code so that the satellite elevations are captured
the first time that they are calculated so that the information can be reused.
4. Enhance the code to perform the position calculation using the code phase
measurements instead of the pseudoranges. When creating the GPS
measurement from the RINEX file, convert the pseudoranges to code phases
and then use that as input to the position calculation. The position
calculation will need to be modified to solve the millisecond ambiguity
problem.
5. The Satellite.calculateEccentricAnomaly method does not handle the case
where the iterative solution does not converge. Update the code so that this
case is handled correctly.
6. Add some additional troposphere models. They should extend the
TroposphereModel abstract class. Modify the GpsPositionCalculation class
so that it is passed in an instance of the troposphere model and uses that one
for the position calculation. Compare the accuracy of some of the different
models.
7. The GpsPositionCalculation.calculatePosition() method contains the code
to perform the calculate the location of the handset and return the result. It
calculates a lot of other information such as PDOP and the SSR. Enhance the
code so that it returns an object that contains the important details about the
calculation.
8. Update the position calculation to be a two-step process. It should initially
perform a location calculation using the Doppler measurements in order to
determine the approximate location. It can then use that location as input to
the code phase calculation in order to determine an accurate location.
9. Implement the Doppler shift-based position calculation described in
Section 6.4.
References
[1] Kaplan, E. D., and J. L. Leva, “Fundamentals of Satellite Navigation,” in Understanding

GPS: Principles and Applications, 2nd ed., E. D. Kaplan and C. J. Hegarty, (eds.),
Norwood, MA: Artech House, 2006.
[2] Axelrad, P., and R. Brown, “GPS Navigation Algorithms,” in Global Positioning System:
Theory and Applications, Vol. 1, B. Parkinson et al., (eds.), Washington, D.C.: American
Institute of Aeronautics and Astronautics, Inc., 1996.
[3] SOPAC, Scripps Orbit and Permanent Array Centre, http://sopac.ucsd.edu/.
CA, 2004.
Signal Specification, 2nd ed., June 2005.
[6] Klobuchar, J. A., “Ionospheric Effects on GPS,” in Global Positioning System: Theory and
Applications, Vol. 1, B. Parkinson et al., (eds.), Washington, D.C.: American Institute of
Aeronautics and Astronautics, Inc. 1996.
[7] Spliker, J. J., “Tropospheric Effects on GPS,” in Global Positioning System: Theory and
Applications, Vol. 1, B. Parkinson et al., (eds.), Washington, D.C.: American Institute of
Aeronautics and Astronautics, Inc., 1996.
[8] Harvey, B. R., Practical Least Squares for Statistics and Surveyors, Monograph 13, Univer-
sity of New South Wales, School of Geomatic Engineering, 1998.
[9] Hill, J., 2001, “The Principle of a Snapshot Navigation Solution Based on Doppler Shift,”
Proceedings of ION GPS 2001, Salt Lake City, UT, September 11–14, 2001.
[10] Bate, R., D. Mueller, and J. E. White, Fundamentals of Astrodynamics, New York: Dover
Publications, 1971.
CHAPTER 7
GPS Position Calculation with Time

Recovery
In an unsynchronized network, when operating in handset-assisted mode, an A-GPS
handset may not know the GPS time well. The LS is normally synchronized to GPS
and can provide the handset with reference time, but that may be seconds away
from the time on the LS by the time that it gets through the network to the handset.
GPS time recovery is a way that the GPS time can be determined as part of the
position calculation solution. In this chapter, time recovery is introduced and two
different algorithms are discussed: iterative time recovery and integrated time
recovery. Results of the two different methods are compared, accuracy and perfor-
mance of both methods are reported, and the implementation of iterative time
recovery is outlined.
7.1 The Time Determination Problem
A-GPS handsets have been shown to report time that is several seconds away from
the true GPS time. In addition, network vendors have reported that they have hand-
sets that may not know the GPS time well when operating in handset-assisted
A-GPS mode.
This is not a limitation of the handset, but is due to the way that hand-
set-assisted GPS works. In this mode, the handset generally requests the GPS acqui-
sition assistance and reference time assistance data types from the LS. The server is
synchronized to UTC time using an NTP server and can calculate accurately GPS
time using the UTC model. It then uses this time to calculate the acquisition assis-
tance data and also complete the reference time assistance data type. The hand-
set-assisted message flow was discussed in Chapter 5.
The handset may use the reference time to synchronize its clock. As mentioned
in Chapter 3, the LS will generally advance the time by a configured amount to
improve that accuracy of the reference time to the handsets in the network. There
will always be some variability in the network latency and the handset that synchro-
nizes its clock using the received reference time data type may be several seconds in
error from true GPS time. This time error is the clock offset between the server and
the handset.
When the handset receives the assistance data, it locks onto the satellites using
the acquisition assistance information and returns the measured code phases and
Doppler shift measurements to the LS. The measurements that the LS receives were
described in Chapters 5 and 6. When the LS receives the measurements from the
153
154 GPS Position Calculation with Time Recovery
handset, it performs a position calculation similar to that discussed in detail in

Chapter 6.
Table 7.1 shows the effects of incorrect GPS time on the accuracy of the position
calculation with different numbers of satellites in the measurements. A GPS antenna
in open-sky conditions on the roof of the laboratory is connected to a NovAtel GPS
receiver that logs ephemeris and other subframe information on regular intervals. It
also logs GPS measurements each second. The data used for the results given in the
table are 30,000 measurements captured during January 2007. The first group of
rows in the table are results for all visible satellites in each measurement and the
rows after that are for the specified number of measurements. The individual satel-
lite measurements used within each measurement are selected randomly. In order to
have a measurement of 6 satellites, for example, the open-sky measurement is used
and 6 of the satellites are randomly chosen from all of those in view. If there are
fewer than 6 satellites in view for the measurement, it is discarded.
Table 7.1 shows the results of the position calculation accuracy by pruning the
number of satellites down to the number specified in the first column. The seed loca-
tion provided to the PCF is 1,000 meters from the ground truth in a horizontal
direction and 100 meters in the altitude direction. The second column shows the
time in seconds that the GPS measurements are manipulated by before being pro-
vided to the GPS PCF. This time manipulation is to simulate error in the time
reported by a handset. The results are shown in the third column as average and
standard deviations in meters from the ground truth of the receiver, and in the
fourth column the 67 and 95 percentile values are listed. The fifth column shows the
yield.
Table 7.1 shows that there is a significant effect on the position calculation
accuracy due to an offset (or error) in the measured time from true GPS time (or the
clock offset between the server and the handset). As the amount of error in the time
increases, the accuracy and yield of the location decrease. The error is even more
significant when there are fewer satellites.
In order to solve the problem in which the handset does not know the time accu-
rately, the server needs to employ a time recovery algorithm [1]. The aim is to calcu-
late the GPS time at the instant the measurements were made. This can be achieved
if there is sufficient redundancy in the measurements. Generally, for time recovery
to work successfully, at least one redundant measurement is needed above the mini-
mum, that is, a minimum of five satellite measurements; that is because an addi-
tional measurement is needed to solve for the additional unknown, which is the
clock offset between the server and the handset.
Iterative time recovery seems to be the simplest method to use on an existing
implementation. The LS iteratively runs the position calculation over a configured
time window size and chooses the best result. The best result is the one with the
smallest sum of the squared residuals (SSR). The iterative time recovery is relatively
easy to implement because it requires no changes to the least squares equations. A
bracketing minimization function allows the position calculation to converge on the
minimum more quickly than a brute force method [2]. Despite this optimized
search, performance (and CPU usage) is a problem due to the large number of posi-
tion calculations required for a single location fix as shown in the next section.
7.1 The Time Determination Problem 155
Table 7.1 Position Calculation Accuracy for Different GPS Time Offset Values
Time Offset Distance from
Applied to Ground Truth in Distance from
Number Measured Time Meters (Average/ Ground Truth
of Satellites in Seconds Standard Deviations) in Meters 67%/95% Yield %
All visible 0 2.29/1.41 2.89/4.76 100.0
All visible 0.5 253.07/88.52 318.87/526.39 100.0
All visible 1 511.54/175.41 644.54/1,064 99.22
All visible 1.5 811.66/252.72 1,022.69/1,688.25 70.23
All visible 2 1,342.00/472.16 1,490.05/2,185.38 38.43
All visible 5 4,966.28/2,842.40 4,755.21/9,070.94 19.52
All visible 10 N/A N/A 0
8 0 2.58/2.15 3.25/5.37 100.0
8 0.5 253.59/87.89 319.52/527.47 100.0
8 1 530.83/221.27 668.85/1,104.13 99.86
8 1.5 852.56/333.18 1,074.23/1,773.32 70.50
8 2 1,273.65/435.84 1,455.02/1,956.28 38.99
8 5 4,153.86/855.50 4,409.81/5,035.61 3.41
8 10 N/A N/A 0
7 0 2.78/2.53 3.5/5.78 100.0
7 0.5 291.84/132.50 367.72/607.03 100.0
7 1 591.73/262.53 745.58/1,230.8 97.82
7 1.5 948.25/401.82 1,194.8/1,972.36 73.89
7 2 1,422.61/528.71 1,588.79/2,227.87 43.22
7 5 4,650.41/1,168.25 5,211.86/6,137.66 8.91
7 10 14,576.99/5,027.87 15,686.83/20,991.78 0.38
6 0 3.37/3.62 4.25/7.01 100.0
6 0.5 339.49/181.81 427.76/706.14 100.0
6 1 699.21/361.95 881/1454.36 94.39
6 1.5 1,122.79/572.13 1,414.72/2,335.4 71.79
6 2 1,574.74/710.52 1,751.51/2,650.04 56.77
6 5 4,767.80/1,776.79 5,284.06/7,199.38 17.36
6 10 10,759.19/2,700.84 11,074.06/16,797.30 6.53
5 0 4.72/7.12 5.95/9.82 99.78
5 0.5 435.50/337.79 548.73/905.84 99.79
5 1 900.49/677.78 1,134.62/1,873.02 91.69
5 1.5 1,382.59/987.48 1,742.06/2,875.79 79.10
5 2 1,842.83/1,242.08 1,940.79/3,605.00 69.19
5 5 4,991.21/2,891.41 5,230.67/9,002.57 38.53
5 10 11,186.99/6,113.45 11,103.05/20,016.51 24.76
Integrated time recovery alters the least squares process by adding an additional
unknown for which to solve. This additional unknown is the offset in time between
the server and the handset. It is called the recovery offset, or gross time error.
The integrated time recovery method proved to have a comparable accuracy to

the iterative method, but has a negligible effect on the performance of the PCF.
Glennon [3] also found that the integrated time recovery algorithm performed well.
In Section 7.2, the iterative time recovery is discussed, accuracy and perfor-
mance results are provided, and the implementation is outlined. Following that, the
integrated time recovery is analyzed.
7.2 Iterative Time Recovery
Iterative time recovery consists of invoking the calculation at discrete time intervals
and choosing the result that minimizes the sum of the squared residuals (SSR) [1].
The SSR is a measure of the quality of the measurements used for the position calcu-
lation and was discussed in Chapter 6.
The position calculation is performed within a configured time window. For
example, if the handsets are known to be within 2 seconds of the GPS time, then the
position calculation is performed for the range of the measured time minus 2 sec-
onds to the measured time plus 2 seconds. The least squares process defined in
Chapter 6 is called repeatedly for different times and the results are stored and SSRs
are compared. The times are chosen within the specified time window relative to the
time reported in the GPS measurement.
Minimizing the SSR for any particular measurement produces a near optimal
result, provided that the granularity of times chosen to perform the position calcula-
tion are sufficiently small. Figure 7.1 shows the location error and the SSR for a typ-
ical GPS measurement over a 7-second time period (3.5 seconds on each side of the
measured time). The graphs in Figure 7.1 shows that the SSR follows a smooth
curve and the location error is minimized very close to the point where the SSR is at
a minimum.
The bracketing search implemented is loosely based on the numerical
minimization function in Chapter 10 of Press et al. [2]. The only assumption that
this search algorithm makes is that the curve is smooth with a single minimum. This
algorithm finds the minimum regardless of where the search space is relative to the
minimum (provided that the minimum is within the search space).
The initial bracketing starts with a coarse time search to find the earliest and lat-
est time where a location can be calculated within the overall search window. This
coarse search starts from each end of the supplied search window in order to find
the first time (relative to that end of the search window) where a successful location
is calculated. These initial “bracketed” end points are defined as a and c. The loca-
tion is then calculated at point b, which is halfway between a and c.
Two more position calculations are then performed for points d (halfway
between a and b) and e (halfway between b and c). If d is less than e, then the search
is recursively invoked using points a, d, and b as input. Alternatively, if d is greater
than e, the next recursive search is performed using points b, e, and c (these become
a, b, and c input to the next search). Alternatively, the points a, d, and b are input to
the next search. Figure 7.2(a) illustrates the selection of points a, b, c, d, and e.
The search is complete when the points a and b are sufficiently close to each
other in time as determined by a defined stop interval in seconds.
Location error by time (search window is 3.5 seconds each side of measured)
1600
1400
1200
Error (meters)
1000
800
600
400
200
0
Time
(a)
SSR by time (search window is 3.5 seconds each side of measured)

1.80E+07
1.60E+07
1.40E+07
1.20E+07
1.00E+07
SSR
8.00E+06
6.00E+06
4.00E+06
2.00E+06
0.00E+00
Time
(b)
Figure 7.1 (a, b) SSR and location accuracy over a 7-second period.
Figure 7.2 shows the three different cases that occur depending on where the
search window is. In Figure 7.2(a), the entire SSR curve is within the search win-
dow. In Figure 7.2(b) the search window occurs such that the minimum is included
within the curve, but it is very close to one end of the search window. This minimum
could be close to either end of the search window. In Figure 7.2(c) the search win-
dow does not include the true minimum, so the time bias estimation discussed in this
section will return the minimum that is within the search window.
The minimization is controlled by two parameters:
• The size of the time window to search each side of the measured time;
• The time resolution at which a and b are deemed to be sufficiently close in
time order to terminate the search.
c
a
SSR
e
d
Time
(a)
e
SSR
a d
Time
(b)
e
SSR
b
d
a
Time
(c)
Figure 7.2 SSR minimization algorithm: (a) the entire curve is within the search window, (b) part
of the curve is within the search window, including the minima, and (c) part of the curve is within
the search window not including the minima.
The iterative time recovery is implemented in the Java example code. The
calcPositionIterativeTimeRecovery() method in the GpsPositionCalculation class is
called to perform the time recovery. It does the high-level processing of the time
recovery algorithm and calls the calculatePosition() method to calculate the loca-
tion of the handset for each given time. The search window size and the stop resolu-
tion are passed into the method and used by the bracketing search. A segment of the
calcPositionIterativeTimeRecovery() method is shown next. The time recovery

method starts by establishing the bounds of the search (lines 3–4) so that the algo-
rithm searches each side of the time reported in the measurement. It then creates a
step size to use for determining the earliest and latest possible location result (lines
7–12). Lines 16–28 determine the earliest time that the location can be calculated. It
starts at the earliest possible time as defined by the size of the window (line 17) and
performs a position calculation (line 21) until it gets a successful result or does not
get a result at all for the time window; each time that the position calculation fails,
the time is stepped forward (line 27). If the early search ends up calculating a loca-
tion (line 31), then we store the SSR (line 34) and start on the late search. The late
search is similar to the early one, except that it starts at the latest possible time and
then works backwards.
1. double originalSecondsOfWeek = theTime.getGpsSecondsOfWeek();
2.
3. double minimumTime = originalSecondsOfWeek - searchWindowSizeSec;
4. double maximumTime = originalSecondsOfWeek + searchWindowSizeSec;
5.
6. //Start with a fairly coarse time step
7. double timeStepSize = 0.5;
8. //unless the search window is only small in which case we will make it smaller
9. if(searchWindowSizeSec < 1)
10. {
11. timeStepSize /= 4;
12. }
13.
14. PosCalcResult result;
15.
16. //find the first time where we get a location and this is the start of the bracket
17. double earliestSuccessTime = minimumTime;
18. while(true)
19. {
20. theTime.set(originalWeek, earliestSuccessTime);
21. result = this.calculatePosition(measurement, ephemeris, initialLocation, iono);
22.
23. if(result.getLocation() != null || earliestSuccessTime >= maximumTime)
24. {
25. break;
26. }
27. earliestSuccessTime += timeStepSize;
28. }
29.
30. //If we got at least one location then we can continue on
31. if(result.getLocation() != null)
32. {
33. //record the SSR for the earliest time
34. double earliestSsr = result.getResiduals().sumSquare();
Once the early and late search is complete and the SSR is recorded for both, we
calculate the SSR for the midpoint and then invoke the recursive bracketing search.
This is shown in the following code fragment. The SSR is recorded at the midpoint
(line 7) and then the recursive bracketing search is invoked (line 10). The
doBracketingSearch() method first checks to see if the difference between the two
outside values of the search are sufficiently small and, if so, then the method returns
which breaks it out of the recursion. If the search is continuing, it then performs the
position calculation at the end points and recursively calls itself with the new search
boundaries.
1. //Calculate the middle time and the SSR at that time. Then invoke the recursive
2. //bracketing search which will converge in on the best location.
3. double middleTime = earliestSuccessTime + ((latestSuccessTime -
earliestSuccessTime)/2.0);
4.
5. theTime.set(originalWeek, middleTime);
7. double middleSsr = result.getResiduals().sumSquare();

8.
9. //Call the method to do the bracketing search
10. double bestTime = doBracketingSearch(earliestSuccessTime, earliestSsr, middleTime,
middleSsr,
11. latestSuccessTime, latestSsr, measurement, ephemeris,
12. initialLocation, iono, stopResolution);
13.
14. theTime.set(originalWeek, bestTime);
The time recovery method is tested in the GpsPositionCalculationTest class in

the testPositionCalculationTimeRecovery() method. The test method goes through
100 records from a RINEX file and intentionally introduces a time error into the
measurement by adding 5 seconds to the time in the measurement. It then invokes
the position calculation without time recovery followed by invoking it with time
recovery. Statistics are collected for all 100 records and the test case ensures that the
statistics without time recovery give a poor result (average distance from ground
truth > 3,000 meters) and with time recovery the average distance from ground
truth has to be less than 5 meters in order for the test case to succeed. The average
distance from the ground truth when the time is corrupted by 5 seconds is 3,651.6
meters without iterative time recovery, and is 4.9 meters with time recovery.
7.2.1 Iterative Time Recovery: Accuracy

Table 7.2 shows the results of the position calculation accuracy by randomly prun-
ing the number of satellites down to the specified number in the first column. The
table shows the accuracy results for different time recovery search windows and
time offsets applied to the input measurements. The stop interval was set to 0.01
second for all tests. The iterative time recovery algorithm produces good results.
When considering all visible satellites (up to 12), the accuracy is very similar to that
when the handset is reporting the true time as shown in the first row of Table 7.1. In
addition, the accuracy is relatively constant across different size search windows
and time offsets for any given number of satellite measurements.
For any given search window, the accuracy is constant because of the iterative
nature of the algorithm. Regardless of the size of the search window, the algorithm
always converges on the SSR minimum; however, for larger sizes of windows, many
more position calculations are required and the LS suffers a performance impact.
The last column of the table shows the average number of discrete position calcula-
tions that are performed in order to minimize the SSR within one complete position
calculation. It is dependent on both the offset of the handset and the size of the
search window under consideration.
When there are fewer satellites in the measurement, the accuracy of the location
starts to decrease even when no offset is applied to the measured time. This shows
that if the handsets do have the ability to measure the true GPS time, it would be
preferable to use that than to employ a time recovery algorithm.
7.2.2 Iterative Time Recovery: Performance

Table 7.3 shows the results of running the position calculation over a data set that
contains a full day’s worth of data with different conditions. The performance mea-
surement software runs the test 100 times. This is so that any short-term effects
Table 7.2 Position Calculation Accuracy Using the Iterative Time Recovery Algorithm
Time Distance from Average Number
Time Offset Ground Truth Distance of Discrete Position
Recovery Applied to Meters (Average/ from Ground Calculations
Number of Search Measured Standard Truth Meters Required to
Satellites Window Time Deviation) 67%/95% Yield % Minimize the SSR
All visible 1 0 2.47/2.72 3.11/5.14 100.0 24.00
All visible 1 0.5 2.47/2.72 3.11/5.14 100.0 24.29
All visible 2 0 2.37/1.54 2.99/4.93 100.0 27.48
All visible 2 0.5 2.38/1.54 3/4.95 100.0 27.66
All visible 2 1.0 2.37/1.53 2.99/4.93 100.0 28.28
All visible 2 1.5 2.39/1.55 3.01/4.97 100.0 28.47
All visible 10 1.5 2.41/1.67 3.04/5.01 100.0 58.39
8 1 0 3.08/3.62 3.88/6.41 100.0 24.00
8 1 0.5 2.99/3.37 3.77/6.22 100.0 24.33
8 2 0 2.80/2.86 3.53/5.82 100.0 27.38
8 2 0.5 2.67/2.46 3.36/5.55 100.0 27.55
8 2 1.0 2.70/2.48 3.4/5.62 100.0 28.22
8 2 1.5 2.70/2.52 3.4/5.62 100.0 28.39
8 10 1.5 2.60/2.12 3.28/5.41 100.0 59.34
7 1 0 3.98/5.50 5.01/8.28 100.0 24.00
7 1 0.5 3.77/4.84 4.75/7.84 100.0 24.33
7 2 0 3.35/3.75 4.22/6.97 100.0 27.34
7 2 0.5 3.34/3.62 4.21/6.95 100.0 27.55
7 2 1.0 3.35/3.67 4.22/6.97 100.0 28.21
7 2 1.5 3.29/3.40 4.15/6.84 100.0 28.38
7 10 1.5 3.95/4.43 4.98/8.22 100.0 59.34
6 1 0 7.15/17.30 9.01/14.87 100.0 24.00
6 1 0.5 7.04/15.37 8.87/14.64 100.0 24.33
6 2 0 6.34/17.27 7.99/13.19 100.0 27.38
6 2 0.5 6.31/18.58 7.95/13.12 100.0 27.58
6 2 1.0 6.46/21.22 8.14/13.44 100.0 28.20
6 2 1.5 5.96/13.89 7.51/12.4 100.0 28.39
6 10 1.5 7.10/13.27 8.95/14.77 100.0 59.34
5 1 0 30.63/112.52 38.59/63.71 99.77 24.00
5 1 0.5 29.30/108.33 36.92/60.94 99.84 24.32
5 2 0 32.22/144.42 40.6/67.02 99.83 27.42
5 2 0.5 32.74/176.77 41.25/68.1 99.83 27.60
5 2 1.0 29.30/149.19 36.92/60.94 99.84 28.22
5 2 1.5 28.37/171.03 35.75/59.01 99.82 28.43
5 10 1.5 42.58/338.01 53.65/88.57 99.78 58.99
from other transient processes running on the machine will be averaged out over a
long period of time. The calculations are performed for all satellites in view of the
receiver.
Table 7.3 Time Recovery Performance for the Iterative Time

Recovery Algorithm
Percentage
Time Time Time Offset of Measured
Recovery Recovery Applied to Transactions TPS to TPS
Search Stop Measured Per Second Without Time
Window Interval Time (TPS) Recovery %
N/A N/A 0 1,430.4 100
0.5 0.01 0 170.9 11.9
1 0.01 0 152.8 10.7
1 0.01 1 152.8 10.7
2 0.01 0 120.1 8.4
2 0.01 1 120.1 8.4
2 0.01 2 120.1 8.4
3 0.01 0 93.0 6.5
3 0.01 1 92.7 6.5
3 0.01 2 92.7 6.5
3 0.01 3 93.1 6.5
5 0.01 0 62.8 4.4
5 0.01 1 62.8 4.4
5 0.01 2 62.8 4.4
5 0.01 3 62.8 4.4
10 0.01 0 34.5 2.4
10 0.01 1 34.5 2.4
10 0.01 2 34.5 2.4
10 0.01 3 34.5 2.5
A software tool records the total elapsed time in seconds to perform the position
calculations, and on completion divides it by the total number of calculations per-
formed. This is recorded in the table as the total number of transactions per second
(TPS).
The absolute numbers are not considered crucial in the analysis because they are
highly dependent on the platform and the implementation; however, the relative
performance effects are worthwhile to consider for analysis. The last column in the
table shows the ratio of the measured TPS rate to the measured TPS rate without
any time recovery processing as a percentage.
The software is running on a Sun Netra 210 running the Solaris operating sys-
tem. During the run, the CPU is operating at 100% of its capacity (0% idle).
The first row in the table shows the TPS when running without time recovery
enabled, which is 1,430.4 TPS. However, once the iterative time recovery is
enabled, there is a significant performance impact. The performance impact is
highly dependent on the size of the search window, since this affects the number of
iterations required.
As mentioned in Section 7.1, in the worst case, the handset timestamps the mea-
surements with the reference time that is provided by the LS [4]. A conservative esti-
mate of the time error when it reaches the handset might be 2 seconds. If the PCF is
configured to work with the 2-second time recovery search window on the host
platform, it would be able to process 120.1 TPS, which is only 8.4% of the speed of
running without time recovery.
Such a large performance impact makes this solution difficult in situations
where the platform needs to achieve a high contracted throughput. For this applica-
tion, a more efficient time recovery algorithm is required. In Section 7.3, we con-
sider integrated time recovery as the alternative.
7.3 Integrated Time Recovery
The integrated time recovery algorithm involves adding an additional term, the time
recovery offset or the gross time error, to the LS solution. In order to solve for
another unknown, we need to have at least five measurements instead of the mini-
mum of four required when the time is well known.
The aim is now to use the least squares described in Chapter 6 to solve for the
coordinates of the receiver in Earth-centered Earth-fixed (ECEF) reference frame
(xu, yu, zu), the receiver clock error (tu), and the gross time recovery error (tG). This
gross time recovery error can be in the range of seconds. As shown in (7.1), Δx is the
estimate of the present location and the handset clock error and now contains an
additional term for the gross time error (tG).
⎡x u ⎤
⎢y ⎥
⎢ u⎥
Δx = ⎢z u ⎥ (7.1)
⎢t ⎥
⎢ u ⎥
⎢⎣t G ⎥⎦
The geometry matrix H is modified to include an additional term. The H matrix

is modified based on [3] in (6.9) and becomes that shown in
⎡ x 1s − x u y1s − y u ⎤
z 1s − z u
⎢− 1
− 1
− − 1 R& ⎥
1
⎢ r r r ⎥
⎢ x s − x u ys − yu z s − z u
2 2 2
⎥
⎢− 2
− 2
− 2
− 1 R& ⎥
H=⎢ r r r ⎥ (7.2)
⎢ x s3 − x u y s3 − y u z s3 − z u & ⎥
⎢− r 3
−
r 3
−
r 3
− 1R ⎥
⎢ ⎥
⎢ x s − x u ys − yu z s − z u
4 4 4
⎥
⎢⎣− − − − 1 R& ⎥
r4 r4 r4 ⎦
& is the range rate that is calculated as specified in equation 5 in [3] and is
where R
shown in
s−u
R& = ( v s − v u ) ⋅ +f +ε (7.3)
r
where vs and vu are the three dimensional velocities of the satellite and the user,
respectively, s and u are the ECEF coordinates of the satellite and the user, respec-
Table 7.4 Time Recovery Accuracy for the Integrated Time

Recovery Algorithm
Distance from
Time Offset Ground Truth Distance
Applied to Meters (Average/ from Ground
Number Measured Standard Truth Meters
of Satellites Time Deviations) 67%/95% Yield %
All visible 0 2.69/1.90 3.00/6.12 99.99
All visible 0.5 2.69/1.91 3.00/6.13 99.99
All visible 1 2.72/2.00 3.02/6.21 99.98
All visible 1.5 2.91/2.55 3.13/6.84 99.89
All visible 2 3.21/3.33 3.28/7.85 99.77
All visible 5 6.12/13.85 4.76/20.64 91.84
All visible 10 9.64/15.78 7.35/36.35 36.01
8 0 3.20/3.38 3.27/7.69 100.0
8 0.5 3.20/3.53 3.27/7.68 99.99
8 1 3.20/3.34 3.28/7.73 99.99
8 1.5 3.23/3.39 3.30/7.80 100.0
8 2 3.26/3.45 3.33/7.87 99.99
8 5 3.05/3.08 3.13/7.62 100.0
8 10 2.77/2.76 2.83/6.70 100.0
7 0 4.19/5.76 3.87/11.56 99.98
7 0.5 4.16/5.17 3.85/11.49 99.98
7 1 4.22/5.78 3.89/11.77 99.97
7 1.5 4.26/5.83 3.91/11.77 99.98
7 2 4.32/6.10 3.97/12.28 99.98
7 5 4.50/5.69 4.12/13.72 99.98
7 10 4.79/5.71 4.17/16.77 99.94
6 0 6.67/11.48 5.44/21.99 99.13
6 0.5 6.66/11.25 5.46/21.94 99.13
6 1 6.68/11.43 5.47/22.18 99.19
6 1.5 6.71/11.70 5.47/22.02 99.19
6 2 6.64/11.12 5.47/21.84 99.28
6 5 7.30/12.22 5.97/25.27 99.07
6 10 8.26/11.25 7.05/28.93 99.21
5 0 12.10/26.15 9.76/43.17 88.40
5 0.5 11.95/23.46 9.64/42.79 88.71
5 1 12.08/23.58 9.77/43.12 88.58
5 1.5 12.29/24.71 9.95/44.05 88.50
5 2 12.29/27.21 9.96/43.51 88.43
5 5 12.55/20.41 10.62/44.66 87.34
5 10 12.24/18.31 10.59/43.80 70.38
tively (see Figure 6.1), r is given in (6.2), f is the receiver clock drift in meters per sec-
ond, and ε is the error.
The range rate is the rate of change of the range between the user and the satel-
lite. When performing the calculation, we have to assume that the user is stationary,
vu = (0, 0, 0), unless we have a way of retrieving that information. The range rate is
normally between 100 meters and 400 meters per second, but can be between 0 and
550 meters per second, either positive or negative.
Since the time error of the original measurement can be quite large, it is impor-
tant to recalculate the location of the satellites each time through the least squares
iteration loop. Section 7.3.1 shows that the integrated time recovery method is quite
accurate and has a good performance. It also has the significant advantage of not
needing to configure the time window over which to search, as is the case with
iterative time recovery.
7.3.1 Integrated Time Recovery: Accuracy

Table 7.4 shows the accuracy for the integrated time recovery algorithm. This table
shows the change in accuracy with a change in the time error of the handset for dif-
ferent numbers of handset measurements. The results show that the accuracy of the
integrated time recovery algorithm is similar to the iterative algorithm. However, it
performs better than the iterative method when there are fewer satellites in the mea-
surement, although there is a slight yield trade-off.
7.3.2 Integrated Time Recovery: Performance

The performance figures for the integrated time recovery algorithm are shown in
Table 7.5. It can be seen that there is very little impact on the performance of the
integrated time recovery algorithm.
Table 7.5 Time Recovery Performance for the

Integrated Time Recovery Algorithm
Time Offset
Applied to
Number Measured Transactions
of Satellites Time Seconds Per Second (TPS)
All visible Time recovery disabled 1,430.4
All visible 0 1,428.9
7.4 Software Project
The software project for this chapter is:
1. Modify the GpsPositionCalculation class to optionally perform integrated

time recovery.
References
[1] Syrjarinne, J., “Possibilities for GPS Time Recovery with GSM Network Assistance,” Pro-
ceedings ION GPS 2000, Salt Lake City, UT, 2000.
[2] Press, W. H., et al., Numerical Recipes in C: The Art of Scientific Computing, 3rd ed., New
York: Cambridge University Press, 2007.
[3] Glennon, E., “Solution of Timing Errors for AGPS,” Proceedings ION GPS 2005, 2005.
[4] Harper, N., et al., “Process for Improving GPS Acquisition Assistance Data and Server-Side
Location Determination for Cellular Networks,” Journal of Global Positioning Systems,
Vol. 3, No. 1-2, 2004.
CHAPTER 8
Hybrid Location
A-GPS works well when the handset is in an area where it can receive measurements
from four or more satellites with good geometry. However, the GPS signal does not
penetrate well into buildings and suffers in dense urban environments. In this situa-
tion, the handset may not be able to measure enough satellites to perform a position
calculation and will fall back to another location technology to determine the loca-
tion. The alternative is to make use of whatever GPS measurements are available
and combine them with other measurements. Combining measurements from mul-
tiple location technologies in order to calculate the location is known as hybrid
positioning.
This chapter discusses hybrid GPS and ranging measurements in order to calcu-
late a location where one would not otherwise be able to be calculated. It discusses
the algorithm and steps through the implementation. It then outlines a series of
experiments and results that use simulated range measurements to calculate a loca-
tion in order to demonstrate the advantages of making use of multiple measurement
types.
Generally, GPS performs well when the user’s environment allows the handset
to lock onto at least four satellites that are well distributed throughout the sky.
However, studies show that there are problems locking on to even the minimum
number of satellites in urban canyons [1]. Even when four satellites are available,
the distribution of satellites can be such that the resulting location is inaccurate. The
primary factors that affect a GPS location are the number of satellites measured and
the geometry of the satellites measured.
In these low-signal situations, additional ranging measurements are helpful,
particularly when the GPS receiver is built into a cell phone and there is an emer-
gency situation. An emergency situation is often a one-off cold-start location deter-
mination. In this chapter we are considering one-off position calculations and
excluding methods where multiple locations are integrated or filtered in order to
calculate a more accurate location.
8.1 Hybrid Positioning Overview
When attempting a high-accuracy fix, the LS initially provides assistance data to the
wireless handset. In handset-assisted mode, the handset attempts to lock on to as
many satellites that it can within the time limit that has been specified by the LS and
returns whatever measurements it has to the LS. In the case where there are not
enough measurements to perform a position fix, the LS can use other measurements
from the network to perform a hybrid location. The other measurements may be
167
168 Hybrid Location
from sources such as the cellular network [for example, round-trip time (RTT) in a
UMTS network or timing advance (TA) in a GSM network], uplink WiFi, DTV, or
other signals.
There is a large amount of work on integrating GPS with other sensing inputs
such as Inertial Navigation Systems (INS), Loran C, and TDOA. There is a lot of
work on improving the quality of the location fixes by taking multiple measure-
ments as described in [2]. Integrating ranging measurements from DTV signals
shows significant promise [3].
This chapter contains the results of some tests where the position calculation is
run using a test data set in open sky. We then investigate the performance of the
hybrid position calculation using ideal range measurements (no error) and with
range measurements with different simulated inaccuracies. The inaccuracies are
simulated using a random process.
We then investigate the performance of the LS with different numbers of GPS
satellites and range measurements. The GPS measurements are sourced from the
open-sky measurements and are pruned down to a smaller number by randomly
selecting a given number of satellites to use. The range measurements are simulated
and are generated with different levels of error.
Note that the measurements discussed in this chapter are considered to be pure
range measurements and are not subject to their own clock errors. For example,
consider the case of hybrid location determination within a UTRAN network (dis-
cussed in Chapter 5). The range measurements are derived from round trip time
(RTT) measurements that are reported by the Node B (or base station) and the
receive-transmit delay that is reported by the handset (the UE). The RTT is mea-
sured in the Node B from the amount of time that a radio signal takes to propagate
from the Node B to the handset (the UE) and return. In addition, the handset reports
the receiver-transmit delay (Rx-Tx time difference) to the Node B. Both of these
measures are reported to the SAS for each Node B from which the RNC has mea-
surements. The SAS ultimately receives a PCAP message with this information. The
range from the Node B to the UE is then determined (in chips) as half of the differ-
ence between the RTT and the Rx-Tx difference. This is converted to a range based
on the chipping rate of the radio access. For example, FDD WDCMA uses a
chipping rate of 3.84 Mchps.
8.2 Hybrid Position Calculation
Range measurements are integrated into the model that was described in Chapter 6.
The range measurements are independent of GPS and hence are not subject to the
receiver or satellite clock errors. Figure 8.1 shows the model where a transmitter t at
range rt is included in the model.
The range from u to t is defined by (6.2) but substituting t for s. The least
squares process in Chapter 6 is used to calculate the location of the handset. The Δρ
matrix changes from that shown in (6.8) to that shown in (8.1). Equation (8.1) con-
tains three satellite measurements and one range measurement in the last row. The
difference between the range measurement and the satellite measurements is that
the clock error of the satellite and the handset does not need to be included. The
t (x t ,y t ,zt) s (x s , y s , zs )
rs
rt
zs
u (x u ,y u ,zu)
ys
xs
y
zu
xu
yu
x
Figure 8.1 User and satellite model.
range is considered as a pure range measurement without clock error as discussed in

Section 8.1.
(
⎡ ρ1 − Δt 1SV
⎢
) (
× c − r1 + t r × c ⎤
⎥
)
Δρ = ⎢
(
⎢ ρ 2 − Δt SV
2
) (
× c − r2 + tr × c ⎥
⎥
) (8.1)
⎢
(
⎢ ρ 3 − Δt SV
3
) (
× c − r3 + tr × c ⎥
⎥
)
⎢⎣ σ 1 − rt1 ⎥⎦
where the variables are the same as described for (6.8) except for rt1, which is the
range from the current estimate of the location to transmitter 1, and σ1 is the mea-
sured range to transmitter 1.
The H matrix changes from (6.9) to as shown in (8.2). Equation (8.2) contains
three satellites and one range measurement in the last row.
⎡ x 1s − x u y1s − y u ⎤ z 1s − z u
⎢− 1
− 1
c ⎥ − 1
⎢ r r r ⎥
⎢ x s − x u ys − yu z s − z u ⎥
2 2 2
⎢− r2
−
r2
−
r2
c⎥
H⎢ ⎥ (8.2)
⎢ x s3 − x u y s3 − y u z s3 − z u ⎥
⎢− r3
−
r3
−
r3
c⎥
⎢ ⎥
⎢ x t1 − x u yt1 − y u z t1 − z u ⎥
⎢⎣− r4
−
r4
−
r4
c ⎥
⎦
170 Hybrid Location
where the variables are the same as described for (6.9) except xt, yt, and zt, which are
the coordinates of the transmitter. Note that the fourth column of the last row con-
tains a 0.
Obtaining a location in an urban canyon can be a significant problem. This is
because the signals are low power and do not penetrate obstacles such as buildings.
The QZSS system is presently under consideration [4] as an augmentation to GPS.
The orbital configurations of the QZSS satellites are such that there will be more
satellites at higher elevations in Japanese cities such as Tokyo. This will allow users
to be able to detect more satellites and get a more accurate location fix.
8.3 Hybrid Position Calculation Implementation
For the Java implementation, the range measurements (transmitter location and
range) are stored in an instance of a RangeMeasurement object and the individ-
ual RangeMeasurement instances are stored in a RangeMeasurementSet object,
which is just a container for the collection of range measurements.
An instance of the RangeMeasurementSet object is passed into the
GpsPositionCalculation.calculatePosition() method. The class diagram for the
range measurement objects is shown in Figure 8.2.
The methods to set up the H and Δρ matrixes were discussed in Chapter 6. They
are enhanced so that they can include the range measurement information in the cal-
culation. The setUpPmatrix() method is shown next. The range measurement set is
now passed into the method. It is checked in line 5 to determine whether there are
any range measurements, and the Δρ matrix is allocated on line 9 with sufficient
rows to include both the GPS and the range measurements. The additional code
from that already outlined in Chapter 6 is in lines 22–32. If there are any range mea-
surements (line 23), we go through each range measurement provided (line 25), cal-
culate the value as shown in the last row of (8.1), and add them to the matrix (line
30).
1. private Matrix setUpPmatrix(GpsMeasurement measurement, RangeMeasurementSet
rangeMeasurements, Wgs84Coordinate[] satelliteLoc,
2. Matrix x, Wgs84Coordinate handsetLocEstimate)
3. {
4. int numRangeMeasurements = 0;
RangeMeasurementSet
-rangeMeasurements
0..*
RangeMeasurement
-transmiiterLocation : Wgs84Coordinate
-range : double
Figure 8.2 Class diagram for range measurement data.

8.3 Hybrid Position Calculation Implementation 171
5. if(rangeMeasurements != null)
6. {
7. numRangeMeasurements = rangeMeasurements.getNumRangeMeasurements();
8. }
9. Matrix p = new Matrix(measurement.getNumSatsMeasured() + numRangeMeasurements, 1);
10.
11. //Complete the p matrix for the GPS measurements
13. {
14. double estimatedSatRange = handsetLocEstimate.distanceTo(satelliteLoc[i]);
15. SatGpsMeasurement satMeasurement = measurement.getSatelliteMeasurement(i);
16.
17. p.setElement(i, 0,
18. (satMeasurement.getCorrectedPseudorange() -
satMeasurement.getAssociatedSatClockErrorMeters()) -
19. (estimatedSatRange + (x.get(3, 0) * Satellite.C_SPEED_OF_LIGHT)));
20. }
21.
22. //Complete the p matrix for the range measurements
23. if(numRangeMeasurements > 0)
24. {
25. for (int i = 0; i < numRangeMeasurements; i++)
26. {
27. int row = i + measurement.getNumSatsMeasured();
28. Wgs84Coordinate transmitterLocn =
rangeMeasurements.getRangeMeasurement(i).getLocation();
29. double transmitterEstimatedRange = handsetLocEstimate.distanceTo(transmitterLocn);
30. p.setElement(row, 0, rangeMeasurements.getRangeMeasurement(i).getRange() -
transmitterEstimatedRange);
31. }
32. }
33. return p;
34. }
The setUpHMatrix() is modified to add the rows associated with the range mea-
surements as shown next. Similar to setUpPmatrix(), there is some additional setup
in lines 4–9. The range measurements are added in lines 20–33. The elements of H
are set up in lines 28–30; the values are calculated based on the location of the trans-
mitter and the estimated range to the transmitter from the reference location as
specified in the last row of (8.2). The final column is set to 0 for range measurements
(line 31).
1. private Matrix setUpHmatrix(GpsMeasurement measurement, RangeMeasurementSet
rangeMeasurements,
2. Wgs84Coordinate[] satelliteLoc, Wgs84Coordinate handsetLocEstimate)
3. {
4. int numRangeMeasurements = 0;
5. if(rangeMeasurements != null)
6. {
7. numRangeMeasurements = rangeMeasurements.getNumRangeMeasurements();
8. }
9. Matrix H = new Matrix(measurement.getNumSatsMeasured() + numRangeMeasurements, 4);
11. {
12. double satRange = handsetLocEstimate.distanceTo(satelliteLoc[i]);
13.
14. H.setElement(i, 0, -1 * (satelliteLoc[i].getX() - handsetLocEstimate.getX())/satRange);
15. H.setElement(i, 1, -1 * (satelliteLoc[i].getY() - handsetLocEstimate.getY())/satRange);
16. H.setElement(i, 2, -1 * (satelliteLoc[i].getZ() - handsetLocEstimate.getZ())/satRange);
17. H.setElement(i, 3, Satellite.C_SPEED_OF_LIGHT);
18. }
19.
20. if(numRangeMeasurements > 0)
21. {
22. for (int i = 0; i < numRangeMeasurements; i++)
23. {
24. int hIndex = i + measurement.getNumSatsMeasured();
25. Wgs84Coordinate transmitterLoc =
rangeMeasurements.getRangeMeasurement(i).getLocation();
26. double transRange = handsetLocEstimate.distanceTo(transmitterLoc);
27.
28. H.setElement(hIndex, 0, -1 * (transmitterLoc.getX() -
handsetLocEstimate.getX())/transRange);
29. H.setElement(hIndex, 1, -1 * (transmitterLoc.getY() -
handsetLocEstimate.getY())/transRange);
172 Hybrid Location
30. H.setElement(hIndex, 2, -1 * (transmitterLoc.getZ() -

handsetLocEstimate.getZ())/transRange);
31. H.setElement(hIndex, 3, 0);
32. }
33. }
34. return H;
35. }
In order to validate the implementation, range measurements are simulated in

the test harness. The test case is in the position calculation test class in the method
testHybridPositionCalcRangeMeasurement(). This method runs a series of position
calculations. It adds a single simulated range measurement to each set of measure-
ments that are provided to the calculation. The range measurements are simulated
and have no error introduced, so they should always improve the accuracy of the
calculation, that is, the distance from the ground truth in the error should be
smaller. The test case runs the position calculation without the range measurement
and calculates and records the distance from the ground truth. It then runs the cal-
culation with the range measurement and calculates the ground truth. The test case
compares the accuracy of both location and will only pass if the hybrid location is
better than the GPS-only location.
8.4 Hybrid Position Calculation Accuracy
This section describes a series of experiments that show the performance of the
hybrid position calculation using a position calculation class.
8.4.1 Simulation Background

In this chapter, we investigate the potential performance of hybridizing the GPS
position calculation with range measurements, and we show the horizontal error
(ground distance) and vertical error (altitude) in the position calculation that is a
result of running the position calculation over the test data under a particular
specified set of conditions.
The position calculation method is provided with an initial location estimate for
the handset in order to initialize the Δx matrix. When ranging measurements are
involved in the calculation, the initial location estimate is more important because
the distances to the range sources are relatively small, compared to the distance to
the satellites, which are approximately 20,200 kilometers away. When there is only
one range measurement in the calculation, it is easy for the position calculation to
converge on a location on the opposite side of the range source from where the
measurement was made.
This means that the accuracy results depend not only on the measurements pro-
vided to the position calculation method but also on how close the initial location
provided is to the true location. For this reason, all of the tabulated test results
shown in this chapter provide the distance of the calculated location from the
ground truth for a particular horizontal offset and altitude offset in the estimated
location provided to the position calculation.
Consider a handset in a cellular network. Figure 8.3 shows an aerial view of an
omnidirectional cell in a cellular network. In this case, the position calculation class
will use the location of the base station as the initial location. The handset could be
anywhere within the range of the cell. Depending on the handset’s location and the
physical size of the cell, the initial location provided to the position calculation
could be some distance away from the true location of the handset.
It is impossible to define a truly typical initial location uncertainty size, but for
this section, we have defined a typical initial location uncertainty where the handset
is 1,000 meters from the base station and at an altitude difference of 100 meters.
Note that the initial location may be more accurate than the size of the cell if other
technologies are employed to calculate the initial location. For example, RTT mea-
surements are readily available in a UTRAN network, so an RTT-based location
may be used as the initial location estimate for the A-GPS fix. Other location tech-
nologies that can provide an accurate seed location for A-GPS include U-TDOA and
TA/NMR. These typical initial location offsets are highlighted in the results tables
throughout this chapter.
The GPS measurements discussed in this chapter are 80,657 distinct GPS mea-
surements taken from the NovAtel GPS receiver on the roof of the laboratory. Dur-
ing the 24-hour period, the GPS receiver locks on to an average of 8 satellites with a
minimum of 6 satellites and a maximum of 11 satellites. The satellites have an
orbital period of just under 12 hours. Using 24 hours of data covers all satellites
coming into view twice and includes many different satellite arrangements, so this is
a reasonable sized data set to use.
In order to run some of the simulations outlined in this chapter, this basic data
set is used and a subset of individual satellites are taken from each of the GPS mea-
surement. For example, the complete data set contains 80,657 GPS measurements.
Each GPS measurement contains a measurement of all of the satellites in view at
that instant in time. To run a test for only four satellites, all 80,657 GPS measure-
ments are still used. However, only four satellites are randomly selected from each
measurement; the location is calculated and results collated.
As a starting point, Table 8.1 shows the accuracy in meters at the 67% and 95%
levels for different initial location offsets in the horizontal and vertical directions.
Range
Cellular
base station
Handset
Figure 8.3 Aerial view of a cell showing the uncertainty.

174 Hybrid Location
During the 24 hours, the position calculation achieved a 100% yield and the accu-
racy for the typical uncertainty of 1,000 meters horizontal and 100 meters altitude
at 67% is 4.94 meters and at 95% is 8.47 meters.
When there are many satellites visible, there is more redundancy when solving
the equations and the horizontal offset has little effect on the calculated location.
For example, when the horizontal offset is 100 kilometers and the altitude is 100
meters, the accuracy is essentially the same as applying no offset.
8.4.2 Location Calculation in Difficult Situations

In this section, we consider the location calculated in nonideal situations. This is the
situation when there are only a minimal number of satellites available or the satel-
lites measured are not in a favorable configuration, such as when they are very high
in the sky.
We initially consider the case where four satellites are in view of the receiver. In
this case, four satellites are randomly selected from each GPS measurement in the
test set. Table 8.2 shows the accuracy results.
Table 8.2 shows that the accuracy of the location fix is worse than when using
the satellites in view from an antenna in open sky. It also becomes increasingly
worse in small increments as the initial location offset is increased.
An even more restricted case is when there are only three satellites in view of the
handset. In this case, an Earth-centered measurement is simulated in order to make
a two-dimensional location fix. Note that this solution does not use a DEM, but
Table 8.1 Horizontal and Vertical (Altitude) Errors for All Satellites in
View
All Satellites: Horizontal Error
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 4.94 8.47 100.00 4.94 8.47 100.00
Offset
1,000 4.94 8.47 100.00 4.94 8.47 100.00
10,000 4.94 8.48 100.00 4.94 8.48 100.00
50,000 4.94 8.49 100.00 4.94 8.49 100.00
100,000 4.93 8.51 100.00 4.93 8.52 100.00
All Satellites: Vertical Error
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 24.26 36.24 100.00 24.26 36.24 100.00
Offset
1,000 24.26 36.24 100.00 24.26 36.25 100.00
10,000 24.26 36.26 100.00 24.26 36.27 100.00
50,000 24.27 36.29 100.00 24.28 36.28 100.00
100,000 24.29 36.29 100.00 24.28 36.29 100.00
uses the altitude from the initial location estimate to set the range to the Earth-cen-
tered measurement. The results are shown in Table 8.3. There is a significant
increase in the horizontal and vertical error in the result compared to when using
four satellites in Table 8.2.
Receiving a small number of satellites at a high elevation can be a problem for
the location calculation as this satellite arrangement results in poor dilution of pre-
cision (DOP). Table 8.4 shows the results when using the four highest elevation sat-
ellites for
each measurement as input to the position calculation. The accuracy of the
location is similar to using four randomly selected satellites; however, the yield has
been significantly reduced.
In this section, we have shown results for situations where a limited number of
satellites are visible, or those visible are not in an ideal arrangement such as being at
a high elevation. In these situations, a stand-alone GPS PCF has been shown to suf-
fer in terms of both yield and accuracy. In the next section we will consider these sit-
uations and the expected accuracy when range measurements are included from
other sources.
8.4.3 Hybrid Location with Ideal Ranges

In this section, range measurements are simulated as if they are from a point source
10,000 meters from the ground truth and are selected in a random direction from 0°
Table 8.2 Horizontal and Vertical Errors for Four Randomly Selected
Satellites
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 9.79 30.55 83.84 10.04 38.62 84.08
Offset
1,000 9.80 30.51 84.24 10.01 38.45 83.71
10,000 9.74 30.86 83.67 10.02 38.51 83.88
50,000 10.06 39.87 83.95 10.01 38.70 83.90
100,000 10.27 46.53 84.24 10.25 45.51 84.03
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 26.37 48.12 83.84 28.01 88.14 84.08
Offset
1,000 26.32 48.08 82.24 27.95 84.87 83.71
10,000 26.83 47.88 83.67 28.02 71.00 83.88
50,000 27.73 64.12 83.95 27.85 58.80 83.90
100,000 27.98 72.78 84.24 28.05 71.03 84.03
176 Hybrid Location
Table 8.3 Horizontal and Vertical Errors for Three Randomly Selected
Satellites and an Earth-Centered Measurement
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 24.45 74.02 87.11 82.26 236.61 87.11
Offset
1,000 24.42 73.56 87.03 82.17 234.13 86.82
10,000 28.07 99.09 87.06 81.80 239.10 87.19
50,000 103.31 333.20 86.79 110.59 402.40 87.16
100,000 203.95 651.10 86.98 206.99 675.29 87.05
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 0.05 0.18 87.11 100.04 100.42 87.11
Offset
1,000 2.70 3.13 87.03 101.56 103.10 86.82
10,000 27.13 31.16 87.06 115.83 130.81 87.19
50,000 135.61 155.72 86.79 180.07 253.96 87.16
100,000 270.29 311.03 86.98 257.23 406.95 87.05
Table 8.4 Horizontal and Vertical Errors for the Four Highest Elevation
Satellites
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 10.06 31.84 59.88 10.06 31.84 59.88
Offset
1,000 10.06 31.84 59.88 10.06 31.84 59.88
10,000 10.06 31.84 59.87 10.06 31.83 59.88
50,000 10.06 31.83 59.86 10.05 31.80 59.86
100,000 10.07 31.79 59.85 10.06 31.78 59.86
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 34.86 69.41 59.88 34.86 69.41 59.88
Offset
1,000 34.86 69.41 59.88 34.86 69.41 59.88
10,000 34.86 69.39 59.87 34.86 69.33 59.88
50,000 34.87 69.38 59.86 34.87 69.40 59.86
100,000 34.85 69.36 59.85 34.86 69.36 59.86
to 360°. This is combined with using the randomly selected number of GPS mea-
surements from each of the 80,657 test measurements.
Consider the casein which the handset can measure three GPS satellites and
three range measurements. The results are shown in Table 8.5. It can be seen that
the yield is almost 100% and the results are very accurate. Note, however, that the
results are somewhat artificial because the range measurements do not have any
error associated with them. The results do show that using range measurements can
significantly improve the calculated location. For example, the accuracy at the 67%
level has gone from 82.17 meters (for three satellites and an Earth-centered mea-
surement) down to 5.83 meters.
It is possible that only one range measurement may be available in association
with some GPS measurements for a particular location fix. This is the case for
TA/NMR and also for some of the early UTRAN RTT deployments where the RNC
is only capable of returning one measurement to the SAS. Table 8.6 shows results
for three measured satellites and one range measurement. This results in a very high
yield and also quite good accuracy. It can also be seen that the accuracy of the loca-
tion fix can become poor when the initial location estimate is a significant distance
from the true location of the handset.
8.4.4 Hybrid Location with Ranges Using Error-Corrupted Ranges

In the previous section, the range measurements were simulated as “perfect” mea-
surements. That is, the simulated range measurements had no error. In the real
Table 8.5 Horizontal and Vertical Errors for Three Satellites and Three
Range Measurements
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 10.06 31.84 59.88 10.06 31.84 59.88
Offset
1,000 10.06 31.84 59.88 10.06 31.84 59.88
10,000 10.06 31.84 59.87 10.06 31.83 59.88
50,000 10.06 31.83 59.86 10.05 31.80 59.86
100,000 10.07 31.79 59.85 10.06 31.78 59.86
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 34.86 69.41 59.88 34.86 69.41 59.88
Offset
1,000 34.86 69.41 59.88 34.86 69.41 59.88
10,000 34.86 69.39 59.87 34.86 69.33 59.88
50,000 34.87 69.38 59.86 34.87 69.40 59.86
100,000 34.85 69.36 59.85 34.86 69.36 59.86
178 Hybrid Location
world, however, range measurements have errors that depend on many factors such
as the resolution of the radio interface, signal propagation effects, interference, syn-
chronization, and measurement error.
In this section, we introduce error into the range measurements to simulate
using measurements of different accuracies. Similar to the previous section, the
range measurements are simulated as from a point source 10,000 meters from the
ground truth and are selected in a random direction from 0° to 360°. A simple
method is then used to introduce an error to the measurements.
The range to the simulated source is corrupted by a randomized value with a
specific range. For example, when a range uncertainty of 500 is considered, the
range to the base station for each measurement is selected as a random distance
between 9,750 and 10,250 meters.
Table 8.7 shows the results of calculating a location using three satellites with
three range measurements, each of which has been corrupted by up to 100 meters.
The results show that the PCF achieves a very high yield and good accuracy. Simi-
larly, when there is only one range measurement as shown in Table 8.8, the yield is
quite high. However, the accuracy is reduced.
A range error of 100 meters is quite a conservative estimate using ranging tech-
nology available today such as RTT for UMTS networks or UTDOA-based
measurements.
Figures 8.4 and 8.5 show the position calculation accuracy at the 67% and 95%
levels for different numbers of range measurements and different amounts of cor-
Table 8.6 Horizontal and Vertical Errors for Three Satellites and One Range
Measurement
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 4.94 8.47 100.00 4.94 8.47 100.00
Offset
1,000 4.94 8.47 100.00 4.94 8.47 100.00
10,000 4.94 8.48 100.00 4.94 8.48 100.00
50,000 4.94 8.49 100.00 4.94 8.49 100.00
100,000 4.93 8.51 100.00 4.93 8.52 100.00
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 30.52 110.02 99.97 32.23 109.60 99.98
Offset
1,000 30.61 125.46 99.98 33.36 130.55 99.99
10,000 50.69 5658.21 99.98 64.45 5681.05 99.98
50,000 2049.77 8551.16 99.98 2060.67 8515.85 99.99
100,000 2419.26 8661.38 99.97 2377.49 8619.04 99.97
ruption in the range measurements on a log scale. They all use the typical initial
location uncertainty of 1,000 horizontal meters and 100 vertical meters (altitude).
The graphs in Figure 8.4 show that there is a direct relationship between the
inaccuracy of the range measurement and the resulting error in the position calcula-
tion result. A low quality of range measurement produces a less accurate location.
When there are only two satellites in view and two range measurements, the accu-
racy is poor when the range measurements have more than about 80 meters of error.
In the case when there are three satellites in view as shown in Figure 8.5, the
accuracy is improved.
This section has shown that hybrid A-GPS and range measurement positioning
is a realistic solution to get an accurate location when there are not enough GPS sat-
ellites available. This is quite often the case in areas such as urban canyons. When
several range measurements are available for the position fix, such as is the case for
an RTT solution, the position calculated becomes highly accurate. When there
are only two GPS satellites but four range measurements accurate to 100 meters, a
typical initial location uncertainty accuracy is 40 meters at 67% with a yield of
99.99%.
When inaccurate ranging measurements are used, the accuracy of the location
fix reduces as the amount of inaccuracy is increased. However, as more ranging
measurements are used, the difference is reduced, that is, the effect of the error is less
significant as there are more range measurements. This demonstrates the value of
including numerous range measurements, for example, from U-TDOA or other
range measures such as from TA or RTT. It also demonstrates that the range mea-
Table 8.7 Horizontal and Vertical Errors for Three Satellites and Three Range
Measurements with a Range Error of 100 Meters
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 33.42 65.52 100.00 32.89 66.60 100.00
Offset
1,000 33.41 65.65 100.00 33.16 65.59 100.00
10,000 33.91 75.31 99.45 33.83 74.77 99.33
50,000 34.82 108.52 98.36 35.11 109.64 98.23
100,000 35.48 160.16 97.66 35.34 157.44 97.67
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 53.43 184.96 100.00 56.40 187.81 100.00
Offset
1,000 54.03 188.03 100.00 54.99 186.96 100.00
10,000 56.57 229.74 99.45 56.78 233.27 99.33
50,000 58.99 385.58 98.36 59.57 387.02 98.23
100,000 59.94 554.20 97.66 60.09 567.84 97.67
180 Hybrid Location
Table 8.8 Horizontal and Vertical Errors for Three Satellites and One Range
Measurements with a Range Error of 100 Meters
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 33.42 65.52 100.00 32.89 66.60 100.00
Offset
1,000 33.41 65.65 100.00 33.16 65.59 100.00
10,000 33.91 75.31 99.45 33.83 74.77 99.33
50,000 34.82 108.52 98.36 35.11 109.64 98.23
100,000 35.48 160.16 97.66 35.34 157.44 97.67
Altitude Offset
0 100
Accuracy Accuracy
67% 95% Yield 67% 95% Yield
Horizontal 0 53.43 184.96 100.00 56.40 187.81 100.00
Offset
1,000 54.03 188.03 100.00 54.99 186.96 100.00
10,000 56.57 229.74 99.45 56.78 233.27 99.33
50,000 58.99 385.58 98.36 59.57 378.02 98.23
100,000 59.94 554.20 97.66 60.09 567.84 97.67
surements will allow a fix when there are not enough GPS satellites in view of the
handset.
The following are the software projects for this chapter:
1. Range measurements will normally have an error associated with the

measurement. Update the RangeMeasurement class to be able to store an
error associated with the measurement and the GpsPositionCalculation
class so that it considers the error when deciding whether to include the
range measurement in the position calculation.
2. At present, the position calculation class assumes that GPS measurements
will always be present. Modify the position calculation so that it works with
range measurements only.
3. Write an application class that can be used to call the position calculation
with different numbers of GPS and range measurements.
Changes in position calculation accuracy with range measurement inaccuracy

two satellites and different numbers of range measurements for 67%
10,000
1,000
2 Range
3 Range
Position calculation accuracy (meters) log scale
100
4 Range
10
1
0 100 200 300 400 500 600 700 800 900 1,000
Range measurement inaccuracy (meters)
Changes in position calculation accuracy with range measurement inaccuracy

two satellites and different numbers of range measurements for 95%
10,000
1,000
2 Range
100 3 Range
4 Range
10
1
0 100 200 300 400 500 600 700 800 900 1,000
Figure 8.4 Change in position calculation accuracy for two satellites and different numbers of
range measurements.
182 Hybrid Location
Change in position calculation accuracy with range measurement inaccuracy

three satellites and different numbers of range measurements for 67%
10,000
1,000
1 Range
2 Range
100
Position calculation accuracy (meters) log scale
3 Range
4 Range
10
1
0 100 200 300 400 500 600 700 800 900 1,000
Change in position calculation accuracy with range measurement inaccuracy

three satellites and different numbers of range measurements for 95%
10,000
1,000
1 Range
2 Range
100
3 Range
4 Range
10
1
0 100 200 300 400 500 600 700 800 900 1,000
Figure 8.5 Change in position calculation accuracy for three satellites and different numbers of
range measurements.
References
[1] Junedi, D., and W. Ren, “Integration of GPS and GSM Signals for Location,” Master’s The-
sis 20, University of New South Wales, SNAP Group, 2004.
[2] Ma, C., Techniques to Improve Ground-Based Wireless Location Performance Using a
Cellular Telephone Network, University of Calgary, Department of Geomatics Engineering
Report 20177, 2003.
[3] Ju-Yong, D., M. Rabinowitz, and P. Enge, “Performance of Hybrid Positioning System
Combining GPS and Television Signals,” 2006 IEEE/ION Proceedings of Position, Loca-
tion, and Navigation Symposium, 2006.
CHAPTER 9
Other Server-Side Improvements and

Controls
The LS has several ways of improving the accuracy of the calculated location. One is
by using measurements from other sources as discussed in Chapter 8. The other is
by making use of additional error modeling information to which the handset may
not have access.
This chapter introduces some of the techniques available to the LS for improv-
ing the accuracy and yield of location calculations by using improved error models.
It also introduces location integrity and the mechanism for location assurance.
There is also a brief introduction to location spoofing.
9.1 Improved Error Modeling
In open sky, the conventional GPS error models, that is, the ones to which a handset
has access, will allow the calculation of the location of the handset using GPS L1 to
within 5 meters or so. In this chapter, some techniques are discussed for using
improved models in order to improve the accuracy of the location calculation by a
small amount.
9.1.1 Orbit Modeling

The GPS broadcast orbit provides a good accuracy when calculating the location of
the satellites over several hours (generally within 3 meters). This leads to a position-
ing error of up to 8 meters.
The orbit information is provided in a standard format and GPS receivers are
able to decode and make use of it. It is also used by the A-GPS handset for predicting
the next bit, or phase shift, in order to integrate over a longer period and detect
weaker GPS signals.
There are improved models that provide better accuracy than the standard
models and they are available to the server. When the location of the satellite can be
determined more accurately and there is good line of sight to the satellite, then the
resulting location will be more accurate.
The International GNSS Service (IGS) provides precise GPS products [1]. The
IGS Ultra-Rapid Products (IGU) provide accurate position information for the sat-
ellites over the previous 24 hours and also include the 24-hour predicted locations
[2]. The data set includes the precise location of the satellite in WGS 84 ECEF coor-
dinates for each 15-minute period. An interpolation method can then be used to
183
184 Other Server-Side Improvements and Controls
accurately predict the location of the satellites for any given time. A review of the
different interpolation strategies can be found in [3].
The expected accuracy of the calculated location of the satellites is in the vicin-
ity of 5 centimeters [3]. This translates to an improved calculated location.
9.1.2 Troposphere Modeling

The troposphere exists from the Earth’s surface to an altitude of about 50 kilome-
ters and consists of nitrogen, oxygen, and water vapor. As the GPS signal propa-
gates from the satellite to the handset, it experiences a delay caused by refraction of
the signal due to the gaseous content of the troposphere. GPS signals traveling
through the troposphere will be affected by a tropospheric refraction delay, which
can be around 2 meters for satellites at the zenith or up to 20 meters for signals from
satellites that are low on the horizon. However, the delay is typically in the range of
2 to 10 meters. Dry atmospheric effects are easily modeled and account for 90% of
the troposphere [4]. There is no specification of troposphere modeling in the GPS IS
[5], so the position calculation may choose any model. The accompanying code
implements the Hopfield troposphere model [6] in the class
HopfieldTroposphereModel, which was described in Chapter 6. Another popular
model is the Saastamoinen model [7], which can be used to model the tropospheric
delay.
The tropospheric delay is a function of temperature, pressure, and relative
humidity, and the Hopfield model uses estimates of that to make the appropriate
corrections.
The wet component is difficult to model, but an improvement can be made by
using real data such as that available in Europe from the European Centre for
Medium-Range Weather Forecasts (ECMWF).
Note that the distribution of water vapor is irregular and it is not possible to
obtain good estimates of wet tropospheric delays from surface measurements only.
A radiosonde profile can provide the temperature, pressure, and humidity at vari-
ous altitudes, and the LS can use this to generate a more accurate delay prediction
[8].
Some troposphere models make it possible to derive local air pressure values
from the model parameters. This air pressure reference could be used to assist
barometers for altitude assistance. This would be extremely valuable, especially in
urban areas where the satellite geometry and hence DOP is often poor.
Another option is to use a regional tropospheric delay modeling reference net-
work to model the delays in a specific region, for example, a specific coverage area.
An example of a regional system is discussed in [9].
9.1.3 Ionosphere Modeling

As discussed in Chapter 3, there is a significant variation in the ionosphere from day
to day and also within a day. The ionosphere delay is a function of the total electron
content (TEC), and the broadcast model generally removes about 50% of the iono-
spheric delay when using a single frequency receiver. These errors can be improved
using TEC maps such as those provided by JPL [10].
9.2 Location Integrity
In the previous section, improvements to the accuracy of the location were dis-
cussed. In this section, some strategies and mechanisms for improving the integrity
of a calculated location are discussed.
Once the LS determines the location of a handset, the location is provided to the
network entity that requested it (for example, an MLP client). If the LS is trusted by
the entity, then the location will be considered to be valid. This is a problem if the
location provided is a falsified location and not the true location of the handset.
The integrity of the location calculated by the LS (in cooperation with the hand-
set) is critical because it may be used by emergency services operators to find an
injured person or the location of an accident. It may also be used to gain access to
services that are restricted to a certain area. One example is when a user fraudu-
lently gains access to a broadcast that is restricted to a particular set of geographi-
cally located users. Other examples include a target that is being tracked and does
not want the tracker to know his or her correct location, spoofing the location of a
shipment that is being remotely tracked, or even disguising criminal activities by
deceiving a law-enforcement location-based application (LBA).
One example of a system where an operator may be motivated to deceive a GPS
receiver in order to make a financial gain is in the area of commercial fishing. In
Europe, vessels are required to carry a device that logs their location so that the area
in which the vessel is fishing can be later checked in order to ensure they are only
fishing where it is legal for them to do so [11].
The aim of the spoofer (or attacker) is to convince the LS to provide the location
that the attacker desires. The attacker does this by falsifying (or spoofing) the loca-
tion or the measurement data so that the location provided by the LS is effectively
predetermined by the attacker. The attacker may be an unscrupulous user or inter-
mediary that changes the software in the handset to manipulate the measurements.
In this section, the mechanism for location assurance is discussed along with
measurement spoofing. Both methods are employed by the LS to reduce the chance
of a location being calculated incorrectly.
9.2.1 Location Assurance

Location assurance is the process of validating, or sanity checking, a location that
has already been calculated. The LS normally applies this mechanism to all location
methods that are calculated by the handset (for example, handset-based A-GPS) or
to location methods that use measurements made by the handset (for example,
handset-assisted A-GPS). It is not generally required for a location calculated on the
server to use information provided by the network (for example, TA-based location
in a GERAN network or one calculated from RTT measurements in a UTRAN net-
work), since the measurements come from trusted entities.
The simplest form of location assurance for handset-based A-GPS is to sanity
check the distance from the location to the cell tower. That is, when the LS receives
the handset-based location, it calculates the distance between that location and the
location of the cell tower. If the location is further than a configured distance from
the tower, then the location is deemed to be invalid by the LS and hence is not
passed on.
An alternative is to determine whether the location is within the defined area of
the cell. The LS will generally have a database that contains not only the location of
the cell tower, but will have additional information such as the orientation and
opening of the antenna and also its range. The LS can determine whether the loca-
tion is within those bounds, and if not, the location is deemed invalid.
A more precise mechanism is to use other measurements from the network to
validate the location. For example, in a UTRAN network, the location can be vali-
dated against the RTT measurements that are sourced from within the trusted net-
work. The RTT measurements are range measurements from one or more base
stations at known locations. If the reported location is outside the bounds of the
individual range measurements, then the location is deemed to be invalid by the LS.
The GpsPositionCalculation.performLocationAssuranceCheck() method per-
forms the location assurance checking. It is configured with a distance in meters
above which the location is deemed to be invalid.
There will be situations where the initial location of the handset is not well
known, for example, if the A-GPS handset reports a cell that is not in the database.
In this situation it is still possible for the LS to calculate the location of the handset
by performing a location calculation using the Doppler initially, followed by a code
phase-based position calculation (as discussed in Chapter 6). The location assur-
ance check can still be applied to this situation; however, if the handset has falsified
both the Doppler and the code-phase measurements, then the location assurance
check is ineffective.
9.2.2 Antispoofing
Location assurance was discussed in the previous section and it applies to checking,
or validating, a location that has already been calculated. Antispoofing, on the
other hand, is a technique that can be applied to help identify whether the measure-
ments are falsified and hence invalidate the calculated location. This gives a more
fine-grained mechanism than location assurance to detect attackers and provides a
mechanism for the analysis of the location when location assurance cannot be per-
formed, such as when there are no independent location technologies to assure the
location of the handset.
Antispoofing is more fine-grained than location assurance because location
assurance is subject to the resolution of the location technology used to perform it.
For example, if the cell location is the only information available to validate the
location, then a spoofer is able to simulate a location anywhere within the boundary
of the cell, which may be a large area for larger cells, for example, tens of
kilometers.
Generally, the LS requires the handset to provide true and accurate measure-
ments (and not false ones) in order to calculate an accurate location. Spoofing is the
process whereby the handset provides falsified measurements to the server in order
that the server calculates an incorrect location for the handset. In this section, the
effect of spoofed measurements provided to the LS is discussed and a basic mecha-
nism to detect spoofed measurements is outlined. This is in contrast to most spoof-
ing research, which has been focused on detecting false radio frequency signals
arriving at the GPS receiver front-end [12] and also authenticating location results
provided to a third party.
As discussed previously, the A-GPS capable handset provides the following
per-satellite measurement elements to the LS: code phase, Doppler, signal-to-noise
ratio, multipath indicator, and pseudorange RMS error. A naïve LS will perform a
position calculation using the measurements as provided and the result will then be
passed on to the network entity that requested it. If the LS is trusted by the entity,
then the location will be considered by that entity to be valid, and the attacker
succeeds.
In the case in which the A-GPS handset is an attacker, and the LS has no defense
mechanism in place, the attacker does not need to measure the signals from the sat-
ellite at all, but can generate the measurements that will result in its desired location
being provided ultimately to the LBA. If the desired location is within a few hundred
kilometers of the attacker’s present location, the handset can simply download the
NAV message from the satellites that are in view.
Once the handset has the NAV message, it can calculate the location and veloc-
ity of the satellites, introduce errors such as ionosphere errors using the ionosphere
model and an additional error model, and generate simulated satellite code phase
and Doppler measurements to send to the LS based on the desired location of the
handset. If the attacker needs to generate a location for somewhere remote from the
current location, a feed of ephemeris data from a network source is required in
order to obtain the information for satellites that the attacker cannot see and hence
cannot get the NAV message.
There are several ways for the server to perform spoofing detection. Some sim-
ple methods are described in the following sections.
9.2.2.1 Antispoofing Through Doppler Spoof Detection

As discussed in Chapter 6, Doppler shift occurs because the GPS signal travels at the
speed of light and the rate of change of the range between the satellite and the
receiver stretches or compresses the wavelength that is effectively measured at the
receiver. When a satellite is approaching the receiver, the frequency will be
increased slightly and when the satellite is receding, the frequency is reduced.
The expected Doppler shift can be calculated given the calculated location. The
measured Doppler shift can be checked against this to determine whether it is
expected. This is a coarse method of spoof detection because Doppler does not have
sufficient resolution (several kilometers); however, it has much better resolution
than a cell (up to tens of kilometers). The expected Doppler shift is compared
against the measured value, and if it is outside the threshold, then the location can
be consider as being spoofed.
The Doppler in hertz (D) is calculated as the dot product of the difference in
velocities between the satellite and the receiver and the estimated line of sight vector
as shown in
⎛ v − vr $ ⎞
D=⎜ s ⋅ls⎟f (9.1)
⎝ c ⎠
where vs is the velocity of the satellite, vr is the velocity of the receiver, c is the speed
of light, l$s is the estimated line of sight unit vector, and f is the transmitted frequency
of L1, which is 1,575.42 MHz. The c and f scalars convert the result from ms−1 to
Hz.
The line-of-sight vector is calculated as the difference between the satellite and
the receiver location divided by the norm of the difference and is shown in
r − r$r
l$s = s (9.2)
rs − r$r
9.2.2.2 Antispoofing Through Analysis of Residuals

When GPS measurements are made, there are many factors that affect the accuracy
of each individual range measurement and hence the resulting location. Some of the
factors are ionosphere error, troposphere error, handset measurement error, and
ephemeris error. As discussed in Chapter 6, one of the outputs of the least squares
process is the residuals.
The residuals indicate how much the measurements are changed in order to fit
the solution and reflect the errors that are in each measurement. The key aspect of
determining whether the code phases are spoofed is whether the residuals reflect the
errors that are normally measured. When the residuals are below the normal range,
then it is a good indicator that the input measurements have been spoofed.
Table 9.1 shows the calculated SSR for successful location calculated from a
handset-assisted A-GPS SUPL client. These come from the logs from the LS. The
handsets reporting the measurements had eight satellites in view.
A receiver is in the open sky making measurements to the satellites. A position
calculation is performed and the SSR is logged. The SSR statistics for the different
numbers of satellites in view is shown in Table 9.2. The results are from a good
quality reference receiver that is continually tracking the GPS satellites and has been
doing so for more than 5 years. The receiver is a NovAtel OEM2 that is installed in
Table 9.1 SSR for a Typical

A-GPS Handset in the Field
Number SSR
of Visible
Satellites
8 634.620
8 493.117
8 7,560.866
8 271.024
8 2,249.028
8 7,475.900
8 1,295.041
8 1,876.897
8 206.079
8 1,300.849
Table 9.2 SSR Statistics from the NovAtel GPS Reference Receiver for
Different Numbers of Satellites
Number of Standard
Visible Number of Average Deviation
Satellites Observations SSR of SSR SSR 67% SSR 95%
5 173,211 6.66 ,13.61 8.39 13.86
6 2,268,482 17.53 ,27.75 22.09 36.47
7 11,589,266 28.85 ,376.38 36.35 60.01
8 25,602,257 52.46 4,448.57 66.10 109.12
9 25,122,525 54.88 709.62 69.15 114.16
10 14,179,154 71.04 876.96 89.51 147.77
11 7,208,648 71.20 131.68 89.71 148.09
12 1,568,299 78.86 120.26 99.37 164.04
the laboratory. The data set consists of 87,713,876 individual measurements of the
satellites in view of the receiver.
The trend is as expected; more satellites result in more total error in the mea-
surements (SSR increases). The relationship between the number of satellites and
the SSR is almost linear. That is, as an extra satellite is considered, the SSR increases
by a reasonably constant amount.
Since this is a good quality receiver operating in the open sky, this can be consid-
ered as a baseline for spoof detection. For example, if a handset that reports 8 satel-
lites results in an SSR of less than 52.46, then it may be considered to be a spoofer;
however, this parameter could be tuned.
Recently, a SUPL handset in the field was found to be spoofing an LS. This was
discovered during an interoperability testing (IOT) exercise. The data from several
location calculations is shown in Table 9.3.
The handset is considered to be a spoofer because the SSR is very low. The
chipset supplier confirmed that it was spoofing the code phases that it was sending
to the LS. It was not trying to intentionally cause harm, but instead of measuring the
code phases, it was generating them based on its own handset-based location calcu-
lation result (which happened to be incorrect).
The following are the software projects for this chapter:
1. Run some analysis on data from a RINEX file to see how the SSR is affected
by different numbers of satellites. Tune the SPOOFING_SSR_LIMIT
constant in the GpsPositionCalculation class, which has a different level
depending on the number of satellites in the measurement.
2. Write a class that attempts to spoof the measurements provided to the
position calculation. Try running it with and without the call to
checkIfMeasurementsSpoofedSsrAnalysis() commented out.
3. Implement the Doppler shift-based antispoofing method.
Table 9.3 SSR Values

from the Spoofing
SUPL Client
Number of
Visible
Satellites SSR
8 3.756
8 2.111
8 2.392
8 2.243
8 2.232
8 2.252
8 2.778
8 3.546
8 2.535
8 1.897
References
[1] Dow, J. M., R. E. Neilan, and G. Gendt, “The International GPS Service (IGS): Celebrating
the 10th Anniversary and Looking to the Next Decade,” Adv. Space Res., Vol. 36, No. 3,
2005, pp. 320–326.
[2] IGS, http://igscb.jpl.nasa.gov/.
[3] Schenewerk, M., “A Brief Review of Basic GPS Orbit Interpolation Strategies,” GPS Tool-
box, National Geodetic Survey, 2003.
[4] Spilker, J. J., and B. W. Parkinson, “Overview of GPS Operation and Design,” in Global
Positioning System: Theory and Applications, Vol. 1, Washington, D.C.: American Insti-
tute of Aeronautics and Astronautics, Inc., 1996.
faces, Interface Specification, IS-GPS-200, Revision D, Navstar GPS Joint Program Office,
El Segundo, CA, 2004.
[6] Spliker, J. J, “Tropospheric Effects on GPS,” in Global Positioning System: Theory and
Applications, Vol. 1, Washington, D.C.: American Institute of Aeronautics and Astronau-
tics, Inc., 1996.
[7] Saastamoinen, J., “Atmospheric Correction for the Troposphere and Stratosphere in Radio
Ranging of Satellites,” in The Use of Artificial Satellites for Geodesy, Geophys. Monogr.
Ser., Vol. 15, S. W. Henriksen, A. Mancini, and B. H. Chovitz, (eds.), Washington, D.C.:
AGU, 1972, pp. 247–251.
[8] Mekik, C., “Tropospheric Delay Models in GPS,” Intl. Symp. on GIS/GPS, Istanbul, Tur-
key, September 15–18, 1997.
[9] Yin, H., D. Huang, and Y. Xiong, “Regional Tropospheric Delay Modeling Based on GPS
Reference Station Network,” International Association of Geodesy Symposia, VI
Hotine-Marussi Symposium on Theoretical and Computational Geodesy, February 27,
2008.
[10] NASA Global Ionospheric (TEC) Maps, http://www.gdgps.net/products/tec-maps.html.
[11] Commission Regulation (EC) No 2244/2003, “Laying Down Detailed Provisions Regard-
ing Satellite-Based Vessel Monitoring Systems,” Official Journal of the European Union, L
333/17, 20.12.2003, December 18, 2003.
[12] Montgomery, P. Y., et al., “Receiver-Autonomous Spoofing Detection: Experimental

Results of a Multi-Antenna Receiver Defense Against a Portable Civil GPS Spoofer,” Pro-
ceedings of the 2009 International Technical Meeting of the Institute of Navigation, Ana-
heim, CA, January 26–28, 2009.
CHAPTER 10
Assisted-GNSS
As mentioned in Chapter 1, the basic task of a GNSS assistance data server is to pro-
vide assistance data to a GNSS-enabled handset in order to improve the time to first
fix and the yield. In addition, the LS often provides the position calculation as well,
in order to reduce the size of the assistance data required and make use of additional
measurements that it can retrieve from the network.
All of the associated implementation and description in the book up to now has
used one example of a GNSS, that is, GPS. In addition, it has been focused on the
first civilian signal, GPS L1. A lot of the information applies to the other GNSSs at a
high level, that is, they broadcast a navigation message, they all have a ranging sig-
nal, and they use their own time reference. There will be a large number of naviga-
tion-enabling satellites in orbit in the future, which means that an A-GNSS receiver
has access to many more satellites than it does at present. That will significantly
increase accuracy and yield, especially in areas where it is presently difficult to cal-
culate a location, such as urban canyons.
This chapter generalizes the previous work in the book to A-GNSS and also dis-
cusses some of the issues associated with an A-GNSS server compared to an A-GPS
server. It discusses the differences in the protocols and how the server can make use
of measurements from more than one GNSS.
10.1 Assisted-GNSS
A GNSS is a system with global coverage that allows a GNSS-capable handset to

make measurements that have been transmitted from satellites in order to accu-
rately determine its own location. This section briefly introduces the other GNSSs
(besides GPS) and augmentations that either are in the planning stage or have been
deployed. Note that a GNSS augmentation is a system that is external to the GNSS
but can be used to improve the performance of the GNSS by providing additional
information such as corrections or integrity information.
Similarly to GPS, all GNSSs consist of a space segment and a ground control
segment. The control segment generally consists of a network of monitoring sta-
tions and a master control station. The monitoring stations provide data to the mas-
ter control station that predicts the orbits, determines the broadcast model, and
then uploads that information to the satellites. The satellites transmit a ranging code
and the broadcast information on specific frequencies. The handset can then make
measurements of the pseudorange and the Doppler in order to perform a position
calculation.
193
194 Assisted-GNSS
Many of the GNSSs are still in the planning and deployment stage and details
will change, so they are only discussed in this chapter in general terms. Specific
details about the constellations, signals, and broadcast messages can be obtained
from the International Committee on Global Navigation Satellite Systems (ICG)
[1].
10.1.1 GLONASS
The GLONASS system is developed and managed by the Russian Federal Space
Agency. A fully operational constellation consists of 24 satellites. A fully opera-
tional constellation means that a minimum of five satellites are visible at any given
time. At present, the satellite transmissions use the frequency division multiple
access (FDMA) technique in which each satellite uses a separate channel, or fre-
quency band, and has a standard precision (SP) and high precision (HP) signal at
different clock rates. In addition, the HP signal has a larger bandwidth than the SP
signal. GLONASS is presently undergoing a modernization effort, which includes
transmitting in CDMA in order to improve compatibility with other GNSSs.
The GLONASS Information-Analytical Center (IAC) provides information
about the status of GLONASS [2] from the GLONASS control center. It also hosts
the current version of the GLONASS ICD [3], and is the source of precise ephemeris
for GLONASS.
GLONASS uses the PZ 90 coordinate reference system, which differs from
WGS 84 by less than 0.4 meters in any direction. The ground control segment and
the network of command and tracking stations are entirely located within the terri-
tory of Russia.
GLONASS has its own time scale called GLONASS time, which is synchronized
within 1 second of UTC (offset by 3 hours). The navigation message has the data to
convert between GLONASS time and UTC time. When a leap second is added to
UTC, it is also added to GLONASS time.
The GLONASS L1 signal is modulated with a pseudorandom ranging code, the
navigation message, and an auxiliary meander sequence [3]. The ranging code has a
period of 1 millisecond with a bit rate of 511 kilobits per second. The navigation
data is transmitted at 50 bits per second and consists of immediate and
nonimmediate portions, where the immediate data relates to the satellite transmit-
ting the information and the nonimmediate data relates to the other satellites in the
constellation.
The navigation message is split into superframes (duration of 2.5 minutes),
which contain 5 frames (duration 30 seconds), and each frame consists of 15 strings
(2 seconds each). The string is 2 seconds long and contains 85 bits of navigation
data and the time mark. Similar to the GPS ICD, the GLONASS ICD contains the
algorithms to calculate the location of the satellites at a given point in time given the
ephemeris.
10.1.2 Galileo
The Galileo GNSS is presently being built and deployed by the European Union
(EU). It will consist of 30 satellites when fully deployed. The satellites transmit on
10.1 Assisted-GNSS 195
several frequencies and will provide different services for civilian use, commercial
use, and safety of life.
The Galileo satellites transmit ranging codes and also a navigation message.
The Galileo open service is specified in the Galileo OS SIS ICD [4]. The Open Ser-
vice (OS) uses the Galileo F/NAV navigation message format. The message struc-
ture is a series of frames, subframes, and pages. The frequency of repeating of data
within the message depends on the categories of the data (fast, medium, and slow
rates) and contains the time, the satellite clock correction, the satellite health, the
ephemeris, and the almanac. The navigation data contains all of the information
required to enable the handset to perform positioning. Similar to the GPS IS and the
GLONASS IS, the Galileo OS SIS ICD provides the equations that apply to the
ephemeris parameters, including calculating the location of the satellites. The equa-
tions used in Galileo to calculate the position of a satellite are similar to that for
GPS.
Galileo System Time (GST) is a sequential time scale that started at midnight
between August 21 and 22, 1999. Each time that a leap second is added to UTC, the
GST moves ahead by a second. The week number is 12 bits, which enables 4,096
weeks after which it rolls over to 0. The time of week is the number of seconds since
the start of the week and ranges from 0 to 604,800 seconds. The navigation message
includes a model to convert GST to UTC.
Galileo has a modern ionospheric model which includes broadcast storm flags
(or ionospheric disturbance) for particular regions [4].
10.1.3 Compass
Compass is a system that is presently in planning and development by the Chinese
government. It consists of 35 satellites, with 5 of them in geostationary orbit. The
ranging signals will use CDMA, similar to GPS and Galileo and consisting of two
levels of service: open and restricted. At the time of this writing, there was no pub-
licly available ICD.
10.1.4 QZSS
The Quasi-Zenith Satellite System (QZSS) is a regional navigation satellite system
that is in the development phase. It is planned that several satellites will be placed in
an orbit so that the satellites are overhead in Japan for 12 hours a day. The orbit
pattern is known as a highly inclined elliptical orbit (HEO). Since the satellites are
high in the sky, they will suffer less from obstruction from tall buildings or moun-
tains. This will increase the availability (yield) for performing a satellite-based posi-
tion calculation. In a dense city, the position yield will go from about 40% to
90%–100% [5]. In addition, VDOP will be improved, which means that a
QZSS-capable handset will be able to calculate the altitude more accurately.
The QZSS will transmit a ranging and navigation message that is similar to (and
compatible with) GPS, but will have additional augmentation information trans-
mitted on a new signal. The augmentation information will be correction data and
integrity data [6]. The satellites use the modernized GPS as a base, transmitting the
L1 C/A, L1C, L2, and L5 signals, in order to minimize the changes to receiver
196 Assisted-GNSS
designs. The QZSS consists of satellites and a ground segment that consists of an
MCS and monitoring stations (MS).
The QZSS uses the time base for GPS with a controlled offset from GPS time.
For representing coordinates, it uses the Japan satellite navigation Geodetic System
(JGS), which is referenced to the International Terrestrial Reference System (ITRS).
The coordinate offset between JGS and WGS 84 shall be 0.2 meters or less [6]. The
navigation message is the same as that broadcast by GPS.
10.1.5 WAAS
The Wide Area Augmentation System (WAAS) is a GNSS augmentation that pro-
vides information about the GNSS satellites and also provides a GPS ranging signal.
The system consists of receiver stations deployed in North America and Hawaii,
several wide-area master stations, and geostationary satellites [7]. The master sta-
tions located on each coast of the United States collect data from the network of ref-
erence stations and calculate correction data. The correction data is then broadcast
on L1 from one of the geostationary satellites. The details of the WAAS are
provided in the WAAS specification [7].
The WAAS provides corrections for GNSS satellite positions and the satellite
clock error. It also provides ephemeris corrections and ionospheric delay informa-
tion. The localized ionospheric delay information is the component that signifi-
cantly increases the accuracy of the location that the handset makes. The
ionospheric delays are provided as corrections for a number of points (organized in
a grid pattern) for the WAAS service area.
The geostationary satellites transmit the same ranging signal as the GPS satel-
lites so it can be used as an additional range measurement (the range of PRNs for
WAAS ranging codes are from 120 to 138 and are compatible with GPS). Since the
satellites are high in the sky, they increase the VDOP, which leads to an improved
vertical accuracy in the calculated location. The WAAS broadcasts on a single car-
rier frequency of GPS L1.
The WAAS transmits data at 250 bits per second and consists of different mes-
sages as defined by the message type. The WAAS has its own time definition and is
maintained to be within 50 nanoseconds of GPS time. The WAAS provides the
parameters to convert between the time scales.
10.1.6 EGNOS
The European Geostationary Navigation Overlay Service (EGNOS) is a system that
provides GPS and GLONASS corrections for GNSS users in Europe. Similar to the
WAAS, it provides several geostationary satellites and a network of ground stations
that monitor satellite signals. The GEO satellites provide corrections to users that
(similarly to the WAAS) allow a five- to tenfold accuracy improvement over using a
GNSS alone. The EGNOS is similar to the WAAS in that the primary accuracy
improvement comes from accurate location specific ionosphere corrections. It also
provides correction over the Internet from SISNeT [8].
The WAAS and EGNOS messages are compatible, so the same receiver can
make use of the signals from both systems.
10.2 Protocols 197
10.1.7 Others
There are several other augmentations and regional satellite systems that are in vari-
ous stages of design and deployment and they are discussed briefly in this section.
The Indian Regional Navigational Satellite System (IRNSS) is a regional naviga-
tion system that will provide service in the Indian region and is in the planning
stages.
The Multifunctional Satellite Augmentation System (MSAS) is a SBAS that is
developed in Japan and is compatible with WAAS and EGNOS. The GPS Aided
Geo Augmentation Navigation (GAGAN) is the other SBAS that is being developed
in India and will also be compatible.
The Local Area Augmentation System (LAAS) is an aircraft landing system that
provides differential GPS corrections over a VHF data link to the GPS receiver. The
Ground-based Regional Augmentation System (GRAS) also provides differential
corrections over a VHF link and is being developed in Australia.
10.2 Protocols
The assistance data protocols (RRLP, PCAP, RRC, and TIA-801) initially only sup-
ported GPS L1 C/A code assistance. Support for modernized GPS, the other GNSSs,
and the SBASs has been added over the last few years. In the protocol standards, it
has been named Galileo and Additional Navigation Satellite Systems (GANSS).
In this section, we explore support for A-GNSS through the RRLP specification
[9]. In this chapter, the fields are not discussed at the encoding level, so the informa-
tion will equally apply to PCAP, RRC, and TIA-801. In Tables 5.1, 5.2, and 5.3, the
important fields from the position request, position response, and assistance data
messages were listed and outlined. In this section, they are explored further from the
GNSS point of view.
When reading this section, it is best to have the RRLP specification nearby.
10.2.1 GANSS Position Request

In Table 5.1, the important fields from the position request were listed and
described at a high level. In this section, the GANSS fields are discussed further.
The first request from the LS to the handset in the location determination pro-
cess contains information about which positioning technologies the LS supports
and which it prefers for this particular location determination. If the LS is in a
GERAN network, it will already have the capabilities of the handset from the class
mark information, or in a UTRAN it will be in the request message. However, for
an SLP it will not necessarily know what the handset supports, so in that case, it will
generally provide all of the positioning types that are supported by the LS. The Posi-
tioning Instructions field is used by the LS to tell the handset the requested (or
allowed) location technology methods. The GANSS Positioning Method Element is
a bitmap within the Positioning Instructions field where one or more bits can be set
to indicate the positioning technologies that can be used. This bitmap can be set to
one or more of the available options, for example, any or all of GPS, Galileo, SBAS
198 Assisted-GNSS
(WAAS, EGNOS, MSAS, GAGAN), Modernized GPS (L1C, L2C, L5), QZSS, and
GLONASS.
The ASN.1 for the GANSS Positioning Method from RRLP is shown here:
— additional satellite systems may be added in future versions of the protocol
GANSSPositioningMethod ::= BIT STRING {
gps (0),
galileo (1),
sbas (2),
modernizedGPS (3),
qzss (4),
glonass (5) } (SIZE (2..16))
The handset will look at this bitmap and, depending on its capabilities, will
respond with the list of the location technologies for which it is capable of using and
needs assistance data. Note that if it already has current assistance data cached, it
will respond with the measurements (handset-assisted) or the location
(handset-based).
The GANSS Carrier-Phase Measurement Request Element is a flag in the posi-
tion request that allows the LS to request carrier phase measurements (compared to
usual code-phase used in SPP) in handset-assisted mode. If present, the handset, if
capable, will make carrier phase measurements for all of the location technologies
that it supports, provided that they were in the Positioning Instructions Element.
The GNSSs support more than one frequency and the LS can request that the
handset returns more than one satellite frequency when operating in hand-
set-assisted mode. The GANSS Multi-frequency Measurement Request Element is a
flag that requests the handset the measurement for more than one signal, for exam-
ple, if it is requesting that the handset return measurements for modernized GPS, it
may request measurements from both L2C and L5.
10.2.1.1 GANSS Assistance Data

The GANSS assistance data is provided to the handset either by default in the initial
request, or is the result of the handset sending a response indicating which assis-
tance data types that it requires. The assistance data can be large, so it is important
that the handset support the GNSS for which the data is being sent.
The GANSS assistance data is split into two separate types: the GANSS Com-
mon Assistance Data and the GANSS Generic Assistance Data. The common assis-
tance data is provided at most once and contains the information that is common to
all of the GNSSs. The generic assistance data contains the assistance data specific to
a GNSS and occurs once for each GANSS location technology that is being sent. For
example, if a handset supports GLONASS and Galileo, the LS will send the com-
mon assistance data and two instances of the generic assistance data—one for
GLONASS and one for Galileo.
The RRLP ASN.1 definition for the GANSS Common Assistance Data is shown
here:
— GANSS Common Assistance Data Elements
GANSSCommonAssistData ::= SEQUENCE {
ganssReferenceTime GANSSReferenceTime OPTIONAL,
ganssRefLocation GANSSRefLocation OPTIONAL,
ganssIonosphericModel GANSSIonosphericModel OPTIONAL,
... ,
ganssAddIonosphericModel GANSSAddIonosphericModel OPTIONAL,
10.2 Protocols 199
ganssEarthOrientParam GANSSEarthOrientParam OPTIONAL

}
The GANSS reference time provides the time fields for a specific GANSS. The
GANSS that the time is for is specified by the GANSS_TIME_ID field, which is
Galileo system time (GST), GPS time, QZSS time, or GLONASS system time.
The GANSS reference location is the location with uncertainty in the WGS 84
coordinate reference frame. This location normally comes from the cell tower loca-
tion and range (and possibly orientation and opening) and is specified by one of the
shapes in the GAD specification [10]. For an omnicell this will normally be the
shape Ellipsoid Point with uncertainty circle. If the cell is a sector, that is, it has an
orientation and opening, then the shape will be an Ellipsoid Arc.
The GANSS ionospheric model is the ionosphere model that is defined by the
Galileo ICD [4]. The Galileo ionosphere model consists of some parameters to
model the ionosphere delay and contains storm flags for specific regions of the
Earth.
The GANSS additional ionospheric model contains the parameters for the
Klobuchar model that is transmitted by GPS [11] and can be applied globally. The
model contains the field Data ID to indicate the area of applicability for the model.
For example, it can be set to a value that indicates that it is only applicable to the
coverage area of a specific GNSS, for example, the QZSS [6].
GANSS Earth orientation parameters contain the parameters to convert
between ECI and ECEF as defined in the GPS IS [11]. These parameters model the
relationship between the Earth’s rotational axis and WGS 84.
The RRLP ASN.1 definition for the GANSS Generic Assistance Data is shown
here:
— GANSS Generic Assistance Data Elements
GANSSGenericAssistDataElement ::= SEQUENCE {
ganssID INTEGER (0..7) OPTIONAL,
ganssTimeModel SeqOfGANSSTimeModel OPTIONAL,
ganssDiffCorrections GANSSDiffCorrections OPTIONAL,
ganssNavigationModel GANSSNavModel OPTIONAL,
ganssRealTimeIntegrity GANSSRealTimeIntegrity OPTIONAL,
ganssDataBitAssist GANSSDataBitAssist OPTIONAL,
ganssRefMeasurementAssist GANSSRefMeasurementAssist OPTIONAL,
ganssAlmanacModel GANSSAlmanacModel OPTIONAL,
ganssUTCModel GANSSUTCModel OPTIONAL,
ganssEphemerisExtension GANSSEphemerisExtension OPTIONAL,
ganssEphemerisExtCheck GANSSEphemerisExtensionCheck OPTIONAL,
... ,
sbasID INTEGER (0..7) OPTIONAL,
ganssAddUTCModel GANSSAddUTCModel OPTIONAL,
ganssAuxiliaryInfo GANSSAuxiliaryInformation OPTIONAL
}
The GANSS Generic Assistance Data is repeated for each GANSS for which
specific assistance data is being provided. Each instance of the GANSS Generic
Assistance Data includes an identifier to indicate which location technology that the
assistance data is for (GANSS ID).
GANSS ID is the identifier of the GNSS for which assistance data is included in
this GANSS Generic Assistance Data. If this ID is missing, then the assistance data
is for Galileo. Otherwise, it could be set to, for example, SBAS, modernized GPS,
QZSS, or GLONASS. If it is set to SBAS, then the particular SBAS is indicated by the
SBAS ID field.
The GANSS time model specifies the model to relate the GNSS system time to a
different GNSS time model. As noted in the previous sections, each of the GNSSs
200 Assisted-GNSS
has its own time models and this data type allows the handset to map the time for
the GNSS specified in this GANSS Generic Assistance Data to the time of one or
more other GNSSs. The LS can specify the relationship to more than one GNSS time
model by including this time model more than once.
GANSS differential corrections specifiy the differential corrections for this
GNSS.
The GANSS navigation model provides the navigation model for this GNSS
(specified by the GANSS ID) to the handset. The LS can provide the navigation
model as Keplerian parameters discussed earlier in this book or as state vectors in
ECEF coordinates. Interpretation of the navigation model fields depends on the par-
ticular GNSS, for example, if the GANSS ID indicates that the assistance data is for
modernized GPS, then the GPS specification is used to interpret the parameters.
Unlike the GPS specific navigation model (not GANSS), which only allows the LS to
transmit 16 satellites, this navigation model allows the LS to send up to 32 satellites.
Note, however, that the LS will normally know the approximate location of the
handset and from that it will determine the satellites that are in view of the handset.
It will then package the assistance data so that it contains the data for that set of
in-view satellites.
The GANSS real-time integrity provides a list of the satellites that are consid-
ered bad for this GNSS. The GRS deems that satellites are bad based on monitoring
and provides this list to the LS. The LS does not provide the other assistance data
types for the bad satellites, so a handset with nothing cached, for example, if it has
just performed a cold start, will not need to use this field because no assistance data
in the other fields will be sent for the bad satellites. Handsets with cached data,
however, can use this to invalidate data that it has already cached.
The GANSS data bit assistance allows the LS to provide the handset with
per-satellite information about the expected bits that are modulated on the broad-
cast message. If the handset knows the bits that are arriving, it can adjust its search
accordingly, which allows it to achieve greater sensitivity.
The GANSS reference measurement is the acquisition assistance information
for this GNSS given the reference location. The LS calculates the acquisition assis-
tance based on the reference location that normally comes from the cell location.
This reference location may be refined based on measurements from the cellular net-
work, such as RTT in a UTRAN network.
The GANSS almanac model provides the coarse long-term model of the satellite
orbital parameters and can be used by the handset to determine the approximate
location of the satellite in order to narrow the search space in the absence of other
more accurate information such as the ephemeris. Similarly to the GANSS naviga-
tion model, the parameters are interpreted depending on the specific GNSS, for
example, for Galileo, the Galileo OS SIS ICD is used.
The GANSS UTC model contains the parameters to relate the time from this
GNSS to UTC time as defined by UTC (NICT). UTC is maintained by the BIPM,
and the physical realizations of UTC (named UTC(k)) are maintained by national
meteorological institutes. The National Institute of Information and Communica-
tions Technology (NICT) is the institute in Koganei, Japan. The QZSS is related to
this time. To relate to other realizations of UTC, the GNSS additional UTC model is
used.
10.2 Protocols 201
In the GANSS ephemeris extension parameters are similar to the GPS extended
ephemeris, but are specific to the GNSS for which this data type is specified. The
GANSS ephemeris extension contains corrections to the ephemeris based on a
long-term model of the satellite orbit that the LS predicts.
In the GANSS ephemeris extension check parameters provide information
about unforeseen events for a specific satellite between the times specified. The
GANSS ephemeris extension check indicates that the extended ephemeris for that
satellite is not valid for that particular duration.
The GANSS SBAS ID is the identifier of the SBAS for this the GANSS assistance
data. It is included if the GANSS ID indicates that this assistance data is for an
SBAS.
The GANSS additional UTC model is used to relate the time for this GNSS to a
realization of the UTC time known as UTC(k). The UTC model to which it is real-
ized is specific to the GNSS, for example, the modernized GPS is realized to
UTC(USNO) and QZSS is realized to UTC(NICT).
GANSS auxiliary information is used by the LS to provide per-satellite informa-
tion to the handset. For each satellite for which the LS chooses to send information,
it can specify the signals available for that satellite. For example, if the GANSS assis-
tance data is for modernized GPS, it specifies whether this satellite supports which
(or all of) L1C, L2C, and L5 signals. In addition, if the GANSS ID is GLONASS, the
channel number associated with the satellite can be specified.
10.2.2 GANSS Position Response

In Table 5.2, the important fields from the position response were listed and
described at a high level. In this section, the GANSS fields are discussed further.
When the first position request is sent to the handset, it may not have current
assistance data. In this case, it will indicate that it needs specific assistance data to
the LS in the Location Information Error field. For a GANSS location determina-
tion it will return an error code in the Error Reason field that indicates GANSS
assistance data missing. The Additional Assistance Data field of the Location Infor-
mation Error will include list of GANSS assistance data types required.
Other fields related to GANSS are for the handset to report the calculated loca-
tion (handset-based A-GNSS) or for handset to report the measurements to the LS
to perform the position calculated (handset-assisted A-GNSS).
GANSS location information provides the location of the handset in the WGS
84 coordinate reference frame. The field also contains a bitmap with one or more of
the satellite systems that were used to calculate the location and the time that the
location was calculated.
GANSS measurement information includes the per-satellite measurements in
order for the LS to calculate the location of the handset. The LS should make use of
all of the measurements that it has received in order to calculate the location of the
handset and may optionally combine other measurements from the network, for
example, RTT measurements in a UTRAN network.
202 Assisted-GNSS
10.3 Using Multiple GNSSs and Signals
As discussed previously, there are significant improvements in accuracy and yield

when more satellites are available for the position calculation. When LS can support
more than one GNSS, it has a significant advantage once the handsets support more
than one GNSS.
In terms of yield, there will be more satellites in the sky so at any given time
there is a much greater chance for the handset to be able to pick one up. This will be
particularly useful in low signal environments such as urban canyons. At present,
the handset is unlikely to get enough satellites in order to make a fix, but when there
are more satellites, there will be more satellites high in the sky, so at any one time
you will get a fix where previously one was not possible.
Accuracy will be improved because dilution of precision (DOP) is improved.
The main factor affecting accuracy of a GPS fix is the geometry of the satellites
(hence DOP). More satellites mean that more satellites can be used for the position
calculation and the resulting location will be more accurate. The second most signif-
icant factor in a position fix is the delay that is introduced into the range measure-
ments by their propagation through the ionosphere. A dual-frequency receiver can
eliminate the effect of the ionosphere and is enabled by taking measurements at two
different frequencies. For example, a GPS L1 and L2C receiver will allow the effect
of the ionosphere to be corrected, which will result in a higher accuracy fix.
References
[1] International Committee on Global Navigation Satellite Systems (ICG),

http://www.oosa.unvienna.org/oosa/SAP/gnss/icg.html.
[2] GLONASS Information-Analytical Center (IAC), http://www.glonass-ianc.rsa.ru.
[3] GLONASS Interface Control Document, version 5.0, Moscow, 2002.
[4] European Space Agency/European GNSS Supervisory Authority, Galileo Open Service, Sig-
nal In Space Interface Control Document, OS SIS ICD, 2008.
[5] Matsuoka, S., Service Status of QZSS, The Asia Pacific Regional Space Agency Forum,
Communication Satellite Application WG, December 10, 2008.
[7] United States of America Department of Transportation Federal Aviation Administration,
Specification for the Wide Area Augmentation System, 2001.
[8] SISNet, http://www.egnos-pro.esa.int/sisnet/index.html.
ing Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP), 2009.
CA, 2004.
Appendix A
Relevant Standards and Documents
This appendix contains the complete list of A-GNSS standards and relevant GNSS
specifications along with a brief description. This table contains the acronym that is
commonly used to refer to each specification, the common name, the reference to
the document, and a description of how it is used.
Table A.1 List of GNSS Standards and Documents

ASN1 ASN.1 basic notation
ITU-T X.680; Series X: Data Networks and Open System Communications; OSI
networking and system aspects—Abstract Notation One (ASN.1); Information
technology—Abstract Syntax Notation One (ASN.1): Specification of basic
notation.
ASN1 is a notation for referencing simple data types without constraining the way
that it is encoded.
ASN1 PER ASN.1 Packed Encoding Rules
ITU-T X.691; Series X: Data Networks and Open System Communications; OSI
networking and system aspects—Abstract Notation One (ASN.1); ASN.1 encoding
rules—Specification of Packed Encoding Rules (PER).
This is a set of encoding rules to achieve a compact representation of data in
binary. It is used by the A-GPS protocols to convert the messages into a binary rep-
resentation for transmission on a communications channel.
BSSAP-LE Base Station System Application Part LCS Extension
3GPP TS 49.031, Third Generation Partnership Project; Technical Specification
Group GSM/EDGE Radio Access Network; Location Services (LCS); Base Station
System Application Part LCS Extension (BSSAP-LE)
This document describes the interface between the SMLC and the BSC. It defines
the coding and procedures to support the BSSAP LCS extension.
Canadian ES The Canadian E9-1-1 requirements
Canadian Radio–Television and Telecommunications Commission, Wireless
E9-1-1 Phase 2 Stage 1 Technical Specification Recommendation Version 1.3 April
30, 2009
This document describes the Canadian emergency services model for location. It
uses the MLP interface to the GMLC and uses the emergency services MLP mes-
sages. In addition, it requires the GMLC to convert the location shape to
CircularArea and has its own special heartbeating message so that the ALI can
ensure that the connection is active.
E2 The E2 Emergency Services Interface
NENA, NENA Standard for the Implementation of the Wireless Emergency Ser-
vice Protocol E2 Interface
The E2 defines the interface for the ESME to request the location of an emergency
caller. It is a binary request response protocol. The ESME connects to the MLC
and makes requests and receives responses over the binary protocol.
203
204 Appendix A
GAD Geographic Area Description

3GPP TS 23.032 Third Generation Partnership Project; Technical Specification
Group Services and System Aspects; Universal Geographical Area Description
(GAD)
The GAD specification defines a WGS 84 location area and is used by GSM and
UMTS protocols. Areas (or locations) include ellipsoid point, ellipsoid point with
uncertainty circle, ellipsoid point with uncertainty ellipse, polygon, ellipsoid point
with altitude, ellipsoid point with altitude and uncertainty ellipsoid, and ellipsoid
arc. A GPS location, for example, would often be represented as an ellipsoid point
with altitude and uncertainty ellipsoid. The point on the ellipsoid is the latitude
and longitude, the altitude is the height, and the uncertainty ellipsoid is the error
ellipse.
Galileo ICD Galileo Interface Control Document, OS SIS ICD
European Space Agency/European GNSS Supervisory Authority, Galileo Open Ser-
vice, Signal In Space Interface Control Document, OS SIS ICD
This document describes the signals related to the open service of the Galileo
GNSS. It described the signals and their payloads.
GERAN Arch The GERAN location services architecture
Group GSM/EDGE Radio Access Network; Functional stage 2 description of
Location Services (LCS) in GERAN
This document describes the LCS architecture for GERAN.
GLONASS ICD GLONASS Interface Control Document
GLONASS Interface Control Document version 5.0, Moscow, 2002
This document describes the signals related to the GLONASS GNSS. It described
the signals and their payloads.
GPS IS GPS Interface Specification IS-GPS-200
GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User
Interfaces, Interface Specification, IS-GPS-200, Navstar GPS Joint Program Office,
El Segundo, California
The IS-GPS-200 is the evolution of the ICD-200 that includes the details of the
modernized GPS signals as they are defined. It is the ultimate reference to the
Navstar GPS system. It provides details of the constellations and the format of the
broadcast signals.
GPS IS 705 GPS interface specification for L5
GPS Navstar Joint Program Office, Navstar GPS Space Segment/User Segment L5
Interfaces, IS-GPS-705, Space and Missile Systems Center, Navstar GPS Joint Pro-
gram Office, El Segundo, California
The GPS-IS-705 describes the GPS L5 signal.
GPS IS 800 GPS interface specification for L1C
GPS Navstar Joint Program Office, Navstar GPS Space Segment/User Segment
L1C Interfaces, IS-GPS-800, Space and Missile Systems Center, Navstar GPS Joint
Program Office, El Segundo, California
The GPS-IS-800 describes the GPS L1C signal.
GPS SPS PS GPS Standard Positioning Service Performance Standard
GPS Navstar Joint Program Office, Global Positioning System Standard Position-
ing Service Performance Standard, Fourth Edition, September 2008
This document defines the minimum performance commitments of the GPS sys-
tem. It is designed to complement the GPS IS.
Appendix A 205
GPS SPS SS GPS Standard Positioning Service Signal Specification

GPS Navstar Joint Program Office, Global Positioning System Standard Position-
ing Service Signal Specification, Second Edition, June 2005
The GPS SPS Signal specification is a short version of the ICD-200 that describes
the SPS part of the GPS. The SPS is the positioning service used by civilian GPS
receivers. This specification explains the SPS in detail, but the GPS IS should be
treated as the ultimate reference document.
GRIP GNSS Reference Interface Protocol
GRIP, Open Source GNSS Reference Server GNSS Reference Interface Protocol
(GRIP) Interface Document http://sourceforge.net/projects/osgrs
GRIP is the only open protocol that has been defined between and A-GNSS server.
GRIP is an XML schema based protocol that uses HTTP to transport the requests
and responses. The request contains the list of data types required and the
response contains the data, or an appropriate error code. GRIP defines the struc-
ture of the HTTP POST that is initiated by the client and also the structure of the
XML document in the body of the request. Similarly, the response is also defined.
ILP Intermediate Location Protocol
Intermediate Location Protocol, Open Mobile Alliance, OMA-TS-ILP
ILP is the protocol used between the SLC and the SPC for SUPL. For A-GNSS
assistance data and measurements, it embeds RRLP, RRC, or PDDM messages.
J-STD-036 Emergency services architecture
TIA/EIA/IS-TIA/EIA/J-STD-036-A-A – Enhanced Wireless 9-1-1 Phase 2, March
2002
This document defines the emergency services architecture for UTRAN, GERAN,
and ANSI-41.
LCS description 3GPP Description of LCS
TS 23.271 Third Generation Partnership Project; Technical Specification Group
Services and System Aspects; Functional stage 2 description of Location Services
(LCS)
This defines stage 2 of the location services for UMTS and GSM. It defines the
architecture, interfaces, messages, and protocols for supporting location services
for operators and subscribers. It also defines the emergency services LBA.
MLP Mobile Location Protocol
Mobile Location Protocol, Open Mobile Alliance, LIF-TS-101 Specification.
MLP is the protocol for LBAs to connect to an A-GNSS server. It is an XML based
protocol that allows the LBA to request the location of a particular handset. The
result is a location with a given uncertainty at the specified confidence.
PCAP Position Calculation Application Part.
Group Radio Access Network; UTRAN Iupc interface Positioning Calculation
Application Part (PCAP) signaling.
PCAP is the protocol used to exchange assistance data, location, or location mea-
surements between the SAS and the UE in a UMTS network. It contains a func-
tionality similar to RRLP.
QZSS IS The Quasi-Zenith Satellite System Interface Specification
Japan Aerospace Exploration Agency, Quasi-Zenith Satellite System Navigation
Service, Interface Specification for QZSS (IS-QZSS)
This document includes a system overview of the QZSS, a description of services,
system performance specifications, RF features of positioning signals, message
specifications, and recommended user algorithms. It essentially describes the inter-
face between the SS and the US of the QZSS.
206 Appendix A
RRC Radio Resource Control

Group Radio Access Network; Radio Resource Control (RRC); Protocol
Specification
RRC protocol handles the control plane signaling between the UE and other ele-
ments in a UTRAN network. It performs connection management and release,
broadcast of system information, mobility procedures, and power control. RRC is
the protocol that is used to carry assistance data and measurements between the
UE and the RNC in UTRAN. It can also be used for the assistance data
mechanism in ULP and ILP.
RRLP Radio Resource Location Protocol
Group GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Sta-
tion (MS)–Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol
(RRLP).
The RRLP protocol defines the procedures and messages for transferring assistance
data and location or measurements between the SMLC and the MS in a GSM net-
work. RRLP is also used in the ULP protocol on the Lup interface of the SLP and
the ILP protocol of the Llp interface of an SPC.
TIA-801 Position Determination Service Standard for Dual Mode
3GPP2 C.S0022 Position Determination Service for cdma2000 Spread Spectrum
Systems
PDDM is the protocol that is used to carry assistance data and measurements
between the handset and the MPC in CDMA.
ULP UserPlane Location Protocol
UserPlane Location Protocol, Open Mobile Alliance, OMA-TS-ULP
ULP is the protocol used between the SET and the SLP for SUPL. For A-GNSS
assistance data and measurements, it embeds RRLP, RRC, or PDDM messages.
UTRAN Arch The UTRAN location services architecture
Group Radio Access Network; Stage 2 functional specification of User Equipment
(UE) positioning in UTRAN
This document describes the LCS architecture for UTRAN.
Appendix B
Accompanying Source Code
This appendix describes the code on the accompanying CD and how to use Maven
and JUnit. Before using the code, you will need to download and install both the
Java SE SDK and Maven.
The source is organized using a standard project structure, as shown in Figure
B.1. At the highest level, the directories are split between src, which contains the
source code, target, which includes the files that are the results of the build, and
batch, which contains some batch files to invoke the targets. The source code is split
between the main classes and the test classes. The main source code classes are in
project directories under the ServerAgps directory. Figure B.1 only shows to the
directory level and the classes are stored under that. The target directory contains
the project’s jar file, the classes directory, which contains the classes that have been
built, and the test-classes, which contains the classes built from the test directory.
The reports directory contains the reports of the unit test results, and the apidocs
contains the Javadoc.
The contents of the source code directories are described in Table B.1.
The Java code is built into a project using Maven, which has been designed for
ease of use. It has a few simple commands described next that will allow you to
make use of the source code.
To build the code, you will need to use the command line interface of your
machine. Note that Maven is integrated into the major IDEs and can be invoked
from there depending on which one you are using, but it is discussed in terms of the
command line interface in this book. To build the Maven project, use the following
command from the highest level in the archive, that is, the serverAgps directory:
mvn package
This command will build all of the source code in the project, run all of the tests
defined in the test classes, and build the jar file. The tests in the test classes are writ-
ten using the JUnit unit testing framework.
207
208 Appendix B
Figure B.1 Project structure.
Table B.1 Project Directories

Directory name Description
app Some sample classes (applications) that can be run to demonstrate different
classes
broadcast Classes to do with the broadcast model
gps Classes specific to GPS but not part of the broadcast model
novatel Contains the code to parse data from NovAtel GPS format logs
Poscalc Position calculation classes
protocol Classes that are specific to A-GPS protocols
protocol/rrlp Classes that are specific to the RRLP protocol
ghtrinex Classes to read and write RINEX data files
supp Contains various support classes
wgs84 Contains the classes that deal with WGS 84 coordinates. The code allows
conversion between WGS 84 geodetic coordinates and ECEF coordinates, as
well as the opposite direction. It also contains some utility methods such as
the distance between two WGS 84 locations.
Appendix B 209
Table B.2 Batch Files

Name Description
ch3NavMessage.bat This batch job invokes the application from Chapter 3 that
parses in navigation message data.
novatelLogParser.bat This batch job invokes the novatelLogParser on the passed
in test log file.
PosCalc.bat Invokes the position calculation for a given RINEX observa-
tion file and a navigation file.
RRLPClient.bat Invokes the RRLP Client simulator class.
RRLPServer.bat Invokes the RRLP Server simulator class.
wgs84.bat This file runs the main method of the Wgs84Coordinate
class.
wgs84test.bat This file runs the WGS 84 test class that is running a bench-
mark test.
Once built, the classes are run directly from the jar file. There are some batch
files in the batch directory that run the main application and other individual
classes. The batch files are listed in Table B.2.
To generate the Javadoc in the Java API form from your source code, use the
Maven command:
mvn javadoc:javadoc
The Javadoc is generated in the apidocs directory (see Figure 2.6).

To run code coverage, use the command:
mvn emma:emma
The code coverage results are generated in the emma directory (see Figure 2.6).
For more details, see the README file on the accompanying CD. Updates to
the code will be available from time to time at http://www.artechhouse.com/static/
reslib/harper/harper1.html
Appendix C
Source Code Object Model
This appendix contains the source code object model for some of the code accompa-
nying this book.
NavMessage
-satellites[] : SatelliteNavMessage
+getSatellite(in prn : int) : SatelliteNavMessage
+newData(in prn : int, in data : byte[])
1
SatelliteNavMessage
Subframe
-prn : int
-data : byte[]
-subframes[] : Subframe
+newData(in data : byte[])
+newData(in data : Subframe)
0..* 1 0..3 +getSubframeId() : int
+getSubframe() : Subframe
+getPageId() : int
+getPage() : SatNavMessagePage
1
0..25
SatNavMessagePage Subframe
-pageNumber : int -data : byte[]
-subframes[] : Subframe +newData(in data : byte[])
+getSubFrame() : Subframe 1 0..2 +getSubframeId() : int
+newData(in data : Subframe) +getPageId() : int
SatelliteInfoHandler
-sateInfoCollection
1
Utc
0..* -utcParameters
+getUtcTime(in gpsTime : double) : double
SatelliteInformation
-satellites[] : Satellite
+getSatellite() : Satellite
IonosphereModel
1
-ionosphereParameters
0..* +getCorrection(in location : Wgs84Coordinate) : double
Satellite
-clockCorrectionParameters
-Ephemeris
+Satellite(in navMessage : SatelliteNavMessage)
+calculateLocation() : Wgs84Coordinate
+calculateVelocity()
Figure C.1 Broadcast object model.
211
212 Appendix C
RrlpMessage
+encode(in data : byte[]) : int

+decode(in data : byte[]) : bool
MeasurePositionRequest MeasurePositionResponse
+encode(in data : byte[]) : int +encode(in data : byte[]) : int

+decode(in data : byte[]) : bool +decode(in data : byte[]) : bool
Figure C.2 RRLP object model.
GpsMeasurementCollection
-gpsMeasurementCollection
TroposphereModel
1
0..*
GpsMeasurement
-satMeasurementCollection
HopfieldTroposphereModel
1
0..*
SatMeasurement
GpsTime
RangeMeasurementSet
-rangeMeasurements
0..*
RangeMeasurement
-transmiiterLocation : Wgs84Coordinate
-range : double
Figure C.3 GPS object model.

Appendix C 213
Rinex
RinexNavFile RinexObsFile
Figure C.4 RINEX object model.

Appendix D
Sample RRLP Messages
Chapter 5 discusses the encoding and decoding of RRLP messages in detail along
with the Java code to do it. This appendix contains some sample messages for fur-
ther study.
D.1 Measure Position Request (with Acquisition Assistance)
This is a measure position request that is part of an MS-assisted location. It is send-

ing the acquisition assistance and real-time integrity GPS assistance data types.
RRLP
0000 001----- Reference Number: 1
---0---- Extension: false
----000- Measure Position Request
-------0 20 Extension: false
Options:
0001 0------- Reference Assist Data: false
-0------ MSR Assist Data: false
--0----- System Info Assist Data: false
---1---- GPS Assist Data: true
----0--- Extension Container: false
Options:
-----0-- EnvironmentCharacter: false
Method Type
------00 10 Choice: MS Assisted
Options:
0002 1------- Accuracy: true
Accuracy
-0000001 81 Uncertainty: 1.0000000000
meters
Position Method:
0003 01------ GPS
Measurement Response Time:
--101--- MeasureResponseTime: 5
Use Multiple Sets:
-----1-- One set
GPS Assistance Data:
Control Header:
Options:
------0- Reference Time: false
-------0 6C Reference Location: false
0004 0------- DGPS Corrections: false
-0------ Navigation Model: false
--0----- Ionospheric Model: false
---0---- UTC Model: false
----0--- Almanac: false
-----1-- Acquis Assist: true
------1- Real Time Integrity: true
215
216 Appendix D
Acquisition Assistance:
Time Relation:
Options:
-------0 06 GSM Time: false
0005 01100010 62
0006 01110100 74
0007 1100100- GPS Tow 23B: 3226212
-------1 C9
0008 011----- Number of Elements: 12
Acquisition Element:
Options:
---1---- Additional Doppler: true
----1--- Additional Angle: true
-----010 7A
0009 001----- Satellite ID: 17
---00111 27
0010 0100100- Doppler0: -1116
-------1 49
0011 01100--- Doppler1: 44
-----100 64 Doppler uncertainty: 4
0012 10111011 BB
0013 00------ Code phase: 748
--00011- Int code phase: 3
-------1 07
0014 1------- GPS bit number: 3
-0010--- Code phase search window: 2
-----001 91
0015 01------ azimuth: 5
--000--- elevation: 0
Options:
-----1-- Additional Doppler: true
------1- Additional Angle: true
-------0 46
0016 10101--- Satellite ID: 21
-----001 A9
0017 01111100 7C
0018 1------- Doppler0: -1287
-100110- Doppler1: 38
-------1 CD
0019 00------ Doppler uncertainty: 4
--111000 38
0020 0110---- Code phase: 902
----0110 66
0021 1------- Int code phase: 13
-11----- GPS bit number: 3
---0010- Code phase search window: 2
-------0 E4
0022 0101---- azimuth: 5
----000- elevation: 0
Options:
-------1 51 Additional Doppler: true
0023 1------- Additional Angle: true
-001110- Satellite ID: 14
-------0 9C
0024 01100111 67
0025 110----- Doppler0: -1218
---11011 DB
0026 0------- Doppler1: 54
-100---- Doppler uncertainty: 4
----0101 45
0027 100100-- Code phase: 356
------01 91
0028 000----- Int code phase: 8
---11--- GPS bit number: 3
-----001 19
0029 0------- Code phase search window: 2
-00010-- azimuth: 2
------00 08
0030 0------- elevation: 0
D.2 Measure Position Response (GPS Measurements) 217
Options:
-1------ Additional Doppler: true
--1----- Additional Angle: true
---01010 6A
[SNIP] – Various satellites removed from Acquisition Assistance for

compactness
Sequence of Bad Satellites:
---0100- Number of Elements: 5

-------0 08
0096 01011--- Satellite ID: 11
-----011 5B
0097 110----- Satellite ID: 30
---01010 CA
0098 0------- Satellite ID: 20
-000101- Satellite ID: 5
-------0 0A
0099 01101--- Satellite ID: 13
D.2 Measure Position Response (GPS Measurements)
This is a Measure Position Request that is part of an MS-Assisted location. It is

sending the Acquisition Assistance and Real-time Integrity GPS assistance data
types.
RRLP
----001- Measure Position Response.
Options:
0001 0------- Multiple Sets: false
-0------ Reference Identity: false
--0----- OTD Measurement Information: false
---0---- Location Information: false
----1--- GPS Measurement Information: true
-----0-- Location Error: false
------0- Extension Container: false
GPS Measurement Information
GPS Measurement Set List:
-------0 08
0002 0------- Sequence size: 1
Options:
-0------ Reference Frame: false
GPS Time of Week:
--100010 22
0003 00000010 02
0004 10111101 BD
0005 00------ GPS Tow 24B: 8915700
GPS Measurement List:
--1011-- sequence size (post8_9_0): 12
GPS Measurement Element:
------01 2D
0006 1100---- Satellite ID: 28
----1001 C9
0007 11------ Carrier Noise Ratio: 39
--001111 CF
0008 00111111 3F
0009 00------ Doppler: -17156
--110111 37
0010 1000---- Whole Chips: 888
----0111 87
0011 0011111- Fractional Chips: 927
Multi Path Indicator
218 Appendix D
-------0 3E
0012 0------- Not Measured
-000000- Pseudo Range RMS Error: 0
-------0 00
0013 00101--- Satellite ID: 5
-----101 2D
0014 001----- Carrier Noise Ratio: 41
---00110 26
0015 11110010 F2
0016 000----- Doppler: -18544
---10111 17
0017 00111--- Whole Chips: 743
-----000 38
0018 10111011 BB Fractional Chips: 187
0019 00------ Not Measured
--000000 00 Pseudo Range RMS Error: 0
0020 011001-- Satellite ID: 25
------10 66
0021 1011---- Carrier Noise Ratio: 43
----0100 B4
0022 11010010 D2
0023 1010---- Doppler: -13014
----1110 AE
0024 010110-- Whole Chips: 918
------00 58
0025 01110111 77
0026 0------- Fractional Chips: 238
-00----- Not Measured
---00000 00
0027 0------- Pseudo Range RMS Error: 0
[SNIP] – Various satellites removed from GPS measurement list for

compactness
D.3 Assistance Data (Reference Location and Navigation Model)
This is an Assistance Data message that is part of an MS-Based location. It is send-

ing the reference time, reference location and the navigation model. The Navigation
model is a very large data type and it is only possible to fit 1 or 2 satellites into each
RRLP segment. The example below shows the first segment. The
MoreAssistanceData indicator is set to true.
RRLP
----010- Assistance Data
Options:
0001 0------- Reference Assist Data: false
-0------ MSR Assist Data: false
--0----- System Info Assist Data: false
---1---- GPS Assist Data: true
----1--- More Assistance Data to be Sent: true
-----0-- Extension Container: false
GPS Assistance Data:
Control Header:
Options:
------1- Reference Time: true
-------1 1B Reference Location: true
0002 0------- DGPS Corrections: false
-1------ Navigation Model: true
--0----- Ionospheric Model: false
D.3 Assistance Data (Reference Location and Navigation Model) 219
---0---- UTC Model: false

----0--- Almanac: false
-----0-- Acquis Assist: false
------0- Real Time Integrity: false
Reference Time:
Options:
-------0 40 GSM Time: false
0003 1------- GPS TOW Assist: true
GPS Time:
-0100001 A1
0004 11010011 D3
0005 01011100 5C GPS Tow 23B: 2216796
0006 01001001 49
0007 11------ GPS Week: 295
GPS TOW Assist:
--1011-- Sequence size: 12
GPS TOW Assist:
------01 ED
0008 0001---- Satellite ID: 17
----0000 10
0009 01000111 47
0010 11------ TLM Word: 287
--1----- Anti Spoof: true
---0---- Alert: false
----00-- TLM Reserved Bits: 0
GPS TOW Assist:
------01 E1
0011 0101---- Satellite ID: 21
----0000 50
0012 01000111 47
0013 11------ TLM Word: 287
GPS TOW Assist:
------00 E0
0014 1110---- Satellite ID: 14
----0000 E0
0015 01000111 47
0016 11------ TLM Word: 287
GPS TOW Assist:
[SNIP] – Various satellites removed from GPS TOW Assist for compactness
Reference Location:
------01 E1
0044 101----- Length: 13
Geographic Shape
---1001- Type of Shape: Ellipsoid point with
altitude and uncertainty Ellipsoid
-------0 B2
0045 000-----
Point:
---10110 16
0046 00011110 1E
0047 00001000 08
0048 010----- Latitude: 34.409888 to
34.409899 degrees south
---01101 4D
0049 01101001 69
0050 01011000 58
0051 100----- Longitude: 150.879450 to
150.879471 degrees east
---00000 80
0052 00000100 04
0053 000----- Altitude: 32 to 33 meters above
the ellipsoid
---0----
Major axis uncertainty:
----0101 05
220 Appendix D
0054 010----- Uncertainty: 537.636992

meters
---0----
Minor axis uncertainty:
----0101 45
0055 010----- Uncertainty: 537.636992
meters
---00000 40
0056 000----- Major axis angle: 0
---0----
----0110 06
0057 000----- Uncertainty Altitude: 102.217030
meters
---0----
----1011 0B
0058 010----- Confidence: 90
Navigation Model:
---0000- Number of Elements: 1
Navigation Model status:
-------0 40
0059 10001--- Satellite ID: 17
Satellite status:
-----0-- Extension: false
------00 88 New Satellite and Model:
Uncompresssed satellite
ephemeris and clock corrections:
0060 01------ Code on L2: 1
--0000-- URA: 0
------00 40
0061 0000---- SV health: 0
----0101 05
0062 111111-- IODC: 383
------0- L2Pflag: 0
Sub frame reserved:
-------0 FC
0063 00000000 00
0064 00000000 00
0065 000000-- Reserved 1: 0
------00 00
0066 00000000 00
0067 00000000 00
0068 000000-- Reserved 2: 0
------00 00
0069 00000000 00
0070 00000000 00
0071 000000-- Reserved 3: 0
------00 00
0072 00000000 00
0073 000000-- Reserved 4: 0
------01 01
0074 101010-- Tgd: -22
------00 A8
0075 10011010 9A
0076 101100-- Toc: 9900
------10 B2
0077 000000-- AF2: 0
------01 01
0078 11111111 FF
0079 100000-- AF1: -32
------01 81
0080 10111100 BC
0081 00100101 25
0082 1010---- AF0: 1609514
----1000 A8
0083 11001000 C8
0084 1100---- CRS: 3212
----1010 CA
0085 11101101 ED
0086 0100---- Delta N: 11988
----1100 4C
0087 01101001 69
0088 10100110 A6
0089 00101001 29
0090 1011---- M0: 1184522907
D.4 Measure Position Response (Location) 221
----1000 B8
0091 10110001 B1
0092 0011---- CUC: 2835
----0000 30
0093 00101101 2D
0094 10011000 98
0095 11010110 D6
0096 1011---- E: 47811947
----1001 B9
0097 00011111 1F
0098 1000---- CUS: 4600
----1010 8A
0099 00010000 10
0100 11011101 DD
0101 10000101 85
0102 1010---- A power half: 2702039130
----0010 A2
0103 01101010 6A
0104 1100---- TOE: 9900
----0--- Fit Flag: 0
-----111 C7
0105 11------ AODA: 31
--011111 DF
0106 11111000 F8
0107 01------ CIC: -31
--000010 42
0108 01111111 7F
0109 11111100 FC
0110 01000100 44
0111 11------ Omega A0: -1979715309
--100000 E0
0112 00010001 11
0113 11------ CIS: 71
--101001 E9
0114 11001110 CE
0115 00111000 38
0116 11110110 F6
0117 10------ IO: 658039770
--100110 A6
0118 10111111 BF
0119 11------ CRC: 6911
--000011 C3
0120 01101001 69
0121 01100100 64
0122 11001001 C9
0123 11------ W: -1918528729
--011111 DF
0124 11101010 EA
0125 00110001 31
0126 01------ Omega ADot: -22331
--100000 60
0127 00111101 3D IDot: 61
More Assistance Data To Be Sent:
0128 1------- More assistance data to be sent.
D.4 Measure Position Response (Location)
This is a Measure Position Response that is part of an MS-Based location.

RRLP
----001- Measure Position Response.
Options:
0001 0------- Multiple Sets: false
-0------ Reference Identity: false
--0----- OTD Measurement Information: false
---1---- Location Information: true
----0--- GPS Measurement Information: false
222 Appendix D
-----0-- Location Error: false

------0- Extension Container: false
Location Information
Options:
-------1 11 GPS Time Of Week: true
0002 11111111 ff
0003 11111111 ff Reference Frame Number: 65535
0004 10000100 84
0005 01110010 72
0006 01000000 40 GPS Time Of Week: 8680000
Fix Type:
0007 1------- Three Dimensional Fix.
Position Estimate:
-01101-- Length: 13
Geographic Shape
------10 b6
0008 01------ Type of Shape: Ellipsoid point with altitude and uncertainty
Ellipsoid
--0000--
Point:
------00 40
0009 10010010 92
0010 10011101 9d
0011 100110-- Latitude: 25.7722735405 to 25.7722842693
degrees north
------11 9b
0012 00011011 1b
0013 11100110 e6
0014 011001-- Longitude: 80.1914191246 to 80.1913976669
degrees west
------00 64
0015 00000000 00
0016 101010-- Altitude: 42 to 43 meters above the
ellipsoid
------0-
Major axis uncertainty:
-------0 a8
0017 001111-- Uncertainty: 31.7724816942 meters
------0-
Minor axis uncertainty:
-------0 3c
0018 000101-- Uncertainty: 6.1051000000 meters
------00 14
0019 100101-- Major axis angle: 37
------0-
-------0 94
0020 001101-- Uncertainty Altitude: 17.0329970184
meters
------0-
-------1 35
0021 000100-- Confidence: 68
------00 10
List of Acronyms and Abbreviations
3GPP Third Generation Partnership Project
A-GNSS Assisted-GNSS
A-GPS Assisted-GPS
ALI automatic location identification
ASN.1 Abstract Syntax Notation 1
BIPM International Bureau of Weights and Measures
bps bits per second
BPSK biphase shift key
C/A coarse/acquisition
CDMA code division multiple access
CRF coordinate reference frame
CRS coordinate reference system
CS control segment
DEM digital elevation model
D-GPS Differential GPS
DN day number
DoD Department of Defense
DOP dilution of precision
DTD document type definition
DTV digital TV ranging measurements
E-911 Enhanced 9-1-1
ECEF earth-centered earth-fixed
ECMWF European Centre for Medium-Range Weather Forecasts
EGNOS European Geostationary Navigation Overlay Service
EOTD enhanced observed time difference
EP elementary procedure
ESME Emergency Services Messaging Entity
ESP Emergency Services Protocol
EU European Union
FCC Federal Communications Commission
FDMA frequency division multiple access
FOC full operational capability
GAD Geographical Area Description specification
223
224 List of Acronyms and Abbreviations
GAGAN GPS Aided Geo Augmentation Navigation

GANSS Galileo and Additional Navigation Satellite Systems
GBAS Ground Based Augmentation System
GEO geostationary satellite
GERAN GSM/EDGE Radio Access Network
GLONASS GLObal’naya NAvigatsionnaya Sputnikovaya Sistema
GNSS Global Satellite Navigation System
GPS Global Positioning System
GPS IS GPS Interface Specification GPS-IS-200
GPS SPS PS GPS SPS Performance Specification
GPS SPS SS GPS SPS Signal Specification
GRAS Ground-Based Regional Augmentation System
GRIP GNSS Reference Interface Protocol
GRN global reference network
GRS GNSS reference server
GSM Global System for Mobile Communications
GST Galileo System Time
HDOP horizontal dilution of precision
HEO highly inclined elliptical orbit
HOW handover word
HP high precision
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
Hz hertz
ICG International Committee on Global Navigation Satellite
Systems
ID identifier
IDE integrated development environment
IE information element
IETF Internet Engineering Task Force
IGS International GNSS Service
IGU IGS ultra-rapid products
ILP Intermediate Location Protocol
IOC initial operational capability
IODC issue of data, clock
IODE issue of data, ephemeris
IP Internet Protocol
IRNSS Indian Regional Navigational Satellite System
ISDN International Subscriber Directory Number
ITRS International Terrestrial Reference System
JGS Japan Satellite Navigation Geodetic System
JPO Joint Program Office

L1 Link 1—GPS L1 Frequency
L2 Link 2—GPS L2 Frequency
L2C L2 Civil
LAAS Local Area Augmentation System
LBA location-based application
LCS location services
LIS location information server
LS location server
LSB least significant bit
MCS master control station
MLC mobile location center
MPC mobile positioning center
MS mobile station
MSAS Multifunctional Satellite Augmentation System
MSB most significant bit
MSID mobile station identifier
MSISDN Mobile Station International ISDN
NA North America
NAES North American Emergency Services
NATO North Atlantic Treaty Organization
NAV Navigation Message
NENA National Emergency Number Association
NICT National Institute of Information and Communications
Technology
NLOS nonline of sight
NSS Navigation Satellite System
NTP Network Time Protocol
OMA Open Mobile Alliance
OO object oriented
OS Open Service
OSGRS Open Source GNSS Reference Server
OTDOA observed time difference of arrival
PCAP position calculation application part
PCF position calculation function
PDDM Position Determination Service Standard for Dual Mode
Spread Spectrum Systems
PER packed encoding rules
PPS Precise Positioning Service
PRN pseudorandom noise (code)
PSAP public safety answering point
226 List of Acronyms and Abbreviations
QoP quality of position

QoS quality of service
QZS Quasi-Zenith Satellite
QZSS Quazi-Zenith Satellite System
RAN radio access network
RF radio frequency
RHCP right hand circularly polarized
RINEX Receiver Independent Exchange Format
RNC radio network controller
RNSS Regional Navigation Satellite System
RRC radio resource control
RRLP Radio Resource Location Protocol
RTI real-time integrity
RTT round-trip timing
Rx receiver
SAS stand-alone SMLC
SBAS Satellite-Based Augmentation System
SET SUPL enabled terminal
SLC SUPL location center
SLIA standard location immediate answer
SLIR standard location immediate request
SLP SUPL location platform
SMLC serving mobile location center
SOAP Simple Object Access Protocol
SOPAC Scripps Orbit and Permanent Array Center
SP standard precision
SPC SUPL positioning center
SPP single point positioning
SPS Standard Positioning Service
SPS PS Standard Positioning Service Performance Standard
SS space segment
SUPL secure user plane location
TA timing advance
TEC total electron content
TLM telemetry
TLS transport layer security
TOA time of arrival
TOF time of flight
TOT time of transmission
TOW time of week
TPS transactions per second
TTFF time to first fix

Tx transmitter
UE user equipment
ULP UserPlane Location Protocol
UML Unified Modeling Language
UMTS Universal Mobile Telecommunications System
UNSW University of New South Wales
US user segment
USAF United States Air Force
USNO U.S. Naval Observatory
UTC Coordinated Universal Time
U-TDOA uplink time difference of arrival
UTRAN UMTS Terrestrial Radio Access Network
VoIP Voice over Internet Protocol
VPN virtual private network
WAAS Wide Area Augmentation System
WARN wide area reference network
WGS 84 World Geodetic System 1984
WN week number
WSP Wireless Session Protocol
XML Extensible Markup Language
List of Symbols
t the time that the handset made the measurement
tSV the time that the satellite transmitted the signal
tSV satellite clock offset
H the geometry matrix
pseudorange
a semimajor axis of the ellipsoid
b semiminor axis of the ellipsoid
c speed of light
D Doppler
f frequency in hertz
f flattening of the earth (for WGS 84)
h height
rr location of the receiver in WGS 84 ECEF coordinates
rs location of the satellite in WGS 84 ECEF coordinates
vr velocity of the receiver
vs velocity of the satellite
Ω& Earth’s rotation rate
e
latitude
longitude
universal gravitation parameter
229
Glossary
Accuracy The distance between the calculated location and the
ground truth.
A-GPS handset A handset that is capable of performing A-GPS. It con-
nects to the A-GPS server over the network and requests
GPS assistance data. Assistance data is specific to the
handset’s approximate location. The handset uses the
assistance data to lock onto the satellites and either calcu-
late its own location or return the measurements to the
server for it to calculate the location.
Autonomous GNSS fix A fix where the GNSS handset receives no assistance data
from a server; also known as a stand-alone fix.
C/A code The C/A code consists of the satellite’s PRN modulated
with the navigation message. It is 1,023 bits long and
repeats each millisecond. Code-division-multiplexing
techniques allow the handset to differentiate between the
satellites, even though they transmit on the same fre-
quency. The C/A code is the PRN with the Modulo-2
addition of the navigation data bits, which are included
in the sequence at 50 bps.
Cartesian coordinate A linear system with the origin at a certain fixed point
system with three axes defined that are perpendicular to each
other. A point in space in the Cartesian coordinate system
is defined relative to the origin and is in the form of (x, y,
z).
Cold start The handset having no prior information about the
GNSS constellation.
Confidence A percentage value that expresses the confidence that the
true location is within the calculated uncertainty. When
the confidence is increased, the size of the uncertainty
area is increased.
Ellipsoid point with The most common representation of a GNSS-based loca-
altitude and uncertainty tion. Latitude and longitude are points on the surface of
ellipse the ellipsoid, altitude is relative to the surface of the ellip-
soid, and the uncertainty is expressed as an ellipse on the
surface of the ellipsoid. The uncertainty ellipse is pro-
vided at a given confidence level.
231
232 Glossary
Ellipsoidal (or geodetic) A system with the origin at a fixed point and with loca-
coordinate system tions defined on the ellipsoid as latitude, longitude, and
height.
Fix The process of determining the location of a handset
from a set of measurements.
GERAN The radio part of GSM/EDGE together with the network
that joins the base stations.
GPS L1 The primary civilian frequency transmitted at 1,575.42
MHz.
Handset A device that is in use by someone wanting to know his or
her location. It could be a cell phone, a handheld com-
puter, or even just a laptop connected to the Internet.
Handset-assisted The handset makes the measurements and returns them
to the server that does the position calculation.
Handset-based The handset makes the measurements and performs the
MS The name for the A-GNSS-enabled handset in a GSM
network.
NAV message The navigation message signal broadcast on GPS L1. The
NAV message allows the handset to determine the status
of the constellation, the satellite’s time of transmission,
its health, its clock correction, its position, and the time
conversion from GPS to UTC.
Octet An octet is 8 bits.
Position calculation A module or element that calculates the location of a
function (PCF) handset, given a set of measurements.
PRN code Each satellite has a unique PRN code sequence which is
1,023 bits in length and provides the method to identify
each individual satellite. Each sequence is a 1,023-bit
gold code.
QoS/QoP The terms quality of service (QoS) and quality of position
(QoP) are often used interchangeably within different
standards to mean the same thing in the context of a loca-
tion calculation. The QoS/QoP define the requirements
for the accuracy and the allowed time for the LS to per-
form a location calculation. For example, the LBA may
request the location of a certain handset with a horizontal
uncertainty of less than 20 meters within a time limit of
30 seconds.
Satellite-based A measurement based on information transmitted from a
measurement satellite.
SET The name for the A-GNSS-enabled handset for SUPL.
Single point A position calculation being performed using a single
positioning (SPP) point in time; it may include measurements form more
than one GNSS frequency (more than one set of signals).
Glossary 233
Spoofing The act of providing incorrect measurements to a PCF in

order to forge the location.
UE The name for the A-GNSS enabled handset in a UMTS
network.
Uncertainty The measure of the error in the location calculation cal-
culated as part of the location fix. For satellite-based
location calculations, the uncertainty is normally calcu-
lated in the form of an ellipse and described in terms of
the orientation, the length of the semimajor axis, and the
length of the semiminor axis.
UTRAN The Node Bs and RNCs that make up the UMTS radio
access network.
About the Author
Neil Harper has more than 20 years of experience in software design, development,
and research. He has completed a bachelor’s degree of mathematics, a master’s
degree of computer science, and a Ph.D. in the field of ultrasonic sensing for mobile
robots.
Over the last 10 years, he has been developing software and researching in the
area of GNSS and Assisted-GNSS while working as a senior software engineer at
Andrew Corporation. His work has included the development of Andrew’s core
GPS position calculation engine and the assistance data type GPS acquisition assis-
tance. These are the two key components of the server for handset-assisted
Assisted-GPS in a cellular network. Previously, Dr. Harper worked as a software
engineer in the Australian steel industry and as an image processing researcher.
Dr. Harper has two published patents in the United States and 15 patent appli-
cations. In addition, he has maintained regular professional output of academic
publications in quality journals and high-profile conference proceedings within the
GNSS research community.
Dr. Harper is a member of the Institute of Navigation (ION) and the Illawarra
Java Users group.
235
Index
A GBAS, 3
Accuracy, 5, 10–11, 58–59, 117, 122–123 Geodetic coordinates, 20–21, 23–27
Acquisition, 35, 54, 76, 77 Geometric range correction, 126, 132–133
Acquisition assistance, 9, 81–86, 87 Geometry matrix (H), 125, 139, 140, 147, 163
A-GNSS, 1, 5, 6, 9–10, 192–197 GERAN, 64, 90, 92, 185
A-GPS, 1, 63–88 GLONASS, 2, 50, 97, 194, 196, 198, 199
Almanac, 9, 44, 54, 86 GMLC, 9, 65, 72, 74, 91, 92
ASN.1, 91, 95–104, 117 GNSS Reference Server (GRS), 6, 7, 63, 65–70,
Assistance data, 1, 6–8, 9, 63–65, 76–88, 92, 77, 79, 86, 200
197, 198 GPS L1, 37, 38
Assistance data size, 87 GPS L2, 36–37, 38–39, 67, 92
Augmentations, 3, 193, 195, 197 GPS measurement, 5, 45, 92, 98, 114, 122,
127
C GPS time, 39
C/A code, 10, 36, 37, 38, 39, 82, 86, 197 GRIP, 70, 71
CDMA, 2, 3, 9, 72, 91, 194, 195 GSM, 6, 78, 91, 93, 168
CNAV, 37, 38–39, 96
H
Code coverage, 30–31
Code phase, 8, 41, 81–83, 92, 121, 123 Handover word (HOW), 40, 77, 78
Compass, 2, 195 Handset, 2–5, 7, 54, 64, 72, 76, 92
Confidence, 10, 56–58, 75, 143 Handset clock error, 5, 124–125, 134, 140,
Configuration management, 32 143, 149, 163, 169
Coordinate reference frame, 17, 132, 194 Handset-assisted, 1, 76, 81, 92, 121, 153, 167
188
D Handset-based, 1, 76. 92, 185, 198
Differential-GPS (DGPS), 9, 59–60, 69, 86, 87 Hybrid, 150, 167
Dilution of precision (DOP), 59, 123, 146, 202
I
Doppler, 81–84, 121, 146, 187–188
Integrated development environment (IDE), 13
E Integrated time recovery, 163
E2 interface, 65, 73, 75, 91 International GNSS Service (IGS), 53, 183
E9-1-1, 11, 92 IODE, 42, 43, 65, 98
ECEF coordinates, 19–21, 23, 42, 73, 83, 96 Ionosphere, 79, 136, 184
EGNOS, 3, 196, 198 IRNSS, 197
Emergency Services Protocol, 75 Iterative time recovery, 156
Emma, 30
J
Ephemeris, 4, 6, 39, 40, 42, 49, 51, 65, 79,
126 Java, 12–14, 22, 23–32
ESME, 64, 65, 72, 75, 91 Javadoc, 13, 14, 24, 107
JUnit, 23, 28, 110,
G
L
GAD specification, 10, 75, 79, 87, 103, 199
GAGAN, 3, 97, 197, 198 Least squares, 57, 126, 128, 138–143, 149,
Galileo, 2, 10, 92, 96, 194–195, 197, 199, 200 156, 163, 165, 168, 188
237
238 Index
Location information server (LIS), 9, 10, 72, 91 Reference location, 8, 9, 79, 87, 94, 96, 114,
Location integrity, 126, 185–189 199
Location server, 62, 64, 71–73 Reference time, 8, 9, 64, 71, 77–78, 87, 94,
Location-based application (LBA), 8, 64–65, 96, 99, 153, 193
73–75, 185, 187 Residuals, 145, 146, 154, 156, 188
Location-based services, 11 RINEX file format, 50–51, 53, 65, 69, 71,
127, 128, 133, 160
M RRC, 9, 10, 64, 72, 91, 92, 93, 114, 197
Master Control Station, 35, 41, 196 RRLP, 9, 10, 64, 72, 78, 91, 92–114, 197,
Maven, 13, 22, 23, 24, 28, 30, 110 198–201
Measurement errors, 5, 45, 56, 58–59, 143, RRLP Measure position request, 93–96, 98,
183–185 99, 100, 101, 102, 104, 105
Mobile Location Center (MLC), 9, 11, 65, 72, RRLP Measure position response, 93, 95, 98,
73, 74, 91 100
Mobile Location Protocol (MLP), 64, 65, 73, RTT, 6, 115, 116, 168, 173, 177, 179, 185,
74, 92, 185 200
Mobile Positioning Center (MPC), 65, 74, 91
Multipath error (NLOS), 5, 8, 58, 59, 122, S
135 SAS, 9, 64, 72, 91, 114, 115, 168
Satellite clock correction, 4, 41, 59, 65, 126,
N 130–132, 195
NAES, 65, 73, 75, 90 Satellite constellation, 2, 3, 35, 39, 71, 86, 194
NAV message, 4, 9, 37, 38, 39–51, 76, 78, 98, Satellite elevation, 73, 83, 123, 126, 134–136,
124, 127, 132, 187, 195 141
Navigation model, 8, 9, 49, 63, 71, 79, 80, 87, Satellite group delay, 41, 80, 126, 132
96, 200 Satellite health, 4, 38, 41, 65, 126, 129–130
Satellite location, 53, 126, 131, 136
O
Satellite orbit, 2, 3, 4, 36, 41, 80, 183
OSGRS, 70–71 SBAS, 3, 96, 87, 197, 198, 199, 201
P Serving cell, 5, 8, 9, 64, 72, 77, 79, 87, 116
SLP, 9, 10, 72, 76, 91, 92, 146, 197
PCAP, 9, 64, 72, 77, 78, 91, 114–117, 168, SMLC, 9, 64, 72, 91, 92, 93, 94, 95
197 Socket, 110–114
Performance testing, 29 SP3, file format 53
Position calculation, 121–150 Spoofing, 186–189
PRN, 4, 37, 38, 40, 54, 77, 78 SSR, 145, 154, 156, 159
Protocol, 7, 9, 64, 71, 91, 92, 197 Standards, 7, 9–10, 64, 72, 91, 92
Pseudomeasurement, 134 Subframe, 4, 39–46, 47–48, 64, 69, 78
Pseudorange, 54, 121, 123, 124, 125, 128, SUPL, 9, 10, 72, 91, 92, 93, 188, 189
130, 193
Public Safety Answering Point (PSAP), 11, 65, T
75 Telemetry word (TLM), 40, 77, 78
Q Time recovery, 77, 153–166
Time server (NTP), 6, 7, 64, 73, 78, 153
Quality of Position (QoP), 65, 74, 116, 117 Timing Advance (TA), 6, 168, 173, 177
QZSS, 96, 170, 195–196, 198, 199, 201 Troposphere, 5, 58, 126, 137–138, 184, 188
R TTFF, 1, 4, 5, 63, 91
Radio Access Network (RAN), 72, 76, 87 U
Ranging signal, 2, 3, 35, 36, 38, 121 UMTS, 6, 9, 91, 168, 178,
Real-time integrity, 8, 9, 71, 77, 86, 87, 96, Uncertainty, 8, 10, 55, 56–58, 59, 64, 74, 79,
130 82, 103, 143–145
Index 239
Unit test, 22, 23, 27–28, 29, 30, 31, 47, 52, W
110 WAAS, 3, 97, 196, 198
Userplane Location Protocol (ULP), 10, 76, 93 Weight matrix (W), 126, 138, 141, 142
UTC model, 4, 8, 9, 39, 44, 71, 78, 80–81, WGS, 84 10, 17, 18–21, 23–27, 42, 67, 73,
87, 96, 153, 201 127
UTDOA, 6, 173, 179
UTRAN, 64, 72, 78, 91, 114, 168, 173, 177
The GNSS Technology and Applications Series
Elliott Kaplan and Christopher Hegarty, Series Editors
A-GPS: Assisted GPS, GNSS, and SBAS, Frank van Diggelen

Applied Satellite Navigation Using GPS, GALILEO, and Augmentation Systems,
Ramjee Prasad and Marina Ruggieri
Digital Terrain Modeling: Acquisition, Manipulation, and Applications,
Naser El-Sheimy, Caterina Valeo, and Ayman Habib
Geographical Information Systems Demystified, Stephen R. Galati
GNSS Applications and Methods, Scott Gleason and Demoz Gebre-Egziabher
GNSS Markets and Applications, Len Jacobson
GNSS Receivers for Weak Signals, Nesreen I. Ziedan
Introduction to GPS: The Global Positioning System, Second Edition,
Ahmed El-Rabbany
Principles of GNSS, Inertial, and Multisensor Integrated Navigation Systems,
Paul D. Groves
Server-Side GPS and Assisted-GPS in Java™, Neil Harper
Spread Spectrum Systems for GNSS and Wireless Communications, Jack K. Holmes
Understanding GPS: Principles and Applications, Second Edition, Elliott Kaplan and
Christopher Hegarty, editors
Ubiquitous Positioning, Robin Mannings
Wireless Positioning Technologies and Applications, Alan Bensky
For further information on these and other Artech House titles, including
previously considered out-of-print books now available through our
In-Print-Forever® (IPF®) program, contact:
Artech House Publishers Artech House Books

685 Canton Street 16 Sussex Street
Norwood, MA 02062 London SW1V HRW UK
Phone: 781-769-9750 Phone: +44 (0)20 7596 8750
Fax: 781-769-6334 Fax: +44 (0)20 7630 0166
e-mail: artech@artechhouse.com e-mail: artech-uk@artechhouse.com
Find us on the World Wide Web at: www.artechhouse.com

Server-Side-GPS and Assited-GPS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Server-Side-GPS and Assited-GPS

Uploaded by

Copyright:

Available Formats

Server-Side GPS and

For a listing of recent titles in the

British Library Cataloguing in Publication Data

Cover design by Igor Valdman

© 2010 ARTECH HOUSE

10.1.7 Others 197

List of Acronyms and Abbreviations 223

Traditionally, a GPS receiver has had a recognizable form-factor. This could be as a

1.3 Global Navigation Satellites Systems (GNSS)

A Global Navigation Satellite System (GNSS) is a system, or technology, with

1.4 GNSS Augmentations

A GNSS augmentation is a system that can be used to improve the performance of a

1.5 GPS from a High Level

between them because each one transmits a different pseudorandom (PRN)

300 bits at 50 bits per second—6s per subframe

Subframe 1– Satellite accuracy and health and satellite clock correction

Subframe 3 – Ephemeris continued

Subframe 5 – Almanac Pages 1-25

Figure 1.1 NAV message structure.

In a time-synchronized system, calculating a three-dimensional location would

1.6 Assisted-GNSS from a High Level

An Assisted-GPS server provides data to a wireless handset that is specific to the

Figure 1.2 Geometric trilateration.

Figure 1.3 A simplified A-GNSS architecture.

A-GNSS Server A-GNSS Handset

A Measure position request

B Measure position response

C Measure position request

D Measure position response

Figure 1.4 Simplified A-GNSS messaging.

would be a location-based application (LBA). The LBA may be a tracking applica-

Table 1.1 Primary A-GNSS Assistance Data Types

1.7 A-GNSS Protocols and Standards

1.8 Why Is an Accurate Location Required?

A GNSS-based location is generally represented as a latitude, longitude, and alti-

1.9 Location Market

1.9.2 Location-Based Services

1.9.3 Lawful Intercept Services

1.10 Java and Software Design for A-GNSS Applications

1.10.1 Coding in Java

Table 1.2 Java Numeric Primitive Data Types

1.11 Organization of This Book

Coding for GNSS and the Coordinate

2.1 Coordinate Reference Frame

2.2 World Geodetic System 1984

Figure 2.3 Earth-centered Earth-fixed coordinate system.

Figure 2.4 Ellipsoid model.

Table 2.1 WGS 84 Parameters

Converting geodetic coordinates to ECEF is performed using (2.4). The vari-

x = (N( ϕ) + h) cos ϕ cos λ

z= ((N( ϕ)(1 − e ) + h))sin ϕ

2.3 Source Code Structure and Management

Figure 2.6 Project structure.

2.4 WGS 84 Implementation

The Java class Wgs84Coordinate (com.ServerAgps.wgs84.Wgs84Coordinate)

25. this.latitude = 90;

The Javadoc is generated in the apidocs directory (see Figure 2.6).

In order to start the numerical conversion from ECEF to geodetic coordinates,

As shown, E_SQUARED is double precision, 1 is an integer, and the result of

2.5 Unit Testing

• Convert a known location from ECEF to geodetic coordinates.

2.7 Performance Testing and Benchmarking

Performance was a particular issue in earlier versions of Java, where it developed a