Server-side GPS and Assisted-GPS in Java (Artech House Gnss Technologies and Applications)

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 merchantability, 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 procedures 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, including 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 information. Use of a term in this book should not be regarded as affecting the validity of any trademark 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.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

1

Overview Terminology Global Navigation Satellites Systems (GNSS) GNSS Augmentations GPS from a High Level Assisted-GNSS from a High Level A-GNSS Protocols and Standards Why Is an Accurate Location Required? Location Market 1.9.1 E9-1-1 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 1.11 Organization of This Book References

1 2 2 3 3 5 9 10 11 11 11 12 12 13 14 14

CHAPTER 2 Coding for GNSS and the Coordinate Reference Frame

17

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

Coordinate Reference Frame World Geodetic System 1984 Source Code Structure and Management WGS 84 Implementation Unit Testing Debugging Performance Testing and Benchmarking Code Coverage Analysis Configuration Management References

17 18 22 23 27 29 29 30 32 32

vii

viii

Contents

CHAPTER 3 GPS 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

3.12 3.13 3.14 3.15 3.16 3.17

GPS Constellation and Segments GPS Services Satellites Ranging Codes PRN Codes GPS C/A Code GPS L1 Signal GPS L2 Signal GPS Time Broadcast Information Navigation Message Structure (NAV) Decoding and Storing the Navigation Model 3.11.1 Storing the Raw NAV Data 3.11.2 Running the Classes to Store the Raw Data 3.11.3 Other Sources of Raw NAV Data 3.11.4 Decoding the NAV Data into Useful Information 3.11.5 RINEX as a Data Source for the Navigation Message 3.11.6 Implementation of Methods Using the NAV Model GPS Signal Acquisition Receiver Positioning 3.13.1 Uncertainty and Confidence Factors Affecting Location Accuracy Geometry and Dilution of Precision Differential-GPS Software Projects References

35 35 36 36 36 37 37 38 38 39 39 46 46 47 49 49 50 51 54 54 56 58 59 59 60 62

CHAPTER 4 Assisted-GPS and Assistance Data

63

4.1 The Assistance Model 4.2 GNSS Reference Server (GRS) 4.2.1 GPS Reference Receiver Configuration for a GRS 4.2.2 GRS Interface 4.2.3 Open Source GNSS Reference Server (OSGRS) 4.3 Location Server (LS) 4.4 Location-Based Application (LBA) 4.5 Emergency Services Messaging Entity 4.6 The Handset 4.7 Assistance Data Types 4.7.1 Reference Time 4.7.2 Reference Location 4.7.3 Navigation Model 4.7.4 Ionosphere Model 4.7.5 UTC Model 4.7.6 Acquisition Assistance 4.7.7 Real-Time Integrity

63 65 66 69 70 72 73 75 76 76 77 79 79 79 80 81 86

Contents

ix

4.7.8 Almanac 4.7.9 DGPS Corrections 4.8 Assistance Data Type Sizes References

86 86 87 88

CHAPTER 5 Assisted-GPS Location Within a Network

91

5.1 Location Architectures 5.2 A-GPS Protocols and Messaging 5.3 RRLP 5.3.1 RRLP Procedures 5.3.2 RRLP Messages 5.3.3 RRLP Encoding and ASN.1 Packed Encoding Rules 5.3.4 RRLP Implementation 5.3.5 Testing the RRLP Classes 5.3.6 Communication Across Sockets with RRLP 5.4 PCAP and RRC 5.4.1 PCAP Procedures 5.4.2 PCAP Messages and Encoding 5.5 Software Projects References

91 92 92 93 94 95 104 110 110 114 115 117 117 118

CHAPTER 6 Position Calculation

121

6.1 Position Calculation and Handset-Assisted A-GPS 6.2 The Accuracy and Yield Trade-Off 6.3 Positioning Using GPS Code Phase Measurements 6.3.1 Data Preparation 6.3.2 Worked Example 6.3.3 Satellite Health 6.3.4 Calculate the Location of Each Satellite 6.3.5 Satellite Clock Correction 6.3.6 Group Delay Differential 6.3.7 Geometric Range Correction 6.3.8 Substituting in a Pseudomeasurement 6.3.9 Pruning Bad Satellite Measurements 6.3.10 Pruning Low Elevation Satellites 6.3.11 Pruning Weak Measurements 6.3.12 Ionosphere Correction 6.3.13 Troposphere Correction 6.3.14 Position Calculation 6.3.15 Uncertainty 6.3.16 Quality Measures 6.4 Doppler-Based Position Calculation 6.5 Hybrid Position Calculation 6.6 Software Projects References

121 122 123 126 127 129 130 130 132 132 134 134 134 136 136 137 138 143 145 146 149 149 150

x

Contents

CHAPTER 7 GPS Position Calculation with Time Recovery

153

7.1 The Time Determination Problem 7.2 Iterative Time Recovery 7.2.1 Iterative Time Recovery: Accuracy 7.2.2 Iterative Time Recovery: Performance 7.3 Integrated Time Recovery 7.3.1 Integrated Time Recovery: Accuracy 7.3.2 Integrated Time Recovery: Performance 7.4 Software Project References

153 156 160 160 163 165 165 166 166

CHAPTER 8 Hybrid Location

167

8.1 8.2 8.3 8.4

Hybrid Positioning Overview Hybrid Position Calculation Hybrid Position Calculation Implementation Hybrid Position Calculation Accuracy 8.4.1 Simulation Background 8.4.2 Location Calculation in Difficult Situations 8.4.3 Hybrid Location with Ideal Ranges 8.4.4 Hybrid Location with Ranges Using Error-Corrupted Ranges 8.5 Software Projects References

167 168 170 172 172 174 175 177 180 182

CHAPTER 9 Other Server-Side Improvements and Controls

183

9.1 Improved Error Modeling 9.1.1 Orbit Modeling 9.1.2 Troposphere Modeling 9.1.3 Ionosphere Modeling 9.2 Location Integrity 9.2.1 Location Assurance 9.2.2 Antispoofing 9.3 Software Projects References

183 183 184 184 185 185 186 189 190

CHAPTER 10 Assisted-GNSS

193

10.1 Assisted-GNSS 10.1.1 GLONASS 10.1.2 Galileo 10.1.3 Compass 10.1.4 QZSS 10.1.5 WAAS 10.1.6 EGNOS

193 194 194 195 195 196 196

Contents

xi

10.1.7 Others 10.2 Protocols 10.2.1 GANSS Position Request 10.2.2 GANSS Position Response 10.3 Using Multiple GNSSs and Signals References

197 197 197 201 202 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 D.2 D.3 D.4

215 217 218 221

Measure Position Request (with Acquisition Assistance) Measure Position Response (GPS Measurements) Assistance Data (Reference Location and Navigation Model) Measure Position Response (Location)

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 preparation 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 simplicity 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 protocol 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 engineering 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 purchasing 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 understanding. 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 contains 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 signal 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 architectures 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 experiments 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 assistance 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 contributed 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 providing 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 enthusiasm 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 integration with other measurements available in the network. This book is a practical introduction to understanding, designing, and implementing 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 implementation. For the detailed background theory and mathematics, the reader should consult 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 calculation. 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). Measurements 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 information 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 software 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 transmit ranging codes that can be detected by a receiver and allow the receiver to determine 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 satellites 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 development 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 Chinese government. It consists of satellites in both medium Earth orbit and geostationary orbit.

1.4 GNSS Augmentations

1.4

3

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 central processing system that determines the integrity and regional ionosphere corrections, and one or more geostationary satellites that can provide the information to users [4]. The reference stations make ranging measurements from the satellites and provide them to the central processing system. The central system determines the integrity of individual satellites and determines corrections based on the measurements and the precisely known location of the reference station’s antenna. This information is then available to users via a signal separate to the GNSS that is being augmented. 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 relevant to the entire coverage of the SBAS, so a user handset can make use of these corrections 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 augmentation 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 frequencies. 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 determine 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 satellite 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 message 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 handset 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 demodulating right at the start of the new frame. The subframes are being continuously transmitted 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 channel. 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

6 subframes—30s per frame

Subframe 1– Satellite accuracy and health and satellite clock correction

Figure 1.1

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

NAV message structure.

1.6 Assisted-GNSS from a High Level

5

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 measured 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 (calculated using the ephemeris) and the pseudoranges ρ1 to ρ4 have been measured. The calculation process will then apply corrections in order to minimize the measurement 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 synchronization 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 S 4 (x, y, z)

ρ3 ρ4 S1(x, y, z)

ρ1 r1 GPS handset x, y, z, t

Figure 1.2

Geometric trilateration.

T1 (x, y, z)

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 satellite 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 perform the position calculation (handset-based) or optionally returns the measurements 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 difference 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 signals. This will give a receiver access to many more satellites and improve both accuracy 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 continental 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 differential-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

1.6 Assisted-GNSS from a High Level

7

GNSS Reference Server (GRS) A-GNSS handset Time server (NTP)

Figure 1.3

A-GNSS Server

Initial uncertainty area

A simplified A-GNSS architecture.

timely, accurate location. The protocol between the server and the handset is normally 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 service 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 Handset

A-GNSS Server

Figure 1.4

A

Measure position request

B

Measure position response

C

Measure position request

D

Measure position response

Simplified A-GNSS messaging.

8

Introduction

would be a location-based application (LBA). The LBA may be a tracking application 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 assistance 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 handset-based assistance data types include the reference time, reference location, ionosphere 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 relative 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 Table 1.1

Primary A-GNSS Assistance Data Types

Assistance Data Type

1.7

9

Description

Handset- HandsetGlobal Assisted Based

Reference time

This data type allows the server to provide N 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 satellites in view.

Y

Y

Reference location

This field contains the approximate location Y of the handset and uncertainty of the location to the handset in order for it to constrain 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.

N

Y

Navigation model

This field contains the per-satellite navigation model.

N

N

Y

Ionosphere model

The ionosphere model contains the fields Y that model the delays in the propagation of the radio signals through the ionosphere.

N

Y

UTC model

The UTC model contains the fields that Y allow the user to determine the relationship between UTC time and GPS time.

N

Y

Acquisition assistance This data type provides the uncertainty 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 elevation of the satellites.

Y

N

Real-time integrity

This data type contains a list of satellites that are presently considered bad and should not be used by the handset.

Y

N

Y

Almanac

The almanac is the coarse long-term model of the satellite position and clocks.

Y

N

N

D-GNSS

This data type allows the server to provide N per-satellite differential corrections based on the initial uncertainty.

N

N

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 protocols 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 telecommunication 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 specification 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 location 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 altitude 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 Geographical 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 produce 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 provide 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 dispatch 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 technology 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 handset 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 location 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 nearest pizza restaurant or cellular phone recharging service. The application may provide 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 component 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 subscriber 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 message 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 advantages 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 performance. 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 significantly over recent releases [19]. All of these factors make Java a good basis on which to develop A-GNSS software and to demonstrate the concepts explained in this book. Java code fragments are shown to illustrate key points and algorithms throughout 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 explanation 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 understandable 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 following 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 calculations will require the use of floating point numbers. The float and double primitive 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 of Bits Minimum Value

Data Type

Format

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 754 floating point

32

1.401298464324817E-45

3.4028234663852886E38

Double

64-bit IEEE 754 floating point

64

4.9E-324

1.7976931348623157E308

14

Introduction Table 1.3

Java Bit Manipulation Operations Used Regularly for A-GPS

Operator Description

Example

Explanation of Example

>

Shift the specified number of bits to the right.

byte result = toc > 5 toc = 1111 1000 result = 0000 0111

Shifts the bits in toc, 5 to the right, and puts 0s in the MSBs.

<

Shift the specified number of bits to the left.

byte result = toe < 5 toe = 0011 1111 result = 1110 0000

Shifts the bits in toe, 5 to the left, and puts 0s in the LSBs.

|

Bitwise OR.

The cus and the crs are combined in a bitwise OR.

&

Bitwise AND.

byte result = cus | crs cus = 1010 1010 crs = 1001 1000 result = 1011 1010 byte result = crc & mask crc = 0110 0101 mask = 0000 1111 result = 0000 0101

The crc and the mask are combined in a bitwise AND.

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] [2] [3] [4]

Parkinson, B., et al., Global Positioning System: Theory and Applications, Vol. 1, Washington, D.C.: American Institute of Aeronautics and Astronautics, Inc., 1996. Kaplan, E. D., and C. J. Hegarty, (eds.), Understanding GPS: Principles and Applications, 2nd ed., Norwood, MA: Artech House, 2006. Misra, P., and P. Enge, Global Positioning System: Signals, Measurements, and Performance, 2nd ed., Lincoln, MA: Ganga-Jamuna Press, 2006. 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 Interfaces, 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 Services 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) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP), 2009. [11] 3GPP TS 25.453 Third Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signaling, 2009. [12] 3GPP TS 25.331 Third Generation Partnership Project; Technical Specification Group 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. [17] 3GPP TS 23.032 Third Generation Partnership Project; Technical Specification Group Services 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 reference 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 configuration 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 coordinate systems and reference frames. This section introduces the reference frames that are used throughout this book. They are the Cartesian coordinate system, the spherical 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 calculate 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 θ z = r sin φ

(2.1)

17

18

Coding for GNSS and the Coordinate Reference Frame z-axis

P (x,y,z)

z y-axis

x

y

x-axis

Figure 2.1

Cartesian coordinate system.

