The University of New South Wales

Performance of Location Determination Techniques in Weak Signal Environments employing Reference Server, Caster, Cellular and Sensor Networks and Multiple Assisted Global Navigation Satellite Systems

Ali Hassan Sarwar

A thesis submitted for the Degree of Doctor of Philosophy

School of Surveying & Geospatial Engineering

2013

Performance of Location Determination Techniques in Weak Signal Environments employing Reference Server, Caster, Cellular and Sensor Networks and Multiple Assisted Global Navigation Satellite Systems

Ali Hassan Sarwar

B.E. University of Engineering and Technology (2003) M.E., University of New South Wales (2005) P.G.D., Macquarie University (2006)

A thesis submitted for the Degree of Doctor of Philosophy

The University of New South Wales

School of Surveying & Geospatial Engineering

2013

THE UNIVERSITY OF NEW SOUTH WALES Thesis/Dissertation Sheet

Surname or Family name: Sarwar

First name: Ali Other name/s: Hassan

Abbreviation for degree as given in the University calendar: Ph.D.

School: School of Surveying and Geospatial Engineering Faculty: Engineering

Title: Performance of Location Determination Techniques in Weak Signal Environments employing Reference Server, Caster, Cellular and Sensor Networks and Multiple Assisted Global Navigation Satellite Systems

Abstract Global Navigation Satellite System’s (GNSS) known shortcomings in difficult radio-environments – signal obstructions and jamming vulnerability – could pose significant risks in critical location based services (LBS) applications. Off-the-shelf systems such as ‘Spot Satellite Messenger’ are not compliant for E911 and other emergency response requirements. Despite considerable research and engineering efforts, few techniques have demonstrated promising results. Multiple sensor-based techniques and systems based on Assisted-GNSS (AGNSS) have been proposed in order to improve the performance of stand-alone GNSS. Improved time-to-first-fix (TTFF), system availability and positioning accuracy are the notable performance gains. Many AGNSS techniques employ proprietary protocols which limit further academic research or pre-deployment testing. The Open Source GNSS Reference Server (OSGRS) – on the other hand uses a Hyper Text Transfer Protocol (HTTP) based stateless GNSS Reference Interface Protocol (GRIP). For the research described in this thesis, a hardware based GNSS receiver was first used to acquire assistance data. Subsequent versions of OSGRS have seen alternative acquisition approaches using numerous GNSS Casters available over Internet Protocol. A variety of data formats are available, hence OSGRSv2 is capable of Multiple Assisted GNSS (MAGNSS). Client and server integration, testing and performance benchmarking against competing technologies appeared promising. The system tracked the highest number of satellites, availability and higher accuracy with low TTFF values. Three configurations of multi- GNSS assistance servers allow flexible operation independent of the presence of Virtual Private Networks (VPNs) – a limitation of OSGRSv1. Iteratively, the server has been augmented with Long Term Evolution (LTE) Positioning Protocol (LPP) and the associated extensions (LPPe) to develop the third generation OSGRSv3. Interconnection of multiple networks is provided through Internet Protocol (IP) data control gateways for user-specific information exchange. Assistance Model Portfolio of OSGRSv3 has been expanded with the development of mobile communications interworking criteria. A real network implementation in a controlled mobile network laboratory has been configured. The architecture exploits LTE Radio Access Network (RAN), Transmission, Core and GNSS elements to test the performance of the system. Performance graphs demonstrate that Radio Resource Location Protocol (RRLP) based system lowered the TTFF and improved the satellite availability and positioning accuracy over OSGRSv1 or OSGRSv2. Options of selectively choosing which GNSS to use is managed through a source selector switch. Presence of basic networking infrastructure has been a critical limitation of Multiple Assisted GNSS systems. A low infrastructure strategy to augment GNSS with adhoc Wireless Sensor Nodes (WSN) has been presented. Pre-programmed fixed sensor nodes are deployed in the test area where a rover sensor node is connected to a GNSS-capable mobile device. Based on the received signal strength, signature indices are generated and autonomous proximity calculations of the rover are performed. The localization information is transferred to GNSS via assistance messages. Experiments were conducted to simulate a reduction in navigation search space, competitive TTFF and improved availability and accuracy. Link quality indicators can effectively provide pre-processed frequency offset, range and coordinate assistance in the absence of IP network, in building coverage (IBC) repeaters or GNSS. Stand-alone sensors based localization demonstrated cm-level accuracy, response sensitivity and reliability. System robustness against partial node malfunction in instances of clocking, time syncing, thermal noise, coordinate decoding and processing issues, was observed. Such errors can arbitrarily eventuate in erroneous localization. Reference Server, Caster and Sensor Networks and MAGNSS can provide cost effective alternatives for generic and specific AGNSS localization applications.

The contributions of this thesis can be summarized as follows:

a. GPS, GNSS, AGNSS, RNSS, SBAS and alternative positioning technologies have been reviewed. Several LBS variants have been investigated and shortcomings listed. Alternative navigation, communication and logging techniques have been suggested to BWRS, NSW Police and the VRA. SPOT GNSS Messenger has been performance evaluated. Architecture for a Multiple Sensor based hybrid Multi-GNSS has been developed. b. An NTRIP capable OSGRS has been developed. System efficiency has been improved and the system has been integrated with an IP and mobile data network. Several configurations of the OSGRS have been developed to suit varying scenarios. Such configurations have been performance tested and benchmarked. c. OSGRSv3 has been developed by upgrading the previous version of server. The system has been augmented with SMLC, GMLC, RRLP 3GPP LPP and OMA LPPe functionality. Performance of the OSGRSv3 vis-à-vis the OSGRSv2 has been evaluated. The design and architecture of the OSGRSv4 has been developed. d. An autonomous positioning method employing the WSN-enabled AGNSS has been developed and tested. The stand-alone WSN-based positioning method which can mitigate the associated communication, energy-cycle and radio limitations has been developed and employed to benchmark the WSN-enabled AGNSS.

Declaration relating to disposition of project thesis/dissertation

I hereby grant to the University of New South Wales or its agents the right to archive and to make available my thesis or dissertation in whole or in part in the University libraries in all forms of media, now or here after known, subject to the provisions of the Copyright Act 1968. I retain all property rights, such as patent rights. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation.

I also authorise University Microfilms to use the 350 word abstract of my thesis in Dissertation Abstracts International (this is applicable to doctoral theses only).

……………………………… …………………………… ………………………... Signature Witness Date

The University recognises that there may be exceptional circumstances requiring restrictions on copying or conditions on use. Requests for restriction for a period of up to 2 years must be made in writing. Requests for a longer period of restriction may be considered in exceptional circumstances and require the approval of the Dean of Graduate Research.

FOR OFFICE USE ONLY Date of completion of requirements for Award:

‘I hereby grant the University of New South Wales or its agents the right to archive and to make available my thesis or dissertation in whole or part in the University libraries in all forms of media, now or here after known, subject to the provisions of the Copyright Act 1968. I retain all proprietary rights, such as patent rights. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation. I also authorise University Microfilms to use the 350 word abstract of my thesis in Dissertation Abstract International (this is applicable to doctoral theses only). I have either used no substantial portions of copyright material in my thesis or I have obtained permission to use copyright material; where permission has not been granted I have applied/will apply for a partial restriction of the digital copy of my thesis or dissertation.'

Signed ......

Date ......

AUTHENTICITY STATEMENT

‘I certify that the Library deposit digital copy is a direct equivalent of the final officially approved version of my thesis. No emendation of content has occurred and if there are any minor variations in formatting, they are the result of the conversion to digital format.’

Signed ......

Date ......

ORIGINALITY STATEMENT

‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously published or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this thesis is the product of my own work, except to the extent that assistance from others in the project's design and conception or in style, presentation and linguistic expression is acknowledged.’

Signed ......

Date ...... STATEMENT OF AUTHORSHIP AND LOCATION OF DATA

This form (and any supporting material) must be lodged with the Research Publication Coordinator (Research- [email protected]) or in hard copy (The Research Publications Coordinator, UNSW Library, UNSW).

AUTHORSHIP DECLARATION

The criterion for “authorship” is clearly defined in the UNSW Research Code of Conduct and the Procedure for Authorship and for Resolving Disputes between Authors.

The minimum requirement for authorship is that an author must have had a substantial intellectual contribution to the paper or research output, where any one of the following conditions are met: 1. conception and design; and/or 2. analysis and interpretation of data; and/or 3. drafting the article or revising it critically so as to contribute to the interpretation.

According to this definition, the authors of the paper titled: submitted/resubmitted to…………………………………………………………………………………………………. on………………………………..are the undersigned, and there are no other valid authors. The order in which the authors’ names appear in the submitted paper is acceptable to all authors. All authors agree that they have met the minimum requirements listed above and have approved the submitted version of the paper. All authors agree that they are responsible for the content of the paper.

NAME SIGNATURE (and other information as necessary) (The UNSW corresponding author on the paper should be marked with an “*”)

More rows may be added as necessary.

If, for any reason, one or more of the co-authors is unavailable or otherwise unable to sign above, a Fax or email from them acknowledging that they are in agreement with the statements must be appended. If this is also not possible the senior School/Centre researcher most related to the work may sign on their behalf, noting the reason for their unavailability in the box above.

LOCATION OF RESEARCH MATERIALS AND DATA DECLARATION

I have read, and agree to comply with the UNSW Procedures for Handling Research Material and Data.

The primary data on which the paper referred to above is:

kept in the School; elsewhere.

If elsewhere, please indicate where:

Signed: !

UNSW Corresponding or Executive author

Date: / /

ACKNOWLEDGEMENT OF LODGEMENT WITH HEAD OF ACADEMIC UNIT

Submitted to School/Centre on: / /

Signed: !

Head of School/Director of Centre

Date: / /

PUBLICATION DETAILS (To be added as appropriate at a later date)

Accepted for publication on: / /

Publication details

NOTE ON STORAGE OF COMPLETED FORMS

1. The original version of this form is to be filed with the UNSW Library. 2. Copies of all documentation to be held by at least the UNSW corresponding or executive author.

! !

To my family

"I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success... such emotions make a man forget food, sleep, friends, love, everything." Nikola Tesla

Abstract

Global Navigation Satellite System’s (GNSS) known shortcomings in difficult radio-environments – signal obstructions and jamming vulnerability – could pose significant risks in critical location based services (LBS) applications. Off-the-shelf systems such as ‘Spot Satellite Messenger’ are not compliant for E911 and other emergency response requirements. Despite considerable research and engineering efforts, few techniques have demonstrated promising results. Multiple sensor-based techniques and systems based on Assisted-GNSS (AGNSS) have been proposed in order to improve the performance of stand-alone GNSS. Improved time-to-first-fix (TTFF), system availability and positioning accuracy are the notable performance gains. Many AGNSS techniques employ proprietary protocols which limit further academic research or pre-deployment testing. The Open Source GNSS Reference Server (OSGRS) – on the other hand uses a Hyper Text Transfer Protocol (HTTP) based stateless GNSS Reference Interface Protocol (GRIP). For the research described in this thesis, a hardware based GNSS receiver was first used to acquire assistance data. Subsequent versions of OSGRS have seen alternative acquisition approaches using numerous GNSS Casters available over Internet Protocol. A variety of data formats are available, hence OSGRSv2 is capable of Multiple Assisted GNSS (MAGNSS). Client and server integration, testing and performance benchmarking against competing technologies appeared promising. The system tracked the highest number of satellites, availability and higher accuracy with low TTFF values. Three configurations of multi-GNSS assistance servers allow flexible operation independent of the presence of Virtual Private Networks (VPNs) – a limitation of OSGRSv1. Iteratively, the server has been augmented with Long Term Evolution (LTE) Positioning Protocol (LPP) and the associated extensions (LPPe) to develop the third generation OSGRSv3. Interconnection of multiple networks is provided through Internet Protocol (IP) data control gateways for user-specific information exchange. Assistance Model Portfolio of OSGRSv3 has been expanded with the development of mobile communications interworking criteria. A real network implementation in a controlled mobile network laboratory has been configured. The architecture exploits LTE Radio Access Network (RAN), Transmission, Core and GNSS elements to test the performance of the system. Performance graphs demonstrate that Radio Resource Location Protocol (RRLP) based system lowered the TTFF and improved the satellite availability and positioning accuracy over OSGRSv1 or OSGRSv2. Options of selectively choosing which GNSS to use is managed through a source selector switch.

Presence of basic networking infrastructure has been a critical limitation of Multiple Assisted GNSS systems. A low infrastructure strategy to augment GNSS with adhoc Wireless Sensor Nodes (WSN) has been presented. Pre-programmed fixed sensor nodes are deployed in the test area where a rover sensor node is connected to a GNSS-capable mobile device. Based on the received signal strength, signature indices are generated and autonomous proximity calculations of the rover are performed. The localization information is transferred to GNSS via assistance messages. Experiments were conducted to simulate a reduction in navigation search space, competitive TTFF and improved availability and accuracy. Link quality indicators can effectively provide pre- processed frequency offset, range and coordinate assistance in the absence of IP network, in building coverage (IBC) repeaters or GNSS. Stand-alone sensors based localization demonstrated cm-level accuracy, response sensitivity and reliability. System robustness against partial node malfunction in instances of clocking, time syncing, thermal noise, coordinate decoding and processing issues, was observed. Such errors can arbitrarily eventuate in erroneous localization. Reference Server, Caster and Sensor Networks and MAGNSS can provide cost effective alternatives for generic and specific AGNSS localization applications. The contributions of this thesis can be summarized as follows: a. GPS, GNSS, AGNSS, RNSS, SBAS and alternative positioning technologies have been reviewed. Several LBS variants have been investigated and shortcomings listed. Alternative navigation, communication and logging techniques have been suggested to BWRS, NSW Police and the VRA. SPOT GNSS Messenger has been performance evaluated. Architecture for a Multiple Sensor based hybrid Multi-GNSS has been developed. b. An NTRIP capable OSGRS has been developed. System efficiency has been improved and the system has been integrated with an IP and mobile data network. Several configurations of the OSGRS have been developed to suit varying scenarios. Such configurations have been performance tested and benchmarked. c. OSGRSv3 has been developed by upgrading the previous version of server. The system has been augmented with SMLC, GMLC, RRLP 3GPP LPP and OMA LPPe functionality. Performance of the OSGRSv3 vis-à-vis the OSGRSv2 has been evaluated. The design and architecture of the OSGRSv4 has been developed. d. An autonomous positioning method employing the WSN-enabled AGNSS has been developed and tested. The stand-alone WSN-based positioning method which can mitigate the associated communication, energy-cycle and radio limitations has been developed and employed to benchmark the WSN-enabled AGNSS. ii

Acknowledgements

Thanks to Allah, the Beneficent, the Merciful, for granting me the opportunity and capability to undertake and complete this work.

My sincere thanks to my supervisor Professor Chris Rizos, without whose kind help, technical guidance, moral support and administrative assistance, I couldn’t accomplish this research. He not only helped me expand my mental horizon but also assisted in setting and following a clear pathway. Thanks to Professor Andrew Dempster for providing me such post-graduate research training opportunity, necessary resources and guidance through the initial phase of this research. I feel honoured to have worked under the guidance of supervisors of such high stature.

I am grateful to my co-supervisor Dr. Eamonn Glennon for providing me invaluable support and feedback throughout the candidature. Many thanks to Mr. Peter Mumford and Dr. Binghao Li for providing me technical guidance at innumerable instances. More than experience, I feel privileged to have been granted the opportunity to work under the guidance of such fine experts.

Thanks to Dr. Jinling Wang and Dr. Yong Li for conducting the yearly progress reviews, critique my work and providing assistance in keeping a focused approach. Thanks to Dr. Samsung Lim for providing the post-graduate candidature administration assistance and Dr. Yincai Zhou for providing all the IT resources within the school.

I would also like to thank Dr. Sana Qaiser, Dr. Faisal Khan, Dr. Omer Mubarak, Dr. Mazher Choudhury, Dr. Usman Iqbal and all academic, student and staff members of the School of Surveying and Geospatial Engineering, Satellite Navigation and Positioning lab and the Australian Centre for Space Engineering Research at University of New South Wales for their continuous support throughout. My sincere thanks to all team members of Bush Walkers Wilderness Rescue Squad for providing me the opportunity to conduct exercises and meetings with them to gain valuable information which thus provided a starting point for this research.

I profoundly thank my parents, brother, sister, brother-in-law, wife and daughter without whose love, encouragement, moral and financial support, I would be nowhere. They contributed a lot to what I am today and without their help I couldn’t possibly complete my research.

iii

Table of Contents

Abstract i Acknowledgements iii Table of Contents iv List of Figures x List of Tables xiv List of Acronyms and Symbols xv

1. Introduction, Motivation and Objectives 1 1.1 GPS and GNSS 1 1.2 GNSS Limitations 3 1.3 Government Mandates 4 1.3.1 United States of America, E911 4 1.3.2 Europe, E112 4 1.3.3 Japan and Other Countries 4 1.4 Assisted-GNSS in Location Based (Emergency) Services (LBS/LBES) 5 1.4.1 Assistance Data Types 6 1.4.2 Significance of Research and LBS Applications 6 1.5 Relevant Positioning Systems and Localisation Techniques 8 1.5.1 Positioning and Navigation Systems 8 1.5.2 Localisation Techniques 9 1.6 Thesis Motivation and Objectives 9 1.7 Structure of Thesis 15 1.8 Contributions of Thesis 16 1.9 List of Publications 17

2. Background, Relevant Literature and Related Work 18 2.1 First Generation Positioning Systems 18 2.1.1 Terrestrial Positioning Systems 18 2.2 Modern Positioning Systems 19 2.2.1 Global Navigation Satellite System (GNSS) 19 2.2.2 Regional Navigation Satellite System (RNSS) 20 2.2.3 Satellite Based Augmentation System (SBAS) 21 iv

2.3 NAVSTAR Global Positioning System (GPS) 21 2.3.1 GPS Signals 22 2.3.1.1 L1 (1575.42 MHz) 22 2.3.1.2 L2 (1227.60 MHz) 22 2.3.1.3 L5 (1176.45 MHz) 22 2.3.2 GPS Signal Components 23 2.3.3 GPS Measurements 23 2.3.4 GPS (GNSS) Error Sources 23 2.3.5 GPS Satellite Clock 24 2.3.6 GPS Message Format 24 2.3.7 CNAV and MNAV 25 2.4 Indoor Positioning Techniques 26 2.5 Outdoor Positioning Techniques 28 2.6 Mobile Phone/Network Positioning Techniques 29 2.6.1 Cell ID based Positioning 30 2.6.2 Time Advance (TA) based Positioning 30 2.6.3 Received Signal Strength (SS) based Positioning 31 2.6.4 Angle of Arrival (AOA) based Positioning 32 2.6.5 Time of Arrival (TOA) based Positioning 32 2.6.6 Time Difference of Arrival (TDOA) based Positioning 33 2.6.7 Fingerprinting 34 2.7 Assisted GNSS 34 2.8 Open Source GNSS Reference Server (OSGRS) 36 2.8.1 Architecture 36 2.8.2 Operation 36 2.8.3 CORS OSGRS Licensing and Technical Support 36 2.8.4 CORS OSGRS Expansion Potential 37 2.9 Network Transport of RTCM via Internet Protocol (NTRIP) 37 2.9.1 Architecture 38 2.9.2 Load Balancing and Scalability 39 2.9.3 GNSS Transmitted Data Security 39 2.9.4 GNSS Data Integrity 39 2.9.5 System User Acceptance 40 2.9.6 Multi-GNSS Positioning Quality 40 v

2.9.7 NTRIP Multi-GNSS Configuration and Operation 40 2.9.8 Raw GNSS Data Acquisition 41 2.9.9 BNC Application 42 2.9.10 Multi-GNSS Acquisition 44 2.9.11 Multi-GNSS File Types 44 2.9.12 Acquired Parameter Translation (Multi-GNSS Client-End Interface) 44 2.10 WSN based Positioning 46 2.11 Secure User Plane Location (SUPL) 46 2.12 Concluding Remarks 49

3. SPOT Satellite Messenger and Hybrid Positioning 50 3.1 Location Based Services 50 3.2 SPOT Satellite Messenger 52 3.2.1 System Hardware 55 3.2.2 System Coverage 55 3.2.2.1 Map Legend 56 3.2.3 Experiments 56 3.2.3.1. Benchmarking Equipment 56 3.2.3.2. Test Area and Test Point Classification 57 3.2.3.3. Signal Attenuation 57 3.2.3.4. Classification of Test Points 58 3.2.3.5. Experimental Results 59 3.3 Mitigation Technique 65 3.3.1 System Architecture 66 3.3.2 System Operation 69 3.3.3 Significance and Applications 72 3.4 Concluding Remarks 73

4. Assisted Multi-GNSS Reference Server, OSGRSv2 74 4.1 Introduction 74 4.2 Open Source GNSS Reference Server (OSGRS) 75 4.3 System Architecture and Operation 76 4.4 Code Structure 78 4.5 Enhanced Assistance Model 79 vi

4.6 Operation and Code Processing 82 4.7 Multi-GNSS Unit Integration 83 4.7.1 Network Transport of RTCM via Internet Protocol (NTRIP) 83 4.7.2 Configuration and Operation 85 4.7.3 Raw Data Acquisition 86 4.8 Acquisition Unit Testing 87 4.8.1 Parameter Translation 89 4.8.2 Observation Data 89 4.8.3 Navigation Data 90 4.9 Positioning Unit Testing and Data Collection 92 4.10 Benchmarked Devices 93 4.11 Experimentation Results 95 4.12 Configurations and Relative Performance Cost 97 4.13 Source Code Architecture 98 4.13.1 Project Structure 99 4.13.1.1 Client Side 99 4.13.1.2 Server Side 100 4.13.1.3 XML GRIP Schemas 102 4.14 Installation and Configuration 103 4.15 Support, Redundancy and Licensing 104 4.16 Concluding Remarks 105

5. LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server 106 5.1 Introduction 107 5.2 Radio Resource Location Protocol (RRLP) 109 5.3 LTE Positioning Protocol (LPP) and LPP Extensions (LPPe) 112 5.3.1 Positioning Techniques 112 5.3.2 LPP/e Data Transmission: Control Plane vs. User Plane 113 5.3.3 Positioning Parameters Format 115 5.3.4 Motivation 116 5.3.4.1 LPP/e based System Capability 117 5.4 Integrated Architecture (3GPP LPP, OMA LPPe and OSGRSv3) 119 5.5 Test Environment and Connectivity Scenarios 120

vii

5.6 Configuration, Clocking and Operational Support Systems (OSS) 123 5.7 Logical Structure and Operation 124 5.8 Quality of Service, Data Collection and Benchmarking 127 5.9 Conclusion 131 5.10 Project Structure and Support 132 5.10.1 Client Side 133 5.10.2 Server Side 133 5.11 System Development and Configuration 136 5.12 Fourth iteration of the OSGRS 137 5.13 Chapter Summary 138

6. WSN Assisted and WSN Based Positioning Techniques 139 6.1 Introduction 139 6.2 Background 140 6.3 Wireless Sensor Networks-Enabled Assisted-GNSS 141 6.3.1 System architecture and operation 141 6.3.2 Node and protocol architecture 142 6.3.3 GNSS hardware and software architecture 142 6.3.4 Network and transmission architecture 143 6.4 Integration and Operation 144 6.5 Location Measurements and Computation 145 6.6 Test Bed and Data Collection 149 6.6.1 Experimentation 151 6.7 Problem Identification and Mitigation 150 6.8 Error Types and Effects on Localisation Performance 154 6.9 Error Mitigation: Stand-Alone Sensor Network-based Localisation 155 6.9.1 System architecture and operation 156 6.10 Test Bed and Experimentation 157 6.11 System Performance 158 6.12 Concluding Remarks, System Potential and Applications 160

7. Conclusions and Future Recommendations 162 7.1 Research Challenges 162

viii

7.2 Location Determination Techniques in Weak Signal Environments 162 7.3 Thesis Summary 163 7.4 Recommendations for Future Work 165 7.5 Conclusive Remarks: A-GNSS Standardization and Industry Status 168

Appendices 169 A. OSGRS Assistance Model and Data Formats 169 A.1 Assistance data support 169 A.2 Interface procedures 169 A.3 OSGRS data formats 179 B. GRIP XML Schema Definition(s) 185 C. GRIP Operation and Data (IETF Controlled Supplement) 198 C.1 GRIP Operation Overview 198 C.2 Assistance Data 203 C.3 XML Schema 204 C.4 Security Considerations 207 C.5 Associated RFC(s) 208 D. OSS Systems Interface employed for LPP/e Project 209 E. MICAz Wireless Measuring System (Datasheet) 210 F. SPOT Satellite Messenger Technical Datasheet 212 G. OSGRS Mobile Execution 213 H. NTRIP Data Stream and Settings 214 I. Miscellaneous Positioning Techniques 215

Bibliography 219

List of Figures

Figure 1.1 GPS, GNSS, RNSS and SBAS systems, (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012) 2 Figure 1.2 Mobile LBS revenue forecast, €mil (2010-2016) 7 Figure 1.3 SPOT Hardware 10 Figure 1.4 Research Hypotheses, Focus, Methodology and Timeline 14 Figure 1.5 Thesis Structure 15 Figure 2.1 Graphical representation of GPS/GNSS error sources 24 Figure 2.2 GPS message format 25 Figure 2.3(a, b) Cell ID based positioning 30 Figure 2.4 TA based positioning 31 Figure 2.5 RSS based positioning 32 Figure 2.6 AOA based positioning 32 Figure 2.7 TOA based positioning 33 Figure 2.8 TDOA based positioning 34 Figure 2.9 NTRIP architecture 38 Figure 2.10 NTRIP Client interface 41 Figure 2.11 a. Binary/raw data NTRIP stream 42 Figure 2.11 b. Decoder configuration screen 43 Figure 2.12 BNCv2.6 client interface 43 Figure 2.13 SUPL architecture (OMA-AD-SUPL-V1_0-20060127-C, 2006) 47 Figure 2.14 Process overview of the SET-initiated AGPS/AGNSS 48 Figure 3.1 Building Blocks of a LBS System 51 Figure 3.2 COSPAS-SARSAT Global Operation 52 Figure 3.3 SPOT Satellite Messenger System 52 Figure 3.4 a. Message updates on mobile phone 53 Figure 3.4 b. Exact location received via SMS 53 Figure 3.5 Entry updates in user profile 54 Figure 3.6a Plots of tracking/logging updates 54 Figure 3.6b Lat/Long plots on Google Maps (Hybrid Mode) 55 Figure 3.7 Global coverage footprint - Location of experiments is highlighted 56 Figure 3.8 General AGNSS components 57

Figure 3.9 Test bed in UNSW campus and surrounding area 59 Figure 3.10a Satellite availability against difficulty levels 60 Figure 3.10b SPOT horizontal & vertical errors, and standard deviations 60 Figure 3.10c SPOT Messenger mean horizontal & vertical errors, and standard deviations 61 Figure 3.10d SET-Assisted AGPS mean horizontal & vertical errors, and standard deviations 62 Figure 3.10e SET-Based AGPS mean horizontal & vertical errors, and standard deviations 62 Figure 3.10f Stand-alone HS-GPS mean horizontal & vertical errors, and standard deviations 62 Figure 3.11a SPOT performance 64 Figure 3.11b MS-Assisted AGPS performance 64 Figure 3.11c MS-Based AGPS performance 64 Figure 3.11d Stand-alone HS-GPS performance 65 Figure 3.12 Performance comparison 65 Figure 3.13 Hybrid Positioning System architecture 68 Figure 3.14 Hybrid Positioning System operation 71 Figure 4.1 Basic components of the OSGRS 76 Figure 4.2 OSGRSv1 Architecture 77 Figure 4.3 System architecture of the MAG OSGRS 77 Figure 4.4 Logical System Operation 82 Figure 4.5 Multi-GNSS Global Footprint, UNSW is highlighted 84 Figure 4.6 Multi-GNSS System Architecture 85 Figure 4.7 Multiple Assisted-GNSS Streamcast, OSGRS v2.0 88 Figure 4.8 OSGRS Operation on a Mobile Device 89 Figure 4.9a Observation data stream 90 Figure 4.9b Navigation data stream 90 Figure 4.10 Test Bed Map at L4 EE UNSW 92 Figure 4.11a WSNAGNSS System 94 Figure 4.11b Mio A-GNSS system 95 Figure 4.11c Spot Messenger System 95 Figure 4.12a Satellite Visibility 96 Figure 4.12b Time to Fix First 96 Figure 4.12c Availability 96 Figure 4.12d Accuracy 96 Figure 4.12e Failure Rate (Overall) 97 xi

Figure 4.12f Failure Rate (Unobstructed) 97 Figure 4.13 OSGRSv2 Config. a. 98 Figure 4.13 OSGRSv2 Config. b. 98 Figure 4.13 OSGRSv2 Config. c. 98 Figure 5.1 Multi-GNSS OSGRSv2 108 Figure 5.2 3GPP Standards Evolution 109 Figure 5.3 Mobile Communications Network 110 Figure 5.4 RRLP Assistance Model 111 Figure 5.5 OSGRSv3 System Architecture 119 Figure 5.6 Test Environment 120 Figure 5.7 Conceptual Connectivity Diagram 121 Figure 5.8a Performance over Ethernet 24hours 122 Figure 5.8b Performance over Ethernet 15mins 122 Figure 5.9 Performance over SDH 123 Figure 5.10 Building Blocks of an Operational Support System 124 Figure 5.11 Logical System Operation 126 Figure 5.12 Quality of Service Management Process 127 Figure 5.13a Satellite Tracking, OSGRSv2 vs. OSGRSv3 129 Figure 5.13b TTFF Performance 129 Figure 5.13c Combined Availability 129 Figure 5.13d Accuracy 129 Figure 5.13e Unobstructed Failure Rate 129 Figure 5.14 OSGRSv3 Performance Improvements over OSGRSv2 130 Figure 5.15 OSGRSv3 Performance Degradation 131 Figure 5.16 OSGRSv4 Architecture 137 Figure 6.1a Wireless sensor mote or node 142 Figure 6.1b Interface device and programmer 139 Figure 6.2 System architecture and Operation 143 Figure 6.3 System information flow 144 Figure 6.4a Database Creation during Training Phase 145 Figure 6.4b Signature training and database creation based on signature slices 146 Figure 6.5 Coordinate orientation in triangular space 146 Figure 6.6 Coordinate orientation in circular space 147 Figure 6.7a Test bed at Electrical Engineering building L4, UNSW 149 xii

Figure 6.7b Localization response: location of mobile node is highlighted by Red marker 150 Figure 6.8 Assistance request by mobile node and localization response provided by fixed nodes 151 Figure 6.9a Mio A-GPS system 152 Figure 6.9b Spot Messenger System 152 Figure 6.10a Overall failure rate 153 Figure 6.10b Availability 153 Figure 6.10c TTFF 153 Figure 6.10d Accuracy 153 Figure 6.10e Satellite Tracking 153 Figure 6.11 WSN hardware architecture block diagram 156 Figure 6.12 Test bed 157 Figure 6.13a.Satellite visibility 158 Figure 6.13b Failure rate (excluding indoors) 158 Figure 6.13c Availability 158 Figure 6.13d TTFF 159 Figure 6.13e Accuracy 159 Figure 6.14.Performance comparison of three different configurations of WSN based localization 160

xiii

List of Tables

Table 2.1 Satellite-based positioning systems (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012) 20 Table 2.2 RNSS positioning and satellite augmentation systems (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012) 20 Table 2.3 SBAS satellite-based augmentation systems (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012) 21 Table 3.1 UNSW test point details 58 Table 4.1. OSGRS vs NTRIP GNSS Model 78 Table 4.2. OSGRS Multi-GNSS Assistance Model 81 Table 4.3 Observation data description (RINEX3, 2007) 91 Table 4.4 Data collection and Results 93 Table 5.1 Cellular network interfaces 111 Table 5.2 Assistance Model Overview 118 Table 5.3 Data Collection 128 Table 6.1 Data collection on UNSW test bed 152 Table 6.2 Summary of test results 153 Table 6.3 Data Collection and Summary of Results 158

xiv

List of Acronyms and Symbols

3GPP Third Generation Partnership Project A-Galileo Assisted Galileo A-GNSS Assisted Global Navigation Satellite System A-GPS Assisted Global Positioning System ACSER Australian Centre for Space Engineering Research AGAGNSS/AGANSS Assisted GNSS and Assisted Galileo Navigation Satellite System AG-ASHIPS AGNSS-All Scenario Human Monitoring Intelligent Positioning System AFLT Advanced Forward Link Trilateration AFP Australian Federal Police AOA Angle of Arrival ARGOS Advanced Research and Global Observation Satellite ASCII American Standard Code for Information Interchange AT&T American Telephone and Telegraph Company ATSC American Television Standard Committee AVL World tracker positioning system BAG Bluetooth Assisted GPS BIOS Basic Input/Output System BITS Building Integrated Timing Supply BKG Federal Agency for Cartography and Geodesy BNC BKG NTRIP Client BNS BKG NTRIP Server BSC Base Station Controller BTS Base Transceiver Station BVI Blind and Visually Impaired BWRS Bushwalker Wilderness Rescue Squad C/A Coarse Acquisition CAS Caster Specification Records CDMA Code Division Multiple Access CNES French Space Agency CSMA/CA/CD Carrier Sense Multiple Access/Collision Avoidance/Collision Detection CE Carrier Ethernet CfP Call for Participation

CLI Command Line Interface CNAV Civilian Navigation Message CORS Continuously Operating Reference Server CPS Cambridge Positioning System DCM Database Correlation Method DGNSS Differential GNSS DGPS Differential GPS DMZ De-Militarized Zone DoD Department of Defence DOP Dilution of Precision DORIS Doppler Orbitography and Radiopositioning Integrated by Satellite DRM Data source managers DTD Document Type Definition DTV Digital Television ECID Enhanced Cell ID EE Electrical Engineering EGNOS European Geostationary Navigation Overlay Service ELT Emergency Locator Transmitters EoSDH Ethernet over SDH EOTD Enhanced Observed Time Difference EPIRB Emergency Position-Indicating Radio Beacons ESA European Space Agency ESOC European Space Operation Centre EU European Union EUREF Regional Reference Frame Sub-Commission for Europe FCC Federal Communication Commission USA FDD Frequency Division Duplex FDMA Frequency Division Multiple Access FFMPU Family and Friends of Missing Persons Coordination Centre GA Geoscience Australia GAGAN GPS-aided geo-augmented navigation GE Gigabit Ethernet GEO Geostationary Orbit GEOSAR Geostationary Orbit Search and Rescue xvi

GIR GNSS Internet Radio GLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema GMLC Gateway Mobile Location Centre GNSS Global Navigation Satellite Systems GNU/GPL General Public Licence GPS Global Navigation Satellite System GPRS General Packet Radio Service GRIP GNSS Reference Interface Protocol GSM Global System for Mobile Communications GUI Graphical User Interface HDOP Horizontal Dilution of Precision HEO High Earth orbit HIS Human Interface System HOW Handover Word HSGNSS High Sensitivity GNSS HSPA High Speed Packet Access HSDPA High Speed Downlink Packet Access HSUPA High Speed Uplink Packet Access HTTP Hypertext Transfer Protocol IBC Inbuilding Coverage Repeater ICD Interface Control Document IDE Integrated Development Environment IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IPDL Idle Period Downlink IrDA Infrared Data Association IRNSS Indian Regional Navigational Satellite System IS-GPS Interface Specification for GPS JDK Java Development Kit JKL Jet Propulsion Laboratory KDDI KDDI Corporation Japan KPI Key Performance Indicators LBA Location Based Advertising LBS Location Based Services xvii

LBES Location Based Emergency Services LCS Location Communication Server LED Light Emitting Diode LEOSAR Low Earth Orbit Search and Rescue LMU Location measurement units LoS Line of Sight LORAN LOng RAnge Navigation System LPP/e LTE Positioning Protocol/extensions LTE Long Term Evolution LQI Link Quality Indicator M-Code Military code MAC Medium Access Control MEMS Microelectromechanical systems MEO Medium Earth Orbit Satellites MGAG/MGAGNSS Multi-GNSS Assisted GNSS MGEX Multi-GNSS EXperiment MGNSS Multi-GNSS MIC Ministry of Internal Affairs and Communications MIT-CS Massachusetts Institute of Technology-Computer Science MLS Microwave Landing System MNAV Military Navigation Message MoIP Mobile communication over internet protocol MPLS Multi-protocol Label Switching MSA Mobile Station Assisted MSAS Multi-functional Satellite Augmentation System MSB Mobile Station Based MSC Mobile Switching Centre MS Mobile Station MU Mobile User/Unit NASA National AeroSpace Agency NAV Navigation Mesage NAVCEN GPS USCG Navigation Center NESDIS National Environmental Satellite, Data, and Information Service NET Network Specification Records xviii

NESDIS National Environmental Satellite, Data and Information Service NMEA National Marine Electronics Association NMPCC National Missing Persons Coordination Centre NLOS Non-Line of Sight NOAA National Oceanic and Atmospheric Administration NRCan Natural Resources Canada NTP Network Time Protocol NTRIP Networked Transport of RTCM via Internet Protocol NTSC National Television System Committee OEM Original Equipment Manufacturer OMA Open Mobile Alliance OSGRS Open Source GNSS Reference Server OSI Open Systems International OSS Operational Support Systems OTD Observed Time Difference OTDOA Observed Time Difference of Arrival PAN Personal Area Network PBO Plate Boundary Observatory PC Personal Computer PCB Printed Circuit Board PDA Personal Digital Assistant PDH Plesiochronous Digital Hierarchy PHY Physical Layer PLB Personal Locator Beacon PLD Positioning device from World tracker PNT Positioning Navigation and Timing POES NOAA Polar Operational Environmental Satellites POI Point of Interconnect PP Priority Pyramid-Mechanism PRN Pseudorandom Noise PTP Precision Time Protocol P(Y) Precise Modulated Y Code QoS Quality of Service QPSK Quadrature Phase Shift Keying xix

QZSS Quasi-Zenith Satellite System R&D Research and Development RADAR Radio Detection and Ranging RAN Radio Access Network RBS Radio Base Station RINEX Receiver Independent Exchange Format RF Radio Frequency RFID Radio Frequency Identifier RRLP Radio Resource LCS Protocol RNSS Regional Navigation Satellite System RSS Received Signal Strength RSSI Received Signal Strength Indicator RT-IGS Real-Time IGS Working Group RTCM Radio Technical Commission for Maritime Services RTI Real Time Integrity RTK Real Time Kinematic RTT Round Trip Time RTTPP IGS Real Time Pilot Project SAGE School of Surveying and Geospatial Engineering SAR Search and Rescue SBAS Satellite Based Augmentation Systems SDH Synchronous Digital Hierarchy SDK Software Development Kit SET SUPL Enabled Terminal SGNSS Stand-alone GNSS SGPS Stand-alone GPS SIM Subscriber Identity Module SIMO Simplified Information Mobility and Orientation SIRGAS Sistema de Referencia Geocéntrico para las Américas SLA Service Level Agreement SLMS Smallest Least Square Method SMLC Serving Mobile Location Center SMS Short Messaging Service SMSC Short message service center xx

SNAP Satellite Navigation and Positioning lab SoL Safety of Life SoS System of Systems SPCF SUPL Position Calculation Function SS Signal Strength SSIS School of Spatial Information Systems STD Standard Deviation STR Stream Specification Records SUPL Secure User Plane TA Timing Advance TCP Transport Control Protocol TCXO Temperature Compensated Chrystal Oscillator TDM/A Time Division Multiple/Access TTB Time Transfer Board TTFF Time to Fix First TCP/IP Transmission Control Protocol TDOA Time Difference of Arrival TLM Telemetry TOA Time of Arrival TOW Time of week UDP User Datagram Protocol UHF Ultra High Frequency UMTS Universal Mobile Telecommunication System UNSW University of New South Wales USB Universal Serial Bus USMCC U.S. Mission Control Center USNO United States Naval Observatory UTC Coordinated Universal Time U-TDOA Uplink-Time Difference of Arrival VAS Value Added Services VDOP Vertical Dilution of Precision VHA Vodafone Hutchison Australia VHF Very High Frequency VLF Very Low Frequency xxi

VOR VHF Omnidirectional Range VTT Database Correlation method by Laitinen 2001 VRA Variable Rate Applications VRA Volunteer Rescue Association VRS Virtual Reference Station VPN Virtual Private Network W3C World Wide Web Consortium WAAS Wide Area Augmentation System WAP Wireless Application Protocol WiFi Wireless Fidelity WiMAX Worldwide Interoperable Microwave Access XPOI Point of Cross/Interconnect XSD Xml Schema Definition XML Extensible Markup Language WCDMA Wideband Code Division Multiple Access WLAN Wireless Local Area Network WRC World Radiocommunication Conference WSN Wireless Sensor Network/Node Series of variable distribution σ Standard deviation s Signature distance r Reference signature h Ellipsoidal heights H Orthometric heights N Geoid ellipsoidal separation k Fixed constant Path loss d Reference distance c RF velocity in air θ Air temperature in degrees Celsius x Superset column matrix of MS(x, y) P Positive scalar quantity F(x) Handover procedure function g(x) Function equivalent to - f(x) xxii

SLMS Smallest lease square method comparison Si Iterative code sample value N Iterative number of vector fields bil Billion mil Million m meters cm centimeters km kilometers

xxiii

Chapter 1 Introduction, Motivation and Objectives

Approximately 30-35,000 people are reported lost (James et al., 2008) to agencies such as Police, Salvation Army and Bushwalker Wilderness Rescue Squad (BWRS) in Australia every year (AFP, 2009). This is equivalent to 1 person lost every 15 minutes Ð exceeding the total number of victims of homicide, sexual assault, robbery and other crimes (Australian Institute of Criminology, 2000). Searching for lost people is estimated to cost more than AUD70million every year.

While many of these people may be children, intellectually disabled young persons or tourists, 0.5- 5% of these people are never found again. There have been 1600 people reported missing for more than a year in the last decade (Henderson and Henderson, 1998; Kiernan, 2000; Swanton, 1998). For every long-term missing person approximately another 12 people are affected emotionally, psychologically, physically or financially (Missing Persons Australia, 2008; Salvation Army, 2008). It is the prime responsibility of state or federal police and rescue agencies to employ all necessary location and recovery measures. Conventional navigation and modern positioning devices may be used for this purpose. National Missing Persons Coordination Centre (NMPCC) and the Family and Friends of Missing Persons Coordination Centre (FFMPU) collect data on the number of lost people, risk factors involved and response mechanisms Ð assisting the relevant agencies in locating such people.

A remote area survey conducted in Mogo Creek, northern NSW with BWRS in 2008 provided technical insights into the operational readiness and the limitations of the location based service (LBS) positioning technologies employed (BWRS Field Survey, 2008). Often, the lost people are not recovered in time due to the performance limitations of stand-alone GPS, GNSS, Assisted GNSS and LBS positioning systems - in challenging environments. This research thesis aims to identify the technical issues associated with such services and techniques, conduct testing and benchmarking of the devices, develop mitigation techniques and implement them.

1.1 GPS and GNSS

The US Global Positioning System (GPS) is without doubt the most pervasive Global Navigation Satellite System (GNSS) for positioning, navigation and timing (PNT) applications. Currently the 1

Chapter 1 Introduction, Motivation and Objectives

Russian GLONASS is the second operational GNSS. Future GNSS will include the EU’s Galileo and China’s BeiDou. Regional Navigation Satellite Systems (RNSSs) and Space Based Augmentation Systems (SBASs) currently also provide some PNT capability, or in the near future. Figure 1.1 summarises the characteristics of GPS, GNSS, RNSS and SBAS, and their operational status.

Expected Yearly Progress Transition GNSS Systems Outlook 1993------>2020 Description Operating Operating Transmission Transmission GNSS Orbit Types Planning, Operation and Upgrade Status Entity Satellites Technologies Band Global Positioning L1, L2, L3, Fully operational with continuous and GPS USA 28-31 MEO CDMA System L4, L5 periodic revisions Global'naya Navigatsionnaya GLONASS Russia 24 MEO FDMA-CDMA Fully operational since 2011 Sputnikovaya Sistema European Space Galileo Europe 30 MEO CDMA Operation and planning for 2013 and 2014 Agency System Chinese Navigation MEO, GEO, COMPASS China 35 CDMA Expected to start operating in 2015 System HEO RNSS Regional Navigation Satellite (Augmentation) Systems Expected to 4 (Beidou-1) MEO, GEO, Beidou China integrate into CDMA Partly operational 35 (Beidou-2) HEO COMPASS Doppler Orbitography and French civil precise orbit determination and positioning system based on the DORIS France Radio-positioning principle of the Doppler effect Integrated by Satellite Indian Government IRNSS India Initiated and 7LEO Indian space based augmentation system Controlled Quasi-Zenith QZSS (Japan) Japan QZSS, launched in 2010 Satellite System SBAS SBAS, multiple regional systems: WAAS, EGNOS, GAGAN, MSAS with varying levels of operational readiness GPS aided geo augmented navigation or GPS GAGAN India 1 Indian Satellite based Augmentation System in planning. and geo- augmented navigation Multi-functional MSAS Japan Satellite 2 Japanese Satellite based Augmentation System similar to SBAS in North America Augmentation European Geostationary EGNOS Europe 3 Initial Operations started in 2005, Fully operational since 2009. Navigation Overlay Service Wide Area Augmentation WAAS USA 38 38 Wide Area Reference Stations (WRN) Expected Operational since Oct 2007 System for North America Figure 1.1 GPS, GNSS, RNSS and SBAS systems, (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012)

A brief overview of such systems is presented here, while a more detailed analysis is given in Chapter 2.

Chapter 1 Introduction, Motivation and Objectives

GPS has proven extremely useful for US military applications since its inception in 1973. It was designed from the start for dual use (military and civilian) however the explosion in civilian sector applications took place after the removal of “selective availability” in 2000. Today its widespread applicability for global navigation has altered modern society in many fundamental ways.

By 2014, ABIResearch (2009) forecasts that about 1.1billion GNSS devices will be shipped, with expected revenue growth of USD330billion by 2020 (Jacobson, 2007; GSA, 2009). GNSS technology has brought a radical technology market transformation, in unison with the evolution of other technologies and the creation of myriad applications (Arthur, 2009; Shivaramaiah, 2011).

1.2 GNSS Limitations

It is well known that several factors can limit the operation of GNSS technologies in a “ubiquitous” sense (every time and anytime) (Wirolla, 2011). Despite several ground-based augmentations to space segment functionality and signal revisions, GNSS is vulnerable in difficult radio-frequency (RF) environments (Wang, 2002; Turrunen, 2008). Weak received signal level is the main cause of performance degradation (Sklar, 2003), while another factor is the existence of disruptive RF interference (Ndili & Enge, 1998). Poor satellite transmitter-receiver geometry may further diminish the quality of PNT performance (Hartinger & Brunner, 1999; Rizos et al., 2010).

GNSS availability and accuracy can degrade in urban canyons, indoors scenarios and unclear sky environments due to signal blockage, attenuation, multipath or interference (Brown and Olson, 2006). This is unacceptable in location determination for emergency services, search & rescue and Safety of Life (SoL) operations. Due to these performance limitations and the availability of stand- alone GNSS, alternate positioning and assistance systems are required (LaMance et al., 2002; Bryant, 2005).

A standard GNSS chipset could take up to 60 seconds or more to compute the first position fix (Diggelen, 2009). Furthermore, stand-alone GNSS (SGNSS) can be unusable in some adhoc sensor network operational environments. “Hot-start” may provide quicker position fix (Mautz et al., 2007; Ganeriwal, 2003). However, this may still be time inefficient due to the need for a comprehensive frequency bin and code delay search (Garin, 2010). Regardless of the mobile phone technology in use (2G/3G/LTE), cellular network coverage inside buildings does experience

Chapter 1 Introduction, Motivation and Objectives

difficulties, with occasional poor reception due to low signal levels and attenuation through the walls (Infonetics Research, 2007).

1.3 Government Mandates

Around the globe, several countries have government mandates (Diggelen, 2009) establishing legislative requirements for LBS provision. Such mandates, to a certain extent, “standardise” the delivery of location-based and information provisioning services in emergencies. Examples of such mandates are briefly discussed below.

1.3.1 United States of America, E911

The provision of a reliable Location Based Emergency System (LBES) was initially legislated in the 1990s by the Federal Communications Commission (FCC) - to respond to all emergency 911 phone calls. The legislation required cellular phone service providers to be able to locate emergency (E911) calls with an accuracy of 100m (67% of the time), or 300m (95% of calls) when using ‘network assisted solutions’. In the case of ‘handset based solutions’, the accuracy requirement is more stringent (E911, Phase-II) (FCC, 1999). LBS service providers and cellular phone service providers were required to comply with these regulations.

1.3.2 Europe, E112

The EU emergency number is E112. This number has been granted an international emergency number status in North America. Dialling 112 on a cellular network in the US equates to dialling 911 as far as the service provider is concerned.However, the mandate does not dictate the level of accuracy for location information as in the case of E911 (European Parliament, 2002).

1.3.3 Japan and Other Countries

Japan’s Ministry of Internal Affairs and Communications (MIC) has established a similar mandate to E911 for emergencies where the network operator sends the required location information of the mobile user - employing GPS (when available) or cell-ID (if GPS not available) (KDDI, 2006; MIC, 2009). Many other countries have similar mandates, however location information delivery is

Chapter 1 Introduction, Motivation and Objectives

subject to the discretion of the service provider and/or subject to specific Service Level Agreements (SLA) (Diggelen, 2009). Such mandates are discussed in further detail in Chapter 2.

1.4 Assisted-GNSS in Location Based (Emergency) Services (LBS/LBES)

The terms Assisted-GPS (AGPS) and Assisted-GNSS (AGNSS) can cause confusion due to the common interchangeable use of the acronyms GPS and GNSS. In this thesis GNSS is used as the generic system acronym, while GPS refers to the US satellite-based positioning system. In a so- called “cold start” GPS chipsets can take longer than a minute to provide the first position fix as they have to search the correct frequency and code phases without prior knowledge of any of the tracking parameters. AGPS can improve the time-to-first-fix (TTFF) by at least 30 seconds by reducing the frequency and code delay search space. We may refer to a “warm start” or “hot start” depending on the level of assistance information provided (Diggelen, 2009). This can be achieved by providing assistance in data acquisition and processing by eliminating the need to demodulate the navigation message from the broadcast signal (Harper et al., 2007).

AGNSS-enabled devices require source(s) for the acquisition assistance necessary to enable positioning in difficult environments, defined here as areas of weak signal strength conditions as experienced indoors (Sarwar et al., 2009). Self-aware structured networks such as those that employ Internet Protocol (IP), the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Wireless Local Area Network (WLAN) or Wireless Fidelity (WiFi) and Wireless Sensor Networks (WSN), can provide initial mobile receiver coordinates, limited timing or some assistance information. Some integration methods have been proposed for the implementation of an AGNSS scheme, and these are discussed in Chapter 2. Recently, LBS technologies for emergency services (LBES) have improved by employing AGNSS and/or navigation sensor integration.

Proprietary protocols on commercial systems that provide assistance are usually associated with high cost, interoperability and licensing issues. This does complicate the process of performing objective research and performance testing. The Open Source GNSS Reference Server (OSGRS) is an open source java application that can provide assistance using local and global GNSS broadcasters. The communication exchange between the mobile device and the AGNSS server may be conducted through either the “control-plane” or the “user-plane”.

Chapter 1 Introduction, Motivation and Objectives

1.4.1 Assistance Data Types

There is a variety of AGNSS assistance data types depending on the assistance system involved, its capability and the associated SLA. In general, the GNSS receiver reports the code phases and processing is carried out by a back-end server. Some of the common GNSS assistance data types are (Yan et. al, 2007; Diggelen, 2009):

a. Reference time b. Navigation model c. Ionosphere model d. Doppler and Doppler rate e. UTC model f. Almanac g. Real time integrity h. Differential corrections i. Acquisition assistance j. Code phases

1.4.2 Significance of Research and LBS Applications

Multiple Network A-GNSS based LBS had remained largely unexplored until the early 2000s, when researchers and industry alike started to realise the potential growth. Global trends in fixed and mobile infrastructure (Figure 7.1) indicate that the LBS market segment had grown significantly from about USD0.5billion and 20 million subscribers in 2003 to over USD8billion and 160 million subscribers by 2010 (ABI Research, 2006).

Chapter 1 Introduction, Motivation and Objectives

Figure 1.2 Mobile LBS revenue forecast, €mil (2010-2016), (Berg Insight, 2010)

There are a number of variants of LBS. For instance, Location Based Advertising alone accounts for 28.3% of total advertising on mobile devices. Regional estimates indicate expected growth from €205million in 2010 to €435million by 2016 in Europe, and USD620million in 2010 to USD710million by 2016 in North America (Berg Insight, 2012). Mobile local search numbers (users) are expected to reach approximately 1.5billion by 2014 - with ubiquitous GNSS integration into mass market handsets (Juniper Research, 2010).

Popular social and individual applications include mapping for navigation, search for information, social networking, entertainment and recreation. General public and/or private sector applications may include asset tracking, community services, vehicular navigation, weather forecasting, intelligent transportation systems, environmental applications, telematics and others. Professional or military applications include security and intelligence operations, notification systems for emergency responders, public notification systems, people and asset monitoring, automatic emergency call down systems, raise preparedness in disaster situations and many more.

Systems providing LBSs are nowadays used in all facets of community life, ranging from social and media, to productivity and navigation. Canalys (2009) identifies navigation and location market trends in six prime segments of LBS:

Chapter 1 Introduction, Motivation and Objectives

a. Social: friend finder b. Productivity: fleet and cargo management c. Information: city guides and local services d. Navigation: turn-by-turn guidance e. Commerce: location aware advertising f. Security: family, friends and pet trackers

1.5 Relevant Positioning Systems and Localisation Techniques

1.5.1 Positioning and Navigation Systems

Emergency Position Indicating Radio Beacons (EPIRB) transmit location information in emergencies at specified intervals of time. They can be used for tracking and sending distress signals. There are several categories of EPIRB operating in the range of 121.5-406MHz - although some frequencies are being phased out. Emergency Location Transmitters (ELT) are mainly used for military applications. Personal Locator Beacons (PLB) are employed to indicate personnel distress in maritime applications.

Most of these devices employ the Cospas-Sarsat system which was established in 1979 Ð predominantly for military applications Ð by Canada, France, the US and Russia. The Cospas-Sarsat system consists of satellite and ground terminals capable of responding upon receipt of registered beacon signals. It is operated by the National Environmental Satellite, Data and Information Service (NESDIS), a division of the US National Oceanic and Atmospheric Administration (NOAA, 2009). Garmin eTrex is one of the commonly used standard sensitivity GPS receiver (-120dBm) (Garmin, 2005). It can be employed to benchmark the relative performance of comparable devices, such as the Nemerix NX2/NJ1030 GPS - a low RF noise, low power and L1 C/A code chipset. Some manufacturers (CanadaGPS & TrackingTheWorld, 2012) market commercial and consumer positioning, tracking and logging devices similar to Bluetooth-based solutions (Toumaz, 2009) which need to be bonded to smartphones for activation. Obvious problems with such systems include limited coverage, system integration issues and lack of back-end network support. This is discussed in Chapter 2.

Chapter 1 Introduction, Motivation and Objectives

1.5.2 Localisation Techniques

Alternative positioning techniques include cellular or mobile phone, WiFi, WSN, Bluetooth, Infra- Red (IrDA), Radio Frequency Identification (RFID) and NETASSIST. Mobile phone positioning employs several techniques to locate a Mobile Station (MS), including measuring signal attenuation, angle-of-arrival (AOA), time-of-arrival (TOA) and time-difference-of-arrival (TDOA), based on base station radio signal exchange (Li, 2006; Rappaport et al., 1996). Difficulties are usually experienced in urban environments where cell geometries change with geographical receiver location and the user is required to be within cell or Radio Base Station (RBS) range to provide a fix. This creates challenges for accurate and reliable rural area LBS positioning.

The WiFi-based “fingerprinting” method has limited effectiveness in certain environments (Quader et al., 2007). Inconsistent signal strength may yield unreliable readings (Wang et al., 2003). Radio Detection and Ranging (RADAR) techniques can locate and track with accuracies as high as 2-3m, under appropriate conditions (Bahl et al., 2000). IrDA have obvious range and line-of-sight limitations. RFID-based techniques cannot cope with adverse environmental conditions (Chon et al., 2004). On the other hand, Bluetooth access points and devices are numerous and can easily create multiple small personal networks (Hallberg and Nilsson, 2002).

WSN nodes can be useful because of the relatively low capital investment and reasonable accuracy, with nodes failure tolerance (Lorincz et al., 2006). The system is effective in infrastructure-less positioning scenarios. NETASSIST has shown promising results indoors for military applications (Brown and Olson, 2006) Ð however, relies on installed infrastructure (Chapter 2).

1.6 Thesis Motivation and Objectives

In light of the discussion above, the performance and reliability of professional-grade GNSS and LBS devices employed by BWRS and NSW police needed a full scope survey - the devices tested in diverse scenarios and benchmarked against competing technologies.

Testing a LBS device indicates whether it can perform reliably in difficult environments such as

Chapter 1 Introduction, Motivation and Objectives

indoors. While several technologies are being employed, ‘Spot Satellite Messenger’ (Figure 1.2) gained attention due to claimed availability exceeding 90%. However, experiments with the device suggested collective availability not exceeding 40% (Chapter 3).

Understanding the space, user, ground and network segments is necessary in order to investigate the limitations in Navigation, Localisation, Communication and/or Tracking. A benchmarking exercise against Garmin GNSS, SiRFStar-III, AGNSS and stand-alone GNSS was carried out.

Figure 1.3 SPOT Hardware

(Note: Spot Messenger Technical Datasheet can be found in Appendix F).

Parameters of interest in tests include TTFF, availability and accuracy. Benchmarking the different devices highlights the need for alternative solutions to AGNSS including integrating multiple sensors, multiple GNSS and ground networks, WSN, mobile communications, stand-alone GNSS and the OSGRS (Chapters 3 & 6). As already mentioned, GNSS does not perform well (or even at all) in indoor, obstructed sky or urban-canyon environments due to multipath, attenuation or satellite signal non-availability. More sophisticated, flexible, scalable and open source alternative technologies are needed.

OSGRS was developed and implemented at the School of Surveying and Geospatial Engineering at the University of New South Wales The first version (OSGRSv1, 2007) was limited to direct connection of GPS hardware - a Novatel OEM3/4 receiver. A further limitation was that the system operated only within a specific Virtual Private Network (VPN) domain. Hence it was difficult for researchers and academics to conduct experiments outside the VPN. The reliance on a single GPS/GNSS hardware source motivated work to connect using Networked Transport of RTCM

Chapter 1 Introduction, Motivation and Objectives

(Radio Technical Commission for Maritime Services) over Internet Protocol (NTRIP) for providing user specified computation assistance and navigation data.

The Radio Resource Location Protocol (RRLP) was proposed by the Third Generation Partnership Project (3GPP) to provide efficient data transfer capability for LBS. Employing Third Generation (3G) or Long Term Evolution (LTE) mobile network’s assisted and stand-alone GNSS capability was a viable choice for the OSGRS expansion project undertaken during this thesis work (Chapter 5). 3GPP LTE positioning protocol (LPP) provides the basic infrastructure roadmap for a high accuracy positioning assistance model through control-plane bandwidth channels - in mobile access and core communication networks. Despite its inherent capacity constraints, LPP can perform well in conjunction with Open Mobile Alliance’s (OMA) Secure User Plane release 3 (SUPLr3) based LPP extensions (LPPe). Combining the constrained control-plane with unconstrained user-plane bandwidth can mitigate such network limitations by exploiting priority-based traffic deviation. Where Secure User Plane (SUPLr1 & r2) provided the positioning functionality through conventional mobile communication systems, SUPLr3 can extend the positioning parameter portfolio, hence laying the baseline for LPPe. It was thus intended to research and develop a 3GPP LPP and OMA LPPe based extensible system.

The upgrade of the OSGRS to the third release would therefore improve the performance. Interconnection of two networks would be provided through IP data control gateways for information exchange depending upon user preferences. Assistance data was to be made available through the OSGRSv3 client interface for the user - with comprehensive testing of the next generation mobile communications network in an actual cellular service provider environment (Chapter 5).

OSGRSv3 is a Multiple-Assisted-GNSS (MAGNSS) - requiring electrical and networking infrastructure to function. In many scenarios it may not be technically or economically viable to deploy such infrastructure, such as in remote and/or GNSS denied environments. This motivated work on adhoc, autonomous and energy efficient schemes employing Wireless Sensor Networks (WSN) Ð providing timing, localisation and assistance information.

A set of self-location aware stationary nodes would be deployed in the area of interest - providing positioning information to a rover node. Techniques in WSN-based positioning have proven 11

Chapter 1 Introduction, Motivation and Objectives

effective for assisting GNSS indoors. The system could be efficient for timing assistance and proximity location positioning in diverse geometrical area(s). System operations is based on received signal strength indicators (RSSI), link quality indicators (LQI) and individual fixed node location slices - contained in cumulative signature indices database on each node. The system could effectively provide pre-processed frequency offset, range and coordinate assistance for LBS by periodic transmission to surrounding nodes (Chapter 2 & 6). Because each node would contain self and neighbouring nodes location slices, a cumulative output stream containing calculated location coordinates of the mobile node and streamed through a dynamically chosen Point of Interconnect (PoI) could be used for location determination. The rover node can be a WSN-interfaced portable device - a smartphone or laptop displaying the location information and providing assistance parameters to a GNSS chipset.

However, sensor nodes have problems associated transceiver time-syncing, thermal noise and broadcast error introduction, incorrect parameter decoding and processor initialisation delay. Such problems can produce erroneous position results. A system based on stand-alone WSN positioning was developed and tested. Performance parameters were established and benchmarked against GNSS and AGNSS in difficult environments (Chapter 6).

Considering the above issues, the prime objectives of this research were to improve the reliability of MAGNSS in terms of key parameters such as availability, accuracy and TTFF. In summary, the objectives were to:

a. Comprehensively review GPS, GNSS, AGNSS, RNSS, SBAS and alternative positioning technologies. b. Perform in-depth operational analysis of techniques used by BWRS, NSW Police and VRA for Navigation, Communication, Tracking and Logging. c. Research conventional LBS variants, investigate shortcomings in order to baseline the performance of MAGNSS enabled LBS. d. Conduct comprehensive performance evaluation of SPOT GNSS Messenger in diverse environments in order to benchmark against competing LBS devices. e. Design the architecture for a Multiple Sensor based hybrid Multi-GNSS. f. Perform in-depth GNSS hardware and Java firmware review of first release OSGRS, and improve the system operability by undertaking a Java client and server upgrade facilitating access to assistance data from globally available broadcasters through NTRIP. 12

Chapter 1 Introduction, Motivation and Objectives

g. Conduct unit-based application testing (including old and new code fragments) of the OSGRS, improve firmware efficiency by debugging and re-integrate the whole application package within an IP and mobile data network. h. Establish multiple configurations of operation of the OSGRS for different scenarios and carryout the multi-configuration performance testing, performance cost analysis and benchmarking of OSGRS. i. Upgrade the OSGRSv2 server functionality further by augmenting SMLC, GMLC, RRLP 3GPP LPP and OMA LPPe functionality; and benchmark the performance of the OSGRSv3 vis-à-vis the OSGRSv2. j. Investigate, develop, program and test autonomous positioning methods employing WSN- enabled AGNSS. k. Investigate, program and test stand-alone WSN-based positioning methods that mitigate the associated communication, energy-cycle and radio limitations. l. Investigate the potential convergence of GNSS platforms, mobile operators and software platforms and speculate on the future OSGRSv4.

A comprehensive research overview is demonstrated in Figure 1.4

Chapter 1 Introduction, Motivation and Objectives

Research GNSS Coverage Issues Timeline and implications on LBS

Identification of Alternative 2007-2009 Techniques and Test Bed and AGNSS Benchmarking Market Survey and Selection of Commerical Devices

Problems of 2009-2010 Commerical Devices

Hypothesis, Hardware Device and and Technique Network Selection Issues Improved First Release Positioning using Open Source 2010-2011 Multiple Assisted Server GNSS

Redesign of Performance Hardware and Issues Firmware

Second Release Open Source Server

2011-2013 Revision of Performance Hardware and Issues Firmware

Problems of Third Release Open Source Server

Resolution to use Infrastructureless OSGRSv4 or flat architecture Proposal positioning Outcome and Non Infrastructure Future Work Based positioning using Adhoc Sensors

Thesis Production

Figure 1.4 Research Hypotheses, Focus, Methodology and Timeline

Chapter 1 Introduction, Motivation and Objectives

1.7 Structure of Thesis This thesis is structured in seven chapters as indicated in Figure 1.4.

Chapter Chapter Chapter No. Name Description

Discusses GPS and GNSS from inception Introduction, to ongoing evolution including Chapter 1 Motivation and limitations which are addressed by Objectives Assisted and Multi-GNSS work in this research. Discusses prior work in the field, conducted field surveys and limitations Background, found in concurrent systems. Chapter 2 Relevant Literature Simultaneously discusses how Multi- and Related Work GNSS Assistance provisioning can improve performance. Discusses extensive testing of SPOT SPOT Satellite messenger system and proposes an Chapter 3 Messenger and integration of System of Systems to Hybrid Positioning alleviate problems found.

Proposes the first Assisted Multi-GNSS Assisted based on the OSGRSv1, locally and Multi-GNSS Chapter 4 globally available GNSS casters to Reference Server, provide acquisiton and processing OSGRSv2 assistance. Test results are presented.

Presents the Radio Resource Location LPP and LPPe based Protocol (RRLP) based positioning Mobile Assisted Multi- techniques and how LPP and LPPe Chapter 5 GNSS GNSS Refernce based OSGRS can improve the Server, OSGRSv3 assistance provisioning portfolio. Test results are presented. Proposes alternative techniques of WSN Based and sensor networks for stand-alone WSN Assisted Chapter 6 positioning and assitance provisioning Positioning without power and communication Techniques network infrastructure. Concludes the chapter with proposals for future work and OSGRS platform Conclusion and extensions. Discusses how technology Chapter 7 Future trends and markets economics are Recommendations changing the game for mobile operators, software platforms owners and A/GNSS. Figure 1.5 Thesis Structure

Chapter 1 Introduction, Motivation and Objectives

1.8 Contributions of Thesis

The contributions of this thesis can be summarized as follows:

b. An NTRIP capable OSGRS has been developed. System efficiency has been improved and the system has been integrated with an IP and mobile data network. Several configurations of the OSGRS have been developed to suit varying scenarios. Such configurations have been performance tested and benchmarked.

c. OSGRSv3 has been developed by upgrading the previous version of server. The system has been augmented with SMLC, GMLC, RRLP 3GPP LPP and OMA LPPe functionality. Performance of the OSGRSv3 vis-à-vis the OSGRSv2 has been evaluated. The design and architecture of the OSGRSv4 has been developed.

d. An autonomous positioning method employing the WSN-enabled AGNSS has been developed and tested. The stand-alone WSN-based positioning method which can mitigate the associated communication, energy-cycle and radio limitations has been developed and employed to benchmark the WSN-enabled AGNSS.

Chapter 1 Introduction, Motivation and Objectives

1.9 List of Publications

The aforementioned work that constitutes several parts of this thesis has been published in several journal, conference and magazine articles as follows:

Sarwar, A., Li, B. & Dempster, A. (2009), ‘SPOT in Location Based Emergency Services, LBES, Detailed Analysis’, IGNSS Symposium, 1 Ð 3 Dec, 2009 Sarwar, A., Li, B. & Dempster, A. (2009), ‘All-Scenario Health Monitoring Intelligent (Multiple Assisted GNSS) Positioning System’, IGNSS Symposium, 1 Ð 3 Dec, 2009 Sarwar, A., Glennon, E. & Rizos, C. (2011), ‘Proposing a Multi-GNSS Assisted GNSS-Concept and Performance’, IGNSS Symposium, 15-17 Nov 2011 Sarwar, A., Glennon, E. & Rizos, C. (2011), ‘Test results of a Wireless Sensor Networks Assisted GNSS’, IGNSS Symposium, 15-17 Nov 2011 Sarwar, A., Glennon, E & Rizos, C (2012), ‘Performance of High Sensitivity Open Source Multi- GNSS Assisted GNSS’, Journal of Applied Geodesy, Dec 2012 Sarwar, A., Glennon, E. & Rizos, C. (2012), ‘RRLP (LPP and LPPe) Based Open Source Mobile Multi-GNSS Assisted GNSS Assistance Model’, IPIN, 13-15 Nov 2012 Sarwar, A., & Li B., (2012), ‘SPOT GNSS in Emergency and Location Based Services’, Dec 2012 issue, Journal of GPS Sarwar A., (2012), ‘Mobile (Operators, Platforms and GNSS), Technology Dynamics and Industry Economics’, pp35-36, Coordinates, Jun 2012 Sarwar, A., Glennon, E. & Rizos, C. (2013), ‘Cooperative Wireless Sensor Nodes based Acquisition for Mobile Location Services (MLoC)’, IGNSS Symposium, 16-18 Jul 2013 Sarwar, A., Rizos, C., (2013), ‘Architecture Proposal of OSGRSv4 following the Convergence of Mobile Network Infrastructure’, IGNSS Symposium, 16-18 Jul 2013 Sarwar, A., (2013), ‘Performance Characteristics of LPP/e over OSGRSv3 in Weak Signal Environments Pertinent to GNSS Network Latency and Data Processing’, JoGPS, 2013

Chapter 2 Background, Relevant Literature and Related Work

This chapter provides a basis for understanding the variety of global, assisted and regional positioning, navigation and timing systems.

2.1 First Generation Positioning Systems

One of the first generation satellite navigation systems deployed by the US military based on applying the principle of received signal Doppler shift was known as ‘Transit’, and dates back to the 1960s. Doppler shift measurements observe the difference between transmitted and received frequency, and when processed together with precise satellite orbit information can yield a position “fix” (Parkinson et al., 1995). Similar Doppler-based systems include Tsikada (Russian), and the Advanced Research and Global Observation Satellite (ARGOS) (France-US cooperation, 1978; Rizos, 1996).

2.1.1 Terrestrial Positioning Systems

Terrestrial radio-frequency (RF) based positioning systems such as Decca, Gee, Loran, Omega (Thorne, 1960) were developed before the advent of satellite systems and employed hyperbolic Time Difference of Arrival (TDOA) schemes. Radio direction finding systems required the user to tune to a radio station/transmitter with known coordinates, and a directional antenna would define a coarse bearing to the radio station. After repeating the process several times while in motion the user’s position could be calculated (Bakker, 1989). Commonly known systems included Long Range Navigation (LORAN-C, 1950), which had between 18-90m average accuracy, 95% confidence and 99.7% availability. However the Russian, US and Canadian LORAN-C signal transmission had been terminated as of early 2010 (Navcen, 2012). OMEGA was the first global navigation system developed by the US and other nations in the 1970s. It comprises eight globally distributed stations transmitting RF signals on the Very Low Frequency (VLF). OMEGA had around 2-4 nautical miles accuracy, 95% confidence level and 95% availability. The system was decommissioned in 1997 (Jproc, 2012). Other older terrestrial systems such as Microwave Landing System (MLS) and Very High Frequency (VHF) Omnidirectional Range (VOR) navigation system have also been abandoned in many countries (Department of

Chapter 2 Background, Relevant Literature and Related Work

Defense, 2008). The Tactical Air Navigation (TACAN) system was employed as a relatively accurate version of VOR to provide bearing, ranging and navigation information for military aircraft and civil aviation (Helfrick, 2009). However many of these systems have been replaced by the Global Positioning System (GPS) technology (Department of Defense, 2002).

2.2 Modern Positioning Systems

Current generation satellite systems today broadcast signals on which range or distance measurements are made, and position is computed with the aid of satellite ephemeris and timing information modulated on the transmitted signals.

2.2.1 Global Navigation Satellite System (GNSS)

GNSS receivers calculate the difference between transmit and receive times on several simultaneously tracked satellites, from which the time-of-flight estimates are made. The US NAVSTAR GPS is the most popular of the GNSSs, used for many PNT applications, because it has been operational for the longest time (since 1995). The GPS space segment nominally consists of 24 satellite in Medium Earth Orbit (MEO), although up to 32 are presently in orbit. The Russian system known as GLONASS is the only other fully operational GNSS with a constellation comprising of about 24 satellites in MEO.

Galileo is the European Union’s GNSS and is also expected to provide an accurate, reliable global positioning service when it is fully operational with a constellation of 30 satellites by the end of the decade (ESA, 2012). Its dual frequency operation and interoperability with GPS, GLONASS and other GNSSs will ensure that metre-level accuracy can be provided to any suitably equipped user. Service availability in extreme circumstances and user response within a few seconds is one of its unique characteristics, making it a viable choice for Safety of Life (SoL), military and sensitive private operations. The Chinese BeiDou GNSS will consist of around 35 MEO, GEO (Geostationary Earth Orbit) and HEO (Highly Elliptical Orbit) satellites, also expected to be operational by the end of the decade.

GPS, Galileo and BeiDou employ Code Division Multiple Access (CDMA) signal technologies, whereas GLONASS will have both CDMA and Frequency Division Multiple Access (FDMA).

Chapter 2 Background, Relevant Literature and Related Work

Pertaining to the summary presented in Chapter 1, Table(s) 2.1, 2.2 and 2.3 list some of the characteristics of satellite-based positioning and augmentation systems.

Table 2.1 Satellite-based positioning systems (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012).

Operating Operating Transmission Transmission GNSS Description Orbit Types Planning, Operation and Upgrade Status Entity Satellites Technologies Band Global Positioning L1, L2, L3, Fully operational with continuous and GPS USA 28-31 MEO CDMA System L4, L5 periodic revisions Global'naya Navigatsionnaya GLONASS Russia 24 MEO FDMA-CDMA Fully operational since 2011 Sputnikovaya Sistema European Space Galileo Europe 30 MEO CDMA Operation and planning for 2013 and 2014 Agency System Chinese Navigation MEO, GEO, BeiDou China 35 CDMA Expected to start operating in 2015 System HEO

2.2.2 Regional Navigation Satellite System (RNSS)

RNSSs augment the functionality of GNSSs. China’s Beidou is currently an RNSS that provides coverage limited to China and surrounding region. Japan’s RNSS will be based on the Quasi Zenith Satellite System (QZSS) to provide extra GNSS-like functionality. QZSS is actually a Space Based Augmentation System. Japan’s RNSS will ultimately have 7-9 satellites in HEO. The Indian RNSS will also consist of 7 satellites in GEO or HEO.

Table 2.2 RNSS positioning and satellite augmentation systems (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012).

RNSS Regional Navigation Satellite (Augmentation) Systems Chinese Regional 4 (Beidou-1) MEO, GEO, Beidou China CDMA Partly operational System 35 (Beidou-2) HEO Doppler Orbitography and French civil precise orbit determination and positioning system based on the DORIS France Radio-positioning principle of the Doppler effect Integrated by Satellite Indian Government IRNSS India Initiated and 7LEO Indian space based augmentation system Controlled Quasi-Zenith QZSS (Japan) Japan QZSS, launched in 2010 Satellite System

Chapter 2 Background, Relevant Literature and Related Work

2.2.3 Satellite Based Augmentation System (SBAS)

SBASs were originally developed in order to augment GNSS functionality for aviation purposes through the use of additional satellite broadcast messages. SBASs provide improved availability, integrity, accuracy and/or continuity of positioning services. Examples include WAAS (US), EGNOS (EU), MSAS (Japan) and GAGAN (India).

Table 2.3 SBAS satellite-based augmentation systems (Diggelen et al., 2009; Harper et. al., 2007; DORIS, 2012; Navcen, 2012; NASA, 2012; ESA, 2012; GLONASS, 2012).

SBAS SBAS, multiple regional systems: WAAS, EGNOS, GAGAN, MSAS with varying levels of operational readiness

GPS aided geo augmented navigation or GPS GAGAN India 1 Indian Satellite based Augmentation System in planning. and geo- augmented navigation Multi-functional MSAS Japan Satellite 2 Japanese Satellite based Augmentation System similar to SBAS in North America Augmentation European Geostationary EGNOS Europe 3 Initial Operations started in 2005, Fully operational since 2009. Navigation Overlay Service Wide Area Augmentation WAAS USA 38 38 Wide Area Reference Stations (WRN) Expected Operational since Oct 2007 System for North America

2.3 NAVSTAR Global Positioning System (GPS)

GPS is a three-dimensional satellite radio-positioning, velocity and time-transfer system developed by the U.S. Department of Defense (DoD) to support real-time global navigation (Parkinson and Spilker, 1996). The system consists of three segments, referred to as the Space Segment, User Segment and Control Segment.

The Space Segment consists of a constellation of up to 32 satellites Ð the number of operational space vehicles at any one time will vary due to operational reasons, routine maintenance and component failure. They operate in six circular orbital planes at an altitude of about 20,200 km above the Earth’s surface (i.e. MEO), with an orbital inclination of 55 degrees, and a guaranteed visibility of four or more satellites by a user receiver at any geographical location on a 24/7 basis. The ground facilities making up the Control Segment undertake satellite tracking, perform orbit computations, telemetry and supervisory functions to ensure operational continuity of Space Segment, with a number of ground monitor and telemetry stations distributed globally. The User 21

Chapter 2 Background, Relevant Literature and Related Work

Segment comprises the end-user devices making timing and navigation capability available to all user communities.

2.3.1 GPS Signals

Modernised GPS satellites transmit unique navigational signals on three L-band frequencies designated as L1, L2 and L5, although older generation satellites only transmit on the L1 and L2 frequencies.

2.3.1.1 L1 (1575.42 MHz)

The L1 signal is a combination of navigation message, coarse-acquisition (C/A) code, encrypted precision P(Y) code, and in the case of GPS Block IIR-M and GPS IIF satellites the military (M) code as well. L1C will be the new range code on the L1 signal for civilian use (IS-GPS-800), to increase interoperability with other GNSS (in particular Galileo). L1C is expected to be transmitted on the new Block III satellites scheduled to be launched from about 2015.

2.3.1.2 L2 (1227.60 MHz)

The L2 signal is modulated with the encrypted P(Y) code. L2C has been broadcast by GPS Block IIR-M satellites since 2005 (IS-GPS-200D). Transmission of two L-band signals by GPS same satellites helps mitigate the ionospheric delay.

2.3.1.3 L5 (1176.45 MHz)

The L5 is a new frequency signal that was first broadcast by GPS Block IIF satellites (from 2009). It was originally intended for international aeronautical navigation (WRC-2000 frequency band) and has also been proposed for civilian safety-of-life (SoL) purposes (IS-GPS-705). With improved signal structure for enhanced performance it has a higher transmit power (> 3dB) than both L1 and L2, higher accuracy and reliability, wider bandwidth, longer spreading codes and better interference resistance.

Chapter 2 Background, Relevant Literature and Related Work

2.3.2 GPS Signal Components

The signals listed above basically consist of three components: the L-band carrier frequency, modulated navigation message, and modulated ranging or spreading codes. The navigation message carries orbit (ephemeris), satellite clock error, satellite status and miscellaneous information. The ranging codes consist of:

¥ Coarse-Acquisition (C/A) Code ¥ Precision (P) Code ¥ M-Code ¥ L1C, L2C and L5 Codes (I5 and Q5)

Different codes on modulated on different carrier frequencies, and transmitted by different generations of GPS satellites.

2.3.3 GPS Measurements

Pseudorange, carrier phase and Doppler frequency are the fundamental types of GPS measurements for positioning. In general most civilian users can get GPS positioning accuracy of the order of a few metres, in real time, using the broadcast navigation message. GPS positioning modes can be grouped into several categories with varying accuracy and operational considerations:

a. Pseudorange-based single point positioning b. Relative or differential (DGPS/DGNSS) positioning c. Carrier phase-based “real time kinematic” (RTK) differential positioning d. Carrier phase-based “precise point positioning” (PPP)

2.3.4 GPS (GNSS) Error Sources

Error sources associated with GPS (and GNSS in general) include satellite orbit, satellite clock, Ionospheric and tropospheric delay (or refraction), multipath disturbance, receiver clock and the antenna phase centre errors. These are illustrated in Figure 2.1.

Chapter 2 Background, Relevant Literature and Related Work

Figure 2.1 Graphical representation of GPS/GNSS error sources (Weston et al., 2010).

2.3.5 GPS Satellite Clock

GPS time (GPST) is maintained through a “composite clock” constituted by the Control Segment monitoring station ground clocks and the frequency standards (or clocks) on-board each satellite. The GPS “master clock” is synchronised with the United States Naval Observatory (USNO) realisation of universal time coordinated (UTC). This ensures the time difference between GPST and UTC(USNO) is maintained to less than 1 microsecond, apart from an integer number of “leap seconds”. The navigation message contains parameters to specify the time offset and drift rate between GPST and UTC(USNO) (Weston et al., 2010).

2.3.6 GPS Message Format

ICD GPS-200 and revisions specify the navigation message content, including:

• Telemetry (TLM): this field is used for synchronisation and maintenance. The field length is 30bits.

Chapter 2 Background, Relevant Literature and Related Work

• Handover Word (HOW): contains the time at the beginning of next sub-frame, sub-frame ID, flagging and parity bits. The field length is 30bits. • Ephemeris and Satellite Clock corrections contained within the first 3 sub-frames. Almanac: location, time and orbit information of the whole GPS constellation. The field is spread over 25 frames of the message.

Other data: includes ionospheric and UTC clock corrections.

Figure 2.2 illustrates the GPS message format. .

Figure 2.2 GPS message format (Wang, 2008).

2.3.7 CNAV and MNAV

The CNAV data is an upgraded version of the original navigation message (NAV), containing higher precision (and nominally more accurate) data than the NAV. The same type of information (i.e. time, status, ephemeris, and almanac) is still transmitted using the new CNAV format. However, instead of using a frame / sub-frame architecture (Figure 2.2) it features a new pseudo- packetised format consisting of 12-second 300-bit message packets. A major component of the GPS “modernization” process is a new military ranging code (M-code) designed to improve anti- jamming and to secure access of the military GPS signals. Little has been published about this restricted code though it is known to contain a PRN code of unknown length transmitted at

Chapter 2 Background, Relevant Literature and Related Work

5.115 MHz. Unlike the P(Y)-code, the M-code is designed to be autonomous, meaning that a user can calculate their position directly using only measurements made on the M-code. This is in contrast to the P(Y)-code which requires first that military users lock onto the C/A code and then transfer the lock to the P(Y)-code. However, direct-acquisition techniques were later developed that allowed some (suitably equipped) users to operate autonomously with the P(Y)-code. The new navigation message (MNAV) is similar to CNAV, also being packetised. As with the CNAV, MNAV utilises forward error correction (FEC) and advanced error detection (CRC).

2.4 Indoor Positioning Techniques

Olivetti Research Laboratory developed an “Active Badge Location System” in the 1980s for indoor positioning (Want et al., 1992). The subject of interest would carry a “badge” capable of emitting a globally unique beacon identifier signal. The system is based on diffuse infra-red technology with a range of several metres, hence the technology has obvious limitations operating in rooms lit by fluorescent lighting or in direct sunlight. The performance of the system is compromised with differences in indoor materials such as walls, doors and ceilings, which cause variations in signal absorption.

A “Bat Location System” was developed by the AT&T Labs in the 1990s. It was based on ultrasonic transducers employing time-of-flight trilateration technique to provide better accuracy than the active badge system (Ward et al., 1997; Harter et al., 2002). The “Bat” emitters were carried by the subject of interest and radio transmission was controlled by a radio transceiver. A radio base station would periodically transmit unique identifiers to cause Bat units to respond with an ultrasound signal, which is received by ultrasound receivers deployed across the area of interest. The receivers then calculate the time-of-arrival of signals using the speed of sound in air and convert the time-of-flight measurement Ð of the ultrasound pulse from the Bat to receivers Ð into Bat-receiver distance(s). Harter et al. (2002) reports that the system can provide an estimate of the Bat’s location with 10cm accuracy around 85% of the time. However the requirement for large- scale deployment of sensor infrastructure meant it was difficult to scale up the coverage area. The “Cricket Location-Support System” was developed by the MIT CS Lab, also using ultrasonic signals (Priyantha et al., 2000). It uses a combination of RF and ultrasound transceiver technology to estimate the difference in transmit and receive times and hence calculate location. Despite the aforementioned benefits, the system cannot achieve a granularity (approx.16 square ft.) exceeding

Chapter 2 Background, Relevant Literature and Related Work

that of the Bat system. However development was motivated by concerns for user privacy so as to operate in a decentralised mode (Li, 2006).

A system known as “Easy Living” was developed by the Microsoft Research Vision Technology Group (Krumm et al., 2000). It utilised two wall-mounted pc-connected colour Triclops stereo cameras. The technology employed registration of images from the cameras to calculate background differences to determine the location of 3D objects in each camera’s scope of view. The system used knowledge of camera relative locations and fields of view to employ the triangulation technique. However its reliance on installed infrastructure, processing power and pervasive camera set-ups makes it non-viable for large area coverage. A system known as “MotionStar Magnetic Tracker” employs electromagnetic sensors (Anisfield, 2000). The “Smart Floor System” uses pressure sensors (Kaddourah et al., 2005).

Many other RF, magnetic or ultrasonic systems have been developed over the last two decades. Only a few have been highlighted here. All require some form of installed infrastructure. There has also been considerable research activity focused on technologies that do not use specially installed transmitters, receivers or transceivers.

WiFi has become a widely used localisation technology. It can be used to determine position in environments where GPS/GNSS cannot perform. such as indoors. WiFi infrastructure is nowadays ubiquitous, but not specifically provided just to support the positioning function. The “fingerprint” based techniques perform well indoors (Li et al., 2008). However despite an abundance of WiFi access points in urban areas, inconsistent signal strength can be observed, yielding unreliable readings and degraded positioning performance. Nevertheless WiFi positioning systems enrich the variety of available positioning methods and are particularly suited for indoor positioning (Wang et al., 2003).

Many aspects need to be considered for positioning via communication systems such as WiFi, Bluetooth, IrDA and RFID. IrDA has range and line-of-sight issues and is not discussed further. Though RFIDs may not withstand harsh conditions and may have communication difficulties (Chon et al., 2004), they are relatively inexpensive and can provide high accuracy positioning information. Nokia have developed a Bluetooth Assisted GPS (BAG) (Wirola, 2006). Bluetooth chipsets are common and Bluetooth devices can easily create multiple small networks, thus increasing the position sharing sources (Hallberg and Nilsson, 2002). 27

Chapter 2 Background, Relevant Literature and Related Work

WSNs can have some limitations with respect to power and processing capacity, depending on the implemented algorithms. However they can be helpful in scenarios for emergency positioning where infrastructure based or pre-deployed network facilities may not be available. WSNs can achieve 50th and 80th percentile(s) accuracies of 0.9m and 1.6m, respectively. They can tolerate up to 60% beacon nodes failure and 50% signature perturbations, with negligible increase in error (Konrad et al., 2007). They can operate in an independent, adhoc or autonomous manager mode, and can be used as direct positioning or as position-aiding devices.

2.5 Outdoor Positioning Techniques

In general testing scenarios of devices or technologies to support Location Based Emergency Services (LBES) can be classified as open sky, urban, suburban, rural and indoors (Li et al., 2009). The worst-case scenario for GPS can generally be categorised as “indoors”, where there are few (if any) signals reception. Although a conventional GPS receiver takes perhaps a minute or more to compute its first position fix (Li et al., 2009; Diggelen, 2009), different government mandates such as the US E911 (911 Service, 2009) require that more than 95% of mobile callers have their locations determined within the first few (15-20) seconds.

Emergency Position Indicating Radio Beacons (EPIRBs) transmit location and tracking beacon signals at intervals of time. They can be used for tracking, sending distress signals and locatisation. There are different categories of EPIRBs operating in the frequency range 121.5-406MHz. Some of these frequencies have been phased out of service recently. Emergency Location Transmitters (ELT) are mainly used for military applications. Personal Locator Beacons (PLB) are used in maritime applications. Most of these devices use the Cospas-Sarsat system established in 1979. The system consists of satellite and ground terminals capable of responding immediately to beacon signals from EPIRBs, PLBs and ELTs.

Garmin eTrex (Garmin, 2005) is a “standard sensitivity” receiver (signal approximately -120dBm) that is in common use. It can often be employed to benchmark the relative performance of other GPS devices such as SPOT’s Nemerix NX2/NJ1030. Detailed analysis of the performance of SPOT is discussed in Chapter 3 (Note: SPOT Messenger Technical Datasheet can be found in Appendix F).

Chapter 2 Background, Relevant Literature and Related Work

There are many companies (CanadaGPS & TrackingTheWorld, 2010) that market GPS-based tracking and positioning applications. Devices include WorldTracker Enduro, G.P.S Letter Logger, Global Asset Tracker, WorldTracker PLD, Covert/Personal GPS Locator Device, Private Label GPS Tracking Websites, WorldTracker GPRS, TrimTrac, Covert GPS Data Logger, WorldTracker SMS, Inmarsat D+ WorldTracker, GSM / GPS Antennas, WorldTracker AVL, WorldTracker Pro, WorldTracker RF, Portable Covert Video Camera, and others. Some solutions are sold as stand- alone devices although their performance is limited. For example, they may need to be tethered for communications with smartphones or wireless modems. User activation may be needed to effectively report paging status or location information.

2.6 Mobile Phone/Network Positioning Techniques

Mobile phone-based positioning is one of the widely used localisation techniques. First generation mobile phone networks were developed for basic on-the-move communications in the 1980s. However, with the transition of technology from 0G-4G, today’s so-called “smartphones” are now used for internet browsing, creating personal area network (PAN), music or video playback, diary keeping, emails and social networking, and have largely replaced the use of separate devices for alarms/clocks, cameras, portable gaming consoles, radio, mobile TV, electronic reader, dictionary, and many more. Mobile handsets are now the primary personal devices that require positioning for LBS or LBES. Apart from using the on-board GPS, or WiFi, cellular phone positioning relies on measuring signal characteristics such as Received Signal Strength (RSS), Time Advance (TA), Angle-of-Arrival (AOA), Cell-ID, Time-of-Arrival (TOA), or Time Difference of Arrival (TDOA), of the radio signals exchanged between the mobile station (MS) and one or more base transceiver stations (BTS) (Rappaport et al., 1996).

Considerable research has focused on using the mobile phone network for positioning, and government mandates such as the US Enhanced 911 (E911) directive have helped drive the process. Phase I of the E911 program required operators to report the telephone number and location of the caller. In Phase II the positioning accuracy requirements became more stringent:

• 100m for 67% of calls and 300m for 95% of calls for so-called “network-based” solutions. • 50m for 67% of calls and 150m for 95% of calls for so-called “handset-based” solutions.

Chapter 2 Background, Relevant Literature and Related Work

Other countries have similar mandates (e.g. EU’s E112).

2.6.1 Cell ID based Positioning

Cell ID is a simple and cost-effective localization method which does not require network or user terminal upgrade. A BTS usually broadcasts messages containing the Cell ID to the MS. On knowing the Cell ID, a MS can calculate its location using the geographical coordinates of the serving BTS. However, Cell ID suffers from an inherent lack of accuracy (Laitinen et al., 2000; Frédéric, 2002) due to inconsistencies in cell sizes. As an example, the dimension of a pico-cell is less than 100m across, while that of a macrocell may be 35km or more (Holtzman and Goodman, 1993). Furthermore, cell sizes may change due to interference, subscriber traffic and antenna sensitivity. The technique can be enhanced with sectored sites returning the “centroid” of the sector coverage area as the estimated caller’s location (see Chapter 5). There are several techniques that can be employed to improve the accuracy of mobile positioning which are discussed in Chapters 4 and 5). Figure 2.3 illustrates the principles of Cell ID based positioning.

Figure 2.3(a, b) Cell ID based positioning (Li, 2006).

2.6.2 Time Advance (TA) based Positioning

Time Advance (TA) is a means of measuring the approximate time a signal takes from the MS to the BTS. According to Drane et al. (1998), the resolution of TA is half a GSM bit (one GSM bit has 30

Chapter 2 Background, Relevant Literature and Related Work

a duration of 3.69 µs), which equates to 550 metres of distance. A similar measurement in the Universal Mobile Telecommunication System (UMTS) and Frequency Division Duplex (FDD) is the Round Trip Time (RTT) (SnapTrack, 2003). Because Cell ID is always known and TA is only available in dedicated mode, the MS location estimate is usually at the TA range in the direction of the sector antenna. The accuracy typically ranges between 500m to 4km. Figure 2.4 illustrates the TA based positioning technique.

Figure 2.4 TA based positioning (Li, 2006).

2.6.3 Received Signal Strength (SS) based Positioning

‘Received Signal Strength (RSS) measurements’ for the purpose of calculating position is a well- known technique (Laitinen et al., 2000). For example, RSS of control channels in GSM and that of the pilot channel in W/CDMA (Wideband/Code Division Multiple Access) can be measured and the distance between the MS and the BTS can be estimated with relative ease. In a free-space propagation model, the signal loss prediction can be comparatively precise on the assumption that the signal level contours around the transmitter are circular. RSS of three BTS need to be measured in order to estimate the location of the MS Ð at the intersection of the transmitter circles. Japanese operators started using localisation systems based on RSS in the 1990s (Koshima & Hoshen, 2000).

More complex propagation models differ from free-space propagation, as environmental-dependent effects are taken into account. Some empirical models are specified by Hata (1980) and Lee (1993). Developing realistic empirical models can be challenging due to environmental dynamics. One model may perform well in some environments but poorly in others. Multipath fading and shadowing have been identified as major problems in accurately estimating the BTS-MS distance from RSS measurements. It is possible to smooth out fast-fading effects by averaging the RSS over some time and frequency band. However, random variations caused by shadowing cannot be easily

Chapter 2 Background, Relevant Literature and Related Work

compensated for (Li, 2006). The accuracy of the RSS technique is similar to that of the TA technique. Figure 2.5 illustrates the RSS based positioning technique.

Figure 2.5 RSS based positioning (Li, 2006).

2.6.4 Angle of Arrival (AOA) based Positioning

Using signal processing techniques, the direction and Angle-of-Arrival (AOA) of a MS with respect to the BTS can be measured. Localisation techniques based on signal timing or AOA measurements have been proposed by Drane et al. (1998). Two AOA measurements with respect to different BTSs can define the location of the MS at the intersection of apparent arrival directions (Figure 2.6).

Figure 2.6 AOA based positioning (Laaraiedh et al., 2011).

Real world implementations of this technique are limited due to issues such as interference, multipath and non-line-of-sight (NLoS) errors, despite higher accuracy possibilities in urban areas (Caffery and Stuber, 1998b). While the MS device is unchanged, significant antenna and network infrastructure is required. Figure 2.6 illustrates AOA based positioning.

2.6.5 Time of Arrival (TOA) based Positioning

The Time-of-Arrival (TOA) technique employs the intersection of distance circles to determine the mobile phone position. Radio propagation time when multiplied by the speed of EMR propagation, gives an estimate of the distance of the MS to each BTS transmitter. Principles identical to the RSS techniques are employed to calculate position in 2D and 3D space, with appropriate clock

Chapter 2 Background, Relevant Literature and Related Work

synchronisation. Some networks are synchronised using GPS and internal clocking sources. Several clock sources are discussed in detail in Chapter 5. The TOA-based technique has a simple elegance, however its shortcomings can be difficult to eliminate in practice (Drane et al., 1998). Figure 2.7 illustrates the TOA based positioning technique.

Figure 2.7 TOA based positioning (Laaraiedh et al., 2011).

2.6.6 Time Difference of Arrival (TDOA) based Positioning

Another commonly used technique in terrestrial positioning is based on Time-Difference-of-Arrival (TDOA), which employs time difference measurements - as opposed to absolute time measurements in TOA. TDOA can eliminate the effects of unsynchronised handset time on positioning. It is a hyperbolic technique as the time difference is converted to differential distance between two BTS thus forming a hyperbolic curve (Bakker et al., 1989). Position is determined as the intersection of two hyperbolas, utilising two pairs of base stations (Figure 2.8).

Chapter 2 Background, Relevant Literature and Related Work

Figure 2.8 TDOA based positioning (Laaraiedh et al., 2011).

One technique in UMTS is based on Uplink TDOA (U-TDOA) (True Position, 2006), and another is Observed TDOA (OTDOA) (3GPP, 2005). In GSM, the equivalent technique is called Enhanced Observed Time Differences (E-OTD) (3GPP, 2004; CPS, 2006). In CDMA, the technique is referred to as Advanced Forward Link Trilateration (AFLT) (3GPP2, 2001). These techniques are further discussed in Chapter 5.

2.6.7 Fingerprinting

AOA, TOA or TDOA can achieve relatively higher accuracy, although multipath can substantially degrade performance (Li et al., 2006). Fingerprinting employs NLOS propagation and multipath for positioning. Initially the area of interest is grid surveyed to record specific characteristics such as RSS (impacted by multipath). The technique consists of a “training” phase, followed by “positioning”. However the creation and maintenance of the associated database of RSSs across a coverage area can be a significant challenge. Commercial implementations of fingerprinting based techniques such as RadioCamera (Wax and Hilsenrath, 2000), and Database Correlation Method (DCM) (Laitinen et al, 2001) have been proposed.

2.7 Assisted GNSS

Zhao (2002) lists four principal functions of a GNSS receiver:

Chapter 2 Background, Relevant Literature and Related Work

a. Measure distances from the satellites to the receiver by determining the pseudoranges (or “code phases”). b. Extraction of TOA in GPS Time with the aid of the satellite navigation message. c. Computation of position of transmitting satellites using ephemeris data at indicated TOA. d. Calculating the receiver’s position by using the measured pseudorange, timing and navigation message data.

In general, a GNSS chipset for LBS or LBES applications encounters two problems:

a. Long start-up time due to the need to decipher the navigation message and acquire comparatively weak signals. b. High power dissipation reducing the unit’s processing and radio sensitivity performance and battery life.

An “assistance” device or server is connected to a base station GNSS receiver to obtain timing and navigation data. The navigation data can then be transmitted to mobile receivers obviating the need for the user receiver to decode the navigation data. This can improve the speed of the positioning process Ð referred to as the Time-to-Fix-First (TTFF) Ð by up to 30 seconds. In addition, assistance messages can provide information on satellite visibility and their predicted signal Doppler shift. The assistance server can also provide processing assistance and differential GNSS correction messages, thus improving positioning accuracy. Assisted-GNSS (AGNSS) can be implemented as a handset- based solution (Sarwar et al., 2011) or a network-based solution, with raw measured pseudoranges being transmitted to a computation server (Rizos, 2005).

There are two primary types of AGPS techniques, apart from network-based solutions:

a. MS-Based (MSB), the mobile station makes most of the measurements and performs the position calculation. b. MS-Assisted (MSA), the assistance server makes the measurements and carries out the position calculation.

Each technique has its respective advantages and disadvantages which are discussed in Chapters 4 and 5. A number of organisations, such as 3GPP and OMA, are working to standardise AGNSS, discussed further in Chapter 7. 35

Chapter 2 Background, Relevant Literature and Related Work

Note: Miscellaneous non-GPS/GNSS positioning techniques are mentioned in Appendix I.

2.8 Open Source GNSS Reference Server (OSGRS)

2.8.1 Architecture

The Open Source GNSS Reference Server (OSGRS) is intended to provide multi-constellation AGNSS client assistance information free of proprietary protocols. OSGRS exploits the GNSS Reference Interface Protocol (GRIP) and was first released in 2007. The assistance can be both for aiding acquisition and for processing the received navigation signals. Data transfer protocol is based on Extensible Mark-up Language (XML) schema with its Java based software architecture allowing felxible software module integration. The first version of OSGRS required a hardware connected GNSS source to acquire and store the assistance data. Chapter 4 describes the development of an upgraded version of OSGRS which provides alternative assistance support from a network of GNSS receivers employing the Networked Transport of RTCM through Internet Protocol (NTRIP). The third generation of OSGRS is discussed in Chapter 5, where the augmentation of LPP and LPPe based LTE mobile network is proposed.

2.8.2 Operation

OSGRS processing can be distributed across several machines to achieve optimum performance for AGNSS, and can operate on a variety of platforms. The assistance data can be of generic or specific types depending upon the client requests. The overall system architecture is client-server based and the client can be a mobile or fixed AGPS/GNSS capable device. Different server configurations cater for the different types and number of available GNSS sources that may be selected.

2.8.3 CORS OSGRS Licensing and Technical Support

The School of Surveying & Geospatial Engineering, UNSW operates a Continuously Operating Reference Station (CORS) for research on AGNSS and other projects. The OSGRS is licensed by the General Public Licence GPL (GNU 2007). Its licence allows modification and enhancements to hardware and software systems with minimal legal constraints. Technical support is available from key contacts involved in the project. 36

Chapter 2 Background, Relevant Literature and Related Work

The next generation OSGRS development was motivated by the limitations mentioned in Chapter 1 and discussed further in Chapter 4. The hybrid Multi-GNSS architecture presented in Chapter 3 provides the foundation for the upgrade of OSGRS described in Chapter 4. Chapter 5 builds on the architecture presented in Chapter 4 and discusses further upgrades to the system.

2.8.4 CORS OSGRS Expansion Potential

The OSGRS data transfer takes place via TCP/IP protocol and can transport assistance data through mobile communication channels. Hence networks such as GSM, GPRS, EDGE, UMTS or LTE can be employed for such purposes. Experiments conducted by Heo et al. (2007) and Yan et al. (2006) and simulations carried out by Li et al. (2007) have demonstrated performance of OSGRSv1.

2.9 Network Transport of RTCM via Internet Protocol (NTRIP) (Screenshots/Results are Author’s Contribution unless highlighted otherwise)

2.9.1 Architecture

NTRIP is one of the most widely-used protocols for distributing real-time GNSS data over the Internet Protocol (Lenz, 2004). Results have confirmed that the system performance can comply with the rigorous end-user requirements for centimeter-level accuracy “real time kinematic” (RTK) GNSS applications. Typically data latencies of about 2 seconds are observed. However, several exceptional samples demonstrated latency of approximately 3 seconds which can make carrier phase ambiguity resolution very challenging or even impossible (Yan et al., 2009). Figure 2.13 illustrates the NTRIP system architecture.

NTRIP is a stateless protocol based on the Hypertext Transfer Protocol (HTTP/1.x) which can be modified to work with subsequent versions of HTTP (BKG, 2007). The HTTP objects are enhanced to acquire broadcast GNSS data streams.

Disseminated differential correction data in formats such as RTCM (Radio Technical Commission for Maritime Services) SC104 can be acquired by clients with an IP connection. Wireless Internet access is supported through mobile, wireless and/or IP networks such as GSM, GPRS, EDGE,

Chapter 2 Background, Relevant Literature and Related Work

WiMax or UMTS. NTRIP is implemented in three system software and/or hardware components (Figure 2.9):

a. NTRIP Clients b. NTRIP Servers c. NTRIP Casters

Figure 2.9 NTRIP architecture, (GeoInfo, 2010).

The “NTRIP Caster” is the actual HTTP server module, while the “NTRIP Client” and the “NTRIP Server” integrate as HTTP client modules. NTRIP Caster(s) maintain a source table containing metadata describing the available GNSS data streams. The source table may also contain information about networks of data streams - the IP address and port of the NTRIP Caster, as well as IP addresses and ports of other NTRIP Casters (BKG, 2007). (BKG is the German language acronym for the German Federal Agency for Cartography and Geodesy.) The NTRIP Client receives the source table to enable a user to choose an appropriate data stream.

NTRIP is well suited to providing access to mobile users with dynamic IP addresses, despite its processing and memory overheads. The caster does not require the IP details to be known prior in client-initiated connections. A classic example can be the Reverse-RTK application (Rizos &

Chapter 2 Background, Relevant Literature and Related Work

Cranenbroeck, 2006; Rizos, 2007) which would require the client to establish a bi-directional adhoc connection to a server. NTRIP is discussed in more detail in Chapter 4.

2.9.2 Load Balancing and Scalability

Typically a single NTRIP Caster can serve up to 200 streams with a 1000 concurrent clients connected. A few techniques can be employed to address the challenge of the growing number of streams and users. One way is to establish regional broadcast services such as those operated by Geoscience Australia, UNSW, the EUREF network in Europe, PBO in the USA and SIRGAS in South America. Weber (2008) proposes community specific measures to establish thematic rebroadcast services, with specific orbits, clocks and atmosphere model products.

2.9.3 GNSS Transmitted Data Security

NTRIPv1 had authentication issues because the NTRIP Caster only provided one global password for all NTRIP Servers attempting to connect. Such a mechanism did not provide a means to authenticate a particular server, mount-point or stream - as malicious or misconfigured servers may connect or upload erroneous data to it. Also, the plaintext unencrypted global passwords that were used were highly susceptible to packet sniffing during transmission over the network. NTRIPv2 resolved this issue by assigning unique encrypted username and password credentials. Data encryption services are provided by operators and users before uploading onto NTRIP systems.

2.9.4 GNSS Data Integrity

There are two main causes of data errors in a packet-switched network:

a. Out-of-order packets (errors can be mitigated using sequence numbering). b. Lost packets (errors can be mitigated using acknowledgement and retransmission).

Because both of the above mitigation mechanisms can be provided by TCP, NTRIP is not susceptible to such errors.

Chapter 2 Background, Relevant Literature and Related Work

2.9.5 System User Acceptance

NTRIP users, operators and clients have grown significantly since its introduction in 2003, and acceptance as a RTCM standard in 2004 (Dammalage et al., 2006). http://rtcm-ntrip.org website logs the known NTRIP Caster installations and data streams, which now numbers hundreds of caster installations with thousands of streams. Implementations of the NTRIP Client, Server and Caster are available from http://igs.bkg.bund.de/ntrip/ntrip_down.htm for various operating systems such as Windows 32-bits, Windows Mobile, UNIX and Mac OS X, in multiple programming languages such as C/C++, Java and Perl. NTRIP supports commercial software and hardware from major manufacturers such as Trimble, Leica, Topcon, Thales and Javad.

2.9.6 Multi-GNSS Positioning Quality

Unlike a post-processed operation, the positioning algorithm may sometimes be constrained in real- time operation. For example, the post-processed positioning algorithm can analyse the whole data set and perform quality control procedures (such as cycle slip detection and improved satellite selection based on availability and detect any multipath effects). However, a real-time positioning algorithm performs without “future” knowledge. Communications links employed in real-time operation often introduce losses and latency in data transfer thus affecting the performance of the algorithm (Dammalage et al., 2006).

2.9.7 NTRIP Multi-GNSS Configuration and Operation

This data is input to OSGRS to be cached to serve non-periodic or scheduled client requests. Relevant login credentials (if applicable) must be supplied by the user where applications are made directly to relevant caster administrators, and are granted based on third party discretion. The server is executed and connection is made to the preconfigured GPS or GNSS receiver or caster. The OSGRS client takes the input parameters from the user and tries to communicate to the server through an XML parser. Once the request is validated the server responds with relevant data cached from the appropriate sources according to the client input parameters.

After downloading the source table, setting up the session parameters and pressing the start button, the software connects to the NTRIP Caster and writes the received GNSS data stream to a serial or IP port until the session is stopped. Last session parameters are stored locally in a file called 40

Chapter 2 Background, Relevant Literature and Related Work

GNSS.ini. The file contains parameters such as IP:port, userID:password and COM-port settings. A file sourcetable.dat is maintained as data is received from the NTRIP Caster (NTRIP, 2007). It contains Caster, Network, and Stream information as shown in Figures 2.16 and 2.17. Several NTRIP Clients are configurable and authorised by BKG to source the NTRIP Caster information. Figure 2.10 shows the client interface of the NTRIP GNSS Internet Radio (GIR).

Figure 2.10 NTRIP Client interface.

Note: NTRIP Radio User Settings are presented in Appendix H.

NTRIP supports Virtual Reference Station (VRS) precise positioning mode, which requires that the user receiver can send its approximate position in National Marine Electronics Association (NMEA) format through the GIR to a NTRIP Caster. In response, an NTRIP Caster supporting the VRS mode can provide a user-specific data stream for that approximate position. A GPS/GNSS source can be directly connected to communicate using the NMEA format. The VRS data stream can also be sourced from NTRIP servers without a GPS or GNSS receiver locally connected. Approximate position is to be input through the ‘man GGA’ option for the function enablement. The NTRIP Client can then generate the NMEA-GGA output, and respond back to the NTRIP Caster (NTRIP, 2007).

2.9.8 Raw GNSS Data Acquisition

RTCM streams become available through the ethernet or serial ports and a decoder is needed for use with clients processing RINEX or ASCII data formats. Some decoders read the serial or IP ports but cannot decode all incoming message types from casters. The blue screen on the right hand side of Figure 2.11 shows the data being retrieved continuously from the serial/IP port.

Chapter 2 Background, Relevant Literature and Related Work

Figure 2.11. a. Binary/raw data NTRIP stream. b. Decoder configuration screen.

2.9.9 BNC Application

The BKG NTRIP Client has been developed under the GPL by the German Federal Agency for Cartography and Geodesy (BKG, 2007). Being a multi-stream client program, it can retrieve real- time GNSS data streams through various global sources, broadcast using the IP, and generate RINEX3.x or RTCM3.x data streams. Figure 2.12 shows the client interface of the BNC client v2.6, which is the latest release (May, 2012).

Chapter 2 Background, Relevant Literature and Related Work

Figure 2.12 BNCv2.6 client interface (http://igs.bkg.bund.de/ntrip/download).

Open source code is available for the following clients for development purposes (http://software.rtcm-ntrip.org/):

a. BNC b. BNS (replaced by BNC) c. POSIX ntripserver d. POSIX ntripclient e. rtcm3torinex

The NTRIP source tables specify the data provided by a caster and consists of three types of records (http://software.rtcm-ntrip.org/wiki/Sourcetable):

a. CAS - caster specification records b. NET - network specification records

Chapter 2 Background, Relevant Literature and Related Work

c. STR - stream specification records

2.9.10 Multi-GNSS Acquisition

Two separate Java code fragments were developed for multi-GNSS support. These acquire data from the cache, local ports and live streams to support real-time processes or for a delayed response. When the user selects the appropriate NTRIP1/2 stream from the user interface (Figure 2.21), the request is XML parsed and validated by the server. If a valid source is connected and response is available, the data is then sent to the client, otherwise an error response is displayed. Data is acquired in RINEX and RTCM formats. RINEXv3.0 incorporates new observation types, possibly to track frequencies on different channels, provide flexible and more detailed definition of the observation codes from different GNSS, RNSS or SBAS constellations (RINEX3, 2007).

2.9.11 Multi-GNSS File Types

The RINEXv3.0 format consists of three ASCII file types:

a. Observation data File b. Navigation message File c. Meteorological data File

The OSGRS client is executed after error-free compilation and building of Java code. As NTRIP data has been requested by client, the OSGRS server responds by querying the preselected caster. This data can be a real-time incoming stream or periodically cached on hard-drive.

2.9.12 Acquired Parameter Translation (Multi-GNSS Client-End Interface) (Author’s Contribution)

Once the selection of appropriate options has been done, the user can press the send button to periodically retrieve cached information from the server. The server URL information is the IP address to which the OSGRS server is connected. Position information is optional and could help the server in providing more accurate assistance information. In this example we wish to acquire the NTRIP data from stream1 as selected in Figure 2.21. The system returns the relevant positioning data in the translated RINEXv3.0 format. The following parameters are relevant in this example: 44

Chapter 2 Background, Relevant Literature and Related Work

• XML schema details: v1.0 • FileType: O or 0 for observation data e.g.ACOR0*.* • Encoding Details: utf-8 • School details: gmat.UNSW • XML specification ref.: W3C • GRIP Protocol Ver.: 1.5 • GNSS communication details: GPS and NTRIP • NTRIP Interface: BNC • End-User Id: asarwar • Date: 2011 02 06 • Mountpoint/MarkerName: Acor0* • MarkerType: Geodetic • MarkerNumber: 13434M001 • Rec.Number: 459187 • Rec.Type: LeicaGRX1200Pro • Rec.Ver.: 8:00/2.125 • Antenna No.: 103033 • Antenna Type: LEIAT504 • Antenna Coding: LEIS • Antenna Approx. Position (x,y,z): 4594489.9390,-678368.0730,4357065.9000 • Antenna Delta H/E/N: 3.0460,0.0000,0.0000 • Observer /Agency: Pedro Gonzalo Lopez IGN-E • Observation type: 8 C1 C2 P1 P2 L1 L2 S1 S2 • Wavelength Fact L1/2: 1 1 • Time of first observation: 2011 02 05 23 50 10.0000000 GPS • Comment: RTCM_3 www.euref-ip.net/ACOR0 • Misc. Comments: Portions of this header generated by caster EPN CB from Sitelog Acord_20100722 • System number and Observation Types: G: GPS R: GLONASS S: Geostationary Signal Payload 45

Chapter 2 Background, Relevant Literature and Related Work

2.10 WSN based Positioning

The challenge of infrastructure-based networks and the limitations of GNSS in indoor environments has motivated the development of an alternative approach based on Wireless Sensor Networks (WSN).

Advancements in the field of WSN promise better reliability, granularity and resolution (Small et al., 2000; Niculescu & Nath, 2001; Savarese et al., 2002; Savvides et al., 2003; Smith et al., 2004). Probabilistic approaches have been proposed for indoor positioning (Roos et al., 2002). Proposed techniques based on adhoc systems can deliver assistance information at low computation cost (Youssef et al., 2003), and similar radio systems hardware can be cost-effective (Krumm et al., 2002). Current WSN market penetration includes use in crime prevention, emergency and incidence response management, product tracking at industrial sites, wildlife habitat monitoring, and home control.

Indoor experiments are suggestive of high availability for such systems being resilient to partial beacon node failure. However, wireless node connectivity can be impacted in certain situations (Lorinz et al., 2006). WSN-supported AGNSS can provide location assistance in Safety-of-Life operations with low TTFF (Krumm et al., 2002). Pseudorange and distance observation simulations have shown increased positioning availability and accuracy with four or less satellites (Zou et al., 2008). This is discussed further in Chapter 6.

2.11 Secure User Plane Location (SUPL)

Secure User Plane Location (SUPL) is an enabling standard specified by OMA (2006) to utilise existing mobile positioning and assistance standards, and to expand the assistance transfer and position acquisition capability over TCP/IP networks. It includes a Location User Plane (LUP) reference point to establish the relationship and interworking criterion between SUPL Enabled Terminals (SETs). Other associated services are authentication, authorisation, charging, roaming and privacy functions, which have been specified in OMA standard release documentation. SET is employed as the user-end device to provide SUPL-based services, as specified by OMA and user subscription, subject to the use of appropriately supported handset. Figure 2.13 shows the

Chapter 2 Background, Relevant Literature and Related Work

conceptual building blocks of the SUPL platform architecture with respect to the services provided by SUPL. These are discussed in detail in Chapters 4 and 5.

Figure 2.13 SUPL architecture (OMA-AD-SUPL-V1_0-20060127-C, 2006).

The SUPL portfolio can be used to provide services in the following domains, in addition to usual positioning and assistance operations:

a. Commercial b. Emergency

The following standards have been released through the course of last (OMA, 2002-2012):

a. SUPLr1 (basic positioning and assistance) 47

Chapter 2 Background, Relevant Literature and Related Work

b. SUPLr2 (enhancements such as periodic and deferred location) c. SUPLr3 (specifies the LPP enhancements)

There are two primary types of location service categories that have been proposed as enhancements in future releases:

a. Periodic location b. Deferred location

There are two types of SUPL services:

a. Network initiated (originate from within the SUPL network) b. SET initiated (originate from within the handset) (Figure 2.14)

Figure 2.14 Process overview of the SET-initiated AGPS/AGNSS (Göze, 2008).

The SET position is computed via the following modes:

a. AGPS SET Assisted b. AGPS SET Based

Chapter 2 Background, Relevant Literature and Related Work

c. Autonomous GPS d. Enhanced Cell or Sector e. AFLT f. EOTD g. OTDOA h. Location ID

The SUPL Reference Architecture specifies the user-plane related location services network entities and associated reference points and defines the basic frame of operation. Here network entities generally represent a group of functions, not physical devices, which are specified by the manufacturer or network operator. The reference point is a conceptual demarcation point for the two conceptual working groups. As an example, LUP is a reference point initiated by one interface. It acts as the underlying protocol layer over which the SET communicates with the network.

As discussed previously, 3GPP and OMA are the two main organisations involved in multi-GNSS standards. This has triggered the need to focus more on the protocol, which is required for the standardisation process, discussed in more detail in Chapters 4 and 5.

2.12 Concluding Remarks

GPS and GNSS technologies have been reviewed with signal structures of GPS. Indoor and outdoor positioning techniques and their challenges are presented. Localization based on mobile networks, hybrid positioning, OSGRS, NTRIP and multiple sensor systems is interesting due to their wide applicability, pervasive deployment, global omnipresence, cost effectiveness and low infrastructure requirements. SUPL is important being the primary protocol capable of providing assistance to multiple GNSS systems which have been standardized.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Chapter 3 SPOT Satellite Messenger and Hybrid Positioning

The Location Based Services (LBS) market segment has experienced exponential growth over the last decade. One of the drivers is the introduction of the smartphone category of mobile devices. However there is also a growing need for what may be referred to as “emergency relief positioning”. The performance requirements for such LBS applications are availability, accuracy and time-to-first-fix (TTFF).

While there are a number of purpose built emergency LBS devices in use, no system seems to be a clear winner. The “SPOT Satellite Messenger” (Figure 1.2) however has gained some attention for its claimed reliability. This chapter summarises the system architecture and experimental test results, comparing them with Assisted-GPS (AGPS). The test bed comprised 26 test points with a variety of GPS difficulty levels, as exemplified by diverse environments inside and outside the University of New South Wales (UNSW) campus. Benchmarking studies analyse SPOT’s TTFF, availability, and accuracy. Although AGPS can provide reliable and cost effective alternatives to the SPOT Satellite Messenger, the reliance on an IP network (wired or wireless) can limit AGNSS performance when the underlying infrastructure is not available, as in the case for example in remote areas.

A Multi-Sensor and Multi-Network based hybrid Multi-GNSS approach is described, referred to here as a “Multiple Sensor Assisted Hybrid Positioning System”. With a backup mechanism for every possible failure scenario, such a system could provide a fail-safe position-navigation-timing (PNT) solution framework. The system can potentially address the AGNSS limitations by establishing a baseline for positioning systems in strong multipath or weak signal environments. Improvements in availability (%), accuracy (m) and TTFF (s) can be realised at a reasonable cost.

3.1 Location Based Services (LBS) and Conventional LBS Variants

Figure 3.1 illustrates the conceptual building blocks of a Location Based Services (LBS) System. A generic system consists of user equipment with an embedded GPS/GNSS chipset that generates a position fix from satellite observations. The user equipment is then remotely connected to a first- hop routing point to report the local parameters and system health. The secondary or tertiary routing

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

point can be a base station (cellular) or access point (WiFi) that serves the requests and interfaces with the internet and emergency service providers.

Figure 3.1 Building Blocks of a LBS System

There are a variety of LBS variants for SoL applications. Conventional systems include the EPIRB, ELT or PLB (Chapter 1). Despite being rather dated, their system architecture, reliance on the COSPAS network, and operation are similar to the SPOT Satellite Messenger. NESDIS-NOAA operates the Search and Rescue Satellite Aided Tracking (SARSAT) system to globally locate mariners, aviators, and recreational enthusiasts in distress. The SARSAT system is based on NOAA satellites in low-earth (LEO) and geostationary orbits (GEO). The satellites relay distress signals received from emergency beacons to terrestrial stations and ultimately transfer to the U.S. Mission Control Center (USMCC) in Suitland, Maryland. The USMCC alerts the appropriate search and rescue authorities (Figure 3.2).

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.2 COSPAS-SARSAT Global Operation (NOAA, 2007)

3.2 SPOT Satellite Messenger

SPOT is a comparatively modern satellite messenger system marketed for consumer LBS applications (Technical Datasheet can be found in Appendix F). The system claims availability of approximately 96-99% within 20 minutes, with 98% accuracy (FindMeSpot, 2009). SPOT Satellite Messenger employs GNSS to generate user equipment coordinates, and up-links the location information to the Global Star commercial satellite communications constellation. The Global Star network relays this information to their earth stations, then to the subscribed cellular operator, who sends an SMS notification. Remote user coordinates are plotted on Google Maps and uploaded on to the personalised online user account.

Figure 3.3 SPOT Satellite Messenger System 52

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.3 elaborates the simplex transmission flow, where there is no feedback mechanism for the user. If sufficient GPS and commercial satellites are visible, and communications is successful, the user is capable of conveying four messages:

• Check-in (ON/OFF) • Safety Notification (OK) • Assistance Required (HELP) • Distress Signal (911)

Four Light Emitting Diodes (LED) indicate the device health and messaging status. The buttons are re-configurable to perform different operations other than the default ones. When a specific button is pressed, the SPOT system operation is initiated by determining position using GPS signals. This location information is then forwarded to the Global Star network (constellation of about 48-56 satellites). These satellites relay this location information to the terrestrial SPOT stations. The subsequent response is received on email, cell phone (via SMS) and the Emergency Response Centre will finally update the online SPOT user profile. SMS notifications received on mobile phones are shown in Figures 3.4a & 3.4b.

Figure 3.4 a. Message updates on mobile phone, b. Exact location received via SMS

Figure 3.5 shows the periodic updates on the user profile. The Lat-Long information, periodic time- stamp updates to the user profile, message types, near location identification, and other data are also shown.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.5 Entry updates in user profile

Subsequent user “footprints” can be plotted via the tracking function preconfigured for SPOT devices in the user profile. These are plotted on Google Maps (Figures 3.6a & 3.6b) and uploaded to the user profile.

Figure 3.6a Plots of tracking/logging updates

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.6b Lat/Long plots on Google Maps (Hybrid Mode)

3.2.1 System Hardware

The AXTracker STX2 user handset was manufactured by AXONN LLC and marketed by SPOT Inc. The GPS chipset used was a Nemerix Nx2, (Nemerix, 2007) baseband processor Ð ultra-low power, high performance, stand-alone and hosted AGNSS L1 C/A code capable receiver. It uses the LEO satellite constellation of Global Star which is one of the leading third-party marketers of communication satellite links.

3.2.2 System Coverage

The SPOT network transmits information to friends, family or to an emergency service centre. The system claims a reliability of 96-99% around the globe. The commercial satellite network claims a 99.4% reliability rate capable of processing over 6 million messages a month - the equivalent of 2.3 messages per second (FindMeSpot, 2009). A global footprint of approximately 90-95% is claimed on the company website (Figure 3.7).

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.7 Global coverage footprint (FindMeSpot, 2009) - Location of experiments is highlighted

3.2.2.1 Map Legend

• Orange Ð 99% or better probability of successful transmission within 20mins • Yellow Ð 96% to 99% probability of successful transmission within 20mins • Dark Grey Ð Reduced or no coverage within a 20min window • Light Grey Ð No coverage at all

3.2.3 Experiments

3.2.3.1. Benchmarking Equipment

In these tests the performance of the SPOT system is compared with receivers with: (a) medium- sensitivity GPS/GNSS, (b) high-sensitivity GNSS, and (c) Assisted-GNSS (AGNSS). For benchmarking, a SUPL-enabled Assisted and GNSS smartphone (Mio A701), capable of providing a position fix in different modes, has been used. Secure User Plane (SUPL) is an emerging protocol standard produced for location determination, either in stand-alone mode or in augmentation mode (OMA, 2007). The standard allows the Mio A701 client to request assistance information when attempting to calculate its location from a third-party location server, such as the Andrew Corporation’s AGNSS server communicating over the TCP/IP protocol (Figure 3.8).

The Mio A701 can execute both MS-based and MS-Assisted AGNSS modes. Once a TCP/IP connection is established, the SUPL Enabled Terminal (SET) determines its location using AGNSS (CommScope, 2009) & (Broadcom, 2007). The Mio A701 can also provide a position fix in stand-

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

alone mode, employing a 20-channel high-sensitivity SiRFStar-III GPS chipset, with a sensitivity of approximately -160dBm (SiRF-CSR, 2009). Figure 3.8 shows the operation of the Mio AGNSS system. A Garmin eTrex was used as a standard sensitivity receiver GNSS (-120dBm).

Figure 3.8 General AGNSS components

3.2.3.2. Test Area and Test Point Classification

A test bed comprising 26 positions was selected around the UNSW campus, highlighted in Figure 3.9. These test positions simulate a diverse range of GNSS environments including open skyview, different levels of tree cover, adjacent to large buildings, under cover, indoors (near windows, in corridors and on balconies), low traffic areas, main streets and roof-tops (partial and complete skyview cover). A database of difficulty levels ranging from 1 (easy) to 10 (difficult) was established based on the fractional visibility of open sky, potential for error factors like multipath errors, etc. 0 means more than 90% open sky visibility, whereas 10 means the position was indoors or there was less than 10% sky visibility (Section 3.3.3.4). Testing a device in such diverse environments can indicate the level of positioning performance (availability, accuracy and TTFF) one could expect in real world environments.

3.2.3.3. Signal Attenuation

Indoor signals at 1.5GHz (L1-band) experience different levels of attenuation when passing through different materials. A drywall, glass or plywood causes comparatively low signal attenuation of

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

between 1-3dB. On the other hand, bricks and concrete can cause attenuations of between 5-33dB (Stone, 1997). Similarly, the attenuation in residential buildings is typically in the range 5-15dB, increasing to between 20-30dB in office buildings. Significant attenuation level changes of approximately 30dB have been reported (Mautz, 2009) for underground car parks and tunnels.

3.2.3.4. Classification of Test Points

There are five categories of scenarios in Figure 3.9 (with a grading system of 0 to 10):

• Urban (U) (e.g. “urban canyons” in the CBD) • Suburban (S) (e.g. partial cover between trees or under a roof) • Rural (R) (limited cover, e.g. canyons) • Indoor (I) (almost complete cover) • Open sky (O) (minimal cover, maximum satellite visibility)

Detailed information is presented in Table 3.1. Each test point shows a test point reference number, description, the difficulty level (DL), type, map reference and lat/long information.

Table 3.1 UNSW test point details

S. No. Point Description DL Type Map Latitude Longitude 1 B042A high tree cover, very close to 5L BLD 5 S NU 33.91632914151.232834 2 B112B minor tree cover nearby, distand 3L BLD 2 S SL 33.91775905 151.2260062 3 B315C dense partial tree cover, nearby 5L BLD 6 U SM 33.91968273 151.22876 4 B328 dense tree cover, nearby low BLDs 8 S NM 33.91537738 151.228901 5 B330 11L BLD one side, clear on other 5 U NM 33.91693494 151.2286315 6 B333 partial tree cover, distant 2L, 7L BLDs 4 U NU 33.9168157 151.2349203 7 B405 partial tree cover, distant 1L BLDs 3 S NU 33.91778346 151.2363298 8 B407 nearby 7& 11L BLDs 5 U NU 33.91802246 151.2347084 9 B408 clear sky view (+) 0 O SU 33.91842128 151.2350467 10 B409 clear sky view, near low trees 1 R SU 33.91862534 151.2343652 11 B410 clear sky view, near low trees 1 R NU 33.91833287 151.2337673 12 B411 under narrow roof, nearby 4L, distant 9L BLDs 9 U NU 33.91788568 151.233785 13 B414 undercover, nearby 4L & 9L BLDs 10 U NU 33.91699689 151.233138 14 HP415 nearby 9L BLD 6 U NU 33.91798571 151.2334542 15 B417 nearby thin trees, surrounded by low to high BLDs 6 U NM 33.9173961 151.2322604 16 B424 distant 8L BLD 2 U SL 33.91943257 151.2270628 17 B429 partial dense tree cover, nearby low BLDs, distant high BLDs 6 U NL 33.91636271 151.2287285 18 B609 distant 4L, 6L &11L BLDs, partial tree cover 4 U SM 33.91763356 151.2289608 19 PM311 open suburban, nearby thin trees, low BLDs 2 S SU 33.92023225 151.2316938 20 PM312 open suburban, nearby thin trees, low BLDs 3 S SU 33.91903576 151.2319338 21 PM316 partial tree cover, nearby 1L BLD 3 S SU 33.91902248 151.2359344 22 PM477 partial thin tree cover, distant 2L BLDs 3 S NU 33.91637951 151.2348598 23 INDR1 Western foyer, level 4, EE BLD 10 I NM 33.9177717 151.2314479 24 INDR2 Room 414, level 4, EE BLD 10 I NM 33.917746 151.2317174 25 INDR3 Eastern foyer, level 4, EE BLD 10 I NM 33.9178248 151.2318354 26 INDR4 Staff Room, level 4, EE BLD 10 I NM 33.91785279 151.2316862 58

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.9 shows a map of the UNSW campus, marked with 22 outdoor test points. The remaining four test points haven’t been marked as they are indoors (see Table 3.1).

Figure 3.9 Test bed in UNSW campus and surrounding area

3.2.3.5. Experimental Results

The SPOT Satellite Messenger performance was compared to that of: (a) high-sensitivity stand- alone GPS (SiRFStar-III), (b) Assisted-GPS (SUPL MSB and MSA) and, (c) medium-sensitivity GPS (Garmin eTrex). A total of 68 attempts were made including repeats at 26 test points, and the results were averaged.

The results were classified as Pass or Fail outcomes depending upon the successful communication, message delivery and updates on the online user profile. Where the SPOT successfully delivered a message and/or updated the user profile, a Pass was reported. Subsequently, a total of two attempts were made at each of such locations, otherwise a Fail was reported. Where multiple conflicting results of both Pass/Fail were recorded, a total of three attempts were made. As a rule of thumb, the SPOT messenger passed when the Garmin eTrex tracked 6 or more GPS satellites.

Figure 3.10a plots the test results of the compared devices. The x-axis shows the test point number, and the y-axis the maximum number of GPS satellites visible for each test. Plots of min-max number of satellites tracked by SET-Assisted and SET-Based AGPS and stand-alone high- 59

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

sensitivity GPS (HS-GPS) are shown. SPOT demonstrated the highest TTFF and the lowest number of visible satellites as compared to AGPS and HS-GPS at each test point.

14 12 SPOT 10 8 SET-ASSISTED 6 4 SET-BASED 2 0 STAND-ALONE 1234567891011121314151617181920212223242526 Max. No. of Satellites of No. Max. Scenario Based No. of Tests

Figure 3.10a Satellite availability against difficulty levels

SPOT and Garmin eTrex tracked a similar number (min-max) of satellites due to similar receiver signal sensitivity capabilities. A deterioration in performance of SPOT was noted with increasing difficulty levels. SET-Assisted AGPS consistently tracked more satellites in most scenarios. Figure 3.10b shows higher horizontal and vertical errors. The highest vertical error magnitude in an urban scenario for SPOT was observed to be 155.8m, with standard deviation of 49.7m. Similarly, the highest horizontal error magnitude in an urban environment was 167.5m, with a standard deviation of 78.3m. There were on average 4.5 visible satellites, and an average TTFF of 680secs.

180 90 160 80 140 70 120 60 100 Hor. 50 Hor. 80 Error 40 STD 60 30 40 20 20 10 0 0 269111416171821 269111416171821

Figure 3.10b SPOT horizontal & vertical errors (left), and standard deviations (right)

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

The Dilution of Precision (DOP), which is a measure of the quality of satellite constellation geometry, is an important factor to be considered in positioning accuracy. High HDOP or VDOP values indicate low horizontal and vertical precision, respectively, and vice versa. Such error values are significantly impacted by the increase in difficulty levels. For comparison and convenience, multiple identical values have been grouped together for all four devices under test. The disparity between the HDOP and VDOP values is clearly larger with the drop in the number of visible satellites.

For each test point the horizontal and vertical error values are positively proportional to the corresponding difficulty levels. It can be seen in Figures 3.10c, 3.10d, 3.10e and 3.10f that vertical errors are higher than the horizontal errors, assuming zero clock errors. In contrast, in some test points the horizontal error values are higher.

Figure 3.10c SPOT Messenger mean horizontal & vertical errors (left), and standard deviations (right)

For partially covered spaces, DOP values between 1-2 are considered ‘Excellent’, values between 2-5 are considered ‘Good’, values between 5-10 are ‘Moderate’, between 10-20 are considered ‘Fair’, whereas values higher than 20 are considered ‘Poor’.

The test points where SPOT satellite messenger reported a ‘Pass’ were chosen for benchmarking (Figures 3.10c-f). The mean horizontal error for SET-Assisted was 21.5m with standard deviation of 32.5m in an urban environment. For the same test point, the mean vertical error was 29m with standard deviation of 42.9m (Figure 3.10d). An average TTFF of 11.2 seconds was recorded with an average 6.4 visible GPS satellites.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.10d SET-Assisted AGPS mean horizontal & vertical errors (left), and standard deviations (right)

Figure 3.10e SET-Based AGPS mean horizontal & vertical errors (left), and standard deviations (right)

The mean horizontal error for SET-Based was 23.3m with standard deviation of 28m in an urban environment. For the same test point, the mean vertical error was 32.2m with standard deviation of 42.8m (Figure 3.10e). An average TTFF of 10.4 seconds with an average of 6.9 visible GPS satellites.

Figure 3.10f Stand-alone HS-GPS mean horizontal & vertical errors (left), and standard deviations (right)

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

The mean horizontal error for the stand-alone system was 18.9m with standard deviation of 28.3m in an urban environment. For the same test point, the mean vertical error was 33.2m with standard deviation 36.9m (Figure 3.10f). Average 42.1 seconds TTFF with an average of 5.3 visible GPS satellites.

For each test point the horizontal and vertical error values were proportional to the corresponding difficulty levels. Standard deviation (STD), σ was calculated:

eq.3.1

Where is the series of variable distribution in STD and represented as:

eq.3.2

Figures 3.11a, 3.11b, 3.11c and 3.11d show the individual device performance plots with Min, Max, and Mean of number of visible satellites and TTFF for diverse scenarios. As mentioned earlier, the SPOT Satellite Messenger “passed” at a test point where it tracked 6 or more GPS satellites.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

SPOT

1400

1200

1000 OpenSky

800 Suburban Urban 600 TTFF(s) Rural 400 Indoor

200

0 0246810 Satellites

Figure 3.11(a) SPOT performance

MS-Assisted

41.412

31.059 OpenSky Suburban 20.706 Urban

TTFF(s) Rural Indoor 10.353

0 02468101214 Satellites

(b): MS-Assisted AGPS performance

MS-Based

103.53 93.177 82.824 72.471 OpenSky 62.118 Suburban 51.765 Urban

TTFF(s) 41.412 Rural 31.059 Indoor 20.706 10.353 0 024681012 Satellites

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Stand-Alone

140

120

100 OpenSky Suburban 80 Urban 60 TTFF(s) Rural 40 Indoor

0 024681012 Satellites

(d) Stand-alone HS-GPS performance

Higher TTFFs and lower overall availability rates are obvious for the SPOT Satellite Messenger. Figures 3.12 benchmark the overall performance, with SPOT having the lowest availability rate of approximately 40% and an average number of tracked GPS satellites of 4.8. On the other hand, the SET-Assisted and SET-Based systems tracked (on average) 6.8 and 7.3 satellites respectively, and the stand-alone system tracked an average of 5.8 satellites. The mean TTFF achieved by SPOT was the highest, at 544 seconds, with the highest failure rate of approximately 60%.

Average Service Availability of Each Device 600 544 120%

500 100%

MS- A s s is ted, MS- Bas ed, 400 80% 98.50% 99.80% MS- A s s isted TTFF HS-GPS, SPOT 300 No. of Sats 60% 86.70% MS- Bas ed Failure Rate (%) HS-GPS 200 Percentage (%) 40%

SPOT, 20% 40.20% 100 59.8 40.8 13.3 4.8 11.6 6.8 1.5 11.8 7.3 0.2 5.8 0% 0 De vice s SPOT SET-Assisted SET-Based Stand-Alone

Figure 3.12 Performance comparison

SET-Based AGPS outperformed the other system/devices with the lowest TTFF, the highest number of satellites (on average), and the lowest failure rate.

3.3 Mitigation Technique

Based on the outcome of the above benchmarking experiments, it appears that the SPOT Satellite Messenger is not the best choice for emergency LBS applications. Stand-alone AGPS demonstrated

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

better performance; however it relies on underlying network infrastructure, and may therefore not be viable for some remote SAR applications. As no stand-alone system can perform well in all scenarios; hybrid techniques based on multi-GNSS concepts may provide alternatives. Li (2006) suggests that hybrid location determination techniques could harness the collective potential of several positioning technologies, hence improving reliability, availability and accuracy.

Weiser et al. (1988) articulated the concept of ‘Ubiquitous Computing’ as follows:

"Ubiquitous computing names the third wave in computing, just now beginning. First were mainframes, each shared by lots of people. Now we are in the personal computing era, person and machine staring uneasily at each other across the desktop. Next comes ubiquitous computing, or the age of calm technology, when technology recedes into the background of our lives."

A similar concept would integrate positioning computation into common, shared environment, in contrast to treating GNSS receivers as distinct objects. Devices will be able to sense changes in their environment and react according to user preferences or scenarios (Weiser, 1993; Weiser and Brown, 1996) Ð including emergency LBS. Their location, orientation, health, speed, acceleration and other parameters would constitute essential pieces of information. LBS can be treated as a subset of “ubiquitous computing” (Li, 2006). To improve the reliability and continuity, combining multiple sensors and systems is necessary. As discussed in Chapter 2, some hybrid examples include:

a. AOA + RSS b. AOA + TDOA c. E-OTD + AGNSS

3.3.1 System Architecture

A Multiple Sensor and Multiple Network based hybrid positioning system is described here (Figure 3.13). The following technologies involved:

a. Navigation and Positioning

• GPS + GNSS + Mobile RBS 66

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

• WSN + Wi-Fi + RFID + Bluetooth

b. Back-to-Base Communication

• Full-Duplex Satellite Link + Ground Station • IP Network + Mobile Communications

c. Terrestrial System Augmentation

• RNSS + Terrestrial Communication Stations + Web Connected Server • User Services Centre + Emergency Response Services

d. Intelligent User Interface

• Human Input Interface + Computer Connectivity Peripherals • Dynamic Management Information Base + Feedback System + Display

Here, the End User Terminal is an advanced ubiquitous computing device such as a smartphone.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.13 Hybrid Positioning System architecture

Such a terminal is referred to here as the Human Interface Segment (HIS). The HIS can carry out local processing, such as displaying the satellite status, positioning processing and correction, assistance data, health status, emergency services response, messaging status and personnel or bearer health monitoring. An embedded GPS/GNSS chipset should perform across as many signal environments as possible.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Abundantly deployed RFID tags can report the geographical location, surroundings, and weather and locality circumstances - to the RFID reader incorporated on the HIS, and would help reduce the processing load on the wireless sensor network (WSN) system pre-deployed in the area to provide assistance data. RFID and WSN are employed when there is low sky visibility. WSN nodes have been incorporated into handheld devices (Toumaz, 2009) and can assist in infrastructure-less positioning (Chapter 6). RFID and sensor nodes can provide a backup to each other in case of partial or complete system failure.

The system operation is controlled through a mechanism called the Priority Pyramid (PP). Where available, the mobile RBS or BTS network would be a preferred choice over a personal area network (PAN). WiFi signal “fingerprinting” will be employed in enclosed walls or buildings (Li et al., 2006). An on-board WiFi interface will process user input data and provide corrections. The Bluetooth network will provide a fix in a similar fashion by pairing with self-location aware neighbouring nodes. A Wi-Max interface would allow data to be directly communicated with the BTS, thus relayed to the appropriate Emergency Response Centre. A high speed USB interface will allow the paramedics or other person’s access to downloadable log files on user health, historical events and incident details.

3.3.2 System Operation

In Figure 3.13, upon the activation of the distress routine, the HIS will generate the lat/long information from the GPS measurements. The communications satellite will relay uplinked information to the earth stations. The messages will be conveyed to call centres and appropriate emergency service agencies. The operational flow chart is shown in Figure 3.14:

a. Continuous or intermittent GPS/GNSS signal acquisition, independent of the situation (emergency or non-emergency), periodically broadcast back to base and stored in memory. b. Health probes monitor parameters such as blood pressure and heart rate, which are relayed via the communication satellite channel at specified intervals of time. c. Accelerometers monitor personal activity, physical hazards, speed, etc., to health processors, and perhaps logged into a master database. d. In case of hazard detection or activation of distress button, user position would be calculated depending on system availability. e. GPS will be used, perhaps with assistance information. In future other GNSS may be used. 69

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

f. Backup device selection is controlled by the PP algorithm based on variables such as reliability factor, scenario and geographical location. g. If GPS/GNSS is unavailable, BTS will acquire a fix in the area of cell coverage. WiFi may be used in urban environments. Alternatively WSN or RFID might be more appropriate in certain areas.

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

Figure 3.14 Hybrid Positioning System operation

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

3.3.3 Significance and Applications

The hybrid solution described above overcomes a number of positioning, communications, data logging, emergency assistance and tracking problems. It also incorporates a comprehensive health monitoring capability.

Relevant emergency LBS applications include SAR operations carried out by police, fire brigade and BWRS. However the proposed hybrid system can also be applicable to other applications such as people and asset tracking, community services, disaster response systems, vehicular navigation, intelligent transportation systems, environmental applications, telematics, security and intelligence operations, notification systems for emergency responders, public notification systems, and others.

Several projects based on a similar approach have been have been proposed. The Open Source GNSS Reference Server (OSGRS) and integrated sensor localisation strategies presented in Chapters 4, 5 and 6 are based on hybrid concepts mentioned earlier. Sarwar et al. (2009), Sarwar et al. (2011), Sarwar et al. (2012) and Sarwar et al. (2013) implement segments of the system and describe configurations and applications tests. Similarly, the Simplified Information Mobility and Orientation (SIMO) programs (Li et al., 2009; Gallagher et al., 2010) seek to ensure positioning accuracy with lowered power requirements.

According to the LBS specifications categorised by Deligiannis et al. (2010) and Sarwar et al. (2012), the applications span:

• Commercial LBS • Internal LBS • Emergency LBS • Lawful Intercept LBS • Mobile LBS

Wauters et al. (2010) quotes Windsor Holden on the importance of mobile and ubiquitous LBS:

“Location-based applications are extremely interesting for brands and retailers in that they allow those companies to direct consumers to outlets in their vicinity while simultaneously providing

Chapter 3 SPOT GNSS and Hybrid Multi-GNSS

information about the products on offer. When these are allied to measures such as mobile coupons and vouchers, you have the combination of information and financial incentive which can be compelling for consumers.”

3.4 Concluding Remarks

Rescue agencies face considerable difficulties in emergency operations. SPOT satellite messenger has been of interest due to a claimed global coverage footprint of 96% with open or partial open sky visibility. SPOT messenger had the lowest availability rate of 40% and tracked 4.8 satellites on average with the highest TTFF of 544sec. The SPOT system also demonstrated higher horizontal and vertical errors than the other systems in discussion. Both SET-Assisted and SET-Based systems tracked more than 6 satellites where the stand-alone system tracked more than 5.

The experiments demonstrated the average reliability and availability not exceeding 40% due to failed communication - in weak signal, NLoS, canyon environments and indoors. Excluding the indoor scenario from test results provided some performance correction to SPOT i.e. approx. 4% however rendering the device unviable for LBS. AGNSS (MS Assisted and MS Based) tracked more satellites. Although the Stand-Alone HS GNSS showed lower relative availability than the AGNSS, the performance was significantly superior to SPOT. SET-Based AGNSS performed the best with the lowest TTFF, the highest mean number of tracked satellites and the lowest failure rate - vital observations for LBS applications.

Reliance on wired or wireless IP network potentially limits the performance when the underlying infrastructure is not available. Stand-Alone GNSS or Assisted GNSS systems may be limited in providing a fix. Multiple system based hybrid positioning can assist standard GNSS and comply with the government mandates like the E911 and user expectations. Global expansion of adhoc and autonomous sensor networks, monitoring tags and their indoor deployment will be the issues of interest for future development.

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Chapter 4 Assisted Multi-GNSS Reference Server, OSGRSv2

4.1 Introduction

Considering the poor performance of commercial LBS devices such as SPOT, AGNSS systems proved viable (Chapter 3) Ð however with some limitations highlighted in this chapter.

The Open Source GNSS Reference Server (OSGRS) exploits the GNSS Reference Interface Protocol (GRIP) to provide assistance data to GPS receivers. Assistance can be both in terms of signal acquisition and in the processing of the measurement data. The data transfer protocol is based on Extensible Mark-up Language (XML) schema. The first version of the OSGRS required a direct hardware connection to a GPS device to acquire the data necessary to generate the appropriate assistance. Scenarios of interest for the OSGRS users are weak signal strength indoors, obstructed outdoors or heavy multipath environments.

This chapter describes an improved version of OSGRS which provides alternative assistance support from a number of Global Navigation Satellite Systems (GNSS). The underlying protocol to transfer GNSS assistance data from global casters is the Networked Transport of RTCM (Radio Technical Commission for Maritime Services) over Internet Protocol (NTRIP), and/or the RINEX (Receiver Independent Exchange) format. This expands the assistance and support model of the OSGRS to globally available GNSS data servers connected via internet casters. A variety of formats and versions of RINEX and RTCM streams become available, which strengthens the assistance provisioning capability of the OSGRS platform.

The prime motivation for this work was to enhance the system architecture of the OSGRS to take advantage of globally available GNSS data sources. Open source software architectures and assistance models provide acquisition and data processing assistance for GNSS receivers operating in weak signal environments. This chapter describes test scenarios to benchmark the OSGRSv2 performance against other Assisted-GNSS solutions. Benchmarking devices include the SPOT satellite messenger, MS-Based & MS-Assisted GNSS, HSGNSS (SiRFstar-III) and Wireless Sensor Networks Assisted-GNSS. Benchmarked parameters include the number of tracked satellites, the Time to Fix First (TTFF), navigation availability and accuracy. 74

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Three different configurations of Multi-GNSS assistance servers were used, namely Cloud-Client- Server, the Demilitarized Zone (DMZ) Client-Server and PC-Client-Server; with respect to the connectivity location of client and server. The impact on the performance based on server and/or client initiation, hardware capability, network latency, processing delay and computation times with their storage, scalability, processing and load sharing capabilities, were analysed.

The performance of the OSGRS is compared against commercial GNSS, Assisted-GNSS and WSN-enabled GNSS devices. The OSGRS system demonstrated lower TTFF and higher availability.

4.2 Open Source GNSS Reference Server (OSGRS)

One of the limitations of stand-alone GPS/GNSS is the length of time it takes for a navigation “fix” under certain circumstances. This is a substantial drawback for emergency applications requiring “instantaneous” fixes, and/or the GPS/GNSS receiver has not been used for a long time, and/or the receiver is operating in a weak signal environment. Assisted-GNSS (A-GNSS) improves TTFF and availability (Sarwar et al., 2009). This is achieved by providing assistance for signal acquisition and measurement processing, and removing the need to demodulate the navigation message from the broadcast signal (Harper et al., 2007). Commercial assistance servers typically use proprietary protocols to provide assistance data. Therefore, there are limited means of pre-deployment testing for non-commercial or research organisations, for system and protocol testing. The development of multi-server support and end-user clients also becomes difficult for such proprietary systems.

The Open Source GNSS Reference Server (OSGRS) is an open source Java application based server system that provides assistance data for A-GNSS clients (Yan et al., 2007). The first version of OSGRS was limited to operating in a local, or virtual private network domain. This limitation has been removed in the subsequent Version 2, expanding the data acquisition resource to globally available GNSS data sources through the Networked Transport of RTCM over the Internet Protocol (NTRIP). NTRIP facilitates differential GNSS (DGNSS) and Real-Time Kinematic (RTK) cm- accuracy assistance and correction data for remote users over TCP/IP, GSM or LTE networks (Dammalage et al., 2007). The overall system architecture is client-server based; while the client can be a mobile or fixed A-GPS/GNSS computer, as in Figure 4.1.

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Figure 4.1. Basic components of the OSGRS

4.3 System Architecture and Operation

OSGRS provides assistance data for GNSS clients using the GNSS Reference Interface Protocol (GRIP). This allows development of algorithms with lowered effort and resource investment. GRIP is based on the XML schema as specified by the World Wide Web Consortium (W3C). Several schema validation mechanisms are employed to validate the request and response routines (W3C, 2009). The OSGRS is developed on a Java-based platform providing current, relevant and specific assistance data. The client can be an A-GNSS handset or a computer application. It is connected to one or more GNSS sources to cache data and serve it in response to client requests. The data is available in a variety of formats useful for accurate position calculations. For supplementary information on OSGRS operation and GRIP data, see Appendices A, B and C.

There are three releases of OSGRS; this chapter briefly describes Release 1 and Release 2. Release 3 and the proposal for Release 4 are discussed in Chapter 5.

a. OSGRS v1.0 (2007): OSGRS v1.0 was limited to supporting a local, single GPS source such as the Novatel OEM3 or OEM4 receiver. This was a local client-server architecture requiring both ends of the system to be within the same WAN domain. This required the client to have a Virtual Private Network (VPN) connection into the network of the server. The GRIP protocol architecture is illustrated in Figure 4.2.

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Satellite 1

HTTP Post

GNSS Data Client GRIP Protocol OSGRS Server Source(s) Control Satellite 2

XML

Satellite 3

Figure 4.2 OSGRSv1 Architecture

b. OSGRS v2.0 (2011) (Author’s Contribution): Improvement was needed to provide support for other GNSS systems and to globalise the server access to provide anywhere/any-system architecture, multi-format output and increased integration flexibility. The second revision incorporates the addition of global GNSS data sources available through NTRIP, making it a multiple A-GNSS system or MAG (Figure 4.3). This version can run the client-server virtually anywhere without any private network or VPN connection limitations.

Figure 4.3 System architecture of the MAG OSGRS

The OSGRS function is based on GRIP, an XML schema based protocol that utilises HTTP. The client requests may be specific or contain an array of parameters required for position calculation. An approximate position can be included in the request. The response contains A-GNSS assistance data for satellites in view of the client or assistance data of all satellites, whichever are available. 77

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

GRIP restricts HTTP 1.1 as the compliance protocol for maintenance of a persistent connection. The connection starts with HTTP POST and the payload comes in XML format, which is easier to read.

Table 4.1 demonstrates the GNSS capability of OSGRSv1 vs. the NTRIP based OSGRSv2.

Table 4.1. OSGRS vs NTRIP GNSS Model

4.4 Code Structure

Java code has been written to provide the multi-GNSS functionality both on the server and on the client. Section 4.14 describes the project structure in more detail. The main processing process functions are:

a. OSGRS: OSGRS server package controlling major functions such as data selection, validation, caching and interfaces. b. OSGRSClient: Provides client interface to other classes and displays are received stream from servers. c. TestOSGRSClient: Client connection tester with preset parameters. d. HTTPServer: Server classes associated package. e. DataManagement: Management and selection of data sources and the caching data. f. Document Object Model: Periodically caches incoming stream from GNSS sources to serve pre-validated requests. 78

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

g. XMLProcessing: Class for processing XML data; includes request validation, request parsing and response generation. h. PositionCalculation: Classes associated with calculating user and satellite position. i. DataType: Contains data models for each of the assistance data types. j. Util: Classes for utility functions, e.g. debug logger, request/response writer and testing facilities. k. NovatelOEM3/4: Connects to Novatel hardware sources and streams back through a serial connection. An interim IP converter is used to transfer the stream to computer. l. NTRIPpoller: Polls remote GNSS sources and caches data to be served in response to client requests. m. SerialPoller: Polls the serial port for inbound GNSS data stream through NTRIP. n. DataTypeTester: Tests data types in client/server test mode.

4.5 Enhanced Assistance Model

The XML schemas can be extended to support other GNSS such as Galileo and the associated protocols such as NTRIP. GRIP supports data acquisition of two categories, all satellites and satellites-in-view for both releases 1.0 and 2.0. Table 4.1 lists the assistance data types for each category. ‘Satellites-in-view’ will list the satellites in view of the client’s position, while the ‘All satellites’ mode will list all valid satellites for the assistance data.

Initially, the ‘HTTPServer’ handles client connections and responses, whereas the ‘DataSourceManager’ starts and caches data through the interface class known as ‘DataSource’. Variations in functionality of successive releases of OSGRS have been itemised in Table 4.2. The multi-GNSS OSGRSv2 column illustrates an extended capability set (Assistance data) Ð a vast improvement over its predecessor. Specifications outlined by OMA (2007), Yan et al. (2007), and Sarwar et al. (2011) have provided a baseline in defining the Multi-GNSS Assistance Model.

System firmware has been kept “open source” for development flexibility and to facilitate the input of global ideas for enhancement. Improvement and standardisation activities can take place independent of any commercial involvement and associated difficulties of working with proprietary protocols. The primary classes to initialise include the ‘HTTPServer’ and ‘DataSourceManager’. The ‘HTTPserver’ handles client connections, requests and responses to clients. The

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

‘DataSourceManager’ class initialises data communicate in order to ensure compatibility and correctness (Yan et al., 2007; Sarwar et al., 2011).

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Table 4.2. OSGRS Multi-GNSS Assistance Model

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

4.6 Operation and Code Processing

GNSS data from various sources are collected and cached in ‘GNSSDataCache’. Polling is controlled by setting parameters, such as log directories, listener port and refresh polling times in configuration files. Xerces XML parser’s validation detects any errors and ‘GNSSErrorResponse’ sends a message to the client. An acceptable request is XML-parsed for assistance data retrieval from cache. The ‘GNSSResponse’ writer then sends calculated or raw data (whichever applicable) to the client. The essence of a generic request handling and information flow through various classes is illustrated in Figure 4.4.

Figure 4.4. Logical System Operation

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

The OSGRS is written and compiled in Java running on Microsoft Windows XP Professional SP3 employing Standard Development Kit (SDK) 5.0 or later with the Eclipse IDE. As evident from Figure 4.4, multi-threaded programming allows for data extracting, storing, validation, communication and monitoring request and/or responses. Libraries such as the Jetty web server are used to handle, accept and respond to HTTP connections.

4.7 Multi-GNSS Unit Integration

With the capability of acquiring assistance data from other GNSS systems, OSGRS v2.0 becomes a Multiple Assisted GNSS (MAG) system, receiving RTCM (Radio Technical Commission for Maritime Services) correction data via the Internet Protocol. From an OSI or TCP/IP protocol perspective, it is an application layer protocol broadcasting formatted GNSS data streams over Internet channels. Application unit test results have been explained in Section 2.14 and Appendix H.

4.7.1 Network Transport of RTCM via Internet Protocol (NTRIP)

As described in detail in Chapter 2, “NTRIP is a stateless protocol based on the Hypertext Transfer Protocol HTTP/1.1” and can be modified to work with miscellaneous versions of HTTP (BKG, 2007). The HTTP objects are enhanced to acquire broadcast GNSS data streams. Disseminated differential correction data in formats such as RTCM can be transmitted to mobile or stationary clients with an IP connection. Wireless Internet access is also supported through mobile, wireless and/or IP networks, such as GSM, GPRS, EDGE, WiMax or UMTS. Figure 4.5 shows NTRIP global footprint with regional broadcasters highlighted. The School of Surveying and Geospatial Engineering at UNSW is one of the listed casters. Caster details are:

2501 Misc AUS www.igs-ip.net:2101 UNSW0 Sydney GPS+GLO L1&L2 -33.92 151.23 Single Base No A LEICA GRX1200+GNSS... RTCM 3.0 1004(1), 1006(10), 1008(10) (BKG, 2011).

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Figure 4.5 Multi-GNSS Global Footprint (BKG, 2011), UNSW is highlighted

NTRIP system’s hardware and software components are described in detail in Chapter 2, section 2.9. The NTRIPCaster is the HTTP server module, whereas the NTRIPClient and NTRIPServer integrate as HTTP client modules. Any NTRIPCaster maintains a source table containing metadata listing the available GNSS data streams. The source table may also contain information about networks of data streams, the IP address and port of the NTRIPCaster, as well as IP addresses and ports of other NTRIPCasters (BKG, 2007). The NTRIPClient receives the source table, to enable a user to choose an appropriate data stream. Figure 4.6 shows a component-wise NTRIP system architecture.

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

GNSS Source 1

GNSS Source 2 NTRIP Caster Firewall or External Network

GNSS Source 3

Figure 4.6 Multi-GNSS System Architecture

4.7.2 Configuration and Operation

The data is input to the OSGRS to be cached to serve non-periodic or scheduled client requests. The client can choose any caster. Relevant login credentials (if applicable) must be supplied by the user. Applications are made directly to relevant casters and access to data is granted based on third party discretion. The server is executed and a connection is made to a preconfigured GPS or GNSS receiver or caster. The OSGRS client takes the input parameters from the user and tries to communicate to the server through the XML parser. Once the request is validated the server responds back with relevant cached data from the appropriate source in response to the input parameters supplied by the client.

Several commercial and research clients are available from Germany’s Federal Agency for Cartography and Geodesy (BKG) to access NTRIP streams. For example, the NTRIP client GNSS Internet Radio (GIR) (BKG, 2007) is designed to run on a Windows PC. It can handle HTTP communication to receive streams from an NTRIPCaster. After downloading a source table, setting up the session parameters and pressing the “start” button, the software connects to the NTRIPCaster and writes the received GNSS data stream to a serial or IP port until the session is stopped. 85

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Configuration data and previous session parameters are stored locally in a file called GNSS.ini, containing parameters such as IP:port, userID:password and COM-port settings, etc. A file sourcetable.dat is maintained as data is received from the NTRIPCaster (NTRIP, 2007), containing Caster, Network, and Stream information and other details. Several BKG authorised NTRIPclients are available to source NTRIP caster information.

NTRIP casters or broadcasters from around the world can be selected depending upon the availability or limitations of authentication details. Settings such as com port and IP address can be specified in a settings window. In either case the data streams are instantaneously fed to the specified output at the selected data rate and IP ports. Generally, the stream is available through local host address 127.0.0.1 if the client is running on the same machine.

NTRIP supports Virtual Reference Station (VRS), which means that the user can send its approximate position in NMEA format through the GIR to an NTRIPCaster. However the end server must support this function to cater for such requests. In response, a Caster supporting the VRS mode can provide a user-specific data stream for the supplied position.

4.7.3 Raw Data Acquisition (Author’s contribution)

RTCM*.* streams become available through an IP or serial port and a decoder is therefore required for clients processing the RINEX or ASCII format. The RTCM decoder from BKG is available, but required modification. Experimentation revealed that although the decoder worked correctly in terms of reading the serial or IP ports, it did not correctly decode the received message.

Another client BKG NTRIP Client, BNC v2.3 has been developed under GPL by BKG (2007). It can retrieve real-time GNSS data streams through various global sources, broadcast over IP and generate RINEX3.* or RTCM3.* streams. It can interface with serial communication for Variable Rate Applications (VRA) and broadcast to other GNSS engines around the globe. Precise point-to- point functions can be supported for remote rover stations.

Two separate Java code fragments were written to cache data from the local serial port and NTRIP stream:

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

a. SerialPoller: Java code is written to read stream output from the COM port string-by- string. It has been integrated with the mainstream code for seamless performance.

b. NTRIPPoller: This Java class is written to poll the NTRIP client and extract disseminated data by NTRIP casters and servers. Its integration with the OSGRS source code allows for seamless acquisition and storage of NTRIPCaster broadcast through TCP/IP protocol.

4.8 Acquisition Unit Testing

As the user selects the appropriate NTRIP 1 or 2 stream from the user interface (Figure 4.7), the request is XML-parsed and validated by the server. If a valid source is connected and a response is available, the data is sent to the Document Object Model to be sent back to the client, otherwise the ‘GNSSErrorResponse’ message is displayed.

The most important set of observables are carrier phase, pseudorange and observation time. RINEX3.0 incorporates new observation types, with the possibility to track frequencies on different channels, thus providing flexible and more detailed definition of the observation codes. It also includes the potential of mixed files, multiple satellite data support, multiple GNSS data support, record of data structures, and is free from the 80 character width constraint (RINEX3, 2007). The RINEX version 3.0 format consists of three ASCII file types:

a. Observation data File b. Navigation message File c. Meteorological data File

The OSGRS client is executed after compiling and building the Java code. The required data source is set as NTRIP and the “send” button pressed. As NTRIP data is requested by the client, the OSGRS server responds by querying the request specific information in the preselected NTRIP caster’s cached information file. This data can be a real-time incoming data or periodically cached on hard-drive. Figure 4.7 demonstrates how the source stream or requested data is checked as NTRIP in the OSGRS client window. The user can specify its own position in lat/long to acquire more accurate assistance information. However the specified NTRIP casters must support NMEA or VRS or user input functions to serve such requests.

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Figure 4.7 Multiple Assisted-GNSS Streamcast, OSGRS v2.0

The user can specify any caster subject to third party discretion on authentication and authorisation. The client interface communicates the input parameters to the respective caster to request information through the XML parser. Input can be received through storage files or using a real- time serial port reader. GNSS information can be specific or dynamic, depending on the broadcaster. NMEA inputs from a locally-connected GPS receiver may be communicated in VRS mode in real-time across the globe for MS-Based assisted GNSS differential position calculations.

The received RTCM or RINEX streams sometimes need to be translated, depending on type of application for user. In case of error ‘GNSSerror’ response is displayed in the response window. Carrier phase, pseudorange and observation time are acquired from output stream, in addition to other observation types, etc. After selecting appropriate parameters and pressing the “send” button, the system acquires relevant assistance data in a specific format on an epoch-by-epoch, as shown in Figure 4.8 (DMZ Client-Server Config with Debug Mode).

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Figure 4.8 OSGRS Operation on a Mobile Device

4.8.1 Parameter Translation

Once the appropriate options are specified, the user can press the “send” button to retrieve periodically cached information from the server. The server URL information is the IP address that the OSGRS server is connected to. Position information is optional, and allows the OSGRS to acquire observation data optimised for that location. In this case, an NTRIP datacast was downloaded from stream 1, as shown in Figure 4.7. The system returned the relevant positioning data in translated RINEX3.0 format.

4.8.2 Observation Data

Figure 4.9a shows an epoch of observation data stream. GNSS system specific observation types can be read as per the RINEX3.0 standard specifications in Table 4.3. Pseudorange (PR) is defined as:

PR (metres) = distance + c * (receiver clock offset - satellite clock offset + other biases) eq.4.1 where

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

c = speed of light

Figure 4.9a Observation data stream

4.8.3 Navigation Data

A navigation data stream acquisition from the system is shown in Figure 4.9b. Depending on whether it is a MS-based or MS-assisted GNSS architecture, this data can be fully or partially processed on the server and/or client for A-GNSS applications. Meteorological messages or data can also be retrieved in a similar fashion.

Figure 4.9b Navigation data stream

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Table 4.3 describes the detailed translation of each epoch or code observation parameter in RINEX3.0. The RINEX acquisition method used in the initial phase of this research, acquired data samples and their description are detailed in Chapter 2.

Table 4.3 Observation data description (RINEX3, 2007)

Observation Codes System Frequency/Band Channel or Code Pseudo Range Carrier Phase Doppler Signal Strength C/A C1C L1C D1C S1C PC1PL1PD1PS1P Z-tracking and similar C1W L1W D1W S1W L1 1575.42 YC1YL1YD1YS1Y MC1ML1MD1MS1M Codeless -- L1N D1N S1N C/A C2C L2C D2C S2C L1(C/A)+(P2-P1) C2D L2D D2D S2D L2C (M) C2S L2S D2S S2S GPS L2C (L) C2L L2L D2L S2L L2C (M+L)1 C2X L2X D2X S2X L2 1227.60 P C2P L2P D2P S2P Z-tracking and similar C2W L2W D2W S2W Y C2Y L2Y D2Y S2Y M C2M L2M D2M S2M codeless -- L2N D2N S2N I C5I L5I D5I S5I L5 1176.45 Q C5Q L5Q D5Q S5Q I+Q C5X L5X D5X S5X G1 1602+k*9/16 C/A C1C L1C D1C S1C i.e. k= -7...+12 P C1P L1P D1P S1P GLONASS C/A (GLONASS M) C2C L2C D2C S2C G2 1246+k*7/16 P C2P L2P D2P S2P A PRS C1A L1A D1A S1A B I/NAV OS/CS/SoL C1B L1B D1B S1B E1 1575.42 C no data C1C L1C D1C S1C B+C C1X L1X D1X S1X A+B+C C1Z L1Z D1Z S1Z I F/NAV OS C5I L5I D5I S5I E5a 1176.45 Q no data C5Q L5Q D5Q S5Q I+Q C5X L5X D5X S5X I I/NAV OS/CS/SoL C7I L7I D7I S7I Galileo E5b 1207.140 Q no data C7Q L7Q D7Q S7Q I+Q C7X L7X D7X S7X I C8I L8I D8I S8I E5(E5a+E5b) Q C8Q L8Q D8Q S8Q 1191.795 I+Q C8X L8X D8X S8X A PRS C6A L6A D6A S6A B C/NAV CS C6B L6B D6B S6B E6 1278.75 C no data C6C L6C D6C S6C B+C C6X L6X D6X S6X A+B+C C6Z L6Z D6Z S6Z L1 1575.42 C/A C1C L1C D1C S1C I C5I L5I D5I S5I SBAS Q C5Q L5Q D5Q S5Q L5 1176.45 I+Q C5X L5X D5X S5X

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

4.9 Positioning Unit Testing and Data Collection

Testing was carried out on a marked track (Level 4) of the Electrical Engineering Building at the University of New South Wales, Sydney (Figure 4.10). The marked track represents high difficulty level signal scenarios ~ 10 (Sarwar et al., 2011) with minor variations in or around the corridors, corner walls and hallways. Indoor signal blockage, absorption or attenuation varies depending on different materials.

A windows based computer executed the OSGRS server through Eclipse IDE and a Novatel OEM 3 GPS receiver was connected through the Ethernet port. The receiver was connected to the Antenna mounted on the roof of Electrical Engineering building. Depending upon the type of configuration used (highlighted in section 4.13) a wired or wireless connection can be used by the remote or rover client which can subsequently affect the TTFF performance. System configuration is further discussed in section 4.15.

Following the request of assistance from the mobile node connected to the GPS and laptop, the client sends the location query to the server.

Figure 4.10 Test Bed Map at L4 EE UNSW

In such system a constant time delay can be added, known as k ~ 0-300 ms (Marotti, 2004), to simulate processing time. It is assumed that computing the final value will take a few milliseconds and a constant value needs to be integrated in the resultant calculations. This provides the actual Round Trip Time (RTT) of complete request-response processing cycle for a better estimate of the 92

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

TTFF. E911 generally requires location-based emergency data to be available with an accuracy of 50m or better, 67% of the time, and 150m within 95% of the time for handset-based device implementations. For network-based services the accuracy requirements are 100m (67%) and 300m (95%) (E911, 2009). Experimentation has been conducted in the aforementioned test area. Localization data from the OSGRSv2 and subject devices (explained in section 4.11) has been collected in Table 4.4. Test results are explained in section 4.12.

Table 4.4 Data collection and Results

Failure Rate No of Satellites TTFF Availability Accuracy(m) Overall Excl. Indoors SPOT 4.8 544 40.2 25 59.8 49.75 MS-Assisted 6.8 11.6 98.5 9.9 1.5 1.1 AGNSS MS-Based 7.3 11.8 99.8 9.9 0.2 0.15 HS-GNSS 5.8 40.8 86.7 10.2 13.3 9.98 WSNAGNSS* 7.5 1.9 99.98 3.1 0.02 9.78 MGNSS OSGRS 10 1.5 99.99 2.5 0.01 0.01

4.10 Benchmarked Devices

Benchmarking was conducted by comparing the performance of the following devices in similar scenarios:

a. Garmin eTrex GPS System and SPOT Satellite Messenger b. Secure User Plane Location (SUPL) enabled device (Assisted-GNSS MS-Based mode) c. Secure User Plane Location (SUPL) enabled device (Assisted-GNSS MS-Assisted mode) d. High Sensitivity GNSS device MiO A701 (SiRFStar-III) e. Wireless Sensor Networks Assisted-GNSS (WSNAGNSS)

The Garmin eTrex is a commonly used “normal sensitivity” GPS receiver. The SPOT satellite messenger is a GNSS tracking device employed by remote bush walkers. SUPL was first proposed by the Open Mobile Alliance (OMA) in 2007 and connects the client to third party A-GNSS location server over TCP/IP, helping the user calculate its position through a third party Assistance Server. Wireless sensor networks can provide a “hot-start” position fix, which makes acquisition in some ad hoc environments quicker (Mautz et al., 2007), unlike some systems that are heavily reliant on mains power (Ganeriwal, 2003). Similar wireless systems can be time inefficient due to

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

comprehensive code and frequency bin search (Garin, 2010). Regardless of the mobile phone technology used (GSM, EDGE, UMTS or LTE), cellular network coverage inside buildings may sometimes experience poor reception due to low signal levels. Wireless Sensor Networks have been shown to effectively provide assistance indoors better than (Sarwar et al., 2011). Requiring wireless connectivity is impractical when many WiFi access points may themselves have failed during an emergency (Lorincz et al., 2006). If the difference between signature distance s and reference signature r is known, the Manhattan distance metric (for received signal strength) defines the absolute difference relationship between sent and received signals as:

M (r,s) = ∑ t€T |mean RSS(t)r Ð mean RSS(t)s| eq.4.2

Such testing considers attenuation through different materials, for example a drywall, glass or plywood wall causes low signal attenuation, approximately 1-3dB compared to bricks or concrete which cause attenuation between 5-33dB (Stone, 1997).

Enclosed buildings can cause attenuation levels around 5-15dB (residential houses), 20-30dB (office buildings) and >30dB in car parks, underground and undercover tunnels (Mautz, 2009). Figure 4.11a shows the system architecture and logical working of a reference signature based WSN-supported GNSS system. The mobile node is connected to a portable computing device and display and fixed nodes are deployed within the green highlight footprint on map. Figure 4.11b shows the operational architecture of the MiO A-GNSS system employing the processing power of a third party back-end server, which can provide positioning assistance in either MS-Based and MS-Assisted mode.

Figure 4.11a WSNAGNSS System

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

The MiO handset contains a “high sensitivity” GNSS chipset (SiRFStar-III ~ 169dBm) for stand- alone GNSS positioning. Figure 4.11c shows the architecture of the SPOT Satellite Messenger, which can relay its positioning parameters through commercial Low Earth Orbit Satellites, which in-turn relay the information to ground-based IP networks and emergency assistance services (Sarwar et al., 2011).

Figure 4.11b. Mio A-GNSS system c. Spot Messenger System

4.11 Experimentation Results

Where a “medium sensitivity” GNSS chipset observed approximately four satellites and could not provide a fix, the OSGRS-assisted GNSS receivers tracked more than 10 satellites with the lowest TTFF of 1.5s. The OSGRS-assisted receiver demonstrated highest availability of 99.99% with an accuracy of about 2.5m. Overall failure rate was 0.11% in obstructed, and 0.1% in unobstructed, environments. WSNA-assisted GNSS was the second best performer with a reasonably low TTFF. A time delay constant k of approximately 300ms has been added (to account for the total processing and computation time) to give the estimated TTFF of 2.2s. The “high sensitivity” GNSS had a higher TTFF than the MS-Based A-GNSS, which had a difference of 0.2s. The SPOT Satellite Messenger had the highest TTFFs, and suffered the lowest availability.

Figures 4.12 (a, b, c, d, e & f) show the performance graphs of all devices against the OSGRS for the following parameters:

a. Satellite Visibility b. Time to Fix First (TTFF) c. Diverse Availability d. Localisation Accuracy 95

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

e. Failure Rate (Obstructed/Overall) f. Failure Rate (Unobstructed)

It is evident that an OSGRS-assisted GPS receiver tracked the highest number of satellites (10 or more) compared to other devices, and gave the lowest TTFF (1.5s). The system also demonstrated the highest availability, though the difference from WSNAGNSS was very low (0.01%). The average recorded accuracy was approximately 2.5m in the testing area. However, significant differences were recorded between the two closely performing systems for the parameters of Failure Rates (Unobstructed ~ 8.68%) and Satellite Availability (>0.25%).

Satellite Visibility TTFF(s) 15 600 544 10 10 6.8 7.3 7.5 400 4.8 5.8 5 200 11.611.840.8 1.9 1.5 0 0 Device Benchmark Device Benchmark

SPOT MS-Assisted SPOT MS-Assisted MS-Based HS-GNSS MS-Based HS-GNSS WSNAGNSS OSGRS WSNAGNSS OSGRS

Figure 4.12a. Satellite Visibility b. Time to Fix First

Availability(%) Accuracy(m) 150 30 25 99.8 99.9899.99 98.5 86.7 100 20 40.2 9.9 9.9 10.2 50 10 3.1 2.5 0 0 Device Benchmark Device Benchmark

SPOT MS-Assisted SPOT MS-Assisted MS-Based HS-GNSS MS-Based HS-GNSS WSNAGNSS OSGRS WSNAGNSS OSGRS

c. Availability d. Accuracy

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Overall Failure Rate(%) Non-Obstructed Environment 80 59.8 Failure Rate(%) 60 100 40 49.75 20 13.3 50 1.5 0.2 0.020.01 1.1 0.159.989.780.01 0 0 Device Benchmark Device Benchmark

SPOT MS-Assisted SPOT MS-Assisted MS-Based HSGNSS MS-Based HSGNSS WSNAGNSS OSGRS WSNAGNSS OSGRS

e. Failure Rate (Overall) f. Failure Rate (Unobstructed)

4.12 Configurations and Relative Performance Cost

The OSGRS is capable of operating in three configurations with respect to the physical and/or logical location of the client and/or server. This can influence the TTFF performance of the OSGRS in different ways, due to several factors such as network transfer latency, lead time, initialisation processing, computation time, network architecture and operational data complexity and/or the full- cycle computation combination of all of these. Wirolla (2011) has reported on the effects of network latency on TTFF performance. RTT constant values have been estimated and can be added to the TTFF value to estimate the final time fix value.The configurations are described below.

a. PC-Client-Server

Client and Server running on the same PC within or outside the reference receiver domain from where the client requests the position fix. The RTT constant (k) value is estimated to be approximately 0.13s.

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

b. DMZ-Client-Server

Either of Client or Server runs outside the reference receiver domain, with other on the inside. This is referred to as the Demilitarised Zone (DMZ) configuration. They can communicate through the pre-established VPN connection. Estimated RTT constant k is 0.45s.

c. Cloud-Client-Server

Client and Server running on the same PC with mobile device outside the reference receiver domain being able to acquire partially processed and calculated assistance. This mode has more portability with higher RTT constant value estimated at approximately 0.99s.

It is evident from Figures 4.13 (a, b & c), the lowest TTFF is obtained from configuration (a) due to lower computation cost associated. This justifies its use for this experiment despite its lower flexibility and lower portability in comparison to other configurations.

TTFF(s) TTFF(s) TTFF(s) 600 544 600 544 600 544

400 400 400

200 200 200 11.611.840.81.91.63 11.611.840.81.91.95 11.611.840.81.92.49 0 0 0 Device Benchmark Device Benchmark Device Benchmark

SPOT MS-Assisted SPOT MS-Assisted SPOT MS-Assisted MS-Based HS-GNSS MS-Based HS-GNSS MS-Based HS-GNSS WSNAGNSS OSGRS WSNAGNSS OSGRS WSNAGNSS OSGRS

Figure 4.13 Config a. Config b. Config c.

4.13 Source Code Architecture

The OSGRSv2 can easily operate in either MS-Based or MS-Assisted modes, within intranet or VPN extranet. This section describes the changes this expansion brings in context of support for RTCM and RINEX data formats. On the server side, the main libraries to change are ‘Data Source 98

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

Managers (DSM)’ for ‘GNSS Request Parser’, ‘Response Writer’, ‘Request Manager’, ‘Response Manager’, ‘Data Cache’ and ‘Error Response Writer’. On the client side, main libraries ‘Graphical User Interface(GUI)’, data sourcing methodologies, html parsing routines and data retrieval functions have been expanded to provide additional functionality. Some new routines such as ‘Ntrip Poller’ and ‘Stop Crash’ were implemented with null checkers to support new Data Source Connectors. System configuration files have been written to adapt to new features of data logging, cache retrieval, and XML schema parsing. Old and new code comparison reflect code changes for all libraries. This quantifies the changes and helps in code tracking. GNSS source flexibility, higher availability, cost efficient expansion, easy testing, low TTFF and higher sensitivity are some of the advantages of the enhanced OSGRS design for location-based and A-GNSS applications.

4.13.1 Project Structure

4.13.1.1 Client Side (Author’s contributions as highlighted)

Below is the project structure on the client side, which has been enhanced with the aforementioned functionality. Each class function is self-explanatory on the basis of their names.

~ OSGRSClientUI ~ OSGRSClientRequest ~ GNSSRequestWriter ~ GNSSUtil ~ DebugLogger ~ GNSSResponseWriter ~ DebugLogger ~ GNSSRequest ~ GNSSResponse ~TestOSGRSClient

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

4.13.1.2 Server Side (Author’s contributions as highlighted)

The server side project structure is shown below. Server side code, and hence the processing is more complex, where the function of each class can be inferred from the class name.

~ OSGRS ~ HTTPServer ~ DataManagement ~ DataSource ~ DataSourceManager ~ NovatelSourceInterface ~ NTRIPSourceInterface ~ NTRIPPollerEngine ~ NTRIPPollerConfig ~ NTRIPPollerTest ~ SerialSourceInterface ~ SerialPollerEngine ~ SerialPollerConfig ~ SerialPollerTest ~ GNSSDataCache ~ DataType ~ AlamancSatelliteParameters ~ DataType ~ GPSAlamanc ~ GPSDateTime ~ IonUTCModel ~ RawAlamanc ~ RawIonUTCModel ~ ReferenceTime ~ RTI ~ SatelliteEphemeris ~SatelliteInView ~ DataTypeTesters 100

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

~ AlamancSatelliteParameterTester ~ GPSAlmanacTester ~ IonUTCModelTester ~ RawAlamanacTester ~ RawIonUTCModelTester ~ ReferenceTimeTester ~ RTITester ~ SIVTester ~ GNSSDataCache ~ GNSSResponseWriter ~ GNSSUtil ~ ReferenceTimeTester ~ BitMask ~ DebugLogger ~ GNSSRequestWriter ~ AzimuthElevation ~ AlamancSatelliteParameters ~ GPSDataTime ~ ConfigManager ~ NovatelOEM3ConfigFile ~ NovatelOEM4ConfigFile ~ NTRIPConfigFile ~ SerialConfigFile ~ SystemConfig ~ PositionCalculation ~ AzimuthElevation ~ SatellitePosition ~ SIVGenerator ~ WGS84ECEFXYZ ~ NovatelDataSourceConnector ~ NovatelOEM4Source ~ NovatelDataSourceConnector ~ NovatelLog ~ NovatelLogCache 101

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

~ NovatelLogProcessing ~ NovatelOEM4SourceConfigFile ~ NovatelOEM4SourceDataFile ~ NovatelOEM3Source ~ NovatelDataSourceConnector ~ NovatelLog ~ NovatelLogCache ~ NovatelLogProcessing ~ NovatelOEM3SourceConfigFile ~ NovatelOEM3SourceDataFile ~ DocumentObjectModel ~ RequestObjectModel ~ DocumentObjectModel ~ ResponseObjectModel ~XMLProcessing ~GNSSErrorResponseWriter ~GNSSRequestParser ~GNSSResponseWriter ~RequestManager ~RequestValidator ~ResponseManager

4.13.1.3 XML GRIP Schemas

The following GRIP schemas in XSD file format are employed to request, parse and display XML data. They contain and specify the relevant and valid arguments to request and process data:

~ CommonDataTypes ~ GNSSErrorResponse ~ GNSSRequest ~ GNSSResponse

These schemas and their relationships to the OSGRS architecture and the GRIP protocol are discussed in detail in Appendices A & B. 102

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

4.14 Installation and Configuration

‘OSGRSClient’ is the actual client for the server interface. Some system requirements are to be met for successful installation of application package. First, a Java compiler and Virtual Machine for the target platform is required. Data sources should also be set up in the relevant compiler. The OSGRS set of source files are openly available for download, and need compilation and building by the user. Modification of each module or class should follow the author’s explicit guidelines and comments within the source codes. The following Java libraries need to be installed and referenced in the Eclipse IDE compiler to support the OSGRS client, server and serial reader. Some of these are built into the Eclipse, depending on the version used, otherwise they should be copied into OSGRS/Tools folder on the main drive.

i. http Commons Codec v1.3 or 1.4 ii. http Commons FileUpload v1.22 iii. http Commons Client v2.0 or 3.1 iv. http Commons Logging v1.11 v. http Components Client v4.03 vi. Jetty Client/Server Libraries v6.13 or 6.14 vii. Org J.unit 3.82 or 4.81 viii. Xerces 2.10 and J-Tools ix. Servlet API(s) x. Commons Apache Libraries xi. Rxtx Libraries xii. Javaxcom

Install ‘OSGRSClient’ files in driveletter:\tempworkspace2\mytest2\src\OSGRSclient. Copy the util function in the util subdirectory. For the server setup, install the ‘OSGRSServer’ files in driveletter\tempworkspace\mytest\src\OSGRS\*miscdirectories. The miscellaneous directories are:

i. DataManagement: Data source selector and processing ii. Datatype: Data type specification by user iii. DataTypeTesters: Data type specification tester iv. HTTPserver: Server host and serving client response v. Novateloem3: Novatel OEM3 data acquisition 103

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

vi. Novateloem4: Novatel OEM4 GPS data acquisition vii. OSGRS: Server source code viii. PositionCalculation: position calculation function ix. Util: Utility files x. XMLprocessing: XML parsing files

Copy the GRIP schema files in driveletter:\temp\OSGRS\GRIP schemas. These are XSD extension files for the four commonly used data types. Also create driveletter:\temp\OSGRS\xmlWorkingDirectory for XML workspace for code compilation and temporary file keeping. Use Eclipse IDE compiler for code compilation in separate sessions for client and server as above. The benefit is ease of use, flexibility and readily available trouble- shooting tools. Install a NTRIP client such as the GNSS Internet Radio or BNC v2.* which is available from the BKG website for the appropriate operating system. ‘Manual Activate’ can be used, or there is an auto-start option to receive data automatically after start-up. Windows XP client can be set to auto-start, which will make the program run on an account automatically, bypassing the login prompt. The NTRIP client should be running before the OSGRS server is started up in order to give it a head-start in acquiring broadcast data from casters. This will also enable the OSGRS server to readily start accessing the streamed data according to user preferences.

4.15 Support, Redundancy and Licensing

The School of Surveying & Geospatial Engineering at UNSW operates a Continuously Operating Reference Station (CORS) for research into A-GNSS and Multi-GNSS projects. The OSGRS is licensed by the General Public Licence (GNU, 2007), a free licence which allows modification and enhancements to hardware and software systems to be made with minimal legal requirements. Technical support is available from key contacts involved in the project.

104

Chapter 4 Assisted Multi-GNSS Server, OSGRSv2

4.16 Concluding Remarks

The OSGRSv2 has proven to provide better indoor availability, flexibility, low TTFF and higher sensitivity. OSGRS assisted GNSS system tracked 10 or more satellites - higher than other devices. The recorded TTFF was approximately 1.5secs which was the lowest. System availability was high with an accuracy of approximately 2.5m in the test area. The OSGRS data transfer takes place through TCP/IP and can alternatively be transported via mobile communication channels. However, the client application needs to be simplified for widespread adoption. Data latency issues need to be investigated further. Researchers believe data latency to adversely affect TTFF values up to 10secs or more in some multiple network configurations. Commercial applications can include use in crime prevention; emergency and incidence respond management, product tracking at industrial sites, wildlife habitat monitoring, home control in addition to location based services, advertising, user guidance, communication network routing and asset tracking.

105

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

The Radio Resource Location Protocol (RRLP, 2011) was proposed by the Third Generation Partnership Project (3GPP) primarily to provide efficient data transfer and network capability for applications such as Location Based Services (LBS). This is achieved by exploiting Third Generation (3G) or the next generation Long Term Evolution (LTE) mobile network’s Assisted- GNSS and high bandwidth capability. The 3GPP LTE positioning protocol (LPP) provides the basic infrastructure roadmap for the high accuracy positioning assistance model through control plane bandwidth channels in mobile access and core communication networks. LPP can perform well in conjunction with the Open Mobile Alliance’s (OMA) Secure User Plane release 3 (SUPLr3) based extension (LPPe). Combining the constrained control plane with the relatively unconstrained user- plane bandwidth alleviates network limitations by exploiting priority-based traffic deviation. Where Secure User Plane (SUPLr1 & r2) provided the positioning functionality through conventional mobile communication systems, SUPLr3 extended the positioning parameter portfolio laying the baseline for LPPe (3GPP RRLP, 2011), (3GPP LPPr1x, 2012), (OMA, 2007), (OMA, 2009) and (OMA, 2011).

This chapter proposes an augmented architecture for LPP and LPPe based LTE mobile networks using the third generation Open Source GNSS Reference Server (OSGRSv3). Interconnection of two networks is provided through IP data control gateways for information exchange. This expands the current Assistance Model Portfolio of Multi-GNSS OSGRSv3 and establishes its interworking characteristics with several mobile communication systems. Current LPPe protocol, and on-going Core Network and Transmission technology evolution are discussed, with a future outlook to outline reasonable design strategies for such bandwidth hungry and higher data rate applications. A real network scenario has been implemented in a controlled laboratory of a mobile carrier network environment exploiting LTE Radio Access Network (RAN), Transmission, Core and GNSS elements to test the performance of the proposed system. Preliminary interface parameters with link performance graphs are presented. An RRLP-based system can potentially lower time-to-first-fix (TTFF) and improve availability and accuracy over the earlier OSGRSv2 with LPPe enhancements by concatenating the functionality of High Sensitivity GNSS, RINEX, RTCM and NTRIP.

106

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

System development timeline is presented as follows:

a. OSGRS v1.0 (2007): OSGRS v1.0 was limited to support a local, single GPS sources such as the Novatel OEM (3&4) receiver. This was a local client-server architecture requiring both ends of the system to be within the same WAN domain. This required the client to have a Virtual Private Network (VPN) connection into the specified network of server. GRIP protocol architecture is demonstrated in (Sarwar et al, 2012).

b. OSGRS v2.0 (2011) (Author’s contribution): Improvement was needed to provide support for other GNSS systems and to globalise the server access to provide anywhere/any-system architecture, multi-format output and increased integration flexibility. Second revision incorporates the addition of global GNSS data sources available through NTRIP. This makes it a multi-GNSS A-GNSS system Ð which may be called MGAG. This version can run the client-server virtually anywhere without any private network or VPN connection limitations.

c. OSGRS v3.0 (2012) (Author’s contribution): The third release is based on Radio Resource Location Protocol (RRLP) functionality and it employs the next generation mobile communication network to source GNSS parameters. This data is transferred through the network to be communicated on the user handset.

d. OSGRS v4.0 (2013) (Author’s contribution) (Under Proposal): The proposal suggests a simplified and flat architecture, smart user access and interface and converged positioning network elements based on latest release(s) of Radio Resource Location (RRLP) and Secure User Plane Protocol(s) (SUPL).

5.1 Introduction

There are a several challenges for current A-GNSS technologies, expected to operate everywhere (every time and anytime) with low TTFF in any environment (Wirolla, 2011). Commercial and proprietary protocols typically have interoperability and licensing issues, thus limiting independent research and academic testing. In some parallel processing and acquisition environments, Fourier Transforms have proven to improve time and frequency domain search and processing, and hence

107

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

to reduce the TTFF (Turunen, 2007). Accuracy and availability of stand-alone GNSS is influenced by attenuation and degradation in weak signal environments (Brown et al., 2006). A standard GNSS chipset could take approximately 60s to compute the first position fix (Diggelen, 2009). E911 requires time and response critical devices to provide acquisition 95% within 150m accuracy, and approximately 65% within 50m accuracy (FCC, 2009; LaMance, 2005).

The Open Source GNSS Reference Server (OSGRS) is a java application that provides assistance data from local and global GNSS casters (Chapter 4). The system has been revised over the last few years to expand the assistance model parameter set, format support capability (hardware and firmware) and improve performance (accuracy, availability and TTFF). The Novatel OEM4 receiver was yused in release 1 (OSGRSv1, 2007) and global casters (e.g. MGEX, 2012) and NTRIP were used in release 2 (OSGRSv2, 2011). The scheme can be categorised as Multi-GNSS Assisted-GNSS, capable also of providing Differential GNSS and Real-Time Kinematic centimetre- level accuracy (Figure 5.1) (Sarwar et al., 2012).

Figure 5.1 Multi-GNSS OSGRSv2

This chapter proposes a further revision of the system Ð OSGRSv3 Ð which employs the enhanced capability of the Radio Resource Location Protocol (RRLPr11) over mobile communication networks. The expanded assistance model portfolio is presented with a real network architecture that carries GNSS and assistance data over control and user planes of the mobile network simultaneously.

108

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

5.2 Radio Resource Location Protocol (RRLP)

In mobile communications, the RRLP release 8 to 11 have been proposed (3GPP, 2012) (Release 12 in progress) for advanced positioning in mobile GSM, EDGE, UMTS and LTE networks. Figure 5.2 shows the evolution of several mobile network standards over the last decade (3GPP, 2012; Youl et al, 2008). Currently, the network supports conventional GNSS (GPS L1/L2 with C/A), Galileo and other GNSS, and Enhanced Observed Time Difference (E-OTD) data to be transported over control plane channels of a radio base station (RBS) site.

Figure 5.2. 3GPP Standards Evolution

The mobile network can support transfer of location information data from a Serving Mobile Location Centre (SMLC), where Gateway Mobile Location Centre (GMLC) acts as the first point of interconnect with Location Communication Server (LCS) client. SMLC and its associated services can exist as a stand-alone unit or co-exist within the GMLC, depending on the type of positioning network architecture. Figure 5.3 shows the building blocks of a mobile network and their interconnections with respect to the Base Station (BTS), Base Station Controller (BSC), Mobile Switching Centre (MSC), SMLC and GMLC. SMLC works in conjunction with Location Measurement Unit (LMU) modules using TOA, TDOA, OTDOA or E-OTD methods (Chapter 2, Section 2.6) to provide the positioning parameters.

The GMLC serves as a cross-connection and translation gateway for the SMLC to external location servers or clients such as OSGRS. Basic location parameters are acquired by the base station on a RAN and transmitted to the SMLC in the core network for location estimation. The SMLC can then work in conjunction with GMLC to acquire assistance from third party client (working on the framework of LPPe) and respond (Figure 5.3).

109

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

Core Network Processing Location Detection, Calculation and Measurements

User Access End

Lb SMLC Lp SMLC

HLR Ls LCS Client Lh

User End Air BTS (LMU Type RAN Access Abis BSC/RNC A MSC/VLR Lg Gateway MLC Le Interface B) Mobile Station

GGSN SGSN

WAP/IP Gateway MLC Router (Other Cellular Network)

External Network

Figure 5.3 Mobile Communications Network e-Node B or BTS to RNC connectivity is referred to as the Radio Bearer (RB) and RNC to MSC and SGSN are called the Iu bearers (3GPP, 1999) (Figure 5.3). Modular interfaces of a cellular network are defined in Table 5.1.

110

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

Table 5.1 Cellular network interfaces

Connectivity Classification Bearer Name 1Mobile Station to RBS/BTSUu/Air Interface 2RBS/BTS LMU to SMLC Lb 3SMLC to SMLC Lp 4RBS/BTS to BSC/RNC Abis/Iub 5BSC/RNC to SGSN Gb 6BSC/RNC to MSC/VLR A/IuCS 7MSC/VLE to GMLC Lg 8BSC/RNC to SGSN IuPS 9GMLC to HLRLh 10 GMLC to LCS client Le

Figure 5.4 shows the RRLP capability matrix to provide location assistance services in a mobile communications network (RRLP, 2011; Wirolla, 2011). The E-OTD Assistance Data Set primarily includes the reference data based on OTD BTS measurements. On the other hand, the GNSS Assistance data set includes reference time and location, navigation and Ionospheric models, UTC model, almanac, ephemeris and integrity specific information. The Galileo and additional navigation satellite systems based assistance data includes all of the aforementioned plus the Earth orientation, inter-GNSS Time Model, data bit assistance and auxiliary information.

Figure 5.4 RRLP Assistance Model 111

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

5.3 LTE Positioning Protocol (LPP) and LPP Extensions (LPPe)

LPP was proposed to carry the bare minimum GNSS parameters on the control plane of LTE (3.9G) and LTE advanced (4G) networks. It is a self-contained protocol to provide basic GNSS services for emergencies and law enforcement services (3GPP, 2009). The protocol predominantly employs RRLP based RAN cell localisation methods in GSM, W/CDMA, UMTS or LTE networks. LPP utilises several transceived (Tx/Rx) signal characteristics for location determination of a mobile user. Such techniques include Enhanced Cell ID (ECID), Base station position, Transmit power, Round Trip Time (RTT), Antenna gain, Azimuth, Beam width and Frequency drift. Based one or a combination of such techniques, several methods can be employed for location estimation (Ericsson, 2011).

5.3.1 Positioning Techniques

Some of the following positioning techniques have been discussed in detail in Chapter 2, section 2.6. With their respective advantages and disadvantages, Time Difference of Arrival (TDOA), Cell Identification, Enhanced Observed Time Difference (E-OTD), Observed Time Difference of Arrival (OTDOA), Database Correlation Method (DCM), Pilot Correlation and OTDOA Idle Period Downlink (IPDL) are commonly used techniques for cellular networks based positioning (3GPP, 1999) (3GPP, 2000) (Wigren, 2007).

Database correlation method employs power delay profile of self-aware nodes and their locations as opposed to GSM which employs received signal strength. DCM simulation results have demonstrated 67% availability within 25m and 95% availability within 140m. On the other hand, OTDOA technique demonstrated 67% availability within 97m and 95% availability within 620m. OTDOA can assist to alleviate multipath problems however delay profile measurements have not been standardized (Ahonen et al., 2003).

Pilot correlation employs a database with pre-measured samples of received signal code power measurements of visible pilot nodes. Such method is network based and requires minimal hardware/software modifications within the user handset. Using pilot correlation, real network testing in an urban environment demonstrated 67% availability between 60-90m and 95%

112

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

availability between 130-180m. Whereas, simulation results based on Cell ID plus RTT produced 67% availability between 50-75m and 95% availability between 150-200m (Borkowski et. al, 2004). (3GPP TSG-RAN WG1, 1999) and (3GPP TSG-RAN WG1, 1999) have reported Time Aligned IPDL based simulation results of 67% error between 8-218m and 90% error between 6- 193m, which are large value spreads. RTT can be employed to evaluate the distance between the RBS and end-user where the transmit/receive values are higher for UMTS resulting in accuracy range of approximately 36m. A subset or superset can be created using the RTT values from neighboring RBS to calculate position (Wijesinghe, 2007).

Radio frequency fingerprinting measurements based positioning (Shi, 2009) has been included in the data set from LTE release 9 onwards. The technique is based on radio frequency fingerprinting, velocity predictions and site survey databases (3GPP, 2011).

5.3.2 LPP/e Data Transmission: Control Plane vs. User Plane

Predominantly, an LTE positioning architecture comprises of the LCS client, target and server. A physical or logical LCS server sources the positioning measurements on request of the LCS client to estimate the target’s location. The LCS server calculates the positioning parameters and velocity estimate based on radio parameters and other information. Many operators provide positioning by employing control and user-plane simultaneously. The Mobility Management Entity (MME) sends the positioning request to the SMLC or E-SMLC requesting the positioning data. Parameters such as user authentication, authorization and/or charging information are controlled by the GMLC. While the Secure User Plane (SUPL) application layer protocol such as LPPe sends additional and value added positioning services over data channels over user plan. Several technologies for the transmission of RRLP localisation data in an RAN network (GSM, EDGE, UMTS and LTE) over user and control plane protocols are available (Creativity Software, 2009) (Ericsson, 2011). Such technologies include Plesiochronous Digital Hierarchy (PDH) on TCP/IP Layer-1, Synchronous Digital Hierarchy (SDH) on TCP/IP Layer-1, Ethernet over SDH (EoSDH) i.e. TCP/IP Hybrid Translated Interconnection of Layer-1 and Layer-2, Carrier class Ethernet (CE) on TCP/IP Layer-2 and Multiprotocol Label Switching (MPLS) or IP on TCP/IP Layer-3

113

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

a. Control Plane

This is an integral part of a RAN to carry signalling, integration, control and access information. Obviously maintaining the integrity and security of information efficiently is capacity constrained and is limited to carry only bare minimum information, which is the reason it is predominantly used to carry LPP information (as discussed in detail in the next section), for E911 (e.g. distress rescue operations), LBS (e.g. GNSS assistance and/or correction), law enforcement (e.g. police calls) and network monitoring and/or control. As an example, the Short Messaging Service (SMS) was originally established for emergency and network control operations and has previously been proposed as a backup for transferring data on mobile phone networks in A-GNSS and LBS. SMS, location and control information flows through the control plane and SMS Centre, which has limited bandwidth (~2Mbps) and is subject to arbitrary blockage or latency.

Character limitation per channel can be an issue if the assistance data exceeds the limit allowed by mobile phone carriers. This can leave the end user in distress, with compromised message delivery confirmation. Other factors causing bandwidth contention include Mobile Number Portability, network congestion, Short Messaging Service Centre faults, unsynchronized Building Integrated Timing Supply clock (in Time Division Multiplexed or Ethernet networks), and incompatible software and/or hardware architecture at user-end. In the case of mobile transmission (PDH or SDH mode) layer, generic out-of-band control channels are 2Mbps bandwidth per mobile base station site. Channel contention cannot be completely resolved even after the standard mobile transmission networks transition to carrier Ethernet level, due to various factors and traffic deviation of enhanced positioning data will be required to channel control and user data appropriately. For effective usage of control plane, this bandwidth will need to be ‘feedback router optimised’ or enhanced, which isn’t a cost effective approach. Rather, enhancement of user plane bandwidth is considered feasible as it permits generic traffic capacity expansion for whatever purpose. b. User Plane

User plane signalling, on the other hand, is well established on call and data channels running on Layer-2 or Layer-3 channels (Ericsson, 2011). However with higher bandwidth and the potential to carry bandwidth heavy control and payload information, it has potential issues with security and

114

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

integrity. For most non-emergency, value-added services, charging, roaming and GNSS assistance information carriage, the user plane is the channel of choice. Mobile communication over internet protocol (MoIP) may be a cost effective alternative. UMTS, WiMAX or LTE networks are being deployed globally and will soon be available for high data rate communication of approximately 100Mbps or higher.

Benefits include relieving the control plane, in lieu of using relatively resource abundant data channels for effective throughput for A-GNSS data transfer applications. Secure User Plane Location (SUPL) also proposes to exploit the user plane for data transfer, which has considerably more bandwidth. Many operators therefore are considering the use of user plane to carry GNSS assistance data (Wirolla, 2011). Many devices have this capability, e.g. the MiO A701 uses SUPLr1.0 (Sarwar et al., 2009). However the protocol will struggle where mobile coverage is unavailable. End user location is estimated with the signal strength knowledge of the RBS, where location accuracy is dependent on coverage. Location is calculated in the Core Network by the SMLC, where GMLC interconnects with the external location server. The SUPL standard (OMA, 2007) specifies the requirements of traffic carried over user plane. The standard has been revised three times since its inception. SUPLr3 (2011) is the latest version based on first release (TCP/IP) and second release (geographic and temporal triggers), specifying the streaming requirements for LPPe assistance data with WLAN and local assistance data servers such as OSGRSv3.

5.3.3 Positioning Parameters Format

(3GPP, 2011) have reported seven positioning formats for LTE, UMTS and GSM which are associated to Geographical Area Description (GAD). The US emergency services can enforce additional requirements and permissions for the use of permitted GADs by cellular operators. Shape conversions may need to be applied for non-emergency compliant positioning parameter sets. Consequently, such measurements obviously result in reduced positioning accuracy (Wigren, 2010) in comparison to the parameter set carried by Emergency Response LBS centres (Ericsson, 2011). To reflect such positioning inaccuracies and confidence levels, several parameters have been included in the LPPe protocol (OMA, 2010). (IETF, 2008) have proposed the native, cost and resource efficient Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) for emergency centres. The civic address format can be directly associated to a radio node thus minimizing the need to convert localization results provided the positioning parameters and their accuracy and sufficiently accurate. The format is supported for user plane based 115

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

localization with US Emergency Number Association’s (NENA) technical requirements (NENA, 2006) (IETF, 2008).

5.3.4 Motivation

As discussed before, several radio networks based positioning technologies and architectures have been established over recent years. In addition third party based solutions such as Google Maps have evolved very quickly. Combining the multiple network standards is necessary to provide fast, reliable and accurate positioning parameters.

LPP extension containers were proposed to support the future development of protocol without drastically changing the LPP and hence to avoid overloading the control channel. The first extension LPPer1 was released in 2010 (OMA, 2010), and a candidate release proposed for approval (OMA, 2011) with standardisation expected to be finalised soon.

It is important to note some primary enhancements in SUPLr3 assistance data for specific applications. In OMA LPPe Release Candidate (RC), the field ‘AGNSS-CCPassistCommonProvide’ is mandatory (with some optional parameters like support area, reference station list, neighbour area etc.) in requesting basic information as Continuous Carrier Phase Assistance to provide millimetre- level accuracy positioning of target device. The parameter ‘phaseRangeRMSerror’ refers to the RMS error in carrier phase and ‘lockIndicator’ is true if tracking has been continuous, and false if it’s broken or a cycle slips. Support is being made available for a variety of GNSS.

The LPPe data sets include additional information elements thus providing environmental information suited to the navigation, data correction and assistance requirements of the target device. Such data sets include Validity area parameters and Ionospheric storm indications, Tropospheric delay model information, Satellite body-fixed coordinate frame, Navigation degradation models (e.g. clock model or orbit model) and solar radiation pressure, CRC16-IBM and antenna information (reference frame, Euler angles), A-GNSS and Enhanced Cell ID based on hyperbolic time-based methods. Other value added services include meteorological and weather Information, Broadcast and Warning information (Table 5.2). Such data sets provide reasonable information for Real-Time Kinematic (RTK) and Precise Point Positioning (PPT) applications providing a quicker time to fix first. Additional hardware mounting is supported for variable rate virtual reference station and NMEA applications. 116

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

5.3.4.1 LPP/e based System Capability

The capability set demonstrates a preliminary step in standardizing indoor-capable positioning methods. This endeavours to bring all the non-standard and standard technologies beneath the framework (GNSS, AGNSS and AGANSS) and utilize the potential of professional-grade GNSS to the consumer market. Continuous and non-continuous Carrier Phase Methods can provide the end- user higher accuracy with flexible mobility by employing multiple reference stations. Simultaneous mechanisms of session control can map altitude data with differential locking and code biasing in real-time thus providing higher accuracy. LPPe can support non-cellular positioning methods based on WLAN, Wireless Beacon Nodes, transmit/received power and Round Trip Time (RTT). Several indoor and undercover techniques have been proposed for indoor/undercover scenarios to provide location estimation in Unspecified or arbitrary geometrical area (Chapter 2). Other supported devices include Radio Frequency Identifier (RFID) and Bluetooth Nodes.

Table 5.2 outlines the Assistance Model of OSGRSv1 & 2 and compares their capability against OSGRSv3 Ð which is based on 3GPP LPP and OMA LPPe integration. A total of 25 assistance data types have been listed in the left most column(s). The assistance data available through OSGRSv2 are depicted in green highlights. The assistance data types available through OSGRSv3 have been depicted in yellow highlights. These represent a significant improvement over OSGRSv2. The underlying integration model constituting such capability set is presented in Figure 5.5.

117

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

Table 5.2 Assistance Model Overview MultiGNSS Assistance Model OSGRS 3GPP/OMA & OSGRSv3 OSGRSv1 P.No. Assistance Data Multi GNSS- LTE SUPL-R3 All Satellites in OSGRSv2 SUPL-R1/2 Statellites View RRLP LPP LPPe

1Navigation Model (Generic (G), Specific (S)) YYY NYY 2UTC, RTIYRTIYY NN 3Ionospheric & Atmospheric Model YNY YYY 4Acquisition Assistance NYNNNY 5Alamanc YYYY YY 6Reference Time YYNY YY 7DGNSSNYNY YY 8RTCM Support NNNY NN 9RINEX Support NNNY NN 10 NMEA Support NN Y N NN 11 Multiprotocol Support NN Y N NN 12 Authentication NN Y N YY 13 Authorization NN Y N YY 14 Mount Point Info NN Y N YY 15 Format RFC NN Y N NN 16 Carrier Info NY Y N YY 17 Compression and Bit Rate Info NN Y N NN 18 GPS TOW Assist (Sat.ID, Anti Spoof, Alerts, LBS) NN N NYN 19 Multi Network Support (GPS, GNSS, GSM, UMTS) GPS GPSNGNSS YY Cell Positioning Methods (OTDOA, O/TOA, E/OTD, GNSS)N N N NYY OTDOA, E/OTD Reference Cell Info NN N N YY Neighbour Cell Info NN N N YY Signal Measurement Info NN N N YY Measurement Quality NN N N YY 20 Capability List Provisioning NN Y N YY Error Lists NN N N YY Target Device Errors NN N N YY Location Server Errors NN Y N YY Enhanced Cell ID Positioning NN N N YY Network Time (GNSS, GPS, GSM, UMTS) NN N N YY GNSS Reference Location NN N N YY Klobucher Model NN N N YY 22 NE Quick Model NN N N YY Earth Orientation NN N N YY Time, Model List NN N N YY Standard Clock Model (NAV, CNAV, GLONASS, SBAS) N N N N Y Y CNAV-ECEF NN N N YY GLONASS-ECEF NN N N YY SBAS-ECEF NN N N YY Navigation Model (Keplerian Set (Normal, REduced)) NAV, 23 CNAV, GLONASS, SBAS NN N N YY GNSS Alamanc NN N YY GNSS UTC NN Y N YY GNSS Realtime Integrity NN N N YY GNSS Data Bit Assistance NN N N YY Auxiliary Info (Sat. ID, Health, Channel) NN N N YY SUPL Roaming Function NN N Y YY OTDOA over LTE NN N N YY Privacy Function NN N Y NY Security Function NN N Y NY Roaming Support Function NN N Y NY Charging/Billing NN N Y NY Service Management NN N Y NY 24 Triggering NN N N NY Position Calculation NN N N NY Altitude Performance NN N N NY High Accuracy Relative Positioning NN N N NY Indoor Performance NN N N NY Cable, DSL, LAN Interworking NN N N NY Wireless, Wifi/WLAN Support NN Y N NY Data Integrity and Confidentiality NN Y N NY Sensitivity (Coarse Time, Fine Time) NN Y N YY Dynamic Range NN Y N YY 25 Multipath NN N N YY Moving Scenario NN N N YY Periodic Update NN N N YY 118

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

5.4 Integrated Architecture (3GPP LPP, OMA LPPe and OSGRSv3)

This chapter proposes and tests the combination of 3GPP LPP, LPPe and OSGRS to enhance the OSGRS’s Hybrid Assistance Model portfolio. Such a system will provide the benefits of locally connected GNSS hardware, globally available GNSS casters, modern RRLP-based mobile phone positioning and third party assistance servers available through LPP extension protocol. This arrangement of several positioning and assistance systems could potentially be a fail-safe GNSS assistance system that can be categorised as a Multi-GNSS Assisted-GNSS capable of up to cm level accuracy. The A-GNSS system (MS-Based or MS-Assisted) can support text, RTCM, RINEX or ASCII formats (Table 5.2) and can operate without the limitations of a Virtual Private Network in a flexible client-server manner. Figure 5.5 shows the overall integrated architecture of the Multi- GNSS A-GNSS OSGRSv3 system.

OSGRS End

GNSS Source1 NMEA/VRA HSGPS Precision Algorithm Matching GNSS Source Assisted GNSS GNSS IP Selector Switch Source Selector Multi-GNSS Data Source2 Network (GSSS) (ASSS) (MGNSS) Repository

NTRIP Data Server Client Gateway Interface Interface

Wireless Positioning Infrastructure (Tx Access, Core, PSTN, SMS, Control NSS, GPRS) Interface Gateway

User Access LPP and LPPe Side RRLP NSS Core LTE BTS, Tx Core (Authen, Author, Aggregation Access Termination SMSC, SMLC, GMLC..)

WAP/IP GPRS Core RRLP PSTN (SGSN, GGSN..) Control

LPP LPPe Figure 5.5 OSGRSv3 System Architecture

119

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

The LPP works in conjunction with LPPe to provide the user specific assistance information through the generic mobile communication positioning system. On the lower left-hand side is the end user air interface system through the BTS. The end user can flexibly connect through the BTS system or OSGRS user interface to request specific assistance data. In general A-GNSS processing can take place on coupled machines to achieve optimum acquisition of generic or specific data and calculation performance of client requests. Client-server based architecture means the client could be a mobile or fixed device requesting assistance through any mobile or IP connected network.

5.5 Test Environment and Connectivity Scenarios

The test environment is an indoor lab with controlled signal absorption (from outdoor towers) characteristics. The test results presented here are for both obstructed and unobstructed indoor environments, representing maximum GNSS difficulty levels (Chapter 3). If a GNSS chipset is used indoors, differences in absorption are important to highlight in order to understand effects of attenuation when signals travel through different materials, as discussed in Chapter 4, Section 4.11. The test area is highlighted in Figure 5.6a. The highlighted four rows represent the GNSS difficulty levels of approximately 10.

Figure 5.6 Test Environment 120

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

Figure 5.7 shows the simplified connectivity diagram of the next generation mobile network components used to provide A-GNSS functionality. The test environment was established in a mobile network exchange utilizing the major RAN, Transmission and Core Positioning Network components. Once the appropriate parameters are selected, the OSGRS sends the request through the mobile network’s IP or HSPA gateway to LPP and LPPe servers connected to the SMLC. The mobile network then responds with the appropriate GNSS parameters or sends a GNSS error response. Tests were conducted using two positioning data transmission topologies in the test environment: Carrier Ethernet and SDH.

Figure 5.7 Conceptual Connectivity Diagram

a. Scenario 1: LPP and LPPe over Layer-2 Carrier Class Ethernet

This configuration was setup using an LTE RAN and Gigabit Ethernet Transmission channel where Huawei and Ericsson devices were used for the high capacity link establishment and interface connectivity. The interface card was named EX2 and the underlying link was a 10Gigabit Full Duplex Ethernet LAN. The link successfully provided LPP GNSS throughput on Layer-2 transmission protocol through the RAN.

The average rate of successful message delivery from the position acquisition unit to the target client over a synchronous digital channel or Ethernet transmission medium can be regarded as ‘GNSS throughput’. Figures 5.8a and 5.8b show the 24hr and 15min interval performances of the GNSS throughput. In a 15min interval no errors were experienced for duration of data transmission, demonstrated by the red line, whereas some intermittent errors are shown by the blue line during a 121

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

24hr interval (however with overall successful throughput). This can be due to many factors, such as inconsistent air interface (radio communications link between mobile station and base station), erroneous cross-connecting data links, faulty base station or problematic microwave or fibre mediums. To investigate the variation in performance, more specific testing needs to be carried out.

Figure 5.8 Performance a. 24hours

b.15mins

b. Scenario 2: LPP and LPPe over Layer-1 Synchronous Digital Hierarchy

The second scenario was established using LPP/e and Layer-1 Synchronous Digital Hierarchy technology where Ericsson devices were used to established the link connectivity on LTE and conventional SDH technology. The user end shows some inconsistent data rate input from the SMLC, which is demonstrated by Unavailable Seconds (UAS) errors (Figure 5.9).

122

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

Figure 5.9 Performance

This can be due to bandwidth mismatch on transmit or receive ends, or logical or physical link failure. Overall results indicated optical signal levels between the ranges of ~ ±3-5dBm with successful transmission, which is generally acceptable for carrier grade networks.

5.6 Configuration, Clocking and Operational Support Systems (OSS)

Clocking and timing synchronisation source was selected to provide GNSS assistance and achieve sustainable performance objectives of the SMLC throughput to cater for potential jitter and wander considerations. The following clock sources were available for network and device synchronisation:

a. G811 standard PTP 1588v2 (internal/external hybrid source) b. G813 SDH (internal source) c. G907 (internal source) d. G811 GNSS (internal/external hybrid source)

For this experiment, the network clock was first used and followed by later isolation of the test environment. The logical control channel provides separate GPS clocking (Clock Class ~ 6) with an accuracy of ~ 25ns for the SMLC information throughput to be transferred to end equipment. Alternatively other Building Integrated Timing Supply (BITS) clocks adhering to 1588/v2 protocol can be chosen, such as Atomic, Terrestrial Radio, Precision Time Protocol (PTP), Network Time Protocol (NTP), User Handset or Internal Oscillator.

Vendor specific OSS(s) are used for interfacing with mobile network devices. They provide a Command Line Interface (CLI) or Graphical User Interface to allow the network operator to access and push the desired preferences, connectivity and functions specific to the device, e.g. manage user end services, network element interface, remote network management, network monitoring, 123

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

capacity management, link management, fault management, fault remediation, and/or physical access and authorisation. Figure 5.10 shows the basic building blocks of such an OSS used to configure the system.

Note: To view interface screenshots of employed OSS systems, see Appendix D.

Figure 5.10 Building Blocks of an Operational Support System

5.7 Logical Structure and Operation

Java code has been written to acquire the LPP and LPPe positioning parameters through the server. System operation is demonstrated in Figure 5.11 and main classes of the OSGRSv3 demonstrating the system structure are as follows:

a. OSGRS: OSGRS main server package which provides data selection, validation, caching and interfaces. b. OSGRSClient: OSGRS main client which provides interface to other classes and displays the incoming streams according to request.

124

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

c. TestOSGRSClient: For testing of OSGRS client and server connectivity and validating system availability status. d. HTTPServer: To cater incoming HTTP requests to server. e. DataManagement: For management of data sources. f. Document Object Model: To cache the incoming streams from GNSS sources periodically. g. XMLProcessing: The XML parser which processes the request validation, request parsing and response generation. h. PositionCalculation: These classes calculate the satellite orientation and user position. i. DataType: They contain data models for each assistance data type. j. Util: Provide utility functions such as debug logger, request and/or response writer and testing facilities. k. NovatelOEM3/4: Connects to Novatel hardware sources and streams back through a serial connection. An interim IP converter is used to transfer the stream to computer. l. NTRIPpoller: Polls remote GNSS sources and caches data to be served in response to client requests. m. LPPpoller: Turn the LPP poller function on and prompts the user to establish the prerequisite connectivity for successful localization. n. LPPePoller: Turn the LPPe poller function on and prompts the user to establish the prerequisite connectivity for successful localization. o. SerialPoller: This class polls the serial port for inbound GNSS data stream through the Cellular, GNSS, NTRIP or any other source. p. DataTypeTester: This class tests the data types in client and/or server test mode.

125

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

Server Side

Alternative Source OMA LPPe

Position HTTP Server Novatel OEM3/4 NTRIP 3GPP LPP Calculation

Response Handler Request Handler OSGRS I/O Data Processing Data Cache

Request GNSS Error Data Source Validator Response Routine Manager Termination

Client Side

Polling Preferences XML OSGRS Test and Parser Util Writer

Input Response Parameter Writer OSGRS Preferences

OSGRS Client Request OSGRS Client GUI Writer Test GUI

GNSS Util DebugLogger DebugCache

Figure 5.11 Logical System Operation

Unlike ‘Cache and Response’ mechanism typical to some multi-GNSS systems (MGEX, 2012), the OSGRSv3 provides assistance data in a real-time ‘Request and Response’ manner. The system however does cache the collected GNSS data from various sources in ‘GNSSDataCache’ file. This is useful for conducting data analysis hence maintaining high integrity. System polling can be controlled by employing the log directories, listener port and refresh polling times functions in configuration files. The Xerces XML parser validates received information and detects possible errors. The error response is displayed by ‘GNSSErrorResponse’ to the target user. XML-parsing is employed to ‘request and response’ assistance data. The ‘GNSSResponse’ writer can send 126

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

calculated or raw data (whichever applicable and requested) to the client. The request handling and system information flow is illustrated in Figure 5.11 whereas system operation on a mobile device in isolated mode is shown in Appendix G.

5.8 Quality of Service, Data Collection and Benchmarking

LPP and LPPe based OSGRS positioning is intended to be delay tolerant, less uncertain and highly accurate (horizontal and/or vertical) thus providing higher Quality of Service (QoS). The response times are critically measured in fractions of seconds and confidence level information is provided under the Service Level Agreements (SLA). The QoS parameters are network controlled and are considered to assist the OSGRS server to determine the reasonable number of attempts required to calculate an accurate position and the application sequence of those methods to provide a quicker time fix. Response times are usually checked first before checking for horizontal and vertical accuracy requirements (see Figure 5.12).

Positioning Requested Method Positioning Accuracy Available Postioning Selection is compared with Methods according to Network Capability preferences

QoS Evaluation of adherence to Acquire radio, Parameter Quality of Service GNSS and other Input Requirements measurements

Position Positioning Results Previous Process Termination Calculation and for Final Computation and New Process intitiation QoS Evaluation

Figure 5.12 Quality of Service Management Process

As highlighted in Chapter 4, a constant time delay of k ~ 0.3-0.9s needs to be added per additional system to simulate processing time. Such delays can influence the TTFF performance of the OSGRS in several ways due to network transmission latency, initialization, computation and processing delay, clocking, jitter and wander considerations (highlighted above). An RTT constant

127

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

is added in the TTFF to estimate the final time fix value. Performance was gauged for the following QoS positioning metrics:

a) Satellite visibility b) Time to fix first c) Accuracy of localization d) Indoor Availability (Scenario(s) 1 and 2) e) Indoor Failure Rate (isolated) f) Indoor Failure Rate (non-isolated)

Indoor/undercover performance parameters were collected for several devices aforementioned in Chapter 4, section 4.11. Both versions of OSGRS were tested in BTS isolated and non-isolated environments to estimate the failure rates.

Table 5.3 Data Collection

Test Area Difficulty No. of Failure Rate TTFF Availability Accuracy(m) (Rows 1-4) Level(s) Satellites Overall Excl. Indoors Isolated SPOT Indoors 10 4 1256 35.789 149.4 64.211 49.41 Assisted MS-Assisted Indoors 10 7.2 11.9 97.976 12.2 2.024 1.044 GNSS MS-Based Indoors 10 7.5 12.6 98.985 10.1 1.015 0.035 HS-GNSS Indoors 10 5.2 49.5 82.367 25.4 17.633 16.653 OSGRSv2 Indoors 10 10 1.5 99.998 2.1 0.002 0.11 Scenario 1 OSGRSv3 Indoors 10 16 1.2 99.999 2.5 0.001 0.02 Scenario 2 OSGRSv3 Indoors 10 14 1.35 96.597 2.3 3.403 1.01 Combined OSGRSv3 Indoors 10 15 1.28 98.298 2.4 1.702 0.515

It is evident from Table 5.3, that in isolated environment, the availability for both OSGRSv2 and v3 drops down compared to the overall values. While the OSGRSv2 demonstrated the similar high performance in a different test environment to the one presented earlier in Chapter 4, the performance of OSGRSv3 was superior. OSGRSv2 tracked around 10 satellites whereas OSGRSv3 tracked around 14-16 in an environment where a medium sensitivity receiver only tracked 4 or less satellites and hence failed. OSGRSv3 demonstrated improved TTFF by 0.3s (Scenario 1) and 0.15s (Scenario 2), availability by 0.001% and accuracy by 0.4m over the OSGRSv2 (Figure(s) 5.13a, b, c, d, e). Erroneous link parameters appear to be the primary reason for reduced system availability of OSGRSv3 in Scenario 2.

128

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

(a) (b)

(e)

Figure(s) 5.13 Test Results, OSGRSv2 vs. OSGRSv3

129

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

The failure rate of the OSGRSv3 was 0.001 where that of the OSGRSv2 was 0.002. This however varies slightly for isolated test environments for both systems. The model of signal propagation from the respective base station(s) to the client can be controlled in a model carrier environment using the system settings of active (SMLC and/or BTS), semi-active (antenna and/or transmission guides) or passive network elements (hard switches). Such phenomenon can provide isolated or selective base station based and non-isolated or any base station within the coverage area based air interface. The failure rate of OSGRSv3 was 0.02 in isolated BTS environments whereas that of OSGRSv2 was 0.11 (Scenario 1). Both OSGRS systems demonstrated better accuracy and availability than the high sensitivity stand-alone GNSS, the MS-Based and MS-Assisted GNSS. In light of the above discussion, the OSGRSv3 provided several improvements over the OSGRSv2. It provides a diversified architecture by providing assistance information through additional A/GNSS systems. The performance improvement over the OSGRSv2 is predominantly due to a simplified and flat LTE (3GPP, 2009) based A/GNSS network architecture. The OSGRSv3 demonstrated improved availability, TTFF and satellite tracking capability for assisted GNSS and LBS applications. The complete software based architecture allows easy integration without significant cost. Where the vertical axis demonstrates the numerical values, Figure 5.14 demonstrates the improved performance of OSGRSv3 over its predecessor.

Figure 5.14 OSGRSv3 Performance Improvements over OSGRSv2

However the final TTFF needs to be calculated by incorporating the RTT constant values. LPP and LPPe are generally point-point communication protocols between the LCS target and client and may or may not work in parallel to reduce the response time and data latency thus affecting the 130

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

RTT. The RTT constant k is estimated to be 0.99s for OSGRSv2 running in configuration (a), as specified in Chapter 4, section 4.13. Such configuration was chosen for its higher flexibility and portability. The final TTFF equates to be 2.49s. Meanwhile, The RTT constant k for OSGRSv3 in the same LTE environment is estimated to be 1.98s. The final TTFF equates to be 3.18s in the first scenario and 3.33s in the second scenario. It is evident that the performance degradation occurred due to inconsistent link parameters (see Figure 5.15, the vertical axis demonstrates the numerical values).

Figure 5.15 OSGRSv3 Performance Degradation

5.9 Conclusion

In optimum configuration, the OSGRSv3 can provide higher availability, accuracy and sensitivity. However the improved performance of OSGRSv3 incorporates added complexity. The failure rates of the two systems in comparison have been marginal. For low accuracy applications, both systems demonstrate a performance difference of up to one decimal point. The focus of this proposal is also to test LPP and LPPe-based OSGRS to also understand the issues related to standardisation.

Logical complications do arise in multi-system integration, protocol translation, coding rates, throughput mismatch, physical factors, environmental factors, microwave interference, network latency and traffic priorities, thus effecting link performance in a complicated system of systems. HSPA bandwidth on user plane addresses transport latency and deals with complications in network architecture to some extent by providing data correction capability. OSGRS cannot only receive input from LPP and LPPe channels integrated into the mobile core network, but can also act as an

131

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

LPPe system directly or TCP/IP connected with conventional mobile, UMTS or LTE networks, provided that user or control plane bandwidth is available. The RRLP capable OSGRS can provide assistance information on wider throughput channels from the SMLC with GMLC being the first point of interconnection with the LCS. However indoor fading, ranging, arbitrary cell geometry or hexagon can effect penetration and coverage footprint of carriers.

The cost and resource efficient OSGRSv3 aims to combine a wide variety of positioning technologies in one system and can enhance LBS specific positioning performance flexibly. The next generation network scenario has been implemented and tested in the laboratory for successful throughput and preliminary performance checks on available bandwidth to support the OSGRS acquisition functions through LPP. However, as mentioned already, such capability isn’t widespread in mobile communication networks as it requires more bandwidth which carrier Ethernet or MPLS transport protocols can afford to provide in order to fully exploit the LPP data source for RRLP. LPPr1.x is proposed to provide higher performance (availability and accuracy) (Wirolla, 2011) subject to higher user plane bandwidth. However most commercial networks need to be designed, deployed and tested beforehand. A backup solution in the absence of in-building coverage repeaters is yet to be proposed. Future enhancement proposal could see Wireless Sensor Networks (WSN) being integrated into the OSGRS to step-up the system’s capability to provide more personalised or localised assistance data independent of conventional GNSS hardware and mains power.

5.10 Project Structure and Support

The OSGRSv3 can operate in MS-Based, MS-Assisted, VPN confined or extranet modes. Libraries such as ‘Data Source Managers (DSM)’ for ‘GNSS Request Parser’, ‘Response Writer’, ‘Request Manager’, ‘Response Manager’, ‘Data Cache’ and ‘Error Response Writer’ have been modified on the server side. On the client side, ‘Graphical User Interface(GUI)’ has remained unchanged however data sourcing methodologies, html parsing routines and data retrieval functions have been expanded. Newly added routines such as the ‘Ntrip Poller’ and ‘Stop Crash’ need to be controlled appropriately to source the new LPP and LPPe Data Source Connectors. System configuration files enhanced for OSGRSv2 (Chapter 4) have been re-used to provide new features of data logging, cache retrieval, and XML schema parsing. The ‘Ntrip Poller’ routine has been enhanced to provide the baseline for LPP and LPPe routines to acquire data and serve the user request. Cellular network

132

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

based GNSS resource provisioning, higher availability, cost efficient expansion; flexible testing, low TTFF and higher sensitivity are key advantages of the OSGRSv3.

5.10.1 Client Side

Where the function of each class can be inferred from its name, Client side project is structured as follows, with newly added functions highlighted in bold:

~ OSGRSClientUI ~ OSGRSClientRequest ~ GNSSRequestWriter ~ GNSSUtil ~ DebugLogger ~ LPPConnector ~ LPPDebugLogger ~ GNSSResponseWriter ~ DebugLogger ~ GNSSRequest ~ GNSSResponse ~TestOSGRSClient

5.10.2 Server Side

The LPP and LPPe poller libraries are added within the ‘DataSourceManager’ to provide the aforementioned functionality. Server side project structure is more complex, where the function of each class can be inferred from the class name, with new functions highlighted in bold:

~ OSGRS ~ HTTPServer ~ DataManagement ~ DataSource ~ DataSourceManager ~ NovatelSourceInterface ~ NTRIPSourceInterface 133

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

~ NTRIPPollerEngine ~ NTRIPPollerConfig ~ NTRIPPollerTest ~ SerialSourceInterface ~ SerialPollerEngine ~ SerialPollerConfig ~ SerialPollerTest ~LPPSourceInterface ~ LPPPollerEngine ~ LPPPollerConfig ~ LPPPollerTest ~ LPPeSource Interface ~ LPPePollerEngine ~ LPPePollerConfig ~ LPPePollerTest ~ GNSSDataCache ~ DataType ~ AlamancSatelliteParameters ~ DataType ~ GPSAlamanc ~ GPSDateTime ~ IonUTCModel ~ RawAlamanc ~ RawIonUTCModel ~ ReferenceTime ~ RTI ~ SatelliteEphemeris ~SatelliteInView ~ DataTypeTesters ~ AlamancSatelliteParameterTester ~ GPSAlmanacTester ~ IonUTCModelTester ~ RawAlamanacTester ~ RawIonUTCModelTester 134

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

~ ReferenceTimeTester ~ RTITester ~ SIVTester ~ GNSSDataCache ~ GNSSResponseWriter ~ GNSSUtil ~ ReferenceTimeTester ~ BitMask ~ DebugLogger ~ GNSSRequestWriter ~ AzimuthElevation ~ AlamancSatelliteParameters ~ GPSDataTime ~ ConfigManager ~ NovatelOEM3ConfigFile ~ NovatelOEM4ConfigFile ~ NTRIPConfigFile ~ SerialConfigFile ~ SystemConfig ~ PositionCalculation ~ AzimuthElevation ~ SatellitePosition ~ SIVGenerator ~ WGS84ECEFXYZ ~ NovatelDataSourceConnector ~ NovatelOEM4Source ~ NovatelDataSourceConnector ~ NovatelLog ~ NovatelLogCache ~ NovatelLogProcessing ~ NovatelOEM4SourceConfigFile ~ NovatelOEM4SourceDataFile ~ NovatelOEM3Source ~ NovatelDataSourceConnector 135

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

~ NovatelLog ~ NovatelLogCache ~ NovatelLogProcessing ~ NovatelOEM3SourceConfigFile ~ NovatelOEM3SourceDataFile ~ DocumentObjectModel ~ RequestObjectModel ~ DocumentObjectModel ~ ResponseObjectModel ~XMLProcessing ~GNSSErrorResponseWriter ~GNSSRequestParser ~GNSSResponseWriter ~RequestManager ~RequestValidator ~ResponseManager

5.11 System Development and Configuration

The School of Surveying & Geospatial Engineering at UNSW operates the OSGRS as part of a Continuously Operating Reference Station (CORS) for research in A-GNSS and Multi-GNSS. The systems are licensed under the free General Public Licence (GNU, 2007). Modification and enhancements to hardware and Java software components of the system can be made with minimal legal requirements. Installation and compilation guidelines of the OSGRS with new components have been specified in Chapter 4, section 4.15 and must be followed appropriately to execute and use the software to full potential. Adherence to the Operating system, Java compiler and Virtual machine requirements is crucial here. Technical support is available from prime contacts involved in the project, its upgrade and testing. Depending on the specific purpose, XML GRIP schemas known as ‘CommonDataTypes’, ‘GNSSErrorResponse’, ‘GNSSRequest’ and ‘GNSSResponse’ may need modification. System configuration files need to be modified to adjust the baud rate and other settings depending on the type of GNSS system used. Link and system configuration of core positioning, radio access and transmission network elements need to be established. Radio base

136

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

station propagation parameters need to be controlled depending on the level of system access required.

5.12 Fourth iteration of the OSGRS

Figure 5.16 illustrates the proposed OSGRSv4 architecture based on evolved mobile phone technology of the future. The soft-phone client will authenticate and connect to the Customer Access Network rather the handset. The communication request from the client will use the carrier network path to reach the core termination point and request assistance data. The LBS core can use either local LPP/e protocol(s), global carrier network localisation functions, or the NTRIP. LPPe may be augmented in the mobile platform end-server to render service equivalent location-based processing and acquisition assistance. This may be achieved through introduction of external open source GNSS IP servers or a new hybrid network integrated with the SMLC and GMLC.

Softphone Network NSS Core LBS Protocol Core over RRLP Aggregation (SMSC, SMLC, GMLC)

IP Gateway NTRIP RRLP GNSS Source 1 Caster GPRS Core Control (SGSN, GGSN..)

LPP LPPe

GNSS Source 2

Figure 5.16 OSGRSv4 Architecture

Through the base station or e-NodeB, the softphone client will connect directly to the GMLC without the intervention of intermediary transmission or network controllers. The GMLC will initiate the positioning request with SMLC and SUPL and provide measurements to the client. Due to a much simplified software and hardware architecture, the intermediary node associated latency will be reduced thus minimizing the response time. Therefore the requirement to add the RTT constant will be reduced hence reducing the time to fix first performance degradation for difficult environments. Potentially, the performance degradation associated to inconsistent link parameters can also be controlled thereby mitigating the adverse effects on availability and sensitivity.

137

Chapter 5 LPP and LPPe based Mobile Assisted Multi-GNSS Reference Server, OSGRSv3

5.13 Chapter Summary

The OSGRSv2 server has been augmented with LPP and LPPe to develop the third generation OSGRSv3. Interconnection of networks is provided through IP data control gateways for user- specified information exchange. Assistance Model has been expanded with the development of mobile communications interworking criteria. Network implementation in a controlled mobile network laboratory has been configured. Experiments demonstrate that the system lowered the TTFF and improved the satellite availability and positioning accuracy over OSGRSv1 and 2. Options of selectively choosing which GNSS to use is managed through a source selector switch. TTFF may increase due to network latency and a simplified OSGRSv4 system has been proposed.

138

Chapter 6 WSN Based and WSN Assisted Positioning

Chapter 6 WSN Assisted and WSN Based Positioning Techniques

6.1 Introduction

The performance and availability of stand-alone GPS or GNSS is degraded indoors, principally due to lack of sky visibility, weak signals and multipath. However Location Based Emergency Systems are time and availability-critical applications. This chapter presents an alternative strategy to augment GNSS with Wireless Sensor Nodes (WSN). Fixed sensor nodes are deployed in the test area and a rover sensor node is connected to a mobile device and GPS/GNSS receiver. Based on a received signal strength algorithm, signature indices are generated and proximity calculations are made by the fixed nodes to locate the rover. The location information is transferred to the GPS/GNSS device in the form of assistance messages. Experiments were conducted at the University of New South Wales to simulate a potential reduction in the GPS navigation search space. This improves time-to-first-fix (TTFF), availability and accuracy. This system also ensures redundancy in the event of partial system or node failure. Test results demonstrate a better relative performance than technologies such as stand-alone GPS, A-GNSS or SPOT Satellite Messenger in indoor environments.

This chapter is organised in two parts. In first part, the WSN is used to assist GNSS indoor positioning. Based on received signal strength indicator (RSSI), link quality indicators and individual fixed node location “slices” contained in cumulative signature indices database on each node; information on pre-processed frequency offset, range and coordinate assistance for location based services is provided by periodic transmission to surrounding nodes. Since each node stores a database of its own and neighbouring nodes’ location “slices”, an output stream containing location coordinates of a mobile node of interest is provided through a dynamically chosen point of interconnect to the rover node. The rover node is a WSN interfaced smartphone displaying the location information and providing assistance parameters to GNSS chipsets. Disturbing errors, their respective effects and resource constraint considerations are discussed. To aid error mitigation, a system comprising of a set of seven fixed stand-alone WSN nodes is tested against traditional GNSS, A-GNSS and WSN-enabled A-GNSS techniques.

139

Chapter 6 WSN Based and WSN Assisted Positioning

The second part of the chapter introduces a stand-alone configuration for improving accuracy, response sensitivity and reliability against partial node malfunction. Empirical non/overlapping measurements in diverse geographical geometry with different distance calculation schemes were carried out. System architecture, code processing flowchart and RSSI-based localisation methods and calculations are presented.

Technical details of the IEEE 802.15.4d protocol and the physical and medium access control layers with respect to the sensor nodes are discussed. Rover tracking experiments were conducted in an enclosed building corridor simulating a difficult indoor GNSS environment. Signal attenuation and absorption parameters subject to different materials were investigated.

6.2 Background

The Global Navigation Satellite System (GNSS) is the most pervasive, widely-used system for positioning, navigation and timing (PNT) applications. However performance is typically degraded indoors, in urban areas and under tree cover, and hence schemes have been developed to aid or assist GNSS in difficult signal environments. A number of integration techniques have been proposed for the implementation of Assisted-GNSS (A-GNSS) schemes. Such systems include assistance from structured networks like Internet Protocol (IP) or Universal Mobile Telecommunications System Terrestrial Radio Access Network (UTRAN), and Wireless Local Area Network (WLAN) or Wireless Fidelity (Wi-Fi).

Stand-alone GNSS (S-GNSS) can be unusable for some sensor network operational environments. “Hot-start” can provide a quicker position fix (Mautz et al., 2007). Some systems can be heavily reliant on mains power (Ganeriwal, 2003) and can be time inefficient due to necessary comprehensive code and frequency bin searches (Garin, 2010). Regardless of the mobile phone technology (2G/3G/4G) cellular network coverage inside buildings does experience difficulties, with occasional poor reception due to low signal levels. This reliance on infrastructure-based networks and the limitations of GNSS in indoor environments has motivated the investigation of an alternative scheme based on Wireless Sensor Networks (WSN).

Some literature relevant to the indoor positioning topic has been presented in chapter 2, section 2.4. Recent advancements in the field of WSN promise better reliability, granularity and resolution (Small et al., 2000; Niculescu & Nath, 2001; Savarese et al., 2002; Savvides et al., 2003; Smith et 140

Chapter 6 WSN Based and WSN Assisted Positioning

al., 2004). Probabilistic approaches have been proposed for indoor positioning (Roos et al., 2002). Proposed techniques based on adhoc systems can deliver assistance information at low computation cost (Youssef et al., 2003) and similar radio systems hardware can be time and cost effective (Krumm et al., 2002). Mobile Radio Base Stations might be incapable due to lack of coverage or destruction of in-building coverage repeaters.

6.3 Wireless Sensor Networks-Enabled Assisted-GNSS

This chapter focuses on improving the availability of S-GNSS and reducing TTFF by providing hot-start; coordinate and pre-processing assistance. WSN could potentially operate independent of power requirements and partial destruction of sensor modules. Furthermore, WSN can provide initial mobile receiver coordinates or partial processing assistance. This chapter also describes a stand-alone WSN approach for efficient, low latency and error-free indoor localisation, as alternative to the proposed WSN-enabled A-GNSS. The system has potential to provide a quick position fix with minimal inter-system transfer processing, data transmission and translation requirements.

An adhoc network is inherently infrastructure-less, autonomous and self-organised in sharing end- to-end information through multiple hops and intermediary nodes. Position is calculated using measurements between pairs of neighbouring nodes based on AOA, TOA, TDOA or SS techniques. Relative position can be obtained easily in infrastructure-less environments, however for absolute positioning at least one node needs to be connected to fixed infrastructure. Other problems include non-line-of-sight, propagation and absorption errors.

6.3.1 System architecture and operation

The system has two main components:

a. Crossbow (2010) manufactured MICAz fixed nodes (model MPR2400CA) (Figure 6.1a). b. The mobile node connected to a high sensitivity GPS chipset.

The fixed sensor nodes are connected to the in-building fire alarm system and the mobile node is connected to a master user laptop in a backpack providing radio guidance. The arrangement

141

Chapter 6 WSN Based and WSN Assisted Positioning

simulates a scenario of fire fighters entering a building with destroyed infrastructure, requiring location assistance for emergency response applications from the master user.

Figure 6.1a Wireless sensor mote or node, b. Interface device and programmer

6.3.2 Node and protocol architecture

Each MICAz sensor node is a high data rate radio sensor based on the Atmel ATmega128L chipset. Due to their portability, low power requirements and reasonable processing capability, they are suitable for rapid deployment applications. The system exploits the IEEE 802.15.4 wireless standard, which is a subset of IEEE 802.15. It uses the 2.4GHz ISM radio frequency band supporting 16 channels, can run low-to-medium complexity computing algorithms, and is suitable for relatively short range (10m) applications (which results in good battery life for longer term applications, IEEE 802.15.4d, 2009). However range can be extended with appropriate antenna design. The chipset comprises of a 128kB ROM for the BIOS functions/startup and 4kB RAM for processing functions, and supports quality of service parameters such as the link quality indication (LQI) (Crossbow, 2007).

6.3.3 GNSS hardware and software architecture

The mobile node is connected to a high sensitivity GPS chipset such as the SiRFStar-III (2009). For sensor node interface and programming the Crossbow MIB510 board is used (Figure 6.1b). Fixed sensor nodes can be deployed in free space, having their unique neighbourhood signatures and proximity coordinates stored. They are connected to the fire alarm or detection system and run in standby mode. The system architecture is illustrated in Figure 6.2. Mobile sensor node is connected to the interface programmer, which connects to a laptop through a USB interface. The same laptop has the MiO (2009) SiRFstar GNSS chipset device connected to it. In the event of a request call 142

Chapter 6 WSN Based and WSN Assisted Positioning

from the mobile node, surrounding nodes provide assistance information. Mechanism of operation is illustrated in Figure 6.2.

The software has been written in open source TinyOS (2010), which is recommended for less resource hungry MicaZ sensor nodes supporting adhoc mesh networking capability and suitable for low processing power requirements. Xubunto Linux has been used to develop code due to its built- in support for TinyOS with a code size of a few hundred lines. Although each node operates on two AA batteries which can potentially last a few weeks depending on usage, application and processing requirements, power usage can still be optimised with careful duty cycling.

Figure 6.2 System architecture and Operation

6.3.4 Network and transmission architecture

The WSN system is based on an OSI model and can work in star, tree or peer-to-peer topology with Personal Area Network controllers. The user computer acts as the hardware and software interface between wireless nodes and GPS. Transmission takes place in individual frames or combined frames sometimes referred to as super-frames consisting of 16 frames. For efficient transmission, contention and collision control Carrier Sense Multiple Access (CSMA-CA) technology is used with the appropriate handshake protocol. Transmission is provided by the physical layer (PHY) and the Medium Access Control (MAC) layer. MAC controls the information flow to upper logical layers through data, beacon, acknowledgement and MAC frames. The system supports several

143

Chapter 6 WSN Based and WSN Assisted Positioning

modulation techniques; more specifically 2.4GHz band models exploit Quadrature Phase Shift Keying (QPSK) (IEEE 802.15.4d, 2009).

Note: Crossbow OEM MICAz Wireless Measuring System Datasheet can be found in Appendix E.

6.4 Integration and Operation

Wireless sensor nodes require no external power or network support to function, being self-location aware, decision autonomous; adhoc deployed and have on-board battery power. Sensor nodes can be pre-deployed and stay in “sleep” mode charging on-board batteries. In the event of a fire alarm, each fixed node would self-activate. The nodes would know their own and their neighbour’s location. Each node will keep a “slice” of the location database eliminating single point of failure. In the case of partial node failure, other nodes can still provide location information to the mobile node. The system operation flowchart is shown in Figure 6.3. For efficient time positioning and time syncing, each node clock should be approximately synchronised to GPS time. Several time sync protocols have been proposed, and can be achieved through individual node programming, flood or time propagation. However consideration needs to be given to send, transmit/receive and access time in the WSN medium access protocol, at the MAC layer for effectively synced communication (Elson, 2003; Garin, 2010; Maroti, 2004).

Figure 6.3 System information flow

144

Chapter 6 WSN Based and WSN Assisted Positioning

6.5 Location Measurements and Computation

There is a two-tier approach to location detection based on received signal strength (RSS): a) Training: Reference signature data is collected during a “dry run” by the mobile node, after deployment of the fixed nodes (Figure 6.4a). Empirical data for the following parameters is calculated and recorded in the database:

i. Location Identified (locID) ii. Location Coordinates (locCoord) iii. Source Address (srcAddr) iv. Sequence Number (sqnNbr) v. Frequency (freq) vi. Transmit Power (txPower) vii. RSSI (rssi_dBm) viii. Link Quality Indicator (lqi)

Figure 6.4a Database Creation during Training Phase b) Localization: In location detection, the actual location coordinates are calculated where the mobile node can obtain the strongest signal.

The mobile node can obtain the strongest signal and passes the information to the fixed nodes (Figure 6.4b). This is a non-centralised approach without backend server support, where fixed nodes process and calculate the position. The basic concept is similar to radar, which needs a backend server support, and Cricket which needs a denser deployment of fixed nodes (Bahl, 2000).

145

Chapter 6 WSN Based and WSN Assisted Positioning

This makes them a poor choice for disaster response operations. The mobile node initially “listens” to broadcast beacon messages from the fixed nodes, thus acquiring signal signatures. Then it broadcasts on request its own information from the fixed nodes. For instance, assume a few fixed nodes in a three dimensional fixed space. They all keep a slice table of reference signatures of nodes within communications range, assuming communications take place periodically as pre-configured. The roaming mobile node can “listen” to the fixed nodes, thereby constructing its unique mean signature superset. This superset contains RSS signature slices, or subsets of all beacon nodes in the vicinity at that point in time.

Figure 6.4b Signature training and database creation based on signature slices

The fixed nodes may then compute the signature distance between the received signature from mobile nodes and the reference signature from their own database. Once the difference between signature distance s and reference signature r is calculated, the Manhattan distance metric can be employed for computation of the absolute difference between sent and RSS:

M (r,s) = ∑ t€T |mean RSS(t)r Ð mean RSS(t)s| eq. 6.1 where t is the set of signature entries. To determine the x, y coordinate orientation (assuming z is approximately 0) in a 2D triangular space, localization results can sometimes be arbitrary (Figure 6.5).

Figure 6.5 Coordinate orientation in triangular space 146

Chapter 6 WSN Based and WSN Assisted Positioning

If the assumed location of the mobile node is centroid C, then the location of the centroid is:

C = [(x1 + x2 + x3)/3, (y1 + y2 + y3)/3] eq. 6.2

In circular space, the orientation of x and y coordinates, where r is the radius and c is the centroid, can be shown as marked by the arrow in Figure 6.6.

Figure 6.6 Coordinate orientation in circular space

Once position proximity is known, the refined location can be calculated by biasing the value to the nearest signature in the database. WSN-based systems can achieve a 50th and 80th percentile accuracy of 0.9m and 1.6m, respectively, and can be resilient with 60% system failure and signature perturbations of up to 50%, with negligible increase in error (Lorincz et al., 2005). The calculated position coordinates are then transferred to the GPS chipset to reduce the search space and provide assistance in location calculation.

There are a few methods to calculate the proximity measurements of such nodes. For RSS, the relationship between transmit/receive power and relative node distance, considering is received power, d is reference distance and (2 for free space, 4 for indoor) is path loss (Krish, 2005):

eq.6.3

147

Chapter 6 WSN Based and WSN Assisted Positioning

The Intel Research Group proposes a similar method, where sensors randomly search surrounding nodes, minimise signature errors (sum of square of all relative distances) and compute the lowest mean error (LaMarca, 2005). Other techniques such as circular coverage intersection around each node provides position proximity in overlapped median areas despite the occurrence of inaccuracies associated to geographical irregularity.

Time Difference of Arrival (TDOA) which is based on the difference measurement between two RF signals with the same transmit but different receive times is applied to contain the impact of such irregularities. Similar to the Time of Arrival (TOA) technique, the distance between nodes is directly proportional to the time taken by the signal from transmit to receive (Garin, 2010) where the velocity is given by:

eq.6.4

where θ is the air temperature in degrees Celsius. To align the arbitrary and inconsistent errors in estimated location coordinate values, standard Deviation (SD) can be calculated using (RMS) method as follows:

eq. 6.5

Where is the series of variable distribution in STD σ:

eq. 6.6

For each test point, the error values (m) are positively proportional to the corresponding difficulty levels. Obviously to correct the horizontal and vertical errors in database or positioning, separate

148

Chapter 6 WSN Based and WSN Assisted Positioning

values will need to be calculated and rounded off to bias towards the nearest signatures obtained during training phase. This will result the more accurate positioning value.

6.6 Test Bed and Data Collection

Figure 6.7a shows the test bed of 10 nodes deployed on Level 4 of the Electrical Engineering Building of the University of New South Wales, Sydney. Testing was carried out for four positions, which represented maximum difficulty for a GPS chipset operating indoors (Sarwar et al., 2009).

The points marked in green are the fixed node positions. Complete floor layout is presented as follows to demonstrate the maximum difficulty in such enclosed environment.

Figure 6.7a Test bed at Electrical Engineering building L4, UNSW

149

Chapter 6 WSN Based and WSN Assisted Positioning

Figure 6.7b shows the location marker in red; code processing in the background shows the events of location calculation displayed in request-response manner. Each line represents a separate response received from the remote beacon node into mobile node and hence copied onto PC screen through the USB serial forwarder.

Figure 6.7b Localization response: location of mobile node is highlighted by Red marker

The zoomed-in-view (Figure 6.8) shows the coordinates obtained after calculation by the fixed nodes. The arrow marks the location of the mobile node indicated by the red marker. Differential correction data can be calculated based on GPS satellite availability for quick startup and accurate positioning indoors. It is assumed that the delta computation will take a few milliseconds and a constant value can be integrated in multiple system transfer and the resultant value. As mentioned in chapter 4, section 4.10, for such systems a constant time delay is added, of the order of k ~ 0- 300ms (Marotti, 2004) for processing time, transfer, latency, and other effects. This gives actual round trip time of complete request-response processing, used to calculate the final TTFF.

150

Chapter 6 WSN Based and WSN Assisted Positioning

Figure 6.8 Assistance request by mobile node and localization response provided by fixed nodes (Zoomed in View)

6.6.1 Experimentation

Performance benchmarking was done using the following devices:

a) Secure User Plane Location (SUPL release 1 & 2) enabled A-GNSS (Figure 6.9a) i. MS-based mode ii. MS-assisted mode b) High sensitivity GPS device (MiO A701, SiRFStar-III) c) SPOT Satellite Messenger (Figure 6.9b) d) Medium sensitivity Garmin GPS

SUPL allows the client to connect to the A-GPS location server over TCP/IP (Sarwar et al., 2009). Once a TCP/IP connection is established, the SUPL-enabled terminal can determine its location (Li et al., 2007) and transmit to client. GNSS Signal absorption characteristics when subject to different materials, have been mentioned in chapter 4, section 4.11.

151

Chapter 6 WSN Based and WSN Assisted Positioning

Figure 6.9a Mio A-GPS system b. Spot Messenger System

Table 6.1 shows the indoor test points with their respective difficulty levels, lat-long in space, and test results. All test points are indoors with GPS difficulty levels of 10. WSN-enabled A-GNSS gave lower TTFFs. Despite minor variations in sky visibility, observed GPS difficulty level stays consistent across all positions. The positions include locations such as corridors, corner walls and hallways. Where GNSS observed four or less satellites, the WSN-assisted system provided RSS observations to support positioning. The highlighted locations (Table 6.1) indicate the inaccessible areas for testing due to building works.

Table 6.1 Data collection on UNSW test bed

No. Point DL Type Map Location SPOT Av. E-Trex Set AssistedSet BasedStand-Alone SPOT SPOT TTFF WSN (SA) WSN+AGNSS Ref Latitude Longitude Pass/Fail Min Max Min Max Min Max Min Max Attempts max 600 secs TTFF (secs) TTFF (secs) 23 INDR1 10 I NM 33.917772 151.23145 Fail 0 0 4 10 4 10 3 3 3 600 1.4 1.9 24 INDR2 10 I NM 33.917746 151.23172 Fail 0 0 4 8 4 10 4 4 3 600 1.7 2.2 25 INDR3 10 I NM 33.917825 151.23184 Fail 0 0 na na na 3 600 1.3 1.8 26 INDR4 10 I NM 33.917853 151.23169 Fail 0 0 4 9 4 7 3 4 3 600 1.9 2.4

Table 6.2 summarises the performance parameters; TTFF, satellite visibility, availability and failure rates, for the competing technologies. WSN-enabled A-GPS has the lowest TTFF i.e. 1.9s of all devices that were tested. If a time delay constant k ~ 0-300ms is added (to account for the total processing and computation time), the resultant TTFF for sensor based system equates to 2.2s. The system also demonstrated the highest availability of around 99.9%in the test environment. High sensitivity GNSS showed a higher TTFF i.e. 40.8s than MS-based or MS-assisted GNSS. The high sensitivity system tracked an average of 5.8 satellites with an overall availability of 86.7%. On the other hand, the MS assisted system showed a TTFF of around 11.6s with a difference of 0.2s from the MS based system. The MS assisted system tracked an average of 6.8 satellites with 98.5% availability where the MS based system tracked an average of 7.3 satellites with an average availability of 99.8%. SPOT Satellite Messenger gave the highest TTFFs of 544s, with the lowest availability of around 40%. The availability of SPOT system improved by around 10% with increased sky visibility and hence reducing the GNSS difficulty level. 152

Chapter 6 WSN Based and WSN Assisted Positioning

Table 6.2 Summary of test results

Figure(s) 6.10 (a, b, c, d and e) are plots of five performance comparison metrics: failure rate, availability, TTFF, satellite visibility and accuracy respectively, comparing A-GNSS, SPOT, High sensitivity GPS, and WSN-enabled A-GNSS. Evidently, the latter system has the lowest failure rate, followed by the MS-based and HS-GNSS systems.

50 MS-Assisted 40 SPOT 30 MS-Based HS-GPS 20 WSNAGNSS 10

0 Failure Rate (%) Figure 6.10a. Overall failure rate (%) b.Availability (%) c. TTFF (s)

The MS- based system differs from WSN based system’s availability by about 0.1%. The accuracy of WSN enabled system is around 3.1m which is the highest of all. Both the MS assisted and MS based systems showed accuracy ranges of 9.9m each while the high sensitivity GNSS showed around 10.2m. SPOT satellite messenger showed the lowest accuracy of around 25m.

d. Accuracy (m) e.Satellite Tracking

153

Chapter 6 WSN Based and WSN Assisted Positioning

6.7 Problem Identification and Mitigation

WSN can provide initial mobile receiver coordinates or partial processing assistance; however a number of problems may introduce errors in the GNSS parameter calculation. TTFF complications associated with the constant k have already been mentioned in chapter 5. This section proposes a stand-alone WSN approach for efficient, low latency and error-free indoor localisation, as alternative to the previously proposed WSN-enabled A-GNSS technique. The system has potential to provide a quicker position fix with minimal inter-system transfer processing, data transmission and translation requirements, and with a simplified architecture.

6.8 Error Types and Effects on Localisation Performance

The following are the primary types of error sources influencing the optimisation and efficiency of the network (Slijepcevic et al., 2002; Roshanzadeh et al., 2012).

a. Measurement: Subject to application of some digital signal processing based techniques that can alleviate this problem, measurement inconsistencies can arise due to physical hardware or logical sensing capability limitations, unstable phenomenon or environmental noise. b. Finite precision: This error type is generally incurred due to the system being inherently low resource; and these errors can potentially cause the WSN to provide incorrect location parameters to GNSS. c. Objective function-specific: The optimisation process may not effectively exploit the objective-function thus leading to erroneous calculations. d. Intractable optimisation tasks: Some inherently intractable of optimisation routines by nature can cause the computation to be cumbersome, hence compromising computational capability versus duty cycle issues (e.g. energy, communication bandwidth, storage and processing power). e. Localised algorithms: Distributed computation systems and capability can limit the efficiency of globalised geographic information and integrity of signatures thus compromising the proximity information.

154

Chapter 6 WSN Based and WSN Assisted Positioning

f. Energy efficiency: The energy consumption of internal WSN components isn’t as high compared to radio transmission by other systems. Since the devices are battery powered, a number of fixed nodes or GNSS interfacing mobile node can fail arbitrarily. g. Fault-tolerance: Noise and other factors can impede performance and induce errors. Fault remediation routines should therefore be computationally efficient with high integrity suited to their individual construction characteristics and deployment geographies. h. Time synchronisation: Being one of the most crucial factors in a distributed infrastructure, time syncing is important and is difficult to source from conventional networks. Precise time is also important to make location-based measurements, which requires accuracy, lifetime, scope, availability, and energy resilience. Local time synchronisation requires only a few peer nodes to collaborate; however global syncing needs GNSS time.

6.9 Error Mitigation: Stand-Alone Sensor Network-based Localisation

The system is based on seven Crossbow MICAz sensor nodes and one mobile node connected to the user computer and display. The test bed had minimal mobile coverage and low GNSS satellite signal penetration, thus making it a difficult scenario for a variety of systems. A wireless sensor system is shown in Figure 6.1a.

Although every sensor node system can be different in terms of processing capability, power usage, radio transmission and sensing capability, Figure 6.11 shows the basic building blocks of the WSN architecture without a positioning chipset connected.

155

Chapter 6 WSN Based and WSN Assisted Positioning

Sensor Node

Internal Cache

Possible External Inteface Radio Interface (Tx/Rx) CPU e.g. GPS

Sensors

Power Source

Figure 6.11 WSN hardware architecture block diagram

6.9.1 System architecture and operation

The fixed node system deployment plan differs from the former system due to the density of nodes. The node, protocol, hardware, software, network and transmission architecture are similar to the specifications in section 6.2. The mobile node can be connected to any mobile computer, which for this experiment was a laptop, through the Crossbow MIB510 interface board (Figure 6.1b). Fixed sensor nodes were deployed in a free space corridor, with their unique neighbourhood signatures and proximity coordinates stored following a training phase, and placed in standby mode. A mobile sensor node was connected to the interface programmer, which connects via the remote machine USB interface. As the mobile node makes a request to the fixed nodes for position information, they wake from standby mode, calculate the proximity fix and promptly respond to the mobile node. The 156

Chapter 6 WSN Based and WSN Assisted Positioning

software has been written in open source TinyOS (2010), as recommended for resource constrained MicaZ sensor nodes supporting adhoc mesh networking capability and low power applications. As mentioned earlier, Xubunto Linux has been used for programming.

6.10 Test Bed and Experimentation

Figure 6.12 shows the test bed on L4 of the EE Building at the University of New South Wales, indicating a difficult scenario (difficulty level ~ 10) (Sarwar et al., 2009). There are seven deployed fixed sensor nodes (green highlight) continuously broadcasting (when awake) their positions, until a query is sent by the mobile node (red highlight) requiring assistance (within the yellow highlight space).

Figure 6.12 Test bed

The yellow highlight shows the rover node scope of operation for this experiment. Figure 6.7a demonstrated the same location with 10 sensor nodes. When the mobile node sends the location query to fixed nodes, they calculate the position and send the response, which is received by user interface and is plotted on the map showing the coordinates with date- and time-stamp. The black arrow indicates the true location of the mobile node. Differential correction data is calculated based on reference and received signatures. The GNSS sensitivity levels also consider pre-established attenuation levels across different materials. Data collection summary is presented in Table 6.3.

157

Chapter 6 WSN Based and WSN Assisted Positioning

Table 6.3 Data Collection and Summary of Results

6.11 System Performance

Benchmarking devices have been listed in section 6.5.1. Figure(s) 6.13 (a, b, c, d and e) plot the satellite visibility, failure rate, availability, TTFF and accuracy, respectively, for all devices used in the comparison tests. The WSN-enabled A-GNSS has not only a lower failure rate of around 0.12% than MS-based and HS-GNSS, it also has a lower TTFF of around 1.9s without the inclusion of processing constant. The WSN enabled GNSS and stand-alone sensor system showed similar accuracies of around 3.1m with an availability of about 99.98%. The high sensitivity GNSS demonstrated an accuracy of around 10.2m, close to the MS-based and MS-assisted system which showed the accuracies of around 9.9m. The SPOT satellite messenger on the other hand showed an accuracy of around 25m.

Figure 6.13a.Satellite visibility b. Failure rate (excluding indoors) (%) c. Availability (%)

The stand-alone system has a simplified architecture as compared to the WSN enabled technique. The stand-alone sensor system demonstrated TTFF improvement over the WSN enabled system by 158

Chapter 6 WSN Based and WSN Assisted Positioning

about 0.3s. Figure 6.14d shows that the stand-alone WSN-based system demonstrated the lowest TTFF of approximately 1.6s, while the WSN-enabled A-GNSS had a slightly higher TTFF of 1.9 seconds, with similar accuracy and availability. This means that the stand-alone system demonstrates the same performance benefits as the assisted system with some TTFF improvement; however the system still needs to be initialised with GNSS clock time.

d. TTFF (s) e. Accuracy (m)

Such improvement predominantly comes due to the elimination of initialisation and processing time factors in the full-cycle of acquisition computation and simplified architecture. High sensitivity GNSS had a higher TTFF than MS-based or A-GNSS, which had a difference of around 0.2s. Similar to the tests (presented in earlier chapters), the SPOT Satellite Messenger gave the highest TTFF of around 544s with lowest availability of around 40%. Experiments have suggested a performance improvement of around 10% for SPOT if open sky visibility is increased. The accuracy of stand-alone system is comparatively degraded in partial beacon node failure by about 1m. Figure 6.13 demonstrates the working environments where some beacon nodes are functionally absent or have failed to provide a fix. The stand-alone system demonstrated a decrease in availability by about 30% in case 2-3 beacon nodes failed. The performance degradation happens due to no-tethered localization device and the sole reliance of this system on stand-alone sensor nodes.

Performance of the three WSN based localization systems is demonstrated in Figure 6.14. Comparison graphs of WSN enabled AGNSS, stand-alone WSN and partially failed WSN system(s) showed that the stand-alone system is highly reliable against partial node-set malfunction. Despite the decrease in availability, the accuracy is not affected by more than 1m. Here the vertical axis shows the numerical performance values.

159

Chapter 6 WSN Based and WSN Assisted Positioning

Figure 6.14.Performance comparison of three different configurations of WSN based localization (TTFF (s), Availability (%), Accuracy (m), (Failure Rate (%) (Overall, Excl. Indoors))

Conclusively, the TTFF performance improvement shown by stand-alone WSN based system can collectively be regarded as reasonable localisation performance at efficient cost for non-satellite based positioning systems.

6.12 Concluding Remarks, System Potential and Applications

Despite the known performance limitations of Received Signal Strength indicated in Chapter 2, section(s) 2.4 and 2.6; Wireless sensor nodes can provide a cost effective alternative to Assisted and GNSS based positioning systems. Obvious benefits include quick TTFF, high reliability, availability and accuracy. However they have weak points too. For example, the sensor node based positioning cannot provide diversity in navigation information such as velocity, acceleration and altitude.

They can be deployed rapidly to establish planned infrastructure or provide disaster relief for emergency applications. An appropriate deployment plan suited to individual disaster relief application needs to be designed. Lower TTFF means quicker position fixes, however the system is more applicable for local applications. Output parameters still need to be coded, decoded and translated for use in any system like GNSS. Radio range considerations require improved antenna design, efficient implementation and appropriate propagation model for efficient performance. The round trip constant associated to complete request-response processing to calculate the final TTFF

160

Chapter 6 WSN Based and WSN Assisted Positioning

can complicate the system design and reduce localization performance. Scenario based constants can significantly vary due to complexity of systems involved and their integration.

Independent Wireless sensor node applications can include building monitoring and security, acoustic video, vibration and other high speed data, large scale deployment. Some monitoring applications include industrial and environmental location based security provisioning, personal health, asset and location tracking. WSN can be used as barometric, temperature, pressure, accelerometer, seismic, and magnetic sensors. However the sensor network deployment needs to be globalised for a much wider adoption.

161

Chapter 7 Conclusions and Future Recommendations

7.1 Research Challenges

The main challenge of this research was to identify shortcomings in current Assisted-GNSS (A- GNSS) implementations for Location Based Services (LBS) solutions. Improvements were made to the Open Source GNSS Reference Server (OSGRS), and alternative A-GNSS techniques based on the use of adhoc sensor networks were developed and tested against competing technologies. Assisted Multi-GNSS has proven superior to generic or purpose built commercial systems for relevant applications. Being open source, OSGRS can be used to test A-GNSS implementations and algorithms.

Development of two subsequent generations of Multiple Assisted GNSS-OSGRS is described Ð thus constituting a major part of this research. These techniques build on the multiple network strategy proposed in Chapter 3. Multiple Assisted GNSS-OSGRS has demonstrated better performance than current A-GNSS implementations. In addition, the proposed wireless sensor network (WSN) based techniques have been shown to provide better viability/availability in “infrastructure-less” environments, with low power usage and suitability for rapid deployment in diverse environments.

7.2 Location Determination Techniques in Weak Signal Environments

The main objectives of this thesis can be summarized as follows:

a. To review GPS, GNSS, AGNSS, RNSS, SBAS and alternative positioning technologies. Several LBS variants to be investigated and shortcomings identified. Alternative navigation, communication and logging techniques to be suggested to BWRS, NSW Police and the VRA. To evaluate the performance of SPOT Satellite Messenger. To propose the architecture of a Multiple Sensor based hybrid Multi-GNSS.

162

Chapter 7 Conclusions and Future Recommendations

b. To develop an NTRIP capable OSGRS, improve system efficiency and integrate the system with an IP and mobile data network. Develop diverse configurations of the OSGRS to suit varying applications and to test and benchmark such configurations.

c. To upgrade and develop the OSGRSv3 server by upgrading the prior version. To augment the system with SMLC, GMLC, RRLP 3GPP LPP and OMA LPPe functionality. To evaluate the performance of the OSGRSv3 vis-à-vis the OSGRSv2. To propose the design and architecture of the OSGRSv4.

d. To propose an autonomous positioning method employing the WSN-enabled AGNSS. The stand-alone WSN-based positioning method can potentially mitigate the associated communication, energy-cycle and radio limitations. The system is to be benchmarked against the former.

7.3 Thesis Summary

The research work addressing the aforementioned objectives is summarised below:

a. BWRS operational limitations prompted the quest for superior solutions Ð due to limited performance of conventional techniques discussed in Chapter 3. The system of interest, SPOT Satellite Messenger claims a global footprint of 96% coverage with open or partial open sky availability. However the experiments revealed average reliability and availability not exceeding 40% in diverse test areas. A-GNSS demonstrated an average reliability of over 98%. Stand-alone, high sensitivity GPS has a lower availability rate of 86% than A- GNSS. With lowest time-to-first-fix (TTFF), highest number (average) of visible satellites and lowest failure rate, stand-alone systems performed the best. Excluding the indoor scenario from SPOT test results provides an availability performance improvement of approximately 4%. Limited performance of stand-alone positioning and assistance systems suggested the need for an improved hybrid and ubiquitous positioning solution. The presented system aims to address the GNSS acquisition, parameter communications, positioning logging and user tracking problems.

b. The OSGRS is based on the GRIP protocol, XML and Java software to parse the throughput assistance data. It can operate in several modes: MS-based or MS-assisted. The 163

Chapter 7 Conclusions and Future Recommendations

first version supported Novatel OEM3/4 GPS data sources with room for expansion to global GNSS data streams. This thesis expanded the capability of the OSGRS to support global GNSS caster data streams/formats in RTCM and RINEX formats. Java code has been upgraded to provision this functionality on both server and client sides.

c. The OSGRSv2 system can operate with multiple GNSS constellations to suit different needs, and provides high availability of greater than 99% and accuracy with low TTFF of 1.5s at a reasonable cost. Greater than 10 satellites were consistently tracked with an average accuracy of 2.5m. Code development, configuration and support have been explained. Effects of different configurations on system performance were discussed and several configurations suited to different applications were proposed.

d. RRLP-capable OSGRS has been developed and tested to enable provisioning of assistance information on wider throughput channels. As mentioned in Chapter 5, a next generation network scenario has been implemented in the lab for performance testing. The next generation LTE network elements were logically and/or physical isolated to support the RRLP throughput. SUPLr3 patent application has recently been finalised.

e. HSPA bandwidth on the user-plane addresses transport latency and to some extent manages the complications in network architecture by providing data correction capability. OSGRSv3 cannot only receive input from LPP and LPPe channels integrated into the mobile core network, but can also directly act as an LPPe system (once standardised and accepted). The system can be TCP/IP connected over conventional mobile, UMTS or LTE networks.

f. In principle, OSGRSv3 demonstrates better availability and accuracy; however final TTFF values were degraded due to system complexity causing processing delay. To mitigate this, an improved architecture was established: the OGSRSv4. The fourth version of OSGRS can potentially eliminate the TTFF performance cost associated the processing times and network latency.

g. The proposed WSN-enabled A-GNSS system provides performance improvements over the stand-alone system. However it requires integration, installation, programming and training with an appropriate deployment plan in disaster relief scenarios. System complexity can lead to arbitrary errors which motivated work on stand-alone WSN-based positioning. It

164

Chapter 7 Conclusions and Future Recommendations

may be interesting to integrate WSN with commercial systems such as SPOT Satellite Messenger to investigate how much performance improvement can be obtained. Potentially a reduction in acquisition times may be realised through efficient implementation. While both systems showed similar accuracy of 3.1m and availability greater than 99.9%, the TTFF of stand-alone WSN system was 0.3s lower than the WSN enabled AGNSS system. The sensor node based system is resilient to signal perturbations and partial node failure.

h. Signal strength is not directly associated to localization however it can assist to provide reasonable results in enclosed or indoor environments. Geographical complexity can make modelling of signal propagation more difficult for sensor node based systems.

Following key benefits have been obtained in Assisted and Multiple GNSS technologies through the above research:

a. Acquisition sensitivity improvement. b. Availability improvement. c. Satellite tracking and time to first fix improvement. d. Localization accuracy improvement and quality of service. e. Multiple GNSS and sensor support for redundancy. f. Cost effective algorithm implementation. g. Open source integration and testing without legal and proprietary requirements.

7.4 Recommendations for Future Work

On the basis of the analysis, discussion and findings of this thesis, the following recommendations are made for future work.

a. The SPOT Satellite Messenger uses a simplex communication channel on LEO commercial satellites for handling distress calls. In such an implementation the user cannot know the delivery status of a message. Future work should investigate the technical and economic viabilities and relevant implications of using a full duplex channel capable of providing message status feedback to the end-user. The communications channel might be similar to satellite phones, such as Thuraya, Iridium, Ericsson R290, etc. To reduce cost and increase

165

Chapter 7 Conclusions and Future Recommendations

availability alternating data transfer schemes should be studied as full channel dedication is not feasible due to economic implications and data overload.

b. Global expansion of adhoc and independent sensor networks, monitoring tags and indoor deployment, are open questions for future investigations. Future challenges for system designers and researchers could include the issues such as integration, testing, analysis, performance benchmarking and implications of radiation parameters. Applications might need to be customised for individual requirements, varying from person to person. This can be enabled by the flexible architecture of multi-GNSS positioning.

c. NTRIP is the most popular protocol for distribution of real-time GNSS data over the internet. New developments will see additional GNSS systems and signals, with inclusion of more precise orbit details, satellite clocks and specific atmospheric correction models being incorporated into the caster network. An important aspect of OSGRS design is enhancement of industry-level practicality by further improving hardware and firmware system efficiency. At the hardware level, application specific hardware may need to be used. On the software level multiple Java classes need to be code optimised to simplify compiling process and reduce system processing overhead.

d. Antenna range is a challenging issue in enclosed corridors and walls in indoor environments. Environmental factors can also have detrimental effects on outdoor positioning performance. Potential reduction in acquisition times can be realised through efficient duty cycling. Future applications may include integration with OSGRSv2 to expand the options for multi-GNSS acquisition sources. Potential benefits include time syncing and additional positioning resource pooling. Another important consideration is the quality of antennas used. Survey grade antennas have well controlled centre of phases on low cost nodes however they may be unviable for adhoc applications. Compact smaller dimension antennas with acceptable performance in carrier phase differential techniques may be considered suitable for higher accuracy applications. The Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) techniques are prone to collision risks which can be detected and mitigated by sensing pre-transmission packet activity and employing random-backoff. However message redundancy can affect energy budgets and hence overall performance due to energy budgeting issues.

166

Chapter 7 Conclusions and Future Recommendations

e. The PlaceEngine tool has gained industry attention for location estimation based on WiFi RSS, especially indoors where standard GNSS may fail. Manufacturers have been working to incorporate this into mainstream mobile and portable devices (PlaceEngine, 2009). The basic system concept is similar to Secure User Plane (SUPL) architecture. The client software is installed on the mobile device connected to a WiFi access point. On query the PlaceEngine server algorithm calculates and returns the location information on Google maps. Performance can be benchmarked against SUPL-assisted GPS and OSGRS. Worth investigating is the performance, and potential of this tool for low-infrastructure positioning applications. While OSGRS is expected to yield the best accuracy, shorter TTFF and higher availability, in principle SUPL may outperform PlaceEngine, due to the use of a standardised architecture.

f. It has been proposed that SMS services on mobile communication networks can be used to transfer GPS assistance data as part of a low-infrastructure implementation (LaMance, 2002). However, SMS services originally established for emergency operations may experience high latency and significant delivery failure rates. This may happen in cases of mobile number portability, delays in information and time updates in different gateways. This can also cause erroneous time-stamps. Character limitation is another issue if the assistance data contains more than the limit allowed by mobile phone carriers. This can result in (partial) loss of coordinate information, or whole messages being lost, for example when external-to-network or international gateways are involved. Use of other channels in existing WCDMA/GSM/PSTN networks to transport assistance data should be investigated. VoIP or HSPA protocols, or the IPSTAR sat system, could be considered, thus providing a robust alternative to SMS for some A-GNSS applications.

g. In the last few years L5 signals have been broadcast by GPS IIF satellites. It would be instructive to design a software-based GPS receiver that is L5-capable. L5 has a range of increased benefits over the L1 and L2 signals. Research would focus on tracking and acquisition approaches for the L5 signal. The open source Kai Borre receiver could be used for such analyses.

167

Chapter 7 Conclusions and Future Recommendations

7.5 Conclusive Remarks: A-GNSS Standardisation and Industry Status

The focus of this research work is to take necessary steps towards testing LPP- and LPPe-based OSGRS and hence contribute to standardisation efforts. SUPL3.0 and LPPe1.x support standardisation of third party devices to augment the functionality of LPP. Improvement and standardisation activities can take place independent of any commercial involvement or use of work-around solutions in the case of proprietary protocols. A-GNSS standardisation was initially highlighted during the development of the Galileo program. 3GPP and OMA are the two primary private sector participants, encouraging the unification of GPS, Galileo and other GNSSs to support the LBS market.

Future challenges for system designers and researchers will include issues such as integration, testing, analysis, performance benchmarking and implications of radiation parameters of multiple computing and radio systems. Algorithm implementation may be challenging and time consuming. In recent years (2000-2012), some private companies have been identified with A-GNSS standardisation activities (Monnerat, 2008; Wirolla, 2011; Sarwar et al., 2012):

a. Qualcomm Europe b. RITT c. SiRF Technology d. Huawei e. ZTE f. European GNSS Supervisory Authority (GSA) g. Alcatel-Lucent h. CGI i. Ericsson j. Global Locate (now Broadcom) k. Nokia and Nokia Siemens Networks l. Orange

168

Appendices

Appendix A OSGRS Assistance Model and Data Formats

This document describes a means of acquiring Global Navigation Satellite System (GNSS) assistance data using HTTP1.x as specified at multiple instances by (Sarwar et al., 2011 & 2012, Heo et al., 2007, Li et al., 2007 & Yan et al., 2007). Assistance data aids GNSS receivers in acquiring and measuring satellite signals, as well as being useful in calculating positions. The GNSS Reference Information Protocol (GRIP) provides a framework for discovering resources capable of providing any kind of location-based assistance data.

A.1 Assistance data support

The client can request assistance data for all satellites or limit it to satellites in view for the following assistance data types listed in the table below:

Table A.1 GNSS request structure

Navigation Model Yes Yes UTC Yes No RTI Yes Yes Ionosphere Model Yes No Acquisition Assistance No Yes Almanac Yes Yes Reference Time Yes Yes DGNSS No Yes

A.2 Interface procedures A.2.1 Client query for A-GNSS data (HTTP POST) Requests to the OSGRS must comply with the HTTP 1.1 protocol (RFC2616) and be made using the ‘POST’ method once a connection has been established. The header should contain the following parameters: User-Agent, Accept, Host, Content-Length, Content-Type. The ‘Accept’ and ‘Content-Type’ field should be set to ‘application/xml’.

169

Appendices

Example A.1 POST / HTTP/1.1 User-Agent: OSGRSClient 1.0 Accept: application/xml Host: 10.102.150.23:8080 Content-Length: 371 Content-Type: application/xml; charset=utf-8 -34.407 150.882

Figure A.1 UML representation of a GNSS Request

As described above in Table A.1, when making a request for assistance data, the client must specify the assistance type and also the data types, a UML representation of a GNSS request is shown below in Figure A.1A.1 Table A.1 High level GNSS Request structure

Element Attribute Range Description When a client makes a GNSS request for assistance data to GNSSRequest the OSGRS, the client needs to specify the GNSS type which can ONLY be GPS or Galileo. The NavType attribute is optional but needs to be specified when making a request for Galileo GNSS type. This is the top level

170

Appendices

element of a request.

GNSSType GPS, Required. This is a required attribute; it specifies the Galileo GNSS type of the assistance data requested. NavType I,C,F Optional. This attribute is used to specify the navigation type; it is only valid for A-Galileo GNSS data requests. Optional. This element is used when requesting assistance AssistTypeAllSats data for all satellites. data NavModel, Required. This attribute contains a list* of A-GNSS data IonoModel UTC, requested for all satellites. RTI, RefTime, Almanac Optional. This element is used when requesting data for AssistTypeSatsInView satellites in view, a position must be specified (this is the latitude and longitude) data NavModel, Required. This attribute contains a list* of A-GNSS data RefTime, RTI, requested for satellites in view. Almanac, DGNSS, AcqAss Position -180 to +180 Required. This is the child element of AssistTypeSatsInView, when requesting data for satellites in view, a position must be specified (this is the lat and long), the lat and long fields are separated by a space. *Note: When making a request for a list of assistance data, each assistance data type should be separated by a space, in the example below we are making a request for a list of assistance data for satellites in view which satisfies this format.

Table A.2 Sample implementation of a GNSS request

-34.407 150.882

In the example above, the client is sending a request to the OSGRS implementing the GRIP GNSSRequest definition. The GNSS Type is GPS. The client is requesting for IonoModel, RefTime, NavModel and RTI assistance data for all satellites, and more specifically requesting AcqAss for the latitude -34.4 and longitude 150.8.

A.2.2 Server response to request for A-GNSS data

Responses from the OSGRS contain the following header parameters: Content-Type, Server, Date and Content-Length. Content-type should be set to ‘application/xml’. XML response is in the body.

Example A.2 Content-Type: application/xml; charset=UTF-8 Server: OSGRS 1.0 Date: Tue, 22 May 2007 01:25:10 GMT Content-Length: 334 -34.407 150.882

172

Appendices

Figure A.2 UML Representation of a GNSS Response

The response is in a similar format to the request, but each data type will have its own individual element field under the appropriate request; for satellites in view or all satellites, a UML representation of the GNSS response is shown below in Figure A.2.

Table A.3 High level GNSS response structure

Element Attribute Range Description When the OSGRS is returning a response for GNSSResponse assistance data to the client, it is required to specify the GNSS type which can ONLY be GPS or Galileo. The NavType attribute is optional but needs to be specified when making a request for Galileo GNSS type. This is the top level element of a response. 173

Appendices

GNSSType GPS, Required. This is a required attribute; it specifies the Galileo GNSS type of the assistance data requested. NavType I,C,F Optional. This attribute is used to specify the navigation type; it is only valid for A-Galileo GNSS data responses. * This element is used if a particular data type is Unavailable unavailable. reason Optional. This attribute states the reason for the Data type being unavailable. * This element is used to list the data not supported by Unsupported the OSGRS reason Optional. This attribute states the reason for the Data type being unsupported. Optional. This element is used to contain the AssistTypeAllSats assistance data which have been requested for all satellites. NavModel, Optional. These elements are used to hold the Almanac, navigation model and almanac data, they contain data RefTime for individual satellites. The number attribute which is Sat number 01 to 32 a part of the sat element is the primary way of identifying a satellite in the specific GNSS. For example, in GPS this is the GPS PRN signal number (PRN), in Galileo this is the Satellite ID (SVID). Note: for reference time assistance data, data fields are in the form of a white spaced separated list*. UTC Optional. This element is used to hold the UTC data assistance data. IonoModel Optional. This element is used to hold the ionosphere data model assistance data. RTI Optional. This element is used to hold the RTI assistance data, it contains a list satellites which cannot be used. badSats 01 to 32 Required. This contains a white spaced separated list of bad satellites. Optional. This element is used to contain the AssistTypeSatsInView assistance data which have been requested for

174

Appendices

satellites in view of a specific latitude and longitude position. Position -180 to 180 Required. This is the child element of AssistTypeSatsInView, when requesting data for satellites in view, a position must be specified (this is the lat and long), the lat and long fields are separated by a space. AcqAss Optional. This element contains the assistance data for acquisition assistance data, it contains the TOW assist as well as TOWAssist Required. This element contains the TOW assist data. Sat number 01 to 32 Required. This element is identical to the element defined above for AssistTypeAllSats, RefTime element. DGNSS Required. This element contains the assistance data for differential corrections and has the same structure as NavModel, Almanac and RefTime defined above. RTI Optional. Defined above RefTime Optional. Defined above Almanac Optional. Defined above NavModel Optional. Defined above *Note: When making a request for a list of assistance data, each assistance data type should be separated by a space, for example: 1 2 3 represents satellites 1, 2 and 3 as individual members of the list.

* If any of the data types are unavailable or unsupported, either the ‘Unavailable’ or ‘Unsupported’ element should be used.

An example showing an implementation of a GNSS response is shown below in

Table A.4

175

Appendices

Table A.4 Sample implementation of a GNSS Response

8B065C8C25B5413657901F18FD4400A10AB84FF052B795DF8AAC6E110034 8B065C8C28344247E290029DFD5900A10C55F85DB15F0706B6935A0F0023 3 6 8 24 0602FFFE2906FFF8 00001F0000000890970E4B070E -34.407 150.882 8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190EFA448B065C8

176

Appendices

CA12AA5091B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B065C8CA1AC0079F86A32C9 FFF0269127BC14675EF1C04CFFAB23A5E094 8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF80143D38B065C8C A12A870A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B065C8CA1ACFFFBF9331B37F FA6268B1C9813770AD0980CFFAB4C87E6B3 407 5410671 2 407 1 0 0 407 5410671 4 407 1 0 0 407 5410671 8 407 1 0 0 407 5410671 9 407 1 0 0 407 5410671 12 407 1 0 0 407 5410671 17 407 1 0 0 407 5410671 26 407 1 0 0 407 5410671 28 407 1 0 0 407 5410671 29 407 1 0 0 The example above is a response to a client’s query for assistance data: IonoModel, UTC, RefTime, Almanac NavModel, and RTI. Ionosphere and UTC data is provided. Two satellites* are provided for both the navigation model data and almanac data. In this instance with the RTI data, there are 4 satellites which have been calculated to be bad for all satellites. The reference time is also given and DGNSS is not supported by the server. More specifically for acquisition assistance data from satellites in view at the position -34.407 (latitude) 150.882 (longitude) data is provided for satellite numbers 5 and 7. *Note: This is only an example and normally we would expect to get between 5-12 satellites for the navigation model assistance data (satellites in view) and 32 satellites for the almanac data.

A.2.3 Server Response to ambiguous request

Header structure is identical to GNSSResponse, but with the body containing a GNSSErrorResponse. When a client sends an ambiguous request, such as incorrect formatting or syntax, the server will respond with a list of the error data. A UML representation of a GNSSErrorRequest is shown below in Figure A.3 177

Appendices

Figure A.3 Representation of a GNSS Error Response

Table A.5 High level GNSS Error Response structure

Element Attribute Range Description When a client makes an ambiguous request or a GNSSErrorResponse request which does not conform to GRIP, the OSGRS will return an error response. This is the top level element of an error response. Required. This element is used to list the specific Error request error. Multiple instances of this element may be used. data Required. This attribute contains a list of error item(s) returned by the OSGRS.

An example showing the implementation of a GNSS Error Response is shown below

Table A.6 Sample implementation of a GNSS Error Response

In the example above shows a response to an ambiguous GNSS Request, the server has returned an error generated when parsing the request xml.

178

Appendices

A.3 OSGRS data formats

This section describes the data formats of the OSGRS.

a. Acquisition Assistance

Data structure: [dop0] [dop1] [dopu] [codephase][intcp][gpsbit][codpwin][azim][elev]

Field number Field type Data description Example 1 dop0 Doppler (0th Order 3052.45 term) - this is the frequency in hertz 2 dop1 Doppler (1st Order 0.65 term - this is the rate of change of Doppler 3 dopu Doppler Uncertainty - 87 this is an integer number in hertz, from 0 to 200 4 codephase CodePhase in 110 chips(integer) - this specifies the size of the search window, from 0 to 1022 5 intcp Integer Code Phase - 10 this is the number of 1023 chip segments from 0 to 19 6 gpsbit Specifies the GPS bit, 2 from 0 to 3 7 codpwin Code Phase search 500 window - this is the integer width of the 179

Appendices

search window, from 0 to 1023 8 azim Azimuth - this is the 55.12 azimuth of the satellites in degrees 9 elev Elevation - this is the 64.12 elevation of the satellite in degrees

Each field is separated by a comma space when transmitted using the GRIP protocol.

Example: 441405.35 3052.45 0.65 87 110 10 2 500 55.12 64.12

b. RTI

The RTI returned by the OSGRS is in the form of a list, each satellite in the list is separated by a comma space.

Example: 1 21 8 10 The satellite numbers returned are: 1 5 8

c. Reference Time

Data structure: [gnssweek][gnsstow] [towassist*] Field number # Bits Scale Field type Data Example Factor description 1 10 1 gnssweek GNSS week 789 number,

180

Appendices

measured in weeks, from 0 to 1023 2 23 0.08 gnsstow GNSS Tow, 504799.92 measured in seconds, from 0 to 604799.92 3 24 --- towassist *Refer to table - below for more information. See below for an example of a response for reference time.

d. TOW Assist

Data Structure:

[satid][tlmmsg][antsp][alrt][tlmrs]

Field Number # Bits Scale Field Type Data Example Factor Description 1 6 --- satid The satellite 12 identification number, from 0 to 63 2 14 --- tlmmsg The telemetry 10223 message being broadcasted by the GNSS satellite, from 0 to 16383 3 1 1 antsp Anti-spoof flag , 1 from 0 to 1 4 1 1 alrt Alert flag, from 0

181

Appendices

0 to 1 5 2 --- tlmrs This field 2 contains the two reserved bits in the TLM, from 0 to 3 Each field is separated by a comma space when transmitted using the GRIP protocol.

Note: satid and tlmmsg unitless while fields 2 to 5 are measured as bit field.

Example: 395 2099827 12 10223 1 0 2

e. Almanac

Data Structure: [hexstring]

Field Number # Hex Characters Field Type Data Description 1 60 hexstring Represents subframe data in hex with parity removed. Sat number represents SV ID. See ICD- 200 section 20.3.3.5.1.1

Note: In OSGRS SV IDs 1-32 represent ‘Almanac’ data Example: 8B062C37ACB641360C4E1F22FD7100A10D8D8D3395B84291C7A1910F0027 182

Appendices

f. Navigation Model

Data Structure:

[hexstring]

Field Number # Hex Characters Field Type Data Description 1 180 hexstring String represents subframes 1-3 of each SV in hex with the parity bits removed Example: 8B062C371C2662D1020123CC6FFFB64E19E21A82F8442A300000150F0B8B8B062C37 1CAB44003327345FED24090018036033491FEFA10DE2F82A307F8B062C371D2E0015 8D3F3139FFE22858848F0C4DB8434788FFAF2F440782

g. Ionospere Model

Data Structure:

[hexstring]

Field Number # Hex Characters Field Type Data Description 1 16 hexstring Represents bits 69-

183

Appendices

145 with parity removed in subframe 4 page 18

Example: 0C01FFFF2C00FDFF

h. UTC Model

Data Structure: [hexstring]

Field Number # Hex Characters Field Type Data Description 1 26 hexstring Represents bits 151- 279 with parity removed in subframe 4 page 18 Example: 000004000000014E8B0E4B070E

184

Appendices

Appendix B GRIP XML Schema Definition(s)

The OSGRS defines the following xml schema definitions which make up the GRIP protocol:

• GNSSResponse.xsd Response definitions • GNSSRequest.xsd Request definitions • commonDataTypes.xsd Common data types used. • GNSSErrorResponse Error response definitions

The protocol is used to request and transmit assistance data; the protocol is composed of 4 XSD files: one for handling the request, one for handling the response, a file which contains the common data types used, and one for handling errors from the request. The data format provided will be specific to the GNSS as specified in the relevant Interface Control Document (ICD) per satellite. For example the GPS data is specified in the ICD-200 and Galileo data is specified in the Galileo open service signal in space interface control document (GAL OS SIS ICD). The DGNSS data is supplied in RTCM format and additional data formats are described in this Appendix.

Note: RTI, Acquisition assistance data, and reference time are not defined in the ICD-200 or Galileo ICD (http://www.navcen.uscg.gov/pubs/gps/icd200/ , http://www.galileoju.com/)

a. GNSSRequest.xsd

185

Appendices

List of assitance data that can be requested for all satellites List of assitance data that can be requested for satellites in view, a position must be specified High level definition of a GNSS Request, it consists of AssistTypeAllSats(optional) and AssistTypeSatsInView(Optional). The GNSSType attribute needs to be specified

186

Appendices

NavType needs to be specified when making a request for Galileo GNSS data The assistance data GNSS Type needs to be specified when making a GNSS request

b. GNSSResponse.xsd

187

Appendices

no longer implemented-Data status indicators and number of sats availiable(mandatory) Individual satellite data, contains the satellite number identification attribute (1-32) (no whitespaces)

188

Appendices

Individual satellite data, contains the satellite number identification attribute (1-32) (with whitespaced list) List of data types not supported/implemented Bad satellites list determined by RTI calculations

189

Appendices

assistance data with individual satellite data w/ no TOW assist assistance data with individual satellite data w/ TOW assist

190

Appendices

reference time assistancce data with individual satellite data (list) RTI data type, contains a list of bad satellites which cannot be used Data type for Iono and UTC data types

191

Appendices

Unavaible data with optional reason Unsupported data with optional reason High level definition for a GNSS Response, GPS type is a required attribute. It contains a list of unavailable data, assistance data for sats in view(optional) and all sats.

192

Appendices

193

Appendices

c. GNSSErrorResponse.xsd

d. commonDataTypes.xsd

Appendices

targetNamespace="http://www.gmat.unsw.edu.au/snap/grip/1.5" version="1.5" The navigation type is required when requesting Galileo GNSS data The lat and long position The GNSS type can be either Galileo or GPS

195

Appendices

Assistance data which can be requested for all satellites Assistance data which can be requested for satellites in view of a lat and long position List of all assistance data types which can be requested

196

Appendices

197

Appendices

Appendix C GRIP Operation and Data (IETF Controlled Supplement)

(Thomson, 2011) specified the Experimental IETF GRIP Tool Internet-Draft with six month validity (expiry Dec 31, 2011) in accordance with BCP 78 and BCP79 to supplement the documents (Sarwar et al., 2011 & 2012, Heo et al., 2007, Li et al., 2007 & Yan et al., 2007) published at School of Surveying and Geospatial Engineering, UNSW. This media type is a specialization of application/xml [RFC3023], and many of the considerations described there also apply to application/grip+xml. It is available for viewing at: http://tools.ietf.org/html/draft-thomson-geopriv-grip-02

C.1 GRIP Operation Overview

A client is configured with the location of a GRIP server, or follows a hyperlink that leads to a GRIP server. This URI indicates the location of a GRIP metadata document which describes all that the server is capable of. From the metadata document, the client is able to determine what information is made available by the GRIP server and where that information is available from. The client retrieves one or more resources to acquire assistance data.

C.1.1 GRIP Metadata

A server providing a GRIP service might provide a certain subset of assistance data to clients. Conveying the set of assistance data types that it is capable of providing to clients is the basis of GRIP. To that end, a metadata document format is defined. A client retrieves a GRIP metadata document using an HTTP "GET" request. The metadata document contains a listing of each of the supported assistance data types, plus a URI indicating where each type can be requested. The following GRIP metadata document shows support for three global assistance data types, support for two local assistance data types over a small area. /grip/utc /grip/ephemeris /grip/ionosphere

198

Appendices

-33.856625 151.215906 -33.856299 151.215343 -33.856326 151.214731 -33.857533 151.214495 -33.857720 151.214613 -33.857369 151.215375 -33.856625 151.215906 /grip/ephemeris /grip/acqAssist A GRIP metadata document can be provided in response to an HTTP "OPTIONS" request made to any GRIP resource. This metadata document can include information about that resource (global and local elements with coverage), or it can include information on other resources.

C.1.2 Local and Global Assistance Data

The GRIP metadata format describes the types of assistance data that the server is willing to provide, separated into two sections: local and global. Local assistance data applies to a particular position on the Earth. When requesting this information, the client indicates the location of interest. The server constructs assistance data that is specific to that location. Global assistance data can be acquired that is useful to a receiver regardless of the position of the receiver. For instance, in GPS the relationship between the GPS time system and Universal Coordinated Time (UTC) is globally applicable. Some assistance data types are always localized, other items are always global.

199

Appendices

In some cases, the localized data provided for some types of assistance data is simply a subset of the global data that is useful at the specified location. For instance, a satellite navigation model, which includes information on the position of the satellite, can be provided as both global and local data. A global request might provide navigation parameters for all satellites in the constellation; a local request might only include those satellites that can be viewed from the indicated location.

C.1.3 GRIP Metadata Format

GRIP metadata is specified as an XML document of type "application/grip+xml". This document is split into three sections: global: This element describes what forms of global assistance data are made available and where each may be retrieved. local: This element describes what forms of local assistance data are made available and where each may be retrieved.

C.1.3.1 ‘coverage’ element

In order to provide GNSS assistance data, receivers need to observe and record satellite signals across a large area. These receivers either need to receive a signal from a satellite (such as the GPS navigation message) or take measurements of the satellite signal. Each receiver can only measure or observe a satellite for part of its orbit. A global distribution of receivers is necessary to be able to provide assistance data for the entire planet. Where receivers are distributed over a smaller area, GRIP provides a means to indicate where receivers are able to measure satellite signals. Both global and local sections optionally include a "coverage" element. The "coverage" specifies the region where the provided information provided is applicable. Outside this area, the assistance data might not be comprehensive or completely accurate. The coverage region is specified using a GML "Polygon" or "Envelope", or a "Circle" as defined in [RFC5491]. If no "coverage" element is specified, this indicates that assistance data can be provided for any location on the Earth. A GRIP service MAY provide information outside its indicated coverage area. Clients need to be aware that this information could be inaccurate, missing certain elements, or it could be extrapolated from old information. Coverage might vary depending on the type of assistance data. Some forms of assistance data, such as differential corrections, can only be collected for a small geographic area. Therefore, multiple "global" or "local" elements can be specified with different coverage areas. If the same assistance data type appears multiple times,

200

Appendices

or if multiple coverage elements are included, the coverage for that assistance data type is the union of the associated coverage regions.

C.1.3.2 ‘ad’ element

The "ad" element indicates availability of a specific type of assistance data. The text content of the "ad" element indicates a URI where assistance data can be acquired. This URI is either an absolute URI or specified relative to the base URI of the GRIP index document. The type of assistance data provided is specified in the "type" attribute of the "ad" element. This identifies an XML element by its qualified name [W3C.REC-xml-names-20060816], using the namespace context from the enclosing document. When included as a child of the "global" element, the "ad" element describes the location of resources that contain the indicated items of global assistance data. Similarly, when included in the "local" element, it indicates where local assistance can be acquired.

C.1.4 GRIP Assistance Data Requests

A GRIP assistance data request is a HTTP GET to the URI indicated in the GRIP index. For global assistance data resources, an unmodified request is sufficient to retrieve the indicated information. For local assistance data resources, a "GeoLocation" header is included in the request. The same resource MAY provide both global and local assistance data of the same type, using the presence or absence of the "Geolocation" header to determine which of these is requested. The MIME type of all assistance data documents is "application/grip-ad+xml". The document contains an XML document with a document element of the type indicated in the GRIP index. A server MUST generate appropriate HTTP status codes in response to errors. As long as it is acceptable to clients, the HTTP response SHOULD contain a GRIP "error" in the body of the message, using a MIME type of "application/grip+xml".

C.1.4.1 Location Parameters

The client MUST specify the location that the local assistance data is applicable to in a "Geolocation" header. Location information can be provided in the body of the request or by providing a URI to an external resource. If location information is necessary, but not provided, the server responds with an error contained in an HTTP 427 (Bad Geolocation) response. GET /grip/acqAssist HTTP/1.1

201

Appendices

Host: grip.example.com Accept: application/grip-ad+xml,application/grip+xml;q=0.5 Geolocation: geo:-35.406,150.882;u=1200 Latitude, longitude and altitude specified in URI parameters use the World Geodetic System 1984 (WGS 84) coordinate reference system. Location information MAY be provided by reference. The "locationuri" parameter is used to include a URI. Percent-encoding MUST be used to ensure that reserved characters in the URI are correctly escaped. The location URI either takes the form of an indirect reference, or location URI [RFC5808]. A location URI MUST resolve to a presence data information format - location object (PIDF-LO) [RFC4119] document. Alternatively, information can be provided directly in URI form using a geo: URI [RFC5870]. A server MAY choose to not support the "locationuri" parameter, or to limit the URI schemes that it accepts. If this is not the case, an error with a code of "unsupportedLocation" MUST be provided. A client MUST be prepared to receive this code and either dereference the URI and either provide the values directly or abandon the request.

C.1.5 GRIP Errors

Errors in the URIs provided are firstly indicated using HTTP errors. However, the body of the HTTP error MUST contain a GRIP document that describes the error. An error document consists of an "error" element, with a mandatory "code" attribute. Any number of "message" elements MAY be added to convey human-readable feedback on the error; each "message" element contains an "xml:lang" attribute that identifies the language of the text. Missing Geolocation header. The following values for the "code" attribute and the values of corresponding HTTP errors are defined: noLocation: (HTTP 427) A request for local assistance data did not contain location information. badLocation: (HTTP 427) A request for local assistance data contained location information that was badly formatted or was not understood by the server. unsupportedLocation: (HTTP 427) A request for local assistance data contained location information that might be valid, but the server is not able to use the provided form.

202

Appendices

noCoverage: (HTTP 400) A request for assistance data indicated a location that the server has no coverage for. noData: (HTTP 503) The identified assistance data type is currently unavailable. Used when the server is temporarily unable to provide assistance data.

C.2 Assistance Data

Assistance data that can be expressed in XML form is supported by this protocol. The XML element is the basic unit of assistance data, since this is what is identified in the "ad" element. All assistance data is provided with the same MIME type, "application/grip-ad+xml". The document element determines the type. New definitions of assistance data only require the definition of an XML format and the use of a unique namespace URI [W3C.REC-xml-names-20060816]. Formal schema definitions, such as XML Schema [W3C.REC-xmlschema-1-20010502] or RelaxNG [ISO.19757-2.2008] SHOULD be used, but are not necessary as long as structure and semantics are clearly defined. Assistance data for the Global Position System (GPS) is defined in [I-D.thomson- geopriv-grip-gps]. These assistance data are used in examples throughout this document.

C.2.1 Caching Assistance Data

Caching of assistance data is particularly useful in improving responsiveness and alleviating server load. Standard HTTP mechanisms are suitable for controlling caching of global assistance data, but local assistance data introduces complications. Adding a "geolocation" tag to the "Vary" header ensures that values are properly cached. Assistance data for two locations within close proximity might not vary significantly. However, HTTP caches place significance in any change in a URI, including trivially significant decimal places in numbers and even the ordering of URI parameters. Therefore, small changes in location can result in a completely different URI. A server MAY redirect requests that include "Geolocation" headers to location-specific resources in order to provide better support for caching. In serving a large number of requests, a server might choose to cache assistance data that is applicable over a geographic area. A method of caching optimization relies on fixing the locations that assistance data is provided for to a grid. Assistance data is only provided for the center point of the grid. All other points in the grid receive the same assistance data. The grid-based method allows caching by the server itself, but not a generic HTTP cache. A server MAY use HTTP redirection to more efficiently use generic HTTP caches. An HTTP 303 (See Other) is appropriate when responses are dependent on location. This improves cache-ability at a cost in latency. Alternatively, using the "Content-Location" header doesn't aid caching of an immediate request, but improves cache-ability for subsequent requests that are directed at resource 203

Appendices

identified in the "Content-Location" header. Local assistance data that is based on a location URI can change if the referenced document also changes. A server MUST either indicate that such local assistance data is not cacheable through the use of "Cache-Control" headers or indicate validity times with an "Expires”. The server might also include a "Geolocation" header that indicates the area that the assistance data applies to. Assistance data itself can be used to derive the location of a client. Servers MUST NOT allow assistance data based on location information to enter a shared cache. The "Cache-Control" headers for such requests MUST be set to "private" or "no-cache". Where redirection is used, the redirection response cannot be placed in a shared cache, but the resulting document is cacheable.

C.2.2 Time Assistance

It is common for GNSS systems to use a different time model than UTC. Commonly assistance data is used to relate the GNSS time to UTC. This allows a client that is accurately synchronized to the GNSS time (a necessary outcome or prerequisite of location determination) to very accurately synchronize with UTC time. Assistance data that relates time systems is an important part of this protocol. Indeed, assistance data that relates GNSS time with other time systems is also useful. It is not the intent for this protocol to itself provide time synchronization functions. Other protocols, such as Network Time Protocol (NTP) [RFC1305], or Simple NTP [RFC4330], perform this task efficiently and accurately. Specific access technologies also provide time synchronization services that are linked to access technology specific timing characteristics.

C.3 XML Schema

GNSS Reference Information Protocol (GRIP) Schema 204

Appendices

This document defines core elements of GRIP documents.

Appendices

minOccurs="0" maxOccurs="unbounded"/>

Appendices

use="required"/>

C.4 Security Considerations

A server MAY individually authorize clients and challenge clients to provide authentication credentials. How authentication credentials are negotiated is outside the scope of this specification. Receivers need to be aware that falsified assistance data can be used to cause a location calculation to be arbitrarily incorrect. In particular, falsifying the location of a satellite by altering ephemeris information could be used to cause the receiver to calculate any location. Small changes in location caused by these methods are difficult to detect, but larger changes can be identified through inconsistency in Doppler shift and comparison of basic satellite location with previously acquired (and trusted) estimates, such as the GPS almanac. Location information provided by a client in making a request for local assistance data is potentially privacy sensitive. A client SHOULD use HTTP over TLS [RFC2818] to ensure that only the identified server is able to use this information. Location URIs SHOULD use similarly secured channels to prevent attackers from intercepting or falsifying this information. Because location information is potentially sensitive, servers MUST NOT use location information for anything other than serving the request that contains it. GRIP metadata is designed to carry descriptions of how assistance data can be retrieved. This document could contain references to resources under the control of other parties that might be unaware of this linkage. The only authoritative source of metadata for a resource is the resource itself; all other links are informative only. A malicious server might use links to cause a client to leak

207

Appendices

information or trigger unintended actions. For instance, links in metadata might refer to files on the client system, or they might invoke specific protocol actions. Clients MUST validate any URI it receives before using it. Restricting use of URIs to "https:" (and optionally "http:") URIs limits the scope of any attack. Only accepting responses of the MIME type "application/grip-ad+xml" further reduces the ability of an attacker to trigger client behaviour.

The section registers two MIME types:

"application/grip+xml" for GRIP metadata and control documents. "application/grip-ad+xml" for GRIP assistance data documents.

C.5 Associated RFC(s)

Associated character set, encoding, security considerations, inoperability issues and other details are primarily specified in RFC3023 and controlled by IETF. Error codes are specified in RFC5226 whereas URN Sub-Namespace Registration is specified in RFC3688.

208

Appendices

Appendix D OSS Systems Interface employed for LPP/e Project

The following figures (D.1 and D.2) demonstrate the OSS systems employed to implement the LPP and LPPe network element configuration(s) (discussed in Chapter 5, Section 5.5 a & b). Shelf, slots, cards, port, interface details and status can be seen in D1. D2 demonstrates link(s) established to provision communication functionality.

Figure D.1 Figure D.2 Figures (D.3 and D.4) demonstrate the OSS systems employed to implement LTE RAN and C.E. based network configuration (discussed in Chapter 5, Section 5.5 a & b). D3 shows the shelf with highlighted interface EX2 where D4 shows link establishment with one of the network element(s) in highlight.

Figure D.3 Figure D.4

209

Appendices

Appendix E MICAz Wireless Measuring System (Datasheet)

210

Appendices

211

Appendices

Appendix F SPOT Satellite Messenger Technical Datasheet

212

Appendices

Appendix G OSGRS Mobile Execution

Android OS v4.0.3 on a HTC Desire HD in ‘rooted mode’ was employed to conduct data acquisition experiments on OSGRS server (discussed in Chapter 4, Section 4.13 b & c). In the figure below, the server is in transition acquisition from NTRIP caster through IP network. Results can be seen in the above sections.

Figure G.1

213

Appendices

Appendix H NTRIP Data Stream and Settings

Figures H.1 and H.2 show the user settings on an NTRIP GNSS client.

Figure H.1. NTRIP data stream. Figure H.2. NTRIP Client settings.

214

Appendices

Appendix I Miscellaneous Positioning Techniques

I.1 Hybrid Positioning Techniques

Hybrid techniques are capable of harnessing the potential of several positioning methods, and in so doing improve positioning performance in terms of reliability, coverage, and accuracy, etc. Some examples of hybrid positioning techniques are (Li, 2006):

a. AOA + RSS b. AOA + TDOA c. E-OTD + AGPS

Obvious disadvantages include deployment and operational costs with increased processing overheads.

I.2 Wireless LAN (WLAN) based Positioning

Originally developed in the 1990s, 802.11 WLAN or WiFi (IEEE, 1997) provides mobile internet access to portable user devices in an area of coverage of an “access point” or “WiFi node”. About a 100 million WiFi nodes were shipped by 2005 (Broadcom, 2005), significantly increasing the WiFi footprint, considering a relatively shorter development time of 10 years. Since then the number of deployed WiFi nodes is probably over a billion. The system attracted initial interest in 1985, when the US Federal Communications Commission (FCC) authorised the civilian use of the Industrial, Scientific and Medical (ISM) bands (frequencies: 900MHz, 2.4GHz and 5.8GHz) without licence requirements. The IEEE 802.11 standard defines the media access control (MAC) and physical layers (PHY) for wireless connectivity. The standard has a few variants operating on different data rates between 54-600Mbps and frequencies between 2.4-5GHz (IEEE Grouper, 2006; Bing, 2002). 802.11b was one of the mainstream WLAN standards initially employed (Geier, 2002). The IEEE 802.11 working group has ratified nine different standards (802.11a - i) (IEEE, 2006). WiFi was not intended to support positioning, however RSS measurements with access point ID (essentially Cell ID) makes it possible to locate a mobile user (MU) using one of several possible RSS-based

215

Appendices

techniques (Bahl and Padmanabhan, 2000; Saha et al., 2003; Ladd et al., 2002; Wang et al., 2003; Youssef and Agrawala, 2003).

There are essentially two types of positioning techniques using WiFi technology:

a. Signal propagation model can be used to calculate distance from RSS measurements (Wang et al., 2003; Bahl and Padmanabhan, 2000). However, local environmental and atmospheric factors affect the signal propagation model. b. Location “fingerprinting” technique can address some problems related to NLOS and multipath propagation (Haldat, 2002), and requires a database of wireless signal measurements at reference points of interest across the coverage area. MU location is estimated by comparing RSS measurements with the reference data (Ladd et al., 2002; Prasithsangaree et al., 2002; Youssef et al., 2003).

Li (2006) proposes the following possibilities for hybrid positioning that incorporate WiFi:

a. GPS + WiFi b. WiFi + AGPS + RFID c. WiFi + RFID + MEMS-INS

Obvious disadvantages include database generation, extensive interface development, algorithm implementation requirements and associated maintenance. Chapter 3 discusses a hybrid positioning method that mitigates some of the problems associated with many positioning techniques.

I.3 TV Signal based Positioning

Digital and analog television signal synchronisation can be employed for positioning purposes. Such signals, which have a power advantage of more than 40dB over a GPS signal, can help mitigate the multipath effects due to a wider bandwidth (of approximately 6MHz). Rabinowitz and Spilker (2004) introduced this technique, which uses the American Television Standard Committee (ATSC)’s Digital Television (DTV) signals to extract the timing signal, permitting the use of trilateration based on estimated distances between receiver and transmitters to calculate the receiver’s position. However, monitor units at known positions are needed to determine TV station clock offsets. Some tests have demonstrated a mean distance error of a few metres in low multipath 216

Appendices

environments, though errors grow to more than 30 metres inside a multi-storey building. Evaluations by Eggert and Raquet (2004) reported the use of National Television System Committee (NTSC)’s analog TV broadcast signal using a TDOA algorithm, and achieved 40-100m accuracy. The requirement for monitor units and data links are drawbacks of such systems, in addition to the inconsistent and larger antenna size(s). Furthermore, in many countries analog TV broadcasts are being phased out, replaced with their digital equivalents.

I.4 Adhoc and Sensor Networks based Positioning

An adhoc network is inherently “infrastructure-less”, autonomous and self-organised in sharing end-to-end information through multiple hops and intermediary nodes. Position is calculated using measurements between pairs of neighbouring nodes using any of the AOA, TOA, TDOA and RSS techniques. Hence, the network devices can be located relative to one another or in an absolute sense (Niculescu and Nath, 2001; Garcia, 2004). Relative position can be obtained easily in infrastructure-less environments, however in the case of absolute positioning at least one node needs to be connected to some fixed infrastructure (with known position). As with many other techniques, some of the obvious problems include NLOS, propagation and absorption errors. In addition, a system based on multiple nodes needs to be trained, deployed and tested before achieving practical readiness. This topic is discussed in detail in Chapter 6, where effective sensor network based techniques have been proposed and tested.

I.5 Ultra-Wideband (UWB) based Positioning

Ultra-Wideband (UWB) technology has been suggested for indoor positioning, with signal transmitters operating across relatively wide bandwidths, e.g. greater than 500MHz (Gezici et al., 2005). The transmitters employ very short pulse waveforms to spread energy across the frequency spectrum. Due to the inherent fine temporal resolution of UWB, arriving multipath components can be sharply timed at a receiver to provide accurate TOA estimates, which can make UWB suitable for high precision radiolocation applications. Commercialisation and operation of UWB devices was approved by the US FCC in 2003 for public safety and consumer applications (Patwari, 2005). IEEE (2006) have recognised the potential of UWB for high accuracy positioning. The IEEE 802.15 task group TG4a has been established to address the issues associated with communications, ranging and location with metre-level accuracy, high aggregate throughput, and ultra-low power.

217

Appendices

AOA, TOA, TDOA and RSS techniques can be employed depending on the requirements of an application. RMS 2D location accuracy of about 5cm, with RMS about 3-4cm in x, y coordinate components, have been reported (Correal et al., 2003).

218

Bibliography

BIBLIOGRAPHY

3GPP LTE LPP Release 11, Series xx (2012), ‘LTE and LPP Technical Specifications’, http://www.3gpp.org/ftp/Specs/latest/Rel-11/xx_series/ accessed 5 Jun 2012 3GPP LTE LPP Release 12, Series xx (2012), ‘LTE and LPP Technical Specifications’, http://www.3gpp.org/ftp/Specs/latest/Rel-12/xx_series/ accessed 7 Jun 2012 3GPP RRLP Release 10 (2011), ‘Digital Cellular Telecommunications System’, LCS, MS, SMLC, RRLP 3GPP TSG-RAN WG1 doc. No R1-00-1186, ‘Initial Simulation Results of the OTDOA-PE positioning method’, 2000, http://www.3gpp.org/ftp/tsg ran/WG1 RL1/TSGR1 16/Docs/ PDFs/R1-00-1186.pdf. 3GPP TSG-RAN WG1 doc. No R1-99b79, ‘Time Aligned IP-DL positioning technique’, 1999, http://www.3gpp.org/ftp/tsgran/WG1 RL1/TSGR1 07/Docs/Pdfs/R1-99b79.pdf ABIResearch (2009), Internet. Accessed on 01 Nov 2010. http://www.abiresearch.com/press/3336 Arthur, B. W. (2009), ‘The Nature of Technology: What it is and how it Evolves’, Free Press, New York. Ahonen S. & Laitinen H., ‘Database correlation method for UMTS location’, Proceedings of the 57th IEEE Vehicular Technology Conference, vol. 4, pp. 2696–2700, Jeju, South Korea, Apr 2003. Anisfield, N. (2000), ‘Ascension technology puts spotlight on DC field magnetic motion tracking’, HP Chronicle, vol. 17, no. 9, . Apache common libraries, accessed and downloaded 11Sept2010, http://commons.apache.org Axonn (2009), ‘Axonn STX2 datasheet AXONN LLC’, v1.5, Covington, Louisiana, accessed 20 April 2008, http://www.axonn.com/pdf/datasheet0409-AXTrackerSTX2.pdf Bahl, P & Padmanabhan, V, (2000), ‘RADAR: An In-Building RF-based User Location and Tracking System’, Microsoft Research, Infocom 2000, Volume: 2, On page(s): 775-784 vol.2, 26 Mar 2000. Bakker, G., de Munck, J.C., Strang van Hees, G.L. (1989), ‘Radio positioning at sea’, Delft University Rress, Delft. Bingemann M., (2012), ‘Vodafone keen to buy Telstra NZ subsidiary’, The Australian, 6 March 2012

219

Bibliography

BKG (2007), Networked Transport of RTCM Protocol, NTRIP, accessed 15Aug2010, http://igs.bkg.bund.de/index_NTRIP.htm Borkowski J. and Lempiäinen J., ‘Pilot correlation method for urban UMTS networks’, Proceedings of the 11th European Wireless Conference, vol. 2, pp. 465–469, Nicosia, Cyprus, Apr 2005. Borkowski J., Niemelä J. & Lempiäinen J., (2004), ‘Performance of Cell ID+RTT hybrid positioning method for UMTS radio networks’, Proceedings of the 5th European Wireless Conference, pp. 487–492, Barcelona, Spain, Feb 2004. Borkowski J, Niemelia J, Lempiainen J, ‘Location Techniques for UMTS Radio Networks’, Presentation of Reasearch Activities, Institute of Communications Engineering, Tampere university of Technology, Tampere, Finland Broadcom (2007), ‘Secure User Plane Location White Paper’, Irvine, California 92617, October 2007, accessed 10 Nov 2008, http://www.broadcom.com/collateral/wp/SUPL-WP100- R.pdf Brown, A & Olson, P (2006), ‘Urban/Indoor Navigation using Network Assisted GNSS’, Proceedings of ION 61st. Annual Meeting, Cambridge, MA, June 2006 Bryant, R (2005), ‘Using cellular telephone networks for GNSS anywhere’. GNSS World, 1 May 2005 BWRS (2006), ‘Bush Safety - Emergency Communication’, http://www.bwrs.org.au/pages/emergency_coms.html, accessed 21 Nov 2007 Caffery, J., Jr. and Stuber, G.L. (1998a), ‘Overview of radiolocation in CDMA cellular systems’, IEEE Communications Magazine, vol. 36, no. 4, pp. 38–45. Cambridge Positioning Systems (2005), http://www.cursor-system.com/cps/, accessed Feb 2008 CanadaGPS (2010), Tracking and Logging devices, http://www.canadagps.com/ Canalys, (2009), ‘Mobile navigation and location market trends 2009/2010’, 17 July 2009 Christ T, Godwin P (1993) ‘A prison guard duress alarm location system’. In: IEEE ICCST http://www.s2is.org/Issues/v1/n2/papers/paper14.pdf Chon, HD, Jun, S, Jung, H & An, SW (2004), ‘Using RFID for Accurate Positioning’, GNSS 2004, Sydney, Australia, 6–8 Dec 2004 Colley A., (2012), ‘Optus readies itself for online battle with structural changes’, The Australian, 6 March 2012 12:00am CommScope (2009), ‘Geometrix MLC, Mobile Location System’, accessed 6 May 2010, http://www.commscope.com/andrew/eng/product/geometrix/index.html

220

Bibliography

Correal, N.S., Kyperountas, S., Shi, Q. and Welborn, M. (2003), ‘An ultra wideband relative location system’, 2003 IEEE Conference on Ultra Wideband Systems and Technologies, Reston, Virginia, US, 16-19, Nov., pp. 394–397. CrossBow Wireless Technology Overview (2011), http://www.xbow.com/Technology/Overview.aspx, accessed 10 Jun 2011. Dammalage, T.L., Srinuandee, P., Samarakoon, L., Susaki, J., & Srisahakit, T. (2006). ‘Potential Accuracy and Practical Benefits of NTRIP Protocol Over Conventional RTK and DGPS Observation Methods’. Map Asia, 29 Aug – 1 Sept, Bangkok, Thailand. Dejun Zou; Zhongliang Deng; Lianming Xu; Weizheng Ren, (2008) ‘Seamless LBS Based on the Integration of WSN and GPS’, Computer Science and Computational Technology, ISCSCT 30 Dec 2008 Deligiannis N., and Louvros S., ‘Hybrid TOA-AOA Location Positioning Techniques in GSM networks,’ Wireless Personal Communications, vol. 54, pp. 321–348, 2010, 10.1007/s11277-009-9728-x, http://dx.doi.org/10.1007/s11277-009-9728-x, accessed 20 Jun 2011 Department of Transportation and Department of Defense (2002-08), ‘2001 Federal Radionavigation Systems’, archives, accessed Nov 07, 2008. Dettmering, D., Soehne, W., Franke, P., & Weber, G. (2007), ‘The use of GNSS real-time data streams for geodetic applications - first results and perspectives’, In EGU General Assembly, 16 April. Vienna, p.184 Diggelen, FV (2009), ‘AGPS: Assisted GPS, GNSS and SBAS’, NavtechGPS, Springfield, VA Dobbie P., (2012), ‘By the numbers: money goes underground, not in the cloud’, 5 Mar 2012 DORIS (2012), ‘International DORIS Service’, http://ids-doris.org/ Drane, C., Macnaughtan, M. and Scott, C. (1998), ‘Positioning GSM Telephones’, IEEE Communication Magazine, vol. 36, no. 4, pp. 46-54, 59. Eclipse IDE for Java Developers, Version: Helios Service Release 1, accessed and downloaded 5Aug2010, http://www.eclipse.org/ Eclipse Compiler includes software from Apache Software Foundation, accessed and downloaded 5Aug2010, http://www.apache.org/ EE Times, ‘Dual GPS/Galileo chips to exhibit sub-second acquisition times’, http://www.eetimes.com/electronics-products/analog-products/4087793/Dual-GPS-Galileo- chips-to-exhibit-sub-second-acquisition-times

221

Bibliography

Eggert, R.J. and Raquet, J.F. (2004), ‘Evaluating the navigation potential of the NTSC analog television broadcast signal’, ION GNSS 17th International Technical Meeting of the Satellite Division, Long Beach, California, USA, 21-24 September, pp. 2436-2446. Ericsson, (2011), ‘LTE – a 4G solution’, Ericsson White paper, http://www.ericsson.com/res/docs/whitepapers/WP-LTE-positioning.pdf EUREF (2007), Global NTRIPServers and Casters listing accessed Aug2010, http://www.euref- ip.net/home European Space Agency (ESA), (2012), ‘EGNOS’, http://www.esa.int/esaNA/egnos.html European Space Agency (ESA), (2012), ‘Galileo’, http://www.esa.int/esaNA/galileo.html European Parliament, (2002),’Directive 2002/22/Ec of The European Parliament and of the Council on Universal Service and Users’, Rights Relating to Electronic Communications Networks and Services Universal Service Directive,” March 7, 2002. FCC 911 Wireless Services (2009), ‘911 Services’, Public Safety and Homeland Security Bureau, http://www.fcc.gov/pshs/services/911-services/, accessed 15 June 2008, 1 July 2009 & 6 July 2010 Featherstone, W. E., and Kuhn, M. (2006), ‘Height Systems and Vertical Datums: A Review in the Australian Context, Journal of Spatial Science, 51(1), 21-42. Federal Aviation Administration (2007), ‘Wide Area Augmentation System (WAAS)’, accessed 20 January 2009, http://www.faa.gov/airports_airtraffic/technology/waas/ Feiner S., COMS W4170 Predicting the Future, http://monet.cs.columbia.edu/courses/csw4170/classes/UIfuture-11f.pdf, Department of Computer Science, Columbia University, New York, NY 10027, 6 Dec, 2011 FindMeSpot (2007), ‘User Guide’, accessed 10 April 2008, Frédéric, C. (2002), ‘Mobile and Vehicles Enhanced Services, Location Service Study Report’, D2.3.1, MOVIES IST-2000-30041. Gallagher T., Li B., Dempster A., Rizos C., ‘Power Efficient Indoor/Outdoor Positioning Handover’, International Conference on Indoor Positioning and Indoor Navigation (IPIN), 21-23 September 2011, Guimaraes, Portugal: link Garcia, J.-E. (2004), ‘Ad hoc positioning for sensors in underwater acoustic networks’, OCEANS'04. MTS/IEEE TECHNO-OCEAN'04, Kobe, Japan, 9-12 November, vol. 4, pp. 2338-2340. Garin, L (2010), ‘Wireless Sensor Network-Based Distributed GNSS. Receiver Architecture for Infrastructure Monitoring’, UCGE Reports Number 20302, Positioning, Location and 222

Bibliography

Navigation (PLAN), Jan 2010 Garmin (2005), ‘Garmin eTrex data sheet’, accessed 12 December 2008, Ganeriwal S., Kumar R., Adlakha S., Srivastava M., (2002), ‘Network-wide Time Synchronization in Sensor Networks’, Technical report, University of California, Los Angeles, Dept of Electrical Engineering, 2002. Ganeriwal S., Kumar R., Srivastava M., (2003), ‘Timing-sync Protocol for Sensor Networks’, SenSys’03, November 5-7, 2003, Los Angeles, California, USA. General Information on GPS, ‘Global Positioning System (GPS), http://www.navcen.uscg.gov/?pageName=GPSmain Geo Info Strategies, ‘GPS Corrections Using GPRS’, http://www.geoinfo.rs/e/GPSSoftware_e.asp, accessed 20 Sep 2010 Gezici, S., Tian, Z., Giannakis, G.B., Kobayashi, H., Molisch, A.V., Poor, H.V. and Sahinoglu, Z. (2005), ‘Localization via Ultra-Wideband Radios’, IEEE Signal Processing Magazine, vol. 22, no. 4, pp. 70-84. GLONASS, ‘Global Navigation Satellite System’, http://www.glonass-center.ru Gontran, H., Skaloud, J., & Gillieron, P.-Y. (2004), ‘Photobus: Towards Real-Time Mapping’. In 20th ISPRS Congress, 12-23 July. Istanbul, Turkey, Part B, Commission 2, pp7-12. Available at: http://www.isprs.org/congresses/istanbul2004/comm2/papers/89.pdf Goze, T.; Bayrak, O.; Barut, M.; Sunay, M.O., ‘Secure User-Plane Location (SUPL) Architecture For Assisted GPS (A-GPS)’, Advanced Satellite Mobile Systems, 2008. ASMS 2008. 4th , vol., no., pp.229,234, 26-28 Aug. 2008 GPS Space Segment, ‘Interface Control Document’, http://www.navcen.uscg.gov/pubs/gps/icd200/ GPS signals, ‘Signal and Message details, C-NAV, MNAV’, http://en.wikipedia.org/wiki/GPS_signals Graycar, A (2000), ‘Missing Persons: Incidence, Issues and Impacts’, Australian Institute of Criminology, accessed 6 September 2008. Gurtner, W., (2007), ‘The Receiver Independent Exchange Format’, RINEX, Version 3.00, Astronomical Institute, University of Bern, November 28, 2007 www.epncb.oma.be/ftp/data/format/rinex300.pdf Haldat, E. (2002) Fingerprinting based-technique for positioning, http://www.telecomlab.oulu.fi/home/Radiotekniikka/materiaali/fingerprinting-report.pdf. Hallberg, J & Nilsson, M (2002), ‘Positioning with Bluetooth, IrDA and RFID’, Division of Computer Engineering, Lulea University of Technology, 2002 223

Bibliography

Harper N, ‘Server-Side GPS and Assisted-GPS in Java’, (2009), Artech House Publishers. Harter, A., Hopper, A., Steggles, P., Ward, A. and Webster, P. (2002), ‘The anatomy of a context- aware application, Wireless Networks’, vol. 8, no. 2-3, pp. 187-197. Hartinger, H. & Brunner, F.K., (1999), ‘Variances of GPS phase observations: The SIGMA-ɛ model’, GPS Solutions, Vol. 2, No. 4, 35-43. Hata, M. (1980), ‘Empirical formula for propagation loss in land mobile radio services’, IEEE Transactions on Vehicular Technology, vol. 29, no. 3, pp. 317–325. Helfrick A., (2009), ‘Principles of Avionics’, 5th Edition Henderson M. & Henderson P., (1998), ‘Missing people: issues for the Australian community’, Canberra: Commonwealth of Australia Henderson M., Henderson P. & Kiernan C., (2000), ‘Missing persons: incidence, issues and impacts’, Trends & issues in crime and criminal justice no. 144. Canberra: Australian Institute of Criminology, http://www.aic.gov.au/publications/tandi/tandi144.html Holtzman, J.M. and Goodman, D. J. (eds) (1993), ‘Wireless communications: future Directions’, Kluwer Academic Publishers, Boston. IEEE 802.15, (2005), ‘WPAN Low Rate Alternative PHY Task Group 4a (TG4a)’, http://www.ieee802.org/15/pub/TG4a.html IETF, (2008), ‘Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)’, Feb 2008. IGS Real Time Working Group. (2008), ‘RT-IGS Prototype Network Station Information’ http://www.rtigs.net/station.php, Jun 2008 Indian Regional Navigation Satellite System (IRNSS), http://ilrs.gsfc.nasa.gov/satellite_missions/list_of_satellites/irns_general.html Infonetics Research (2007), ‘An Evaluation of In-Building Wireless Coverage’, http://www.infonetics.com/whitepapers/Infonetics-In-Building-Wireless-white-paper.pdf International GNSS Service (2007). IGS Real-Time Pilot Project 2007-2010. Jacobson, L. (2007), ‘GNSS Markets and Applications’, Artech House, Chapter 6 Future GNSS Markets, pp. 95, 114. James M., Anderson J. & Putt J., Missing Persons Australia, (2008), ‘Missing persons statistics, trends and issues in Crime and Criminal Justice’ http://www.missingpersons.gov.au/aboutus/~/media/MP/Files/PDFs/Trends%20%20Issues. ashx, Australian Institute of Criminology, issue No. 353, accessed 15 Jun 2009 James M., Anderson J. & Putt J., (2008), ‘Missing personsin Australia’, Research and public policy series no. 86, Canberra: Australian Institute of Criminology. 224

Bibliography

http://www.aic.gov.au/publications/rpp/86/index.html Java communication libraries, http://www.javax.com, accessed and downloaded 11 Sep 2010 Java help and documentation guidelines, http://www.oracle.com, accessed and downloaded 20Oct2010 Java help and documentation guidelines, http://www.sun.com, accessed 20Oct2010 Java ‘transmit receive libraries’, http://www.rxtx.com, accessed and downloaded 12Sept2010 Janssen, V. (2009), ‘Understanding Coordinate Reference Systems, Datums and Transformations’, International Journal of Geoinformatics, 5(4), 41-53. Juniper Research (2010), ‘Mobile Location Based Services’, https://www.juniperresearch.com/reports/mobile_location_based_services, Applications, Forecasts & Opportunities 2010 - 2014 Kaddourah, Y., King, J. and Helal, A. (2005), ‘Cost-precision tradeoffs in unencumbered floor- based indoor location tracking’, Proceedings of the third International Conference On Smart homes and health Telematic (ICOST), Sherbrooke, Canada, 4-6 July. Kaplan ED (2005), ‘Understanding GPS: principles and applications’, (2nd ed.), Artech House, Boston KDDI, (2006,) “Study on Emergency Call Handling in Japan,” KDDI Corporation, November 30, 2006. King, TM, Geler, GJ, Zhao, Y & Hart, RC (2001), ‘Method and Apparatus for Assisted GNSS Protocol’, US Patent No.:6313787B1, Nov 6, 2001 Krishnamachari, B. (2005) "Networking Wireless Sensors", Cambridge University Press,2005. Krumm J, Williams L, Smith G (2002) ‘SmartMoveX on a graph—an inexpensive Active Badge Tracker’, UbiComp 2002 Klukas, R, Lachapelle, G & Fattouche, M, (1998): ‘Cellular Telephone Positioning Using GNSS Time Synchronization’, GNSS World Magazine, 9, 4, 49-54. Koshima, H. and J. Hoshen (2000), ‘Personal locator services emerge’, IEEE Spectrum, Feb 2000, 41-48 Ladd, A.M., Bekris, K.E., Rudys, A., Marceau, G., Kavraki L.E. and Dan, S. (2002), ‘Robotics- based location sensing using wireless Ethernet’. Eighth ACM Int. Conf. on Mobile Computing & Networking (MOBICOM), Atlanta, Georgia, USA, 23-28 September, pp. 227-238. LaMance, J, Jarvinen J & DeSalas J (2002), ‘Assisted GPS: A low infrastructure approach’, GPS World, Mar 1, 2002 LaMarca,A., J. Hightower, I. Smith, and S. Consolvo (2005) "Self-Mapping in 802.11 Location 225

Bibliography

Systems" , Intel Research Seattle, Lecture Notes in Computer Science, 2005 - Springer, ISSN 0302-9743. LAN/MAN Standards Committee, IEEE Computer Society, 19 Mar 2009, ‘IEEE 802.15.4d Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for ‘Personal Area Networks’ http://standards.ieee.org/getieee802/download/802.15.4d- 2009.pdf, accessed 10July 2010 Laaraiedh M., Stephane A., & Uquen B., (2011), ‘WHERE : Wireless Hybrid Enhanced Mobile Radio Estimators’, http://www.ietr.fr/spip.php?article378 Laurs I., (2011),’Mobile operators will lose voice services to mobile platforms’, Gigacom, 11 Sep 2011 Lee, W.C. (1993), ‘Mobile communication design fundamentals’, John Wiley & Sons, New York. Lenz, E. (2004), ‘Networked Transport of RTCM via Internet Protocol (NTRIP) Application and Benefit in Modern Surveying Systems’, In FIG Working Week, 22-27 May. Athens, Greece. http://www.fig.net/pub/athens/papers/ts03/ts03_2_lenz.pdf Laitinen, H., Ahonen, S., Kyriazakos, S., Lahteenmaki, J., Menolascino, R. and Parkkila, S. (2000), ‘Cellular Location Technology, document for Cellular network optimization based on mobile location’, http://www.vtt.fi/tte/tte35/pdfs/CELLO-WP2-VTT-D03-007-Int.pdf. Li B., Mumford P. & Dempster A.G. (2009), ‘Secure User Plane Location: concept and performance’, GNSS Solutions, Springer Berlin / Heidelberg, 1080-5370 (Print) 1521-1886 (Online) April 2009 Li B., Quader I., Dempster A., (2008), ‘On outdoor position location with Wi-Fi’, Journal of Global Positioning Systems, pp 18-26, Vol. 7, No. 1, 2008 Li B., Mumford P., & Dempster A., (2009), ‘Secure User Plane Location: concept and performance’, GPS Solutions, Springer Berlin / Heidelberg, 1080-5370 (Print) 1521-1886 (Online) April 2009 Li B., (2006), ‘Terrestrial Mobile User Positioning Using TDOA and Fingerprinting Techniques’, SSIS, UNSW, Feb 2006 Li B., Ramsey-Stewart E., Johar K., & Rizos C., (2009), ‘More Freedom to Blind and Vision Impaired - A proposed navigation and information system’, IGNSS Symposium 2009 Liang S. & Wigren T., (2009), ‘AECID Fingerprinting Positioning Performance’, Proc. IEEE GLOBECOM 2009, pp. 2767-2772, Nov 2009, http://202.194.20.8/proc/GLOBECOM2009/DATA/PID967396.PDF. LORAN-C General Information, ‘LORAN-C Navigation System’, http://www.navcen.uscg.gov/?pageName=loranMain 226

Bibliography

Lorincz, K & Welsh, M, 2006, ‘MoteTrack: A Resilient, Uncentralized Approach to RF-Based Location Tracking’, Springer Personal and Ubiquitous Computing, Special Issue on Location and Context-Awareness, October 2006. ISSN: 1617-4909 (Print) 1617-4917 2006 LTE World, “LTE Protocols & Specifications”, www.lteworld.org/category/tags/otdoa accessed 17 Dec 2011 MacLeod, K., Caissy, M., Fong, R., & Forgues, V. (2002). NRCan’s Internet GPS Data Relay (iGPSDR). In International GPS Services for Geodynamics, Towards Real-Time Network, Data and Analysis Centre 2002 Workshop, April 8-11. http://igscb.jpl.nasa.gov/igscb/resource/pubs/02_ott/session_3.pdf Maróti, M., B. Kusý, and G.Balogh (2005) “Radio Interferometric GeoLocation” , SenSys’ 05, November 02-04, 2005, San Diego, California, USA. Maróti, M., B. Kusy, G. Simon, and A. Ledeczi (2004) "the Flooding time synchronization protocol," SenSys'04, November 3-5, 2004, Baltimore, Maryland, USA. Mautz, R (2009), ‘Overview of Current Indoor Positioning Systems’, Geodesy and Cartography, Versita, 2009. MIC Japan, Ministry of Internal Affairs and Communications, (2009), http://www.soumu.go.jp (in both Japanese and English) accessed January 16, 2009. Mortbay jetty libraries, http://www.mortbay.org, accessed and downloaded 10Sept2010 Murata M, St. Laurent S, Kohn D (2001) XML Media Types (RFC 3023). http://www.rfceditor.org/rfc/rfc3023.txt, accessed 20 Dec 2010 Myllymaki P, Roos T, Tirri H, Misikangas P, Sievanen J (2001) ‘A probabilistic approach to WLAN user location estimation’, Proceedings of the 3rd IEEE Workshop on Wireless LANs National Missing Persons Coordination Centre n.d (2009),‘SOS.Search options and support: a guide for the families andfriends of missing people, Canberra: Australian Federal Police Ndili, A. & Enge P, (1998), ‘GPS receiver autonomous interference detection’, IEEE Position, Location and Navigation Symposium, Palm Springs, California, April 20-23, 123-130. Nemerix (2007), ‘Axonn on Nemerix NX2’, PRIME NEWSWIRE, MILPITAS, California, http://www.axonn.com/news_11-07-07.html, accessed 7 November 2007 NENA i3 Technical Requirements Document, (2006), NENA 08-751, Issue 1, Sep 28, 2006, http://www.nena.org/sites/default/files/08-751 20060928.pdf. Niculescu, D. and Nath, B. (2001), ‘Ad-hoc positioning system (APS), IEEE Global Telecommunications Conference’, San Antonio, USA, 25-29 November, vol. 5, pp. 2926- 2931. 227

Bibliography

Netbeans Java compiler, http://www.netbeans.com, accessed and downloaded 9Sept2010 Networked Transport of RTCM via Internet Protocol (NTRIP) sourcetable(s), (2011), ‘Caster, Network and Stream specification records’, http://software.rtcm-ntrip.org/wiki/Sourcetable, accessed 24 Dec 2011 NOAA (2007), ‘NOAA Satellite and Information Service’, Public Domain accessed 15 August 2007, http://www.sarsat.noaa.gov NTRIP Architecture, http://www.geoinfo.rs/e/GPSSoftware_e.asp, accessed 20 Sep 2011 Open Mobile Alliance (2007a), ‘Secure User Plane Location architecture’, Approved version 1.0— 15 June 2007, OMA-AD-SUPLV1_0-20070615-A Open Mobile Alliance (2009), ‘Secure User Plane Location Architecture v2.0’, Sep2010, OMA- AD-SUPL-V2_0-20110527-C Open Mobile Alliance (2011), ‘Secure User Plane Location Architecture v3.0’, May2011, OMA- AD-SUPL-V3_0-20110308-C Open Mobile Alliance (2011), ‘LPPe Public Release Documents’, http://member.openmobilealliance.org/ftp/public_documents/loc/2011/ accessed 13 Dec 2011 Open Mobile Alliance (2011), ‘Secure User Plane Location Architecture v3.0’, May2011, OMA- AD-SUPL-V3_0-20110308-C Pala, A., Sanna, G., & Vacca, G. (2004). ‘Real Time Mapping With DGPS-enabled Navigation Equipment’. 20th ISPRS Congress, 12-23 July. Istanbul, Commission 2, pp51-56. http://www.isprs.org/congresses/istanbul2004/comm2/papers/97.pdf Parkinson, B.W. and Spilker, J.J., Jr. (eds) (1996), ‘Global Positioning System: Theory and Applications’, (Vol. 1). American Institute of Aeronautics and Astronautics, Inc., Washington D.C. Parkingson, B.W., Stansell, T., Beard, R. and Gromov, K. (1995), ‘A history of satellite navigation, Journal of the Institute of Navigation’, vol. 42, no. 1, pp. 109-164. Patwari, N., Hero, A.O., Ash, J., Moses, R.L., Kyperountas, S. and Correal, N.S. (2005), ‘Locating the nodes’, IEEE Signal Processing Mag., vol. 22, no. 4, pp. 54–69. Pereira, J. M., (2004), ‘E-112 and Location-Based VAS Regulatory Framework and Privacy Concerns’, 8 Mar 2004 Peterson, B, Bruckner, D & Heye, S (1997): ‘Measuring GNSS Signals Indoors’, Proceedings of the Institute of Navigation ION GNSS-97 (September 16-19, 1997, Kansas City, Missouri), pages 615–624.

228

Bibliography

Prasithsangaree, P., Krishnamurthy, P. and Chrysanthis, P.K. (2002), ‘On indoor position location with wireless LANs’. 13th IEEE Int. Symp. on Personal, Indoor, & Mobile Radio Communications, Lisbon, Portugal, 15-18 September, vol.2, pp. 720-724. Priyantha, N.B., Chakraborty, A. and Balakrishnan, H. (2000), ‘The cricket location support system’, Proc. 6th ACM International Conference on Mobile Computing and Networking, Boston, USA, 06-11 August, pp.32-43. Proc J., ‘Omega Radio Navigation System’, www.jproc.ca/hyperbolic/omega.html Rabinowitz, M. and Spilker, J.J., Jr. (2004), ‘A new positioning system using television synchronization signals’, Rosum Corporation white paper, http://www.rosum.com/rosum_whitepapers.html. Rao B., Minakakis L., ‘Evolution of Mobile Location-based Services’ www.faculty.poly.edu/~brao/CACM.LBS.pdf Rappaport T, Reed, J, & Woerner, D (1996), ‘Position location using wireless communications on highways of the future’, IEEE Commun. Mag., vol. 34, pp. 33–41, Oct. 1996. Receiver Independent Exchange Format (2007), RINEX, accessed 25Jan2011, http://gps.wva.net/html.common/rinex.html RFC3023 (2001), ‘XML media types’, http://tools.ietf.org/html/rfc3023, accessed 30 Jun 2010 and 20 July 2012 Rizos, C. (1996), ‘Principles and Practice of GPS Surveying Monograph 17’, School of Surveying and Spatial Information Systems, The University of New South Wales, Sydney, Australia. Rizos, C. (2005), ‘Trends in geopositioning for LBS, navigation and mapping’. Int. Symp. & Exhibition on Geoinformation 2005, Penang, Malaysia, 27-29 September, invited paper. Rizos, C. (2007), ‘Alternatives to Current GPS-RTK Services and Some implications’, GPS Solutions, 11 (3), 151-158. Rizos, C., & Cranenbroeck, J. van. (2006). ‘Making GNSS-RTK Services Pay’. In 23rd FIG Congress, 8-13 October. Munich, Germany. TS 13 - Forum for Providers and Users of Real Time Correction Rizos, C. Roberts, G.W., Barnes, J. & Gambale, N., (2010), Locata, ‘A new high accuracy indoor positioning system’, International Conference on Indoor Positioning & Indoor Navigation, Zurich, Switzerland, 15-17 September, to appear in proceedings. Rogowski, J., Kujawa, L., Leszczynski, M., & Rogowski, A. (2004). ‘Some Experiences in RTK and DGPS Measurements Using Internet and GSM Mobile-phone’. EUREF 2004 Symposium of the IAG Subcommission for Europe, 2-5 June. Bratislava, Slovakia, Volume 14. http://www.euref-iag.net/symposia/book2004/P-10.pdf 229

Bibliography

Roshanzadeh M., Saqaeeyan S., (2012), ‘Error Detection & Correction in Wireless Sensor Networks By Using Residue Number Systems’, I. J. Computer Network and Information Security, 2012, 2, 29-35, Published Online March 2012 in MECS, http://www.mecs- press.org/, DOI: 10.5815/ijcnis.2012.02.05 RTCM Special Committee 104 on Global Navigation Satellite Systems (GNSS) Service (2001) RTCM10402.3 RTCM Recommended Standards for Differential GNSS (Global Navigation Satellite Systems) Service, Version 2.3, The Radio Technical Commission for Maritime Services, Arlington. RTCM Special Committee 104 on Global Navigation Satellite Systems (GNSS) Service (2001) Saha, S., Chaudhuri, K., Sanghi, D. and Bhagwat, P. (2003), ‘Location determination of a mobile device using IEEE 802.11b access point signals’, IEEE Wireless Communications & Networking Conference (WCNC), New Orleans, Louisiana, USA, 16-20 March, vol.3, pp.1987-1992. Salvation army, (2008), ‘Missing Person Statistics’, http://www.salvationarmy.org.au/family- tracing/missing-persons-statistics.html, accessed 15 Jun 2009 Sarwar, A., Li, B. & Dempster, A. (2009), ‘SPOT in Location Based Emergency Services, LBES, Detailed Analysis’, IGNSS Symposium, 1 – 3 Dec, 2009 Sarwar, A., Li, B. & Dempster, A. (2009), ‘All-Scenario Health Monitoring Intelligent Multi-GNSS Positioning System’, IGNSS Symposium, 1 – 3 Dec, 2009 Sarwar, A., Glennon, E. & Rizos, C. (2011), ‘Proposing a MultiGNSS Assisted GNSS-Concept and Performance’, IGNSS Symposium, 15-17 Nov 2011 Sarwar, A., Glennon, E. & Rizos, C. (2011), ‘Test results of a Wireless Sensor Networks Assisted GNSS’, IGNSS Symposium, 15-17 Nov 2011 Sarwar, A., Glennon, E & Rizos, C (2012), ‘Performance of High Sensitivity Open Source Multi- GNSS Assisted GNSS’, IPIN, 13-15 Nov 2012 Sarwar, A., Glennon, E. & Rizos, C. (2012), ‘RRLP (LPP and LPPe) Based Open Source Mobile Multi-GNSS Assisted GNSS Assistance Model’, IPIN, 13-15 Nov 2012 Sarwar, A., Glennon, E. & Rizos, C. (2012), ‘Cooperative Wireless Sensor Nodes based Acquisition for Mobile Location Services (MLoC)’, IPIN, 13-15 Nov 2012 Sarwar, A., & Li B., (2012), ‘SPOT GNSS in Emergency and Location Based Services’, JoGPS Dec 2012. Sarwar A., (2012), ‘Mobile (Operators, Platforms and GNSS), Technology Dynamics and Industry Economics’, pp35-36, Coordinates

230

Bibliography

Services from Continuously Operating Reference Stations (CORS) – Session II. http://www.fig.net/pub/fig2006/papers/ts13/ts13_01_vancranenbroeck_rizos%20_0298.pdf Shivaramaiah N., ‘Enhanced Receiver Techniques for Galileo E5 AltBOC Signal Processing’, SSIS, UNSW, Jun 2011 SiRFstarIII Chipset Overview, GSD3tw (2007), http://www.csr.com/products/26/sirfstariii-gsd3tw, accessed 15 Aug 2011 SiRF (2009), ‘SiRFstarIII, High Performance, Low Power GPS Solution, SiRF Chips + GPS’ accessed 13 Oct 2007, http://www.sirf.com/products/GSC3LPProductInsert.pdf Smailagic A, Small J, Siewiorek DP (2000) ‘Determining user location for context aware computing through the use of a wireless LAN infrastructure’ , 2010 SnapTrack (2003), ‘Location Technologies for GSM, GPRS and UMTS networks’, SnapTrack white paper http://www.cdmatech.com/download_library/pdf/location_tech_wp_1-03.pdf. Soehne, W., Habrich, H., & Weber, G. (2008). ‘Data Centre Support for the IGS-RT Pilot Project’. International GNSS Service, Analysis Center Workshop 2008, Miami, Florida, 4-6 June. http://www.ngs.noaa.gov/IGSWorkshop2008/docs/igs08_soehne.ppt SMLC, ‘How SMLC works’, http://www.creativitysoftware.net/what-is-an-smlc, accessed 13 Dec 2011 Slijepcevic S, Megerian S, Potkonjak M, (2002), ‘Energy Efficient Schemes for Wireless Sensor Networks with Multiple Mobile Base Stations’ ACM SIGMOBILE Mobile Computing and Communications Review, Volume 6 Issue 3, July 2002 Pages 67 – 78, ACM New York, NY, USA Stone, WC (1997) ‘Electromagnetic Signal Attenuation in Construction Materials’, NIST Report 6055, National Institute of Standards, Gaithersburg, Maryland TrackingTheWorld (2010), Tracking and Logging devices, http://trackingtheworld.com/ The Working Group for WLAN Standards, ‘IEEE 802.11 WIRELESS LOCAL AREA NETWORKS’ http://grouper.ieee.org/groups/802/11 Thorne, T.G. (ed.) (1960), ‘Navigation systems for aircraft and space vehicles’, Pergamon Press, Oxford. TinyOS (2010) ‘Operating System for motes’, and WSN, http://www.tinyos.net, accessed December 2010. Toumaz (2009), ‘Revolutionary body monitoring for health care: Wireless, Intelligent, Continuous, Low Cost’, http://www.toumaz.com/index.php, accessed 20 March 2009. TruePosition, ‘Location Determination and Intelligence Solutions’, http://www.trueposition.com/ TruePosition, ‘U-TDOA Location Determination Solutions’, http://www.trueposition.com/tech_U- 231

Bibliography

TDOA.php Turunen S, ‘Network Assistance, what will new GNSS signals bring to it’, Inside GNSS, Spring 2007. Wang, J., Dai, L., Tsujii, T., Rizos, C., Grejner-Brzezinska, D. and Toth, C. (2001), ‘GPS/INS/Pseudolites integration: concept, simulation and testing’, 14th Int. Tech. Meeting of the Satellite Division of the U.S. Inst. of Navigation, Salt Lake City, Utah, USA, 11-14 September, pp.2708-2715. Wang S., ‘Location Based Services for Mobiles: Technologies and Standards’, WCNC 2008 / ICC 2008 Wang, W., Wang, Z. and O’Dea, B. (2003), ‘A TOA-based location algorithm reducing the errors due to Non-Line-of-Sight (NLOS) propagation’, IEEE Trans.Veh. Technol., vol. 52, no. 1, pp. 112-116. Wang, Y., Jia, X., Lee, H.K. and Li, G.Y. (2003), ‘An indoor wireless positioning system based on WLAN infrastructure’, 6th Int. Symp. on Satellite Navigation Technology Including Mobile Positioning & Location Services, Melbourne, Australia, 22-25 July, CD-ROM proc., paper 54. Want, R., Hopper, A., Falcão, V. and Gibbons, J. (1992), ‘The Active Badge Location System’, ACM Trans. Information Systems, vol. 10, no. 1, pp. 91-102. Ward, A., Jones, A. and Hopper, A. (1997), ‘A new location technique for the active Office’, Personal Communications, IEEE, vol. 4, no. 5, pp. 42-47. Wauters W., (2010), ‘Mobile Location-Based Services’, http://techcrunch.com/2010/02/23/location- based-services-revenue/, 23 Feb 2010 Wax, M. and Hilsenrath, O. (2000), ‘Signature matching for location determination in wireless communication systems’, US patent 6112095. Weber, G. (2008), ‘Real-time IGS Network Management and Data Exchange Interfaces’. In International GNSS Service, Analysis Center Workshop 2008, Miami, Florida, 4-6 June. http://www.ngs.noaa.gov/IGSWorkshop2008/docs/Weber_RTIGS_PP.ppt Weber, G., & Bruyninx, C. (2008). ‘Monitoring The Real-time IGS NTRIP Interface’. In International GNSS Service, Analysis Center Workshop 2008, Miami, Florida, 4-6 June. http://www.ngs.noaa.gov/IGSWorkshop2008/docs/RT-ops-weber2.pdf Weber, G., Dettmering, D., Gebhard, H., & Kalafus, R. (2005), ‘Networked Transport of RTCM via Internet Protocol (Ntrip) -IP-Streaming for Real-Time GNSS Applications’. In ION GNSS 18th International Technical Meeting of the Satellite Division, 13-16 September. Long Beach, California, pp22, 43-47. 232

Bibliography

Weber, G., & Gonzalez-Matesanz, J.F. (2004), ‘EUREF-IP for Wireless GNSS/DGNSS, Example Implementation in Madrid’. EUREF Publication No. 13, Mitteilungen des Bundesamtes fur Kartographie und Geodasie, Band 33, 78-83. Weber, G., & Mervart, L. (2008). The BKG Ntrip Client (BNC). ‘In International GNSS Service’, Analysis Center Workshop 2008. Miami, Florida, 4-6 June. Available at: http://www.ngs.noaa.gov/IGSWorkshop2008/docs/RT-ops-weber1.pdf Weiser M., ‘Ubiquitous computing’, http://www.ubiq.com/hypertext/weiser/UbiHome.html Weston D. N. and Schwieger V., (2010), ‘Cost Effective GNSS Positioning Techniques’, FIG Commission 5 Publication, Jan 2010 Weyn, M & Schrooyen, F (2008), ‘A WiFi Assisted GNSS Positioning Concept, University College of Antwerp’, Department of Applied Engineering, Paardenmarkt 92, B-2000, Antwerp, Jan 2008. Wireless E911 Location Accuracy Requirements, Second Report and Order, FCC, Sep 2010. Wigren T., (2007), ‘Adaptive Enhanced Cell ID Fingerprinting Localization by Clustering of Precise Position Measurements’, IEEE Transactions on Vehicular Technology, vol. 56, no. 5, pp. 3199-3209, 2007. Wigren T., Anderson M. & Kangas A., (2010) ‘Emergency Call Delivery Standards Impair Cellular Positioning Accuracy’, Proc. IEEE ICC 2010, May 2010. Wirola L (2011), ‘Location Standards Driving mass market LCS adoption’, Location and Commerce, Nokia, ICL-IGNSS 2011, 29 Jun 2011, http://www.icl-gnss.org/2011/index.php Wirola, L., Alanen, K., Käppi, J., Syrjärinne, J. (2006). ‘Bringing RTK to Cellular Terminals Using a Low-cost Single-frequency AGPS Receiver and Inertial Sensors’, Proceedings of 2006 IEEE/ION Position, Location, and Navigation Symposium, 2006 Workshop on ‘Location-Based Technologies, Services, and Applications’, Brussels, Belgium, March 8, 2004. Xerces ‘XML parser libraries’, http://xerces.apache.org, accessed and downloaded 10 Sep 2010 Yan, T., Mumford, P., Dempster, A.G., Rizos, C., Hoang, N., & Fernando, M., 2007. Open source GNSS reference server. 20th Int. Tech. Meeting of the Satellite Division of the U.S. Inst. of Navigation, Fort Worth, Texas, 25-28 Sep, 2224-2229. Yan T., Lim S., Rizos C., (2009), ‘Performance Analysis of Real-time GNSS Data Distribution over the internet’, 2009 Youssef, M., Agrawala A. and Shankar, A.U. (2003), ‘WLAN location determination via clustering and probability distributions’. IEEE Int. Conf. on Pervasive Computing & Communications (PerCom) 2003, Fort Worth, Texas, USA, 23-26 March, pp.143-150. 233

Bibliography

Youl B., (2008), Intel Mobility Group, ‘3GPP LTE’, http:www.3g4g.co.uk/Lte/LTE_Pres_0805_Intel.pdf, accessed 5 Mar 2012 Zhao, Y. (2002), ‘Standardization of mobile phone positioning for 3G systems’, IEEE Communications Magazine, vol. 40, no. 7, pp. 108-116.

234