z-axis

P(r, θ, φ) r φ θ

y-axis

x-axis

Figure 2.2

Spherical coordinate system.

r=

x 2 + y2 + z 2

⎛ z φ = sin −1 ⎜ ⎜ x 2 + y2 + z 2 ⎝

⎞ ⎟ ⎟ ⎠

(2.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

2.2 World Geodetic System 1984

19

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 calculations 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 measure 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 reference 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 accompanying 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.

20

Coding for GNSS and the Coordinate Reference Frame 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

Speed of light

c

2.99792458 × 10 meters/sec

Universal gravitation parameter μ

8

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.

2.2 World Geodetic System 1984

21 z-axis

P (x, y, z) h

Normal to ellipsoid ϕ (latitude) Equator

λ (longitude)

y-axis

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 − N( ϕ) cos ϕ where

h=

p=

x 2 + y2

⎛ za ⎞ θ = a tan ⎜ ⎟ ⎝ pb ⎠ e' 2 =

(2.3)

a2 − b2 b2

N( ϕ) =

a 1 − e sin 2 ϕ 2

e 2 = 2f − f a−b f = a

Converting geodetic coordinates to ECEF is performed using (2.4). The variables are the same as those defined for (2.3). x = (N( ϕ) + h) cos ϕ cos λ

y = (N( ϕ) + h) cos ϕ sin λ z=

((N( ϕ)(1 − e ) + h))sin ϕ 2

(2.4)

22

2.3

Coding for GNSS and the Coordinate Reference Frame

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 addition, 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 directory 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.

2.4 WGS 84 Implementation

23

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 written 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 discussed here. An instance of Wgs84Coordinate is constructed without any parameters 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 location, 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 second 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. {

24

Coding for GNSS and the Coordinate Reference Frame

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 variable 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 confusing 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 classlevel 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 values 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 coordinates, 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

2.4 WGS 84 Implementation

25

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 calculated as the square root of the sum of x squared and y squared (line 37). To perform 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 altitude 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; }

26

Coding for GNSS and the Coordinate Reference Frame

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 coordinate 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 coordinates 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 definition 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 software 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 providing 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 following 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 hemispheres 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).

28

Coding for GNSS and the Coordinate Reference Frame

• •

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 inadvertently 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 operation 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 failure 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

2.6

29

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 software. 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 platform-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 message-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 occasionally 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

30

Coding for GNSS and the Coordinate Reference Frame

report on the results (lines 26–27). Inside the iteration loop for the WGS 84 benchmark 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 coverage 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 testing 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.

32

2.9

Coding for GNSS and the Coordinate Reference Frame

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, directories, 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 management 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 version 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, directory, 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 introduced 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]

[2] [3]

[4]

National Imagery and Mapping Agency, Technical Report TR8350 Department of Defense World Geodetic System 1984: Its Definition and Relationships with Local Geodetic Systems, Third Edition, Amendment 1 January 2000, NIMA Bethesda, MD. Bowring, B., “Transformation from Spatial to Geographical Coordinates,” Survey Review, XIII, 181, July 1976, pp. 323–327. Kaplan, E. D., et al., “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. Maven software project management and comprehension tool, http://maven.apache.org/ index.html.

2.9 Configuration Management [5] [6] [7] [8] [9]

33

JUnit, www.junit.org. Javadoc, http://java.sun.com/j2se/javadoc/. Shirazi, J., Java Performance Tuning, 2nd ed., Sebastapol, CA: O’Reilly & Associates, Inc., 2003. EMMA Java code coverage tool, http://emma.sourceforge.net/index.html. 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. government and operated by the U.S. Air Force (USAF). It reached initial operation capability 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 information 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 introduces GPS signal acquisition and receiver positioning. Factors affecting the accuracy 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 transmit 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 handsets 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 Positioning 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 service 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 transmit 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 throughout 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 transmit 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 transmitted by the satellite. For GPS L1, for example, it is 1,023 bits in length and provides 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 milliseconds. 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 considered in this book. It is transmitted at 1,575.42 MHz as right-hand circularly polarized (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 continuously 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 modulated 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

x

PRN –1.023 MHz

+ NAV data –50 Hz

Figure 3.1

GPS L1 signal.

C/A code

Modulo 2

GPS L1

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 satellite’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 Pand 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 location 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 message. 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 complete 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 specific 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

Figure 3.2

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

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 number. 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

Parameter Preamble

Starting Byte and Bit Bit Number Number Number Within (of 300 bits) of Bits the Byte: Byte (Bit) Notes 1

8

TOW-count truncated 31

1 (1)

17

4 (7)

Momentum or alert

48

1

6 (8)

Synchronization or antispoof

49

1

7 (1)

Subframe ID

50

3

7 (2)

Hardcoded to 0×8B

From 1 to 5

3.10 Broadcast Information Navigation Message Structure (NAV)

41

⎛ 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 specified 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 transmitted parameters and will be unique within a 7-day period. The satellite clock correction 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 F =

Table 3.3

−2 μ c2

= −4.442807633 × 10 −10

Subframe 1 Parameters

Parameter

Starting Bit Number (of 300 Bits)

Byte and Bit Number Number Within of Bits the Byte: Byte (Bit) Notes

Scale Factor Units

Week number

61

10

8 (5)

1

Satellite accuracy

73

4

10 (1)

Satellite health

77

6

10 (5)

1

TGD

197

8

22 (5)

Two’s complement 2

IODC

83 (2 MSBs) 211 (8 LSBs)

10

11 (3) and 27 (3)

toc

219

16

28 (3)

2

af2

241

8

31 (1)

af1

249

16

32 (1)

GPS week

–31

Seconds

4

Seconds

Two’s complement 2

–55

Sec/sec

Two’s complement 2

–43

Sec/sec

2

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 parameters. 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 navigation 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 elements 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.

Table 3.4

Subframe 2 Parameters

Starting Bit Number Parameter (of 300 Bits)

Number Byte and Bit of Bits Number Within the Byte: Byte (Bit) Notes

IODE

61

8

8 (5)

Crs

69

16

9 (5)

Two’s complement

Scale Units Factor

2–5

Δn

91

16

12 (3)

Two’s complement

2

–43

M0

107 (8 MSBs) 121 (22 LSBs)

32

14 (3) 16 (2)

Two’s complement

2

–31

Cuc

151

16

19 (7)

Two’s complement

2–29

e

159 (8 MSBs) 181 (24 LSBs)

Cus A

1/2

toe

20 (7) 23 (5) Two’s complement

Meters Semicircles/ sec Semicircles Radians

2

–33

2

–29

Radians

211

16

27 (3)

227 (8 MSBs) 241 (24 LSBs)

32

29 (3) 31 (1)

2

–19

Meters

271

16

34 (7)

2

4

Seconds

1/2

3.10 Broadcast Information Navigation Message Structure (NAV) Table 3.5

43

Subframe 3 Parameters

Starting Bit Number (of Parameter 300 Bits)

Number Byte and Bit of Bits Number Within the Byte: Byte (Bit) Notes

Scale Factor Units

Cic

61

16

8 (5)

Two’s complement 2–29

Ω0

77 (8 MSBs) 91 (24 LSBs)

32

10 (5) 12 (3)

Two’s complement 2

–31

Semicircles

Cis

121

16

16 (1)

Two’s complement 2

–29

Radians Semicircles

Radians

i0

137 (8 MSBs) 151 (24 LSBs)

32

18 (1) 19 (7)

Two’s complement 2

–31

Crc

161

16

21 (1)

Two’s complement 2

–5

Meters Semicircles

ω

197 (8 MSBs) 211 (24 LSBs)

32

25 (5) 27 (3)

Two’s complement 2

–31

Ω

241

24

31 (1)

Two’s complement 2

–43

Semicircles/sec

IODE

271

8

34 (7)

IDOT

279

14

35 (7)

Two’s complement 2

–43

Semicircles/sec

A=

( A)

2

μ A3 t k = t − t oe n0 =

n = n 0 + Δn M k = M 0 + nt k M k = E k − e sin E k ⎛ 1 − e 2 sin E (1 − e cos E )⎞ ⎛ sin v k ⎞ k k ⎟ −1 ⎜ = v k = tan −1 ⎜ tan ⎟ ⎜ ⎟ 1 − e cos E v E e − cos cos )( ⎝ k) ⎠ k⎠ k ⎝ ( ⎛ 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 δ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

(3.4)

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

Parameter

Subframe 4 Page 18 Parameters Starting Bit Number (of 300 Bits)

Page number 63

Number of Bits 6

Byte and Bit Number Within the Byte: Byte (Bit)

Notes

8 (7)

The parameters below are for when this is 18.

9 (5)

Two’s complement

Scale Factor

Units

Ionosphere Model Parameters α0

69

8

2

–30

Seconds

–27

Seconds per semicircle

α1

77

8

10 (5)

Two’s complement

2

α2

91

8

12 (3)

Two’s complement

2–24

Seconds per 2 semicircle

α3

99

8

13 (3)

Two’s complement

2

–24

Seconds per 3 semicircle

β0

87

8

11 (7)

Two’s complement

2

11

Seconds

β1

121

8

16 (1)

Two’s complement

2

14

Seconds per semicircle

β2

129

8

17 (1)

Two’s complement

216

Seconds per 2 semicircle

β3

137

8

18 (1)

Two’s complement

2

16

Seconds per 3 semicircle

UTC Model Parameters A1

151

24

19 (7)

Two’s complement

2

–50

Sec/sec

A0

181 (24 MSBs) 211 (8 LSBs)

32

23 (5) 27 (3)

Two’s complement

2

–30

Seconds

tot

219

8

28 (3)

2

12

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

Seconds

3.10 Broadcast Information Navigation Message Structure (NAV)

45

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 ionospheric 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).

Tiono

⎧ ⎡ ⎫ ⎛ x2 x 4 ⎞⎤ −9 * 5 . 0 * 10 1 . ⎪ F + AMP − + ⎜ ⎟ ⎥, x < 157 ( ) ⎪ ⎢ 2 24 ⎠ ⎦ ⎝ =⎨ ⎣ ⎬ ⎪ ⎪ −9 . F * 5.0 * 10 , x ≥ 157 ⎩ ⎭

(

)

where ⎧ 3 ⎫ n ⎪ α n φ m , AMP ≥ 0 ⎪ AMP = ⎨ n∑ ⎬ =0 ⎪ if AMP < 0, AMP = 0⎪ ⎩ ⎭ x =

2 π(t − 50,400) PER

⎧ 3 ⎫ n ⎪ ∑ β n φ m , PER ≥ 72,000 ⎪ PER = ⎨ n = 0 ⎬ ⎪ if PER < 72,000, PER = 72,000⎪ ⎩ ⎭ F = 1 + 160 . (053 . − E)

3

φ m = φ l + 0064 . cos( λ l − 1.617 ) λl = λu +

(3.5)

ψ sin A 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 (3.7)

where Δ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 substituted for ΔtLS.

3.11

Decoding and Storing the Navigation Model The broadcast package com.serverAgps.broadcast contains the Java code associated with the broadcast navigation message. It contains classes to store the navigation 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

3.11 Decoding and Storing the Navigation Model

47

NavMessage -satellites[] : SatelliteNavMessage +getSatellite(in prn : int) : SatelliteNavMessage +newData(in prn : int, in data : byte[]) 1 SatelliteNavMessage

0..*

Subframe

-prn : int -subframes[] : Subframe +newData(in data : Subframe) +getSubframe() : Subframe +getPage() : SatNavMessagePage

-data : byte[] 1

0..3

+newData(in data : byte[]) +getSubframeId() : int +getPageId() : int

1 0..25 Subframe

SatNavMessagePage -pageNumber : int -subframes[] : Subframe +getSubFrame() : Subframe +newData(in data : Subframe)

Figure 3.3

-data : byte[] 1

0..2

+newData(in data : byte[]) +getSubframeId() : int +getPageId() : int

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 numbered 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 Figure 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

satNavMsgPage

satNavMessage

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

0

0

1

1

>> 4

(d) Shifted bits

0

0

0

0

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.

3.11 Decoding and Storing the Navigation Model

49

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 commercial 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 several 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 example, 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 information 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 location 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 0..*

Utc -utcParameters +getUtcTime(in gpsTime : double) : double

SatelliteInformation -satellites[] : Satellite +getSatellite() : Satellite IonosphereModel 1 0..*

-ionosphereParameters +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 format for GPS and GLONASS information [10]. The file format consists of six different 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 messages 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 contain 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.

3.11 Decoding and Storing the Navigation Model

51

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. 43. 44. 45. 46. 47. 48. 49. 50. 51. }

Satellite.OMEGA_EARTHS_ROTATION_RATE_RADIANS_PER_SECOND * this.toe; double x = xk * Math.cos(omegak) - yk * Math.cos(ik) * Math.sin(omegak); //ECEF x double y = xk * Math.sin(omegak) + yk * Math.cos(ik) * Math.cos(omegak); //ECEF y double z = yk * Math.sin(ik); //ECEF z Wgs84Coordinate thisSatelliteCoordinate = new Wgs84Coordinate(); thisSatelliteCoordinate.setEcef(x, y, z); return thisSatelliteCoordinate;

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 calculate Ek (the eccentric anomaly) that is called on line 15. It is calculated iteratively by the calculateEccentricAnomaly() method as shown here: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.

/** * This method determines Ek through iteration. Ek is the eccentric * anomaly and is defined in the GPS SS and the GPS IS as one of the * calculations used for calculating the location of the satellite. * It normally converges in 5 to 8 iterations. * * @param mk this is the mean anomaly. * * @return the calculated eccentric anomaly. */ private double calculateEccentricAnomaly(double mk) { double ek = mk; double oldEk; //This loop normally converges within 8 iterations but we have a counter in the loop to //guard it from getting into an endless loop. int numberOfIterations = 0; do { oldEk = ek; ek = mk + this.e * Math.sin(ek); numberOfIterations++; } while(Math.abs(ek - oldEk) >= Satellite.SMALL_DIFFERENCE_IN_ESTIMATE && numberOfIterations < Satellite.MAX_NUM_ITERATIONS_CALCULATING_EK); //We should check to make sure that the iteration converged if(numberOfIterations == Satellite.MAX_NUM_ITERATIONS_CALCULATING_EK) { System.out.println(“calculateEccentricAnomaly ek did not converge”); //Do something here to indicate that there is a problem. //Throwing an exception might be the best thing to do. } return ek; }

The calculateEccentricAnomaly() method iteratively calculates Ek until the different 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 perform 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

3.11 Decoding and Storing the Navigation Model

53

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-minute 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 compared 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

3.12

GPS

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 approximate 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 information 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 immediately 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 internal 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 satellite and the handset.

3.13

Receiver Positioning This section introduces receiver positioning at a geometric level. The position calculation 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 converted 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 converted 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 situation 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

3.13 Receiver Positioning

55

r3 Tx 3 Tx 1

x r1

y

r2

Figure 3.7

Tx 2

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 foghorn; 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 solution of the user location is now the intersection of spheres and not circles. The intersection 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 priori position as described in Chapter 6. In addition, the GPS location calculation is

56

GPS

r3 Tx 3 Tx 1

x r1

r2

Figure 3.8

Tx 2

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 measurements 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

3.13 Receiver Positioning

57 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 determined 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 probability distribution [16]. The position calculation is discussed in more detail in Chapter 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

scaledUncert = initialUncert ×

1 ⎛ ⎞ erfinv⎜⎜ desiredConfidence n ⎟⎟ ⎝ ⎠ 1 ⎛ ⎞ erfinv⎜⎜Confidence n ⎟⎟ ⎝ ⎠

(3.9)

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 altitude 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 signals 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 temperature, pressure and relative humidity. A troposphere model is a model that predicts 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 temperature, 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 transmitters. When the transmitters are very close together, the area of overlap of the signals 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 constant 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 situation 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 resulting 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 Chapter 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 handset can calculate a highly accurate location by using differential corrections provided 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 satellite. 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 measurements to the satellites in view, and using its accurately known location, it determines 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 calculated 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

Figure 3.10

Tx 2

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 corrections 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?

3.17 Software Projects

61

Good DOP

Figure 3.11

Poor DOP

Good DOP and poor DOP.

Corrections GPS reference receiver R 1 (x, y, z)

Figure 3.12

GPS handset x, y, z, t

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 [1] GPS Navstar Joint Program Office, Global Positioning System Standard Positioning Service Performance Standard, 4th ed., September 2008. [2] GPS Navstar Joint Program Office, Global Positioning System Standard Positioning Service Signal Specification, 2nd ed., June 2005. [3] Parkinson, B. W., “Introduction and Heritage of NAVSTAR, the Global Positioning System,” in Global Positioning System: Theory and Applications, Vol. 1, Washington, D.C.: American Institute of Aeronautics and Astronautics, Inc., 1996. [4] GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User Interfaces, 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 Interfaces, 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 Interfaces, 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 Astronautics, Inc., 1996. [9] The NovAtel log format specification, http://www.novatel.com/. [10] Gurtner, W., RINEX: The Receiver Independent Exchange Format, Version 2.10, Astronomical 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 Survey, 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 Institute 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 compared to stand-alone GPS by removing the need to demodulate the navigation message 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 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. 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 coverage area of the wireless network or geographically over the Earth for global coverage. 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

Time server (NTP)

Network Location Server (LS)

Location-based application (LBA)

Figure 4.1

Serving cell Initial uncertainty area

Emergency Services Messaging Entity (ESME)

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 assistance 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 controller (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 subject to strict privacy controls and uses the Mobile Location Protocol (MLP) [7] to

4.2 GNSS Reference Server (GRS)

65

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 Number 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 connected 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 information 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.

66

Assisted-GPS and Assistance Data

Satellite broadcast information

GNSS Reference Server (GRS)

Fixed GPS receiver Connections to GPS reference receivers

Earth

Client 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

4.2 GNSS Reference Server (GRS)

67

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 ⎜ . degrees ⎟ = 761 ⎝ a + r⎠

(4.1)

GPS Reference receiver

a α r

Earth

a + r

GPS Reference receiver

Approximate satellite orbit

Figure 4.3

GPS reference receiver separation.

68

Assisted-GPS and Assistance Data

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). d =

2α 2 πa = 16,945,0233 . meters 360

(4.2)

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 coverage (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 ⎜⎜ a+r ⎝ ⎠

GPS Reference receiver

(4.3)

β

δ

a χ r α

a+r

GPS Reference receiver Earth

Approximate satellite orbit

Figure 4.4

Two-dimensional view of field of view with overlapping field of view.

4.2 GNSS Reference Server (GRS)

69

and χ is given by χ = 180 − (( β + 90) + δ)

(4.4)

In the case where the overlap (β) is 5°, δ is 13.8°, χ becomes 71.2°, and the angular 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 consideration 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 receivers 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 reference 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 Alliance (OMA) Location group. This has lead to a proliferation of proprietary interfaces 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 support 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-

70

Assisted-GPS and Assistance Data

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 completely open protocol called GRIP [12]. The OSGRS is being developed at the University 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 associated 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 collected 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

Location Server (LS)

Figure 4.5

GRIP

Open Source GNSS Reference GPS Data Server source (OSGRS)

Example OSGRS architecture.

4.2 GNSS Reference Server (GRS)

71

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.

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 satellites or more. If the data source is from a global network such as a commercial provider 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. 8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190EFA448B065C8CA12AA50 91B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B065C8CA1AC0079F86A32C9FFF0269127BC14675 EF1C04CFFAB23A5E094 8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF80143D38B065C8CA12A870 A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B065C8CA1ACFFFBF9331B37FFA6268B1C9813770 AD0980CFFAB4C87E6B3 0602FFFE2906FFF8 3 6 8 24 00001F0000000890970E4B070E 407 5410671 2 407 1 0 0 407 5410671 4 407 1 0 0

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 latitude, 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.

72

4.3

Assisted-GPS and Assistance Data

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 provides 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 measurements 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 networks 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 protocol 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 location 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 approximate 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 database. 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 location 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 protocol

GNSS reference server (GRS)

Time is synched using NTP protocol

6. Location response

Location server (LS)

1. Location request

Time server (NTP)

2. Position request

A-GPS handset 3. Required assistance data 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 satellites are in view of the approximate location. The LS uses the ephemeris to calculate 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 satellites that are above a certain mask angle are considered to be in view of that location. 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 alternatively 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 protocol [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 applications, applications that provide directions to services or facilities, and geo-games. They all require the location of the handset at a given time.

74

Assisted-GPS and Assistance Data

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 connect 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 requirements 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, respectively, with a maximum location age of 30,000 milliseconds, or 30 seconds. 2 hummer 0800000000 100 50 30000

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

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 declarations and then enters attempts to read from the input stream (line 42). It then enters

114

Assisted-GPS Location Within a Network

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 positioning 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.

Stand alone SMLC (SAS)

Figure 5.5

PCAP

Radio network controller (RNC)

RRC

UTRAN elements involved in location.

Node B

RRC

UE

5.4 PCAP and RRC

115

RNC

SAS Position Calculation Request [approx location, measurements] Position Calculation Response [location] Or Position Calculation Failure [cause] (a)

SAS

RNC 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

5.4.1

(a, b) RNC-centric procedures.

PCAP Procedures

The two functions for RNC-centric operation are the position calculation and information exchange elementary procedures (EPs) and are described here. The position calculation procedure allows the RNC to query the SAS for a position estimate of a UE. The message flow is shown in Figure 5.6(a). The position calculation 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 calculates 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 location, 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 predetermined based on provisioning the SAS. The SAS responds with an information

116

Assisted-GPS Location Within a Network

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 requirements 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. Alternatively, 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

A B

C

SAS

Position Initiation Request [UE capabilities, approx location, QoP] Position Activation Request [positioning method, assistance data]

Position Activation Response [location or measurements] Or

D

Position Activation Failure [cause]

E

Position Initiation Response [location]

F

Position Initiation Failure [cause]

Or

Figure 5.7

SAS-centric procedures.

5.5 Software Projects

117

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 measurements 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 variant, 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.

5.5

Software Projects The following are software projects for this chapter: 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

118

Assisted-GPS Location Within a Network

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 [1] 3GPP TS 44.031 Third Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (MS)—Serving Mobile Location Center (SMLC) Radio Resource LCS Protocol (RRLP), 2009. [2] 3GPP TS 25.453 Third Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iupc Interface Positioning Calculation Application Part (PCAP) Signaling, 2009. [3] 3GPP TS 25.331 Third Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Resource Control (RRC); Protocol Specification, 2009. [4] 3GPP2 C.S0022/TIA IS-801, Position Determination Service Standard for Dual Mode Spread Spectrum Systems, 2004. [5] 3GPP TS 23.271 Third Generation Partnership Project; Technical Specification Group Services 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 Location Services Enhancements, 2002. [7] 3GPP TS 43.059 Third Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Functional Stage 2 Description of Location Services (LCS) in GERAN, 2008. [8] 3GPP TS 25.305 Third Generation Partnership Project; Technical Specification Group Radio Access Network; Stage 2 Functional Specification of User Equipment (UE) Positioning in UTRAN, 2008. [9] Secure User Plane Location Architecture, Open Mobile Alliance, OMA-AD-SUPL, 2009. [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 Protocol 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 Application 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.

5.5 Software Projects

119

[16] Japan Aerospace Exploration Agency, Quasi-Zenith Satellite System Navigation Service, Interface Specification for QZSS (IS-QZSS), 2008. [17] GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User Interfaces, Interface Specification, IS-GPS-200, Navstar GPS Joint Program Office, El Segundo, CA, 2009. [18] 3GPP TS 23.032 Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Universal Geographical Area Description (GAD), 2004. [19] 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, 2008. [20] 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), 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 handset-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 protocol 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 measurements (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

GPS TOW

Notes 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

Doppler

+/− 6,553.6 Hz

dB-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

Multipath indicator Pseudorange RMS error

The handset’s estimate of the carrier to noise ratio.

The fractional value of the code phase measurement. An indicator of the multipath as measured by the handset and set to low, medium, or high.

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 handset 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 accuracy 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.

6.3 Positioning Using GPS Code Phase Measurements

123

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 measurement 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 discussed in Section 6.3 does not have this optimization, but is a single run through a position calculation.

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 determining 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 r=

(xs

− x u ) + (ys − yu ) + (z s − z u ) 2

2

2

(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

124

Position Calculation z

s (x s , y s , zs )

r

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 synchronized 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 generally 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)

6.3 Positioning Using GPS Code Phase Measurements

125

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 estimated handset clock error, and ε is the residual error. The contents of each element of Δρ when there are four satellite measurements are shown in

(ρ (ρ (ρ (ρ

⎡ ⎢ ⎢ Δρ = ⎢ ⎢ ⎢ ⎢ ⎣

1

2

3

4

) ) ) )

( ( ( (

) ) ) )

− Δt 1SV × c − r 1 + t r × c ⎤ ⎥ 2 − Δt SV × c − r2 + tr × c ⎥ ⎥ 3 − Δt SV × c − r3 + tr × c ⎥ ⎥ 4 − Δt SV × c − r4 + tr × c ⎥ ⎦

(6.8)

where ρ is the measured pseudorange to satellite n, ΔtSVn is satellite clock error for satellite n, c is the speed of light, rn is the calculated range to satellite n from the current 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 n

⎡ ⎢− ⎢ ⎢ ⎢− H=⎢ ⎢ ⎢− ⎢ ⎢ ⎢⎣−

⎤ c ⎥ r r r ⎥ x s2 − x u y s2 − y u z s2 − z u ⎥ − − c⎥ r2 r2 r2 ⎥ x s3 − x u y s3 − y u z s3 − z u ⎥ − − c⎥ r3 r3 r3 ⎥ x s4 − x u y s4 − y u z s4 − z u ⎥ − − c⎥ r ⎦ r4 r4 x 1s − x u 1

−

y1s − y u 1

−

z 1s − z u 1

(6.9)

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.

126

Position Calculation

⎡Δx u ⎤ ⎢Δy ⎥ Δx = ⎢ u ⎥ ⎢Δz u ⎥ ⎢Δt ⎥ ⎣ u⎦

(6.10)

The weighted least squares solution to the equation is shown in

(

x$ = H T WH

)

−1

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 satellites at higher elevations are given a higher weight; this also accounts for measurement errors. The implementation of the least squares solution is discussed later in this chapter. Generally, the process of calculating the handset location consists of preprocessing 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 transmission. 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.

6.3 Positioning Using GPS Code Phase Measurements

127

These steps are outlined in the following sections with the code that implements the algorithm. The GpsPositionCalculation Java class contains the code to calculate the location given a set of GPS measurements, the ephemeris, an initial location 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 information 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 precalculating 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 position calculation for all of the records in a RINEX file. It has command line parameters 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 observation data comes from a RINEX file for the “mia3” CORS station [3]. It is a permanent 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 measurement 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.

128

Position Calculation

GPS Measurement 16/03/2009 12:00:00 AM wk: 1523 gpsSecondsOfWeek: 86400.0 fractionsOfSeconds: 0.0 PRN: 32 pseudorange: 23318037.10 PRN: 31 pseudorange: 20928086.44 PRN: 14 pseudorange: 21657793.22 PRN: 16 pseudorange: 23168462.59 PRN: 30 pseudorange: 22345695.94 PRN: 22 pseudorange: 21865208.73

Note that the RINEX observation contains the pseudorange measurements. The pseudoranges have been constructed from the original code phase measurements. The measurements are not normally presented to the position calculation method as pseudoranges, but are actually code phase measurements, that is, the offset within the 1,023-bit-long C/A code. To preserve this and make the position calculation 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 absolute 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 0.0 PRN: 32 wholeChips: 798 fracChips: PRN: 31 wholeChips: 827 fracChips: PRN: 14 wholeChips: 248 fracChips: PRN: 16 wholeChips: 288 fracChips: PRN: 30 wholeChips: 549 fracChips: PRN: 22 wholeChips: 955 fracChips:

wk: 1523 gpsSecondsOfWeek: 86400.0 fractionsOfSeconds: 0.55 0.18 0.20 0.15 0.57 0.98

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 position 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 Positioning Using GPS Code Phase Measurements

6.3.3

129

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 satellite. 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 calculation. 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 = 25 && satelliteHealthCode = 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

132

Position Calculation PRN: PRN: PRN: PRN:

6.3.6

14 16 30 22

satClockCorrectionSec: 0.00014040 satClockCorrectionSec: -0.00006731 satClockCorrectionSec: -0.00013265 satClockCorrectionSec: -0.00020342

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-frequency 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: PRN: PRN: PRN: PRN: PRN:

32 31 14 16 30 22

TGD: TGD: TGD: TGD: TGD: TGD:

-0.000000003260 -0.000000013039 -0.000000009313 -0.000000009779 -0.000000007916 -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: PRN: PRN: PRN: PRN: PRN:

32 31 14 16 30 22

satClockCorrectionSec: satClockCorrectionSec: satClockCorrectionSec: satClockCorrectionSec: satClockCorrectionSec: satClockCorrectionSec:

6.3.7

-0.00028607 0.00005485 0.00014041 -0.00006730 -0.00013264 -0.00020341

satClockCorrMeters: satClockCorrMeters: satClockCorrMeters: satClockCorrMeters: satClockCorrMeters: satClockCorrMeters:

-85760.25882810 16444.73363056 42093.99616495 -20175.28541734 -39764.21938552 -60979.78075286

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

(

)

& Δt X X S′ = R z Ω e S

(6.14)

& is the rotation rate of the Earth where Rz is the rotation matrix about the z axis, Ω 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 satellite location. Equation (6.15) is the expanded form of the rotation matrix with the signal travel time and Earth rotation rate terms included.

6.3 Positioning Using GPS Code Phase Measurements

Rz

& Δt ⎡ cos Ω e & Δt = ⎢− sin Ω & Δt Ω e e ⎢ 1 ⎢⎣

(

)

133

& Δt 0⎤ sin Ω e & Δt 0⎥ cos Ω e ⎥ 1 1⎥⎦

(6.15)

which gives the corrected satellite coordinates as specified by & Δtx + sin Ω & Δty x ′ = cos Ω e e & & y ′ = − sin Ω Δtx + cos Ω Δty e

e

(6.16)

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 calculated 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 locations in ECEF coordinate along with the magnitude of the correction in meters is shown here: PRN: PRN: PRN: PRN: PRN: PRN:

32 31 14 16 30 22

correctedSatLocn:-11501835.93 correctedSatLocn: -1452239.96 correctedSatLocn: 13580751.29 correctedSatLocn: 60349.37 correctedSatLocn: 16300425.99 correctedSatLocn: 11669635.47

-11195740.73 21600295.49 correctionSizeMeters: 91.04 -19791486.46 17799129.73 correctionSizeMeters: 101.02 -14259786.92 17887352.18 correctionSizeMeters: 103.74 -23829335.30 -11422170.12 correctionSizeMeters: 134.29 -8989904.38 18552206.96 correctionSizeMeters: 101.18 -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.

134

Position Calculation

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 differs significantly from the altitude of the handset. Note that since the pseudomeasurement is a direct measurement, it is not subject 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 digital 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 measured 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 differences 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-

6.3 Positioning Using GPS Code Phase Measurements

135

culating the elevation of the satellites that have been measured and removing measurements 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 testing. 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 calculated 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: PRN: PRN: PRN: PRN: PRN:

32 31 14 16 30 22

elevation: elevation: elevation: elevation: elevation: elevation:

28.60 64.03 48.64 25.32 33.09 42.18

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.elevation(satelliteLocations[i]); 16. 17. if(Math.toDegrees(satElevationRadians) < this.satelliteElevationMask) 18. { 19. //prune out the satellite because it is below the elevation mask

136 20. 21. 22. 23.

Position Calculation //this sample code does not do the pruning } } }

6.3.11

Pruning Weak Measurements

The handset returns the quality measures associated with each satellite measurement 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 ionosphere was given in (3.5). The ionospheric delay coefficients come from subframes 4 and 5 of the broadcast navigation message. The ionosphere correction method, Ionosphere.getIonosphereDelay(), is passed the latitude and longitude of the user’s estimated 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 calculating 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. 2. 3. 4.

double psi = (0.0137/(elevationSemiCircles + 0.11)) - 0.022; double latitudeSemiCirc = Satellite.radsToSemiCircles(Math.toRadians(latitudeDegrees)); double phi = latitudeSemiCirc + (psi * Math.cos(azimuthRadians));

6.3 Positioning Using GPS Code Phase Measurements 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

137

//phi is limited so it is set to the boundary value if it is outside the range if (phi > +0.416) { phi = +0.416; } if (phi < -0.416) { phi = -0.416; } double lambdaI = Satellite.radsToSemiCircles (Math.toRadians(longitudeDegrees)) + (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: PRN: PRN: PRN: PRN: PRN:

6.3.13

32 31 14 16 30 22

ionoCorrection: ionoCorrection: ionoCorrection: ionoCorrection: ionoCorrection: ionoCorrection:

4.29 2.50 2.73 4.94 3.34 3.26

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 contribution 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]: d =

2.312 sin θ + 194 . x 10 2

−1

+

0084 . sin θ + 06854 . x 10 −3 2

(6.18)

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: PRN: PRN: PRN: PRN: PRN:

32 31 14 16 30 22

tropoCorrection: tropoCorrection: tropoCorrection: tropoCorrection: tropoCorrection: tropoCorrection:

4.99 2.66 3.19 5.58 4.38 3.56

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().

138

Position Calculation TroposphereModel +getTroposphereDelay(in elevation : double) : double

HopfieldTroposphereModel +getTroposphereDelay(in elevation : double) : double

Figure 6.2

Class diagram for the troposphere classes.

The GPS position calculation class is shown in Figure 6.3. The position calculation 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 calculation involves iterating until the change from one iteration to the next is sufficiently 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 elevation of the satellite from the estimated location. The least squares estimate of the location x is given by (6.19). The solution iterates 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. 2. 3.

public PosCalcResult calculatePosition(GpsMeasurement measurement, RangeMeasurementSet rangeMeasurements, SatelliteInformation ephemeris, Wgs84Coordinate initialLocation, IonosphereModel iono)

poscalc::GpsPositionCalculation

1

1

TroposphereModel

-tropo : TroposphereModel +calculatePosition() : Wgs84Coordinate

Figure 6.3

+getTroposphereDelay(in elevation : double) : double

Class diagram for the GPS position calculation.

6.3 Positioning Using GPS Code Phase Measurements

139

4. { 5. //Calculate the location 6. 7. //call the method to perform the preprocessing 8. Wgs84Coordinate[] satelliteLocations = performPosCalcPreprocessing(measurement,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 27. int numberOfIterations = 0; 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, estimatedPresentLocation); 54. 55. //Set up the delat p matrix 56. p = this.setUpPmatrix(measurement, rangeMeasurements, satelliteLocations, x, estimatedPresentLocation); 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

140 77. 78. 79. 80. 81. 82. limit 83. 84. 85. 86. 87. 88. 89. }

Position Calculation estimatedPresentLocation.setEcef(x.get(0,0), x.get(1,0), x.get(2,0)); //increment the iteration counter. It is used as a last resort to break the iteration numberOfIterations++; //Break out of the loop when the estimate has not changed much or we hit the iteration } while(xHat.norm() > 1 && numberOfIterations < GpsPositionCalculation.MAX_ITERATIONS); //set up the result and return it PosCalcResult result = new PosCalcResult(estimatedPresentLocation); return result; 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.

x0

. ⎡ 983,04658 ⎤ ⎢−5,662,32388 . ⎥ ⎥ =⎢ . ⎥ ⎢ 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 complete the matrix, we first calculate the range from the estimated location x0 to satellite 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 : 2 r: 3 r: 4 r: 5 r: 6 r:

23271479.32 20780526.90 21483641.96 23063820.33 22252736.49 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 ⎢ 23271479.32 ⎢ −142139.21 − 983046.58 ⎢ − 2078052690 . ⎢ 13580826 .41 − 983046.58 ⎢ − 2148364196 . H=⎢ ⎢ − 60483.65 − 983046.58 ⎢ 23063820.33 ⎢ 16300474.85 − 983046.58 − ⎢ 22252736.49 ⎢ 11669760.39 − 983046.58 ⎢− ⎣ 2179974186 .

− − − − − −

1119580597 . + 566232388 . 23271479.32 1979149385 . + 566232388 . 2078052690 . −14259715.37 + 566232388 . 2148364196 . −23829334.95 + 5662323.88 23063820.33 −898981578 . + 566232388 . 22252736.49 −23488115.02 + 566232388 . 2179974186 .

− − − − − −

21600295.49 − 2756974.22 23271479.32 17799129.73 − 2756974.22 2078052690 . 17887352.18 − 2756974.22 . 2148364196 −11422170.12 − 2756974.22 23063820.33 1855220696 . − 2756974.22 22252736.49 −3820602.87 − 2756974.22 2179974186 .

2.99792458 × 10 8 ⎤ ⎥ ⎥ 2.99792458 × 10 8 ⎥ ⎥ 2.99792458 × 10 8 ⎥ ⎥ 2.99792458 × 10 8 ⎥ ⎥ ⎥ 2.99792458 × 10 8 ⎥ ⎥ 2.99792458 × 10 8 ⎥ ⎦

and the resulting H matrix for the first iteration is shown as the output of the following Matrix.toString() method. Note that the H matrix is recalculated each iteration as the location is refined.

6.3 Positioning Using GPS Code Phase Measurements H: Matrix size: (6, 4) 0.5364885635911322 0.23777675557667408 0.11719079854128966 0.679923211043823 −0.586385899354948 0.40018647925537915 0.04000626095527544 0.787684397310103 −0.6883368890305347 0.14953578843670645 −0.4902163042645664 0.8177093713517571

−0.8097173801045364 −0.7238582346158065 -0.7042743491416346 0.6147786506691642 −0.7098108023807316 0.30172729249556474

141

2.99792458E8 2.99792458E8 2.99792458E8 2.99792458E8 2.99792458E8 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); 14. for (int i = 0; i < measurement.getNumSatsMeasured(); i++) 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. 2. 3. 4. 5. 6. 7. 8. 9.

Matrix C = new Matrix(measurement.getNumSatsMeasured(), measurement.getNumSatsMeasured()); for (int i = 0; i < measurement.getNumSatsMeasured(); i++) { double satElevation = handsetLocEstimate.elevation(satelliteLoc[i]); C.setElement(i, i, 1/Math.sin(satElevation)); } Matrix W = C.invert();

142

Position Calculation

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 0.4787 0.0 0.0 0.0 0.0 0.0

size: (6, 6) 0.0 0.0 0.8990 0.0 0.0 0.7506 0.0 0.0 0.0 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) ⎤ ⎢ ⎥ . × c ) − (20,780,52690 . + 00 . × c) ⎥ ⎢(20,928,086.44 − 000005484 ⎢(2165 , 7,79322 . − 000014040 . × c ) − (21,483,64196 . + 00 . × c) ⎥ ⎢ ⎥ Δρ = ⎢(23,168,462.59 + 000006731 . × c ) − (23,063,82033 . + 00 . × c) ⎥ ⎢ ⎥ . × c ) − (22,252,736.49 + 00 . × c )⎥ ⎢(22,345,695.94 + 000013265 ⎢ ⎥ , ,20873 . + 00 . 0020342 × c ) − (21799 , ,74186 . + 00 . × c) ⎦ ⎣(21865

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); 13. for (int i = 0; i < measurement.getNumSatsMeasured(); i++) 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. }

6.3 Positioning Using GPS Code Phase Measurements

143

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 deviation). A model of a horizontal error ellipse is shown in Figure 6.4. The ellipse is offset 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 calculate the covariance matrix of the parameters as shown in

(

C x$ = H T WH

)

−1

(6.20)

This is then converted to the ENH coordinate system using C xlocal = RC x$ R T $

where R is the rotation defined in (6.22)

(6.21)

144

Position Calculation N

E σmax σmin

Figure 6.4

Error ellipse.

⎡− sin φ cos λ − sin φ sin λ cos φ⎤ R = ⎢ − sin λ cos λ 0 ⎥ ⎢ ⎥ ⎢⎣ cos φ cos λ cos φ sin λ sin φ ⎥⎦

(6.22)

where φ is the latitude and λ is the longitude. The resulting local covariance matrix is given by

C xlocal $

⎡ σ e2 = ⎢⎢σ ne 2 ⎢⎣σ he

σ en σ σ

2 n 2 hn

σ eh ⎤ σ nh ⎥⎥ σ h2 ⎥⎦

(6.23)

The VCV is then calculated by multiplying the variance factor (discussed in Section 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 VCV = ⎢ e ⎣σ ne

σ en ⎤ σ 2n ⎥⎦

The orientation of the ellipse (β) can be calculated using

(6.25)

6.3 Positioning Using GPS Code Phase Measurements

β=

145

⎛ 2σ ⎞ 1 tan −1 ⎜ 2 en 2 ⎟ 2 ⎝σn − σe ⎠

(6.26)

The major axis at 39.4% confidence is given by semiMajor =

1⎛ 2 2 ⎜σ e + σ n + 2⎝

(σ

2 e

− σ 2n

)

(σ

2 e

− σ 2n

)

2

2 ⎞ + 4( σ en ) ⎟ ⎠

(6.27)

2 ⎞ + 4( σ en ) ⎟ ⎠

(6.28)

and the minor axis is given by semiMinor =

1⎛ 2 2 ⎜σ e + σ n − 2⎝

2

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 position 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.

146

Position Calculation

6.3.16.2

Variance Factor

The variance factor [8] is defined by vf =

v$ T Wv$ n −u

(6.30)

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 HDOP = C x$ 11 + C x$ 22

(6.31)

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 calculated 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 measurements 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 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. 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 position 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 ⎢ 2 ⎢v x H=⎢ 3 v ⎢ x ⎢ v x4 ⎣

v1y

v1z

v y2

v z2

v y3

v z3

v y4

v z4

n

s1 ⎤ ⎥ s2 ⎥ s3 ⎥ ⎥ s4 ⎥ ⎦

(6.32)

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 determine ρ (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 vectors of the perifocal coordinate system.

148

Position Calculation

vp =

μ (i sin v) ρ

vq =

μ ( e + cos v) ρ

(6.34)

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 p ⎤ ⎡v i ⎤ ⎢ ⎥ ~⎢ ⎥ ⎢v j ⎥ = R ⎢v q ⎥ ⎢⎣v w ⎥⎦ ⎢⎣v k ⎥⎦

(6.35)

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 inclination 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 reference frame. This is given by & y⎤ ⎡v x ⎤ ⎡v i ⎤ ⎡− Ω ⎢ ⎥ ⎢ ⎥ ⎢ & ⎥ ⎢v y ⎥ = ⎢v j ⎥ − ⎢ Ωx ⎥ ⎢v z ⎥ ⎢v ⎥ ⎢⎣ 0 ⎥⎦ ⎣ ⎦ ⎣ k⎦

(6.38)

The Δx matrix has the same meaning as used for the code phase-based calculation as shown in (6.10). The significant difference is that it does not need to be

6.5 Hybrid Position Calculation

149

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 1 1 1 ⎢ F c × r + s ⋅v +tu ⎢ t ⎢ ΔF r2 c × r 2 + s 2 ⋅ v2 + t u ⎢ F t Δρ = ⎢ 3 ⎢ ΔF ⎢ r c × r 3 + s 3 ⋅ v3 + t u ⎢ Ft ⎢ 4 ⎢ ΔF r c × r 4 + s 4 ⋅ v 4 + t u ⎢⎣ Ft

⎤ ⎥ ⎥ ⎥ s2 − r ⎥ ⎥ ⎥ s3 − r ⎥ ⎥ ⎥ s4 − r ⎥ ⎥⎦

(s

1

(

( (

)

−r

)

)

(6.39)

)

where ΔFrn is the measured Doppler shift for satellite n, Ft is the transmitted frequency 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 difference between range measurements and GPS measurements is that they are not subject 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.

6.6

Software Projects The following are software projects for this chapter: 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

150

Position Calculation

2.

3.

4.

5.

6.

7.

8.

9.

and then check whether the measurement is valid before putting into the matrices for the least squares process. 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. 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. 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. 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. 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. 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. 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. Implement the Doppler shift-based position calculation described in Section 6.4.

References [1]

[2]

[3]

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. 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. SOPAC, Scripps Orbit and Permanent Array Centre, http://sopac.ucsd.edu/.

6.6 Software Projects [4]

151

GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User Interfaces, Interface Specification, IS-GPS-200, Navstar GPS Joint Program Office, El Segundo, CA, 2004. [5] GPS Navstar Joint Program Office, Global Positioning System Standard Positioning Service 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, University 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 performance 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 handsets 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 handset-assisted GPS works. In this mode, the handset generally requests the GPS acquisition 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 assistance data and also complete the reference time assistance data type. The handset-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 synchronizes 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 satellite 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 location 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 provided 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 accurately, the server needs to employ a time recovery algorithm [1]. The aim is to calculate 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 minimum, that is, a minimum of five satellite measurements; that is because an additional 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 position calculations required for a single location fix as shown in the next section.

7.1 The Time Determination Problem Table 7.1

155

Position Calculation Accuracy for Different GPS Time Offset Values

Number of Satellites

Time Offset Applied to Measured Time in Seconds

Distance from Ground Truth in Meters (Average/ Standard Deviations)

Distance from Ground Truth 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.

156

GPS Position Calculation with Time Recovery

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 performance 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 calculation 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 seconds 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 calculation are sufficiently small. Figure 7.1 shows the location error and the SSR for a typical 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 latest 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 location 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.

7.2 Iterative Time Recovery

157

Location error by time (search window is 3.5 seconds each side of measured) 1600 1400

Error (meters)

1200 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

SSR

1.20E+07 1.00E+07 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 window. 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 window 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.

158

GPS Position Calculation with Time Recovery

c

SSR

a

e

d b Time (a) c

SSR

e

b a

d Time (b)

c

SSR

e

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 location of the handset for each given time. The search window size and the stop resolution are passed into the method and used by the bracketing search. A segment of the

7.2 Iterative Time Recovery

159

calcPositionIterativeTimeRecovery() method is shown next. The time recovery method starts by establishing the bounds of the search (lines 3–4) so that the algorithm 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 location (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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.

double originalSecondsOfWeek = theTime.getGpsSecondsOfWeek(); double minimumTime = originalSecondsOfWeek - searchWindowSizeSec; double maximumTime = originalSecondsOfWeek + searchWindowSizeSec; //Start with a fairly coarse time step double timeStepSize = 0.5; //unless the search window is only small in which case we will make it smaller if(searchWindowSizeSec < 1) { timeStepSize /= 4; } PosCalcResult result; //find the first time where we get a location and this is the start of the bracket double earliestSuccessTime = minimumTime; while(true) { theTime.set(originalWeek, earliestSuccessTime); result = this.calculatePosition(measurement, ephemeris, initialLocation, iono); if(result.getLocation() != null || earliestSuccessTime >= maximumTime) { break; } earliestSuccessTime += timeStepSize; } //If we got at least one location then we can continue on if(result.getLocation() != null) { //record the SSR for the earliest time 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); 6. result = this.calculatePosition(measurement, ephemeris, initialLocation, iono);

160

GPS Position Calculation with Time Recovery

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); 15. result = this.calculatePosition(measurement, ephemeris, initialLocation, iono);

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 pruning 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 calculations 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 measurement software runs the test 100 times. This is so that any short-term effects

7.2 Iterative Time Recovery Table 7.2

161

Position Calculation Accuracy Using the Iterative Time Recovery Algorithm

Time Recovery Number of Search Satellites Window

Time Offset Applied to Measured Time

Distance from Ground Truth Meters (Average/ Standard Deviation)

Distance from Ground Truth Meters 67%/95% Yield %

Average Number of Discrete Position Calculations Required to 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.

162

GPS Position Calculation with Time Recovery Table 7.3 Time Recovery Performance for the Iterative Time Recovery Algorithm Time Recovery Search Window

Time Recovery Stop Interval

Percentage Time Offset of Measured Applied to Transactions TPS to TPS Measured Per Second Without Time 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 performed. 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 system. 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 measurements with the reference time that is provided by the LS [4]. A conservative estimate 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

7.3 Integrated Time Recovery

163

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 application, a more efficient time recovery algorithm is required. In Section 7.3, we consider 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 minimum 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 ⎥ ⎢t ⎥ ⎢ u ⎥ ⎢⎣t G ⎥⎦

(7.1)

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 ⎡ ⎢− ⎢ ⎢ ⎢− H=⎢ ⎢ ⎢− ⎢ ⎢ ⎢⎣−

⎤ − 1 R& ⎥ r r r ⎥ 2 2 2 x s − x u ys − yu z s − z u ⎥ − − − 1 R& ⎥ 2 2 2 r r r ⎥ x s3 − x u y s3 − y u z s3 − z u ⎥ & − − − 1R ⎥ 3 3 3 r r r ⎥ 4 4 4 x s − x u ys − yu z s − z u ⎥ − − − 1 R& ⎥ ⎦ r4 r4 r4 x 1s − x u 1

−

y1s − y u 1

−

z 1s − z u 1

(7.2)

& is the range rate that is calculated as specified in equation 5 in [3] and is where R shown in s−u +f +ε R& = ( v s − v u ) ⋅ r

(7.3)

164

GPS Position Calculation with Time Recovery

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 Time Offset Applied to Number Measured of Satellites Time

Distance from Ground Truth Meters (Average/ Standard Deviations)

Distance from Ground Truth Meters 67%/95% Yield %

All visible

0

2.69/1.90

3.00/6.12

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

99.99

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

7.3 Integrated Time Recovery

165

tively (see Figure 6.1), r is given in (6.2), f is the receiver clock drift in meters per second, and ε is the error. The range rate is the rate of change of the range between the user and the satellite. 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 important 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 different 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 measurement, 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 of Satellites Time Seconds

Transactions Per Second (TPS)

All visible

Time recovery disabled 1,430.4

All visible

0

1,428.9

All visible

1

1,407.0

All visible

2

1,184.9

All visible

3

1,209.4

All visible

4

1,305.2

All visible

5

1,404.8

All visible

6

1,428.9

All visible

7

1,420.6

All visible

8

1,430.8

All visible

9

1,415.8

All visible

10

1,407.1

166

7.4

GPS Position Calculation with Time Recovery

Software Project The software project for this chapter is: 1. Modify the GpsPositionCalculation class to optionally perform integrated time recovery.

References [1] [2] [3] [4]

Syrjarinne, J., “Possibilities for GPS Time Recovery with GSM Network Assistance,” Proceedings ION GPS 2000, Salt Lake City, UT, 2000. Press, W. H., et al., Numerical Recipes in C: The Art of Scientific Computing, 3rd ed., New York: Cambridge University Press, 2007. Glennon, E., “Solution of Timing Errors for AGPS,” Proceedings ION GPS 2005, 2005. 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 situation, 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 location. The alternative is to make use of whatever GPS measurements are available and combine them with other measurements. Combining measurements from multiple location technologies in order to calculate the location is known as hybrid positioning. This chapter 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 experiments and results that use simulated range measurements to calculate a location 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 emergency situation. An emergency situation is often a one-off cold-start location determination. 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 measurements 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 (discussed 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 measured 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 measurements. 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 difference 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) contains 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

8.2 Hybrid Position Calculation

169 z

s (x s , y s , zs )

t (x t ,y t ,zt) 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 ⎢ 2 ⎢ ρ 2 − Δt SV Δρ = ⎢ 3 ⎢ ρ 3 − Δt SV ⎢ ⎢⎣

) ( ) ( ) (

) ) )

× c − r1 + t r × c ⎤ ⎥ × c − r2 + tr × c ⎥ ⎥ × c − r3 + tr × c ⎥ ⎥ ⎥⎦ σ 1 − rt1

(8.1)

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 measured 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. ⎡ ⎢− ⎢ ⎢ ⎢− H⎢ ⎢ ⎢− ⎢ ⎢ ⎢⎣−

⎤ c ⎥ r r r ⎥ 2 2 2 x s − x u ys − yu z s − z u ⎥ − − c⎥ r2 r2 r2 ⎥ x s3 − x u y s3 − y u z s3 − z u ⎥ − − c⎥ r3 r3 r3 ⎥ x t1 − x u yt1 − y u z t1 − z u ⎥ − − c ⎥ ⎦ r4 r4 r4 x 1s − x u 1

−

y1s − y u 1

−

z 1s − z u 1

(8.2)

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 contains 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 individual 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 calculation. 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 measurements (line 23), we go through each range measurement provided (line 25), calculate 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

1 0..* RangeMeasurement -transmiiterLocation : Wgs84Coordinate -range : double

Figure 8.2

Class diagram for range measurement data.

8.3 Hybrid Position Calculation Implementation 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

171

if(rangeMeasurements != null) { numRangeMeasurements = rangeMeasurements.getNumRangeMeasurements(); } Matrix p = new Matrix(measurement.getNumSatsMeasured() + numRangeMeasurements, 1); //Complete the p matrix for the GPS measurements for (int i = 0; i < measurement.getNumSatsMeasured(); i++) { double estimatedSatRange = handsetLocEstimate.distanceTo(satelliteLoc[i]); SatGpsMeasurement satMeasurement = measurement.getSatelliteMeasurement(i); p.setElement(i, 0, (satMeasurement.getCorrectedPseudorange() satMeasurement.getAssociatedSatClockErrorMeters()) (estimatedSatRange + (x.get(3, 0) * Satellite.C_SPEED_OF_LIGHT))); }

19. 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 measurements 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 transmitter 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); 10. for (int i = 0; i < measurement.getNumSatsMeasured(); i++) 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 measurements 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 calculation 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 provided 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

8.4 Hybrid Position Calculation Accuracy

173

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 measurements 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 technologies 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 measurements taken from the NovAtel GPS receiver on the roof of the laboratory. During 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 measurement. 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 measurements 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 accuracy 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 satellites 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 View

Horizontal and Vertical (Altitude) Errors for All Satellites in

All Satellites: Horizontal Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

4.94

8.47

100.00

4.94

8.47

100.00

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 67% Horizontal 0 Offset 1,000

95%

Accuracy Yield

67%

95%

Yield

24.26 36.24 100.00

24.26 36.24 100.00

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

8.4 Hybrid Position Calculation Accuracy

175

uses the altitude from the initial location estimate to set the range to the Earth-centered 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 precision (DOP). Table 8.4 shows the results when using the four highest elevation satellites 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 suffer in terms of both yield and accuracy. In the next section we will consider these situations 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 All Satellites: Horizontal Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

9.79

30.55 83.84

10.04

38.62 84.08

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

All Satellites: Vertical Error Altitude Offset 0

100

Accuracy 67%

Accuracy Yield

67%

95%

26.37 48.12 83.84

28.01

88.14 84.08

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

Horizontal 0 Offset 1,000

95%

Yield

176

Hybrid Location Table 8.3 Horizontal and Vertical Errors for Three Randomly Selected Satellites and an Earth-Centered Measurement All Satellites: Horizontal Error Altitude Offset 0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

24.45

74.02

87.11

82.26

236.61

87.11

24.42

73.56

87.03

82.17

234.13

86.82

10,000 28.07

99.09

87.06

81.80

Horizontal 0 Offset 1,000

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

All Satellites: Vertical Error Altitude Offset 0

100

Accuracy

Accuracy

67%

95%

Yield

67%

0.05

0.18

87.11

100.04 100.42

87.11

2.70

3.13

87.03

101.56 103.10

86.82

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

Horizontal 0 Offset 1,000

10,000 27.13

Table 8.4 Satellites

95%

Yield

Horizontal and Vertical Errors for the Four Highest Elevation

All Satellites: Horizontal Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

10.06

31.84

59.88

10.06

31.84

59.88

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

All Satellites: Vertical Error Altitude Offset 0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

34.86

69.41

59.88

34.86

69.41

59.88

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

Horizontal 0 Offset 1,000

8.4 Hybrid Position Calculation Accuracy

177

to 360°. This is combined with using the randomly selected number of GPS measurements 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 measurement) 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 location 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” measurements. 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 All Satellites: Horizontal Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

10.06

31.84

59.88

10.06

31.84

59.88

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

All Satellites: Vertical Error Altitude Offset 0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

34.86

69.41

59.88

34.86

69.41

59.88

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

Horizontal 0 Offset 1,000

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, synchronization, 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. Similarly, 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 technology 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 All Satellites: Horizontal Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

4.94

8.47

100.00

4.94

8.47

100.00

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 Horizontal 0 Offset 1,000

Accuracy

67%

95%

Yield

67%

95%

Yield

30.52

110.02

99.97

32.23

109.60

99.98

30.61

125.46

99.98

33.36

130.55

99.99

5658.21 99.98

64.45

5681.05 99.98

10,000 50.69

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

8.4 Hybrid Position Calculation Accuracy

179

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 calculation 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 accuracy 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 satellites 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 meaTable 8.7 Horizontal and Vertical Errors for Three Satellites and Three Range Measurements with a Range Error of 100 Meters All Satellites: Horizontal Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

33.42

65.52

100.00

32.89

66.60

100.00

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

All Satellites: Vertical Error Altitude Offset 0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

53.43

184.96

100.00

56.40

187.81

100.00

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

Horizontal 0 Offset 1,000

180

Hybrid Location Table 8.8 Horizontal and Vertical Errors for Three Satellites and One Range Measurements with a Range Error of 100 Meters All Satellites: Horizontal Error Altitude Offset 0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

33.42

65.52

100.00

32.89

66.60

100.00

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

Horizontal 0 Offset 1,000

All Satellites: Vertical Error Altitude Offset

Horizontal 0 Offset 1,000

0

100

Accuracy

Accuracy

67%

95%

Yield

67%

95%

Yield

53.43

184.96

100.00

56.40

187.81

100.00

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.

8.5

Software Projects 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.

8.5 Software Projects

181

Changes in position calculation accuracy with range measurement inaccuracy two satellites and different numbers of range measurements for 67% 10,000

Position calculation accuracy (meters) log scale

1,000 2 Range 3 Range

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 3 Range

100

4 Range 10

1 0

100

200

300

400

500

600

700

800

900

1,000

Range measurement inaccuracy (meters)

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

Position calculation accuracy (meters) log scale

2 Range 100

3 Range 4 Range

10

1 0

100

200

300

400

500

600

700

800

900

1,000

Range measurement inaccuracy (meters)

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

Range measurement inaccuracy (meters)

Figure 8.5 Change in position calculation accuracy for three satellites and different numbers of range measurements.

References [1] [2]

[3]

[4]

Junedi, D., and W. Ren, “Integration of GPS and GSM Signals for Location,” Master’s Thesis 20, University of New South Wales, SNAP Group, 2004. 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. Ju-Yong, D., M. Rabinowitz, and P. Enge, “Performance of Hybrid Positioning System Combining GPS and Television Signals,” 2006 IEEE/ION Proceedings of Position, Location, and Navigation Symposium, 2006. Japan Aerospace Exploration Agency, Quasi-Zenith Satellite System Navigation Service, Interface Specification for QZSS (IS-QZSS), 2009.

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 improving 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 positioning 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 satellites 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 coordinates 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 vicinity 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 kilometers and consists of nitrogen, oxygen, and water vapor. As the GPS signal propagates 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 various 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 network 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 ionospheric 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

9.2

185

Location Integrity In the previous section, improvements to the accuracy of the location were discussed. 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 handset) 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 fraudulently gains access to a broadcast that is restricted to a particular set of geographically 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 location 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 intermediary 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 network), 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

186

Other Server-Side Improvements and Controls

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 location 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 validated against the RTT measurements that are sourced from within the trusted network. 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 performs 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 assurance 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 measurements 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 performed, 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 measurements (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 mechanism to detect spoofed measurements is outlined. This is in contrast to most spoof-

9.2 Location Integrity

187

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 satellite 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 velocity 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 simple 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 ⎝ c ⎠

(9.1)

188

Other Server-Side Improvements and Controls

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 rs − r$r

9.2.2.2

(9.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

9.3 Software Projects

189

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 114.16

9

25,122,525

54.88

709.62

69.15

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 measurements (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 considered as a baseline for spoof detection. For example, if a handset that reports 8 satellites 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 calculation result (which happened to be incorrect).

9.3

Software Projects 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.

190

Other Server-Side Improvements and Controls 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 Toolbox, 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 Institute of Aeronautics and Astronautics, Inc., 1996. [5] GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User Interfaces, 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 Astronautics, 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, Turkey, 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 Regarding Satellite-Based Vessel Monitoring Systems,” Official Journal of the European Union, L 333/17, 20.12.2003, December 18, 2003.

9.3 Software Projects

191

[12] Montgomery, P. Y., et al., “Receiver-Autonomous Spoofing Detection: Experimental Results of a Multi-Antenna Receiver Defense Against a Portable Civil GPS Spoofer,” Proceedings of the 2009 International Technical Meeting of the Institute of Navigation, Anaheim, 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 provide 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 signal, and they use their own time reference. There will be a large number of navigation-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 calculate a location, such as urban canyons. This chapter generalizes the previous work in the book to A-GNSS and also discusses 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 accurately 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 stations and a master control station. The monitoring stations provide data to the master 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 operational 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 frequency 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 territory 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 transmitting 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 Service (OS) uses the Galileo F/NAV navigation message format. The message structure 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 equations 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 publicly 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 mountains. This will increase the availability (yield) for performing a satellite-based position 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 transmitted 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 provides 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 stations located on each coast of the United States collect data from the network of reference 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 information. The localized ionospheric delay information is the component that significantly 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 satellites 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 carrier frequency of GPS L1. The WAAS transmits data at 250 bits per second and consists of different messages 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

10.1.7

197

Others

There are several other augmentations and regional satellite systems that are in various stages of design and deployment and they are discussed briefly in this section. The Indian Regional Navigational Satellite System (IRNSS) is a regional navigation 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 supported 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 information 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 process 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 Positioning 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 position 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 handset-assisted mode. The GANSS Multi-frequency Measurement Request Element is a flag that requests the handset the measurement for more than one signal, for example, 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 assistance 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 Common Assistance Data and the GANSS Generic Assistance Data. The common assistance 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 common 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 ganssRefLocation GANSSRefLocation ganssIonosphericModel GANSSIonosphericModel ... , ganssAddIonosphericModel GANSSAddIonosphericModel

OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL,

10.2 Protocols ganssEarthOrientParam

199 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 location 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) ganssTimeModel SeqOfGANSSTimeModel ganssDiffCorrections GANSSDiffCorrections ganssNavigationModel GANSSNavModel ganssRealTimeIntegrity GANSSRealTimeIntegrity ganssDataBitAssist GANSSDataBitAssist ganssRefMeasurementAssist GANSSRefMeasurementAssist ganssAlmanacModel GANSSAlmanacModel ganssUTCModel GANSSUTCModel ganssEphemerisExtension GANSSEphemerisExtension ganssEphemerisExtCheck GANSSEphemerisExtensionCheck ... , sbasID INTEGER (0..7) ganssAddUTCModel GANSSAddUTCModel ganssAuxiliaryInfo GANSSAuxiliaryInformation }

OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, 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 particular 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 considered 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 broadcast 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 assistance based on the reference location that normally comes from the cell location. This reference location may be refined based on measurements from the cellular network, 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 navigation 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 Communications 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 realized 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 information 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 assistance 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 determination 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 Information Error will include list of GANSS assistance data types required. Other fields related to GANSS are for the handset to report the calculated location (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

10.3

Assisted-GNSS

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 significant factor in a position fix is the delay that is introduced into the range measurements 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, Signal 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. [6] Japan Aerospace Exploration Agency, Quasi-Zenith Satellite System Navigation Service, Interface Specification for QZSS (IS-QZSS), 2009. [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. [9] 3GPP TS 44.031 Third Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (MS)—Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP), 2009. [10] 3GPP TS 23.032 Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Universal Geographical Area Description (GAD), 2008. [11] GPS Navstar Joint Program Office, Navstar GPS Space Segment/Navigation User Interfaces, Interface Specification, IS-GPS-200, Navstar GPS Joint Program Office, El Segundo, 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 representation 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 messages. 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 Service 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 Service, 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 3GPP TS 43.059 Third Generation Partnership Project; Technical Specification 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 Program 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 Positioning Service Performance Standard, Fourth Edition, September 2008 This document defines the minimum performance commitments of the GPS system. 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 Positioning 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 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. 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. 3GPP TS 25.453 Third Generation Partnership Project; Technical Specification 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 measurements between the SAS and the UE in a UMTS network. It contains a functionality 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 interface between the SS and the US of the QZSS.

206

Appendix A RRC

Radio Resource Control 3GPP TS 25.331 Third Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Resource Control (RRC); Protocol Specification RRC protocol handles the control plane signaling between the UE and other elements 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 3GPP TS 44.031 Third Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (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 network. 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 3GPP TS 25.305 Third Generation Partnership Project; Technical Specification 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 written using the JUnit unit testing framework.

207

208

Appendix B

Figure B.1

Table B.1

Project structure.

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 observation 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 benchmark 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 accompanying this book. NavMessage -satellites[] : SatelliteNavMessage +getSatellite(in prn : int) : SatelliteNavMessage +newData(in prn : int, in data : byte[]) 1 SatelliteNavMessage

0..*

Subframe

-prn : int -subframes[] : Subframe +newData(in data : Subframe) +getSubframe() : Subframe +getPage() : SatNavMessagePage

-data : byte[] 1

0..3

+newData(in data : byte[]) +getSubframeId() : int +getPageId() : int

1 0..25 Subframe

SatNavMessagePage -pageNumber : int -subframes[] : Subframe +getSubFrame() : Subframe +newData(in data : Subframe)

-data : byte[] 1

0..2

+newData(in data : byte[]) +getSubframeId() : int +getPageId() : int

SatelliteInfoHandler -sateInfoCollection

1 0..*

Utc -utcParameters +getUtcTime(in gpsTime : double) : double

SatelliteInformation -satellites[] : Satellite +getSatellite() : Satellite IonosphereModel 1 0..*

-ionosphereParameters +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

Figure C.2

MeasurePositionRequest

MeasurePositionResponse

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

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

RRLP object model.

GpsMeasurementCollection -gpsMeasurementCollection TroposphereModel 1 +getTroposphereDelay(in elevation : double) : double

0..* GpsMeasurement -satMeasurementCollection

HopfieldTroposphereModel 1 +getTroposphereDelay(in elevation : double) : double 0..* SatMeasurement

GpsTime

RangeMeasurementSet -rangeMeasurements

1 0..* RangeMeasurement -transmiiterLocation : Wgs84Coordinate -range : double

Figure C.3

GPS object model.

Appendix C

213 Rinex

RinexNavFile

Figure C.4

RINEX object model.

RinexObsFile

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 further 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 sending the acquisition assistance and real-time integrity GPS assistance data types. RRLP 0000 001-------0-------000-------0 20 0001 0-------0-------0-------1-------0-------0-------00 10 0002 1-------0000001 81 meters 0003 01-------101-------1--

------0-------0 6C 0004 0-------0-------0-------0-------0-------1-------1-

Reference Number: 1 Extension: false Measure Position Request Extension: false Options: Reference Assist Data: false MSR Assist Data: false System Info Assist Data: false GPS Assist Data: true Extension Container: false Position Instructions Options: EnvironmentCharacter: false Method Type Choice: MS Assisted Options: Accuracy: true Accuracy Uncertainty: 1.0000000000 Position Method: GPS Measurement Response Time: MeasureResponseTime: 5 Use Multiple Sets: One set GPS Assistance Data: Control Header: Options: Reference Time: false Reference Location: false DGPS Corrections: false Navigation Model: false Ionospheric Model: false UTC Model: false Almanac: false Acquis Assist: true Real Time Integrity: true

215

216

Appendix D

-------0 06 0005 01100010 62 0006 01110100 74 0007 1100100-------1 C9 0008 011-----

0009 0010 0011 0012 0013 0014 0015

0016 0017 0018 0019 0020 0021

0022

---1-------1-------010 001-------00111 0100100-------1 01100-------100 10111011 00-------00011-------1 1-------0010-------001 01-------000-------1-------1-------0 10101-------001 01111100 1-------100110-------1 00-------111000 0110-------0110 1-------11-------0010-------0 0101-------000-

-------1 0023 1-------001110-------0 0024 01100111 0025 110-------11011 0026 0-------100-------0101 0027 100100-------01 0028 000-------11-------001 0029 0-------00010-------00 0030 0-------

Acquisition Assistance: Time Relation: Options: GSM Time: false GPS Tow 23B: 3226212 Number of Elements: 12 Acquisition Element: Options: Additional Doppler: true Additional Angle: true

7A Satellite ID: 17 27 Doppler0: -1116 49 64 BB

Doppler1: 44 Doppler uncertainty: 4 Code phase: 748 Int code phase: 3

07 GPS bit number: 3 Code phase search window: 2 91 azimuth: 5 elevation: 0 Acquisition Element: Options: Additional Doppler: true Additional Angle: true 46 Satellite ID: 21 A9 7C Doppler0: -1287 Doppler1: 38 CD Doppler uncertainty: 4 38 Code phase: 902 66 Int code phase: 13 GPS bit number: 3 Code phase search window: 2 E4

51

azimuth: 5 elevation: 0 Acquisition Element: Options: Additional Doppler: true Additional Angle: true Satellite ID: 14

9C 67 Doppler0: -1218 DB Doppler1: 54 Doppler uncertainty: 4 45 Code phase: 356 91 Int code phase: 8 GPS bit number: 3 19 Code phase search window: 2 azimuth: 2 08 elevation: 0

D.2 Measure Position Response (GPS Measurements)

-1-------1-------01010 6A

217 Acquisition Element: Options: Additional Doppler: true Additional Angle: true

[SNIP] – Various satellites removed from Acquisition Assistance for compactness Sequence of Bad Satellites:

0096 0097 0098

0099

D.2

---0100-------0 01011-------011 110-------01010 0-------000101-------0 01101---

Number of Elements: 5 08 Satellite ID: 11 5B Satellite ID: 30 CA Satellite ID: 20 Satellite ID: 5 0A Satellite ID: 13

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. 0000 001-------0-------001-------0 22 0001 0-------0-------0-------0-------1-------0-------0-

-------0 08 0002 0-------0-------100010 22 0003 00000010 02 0004 10111101 BD 0005 00-------1011-------01 0006 1100-------1001 0007 11-------001111 0008 00111111 0009 00-------110111 0010 1000-------0111 0011 0011111-

RRLP Reference Number: 1 Extension: false Measure Position Response. Extension: false Options: Multiple Sets: false Reference Identity: false OTD Measurement Information: false Location Information: false GPS Measurement Information: true Location Error: false Extension Container: false GPS Measurement Information GPS Measurement Set List: Sequence size: 1 Options: Reference Frame: false GPS Time of Week:

GPS Tow 24B: 8915700 GPS Measurement List: sequence size (post8_9_0): 12 GPS Measurement Element:

2D Satellite ID: 28 C9 Carrier Noise Ratio: 39 CF 3F Doppler: -17156 37 Whole Chips: 888 87 Fractional Chips: 927 Multi Path Indicator

218

Appendix D -------0 3E 0012 0-------000000-------0 0013 00101-------101 0014 001-------00110 0015 11110010 0016 000-------10111 0017 00111-------000 0018 10111011

00 Satellite ID: 5 2D Carrier Noise Ratio: 41 26 F2 Doppler: -18544 17 Whole Chips: 743 38 BB

0019 00-------000000 00 0020 011001-------10 0021 1011-------0100 0022 11010010 0023 1010-------1110 0024 010110-------00 0025 01110111 0026 0-------

Not Measured Pseudo Range RMS Error: 0 GPS Measurement Element:

Fractional Chips: 187 Multi Path Indicator Not Measured Pseudo Range RMS Error: 0 GPS Measurement Element: Satellite ID: 25

66 Carrier Noise Ratio: 43 B4 D2 Doppler: -13014 AE Whole Chips: 918 58 77

-00-------00000 00 0027 0-------

Fractional Chips: 238 Multi Path Indicator Not Measured 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 sending 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 Reference Number: 1 Extension: false Assistance Data 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 ----1--More Assistance Data to be Sent: true -----0-Extension Container: false GPS Assistance Data: Control Header: Options: ------1Reference Time: true -------1 1B Reference Location: true 0002 0------DGPS Corrections: false -1-----Navigation Model: true --0----Ionospheric Model: false 0000 001-------0-------010-------0 24

D.3 Assistance Data (Reference Location and Navigation Model) ---0-------0-------0-------0-

-------0 40 0003 1-------

0004 0005 0006 0007

-0100001 11010011 01011100 01001001 11------

219

UTC Model: false Almanac: false Acquis Assist: false Real Time Integrity: false Reference Time: Options: GSM Time: false GPS TOW Assist: true GPS Time:

A1 D3 5C 49

--1011-------01 ED 0008 0001-------0000 10 0009 01000111 47 0010 11-------1-------0-------00-------01 E1 0011 0101-------0000 50 0012 01000111 47 0013 11-------1-------0-------00-------00 E0 0014 1110-------0000 E0 0015 01000111 47 0016 11-------1-------0-------00--

GPS Tow 23B: 2216796 GPS Week: 295 GPS TOW Assist: Sequence size: 12 GPS TOW Assist: Satellite ID: 17

TLM Word: 287 Anti Spoof: true Alert: false TLM Reserved Bits: 0 GPS TOW Assist: Satellite ID: 21

TLM Word: 287 Anti Spoof: true Alert: false TLM Reserved Bits: 0 GPS TOW Assist: Satellite ID: 14

TLM Word: 287 Anti Spoof: true Alert: false TLM Reserved Bits: 0 GPS TOW Assist:

[SNIP] – Various satellites removed from GPS TOW Assist for compactness Reference Location: ------01 E1 0044 101-------1001altitude and uncertainty Ellipsoid -------0 B2 0045 000-----

Length: 13 Geographic Shape Type of Shape: Ellipsoid point with

Point: ---10110 16 0046 00011110 1E 0047 00001000 08 0048 010----34.409899 degrees south ---01101 4D 0049 01101001 69 0050 01011000 58 0051 100----150.879471 degrees east ---00000 80 0052 00000100 04 0053 000----the ellipsoid ---0----

Latitude: 34.409888 to

Longitude: 150.879450 to

Altitude: 32 to 33 meters above

Major axis uncertainty: ----0101 05

220

Appendix D 0054 010----meters ---0----

Uncertainty: 537.636992

Minor axis uncertainty: ----0101 0055 010----meters ---00000 0056 000-------0-------0110 0057 000----meters ---0-------1011 0058 010-----

45 Uncertainty: 537.636992 40 Major axis angle: 0 06 Uncertainty Altitude: 102.217030

0B

---0000-------0 40 0059 10001-------0-------00 88 ephemeris and clock corrections: 0060 01-------0000-------00 40 0061 0000-------0101 05 0062 111111-------0-------0 FC 0063 00000000 00 0064 00000000 00 0065 000000-------00 00 0066 00000000 00 0067 00000000 00 0068 000000-------00 00 0069 00000000 00 0070 00000000 00 0071 000000-------00 00 0072 00000000 00 0073 000000-------01 01 0074 101010-------00 A8 0075 10011010 9A 0076 101100-------10 B2 0077 000000-------01 01 0078 11111111 FF 0079 100000-------01 81 0080 10111100 BC 0081 00100101 25 0082 1010-------1000 A8 0083 11001000 C8 0084 1100-------1010 CA 0085 11101101 ED 0086 0100-------1100 4C 0087 01101001 69 0088 10100110 A6 0089 00101001 29 0090 1011----

Confidence: 90 Navigation Model: Number of Elements: 1 Navigation Model status: Satellite ID: 17 Satellite status: Extension: false New Satellite and Model: Uncompresssed satellite Code on L2: 1 URA: 0 SV health: 0 IODC: 383 L2Pflag: 0 Sub frame reserved:

Reserved 1: 0

Reserved 2: 0

Reserved 3: 0

Reserved 4: 0 Tgd: -22

Toc: 9900 AF2: 0

AF1: -32

AF0: 1609514

CRS: 3212

Delta N: 11988

M0: 1184522907

D.4 Measure Position Response (Location) ----1000 0091 10110001 0092 0011-------0000 0093 00101101 0094 10011000 0095 11010110 0096 1011-------1001 0097 00011111 0098 1000-------1010 0099 00010000 0100 11011101 0101 10000101 0102 1010-------0010 0103 01101010 0104 1100-------0-------111 0105 11-------011111 0106 11111000 0107 01-------000010 0108 01111111 0109 11111100 0110 01000100 0111 11-------100000 0112 00010001 0113 11-------101001 0114 11001110 0115 00111000 0116 11110110 0117 10-------100110 0118 10111111 0119 11-------000011 0120 01101001 0121 01100100 0122 11001001 0123 11-------011111 0124 11101010 0125 00110001 0126 01-------100000 0127 00111101

B8 B1 CUC: 2835 30 2D 98 D6 E: 47811947 B9 1F CUS: 4600 8A 10 DD 85 A power half: 2702039130 A2 6A TOE: 9900 Fit Flag: 0 C7 AODA: 31 DF F8 CIC: -31 42 7F FC 44 Omega A0: -1979715309 E0 11 CIS: 71 E9 CE 38 F6 IO: 658039770 A6 BF CRC: 6911 C3 69 64 C9 W: -1918528729 DF EA 31 Omega ADot: -22331 60 3D

0128 1-------

D.4

221

IDot: 61 More Assistance Data To Be Sent: More assistance data to be sent.

Measure Position Response (Location) This is a Measure Position Response that is part of an MS-Based location. RRLP 0000 001-------0-------001-------0 22 0001 0-------0-------0-------1-------0---

Reference Number: 1 Extension: false Measure Position Response. Extension: false Options: Multiple Sets: false Reference Identity: false OTD Measurement Information: false Location Information: true GPS Measurement Information: false

222

Appendix D -----0-------0-

0002 0003 0004 0005 0006

-------1 11111111 11111111 10000100 01110010 01000000

0007 1-------01101--

11 ff ff 84 72 40

Location Error: false Extension Container: false Location Information Options: GPS Time Of Week: true Reference Frame Number: 65535

GPS Time Of Week: 8680000 Fix Type: Three Dimensional Fix. Position Estimate: 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 ------0Major axis uncertainty: -------0 a8 0017 001111-Uncertainty: 31.7724816942 meters ------0Minor 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 A-GNSS A-GPS ALI ASN.1 BIPM bps BPSK C/A CDMA CRF CRS CS DEM D-GPS DN DoD DOP DTD DTV E-911 ECEF ECMWF EGNOS EOTD EP ESME ESP EU FCC FDMA FOC GAD

Third Generation Partnership Project Assisted-GNSS Assisted-GPS automatic location identification Abstract Syntax Notation 1 International Bureau of Weights and Measures bits per second biphase shift key coarse/acquisition code division multiple access coordinate reference frame coordinate reference system control segment digital elevation model Differential GPS day number Department of Defense dilution of precision document type definition digital TV ranging measurements Enhanced 9-1-1 earth-centered earth-fixed European Centre for Medium-Range Weather Forecasts European Geostationary Navigation Overlay Service enhanced observed time difference elementary procedure Emergency Services Messaging Entity Emergency Services Protocol European Union Federal Communications Commission frequency division multiple access full operational capability Geographical Area Description specification

223

224

List of Acronyms and Abbreviations

GAGAN GANSS GBAS GEO GERAN GLONASS GNSS GPS GPS IS GPS SPS PS GPS SPS SS GRAS GRIP GRN GRS GSM GST HDOP HEO HOW HP HTML HTTP Hz ICG ID IDE IE IETF IGS IGU ILP IOC IODC IODE IP IRNSS ISDN ITRS JGS

GPS Aided Geo Augmentation Navigation Galileo and Additional Navigation Satellite Systems Ground Based Augmentation System geostationary satellite GSM/EDGE Radio Access Network GLObal’naya NAvigatsionnaya Sputnikovaya Sistema Global Satellite Navigation System Global Positioning System GPS Interface Specification GPS-IS-200 GPS SPS Performance Specification GPS SPS Signal Specification Ground-Based Regional Augmentation System GNSS Reference Interface Protocol global reference network GNSS reference server Global System for Mobile Communications Galileo System Time horizontal dilution of precision highly inclined elliptical orbit handover word high precision Hypertext Markup Language Hypertext Transfer Protocol hertz International Committee on Global Navigation Satellite Systems identifier integrated development environment information element Internet Engineering Task Force International GNSS Service IGS ultra-rapid products Intermediate Location Protocol initial operational capability issue of data, clock issue of data, ephemeris Internet Protocol Indian Regional Navigational Satellite System International Subscriber Directory Number International Terrestrial Reference System Japan Satellite Navigation Geodetic System

List of Acronyms and Abbreviations

JPO L1 L2 L2C LAAS LBA LCS LIS LS LSB MCS MLC MPC MS MSAS MSB MSID MSISDN NA NAES NATO NAV NENA NICT NLOS NSS NTP OMA OO OS OSGRS OTDOA PCAP PCF PDDM PER PPS PRN PSAP

225

Joint Program Office Link 1—GPS L1 Frequency Link 2—GPS L2 Frequency L2 Civil Local Area Augmentation System location-based application location services location information server location server least significant bit master control station mobile location center mobile positioning center mobile station Multifunctional Satellite Augmentation System most significant bit mobile station identifier Mobile Station International ISDN North America North American Emergency Services North Atlantic Treaty Organization Navigation Message National Emergency Number Association National Institute of Information and Communications Technology nonline of sight Navigation Satellite System Network Time Protocol Open Mobile Alliance object oriented Open Service Open Source GNSS Reference Server observed time difference of arrival position calculation application part position calculation function Position Determination Service Standard for Dual Mode Spread Spectrum Systems packed encoding rules Precise Positioning Service pseudorandom noise (code) public safety answering point

226

List of Acronyms and Abbreviations

QoP QoS QZS QZSS RAN RF RHCP RINEX RNC RNSS RRC RRLP RTI RTT Rx SAS SBAS SET SLC SLIA SLIR SLP SMLC SOAP SOPAC SP SPC SPP SPS SPS PS SS SUPL TA TEC TLM TLS TOA TOF TOT TOW TPS

quality of position quality of service Quasi-Zenith Satellite Quazi-Zenith Satellite System radio access network radio frequency right hand circularly polarized Receiver Independent Exchange Format radio network controller Regional Navigation Satellite System radio resource control Radio Resource Location Protocol real-time integrity round-trip timing receiver stand-alone SMLC Satellite-Based Augmentation System SUPL enabled terminal SUPL location center standard location immediate answer standard location immediate request SUPL location platform serving mobile location center Simple Object Access Protocol Scripps Orbit and Permanent Array Center standard precision SUPL positioning center single point positioning Standard Positioning Service Standard Positioning Service Performance Standard space segment secure user plane location timing advance total electron content telemetry transport layer security time of arrival time of flight time of transmission time of week transactions per second

List of Acronyms and Abbreviations

TTFF Tx UE ULP UML UMTS UNSW US USAF USNO UTC U-TDOA UTRAN VoIP VPN WAAS WARN WGS 84 WN WSP XML

227

time to first fix transmitter user equipment UserPlane Location Protocol Unified Modeling Language Universal Mobile Telecommunications System University of New South Wales user segment United States Air Force U.S. Naval Observatory Coordinated Universal Time uplink time difference of arrival UMTS Terrestrial Radio Access Network Voice over Internet Protocol virtual private network Wide Area Augmentation System wide area reference network World Geodetic System 1984 week number Wireless Session Protocol Extensible Markup Language

List of Symbols t tSV tSV H a b c D f f h rr rs vr vs & Ω e

the time that the handset made the measurement the time that the satellite transmitted the signal satellite clock offset the geometry matrix pseudorange semimajor axis of the ellipsoid semiminor axis of the ellipsoid speed of light Doppler frequency in hertz flattening of the earth (for WGS 84) height location of the receiver in WGS 84 ECEF coordinates location of the satellite in WGS 84 ECEF coordinates velocity of the receiver velocity of the satellite Earth’s rotation rate 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 connects 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 calculate 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 frequency. 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 locaaltitude and uncertainty tion. Latitude and longitude are points on the surface of ellipse 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. The uncertainty ellipse is provided at a given confidence level.

231

232

Glossary

Ellipsoidal (or geodetic) A system with the origin at a fixed point and with locacoordinate 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 computer, 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 position calculation. 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 location calculation. The QoS/QoP define the requirements for the accuracy and the allowed time for the LS to perform 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

Spoofing UE Uncertainty

UTRAN

233

The act of providing incorrect measurements to a PCF in order to forge the location. The name for the A-GNSS enabled handset in a UMTS network. The measure of the error in the location calculation calculated as part of the location fix. For satellite-based location calculations, the uncertainty is normally calculated 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. 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 assistance. 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 applications. 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 Accuracy, 5, 10–11, 58–59, 117, 122–123 Acquisition, 35, 54, 76, 77 Acquisition assistance, 9, 81–86, 87 A-GNSS, 1, 5, 6, 9–10, 192–197 A-GPS, 1, 63–88 Almanac, 9, 44, 54, 86 ASN.1, 91, 95–104, 117 Assistance data, 1, 6–8, 9, 63–65, 76–88, 92, 197, 198 Assistance data size, 87 Augmentations, 3, 193, 195, 197

C C/A code, 10, 36, 37, 38, 39, 82, 86, 197 CDMA, 2, 3, 9, 72, 91, 194, 195 CNAV, 37, 38–39, 96 Code coverage, 30–31 Code phase, 8, 41, 81–83, 92, 121, 123 Compass, 2, 195 Confidence, 10, 56–58, 75, 143 Configuration management, 32 Coordinate reference frame, 17, 132, 194

D Differential-GPS (DGPS), 9, 59–60, 69, 86, 87 Dilution of precision (DOP), 59, 123, 146, 202 Doppler, 81–84, 121, 146, 187–188

E E2 interface, 65, 73, 75, 91 E9-1-1, 11, 92 ECEF coordinates, 19–21, 23, 42, 73, 83, 96 EGNOS, 3, 196, 198 Emergency Services Protocol, 75 Emma, 30 Ephemeris, 4, 6, 39, 40, 42, 49, 51, 65, 79, 126 ESME, 64, 65, 72, 75, 91

G GAD specification, 10, 75, 79, 87, 103, 199 GAGAN, 3, 97, 197, 198 Galileo, 2, 10, 92, 96, 194–195, 197, 199, 200

GBAS, 3 Geodetic coordinates, 20–21, 23–27 Geometric range correction, 126, 132–133 Geometry matrix (H), 125, 139, 140, 147, 163 GERAN, 64, 90, 92, 185 GLONASS, 2, 50, 97, 194, 196, 198, 199 GMLC, 9, 65, 72, 74, 91, 92 GNSS Reference Server (GRS), 6, 7, 63, 65–70, 77, 79, 86, 200 GPS L1, 37, 38 GPS L2, 36–37, 38–39, 67, 92 GPS measurement, 5, 45, 92, 98, 114, 122, 127 GPS time, 39 GRIP, 70, 71 GSM, 6, 78, 91, 93, 168

H Handover word (HOW), 40, 77, 78 Handset, 2–5, 7, 54, 64, 72, 76, 92 Handset clock error, 5, 124–125, 134, 140, 143, 149, 163, 169 Handset-assisted, 1, 76, 81, 92, 121, 153, 167 188 Handset-based, 1, 76. 92, 185, 198 Hybrid, 150, 167

I Integrated development environment (IDE), 13 Integrated time recovery, 163 International GNSS Service (IGS), 53, 183 IODE, 42, 43, 65, 98 Ionosphere, 79, 136, 184 IRNSS, 197 Iterative time recovery, 156

J Java, 12–14, 22, 23–32 Javadoc, 13, 14, 24, 107 JUnit, 23, 28, 110,

L Least squares, 57, 126, 128, 138–143, 149, 156, 163, 165, 168, 188

237

238

Location information server (LIS), 9, 10, 72, 91 Location integrity, 126, 185–189 Location server, 62, 64, 71–73 Location-based application (LBA), 8, 64–65, 73–75, 185, 187 Location-based services, 11

M Master Control Station, 35, 41, 196 Maven, 13, 22, 23, 24, 28, 30, 110 Measurement errors, 5, 45, 56, 58–59, 143, 183–185 Mobile Location Center (MLC), 9, 11, 65, 72, 73, 74, 91 Mobile Location Protocol (MLP), 64, 65, 73, 74, 92, 185 Mobile Positioning Center (MPC), 65, 74, 91 Multipath error (NLOS), 5, 8, 58, 59, 122, 135

N NAES, 65, 73, 75, 90 NAV message, 4, 9, 37, 38, 39–51, 76, 78, 98, 124, 127, 132, 187, 195 Navigation model, 8, 9, 49, 63, 71, 79, 80, 87, 96, 200

O OSGRS, 70–71

P PCAP, 9, 64, 72, 77, 78, 91, 114–117, 168, 197 Performance testing, 29 Position calculation, 121–150 PRN, 4, 37, 38, 40, 54, 77, 78 Protocol, 7, 9, 64, 71, 91, 92, 197 Pseudomeasurement, 134 Pseudorange, 54, 121, 123, 124, 125, 128, 130, 193 Public Safety Answering Point (PSAP), 11, 65, 75

Q Quality of Position (QoP), 65, 74, 116, 117 QZSS, 96, 170, 195–196, 198, 199, 201

R Radio Access Network (RAN), 72, 76, 87 Ranging signal, 2, 3, 35, 36, 38, 121 Real-time integrity, 8, 9, 71, 77, 86, 87, 96, 130

Index

Reference location, 8, 9, 79, 87, 94, 96, 114, 199 Reference time, 8, 9, 64, 71, 77–78, 87, 94, 96, 99, 153, 193 Residuals, 145, 146, 154, 156, 188 RINEX file format, 50–51, 53, 65, 69, 71, 127, 128, 133, 160 RRC, 9, 10, 64, 72, 91, 92, 93, 114, 197 RRLP, 9, 10, 64, 72, 78, 91, 92–114, 197, 198–201 RRLP Measure position request, 93–96, 98, 99, 100, 101, 102, 104, 105 RRLP Measure position response, 93, 95, 98, 100 RTT, 6, 115, 116, 168, 173, 177, 179, 185, 200

S SAS, 9, 64, 72, 91, 114, 115, 168 Satellite clock correction, 4, 41, 59, 65, 126, 130–132, 195 Satellite constellation, 2, 3, 35, 39, 71, 86, 194 Satellite elevation, 73, 83, 123, 126, 134–136, 141 Satellite group delay, 41, 80, 126, 132 Satellite health, 4, 38, 41, 65, 126, 129–130 Satellite location, 53, 126, 131, 136 Satellite orbit, 2, 3, 4, 36, 41, 80, 183 SBAS, 3, 96, 87, 197, 198, 199, 201 Serving cell, 5, 8, 9, 64, 72, 77, 79, 87, 116 SLP, 9, 10, 72, 76, 91, 92, 146, 197 SMLC, 9, 64, 72, 91, 92, 93, 94, 95 Socket, 110–114 SP3, file format 53 Spoofing, 186–189 SSR, 145, 154, 156, 159 Standards, 7, 9–10, 64, 72, 91, 92 Subframe, 4, 39–46, 47–48, 64, 69, 78 SUPL, 9, 10, 72, 91, 92, 93, 188, 189

T Telemetry word (TLM), 40, 77, 78 Time recovery, 77, 153–166 Time server (NTP), 6, 7, 64, 73, 78, 153 Timing Advance (TA), 6, 168, 173, 177 Troposphere, 5, 58, 126, 137–138, 184, 188 TTFF, 1, 4, 5, 63, 91

U UMTS, 6, 9, 91, 168, 178, Uncertainty, 8, 10, 55, 56–58, 59, 64, 74, 79, 82, 103, 143–145

Index

Unit test, 22, 23, 27–28, 29, 30, 31, 47, 52, 110 Userplane Location Protocol (ULP), 10, 76, 93 UTC model, 4, 8, 9, 39, 44, 71, 78, 80–81, 87, 96, 153, 201 UTDOA, 6, 173, 179 UTRAN, 64, 72, 78, 91, 114, 168, 173, 177

239

W WAAS, 3, 97, 196, 198 Weight matrix (W), 126, 138, 141, 142 WGS, 84 10, 17, 18–21, 23–27, 42, 67, 73, 127

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: [email protected]

e-mail: [email protected]

Find us on the World Wide Web at: www.artechhouse.com